HOVD 2017 - Kedvenc szkriptnyelv

HUP

javascript
8% (61 szavazat)
lua
2% (17 szavazat)
*nix shell (bash, csh stb.)
25% (192 szavazat)
perl
7% (53 szavazat)
php
16% (123 szavazat)
powershell
3% (24 szavazat)
python
32% (246 szavazat)
r
1% (11 szavazat)
ruby
2% (19 szavazat)
typescript, coffeescript (javascript jellegu nyelvek)
3% (27 szavazat)
Összes szavazat: 773

( saxus | 2017. 12. 15., p – 20:54 )

Sokáig gondolkodtam a kedvencen, mire rájöttem, hogy azok közül, amelyeket használtam (js, lua, shell script, perl, php, powershell, pythno), valamiért mindegyiket rühellem. :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

lol +1

Vegul "*nix shellre" (inkabb nem ra, hanem ala) ment a szavazatom.

Valamint iden eloszor elgondolkodtam, hogy bar utalom a javascriptet is, de a javascriptre fordulo ideiglenesen piacon levo nyelveket (coffeescript, typescript, clojure) megjobban, es hogy javascriptre szavazva rontanam azok aranyat a javascripthez kepest. De vegul nem ment javascriptre az X-em, ehhez nem eleg enyhe bennem az utalat iranta.

Nem lenne fenntarthatóbb. A fejlesztési, fordítási, debugolási idő végső soron többet elvinne a teljesítménykülönbséghez képest.

(Egységsugarú mérnök urak kedvéért: A fenti állítás nem minden esetben igaz, csak akkor, ha a scriptnyelveket arra használjuk, amire valóak: egyszerű feladatok automatizálására, eseti megoldásokra, PoC-ra. Tehát, a JavaScript keretrendszerre épülő honlapok, illetve a divatdiktatúra által kierőltetett scriptnyelveken (pl. python) összetákolt, több tízezer soros bloatware-ek nem ide tartoznak. Különösen igaz ez akkor, ha a bloatware-t nem egy vagy pár száz ember használja egy cégen belül, hanem többszázmillióan, szerte a világon.)

Bár alapvetően csak egy poén volt, de azért csodálatos, hogy már megint oda jutunk, hogy ahogy te csinálod, úgy pont jó, neked pont lehet, csak más farkával vernéd a csalánt. Egyébként meg a fenét, egyszerű dolgokat Cben sem sokkal bonyolultabb megírni (bár ugye ezt tudjuk, hogy a fejlesztési, fordítási, debugolási idő másnál nem számíthat, uh nálad sem kéne), ráadásul mivel te a fenntartható dolgok híve vagy, ezért amit egy pár száz ember használ a cégen belül, az nyilván nagyonminimum 10 év, szerinted inkább 20-25, komoly esőerdő mennyiséget lehetne megspórolni vele, és kiforrott dolgokon feljleszteni egyébként se kell, enni nem kérne, de persze neked nem kötelező.

Oda jutunk, hogy ismét csak olyan beszűkülten vagy képes gondolkodni, hogy ha valaki natív kódra forduló nyelven ír hatékony programot, az már csalánt ver a farkával.

http://a.te.ervelesi.hibad.hu/mazsolazgatas

