Názory k článku Integrované vývojové prostředí Lazarus: jen zdánlivý anachronismus

Škodaže neni aj alternatíva k C Builderu... pre C++. Object pascal som kedysi používal, ale už si z toho nič nepamatám... viem že pointery sa v Pascale robili strieškou, namiesto hviezdičky, ale to je tak všetko. Prečo nemohli to IDE rozšíriť aj o iné jazyky? Ten komponentový spôsob programovania nebol najhorší, na rýchly vývoj aplikácií je ot ako stvorené. Ešte je tu Qt ale to je zase trošku o inom.

Když jsem Lazarus před měsícem začal testovat, tak to pro mě byl návrat o 20 let zpátky. Mezitím jsem Pascal vlastně neviděl, ale dalo si zvyknout vcelku v pohodě. Ano, má to svoje specifika a někdy i nelogičnosti, ale to každej dnešní jazyk, takže na naklikání GUI + reakcí dobré (a další věci jdou psát v něčem jiném, když bude potřeba).

Ad rozšíření - to by bylo skutečně dobré.

Ohledně C++, nedávno jsem něco plodil v Ultimate++ . Není to sice kopie BCB, to IDE je poněkud "svoje", ale podle mého jsou některé věci (třeba nativní dědičnost vizuálních tříd) řešeny lépe než v BCB (to býval trochu kočkopes s pascalovou OWL pokud se nepletu) a třeba ve srovnání s klasickým QT vizuálním designérem formulářů má mechanika U++ formulářů blíž wokenním RADům (Delphi). = Řekl bych že hoši od U++ odvádějí veliký kus poctivé práce.

Upp by možná byl i na samostatný článek.

Je to ale další z toolkitů, co člověku nutí svůj "správný" styl a v tom frameworku je řada věcí, které člověk vůbec nepotřebuje (třeba různé parsery a tak, které používají v tom jejich vlastním IDE).

Zjevně jste se do U++ ponořil hlouběji než já :-)
No... jasně že grafickým GUI designerem je člověk maličko sešněrovaný - to je daň za rychlé klikací skládání GUI. Zkusil jsem si cvičně i tu svobodu, napsat základ GUI aplikace v holém MinGW GCC - děkuju nechci :-)
Třeba vnímám, že každý ten "framework" má nějaký svůj způsob, jak přivázat na různé akce či události v GUI obslužné funkce (callbacky). Toto není standardní součást C++, tak holt to má každý nějak po svém, jako nadstavbu. Já jsem hobbík a moc jsem toho nezažil, ale pokud srovnám BCB, Qt a U++, tak mi připadá, že v U++ mám největší svobodu. Je to nejblíž duchu standardního C++ a v "maximální užitečné" míře to vychytávky moderního C++ využívá. Jasně, U++ má spoustu "svých" datových typů a tříd (i nevizuálních), obvykle s velkými písmeny na začátku - v tomhle jejich "vesmíru" máte třeba dost bezešvě vyřešený Unicode, pokud se správně pamatuju... ale můžete prakticky stejně svobodně využívat STL nebo co se to vlastně k moderním překladačům přibaluje, můžete používat standardní Céčkové konvence a knihovní funkce...
A jestli se správně pamatuju, tak svoji "standardní knihovnu" včetně "contrib" komponent (bazaar) to má ve zdrojácích, takže pokud pozměníte nějaké základní CFLAGS, tak si to při prvním dalším buildu prakticky překompiluje i všechny použité součástky ze své "standardní knihovny" :-)
Já jsem v U++ klikal dost primitivní vizuální aplikaci, a dost mi v základech pomohli klíčoví vývojáři, kteří se vyskytují na fóru (Mirek a Iňaki). Dohromady jsem byl příjemně překvapen.

Tenhle způsob práce s pointery skoncil s pascalem pro Delphi 1 pred cca 30 lety. Jazyk se posunul obrovsky, má většinu moderních rysů. IDE se pokusili rozšířit o PHP (HTML Builder), ale to se neujalo.

Hmm pascal (Turbo/Borland), to uz je dlouho, kdysi na VS. Koukam ze porad zije, myslel jsem ze uz skoncil v propadlisti dejin. Kdyz nad tim premyslim vic ma vlastne vsechno co je potreba, i kdyz ja do te reky uz asi nevstoupim :)

No já kdysi v Delphi napsal diplomku a byl to skutečně RAD - ten vývoj šel dopředu strašně rychle. Teď se chystám na jednu appku s dost složitým GUI (tedy spíš než složitým, tak se dá předpokládat, že se bude velmi často měnit), tak hoodně uvažuju o tom vykašlat se na dnešní mainstream*, překousnout ten Pascal a naklikat si to v Lazaru :-)

* mainstreamem se zdá být Electron, to se mi nechce hned ze tří důvodů :-)

