Python 3 >> Ruby

Sajnos azt kell mondjam, hogy nagyon nem tetszik a Python 3. Amennyire levette a terhet az ember válláról a 2-es és nem kellett "gondolkodni" a kódoláshoz, hanem produktív tudtam lenni, annyira nem a 3-as.

Eleve a print parancs. Nagyon kényelmes volt, majdnem ez miatt szerettem Python-t a leginkább. Mindegy mit printeltünk, kinyomta a tartalmát.

Ezen kívül bevezettek egy rakás olyan kulcsszót, amelyek kellenek a függvény hívásokhoz, ráadásul olyan alapértelmezésekkel, ami nem tetszik. Pl.: 


out = subprocess.check_output(["acpi", "-V"], universal_newlines=True)
print (out)

A "universal_newlines" kulcsszót mindig ki kell írni, ha normál formában akarom megkapni az új sorokat. Ez is olyan, ami nem teszi a kódolást egyszerűbbé. Hosszúak és nem logikusak a függvény és osztály nevek. Sokkal jobb volt az os, sys, command stb. osztály, amelyeket lecseréltek.

Meg még egy rakás dolog. Hogy kell a print-hez end="" hogy ne legyen newline, meg hasonló apróságok.

A gép úgyis azt csinálja, amit mondunk neki, viszont pont a humán részét kellene megkönnyítenie. Olvasható kóddal, _rövid_ kulcsszavakkal és normális paraméterekkel. Értem hogy hosszú kulcsszavakkal és a fent leírtakkal strukturáltabb lesz a szintaktika, de ez a gépnek segít, nem a humán oldalnak. Ráadásul sűrűn változtatják a beépített osztályokat, sok deprecated lett a 2-es óta.

Ez az, amikor már nem olyan irányba megy a fejlesztés, mint amire eredetileg kitalálták.

Mi a véleményetek? Nem vesz el nagyságrenddel több energiát nálatok egy 3-asban összerakott kód, mint a 2-es szériában?

( log69 | 2012. 01. 18., sze – 09:35 )

Azt hiszem, Ruby felé mozdulok. Ez tetszik:

"Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves."

( mkristof | 2012. 01. 18., sze – 09:49 )

"First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute."

-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO

( log69 | 2012. 01. 18., sze – 11:19 )

Úgy látom, a regexp-től kezdve a ciklusokon át sokkal használhatóbb és egyszerűbb a kód. Regexp-nél pl. nem kell import meg semmi egyéb: 

"ez itt a szoveg".match(/regexp/)

Ugyanez összes regexp találattal: 

"ez itt a szoveg".scan(/regexp/)

A találatokból a második (mint egy tömb elemére hivatkozva): 

"ez itt a szoveg".scan(/regexp/)[1]

A random érték kérése csak 

rand(60)

pl., nem kell import random. Jó érzések ezek az apróságok.

Nagyon jó. Sőt, nekem fényévekkel jobb. Abszolút ráálltam.

A Rubynak szerintem is az az egyik előnye, hogy sikerült a tömörség-olvashatóság skálán egy elég jó kompromisszumos szintet belőnie. Mondjuk valahol a Perl és Python között.

(Persze itt azért eléggé szubjektív ítéletről van szó, szóval meg tudom érteni azokat is akik inkább jobban kedvelik az egyik vagy a másik végletet.)

( ijanos | 2012. 01. 18., sze – 12:17 )

A print kényelmes volt mint statement? Szerintem függvényként több értelme van, ráadásul áltlában csak két zárójellel kell többet írnod, az nem olyan nagy ár azért.

A kulszavak nem "kellenek" ha ennyire zavar írhatnál out = subprocess.check_output(["acpi", "-V"], None, None, False, True) -t is csak aztán két nap múva tudd mi miért van ott. Milyen logika szerint segít az a gépnek ha jobban olvasható a kód?

Ja és nem értem a "mindig ki kell írni" dolgot. Ha sokat használod csinálsz egy függvényt és csókolom. Sőt az egész egy megoldható egy sorban:
getoutput = lambda cmd : subprocess.check_output(cmd.split(" "), universal_newlines=True)

print(getoutput("acpi -V"))
print(getoutput("uname -a"))

