Tại sao OCaml không phổ biến hơn?

Tôi luôn nghe nói rằng C là các ngôn ngữ của sự lựa chọn để sử dụng cho các hệ thống nhúng, hoặc bất cứ điều gì mà cần phải chạy ở tốc độ tối đa. Tôi chưa bao giờ yêu thích C, chủ yếu là vì tôi không thích số học con trỏ và ngôn ngữ chỉ là một bước tiến trên trình biên dịch.

Mặt khác, các ngôn ngữ ML là chức năng, ngôn ngữ được thu gom rác và OCaml thậm chí còn có một mô hình đối tượng, nhưng chúng có tiếng là nhanh như ngôn ngữ C. ML có sự trừu tượng mà bất cứ ai cũng có thể yêu cầu để viết cấp độ cao, súc tích mã, nhưng nó vẫn giữ tốc độ cần thiết để viết các ứng dụng hiệu suất cao.

OCaml đặc biệt có thể được sử dụng ở bất cứ nơi nào mà C được sử dụng theo truyền thống, chẳng hạn như cho các thiết bị nhúng, trình điều khiển đồ họa, hệ điều hành, v.v ... Bằng tất cả các quyền, OCaml nên đã chiếm lĩnh thế giới, nhưng hầu như không ai nghe thấy ngôn ngữ này sử dung nó.

Đây là một câu hỏi chủ quan, nhưng tại sao các ngôn ngữ khác của OCaml và ML vẫn còn quá mù mờ, trong khi C và các ngôn ngữ khác trở nên phổ biến?

Câu trả lời đầu tiên là không ai thực sự biết tại sao ngôn ngữ trở nên phổ biến và bất kỳ ai nói khác là bị lừa dối hoặc có một chương trình nghị sự. (Thường dễ xác định lý do tại sao một ngôn ngữ không trở nên phổ biến, nhưng đó là một câu hỏi khác.)

Với tuyên bố từ chối trách nhiệm đó, đây là một số điểm mang tính gợi ý, quan trọng nhất trước tiên:

• Trình biên dịch C trưởng thành đầu tiên xuất hiện vào năm 1974; trình biên dịch OCaml trưởng thành đầu tiên xuất hiện vào cuối những năm 1990. C có một khởi đầu 25 năm.

• C được vận chuyển với Unix, là "ứng dụng sát thủ" lớn nhất mọi thời đại. Trong một thời gian dài, mọi bộ phận CS trên thế giới đều phải có Unix, điều đó có nghĩa là mọi người hướng dẫn và mọi người tham gia khóa học CS đều có cơ hội được tiếp xúc với C. OCaml và ML vẫn đang chờ đợi ứng dụng sát thủ đầu tiên của họ. (MLdonkey rất tuyệt, nhưng nó không phải là Unix.)

• C lấp đầy chỗ đứng của nó tốt đến mức tôi nghi ngờ sẽ không bao giờ có một ngôn ngữ cấp thấp khác chỉ dành cho lập trình hệ thống. (Để xem bằng chứng có lợi, hãy đọc bài viết của Dennis Ritchie về lịch sử của C từ HOPL II.) Thậm chí còn không rõ thị trường ngách của OCaml là gì và thị trường ngách của Standard ML chỉ rõ ràng hơn một chút. Vì vậy, Caml và ML có khá nhiều đối thủ cạnh tranh, trong khi C đã giết chết đối thủ cạnh tranh duy nhất (BLISS).

• Một trong những thế mạnh lớn của C là mô hình chi phí của nó rất dễ đoán: dễ dàng xem xét bất kỳ đoạn mã C nhỏ nào có thể có ngay ý tưởng chính xác về những hoạt động của máy sẽ phải được thực hiện để thực thi mã đó. Mô hình chi phí của OCaml ít rõ ràng hơn, đặc biệt là vì phân bổ bộ nhớít rõ ràng hơn và tổng chi phí phân bổ bộ nhớ (bằng chi phí phân bổ cộng với chi phí phát sinh trong quá trình thu gom rác) phụ thuộc vào các thuộc tính mới nổi như thời gian các đối tượng sống và các đối tượng tham chiếu đến các đối tượng khác. Kết quả cuối cùng là hiệu suất rất khó dự đoán và thậm chí khó phân tích sau thực tế. (Các công cụ định hình bộ nhớ của OCaml không phải là những gì chúng cần phải có.) Kết quả là, OCaml không tốt cho các ứng dụng mà hiệu năng phải rất dễ đoán --- như các hệ thống nhúng.