No, embarcadero (nastupce borlandu) vydava i community verze delphi a c++builderu . Asi pred tydnem jsem na to prisel a uz jsem si zacal naklikavat appku pro sebe :)
Je tam nake omezeni na zisky za rok, ale na osobni projekty se to zda dost dobre pouzitelne. A jelikoz poskytuje i c++builder, tak nemusim oprasovat zase Pascal :)

Díky, podívám se na to. Já jsem už sice pár let linux-only, ale třeba i pro Linux něco budou mít (Kylix těžko...)

Linux je tam jako target, to znamená můžete pro něj vytvářet aplikace včetně grafických, IDE zůstává na Win :(

Tady je návod Delphi + WSL + Linux https://www.youtube.com/watch?v=AD9XG4Y7MwA

6. 1. 2022, 19:06 editováno autorem komentáře

Kylix nikdy nefungoval. To byl pokus ktery nebyl dotazen ani do faze alpha.

Mainstream si, kdo ví proč, vždy vybírá to nejmasochističtější řešení :-)

V Delphi jsem delal sve prvni komercni programy (pred 20+ lety) a ten vyvoj byl opravdu neuveritelne rychly. Smutne je, ze s dnesnimi state-of-the-art postupy clovek neni ani z poloviny tak efektivni jak pred temi dvaceti lety. :-/

Dneska, kdyz chci udelat rychle GUI aplikaci, tak sahnu Java + JavaFX/OpenJFX, neni to sice tak vyladene jako Delphi, ale aplikace vypadaji hezky, vyvoj v tom docela odsypa a neni to nenazrany slepenec v podobe Electronu.

S BP/Delphi je pro me problem ten, ze jazyk odpovida koncepcne devadesatym letum a tehdy nemel prakticky zadne prostredky, ktere by umoznovaly funkcionalni pristup k programovani.

Nebo se situace zmenila a pribyly tam funkce vyssiho radu (map, filter, fold...) a anonymni funkce?

Trošku problém je, jak ty JavaFX aplikace zapadají do desktopů, to taky není ideální. Ale zase Electron appky nezapadají vůbec :) Ten vývoj desktop GUI se tedy od dob Delphi pohnul špatně IMHO

No v stejnou GUI libku (vcl) pouziva i c++builder, kde je dneska k dispozici c++17. A to i v communty verzi, takze neni problem s novejsim jazykem.

Těch konstrukcí v object pascalu přibylo obrovské množství - generika, anonymní metody, atributy, class helpery, inline deklarace proměnných, rozšíření možností záznamů, ... Bohužel nedokážu říci, co všechno už umí Free pascal. Jak psal kolega výše, free verze je k disposici.

Jo ještě - ta diplomka byl relativně složitý program a přitom překlad na 486 s 8MB paměti byl prakticky okamžitý. To Borlandi prostě uměli (+ pomohla samozřejmě gramatika Pascalu).

Absolútny súhlas. Borland Delphi 7, bola iná rýchlovka v kompilácii. Ale ten zážitok, keď roky po troške programujete emulátor MZ-800 v Lazarovi a ono sa to po skutočne drobných úpravách spustí v Linuxe, je neopísateľný. Beží mi to aj na Raspberry Pi. Len ho musím dotiahnuť do konca, aby to bolo použiteľné aj mimo moju osobu. :-)

Já nevím jak moc je to klikací, ale takové Pharo + Spec na GUI nevypadá špatně.

Spec je z pohledu programátora, co ho používá, asi nejpohodlnějí použitelný GUI framework, co jsem kdy viděl, ale klikací není vůbec. Udělal jsem alespoň prototyp jednoduchého GUI editoru, kde se elementy a layout definují jako strom - s živým náhledem na výsledek (https://pbs.twimg.com/media/EwGhFiLXEAAMnUV?format=png&name=large)

To je skvělé! Nenabízíte nějaké kurzy programování ve Smalltalku?

Jake jsou ty tri duvody proc nechcete electron?

Za mě třeba nutnost s sebou tahat celý webový prohlížeč (Hello World má 100 MB) nebo hackovat integrované webové jádro na daném OS (konec write once, run everywhere), které často nemusí stačit (omezení od Apple, případně stejně nutnost doinstalovat Edge Chromium na starší Windows, jinak tam je jen Edge UWP nebo dokonce jen IE11). Stejně jako webový prohlížeč i ten Electron musíš kvůli bezpečnosti furt aktualizovat, protože si ho použil, aby tam lidi mohli vkládat HTML obsah ;-) (formátování, externí obrázky a odkazy s náhledy, ...). Si vemte, kolik verzí pozadu je třeba známý Teams.

8. 1. 2022, 00:47 editováno autorem komentáře

Chtel jsem se rozepsat (jako stara konzerva o tom, jak kdysi byla trava zelenejsi a tak :), ale ony jsou shrnuty tady https://tonsky.me/blog/disenchantment/

“We cover shit with blankets just not to deal with it.”

Ta část o Dockeru a Kubernetes mi mluví z duše :)

1/ je to velké
2/ je to pomalé
3/ nemá to nativní look&fell

