Czy składnia naprawdę ma znaczenie w języku programowania? [Zamknięte]

41

Jeden z moich profesorów mówi „składnia jest interfejsem użytkownika języka programowania”, języki takie jak Ruby mają doskonałą czytelność i stale się rozwijają, ale widzimy wielu programistów produktywnych w C \ C ++, więc dla programistów naprawdę ważne jest, aby składnia powinno być dopuszczalne?

Chciałbym poznać Twoją opinię na ten temat.

Oświadczenie: Nie próbuję zaczynać kłótni. Myślałem, że to dobry temat dyskusji.

Aktualizacja: To okazuje się być dobrym tematem. Cieszę się, że wszyscy w tym uczestniczycie.

Saif al Harthi
źródło
16
Hmm, to wydaje się zakładać, że składnia C / C ++ jest zła? Z pewnością niektóre elementy szablonów C ++ są brzydkie, ale jeśli chodzi o języki (historycznie), C / C ++ jest nadal bardzo, bardzo czytelny.
Macneil,
2
no cóż, znam wielu programistów, którzy się z tym nie zgodzą, głównie ze społeczności ruby, ale jest to bardziej czytelne niż seplenienie, o ile mogę powiedzieć :)
Saif al Harthi
9
Czy to był kurs teoretyczny? Pamiętaj: profesorowie są często jednymi z najgorszych programistów. Nie mają pojęcia, jak to jest na wolności.
Job
2
Czytelność zależy od obserwatora :).
MAK
8
Dobra składnia nie może poprawić nieszczęśliwego języka. Ale żałosna składnia może pogorszyć dobry język;)
Dario

Odpowiedzi:

65

Tak. Jeśli masz wątpliwości, weź APL , J , Brainfuck , a nawet prosty i prosty Lisp lub Forth, i spróbuj zrozumieć dowolny nie całkiem trywialny program. Następnie porównaj np. Do Pythona.

