Wpis z mikrobloga

uwaga #programowanie #niepopularnaopinia

szkoda że #delphi i #pascal umarło. nie to że bym chciał żeby pascal był wiodącym językiem na rynku ale spójrzcie na to obiektywnie

1. Jako kompilator C i Pascal walczyli z soba na długo
2. Kompilator pascala/delphi dalej jest ciągle dobry. Project lazarus zrobił kompilator nawet na gameboya adv :)
3. Pascal jest doskonałym językiem do nauki bo piszemy tak jak mówimy "begin" "end" itd i pewnie wielu go za to hejtuje jak spotka się z nim na uczelniach
5. Zarąbisty RAD. Tu się nie mogę wiele wypowiedzieć, może Visual Studio albo inne też dają radę, są generatory form, ale w Lazarusie/Delphi świetnie to działa, klikacie dwa razy i piszecie kod :)
6. Dobre OOP i skłądnia. Jak zamienicie begin i end na klamry to kod wygląda podobnie do wiodących dziś języków jak #java.

Nie żebym był wielkim fanem pascala i żebym kiedykolwiek w nim kodził oprócz prostych aplikacji ale to był i jest porządny język

tu macie popularny rant na pascala http://www.lysator.liu.se/c/bwk-on-pascal.html a tak naprawdę to tam wiele nie ma.

oczywiście języki od czasów pascala i delphi o wiele bardziej dojrzały nie można porównywać C++ do niego.

tldr; pascal to był dobry język na swoje czasy i jest ok do nauki okażcie szacunek dziadkowi.
  • 22
@KwadratowyPomidor2: pamiętam w zinie AM Komputery (dołączany do płyty z CD Action) była zacięta dyskusja czy lepszy C czy Pascal.

Pascal dobry do nauki, ale obecnie równie dobry jest np. Python.

W Pascalu mam sentyment do operatora przypisywania := zamiast =. Bo matematycznie to jest bardziej prawidłowe (a w obecnych językach to tylko umowne).

Ale chodzi o wydajność pisania. Operator = szybciej napisać niż :=, klamerki szybciej napisać niż begin/end.
@KwadratowyPomidor2: lubię Delphi, ale Twoje argumenty są słabe. begin/end a klamerki to akurat żadna różnica - i tak się czyta wcięciami. OOP rzeczywiście jest w Delphi lepsze, niż w C++, ale to niewielkie osiągnięcie ;) Mi się najbardziej podobał system modułów - dużo lepiej przemyślany, brak prywatnych pól w plikach nagłówkowych (to chyba największa durnota C++), brak haków typu #include i #ifndef. no i czasy kompilacji rzędzy wielkości mniejsze niż
@mk321: operator = jako przypisanie powoduje, że masz == zamiast =, więc nie zyskujesz wiele (a czasem nawet tracisz). Wolałem := bo trudniej zrobić literówkę

if (x := 5) // Delhi tego nie skompiluje, z resztą kto by tam wpisywał : niechcący

niż

if (x = 5) // C++ nie widzi przeszkód, a niechcący za słabo kliknąć się zdarza.

To na tyle częsty problem, że niektórzy progrmują tak:

if (5 ==
RAD był fajny, bo prosty, ale tworzyło się formatki pod konkretną rozdzielczość, co jest słabe. Dużo lepszy w qt, i to przynajmniej od kilkunastu lat (już qt3 było lepsze). Głównie dlatego, że sygnały/sloty kopią dupę wszelkim frameworkom opartym na callbackach, listenerach, czy jak to sobie nazwiesz. No i layouty qt są dużo lepiej przemyślane.


@tell_me_more: o to ciekawe. nie robię zawodowo aplikacji desktopowych ale czasem sobie coś machnę sam dla siebie.
if (x := 5) // Delhi tego nie skompiluje, z resztą kto by tam wpisywał : niechcący

niż

if (x = 5) // C++ nie widzi przeszkód, a niechcący za słabo kliknąć się zdarza.

To na tyle częsty problem, że niektórzy progrmują tak:

if (5 == x)

Choć oczywiście wystarczyłoby włączenie ostrzeżeń.


@tell_me_more: każde IDE ci pokazuje ostrzeżenie co jest plusem i minusem bo jednak czasem tak chcesz

ale w sumie
Z resztą w dzisiejszch czasach takie rzeczy, jak się pisało w Delphi można machnąć w qml i napisać ui deklaratwnie. Używam tego w pracy i jest zajebiste - są nawet maszyny stanów więc możesz sobie rozpisać, że formatka ma 3 komponenty, każdy z nich ma wypisane kilka stanów i przejścia pomiędzy nimi, a konkretne kontrolki mają przypite animacje zależne (w deklaratywny sposób - czyli bindingami nie ifami - czyli zależność jest uaktualniana
osobno generator osobno kod


No i właśnie to jest plus qt, że jednak sugeruje sensowną strukturę kodu, a nie TButton1, TButton2, TButton14.

czemu sygnały i sloty są lepsze?


@KwadratowyPomidor2: bo pozwalają pisać klasy które współpracują ze sobą a nic o sobie nie wiedzą. Pozwala to wydzielić kod pośredniczący poza te klasy. Jak dla mnie to jedno z najlepszych wynalazków ułatwiających pisanie ładnego kodu.

Drugi to pythonowe generatory - też z tego
Ale odbiorca musi sobie rzutować tego sendera na właściwy obiekt, jeśli chce cokolwiek z niego pobrać. Czyli musi klasa odbiorcy mieć wiedzę o typie tego obiektu. To niepotrzebna zależność, którą system sygnałów i slotów eliminuje.


@tell_me_more: a jak inaczej to działa w OOP? jak to sygnały i sloty rozwiązują?

jak mówię nie jestem znawca zrobiłem tylko kalkulator w QT i C++ ale z tego co widziałem to działało to podobnie jak
@KwadratowyPomidor2: no w qt piszesz np tak:

//biblioteka A
class A1 {
...
signals:
somethingHappened(int x, string s);
};

//biblioteka B
class B1 {
...
public slots:
void doSth(int x) { ... };
};

//twój kod
#include
#include A1 a1;
B1 b1;
connect (a1, SIGNAL(somethingHappened(int, string)), b1, SLOT(doSth(int)));

Zauważ, że nie ma ingerencji w żadną z klas. Jedynym wymaganiem jest to, żeby parametry z sygnału wystarczały do wywołania slotu (niekoniecznie muszą
Odkopuję ( ͡° ͜ʖ ͡°) U mnie w firmie piszemy w delphi. Szef uważa, że Delphi jest dobre dla małych firm i coraz więcej będzie na nie przechodzić, bo znając jeden język można pisać na wiele platform (Android i IOS chociażby). Nie wiem na ile prawdziwe są takie przewidywania więc pytam bardziej doświadczonych @tell_me_more: @Dzyszla: @KwadratowyPomidor2: @Ragnarokk:
@XailonOZ embarcadero strata się stworzyć wieloplatformowe środowisko, ale o pisaniu jednego kodu na każde tak różne urządzenia można zapomnieć. Niestety, nie korzystam z tego wprost, więc trudno mi coś praktycznego powiedzieć. Natomiast czy małe firmy? Jest to dość drogie.