Vlákno názorů ke zprávičce Nejlepší programovací jazyky aneb co se učit v roce 2018 od vlk - Zaujimalo by ma ako by vyzeral rebricek aby...

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 :-)

Pro tvou informaci, to exe nespustis ani v linuxu ani na androidu.

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

Asi si nikdy nepisal nic vacsie v pythone a len pocuvas reci okolo toho, lebo by si vedel ze sa da pisat "kompatibline" ale niesom blazon a pisem vsetko pre p3, lebo p2 dnes uz nema zmysel, a to asi tak ako dnes pisat pre C ,-)

btw, pises C kod v standarde ANSI, C99 alebo C11?

No flame,ale jak napisu treba v pythonu kernel modul?
Srovnavat C s pythonem je mimo,oba jazyky jsou fajn,ale prunik jejich use cases je temer nulovy

Stejne jako v C naskriptujes webovou stranku.

Ano, v C jde naskriptovat webová stránka. A hřebík jde zatlouct šroubovákem.

Ani jedno nejde, klidne si to zkus. A o tom to prave je. Je hloupost posuzovat nastroje na zaklade ukolu, pro ktere nejsou urceny.

Dynamickou webovou stránku v C jsem už dělal. Omlouvám se, nevěděl jsem, že to nejde...

To jsi mohl delat, ale o tom rec nebyla. Ty ani nevis co to znamena a pletes si to s jinou cinnosti :-). A myslim ze takhle to ma vetsina lidi, ktera se o necem zavedenem vyjadruje s despektem. Nema znalosti ani zkusenosti, jen predsudky a nevi o cem je rec .

Dělal nebo skriptoval? Jestli skriptoval, pak C je skriptovací jazyk. V diskusích se člověk dozvídá stále něco nového.

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.

dynamická stránka může znamenat i stránka generovaná na serveru.

Ta může být vytvořena dynamicky, ale sama o sobě je statická. Dynamické chování stránky zajišťuje JavaScript a je v tom Céčkem nenahraditelný. Tak moc jednoduché to je a stejně to tady evidentně spousta lidí nechápe a je zmatená, byť má potřebu se proti JS vymezovat.

Existuje emscripten.

Jde to, ale je to hloupost, dělat weby v C může jen pošahaný hipster.

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

Bavili jste se o pythonu a když se řekne "naskriptujes webovou stranku", tak si většina lidí představí server side script.

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

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 :)

Slovné spojenie "lepšie optimálny" neexistuje. Slovo "optimus" je tretí stupeň od "bonus". Čiže "lepšie optimálny" znamená niečo ako "lepšie najlepší", čo je blbosť.

To je odpoved lineho C++ programatora, ktery se nechce naucit pouzivat C a pouziva ho jako C++. To jest neumi v nem napsat citelny kod a neumi myslet jinak nez objektove. Tuto svou neschopnost pak vydava za nschopnost jazyka, ktery neovlada.

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.

Osobne nevidim dovod zlomu medzi mensimi a vacsimi procesormi.
Minimalny program "hello blinky" v C++ pre M0 zabera menej nez 200B pri -O1 a z toho je vacsina kodu NMI handlery a startup kod. (samozrejme vypnute vynimky, rtti, ...)