ugrás a tartalomhoz

Your Language Sucks

tgr · 2013. Feb. 21. (Cs), 15.48
Különféle programnyelvek hibáinak gyűjteménye
 ■
1

Lista

Hidvégi Gábor · 2013. Feb. 21. (Cs), 16.38
  • A Javascript részben felsoroltak túlnyomó többsége szerintem hülyeség; jópár éve dolgozom ezzel a nyelvvel, de sosem zavartak igazán ezek. Ilyen a szintaktika, így működik, ha az ember ezt tudja, akkor eszébe sem jut rossz kódot írni. Szerintem az, aki ezt a listát összegyűjtötte, más nyelvből jött, és a megszokásain nem tud túllépni. Az emberi nyelvekben is mások a szabályok. A parseInt()-nél viszont sosem értettem, miért nem alap a 10-es számrendszer.
  • A PHP-nál hasonló a helyzet. Amivel találkoztam viszont:
    <?php
      print (0 == 'SL') ? 'igaz' : 'hamis';
    ?>
  • A C-ben viszont teljesen igaza van.
  • CSS:
    - statikus; ez mindent überel
    - nem lehet egy változó méretű tartalmi blokkot egyszerűen vízszintesen és/vagy függőlegesen középre igazítani egy szülőhöz viszonyítva
  • HTML: ez kimaradt, talán azért, mert jót nem igazán lehet róla mondani
2

Szerintem nincs olyan nyelv,

inf · 2013. Feb. 21. (Cs), 19.58
Szerintem nincs olyan nyelv, ami tökéletes lenne. Mondjuk vannak tökéletlenek, meg katasztrófálisak :D
PHP-t is sokat szidtam, de azért az 5.2.x-es verzióhoz képest tényleg sokat fejlődött. Keretrendszert már soha az életben nem kezdenék el ráépíteni, mondjuk egyik nyelven sem kezdenék el ilyesmivel foglalkozni. Legalább ezt megtanultam a PHP-val töltött idő alatt. :-)
3

váltogatásokkor

zzrek · 2013. Feb. 22. (P), 00.04
Nekem a váltogatásokkor jelent ez problémát, ami ugye sokszor fordul elő, ha az ember PHP/JS cuccot csinál. Engem ilyenkor sokszor szörnyen idegesít, hogy a PHP-ben $ jelet kell tenni a változók elé, az objektumok tagolása -> izével megy és nem ponttal, a stringösszefűzés meg ugye pont.... ráadásul ezek véletlen összekeverése olyan hibát eredményezhet, ami nem ad közvetlen hibajelzést, ilyenkor meg aztán eltart egy ideig, míg kapcsol az ember, hogy a tökéletesnek hitt kód miért produkál fura eredményt.

Sokszor az az érzésem, hogy direkt csinálták így a PHP-ben, csak azért, hogy más legyen, mint általában a többi nyelvben.

Örülnék, ha lenne egy szintaktika-cserélő, amivel ilyen szempontból JS-szerűbb kódot lehetne a PHP-vel megetetni. Mondjuk az értelmező a <?jhp ?> jelölők közt ilyet fogadna el. Sőt, annak méginkább örülnék, ha lenne <?js ?> lehetőség is, amiben pedig JS kódot értelmezne, a PHP mellé egy JS interpretert is csomagolnának, a változónevek pedig valamilyen szisztéma szerint átjáródnának a két névtér közt (kérésre).

Még azt is megfogalmaztam magamban, hogy sok esetben fölöslegesen csinálnak különbözőségeket a nyelvek közt, jobban járnánk, ha le lenne fektetve egy minimum standard, amit minden nyelv követne (amennyire lehetséges), minthogy ezt teszik a matematikai alapú kifejezésekkel, jelekkel, a ciklusparancsokkal, stb. Szóval közös szabványt kéne elfogadtatni.
4

Egy nyelv mind felett

Udi · 2013. Feb. 22. (P), 15.25
Már évek óta létezik a Haxe, aminek pont ez lenne a célja. Több esélye lett volna az elterjedésre, ha a Flash népszerű maradt volna. Így csak egy újabb hang a zajban.

