HOVD 2023 - Kedvenc szkriptpnyelv

HUP

  Itt a HUP Olvasók Választása Díj 2023 szavazás. Az idei HOVD immár a tizennyolcadik a sorban.

  A HOVD 2023-on minden HUP olvasó szavazhat. A HOVD 2023 választás ideje - két hónap - alatt a 20 kategóriában állított jelöltekre lehet majd szavazni.

  Szavazz az alábbi kategóriákban! Kedvenc ...

javascript
6% (60 szavazat)
lua
1% (15 szavazat)
*nix shell (bash, csh stb.)
24% (255 szavazat)
perl
5% (49 szavazat)
php
13% (135 szavazat)
powershell
7% (70 szavazat)
python
38% (408 szavazat)
r
1% (12 szavazat)
ruby
2% (17 szavazat)
typescript, coffeescript (javascript jellegű nyelvek)
5% (53 szavazat)
Összes szavazat: 1074

( zslaszlo v | 2023. 05. 18., cs – 17:33 )

Vicces. Ahhoz képest, hogy mennyit fikázzák a pythont (lassú szar, csak a C az igazi, python pistike stb) azért sokan használjuk.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

( carlcolt | 2023. 05. 18., cs – 17:42 )

Szerkesztve: 2023. 05. 18., cs – 17:44

Sose szerettem a JavaScriptet, de kezd zavarni az a reteg, aki azt hiszi, hogy kulonb, mert o TypeScriptezik. A C-sek se neztek le az Assmebly-seket (csak a Rustosok a C-seket, holott negyedannyira se ert a tobbseguk semmihez se, de ez most mindegy). De a TypeScripteseknel kialakult egy szamomra erthetetlen szintu es eddig ritkan latott merteku felsobbrendusegi tudat. Megis mi annyival jobb abban? Az, hogy minden fel evben maskepp hype-olt build scriptekre vagy utalva, es meg az npm is sir, hogy milyen vulnerability-ket talalt a dependency helledben? A TypeScript nekem ranezesre is a meglevo tipusproblemakat megemelte a harmadaval, vegeredmenykent meg tobb helyen kell figyelni, hogy hol romolhat el a tipus. Vegeredmenykent ugyanugy megszivhatod a null, undefined, 0, 0.0 es '' kozti furcsasagokat, holott arra keszitettek, hogy ezt a problemat megoldja, csak mostmar ezt is kulon erteni kell.

De meg a nyelvet el is fogadom. Az embertipus zavar, aki "nem nyul a legacy JavaScripthez mert nem TypeScript" es kop egyet. Sot, ha kozli, hogy frontendes, visszakerdezel, hogy JavaScriptezik-e, lenezoen es sertodotten reagal, hogy o TypeScriptezik, nem JavaScriptezik.

Nem, emiatt nem szavaztam at JavaScriptre, annyira melyre nem sullyedek.

De zavar, hogy par eve a JavaScriptesek tobben voltak, most meg a "JavaScript-szeruek" (ismerve a vilagot tobbseguk TypeScriptes) vannak tobben itt is. Mi fertozte meg ennyire oket?

Alapvetően C++ programozóként nekem scriptnyelvek közül Javascript a kedvencem és arra is szavaztam.

Ha az ember ismeri az idióta típuskonverzióit, totál kézre eső scriptnyelv apró kis feladatokra, eldobható kódokra és persze a böngészőben GUI bizgetésére.

Az új template literaljait is nagyon kényelmes használni, az async / await megoldása pedig kifejezetten zseniális szerintem.

Haaaaaat, ezt legalabb meg tudom erteni. :)

Felteve hogy tenyleg vanilla JS-rol beszelunk es egy (kb.) package management nelkuli nodejs-rol. A legnagyobb kupleraj a webes build scriptek korul van, azt ezzel vegulis elkerulod. Igy valahol megertem, ha "nincs ezzel problemad".