Azt pedig már elmondtam szerintem elég sokszor korábban is, hogy nem azzal van nagy baj, hogy a scriptnyelveket vagy a .NET-et használják valamire. Még azzal sincs nagy baj, ha a belsős használatra szánt szoftver megírására egy bloat scriptnyelvet (Python) vagy keretrendszert (.NET) választanak és ezzel kilowattokat pocsékolnak el, miközben spóroltak mondjuk egy hónapot a fejlesztési időn. Valószínűleg a fejlesztői számítógépek által +1 hónap alatt elhasznált kilowattok nagyságrendekkel többre jönnének ki, mint amennyit maga a szoftver többletfogyaszt. A nagy baj ott kezdődik, amikor nem belsős használatra szánt szoftvereket írnak meg bloated módon, amiről már előre tudni, hogy a release után százmilliók fogják használni. Ott már akár egy nap alatt több erőforrás lesz elpocsékolva, mint amennyit a cégnek bele kellett volna fektetni, hogy hatékonyra csinálja meg. Ezt hívják vállalati arroganciának, ami a szoftveriparban sajnos jelentős mértékben ott van, gyakorlatilag minden nagyobb cég folytat ilyen gyakorlatokat. Tehát, a vállalat spórol egy kicsit, a másik oldalon pedig ezzel a kis spórolással óriási kiadásokat generál. Mivel az óriási kiadás mindenkinek csak egy kicsi, ezért nem feltűnő. De ha például összeszámolnánk, hogy a Google szolgáltatásai (YouTube, Maps stb.) a bloated javascript, CSS, webfontos material okádék stb. futtatásához mennyi elpocsékolt energia társul világszerte, akkor egységnyi idő alatt biztos, hogy nagyobb energiamennyiséget kapnánk, mint amennyit a Google-nak el kellett volna használnia arra, hogy megfelelően kioptimalizálja a szoftvereit, vagy mint amennyit a Google a napelem projektjeivel megtermel. (Nem, nem a V8-at kell villogtatni, hogy milyen hűde gyorsan kompájlol, hanem a YouTube felületnek kell olyan gyorsan és hatékonyan mennie, mint egy natív VLC-nek, akár egy régi gépen is, a végeredmény számít, mert az fogja elpöfékelni a kilowattokat és az fogja a lassúságával a felhasználót új gép vásárlására és a régi kidobására ösztökélni) Mivel a Google tudatában volt és van annak, hányan használják a termékeit, felelőtlenül jár el, amikor bloated megoldásokkal elégíti ki a felhasználói igényeket.

Ezzel teljesen egyet lehet érteni, ez volna a követendő politika.

Viszont nem rég beszélgettem egy fejlesztővel aki egy német cégnél fejleszt, és azt mondta a szoftveresek olyan pazarlóan bánnak az erőforrásokkal, hogy az már neki is fáj. Minden vacakra külön virtuális gép, és abban fut valami.

Azt mondta olyan olcsó a hardver hogy tesznek rá. Bár ez egy belső használatú szoftver, a cég magának csinálja.

Így igaz.

Az a tény pedig, hogy tesznek rá, felelőtlenség és nemtörődömség. Az pedig, ha egy vállalat szándékos költségcsökkentés miatt pazaroltat erőforrást a szoftverének használóival, egyenlő a vállalati arroganciával. Nagyjából ugyanaz, mint amikor az aranybánya ciánt enged a folyóba. Csak kevésbé észrevehető, ugyanis az állatok elsőként nem a közvetlen közelünkben pusztulnak el, hanem az energiapazarlás miatt felolvadó sarkvidékeken.

Jó menedzsment politikával viszont ez nem fordulna elő, ha legalább olyan szabályozást kapnának a szoftveróriások, mint egyes kézzel fogható termékek gyártói, például a háztartási gépek energiaosztályozása, vagy az autók károsanyag-kibocsájtása. Bár utóbbit is rendre elcsalják, de így is több, mint a semmi.

A cég számára egyértelműen az a hatékonyabb üzletileg, ha minél kevesebb anyagi erőforrás ráfordításával csinálják meg az alkalmazást. Idáig gond egy szál se, egészséges kapitalizmusról beszélünk. Onnantól viszont már nem nevezhető sem egészséges, sem tisztességes üzletnek, hogy a nagy üzletieskedés (költségeken való spúrkodás) közepette átbillen a mérleg arra az oldalra, hogy a társadalom nagyságrendekkel magasabb árat fizet járulékosan, mint amennyit a cég valaha is megspórolt.

Szóval, mondjuk a YouTube fejlesztőbrigád spórol százezer dollárt azon, hogy JavaScript-ben írja meg a felületet, a "minden platformon tökéletesen fut kivéve a nem google által írt böngészőkben, de ezt most hagyjuk" menedzseri idealizmussal alátámasztva. A YouTube-on havonta 3,25 milliárd órányi videót néznek meg. Ha minden egyes eszköz csak 1 Wattal fogyaszt többet, az a felhasználóközönségnek 3,25 gigawattórányi energiaköltséget jelent pluszban, ami mai (átlag amerikai 12 cent/kWh) áron számolva 3250000000/1000*12/100 = 390 ezer dollár havonta (több, mint egymilliárd forint). Ennyit pazaroltat el a teljes felhasználóközönséggel a Google, cserébe megmarad a százezer dollárja. Azt pedig még nem taglaltuk, hogy a videók hány százaléka ment le olyan eszközön, ahol nem +1 Watt a különbség, például PC-ken, ahol az m.youtube.com se jön be és natív alkalmazás sincs. Azt sem taglaltuk, micsoda környezetszennyezéssel jár eme energiamennyiség megtermelése. Utóbbit nehéz pénzben számszerűsíteni, bár a CO2-kvótákból talán át lehetne számolni.