A JavaScript viszont még lehet univerzális, node.js van már szerveroldalon, legutóbb a Gnome tette ajánlott nyelvéve, tehát máshol is erősen terjed. Az ECMA révén szabvány is van mögötte, reméljük gyorsan és egységesen fejlődik majd.
5

kliens oldali nyelv = szerver oldali nyelv

T.G · 2013. Feb. 22. (P), 15.36
Ha az a cél, hogy kliens és szerver oldalon ugyanaz legyen, akkor a JS mellett ott van még a Java is. (most ismerkedem még csak a GWT-vel, de elsőre nagyon pozitív a benyomás) Illetve a GWT-hez hasonló megoldás van a Pyhton-nál is (Pyjamas)
6

js

zzrek · 2013. Feb. 23. (Szo), 01.02
A js jó lenne (a haxe-nél az nem tetszik, hogy sehol sem fut natívan) szerver oldalon, de amíg az olcsó tárhelyszolgáltatók nem adnak node.js-t, addig nemigazán jön (nálam) számításba. Viszont a PHP meglovagolhatná a lehetőséget, ami az elterjedtségében van: miért is ne integrálna más nyelv értelmező modult is a következő kiadásába? A tárhelyszolgáltatók frissítenék, és máris lenne mindenhol szerveroldali JS. Ezzel a PHP is erősíthetné a fennmaradását.
7

Szerintem semmi szükség arra,

MadBence · 2013. Feb. 24. (V), 13.47
Szerintem semmi szükség arra, hogy az amúgy is rettentő lassú PHP értelmező tetejére még egy JS értelmezőt is pakoljanak. Másrészt nem értem mi értelme lenne a szerveroldali PHP és szerveroldali JS keverésének.
9

+1, én sem értem minek kéne

inf · 2013. Feb. 24. (V), 18.23
+1, én sem értem minek kéne keverni a szezont a fazonnal...
25

milyen szezont, milyen fazonnal?

zzrek · 2013. Feb. 25. (H), 15.59
Vagy én értettem félre valamit, vagy te. Milyen szezonfazon keverésről beszélsz?
24

félreértettél

zzrek · 2013. Feb. 25. (H), 15.58
Félreértettél, nem a php tetejére kérek JS értelmezőt, hanem mellé. Egy csomagban jöhetne a kettő, pusztán azért, hogy hipphopp legyen egy elterjedt szerveroldali JS értelmező. Külön, nem a PHP tetején, a JS értelmező sebessége nem függ a PHP-sebességétől. Ez nem befolyásolna semmit sem a PHP-n, pusztán annyit, hogy az is használhatná az olcsó szervereket, aki szerveroldali JS-t használna, ezáltal a PHP csomag terjedése, fennmaradása is pozitív lökést kapna.
33

Nem tartom valószínűnek ezt a

MadBence · 2013. Feb. 25. (H), 21.01
Nem tartom valószínűnek ezt a verziót. Valamint továbbra sem értem, miért kellene a JS-t a PHP-val vegyíteni.
További probléma, hogy ott milyen API-t lehetne használni? Mi van az aszinkron műveletekkel?
35

Nem muszáj

zzrek · 2013. Feb. 25. (H), 22.04
Nem muszáj vegyíteni, ez csak egy plusz kényelmi funkció lenne arra az esetre, ha valaki vegyesen szeretne js és php kódot használni. Egyébként a két értelmező teljesen független lenne. (A lényeg, hogy a PHP karolhatná fel a JS terjesztését, ahogy fenn is említettem, akár .php kiterjesztésű fájlokon belül. A PHP mozaikszó jelenthetné ezekután mondjuk azt is, hogy Piszkosul Hiperszuper Programozás :-) )
Az API kérdést nem értem.
Az aszinkron műveleteket akárhogy lehetne értelmezni, a lényeg, hogy JS szintaxis szerint menjen/mehessen.
37

Aztán jönnének a különböző

BlaZe · 2013. Feb. 25. (H), 23.04
Aztán jönnének a különböző szintaktikájú scripteken fejlesztett projektek?
39

Most vannak

zzrek · 2013. Feb. 26. (K), 18.45
Most vannak - kényszerűen - különböző szintaktikájú projektek, mert sok esetben szerver oldalon csak php áll rendelkezésre. Ha a php (csomag) tartalmazna js fordítót is, akkor jöhetnének az "egy szintaktikán" alapuló projektek bárhol (és nem csak ott, ahol a szerverre nodejs tehető)
40

