Bir programlama dili tasarlayacak olsanız, nasıl yapardınız? Hangi özellikleri koyardınız? Ne bırakacaktın? Statik veya dinamik olarak yazılmış? Güçlü veya zayıf yazılan? Derlenmiş veya yorumlanmış? Cevaplarını doğrula.

• Kesinlikle işlevsel programlama dillerinin yakalanacağını düşünüyorum , bu yüzden dilim işlevsel olacak. İşlevsel Programlama ile Etkileri Etkilemeye Bakın

• Sanırım CPU'ların yakında çekirdek çekirdeği olacak, ve o iş parçacığı idare edecek bir cehennem olacak. Dolayısıyla Aktör Modeli , iplik yerine bir zorunluluktur. Erlang'ı görün - eşzamanlı bir dünya için yazılım

• Ayrıca OOP'nin başarısız olduğunu düşünüyorum, nesneler arasındaki iletişimin asenkronize olduğu varsayıldı . Bence Yani ihtiyacımız mesajı geçmesini değişmez mesajlarla. Gönder ve Unut. Aktör modelinde olduğu gibi. Bkz Nesne Tabanlı Programlama: Yanlış Path?

• Statik yazmanın iyi olacağını düşünüyorum, bu yüzden geliştirme döngüsünde daha önce hatalar yakalanır. Ancak Haskell'de olduğu gibi tip çıkarımı kullanırdım , böylece geliştiricinin C, C # ve Java'daki kodun her yerine türü yazmasına gerek kalmaz. Büyük İyi Bir Haskell Öğrenin See See

• Ben de bir tasarım olacaktır muhteşem arayüz kütüphanesi ile, bildirim düzeni WPF ve Android'de olduğu gibi. Ancak, İşlevsel Reaktif Programlamadaki gibi olmasını isterim .

Bu yüzden dilim Erlang'daki eşzamanlılık gibi olacak ama Haskell ve WPF.NET'teki gibi bir GUI çerçevesi yazarak.

Not: Bu yayındaki özellikleri tanımlamak için C benzeri bir sözdizimi kullandım, ancak CAPS olan tüm anahtar kelimeler gibi saçma bir şey olmadığı sürece sözdiziminin kendisi konusunda seçici değilim.

1. Yazma sistemi

Bir dilde isteyeceğim bir numaralı özellik, isteğe bağlı dinamik yazma ile statik yazma. Bunun nedeni, statik yazmanın a) geç değil erken hataları yakalamanıza izin vermesidir ve b) çoğu kod, dilin ayrım yapıp yapmamasına rağmen, statik olarak yazılmıştır. Ancak, dinamik yazmanın son derece yararlı olduğu birkaç kullanım durumu vardır. Örneğin, bir dosyadan veri okurken, genellikle farklı tür alanlara sahip olursunuz ve dinamik yazma, heterojen kapları kolaylaştırır. Bu yüzden, ideal dilin şöyle bir şeyi olurdu:

//variable declarations
int anInt = 42 //anInt is now irrevocably an integer and assigning another type to it is an error
vartype aVariable = 42 //aVariable is currently an integer, but any type can be assigned to it in the future

//function definitions
int countElements(Collection c)
{
  return c.count();
} 

//c HAS to be a collection, since countElements doesn't make sense otherwise

void addToCollection(Collection& c, vartype v) 
{
  c.append(v)
}

//c is passed by reference here

2. Derlenmiş ve Yorumlanan

Dilin vaktinden önce derlenmesini ya da JIT'nin derlenmesini, ancak tamamen yorumlanmamasını, bunun sebebi olarak hızlanmasını istiyorum. Bu , 1 numaralı noktaya bağlanır , çünkü bir optimizasyon derleyici / jitter, statik olarak yazılan kodu optimize etmek için çok daha kolay bir zamana sahip olacaktır ve dinamik olarak yazılmış kod, olduğu gibi bırakılabilir.

3. Kapaklar

Dil, işlevsel programlama yapılarını desteklemeli ve işlevler birinci sınıf nesneler olmalıdır.

4. Nesneye yönelik

Dil, nesne yönelimli kod yazmanıza izin vermelidir, ancak basit zorunlu koda da izin verilmelidir. yani, şöyle bir merhaba dünya programı yazmak mümkün olmalıdır:

int main(string<> args=null)
{
  printf("hello, world"); 
  return 0;
}

// this code also demonstrates two other features,
// default arguments for functions (not explained further)
// and immutable lists like string<> (see 6. Built-in datatypes)

5. İsim Alanları

