Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Ještě zbývá naděje, že je to podobná pitomost, jako zpráva o konci telefonů BlackBerry :)
Jak už jsem psal pod svůj článek o konci telefonů BlackBerry - není to pitomost, jen asi došlo k nepochopení toho, o čem zpráva je. Nikoliv však na mé straně. BB nebude nadále dělat in-house vývoj ani výrobu, další telefony budou totéž co DTEK50 - vše hardwarové tam udělá někdo jiný, než BlackBerry.
Mě ta myšlenka 'operačního systému' postaveného na webovém prohlížeči přišla už od samého začátku jako přitažená za vlasy. To samé Chrome OS.
Vývojáři mobilních aplikací taky určitě ocenili, že by museli vyvíjet pro další nekompatibilní a nedodělanou platformu navíc. Tak se na to s ohledem na tržní podíl Firefox OS pochopitelně vykašlali.
Ta platforma je ale vlastně obyčejné HTML5, a když už nic jiného, tak alespoň se takovéhle projekty zaslouží o odstranění jejích omezení. Tak proč nad tím lamentovat? Web je velký a jestli to mělo nějaké přínosy, tak se na něm ty pozitivní výsledky projeví.
Presne tak, od prvni chvile to nebyl ani trochu hezky sen, byla to nocni mura, kterou slunickovata Mozilla cerstve posilena o uspech v boji proti antibuzerantskemu vedeni zivila sebe i nas ostatni. Samozrejme v mozcich tech vocasu ohrivanych buhvicim to vypadalo jako smely plan, ovsem nikdo kdo nebyl smyslu zbaveny, to tem bukvicim od zacatku nezral.
Tou dobou zacali znacne problemy weboveho prohlizece Firefox a tak bylo hned jasne, ze tohle nemuze dopadnout dobre. Zajimali by me mozkove pochody lidi, kteri nezvladali jednu vec a pustili se do druhe. Navic muzeme se smat Microsoftu, ze prisel pozde, ale Mozilla prisla vyslovene s krizkem po funuse. Proc by svet krome polofunkcnich nedodelku ala Android a Windows Phone potreboval dalsi?
Nepotreboval a proto se jejich sen (nase nocni mura) rozplynul jak para nad hrncem, nastesti.
Panasonic jen ukazal, ze jde do kopru taky. Ja se jeste pred nejakymi 5-6 lety koupil od Panasonicu televizi (hloupou), no to co ted predvadeji, to jako opravdu ne. Takze se vubec nedivim, ze zustali s tim idiotskym OS "stat jak kul v plote" sami.
Jestli neco svet opravdu potrebuje na poli OS, tak je to kvalitni propracovany OS s moznosti vytvaret robustni nativni aplikace a ten zcela chybi a ikdyz je mozne, ze se rodi v hlavach lidi z Canonicalu nebo u Samsungu, realne tu nic neni (vyjma nejakych alfa verzi) a pocitam, ze nez bude jeste to nekolik let potrva.
K čemu chromovatý Firefox. Můžou to zabalit třeba hned a jít raději pěstovat ředkvičky...
A co ako cakali? OS kde su gui a aplikacie postavene okolo browseru je magorina odsudena na zanik. Ostatne staci sa pozriet na ChromeOS a zaujem o neho. Ten preziva len vdaka velkosti a sile Googlu nez vdaka nejakej krutej inovativnosti alebo pouzitelnosti. Cely tento trend web app je vrchol zvratenosti designovania aplikacii a vobec SW. Je to vrchol plytvania prostriedkami za cenu ze si mozem v par riadkoch chaotickeho markup jazyku zobrazit nejake elementy a dynamicky s nimi manipulovat, hoci sa toto da dosiahnut aj setrnejsimi sposobmi.
Co čekáte od softwarového ekosystému, ve kterém Javu, C# a C++ považují lidé za dobrý nápad?
Prosil bych neházet C++ se C# a Javou do jednoho pytle.
Máte pravdu, co jsem to naposledy před lety kontroloval, použitelností specifikace jako zarážky do dveří se Java a C# ještě musejí na C++ docela dotáhnout.
to je tak vtipné, až je to hloupé... případně naopak. Nejlepší je, že nejdřív jsem chvilku vážně přemýšlel o jaké specifikace zarážek jde LOL
Co máte proti C++? Jak můžete tento jazyk srovnávat s obskurností jako JAVA?
Možná se jen snažil odhalit zdejší programátory. ;)
jestli Gath náhodou nemířil na objektovost těchto jazyků.
Co mám proti C++? Třeba pěkné jazyky jako Lisp, Smalltalk, Oberon, nebo i FL, APL atd., jejichž autoři aspoň měli tušení, k čemu se vlastně chtějí dostat (a hlavně jak efektivně se k tomu taky chtějí dostat)? I když nejhorším provinilcem je zde samozřejmě veskrze cargo kultové PHP...
Jazyky Lisp, Smalltalk, Oberon, nebo i FL, APL atd. jsou pro současnou HW architekturu naprosto nevhodné. Bohužel jedná se o Deklarativní jazyky, které mají sice velikou vyjadřovací sílu, ale jejich runtime je postavený na existenci nereálných počítačů a to se musí stejně řešit přizpůsobením na reálný HW což přináší výkonovou ztrátu a další omezování těchto jazyků, takže výsledek je oproti původnímu zápisu kripl. V deklarativních jazicích totiž nemusí záležet na pořadí vykonáchaných výpočetních větví a je v nich velice hojně využívaná rekurze - což je sice z pohledu teorie super, ale opět to v realitě naráží na fyzikální a ekonomické limity našeho světa.
Naproti tomu C++ je jazyk, který BS vytvořil z důvodu nevhodnosti jazyka C pro vědeckou činnost. C++ elegantně spojuje abstraktní konstrukce s běhovým prostředím na HW. Díky vývoji kompileru dokonce už několik let vytlačuje C z embedded sféry. C++ má tedy jasnou příčinu i směr.
Naproti tomu Java C# a zmiňované PHP jsou navrženy primárně na VM a podle toho to taky vypadá. Jejich runtime při pokusu o nativní build je mnohem větší a složitější než u C++.
Proto po současnou HW architekturu jsou nejvhodnější jazyky, které pro ní byli přímo vytvořeny. C, C++, Assembler.
Samozřejmě pro abstraktní a vedecké úlohy, které mají ověřit proveditelnost té či oné logické konstrukce je vhodnější LISP. Nicméně nasazení ala Lisp jazyků, nebo VM jazyků např. do systémů reálného času nebo jinak kritických systémů je to taková babicovina.
PS: Jak jsem ze začínal Lisp učit, tak jsem si zapamatoval jednu z potrhlých interpretací té zkraty - Lost in stupid parentheses. Ano další nevýhoda těchto deklarativních záležitostí je, že né každý programátor je schopen v tom číst.
pro mě byl vrchol programování Karel v bludišti :D
Karel je cool :), alespoň na algoritmizaci pro základoškoláky.
Tenhle argument mi připomíná to anglické úsloví o rtěnce a praseti.
C++ je jazyk, který se snaží dělat všechno najednou, takovým způsobem, že sami jeho tvůrci jsou leckdy překvapeni, jak se chová, a nečekají, že by ho někdo skutečně pochopil. Že dosáhl parametrů a míry použitelnosti, jaké u něj známe dnes, je čistě otázka obrovské hromady peněz a času vynaložených na správná řešení špatných problémů (kdyby býval Stroustrup v 80. letech spolupracoval se Steelem, možná dnes programujeme ve Fortressu a nehádáme se o to, že procesor XYZ má "příliš mnoho jader").
Co je na Oberonu deklarativního tedy netuším, a i ty ostatní jazyky jsou především algoritmické. Ovšem na rozdíl od C++ (tedy snad s výjimkou Common Lispu) se NEsnaží dělat všechno najednou, takže to, o co se snaží (třeba numerické výpočty), docilují mnohem efektivněji. Taky nepěstují kulturu stomegabajtových binárek a programů vrstvících jednu věc na druhou, což nás dohnalo k výše lamentovanému stavu věcí, včetně tématu tohoto clánku, tedy Firefoxu, který vypadá tak, jak vypadá, mj. díky bloatwarové kultuře C++.
Tvrzení o řazení výpočtů a hojném využívání rekurze pominu, žádného ze mnou jmenovaných jazyků se pokud vím (možná kromě FL?) netýká, a i kdyby se týkalo, líné výpočty si v jazycích jako C++ lidé často píší dodatečně, kdykoli jim chybějí, a rekurze prokazatelně buď je transformovatelná na smyčku, nebo obsahuje non-O(1) stav, který vyžaduje ekvivalentní explicitní zásobník, takže člověk stejně píše totéž, jenom jinak. Stačí, aby tyto vlastnosti nevnášely režii tam, kde je člověk nepotřebuje, což je realizovatelné. (*Skutečné* deklarativní jazyky by pak ale šly mnohem dál a takovéhle nízkoúrovňové vlastnosti by na ně měly mít mnohem menší vliv než vysokoúrovňové transformace typu např. automatického výběru algoritmů, jenže žádný takový nebyl zmíněn.)
Tvrzení o "nevhodnosti pro současnou HW architekturu" padá na kámen toho, že dnes na rozdíl od 60.-70. let víme, jak jazyky efektivně kompilovat, takže výkon víceméně není problém. Ba co víc, některé z nich, třeba jazyky orientované na pole, si asi těžko budou už z principu rozumět se "současnou HW architekturou" HŮŘE než třeba C++, když povážíte, že tyhle jazyky mají nativní vektory a pole a "současná HW architektura" má široké vektorové operace, zatímco u C++ je třeba vektorové operace pracně dedukovat ze smyček způsobem, který může, ale nemusí požadované transformace najít (a to až po zanesení dalších velkých modulů do kompilátoru, které se tohle "hádání" snaží více či méně úspěšně provádět), nebo příslušné operace psát ručně. A teď, po příchodu GPGPU, ta situace vypadá pro disciplinované jazyky ještě lépe.
Ostatně sami autoři kompilátorů, jako třeba Fran Allenová, tvrdí PŘESNÝ OPAK toho, co píšete: totiž že vznik C/C++ zabil vývoj skvělých kompilátorů skvělých jazyků a že to posunulo technologický vývoj zpět. Najednou tu byl jazyk, který nejenže neumožňoval snadno napsat dobrý kompilátor, ale dokonce to bylo v rozporu s jeho posláním nutit lidi dělat všechno ručně.
Takže ironicky právě C/C++ má s výkonem a kompilací větší problémy, tedy pokud do toho nezatáhnete rozšíření typu třeba restricted pointers apod., které slouží k tomu, aby těmto jazykům na téměř strojové úrovni kompilátor mohl více porozumět a vůbec něco s nimi provést (a nikoli pesimisticky, ale nutně předpokládat, že třeba jakýkoli statement může změnit cokoli za kterýmkoli ukazatelem, protože ukazatelové parametry funkcí můžou kdykoli mířit kamkoli). C++ má velké štěstí v tom, že jak jsem psal výše, zainteresované strany do něj (navzdory varováním Fran Allenové) nalily obrovskou hromadu peněz a času, protože kdybyste všem jazykům přidělil "férové" fixní množství snahy implementátorů o efektivní implementaci ("ať vyhraje ten nejlepší"), žádnou radost byste z výsledku pro C++ asi neměl.
Konstrukce C++ jsou abstraktní jen tehdy, pokud ho srovnáte s Cčkem. Což mi přijde smutné. Modula-3 blahé paměti vypadala mnohem zajímavěji. Dnes už v ní ale asi nikdo nic psát nezačne, což je docela škoda.
PS: To, že některé věci třeba v Lispu se nedají dobře číst je pravda. Jenže ony se špatně čtou i mnohé věci v C++ (spousta dodatečné "magie"). Takže ono to záleží mnohem víc na kódu a na programátorovi a na jeho disciplinovanosti než na jazyku. Ostatně že spousta věcí v C++ je "extrajazyková"/věcí konvence je celkem známé ("naučte se RAII a používejte ho, jazyk vás k tomu sám nedonutí"). Pak vznikají všechny ty místní stylové příručky, co všechno nesmíte používat, aby to po vás kolegové přečetli a binárka programu nevzrostla na několikanásobou velikost. A zase skončíte na půl cesty mezi standardním C a standardním C++.
A protože nehodlám naspat ještě delší reakci tak se budu snažit být stručný.
Argumentum ad hominem.
BS prohlásil, že slovo paradigma nemá rád. Nicméně já nejsem tak vyhraněný tak řeknu toto: Kdo není sto pracovat s multiparadigmatickým jazykem, ať jde raději cvrnkat kuličky. S těma penězma by to nepřeceňoval, Např. M$ do toho začal lít velké peníze až v roce 2012 a stejně je pořád pozadu za
clangem a gcc. Navíc právě M$ do toho zanášel svůj balast a štěpil komunitu. Jediná věc, která C++ ublížila bylo to, že svoje ISO získal až v roce 1998.
Pravda oberon není deklarativní. Nicméně je to děs s brutálním runtime. C++ na web teprve míří - WebAssembly. Fun projekty, kde C++ běží pod Apache místo PHP neberu. Pouze připomenu, C++ zcela reflektuje HW model, protože to nejdůležitější na C++ byl je a bude kompiler. C++ totiž místo velké binárky nebo/a brutálnímu runtime dává přednost compile time optimalizacím, předvýpočtům a redukcí kódu. Je smutné, že si toto uvědomuje či ví jen málo programátorů.
Další odstavec - rekurze
(defun reverse_g(list) (cond ((null list) list)
((atom (car list)) (append (reverse_g(cdr list)) (cons (car list) nil)))
(T (append (reverse_g (cdr list)) (cons (reverse_g (car list)) nil)))))
a úplně ve stejném duchu nezáleží na vykonání větví, pokud by se např. jednalo o prohledávání stromu.
Doporučuji si nastudovat instrukční sady procesorů CPU a GPU, protected/supervisor mód, architekturu, způsob, jakým pracuje paměťový řadič atd. Potom by asi ten odstavec vypadal jinak. Holt libovolnou konfiguraci TM nelze v našem vesmíru vytvořit. C++ prostě reflektuje HW model. A ještě jednou C++ není jenom zdrojový kód, ale i kompiler. Takto to bylo koncipováno od začátku.
C++ vzniklo v jako preprocecor jazyka C v osmdesátých letech. Takže to není ani 60 ani 70. A právě díky nárůstu na straně kompileru může mít C++ novější standardy. Poslední i budoucí standard C++(11-20)totiž vyžaduje vynikající kompiler. C byl, je a bude vynikajicí nízkoúrovňový jazyk a jako takový opravdu složitý kompiler nepotřebuje, protože je velice blízko strojovému kódu. To co kritizuju je příliš veliký runtime a memory management(gc, smart pointery atd.) v současném stavu HW. Až bude hojně používané pro runtime účely FPGA přímo v procesoru, pak nemám námitek.
Kompiler C++ je nekolika-úrovňový a dochází k transformacím nektěrých konstrukcí do stravitelnější formy. Je to dáno tím, že mnohé konstrukce snižují množství úhozů nutných k vyprodukování požadované funkcionality. Memory management je u jazyků C/C++ věcí programátora, protože tyto jazyky se zaměřují na výkon a kritické aplikace - alokace/dealokace pamětí je v režii programátora. Ano C++ tu není pro lidi s IQ <= 90.
Takové použití šablon vede ke stejně abstraktním konstrukcím jako např. v Lispu. Což opět většina programátorů C++ nechápe a ani neumí použít.
A to moje PS: Prasata jsou všude, ale závorky v takovém množství jenom v Lispu. A s tou velikostí binárky to vzniká jenom pokud se prasí makra ve velkém, makra jsou totiž v C++ zlo a BS se s tím snaží už dlouhou dobu něco udělat. To poslední platí pouze u lidí, co nepochopili C++ a plodí takový C a C++ mix.
"Argumentum ad hominem."
Kde ho vidíte?
"BS prohlásil, že slovo paradigma nemá rád. Nicméně já nejsem tak vyhraněný tak řeknu toto: Kdo není sto pracovat s multiparadigmatickým jazykem, ať jde raději cvrnkat kuličky."
Tak s tím bych zcela souhlasil. Nicméně *dobře* navrhnout takovýto jazyk se ukázalo jako docela těžké, a ještě ho současně posunout na strojovou úroveň při zachování všech jeho kvalit je skoro nemožné. To už se v praxi viditelně osvědčuje kombinace vyššího jazyka a modulů v C(++). Samozřejmě čím kvalitnější tento vyšší jazyk je, tím méně je takovýchto modulů zapotřebí, ale vůči možnosti pokrýt celé spektrum bez kompromisů jsem poněkud skeptik. To se v úplnosti nepodařilo ani Common Lispu, i když k tomu nemá daleko (mnohé implementace umí (obstojně, ne dokonale) spektrum od abstraktního deklarativního kódu s vlastní syntaxí až po vnořený assembler).
"Pravda oberon není deklarativní. Nicméně je to děs s brutálním runtime."
To je zajímavé tvrzení, protože spousta lidí je zřejmě toho názoru, že je to elegantní jazyk s kompaktním prostředím, dokonce i na dobu minulou, nejen současnou. "Brutální runtime" se nejeví jako správné označení.
"Např. M$ do toho začal lít velké peníze až v roce 2012 a stejně je pořád pozadu za
clangem a gcc."
MS pracuje na kompilátorech C(++) již přes třicet let. Samozřejmě že dříve se do celého odvětví "lilo" méně peněz, ale rozvoj osobních počítačů to změnil. Staré kompilátory C nebyly nijak zvlášť dobré. V 90./00. letech se začala situace zlepšovat. Čím více počítačů na světě je, tím se více se vyplatí mít lepší kompilátor, protože každá hodina věnovaná jeho zlepšení se vrátí mnohonásobně - použitelností v závislosti na počtu programátorů a výkonem v závislosti na počtu běžících programů/provozovaných počítačů. Je logické, že boom PC výrazně přispěl k jejich zlepšení.
"C++ totiž místo velké binárky nebo/a brutálnímu runtime dává přednost compile time optimalizacím, předvýpočtům a redukcí kódu. Je smutné, že si toto uvědomuje či ví jen málo programátorů."
V takovém případě by bylo docela pěkné, kdyby podporoval (fázovaná) makra, protože pak by bylo možné tyto věci provádět duševně zdravým způsobem a nikoli použitím podjazyka založeného na aplikaci šablon, který sice umožňuje dělat v čase kompilace podmnožinu věcí, které jdou dělat za běhu, ale s jinou syntaxí i modelem výpočtu. Jinak řečeno, bylo by pěkné, kdyby šlo tyhle věci řešit tak, aniž by se člověk efektivně učil dva jazyky najednou, a jeden z nich navíc silně omezený. Přijde mi, že třeba D v tomhle směru dopadlo lépe.
"Další odstavec - rekurze"
Netuším, co přesně se tím snažíte ukázat. Má to být nějaká demonstrace LISPu 1.5 ze 60. let? Sám jste se zmiňoval o multiparadigmatických jazycích a kuličkách... Podstatná část lispového kódu dnes nemá se seznamy moc společného. Spíše jde o budování vhodných abstrakcí a jejich řízený překlad do nižších konstrukcí. Takové věci, jakou jste napsal, by nikdo neměl potřebovat psát.
"a úplně ve stejném duchu nezáleží na vykonání větví, pokud by se např. jednalo o prohledávání stromu."
Ano, to je prakticky nezbytné pro efektivní optimalizaci na moderních architekturách, viz Fortress.
"Doporučuji si nastudovat instrukční sady procesorů CPU a GPU, protected/supervisor mód, architekturu, způsob, jakým pracuje paměťový řadič atd. Potom by asi ten odstavec vypadal jinak. Holt libovolnou konfiguraci TM nelze v našem vesmíru vytvořit. C++ prostě reflektuje HW model."
Děkuji, již znám. Ale netuším, jaký to má důsledek pro vaše tvrzení. GPU jsou vektorové procesory, C++ jim nechutná a bylo nutné vytvořit pro ně specializované jazyky (jinak by všichni programovali GPU kód v C++, což se zjevně neděje - viz CUDA a OpenCL). "Jaderné" režimy CPU nemají vliv na aplikační jazyky. (Přitom jsem netvrdil, že C není dobré na psaní kernelů OS! To je jeho optimální aplikace.) Vliv pamětí je třeba vzít v úvahu při práci v jakémkoli jazyku, jinak si naběhnete - zarovnání dat a vzory přístupů mohou výkon vaší aplikace zruinovat (čekáním na paměť) bez ohledu na to, jak dobrou sekvenci instrukcí kompilátor generuje (viz třeba benchmark DataDraw na http://datadraw.sourceforge.net/). Že "C++ reflektuje HW model" je také zajímavé tvrzení už z toho pohledu, že hardwarových modelů je hromada (dnes minimálně x86 a ARM se hodně liší), zatímco C++ je jeden. Tak který model že to přesně reflektuje?
"A právě díky nárůstu na straně kompileru může mít C++ novější standardy. "
Tím "nárůstem" rozumíte přesně co? Nárůst velikosti?
"C byl, je a bude vynikajicí nízkoúrovňový jazyk a jako takový opravdu složitý kompiler nepotřebuje, protože je velice blízko strojovému kódu."
Ano, protože záměrem bylo udělat jazyk, ve kterém se prakticky vše dělá ručně. Nepřijde vám, že založit na takovémto jazyku "nadmnožinováním" jiný jazyk, kde by se spousta věcí ručně dělat neměla, je takový trošku pochybný podnik? Co začít kvalitním návrhem od začátku?
Nemluvě o zachování bizarního kompilačního modelu, který trošku odporuje tomu, co by člověk od skutečně moderního jazyka čekal. Hlavičkové soubory, absence jasných rozhraní/modulů (dokonce i neexistence jednotného ABI v rámci jednoho jazyka), složitá/pomalu analyzovatelná syntaxe C++ (která společně s existencí hlavičkových souborů byla jedním z hlavních důvodů autorů jazyka Go k jeho vývoji) jsou jen začátek.
"Memory management je u jazyků C/C++ věcí programátora, protože tyto jazyky se zaměřují na výkon a kritické aplikace - alokace/dealokace pamětí je v režii programátora."
Jestli myslíte výkon ve smyslu propustnosti, tak to je asi docela sporné. Výzkum ukázal, že "neruční" správou dynamické paměti nemusíte ani ztratit (zato se tím zjednodušuje třeba souběžné zpracování). Mnohem zajímavější se jeví možnost rozhodnout o paměťovém layoutu struktur a jejich vztah ke správě paměti apod., což je ale ortogonální koncept.
Pokud máte na mysli výkon ve smyslu nejhorších časů (pro skutečně "kritické" aplikace, jak jim říkáte), tak to je nejlepší asi se úplně vykašlat na alokace, vypnout cache a začít používat JOVIAL nebo něco obdobného.
"A to moje PS: Prasata jsou všude, ale závorky v takovém množství jenom v Lispu. A s tou velikostí binárky to vzniká jenom pokud se prasí makra ve velkém, makra jsou totiž v C++ zlo a BS se s tím snaží už dlouhou dobu něco udělat. To poslední platí pouze u lidí, co nepochopili C++ a plodí takový C a C++ mix."
No a středníky v takovém množství jsou zase jen v C++, to si nevyberete. ;) A to je zajímavé, ale třeba v Googlu kvůli takovým věcem omezili i spoustu věcí, které makra nejsou (viz https://google.github.io/styleguide/cppguide.html). Je docela zajímavé - a celkem pochopitelné a nepříliš překvapivé - že Go dopadlo jako podobná podmnožina, jen v "uhlazenějším" provedení.
Kdybych chtěl jazyk typu C++, sáhnu jednoznačně po D (http://dlang.org/). D je "C++, jak mělo od začátku vypadat". Škoda, že nepřišlo o dost dřív. Teď už je asi prakticky nemožné, aby C++ nahradilo.
Ano, vytvořit komplexní jazyk, který propojuje vysoko a nízko úrovňový přístup, a je multiparadigmatický je běh na dlouhou trať. A udělat jeho design tak, aby výsledek byl optimální bez ztráty kytičky je taky umění. Nicméně to neznamená, že to nejde. Jak jsem již napsal, C++ stejně jako většina moderních jazyků je jak zdrojový kód, tak kompiler a nelze to od sebe oddělit. Kompiler je převodník modelu z jednoho systému na ekvivaletní model jiného systémů, tedy zdrojového kódu do strojového kódu.
Všechno, co má GC má brutální runtime. Nicméně i to se dá v C++ udělat, ale to je míchání jablek s hruškama. C++ se stále snaží mít C jako svojí podmnožinu. Já osobně to nepovažuji za příliš štastné, ale už jsem se s tím smířil. Znám(četl jsem drafty a pak specku) jazyk D, poprvé jsem se s ním setkal v době, kdy koloval na netu draft. Ano déčko řeší mnohé bolesti C++ jako např delegáty, ale právě problém je ten, že není podporovaný. Nicméně BS si D bere jako atraktor, alespoň podle toho co by do C++ rád zaiplementoval.Už jsem psal, že C++ vznikl původně jako preprocesorová záležitost nad C, ale vývoj už urazil dlouhou cestu.
Ještě jednou: C++ vyžaduje velice dobrý a propacovaný kompiler. Čím vyšší verze standardu tím to platí více, celkem velikou revolucí je C++11, v té době se M$ zaměřoval na C# už skoro 10 let, což způsobilo jedno ze zpoždění vývoje tohoto standardu. Další celkem brzda bylo MFC + ATL - rozdrolilo komunitu a brzdilo vývoj standardu. Takže to, že někdo sype do jedné věci peníze automaticky neznamená, že posun v před. Pokud se to stihne, tak C++17 už např. nebude potřebovat hlavičkové soubory. Do C++20 se stand stihne contract a static reflection + concepts. C makra jsou zlo. Šablony jsou super, chybí jenom ony koncepty a reflexe a bude to dotažené.
Problém GC a smart pointerů je v množství vykonávaných instrukcí navíc. Proto jsem psal, že až bude nasazeno FPGA pro runtime účely do procesorů, pak to bude OK. FPGA je navíc také možno použít pro optimalizaci přístupu k nelineárním paměťovým strukturám. V systémech reálného času se ale počítá s každou instrukcí a ty musejí bých predikovatelné.
Cache lze použít jen pokud je dostatech operační paměti, což často není. Nicméně na takových systémech postrádá runtime smysl a tady má právě C++ výhodu. Protože runtime nuntně nepotřebuje.
Ono je totiž jedno zda se jedná o x86, I64, amd64, arm, sparc, pa-risc, pic, motorola aj. Protože tam se jedná pouze o poslední a nejnižší vrstu kompileru a ta se píše pro každou HW architekturu separé - viz. transformace modelu.
Otevřených bodů v ABI pro C++ lze spočítat na prstech obou ruk.
GPU mají sice vektorovo maticovou část, ale ta je optimalizovaná pro velikosti 4 a 4x4. Vše nad tím je zase přes nástavbu.
V C++ jsou sice středníky, ale né 10 za sebou.
S posledním odstavcem souhlasím, C++ se k D přibližuje, ale zůstává tam pořád ta podmnožina toho C a stejně jako C nebude mít C++ GC jinak, než optional, alespoň dokud bude BS mezi námi. To totiž souvisí s tím, že každý projekt v C++ si může udělat na správu paměti framework tak, že programátoři při řešení businessu nebudou muset/moci používat new a delete.
S tym sa neda nez suhlasit. Dnesny stav je tragedia a mam pocit ze bude horsie. Kazdy si pridava do C++ co potrebuje a s nastupom GPGPU vypoctov to bude este vecsia pruda. C++ bol zaujimavy a celkom cool v C++98 alebo C++03 forme. Sice nie idealny ale aspon sa dalo dufat sa to mozno otoci lepsim smerom. Uz 11 alebo 14 standard su ciste magoriny. Preberanie roznych paradigiem, templaty kde sa clovek pozrie a compile time daleko za rozumnou hranicou pouzitelnosti pomaly aj pri malom projekte.
Java a C# niesu az tak tragicke jazyky ale tie platformy na ktorych su postavne to je des. Hlavne cely ten ekosystem Javy je peklo. Nechapem ako sa to mohlo presadit, asi to Sun hodne tlacil do enterprise sfery alebo fakt boli len horsie riesenia. .NET je na tom trochu lepsie ale MS to tak isto hnoji ako moze.
Mimochodom build systemy Javy, to navrhoval nejaky fetisista na pocet generovanych suborov? Prazdna aplikacia v Androide, vygenerovana wizardom (aj ked uznavam ze to nieje len Javou) ma cez 1000 suborov.WTF?
Docela by ma zaujimalo kam by sa dostal taky Pascal keby sa zmodernizoval a dostal na nejaku komercnejsiu a rozsirenejsiu uroven. Ci by mal sancu prekrocit svoj "skoliaci" rozmer.
Vývojem Pascalu vznikly Modula-3 a Oberon, které oba míří tak trošku jinam. Jestli si chcete vyzkoušet implementaci jedné verze Oberonu-2 (a máte počítač s Windows), existuje docela zajímavé prostředí http://blackboxframework.org (s nějakými knihovnami na http://www.zinnamturm.eu/ , abyste také mohl dělat nějaké užitečné věci. ;)). Je to takový svěží závan toho, jak by se také dala dělat programovací prostředí, kdyby lidé nebyli duševně zamrzlí na monokultuře MSVC/Eclipse/NetBeans a pod. a dokázali jednou také vymyslet něco trošku jiného.
EMACS
Emacs je skvely, obávám se ale, že jej moc lidi už nezna. Já jej treba pouzivam a neměl bych ho za ty srackove okenní produkty ani za nic..Ale kolik takových je..
Ad Pascal: Koukněte se na Go. Perfektně navržený, stopy Pascal/Modula/Oberon jsou viditelné, ale i jiných jazyků. On ani ObjectPascal (Lazarus a Delphi [i když ty znám naposledy ve verzi 7]) není k zahození a znám projekty v něm psané, ne zrovna malé.
Samozrejme aj dnes sa da pisat v hocicom a zalezi na akom projekte sa bude robit a ake su moznosti.
Bohuzial ale realita dneska je, pokial to nieje podpora nejakeho satareho systemu ktory uz na niecom existujucom a obskurnom bezi, ze sa pouzije c/c++ , java alebo c# pokial je to "kompilovane" a ak sa jedna o skriptovane jazyky tak to zasa bude s vysokou pravdepodosnostou php,python a js. A to nema nic spolocne s kvalitami a popularitou jazykou ale skor s cenou, dostupnostou programatorou, rozsirenostou nastrojov atd. Pascal nieje zly, aj ked naposledy som s nim robil pred x rokmi este na skole a vobec netusim ake su teraz moznosti, ale je ine ked v pripade c/c++ mam na vyber niekolko kompilerov a IDE, v pripade ze mi nevyhovuju alebo niektore je nestabilne ako ked mam iba Lazarus kde ak je v niecom bug alebo iny problem tak mam proste smolu. Nehovoriac o knizniciach a kvantach existujuceho kodu. Ostatne toto je asi aj jedna z mala veci co drzi pri zivote Javu.
LISP neni jazyk ale proof of concept par zajimavych veci (funkcionalni programovani, garbage collecting ...). Uz z tech zavorek je zrejme, ze to neni mysleno pro seriozni praci. Bohuzel, misto toho, aby se na tom zakladu zacal psat rozumny programovaci jazyk, prislo C++ ... teprve dneska se s velkou slavou tyhle koncepty znovuobjevuji a pridavaji se do existujicich jazyku (vcetne perlu, javascriptu nebo zmineneho PHP), a to s vetsim ci mensim (v pripade PHP mensim) uspechem. Prakticky kazdy rozsireny jazyk ma nejake problemy dane chybami v zacatku navrhu, ale udelat uplne novy jazyk a rozsirit ho je moc tezke.
Neházet prosím C++ do jednoho pytle s Javou.
To zrovna nepotěší, když má člověk nový telefon s tímto OS, že Davide ? Ale osobně bych se nebál, telefonovat a posílat SMS to bude i nadále, alternativa v podobě MSNokie s S30+ tu je v aktuální a vyšperkované (poslední) verzi a kdyby nic jiného, k Ježíšku budou pod smrkem i nějaké ty zlevněné výprodejové Lumie. Zkrátka samé pozitivní zprávy a lepší rok si socky prostě nemohly přát ! :))
Ježíš Davide, nekresli čerta na zeď, Chrome mi nesmí přes práh. Naštěstí Mozilla není firma, ale nadace a Firefox je jejím smyslem.
Sa ani nenarodil nikdy takze nemoze zomriet.
Přístroje s androidem jsou taky "exoti". Sice se androidu honosně říká operační systém, ale používá se jen jako jednorázový firmware. Buď výrobce sestaví image pro konkrétní zařízení a pro každou aktualizaci, nebo ne. Nic jako nainstaluj si sám z generického instalátoru, dodej jen ovladače, a aktualizovat se bude samo.
Smutná pravda...
Kdyby google chtěl, mohl by prosadit že se na všechna zařízení od určitého data nechá, když to bude uživatel chtít, nainstalovat Nexus, anebo jiná neutrální distribuce jako třeba Cyanogenmod (asi by do ní pak museli vstoupit nebo ji zaštítit nějakým konsorciem).
Samozřejmě, ze začátku existence Androidu by to nešlo, protože to by bylo pro výrobce složité a bránilo by to rozšíření, dneska by to vynutit mohli. A přesně, hlavní problém toho, že to nejde jsou uzavřené ovladače třetích stran jako třeba grafiky nebo wifi, které se zkompilují speciálně pro každé zařízení co jde na trh. Zároveň by se tím i tenhle vyděračskej nešvar korporací konečně moh vymýtit...
Windows i Linux taky fungují s closedsource ovladači, to není problém. Problém je, že neexistuje uživatelsky použitelný způsob, jak OS instalovat a aktualizovat z generického zdroje.
Toto je myslím ten nejmenší problém. Zaprvé odedávna existují univerzální bootloadery, zadruhé většina seriozních výrobců umožňuje OTA update systému a zatřetí u hloupějších krabiček, televizí nebo STB existuje odedávna způsob updatu pomocí vložené SD karty kam se nahraje soubor s updatem, vloží se a zapne. Jednodušší to už být nemůže.
A na používání closed-source ovladačů by se musely vytvořit speciální wrappery. V linuxu to může fungovat proto, že každý takový firmware si uživatel stáhne a instaluje individuálně, čímž se neporušuje licence (usnadnit mu to můžou nějaké skripty, které běží na pozadí a typický uživatel ubuntu to jen "odklikne", ale to na věci nic nemění). Distribuovat wrapper i s closed firmware hromadně by znamenalo riziko soudních a patentových sporů a to žádná větší firma určitě riskovat nebude. Takže tudy cesta určitě nevede.
Vzdyt ale oba mluvite o tom stejnem.
Firmy jako Samsung, Mediatek a Huawei maji svoje ovladace pro SoC uzavrene a tudiz dnes nejdou pouzit mimo jejich firmware (to jest jimi vygenerovany Android ze zdrojoveho kodu).
Distribuovat je spolecne s kompletnim firmwarem take nejde presne jak pises.
Andoid neni k dispozici z jednoho generickeho zdroje, tudiz to cele take nelze, jak pise kolega.
Ovsem co existuje, jsou projekty typu CyanogenMod, coz je vlastne upraveny custom Android v jedinnem generickem zdroji, kam jen dobrovolni vyvojari pridaji otevrene pripadne i uzavrene ovladace tech firem, ktere to umoznuji. Problem je ale, ze Huawei nebo Samsung ti proste na sve SoC ovladace zvlast nevyda ani uzavrene a tudiz takova zarizeni potom treba na CyanogenMod nelze.
Jednoduse to prirovnam k situaci na poli PC s Windows. Dejme tomu mas notebook na ktery jsou k dispozici ovladace pro Windows Vista a jen pouze pro ne. Kdyz na nem budes rozbihat Windows 10, tak proste ovladace nemusi byt k dispozici a Windows 10 na tom chodit nebudou, takze jsi se systemem, kteremu za chvili skonci podpora, docela v riti.
Jenze realny stav je takovy, ze vetsina vyrobcu ma k dispozici ovladace (jedno zda opnesource nebo closedsource) pro vice verzi Windows a vetsinou ti ten notebook bude fungovat i s ruznyma generickyma ovladacema na linuxu nebo pro nej i ovladace na linux jsou k dispozici. To cele podtrhuje jeste fakt, ze desktopovy operacni system ma vetsinou mnohaletou podporu a ze nez skonci podpora OS, uz vetsinou stejne nefunguje hardware nebo totalne zastara.
U Androidu je situace diametralne odlisna, novy OS kazdy rok, podpora maximalne dva roky a potom slus a pokud nemas k dispozici jakekoli ovladace, tak nemuzes prejit ani na CyanogenMod atp.
Čím je daná ta situace, že značkoví výrobci PC mají podporu výrazně delší než čas do uvedení nového modelu, že ovladače zařízení v PC bývají volně ke stažení, a že se nebrání ani tomu, že bude jejich ovladač obsažen v generické distribuci OS - ať už přímo nebo v centrálním úložišti? Respektive co výrobcům brání v tom, aby pro PC měli stejně nepřívětivé licence k ovladačům jako u telefonů, televizorů a jiných chytrých krabiček.
Peníze - výrobce telefonu/tabletu prodává zařízení se systémem, který pro dané zařízeni odladil. V těch ovladačích můžou být chyby nebo nějaká omezení, kvůli kterým s další verzi androidu nefungují. Takže vyrobce se vykašle na update systému/ovladače, protože vývojáři už makají na novým zařízení. U PC je situace trochu jiná, protože výrobce neví, v jakém systému to zařízení má pracovat, a protože chce co nejvíc prodat, udělá ovladače pro systémy na které se mu to vyplatí (řekněme podle podílu na poptávce po jeho zařízení).
Nějak se nechápeme, z hlediska poruchovosti a výkonu by byl správný přístup ala DEBIAN tzn. aby byla zásadní povinnost výrobců a jejich dodavatelů, vynucená LICENCÍ, u těch, kteří chtějí na zařízení instalovat Android (z podmínek licence tedy u google), zveřejnit SPECIFIKACE rozhraní a komunita by pak, kdykoli bude potřeba, mohla dodat kompilovatelné ovladače.
Protože základní problém dneška je v tom, že velký výrobce, třeba grafiky typicky dodá výrobci mobilu nějakou atypickou grafiku, pro kterou mu licenčně nakompiluje ovladač pro systém a pak případně pro jeden, dva OTA updaty. Po 1- 2 letech až skončí záruka, a přijde nový android už ty ovladače fungovat nemusí a pak není žádná možnost jak to zařízení dál rozumně provozovat. Protože komunita kvůli relativně malýmu množství zařízení určitě nebude reverzně zjišťovat specifikace atd. U globálně rozšířených typů jako Galaxy S5,6,7 kdy jde o stamiliony to komunita samozřejmě zajistí sama, tam se toho nebojím. U menších výrobců nebo u nějakých speciálních typů (třeba s odolností do terénu atd.) na konci záruky se žádný Cyanogenmod nebo Nexus nekoná a zařízení je pak dobrý akorát jako to těžítko(pokud ho nechci provozovat se starým děravým neupdatovaným systémem, samozřejmě).
Tak samozrejme, otazka je zda-li tyhle veci vynucovat jako povinnost. Je hlouposti lidi, ze nekupuji zarizeni, kde ovladace k dispozici jsou. Proto ja treba pri koupi prvni koukam, jestli to ma SoC Snapdragon, protoze ten splnuje prvni podminku pro moznosti customizace, jsou k dispozici ovladace. Treba u SGS7 mas smulu a CyanogenMod se nekona, protoze Samsung Exynos nema volne pristupne ovladace, akorat u americke verze se Snapdragonem jsou, ale ten u nas nesezenes ani jako sedivku, musi se objednavat z USA.
A proto je nejlepsi mit hloupy televizor ala monitor a obsah plnit z externi smart krabicky :)
Jestli se mozilla bude nadale snazit udelat z Firefoxu druhy chrome, tak skonci a to zaslouzene. Mivali proti chrome vyhodu skveleho ekosystemu extensions, ted to zabiji. Mivali skvelou customizaci, ted to zabiji. Jeste ze tu je alespon Palemoon, ale bohuzel, ve features nutne zaostava ...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.