Kendi programlama dilimi oluşturmak ne zaman makul olur?

Uzun vadede kendi dilimi yaratmanın daha iyi olduğu yerlerde katil uygulamalar, algoritmik problem sınıfları vb. Var mı?

Not: Tabii ki, yeni bir programlama dili ve bir derleyici demek istiyorum, mevcut bir dil için yeni bir derleyici değil.

EDIT : Cevaplar için teşekkürler. Bir DSL oluşturmanın kesinlikle gerekli olmadığı durumlarda veya DSL'in iyi bir fikir olabileceği durumlar için bazı örnekler verebilir misiniz?

Bir kişinin eğitim amaçlı olarak kendi dilini yazması kesinlikle önemlidir. Dil tasarımı programlama ve derleyici tasarımı hakkında bilgi edinmek. Fakat gerçek dünyadaki kullanımlar çok az ve çok uzaktır.

Kendi dilinizi yazarken:

• Probleminize muazzam miktarda karmaşıklık eklemek
• Yeni dil ve derleyiciyi yazmaya ve sürdürmeye önemli miktarda çalışma ekleme

Dolayısıyla, projeniz için kendi dilinizi yazmayı planlıyorsanız, o zaman diğer dillerin sağladığı özelliklerin yukarıdaki maliyetleri dengelemesi gerekmiyor.

Örneğin, oyun geliştirme al. Genellikle oyunlarında veya kodlama dillerinde mini dillere ihtiyaç duyarlar. Bu dilleri, gerçekleşen oyun içi olayların büyük bir bölümünü çıkarmak için kullanıyorlar. Bununla birlikte, bu durumda bile, neredeyse her zaman mevcut kodlama dillerini seçer ve onları ihtiyaçlarına göre uyarlar.

VB derleyicisinin eski geliştiricisi Paul Vick'i teklif edeyim ve şimdi Proje Oslo ve M dili üzerinde çalışıyorum:

Yeni bir dil inşa etmek, büyük ölçüde varolan bir dili temel alan bir dil oluşturmak için bile şaşırtıcı derecede şaşırtıcı. Yine de pek çok programcı “hey, dilleri kullanıyorum, bu ne kadar zor olabilir?” Diye düşünüyor ve devam ediyor. … Muhtemelen bunların% 98'inden fazlası hiç bir zaman çekiş kazanamamaktadır, ancak Tanrı iyimserleri kutsar çünkü onlar olmadan başarılı olan dillerin% 2'sini asla alamazdık. Şahsen, C # ve Java, Ruby ve Python gibi dilleri alabilmemiz için asla bitmeyen dillere harcanan milyonlarca dolar ve saati feda etmeye hazırım.

Dolayısıyla, yeni bir dille gelmenin kötü bir fikir olduğu gerçeği, insanları yeni DSL'ler geliştirmekten caydırmamalı, onları sadece duraklatmalı ve umarım biraz alçakgönüllülük vermelidir. Sanırım, anahtar küçükten başlamak ve küçük kalmak.

DSL: Kesinlikle kötü bir fikir!

Ne zaman makul olur?

Hissettiğin zaman!

Temelde şunu söyleyen keskin görüşleri olan bu insanları dinlemeyin:

"Yapmayın çünkü çok zor ve X dili bulabileceğiniz herhangi bir dilden daha iyi".

Mesele şu ki, DSL oluşturmak her zaman olur. Çerçeve bir DSL'dir. Bir makro bir DSL'dir. Programınız için her fonksiyon yazışınızda, bu DSL'in bir parçasıdır. Elbette, dilbilgisi sınırları dahilinde, ancak kelime hazinesi bir dilin parçası. Bu yüzden endüstriler genellikle kendi yerellerini yaratırlar: daha verimli!

"Yapmayın" doğru cevap olsaydı, hepimiz COBOL ve Fortran yazardık.

Kendi dilinizi yazmayı düşünüyorsanız, Martin Fowler'in yaklaşmakta olan DSL kitabının bölümlerini okumak isteyebilirsiniz .

Muazzam bir öğrenme deneyimi olmasının dışında sıfırdan bir dil oluşturmak için bir iş vakası düşünemiyorum.

