Trong cuộc thi Google Code Jam (2013) hiện tại , đã xảy ra sự cố khiến người dùng C ++ và Java có hơn 200 dòng mã so với người Python đã giải quyết vấn đề tương tự chỉ bằng 40 dòng mã.

Python không thể so sánh trực tiếp với C ++ và Java nhưng sự khác biệt về tính dài dòng mà tôi nghĩ có lẽ có ảnh hưởng đến hiệu quả của thuật toán.

Làm thế nào quan trọng là biết thuật toán đúng so với sự lựa chọn của ngôn ngữ? Một chương trình Python được triển khai xuất sắc có thể được triển khai trong C ++ hoặc Java theo cách tốt hơn (sử dụng cùng một thuật toán) và điều này có liên quan gì đến tính dài dòng tự nhiên của các ngôn ngữ lập trình nhất định không?

Rõ ràng, nếu bạn xem xét câu hỏi này trong bối cảnh giống như Google Code Jam, thì tư duy thuật toán rõ ràng quan trọng hơn khi phải giải quyết các vấn đề thuật toán.

Tuy nhiên, trong cuộc sống hàng ngày, khoảng một triệu yếu tố khác cũng phải được xem xét, điều này làm cho câu hỏi trở nên ít đen hơn so với trắng.

Chỉ là một ví dụ ngược lại: Nếu bạn cần thêm 200 dòng trong Java, nhưng mọi người trong công ty của bạn đều biết Java, đây không phải là vấn đề lớn. Nếu bạn có thể viết nó bằng 5 dòng Python hoặc bất kỳ ngôn ngữ nào khác, nhưng bạn sẽ là người duy nhất trong công ty biết ngôn ngữ đó - đó là một vấn đề lớn. Trên thực tế, một thỏa thuận lớn như vậy, rằng bạn thậm chí sẽ không được phép làm như vậy và thay vào đó phải viết nó bằng Java.

Từ quan điểm của một người thợ, chúng tôi luôn cố gắng tiếp cận với công cụ phù hợp cho công việc, nhưng từ đúng trong đó rất khó để người ta có thể dễ dàng hiểu sai.

Ngược lại, tôi thấy tư duy thuật toán trong các công ty gần như vắng bóng. Chỉ một số người được chọn sở hữu nó, trong khi kẻ thù trung bình thường gặp khó khăn khi ước tính độ phức tạp thời gian chạy của các vòng lặp, tìm kiếm, v.v.

Tuy nhiên, về mặt các cuộc thi thuật toán, kinh nghiệm cá nhân của tôi từ việc cạnh tranh trong vài năm, rõ ràng cho tôi biết rằng bạn nên bám vào một ngôn ngữ. Tốc độ là một yếu tố chính và đơn giản là bạn không thể lãng phí thời gian cho các công cụ của mình, khi bạn nên dành nó để giải quyết các vấn đề trong thời gian giới hạn. Cũng xem xét rằng viết 200 dòng mã Java mà không cần suy nghĩ vẫn nhanh hơn nhiều so với việc tạo thủ công 50 dòng mã trăn phức tạp đòi hỏi nhiều suy nghĩ, nhưng cả hai đều giải quyết ít nhiều cùng một vấn đề.

Ồ và cuối cùng, hãy chắc chắn rằng bạn hiểu sự khác biệt chính giữa mã cạnh tranh thuật toán và mã sản xuất công ty. Tôi đã thấy các lập trình viên thuật toán tuyệt vời, đã viết mã khủng khiếp mà tôi sẽ không bao giờ chấp nhận trong một sản phẩm.

Tôi sẽ lập luận rằng, ngay cả các cuộc thi bên ngoài, tư duy thuật toán quan trọng hơn việc biết mọi thủ thuật cho một ngôn ngữ cụ thể.

Tất nhiên, bạn muốn biết ngôn ngữ bạn làm việc tốt nhất có thể, nhưng ngôn ngữ đến và đi, trong khi khả năng suy nghĩ trừu tượng về thuật toán là một kỹ năng có thể chuyển nhượng cao.

