Delphi - velké plány, 64bit a multi-platform

25.8.2010 17:02 | Přečteno: 1944× | gnu_linux | poslední úprava: 25.8.2010 17:15

Nechtěl jsem to navrhnout jako zprávičku, jelikož se to podle mě nedotkne Linuxu až tak brzy (2011 / 2012).

Jenže má tohle vůbec v dnešní době smysl? V Delphi jsem kdysi pár věcí dělal a byl jsem nadšený. Borland / Inprise ale zaspal dobu, dost opožděná verze pro Linux byla nejen komerční, ale i dost okousaná a mezitím se objevil a vypracoval relativně dobrý projekt Lazarus, který je navíc celý open source (jeho aktuální stav ale neznám, v Pascalu už jsem delší dobu nic nedělal, přešel jsem na Python, což mi na to moje občasné skriptování vyhovuje daleko víc).

Originální zpráva tady.

       

Komentáře

[Filip Jirsák]

Přejmenujou se zase na Borland? Návraty Delphi už jsou takový evergreen…

[pc2005]

Jo Borland (nebo ještě Turbo) Pascal byla skvělá věc. I když dneska bych v tom programovat moc nechtěl .

Schválně zda to dopadne jako Kylix, v době IDE jako Netbeans si budou muset máknout.

[Amarok]

Jo Kylix jsem myslel v blogu, nemohl jsem si vzpomenout na tu verzi pro Linux.

[virt6]

To mi připomíná, že bych si mohl zažádat o schválení balíku Lazarus do práce. Zatím to tam ochcávám Pythonem portable.

Pascal jsem měl rád a dodnes ho ovládám lépe než Python. Jsem holt "lama"

[Amarok]

To jsi spis old-school. FreePascal/ObjectPascal je prece nesrovnatelne slozitejsi nez Python. Nebo spis komplikovanejsi. I z toho duvodu uz jsem se k nemu nevratil, nemam cas se vetsinu ucit znova, s Pythonem toho je taky nad hlavu, a to umim jen zaklady.

[________________]

Delphi bolo plnohodnotné prostredie na vývoj aplikácií všetkého druhu ktorý sa kompiloval do strojového kódu procesora. Python je len primitívny skriptovací jazyk na pár riadkové skripty. Veď to sa nedá ani porovnávať.

[|🇵🇸]

Mno.

[virt6]

No. Zrovna RedHat by s vámi asi nesouhlasil. Ten tvoří Pythonu své administrační nástroje.

[Rezza]

Mam te nastvat nebo ne? Ze bych zacal psat v Object Pascalu? :D

[ext3fs]

Nechci rypat,ale samotny Pascal neni zrovna dobry priklad plnohodnotneho jazyka na produkcni programovani a Delphi uz vubec neni dobrym prikladem vhodneho jazyka/OOP jazyka. Ale je to jen muj nazor.

[________________]

ja Delphi neobhajujem, ja som s ním tiež nebol spokojný ja len nechápem ako môže niekto porovnávať prostredie na vývoj plnohodnotných desktopových aplikácií(Delphi) so skriptovacím jazykom Python.

[Amarok]

Abych to ujasnil, vyvojove prostredi Delphi se porovnavat neda, ja porovnavam ObjectPascal a Python. A Python jednoznacne vyhrava svoji flexibilitou, mnozstvim standardnich knihoven a jednodussi syntaxi. Jedina nevyhoda je jeho relativni pomalost (dokonce Ruby je o trosku rychlejsi), to je podle me jedine omezeni, ale zadny jazyk neni univerzalne vhodny na vsechno.

[________________]

Python vyhráva? Nebuď smiešny ako som už písal Python a Object Pascal sa nedá porovnávať lebo python neni plnohodnotný PROGRAMOVACÍ jazyk ale SKRIPTOVACÍ jazyk - Pythonu NEROZUMIE PROCESOR, Object Pascal sa naproti tomu prekladá do strojového kódu ktorému ROZUMIE PROCESOR. Python sa hodí len na niektoré typy úloh, v object pascale môžeš napísať aplikácie všetkého druhu, je to univerzálny programovací jazyk. Skús v pythone napísať obyčajnú Windows aplikáciu bez závislosti na interpretery pythonu. A čo sa týka knižníc tak Delphi ich má oveľa viac(niekoľko desiatok tisíc) ale to sa ani nedá porovnávať pretože knižnica v pythone a knižnica v delphi je už z princípu niečo úplne iné. A čo sa týka rýchlosti Python vs. Ruby tak sa mýliš Ruby má pomalší interpreter ako Python.

[kralyk z abclinuxu]

Co je na skriptování neplnohodnotného?
Tady si někdo urychleně potřebuje přečíst Master Foo and the Ten Thousand Lines

[________________]

Veď to práve píšem v tom príspevku nad tebou. Keby bol Python plnohodnotný programovací jazyk tak by sa zaobišiel bez jazykov ako C++ prečo neni samotný interpreter pythonu napísaný celý v pythone? lebo to jednoducho neni plnohodnotný jazyk. V Object Pascale by si mohol naprogramovať trebárs aj interpreter pythonu.

[kralyk z abclinuxu]

Tovje definice pojmu "plnohodnotný programovací jazyk" je podivná. Z takového hlediska je plnohodnotným programovacím jazyke jen C/C++, Object Pascal, ASM a pár dalších staticky kompilovaných jazyků. Z takového hlediska není "plnohodnotným programovacím jazykem" ani C# a Java, protože potřebují runtime, který nenapíšeš sám v sobě.

[Filip Jirsák]

Myslím, že existuje i JVM napsaná v Javě (každopádně je to proveditelné). A také existují interprety C nebo Pascalu, což by znamenalo, že toto nejsou plnohodnotné programovací jazyky.

[________________]

interpretované C a interpretovaný pascal nie je plnohodnotný jazyk.

[Jendа]

Takže když napíšu Hello World v C a pak to přeložím GCC, tak jsem psal v plnohodnotném jazyce, ale když úplně ten stejný soubor spustím interpretovaně, tak jsem v plnohodnotném jazyce nepsal?

[________________]

Toto je len chytanie zaslovíčka. Aspoň vidím že chápeš ako som to myslel.

[Jendа]

Takže jestli to chápu, tvoje definice plnohodnotného jazyka je, že pro něj existuje kompilátor, který z programu vyrobí strojový kód.

[|🇵🇸]

Co je podle tebe plnohodnotný jazyk? @_@ Lisp asi ne...

[________________]

C, C++, Pascal, Eiffel, ADA, Fortran atď atď je ich veľa

[kralyk z abclinuxu]

Myslím, že existuje i JVM napsaná v Javě (každopádně je to proveditelné).

No to nejde. Leda by se to z Javy přeložilo přímo do strojáku, což je samozřejmě možné, ale už je to jiná situace, než běžné psaní programů v Javě, ačkoli jazyk je stejný...

[Filip Jirsák]

Ještě že to nevěděli autoři projektu joeq, že to nejde, a udělali to.

[kralyk z abclinuxu]

Hned v prvním kroku bootstrapingu píšou tohle:

1. Load joeq into a 'host' Java virtual machine. joeq is completely written in Java, which means a Java virtual machine can load and execute the code.

[Filip Jirsák]

No a co? Program v Javě běží pod JVM. To je celkem normální, takhle běží každý program napsaný v Javě.

[kralyk z abclinuxu]

Jo. Ale plyne z toho, že to JVM napsané v Jave nerozjedeš bez pomoci jiného JVM napsaného v něčem jiným nebo nakompilovanýho staticky...

