it-swarm.asia

OCaml neden daha popüler değil?

Her zaman C'nin the gömülü sistemler için kullanmak istediğiniz dil olduğunu veya maksimum hızda çalışması gereken bir şey olduğunu duydum. C için hiç bir sevgi geliştirmedim, çünkü çoğunlukla işaretçi aritmetiği sevmiyorum ve dil, montajcının üstünde bir basamak değil.

Öte yandan, ML dilleri işlevseldir, çöp toplanan dillerdir ve OCaml bile bir nesne modeline sahiptir, ancak C kadar hızlı olma konusunda bir üne sahiptir. ML dilleri, herkesin üst düzey, özlü yazmak için isteyebileceği soyutlamaya sahiptir. 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ığı her yerde kullanılabilir. Tüm hakları gereği, OCaml şimdiye kadar dünyayı ele geçirmiş olmalıydı, ancak dili henüz hiç kimse duymadı. kullandım.

Bu öznel bir soru, ama OCaml ve ML diğer diller neden bu kadar belirsiz kalırken, C ve diğer diller popüler oldu?

86
Juliet

İlk cevap, kimsenin dillerin neden popüler hale geldiğini gerçekten bilmediğini ve aksini söyleyen herkesin kandırıldığını veya gündemi olduğunu bilmiyor. (Bir dilin popüler olmanın neden başarısız olduğunu tanımlamak genellikle kolaydır, ancak bu başka bir soru.)

Bu feragatnameyle, ilk önce en önemlisi, bazı önemli noktalar şunlardır:

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

  • C, tüm zamanların en büyük "katil uygulaması" olan Unix ile birlikte gönderildi. Uzun bir süre boyunca, dünyadaki her CS departmanının Unix'e sahip olması gerekiyordu, bu da her eğitmen ve CS kursuna katılan herkesin C. OCaml ve ML'ye maruz kalma şansının hala ilk katil uygulamasını beklediği anlamına geliyordu. (MLdonkey iyidir, ancak Unix değildir.)

  • C, nişini o kadar iyi doldurur ki, sistem programlarına sadece ayrılmış başka bir düşük seviyeli dil olmayacağından şüpheliyim. (Kanıtları olumlu 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 net değil ve Standart ML'nin nişi biraz daha net. Bu yüzden Caml ve ML'nin birkaç rakibi var, C ise tek rakibini (BLISS) öldürdü.

  • C'nin en güçlü yönlerinden biri, maliyet modelinin çok öngörülebilir olmasıdır: C kodunun herhangi bir küçük parçasının anında doğru bir fikir edinebilmesi kolaydır bu kodu yürütmek için hangi makine işlemlerinin yapılması gerektiğine dair OCaml'ın maliyet modeli, özellikle bellek ayırma çok daha az açık ve toplam bellek ayırma maliyeti (ayırma maliyetine ve ortaya çıkan maliyetlere eşit) çöp toplama sırasında) nesnelerin ne kadar süre yaşadığı ve hangi nesnelerin diğer nesnelere başvurduğu gibi ortaya çıkan özelliklere bağlıdır. Bunun neticesi, performansın tahmin edilmesinin ve hatta gerçeğin ardından analiz edilmesinin zor olmasıdır. (OCaml'in bellek profili oluşturma araçları olması gerektiği gibi değildir.) Sonuç olarak, OCaml, performansın çok tahmin edilebilir olması gereken (gömülü sistemler gibi) uygulamalar için iyi değildir.

  • C, standart ve birçok derleyiciye sahip bir dildir. OCaml bir yazılım eseridir: tek derleyici tek bir kaynaktan ve derleyici standarttır. Ve bu standart her sürümle birlikte değişir. İstikrara ve geriye dönük uyumluluğa değer veren insanlar için, tek kaynaklı bir dil kabul edilemez bir riski temsil edebilir.

  • Yarı-iyi bir lisans derleyici kursu ve çok fazla sebat olan herkes, az ya da çok çalışan ve yeterli performansa sahip bir C derleyicisi yazabilir. OCaml veya ML'nin bir yerden uygulamasını sağlamak çok daha fazla eğitim gerektirir ve saf bir C derleyicisine benzer bir performans elde etmek çok daha fazla iş gerektirir. Bu, OCaml gibi dillerle uğraşmak için çok daha az hobinin olduğu anlamına gelir, bu nedenle topluluktan nasıl yararlanacağı konusunda derin bir anlayış geliştirmek daha zordur.

82
Norman Ramsey

Ben OCaml ile sorun "kutunun dışında" çok yararlı olmadığını düşünüyorum. İnsanların bir dili kullanmasının nihai nedeni, ihtiyaç duydukları kütüphanelere sahip olmasıdır. Bununla birlikte, "kutunun dışında" hiçbir şey olmadan, hiç kimse bir kütüphane yazmaları gerektiğini anlayacak kadar projeye giremez. Sonuç, "gerçek uygulamalar" yazmayı zorlaştıran, kütüphanesi olmayan bir dildir.

Bence OCaml bu kadar acı çekiyor - kimse "gerçek projelere" başlamak için rahatsız etmiyor çünkü her şey bir programlama dili. Yay, iki ve iki ekleyebilir ve sonucu yazdırabilirim. Sonuç, çoğunlukla akademik vazgeçilmez kütüphanelerden oluşan bir koleksiyon (yazar doktorasını aldı ve devam etti), bu da programcıları uygulamak için çok yararlı değil.

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

Bu kuralın bazı istisnaları vardır. Java kütüphane olmadan başladı, ancak Sun insanlara hepsini evde yazmak için para verdi ve sonra cehennemden çıktılar. Java sertifika, Java -özel donanım, Java kitaplar, Java dersler, vb.) Hatta çok iyi bir dil olmasa bile çoğu üniversiteyi sadece öğretmeye ikna etti programlama öğrenmek için kullanmak.