preco nie glade? minuly rok som to pouzival prvykrat od prechodu na gtk3 a v zasade to funguje stale rovnako, naklikat napojit signaly a hotovo

Pěkný článek. Rád bych se zeptal, v původním Delphi byl k dispozici i BDE - Borland Database Engine. Je něco takového i v Lazaru?
Kdysi jsem v Delphi vyrobil aplikaci, která měla pomocí BDE uložená a přístupná data a z nich potom generovala do otevřeného wordu obsah.
Pominu-li, náhradu wordu writerem, alternativu k BDE jsem zatím nenašel.
Poradil by někdo čím takový velmi lehký databázový systém nahradit vč integrace do Freepascalu/Lazaru?

Asi bych použil SQLite nebo TDBF. Obojí má v Lazarusu podporu. V případě TDBF nemusíte řešit závislost na externích knihovnách.

TDBF je ale klasika v podobe dBase, nie? To potom radšej SQLite, ale tam mi vadí jedna nedotiahnutá vec a to je triedenie podľa národných abecied. Ja som mal aj SQLite ICU a v Lazarovi to FUNGOVALO!!, ale podpora zo strany ostatných aplikácii je horšia než nulová. Nie je vôbec žiadna, takže tým pádom mám pochybnosti, či indexy s ICU fungujú aj po zásahu zvonka aplikáciou, ktorá ICU nepoužíva (má zo zvlášť príkazy), takže som to prestal používať úplne a ostal som na zohyzdenom triedení. Ako toto riešite páni? Zvyžujem nový stĺpec s pridanými znakmi pre mäkčene a triediť podľa neho.

BDE byla odpověď Borlandu na ODBC Microsoftů. BDE není databáze, je to interface, který podobně jako ODBC je dost "tlustý". Co tak píší, tak Lazarus BDE nepodporuje, stejně jako je nepodporované v originálních Delphi.

Dnešní alternativou může být (a to výrazně lepší) použití SQLite například.

Jako v originálních Delphi si jsem jistý, že připojení na BDE fungovalo. K aplikaci se musel BDE doinstalovat. Při běhu se aplikace na BDE připojila a pracovala s databází - načítala data, měnila záznamy atp. Bylo to velmi jednoduché.
Jako při tvorbě jsem tenkrát měl velký voči, ve výsledku to byla databáze s několika sloupci a pár stovkama řádků, přičemž největší buňka byla odstavec textu (cca 3-5 řádků). Na to by bývalo stačilo asi něco jako xml nebo json, ale v té době to jednak nebylo, druhak jsem se chtěl něco s databázema naučit.

V Delphi je BDE deprecated od 2014.

Na to, co popisujete, se perfektně hodí SQLite.

6. 1. 2022, 11:10 editováno autorem komentáře

Aha, no ja to psal někdy kolem roku 2000.

problem byl kdyz dve ruzne aplikace chteli dve ruzne verze BDE

Lazarus je super, rád jsem jej používal.

Když si ale zkusíte udělat nějakou aplikaci a tu pak dále distribuovat, narazíte na několik problémů:

- v různých distribucích je různě stará verze, nové verze nevychází moc často, takže je velká šance, že v dané distribuci bude o dost starší verze než je aktuální

- autoři Lazarusu nestíhají tempo změn ve vývoji GTK/QT. Aktuálně je funkční pouze GTK 2, verze 3 je nepoužitelná, verze 4 ani neexistuje, myslím. Verze pro QT je aktuálně QT5, ale když jsem svoji aplikaci kompiloval pro QT5, občas záhadně padala, verze GTK2 problémem netrpěla