[Filip Jirsák]

Nebo na hardwarové JVM. Ostatně klasický program v C taky nespustíte bez nějakého běhového prostředí, které mu poskytuje operační systém.

[kralyk z abclinuxu]

To je pravda. Koneckonců, afaik i programy v ASM nějaké to prostředí potřebují...
A s rozvojem technologií jako Clang/LLVM platí pro C/C++ podobné co pro Javu...

[Pavel Stárek]

Toto je přeci klasický problém slepice a vejce

[________________]

No veď tie staticky typované jazyky sú naozaj plnohodnotné jazyky lebo v nich môžeš naprogramovať akýkoľvek druh aplikácie a preto sú najpoužívanejšie. C# a Java nie sú plnohodnotné jazyky ale sú univerzálnejšie ako Python. A čo sa týka rýchlosti java sa kompiluje do bytecode a z neho v rámci JIT kompilácie do strojového kódu, C# sa prekladá CIL a z neho tiež v rámci JIT kompiluje do strojového kódu. Python sa prekladá do bytecode a ten sa priamo interpretuje preto je omnoho pomalší ako Java.

[Jendа]

No veď tie staticky typované jazyky sú naozaj plnohodnotné jazyky lebo v nich môžeš naprogramovať akýkoľvek druh aplikácie

A v těch ostatních nemůžu naprogramovat jakýkoli druh aplikace?

Python sa prekladá do bytecode a ten sa priamo interpretuje

Ehm…

[________________]

>A v těch ostatních nemůžu naprogramovat jakýkoli druh aplikace?

nie.

[Jendа]

nie.

Například?

Jinak s tím Pythonem - kdo říká, že se ten bytecode musí hned vykonávat a nemůže se uložit napotom jako u Javy?

[________________]

no skús v pythone naprogramovať napr. rýchly 3D grafický engine, bez použitia knižníc napísaných v iných programovacích jazykoch.

[kralyk z abclinuxu]

Uvědom si, že rychlé 3D grafické a podobné enginy napsané v C/C++ používají poměrně drsné per-platform HW-specifické optimalizace realizocvané většinou asemblerem. Čili čisté C/C++ to taky není.

Jde jen o to, že tyto optimalizace se v C/C++ (a dpoboných jazycích) lépe realizují.

[Jendа]

Aha, já čekal nějakou věc, která nejde z principu toho jazyku.

[kralyk z abclinuxu]

Ale ono to by to afaik šlo i v tej Javě, akorát by kompilace byla složitá a celkově by to bylo nepraktické řešení, protože použít (např.) céčkové knihovny je pro každého vývojáře prostě rychlejší.

[________________]

v jave áno v pythone v žiadnom prípade.

[Amarok]

no skús v pythone naprogramovať napr. rýchly 3D grafický engine, bez použitia knižníc napísaných v iných programovacích jazykoch. ... v jave áno v pythone v žiadnom prípade.

Teda ja uz jsem z toho jelen. Prece je nesmysl, ze by se v Jave dal napsat 3D engine (slovo "rychly" vynechejme, ted nejde o rychlost), aniz by byl pouzit jiny nez Java kod. Ty Java knihovny, ktere se tam pouziji, jsou treba napsane samy o sobe v Jave, ale samy pouzivaji opet dalsi knihovny, ktere uz v Jave nejsou, az se postupne takto dostaneme treba az k Assembleru. Vidim tam dost podobnosti s Pythonem.

(Jinak pojem skript vs. program je vec pohledu, ja to tak dramaticky nerozlisuju. Skript muzu taky zkompilovat a mam z toho program. Je to jen slovni hricka.)

[________________]

java je niekde na polceste

[Radek Miček]

Ale jistě, že by to šlo i v Pythonu.

[________________]

Tak mi sem teda daj príklad 3D enginu celého napísaného v pythone bez doplnkových knižníc napísaných v C++ toto je len filozofovanie čo by bolo keby atď.

[kralyk z abclinuxu]

No a co kdybys ty dal příklad "rychlého" 3D enginu napsaného jen v C/C++ (nebo podobném jazyce)?

Btw. pochybuju, že existuje takový engine v pythonu. Z praktických důvodů se to nedělá. To ale ještě neznamená, že to nejde.

[________________]

myslím že nemá zmysel vyvracať argumenty odtrhnuté od reality

[kralyk z abclinuxu]

Souhlasím. Ještěže jsem takové neuvedl

[________________]

programovať graficvký engine v pythone je odtrhnuté od reality, nikto to nerobí prečo asi?

[kralyk z abclinuxu]

programovať graficvký engine v pythone je odtrhnuté od reality, nikto to nerobí prečo asi?

To už jsem říkal. Je to nepraktické.
Ale ok, ukaž mi příklad takového "rychlého" 3D grafického enginu napsaného v čistém C/C++, bez asm optimalizací.
Anebo se koukni do zdrojáků nějakého video kodeku - hádej co najdeš. Správně. Hafo asm.

[__dark__]

Mícháš jablka s hruškama, a přidáváš k tomu ještě jahody.

Vhodnost jazyka na nějakou úlohu určitě není způsobená statickým nebo dynamickým typováním, to je záležitost programovacího stylu. Dále pokud je rozhodující rychlost, tak volím obecně staticky typovaný jazyk (lepší optimalizace a paměťová náročnost), ale toto nemusí být pravidlo a je tu jedna velká výjimka u webových aplikací (javascript, kde není jiná možnost).

Java nemusí být vždycky kompilovaná do bytecode, jsou i projekty pro překlad javy do nativního kódu, jaký je to pak jazyk podle tvoji definice?

Podle mě to co tvoří programovací jazyk je jeho syntax, základní a externí knihovny. Python by nebyl tak široce používaný, kdyby neměl knihovny, to ani java, .net, atd. Pro skriptovací jazyk může být rozhodující i to, kolik dá práce udělat most mezi C/C++ kódem a skriptem. Věřím dokonce tomu, že pro některé vývojáře je dostupnost a kvalita knihoven vyšší faktor, než jazyk samotný (i když je to podle mě špatně).

[Jendа]

Java nemusí být vždycky kompilovaná do bytecode, jsou i projekty pro překlad javy do nativního kódu, jaký je to pak jazyk podle tvoji definice?

Navíc u mnoha mobilů nebo smart karet by se podle mě klidně dalo říct, že Java (ME) je jejich nativní kód. Protože J2ME JRE je tam v podstatě natvrdo vysmažené v hardware.

[__dark__]

No vida, na to jsem úplně zapomněl, i když to podle mě rozhodně není budoucnost.

[pc2005]

Imho jo aspoň v ARMu přidávaj další a další instrukční módy v tomto smyslu.

[__dark__]

To jsou spíš multimedialní instrukce ne? Podle mě je v tomto případě lepší JIT, sice to zabere trochu paměti, ale lepší než drátovat jazyk přímo do procesoru :)

[pc2005]

Jo multimediální instrukce to má taky, stále nový a nový, ale podle toho co jsem napsaldole, jsou ty módy minimálně tři (podpora pro javu a pak podpora pro JIT).

Jinak i mě připadá cpaní Javy do ARMu trochu overkill, ale když se tam už cpou multimedialní opkódy a spotřebu to extra nezvedne, tak proč ne. Zajímavý by bylo tyhle módy vyhodit a nahradit nějakým supermódem, kde by šly i celý architektury. A nebo ušetřené místo použít pro další ARM jádro (ale tolik ho asi nebude).