Trường hợp cụ thể: nếu tôi nhớ lại một cách chính xác, đã có một bài đăng ở đây trên Lập trình viên cách đây một thời gian, trong đó có người phàn nàn về việc thất bại FizzBuzz trong một cuộc phỏng vấn và đổ lỗi cho sự thiếu hiểu biết của ông về toán tử modulo của Java cho nó. Kết luận này là sai - việc thiếu kiến ​​thức về cách thức hoạt động của modulo khiến anh ta không thể nghĩ theo thuật toán về vấn đề và giải quyết nó, ngay cả khi không có toán tử modulo chuyên dụng. Đi xa hơn: Java có một lớp Tree - nếu trong tương lai, bạn phải làm việc với một ngôn ngữ không triển khai lớp này thì sao? Một lần nữa, khả năng suy nghĩ về vấn đề hơn hẳn các chi tiết ngôn ngữ cụ thể.

Tôi thừa nhận rằng các ví dụ rất đơn giản, nhưng chúng giúp mang lại điểm nhấn.

Vấn đề ngôn ngữ.

DARPA và Hải quân Hoa Kỳ đã thực hiện một thí nghiệm bắn súng gần 20 năm trước. Người chiến thắng trong cuộc đua ngựa đen là Haskell. Ada và C ++ đều được đại diện; Java thì không.

Cùng thời gian đó, Pratt & Whitney đã thực hiện một nghiên cứu khai thác dữ liệu về các dự án điều khiển động cơ phản lực, xem xét dữ liệu theo dõi thời gian và lỗi. Họ phát hiện ra rằng Ada đã tăng gấp đôi năng suất lập trình viên và 1/4 mật độ khiếm khuyết của bất kỳ ngôn ngữ nào khác mà họ đang sử dụng.

Atari đã từng sử dụng FORTH để phát triển các trò chơi điện tử và thực tế là họ đang sử dụng FORTH được coi là cực kỳ độc quyền.

Nhận xét của Paul Graham về việc sử dụng LISP là nổi tiếng. Nhận xét của Erann Gat về LISP tại JPL cũng không kém phần quan trọng, mặc dù không được nhiều người biết đến.

Phần mềm hàng không Boeing 777 có khá nhiều Ada. Kinh nghiệm của họ rất tốt, mặc dù một nhà thầu phụ lớn phải bắt đầu lại giữa dòng.

Vấn đề ngôn ngữ.

Một số điểm:

• Các vị trí hàng đầu có xu hướng là C ++ / C / Java, bất kể có bao nhiêu dòng mã khác biệt giữa ngôn ngữ đó và một số ngôn ngữ khác. Điều này có thể nói thêm rằng các lập trình viên hàng đầu có xu hướng chọn các ngôn ngữ này hơn một số ngôn ngữ khác, có thể là do tốc độ thô của chúng.
  Thật không may, bạn không thể dễ dàng nhìn thấy ngôn ngữ lập trình trên Google Code Jam, nhưng tôi đã tải xuống một vài ngôn ngữ hàng đầu và theo tôi nhớ, những thứ này chủ yếu là C / C ++. TopCoder (một trang web lưu trữ cuộc thi lập trình trực tuyến phổ biến) hầu hết đều có kết quả tương tự.

• Vì chúng ở mức khá thấp, tôi khá chắc chắn rằng bạn sẽ không dễ dàng đánh bại C / C ++ về thời gian chạy thô (và Java không đi quá xa phía sau). Từ kinh nghiệm của tôi, các ngôn ngữ gõ động có xu hướng chậm hơn đáng kể so với các ngôn ngữ gõ tĩnh. Giải pháp tối ưu có thể không đủ nhanh trong một số ngôn ngữ, nhưng đây không phải là một quy tắc chung.

• Các thuật toán đúng là rất quan trọng. Nếu bạn biết cách giải quyết tất cả các vấn đề (chi tiết cao) ngay từ đầu và bạn là một lập trình viên giỏi, nhanh, rất có thể bạn sẽ thắng, bất kể bạn viết mã bằng ngôn ngữ nào (giả sử giải pháp tối ưu trong ngôn ngữ đó là đủ nhanh).