Tehát tudsz egyszerűsíteni új függvények létrehozásával. Nekem pont erre kellene a Python: tegye meg ő és rejtse el előlem. Ez már úgyis a sokadik réteg. :)

Olyan szempontból is számít nálam, hogy odaülök egy szűz telepítésű szerverhez, és nincsenek nálam az előre leszenvedett egyszerűsítő kódjaim. Minél több dolgot tudok hamar gyorsan csak fejből és minél produktívabban, annál előnyösebb számomra. De elfogadom, hogy a szempontok másnál más alapján változnak.

Nézegetem Ruby-t, sajnos a Python-ban sokkal jobban tetszett a string manipuláció, például a 3. karaktertől kivágni az utolsó előtti karakterig: print "hello"[2:-1], ez Ruby-ban "string".osztaly(param1, param2) ilyesmi módon van ahogy látom.

( zsitvaij v | 2012. 01. 18., sze – 15:18 )

UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 6:
ordinal not in range(128)

Már azzal meggyőzött a Python 3, hogy ilyen nincs benne. (De bejön a maradék változás is.)

Kicsit zavaró, hogy sok kód arról tanúskodik, hogy nem is ismeri az illető nyelvet. Hamis előfeltételezések miatt bekövetkező rossz használat mellett meg persze hogy elbukik néhány.

Jó példa a java kód (ott ugyanis a String nem módosítható erre van a StringBuilder), középen belinkeli, hogy valaki ki is javította a kódját, aztán folytatja tovább a mantrát, hogy milyen lassú.

Más nyelveknél is a hozzá nem értés látszik: pl a ruby kód sem a megszokott idiómákat használja, hanem egy C típusú kód direkt átirata.

Minden nyelven lehet Fortran kódot írni, de ha így állunk hozzá akkor biztos a Fortran lesz a nyertes az összehasonlításban...

Viszont elgondolkodtató, hogy milyen minőségű kód sebességére vagyok kíváncsi. Nyilván nem vagyok én sem profi, viszont kérdés hogy milyen szintig akarom elsajátítani. Egy számomra egészséges határ után nem érdekel. Csinálja azt amit mondok, és persze _úgy ahogy_ mondom, és ehhez képest fog nekem megmutatkozni a sebessége és használhatósága. Tehát mik a szempontok ugye.

Nyilván profibb ember magasabb szinten tudja használni az általa jobban ismert eszközt. Meg úgy gondolom, hogy nincs legjobb megoldás. Van egy elfogadható (nekem jó) megoldás, amit adott idő és energián belül összerakok, viszont a jótól a legjobb megoldás felé haladva (ami a végtelenben van ugye) egyre nő a szükséges idő és energia (és persze szükséges tudás), kérdés hol éri még meg az optimalizáció.

Azért rubynál feltüntetett kis memóriaigény valós alkalmazásokban biztos nem igaz.
Pl a Ktoggl korundum4 GUI-val induláskor 70MB RSS (és folyamatosan "leakel" - a ruby soha nem adja vissza a memóriát az oprendszernek, csak hízik), a KDE /usr/bin/printer-applet -je Pythonban csak 27MB. Az arányok hasonlóak egy régebbi Zend és egy Rails projectem összevetve.

Az biztos, ha van nyelv, ami szerethető, az számomra a ruby. Hogy miért arra aktuális példa mondjuk a fenti "hello"[2:-2] megoldásom. Fogalmam sem volt arról, hogy hogy kell csinálni. Csak logikusnak tűnt, hogy ha a -1 a string vége, akkor -2 legyen a vége előtt egyel. Kipróbáltam: működött. Ilyen a ruby. Úgy működik, ahogy arra az ember számít. Na jó, általában.. :)

Pl a kedvenc gotcha-m a következő: 


i = 0
loop do
    puts i+=1
    ret = catch :error do
        if i > 3
            puts "error"
            throw :error
        end
        "ok"
        next
    end
    puts "error ret: "+ret.inspect
    break
end

Én itt arra számítanék, hogy a "next" a loopot fogja ugratni, de nem: simán átugrik rajta és break-re fut. Persze lehet, hogy ezzel én vagyok a kisebbség. :)

Kíváncsi vagyok, hosszabb távon hogy alakul majd a véleményed róla.