První programovací jazyk? (diskuse)

[Jiří P.]

řešilo se to tady ani ne před týdnem

[Karel]

Jedine C#

[Filip Jirsák]

Protežovaný, má společné kořeny jako protekce, s tíhou nebo těžbou nemá nic společného.

A něco přímo k tématu: asi bych si vybral Pascal, nebo možná i něco jako Clipper, dBase a spol. na čem jsem opravdu začínal. Každopádně by to mělo být něco, co lze snadno přinutit můj program zkompilovat a spustit (což je spíš otázka IDE nebo nástrojů), a zároveň něco, co dokáže se základními typy (čísla, boolean, řetězce) pracovat bez použití ukazatelů nebo objektů. Pravda, z dnešního pohledu by Pascal mohl mít více C-like syntaxi (bez begin/end a "zvláštního" chování středníků), ale pokud člověk nic jiného nezná, ani ta syntaxe by mu nevadila.

[Michal Vyskočil]

Protežovaný, má společné kořeny jako protekce, s tíhou nebo těžbou nemá nic společného.

Tak tohle slovo slyším poprvé v životě. No ale asap to opravím ...

[mm]

Jednoznačně Python. Python je podle mě ten nejlepší jazyk pro začátečníky co může být (jsou tu i jazyky přímo pro výuku jako třeba Logo, ale IMHO je lepší naučit se rovnou v jazyku, který mohu úspěšně dál používat i v praxi). Sám jsem začínal jako hodně malé dítě pod DOSem na QBasicu, v té době to byla pro mě jediná možná volba, ale rozhodně bych nyní nikomu žádný derivát Basicu nedoporučil. A stejně tak nedoporučuji jako jazyk pro začátečníka Pascal nebo dokonce C.

Zkrátka jedině Python (nebo ještě možná Ruby).

[happy barney]

pre začiatočníka je najlepšie C (asm je moc hardcore). python ťa nenaučí nič, je až moc vysoko. čím viac si na začiatku natlčieš hubu na segfault, tým si neskôr dávaš väčší pozor.

[mm]

Tak to zásadně nesouhlasím. Nevidím důvod proč se učit v dnešní době nízkoúrovňový jazyk jako C, pokud to člověk vysloveně nechce a nepotřebuje. Dnes jsou hlavním táhlem vysokoúrovňové jazyky a je to tak dle mého názoru dobře. Čím výš, tím lépe. Takovým ideálem kam doufám že se jednou svět dopracuje je Smalltalk.

Navíc pokud by člověk začínal s C, do krve se mu zaryje spousta procedurálních "zlozvyků" a zbytečně si hlavu zatíží spoustou nízkoúrovňových "blbostí" (myšleno s nadsázkou). Lepší je prostě začít rovnou na vysokoúrovňovém objektově orientovaném jazyku, toť můj názor. Nízkoúrovňový jazyk se člověk může (když ho nutně potřebuje/chce umět) doučit později.

[happy barney]

parafráza: načo sa v dnešnej dobe učiť malú násobilku, keď tu máme špeciálnu teóriu relativity?

čím výš, tím lépe ... plus mínus súhlas.

bez znalosti ako funguje nižšia úroveň z vás nikdy nebude programátor. možno tak drevorubač, čo bude vedieť kliknúť sem a kliknúť tam (a nie tam, lebo mu ten múdry soft vynadá niečo o nesprávnych datových typoch).

len tak mimochodom, ako chcete bez procedurálnych blbostí ako podmienky alebo cykly písať vaše všemocné metódy?

[Michal Vyskočil]

No jak, prostě pošlu objektu třídy Boolean zprávu ifTrue, nebo ifFalse s argumentem blok kódu, který se má vykonat- viz řídící struktury ve Smalltalku

[trekker.dk]

Tohle je vtip nebo to tak někde opravdu funguje?

[Michal Vyskočil]

Pokud ano, potom Smalltalkeři na wikipedii a všude jinde (i v odkazovaném článku na rootu) pěkně kecají

[ext3fs]

Souhlasim.

[Honza "tux" Friesse]

Tak Smalltalk už tu byl, Self je na tom podobně, akorát to nebude třída Boolean (Self nemá třídy), ale prostě objektu co rozumí ifTrue a/nebo ifFalse se pošle tahle zpráva a jako parametr bude objekt prezentující blok kódu (lépe řečeno se ten objekt nejdřív klonuje a nastaví se mu jiný parent*, aby fungovalo self tak, jak má).

V TCL to udělám tak, že si vyhodnotím podmínku nějakým příkazem a pak provedu exec na jeden, nebo druhý blok.

V Lisp based jazycích (Scheme, Common Lisp) si to s trochou hraní s makry napíšu podobně jako v TCL.

"Procedurální blbosti" jsou sice v absolutních číslech nejrozšířenější, ale kromě imperativních jazyků, se to zřejmě všude řeší jinak, bez zásahů do kompileru.

[trekker.dk]

Navíc pokud by člověk začínal s C, do krve se mu zaryje spousta procedurálních "zlozvyků" a zbytečně si hlavu zatíží spoustou nízkoúrovňových "blbostí" (myšleno s nadsázkou). Lepší je prostě začít rovnou na vysokoúrovňovém objektově orientovaném jazyku, toť můj názor. Nízkoúrovňový jazyk se člověk může (když ho nutně potřebuje/chce umět) doučit později.

Zlozvyků jako třeba že paměť je po použití potřeba uvolnit, proměnné před použitím inicializovat apod.

Je tu spousta lidí, kteří tvrdí, že je potřeba programovat vysokoúrovňově. Tak mi řekněte, jak ve vašem vysokoúrovňovém jazyce naprogramujete ovladač k HW. Nebo operační systém. Nebo realtime aplikaci. Z toho první dvě položky dost nutně potřebujete, jinak sice můžete krásně programovat ve Smalltalku, Javě nebo podobných, ale jaksi to nebudete mít na čem spusit.

A doučit se nízkoúrovňový jazyk později je problematičtější, než opačně. V nízkoúrovňovém jazyce víte, co všechno je potřeba udělat a při přechodu výše akorát zjišťujete, co už udělat nemusíte, protože to někdo udělal za vás.

