Vlákno názorů k článku Hacking Team: co všechno uměl a jak to dokázal? od thomaas - Heh, poprví co jsem otevřel dokumentaci funkce ABS...

Abych to trochu upřesnil: Nerozporuji nic z citovaného komentáře, jen úplně nechápu, proč se dnes ještě pořád píší vysokoúrovňové aplikace v nízkoúrovňových jazycích. Zákonitě pak vzniká mnohem víc bezpečnostních chyb typu přetečení zásobníku a podobných.

výkon možná bude jeden z těch důvodů. Další důvod bude asi existující ekosystém, který u těch starší (a často nízkoúrovňových) jazyků je hodně rozsáhlý. Vysokoúrovňový jazyk mi zase nedává takovou volnost.

Každopádně se zkus zeptat programátorů kolem tebe proč neprogramují třeba v Adě?

Ano, výkon je jeden z hlavních argumentů, které slýchávám. Nicméně to podle mě platí čím dál tím méně. Samozřejmě, pro jádro OS je výkon kritický, stejně tak ve hrách, u vykreslovacího jádra webového prohlížeče, a tak podobně. Jenže většina programátorů nepíše nic z toho, a stejně používají nízkoúrovňové jazyky. U kancelářských a webových aplikací výkon obvykle není problém (pokud neobsluhuji miliony klientů), přesto se zcela nové aplikace píší hodně v C, C++, Javě. A výkon v podání Javy není zrovna tak oslňující.

Myslím, že právě ten ekosystém je rozhodující. Pro Javu existuje nespočet tutoriálů, hotových řešení, knihoven apod. A to je výhoda i nevýhoda. Právě díky tomu může programovat kdekdo, i ten, kdo vůbec neví, co dělá, jen vezme několik knihoven, zkopíruje pár řádků ze StackOverflow a aplikace je na světě :-). (U webových aplikací má takovou reputaci PHP.) A nemám nic proti takovým lidem, snad každý (včetně mě) si tím prošel. Jen si myslím, že pro člověka, který tomu nerozumí moc do hloubky, je takový jazyk příliš nebezpečná zbraň.

Lepší způsob je podle mě začít programovat v jazyce, kde se tak snadno nemůžu „střelit do nohy“, tedy kde tak snadno nevyrobím kritickou bezpečnostní chybu. A pak, když ovládnu základní principy, algoritmizaci a naučím se víc o fungování HW, o bezpečnostních problémech atp., se můžu pustit do C, C++. Alespoň už budu vědět, na co si dávat pozor a co se tam skrývá za problémy. Problémy, o kterých jako začínající programátor nemám ani ponětí. Abych totiž dobře programoval v C nebo C++, musím myslet na velice mnoho věcí najednou. Jako začínající programátor to nedokážu. Já osobně to nedokážu ani teď. A troufnu si tvrdit, že to nedokáže ani většina ostatních programátorů. Proto také osobně větší věci v C a C++ nedělám – prostě si na to netroufnu.

(Pozn. na okraj: Na VŠ jsme samozřejmě začali s C, pak přišlo C++ a pak teprve další jazyky (Java, Smalltalk). Podle mě by to bylo vhodnější přesně naopak. Začít Smalltalkem, pokračovat Javou a pak C++ nebo C.)

ad Ada: V mém okolí nikdo Adu neumí nebo nezná :-), nicméně ve firmě programujeme právě ve Smalltalku.

popravdě pokud jste brali C, C++, Java, tak to jsou jazyky na jedno brdo a +- uprostřed celého ekosystému. Smalltalk už je zajímavější, i když tedy podle mě šel špatným směrem (vše implicitně měnitelné, až do absurdních důsledků). Měli jste i nějaký základy funkcionálního paradigmatu? To by vám dalo asi víc, než rozebírat rozdíly C++ a Javy (ale za to samozřejmě nemůžete, studijní plán nalinkoval někdo jinej).

Ano, zapsal jsem si i předmět o funkcionálním a logickém paradigmatu, ale pouze jako volitelný. Povinný v době mého studia nebyl, od té doby se to již mělo změnit, nekoukal jsem na aktuální studijní plány. Ten předmět mi dal hodně, i když mi ani jedno k srdci nepřirostlo: v době studia jsem měl za sebou již několikaleté zkušenosti s procedurálním programováním, to už se přeci jen myšlení trochu hůře mění. Slyšel jsem dokonce názor, že je snazší naučit neprogramátora Smalltalk, než naučit „céčkaře“ Smalltalk. Něco na tom bude. Java byla mimochodem také oficiálně nepovinná – zapsal jsem si ji čistě ze zájmu („co na tom všichni vidí?“) – ale další povinné předměty používaly Javu jako prostředek pro ukázky kódu, semestrální práce apod.

Hej, hej, kde se v roce 2017 programuje ve Smalltalku? Já chci taky. :-)