Następnie porównaj ten sam Python (lub Ruby, a nawet C #) z rzeczami takimi jak Cobol lub VB6.

Nie próbuję powiedzieć, że składnia owłosiona jest zła, a składnia podobna do języka naturalnego jest dobra we wszystkich okolicznościach. Ale oczywiście składnia robi ogromną różnicę. Podsumowując, wszystko, co możesz napisać w najpiękniejszym języku programowania, które możesz również napisać jako program maszyny Turinga - ale zwykle nie chcesz, prawda?

9000
źródło
26
Lisp jest zdecydowanie zrozumiały.
cbrandolino,
65
+1 za umieszczenie Lisp na liście nieczytelnych języków.
asmeurer
65
-1 za włączenie Lisp na listę nieczytelnych języków.
Paul Nathan
27
Programowanie w ogólności jest nieczytelne dla niewtajemniczonych. Podobnie jak notacja muzyczna i plany architektoniczne. (= XY) jest tak samo czytelny jak X == Y, dla kogoś, kto umie czytać.
Paul Nathan
6
Uwielbiałem APL i jeśli kod nie został celowo napisany w celu zaciemnienia (bardzo łatwy do zrobienia), był dość łatwy do odczytania. Moc składni polegała na tym, że można było zaprogramować algorytmy w 2 lub 3 liniach kodu APL, które wymagałyby dziesiątek lub setek linii C, Fortran lub COBOL. Zwięzłość i moc takiego języka jak APL jest ważna w tej dyskusji, ponieważ próba odczytania setek wierszy kodu innego języka może być tak samo frustrująca, jak rozszyfrowanie niejasnych elementów APL.
oosterwal 31.01.11
11

W praktyce myślę, że to ma znaczenie. Czytelność została już omówiona powyżej. Innym problemem może być liczba naciśnięć klawiszy potrzebnych do wyrażenia pomysłu / algotithm? Kolejną kwestią jest to, jak łatwo literom ciężko jest uchwycić ludzkie oko i jak wiele psot mogą wywołać.

Uznałem również za przydatne w niektórych kontekstach analizowanie i / lub generowanie fragmentów kodu za pomocą innego programu komputerowego. Trudność w parsowaniu języka i / lub generowaniu poprawnego kodu wpływa bezpośrednio na to, ile wysiłku wymaga przygotowanie / utrzymanie takich narzędzi.

Omega Centauri
źródło
Świetna obserwacja na temat literówek, które są łatwe do rozróżnienia.
7
Ale w teorii nie ma różnicy między teorią a praktyką.
Job
10

Wierzę, że twój profesor odnosi się do cukru syntaktycznego .

Cukier syntaktyczny jest terminem informatycznym, który odnosi się do składni w języku programowania, który ma na celu ułatwienie czytania lub wyrażania, podczas gdy istnieją alternatywne sposoby ich wyrażania .

Profesor sugeruje więc, że każdy kod / składnia napisana w jednym języku programowania może być wyrażony w innych językach w tym samym lub nawet w tym samym języku.

Robert Martin, odwołując się do twierdzenia o programowaniu strukturalnym , wyodrębnił, co programiści zasadniczo robią z językami programowania podczas swojego przemówienia na RailsConf 2010: Robert Martin (wideo z YouTube'a , zobacz po 14 minutach, chociaż polecam całą rzecz):

  • Sekwencja (zadanie)
  • Wybór (jeśli instrukcje)
  • Iteracja (pętle do)

To wszystko robią programiści, od jednego języka programowania do drugiego, tylko w innej składni lub interfejsie użytkownika (UI). Chyba właśnie do tego zmierza twój profesor, jeśli mówi abstrakcyjnie o językach programowania.

Tak w istocie , składnia nie ma znaczenia . Ale jeśli chcesz być konkretny, to oczywiście niektóre języki i składnia lepiej nadają się do niektórych zadań niż inne, dzięki czemu możesz argumentować, że składnia ma znaczenie.

sunpech
źródło
Czy nazwałbyś C tylko cukrem syntaktycznym dla asemblera?
Goran Jovic,
1
Ja bym. Ale twierdzę, że składnia ma znaczenie. ;)
Lennart Regebro,
2
„... Robert Martin streścił to, co zasadniczo robią programiści…” Robert Martin? Robert Martin ?? Być może warto rozważyć ten artykuł: C. Böhm, G. Jacopini, „Diagramy przepływu, maszyny Turinga i języki z tylko dwiema regułami formacji”, Comm. ACM, 9 (5): 366–371,1966. który jest zwykle uznawany za źródło „Twierdzenia o programie strukturalnym”. en.wikipedia.org/wiki/Structured_program_theorem
leed25d
@ lee25d Nie chciałem uznać wujka Boba za twórcę abstrakcji, ale jako źródło, z którego ostatnio ją usłyszałem (i do którego linkowałem). Ale dziękuję za link, zaktualizuję moją odpowiedź, aby odzwierciedlić twój link.
gąbka
Link do powyższej Wikipedii nie do końca rozumie historię „twierdzenia o programowaniu strukturalnym”. Pomysł poprzedza Bohm & Jacopini. Wkład Bohma i Jacopiniego pokazał, że BYŁoby to twierdzenie, a nie tylko przypuszczenie, tj. Dostarczyło ścisłego formalnego dowodu.
John R. Strohm,
7

Tak i nie.

Składnia obejmuje kilka różnych aspektów.

  • czytelność
  • ekspresja
  • przetwarzalność

Czytelność została już wspomniana.

Ekspresyjność to ciekawy przypadek. Jako przykład wykorzystam przekazywanie funkcji, ponieważ jest to punkt przegięcia bólu semantycznego / składniowego.

Weźmy na przykład C ++. Po tej modzie mogę utworzyć funkcję pierwszego rzędu:

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

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

Ten szczególny idiom jest powszechnie używany w elementach programowania Stepanova .

Z drugiej strony, mogę naśladować go w Common Lisp coś jak to :

(defun myfunc() )

(defun run_func(fun)
  (fun))

Lub w Perlu -

   sub myfunc
   {
   }

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

Lub w Pythonie -

def myfunc():
    pass

def run_func(f):
    f()

Wszystkie mają - zasadniczo - tę samą treść semantyczną, chociaż przykład w C ++ niesie metadane typu. Który język najlepiej wyraża przekazanie funkcji wyższego rzędu? Common Lisp ledwo tworzy odmianę składniową. C ++ wymaga utworzenia klasy tylko do „przenoszenia” funkcji. Perl jest dość prosty w kwestii różnicowania. Podobnie jak Python.

Które podejście najlepiej pasuje do dziedziny problemowej? Które podejście najlepiej wyraża myśli w twojej głowie z najmniejszym „niedopasowaniem impedancji”?

Parsowalność jest - moim zdaniem - dużą sprawą. W szczególności odnoszę się do zdolności IDE do parsowania i rąbania języka bez popełniania błędów. Ponowne formatowanie jest przydatne. Języki rozdzielane znakami zwykle parsują się dobrze - ruby ​​/ c / pascal itp.

Zastanów się jednak - w każdym poważnym języku stworzono główne systemy wszelkiego rodzaju, aby rozwiązać rzeczywiste problemy. Chociaż składnia jest barierą do wyrażania niektórych rzeczy, jest barierą umożliwiającą obejście problemu. Równoważność Turinga i tak dalej.

Paul Nathan
źródło
5

Składnia na pewno ma znaczenie, chociaż zauważasz ją częściej, gdy jest nieintuicyjna i zachęca do błędów. Na przykład niesławny żart „ostatniego błędu świata”:

if (AlertCode = RED)
   {LaunchNukes();}
Mason Wheeler
źródło
2
+1: Interesujące, nigdy nie widziałem (ani nie przyznałem) tego niesławnego żartu z „ostatniego błędu świata”. Widzę jednak, że w zależności od składni języka (a właściwie nawet semantyki) wynikiem tego pseudokodu może być cokolwiek. Biorąc pod uwagę kąt semantyczny, można to naprawdę przypisać klasycznemu przypadkowi nieporozumień kulturowych.
Stephen Swensen
Właśnie dlatego powinieneś używać warunkowych Yoda, tzn. if(RED = AlertCode)Nigdy nie należy kompilować, ponieważ RED jest stały (lub powinien być!)
Malfist
4
@Malfist: I tak widzimy, że zła składnia prowadzi do jeszcze gorszej składni w celu kompensacji. Warunki warunkowe Yody są brzydkie i trudne do odczytania, ponieważ ludzie nie myślą o związanej z nimi koncepcji. Chodzi mi raczej o to, że „jest to (jeden z wielu powodów), dlaczego należy unikać rodziny C, gdy tylko jest to możliwe”.
Mason Wheeler,
1
Na szczęście ten kod zawiera dwa błędy. Jasne, zawsze wejdzie w warunek, ale tam po prostu otrzymuje odniesienie do LaunchNukesprocedury i nigdy jej nie wywołuje. Kryzys zażegnany!
szczodry
3
Zależy od tego, co REDjest. Jeśli LaunchNukes()wynosi 0, to nigdy nie zostanie wywołany.
dan04
5

Składnia ma znaczenie i mogę podać dwa dodatkowe przykłady: Dylan, czyli Lisp o bardziej konwencjonalnej składni, i Liskell, który jest Haskell o składni podobnej do Lisp. W każdym przypadku zaproponowano wariant języka, który miał dokładnie taką samą semantykę, ale radykalnie różną składnię.

W przypadku Dylana sądzono, że porzucenie wyrażeń s na rzecz czegoś bardziej konwencjonalnego pomogłoby przyciągnąć większą liczbę programistów. Okazało się, że składnia nie była jedyną przeszkodą dla programistów w korzystaniu z Lisp.

W przypadku Liskell sądzono, że użycie wyrażeń s pozwoli na łatwiejsze użycie makr. Okazało się, że makra naprawdę nie są potrzebne w Haskell, więc eksperyment też nie zadziałał.

Oto rzecz: jeśli składnia nie ma znaczenia dla nikogo, żaden eksperyment nie zostałby wypróbowany.

Larry Coleman
źródło
1
Dylan był za mały, za późno na inne języki. To, co miało na swoją korzyść, nie mogło tego nadrobić. Nie możemy bardziej założyć, że to błąd składni niż błąd w nazewnictwie.
Macneil,
@Macneil: Masz rację co do zbyt małej, zbyt późnej rzeczy. Usunięcie składni Lisp było tylko ostatnim gwóźdźem do trumny. Nie sądzę, żeby był to główny powód niepowodzenia Dylana, ale nie jestem pewien, jak przeformułować odpowiedź, aby jak najlepiej to odzwierciedlić.
Larry Coleman
Co ciekawe, nie wiedziałem, że mają składnię Lisp we wcześniejszej wersji ... Czy to wtedy nazywał się Ralph? W Newton Message Pad pierwotnie miał znajdować się Dylan. 15 lat później mamy iOS z Objective-C u podstaw, mniejszym językiem z tych dwóch, IMHO.
Macneil
Nie pamiętam dokładnych szczegółów, kiedy Dylan stracił s-wyrażenia. Czułem się na comp.lang.lisp od dłuższego czasu i pamiętam temat pojawiający się w jednym z ich okresowych flamewars nad nawiasami.
Larry Coleman
Dylan poprzedza Javę i nie sądzę, żeby było wtedy dużo C ++.
Tom Hawtin - tackline
3

Odpowiedzią może być rozdzielenie tego, co „ważne” na czynniki komputerowe i ludzkie . Składnia składa się z wielu ludzkich czynników:

  • Czytelność
  • Zwięzłość
  • Konserwowalność
  • Pedagogia
  • Zapobieganie błędom
  • Odpowiedni do tego celu - czy jest to język REPL, język skryptowy czy duży język systemowy?

Jeśli chodzi o komputer, jedynym problemem związanym ze składnią jest to, czy istnieją niejasności, które należy rozwiązać, oraz ile czasu zajmuje tokenizacja / parsowanie kodu po kompilacji / interpretacji - i to tylko w przypadku tych ostatnich, w których narzut jest parsowaniem.

Być może dlatego zawsze otrzymasz odpowiedź „tak i nie” na to pytanie - ponieważ są dwa aspekty.

Rei Miyasaka
źródło
1

Bez składni nie mielibyśmy wspólnego „szablonu”, z którego można by komunikować na poziomie ludzkim intencję bloku kodu. Składnia zapewnia wspólną platformę, z której można kompilować kompilatory; metody mogą być współużytkowane; konserwacja może być uproszczona.

IAbstract
źródło
Dlaczego moja odpowiedź została odrzucona?
IAbstract
1

Myślę, że tak naprawdę liczy się dostęp do interfejsu API i dostępność funkcji niskiego poziomu (takich jak kontrola pamięci i blokowanie) w razie potrzeby. Większość innych języków zawiera te funkcje. Problem polega na tym, że gdy potrzebujesz dodatkowej funkcjonalności , często musisz użyć języka takiego jak C, aby ją wdrożyć. Jest to kłopotliwe, gdy łączysz język C z używanym językiem.

Mimo wszystko, oprócz programowania stron internetowych (i matematyki), zauważyłem, że C / C ++ jest nadal językiem systemu operacyjnego i aplikacji. To jest obsługiwane przez większość czasu dla prawdziwego wielowątkowego, preformującego, wieloplatformowego rozwoju aplikacji. A składnia C jest w porządku. Po prostu bardzo prosty i względnie pełny. Niesamowita składnia tak naprawdę nie ma znaczenia. Dostępność mocy i interfejsu API Wszyscy potrzebujemy interfejsu z kodem innych osób (który jest w większości napisany w C lub jego pochodnych).

unixman83
źródło
Nie mam skrupułów z C, ale tłum ML / Haskell prawdopodobnie miałby coś do powiedzenia na temat wątków.
Rei Miyasaka
+1 za „Dostęp API”: Myślę, że może to być nawet ważniejsze niż funkcje językowe.
Giorgio,
1

Składnia zdecydowanie ma znaczenie. Jest niezwykle cenny, jeśli składnia języka jest wystarczająco elastyczna, aby umożliwić utworzenie wygodnego i czytelnego języka specyficznego dla domeny dla aplikacji. Jeśli masz co do tego wątpliwości, wyobraź sobie, że możesz robić problemy z algebrą w prozaicznej łacinie, tak jak miało to miejsce przed XVIII wiekiem, lub wyobraź sobie, że wykonujesz rachunek różniczkowy bez znanego obecnie zapisu Leibniza. Oczywiście, tekst rachunku różniczkowego jest nieczytelny dla początkującego, ale dzięki praktyce możemy użyć rachunku różniczkowego i notacji Leibniza, aby szybko rozwiązać klasę problemów, które wymagały stron matematyki metodami klasycznymi. Programowanie to tylko kolejny kawałek matematyki. Wygodny zapis, blisko dziedziny problemowej, może mieć ogromną różnicę w wydajności.

Kevin Cline
źródło
DSL to nie tylko cukier składniowy. Semantyka jest znacznie bardziej wartościową częścią. Można zaprojektować eDSL, które nie dodadzą niczego do istniejącej składni.
SK-logic
@SK: jasne, ale semantyka jest pod pełną kontrolą programisty. Składnia jest ograniczona przez język podstawowy. Możemy budować wygodne DSL w Groovy i innych językach, ale nie tak bardzo w Javie.
kevin cline
1

Oto program, który oblicza wydział 6:

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)))))))