Java-ban ugyanúgy lehet ilyen

inf · 2013. Feb. 26. (K), 19.42
Java-ban ugyanúgy lehet ilyen projekteket írni, meg szerintem asp.net-hez is létezhet ilyen csomag, ehhez viszont egyik sem használ js fordítót, szimplán objektumokkal csináltatják meg a js kódot...
8

Szerintem nem ezzel, hanem a

Poetro · 2013. Feb. 24. (V), 15.34
Szerintem nem ezzel, hanem a nyelv gatyába rázásával kellene megerősíteni.
10

Nekem csak tippem van, miért

Karvaly84 · 2013. Feb. 24. (V), 19.55
Nekem csak tippem van, miért van lemaradva a JS. Van egy rakás fentartott kulcsszó benne, ami 20 éve benne van. Véleményem szerint azt akarják, hogy konzisztens maradjon a nyelv, ami tök jó, viszont ez miatt határához érkzett és nincs tovább. A PHP-ről ez nem mondható el, fejlődik csak sokat anyázik az ember ha pl 4-ről 5re akar váltani, de szerintem így lessz ez a 5-6 esetében is. Én egy JS++ nevezető nyelvre vágyom azóta mióta a JavaScript-hez hozzányultam, vagy az ActionScript-re, minden hova.
11

-html, -css

Arnold Layne · 2013. Feb. 24. (V), 20.15
Ez utóbbi mondatodat annyival fejelném meg, hogy webes alkalmazásoknál a HTML-t és a CSS-t ki is lehetne már akkor golyózni a bandából. Egyszerűbb szöveges dokumentumokra azért maradhatnának. Amire ugye ki lettek találva anno.
12

A TypeScript valami ilyesmi

inf · 2013. Feb. 24. (V), 22.24
A TypeScript valami ilyesmi próbálkozás, js-re fordul... Van még coffeescript, az pythonra emlékeztető... A TypeScript-hez lehet használni visual studiot. Jelenleg kb. ennyi a lehetőség, ha terjeszkedni akar az ember... Én mondjuk nem akarok, nekem jó úgy is a js, ahogy most van.
13

Nyilván azért van lemaradva,

tgr · 2013. Feb. 25. (H), 12.22
Nyilván azért van lemaradva, mert egy átlagos nyelven ha fejleszteni akarsz, akkor kiadsz egy új változatot, és akinek szüksége van rá, frissíti a szerverét, és onnantól tudja használni, JS-nél meg kiadsz egy új változatot, és vársz tíz évet, hogy a látogatók 99%-a olyan eszközre váltson, ami támogatja. Az ES.next egyébként egy elég modern nyelv, csak épp nem nagyon tudod hol használni.
14

..

Greg · 2013. Feb. 25. (H), 12.25
Itt jonnek a kepbe azok a nyelvek amik js-re fordulnak, mint peldaul a coffeescript. Bar azoknak is van hatulutoje, mert amit abba beleraknak, abbol van olyan feature ami a kovetkezo JS-ben alapbol tamogatott lesz, igy lesz nemi utozes. Bar gondolom kitalalnak majd ra valamit a sracok.
15

A PHP elég dinamikusan

tgr · 2013. Feb. 25. (H), 12.58
A PHP elég dinamikusan fejlődik mostanában. Ha egy éve azt mondja valaki, hogy mostanra már lesz benne closure és generátor, valószínűleg nagyon kinevettem volna. Van short array syntax, finally, function call array dereferencing... ha még a nevesített függvényparamétereket és a list comprehension-öket beteszik az 5.6-ba, meg a weak map stabil lesz, akkor szerintem el is fogynak a visszafelé kompatibilitás felrúgása nélkül pótolható zavaró hiányosságok. Userlanden meg a Composer és a PSR révén szintén jó irányba mennek a dolgok.
16

re

Greg · 2013. Feb. 25. (H), 13.48
visszafelé kompatibilitás felrúgása nélkül pótolható zavaró hiányosságok


Ez amit el kellene felejtenie a php-nak. Hozzak ki a 6ost, ami nem visszafele kompatibilis, es javitsak benne azokat amiert nem szeretheto a jelenlegi nyelv. Aki akar az frissit majd, aki nem az meg igy jart.
17

