Melyik a számodra legkevésbé kedves programozási nyelv?

Címkék

C
6% (27 szavazat)
C#
7% (30 szavazat)
C++
3% (16 szavazat)
Haskell, Erlang, Caml, ... (funkcionális nyelvek)
9% (43 szavazat)
Java
17% (79 szavazat)
JavaScript
8% (38 szavazat)
Perl
7% (32 szavazat)
PHP
13% (60 szavazat)
Python
4% (18 szavazat)
Ruby
3% (13 szavazat)
egyéb, leírom
3% (16 szavazat)
(csak az eredmény érdekel)
19% (89 szavazat)
Összes szavazat: 461

Hozzászólások

Az opciók a legutóbbi HOVD-ról vannak.

ez egy jó kérdés.
a c++-hoz sose értettem, indokolatlanul bonyolultnak tartom, de ez nyilván nem a nyelv hibája.
esélyes volt a perl az érthetetlensége miatt, de ez se a nyelv hibája.
végül a python nyert a szigorú kódolási megkötések (pl. behúzások) miatt. függetlenül attól, hogy bármire használható a nyelv.

+1 a Python-ra (mar azok kozul amit ismerek)

Ez a behuzasos dolog nagyon bosszanto tud lenni, kulonosen amikor kap az ember egy kodot, amit valaki tab-okkal kezdett el, majd valaki mas space-ekkel folytatta...

/sza2

Szerk.: Meg a csak egysoros kommentezes. Vagy van tobbsoros is, csak nem tudok rola?

De mi koze ennek az editorhoz?

A Python ertelmezo a kerdes. A tobbi, nem indentalas alapjan stukturalo nyelvnel maximum csunya a kod, de a Python eseten nem azt fogja csinalni amit szerettel volna, mindossze azert, mert az egyik sorban 4 space van, a masikban meg egy tab.

Ha Python-t editalok, _mindig_ be van kapcsolva, hogy latszodjanak a whitespace karakterek, ez valamekkora segitseg.

/sza2

Persze, egy editor sokat tud segiteni, de ha eleve van egy kodod, amit tobben irtak, tobb kulonbozo editorban, mondjuk vannak tab-ok, space-ek vegyesen (mert sajnos kellet ma ilyet tovabbvinnem), akkor a tab/space konvertalo sokesetben tobb kart csinal mint hasznot, lehet, hogy az egesz kodot at kell nezned, megertened, mert nem tudod automatikusan konvertalni.

/sza2

Csak egy kérdés, ez a kód eddig hogyan futott? Ha futott, akkor tudod a tab értékeket és át tudod konvertálni a forrásokat. Vagy ez csak leírva ilyen egyszerű? Őszinte leszek, ilyen kódot még nem láttam, nem tudom ilyen esetben két tab egyenlő két szóközzel?

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

"nem tudom ilyen esetben két tab egyenlő két szóközzel"

Na ez az, arra sincs garancia, hogy ugyanolyan tab size-zal dolgoztok. Általában a 4 space az elfogadott, de ez nincs kőbe vésve. Olyan nyelveknél, ahol a szintaxisnak nem része a space, ott ez nem probléma, legfeljebb ha valami nem sor elején lett tabokkal egymás alá igazítva (de olyat meg miért tennél).

Nem csípődött be, de ismét csak visszatérek az editorra. Van amibe bele tudod írni mekkora tabot használsz a forrásban, írsz scriptet alá, hogy jelezze ha tab van a forrásban, stb. Persze tudom, ha más nem használja, akkor ő szétcsesz(het)i. De legalább az editorod tud erre "figyelmeztetni".

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

"de ha eleve van egy kodod, amit tobben irtak, tobb kulonbozo editorban, mondjuk vannak tab-ok, space-ek vegyesen"

Normális esetben nincs lespecifikálva a coding standard legalább egy projektszinten, hogy azt kövesse mindenki? Oké, hogy a python megköveteli a korrekt behúzásokat, de ahol nincs megkövetelve ott is elég zavaró tud lenni, ha vegyesen vannak.

Ha követjük Robert C. Martint, akkor :D nélkül is igaz az állítás második része és nem csak pythonban.
Viszont a több soros komment, amint azt a korábbi példa is mutatja, arra is jó eszköz lenne, hogy ideiglenesen kiiktass kódrészleteket. Erre úgy tűnik, valóban nincs megoldás pythonban.

"Erre úgy tűnik, valóban nincs megoldás pythonban."

Nem is kell, mert egyszerűen kijelölöd a blokkot, és szólsz az editorodnak, hogy kommentezze ki. Aztán meg vissza, ha kell. Azért ez nem űrtechnika. Jobb is, mint mondjuk a /* */, mert a kikommentezett blokkból akár egy kisebb részt is vissza tudsz engedni egyetlen gombnyomással (mivel soronként van jelölve).

A SHIFT+I nekem nem jó, mert így végig kell szántanom azokat a sorokat, amit ki szeretnék kommentezni. :D

Szerk.
Nem sikerül így globálisan beszúrni a # jelet, tehát hogy csak egyszer keljen a # leütni.

Szerk.Szerk
Sikerült, az ESC-nél toltam el, pedig automatikusan duplán ütöm le, ha kell ha nem. Köszi! :)

Nem mindegy? Aki tudja, már nem használja, mert túllépett rajta, aki nem tudja, az meg azért nem használja azt az editort...
- - - - - - -
A nagy tudású uraknak felhívnám a figyelmét arra, hogy a Windows ugyan sok mindenre nagyon jó, de Linuxnak speciel nagyon szar.
"http://hup.hu/node/111669#comment-1419622">csfeco

Az identalason kivul milyen "szigoru kodolasi megkotesek" vannak?

Amugy en epp szeretem ezt, egyreszt nem kell zarojelezni (pontosabban zarojeleket vagy statemnteket lezarni), masreszt meg az identalast amugy is hasznaljuk, akkor miert ne hasznalja ki a nyelv is?

Igen, persze a masokkal valo egyuttmukodes problemas lehet, de ebben a szovegszerkeszto sokat segithet. Meg esetleg a kozos kodolasi szabalyok (amik amugy is hasznosak).

Azert az is tud szop@st generalni, amikor veletlenul kitorolsz egy-ket space-t (raadasul egy mas altal irt programban), es kesobb azt veszed eszre, hogy nem emlekszel, hogy az adott utasitast a program iroja egy cikluson belulre, vagy kivulre akarta tenni...

Tobb emberrel beszeltem mar akinek kellett Python-ban kodolni, de egyontetu velemeny volt, hogy az indentalassal valo strukturalas egy oriasi hatrany.

En C-ben is eleg kovetkezetesen betartom az indentalasi "szabalyokat", de egy ossze-vissza behuzott C programot is kivaloan meg tud szepiteni az autoformatter - ellenben Python eseten ez ugye ertelmezhetetlen.

Raadasul ha egy kodreszletet egy szinttel fentebb / lentebb akarsz tenni, az Python-ban mindenfelekeppen bonyolultabb, hiszen minden sort manualisan kell atrendezned.

/sza2

Ide, es artifex-nek is:

Arra gondolok, hogy pl. egy for ciklusnal, ha eggyel kulsobb szintre szeretnel tenni egy masik ciklust, inteligens editorok (tegyuk fel C, C++, akarmi eseten), kepesek atrendezni a kodot, hogy jo legyen az indentalas. Ugyanez Python-nal a zarojelezes hianya miatt nem oldhato meg, hiszen az autoformatter nem tudja, hogy az egyik ciklus a masikon belulre kerult. Egyebkent a normal auto indentalast sem lehet az editorra bizni, mert nem tudja, hogy a kozetkezo sort melyik szintre szeretned.

Eleg sok ram maradt Python kodot kell karbantartanom, es en ezt az behuzasos strukturalas az egyik rakfenejenek tartom, megha szamos mas elonye van is.

/sza2

A cikluson belüli részt beljebb tolod és utána írod be az új ciklust?

De értem a dolgot, blokk eleje és vége jelzés nélkül nehezebb a forrás későbbi feldolgozása.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Feltételezem arra gondolt, hogy míg a

if (a) {
p1
if (b) {
p2
}
p3
}

kódot szépen tudod identálni később, addig a

if a:
p1
if b:
p2
p3

gyakorlatilag megoldhatatlan python alatt, hiszen nem derül ki a p3 kihez tartozik.

Másrészről, az bizonyos lustaság (nem fikázás, én is csinálok ilyet, ha a nyelv megengedi), hogy nem a helyére teszed a kódot, hanem majd az autoformatter rendberakja utána.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Pythonban ezért kell gondosan indentálni, nem mintha máshol nem kéne figyelni. :)

Én az osztályokat 2 üres sorral választom el, belül meg 1 üres sorral választok el mindent, még egy magányos változót is. Szellősen dolgozom, de legalább szemre egyből látszik, hogy ki/mi hova tartozik.

Az identálást akkor is lehet jól csinálni, ha az elrontásától a programod hibásan működne. Egy blokkot _csak_ az identálás különböztet meg a rajta kívüli kódtól. Elég egy sornak elrontani a behúzását, és máris nem azt csinálja a kód, amit szeretnél.
Blokkhatárolókat használó nyelvekben ez két sor felcserélését jelenti, ami azért messziről látszik.

Ez jogos, de ettől még számomra szimpatikus az alapötlet. Túl sok p.szőr hófúváskor kódot láttam már ahhoz, hogy a szép kódot értékelni tudjam. De jogos amit írsz, ha elcsúszik valami, akkor szopás.

"egy ossze-vissza behuzott C programot", lehet az a cél ilyen ne legyen.

A szintlépés problémát nem értem, megint editor kérdése, hogyan tudod a szintlépést megoldani.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

> "egy ossze-vissza behuzott C programot", lehet az a cél ilyen ne legyen.

Igen, a cel egyertelmuen ez, csak nem biztos, hogy sikerult a kerdesre a legjobb valaszt talalni.

Egyebkent a Python 3-nal azt hiszem csak space elfogadott az indentalasra, ami kicsit egyertelmubbe teszi a helyzetet (bar azon nem valtoztat, hogy pikk-pakk keresztbe lehet f0sni a kodot, ha veletlenul torol az ember par space-t, raadasul szintaktikailag helyes is marad, szoval ki tudja, mikor veszed eszre...)

