Lazarus 3.6 (diskuse)

[jozo34563456]

existuje nieco podobne pre C++ alebo python?

Qt creator nie je alternativa, tam sa tie komponenty nedaju "vyklikat"

[Martin Tůma]

Qt má QtDesigner, pokud chceš GUI "naklikat". Na "profesionální GUI" se to ale moc nepoužívá.

[jozo34563456]

No v Qt designeri su len zakladne komponenty. Neexistuje tam nic take (alebo nie je popularne nieco sa mi mari ze tam bolo) ako v delphi - napr databaza vysledky query boli vidno uz pri dizajne app

[Martin Tůma]

AFAIK tam jsou prakticky všechny widgety, jenom jich prostě v Qt není tolik, kolik by sis možná představoval. Pokud nemáš ani elementární vkus, ještě můžeš zkusit Gtk/GLADE, ale moc víc RAD toolů pro Linux není.

Věci, co se rychle nějak splácají pro "teď" bez nějaké vize do budoucna se dneska místo v Delphi píšou v JavaScriptu.

[koroptev]

A v cem se pisou veci, ktery maji tu vizi do budoucna?

[Martin Tůma]

V čemkoliv, co je léty prověřené a zcela nepochybně tu s námi na desktopech ještě roky bude, např. C++ nebo C#. Menší veci třeba v Pythonu. Pokud píšeš pro korporát, který může zaměstnancům vnutit něco, co by si nikdy sami nevybrali (bavíme se o desktopu), tak můžeš zvolit i Javu.

Co zvolit nemůžeš je libovolný JS framework, co je zrovna tento měsíc "in". Protože ten za tři roky už s velkou pravděpodobností v prohlížečích nebude fungovat. Nebo bude, ale bude vypadat úplně jinak, než před těmi třemi lety a ty tu aplikaci tomu budeš muset přizpůsobovat...

[koroptev]

to musis stejne

podivej se treba na to "lety proverene" Gtk, major verze jsou mezi sebou navzajem nekompatibilni a je jich kolik dnes relevantnich? 2, 3, 4..

rozdil je jen v rychlosti, kterou se ten kterej ekosystem zene dopredu, silenosti jsou tam i tam..

pokud si myslis, ze existuje nejaka vyssi proverena moc, ktera zajisti, ze neco bude fungovat za 3 roky, tak te zklamu, recept je porad stejnej, aktivni pece o produkt, tohle je a funguje to, neni to a nefunguje..

[Martin Tůma]

podivej se treba na to "lety proverene" Gtk, major verze jsou mezi sebou navzajem nekompatibilni a je jich kolik dnes relevantnich? 2, 3, 4..

Gtk je ale psané v C a právě proto, aby náhodou někdo nevytáhl šílenost zvanou Gtk jsem tam explicitně napsal C++, ne C/C++

rozdil je jen v rychlosti, kterou se ten kterej ekosystem zene dopredu, silenosti jsou tam i tam..

Jako ano, dost možná se jednou za čas změní i něco ve WinAPI, ale ta kvalita/použitelnost je právě o tom, jestli je ten čas geologicky krátký. Qt má třeba tu dobu mezi major verzemi, tedy verzemi, co potřebují změnu v aplikačním kódu (na desktopu, Android je zcela jiný příběh...), +/-10 let a to mi přijde "good enough".

pokud si myslis, ze existuje nejaka vyssi proverena moc, ktera zajisti, ze neco bude fungovat za 3 roky, tak te zklamu, recept je porad stejnej, aktivni pece o produkt, tohle je a funguje to, neni to a nefunguje..

Ale ona jedna taková vyšší moc existuje, jmenuje se Microsoft. To co si před 20 lety napsal ve WinAPI a přeložil v MSVC 2.0 v drtivé většině případů poběží i na dnešních Windows 11... Samozřejmě teď neřeším otázku, jestli to taky někdo bude stále chtít používat, za tu dobu spousta oblastí využití desktop aplikací prostě zmizela.

[koroptev]

dle stejny logiky ti ale uplne stejne v pohode pobezi i ta electron appka.. michas hrusky s jabkama, nejdriv mluvis o zivotnosti kodu ted zase zivotnost binarky..

[Martin Tůma]

Psal jsem o JavaScriptu pro prohlížeč, ne o Electronu. A kód a binárky nejsou "jabka a hrušky", ale "spojené nádoby". ABI a dostupnost/zpětná kompatabilita "runtime" je stejně podstatná jako kompatabilita API/jazyka.