[Ladicek]

Python napsaný v Pythonu samozřejmě existuje, a celá argumentace bootstrapem je u programovacích jazyků nanejvýš pomýlená, povrchní a zavádějící.

Vůbec tady šíříte množství bludů (namátkou: dynamicky typované jazyky nelze přeložit do nativního kódu, skriptovací jazyky se poznají podle toho, že jsou interpretované, skriptovací jazyky nejsou plnohodnotné), ale takovéhle diskuse už jsem vedl stokrát a tisíckrát. Nemám chuť na další.

[Filip Jirsák]

Co vám brání použít nějaký intrepret Pascalu nebo naopak napsat pro Python kompilátor do strojového kódu?

[________________]

Už samotná dynamická povaha jazyka.

[Filip Jirsák]

To znamená co? Vzhledem k tomu, že ten kód nakonec stejně běží na procesoru, nějaká cesta od zdrojového kódu v Pythonu ke strojovému kódu musí existovat.

[________________]

proste je to nezmysel, ako chceš skompilovať napr. toto:

x = 'y = 1 + 1'
exec(x)
print y

vidno že si nikdy nevytvoril vlastný interpreter programovacieho jazyka :D

[Radek Miček]

ako chceš skompilovať napr. toto

Kompilátor může být součástí zkompilovaného programu.

[pc2005]

Není nic jednoduššího, tohle dokážu i ručně.

plus:
	mov ry,1
	add ry,1
	ret
main:
	mov rx,&plus
	call rx
	mov rp,ry
	call print_val	;number in rp

	call exit

Jo to kdybys chtěl print x, tak by to bylo horší . Ale nemyslím, že by byl takový problém udělat hardwarový interpreter i pro věci jako perl nebo python, koneckonců ani C nebo třeba brainfuck (ten by byl nemálo triviální ). Tuším, že i LISP měl hw. zpracování a takovej postscript je taky skvělá věc (emulace v tiskárně, emulace v prohlížeči).

Jediný problém je výpočetní síla, ale podle tohoto kritéria by se vyplatilo všude používat jen assembler popřípadě strojový kód. U postscriptu je naopak hw. provádění jedno z nejefektivnějších.

[________________]

okej a prelož mi prosímťa aj toto:

a = raw_input("zadaj hocijaký python kód na vykonanie"); exec(a)

presne toto som čakal zase chytanie za slovíčka a fylozofovanie. o tom čo sa dá a čo nedá keď si taký múdry tak vyrob hardwarový interpreter Pythonu. Tieto argumenty sú postavené na nezmyselných konštrukciách čo by bolo keby.

[________________]

oprava:

a = raw_input("zadaj hocijaký python kód na vykonanie")
exec(a)

[pc2005]

Já teda moc python nemusím protože má dost mizernou kompatibilitu (skoro vždycky když jsem si do slacka něco nainstaloval v pythonu, tak tomu vyjelo x řádků o chybě - holt nevýhoda stable přístupu..), pak má tuším taky odsazování přes whitespace, což je taky dost silný kafe na mě.

Ale za předpokladu, že je podobný jako perl, tak už samotný text co jsi napsal, je zkompilovaná forma programu. Není problém udělat procesor, který bude konat stejný postup jako interpreter, pouze natvrdo zadrátovaný. Jediné kritérium je pak rychlost, protože je rozdíl mezi několika takty nativního kódu a mnoha takty při parsovaní řetězců nějakým mooreovým automatem. Ale to je pak jak už jsem psal (z tohoto hlediska) nejefektivnější psát ve strojáku.

Jinak taková vtipná myšlenka, on i x86 kód je vlastně interpretovaný a to mikrokódem (ten může být tuším ještě interpretovaný nadrátovaným automatem). A samozřejmě tu pak jsou věci jako popis struktury FPGA jazykem C a dokonce už měl někdo nápad na Python bytecode procesor (takovej Java bytecode processor už existuje, pravděpodobně ho máš v mobilu).

Každopádně pythonem jdou udělat ty samé věci jako céčkem, pascalem nebo třeba javascriptem (má v tom prsty pan Turing).

[Jendа]

Tak to asi bude muset být interpreter Pythonu součástí zkompilovaného programu.

[________________]

jedine tak a niektoré časti sa budú kompilovať počas behu programu, čo samozrejme bude bude mať nemalú réžiu a spomalovať vykonávanie programu a vpodstate sa tým stratí výhoda kompilovaného jazyka. a okrem toho toto všetko sú len nezmyselné teoretické úvahy python je interpretovaný jazyk, keby sa python dal skompilovať pravdepodobne by sa používal aj tam kde sa dnes používajú plnohodnotné jazyky, python sa ale používa len ako doplnkový jazyk na tvorbu pluginov a rozširovanie aplikácie alebo ako prostriedok na tvorbu menších web aplikácií.

[pc2005]

Jen tak otázka: Jaká úloha potřebuje za vstup zdrojový kód a jak bys jí řešil plnohodnotným jazykem (typu C)?

python sa ale používa len ako doplnkový jazyk na tvorbu pluginov a rozširovanie aplikácie alebo ako prostriedok na tvorbu menších web aplikácií.

Před pár hodinama to byl skriptovací jazyk na pár řádků .

[|🇵🇸]

No, však za moment se dostaneme k realitě. ~.^

[________________]

>>Před pár hodinama to byl skriptovací jazyk na pár řádků.

to je aj teraz.

>>Jaká úloha potřebuje za vstup zdrojový kód a jak bys jí řešil plnohodnotným jazykem (typu C)?

žiadna, veď práve preto nemá používanie dynamických jazykov žiadny podstatný prínos.

[Jendа]

žiadna, veď práve preto nemá používanie dynamických jazykov žiadny podstatný prínos.

Tak co ti brání, abys Python používal jako statický?

[________________]

aký zmysel má používať pomalý dynamický jazyk ako statický? kaď chcem použiť statický jazyk s python syntaxou použijem boo.

[pc2005]

No pár jsou dvě , v jiném významu tak v řádu jednotek až desítek. Ale ty projekty z tý wikipedie budou mít tisíce.

No ony ty jazyky nemaj jedinou výhodu spočívající ve schopnosti provádět vlastní zdroják...

[__dark__]

žiadna, veď práve preto nemá používanie dynamických jazykov žiadny podstatný prínos.

LOL. Osobně mám taky radši staticky typované jazyky, ale tato hláška je perla!

Kdo nikdy nevytvořil kód v dynamicky typovaném jazyce, asi nikdy nepřijde na to, že ta dynamická povaha jazyka je strašně flexibilní, a někdy může práci naopak ušetřit.

Dynamické typování se často pomocí pomocných tříd používá i ve staticky typovaných jazycích, je to všude - Qt, Glib, .NET, atd... A naopak někdy se zase zavádí statická kontrola do dynamicky typovaných jazyků.

Meze se posunujou. Před 10 lety by mi nikdo nevěřil, že v tom pomalém javascriptu někdo napíše použitelný emulátor 8bitu nebo klon boulder dash. Nebo že někteří blázni začnou v tekovém jazyce psát UI pro mobilní zařízení.

[pc2005]

Meze se posunujou. Před 10 lety by mi nikdo nevěřil, že v tom pomalém javascriptu někdo napíše použitelný emulátor 8bitu nebo klon boulder dash. Nebo že někteří blázni začnou v tekovém jazyce psát UI pro mobilní zařízení.