Sonuç popülerlik oldu. Para birçok sorunu çözebilir.

İşlevsel dil alanında Haskell'in oldukça popüler hale geldiğini görebiliriz. Popülerliğin çoğunun yararlı kütüphaneler yazan ve dili pazarlamayı asla bırakmayan dons gibi insanlardan kaynaklandığını düşünüyorum. Her gün Reddit Programlama ile ilgili birkaç Haskell makalesi görüyorsunuz. Bu, sonunda "Haskell'i deneyeceğim" kararını verene kadar insanların zihninde takılı kalmasını sağlar. Yaptıklarında, web çerçeveleri, nesne veritabanları, OpenGL kütüphaneleri ve XML işleme kütüphaneleri gibi yararlı şeyler görürler. Bu, aslında "Hemen Şimdi" yararlı bir şey yapabildikleri anlamına gelir. Dolayısıyla üretken olma potansiyeli ile bu konuda çok şey duymak arasında Haskell çok popülerlik kazandı.

CL, Haskell ile aynı kütüphanelerin çoğuna sahiptir ve neredeyse hızlıdır, ancak kimse bundan bahsetmez, bu yüzden "ölü hisseder". Aslında #LISP #haskell'den çok daha sessizdir, ancak LISP hala çok sayıda kütüphaneye sahip çok üretken bir dildir. Başka hiçbir dilde SLIME yoktur. 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 programlamayı asla "almaz", bu nedenle zihinsel modellerini kırmak (değişkenler değer içeren kutulardır, kod yukarıdan aşağıya çalışır) dilinizi kullanmadıklarından emin olur. Bu tür programcı programlama popülasyonunun büyük bir yüzdesidir, bu nedenle LISP, Haskell ve OCaml gibi soyut dillerin olası kullanıcı tabanı daha da sınırlandırılır.

63
jrockway

OCaml çok dil olarak seviyorum. FAKAT...