/sza2

Nyilvan van kulonbseg az egy-ket karakter es az egy-ket space kozott, de azt is belathatod, hogy hasonlosag is van. Miutan veletlen torlesrol beszelunk igy kb mindegy.

Amugy shell-ben sem mindig mindegy hogy van-e space vagy sem, de az kicsit furmanyosabb (es sokkal inkabb bosszanto szerintem). Pl:


if [ $a = 3 ]
if [$a=3]

De asszem mindegy is, ez a python identalason lovaglas is hitvita, es ha meg nem derult volna ki: nekem semmi bajom vele, en birom a pythont. :)

Nem erzem hitvitanak, engem a gyakorlatban zavart / zavar. Van, amit en is Pythonban irok meg, mert epp az a legjobb ra, de engem mar bosszantott par tulajdonsaga.

Szerintem az Eclipse pl. eleg ugyesen tud banni a tab-okkal, space-ekkel, indentacioval, de volt mar hogy a sor elejen egy veletlenul nyomott tab miatt a program mast csinalt mint amit kellett volna.

Megprobalhatod megmagyarazni, hogy nem igy van, de azert mondjuk egy szintaktikai hibat elobb eszre vesz az ember mint egy whitespace elirast.

/sza2

Én is szeretem a pythont, sőt szerintem első nyelvnek is kiválló, pontosan a behúzásos móka miatt, ami struktúrált gondolkozásra tanít. Ettől függetlenül jártam úgy, hogy egy egy hobby projektet az egyik IDE-ben elkezdtem, majd egy idő mulva elővettem a projektet egy másik IDE-ben, elvégeztem az eglsz refaktorálást, amit kigondoltam, és 1-2 óra fejlesztés után volt a kopp, amikor indítani akartam, hogy bizony szemre jók a blokkok, csak épp nem fut az egész. Persze "csak" 1-2 óra munkát kellett átnyálazni/rendbeszedni, de mondhatni pain in the @ss volt.
-
groovy.lang.Tuple kicsit közelebbről

Egysorosokat nem igazán tudsz benne csinálni, "szépen" formázni a kódot meg nem így kéne megtanulni, ahogy az első osztályosoknak sem betűsablont adnak a kezébe, hogy tanuljanak meg szépen írni :-P
Normális editor szépen egységesen kezeli az identálást, jön a python-fanok kedvence, én meg azt mondom, hogy normális editor szépen tud például {}-es blokkokat formába önteni :-P

Tud, ne:
a) nem kötelező
b) eltérő lehet editoronként
c) én nem a forráskód behúzásáról beszélek, hanem a struktúrált gondolkozás fejlesztéséről

De értem amit mondasz, én csak annyit mondtam, hogy tanulónyelvnek ezért (is) alkalmas, ahogy pl a Groovy-t 3-5 év Java tapasztalat híjján senkinek sem ajánlom, mert elfed egy csomó mindent, amivel aztán lehet szívni

-
groovy.lang.Tuple kicsit közelebbről

"de egyontetu velemeny volt, hogy az indentalassal valo strukturalas egy oriasi hatrany."

Ilyenkor mindig azt szoktam kérdezni, hogy "miért, hogy akarsz másképpen indentálni"?
:)

Ez egy hatalmas fícsör. Rákényszeríti a gányművészeket, hogy egyféleképp indentáljanak.

"Raadasul ha egy kodreszletet egy szinttel fentebb / lentebb akarsz tenni, az Python-ban mindenfelekeppen bonyolultabb, hiszen minden sort manualisan kell atrendezned."

Erre a megoldás egy IDE használata. Pl. http://pydev.org/ A vim/joe/stb fasza konfigszerkesztésre, viszont nagyobb projectre nem igazán...

Sajnos nem. Nem kenyszeriti ra az egyforma indentalasra.

Lehet tab, 1, 2, 3, 4 space, N space, mittudomen, etc. Aztan jon a sz0pas, mert nem is latod, hogy epp melyik van hasznalva, mivel whitespace (persze, a legtobb editorban be lehet kapcsolni, hogy mutassa oket, de szerintem ez akkor sem normalis)

Raadasul, megcsak az sincs, hogy mindig ugyanannyi space kell hogy legyen, siman megy, hogy az egyik szinten 3 a masikon meg 5 space a behuzas.

4 space eseten szerintem mar eleg konnyu veletlenul 3-at vagy 5-ot rakni, aztan javitgathatsz amikor nem megy.

Ha neked ez feature, hat orulj neki, de ne vard, hogy mas is igy erezze.

/sza2

4 space eseten szerintem mar eleg konnyu veletlenul 3-at vagy 5-ot rakni, aztan javitgathatsz amikor nem megy.

Én nem tabolok, csak spacet használok. A másik meg az, hogy egy idő után már szemre is meg tudod állapítani, hogy 4, 8 vagy éppen 16 space a behúzás, legalábbis én látom.

Nem ertem, ez hol volt kerdes. En is meg tudom kulonboztetni, a 4, 8, 16 space-t.

Ugy tunik nem ertetted meg, en azt mondom, hogy mondjuk a 8 es a 7 vagy 9 megkulonboztetese tud gaz lenni. Pl.:


a = 0

for i in range(1)
        if a == 0:
                print "0"
         else:
                print "!0"

Eredmeny: IndentationError: unindent does not match any outer indentation level

/sza2

Nem azért anonymous egy függvény, mert egysoros, hanem mert nem akarom többször használni. Ha ilyenkor előtte nevesítenem kell, és úgy átadni egy függvények, az teljesen felesleges, ráadásul sokkal nehezebben olvasható.

Amúgy nálunk konkrét eset volt, amikor ez gondot okozott (és amúgy nem csak ez, sok más hasonló idegesítő aprósággal /vagy inkább baromsággal?/ meggyűlt a bajunk). Mégpedig egy xml alapú transzormációs logikából (kb xslt-hez, vagy mondjuk ant-hoz lehetne hasonlítani) python kódot kellett generálnunk, mert azok az emberek, akik ezt fejlesztik nem értenek máshoz. Ráadásul ők nem is programozók, hanem domain expertek, és nem a programozás a szakmájuk. Na most nekik egy soksoros lambdát meg tudok magyarázni, de azt nem, hogy mit jelent, ha definiálok egy függvényt egy másik közepén, és azt adom át egy másik függyvényhíváskor paraméterként.

Szóval ezzel a példával azt akartam mondani, hogy igen, legtöbbször ezek az apróságok nem jelentenek gondot, de ahhoz, hogy egy nyelv jó legyen, az ilyen speciális eseteknek sem lenne szabad problémát okozniuk. Sajnos a pythonnál ez nem így van.

Hát látszik, hogy nem ugyanott tanultuk a kódolást. :)
Én valami olyat olvastam (talán Uncle Bobtól a Clean Code-ban? Erre nem mernék megesküdni), hogy nem csak olyasmit teszünk függvénybe/metódusba, amit többször akarunk hívni, hanem a zárt egységet alkotó részeket is. Többek közt azért, mert a nevük helyettesíthet pár sor kommentet is.

Például egy hosszabb kódot, amit te többsoros lambdaként írsz le, azt én pusztán azért, mert viszonylag nagyobb egységet képez, valószínűleg külön függvénybe tenném.
(azért azt nehezen tudom elképzelni, hogy valaki, aki python kódokat buzerál, ne értené meg, még ha nem is programozó az illető)

Mindkettonek lehet letjogosultsaga.
Pythont nem ismerem ilyen szinten, de mashol mar tobbszor lattam olyat, hogy egy fuggveny meghiv valamit, es utana callbackkel kapja vissza aszinkron modon az eredmenyt. Ilyenkor ha a hivaskor egy lambda fv-t adsz callback fuggvenynek, akkor logikailag ott tudod folytatni a kodot, ahol akkor folytatodna, ha szinkron lenne a hivas. Egy ilyen lambda nyugodtan lehet tobbsoros.

--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.

Na de azért ugye egy két soros kód még nem számít hosszúnak? Attól, hogy egy lambda többsoros, még nem feltétlenül lesz bonyolult, vagy hosszú.

Amúgy igen, a felvetésed teljesen jogos, magam is amikor coding style-t ismertetek az új kollégákkal mindig kitérek rá, hogy a jól körülhatárolt feladattal rendelkező pár soros kódot is érdemes külön függvénybe szervezni, viszont azért a többsoron lambdának is van létjogosultsága, például, hogy nem töri meg a kódot, és ott folytatódik, ahol az őt hívó függvény van.

És igen, nem teljesen egyértelmű, hogy mit jelent az, ha függvény közepén van függvény definiálva, ugyanis az emberek nincsenek hozzászokva, nem látnak ilyet nap mint nap. Ráadásul felmerül, hogy milyen változók láthatóak, de az sem feltétlenül egyértelmű mindenkinek, hogy az nem fut le ott, ahol definiálva van, stb.

Azt legalább a margó szélén lásd be, hogy ez egy eléggé speciális eset (nem az egysoros lambda, hanem az egész szituáció). Minden koncepciónak megvannak az előnyei és a hátrányai, ettől még az egész koncepció nem kell, hogy szar legyen, csak egyszerűen lehetnek (szélsőséges) esetek, amire nem való az adott koncepció. És most %s/koncepció/programozási nyelv/g. Szerintem meg a PHP egy rakás sz@r, mert mindhárom állítás igaz: 0 == false, "0" == true, 0 == "0", aztán mégis millióan használják. Vagy pl Groovy-ban fordul, és fut az alábbi sor: List a = ['a'] (és nem vagyok tőle túl boldog).
-
groovy.lang.Tuple kicsit közelebbről

"a PHP egy rakás sz@r, mert mindhárom állítás igaz: 0 == false, "0" == true, 0 == "0""

Ezt sokszor olvastam már, de ez mégis mikor jelent a gyakorlatban problémát? És hogy kéne jobban megoldani? Úgy persze lehetne, hogy az egyik operátor ne működjön, de ha nem tetszik, ne használd, probléma megoldva.

"mégis mikor jelent a gyakorlatban problémát?" mármint az, hogy az egyenlőség vizsgálat nem szimmetrikus, az minden szinten problémát okoz.

