(PCWorldVN) PHP hay Node, SQL hay NoSQL, biên dịch hay kịch bản - đó là 3 trong số những tranh luận dường như bất tận về mặt kỹ thuật đối với ngành lập trình hiện nay. Trong đầu của chúng ta luôn luôn tồn tại những điều trái ngược nhau mà khiến chúng ta phải chọn lựa. Đó là tính song đôi của một sự kiện, hiện tượng, và nó xuất hiện rất thường xuyên trong đời sống: cộng sản hay tư bản; chua hay ngọt; chuyền bóng hay giữ bóng... Mọi thứ chúng ta nhìn vào dường như đều đi theo cặp, đối chọi nhau, mang lại cho chúng ta nhiều cơ hội khác nhau nếu đi theo hướng này, hoặc theo hướng khác. Trong ngành công nghiệp máy tính cũng không ngoại lệ, mà trái tim của nó chính là công nghệ. Công nghệ cũng khiến chúng ta băn khoăn, vì mỗi một công nghệ đều có thế mạnh riêng, mang lại những giải pháp đặc trưng riêng. Bên này thì là X, nhưng bên kia hoàn toàn không phải là X. Và rồi chúng ta lại phải chọn lựa dựa trên rất nhiều yếu tố tác động. Dưới đây là 10 cặp đối chọi nhau mà các nhà phát triển nhiều năm nay từng trăn trở nên đi theo hướng nào. Với mỗi cặp ấy, chúng ta phải đối diện với những câu hỏi mang tính bản lề, tạo nên đặc trưng của từng công nghệ. Chúng ta thích tính đơn giản hay tính chính xác? Nguồn mở hay hỗ trợ kỹ thuật của nhà sản xuất? Trong ngoặc hay khoảng trắng? Âm hay dương?... Những câu hỏi ấy đặt chúng ta vào thế tiến thoái lưỡng nan. PHP hay Node.js Chưa bao giờ vào đến được trái tim của những nhà khoa học máy tính nhưng PHP lại được rất nhiều người đón nhận vì nó thêm được một chút "trí tuệ" cho trang web. Nó có được những framework tuyệt hảo như WordPress, Drupal, Joomla... Nhiều trang web chạy trên nền PHP. Nhưng đến nay, có những kẻ hỡ trong mô hình này. Những nhà lập trình trẻ lại chuộng NOde.js hơn, là một cơ chế phía máy chủ được lập trình trên nền JavaScript. Đột nhiên, các nhà lập trình có thể viết mã chạy được trên cả phía máy khách lẫn máy chủ mà không cần phải học cả 2 ngôn ngữ riêng. Node.js có đặc trưng riêng của nó nhưng nó cũng có nhiều framework rất tuyệt, giúp nó sánh ngang được với PHP. Liệu thế hệ tiếp theo có chuộng tính đơn giản trong viết mã JavaScript hay không? Hoặc cũng có thể kết hợp tính đơn giản này bằng cách nhúng mã vào trong HTML? Những ai thích JavaScript chắc chắn sẽ chuyển lên Node. Còn những ai muốn dùng những framework ổn định của PHP như WordPress hay Drupal có lẽ sẽ tránh xa tính hấp dẫn của Node.js. MySQL hay PostgreSQL Hai nền tảng cơ sở dữ liệu nguồn mở tuyệt vời này đấu với nhau từ cả 2 thập kỷ qua và chưa thấy được hồi kết. Một mặt, MySQL có được thị phần rất lớn trên web nhờ khả năng dễ dàng cài đặt và cấu hình. Mặt khác, PostgreSQL lại mở ra một cơ chế giao dịch tốt hơn để bảo vệ dữ liệu chống lại lỗ hổng bảo mật. Cả hai đều có hướng phát triển nhắm vào thế mạnh của kẻ kia, vì MySQL đang đưa ra những khả năng cải thiện giao dịch còn PostgreSQL đơn giản hơn khi thiết lập. Những khác biệt cơ bản, lâu đời vẫn còn thể hiện rất rõ trong cuộc chiến của hai nền tảng cơ sở dữ liệu này. PostgreSQL được xem như "ổn định" hơn còn MySQL lại được đánh giá "nhanh" hơn, nhưng điều này có vẻ còn rất mơ hồ so với thực tế. Nhưng về sau, có vẻ PostgreSQL lại được những tay tin tặc trẻ hay những kẻ không thích nền tảng của Oracle chuộng hơn. Swift hay Objective-C Apple luôn luôn một mình một ngựa trên con đường Objective-C, là ngôn ngữ lạp trình sạch, gọn, kết hợp giữa C và hướng đối tượng. Nhưng thời gian thay đổi và Swift ra đời, có cú pháp hiện đại nên giữ chân được nhiều nhà phát triển viết ứng dụng cho nền tảng Apple. Chắc chắn là những ai học C "gốc" không quan tâm đến mấy dấu hoa thị và nhiều file, nhưng những kẻ lập trình mới vào nghề sẽ chuộng Python, Ruby và thậm chí Java hơn. Liệu Swift với cấu trúc gọn nhẹ sẽ hấp dẫn được các nhà phát triển Apple? Liệu các nhà phát triển Python và Ruby sẽ chuyển sang iOS và bỏ rơi Objective-C cũ kỹ? Hoặc thế giới sẽ bị các nhà phát triển Objective-C rất hiệu quả thống trị? Những thư viện và tính năng mới sẽ được lập trình trong Swift hay trong Objective-C? Apple đã công bố rằng cả hai ngôn ngữ này sẽ tồn tại song song nhau. Vì vậy, các nhà phát triển chắc chắn sẽ dùng ngôn ngữ nào mình quen thuộc hơn. Còn ai yêu mến Python hay Java sẽ hướng đến Swift. Còn những ai thành thục C sẽ gắn bó với Objective-C. Python hay Ruby Cách đây đã lâu, một ngôn ngữ lập trình kịch bản (script) giống như kẹo chewing gum đối với phần mềm. Nếu bạn cần gắn kết những chương trình lớn lại với nhau thì bạn có thể viết mã đơn giản trong hệ điều hành, thế là xong. Đâu đó trong cách này, người ta lại thích những ngôn ngữ ngắn gọn để tạo chương trình lớn thực sự hữu ích. Ruby bùng nổ thực sử khi nó kết hợp được với framework Rails. Bộ đôi này giúp đơn giản hoá việc gắn giao diện frontend phức tạp vào cơ sở dữ liệu chỉ bằng vài dòng mã. Trong khi đó, Python lại tìm được cộng đồng yêu khoa học. Đa số phòng thí nghiệm trên thế giới thường xuyên sử dụng Python. Và với khả năng phân tích dữ liệu tuyệt vời trong bất kỳ doanh nghiệp nào thì Python thực sự chiếm được cảm tình của các phòng lab nghiên cứu, phân tích về dữ liệu thuộc những tập đoàn lớn. Liệu thế hệ tiếp theo sẽ bị lôi kéo bởi tính đơn giản của Python nhờ cấu trúc khoảng trắng? Liệu Ruby có vươn ra được ngoài Rails? Liệu các hàm tích hợp của Python sáng giá hơn những "viên đá quý" gem của Ruby? Bạn có muốn trở thành kẻ chuyên phân tích khoa học dữ liệu hay trở thành tin tặc lang thang trên web? Có lẽ trận chiến giữa hai ngôn ngữ này ngày càng khốc liệt hơn và tách biệt hơn lúc trước khi mà những chuyên gia web hướng nhiều đến Rails còn các nhà khoa học quay sang các thư viện của Python. SQL hay NoSQLMột bên là cơ sở dữ liệu mà có lẽ ông cha ta từng dùng. Dữ liệu nằm gọn gàng trong các bảng biểu và dữ liệu được lấy ra dựa trên truy vấn, lấy ra theo hàng. Còn một bên là NoSQL mới mẻ, cho tốc độ rất nhanh và có thể xử lý cùng lúc nhiều truy vấn nhưng lại thỉnh thoảng ra tình trạng lỗi hoặc dữ liệu không chính xác, nhất quán. Bạn có muốn những hệ cơ sở dữ liệu truyền thống, với quy trình bảo mật giao dịch truyền thống luôn luôn chính xác đối với dữ liệu của mình? Hay bạn muốn một công cụ hiện dại hơn, rẻ hơn, nhanh hơn, tải rất hiệu quả từ các cụm máy chủ? Chắc chắn là tính nhất quán và tính chính xác là rất cần thiết và tối quan trọng đối với ngân hàng, nhưng nếu một bảng dữ liệu đầy những thứ linh tinh từ Internet thì sao? Liệu cái gì cũng cần được bảo vệ ở mức tốt nhất? Câu trả lời là những ai cần tính nhất quán tuyệt đối như ngân hàng và ngành hàng không sẽ sử dụng cơ sở dữ liệu truyền thống SQL với những giao dịch nghiêm túc. Còn lại, ai cũng chọn NoSQL có tốc độ nhanh, đơn giản và khả năng mở rộng tốt. JavaScript hay Dart và Go Có thể có vài nhà lập trình của Google chuộng JavaScript nhưng bạn không thể biết được liệu nó có bị thay thế hay không. Đầu tiên là Google Web Toolkit (GWT), một trình biên dịch đa nền rất tốt, biến Java thành JavaScript. Nếu bạn từng xem mã nguồn của Gmail, là một trong những sản phẩm của Google, thì bạn sẽ biết được nó không phải làm bằng JavaScript. Rồi Google phát minh ra Dart và Go, hai ngôn ngữ có thể một ngày nào đó thay thế JavaScript trong trình duyệt. Cả Dart và Go đều có những người tâm huyết với nó đang làm việc ở đúng nơi đúng chỗ. Họ sửa những lỗi chính trong JavaScript và trình duyệt, nhưng nhiều người lại không mấy quan tâm. JavaScript ở trên máy chủ trở nên phổ biến nhờ vào Node.js. Ai cần gì hơn thế nữa? Với mọi khả năng và quyền hạn của mình, Google đang chống lại một trận chiến gồm một đội quân lập trình viên khổng lồ đang theo đuổi JavaScript lâu nay và bây giờ phải viết lại chương trình cho máy chủ của họ. Rất khó cho Google nhưng có lẽ với những ai mới bước vào thế giới lập trình thì các mô hình đơn giản và cấu trúc rõ ràng của Dart và Go có thể khiến đám đông khó lòng ngoảnh mặt. Chef hay Puppet Từ lâu, một doanh nghiệp chạy vài máy chủ thì việc cài đặt phần mềm chẳng có gì khó. Sau đó, đám mây bùng nổ và một trang web "đúng nghĩa" đều chạy trên một cụm máy chủ. Điều này có nghĩa là nếu cài một phần mềm trên N máy thì cần cài N lần, là chuyện thực sự rắc rối. Chef và Puppet là hai công cụ hiện đang rất nổi, giúp các nhà quản trị có thể chạy một lần để cấu hình các máy chủ đám mây. Các chuyên gia DevOps cho rằng Chef là công cụ số một để quản lý cấu hình vì nó có tính linh động, cho bạn viết các lệnh tạo máy chủ bằng ngôn ngữ Ruby. Puppet cũng cấu hình cụm máy chủ nhưng sử dụng lệnh bằng ngôn ngữ giống như JSON, chỉ tốt khi làm một thứ mà thôi. Trong khi đó, các phiên bản Puppet mới cho phép dùng một ít Ruby. Liệu có tốt hơn không khi tạo một tác vụ bằng ngôn ngữ "bí hiểm" hơn hay sử dụng một ngôn ngữ nhiều người biết đến? Hudson hay Jenkins Ý tưởng tích hợp liên tục (continuous integration) là một cách thử nghiệm và triển khai tự động mã nguồn commit lên repo. Khi đã chạy được, người ta lại vấp phải mấy thứ phát sinh của nó. Xét về một phía là Hudson, nhánh (branch) chính thức của Eclipse Foundation và được nhiều người ở Oracle dùng, thừa hưởng mã nguồn từ Sun. Họ làm việc cật lực để tạo ra một công cụ ổn định, đúng nghĩa cho doanh nghiệp. Phía còn lại là Jenkins, là nhà của nhiều tin tặc thích thử nghiệm. Nhánh Jenkins dường như nhanh hơn với nhiều phiên bản mới xuất hiện hàng tuần. Cuộc chiến giữa Hudson và Jenkins như đại diện tiêu biểu cho một trận chiến rộng lớn hơn trong thế giới các nhà phát triển, giữa một bên ủng hộ mã nguồn ổn định, thử nghiệm cẩn thận và một bên là các tính năng mới liên tục xuất hiện, sửa lỗi nhanh chóng và được nhiều nhà phát triển tham gia. MySQL hay MariaDB Nói về những chiến tuyến xoay quanh các dự án do Oracle hỗ trợ, không thể không nhắc đến MariaDB "ly khai" và MySQL. Khi Oracle mua lại MySQL, những người ủng hộ nguồn mở sợ rằng công ty sẽ đưa ra một công cụ mạnh mẽ, có bản quyền. Nhưng nỗi lo của họ cuối cùng cũng khuây khoả. Và thương vụ ấy cũng không khiến ông Monty Widenius, một trong những nhà sáng lập MySQL, dựa trên mã nguồn cũ để tạo ra một thứ mới. MariaDB có cú pháp và tính năng hầu như giống với MySQL nhưng đến nay nó lại có vài tính năng mới và engine lưu trữ mới chạy nhanh hơn một chút, ít nhất là đối với những ai ủng hộ MariaDB. Liệu thị trường có chọn một kẻ mới hay đi theo một nền tảng thống trị lớn hàng nhiều năm nay? Liệu thế giới sẽ chọn một nền cơ sở dữ liệu nhỏ, đầy tính sáng tạo hay một doanh nghiệp tầm cỡ hướng đến tính ổn định? Biên dịch hay kịch bản Phân biệt giữa mã biên dịch và mã kịch bản không giống như các trình biên dịch và các trình tối ưu, nhưng nó còn là vấn đề của các nhà phát triển. Liệu họ có muốn mã nguồn của mình được chạy, được tối ưu và được chuyển dịch sang mã máy đơn giản? Hoặc liệu họ muốn tiếp cận theo cách trực tiếp hơn, là máy tính can thiệp mã nguồn ngay tại thời điểm chạy nó, đôi khi cho phép mã nguồn tự chỉnh? Ở một phía, các ngôn ngữ truyền thống như C và Java nằm trong các bộ công cụ phát triển. Còn phía kia, các ngôn ngữ kịch bản đơn giản hơn như Python, Ruby và JavaScript có thể tạo ngay trong trình biên tập văn bản đơn giản và có thể chạy trực tiếp qua trình biên dịch nhỏ. Phức tạp hơn, có những giải pháp "lai" như Groovy, là ngôn ngữ giống dạng kịch bản, chạy trong máy ảo Java, chính nó là một cộng cụ có nhiều khả năng tối ưu qua trình thực thi. Có lẽ sự phân biệt này dần dần nhạt đi nhưng điều đó không khiến nhiều người tranh luận rằng liệu một công cụ biên dịch nghiêm túc có đáng nữa hay không. Nguồn PC World VN
