2011. június 14., kedd

Második nyelv: Python?

Remélem ezzel a cikkel is sikerül annyi gondolatot megmozgatni, mint az előbbivel, ha valami eszetekbe jut, ne legyetek rest hozzászólni!

Mostanában divat második/sokadik nyelvet keresni, egy kicsit kiszakadni a mindennapi munka egyhangúságából, és egy másik világot megismerni, egy másik programozási nyelvben is jártasságot szerezni.

Bár sokan azt mondják, hogy ha megtanulsz egy programozási nyelvet, utána a többi gyerekjáték, azért ezzel nem teljesen értek egyet. Egyrészt igaz lehet ez imperatív nyelveknél, de egy funkcionális vagy logikai nyelv már távolabb áll ettől a világtól, érdemes rápillantani a Lispre. Másrészt nem a nyelvben való jártasság, ami a programozó értékét adja, hanem a köré épülő platform, "ecosystem" ismerete. Megtanulni a nyelv szintaktikáját egy dolog, de ismerni az elterjedt keretrendszereket, könyvtárakat, best practice-eket, konvenciókat, eszközöket. Egy másik nyelv megismerése a többi nyelv használatában is fejleszt, ugyanis lehet új és hasznos ötletekkel találkozni, melyeket újra lehet használni.

Én is elindultam keresni, és a Python mellett döntöttem, olvassátok, miért. A bejegyzésben egy nyelv professzionális elsajátítása mellett érvelek, és nem egyszerű felhasználásról, ami elkerülhetetlen bizonyos esetekben (pl. mennyien használnak JavaScript-et, PL/SQL-t annak alapos ismerete nélkül).

Semmiképp nem akartam nagyon elrugaszkodni, egy imperatív nyelvet akartam választani. Először egy olyan nyelvet akartam választani, melyet sokan használnak, a munkám során is gyakran találkozok vele, és az álláshirdetésekben is gyakran szerepel. Szóba jöttek az előbb említett nyelvek, a JavaScript, PL/SQL, valamint a PHP is. Ezeket valamilyen szinten ismerni kell, miért ne ismerje meg az ember a lehető legmélyebb szinten. A PL/SQL-lel (Procedural Language extensions to the Structured Query Language) kezdtem. Egy adatorientált imperatív nyelvről van szó (Adán alapul), mely Oracle adatbázisban fut (embedded - viccesen platformfüggetlennek nevezik, hiszen amelyik platformra van Oracle telepítve, ott megy), és emiatt erősen gyártófüggő. Mivel alapvetően adatokon dolgozunk, gyakran jöhet jól, egy adatokhoz közelibb nyelv. Én hiszek abba a modellbe, hogy ne vigyünk fel mindent Java szintre, amit meg lehet egyszerűbben oldani adatbázisban, miért ne. Felesleges bizonyos dolgokat megjáratni a rétegek között. Tipikus ilyen példa a nagy adatmennyiséggel dolgozó riportok. A nyelv sajnos nem adta meg azt, amit vártam tőle, hiányzott a szépség, az elegáns megoldások. Az alap szinttől a professzionális szintig nehéz út vezet, mely nem olyan látványos, és sokszor nincs is igazán szükség az emelt szintű dolgokra, és feltételezem, hogy a látókörömet sem tágítja annyira. Az előnye a hátránya, kizárólag adatmanipulációra használatos.

A JavaScript fénykorát éli, megvan benne minden, amire a programozónak szüksége lehet, és úton útfélen találkozik vele az ember. Bár szerver oldalon is használható, azért mégis kliens oldalon jellemző. Egy erősen JavaScript/AJAX megoldásokat használó projekt után ezt is elvetettem. Igaz, hogy vonzóak a nyelv képességei, és az, hogy egy oldal újratöltéssel azonnal tesztelhető, mégis úgy találtam, hogy a JavaScript legmélyebb szintű megtanulása a User Interface-hez köt, specializálódsz, és innentől kellenek a design, tipográfiai és usability ismeretek is. Én ebbe az irányba nem akartam elmenni, én ezt külön szakmának tartom, és alapvető hibának, ha a programozókkal akarnak felhasználói felületet terveztetni (tisztelet a kivételnek).

