Składnia Delphi kontra reszta świata

ten watek o tyle nie ma sensu, ze jest cala masa (niespodzianka) jezykow bezklamerkowych poza Pascalem...

Python, Ada, Rexx, Cobol, Basic, Lisp itd...

BTW, trochę humoru:
http://www.thealmightyguru.com/Humor/Docs/ShootYourselfInTheFoot.html
http://www.codeproject.com/Articles/927/Real-Programmers-Don-t-Use-PASCAL

Demonical Monk napisał(a)

Czego chcesz unikać? Właśnie odkryłeś, że istnieją również inne rodzaje scopingu, niż ten jedyny słuszny w Pascalu...

Chciałbym uniknąć jakichś niezbyt logicznych konstrukcji, które mogą powodować potencjalne błędy (chociaż ofc.wiadomo, że wszystko ma swoje wady i zalety).

Nadal nielogiczne?

Cóż, wiem, że pętla skończy się, gdy x osiągnie wartość zerową, lecz imo i tak średnio racjonalne (bo występuje niejawne rzutowanie int->bool), chociaż przydatne :P

Chyba każdy kto potrafi programować za pomocą begin end potrafi też { }

Ale nie każdy posługujący się klamerkami ogarnia delphi.

bueeeedleee napisał(a):

Ale nie każdy posługujący się klamerkami ogarnia delphi.

Nie każdy ogarniający delphi potrafi wieszać pranie.

Skoro już i tak wątek i pierwotny temat szlag trafił, to może przyłączę się do dyskusji na temat składni;

EDIT: gratuluję przezabawnego nowego tematu wątku :D

somekind napisał(a)

Ale gdzie w negatywnej opinii jest ten "irracjonalny hejt"?

Gdzie? Pół tego wątku to irracjonalny hejt na Pascala i to tylko przez tych, którzy w nim po prostu nie piszą; Bo najlepiej jest ktytykować coś, czego się nie używa, a główne argumenty są nie dość, że subiektywne, to wynikają po prostu z gustu a nie funkcjonalności; O gustach się nie dyskutuje;

somekind napisał(a)

To zjawisko spotyka tutaj raczej @mcodera, tylko dlatego, że wymienił kilka konkretnych wad Delphi.

Tu zagadka - przypomnijcie sobie świętoszki kto już od dawna najeżdżał na @mcodera i o co - nikt z Was nie jest bez winy;

somekind napisał(a)

A to, co opisał, czyli np. rozwlekłość składni (sekcja var, pojebane begin i end)
[...]
begin i end zaciemniają te miejsca, które wymagają ich użycia. Klamerki to jednak cztery razy mniej znaków, szybciej się je czyta, nie rozpraszają tak, jak słowa.

Poj#### jest twierdzić, że coś jest poj####używając poj#### argumentów; Sekcja var? Świetna sprawa dla tych, którzy lubią mieć porządek w kodzie (czyli pedantycznego mnie); Nie trzeba się zastanawiać gdzie co się zadeklarowało, bo wszytko w danej procedurze/funkcji/metodzie/wtf jest w jednym logicznym miejscu; begin i end jest poj####? A:

sub Foo(ByVal Bald As Integer)
  'code here
end sub

już nie jest? No pewnie - lepiej up#### się Pascala i wciskać kit, że ma najgorszą składnię tylko dlatego, że trzeba więcej napisać niż w tym "boskim" C/C++ jeśli są języki, w których napisać trzeba jeszcze więcej i których się nie hejtuje;

Komuś ciężko zauważyć begin i end jako początek/koniec bloku? To przypominam o takim złowieszczym fiuczerze jak "syntax highlighting" i w nowszych niż Delphi7 środowiskach - "code folding"; Rzeczą normalną są odmienne kolory dla słów kluczowych, przez co kod jest bajecznie czytelny; Czego nie można powiedzieć o klamrach w C/C++/C#/java, jeśli klamrę otwierającą blok pozostawia się na końcu linii i nie używa się wcięć jak Pan Bóg przykazał; Często poprawiam formatowanie kodu w dziale Newbie i szlag mnie trafia jak mi wcięcia nie pasują, bo jakiś gieniuś w nie dość, że nadziubdzianym kodzie zostawia klamrę otwierającą na końcu linii, np. nagłówku funkcji; To jest jeden znak, więc o wiele trudniej go zauważyć, niż pozostawiony na końcu linii begin skłądający się z pięciu znaków; Kolorowanie składni wcale Bóg wie jak nie uwidoczni tej klamry, za to "ogromnego" begin owszem, którego i tak powinno się przenosić do newej linii, bo takie są nieoficjalne (a może i oficjalne) "standardy" tworzenia kodu w Pascalu;