V roce 2017 se ve Smalltalku pořád programuje. Dost často jde o údržbu stávajících systémů (v bankovnictví, pojišťovnictví), ale objevují se i nové aplikace. Slyšel jsem třeba o firmě, kde Smalltalk používají výhradně k rychlému prototypování. Když dojdou k finální verzi, implementují to v „normálním“ jazyce, kde vývoj trvá déle :-). Znáte např. Pharo? To je takový modernější Smalltalk s aktivní a rostoucí komunitou. V porovnání s C/C++/Java/C#/Ja­vaScript/atd. je to samozřejmě jen kapka v oceánu. V ČR je bohužel možností pomálu, v relativní míře možná ještě méně než v jiných evropských zemích (třeba Německo). Ale pokud hledáte práci ve Smalltalku, zeptejte se na Pharo mailing listu, určitě něco najdete. My momentálně nikoho nesháníme, pouze výhledově budeme potřebovat další lidi. Pokud chcete něco exotičtějšího než Evropu, tu a tam se objeví poptávka v USA nebo v Indii (Bangalore) :-).

Bohužel se dost často také stává, že kvalitní Smalltalkery si pro sebe vyhlídne firma pracující s jinými technologiemi. Firmy totiž pořád berou Smalltalk trochu jako záruku kvality programátora. A pak je jedno, v čem daný člověk píše, konkrétní jazyk je jen nástroj. Třeba Google takto „krade“ Smalltalkery. Firmy, které ve Smalltalku vyvíjí i nové věci, jsou převážně malé, a tedy nemůžou člověku nabídnout takové podmínky (zejména finanční) jako Google.

Programatori okolo mna programuju v jazyku ADA, podobne ako ja. Strata vykonu mozno 10-15% je bohato vyvazena bezpecnostou (defaultne kontrola ci som v ramci pola, kontrola tried atd), cistotou kodu (ziadne #define a preprocesorovy humus), jednoduchostou migracie aplikacii [bez grafickeho kukucu] - Win, Linux, HPUX (big endian), OpenVMS.

Silne ocenujem aj zmysluplne tracebacky, ked to zarve na nejakej chybe (napr. to indexovanie pola) a zarve to hned, nie az o milion cyklov, az sa prejavi nejaky nasledok nasledku.

Robime riadiace systemy (SCADA, MES), ktore musia fungovat dlho a stabilne.

Nejvetsi peklo ktery sem videl bylo node.js a python eggs... Podivejte se na GIS a OpenStreet maps aplikace ktery generuji vase vlastni mapy (tile server). Chtel bych videt jak to naportujete na yocto :) Stejne tak inteligentni instalace v pythonu... rozlucte se se zjistovanim zavislosti a proc to nebezi. Peklo narozdil od cmake (alespon tak jak se pouziva v gnuradiu).

jj, nejlepsi sou programatori, kery neresej ty "implementacni detaily" ... pak to vypada jako iinfo a root.

Ale no tak, neřešit implementační detaily neznamená psát špatný kód, dle mé zkušenosti je to mnohdy právě naopak. Musíte ale programovat na platformě, která vás od toho opravdu odstíní (a sama to dělá dobře). Neřešit implementační detaily na platformě, která je za vás neřeší, je samozřejmě cesta do pekel.

Píší se kvůli výkonu. Vynecháváte balast vyšší úrovně abstrakce a jdete cíleně na nižší úroveň, na které máte větší kontrolu nad tím, co se dělá a hlavně co se nedělá. V zásadě vám nic nebrání v používání BigInt apod. Jenže ten výkon a paměťové nároky jsou rázem úplně někde jinde. Proto malá část vývojářů dělá ústupky a používá méně neprůstřelné, ale zato rychlejší prostředky. Ten zbytek je pak napodobuje, zjevně bez hlubších znalostí toho "něco za něco".

Každopádně nejde jen o špeky typu "MinInt != -MaxInt". Lidé běžně ani netuší, že vůbec nějaký MinInt a MaxInt existují. Třebas v C na to narážíme pořád - prostě si borec na uložení dne v roce vyhradí unsigned byte a pak špekuluje, proč to začátkem září přestalo fungovat, když to před tím půl roku jelo. Proč unsigned byte? Protože na den v týdnu, den v měsíci, měsíc v roce i počet let od roku 1900 tam unsigned byte byl a on to jen obšlehnul když si dělal proměnnou pro sestavení datumu pro JD Edwards (formát DDDYYY, kde DDD je právě kolikátý je to den v roce a YYY je počet let od roku 1900). A jeho reakce? Prostě si myslel, že byte na 3 číslice stačí.

V tomhle je třebas dobrý Oracle, tam máte NUMBER. Ale už v PL/SQL je i PLS_INTEGER, INTEGER, FLOAT atd. A v tom chlapci obvykle plavou.

Total Commander je napsaný v Delphi

Je, a funguje (stale) i na windows 3.1.

napriklad ktere funkce a ktere procesory?

A mely by to delat i aritmeticke posuny doprava u -1 nebo tam je to ok?

Přerušení negenerují, generují carry flag. Ale je to jedna či dvě (clear carry) instrukce navíc, takže najednou každá operace s čísly trvá třikrát déle. V tom lepším případě, kdy to nerozbije superskalární frontu.