Düzenleme: DSL'ler için birçok iş vakası vardır, ancak buradaki anahtar taşınmamak ve Basit Tutmaktır.

Anahtar soruların "Hangi sorunu çözmeye çalışıyorum?" Olduğunu düşünüyorum. ve "Yatırım Getirisini kim alır?"

Kendi becerilerinizi ve deneyiminizi geliştirmeye çalışıyorsanız, o zaman tam hızda ilerleyin, ancak başkasının sorununu çözmesi gereken bir üretim sisteminde değil.

Yeni bir dil istemenin asıl nedeni, kodunuzda, mevcut dillerin iyi işleyemediği kalıpları keşfetmeye başlamanızdır. Ancak kendi dilinizi oluştururken bir sürü sorun var. Mevcut diller için hazırlanmış tüm kütüphaneleri ve çerçeveleri gözden kaçırmış olacaksınız. Yeni dili tasarlamak ve uygulamak için çok zaman harcayacaksınız, bu da gerçek programlama işinde zaman harcamanıza gerek kalmayacak. Diğer geliştiricileri dilinizi kullanmaları gerektiğine ikna etmek için çok çaba harcayacaksınız. Ayrıca, yeni geliştiricilerin işe alımı ve eğitimi konusunda zorlanacaksınız.

Neden Lisp gibi yeni bir dil keşfederken dili genişletmenize izin veren bir dilde yazmıyorsunuz? Ardından, yerleşik bir dilin tüm avantajlarıyla yeni bir dilin gücünü elde edersiniz.

Bunun bir nedeni, dil tasarımı ve derleyici oluşturma hakkında bilgi edinmek için bir deney olarak oluşturmak olabilir.

Başka bir neden, bir üçüncü taraf API ekleme seçeneğiniz olmadığında, bir uygulamaya komut dosyası dili oluşturmak olabilir.

Sana programlayabilir sanmıyorum olmadan 's iyi ne yaptığını o' s gerçekleştirmek ve sorunları anlamak için, bu yüzden yeni bir dil yaratma.

• Dil nedir
  Kelime, sözdizimi ve anlambilim.

VB, Java, C #, vs. gibi hazır bir dil sadece temel bir dildir. Buna sınıflar, yöntemler vb. Eklerken, kelime ve anlambilim eklediniz. Dilleri uygulamak için birçok yol vardır - ayrıştırma ve çeviri, ayrıştırma ve yorumlama, varolan bir dilin üstündeki makrolar, varolan bir dile sınıflar ve yöntemler ekleme.

• Bir dilin ne yapmasını istersiniz?
  Sorunları tam olarak ifade etmek için iyi olun.

Bunu yapıp yapmadığını nasıl bildin? Kullandığım ölçü düzenleme sayısıdır . Bir cümle şartı A gelirse, şartı kodda uygulamaya devam ederim. İşim bittiğinde ve tüm hataları çözdüğümde, kodu kontrol ediyorum ve kod deposu bana yaptığım değişikliklerin bir listesini veriyor, B ne kadar küçükse, dil o kadar iyi. Gerçek ve muhtemel ihtiyaçların alanı üzerinden ortalama alınan bu ölçü, dilin ne kadar "etki alanına özgü" olduğunu gösterir.

• Özlü neden iyidir?
  Çünkü hataları en aza indirir.

N gereksinimini uygulamak için N kodu değişiklikleri alırsa ve bazen hata yaparsanız, girdiğiniz hataların sayısı kabaca N ile orantılıdır. N = 1 olduğu sınırda, denemeye gerek kalmadan hata bildirmek neredeyse imkansızdır .

Bunun, bugünlerde gördüğümüz "kod şişirme" ye doğrudan bir meydan okuma olduğunu unutmayın.

EKLENDİ: Bir örnek isteğinize cevaben, diferansiyel uygulama bölümüne bakınız . Hızlıca anlaşılabileceğini söyleyemem, ancak UI kodunu önemli ölçüde azaltır.