somekind napisał(a)

nierozróżnianie wielkości liter

To jest według Ciebie wada? Dla mnie to ogromny plus, przez co nie można obfuskować kodu przez pierdyliard takich samych identyfikatorów różniących się jedynie wielkością liter; Dzięki temu każda zmienna/procedura/funkcja/wtf ma inną nazwę i nie trzeba się domyślać jej przeznaczenia; Pewnie - to jest minus oczywiście i jak zwykle dla tych, którzy piszą w C lub pochodnych językach;

semekind napisał(a)

różne sposoby wywoływania metod (o ile dobrze zrozumiałem, to jest to syf największy z możliwych)

Mam podobne zdanie, choć nie aż tak bardzo negatywne; Też denerwuje mnie to, że można wywołać procedurę/funkcję (która nie posiada argumentów) bez klamer - dlatego tego nie stosuję; Zawsze i każdą procedurę/funkcję/metodę wpisuję z nawiasami, dlatego zawsze wiem gdzie one są, a gdzie są zmienne czy stałe; Jeśli ktoś nie stosuje klamer przy wywoływaniu ww. elementów to zaciemnia kod i to jest wadą; Osobiście je stosuję i nigdy nie mam problemu ze zrozumieniem kodu;

somekind napisał(a)

"udziwnione" operatory porównania i przypisania.

No tak, dziwne jest to, że operator równości oznacza faktyczną równość; Po raz kolejny używasz bezsensownych argumentów przeczących ustalonym od wiek wieków standardom;

Wiesz co jest nienormalne? To, że w językach ceplusplusowatych część operatorów ma zupełnie inne znaczenie, niż się tego można spodziewać: = to nie jest równość, a przypisanie, == jest równością, co dziwacznie wygląda, != jest operatorem "różności", oczywiście inne znaczenie niż <> w matematyce;

somekind napisał(a)

Takie rzeczy faktycznie nakłaniają do pisania niechlujnego kodu, i utrudniają zmianę języka, bo wymaga ona złamania wielu przyzwyczajeń.

No tak, teraz trzeba mieć pretensję do twórców wszystkich języków, które nie mają zerżniętej na żywca składni z C; Na szczęście są jeszcze języki z czytelną skłądnią, jak choćby wspomniany wyżej VB; Jednych podnieca obfuskowanie kodu nieczytelnymi znaczkami, innych cieszy dłuższy, ale o wiele bardziej czytelny kod;

somekind napisał(a)

Nie. Fajnie jest mieć jak najmniejszy zasięg, a nie musieć wszystkiego deklarować na początku pliku jak w XIX w.

Widać Twoje pojęcie o Pascalu jest zbyt małe na obiektywną ocenę; Poza tym widać zatrzymałeś się w latach 70/80-tych operając się na manii deklarowania wszystkiego globalnie;

Na szczęście bardzo dobrą i szeroko stosowaną techniką jest dbanie o jak najmniejszą widoczność i dzielenie kodu na "jednoekranowe" bloki znacznie ułatwiające zrozumienie kodu; Jeśli ktoś nawali milion zmiennych i procedur/funkcji globalnych nie dbając o ich widoczność i bezpieczeństwo to po prostu jest niechlujem - powinien wrócić do kursu z podstaw kodzenia;

somekind napisał(a)

= to porównanie
:= to przypisanie
Jest to logiczne i zrozumiałe dla każdego, kto miał z tym językiem kontakt na przynajmniej parę dni.

A co w tym logicznego?

Nie wiesz? Symbol := czyta się (z matematyki) jako "zdefiniowane jako, (równe) z definicji" i ma to jak nabardziej sens logiczny;

Logiczne jest, że wpajany od dziecka w szkole na matematyce operator równości oznacza równość, a operator przypisania, który ma inne przeznaczenie ma ma inny identyfikator; Podobnie ze znakiem różności - <> - który tak samo jest zgodny z matematycznym zapisem; Tylko że zaraz ktoś się przyczepi, że operator negacji to słówko not, który oczywiście z racji swojej ogromnej długości pisze się przez pół godziny - podobnie z koniunkcją and i alternatywą or; Ileż to trzeba się opisać...