Araçlar desteği orada değil. Hata ayıklayıcı sadece Tamam çalışıyor ama windows üzerinde çalışmıyor (son kontrol) ve orada sadece pek çok geliştirme araçları mevcut değildir.

Türü sistemi, bazen, biraz çok güçlüdür. Tip çıkarımının veya genel olarak ML tipi sistemin nasıl çalıştığını anlamayan biri için, bir şamandıraya bir tamsayı ekleyememesi hemen önemli bir kapanmadır.

Standart kütüphane bazen tutarsız bir his verebilir.

Nesne modeli biraz takılmış gibi görünüyor ve standart kütüphane bunu neredeyse hiç kullanmıyor, bunun yerine modül tabanlı kütüphaneleri tercih ediyor.

Temelde "cilalı" hissetmeme diline denk gelen ve insanları bir dili seçtikleri ve dilden hoşlanıp hoşlanmadıklarına karar vermeye çalışırken çok kritik dönemde uzaklaştıran birçok başka şey var.

En önemli mirası, diğer ML lehçeleriyle birlikte, diğer işlevsel diller üzerinde çok güçlü bir etkisi olması olacaktır. Mevcut nesil fonksiyonel dillerin çoğu ML lehçelerinden en iyi unsurları alır ve bazı sıkıntıları düzeltir.

22
user21714

Gömülü sistemler genellikle iki şey gerektirir: hız ve determinizm. OCaml hız sağlayabilir, ancak bir çöp toplayıcıya sahip olması, onu doğası gereği belirsiz kılar ve basit olmayan bir gerçek zamanlı sistem için yapar.

21
ctacke

Bu biraz elma-portakal karşılaştırmasıdır. OCaml oldukça genç bir dildir [1] ve onu ana akım haline getirmek için hiçbir zaman ciddi ve sürekli bir çaba gösterilmemiştir (Microsoft'un F # ile şu anki çalışması hariç). C'den farklı olarak, en yaygın olarak desteklenen ve taklit edilen kurumsal işletim sisteminin lingua franca değil (UNIX). Java'nın aksine, yeni nesil bir bilgi işlem platformu olarak iten büyük bir şirkete sahip değildi. Perl, Python ve Ruby'den farklı olarak, yüksek profilli, etkili bir nişte tutulmamıştır (yani, niş programlama dili ve otomatik akıl yürütme araştırmasıdır - web geliştirmeye kıyasla çok yüksek profilli değildir). Bu nedenle, süper popüler değil.

[1] Adil olmak gerekirse, orijinal ML dili 70'lerden beri var olmuştur. Ancak OCaml 1996'ya kadar görünmedi ve Standard ML kütüphanelerini miras almadı. Pratik olarak C, C++, Java, Python, Haskell ve hatta Ruby'den daha genç bir dildir.

18
Chris Conway

OCaml topluluğu, uygulama geliştirmeyi kolaylaştıran geniş ve güvenilir bir standart kütüphane (bugün OCaml ile birlikte gelenlerin ötesinde) geliştiremedi. Sorunu çözmek için birkaç deneme vardır, ancak neyin eksik olduğunu görmek için Python veya Ruby) neyin eksik olduğunu görmek için göz atın. XML, ağ, veri hesaplama ve benzeri gibi gelişmiş standart modüller ile etkileşime girmeye çok fazla bağımlı olmayan algoritmik bir problemi çözebilir, ki bu da kendinizi uygulamak istemezsiniz.

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ı aynı ad alanında yaşıyor ve dizinlerin hiçbir anlamı yok. Bu, bir topluluğun bir kütüphaneyi geliştirmesi zorlaştırır. Derleyici, dizin hiyerarşilerini modül hiyerarşileriyle eşlese, standart bir kitaplığın gelişmesi için daha iyi bir şans görürdüm. Ancak bu, çekirdek derleyici geliştiricilerinin hatırı sayılır çaba göstermesini gerektirecektir. (Modüllerin paketlendiğinin farkındayım, ancak bunun bir çamur olduğunu düşünüyorum.)

