Sözdizimi bir programlama dilinde gerçekten önemli mi? [kapalı]


41

Profesörlerimden biri "sözdiziminin bir programlama dilinin kullanıcı arayüzü olduğunu" söylüyor, Ruby gibi dillerin okunabilirliği artıyor ve büyüyor, ancak programcıların sözdiziminin gerçekten önemli olduğu için C \ C ++ ile verimli bir sürü programcı görüyoruz. kabul edilebilir mi olmalı?

Bu konudaki fikrinizi bilmek isterim.

Yasal Uyarı: Bir tartışma başlatmaya çalışmıyorum. Bunun iyi bir tartışma konusu olduğunu düşündüm.

Güncelleme: Bu iyi bir konu olarak ortaya çıkıyor. Hepiniz buna katıldığınız için çok mutluyum.


16
Hmm, bu C / C ++ sözdiziminin kötü olduğunu varsayıyor gibi görünüyor? Elbette C ++ şablonlarının bazı unsurları çirkin, fakat diller devam ettiği sürece (tarihsel olarak), C / C ++ hala çok ama çok okunaklı.
Macneil

2
pekala, çoğunlukla yakut topluluğundan olsa da, söyleyebildiğim kadarıyla
lisp'ten

9
Teorik bir kurs mu? Unutmayın: Profesörler genellikle en kötü programcılardan bazılarıdır. Vahşi doğada nasıl bir yer olduğu hakkında hiçbir fikirleri yok.
Meslek

2
Okunabilirlik, sahibinin gözündedir :).
MAK,

8
İyi sözdizimi, sefil bir dili daha iyi hale getiremez. Ancak sefil sözdizimi iyi bir dili daha da kötüleştirir;)
Dario

Yanıtlar:


65

Evet öyle. Şüphe duyuyorsanız, APL veya J veya Brainfuck , hatta basit ve basit Lisp veya Forth alın ve tamamen önemsiz olmayan programları anlamaya çalışın. Sonra örneğin Python ile karşılaştırın.

Sonra aynı Python (veya Ruby, hatta C #) ile Cobol veya VB6 gibi şeyleri karşılaştırın .

Kıllı sözdiziminin kötü olduğunu ve doğal dil benzeri sözdiziminin her durumda iyi olduğunu söylemeye çalışmıyorum . Ama obvoiusly sözdizimi yapar büyük bir fark yaratır. Sonuçta, en güzel programlama dilinde yazabileceğiniz her şey, bir Turing makine programı olarak da yazabilirsiniz - ama genellikle istemezsiniz, değil mi?


26
Lisp kesinlikle anlaşılabilir bir durumdur.
cbrandolino

65
Okunamayan diller listesine Lisp eklemek için +1.
asmeurer,

65
Okunamayan diller listesine Lisp eklemek için -1.
Paul Nathan,

27
Genel olarak programlama, başlatılmamış olanlara okunamaz durumdadır. Müzik notasyonu ve mimari döşeme planları gibi. (= XY) nasıl okunacağını bilen birisine X == Y kadar okunabilir.
Paul Nathan,

6
APL'yi sevdim ve kod kasıtlı olarak şaşırtmak için yazılmadığı sürece (yapılması çok kolay) okumak oldukça kolaydı. Sözdiziminin gücü, algoritmaları düzinelerce veya yüzlerce satır C, Fortran veya COBOL gerektiren 2 veya 3 satır APL kodunda programlayabilmenizdi. APL gibi bir dilin özlüğü ve gücü bu tartışma için önemlidir, çünkü başka bir dilin yüzlerce kod satırını okumaya çalışmak APL'nin belirsiz öğelerini deşifre etmek kadar sinir bozucu olabilir.
oosterwal

11

Uygulamada önemli olduğunu düşünüyorum. Okunabilirlik yukarıda zaten tartışılmıştır. Başka bir konu, bir fikri / algotitmayı ifade etmek için kaç tane tuşa basılmasıyla ilgili olabilir? Diğer bir mesele, basit yazım hatalarının insan gözünün yakalaması için zor olmasının ne kadar kolay olduğu ve ne kadar yaramazlık yapabilecekleridir.

Bazı bağlamlarda analiz etmek ve / veya başka bir bilgisayar programı aracılığıyla kod parçalarını oluşturmak için de faydalı buldum. Dilin ayrıştırılması ve / veya doğru kodun üretilmesinin zorluğu, daha sonra, bu tür araçları oluşturmak / sürdürmek için ne kadar çaba gerektiğini doğrudan etkilemektedir.


Ayırt edilmesi kolay yazım hataları hakkında büyük gözlem.

7
Fakat teoride teori ile pratik arasında bir fark yoktur.
Job

10

Profesörünüzün Syntactic şekerden bahsettiğine inanıyorum .

Sözdizimsel şeker, programlama dilindeki sözdizimini ifade eden, bir şeyleri ifade etmenin alternatif yolları varken bir şeyleri okumayı veya ifade etmeyi kolaylaştıracak şekilde tasarlanmış bir bilim terimidir .

Yani profesörünüzün ima ettiği şey, bir programlama dilinde yazılmış kod / sözdizimi ne olursa olsun, aynı dilde, hatta aynı dilden başka dillerde de ifade edilebilir.

Structured Programming teoreminden yola çıkarak Robert Martin, programcıların RailsConf 2010'daki açılış konuşmasında programlama dilleriyle temelde ne yaptığını özetledi: Robert Martin ( youTube videosu, her şeyi tavsiye etmeme rağmen, 14 dakika sonrasına bakın):

  • Sıra (atama)
  • Seçim (eğer ifadeler)
  • Yineleme (do-döngüler)

Tüm programcılar, bir programlama dilden diğerine, sadece farklı bir sözdiziminde veya kullanıcı arayüzünde (UI) yapar. Programlama dilleri hakkında soyut bir şekilde konuşuyorsa, profesörünüzün ulaştığını tahmin ediyorum.

Yani özünde , sözdizimi önemli değil . Ancak, belirli olmak istiyorsanız, belli diller ve sözdizimi belli görevler için diğerlerine göre daha uygundur, bu nedenle sözdiziminin önemli olduğunu iddia edebilirsiniz.


C'ye montajcı için sözdizimsel bir şeker mi diyorsun?
Goran Joviç,

1
İsterim. Ancak sözdizimi ile ilgili meseleleri iddia ediyorum. ;)
Lennart Regebro