[koroptev]

aha

takze ty bys ty klienty pro ty vsechny crudy psal v Qt misto v necem, co ve vysledku pobezi v browseru, aby to melo budoucnost? to je recnicka do humoru, ale ta nehumorna odpoved je to, co uz jsem ti napsal - budoucnost nejen ty webovy ale jakykoli aplikaci nezajisti jazyk ale tym, kterej se o to stara, nic jinyho

kdyby ses v tom pohyboval, videl bys, ze JS je stabilni, api se pridavaji, starej kod ti pobezi, co se meni tou silenou rychlosti jsou knihovny, tam je neco, co se ideove blizi tomu problemu, o kterej ti asi slo - v tom pripade ale porad plati, ze "staticky" zbundlovana aplikace proste nadale pobezi..

spojeny nadoby - to delas z nouze ctnost, tvuj puvodni argument byl jabko a pak jsi presel na hrusku.. hruska problem neni, jabko viz vyse

[PetebLazar]

Existuje nějaká výpočetně intenzivní multi-thread Electron aplikace? Ideálně open-source pro inspiraci.

[koroptev]

Jakoze kdyz jsi nase use case, pro ktery nejake reseni neni vhodne, tak to popira jeho validitu pro celkem hodne sirokou skalu problemu jinych?

Ja nejsem ten, co se divi, proc to ma uspech Ja to vam, natvrdlinum, objasnuju, ze ten duvod je jinej nez "svet se mi nelibi, vsichni jsou blbi".

[PetebLazar]

V předchozích příspěvcích jsem si nevšiml, že by někdo nějaká omezení Electron frameworku v tomto směru zmiňoval. Rady těch co zdůrazňují jen pozitiva určitého řešení a nejsou schopni(ochotni) upozornit na jeho případná omezení je třeba brát s velkou rezervou.

[Profik]

Tva otazka je nesmyslna. Electron ma ABI a ten samozrejme umi spustit libovolnou intenzivní multi-thread libku (so/dll/dylib) napsanou v cemkoli co exposuje FFI. To ze se GUI v Electronu dela web technologiemi neznamena, ze i middleware/be/libs musi byt v JS

[PetebLazar]

Předpokládám, že taková heterogenní aplikace již nebude jako celek na úrovni kompletního zdrojového kódu přímo přenositelná mezi platformami, nebo ano?

[Zjeveni]

Az jsou zdrojaky ke knihovne v podporovanem jazyce (C/C++/Rust) a nemaji vylozene ASM call pro specificky typ procesoru (obvykle x86+ vs ARM6+) tak pres GYP je muzes mit multiplatfo out-of-the box. V praxi ale stejne kompilujes binarku Electron apky pro konkretni architekturu a builder proste jen pribali binarku libky dle daneho OS+flavour (za predpokladu, ze libka je multiplatfo a jsou k dsipozici potrebne binarky).

Proste se uz zbavte tech blbych pover o Electron(-like) apkach. Jo potrebuji vic RAM, a to je tak asi vse, ostatni jsou jen a jen vyhody. RAM dnes neni zadny luxus, rejpalove s 4GB pred 10 lety zkusili prvni Electron apku a od te doby se k tomu nevratili...

A nezapomente to hlavni - Electron apky vznikli protoze NEEXISTUJE STANDARDNI LINUX DESKTOP - kazde distro jiny pes a jina ves krat desitky verzi knihoven krat desitky verzi desktopu krat to a krat ono. A pak vznikli ty FlatFucky s FapImages a SlapWhores kde spolecny jmenovatel je "picou ke zdi"... ZLATY ELECTRON!

[xkucf03]

Stará webová aplikace v prohlížeči možná^[1] poběží, ale ten drobný háček je v tom, že frontendové technologie zastarávají neuvěřitelnou rychlostí, takže údržba a provoz starších aplikací jsou velmi problematické. Frotnendisti budou držkovat, že na rok staré knihovně nechtějí pracovat, že dneska frčí něco jiného... Budou nad tím ohrnovat nos a práce jim půjde pomalu nebo je vůbec neseženeš. Pokud nad tím pustíš nějaké testy/skeny nebo uděláš dokonce penetrační test, tak ti z toho vypadne hromada bezpečnostních chyb (je otázka, jak jsou relevantní, ale už jen vyhodnotit je zabere spoustu času). Pak zjistíš, že novější verze těch JavaScriptových knihoven a frameworků buď neexistují nebo jsou zpětně nekompatibilní, protože jejich autor změnil názor a teď se ukájí nad něčím jiným. Když se to pokusíš upgradovat, tak se ti to celé rozsype, nepůjde to ani zkompilovat… když to nakonec dokopeš do spustitelného stavu, tak začneš řešit funkční testy a budeš zjišťovat, že to, co na první pohled vypadá v pořádku, reálně nefunguje, protože uvnitř těch knihoven je teď něco trochu jinak.