De azert a python aiolofaszoknak azert adj egy eselyt. :) Ott is szepen meg van oldva az async-await.

C++ backendekhez írtam HTML + minimál VanillaJS frontendet. A legnagyobb szívást az okozza, hogy a böngészők becache-elik a JS fájlokat.

Erre megoldás, ha folyamatosan átnevezzük a JS fájlokat és átírjuk a hivatkozásokat mindenhol. Ez agyrém. Úgyhogy elkezdtem a Vite nevű nodejs-es dolgot használni, ami megoldja ezt és még egy sor kényelmi funkciót is ad. Persze lehetne elvemberkedni, primadonnáskodni, de nekem fontosabb, hogy a munka haladjon és ne felesleges dolgokkal töltsem az időmet.

Szóval lehet ezeket a buildereket, dev szervereket használni.

2-3 éve még utálattal néztem a Javascriptre a régi emlékek miatt, aztán mióta használom a mai modern verzióját, eszembe sem jut Perl, PHP, amiket régen egész komolyan használtam.

Viszont a framework-ök használatának én sem látom értelmét, a mai JS-ben minden benne van és totál hordozható. Ami meg nincs benne, azt meg lehet írni és vannak egészen jó minimális méretű libraryk, kódgyűjtemények is.

TS pedig szerintem kimondottan elvadult ötlet. Komolyabb dolgok fejlesztéséhez mindenképp rendes típusos nyelvet nyelvet javasolnék mindenkinek. Ez nálam speciel C++, mert ezt szeretem.

Erre megoldás, ha folyamatosan átnevezzük a JS fájlokat és átírjuk a hivatkozásokat mindenhol. Ez agyrém.

Az. És felesleges. Ahogy a nodejs is. Nem a fájlnevet kell cserélgetni, hanem át kell a referenciában adni neki egy pszeudoargumentumot, ami ugyan nem csinál semmit, de a cache-reload-ot force-olni fogja:

<script src="/path/to/script.js?RANDOM_ALPHANUMERIC_SEQUENCE"></script>

és meg van oldva a cache probléma kb. egyetlen sornyi szerveroldali kódból.

Oldschool Computer - http://oscomp.hu

Ja, innen indultam én is, bár nálam a szerver semmi HTML-t nem generál csak JSON-okat és a JS API-t saját maga alapján.

Ehhez a RANDOM_ALPHANUMERIC_SEQUENCE-hez képest Vite HMR-je (Hot Module Reload) folyamatosan figyeli, milyen JS modulok vagy HTML-ek változtak és újratölteti a browserrel, amit kell. Még F5-öt sem kell nyomkodni. Borzasztó kényelmes használni fejlesztés közben.

Buildeléskor pedig a JS fájlok digest-jét teszi a fájlnévbe és az összes hivatkozást eszerint cseréli. Tehát az alkalmazásod mindig konzisztens marad éles környezetben is. Ráadásul a build az összes felesleges dolgot kiszórja a forrásból és mivel én csak azokat a modulokat töltöm be, amik éppen kellenek, piszok gyors az eredmény pl. Reacthoz, Angularhoz vagy más őskövület frameworkökhöz hasonlítva.

Ha annyira F5 nélkül akarod újrahúzni a változott JS-eket: egy ciklikus AJAX kérés megvan pár sorból és a szerver visszaadhatja, hogy mit kell újrahúzni, amit megint csak végrehajthatsz pár sorból. A legtöbb esetben a framework-ök által megoldott problémákat vanilla JS-ben is meg lehet oldani és az esetek 4/5-ében igazából gyorsabban és egyszerűbben. Arról nem is beszélve, hogy a JS framework-ök több problémát generálnak, mint amit megoldanak.
Ha a fájlnév mindig ugyanaz, akkor is konzisztens az alkalmazás; nem a fájlnév ami a cache-beni bentragadást okozza, hanem az URL, az pedig változhat a fájlnév cseréje nélkül is, ld. fent.