- na aplikace v Lazarusu se nějak divně aplikují témata, je dost problém udělat složitější GUI tak, aby nebylo věčně rozpadlé :-(

Lazarus by potřeboval více vývojářů, ale k tomu už asi nedojde, hodně věcí se přesouvá na web, bohužel.

Jj, ten vývojový cyklus je pomalejší (což nemusí být úplně špatně).

První věc by neměla být problém ne, když se linkuje staticky. Ale asi myslíte, že lidi mají problém naklonovat repo a přeložit projekt že?

Druhá to je pravda, na druhou stranu mám zatím všude i knihovny gtk2, tak snad snad to vydrží

Blbé je, že když čekám na opravu nějakého bugu, trvá to fakt dlouho.

Naklonovat a kompilovat není problém. Problém je při buildu balíků, které se musí buildovat k tomu, co je aktuáně v distribuci.

V Debianu už měli problém, že balík závisí na GTK2 :-(. Myslím, že nebude trvat dlouho a GTK2 vyhodí úplně.

No právě. Na jednu stranu se říká, jak chybí desktop appky pro Linux, na stranu druhou tady máme (IMHO) velmi dobrý nástroj a kvůli poněkud efemerním (pseudo)problémům se mu hází klacky pod nohy.

Vývoj letí šíleným tempem, na zpětnou kompatibilitu se z vysoka kašle. Asi stárnu, ale štve mě to čím dál více. Nemohu se aplikaci věnovat na fulltime abych mohl sledovat změny v knihovnách a furt něco měnit a testovat. Je to fakt smutné :-(.

ten vývojový cyklus je pomalejší (což nemusí být úplně špatně)

Když jediný pořádně podporovaný framework už není ani udržovaný (a že to trvalo, GTK2 bylo v maintenance fázi 10 let), tak mi přijde, že už to není ani úplně dobře. :)

Njn, když gtk je takový hodně pohyblivý cíl. IMHO by u těchto frameworků mělo být API drženo dýl, ale popravdě už dávno nepatřím mez free-cool-in vývojáře, spíš jsem postarší konzerva, tak mě neber příliš vážně :-)

No, pohyblivý cíl... GTK3 má stabilní rozhraní už 5,5 roku (já vím, letí to).

Jo, v Delphi jsem kdysi psal zápočťák a byla to paráda. Neustále nové nekompatibilní verze GTK musí nutně dělat problémy jakémukoliv menšímu projektu, viz např. XFCE. I když tam je to byla spíš výhoda, že nemají čas na nic jiného, než upgradování na nové GTK, protože to značně zpomalilo tempo, kterým se XFCE devastuje -pardon, modernizuje.

A v LXDE už to vzdali.

To s tím QT Designerem a QT Creatorem se mi zdá jako blbost. QT Designer pořád existuje a je to návrhář UI. QT Creator byla a je jiná aplikace, kterou jsem znal už minimálně od QT 4 a je to vývojové prostředí. Jsou to odjakživa 2 různé aplikace s různým účelem. Žádný předchůdce a následovník.

Podívám se na to, díky za upozornění. Já pracoval s oběma, ale je to už delší doba popravdě...

Moc děkuji za pěkně zpracovaný text, o projektu Lazarus se na českých webech moc nepíše. Vzpomínám si na starší článek od stejného autora na mojefedora.cz, už to bude bratru 10 let.

Pascal to má dnes těžké (stále mě rozesmává jeden nejmenovaný autor, který jej v tolkienovském duchu označuje za "nemrtvé zlo" v porovnání s Pythonem, který je "jako elfština"), zažil jsem jako administrátor obrovský rozmah účetních aplikací a informačních systémů psaných v různých verzích Delphi a poté jako mávnutím kouzelného proutku migraci na C# nebo Javu, takový je však vývoj. O to více oceňuji, že projekty Freepascal a Lazarus stále žijí (a mají opravdu velmi aktivní komunitu), pokukují po moderních technologiích (velmi zajímavá integrace s Javascriptem Pas2JS, webové frameworky Brook a Fano, neuronové sítě CAI Neural API plus v nejnovější verzi integrace FpDebug) a mají fandy, kteří na ně nedají dopustit (projekt Castle Game Engine).

Osobně mám systaxi Algolských jazyků rád, Pascal a především Ada je pro mě čitelná na první pohled, kdežto v Cčku nebo v Javě tápu jak ve tmách, to je ale samozřejmě věc vkusu. Projektů (dnes většinou hobby) se zdá být stále dost:

https://wiki.freepascal.org/Projects_using_Free_Pascal

takže tento jazyk tu s námi ještě nějaký čas zůstane a svůj smysl určitě má. I kdyby jen na školách, pokud se některý z kantorů rozhodne místo dnes jistě velmi vhodného Pythonu pracovat právě s Lazarem (nikoliv s Turbo Pascalem).

Python se skutečně učí, ale má to problém v tom, že se úplně odstíní od datových typů. A potom jsou lidi zmateni, když přijdou ke staticky typovanému jazyku (a to není všechno - mají i problémy s pochopením vůbec toho, co je to integer a že to není float). V tomto ohledu na tom pořád není Pascal vůbec špatně, spíš naopak (a to ten jazyk osobně moc nemusím).

Chceš říct, že v Pythonu jsou int a float jeden typ?

Není, ale ten rozdíl se při výuce smazává protože převody se mnohdy provádí automaticky. Resp. se nad tím vůbec nepřemýšlí (mám doma dva příklady děcek, co se Python učí a tam na to prostě nenarazili, protože to "samo" nějak funguje v 99% případů).

Tam je otázka, v jaké fázi učení ty strojově závislé věci řešit. Učebnice Pascalu bývaly plné "pitomostí" typu vytváření spojových seznamů, tedy struktur, které normálně člověk nepoužije, natož aby je chtěl sám implementovat. Zrovna tak si myslím, že "nekonečné" datové typy jsou pro výuku programování docela vhodné, není třeba hned řešit, co je int a co long long.

Rozdíl mezi celým a reálným číslem se vyjeví (v Pythonu 3) nejpozději v době, kdy si někdo napíše print(2/3).

prevody mezi ciselnymi typy se provadi automaticky i v Pascalu.

"mají i problémy s pochopením vůbec toho, co je to integer a že to není float"

troufam si tvrdit, ze programator v pythonu musi vedet co je integer a float.

Tohle je problém Pythonu že můžeš docela dlouho vyvíjet SW aniž bys měl tušení jaký rozdíl je mezi int a float.

Něco jako Hello World?

Nebo Javascriptu.

Dobré načasování, zrovna vyšel nový Lazarus: https://forum.lazarus.freepascal.org/index.php/topic,57752.0.html

V Lazarus-e pisem stale a nielen GUI veci ale aj CLI aplikacie. Hlavne prenosnost je velka vyhoda. Da sa pisat napr. pod Win a potom len aplikaciu prekompilovat na Raspi a vsetko bezi.
DB sa daju pouzivat aj bez vizualnych komponent. Napriklad na MS Sql staci mat nainstalovany driver a mozem s toho citat pomocou Sql jazyka. Takto taham veci z firemneho uctovnictva co bezalo nad mdb a teraz to prerobili na Sql. Je to rychlejsie ako samotne uctovnictvo a prepisanie aplikacie z mdb na sql je zalezitost tak na 15 riadkov.

Ak pod linuxom nema distro aktualnu verziu Lazarusu v repozitaroch tak sa da nainstalovat balik rovno zo stranok projektu. Deb je podporovany.

Pre komunikaciu TCP, HTTP, SMTP..RS232..je neocenitelna kniznica Synapse.
https://wiki.freepascal.org/Synapse

Lazarus mi vychadza ako robustnejsie risene v porovnani s .net. Hlavne mozem linkovat staticky a aplikacia sa rozbehne po prekopirovani na aj na starom aj na najnovsom systeme.

Ta praca s assemblerom v Pascale bola fakt pohodlna. Ked som niekedy v 90tkach presiel na C a potom neskor na Linux, z toho ako sa integruje do C-cka assembler som bol dost zdeseny. Na druhu stranu dnes to berem ako pozitivum, pretoze clovek musi mat fakt dobry dovod na to, aby si lamal hlavu s tym, ako nalepit kus assemblera do C-cka.

Jedine co ma napada tak optimalizovany kod so SIMD instrukciami.

Jako RAD je to super, jen kdyby to bylo v něčem lepším, třeba Rustu :-)

