Lưu ý: bài đăng sau đây có thể bao gồm các ý kiến gây tranh cãi, vì vậy xin lưu ý rằng chúng chỉ là ý kiến của tôi và không có ý định xúc phạm bất cứ ai.
Tôi đang lập trình dưới hình thức này hay hình thức khác từ khoảng năm 1999. Ban đầu tôi sử dụng R, và sau đó, khoảng năm 2004, chủ yếu chuyển sang Python.
Đối với nhiều ứng dụng khoa học, ví dụ, mô phỏng, bao gồm cả những thứ như MCMC, cả R và Python đều quá chậm và cần phải được tăng tốc. Cách thông thường để làm như vậy là mở rộng với C hoặc C ++. Đối với cả R và Python, đây là những gì tôi đã làm, sử dụng API C của R với C ++ và thư viện Boost Python với Python.
Tuy nhiên, vì nhiều lý do, sự kết hợp này không phải là giải pháp lý tưởng. Điều gì là quan trọng trong lập trình, đặc biệt là các thuật toán? Biểu cảm và tốc độ, tất nhiên có liên quan. Một ngôn ngữ càng biểu cảm, người ta có thể viết nhanh hơn trong đó.
1) Theo như biểu cảm, cả R và Python đều không thực sự lý tưởng để viết các thuật toán khoa học theo ý kiến của tôi. Họ không ánh xạ chặt chẽ với các thuật toán cơ bản. Tuy nhiên, cả hai đều tốt hơn đáng kể so với C ++.
2) Tôi thích viết bằng Python, một ngôn ngữ dễ chịu, mặc dù như đã lưu ý ở trên, nó không lý tưởng cho công việc thuật toán. Tuy nhiên, khi người ta phải làm việc với tổ hợp Python / C ++ vì vấn đề tốc độ, bản phối này trở nên kém dễ chịu hơn khi làm việc. Điều thường xảy ra là lần đầu tiên tôi viết bằng Python và một khi tôi có thứ gì đó hoạt động tốt, thường phát hiện ra rằng nó quá chậm (đối với một số giá trị chủ quan của quá chậm). Sau đó, tôi phải đối mặt với quyết định có nên dành một lượng thời gian không hợp lý để viết lại nó trong C ++ hay đưa ra sự chậm chạp. Nhìn nhận lại, tôi thường cảm thấy mình có thể tốt hơn khi vượt qua sự chậm chạp, đặc biệt là khi tốc độ thu được là không thể đoán trước. Ngoài ra, giao diện Boost Python giữa hai người là một vấn đề đau đầu về bảo trì đáng kể, và có mã bằng hai ngôn ngữ rất khác nhau được dán vào nhau như thế này chỉ gây mất tập trung. Không có chỉ trích về Boost Python có ý định, nó là một giao diện mạnh mẽ như người ta có thể tưởng tượng, và hầu như chỉ hoạt động hầu hết thời gian.
Bây giờ, trong một thế giới lý tưởng, với thời gian và nguồn lực không giới hạn, cả hai vấn đề này sẽ không phải là vấn đề lớn. Tuy nhiên, trong các dự án khoa học tôi đã thực hiện, tôi đã có kinh nghiệm sau đây.
Cho dù tôi có cộng tác viên trong dự án hay không, tôi dường như luôn kết thúc việc thực hiện phần lớn máy tính. Trong tổng số 5 dự án quan trọng, tôi chỉ có sự tham gia đáng kể của một người trong một dự án. Đó là một người đã làm nhiều hơn là kéo trọng lượng của mình; anh ấy đã làm nhiều như tôi hoặc nhiều hơn nữa. Tuy nhiên, trong tất cả các trường hợp khác, bao gồm các dự án có nhiều cộng tác viên, tôi đã thực hiện (hầu như) tất cả các công việc tính toán. Mặc dù tôi có thể nói rằng tôi chưa được ban phước với những cộng tác viên giỏi nhất (dường như đó là sự pha trộn giữa sự lười biếng và bất tài) nhưng tôi không rõ liệu tình trạng này có thể thay đổi trong tương lai hay không.
Công việc khoa học tính toán là một nỗ lực to lớn và nếu tôi không thể thay đổi cách cộng tác viên của mình cư xử, tôi có thể thay đổi cách làm việc. Cải tiến quan trọng nhất sẽ là hoàn thành công việc nhanh hơn. Điều này đưa tôi đến sự cân nhắc chính ở đây, đó là việc chuyển đổi ngôn ngữ sang một thứ gì đó ít chính thống hơn có thể giúp ích. Dựa trên nghiên cứu trước đây, các ứng cử viên có khả năng theo thứ tự khả năng nhất là Lisp và Ocaml chung. Tôi đã suy nghĩ về điều này trong nhiều năm, nhưng gần đây đã suy nghĩ về nó nghiêm túc hơn.
Theo tôi có thể nói, rất ít người sử dụng CL hoặc Ocaml cho tính toán khoa học. Khi tìm kiếm trang web này, tôi tìm thấy hai tài liệu tham khảo về CL (một là của tôi) và một cho Ocaml (của tôi). Tôi đã có một vài liên hệ đáng khích lệ trong những năm qua với những người thích phiêu lưu làm việc ở rìa. Vào năm 2008, tôi đã xem qua một cuốn sách đánh giá về "Lisp thực tế chung" của Peter Seibel (mà tôi sở hữu), bởi Tamas K. Papp. Điều này thu hút sự chú ý của tôi, vì đó là một trong số ít đề cập đến tính toán khoa học cho Lisp mà tôi đã bắt gặp trên mạng. Tôi đã viết thư cho Tamas, người ngay lập tức trả lời một cách hữu ích và khích lệ. Để báo cho anh ấy
Năng suất lập trình của tôi có thể tăng gấp 10 lần với Lisp, nhưng điều đó mất khoảng một năm để xảy ra và tôi vẫn đang học (mặc dù tôi đã làm khá tốt sau 2 tháng). Vì vậy, nếu bạn đang làm việc trên một cái gì đó quan trọng về thời gian, thì hãy hoãn việc chuyển đổi.
Bạn nên xem xét việc hỏi mọi người về cll, tôi không phải là người duy nhất biết về những điều này, những người khác làm máy tính khoa học trên Lisp.
Ông cũng có một blog và một trang GitHub .
Một người khác mà tôi đã trao đổi ngắn gọn với (vào tháng 12 năm 2006) là Ira Kalet , người đã sử dụng Common Lisp trong bối cảnh ung thư bức xạ.
Có lẽ có những người khác làm máy tính khoa học trên Lisp, nhưng tôi không biết ai cả.
Vấn đề phổ biến nhất mà mọi người trích dẫn với CL là thiếu thư viện. Đây là một vấn đề nghiêm trọng trong điện toán cho mục đích chung, nhưng có thể không quá nhiều trong điện toán khoa học, đặc biệt là từ việc triển khai các thuật toán. Cụ thể, tôi có thể nhận được hầu hết thời gian với một thư viện toán học cơ bản, bao gồm các hàm phân phối xác suất, thư viện mảng đa chiều và một bộ container cơ bản, ví dụ như map, set, list, v.v. như được tìm thấy trong các thư viện chuẩn C ++ và Python.
Tôi thậm chí còn biết ít về Ocaml hơn tôi về CL, nhưng đã ném nó vào như một cách thay thế. Nó được cho là rất nhanh, có một triển khai miễn phí bởi các nhà nghiên cứu Pháp, và có vẻ như là ngôn ngữ khả thi nhất trong họ ngôn ngữ ML cho máy tính khoa học.
Để kết luận, tôi tự hỏi nếu những người khác có kinh nghiệm với điều này, và họ có suy nghĩ gì, nếu có.
EDIT: Tôi chủ yếu quan tâm đến trải nghiệm đầu tay, trong bối cảnh các vấn đề tôi đã thảo luận ở trên. Ví dụ: nếu bạn đã từng sử dụng Python và C ++ (hoặc R và C ++) và chuyển sang một ngôn ngữ khó hiểu hơn, tôi rất muốn nghe về trải nghiệm của bạn.