Aha

Hidvégi Gábor · 2013. Feb. 25. (H), 14.08
Persze, ez így megy egy mondjuk többmegabájtos szoftvernél, írjuk át az egészet, közben derülnek ki a bugok magában a PHP-ban, 6.2-re lesz valamennyire használható...
18

..

Greg · 2013. Feb. 25. (H), 14.14
En inkabb rubyval dolgozom mostanaban, es ott ez az iranyado viselkedes. Idonkent eljon az ido, amikor a backward compatibility-t dobni kell. En ezt elonynek latom, es teljesen jol mukodik.
Az egesz alkalmazast egyebkent nem feltetlenul kell atirni ha a nyelvet frissited mogotte, mert a changelog alapjan latod a te app-odat mi erinti. Es a bug-ok nagy resze megelozheto lenne TDD-vel, de az a PHP vilagaban nem divat sajnos.
Na es meg mindig ott van az opcio, hogy maradsz az elozo verzional.
19

Hát igen, mindkét irány

Hidvégi Gábor · 2013. Feb. 25. (H), 14.40
Hát igen, mindkét irány mellett vannak érvek és ellenérvek. A csodákban viszont már nem hiszek (hogy egy új [al]verzió sokkal jobb lesz).
22

szerintem se lenne jobb. en

Greg · 2013. Feb. 25. (H), 15.41
szerintem se lenne jobb. en eppen ezert valtottam ruby-ra. sokkal jobban erzem magam amikor rubyval dolgozom, mint amikor php-val. Egy percig sem bantam meg a tanulasara szant idot. De kinek a pap, kinek a papne.
23

Verziók

Hidvégi Gábor · 2013. Feb. 25. (H), 15.53
Bocsánat, nem voltam egyértelmű, én általában értettem azt, hogy az új verziókban nem hiszek, nem kifejezetten a php-ra. Nem igazán látom a szoftverekben a nagy fejlődést, sokszor csak egy újabb skint kapunk. Persze az is lehet, hogy nekem alacsonyak az igényeim vagy túl nagyok az elvárásaim, de már rég volt az "ez igen, erre megérte várni" érzésem, meg hogy "na, ezért szívesen fizetnék".

A magam részéről a PHP-val elégedett vagyok, mert mindent meg tudok vele oldani. Boldogabb lennék viszont, ha JS-ben meg tudnám csinálni ugyanezt, mert a szintaktikája közelebb áll hozzám. Mindenkinek van legalább egy nyelve, amiben a legjobban ki tudja fejezni magát, örülök, hogy a Rubyban te is megtaláltad a magadét, mert így igazán élvezetes a munka.
26

re

Greg · 2013. Feb. 25. (H), 15.59
de már rég volt az "ez igen, erre megérte várni" érzésem, meg hogy "na, ezért szívesen fizetnék".

Nalam a Rails4 ilyen peldaul. De akar a puma2 is, es ha gondolkoznek meg, akkor szerintem talalnek meg par projectet :).
20

Nézz utána, hány site alatt

tgr · 2013. Feb. 25. (H), 15.21
Nézz utána, hány site alatt fut ruby és hány alatt PHP, és akkor megérted az eltérő hozzáállás okát.
21

..

Greg · 2013. Feb. 25. (H), 15.40
Ez szerintem nem mervado erv. Attol hogy kiadnak egy uj verziot, ami nem visszafele kompatibilis, nem kotelezo mindenkinek frissiteni. De gondolom, aki uj projectbe kezdene, az mar az uj verzioval dolgozna.
29

A PHP oldalak nagy része nem

tgr · 2013. Feb. 25. (H), 17.05
A PHP oldalak nagy része nem self-hosted, a szolgáltatók nem fognak átállni, ha csak az oldalak elenyészően kis részének van szüksége az új verzióra (lásd a PHP4/PHP5 átállás nehézségeit). Arról nem beszélve, hogy a PHP egy opensource projekt, tipikusan azok fejlesztik, akik használják, ők pedig abban érdekeltek, hogy a meglévő alkalmazásaik, frameworkjeik jobban működjenek, miért dolgoznának egy olyan PHP-újraíráson, ami ezt a célt nem szolgálja?