"És hogy kéne jobban megoldani?" Hát ugye PHP-ban a csodás === való erre, de ugye a hanyag programozók azt sorra lefelejtik, és az ő teszteseteikben rendben mennek is a dolgok, aztán jön az R1 úser, és aztán értetlenkednek. Volt PHPs kolléga, aki mikor erről beszéltünk, akkor mondta, hogy ő pont ezért mindig ===-t használ. aztán rákerestem, és az egész projektben volt 2. Mert sajnos a szakmai hozzáértés pont annál a nyelvnél igen alacsony (úgy általában), amelyik a legrenyhébben kezeli ezeket a dolgokat, és ebből születik az a sok takony kód, ami a webes világot elárasztja (tisztelet a kivételnek). Érdekes más dinamikus típusos nyelveknél le tudták kezelni ezt a problémát.

"ha nem tetszik, ne használd" nem tetszik, nem használom
-
groovy.lang.Tuple kicsit közelebbről

Szimmetrikusnak szimmetrikus, csak nem tranzitív.

Normális esetben, amikor beírsz egy kifejezést, tudod, hogy a változók milyen típusúak benne, akkor meg azt is, hogy mit fog csinálni az operátor. Ellenőrizve persze nincs, ez minden laza típusos nyelvnél probléma.

A "ne használd"-at az == operátorra értettem olyan esetben, amikor különbözőek a típusok, nem a nyelvre.

Azért arra kiváncsi lennék hogy ezt a C# mivel érdemelte ki egyesek szerint... :)

Üdv. bnv

En oda ikszeltem. :) Nekem a platfromfuggetlenseg nem tetszik benne. Persze, persze, a nyelv nem fugg elvileg a platformoktol, de az MS-nek tulsagosan rajta van ezen a keze, a .Net meg mar erosen egy platfromos. (Letezik olyan, hogy valaki C#-ban dolgozik, de koze nincs a .Net-hez? Nem azt kerdezem, hogy elvileg lehet-e ilyet, hanem van-e aki tenyleg igy dolgozik.) En legalbbis meg sosem hallottam olyanrol, hogy valaki nekiallt egy projektnek aminek fontos a platformfuggetlenseg es azt C#-ban csinalta volna.

En azt nem ertem miert ixeltek sokkal tobben a Javara. A ket nyelv eleg hasonlo, de a fentiek miatt a C# -szerintem- rosszabb, szoval aki igazan gyuloli a Javat az ezt is, legfeljebb Javaval tobbszor lehet talalkozni.

Én pl C#-ban álltam neki egy Linuxon futó szabályzó rendszer megírásának, mivel a Visual Studio-t nyüstölöm 6 éve, a Mono-ban meg kb mára minden megvan ami egy .NET 4.5-ben. Kivéve persze a Microsoft specifikus dolgokat, mint WPF...
A Java-t én pl nem szeretem, túl butuska a C# képességeihez képest, de nem ez a legrosszabb nyelv szerintem. A Java gyűlölet hátterében a lassúsága és az Oracle állhat (szerintem)

Pl. unityben dolgozhatsz c#-ban.

Mondjuk azt én sem értem, hogy miért szavaztak annyian javara amikor a php sokkal rosszabb. ;) De mint nyelv, a c# sokkal gazdagabb a javanál. Lambda kifejezések (oké, java 8 óta van), linq, "var" kulcsszó, anonim típusok (nem összekeverendő a java anonim típusaival), yield return, reference passing, delegates és events nyelvi szinten, a c++-ból átvett dolgok (pl. default arguments, operator overloading). Aztán folytatható a sor a szerintem értelesebben megoldott dolgokkal, pl. a típusrendszerrel, a switch szerkezettel, a checked exceptionök hiányával, az értelmesebben megoldott láthatóságokkal.

Szerk: legfontosbbat kifelejtettem: properties!

Mindezt fejből soroltam fel úgy, hogy hónapok óta nem nyúltam c#-hoz, ellenben javahoz annál többet. :)

Lássuk csak... (itt-ott nyilván enyhe csúsztatások és túlzások lelhetőek fel az írásomban :-) )

C --> nem szeretem, mert a hozzám eljutó problémák körében nincs olyan, amire egy C program megírása lenne a jó megoldás, ellenben van egy csomó olyan, amikor egy nem jól működő C programban kell hibát keresni, forráskód nélkül, a mocsár közepében.

C# --> nem szeretem, mert .NET futtatómotor kell hozzá, amivel régről kimondottan rossz tapasztalataim vannak két projekt kapcsán is (performancia-problémák - nem lassú, hanem nem egyenletes futási sebességű volt a kód, ami akkor tök zavaró volt).

C++ --> nem szeretem, mert a legokosabb programozó ismerőseim körében sincs olyan, aki tényleg értené, hogy miről is szól ez a nyelv a template-ekkel és társaikkal, így nem igazán várnám, hogy bárki is jól működő programot hozzon össze benne.

Haskell és társai --> nem szeretem őket, mert bár bizonyos célterületekre kimondottan nagyon jól használhatóak, sajnos sokan olyan helyeken is erőltetik a használatukat, ahol semmi keresnivalójuk, mert egy nem-funkcionális nyelven sokkal egyszerűbb, szebb, jobb megoldást lehetne adni a problémára.

Java --> nem szeretem, mert mindig védenem kell, hogy nem olyan lassú az, nem olyan rossz az stb., pedig nem hozzáértő kezekben olyan lassú az és olyan rossz az. Továbbá nem tetszik, hogy az 1.5-óta csak bonyolultabb lett a nyelv, sokkal használhatóbb nem.

JavaScript --> nem szeretem, mert az összes felsorolt közül ennek van legkevésbé egységesen és értelmezhetően definiálva és megvalósítva a szintaktikája és szemantikája, a nemfunkcionális tulajdonságairól meg ne is beszéljünk, böngésző-kisverziónként változik.

Perl --> nem szeretem, mert egy olyan eszközt ad egy csomó hozzánemértő kezébe, amellyel olyan kódokat tud létrehozni, amit nem tudok elolvasni. Egy program akkor jó, ha az elolvasásához és megértéséhez nem kell komolyabb energiabefektetés, ezt a Perl és a Perl programozók nem tudják nyújtani.

PHP --> nem szeretem, mert ennek talán a leginkább inkonzisztens az API-ja, nem elég tudni a függvény nevét nagyjából, azt is kell tudni, hogy hol van benne az aláhúzásjel. Nameg a mysql_real_escape_string()? Meh, hogy kell ilyen.

Python --> nem szeretem, mert az OO modellje éppen annyira tér el a többi OO nyelvétől, ami miatt már oda kell figyelni az eltérésekre tudatosan. Nem lenne ezzel baj, ha csak a Python létezne, de a sok Java meg C# között néha Python-ozni is nem egy élvezet.

Ruby --> nem szeretem, mert amit eddig leírtam, az lehetne akár Ruby kód is. A DSL-ek erőltetése miatt szerintem tökéletesen olvashatatlan a nyelv (egyébként pont emiatt nem lett a kedvencem a Puppet és a Chef sem, de ez más témakör).

egyéb --> igen, minden programozási nyelvet utálok. Ami tetszene, az egy olyan nyelv, amiben a C# nyelvi lehetőségeit használhatnám egy Java ökoszisztéma kiterjedt és konzisztens API-jára hasonlító valamivel, miközben lehetőséget kapok a párhuzamos programozásra Erlang-szerű stílusban, mindezt a Python szintaxis eleganciájával. Nyilván.

Ruby: szerintem a DSL-ek miatt pont, hogy olvashatobb kodok jonnek ki (a Perlhez viszonyitva feltetlenul, de egyebkent is), raadasul pont elegge hasonlit az OO modellje a tobbi nyelvhez (excluding Python). A new operator hianya kihivas, de szerintem konnyen megszokhato. Cserebe a vegletekig override-olhato benne minden, majdnem mint a C++-ban.

Egyebkent minden programozasi nyelvet lehet jol es rosszul is hasznalni - am ez elsosorban nem a programnyelven mulik. Lattam mar szep Perl kodot es csunya Java/Ruby kodot is.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

"1.5-óta csak bonyolultabb lett a nyelv, sokkal használhatóbb nem" nekem szivem csücske a generikusok meg az @annotációk, hogy többet ne is mondjak. Persze több mindent kell tudni, de azért hasítja szét a fejemet a tudás, ráadásul mint EE fejlesztő meg még többet, hiszen a platform igazi inyencségei ott kezdődnek.

"böngésző-kisverziónként változik" hát ez k. nem a nyelv hibája ;)
-
groovy.lang.Tuple kicsit közelebbről

Néhányat nem ismerek, azokkal nincs bajom. Sokat szeretek és ismerek. Egyértelműen van egy, amit viszont nem szeretek, súgok: http://www.phpwtf.org/

--

A szavazók közül hányan láttak már FORTH programot? :D

Jelmagyarázat:
n/k ha nem ismerem annyira, hogy szakmai érvekkel alátámasztható véleményt alkothassak róla
n/a ha nem ismerem

C: Alapjában véve nem sok új kódsort írtam C-ben, de webservice interface-eket elég sokat gyártottam C-ben készült DLL-ekhez. Illetve néha bele kellett módosítanom. Ezek után: bizonyos feladatokra állati jó, amúgy generikus alkalmazást nem fejlesztenék vele. ++

C#: Abszolút kedvenc. Nagyon jól ki lett szerintem találva, MSFT vonalon maradva nagyon komoly dolgokat meg lehet vele valósítani nagyon alacsony költséggel. Amíg a .NET adott, addig heterogén rendszerben is nagyon szépen helyt áll, mondom ezt a PInvoke elég kreatív használata után. :)

C++: n/k, sosem foglalkoztam vele komolyabban, valamire biztosan jó, üzleti aspektusból csak akkor választanám, ha explicit jobb, mint az alternatíva. Tehát akárcsak a C-t, kliensoldali alkalmazásfejlesztésre megint nem annyira.

Haskell, Erlang, Caml, ... (funkcionális nyelvek): n/a

Java: Sok jó tulajdonságon osztozik a C#-pal. Pro, hogy ökoszisztémán belül k*rva sok mindenből lehet választani. Kontra: ugyanaz, k*rva sok mindent kell ismerni, hogy az adott részfeladathoz a lehető legjobb eszközt válaszd.

