Na serveru Linux and Ubuntu vyšel článek se šesti podle autora nejlepšími programovacími jazyky, které má cenu se učit v příštím roce. Uvádí zde Python, C/C++, PHP, JavaScript, SQL a Kotlin. Naopak chybí například Java nebo Go. Jaký jazyk je podle vás nejlepší a má cenu se jej učit v příštím roce?
Nejlepší programovací jazyk, který ma cenu se učit v roce 2018
Takže přesně stejně, jako se to dělá v Pythonu? Kde navíc (nezávisle na multiprocess architektuře aplikace) můžu používat i skutečná vlákna například aby mi IO neblokovalo proces?
Ne nutně - záleží na architektuře jazyka. Kupříkladu Erlang má svoje vlastní vlákna (kterým se nesmyslně říká procesy), která jsou přiřazena vláknům (skutečným) pomocí vlastního scheduleru, který zajišťuje, že počet skutečných vláken nepřesáhne počet jader CPU - tudíž odpadají nároky na vytváření nových vláken a přepínání mezi nimi.
Tím komentářem jsem myslel hlavně to, že GIL se Python už asi nikdy nezbaví, ale mínusáři to nedali, protože jsem si dovolil zmínit ten ošklivý JS :) Threading v Pythonu je vtip, který má tolik omezení, že je lepší async nebo rovnou ten multiprocess.
Non-blocking io má třeba node.js přes libuv od samého začátku, takže moc nerozumím tomu příkladu s io. Co se týče vláken tak V8 už umožňuje spustit více VM v jednom procesu, takže když člověk pořeší komunikaci tak má multithreaded aplikaci aniž by musel přejít na multiprocess (v případě, že multiprocess není potřeba).
Singlethread by design je výhoda, protože není potřeba řešit věci, které rozumně v takovém jazyku řešit asi ani nejdou. Kompromis typu SharedArrayBuffer a WebWorkers v JS mi přijde jako mnohem rozumnější řešení než multithreading zabitý díky GIL.
Nevím, mně to moc netrápí - Python je inherentně pomalý, takže nemá cenu používat ho pro aplikace, kde je potřeba výkon (a tedy by se hodilo více threadů), a blokující operace (I/O, síť) i výpočetně náročné věci co si napíšeš v C (nebo použiješ nějakou knihovnu typu numpy) a voláš je přes Swig/(C)FFI GIL uvolňují a více threadů umí.
Ty magore, inteligencni front je vše, co vyhovuje uživatelům a slouží jim dobře. Mrkni na bazos.cz, ten maník uspěl s tím, že users nestojí o ty tvoje sračičky v js. Používají to, ptž to plní svojí funkci a je to jednoduchý, pustím to klidně na totálně ořezaný verzi debiana na RPI Zero a jede to vše v pohodě. Klidně na HTML1x browseru. Zkus na tom pustit třeba fejsksich shit a můžu si jít zahrát fotbal.
Ono je to podobné s tím js. Je moře patlalů, co v tom píše, ale je to šunt. Ona odpověď je poměrně jednoduchá. Zkus říct js "programátorovi", ať napíše driver v C nebo Asm, ani kdyby se posral to nedá. Nebo ať udělá jen blbý build C projektu, js maník bude zděšeně koukat. Ale řekni maníkovi, co umí opravdu programovat třeba v C nebo C++ a i kdyby js nikdy neviděl, za chvíli to dá. Protože js je bastlící jazyk, nemusíš nic umět a chápat o systému, ani nic neovlivníš, i kdybys věděl, prostě píšeš kód bez přemýšlení o dopadu. A ty dutý hlavy v js ti řeknou, že to hw utáhne nebo ať uživatel upgraduje. Prostě bastliči, jak tady někdo psal přede mnou.
ne nejsou, ve skutecnosti sovetske tanky mely podvozky christie z US..a motory taktez americke provience , a par britskych RR.
nemci pouze tanky ( spis tankovou taktiku) testovali v rusku.
A nezapomen ze nemci zacali valku s Pz.I a Pz.II coz zrovna moc vykonne stroj nebyly. Zatimco soveti s vecmi jako renault-17, T-28 a dalsimi podivnostmi. Ze zacatku barbarosy rusaky zachranila Americka a Britska materilni pomoc. Pak prestehovni tovaren za ural + jejich nasazaneni na valecnou vyrobu narozdil od nemcu kteri s valecnou vyrobou nezacali do konce 44.
Materiál na pancíř, technologie svařování, motor, převodovka, odpružení, pásy..... Neměli zkušenosti s podobně těžkými tanky. Neměli optimalizované výrobní procesy, proto spotřebovali na jeden tank několikanásobek člověkohodin.
"In November of 1941, high ranking engineers, industry representatives, and armament directorate officers came to my tank army in order to familiarize themselves with the Russian T-34 tank. Frontline officers suggested that we should build tanks exactly like the T-34 in order to correct the unpleasant position of our armoured forces, but this position did not receive support from the engineers. Not because they were opposed to imitation, but because it was not possible to rapidly set up manufacturing of important components, especially the diesel motor. Additionally, our hardened steel, whose quality was dropping due to a lack of natural resources, was inferior to the Russians' hardened steel."
H. Guderian, "Panzer Leader", page 268
Pokud umím anglicky, tak jim nechyběli technologie, ale nemohli přenastavit výrobu* a ztráceli kvalitu kalené oceli, ale ne kvůli tomu, že by neměli technologie, ale kvůli nedostatku přírodních zdrojů ... což bych řekl, že je podstatný rozdíl ve výkladu onoho odstavce ....
* proč se tam nepíše, možná ty zdroje, ale že by neuměli udělat dieslový motor, notabene ho třeba i okopírovat, si nemyslím.
Je to poválečné tvrzení nacistického generála. Bral bych ho s rezervou. V době studené války nemohl napsat pravdu. Problém byl v zaostalém ocelářství a celkové neefektivitě kapitalistické ekonomiky. Na nedostatek surovin to svalovali po válce.
Německé tanky měly benzínové motory. V technologii dieslových motorů byli nacisté pozadu.
Dieselove motory (napriklad do ponoriek) Nemci robit vedeli. Ale nemali ropu a z uhlia vedeli vyrobit len benzin.
Male zasoby ropy (z ropnych poll v Rumunsku) z ktorej vyrabali naftu, si setrili pre ponorky, preto museli tanky a ostatna technika fungovat na benzin, aj ked to prinasalo obrovske mnozstvo problemov ako kratky dojazd na nadrz a velke riziko poziaru pri zasahu.
Citát jsem uvedl pro potvrzení mého tvrzení, že nacisté chtěli t-34 okopírovat.
Po válce (během studené války) v okupované SRN nemohl psát pozitivně o SSSR. Kdyby nebyl dostatečně protikomunistický, ty jeho paměti by nevydali. Paměti generálů jako Manstein a Guderian sloužily hlavně protikomunistické propagandě i v USA byli Němci prezentování jako "ti dobří".
Kdyby měli Němci skutečně nedostatek oceli, tak by jejich tanky nebyly o tolik těžší než sovětské. Neuměli vyrobit stejně kvalitní ocel, tak to doháněli množstvím.
@mmm
Metalurgie je soubor technologií, dokonce celý vědní a výrobní obor, nicméně aktuální nedostatek surovin není problém technoligický, ale logistický.
Motor s potřebnou charakteristikou mohli klidně okopírovat. Už jenom to, že by se v celé říší nenašel nikdo kdo by neuměl udělat dieslový motor alespoň podobný, když měli vlastní výroby letadel, raketový program, lodstva, tankových vojsk, je směšné.
Ale v tom citátu se nepíše že neuměli, ale že nemohli přenastavit výrobu na dieslové motory. A pokud to bylo v době, kdy začali dostávat na zadek, tak se nedivím, že nezastavili a nerozpůlili výrobu něčeho, k čemu neměli suroviny ...
Nehledě na to, že přejít na vzdálené frontě na jiný typ pohonu tanků, ne tak ještě že by to by druhý, paralelní, když připočítáš konstrukci, výrobu a továrny, dopravu, opravárenský servis, náhradní díly, pohoné hmoty, výcvik, je klidně i otázka několika let. Ne dvou týdnů, nebo měsíce. Takový krok se v defenzívě může rovnat kapitulaci ...
To je totalni nesmysl. Jazyk C je stejne jednodýchy jako JS, pravdepodobne jeste jednodussi. Tve priklady nejsou o jazyku, ale o odbornych znalostech. Rekniprogramatorovi v C, at napise v JS prezencní a bussines vrstvu nejakeho soap b2b burzovniho reseni a bude v loji uplne stejne.
Já mám poslední dobou opačný problém :) Build C pomocí maka, CMake a v omezené míře autotools si spáchám snadno. Drivery a low level kód píšu často. Ale vyrobit distribuční archiv nějakého projektu v JS je děs - všechny ty neustále se měnící nástroje (npm, bower, gulp, grunt, transcompilery..).
A má PHP alternativu? Už konečně existuje něco, co by mi umožnilo napsat do existující stránky <?python ?> a vyplivnout tam kus kódu? Když jsem takovou věc před rokem hledal, byla situace dost zoufalá - typu „musíte použít šablonovací systém“ a „aplikace musí mít aplikační server!“
A mohl by jsi říct co je na tom návrhu tak moc špatně? Zatím všechny podobné hejty byli od idiotů který si někde vyguglili 10 důvodů proč je JS evil, a pak s tím srali donekonečna. Jedno že těch 10 důvodů akorát ukazovalo na ignoranci a neznalost blba který je napsal místo na díry v JS.
V JS je budoucnost právě díky jeho neomezené flexibilitě. Webové aplikace se nezadržitelně všude rozrůstají prostě proto že je tak snadné a pohodlné je dělat než v jiných alternativních platformách.
I Google se pokusil JS zabít a selhal prostě proto, že je JS tak populární a elegantní.
S budoucností JavaScriptu bych si nebyl tak jistý, už jsi slyšel o WebAssembly? http://webassembly.org/
Jsi trochu zaspal dobu, web apps byly hlavní trend tak kolem 2000, teď to jsou mobilní aplikace. Firmy a často startupy se vůbec s webovou apkou neserou a udělají jen ve wordpressu odkaz na svoje mobilní apky, takže vývoje je backend v java, python, ccko, c# whatever a na to si přes nějaké rest api napojí svoje mobilní apky. A ty dělají nativní, ptž ty, co se zkoušely dělat v js nejsou uživateli přijímány dobře. Takže nikdo nehledá js programátora pro mobily, ale hledají se lidi se znalostí Andoidu a iOS nativního vývoje. To je dnešní trend, tak se prober. A v korporátu je taky trend držet win desktopy a na nich nativní apky, je to podobné, jak s těmi mobily. Zrovna nedávno jsme vyhazovali u jednoho korpu v top500 web apku namísto desktopu + k tomu napsané mobilní apps. Jediné, co se ještě zvažuje je lightweight web klient, minimum js a rychle rendrovaný, především jsou věci na reporting a rychlé zpracování dat pro koncáky. Právě proto, jak je js rozežraný a systémově neefektivní a nikdo z těch korporátů nechce každé 2 roky upgradovat kompy kvůli tomu, že web vývojáři jsou prasata a cpou js všude možně a uživatelé pak čekají několik minut, než jim to prohlížeč přelouská. O to nikdo nestojí, proto vládnou nativní mobilní apps, rychlé, max. funkčnost, možnost max optimalizace, která u js nikdy nebude, ptž poběží vždy v nějakém tom silně okleštěném sandboxu. A hlavně tenhle trend je vidět v reálu, nejsou to kecy v kleci nějakého js fanatika.
V korporátu většina CPU náročných procesů běží na backendu a ne na frontendu. Na frontendu už vám stačí pouze něco zobrazit nebo sesbírat vstupy.
Prohlížeč (Chrome) je teď na frontend skoro stejně dobrá platforma jako .NET nebo Java. Její mínusy jsou vyvážené jejíma featurama jako je snadný deployment.
To že je taková spousta JS aplikací pomalá není kvůli platformě ale pouze neschopností programátorů. Dobrý programátor napíše dobrou aplikaci v JS i nativní.
Většina korporátů přechází z .NET a Java desktopových appek na HTML. Můj tým také. A světe div se, ono to funguje líp než predchozí .NET verze. Ovšem transpilujeme z Kotlinu, JS je nepoužitelný pro větší projekty.
"Populární jazyk v té anketě nemá šanci, protože už ho všichni znají."
Pak je na místě otázka, zda si nepletete významy následujících slov:
nejlepší vs. nejpopulárnější
popularita vs. rozšířenost
známost vs. popularita
rozšířenost vs. kvalita
Protože to že se něco rozšíří ještě neznamená, že je to ku prospěchu těch co to šíří a/nebo těch které to potká.
To je jako kdybyste dnes řekl, že islám je nejlepší náboženství, 3 generace zpět že Komunismus/Marxismus-Leninismus je nejlepší systém správy věcí veřejných a nějakých 7 století nazpět že mor je nejlepší zdravotní kondice - to vše jen na základě rozšířenosti daného... konceptu... v populaci.
Nejpopulárnější v tomto případě znamená nejlepší, protože má největší ekosystém knihoven, nejvyladěnější implementace interpretu, nejvíc zdrojů informací.
K těm přirovnáním. Ano. Úspěch ideologie je určen počtem a oddaností stoupenců. To, že vy vyznáváte jinou ideologii nic neznamená. Nejste lepší. Naopak, chybí vám potřebný fanatismus.
"Nejpopulárnější v tomto případě znamená nejlepší,"
Aha, takže pro vás platí rovnice popularita = kvalita
"Úspěch ideologie je určen počtem a oddaností stoupenců"
Ale my se zde nebavíme o úspěšnosti, nýbrž o kvalitě. Nikdo soudný zde nebude popírat úspěch JavaScriptu. To co tu ale dost lidí nadzvedlo je to vaše "Nejlepší jazyk." On si termín "nejlepší" typicky asociují s "kvalitou" dané věci, přičemž kvalitu si lidé vyhodnocují podle vlastních kritérií.
To že vaším jediným měřítkem kvality je rozšířenost už je váš problém.
Pokud byst chtěl nějak OBJEKTIVNĚ vyhodnotit kvalitu, tak byste tedy musel měřit spokojenost lidí co danou technologii používají - a s tím byste u JavaScriptu myslím dost narazil (viz. příspěvky zde v diskuzi).
@eee
Ale termín "nejlepší" když stojí sám o sobě nutně zahrnuje kvalitu. Nebo vy byste souhlasil např. s tvrzením "Nejlepší bydlení je v paneláku" ???
Když si ale změníme definici "nejlepšího" na co nejvyšší poměr cena/kvalita nebo na dostupnost, tak tvrzení "Nejlepší bydlení je v paneláku" už dává smysl - vše tedy záleží na tom, v jaké doméně dané tvrzení vyhodnocujete.
mmm vyhodnocuje "nejlepší" podle toho co používá nejvíce lidí a pak s tím tady naráží. Kdyby původně napsal, že jde o NEJROZŠÍŘENĚJŠÍ jazyk, jeho tvrzení by mělo smysl a nikdo by proti tomu nemohl nic namítat - a to ani ten největší odpůrce JavaScriptu.
Fakt nechápu jak je možný, že bandě ajťáků tady na Rootu dělá problém logika a význam slov.
Já bych rozhodně s tím tvrzením o paneláku bez výhrad souhlasil. Uznávám, že to může být věc vkusu a někdo by mohl z nějakého divného důvodu preferovat dům.
Třeba kvůli tomu, že má málo problému a když se něco pokazí (zatékající střecha, pokažený boiler a ucpaný odpad) tak je to jeho problém a musí to řešit, což ho vzrušuje. Nebo kvůli mizernému internetu, díky kterému se může vymlouvat na pozdě odevzdanou práci. Nebo možná láká více než dvojnásobná pravděpodobnost vykradení? Nebo je rád otrokem. Otrokem zahrady, kterou musí sekat atd. Kdo ví.
JS je nocni mura, na hrani asi dobry ale vetsi veci? asi ne.
Heh, zkousel si nedy zprovoznit tilt server (vlastni offline OSM mapy) ? Vsechno to je v node.js protoze ty GIS amateri asi nic jinyho neumi. Myslim, ze slozitost projektu je uz rozumna na posouzeni jazyka. Rek bych ze instalace zavislosti a asi i jednotlive vytovory jsou pekna prasarna. Propomina mi to produkci SW jedne nejmenovane spolecnosti z Redmondu
To je trochu nestastna metafora. Clovek predsa vnima polievku pomocou zmyslov - cuch, chut a hmat (na ociach nech ma trebars satku). Navyse ich musi mat natrenovane predom.
Je preto uplne jedno z coho je polievka uvarena. Pokial vonia ako sosovica a chuti ako sosovica, nech je trebars aj z h*ven (vid. znamy kolobeh v Conkinovi).
Ak uzivatel zmyslami nedokaze rozlisit povahu sosovice, ide v podstate o ekonomicky aspekt - ci je lacnejsie varit sosovicu zo sosovice alebo z h*ven.
Snažím se maximálně používat primární suroviny a nekupovat polotovary, párky, salámy, vyhýbám se fastfoodům... Mám zahradu a rodinu co má slepice, králíky, nutrie, známé řezníky, pěstitele ovoce a zeleniny... Vím že to není stoprocentní, ale čočkovou vařím z čočky a ne z h*ven. Takže asi tak.
C++ se hodí kamkoliv, kde je dostupný plnohodnotný C++ kompilátor (ideálně ještě s knihovnou Boost). To je totitž kompletní C++ prostředí.
Až bude .NET plnohodnotně se vším všudy portovaný na Linux, tak se mu server s názvem "LinuxAndUbuntu" taky třeba bude věnovat - podobně jako třeba Javě.
.Net core je celkem nový a staré aplikace v tom asi moc nepůjdou, musí se to částečně přepsat a znovu překládat
Mono taky není ideální, část věcí je zabugovaná, část věcí tam chybí (třeba WPF) a část interfaců má implementace, které akorát vyhazují NotImplementedException :-). Pokud má člověk reálnou aplikaci složitější než HelloWorld a zkusí ji spustit, tak to fungovat může, ale nemusí.
.NET core je primarne pro server side aplikace, konec koncu tech WPF aplikaci se netvori moc uz ani na Windows.
S portaci mas pravdu, ale s .NET Core 2.0 se to hodne zlepsilo, pribylo hodne API z .NET frameworku, portace je vetsinou hodne pohodova u knihoven, pokud je vubec neco potreba menit (hodne zalezi, jak stary .NET framework to puvodne cililo).
A pro nove aplikace je to docela sympaticke prostredi, s VS Code se to pohodle vyviji na Linuxu, MS jednou pro zmenu prijemne prekvapil :)
To ze "nie C" je cisto moj nazor, podla mna uz ten jazyk ma svoje roky za sebou a C++ je jeho dobry nastupca ktory ho plne nahradza, je stale rovnako low level a navyse prinasa velmi vela uzitocnych veci, pisat dnes novy kod v C je uz hlupost a radsej malo by ist do softwaroveho muzea.
takze pisete vzdycky 2 verze, Jednu pro p2 a druhou pro p3. A az udelaji p4 tak dalsi verzi. To je skutecne senzacni.
Jeste pro vasi informaci. To EXE, ktere bylo napsano v C a prelozeno uz ten c-prekladac na zadnem jinem pocitaci nepotrbuje. Tam uz je to na rozdil od toho vaseho preferovaneho udelatka prelozene :-)
tak ja jsem me programy vytvorene v SCO-Unixu pod linuxem vesele spoustel. (iBCS). Ale jo, to je davna minulost.
Pan Stehule hovoril o systemovych utilitach a proc ma pravdu je videt na 'yumu' , ktery je v RHEL zavisly na urcite verzi pythonu a to je prave ta debilita, Systemovy tool musi byt zavisly jen na sobe a ne na rade jinych komponent , zvlast kdyz takova systemova komponenta je urcena pro pohodlnou vymenu sebe sama :-) Jak na tohle ti pitomci v RedHatu prisli mi fakt hlava nebere.
Zkuste si nainstalovat pomoci yumu nove django na centos 6. :-)
Povedzte Kefalín, čo vy si predstavujete pod takým slovom skript? https://root.cern.ch/cint
Není poznat koho se ptáš, a tím rádoby vtipným oslovením jsi to nevylepšil.
Obecně je skript interpretovaný program. U webových dynamických stránek je tímto interpretem webový prohlížeč. Takže stále setrváváme v pozici, že někteří diskutující ani netuší o čem je řeč, ale rozhodně se proti tomu vymezují :-). Kdo si myslí, že existuje univerzální programovací jazyk na všchno, jednoduše nemá dostatečný rozhled.
eee, co takhle si nejdřív ujasnit rozdíl mezi server-side a client-side dynamickou webovou stránkou, než nás tady začneš obšťastňovat svými moudry? https://en.m.wikipedia.org/wiki/Dynamic_web_page
To si právě představí menšina bez rozhledu, která vidí jen to svoje. Python je považován za programovací jazyk a v jeho kontextu se programuje, vytvářejí ucelené programy. Když se mluví o skriptování webových stránek, většině lidí je zřejmé, že jde o jejich oživení javascriptem. Skriptují se aplikace, případně případně příkazový řádek. A promouly dodávám, že skriptovat aplikaci neznamená ji vytvářet, ale skriptem ovládat. Tak jak to js dělá ve webovém prohlížeči. Normálnímu it vzdělanému člověku by měl být jasný rozdíl mezi programováním a skriptováním aplikace.
To by mě vážně zajímalo, proč myslíte, že C má "svoje roky za sebou" ? V embedded světě se C díky své přehlednosti používá daleko více a naopak od C++ se upustilo už někdy před 10-ti lety.
Podobně když budu chtít napsat nějakou aplikaci, tak použiji nějaký vysokoúrovňový jazyk s GC a nebudu se mastit s nějakými pointery a manuálním uvolňováním paměti.
Pokud jde o výkon, tak prakticky všechny vysokoúrovňové jazyky nabízejí FFI do C - do C++ pak už jen některé, protože ten jazyk je prostě příliš překombinovaný.
Takže za mě má C budoucnost coby univerzální nízkoúrovňový jazyk, naopak v C++ žádnou budoucnost nevidím - to je podle mě takový nový Cobol.
To je právě ono, podobné diskuze o nej jazyku mě vždy dostávají, jazyk se má vybírat podle use case a ne podle toho co má programátor rád. Takže souhlas.
Každý jazyk má něco do sebe a každý vznikl pro nějakou oblast, protože pokud by existoval dokonalý programovací jazyk tak by nevznikaly další a další.
posledne 4 roky v embedded vyuzivam vyhradne C++ a podla moznosti uz nikdy viac ciste C!
preco?
- uz aj pri malych tooloch je to pohodlnejsie
- dokazem mat cistejsi a hlavne citatelnejsi kod
- nepotrebujem prasit kod s nejakymi #define
- nemusim emulovat objekty, ale pouzivam skutocny objektovy pristup
- kod ktory vytvorim v C++pre embedded a po dodrzani urcitych pravidiel je rovnako ak nie lepsie optimalny ako podobny kod ktory mi vypadne z C
- C++ je rovnako nizkourovnovy ako C ale pridava mnoho veci ktore ten jazyk posuva na vyssiu uroven ako obycajne C pri zachovani nizko urovnovnovosti
- pise sa rok 2017 (vlastne uz za nejakych 24hodin 2018) a prave preto by sme mali nasledovat trocha dobu
Myslim si ze zarity C-ckari co nemaju radi C++ su prave riadne lenivy ludia ktorim sa nechce naucit nieco a posunut sa trocha dalej aby napriklad vylepsili kvalitu svojho kodu.
celkem souhlas az na:
- kod ktory vytvorim v C++pre embedded a po dodrzani urcitych pravidiel je rovnako ak nie lepsie optimalny ako podobny kod ktory mi vypadne z C
toto by chtelo dolozit prikladem. Asi mas na mysli, ze vysledny strojak bude rychlejsi nebo zabere min mista (jen se ujistuji co je mysleno tim "lepsie optimalny", protoze "optimalni" je uz samo o sobe absolutni meritko :)
to jdes proti proudu: https://www.tiobe.com/tiobe-index/, cituji jen uvod (protoze se ta stranka do tydne zmeni):
"The programming languages Kotlin and C seem to be the only candidates to become programming language of the year 2017. TIOBE will announce the winner of this award next month. Thanks to the boost of small software devices and the increase of low level software in the automotive industry, the C programming language gained a lot of popularity in 2017."
C++ si udelalo spatnou povest a i kdyz C++11 (14) uslo velmi dlouhou cestu dopredu, tak "klasicke" C++ byl velkej humac (hlavne, kdyz se pouzivalo jen jako C s tridami, coz bylo v embedded nutnost)
Ano, je to bohuzial tak, ale dovod preco C v embedded svete vedie osobne vidim inde.
Pracujem v danom odvetvi uz celkom dlho a mam trosku predstavu ako to je (aspon u nas vo firme). Jednak najst embedded vyvojara je stale celkom narocne, pretoze vela SW vyvojarov netusi takmer nic o elektronike a embedded vyvojar by sa mal v tom orientovat (aspon vediet citat schemu, pochopit periferie z datasheetov a dokazat si pripojit osciloskop alebo logicky analyzer). a za tych co sa k nam dostanu sme niekedy radi ze vedia aspon C. Druhy problem je ze aj ked vo firme je vela vyvojarov ktori C++ ovladaju tak su donuteni (ci uz z projektovo-historickych dovodov, alebo inych napriklad politickych) programovat prave v C-cku.
Nadruhu stranu casy sa menia a vela mladych vyvojarov uz s C++ ma skusenosti a ma aj motivaciu v tom vyvijat a musim povedat ze nove projekty sa coraz castejsie pisu prave v C++. Tak hadam o rok bude C++ niekde inde v embedded svete.
Osobne pracujem na novych projektoch kde sme zacinali prakticky na zelenej luke a nebol problem C++ presadit a som zato rad.
(mam na mysli minimalne C++11)
v podstate souhlas, diky za doplneni. Jen me napada - delate ty nove embedded aplikace s nejakymi vykonnejsimi cipy typu H8SX, H8/300H, ARM, TriCore, nebo i s mensimi cipy (MSP 430 nebo dokonce osmibity)?
U nas se to lamalo nekde u MSP 430: mensi cipy jen C (C++ melo mnohem vetsi runtime, neslo PRAKTICKY pouzit nic slozitejsiho typu vyjimky apod.), vetsi cipy klidne C++. Mozna mozna v budoucnu zkusime i Rust, ale zatim to nema tak dobry tooling.
Starsie projekty: MSP430: +/-32KB/2KB flash/ram (IAR - C++99 - ale chybali mi nejake veci z 11)
Aktualne ARM: od malinkych M0 16KB/2KB az po velke M4 s 1MB/320KB flash/ram (GCC C++11 alebo 14)
Vsade s vypnutymi vynimkami a rtti, new a delete len nad lokalnym pool-om, ziadne std (lebo to vyuziva vynimky) ale mame vlastne zjednodusene/usite implementacie zakladnych funkcii ... u tych najvacsih procakoch mame nejaku newlib, to prida tak cca 80-150KB kodu ale potom mozem pouzivat cokolkvek z C++ vratane std a boost.
Ale vynimky a RTTI, heap, ale aj thready a podobne su v embedded cesta do pekla a navyse to ma obrovsku reziu lebo v mnohych projektoch riesime prakticky kazdu mikrosekundu.
Uprime, jsem presvedcen, ze nebyt C a C++ zadne komplexni jazyky vyssi urovne nikdy ani nevznikly. No a pak by jsme se tu dohadovaly jestli Fortran, nebo BASIC ;-)
Navic jsou ulohy na ktere je jazyk vyssi urovne naprosto nevhodny; mozna dokonce nepouzitelny. Kdezto C/C++ diky svym vlastnostem je pouzitelny opravdu vsude (nerikam, ze je vsichni musi milovat, jen ze se daji pouzit na vse)
Dal jsem vám +1 za druhý odstavec, ale nesouhlasím s tím začátkem - kupříkladu můj oblíbený Lisp vzniknul daleko dříve než C. To že se neprosadil bylo dáno tím, že se tehdy hledělo jen na výkon, takže Lisp s GC (ještě k tomu špatně naprogramovaným - protože nikdo tehdy nevěděl jak správně přistoupit k automatické správě paměti) neměl tehdy šanci.
Podobně před C tu byl Algol, ze kterého vzniklo jak C, tak třeba ve stejné době (a nezávisle na C) Pascal. Ne ne - C se sice prosadilo, ale už na samém počátku mělo vážnou konkurenci.
Jaký jazyk je "nejlepší" nebo jaký "má smysl" se učit je ve své podstatě absurdní otázka, asi jako jaký cizí jazyk je "nejlepší". Učit se nějaký jazyk má smysl podle toho, čím se člověk chystá zabývat. Na webovky to ještě dlouho budou C#, Java, Ruby, Python a samozřejmě JS, v příštím roce hlavně teda C#, JS a postupně i Go. Go je dále výborné na serverové aplikace, ale hojně se dneska používá i u všeho, co nějak souvisí s kontejnery (jaily) v Linuxu, takže i ten, kdo chce se vrtat v LXD, snapu, dockeru atd. by se měl naučit především Go. Kdo se chce začít zajímat o IoT si musí osvojit C, které je tam stále hlavním jazykem. Rust je pro aplikace, které mají extra nároky na rychlost a/nebo bezpečnost, ale je to relativně složitý hardcore jazyk podobně jako třeba C++, takže představa "naučím se Rust a půjdu se ucházet o práci" je spiš naivní. Ne proto, že by ho člověk nemohl sám naučit, ale proto, že v aplikačních oblastech, kde se používá, zaměstnavatelé hledají lidi, kteří jsou odborníky na nějaký daný problém, a ne běžné programátory. D je dobrý jazyk, ale holt málo rozšířený, a připadá mi, že učit se ho má smysl spíš jenom z osobního zájmu, nebo když někdo hledá přímou náhradu za C++ pro nějaký hobby projekt.
Tak to sa riadne mylis, ja si totiz pamatam na JS spred 20 rokov. To boli casy, ked bol JS nekompatibilny, explorer kraloval, ludia si JS mylili bezne s Javou, neexistovali ziadne JS kniznice, len holy, zle navrhnuty jazyk.
JS bol priselne pomaly, reklama v JS vam mohla spomalit stranku o niekolko sekund.
Nik netusil, ze ide o vyrazne funkcionalny jazyk, nic poriadne sa v tom nedalo spravit. Boli to casy, ked kraloval na frontende Flash.
Aby sa JS stal modnou zalezitostou, museli v Google spravit rychly open source JS engine, explorer sa musel prepadnut, standardizacia sa zacala presadzovat, vzniklo ultrapopularne jQuery, nasledovane Node.js. A v neposlednom rade, vojnu RIA vyhralo HTML5...
Netvrdím, že je špatný, ale třeba mně jako pythonistovi nepřijde jako nějaký upgrade - když jsem někde četl, že autor vzal "to nejlepší z Pythonu a to nejlepší z Perlu", jenom jsem kroutil hlavou, protože Perl mi nijak sexy nepřijde. Chápu, že má svoje příznivce, i Ruby je má, ale oba jsou to minoritní jazyky, které zazářily v úzké oblasti a jsou na ústupu. Pokud má Ruby špatně řešené nástroje, také to o něčem vypovídá.
Taky se mi strašně líbí nová generace C++. Bohužel pro vážnou práci člověk stejně musí znát i ten historický bordel. To je zhruba jako v JS, když už se o něm tak živě diskutuje - ES6 a výš už je vcelku elegantní a použitelný jazyk. Pokud ovšem někdo chce v JS dělat i nějakou serióznější práci, tak se tomu předchozímu bordelu prostě nevyhne, a v těch hovnech si pěkně zaplave.
Anketa vypovídá spíš o návštěvnících roota, než o tom, co se skutečně používá.
https://insights.stackoverflow.com/survey/2017#most-popular-technologies
A, už vím, kam jsem koukal:
https://insights.stackoverflow.com/survey/2017#technology-most-popular-languages-by-occupation
Příště bude podobná anketa, na téma "Které ovoce je nejlepší aneb co začít jíst v roce 2018". Bude to strhující bitva mezi záludnostmi a utajenými výhodami jabka, pomeranče a banánu... Doufám, že si letos konečně lidé uvědomí, jak strašně důležité jsou často opomíjené a nedoceněné limetky...