(Orijinal) sorunuzdaki kelimeyi kullanmak her zaman "uygulanabilir" dir, ancak var olan iyi desteklenmiş ve olgun dillerin ve çerçevelerin bolluğu göz önüne alındığında çok nadiren kullanışsız ve çok nadiren uygun değildir.

Bununla birlikte, ilginç bir entelektüel zorluktur.

Sadece ekibinizin ana işi programlama dilleri ise.

Bir finansal şirkette oluşturulan bir programlama dili üzerinde çalıştım.

Açıkçası, mimarın kendisi için bu büyük bir zorluktu ve kendi becerilerini geliştirdi.

Kaçınılmaz olarak, dil C # veya Java gibi bir şeyin yapabileceği oranın yakınında hiçbir yerde büyüyemez veya gelişemezdi - bunu yapmaya adanmış ekipleri var.

Dil, kısa bir süre sonra kimsenin başkasının evcil hayvan projesini geliştirme görevini üstlenmek istemediği için durdu.

Orijinal mimar ayrıldı. Dil 10 yıl sonra soldu ve öldü.

Bu 10 yıl, çıkmaz bir dilde çalışmak için talihsizlik yaşayan herkes için cehennemdi.

Öyleyse devam et, kendi dilini oluştur ama lütfen başka birinden gerçekten kullanmasını isteme. Lütfen başkalarının bunun için size teşekkür etmesini beklemeyin.

Dilleri tasarlamak eğlenceli olabilir. Fakat kendinizi programlama dillerine çevirmek zorunda değilsiniz.

Orta derecede karmaşık bir uygulama geliştirirsem, karmaşık tekrarlayan görevlerin yürütülmesini kolaylaştırmak için bir tür makro / komut dosyası dili eklemeyi severim. Çoğu kullanıcı bu işlevi kullanmaz, ancak bunu kullanan az kişi çok minnettardır. Ayrıca, destek çalışanlarının müşteri sorunlarını çözmelerine yardımcı olmalarının değerli olduğunu düşünüyorum.

Becerilerinizi geliştirmek ve öğrenmek için yapılırsa tamamen mantıklı.

Bunun dışında, soruyu sormak zorunda kalırsan, o zaman olmaz. Belirli bir algoritma sınıfı veya belirli bir problem alanı ile mevcut dillerden daha iyi bir şekilde başa çıkıp çıkamayacağınızı anlamaya çalışıyorsanız, öncelikle ele aldığınız alanda uzman olmanız gerekir. Becerileriniz ve deneyimleriniz size söylerken uygun olduğunu anlayacaksınız.

Ve bu konuda da yanılıyor olabilirsiniz, ancak sizi ikna etmek için başka bir uzmana ihtiyacınız olacak (ya da sizi düşündüğünüz uzman olmadığınızı göstermek için). Burada bulacağınız kadar basit bir Q ve A olmayan, canlı bir tartışma.

Kendi kendine eğitim amaçları dışında, bugün kendi dilinizi oluşturmanıza gerek olmadığını iddia ediyorum . Her durumda. Hiç. Ne yapmak istediğinize bakmaksızın, ihtiyaçlarınıza göre uyarlayabileceğiniz / adapte edebileceğiniz mevcut dillerden oluşan tekne yükleri var.

Bu kesinlikle duruma bağlı. Nosklo'nun dediği gibi - İyi bir fikriniz, yepyeni bir konseptiniz veya bunun gibi bir şey varsa, bunu yapmanızı şiddetle tavsiye ederim.

Genel olarak, yerleşik teknolojiye güvenmeyi öneriyorum.

Ancak kendi "dilinizi" oluşturmakla ilgileniyorsanız, şunlara bakmalısınız: YACC & Lex

Sadece, "Kare tekerleği yeniden yaratma" karşıtı modelinde kendinizi yakalamayın.

Yani, zaten yapılanları yeniden yaratıyorsunuz, yalnızca orijinallerden daha fakir.

Wouter, yeni bir fikir için yeni bir dil yarattığı için biliniyordu. Çalışmalarından ilham alabilirsiniz: Wouter'in programlama dili sayfası .

Kendi dilinizi ne zaman oluşturabilirsiniz?

İstediğiniz zaman, büyük bir hobi projesi olarak.