Başka bir kütüphane sorunu, derleyici sürümleri arasındaki ikili uyumluluktur. Derleyici yükseltmesinden sonra tüm kitaplık 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.

15
Christian Lindig

Muhtemelen çok fazla insana ML'ye türlerle ilgili garip ve kafa karıştırıcı teorik şeylere girişin bir parçası olarak öğretildi. Bana böyle oldu.

Aynı zamanda ML ve Smalltalk gösterildim. Smalltalk sadece baktı lanet serin, ve ne OO ne olduğunu ve bu ortamda güzel, interaktif şeyler nasıl yapabileceğiniz hemen anlaşılabilir oldu. ML soyut matematiksel şeyler hakkındaydı C'den farklı olarak, 16 bitlik mikrolara hızlı oyunlar yazmama izin vermeyi vaat etmedi.

Bu, elbette, derin bir haksızlık ve özneldir. Ama bu çoğu insan için gerçek bir hikaye olacak.

Bugünlerde soru şu olurdu: şimdi türler hakkındaki bu garip ve kafa karıştırıcı teorik şeyleri bilmem gerektiğini hissediyorum, neden ML'yi Haskell veya Erlang'a seçmeliyim?

11
interstar

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

Kötü Windows desteğinin, dik bir öğrenme eğrisinin ve ince standart kütüphanenin, geçmişte OCaml'ın alımını engellediğini kabul ediyorum, ancak Java gibi ana dillerle karşılaştırıldığında OCaml hakkında çok büyük bir öğretici bilgi eksikliği (örn. Kitaplar) olduğunu ekleyeceğim.

Ayrıca, OCaml gibi dil bilen insanlar büyük ölçüde heterojendir. Web programcıları arasında belki 1.000 kişiden 1'i OCaml'ı duymuş olacaktır. Cambridge Üniversitesi'nde bilimsel bilgi işlem yapan insanlar arasında tanıdığım insanların yaklaşık% 90'ı OCaml'de akıcıydı. Aslında, arkadaşlarım arasında OCaml'ı öğrenen son kişilerden biriydim. Biz bile 256 CPU süper bilgisayar OCaml koştu ...

Ayrıca bu konuların hızla ele alındığını da belirtmeliyim. OCaml, Ocsigen gibi projelerle son zamanlarda web programlama için kendini yeniden keşfetti ve bu bağlamda en az iki önemli endüstriyel başarı öyküsüne sahip. Şimdi OCaml hakkında yeni bir kitap daha var. Topluluk, beta sürümüne giren ve harika görünen "piller dahil" adı verilen kapsamlı bir standart kütüphane üzerinde işbirliği yapıyor. OCaml'ın çok çekirdekli bir sürümü piyasaya sürülmek üzere. OCaml'ın son sürümü, tembel desenler ve dinamik olarak yüklenmiş yerel kod OCaml kütüphaneleri gibi birçok yeni özellik içerir.

8
Jon Harrop

Sorunun bir parçası, fonksiyonel programlamanın çoğu insanın düşünmesi için doğal bir yol olmadığını düşünüyorum (ve bunu fonksiyonel programlamaya büyük ilgi duyan ve takdir eden biri olarak söylüyorum). Bu, bugün programcıların büyük çoğunluğunun prosedürel programlamayı (en popüler OOP diller hala yürürlükte prosedüreldir) öğrenmeye başladığı ve dolayısıyla fonksiyonel dillerin başlangıçta ayarlanması zor olmasından kaynaklanmaktadır.