somekind napisał(a)

Wszyscy przecież wiedzą, że C++ to obrzydliwy język, ale nie o to tu chyba chodzi.

Nie twierdzę tak, ale i nie wypowiadam się o funkcjonalności C-pochodnych języków, bo najzwyczajniej w świecie mam nikłe o tym pojęcie; Cały czas bijecie w składnię Pascala (mniej w funkcjonalność);

somekind napisał(a)

Ja bym powiedział, że zależy od jednego i drugiego, ale od składni bardziej. Bo nieczytelnego programistę można nauczyć lepiej pisać, ale składni zmienić się nie da.

A to ciekawe, czy niechlujny programista bardziej zobfuskuje kod języka przywiązującego większą wagę do czytelności kodu (tu: Pascala/VB) czy pozwalającego na większą swobodę (tutaj: C i pochodne);

vpiotr napisał(a)

ten watek o tyle nie ma sensu, ze jest cala masa (niespodzianka) jezykow bezklamerkowych poza Pascalem...

Nie ma sensu, bo hejtuje się tutaj Pascala za "czytelną składnię" bardzo prostą do zrozumienia tylko dlatego, że po pierwsze jest inna od ceplusplusowatych języków, a po drugie - trzeba więcej pisać.

Wybacz @somekind, że w większości cytowałem Twoje słowa - użyłeś akurat wszystkich argumentów, które można łatwo obalić; Wypowiadam się jedynie w kwestii składni języka, który tak hejtujecie;

Nie uważam, że Pascal jest najlepszym językiem (rzutując na całokształt) bo wyniki popularności mówią same za siebie - górują C/C++/Java i to prędko się nie zmieni; Osobiście nie piszę w nich głównie dlatego, że nie podoba mi się składnia, która de facto jest bardzo ważna; Za to w najbliższym czasie zamierzam bliżej poznać VB, bo urzeka mnie od dawna jego składnia i niesamowita czytelność kodu.

furious programming napisał(a):

Nie uważam, że Pascal jest najlepszym językiem (rzutując na całokształt) bo wyniki popularności mówią same za siebie - górują C/C++/Java i to prędko się nie zmieni; Osobiście nie piszę w nich głównie dlatego, że nie podoba mi się składnia, która de facto jest bardzo ważna; Za to w najbliższym czasie zamierzam bliżej poznać VB, bo urzeka mnie od dawna jego składnia i niesamowita czytelność kodu.

To też zależy w czym górują.
W rozmiarze kodu "legacy" to chyba nadal COBOL...
Na git - np. JavaScript: https://github.com/languages
Sourceforge - Java
Mix nie-wiadomo-czego (popularność?): C - http://lang-index.sourceforge.net/

A tak naprawdę to chciałem napisać, żebyś przemyślał ten VB (o ile to pisałeś na serio).
Microsoft promuje w pierwszej kolejności C# i możliwe że VB pójdzie w odstawkę (jako język stricte jednego producenta).
Na pocieszenie dodam, że C# projektowali goście od Delphi (Anders Hejlsberg), co się objawiło (prawdopodobnie) np. w obecności properties:
http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx

Patryk27 napisał(a):

Ja bezproblemowo radzę sobie z rozpoznawaniem wywołań procedur, głównie dlatego, że czym innym może być foo;, jak nie wywołaniem procedury (a w razie czego IDE dodatkowo podpowiada)? ;)

To powiedz mi co to jest:

procedure TForm1.Button1Click(Sender: TObject);
begin
  foo1 := foo2;
end;

Przypisanie zmiennej do zmiennej? Nie.

var
  Form1: TForm1;
  foo1 : Integer;

implementation

{$R *.dfm}

function foo2(): Integer;
begin
  //some code

  Result := 1;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  foo1 := foo2;
end;

Przypisanie zmiennej do zmiennej? Nie.

Kto normalny nazywa funkcję foo2? To jest niekonsekwencja w nazewnictwie, co powoduje zagmatwanie kodu. Kolejny idiotyczny przykład.

Patryk27 napisał(a):

Kto normalny nazywa funkcję foo2?

Ty :D

Patryk27 napisał(a):

czym innym może być foo;, jak nie wywołaniem procedury (a w razie czego IDE dodatkowo podpowiada)? ;)

