Vì sao các ông lớn công nghệ lại đua nhau phát triển ngôn ngữ lập trình của riêng mình?_link vào fabet

Chỉ trong vòng 3 năm,ìsaocácônglớncôngnghệlạiđuanhaupháttriểnngônngữlậptrìnhcủariêngmìlink vào fabet gần như gã khổng lồ công nghệ nào cũng đã có một ngôn ngữ lập trình của riêng mình. Đình đám nhất là sự kiện ra mắt của Swift vào năm 2014: với ngôn ngữ này, Apple sở hữu một ngôn ngữ vượt trội hơn hẳn Objective-C về mức độ trực quan, mức độ dễ học và khả năng maintain (sửa lỗi, bảo trì hệ thống cho tương lai).

Đối thủ truyền kiếp của Apple là Microsoft thì đã có ngôn ngữ riêng (C# .NET) từ lâu. Đến năm 2016, C# được tiếp sức mạnh mẽ khi gã khổng lồ phần mềm tuyên bố mua lại Xamarin, một công nghệ cho phép phát triển ứng dụng iOS, Android và Windows đồng thời từ một codebase viết bằng C#.

Không đứng ngoài cuộc, Facebook cũng ra mắt một phiên bản cải tiến của PHP với tên gọi "Hack". Google gần đây nhất tuyên bố sẽ hỗ trợ một ngôn ngữ mới mang tên Kotlin để các nhà phát triển ứng dụng có thêm lựa chọn khi phát triển cho Android. Thực tế, Kotlin không thuộc về Google mà là một ngôn ngữ có tương thích với Java do một công ty độc lập phát triển. Tuy vậy, xét tới vai trò "thâm căn cố đế" của Java trên lĩnh vực doanh nghiệp, có lẽ trong tương lai gần Kotlin chỉ có thể thay thế ngôn ngữ này trên hệ điều hành của Google mà thôi.

Từ góc độ kỹ thuật, lợi ích của Swift, Hack và Kotlin so với các ngôn ngữ tiền nhiệm được các ông lớn sử dụng là tương đối rõ ràng. Tầm nhìn dành cho C, PHP và Java đều là các ngôn ngữ đột phá khi ra mắt, song chúng không thuộc về thời đại di động và mạng xã hội. Lý do đầu tiên để các ngôn ngữ mới ra đời là để khắc phục các điểm yếu cố hữu của các ngôn ngữ cũ. Ví dụ, quyết định thêm khả năng hỗ trợ static type (kiểu tĩnh) vào PHP của Facebook khi tạo ra hack cũng là có lý do rất rõ ràng: tăng khả năng kiểm tra code và bắt lỗi cho ngôn ngữ ngay trong quá trình code.

Hoặc, cải tiến lớn nhất của Kotlin so với Java là thiết kế nhằm loại bỏ lỗi NullPointerException, một lỗi quá quen mặt với lập trình viên OOP, xảy ra khi hệ thống cần gọi đến một biến chưa được reference tới bất kỳ một giá trị nào trong bộ nhớ. Các cơ chế cải tiến của Kotlin so với Java, ví dụ như không cho phép gán biến String thành null hoặc construct ? sau tên biến để tự động trả về giá trị null khi biến gọi tới đang là null, sẽ giúp cho các lập trình viên có thể tránh "lỗi tỷ đô" này một cách dễ dàng.

Quan trọng hơn cả là những vấn đề của riêng từng ông lớn, những mục đích mà họ muốn theo đuổi. Ví dụ, Google phát triển GO là bởi các ngôn ngữ cũ chưa thực sự phù hợp với deep learning. Hãy nhớ rằng tất cả các ông lớn công nghệ đều đã có hàng năm trời sử dụng các ngôn ngữ cũ để giải quyết bài toán của riêng họ - họ hiểu rất rõ giới hạn của các công nghệ hiện tại khi theo đuổi các bài toán riêng đó.

Và họ có tiềm lực để tạo ra những ngôn ngữ mới, khắc phục những điểm yếu nhãn tiền của ngôn ngữ cũ để giải những bài toán quen thuộc một cách thuận tiện, dễ dàng hơn.

Nhưng điều không mấy ai nhận ra, là những bài toán của Apple hay của Facebook có thể cũng là bài toán của cả thế giới công nghệ. Nói một cách đơn giản, nếu như Apple có thể tạo ra một ngôn ngữ trực quan, dễ học theo kiểu script nhưng vẫn có thể đảm bảo hiệu năng ở mức chấp nhận được cho các ứng dụng di động, tại sao không "mở" ngôn ngữ ấy ra cho tất cả mọi người cùng sử dụng? Làm gì có lập trình viên nào không thích các ngôn ngữ vừa có hiệu năng tốt, vừa dễ maintain?

Tương tự, nhiều developer dùng PHP chắc hẳn cũng đã gặp phải những vấn đề mà Facebook từng gặp phải. Dùng Java, bạn có thể hiểu được những tình huống Google muốn tránh.

Còn với Xamarin, Microsoft lại giải quyết một bài toán tất yếu mà ai ai cũng có thể nhìn ra, ngay cả khi thời đại Internet of Things sắp bùng nổ: ứng dụng/dịch vụ nào cũng sẽ phải hỗ trợ nhiều loại nền tảng khác nhau. Trong thời đại đa nền tảng này, bất cứ một coder nào cũng đều mong muốn có thể tiết kiệm tối đa công sức bằng cách tái sử dụng lượng code tối đa có thể (cụ thể hơn là các lớp code chứa business nằm ngoài các lớp code gọi trực tiếp xuống hệ điều hành). Dĩ nhiên, bài toán cao đẹp ấy cũng xuất phát từ riêng một vấn đề của Microsoft: Windows (và Windows Phone trước đây) quá thiếu ứng dụng so với iOS và Android.