A PHP-n kellett a legtöbbet gondolkozni, hogy mivel is érveljek ellene. Az alapvető unszimpátia megvolt, de nehéz ezt objektív érvekkel alátámasztani. A Java nagy kihívója webes felületek implementálására, de lazasága miatt nem köti meg annyira meg az ember kezét (értsd: könnyebb benne gányolni). Feltehetőleg ezért nem ismerik el annyira pl. bankos környezetben, és ezért tartják még mindig a Java-t alkalmasabbnak üzleti logika megfogalmazására. Megtanulásával ott vagyok, ahol a part szakad, egy újabb technológia, mellyel kb. ugyanúgy és ugyanazt lehet kihozni webes alkalmazások terén, mint Java használatával. Szerintem ugyanolyan kvalitású fejlesztők ugyanúgy használják jól vagy rosszul mind a kettőt. A .NET-tel kapcsolatban is azt érzem, hogy szimmetrikus párja a Java-nak, szemléletbeli váltást nem hoz, sok pluszt nem nyújt.

A C, C++ mindig is az alacsony szintű programozásra volt alkalmas (értsd jól, pl. kernel, beágyazott rendszerek fejlesztése, amiről tudjuk, hogy az egyik legnagyobb szaktudást igényli), ebbe az irányba szintén nem akartam elmozdulni.

Így kilőttem az első követelményt, hogy lehetőleg olyan nyelvet válasszak, ami nagyon elterjedt, és divatos, és nem utolsó sorban keresett. A második legfontosabb követelmény az volt, ha nem is annyira érték emelő, legalább a mindennapi munkámban bizonyuljon hasznosnak. Egyrészt gyakran kell ilyen-olyan kisebb feladatokat megoldani, melyekhez felesleges az IDE-t elindítani, és Java alkalmazást írni rá, tipikusan shell script-ekkel megoldható problémák. Amikkel ugye az a baj, hogy nem platformfüggetlenek, persze van pár jó Windows port, Cygwin pl., melyet aktívan használok. Valamint, ami ehhez is kapcsolódik, hogy bizonyos feladatok megoldásában nagyon lassúnak találom a Java fejlesztési ciklusát, kódolás - fordítás - futtatás, gyakran az effektív munkától veszi el a kapacitásokat, legrosszabb tapasztalatom ezen belül is a portál keretrendszerekkel való fejlesztés bizonyult, ahol több perc kellett a keretrendszer elindításához.

Így adott is, hogy a script nyelvek közül választottam, méghozzá a Python nyelvet. A nyelv fejlesztése 1989-ben kezdték el fejleszteni, neve a Monty Python’s Flying Circus-ből ered. A nyelvet Guido van Rossum alkotta azzal a céllal, hogy eszközt teremtsen olyanoknak, akik érdeklődnek a programozás iránt, és jó eszközt biztosítson olyanoknak, akik szeretnek és tudnak programozni. Engem az ragadott meg, hogy egy Python script ránézésre megérthető, annyira tiszta a szintaxisa, olyan érzésem volt a nyelvvel való ismerkedés közben, hogyha én nyelvet alkotnék, én is mindent így csinálnék. (Szemben mondjuk egy Perl programmal.)

A Python általános célú nyelv, interpretált, interaktív, platform független és ingyenes. Nem szükséges objektum orientáltan programozni, de megvan rá a lehetőség, támogatja a többszörös öröklődést, és az operátor overloading-ot.

Mivel oktatok olyan szemmel is néztem, hogy milyen gyorsan tanulható, és mennyire alkalmas oktatásra. Be kell valljam, sokkal alkalmasabb, mint a Java. Mivel a program struktúrája a behúzáson alapul (igen!), az ifjú fejlesztőket rászoktatja a formázásra, és nagyon könnyen össze tudják kötni a formátumot a struktúrával. Java-ban gyakran látom, hogy küzdenek a szintaktikával, közben nincs idejük a kódot formázni (bár ebben az IDE is segít), és szétesik nekik. Valamint aki oktatott már Java-t, és a változó deklaráció oktatásánál megkérdezi a hallgató, hogy mi az a public static void main, és miért kell kiírni, az tudja, mire gondolok.

A könnyű megértést az is bizonyítja, hogy egy projektben dokumentum generálásra vezettem be, és anélkül, hogy még bárkinek is részleteztem volna, másnapra többen lemásolták és adaptálták a megfelelő script-eket kizárólag a script és a Google alapján, és mindenkinek tetszett alapvetően.

