Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: uuuuuuuu 02. 07. 2018, 16:17:33
-
Nove programovaci jazyky vznikaji protoze starsi jazyky jsou zkostnatele, nebo aby slabsi programatori meli v cem programovat?
Kdyz si vezmu moderni c++ a javu a c# a rust, c++ se vyviji a postupem casu bude lehke jako java, c# vrati se pak lidi k c++17?
Na webu byl i nejaky clanek, ze rust je jen prechodne obdobi, nez se c++ dostane do verze 30 :-)
Pominme funkcionalni jazyky, pro vznikaji nove jazyky?
Kvuli chytrym lidem, aby jazyk mel neco co stary jazyk nema, nebo kvuli blbym lidem, aby zvladli prgat????
-
Chytrým lidem by stačil Language Intended for Smart People. ;)
-
Kdyz si vezmu moderni c++ a javu a c# a rust, c++ se vyviji a postupem casu bude lehke jako java, c# vrati se pak lidi k c++17?
Na webu byl i nejaky clanek, ze rust je jen prechodne obdobi, nez se c++ dostane do verze 30 :-)
To dost těžko. Největší síla i slabina C++ je zpětná kompatibilita. To dost omezuje další vylepšování. Na c++ je vidět, že by komise s chutí polovičku vyházela, jenže to zároveň není tak jednoduché. Takže se přidávají nové a nové věci, aby se aspoň daly používat místo toho starého bince.
Pokud se Rust ujme, tak spíš z nějakých specifických oblastí C++ vytěsní a to už se tam nevrátí. A o 10 let později se bude Rust dolepovat úplně stejně, jako dneska C++.
-
návrh a implementace jazyka je sranda, to může být další důvod :)
-
Chytrým lidem by stačil Language Intended for Smart People. ;)
Bohužel pro ty méně chytré to znamená spíš Lost In Stupid Parentheses.
-
To měl kdysi jeden profesor třídu studentů příliš líných, než aby se naučili FORTRAN, tak pro ně vymyslel BASIC. A historie se pořád opakuje...
-
Nemohu si pomoct, ale C++ mi stále připadá spíš jako makroassembler než jako pokročilý jazyk. Dnes je upřednostňována rychlost vývoje a robustnost před výkonem aplikace - C++ v tomto ohledu stále pokulhává. Pokud bych někdy použil C++, tak asi jen na vytvoření zmíněného Lispu, hlavně kvůli možnosti definice maker.
Pokud někdo programuje v C++, má k tomu jistě dobrý důvod, zejména kvůli výkonu. Jenže každý programátor nemá potřebu psát operační systémy.
-
To měl kdysi jeden profesor třídu studentů příliš líných, než aby se naučili FORTRAN, tak pro ně vymyslel BASIC. A historie se pořád opakuje...
Potíž je v tom, že kdekdo nadává na přebujelý jazyk a hledá něco jednoduchého a rychlého, co pokryje jeho doménu. Pak se toho chytí někdo jiný a snaží se z toho udělat univerzální jazyk. Tento vývoj pokračuje tak dlouho, než se jazyk stane nepoužitelným. Mezitím vznikne hromada knihoven a frameworků. Dokud žijí jejich fandové, tak se ještě udržují, ale postupně s nimi zanikají. A historie se opakuje.
-
Väčšinou sa riešia dookola stále tie isté veci, nejaké presýpania dát medzi dokladmi.
Kto by dnes platil vývoj v c++?
Musí by to byť hlavne rýchlo zlepené, ľudí je málo, zákaziek veľa....
-
Pokrok nezastavíš. Výše zmiňovaný LISP je sice akademicky krásný, ale nepříliš praktický. C++ má také k dokonalosti daleko, proto vznikají různé náhrady jako Rust, Go nebo i takové šílenosti jako node.js apod. Tvůrce chce většinou něco usnadnit, pak se to zvrtne a tak nějak samospádem zesložití.
-
Pokrok nezastavíš. Výše zmiňovaný LISP je sice akademicky krásný, ale nepříliš praktický.
Co je nepraktické na Lispu? Snad jen neochota se naučit používat jeho přirozené paradigma. Nepraktické jsou naopak ostatní jazyky, které se velkým obloukem k tomu Lispu neustále vrací.
-
Pokrok nezastavíš. Výše zmiňovaný LISP je sice akademicky krásný, ale nepříliš praktický. C++ má také k dokonalosti daleko, proto vznikají různé náhrady jako Rust, Go nebo i takové šílenosti jako node.js apod. Tvůrce chce většinou něco usnadnit, pak se to zvrtne a tak nějak samospádem zesložití.
Preto su dobre jazyky, ktore su uz od zaciatku robustnejsie. Blbsie sa sice zo zaciatku ucia a chapu, ale aspon to nedopadne ako C++, ktore ma milion rozsireni, skaredu syntax a na skompilovanie jednej veci je treba 10 nastrojov pricom koderi v tom tvoria nehorazne spagety.
-
Pokrok nezastavíš. Výše zmiňovaný LISP je sice akademicky krásný, ale nepříliš praktický. C++ má také k dokonalosti daleko, proto vznikají různé náhrady jako Rust, Go nebo i takové šílenosti jako node.js apod. Tvůrce chce většinou něco usnadnit, pak se to zvrtne a tak nějak samospádem zesložití.
Naopak, LISP je velice praktický, ale musí to být nějaká moderní forma, třeba Clojure.
-
Pokrok nezastavíš. Výše zmiňovaný LISP je sice akademicky krásný, ale nepříliš praktický. C++ má také k dokonalosti daleko, proto vznikají různé náhrady jako Rust, Go nebo i takové šílenosti jako node.js apod. Tvůrce chce většinou něco usnadnit, pak se to zvrtne a tak nějak samospádem zesložití.
Preto su dobre jazyky, ktore su uz od zaciatku robustnejsie. Blbsie sa sice zo zaciatku ucia a chapu,
Jo, Haskell, to už tu bylo.
-
Pokud se Rust ujme, tak spíš z nějakých specifických oblastí C++ vytěsní a to už se tam nevrátí. A o 10 let později se bude Rust dolepovat úplně stejně, jako dneska C++.
Rust je vlastními autory brán spíš jako článek evoluce než jako ultimátní řešení na věky věků. Pokud by se podařilo mít jazyk, ve kterém se budou psát aplikace v rozumných idiomech, bude převod do jiného jazyka se srovnatelnými výrazovými prostředky pouhou formalitou. Tam bych viděl směr vývoje - lepší typové systémy, beznákladové abstrakce, přesnější vyjádření problému s odsunutím low level detailů do nějaké tenké vrstvy. Není to jednoduché vyřešit, ale v rámci Rustu se na tom dost intenzivně pracuje.
-
Tak podle odpovedi jsem si v sobe utvrdil nazor, ze to je kvuli slabsim programatorum.
Jdu se ucit lisp.
-
Tak podle odpovedi jsem si v sobe utvrdil nazor, ze to je kvuli slabsim programatorum.
Jdu se ucit lisp.
Doporučuji ale začít se Scheme - učebnice "The Little Schemer" nebo klasika "Structure and Interpretation of Computer Programs". Pokud tě to zaujme a zvykneš si na to, tak pak teprve přejít na Common Lisp (učebnice Practical Common Lisp).
-
Tak podle odpovedi jsem si v sobe utvrdil nazor, ze to je kvuli slabsim programatorum.
Jdu se ucit lisp.
Odporucam haskell. V lispe sa nedaju elegantne oddelit side effecty od funkcionalneho kodu a je dynamicky typovany.
literatura:
http://learnyouahaskell.com/chapters
https://www.amazon.com/Programming-Haskell-Graham-Hutton/dp/0521692695 ( je to aj na uloz.to ale psst! :) )
-
můžete mi vysvětlit, v čem je Lisp o tolik lepší než moderní dynamické jazyky, na které tu každý nadává?
-
můžete mi vysvětlit, v čem je Lisp o tolik lepší než moderní dynamické jazyky, na které tu každý nadává?
Co mi na tech "modernich jazycich" chybi, jsou makra. Jinak si myslim, ze Lisp je dobry vesmes v tom, jak je "blby". Ze na nem napriklad nelze kritizovat syntaxi, protoze zadnou nema. To je jako se Smalltalkem. Pan Kay neumel udelat (z jeho pohledu) rozumny typovy system, tak napsal Smalltalk a absenci typove kontroly vyhlasil za prednost.
-
Neni to jen kvuli hlouposti, ale treba i kvuli tomu ze spousta jazyku vznikla v dobe jednoho jadra v cpu a pustit vypocet paralelne je proste sileny. Nove jazyky se s tim umi leckdy poprat velmi elegantne a nekdy i bez zasahu programatora.
-
můžete mi vysvětlit, v čem je Lisp o tolik lepší než moderní dynamické jazyky, na které tu každý nadává?
Prakticky v nicem, ale je provereny casem. Zkuste nasadit v praxi nejaky uplne novy jazyk. Co kdyz se prestane podporovat? Pak jste v loji a mate krasny software, ktery je odsouzen k zaniku. A nebo muzete mit stesti a trefite se.
-
Problém je ten, že vznikají nové programovací jazyky (syntaxe), namísto aby k těm stávajícím vznikaly prostě jen nové překladače, které by zvládly řešit totéž už s programovacím jazykem existujícím. Ani nevznikají jejich další run-time implementace.
Umím si představit např. low-level verzi Javy, kde místo bytekódu bude překládána přímo pro konkrétní CPU (to co nyní dělá JIT).
A nebo light-verze standartní knihovny, atd..
Vymýšlet nové programovací jazyky k tomu vůbec není potřeba.
-
Problém je ten, že vznikají nové programovací jazyky (syntaxe), namísto aby k těm stávajícím vznikaly prostě jen nové překladače, které by zvládly řešit totéž už s programovacím jazykem existujícím. Ani nevznikají jejich další run-time implementace.
Umím si představit např. low-level verzi Javy, kde místo bytekódu bude překládána přímo pro konkrétní CPU (to co nyní dělá JIT).
A nebo light-verze standartní knihovny, atd..
Vymýšlet nové programovací jazyky k tomu vůbec není potřeba.
Ta low-level verzia javy sa vola C :) Neviem, ako teraz, ale kedysi sme sa ucili najprv C-cko a potom JAVU.
Ako si matne spominam, kedysi bolo GCJ, aj sme s tym robili pokusy u jednej aplikacie, ktoru sme z JAVY potrebovali dostat do nativneho kodu (cielova platforma nemala JRE), ale moc slavne to nebolo. Skoncilo to tak, ze sme to prepisali rucne do cisteho C-cka.
-
Problém je ten, že vznikají nové programovací jazyky (syntaxe), namísto aby k těm stávajícím vznikaly prostě jen nové překladače, které by zvládly řešit totéž už s programovacím jazykem existujícím. Ani nevznikají jejich další run-time implementace.
Umím si představit např. low-level verzi Javy, kde místo bytekódu bude překládána přímo pro konkrétní CPU (to co nyní dělá JIT).
A nebo light-verze standartní knihovny, atd..
Vymýšlet nové programovací jazyky k tomu vůbec není potřeba.
"Nove" programovaci jazyky ale resi to, co ty "stare" z principu neumeji. Treba rozumnou praci s "prazdnou hodnotou" (optional type) nebo osetreni chyb Either/Result. Nebo zminena makra, line vyhodnocovani. Nebo treba citelnejsi zapis cisel (1000000 vs 1_000_000). Prinaseji rozumnejsi zaruky, ze kod dela, co delat ma a nedela, co delat nema. Proste ty "stare" programovaci jazyky umeji vsechno (protoze Turing), ale programy jsou typicky nachylnejsi k chybam, nez je nutne. Je kratkozrake tvrdit, ze neni treba delat nove jazyky.
Co resis Ty, je samozrejme taky dulezite, ale to se da resit zvlast (a resi, viz gcj napriklad).
-
Ako si matne spominam, kedysi bolo GCJ, aj sme s tym robili pokusy u jednej aplikacie, ktoru sme z JAVY potrebovali dostat do nativneho kodu (cielova platforma nemala JRE), ale moc slavne to nebolo. Skoncilo to tak, ze sme to prepisali rucne do cisteho C-cka.
Ano, na GCJ si vzpomínám, právě něco takového mám namysli. Stejně tak by C-čko mohlo být přeloženo do bytekódu, třeba pro JVM...
-
můžete mi vysvětlit, v čem je Lisp o tolik lepší než moderní dynamické jazyky, na které tu každý nadává?
Co mi na tech "modernich jazycich" chybi, jsou makra. Jinak si myslim, ze Lisp je dobry vesmes v tom, jak je "blby". Ze na nem napriklad nelze kritizovat syntaxi, protoze zadnou nema. To je jako se Smalltalkem. Pan Kay neumel udelat (z jeho pohledu) rozumny typovy system, tak napsal Smalltalk a absenci typove kontroly vyhlasil za prednost.
Pluginy pro babel v javascriptu umožňují to stejné co makra.
-
můžete mi vysvětlit, v čem je Lisp o tolik lepší než moderní dynamické jazyky, na které tu každý nadává?
Co mi na tech "modernich jazycich" chybi, jsou makra. Jinak si myslim, ze Lisp je dobry vesmes v tom, jak je "blby". Ze na nem napriklad nelze kritizovat syntaxi, protoze zadnou nema. To je jako se Smalltalkem. Pan Kay neumel udelat (z jeho pohledu) rozumny typovy system, tak napsal Smalltalk a absenci typove kontroly vyhlasil za prednost.
Pluginy pro babel v javascriptu jsou něco jako makra.
A s externim makroprocesorem muzu mit makra v cemkoli. To ale neni to, co mam na mysli. A sokuje me, ze modernim dynamickym jazykem jsi myslel konkretne JavaScript.
-
můžete mi vysvětlit, v čem je Lisp o tolik lepší než moderní dynamické jazyky, na které tu každý nadává?
Asi v tom, že si z něho autoři těch "moderních" jazyků neustále něco vypůjčují - tak proč se nenaučit rovnou samotný Lisp, místo čekání, až v něm zase autoři těch moderních jazyků něco objeví a vítězoslavně implementují do toho svého výtvoru jako nějakou super new hyper cool feature.
A že je narozdíl od Haskellu dynamický a na side-effecty se jen upozorňuje jmennou konvencí? Tazatel se ptal na jazyk pro chytré lidi, ne pro ty, co potřebují, aby je překladač vodil za ručičku. Navíc Haskell je funkcionální, zatímco Lisp je multiparadigmatický - můžeš iterovat přes rekurzi, ale taky přes imperativní loop. Můžeš programovat funkcionálně, ale klidně i objektově nebo obojí najednou, chceš-li.
Pluginy pro babel v javascriptu jsou něco jako makra.
Viz výše - proč používat "něco jako makra", když můžu použít nefalšovaná lispovská makra? A srovnávat JavaScript s Lispem, to je hodně silné kafe. :D
A s externim makroprocesorem muzu mit makra v cemkoli.
Ale ne taková, jako má Lisp. To se externím makroprocesorem fakt udělat nedá.
-
A s externim makroprocesorem muzu mit makra v cemkoli. To ale neni to, co mam na mysli. A sokuje me, ze modernim dynamickym jazykem jsi myslel konkretne JavaScript.
Samotný makroprocesor neposkytuje prostředky pro manipulaci s AST, kterou většina moderních jazyků umožňuje, ale nebývá dobrý nápad to používat. Jestli chcete moderní jazyk s first class makry, tak Elixir.
-
Zlati komuniste. Byt tady socik, tak tyhle srackoidni jayzky ku nam nedorazi. Prohnity Zapad. Programovaci jazyky stoji zahovno, take zradlo, ktere sem vozi. Jdu blejt
-
můžete mi vysvětlit, v čem je Lisp o tolik lepší než moderní dynamické jazyky, na které tu každý nadává?
Asi v tom, že si z něho autoři těch "moderních" jazyků neustále něco vypůjčují - tak proč se nenaučit rovnou samotný Lisp, místo čekání, až v něm zase autoři těch moderních jazyků něco objeví a vítězoslavně implementují do toho svého výtvoru jako nějakou super new hyper cool feature.
A že je narozdíl od Haskellu dynamický a na side-effecty se jen upozorňuje jmennou konvencí? Tazatel se ptal na jazyk pro chytré lidi, ne pro ty, co potřebují, aby je překladač vodil za ručičku. Navíc Haskell je funkcionální, zatímco Lisp je multiparadigmatický - můžeš iterovat přes rekurzi, ale taky přes imperativní loop. Můžeš programovat funkcionálně, ale klidně i objektově nebo obojí najednou, chceš-li.
Chytry clovek neznamena neomylny clovek. Jazyk, ktery dava prilis mnoho volnosti, nepovazuju za moc dobry nastroj pro projektu, na kterych spolupracuje vice lidi.
A s externim makroprocesorem muzu mit makra v cemkoli.
Ale ne taková, jako má Lisp. To se externím makroprocesorem fakt udělat nedá.
Tady my dva nejsme ve pri. "Interni makroprocesor" je ponekud jine kafe nez externi. A ty externi povazuju za prinejlepsim vychodisko z nouze.
-
A s externim makroprocesorem muzu mit makra v cemkoli. To ale neni to, co mam na mysli. A sokuje me, ze modernim dynamickym jazykem jsi myslel konkretne JavaScript.
Samotný makroprocesor neposkytuje prostředky pro manipulaci s AST, kterou většina moderních jazyků umožňuje, ale nebývá dobrý nápad to používat. Jestli chcete moderní jazyk s first class makry, tak Elixir.
Z jazyku s makry davam prednost Rustu. Ale diky za tip.
-
Pluginy pro babel v javascriptu jsou něco jako makra.
Viz výše - proč používat "něco jako makra", když můžu použít nefalšovaná lispovská makra? A srovnávat JavaScript s Lispem, to je hodně silné kafe. :D
A s externim makroprocesorem muzu mit makra v cemkoli.
Ale ne taková, jako má Lisp. To se externím makroprocesorem fakt udělat nedá.
udělat se dá cokoliv, jen v některých případech s větší námahou. To nevadí, protože i v Lispu je bad practice používat makra na každou blbost. Pro jednoduchá makra neprovádějící AST transformace existuje přímo plugin https://github.com/codemix/babel-plugin-macros , pro složitější lze použít sweet.js .
-
Stejně tak by C-čko mohlo být přeloženo do bytekódu, třeba pro JVM...
webassembly
-
Neni to jen kvuli hlouposti, ale treba i kvuli tomu ze spousta jazyku vznikla v dobe jednoho jadra v cpu a pustit vypocet paralelne je proste sileny. Nove jazyky se s tim umi leckdy poprat velmi elegantne a nekdy i bez zasahu programatora.
Lispu je jedno, kolik máš procesorů a na kolika vláknech. Dokonce mu nevadí, když program modifikuješ za chodu. V moderních jazycích musíš řešit explicitně to, co Lisp umí nativně.
-
Neni to jen kvuli hlouposti, ale treba i kvuli tomu ze spousta jazyku vznikla v dobe jednoho jadra v cpu a pustit vypocet paralelne je proste sileny. Nove jazyky se s tim umi leckdy poprat velmi elegantne a nekdy i bez zasahu programatora.
Lispu je jedno, kolik máš procesorů a na kolika vláknech. Dokonce mu nevadí, když program modifikuješ za chodu. V moderních jazycích musíš řešit explicitně to, co Lisp umí nativně.
o kterém Lispu mluvíš?
-
Neni to jen kvuli hlouposti, ale treba i kvuli tomu ze spousta jazyku vznikla v dobe jednoho jadra v cpu a pustit vypocet paralelne je proste sileny. Nove jazyky se s tim umi leckdy poprat velmi elegantne a nekdy i bez zasahu programatora.
Lispu je jedno, kolik máš procesorů a na kolika vláknech. Dokonce mu nevadí, když program modifikuješ za chodu. V moderních jazycích musíš řešit explicitně to, co Lisp umí nativně.
C je to taky jedno, ne?
-
Lispu je jedno, kolik máš procesorů a na kolika vláknech. Dokonce mu nevadí, když program modifikuješ za chodu. V moderních jazycích musíš řešit explicitně to, co Lisp umí nativně.
C je to taky jedno, ne?
V C nebo v Javě to musíš řešit jako vícevláknovou aplikaci. Bez toho to pojede jen v jednom vláknu.
-
V C nebo v Javě to musíš řešit jako vícevláknovou aplikaci. Bez toho to pojede jen v jednom vláknu.
a v Lispu to řešíš jak? uveď příklad
-
V C nebo v Javě to musíš řešit jako vícevláknovou aplikaci. Bez toho to pojede jen v jednom vláknu.
a v Lispu to řešíš jak? uveď příklad
Nijak. Pokud to použitý engine umí, tak se použije automaticky.
-
V C nebo v Javě to musíš řešit jako vícevláknovou aplikaci. Bez toho to pojede jen v jednom vláknu.
a v Lispu to řešíš jak? uveď příklad
Nijak. Pokud to použitý engine umí, tak se použije automaticky.
Sorry, ale to je bullsh*t. Automaticka paralelizace obecneho algoritmu nemuze nijak rozumne fungovat a pokud jedes na nejakem engine, ktery umi vyuzivat vice vypoctovych vlaken v nejakem specialnim kontextu, neni to zadna zasluha jazyka.
-
Nijak. Pokud to použitý engine umí, tak se použije automaticky.
který engine to umí?
-
Nijak. Pokud to použitý engine umí, tak se použije automaticky.
který engine to umí?
Co to je vůbec myšleno tím "engine" v kontextu téhle diskuze?
-
Nijak. Pokud to použitý engine umí, tak se použije automaticky.
který engine to umí?
Co to je vůbec myšleno tím "engine" v kontextu téhle diskuze?
předpokládám, že implementace
-
Nijak. Pokud to použitý engine umí, tak se použije automaticky.
který engine to umí?
Co to je vůbec myšleno tím "engine" v kontextu téhle diskuze?
předpokládám, že implementace
Vyhral jsi soutez o nejdebilnejsi komentar :)
V lispu jsem programoval pouze na skole semestralku (pred 20 lety). Mejme notoricky znamy faktorial, je jedno zda rekurzivni nebo iteracni verzi. Ten engine (lisp interpreter) by teda musel vedet, jak tu funkci paralelizovat. Umi to dneska? Nebo jsou na to nejake knihovny?
-
Nijak. Pokud to použitý engine umí, tak se použije automaticky.
který engine to umí?
Co to je vůbec myšleno tím "engine" v kontextu téhle diskuze?
předpokládám, že implementace
Vyhral jsi soutez o nejdebilnejsi komentar :)
V lispu jsem programoval pouze na skole semestralku (pred 20 lety). Mejme notoricky znamy faktorial, je jedno zda rekurzivni nebo iteracni verzi. Ten engine (lisp interpreter) by teda musel vedet, jak tu funkci paralelizovat. Umi to dneska? Nebo jsou na to nejake knihovny?
Zrovna faktorial lze parlelizovat snadno, to je obyčejný reduce. Já netvrdím, že něco takového obecně lze. To tvrdil Kit.
-
Problém je ten, že vznikají nové programovací jazyky (syntaxe), namísto aby k těm stávajícím vznikaly prostě jen nové překladače, které by zvládly řešit totéž už s programovacím jazykem existujícím. Ani nevznikají jejich další run-time implementace.
Umím si představit např. low-level verzi Javy, kde místo bytekódu bude překládána přímo pro konkrétní CPU (to co nyní dělá JIT).
A nebo light-verze standartní knihovny, atd..
Vymýšlet nové programovací jazyky k tomu vůbec není potřeba.
Python těch překladačů a interpretů má docela dost.
-
Jazyky samozřejmě vznikají pro potřeby hloupých a líných programátorů. Kdyby byli chytří a pracovití, mohou psát přímo strojový kód.
-
...To je jako se Smalltalkem. Pan Kay neumel udelat (z jeho pohledu) rozumny typovy system, tak napsal Smalltalk a absenci typove kontroly vyhlasil za prednost.
...koneckonců názor může mít každý, i kdyby byl jakýkoliv.
Pak Kay (a jeho skupina) chtěl především co nejtriviálnější jazyk s co největšími schopnostmi, o několik desetiletí dříve než čtenáři Rootu přišel na to, že s typovým systémem to asi nepůjde.
-
...To je jako se Smalltalkem. Pan Kay neumel udelat (z jeho pohledu) rozumny typovy system, tak napsal Smalltalk a absenci typove kontroly vyhlasil za prednost.
Jaká škoda, že tenkrát nebyl Root. Mohl se zeptat zdejších brouků pytlíků, jak na "rozumný typový systém".
Some people are completely religious about type systems and as a mathematician I love the idea of type systems, but nobody has ever come up with one that has enough scope. -- A. Kay
-
...To je jako se Smalltalkem. Pan Kay neumel udelat (z jeho pohledu) rozumny typovy system, tak napsal Smalltalk a absenci typove kontroly vyhlasil za prednost.
Jaká škoda, že tenkrát nebyl Root. Mohl se zeptat zdejších brouků pytlíků, jak na "rozumný typový systém".
Some people are completely religious about type systems and as a mathematician I love the idea of type systems, but nobody has ever come up with one that has enough scope. -- A. Kay
To by bolo uplne zbytocne, lebo okrem Root-a by musel vtedy byt aj Haskell.
-
...To je jako se Smalltalkem. Pan Kay neumel udelat (z jeho pohledu) rozumny typovy system, tak napsal Smalltalk a absenci typove kontroly vyhlasil za prednost.
...koneckonců názor může mít každý, i kdyby byl jakýkoliv.
Pak Kay (a jeho skupina) chtěl především co nejtriviálnější jazyk s co největšími schopnostmi, o několik desetiletí dříve než čtenáři Rootu přišel na to, že s typovým systémem to asi nepůjde.
No a v cem se mnou nesouhlasis? Ja jsem nemel v umyslu pana Kaye kritizovat - jeho reseni bylo funkcni a asi dosahl toho, ceho chtel. Nechci tady delat flame na tema OOP vs FP, ale vlastne jsem rad, ze nekdo zareagoval, byt jsem Smalltalk zminil spis mimochodem.
Cele tohle tema se vsak toci kolem Lispu, delejme flame o nem. Zatim jsem se dozvedel, ze Lisp je pro chytre lidi, od jeho stvoreni nikdo zadny dalsi potrebny vyssi jazyk nevymyslel a dokonce Lisp umi sam paralelizovat program, ale zatim jeste Kit nenapsal jak.
-
Jaká škoda, že tenkrát nebyl Root. Mohl se zeptat zdejších brouků pytlíků, jak na "rozumný typový systém".
Some people are completely religious about type systems and as a mathematician I love the idea of type systems, but nobody has ever come up with one that has enough scope. -- A. Kay
To by bolo uplne zbytocne, lebo okrem Root-a by musel vtedy byt aj Haskell.
Haskell nebyl, ale uz 7 let existovalo ML. Ale jak pisu vyse, pojdme resit Lisp. ;-)
-
...To je jako se Smalltalkem. Pan Kay neumel udelat (z jeho pohledu) rozumny typovy system, tak napsal Smalltalk a absenci typove kontroly vyhlasil za prednost.
Jaká škoda, že tenkrát nebyl Root. Mohl se zeptat zdejších brouků pytlíků, jak na "rozumný typový systém".
Some people are completely religious about type systems and as a mathematician I love the idea of type systems, but nobody has ever come up with one that has enough scope. -- A. Kay
To by bolo uplne zbytocne, lebo okrem Root-a by musel vtedy byt aj Haskell.
V době vzniku toho citátu už Haskell dávno byl. Haskell? Ale jo, hezký jazyk - do doby, než mě v něm někdo bude nutit programovat.
-
V době vzniku toho citátu už Haskell dávno byl.
můžete postnout nějaký text kde se vyjadřuje konkrétně k haskellu nebo podobnému jazyku? mi se to zatím najít nepovedlo
-
Dobre by bylo zacit treba timto nez skakanim z jazyka na jazyk..... http://suckless.org/philosophy/
-
Dobre by bylo zacit treba timto nez skakanim z jazyka na jazyk..... http://suckless.org/philosophy/
suckless jsou hobbysté, mohou si dovolit pracovat neefektivně.
-
V C nebo v Javě to musíš řešit jako vícevláknovou aplikaci. Bez toho to pojede jen v jednom vláknu.
a v Lispu to řešíš jak? uveď příklad
Nijak. Pokud to použitý engine umí, tak se použije automaticky.
Automaticka paralelizace obecneho algoritmu nemuze nijak rozumne fungovat a pokud jedes na nejakem engine, ktery umi vyuzivat vice vypoctovych vlaken v nejakem specialnim kontextu, neni to zadna zasluha jazyka.
Lisp je navržen tak, aby mohl běžet paralelně. Každý node aplikace může být obsluhován jiným vláknem. Podmínkou pro správný běh paralelních aplikací je pouze používání immutable nodů.
-
Automaticka paralelizace obecneho algoritmu nemuze nijak rozumne fungovat a pokud jedes na nejakem engine, ktery umi vyuzivat vice vypoctovych vlaken v nejakem specialnim kontextu, neni to zadna zasluha jazyka.
Lisp je navržen tak, aby mohl běžet paralelně. Každý node aplikace může být obsluhován jiným vláknem. Podmínkou pro správný běh paralelních aplikací je pouze používání immutable nodů.
A už jsme u toho. Aby se dalo něco paralelizovat, musí to být "pouze" správně napsané a pak už to jde skoro samo. No a protože Lisp je "pro chytré lidi" a umožňuje imperativně prasit až do omdlení, nedá se v něm samozřejmě zaručit vůbec nic, rozhodně se to zaručuje složitěji než u jazyků "pro blbce", jakým je třeba Haskell. Jenže je tady ještě jeden problém a to ten, že paralelizování může výpočet slušně zpomalit kvůli režii spojené například s přenosem dat nebo nevhodnou strukturou. Takže se dostáváš úplně do stejné situace jako programátoři v ostatních jazycích, totiž musíš si to ošéfovat sám, protože jinak se se zlou potážeš. Ale klidně můžeš dát (už konečně) konkrétní příklad, jak to v Lispu jde úplně samo, jak si ten "engine" sám inteligentně poradí. Klidně se nechám vyvést z omylu.
-
Automaticka paralelizace obecneho algoritmu nemuze nijak rozumne fungovat a pokud jedes na nejakem engine, ktery umi vyuzivat vice vypoctovych vlaken v nejakem specialnim kontextu, neni to zadna zasluha jazyka.
Lisp je navržen tak, aby mohl běžet paralelně. Každý node aplikace může být obsluhován jiným vláknem. Podmínkou pro správný běh paralelních aplikací je pouze používání immutable nodů.
... Lisp ... umožňuje imperativně prasit až do omdlení ...
haskell taky - a jak ;)
-
... Lisp ... umožňuje imperativně prasit až do omdlení ...
haskell taky - a jak ;)
Jenže ve světě Haskellu se tím nikdo nechlubí.