Składnia jest minimalna:

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

Wydaje się, że istnieje powszechne przekonanie, że składnia utrudnia język. Jak to często bywa przy powszechnych przekonaniach, jest dokładnie odwrotnie.

Zauważ, że składnia LISP jest czytelna (jeśli w ogóle), ponieważ ma dużo więcej składni niż powyższe. Jeśli więc fani LISP powiedzą ci, że „składnia nie ma znaczenia”, poproś o konsekwencję i wypróbuj rachunek SKI. Będą musieli przyznać, że trochę składnia wcale nie jest taka zła.

Ingo
źródło
Nie rozumiem głosowania w dół. To naprawdę wnikliwa odpowiedź. +1
scravy
0

Nie sądzę, żeby to miało znaczenie poza osobistymi preferencjami. Wszystkie rzeczy (wydajność, możliwości itp.) Są równe, wtedy rozumiem, dlaczego ktoś przykłada większą wagę do składni języka, ale decyduje się na pominięcie wydajności języków takich jak c / c ++ lub innego języka lepiej dostosowanego do tego zadania z powodu składnia wydaje się złym pomysłem dookoła.

Kurtis
źródło
6
Co powiesz na „czas wprowadzenia na rynek”, „koszt uzyskania korzyści” itp.?
Job
0

