OCaml neden daha popüler değil?

Her zaman C'nin gömülü sistemler ya da maksimum hızda çalışması gereken herhangi bir şey için tercih edilen dil olduğunu duydum . Asla C'ye karşı bir düşkünlük geliştirmedim, çünkü işaretçi aritmetiğinden hoşlanmıyorum ve dil bir meclisin üstünde zar zor duruyor.

Öte yandan, ML dilleri işlevseldir, çöp toplanan dillerdir ve OCaml bile bir nesne modeline sahiptir, ancak C kadar hızlı oldukları için bir üne sahiptirler. kod, ancak yüksek performanslı uygulamalar yazmak için gereken hızı korur.

Özellikle OCaml, gömülü aygıtlar, grafik sürücüleri, işletim sistemleri vb. Gibi C'nin geleneksel olarak kullanıldığı herhangi bir yerde kullanılabilir. Tüm haklarıyla OCaml, şu ana kadar dünyayı ele almalıydı; kullandım.

Bu öznel bir sorudur, ancak C ve diğer diller popüler hale gelirken OCaml ve ML diğer diller neden bu kadar belirsiz kaldı?

İlk cevap, hiç kimse dillerin neden popüler olduğunu bilmiyor ve başka türlü söyleyenlerin kandırılmış olduğunu veya bir gündeme sahip olduğunu. (Bir dilin neden popüler hale gelemediğini belirlemek genellikle kolaydır , ancak bu başka bir soru.)

Bu feragatname ile, işte ilk önce düşündürücü, en önemli noktalardan bazıları:

• İlk olgun C derleyicisi 1974'te ortaya çıktı; İlk olgun OCaml derleyicisi 1990'ların sonunda ortaya çıktı. C 25 yıllık bir kafa başlangıcına sahip.

• C, tüm zamanların en büyük "katil uygulaması" olan Unix'le birlikte gönderildi. Uzun zamandır, dünyadaki her CS departmanının Unix'e sahip olması gerekiyordu; bu, her eğitmenin ve bir CS kursuna katılan herkesin C'ye maruz kalma şansı olduğu anlamına geliyordu. OCaml ve ML hala ilk katil uygulamasını bekliyor. (MLdonkey harika, ama Unix değil.)