İsim alanları iyi bir şey. Küresel isim alanına çok az şey girmeli. Ama eğer gerekir yapabilirsiniz (C ++ ala) genel ad şeyler koymak.

6. Yerleşik veri türleri

Dil, yerleşik veri türleri olarak aşağıdaki yapılara sahip olmalıdır:

• Bir intveri türü veya türleri. Yalnızca bir inttür varsa, sınırsız aralığa sahip olmalıdır. Eğer daha fazlası varsa , sınırsız aralık tipi en büyük olan bir hesaplama sonucunu tutabilen en küçük tipe örtülü olarak yukarı doğru olmalıdır .
• floatIEEE 754'e eşdeğer, tek bir dahili ikili tipdouble
• İkili listolarak bağlı bir liste veya her bir elemana işaretçiler içeren bitişik bellek bloğu olarak uygulanan değişken bir tür
• Bir listdizi gibi davranan ancak oluşturulduktan sonra boyutu değiştirilemeyen değişmez bir tür
• Değişken ve değişmez stringtürler, varsayılanı değişmezdir.
• Değişken olan ve değişmeyen anahtarları ve değişken ve / veya değişmez değerleri tutan A mapveya dicttürü.
• Yerleşik koleksiyon türleri varsayılan olarak homojen olmalıdır, ancak vartypegerekirse d olabilir
• Bir booleantür
• Herhangi bir tür değişkene atanabilecek A nullveya nonetürü.
• Değişken ve değişmez settipler
• decimalOndalık kayan nokta değişkenleri uygulayan bir tür
• Bir fixedtip, bu takma sabit bir nokta sayısı

decimal, floatVe fixedçeşitleri paylaşmalıdır kesin onları şeffaf geçirilen ve işlevleri döndürülmesini sağlayan (ya miras veya ördek yazarak yoluyla) aynı kamu arayüzü. Ana tip çağrılabilir real.

7. Değere ve referansa göre arayın

İşlevleri hem değer hem de referans olarak çağırabiliyor olmalısınız, varsayılan değerdir (yani, argümanın bir kopyası işlevde yapılır ve çalıştırılır).

8. İşaretçiler

Dil, işaretçilere sahip olmalı ve işaretçi aritmetiğine izin vermelidir. İşaretçiler yalnızca statik olarak yazılabilir (a olan kabustan kaçınmak için void*). vartypeişaretçiler açıkça reddedilir. İşaretçilere ve işaretçi aritmetiğine sahip olmak, dilin bir sistem programlama dili olarak ciddi şekilde kullanılmasını sağlar.

9. Satır içi montaj

8 ile bağlantılı olarak , dil, gerekli olduğu durumlarda satır içi derlemede dil koduna izin vermelidir.

10. Güvenlik

Dil, istisnasız kullanımı vb. Kullanmak için çoğunlukla güvenli olmalıdır. İşaretçi aritmetik ve satır içi derleme, açıkça güvensiz olarak işaretlenmiş kod bölümlerine ayrılabilir. Güvenli olmayan kod izin verilir, ancak kesinlikle önerilmez.

11. Tanımlanmamış davranış

Dil standardı, açıkça güvensiz olarak işaretlenmiş kod dışındaki tüm koşullar altında programın nasıl davranacağını belirtmelidir , yani güvensiz blokların dışında tanımsız bir davranış olmamalıdır. Bu, dilin uygulanabilir bir uygulama geliştirme dili olarak kullanılmasına izin verirken, yine de, içine bir işletim sistemi yazmanıza izin verir.

Şu an düşünebildiğim tek şey bu, ancak daha fazla şey düşündüğüm gibi gönderiyi düzenleyeceğim / güncelleyeceğim.

İşte rüya programlama dilim şöyle gözüküyordu:

• Bazıları bağımlı yazma için destekleyen güçlü bir statik tip sistem.
• İsteğe bağlı dinamik yazma.
• Sayısal Kule a la Lisp, ancak statik olarak yazılmıştır.
• Makrolar a la Lisp.
• Öncelikle, zorunlu programlama (ML ailesi gibi) için temel desteği olan bir İşlevsel Programlama dili.
• Çöp toplama.
• Çıkarım yazın.
• Continuations.
• İsteğe bağlı tembel anlam.
• Tüm kontrol yapıları kütüphane fonksiyonları şeklinde sağlanacaktır. (Bu, son iki özellik kullanılarak mümkün olabilir.)
• Minimal sözdizimi (Lisps kadar değil, Ioke / Seph türünde bir şey)

Bunu C # gibi tasarlardım ama Microsoft beni dövdü. :)

^{_{(Tabi ki benimki daha az düşünülmüş ve amatör olacaktı.)}}