Üniversiteye başladığımda makul miktarda BASIC, C++ ve Java ve biraz Pascal ve x86 Assembly dili) biliyordum. Bir uzmandan uzaktım ama (biraz naif) sonuca ulaşmıştım tüm programlama dilleri temel olarak biraz farklı sözdizimi ile aynıdır.Programlama dersine girişimiz, bu düşünceyi hızla etkisiz hale getiren ML'yi kullandı.Programlama kariyerimin bu aşamasında başımı ML'ye getirmekte zorlandım ve gerçekten görmedim Fonksiyonel programlamanın bazı problemleri ile ilgili fonksiyonel yaklaşımın faydalarını gerçekten takdir etmenin biraz daha fazla deneyim gerektirdiğini düşünüyorum.

ML öğretim üyemiz sık sık problemleri özyineli olarak ifade etmenin döngüler veya diğer prosedür kavramlarını kullanmaktan daha 'doğal' ve daha kolay olduğunu iddia etti. Bu iddiadan asla ikna olmadım ve hala satın almıyorum. Özyinelemeli işlevler bazen sorunlara özellikle zarif ve özlü çözümler sağlayabilir, ancak yine de sorunları düşünmek için doğal olmayan bir yol buluyorum. Belki çok güçlü bir matematiksel geçmişiniz varsa, daha sezgisel görünüyor, ancak çoğu insanın tekrar tekrar düşünmesinin kolay olduğunu düşünmüyorum. Özyinelemeli işlevlerin işlevsel programlama paradigmasına merkezi olması nedeniyle, bunun işlevsel dillerin daha az popüler olmasının bir nedeni olabileceğini düşünüyorum.

Dilin popülerliğine bir geri bildirim etkisi de vardır. Programlamaya başladığımda grafik efektleri ve oyunları nasıl programlayacağımı bilmek istedim. Biraz BBC BASIC ve daha sonra QBASIC öğrendikten sonra, doğal olarak demo sahnesi ve oyun programcıları tarafından kullanılan en yaygın dillerin ne olduğunu araştırdım ve C++ ve x86 Assembly öğrenmeye başladılar. Günümüzde bazı yeni programcılar web uygulamalarının nasıl üretileceğini bilmek isteyebilir ve bu yüzden PHP, Ruby veya C # öğrenmeye yönelecektir.) Kendini motive eden yeni başlayan programcılar için çok az uygulama alanı vardır. X gibi bir şeyi programlamayı öğrenmek için en iyi dil ne 'Ocaml' olacaktır.

Ocaml'in sınırlı popülaritesi (olgun kütüphanelerin, hata ayıklayıcıların, IDE'lerin vb. Eksikliği) için verilen pratik nedenlerin çoğu, Microsoft'un birinci sınıf .NET dili olarak F # için resmi desteği ile ele alınmaktadır. F # 'ın fonksiyonel programlama için daha fazla popülerlik sağlayıp sağlamadığını görmek ilginç olacaktır.

6
mattnewport

Sorunun özünün siyaset olduğuna inanıyorum. Ocaml geliştiricileri temel olarak araştırmayla ilgileniyorlar ve zengin bir kütüphane sağlamak ve sürdürmek için kaynaklara sahip değiller. Bununla birlikte, ürünün bu kaynaklara sahip olan topluluğa kontrolünü serbest bırakmak istemiyorlar, sonuçta bu sorunu çözmek için yapılan birçok girişim, üçüncü taraf kütüphanelerinin var olmayan işbirliğine ve finansmanına dayanıyordu ve bu girişimler başarısız oldu. Ocaml geliştiricileri tutumlarını değiştirmedikçe, piller aynı nedenden dolayı 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 olan bağımlılığı en aza indirin. Bir üçüncü taraf öğesi yararlı olduğunda, mümkünse, kaynak kodlarını 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, böylece onlar üzerinde bazı kontrollerimiz olur. Kontrol biraz yanıltıcıdır (en azından Dypgen çok karmaşık olduğundan, onu koruyabileceğimiz pek olası değildir, ancak en azından işe yaradığını düşündüğümüz bir kopyamız var :)