Když místo standardního prohlížeče použiješ navíc Electron, tak ten má krátkou podporu, takže vydaná verze tvé aplikace do půl roku shnije. A je to postavené na aktuálním Chromu/Chromiu, takže na podporu starších verzí OS rovnou zapomeň.

V tomhle mají výhodu ty konzervativní technologie jako Java nebo ten Lazarus, které tu kompatibilitu drží desítky let. Byť samozřejmě chápu, že to UI pro mnoho lidí nevypadá dostatečně moderně. Řešením může být vícevrstvá architektura – většinu aplikace mít psanou v něčem konzervativnějším a trvanlivějším + nad tím mít tenkou prezentační vrstvu, která se obměňuje dle aktuální módy.

_{[1] Píšu „možná poběží“, protože se mění různé věci např. kolem zabezpečení a to má někdy za následek znefunkčnění starých webů, které v dřívější verzi prohlížeče fungovaly.}

[koroptev]

ctu jenom prvni vetu a "ale ten drobný háček je v tom, že frontendové technologie zastarávají neuvěřitelnou rychlostí, takže údržba a provoz starších aplikací jsou velmi problematické" se samozrejme beze zmeny vztahuje i na tu msvc aplikaci ze starejch windows..

[Martin Tůma]

Tak jestli máš pocit, že WinAPI, nebo třeba Qt, ať nejsme pouze na Windows, zastarává stejnou rychlostí jako JS frameworky tak potom je každá další diskuze na toto téma s tebou asi bezpředmětná...

[koroptev]

nemam, ale ja neargumentoval 20 lety starym kodem bezicim na win11..

ten kod je dnes mrtvy, jen bezi binarka, ale o hruskach a jabkach uz tu rec byla

cili jazyk pro budoucnost z tveho pohledu je ten, jehoz knihovny se jiz nevyviji nebo vyviji jiz jen velmi pomalu? ok, jinej kmen

[Martin Tůma]

ja neargumentoval 20 lety starym kodem bezicim na win11..ten kod je dnes mrtvy, jen bezi binarka, ale o hruskach a jabkach uz tu rec byla

Pokud má někdo pro tu aplikaci využití, tak to zdaleka nemusí být pravda. Viz třeba stále nejpopulárnější file managery dneška - Total Commander (Delphi), Servant Salamander/dnes Open Salamander (C++/WinAPI).

cili jazyk pro budoucnost z tveho pohledu je ten, jehoz knihovny se jiz nevyviji nebo vyviji jiz jen velmi pomalu? ok, jinej kmen

To si zase čteš něco jiného, než píšu. Já říkám, že ta technologie (není to jenom o jazyku, jak se ti tady celou dobu snažím vysvětlit) je taková, která je dnes stabilní, udržovaná a má velký předpoklad, že tak bude i za 10 let.

[Profik]

Dalsi jabko-hruskar. Frontendove technologie jsou presne 4. HTML,JS,CSS,WASM. Jsou navrzeny a vyvyjeny tak, ze jsou vzdy zpetne kompatibilni, jenom se pridavaji ficury, nic se nevyhazuje pouze deprecatuje.

Kdyz ti nahodou neco prestane chodit (u webu) tak za to muze bud browser, ktery neco prestal podporovat (treba http), nebo knihovna treti strany ktera zmizela z netu (treba Twitter zarizne stare API a dynamicka connect knihovna uz neni). Dokud mas ale vsechny knihovny u sebe, nebo zbundlovane staticky tak se nic nedeje ani za 20 let (az nejsi zavisly od externich dat, API). A to je prave pripad Electron(-like) aplikaci, vsechno maji zbundlovany staticky u sebe.

[Martin Tůma]

budoucnost nejen ty webovy ale jakykoli aplikaci nezajisti jazyk ale tym, kterej se o to stara, nic jinyho

V tom nejsme vepři. Podstatný rozdíl v těch technologiích ale je, kolik tě ta budoucnost bude stát.

co se meni tou silenou rychlosti jsou knihovny, tam je neco, co se ideove blizi tomu problemu, o kterej ti asi slo