JavaScript: n/k, általában csak az "áldásos" hatásával találkozom, amikor pl. a pure JS-ben íródott "enterprise" vagy "webkettő" fos alatt izzad a gép. Pedig nem, nem tartozom kifejezetten azok közé, akiket zavar, hogy egyre több kraft kell a gépbe.

Perl: n/k, üzemeltető kollégák beszámolója szerint enélkül nem lenne élet, ha látom őket munka közben, hajlok arra, hogy ezt elhigyjem

PHP: Fuck that shit.

Python: n/a

Ruby: n/a

Ez kb. annyira értelmes kérdés, mint ez lenne: "Melyik a számodra legkevésbé kedves fűszer? "

Attól függ, mit főzök.

-----------------
-activer
document.write(new Date().getFullYear()+1) will be the year of Linux on the desktop!

Nem. Attol, mert valamit muszaj hasznalni, mert azzal lesz hatekony a megoldas, meg nem biztos, hogy szeretem is. Ha olyanoknak fozok, akik szeretik az erospaprikat, teszek bele, de nem vagyok koteles szeretni az ilyen fuszerezesu etelt.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Főleg ha grízes tésztát csinálsz, lekvárral. Akárhogy szeretik páran az erőspaprikát nem abba való. Azaz feladathoz az eszköz elvet illik követni, nem pedig epoxiból trabantfőtengelyt csinálni, ahogy ez anno a Fábry showban elhangzott...
- - - - - - -
A nagy tudású uraknak felhívnám a figyelmét arra, hogy a Windows ugyan sok mindenre nagyon jó, de Linuxnak speciel nagyon szar.
"http://hup.hu/node/111669#comment-1419622">csfeco

Amelyikre a legkevesebb szavazat fog érkezni, meg fogom tanulni :)

PHP - a következetlenségei miatt, meg mert az összes többi nyelvre ki tudok találni valamit amiben az határozottan jobb mint a többi, egy niche-t. A php semibben sem jobb határozottan mint mondjuk a python/ruby/perl hármas.

A többire mondjuk, tényleg csak 1-2 dolog amiben vezetnek a többihez képest:
c - hardverközeli, könnyebben tanulható mint a c++

c++ - hardverközeli, de az összes létező zero vagy minimal overhead absztrakció rendelkezésre áll

c# - MS környezet

java - hordozhatóság (és azon belül közel natív sebesség)

funkc. nyelvek - parallel és konkurens programozás

Js - kliens oldali web

python - olvashatóság (de scientific computingban is versenyben van talán)

ruby - nagyon tömör, nagyon OO(következetesen), kifejezőkèpes de még jól olvasható

perl - amire eredetileg kitalálták (shell++, sed++ , awk++) ott még mindig talán a legkézenfekvőbb választás annak aki ért hozzá

"a vas maga vonja magához az embert" (Homérosz: Odüsszeia)

Azért nekem ezek némileg önkényes határoknak tűnnek, előbb utóbb minden fejlesztő belefut majd valamibe amit C++-os módon könnyebben megoldhatónak tűnik. És jönnek a viták: "Akkor már miért tilos más generikus adatszerkezet?", "Miért ne lehetne függvényt tenni egy structba ahelyett globális függvényt használsz ugyanarra?", "Akkor már miért ne hívjuk classnak?", "Miért ne írhatnál saját generikus adatszerkezetet?", "Miért ne használhatnál destruktorokat?", "Miért ne smart pointer?", stb...

Egy több fős fejlesztésben hogy képzelnél betartatni bármilyen ilyesmi korlátot?

Mondjuk te valamilyen coding guideline diktátor lennél - kellő hatalommal - hogy leverd a lázadó csoportokat?

Az ilyesmi vége a gyakorlatban egy valahogy magától fokozatosan kialakuló "stílus" (résztvevő emberek vitái, kvalitásai, meggyőződései, rendelkezésre álló eszközei alapján) hogy végül mit is használnak, de amit végül nem akarnak használni az is egyszer csak átcsúszik itt ott a code review-en, és már használják is. A végeredmény meg az egységesség hiánya.

Szóval végül egy c++ project lesz a végeredmény, amihez már c++ fejlesztőket kell majd alkalmazni - és még ők sem fogják tudni rendbe tenni azt, amit még a régi C fejlesztők kezdtek el, kiindulásként "de csak majd Vector-t használunk" mentalitással ;)

Szóval akkor már szerintem inkább "valódi" C++ projektet kell indtani, tapasztalt c++ fejlesztőkkel.

Egyebre szavaztam a Visual Basic miatt, bar az obj-C es a C# is magasan van a listan.
Java nem tartozik a kedvenceim koze, de az Android SDK nagyon kenyelmes, ugyhogy kezdem megszeretni.

--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.

Mi a baj a VB-vel? Pontosabban, melyik VB-vel van bajod, VBA, VB6 vagy VB.NET? Az elso ketto valoban kisse szerencsetlen volt, de az ujabb VB.NET-ekben dicseretesen sok fejlesztes van, egeszen hasznalhato szintet ut meg.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Pythonra negativ velemenyt adni nem nagy gyakorlatra vall (Pythonban).

Kb. sokan programolnak (igy l-lel) mindenben, de attol meg nem ertenek semmilyen nyelvhez sem alapvetoen.

Stroustrup megmondta, hogy Python nelkul nincs _elet_, sokan masok meg azt, 5-10x gyorsabban lehet vele haladni.

Behuzassal kapcsolatos baromsagok meg olyanok, mint a monospace-ben lehet csak igazan jo programolni, kozben meg Stroustrup ota biztosan tudjuk, hogy proporcionalisan szep az elet.

De ez utobbi pont arrol szol, hogy legtobben beszopnak valamit az elejen, onnantol meg kb. nem tudjak kimosni a szajukat.

De kb. igy jo a vilag, mert mi lenne akkor, ha mindenki jol haladna?

pl ilyenek: https://lwn.net/Articles/590299/ (regebben olvastam egy hosszabb cikket rola, ahol rendesen le volt irva hogy hogyan hisztiznek egymassal a pythonos 'nagy emberek', folyamatosan keresztbe teve egymasnak)
amikor egy bugbol feature-t csinalnak, mert annyira broken az egesz hogy egyszerubb ugy hagyni mint megcsinalni :)

a 'helyen erzem' az, ami nalam mindig is hianyzott pythonnal, pont az ellenkezojet erzem
adott egy egyebkent jo otleteken alapulo modern nyelv, amit egy rakas rossz dontessel tonkrevagnak
pl. az is szimplan egy rossz dontes, hogy a space-t es tabot engedi keverni, emiatt kb. biztos hogy egy ilyen file sehol nem fog normalisan mukodni. Mindezt meg lehetett volna elozni azzal, ha kijelentik hogy egy file-on belul csak az egyik karaktert fogadja el behuzasra. Vagy akar nyelvszinten kikotni hogy az indentalas az csak tab (vagy csak space) es kesz...

vagy ott van pl. a hulye metodusdefinicio: a definicional kiirsz mondjuk 3 parametert, amit viszont csak kettovel hivsz meg, mert az elsot azt 'ki kell irni' de amugy a hivasnal mar nem hasznalod... ez is siman egy hulye dontes eredmenye, es aki mondjuk pythonnal ismerkedik eloszor, annal elkepzelem milyen zavart okoz hogy 'de hat miert 2 parameterrel hivom meg, mikor 3 van neki?'

vagy ott a kompatibilitas: elvileg remekul kompatibilis, a gyakorlatban nem egyszer fordult mar elo, hogy a python 2.4.X-re irt kod a python 2.4.Y-on nem mukodott (de gyakran meg a 2.4.X-en sem egy masik gepen), mindenfele rejtelyes syntax errorokra hivatkozva

es eleg sok hasonlo problemam van vele (mikor tobbet kodoltam pythonban, akkor naponta 4-5 hasonloba futottam bele, azota komoly munkaval sikerult ezeket elfelejtenem es nyugodtabb, bekesebb eletet elek :D)

Es ahogy mondtam, mindez nem is erdekelne ha a nyelv amugy szar lenne. A PHP-nal nem duhit hogy milyen, mert az ugy szar ahogy van es kesz... De a Pythonban rengeteg jo otlet es feature van, es lehetne egy baromi jo nyelv, ezert elkeserito hogy ilyen hulyesegekkel van tele :( persze aki megszokta, annak ez termeszetes, es mar fel sem tunik, de masik nyelvek felol erkezve ez tenyleg ki tudja verni az ember szemet (meg a biztositekot)

Köszi a korrekt választ. A linket is köszönöm, lemaradtam róla.

az is szimplan egy rossz dontes, hogy a space-t es tabot engedi keverni

Én ezt egy választási lehetőségnek tekintem. Céges környezetben remélhetőleg mindenhol:D van valami policy, hogy milyen irányelveket kövessünk. Na meg egy nagyobb projekt mellé nem árt egy style guide csatolása. Viszont én azt vettem észre, hogy akik komolyabban pythonoznak, ott betartják a 4 spacet, mint általános ajánlást.

vagy ott van pl. a hulye metodusdefinicio: a definicional kiirsz mondjuk 3 parametert, amit viszont csak kettovel hivsz meg...es aki mondjuk pythonnal ismerkedik eloszor, annal elkepzelem milyen zavart okoz

Gondolom a self nevű változóra/paraméterre/objektumra gondolsz. Pythonnal ismerkedő olvasson utána. :)

Igen, a ceges policy jo es szukseges, es ha mindenki betartja, akkor legalabb adott cegen belul nem merul fel a problema.
Viszont ha a nyelv egyik tervezesi alapelvet company policyvel kell workaroundolni, az szerintem rossz. Ezt meg lehetne (lehetett volna) annyival oldani, hogy nem azt mondjuk hogy "space es tab" hanem mondjuk "tab". Vagy space, aminel meg darabszamot sem kell kikotni. De meg az is jo lenne, ha azt mondana a fordito hogy lehet akar space akar tab, de egy adott forrasfile-on belul csak az egyik. Igy megmaradna a dontes a company policyben hogy melyik legyen, megsem allna elo az hogy az egyik gepen jo az indentalas, a masikon meg mar nem.

