HOVD 2015 - Kedvenc szkriptnyelv

HUP

dart
0% (4 szavazat)
javascript
9% (83 szavazat)
lua
2% (14 szavazat)
*nix shell (bash, csh stb.)
27% (235 szavazat)
perl
9% (83 szavazat)
php
18% (160 szavazat)
powershell
3% (28 szavazat)
python
27% (239 szavazat)
ruby
3% (28 szavazat)
typescript
1% (8 szavazat)
Összes szavazat: 882

( DirtY_iCE | 2015. 12. 14., h – 15:49 )

ez ilyen attol fugg. ha valami olyasmi kell, amit meg lehet egyszeruen oldani meglevo programok hivogatasaval es pipe-okkal, akkol nyilvan shell script. ha valami komolyabb dolog kell, akkor ruby vagy lua.

I hate myself, because I'm not open-source.

( carlcolt | 2015. 12. 16., sze – 12:44 )

Nagy ev volt ez az idei: iden talalkoztam eletem elso olvashato mas altal irt perl kodkjaval.

( Tomito | 2015. 12. 31., cs – 12:54 )

esetleg guile // hogyhogy kimaradt ? :)
--
Avoid hangovers, Stay Drunk!

( sj | 2015. 12. 31., cs – 14:25 )

perl, php (hagyjuk mar ezt a 'nem nyelv' es mas hasonlo baromsagokat), bash, ... ill. ha a go is belefer a scriptnyelv koncepciojaba, akkor meg az is a listamon van (amibe beleasom idovel magam).

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

akkor olyan a php, mint a vindoze: bar vannak hulyesegei, megis sokan hasznaljak. Btw. en is olvastam azt a php fikazo oldalt, ahol a nyelv 'furcsasagait' taglaljak. Valahogy sikerult kikerulnom azokat a hibakat...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

en arra probalom hasznalni, amire alkalmas a php. Mert azert 1-2 dolgot meg lehet vele csinalni...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Ha egy nyelv/library intuitív, akkor nem kell mindig a doksit olvasgatni, ahányszor valami olyat akar a fejlesztő csinálni, amit eddig még nem csinált. Pl. ha az MP3AudioStream osztálynak van egy olyan metódusa, hogy toAACAudioStream, meg egy olyan, hogy toVorbisAudioStream, akkor joggal várom el, hogy ha nekem Flac kell, akkor a metódusnak toFLACAudioStream legyen a neve, ne pl. asFLACAudioStream vagy toFlac vagy toLosslessAudioStream(LosslessFormat.FLAC) vagy FLACAudioStream.fromMP3AudioStream(mp3AudioStream).
A PHP-ban szinte semmilyen nyoma nincs konzisztenciának, se nyelvi, se API szinten. Ezért fejben kell tartani szinte az egész PHP doksit, vagy legalábbis emlékezni, hogy adott függvény valamiben eltér a többitől, ezért meg kell nézni a doksit, hogy mi ez az eltérés. Illetve ha megvan a megfelelő teszt lefedettség, akkor lehet még trial and error módszert is alkalmazni, csak nehogy pont az az eset ne legyen lefedve, ahol a hiba van. Ami egy dinamikusan és gyengén típusos nyelvnél sokkal valószínűbb, mint egy statikusan típusosnál.

Aham, világosan. Úgy 2008-9 környékén futottunk bele abba a problémába, hogy a crc32 függvényt akartuk használni, ami teljesen jól ment a fejlesztői gépeken (XP, 32 bit), az első éles gépen és a tesztkörnyezetben (Linux, 32 bit, PAE-vel). Majd szervercsere után egyszer csak elkezdett az esetek 50%-ában elhalni.

Most már persze fel van tüntetve, hogy vigyázz, mert 64 biten long az int PHP-ül, 2009-ben nemigazán volt.

Vagy a másik emlékezetes szopásunk a pg_escape_string-gel volt, amikor egy serialize eredményét akartuk volna használni. Ott némi kódolvasgatás (mármint a PHP-nek a pgsql bővítményének a C-s kódjának olvasgatása) és a PQescapeString dokumentációjának elolvasása után kiderült, hogy igazából hiába van neki egy size_t length paramétere, szarik rá, ha egy \0 karakterrel találkozik. Mondanom sem kell, valamelyik zseniális PHP dev-nek volt egy olyan remek ötlete, hogy egy serializált osztályban valamit egy \0-al válasszon el, mert gondolom a kettőspont kimerítette az összes létező szeparálásra használható karakterkészletet. Ok, itt egy picit a libpq is ludas, de sorolhatnék még ilyen kisebb-nagyobb apróságot, amikor egyszerűbb megnézni, hogy mit csinál a program, mint a "jól, világosan megírt" dokumentációt böngészni.