Samozřejmě, že mi jde o "ekosystém" (zjednodušeně knihovny). Jazyky samotné až na výjimky (zdravíme Python a Rust) bývají většinou velice dobře zpětně kompatabilní, ale reálné desktopové aplikace opravdu nepíšeš v "čistém C++", stejně tak jako se reálné webové aplikace nepíšou v "čistém JavaScriptu".

[koroptev]

kdyz mas ten tym lidi, co se o tu aplikaci stara, tak ten tym typicky neresi problem "nahle jsme se probudili a musime 20 let stary kod ucinit funkcnim v dnesnim svete a stavu ekosystemu", ten tym tenhle problem resi inkrementalne nonstop a ... tak nejak to neni problem

vy v c++ a qt hybernujete na par let a pak se probouzite?

[Martin Tůma]

Když máš ten tým lidí... Vtip je v tom, že sehnat/udržet tým lidí na 10 let starý webový framework je obvykle podstatně těžší, než na nějakou méně překotně se měnící technologii.

vy v c++ a qt hybernujete na par let a pak se probouzite?

Ne. My jenom ten projekt nepřepisujeme každý rok do něčeho jiného, co je zrovna in.

[koroptev]

a kdy jsi se naposledy nachazel v situaci, ze jsi potreboval ozivovat kod, na kterej nikdo nesahl 10 let? myslis, ze to je typicka starost lidi, kteri vybiraji technologii pro svuj novy projekt?

ad prepisovani - to se nedeje ani na tom webu.. a kdyz chces zustat na urcite verzi, muzes, nikdo ti nebrani, jen holt nebudes mit novy ficury / fixy bugu

[xkucf03]

Tohle vídám v praxi, neříkám, že je to správné, ale je to realita, se kterou je potřeba žít. U některých produktů si zákazník mého zákazníka si platí malou servisku – nemá šanci to uživit tým lidí, sotva jednoho, aby se občas na něco podíval, a víc ten zákazník nedá. Takže ten produkt opravdu třeba rok nebo i pár let spí a pak si ten zákazník vzpomene, že tam chce něco upravit nebo dovyvinout.

Na tohle téma jsem psal i tady: Komplexita softwaru: Časová dimenze.

Mám pocit, že tohle si málokdo uvědomuje a hodně firem na to někdy doplatí. Jsou období (typicky na začátku), kdy máš silný tým, třeba deset vývojářů, kteří na tom naplno vyšívají, hodně se do produktu investuje. A pak máš období, kdy jsi rád, že máš jednoho člověka, který to oprašuje. Dobře zvolené technologie a architektura ti umožní přežít v obou těchto režimech.

To, že se produkt moc nevyvíjí, nemusí být špatně, nemusí to znamenat, že o něj není zájem, naopak – může dobře sloužit tak, jak je, a být víceméně hotový. A změnové požadavky pak přicházejí jen jednou za čas.

[koroptev]

Prizmatem tohohle pohledu bys vzdy volil neco extremne konzervativniho. Cili tenhle pohled asi neni dobry mit jako jediny kriterium.

[xkucf03]

Ne tak docela. Např. když ty weby považuješ za spotřební materiál a firma je smířená s tím, že každých pár let udělá projekt „výroba nového webu“, tak klidně používej různé pomíjivé a módní technologie – může to mít i svoje výhody a smysl.

Problém je, když někdo tyhle zvyky a praktiky přenáší do prostředí, kde se vyvíjí software a očekává se větší trvanlivost. O tomhle jsem taky psal: Komplexita softwaru: Charakter projektu a priority. Takovým příkladem je internetové bankovnictví – tam banka čeká, že jí ten software vydrží 10+ let, je to přeci jen velká investice, a mezi tím maximálně zaplatí nějaké přestylování pomocí CSS, aby to vypadalo dobře + implementaci nových funkcí. Ale určitě to nebude chtít po roce nebo dvou celé zahodit a psát znova.

[Migi]

QtCreator jeste par let zpet integroval qtdesigner, to už neplatí?

[Andreas]

Nutno si uvedomit ze jak pascal tak C++ i s jejich RAD/GUI nastroji jsou relikt z minuleho tisicileti. Dnes se uz absolutne nepouzivaji nebo by su uz nemeli vubec pouzivat na vyvoj GUI aplikaci. Doporucuji vam jit s dobou:

1. Predevsim vyvoj se dnes dela predevsim v macOS, linuxovy desktop skomira a v podstate je uz mrtvej, windows ma zase spoustu problemu.
2. Idealni je delat aplikace v Electron frameworku. Jsou multiplatformni a rychle. Pred lety u linukaku s 1GB ram nebyl moc popularni, ale dnes maji 8GB ram i posledni hodinky takze to neni uz davno problem.
3. Avangarda je dnes u Rustu. Moderni jazyk hodny tohto tisicileti, moznost pouzit nativnich GUI knihoven, nebo rust native, nebo treba i (FL)TK.

Takze tak. Neposlouchej QT dinosaury jako Tuma a jdi s dobou!

[PetebLazar]

Do kdy odhadujete, že ta "Electron doba" bude trvat?

[vlk]

dokym nevymyslia nieco este viac zrave a narocne na systemove prostriedky, ale to nebude vadit, to uz bude bezne mat v pocitaci 128GB RAM

[koroptev]

asi furt

napises to jednou a s minimemm usili (v porovnani s tim psat to nejspis v x ruznejch obvyklejch jazycich na x platformach) to bezi vsude + browser

[Profik]

Minimalne dokud nebude standardni linux desktop. Delat nativni apku/libku pro tri hlavni OS by jeste jakz takz slo. Ale voni nejsou jen win/mac/lin, ale lin je asi 5 rucnych deskopu v ruzych verzich protoze nekomu nestoji pri KDE6 ale musi mit KDE3 forknutou jak Trinity, jineho vzrusuje Gnome2 a Gnome47 je hereze, ale to Gnome2 musi byt Cinamon a tak muzu pokracovat donekonecna.

TLDR: Electron tu bude navzdy, resp. dokud bude Chromium Co ja vim treba za 10 let zacnou dratovat browser rovnou do CPU jako koprocesor nebo FPGA a pak to uz nebude treba?

[koroptev]

linuxovej desktop v tom imho nehraje zadnou roli, protoze nikoho nezajima, firmy na to necili

ale co pro ne hraje roli je, jestli musi mit 3 separatni tymy pro napr. windows / macos / web nebo jestli jim staci tym jeden a na tehle jednoduchejch poctech se nic moc menit nebude

[~]

Pro mnohe velke firmy linux desktop = web verze. Treba takovy MS Office, Adobe Photoshop, Affinity Designer atd. Maji tri teamy - win/mac/lin. Ten lin ma jednoho cloveka a posila linuxaky do <|>e odkazem na nejakou webovou sragoru

[PetebLazar]

Davinci Resolve od BlackMagicDesign snad používá Qt na Windows/MacOS/Linuxu, pochybuji že se najde srovnatelně výkonově intenzivní (značně GPGPU orientovaná) aplikace napsaná v Electron.

Přístup (jednou zaplatit DRS, či jej získat v bundle k jejich HW) s bezplatným upgrade na nové verze DRS je úplným opakem co v současnosti předvádí Adobe. Nemluvě o bezplatné verzi DR dostupné za registraci.

[+]

Vzhledem na to ze jiny priklad asi nenajdes to muzem povazovat za vyjimku potvrzujici pravidlo, ze linux desktop sal/saje/bude sat a nikdo pro nej nehne prstem vic nez Electron verzi.

[PetebLazar]

Pokud je opravdu jediná tak asi mohu zobecnit (na 100% vzorku), že HW každá náročná aplikace pro Linux je pod Qt.

[666]

Tahle progresivni sracna dopadne stejne jako multiplaformni java.

[koroptev]

ani ne, java nebezi nativne v browseru a napsanim javovsky aplikace neziskas totez zdarma skoro bez prace pro browser..

[xkucf03]

Java je dneska poměrně minimalistický způsob, jak psát multiplatformní aplikace v paměťově bezpečném a vysokoúrovňovém jazyce. (na to samozřejmě může někdo odpovědět, že framework nebo knihovna XY jsou moc komplexní a nelíbí se mu, ale já mluvím primárně o jazyce a platformě – ty knihovny a frameworky nad tím je potřeba si pečlivě vybírat a ten výsledný celek držet příčetný… ale to platí všude – knihovnami a frameworky lze komplexitu navyšovat donekonečna).

I dneska můžeš napsat v Javě aplikaci, která bude chodit i na operačním systému z roku 1995 a třeba i na tehdejším hardwaru. Spoustu aplikací, které se dnes píší tak, že požírají gigabajty RAM, by šlo napsat tak, aby běhaly i na třicet let starých systémech – a to svižně, protože ty aplikace často nic inherentně náročného nedělají – tu komplexitu a HW nároky k tomu přidává dnešní průměrný programátor.