Pilleri kullanmam çünkü lisans kısıtlayıcıdır, bu yüzden kaynağı kopyalayamıyorum ve tek başına bir ürün olarak uzun vadede uygulanabilirliğine inanmıyorum: kullanabilmemin tek yolu, doğrudan Ocaml'ın standart dağıtımına dahil edilmiştir.

C++ dünyasında, sadece Boost'u kullanmayı düşünebilirim: Standardın bir parçası olmayan bir üçüncü taraf kütüphanesi olmasına rağmen, bu kadar ağır topluluk desteğine sahiptir ve aslında Standartlar geliştirme süreci ile mükemmel bir şekilde senkronize edilmiştir. Boost'da geliştirilen ve test edilen fikirler, standartlaştırılabilen mevcut uygulama türü haline gelir ve standartlar süreci, toplumun katılımına izin verecek kadar açıktır.

Ocaml, sahip olduğu popülariteyi çok iyi bir ürün olduğu için elde etti, ancak bu, ana akım bir dil olmasına izin vermek için yeterli değil. Java kabuksuzdur, milyarlarca dolarlık pazarlama ve kütüphane geliştirme ile popüler hale getirildi, ancak sonunda hayatta kalmak için topluluğa bırakılmak zorunda kaldı.

6
Yttrill

Çok çeşitli projeler için hem ML hem de C kodlamasından keyif aldım. Gömülü projelerde ML'yi kullanmamı engelleyen şey (çoğu gerçek zamanlı kısıtlamaları olan ve doğrulama gerektiren) çöp toplamadır.

bölgeleri (bkz. MLKit ) ile bellek yönetimi ile ilgili araştırmalar vardır, ancak bunları düzgün bir şekilde kullanmak için gereken uygulamaların ve eğitimin karmaşıklığı (ve ilgili riskler) bunları kullanmak için bir engel olmuştur.

5
Doug Currie

@Jrockway'in söylediği gibi parayla ilgili ise, F # 'ın Java veya C # gibi popülerlik kazanıp kazanmayacağını göreceğiz.

Benim için geliştiriciler, bir şeyler yapmanın fonksiyonel yolundan rahatsız hissetmiyorlar (bu, yaklaşık 10 kişinin neredeyse 100 kişi arasında fonksiyonel programlamayı bildiğini söylediği 2009 teknik günlerindeki F # oturumundan).

Bu yıl OCAML'ye başladım, ellerimi fonksiyonel programlama ile hiç kirletmedim, ama şimdi her zaman OCAML'den ve problemleri çözmenin fonksiyonel yolundan yeni şeyler öğreniyorum, (ama C #'dan vazgeçeceğimi söyleyemem. OCAML kullanmak :)).

3
0xFF

IMHO, sanırım OCaml'ın büyük bir sorunu dilde değil (harika) ama onu geliştiren insanlarda ve sonuç olarak lisansı:

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

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

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

Kısacası, OCaml'ı kullanmam, çünkü gerçekten iyi bir bilgisayar korsanı olmadan GERÇEKTEN açık kaynak lisansına ve GERÇEKTEN açık kaynak davranışına sahip bir topluluğa sahip bir OCaml derleyici oluşturmadan daha iyi bir yere gitmediğini görmüyorum.

3
Patrizio Rullo

Belki de F # popüler olur.

2
tuinstoel

C-> ocaml'ın c-> LISP'den daha büyük bir zihinsel geçiş olması yardımcı olmaz. Ocaml birkaç kez düşündüm ve her zaman maliyet/fayda sadece benim için orada olmadığını bulundu, bu yüzden tekrar bir kenara koyun. Sert görünmesini sağlayan yapılar değildi, aslında gerçekten düzgün görünüyordu. '!' İç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 kolay c.

2
Kim Reece

Bir dilin gerçek zamanlı gömülü sistemlerde kullanılmasını istiyorsanız, işaretçiler gerekir ve bir GC'yi karşılayamazsınız.

2

Bence asıl sebep OCaml'ı çok az geliştiricinin bilmesi.

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

1
Chris

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

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

0
LB40