Az egységsugarú felhasználónak persze nem tűnik fel, mert mindenki csak egy kicsivel fizet többet, ha meg valaki panaszkodik, hogy sok a villanyszámla a jútyúb miatt, rögtön rendre utasítják és vetetnek vele új™ gépet, ami már valamivel kevesebbet fogyaszt.

A logika tehát egyszerű: mindenki egy kicsit, de összességében mindenki sokat fizet a cégek önző hozzáállásáért. Megemlíthetném a freon gázzal töltött dezodorok esetét, amikor egy dezodoros palack kifújásából nem lesz ózonlyuk, de ha egy egész kontinens fújja, abból igen. Ja és persze, többletköltség lenne más gázzal tölteni. Egészen addig az is volt, míg be nem tiltották, aztán valahogy jó lett a PB gáz is. Megemlíthetném a műanyagpalackokban árult ásványvizet. Magyarországon siralmas a helyzet ezügyben, és természetesen többletköltséget™ jelent vízpalackozóéknak egy értelmes visszaváltási rendszer fenntartása. Ellenben, Németországban, ahol a haladóbb törvényi szabályozásoknak köszönhetően már nincs más választásuk, mégis teljesen jól elvannak vízpalackozóék a visszaváltós rendszerrel. Ezekben az esetekben a cégeknek csak egy kicsivel kellene többet beleinvesztálni a témába, de elmulasztják, mert úgy költséghatékony™.

Mivel a kapitalizmus sem egy tökéletes rendszer, vannak olyan szituációk, melyeket nem tud önmagában megoldani. Sőt van, hogy nem nem is fog, vagy még rá is tesz egy lapáttal. Itt kell beiktatni szigorú törvényi szabályozásokat. Amint ez megvan, és kötelező érvényű, hidd el, hogy a cégek már azzal fogják magukat marketingezni, hogy P3-ason is fut a cuccuk. Ahogy ma a mosógépeket A++++++ jelölgetik, meg szinte már milliWattra kicentizik a fogysztásukat.

Kedves usereknek minden lehetősége megvan, hogy ha ez nekik fontos, akkor válasszanak másik streaming szolgáltatást. De egyelőre ott tart a tudomány, hogy az userek többnyire nem a wattokért fizetnek, hanem a featurekért.

Egyébként meg ne zavarjon, hogy a video dekóder nem JS-ben van írva.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szokásos blőd, ignoráns idealista-kapitalista mindentpénzbenmérünk maszlag. Köszönjük, Mérnök Úr.

Sajnos nem értetted meg a lényeget.

Kedves usereknek minden lehetősége megvan, hogy ha ez nekik fontos, akkor válasszanak másik streaming szolgáltatást.

Tény és való. Ettől viszont még a Google ugyanúgy arrogáns hozzáállású és energiát pazaroltat azokkal, akik őket választották.

Egyébként meg ne zavarjon, hogy a video dekóder nem JS-ben van írva.

Nem zavar. Ahogy elnézem Mérnök Uraságod sem zavarja, hogy alapvetően a kezelőfelületről volt szó. Megjegyzem, a nemJS™ videólejátszás is többet zabál egy Chrome-ban, mint egy VLC-ben vagy egy MPC-HC-ben.

Hivatalos, egyszerű, assembly-ben kioptimalizált natív alkalmazást, mely minden platformmal kompatíbilis, amivel a Chrome és rendelkezik a YouTube vagy a Maps egyéb járulékos funkcióival (komment lehetőség, lájkolgatás, műsorajánló, GPS jel fogadása, Panoramio helyek betöltése stb.). Persze YouTube és Maps két külön alkalmazás.

( manfreed (nem ellenőrzött) | 2017. 12. 16., szo – 21:43 )

