HOVD 2017 - Kedvenc szkriptnyelv

 ( trey | 2018. január 16., kedd - 9:55 )
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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

A clojure joval tobb ennel, egy rendes lisp java VM-re es arra, ami a C# alatt van, az csak egy plusz, hogy a clojurescript forditoval lehet JS-be is forditani.

My bad, nem neztem utana, bocsi.

Szimplan kaptam karbantartasra egyszer egy write only clojure kodot ami JS-re fordult. Ez volt a kiindulasi pont.

Akkor nem lehet, hogy te siman a munkadat utalod? :)

Azzal semmi gond nincs. Csak, amikor valami gyengén típusos scriptnyelv^Wszar is képbe kerül.

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

A vicc, hogy mindegyiket utalom en is, de egyiket se a gyengen tipusossaga miatt. (Illetve ez neha visszakovetkeztetheto picit vegulis)

Biztos, hogy a gyenge típusossággal van problémád, és nem a dinamikus típusossággal? A fenti listában van pár nem gyengén típusos nyelv is (pl. python, ruby).

Is. Pythonnal már a syntaxnál kezdődnek a problémák (jó, tudom), meg volt vele egy-két fura esetem. Mondjuk az is tény, hogy keveset használtam.

Ruby-hoz nem volt szerencsém.

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

R forevör :-)
--
Csaba

foreveR

;)

- waiter -

VBScript?

.bat (DOS batch) akkor mar, legyunk stilusosak :)

Komment benne:

GOTO EndComment1
This line is comment.
And so is this line.
And this one...
:EndComment1

+1 :)

Nade hé.. REM luxus? :P

Volt valami, hogy a REM utasítás feldolgozása több erőfeszítést igényelt az interpretertől, mint a kettősponté, ezért még egysoros komment esetében is a kettőspontos megoldás volt az "ajánlott." Szóval REM = bloat.

_______Peter
I am a stone. I do not move.

Szóval REM = bloat.

^^^ hajbazer like this!

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

+1

hajbazer likes this

hajbazer atveszi egy ilyen gepen is mobilon is nehany TCP csomaggal elintezheto kommunikaciohoz tobbgiga ramot zabalo bloatware szlengjet, mint a Facebook?

carlcolt reacted to this :O

Igen, mocskos kapitalista multi szlengje. Biztos megfertoztek az extraprofitjukkal.

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

Miért használsz ilyen bloat lassú megoldásokat, amikor C-ben megírhatnád a kódot, ami sokkal gyorsabb?

Mert arra használom, amire való. Egyszerűbb feladatok script-elésére, nem programozásra.

dehát sokkal fenntarthatóbb lenne, ha cben írnád, és kevesebb áramot enne :)

+1 :-)

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.

Ez üzlet. Mi a költséghatékonyabb? Memória/cpu/fogyasztás vagy a fejesztői órabér.

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.

Idézet:
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.

Idézet:
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.

+1. Illetve bátran lehet natív alkalmazást is használni (pl. ami a TV-ken fut)

Kliens oldalon mit használnál javascript helyett (maps és youtube megjelenítésre)?

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.

> assembly-ben kioptimalizált natív alkalmazást, mely minden platformmal kompatíbilis

I lol'd

:-) Tovább csavarva:
Állítsuk meg az esőerdők és a pólusok pusztulását/erózióját! Futtassunk kizárólag natív programokat!
(Időmilliomos Zöld Informatikus Frontja)

Mennyire natívat? Hiszen a CPU-ban is mikrokód van. Mit jelent a natív? :D

C, mert az az Isten nyelvezete!

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

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.

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

Miért is nem szkriptnyelv a python? És miért az a C#?
--
:wq

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.

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

Erre van valami kulonosebb okod? Vagy egyszeruen azt ismered?

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

Abban programozok főleg, és azt ismerem legjobban, abban vagyok a legproduktívabb. Nincs más okom rá.

Egyik nagyobb bloatware, mint a másik.

Ha már alátoltak 4 magot, meg 32 giga memóriát, nehogy már ne legyen kihasználva.

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.

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

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?

értelmes programozási nyelv helyett.
Pl. mint a VBScript? ;-)

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

Idézet:
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!

Idézet:
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

Idézet:
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.

Idézet:
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.

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

Hol? Ebben a topikban egy "fősodratú mérnök Úr" sem írt ilyet!

Nem vagy hajlandó megérteni. Rendben.

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

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

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

Idézet:
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.

Hát, ha valamiben nem írtak semmi komolyat, akkor nem csoda, hogy nem láttál belőle lassút.

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

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.

Oszt tán sorról-sorra ugyanazt implementálták le mindkét nyelven? :) Vagy egészen véletlen elképzelhető, hogy nem ugyanaz a feature settel rendelkezik?

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

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™

Sajnálom. Nem tudsz C-ben programozni. Fájdalmas lehet. Akár még csak beismerni is önmagadnak. Igyekszem átérezni.

Sajnos C-ben még az sem tud programozni, aki azt hiszi magáról, hogy tud. Vagy szerinted mire van a MISRA-C?

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

nem triviális? akkor gcc -S valami.c és megnézed mit csinál.
A C az isten nyelvezete.
C-ben a világegyetemet újra lehet írni.

--
GPLv3-as hozzászólás.

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™

true-nak.

É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"

a gcc és llvm is true-ra fog értékelni. A C a leglogikusabb nyelv az asm után.
Ahogy mondtam, gcc -S ha bizonytalan vagy valamibe.

--
GPLv3-as hozzászólás.

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.

wow, ez igen :D

TIL, köszönöm. Szerencsére nem vagyok C fejlesztő.

Ez sehol nincs leírva, hogy így kell működnie.

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

Egyszerű: mivel van az a bonyolultság, amire a bash nem igazán alkalmas, de legalább nem is lehet normálisan debuggolni. Ilyenkor mindenki python, c#, java, stb.
kódokat fog írni, egyszerűen, mert az átlátható, tesztelhető, és kb. 3-ad annyi idő alatt megvan.

> 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?

sub

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

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."