2
“... Robert Martin, programcıların temelde ne yaptığını soyutladı ...” Robert Martin? Robert Martin? Bu makaleyi düşünmek isteyebilirsiniz: C. Böhm, G. Jacopini, "Akış diyagramları, Turing Makineleri ve Sadece İki Oluşum Kurallı Dilleri", Comm. ACM, 9 (5): 366-371, 1966'da açıklanmıştır. Genellikle 'Yapılandırılmış Program Teoremi'nin kaynağı olarak alacaklardır. en.wikipedia.org/wiki/Structured_program_theorem
leed25d

@ lee25d Bob Amca'yı soyutlamanın yaratıcısı olarak değil, son zamanlarda duyduğum kaynak olarak (ve buna bağlı olarak) kastetmek istememiştim. Ancak bağlantı için teşekkür ederim, bağlantınızı yansıtacak şekilde cevabımı güncelleyeceğim.
10:09

Yukarıda bağlanan Wikipedia eseri "Yapısal Programlama Teoremi" nin tarihini tam olarak anlamıyor. Bu fikir Bohm ve Jacopini'yi öncülük etti. Bohm & Jacopini'nin katkısı, yalnızca bir varsayım değil, aynı zamanda sıkı bir resmi kanıt sağladığının bir teoremi olduğunu gösteriyordu.
John R. Strohm

7

Evet ve hayır.

Sözdiziminin birkaç farklı yönü var.

  • okunabilirliği
  • ekspressivite
  • parsability

Okunabilirlik zaten belirtilmiştir.

Anlatımcılık ilginç bir durumdur. Fonksiyon-geçişi örnek olarak kullanacağım, çünkü bu bir anlamsal / sözdizimsel ağrının çarpma noktası.

Örneğin C ++ alalım. Bu modadan sonra birinci dereceden bir fonksiyon yaratabilirim:

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

Bu belirli deyim, Stepanov'un Programlama Öğelerinde yaygın olarak kullanılmaktadır .

Öte yandan, ben böyle bir şeyle Common Lisp bunu taklit edebilir bu :

(defun myfunc() )

(defun run_func(fun)
  (fun))

Veya, Perl -

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