• C là một ngôn ngữ với một trình biên dịch chuẩn và nhiều. OCaml là một tạo phẩm phần mềm: trình biên dịch duy nhất là từ một nguồn duy nhất và trình biên dịch là tiêu chuẩn. Và tiêu chuẩn đó thay đổi với mỗi bản phát hành. Đối với những người coi trọng sự ổn định và khả năng tương thích ngược, một ngôn ngữ nguồn đơn có thể gây ra rủi ro không thể chấp nhận được.

• Bất kỳ ai có khóa học trình biên dịch đại học nửa chừng và rất kiên trì đều có thể viết trình biên dịch C hoạt động ít nhiều và có hiệu suất đầy đủ. Để có được việc triển khai OCaml hoặc ML khỏi mặt đất đòi hỏi nhiều sự giáo dục hơn và để có được hiệu năng tương đương với trình biên dịch C ngây thơ đòi hỏi nhiều công việc hơn. Điều này có nghĩa là có rất ít người có sở thích để loay hoay với các ngôn ngữ như OCaml, vì vậy cộng đồng càng khó phát triển sự hiểu biết sâu sắc về cách khai thác nó.

Tôi nghĩ vấn đề với OCaml là nó không hữu dụng "ngoài luồng". Lý do cuối cùng tại sao mọi người sử dụng một ngôn ngữ là vì nó có thư viện họ cần. Mặc dù vậy, không có gì "ngoài lề", không ai có đủ khả năng tham gia vào một dự án để nhận ra rằng họ cần phải viết một thư viện. Kết quả là một ngôn ngữ không có thư viện, khiến cho việc viết "ứng dụng thực" trở nên khó khăn.

Tôi nghĩ đây là điều mà OCaml phải chịu - không ai bận tâm để bắt đầu "các dự án thực sự" trong đó bởi vì tất cả đều có ngôn ngữ lập trình. Yay, tôi có thể thêm hai và hai và in kết quả. Kết quả là một tập hợp các thư viện chủ yếu là các phần mềm bỏ học thuật (tác giả đã lấy bằng tiến sĩ và tiếp tục), điều này không quá hữu ích cho các lập trình viên thực hành.

(Tôi biết có công việc đang được tiến hành để thay đổi điều này, với các dự án như "Bao gồm pin". Hãy quay lại đây sau 5 năm và có lẽ OCaml sẽ phổ biến hơn.)

Có một số trường hợp ngoại lệ cho quy tắc này. Java bắt đầu không có thư viện, nhưng Sun trả tiền cho mọi người để viết tất cả trong nhà, và sau đó họ tiếp thị nó. Chứng nhận Java, phần cứng dành riêng cho Java, sách Java, các lớp Java, v.v.

Kết quả là sự nổi tiếng. Tiền có thể giải quyết rất nhiều vấn đề.

Trong lĩnh vực ngôn ngữ chức năng, chúng ta có thể thấy Haskell đang trở nên khá phổ biến. Tôi nghĩ rằng hầu hết sự phổ biến là do những người như dons viết thư viện hữu ích và không bao giờ ngừng tiếp thị ngôn ngữ. Mỗi ngày bạn nhìn thấy một vài bài viết của Haskell về Lập trình Reddit. Điều này khiến nó bị mắc kẹt trong tâm trí của mọi người cho đến khi cuối cùng họ quyết định, "Tôi sẽ thử Haskell." Khi họ làm, họ thấy những thứ hữu ích như khung web, cơ sở dữ liệu đối tượng, thư viện OpenGL và thư viện xử lý XML. Điều này có nghĩa là họ thực sự có thể làm một cái gì đó hữu ích "Ngay bây giờ". Vì vậy, giữa tiềm năng để có năng suất và nghe về nó rất nhiều, Haskell đã trở nên nổi tiếng.