Na druhou stranu bych chtěl vidět, za jak dlouho (pokud vůbec) by někdo, kdo dlouho programoval v jazyce, který poskytuje nějaký ekvivalent garbage collectoru, odladil program, aby v něm nebyly memory leaky.

[xkucf03]

Např. v javě se naučíš proměnné nastavit hodnotu null, když už ji nepotřebuješ -- tím řekneš GC, aby při nejbližší vhodné příležitosti uklidil. Rovněž java není prasárna typu PHP, takže když nedeklaruješ proměnnou, tak program ani nepřeložíš. Když jí nenastavíš hodnotu, tak je null, ale s tím si už musíš poradit sám.

Kdo říká, že by se ovladače měli programovat pomocí vysokoúrovňového jazyka? Já jen říkám, že to běžný programátor nepotřebuje. Skutečně dobrých programátorů, kteří dělají ovladače, není na světě mnoho, ale stačí to. Všichni ostatní se pohybují na vyšších úrovních, jejich cílem je dělat užitečné programy pro uživatele a ne přesypávat bajtíky z místa na místo.

"A doučit se nízkoúrovňový jazyk později je problematičtější, než opačně." S tím zásadně nesouhlasím. Když jsem zvyklý na OOP a přijdu k nějakému nižšímu jazyku, tak mi tam něco chybí -- a nezbude mi, než se to doučit. Ale si někdo zvykne namastit program v céčku (céčkaři prominou) a přejde na vyšší jazyk, tak mu tam relativně nic nechybí a on bude ty kódy mastit tak, jak byl zvyklý. Prostě ho často ani nenapadne, že v OOP to jde jednodušeji, jinak, lépe...

[happy barney]

OOP nie je všeliek. java je prasárna iného typu. java nie je objektový jazyk. je to len jazyk s niektorými objektovými črtami.
vyššia úroveň nie je len o OOP. Prečo programovať, keď často postačuje deklarovať pravidlá a zvyšok si program doráta sám?

[kouby]

Java je objektovy jazyk.

[happy barney]

nie je. java je jazyk s objektovými vlastnosťami.

[Miloslav Ponkrác]

Java není zcela objektový jazyk, to pochopíte, až poznáte skutečně 100% objektový jazyk, kde je naprosto všechno objektem.

[kouby]

Píšu snad někde, že je zcela objektový? To, že nesplňuje větu "everything is an object", tak to z tohoto jazyka udělá 90% objektový jazyk? To tu objektové jazyky budeme rozlišovat podle procent? Nepřijde vám to hloupé? Jednou je navržen jako objektový, pracuje se v něm s objekty, tak kde je problém? V tom případě je to objektový jazyk. Nevím tedy do jaké jiné kategorie programovacích jazyků by jste Javu zařadil, ale kategorie 90% OOP languages neexistuje.

[zippy]

v prvom rade - java je prasacky jazyk. nechapem preco musim mat 2 rozne triedy, ktore chcu medzi sebou komunikovat v 2 roznych zlozkach? Preco to nemoze byt ako C/C++ vsetko v jednej zlozke - prip. vo viacerych? Tuto musim mat kazdu triedu zvlast - to mi pride ako najvacsia zvrhlost. Prekladac by mal byt aspon trosku inteligentny, nie?

[xkucf03]

Těm složkám se v Javě říká balíčky (package). V jedné složce můžeš mít úplně klidně víc tříd. Když budeš prasák, tak můžeš dát všechny třídy do jedné složky (výchozí balíček). Ale javisté mají rádi pořádek, takže třídy tématicky dělí a související třídy dávají do balíčků Navíc pokud dodržuješ konvence, tak má třída celosvětově jedinečnou identifikaci - např. cz.mojeDomena.superUzasnyProjekt.NejakaMojeTrida

[Pavel Křivánek]

Ve Smalltalku se psaly operační systémy, když neexistoval ještě ani MS-DOS a běžně se pro něj virtuální stroje píší v něm samém.

[trekker.dk]

A kolik takových operačních systémů se v něm píše dnes? A nebo jinak, proč se všechny běžně používané operační systémy píší v C?

[Pavel Křivánek]

Asi jeden. Samozřejmě nechci popírat hegemonii C a Smalltalk bych jako první programovací jazyk doporučoval asi jen neprogramátorům. Chtěl jsem jen zpochybnit tvrzení, že to nejde.

[xkucf03]

Ahoj. O smalltalku vím jen něco málo, ale mám tušení že je to hodně zajímavý jazyk Jaké je jeho dnešní praktické použití? Nějaké reálné projekty? Ne jen nějaké ukázkové příklady. Abych viděl, co se v tom dá udělat?

[Pavel Křivánek]

Pár odkazů:

http://www.seaside.st/

http://www.squeaksource.com/

http://www.opencroquet.org/index.php/Main_Page

http://www.sophieproject.org/

http://planet-plopp.de/

http://weblogs.media.mit.edu/llk/scratch/

http://www.dabbledb.com/

http://www.cmsbox.ch/

http://wiki.laptop.org/go/Etoys

http://wiki.cs.uiuc.edu/VisualWorks/Commercial+projects+that+use+Smalltalk

[Kyosuke]

"Z toho první dvě položky dost nutně potřebujete, jinak sice můžete krásně programovat ve Smalltalku, Javě nebo podobných, ale jaksi to nebudete mít na čem spusit."

Vím, že jdu pozdě, ale jen jednu drobnost: Autorům Squeaku se právěže nechtělo psát virtuální stroj v křehkém Cčku, tak ho napsali ve Smalltalku. Pokud jde o Smalltalk-80, ten běžel přímo na hardwaru - smalltalkovém CPU. Lisp Machine měla OS psaný ve vysokoúrovňovém Lispu, a ten běžel na lispovém CPU.

[botanicus]

"Python je podle mě ten nejlepší jazyk pro začátečníky co může být"

Ale ne! Ty fakt neznas Ruby :) ? (vim, ze ho tam pak jmenujes, ale to by bylo abych si nerejpnul ;) )