Jj nebo třeba tuhle google a pacman . A to nejsou ty nejvýkonější věci. Takovej wolf3D je taky dobrej , myslím, ze jsem viděl i něco s 3D.

Jinak slyšel jsem, že stránky Expa 2010 maj 3D renderovanou prohlídku ve flashi.

[Filip Jirsák]

jedine tak a niektoré časti sa budú kompilovať počas behu programu, čo samozrejme bude bude mať nemalú réžiu a spomalovať vykonávanie programu a vpodstate sa tým stratí výhoda kompilovaného jazyka.

Kompilaci až za běhu používají třeba některé multimediální přehrávače – ne kvůli tomu, aby byly pomalejší, ale právě naopak. vaše úvahy o tom, co je rychlé a co pomalé svědčí akorát o tom, že toho o tom, jak fungují programy a procesory mnoho nevíte.

a okrem toho toto všetko sú len nezmyselné teoretické úvahy python je interpretovaný jazyk

To nevadí, že vám to tady několik lidí vyvrátilo, stejně budete trvat na svém.

keby sa python dal skompilovať

On se dá zkompilovat. Víte třeba o existenci Jythonu?

pravdepodobne by sa používal aj tam kde sa dnes používajú plnohodnotné jazyky, python sa ale používa len ako doplnkový jazyk na tvorbu pluginov a rozširovanie aplikácie alebo ako prostriedok na tvorbu menších web aplikácií.

To, že vy nevíte o existenci velkých aplikací napsaných v Pythonu, ještě neznamená, že neexistují.

[Filip Jirsák]

Víte o tom, že gcc nebo ld jsou napsané v C? Oba pracují tak, že načtou nějaký soubor na vstupu, zpracují jej a zapíší něco na výstup. Nebyl by problém z nich udělat knihovní funkce, které předáte pole bajtů a na výstupu dostanete jiné pole bajtů – dost možná, že takové knihovní funkce už někde existují – já si je pojmenuju gcc() a ld().

#include <stdio.h>

int main(void)
{
  char x[] = "int y = 1 + 1";
  void *o = gcc(x);
  void *out = ld(o);
  (*out)();
  return 0;
}

V čem se liší tenhle program v C od toho vašeho v Pythonu (až na ty memoryleaky)?

[pc2005]

Wow, tím jsi mě připomněl projekt pana Bellarda, který využil svůj skoro JIT C kompilátor na zkompilování jádra před jeho samotným nabootováním .

[Filip Jirsák]

Teď jste ovšem Blizzbozovi prozradil, že i jádro může běžet v interpretu, takže vlastně ani linuxové jádro není plnohodnotný program.

[pc2005]

Což ovšem nemusí být pro diskuzi na škodu .

[Filip Jirsák]

Diskuzi ne, ale možná je to na škodu Blizzbozovi. Kdo ví, jestli by teď nepotřeboval vzkřísit.

[pc2005]

Škoda, přitvrdil bych .

[________________]

a čo?

[deda.jabko]

prosimte, zpomal... ze zacatku to bylo vtipne, ale ted uz ne.

to ze, neco neexistuje, neznamena ze to nejde. psat interpreter/prekladc v interpretru/prekladaci jazyka je naprosto bezna zalezitost. mj. to ma uplatneni pri vyuce programovani... doslova ucebnicovym prikladem je implementace Schemu ve Schemu, kterou v SICP navrhuje abelson a sussman.

[________________]

Ale to predsa neni podstatné čo jde, podstatné je ako to funguje v praxi.

Napísal som:

Delphi bolo plnohodnotné prostredie na vývoj aplikácií všetkého druhu ktorý sa kompiloval do strojového kódu procesora. Python je len primitívny skriptovací jazyk na pár riadkové skripty. Veď to sa nedá ani porovnávať.

A to je pravda. Zatiaľ tu nezaznel ešte ani jeden relevantný argument ktorý by vyvrátil to čo som napísal.

[pc2005]

ktorý sa kompiloval do strojového kódu procesora.

Podporuje i LISPový stroj? Klidně snížím požadavky na ARM, ale i na ten by bylo potřeba něco jako QEMU, což je "interpreter".

Python je len primitívny skriptovací jazyk na pár riadkové skripty.

Tohle nestačí?

P.S. Heh asi bych neměl zmiňovat, že bych rád dodělal emulátor 486 procesoru v perlu a nabootoval na něm to by pak byl třeba Windows 98 celej interpretovanej.

[________________]

čo je to lispový stroj? používa to niekto alebo je to ďalší fylozofický výmsel.

>>Tohle nestačí?

čo ste tým chceli povadať?

>>P.S. Heh asi bych neměl zmiňovat, že bych rád dodělal emulátor 486 procesoru v perlu a nabootoval na něm to by pak byl třeba Windows 98 celej interpretovanej.

tak to želám vela šťastia...

[pc2005]

Neznáš LISPový stroj? :-O LISPový stroj uměl vykonávat jazyk LISP. Což je vysokoúrovňový jazyk, který pracuje se vším jako se seznamy, za seznam tuším může mít i funkci (měl jsem jen potomka Scheme). Imho skriptovaný jazyk co se neinterpretuje.

Ty projekty na wikipedii nevypadaj jako skripty na pár řádků. Tedy alespoň v tomhle případě bych Python nepovažoval za primitivní.

Dík, budu ho potřebovat, abych měl dost síly pokračovat .

[________________]

Verím tomu že taký stroj existuje a verím tomu že je to pekná zaujímavosť a hlavne verím tomu že to v praxi nikto nepoužíva. Tak ako v praxi nikto nepoužíva Lisp(až na jedno promile AUTOCADistov) a pár vysokoškolákov ktorí sa to naučili ako zaujímavosť ale v reále to nikde nevyužijú, to už aj exotický Python má širšie uplatnenie.

http://ipremiere.eu/images/languages_all_5yrs.png

Keby boli Lispové stroje taký prínos určite by programátori opustili C# Javu a C++ a pustili sa do štúdia Lispu.

[________________]

predpokladám že teraz mi sem dáš linky na projekty napísané v lispe a možno ich sa ich nazbiera veľa parcentuálne je to ale zanedbateľné množstvo, jednoducho lisp sa v praxi nepoužíva.

[pc2005]

Už ne, sice trochu opožděně, ale přece, jsem tady dokázal, že není potřeba interpreter Pythonu, Perlu apod. a že tedy jsou tyto jazyky na stejné úrovni jako C nebo Pascal.

[|🇵🇸]

Emacs. Výzkum umělé inteligence. A celkem dost programů ho používá (třeba Maxima). Detaily si snadno najdeš na Wikipedii.

[pc2005]

Hmm tak to vypadá, že je hotovo podle tý wiki umí část procesoru ARM nejen provádět Javu, ale i Python, Perl apod. A když to nacpali i do ARMu, tak to bude možná efektivnější (čas, energie) než nativní kód x86 - tedy třeba C.

Jinak i takovej procesor Transmeta Crusoe (četl jsem, že se dával i do foťáků) iterpretuje x86 kód nad svou vlastní instrukční sadou (a je to víc než jednoduchej mikrokód). A výpočetní výkon byl prakticky stejný jako má komp, ze kterýho píšu.

[Filip Jirsák]

Proč by to nešlo zkompilovat? Jde vám zkompilovat násleudjící kód v C?

#include <stdio.h>

int main()
{
   printf ("%s \n", "A string");
   return 0;
}

Je v tom nějaký principiální rozdíl oproti vašemu kódu?

[________________]