Tak, składnia ma znaczenie, chociaż tak naprawdę tylko dla czytelności. Porównać:

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

(Tak, to jest Python) z

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

(Tak, to właśnie język, który właśnie wymyśliłem) Oba zrobiłyby dokładnie to samo, w ten sam sposób, ale składnia jest inna, a Python jest łatwiejszy do odczytania. Tak, tak, składnia zdecydowanie ma znaczenie. Nawet „cukier syntaktyczny” ma znaczenie.

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

Jest łatwiejszy do odczytania niż

 def year(self):
     return self._date.year
 year = property(year)
Lennart Regebro
źródło
0

Tak, jasne.

Jeśli chcesz zainicjować wielki płomień, zapytaj ludzi, gdzie umieszczają bransoletę otwierającą w językach podobnych do C. mam na myśli

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

a nawet VS

void foo() 
{ // blah
}

A to tylko ten sam język! Zapytaj ich również o spacje, gdzie je umieszczają (nazwa funkcji i bransoleta, operatory itp.).

1000 odpowiedzi jest gwarantowanych!

ern0
źródło
nie chcę rozpalać ognia i jak dotąd mam dobre odpowiedzi i dziękuję wszystkim za udział i poszerzanie mojej wiedzy. Założę się, że inni ludzie uznali to za pomocne
Saif al Harthi
0