Gyakran kell fájlokon matató segédprogramokat írnom, pl. napló állományok elemzésére, amire sosem találtam általános eszközt, a grep/sed párosításból kell általában kihoznom a megoldásokat. Ahhoz, hogy Java-val nyúljunk a problémához, ahhoz egyrészt osztályt, main metódust kell deklarálnunk, majd jön a rémálom, a Stream-ek, Reader-ek használata, ami ugyan koncepció szinten nagyon szép, a decorator design pattern egy remek megvalósítása, de gyakorlatban sajnos használhatatlan. Szóval jó, ha egyszerűen lehet állományokat kezelni.

Ugyanúgy ilyen jellegű tool-oknál nem hátrány, ha nem kell objektum orientáltan fejleszteni, valamint nem baj, hogy dinamikus típusú, azaz nem kell előre definiálni a típusokat. Nem kell memóriát foglalgatnunk, felszabadítanunk, automatikusan kezeli az erőforrásokat. Nyelvi szinten támogatja a listákat, szótárakat, ami szintén tömör és jól olvasható kódot eredményez. Hibakezelése kivételkezelésen alapszik, mely szintén a kód tisztaságán segít, hiszen tisztán elválik a hibaág. Azért mégsem enged mindent, erős típusosság jellemzi.

Dinamikus, azaz Python kifejezéseket és utasításokat ki lehet értékeltetni. Ortogonális, azaz kevés fogalommal nagy számú konstrukció írható le, melytől szintén a tanulási görbe lesz meredekebb. Reflektív, azaz futásidőben lehet az osztályokon matatni és introspektív, azaz számos eszköz, mint a debugger és a profiler is, Pythonban implementált.

A Python abban hasonlít a Java-hoz hogy hatalmas osztálykönyvtár adott hozzá, csak néhány a sok közül: regexp, diff, io, objektum szerializáció, tömörítés, CSV feldolgozás, hash függvények és kriptográfiai funkciók, naplózás, többszálúság, hálózatkezelés és internetes protokollok (socket, ssl, e-mail, json, http kliens és szerver, ftp), formátumok (xml, html), I18N, GUI, stb.

Néhány kódrészlet, futtatható, ha bemásolod egy állományba és "python [fájlnév.py]":

# Hello World
print "Hello World"

# Listán iterálás
for t in ["a", "b"]:
 print t

# Egy állományban a # karakterrel kezdődő sorok eltávolítása
import fileinput, re

for s in fileinput.input(inplace = 1):
   print re.sub("#.*", "", s),

# Két változó értékének megcserélése
a, b = b, a

# Állomány tartalmának kiírása
f = open("file.txt")
print (f.read())

# Függvény dokumentációjának definiálása és kiírása
def add(a, b):
 "Két szám összeadása"
 return a + b

print add.__doc__

# Egy weboldal letöltése, és a linkek kigyűjtése
import httplib, re

conn = httplib.HTTPConnection("jtechlog.blogspot.com")
conn.request("GET", "/")
r = conn.getresponse()
d = r.read()
for l in re.findall("<a href=\"([^\"]+)\"", d):
 print l

# coding=UTF-8

print "árvíztűrő tükörfúrógép".decode("UTF-8")

# XML beolvasása
import xml.dom.minidom

document = """
<books>
<book title="Beginning Python From Novice to Professional" />
</books>
"""
dom = xml.dom.minidom.parseString(document)
for book in dom.getElementsByTagName("book"):
 print book.getAttribute("title")

Ha kedvet kaptál, lájkolj!

Azért nem szabad letagadni, hogy azért álltam egyből pozitívan a nyelvhez, mert létezik a Jython, ami egy JVM-en futó Python implementáció, gyakorlatilag Java bytekódot állít elő. Emiatt azonban könnyen integrálható a Java-hoz, minden Java könyvtárat tudunk Python-ból is használni.

Nézzünk is egy példát, méghozzá a QDox Java 3rd party library-t, mely a Java forráskódot tudja elemezni, és API-t biztosít annak bejárására. Egy könyvtárban lévő forráskódok beolvasása, majd az osztályok és azok metódusainak bejárása a következőképp történik Java-ban:

import com.thoughtworks.qdox.*;
import com.thoughtworks.qdox.model.*;
import java.io.File;