CL có nhiều thư viện giống như Haskell và gần như nhanh, nhưng không ai nói về nó, vì vậy nó "cảm thấy chết". Quả thực #lisp yên tĩnh hơn nhiều so với #haskell, nhưng Lisp vẫn là một ngôn ngữ rất năng suất với rất nhiều thư viện. Không có ngôn ngữ khác có SLIME. Nhưng tiếp thị là rất quan trọng và Haskell làm điều đó tốt hơn Lisp hoặc OCaml (và cạnh tranh cho cùng một cơ sở người dùng).

Cuối cùng, một số người sẽ không bao giờ "có được" lập trình, do đó, phá vỡ mô hình tinh thần của họ (biến là các hộp có giá trị, mã thực thi từ trên xuống dưới) sẽ đảm bảo rằng họ không sử dụng ngôn ngữ của bạn. Kiểu lập trình viên này chiếm tỷ lệ lớn trong dân số lập trình, vì vậy điều này càng hạn chế cơ sở người dùng có thể có của các ngôn ngữ trừu tượng như Lisp, Haskell và OCaml.

Tôi thích OCaml rất nhiều như một ngôn ngữ. NHƯNG...

Các công cụ hỗ trợ chỉ là không có. Trình gỡ lỗi chỉ hoạt động tốt nhưng không hoạt động trên windows (tôi đã kiểm tra lần cuối) và không có nhiều công cụ phát triển có sẵn cho nó.

Hệ thống loại của nó, đôi khi, một chút quá mạnh. Đối với một người không hiểu cách thức hoạt động của suy luận kiểu hoặc hệ thống loại ML nói chung, việc anh ta không thể thêm một số nguyên vào một số float là một sự thay đổi lớn ngay lập tức.

Thư viện tiêu chuẩn đôi khi có thể có một cảm giác không nhất quán.

Mô hình đối tượng có vẻ hơi khó xử và thư viện tiêu chuẩn hầu như không sử dụng nó, thay vào đó chọn sử dụng cho các thư viện dựa trên mô-đun.

Có rất nhiều thứ khác về cơ bản khiến ngôn ngữ không cảm thấy "bóng bẩy" và khiến mọi người tránh xa trong giai đoạn rất quan trọng khi họ chọn ngôn ngữ và cố gắng quyết định xem họ có thích ngôn ngữ đó hay không.

Tôi nghĩ rằng di sản quan trọng nhất của nó sẽ là nó, cùng với các phương ngữ ML khác, đã có ảnh hưởng rất mạnh đến các ngôn ngữ chức năng khác. Hầu hết các ngôn ngữ chức năng thế hệ hiện tại đều lấy các yếu tố tốt nhất từ ​​phương ngữ ML và tinh chỉnh một số phiền toái.

Các hệ thống nhúng thường yêu cầu hai điều: tốc độ và tính quyết định. OCaml có thể cung cấp tốc độ, nhưng thực tế là nó có một công cụ thu gom rác khiến nó không có gì đặc biệt, và đối với một hệ thống thời gian thực mà đơn giản sẽ không làm được.