ale tak zas trochu vazne - ano, python je na uceni se dobrej jazyk, sam jsem se na nem ucil a nelituji toho (byt v nem dnes jiz nic nepisu). Ale kdybych si mel vybrat, Ruby mi prijde na uceni o trochu intuitivnejsi a praktictejsi. A rozhodne mocnejsi.

[jarda]

Python - to si chtel slyset ne?

[anicka]

Ja bych zacala zase ceckem - prezila jsem to jednou, prezila bych to znovu... ale nevim, jestli je to skutecne doporucenihodne

[nooneanymore]

FORTH? MODULA-2?

[nooneanymore]

Otázka asi zněla: jaký jazyk bych si dnes vybral. Takže to, co jsem napsal odvolávám.

Dnes bych se asi hned odhodlal k C: je to přece jenom nejpoužívanější jazyk (mýlím-li se, opravte mě). Nebo C++?

Python se mi zdá svou jednoduchostí zrádný. Člověk o programování nepotřebuje znát vůbec nic, aby s ním začal, což je asi dobré pro začátky, ale určitě ne pro život.

Já se kvůli škole dostal k FORTRANU 95 a nezdá se mi nějak obzvlášť těžký. Sice teďka mírně z donucení programuju v C a něco píšu v Pythonu, ale ten fortran určitě ještě nepatří do starého železa. Ale asi není použitelný pro "takové každodení žvýkání, vite?"

Offtopic: Mimochodem, nevíte, jak se pokročilo s fortranem 2003? Už existuje kompilátor?

[Luboš Doležel (Doli)]

Já jsem šel JavaScript -> PHP -> Java -> C++ a nebylo to zlé

[happy barney]

s odstupom času?

z postupnosti pascal, c, c++, asm, shell, perl, lisp, prolog, java by som vyhodil pascal, c++ presunul k jave (s miernou preferenciou javy a uml) a perl presunul za prolog.

[xkucf03]

Doporučil bych Javu nebo nějaký objektově orientovaný jazyk. A nejlépe pod vedením někoho zkušenějšího ať už učitele ve škole nebo staršího kamaráda. Nejdůležitější je, naučit se objektově myslet. OOP se dnes nevyhne žádný programátor a je velká škoda zatěžovat se procedurálními zlozvyky.

Psát geniální algoritmy v assembleru nebo čistém C je záležitost pro pár vyvolených, chce to v první řadě nadání. Kdežto většina programátorů bude dělat OOP, programovat na vyšší úrovni. Naučit se nízkoúrovňově programovat třeba v C se dá i v pozdějším věku, ale opačný postup je o dost složitější. Objektový přístup je nejlepší si osvojit s "čistou hlavou" dokud člověk není zatížený rutinní prací nižších jazycích. Pozdější přeučování se na OOP dá přinejmenším více práce.

Já jsem začínal s SGP Baltazarem (to byly časy pak chvíli nic, potom Visual Basic 6, ale v něm jsem naklikal jen pár okýnek, moc jsem toho nenaprogramoval, takže mě tenhle jazyk nestihl zkazit pak zase chvíli pauza a potom rovnou Java, které se věnuji dodnes.

[Miloslav Ponkrác]

Já bych doporučil začít bez objektů. Protože myslím, že lepší cesta je nejdřív strukturované programování bez objektů a pak je nasadit. Nesouhlasím s tím, že objekty je potřeba se naučit s čistou hlavou. Objektový přístup je stejně metodika, a ta se dá dělat i v neobjektových jazycích. Objektový přístup je přirozený, ale není vhodný na všechno vždy a všude. Cílem prostě není vytvořit sektu programátorů co se budou klanět objektům, ale pochopit OOP jako prostředek k nějakému cíli. A není to prostředek jediný.

Javu bych na učení nevybral z jednoduchého důvodu, neznám naprosto žádného programátora, který by dobře psal v Javě a nenaučil se proamovat v jiném programovacím jazyce. Vzhledem k její očesanosti a nutnost leccos "opisovat jinak" jen kvůli přehnané strohosti tohoto jazyka ani Javu za vhodný učební jazyk nepovažuji. Ale můj subjektivní názor.

Můj postup byl asm -> Pascal -> C -> Simula/Smalltalk/Ada -> C++ -> a pak se to hodně začíná rozvětvovat.

V poslední době hodně Java (ze které utíkám), Python, PHP, C++, a různé speciální problémové věci.

Je také dobré si časem vyzkoušet funkcionální programování a dynamický jazyk - hodně to změní náhled na programování a zjistíte nové možnosti.

Jinak záleží co chcete programovat. Podle toho bych vybral jazyk.

[botanicus]

Nesouhlasim. Dneska bez objektu? IMHO je to jedna z prvnich veci, co by se mel clovek o programovani dozvedet. (nejlepse s pronasenym povzdechem: "jo jo, driv se psavalo proceduralne, no jo, to byl jeste pravek IT....") :D

S funkcionalnim souhlasim, fakt ze to chce zkusit, pozdejc. Sam jsem nekolika lispovskymi zavorkovymi orgiemi prosel a nelituji toho :)

[Miloslav Ponkrác]

Bez objektů se dneska prakticky neprogramuje, ale přesto si nemyslím, že by se s tím mělo začínat, pokud se někdo učí programovat. Procedurálně se programuje mimochodem dodnes, jak si jako myslíte, že je psaný třeba kód metod tříd, apod..?

OOP se v klidu a v pohodě člověk naučí o chvilku později. Mimochodem, když už tak ať se OOP učí na jazyce, který je skutečně dobře objektový - Java to není, neboť si pomáhá mnoha neojektovými triky, takže to co se naučíte na Javě není až tak úplně OOP.

[Kyosuke]

Objekty určitě, ale jedině v duchu třetí kapitoly SICP!

[trekker.dk]

Nejdůležitější je, naučit se objektově myslet. OOP se dnes nevyhne žádný programátor a je velká škoda zatěžovat se procedurálními zlozvyky.

Tyhle procedurální zlozvyky umožní člověku pochopit, jak takový program funguje. Člověk který začne rovnou Javou, nemá tušení, že program musí nějak začít, proměnné je třeba nějak inicializovat atd.