Oldschool Computer - http://oscomp.hu

Vite nem framework, csak egy nagyon jól összerakott dev szerver és build rendszer. Persze, én is össze tudnék rakni hasonlót, ahogy írhatnék rendező algoritmust, hashmap-et, kódszerkesztőt vagy akár oprendszert is, de ha már van használható, inkább használom azt, ami van. Mondom, nekem az eredmény a lényeg és a felhasználóknak is. Kinőttem már ebből, hogy mindent magam írjak meg. Annyi hogy frameworkökbe nem akarom magam belekényszeríteni, hanem inkább meglévő cuccokat használok, amiket könnyen le tudok cserélni, ha akarok. Főleg, hogy a Javascript frameworkök fölött már eljárt az idő, semmi hasznuk nincsen.

Javascript dev-szerverből pedig kismillió van. Többet is kipróbáltam, nekem Vite nagyon bejött, de ez tényleg egy lecserélhető segédeszköz, mint pl egy editor.

Az is kikerülhető, ha a random string mondjuk a szülő könyvtár neve, ami persze nem létezik; egy rewrite rule átirányítja a megfelelő fájlra.

A CDN meg csak egy tárhely, hóttmindegy, hogy honnan jön a JS, a kérdés, hogy mi cache-eli: ha a browser -> elég a random pszeudoargument a fájlhoz, ha meg valami menetközbeni szar csinálja, azt is át lehet verni azzal, ha az elérési utat másnak hiszi. Ismét egy-egy sor, framework nélkül.

Oldschool Computer - http://oscomp.hu

Mar kezdtem azt hinni, hogy csak en szeretem pont igy hasznalni a JavaScriptet - kivetel a ?version a forrasfajlhoz ami a TCH altal emlitett modon kiuti a cache-t egy sorral - en azt hasznalom, igy nem kell nekem se arra lib meg csomagkezelo.

Ha igy gondolkodna mindenki a JS-rol, mint pl. te, vagy en, nem utalnam a JS-t.

Az egyetlen furcsasag, hogy pont az async-await tetszik neked annyira. Szerintem a C++-os std::thread es tarsai sokkal elegansabb, igaz, kicsit masra valo. Csak pont furcsa volt nekem, hogy ezt C++-oskent emelted ki.

Amugy evente ket olyan dologba futok bele, amit valahogy cli JS-ben lehet a leggyorsabban osszedobni pont. Ritka, de lattam ilyet. Ergo tenyleg furcsa, de valahol ertem, ha jo scriptnyelvnek tartja valaki.

De amit eszrevettem: a C++-osok a tobbi nyelven tok olvashato kodot irnak. :)

az async / await megoldása pedig kifejezetten zseniális szerintem.

Biztosan nagyon jó, de amikor én először láttam a goroutinokat meg a channeleket a Go-ban, akkor - ahogy szokták mondani "az angyalok énekelni kezdtek, a felhők szétváltak, egészen mennyei élmény volt".

Más kérdés, hogy én nem rendszerprogramozó vagyok, csak apróbb alkalmazásokat fejlesztek, a webet is messziről elkerülöm, biztosan ez sem jó mindenre.

https://www.youtube.com/watch?v=LvgVSSpwND8

( Raynes v | 2023. 05. 18., cs – 17:55 )

Ezeknek szinte mindegyikét használom, a JS/JS-alapúak és a Powershit, Ruby kivételével. A Lua-hoz húzna legközelebb a szívem, mert annak nagyon egyszerű, Basic-szerű szintaxisa van, de a legtöbbet shell scriptet írok (abból is szigorúbb POSIX-kompatibilitásra törekszem mostanság), illetve elvétve megy Perl és Python is, az előbbi szöveges formátumok feldolgozására (főleg szótárfájlok), az utóbbi meg matekos témákban verhetetlen (sok lib van hozzá, bár néha bc-alapú calc-ot is használok, illetve próbáltam egy időben GNU Octave-ot is). Webszerveren a PHP-t preferálom viszont a Perl-lel szemben. Szóval attól függ mi kell, a szükség úgy hozza, hogy legtöbbször shellscript. Néha még awk-ot is beröffentek, de annak a szintaxisa nagyon awk-ward, még ha a C-jét is utánozza, nem szeretem.