Derlenmiş ya da yorumlanmış olup olmadığını pek umursamıyorum, bu yüzden o parçayı haklı çıkarmaya ihtiyacım yok.

Güçlü statik yazım ile ilgili olarak, bunun neden gerekçe gerektirdiğini bile anlamakta zorlanıyorum. Statik yazım, derleme zamanı sırasında hataları yakalayan bir özelliktir. Dinamik yazma, bu özelliğin eksikliğidir ve hataları çalışma zamanına kadar savunur. Kişisel deneyimime göre, dinamik gönderimin anlamlı olduğu ve faydalı olduğu birkaç kullanım durumum vardı, bu yüzden 4.0'dan önce C # 'da geçirmem gereken konvolüsyonlar kolayca haklı çıkarıldı. C # 4.0 ile artık bunu haklı göstermeme gerek yok çünkü artık dinamik gönderim yapıyoruz.

Ancak, muhtemelen eski C sözdizimine C # gibi dinsel olarak yapışmak yerine yeni bir sözdizimi oluşturacaktım. Switch ifadesi özellikle korkunç, ve aynı zamanda cast sözdizimini de beğenmedim (yanlış yol). Yine de sözdiziminin detayları hakkında büyük bir sıkıntı yaratmıyorum, bu yüzden onu daha ayrıntılı olarak açıklamaya ihtiyacım yok, ancak Visual Basic kadar ayrıntılı istemem.

Başka ne haklı göstermemi istersin?

İşte size koyacağım özelliklerin bir listesi:

Lisp sözdizimi gibi

Lisp tarzı

Artıları :

• Kolayca genişletilebilir sözdizimi. Hiç C'de bir foreach döngüsü uygulamaya çalıştınız mı? Bu tam olarak kolay değil. (Dikkat et, ben yaptım ).
• Homoiconicity. Basitçe(eval "your data files")

Eksileri :

• İç içe cila yazımını okumak genellikle zordur

İşlevsel Programlama

Haskell tarzı

Artıları :

• Kolay eşzamanlılık, tüm kod iş parçacığı güvenlidir.

Eksileri :

• Yan etkilerin saf işlevsel kodda uygulanması zordur, ancak monadların iyi bir iş çıkardığı görülmektedir.

Güçlü dinamik yazma

Python tarzı

Artıları :

• Dinamik yazarak temiz okunabilir kod yapar, Güçlü yazarak yazım hataları ortadan kaldırabilir

Uygulama :

CL'lere benzeyen türlere bağlı olarak fonksiyon aşırı yüklenmesine izin verin defgeneric:

(define (+ (a <int>) (b <int>))
  (ints-add a b))

(define (+ (a <string>) (b <string>))
  (string-concat a b))

(define (+ a b)
  (add-generic a b))

Derlenebilir ve Yorumlanabilir

Artıları :

• Derlenirse performans artışı (genellikle doğru, her zaman değil)

Eksileri :

• Dilde özellikleri sınırlayabilir, llvm olsa iyi bir destek olurdu.

Sistem programlama

C tarzı

Artıları :

• Çok hafif bir kullanıcı yelpazesine hitap ediyor.
• Hepsi aynı dilde yazılmışsa, uygulamalar, çekirdek ve aygıt sürücülerinin etkileşimi daha kolaydır

Eksileri :

• Dildeki soyutlamaları sınırlandırır, dinamik yazma genellikle uygun değildir.

Hijyenik makrolar (CL stili ve Şema stili)

Artıları :

• Dili genişletmek kolaydır, özellikle Lispy ™ sözdizimi ile
• Bunu daha önce söyledim, değil mi?

Eksileri :

• Lispy ™ sözdizimi ile yapılmadıysa çok fazla değil

Bir düşünün, derleme ve sistem programlama biti hariç, bu az çok şema tanımlar. Bu libguile kullanarak ve bu parçaları C'ye yazarak çözülebilir.

