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

 ( utpKabel | 2014. május 4., vasárnap - 16:41 )
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ás megjelenítési lehetőségek

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

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?

Python többsoros komment:

#
#
#
#

:D

''' vagy erre
a fajta
kommentre
gondoltál?
'''

Azt hittem ez csak docstring.

Sajnos ez viszont pl. nem mukodik vele:

#!/usr/bin/python

class Test:
	def test1(self):
		print "test1"
'''
	def test2(self):
		print 1
'''
	def test3(self):
		print "test3"

t = Test()

t.test1()
t.test3()

/sza2

Végeredményben az. :)
De hogyhogy nem működik ezzel?
Lezárja az osztályt idő előtt? Vagy mi a gond vele?
Amivel kipróbáltam, azzal működött.

Nekem ezt mondja az interpreter:

  File "mlc.py", line 10
    def test3(self):
    ^
IndentationError: unexpected indent

/sza2

Jé... valóban.
(mondjuk csak poénnak szántam a '''-t, de eddig nem tűnt fel, hogy bármi, amit odaírok a nyitó és a záró aposztrófok közé, zavarná az interpretert)

Tab-space sok más nyelvre is igaz. Sajnos. De normális editorok ezt lekezelik, tudnak a kettő között konvertálni.


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

Valahogy csak beírod azt a fránya kódot, nem? Itt érdekes az editor tudá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."

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.

zavaro != mukodeskeptelen

Le van speckózva, és komolyabb prozsék esetében van megfelelő forráskód-formázó tool, ami az esetleges trehányságokat helyreteszi, mielőtt a verziókezelőbe belezuttyanna a forráskód.

+1

Nekem a Visual Studio már C# és SQL kódnál is elkezd vinnyogni, ha keverném a space-eket a tabokkal, vagy fordítva, pedig ott semmi jelentőségi nincs kódszinten. Azt már nem tudom, hogy ez alap feature, vagy plugin, mert extensionből elég sok van telepítve.

Pythonban nem kell többsoros komment, a kód maga a komment! :D

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.

Nincs, max. ki egysorozod :D

Armin Ronachernél is így néz ki egy többsoros komment.

Miért kell kikommentezned sorokat a kódban? Töröld ki, ha nem kell. Aztán ha mégis kell, akkor a verziókezelőből előszeded. Egy normális IDE egyébként ki tud kommentezni akármennyi sort.

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

Tehát kell hozzá olyan editor, ami ezt tudja. Meg mást is.

azert ez nem olyan nagy elvaras szerintem, ha egy editor nem kepes X darab egymas feletti sor ele beszurni a #-t vagy onnan kitorolni, akkor azt nem nagyon kene eroltetni :)

Azaz megszámolom, hány sor, majd .,+Xs/^/# Rendben :-P

VIM visual mód, számolni sem kell. :)

:'<,'>s!^!#!

ti most komolyan azzal szorakoztok hogy a leheto legbonyolultabb megoldasokat keresitek? :D

(en Perlnel vagy shell scriptnel csak a sor elejere megyek, CTRL-V-vel le/felmegyek addig, ameddig a kommentet akarom, aztan SHIFT+I es # majd ESC es kesz :) )

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

kevesbe gyoker editorban (emacs): ALT-;

--
NetBSD - Simplicity is prerequisite for reliability

es ez a "kevesbe gyoker editor" magatol kitalalja helyetted, hogy pontosan melyik sorokat akarod ki- illetve visszakommentelni?

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

Ehhez legalább tudsz neked kedvesen működő funkciót írni (elisp-ben) vagy más okosságát használni - ha az alap nem felel meg. :)

ez sok mas szovegszerkesztore is igaz (pl. a szalban alapvetoen emlitett Vim-re is), de tenyleg nem ertem hogy ez most hogy jon ide...

És írtak már normális szövegszerkesztőt az Emacs-hez, vagy arra még várni kell? :-D

hat, ha mindenaron szopatni akarod magad, azt is lehet :D

Jaj, de hát számítógép is kell a szoftverfejlesztéshez!

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

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

Utolsó mondatra: http://legacy.python.org/dev/peps/pep-0008/
Ezt kell betartani és nincs több probléma. ;)
(egyébként nálam a Python inkább a kedvenc, mivel nem vagyok fejlesztő már nagyon rég)

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

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

Nem használok Python-t, de ezt nem oldja meg a sok szerkesztőben meglévő kijelölöm, majd Tab (ill. Shift+Tab)?

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

"Ugyanez Python-nal a zarojelezes hianya miatt nem oldhato meg"

Én intellij idea-t használok, szépen megcsinálja.

Én meg - ha nagyon szépre akarom pintyőzni a kódot, akkor perltigy vagy más hasonló motyót veszek elő, de általában nem sokat szokott módosítani a formázáson, mert eredendően szépen dolgozni kötelező identálás nélkül is lehet :-P

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

Azért az értelmező elég jól kiírja hol az indent hiba. Tehát fel van erre készítve a python. Meg jó editor kell és kész.

--
http://pyftpadmin.earthquake.hu

Idézet:
"Azert az is tud szop@st generalni, amikor veletlenul kitorolsz egy-ket space-t..."

Az egy viszonylag altalanos tulajdonsaga a programnyelveknek, hogy ha veletlenul kitorolsz egy-ket karaktert, akkor bazira mast fog csinalni mint addig.

egy-ket space != egy-ket karakter

Azert keves olyan nyelv van, amiben ha whitespace-eket torolsz, akkor mast fog csinalni mint addig (termeszetesen nem arra gondolok, hogy int a; -> inta;).

De lehet, hogy en latom rosszul, esetleg mondhatnal meg par nyelvet ahol ez igy van.

/sza2

Szerintem ebben a nyelvben például okozhat problémákat... :D

Ha nem 2003-ban lett volna kiadva, meg azt hinnem toluk szarmazik a Python alapotlete:-)

/sza2

Make

--
NetBSD - Simplicity is prerequisite for reliability

Bizonyara azon is el lehetne filozofalni, hogy a make programozasi nyelv-e.

/sza2

vegul is, egy erosen specializalt scriptnyelvnek tekintheto (bar en azert nem mernem programozasi nyelvnek hivni)

igen, mert DSL

--
NetBSD - Simplicity is prerequisite for reliability

Biztos ez is hozzaallas kerdese, de nekem a nyelv != programozasi nyelv.

Ennyi erovel akkor a HTML, PostScript, etc is ide tartozik, de szerintem nem (legalabbis ugy erzem ez a topic nem errol szol).

/sza2

Imho amiben lehet írni http szervert, az programozási nyelv. ;)

a socket kommunikációt nem is a PS végzi :(

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

Irtam is gyorsan bash-ben egy http szervert:

#!/bin/bash
/etc/init.d/apache2 start

:-)

/sza2

Ok, akkor most ugyanezt make-ben. Koszi :-)

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

Igen, a "test" írható úgy is, hogy " [ " :-P

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

Te nem értettél meg, nem voltam elég világos. :)

Én látom ha 7 vagy 9 a space. Ja és nincs kipontozva :P

es azt is latod, ha a 8 space-es behuzasnal a harmadik szinten mondjuk 100 sorral lejjebb valahol 24 helyett csak 23 space van?

Nem fogja látni :) de majd abba fog belekötni, hogy a 100 soros blokkot tovább lehet bontani ;)
-
groovy.lang.Tuple kicsit közelebbről

100 soros blokkot tovább lehet bontani! :D

Eddig megúsztam az egymásba ágyazást a végtelenségig, pl. if -> if -> if már nálam sok(k). :)

a kerdes nem ez volt, de akkor ezt egy NEMnek veszem :)

egyebkent mar csak ezert is erdemesebb TABot hasznalni, ott egybol eszreveszi az ember ha eggyel tobb vagy kevesebb van (legalabbis sokkal inkabb, mint a space-ek eseteben)

+1

Ugye az tiszta, hogy itt a for végéről hiányzó kettőspont miatt írt egy "érdekes" hibaüzenetet az interpreter?
(nem tudom, mi volt az előzmény, mert a drupal threadeket nehezebb követni, mint a python indentálást. :D)

Ugyanezt proporcionális fontokkal nyomtatott kód esetén is?

Aki Python kódot proporcionális fonttal nyomtat, az menjen kapálni.
--
♙♘♗♖♕♔

+1 (Meg ugy altalaban barmilyen kodot...)

Apró de lényeges különbség, hogy a többi (nagyjából a whitespace kivételével) értelmes, használható marad, a python kód meg gyakorlatilag mehet a kukába...

Az nem a nyelv hibája, ha valaki nem képes 1 lépést előre gondolkodni.
--
♙♘♗♖♕♔

Ja. A nyelv kitalálójának a hibája.

Mitol is lesz nagyobb baja a pythonnak a tobbi nyelvhez kepest a proporcionalis betuktol?

Valószínűleg arra célzott, a proporcionális betűk miatt romlik a kód olvashatósága.

Stroustrup mehet kapálni... :)

Ha egy nyelv kifejezőképességét befolyásolja a szintaxis, akkor az szerintem gáz. Márpedig pythonban pl azért nem lehet többsoros lambdát írni, mert nem lenne megfeleltethető az identálási szabályoknak.

Ha többsoros, akkor azt nem illene egyébként is nevesített függvénybe pakolni? Vagy van olyan funkciója a lambda fv-eknek, ahol nem helyettesíthetőek normál függvénnyel? (ezt tényleg nem tudom, csak pythonban használtam ilyet)

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.

"csak nem tranzitív" jogos!

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

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

Üdv. bnv

hasonló kérdés fogalmazódott meg bennem a javaval kapcsolatban.

... nekem meg a C-vel kapcsolatban :]

C: debugolni remalom, a SIGSEGV borzalom. Ha valamit nagyon C-ben kell megcsinalni, akkor a leheto legkevesebb koddal oldom meg, a tobbit valami scriptbol, amiben van ertelmes debugging, es nem felora ujraforgatni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

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

Lefordítom: 99%-ban azok szavaznak, akik egy sort nem kódoltak benne (és nagyrészt más nyelvekben sem), de MS, szóval utálni kell.

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

Szerintem en nem anyaztam az MS-t, viszont amit te csinalsz az.... ;)

brainfuck

http://en.wikipedia.org/wiki/Brainfuck

--
Live free, or I f'ing kill you.

A basic.

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.

Ez jo, :-)

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.

Egy DSL akkor olvasható jól, ha az adott DSL-t ismered, ennek a nyelv olvashatóságához igazából nincs köze. A "sima" Ruby kód szerintem nem gáz.

A ruby alapu dsl-ek olvashatoak, ha ismered a ruby nyelv alapjait. raadasul egy rspec DSL-t peldaul konnyebb megerteni mint egy XML-t.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Elég jól összefoglaltad, kevés dologgal tudnék vitatkozni.
Én annyiban látom másként, hogy minden nyelvet szeretek, de azért mindnek vannak kisebb nagyobb hibái.

egyéb --> Pontosan ilyesmi nyelv a Scala, minden fő kívánalmadat hozzá.

Scala-hoz közel sincs olyan kiterjedt natív ökoszisztéma, mint Javahoz... :-(

Nem igazán értelek, a Scalahoz minden java könyvtár használható.

A "natív" a kulcsszó, ami ront a dolgokon, de egyébként igazad van :-)

Az tényleg jobb volna, ha minden Javas könyvtár meg lenne Scalasan is, de azért ne legyünk telhetetlenek. :)

Nem vagyok expert a témában, de legutóbb mikor erről beszélgettem egy Scalással, azt mondta, hogy rengeteg wrapper cucc van, ami "scalásítja" a libraryt, és írni sem bonyolult (persze az írni != kész van)
-
groovy.lang.Tuple kicsit közelebbről

"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

A generikusok nem az 1.5-ben jöttek be?

De, a szövegértés nem sikerült ;)
-
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/

--

Objective-C

Pedig az jo, de elsore tenyeg szokatlan. Ha siman a smalltalkot irtad volna at meg meg is ertenem.

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

Én írtam is! Szerettem...

--
Soli Deo Gloria

Nem csak hogy Forth-ban volt szerencsém programozni, de még Forth-ot is írtam ASM/Forth-ban (Novell-alá is mint VAP vagy NLM, C-vel összegyógyítva ...). Én szerettem, de eljárt felette az idő.

Mi baj van a FORTH-szal? A veremkezelést legalább egy életre megtaníttatta az emberrel. A Commodore Assembly-hez képest pedig gyakorlatilag ojjektumorientált teljesen ;)

--
http://csuhai.hu

Hát abban próbálj webes alkalmazást írni! ;)
Vagy pláne: olvasható kódot (a'la Uncle Bob :) )

Na jó, ezt visszavonom. A topik hatására belenéztem egy erlang tutorialba... A FORTH egy kedves, érthető, könnyen kezelhető nyelv! :)

Anno erlangoztam kicsit, szerettem.

Én csak a tutorialba olvastam bele és hazudnék, ha azt mondanám, hogy könnyen érthető amit olvastam. (most nem a nyelvi elemekre gondolok, hanem a logikájára - azt hiszem, ehhez kell némi matematikusi véna, ami belőlem sajnos hiányzik :( )

Akkor ezután a prolognak ne nézz utána. Prolog után az erlang egy szép, könnyen megérthető, szerethető nyelv. :)

Mintha lenne némi közük egymáshoz. ;)

Mindkettő deklaratív, csak az egyik logikai, másik funkcionális.

"The initial version of Erlang was implemented in Prolog"
Ezt láttam korábban. Csak én úgy emlékeztem, hogy a prolog ihlette az erlang kitalálóját.

minden FreeBSD-s :)
_____________________________
Powered by 1,3,7-trimetilxantin

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!

+1
Hülye kérdés...

+1

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

+1

A köménymag, húú de nem szeretem, de hogy komolyan is válaszoljak, ez ugye ítlés dolga, és a kérdés is arra vonatkozott. Ha lehet kedvenc programozási nyelvem, akkor lehet -(kedvenc) is.
-
groovy.lang.Tuple kicsit közelebbről

Hát igen. A fradi/ute/stb. köménymagot én se szeretem. ;)

A köménymag az a szegedi B-közép :-D

vagy nem. Pl.: nacionalista lehetsz, soviniszta nem. De tobbek kozt Jezus tanitasainak is ellentmond.

Egyéb: Fortran. :D

> Prolog
no

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

Gyanítom, abban benne van az is, hogy mennyien ismerik.

Az se baj. Kell a kihívás :)

PL/pgSQL

-1 az nagyon is jo cucc es olvashato is

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á

"c - hardverközeli, könnyebben tanulható mint a c++"

Az egész C++-nál könnyebben tanulható, de ha a C++-ból csak a string-et meg a vector-t használod, már jobban jársz, mint C-vel.

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

Hát ja, csak eddig nem igazán találkoztam olyan szituációval, ahol VB.NET-et kifizetődőbb lett volna használni, mint C#-ot. Ha már .NET.

En VB.NET-ben jobban otthon vagyok, nekem kifizetodobb azt hasznalni, mint C#-ot, amit nem ismerek annyira.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

COBOL kód olvasásakor fizikai rosszullétet éreztem :)
--
♙♘♗♖♕♔

Csak azért nem említettem, mert amikor COBOL-lal dolgoztam, még szerettem a munkámat. ;)

Azért a Cobol-t ne a mostani cuccokkal hasonlítsd össze - a többi korabeli nyelv sem szép mai szemmel nézve :-P

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?

a Pythonban nem az elcseszett behuzasok a legnagyobb problema, hanem a kaosz, es az, hogy az egyebkent jo koncepciot agyonvagjak egy rakas idiotasaggal

Milyen káosz, és idiótaságra gondolsz? Én pont azért szeretem a pythont, mert mindent a helyén érzek.

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

Nem lehet hogy a ruby felelne meg neked jobban?

Amúgy +1 a tab pártiságra az általad vázolt ok miatt.

a pythonhoz kepest mindenkepp, kicsit feljebb irtam is a Rubyrol: http://hup.hu/szavazasok/20140504/melyik_a_szamodra_legkevesbe_kedves_programozasi_nyelv#comment-1731116

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

Kaosz a Pytonban, mi?

Oh man!

Lehet doc huptárs PHP-t akart írni! :D

Csak egy egyszerű példa: oop <-> len(lista).

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?

Szerintem a nyelvet

1, meg kell tervezni
2, a döntéseket indokolni kell
3, ezeknek rendszerben kell lenni
4, a verzióváltásnál (major) megoldani, hogy a korábbi komoly hibákat javítsuk, akár úgy is, hogy API-t törünk, max támogassuk a migrálást automatikusan

most mirol beszelsz; melyik szalat nem talaltad el?

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.

'''primitiv konstrukciok (tombok, stringek, szamok) nem objektumok,'''

oh man!

Ezt a marhaságot hogy sikerült leírnod?

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

Pythonban minden ojjektum.
Szóval így "kritizálni" valamit...
Nagyon finoman és kulturáltan fogalmaztam amikor marhaságnak neveztem.

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.

> a primitiv konstrukciok (tombok, stringek, szamok) nem objektumok

most erre milyen kulturált érvet vársz válaszul?
_____________________________
Powered by 1,3,7-trimetilxantin

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)

Na a "sajna..." kezdetű sorodtól kezdve szimpla idióta vagy a szememben.

ha szerinted ez a kulturalt stilus es a konstruktiv vita, akkor itt nyugodtan abba is hagyhatjuk :)

Szerintem, ha valaki kinyilatkoztatás jelleggel leír egy kapitális ökörséget, az ne várjon kulturált választ. Ha meg valaki erre flame-et kezdeményez, ahogy azt tetted...

"Ha meg valaki erre flame-et kezdeményez, ahogy azt tetted..."

Ezzel?

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

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.

Rubyt nem ismerem (csak tudom hogy van), de ha jol tudom Pythont tobb helyen hasznaljak ill. tamogatjak. Nekem ez inkabb eldonti, hogy Python vagy Ruby.

Ha meg mar teccik alapon kellene donteni, akkor __Groovy__.

hasonloan voltam a Rubyval en is :D (bar en nagyon kicsit belenezegettem, es kimondottan tetszett, de a konkluziom a tamogatottsagrol hasonlo volt)
http://hup.hu/szavazasok/20140504/melyik_a_szamodra_legkevesbe_kedves_programozasi_nyelv#comment-1731116

Amiota Redmine-t hasznalunk a cegnel, azota utalom a Ruby-t. Ha egy ideig nem hasznaljuk (pl ejszaka), masnap az elso betoltodes kb. 15-20 sec. Hogy mire var, ne kerdezzetek.

Én is megsértődőm, ha "báncsák" a pythont! :) Pont mint egy gyerek, a kedvenc játékom az tabu. :D

Szerk.
Meg akkor is megsértődöm, ha HZ jó arcoknak szól be! :D

És ki lenne a "jó arc"? :)

doc. De szóltál már be olyannak itt, akit személyesen is ismerek, jó szaki, és nála önzetlenebb/nagyobb szívű fickó szinte nincs is. :)

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

Ritkán szólok be olyannak aki nem szolgál rá. :D

es azt, hogy ki "szolgal ra" termeszetesen te dontod el :)
vagyis csak annak szolsz be, akinek be akarsz szolni

Gyurex: ennyit az emberismeretedről ;)

Te kérted fel táncolni.:D Egyébként nem látok semmi kivetnivalót a hozzád fűzött szavaiban. Na meg én nem is elemzem docot, szeretve van itt mindenki, úgy ahogy van.

''' szeretve van itt mindenki, úgy ahogy van'''

Ez jol esett; azt hittem, hogy a bunkokat csak a jo csajok szeretik.

Nálam nem feltétlenül van olyan, hogy bunkó. Max. másképp szocializálódott. :D

Provokálja a flame-et. Én úgy saccolom, szándékosan.

Ezt már hányszor láttam hupon tőled... :) Kiharcolod, hogy visszaszóljanak, aztán letrollozod :D

Aham. Mer azt ki kő harcóni... :D

:D

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)

dir (0)
dir ("")
help (77)
help ("krixkrax")

Próbáld ki!


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

ez ugyanaz amit en irtam, hogy a string (pontosabban 'str') tipusu valtozok objektumok
(es implicit benne van, hogy a string literal viszont nem)

szoval szerintem hrgy84 eredeti felveteset megvalaszoltnak tekinthetjuk, barhogyan is ertette :)

a "példám" nem a kérdésedre válaszoló példa volt, bocsi :)

hogy a str.center() példánál maradjunk:
>>>'doc'.center(3)
'doc'
>>>'doc'.center(5)
' doc '

Rubyban is így megy nem?
_____________________________
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

nincs ezen semmi különös, ezen logika alapján a -6-ot nézve nem lenne egyértelmű, hogy -1×|-6|, vagy |-6|. Nem mintha bármikor így használnám, az abs(-6) egyszerűbb :)
_____________________________
Powered by 1,3,7-trimetilxantin

na jo, de az sem mukodik hogy 4.__abs__()
de amugy ez tenyleg nagyon erosen reszletkerdes

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

Mitől lista?
A type(()) azt mondja, hogy 'tuple'.
A (4) ilyen alapon egyelemű lista (alias tuple) lenne.
Szintaktikailag.

A [4] már 'list' típusú.
Kezdem megutálni a pythont... pedig eddig szerettem. :D

"Kezdem megutálni a pythont... pedig eddig szerettem. :D"

MISSION ACCOMPLISHED!
>:-D

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

Hogy neked milyen igazad van! Tizedespontként értelmezi a pontot...

Ez emberi olvasáskor is hasznos lehet.

Bizonyára számtalanszor előfordult már minden ruby programozóval, hogy az intek felett definiált egy l415926 metódust és nem jó karakterkészletet választva a 3.l415926-ot lebegőpontosnak vélte a kódot később visszaolvasva. ;)

Ezt a ruby-s poént valahogy nem tudom értelmezni, viszont azt sem, hogy ha pythonban is, az őt indító shellben is magyarra állítom a locale-t, akkor a tizedes miért marad meg pontnak a pythonban.

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

Ha valakinek van kedve flamelni a tizedespont\vessző témaköréről, akkor szóljon, vevő vagyok rá :)
_____________________________
Powered by 1,3,7-trimetilxantin

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.

ugy sikerult neki, hogy -mint a tobbi Python anyazo- egyaltalan semmi fogalma a Pythonrol, de azt hiszi, hogy az a semmi ami van neki, mar valami.

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

Jurányi utca? :)
Vagy volt máshol is R20?

Igen :)
Volt még egy R40-es is az Alkotás úton a MOM-ban is, a jelenlegi pláza helyén, ami már modern monochrome konzolokkal rendelkezett, nagyon király dolog volt :D

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

Bármilyen nyelven lehet writeonly forrást "alkotni". Van, amiben egyszerűbb,és van, amiben nehezebb. Ez utóbbiakhoz kell a kevesebb programozási gyakorlat és szépérzék :-P

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

mau kimaradt.
--
http://www.micros~1

Erősen torzítaná az eredményt :-D

:DDDD

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.

Nem hiszem hogy a Map kedvéért csinálnának ilyesmit. :)

--
arch,xubuntu,debian,windows,android

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

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.

Kétélű fegyever, mint minden kb a programozásban
-
groovy.lang.Tuple kicsit közelebbről

csak nem jonnek az indokok, pedig kivancsi lennek ra...
en sem szeretem a Javat, de az meglep hogy meg a PHP-nal is tobb szavazatot kapott, ANNYIRA azert nem rossz :)

Az enyem az, hogy a linkelt blog egy eleg szubjektiv velemeny a Javarol es az OOP-rol. Ahogy a blog alcime is irja: "RANDOM WHINING AND STUFF."

Úgy néz ki a "nem ér" kitétel sok kommentet kizárt.
-
groovy.lang.Tuple kicsit közelebbről

Csak épp annak, hogy lassú, annak maga a nyelv is oka lehet. erről mi a véleményed?

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

Hm, lehet, hogy rosszul értem, de nem azt mondja, hogy speciálisan pöcsölniük kellett, hogy gyors legyen attól még, hogy Java?

Hát az biztos, hogy másképp érted, mint én. Arra kívántam felhívni a figyelmedet, hogy a céljuk a leggyorsabb megírása és Javaban írják. Azt, hogy ehhez mérni kell és optimalizálni, az nem Java specifikus.

Most komolyan egy tizenvalahány éves blogbejegyzéssel akarsz érvelni egy vitában, ahol egy Visual Basic fejlesztéssel nyitó C/C++ fejlesztő elmondja, hogy mit nem értett meg a Java-ból? :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

fuggetlenul attol hogy mi a velemenyem a temarol, ez a komment odabasz, respect :D

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.

Igaz, bár a legtöbb nyelvben a kettő együtt jár, mivel a memory safety-hez bounds checking és automatikus memóriakezelés szükséges (explicit free dangling pointerhez vezethet), az automatikus memóriakezeléshez pedig GC kell.

Egyébként 5.-ös pont High-Level Optimizations, kifejezetten érdekes felvetés.

Amilyen megvalósításról én mondjuk tudok, hogy Haskellben van rá okos pragma: https://www.haskell.org/ghc/docs/7.8.2/html/users_guide/rewrite-rules.html

"Egyébként 5.-ös pont High-Level Optimizations, kifejezetten érdekes felvetés."

De ez nyelvfüggetlen... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Én nem érvelni akartam, hanem a véleményeteket kérdeztem.

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.

Lehet regexp nélkül is élni meg kódolni,csak néha nem érdemes :-P

a regexpet nem a Perl talalta fel, csak azzal epitettek kore elsokent teljes erteku nyelvet :)

Tudom :)

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

+1
Perlbel lehet akar Qt-t is hasznalni, de en sem vetemednek ilyenre, mindenre a megfelelo eszkozoket kell hasznalni :)

Ha mar regexelni kell, en inkabb Rubyzok, mert van olyan powerful, mint a Perl, viszont a kornyezet sokkal kulturaltabb. Raadasul fel lehet venni mashol is, nem csak a strandon.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

a Ruby erdekes nyelv, regota neki akarok allni foglalkozni vele, de nincs ra idom :(
meg annyira nem nagy a motivacio sem, mert mig Perl kb. mindenhol van, rubynal ez lehet problemasabb
de nagyon tetszik a mogottes 'filozofia', az meg plane hogy meg egy numeric literal is object :D

Sot, meg a null (nil) is az! :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Tudom, hogy sokszor nagyon hatekony a regex. Cserebe az olvashatosaga nem is nulla, hanem negativ. Az meg hagyjan, hogy a sajat regex-eidet nem erted 2 honap mulva, de maset... Szoval akinek ez megy, annak respect, de en nem tartozom ezek koze :D

Mit használsz helyette?

Nem nagyon szokott szuksegem lenni pattern-intenziv (ez ertelmes kifejezes egyaltalan?) dolgokra, ugyhogy a beepitett string-kezelo fuggvenyek elegek szoktak lenni.

Nekem úgy tűnik, egy regex speciális karaktert gyakran >1 string-kezelő függvénnyé tudsz kifejteni. Így már nem biztos, hogy azt gyorsabb megérteni.

Parsec

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

ez igy teljesen korrekt
en ennel azert lustabb szoktam lenni, rendszerint 2-3 szoban leirom hogy mire valo, aztan kesz (igaz, hogy agyonbonyolitott regexpeket nem szoktam irni, inkabb szetbontom ha lehet, ugy sokkal konnyebben karbantarthato)

lájk

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

A helyes megoldás:

# Search for noncomment (not # line) patterns listed in patterns.txt and search for them
# one by one in text.txt and list matching lines alphabetically (and uniquely)
grep -f <(grep -v ^# patterns.txt) text.txt |sort -u

Szerintem ez sem "A" helyes megoldása a problémának - a helyes megoldás, hogy a megfelelő esetre a három közül a megfelelő megoldást választjuk. (Ez a megoldás módosíthatóság tekintetében pl. rosszabb, mint az első, még a kommenttel együtt is.)

Gondolom, $() akart lenni.

Ez a megoldás szerintem semmivel nem kevésbé olvasható, mint a ciklusos, ha az ember fejben tartja, az opciókat (-v, -f). Talán leginkább a ritkán használt opciókat érdemes kommentálni.

Csak kopiztam a parentet, nem teszteltem, elhittem hirtelen. :)

Ne csak hirtelen hidd el, nem kell oda a $, ha jól emlékszem.

Valóban, <-vel egybeírva a zárójelet működik. Ezt nem ismertem.

Látjátok, hogy mennyire nem olvasható? Nem is sikerült elolvasni, hogy mit írtam... :/ (Ez is cél volt, direkt akartam belerakni valami nem megszokott struktúrát, a <() pont ilyen.)

De sikerült, csak sokunk számára ismeretlen ez a szerkezet, míg a $( ... ) a'la ` ... ` (backtick) ismerős.
Én is csak onnan tudom, hogy nem kell a $, hogy kipróbáltam. :)

Na igen, viszont nem lett volna sokkal hosszabb a $() se (vagy a még ismertebb ``).

Csak az mást csinál.

Jogos, úgy a -f nem kéne. (És a $() idézőjelbe.)

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.

Valóban hagy kívánni való maga után a doksi, de azért folyamatosan javul észrevehetően szerintem. Viszont ami plusz, hogy mindig sok példa kódot tartalmaz. Ez még MS doksiknál sem volt mindig így emlékeim szerint.

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.

Ott van a TypeScript, az egészen szerethetővé varázsolja az egészet.

Ü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™

+1

Ööö, megírsz pár bajt? Magánban is jöhet.

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.

Mármint miért nem kedvelem a PHP-t? Itt van egy egész jó összefoglalás:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

És itt egy igazán vicces dolog:

http://news.php.net/php.internals/70691

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

Még mindig kicsit össze vagyok zavarodva a funkcionális paradigmától a saját munkakörömben. Milyen előnyt ad egy átlagos webapp fejlesztéséhez a funkcionális szemlélet, amit mondjuk nem kényszerít ki pl. a Clean Code?

Nem tudom mi van a CC-ben.
Ennek fényében a funkcionális szemlélet hozzájárul a következők javításához/megoldásához: skálázhatóság, újrafelhasználhatóság, biztonság, tesztelhetőség, kevesebb programhiba, átláthatóbb, jobban strukturált kód.

+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

Az SRP nem függvényre/metódusra vonatkozik, hanem az osztályokra. Igaz, ez eredendően OOP téma.

Szerintem osztályokra is és függvényre/metódusra is, de ezen nem veszünk össze.

Úgy értem: nagyobb egységekre találták ki, a kisebb egységre ezért már alapértelmezett.

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.
--
♙♘♗♖♕♔

antipátia, antipatikus

Ellengyógyszerész. :)

legyszi ne irjal mar le olyat hogy "unszimpatikus"...

MOD: latom megeloztek :)

Miután a kedves antipatikus Hevi beszólt, sajnos ez már örökre így marad :)
--
♙♘♗♖♕♔

Azt kell megjegyezni, hogy Antal foglalkozását tekintve gyógyszerész.

Nem könnyű ezzel megbarátkozni, de azt hiszem menni fog :)
--
♙♘♗♖♕♔

mi a baj a szokepzessel?

Tképp semmi: http://www.gyakorikerdesek.hu/tudomanyok__helyesiras__505981-unszimpatikus-vagy-antipatikus
Bár nem tartom hiteles forrásnak az oldalt, amit az első pár hozzászólásban leírtak, az legalábbis érdekes.

Pedig németben teljesen oké a szó.

Értem én, de annyira mégsem. Pl. a python számomra nem szimpatikus, de elhiszem hogy lehet benne jó, áttekinthető kódot írni, elismerem hogy "jó szakember" az analógiával élve.
A php minden elképzelhető szempontból egyszerűen rossz.

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

Mindenféle szavazási rendszer mást mutat meg. Ezek szerint számodra valamilyen Concordet módszer lenne beszédes (pl. Schulze method) ott valószínűleg olyanok nyernének amik kevésbbé megosztók.

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

Egy szavazásban is lehetne (bár nem tudom, mennyire van drupal-hoz lehetőség), mindegyikre meg lehetne jelölni, a tetszik/nem tetszik/nem ismerem lehetőséget. Persze ezzel meg az az információ veszik el, hogy melyik tetszik a legjobban.

Szerk.: nem 3^10 szavazási opció? :)

De.
--
blogom

+1 :)

Igen talán ez a konszenzust leginkább támogató módszer, jól döntöttél ha ez volt a célod:

http://en.wikipedia.org/w/index.php?title=Borda_count#As_a_consensual_method

Jaja. A végeredményt ismerve is úgy gondolom, jó, hogy nem szimpla többséges szavazósdit játszottunk.

Twitter-en lévő álláshirdetések által generált sorrend az elmúlt egy évre: http://www.sitepoint.com/best-programming-language-learn-2014/
Lentebb van olyan lista is, mely nyelvet mennyien szerették volna megtanulni az egyik weboldal segítségével.

Hat, a C betuvel kezdodo nyelveknek van meg hova fejlodniuk... :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.