Objektový přístup je nejlepší si osvojit s "čistou hlavou" dokud člověk není zatížený rutinní prací nižších jazycích.

Naopak - nejdřív je potřeba naučit se základy algoritmizace - podmínky, cykly, používání proměnných - bez zbytečného public static objektového balastu okolo - ten začátečníky jenom mate (viděl jsem spoustu lidí, kteří byli nuceni začít Javou - moc se nechytali)

To souvisí i s předchozím odstavcem - když si člověk navykne, že překladač za něj automaticky inicializuje proměnné a JVM za běhu hlídá, aby si programátor nemohl nabít ústa; přechod na jazyk, který tohle nedělá, může působit značné potíže.

[happy barney]

btw, implementácia metód je čisté procedurálne programovanie

[xkucf03]

Tyhle procedurální zlozvyky umožní člověku pochopit, jak takový program funguje. Člověk který začne rovnou Javou, nemá tušení, že program musí nějak začít, proměnné je třeba nějak inicializovat atd.

V javě začne program zavoláním statické metody main nějaké třídy. Je na tom snad něco špatného?

Naopak - nejdřív je potřeba naučit se základy algoritmizace - podmínky, cykly, používání proměnných.

Podmínky a cykly jsou samozřejnou součástí jakéhokoli programování včetně OOP. To se prostě musí naučit každý, ani v OOP o ně člověk nebude ochuzen.

Viděl jsem spoustu lidí, kteří byli nuceni začít Javou - moc se nechytali.

Proto jsem tam taky psal, že je vhodné, když tě ze začátku někdo vede a neučíš se to sám. Pochopit objektový přístup dá trochu práce (dneska mi to připadá úplně přirozené, ale na začátku jsem taky divně koukal na nějaké třídy, když jsem si chtěl vypsat jen "Hello world"), ale je potřeba se to naučit hned na začátku

To souvisí i s předchozím odstavcem - když si člověk navykne, že překladač za něj automaticky inicializuje proměnné a JVM za běhu hlídá, aby si programátor nemohl nabít ústa; přechod na jazyk, který tohle nedělá, může působit značné potíže.

V tom je právě ten vtip: když přecházíš z vyššího jazyka na nižší, tak zjišťuješ, co všechno musíš a protože musíš, protože jinak by se ti to nepřeložilo, tak se to prostě doučíš. Ale když přecházíš z nižšího jazyka na vyšší, tak nevíš, co všechno nemusíš, co za tebe udělá jazyk/překladač, a proto to tam mastíš tak jak jsi byl zvyklý doteď. To jsou právě ty zlozvyky. Buď bys musel mít nějakého dobrého učitele, který by ti s přechodem na OOP pomohl nebo pozorně číst dobré knihy, ale každopádně je to víc práce, než při opačném postupu.

A navíc, kdo říká, že budeš muset přecházet na nižší jazyky?

[trekker.dk]

V javě začne program zavoláním statické metody main nějaké třídy. Je na tom snad něco špatného?

Nezačne.

Naopak - nejdřív je potřeba naučit se základy algoritmizace - podmínky, cykly, používání proměnných.

Podmínky a cykly jsou samozřejnou součástí jakéhokoli programování včetně OOP. To se prostě musí naučit každý, ani v OOP o ně člověk nebude ochuzen.

Proč jsi v té citaci vynechal tu část "bez zbytečného public static objektového balastu okolo - ten začátečníky jenom mate". Ta tam byla dost podstatná.

Pochopit objektový přístup dá trochu práce, ale je potřeba se to naučit hned na začátku

Není - všechno, co jde udělat s objekty, jde udělat i bez nich.

když přecházíš z vyššího jazyka na nižší, tak zjišťuješ, co všechno musíš a protože musíš, protože jinak by se ti to nepřeložilo

To není pravda... když v programu v C vyřeším dealokaci takhle

velka_struktura_v_pameti_t *struktura;
struktura = NULL;

překladač to naprosto bez jediného varování přeloží. Když si neinicializuješ proměnnou, možná vyhodí varování, ale program taky přeloží.

Ale když přecházíš z nižšího jazyka na vyšší, tak nevíš, co všechno nemusíš, co za tebe udělá jazyk/překladač, a proto to tam mastíš tak jak jsi byl zvyklý doteď.

Pokud přecházíš na vyšší jazyk, tak to děláš proto, aby ses ten jazyk naučil. Kdybys všechno dělal tak, jak jsi byl zvyklý doteď, je ten přechod naprosto zbytečný a není potřeba to vůbec dělat. A hlavní rozdíl - narozdíl od předchozí možnosti, když to namastíš tak, jak jsi byl zvyklý, ten program bude fungovat.

Buď bys musel mít nějakého dobrého učitele, který by ti s přechodem na OOP pomohl...

Omyl - když člověk zná programování bez objektů, OOP pochopí snadno - z jeho hlediska je objekt jenom další datová struktura s tím rozdílem, že se do ní nehrabe přímo, ale pomocí metod třídy.

[Pavel Křivánek]

Proč jsi v té citaci vynechal tu část "bez zbytečného public static objektového balastu okolo - ten začátečníky jenom mate". Ta tam byla dost podstatná.

Public static balast má s objektovým programováním pramálo společného.

[xkucf03]

Nezačne.

A čím jiným by asi začínal? Teda pokud nemyslíš spuštění vlastního VM jakožto spuštění procesu z pohledu OS.

Proč jsi v té citaci vynechal tu část "bez zbytečného public static objektového balastu okolo - ten začátečníky jenom mate". Ta tam byla dost podstatná.

Ty nevíš, k čemu to slouží, že to nazýváš balastem? Ono je to nemate o nic víc, než kdyby začínali s OOP až po osvojení se procedurálních základů. Takhle jen vstřebávají oboje současně a výhoda je v tom, že začnou rovnou v jazyce, ve kterém budou později pracovat, a hlavně se vyhnou těm zlozvykům.

co jde udělat s objekty, jde udělat i bez nich.