Veya, Python'da -

def myfunc():
    pass

def run_func(f):
    f()

Bunların hepsi - esasen - aynı anlamsal içeriğe sahiptir, ancak C ++ örneği bazı tipte meta veri taşır. Hangi dil, daha üst düzey bir işlevi en iyi şekilde geçirme fikrini ifade eder? Common Lisp zar zor sözdizimi bir varyasyon yapar. C ++, yalnızca işlevi 'taşımak' için bir sınıf oluşturulmasını gerektirir. Perl, bir miktar farklılaşma yapmak için oldukça basittir. Python da öyle.

Hangi alan problem alanına daha uygun? Aklınızdaki düşünceleri en az 'empedans uyumsuzluğu' ile en iyi hangi yaklaşım ifade edebilir?

Parsability - aklımda - büyük bir anlaşma. Özellikle, IDE'nin dili hata yapmadan ayrıştırma ve doğrama yeteneğine atıfta bulunuyorum. Yeniden biçimlendirme yararlıdır. Belirteçle ayrılmış diller iyi ayrıştırma eğilimindedir - ruby ​​/ c / pascal, etc.

Yine de düşünün - gerçek dünyadaki sorunları çözmek için her ciddi dilde her türden büyük sistemler oluşturuldu. Sözdizimi bazı şeyleri ifade etmek için bir engel olsa da, işe yaramaz bir engeldir. Turing denkliği ve hepsi.


5

Sözdizimi kesinlikle önemlidir, ancak sezgisel olmadığında daha fazla fark etme eğilimindedir ve hataları teşvik eder. Örneğin, rezil "dünyanın son böceği" şakası:

if (AlertCode = RED)
   {LaunchNukes();}

2
+1: İlginç, bu rezil "dünyanın son böceği" şakasını hiç görmedim (ya da kabullenmedim). Ancak bir dilin (veya hatta anlambilimin bile) sözdizimine bağlı olarak sözde kodun sonucunun herhangi bir şey olabileceğini görebiliyorum. Anlamsal bakış açısı göz önüne alındığında, bu gerçekten klasik kültürel iletişimsizlik olgusuna yansıtılabilir.
Stephen Swensen

Bu yüzden Yoda koşullarını kullanmalısın, yani if(RED = AlertCode)asla
derlememelisin

4
@Malfist: Ve böylece kötü sözdiziminin telafi etmek için daha kötü sözdizimine yol açtığını görüyoruz. Yoda koşulluların okunması çok çirkin ve zordur, çünkü insanların ilişkili kavramı düşündüğü gibi değildir. Demek istediğim daha çok "bu (birçok nedenlerden biri) neden C ailesinden mümkün olduğunca kaçınmanız gerektiğidir."
Mason Wheeler,

1
Neyse ki, bu kodun iki hatası var. Tabii ki, her zaman şartlı girecektir, ancak orada, sadece LaunchNukesprosedürü referans alıyor ve hiçbir zaman onu çağırmıyor. Kriz önlendi!
munificent

3
Neyin olduğuna REDbağlı. 0 ise, o LaunchNukes()zaman asla aranmaz.
dan04,

5

Sözdizimi önemli ve size iki destekleyici örnek verebilirim: daha geleneksel bir sözdizimi olan bir Lisp olan Dylan ve Lisp benzeri sözdizimi olan Haskell olan Liskell. Her durumda, tamamen aynı semantiklere sahip fakat kökten farklı bir sözdizimine sahip bir dil çeşidi önerildi.

Dylan söz konusu olduğunda, s ifadelerinin daha geleneksel bir şey lehine düşürülmesinin daha geniş bir programcı yelpazesini çekmeye yardımcı olacağı düşünülmüştü. Programcının Lisp kullanmasını engelleyen tek şey sözdizimi olmadığı ortaya çıktı.

Liskell durumunda, s ifadelerinin kullanılmasının makroların daha kolay kullanılmasına izin vereceği düşünülmüştü. Haskell'de makroların gerçekten gerekmediği ortaya çıktı, böylece deney de işe yaramadı.

İşte size bir şey var: sözdizimi kimseye bir şey ifade etmezse, hiçbir deney denenemezdi.