Na co vytahovat tyhle kostlivce? I pro takové NetBeans existuje GUI návrhář, jestli jde o tohle.

Jinak ta rychlost překladu u starých Delph, by mě zajímalo, v čem bylo to kouzlo?

(k prvnímu odstavci se nebudu vyjadřovat, ostatně rok narození Javy je taky relativně malý :-)

ad rychlost překladu: Wirth navrhl Pascal tak, aby se pro jeho zpracování mohl používat LL parser (proto se LL parserům říkalo "evropské", Wirth se těmito parsery zabýval a snad všechny jeho jazyky jsou na něm postaveny). A LL parser je možné napsat hodně efektivně, prakticky (teď přeháním) s okamžitým generováním výsledného objektového kódu. Taky se Pascal moc nezdržoval nějakým velkým preprocesingem (i když TP měl include apod.), překlad byl z velké části hotov v prvním průchodu atd.

Těch vychytávek tam bylo několik, ale základem byl Pascal jako formální jazyk založený na LL gramatice. Zajímavé bylo, že Borland vydával i obdobu C/C++, jak pro Turbo Pascal (Turbo C), tak i pro Delphi (Borland C++ Builder), ale ta rychlost byla možná i řádově jinde (i přesto, že tam dělali triky s předzpracovanými headery atd.). Ono jen pitomé #include <windows.h>, nebo co tam bývalo, si vzalo spoustu času.

Jde hlavně o to, že je to byl jednoprůchodový překladač navíc bez větších optimalizací. V podstatě je to Pascal -> exe

C je na parsování také poměrně jednoduchý jazyk, možná ještě jednodušší než Pascal, ale je tam několik etap, které dříve vyžadovaly zápis na disk a start dalšího překladače nebo linkeru. Navíc u Cčka bude dost náročná evaluace (interpretace) maker. U Cčka je preprocesor -> C -> asm -> stroják -> linker.

Pascal je novější jazyk, který reflektuje silnější počítače a snaží se o rychlejší vývoj (a rychlost běhu aplikací není absolutní kritérium). Cčko byl systémový jazyk (tudíž přirozený bottleneck), a navíc vznikal na starších mašinách, kde šlo vůbec o to dokončit překlad. Rychlost vývoje v Cčku se porovnávala s assamblerem (tudíž pro Cčko super, i když to bylo výrazně pomalejší než v Pascalu). Ale z té perspektivy se na Cčko nikdo nedíval.

Pascal byl aplikační jazyk, Cčko byl systémový jazyk. Ve starých učebnicích se píše něco ve smyslu - v shellu máte extrémně rychlý a jednoduchý vývoj, ale výsledek je pomalejší, a pokud by byl extrémně pomalý, tak to napište v Cčku. A Pascal byl výrazně lepší alternativou shellu (nebyl alternativou Cčka).