predstav si že obsah premennej x sa načíta napr. z databázy.

[Filip Jirsák]

V tom není žádný rozdíl.

[________________]

je v tom rozdiel, lebo ty v čase prekladu nevieš čo je uložené v databáze tak ako to chceš preložiť?

[Filip Jirsák]

Přeložím to později, až se dozvím, co v té databázi je.

[________________]

ale to potom musíš prekladať vždy odznova takže ten kód inak povedané interpretuješ.

[Jendа]

Ale to přece v jiných jazycích taky!

[pc2005]

Nemusí, pro přeložení modulu Linuxu, taky nepotřebuješ obecně přeložit celý jádro znova.

Přitvrdíme: Dokonce ani když ve FPGA procesoru chceš najednou třeba spočítat matici, tak stačí změnit část procesoru klidně softwarem, který na tom procesoru běží. Zajímalo by mě co tady interpretuje co .

BTW já si imho myslím, že pokud se vyvine UI, tak že za nima budou stát minimálně dynamicky typovaný jazyky (asi ovládající nějakou databázi).

[________________]

a?

[Filip Jirsák]

To samé dělá linuxové jádro, překladače C, multimediální přehrávače… Chcete říci, že to nejsou plnohodnotné programy?

[Šerpik]

A co takhle zkusit Phyton v Delphi http://www.atug.com/andypatterns/pythonDelphiTalk.htm

Existuje i komponenta interpretru (Object)Pascalu a možná i nějakých dalších jazyků.

[________________]

jj to som používal kedysi

[ext3fs]

Jinak abych jen neplacal tak podam par prikladu:

- kdysi na VS jsme psali projekty do predmetu Algoritmy umele inteligence, jednalo se ve smes o prohledavani stavoveho prostoru ruznyma metodama (lifo,fifo,A*,...)...celkove vzato bylo reseni tehoz problemu v C mnohem efektivnejsi nez v Delphi a v Jave o neco mene efektivnejsi nez v Delphi.

- spoluzak tehdy psal program pro diplomku na rozpoznavani OCR (v Delphi) a v zaveru zacal poznavat ze ho Delphi velmi omezuje (ac jej pred tim honosne vyzdvihoval nad C)

[________________]

Miešaš jablká s hruškami Delphi neni jazyk ale prostredie. Ja mám tiež radšej C like syntax lebo je kratšia a stručnejšia ako Pascal like syntax. Preto používam jazyk C#.

[|🇵🇸]

AFAIK v jedné z pozdějších verzí Delphi se Object Pascal už jmenoval Delphi.

[Ladicek]

Delphi Language.

[ext3fs]

Otazka zda C# je nejaka vyhra....

[Amarok]

Python je len primitívny skriptovací jazyk na pár riadkové skripty.

Slunce se toci taky kolem Zeme, ze jo. Vyznas se v Delphi, tak pis komentare o Delphi a ne o necem, s cim jsi se delsi dobu nezabyval.

[________________]

Delphi už 10 rokov nepoužívam.

[PPK]

Dyt to jsou furt dokola stejny pohadky. 64bit sliboval uz borland nekdy v roce 2005. Pokusy s linuxem uz byly a dopadlo to katastrofalne. Dokud neuvedou realnej, funkcni a pouzitelnej produkt tak jim neverim ani nos mezi ocima

[kralyk z abclinuxu]

V Borlandím prostředí je AFAIK napsaný slavný Total Commander, ale nevim, jestli to je Borland C++ nebo Delphi, ale mam dojem, že Delphi. Což je docela síla, to by člověk neřek, vzhledem k tomu, že Pascal je určený na výuku programování a většina věcí se v něm řeší dost neflexibilně...

[Ladicek]

To asi bude tím, že mezi Wirthovým Pascalem, určeným pro výuku programování, a různými Pascaly určenými pro normální programování, je dost velký rozdíl. A borlandí překladače C++ a Delphi mají (nebo přinejmenším měly) totožný backend, což něco málo o vlastnostech Delphi napovídá.

A teď se na mne vrhne ponkrácovská klika

[deda.jabko]

a různými Pascaly určenými pro normální programování, je dost velký rozdíl.

jo, to vetsina lidi nechape. navic si neuvedomuji, ze v pascalech ala delphi se programuje uuuuuuplne, ale uplne jinak. typicky se pascalu vycita priserna prace s ukazately... v delphi jsou takove veci spis pro zpetnou kompatibilitu a diky pouzitemu objektovemu modelu nejsou potreba (stejne jako v jave).

proti moznostem toho jazyka bych mel vyhrady... neni tak expresivni jako ostatni. ale u javy se to povazuje za killer feature.

co se mi na delphi libilo, kdyz jsem v nem nekdy na prelomu tisicileti delal, byla standardni knihovna. bylo u ni videt, ze se nad ni premyslelo a ktera mela koncepci. a nebyl to zmet napadu slepena dohromady.

[kralyk z abclinuxu]

co se mi na delphi libilo, kdyz jsem v nem nekdy na prelomu tisicileti delal, byla standardni knihovna. bylo u ni videt, ze se nad ni premyslelo a ktera mela koncepci. a nebyl to zmet napadu slepena dohromady.

K tomu dávám +1, to je pravda.
Na druhou stranu, ona ta standardní knihovna byla dost pověšená na win32 API. Vím, byly tam cross-platform-ready části, nicméně zdaleka ne všechno.

[__dark__]

K tomu dávám +1, to je pravda. Na druhou stranu, ona ta standardní knihovna byla dost pověšená na win32 API. Vím, byly tam cross-platform-ready části, nicméně zdaleka ne všechno.

Těžko zrovna toto vyčítat. Kód mezi Delphi a C++Builderem byl sdílený, a když jsem opravdu hodně dávno nainstaloval C++Builder 1.0 na Win95 desktop, byl jsem z toho nadšený. Form designer byl na tu dobu vymakaný, velice jednoduché bylo vytvořit si DIBSection a renderovat si vlastní widgety, prostě paráda;) Hodně aplikací, co vzniklo v té době používalo právě C++Builder.

[Rezza]

VLC je moc pekna knihovna, jen moc navazana na Windows. Jinak spousta databazovych komponent - na to co jsme delali fakt perfektni - kdyz chtel clovek neco vic, ano bolelo to, ale porad pekne udelane. Ja na Delphi nedam dopustit, napsat nekdo neco ala Delphi pro Qt/C++ (jako IDE), tak... A Object Pascal nakonec umim asi nejvic - znovu, ne tolik moznosti jako v C++, ale jednoduchy jazyk co umel i objekty. Nedaji se tam delat silenosti, ale na co?

[Pavel Stárek]

co se mi na delphi libilo, kdyz jsem v nem nekdy na prelomu tisicileti delal, byla standardni knihovna. bylo u ni videt, ze se nad ni premyslelo a ktera mela koncepci. a nebyl to zmet napadu slepena dohromady.

No, ona slavná knihovna byla možná dobrá, ale v rámci Delphi. Jakmile člověk chtěl trošku hlouběj (použít něco z Win32 API - psali jsme kdysi aplikaci, která používala sériové porty) tak to zase taková výhra nebyla. V principu to byla zplácanina mezi borlandím runtimem <-> MFC <-> Win32 API. A tuto zplácaninu rovněž používal Borland C++ Builder 5 a vyšší. Ale jinak v celku proti Delphi nic nemám, bylo v tom napsáno mnoho všelijakých aplikací a svého času bylo na výsluní a používalo se hodně.