public class QDoxSample {

public static void main(String args[]) {
 JavaDocBuilder builder = new JavaDocBuilder();
 builder.addSourceTree(new File(args[0]));
 for (JavaClass clazz: builder.getClasses()) {
   System.out.println("Class: " + clazz.getName());
   for (JavaMethod method: clazz.getMethods()) {
     System.out.println("Method: " + method.getName());
   }
 }
}

}
Ugyanez Python-ban (Jython-ban), figyeljük, milyen elegánsan történik a külső függőség használata:
import sys

sys.path.append("qdox-1.12.jar")

from com.thoughtworks.qdox import JavaDocBuilder
from java.io import File

builder = JavaDocBuilder()
builder.addSourceTree(File(sys.argv[1]))
for clazz in builder.getClasses():
  print "Class: " + clazz.getName()
  for method in clazz.getMethods():
    print "Method: " + method.getName()

Mivel nem kell mindig fordítgatnunk, hanem azonnal futtatható a script-ünk, tényleg gyorsabb lehet a fejlesztés. Pont emiatt, ha valamit gyorsan ki kell próbálni Java-ban, akkor is a Jython-t veszem elő, és nem egy Java-s IDE-t.

A Python azért is lehet ismerős, mert a Google a Google App Engine-t Python-ban és Java-ban bocsájtja rendelkezésünkre. Ahhoz, hogy elkezdjünk fejleszteni, le kell tölteni a Google App Engine SDK for Python környezetet. Hozzunk létre egy állományt, mely kiírja standard kimenetre a szokásos üdvözlő szöveget.

print 'Content-Type: text/plain' print '' print 'Hello, world!'

Ezt az SDK majd HTTP kérésre fogja meghívni, és a kimenetet HTTP válaszba írja vissza. Ehhez konfigurálnunk kell, hogy az összes HTTP kérést ez a script szolgálja ki:

application: helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /.*
script: helloworld.py

Ha elindítjuk az SDK-t, akkor a menüből a File/Add Existing Application-re kattintva válasszuk ki a script-et és a konfigurációs állományt tartalmazó könyvtárat. Az alkalmazást kiválasztva, a script-et a http://localhost:8080 címen ki is próbálhatjuk. Ha fel akarjuk tölteni a felhőbe, akkor az App Engine Administration Console-on létre kell hozni egy alkalmazást, adni neki egy nevet, melyet az előbbi konfig állományban is át kell írni. Az SDK-ban a Deploy gombot megnyomva máris próbálhatjuk az alkalmazásunkat a http://[alkalmazás neve].appspot.com címen.

Ugyanilyen egyszerű az ütemezés, valamint a hozzáférés a Datastore-hoz, Memcache-hez, stb.

Ne értsetek félre, a Java továbbra is az elsődleges nyelv és platform, melyet használok, és javaslok, de a Python remek kiegészítő tud lenni a mindennapi munkában, hiszen általános célú nyelv, és bizonyos feladatokat könnyebben és gyorsabban lehet megvalósítani.

Ti mit használtok Java-n kívül önszántatokból, és nem kötelező jelleggel, és miért?