6. 1. 2022, 19:53 editováno autorem komentáře

jojo, jednoprůchodový překladač, co prakticky hned generoval objektový kód, je v tomto super.

Jinak k tomu, že C je jednodušší - v C je problém, že se parser (pokud je top-down, což právě není) musí často vracet, protože "strašně dlouho" neví, co vlastně má na vstupu. Třeba takové "int **foobar" (a můžeme tady mít pole atd.) - překladač stále v tento okamžik neví, co vlastně má na vstupu, protože to může být jak deklarace proměnné, tak i deklarace funkce.

Nebo často ukazované "a * b;" - tady musí mít parser tabulku symbolů, aby dokázat rozhodnout, jestli je to násobení dvou proměnných nebo deklarace proměnné typu "ukazatel na a". Pascal je strašně ukecanej mj.i proto, aby toto dokázal rozhodnout dopředu (resp. dopředu věděl, co se vlastně překládá).

Tady si možná nerozumíme. Myslím si, že náročnost parseru Cčka a Pascalu je stejná. Co je jiné - parser Pascalu může generovat strojový kód, případně p kód. Z Cčkového parseru mi vypadne AST, které se pak dál zpracovává. To další zpracování už ale nepovažuju za parsování.

Jinak ta realita byla jiná - Wirthův Pascal překládal do pcodu - takže z dnešního pohledu by to byl spíš interpret, a co si vzpomínám, tak M-Pascal byl také více průchodový. Turbo pascal by revolucí (a co mne dostalo, a i jsem ho používal, tak byl běh na 8bit CP/Mku). Nicméně pokud se používaly unity nebo overlaye, tak to na jeden průchod také nebylo. 4kový Turbo Pascal uměl uložit unity v paměti (tam se dalo zapínat/vypínat linkování).

Jenom bych podotknul, že Delphi stále žije.

https://www.embarcadero.com

Má i nějaké community edice za registraci.

My v placených verzích vyvíjíme pár multiplatformních aplikací a kupodivu to funguje :D

Jinak taky žije česká komunita: www.delphi.cz

Třeba na základní hraní pro děti, pro které je třeba processing(JAVA) moc jednoduchý , se dá použít klasická knihovna delphix , což je DirectX wrapper.

Třeba tu : http://www.micrel.cz/Dx/

Díky za odkazy!

pozvzdych: Pomohlo by mi, keby taky Lazarus existoval pre wxpython.

Myslím, že je dobré posuzovat prostředí tím, jestli se někde skutečně používá.

Lazarus/free pasal se kupodivu používá, třeba u Double Commanderu (https://doublecmd.sourceforge.io/). Nyní se k němu znova vracím a koukám se jestli je to použitelné a jaké jsou tam chyby. Zatím jsem s Double Commanderem spokojen.

Ano, skutečně se používá a stále dost často, viz. např. odkaz přímo na jejich wiki:

https://wiki.freepascal.org/Projects_using_Free_Pascal

nebo tady:

https://awesomeopensource.com/projects/lazarus

Osobně používám Lazpaint, GHTopo, Skychart, Virtual Moon Atlas, Castle Game Engine a k zahození není ani Python4Lazarus. Existuje i účetní program Gestinux, který právě testuji (i když GUI vypadá slušně řečeno odpudivě). Zajímavě vypadá i embedeed prostředí pro RPi Ultibo Core.

Uvidíme, kam se bude další vývoj ubírat, autoři stále umožňují běh pod Win2000/XP, což je přinejmenším podivuhodné. Stále vychází aktuální Blaize Pascal magazín a oficiální fórum je velmi živé, takže přes veškeré problémy projekt stále žije a nevypadá, že by tomu v dohledné době mělo být jinak.

Mimochodem, tady jsou hezky popsané jednotlivé verze Free Pascalu i s jejich novými vlastnostmi:

https://www.duhoctrungquoc.vn/wiki/en/Free_Pascal

a pokud někdo stále čeká na nejnovější verzi nebo rád ty vývojové (v mém Archu je stále starší 2.0.12), je zde klikací možnost fpcupdeluxe.

Vypadá použitelně, jsem zvědav na kód.

Tak tohle fakt není pro mě. Už jsem zapomněl, že existuje něco jako řetězec dlouhý maximálně 256 znaků, case insensitive kód, Inc(i), sekce Interface a Implementation apod.

Navíc ty dialekty - v každém souboru je explicitně uvedeno, že se jedná o {$mode objfpc}{$H+}. Ale proti gustu...

Tohle dráždí jen nedorostlé script kiddies, staří fortranisté to berou stoicky :)

Nedráždí to nikoho, kdo tohle používat nemusí. Užij si to, i s Fortranem a Cobolem. ;)

Řetězec max. 255 (ne 256 pokud si dobře pamatuju) znaků je ještě z Turbo Pascalu, tj. 30 let stará věc. Už první Delphi mělo "dlouhé řetězce". Zase naopak, situace, kdy pro zjištění délky řetězce musím iterovat přes všechny znaky, až (možná) dojdu k nule, je taky nic moc. (tedy obě řešení na houby :-)