Składnia ma znaczenie. Jednak w dzisiejszych czasach powiedziałbym, że ma to znaczenie prawie całkowicie ze względu na czytelność, a nie tak naprawdę pod względem ilości wymaganych naciśnięć klawiszy. Dlaczego?

  • Jeśli naprawdę nie piszesz czegoś tak prostego, jeśli liczba klawiszy, które naciskasz, jest czynnikiem ograniczającym w pisaniu programu, albo naprawdę, naprawdę bzdurnie piszesz lub myślisz o wiele, o wiele za szybko.
  • Wszystkie przyzwoite IDE w dzisiejszych czasach mają dużą liczbę skrótów, co oznacza, że ​​nie musisz tak naprawdę pisać wszystkich znaków, których używasz przez większość czasu.

To powiedziawszy, jeśli jest zbyt szczegółowe, może dojść do punktu, w którym wpływa na czytelność. Wolałbym zobaczyć coś takiego:

foreach (String w stringList)

Do:

dla każdego ciągu znaków na liście, do którego odwołuje się zmienna stringlist

...każdego dnia!

berry120
źródło
0

Składnia ma znaczenie dla tych, którzy się jej uczą, im niższa bariera wejścia, tym bardziej popularny może być początkowo język. Ale jeśli język jest trudny lub niemożliwy do wyrażenia siebie w sposób bogaty i zwięzły, zacznie tracić na popularności.