[Pavel Píša]

+1

[koroptev]

minimalisticky urcite neznamena z pohledu programatora, java je cobol dneska (a +- i smeruje do stejne oblasti pouziti - korporaty / backend, ok, tam to nejsou jen korporaty)

[Martin Tůma]

Problém Javy na desktopu je, že z uživatelského hlediska je to katastrofa (pomalé a hnusné prakticky na jakékoliv platformě) a nikdo s tím nechce dělat. Pokud píšeš pro korporát, kde o tom jestli to budou používat nerozhodují samotní uživatelé, tak tě to nemusí zajímat, ale pokud chceš dělat "SW pro masy", tak to je deal-breaker, i když se v Javě píše rychle a levně.

Schválně se zkus zamyslet, kolik populárních aplikací v Javě (co nejsou IDE pro Javu) znáš...

[PetebLazar]

Nejsou prakticky všechny Android aplikace napsány v jazyku Java?

[PetebLazar]

O: Asi byl míněno pro desktop.

[Martin Tůma]

Ano byl, když někdo napíše:

Problém Javy na desktopu je...

většinou desktop myslí...

[koroptev]

to je stejnej dotaz jako "neni android vlastne linuxovej desktop?"

[_]

Neni ani linux. Android patche byly vyhozeny a Linus o nich nechce ani slyset A tak si Google musi drzet vlastni zbirku hacku, fucku a facepalmu aby slo linuxa vohnout v androida.

[Martin Tůma]

Ne, nejsou. I když budeš Kotlin považovat za "převlečeou Javu", stále je tu spousta "nativních" (od slova nativní kód) aplikací jako třeba hry a někteří extremisti používají dokonce i "desktopové" Qt.

[xkucf03]

Tenhle komentář mi připadá vnitřně rozporuplný. Neměl bys jako správná iOvce propagovat spíš Swift a nativní jablečné GUI?

[sid]

Hlavne preco electron ked je flutter.

[Profik]

Protoze nevis dne kdy Google flutter zarizne

[BoneFlute]

1. Nesmysl
2. Jestli 1/ byla nesmysl, tak tohle je nesmysl^2. Ale spíš už to smrdí trollením.
3. Zde se dotyčný pokoušel dovzdělat, ale zatím zůstal na startu:

Rust se začíná etablovat. Píší se v něm i desktopové aplikace. Zkouší se v něm různé strategie, od GTK (úspěšné)/QT (ještě čerstvé) bindingi, po všemožné abstrakce. Obecně UI je v Rustu velice punk. Je možné použít GTK a víceméně postaru napsat apku. Bude to dobré. Pokud šáhne po nějakém "zajímavém" projektu coby abstrakce, bude to bez záruky. V tomto směru se v Rustu ještě hodně vaří.

[koroptev]

zajimalo by me, kolik desktopovych aplikaci na win / macosu je napsanych v gtk / qt / nativnim frameworku platformy, procentuelne

a potom kolik webovych aplikaci si k sobe pise separatni klienty v cemkoli viz vyse, paklize platforma neni mobil

[RealJ]

Ale hovno, TCL je budoucnost.

[B]

Jde vidět, že jsi nikdy nic pořádného neprogramoval. Všechny tyhle scriptovací sračky (Tcl, Python, ...) napsané v céčku se hodí tak akorát na rychlokvašky, které mají jeden soubor a maximálně tak 100 řádků kódu. Na všechno ostatní si příčetný programátor zvolí kompilovaný jazyk. Bohužel spousta takzvaných programátorů to nechápe.

[RealJ]

Hlavne spousta programatoru jako ty nechape ironicky prispevek... ;)

[jozo34563456]

Ja som embedded developer, riesim povacsine drivery / low level stuff a GUI/Web ide mimo mna.

V automotive sa momentalne nepouziva ani rust ani electron(mozno kdesi v infotainmente ano ale to je mimo). Povacsine sa jedna o kombinaciu Yocto + Qt.

Lazarus/Delphi bol idealny v tom ze som mal Wysiwig navrh formmularov kde som si "naklikal vzhlad". Ak chcem nieco podobne v Qt musel by som si to nastudovat. Na lazaruse mi vadi to ze je to pascal - nemozem tam copy paste existujuci c/c++ kod

[RealJ]

Tak automotive je obvykle 10 let pozadu v cemkoliv.