Vlákno názorů k článku Suckless: méně smradlavý software od Dave - Koukám na mého oblíbence Python a je taky...
-
Dave (neregistrovaný)
Koukám na mého oblíbence Python a je taky v harmfull. :) Nevím proč, ale asi proto, že objektové programování je obecně v harmfull.
Jenže to je věc kterou začínám číst čím dál častěji. Já teda fakt nemám kapacitu na to odhadnout jaké paradigma příjde po OOP, ale zdá se mi, že už to bude brzo.
-
JSH (neregistrovaný)
Je pravda, že z oop se poslední dobou udělal jakýsi kargokult. Ale shrnout ho šmahem je taky blbost.
Momentálně se všude možně cpou prvky z funkcionálního programování. Jak bude přibývat jader a vláken, tak se víc a víc vyplatí neměnné objekty, které se nemusí zamykat. Taky by se mi líbilo, kdyby se do mainstreamu protlačil systém tříd z Haskellu. Nadějné náznaky vidím v C++ (fuj) přes boost (ještě víc fuj) :) -
xxar3s (neregistrovaný)
Funkcionálne?
V prvom OOP rieseni su metody pevne zviazane s datami. Ked chcem objekt rozsirit o inu funkcionalitu musim pouzit dedicnost alebo mixiny. Pricom vzdy dedim vsetky metody z rodica.
V druhom pripade pouzivam objekt list na ktory si vytvorim sadu funkcii (modul) Stack takze list pouzivam ako zasobnik. Ked potrebujem inu sadu funkcii pouzijem iny modul ale stale pouzivam ten isty objekt. Dalsia vyhoda toho funkcionalneho riesenia je ze cely zasobnik je immutable.
-
belzebub (neregistrovaný)
LOL. Muzete mi prosim vysvetlit, proc je dle Vas na produkcni nasazeni lepsi c++ ?
Prehlednejsi kod? NE!
Snadnejsi udrzba? NE!
Lepsi prenositelnost? NE!
Snadnejsi deployment? NE!
Jednodussi testovani? NE!
Mensi riziko padu? NE!
Vyssi vykon (CPU)? Mozna, ale v 99% pripadu irelevantni (mysleno tak, ze sitova latence je radove vyssi nez cas zpracovani pozadavku pythonem).
Setkal jsem se s podobnymi nazory, ktere ovsem ve vetsine pripadu zastavali lide, kteri (a) vubec nic nevedeli o vyvoji, a pouze "vedeli, ze v C++ pisi profesionalove" (=cargo cult), nebo (b) umeli jen jeden jediny jazyk ve kterem pracovali 20 let a kdyz jediny nastroj, ktery mate je kladivo.. vse vypada jako hrebik.
-
Sten (neregistrovaný)
Menší riziko pádu rozhodně ano. Jako každý jazyk, který je staticky kompilovaný.
Síťová latence je pro výkon irelevantní, proto se taky webové aplikace navrhují posle počtu požadavků za sekundu a ne podle latence. Nad určité množství požadavků za sekundu začne být C++ o dost lepší.
-
belzebub (neregistrovaný)
Vzhledem k tomu, ze jsem stravil pravdepodobne stovky hodin sveho zivota hledanim nejake obzvlaste vypecene "pametove chyby" v C/C++, tak si troufnu tvrdit, ze staticka kompilace s rizikem padu souvisi vicemene nijak.
Podle toho co pisete o webovych aplikacich by mely byt vsechny serioznejsi psany v C++. Coz se zjevne nedeje. Abyste mi dobre rozumel - ja naprosto souhlasim, ze v EXTREMNICH a velmi vzacnych pripadech muze byt pouziti nejakeho kompilovaneho "rychleho" jazyka lepsi nez nejakeho interpretovaneho/bytecode jazyka. Ovsem znovu zduraznuji - v EXTREMNICH A VELMI VZACNYCH PRIPADECH.
-
j (neregistrovaný)
Divil by ses, ale casti nekterych webu, ktere jsou vytezovany, jsou kompilovany trebas jako modul do apache.
A proc to tak neni u vetsiny webu? Protoze weby z 90% nic narocnyho nedelaji, a interpret tomu bohate staci. Svoji (vyrazne) horsi vykonnost pak nahrazuje snadnou modifikaci. V mnoha pripadech se pak problem s vykonem webu samotnyho resi vsemoznych cachovanim obsahu ... protoze se stejne i tom alo co web dela porad dokola opakuje.
Mimochodem, jisty pravidelny prispevatel by ti jiste mohl povyprave o tom, jak se M$ roky snazil prepsat widle do .NET ... a ve finale to cele zahodili, protoze se to nedalo zprovoznit ani na nejvykonnejsim zeleze.
Pro zajimavost, mam tu uzasnou .NET aplikaci ... scroll gridu zatezuje 2jadro na 80+%. Kdyz sem si v C++ doslova naklipal grid a nacet do nej tataz data ... tak sem srolovat asi tak 1000x rychlejs bez znatelny zateze CPU. Toz asi sem pri tom klipani jako neprogramator zapomel neco zmrvit nebo nevim ...
-
Lael Ophir (neregistrovaný)
MS se snažil přepsat Windows do .NETu? Fakt? Já si všiml jen toho, že ve Vistě byl v nějaké fázi explorer.exe přepsaný do .NETu, a nakonec zůstali u C++. Ale možná máte lepší zdroj informací.
Právě jsem si založil projekt, natáhnul GridView na form a ve wizardu vybral tabulku z DB. Trvalo to cca půl minuty včetně spuštění VS, a napsal jsem u toho nula řádků kódu. Žádné vytížení CPU v task manageru nepozoruji. Zjevně tak nízké, že bych ho musel měřit perfmonem. Ale pokud chcete napsat v C++ form s datagridem, který vytíží CPU klidně na 100%, tak bych to jistě zvládnul :D. Jinými slovy to co jste viděl není o výkonu datagridu v .NETu, ale o nějaké prasárně autora kódu.
-
Sten (neregistrovaný)
Ještě si pamatuji, kdy budoucnost podle vás bylo Singularity. Teď je to zmršené C++ s ořezaným .NETem. Za deset let to třeba bude i ISO C++ a MS konečně zvládne něco udělat pořádně :-)
-
Lael Ophir (neregistrovaný)
Ano, právě kompatibilita s Win32 je problém. Managed kernel má samozřejmě nějaký overhead, ale je to do značné míry vyvážené tím, že neexistuje context switch mezi procesy. Bohužel při běhu Win32 kódu context switche zůstávají, takže to ohledně výkonu není dobré. To by asi tolik netrápilo uživatele Wordu, ale na DB nebo aplikačním serveru by to nebylo dobré.
Dalším problémem je rozumná implementace unmanaged Win32 nad managed kernelem. Aby to celé přineslo kýžený výsledek, tedy dramaticky zvýšenou stabilitu a bezpečnost, bude potřeba psát aplikace v jiném prostředí. Windows Runtime je podle mě krok přesně tímhle směrem - k bezešvé integraci managed a unmanaged kódu.
-
ebik (neregistrovaný)
V pythonu vetsinou nedeklarujete typ promenne, coz vede k runtime chybam, ktere by se daly odhalit compiletime. A neni to jen o promennych. Zrovna toto muze zprehlednit kod a urcite to zlepsi jeho udrzovatelnost. (Coz zase ovlivni riziko padu.)
U ostatnich bodu s vami souhlasim, ze C++ neni lepsi - je totiz stejne dobre. -
Sten (neregistrovaný)
Tak ve své podstatě to ani není potřeba, protože to ohlídá kompilátor. Narážel jsem na to, že u Pythonu tohle nejde udělat a nikdo to před spuštěním neohlídá, protože až do použití té funkce není jasné, co vlastně očekává (kromě dokumentace samozřejmě, ale tu budou nějaké automatické nástroje těžko studovat).
-
Inkvizitor (neregistrovaný)
C++ stejně dobře (např.) čitelné jako Python? To je tedy opravdu odvážné tvrzení. Typová kontrola v době kompilace pomáhá, ale bez pořádného typového systému (alespoň na úrovni třeba Haskellu) se na ni moc spoléhat nedá. Objektově orientovaný assembler by nevyřešil v podstatě jediný podobný problém, který jsem v Pythonu na rozsáhlých projektech narazil a to je použití symbolické konstanty (číslo) tam, kam patřila jiná sada konstant.
Takže ano, teoreticky je C++ v tomto ve výhodě, ale za ty problémy to podle mě nestojí.
-
Petr M (neregistrovaný)
On je tady ještě jeden podstatný faktor. Když člověk dělá víc jeden jazyk a jeho knihovny, může mít problém přepnout na něco jinýho. Když skočí na třeba z PHP na C, tak cykly se zapisují stejně, podmínky se zapisují stejně,... Ale najednou přibudou třeba typy dat, je to pár řádků navíc, alepůsobí to tak nějak rušivě... Javař může mít probléy s tím, že zapomíná jince explicitně volat destruktory... A podstatně se liší i knihovny, který jspu k dispozici. Člověk tápe, jaký soubor přilinkovat a jak se ten objekt / atribut / metoda / funkce / konstanta jmenuje...
Programovací jazyk je nástroj. Pokud ovládám jazyk, ve kterým dokážu efektivně a uspokojivě vyřešit zadání, dá se použít. A je to lepší, než použít sice vhodnější a efektivnější jazyk, který se ale musím napřed naučit a projektový čas běží...
-
belzebub (neregistrovaný)
A to je argument pro co? Rikate tedy, ze pokud bych umel pouze visual basic, mam vse psat ve visual basicu? Nebo pokud budu umet jen assembler, mam vse psat v assembleru, abych neztracel cas ucenim se noveho jazyka?
Takovato logika je zcestna, a velmi silne zavani povestnym "Kdyz jediny nastroj co mam, je kladivo, vsechno zacne brzy vypadat jako hrebik".
Z meho pohledu je chyba v uvazovani tam, kde se predpoklada ze clovek umi jeden jazyk perfektne, a naucit se jine mu bude trvat neskutecne dlouho.
Nejenze to neni pravda (python jsem byl schopen obstojne pouzivat po cca tydnu "uceni", a s kazdym novym jazykem, ktery jsem se naucil, mi zvladnuti dalsiho trvalo kratsi dobu), ale hlavne: jakykoliv programator, ktery neumi alespon 2 (ruzne*) jazyky, je u me mrtvy programator. Pripadne jakykoliv vyvojarsky team, ktery ve svych lidech nema znalosti alespon 4 (ruznych*) jazyku, je odsouzen do propadliste dejin.Tj. dle meho nazoru problem "musime se naucit novy jazyk" neexistuje, protoze kompetentni vyvojar umi vicero jazyku (dobra kombinace by byla treba C/C++, Java, Python, Javascript, Scala), a pouzije ten, ktery je pro dany problem nejvhodnejsi.
* ruzne - tim myslim skutecne vyrazne odlisne, ne veci jako (C++ a C), (ruby a python), (Java a C#) nebo (C++ a PHP)
-
Petr M (neregistrovaný)
To je jenom pozstřeh z praxe, často se setkám s tím, že někdo umí (většinou mizerně) jeden jazyk a špiní ostatní jazyky, aby se nemusel nic dalšího učit.
Jde o to, že pokud mám možnost volby (není to např. starý projekt nebo rozhodnutí managementu) a umím Javu, nemusím týden zkoumat C#. Prostě z každé skupiny jazyků stačí pro vlastní potřebu dobře zvládnout jeden (skriptovací, interpretovaný OOP, web script...) a když člověk něco potřebuje, tak to prostě nativně použije.
Ale to celoživotní vzdělávání beru, čím víc jazyků zvládám, tím větší odstup od problému mám a tím líp se hledá efektivní řešení. A nesvazuju obecný řešení s jazykem nebo platformou.