19 megjegyzés:

  1. Nekem ez forditott, a Java nekem masodlagos nyelv, a Ruby az elsodleges.

    A dologhoz hozzatartozik, hogy en nagyon sokaig Pythonoztam, belekezdtem a webes feluletekbe is, mod_python, megvolt az elso helloworldom djangoban - azutan valtottam Rubyra.

    Tetszik a nyelv formazas-alapusaga, de nagyon elvittek egy olyan szintre, ahova en mar ugy gondoltam, hogy nem feltetlen felel meg az igenyeimnek. De meg ezzel egyutt tudtam volna elni. Ami a legjobban eldontotte nalam a Ruby vs Python kerdest, az az objektumorientaltsag volt.
    En nagyon szeretem az OOP szemleletet, valahogy konnyebben ertem meg az ilyen programokat, mint egy alapvetoen proceduralis valamit (PHP, C, ...). Engem borzasztoan zavartak az olyan apro kulonbsegek, mint pl:

    Python:
    array = ['a','b','c']
    length = len(array)

    Ruby:
    array = %w(a b c)
    length = array.size

    Szoval a ruby sokkal inkabb objektumorientaltabb. Sajnos rubyban lehet olyan kodokat irni, amik rosszul vannak indentalva - bar en mindig figyelek arra, hogy jol indentaljak -, ez nem volt olyan komoly szempont, ami a python melle kotott volna.
    A Ruby van annyira elismert es nepszeru nyelv mint a python, a Rails framework rengeteget ad a webes fejleszteshez, es szinte minden platformra elerheto. Erdemes lenne kiprobalnod...

    (Uhh, ez hosszu lett, bocsi)

    VálaszTörlés
  2. Ja, es elfelejtettem: van JRuby... :-)

    VálaszTörlés
  3. Én sok év C/C++ után kb. 8 éve Java-zom, és a következő áldozat a Scala lenne...

    Azért feltételes módban egyelőre, mert az OO -> functional váltás elég kemény mental switch-et jelent, ezt meg kell erősítenem, sajnos.

    VálaszTörlés
  4. Megint jó lett a cikk! Gratulálok!

    Érdekes volt olvasni erről a témáról is, és ami számomra még érdekesebb volt, azok a téma kapcsán felmerülő egyéb meglátások, gondolatok, tapasztalatok.

    Várom a következőt! :)

    VálaszTörlés
  5. Személy szerint Java előtt Python volt a favorit. Nagyon szeretem azt a nyelvet, az átláthatósága, és a "végtelen" felhasználhatósága miatt. Pythonban lehet scriptet írni, de komolyabb desktop alkalmazást is, ahogyan pda-ra is írtam már progit tcl/tk-val annó, webre is alkalmasabb, mint a PHP. Egy igazi általános célú programozási nyelv. Egy-két esettől "len(array)" eltekintve objektumorientált a Python is. Személy szerint PHP-ban is programoztam éveket, de ott zavart a következetlenség, ami a metódusok paraméter-listájában felfedezhető. Kezdőknek és haladóknak egyaránt csak ajánlani tudom (én is), egy kicsit talán a magyar nyelvű könyvek hiányoznak, ez talán hátráltathatja a tanulást. Létezik Python 3 könyv, bár olvasni nem olvastam, elég vaskos, de még így is töredéke a Java, C, vagy PHP könyvekhez képest.

    VálaszTörlés
  6. Nálam JavaScript és Scala.

    Nem értek egyet a cikkben lévő azon kijelentéssel, hogy a JS szorosan a GUI tervezéshez tartozik. A tipográfiai, dizájn elemeket általában CSS-ben és HTML-ben kell megoldani. Dizájnernek átadható. A trend az, hogy egyre több kommunikációs logika kerül a JS rétegbe. Az a JS programozó, aki nem tudja magáról lepattintani a dizájn feladatokat rosszul szervezi a kódot.

    Áron: A funkcionális nyelvre való váltás szvsz annyira nem nagy durranás, főleg nem a Scala esetében, ahol nem muszáj ezt a paradigmát követni. Egyébként néhány Java "enterprise best practice"-ben is fel lehet fedezni a funkcionális programozás elveit, pl. amikor az állapotmentességre törekednek.

    Jóacikk!

    VálaszTörlés
  7. A cikk mondanivalója tökéletes, bár egy kicsit fájt látni az ilyen nyelvtani helytelenségeket, pl. "abba hasonlít", etc. (helyesen: abban hasonlít) Ez kicsit olyan, mint a helyes kódformázás, nem kötelező, de sokkal jobb, ha nyelvtanilag helyes.

    A tartalmat illetően: Én pont ugyanígy tanultam meg a Java mellé második nyelvként a Pythont, miután futottam egy kört a Javascript-tel és a Scala-val. Azok számára, akik JVM alapú, egyszerű és Java-ra hasonlító nyelvet szeretnének, merem még ajánlani a Gosu-t is. ( http://gosu-lang.org/ )

    Áron: Egyetértek tvik-kel, a Scala nem funkcionális, hanem kevert paradigmájú nyelv (az alkotók is így jellemzik) így tökéletes arra, hogy az ember megtanulja a funkcionális gondolkozást.

    VálaszTörlés
  8. PHP-t használok már a kezdetek óta. Az egyetemen Java és C# képzés van, én mégis vittem szakirányon a PHP-s elképzeléseimet.

    Hogy miért?

    Mert nem kell hozzá semmi, bármelyik tárhelyszolgáltatónál jelen van, minimális költségekkel üzemeltethető.

    Rossz kódot pedig bármelyik nyelven lehet írni, én Java-ban is láttam durván redundáns kódot, 1 osztályban megvalósított programot, ékezetes változóneveket. :)
    Ezek a dolgok a programozón múlnak. PHP-ban is lehet szép OO kódokat írni és nem kell hozzá fejlesztő eszköz, se fordító, se futtató környezet (legalábbis Java-s értelemben vett virtuális gép, vagy C# esetén célszerver).

    Ami talán plusz nehezítés, hogy szinte minden esetben kell hozzá tudni html-t, css-t, javascriptet (utóbbihoz valami frameworkot (jQuery)), tehát alapból nem elég a PHP ismerete, a többi webes dologgal és böngészők képességeivel is tisztában kell lenni. Ez Java, C# esetén gondolom nem igazán jön fel, mert ezek is az adott nyelvre meg vannak írva osztályokban és automatikusan generálódik a felhasználói felület és az AJAX visszahívás is (így láttam).

    A Python nekem is tetszik és figyelemmel követem a róla szóló híreket, jó lenne, ha a tárhelyszolgáltatók is követnék, de amíg nem teszik, addig marad a PHP elsődlegesnek, mivel ha itthon megírom, akkor azt bárhol máshol fel tudják másolni és megy (most verziók dolgától tekintsünk el, az minden nyelvnél elő jön).

    Amit még figyelembe szoktam venni az az erőforrás-használat, teljesítmény, skálázhatóság.. sokat olvastam ebben a témakörben és sehol sem győztek meg arról, hogy ha a PHP-nál maradok az rossz döntés lenne.

    Végül pedig valamennyire az OO ellen szólva, engem borzalmasan idegesít, hogy egy fájlt nem lehet Java-ban(/C#-ban) beolvasni 1 sornyi kóddal, hanem kell FileReader, BufferedReader, ciklus, stb., PHP esetén pedig egy file_get_contents() megoldja. Nekem ez valahogy számít, amikor programot írok, hogy mennyit is kell írni.
    Ezért szimpatikus a Python is, mert még rövidebb is tud lenni, mint a PHP.

    VálaszTörlés
  9. "PHP-ban is lehet szép OO kódokat" ebbe belekötnék. Egyrészt az OO eszköztár elég vékony szegmensét prezentálja a PHP, ráadásul azt is "ocsmányul". Ez a new \HU\BAR\FOO ... inkább nem is írok semmit. Hiába a nagy oop, ha a nyelvi dolgok nem azok, tehát bukott az OOP szemlélet. A függvények paraméterlistálya teljesen következetlen, tök random, hogy az amiben, amit, amire hármast melyik függvény hogy kéri be (igazából az egész nyelvre jellemző ez a következetlenség). Szerintem komolyabb alkalmazásoknál nem az kell, hogy döntő legyen, hogy fel tudom-e tenni Pistike szerverére :D ez elmegy egy darabig, de egy bizonyos projektméret után nem kifizetődő szemlélet. A file_get_contents szerinted mit csinál? Azért mert egy magasabb szinten elfedik előled az ilyen alacsonyabb szintű dolgokat nem jelent semmit. Ez azért van, mert a PHP-t egy bizonyos feladatra szánták, amire jó + gyors meg minden, de biztosan lenne olyan fájlkezelési probléma, amire a file_get_contents nem volna megoldás, de valamelyik Readerrel biztos meg lehetne oldani. Egy szó mint 100 a PHP egy template nyelv, amibe bele"hekkeltek" egyéb dolgokat is. Arra jó amire kitalálták.

    VálaszTörlés
  10. +1 a Jython-nak. A wsadmin is ezt használja a konfigurációs feladatok automatizálásához.

    Talán még a Ceylon Project is érdekes lehet a számodra!

    VálaszTörlés
  11. Tényleg remek poszt ismét.

    Én a javascript mellett tettem le a voksot jelenleg (mint második/harmadik nyelv), mert:

    1, viccesnek tartom, hogy MongoDB, NodeJS és kliensoldali JS kód segítségével egy nyelvvel megoldható a teljes stack
    2, rendkívül poén ágyban fekve pötyögni vim-be, azonnal visszatesztelni brózerrefresh-sel (ezt írtad Te is a pythonhoz, abszolút fun)... Java-s IDE-t indítani itthon már kevés a lelkierőm
    3, lehet kapni kis funkcionális programozás szájízt, ha épp arra van kedv, pl. underscore.js segítségével

    VálaszTörlés
  12. Én is nem rég kezdtem Python -ozni. A PyDev nevű Eclipse plugin -t használom, így az IDE is ismerős (elég sok shortcut ugyanaz, mint a JDT -ben).
    Viszont a Java után a duck typing marha idegesítő: felcseréltem két ősosztály konstruktor paramétert és csak futási időben szólt be, aztán mehettem debugolni (a kódot nézve nem tűnt fel...).
    Ennek ellenére elég jól kitalált nyelv, bash és bat szkript után milliószor értelmesebb.

    VálaszTörlés
  13. Nekem az a bajom a Pythonnal, hogy régi, és nem a nyelv, hanem a környezet, és a megoldások csomó olyan dolgot hurcolnak magukkal, amiket azóta másként, -- és ahogy az idő megmutatta -- jobban oldunk meg.

    Python környezetben (tehát nem a nyelvben) nagyon nem értem, hogy miért kell egy virtualenv kialakítása, miért kell az egész interpretert átmásolni (symlinkeket csinálni), ahhoz, hogy olyan környezetet hozzak léátre, ami nem interferál a többi, ugyanazon a gépen telepített Python alkalmazással. Java-ban ezt egyszerűen megoldottuk:

    Van a JRE, vagy a JDK, ahova a JAVA_HOME mutat, meg azt a java-t indítottuk el, és a CLASSPATH-ban benne van, hogy a classloader honnan vegye. Ha akarok, akár classloader-t is írhatok, ha Vicián István meg nem tiltja, minthogy az már keretrendszernek számít.

    Pythonban is van PYTHONPATH, de miért nem azt használja a Pythonos közösség? Persze én használhatom, de akkor az nem lesz Python like, és nem illeszkedik az elterjedt konvenciókba. Nem fog működni az easy_install, meg még nem tudom, hogy mi.

    A virtualenv.py pedig 64bites windows-on elhasalt.

    Ebből azt érzem, hogy nincs mögötte akkora támogatás, mint a Java mögött. Amatőrebb, bizonyos értelemben.

    Az sem tetszik, hogy a string az nem unicode, hanem byte tömb. (Na ez pl. az egyik nem kompatibilis változás a Python 3-ben, mert ott már unicode a string.)

    Régen, még 2000 előtt pythonoztam keveset, de nekem először assembly, C, Perl, BASIC, PASCAL, FORTRAN (nem ebben a sorrendben voltak), és csak ezt követően jött a Java. Így nekem azokra a feladatokra, amikre Isván elkezdte használni a Pythont inkább a Perl volt ott. Viszont most szembe jött a feladat, egy Python/Pylons/SQLAlchemy trióval.

    VálaszTörlés
  14. Ami nem tetszik a Python-ban, az a GC elégtelensége (egy jó leírás erről példával: http://www.kylev.com/2009/11/03/finding-my-first-python-reference-cycle/)

    (amúgy nagyon nem kiabálhatok, mert pontosan ezt az algoritmust implementáltam egy saját interpreteremben 1997-től kezdve)

    VálaszTörlés
  15. "És mi a helyzet a Groovy-val?" Szerintem Java mellett második nyelvnek nem pont a Groovyt érdemes választani. Szerintem ha az ember körbe akar nézni, akkor ne csak a dobozon belül forgassa a fejét, nyissa ki az ajtót.

    VálaszTörlés
  16. Ha ki akarsz kerülni a dobozból, akkor a Scala sem jön szóba.

    VálaszTörlés
  17. Jómagam a PHP, JavaScript, (PL/)SQL, VB/C#.NET út után kezdtem el alternatívákat keresni. Próbálkoztam Scalaval, ami remek volt, viszont akkor még (egy-másfél éve) az eszköztámogatás pocsék volt, s még erős gépen is szörnyű lassú volt a fordítás, így végül otthagytam. Viszont hatással volt arra, hogy programozom C#-ban, s ennek örülök :). Jelenleg én is a Pythonnál kötöttem ki: többplatformú (IronPython .NET-re) és párom netbookján is villámgyorsan fut.

    Legnagyobb fájdalmam a 3.x backward incompatibility. Jó, hogy van 2to3, de az egész 3.0 élmény döcögős, még sok népszerű library nem támogatja (pl.: BeautifulSoup).

    A virtualenv egyébként nekem pont pozitív élményem, még ha értem is Verhás kolléga fenntartásait (mondjuk CLASSPATH-ot debugolni nem szeretek!) Én szeretem a lokális, bináris függőség tárolást (pl. a Microsoft is ebbe az irányba megy fejlesztéshez (NuGet), pedig a GAC pont a verzióproblémák megoldására lett kitalálva). Ha csak egy setup.bat/sh kell a verziókezelőbe, s utána nem akadnak össze a különböző projektek különböző verziójú függőségei, már boldog vagyok. A virtualenv-el ezt meg tudtam oldani :)

    Az is nagy élmény volt, hogy a nemrég talált distutil problémát helyben tudtam javítani pár perc alatt (meg persze nyitottam egy bugot is https://bitbucket.org/tarek/distribute/issue/212/reading-bytes-instead-of-string-from :), s tudtam tovább haladni.

    A 64 bites problémák sajnos számos más platformra is igazak. Ez persze nem felmentés/magyarázkodás, inkább csak a döbbenet, hogy miért-is-nem-működnek-már-ezek jellegű tehetetlen karszéttárás. A http://ndc2011.no videók között van egy Richard Campbell-el a skálázásról, ahol is az a tanácsa, hogy 64 bites windows, de 32bites assemblyt használjanak, mert valamiért úgysem fog működni az AnyPlatform/x64)... Javaban annyire nem vagyok járatos, ott a 64 bit már megoldott probléma (driverek, stb)?

    VálaszTörlés
  18. Nálam PHP volt a fő csapásirány, de mellette volt PL/SQL, Transact SQL, Perl, Javascript, kis .Net

    Most java a fő irány.
    Az a PHP után tetszik a javaban, hogy sokkal jobban kikényszeríti az OOP használatát, ezért nagyobb alkalmazások esetén sokkal jobban "kénytelen" vagy jobb szerkezetű alkalmazást írni. Php esetén ehhez több önfegyelem kell. Ezzel együtt php-ban nagyon gyorsan lehet valami működőt létrehozni. Ameddig az embernek a php-n kívül nincs másra rálátása, addig nem zavarja nagyon a php nevezéktana és a névterek kezelése. Viszont Javaból visszanézve ezek már igen zavaróak.

    A korábbi hozzászólásokhoz még annyit hozzátennék, hogy bár a webes alkalmazások esetén elvileg kb. mindent meg lehet csinálni phpben és javaban is, mégis a felhasználás körében csak részben van átfedésben. Üzleti környezetben (legalábbis nálunk) meglátásom szerint .net és java dominál, a kevesebb üzleti logikát tartalmazó inkább webes fejlesztésekben a php dominál. Komolyabb üzleti rendszerek futtatásakor nem releváns szempont, hogy van sok tárhelyszolgáltató, ami támogatja.

    Mostanában kicsit több időm volt, hogy körbenézzek mindenféle nyelvek, technológiák között. Az én választások a CouchDB-re esett és a Ruby on Railsre (és ezzel együtt persze a rubyra is). CouchDB érdekes volt, de azokban a problémakörökben, ahol mozgok, nem tudnám használni, ezért végül hagytam. A RoR környezet ezzel szemben sok szépet és érdekeset mutatott. Ezeket sem biztos, hogy tudom napi szintű munkában használni, de sok olyan megoldást láttam, amiből tanulni lehet, mégha megmaradok továbbra is php/java vonalon.
    Az utóbbi idők másik érdekes felismerése volt számomra, hogy végignézve a mostani legdivatosabb web2-es szolgáltatások, amik nem régen (<5év) indultak, a felhasznált nyelvek, eszközök teljesen megváltoztak. Korábban ezeket jellemzően valamilyen php-mysql kombó segítségével követték el, de az újabb esetekben sokkal inkább rubyt, pythont használnak sok esetben valamilyen nosql megoldással kiegészítve. Web2-es szolgálatások esetén java, .net (itt egy érdekes kivétel a stackexchange.com) továbbra sem nagyon tört előre.

    Az eredeti felvetés az volt, hogy ki milyen nyelvet tanult meg kedvtelésből. A választásban ezzel együtt mégis szempont lehet, hogy a megtanult technológiát hogyan lehet a napi munkában is kamatoztatni.
    Ezzel kapcsolatban kérdezném azokat, akik pythont, rubyt jelöltek meg iránynak, hogy magyar viszonylatban mennyire látják ezeket eladható tudásnak, illetve jellemzően milyen jellegű projekteket szoktak ezeken a nyelveken megvalósítani (egyedi szoftver, termék, szolgáltatás, stb.)?

    VálaszTörlés