Tím ale pouze potvrzuješ moje slova. Jasně, že můžeš namastit krásnou GUI aplikaci i procedurálně, ale jednak ti to zabere hodně času a jednak budeš psát jako prase i ve vyšších jazycích, nebudeš přirozeně využívat možností, které ti přinášejí.

Pokud přecházíš na vyšší jazyk, tak to děláš proto, aby ses ten jazyk naučil. Kdybys všechno dělal tak, jak jsi byl zvyklý doteď, je ten přechod naprosto zbytečný a není potřeba to vůbec dělat.

Ale nebuď tak naivní, programátor bude spíš přecházet na nový jazyk, protože to po něm chtějí v práci, nebo proto, že se chce zapojit do projektu, který se dělá v jiném jazyce.

A hlavní rozdíl - narozdíl od předchozí možnosti, když to namastíš tak, jak jsi byl zvyklý, ten program bude fungovat.

Fungovat sice ano, ale až dostane nějaký tvůj kolega za úkol k tomu přibastlit nějakou novou funkčnost, tak tě bude proklínat nebo ti to rovnou přijde omlátit o hlavu, protože jsi mu tím přidělal spoustu práce Kdežto když budeš přecházet z vyššího jazyka na nižší, tak se ti to buď nepřeloží, nebo to nebude fungovat, což tě donutí doplnit si znalosti a napsat to hned napoprvé čistě a správně

[finc]

Souhlas. V knize Java 5.0 od Rudolfa Pecinovského, sám autor psal, že při výuce OOP se setkal s tím, že lidem, kteří měli zkušenosti s procedurálním programováním, trvalo o mnoho déle se objekty naučit než těm, kteří byli čistý list papíru. Je to logické, jelikož ti bude minimálně rok či dva trvat, než se zbavíš toho procedurálního přemýšlení při návrhu. Co se týče if, switch, while, for, atd. je to tak elementární věc, která lze naučit během pár hodin. A co se týče efektivního použití, stejně je to o praxi a až za několik let později zjistíte, jak vlastné správně a co nejrychleji (pro program) dokážete udělat správný algoritmus.

[Miloslav Ponkrác]

Aha, no to jsou mi noviny. Takže nakonec se dozvím, že je super těžké naučit se OOP, ale if, switch, while, for a algoritmizace je levou zadní.

Přechod na OOP je velmi přirozený, a zapomínáte na jednu věc. OOP NENÍ CÍLEM. Cílem je vyřešit problém, a OOP není posvátná kráva, ke které by se měli všichni modlit, ale cílem je efektivně řešit problém. Nevím, proč se tu prezentuje furt OOP jako posvátný cíl, protože to tak není.

Nevím, ale snad každý kdo preferuje Javu si pořád myslí, že OOP je ten posvátný cíl, ta velká modla, ke které se musí dojít. A že umět OOP = umět programovat, což je blbost na entou. Tohle je mýtus, který Javisté velmi mohutně podporují, ale je to blábol.

Můžete se tedy klidně rychle z čisté vody naučit OOP, ale klidně budete programátoři na baterky, to už pan Pecinovský, ani jiní Javisté nezohledňují - věřte tedy jen statistice, kterou si sami zfalšujete...

[xkucf03]

Aha, no to jsou mi noviny. Takže nakonec se dozvím, že je super těžké naučit se OOP, ale if, switch, while, for a algoritmizace je levou zadní.

Naučit se seřadit podmínky v IFu tak, aby se vyhodnocovaly co nejefektivněji, se můžeš naučit později. Prostě to ze začátku neřešíš, nepřemýšlíš nad tím a potom začneš a budeš to dělat líp a líp. Ale když se naučíš řešit složitější otázky procedurálně a pak přejdeš na OOP, tak už budeš zatížený těmi zlozvyky, ty víš, jak problém vyřešit procedurálně, a tudíž tě nic nenutí využívat výhod OOP natož myslet objektově. Jak už tady někdo psal, ty zlozvyky tě ovlivňují už ve fázi analýzy.

A že umět OOP = umět programovat, což je blbost na entou.

Ale no tak, vždyť nejde o to, hádat se, kdo je větší guru. Někdo je machr v tom, že programuje ovladače zařízení a jádra operačního systému v nízkoúrovňovém jazyce, a druhý zase dokonale chápe objektový přístup a dokáže dělat geniální aplikace. Oba tihle programátoři jsou machři, ale jsou to dvě různé disciplíny, takže nemá cenu se hádat, kdo z nich je lepší.

[Miloslav Ponkrác]

Ne, zase v prvním odstavci vidím, OOP je posvátná kráva, naučte se OOP, ostatní se můžete naučit později. To je přeci blbost jako vrata!!! Slovo zlozvyky v tomto kontextu moc nechápu - prostě procedurální chápání je základ. Podotýkám, že se profesionálně živím jako programátor a analytik zhruba 20 let. OOP používám na každém rohu.

Druhý odstavec není o hádání se, kdo je větší guru, ale o tom, že prostředky (tedy OOP) by se neměly vydávat za cíl. A bohužel Vy (a pan Pecinovský bohužel rovněž) za cíl.

[xkucf03]

1) neříkám, že se OOP nedá naučit dodatečně. Ale dá to víc práce a je tam vyšší nebezpečí, že člověk bude programovat jako prase (čímž se nechci nikoho dotknout).

Problém je asi v tom, že když někdo zvládne ty úplné začátky jazyka, tak chce dělat nějaké složitější smysluplnější aplikace. Kdyby v tu chvíli přešel na OOP, tak to bude v pořádku a nebude vadit, že začínal procedurálně. Ale většina lidí to neudělá a začne ty složitější* věci mastit procedurálně, jakž takž se to naučí. A když se jim dostane do ruky objektový jazyk, tak nemají přirozenou potřebu chápat OOP a programovat objektově, protože to už umí nějak zbastlit. Kdežto člověk, který neumí nic, se to OOP spíš naučí.