[Amarok]

Lidi, zahoďte už konečně tohle klišé!! To když čtu, tak pokaždé znovu žasnu. Pascal vytvořený panem Wirthem je záležitost ze 70. let, to nemá s moderním Pascalem vůbec nic společného, zůstalo jen pár klíčových slov.

[Cervajz]

+1 Naprosto souhlasím. Nechápu, že se pořád traduje, že Pascal patří na střední školy a pořádně se v tom nedá dělat. Jen pro ilustraci - společnost, ve které pracuju jako vývojář, prodává aplikace vytvořené v Object Pascalu (Delphi) od 400 tis Kč výš....

[Miloslav Ponkrác]

Jen pro ilustraci – v COBOLu si vyděláte ještě daleko vyšší částky, a přesto se nedá říct, že to dokazuyje úžasnost, modernost a genialitu jazyka COBOL.

[Miloslav Ponkrác]

„Pascal vytvořený panem Wirthem je záležitost ze 70. let, to nemá s moderním Pascalem vůbec nic společného, zůstalo jen pár klíčových slov.“

Jako obvykle, boření mýtů je vždy provázeno vytvářením daleko větších mýtů.

Moderní Pascal je naprosto celý Wirthův Pascal (snad až na pár detailů) + něco navíc. Pokud někdo napíše, že moderní Pascal a Wirthův nemají nic společného – pak je to lhář a já osobně už bych mu nevěřil ani slovo.

Nicméně jsou lidé, kterým lze věřit, a jsou lidé, kteří si z úst dělají holubník.

[Amarok]

Moderní Pascal je naprosto celý Wirthův Pascal (snad až na pár detailů) + něco navíc.

Jde o to, jestli se bavime o teorii Wirthova Pascalu nebo o hotovem kompilatoru.

Tvrdit, ze koncepce a vlastnosti Pascalu ze 70.let jsou stejne jako z 90. let a z tohoto tisicileti je silenost. To "+ neco navic" dokazuje jen to, ze jste se tim dostatecne nezabyval, ja delal v TurboPascalu 6, 7 a pak v nekolika verzich Delphi od 1 az asi po 4 a rozdily byly obrovske, ze se skoro nedalo mluvit o stejnem jazyku a vyvoj jazyka sel s kazdou verzi o kousek dal (samozrejme i zasluhou knihoven, ne jen koncepce jazyka). A to porovnavam jenom TurboPascal a ObjectPascal. Podobnost syntaxe nic nerika, Modula taky neni Pascal.

[kralyk z abclinuxu]

Beru, že dnešní Object Pascal už asi vypadá jinak, než staré podoby toho jazyka.
Nicméně, je potřeba se zamyslet nad tím, co Object Pascal nabízí?
Kompilátor+standardní knihovny, jejichž přenosnost je diskutabilní a jazyk, který je stavbou podobný C++, ale méně ohebný.
Jakou přináší Object Pascal výhodu oproti C++?
Jedinné, co mě napadá je, že je snazší na pochpení. To je vše...

[sivlk]

> Jakou přináší Object Pascal výhodu oproti C++?

- with
- 'a'+'b' je string :)
- neskutocne rychlu kompilaciu (milion riadkov za 10s)
- ...

[kralyk z abclinuxu]

Ten with beru, člověku to kolikrát ušetřilo zuřivé cvakání na klávesnici.
To 'a'+'b' je opravdu drobnost...
A co se týče rychlosti, dalo by se to něčim podložit?

[__dark__]

Sorry, ale rychlost kompilace by nikdy neměla být brána v úvahu při výběru programovacího jazyka. V dnešní době, kdy je čtyřjádro dostupné i pro obyčejné uživatele (a programátoři už můžou pořídit procesor s 6 nebo 8 jádry) je to podle mě naprosto nelogický argument. Navíc pro vývoj je většinou možné vypnout optimalizace, a v takovém případě se i to C++ kompiluje celkem rychle.

Takže, až bude někdy někdo vymýšlet programovací jazyk, a kvůli rychlosti parsování a kompilace zvolí naprosto debilní syntax jako třeba GO, tak se nesmí divit, že v tom nikdo nechce dělat :)

[sivlk]

Vo firme stale pouzivame stale Delphi 7, nic lepsie zatial v borland/inprise/borlan/embracadero nevymysleli.

[Jardík]

V tom jsem taky kdysi neco kutil, ale nikdy jsem nic nedokutil. Ted zkousim v lazarusu zbastlit kopii PE Exploreru (ten je tusim napsan v delphi) + podporu ELFu, ale jsem naprosto neschopny a pote, co jsem nastudoval strukturu PE souboru me to nejak prestalo bavit. Mozna by se dala zbastlit kopie TC. Jenze kdyby ty aplikace vypadali nativne. Na Windows vypadaji docela slusne (sem tam spatne vyrenderovany widgety), ale s GTK je to horsi. V nekterych tematech spatny barvicky, neumi to pruhledny ikony, blika to, widgety jsou vylozene spatny, to same jejich velikosti, ...

[kralyk z abclinuxu]

pote, co jsem nastudoval strukturu PE souboru me to nejak prestalo bavit.

+1

Polovička headeru je tam pro zpětnou kompatibilitu s počítačem ze starověkého řecka, druhá polovička "obsahuje" různé informace, které ale stejně žádný linker nevyplňuje, protože každýho akorát zajímá offset sekcí...

[pc2005]

V tom jsem taky kdysi neco kutil, ale nikdy jsem nic nedokutil. Ted zkousim v lazarusu zbastlit kopii PE Exploreru (ten je tusim napsan v delphi) + podporu ELFu, ale jsem naprosto neschopny a pote, co jsem nastudoval strukturu PE souboru me to nejak prestalo bavit.

To je tak složitý rozparsovat /etc/file/magic ?

[Filip Jirsák]

PE Explorer pravděpodobně nebude průzkumník adresářové struktury, ale PE, neboli Portable Executable, formátu spustitelných souborů.

[pc2005]

No vždyť jo, u mě je /etc/file/magic soubor obsahující popis hlavičky všech známých formátů programu file. Je sice fakt, že má jen základní informace o MZ a PE, ale jistě by šel použít jako počáteční impulz překonávající tu nechuť pro vytvoření toho exploreru. Vedlejší kladná vlastnost je řada dalších formátů co v file magic jsou.

[Filip Jirsák]

Ten popis je ale určen pro rozpoznání typu souboru a případně základních informací o něm, pochybuju, že by se z něj dal udělat rozumný prohlížeč složitějších formátů.

[pc2005]

Tak není to nic jinýho než offsety v souboru a jejich popis. Pro další informace by to chtělo doplnit to jo. Imho to ale bude lepší než to psát od začátku (a pak se na to vykašlat ).

[Jardík]

Tak ona ta dokumentace tak špatná nebyla (popis struktur na msdn.com a nějaký docx přímo od MS s podrobnějším popisem). Já se na to nevykašlal kvůli složitosti toho formátu, prostě mě to najednou nějak přestalo bavit, k čemu by to sloužilo. Sice jsem v trial verzi PE Exploreru sem tam kouknul v jeho (docela dobrém) disassembleru do nějakýho programu, spíž ze zvědavosti, ale abych s tím dělal něco důležitého (jako např. crackovat programy ), to ne.

[Jiří Němec]