Inc() a Dec() je na hlavu, to zase jo.

Neomezené řetězce má každý "velký" jazyk, že některé mají vedle toho i řetězce pevné délky je jen plus. Třeba Fortran má obě varianty, stačí si vybrat tu lepší podle konkrétní situace.

BTW příčetné jazyky vyšší úrovně si u řetězců drží i jejich délku, nic se neiteruje pro její zjištění.

Jasně, všechno má pro a proti, já jsem nechtěl vyloženě Pascal pomlouvat. Mně tam dost věcí nesedí, ale beru to i jako osobní preferenci - někdo má rád kávu a někdo čaj a je to i zvyk. Já jsem od (Turbo) Pascalu přešel k C, chvíli jsem byl z lecčehos otrávený, ale zvykl jsem si a něco mi přišlo lepší. Na druhou stranu ++i a i++ je v něčem taky peklo. V tom kódu Double Commanderu je explicitně zapnuté {$H+}, což by mělo znamenat, že to jsou AnsiStringy, tedy normální UTF-8 řetězec, jaký používáme běžně v "moderních" jazycích.

Retezce prosly dvema velkymi prerody. Puvodni verze 255 znaku + pocitadlo. Od Delphi 2 neomezene + pocitadlo + 0 na konci. Soucasna (2009) verze totez s unicode podporou. Copy on write, pocitani referenci.

Keby len doublecmd, veď aj slávny Total Commander je v Lazarovi. Dôvod bol, že ľudia chceli 64 bitovú verziu a Delphi stále meškalo. Tak sa autor rozhodol prepísať to do Lazara. TC od verzie, myslím, 8.0 je už v Lazarovi.

TC není celý v Lazarovi. 32-bit verze je stále v Delphi. 64-bitová verze je v Layarovi. Budu citovat pana Ghislera (autora TC):

"I didn't migrate to Lazarus, I'm still using Delphi for TC 32-bit. I'm using Lazarus for TC 64-bit because there was no 64-bit Delphi at the time when I needed to create a 64-bit version.

Lazarus works well, but the created EXE files are quite a bit larger. If you can afford Delphi, I recommend that you stay with it. Lazarus is a bit slower, but it's still fast enough to not slow down my workflow."

V prvom rade ďakujem za článok. Lazarus je moja srdcovka pre voľný čas. Programujem v ňom už asi 10 rokov. Dovolím si ale upozorniť na jednu nezrovnalosť:
Menu => Projekt => Voľby projektu => Voľby prekladača => Ladenie => Generate infor for the gebugger
Táto voľba stiahne EXE z 15 na 2,5 MB, ak sa dobre pamätám pri 32 bitovej verzii Lazara. Popravde, nechce sa mi to teraz presne overovať koľko to bolo, nech autor vyskúša sám. Takže žiadne aplikácie na vyhadzovanie ladiacich informácií. Dokonca sa v Lazarovi dá priamo nastaviť, že či sa kompiluje finálna aplikácia (bez ladiacich informácií) alebo na ladenie. Potom je to len o jednom kliku navyše pri kompilácii. Ale nemám to vyskúšané a nepoužívam to. Áno, po 10 rokoch to neovládam, takže ako to nastaviť, neviem. ;-)

jj je to tak, díky za doplnění.
Výsledek bude stejný, protože to debug info je ve standardním formátu (pro gdb) a strip tedy bude pracovat korektně.

Ešte doplním, že od novej verzie (vyšla myslím vo štvrtok) 2.2.0 je štandardný debugger FpDbg alebo ako sa volá, takže Lazarus má konečne vlastný debugger. Nemám to ale vyskúšané vôbec, lebo Lazara vždy inštalujem ako portable a je tam v úvodnom spustení chyba, kvôli ktorej sa pre FpPkg (ja som si to takmer pomýlil s tým novým debuggerom) uloží lokálna konfigurácia. Vo fóre mi na to nikto neodpovedal, takže zvažujem nahlásiť bug.

Este k velkosti vysledneho binarneho suboru. V clanku je to kompilovane aj s Debug info a v takom pripade sa neda pouzit Smart linking. Je potrebne vypnut generovanie Debug info a zapnut Smart linking, vysledny sobor bude mat kusok cez 3.5 MB.

Tuším som tam v článku čítal, že reťazce majú 255 znakov. Nie nemajú. Lazarus používa AnsiString, ktorý je štandardne použitý, ak sa použije kľúčové slovo String. Asi to dám aj do chýb v článku, lebo na to poukazujú v diskusii.

To v článku není :-) Je tam jen v poznámce napsáno, že tato část původně převzatá z TP byla hned v prvním Delphi (na 100% v Delphi 2) upravena, resp. přibyl nový datový typ. Dnes je to ještě lepší v režimu FPC.