Nie sądziłem, że w epoce Javy, C#, PHP, .NET itd. będą jeszcze możliwe kłótnie o wyższości Pascala nad C (i na odwrót) i ich potomnymi. Najbardziej jednak rozbawił mnie argument, jakoby zaczynanie od Pascala/Delphi uczyło złych nawyków. Eksperymentowałem z różnymi językami, w tym C, C++, C#, Pascale, Ada... nawet w awk-u popełniłem parę skryptów. Niestety, wtedy jeszcze nie wiedziałem, że Pascal przyzwyczaja do złego i najnormalniej w świecie nie miałem problemów z przestawieniem się na cokolwiek innego.

A żeby nie nabijać postów po próżnicy dorzucę tylko kilka przemyśleń:

• w każdym języku jest coś, co uważamy za wygodne i coś, co przeklinamy.
• Widywałem czytelny kod w C-podobnym języku i nieczytelny w Pascalu i na odwrót. Składnia języka nie ma tu nic do rzeczy. O wiele większe znaczenie ma logiczne rozplanowanie kodu i odpowiednie jego sformatowanie (nazewnictwo, wcięcia, odstępy, komentarze, ozdobniki). Ma to szczególne znaczenie w przypadku pozagnieżdżanych jednolinijkowych pętli, if-ów else-ów itp. Czasem nie wiadomo, gdzie który blok się kończy i jak ma działać. Pod tym względem sztywne rozwiązanie z Ady bije na głowę wszystko.
• Nierozróżnialność wielkości liter jest DLA MNIE wadą - po pierwsze ogranicza dostępne dla nas "słownictwo" (weszło mi już w krew, że String i string to zupełnie różnie rzeczy), a po drugie daje przyzwolenie na niechlujstwo - widzieliście kod w Pascalu napisany samymi małymi literami? Po kilku godzinach czytania czegoś takiego bolą oczy! Komuś może to nie przeszkadzać. Mnie przeszkadza. żeby nie było - kod w C napisany w ten sam sposób również będzie nieczytelny.
• Pascale to pełnowartościowe HLLe. C/C++ bardziej przypominają assemblera wzbogacanego co jakiś czas o nowe "ficzery". Z drugiej strony, nadmierne ustrukturowienie i uściślenie języka bywa niewygodne w praktyce. Sekcja Var w Pascalu jest dobra, gdy uczysz się programowania. Potem zaczyna być zbędnym uprzykrzeniem. Zwłaszcza, gdy poprawiasz stary kod, gdzie jest 20 zmiennych lokalnych, o podobnych nazwach, ale innych typach, a procedura, w której są użyte, ma 200-300 linijek. Rozwiązanie C-podobne jest tu dla mnie dużo wygodniejsze i bardziej czytelne.

Odnośnie pytania o wybór języka - C++ jest o tyle dobre, że jest oparty o bardzo popularną składnię, używaną w wielu innych językach, przez co przesiadka na coś innego (Javę/C#) będzie nieco bardziej płynna. Napisałem 'nieco', bo wymienione języki, poza podobną składnią, mają niewiele wspólnego i każdy z nich, tak czy inaczej, trzeba poznawać od początku.

Ok, mógłbym napisać:
'Czym innym może być TCompiler.CompileError, jak nie wywołaniem procedury*?'
Z tym, że ja miałem stricte na myśli fragment składni: identyfikator + średnik, a Ty podajesz jakiś nierealny kod na obalenie sensu tej konstrukcji :P
Przykłady podaje się uproszczone, podczas gdy próby udowodnienia sensu czegoś (lub jego braku) powinny być jak najbardziej 'z życia wzięte'.

Patryk27 napisał(a):

Bardziej chodzi o to, gdy np.mówisz, że nie lubisz Xyz, bo coś tam coś tam coś tam i twierdzisz, że Abc jest lepsze uzasadniając to jakimiś nierealnymi przykładami, które ukazują wybrane zalety Abc, a nie są ani trochę obiektywne i po prostu... nota bene idiotyczne.

Ale gdzie te nierealne przykłady?

Kwestia przystosowania imo; ilekroć patrzę na jakiś dłuższy C++-owaty kod, to zaczynam dostawać mini ataku epilepsji od tych klamerek.
Poza tym, gdyby to było kompletnie złe rozwiązanie, nie zostałoby zastosowane np.w Rubym.

Nie mówię, że jest kompletnie złe. Mówię tylko, że jest niepotrzebne. Słowa powinny oznaczać ważne rzeczy, które mają rzucać się w oczy: instrukcje i identyfikatory, a nie operatory, ani nie takie detale jak początki bloków, których spokojnie można by w ogóle nie oznaczać.

Dawanie programiście dostępu do klawiatury jest samo w sobie przyzwoleniem na niechlujstwo, nie mówiąc o angażowaniu go w jakiś projekt.

Wiesz, ja tutaj próbuję poważnie dyskutować, a z takimi tekstami jest trudno.

Cóż, again: kwestia przyzwyczajenia. Ja bezproblemowo radzę sobie z rozpoznawaniem wywołań procedur, głównie dlatego, że czym innym może być foo;, jak nie wywołaniem procedury (a w razie czego IDE dodatkowo podpowiada)? ;)

