Ideálny programovací jazyk

[Radovan .]

... fortran, matlab ...

Prosím ne. ...

Už jsem to tu kdysi zmiňoval. Kamarád něco řešil v Matlabu - a trvalo to dlouho. Příliš dlouho. Tak to přepsal do Fortranu a bylo to rychlejší. Neřekl mi sice kolikrát, ale prý to číslo mělo pět nul
Je tedy poněkud mladší a změkčilejší, takže to byl F90, já bych dal přednost FORTRANu IV.

[Reklama]

[Kit]

Prosím ne. K Fortanu se nehodlám moc vyjadřovat, jen uvedu, že většina fortranového kódu, co jsem kdy viděl, byla neuvěřitelně zprasená, čímž jsem si k němu asi vytvořil doživotní odpor. Takže na „tvrdou“ numeriku používám C.

Tvrdou numeriku má C neuvěřitelně zprasenou, takže raději ten Fortran. Ovšem v dnešní době jdeme do vyšších jazyků a v nich povede Python.

[Juras N]

Ideální jazyk? Bude to sice znít masochisticky, nicméně za mě
- Vyjít konceptem a syntaxí z Pythonu
- Odstranit GIL
- Přidat silnou typovost ala cpp
- Odstranit garbage collector, přidat ruční správu paměti a destruktory
- Udělat jako kompilovaný jazyk, jehož výsledkem bude klasická binárka běžící rovnou na železe

[Ladislav Zitka]

Ideal je co neco zpusob pomocnika, kteryho ma k dispozici Iron Man. Zadani se rovnou materializuje a nevyzaduje vysedavani u kompu at all! Vystup je nejen informacni, ale i materialni (pokud je potreba)

Infrastruktura skladajici se z pocitace, obrazovky a klavesnice, jazyku je vlastne uplne strasne komunikacni rozhrani, ve kterem si muzeme skladat modely myslenek pro hledani odpovedi(ani ne tak reseni :-)) ), at uz je tim pocet emitovanych castic, nebo delani loginu do systemu, nebo pocitani auticek na fotce, cokoli. Potrebujeme vytvorit ne jazyk, ale pomocnika, nejlepe pomocniky, kteri si vytvori vlastni jazyk, ale budou rozumnet nasemu jazyku, nejlepe jeste telepaticky, ale tak to muze umet verze 2-ALFA. A nase myslenkove uvahy se muzou posunout na jinam... :-))

Takze me zajima jaky jazyk by byl nejlepsi pro navrh takoveho pomocnika.

Jinak ten clanek o Jave od Software Samuraje je nadherny :-)

za me dnes vede Go a python (primocarost), A v GCC vystrcila ruzek podpora D (o nem jen sem tam ctu, ale nenapsal jsem v nem jeste ani return :-)

[Ladislav Zitka]

- Odstranit garbage collector, přidat ruční správu paměti a destruktory

Brrr, zadna rucni sprava... its just burden, ja taky neresim, co si mam pamatovat a co zapomenout, zapomene se to samo.

[Reklama]

[Juras N]

Brrr, zadna rucni sprava... its just burden, ja taky neresim, co si mam pamatovat a co zapomenout, zapomene se to samo.

Do té doby, než jsem objevil Qt framework a jeho metodu všechny data řadíme do stromu a když jeden node stromu smažeme, tak se sám uklidí binec pod tím, jsem si to taktéž myslel, nicméně při šikovném návrhu jednotlivých tříd ten garbage collector prostě není potřeba

[Cikáda]

Ideální jazyk? Bude to sice znít masochisticky, nicméně za mě
- Vyjít konceptem a syntaxí z Pythonu

Jo, tohle zní hodně masochisticky.

- Přidat silnou typovost ala cpp

C++ nemá silnou typovost.

- Udělat jako kompilovaný jazyk, jehož výsledkem bude klasická binárka běžící rovnou na železe

Líbí se mi Haskell, respektive interaktivní ghci a to, jak je to udělané.

[cvak01]

Ideální jazyk? Bude to sice znít masochisticky, nicméně za mě
- Vyjít konceptem a syntaxí z Pythonu
- Odstranit GIL
- Přidat silnou typovost ala cpp
- Odstranit garbage collector, přidat ruční správu paměti a destruktory
- Udělat jako kompilovaný jazyk, jehož výsledkem bude klasická binárka běžící rovnou na železe

mohl by se ti líbit Nim https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

[Zabanovaný Anonymní Troll]

Ideal je co neco zpusob pomocnika, kteryho ma k dispozici Iron Man. Zadani se rovnou materializuje a nevyzaduje vysedavani u kompu at all! Vystup je nejen informacni, ale i materialni (pokud je potreba)