2) OOP je svým způsobem posvátná kráva A kvalitní OOP je jedním z cílů** Protože kritériem pro kvalitu programu není jen rychlost, funkčnost, ale i možnost dalších úprav. Jestli někdo pomalu ani neví, co je třída, nebo dědičnost a jen tak tam něco namastí, tak tím přidělává práci programátorům, kteří mají navázat na jeho práci, oni se budou prát s jeho zprasenou architekturou. Proto je správné využívání objektového přístupu jedním z druhotných cílů, protože nám šetří práci v budoucnu, až bude potřeba program rozšiřovat.

*) tím složitější nemyslím nějaké "enterprise" záležitosti, ale skoro všechno kromě hello world a třídění seznamu. **) ne, že by se objektový přístup měl cpát všude, ale když už se použije objektový jazyk, tak by se měl používat správně.

[Miloslav Ponkrác]

ad 1) A já nechápu proč by se měl OOP učit jako první, dále nechápu, proč to dá více práce naučit se to později, a už vůbec nechápu jakým způsobem OOP zabrání tomu, že člověk bude psát méně jako prase. Prostě spousta nesprávných tvrzení položených jen tak.

ad 2) Ne, cíl není kvalitní OOP - mohu říci, že za 20 let praxe jsem nikdy neměl, ani nedostal za úkol tento cíl. Kvalitní OOP byl vždy maximálně prostředkem, nikdy cílem.

Správné využívání OOP je jedním z prostředků, ale spíše mám pocit, že dnešním problémem je nesmyslné nadužívání a ztrácení se v tom, že to nutně musí být "správně" OOP.

Mimochodem, OOP stejně jako všechno na světě nemá jen klady, ale také i zápory.

ad **) OOP nepotřebuje objektový jazyk, OOP lze klidně jako metodiku využívat i třeba v assembleru, nebo v C - to není až takový problém

[xkucf03]

1) Argumenty jsem napsal už v bodu 1 předchozího příspěvku. Jestli je někdo nechce vidět, tak už nemá cenu psát něco dál.

2) Jedním z cílů bude, aby byl kód přehledný a v budoucnu rozšiřitelný, což v případě objektových jazyků vyžaduje správné objektové myšlení a promyšlenou architekturu.

[Miloslav Ponkrác]

ad 1) Já jen napsal zase svoje argumenty.

ad 2) No to hlavně vyžaduje víc a je třeba také počítat s tím, že rozšířitelnost vyžaduje také předvídavost a zkušenosti - a to někdy velmi značné a i tak se to nemusí vždy podařit - to OOP je tam tak trochu v pozadí. Proto znovu říkám, že OOP by nemělo být tak vyzdvihováno.

[happy barney]

ad 2: viac ako rozšíriteľnosť je imho potrebná znovupoužiteľnosť ... a tam má síce OOP krásne reči, ale generické programovanie je lacnejšie.

[Kyosuke]

"Jestli někdo pomalu ani neví, co je třída, nebo dědičnost a jen tak tam něco namastí, tak tím přidělává práci programátorům, kteří mají navázat na jeho práci, oni se budou prát s jeho zprasenou architekturou."

Mnohem větší problémy těm programátorům způsobí tehdy, nebude-li vědět, co je to abstrakce a modularita. Dědičnost a třídní objektový model jsou jen konkrétní - a to velmi rigidní a omezené! - prostředky, jak abstrakce a modularity dosáhnout. Mnohem lepší je umět abstrahovat a modularizovat obecně. (Pokud má člověk jen dědičnost a třídy, taky může vyřešit všechno. Stejně tak se dají zatloukat hřebíky kombinačkami, že. )

[botanicus]

A Ruby? Samy objekt a balast zadnej.

[anicka]

Psát geniální algoritmy v assembleru nebo čistém C je záležitost pro pár vyvolených, chce to v první řadě nadání. Kdežto většina programátorů bude dělat OOP, programovat na vyšší úrovni.

To bych zrovna netvrdila - unixove prostredi je spjate s obycejnym C a jeste dlouho to tak zustane. Naprosta vetsina software pro Linux je napsana v C. Uzivit se psanim v C se zatim da velmi pohodlne a myslim, ze jeste nejaky cas to nebude jine... ja mam tedy rozhodne v planu vyhybat se OOP hype pokud mozno az do konce zivota

Mimochodem, ma dosavadni zkusenost rika, ze spis nez nadani vyzaduji zacatky s C ohromnou spoustu trpelivosti. (Eh, tenhle prispevek pisu, protoze mam plne zuby po nekolika hodinach dosud marneho hledani jednoho memory leaku... tak ted radsi pujdu posbirat zbytky trpelivosti a zpatky na stromy. )

[xkucf03]

To bych zrovna netvrdila - unixove prostredi je spjate s obycejnym C a jeste dlouho to tak zustane.

To nízkoúrovňové každopádně, ale psát v tom GUI nebo enterprise aplikace, to by mě asi jeblo Pro užitečnost aplikace je důležitější nápad, myšlenka, co mi ten program jako uživateli přinese. Ale jestli ten programátor strávil stovky hodin nad tím, aby to napsal ve starém céčku, místo aby to měl v Javě o polovinu rychleji, mne jako uživatele vůbec nezajímá. Natož abych byl ochotný mu za to platit.

[trekker.dk]

Ty bys mu to možná nebyl ochotný platit, ale tvůj zákazník by možná nebyl ochotný platit za program v Javě.

A co se enterprise aplikací týče, tam se C určitě neztratí.

[xkucf03]

Musím říct, že za tu javu platí slušně rozhodně si nestěžuji.

Enterprise aplikace bude používat třeba DB napsanou v C. Ale ta vlastní aplikace bude už v nějakém vyšším jazyku. Mluvím o takových věcech, jako jsou webové služby, webové aplikace, client server aplikace s tlustším klientem atd. To jsou prostě věci, které se nedají psát v céčku. A když už to v něm napíšeš, tak je to akorát práce navíc. Musíš prostě uznat, že každý jazyk je vhodný na něco jiného. Já si vážím těch programátorských polobohů, kteří pracují třeba pro Oracle nebo PostgreSQL, nebo píšou jádra operačních systémů. Ale takových lidí je poměrně málo. Když teď někdo začíná programovat, tak ho s největší pravděpodobností čeká práce v nějakém vyšším jazyce.