Par evvel ezelott mikor az akkori projectunkon is kellett kicsit Pythonozni, tobbszor elofordult hogy megszokasbol indentaltam (meg pl. vimben nem volt bekapcsolva hogy tab-bol space-t konvertaljon), es a szovegszerkesztoben szemre jol nezett ki, az en gepemen jol mukodott, de mikor masik gepen teszteltuk akkor meg elhasalt, mert ott eppen nem annyi space-bol allt a tab...

Meg most eszembe jutott egy masik erdekes vonas: elofordult parszor hogy mas nyelveknel kialakult reflexbol pontosvesszot raktam a sor vegere (ez nyilvan az en balfeksegem, ezt abszolut vallalom), es nem vettem eszre, mert tesztelesnel pont nem futottunk bele abba az agba, aztan egyszer napokkal kesobb mikor mashol meg igen, akkor dobalta a runtime errorokat... (bar ha jol emlekszem, lehet alapbol .pyc-t csinalni, ami a teljes file-t ellenorzi, igy az ilyenek kiszurhetok, eleg homalyosak mar az akkori emlekeim). Ez pl. Perl-nel ugy mukodik, hogy mikor elinditod a scriptet akkor az egeszen beparse-olja, ha valahol syntax error van akkor hibat dob es megall.

"Gondolom a self nevű változóra/paraméterre/objektumra gondolsz."
Arra bizony :) Ez is eleg ertelmetlennek tunik, mert ertem en hogy igy 'rugalmasabb' mint mondjuk a C++ -nal a fix 'this' pointer, de szerintem sokkal zavarobb is a kovetkezetlenseg.

Egyebkent kicsit visszaterve indentalas temakorre: en abszolut TAB-parti vagyok, azon egyszeru oknal fogva hogy az mindenkinel ugy nez ki, ahogy neki jobban tetszik. Ha valaki a suru kodot szereti akkor beallitja 2 space-nyire, aki a szellos, jol lathato behuzasokat az meg 4-re vagy akar 8-ra, es a kod maga ettol meg nem valtozik.
Nalunk a company policy pl. fixen 2 space, ami szerintem baromi ronda :D

a pythonhoz kepest mindenkepp, kicsit feljebb irtam is a Rubyrol: http://hup.hu/szavazasok/20140504/melyik_a_szamodra_legkevesbe_kedves_p…

egyebkent en scriptnyelvek kozul a Perlt szeretem (nem tartom hibatlannak, es plane nem minden helyzetben mindenre jonak, sot sok vonasa nem tetszik, de bizonyos tipusu feladatokra baromi hatekony, )

nekem annyira nem tetszett az indoklás. Rendszer api szinten konzekvensen kell(ene) tartani az elnevezéseket. Hogy most valami property (.length) vagy függvény (.length())
vagy size, vagy akármi, de legalább az alapkönyvtárban legyen már egységes. Hogy a felhasználó a saját kis könyvtárában hogyan nehezíti meg az életét, az szerintem
egy teljesen más tészta.

Kar, hogy a Python tanulasi gorbeje meg tul meredek.

'''Rendszer api szinten konzekvensen kell(ene) tartani az elnevezéseket.'''
Oh man! (bocsanat!)
Szerintem meg minden a kompromisszumok korul dol el egy jo nyelv megalkotasakor; az ido (kor) meg ugyis majd kozbe szol (ez nem vers).
Akkor meg?

Olyan, hogy tokeletes nyelv nincs; tehat kinek van igaza?

A Python egyetlen nagy problemaja az, hogy nem teljesen OOP. Olyan, mintha eredetileg modularis szeretett volna lenni, aztan kesobb beleeroszakoltak az osztalyokat meg az oroklodest, kilognak a sorbol. Raadasul nem is kovetkezetesen OOP, a primitiv konstrukciok (tombok, stringek, szamok) nem objektumok, es ez nagyon meg tudja kavarni azt, aki egy normalis OOP vilagbol jon (Java, Ruby, you name it).
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

szerintem probaljunk mar megmaradni a kulturalt vitanal :)
ha ugy gondolod nincs igaza, akkor ird le hogy szerinted miben es miert, de ne intezzuk mar el annyival hogy "marhasag" meg "oh man", mert ez a "csak"-kal meg a "mert en azt mondtam"-mal egy szinten levo "erv"

legalabbis en kivancsi vagyok hogy a nyelvet nalam jobban ismerok milyen erveket sorakoztatnak fel egyik vagy masik oldalon

Szerintem meg az a kulturalt, ha valamihez nem ertek, akkor befogom a szamat.

A kollegad kurva okosnak gondolja magat pl. Pythonban, mikozben tudja magarol, hogy amit gondol, azt nem tudja, csak __elkepzelt__ (igy pythonosan) valamit; most pont nem jott be neki a mano vagyok, kb. ennyi tortent.

pl azt hogy "de igen, azok, tessek itt egy PELDA"
vagy az hogy "valoban nem azok, es ez igy tenyleg nem jo"
vagy "valoban nem azok, DE ez igy szerintem jo, MERT"

gyanitom az utolso kettobol kene ebben az esetben valasztani
de ne kelljen mar azt is elmagyarazni hogy mit jelent a kulturalt, konstruktiv vita...
sajna a Python is olyan mint az Apple, sokan teljesen fanatikusok, semmifele ervelesre nem kepesek csak hisztiznek ha valaki rosszat mond a szerelmukre (es mielott meg megkopkodnetek: en is hasznalok Apple-termeket, teljes megelegedettseggel, de fanatizmus meg hiszti nelkul)

Ha már nem a vita kedvéért, de értünk, akik nem értenek a Pythonhoz túlságosan, nem lehetne picit tényleg konstruktívabban?:) Speciel én most tök nem tudom eldönteni, hogy kinek van igaza és miért.

Számomra azért is érdekes ez, mert sokat vaciláltam a Python és a Ruby közt általános script-nyelvnek megtanulni, és végülis a Ruby mellett kötöttem ki. Mondjuk itt csak az alap benyomások voltak mérvadóak számomra, nem tetszett a Pythonos szívás a 2-3 váltással, meg a pip install is nehézkes volt így picit, Ruby ennél picit felhasználóbarátabbnak tűnt elsőre.

ooo... koszonom (blush) :D
de nem volt celom "jo arc"-nak lenni, pusztan remeltem hogy vegre kibontakozik elottem egy konstruktiv vita, amibol megertem a ket oldal allaspontjat, es netan meg tanulok is valami ujat es erdekeset

de eddig csak az jott a "Python-vedo" oldalrol hogy "baromsag" meg "idiota" meg "oh man" meg "kurva okosnak gondolja magat", ezzel meg nem nagyon lehet mit kezdeni...

De igen, azok, tessék, még itt, a Ruby oldalán is írják, így a ruby-warrior-python-bashereknek sem kell égetniük magukat.

És nem vagyok Python-fan, egyszerűen a közmondásos, minden 0 skilles python tutorialban szereplő a "pythonban minden objektum" kinyilatkoztatással történő tagadása nem érvelő beszéd fogalmazására sarkallja az embert, hanem egy OMFG szintű beszólásra. (Egyébként a hozzászólás első része is elég zavaros, csak mindenki a már említett rész miatt bukott ki.)
_____________________________
Powered by 1,3,7-trimetilxantin

na latod, ugye hogy lehet normalis valaszt adni, jelen esetben pl. azt hogy "de igen, objektumok azok is" :)

bar szerintem a linkelt cikkben nem irjak azt, hogy pl. a tomb vagy a string is objektum, az "everything is an object" ertheto siman alapelvnek is (lasd: "a Linuxban minden file" de pl. az ablak fejlece az nem file)

de akkor most mar tisztazzuk, mert tenyleg erdekel :)
szoval a pythonban pl. a string literal az egy object? mert Rubyban pl. igen, tehat ott mondhatod hogy "text".center(15), mert maga a string literal is egy object
(maga a valtozo amibe beleraksz egy tombot vagy stringet, mar nyilvan a Pythonban is objektum lesz, ez tiszta sor)

nem tudom hogy eredetileg hrgy84 erre gondolt-e, ha nem, akkor remeljuk jar meg erre es leirja hogy akkor mire :)
a hozzaszolas elso fele meg talan arra vonatkozik, hogy gyakran nem OOP modon kell/lehet kezelni az objektumokat (pl. a len es hasonlok esete)


>>> -4.__abs__()
File "", line 1
-4.__abs__()
^
SyntaxError: invalid syntax
>>> int(-4).__abs__()
4

>>> help ("krixkrax")
no Python documentation found for 'krixkrax'

vagyis ugy tunik, a literal az valoban nem object a pythonban (amivel mondjuk nekem szemely szerint nincs bajom, bar filozofiailag "szebb" a Ruby megoldasa, ahol az, es helyenkent kimondottan hasznos is tud lenni )
egyebkent ez a dupla alahuzogatas a masik amitol hulyet tudok kapni, hogy lehet osztalymetodusokat __nev__ modon kitalalni a standard libben? :S

illetve:

int(-4).__abs__() es nem int(-4).abs()
de
abs(4) es nem __abs__(-4)

vagy:


>>> str("abcdef").__contains__("d")
True
>>> str("abcdef").find("d")
3

tobbek kozott ezekre is gondoltam mikor kaoszrol meg logikatlansagokrol irtam...

Igaz, a help nem működik mindennel, erre nem gondoltam, de ennek elég sok oka lehet, ennyire mélyen nem ismerem - pont a str egy olyan osztály, amivel sohasem próbáltam.
Ettől függetlenül a legtöbb tutorial úgy kezd, hogy a pythonban minden objektum.

Az ilyen: __név__ formátumú nevekkel kapcsolatban ajánlom figyelmedbe a python doksit!

ok, a helpes resz nem annyira lenyeg, vegul is megtalaltam amit kerestem (talan a help(str) volt az)

a linkelt doksi meg baromi hosszu, vegigolvasni biztos nem fogom (gyorsan atfutottam, de nem talaltam benne meg a valaszt/indoklast, bar tippem van hogy mi lehet)
de ha esetleg megmondod hogy melyik fejezetben van, akkor azt elolvasom :)

https://docs.python.org/3.4/library/stdtypes.html#text-sequence-type-str