• C nişini o kadar iyi dolduruyor ki, yalnızca sistem programlamaya adanmış bir başka düşük seviye dil olmayacağından şüpheliyim . (Kanıtları lehine görmek için, Dennis Ritchie'nin HOPL II'den C'nin tarihi hakkındaki makalesini okuyun.) OCaml'ın nişinin ne olduğu bile belli değil ve Standard ML'nin nişi sadece biraz daha net. Bu yüzden Caml ve ML'nin oldukça az sayıda rakibi var, C ise tek rakibini (BLISS) öldürdü.

• C'nin en güçlü yanlarından biri, maliyet modelinin çok tahmin edilebilir olmasıdır: herhangi bir küçük C kodu parçasına bakmak kolaydır, bu kodun yürütülmesi için hangi makine işlemlerinin gerçekleştirilmesi gerektiğine dair doğru bir fikir edinebilir. OCaml'ın maliyet modeli, özellikle bellek tahsisi nedeniyle çok daha az açıktır.çok daha az açıktır ve toplam bellek tahsisi maliyeti (tahsisat maliyeti artı çöp toplama işlemi sırasında ortaya çıkan maliyetler), nesnelerin ne kadar süre yaşadığı ve hangi nesnelerin diğer nesnelere başvurduğu gibi ortaya çıkan özelliklere bağlıdır. Net sonuç, performansın tahmin edilmesi zor ve hatta olaydan sonra analiz edilmesi zor olmasıdır. (OCaml'ın bellek profilleme araçları olması gerektiği gibi değildir.) Sonuç olarak OCaml, performansın çok öngörülebilir olması gereken uygulamalar için iyi değildir - gömülü sistemler gibi.

• C standart ve birçok derleyici içeren bir dildir. Sadece derleyici tek bir kaynaktan ve derleyici: OCaml bir yazılım eserdir olduğu standardı. Ve bu standart her sürümde değişir. Kararlılığa ve geriye dönük uyumluluğa değer veren insanlar için, tek kaynaklı bir dil kabul edilemez bir riski temsil edebilir.

• Yarısı kadar iyi bir lisans derleyici kursu ve çok ısrarlı olan herkes az ya da çok çalışan ve yeterli performansı olan bir C derleyicisi yazabilir. Bir OCaml veya ML uygulamasını yerden kaldırmak için çok daha fazla eğitim gerekir ve saf bir C derleyicisiyle karşılaştırılabilir performans elde etmek için çok daha fazla çalışma gerekir. Bu, OCaml gibi dillerle uğraşacak çok daha az hobicinin olduğu anlamına gelir, bu yüzden toplumdan nasıl yararlanılacağı hakkında derinlemesine bir anlayış geliştirmek daha zordur.

OCaml ile ilgili problemin “kutudan çıkma” için çok kullanışlı olmadığını düşünüyorum. İnsanların bir dili kullanmasının nihai nedeni, ihtiyaç duydukları kütüphanelere sahip olmasıdır. "Kutunun dışında" hiçbir şey olmadan, hiç kimse bir kütüphane yazmak zorunda olduklarını anlamaya yetecek kadar projeye giremez. Sonuç, kütüphaneleri olmayan ve "gerçek uygulamalar" yazmayı zorlaştıran bir dildir.

Sanırım bu OCaml'ın yaşadığı şey - hiç kimse bir programlama dili olduğu için “gerçek projelere” başlamayı zorlaştırmıyor. Yay, iki ve iki ekleyebilir ve sonucu yazdırabilirim. Sonuçta, programcıların pratik yapması için fazla yardımcı olmayan, çoğunlukla akademik yazılım olan (yazar doktora yaptı ve devam etti) bir kütüphane koleksiyonudur.

(“Piller Dahil” gibi projelerle bunu değiştirmek için yapılan çalışmalar olduğunu biliyorum. 5 yıl içinde buraya geri dönün ve belki de OCaml daha popüler olacak.)

Bu kuralın bazı istisnaları vardır. Java, kütüphaneler olmadan başladı, ama Sun, insanlara hepsini evde yazmaları için para ödedi ve sonra da cehennemi sattılar. Java sertifikası, Java'ya özgü donanım, Java kitapları, Java sınıfları, vb. Sonra bile çoğu üniversiteyi, öğrenme programlaması için kullanmak çok iyi bir dil olmasa da, özellikle öğretmeye ikna etti.

Sonuç popülerdi. Para birçok sorunu çözebilir.

İşlevsel dil arenasında Haskell'in oldukça popüler hale geldiğini görebiliriz. Bence popülerliğin çoğu, yararlı kütüphaneler yazan ve asla dilleri pazarlamayı bırakmayan insanlar gibi. Her gün Reddit Programlama hakkında birkaç Haskell makalesi görüyorsunuz. Bu, nihayet “Haskell'ı deneyeceğim” kararını verinceye kadar halkların kafasında sıkışıp kalmasını sağlar. Bunu yaptıklarında, web çerçeveleri, nesne veritabanları, OpenGL kütüphaneleri ve XML işleme kütüphaneleri gibi faydalı şeyler görürler. Bu aslında "Hemen Şimdi" konusunda yararlı bir şeyler yapabilecekleri anlamına gelir. Dolayısıyla, üretken olma potansiyeli ve bu konuda çok şey duyma potansiyeli arasında Haskell, çok fazla popülerlik kazandı.

CL, Haskell ile aynı kütüphanelere sahiptir ve neredeyse hızlıdır, ancak kimse bundan bahsetmez, bu yüzden "ölü hisseder". Gerçekten de #lisp, #haskell'den çok daha sessizdir, ancak Lisp hala birçok kütüphanesi olan çok üretken bir dildir. Başka hiçbir dilde SLIME yok. Ancak pazarlama çok önemlidir ve Haskell bunu Lisp veya OCaml'den daha iyi yapar (ve aynı kullanıcı tabanı için rekabet eder).

Son olarak, bazı insanlar hiçbir zaman programlamayı "başaramaz", bu yüzden zihinsel modellerini kırmak (değişkenler değer içeren kutulardır, kod yukarıdan aşağıya doğru yürütür) dilinizi kullanmadıklarından emin olur. Bu tip programcı, programlama popülasyonunun büyük bir yüzdesidir, bu nedenle Lisp, Haskell ve OCaml gibi soyut dillerin olası kullanıcı tabanlarını sınırlar.

OCaml'i dil olarak çok seviyorum . FAKAT...

Araçlar sadece orada değil. Hata ayıklayıcı yalnızca Tamam çalışır, ancak pencerelerde çalışmaz (en son kontrol ettiğim) ve bunun için pek fazla geliştirme aracı yoktur.

Tip sistemi zaman zaman biraz fazla güçlüdür. Tip çıkarımının nasıl çalıştığını veya genel olarak ML tipi sistemi anlamayan biri için, bir şamandıraya bir tamsayı ekleyemediği gerçeği hemen büyük bir sonuçtur.

Standart kütüphanede bazen tutarsız bir his olabilir.

Nesne modeli biraz ele geçirilmiş gibi görünüyor ve standart kütüphane, modül tabanlı kütüphaneleri tercih etmeyi zorlukla kullanıyor.

Temelde "cilalı" hissetmeyen bir dille ilgili olan ve bir dili seçerken ve onları sevip sevmeyeceklerine karar vermeye çalışırken insanları çok kritik bir süre boyunca uzaklaştıran birçok şey var.

En önemli mirasının, diğer ML lehçeleriyle birlikte diğer işlevsel diller üzerinde de çok güçlü bir etkisi olacağına inanıyorum. Mevcut nesil işlevsel dillerin çoğu, ML lehçelerinden en iyi unsurları alır ve bazı sıkıntıları giderir.

Gömülü sistemler genellikle iki şey gerektirir: hız ve determinizm. OCaml hız sağlayabilir, ancak bir çöp toplayıcısına sahip olması, doğası gereği belirlenmemiş ve basit yapamayacağı gerçek zamanlı bir sistemdir.

Bu biraz elma-portakal karşılaştırması. OCaml oldukça genç bir dildir [1] ve onu ana akıma sokmak için hiçbir zaman ciddi ve sürekli bir çaba olmamıştır (Microsoft'un F # ile yaptığı çalışmayı hariç). C'den farklı olarak, en yaygın olarak desteklenen ve taklit kurumsal işletim sisteminin (yani, UNIX) lingua franca'sı değildir . Java'nın aksine, onu yeni nesil bilgisayar platformu olarak iten büyük bir şirketi olmamıştır. Perl, Python ve Ruby'den farklı olarak, yüksek profilli, etkili bir niş içinde yer almadı (yani, niş, programlama dili ve otomatik mantık araştırmasıdır - web geliştirme ile karşılaştırıldığında çok yüksek profilli değildir). Bu nedenle, süper popüler değildir.

[1] Adalet konusunda asıl ML dili 70'lerden beri buralarda. Ancak OCaml 1996 yılına kadar görünmedi ve Standard ML kütüphanelerini miras almadı. Pratik açıdan C, C ++, Java, Python, Haskell ve hatta Ruby'den daha genç bir dildir.

OCaml topluluğu, uygulama geliştirmeyi kolaylaştıran büyük ve güvenilir bir standart kütüphane (bugün OCaml ile birlikte gelenlerin ötesinde) geliştiremedi. Sorunu çözmek için birkaç girişimde bulunulmasına rağmen, eksik olanı görmek için Python veya Ruby'ye bir göz atın. OCaml, XML, ağ oluşturma, veri hesaplama vb. Gibi ileri standart modüller ile etkileşime girmenize gerek duymayacağınız ve kendiniz uygulamamayı tercih ettiğiniz, algoritmik bir problemi çözmek istiyorsanız harika bir dildir.

Sorunun bir kısmının modüllerin OCaml tarafından dosyalara nasıl eşleştirildiğine inanıyorum: kavramsal olarak tüm * .ml dosyalarının aynı isim alanı içinde yaşıyor ve dizinlerin hiçbir anlamı yok. Bu, bir topluluğun bir kütüphane geliştirmesini zorlaştırır. Derleyici, dizin hiyerarşilerini modül hiyerarşilerine eşlerse, standart bir kütüphanenin gelişmesi için daha iyi bir şans görürüm. Bununla birlikte, bu, çekirdek derleyici geliştiricileri tarafından önemli ölçüde çaba gerektirecektir. (Paketleme modüllerinin farkındayım ama bunun bir kirlilik olduğunu düşünüyorum.)

Diğer bir kütüphane problemi, derleyici sürümleri arasındaki ikili uyumluluktur. Bir derleyici güncellemesinden sonra tüm kütüphane kodunun yeniden derlenmesi gerektiğini söylemek oldukça güvenlidir. Bu, modüllerin veya kütüphanelerin ikili sürümlerini sağlamayı zorlaştırır.

Muhtemelen çok fazla sayıda insana ML'nin türlerle ilgili tuhaf ve kafa karıştırıcı teorik konulara girişin bir parçası olarak öğretildiği için. Bana da öyle oldu.

Aynı saatlerde ML ve Smalltalk gösterildi. Smalltalk çok güzel görünüyordu ve OO'nun ne için olduğu ve bu ortamda nasıl güzel ve etkileşimli şeyler yapabileceğiniz hemen anlaşılabilir bir durumdu. ML, yapmak istediğim şeyle alakalı olmayan soyut matematiksel şeyler hakkındaydı. Ve C'nin aksine, 16-bit mikroplara hızlı oyunlar yazmama izin vermedi.

Bu, elbette, haksız ve özneldir. Fakat çoğu insan için gerçek hikaye bu olabilir.

Bugünlerde sorunun şu soru olacağını tahmin ediyorum: şimdi türler hakkında bu garip ve kafa karıştırıcı teorik konuları bilmem gerektiğini hissediyorum, neden Haskell veya Erlang üzerinden ML seçmeliyim?

Asıl meselenin gerçek bir standart kütüphanenin olmayışı olduğuna inanıyorum. Bu nedenle , durumu büyük ölçüde iyileştirmesi beklenen OCaml Pilleri Dahil Projesi . Birkaç gün içinde Beta aşamasına girmesi gerekiyor, bu yüzden soruyu bir yıl sonra tekrar sormanız gerekecek.

Zayıf Windows desteğinin, dik bir öğrenme eğrisinin ve ince standart kütüphanenin geçmişte OCaml'in alımını engellediğine katılıyorum, ancak Java gibi ana dillere kıyasla OCaml hakkında çok fazla öğretici bilgi eksikliği (örneğin, kitaplar) olduğunu ekleyeceğim.

Ayrıca, OCaml gibi dilleri bilen insan türleri oldukça heterojendir. Web programcıları arasında, belki 1000'de 1'i OCaml'ı duymuş olacak. Cambridge Üniversitesi'nde bilimsel hesaplama yapan insanlar arasında, tanıdığım kişilerin yaklaşık% 90'ı OCaml'da akıcıydı. Aslında arkadaşlarım arasında OCaml öğrenen sonlardan biriydim. Hatta 256 CPU süper bilgisayarımızda OCaml'ı çalıştırdık ...

Ayrıca bu sorunların hızla çözüldüğünü de belirtmeliyim. OCaml, Ocsigen gibi projelerle son zamanlarda web programcılığı için kendini yeniden icat etti ve bu bağlamda en az iki büyük endüstriyel başarı öyküsü var. Şimdi OCaml'da yeni bir kitap daha var. Topluluk, beta sürümüne yeni giren ve harika görünen "piller dahil" adlı kapsamlı bir standart kütüphanede işbirliği yapıyor. OCaml bir çok çekirdekli dostu sürümü piyasaya sürülmek üzere. OCaml'ın en yeni sürümü ayrıca tembel desenler ve dinamik olarak yüklenmiş yerel kod OCaml kütüphaneleri gibi birçok yeni özellik içeriyor.

Problemin bir kısmı, işlevsel programlamanın çoğu insanın düşünmesi için doğal bir yol olmadığını düşünüyorum (ve bunu işlevsel programlamaya büyük ilgi duyan biri olarak söylüyorum). Bu, günümüzde programcıların büyük çoğunluğunun prosedürel programlamayı öğrenmeye başlaması (çoğu popüler OOP dili hala tam anlamıyla prosedürseldir) ve bu nedenle işlevsel dillerin başlangıçta ayarlanması zordur.

Üniversiteye başladığımda, makul miktarda BASIC, C ++ ve Java ile biraz da Pascal ve x86 assembly dili biliyordum. Bir uzmandan çok uzaktım ancak tüm programlama dillerinin temelde biraz farklı sözdizimiyle aynı olduğu sonucuna vardım. Programlama kursuna girişimiz, bu düşüncemi hızla etkisiz hale getiren ML kullanıyordu. Programlama kariyerimin o aşamasında ML’ye başımı döndürmekte zorlandım ve gerçekten işlevsel programlama noktasını görmedim. İşlevsel bir yaklaşımın faydalarını gerçekten takdir etmek için prosedürel programlamanın bazı sorunlarıyla ilgili biraz daha tecrübe gerektirdiğini düşünüyorum.

ML öğretim üyemiz sık sık sorunları özyinelemeyle ifade etmenin döngüleri veya diğer prosedür kavramlarını kullanmaktan daha "doğal" ve kolay olduğunu iddia etti. Bu iddiaya asla ikna olmadım ve hala satın almadım. Özyinelemeli işlevler bazen sorunlara özellikle şık ve özlü çözümler sağlayabilir, ancak yine de sorunları düşünmenin doğal olmayan bir yolunu buluyorum. Belki de çok güçlü bir matematik geçmişiniz varsa, daha sezgisel görünür, ancak çoğu insanın özyinelemeli düşünmesinin kolay olduğunu sanmıyorum. Fonksiyonel programlama paradigmasına özyinelemeli fonksiyonların merkezi olması göz önüne alındığında, bunun işlevsel dillerin daha az popüler olmasının bir nedeni olabileceğini düşünüyorum.

Dil popülerliğine bir geribildirim etkisi de var. Programlamaya başladığımda grafiksel efektlerin ve oyunların nasıl programlandığını bilmek istedim. Biraz BBC BASIC ve daha sonra QBASIC'i öğrendikten sonra, demo sahnesi ve oyun programcıları tarafından kullanılan en yaygın dillerin ne olduğunu ve C ++ ve x86 montajını öğrenmekle ilgili olanları doğal olarak araştırdım. Günümüzde bazı yeni programcılar web uygulamalarının nasıl üretileceğini bilmek isteyebilirler ve bu nedenle PHP, Ruby veya C # öğrenmeye yönelirler. Kendini motive eden yeni başlayan programcılar için 'X gibi bir şeyi programlamak için en iyi dil hangisidir' cevabının 'Ocaml' olacağı çok az uygulama alanı vardır.

Ocaml'ın sınırlı popülaritesi için verilen pratik sebeplerin birçoğu (olgun kütüphanelerin, hata ayıklayıcıların, IDE'lerin, vb. Eksikliği) Microsoft'un birinci sınıf .NET dili olarak F # için resmi desteği ile ele alınmaktadır. F # 'nin işlevsel programlama için daha fazla popülerlik seviyesi getirmesine yardımcı olup olmadığını görmek ilginç olacaktır.

Sorunun özünün politika olduğuna inanıyorum. Ocaml geliştiricileri esas olarak araştırmaya ilgi duyuyor ve zengin bir kütüphane sağlayacak ve sürdürecek kaynaklara sahip değiller. Bununla birlikte, ürünün kontrolünü bu kaynaklara sahip olan topluma salıverme konusunda da isteksizler, sonuçta bu sorunu çözmek için yapılan birkaç girişimde bulunmayan işbirliği ve üçüncü taraf kütüphanelerinin finansmanına dayanıyor ve bu girişimler başarısız oldu. Ocaml geliştiricileri tutumlarını değiştirmediği sürece, bataryalar aynı sebeple başarısız olacaktır.

Ürünümü geliştirmek için Ocaml kullanıyorum ve basit bir kuralım var: üçüncü taraf koduna bağımlılığı en aza indirgemek. Bir üçüncü taraf ürünü yararlı olduğunda, eğer mümkünse, kaynak kodları doğrudan pakete dahil edin. Örneğin, OCS Şeması ve Dypgen, Felix ayrıştırıcısının temel parçalarıdır, bu yüzden kaynaklarımıza kopyalanırlar, bu yüzden onlar üzerinde bazı kontrollerimiz vardır. Kontrol biraz yanıltıcıdır (Dypgen en azından çok karmaşık olduğu için bakımını yapmamız pek mümkün değil, ama en azından işe yaradığını düşündüğümüz bir kopyaya sahibiz :)

Pilleri kullanmayacağım, çünkü lisans kısıtlayıcıdır, bu yüzden kaynağı kopyalayamıyorum ve uzun süredir bağımsız bir ürün olarak yaşayabildiğine inanmıyorum: bu ürünü kullanabilmemin tek yolu, doğrudan Ocaml'in standart dağılımına dahil edilmiştir.

C ++ dünyasında Boost'u kullanmayı düşünebilirim: Standardın bir parçası olmayan üçüncü taraf bir kütüphane olmasına rağmen, bu kadar yoğun bir topluluk desteği var ve aslında Standartlar geliştirme süreci ile mükemmel şekilde senkronize edildi. Boost'ta geliştirilen ve test edilen fikirler, standardize edilebilecek mevcut bir uygulama türü haline geldi ve standartlar, toplumun katılımına izin verecek kadar açık.

Ocaml, sahip olduğu popülerliği, çok iyi bir ürün olduğu için edinmiştir, ancak bu, ana dil haline gelmesine izin vermek için yeterli değildir. Java kabalıktır, milyarlarca dolarlık pazarlama ve kütüphane gelişimi ile popüler hale getirildi, ancak sonunda hayatta kalmak için topluma serbest bırakılması gerekti.

Çok çeşitli projeler için hem ML hem de C'de kodlamanın tadını çıkardım. ML'yi gömülü projelerde kullanmamı engelleyen şey (çoğu gerçek zamanlı kısıtlamaları olan ve doğrulama gerektiren) çöp toplama.

Bölgelerle hafıza yönetimi konusunda araştırmalar var (bkz. MLKit ), ancak bunları düzgün bir şekilde kullanmak için gereken uygulamaların ve eğitimin karmaşıklığı (ve görevli riskleri) bunları kullanmakta zorlandı .

IMHO, OCaml'ın büyük bir probleminin dilde (bu harika) değil, onu geliştiren insanlarda ve bunun sonucu olarak lisansında olduğunu düşünüyorum:

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

Derleyici için Q Public lisansını kullanıyorlar! Evet, eski Trolltech lisansı Qt kütüphaneleri için kullanıldı! Böyle bir lisansla herhangi bir katkı almayı unutun.

Language Shootout'u ( http://shootout.alioth.debian.org/ ) yaklaşık 7-8 yıl önce kontrol ediyorsanız , OCaml C ve C ++ 'nın tam arkasındaydı. Bu arada, diğer diller (Haskell gibi) daha iyi bir derleyici elde etti (farklı bir topluluk yaklaşımı nedeniyle, sanırım) ve şimdi OCaml yürütme hızı geçmişte olduğu kadar büyük değil.

Kısacası, OCaml'ı kullanmayacağım, çünkü gerçekten iyi hacker'ların GERÇEKTEN açık kaynak lisansına sahip bir OCaml derleyicisi ve GERÇEKTEN açık kaynak davranışına sahip bir topluluk oluşturmadan daha iyi bir yere gitmediğini görmüyorum.

Eğer jrockway'in dediği gibi parayla ilgiliyse, F #'nın java mı yoksa C # gibi popülerliği mi kazanacağını göreceğiz.

Benim için geliştiricilerin bir şeyleri yapmanın işlevsel yoluyla rahat hissetmediklerini tahmin ediyorum (bu, 2009'un 100. Günündeki F # oturumundan yaklaşık 100 kişinin işlevsel programlama bildiğini söylediği bir oturumdan).

OCAML'e bu yıl başladım, ellerimi fonksiyonel programlama ile kirletmedim, ama şimdi gerçekten OCAML'den ve sorunları çözmenin işlevsel yolundan her zaman yeni şeyler öğreniyorum (ama C # 'dan vazgeçeceğimi söyleyemem. OCAML kullanmak :)).

Belki F # popüler olur.

C-> ocaml'in c-> lisp'den daha büyük bir zihinsel geçiş olmasına yardımcı olmuyor. Ocaml'i birkaç kez düşündüm ve her zaman maliyet / kazancın benim için orada olmadığını fark ettim, bu yüzden tekrar ayırın. Sert görünmesini sağlayan yapılar değildi, aslında çok temiz görünüyorlardı. '!' İçin tamamen farklı bir anlam öğrenmeye çalışıyordu. Lisp en azından o kadar farklı görünüyor ki, küçük parçalarını yanlış yorumlamaktan kaçınmak c.

Bir dilin gerçek zamanlı gömülü sistemlerde kullanmasını istiyorsanız, işaretçilere ihtiyacınız vardır ve bir GC'yi karşılayamazsınız.

Bence asıl sebep, çok az sayıda geliştiricinin OCaml'ı bilmesidir.

Diğer geliştiricilerle (Ocaml hakkında bir şeyler duyanlar) konuşurken, OCaml'i "sadece eğitim amaçlı" bir dil olarak düşündükleri izlenimini edindim ... üzgün ama gerçek

O'caml'i çok seviyorum ... C ile iletişim kurmak için derleyici, tercüman, sistem kullanarak bir sürü şey uyguladım.

öğrendiğimde, asıl sorun, hata mesajlarının gerçekten net olmadığıydı ... yani, başlangıçta ne zaman koymak istediğimden emin değildim ';' ve bunu gerçekten bulmak zordu; yanlış yerleştirildi ...