1
Dylan diğer dillere çok geç kalmıştı. Onun lehine olan şey bunun için telafi edemedi. Bunun bir sözdizimi hatası olduğunu, adlandırmada bir hata olduğunu kabul edemeyiz.
Macneil

@ Macneil: Çok küçük, çok geç bir şey hakkında haklısın. Lisp sözdizimini bırakmak tabuttaki son çiviydi. Dylan'ın başarısızlığının temel nedeni olduğunu sanmıyorum, ancak cevabı en iyi şekilde yansıtacak şekilde nasıl yeniden sözcüklendirileceğinden emin değilim.
Larry Coleman

İlginç, önceki versiyonda Lisp sözdizimine sahip olduklarını bilmiyordum ... Ralph isminde miydi? Newton Mesaj Defteri aslen Dylan'ın çekirdeğinde olacaktı. 15 yıl sonra, iki IMHO'nun dilinin daha az dili olan çekirdek iOS'tayız.
Macneil,

Dylan'ın ifadelerini ne zaman kaybettiğine dair kesin ayrıntıları hatırlamıyorum. Uzun zamandır comp.lang.lisp'i gizliyordum ve periyodik flamewarlarından birinde parantez üzerine çıkan konuyu hatırlıyorum.
Larry Coleman,

Dylan Java'yı yiyor ve sanırım o zamanlar birçok C ++ yolu yoktu.
Tom Hawtin - tackline

3

Cevap, neyin önemli olduğunu bilgisayar faktörlerine ve insan faktörlerine ayırmada olabilir . Sözdiziminde birçok insan faktörü var:

  • Okunabilirlik
  • Özlülük
  • İdame
  • pedagoji
  • Hata önleme
  • Amaca uygunluk - REPL dili, bir betik dili veya büyük bir sistem dili midir?

Bilgisayar söz konusu olduğunda, tek sözdizimi konusu, çözülmesi gereken belirsizliklerin olup olmadığı ve derleme / yorumlama sırasında kodu belirtmek / ayrıştırmak için ne kadar zaman alacağıdır - ve sadece durumda ayrıştırma ek yükünün önemli bir konu olduğu sonuncusu.

Bu soruyu her zaman "evet ve hayır" cevabı alabilmenizin nedeni bu olabilir - çünkü bunun iki yönü vardır.


1

Sözdizimi olmadan, insan düzeyinde bir kod bloğunun amacını iletmek için ortak bir "şablon" a sahip olmazdık . Sözdizimi, derleyicilerin standartlaştırılabileceği ortak bir çerçeve sağlar ; yöntemler paylaşılabilir; bakım basitleştirilebilir.


Neden cevabım aşağı oy kullandı?
IA,

1

Ben ne düşünüyorsun gerçekten önemli olan API erişimi gerektiğinde ve (bellek kontrol ve kilitleme gibi) düşük seviyeli özelliklerin kullanımı. Diğer birçok dilde bu özellikler bulunur. Sorun şu ki, ek bir işlevselliğe ihtiyaç duyduğunuzda, bunu uygulamak için genellikle C gibi bir dil kullanmanız gerekir. Ve kullandığınız dil ile C arayüzünü kullanması zordur.

Web geliştirme dışındaki her şey için (ve matematik) C / C ++ 'nın hala bir işletim sistemi ve uygulama dili olduğunu buldum. Gerçek çoklu iş parçacığı, ön biçimlendirme, platformlar arası uygulama geliştirme için çoğu zaman bu desteklenir. Ve C'nin sözdizimi tamamdır. Sadece çok basit ve nispeten ayrıntılı. Şaşırtıcı Sözdizimi bu kadar önemli değil. Güç ve API kullanılabilirliği hepimizin başkalarının koduyla (çoğu zaman C veya türevleriyle yazılmış) kodları arasında bağlantı kurması gerekir.


C ile hiçbir ilgim yok, ancak ML / Haskell kalabalığının muhtemelen diş çekme konusunda söyleyeceği bir şey var.
Rei Miyasaka

"API erişimi" için +1: Bunun dil özelliklerinden bile daha önemli olabileceğini düşünüyorum.
Giorgio

1

