Portál AbcLinuxu, 13. května 2024 17:57
15.7.2007 12:45
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Myslím, že takovéto projekty vždycky mají smysl, protože se při nich může přijít na ledacost nového a užitečného, třeba i úplně mimochodem.
Pomohl bych, jenže už mám rozpracovaný jiný megalomanský projekt
. Imho se má učit v něčem prakticky použitelném a ne v jazyce, který byl od samého začátku navržen pro výuku a ne pro normální programování 
. Škola pro život a ne škola pro školu!
Jinak "není to OOP kráva" považuji za druhou největší nevýhodu, hned po divné syntaxi -- s Pascalem jsem naštěstí moc času netrávil, ale ještě teď se občas zapomenu a do ifu dám jen jedno rovnítko. Grrr.
Imho se má učit v něčem prakticky použitelném a ne v jazyce, který byl od samého začátku navržen pro výuku a ne pro normální programování
Právě, že ne! Kdosi to hezky zdůvodnil, ale teď se mi to nechce hledat.
Jinak "není to OOP kráva" považuji za druhou největší nevýhodu, hned po divné syntaxi -- s Pascalem jsem naštěstí moc času netrávil, ale ještě teď se občas zapomenu a do ifu dám jen jedno rovnítko. Grrr.
Část syntaxe mi taky vadí (proto to píšu). Vysvětli vyjukanému začátečníkovi "Hello, World!" v Javě! Dobře nedopadneš.
A ty to zdůvodnit neumíš? ;)Právě, že ne! Kdosi to hezky zdůvodnil, ale teď se mi to nechce hledat.
. Podstatné vidím to, aby ten jazyk naučil člověka dobře základy.
A rikejte si co chcete
...ale hned C
U Céčka se dá lépe prasit.
15.7.2007 12:58
// Generating mines
for(counter = 0; counter < mines_count; counter++)
{
// Be aware not to replace one mine by another
do
{
x = rand() % MAXX;
y = rand() % MAXY;
} while(pole[x][y] == -1);
pole[x][y] = -1;
}
(http://distfiles.jarcec.net/miny/miny.c)
Ale ten zdroják určitě není ukázkou tvého umění, nelíbí se mi v něm vůbec nic 
Mam sice vymluvu, ze toto je jen narychlo splacana gamesa, ale tak priznavam ze je psana odporne
Ale na web bych to radši nedával, nikdy nevíš, kdo to proti tobě může použít
).
Takovyhle zpusob (nageneruju si nahodne neco, a kdyz to nahodou nevyhovuje, generuju znova) je bezny i v jinych oblastech (treba Monte Carlo Markov Chains s Metropolis filtrem, generovani prvocisel atd.). Jde jenom o to, aby pravdepodobnost "nevraceni" byla v nejakem smyslu "velka".
16.7.2007 08:07
andree | skóre: 39
| blog: andreeeeelog
Pascal pravda je krapet zastaralý, ale není lepšího jazyka pro výuku základů.Souhlasím, taky jsem moc rád, že mě učili na MFF na Pascalu. Trochu jsem se zděsil, když se ke mě donesly zvěsti, že se údajně jako na první jazyk přejde na Javu či C#. Ani vlastně nevím, jak to nakonec dopadlo. Snad z toho sešlo
úplné vyhodnocování logických výrazůPascal logické výrazy vyhodnocuje tak, jak mu řekneš. Zkráceně, nebo úplně. K tomu nadšenému postu: pokud se do toho někomu chce, tak prosím. Ale myslím si, že už tady byly daleko užitečnější a nadějnější náměty na různé projekty, které nakonec skončily pod kytičkama
Navíc si nejsem úplně jist, zda se norma Pascalu od defakto normy (Borland) v tomto neliší.
Jasně.
Když přešli na nový engine, šel do kšá i obsah - škoda...co se tam děje teď, netuším.
)
Jo jo, Scheme, to by byla paráda. Ale jsem rád aspoň za ten Pascal.
Jaký by měl být.
http://okmij.org/ftp/cpp-digest/Functional-Cpp.html
)
). Jde mi o to, ze takove pentleni nazvu, aby se tam nemusela psat hvezdicka (v pripade Pascalu strecha) nebo jine modifikatory, je vetsinou spis na skodu (vite co je LPCTSTR? a ma byt LPTSTR konvertibilni na LPCTSTR? podle pravidel Pascalu ne).
Samozrejme ze do funkce ktera chce Zasobnik* vam Strom* nepujde, to da rozum.
Neco jinyho je definovat type Milisekundy : integer; s tim, ze typ Sekundy (definovany obdobne) s nim nebude kompatibilni. Pak by to ale chtelo zpusob, jak rict ze milisekundy se ze sekund dostanou tak, ze se vynasobi 1000. To ale nejde. Ale tlacit programatory aby pojmenovavali ukazatele na neco, ktere nemaji jiny smysl nez ukazatel na neco, s tim, ze kdyz to dva pojmenuji ruzne, tak jim to vynada ... podle mne je to zbytecna buzerace.
Fce vs. procedury. Me vadi ne ze se to jmenuje jinak, ale ze nejde funkci zavolat jen tak, kvuli jejim side-effectum. Pritom nejaky ekvivalent f(x++, x++), coz je v C docela velka pasticka, napsat jde.
Jinak typ Void je nulovy prvek vzhledem k temer vsem operacim s typy, a jednicka v polosvazu konverzi . Nevim, co se vam na tom nelibi. (Jo, bylo by super, kdyby to tak v C++ opravdu fungovalo.. aspon ze jde hodnota typu void vratit pres return).
V nejake forme ma side-effectni a neside-effectni funkce rozlisene treba Haskell.
(ty algoritmy)
No, můj příspěvek byl i tak příliš dlouhý, že jsem to nechtěl rozpatlávat víc.Stačilo by stručně, protože to fakticky nechápu. Co je tedy to všudypřítomné to něco a ty základy, o kterých jsi mluvil? Třeba tady: "základy mi dal BASIC" (jaké základy?). Pro mě jsou ty základy tvořený nejdůležitějšími algoritmy a znalosti jejich výhod a nevýhod. To honění se za Tím Nejlepším a Nejvymakanějším Jazykem™ mi přijde pro výuku naprosto nepodstatné.
Já nikomu pascal neberu - jen u sebe mám pocit, že kdybych ho vynechal, o nic bych nepřišel.Hmmm, fakt to moc nechápu. Ani nevím, co přesně bys čekal, že by ti měl konkrétně dát. Jak už jsem řekl, důležitá je podle mě ta algoritmická stránka výuky a pak ještě něco obecného, čemu se v literatuře říká "dobré programátorské návyky" (to pro tuhle diskusi ale není nějak důležité, tak se tady nebudu snažit vyjmenovávat, co ten pojem zřejmě všechno obsahuje). Pro nic z toho není žádný jazyk, který má "(pořádné) objekty" nebo "různé high-level věci", potřebný.
A co se týče umění programovat - já v tom vidím hlavně strašnou administrativu. Jak to udělat, abych se v tom za čas neztratil? Když to po mě někdo bude číst - pochopí to? Mám to rozdělit do dvou souborů/knihoven hned nebo až potom? Proč autoconf vyhazuje chybu? Bude to fungovat i na topinkovači? Neudělal to už někdo? Co tahle knihovna/funkce dělá? Je k tomu dokumentace? Jaký má autor mail? Proč neodpovídá?Samozřejmě, že jsou tyhle praktické otázky důležité. Ale člověk by si je měl začít klást až poté, co zvládne základy, o kterých jsem psal. Pokud by to tak nebylo, dopadlo by to asi dost špatně.
"Pro mě jsou ty základy tvořený nejdůležitějšími algoritmy a znalosti jejich výhod a nevýhod. To honění se za Tím Nejlepším a Nejvymakanějším Jazykem™ mi přijde pro výuku naprosto nepodstatné."Tak to by sis možná měl přečíst Structure and Interpretaton of Computer Programs, druhé přepracované vydání. Ta učí i "něco navíc". Někteří v čtenářských recenzích říkají, že jim ta kniha třebas i po patnácti letech je stále platná a užitečná, jelikož na některé věci z ní by sami nepřišli (přesněji řečeno věci, které v abstraktních knížkách o algoritmech odtržených od jakéhokoli jazyka nejsou) a pořád tam nacházejí nová moudra. Nedivím se jim, vidím to stejně.
Rád bych si ji sehnal v tištěné podobně, pokud se mi to někdy podaří...
Chvíli jsem přemýšlel, jestli byl tvůj příspěvek vyjádřením nesouhlasu nebo jsi ho napsal "jen tak". Nakonec jsem došel k názoru, že to asi bude ten první případ (jestli ne, tak ani nečti dál ), i když si nejsem jistý, jestli jsem dobře pochopil to, na co narážíš. Takže bych rád zdůraznil, že si nemyslím, že všechna moudrost leží "v abstraktních knížkách o algoritmech odtržených od jakéhokoli jazyka", to jsem určitě naznačit nechtěl a snad jsem ani nic podobného nenapsal (rozhodně ne úmyslně). Chtěl jsem říct jenom to, že podle mě není důležité (a ani vhodné), aby se programování učilo na komplikovaných záležitostech typu C++ nebo Java.
). K tomu pár realtimových jazyků - dodnes se mi stýská. A šup Ada. Jsem už starší, učil jsem se programovat někdy kolem 90-tých let, ale tyhle všechny jazyky měly osobnost a byly promyšlené.
Když vezmu dnešní běžné jazyky pro praxi - C++ je velmi složité, Java je zase tak osekaná, že se v ní pořád všechno co nemá emuluje pomocí objektů, C# je trochu lepší, ale v poslední verzi je to hodně zmatený jazyk ve stylu pejsek s kočičkou vařili dost. Python - no dobře, dejme tomu.
15.7.2007 18:41
Jardík | skóre: 40
| blog: jarda_bloguje
úplné vyhodnocování logických výrazů
Tohle má VB, když jsem dělal v Delphi (pascal), tak to rozhodně úplné vyhodnocování neprovádělo, protože ty moje konstrukce typu (tohle je sice v C++, pascal už jsem skoro zapomněl)
if( a && a[i] && a[i]->janevimco ) {}
by tam určitě jinak neprošly.
and then a or else, které provádějí zkrácené vyhodnocování.
15.7.2007 20:49
martidlo | skóre: 3
| blog: Vztekárna
| Opava
15.7.2007 21:29
martidlo | skóre: 3
| blog: Vztekárna
| Opava
for(i = 0; i < x; i++) je vlastne i = 0; while (i < x) { neco_delej(); i++)) Ale aspoň se to dalo rychle kompilovat, cože tehdy bylo docela důležité (a myslím, že až do začátku 90. let neměly počítače v tomhle směru výkonu nazbyt, a lepší je vynutit deklarace předem než nechat přetéct paměť měřenou na desítky kilobajtů a znemožnit kompilaci vůbec). Nečekám však, že Tě tohle bude zajímat...
15.7.2007 21:53
martidlo | skóre: 3
| blog: Vztekárna
| Opava
Kdo nezna, prohloupil
Je tezsi v nem napsat osklivy program nez hezky.Tohle je bohužel naprostý nesmysl. Jsou lidi, kteří prasí i v tom údajně nezprasitelném Pascalu. Byl jsem toho už vícekrát očitým svědkem
Ale jeden postřeh k Javě - neznám žádného dobrého programátora, který by se vyučil na Javě. Neznám ani dobrého Javistu, který by se naučil programovat právě v Javě. Od té doby lidi zoufale prosím, ať mi takového člověka ukáží, ale nikde nic. Díky tomuto pozorování velmi pochybuji o vhodnosti Javy pro učení programování.Nebude to tím, že Java je mladý programovací jazyk? A tedy jednak zkušení programátoři (s dlouhou praxí) museli logicky začínat na něčem jiném (protože v době jejich začátků Java ještě nebyla), jednak je dnes "programátorů" spousta, takže pokud je někdo dobrý programátor i s krátkou praxí (a mohl tedy začínat s Javou), zanikne v tom kvantu rychloprogramátorů?
Mnozí pomýlení potom doporučují velmi osekané jazyky (např. Javu) s bláhovou domněnkou, že v tom nikdo prasit nebude. Není to pravda.Samozřejmě že je to nesmysl. Prasit se bude, a jak. Zásadní rozdíl spočívá v tom, že zprasený kód v Javě se dá ještě použít.
Podle mě odnaučit prasení je velmi jednoduché - udělejte dostatečně velký projekt (ideálně alespoň stotisíc řádek v jazyce) a několik let ho udržujte - přidávejte do něho nové featury - a mějte nad sebou zákazníka s ostrými termíny odezvdání každé úpravy, nebo opravy chyb. Ideálně v týmu. Je úplně jedno, co používáte za jazyk.Jo jo, to doporučuji. Hlavně ten tým, to je důležité. Člověk se naučí, k čemu je Java. A zapomene na C++ a podobné nápady. Jistě, je zde možnost dát dohromady tým lidí co zvládnou C++. Nebo třeba LISP
Možnost v mnoha oblastech čistě teoretická - člověk co chápe LISP nebo dokáže psát udržitelný program v C++ nebude nikdy ochoten pracovat na úkolech typu "pokud si zákazník objedná kilo jablek mezi druhým a třetím úplňkem v létě, dostane slevu 15% na hrušky".
člověk co chápe LISP nebo dokáže psát udržitelný program v C++ nebude nikdy ochoten pracovat na úkolech typu "pokud si zákazník objedná kilo jablek mezi druhým a třetím úplňkem v létě, dostane slevu 15% na hrušky".Jednomu kamarádovi s takovými kvalitami se naskytla příležitost dva-až-třikrát si polepšit platem...tím, že by programoval makra pro sekretářky ve VBA. Co myslíš, že udělal? Dál programuje embedded zařízení v Lispu a v Cčku... Prostě by to nepřekousl.
Ale jeden postřeh k Javě - neznám žádného dobrého programátora, který by se vyučil na Javě. Neznám ani dobrého Javistu, který by se naučil programovat právě v Javě. Od té doby lidi zoufale prosím, ať mi takového člověka ukáží, ale nikde nic. Díky tomuto pozorování velmi pochybuji o vhodnosti Javy pro učení programování.Také neznám. Ale z toho bych závěry nedělal... Java je nevhodná, protože se jedná o nízkoúrovňový jazyk. Podobně jako C, které je vhodné jen pro ty co znají fungování mikroprocesorů (a vůbec celé architektury, především pak práce s pamětí). Pokud se někomu zdá že je snad Java high-level jazyk, tak ať se pořádně podívá z hlediska JVM. Nebo názorněji, ať se podívá na C# (nejlépe verze 1) z hlediska CLI a v porovnání třeba s F# či Scala.
)
Puvodne nasledovaloJe tezsi v nem napsat osklivy program nez hezky.Tohle je bohužel naprostý nesmysl. Jsou lidi, kteří prasí i v tom údajně nezprasitelném Pascalu. Byl jsem toho už vícekrát očitým svědkem
I kdyz je pravdou, ze prase bude prasecky programovat v cemkoli ...Kterou cast jste nepochopil?
Algoritmy se daji ucit i na kousku papiru. ;)No to dají, ale oni pořád v řadách studentů existují lidi, kteří více věří číslu na obrazovce, než elegantnímu matematickému důkazu
Tudíž je třeba ty algoritmy nabušit do nějakého programu, nejlépe aby měl i nějak hezký barevný výstup a studentíci jsou šťastní A když ne šťastní tak alespoň ne znechucení.
Ajéje! Nechci vyvolat flamewar, ale tenhle příspěvek mě zvedl ze židle tak, že musím reagovat.
...a praktičtí klik-klik-programátoři (Java/C# je the best, protože umí OOP, kompiluje se do bytecode a dělá se v tom EE). Balast.
Smím se zeptat, do jaké míry znáš Javu nebo C#, že si troufáš na takovéto soudy? Koho označuješ za klik-klik programátora? Toho, kdo se programováním opravdu živí? Já osobně mám mnohem radši C++ než Javu, ale tento můj názor těžko obstojí před faktem, že v Javě dnes vzniká 45% veškerého software na zakázku.
Společně pomlouvali Pascal.
Vskutku? Moc rád bych se přidal, kdykoliv by to bylo možné.
Pascal pravda je krapet zastaralý, ale není lepšího jazyka pro výuku základů.Je obecnou zásadou slušnosti napsat v úvodu takto příkrých tvrzení něco jako „Podle mého názoru...“. Podle mého názoru je Packal hnusné svinstvo, které nemělo nikdy spatřit světlo světa a už vůbec jím neměli být nikdy obtěžováni začínající programátoři (studenti). Několik desítek tisíc řádků jsem byl nucen v Packalu napsat a říkám děkuji, již nikdy více. Ale je to jen názor, nemíním se s nikým přít.
Je čtivější než C/C++,...
Věc názoru a vkusu.
...není to OOP kráva (jinak kanón na vrabce) jako Java/C#.
Smím se zeptat, do jaké míry chápeš podstatu OOP a do jaké míry ovládáš jazyky, které kritizuješ?
K PHP se nehodlám vyjadřovat.
Ach tak. Jistě jsi v něm napsal spoustu kódu, když jsi jím tak znechucen.
Konkurovat mu čitelností může jen Python (ale ten si uživatele moc hýčká)...
Mícháš dohromady hrušky a jablka, srovnáváš jazyky bez ohledu na účel, pro který byly navrženy a bez ohledu na to, zda jsou převážně kompilované či interpretované.
Proto mě napadlo, že by bylo zajímavé založit nějaký projekt, v němž by se syntaxe nepatrně přiblížila Céčku, chování také a k tomu se přidalo pořádné OOP, aby propagátorům v Javě sklaplo.
Zaprvé, takový projekt už dávno existuje. Jmenuje se FreePascal a má rozšíření, o kterých tu mluvíš. Navazuje na něj Lazarus, což je náhražka Delphi pro ty „klikací“ programátory.
Zadruhé, podle mého skromného názoru by nebylo dobré zakládat žádný projekt. Naopak by bylo lepší zakázat Packal na všech světových školách a jednou provždy tento humus odstranit. Ale to je pouze můj ryze osobní názor, který nehodlám nikde prosazovat, protože respektuji (často opačné) názory ostatních.
Nebylo by špatné, kdyby to bylo interpretované. Lépe by se ladilo a testovalo.
Opravdu? Za jakých podmínek? Pro jaký typ projektu? Tohle se přece nedá takhle dogmaticky tvrdit.
P.S. Mě do toho tak docela netahejte, jsem v-podstatě-skoro-laik.
Jo tak. Aha. Takže o co v tomhle blogpostu vlastně šlo???
Doslechl jsem se, že na některých vysokých školách se dnes už jako první programovací jazyk vyučuje Haskell. Pravdou je, že jeho praktické využití není valné, ale mám za to, že pro pochopení základních principů programování a algoritmů poslouží výborně.
Kazdy zapisek na blogu je preci subjektivni nazor.To je pravda. Asi jsem reagoval moc podrážděně. Pořád si ale myslím, že „Podle mého názoru...“ na začátku některých těch ostrých tvrzení by neuškodilo. Kdyby třeba napsal „vyzkoušel jsem jazyk X a nelíbilo se mi na něm Y a Z“, nic bych nenamítal. (Vyzkoušet jazyk == aspoň 10000 řádků v procedurálním jazyce nebo aspoň 500 řádků v Lispu/Prologu/Haskellu.) Vždy mě spolehlivě naštvou nepodložené fráze o efektivitě, kanónech na vrabce, čitelnosti nebo podobných rádobycharakteristikách. Zejména když je polovina důležitých jazyků odbyta slovy „o tom raději nemluvím“.
Tak to Vás mohu ujistit, že já se klidně rozhoduji o jazycích,i když v nich nenapíšu 10000 řádků.
Já též. Ale většinou v takových případech své dojmy nepopisuji veřejně a když už, tak s „Myslím si, že...“ na začátku.
Případně můj názor, že Pascal je učební jazyk, který může naučil začínajícího dobrým návykům, ale pro praxi se nehodí a ani tak nebyl zamýšlen.
Souhlasím jen s tím, že nebyl nikdy určen pro praxi. Koneckonců v něm nikdy nic rozumného nevzniklo. Jedinou světlou výjimkou je TeX, ale ten byl brzy poté přepsán do C. Pokud jde o dobré návyky, musím velmi ostře nesouhlasit.
Spousta učebnic této hatmatilky jen tak beze všeho počítá s indexováním [1..N], což je naprosto nevhodné. Chyby typu +-1 jsou při programování v Packalu na denním pořádku a run-time kontrola všech mezí pak vede k přístupu „nějak to zbastlím, pak to párkrát spadne a nakonec to bude v pohodě“. V C tento přístup samozřejmě nefunguje. Možná to spadne hned, možná až za hodinu, možná až na jiné platformě při odevzdávání projektu.
Předávání proměnných „referencí“ - poměrně jasná a rozumná koncepce - je v Packalu neprůhledný nesmysl. Reference tam sice tiše existují, ale nelze je použít nikde jinde než při předávání parametrů, a to ještě velmi ošklivým způsobem. Java i C++ využívají reference mnohem lépe. (Ale tento pojem se v obou jazycích velmi liší.)
Pointery - základ veškerého nízkoúrovňového programování - jsou v Packalu jakousi černou skříňkou. Sice tam existují, ale jen tak napůl. Ve světě skutečných (čti používaných) programovacích jazyků platí zásada: Buď je povolena veškerá manipulace s pointery, včetně aritmetiky (C a C++), nebo neexistují pointery vůbec (Java). (Některé jazyky umí přepínat mezi oběma režimy - C# a jeho unsafe.) Jenže Packal v sobě spojuje nevýhody obou přístupů, aniž by na oplátku přinášel jakoukoliv výhodu. Pointery nejsou nijak chráněny proti zneužití a zároveň není povolena manipulace s nimi.
Stringy v Packalu - toto považuji za nejhorší nápad, jaký kdo kdy mohl mít. S dobrými návyky to podle mého názoru nemá společného vůbec nic.
Řízení běhu - podmínky a cykly jsou navržené velmi špatně. Syntaxe mi připadá ošklivá a nepřehledná (osobní názor). Klíčová slova begin a end sice většinou ohraničují něco jako bloky kódu, ale tyto bloky nemohou mít v sobě další dočasná data. A když už jsme u toho, kam se poděly bloky u repeat - until? Když packalista přejde třeba na C, často píše cykly ošklivým způsobem. Packal nikoho nenaučí, aby správně zapsal, co přesně se v cyklu děje. Jakmile je potřeba cyklit přes něco jiného než několik integerů, jde to jen velmi ošklivě.
Ptám se tedy: V čem tkví výhody Packalu? Jaké dobré návyky se díky němu programátor naučí? Já žádné nevidím. Není to náhodou jen donekonečna opakovaná fráze, o jejíž pravdivosti už nikdo neuvažuje?
Samotný Pascal je hlavně základem mnoha Pascal-like jazyků. Dnes jsou tyto jazyky v pozadí, ale dříve byly na každém kroku.
Tomu rád věřím. V minulosti vidíme spoustu slepých (a zdnešního pohledu přímo nesprávných) směrů vývoje. Zatímco například jazyk C (a s ním i UNIX) přetrvaly už 35 let, pascalovské jazyky (mírně řečeno) poněkud živoří.
Pascal není podle mě zcela domyšleným jazykem (na rozdíl od té Simuly, Ady, Moduly, atd..), prostě byl zamýšlen jen pro výuku, nikoli pro praxi.
Pro výuku má smysl jedině ten jazyk, který je po všech stránkách domyšlený a obecně uznávaný. Děti v první třídě jistě nedostanou slabikář s pravopisnými hrubkami. Taky by někdo mohl říct, že malé děti si záplavy chyb nevšimnou a že ten slabikář není určen pro skutečné zvládnutí jazyka a komunikace, ale jen pro výuku. Tohle je zkrátka špatný argument.
To, že to někdo využívá stylem jakým píšete snad není mínus jazyka.
Je. Nízkoúrovňově se tvářící výukový jazyk prostě nemá umožnit žádné jiné meze než od 0. Vezměte do ruky libovolnou učebnici Packalu. Po několika stranách tam uvidíte Array[1..N] of Integer. Je to jako mor - pořád dokola tenhle nesmysl. Že si v C++ můžu naprogramovat kontrolu mezí? Ano, ale jen když chci. V tom je rozdíl. Dokonce je to v STL. Buď mám nekontrolovaný operator[], nebo kontrolovanou metodu at(). To je možnost volby. V Javě je kontrola mezí vynucená filosofií jazyka, konkrétně neexistencí práce s pamětí.
ad 2) Java, kde rozhodně nepředáte typ int referencí...
public class IntRef { public int value; } A když k tomu přistupuji, přesně vím, co dělám. Když modifikuji nějakou proměnnou o deset rámců zásobníku níže, chci o tom vědět. V Packalu to nevím. Stačí někde zapomenout na var...
...a objekt zase ničím jiným...
To vyplývá z filosofie jazyka - úplná abstrakce paměti, žádné objekty na zásobníku. Ani to jinak nejde. Objekt v Javě není jen chomáč datových položek jako v C++. Je to velmi složitá struktura, provázaná s příslušnou třídou, synchronizačními vlákny, garbage collectorem... Prostě toto omezení má své přesné důvody. (To se o 90% omezení v Packalu říct nedá.)
ad 3) To, že jste si zvykl na "high level assembler" ve stylu C/C++, neznamená, že je to norma.
U toho C bych to přirovnání ještě uznal, ale C++? To fakt ne.
Naopak, pro učební účely umí pointery v Pascalu vše co je potřeba.
Neumí pointerovou aritmetiku. Jednu z nejpodstatnějších záležitostí prostě neumí. Jak už jsem psal: Buď ať tam existují pouze 100% bezpečné reference, nebo ať jsou tam pointery se vším všudy. FreePascal samozřejmě pointerovou aritmetiku má. Původní Packal nemá ani pointerovou aritmetiku, ani bezpečné pointery. Má nevýhody obou přístupů a žádné výhody.
ad 4) Konkrétně co Vám vadí na stringech v Pascalu? To jako práce se stringy ve stylu C je lepší, kde je to jen blok paměti?
Zaprvé, omezení na 255B. Zadruhé, alokace 256B pro každý string. Zatřetí, nedostatečné a nerozšiřitelné knihovní funkce. Začtvrté, jazyk nijak neomezuje takové průšvihy jako předávání stringů hodnotou. Něco takového by mělo být setsakra těžké, aby programátor přesně věděl, co a proč dělá.
Nemusíte hned prasit program pointerovou aritmetikou jako v C/C++, když chcete použít pouhé pole například.
Nejen neprasit. Nemá vůbec smysl používat pole, dokud není začátečníkovi jasné, proč se používá a co vlastně představuje. Začínám mít dojem, že i přes všechny možné námitky by byl pro začátek velmi vhodný Haskell. (Upřímně, já sám Haskell nemám moc rád, protože mi dal ve škole pořádně zabrat.) Tam člověk přesně pochopí, jak funguje zásobník a rekurze a odkud a kam „tečou“ data. Naučí se úspornému a minimalistickému přístupu ke každému problému.
Nemusíte hned chápat pointery jen proto, že chcete práci s řetězcem. Nemusíte všechno násilně ohýbat na meze polí začínající od nuly. Naučíte se dobře strukturovat program, atd..
Ano, ale proč tam pak ty pointery jsou? K čemu? Jazyk, který si hraje na vysokoúrovňový a místo toho vnáší do věci zmatek, mi moc dobrý nepřipadá. OK, zrušme tedy úplně pointery a považujme stringy a soubory dat za axiomy. To je možné. Pak je ale dobré uvažovat o Lispu nebo Haskellu.
Java - naprosto nevhodná - velmi osekaný jazyk - spoustu věcí se musí ohýbat pomocí OOP, i když to OOP není. A vlastně to není ani OOP jazyk. Neznám dobrého programátora, který se učil na Javě.
S tímto plně souhlasím, s poznámkou o C# rovněžtak.
C - dost neschopný jazyk, v podstatě "portable assembler".
Jazyk odráží účel, ke kterému byl navržen. Já si vůbec nemyslím, že by student měl začínat nízkoúrovňovými věcmi. Napřed by měl chápat aspoň základy toho, jak lze formulovat problém, co je to algoritmus, invariant, rekurze, složitost a podobně. Souběžně s tím se může zdokonalovat v technické stránce věci.
C++ - trochu vhodnější jazyk, avšak dost složitý. Velmi těžký jazyk na chápání.
Naprostý souhlas. Pro tento jazyk je nutné chápat správně vše od adresování paměti přes OOP až po algoritmy a jejich použití. Od prvního seznámení k napsání vlastního STL kontejneru vede velmi dlouhá cesta.
Myslím, že to chce začínat po částech a oddělit matematické myšlení (Prolog, Scheme/Lisp/..., Haskell) od ryze technického (C) či objektového (Smalltalk, Java) - aby programátor znal od každého trochu a neztratil se v tom. Žádný přesný recept mě ale nenapadá. Jedno ale vím jistě: Jen ne Packal.
(/ironie)
Já na Vašem místě bych byl opatrnější s těmi slepými větvemi vývoje. To je jenom taková rada.
Pro výuku má smysl jedině ten jazyk, který je po všech stránkách domyšlený a obecně uznávaný. Děti v první třídě jistě nedostanou slabikář s pravopisnými hrubkami. Taky by někdo mohl říct, že malé děti si záplavy chyb nevšimnou a že ten slabikář není určen pro skutečné zvládnutí jazyka a komunikace, ale jen pro výuku. Tohle je zkrátka špatný argument.
Řekl bych tak, běžně se nemluví jazykem, který najdou děti ve slabikáři. Smiřte se s tím, že jazyk pro učení a jazyk pro praxi mohou být dva různé jazyky. A 100% domyšlený není jazyk žádný, natož obecně uznávaný.
Je. Nízkoúrovňově se tvářící výukový jazyk prostě nemá umožnit žádné jiné meze než od 0. Vezměte do ruky libovolnou učebnici Packalu. Po několika stranách tam uvidíte Array[1..N] of Integer. Je to jako mor - pořád dokola tenhle nesmysl. Že si v C++ můžu naprogramovat kontrolu mezí? Ano, ale jen když chci. V tom je rozdíl. Dokonce je to v STL. Buď mám nekontrolovaný operator[], nebo kontrolovanou metodu at(). To je možnost volby. V Javě je kontrola mezí vynucená filosofií jazyka, konkrétně neexistencí práce s pamětí.
Poslouchejte, vy jste se zaseknul někde ve strojáku. Je naprostý nesmysl trvat na nulové spodní mezi - dokonce bych řekl, že je to dost mínus. A neohánějte se C++ bez pochopení souvislostí - C++ je jazyk stvořený na maximální rychlost, ale platí za to krutou cenu - ztrátou bezpečnosti jazyka - a drobná chyba při práci s STL se dá hledat mnoho dní (programuji v C++ asi 15 let). Tyhle prasárny v C++ bych strašně nerad viděl v jiných jazycích - a už vůbec ne v jazycích pro učební účely.
ad 2) Odpovídáte úplně na něco jiného, než jsem napsal, takže se nevyjadřuji.
ad 3) Ale ano, C++ je sice high level, ale pořád je to jazyk tvořený na max, rychlost - a stále je to prací s poli velmi neohrabaný jazyk.
Zaprvé, omezení na 255B. Zadruhé, alokace 256B pro každý string. Zatřetí, nedostatečné a nerozšiřitelné knihovní funkce. Začtvrté, jazyk nijak neomezuje takové průšvihy jako předávání stringů hodnotou. Něco takového by mělo být setsakra těžké, aby programátor přesně věděl, co a proč dělá.
Jste vedle - to co píšete o stringách a jejich limitech byla pravda pro Turbo Pascal od Borlandů, ale standardní normovaný Pascal tyto limity nemá. Za druhé nechápu, proč předávání stringů hodnotou je průšvih. Pokud jste myšlením ve strojáku a počítáte bajtíky pak vám rozumím, ale já mluvím o seriózním programování. Mimochodem, v C++ klidně mohu předat hodnotou řetězec typu ::std::string a jazyk mě v tom nikterak neomezuje.
Nejen neprasit. Nemá vůbec smysl používat pole, dokud není začátečníkovi jasné, proč se používá a co vlastně představuje. Začínám mít dojem, že i přes všechny možné námitky by byl pro začátek velmi vhodný Haskell. (Upřímně, já sám Haskell nemám moc rád, protože mi dal ve škole pořádně zabrat.) Tam člověk přesně pochopí, jak funguje zásobník a rekurze a odkud a kam „tečou“ data. Naučí se úspornému a minimalistickému přístupu ke každému problému.
Já vím začínám rozumět - Vy prostě chcete začátečníka okamžitě zatížit detaily o paměti a o tom, jak to funguje uvnitř. Ale to je zbytečné. Ze začátku se musí naučit algoritmizovat a pochopit všechny abstraktní struktury. Pole má smysl používat, ale nutit hned začátečníkovi představu, že pole je pointer v paměti a je potřeba s ním pracovat pomocí pointerové aritmetiky je IMHO špatná věc.
Úsporný a minimalistický problém je prostě vhodný pro low level věci a tam kde záleží na každé milisekundě, a kde máte pro program několik kilobajtů, jako na jednočipech. Ale profesionální programování o tomhle není, tím se akorát zahrabete. Každá optimalizace (na paměť, nebo rychlost) musí mít důvod - aneb optimalizace pro optimalizaci způsobí, že nikdy nic většího nestvoříte.
Ano, ale proč tam pak ty pointery jsou? K čemu? Jazyk, který si hraje na vysokoúrovňový a místo toho vnáší do věci zmatek, mi moc dobrý nepřipadá. OK, zrušme tedy úplně pointery a považujme stringy a soubory dat za axiomy. To je možné. Pak je ale dobré uvažovat o Lispu nebo Haskellu.
Ty pointery jsou tam proto, že se pracuje s pamětí. A jen zbytečné začátečníka od první chvíle zatěžovat pointery. Takový Python například považuje stringy a datové struktury za axiomy a nikdo nemá problém. A v C++ s pomocí STL se tomuto pojetí blížíte také. V Javě to není o moc odlišné. Je velmi praktické a efektivní mít součástí jazyka základní prvky a struktury jako axiomy - to je také důvod, proč význam jazyka C (a trochu i C++) jde prudce dolů a používá se čím dál méně.
Jazyk odráží účel, ke kterému byl navržen. Já si vůbec nemyslím, že by student měl začínat nízkoúrovňovými věcmi. Napřed by měl chápat aspoň základy toho, jak lze formulovat problém, co je to algoritmus, invariant, rekurze, složitost a podobně. Souběžně s tím se může zdokonalovat v technické stránce věci.
A tohle se právě může naučit a vyzkoušet i prakticky na vhodném jazyce, který anstrahuje od stacku, pointerové aritmetiky, a bere stringy a datové struktury jako axiomy.
Myslím, že to chce začínat po částech a oddělit matematické myšlení (Prolog, Scheme/Lisp/..., Haskell) od ryze technického (C) či objektového (Smalltalk, Java) - aby programátor znal od každého trochu a neztratil se v tom. Žádný přesný recept mě ale nenapadá. Jedno ale vím jistě: Jen ne Packal.
Vidíte a na Pascalu se vyučila spousta vynikajících programátorů. To je pro mě docela měřítko, že to není špatný učební jazyk. Ale jinak s myšlenkou kromě té poslední věty souhlasím.
Váš názor na věc chápu a respektuji. Ale nevkládejte mi prosím do úst prosazování assembleru a kdovíčeho ještě. Já přece neříkám „vnuťme každému C“. Dokonce mám ten dojem, že jsem toho v životě napsal víc v Javě než v C, ale řádky jsem nepočítal, tak nevím. Chtěl jsem jen říct, že je třeba přesně zvolit určitý přístup a využít všechny jeho výhody. Packal je přístup typu „ani ryba ani rak“ aneb „omezení bez výhod“. Má-li být začátečník uchráněn od zásobníku, polí a pointerů, nechť tedy začíná Haskellem nebo Lispem. Tam se o samotné podstatě programování a algoritmizace dozví mnohem víc než v „techničtěji“ zaměřených jazycích. Navíc se úplně vyhne všem zmiňovaným problémům.
Mimochodem, v C++ klidně mohu předat hodnotou řetězec typu ::std::string a jazyk mě v tom nikterak neomezuje.
Ruku na srdce, není toto tak trochu demagogie? Oba přece tušíme, jak se to dá implementovat. Je tam rozhodně copy on write. Na zásobníku je jen pár bytů (možná cca 3 pointery nebo tak) a místo pro vlastní data vyhradí alokátor mimo zásobník, většinou velmi efektivně. Předání „hodnotou“ znamená kopírování malé statické části a zvýšení počítadla pro nějaký counted pointer. Jistě se nezkopíruje rovnou celý string. (Dokud není modifikován.)
Naprosto souhlasím s tím, že pro začátečníka, který neví, co se přesně děje, je STL a vůbec C++ velmi nevhodné. O to se vůbec nepřu. To ale nic nemění na faktu, že Packal přímo umožňuje předávání stringů (a dokonce i celých polí) hodnotou a nikde není přesně popsáno, kdy a jak se to optimalizuje. Jistě namítnete, že takovými věcmi by se začátečník neměl zatěžovat. Souhlasím, ale pak ať se učí jazyk, který takové věci prostě neřeší - některé kandidáty jsem již zmiňoval.
Předchozí odstavec opět není výzvou k výuce C. Právě naopak. Byl bych pro zavedení jazyků nejvyšší úrovně, tedy logických či funkcionálních. Pak by nějaké pole nebo předávání parametrů prostě nebylo nutné chápat ani optimalizovat.
A kde že to prosazuji ten strojový kód?
Pro výuku je lepší interpret á la Python. Z jasných důvodů.Jaké jsou ty "jasné" důvody, nějak je totiž nevidím.
někde se používá Logo, což je taky hezký jazyk (na výuku rekurze).To je Karel taky. Proč tu vlastně ještě nikdo nezmínil Karla?
Ad Haskell: Neznám, ale někde se používá Logo, což je taky hezký jazyk (na výuku rekurze).
Není příliš rozumné srovnávat programovací jazyk s hračkou pro děti...
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
16.7.2007 01:02