Amúgy nem vagyok a scriptnyelvek barátja, inkább C.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( uid_6201 v | 2023. 05. 18., cs – 19:19 )

Se Julia, se Octave, se TCL ... szelektív a szkriptnyelv-skála.

Bármilyen ilyen szavazás szelektív, mert lehetne sorolni millió egy nyelvet, kérdés mennyi értelme van. Akár még olyanokat is lehetne, mint S-lang, vimscript, Emacs Lisp, Rexx, VBScript/Gambas, AutoHotKey, QuakeC, HolyC, Matlab, OpenSCAD CSG, stb.. Valakiknek biztos azok is kedvencek. A valóság az, hogy a kóderek és kódok 90+ százaléka kb. ugyanazt a 4-5 legelterjedtebb megoldást, nyelvet, libet, stb. használja egy adott témában, területen, platformon.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( bimlas | 2023. 05. 18., cs – 21:33 )

Ez a szavazás így kicsit sántít szerintem, mert nem egyértelmű, hogy CLI-ben utility-ként használt script írásához használt nyelvről van-e szó, vagy app fejlesztéséhez használt nyelvről, ami épp egy script nyelv.

Én pl. melóban TypeScript-et is használok, de ha klasszikus értelemben vett script-et kell írnom, akkor a shell-t veszem elő, összetettebb feladatokhoz meg Python-t.

( asch v | 2023. 05. 19., p – 09:19 )

Pythonra szavaztam, mert ezek közül még azt szeretem legjobban. De igazából egyáltalán nem szeretem.

Valójában már a szkripteket is Javában írom. Arra jöttem rá, hogy a szkript mint olyan egyszerűen nem valid mint elképzelés. Hasonlóan a nem szigorúan típusos nyelvek is mind tévúton vannak. Mire pontos szemantikát rendelsz ahhoz amit leírtál, és megvalósítanád a hibaágakat is, addigra egy rendes programnyelven is végzel a feladattal.

Szerintem a szkriptnyelveknek megvan a létjogosultsága, mikor változó tartalmat kell futtatni újraforgatás nélkül, úgy, hogy lehetőleg menet közben is bármikor fusson egy új változat. Meg ha valami nagyon egyszerűt, pár sorosat gyorsban kell összedobni, amire nem éri meg fordított nyelven nekiállni komplett alkalmazást fejleszteni. Abban viszont igazat adok, hogy manapság sokan túlerőltetik őket

Pythont én se szeretem. Bloat, lassú, szintaxisa nem tetszik. Csak az a baj, hogy ma már sok mindenhez megkerülhetetlen, főleg mert a legtöbb libet erre fejlesztik.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

változó tartalmat kell futtatni újraforgatás nélkül, úgy, hogy lehetőleg menet közben is bármikor fusson egy új változat

Ugye ilyenkor azert felmerul a kerdes, hogy biztos jol van-e megfogalmazva a problema, ha ilyet kell csinalni. :)

nem éri meg fordított nyelven nekiállni komplett alkalmazást fejleszteni

En ezt nem is ertem. Pythonban is lehet tobb tizezer soros alkalmazast fejleszteni, de C#-ban is osszedobok barmikor egy 10-20 soros kis scriptet. Sot, ha mar ilyenekrol beszelunk, a Python is "forditott nyelv", bytecode lesz belole.