Dışarıda oldukça iyi olduğunu düşündüğüm birkaç dil var (C # şu anki favorim). Bu benim fantezi dilim olduğundan, gerçekten olmasını istediğim şey:

• Kick-ass resmi api belgeleri. Java API bu şekilde iyidir ve C # /. NET oldukça iyidir. Ruby / Rails burada oldukça korkunç.
• Kick-ass resmi genel belgeleri (nasıl yapılır, genel kullanımlar, birçok örnek kod). C # /. Net bunun için iyidir.
• Blog tabanlı belgeleyicilerden oluşan büyük bir topluluk ve StackOverflow sorunu, zor noktalardan kurtulmama yardımcı oluyor
• Çok iyi desteklenmiş, iyi belgelenmiş ve güçlü eklentiler / kütüphaneler / uzantılar yelpazesi (Ruby / Rails 'güçlüdür' ancak diğer ikisinin hiçbiri yoktur).
• Oldukça kararlı - mevcut kodu çoğu kez yıllık bazda kırmak için hiçbir şeyi değiştirmemek (size bakmak, Ruby / Rails).
• Çok kararlı değil - dil tasarımındaki ilerlemelere uyum sağlayabiliyor (sana bakmak, c ++)

Derleyici ipuçları

Dil tasarımı hakkında fazla bir şey bilmediğim için benden bıktım, ama bahsettiğim özelliğin başka dillerde ipucu olarak adlandırıldığını düşünüyorum . Derleyici belki ipuçları ?

Bunu bir Perl6 taslağında mı okudum, yoksa o zamanlar çok yüksek miydi bilmiyorum, ama varsayılan olarak her şeyin gevşek olduğu gibi bir dil olduğunu ve otomajik olduğunu hayal ediyorum. Fakat eğer performansı gerçekten arttırmak ve söylemek istiyorsanız, hey, bu değer her zaman bir tamsayıdır ya da asla boş olamaz, ya da bu paralel olabilir ya da bu vatansızdır, bunun gibi şeyler ... Derleyicinin otomatik olarak kasabaya gidebileceği Bu özel olarak işaretlenmiş alanlarda.

E: Ne istediğimi açıklayan veya bunun zaten mevcut olduğu örnekleri gösteren yorumları takdir ediyorum.

Yeni fikirler denemek için:

Dinamik tip bir işlevsel programlama dili yapardım, tüm ifade ifadelerini ve en basit lambda sözdizimini desen eşleştirmesi ile yapmanızı sağlar. Dış kural etkin.

// a view pattern (or Active Pattern in F#)
default = \def val: !!val.Type val def

// usage of the pattern
greet = \name<(default "world") `and` hasType Str>:
  p "Hello, \{name}!"

(p "Enter your name", .input).greet // (, ) is a sequence expression, returning the last value

İşte bir açıklama:

default =Depolama ayarlar \def val, iki bağımsız bir curried işlevi başlar val.Typeaynıdır Type[val], !!dönüştürür boolean ve Boole uygulanabilir, yani valvedef are after it.

f x= f[x]= x.f .f=f[]

ve içinde greetkullanıldı name<(default "world")ve hasType Str>kalıbın default "world"kullanılacağı ve bağlanacağı anlamına gelir name. Varsayılan kalıp, varsayılan bir değer belirtir. andbirlikte iki modeli zincirleyen başka bir kalıptır. defaultiken desen başarısız olamaz hasTypebaşarısız olabilir. Bu durumda, bir istisna atar.

Değişkenler aslında işlevsel olarak geçirilebilecek depolardır ve saklama tabloları kapsam değiştikçe referanslar oluşturulabilir ve tahrip edilebilir.

Hash'ler ve benzeri Lua ve JavaScript'te olduğu gibi olacak.

Derlenmiş bir dil yapacaksam, Java için Haskell benzeri özelliklere sahip bir F # yapacağım. Tamamen işlevsel bir dildir, sözde kod benzeri bloklar yazarak zorunlu programlama yapmak için Alıntı Yapan ve Comp Exprs'ı bir araya getiren bir özellik olması dışında.

Bildiğim tek dilin PHP ve javascript olduğunu ve bir dil tasarlamadan önce gerçekten birkaç şey öğrenmem gerektiğini akılda tutarak:

Sözdizimi: İşlev adları ve argüman sırası hakkında dikkatlice düşünün (örn. PHP'den daha az dağınık olun).

Özellikler: bir dizi var stringbayt dizisi olarak değişkenler üzerinde işlem, ancak metni anlamıyorum fonksiyonları, ve bir dizi textkodlamaların sürü anlamak ve UTF-8 ve diğer baytlı dizeleri üzerinde çalışabilir fonksiyonlar. (Ve text.isValidEncoding(text, encoding)bir bayt dizisinin hatalı biçimlendirilip biçimlendirilmediğini ve metin olarak ele alınma konusunda güvensiz olup olmadığını söyleyen bir işlevi olan , dilin içine yerleştirilmiş kodlama akıl yürütme kontrollerini yapın .

Güçlü statik yazma fikrini sevdiğimi düşünüyorum, ancak hiç kullanmadım, bu yüzden gerçekten söyleyemem.

Bir programlama dili tasarlamadan önce şu soruya iyi bir cevap bulurum: neden başka bir programlama diline ihtiyacımız var? Bu yazı sırasında Rosetta Kodu 344 dilde listeler. Bunların hiçbiri benim ihtiyaçlarıma cevap vermezse, neden başlangıç ​​noktasını (en yakın gelen diller) belirlemediğinin ve buna ne ekleneceğine ilişkin özellikler.

Piyangoyu kazanırsam ve bir nedenden ötürü yapacak daha iyi bir şeye sahip olmasaydım, Liskell ile başlardım ve GHC ön uç yerine tam teşekküllü bir dil yapardım, sonra FFI'yı daha kolay (ve otomatik) hale getirirdim; C / C ++ kütüphanesi.

İyi bir dil olan dil:

• akla gelmesi kolay (belirsiz sözdizimi yok)
• fikirlerinizi minimum bozulma ile ifade etmenize izin verin
• nitty gritty detaylarını sizden gizleyin (optimizasyon / kaynak yönetimi)
• Kolayca paralelleştirilebilir (çoklu çekirdek, dağıtık bilgi işlem)

Bunu bir özellikler listesine dönüştürmek oldukça zor, ancak İşlevsel Programlamanın, doğal olmamasına rağmen , zorunlu programlamaya göre daha yakın olduğunu düşünüyorum (özellikle nitty kumlu detaylarını gizlemek için).

• C-arayüzey : C, programlama dillerinin lingua franca'sıdır ve C'de geliştirilen kütüphanelerin sayısı şaşırtıcıdır. C'ye kolay bir arayüze (Python gibi) sahip olan dil, tüm bu kütüphanelerden otomatik olarak yararlanır ve ayrıca metal bir dile yetecek kadar optimize edilemeyen ağır işler göndermeyi sağlar.
• Dağıtılmış : Go'nun çok iş parçacıklı olarak çalışmasını seviyorum, çalışma süresinin faaliyetlerine bağlı olarak iş parçacıklarında gönderdiği hafif yordamlarla. Böyle bir dil, programcıyı görevler hakkında düşünmeye ve birbirlerinden ayırmaya teşvik eder.
• Çöp Toplama : Bugünlerde söylemeden gider;)
• Düşünülemez : Asla mutasyona uğramayacak bir şey hakkında anlaşılması çok daha kolay, çok iş parçacıklı / dağıtılmış hesaplamayı da uygulamak çok daha kolay (sadece derleyici görevi olan kullanım ömrünü idare etmek için eşitleme yeterlidir)
• Lambdas : Sanırım birinci sınıf fonksiyonlarla gidiyor
• İleti İletme: değişmezlik muteks yok demektir, bu nedenle Tony Hoares'in önerisini takip ediyoruz
• Modüller : ad alanlarına benzer, ancak daha iyi kapsülleme
• Yansıma : dağıtılmış hesaplama, derleyiciye bırakılması gereken seri hale getirme gerektirir ve bir tür geri yansıtma ile seri hale getirme daha kolay elde edilir.
• Statik Güçlü Yazma : Bir hata ne kadar erken tespit edilirse, maliyeti o kadar düşük olur

Şu anda, bu listeye daha yakın olan dil muhtemelen Haskell'dir:

• Rutinlerden yoksun: Haskell'de paralelliği ifade etmenin doğal bir yolunu henüz görmedim (buna rağmen cehaletim olabilir ...)
• Net bir Sözdizimi var: bir şekilde Haskell programcıları kelimelerden ziyade garip operatörleri kullanmaya devam ediyorlar. Kaygan görünebilir, ancak neler olduğunu anlamak için pek yardımcı olmuyor.

İlk sorunuza “nasıl yaparsınız” - kısa cevap vermedim. Bunu çıkarmak için yeterli ayrıştırıcı / derleyici teorisi yok. Fakat 25 yıldır program yapıyorum, bu yüzden paylaşacak fikir ve görüşlerim var.

Öncelikle, gerçekten bağlı modeller oluşturmanıza izin veren bir OOP yaklaşımı bulmaya çalışacağım. Demek istediğim, modeller hemen hemen her türlü programlama projesinde en önemli şeylerden biridir - doğru bir şekilde yapmak her zaman çok homurdanan ve sürekli yeniden yapılanmadır. OO dilleri.

Göstermeme izin ver. Diyelim ki bir sınıfın bir Kapı özelliği var.

var door = house.Door;

Artık Door örneğine referansla yerel bir değişkeniniz var.

Ama şimdi olanları düşünün: Sadece Kapıyı Evden söktünüz ve şimdi Kapıyı dolaştırmaktan oldukça memnunsunuz ve kodunuzun geri kalanı bu Kapı'nın aslında bir Ev'e bağlı olduğu gerçeğinden habersiz.

Bana göre, bu temelde yanlıştır.

Ve evet, biliyorum, bu durum durum bazında "kolay" bir şekilde sabitlendi - bu durumda, şu anda bağlı olduğu her Kapıdan Eve doğru bir referansı koruyarak. Elbette bu, modelinizi hatalara açar, çünkü şimdi iki ters referansı doğru bir şekilde korumak sizin görevinizdir, bu nedenle House.Doors ve Door.House özelliklerini özel yaparsınız ve House.AddDoor (), House.RemoveDoor (gibi) yöntemleri eklersiniz. ), Door.SetHouse () vs. ve hepsini kablolayın ve gerçekten çalıştığından emin olmak için ünite testi yapın.

Bu kadar düz bir ilişkiyi modellemek için çok fazla iş gibi gelmiyor mu? Saklamak için çok kod? Model geliştikçe refactor için çok fazla kod var mı?

Sorun işaretçiler. Gördüğüm her OO dili doğal olarak, bir nesne referansının gerçekten bir işaretçi olduğu gerçeğinden muzdarip, çünkü bilgisayarların kullandığı şey bu.

İşaretçiler, gerçek dünyayı modellemenin iyi bir yolu değildir. Hangi dünyayı modellemeye çalıştığınıza bakılmaksızın, o dünyadaki tüm ilişkilerin iki yönlü ilişkiler olacağı neredeyse garanti edilir. İşaretçiler yalnızca bir yöne işaret eder.

Temel veri modelinin grafik olduğu bir dil görmek istiyorum - tüm ilişkilerin varsayılan olarak iki ucu vardır. Bu hemen hemen kesinlikle gerçek dünyayı modellemek için çok daha doğal bir uygunluk sağlayacaktı, ki bu gerçekten de ilk başta bilgisayarlara ihtiyacımız olan şeydi. (bu ve video oyunları.)

Böyle bir dilin sözdiziminin nasıl görüneceği veya metin kullanılarak makul bir şekilde ifade edilip edilmeyeceği konusunda hiçbir fikrim yok. (Böyle bir dilin grafik olması gerekip gerekmediğini merak ettim ...

Ayrıca tüm kaza durumlarının ortadan kalktığını görmek isterim.

Örneğin, web geliştirmede, veritabanlarından, iş modellerine, sunum için görünüm modellerine veri şekillendirmek için çok zaman harcıyoruz ... sonra bu verilerin bir kısmı gerçekten başka bir dönüşüm olan formlarda sunuluyor. ..ve durum form-postlardan geri gelir ve sonra bu verileri yeniden şekillendirir ve onu tekrar görünüm modeline yansıtırız, örneğin görünüm modeli bağlayıcıları ve ... daha sonra görünüm modelinden işletmeye geri yansıtırız. model ... daha sonra verileri görünüm modelinden dönüştürmek ve ilişkisel bir veri tabanına yansıtmak için nesne-ilişkisel eşleştiricileri (ya da grunt çalışması) kullanırız ...

Bu gereksiz gelmeye başladı mı? Bütün bu delilik sırasında hangi noktada gerçekten işe yarar bir şey başardık? Faydalı olarak demek istediğim, somut bir şey - son kullanıcının anlayabileceği ve umursadığı bir şey. Günün sonunda, aslında kullanıcıların anlayabileceği bir şey inşa etmek için harcadığınız saatler, gerçekten iyi harcanan tek saatlerdir. Geriye kalan her şey yan etkiler.

Çok dinamik bir dil istiyorum. Yazma / derleme / çalıştırma sıkıcı bir zaman kaybıdır. İdeal olarak, dil neyin değiştiğini anlamak ve gerektiğinde arka planda saydam bir şekilde derlemek / yüklemek zorundadır.

İdeal olarak, "koşmak" zorunda bile kalmamalısınız - değişiklikler yaptığınızda, yaptığınız değişiklikleri anında yansıtan şeyler ekranda olmalıdır. Yazma / derleme / çalıştırma döngüsü, hatta bununla ilgili daha doğrudan yazma / çalıştırma döngüsü ile ilgili sorun, yaptığımız işle bağlantınızı kesilmiş olmanızdır - yaptığımız işle bağlantılı hissetmek için anında geri bildirim, anlık sonuçlara ihtiyacınız var. Beklemek çok uzun!

Yine, bunun geleneksel bir IDE ile gerçekleştirilebileceğini veya bunun tamamen yeni bir arayüz gerektirip gerektirmeyeceğini bile bilmiyorum.

Üzerinde çalıştığınız sorun için en uygun olanı, zayıf ve güçlü bir yazı tipi karışımı kullanabilmelisiniz.

Genel olarak devlet, sizin için tamamen idare ettiği bir dil olmalıdır. Kalıcılık için neden bir veritabanına güvenmeniz gerekiyor? İdeal olarak, modeldeki herhangi bir değişkenin kullanım ömrünü basitçe belirtmek isterim: bir web isteği, bir seans, 24 saat, kalıcı olarak.

Neden farklı medya ve yaşam koşulları için bir dizi depolama çözümü arasında seçim yapmak zorundayız? - Verileri her ortama sığacak şekilde dönüştürmekten ve biçimlendirmekten bahsetmiyorum; tarayıcı önbelleği, veritabanı, bellek, disk kimin umrunda! Veri veridir. Verilerinizi nerede sakladığınız (ve ne kadar süreyle), Tanrılara karşı bir savaş değil, basit bir seçim olmalı!

Güzel, iyi şanslar dilerim.

Muhtemelen aşağıdakileri destekleyen çok paradigma dili olacaktır:

• Yapısal / prosedürel programlama
• Nesne yönelimli programlama
• İşlevsel programlama

Neden bunlar? Nesneye yöneliktir, çünkü özellikle verileri düzenlemek için büyük programlar düzenlemek için harika bir yoldur. Her zaman buna ihtiyaç duymadığınız / ihtiyaç duymadığınız için (OOP), insanların seçim yapması gerekir. İşlevsel, çünkü programcıların hata ayıklamasını kolaylaştırır ve programları daha açık hale getirir.

Python'un modelini kod bloklarını işaretlemek için girintili bloklarla kullanırdım. Çok clen ve okumak güzel.

Python'dan oldukça fazla fikir çalıyordum çünkü Python çok hoş bir dil. İfade için alırdım, haritalarını, listelerini ve tuples'lerini kopyalardım.

Şimdi, muhtemelen dinamik kavramları Python'dan almayacağım: Birincisi, muhtemelen açıkça ve statik olarak yazılabilirdi. Bence programlar bununla daha netleşiyor. Değişkenlerin hepsi muhtemelen yöntemli nesneler olur, o zaman str.length()dize uzunluğunu almak gibi bir şey yapabilirsiniz . İşlev tanımlarında, geri dönüş türünü ve argüman türlerini belirtmeniz gerekir (bazı tür genel türleri de destekler).

Python ;-) 'dan kopyalamaya geri dönelim. İsteğe bağlı prosedür argümanlarına sahip olmanın yolunu seviyorum, bu yüzden muhtemelen buna sahip olacaktım. Ancak Python yordamın aşırı yüklenmesini desteklemiyor, bunu istiyorum.

Sınıflara bakalım, çoklu kalıtımdan kaçardım; kötüye kullanımı kolay. Özel ve benzer kapsamları uygulardım ve muhtemelen C ++ 'da olduğu gibi uygulardım. Ayrıca soyut sınıflar ve arayüzler olurdu; Python'un buna sahip olduğuna inanmıyorum.

İç sınıfları destekleyecek, aslında çok güçlü bir nesne yönelimli dil isteyecektim.

Muhtemelen yorumlanacaktı. İyi bir JIT derlemesi kullanarak hızlı bir şekilde elde etmek mümkündür (hızlı bir dil isterdim, ancak programcı üretkenliği önce gelir) ve derleme çoğu zaman üretkenlik için kötüdür. Yorumlanan diller ayrıca her gün için daha da önemli olan platform bağımsızlığını da destekler.

Yerleşik bir Unicode desteği olurdu; Bugünlerde uluslararasılaşma çok önemlidir.

Kesinlikle toplanan çöpler olurdu. Kahretsin, hafıza yönetimini kendim yapmaktan nefret ediyorum; Verimlilik için de iyi değil.

Sonunda iyi bir standart kütüphaneye sahip olacaktı.

Vay canına, Python'u gerçekten ne kadar sevdiğimi fark ettim.

Öncelikle, derleyicilerle ilgili birkaç kitap, birkaç standart alacağım ve diller veya derleyicilerle bir iki kursa katılacağım. KEP'lere katkıda bulunmak ve C ++ standartları komite toplantılarını ziyaret etmek istiyorum . Umarım hem özellikler hem de hatalar için kullandığım derleyicilere yamalar eklerim.

Sonra geri dönüp şimdi geldiğim bu listeye dehşete baktım, şu anda başlasaydım bir dilin içine girdiğim yollardan hangisi?

• İşlevsel , çünkü şu anda herhangi bir işlevsel dilde iyi bilgili değilim ve bir tanesini öğrenmek, öğrenmek için harika bir yol olacaktır. Doğrudan takip etmemesi durumunda: her şey sabittir .
• İçine sığabileceğim kadar Tip Çıkarımı ile doldururum , ancak arayüzleri açıkça belirtme seçeneği ile. Diğer tiplerden emin değil. Bu, tüm işlevlerin varsayılan olarak genel olması nedeniyle iki katına çıkar .
• Tahmin edebileceğiniz gibi, Arayüzlerle ; yani, sadece mevcut operasyonlarla ilgili sözler veren tiplerle.
• Dilin güçlü ya da zayıf olarak yazılmış olup olmadığını söylemek, söyleyebileceğim kadarıyla bu anlamda çok anlamlı değil. Hangi tür arayüzleri uyguladıklarını hiçbir zaman değiştirmeyeceklerinden , kesinlikle güçlü bir şekilde yazılmış derdim .
• Sözleşme desteğiyle çok fazla Tasarım olacaktır . Yine, sığabildiğim kadarıyla: ön koşullar ve son koşullar şarttır; İşlevsel programlama söz konusu olduğunda ne kadar değişmezlerin ne kadar önemli olduğunu bilmiyorum.
• Ben oradayken , resmen doğruluğu kanıtlayabileceğiniz ve oradan bir şey alıp alamayacağımı görmek için dillere bakarım .
• Dışarı çıkıp harika bir test kütüphanesi yazardım . Harika olmasam bile, en azından her dilin sahip olması gereken bir şey olduğunu düşündüğüm için üzerinde çok fazla zaman harcayacağım.
• Sözdizimine gelince, dilin ya önemli bir beyaz alanı olacak ve Python'a çok benzeyecek , ya da Lojban'a dayanacak ve birçok dilbilgisi ve kelime hazinesi paylaşacaktı. İlk durumda, gramerin bir CFG'ye mümkün olduğu kadar yakın olması için elimden gelenin en iyisini yapardım.
• Dili uygulayan insanların önceden derleyip derlememesi, JIT tarafından yorumlanması, yorumlanması , kamp ateşinde konuşması veya üniversite çocuklarına onlar için yürütmeleri için ödeme yapması umurumda değil . Kendi uygulamam muhtemelen bir tercüman ya da bir C derleyicisi olarak başlayacak ve sonunda bir JITter'a doğru ilerleyecektir.

Bu oldukça geniş noktaları bile görmek, dili uygulamaya başladığımda muhtemelen hızlı bir şekilde değişeceğinden, daha fazla ayrıntıya girmenin gereksiz olduğunu düşünüyorum.

Zamanım olsaydı , Scala'ya dayanan yerelleştirilebilir bir programlama dili tasarlardım , bu nedenle muhtemelen XML dışında çoğu özelliğine sahip olurdu. Amacım, arapça (anadilim) gibi İngilizceden farklı bir yapıya sahip dillerde neredeyse doğal olarak okuyan bir dil yapmak. Aşağıdaki özellikleri düşünüyorum:

• #langProgramlama için kullanılan insan dilinin ön işlemcisini bilgilendirmek için kullanılan bir ön işlemci yönergesi. Örneğin: #lang arkelimenin فئةyerine class, عرفyerine defvb. Kullanılmasına izin verir . İnsan diline özgü anahtar kelimeler standart önişlemci dosyalarında tanımlanır.
• Ön işlemci, tek amacı koda açıklık kazandırmak olan bazı isteğe bağlı anahtar kelimeleri kaldırır. Örneğin, " class MyClass is composed of {olmak " olmaktan çıkar ve " olmak class MyClass {" def MyMethod(x: Int) as {olmaktan çıkar def MyMethod(x: Int) {. Bazı (insan) dillerde, bu kod özellikle öğrenciler için anlaşılması çok daha kolay hale getirecektir.
• Derleyici, özellik erişimi için önek notasyonu kullanımına izin verir. Bu, çoğu Latin dilindeki konuşmacılar için bir anlam ifade etmeyebilir, ancak diğer bazı diller için de mükemmel bir anlam ifade eder. Örneğin, Arapça'daki mülk erişimi normalde, programlama-İngilizce'ye اعرض طول اسم محمدeşdeğerde olduğu gibi önek şeklindedir print(length(name(Mohammad))). (Parantez açıklık içindir.)

Ön işlemci ve derleyicide yapılan bu minimum değişikliklerin, İngilizce konuşamayanlar için programlamayı çok daha kolaylaştıracağına inanıyorum.