Kár, hogy a typescript és coffeescript és társai össze vannak vonva, holott tök más a két nyelv, és a kedvelés egyáltalán nem azon múlik, hogy js-re fordul-e vagy sem.

Az en tavalyi javaslatom resze volt. Keves a hely, kellett a kompromisszum, nem az egyetlen az idei ket programnyelv listan (sem). Pl. Scala is jobb helyen lenne elkulonitve a tobb ifunkcionalis nyelvtol (tavaly ugyanannak a javaslatnak a kereten belul azt kertem, ne vonjuk oket ossze), megis ugy gondolom, jo lepes volt osszevonni a kettot, mivel igy bekerulhetett a Kotlin.

( uid_17784 | 2017. 12. 16., szo – 23:04 )

Ha a C# hianyzik a listabol,
akkor a Python meg feleslegesen van itt.

A Pyhthon nem szkriptnyelv; a kategoria elnevezese a hibas. Ugy kellett volna kiirni, hogy szkriptelesre hasznalt kedvenc nyelv.

Pont az a jó benne, hogy bár szkriptnyelv(nek tartják), mégis logikusan felépített, mint egy hagyományos programnyelv. Nem egy összegányolt valami mint pl a BASH. Az R-t is rengeteget használom, de az eléggé specializált, és könnyű benne nagyon elbarmolni a kódot. És persze list comprehension forevör <3 :)

C# inkabb a forditott nyelvek listajaba valo. Nem tudom, azert mondod, mert ma mar van C# REPL? (van?) Mert van ott meg olyan kategoria, amirol ugyanez elmondhato.

Valoban rosz a kategoria elnevezese. Egy statikusan tipusos es egy masik, dinamikusan (illetve gradualisan, opcionalisan, stb.) tipusos programmozasi nyelvek listaival kene helyettesiteni.

( asch v | 2017. 12. 23., szo – 20:36 )

Én szkriptes feladatra is Java programot írok, de ha nem, akkor Python ezek közül.

PS, C# = Hogyan végezzünk el egy feladatot 10x annyi memória és 3x annyi CPU elpocsékolásával.

Míg élek, nem fogom megérteni, hogy pont az ilyen produktív, látszólag igencsak motivált mérnök urak, amilyen te is vagy, miért ilyen elbaszott, bloated, divatmegoldásokat használnak, értelmes programozási nyelv helyett.

Ennyire türelmetlenek vagytok csak a menedzser ennyire spúr a fejlesztési idővel?

Ha a nevéből esetleg nem lenne egyértelmű, a VBScript egy scriptnyelv, nem programozási nyelv. Értelmes programozási nyelv számomra azt jelenti, hogy natív gépi kódra fordul, mindenféle bájtkód-mágia nélkül. Tehát, C, C++, Visual Basic (és még egyszer: nem Visual Basic Script).

A probléma az, amikor egy relatíve komplex programozási projektet scriptnyelven oldanak meg.

Döntsd már el, hogy a nyelv a lényeg, vagy a fejlesztési, fordítási, debugolási idő is számít!!

Ha már ilyen kitűnően tudsz kommentre linkelni, ajánlom, hogy olvasd is el magát a kommentet, különös tetkintettel annak zárójelben kifejtett tisztázására, mivel jelen (értelmetlen) hozzászólásodban előadott fogalmatlanságoddal tanúsítod, hogy te is az említett címzettek közé tartozol.

Te írtad a PowerShellre és a Pythonra, hogy nem alkalmas scriptelésre, mivel bloatware. Ellenben a VBScript alkalmas rá.

A probléma az, amikor egy relatíve komplex programozási projektet scriptnyelven oldanak meg.

Itt végig scriptelésről volt szó, Te kevered ide a "relatíve komplex programozási projektet".

Ha már ilyen kitűnően tudsz kommentre linkelni, ajánlom, hogy olvasd is el magát a kommentet

Ezt tudom ajánlani számodra is, különös tekintettel amire válaszolsz és amit válaszolsz, azokat is!

Te írtad a PowerShellre és a Pythonra, hogy nem alkalmas scriptelésre, mivel bloatware.

Nem írtam, hogy nem alkalmas a scriptelésre. Azt írtam, hogy bloatware.
http://a.te.ervelesi.hibad.hu/szalmabab

Itt végig scriptelésről volt szó, Te kevered ide a "relatíve komplex programozási projektet".