Sözdizimi kesinlikle önemli. Dil sözdiziminin, uygulamanız için uygun ve okunabilir bir etki alanına özgü dil oluşturmanıza izin verecek kadar esnek olması çok değerlidir. Bundan şüphe ediyorsanız, 18. yüzyıldan önce olduğu gibi yalancı Latince'de cebir problemleri veya hayalinizdeki Leibniz notasyonu olmadan matematik yaptığınızı hayal edin. Elbette, bir matematik metni acemiler tarafından okunamıyor, ancak pratikte matematiği ve Leibniz gösterimini klasik yöntemlerle matematik sayfalarını gerektiren bir problem sınıfını hızla çözmek için kullanabiliriz. Programlama matematiğin bir başka kısmıdır. Problem alanına yakın olan uygun bir gösterim, üretkenlikte büyük bir fark yaratabilir.


DSL'ler tamamen sözdizimi şekeri ile ilgili değil. Anlambilim çok daha değerli bir kısımdır. Mevcut bir sözdizimine hiçbir şey eklemeyecek olan eDSL'leri tasarlamak uygundur.
SK-mantığı

@SK: elbette, fakat anlambilim programcının kontrolü altında. Sözdizimi, temel dil tarafından sınırlandırılmıştır. Groovy ve diğer dillerde uygun DSL'ler oluşturabiliriz, ancak Java'da çok fazla değil.
kevin cline

1

İşte 6 fakülteyi hesaplayan bir program:

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

Sözdizimi en az:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

Bir dili zorlaştıran şeylerin sözdiziminin olduğuna dair yaygın bir inanç var gibi görünüyor. Sıkça tutulan inançlarda sıklıkla olduğu gibi, tam tersi doğrudur.

LISP sözdiziminin sadece okunabilir olduğunu unutmayın (eğer varsa) , yukarıdakilerden çok daha fazla sözdizimine sahiptir. Bu nedenle, eğer LISP hayranları size “sözdiziminin önemli olmadığını” söylerse, sonuçlanmalarını isteyin ve SKI hesaplamasını deneyin. Biraz sözdiziminin sonuçta çok da kötü olmadığını kabul etmek zorunda kalacaklar.


Aşağı oyu anlayamıyorum. Bu gerçekten anlayışlı bir cevap. +1
scravy

0

Kişisel tercihlerin ötesinde önemli olduğunu sanmıyorum. Her şey (performans, yetenekler, vb.) Eşit olmaktan sonra neden bir dilin sözdizimine daha fazla ağırlık vereceğini görebiliyorum, ancak c / c ++ gibi dillerin performansını veya iş için daha uygun olan diğer dilleri geçmeyi tercih ediyorum. sözdizimi her yerde kötü bir fikir gibi görünüyor.


6
"Pazara çıkma zamanı", "faydalanma maliyeti" vb.
Meslek

0

Evet, sözdizimi önemlidir, ancak gerçekten yalnızca okunabilirlik için. Karşılaştırmak:

for i in range(10):
   print(i)

(Evet bu Python) ile

FOR(i<-RNG-<10){PRN<-i}

(Evet, bu yeni oluşturduğum bir dil.) Her ikisi de aynı şeyi aynı şekilde yapar, ancak sözdizimi farklıdır ve Python'un okunması daha kolaydır. Yani evet, sözdizimi kesinlikle önemli. "Sözdizimsel Şeker" bile önemlidir.

 @property
 def year(self):
     return self._date.year

Okumaktan daha kolay

 def year(self):
     return self._date.year
 year = property(year)

0

Evet tabii.

Büyük bir alev başlatmak istiyorsanız, milletvekillerine, açılış bracetini C-benzeri dillerde nereye koyduklarını sorun. Demek istediğim

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

hatta VS

void foo() 
{ // blah
}

Ve bu sadece aynı dil! Ayrıca, yerlerine, onları nereye koyduklarına (işlev adı ve bracet, operatörler vb.) Sorun.

1000 cevap garantilidir!


bir alev başlatmak istemiyorum ve şimdiye kadar iyi tepkiler aldım & katılımlarıma ve bilgilerimi arttırdıkları için hepsine teşekkür ediyorum ve bahse girerim bu diğer insanları yararlı buldu
Saif al Harthi

0