Áno, poznámnku som potom našiel, ale nahlásil som to ako chybu v článku, lebo to vyznieva ako keby Lazarus nič lepšie nepoznal. Nechám na zváženie, či poznámku ponecháte ako je.

Zkusím to raději přeformulovat, v každém případě díky za upozornění.

V Delphi se i dnes stále píší aktuálně používané programy a to i zde v Česku. Když jsem spustil Lazarus, dýchla na mne atmosféra roku 1998, zkusil jsem si v tom navrhnout jednoduchý formulář a za 5 minut je hotovo. Nevím, v čem jiném dělat gui appky pro widle / llinux.

V čem dnes dělat moderní gui appky? Rychle, efektivně, použitelně?

V Lazarusu :) [tedy nevím, co to znamená "moderní"]

Taky nevím co to znamená, ale po golangu se mi moc nechce vracet k pascalu. Na druhou stranu psát backend v golangu a potom to používat jako desktopovou appku je taky blbost. Takže asi nakonec jo, Lazarus.

No já jsem +- v podobné situaci. Backend bych udělal v Go, jenže do GUI ve stylu Electronu se mi z mnoha důvodů nechce a navazovat se na Qt/Gobject atd., to sice by i šlo, ale jednosměrně a nebylo by to RAD.

“Moderní” znamená co nejvíc buzzwordů v popisu :)

No tak třeba rozumný vzhled. Je to jistě věcí vkusu každého, ale šedá tlačítka styl windows 95 už dnes nemusí vyhovovat. Viděl jsem pěkné nativní desktopové programy napsané v nějakém frameworku v C# (.NET) a vypadají pěkně a současně jsou velmi použitelné.

Delphi / Lazarus se hodí pro takový ten "úřednický" vzhled formulářů, pro účetnictví, skladové hospodářství a tak podobně.

Flutter?

Já bych viděl jako důležitou možnost stavět na předchozích řešeních, tedy třeba použít ten formulář jako základní kámen pro vytvoření nového (třeba i přes dědičnost). Zásadní je třeba i možnost prohledat VŠECHNY soubory projektu na výskyt řetezce, je jen ty *.pas nebo *.cpp. Výhoda těchto nástrojů (Deplhi, Lazarus, C++ Builder) je určitě v dlouhověkosti vytvořených aplikací - mám jeden program v C++ Builderu, který běží beze změny od roku 2005. Jak budou fungovat za 15 let programy založené třeba na .NET?

Dědičnost? Podle místních ekšpertů už žijeme v post-OOP světě (Rust), takže tudy cesta nevede. Ekšperti se přece nemýlí, nebo? :)

Ekšperti neměli na mysli ani tak Rust, jako spíš lambdu v Javě, která jednou provždy poslala představy o všespásném OOP do minulosti. Nebo třeba i Julii nebo Go, můžeš si vybrat.

No fajn, tak teď máme všespásné lambdy, než přijde další generace ekšpertů, řekne, že lambdy jsou bordel, a navrhne něco jiného lepšího. A tak ad infinitum.

Nehledě na to, že ty zmíněné jazyky podle původní definice OOP jsou a Julia má navíc HKT a multi-dispatch (díky čemuž generuje rychlejší kód než Rust).

Jo a mimochodem - GUI je jedna z mála oblastí, kde OOP působí přirozeně a nemá moc konkurenci. Všude jinde je jeho pozice výrazně slabší. Tohle ale přece víš.

Taky má “silnou pozici” v simulacích, jeho céplusplusová reinkarnace ostatně pochází ze Simuly. Smalltalkovské pojetí OOP má silnou pozici pořád skoro ve všech obecných jazycích. Nepatřičně působí OOP jen v jiných paradigmatech, třeba když IBM vydalo OO Prolog, tam to je úlet. I v tom Fortranu působí přirozeně. A zmíněná Julia má plný subtyping včetně HKT a typové variance.

> V čem dnes dělat moderní gui appky? Rychle, efektivně, použitelně?
Na Windows je super SharpDevelop, len uz sa asi 5 rokov nevyvija. Skusal som na Linuxe MonoDevelop, ale to ma moc nenadchlo.
Asi teda Lazarus alebo potom Java... alebo Tcl/Tk :-)

GUI je jenom jeden aspekt - rychle naklikat formulář se dá v lecčems (jsou na to nástroje (např.) pro Qt i Gtk) a navázaný jazyk může být C, C++, Python... V tomhle žádná věda není. Pokud vysloveně nechceš používat Pascal, tak Lazarus samozřejmě nepoužiješ (s Javou to je podobné).

ako tak citam reakcie, tak vacsina ludi ma skusenost iba s webom, inak si neviem vysvetlit, ze opominaju hned dva majoritne cross-platform toolkity a skacu hned k tk, electron alebo windows-only

gtk (glade) alebo qt (qtcreator) ako najvacsi mainstream. neviem ako je na tom wxwidgets, ktory sa kedysi snazil o nativne UI na windowse

wxWidgets aktuálně trochu spí