Infrastruktura skladajici se z pocitace, obrazovky a klavesnice, jazyku je vlastne uplne strasne komunikacni rozhrani, ve kterem si muzeme skladat modely myslenek pro hledani odpovedi(ani ne tak reseni :-)) ), at uz je tim pocet emitovanych castic, nebo delani loginu do systemu, nebo pocitani auticek na fotce, cokoli. Potrebujeme vytvorit ne jazyk, ale pomocnika, nejlepe pomocniky, kteri si vytvori vlastni jazyk, ale budou rozumnet nasemu jazyku, nejlepe jeste telepaticky, ale tak to muze umet verze 2-ALFA. A nase myslenkove uvahy se muzou posunout na jinam... :-))

Takze me zajima jaky jazyk by byl nejlepsi pro navrh takoveho pomocnika.

Jinak ten clanek o Jave od Software Samuraje je nadherny :-)

za me dnes vede Go a python (primocarost), A v GCC vystrcila ruzek podpora D (o nem jen sem tam ctu, ale nenapsal jsem v nem jeste ani return :-)

Takovy pomocnik uz existuje, vymysleli ho uz davno v Micosoftu, jmenuje se Sponka.

[qelurg]

Ideální jazyk? Bude to sice znít masochisticky, nicméně za mě
- Vyjít konceptem a syntaxí z Pythonu
- Odstranit GIL
- Přidat silnou typovost ala cpp
- Odstranit garbage collector, přidat ruční správu paměti a destruktory
- Udělat jako kompilovaný jazyk, jehož výsledkem bude klasická binárka běžící rovnou na železe

Python 3 je dobrý základ.
Odstranit GIL by se hodilo.
Silné typy už python má. Statické anotace už také podporuje.
Ruční správu paměti - ee.
Kompilovat Python v podstatě už jde, viz Cython.

[Kit]

- Odstranit garbage collector, přidat ruční správu paměti a destruktory

Pokud jsem si všiml, tak destruktory fungují korektně jen v PHP. Spouští se ihned po uvolnění objektu. V ostatních jazycích je to slepeno dohromady s GC - destruktory neplní řádně svou funkci a proto je s nimi tolik potíží.

[Juras N]

Pokud jsem si všiml, tak destruktory fungují korektně jen v PHP. Spouští se ihned po uvolnění objektu. V ostatních jazycích je to slepeno dohromady s GC - destruktory neplní řádně svou funkci a proto je s nimi tolik potíží.

No nevím, ale v cpp jsem divné chování destruktorů nikdy nezaznamenal, zatím se mi vždy spustil bezprostředně po zavolání delete nebo když daný objekt má zmizet ze stacku. Pravdou je, že u jazyků používajících garbage collector tomu může být jinak, nicméně to bude asi jeden z důvodů, proč v Pythonu destruktory nejsou (měl by se spustit s během GC, což je nedefinovaný okamžik).

[Kit]

Pokud jsem si všiml, tak destruktory fungují korektně jen v PHP. Spouští se ihned po uvolnění objektu. V ostatních jazycích je to slepeno dohromady s GC - destruktory neplní řádně svou funkci a proto je s nimi tolik potíží.

No nevím, ale v cpp jsem divné chování destruktorů nikdy nezaznamenal, zatím se mi vždy spustil bezprostředně po zavolání delete nebo když daný objekt má zmizet ze stacku. Pravdou je, že u jazyků používajících garbage collector tomu může být jinak, nicméně to bude asi jeden z důvodů, proč v Pythonu destruktory nejsou (měl by se spustit s během GC, což je nedefinovaný okamžik).

Ruční volání destruktorů nebo třeba zavírání souborů by mě už nebavilo. Proč bych to měl hlídat?

[nula]

Pokud jsem si všiml, tak destruktory fungují korektně jen v PHP. Spouští se ihned po uvolnění objektu. V ostatních jazycích je to slepeno dohromady s GC - destruktory neplní řádně svou funkci a proto je s nimi tolik potíží.

No nevím, ale v cpp jsem divné chování destruktorů nikdy nezaznamenal, zatím se mi vždy spustil bezprostředně po zavolání delete nebo když daný objekt má zmizet ze stacku. Pravdou je, že u jazyků používajících garbage collector tomu může být jinak, nicméně to bude asi jeden z důvodů, proč v Pythonu destruktory nejsou (měl by se spustit s během GC, což je nedefinovaný okamžik).

Ruční volání destruktorů nebo třeba zavírání souborů by mě už nebavilo. Proč bych to měl hlídat?

V cpp zadne rucni volani destruktoru neni potreba. Akorat lze presne zjistit kouknutim do kodu, kdy se tak stane.

[Kit]

Ruční volání destruktorů nebo třeba zavírání souborů by mě už nebavilo. Proč bych to měl hlídat?

V cpp zadne rucni volani destruktoru neni potreba. Akorat lze presne zjistit kouknutim do kodu, kdy se tak stane.

Takže se zánikem posledního deskriptoru na objekt se automaticky zavolá jeho destruktor? Java se má co učit, neboť tohle neumí.