Bài viết được dịch từ tạp chí InfoWorld

Trong cuộc phỏng vấn này, người phát minh ra ngôn ngữ lập trình Python là Guido van Rossum cũng nhấn mạnh về sự cần thiết của việc phát triển một nhánh Python mới và triển vọng của ngôn ngữ này.

Tác giả ngôn ngữ lập trình Python phản ứng ra sao trước những lời chỉ trích về tốc độ  của ngôn ngữ này?
Tác giả ngôn ngữ lập trình Python phản ứng ra sao trước những lời chỉ trích về tốc độ
của ngôn ngữ này?

Guido van Rossum đã tạo ra ngôn ngữ Python, đó là một trong những ngôn ngữ dynamic phổ biến nhất hiện nay, được sử dụng bởi các tổ chức lớn như Google và NASA. Chủ nhật vừa rồi, van Rossum, một kỹ sư phần mềm hiện là nhân viên của Google, đã tham gia trình bày tại hội nghị PyCon ở Thung lũng Silicon, sau đó đã có một cuộc trao đổi với biên tập viên của tạp chí InfoWorld, để có một cái nhìn sâu sắc về Python và đáp trả lại những lời chỉ trích gần đây.

InfoWorld: Ông đã trả lời ra sao khi những người chỉ trích nói rằng Python quá chậm. Ông nói rằng mỗi lần ông cố gắng viết một cái gì đó bằng Python, thì nó đều đủ nhanh. Tại sao lại có những chỉ trích rằng nó quá chậm?

Van Rossum: Tất nhiên những gì người ta làm là họ chọn lấy một công cụ và họ xây dựng một cái gì đó thật khó tin, họ đang làm những thứ thật điên rồ, và một số trong những thứ điên rồ đó liên quan đến công việc tính toán rất lớn, thu thập dữ liệu thông qua một mạng lưới của hàng tỷ mối quan hệ trên mạng xã hội hoặc phân tích hàng nghìn tỷ bức email hoặc bất cứ điều gì giống vậy.

Nếu bạn chỉ sử dụng một dạng vòng lặp Python đơn giản, tại một số điểm bạn sẽ thấy rằng đó là nút thắt cổ chai trong hệ thống của mình. Sẽ hiệu quả hơn nhiều khi thay thế một số phần bằng một function hoặc module viết bằng C hoặc C++ hơn là viết lại toàn bộ hệ thống của bạn trong một ngôn ngữ nhanh hơn, bởi vì đối với hầu hết những gì mà bạn đang làm, thì tốc độ của ngôn ngữ không liên quan gì cả.

InfoWorld: Phiên bản hiện tại của ngôn ngữ Python hiện nay ra sao, thưa ông?

Van Rossum: Có 2 phiên bản khác nhau vào thời điểm hiện tại. Có 2 nhánh của ngôn ngữ này và chúng tôi đang cố gắng để hợp nhất lại một bản cuối cùng. Chúng tôi đang cố gắng bỏ đi nhánh Python 2, vì vậy phiên bản cuối cùng trong nhánh Python 2 là Python 2.7. Nhưng bạn sẽ vẫn nhìn thấy rất nhiều bản Python 2.6 và 2.5. Với nhánh Python 3, phiên bản hiện tại là 3.2, và chúng tôi chỉ mới phát hành một phiên bản alpha của 3.3, trong một vài tháng tới thì phiên bản 3.3 hoàn chỉnh sẽ ra mắt.

InfoWorld: Đâu là điểm hấp dẫn nhất của nhánh Python 3?

Van Rossum: Python 2 đã tích lũy được nhiều cách để làm điều tương tự. Ngoài ra, Python 2 đã giới thiệu một cách để làm việc với Unicode; khi chúng tôi giới thiệu nó vào năm 2000, chúng tôi đã rất tự hào về sự hỗ trợ Unicode của mình và cách thức mà nó tương thích ngược. Đến thời điểm 2006-2007, chúng tôi nhận ra rằng mình cần một cách tiếp cận hoàn toàn khác tới Unicode, và chúng tôi không thể tìm ra một cách để làm một tiếp cận đúng đắn mới tới Unicode mà tương thích với phiên bản cũ của ngôn ngữ này.