Często fajnie móc zrobić coś na kilka sposobów, ale nie w tak elementarnej sprawie, jak wywołanie funkcji. Mi to wygląda na coś potencjalnie mylącego.

A to C++ nie pozwala na nazywanie wszystkiego małymi literami, wielkimi literami lub w camel-case?

Nie. Jak zadeklarujesz zmienną foo, to nie odwołasz się do niej przez FOO ani Foo. W w większości normalnych języków też tak jest.

Chyba nie rozumiem pytania: to są po prostu dwa odmienne operatory, w C++ ich odpowiednikami są = oraz ==, dla programisty Pascala właśnie podejście C++ jest nielogiczne i vice versa :P

Mi po prostu przymiotnik "logiczny" nie pasuje w tym kontekście. To jest umowa i przyzwyczajenie, a nie logika.

Można by natomiast się wykłócać o logiczność takiego C++owego kodu:

if (a=10)

Nie mam zamiaru się o to kłócić. To jest akurat kompletny bezsens i źródło problemów, które nie ma żadnych zalet.

I w ogóle nie rozumiem Twojej kontrargumentów opartych na C++. Czy ja napisałem tutaj coś dobrego o tym języku? **Odniosłem się tylko do kilku wad języka programowania, bo nie chodzi nawet o to, że występują one akurat w Delphi. Po prostu te rozwiązania są złe. **
Nigdzie też nie napisałem, że Delphi to jest zły język, że ma same wady i żadnych zalet, itp.
A w ogóle, to nie chodziło mi o Delphi, tylko o hipokryzję, którą tutaj się uprawia.

Programs must be written for people to read, and only incidentally for machines to execute.

No właśnie. I begin oraz end albo różne możliwości odwołania się do tego samego identyfikatora mają w tym pomóc?

furious programming napisał(a):

Tu zagadka - przypomnijcie sobie świętoszki kto już od dawna najeżdżał na @mcodera i o co - nikt z Was nie jest bez winy;

Nie przypominam sobie, żebym to robił, ale jeśli kojarzysz jakieś moje najazdy na niego, to proszę, podlinkuj.

Sekcja var? Świetna sprawa dla tych, którzy lubią mieć porządek w kodzie (czyli pedantycznego mnie); Nie trzeba się zastanawiać gdzie co się zadeklarowało, bo wszytko w danej procedurze/funkcji/metodzie/wtf jest w jednym logicznym miejscu;

Porządek polega na niezaśmiecaniu, zmienne zadeklarowane wcześniej niż trzeba, to śmieci. Po co dostęp do czegoś, co nie jest potrzebne? I nie jest to wada jedynie Delphi.

begin i end jest pojebane? A:

sub Foo(ByVal Bald As Integer)
  'code here
end sub

już nie jest?

A kto pisał, że nie jest? Oczywiście, że jest złe, jak wszystkie nadmierne śmieciowe słowa kluczowe.
Tylko w tym wątku nikt nie poruszał tematu VB, więc o co Ci chodzi?

No pewnie - lepiej upierdolić się Pascala i wciskać kit, że ma najgorszą składnię

Ale... Kto i gdzie tak napisał? Bo jeśli nikt, nigdzie, to masz jakieś urojenia.

Dla mnie to ogromny plus, przez co nie można obfuskować kodu przez pierdyliard takich samych identyfikatorów różniących się jedynie wielkością liter;

Nikt tak nie robi.
A rozróżnienie jest wygodne, dzięki niemu np. w C# można mieć pole myValue, właściwość MyValue i każdy wie co jest czym.