Etki alanına özgü bir dil için. Bunlar oldukça ayrıntılı olabilir; Etkileşimli Kurgu (veya metin macerası) topluluğunda neler olup bittiğini arşivi inceleyerek inceleyin .

Hedefleriniz çok iddialı olduğunda ve Paul Graham'ın Arc projesi gibi gerçek bir ilerleme kaydedebileceğinizi düşünüyorsunuz .

Ayrıca, yeterli düzeyde uyarlanabilir herhangi bir dilde (belki de C ++, kesinlikle Ortak Lisp) düşük seviyeli yapılar geliştirme sürecinde.

Ne zaman olmasını istediğin gibi kaçınmalıyım, umarım, veba gibi kaçmak gibi bir klişeden kaçınırsın?

Gerçek projeler için sürekli gelişmenin temeli olunca. Her zaman, ucuza ticari olarak temin edilebilir olanların arkasında ciddi bir gecikme yaşayacak ve daha fazla gelişmeyi engelleyecektir. COBOL versiyonuna sahip bir şirkette çalıştım ve hiçbir zaman kendi dilini tutan başka bir şirkette çalışmak istemiyorum. COBOL'un diğer versiyonlarının aynı problemlerle karşılaştığımızda daha iyi yetenekler ve daha iyi araçlar elde etmesini izledik. (Bir daha asla COBOL ile çalışmak istemiyorum, ama bu başka bir hikaye.)

Kendi dilinizi oluşturabileceğiniz durumlar buna dahil değildir. Hobi projeleri gerçek gelişim için kullanılmaz. Arc gibi bir şey başarılı olacak (ve birçok uygulama ve daha fazla evrim ve gelişme elde edecek) veya başarısız olacak (ve başka hiç kimse kullanmayacak). Etki alanına özgü küçük bir dil, projenin yalnızca bir parçasıdır ve küçük olduğundan zamanla geliştirilebilir. Bireysel oyunlar yazmak için bir metin macera dili kullanılır ve bu oyunlar hobi projeleri olmasının yanı sıra, neredeyse hiç gelişim için kullanılmazlar.

Benim bakış açım, DSL’lerin genellikle “zayıf bir fikir” olduğu ve uzun vadede standart bir dil kullanmak ve etki alanına özgü ihtiyaçlarınızı “DSL olmayan” bir kütüphane olarak geliştirmek daha verimli.

Ancak, ihtiyaçlarınızın şirketiniz için bir DSL (sadece biraz değiştirilmiş bir gcc veya lisp uygulaması değil) tercih edilmesinin yeterince özel olduğu ortaya çıkabilir. Birçok şirket, kendi dilini yazmadan / sürdürmeden, ne yaptıklarını hedef alan mevcut dillerden yararlanırlar. Örneğin, PHP'nin hoş bir şekilde bırakıldığını duydum; Lua bir drop-in çevresinde tasarlandı, ModelView Python'u kullanıyor ve AutoCAD'in komut dosyası olarak AutoLISP'i var.