Đó chính là điều mà chúng tôi nghĩ rằng thay vì phát hành ra phiên bản bị ràng buộc bởi những yêu cầu tương thích khá nghiêm ngặt, thì chúng tôi sẽ cho ra một phiên bản mới Python 3. Chúng tôi sẽ phải dọn dẹp nhiều thứ và sẽ bỏ đi các đặc trưng không được tán thành. Người dùng sẽ biết Python 3 không tương thích với Python 2, nhưng họ vẫn cảm thấy chúng là cùng một ngôn ngữ.

InfoWorld: Nếu nó không tương thích, thì ông có phải biên dịch lại các ứng dụng Python 2 của mình không?

Van Rossum: Bạn phải thay đổi mã nguồn các ứng dụng Python 2 của mình trong hầu hết các trường hợp. Chúng tôi đã cung cấp một công cụ có tên là 2to3 làm hầu hết những thay đổi mã nguồn của bạn một cách tự động. Nhưng có một số thứ mà bạn không thể làm tự động được, vì vậy bạn phải tự sửa lại chúng. Từ lúc này, người ta cũng phải đưa ra các chiến lược để viết ứng dụng trong một phiên bản Python 2 có giới hạn, bằng cách không sử dụng những đặc trưng nhất định nào đó, và điều kỳ diệu là mã nguồn của chúng sẽ tương thích với Python 3.

InfoWorld: Ông đã nói về những tranh luận về việc ủng hộ và chống lại kiểu động (dynamic typing). Ông nói rằng nếu bạn tin vào trình biên dịch có thể tìm thấy tất cả các bug trong chương trình của mình, thì bạn sẽ không thể làm công việc phát triển phần mềm lâu dài được. Nhưng tại sao ông lại cảm thấy hài lòng với việc Python trở nên dynamic?

Van Rossum: Tuyệt đối không. Triết lý cơ bản của ngôn ngữ này sẽ không thay đổi. Tôi không thấy Python đột nhiên phát triển nhánh riêng hoặc các đặc trưng nhỏ nào theo hướng đó cả.

InfoWorld: Ông có đề cập về một số điểm mà ông mong chờ một cuộc phân tích toàn cầu của các chương trình Python sẽ thành hiện thực. Các lập trình viên Python sẽ thu được lợi ích gì qua việc đó?

Van Rossum: Những gì bạn có thể làm với một cuộc phân tích toàn cầu đó là bạn có thể tìm thấy một số loại bug nào đó. Một điều khác bạn có thể làm đó là tối ưu hóa.

InfoWorld: Liệu GIL (Global Interpreter Lock) của Python có là một trở ngại để làm lập trình đa nhân (multicore)?

Van Rossum: Thực ra vấn đề này có nhiều điều phải nói thêm. Nếu bạn có nhiều core, bạn không thể có mỗi core thực thi các mã bytecode Python song song với những core khác được, bởi vì mã bytecode của Python chạy với GIL, và chỉ một trong số các core đó có thể có GIL. Điều mà các thread Python có thể làm khi chúng không nắm giữ GIL chỉ là chờ đợi cho việc nhập/xuất I/O, hoặc chúng có thể gọi code đã được viết bằng C hoặc C++.

Ví dụ, trong framework NumPy, chuyên thực thi tính toán trên các ma trận lớn, khi bạn đưa một ma trận vào NumPy hoặc một mảng lớn và bạn yêu cầu nó tính toán trên 10 triệu điểm, nó sẽ giải phóng GIL mà có thể đã được thực thi trên một core. Tôi không biết liệu NumPy có thiết kế tính toán song song hay không, nhưng thậm chí bạn có thể tưởng tượng rằng nếu bạn có 10 core, bạn có thể chia nhỏ công việc tới 10 core, và chúng có thể chạy song song trên các mẩu dữ liệu khác nhau, và không cái nào trong số chúng cần GIL bởi vì chúng không thao tác với các đối tượng Python.