Po raz kolejny używasz bezsensownych argumentów przeczących ustalonym od wiek wieków standardom;

Języki programowania pojawiły się w zeszłym wieku, na dodatek chyba większość z nich stosuje przypisanie przez znak =.

Wiesz co jest nienormalne? To, że w językach ceplusplusowatych część operatorów ma zupełnie inne znaczenie, niż się tego można spodziewać: = to nie jest równość, a przypisanie, == jest równością, co dziwacznie wygląda, != jest operatorem "różności", oczywiście inne znaczenie niż <> w matematyce;

Ja tu widzę przynajmniej spójność: ==, <=, >=, !=

No tak, teraz trzeba mieć pretensję do twórców wszystkich języków, które nie mają zerżniętej na żywca składni z C;

NIC w tym wątku nie pisałem o C.

Na szczęście są jeszcze języki z czytelną skłądnią, jak choćby wspomniany wyżej VB;

Tak, język, w którym pisze się poematy, zamiast programów, który ma więcej słów kluczowych niż wszystkie pozostałe razem wzięte.

Widać Twoje pojęcie o Pascalu jest zbyt małe na obiektywną ocenę; Poza tym widać zatrzymałeś się w latach 70/80-tych operając się na manii deklarowania wszystkiego globalnie;

WTF? Co Ty pijesz, że takie wnioski wyciągasz?
Niczego nie robię globalnie, wszystkie zmienne deklaruję jak najbliżej miejsca ich użycia.

Logiczne jest, że wpajany od dziecka w szkole na matematyce operator równości oznacza równość, a operator przypisania, który ma inne przeznaczenie ma ma inny identyfikator; Podobnie ze znakiem różności - <> - który tak samo jest zgodny z matematycznym zapisem;

Programowanie, to nie jest matematyka. Tu nawet liczby zazwyczaj nie działają tak, jak w matematyce.

A to ciekawe, czy niechlujny programista bardziej zobfuskuje kod języka przywiązującego większą wagę do czytelności kodu (tu: Pascala/VB)

Jakiej niby czytelności? Czym wyrażonej? Większą ilością słów niż znaków?
Muszę Cię rozczarować, czytelność nie na tym polega.

Wybacz @somekind, że w większości cytowałem Twoje słowa - użyłeś akurat wszystkich argumentów, które można łatwo obalić; Wypowiadam się jedynie w kwestii składni języka, który tak hejtujecie;

Nie hejtuję tutaj żadnego konkretnego języka, jeśli ktoś tak uważa, to niech się nauczy czytać ze zrozumieniem i nie dopowiadać sobie.

Jeśli już się tak przyczepiliście tych nawiasików, to kontr-przykład w C++:

MyObject object(123); // wywołanie konstruktora
MyObject object; // wywołanie konstruktora
MyObject object(); // surprise! deklaracja funkcji

To jest konsekwencja?

Przecież to wszystko rzeczy umowne... Gdyby trzymać się tego ściśle to:
x = x + 1
Byłoby przecież największym kłamstwem świata.
Moim zdaniem Pascal na początek jest dobrym językiem, sam od niego zaczynałem. Składnia to kwestia gustu, czytelności - przecież nawet w obrębie jednego języka trzeba się czasem zastanawiać jakiej składni użyć. Operator ?: czy lepiej if. Albo foreach vs LINQ (czasem w R# gdy kliknie się w convert to linq można się nieźle uśmiać z tego co otrzymamy). Takie void też jest ciekawe, słowo kluczowe do stwierdzenia, że nie będziemy nic zwracać - a gdyby użyć coś na wzór Pascala:
func Funkcja(int a, int b) : int
proc Procedura(string a)
Byłoby tylko kilka znaków więcej, a uniknęlibyśmy podanej przez @vpiotr niejednoznaczności.
Swoją drogą, czytałem kiedyś wywiad z Brendanem Eichem (twórcą JS), który zastanawiał się, czy zamiast słowa function nie zastosować lambda. Argumentacją za tym pierwszym było to, że... zbyt dużo osób nie wie co to lambda i tego wtedy nie zrozumie ;)

Nie czepiajcie sie aż tak tego Delphi. Są języki z gorszą składnią, jak np pl-sql, bash albo nie daj Boże perl (czyli rzucanie kotem o klawiaturę). Ja osobiście preferuję składnię a'la C/C++/C.

Tak w ogóle, dość dziwne jak bardzo pl-sql momentami przypomina pascala