Jasně, že je dobré, když člověk ví, co se děje uvnitř, na těch nižších úrovních, ale to se může doučit za pochodu, postupně. Ale když si na začátku vytvoří zlozvyky a nebude schopný správně objektově programovat, tak se to bude doučovat podstatně hůř. Já musím číst kód i po jiných lidech a vylepšovat ho, takže vím, o čem mluvím...

[happy barney]

zlozvyky sú FUD. zlozvyky neexistujú. a aj polobohovia sú smrteľný.

nie, nevieš, o čom točíš. nečítal si všetok kód po iných ľuďoch, čítal si len po tých, čo ho vylepšovať nemôžu ... neodišli náhodou z firmy?

čitateľný kód je záležitosťou disciplíny a schopností. Príklad: perl. Zlé jazyky o ńom vravia, že je nečitateľný ... ale napr z CPAN modulov, mnou používaných, 90% je pochopiteľných na prvé prečítanie, ((zámeno)to).concat (WhiteSpace.SPACE).concat (((sloveso)je).negate()).concat ((trademark)Java))

[botanicus]

OOP se nelibi? Proboha proc?

[Martin]

Doporučil bych Javu nebo nějaký objektově orientovaný jazyk.

No, s tou Javou (a jí podobným jazykům) bych si tak jistý nebyl. Kamarád měl první kurz programování v minulém semestru právě v Javě a jediné, co dělali, bylo, že se patlali ve specifikách jazyka, algoritmy žádné. I když nevím, jak přesně to na VŠB chodí - syntaxi Javy bych snad zvládnul za pár hodin a že by tam bylo tolik speciálních záležitostí, které by byly nějak náročné na zvládnutí, to teda nevím... tak či onak, mi jazyky podobného typu nepřijdou na učení se programování (tj. učení se algoritmům) zrovna vhodné - algoritmům je úplně jedno, v čem je naimplementuju, je důležité pouze to, že jim porozumím. Ztrácet čas babráním se v kurzech algoritmizace v samotném jazyce mi přijde hloupé.

Jak už jsem psal v předešlé diskusi - stojím si za jazyky stejně jednoduchými na naučení jako je Pascal. Nemám ho sice moc rád, ale líbí se mi, že sám o sobě prakticky nic neumí, dá se celý vysvětlit za pár hodin a je snadno čitelný. Ponechám stranou rozšířené a zavedené omyly jako že je v něm těžší prasit (by me zajímalo, kdo tohle první vyslovil ) - to je totiž blbost, prasit se dá všude.

Na druhou stranu uznávám, že by bylo lepší učit algoritmizaci na jazyce, který je stejně jednoduchý jako Pascal a jako bonus je dokonce použitelný v praxi (což se o Pascalu moc říct nedá) - tady je jediný kandidát, který mě napadá, Python. Možná i Ruby, ale v tom jsem nikdy nedělal (ale chystám se - líbí se mi na něm pár věcí, které v Pythonu nejsou - žel to platí i naopak).

Úplně nejradši bych se učil třeba na Scheme, ale to je spíš zbožné přání Lispovské jazyky mě naprosto fascinují (i když v nich neumím ).

[Martin]

Jen tak mimochodem, abych využil příležitosti - co by mi místní Lispeři/Schemeři doporučili jako nejlepší studijní materiál pro Scheme? Celkem sympaticky na mě působí "Teach Yourself Scheme In Fixnum Days", ale rád bych nějakou publikaci, která se nezabývá pouze syntaxí a jazykem, ale obsahuje i nějaké základy samotného funkcionálního programování. Dík za tipy

[Tom.š Ze.le.in]

Nejsem schemer, ale často se doporučuje třeba: Structure and interpretation of computer programs (učebnice k úvodnímu kurzu na MIT - mimochodem slyšel jsem že ten kurz má přejít ze Scheme na Javu), a Little Schemer/Seasoned Schemer (útlé knížečky psané zajímavým stylem, online asi nejsou).

[Martin Stiborský]

No moje první "programování" bylo v PHP, byl jsem tehdá na sebe pyšný jak to hezky jde, ale po zjištění že umím vlastně prd a ještě k tomu je to PHPprd mi sklapnul hřebínek.

Potom dlouho nic, pak přišel Linux, s ním Python, bash, no, a takhle to zůstalo. Ale po diskuzích tohoto typu, jsem si pořídil knihu, je to kniha o jazyku C, od Kernighana a Ritche. Chci se C naučit a dobře ho umět .. snad to půjde ..

Jinak jelikož bych fakt rád někdy pracoval jako vývojář, tak jenom Python rozhodně stačit nebude .. takže zkusím C a pak půjdu dál ..

Jsem lamka, ještě k tomu ovlivněná Pythonem, ale stejně bych ten Python začátečníkovi doporučil ...

[robo]

Tak ja som zacal s BASICom na PMD 85 :)), potom qBasic, Pascal a dBase v DOS, neskor PHP, VisualBasic (Win) a teraz Python, C++. Odporucal by som zacat s Pascalom.

[Trained.Monkey]

Zalezi jak je clovek stary. Ale asi Beanshell, je velmi jednoduchy a umoznuje plynule prejit na javu.

[thingie]

Žádný.

[Bluebear]

Amen. Právě jsem se to chystal napsat.

[Pavel Stehule]

