Jaký jazyk zvolit pro začátečníka

Semestralky, BP a DP

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #45 kdy: 16. 10. 2010, 21:21:03 »
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 ;)


Logik

  • *****
  • 1 049
    • Zobrazit profil
    • E-mail
Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #46 kdy: 16. 10. 2010, 21:50:46 »
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í....
« Poslední změna: 16. 10. 2010, 22:00:33 od Matyáš Novák »

D.A. Tiger

  • ****
  • 486
  • Tygr, který žere tučňáka ;-)
    • Zobrazit profil
    • E-mail
Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #47 kdy: 16. 10. 2010, 23:52:55 »
Citace
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...
Citace
Citace
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... 

Citace
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
Citace
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...   


ondra.novacisko.cz

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #48 kdy: 17. 10. 2010, 00:13:12 »
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)

David Strejc

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #49 kdy: 17. 10. 2010, 07:43:55 »
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".


Ivan Nový

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #50 kdy: 17. 10. 2010, 09:00:06 »
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 :-)

Radovan

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #51 kdy: 17. 10. 2010, 09:15:36 »
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...

David Strejc

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #52 kdy: 17. 10. 2010, 10:08:59 »
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)

Semestralky, BP a DP

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #53 kdy: 17. 10. 2010, 10:50:01 »
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.

hurda

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #54 kdy: 17. 10. 2010, 11:37:31 »
Citace
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.

mirec

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #55 kdy: 17. 10. 2010, 14:42:22 »
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.

Ultimator

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #56 kdy: 17. 10. 2010, 15:17:31 »
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á.


Logik

  • *****
  • 1 049
    • Zobrazit profil
    • E-mail
Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #57 kdy: 17. 10. 2010, 15:44:49 »
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.

Citace
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í...

Citace
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.

Citace
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.

Citace
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.


Citace
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á... :-)

ondra.novacisko.cz

Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #58 kdy: 17. 10. 2010, 21:02:09 »
Citace
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ě.

Citace
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.

Logik

  • *****
  • 1 049
    • Zobrazit profil
    • E-mail
Re: Jaký jazyk zvolit pro začátečníka
« Odpověď #59 kdy: 17. 10. 2010, 23:47:04 »
Citace
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)?

Citace
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.

Citace
...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é.

Citace
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.

Citace
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.

Citace
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.

« Poslední změna: 18. 10. 2010, 00:06:35 od Matyáš Novák »