Bardzo zwięzłe i nieprzezroczyste (Perl) jest tak samo złe, jak nadmiernie gadatliwe i wordy (AppleScript).

Konieczna jest równowaga, niższa bariera wejścia, wysoka wydajność i łatwa konserwacja.

użytkownik7519
źródło
-2

Inną rzeczą do rozważenia jest to, że języki programowania z ładniejszą składnią są łatwiejsze do analizy, dzięki czemu kompilator jest łatwiejszy do pisania, szybszy i mniej podatny na błędy.

asmeurer
źródło
3
Umm ... 10000 SLOC z parse.yRuby się nie zgadza. Istnieje powód, dla którego każda z 7 gotowych obecnie lub wkrótce gotowych do produkcji implementacji Ruby używa tego samego analizatora składni, a każda implementacja Ruby, która kiedykolwiek próbowała opracować własny analizator składni, zawiodła.
Jörg W Mittag,
A potem był niesławny język ADA. Oprócz specyfikacji języka istniało 100 programów, które musiały działać poprawnie, aby certyfikować kompilator. W składni było kilka bardzo subtelnych rzeczy. Krótko mówiąc, KAŻDY wczesny kompilator ADA zbudował kilka z tych programów. Naprawienie błędu nie było prostą sprawą, ale musieli zacząć od nowa od zera. Mimo ogromnego wsparcia ze strony rządu (wszystkie kontrakty DOD upoważniały ADA), zmarł nieszczęśliwą śmiercią.
Omega Centauri
-2

Krótko mówiąc: składnia jako taka nie ma znaczenia. Semantyka, którą możesz wyrazić za jej pośrednictwem, ma znaczenie.

back2dos
źródło
5
W ramach ćwiczenia napisz złożony parser w C, a następnie sterownik urządzenia w Haskell. Czy składnia ci pomogła? Następnie odwróć, ściśle zachowując semantykę obu programów. </irony>
9000
1
@ 9000: Widziałem kilka sterowników urządzeń w Haskell. Nie widziałem w nich nic szczególnie złego. Możesz rozwinąć temat?
Jörg W Mittag,
2
@ 9000, biorąc pod uwagę, jak trudno jest uzyskać sterowniki urządzeń bezpośrednio w C, nie jestem pewien, czy wybrałeś dobry przykład.
1
@ 9000: Właśnie o to mi chodziło. Konkretna natura konstrukcji składniowej nie ma znaczenia, to, co z nią wyrażasz. Język programowania z dokładną składnią Haskella , ale wykorzystujący inną strategię oceny, sprawi, że wiele Haskell będzie działało fatalnie, a nawet utknie w nieskończonych pętlach. Jeśli chodzi o konstrukty składniowe (lub szerzej: cechy językowe), nie liczy się ich konkretna składnia, ale ich semantyka, czyli to, co można za ich pomocą wyrazić.
back2dos
@ 9000, nie będzie problemu napisać parsera w Haskell ze składnią podobną do C (lub sterownikiem, używając C ze składnią podobną do Haskell).
SK-logic