Nos, elsősorban Saxus Mérnök Úr keverte ide a C#-ját. Nem láttalak nyálat verni ezügyben, a kommentje alatt. Amiről én beszéltem (programnyelvek vs scriptnyelvek, programozási projektek vs scriptelés), az nem belekeverés volt, hanem kis magyarázat, hogy disztingválni tudj, mert elsőre sem értetted.

Nem írtam, hogy nem alkalmas a scriptelésre. Azt írtam, hogy bloatware.

Nem írtad, de amire, amit válaszoltál, abból egyenesen következik.

Akkor menjünk végig egy szálon:

asch: Én szkriptes feladatra is Java programot írok, de ha nem, akkor Python ezek közül.

saxus: Dettó, en a PowerShellel vagyok igy: Ire rajonnek, hogy hogy kellene, megírom C#-ban, RoslynPadban. Persze, ebben benne van az is, hogy PS-ben jóval kisebb gyakorlatom van.

hajbazer: PS, C# = Hogyan végezzünk el egy feladatot 10x annyi memória és 3x annyi CPU elpocsékolásával.
Míg élek, nem fogom megérteni, hogy pont az ilyen produktív, látszólag igencsak motivált mérnök urak, amilyen te is vagy, miért ilyen elbaszott, bloated, divatmegoldásokat használnak, értelmes programozási nyelv helyett.

Szóval vagy azt gondolod, hogy nem alkalmasak scriptelésre, mert bloat-ok vagy egy hatalmas troll vagy, mert nem arra válaszolsz, amit írnak. Van még harmadik lehetőség is, de az már személyeskedés lenne.

Nem láttalak nyálat verni ezügyben, a kommentje alatt.

Persze, hogy nem, mivel nekem semmi bajom sincs azzal, ha valaki Java-ban, C#-ban, ...-ben ír scripteket.

Nem írtad, de amire, amit válaszoltál, abból egyenesen következik.

http://a.te.ervelesi.hibad.hu/hamis-okozat

Nem az következik belőle, hogy nem alklamas a scriptelésre, hanem maximum az, hogy nem érdemes használni. Persze még ez sem, hiszen a fősodratú mérnök urak szépen megindokolják nekünk, hogy bizony megéri (amúgy nem, csak a cégnek, és ha a cégen kívül is használják, akkor a felhasználók fizetik meg a cég által megspórolt járulékos költségeket, villanyszámlában, környezetkárosításban, gépkidobásban).