Đây là một chút so sánh táo với cam. OCaml là một ngôn ngữ khá trẻ [1] và chưa bao giờ có một nỗ lực nghiêm túc, bền vững nào để đẩy nó vào dòng chính (ngoại trừ công việc hiện tại của Microsoft với F #). Không giống như C, nó không phải là ngôn ngữ chung của hệ điều hành doanh nghiệp được hỗ trợ và bắt chước rộng rãi nhất (ví dụ, UNIX). Không giống như Java, nó đã không có một tập đoàn lớn đẩy nó như một nền tảng điện toán thế hệ tiếp theo. Không giống như Perl, Python và Ruby, nó không nắm giữ một vị trí cao, có tầm ảnh hưởng lớn (nghĩa là, lĩnh vực của nó là ngôn ngữ lập trình và nghiên cứu lý luận tự động, không quá cao so với phát triển web). Do đó, nó không phải là siêu phổ biến.

[1] Công bằng mà nói, ngôn ngữ ML gốc đã có từ những năm 70. Nhưng OCaml đã không xuất hiện cho đến năm 1996 và nó không kế thừa các thư viện ML chuẩn. Về mặt thực tế, đó là một ngôn ngữ trẻ hơn C, C ++, Java, Python, Haskell hoặc thậm chí là Ruby.

Cộng đồng OCaml đã thất bại trong việc phát triển một thư viện tiêu chuẩn lớn và đáng tin cậy (vượt xa những gì đi kèm với OCaml ngày nay) giúp cho việc phát triển ứng dụng trở nên dễ dàng. Có một số nỗ lực để giải quyết vấn đề nhưng chỉ cần xem Python hoặc Ruby để xem những gì còn thiếu. OCaml là một ngôn ngữ tuyệt vời nếu bạn muốn giải quyết một vấn đề thuật toán không phụ thuộc quá nhiều vào việc phải tương tác với các mô đun tiêu chuẩn nâng cao như XML, mạng, tính toán dữ liệu, v.v., mà bạn không muốn tự mình thực hiện.

Tôi tin rằng một phần của vấn đề là làm thế nào các mô-đun được ánh xạ tới các tệp bởi OCaml: về mặt khái niệm tất cả các tệp * .ml sống trong cùng một không gian tên và các thư mục không có ý nghĩa. Điều này làm cho một cộng đồng khó phát triển một thư viện. Nếu trình biên dịch sẽ ánh xạ phân cấp thư mục thành phân cấp mô-đun, tôi sẽ thấy một cơ hội tốt hơn rằng một thư viện tiêu chuẩn sẽ phát triển. Tuy nhiên, điều này sẽ đòi hỏi nỗ lực đáng kể của các nhà phát triển trình biên dịch lõi. (Tôi biết về các mô-đun đóng gói nhưng tôi nghĩ rằng đây là một loại bùn.)

Một vấn đề thư viện khác là khả năng tương thích nhị phân giữa các bản phát hành trình biên dịch. Khá an toàn để nói rằng tất cả mã thư viện phải được biên dịch lại sau khi nâng cấp trình biên dịch. Điều này gây khó khăn cho việc cung cấp các bản phát hành nhị phân của các mô-đun hoặc thư viện.

Có lẽ bởi vì có quá nhiều người được dạy ML như một phần giới thiệu về những thứ lý thuyết kỳ lạ và khó hiểu về các loại. Đó là những gì đã xảy ra với tôi.

Tôi đã được hiển thị ML và Smalltalk cùng một lúc. Smalltalk trông thật ngầu, và ngay lập tức có thể hiểu được OO là gì và làm thế nào bạn có thể tạo ra những thứ tương tác đẹp mắt trong môi trường này. ML là về những thứ toán học trừu tượng dường như không liên quan đến những gì tôi muốn làm. Và không giống như C, tôi không hứa sẽ cho tôi viết các trò chơi nhanh trên kính hiển vi 16 bit.

Điều này, tất nhiên, sâu sắc không công bằng và chủ quan. Nhưng đó có thể là câu chuyện có thật cho hầu hết mọi người.

Những ngày này tôi đoán câu hỏi sẽ là: bây giờ tôi cảm thấy mình cần biết thứ lý thuyết kỳ lạ và khó hiểu này về các loại, tại sao tôi lại chọn ML thay vì Haskell hoặc Erlang?

Tôi tin rằng vấn đề chính là thiếu một thư viện tiêu chuẩn thực tế. Do đó, dự án Pin OCaml được bao gồm , dự kiến ​​sẽ cải thiện phần lớn tình hình. Bạn nên tham gia giai đoạn Beta trong vòng một vài ngày, vì vậy bạn sẽ phải đặt lại câu hỏi sau một năm nữa.

Tôi đồng ý rằng hỗ trợ Windows kém, đường cong học tập dốc và thư viện tiêu chuẩn mỏng đã kìm hãm sự phát triển của OCaml trong quá khứ nhưng tôi sẽ nói thêm rằng đã thiếu rất nhiều thông tin hướng dẫn (ví dụ như sách) về OCaml so với các ngôn ngữ chính như Java.

Ngoài ra, những người biết ngôn ngữ như OCaml rất không đồng nhất. Trong số các lập trình viên web, có thể 1 trong 1.000 sẽ nghe nói về OCaml. Trong số những người làm máy tính khoa học tại Đại học Cambridge, khoảng 90% những người tôi biết là thông thạo OCaml. Thật vậy, tôi là một trong những người cuối cùng trong số bạn bè của tôi học OCaml. Chúng tôi thậm chí đã chạy OCaml trên siêu máy tính CPU 256 của chúng tôi ...

Tôi cũng nên đề cập rằng những vấn đề này đang nhanh chóng được giải quyết. OCaml đã phát minh lại chính nó cho lập trình web gần đây với các dự án như Ocsigen và đã có ít nhất hai câu chuyện thành công công nghiệp lớn trong bối cảnh đó. Có một cuốn sách mới về OCaml bây giờ. Cộng đồng đang hợp tác trên một thư viện tiêu chuẩn toàn diện có tên là "bao gồm pin" vừa được phát hành phiên bản beta và trông thật tuyệt vời. Một phiên bản thân thiện đa lõi của OCaml sắp được phát hành. Phiên bản mới nhất của OCaml cũng bao gồm nhiều tính năng mới tuyệt vời như mẫu lười biếng và thư viện OCaml mã nguồn được tải động.

Tôi nghĩ một phần của vấn đề là lập trình chức năng không phải là cách tự nhiên để hầu hết mọi người nghĩ (và tôi nói điều này như một người rất quan tâm và đánh giá cao về lập trình chức năng). Điều này được kết hợp bởi thực tế là phần lớn các lập trình viên ngày nay đã bắt đầu học lập trình thủ tục (hầu hết các ngôn ngữ OOP phổ biến vẫn là thủ tục) và vì vậy các ngôn ngữ chức năng khó điều chỉnh ban đầu.

Khi tôi bắt đầu học đại học, tôi đã biết một lượng BASIC, C ++ và Java hợp lý và một chút ngôn ngữ lắp ráp Pascal và x86. Tôi ở xa một chuyên gia nhưng đã đi đến kết luận (hơi ngây thơ) rằng tất cả các ngôn ngữ lập trình về cơ bản là giống nhau với cú pháp hơi khác nhau. Giới thiệu về khóa học lập trình của chúng tôi đã sử dụng ML, điều đó nhanh chóng làm tôi thất vọng về khái niệm đó. Tôi gặp khó khăn trong việc xoay quanh ML ở giai đoạn lập trình sự nghiệp và không thực sự thấy được lập trình chức năng. Tôi nghĩ rằng cần thêm một chút kinh nghiệm với một số vấn đề của lập trình thủ tục để thực sự đánh giá cao lợi ích của cách tiếp cận chức năng.

Giảng viên ML của chúng tôi thường tuyên bố rằng việc diễn đạt các vấn đề theo cách đệ quy là 'tự nhiên' và dễ dàng hơn so với việc sử dụng các vòng lặp hoặc các khái niệm thủ tục khác. Tôi chưa bao giờ bị thuyết phục bởi tuyên bố đó và vẫn không mua nó. Các hàm đệ quy đôi khi có thể cung cấp các giải pháp đặc biệt tao nhã và ngắn gọn cho các vấn đề nhưng tôi vẫn thấy đó là một cách không tự nhiên để suy nghĩ về các vấn đề. Có lẽ nếu bạn có một nền tảng toán học rất mạnh thì nó có vẻ trực quan hơn nhưng tôi không nghĩ rằng hầu hết mọi người sẽ dễ dàng suy nghĩ đệ quy. Do tính trung tâm của các hàm đệ quy cho mô hình lập trình chức năng, tôi nghĩ rằng đây cũng có thể là một lý do cho sự phổ biến ít hơn của các ngôn ngữ chức năng.

Ngoài ra còn có một hiệu ứng phản hồi để phổ biến ngôn ngữ. Khi tôi bắt đầu lập trình, tôi muốn biết cách lập trình các hiệu ứng đồ họa và trò chơi. Sau khi học một chút về BBC BASIC và sau đó là QBASIC, tôi đã tự nhiên tìm hiểu những ngôn ngữ phổ biến nhất được sử dụng trong bối cảnh demo và các lập trình viên trò chơi là gì và bắt đầu học về lắp ráp C ++ và x86. Ngày nay, một số lập trình viên mới có thể muốn biết cách tạo ra các ứng dụng web và do đó sẽ thu hút được việc học PHP, Ruby hoặc C #. Có rất ít lĩnh vực ứng dụng cho các lập trình viên mới bắt đầu tự thúc đẩy trong đó câu trả lời cho 'ngôn ngữ tốt nhất để học lập trình một cái gì đó như X' sẽ là 'Ocaml'.

Nhiều lý do thực tế được đưa ra cho sự phổ biến hạn chế của Ocaml (thiếu thư viện trưởng thành, trình gỡ lỗi, IDE, v.v.) được hỗ trợ bởi chính thức của Microsoft cho F # là ngôn ngữ .NET hạng nhất. Sẽ rất thú vị để xem liệu F # có giúp mang lại mức độ phổ biến cao hơn cho lập trình chức năng hay không.

Tôi tin rằng cốt lõi của vấn đề là chính trị. Các nhà phát triển Ocaml chủ yếu quan tâm đến nghiên cứu và không có tài nguyên để cung cấp và duy trì một thư viện phong phú. Tuy nhiên, họ cũng không sẵn sàng phát hành quyền kiểm soát sản phẩm cho cộng đồng có các tài nguyên này, kết quả là một số nỗ lực để giải quyết vấn đề này dựa trên sự hợp tác và tài trợ không tồn tại của các thư viện bên thứ ba và những nỗ lực này đã thất bại. Pin sẽ thất bại vì lý do tương tự, trừ khi các nhà phát triển Ocaml thay đổi thái độ.

Tôi sử dụng Ocaml để phát triển sản phẩm của mình và tôi có một quy tắc đơn giản: giảm thiểu sự phụ thuộc vào mã của bên thứ ba. Khi một mục của bên thứ ba hữu ích, nếu có thể, hãy kết hợp các mã nguồn trực tiếp trong gói. Ví dụ: Lược đồ OCS và Dypgen là các phần thiết yếu của trình phân tích cú pháp Felix, vì vậy chúng được sao chép vào các nguồn của chúng tôi để chúng tôi có quyền kiểm soát chúng. Sự kiểm soát có phần ảo tưởng (vì ít nhất Dypgen rất phức tạp nên chúng tôi không thể duy trì nó, nhưng ít nhất chúng tôi có một bản sao mà chúng tôi nghĩ là có hiệu quả :)

Tôi sẽ không sử dụng pin vì giấy phép bị hạn chế, vì vậy tôi không thể sao chép nguồn và tôi không tin vào khả năng tồn tại lâu dài của nó như một sản phẩm độc lập: cách duy nhất tôi có thể sử dụng là nếu nó là kết hợp trực tiếp vào phân phối tiêu chuẩn của Ocaml.

Trong thế giới C ++, tôi có thể chỉ xem xét sử dụng Boost: mặc dù đây là thư viện của bên thứ ba không phải là một phần của Tiêu chuẩn, nó có sự hỗ trợ cộng đồng lớn như vậy và nó thực sự được đồng bộ hóa tuyệt vời với quy trình phát triển Tiêu chuẩn. Các ý tưởng được phát triển và thử nghiệm trong Boost trở thành loại thực tiễn hiện có có thể được tiêu chuẩn hóa và quy trình tiêu chuẩn đủ mở để cho phép cộng đồng tham gia.

Ocaml đã đạt được sự phổ biến mà nó thực sự có bởi vì nó là một sản phẩm tốt như vậy, nhưng điều đó là không đủ để cho phép nó trở thành một ngôn ngữ chính. Java rất tệ, nó đã trở nên phổ biến với hàng tỷ đô la tiếp thị và phát triển thư viện, nhưng cuối cùng phải phát hành ra cộng đồng để tồn tại.

Tôi đã thích mã hóa ở cả ML và C cho nhiều dự án. Điều ngăn tôi sử dụng ML trong các dự án nhúng (hầu hết trong số đó có các ràng buộc thời gian thực và yêu cầu xác thực) là bộ sưu tập rác.

Có nghiên cứu về quản lý bộ nhớ với các vùng (xem MLKit ) nhưng sự phức tạp của việc triển khai và đào tạo cần thiết để sử dụng chúng đúng cách (và rủi ro tiếp viên) đã gây trở ngại cho việc sử dụng chúng.

IMHO, tôi nghĩ rằng một vấn đề lớn của OCaml không phải ở ngôn ngữ (đó là điều tuyệt vời) mà là ở những người phát triển nó và do đó, giấy phép của anh ấy:

http://caml.inria.fr/ocaml/license.en.html

Họ sử dụng giấy phép Q Public cho trình biên dịch! Có, giấy phép cũ - Trolltech được sử dụng cho các thư viện Qt! Quên về việc nhận bất kỳ đóng góp với giấy phép như vậy.

Nếu bạn đang kiểm tra Shootout ngôn ngữ ( http://shootout.alioth.debian.org/ ) khoảng 7-8 năm trước, OCaml chỉ đứng sau C và C ++ về tốc độ thực hiện. Trong khi đó, các ngôn ngữ khác (như Haskell) có trình biên dịch tốt hơn (do cách tiếp cận cộng đồng khác, tôi cho rằng) và bây giờ tốc độ thực thi của OCaml không còn lớn như trước đây.

Một thời gian ngắn, tôi sẽ không sử dụng OCaml, vì tôi không thấy nó đi đâu tốt hơn nếu không có một số tin tặc thực sự giỏi tạo ra trình biên dịch OCaml có giấy phép nguồn mở THỰC SỰ và một cộng đồng có hành vi nguồn mở THỰC SỰ.

Chà, nếu đó là về tiền như @jrockway nói, chúng ta sẽ xem liệu F # sẽ đạt được sự phổ biến như java hay C #.

Đối với tôi, tôi đoán các nhà phát triển không cảm thấy khó hiểu với cách làm chức năng (đó là từ phiên F # trong ngày công nghệ 2009, nơi có khoảng 10 người nói rằng họ biết lập trình chức năng trong số gần 100 người).

Tôi đã bắt đầu OCAML năm nay, tôi chưa bao giờ nhúng tay vào lập trình chức năng, nhưng bây giờ tôi thực sự học được những điều mới luôn luôn từ OCAML và cách chức năng để giải quyết vấn đề, (nhưng tôi không thể nói rằng tôi sẽ từ bỏ C # để sử dụng OCAML :)).

Chà, có lẽ F # trở nên phổ biến.

Nó không giúp c-> ocaml là một sự chuyển đổi tinh thần lớn hơn c-> lisp. Tôi đã xem xét ocaml một vài lần và luôn thấy rằng chi phí / lợi ích không có ở đó cho tôi, vì vậy hãy đặt nó sang một bên một lần nữa. Đó không phải là những công trình khiến nó trông khó khăn, những cái đó thực sự trông rất gọn gàng. Nó đã cố gắng học một ý nghĩa hoàn toàn khác cho '!'. Lisp ít nhất trông khác nhau đến mức dễ dàng tránh hiểu sai các phần nhỏ của nó là c.

Nếu bạn muốn sử dụng ngôn ngữ trong các hệ thống nhúng thời gian thực, bạn cần con trỏ và bạn không thể đủ khả năng sử dụng GC.

Tôi nghĩ lý do chính là quá ít nhà phát triển biết OCaml.

Và khi nói chuyện với các nhà phát triển khác (những người đã nghe điều gì đó về Ocaml) tôi luôn có ấn tượng rằng họ nghĩ về OCaml như một ngôn ngữ "chỉ giáo dục" ... buồn nhưng đúng

Tôi thích O'caml rất nhiều ... Tôi đã triển khai rất nhiều thứ bằng cách sử dụng nó, trình biên dịch, thông dịch viên, hệ thống để giao tiếp với C ...

Khi tôi học nó, vấn đề chính là các thông báo lỗi không thực sự rõ ràng ... vì vậy, lúc đầu, tôi không thực sự chắc chắn khi nào nên đặt ';' và điều đó thực sự khó để tìm thấy điều đó thực sự; đã đặt nhầm chỗ ...