Jako by Delphi bylo použitelné na Windows, ještě to chtejí cpat do jiných platforem. Měli jsme to na střední jako Delphi a na vysoké nám to ve formě C++ buildera nutil slavný "autor knih"(překladatel manuálů) David Matoušek. Je to jen trochu obalené windows api, jen naprosto šíleně zprzněné. C++ tam ztrácí svůj význam, protože si tam všechno řeší tak nějak po svém napůl pascalovsky. Ten nástroj je dobrý tak na rychlé vytvoření prototypu uživatelského rozhraní, ale pak musí nastoupit opravdoví programátoři a napsat to v něčem rozumném, moderním, v něčem používajícím návrhové vzory a umožňujícím opravdovou práci v týmech.

[Amarok]

Chápu správně, že kritizuješ Delphi (Object Pascal) na základě špatné zkušenosti s C++ builderem? Trochu zvláštní, ne?

[Jiří Němec]

On je to dnes jen jeden produkt. Delphi mě učili 2 roky, c++ builder 1 semestr a oboje to je stejný bordel, na jazyku vůbec nezáleží.

[zulu]

Velký kulový. Já s tím přicházím do styku už 15 let a nic jako bordel nepamatuji.

[rainman]

Nevím s jakou verzí Delphi máš zkušenosti, ale např. už zmíněná verze 7 (tuším 7.02) byla hodně propracovaná a stabilní. Dělal jsem ve firmě, která v tom vyvíjela billingové a informační systémy a kódilo se v tom rychle, dobře se to udržovalo a nikdy se nenarazilo na limity jazyka Delphi/Object Pascalu. Prodejní ceny za licence byly v řádech stovek tisíc až milionů Kč.

Samozřejmě trochu chyběly makra a šablony a z moderních jazyků pokročilejší datové struktury jako seznamy, slovníky a operace nad nimi, ale dalo se to řešit a nikoli na úkor pracnosti, horší udržovatelnosti nebo znovupoužitelnosti kódu.

[Bedňa]

Keď som ja začínal s programovaním, tak sa o dokumentácií hovorilo len v krúžkoch anarchistických skupín :) Internet neexistoval. Kedže som mal v pláne vytvoriť grafický program, otestoval som si rýchlosť C a Pascalu pri vykreslovaní, testy dopadli na stotinu rovnako. Keďže som mal vždy blísko k umeniu a Pascal mal ku mne bližšiu syntax, tak som začal kódiť v Pascale. Dotiahol som to na dosť slubný projekt like Corel, ktorý som nikdy ale nedokončil. Práca s krivkami je tam premakaná ako SignLabe. Coreláci môžu závidieť :) Pred časom som po rokoch riešil problém s kódom v Pascale a čudoval som sa čo sa mi na ňom vtedy tak páčilo :) Odhliadnuc od toho Lazurus je fakt pecka na jednoduché GUI aplikácie, občas do neho teraz nazerám keď radím na fórach.

[Jardík]

Dovolim si nalinkovat info o dostupnosti "uchazejici" dokumentace pro FPC/lazarus.

[________________]

Delphi som používal veľmi dlho do konca tisícročia nemal konkurenciu. Potom prišiel MS s platforomou .NET a jazykom C# a keď som zistil že C# je oproti delphi omnoho viac objektovejší a bohatší jazyk a má omnoho viac knižníc už v základe nemal som inú možnosť ako opustiť zastaralé Delphi a prejsť na .NET jediné v čom Delphi stále nemá konkurenciu sú komponenty. Delphi malo obrovskú komunitu hobby vývojárov a obrovské množstvo vizuálnych aj nevizuálnych komponent. Vývoj komponent v Delphi bola brnkačka a každý amatérsky vývojár vytvoril nejaké tie komponenty a vypustil ich (vačšinou) pod MPL (Mozilla Public License). Aj ja som si spravil pár kompoonent na prácu s grafikou vo vysokom rozlíšení alebo na pŕacu s true color ikonami atď.

[Martin.notoric]

Možná pitomý dotaz. Jaký je rozdíl mezi komponentou a knihovnou nebo třídou?

Co vim tak funkce v Pascalu nemohla mít jako návratový typ třeba soubor nebo datovou strukturu - ty se musely vracet přes výstupní parametery. Borland Pascal vylepšoval, nicméně obojí je hrozný. A ten borlandí je hrozný proto, že ten původní je hrozný.

[deda.jabko]

Co vim tak funkce v Pascalu nemohla mít jako návratový typ třeba soubor nebo datovou strukturu - ty se musely vracet přes výstupní parametery

dobra otazka. co vim, tak v delphi toto by nemel byt problem. navic pri spravnem navrhu, nebudes vracet z funkce soubor, ale hodnotu typu myslim TFile (coz je vlastne ukazatel na instanci objektu). i.e., hezka ukazka, ze davat rovnost mezi pascal 70-let a delphi je blbost.

[Šerpik]

Dokonce tu strukturu (třídu) lze dál použít. Má oblíbená "prasárna":

Root.Items.Add('item1').Items.Add('Item2').Items.Add('Item3');

ale hodnotu typu myslim TFile

Spíš TFileStream Ono se s tím pak líp pracuje v komponentách, co umí "jen" TStream. A to už je opravdu o něčem jiném než pascal ze 70.let.

[sivlk]

Trieda: type TJablko = class(TOvocie);
Knihovna: subor na disku ktory moze obsahovat kod a interface (verejne dostupna cast kodu)
Komponenta: potomok TComponent a je to najma vizualna zalezitost, proste to co si placnes do okna, napr. TButton->TButtonControl->TWinControl->TControl(to su komponenty co mozu mat fokus)->TComponent->TPersistent, IInterface, IInterfaceComponentReference. Aj ked mozu byt aj nevyzualne komponenty (ftp spojenie, casovac, open dialog, hlavne menu, popupmenu, ...)

[Jardík]

Jaký je rozdíl mezi komponentou a knihovnou nebo třídou?

Knihovna - knihovna kompomenent a tříd? Dynamická knihovna? Musíš se lépe vyjádřit.
Komponenta a třída se prakticky neliší. Komponenta je třída, akorát ji většinou vidíš na "paletě" komponent (ať už vizuální či nevizuální). Oboje můžeš vracet z funkce (respektive ve skutečnosti vracíš něco jako ukazatel na instanci třídy).
Soubor můžeš samozřejmě vrátit taky, záleží na tom, co k nim používáš. Např. TFileStream můžeš normálně vrátit, jako každou jinou třídu. Typy file of blabla či textfile jsem nikdy nepoužil, jsou špatně použitelné, a tedy netuším, jestli to jde vrátit z funkce, spíš ne.

[Aminux]

Ghaad: Teda ja uz jsem z toho jelen. Prece je nesmysl, ze by se v Jave dal napsat 3D engine (slovo "rychly" vynechejme, ted nejde o rychlost), aniz by byl pouzit jiny nez Java kod.

Tak to jsi asi nečetl toto: http://www.linuxexpres.cz/knihy/brackeen-barker-vanhelsuwe-vyvoj-her-v-jazyku-java

[Radek Hladik]

Teda koukám jak blázen, jaká se tu rozvinula diskuze na téma delphi a spol Dovolím si přidat svojí myšlenku. Delphi jsou především velmi pohodlný a rychlý vývojový nástroj. V době, kdy jsem s nimi začínal (tuším delphi 2 nebo 3), tak jsem chodil na přednášku programování pro windows na matfyzu (mimochodem na katedře numerické matematiky, nevím už proč). Po asi 5ti přednáškách by člověk dokázal sestrojit něco spustitelného s neprázdným oknem. Delphi jsem si pustil ve školní učebně místo jedné přednášky z programování a za hodinku jsem měl pěkný program na převod jednotek se skvělým GUI (na tehdejší poměry). A do dneška jsem neviděl tak přehledný a propracovaný systém na výrobu GUI. Je fakt, že v mnoha rysech zaspali u Borlandů dobu, ale i dnes v Delphi vyvíjíme a jsme naprosto spokojeni.

