Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: bubavanek 14. 10. 2010, 18:41:09
-
Ahoj, chtěl bych se seznámit do hloubky s programovacími jazyky. Tudíž se vás ptám, jestli byste mi mohli poradit v čem začít. A jestli by pro mě jako pro začátečníka bylo výhodnější si nainstalovat Linux. Plánuji si samozřejmě koupit nějakou tu literaturu pro začátečníky, ale zajímalo by mě zda-li byste mi nějakou mohli doporučit. Tak trochu jsem se zaobíral PHP, HTML, CSS (velmi okrajově), Delphi samozřejmě ve škole, Visual Basic trošku.
Budu rád za jakoukoliv objektivní radu.
Předem děkuji.
-
Linux imho nepotřebuješ.... zatim. Jakej jazyk je taky dosti sporny, jen ne to php. Osobně bych na učení algoritmů doporučil pascal, na učení objektovosti třeba javu, na to abys něco napsal rychle a přitom furt hezky python, na to abys zjistil něco o vnitřnostech počítače tak C, abys ses naučil něco z funkcionálních paradigmat tak třeba javascript (ale v tom se dá dosti prasit, čili ten rozhodně ne na začátku).... IMHO začni s libovolnym z tědle jazyků a časem vždy nějakej přiber...
-
No je mi jasný že vše se nedá dělat jen v jednom a každý je dobrý na něco. Počítám že nejspíš začnu s Pythonem, většina lidí se přiklání k němu, jako jazyku pro nováčky. Děkuji za odpověď. Jinak přemýšlím, že bych šel studovat Informatiku, tak by mě ještě zajímalo kdo jste co kde vystudoval, či je zatím samostudium.
-
Počítám že nejspíš začnu s Pythonem, většina lidí se přiklání k němu, jako jazyku pro nováčky.
Jestli se přikláníš k Pythonu, tak se zkus podívat na jazyk Boo (http://boo.codehaus.org/) - u něj je veliká výhoda, že běží nad .NET frameworkem, takže se zároveň naučíš std. knihovnu, jejíž znalost potom můžeš zpeněžit (C#). Znalost Pythonní std. knihovny se zpeněžuje podstatně hůř.
-
Díky za rady ;) :)
-
Ještě jsem se chtěl zeptat na nějakou ,,povinnou,, literaturu. Pokud byste něco věděli
-
Pis si -
Pavel Herout
Ucebnice jazyka C
KOPP, 1992
-
Take zdravim.
Pokud bych Vam mel doporucit z vlastni zkusenosti, tak zacnete s C. Muzete i s C++, ale na tridy a na nich zalozenych abstrakcich se vrhnete az si osvojite zaklady jazyka, algoritmizace, funkci a teoreticke zaklady OOP (objektove orientovane programovani). Ucebnice Jazyka C od Pavla Herouta je vyborny pruvodce timto jazykem a pro C++ je dobra kniha C++ programovaci jazyk od pana Bjarneho Stroustrupa (nakladatelstvi Ben, 1997 ). Uvidite, ze je to mocny nastroj.
Muzete zkusit i Pascal. rozhodne bych Vam nedoporucoval se ze zacatku zabyvat jazyky jako je java, C#, Python a pod, protoze tyto jazyky vysi urovne uz pred programatorem skryvaji nektera uskali programovani (sprava pameti, kontroluji rozsah poli, atpd..) coz by mohlo vest ke spatnym, nebo nevhodnym navykum.
Je zajimave jak dlouho pretrvavaji nektere myty, jako napr. ten, ze Linux je platforma vhodna jen pro programatory. Stejne jako muzete pohodlne pouzivat Linux na Desktopu, treba v kanclu, nebo doma, muzete pohodlne programovat treba i na Windows: pokud chcete open Source vyvojove prostredi, zkuste se poohlednou po programu Code::Block, nebo wxDev-C++ (pro C/C++). Myslim, ze i MS nabizi nejakou (pravdepodobne silne orezanou) verzi Visual Studia pro nekomercni pouziti...
-
Je zajimave jak dlouho pretrvavaji nektere myty, jako napr. ten, ze Linux je platforma vhodna jen pro programatory.
Imho neni jenom pro programatory, ale na spoustu programatorskych cinnosti je proste Linux tisickrat lepsi, nez cokoliv jineho. "aptitude install sun-java6-jdk maven netbeans postgresql tomcat...." a jede se. Ve windows je to prace na dva dny.
P.S. Priklad je samozrejme trochu zjednoduseny, ale jakozto java developer, ktery je nucen pracovat ve windows, tento system z celeho srdce nenavidim a proklinam.
-
jehovista: no, já zas ve windows na notebooku třeba rozchodím dva monitory a hybernaci, v linuxu nikoli. Každej systém má svoje plus a svoje mínus. Pro C/C++ by zas člověk proklínal linux, protože MS Visual studio imho nemá v IDE konkurenci (byť díky eclipse, emacs apod. je situace daleko lepší než dřív). Trochu nadhledu to chce...
tiger: Souhlasím. POokud se to chce dělat pořádně, tak aspoň nejakej čas na Cčku to chce. Akorát si nejsem jistej, že ze začátku, první co je potřeba je do sebe dostat programovací paradigma, a to jde v čemkoli. A špatné náviky se dají získat i z Cčka
- díky neexistenci objektů (respektive ne zrovna ideální implementaci v C++) se člověk
učí bastlit místo dělání čistýho návrhu.
Osobně myslím, že C/C++ rozhodně ano, a poměrně brzo, ale nevím, jestli bych s ním začínal...
-
jehovista : Jasne, o tom zadna. jen jsem chtel naznacit tu myslenku, ze Linux neni proste nezbytnou podminkou, a ani z nikoho programatora sam o sobe neudela.
-
tiger: Souhlasím. POokud se to chce dělat pořádně, tak aspoň nejakej čas na Cčku to chce. Akorát si nejsem jistej, že ze začátku, první co je potřeba je do sebe dostat programovací paradigma, a to jde v čemkoli. A špatné náviky se dají získat i z Cčka
- díky neexistenci objektů (respektive ne zrovna ideální implementaci v C++) se člověk
učí bastlit místo dělání čistýho návrhu.
Osobně myslím, že C/C++ rozhodně ano, a poměrně brzo, ale nevím, jestli bych s ním začínal...
Myslim, ze pokud bude postupovat od zacatku, je jedno jaky kompilator pouziva. Mezi ANSI C a C++ zas tak markantni rozdily nejsou. Navic je prece v poradku, kdyz se bude hned od zacatku ucit trose te zdrave neduverivosti (ze za nej vsechny problemy nekdo, nebo nejaky nastroj resi). Navic snad se vyhne tomu dneska tolik oblibenemu nutkani pouzivat letdlovou lod na komara (na problem ktery resi par radek v shellu, nebo v main( ) v C, pouzit rovnou moloch v C#, nebo Pythonu) - uz jen proto bych volil C/C++
Teorii se stejne nevyhne - pokud bude chtit jit dal, nez na obligadni "Hello world". Driv ci pozdeji stejne si bude muset zjistit o cem OOP vlastne je... pravdou je, ze spatne navyky muze ziskat i v C/C++, ale je tam taky velmi velka pravdepodobnost, ze s trochou stesti a snahy brzy prijde na jejich nasledky.
C++ NENI objektovy jazyk, presto ze principy OOP podporuje a pracuje s nimi. Je to typovy jazyk - programator v podstate hlane definuje datove typy. Objekty jsou v C++ az konkretni instance trid (s trochou drzosti: hodnoty v pameti). Je jednou veci vytvorit datovou strukturu a definovat k ni mnozinu operaci (datovy typ) a pak ji bez nutnosti do ni jakkoliv zasahovat nebo ji upravovat pouzit na nekolik ruznych aplikaci jen tim, ze ji predam odpovidajici data ( napr. mejme tridu Graficke_udelatko. A hned muzeme vytvorit objekty letadylko, pozadi, zamerovac, exploze, tlacitko...). A kdyz k tomu prictu sablony a moznosti OOP, pak me napadaji takove veci jako jsou treba tovarny na obekty, strategie, a pod... Ale to uz je asi trochu mimo ramec zacatecnika.
-
Na běžné pochopení programování opravdu stačí Pascal (jazyk vyvinut pro výuku programování), z MS projektů bych možná doporučil Visual Basic (pořád je to ještě Basic). Pokud to ale myslíte s programováním vážně, pak rozhodně C a C++. S objekty začít co nejdřív, seznámit se s tím aspoň teoreticky paralelně při výuce jazyka. Jako že prakticky zkoušet programovat běžné algoritmy, jako řazení polí, hledání a podobně, ale vedle toho se seznamovat s tím, co to vlastně ty objekty jsou. A opravdu se připravit na to, že to je hlavně teoretické procvičování, kde než člověk napíše do kódu klíčové slovo class, měl by mít povědomí něco o tom, co to objekt je, mít ale také povědomí aspoň o jazyce UML, aspoň vědět k čemu to je a jak se v tom modelují třídy. Na začátku to může být otrava, ale mnohonásobně se to vrátí. V dnešní době všichni co programují v nějaké Javě, v Pythonu nebo v C++ umí sice vyrobit objekt, ale OOP to není ani náhodou.
Ještě se vrátím k C / C++. Jak psal předchozí diskutující, možná jsou dneska jazyky, které umí řešit správu paměti, a spoustu věcí dělají za programátora, ale přesto je dobré si to vyzkoušet ručně. Vědět, že se program musí umět postarat o přidělené zdroje, musí je umět alokovat, včas uvolňovat, sdílet je tak aby nebyl v konfliktu s ostatními aplikacemi ... a není to jen paměť, byť je to prostředek, který se nejvíc používá. Právě proto. Na tom se nejlépe cvičí správa zdrojů. Když se to člověk nenaučí, pak jeho programy budou alokovat systémové prostředky jako otesánci (soubory, sockety, sdílenou paměť, atd), budou pomalé, těžkopádné a v extrémních situacích budou jako první vypovídat službu.
-
Muzes brat drogy. Muzes hulit travu od rana do rana. Muzes ... co chces. Ale zaprve:
http://www.catb.org/esr/faqs/hacker-howto.html
Zadruhe:
http://catb.org/esr/writings/unix-koans/ten-thousand.html
a za treti - NA LINUX SE VYSER! ;o)) To byla nejlepsi rada, kterou jsem kdy dostal.
Nainstaluj si FreeBSD (dva az tri roky budes brecet, ale ... tezko na cvicisti ...). Nainstaluj si tam ztko. A tam si hraj s Pythonem. Na nejaky .NET ... > .NOT!!!! Java? Proc proboha? Python je super na uceni se programovani. A pokud budes chtit jit fakt uplne k jadru kudla, tak pak je to o Ccku a Assambleru. Je to fakt docela drina naucit se prgat. Ma to neuveritelne mnoho aspektu. Poradne si precti a pochop ten druhy link, co jsem posilal ;o)
Fakt se to vyplati. A na Wydle ... uplne zapomen - to neni pro programatory. Taky zapomen na mys. Nesmysly, ktere nebyly vymysleny pro programovani ale pro lidi, kteri programovat nechteli.
-
C++ NENI objektovy jazyk, presto ze principy OOP podporuje a pracuje s nimi. Je to typovy jazyk - programator v podstate hlane definuje datove typy. Objekty jsou v C++ az konkretni instance trid (s trochou drzosti: hodnoty v pameti). Je jednou veci vytvorit datovou ...
Nechci zabředávat do flame, takže jen poupravím. Nerad bych začátečníkovi radil, aby používal plnohodnotné OOP jazyky (myslím zejména smalltalk), tedy pokud si pro svůj první sexuální zážitek nevybral sadomasochistické praktiky :) Ostatní OOP jazyky se od OOP v C++ zase až tak moc neliší. Pokud bych chtěl jít až do krajnosti, tak v každém jazyce je objekt nějaká kolekce hodnot v paměti ;)
Ty věci, které OOP programátora v C++ omezují mohou naopak hodně pomoci začátečníkovi. Například v tom, že se nebude pokoušet posílat zprávu objektům, které je neumí zpracovat (díky typovosti to překladač zjistí hned). Přitom mu nijak nebudou bránit v pochopení toho, jak se v objektech modeluje svět. Dokonce i taková nutnost, jako vytvářet ke každému flusu rozhraní je spíš přínosem, protože si člověk uvědomí, že něco jako rozhraní existuje (rozhraní je i třeba klika na dveřích, šňura na splachování na WC) a právě typová kontrola zajistí, že nám překladač nedovolí tahat za kliku na dvěří, nebo se snažit otevřít dveře splachováním na záchodě.
Šablony jsou pak určitým kompromisem při návrhu generických algoritmů, kde se typy mohou být velkou přítěží.
-
Fakt se to vyplati. A na Wydle ... uplne zapomen - to neni pro programatory. Taky zapomen na mys. Nesmysly, ktere nebyly vymysleny pro programovani ale pro lidi, kteri programovat nechteli.
Připomíná mi to Červený Trpaslík. K úspěšnému postupu v karieře stačí být disciplinovaný, organizovaný, naprosto oddaný své práci a vždycky mít u sebe tužku.
Výsledek: Naprostý magor, kterým pohrdají všichni, krom lodního papouška. A to jen proto, že žádného nemáme
-
Muzete zkusit i Pascal. rozhodne bych Vam nedoporucoval se ze zacatku zabyvat jazyky jako je java, C#, Python a pod, protoze tyto jazyky vysi urovne uz pred programatorem skryvaji nektera uskali programovani (sprava pameti, kontroluji rozsah poli, atpd..) coz by mohlo vest ke spatnym, nebo nevhodnym navykum.
To mi přijde jako zvláštní názor. Jaké např. špatné návyky přináší jazyk, který obsahuje kontrolu rozsahu polí? Když index přešvyhnu, dojde k výjimce, která jasně říká k čemu a kde došlo (IndexOutOfRangeException na řádku 123 v souboru xyz). U C může dojít v podstatě k čemukoli, včetně toho, že nedojde k ničemu a program normálně funguje (přepíšu data, která už potom nepoužívám, takže na chybu nepřijdu). Nebo přestane fungovat úplně jiná část programu a chudák začátečník ať si láme hlavu, proč...
Správa paměti - no to je fakt, že to se člověk v C# moc nenaučí - ovšem otázka je, proč by se to taky měl učit, když to v C# není potřeba. V C se taky nenaučí práci s registry procesoru a nikomu to nevadí...
-
Správa paměti - no to je fakt, že to se člověk v C# moc nenaučí - ovšem otázka je, proč by se to taky měl učit, když to v C# není potřeba. V C se taky nenaučí práci s registry procesoru a nikomu to nevadí...
Protože paměť je prostředek OS jako každý jiný. Třeba diskový soubor, nebo otevřené spojení, nebo zámek, vlákno. Tyhle prostředky už v GC jazycích automaticky spravovat nelze. V C++ ano.
-
Ze svých zkušeností (nějaký čas jsem to učil) rozhodně nedoporučuji začínat s C.
Naprosto souhlasím s tím, že každý programátor by měl C umět a získat nějaké zkušenosti s low-level programováním, takže určitě C nepřeskakovat. Na druhou stranu, pro opravdového začátečníka je docela "záhul" učit se základy programování (algoritmizace, větvení, smyčky, proměnné / parametry, funkce/procedury) a zároveň současně detaily a zákeřnosti architektury počítačů (paměť a její adresování, zásobník, registry).
Za mých mladých let se s C začínalo až když člověk získal nějaké zkušenosti z BASICu (Pascalu, pokud někdo začínal až ve škole) a trochu si pohrál s asemblerem (nebo alespoň s hw).
-
Suhlasim s predrecnikom: vacsina zaciatocnikov, co vidim na okoli, ma dostatok problemov uchopit uz len zakladnu algoritmizaciu. Pre nich je dolezite pochopit zakladne finty, kedy aky cyklus pouzit, ako stavat funkcie, ako postavit podmienku. Pre nejedneho z nich su uz aj datove typy vec, ktora im sposobuje na uvod potiaze a najradsej by ich ignorovali.
Low-level veci im pridu kontraproduktivne, resp. im stazuju pristup.
Vsak kopa ludi zacinala tiez blahej pamati v 80. rokoch v BASICu, kde ziadne low level veci neboli, a ludia sa to prevazne ucili az potom, co zvladli zaklady.
Ja by som skusil Python (to hovorim ako clovek, co bdie a zaspava s Javou)
-
Ja by som skusil Python (to hovorim ako clovek, co bdie a zaspava s Javou)
S tím pythonem nevím. je fakt, že člověk neposkrvění programováním nebude zápasit s odsazováním na každém řádku, na druhou stranu může mít později problém zvyknout si na to, že většina jazyků strukturu nehledá v bílých znacích, ale zpravidla v blocích uvozených nějakými závorkami (ať už symbolem, nebo klíčovým slovem)
-
Samozrejme, ze jsem si delal zadek ;o)
Pouzivat kazdy muze co chce - vcetne Cerveneho trpaslika, kde se to vypousti z hlavy.
Jen dle meho nazoru jsou windows malicko nepritulne v tom, ze vsechno kvalitni je placene (fajn - tak to byt muze ...) a nema to dostupne zdrojove kody, ktere nekdy staci oeditovat tak, ze zakomentujeme jeden radek a funguje to.
Programovaci jazyk je jen nastroj - dulezite jsou myslenky - co programuju - proc to delam a tak dale. Cili bych zacal teoretickou rovinou - kdy pouzit for, kdy while, kdyz pole, kdy hash a tak dale az k tomu, co je to trida, objekt ...
Podle me je nejdulezitejsi to neustale zkouset. Co to dela, jak to dela ... Ted jsem resil napriklad to, ze v BSD, Linuxu a Win jsou ruzne naimplementovane traceroute ... A pak si debugujte sit, kdy dva velci provideri pravdepodobne "prepajali" ve stejny den ... Firewally na BSD jsou nastavene na ICMP echo ... Linux ma ICMP volani jine pri spusteni traceroute.
A to je taky programovani, jestli se nepletu. Programovani je hrani si s kostickama. Muzou to byt mikrokosticky Assambleru nebo to muzou byt makro kosticky Javy ... stejne jde jen o to, co clovek skutecne chce a co ma byt vysledek jeho tvorby.
-
Jen dle meho nazoru jsou windows malicko nepritulne v tom, ze vsechno kvalitni je placene (fajn - tak to byt muze ...) a nema to dostupne zdrojove kody, ktere nekdy staci oeditovat tak, ze zakomentujeme jeden radek a funguje to.
Ty Express edice jsou zdarma. Většinou jsou určeny pro začínající programátory
(http://www.microsoft.com/express/Windows/ - tady si můžete vybrat Basic, C++ a C#)
-
Podlesh: tys asi v C moc nedělal, když ho dáváš do souvislosti s různým adresováním a zásobník a registry.... IMHO pro začátečníka jsou v C dva problémy a to práce s řetězci a horší možnosti ladění.
Pro výuku ho považuju za vhodnější než Basic či VisualBasic. Jelikož jsem prošel ve svých mladých letech vývojem Basic - VisualBasic - C++ (pascal až poté ve škole), tak myslím, že to tvrzení má nějakou relevanci. Těch zlozvyků, co jsem se musel z Basicu odnaučit....
Tiger, novačisko: Psát objewktově se dá i v assembleru. Jde jen o to, jak velkej support ten danej jazyk poskytne. C++ proti modernějším jazykům v tom moc dobře není a proto ho osobně pro výuku objektového programování nepovažuju za příliš vhodný - netlačí člověka k správnému způsobu psaní, a některé běžně používané obraty se tam nechovaj standardně
(např. interface).
Čím víc nad tím přemýšlím, tak bych začal algoritmizací v pascalu či pythonu, přes pokročilejší algoritmizaci v C a pak přešel na nějakej objektovej jazyk (Java, C#).
No a do toho nějakej kus javascriptu, pokud člověk není takovej masochista, že si začne s lispem/schemem...
-
Muzete zkusit i Pascal. rozhodne bych Vam nedoporucoval se ze zacatku zabyvat jazyky jako je java, C#, Python a pod, protoze tyto jazyky vysi urovne uz pred programatorem skryvaji nektera uskali programovani (sprava pameti, kontroluji rozsah poli, atpd..) coz by mohlo vest ke spatnym, nebo nevhodnym navykum.
To mi přijde jako zvláštní názor. Jaké např. špatné návyky přináší jazyk, který obsahuje kontrolu rozsahu polí? Když index přešvyhnu, dojde k výjimce, která jasně říká k čemu a kde došlo (IndexOutOfRangeException na řádku 123 v souboru xyz). U C může dojít v podstatě k čemukoli, včetně toho, že nedojde k ničemu a program normálně funguje (přepíšu data, která už potom nepoužívám, takže na chybu nepřijdu). Nebo přestane fungovat úplně jiná část programu a chudák začátečník ať si láme hlavu, proč...
Jenze prave proto, ze je to jazyk nizsi urovne, tak je mnohem vetsi pravdepodobnost, ze duvod chybneho chovani programu snaze najde - Jazyk pred nim nic neskryva a nedela nic sam. Navic nikde neni psano, ze naucit se programovat je neco jednoducheho a bez obtizi.
Správa paměti - no to je fakt, že to se člověk v C# moc nenaučí - ovšem otázka je, proč by se to taky měl učit, když to v C# není potřeba. V C se taky nenaučí práci s registry procesoru a nikomu to nevadí...
A to je prave ono - presne jak uz tu myslenku nekolikrat rozvedl a upresnil kolega Ondra. Ono to podle toho taky tak potom vypada. Clovek si lejhce zvykne na to, ze spravu zdroju a podobne lahudky (treba zminovanou kontrolu indexu poli, kterou se tolik ohani zastanci C#) za nej dela jazyk. Za prve ty techniky nejsou uplne 100% (automaticka sprava pameti obcas uvolni obekt, ktery uvolnen byt nema, atpd...) a za druhe pokud se od zacatku nauci si hlidat zdroje (a jine veci) bude mit (snad) tendence psat o dost usporneji a efektivneji. No a za treti, o delu na komara jsem uz mluvil....
-
Jenze prave proto, ze je to jazyk nizsi urovne, tak je mnohem vetsi pravdepodobnost, ze duvod chybneho chovani programu snaze najde
"Snaze najde"? Kdyz nekde v ramci programu pretecu prez hranice pole, tak v C v nejlepsim pripade program spadne - tzn. dostanu core dump. V C# dostanu hlasku "v souboru xyz na radce abc pretekl index pole". Nechapu, co je snazsiho na hledani chyby v coredumpu... A to coredump je jeste ten nejlepsi moznej zpusob, jak se chyba projevi.
Clovek si lejhce zvykne na to, ze spravu zdroju a podobne lahudky [...] za nej dela jazyk.
No a?
V C si zase člověk snadno zvykne na to, že se nemusí zamýšlet nad tím, do kterých registrů se co ukládá. A to je jako špatně?
Dneska se prostě vyvíjí v jazycích, které mají GC a podobná usnadnění. A když ho nemají, tak se tam dodělá poloautomatický GC (C++, Objective C). Není důvod se (obzvláště na úplném začátku) prudit s něčím, co člověk v praxi stejně nebude potřebovat.
-
No co jsem si tak přečetl, tak je pravděpodobně jedno v čem začnu (pokud to nebudou vyšší jazyky, ne který bych měl mít nějaké ty znalosti) stejně si budu muset projít minimálně vším. S tím jsem počítal. Takže první možnost je tedy asi C, Python či Pascal.
Všem moc děkuji, jak za názor, tak za odkazy. Pokud byste chtěli něco dodat budu jen rád.
-
C++ proti modernějším jazykům v tom moc dobře není a proto ho osobně pro výuku objektového programování nepovažuju za příliš vhodný - netlačí člověka k správnému způsobu psaní, a některé běžně používané obraty se tam nechovaj standardně
(např. interface).
chemem...
Které moderní jazyky jste zde měl na mysli?
-
Ahoj, chtěl bych se seznámit do hloubky s programovacími jazyky. Tudíž se vás ptám, jestli byste mi mohli poradit v čem začít. A jestli by pro mě jako pro začátečníka bylo výhodnější si nainstalovat Linux. Plánuji si samozřejmě koupit nějakou tu literaturu pro začátečníky, ale zajímalo by mě zda-li byste mi nějakou mohli doporučit. Tak trochu jsem se zaobíral PHP, HTML, CSS (velmi okrajově), Delphi samozřejmě ve škole, Visual Basic trošku.
Budu rád za jakoukoliv objektivní radu.
Předem děkuji.
Java, protože je to čistý objektový jazyk. Na naučení objektového programování je podle mě ze současných dostupných jazyků nejlepší. :)
-
Ahoj, chtěl bych se seznámit do hloubky s programovacími jazyky. Tudíž se vás ptám, jestli byste mi mohli poradit v čem začít. A jestli by pro mě jako pro začátečníka bylo výhodnější si nainstalovat Linux. Plánuji si samozřejmě koupit nějakou tu literaturu pro začátečníky, ale zajímalo by mě zda-li byste mi nějakou mohli doporučit. Tak trochu jsem se zaobíral PHP, HTML, CSS (velmi okrajově), Delphi samozřejmě ve škole, Visual Basic trošku.
Budu rád za jakoukoliv objektivní radu.
Předem děkuji.
Java, protože je to čistý objektový jazyk. Na naučení objektového programování je podle mě ze současných dostupných jazyků nejlepší. :)
Ještě jsem viděl, že vám tu doporučují na učení jazyk C++. To můžu silně nedoporučit, protože v C++ se často stává, že vám kompilátor nahlásí chybu někde úplně jinde než ve skutečnosti je - třeba v úplně jiném souboru. Sám mám C++ rád, ale na naučení programování je podle mě jeden z nejméně vhodných. To už je opravdu mnohem lepší Pascal/Delphi.
-
Já začal s C# a přijde mi to celkem srozumitelný a lehčí jak Pascal. Ne že bych uměl .NET 4.0, ale dost věcí z .NET 1.0 (základy) bych dal.
Ale v IT bych asi začal jako tester. Co myslíte? Po mě na testech chtěj akorát Excel, klikat do aplikace a upravit si jednořádkový SELECT. Když se k tomu doučím Bash a základy Unixu, tak doufám, že by mě mohli někde vzít jako junior testera. A ne jenom na občanou brigádu za 70 na hodinu :'(.
C++ mi přijde nejtěžší, pořád mi všechno padalo i na jednoduchých věcech.
-
Nepatří to sem, ale přece:
Díky za ty odkazy, David Strejcy.
-
Jestli si to bude číst nějaký začáteční tak bych napsal pár bodů:
1) Pascal NE! To stejné, co se naučíte v pascalu, se třeba v C naučíte taky a z C vychází prakticky všechny dnešní prog. jazyky. Při učení programování se člověk chtě nechtě učí i samotný jazyk a pascal můžete následně klidně zapomenout. Je to tedy zbytečná práce.
2) C na začátek určitě dobré a jeho znalost se určitě bude hodit.
3) Java - Skvělý jazyk (nejen) pro začátečníka. Možná bych jej doporučil ze všeho nejvíce. Ale je nutné si uvědomovat existenci GC, že se ta paměť musí odalokovat, jen to dělá "jazyk" automaticky. Java vede k psaní čistého kódu, což je pro začátečníka docela užitečné.
4) Python na výuku taky hodně dobrý jazyk. Jen si člověk musí krom GC uvědomovat i beztypovost, že tam ty typy jsou, ale jazyk je řeší. Ale to asi člověk časem pochopí sám.
5) C++ NE! Nejsložitější jazyk co snad existuje, je příliš obecný a nevede člověka (narozdíl třeba od javy) k čistému programování.
6) Perl také ne - to je jazyk pro zkušené programátory, kteří ví, co píší. (proto ho taky spousta lidí odsuzuje, protože v něm píší prasárny)
7) C# - nemám osobní zkušenosti
8) PHP také ne. To vás naučí leda špatné návyky
Jak jste si asi všimli vyzvedávám jazyky, co člověka tlačí do dobrého coding stylu. Pokud se toto nenaučíte a programujete jen pro sebe, tak maximálně po půl roce svůj program nepochopíte, ale v kolektivu vás poženou a budete se muset všechno přeučovat.
-
2) C na začátek určitě dobré a jeho znalost se určitě bude hodit.
5) C++ NE! Nejsložitější jazyk co snad existuje, je příliš obecný a nevede člověka (narozdíl třeba od javy) k čistému programování.
S Javou bych pro výuku souhlasil, to je dobrý kompromis, s výhradou k GC a k nemožnosti vytvářet destruktory nebo objekty, které se sami likviduji v okamžiku kdy končí jejich platnost (tedy rychleji, než to dělá GC). Bohužel, tohle je vlastnost Javy, která se na první pohled zdá, že je bezvýznamná, ale pokud někdo hojně využívá destruktorů v C++ bude si v Javě připadat jako bez rukou a nohou.
Cituju oba body, protože bych je prohodil. Čisté C rozhodně víc svádí k prasárnám, než C++.
Coding style se dá naučit nezávisle na jazyku a je to čistě věc osobní disciplíny. Prasit se dá i ta Java. Viz mé počátky v Javě.
-
1. volitelně Pascal a pak Object Pascal
2. C a pak C++
3. Pak i třeba Javu, nebo C#
Lidi, kteří se začali nejprve učit Javu a pak C#, už se nikdy nedokázali naučit napsat pořádný program v pointerovém jazyku. Opačně to šlo.
Pointery vychovávají schopné programátory, kteří skutečně ví, co jejich kód vlastně dělá. I když mě za to asi příznivci Javy sežerou:-)
-
Jenze prave proto, ze je to jazyk nizsi urovne, tak je mnohem vetsi pravdepodobnost, ze duvod chybneho chovani programu snaze najde
"Snaze najde"? Kdyz nekde v ramci programu pretecu prez hranice pole, tak v C v nejlepsim pripade program spadne - tzn. dostanu core dump. V C# dostanu hlasku "v souboru xyz na radce abc pretekl index pole". Nechapu, co je snazsiho na hledani chyby v coredumpu... A to coredump je jeste ten nejlepsi moznej zpusob, jak se chyba projevi.
Ano, snaze najde. Hlaska "v modulu/souboru xyc doslo k preteceni indexu pole", sice vypada docela pekne ale jeji uzitecnost je minimalni (mozna v pripade, ze jste omylem zamenil operatory). V pripade kdy pouzivate dynamicke struktury a pole muzete byt pekne v ... Coredump vam takovou hezkou halsku asi nevypise, ale bude alespon obsahovat stav aplikace a pokud mozno i kontext ve kterem doslo owerloadingu.
A co kdyz vam selze sprava pameti - i to se stava, a neni to nic zas tak vyjmecneho, z duvodu, ktere zna jen on? V C/C++ pokud to nesprasi programator k nicemu takovemu by dojit nemelo. Jeste jednou - pokud to neprasi programator.
Navic pokud se Vam straci zdroje v C/C++ kodu, je chyba vetsinou odhalitelna primo v kodu - nejsou tam zadne tajuplne zasahy a invence ze strany kompilatoru....
Clovek si lejhce zvykne na to, ze spravu zdroju a podobne lahudky [...] za nej dela jazyk.
No a?
V C si zase člověk snadno zvykne na to, že se nemusí zamýšlet nad tím, do kterých registrů se co ukládá. A to je jako špatně?
Dneska se prostě vyvíjí v jazycích, které mají GC a podobná usnadnění. A když ho nemají, tak se tam dodělá poloautomatický GC (C++, Objective C). Není důvod se (obzvláště na úplném začátku) prudit s něčím, co člověk v praxi stejně nebude potřebovat.
Jenze o tom to asi je. Nesouhlasim s nazorem, ze vse co se dnes dela je jaksi automaticky lepsi - to ani omylem. Je docela nesmysl tvrdit, ze znalosti a zkusenosti se spravou zdroju nebude zacinajici programator nikdy potrebovat - presne tento postoj vede pouze k tem typum programu, jake se v Pythonu, nebo C# pisi - zbytecne molochy resici ulohy, ktere by shellscript, nebo program v C/C++ zvladl v polovicni rezii, jen proto, aby byla programatorovy poskytnuta iluze, ze se muze oprit o funkcnosti, jejich spolehlivost je asi na stejne urovni, jako spolehlivost tydeni predpovedi pocasi. Tohle je lepsi? Ja tvrdim, ze ani omylem...
Java, C# a Python - na to by mel byt zbrojni pas....
-
Pointery vychovávají schopné programátory, kteří skutečně ví, co jejich kód vlastně dělá. I když mě za to asi příznivci Javy sežerou:-)
+100 naprosty souhlas.
-
Všechno co tady lidi napsali jsou subjektivní věci a nemá moc smysl se podle toho řídit. Není možné obecně říct jestli je lepší začít s jednoduchým jazykem a potom přejít na složitější. To záleží na tom, co komu vyhovuje.
Já bych doporučil nejdřív začít se základními algoritmy a datovými strukturami. Programovací jazyk není až tak podstatný a vybíral bych si podle množství a kvality dostupných materiálů a ne podle toho co je zrovna in nebo co kdo radí jako zaručený postup.
-
Nepatří to sem, ale přece:
Díky za ty odkazy, David Strejcy.
:o))) Sice jako v kazdem programu i tady je chyba (nejsem David StrejcY ale David Strejci ;o))) Tvrdej jsem jak blazen to je jasny ;o) A pro vsechny, kteri maj radi UNIX (Live Free Or Die) - fakt doporucuju si precist uplne vsechny koany zde:
http://catb.org/esr/writings/unix-koans/
Je to starsi, lec platne cteni ;o) (je to starsi, ale platny kod {kdyz Luk Skywalker leti na Endor a Darth Vader se pta, jestli maji platny kod ;o))})
Je to i v The Art of Unix Programming - z toho jsem si odnesl tu nejdulezitejsi vec a myslim, ze je to i tady do diskuze platne ;o) - NIC NEOPTIMALIZOVAT!!!!!!!!!! - funguje to v Pythonu? Fakt to dela to, co chces? Pak si radsi koupim rack serveru (cca pul milionu), nez abych platil pul roku optimalizatora, ktery to bude prevadet do Ccka - proc? Proc proboha? Zaprve tim ziskam to, ze mam pul roku volneho cloveka a za druhe ... Python neni zas az tak pomaly ... Stroje to spocitaj. ;o)
-
No tak jsem přehodnotil své stanovisko, asi začnu s Cečkem, prozatím jsem našel na internetu lepší dokumentaci.
Moc vám všem děkuji
-
novacisko:
Které moderní jazyky jste zde měl na mysli?
Např. Java, C#, Delphi, dokonce i blbý php. Všechny tydle jazyky např. podporují interfacy, které se sice dají V C++ emulovat vícenásobnou dědičností, někdy to ale vyžaduje virtuální dědičnost a to ne vždy jde (např. u interfaců z cizí knihovny).
Další věc, která v C++ není jsou např. anonymní funkce, které se používají jako handlery, s member pointery taky není úplně ideální práce atd... Není to samozřejmě nic, co by nešlo obejít, ale objektově se dá psát i v assembleru, ale v jiných jazycích má člověk víc předpřipravených programátorských idiomů.
A co kdyz vam selze sprava pameti - i to se stava, a neni to nic zas tak vyjmecneho, z duvodu, ktere zna jen on?
Co to znamená selže správa paměti? Tobě se jako v javě stalo, že ti něco alokátor odalokoval, když neměl???
V C/C++ pokud to nesprasi programator k nicemu takovemu by dojit nemelo. Jeste jednou - pokud to neprasi programator.
Jenže to je právě to o čem mluvíme. Pokud se člověk učí programovat, tak dělá chyby. Takže na učení je vhodnej jazyk, kterej mu jasně a srozumitelně řekne kde je chyba. To C není - např. chyba v mezích pole se projeví jen tím, že se přepíše hodnota nějaké jiné proměnné a program běží dál....
Další nevýhoda C je v tom, že je to velmi výrazově bohatý jazyk. Což ale vede k těžko odhalitelným chybám, púamatuju si, jak jsem kdysi asi den ladil to, že místo
(*c)++ jsem napsal *c++. Skončilo to přepsáním CMOSKY a nefunkčním tátovým počítačem :-).
Jinak já netvrdím, že ty všechny výhody, které C má (že dělá jen to, co člověk chce) nejsou pro učení podstatné. IMHO každej programátor by měl někdy v takovém jazyku psát. Akorát nejsem přesvědčen, že (obzvlášť pro samostudium, kde Ti tu chybu nikdo nenajde) je vhodné s ním začínat.
Nicméně po nějaké průpravě s Delphi a Visual basicem to asi už jde....
-
novacisko:
Které moderní jazyky jste zde měl na mysli?
Např. Java, C#, Delphi, dokonce i blbý php. Všechny tydle jazyky např. podporují interfacy, které se sice dají V C++ emulovat vícenásobnou dědičností, někdy to ale vyžaduje virtuální dědičnost a to ne vždy jde (např. u interfaců z cizí knihovny).
Další věc, která v C++ není jsou např. anonymní funkce, které se používají jako handlery, s member pointery taky není úplně ideální práce atd... Není to samozřejmě nic, co by nešlo obejít, ale objektově se dá psát i v assembleru, ale v jiných jazycích má člověk víc předpřipravených programátorských idio...
Ja tedy nevim, ale ja jsem interfaci bral jako emulaci neexistujici vicenasobne dedicnosti, a to z implementacnich duvodu. C++ prave ma pravou vicenasobnou dedicnost a vsichni znaji jeji omezeni. To ze do toho pletete virtualni dedicnost spis ukazuje, ze varite z vody. Objektove programovani ve skutecnosti zadne interfacy nema, a vicenasobna dedicnost ma tak nejak blize k OOP nez interfacy. Interace je popis protokolu komunikace s objektem a ten lze popsat jak interfacem tak abstraktni tridou v C++
Anonymni funkce lze vzdycky nahradit neanonymni. 100% nahrada.
-
Anonymni funkce lze nahradit neanonymnimi? Ano, i v assembleru lze psát objektově. Bohužel
1) funkce se definuje jinde než se používá, tzn. kód je hůře čitelný
2) namespace se zaplácává zbytečnejma identifikátora a tím např. stěžuje orientaci v kódu pomocí automatizovanejch nástrojů, zapleveluje automaticky generovanou dokumentaci etc...
---
ad interfacy: Mám knihovnu, ve které je interface IA a IB poděděné z IA. Implementuju objekt A implementující IA a jeho potomka B implementujícího IB. Přestože objekt B má všechny metody interfacu IA, C++ kompilátor zařve, že mu schází všechny metody IA, poděděné skrze IB.
Proto pomocí vícenásobné dědičnosti v podání C++ neimplementují vše, co nabízejí jiné jazyky v podobě interfaců.
Řešit to lze pomocí virtuální dědičnosti, ale
1) knihovna, ve které mám ty interfacy nemusí být moje a tedy nemusím mít možnost ji upavovat
2) i pokud je knihovna moje, tak proč bych musel při návrhů interfaců přemýšlet o tom, jestli se někdy budou nebo nebuou účastnit diamantové dědičnosti? To je čistě záležitost implementace a proto do návrhu interfaců nepatří.
3) Řešit to celé tím, že všechny interfacy budou děděné virtuálně taktéž není řešením, neboť hlubší virtuální dědičnost má velké nároky na výkon.
prave ma pravou vicenasobnou dedicnost
Ano, C++ má pravou vícenásobnou dědičnost. Bohužel není v praxi příliš použitelná.
Jediné, co v C++ odpovídá vícenásobné dědičnosti tak, jak ji chápe OOP je vícenásobná virtuální dědičnost.A ta je natolik paměťově i časově náročná, že se používá minimálně.
Běžně užívaná prostá vvícenásobná dědičnost se již chová jinak, než by člověk čekal: je to něco mezi dědičností a kompozicí.
Navíc rozlišování mezi virtuální a nevirtuální dědičností vede k tomu, že musím u předka přemýšlet nad tím, jací a jak budou implementováni potomci (a jestli tedy musím dědit virtuálně či ne). Což je úplný opak toho, o co se snaží OOP - aby jednotlivé objekty byly implementovány samostatně.
a vsichni znaji jeji omezení
I v assembleru lze psát objektově a všichni znají jeho omezení. Přesto bych na objektové programování doporučil jiný jazyk.
Implementace vícenásobné dědičnosti v C++ má svoje plusy a svoje mínusy.Když píšu v C++, vadí mi absence interfaců (respektive její ne uplně dobrá emulace pomocí vícenásobné dědičnosti), když píšu v jiných jazycích, někdy mi vadí absence vícenásobné dědičnosti.
Přesto myslím, že jak mé zkušenosti, tak i obecná praxe a výsledek vývoje nových programovacích jazyků ukazuje, že interfacy jsou daleko užitečnější než vícenásobná dědičnost: zatímco snad všechny moderní jazyky mají interfacy, snad žádný neimplementuje vícenásobnou dědičnost. Přičemž vzhledem k tomu, že drtivá většina z nich je interpretovaná či alespoň runtime kompilovaná, nebyl by s přidáním vícenásobné dědičnosti žádný problém.
-
Nepatří to sem, ale přece:
Díky za ty odkazy, David Strejcy.
:o))) Sice jako v kazdem programu i tady je chyba (nejsem David StrejcY ale David Strejci ;o))) Tvrdej jsem jak blazen to je jasny ;o) A pro vsechny, kteri maj radi UNIX (Live Free Or Die) - fakt doporucuju si precist uplne vsechny koany zde:
http://catb.org/esr/writings/unix-koans/
Je to starsi, lec platne cteni ;o) (je to starsi, ale platny kod {kdyz Luk Skywalker leti na Endor a Darth Vader se pta, jestli maji platny kod ;o))})
Je to i v The Art of Unix Programming - z toho jsem si odnesl tu nejdulezitejsi vec a myslim, ze je to i tady do diskuze platne ;o) - NIC NEOPTIMALIZOVAT!!!!!!!!!! - funguje to v Pythonu? Fakt to dela to, co chces? Pak si radsi koupim rack serveru (cca pul milionu), nez abych platil pul roku optimalizatora, ktery to bude prevadet do Ccka - proc? Proc proboha? Zaprve tim ziskam to, ze mam pul roku volneho cloveka a za druhe ... Python neni zas az tak pomaly ... Stroje to spocitaj. ;o)
Každý OS musí mít optimalizovanou minimálně správu přerušení, aby jejich okamžitá obsluha dokončila svou činnost co nejdříve. Že se někde nedá použít /O3 je dáno hardwarem, ne programátorským přesvědčením o čistotě kódu. Další ukázkou optimalizace, která ukazuje nesmyslnost přístupu "koupím další rack" (kromě toho, že asi volné místo na další racky nejspíš není nafukovací), je eliminace BigLocku v SMP kernelu Linuxu.
-
Vy mu teda dáváte. Další přesvědčený na jazyk C. Jestli v tom bude vyvíjet OS pro Oracle, drivery, signálové procesory nebo programovatelné logické obvody, tak ať se to učí. C není nic jiného než assembler. Jenže to on dělat nebude!
Jasně vám napsal, že umí PHP, HTML a CSS a je to teda lampasák, jesli vám to něco říká. A protože zná i základy Visual Basicu, tak by se mu hodilo se ho pořádně doučit a přidat k tomu C#. Ale konkurence je fakt velká, musíš znát ještě databáze, ASP.NET a slušně MS Sharepoint, jinak ti nedají ani toho Junior Programmera.
-
A tak je to jeho volba. Jenom by asi nebylo od věci si uvědomit, že takových lidí bude vždycky dost a tím pádem konkurence bude značná => dopad na jeho hodnotu na trhu práce. Pořádných programátorů (jo, těch s pointery:), už dnes tolik není a může se ucházet o podstatně lépe placené místo. A když bude fakt dobrej, tak třeba i u real-time systémů, kde to real-time specifikace Javy opravdu nevytrhne.
Takže sice můžu mlčet, protože ho takhle nenapadlo uvažovat, ale taky mu můžu poradit, aby se zamyslel i nad tím, jakou bude mít jeho dovednost hodnotu v budoucnosti. No offense. Ale jen aby nedopadnul jako Al Bunda, když říkal, že má na léto brigádu v krámě s dámskýma botama ;)
-
Ultimator:Otázka byla, jak se naučit programovat. Nikoli jak získat místo junior programmera. Pokud se naučí programovat, na to co píšeš bude v případě potřeby stačit měsíc...
Samozřejmě, že nejjednodušší je naučit se php a jít dělat weby. Tomu ale se skoro nedá říct programování....
-
A co kdyz vam selze sprava pameti - i to se stava, a neni to nic zas tak vyjmecneho, z duvodu, ktere zna jen on?
Co to znamená selže správa paměti? Tobě se jako v javě stalo, že ti něco alokátor odalokoval, když neměl???
Ano, v C#, a zel bohu, nebyla to pouze ma zkusennost - uz se o tom tu nekolikrat diskutovalo. Mimochodem, malo z tech co tak chvali GC a podobne ficurky uz zapomina dodat, ze jejich pritomnost v applikaci take neco stoji - Java je (byla a asi i bude) proste pomala, aplikace v C# jsou na tom sice rychlostne lepe, ale jsou to nenazrane molochy. A kdyz k tomu prictete des ve forme Mono, nebo .NET Freamworku... pak Vam z toho vyjde nadherny otesanek, zerouci pamet a diskovy prostor a co to vlastne vsechno dela, muzem jen hadat. No a nakonec muj oblibenec >:( Python, ma docela sklony k absolutne zahadnym chybam a nestabilitam...
V C/C++ pokud to nesprasi programator k nicemu takovemu by dojit nemelo. Jeste jednou - pokud to neprasi programator.
Jenže to je právě to o čem mluvíme. Pokud se člověk učí programovat, tak dělá chyby. Takže na učení je vhodnej jazyk, kterej mu jasně a srozumitelně řekne kde je chyba. To C není - např. chyba v mezích pole se projeví jen tím, že se přepíše hodnota nějaké jiné proměnné a program běží dál....
Ano takto zakerne se opravdu muze projevit pre/pod-teceni indexu pole. Ale nastesti existuji nastroje jako je valgrid, nebo Eletric Fence, ktere dokazou odchytavat problemy s dinamicky alokovanou pameti. A debuger je dneska snad standard (no a potom je potreba umet pocitat po parech a od 0 do n-1 ) :)
Jinak myslim, ze prave C/C++ by melo programatory vest k tomu, aby to neprasili. Myslim, ze je ucit lepsi psat korektni programy (tedy hlidat si zdroje => kazde malloc() ma sve free( ), new - delete, open( ) - close( ), atd ..., kontrolovat navratove hodnoty, nebo indexy poli. Neni to zas tak tezke. Jen to chce trochu trpelivosti, pozornosti a asi i discipliny), a podobne veci jako je garbage Collector a pod pouzivat, az uz opravdu ma clovek tohle v "krvi" a opravdu dobre vi co dela. A toho lze docilit jen na zacatku. Pozdeji to jde hodne, hodne tezko...
Další nevýhoda C je v tom, že je to velmi výrazově bohatý jazyk. Což ale vede k těžko odhalitelným chybám, púamatuju si, jak jsem kdysi asi den ladil to, že místo
(*c)++ jsem napsal *c++. Skončilo to přepsáním CMOSKY a nefunkčním tátovým počítačem :-).
Me se odpalit kompl vlastnim dilkem nepostestilo (co vsak nebylo, muze byt :) ), ale i tak kdyz se clovek uci - dela chyby a chybama se zase zpetne uci - Dam krk na to, ze dneska jste o dost pozornejsi a opatrnejsi... me se zase povedlo prepsat si kompilator. Muj prvni program v C jsem pojmenoval bc.exe. Stary dosovsky Borland C++ se spoustel programem ... bc.exe ;D
Jinak já netvrdím, že ty všechny výhody, které C má (že dělá jen to, co člověk chce) nejsou pro učení podstatné. IMHO každej programátor by měl někdy v takovém jazyku psát. Akorát nejsem přesvědčen, že (obzvlášť pro samostudium, kde Ti tu chybu nikdo nenajde) je vhodné s ním začínat.
Nicméně po nějaké průpravě s Delphi a Visual basicem to asi už jde....
Ja jsem na Basicu (na osmibitech a pozdeji v DOSU na MS QBasicu) kdysi zacinal. Mohu vam rici, ze prejit z nej na C a potom C++ bylo docela peklicko. Zrovna pochopit pointry, tridy a zvyknout si na typy, byla opravdu fuska a peknou chvili mi trvalo, nez jsem se naucil s tim zachazet. vytrval jsem - a vyplatilo se. Nelituji toho, ale asi bych si usetril docela dost trapeni, kdybych tehdy zacal rovnou s C...
-
Anonymni funkce lze nahradit neanonymnimi? Ano, i v assembleru lze psát objektově. Bohužel
1) funkce se definuje jinde než se používá, tzn. kód je hůře čitelný
2) namespace se zaplácává zbytečnejma identifikátora a tím např. stěžuje orientaci v kódu pomocí automatizovanejch nástrojů, zapleveluje automaticky generovanou dokumentaci etc...
Lamda funkce se chystají v C++0x a co vím, tak běžné překladače od MS a v Linuxu je už umí. Pokud vám vadí vytvářet funkce mimo funkci, můžete si je vyrobit uvnitř funkce. Že to nejde? Ale jo, jde, protože můžete deklarovat třídu uvnitř funkce a v ní můžete deklarovat funkci. Jediný problém je, že tuhle funkci nelze nacpat jako parametr šablony, ale jinak se s ní dá pracovat jako s funkcí. Nevěděl jste to. Učte se, než začnete něco psát.
---
ad interfacy: Mám knihovnu, ve které je interface IA a IB poděděné z IA. Implementuju objekt A implementující IA a jeho potomka B implementujícího IB. Přestože objekt B má všechny metody interfacu IA, C++ kompilátor zařve, že mu schází všechny metody IA, poděděné skrze IB.
Tak mu je tam vyrobte. Co řešíte. Jsou horší věci, kde se upíšete k smrti. Třeba takový generátor wrapů by se hodil, dodnes je musím psát ručně. Ale ten nehledejte ani v Javě :-) Brání tenhle problém nějak používání takto zděděných interfaců. Nebrání. Navíc to určitou logiku má. Interface poděděný přes A může mít jiný význam, než interface přímo, přestože je to stejný interface. To si myslíte vy. Já třeba občas používám i to, že jde o dva různé interface a v různých situacích se ten objekt chová jako dva různé objekty, podle toho, zkrs co se na něj dívám.
2) i pokud je knihovna moje, tak proč bych musel při návrhů interfaců přemýšlet o tom, jestli se někdy budou nebo nebuou účastnit diamantové dědičnosti? To je čistě záležitost implementace a proto do návrhu interfaců nepatří.
ale houby, diamantovou dědičnost nemusíte přece u interaců řešit. Pokud je ten interface tam 5x, tak vám to přece nijak nevadí. Virtuální dědičnost vám sice ušetří práci v psaní, ale rozhodně to zaplatíte výkonem. Virtuální dědičnost má opravdu smysl jen u dědění celých tříd, ne jen abstraktních tříd a interfaců. Možná ještě u výjímek, kde se diamantově poděděná výjimka na základní třídě neodchytí, protože catch handler neví, který z interfaců použít. Ale výjimky je vůbec speciální oblast, která si o virtuální dědění ze základní třídy přímo říká.
Navíc rozlišování mezi virtuální a nevirtuální dědičností vede k tomu, že musím u předka přemýšlet nad tím, jací a jak budou implementováni potomci (a jestli tedy musím dědit virtuálně či ne). Což je úplný opak toho, o co se snaží OOP - aby jednotlivé objekty byly implementovány samostatně.
Je to volba řešení, které nenajdete v jiných jazycích. Je to prostě nástroj a když se vám nelíbí, používat jej nemusíte. Já to používám u výjimek, kde každá výjimka může patřit do kategorie a všechny kategorie dědí základní výjimku. Tam je zřejmé, že kategorie, které nejsou výjimkami dědí vždy virtuálně a konečné výjimky dědí nevirtuálně. Výjimka pak dědí z více kategorií, pokud do těch kategorí patří (třeba FileReadErrorException patří do IOException a SystemException a obě kategorie dědí virtualně Exception).
Virtuální dědičnost je určitý nástroj, který samozřejmě vyžaduje trošku jiné uspořádání, je třeba lépe kategorizovat jednotlivé účastníky hierarchie. Vědět, proč tam ten prvek je a jaký má význam. Umožní to člověku lépe si uspořádat organizaci projektu. Vidíte v příkladu nahoře, že nic nebrání komukoliv napsat další výjimku, která dědí z vícero kategoríí, nebo napsat kategorii, aby z ní mohl vytvářet výjimky.
Divil byste se, kolik lidí neumí OOP. Cpou dědičnost tam, kam patří kompozice, cpou kompozici, kam patří dědičnost. A pak se diví, že to takhle nejde.
I v assembleru lze psát objektově a všichni znají jeho omezení. Přesto bych na objektové programování doporučil jiný jazyk.
No pokud doporučit něco na OOP, tak smalltalk. Rozhodně ne Javu, ani python, ani C#. Jsou to takové lightweight OOP jazyky asi na úrovni C++ (a nemají vícenásobnou dědičnost)
Implementace vícenásobné dědičnosti v C++ má svoje plusy a svoje mínusy.Když píšu v
vícenásobnou dědičnost. Přičemž vzhledem k tomu, že drtivá většina z nich je interpretovaná či alespoň runtime kompilovaná, nebyl by s přidáním vícenásobné dědičnosti žádný problém.
Plete te se. Právě většinou implementační detaily tohle dělají. Třeba problém u vícenásobne dědičnosti je, že objekt nemusí mít stejnou adresu. Místo porovnávání dvou pointerů se musí porovnávat jejich dynamic_cast<void *> transformace. Atd. Tohle jsou všechno argumenty tvůrců těchto jazyků, které nemají vícenásobnou dědičnost. Prostě důvodem je zjednodušení implementace. Smalltalk a možná python řeši objekty poněkud jinak. Jsou to mapy názvů funkcí (zpráv) a adresy jejich volání. Proměnné jsou taky v mapách. Každý objekt je mapa (asociativní pole) organizovaná jako jméno a obsah. Tam můžete mít netypové funkce, které pracují s objekty, jenž definují nějakou kolekci zpráv, jenž umí zpracovat.
Tyhle "objekty" si můžete vyrobit i C++. A budou to objekty, budou se chovat jako objekty a já jsem určitě schopen to navrhnout tak, aby se s tím pracoval tak pohodlně, jako v tom pythonu a ve smalltalku (kromě funkcí stylu eval)
-
Ultimator:Otázka byla, jak se naučit programovat. Nikoli jak získat místo junior programmera. Pokud se naučí programovat, na to co píšeš bude v případě potřeby stačit měsíc...
Samozřejmě, že nejjednodušší je naučit se php a jít dělat weby. Tomu ale se skoro nedá říct programování....
To by urcite hrozne rad slysel pan Martin Maly ze Zdrojaku. Lidi, co placaj, ze webarina neni programovani jsou opravdovi kouzelnici. Stejne v dusledku vsechno pojede pres web. Za par let nebude nic jineho nez HTTP klienti. Je jedno, jestli to bude v PHP (treba jako Facebook pane kolego - a nemyslim si, ze to neni "programovani" udelat neco takoveho) nebo v RoR nebo v C++
Programovani je hodinarina. Vsechno to jsou jen mechanismy vyjadrene v nejakem jazyce.
Opet jeden, ktery si mysli, ze umi "programovat".
-
Ha, ha, ha, ... Vidím, že dnes úlohu assembleru převzalo C v diskuzích o tom, který jazyk je nejlepší pro opravdové programátory :-)
-
Ha, ha, ha, ... Vidím, že dnes úlohu assembleru převzalo C v diskuzích o tom, který jazyk je nejlepší pro opravdové programátory :-)
A proč by ne? Vždyť je to jen takový lepší makroassembler, z dnešního hlediska a v porovnání s "moderními" jazyky, samozřejmě ;-) Stejně tak se za téměř pět desetiletí své existence BASIC přesunul z vysokoúrovňového jazyka pro sdílení času mezi jazyky skriptovací, jako je Bash nebo PHP...
-
Vy jazykozpytci - a umite cesky? ;o)))
Jazyk je je nastroj. Nastroj pro vyjadreni myslenky. Je jedno, jestli to je PHP, C++, Java (bliju kdyz to pisu), Bash (uz mam nablito vlevo, tak nabliju doprava), ZSH (broucek), Python (milacek), Perl (... da se).
Nejdulezitejsi je tim jazykem mluvit. Proste a jednoduse to delat. Maminka vas taky naucila cesky, coz bych prirovnal k ... Jave? Python je anglictina?
Nejdulezitejsi prece je to rict - jakkoli, ale rict to. Optimalizovat pytloviny? Proc proboha? Stroje dneska jsou ZADARMO!!!!!!!!! Je pravda, ze obcas musim neco zoptimalizovat na tech PHP webech, co tu kluci delaj. Ale to udelam tak, ze zapnu cache a je vysmato ;o)))
Hodne funkcnich radku preje deda mraz ;o)
-
To by urcite hrozne rad slysel pan Martin Maly ze Zdrojaku. Lidi, co placaj, ze webarina neni programovani jsou opravdovi kouzelnici. Stejne v dusledku vsechno pojede pres web. Za par let nebude nic jineho nez HTTP klienti. Je jedno, jestli to bude v PHP (treba jako Facebook pane kolego - a nemyslim si, ze to neni "programovani" udelat neco takoveho) nebo v RoR nebo v C++
Programovani je hodinarina. Vsechno to jsou jen mechanismy vyjadrene v nejakem jazyce.
Opet jeden, ktery si mysli, ze umi "programovat".
To je vcelku zajímavá myšlenka, že všechno v budoucnu pojede jako HTTP klient a bude jedno jestli to bude v C++ nebo v PHP nebo v RoR. Dejme tomu, že HTTP ještě několik let pojede přes TCP/IP. A celý TCP/IP stack, ať už v NT, Linux, UNIX, IOS, atd. kernelu, bude moci být naprogramován v PHP, nebo v Ruby :o A ještě ta rekurzivní stránka věci, že budou moci být implementován jako HTTP klient ;D
Aby to nevypadalo, že jde jenom jádra OS, co takhle matematicko-fyzikální výpočty a real-time systémy? Až budou rakušani stávkovat, že Temelín používá sw napsaný v Ruby, tak budu stávkovat s nima ;D
V čem je co napsáno totiž není jedno ani u Javy. Z white paperu Sunu k JVM: Hand-coded assembly stubs are now being used [sic]. A tím assembly se opravdu myslí assembler.
A co třeba BBCode? Vlastně jeho tagy programuju zobrazování příspěvku, takže ovlivňuji, jaké instrukce procesor vykonává, ergo programuju. Hej, a hned můžu všem povědět, že jsem taky programátor, jako ten, který umí C++ ;D
Na programátorech s pointery se mi líbí zásadní věc - než něco napíšou, tak se zamyslí, co vlastně píšou a jestli je to opravdu tak, jak si myslí. A tenhle příspěvěk jsem napsal jen proto, že jsem se neskonale pobavil omezenou vidinou světa programovacích úloh, kterou citovaný komentář představuje.
-
Jinak myslim, ze prave C/C++ by melo programatory vest k tomu, aby to neprasili.
:D :D :D :D :D :D :D :D :D :D :D
Tak takhle dobře jsem se už dlouho nezasmál.
-
ja osobne si myslim, ze si netreba pre zaciatocnika vyberat nic zbytocne jednoduche.
rovno ist do dospeleho c# alebo javu. dnes sa da web pisat pekne aj v jave, vid gwt framework apod. potom clovek uz nema problem s javascriptom, php a vsetky jazyky ajtak smeruju k OOP. takisto si clovek moze hned vyberat .net, pisat pre linux apod.
ziadne pascaly, vb a pod nema zmysel.
-
VB pro něj smysl má, protože už má základy, ale ten VB .NET. A taky C#.
Za 3 týdny se rozhodně programovat nenaučí ani weby, jak tu někdo chybně psal. Pokud se bude učit tak 3 -4 hodiny denně, bude za 2 roky Junior Programmer - tj. kodér. Nejnižší možná úroveň v informačních technologiích. Důležité je pracovat bez chyb a nekomitovat kód, co není podle normy. Doporučuji dělat komit přes Teamleadera, tj komity s filtrací a všechny závady a jakékoliv odchylky od smluvené normy dávat jako Reopeny.
Co je na C++ tak zvláštního, že se bez toho nikdo neobejde? Ty pointery nejsou nic těžkého, vyžaduje to jenom nízkoúrovňové myšlení a kontrolu.
Smysl mají všechny jazyky. Jak na co. Nám by se třeba hodil Fortranista se znalostí C a C++. Numerická matematika nutná.
-
mirec:VB nic moc, souhlasím. Ale takovej pascal na jednoduché algoritmy je imho vhodnější jazyk - už jen porovnej hello world. OOP má smysl až u větších projektů. Jenže člověk, kterej sotva zvládne napsat setřídění pole může psát větší projekt?
Navíc v javě je v hello worldu spousta balastu, která se poměrně špatně začátečníkovi vysvětluje. A když se nevysvětlí, tak se učí největšímu programátorskýmu nešvaru - používat něco, aniž by vlastně věděl co a proč.
Ultimator:Na C++ je to zvláštního, že je velmi blízko hardware. Takže se na něm velmi dobře učí jak dělat věci efektivně. Není výjimkou, že vidím v kódu např
$a=explode(',',$vstup);
$a=$a[1];
Takovoudle prasečinu člověk, co umí C++ nenapíše, protože tomu je jasné, o kolik je to více práce než
if($false===($pos=strpos(',',$vstup)))
$a=$vstup;
else
$a=substr($vstup,0,$pos-1);
hurda: ano, protože pokud se někdo naučí C/C+, tak se naučí
a) psát pořádně a neprasit
b) psát efektivní kód
pokud se to totiž nenaučí, tak C/C++ neumí!
David Strejc:jde o to jak která. Samozřejmě naprogramovat střeva velký apliakce typu twitter tak, aby to opravdu vydrželo zátěž je hezkej kus práce. Na druhou stranu na to člověku jen znalost php nestačí - je třeba pořádně rozumět databázím, race condition, optimalizacím...,.... Ale právě znalost tědle věcí se nejlépe získá tím, že se člověk nebude omezovat na PHP a nastudování jedné knihovny.
Na zbytek hezky odpověděl Semestralky.
novacisko:
Nová verze C++ bude velkým krokem kupředu. Ale zatím tady není a i když nějaké kompilátory některé věci používají, není to C++ dle normy. Já se bavím o C++ dle poslední platného standardu.
Ale jo, jde, protože můžete deklarovat třídu uvnitř funkce a v ní můžete deklarovat funkci. Jediný problém je, že tuhle funkci nelze nacpat jako parametr šablony, ale jinak se s ní dá pracovat jako s funkcí.
Což je vyloženě čisté, čitelné a pohodlné řešení...
Tak mu je tam vyrobte. Co řešíte....
Proto tvrdím, že C++ se na objektové psaní hodí o něco méně. Protože musím ručně vyrábět to, co jinde je automaticky. Navíc při každé změně předka musím měnit i potomka - což je opět proti OOP paradigmatu.
ale houby, diamantovou dědičnost nemusíte přece u interaců řešit
Musím v příkladu, který jsem dal. Respektive jinak oproti jiným jazykům buď musím psát zbytečný balast a navíc je kód hůře udržovatelný (změna na jednom místě vynucuje změnu na x dalších), nebo musím užívat v hierarchii interfaců virtuální dědičnosti a utrpí tím výkon.
Interface poděděný přes A může mít jiný význam, než interface přímo, přestože je to stejný interface.... Já třeba občas používám i to, že jde o dva různé interface a v různých situacích se ten objekt chová jako dva různé objekty, podle toho, zkrs co se na něj dívám.
Podědění interfaců znamená rozšíření funkčnosti. Tzn. pokud objekt je např. seřaditelný a přidám interface seřaďitelný dle kritéria, nemělo by to na seřaditelnosti nic měnit. Jinak je to porušením zásad OOP.
Pokud se objekt chová jinak při volání přes básový interface než přes poděděný interface, tak jde imho s největší pravděpodobností o chybu návrhu: buďto jde opravdu o dva "reálné" objekty implementované jedním programátorským objektem (správné řešení by bylo tedy rozdělit ho na dva a implementovat správné interfacy), nebo naopak poděděný interface nemá být potomkem bázového interfacu (protože ho nespecializuje, ale dělá trochu něco jiného).
Ono to i naznačuje to co píšete - pokud se něco chová jako dva objekty, tak to s největší pravděpodobností dva objekty jsou :-)
Pokud nesouhlasíte s tím, že takový design je chyba v návrhu, dejte sem nějaký reálný příklad, kdy se to takto chová a je to dle vás správně. Nebo možná radši do samostatného threadu, jsme dosti OT.
Prostě důvodem je zjednodušení implementace.
Samozřejmě. Stejně jako u C++ je zjednodušení implementace to, že člověk musí rozlišovat mezi normální a virtuální dědičností. Pokud vícenásobnou dědičnost omezím na interfacy, tak se každá dědičnost chová jako virtuální. Pokud se neomezím, tak musím řešit virtualitu dědičnosti a navíc u hlubších virtuálně poděděných struktur narůstá overhead z virtuální dědičnosti.
Jsou to dva přístupy a vzhledem k tomu, že u všech nových jazyků zvolili cestu interfaců, troufám si tvrdit, že to je proto, že se s pomocí interfaců píše lépe než s pomocí vícenásobné dědičnosti. Byť mi někdy schází. Samozřejmě, nejradši bych jazyk co umí obé, ale kdybych si měl vybrat tak souhlasím s dnešním trendem a říkám: interfacy.
Je možné, že na některý konkrétní projekt by byla vícenásobná dědičnost vhodnější - jen myslím, že projektů, kde se spíš užije snadná definice interfaců je více.
C++ je úžasně flexibilní jazyk a dají se v něm dělat kouzla a chápu, že ho máte rád. Kdybych pracoval na projektech, kde se dají tydle vlastnosti využít, tak bych si to také užíval (např. šablonový systém C++ asi nemá obdoby).
Ale to nic nemění na tom, že díky absenci některých věcí (byť je můžu díky flexibilitě jazyka více či méně emulovat) se v něm nepíše objektově tak jednoduše a hezky jako např. v Javě. Ale dovede zas jiný věci, o tom žádná... :-)
-
Ale jo, jde, protože můžete deklarovat třídu uvnitř funkce a v ní můžete deklarovat funkci. Jediný problém je, že tuhle funkci nelze nacpat jako parametr šablony, ale jinak se s ní dá pracovat jako s funkcí.
Což je vyloženě čisté, čitelné a pohodlné řešení...
Ono samotné používání callback funkcí není čisté řešení (já vím, že delegáti jsou u C# oblíbené). Čistější je používání callback interfaců. A ten mohu čistě implementovat třídou deklarovanou ve funkci. Norma to umožňuje, takže je to čisté. A čitelné taky. Má to hodně blízko anonymnímu objektu (třídě) v Javě.
Tak mu je tam vyrobte. Co řešíte....
Proto tvrdím, že C++ se na objektové psaní hodí o něco méně. Protože musím ručně vyrábět to, co jinde je automaticky. Navíc při každé změně předka musím měnit i potomka - což je opět proti OOP paradigmatu.
Samořejmě že jen dokazujete, že to moc v C++ neumíte. Ty metody se zpravidla implementují tak, že se přímo zavolá implementace patřičného předka. Překladač to odmítá přeložit hlavně proto, že neví, která z obou tříd má mít hlavní slovo, takže vyžaduje od programátora to určit. A protože to souvisí jen se změnou interface, tak to není proti OOP paradigmatu. Pokud některý objekt změní svůj interface, zpravidla musíte upravit všechny místa programu, kde se interface používá. Pokud změníte implementaci v předkovi, v potomkovi se to samozřejmě měnit nemusí. Takže ten Váš argument samozřejmě nefunguje.
Ono to i naznačuje to co píšete - pokud se něco chová jako dva objekty, tak to s největší pravděpodobností dva objekty jsou :-)
A to je problém? Objekt se kolikrát skládá z mnoha objektů. Klasický příklad je televize. Má jedno rozhraní, dálkový ovladač a přesto je to vlastně skládačka mnoha objektů. A kupodivu může mít dvě rozhraní, z nichž jedno obsahuje část druhého a přesto to dělá něco jiného. Rozhraní je popis protokolu komunikace. Rozhraní A rozšířené o rozhraní B pak může přistupovat k jiným službám, než samotné rozhraní B, které nic nerozšiřuje.
Ale to nic nemění na tom, že díky absenci některých věcí (byť je můžu díky flexibilitě jazyka více či méně emulovat) se v něm nepíše objektově tak jednoduše a hezky jako např. v Javě. Ale dovede zas jiný věci, o tom žádná... :-)
Ano mám C++ radši než Javu. Java má spoustu omezení a jediným přínosem je GC a RAD (Rapid Aplication Development) - hlavně díky obrovské knihovní základně. V C++ udělám vše jako v Javě a ještě něco navíc. Všechno bych ale překous, klidne oželil omezené C++ jako Java, ale chybějící destruktory v Javě prostě je něco, co se nedá překousnou.
-
Ono samotné používání callback funkcí není čisté řešení....
Anonymní funkce se např. používají i u funkcionálních paradigmat a tam je to imho čisté. U callbacků je interface asi o něco čistší, s tím souhlasím, ale pořád definice
objektu + jeho užití je IMHO méně user friendly než anonymní objekt (proč by se jinak anonymní objekty zaváděly)?
Pokud změníte implementaci v předkovi, v potomkovi se to samozřejmě měnit nemusí.
Souhlas - ale já mluvím o změně interfacu, nikoli změně implementace.
...Pokud některý objekt změní svůj interface, zpravidla musíte upravit všechny místa programu, kde se interface používá....
To ano, v C++ ale navíc musím upravit ještě všechny potomky, ve kterých jsou wrappery pro tyto funkce. Např. přidám do interfacu jednu metodu. V javě stačí přidat implementovat metodu v předkovi. V C++ navíc musím projít všechny potomky tohoto objektu které dědí zděděný interface a doplnit patřičný wrapper.
Navíc ty potomci nemusí být ani v mém kódu (např. různé pluginy třetích stran distribuované jako zdrojový kód). V tu chvíli z jednoduché operace (přidání pár řádek a rekompilace pluginů) se stane dosti složitá věc: musím kontaktovat všechny vývojáře pluginů a požádat je o patřičné úpravy v kódu a záslání nové verze pluginů (totéž v menší míře samozřejmě nastane i při týmovém vývoji).
---
Další nepřijemnost je, že pokud mám takový objekt
(interface IA, interface IB extends IA, class A implements IA, class B extends A implements IB) tak kdykoli chci použít B jako objekt typu IA, tak musím přetypovávat - což navíc v C++ vzhledem k složitosti konstrukce static_cast není příliš přehledné.
A to je problém? Objekt se kolikrát skládá z mnoha objektů. Klasický příklad je televize. Má jedno rozhraní, dálkový ovladač a přesto je to vlastně skládačka mnoha objektů
Ano, televize je skládačka mnoha objekt;. Jeden z nich je i dálkový ovladač, který volá funkce televize. Ale televize NENÍ dálkový ovladač. Např. proto, že dálkový ovladač může ovládat více televizí, nebo naopak televize byla ovládaná více dálkovými ovladači.
Implementovat ovladač jako součást televize je IMHO hrubá chyba.
A kupodivu může mít dvě rozhraní, z nichž jedno obsahuje část druhého a přesto to dělá něco jiného. Rozhraní je popis protokolu komunikace. Rozhraní A rozšířené o rozhraní B pak může přistupovat k jiným službám, než samotné rozhraní B, které nic nerozšiřuje.
Ehm? Takže jeden dálkový ovladač pošle televizi signál 0001 a televize se vypne, zatímco když to ve stejné situaci pošle druhý ovladač naprosto stejný signál, tak se zvýší jas televize? Jenom proto, že druhý ovladač umí vyslat ještě i 0010? To je přeci blbina.
Pokud B přistupuje k jiným službám, tak jsou to opravdu jiné služby, tzn. by měli být reprezentované jiným rozhraním. A pokud opravdu používají stejný protokol, pak musí být nutně jiný přijemce, tzn. příjmající objekt se skládá z více částí, kdy každá část implementuje nějaký interface - správné je tedy užít kompozici více objektů.
Tomu co popisujete by např. odpovídala televize s integrovaným videem, kdy jak televize tak video má svůj ovladač. Monolitická implementace vypadá Ok.... do té doby než např. přijde televize s integrovaným DVD. Nebo se integrované video rozbije.... Nebo když někdo integruje do televize videa dvě (by se dalo kopírovat z jednoho na druhý).
S kompozitním přístupem tyto modifikace provedu snadno, u monolitického designu bude např. integrace druhého videa dosti složitá - jak rozliším ty dva ovladače na video, když oba mají naprosto stejné rozhraní?
IMHO zaměňujete rozhraní s ovládáním. To že se něco něčím ovládá ještě neznamená, že to implementuje dané rozhraní. Implementovat rozhraní imho znamená spíše býti něčím, popř. umožňovat něco.
Televize tedy má rozhraní přijmi povel. Ten povel může vysílat např. tlačítko na televizi, příjkmák infra a tak... A to infra vyšle objekt ovladač, implementují metodu zmáčkni tlačítko(typ tlačítka). Mixovat to dohromady je imho chyba.
V C++ udělám vše jako v Javě a ještě něco navíc. Všechno bych ale překous, klidne oželil omezené C++ jako Java, ale chybějící destruktory v Javě prostě je něco, co se nedá překousnou.
V javě jdou destruktory emulovat pomocí klasických metod - jediný rozdíl oproti klasickým destruktorům pak bude v tom, že u lokálních proměnných se nebude destruktor volat automaticky. U dynamicky alokovaných je pak imho zcela jedno,
jestli volám delete object, nebo object.delete().
Nicméně souhlasím, že na některé úkoly (např. čtení ze souboru) je koncept lokálního objektu s automaticky volaným destruktorem na používání přijemný a lze daný kód napsat úsporněji než v javě.
Osobně to však nevidím jako takový problém, stejně je v drtivé většině možné - a tedy i vhodné - uvolnit daný zdroj (ať jde o soubor, připojení k databázi apod.) dřív než při zániku objektu.
Případné řešení chyb lze pak řešit pomocí try.... finally a zajištění toho, že došlo ke korektnímu uzavření objektu lze provést kontrolou v pseudodestruktoru. Nicméně ukecanější než jednoduchý lokální objekt to je, v tom souhlasím.
-
Ono samotné používání callback funkcí není čisté řešení....
Anonymní funkce se např. používají i u funkcionálních paradigmat a tam je to imho čisté. U callbacků je interface asi o něco čistší, s tím souhlasím, ale pořád definice
objektu + jeho užití je IMHO méně user friendly než anonymní objekt (proč by se jinak anonymní objekty zaváděly)?
No anonymní třídy (anonymní objekt je tedy blbost, ale myslí se tím objekt vytvoření z anonymní třídy) zavedla až Java. Obecně to nepovažuju za problém
V javě stačí přidat implementovat metodu v předkovi. V C++ navíc musím projít všechny potomky tohoto objektu které dědí zděděný interface a doplnit patřičný wrapper.
V Javě taky. Co když tu metodu nějaký předek reimplementuje?
Navíc ty potomci nemusí být ani v mém kódu (např. různé pluginy třetích stran distribuované jako zdrojový kód).
A mohu kontrovat i tím, že pokud se ukáže úprava v předcích jako problém, vždycky tam můžete vrznout tu virtuální dědičnost (když už se vrtáte v předcích ;) )
(interface IA, interface IB extends IA, class A implements IA, class B extends A implements IB) tak kdykoli chci použít B jako objekt typu IA, tak musím přetypovávat - což navíc v C++ vzhledem k složitosti konstrukce static_cast není příliš přehledné.
Naučte se C++. Při downcastu nemusíte přetypovávat static_castem (můžete). Překladač pouze chce vědet, zda chcete IA které bylo rozšířeno přes IB nebo jen samotné IA
Ale televize NENÍ dálkový ovladač.
Dálkový ovladač byl použit jako abstrakce rozhraní. Nebo si myslíte, že tím, že implementuje třída rozhraní říká, že třída je rozhraním? Toje taky blbina. Třída pouze implementuje rozhraní. Tudíž rozumí protokolu a lze s ní pomocí toho rozhraní komunikovat.
Ehm? Takže jeden dálkový ovladač pošle televizi signál 0001 a televize se vypne, zatímco když to ve stejné situaci pošle druhý ovladač naprosto stejný signál, tak se zvýší jas televize? Jenom proto, že druhý ovladač umí vyslat ještě i 0010? To je přeci blbina.
a)A co stavové protokoly? (rozšíření dalším rozhraní přidá další stavovost, kterou původní rozhraní neumí)
b)To že má druhý ovladač stejně barevná tlačítka a tři tlačítka navíc neznamená, že ty barevná tlačítka dělají totéž jako na prvním ovladači
V javě jdou destruktory emulovat pomocí klasických metod - jediný rozdíl oproti klasickým destruktorům pak bude v tom, že u lokálních proměnných se nebude destruktor volat automaticky. U dynamicky alokovaných je pak imho zcela jedno,
jestli volám delete object, nebo object.delete().
RAII pattern je v C++ velice oblíbený. V zásadě bych se bez něho nikam nehnul. Java RAII neumožňuje a já se prostě skoro nikam nehnu
( http://www.hackcraft.net/raii/ )
Na dynamicky alokované objekty máme chytré pointery (podle RAII) ... vůbec nepoužívám delete. Pokud už ano, tak v útrobách implementací alokátorů.
-
V Javě taky. Co když tu metodu nějaký předek reimplementuje?
Edit: V Javě taky. Co když tu metodu nějaký potomek reimplementuje?
-
Velmi vyčerpávající čtení, zatím studuji jen teoreticky. Jelikož je zde mnoho informací, kterým jsem zatím neporozuměl, zatím zkouším jen jednoduchý kravinky typu Hello World, zjišťuji co který příkaz dělá. Ale Visty mě tak trochu se*ou, když něco v C zkompiluji, tak mi to Visty odmítají spustit. Pravděpodobně mi blbě ukládají cestu.
-
bubavanek:
nic si z toho nedělej, na todle bychom si měli založit svuj thread. Nicméně pokud si dáš práci a pochopíš, o čem se píše, myslím, že Ti to k něčemu bude, ať už skončíš u C++ nebo ne.
novacisko:
V Javě taky. Co když tu metodu nějaký předek reimplementuje?....
A mohu kontrovat i tím, že ... vždycky tam můžete vrznout tu virtuální dědičnost...
a) No tak napíšu tu reimplementaci. Přeci když přidávám novou metodu, tak vím, co má metoda dělat a kterých tříd se týká. Nemusím ale hrabat do tříd, které tuto metodu dědí a to považuji za podstatné.
Právě to, že při modifikaci třídy musím modifikovat i potomky nepovažuji za vhodnou vlastnost.
b) Např. u agilní metodiky se budu v předcích hrabat furt. Takhle skončím se všemi dědičnostmi virtuálními...
Naučte se C++. Při downcastu nemusíte přetypovávat static_castem (můžete).
Co kdybyste místo předpokládání, že je ten druhej blbej se snažil pochopit, coten druhý píše?
class IA
{
public:
virtual void a()=0;
};
class IB: public IA
{
public:
virtual void b()=0;
};
class A: public IA
{
public:
void a() {};
};
class B: public A, public IB
{
public:
void b() {};
void a() {};
a.cpp: unmodified: line 1
class IA
{
public:
virtual void a()=0;
};
class IB: public IA
{
public:
virtual void b()=0;
};
class A: public IA
{
public:
void a() {};
};
class B: public A, public IB
{
public:
void b() {};
void a() {};
B() {};
};
int main()
{
B* b=new B();
IA* a=b;
}
Tady (na předposlední řádce) přetypovávat musím, jinak kompilace spadne. Právě proto, že pro C++ je IA a IB jiné rozhraní, přičemž ve všech ostatních jazycích se IB bere jako rozšíření IA .
A jestli jste myslel, že můžu použít normální přetypování, tak to sice máte pravdu, ale obecně se C-like přetypování užívat v C++ programech nedoporučuje, anžto může zavléct chybu....
Dálkový ovladač byl použit jako abstrakce rozhraní.
Ale copak je ovladač rozhraní - tedy ve vašem významu (se kterým úplně nesouhlasím) tedy komunikačním protokolem?? Ovladač je entita, která vysílá povely nějakým komunikačním kanálem jiné entitě (televizi).
Nebo si myslíte, že tím, že implementuje třída rozhraní říká, že třída je rozhraním? Toje taky blbina.
IMHO není. Pokud např, objekt implementuje rozhraní ISerializible, pak ten objekt JE serializovatelný. Možná spíše bych volil "se navenek chová jako objekt typu popř. objekt mající danou vlastnost".
Pokud omezím "implementovat rozhraní" na "rozumí komunikačnímu protokolu", vede to imho právě na chyby v návrhu, protože to neodhalí složené objekty. Televize s videem rozumí jak příkazům pro televizi, tak příkazům pro video - takže při vašem přístupu je košér implementovat obě rozhraní. Jak jsem ukázal v minulém postu, pokud to ale implementuju jako objekt, tak se brzy při případných úpravách dostanu do problémů - televizi se dvěma videi tímto způsobem neimplementuji.
Pokud přijmu můj přístup, tak televize není video, video není televize a televize s videem není ani video, ani televize, ale spojení dvou objektů. Takže nechám televizi implementovat rozhraní televize, videu rozhraní videa a není žádný problém.
Proto tvrdím: implementovat rozhraní znamená konstatování, že tento objekt je nějaké povahy (např. být televizí, být serializovatelný atd...).
a)A co stavové protokoly? (rozšíření dalším rozhraní přidá další stavovost, kterou původní rozhraní neumí)
Představte si rozhraní jako port na serveru: Jak to rozhraní pozná, že ta druhá strana, která s tím protokolem komunikuje je stavová či nestavová? Jediná možnost je, že se zašle nějaký příkaz: přepni se do rozšířeného módu. Ale pak to jde implementovat v jedné metodě a nepotřebuji různé metody podle toho kdo volá. Takto se dá koukat např. na IP protokol, kde vždy musí být uvedeno, jestli jde o TCP nebo UDP....
Anebo stavová komunikace používá jiný kanál než nestavová komunikace (např. TCP/UDP). Pak ale přeci nejde o stejné rozhraní.... TCP přeci není totéž co UDP - i když používá "stejná" čísla portů...
b)To že má druhý ovladač stejně barevná tlačítka a tři tlačítka navíc neznamená, že ty barevná tlačítka dělají totéž jako na prvním ovladači
Ale ovladač přeci není rozhraní!!! Ovladač je reálný objekt, nikoli komunikační protokol. Ty dva ovladače budou sdílet stejné vstupní rozhraní "mít tři stejná barevná tlačítka". A pokud dělá každý jinou věc, tak stisk těch tlačítek vyprovokuje komunikaci po jiném rozhraní s ovládaným objektem (nebo lépe po stejném rozhraní - obé bude infra - ale s jiným objektem a jinými kódy).
Vždyť i pokud by byl ovladač rozhraní, tak jak byste implementoval programovatellný ovladač, který umí ovládat padesát různých věcí? To kvůli jednomu objektu budete modifikovat padesát tříd a každé přidávat další rozhraní? I když jak ta televize, tak video i HIFI věž se existencí programovatelné ovladače vůbec nezmění? Furt půjde jen např. vypnout posláním 000, zapnout posláním 001 a přepnout program posláním 100??
Naopak pokud přijmete paradigma, že ovladač je objekt, tak prostě napíšete jeden programovatelný ovladač, který bude umět volat jedno obecné rozhraní IInfraOvladač.
Dokonce se pak může klidně stát, že jeden příkaz zapne televizy, na videu spustí nahrávání a na HIFIvěži vymění CD. A to celé zajistím, aniž bych jakýkoli přístroj modifikoval.
PS: samozřejmě, pokud programuju jednoduchou věc, často ovladač a televizi pro jednoduchost sloučím. Je to ale "berlička", měl bych si být vědiom, že to co dělám je nelegální a v případě implementace např. dvou ovladačů budu muset buďto prasit
(s omluvou: váš přístup :-)), nebo refaktorovat.
Ono v tomto případě je zas ale lepší se vykašlat na ovladač a tvářit se, jako že se ovládá přímo televize. Pokud budu potřebovat více různých ovladačů, tak vždycky mohu dopsat "mezivrstvu".
RAII pattern je v C++ velice oblíbený. V zásadě bych se bez něho nikam nehnul....
To co v javě schází je automatická destrukce (a uzavření). Souhlasím, že to někdy vadí, na druhé straně mám dva typy zdrojů: jedny je potřeba uvolňovat hned, druhé nikoli.
U prvního typu zdrojů je imho chyba spoléhat na RIAA a chytré pointery, když se mají uvolňovat co nejdříve, tak bych je měl opravdu uvolnit hned a explicitně - spoléhat na to, že tento pointer nikam neuteče není moc bezpečné - při další úpravě se situace změní a zdroj se neuzavře.
(Navíc většina chytrých pointerů používá reference counting a tedy reálně hrozí, že dojde k zacyklení a neuvolnění zdroje - ale třeba máte chytřejší implementaci chytrých pointerů?).
U druhého typu jde naopak počkat "až někdy". V tu chvíli mohu použít kombinaci pseudodestruktorů a nějakého sběrného objektu, který na konci programu zajistí uzavření všech dosud neuzavřených zdrojů. Samozřejmě to si musím napsat, ale implementace nebude složitější než chytré pointery v C++.
Takže imho RAII pattern je v javě v podstatě stejně použitelný jako v C++, jen se musí využít toho, co nabízí java a ne k tomu přistupovat jako k C++. Výsledek bude +- stejný: V C++ občas díky zacyklení nedojde k uvolnění zdroje, v javě zas dojde k uvolnění zdroje se zpožděním oproti C++.
-
... spoustu nesmyslů...
Nezlobte se na mne, ale nemohu na to reagovat. Stačilo mi si přečíst nesmyslné vymlouvání okolo RAII, anižbyste pochopil o co jde. Stejně tak o tom ovladači, nebo o ISerializable. Proto raději končím diskuzi, bude to možná lepší. Stejně nemám čas se tím až tak podrobně zabývat.
-
Ok, píšu samé nesmysly a nic nechápu. Ovladač je rozhraní k televizi, počítač je rozhraní k internetu (takže internet implementuje počítač) a já jsem rozhraní k počítači. :-) :-) Jdu se implementovat... :-)
-
Ok, píšu samé nesmysly a nic nechápu. Ovladač je rozhraní k televizi, počítač je rozhraní k internetu (takže internet implementuje počítač) a já jsem rozhraní k počítači. :-) :-) Jdu se implementovat... :-)
No tomudle jsem rozuměl:D
-
Ok, píšu samé nesmysly a nic nechápu. Ovladač je rozhraní k televizi, počítač je rozhraní k internetu (takže internet implementuje počítač) a já jsem rozhraní k počítači. :-) :-) Jdu se implementovat... :-)
-
rozhodně doporučuji začít strukturovaným jazykem - nejlépe Pascal, pak přejít na C a dále pokračovat objektově C++. Potom jakýkoliv jiný jazyk se naučit je otázka 1 měsíce.nezačínej objektovým jazykem...
-
Osobně bych vybíral jazyk podle toho, co chcete vytvářet
pokud bude cílem vytvářet systémové záležitosti, ovladače, rychlý výpočetní software, programování mikroprocesorů a spol. šel bych cestou c a pořádně si osvojil jeho low level schopnosti, případně poté nahlédnul do assembleru
pokud budete chtít vytvářet desktopové aplikace, rozkoukal bych se v c a pak přešel na c++, javu nebo net
pokud vás zajímá převážně vývoj webových aplikací, tak bych se učil pořádně do hloubky PHP, JS, případně různé frameworky a knihovny (pozor na problém kanónu a vrabců)
pokud vás spíš zajímá různé bastlení drobných věcí na koleně, pluginů k programům a spol, nebál bych se pythonu
basic a pascal bývaly dříve téměř jasnou volbou, vzhledem k tomu, že téměř všechno dnes vychází z c syntaxe, jsou trochu zbytečnou cestou do spelé uličky
-
Osobně bych vybíral jazyk podle toho, co chcete vytvářet
To je s prominutím blbina. Důležitý je naučit se algoritmizaci, progr. myšlení atd... a
u nich je nejdůležitější "čistota" jazyka (teď tím nemyslím čistotu ve smyslu některých puristů, co prohlašujou že jen ten a ten jazyk je objektový a žádný jiný apod., jako spíš eleganci, konzistenci, dobré hlášení a odchytávání chyb, jemné vedení k čistému programování atd).
Navíc i pro lowlevel programátora má smysl se naučit funkcionální programování, stejně tak pro webovvýho vědět něco o tom, jak to funguje vevnitř, takže je dobré vyzkoušet více co nejrůznějších jazyků (alespoň jeden lowlevel (asm/C), alespoň jeden objektový (java, c#....), alespoň jeden funkcionální (javascript, scheme), pro začátek - kterým si prošel - nějakej jazyk na základní algoritmy, třeba ten packal).
Konkrétní knihovny či syntax jazyka atd. jsou vedleší, ty se naučí "každý kopyto".
Takže rozhodně např. začít se učit PHP je prostě totální blbina, protože PHP pokazí programátorský návyky, v JS bez toho, aniž by už měl nějakou praxi v jinejch jazycích a teda dokázal využít funkcionýálních a prototypovejch rysů jazyka bude s největší pravděpodobností psát bastly atd....
Rozhodně tedy si nevybírat podle toho,m co chci dělat, ale nejdřív se naučit pořádně programovat a pak se teprve specializovat. Stejně jako v každém jiném oboru.
-
ahoj :-)
Ak Ti mam priamo odpovedat na tvoju otazku, ze sa chces od hlbky zoznamit s jednotlivymi jazykmi, tak studuj ich prekladace a specifikacie :-)
Par slov k programovaciemu jazyku. Ak sa na to pozrieme abstraktne, programovaci jazyk je iba jazyk. Teda nejaky nastroj na zapis myslienok. Nic viac, nic menej.
Ak s programovanim uplne zacinas, potrebujes minimalne pochopit svoje myslienky, spravit deterministicky (v kazdom kroku musi byt jasne, co sa ma robit) algoritmus a zapisat ho v danom jazyku s vyuzitim strukturalneho, objektovo-orientovaneho, funkcionalneho alebo logickeho programovania. Zvladnut vsetko naraz je znacne tazke.
Ak sa zacneme bavit o znamych jazykoch, ktore su zadarmo a su univerzalne (existuju na Windows a Unix plaforme) tak padne Basic a prevazne aj C# ( i ked na linux je nejaky projekt mono).
Strukturalne programovanie: naznamejsie su Pascal a C. Osobne som zacinal s Pascalom, lebo som o inom nevedel. Pascal je jazyk, ktory nema najlepsiu syntax a okrem Delphi/Lazarus nevyuzijes znalost jeho struktury v ziadnom inom jazyku. Chce to iba trochu snahy a zvladnes v C toto iste co v Pascale. Koncept strukturalneho programovania je podstatne lahsie pochopitelny ako OOP (vela ludi si mysli, ze vie OOP, ale len si to naivne myslia. Pochopit a maximalne vyuzivat koncept OOP je silno netrivialne, k tomu existuje nespocet situacii, kde je najlepsie sa na OOP uplne vykaslat a spravit to struktularne...) Teda aby som to zrhnul, v strukturalnom programovi ak pochopis pravidla jazyka, ktore nie su narocne (ano, v C sa nemusi prasit, moze sa v nom (programatorsky) ludsky pisat) mozes viacej casu venovat logike programu. Este upozornenie, nech ti pri nom nezatvrdne mozog (boli, su a budu ludia, ktori tvrdia, ze C je najlepsi jazyk)
OOP: Najznamejsie su Java, C#, Smalltalk. V tomto koncepte sa nevyhnes pisaniu slovicok, ktorym este dlho nebudes rozumiet, lebo hold, bez triedy to nepojde a koncept triedy je netrivialny. Kto to nahodou uci, tak to uci stylom, ze tieto slovicka tu musia byt, a preco musia byt, to sa dozvete (podstatne) neskor. Mna osobne by stvalo pisat nieco, co neviem preco.. Kedze OOP chce, ci nechce, zahrnuje v sebe aj struktularne programovanie, budes musit zapasit s myslienkou, logikou programu, moznostami jazyka, s OOP aj skryto so struktularnym konceptom, to mi pride huste...
Dalej mam vlastnu teoriu, ze mozog ma tendecniu sa ucit nove veci rad. Keby si na najskor ucil struktularne programovanie, bavilo by ta, lebo by si sa ucil nieco nove. Potom by si presiel na OOP, to by ta znova bavilo, lebo by to bolo znova nieco nove. Co ma dosledok ten, ze budes vediet oba koncepty a aj ich spravne pouzit. Tam, kde sa hodi struktularne, pouzijes strukturalny pristup, tam kde OOP, pouzijes OOP. Ludia, co poznaju OOP, tak ho pchaju doslova vsade, aj tam, kde by bol 100x lepsi strukturalny pristup a vznika neuveritelne spraseny OOP kod. Lebo nejake struktularne programovanie im pride zastarale, tak na cele vybodnu.
Jazyk C++ je niekde na rozhrani medzi OOP a strukturalnym principom. V plnej miere v nom mozes vyuzit oba koncepty. C++ moze byt aj vhodne na zaciatok, ale iba s kvalitnou literaturou urcenou uplnym zaciatocnikom. Naozaj, treba kvalitnu knihu inac je to silno kontraproduktivne, lebo C++ je najmocnnejsi a najtazsi jazyk, aky poznam. Viem, ze s dobrou knihou to ide. Dobra kniha je napriklad Rozumime C++, Myslime v C++.
Ak mas rad matematiku, nie je uplne odveci zacat s Haskellom (funkcionalne programovanie), kde programujes v matematickych funkciach (funkcia je specialny pripad relacie, relacie je podmnoznina karteskeho sucinu mnozin). Napriklad na M.I.T sa dlhe roky ucil na uvod LIPS (nieco podobne) a 3 roky dozadu ho vystriedal Python. Haskell v komercnej sfere vyuziva naprikad SonyEricsson. Ak mas rad matematicky korektne logice formule (logicke programovanie), asi najznamejsi je Prolog.
Vravel som o spuste veci, co treba zaciatocnikovi zvladnut. Najmenej ich musi zvladnut, a zacne s Pythonom alebo nim podobnym. Svoje myslienky v nom budes moc lahko zapisovat, lebo Python ma relativne lahku strukturu + ma niektore funkcionalne vymozenosti, teda sa clovek nebude chytat za hlavu, ak neskor uvidi v bashi cyklus for. Pri Pythone nemusis riesit OOP, so zaciatku ani strukturalny postoj a ovela viac casu mozes venovat logike programu a vlastnym myslienkam.
Mne osobne pride lahsie aj ovela schodnejsie robit veci postupne ako
vsetko naraz. Po Pythone by asi bolo dobre take C, aby si uvidel, ako PC realne funguje. Ucenie C bude ovela lahsie, lebo uz nebudes riesit logiku programu (to uz budes vediet) a viac sa zameras na ten jazyk...
S tych vsetkych konceptov, co som vymenoval, si myslim, ze OOP by mal nastupit az ako posledny, uz len preto, ze je najtazsi...
Hm, mozno keby si sa ucil najprv Python a potom C, trvalo by to kratsie, ako keby si zacal rovno s C.
Este mozes chciet sa ucit programovat pre nejake programatorske sutaze. V tych jednoznacne vedie C++ kvoli STL.
Snad som poskytol na vec trochu iny pohlad...
Sviezi den :-)
-
a okrem Delphi/Lazarus nevyuzijes znalost jeho struktury v ziadnom inom jazyku.
Ada - ale z jeho primárního účelu to nejspíš bude vyžadovat i bezpečnostní prověrku 8)
-
S tych vsetkych konceptov, co som vymenoval, si myslim, ze OOP by mal nastupit az ako posledny, uz len preto, ze je najtazsi...
Nechci se pouštět do dalšího flame, ale OOP bych rozhodně neodsouval. Nechat ho hned za základní entity jako cyklus, rozhodování, funkce, procedura, pole, a tyhle základaní veci... by následovala třída.
Není nic horšího, když se člověk naučí procedurálně programovat a myslet. Pak se velice špatně přeučuje do objektového programování, které je úplně jiné. Ano, platí tam ty základná věci, jako cyklus, rozhodování,funkce, procedura, ale pak se to začne dost lišit.
Ti co napíšou, že ne, tak dal bych ruku do ohně za to, že neumí OOP programovat (nebo jsou to geniové, ale kolik jich bude, že?) OOP totiž není vůbec o tom pochopit význam klíčového slova class. OOP je o něčem úplně jiném. O umění umět popsat realitu (čili reálné věci z okolí) pomocí objektů. Dokonce bych řekl, že OOP není vůbec o programování, ale o stylu myšlení.
OOP je zároveň samostatn disciplína, kterou se lze učit paralelně. Dokonce se ji lze naučit bez programovacího jazyku. Pokud je dotyčný dychtiv po teorii, pak bych jednoznačně doporučil začít jazykem UML. Je pravda, že v tom "hello world" asi nenapíšu (minimálně ne tak snadno) a velice těžko budu schánět překladač jazyka UML do nativního kódu (neexistuje, UML není programovací jazyk). Ale až se pak dostanu k běžným programovacím jazykům, budu se moci na problémy, které tam budu řešit, dívat trošku z jiné perpsektivy. Pak budu obecně tíhnout k OOP jazykům, protože mi pomohou lépe řešit mé problémy objektově, než jazyky, které OOP podporu nemají.
-
Souhlas. Sice si nemyslím, že je s OOP dobré úplně začít (jednou jsem učil zoufalce, co měli mít čtvrtej rok programování a nic neuměli - OOP naprosto nezvládali - ale to zas pravda asi nebylo tim OOP :-)), ale neměl by se ani odkládat.
IMHO dobrý čas, kdy s OOP začít je okamžik, kdy člověk zvládá jednoduché algoritmy (různá třídění a podobné blbinky) a začne se snažit dávat dva (a víc) takovejch algoritmů dohromady.
Když to řeknu hodně zjednodušeně - s OOP by se mělo začít v okamžiku, kdy člověk začne pracovat se dvěma různejma entitama.... No, moc jednoduše mi to nezní, snad je pochopitelný, co tim myslim... :-)
-
Ti co napíšou, že ne, tak dal bych ruku do ohně za to, že neumí OOP programovat (nebo jsou to geniové, ale kolik jich bude, že?) OOP totiž není vůbec o tom pochopit význam klíčového slova class. OOP je o něčem úplně jiném. O umění umět popsat realitu (čili reálné věci z okolí) pomocí objektů. Dokonce bych řekl, že OOP není vůbec o programování, ale o stylu myšlení.
Myslim si, ze poznam OOP aj ho viem relativne vhonde pouzivat. Pamatam si, ako som zacinal s C++, vadilo mi, ze nerozumiem, co su namespace ale musel som pisat namemspace std. V Jave jednak musis pisat class, jednak public static void main(), co by bolo pre mna (keby som nevedel co je to premenna a cyklus) osobne kopu cudnych slovicok, ktore netusim na co su ale musia tam byt a nemal pocit, ze tomu rozumiem, lebo pisem slovicka, ktorym nerozumiem. Kdez to v Haskell, C, Python by som rozumel kazdemu slovicku co by som bol napisal, co by pre mna ako zaciatocnika velka vyhoda...
Asi mas nejake komplexy, neviem, kazdopadne tlacit do cloveku, ktory nevie co je premenna, UML, ktore je myslienkovo uplne nad vsetkym mi pride ako zaciatocnika ucit hrat na gitare rovno Lennyho Kravitza.
Zacinal som struktruralne, zvladol som OOP a poznam kopu takych ludi... Ak sa chce, da sa vsetko, ak clovek nazatvrdne pri C...
Resp. neviem ako pre Vas, ale pre mna vzdy bolo lepsie, ako som niecomu rozumel uplne a mal som aj z toho radost.
Inac vela ludi zacinajucich s OOP si mysli, ze vyhladanie nejakeho znaku v stringu trva konstatny cas. A je potom problem ukazat cloveku, ze to tak nie je... Lebo pristup OOP je fakt taky, ze tu si spravime metodu, ona nam vrati co chceme a nikde sa nestarame ako dlho to trva atd... vrati nam co chceme a to je jedine dolezite.
Co poznam studentov, ktori zacinali s OOP a ktori strukturalne, OOP kod pisali rovnako kvalitny a ked nebolo vhodne pouzit OOP tak ti OOP sprasili OOP ako sa dalo (nemal som chut ani citat) a ti druhi to krasne elegatne vyriesili...
Myslim, ze uz fakt nemas otvorenu mysel, nemapatas ako si zacinal ty a zijes mimo realneho sveta ak chces zaciatocnikovi tlacit do hlavy UML, z ktoreho by sa asi zblaznil a uz by v zivote nehcem programovat. Resp. ja by so sa zblaznil z toho ako zaciatonik urcite...
Ludia, doparoma, ucili ste zaciatocnikov vobec? Viete, ako uvazuju? Pamate si este ako ste uvazovali vy, ked ste nevedeli cyklus for? Ako to je rapidny pokrok v mysleni a zaciatocnik uvazuje ale uplne inac ako vy... A na to ste uz ocividne zabudli...
-
No ono je OOP a (pseudo)OOP. Třeba namespace s OOP nesouvisí naprosto vůbec, má svoje místo jak v OOP, tak i procedurálním programování a jestli je něco, kam by šlo namespace zařadit, tak je to "modulární programování".
Stejnětak vyhledávání v řetězci? Jakej je rozdíl mezi strpos(retezec, znak) a retezec.pos(znak)? To co popisuješ nesouvisí s OOP, ale se znalostí vnitřností počítače a nějakého nízkoúrovňového jazyka.
Lidi co umí OOP se musí naučit procedurálně programovat, lidi co umí procedurálně se zas musí naučit objektově. Ani bez jednoho se dobrej progr. neobejde.
Protože objektovost se lépe ukazuje na větších celcích, tak je imho vhodnější začít s procedurálním stylem, jakmile ale člověk začne psát větší celky, tak na ně je OOP vhodnější paradigma a tedy čas ho začít používat.
Jakmile totiž člověk začne psát větší celky neobjektově, už si imho "kazí styl". Lepší je učit se oba přístupy najednou, aby si člověk mohl na správnou věc vybrat správnej přístup - oni totiž nejsou v protikladu, spíše se doplňujou.
A co se týče UML, tak nevím, jestli zrovna tendle jazyk je na to vhodnej - sám v něm takovou praxi nemám, ale analýza problému bez použití konkrétního jazyka, jen jako analýzu entit a jejich vztahů, je imho základní dovedností programátora a neni důvod, proč se jí neučit od začátku...
-
Ti co napíšou, že ne, tak dal bych ruku do ohně za to, že neumí OOP programovat ....
Ludia, doparoma, ucili ste zaciatocnikov vobec? Viete, ako uvazuju? Pamate si este ako ste uvazovali vy, ked ste nevedeli cyklus for? Ako to je rapidny pokrok v mysleni a zaciatocnik uvazuje ale uplne inac ako vy... A na to ste uz ocividne zabudli...
Ano, tak přesně Vy potvrzujete moje slova :-) OOP prostě nechápete, vůbec nevíte která bije, možná jste se o to někdy snažil, ale nikdo Vám to pořádně neukázal, nebo jste četl špatnou literaturu. Takže teď už Vám nezbylo nic jiného, než se divit a nadávat.
UML se dá naučit celkem dobře. Stejně jako v mých začátcích, kdy jsme se učili vývojové diagramy. Ty v UML najdete taky (jen se jmenují jinak, a mají trošku jiné symboly). v UML ale najdete spoustu dalších názorných diagramů, které mnohem lépe popisují problém. MImochodem, smyslem UML je ten, aby tomu diagramu nerozuměl jen programátor (ten ho nepotřebuje, všechno si sestaví v hlavě), ale zpravidla produkťák, nebo někdo takový, který moc neprogramuje a přesto potřebuje, abyste mu nějak předvedl, na čem budete dělat.
-
UML nemusi znamenat, ze na zaciatocnika sa vybafne kompletna specifikacia, pokojne sa daju kreslit zakladne skatule, pripadne to pouzit ako analogia vyvojakov. Na cvikach (ale nie pre uplnych zaciatocnikov) som standardne kreslil UML boxy, hoci ti ludia nemuseli vediet, ze je to UML.
Napr. Head First Java od O'Reilly natrepe do zaciatocnika objekty rovno od zaciatku, ukazuje zakladne uvazovanie v duchu ,,toto je objekt a toto vieme s nim robit" (prirodzene mapovanie na metody), nasledne ukazuju foreach, a klasicky for cyklus pride az daleko daleko neskor.
To je pozitivny priklad toho, ako je kopa ludi zakonzervovanych v zmyslani, ze ,,ja som sa ucil [meno jazyka] ako prve a kto robi inak, robi chybu, pricom velmi zriedka je vyargumentovane, preco ta chyba je.
Napr. netusim, preco musi zaciatocnik rozmyslat nad vypoctovou zlozitostou: ked idem hrat na klavir, tiez nemusim vediet vsetky fyzikalne javy, ktore stoja za uderom klapky. Ano, zlozitost je treba vediet, ano algoritmy je treba vediet, ano pointre treba vediet, ale je dobre si polozit otazku, ci hned od zaciatku.
Mozno by to chcelo viac prikladov a spomienok ludi z minulosti, resp. skusenosti z ucenia.
-
Ti co napíšou, že ne, tak dal bych ruku do ohně za to, že neumí OOP programovat ....
Ludia, doparoma, ucili ste zaciatocnikov vobec? Viete, ako uvazuju? Pamate si este ako ste uvazovali vy, ked ste nevedeli cyklus for? Ako to je rapidny pokrok v mysleni a zaciatocnik uvazuje ale uplne inac ako vy... A na to ste uz ocividne zabudli...
Ano, tak přesně Vy potvrzujete moje slova :-) OOP prostě nechápete, vůbec nevíte která bije, možná jste se o to někdy snažil, ale nikdo Vám to pořádně neukázal, nebo jste četl špatnou literaturu. Takže teď už Vám nezbylo nic jiného, než se divit a nadávat.
Ja si pamatam davne dni, kde som sa ucil cykly a ulohu typu vypisat zrkadlovy obraz cisla (nie retazca) mi trvalo cely den a dnes do dam do 3 minut... Ano, nerozumiem, ako sa da v tejto ulohe vyuzit OOP.
OK, predpokladajme, ze mate pravdu a nerozumiem OOP. To si nemyslim, ze je pravda ale urcite su nejake suvislosti a vynimky, ktore som nepochopil. Lebo OOP je podla mna silno netrivialny koncept a zaciatocnik travi hodiny nad trivialnymi ulohami... Teda ja neviem OOP ale od zaciatocnika cakate, ze sa to nauci. Pritom OOP je nad strukturalnym a mne dava rozumu ucit sa radsej po castiach a nie nieco najprv vetu o kompaktonosti a potom az, co je to formula vlastne je... Preto je podla mna vhodny Python, lebo odsteni co moze a najviac priestoru dostava logika programu... Inac za cias vyvojovych diagramov OOP nebolo a v sucasni sa ukazeje, ze OOP na fakt velke projekty nestaci a hlada sa nieco nove. Preto aj OOP vzniklo, lebo sa ukazalo ze strukturalne programovanie na vacsie veci nestaci. Asi cakate, ze zaciatocnik bude rovno robit velke veci, kde je OOP vhodne...
Dalsia vec, mam znamych vo firmach, ktori robia pohovory. Vela ludi si mysli, ze ked hladaju programatora v Jave a oni sa Javu kvazi naucili, tak ich prijmu. 98% z nich leti oknom, lebo nie su schopni spravit fukcny a stabilny program a o programovani maju uplne skreslenu predstavu. Dalsia zaujimavost, ked niekto programoval v C a pozna zbezne aj v C++, tak za kratku dobu pise v Jave ovela lepsi kod ako ten, kto videl iba Javu. Ak nahodou neviete, v Jave sa neda zacat inac ako OOP + myslim si, ze pre zaciatocnika je problem kazde slovicko, ktoremu nerozumie. Chodia im na pohovory stovky takych pseudoprogramatorov a vsetci letia oknom. Ono ak clovek robi drivery pre liedadla, letecke simulatori, soft pre zdravotne zariadania tak sa neodpusta ziadna chyba...
Bola tu poznamka, ze treba vediet aj OOP aj struktularne. Ano. Len prax ukazuje, ze zo strukturalneho programovania sa lahsie naucit OOP ako opacne. Ak si myslite, ze strukturalne programovanie netreba vediet, tak je zbytocne sa s Vami bavit. Mne so strukturalneho prechod na OOP dava zmysel. Naopak nie, lebo by som mal pocit, ze sa ucim historiu a netesilo by ma to ani. A ked si myslite, ze OOP nie je nadmnozina strukturalneho programovia, tak sa s Vami tiez nemam o com bavit.
Ved len kolko ludi ma problem pochopit, co je to relace, triedy ekvivalencie atd...
A uprimne, nepoznam jedneho schopneho programatora, ktory zacinal s OOP. Ale kopec ludi, co zacinali s OOP a pchaju ho totalne vsade a povacsine nemaju sajnu o nejakej lower layer...
A k tomu zaciatonik sa dlho nestretne s ulohou, kde by sa OOP naozaj hodilo...
Uz sa nepovazujem zaciatnika, a chces od zaciatocnika nieco, co podla Vas neviem ani ja, tak nemozem to pochopit (mozno preto, ze nechapem OOP).
OOP je silno abstraktny pojdem a abstrakcia je to, co je na programovani najtazsie. A zacinat rovno s natazsiou vecou mi pride daleko odvaznejsie ako zacat s cistym C...
Ale neviem. Myslim, ze by mohli existovat schopny programatori, odchovanci cisto OOP, ale naozaj ziadneho nepoznam. (ale programovat v ramci Unix API by som im nedal) Samozrejme, UML je pri OOP velmi vhodne.
Neviem ako ostatnym, ale mne sa fakt naljlepsie uci jedna vec a ked sa ju naucim, tak sa potom ucim dalsie. Preto mi pride fajn Python, kde sa budem venovat najviac logike programu a minimalne vsetkym ostatnym veciam. Potom by bolo vyskusat si fajn struktularne programovanie, mozno aj ciste C (ono to ide rychlo, ak uz clovek zvlada logiku), kde si vyskusa riesit problemy, kde je najvhodnejsie strukturalne programovanie a potom nieco OOP. Dava mi zmysel, aby sa to tak mohlo naucit aj rychlejsie ako vsetko vramci nejakeho umeleho OOP.
Vlastne, aj vsetky problemy sa snazim tak riesit, ze ich rozdelim na mensie casti... A ked sa bavime o programovani obecne, nie iba o OOP, tak na zaciatok pride OOP ako zbytocny kanon.
-
Myslim si, ze jazyk by mal byt zvoleny podla konceptu a ako som spominal, najvacsi zmysel mi dava ist na to postupne: logika programu (vyvojove diagrami, alebo z toho by som nemal taku radost ako si naprogramovat a najlahsie to bude napr. v jazyku typu Python), potom strukturalne (kedze je to podmnozina OOP) a potom OOP (kedze je nad vsetkym).
Dalej si myslim, ze pre zaciatocnika je kazde slovicko zlo, ak nepozna jeho vyznam a v takom poriadi sa daju zvolit jazyky, ze bude rozumiet kazdemu napisanemu slovu, co mi pride fajn.
Ono, dlho som si myslel, ze volba uvodneho jazyka zavisy od vlastnoti jazyka, ale to bola hlupost. Zavisi to od konceptu a mnou vymenova cesta sa mi javi ako naschodnejsia a teda aj najrychlejsia, ak je cielom kvalitny programator. Je pekne aj to, ze sa vdaka teorii konceptov by sa mal na ceste stretnut aspon s dvoma, idealne 3 jazykmi. Potom by aj tu spojitost a abstrakciu mohol vnimat celkom tak... prirodzene.
Ale ako, velmi uvidim nejaku inu, najlepsie odskusanu teoriu :-)
P.S.: Neschopnych cistyvh OOP programatorov poznam daleko viac ako tych, ktory nezacinali s OOP.
-
Koukám, že pro mne je problém se naučit slovensky chápat Váš text :D
Mám z toho ale pocit, že si myslíte, že o OOP se akorát mluví a nikdo v něm skoro neumí, že je to plné chyb a je vznikají obrovské nefunkční programy. Nemáte pravdu. Třeba například Seznam jede komplet v C++, objekty tady napsat umí každý programátor v C++. Je pravda, že je to kus od kusu na jiné úrovni. Pracovat s třídami po některých lidech je přímo radost, je to tak dobře navržený, že člověk nemá ani potřebu skoumat, co je obsahem těch tříd a objektů. U některých samozřejmě ne, najdou se i případy, kdy je vidět, že ten člověk viděl C++ poprvé první den ve svém novém zaměstnání. Ale v zásadě každá analýza začína takto: "potřebujeme udělat tohle: takže vytvoříme objekt, který bude mít tyhle metody"... a takhle se tu jede pořád.
-
Třeba například Seznam jede komplet v C++, objekty tady napsat umí každý programátor v C++.
To, že Seznam nepoužívá objektový jazyk neznamená, že ho ostatní nepoužívají.
;)
-
Třeba například Seznam jede komplet v C++, objekty tady napsat umí každý programátor v C++.
To, že Seznam nepoužívá objektový jazyk neznamená, že ho ostatní nepoužívají.
;)
(http://upload.wikimedia.org/wikipedia/commons/0/08/Achtung_troll.png)
-
(http://upload.wikimedia.org/wikipedia/commons/0/08/Achtung_troll.png)
Ale ne, to byl jenom pokus o hloupý vtip :)
-
Mám z toho ale pocit, že si myslíte, že o OOP se akorát mluví a nikdo v něm skoro neumí, že je to plné chyb a je vznikají obrovské nefunkční programy.
To som nikde nepovedal. Cely cas hovorim, ze OOP je netrivialny koncept a chce nezanedbatelne mnozstvo casu naucit sa ho spravne pouzivat...
Dalej vravim, ze zaciatocnik by mal zapasit s ulohami typu: zrkadlovo vypis cislo, kde je hlupost pchat OOP. (aspon ja v tom nevidim ziaden zmysel). Dalej si myslim, ze OOP potrebuje pre zaciatocnika kopu slovicok, pri ktorych nebude rozumiet, preco ich musi pisat ale musia tam byt, lebo to vyzaduje koncept OOP. Co si taktiez nemyslim, ze je dobre. Dalej si myslim, ze OOP v sebe zahrnuje logiku, struktularne programovanie, navrch OOP. Co tu 3 podstatne entity, ktore sa vidia velmi tazke, ak sa ich ma ucit clovek naraz, zvlast ak nevie za 3 minuty naprogramovat zrkadlovy obraz cisla. Mam pocit, ze lepsie sa je tie veci ucit postupne, teda najprv logiku programu, potom navrh struktur a funkcii a potom navrh OOP. Snazim sa problem naucit sa programovat rozdelit na 3 mensie problemy, zlozenim ktorych (konkretne inkluziou) sa vyriesit problem seriozne sa naucit programovat. Neviem, ako riesite problemy Vy, ale sa snazim vsetky problem riesit tak, ze si ich rozdelim na mensie, urcim disjuktne, urcim inkluziu a zacnem tie problem riesit postupne (sekvecne (mam iba jednu hlavu)). A na zaver si myslim, ze vediet kvalitne programovat v OOP vyzaduje vsetky spominane entity.
Snad je uz jasne. Dakujem.
-
To je porad s tim zrkadlovym obrazem cisla - v ciste OOP jazyce Smalltalk napisu
12345 printString reversed 3 minuty mi to fakt netrvalo, a nemam pocit ze by to bylo pro zacatecnika nejak obtizne pochopitelne nebo ze by bylo hloupost delat to v OOP jazyce..
-
To je porad s tim zrkadlovym obrazem cisla - v ciste OOP jazyce Smalltalk napisu
12345 printString reversed 3 minuty mi to fakt netrvalo, a nemam pocit ze by to bylo pro zacatecnika nejak obtizne pochopitelne nebo ze by bylo hloupost delat to v OOP jazyce..
Number(12345).toString().reversed();
Jo. tohle není Java, ale C++. Nicméně to vyžaduje knihovnu, stejně jako v tom smalltalku (a v Javě). Z OOP tam je snad jen to, že číslo je objekt, ale jinak to o OOP nic nevypovídá ;D
Medvědí služba (váš příspěvek)
-
Number(12345).toString().reversed();
Jo. tohle není Java, ale C++. Nicméně to vyžaduje knihovnu, stejně jako v tom smalltalku (a v Javě). Z OOP tam je snad jen to, že číslo je objekt, ale jinak to o OOP nic nevypovídá ;D
myslel som, ze chcete viest zaciatocnika ku algoritmizacii... Kludne by namiesto toho mohlo byt aj vypisat ciferny sucet... (panecku, strelil som prvu ulohu co ma napadla a uz sa musite predhanat...) Btw, stale ste nepovedali jediny rozumny dovod (aspon som ho nikde nepostrehol) preco zacat s OOP.
#include <stdio.h>
int
main(void)
{
int cislo, obraz;
scanf("%d", &cislo);
obraz = 0;
while (cislo > 0 ) {
obraz *= 10;
obraz += cislo % 10;
cislo /= 10;
}
printf("Obraz je: %d\n", obraz);
}
V Pythone som dlho nerobil, tak to nedam za 2 minuty ale mal by ten zdrojak vyzerat krajsie i jednoduchsie
-
Nehoruji primo pro OOP, jen jsem chtel ukazat, ze v OOP jazyku clovek muze programovat, aniz by zpocatku musel znat tu furu netrivialnich konceptu (mimochodem, objekty = data + metody a posilani zprav, coz jsou skutecne asi jedine podstatne koncepty OOP, prijdou pomerne intuitivni). Vas "algoritmizujici" priklad na zrcadlovy obraz cisla by ve smalltalku doslovne vypadal takto:
| cislo obraz |
cislo := 12345.
obraz := 0.
[cislo > 0] whileTrue: [
obraz := obraz * 10 + (cislo \\ 10)).
cislo := cislo // 10.
].
obraz.
Mozna je to profesni slepota, ale prijde mi, ze je pomerne dobre citelny i pro cloveka co smalltalk vubec nezna.
Jinak samozrejme netvrdim, ze OOP je jedina spravna cesta. Ale myslim si, ze jazyk C, Pascal apod. NEJSOU dobre jazyky na vyuku algoritmizace.
Priklad: Jako zadani jakehosi algoritmizacniho prikladu je implementace stromu, vcetne metod (funkci, procedur, podle jazyka), ktere strom prochazeji preorder, inorder, postorder. Aby tyto byly zaroven uzitecne, a zaroven obecne, musi byt (jinak to podle me opravdu nejde) naimplementovany tak, aby braly jako parametr kus vykonavatelneho kodu, ktery se pro kazdy prochazeny element zavola s timto elementem jako parametrem. Nyni mame podle schopnosti jazyka nasledujici moznosti:
1)
Jazyky, ktere to podporuji (Smalltalk, Ruby, Lisp, Python, Scala, C#) maji syntaxi pro anonymni (lambda) funkce, muzeme tedy primo psat napr: aTree inorderDo: [:eachElement | eachElement echo]2)
V OOP jazycich udelame tridu, ktera implementuje pozadovanym zpusobem napr. metodu EchoExecutor::executeOnElement(e: TreeElement)
{
echo(e)
}
, a volame
aTree.inOrderDo(new EchoExecutor)
3)
Konecne v jazyce C, kde nemame ani jedno, ani druhe, nam zbyva ukazatel na funkci, Ten ma ovsem dve nevyhody:
a) "Ukazatel na funkci, ktera bere jako parametr ukazatel na TreeElement" je podle me nejobtizneji uchopitelny koncept ze vsech tri
b) Predstavme si, ze by prvky stromu byla cisla, a my chceme jejich soucet. V tomto pripade je nutne nekde ukladat mezisoucet. V pripade lambda funkci to neni problem, protoze mohou referencovat promennou z blizkeho kontextu, napr.
| sum |
sum := 0.
aTree inOrderDo: [:eachElement | sum := sum + eachElement]
V pripade OOP jazyku mame situaci snad jeste jednodussi, protoze staci do EchoExecutora pridat instancni promennou. Ovsem v pripade jazyka C a ukazatelu na funkce mame jedinou moznost, pouzit statickou (globalni v souboru) promennou. Ze jsou tyto spatne, vi kazdy slusny programator. Kdyz nic jineho, nas kod nyni neni thread-safe. Samozrejme, ze jsou cesty, jak tento problem obejit, myslim ze asi vetsina C-Ckaru by vycouvala tak, ze by funkce, ktera se vykonava nad elementem stromu, brala jeste druhy parametr, nejake void *data (chceme preci byt obecni a neomezovat se jenom na scitacky), do ktereho by bylo mozne ukladat mezistavy (pozn: to je presne pripad napr. knihovni funkce strtok vs. strtok_r). V pripade souctu by tam byl int *sum, a v tele funkce by se pretypovavalo - cimz jsme se efektivne zbavili typove kontroly, kterou za nas prekladac delal, a zavedli koncepty, ktere spolehlive maloktery zacatecnik rozdycha. A proc? Abychom simulovali, to co za nas delaji OOP jazyky samy - svazali data a kod do jednoho zapouzdreneho objektu. Ovsem zatimco OOP jazyky to za nas delaji vsude, rady a efektivne, my to delame ad-hoc, kod je tezko srozumitelny, a ztracime typovou kontrolu.
Zaver
Tvrdim, ze na vyuku algoritmizace je potreba jazyk, ktery snadno podporuje kod-jako-data. Ja znam pouze blokove uzavery a OOP instance v objektech (v LISPu je ovsem veskery kod zaroven data, ale nevim, jestli se to da povazovat za blokovy uzaver). Toto je nezbytne k budovani algoritmickych stavebnich bloku. Jake jsou dusledky? U ktereho kodu rozhodnete rychleji, co dela?
int coAsiDelaTahleFunkce(const int pole[], const int velikostPole)
{
int i;
for (i = 0; i < velikostPole; i++)
if (odd(pole[i]))
return true;
return false
}
vs
coAsiDelaTahleFunkce: pole
^pole anySatisfy: [:element | element isOdd]
Osobne nepovazuji za podvod to, ze v C-ckove verzi je zaroven implementovan algoritmus anySatisfy, protoze v praxi ho kazdy C-ckovy programator proste naimplementuje znovu a znovu. Jako jedinou alternativu ma totiz udelat si funkci,
int isOdd(void *arg)
{
return odd(*((int *)arg))
} /* (doufam, ze jsem tam ty hvezdicky dal spravne, melo jit o pretypovani na int* a naslednou dereferenci) */, a to proste nikdo delat nebude. Pritom smyslem algoritmizace neni vsechny, i ty nejtrivialnejsi konstrukty, prepisovat pomoci assembler-like primitiv jako jsou for-smycky, ale vybudouvat rozumne stavebni bloky prislusne domene algoritmu, a z tech pak srozumitelne algoritmus vybudovat. V zaplave smycek clovek nepozna, co je allSatisfy, co anySatisfy, co je map, co je reduce, a tak, misto aby se vzdelaval v tom, jake konstrukty se pro tvorbu algoritmu hodi, cvici se jen ve for/while/break/continue/ukazatel na funkci, co ma jako parametr ukazatel na funkci vracejici ukazatel na pole charu a jak na nej pretypovat z void* idiomech, ktere jsou stejne neprenositelne do jinych jazyku.
Takze jeste jednou. Netvrdim ze OOP je jedina moznost jak lepe programovat. Jazyky podporujici funkce vyssiho radu (lambda funkce) jsou dalsi. Nicmene, jazyky ktere neumoznuji snadno reprezentovat kod jako data a manipulovat s nim, jsou proste velice omezujici a na vyuku programovani se nehodi. Pokud si myslite, ze jsou obtizne, vyzaduji kupu novych a tezko pochopitelnych pojmu, vezte, ze zadny z nich neni ani zdaleka tak komplikovany jako pretypovani void* ukazatele na ukazatel na funkci, ktera zpracovava pole stringu. Naopak, jak blokove uzavery (closures/lambda funkce), tak objektove programovani (tedy zasilani zprav a zapouzdreni kodu a dat do objektu) jsou velice intuitivni, pokud nejsou ovsem zkomplikovany kupou dalsich, s OOP vubec nebo jen vzdalene souvisejicich pojmu, jako je tomu napr. v jazyce C++.
Doufam ze tento post byl konstruktivnejsi nez muj predchozi :-)
-
Nechci se pouštět do té samé diskuze, ale OOP nejsou jazyky, které umí eval ;D
A to že nemáte příklad v C++ by o něčem svědčilo :-)
-
To prvni netvrdim, ani to nevyplyva z toho co pisu. O cem by svedcilo to druhe, mi neni jasne, ale myslim ze treba priklad 2) nema k C++ daleko. Jeste jsem si uvedomil, ze v C-cku jde castecne rozsirit syntaxi pomoci maker (s urcitym omezenim jde udelat treba zminovane allSatisfy apod.), ale vzhledem k tomu, ze C-ckovy preprocesor je vlastne jiny jazyk, nevim, jestli je to zrovna dobra ukazka neceho, co zacatecnikovi zjednodusi programovani. Celkove mi ovsem neni jasne, co si z vaseho miniprispevku vlastne odnest, jen mam podvedome podezreni, ze s nekterymi castmi nesouhlasite. To je prirozene, urcite muj dlouhy prispevek neni ani uplne spravne, ani nesedne vsem, ale za tim, ze co nejjednodussi podpora pro kod-jako-data (tedy referencovani bud closures, nebo objektu ve smyslu OOP) je nezbytna pro snadnou tvorbu generickych algoritmu, si stojim.
-
To prvni netvrdim, ani to nevyplyva z toho co pisu. O cem by svedcilo to druhe, mi neni jasne, ale myslim ze treba priklad 2) nema k C++ daleko. Jeste jsem si uvedomil, ze v C-cku jde castecne rozsirit syntaxi pomoci maker (s urcitym omezenim jde udelat treba zminovane allSatisfy apod.), ale vzhledem k tomu, ze C-ckovy preprocesor je vlastne jiny jazyk, nevim, jestli je to zrovna dobra ukazka neceho, co zacatecnikovi zjednodusi programovani. Celkove mi ovsem neni jasne, co si z vaseho miniprispevku vlastne odnest, jen mam podvedome podezreni, ze s nekterymi castmi nesouhlasite. To je prirozene, urcite muj dlouhy prispevek neni ani uplne spravne, ani nesedne vsem, ale za tim, ze co nejjednodussi podpora pro kod-jako-data (tedy referencovani bud closures, nebo objektu ve smyslu OOP) je nezbytna pro snadnou tvorbu generickych algoritmu, si stojim.
To že neznáte C++ jste dokázal v odstavci několikrát. Samozřejmě je pravdou, že v kompilovaných jazycích nelze vykonávat data jako kód. Ale není to nepřekonatelné omezení. Lze samozřejmě vykonávat kód podle dat, pokud ty data jsou očekávaná. Tedy mohu na základě dat vykonávat předpřipravený kód. V C++ se už vůbec makro jazyk neuvažuje, maximálně opravdu jen na fajnšmekřiny a věci, co se nezvládne syntaxí jazyka C++. Nicméně v C++ najdeme polymorfní typy a najdeme tam i generiku. Generika má sice tu nevýhodu, že se vyhodnocuje během překladu, čili sklouzáváme tam, že kód už musí být připřaven, ale na druhou stranu, polymorfní objekty nám umožní ten kód na základě dat snadno vykonávat. V c++ například máme interfacy, což není nic jiného, než popis protokolu komunikace s objektem, tedy nemohu na objekt poslat libovolnou zprávu, ale mohu požádat o libovolný interface, podle kterého pak s objektem komunikuji. Objekt pak vykonává kód podle toho kým je. Ten kód samozřejmě není napsán "v objektu" jako u čistých OOP jazyků, ale je tam někde vnitřně udělaná tabulka ukazatelů na funkce, které už jsou připravené podle toho o jaký _typ_ objektu jde.
V C++, Java, C# a ve všech těchto podobných jazycích nezvládnete napsat 100% čistý objektový kód, ale zvládnete to třeba z 80% (a zbytek si poradíme strukturovaně , případně rekurzivně) za cenu ztráty výkonu v řádově v procentech. Vyjádřete ztrátu výkonu u čistých objektových jazyků. Pak už to je jen o tom umět si vybrat vhodný kompromis.
Hlavní význam polo-OOP jazyků vidím v tom, že umožňují používat strukturované programování na nízkých úrovních a tyto úrovně pak kompletovat do velkých celků formou objektů. Čím hloubš niže totiž s objekty, tím roste cena takového sestupu. Nakonec i v pythonu, či ve smalltalku je za celým virtuálním strojem nějaký jednoduchý céčkový program, který ty operace nízké úrovně provádí klasickým strukturovaným programem.
-
Perfektně napsaný post!
Nehoruji primo pro OOP, jen jsem chtel ukazat, ze v OOP jazyku clovek muze programovat, aniz by zpocatku musel znat tu furu netrivialnich konceptu
Obávám se, že problém je v tom, z čeho jsem si dělal srandu výš (a byl označen za trolla :) - je docela málo lidí, kteří slušně znají a umí správně používat skutečné OOP (tj. Smalltalk, Objective C apod.) a ještě míň je lidí, kteří by jima začínali (těch bude v ČR myslím asi max tolik. kolik mám prstů :) - takže prostě ti, kdo začínali Cčkem si ani nedokážou představit, že by to mohlo jít i jinak a tak se tenhle náhled replikuje do další generace programátorů...
S tím, jak nabývá na popularitě Java a C# se snad trochu pohnou ledy...
-
Samozřejmě je pravdou, že v kompilovaných jazycích nelze vykonávat data jako kód.
Nechci prudit, ale na to, že v Seznamu umíte všichni programovat objektově, vám docela uniká význam closures. Closures opravdu nejsou o spouštění dat :)
-
Nehoruji primo pro OOP, jen jsem chtel ukazat, ze v OOP jazyku clovek muze programovat, aniz by zpocatku musel znat tu furu netrivialnich konceptu (mimochodem, objekty = data + metody a posilani zprav, coz jsou skutecne asi jedine podstatne koncepty OOP, prijdou pomerne intuitivni). Vas "algoritmizujici" priklad na zrcadlovy obraz cisla by ve smalltalku doslovne vypadal takto:
| cislo obraz |
cislo := 12345.
obraz := 0.
[cislo > 0] whileTrue: [
obraz := obraz * 10 + (cislo \\ 10)).
cislo := cislo // 10.
].
obraz.
Pekny post, s ktorym v podstate suhlasim :). Pravdepodobne som slabo podotkol, OOP som myslel skor Java/C# stylom. Smalltalk osobne nepoznam (neviem, ci bude mat niekedy prilezitost, ale rad by som) ale pocul som, ze aj mal take tendecie pri navrhu byt prijemny pre novacika. Nemam nic ani proti Lisp (ale radsej uz Scheme, aby sa clovek neuzatvorkoval k smrti :)) ani Haskellu (osobne sa mi velmi paci) a Python som na zaciatok navrhoval sam :) Ono ja poznam OOP iba Delphi, C++ a Java a Smalltalk sa tvari trochu inac :) A stale si myslim, ze zacinat OOP v Delphi, C++, Java nie je najprijemensie pre zaciatonika :)
Osobne citim ako hriech spachany na na mne, ked som zacinal s Pascalom (lebo nikto mi nepoveda o nicom inom) a neskor s vlastnej iniciativy C. Ovela rasej by som zacinal Smalltalk, Lisp alebo Python.
Na druhej strane nemusite prehanat, nikto v C novacika nebude zatazovat niecim ako void *(*strcpies[3])(void *, char *) :). Osobne si myslim, ze sa chce clovek clovek venovat profesionalne programovaniu, mal by par hodin venovat aj C...
Ale aj dost zavisi, po com clovek tuzi. Ti chce programovat systemove veci, tak taki novacikova maju C doslova radost (a to je to najlepsie, mat radost) a poznam vela ludi, co zacinali s C a su tomu velmi radi (osobne radsej C ako Pascal). Ked si chce niekto robit utilitky pre Windows, tak asi by som mu odporucal Visual Basic (alebo SmallBasic podla veku, ale ze vraj SmallBasic je vhodny aj na 8 rocne deti).
Ten, kto ma niekto furu napadov a chce si programovat hry, Game Maker je tiez velmi pekna volba. Neskor sa moze ucit jazyk GM a este neskor GML.
Chce niekto robit hry pre web, flash ma pekny ActionScript...
Ked chce robit niekto web, tak hold, ostava mu PHP atd... Ale to vobec nevadi, ak bude mat z toho radost.
Myslim, ze novacik by mam mat z toho najma radost.
Dakujem :-)
ondra.novacisko: Uz by mi prislo trochu trapne, vraviet kazdemu druhemu ze neumi C++, neumi OOP atd... Uz to ani nemusite pisat, myslim, ze uz si aj taky kazdy predstavi ako prvu vetu vo Vasom poste.
-
To že neznáte C++ jste dokázal v odstavci několikrát. Samozřejmě je pravdou, že v kompilovaných jazycích nelze vykonávat data jako kód. Ale není to nepřekonatelné omezení. Lze samozřejmě vykonávat kód podle dat, pokud ty data jsou očekávaná. Tedy mohu na základě dat vykonávat předpřipravený kód. V C++ se už vůbec makro jazyk neuvažuje, maximálně opravdu jen na fajnšmekřiny a věci, co se nezvládne syntaxí jazyka C++. Nicméně v C++ najdeme polymorfní typy a najdeme tam i generiku....
C++ UZ neznam - ale pred cca 5ti lety jsem v nem nekolik let delal, takze mam pomerne slusny prehled, co umi a co ne. Kazdopadne mam z vaseho prispevku dojem, i kdyz to nikde explicitne nerikate, ze nekde bojuji proti C++. To ale prece vubec neni pravda! Jak jeste jednou zopakuji, priklad 2) v mem puvodnim dlouhem postu je v podstate v C++ (asi s mirne ohnutou syntaxi, ale to je drobnost), a na nem ukazuji jak predlozeny problem resit v OOP jazycich. C++ sice nemam rad, jako vyukovy jazyk pro zacatecnika bych jej urcite nedoporucil (uplne nejspravneji by se allSatisfy resilo pomoci sablon, viz napr. http://stackoverflow.com/questions/265228/how-can-i-negate-a-functor-in-c-stl, a to povazuji za vice nez dostatecny zpusob, jak zacatecnika vystrasit), ale ve svem dlouhem postu proti C++ nic nemam, a ani netvrdim, ze to neni OOP jazyk. Ve vasem postu tedy bojujete proti fantomum ve vasi hlave, ktere vznikly spatnym prectenim a/nebo pochopenim meho prispevku, nikoliv proti realite.
-
Na druhej strane nemusite prehanat, nikto v C novacika nebude zatazovat niecim ako void *(*strcpies[3])(void *, char *) :). Osobne si myslim, ze sa chce clovek clovek venovat profesionalne programovaniu, mal by par hodin venovat aj C...
Když někdo bude dělat učebnici/cvičení pro nováčky, tak pokud není sadista, tak se tomu záměrně vyhne. A v tom je právě ten problém - ona by tahle konstrukce totiž v některých případech byla čistá a správná - a pokud se jí vyhneme jenom proto, že je v C absolutně nečitelná, tak právě už nováčka deformujeme. Proto je lepší začít jazykem, kde i takováhle (nebo podobná) konstrukce je v poho čitelná i pro nováčka.
-
presne!
-
Na druhej strane nemusite prehanat, nikto v C novacika nebude zatazovat niecim ako void *(*strcpies[3])(void *, char *) :). Osobne si myslim, ze sa chce clovek clovek venovat profesionalne programovaniu, mal by par hodin venovat aj C...
Když někdo bude dělat učebnici/cvičení pro nováčky, tak pokud není sadista, tak se tomu záměrně vyhne. A v tom je právě ten problém - ona by tahle konstrukce totiž v některých případech byla čistá a správná - a pokud se jí vyhneme jenom proto, že je v C absolutně nečitelná, tak právě už nováčka deformujeme. Proto je lepší začít jazykem, kde i takováhle (nebo podobná) konstrukce je v poho čitelná i pro nováčka.
Snazili ste sa moj post pochopit ako celok alebo ste uvideli iba jednu vec, ktoru musite hned nezmyselne vypichnut?
-
Snazili ste sa moj post pochopit ako celok alebo ste uvideli iba jednu vec, ktoru musite hned nezmyselne vypichnut?
Vsak ja s Vami nepolemizuju, jenom rozvijim to, co jste napsal, hlavne tohle:
Na druhej strane nemusite prehanat, nikto v C novacika nebude zatazovat niecim ako
- k tomu dodavam, ze presne v tomhle je ten duvod, proc s Cckem NEzacinat.
Mozna jsem to napsal necitelne, v tom pripade se omlouvam.
-
Snazili ste sa moj post pochopit ako celok alebo ste uvideli iba jednu vec, ktoru musite hned nezmyselne vypichnut?
Vsak ja s Vami nepolemizuju, jenom rozvijim to, co jste napsal, hlavne tohle:
Na druhej strane nemusite prehanat, nikto v C novacika nebude zatazovat niecim ako
- k tomu dodavam, ze presne v tomhle je ten duvod, proc s Cckem NEzacinat.
Mozna jsem to napsal necitelne, v tom pripade se omlouvam.
C++ je najtazsi jazyk aky poznam, aky kolvek programator s nim zacne, narazi coskoro na nieco, kde sa bude citit ako novacik pri tom Cckovom kode (vratane Ceckarov. Napr. vela ludi ani nevie, ze C++ dokaze na realny vypocet vyuzit uz kompilator). A predsa sa s nim musi nejako zacat...
Je kopu ludi, ktory zacinali s C, skoncili pri bohvie com a niekolko nasobne schopnejsi ako ti, co zacinali Java/C#... To je nevyvratitelny fakt, uznavam vsetky dovody preco nezacat s C, ale ani urcite by som ho nezavrhoval. Dalej existuje netrivialna skupina ludi, ktorych bavi zacat rovno C. Ked maju z toho radost, nie je na tom nic zle...
Na zaciatok by som akurat neodporucal OOP typu Java/C#, lebo znacna cast tych ludi pcha OOP uplne vsade, a to nie vzdy je vhodne a povacsine nevedia ani inac uvazovat...
-
Na zaciatok by som akurat neodporucal OOP typu Java/C#, lebo znacna cast tych ludi pcha OOP uplne vsade, a to nie vzdy je vhodne a povacsine nevedia ani inac uvazovat...
Toto ma zaujalo, vieš to nejak elaborovať? Teda nejaké konkrétne príklady problémov, keď je použitie OOP na škodu?
-
Toto ma zaujalo, vieš to nejak elaborovať? Teda nejaké konkrétne príklady problémov, keď je použitie OOP na škodu?
No, ono se často zaměňuje použít OOP s vytvořit objekt. Pokud samozřejmě pako se půl roku učí OOP a pak přijde k nějakýmu problému, tak první co udělá je, že začne prasit nějaký objekty bez ladu a skladu a myšlenky. Ale to je za
a) chyba toho paka a ne OOP
a za
b) to nemá s OOP nic společnýho, kromě objektů
OOP se týká designu programu, entit, vztahů a procesů mezi nimi a výstupem OO analýzy může bejt i např. pouze algoritmus. Byť pravda u většiny reálnejch problémů ˇjde vždycky provést dekompozice a tak těch objektů tam párr bude...
-
Na zaciatok by som akurat neodporucal OOP typu Java/C#, lebo znacna cast tych ludi pcha OOP uplne vsade, a to nie vzdy je vhodne a povacsine nevedia ani inac uvazovat...
Toto ma zaujalo, vieš to nejak elaborovať? Teda nejaké konkrétne príklady problémov, keď je použitie OOP na škodu?
napriklad Master Boot Record... Alef0, zachoval si sa ako zachoval, a znova ides rypat na veciach, ktore sa daju trivialne vyvratit. Pozdrav Peta, podakuj sa mu za mna a sorry, nechcem riesit uz ziadne Tvoje ani Vase nezmyselnosti. Ked si nahodou myslis, ze to nie su nezmyselnosti, najdem podstatne viac a nie menej vzdelanych ludi ako ty, ktori povedia, ze su to nezmyselnosti.
Programovanie v Unixe prednasaju ludia priamo zo Sunu (Oracle) a ver, ze tam OOP nechodis vobec a aj ver, ze zarabaju inac a su aj inac ziadani. Ich platy a platy Javistov (tvoja alma mater) su neporovnatelne.
Recnicka otazka. Preco su ziadani, firma ich strazi a zarabaju uplne inac a pritom takmer vylucne programuju v cistom C vo vime alebo emacs?
Ak planujes byt taky isty, tak som uz s Tebou dohovoril. Pekny zivot.
-
Pozor, ja netvrdim, ze OOP sa ma pouzivat vsade, vzdy a zakazdym -- v mnohych problemoch na to jednoducho nie su nastroje, resp. moznosti. Programovanie zeleza s pouzitim OOP nik robit nebude, lebo tie jazyky na to nedava moznosti.
Ale tu sa bavime o metodologiach pre zaciatocnikov a nehovor mi, ze programovanie zeleza je idealny sposob ako prilakat generalne masy k programovaniu.
Ty ako keby si tvrdil, ze vyucba OOP je kontraproduktivna, lebo ,,ludia pchaju OOP vsade a to nie je vzdy vhodne a je to na skodu.", lebo nevedia naprogramovat MBR?
(Programovanie Unixu je opat zvlastna kategoria, ktora si rozhodne zasluzi pozornost, ale ako to suvisi so zaciatocnikmi, nechapem.)
-
iwtu:Unix není objektovej? Odkdy? Co je např. socket, soubor, semafor? Jaktože to není objekt?
Právě např. design "vše je soubor" je krásnej příklad OO myšlení: jeden interface pro soubory a konkrétní objekty ho implementují.
Že je většina jádra linuxu v C? No a co, to něčemu vadí? OOP se týká designu a přístupu k entitám, se kterými se pracuje, nikoli o tom, jestli něco píše tak nebo jinak. Tzn. to, že se v unixu píše místo socket.write(data, size) write(socket, data, size) nemá s tím, jestli unix je nebo není OO společnýho lautr nic.
-
Toto ma zaujalo, vieš to nejak elaborovať? Teda nejaké konkrétne príklady problémov, keď je použitie OOP na škodu?
Zaujalo Ta to... tak som Ti povedal. Skusil si naprogramovat Aho-Corasick? Cerveno-cierny strom? Ja ano a nemam tam ziadne OOP, lebo sa mi to nevidi vhodne. Ak nepocitam cely ten kod obalit to nejakej triedy... Tu studenti, ktori zacinali s OOP tak pchaju OOP vsade. Pisu kvalitne OOP ale znasilnuju ho tam, kde sa nehodi. Sami uznali, ked si zacali porovnavat kody, ze Java/C# nebola najstastnejsia volba na zaciatok... (ked videli kod ludi, ktori zacinali C/C++, Haskell, Erlang, Lisp ...) (podla mna preto, lebo mozog bavit sa ucit OOP aj uz zvladne veci predtym ale ak uz pouziva OOP tak ho nebavi sa vraciat k veciam pred nim)
A to je to cele nedoruzemie a cely tvoj problem. Hrate na sa na individualny pristup a a idete na to masovo. Rovno Javou, ktora sa bezproblemov naucit z netu.
Ja si zaciatocnika predtavujem trochu inac, nemasovo. Predpokladam, ze masovy student nezacne programovat v 13-16 rokoch a pocka si na skolu, ved tam sa nauci. Nebavim sa ako ma zacat prvak na vysokej skole, lebo je to bezpredmetne. Ak zacne byt masovy, tak si pocka do vysky atd...
Skor predpokladam nemasovaho cloveka a snazim sa mu ukazat, ze jazyky Java/C# vsebe zahrnuju vsetko a musi so vsetkym zapasit naraz a s velkej casti ich pouzivaju masy, teda asi to nebude az taky problem zvladnut. Tvoj cely predmet paz1c za mojich cias sa nauci priemerny schopny student za tyzden. Teraz neviem, aku tam mate stavbu ale v Jave nie je problem ani siet ani vlakna. Clovek, ktory vie uvazovat a programovaval inde, tak sa za 2-3 tyzdne nauci vase 3 semestre Javy.
No ak ked predpokladam nemasovaho citatela, tak sa skor snazim ukazat nemasove moznosti, ktore sa hodia aj v praxi. Teraz prisla do Prahy z Londyna firma a hlada ludi na programovanie v Haskell (dalsi specialny pripad). A tych specialnych pripadov je vela, masa je iba jedna... Tot moja logika.
V tom sa lisime. Ja sa nesnazim prilakat masy k programovaniu...Snazim sa tomu, kto naozaj chce, ukazat co najviac moznosti.
Myslim si, ze programovanie urcite nie je cinnost, ktora by mala lakat masy...
-
Ale ja stale nechapem, preco je kvalitne napisane OOP pre efektivne napisany algoritmus zle.
Co sa tyka Javy, nebudem ju branit zubami nechtami, napr. moj sen je urobit experimentalny kurz pre uplnych zaciatocnikov.
Ostatne argumenty su ale velmi ovplyvnene tym, ze ked uz clovek nieco ovlada a ma za sebou skusenosti, tak sa mu ovela lahsie diva na omyly minulosti... problem je vsak to, ako naucit cloveka, ktory ziadne skusenosti nema a teda nevie porovnavat. Inak povedane, cim viac jazykov jednej paradigmy ovladam, tym lahsie sa mi migruje na iny jazyk, pretoze je to obvykle len syntakticky cukor.
Napr. velmi rad by som videl ucenie zaciatocnikov v Haskelli (nejake skusenosti?), viem totiz, ze na MIT mali (a asi aj maju) zauzivanu vyucbu uvodneho kurzu v Lispe.
A mame tu dva problemy:
a) cloveka, ktory sa pytal, cim zacat
b) a masy studentov, ktore chodia studovat informatiku na rozlicne skoly.
Cielom by malo ulahcit pristup a nezaujimat elitarsky postoj, kde sa povie, ze tento odbor nie je pre masy, pretoze to je unik od riesenia.
-
iwtu - jenžeš algoritmy nejsou všechno. Zrovna takovej červenočervenej strom v podstatě pochopí a napíše každej blb. A kdo ne, tak nemá šanci se naučit programovat.
Jenže pak přijde okamžik, kdy máš ten červenočervenej strom použít. A tam už se opoužití OOP nevyhneš.
Samozřejmě jsou špičkoví odborníci, který např vymejšlej co nejefektivnější IO plánovač. Tam se uplatní hlavně algoritmizace a jen okrajově o OOP. Ale stejně tak musí při psaní jádra existovat člověk, kterej vůbec vymyslí, že tam bude nějakej plánovač, že bude mít zodpovědnost za todle, že bude se zbytkem systému komunikovat takhle atd... A to je doména, kde bude excelovat člověk s dobrým OO myšlením.
Tím netvrdím, že lepení komponent k sobě je vrchol programování. Ale mezi lepením komponent a psaním algoritmu je ještě velkej prostor. Např. kdyby se OO návrh dodržoval při psaní linux kernelu, tak by se teď nemusel odstraňovat big kernel lock... Když se koukneš na vývoj kernelu, tak bych řekl, že daleko víc problémů je dáno špatným původním návrhem, kdy se to teď snaží zlepšit, aniž by porušili zpětnou kompatibilitu, než špatných algoritmů, které je třeba vylepšit (špatný algoritmus se snadno nahradí, špatný návrh nikoli).
Nebo naopak - jací jsou Ti nejhorší programátoři? Lepiši komponent. Z toho vyplývá, že lepit komponenty je evidentně nejednodušší k pochopení. Takže rozhodně jedna z dobrých cest, jak se naučit programovat je začít lepit komponenty. Navíc je to "povzbuzující", protože je daleko dříve vidět hezký výsledek. Samozřejmě, chytrej člověk u toho lepení komponent nesmí zůstat dlouho...
PS: A i u toho RB stromu se částečně využije OO myšlení - jednotlivé nody jsou objekty a na psaní stromu se můžeš koukat jako na metody těch objektů. Samozřejmě třeba kvůli rychlosti nebudeš striktně vyžadovat zapouzdření apod., ale pokud se na ten RB strom "správně" podíváš, tak máš půl práce hotový. A to je přesně to OOP - umět se správně podívat na to, co píšeš.
-
Chtěl jsem napsat totéž co Logik. OOP člověk využije zejména při zapojování menších celků do větších. A i ty větší celky lze navrhovat jako objekty, aby se daly zapojit do dalších větších celků. Dokonce si myslím, že dobrý OOP návrh vede nejen k rychlejšímu lepení, ale kolikrát i k rychlejšímu kódu, byť se to nemusí na začátek zdát, protože všechno je slepení a tu vlastní práci dělá jen minimum kódu. Jenže třeba díky správnému návrhu to dělá efektivnějí.
Prostě OOP je zejména o zapojování černých krabiček a proto tomu začatečníkovi bych objektový jazyk doporučil. Zrovna třeba Java, kde jsou výsledky hned vidět, napsat UI aplikaci lze za pár hodin a to člověk nemusí vytvářet dokonalé objekty hned na začátku. Ale obecná objektová architektura ho donutí (snad) se nad tím zamyslet a psát to podobně, jako jsou navrženy všechny Javovské knihovny.
-
Ano, ale aj tie mensie celky by mal podla mna vediet programator spravit. nie iba lepit dokopy.
alef0: Nemate uplnych zaciatocnikov a nezacinaju v Jave? Tusim Viliam Bur tak experimentoval s Javou. Vysledok bol, ze lepenim dokazali spravit uzasne veci ale nevedeli utriedit 4 cisla.
Dalej, pokial je mi zname, ludia co maju cosi odprogramovane a chytia do ruky Javu, pisu v nej povacsine lepsi kod ako ti, ktori videli iba Javu.
Osobne poznam vela programatorv C/C++, ktori dostali ponuku na projekt v Jave, vzali ho a dari sa im. Su lepsi ako nativni Javisti povacsine. Ale opacne pripady, velmi, nepoznam... Ludia co zacinali s Javou, vacsinou uz pri Jave ostali a C++, Erlang, Lips su im uplne cudzie. Neviem, mate nejake ine skusenosti? Mne osobne pride lepsie mat skusenosti aj s C aj Java aj Erlang atd... ako iba Java.
Vela ludi obhajuje LISP ako jazyk vhodny na zaciatok... Ono pohlad na data ako celok programu moze byt zaujimavy...
Cely cas, ze kvalitny programator by nemal vediet iba lepit male krabicky, ale aj ich naprogramovat.
Ja si osobne predstavujem kvalitneho programatora/analytika ako cloveka, ktory pozna technologie a vie zvolit tu nalepsiu, z programovacich jazykov zvolit ten spravny (casto krat je velmi vhodna volba Erlang), vedomost o algoritmoch, vymysliat vlastne algoritmy, vediet co nejde za danych podmienok vediet riesit efektivne a tak nejako.
A moje osobne skusenosti vravia, ze Javisti skoncia na Jave a nic okrem nej a C# nic okrem C#, to sa mi vidi s v rozpore s mojou predstavou kvalitneho programatora/analytika.
Programovanie sa nevidi ako masova cinnost. Masova cinnost mi pride sex, prijem potravy a vylucovanie. Tak ako sa nemoze kazdy zivit hudbou, tak podla mna ani programovanim.
Logik... Skus sa pre srandu opytat, kolko ludi naprogramovalo cerveno cierny strom a kolkno z nich by som naprogramovalo za den ;)
Ani medicina nie je podla mna pre kazdeho ani nic (okrem vyssie vymenovanych cinnosti vyplyvajuce zo zivocisnej podstaty cloveka). Nevidim dovod, preco by malo byt programovanie pre masy...
Poznate ludi, ktory zacinali s Javou/C# a vedia schopne aj nieco ine? Ja iba velmi malo vynimiek...
-
iwtu: Ale my nikdo nepopíráme, že kvalitní programátor se nemusí učit takový věci, jako RB strom. Jen že není potřeba, by to dělal hned od začátku. Je to určitě jedna z možných cest, ale rozhodně ne jediná a já osobně nevím, jestli nejlepší.
Osobně si myslím, že ať už člověk začne s OOP, nebo s algoritmizací, tak by měl hodně rychle začít i ten druhej směr - jeden bez druhýho v podstatě nemůže existovat.
Co se týče dobrejch a špatnejch javistů a C++, tak Java je mladá, takže ji uměj mladý ucha, zatimco starý zkušený programátoři se učili v C++. Popř mladý schopný se učili od starejch schopnejch.. zas C++.
Ono to dost často vypadá (na školách), že učit v javě znamená učit jakoby pascal, akorát v javovský syntaxi. A to je blbina. To ale neznamená, že nejde dobře učit v javě.
-
Co se týče dobrejch a špatnejch javistů a C++, tak Java je mladá, takže ji uměj mladý ucha, zatimco starý zkušený programátoři se učili v C++. Popř mladý schopný se učili od starejch schopnejch.. zas C++.
Ono to dost často vypadá (na školách), že učit v javě znamená učit jakoby pascal, akorát v javovský syntaxi. A to je blbina. To ale neznamená, že nejde dobře učit v javě.
Nevravim, ze nejde dobre ucit v Jave. Na jednej strane viem o kopec prasicov v Jave a na druhe viem aj o kopec Ceckarov, ktory sa rychlo naucili Javu a robia v nej lepsi kod ako ti prvy. To je dovod, preco neodporucam zacat s Java/C#, lebo neviem o dobrych (podla mna) programatorov, ktori zacinali Java/C#.
Nikomu nebranim v Jave experimentovat a priniest nejaku novu metodologiu. Ale z mojich doterazsich poznatkov je dost nizka sanca aby takto vznikol kvalitny programator. To je vsetko, co vravim :)
Preto ja osobne neodporucam...
-
Kdo umí C, je dobrej a inteligentní programátor.
Kdo umí javu, je většinou břídil.
Je třeba dodat, že java programátorů oproti C programátorům je v poslední době více
(Cčko se už skoro bohužel neučí) a že existuje i dobrej Java programátor.
Co z toho plyne? IMHO nikoli: "neučte se javu, udělá z vás blbce", ale "javu se naučí i blbec". IMHO je to spíš argument proto, aby se začlo s Javou :-)
-
Budiz flame ...
je lepsi zacit s vysokourovnovym programovanim / nizkourovnovym ... ma cenu zacinat s jazyky "pro vyuku programovani" / nebo s realne pouzitelnymy ??? ... tot vec nazoru.
Podle me ma cenu zacit s tim, co clovek potrebuje nebo chce pouzivat. Praxe je totiz praxe.
Osobne jsem zacinal s C (Podle knihy od Pavla Herouta) a rozhodne nelituju. Kdyz se uci matematika tak se taky zacina se zakladnima operacema, scitani, odcitani, nasobeni a postupuje se k slozitejsim vecem. Clovek tak totiz porad vi oc jde ... Kdyz se neco preskoci (napr. jazyky s GC) clovek se nemusi starat o pamet a tim padem si neuvedomi, ze sprava pameti take neco stoji. Stejne jako ostatni operace - muze pak klidne psat "prvni varianta" == "prvni varianta" misto PRVNI_VARIANTA == PRVNI_VARIANTA ... a nemusi se starat, vzdyt to za nej jazyk vsechno poresi ...
Trochu mi to pripomelo jednoho "programatora" ve flashi, ktery v nicem jinem neumel a delal webovou aplikaci. O TCP/IP nemel ani paru a vsecho co znal bylo RTAP, Stream a Shared Object ... kouzelne objekty, ktere zajistuji ze objekt na jedne strane je stejny jako objekt na strane druhe .... zkuste takovemu cloveku neco rict o optimalizaci nebo s nim vubec cokoli resit ... jedineho ceho se dockate je halda Adobe terminologie a nic nevyresite.
-
Kdo umí C, je dobrej a inteligentní programátor.
Kdo umí javu, je většinou břídil.
Je třeba dodat, že java programátorů oproti C programátorům je v poslední době více
(Cčko se už skoro bohužel neučí) a že existuje i dobrej Java programátor.
Co z toho plyne? IMHO nikoli: "neučte se javu, udělá z vás blbce", ale "javu se naučí i blbec". IMHO je to spíš argument proto, aby se začlo s Javou :-)
Ako kto to berie takto, tak Java pre neho jeden s najlepsich jazykov (ja osobne by som ho nezamestnal, no kopec firiem ano). Verim, ze ide o to, ako to clovek berie. Ja osobne od mojich styroch rokov, kde som prvy krat videl PMD, chcem byt programator. Lebo ma bavi mysliet a chcem vediet principy, ako funguje PC atd. Nechcem programovat zfleku magicke veci, ale chcem rozumiet principom a potom podla toho, co treba. Mne osobne pride krajsie programovat nejake API, lebo nad API bezi uz nieco ine, co je obmedzene tym API, teda musi byt API vyoptimalizovane a mam zmysel tam uvazovat prirodzene. Prirodzene je pre mna, aj usetrit jeden bite ak mam k dispozicii 512B a dost. Mne na tej nizsiej urovni pride myslenie prirodzenejsie. Zas bavi ma aj pisat specifikacie a robit OOP navrh, ale uz podstatne menej to vsetko kodit, pride mi to taka rutinna praca. Ale to su veci specificke pre mna ale viem, ze nie som takto zmyslajuci sam.
Nekdo zacinal s C a nelutuje toho a ver, ze takych ludi je velmi vela ako on. Plus ma podla mna pravdu v tom, ze by na uvod mohlo byt nieco prakticke. Ked chce clovek zistit, ci by bavilo algoritmicky uvazovat atd, ako vhodna volba je napr. Python (pascal je nepouzitelny a clovek sa s nim a jeho strasnou syntaxou uz nestretne) Odstieni co najviac od vsetkych technickych veci, co najviac sa zamera na logiku programu, teda jeho ucenie by malo ist pomerne rychlo a v praxi sa naozaj vyuziva, lebo sa v nom daju rychlo robit nie uplne trivialne veci. Plus je na druhe spustenie celkom rychly, ked uz je .pyc. Preto je taky hybrid medzi imperativnych a skriptovacim jazykom... Bruce Eckel casto pise az na Python...
Potom by nebolo na skodu napriklad C, ktore je podstatne jednoduchsie ako C++ a ukazuje veci, ako su. Z toho principialneho hladiska. Ale okrem C by nebol na skodu ani Erlang a podobne jazyky. Sice uz velmi nebude zapasit s algorimizaciou (tu by mal mal zvadnutu s Pythonu) ale s implementaciou. Co pri pride fajn, lebo si bude isty, ze je chyba s implementaciu a nie v logike programu (ako by si mohol mysliet, keby s tym zacinal rovno).
Ono da sa pokracovat aj zacat s C++, ale bez kvalitnej knihy to bude znacne kontraproduktivne.
Potom moze byt aj kludne Java a bude velmi schopny programator v Jave a mu to pojde rychlo.
Univerzalna odpoved nie je, malo by to byt silno podmieneme tym, o co zaciatocnikovi ide. Ked chce programovat webove stranky, tak PHP a uplne zbytocne mu je tlacit do hlavy nejaku Javu ci C. Na druhej strane, Python tlacit do hlavy nemusi byt na skodu nikdy (posednu vetu som len tak tresol, lebo fakt ma nepride zbytocne s nim zacinat, nenapada ma rychlo preco...)...
Ked chce programovanim co najskor zarabat a ide mu iba o to, nech sa paci, kludne Java, C# a ine masy...
Ked chce rovno programovat nejake hry, tak Game Maker je priam idealna vec pre neho...
Mozno tu boli tendencie hladat univezalnu odpoved, ale myslim si, ze odpoved je silno podmienena tym, co dany clovek chce...
-
Docla obsahlou odpoved o tomhle jsem napsal jsem:
http://forum.root.cz/index.php?topic=1143.0
prispevek od Ivan: « Odpověď #34 kdy: Dnes v 23:10:25 »
Mam pres 15 let zkusenosti s programovanim, ziskal jsem i nekolik oceneni a po tom vsem co znam doporucuji si odpovedet na zakladni otazky "proc chces programovat". jestli kvuli zabave, jdi do C# (desktop) a ASP.NET (web). Checes-li kvuli penezum, ber Javu.
Z DB platforem, chces-li efektivitu a technologicky nejvyspelepsi DB za rozumnou cenu ber Firebird, chces-li byt "in" ber MS SQL Server, chces-li hodne penez a nevadi te donekonecna se s*at se zbyetcnymi problemy jdi do Oracle. Chces-li nejvykonnejdi databazu na obrovske mnoztsvi dat jdi to Teradata.
-
Docla obsahlou odpoved o tomhle jsem napsal jsem:
http://forum.root.cz/index.php?topic=1143.0
prispevek od Ivan: « Odpověď #34 kdy: Dnes v 23:10:25 »
Mam pres 15 let zkusenosti s programovanim, ziskal jsem i nekolik oceneni a po tom vsem co znam doporucuji si odpovedet na zakladni otazky "proc chces programovat". jestli kvuli zabave, jdi do C# (desktop) a ASP.NET (web). Checes-li kvuli penezum, ber Javu.
Z DB platforem, chces-li efektivitu a technologicky nejvyspelepsi DB za rozumnou cenu ber Firebird, chces-li byt "in" ber MS SQL Server, chces-li hodne penez a nevadi te donekonecna se s*at se zbyetcnymi problemy jdi do Oracle. Chces-li nejvykonnejdi databazu na obrovske mnoztsvi dat jdi to Teradata.
No jednou bych se tím i rád živil. Ovšem netrvám na tom.
Chtěl bych ale jít studovat informatiku na VŠ, předpokládám, že mi vyjde Brno MU či ČVUT.
Samozřejmě bych si rád spravil nějaký ten užitečný software, jak pro sebe, tak pro širší veřejnost či pro přítelkyni. Game maker znám a zdá se mi, že hry v něm zabírají hrozně moc místa na disku a berou si velmi mnoho paměti.
Velmi uvažuji, že začnu s C pak přejdu na C++ či C# , podívám se také na Javu a ASP, na tu Javu bych se rád pozdějí zaměřil. Ale nechci vynechat C.
Navíc chci psát kod správně a srozumitelně, tak abych ho za pár let pochopil, kdybych se k němu vrátil.
Kdybyste byl někdo tak hodný a řekl mi jestli a popřípadě kde jste studovali. Také co.
Omlouvám se za svůj pravopis, jsem poměrně unavený.
-
Cčko se už skoro bohužel neučí
Jetli myslíte VŠ, tak právě naopak :) Každá kvalitnější škola chce naučit principy a jde od základů výš a výš. Proto se skoro všude setkáte s Assemblerem a Cčkem.
-
@Jakub ja som obycajny priemerny student matfyzu :-) Poznam ludi, co programuju v google, vyhravaju medzinarodne informaticke olympiady, dokonca aj pre vymyslaju ulohy atd. Naozaj si myslim, ze poznam hodne kvalitne dobrych ludi, ktorym nesiaham ani po paty :-)
Ti ludia maju par veci spolocnych. Jednak sa prestali uz zaujimat o podobne diskusie. Casto krat maju skusenosti viac ako 15 rokov a ich ocenenia si davaju doma pod koberec...
Dalej dnes je Java/C# najvacsi boom. Preto pocet programatorov rapidne stupol, ale pocet dobrych sa nejako nemeni. Ano, v globalne vrami statu zarabaju ti ludia nadpiemerne. Ale oproti programatorovi C,C++, Erlang, Assembler v banke je to stale smiesna suma... Jednoducho preto, ze ti ludia su naozaj dobri a je ich malo. Javistov/C#istov je daleko viac, i ked stale asi nimi nie je nasyteni trh...
Dalsie pozorovanie je, ze zacinaju silno do popredia prenikat webove aplikacie. Ono ich vyhoda, ze staci updatovat iba raz na jednom mieste + nemusis riesit rozne OS je pomerne silna..
P.S. Ti spickovi ludia, ktorych poznam, ak uz nahodou aj na nejakom fore su, tak maju profil a maju svoje meno aj priezvisko. Vies, nejaky Ivan si aj o sebe a ocividne aj programovani moze tvrdit hocico...
Ja som registrovany na abclinuxu, kde mam aj nejaky blog atd... a zasa viem, ze som priemerny student (bol som tu uz aj odhaleny :-P), teda moj nazor okrem tych myslienok v nom nema ziadnu vahu. Mozno keby sme sa bavili o matfyze, tak by nejaku mal, kedze tam studujem ale inac ma hodnotu iba holych slov a myslienok...
Len som Ti chcel povedat, ze never kazdemu, kto nema ani meno/priezvisko a o sebe tvrdi, ze ma 15 rokov skusenosti a niekolko oceneni. Tie ocenenia tiez vyzneju casto na myknutie ramenami... Najviac sa asi pocita to, za cim realne stoji, co spravil. Teda nie, mam 15 rokov skusenosti ale spravil som to a to... Skor na Slovensku mame takych ludi, co o sebe tvrdia, ze maju n rokov skusenosti a dokopy za tie roky nic nespravili... Ale potom uz treba davat pozor na prehnanu uctu :-)
-
No jednou bych se tím i rád živil. Ovšem netrvám na tom.
IMHO je dulezite si rozmyslet, zda se tim chces zivit nebo ne. Programovani je jako umeni. Bud mas talent a budes spicka, nebo to delas protoze musis a budes bezny znudeny prumer, ktery si odkrouti svych osm hodin a jde domu. Ja tvrdim, ze clovek, ktereho to nebavi, by to nemel delat. Bohuzel dnes mnoho mladych lidi mysli jen na to, ze v IT jsou velke penize. Ale to uz neni pravda. Z IT se stava klasicka delnicka profese a i jejich prijem se zacina normalizovat. Boom IT je uz davno pryc. Navic IT ma proti jinym profesim jeste jednu zasadni nevyhodu a tou je to, ze staci jedna firma na jeden svet aby dodala vsem svuj produkt, takze na SW odvetvi ma globalizace nejradikalnejsi vliv. Neprodavam hmotu, nas produkt si muze stahnout kdokoliv. Budoucnost v IT je proto znacne nejista a bude patrit pouze spickam.
Game maker znám a zdá se mi, že hry v něm zabírají hrozně moc místa na disku a berou si velmi mnoho paměti.
Velikost dat v dnesni dobe 25+ GB Blu Ray disku a 2+ TB HDD, jiz opravdu NEMA smysl resit. Velikost jiz opravdu nikdo neresi, zapomen na to. Zbytecna brzda, naprosto nezajimavy parametr.
Velmi uvažuji, že začnu s C pak přejdu na C++ či C# , podívám se také na Javu a ASP, na tu Javu bych se rád pozdějí zaměřil. Ale nechci vynechat C.
Navíc chci psát kod správně a srozumitelně, tak abych ho za pár let pochopil, kdybych se k němu vrátil.
Kdybyste byl někdo tak hodný a řekl mi jestli a popřípadě kde jste studovali. Také co.
Studium nerozhoduje o tom, zda budes v praci uspesny nebo ne!
Titul Ti ovsem otevre vice dveri a ulehci Ti nastup, takze je dobre ho mit. Prilis nezalezi na tom jaky titul. Klienty to nezajima vubec a zamestnavatele zajima praxe a znalosti vic nez titul.
Ovsem chces-li pusobit na technickych postech, tak je samozrejme lepsi mit technickou skolu. ;-)
Ja osobne, po zkusenostech ktere mam, absolutne nehledim na VS, kterou uchazec ma, ale hledim na to, zda je jeho stredni, nebo VS technicka. A jak uz jsem zminil, kdyby prisel na pohovor clovek se zakladni skolou a predvedl mi, ze ma za sebou nejaky dobry produkt a ze to umi, tak ho vemu taky. To co me vydelava penize je produktivita a ne tituly.
-
Velmi uvažuji, že začnu s C pak přejdu na C++ či C# , podívám se také na Javu a ASP, na tu Javu bych se rád pozdějí zaměřil. Ale nechci vynechat C.
Navíc chci psát kod správně a srozumitelně, tak abych ho za pár let pochopil, kdybych se k němu vrátil.
Jeste tohle jsem zapomel.... Svym programovanim se budes ucit a vyvijet a kdyz se vratis ke kodu, ktery jsi delal pred 3 roky, tak vzdy budes koukat, jak jsi mohl napsat takovy paskvil. Takze to moc neres, aspon ne ze zacatku. Po 10 letech programovani budes mit jiste nejake navyky, ale ze zacatku to bude turbolence. Navic kdyz delas spravny OOP vyvoj v modernim jazyku, ke staremu kodu se prilis casto nepotrebujes vracet.
A hlavne si vyber jazyk a ten se uc poradne. Kdyz mi nekdo do zivotopisu napise, ze umi 6 jazyku, tak ten zivotpis okamzite hazim do kose, protoze je jasny, ze neumi poradne ani jeden. To proste v dnesni turbolentni dobe neni mozne umet vic nez 2 jazyky poradne. Navic uvadet znalost jazyku, se kterymi si naposledy pracoval 5 let zpatky taky nema smysl. Jednak je ten jazyk uz uplne nekde jinde a jednak si ho uz stejne nemuzes efektivne pamatovat.
-
Len som Ti chcel povedat, ze never kazdemu, kto nema ani meno/priezvisko a o sebe tvrdi, ze ma ...
To je u vas na slovensku nejaka nabozenska specialita "vodu kazat a vino pit"? Nebo je snad tve jmeno a pijmeni "iwtu iwtu"?
Ja jsem sve argumenty uvedl a myslim, ze i logicky zduvodnil, takze kazdy si muze udelat obrazek o tom, zda zkusenosti mam nebo ne i bez toho, abych se tady predstavoval vic nez jsem to udelal. Jako spravny ajtak Jsem totiz paranoik...
Moji IT kolegove se titoz zivi sledovanim lidi na netu a vytvarenim jejich pohybu.
-
No když jsem to tak prošel, zjistil jsem že podle mnohých je nejlepší začít tak a tak. Nakonec to vidím stejně tak, že prostě začnu v jazyce který mě bude ze začátku vyhovovat nejvíce, bude mít pro mě smysluplnou syntaxi. Ze začátku stejně nebudu psát kódy o délce xy řádků. Takže nejdůležitější pro mě bude pochopení správného fungování toho a onoho a jeho správné užití ve správnou chvíli. Jednoduše se učit, se učit, se učit. A hlavně zkoušet.
Chci poděkovat všem kdo přispěli do diskuze, víc hlav víc ví, aspoň se to říká.
Moc děkuju.
-
Jazyk pro začátečníka (chápe ho i můj 5 letý syn) ;D
http://www.superhry.cz/games/1734
-
Jedině Céčko.
-
IMHO je na naucenie pre uplneho zaciatocnika najlepsi Pascal (v tomto suhlasim s Martinom Maresom, ktory to dobre rozobral na svojich strankach http://mj.ucw.cz/papers/proglang.html (http://mj.ucw.cz/papers/proglang.html)).
-
Rozpoutejme poradny flame!
- Python
- Ruby
- Smalltalk
- Ada
- Eiffel
- Erlang
- Clojure
- Cobol
- Fortran
- R
-
Osobne bych doporucoval Ruby. Kdybych nezacinal na PHP, urcite bych do nej sel (ted uz se bude dost tezko presedlavat).
-
Co všichni máte proti Céčku? Já bych řekl, že znalost C je základ. Navíc, dost jazyků z něho vychází. Ano, C je těžký jazyk pro začátečníka, ale programování samo sobě je těžké. Já se také teprve učím programovat, pravděpodobně se tím živit nebudu. Mám to spíše jako koníček. Ale programování beru jako záležitost na celý život. Vtipné je, že i když se člověk učí C, C++, stromy, grafy, dva, tři roky, tak stejně nenapíše nic zajímavého. Ale jen nějaké nudné prográmky pro příkazovou řádku. Takže se člověk musí naučit různé knihovny, jako třeba ncurses, gtk, qt, sdl, opengl, socket atd. Programování je prostě velice zapeklitý svazek na celý život. Tak tahle já vidím programování, a to jsem ještě nic velkého nenapsal, ha ha, ale už mám pár nápadů.
-
Programování je pro mě hobby, nicméně když do něčeho investuju čas, chtěl bych aby mě to mohlo v budoucnu živit...
Mohl by mi někdo zkušenej poskytnout názor, jakýmu jazyku se vyplatí věnovat?
Prošel jsem základama assembleru, 1díl herouta v C, okrajový nahlídnutí do Javy a Pascalu, aplikace do 1000 řádků v C#(ADO.NET, win. forms) a teď jeden nepatrně rozsáhlejší projekt v PHP ...; C-like syntaxe mi vyhovuje, s OOP to pokud možno nepřehánět, efektivita programu je důležitá, ale rychlost vývoje zrovna tak. Java mi přišla vysloveně neintuitivní. Láká a děsí mě zároveň C++. Co se finančního prospěchu týče, více kšeftů mají vývojáři webových aplikací Zajímalo by mě srovnání PHP, Pythonu a (úchylně objektovýho ;)) Ruby.
-
Co se finančního prospěchu týče, více kšeftů mají vývojáři webových aplikací Zajímalo by mě srovnání PHP, Pythonu a (úchylně objektovýho ;)) Ruby.
Pokud ti jde o hodně kšeftů, tak rozhodně PHP. Ostatní nejsou tak častý, na druhou stranu líp placený.
BTW, styl Javy a PHP mi silně vyhovuje, Ruby má dost zvláštní syntax a třeba já si na ni prostě nezvyknul. Každopádně, pokud se tím budeš chtít živit a brát to vážně, počítej s OOP a věcmi jako MVC frameworky.
-
Jediná správná volba pro začátečníka je assembler.
-
Podľa mňa najlepšie je začať sa učiť ten jazyk, ktorý budeš v budúcnosti najviac potrebovať. Pokiaľ vieš, že chceš ísť na vysokú školu tak podľa mňa najlepšie je zvoliť c-čko, lebo na vysokých školách už o pár rokov ani nebudú žiaci vedieť čo je pascal ale zato väčšina z nich bude c-čko dokonale ovládať (pred pár rokmi sa na stredných školách masovo začalo učiť c-čko) a keď budeš potrebovať s dačím pomôcť nebudeš musieť chodiť ďaleko.. a zvyšné jazyky ťa výška naučí :)..
Pokiaľ chceš ísť robiť web, tak sa začni učiť rovno php, pokiaľ chceš ísť robiť aplikácie pre windows tak rovno C#, pokiaľ multiplatform aplikácie rovno java, pokiaľ linux aplikácie rovno c/c++, atď.
Podľa mňa je blbosť učiť sa viac jazykov / prechádzať z jazyku na jazyk atď, lebo sa to dosť pletie.. napr. my sa v škole (gymnázium) učíme pascal, doma sa učim programovať v C++ (chcem ísť na matfyz študovať info :)) (základy OOP už mám za sebou, teraz sa učím SDL a OpenGL), a nehorázne sa mi to pletie, ešte si neviem predstaviť čo budem robiť keď náhodou budem potrebovať dačo spraviť v niečom inom :)
-
Ja by som na tvojom mieste začal s F#
http://cs.wikipedia.org/wiki/F_Sharp
alebo niečim čo vychádza z rodiny jazykov ML (F#, Caml, Ocaml).
jazyk F# má jednoduchú a ľahko pochopiteľnú syntax aj pre začiatočnikov je multiparadigmický takže umožňuje programovať všetkými možnými spôsobmi hlavne funkcionálne ale aj imperatívne (narozdiel od haskellu obsahuje aj mutable premenné a cykly, ale ideálne je ich nepoužívať). A hlavne je minimalistický, kód v F# je niekedy až o 50% kratší ako v Jave alebo C#.
Ak chceš začať s F#, tak by som ti odporučil tento tutorial od Tomáša Petríčka
http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-I
http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-II
http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-III
http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-IV
viac info o jazyku je na:
-MSDN (http://msdn.microsoft.com/library/dd233154(VS.100).aspx)
-a na tomto blogu http://blogs.msdn.com/b/chrsmith/
-
Multiparadigmový jazyk typu F#, Scala nebo Clojure je možná vhodný pro začátečníka, ale s dobrým vedením. Určitě ne pro samouka, který se jej chce začít učit z pár tutoriálů na netu.
Je potřeba vědět, kdy které paradigma použít, na které problémy se hodí, co v konkrétním případě přinese a jaká bude výsledná čitelnost kódu. Bez předchozích zkušeností nebo vedoucího, který Ti neustále stojí za zadkem, vždycky vznikne polofungující bastl, čímž se každému programování tak možná znechutí.
Zrovna u F# musíš řešit napojení na C# (F# a C# kolekce jsou občas trochu problém, neb jsou jiné, v F# nefungují některé implicitní konverze - např. když vytváříš XElement, tak nefunguje implicitní konverze System.String na XName, což znamená, že v C# můžeš napsat XElement elem = new XElement("můjPrvníXmlElement");, ale v F# už musíš vytvořit něco takového:
let xn s = new XName(s)
let elem = new XElement(xn "můjPrvníElement)
atp.; jenomže tohle Ti málokdo dopředu řekne). Je tam prostě pár temných zákoutí a "ostrých hran". A pokud budeš chtít dělat grafické rozhraní, určitě ho nebudeš chtít psát ručně, ale sáhneš po grafickém editoru, který je ve Visual Studiu ... ten Ti ale generuje jen C# kód, takže se řešení podobných kravin nevyhneš a de facto se budeš muset učit oba jazyky.
Tvůrci F# se sice chvástají, že je F# plně integrovaný do VisualStudia, ale není to pravda. Je to jenom takový "chudý příbuzný". Nefunguje tam např. zobrazování hierarchie funkcí a tříd (musíš procházet každý modul shora dolů, když něco hledáš ... nějaké "class view" nebo něco takového neexistuje), v F# shellu nefunguje doplňování kódu, zdroje informací jsou trochu omezené ... furt Tě prostě bude něco štvát.
F# je zajímavý jazyk, ne že ne, ale neustále Tě bude něco štvát. A ani další dva mnou jmenované jazyky nejsou úplnou výhrou - Scala je "scalable language", což s sebou nese to, že spoustu věcí v syntaxi lze vynechat a celkově komplexní syntax (neříkám složitou, jen je jí hodně a program může vypadat pokaždé jinak). Zato je ale její základ shodný s Javou. Clojure má sice krásnou a jednoduchou syntax, ale LISPového typu. Vzhledem k tomu, že se stejně nevyhneš spolupráci s Javou (minimálně u grafického rozhraní), tak se budeš muset učit, stejně jako v případě F#(ML syntax)/C# (Céčkoidní syntaxe), 2 syntakticky rozdílné jazyky.
Spíš se poohlédni po jazyuku jako je Ruby nebo Python. Jsou to sice "jen" skriptovací jazyky, ale mají dobré informační zdroje a slušná vývojová prostředí (např. Eclipse/NetBeans) a přestože jejich interprety jsou občas dost omezené (např. o konkurenčním programování si můžeš nechat jen zdát kvůli tomu, že všechno běží "v jednom vlákně") a dělat v nich opravdu rozsáhlé aplikace není z hlediska paměťových ani výkonnostních moc dobrý nápad, na naučení se a psaní jednoduchých skriptů či okenních aplikací jsou super. A informačních zdrojů je, zvlášť v případě Pythonu, opravdu přehršel.
-
Podľa mňa je blbosť učiť sa viac jazykov / prechádzať z jazyku na jazyk atď, lebo sa to dosť pletie.. napr. my sa v škole (gymnázium) učíme pascal, doma sa učim programovať v C++ (chcem ísť na matfyz študovať info :)) (základy OOP už mám za sebou, teraz sa učím SDL a OpenGL), a nehorázne sa mi to pletie, ešte si neviem predstaviť čo budem robiť keď náhodou budem potrebovať dačo spraviť v niečom inom :)
S trochou praxe se Ti to plést nebude. Já můžu psát v několika odlišných jazycích (C++, Scala, Python...) ten samý den a nemám s tím problém. Problém je, když s nějakým jazykem začínáš a mozek si na něj teprve zvyká. Kdysi jsem musel (trochu z jiného soudku) po několikaměsíčním každodenním používání Vimu použít Visual Studio, pořád jsem chtěl mačkat Escape a měnit režimy editoru. Dnes mi nedělá problém psát v jednom editoru "klasicky" a pak přejít do Vimu a zase zpět.
-
F# je zajímavý jazyk, ne že ne, ale neustále Tě bude něco štvát. A ani další dva mnou jmenované jazyky nejsou úplnou výhrou - Scala je "scalable language", což s sebou nese to, že spoustu věcí v syntaxi lze vynechat a celkově komplexní syntax (neříkám složitou, jen je jí hodně a program může vypadat pokaždé jinak). Zato je ale její základ shodný s Javou. Clojure má sice krásnou a jednoduchou syntax, ale LISPového typu. Vzhledem k tomu, že se stejně nevyhneš spolupráci s Javou (minimálně u grafického rozhraní), tak se budeš muset učit, stejně jako v případě F#(ML syntax)/C# (Céčkoidní syntaxe), 2 syntakticky rozdílné jazyky.
Spíš se poohlédni po jazyuku jako je Ruby nebo Python. Jsou to sice "jen" skriptovací jazyky, ale mají dobré informační zdroje a slušná vývojová prostředí (např. Eclipse/NetBeans) a přestože jejich interprety jsou občas dost omezené (např. o konkurenčním programování si můžeš nechat jen zdát kvůli tomu, že všechno běží "v jednom vlákně") a dělat v nich opravdu rozsáhlé aplikace není z hlediska paměťových ani výkonnostních moc dobrý nápad, na naučení se a psaní jednoduchých skriptů či okenních aplikací jsou super. A informačních zdrojů je, zvlášť v případě Pythonu, opravdu přehršel.
Nemůžu mluvit za uživatele F#, ale se Scalou je možné začít v Java stylu (OOP a mutable proměnné) a možnosti FP přidávat postupně. Co se týče Pythonu, mám zkušenosti s opravdu velkými projekty a paměť ani rychlost nejsou problém (a místo vláken používáme procesy). Několikrát jsme ale narazili na meze typového systému (hlavně promíchané konstanty) - to je ale problém většiny často používaných jazyků. Jinak ale souhlasím; Python nebo Ruby do začátku nejsou špatné a F#, Scala nebo Clojure (to je fakt mezi dnešními jazyky trochu "exot") nebyly navrhovány pro potřeby začátečníků.
-
Nedávno jsem psal článek na toto téma Programujte snadno a zábavně. Koukni na to třeba tě to bude inspirovat.
http://novinky.enachod.cz/microsoft_small_basic/ (http://novinky.enachod.cz/microsoft_small_basic/)
-
Nedávno jsem psal článek na toto téma Programujte snadno a zábavně. Koukni na to třeba tě to bude inspirovat.
http://novinky.enachod.cz/microsoft_small_basic/ (http://novinky.enachod.cz/microsoft_small_basic/)
Ten článek je dost o ničem, spíš to vypadá jako reklama. Mě by zajímalo proč je ten jazyk vhodný pro začátečníky a v čem je třeba lepší než konkurence (kromě toho, že to je "ideální řešení pro programovací prostředí pro začátečníky"). Můžu si to najít, ale jsem líný, tak radši budu dál doporučovat osvědčeného karla.
-
Nedávno jsem psal článek na toto téma Programujte snadno a zábavně. Koukni na to třeba tě to bude inspirovat.
http://novinky.enachod.cz/microsoft_small_basic/ (http://novinky.enachod.cz/microsoft_small_basic/)
Ten článek je dost o ničem, spíš to vypadá jako reklama. Mě by zajímalo proč je ten jazyk vhodný pro začátečníky a v čem je třeba lepší než konkurence (kromě toho, že to je "ideální řešení pro programovací prostředí pro začátečníky"). Můžu si to najít, ale jsem líný, tak radši budu dál doporučovat osvědčeného karla.
Souhlas, reklama na článek, který je naprosto o ničem.
-
Thread jsem jen v rychlosti prolitl a chtel bych pridat svuj nazor.
K vyberu jazyka:
- pokud vas zajmaji webove, kancelarske a vsemozne enterprise aplikace a jde vam jen o to "nejak" programovat naucte se javu, popr C#
- pokud se chcete naucit programovat PORADNE naucte se C/C++
- z vlastni zkusenosti: jakykoliv bastl bude rychleji napsany v jave a bude pravdepodobne i rychleji bezet, nicmene kod od profika v C++ je proste kod od profika c C++ :)
Kdyz jsme tedy u C/C++ tak k vyberu prostredi:
- nekdo tu psal ze VS je nej ide na C++, to je bohuzel totalni nesmysl, bylo tomu tak pred nekolika lety, dnes silne zaostava jak za qt-creatorem tak kdevelopem (pravdepodobne i za netbeans a eclipse s C++ pluginem, ale to nemam overene)
- osobne vyvyjim v qt-creatoru s emulatorem vimu, projekty vetsinou v cmake (btw spousta lidi si mysli ze qt-creator je jen na Qt a C++, neni tomu tak, napsal sem v tom tisice radek v C pro embedded ARMy, tisice radek CUDA a desetitisice C++, ktere s Qt nemelo nic spolecneho
-
Nedávno jsem psal článek na toto téma Programujte snadno a zábavně. Koukni na to třeba tě to bude inspirovat.
http://novinky.enachod.cz/microsoft_small_basic/ (http://novinky.enachod.cz/microsoft_small_basic/)
Začínáš dobře: "Květen 17th,2011 V minulém týdnu představila společnost M..." Jenže on ten minulý týden byl v říjnu 2008!
Věta "Programovací prostředí se velice podobá QBasicu." se také poněkud nezakládá na pravdě, v mých vzpomínkách QB vypadá dost odlišně, tohle mi připomíná spíš nejnovější verze MS Office, bohužel. Není problém si nějaký QB stáhnout a vyzkoušet, uvidíš sám ten rozdíl ;-)
Takže abych to neprotahoval, jediná kladná věc na Small Basicu by mohla být zabudovaná želví grafika, ale pokus zkřížit Logo se zbytky zkomolených basicových příkazů opravdu není šťastný nápad. A ještě ho navíc tlačit do .NETu.
Navíc jako pamětník osmibitových dob, s vědomím že BASIC je dodnes můj nejoblíbenější jazyk a často ho používám, prohlašuji: "Ne, nic co má společného s jakýmkoliv Basicem (zejména od Microsoftu) není vhodné pro výuku, tím méně začátečníků!". To už radši Baltík, ten napáchá méně škody.
Takže jak výše zmínil aj, pro úplné začátečníky a děti Karel (v něm se dají dělat i hodně složité věci), potom Pascal nebo Python, dál podle toho k čemu bude dotyčný inklinovat. Případně podle zájmu zkusit to zmíněné Logo, Scratch, Alice...
-
Nedávno jsem psal článek na toto téma Programujte snadno a zábavně. Koukni na to třeba tě to bude inspirovat.
http://novinky.enachod.cz/microsoft_small_basic/ (http://novinky.enachod.cz/microsoft_small_basic/)
Upřímně tohle je dost o ničem. Když už by s tím chtěl někdo začít, tak muže rovnou začít na Visual Basicu (Express) se vším všudy a ne na téhle zvláštní verzi.
-
Prosim poradte:
S programovanim som zacal asi pred 5 mesiacmi, dovtedy som som ovladal akurat zaklady Pascalu, no predsalen nejake zaklady algoritmizacie som uz mal. Ako prvy jazyk som si zobral C++, snazil som sa osvojit si aj veci ako je pointrova aritmetika a OOP. Doteraz som robil ale iba prevazne male programy. Chcel by som sa posunut od konzoly dalej no neviem sa rozhodnut, ktory smer je pre mna najvhodnejsi. Z toho, co som v roznych forach vycital, mam asi tieto moznosti:
1. Zostat pri C++ + naucit sa urcitu GUI kniznicu, napr. Qt alebo C++ Builder
2. Zostat pri C++ + naucit sa nieco z grafiky, napr. SDL alebo OpenGL
3. Prejst na nieco rydzo prakticke: Java, C#
4. Na urcity cas sa venovat databazam, napr. MySQL
5. nechavam na vas...
Este by som chcel dodat, ze s programovanim to myslim vazne, pretoze sa o rok chystam IT studovat. Velakrat som cital, ze to, co najviac treba, je stanovit si urcity ciel, napr. vytvorenie urciteho konkretneho programu a az potom hladat prostriedky k tomu potrebne. Mam pocit, ze prave takyto ciel mi chyba, preto by som chcel, aby ste mi poradili, s cim ste vy zacinali.
Dakujem za rady :)
-
Jaký jazyk zvolit pro začátečníka
Třeba Slovenštinu a pak Polštinu :P
Ale Angličtina se hodí víc 8)
-
- pokud se chcete naucit programovat PORADNE naucte se C/C++
- z vlastni zkusenosti: jakykoliv bastl bude rychleji napsany v jave a bude pravdepodobne i rychleji bezet, nicmene kod od profika v C++ je proste kod od profika c C++ :)
A v Jave nesmi programovat profici? Nebo se v Jave nesmi/neda programovat poradne? Ja nevim, jen se ptam. Doted jsem myslel, ze kvalita programu zavisi na programatorovi, ne na programovacim jazyku.
-
- pokud se chcete naucit programovat PORADNE naucte se C/C++
- z vlastni zkusenosti: jakykoliv bastl bude rychleji napsany v jave a bude pravdepodobne i rychleji bezet, nicmene kod od profika v C++ je proste kod od profika c C++ :)
A v Jave nesmi programovat profici? Nebo se v Jave nesmi/neda programovat poradne? Ja nevim, jen se ptam. Doted jsem myslel, ze kvalita programu zavisi na programatorovi, ne na programovacim jazyku.
no to je tak ze sa musis naucit TEN PRAVY programovaci jazyk a to je c++. c++ je pre chlapov, java je pre deti ... proste bez c++ si s profesionalmi ruky nepodavaj. lebo oni sa naucili nechutne zlozite c++ aby boli tymi spravnymi programatormi :) ty nikdy nebudes TEN PRAVY programator pretoze programujes v tom co ta bavi, ked robis v jave alebo c# tak si lepic lepovy.
-
- pokud se chcete naucit programovat PORADNE naucte se C/C++
- z vlastni zkusenosti: jakykoliv bastl bude rychleji napsany v jave a bude pravdepodobne i rychleji bezet, nicmene kod od profika v C++ je proste kod od profika c C++ :)
A v Jave nesmi programovat profici? Nebo se v Jave nesmi/neda programovat poradne? Ja nevim, jen se ptam. Doted jsem myslel, ze kvalita programu zavisi na programatorovi, ne na programovacim jazyku.
no to je tak ze sa musis naucit TEN PRAVY programovaci jazyk a to je c++. c++ je pre chlapov, java je pre deti ... proste bez c++ si s profesionalmi ruky nepodavaj. lebo oni sa naucili nechutne zlozite c++ aby boli tymi spravnymi programatormi :) ty nikdy nebudes TEN PRAVY programator pretoze programujes v tom co ta bavi, ked robis v jave alebo c# tak si lepic lepovy.
Ale houby! Skuteční chlapi programují ve FORTRANu, všichni ostatní jsou jen pojídači koláčů 8) Tedy s výjimkou Mela Kaye...
-
Já bych určitě každému poradil, aby vydržel alespoň rok u C/C++ + nějaké ty základy assembleru. Sám jsem nějak intenzivněji začínal programovat v C# s tím, že jsem uměl akorát HTML. Internet jsme měli totiž relativně pozdě (v 19 letech, teď mi bylo 23), takže v podstatě do té doby jsem ani nějak netušil, co všechno je možné.
Začátky s C# - jel jsem podle tutoriálu na živě.cz a zas*ral builder.cz svými dotazy.
No zhruba po týdnu jsem si řekl, že šíleně věcí nechápu a používám je jen tak, že je mám naučené. Typickým příkladem byla problematika eventů a delegátů. Takže jsem udělal, když se na to tak dívám zpětně, nejlepší věc co jsem mohl. Koupil jsem si knihu mistrovství v c++ a řekl si, že se naučím nejprve ty základy a hlavně jazyk, co má blíž k tomu, jak to vlastně v pc funguje.
Po nějaké době jsem se začal zajímat o problematiku prolamování ochran lineage 2 klientů proti používání jednoho programu, který v podstatě hraje za vás. To mi dalo neskutečně moc. Naučil jsem se základy assembleru a toho, jak program funguje a co se děje např. v paměti a taky trochu interní práce ve windows. Např. jedna ochrana odesílala verzi toho nepovoleného programu někam na server a podle toho admin rozdával bany. Já jsem si ve windowsech napsal knihovnu, která při nahrání do paměti procesu přepsala prvních 5 bajtů funkce send relativním skokem do mé funkce a v té jsem nedělal vůbec nic, pouze vrátil návratovou hodnotu podle msdn, což je počet úspěšně odeslaných bajtů. Takže doporučuji každému se ponořit na co nejdelší dobu do té "low level" problematiky a pokud máte navíc něco mezi ušima, tak pak nebudete mít problém s žádným moderním (Java, C#,...) jazykem.
-
Cčko se už skoro bohužel neučí
A to Vam nakecal kdo? Od Mendlovky v Brne po CVUT v Praze se uci v prvnim rocniku C/C++.
-
Všechno co tady lidi napsali jsou subjektivní věci a nemá moc smysl se podle toho řídit. Není možné obecně říct jestli je lepší začít s jednoduchým jazykem a potom přejít na složitější. To záleží na tom, co komu vyhovuje.
Já bych doporučil nejdřív začít se základními algoritmy a datovými strukturami. Programovací jazyk není až tak podstatný a vybíral bych si podle množství a kvality dostupných materiálů a ne podle toho co je zrovna in nebo co kdo radí jako zaručený postup.
+100
-
"Programovanie sa nevidi ako masova cinnost. Masova cinnost mi pride sex, prijem potravy a vylucovanie. Tak ako sa nemoze kazdy zivit hudbou, tak podla mna ani programovanim."
To by me zajimalo, jestli cteni a psani povazujete za masovou, nebo za nemasovou cinnost. :-)
-
Tak zrovna to čtení bych jako masovou činnost určitě nevnímal, zato psaní se nám nějak rozmohlo, také podle toho ty výplody vypadají :-D
-
Doporučil bych navštívit http://www.jakprogramovat.cz/ právě probíhající tutoriály o začátcích programování. Vše popsáno pro naprosté laiky.