>>> from string import Template
>>> s = Template('$who likes $what')
>>> s.substitute(who='doc', what='Perl')
'doc likes Perl'
>>> s.substitute(who='hrgy84', what='Ruby')
'hrgy84 likes Ruby'
_____________________________
Powered by 1,3,7-trimetilxantin

ezaz, koszi :D
basszus az elobb pedig tutira probaltam igy kicsikarni belole valamit (bar lehet hogy csak a numeric literal-nal ragadtam le, kicsit szejjel vagyok mar igy hetfo delutan :-/)

szoval akkor a string literal is ojjektum, alakul :)
de ha az, akkor a szamok miert nem?

na rajottem, tulajdonkeppen azok is azok, csak 'nem annyira' mint Rubyban :D


>>> 6.__abs__()
File "", line 1
6.__abs__()
^
SyntaxError: invalid syntax
>>> (6).__abs__()
6

(-4).__abs__()

Így működik, de bevallom, ezt a részét már én sem értem.
A dir, a help, a type mind azt mondják, hogy int típusú objektum a numerikus konstans.
Viszont ha egy (numerikus) konstans osztályához tartozó metódusra hivatkozom, akkor máris syntax error az eredmény.

Ahogy azt sem értem, ha már itt tartunk, hogy miért tér el a dir((4)) és a dir((4,5)) kimenete.
Hiszen _elméletileg_ mindkettő lista.

igen, pont ezt irtam kettovel feljebb :)

a tobbihez (a miertekhez) nem nagyon tudok hozzaszolni, en mar regota nem probalok logikat keresni abban hogy miert mukodik vagy nem mukodik a pythonban valami ugy ahogy... mivel kb. 2-3 evente egyszer kell pythonhoz nyulnom, ez nem okoz nagy problemat :D

de ha mar...
a dir((4)) az mitol lista? ilyen erovel a (-4).__abs__() -ben is lista kene hogy legyen a (-4), nem? gondolom az alapjan donti el hogy lista-e, hogy van-e benne felsorolas (ami eleg logikus, hiszen miert lenne lista mondjuk a 2 * (3 + 4) - ben a (3+4)? )

Úgy tudom a parsere ilyen (buta) vagyis a szintaxis úgy van definiálva hogy a pont utáni szöveg már nem befolyásolhatja lebegőpontos szám vagy metódushívás jön, azaz nem kell lookahead a parserba - mire a pont jön a dolog eldőlt.

szerk.: A zárójel meg egy aritmetikai kifejezés zárójele, semmi extra. (-4).__abs__() vagy pl. ((5 - 2) * (1 - 15)).__abs__(). Viszont lezárja a -4 parsolását ami így egyértelműen egy egész.

Ok, a személyes információid alapján látom hogy miért nem: az 1 mint számjegy és az l mint László karakterekkel játszottam.

Ha a locale befolyásolná egy nyelv szintaxisát az szörnyű lenne: bad design. Az excelnél is összerezzenek tőle valahányszor szembe jön a jelenség.

Félreértesz: a kiírt szövegben annyira feltűnő, hogy a pont után nem számjegy áll, hogy képtelenség nem észrevenni az eltérést. (no meg ki ad numerikus karakterrel kezdődő nevet egy metódusnak?)

Locale... hm. Excelék nem tudnak róla, mert ott még a függvények nevét is befolyásolja, ha jól tudom. ;)
(lehet, hogy hülyén fogalmaztam: a kiírt számokra gondoltam elsődlegesen. Ott sem használ vesszőt a tizedespont helyett)

Mint írtam karakterkészlet függvénye. Microsoft (meg gondolom egyéb) termékkulcsokban sincs 1, l, O, 0, I stb.. bizonyos országokban rendszámban se.

A kiírtnál több a játéktér. De ott is mondhatja valaki, hogy a standard input függvényektől elvárja hogy locale-tól függetlenül - feltétel nélkül - mindig beparsoljon egy számot amit valaki a standard output függvénnyel írt ki - és az ezen felüli igényekre meg használható valami explicit pretty print könyvtár.

szerk: csak eszembe jutott erről - érdemes utánaolvasni a lebegőpontos számkiíró/beolvasó algoritmusoknak, ott pl. explicit követelmény általában hogy többszöri kiírás és visszaolvasási ciklus után minél kevésbé (vagy ne) divergáljon az érték, kb. ez az egyik fő fokmérője a algoritmusok "helyességének" (dragon4, grisu3, stb...)

Ez a megoldás (parser ilyentén segítése), meg a __név__ típusú metódus nevek meg a több soros komment hiánya mind szönyeg alá söprése a problémának. Nyilván semmi sem tökéletes, de ezek a gépet segítik a humán helyett, és ez nem jó írány szerintem.

Szerintem úgy működik, hogy attól függően hogy már alapból milyen jóra tervezték, ettől fog függeni hogy milyen későn siklik ki a vonat és kell elkezdeni hack-elni, mert már nem éri meg / lehet át tervezni, mert olyan mélységű kellene legyen az átalakítás.

PL/1
Amikor utoljára használtam, akkor lyukkártyán lehetett leadni az operátornak futtatásra az R20-as gépen, és legkorábban is csak másnapra volt meg a batch eredménye :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Csak ha jól emlékszem, pár évvel öregebb vagy nálam. :)
R gépből volt sok az országban, de az R20 már akkor is öregnek számított, amikor a suli megkapta.
22-es, 35-ös, 40-es volt sok és én még láttam az ország utolsó R gépét, egy R57-est (??? a szám nem biztos) működgetni. :)

Ermefeldobassal dontottem el hogy a Perlre vagy a haskell/funkcionalis nyelvekre menjen. Mindket write-only nyelv hanyingerkeltoen sok fejfajast tud okozni ha hozza kell nyulni, akik szeretik azok pedig szeretik elfelejteni, hogy nem eleg a programot sokszor csak ugy egyszer megirni. Meg mar onmagaban aki par karakternel hosszabb regexpet ir kommentben jelzett pelda es helyi gyors leiras nelkul, azt is 10 evre eltiltanam a szakmatol.

Funkc. nyelvben ott lehet félremenni hogyha az ember nem nevez el elég sok dolgot, pl.. több soros függvényeket pakol össze let vagy where blokk nélkül ahol értelmes neveket ad a részeknek.

Amit viszont mindig a javára lehet írni a megértésnél, az az hogy garantáltan nincs állapot:

egy pure function önmagában egy megérthető, szeparált egység - nem kell közben az egész programot szem előtt tartani, nem kell az "idő"-re gondolni hogy mikor mi történhet, csak a konkrét transzformációt kell megérteni az adott függvény bemenete és kimenete között.

FoxPro nincs a listában, se a jó öreg Fortran.
Mindkettővel volt kisebb dolgom.

PHP-ra szavaztam, mert egy átgondolatlan, össze-vissza tódozott-foltozott, önmagával is inkonzisztens, rossz szokásokat fejlesztő gányhalmaz. Jah és persze ez nem a nyelv hibája, de mégis elárúl valamit ;)

Aki a Java -ra szavazott ide megindokolhatja, de légyszi szorítkozzunk a language levelre, ahogy a kiírás is szerepel (tehát a "lassú a java" című közmondás nem ér)

--
arch,xubuntu,debian,windows,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Elsutom, mert ugyis el fogjak: lassu a java!!!!4negy!

Nyelvi szinten ami nekem nagyon hianyzott eddig, az a kulturalt anonim fuggvenyek (ez most talan megoldodik a lambda kifejezesekkel), illetve nekem nagyon hianyzik a [] / []= operator a map-szeru objektumok eseteben, a get/put nem eleg vicces ehhez.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

A Map['string']-es résszel egyetértek, iszonyú rossz mindig leírni minden kilométer hosszú metódusnevet, ellenben az anonim függvények más nyelveken is a kárhozat útjai, fúj. Javascriptben pl. debuggoláskor jobb ha látsz egy függvénynevet, ennek ellenére sok barom inkább anonim függvényt csinál, mert a nyelv megengedi.

A linkelt oldalon azt allitja a szerzo, hogy "A Java benchmarkon lehet ugyanolyan gyors, mint a C++, de a valo eletben nem".
Ugyhogy akkor vegyunk egy peldat a valo eletbol: a Disruptor opensource java libet fejleszto ceg a kovetkezoket irja:
"LMAX aims to be the fastest trading platform in the world. Clearly, in order to achieve this we needed to do something special to achieve very low-latency and high-throughput with our Java platform. Performance testing showed that using queues to pass data between stages of the system was introducing latency, so we focused on optimising this area."

Nem minden haladt ám olyan sokat azóta, generics pl. már rég van de az 1. pontra (value types) még csak proposal született 1 hónapja: http://cr.openjdk.java.net/~jrose/values/values-0.html

" If, on the other hand, we could represent a Point in the same manner we do an int, we could store them in registers, push them on the stack, iterate through an array with locality, and use far less memory, with no loss of encapsulation."

Nagyszerű... és? Kevés use-case az, ahol ez igazán nagy előnyt adna, ahol igen, ott meg DalvikVM van és Android. Nincs olyan nyelv, ami mindenben jobb, mint egy másik, pláne hogy itt összemosódik a nyelv és a platform fogalma.

Tehát például van-e értelme egy register-based VM-et összehasonlítani egy stack-based VM-el, miközben ugyanarról a forrásnyelvről beszélünk, amely bytecode-ra vagy dex-re fordulva teljesen más módon fut.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"összemosódik a nyelv és a platform fogalma"

De hát erről szól az eredeti post, illetve a jdk proposal is, hogy maga a NYELV nem ad lehetőséget bizonyos platformszintű optimalizációkra.

Ha nehéz is megérteni egy Visual Basices arc cikkeit, köpködni még megy nemde? ;)

hint: A fikázás helyett, eleve írhattál volna ennyit: hogy Java magas szintű nyelv, szarunk a platformra, nem kell elcsúfítani mindennel mint a C++-t, pár ms nyereségért! ÉS kész. Ez egy értelmes komment lett volna.

"De hát erről szól az eredeti post, illetve a jdk proposal is, hogy maga a NYELV nem ad lehetőséget bizonyos platformszintű optimalizációkra."