Nekem sem volt bajom azzal, hogy mások idekevertek nem scriptnyelveket is (Java, C#), te vertél nekem nyálat, hogy döntsem el, hogy értelmes programozási nyelvek, vagy VBScript.

Nekem továbbra sincs bajom azzal, ha mások idekevernek programozási nyelveket. Azzal van, ha valaki scriptnyelven (vagy bloat programozási nyelven, pl. Java, C#) valósít meg programozási feladatokat. Erről írtam.

hiszen a fősodratú mérnök urak szépen megindokolják nekünk, hogy bizony megéri

Ugyanezt az érvelést láttuk Tőled is: Nem lenne fenntarthatóbb. A fejlesztési, fordítási, debugolási idő végső soron többet elvinne a teljesítménykülönbséghez képest.

Épp ez volt a bajom az általad írtakkal, ha Te használsz bloat megoldást scriptelésre (VBScript), az rendben van, mert megtérül a fejlesztési, fordítási, debuggolási időben; de ha más használ, akkor meg kb. vége a világnak.

Tovább már nem próbálom elmagyarázni, hogy itt csak és kizárólag scriptelésről volt szó és rajtad kívül senki sem írt "rendes" programozásról.

Leírtam az idézett mondat alá, hogy milyen esetben igaz.

A fősodratú mérnök urak olyan projektek scriptnyelvben való fejlesztését indokolják meg, melyek egyébként komplex programozási projektek, csak voltak olyan idealisták a mérnök urak, hogy inkább scriptnyelven írják meg, mert egyszerűbb elkezdeni és a haladás illúziója is jobban megvan. Cserébe, mindenki, aki használni fogja, rengeteg erőforrást elpazarol. Ha sokan használják, akkor sokszorta annyi erőforrást pazarolnak el mérnök úréknak köszönhetően, mint amennyit mérnök uréknak be kellett volna fektetni, hogy megírják normálisan (programnyelven).

Az idézett mondat a jól scriptelhető, egyszerű feladatokra, illetve egyedi megoldásokra vonatkozott.

Most melyik Visual Basic-ról beszélsz? Arról a VB6-ról, ami egy interpretált nyelv és gyakorlatilag nem különbözik semelyik másik "bloat" scriptnyelvtől, vagy a VB.NET-ről, ami meg gyakorlatilag nem különbözik semmiben a C#-től működését tekintve? (Ugyanúgy IL kódra fordul, az ugyanúgy natív kódként fut, stb.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Only a Deranged Fool would use VB.Net for a task this important. Clearly the only Sane Choice is ... no, I'm not going to calm down. Get your hands off me! I don't care how many side effects that filthy solution has; I'm not going to use a functional alternative.

Dysfunctional languages, that's the way to go.

http://thedailywtf.com/Comments/Spaced-Out.aspx
--
-What we need is a language with a compile-time garbage collector!
-I thought VB already collects all the garbage programming-time!
--
One thing to consider is that without VB, idiots would learn another language. At least with VB's creepy looking source, you can tell at a glance that the code is slow and buggy at best or causes severe head trauma at worst -- and you don't actually have to read it.
VB is a necessary evil. Just never hire or work with a VB-only programmer.

--

Come on folks! It's written in Visual BASIC

B EGINNERS
A ll purpose
S ymbolic
I nstruction
C ode

This is a language created for beginners, did you really expect anything other than stupid code.

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

Most melyik Visual Basic-ról beszélsz?

Természetesen a natív EXE-re forduló Visual Basic-ről.

Arról a VB6-ról, ami egy interpretált nyelv és gyakorlatilag nem különbözik semelyik másik "bloat" scriptnyelvtől

Saxus Mérnök Úr at his finest. Remélem, ez kikerül HUPmeme-re, mint az összes többi baromságod. A Visual Basic 5-től fölfele tud natívra fordulni, tehát nem scriptnyelv. Előtte bájtkódra fordult. Akkor sem volt scriptnyelv. Meg egyébként bloat sem, csak max. nem a leghatékonyabb. Ettől függetlenül, én nem láttam még lassú VB programot. Lassú C#-ot, meg Java-t már igen. Sajnos szinte csak olyat.

Elég, ha összehasonlítasz egy azonos feature-ökkel rendelkező, natív torrent klienst és egy Java-ban írtat. A CPU és a memóriahasználat a többszöröse lesz.

Saxus Mérnök Úr biztos a világ legkomolyabb programjainak forráskódját pötyögi .NET-ben a melóhelyén, ugyanakkor az, hogy egy program mennyire bloat, nem minden esetben függ össze azzal, hogy mennyire komplex. Sőt, legtöbbször attól függ, hogy a lusta fejlesztők milyen bloated keretrendszer bloated megoldását kényelmeskedték ki magukból.

MUHAHAHAHAHAHAAAAAAAA. C, mint értelmes programozási nyelv. MUHAHAHAHAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. Ha értelmes programozási nyelv lenne, rendesen definiálva lenne a működése és nem írnának csillió szabványt arra, hogy hogyan ne kúrj el egy triviális programot se benne. Mert sajnos az a helyzet, hogy a te értelmes nyelveiddel egy triviális feladatot sem lehet megoldani komoly elkúrás nélkül. Aztán még ott van az, hogy hiányzik az a "bloat", amitől használható lesz a nyelv és ne kelljen a spanyol viaszt újra feltalálni. (Amit jellemzően mindenki ismételten el szokott kúrni.)

A megszakértett memória és CPU felhasználást meg kommentelni sem érdemes, millió helyen megcáfolták már mérésekkel és millió helyen megírták már, hogy mire kell az a "bloat".

Mondjuk, akinek fingja nincs a szakmáról és az afelé támasztott (vevői) igényekről, az lehet ne okoskodjon bele.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A C nyelvről volt szó, nem arról, hogy egy C nyelven írt kódból mit csinál a GCC egy adott architektúrán.

Például meg tudnád mondani, hogy minek _KELL_ történnie egy nullával osztásnál? Vagy, hogy minek _kell_ lennie ennek az eredménye? 

int C = 0;
if (C == C++) {

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

És miért is? Ezt írja egy szabvány a side-effectes kifejezések kiértékeléséről:
"6.5 Expressions
1 An expression is a sequence of operators and operands that specifies computation of a
value, or that designates an object or a function, or that generates side effects, or that
performs a combination thereof. The value computations of the operands of an operator
are sequenced before the value computation of the result of the operator.
2 If a side effect on a scalar object is unsequenced relative to either a different side effect
on the same scalar object or a value computation using the value of the same scalar
object, the behavior is undefined. If there are multiple allowable orderings of the
subexpressions of an expression, the behavior is undefined if such an unsequenced side
effect occurs in any of the orderings."
És az == kiértékeléséről nincs megadva, hogy milyen sorrendet kell követnie, viszont a post-increment operatorról elő van írva, hogy:

"The value computation of the result is sequenced before the side effect of updating the stored value of the operand."
Azaz előbb kell kiszámolni a kifejezés értékét, és csak utána (valamikor) kell frissíteni az operandus értékét.
Azaz előfordulhat (és teljesen szabályos) a következő kiértékelés:
1. Kiszámoljuk C+1 értékét (C++ kiértékelésekor)
2. Összehasonlítjük C értékével
3. Mivel nem egyeznek, az egyenlőségvizsgálat értéke 0 lesz.
4. Ezután C-t megnöveljük 1-gyel.

Mint ahogy teljesen szabályos a következő kiértékelés is:
1. Kiszámoljuk C+1 értékét (C++ kiértékelésekor)
2. Megnöveljük C-t 1-gyel
2. Összehasonlítjük az 1-es pontban kiszámolt értéket C értékével
3. Mivel egyeznek, az egyenlőségvizsgálat értéke 1 lesz.

Ugyanígy, a szabvány leírja, hogy például az i = 1 + i++ kifejezés kiértékelése undefined.

Azt már csak futólag említem, hogy C-ben az egyenlőségvizsgálatok értéke sosem true és false, hanem 1 és 0.
"The == (equal to) and != (not equal to) operators are analogous to the relational
operators except for their lower precedence. 108) Each of the operators yields 1 if the
specified relation is true and 0 if it is false. The result has type int"

Elolvastad te egyáltalán a kommentet? Erre _SEMMI_ garancia nincs, hogy azt neked valóban true-ként fogja értékelni. Ugyanígy, azért, mert x86-on hibát kapsz 0-val osztásra, még semmi garancia nincs arra, hogy más platformon is ezt fogsz kapni.

Futottam már bele x86/x86_64 váltás környékén platformbeli különbségekbe bőven és valahogy mindig az lett a vége, hogy a C-ben írt komponenstől szivárog a szar.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kit érdekel a gcc meg a clang? És az Intel compilere? És a MS compilere? És a többi más compiler?
értsd meg: a fenti kifejezés értéke a nyelv specifikációja szerint nem definiált, azaz az értéke implementációtól függ, nem definiált, hogy egy fordítónak mire KELL fordítania ezt. Fordítónként más lehet a viselkedés.

> amire a bash nem igazán alkalmas, de legalább nem is lehet normálisan debuggolni

Először megtanulja a jóember a nyelvet rendesen. (Itt elvérzik a többség.) Utána megtanulja a lehetőségeket kihasználni. Gondolom te is leragadtál a set -v / set -x szintjén, pedig van tovább. És végül keresgél. Hint:
DEBUG-trap, PS4, bashdb.

http://bashdb.sourceforge.net/bashdb.html

http://wiki.bash-hackers.org/scripting/debuggingtips

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( NevemTeve | 2018. 01. 16., k – 09:57 )

A kedvencem a PHP. Persze utálom, mert sz_r.

( hnsz2002 v | 2018. 01. 17., sze – 10:58 )

Ez attól függ. Feladathoz eszközt.
Ha csak ilyen unix parancsok csokorba szedése, esetleg egy-két feltétel, vagy más egyszerű dolog, akkor bash.
Ha pl. mysql babrálás, akár csak egyetlen sor update-je, akkor php.
Ha valami input vagy file parse-olás regex-szel, szűrés, tömbök kreálása, rendezése, ciklussal végigjárása, akkor perl, esetleg awk.
--
"Sose a gép a hülye."