Mevcut araçlardan yararlanabiliyorsanız, kendi programlama dilinizi yazarken yanlış bir şey yoktur. Bugünün dünyasında bu, onu mevcut bir dile (Java veya C # gibi) kullanılabilen bir sözdiziminde tanımladığınız veya mevcut bir dilde kod üreten küçük bir dönüşüm sistemi (makro genişletici) yazdığınız anlamına gelir.

Makine koduna kadar gitmek bir sürü çarkı yeniden icat ediyor ...

DSL için çok iyi bir neden, etki alanı verilerini özlü bir şekilde temsil etmektir. Bu, etki alanı uzmanlarının başkaları arasında gezinmek yerine doğrudan verilerle çalışmasına olanak tanır. İşin püf noktası, sonuçta elde edilen programların işlenmesi kolay bir formda olmasıdır.

Genel olarak cevap, büyük bir NO olacaktır. Dışarıdaki yüzlerce dilden, genellikle sizin probleminize uygun bir dil var.

Ancak, yeni bir dil geliştirmenin rasyonel bir seçenek olduğu durumlar vardır: -

• Rakiplerinizden biri şimdi ana gelişim platformlarınızdan birine sahip olduğunda. Googles’in Java’ya olan güvenini ve “go” ’yu geliştirmelerini düşünüyorum (bordroda bugüne kadarki en başarılı dilin yazarı olsaydı!).
• Yeni bir platform için bir ton kod yazmanız gerektiğinde ve mevcut diller ayrıntılı ve yanlıştır - örneğin web geliştirme için php.
• Daha önce hiç karşılaşılmayan ölçek ve paralellik problemleriyle karşılaştığınızda, hiç kimse daha önce bu kadar çok veriyi işlemek için bu kadar donanıma sahip değildi - örneğin Scala ve (bir dereceye kadar GO).

Hangi dilin iyi olabileceği kompozisyon oluşturma veya aynı bileşenleri farklı şekillerde bir araya getirme.

Eğer etki alanı probleminiz sadece bir grup ortogonal şalter ayarlamanızı gerektiriyorsa, bir dil muhtemelen formların üstüne, bir grafik kullanıcı arayüzü veya düz bir text-config eklemez. dosya. (Burada anahtarla dolu bir dosyanın değer çiftlerinin bir "dil" ile kastettiğiniz olmadığını farz ediyorum .)

OTOH, eğer yapılandırmanız gerçek dil gibiyse, örneğin. fiiller ve isimler, herhangi bir karmaşıklık derecesine göre birçok farklı (ve yeni) kombinasyonda bir araya getirilebilir, daha sonra bir dil neredeyse kaçınılmaz hale gelir, çünkü ne istediğinizi başka bir yöntemle belirtmeye çalışırken bir arada patlama.

Öğrenme alıştırmaları bir yana, kendi programlama dilinizi yalnızca başka dilleri, belirli sorun alanınızı ve mevcut dillerin bu sorun alanını ele alma biçimini anladığınızda ve bu anlayışın yeni bir dilin makul olduğunu bildiğiniz kadar iyice anladığınızda oluşturması makul olacaktır. soruyu sormaya gerek kalmadan çözüm.

Bunu en son hobi projesinde yapmaya başladığımda, sözdiziminin neye benzemesini istediğimi belirlemeye başladım ve yarı yarıya fark ettim ki prolog yeniden icat ediyordum. Bir dil icat etmeniz gerektiğini düşündüğünüzde uygun olabilecek diğer diller lisp, lua veya Haskell gibi şeylerdir. Temel olarak, kolejde görmezden geldiğiniz tüm diller, çünkü onların asla işe yaramayacaklarını düşündünüz.

Bunun bir nedeni, daha önce belirtildiği gibi eğitim amaçlıdır. Fakat dahası var. Örneğin, gibi birçok araştırma dil vardır Sing#üzerinde Singularity işletim sistemi ve BitCüzerinde Coyotos mevcut diller (dil düzeyinde örnek doğrulama için) gerekli özellikleri sunmuyor çünkü tasarlanmıştır.

Tom Van Cutsem geçenlerde bu soruya bir cevap yazdı:

http://soft.vub.ac.be/~tvcutsem/whypls.html

Madde işareti özeti (o sayfadan):

• Sözdizimsel soyutlama mekanizması olarak dil: başka bir dilin yerleşik soyutlama mekanizmalarını kullanarak soyutlanamayan tekrarlayan "kazan plakası" kodunu azaltmak.
• Düşünce şekli olarak dil: birinin yazılımı nasıl yapılandırması gerektiğine ilişkin bir paradigma kaymasına neden olmak ("en az direnç yolunu" değiştirmek).
• Basitleştirici olarak dil: Mevcut bir paradigmayı yalnızca temel kısımlarına indirgemek, çoğunlukla anlayışı ve içgörüyü arttırmak.
• Yasa uygulayıcısı olarak dil: önemli mülkleri veya değişmezleri zorlamak, muhtemelen programlardan daha faydalı mülkleri çıkarmayı kolaylaştırmak için.

Muhtemelen asla.

Lua, dili başka bir dilde gömmek istiyorsanız, alabileceğiniz en iyi seçimdir.

Küçük Alan Adı Özel Dilleri şu anda içinde ve bazı uygulamalarda mantıklı.

Bunun dışında, nedenler çoğunlukla akademik.

Gerekmediğinde bir dil oluşturmak, onu geliştirmek ve sürdürmek konusundaki karmaşıklıktan ötürü yapılacak kötü bir şey. Sadece o programa özgü bir tür kodlama dili tanıtan birçok proje gördüm ve bu temel şeyin gelişimini büyük miktarda yavaşlatan şeydi. İyi örnekler örneğin Phantom, AutoHotKey, AutoIt gibi otomasyon dilleridir. Bu araçlar, Lua gibi iyi bilinen bir yayılma dili kullanmışlarsa IMO daha iyi olurdu.

'Düzenlemeniz' oldukça farklı bir soru gibi görünüyor (insanların "yeni, genel amaçlı bir programlama dili ne zaman yapmalıyım" olarak anladığı orijinal soru yerine "ne zaman bir DSL yapmalıyım?"). İnsanların 'orijinal' soruyu tam olarak yanıtladığı görülüyor, ancak DSL'nin ne zaman kullanılacağına dair belirli kriterler veren çok az cevap var. Bu yüzden bir kontrol listesi öneriyorum:

1. Kullanıcı tabanınız birkaç kişiden daha büyüktür, genellikle teknik değildir ve / veya sisteme erişimi kısıtlıdır (bu nedenle, mevcut bir genel amaçlı dili öğrenme / kullanmalarını beklemenin mantıksız olması gerekir). Geliştirme ekibinizde veya yazılım organizasyonunuz içindeyse, bunun yerine "sadece bir senaryo yaz" diyebilirsiniz.
2. Kullanıcılarınızın yeterince sık, yeterince çeşitli ve değişen davranış gerektiren davranışlarla kullanmaları gerekir (yani, yalnızca sizin tarafınızdan tutulan sabit bir işlev kütüphanesi sağlayamazsınız)
3. Kullanıcıların belirleyebileceği davranışlar veri olarak belirtmek için çok karmaşık (örneğin, bir veritabanı tablosu veya kullanıcı girişi matrisi veya bir görev listesi veya anahtar / değer toplama kullanarak bunu başaramazsınız ... dikkatlice düşünün çünkü bunlarla çok karmaşıklık elde edebilirsiniz). DSL yerine veri girişini veya konfigürasyonunu kullanarak bu davranışı başarabilirseniz, muhtemelen daha az çalışacağından muhtemelen yapmalısınız. Bir tür şartlılık veya bir araya getirilebilirlik / birlikte zincirleme veya birkaç farklı soyutlamayı modelleme, ihtiyacınız olan davranışın düz veri / yapılandırma için çok karmaşık olduğunun işareti olabilir
4. Ancak davranış hala özlü bir DSL'de belirtebileceğiniz şekilde sınırlandırılmıştır. Büyük bir tehlike 'platformun şişmesi' şeklindedir, örneğin kullanıcılar "ekleyebilir misin ...?" İnternete bağlanması veya dosya sisteminden okuyup yazmaları veya işlemleri açıp kapatmaları gerekiyorsa, bu artık bir DSL değildir. (Bunun gerçek olduğunu gördüm ... kullanıcılar küçük python çağrılarını yerleştirmeye, yavaş yavaş python komut dosyalarına büyümeye ve sonunda tüm limitleri / modülerliği / performansı yok etmeye izin verdiler)

Bunların tümü doğruysa, DSL uygun olabilir.

Uzun vadede kendi dilimi yaratmanın daha iyi olduğu yerlerde katil uygulamalar, algoritmik problem sınıfları vb. Var mı?

Değişir.

Beynimizi alalım. HERHANGİ bir programlama diliyle (en azından şimdi) sınırlarla karşılaştığımız karmaşık bir karmaşa gibi görünüyor. Bu yüzden belki de beynimizi sanallaştırmak için başka yaklaşımlara ve oradaki diğer anlambilim ve sözdizimlerine ihtiyacımız var.

Genel olarak konuşursak, belirli bir senaryo için “daha ​​iyi” bir dil de içeren başka stratejilere yol açabilecek karmaşık konular var.