co treba Karel? Lisp ani nahodou. Zacinal jsem s Pascalem a C-kem zaroven. A do toho ZX Basic a Assembler. Proste pred 18 lety si clovek jazyk nevybiral a bral co bylo . Na to jaky bude clovek programator nema jazyk vubec zadny vliv. Budto to jde, nebo ne. A jakmile clovek prokoukne, tak v podstate rozdily mezi proceduralnimi jazyky mizi. A jestli nejaky jsou, tak maji ciste esteticky vyznam. Proste nekdo radsi dlouhovlase blondynky a druhej tmavovlasky na jezka, a vsechny jsou krasny. Byla jina doba. Manual k TurboPascalskym unitam mel 80 stranek, takze je clovek zvladl docela rychle (nekolik desitek hodin). Moderni knihovny jsou celkem dobre navrzene (zacalo to Javou, C# nebo Python) nicmene jsou mnohem komplexnejsi. Coz odrazuje od uceni a ulehcuje praxi.

[Bluebear]

Karel je *H*N*U*S*, dámy prosím prominou.

Týrání Karlem jsem zažil jeden celý rok v kroužku programování. Škemrali jsme o Basic!

[Pavel Křivánek]

Není to jednoduchá otázka. Možná něco vizuálně laděného jako Scratch.

Třeba by ideální cesta byla nějaký podobný "dětský" jazyk následovaný paralelní výukou velmi jednoduchého didaktického Assembleru (podobného Z80), nějakého funkcionálního jazyka (Haskell/Scheme) a nějakého objektového jazyka s inkrementálním prostředím. Pak by se člověk asi mohl snadno naučit pracovat s dalšími jazyky a byl by méně náchylný na přenášení zlozvyků.

Občas mám pocit, že skutečně programovat jsem se naučil až ve Smalltalku

[Bluebear]

Nejsem si jist, jestli něco takového jako dětský jazyk lze správně udělat - všechny, co jsem zatím viděl, byly úplně nanic - ale velmi se mi líbí myšlenka začít assemblerem a funkcionálním prostředím, ale pokračoval bych nejdřív aspoň zhruba procedurálně a pak teprve objekty.

Jinak, podle mého názoru objektové programování má stejnou nezdravou přitažlivost jako procedurální, nebo jako jakákoli jiná šablona myšlení. Člověk v ní může uváznout a pak ji bez přemýšlení napasuje na všechno, ať už se to hodí nebo ne. Kolik už jsem viděl programů doprasených k nepoznání jen proto, že autor neuměl použít jiné paradigma než třída-objekt-instance-metoda.

[Bluebear]

Kolik už jsem viděl programů doprasených k nepoznání jen proto, že autor neuměl použít jiné paradigma než třída-objekt-instance-metoda.

Zapomněl jsem dodat: a kolik jsem jich napsal...

[Pavel Křivánek]

Nejsem si jist, jestli něco takového jako dětský jazyk lze správně udělat - všechny, co jsem zatím viděl, byly úplně nanic

Najít něco rozumného je opravdu problém. Ale jako krátce používaná hračka třeba pro pochopení základních řídících struktur to může být užitečné.

ale velmi se mi líbí myšlenka začít assemblerem a funkcionálním prostředím, ale pokračoval bych nejdřív aspoň zhruba procedurálně a pak teprve objekty. Jinak, podle mého názoru objektové programování má stejnou nezdravou přitažlivost jako procedurální, nebo jako jakákoli jiná šablona myšlení. Člověk v ní může uváznout a pak ji bez přemýšlení napasuje na všechno, ať už se to hodí nebo ne. Kolik už jsem viděl programů doprasených k nepoznání jen proto, že autor neuměl použít jiné paradigma než třída-objekt-instance-metoda.

Základy procedurálního programování člověk pochytí i v tom Assembleru. On bude obrovský rozdíl mezi tím, když se člověk naučí procedurální jazyk a pak na něm bude stavět OOP, nebo když začne třeba Selfem. Hlavní přednost bych ale viděl v tom, že se naučí orientovat v obrovském a přitom v základech velmi jednoduchém a logickém systému, odpoutá se špagetových zdrojáků, bude nucen více číst a orientovat se v kódu jiných než sám psát vlastní apod. To jsou dovednosti k nezaplacení.

[Miloslav Ponkrác]

Kolik už jsem viděl programů doprasených k nepoznání jen proto, že autor neuměl použít jiné paradigma než třída-objekt-instance-metoda.

Problém je, že na toto téma si nabili ústa i odborníci, což třeba Javisté nevidí. Mnohým odborníkům je jiště známo jméno pana Kravala, vyhlášeného odborníka na OOP a proslulého machra na OOP, který učí mnoho profesionálů. Kdysi jsem se hlásil do jedné firmy a tak mi u pohovoru vyprávěli, jak s tímto pánem spolupracovali a on navrhl (samozřejmě striktně OOP) a udělal analýzu. Po dvou letech práce se musel projekt zahodit pro nepřekonatelnou pomalost běhu - ač perfektně a odborníkem na OOP navrženou strukturou.

Já jsem naopak zastánce toho, aby vše co učíte jste si pochválili i zkritizovali. Naučte se vnímat, že cokoli, jakýkoli jazyk, metodika, i OOP má své plusy, ale i MÍNUSY. Také proto nesouhlasím s tím, že OOP má být první a jediné.

Nezatracuji OOP, haním jen proto, abych vyrovnal ty lživé výroky o nepostradatelnosti a nutnosti OOP jako numero uno pro začátky programování.

[vend]

Jedině FORTRAN 68

Nejlépe na EC 1010 nebo Tesla 200

[Penguin_007]

Kdybych si mohl vybrat dnes, tak jdu do Pythonu a Lisp/Scheme.

Jinak mým prvním jazykem, vyjma malinkých základů BASICu na Sinclairu, byl Forth a Assembler na tomtéž počítači. Teprve později jsem přišel na Pascal a Fortran, v Pascalu dodnes udržuji a dále rozvíjím pojekty, které mají dohromady cca 250 000 řádek. C/C++ a další jazyky se nebalovaly teprve kolem přelomu tisíciletí.

Trochu hardcore bych možná někomu doporučil, aby se naučil myslet Scheme a aby se naučil pracovat na hodně nízké úrovni, tak Forth (proti tomu je C/C++ hodně vysokoúrovňový jazyk ).

[zippy]

no. zacinajuci programator stoji pred problemom: Mam ten algoritmus v hlave - ale ako donutit pocitac, aby ho vykonal? z toho mi vyjde nejaky NEobjektovy program. jazyk. C? ako zacinajuci programator neviem nic o pointeroch, dynamickom programovani, alokacii. Pascal? to vyzera najlepsia volba. Clovek sa nauci algoritmicky mysliet, ako ten algoritmus prepisat... presiel som Pascalom, assemblerom, C, C++, Javou, Lisp, Prolog, HTML a trosku PHP. a poradil by som ten pascal.