A co se týče Pascalu, tak ten mám poměrně rád, rozhodně mnohem více než hrozné C. Občas sice člověku chybí pokročilejší funkce, ale téměř vždy jde jen o delší zápis, který je ve finále přehlednější. Takže když pak na kód kouám, tak vidím, co dělá, a ne konstrukce typu vem pointer na pointer přetypuj na pointer na bžž, prvek kvák++ a přetypuj zpět na pointer na pointer, ten předej funkci xy, která očekává pointer, ale ve skrytu duše ví, že to je pointer na pointer na kvák A to vše namačkané na jednom řádku. http://www.fi.muni.cz/usr/jkucera/pb071/obfuscated.htm.

[ext3fs]

Nachepu co se vam na C nelibi. Preci neco jako:

int f,u=32,n[1024];s(v){if(u/=2)s(v),s(v|u),s
(v|u<<5);n[v]=u=u?u+u:1;};main(){for(f=~1,s(0
);f<1024;printf(n[++f]?f&31?"#":"\n#":" "));}

je krasa :)

Ne,ale ted vazne...programoval jsem v Pascalu(i Delphi) i v C a nazor mam uplne opacny. C syntaxe je jednoducha, elegantni kratka a prehledna...pokud clovek nepise jako prase. Ja teda kdyz vidim Pascal tak je mi spatne...mozna proto ze nam i na VS tlacili do hlavy "Kdo programuje v Pascalu tak mu patri obe ruce urezat... :)"

Btw, zkuste si ten kod prepsat do Pascalu...

[Amarok]

O tomhle radsi nediskutovat, na to ma kazdy jiny nazor. Ja zase preferuju pythonovsky zapis bez begin/end a ceckovych {}, a to teprve pote, co jsem si to na par prikladech vyzkousel. Do te doby jsem preferoval begin/end (protoze se {} snadno da prehlednout) a na Python jsem se dival trochu skepticky. Clovek by mel vse zkusit a predem nic nezavrhovat.

[Radek Hladik]

Krása je (naštěstí) subjektivní věc. Já bych z něčeho takovéhleho znovuviděl oběd

Ale bez urážky, pokud vám na VS tlacili do hlavy "Kdo programuje v Pascalu tak mu patri obe ruce urezat... :)" , tak to byla špatná škola. Programuju v Delphi, Javě, C, PHP, Perlu, Pythonu,... (z prvních třech jsem na VŠ dosáhl v patřičných předmětěch maximálního hodnocení) a vždy platí, že jazyk se volí podle požadavků a potřeby. Už jste někdy viděli webaplikaci v Delphi? Ne že by to nešlo, jednu jsem kdysi dokonce tvořil, ale přiznejme si, nebylo to zrovna ono. GUI aplikaci v PHP? Operační systém v Pythonu? Kvalita programátora se pozná podle toho jak programuje a ne v čem. Mimochodem u nás na VŠ jsme u důležitých zkoušek dostávali fragmenty kódu v C i v Pascalu. A pokud se mělo v rámci odpovědi napsat nějaký kód, bylo možno použit C, pascal nebo Javu.

Pro ilustraci bych dodal, že kdysi jsem se při jedné souteži v programování setkal se zajimavým řešením problému "napište třídící alhoritmus". Bylo to mladší žáky (tedy asi do 13 let) a očekávalo se něco jako:

for i := 0 to max do for j := i to max-1 do if pole[j]>pole[j+1] then prehod;

a jeden účastník vyrobil něco ve stylu:

for (i=0;i<max;i++) if (pole[i]>pole[i+1]) {prehod; i=-2; }

možná to není úplně přešné, ale to není podstatné. Oboje to funguje, ale na první, když se člověk podívá, tak vcelku rychle pochopí, co to dělá. U toho druhého, to už tak jednoduché není a rozhodně není ani jednoduché dokázat, že složitost je stejně n^2 jako v prvním případě. A dokonce i fakt, že se to vůbec zastaví není triviální... Na té soutěži jsme mu za originální řešení dali bod navíc, ale přiznejme si, v pracovním procesu bych radši viděl řešení prvním způsobem...

[kralyk z abclinuxu]

Asi tam mělo být i -= 2, předpokládám... (Nerejpu, jen poznámka )

Nicméně co se týče přehlednosti těch dvou řešení, tak je úplně jedno, jestli to je C nebo Pascal, protože v obojím se dá napsat jak první tak druhé řešení se zhruba stejnou přehledností...

[Radek Hladik]

Do detailu nechci moc zabíhat, už si to přesně nepamatuju. Jen vím, že to po tom poli jezdilo jak nevím co . Samozřejmě vtip je v přístupu odečteme dvě, protože cyklus nám za chvíli jedna přičte, takže se dostaneme o jeden doleva místo doprava...

A práveže není jedno, jestli Pascal nebo C. For x := 1 to 20 v Pascalu znamená projeď proměnou x od 1 do 20. To je naprsoto přehledné a jasné. Delphi vás už nenechají měnit řídící proměnou cyklu v cyklu, takže v Delphi už toto pomocí for nenapíšete. A to je právě ta pointa. V Pascalu budete muset použít while. A když na to někdo kouká, tak while je něco, co se opakuje, dokud platí podmínka, zatímco for je něco, co projede několik vstupních hodnot... Takže když v pascalu vidím něco for i := 0 to neco.count-1 do tak hned vím, co to dělá...

[kralyk z abclinuxu]

A práveže není jedno, jestli Pascal nebo C. For x := 1 to 20 v Pascalu znamená projeď proměnou x od 1 do 20. To je naprsoto přehledné a jasné. Delphi vás už nenechají měnit řídící proměnou cyklu v cyklu, takže v Delphi už toto pomocí for nenapíšete. A to je právě ta pointa.

To právě není ta pointa, protože v tom příkladě jsou v Pascalu dva for cykly vnořené do sebe. A na tom na první pohled není vidět o nic víc, než v tom Céčkovém zápisu.

Jinak samozřejmě je pravda, že for má v Pascalu trochu jinou definici, v céčku to je v podsatě stejné jako while. Nadruhou stranu, zkus si v Pascalu (v Delphi) napsat ekvivalent

   for (int i = 0; i < 20; i+=2) {}

anebo

   int i = 0, j = 20; for (;(i<20) && (j>0); i++,j--) {}

V obou případech budeš muset použít dost nepřehlednou konstrukci použitím while.
Čili ty omezující podmínky v Pascalu mohou sice někdy vynucovat přehlednost, jindy ji zase znemožňovat.
Každopádně stojím si za tím, že přehlednost kódu není dána výběrem jazyka.

[pc2005]

Každopádně stojím si za tím, že přehlednost kódu není dána výběrem jazyka.

I u whitespace?

[kralyk z abclinuxu]

Ok, dobře, jsou výjimky

[Trained.Monkey]

Pokud nepocitam hodne spatne pokusy na 8 bitech, tak moje zacatky byli na XT 6 MHz s Turbo Pascalem 6. Na tu dobu neuveritelne vymakane IDE. Delhi 1 my bezeli na 386 25Mhz se 4 MBram.