Sözdizimi önemli. Ancak bu gün ve yaşta, neredeyse tümüyle okunabilirlik nedeniyle önemli olduğunu ve ihtiyaç duyulan tuş vuruşu miktarları açısından gerçekten önemli olmadığını söyleyebilirim. Neden?

  • Gerçekten çok basit bir şey yazmıyorsanız, bastığınız tuşların sayısı bir program yazmada sınırlayıcı bir faktör ise, o zaman gerçekten ya da gerçekten çok fazla çabuk yazmayı düşünürsünüz.
  • Bugünlerde tüm makul IDE'lerde, çoğu zaman kullandığınız tüm karakterleri yazmanız gerekmediği anlamına gelen çok sayıda kısayol vardır.

Bununla birlikte, eğer çok ayrıntılıysa, okunabilirliği etkilediği noktaya gelebilir. Gibi bir şey görmeyi tercih ederim:

foreach (stringList'te dize)

Kime:

stringlist değişkeni tarafından başvurulan listedeki her String için

...herhangi bir gün!


0

Sözdizimi, onu öğrenenler için önemlidir, dilin girişi ne kadar popülerse, giriş engeli o kadar düşük olur. Ancak, dilinizi kendinizden zengin ve özlü bir şekilde ifade etmek zor veya imkansızsa, popülerliğini yitirmeye başlayacaktır.

Çok özlü ve opak (Perl), aşırı ayrıntılı ve wordy (AppleScript) kadar kötü.

Bir denge, girişe daha az engel, yüksek verimlilik ve kolay bakım olması gerekiyor.


-2

Dikkate alınması gereken bir diğer husus, daha iyi sözdizimi olan programlama dillerinin ayrıştırılmasının daha kolay olmasıdır, bu sayede derleyicinin yazması daha kolay, daha hızlı ve hatalara daha az eğilimlidir.


3
Umm ... 10000 SLOC’dan Ruby’ye parse.ykatılmıyorum. Orada bir nedeni olduğunu her biri 7 akım ya-yakında üretime hazır Yakut uygulamasının kullandığı aynı ayrıştırıcı ve her zamankinden onların geliştirmeye çalıştı Ruby uygulaması kendi ayrıştırıcı başarısız oldu.
Jörg W Mittag

Ve sonra rezil ADA dili vardı. Dil belirtimi ile birlikte, derleyiciyi sertifikalandırmak için doğru şekilde çalışan 100 program vardı. Sözdizimi hakkında bazı ince şeyler vardı. Uzun bir öyküyü kısaltmak için, HER erken ADA derleyici bu programlardan birkaçını kullandı. Ve bir hatayı düzeltmek basit bir mesele değildi, ama sıfırdan başlamaları gerekiyordu. Büyük devlet desteğine sahip olmasına rağmen (tüm DOD sözleşmeleri ADA'yı zorunlu kıldı), sefil bir ölümle öldü.
Omega Centauri,

-2

Basitçe söylemek gerekirse, bunun gibi bir sözdizimi önemli değil. İçinde ifade edebileceğiniz anlambilim önemlidir.


5
Bir egzersiz olarak, C'ye karmaşık bir ayrıştırıcı ve ardından Haskell'de bir aygıt sürücüsü yazın. Sözdizimi size yardımcı oldu mu? Sonra, diğer iki yolu da kesin olarak koruyarak her iki programın
9000

1
@ 9000: Haskell'de birkaç aygıt sürücüsü gördüm. Onlarla özellikle yanlış bir şey göremedim. Detaylandırmak ister misiniz?
Jörg W Mittag

2
@ 9000, C’de aygıt sürücülerinin doğru olmasının ne kadar zor olduğu göz önüne alındığında iyi bir örnek seçtiğinizden emin değilim.

1
@ 9000: Bu tam olarak benim amacımdı. Sözdizimsel yapının somut doğası önemli değil, onunla ifade ettiğiniz şey bu. Haskell'in tam sözdizimine sahip, ancak farklı bir değerlendirme stratejisi kullanan bir programlama dili, Haskell'in çok fazla performans göstermesine ve hatta sonsuz döngülere takılmasına neden olacaktır. Sözdizimsel yapılara gelince (ya da daha geniş: dil özellikleri), önemli olan onların sözdizimleri değil, onların anlambilimleri, yani onlarla ifade edebileceğiniz şeylerdir.
back2dos

@ 9000'de, Haskell'de C benzeri bir sözdizimine sahip bir ayrıştırıcı (veya Haskell benzeri bir sözdizimine sahip C kullanarak bir sürücü) yazmak sorun olmaz.
SK-mantığı
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.