Van, amit nem lehet máshogy megfogalmazni, mert nem lehet tudni előre, hogy mit akarnak benne futtatni, kell egyfajta rugalmasság a cél. A Pythonban egyetértünk, túltolják, komplett alkalmazásokat írnak benne, amire nem való, pl. ablakkezelő. Tudtommal a Python interpretált, de van valóban JIT fordításos változata is, PyPy, CPython, stb.. De ez a többi nyelvnél sem akadály, a Perl is már JIT-et alkalmaz, és a Lua-hoz is van luajit, ettől nem lesznek kevésbé szkriptnyelvek.

Nyilván C-ben, C#-ban is meg lehet írni bármit, de 10-20 soros szösszenetet, ami alig párszor kell futtatni, és nem kell alá a natív kód teljesítménye, megéri-e a külön fordítgatást. Működni működik, persze, már láttam webszervert is C-ben, C++-ban webkódot futni, natív fordított bináris generálta le a CGI HTML kódot. Vagány, kérdés megéri-e. Extrém esetben akár még el is megy, pl. függőségek csökkentése, nem kell az adott platformra interpretert feltenni, külön frissítgetni, gyorsabb kódfutás, stb..

Amire még jók a szkriptek: realtime felhasználás, pl. matek, számolások, írod be soronként az interpreterbe a műveleteket, köpi vissza az eredményt (dc, bc, calc, Octave, Julia, R, Python, stb.), semmit nem kell várni, nem kell fordítgatni, és sokkal hatékonyabbak, mint a GUI-s appok. Vagy pl. ha ragasztónyelvnek kell, pl. shell script, mikor már kész parancsokat, programokat futtatsz sorban, csak azok fölött kell egy még magasabb szintű automatizáció. Ilyenekre simán jók a szkriptnyelvek, csak a helyi értékükön kell használni őket. Sok programozó követi el azt a hibát, hogy használja mindenre ugyanazt az 1 megoldást, amit ismer, tanult, mert ha kalapácsa van, minden szögnek néz ki.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

⛵ vnagy-eu in /tmp/oobar via ☕ v17.0.6 on ☁️  eu-west-1 took 33s 
❯ cat Hello.java 
public class Hello {
    public static void main(String[] args) {
        System.out.println("Fordítgasson a halál");
    }
}

⛵ vnagy-eu in /tmp/oobar via ☕ v17.0.6 on ☁️  eu-west-1 
❯ java Hello.java
Fordítgasson a halál

⛵ vnagy-eu in /tmp/oobar via ☕ v17.0.6 on ☁️  eu-west-1 
❯ jshell
|  Welcome to JShell -- Version 17.0.6
|  For an introduction type: /help intro

jshell> System.out.println("Fordítgasson a halál itt is");
Fordítgasson a halál itt is

jshell> 

Tudtommal a Python interpretált

Manapsag eleg elmosodottak a hatarok, de Is Python interpreted, or compiled, or both? - Stack Overflow

ettől nem lesznek kevésbé szkriptnyelvek.

A millio dollaros kerdes, hogy mi szamit manapsag scriptnyelvnek. A JavaScript az? Jo, de akkor miert irnak benne tobb szazezer soros, elesben hasznalt appokat? A Python az? Jo, de akkor miert tudok belole .NET bytecode-ra forditani? Stb. Szerintem ez a felosztas mar csak hagyomanyorzesbol letezik – azert scriptnyelv a JS, mert regen az volt, kesz. :)

Működni működik, persze, már láttam webszervert is C-ben, C++-ban webkódot futni, natív fordított bináris generálta le a CGI HTML kódot. Vagány, kérdés megéri-e.

Meglepoen gyakran megeri. Nezd meg, itt mik a legjobb teljesitmenyuek: Round 21 results - TechEmpower Framework Benchmarks

C, Rust, Java. De ha csak a mainstreamebb frameworkoket nezzuk, 35 helyen van az ASP.NET, a szutykos Node.js meg a ketszaz-valahanyadikon.

( eff | 2023. 05. 19., p – 16:04 )

Attol fugg mire. File muveletekre shell script. Ha inkabb csak parse-olas/egyeb logikai mokolas kell, akkor python.