Persze bárki megteheti, hogy csinál egy inkompatibilis PHP forkot, akár te is. De nyilván nem fogod, mert sok munka, és nem nyersz vele semmit: ha inkompatibilis nyelvet akarsz nagyobb kifejező erővel, akkor ott a Ruby, a Python, a Scala stb. Ez egy másik niche.
30

Én azt nem értem, hogy miért

inf · 2013. Feb. 25. (H), 18.06
Én azt nem értem, hogy miért kell alapból kompatibilisnek lennie a régi változattal... Sokkal ésszerűbb lenne, ha csinálnának mondjuk php6-hoz php4 meg php5 extension-öket, aztán össze lehetne válogatni, hogy mire van szükség, és mire nincs... Pl az alap string, array, stb... függvényeket teljesen át kellene dolgozni. (nem tudom 5.2.x óta ezzel foglalkoztak e), ugyanúgy a hibakezeléssel kezdeni kéne valamit, mert ott is elég nagy a káosz...
27

Szerintem

zzrek · 2013. Feb. 25. (H), 16.05
Szerintem meg ezzel nem kapnám meg azt az előnyt, amiről beszéltem: ugyanazt a nyelvet kliens és szerveroldalon is. Hiába rázzák gatyába a PHP-t, a macerás különbségek megmaradnak. Az én javaslatomnak az lenne az előnye, hogy gyorsan rendelkezésre állhatna egy szerveroldali JS, ha annak a terjesztését a PHP felvállalná.

A mondanivalóm két kulcskifejezése tehát: ugyanaz a nyelv mindkét oldalon ; mindez reális lehetőségekkel gyorsan elterjedve.
Ha erre van jobb javaslatotok is, akkor nekem úgy is jó. Kövezzetek meg viszont, ha szerintetek ennek semmi értelme.
28

..

Greg · 2013. Feb. 25. (H), 16.12
Most nem talalom, de lattam php szintakszishoz hasonlo, js-re fordulo micro nyelvet. Ugyanaz mint a coffescript, csak a szintakszis inkabb a php-ra hajaz, mint a ruby-ra. Ez ezzel majdnem olyan mintha ugyanazt a nyelvet hasznalnad a kliensoldalon is, mint a szerveroldalon.
31

Ja, létezik ilyen, sikítva

inf · 2013. Feb. 25. (H), 18.07
Ja, létezik ilyen, sikítva menekültem, amikor meghallottam :D
32

érdekes

zzrek · 2013. Feb. 25. (H), 19.08
Érdekes ötlet, de én a JS-t szeretném szerver oldalon, nem a PHP-t kliensoldalon.

A fordítottja talán hasznos lenne, egy olyan fordító, ami php-t generál js szintaxisból. Ilyet láttam régen, valami phpjs vagy ilyesmi volt a neve. Ha tökéletes lett volna, talán adtam volna neki egy esélyt, de nem fejezték be.
34

Nem értem...

Max Logan · 2013. Feb. 25. (H), 21.38
...mire ez a nagy love a JS felé. Nekem a hátamon feláll a szőr a JS szintaktikájától, meg az objektum modelljétől... (Tudom, egyéni szoc.problem...)
36

Biztos van jobb is

zzrek · 2013. Feb. 25. (H), 22.10
Biztos van jobb is, de már megszoktam. A bajom a kettősséggel van, hogy amikor váltok, akkor hibázok gyakrabban, ezért jó lenne ha egyfajta szintaxist kellene csak használnom. Engem a PHP inkább idegesít, a $-ozás meg a -> meg a . összefűzés fölösleges jelölési kavarásnak tűnik, ha már lehet választani, akkor inkább JS. (A JS objektummodell nekem sem annyira természetes egyébként :-) )
38

+1

Pepita · 2013. Feb. 26. (K), 01.22
Nekem sem barátom a szintaktikája, ezzel együtt nem zavar, hogy eltér a PHP-tól vagy egyébtől. Szerintem én akkor hibáznék jóval többet, ha mindkét oldalon (kb. vagy teljesen) ugyanazt a nyelvet használnám.
Így legalább mindig tudom, hol vagyok. :) (Vagy mégsem?)