Szóval igen, valahol a doksiban, kommentben, forráskódban elejtett félszavakban, fórumon, ezer éves IRC logban benne van a tudás. De attól még nem fogja segíteni a munkámat az, hogy a héber-angol||magyar szótárban kell túrni, hogy mi az isten az a T_PAAMAYIM_NEKUDOTAYIM, mert egy izraeli származású fejlesztő úgy döntött, hogy tök jó poén lesz a T_DOUBLE_COLON helyett, amit valószínűleg jóval többen megértenek* (ami egyébként benne van a kódban). Természetesen nem javítják, mert csak, neki így tetszik. Majd a paraszt kikeresi a doksiból, elvégre is nem a nyelv van a fejlesztőkért.

(* Ilyenkor egyébként hol vannak azok, akik amiatt sírnak, hogy egy kifejezetten .hu-ra fejlesztett szoftverben valaki meghagyja az eredeti magyar kifejezést a kódban?)

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

A pg_escape_string ok, de én most kifejezetten a type jugglingról beszéltem. Ezen szoktak a legtöbben fennakadni, pedig ez egy nagyon régi dolog a PHP-ben, amivel illik tisztában lennie annak, aki ezzel a nyelvvel dolgozik. Aki meg csak úgy leül PHP fejleszteni a nyelv ismerete nélkül, az magára vessen. De szerintem ez más nyelvekre is igaz.

A T_PAAMAYIM_NEKUDOTAYIM-en szerintem nem is fognak változtatni, mert az úgy vicces, ahogy van :)

Na és te pontosan tudod az összes type jugglingos szabályt a PHP-ben? Néha próbaképp beraktunk egy-két ilyet a felvételibe, csúnya vérengzés volt. A string-float/int konverziónál meg ha valaki nem néz a mélyére (jellemzően valamilyen phpwtf oldalon kell), csúnya meglepetés érheti az embert. Ld. 'x' == 0.

Egyébként nem azt mondom, hogy nem kell ezeket megtanulni. A különbség az, hogy PHP esetén csak a type jugglinghoz annyi szabályt kell kell megtanulni, mint a C#-hoz meg a Javahoz összesen...

Igen, valahol sejtem, hogy nem fog kikerülni a nyelvből, mert csak. Csak az a kérdés, hogy
- egy programnyelvnek "viccesnek" kell-e lennie vagy produktívnak
- vajon azt a nyelvet érdemes-e használni, amit "így marad, mert csak" elvek mentén fejlesztenek vagy azt, amit értelmes, műszaki érvek alapján?
- illetve, ahol ennyire látványosan szarják le az usereket.

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

Elég jól ismerem, igen. Én is fel szoktam tenni type juggling típusú kérdést interjúkon, és nálunk is rendszeresen elvéreznek ezen, de ez nem a nyelv hibája, hanem a PHP fejlesztők többsége sajnos ennyire ismeri az eszközt, amivel dolgozik. Szomorú. Nem nehéz ez, csak utána kéne egyszer olvasni.

Nem szeretem a vicceskedést a kódban én sem, tiltom is a kollegáknak, de ez a T_PAAMAYIM_NEKUDOTAYIM már annyira régi, hogy sajnálnám, ha kikerülne.

( chx | 2015. 12. 31., cs – 15:29 )

Perl-t sokan siratják Python okán. Utóbbit nem ismerem, de itt is 3x annyi szavazatot kapott. Lehet meg kellene néznem.

____________________
echo crash > /dev/kmem

Azt a "data scientist" dolgot értem is, meg nem is. Értem, hogy ha adatbányászatra kell gyorsan valami kis progi, akkor Python-ban hamarabb megvan, mint Java-ban. Többnyire én is erre használom a Python-t. De ha komoly munkáról van szó, azaz cégek iratnak programokat, amiket aztán használnak is, azaz jóval tovább futnak, mint amennyi idő a kifejlesztésük volt, akkor a Python nem lehet vetélytársa a Java-nak, mert a keletkező kód kb. 10-szer lassabb.
Szóval nem nagyon értem, miért lenne összefüggés a "data scientist" és a "python developer" között. Szerintem a Python népszerűsödését a cikk ezen mondata indokolja a legjobban: "And many sysadmins, penetration testers and office workers use Python to automate their repeating tasks."

( uid_17784 | 2016. 01. 20., sze – 00:24 )

Kedvenc szkriptnyelv?
Ez igy most vicc?

PHP vs JavaScript?

A terulet lemaradt, anelkul szart sem er ez a kategoria.