• Số lượng đường thẳng không phải là một vấn đề lớn. Khi bạn có đủ kinh nghiệm lập trình, bạn sẽ biết rằng bạn có thể dành 10 phút để lập trình 10 dòng hoặc 200 dòng, tất cả phụ thuộc vào mức độ phức tạp của các dòng. Ngoài ra, nếu bạn đã mã hóa mã tương tự hàng trăm lần, bạn sẽ có thể thực hiện việc đó khá nhanh chóng. Không quá đề cập đến tất cả các macro mà các lập trình viên C / C ++ hàng đầu thường sử dụng để tối ưu hóa thời gian mã hóa của họ.

• Frank đưa ra một quan điểm tốt - (bên ngoài các cuộc thi lập trình) bạn không thể tiến hành viết mã bằng Python cho công ty của mình nếu toàn bộ cơ sở mã của họ bằng C hoặc bất cứ điều gì, bạn cần tuân thủ ngôn ngữ của họ.

• Thật dễ dàng để chuyển đổi giữa các ngôn ngữ, không dễ để xây dựng kiến ​​thức tư duy thuật toán nhiều năm. Tôi sẵn sàng đặt cược hầu hết mọi lập trình viên xuất sắc có thể chuyển sang ngôn ngữ khác (tương tự mơ hồ) trong một tuần. Có thể anh ấy / cô ấy sẽ không đủ giỏi để chiến thắng các cuộc thi lập trình bằng ngôn ngữ đó (hãy chờ thêm 2 tuần nữa), nhưng sẽ có những điều cơ bản.

Liệu logic tương tự có thể được thực hiện tốt hơn trong C ++? Tất nhiên nó có thể, nếu tốt hơn bạn có nghĩa là nhanh hơn và hiệu quả bộ nhớ hơn. Vấn đề là số lượng nỗ lực cần thiết để làm như vậy là cao hơn đáng kể. Hơn nữa, về mặt lý thuyết, bạn vẫn có thể xuống cấp thấp hơn và thực hiện nó ở C thuần hoặc thậm chí ASM, sẽ mất nhiều thời gian hơn, nhưng bạn thậm chí có thể có mã được tối ưu hóa hơn nữa.

Tất nhiên, trong trường hợp các cuộc thi như Code Jam hoặc TopCoder, đó không phải là một vấn đề lớn, vì nó chỉ là 40 dòng so với 200 dòng. Mặt khác, trong loại cạnh tranh này, điều quan trọng nhất là độ phức tạp thời gian / không gian của thuật toán. Trong khi ở ứng dụng thực tế, YMMV, trong các loại cuộc thi này, thuật toán O (n) được viết bằng ngôn ngữ chậm nhất sẽ luôn đánh bại O (n²) được viết bằng ngôn ngữ nhanh nhất. Đặc biệt là sẽ có nhiều bài kiểm tra là trường hợp xấu nhất.

Nhưng ngoài các cuộc thi, nếu chúng ta đang nói về các dự án lớn trong đời thực, thì nó không còn là 40 dòng so với 200 dòng nữa. Trong các dự án lớn, cơ sở mã lớn bắt đầu là một vấn đề. Tại thời điểm bạn nhận được:

C ++ vs Python?

Python thuần là chậm. Đó là lý do tại sao trình thông dịch Python chuẩn (CPython) được viết bằng C. Thực tế tất cả đều có các hàm dựng sẵn được viết là tối ưu hóa cao C. Python cũng có thể dễ dàng được sử dụng cùng với các thư viện C (thông qua ctypes hoặc như các mô đun cpython gốc ) và với các thư viện C ++ thông qua Boost :: Python . Bằng cách này, bạn có thể viết logic cấp cao của mình bằng Python, một ngôn ngữ linh hoạt, cho phép tạo mẫu và điều chỉnh nhanh chóng (có nghĩa là bạn có thể dành nhiều thời gian hơn để điều chỉnh và cải thiện thuật toán của mình). OTOH, bạn có thể viết các hàm thư viện cấp thấp hơn trong mô-đun C hoặc C ++. Ví dụ tuyệt vời về cách tiếp cận như vậy là SciPy, là thư viện Python, nhưng dưới vỏ bọc, nó sử dụng các thư viện số được tối ưu hóa cao như ATLAS, LAPACK, Intels MKL hoặc AMD's ACML.

Theo tôi, những gì mọi người thường coi là "ngôn ngữ lập trình" thực sự là ba điều riêng biệt:

1. Loại ngôn ngữ và cú pháp
2. Ngôn ngữ IDE
3. Thư viện có sẵn cho một ngôn ngữ

Chẳng hạn, khi ai đó đưa ra C # trong một cuộc thảo luận, bạn có thể nghĩ rằng anh ấy / cô ấy đang nói về cú pháp ngôn ngữ (1) nhưng chắc chắn 95% rằng cuộc thảo luận sẽ liên quan đến .Net framework (3). Nếu bạn không thiết kế một ngôn ngữ mới, thật khó và thường vô nghĩa khi cô lập (1) và bỏ qua (2) và (3). Đó là bởi vì IDE và thư viện chuẩn là "yếu tố thoải mái", những thứ ảnh hưởng trực tiếp đến trải nghiệm sử dụng một công cụ nhất định.

Vài năm qua tôi cũng đã tham gia Google Code Jam. Lần đầu tiên tôi chọn C ++ vì nó có hỗ trợ tốt để đọc đầu vào. Ví dụ: đọc ba số nguyên từ một đầu vào tiêu chuẩn trong C ++ trông như thế này:

int n, h, w;
cin >> n >> h >> w;

Trong khi ở C # giống như thế này:

int n, h, w;
string[] tokens = Console.ReadLine().Split(' ');
n = int.Parse(tokens[0]);
h = int.Parse(tokens[1]);
w = int.Parse(tokens[2]);

Đó là chi phí tinh thần nhiều hơn cho một chức năng đơn giản. Mọi thứ thậm chí còn phức tạp hơn trong C # với đầu vào đa dòng. Có lẽ tôi chỉ đơn giản là không tìm ra cách nào tốt hơn khi đó. Dù sao, tôi đã không vượt qua được vòng đầu tiên vì tôi có một lỗi mà tôi không thể sửa trước khi kết thúc vòng thi. Trớ trêu thay phương pháp đọc đầu vào làm xáo trộn lỗi. Vấn đề rất đơn giản, đầu vào chứa một số quá lớn đối với số nguyên 32 bit. Trong C #int.Parse(string) sẽ đưa ra một ngoại lệ nhưng trong C ++, luồng đầu vào tệp sẽ đặt một cờ lỗi nhất định và âm thầm làm cho nhà phát triển không nghi ngờ không biết về một vấn đề.

Cả hai ví dụ cho thấy cách thư viện được sử dụng thay vì cú pháp ngôn ngữ. Đầu tiên chứng minh tính dài dòng và cái còn lại thể hiện độ tin cậy. Nhiều thư viện được chuyển sang nhiều ngôn ngữ và một số ngôn ngữ có thể sử dụng các thư viện không được xây dựng riêng cho chúng (xem câu trả lời của @ vartec về Python với các thư viện C).

Để kết thúc việc này, biết đúng thuật toán sẽ giúp. Trong các cuộc thi mã hóa, điều đó rất quan trọng, đặc biệt là khi các tài nguyên như thời gian thực hiện và bộ nhớ bị hạn chế. Trong phát triển ứng dụng, nó được hoan nghênh nhưng nhìn chung không quan trọng. Bảo trì là quan trọng hơn đó. Có thể đạt được bằng cách áp dụng các mẫu thiết kế chính xác, có kiến ​​trúc tốt, mã dễ đọc và tài liệu liên quan và tất cả các phương pháp đó phụ thuộc rất nhiều vào các thư viện bên trong và bên thứ 3. Vì vậy, tôi thấy điều quan trọng hơn là phải biết loại bánh xe nào đã được phát minh và làm thế nào để chúng phù hợp sau đó làm thế nào để làm cho riêng tôi.

Nếu bạn muốn cạnh tranh trong các cuộc thi lập trình theo thời gian, bạn nên học ngôn ngữ biểu cảm nhất được phép trong cuộc thi. Perl có lẽ sẽ là tốt nhất, theo sau là Ruby hoặc Python. Bạn vẫn sẽ cần cơ sở tốt với các thuật toán, nhưng ít nhất bạn sẽ không bị sa lầy khi viết một cái gì đó như

Integer prev = b.get(k)
if (prev == null) prev = 0
Integer v = a.get(k);
if (v == null) v = 0;
b.put(prev + v);