Attól függ, mit értesz platformon és azon, hogy a nyelv miért nem ad lehetőséget ilyesmire és hogy ezt hol olvastad egészen pontosan... a hivatkozott cikkben ugyanis csak JDK-ról van szó, és ott is a __ jel inkább egy hint a fordítónak, hogy más struktúrát készítsen, de ez eldönthető lehet hint nélkül is és akár futásidőben is...

Hozzátenném, hogy a DalvikVM az nem bytecode-ot kap, hanem dalvik executable formátumot, tehát egyáltalán nem érintett abban a megoldásban, ami le van írva.

"Ha nehéz is megérteni egy Visual Basices arc cikkeit, köpködni még megy nemde? ;)"

Megértettem, de látszólag Te nem érted a Java nyelvet, a platformot, az ecosystem-et és a futtatókörnyezetet, ahogy a VB-s arc se igazán.

"A fikázás helyett, eleve írhattál volna ennyit: hogy Java magas szintű nyelv, szarunk a platformra, nem kell elcsúfítani mindennel mint a C++-t, pár ms nyereségért! ÉS kész. Ez egy értelmes komment lett volna."

Megvan mindennek a helye és ideje. Lehet köpködni például a GC-t, hogy több memóriát igényel, mintha minden esetben a fejlesztő lekezelné a memória foglalást és felszabadítást, de cserébe csak igen erős ráutaló magatartással tudsz olyan hibát ejteni, mint a Heartbleed vagy a memóriaszivárgás...

...egyszerűen csak arra akartam rámutatni, hogy fura 2014-ben egy Java-val messziről találkozó blogszerző 2004 előtti írását lobogtatva egy IT megoldásról vitázni, ahol egy éven belül változnak a dolgok, nemhogy egy évtized távlatban...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"de ez eldönthető lehet hint nélkül is és akár futásidőben is"
Erre írják Guy Steele-ék, hogy: "Despite significant attempts, JVMs are still poor at figuring out whether an object’s identity is significant to the program, and so must pessimistically support identity for many objects that don’t need it"

Tehát a gyakorlatban nem megy jól.

"nemhogy egy évtized távlatban"

Én meg pont azt írtam, hogy ez a value typeos felvetés nem változott semmit. Ma is érvényes.

"DalvikVM ... tehát egyáltalán nem érintett abban a megoldásban, ami le van írva"

Azaz ott tehát előfordulhat, hogy még tíz év benne lesz ebben az optimalizációban ha egyáltalán valaha megvalósul. Na, te tudsz ilyen időtálló rant-et írni? ;)

"Tehát a gyakorlatban nem megy jól."

Most akkor proposal vagy proof-of-concept? Aztán meg a GC-ről is ezt mondták eleinte...

"Én meg pont azt írtam, hogy ez a value typeos felvetés nem változott semmit. Ma is érvényes."

Nagyszerű... leszámítva azt, hogy ez nem nyelvi sajátosság, hanem platform tulajdonság és egyetlen egy VM implementációról írsz, holott van néhány... tisztázzuk már a fogalmakat és azt is, hogy mi a bajod alapvetően. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"és egyetlen egy VM implementációról írsz, holott van néhány"

Ok, akkor ha hozol példát arra (forrással) ahol ezt az optimalizációt jól megcsinálták, elhiszem hogy nem VB-s fickónak van igaza és a Java nyelv önmagában nem akadálya, hogy az egyszerű value typeokat 0 byte memory overheaddel kezeljék.

Ha maguk a Java nyelv közelében molyoló nagy nevek is azt mondják, hogy nyelvi kiegészítés nélkül nem megy ez jól automatikusan (VB-s csávóval együtt már négyen vannak), te meg hogy igen, akkor tényleg hozz már valami forrást rá kérlek!

"Ok, akkor ha hozol példát arra (forrással) ahol ezt az optimalizációt jól megcsinálták, elhiszem hogy nem VB-s fickónak van igaza és a Java nyelv önmagában nem akadálya, hogy az egyszerű value typeokat 0 byte memory overheaddel kezeljék."

Nem hozok példát, mert (jelenleg) nincs. Se erős igény, se implementáció.

Leírva meg az van, hogy "JVMs are still poor at figuring out", ami az én szegényes és gyenge ismereteim szerint nem azt jelenti, hogy nem lehetséges, de majd felveszem így a szótáramba, mert ezek szerint rosszul értelmeztem.

"Ha maguk a Java nyelv közelében molyoló nagy nevek is azt mondják, hogy nyelvi kiegészítés nélkül nem megy ez jól automatikusan (VB-s csávóval együtt már négyen vannak), te meg hogy igen, akkor tényleg hozz már valami forrást rá kérlek!"

Hhh... tudod mit? Igazad van. Szar a Java, hagyjuk.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Hhh... tudod mit? Igazad van. Szar a Java, hagyjuk."

Nem, csak ebben a felvetésben pl. igaza volt az általad lesajnált cikknek.

Mondhatnánk, hogy nem lényeges az a felvetés és nincs rá igény, de a fő JVM implementáció körül dolgozó emberek is foglalkoznak a kérdéssel (erre hoztam egy friss cikket). Tehát van akiknek lényeges!

Csak arra akartam felhívni a figyelmed, hogy a nagy hangú fikázás mögött nincs is semmi. Persze tartalmi kritikát nem is írtál - de most hogy kikényszerítettem tartalmi vitát az egyik pontról, kiderült a VB-s srácnak tizenX éve igaza van. Csomó ilyen Java fanboy van, ha kritizálják a JAvat a válaszuk csak annyi, "áááá hülye vagy, nem értesz a Javahoz", aztán végül kiderül h. talán még a kritikát se értik, amikor elmagyarázzák nekik akkor jön a: "jaa de az számomra nem is lényeges" vonal - persze mert korábban még nem is halottak a problémáról nem is értették, hogyan bánthatná őket. Szépen illeszkedsz a típusba. ;)

Évekkel ezelőtt megfogadtam, hogy nem kezdek bele parttalan vitákba, ahol órákon vagy napokon át rágódunk egy végtelenített szálon át nehézkesen szóról-szóra lépve előre (például abban, hogy mi a filozófiai különbség a "nem lehet" és a "are still poor at figuring out" kifejezések között), hogy aztán a végén mindenki azzal hagyja abba, hogy most aztán jó megmondta a másiknak, a közönség már rég nem olvassa, csak átlapozza, aztán másnap, egy hét múlva vagy egy hónap múlva másvalakivel lehet elölről kezdeni az egészet egy másik fórum másik hozzászólásában.

Ezért inkább azt mondom, hogy igazad van, ha (meg)érted, ha nem. Én meg szarok rá, és így sokkal jobb mindenkinek. Ezt a permalinket meg elteszem és legközelebb csak belinkelem, ha hasonló szituációba kerülök.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ok. Értelek. Lehet, hogy elméletileg nincs lassú nyelv csak rossz fordító (mert gondoljunk pl egy okos emberi fordítóra - az akár a naív bubble sortot is kicserélheti ekvivalens heapsortra, vagy akár egy turing gép progtamot is átírhat ekvivalens eredményt adó regiszteres gépi kódra)

De gyakorlatban meg a vitatott esetben a javahoz nincs az elméleti optimumot megközelítő megoldás : és ez jelentheti azt hogy ez az optimális elméleti fordító mégiscsak túlmutat a jelenlegi képességeinken, és mondjuk más nyelvek ebben jobban állhatnak - ilyen gyakorlati értelmben mondhatjuk hogy egy nyelv lassú

Csakhogy tudjárok van, aki olvassa ;) Abban igazad van, hogy a gyakorlatban nincs ilyen, abban pedig a Gábornak van igaza, hogy lehetséges lenne csak nincsen. De talán azért nincsen, mer tnincs is rá szükség. A JIT compiler finomhangolásával a teljesítménykritikus részeket szépen le lehet fordítani, és innentől az összehasonlítást is a natív kód, és a szignifikáns működésű másik kóddal kell elvégezni. A gyakorlat az, hogy vannak esetek, ahol mérhető gyorsulás van a C++al szemben, és vannak mások, ahol fordítva, az pedig még mindig igaz, hogy az esetek nagy százalékában az emberóra drágább mint a gépóra.

-
import groovy.transform.Immutable

"Lehet köpködni például a GC-t, hogy több memóriát igényel, mintha minden esetben a fejlesztő lekezelné a memória foglalást és felszabadítást, de cserébe csak igen erős ráutaló magatartással tudsz olyan hibát ejteni, mint a Heartbleed vagy a memóriaszivárgás..."

A Heartbleed nem inkább a range checking-en (ill. a hiányán) múlt? Az is optimális sebesség vs. biztonság kérdés, de nem ugyanaz, mint a gc.

Erlang. Amilyen bénán kezeli a *NIX signal-okat. Meg úgy tűnik állandóan inkompatibilis módon változik.

Perl, mert lavorba hanyok a regexektol.

Én a Perl-t nagyon szeretem, bizonyos feladatokat nagyon gyorsan és jól meg lehet benne oldani. Regex-elek benne ezerrel, hiszen ez az egyik oka, amiért használom. De attól még a hideg veríték kiver, akárhányszor el kell olvasnom egy regex-et, akár én írtam, akár nem.

Nyilván GUI-s progikat nem fogok Perlben írni, bár elvileg lehetne. OOP progikat is lehet elvileg Perlben írni, de köszönöm, abból sem kérek. A Perl egy strandpapucs, focipályára stoplis cipőt, erdőbe túracsukát veszek, de a Balcsi partra a strandpapucs a legtutkóbb.

Nalunk (reszben az en harcaimnak koszonhetoen) konvencionalisan meg van kotve hogy regexpet nagyon erosen kell kommentelni es peldakat is irni kell kore, hogy mit mive miert alakit (igy legalabb azt tudjuk, hogy mit kene annak a regex-el teli sornak csinalnia, mert sokszor az sem volt vilagos). Igy azert szerintem meg eppen van ertelme, de az ettol eltero modon hasznalt regexpekrol ugyanaz a velemenyunk Viktor ur. :)

Erre van egy válaszom, amit szerintem senki nem fog szeretni.

A unix-szerű rendszereken általában igaz, hogy kétféleképpen tudsz megoldani dolgokat:

- kevéssé hatékony, de jól átlátható elemi műveletekkel
- hatékony kriszkraszokkal.

Egy nagyon egyszerű példa:

cat patterns.txt |grep -v ^# |while read pattern
do
cat text.txt |grep $pattern
done |sort |uniq

vs.

grep -f <(grep -v ^# patterns.txt) text.txt |sort -u

Ha olvasni akarod őket, akkor így lehet olvasni őket. Első:

- kilistázom soronként a patterneket
- kiszedem közülük a kommenteket, csak a nem-kommentezett patternekkel foglalkozom tovább
- aztán mindegyik patternt egyesével megpróbálom megtalálni a szövegben
- a talált sorokat rendezem
- és végül mindegyik találatot csak egyszer kérem.

Második:

- WTF???

Cserébe az első O(n*m) futásidejű (lassú), a második meg O(m) futásidejű (gyorsabb).

Félreértés ne essék: nem azt mondom, hogy az első vagy a második helyesebb megoldása a problémának. Csak azt hiányolom, hogy az általam ismert rendszergazdák többsége nem próbálja tudatosan menedzselni ezt az olvashatóság vs. hatékonyság dolgot, hanem egyértelműen a hatékonyságot részesíti előnyben, gondolkodás nélkül. Van, amikor ez kell, de van, amikor összességében jobb lenne a másik...

Olvasgatva a hozzászólásokat, bennem felmerült a ruby is, mint egyike a "bottom ten"-nek. :)
Miért? Az általam látott doksik miatt. Valahol olvastam, hogy a fejlesztője szerint a forráskód a legjobb dokumentáció (hogy ez UL vagy tényleg mondott ilyet, azt nem tudom) és a kb. két éve nézegetett leírások finoman szólva hiányosak voltak.
Hogy azóta változtak-e a dolgok vagy sem, esetleg csak én kerestem rossz helyen... hát ezt nem tudom.

Ha jól látom ez egy flame generátor poszt, úgyhogy beszállok. JavaScript fikkantás még nincsen :-).

Nekem az benne a halálom, hogy olyan matematikai konstrukció-szerű az alapnyelv (minden objektum egy map), mintha nem programozó tervezte volna. Nincsen semmi láthatóság, jogosultság, névterek vagy bármi ami segítené a komponensek együttműködését. Ha nem írom ki hogy var, akkor egy globálist vágok felül, ami csak debuggolás árán derül ki. Semmi gyakorlati megfontolást nem látni a tervezésében.

Ha háború lenne, akkor küldenék az ellenségnek egy beépített ügynököt, hogy terjessze el az iparukban. Ezzel évekre vissza lehetne vetni a fejlődést.

Nem a nyelv, hanem a standard könyvtárak hibája, de alig látszik rajta valami nevezéktani logika. Meg az objektum-orientáltság is teljesen esetleges. De legalább van 1000 féle könyvtár, ami egy rétegbe beburkolja az alapmechanizmusokat, hogy kicsit értelmesebb és lassabb legyen.

Külön öröm látni, hogy mekkora erőfeszítéseket tesz az iparág a JavaScript interpreterek optimalizálásába - ami fából vaskarika a nyelv alapvető szerkezete miatt :-). Amit a JS-be beleöltek a programozók, azzal az erővel 10 értelmes programnyelvet is be lehetett volna integrálni a böngészőbe.

Korunk kudarcra determináltságának csimborasszója, hogy egyesek megpróbálták szerver-oldalon is bevetni. Ez azért nagyon jó, mert így a káosz kiterjedése nem kell, hogy megálljon a kliensen, és a sötét erők még nagyobb hatalomra tehetnek szert.

Az egyetlen előnye az, hogy kizárja a valódi threadinget, és így legalább szálkezelési hibákat nem lehet csinálni benne.

Üdítő volt olvasni, köszi! :)

Vicces különben hogy milyenek vagyunk. Gondolom a node.js meg hasonlók is azért születtek, mert a fejlesztő beleölt időt a JS-be, és persze kényelmesebb a meglévő tudást tovább bővíteni mint egy radikálisan új irányt felvenni. Illetve a másik amely sok helyen fellelhető, hogy ugye mindig kifizetődőbb az e-pénisz eredmény, ha új dolgot hoz létre, mintha beállna sokadiknak a sorba egy meglévő projekt mögé.

Ilyenek vagyunk, ez motivál és fékez minket. Felkapaszkodunk a tudáshoz, majd hagyjanak minket már békén, tanultunk már eleget. És ez az örökös oda vissza szül érdekes dolgokat.

Számomra megdöbbentő a jelenlegi sorrend igazából:

1. Java.
2. PHP
3. Funkcionális nyelvek

Komolyan, a Javával sok baj van, nade rosszabb mint a PHP!? Komolyan? Leesett az állam.
A funkcionális nyelvek meg aztán végképp nem értem, kinek ártottak. Ha valakinek nem inge, ne használja, de ettől még csak a vak nem látja, hogy érdemes ötleteket átvenni onnan és bármilyen nyelvben használni.

"A funkcionális nyelvek meg aztán végképp nem értem, kinek ártottak."

Csupán annyival, hogy egyes funkcprogosok szeretik a szent grálnak beállítani és minden más - jellemzően OO - nyelveket leírni a francba. (Aztán kiderül, hogy életükben nem készítettek egy szál (G)UI-t.)

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

Hát igazából nem akarok most belemenni Java elemezgetésébe, lehet szeretni, lehet nem szeretni, nekem annyira speciel nem áll kézre, de úgy azért alapvetően "egész jónak" tartom.
Nem így a php -vel. Azt egyáltalán nem értem, hogy lehet szeretni, vagy jobban szeretni mint a Java-t. Ez lett volna a mondandóm lényege.

+1
A fenti hozzászólásból azért sejteni, hogy nem a funkcionális nyelvekkel van a baj, hanem inkább valamilyen komplexusból fakadhat az ellenszenv. A fenti hozzászólásból az is látszik, hogy sokan azt hiszik, hogy vagy OO vagy FP, mintha ezek kizárnák egymást.

Pár példa, hogy mi lehet a háttérben:
- A "funkcprogosok szeretik a szent grálnak beállítani és minden más - jellemzően OO - nyelveket leírni a francba", ezért utálom a funkcionális nyelveket!
- Csak száraz algoritmusokat lehet vele kódolni (pl. fibonacci), GUI-ra teljes alkalmatlan, vesszen!
- Hú, ez nagyon bonyolult, tán egy kis matematika is kell hozzá, le vele!
- Nem tudom mi az, de sok rosszat hallottam róla, pusztuljon!
- Már a 60-as, 70-es években is használták, így nagyon elavult lehet, ne is lássak még csak szavazást se róla!
- FP-ben csak olvashatatlan és érthetetlen dolgokat lehet csinálni, miért nem törli el már végre valaki ezeket?

+1
Én mondjuk az állítólag öntökönlövésvilágbajnok C++ helyét sem értem.
Válogatott egy közönség ez. :)

A funkcionálisakkal szembeni sztereotípiák meg talán enyhülni fognak, ha felnő egy "harmadik generációs" lisp, meg "első/második generációs" haskell nemzedék. :)

+1
Annyival egészíteném ki, hogy a CC az FP-nél is alapvető követelmény.
A CC ilyesmi:
- Minél több kis függvény (osztály), egy nagy helyett.
- Minél kevesebb paraméter egy függvénynél (metódusnál)
- DRY (Ne ismételd magad)
- Jól érthető elnevezések
- Egy függvény (metódus) egy dolgot végezzen

A megfejtés nyilvánvalóan az, hogy a szavazás nem a nyelvek minőségéről(rosszaságáról) szól, hanem a nyelvekkel kapcsolatos (un)szimpátiáról. Nem autós hasonlattal: vannak itt a hup-un néhányan, akik számomra unszimpatikusak, pedig nagy valószínűséggel igen jó szakemberek/programozók.
--
♙♘♗♖♕♔

Én spec a funkcionálisokra szavaztam, meg is magyarázom, ha gondolod. Nem vagyok programozó, leginkább rendszertervezek meg sysadminkodok, ha kódot kell írni az leginkább valami párszáz sor perl ami a wd40-szigszalag szerepét tölti be valami olyan részen, amire a rendes programozó urak nem gondoltak (vagy nem jól, vagy "jól" nagyon drága lett volna). Meg persze tanultam azért programozni, csak mondjuk c-t, javat, ilyesmit rég nem kellett magamnak írni.

De ha szembe jön valami, amibe valamiért bele kell nézni, modjuk hogy az ember kitalálja mi a baja, akkor egy random funkcionális / oop nyelven írt izét általában megértek komolyabb erőfeszítés nélkül, látom kb mit csinál, tudok szólni, hogy hol néz ki marhaságnak, esetleg meg tudom patkolni magam. A haskellre mondjuk meg nézek mint borjú az újkapura, hogy ez mi a tököm akar lenni. Na, nekem ezért legkevésbé kedves :)

A 2013-as "Kedvenc programnyelv" HOVD-n első lett a PHP, második a java. Itt a második a php, első a java.
Az első két helyezett ugyanaz a kedvencben és az antikedvencben is, érdekes. És persze felveti azt a kérdést is, hogy a HOVD-n ez a szavazás mennyire mutatja helyesen egy nyelv kedveltségét a HUP olvasói között.

Fene tudja. Esetleg egy egyszerű rangsorolás, mondjuk az első háromra kellene szavazni, és kapnának 3-2-1 pontokat. Szerintem érdekes lenne így is a szavazás, mert ebből (megfelelő lekérdezéssel) a klasszikus HOVD eredménye is kijönne ("ki kapta a legtöbb három pontot").

Hasonlóan szavaztattam az osztályomat még novemberben, hogy a szalag milyen színű legyen - ami lett végül, kevesen mondták első helyen, de mindenkinek tetszett, sőt, még a párhuzamos osztályfőnökök szerint is talán a legjobb lett :)

Szerintem itt inkább arról lehet szó, hogy a többség ezt a két nyelvet ismeri a megfelelő mélységében, ezért ezekről tud véleményt mondani. Ezért szerintem az is egy jó módszer lenne, ha minden nyelvről külön lehetne véleményt nyilvánítani, elég lenne a tetszik/nem tetszik/nem ismerem opciók közül választani. Csakhogy ez 10 nyelv esetén 10 szavazás vagy 10^3 szavazati opció lenne...