thay vì

b[k] += a[k]

Đừng lo lắng về việc học một số thư viện. Tất cả đều rất giống nhau và tài liệu trực tuyến. Trở nên thông thạo các ngôn ngữ biểu cảm hơn sẽ giúp bạn trở thành một lập trình viên tốt hơn (nhưng có thể nản lòng) trong các ngôn ngữ ít biểu cảm hơn. Điều ngược lại là không đúng sự thật.

Lưu ý

Sự khác biệt giữa 200 dòng mã và 40 dòng mã là rất lớn và thậm chí còn lớn hơn khi đó là sự khác biệt giữa chương trình 200.000 dòng và chương trình 40.000 dòng. Sau đó, đó là sự khác biệt giữa một nhóm năm cộng với một người quản lý và một nhóm một hoặc hai.

Bất kỳ thuật toán có thể được thực hiện trong bất kỳ ngôn ngữ lập trình. Rốt cuộc, nó không phải là cú pháp quan trọng. Nhưng sử dụng một ngôn ngữ cấp cao như Python có lợi thế riêng của nó. Công việc ít hơn và số lượng mã hóa ít hơn. Vì vậy, để triển khai một thuật toán trong Python, bạn sẽ cần ít dòng hơn những gì được yêu cầu trong một ngôn ngữ cấp thấp như C.

Python có hầu hết các cấu trúc dữ liệu được xây dựng trong thư viện của nó. Nhưng trong C, chúng ta cần bắt đầu từ đầu và sử dụng một cấu trúc để xây dựng tất cả. Chắc chắn có sự khác biệt giữa ngôn ngữ cấp cao và cấp thấp, nhưng ngôn ngữ không nên ngăn bạn thực hiện bất kỳ thuật toán nào.

Trong khi ngoại suy ví dụ "40 LoC so với 200 LoC", nói rằng "tốt, chỉ 1/5 tổng số LoC rõ ràng là viết nhanh hơn nên nó phải tốt hơn" có vẻ hấp dẫn, tôi thực sự nghĩ rằng có rất ít sự thật được tìm thấy ở đó.

Tối ưu hóa cho LoC ít nhất gần như không bao giờ là một ý tưởng tốt trong quan điểm của tôi. Có, mỗi LoC được viết là một tiềm năng cho các lỗi và bạn không bao giờ phải gỡ lỗi những gì bạn chưa bao giờ viết vvetc. Vấn đề là, tối ưu hóa cho khả năng đọc và tách rời. Sẽ không có vấn đề gì nếu bạn giải quyết vấn đề bằng cách sử dụng regex lớn 20 dòng, trái ngược với việc viết mô-đun 1k LoC. Regex sẽ là một bức tường mờ đục, cực kỳ dễ bị lỗi, khó hiểu, ác mộng để thay đổi mà không thay đổi hành vi của nó theo những cách không được bảo vệ, v.v.

Loại bỏ nồi hơi và độ dài mà không thêm bất kỳ giá trị nào là tốt và tốt, nhưng mặt khác, sử dụng một cái gì đó như Java hoặc C #, có kiến ​​thức về các mẫu thiết kế và công cụ như chia sẻ lại cho phép bạn linh hoạt trong việc tái cấu trúc mã , làm sạch nó theo thời gian, phá vỡ mọi thứ, v.v., điều đó đơn giản sẽ khó khăn hơn nếu bạn viết nó như một kịch bản python nhỏ hơn hoặc ứng dụng ruby.

Một so sánh rất hay: Tôi thà có 100 nghìn LoC mã C # tách rời được kiểm tra, chứa đầy những thứ "quá mức" như mô hình chiến lược, các nhà máy, v.v., chứ không phải là một ứng dụng python 20k chỉ "hoàn thành công việc". Thêm 5 lần mã hay không, kiến ​​trúc chiến thắng mỗi ngày.

Tôi hoàn toàn đồng ý một số loại công việc dễ dàng và thuận tiện hơn trong một số ngôn ngữ, nhưng tôi tin tưởng hơn vào việc lựa chọn ngôn ngữ của bạn dựa trên những công cụ bạn cần và yêu cầu là gì (và có thể trong tương lai gần).