Python - Ruby - Groovy?

Szkriptek: Python, Perl, Bash, ...

Nehéz dönteni.

Groovy jó lenne a brutálsok Java lib miatt, meg amúgyis Java-t használok mostanság.

Ruby tetszik, de nem ismerem annyira.

Pythonnal meg elég sok command line-os util létezik, akár pl. Arduino-hoz is, viszont ha jól tudom, az unicode kezelés elég kezdetleges.

Szeritnetek? Előnyök, hátrányok?

(Univerzális scriptnyelvnek kéne, meg Arduino-t tutujgatni a későbbiekben, ahogy látom, emiatt a Groovy ki is esett).

  • 5481 megtekintés

( develru | 2012. 12. 05., sze – 17:03 )

Groovy-t egy projektben használtam, így nem sok mindent tudok róla mondani. Java-s projekthez, pluginozáshon kiváló lehet.

Pythont kedvelem. 3.x unicod-ot használ minden szövegre már nem lehet keverni. Bár nekem 2.x alatt se volt vele problémám.

Ruby-t nem használtam.

Nagyon szubjektív véleményem szerint én a Groovy-t nem használnám, akkor már Java. Egyedülálló nyelvként nem látom értelmét. (De lehet csak a tudatlanságom miatt.) Python és Ruby közül meg válaszd azt ami neked a szimpatikusabb, szerintem egyikkel se fogsz rosszul járni. (Itt is megjegyzem aktívan Ruby-t nem használtam, de sokan esküdnek rá.)
---
arch linux user

Ruby egy izgalmas darab, de (tévedés és tudatlanság jogát fenntartva) úgy vettem észre, hogy kissé aluldokumentált és a komolyabb (de ingyenes) IDE-k nem viszik túlzásba a támogatását. Nem emlékszem, netbeans v. eclipse plugin volt, amit "kissé" bugosnak találtam.
Végül e két dolog miatt döntöttem úgy, hogy inkább a pythonnal kezdek ismerkedni.

Hat nem tudom, en a JetBrains RubyMine nevu IDE-jet hasznalom, az konkretan annyira ra van epitve a Ruby nyelvre, hogy refaktoralni tud benne, meghozza nyelvspecifikusan. Tulajdonkepp az egesz IDE a Ruby nyelvrol szol. Megkerik az arat, de cserebe nem kell kompromisszumokat kotnod.

Aluldokumentalt... magarol a nyelvrol van programozoknak es total kezdoknek szolo konyv is. De ezen felul papirformaban is latott mar napvilagot konyv. Ja, es ne felejtsuk el az orokzold Pragmatic Programmer konyvet sem.

Ami az alaprendszert illeti, abbol ugye van az ujabb (1.9) meg a regebbi (1.8) verzio, nehol elternek, foleg az unicode/egyeb encodingok kezeleseben, illetve kapott par uj API-t.

Es hat ugye ne felejtsuk el, hogy minden gemnek van (ilyen vagy olyan mertekben kitoltott, de mindenkeppen) sajat dokumentacioja, meg annak is, ami csak GitHubon van fenn.
-- 

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

Nem merültem el benne túlzottan.
Negatív tapasztalatok (két éve történt, azóta nem foglalkoztam vele)
- valamelyik beépített függvényhez, osztályhoz kerestem doksit, de csak annyit találtam róla, amennyit a neve is elmondott róla. Az, hogy van doksi, meg az, hogy ez a doksi mennyire használható, azért nem egy kategória ;)
(és itt most kifejezetten valami language reference jellegű dolgot hiányoltam)
- kerestem az említett eclipse-hez v. netbeans-hez ruby plugint, de iszonyat bugos volt. (amit írtál, arról most hallok először)
- doksi kapcsán a szerzőjétől származó idézetet láttam még: "legjobb dokumentáció a forráskód" - ezzel addig egyet is értek, amíg nem a nyelv elemeit kellene forráskódból visszafejteni. :)

- könyvből egy magyarra fordított könyvem van, hihetetlenül gyengének tartom.

De mondom, ezek egy két évvel ezelőtti történet és úgy voltam vele, hogy a kisebb ellenállás irányába megyek.
Maga a nyelv egyébként tetszett a tutorialok alapján.

Ja! Még valami: gem-ek... Borzasztóan utálom, ha egy rendszerben kétféle csomagkezelő működik. Felrakok pl. apt-vel egy ruby-t, hoz magával pár csomagot, majd ugyanezen csomagokat kénytelen vagyok gem-mel valahova máshova is felpakolni a gem függőségek miatt.
(régebbi Debian + Oracle interface ruby-hoz kapcsán jött elő egy ilyen helyzet)

LangRef, nem egy mostani darab, de azert meg hasznalhato, bar sokminden valtozott.

Gemek: Oszinte legyek? Ez a Debian/Ubuntu csomagolokrol allit ki szegenysegi bizonyitvanyt. Ugyanis _normalis_ rendszeren a rendszer altal feltelepitett csomag egyben gemkent is viselkedik - Fedora, openSUSE, Gentoo, Arch... mind meg tudtak ezt a szintet ugorni. A tobbiekkel nem tudok mit kezdeni.

Egyebkent a Ruby tipikusan az a nyelv, ahol felrakjuk az interpretert, majd elfelejtuk a disztro sajat csomagkezelojet, foleg azert, mert ott szinte mindig elavult csomagok vannak.
-- 

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

> Egyebkent a Ruby tipikusan az a nyelv, ahol felrakjuk az interpretert, majd elfelejtuk a disztro sajat csomagkezelojet,

Na, en pont ezert nem hasznalok rubyt. Ha egy nyelv kozossege ugy gondolja, hogy ok jobban tudnak csomagkezelni, mint a distrok, akkor biztosan elbasszak. Eddigi rubys tapasztalataim alapjan ez a rubys gem fejlesztokre tokeletesen illik. :P

--
|8]

Mivel a disztrok tobbsege altalaban eb@ssza a gemek csomagolasat, igy en nem lennek ennyire meglepodve ezen. Nincs sok szabaly, amit be kell tartani egy gem csomagolasanal, de azt kovetkezetesen be kell. Es van olyan disztro, amelyiknek sikerul is. Sajnos keves.

Egyebkent nem kell ezt ennyire lesarkitani, allitom neked, hogy a python egg fejlesztok kozott is vannak ilyen problemas egyenek. De attol, hogy valaki permanensen az ujjat csapkodja a kalapaccsal, meg nem a kalapacs a hulye.
-- 

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

A gemekkel a fo problemam az, hogy jelentos tobbseguknel a fejlesztok semmi ingerenciat nem mutatnak arra, hogy a gemjuket csomagoljak. Nem csak arrol van szo, hogy az ember becsomagolja az egyes verziokat, es szevasz, mert az tenyleg egyszeru, nehez elszurni. De amikor mar arra is kell figyelni, hogy bizony van ami a gemre dependal, es az uj verzioval azt nem kene eltorni, vagy ha megis, azt valami ertelmes modon kezelni, onnantol mar sokkal nehezebb a helyzet. ERRE a gemek alkotoi az esetek tobbsegeben nem figyelnek tapasztalataim szerint. Upgradeljek mindent ami dependal ra... kosz.

Es jah, python eseten is vannak ilyen problemak, de kevesebb.

Miheztartas vegett, rubyt keveset hasznaltam, redminet es octopresst hasznaltam egy ideig, ezek alatt probaltam upgradelgetni egy-egy gemet, amikor javitodott bennuk valami bug. Ennek hatasara eltort a teljes stack, es csillio mast is meg kellett hozza upgradelni, valamint sajat kodot is frissiteni kell, mert API stabilitas az nem meno, meg bugfix releaseben sem. (Tortent ez ugy, hogy nem hasznaltam semmi distros cuccot, hanem a rubysok altal javasolt modszerrel kezeltem a rubys dolgaim)

Pythont lenyegesen tobbet hasznaltam, es mig ruby eseten kettobol kettovel kolosszalisat szivtam, python eseten eddig ket tucatbol egynel tartok. Nemileg jobb arany.

Node nem rantelek tovabb, privatban szivesen elbeszelgetek barkivel a rubys kalandjaimrol.

--
|8]

Ja, nagy általánosságban a ruby közösségre szerintem is jellemző a bleeding edge technológia, a folyamatos "előre menekülés". Sok gem eltűnik a ködben és jön az új ami kiváltja, release early - release often, stb. Jó code coverage nélkül öngyilkosság a gem update. A Rails is gyakran jelöl deprecatednek alapvető elemeket, nem szívbajosak. A ruby világához képest az ócsárolt kernel API olyan stabil mint a kínai fal. :)

De ugye a bleeding edge technológiának megvannak az előnyei is, illetve nem minden projectben kell gemek hadát használni, az stdlib pedig nem ennyire mozgó célpont.

Ezen felul pedig a ruby kozossegben van egy technologia, gem freeze-nek hivjak. Ez azt takarja, hogy van egy keszletnyi gemed, amivel mukodik az appod, es nem bantod. Ha valami bug van, akkor az ugye fejlesztes, kikiserletezed a kovetkekzo gem keszletet, freeze, nem bantjuk.

Mondjuk a verzio inkonzisztenciaval nem talalkoztam meg komolyabban. En bundlert hasznalok, az kepes az osszes fuggoseget lekovetni, es szinkronban frissiteni.

Ja, es a normalisabb gemek eseteben a deprekaciotol felni nem kell, mert a legtobb esetben vagy jobb lesz, vagy biztonsagosabb az app. A Rails tipikusan ilyen.

Egyebkent meg en azt erzem, hogy az egesz Linux kozossegre is jellemzo a bleeding edge technologia, a folyamatos elore menekules. Na de ez mar privat velemeny :-)
-- 

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

( dap | 2012. 12. 05., sze – 17:42 )

A Groovy túl nehéz scriptnyelvnek.

A Ruby mint nyelv szerintem kiváló. Én használom scriptelni (oneliner-ekre, bash/awk/sed helyett, ld '-n' opció), GUI-zni (Qt), webre (Rails), jól skálázódik. Hátránya a gyenge VM: pl ha egyszer lefoglalta a memóriát az oprendszerből, azt utána soha nem adja vissza és a belső memória menedzsmentje nem igazán barátja annak sem, hogy legalább az oprendszer ki tudja swappelni a már nem használt lapokat. Ez viszont idővel javulhat és ha nem gond, hogy néha újra kell indítani az alkalmazást, akkor ez nem fog zavarni. A gems rendszer szerintem kiváló. Néha vannak gondok a stabilitással, magyarán láttam már segfaultot - persze ezért lehet felelős egy gem is.

A Python egy erősebb VM-el bír, gyorsabb és jobban spórol a memóriával is, de oneliner scriptekre nem igazán alkalmas, ahhoz túl szigorú szerintem. Webes fronton a Rails erősebb húzónév mint a Django és azt kell mondjam, nem csak a hype végett. A PyPi csomagkezelőt nem igazán ismerem, de AFAIK nincsenek olyan komoly hagyományai/támogatása mint a gemsnek Rubyban, persze ez erősen szubjektív vélemény.

Disclaimer: pythonban kevesebbet programoztam, csak néhány demo projectem volt, hogy eldöntsem Ruby vagy Python. Egyikkel se jársz rosszul.

A VM-hez: amit irsz, az ugye elsosorban az MRI VM-rol szol, a Rubinius VM teljesen mas rendszerben epul fel, elsosorban LLVM alapokon, sokkal jobb memoriamenedzsmenttel (van jopar gem, ami pont a lazy memory management miatt nem fut vagy crashel el Rubinius alatt).

Aztan ott van a JRuby is, mint pelda, ez teljesen a Java-ra hagyatkozik memoria menedzsmentben, kovetkezeskepp pont olyan lehetosegeid vannak benne, mint egy normal Java alkalmazasban. Bonuszkent megkapod a komplett Java okoszisztemat is, JDBC-stul, Swingestul.

Illetve amit irsz az MRI-rol, az sem teljesen igaz, a Ruby-ban van GC, ha kell, ki is lehet kenyszeriteni a futasat, viszont a szarul felepitett kodok valoban kepesek memoriaevest okozni.

A segfaultokert - foleg ha amugy binarisbol raktad a Ruby-t - 85%-ban a nativ gemek a felelosek.

A pythonnal a legnagyobb problema, hogy 3-4 fajta csomagkezelo van ra. Az easy_install, a pypi, a pip ezek kozul a legismertebb. En nem tudom mi koztuk a kulonbseg, oszinten szolva nem is erdekel, mert ahol 1 dudasnal tobb van egy csardaban, ott mar bizony tomegnyomor van, azt meg nem szeressuk.

Amiben a python szerintem nagyon eros, az a GUI frontendre dolgozas. PyQt/PyKDE, PyGtk, wxPython mind nagyon kiforrott frameworkok. A Ruby is tamogat ilyesmiket, de en ugy erzem, hogy ez a resze annyira eros, mint pl. a PHP ilyen iranyu torekvese: van, de nem ez a fo cel. (A Korondum pl. nagyon lassan jott fel az uj KDE-hez, a Ruby/Gtk -ban van egy csomo jo otlet, de a dokumentacioja verciki, illetve lehetne sokkal Rubysabb is, egyedul talan a JRuby + Swing az, ami turheto frontendes rendszert alkot).

Illetve a python nagyon jo webes middlewarekhez, kis, egyszerubb XML-RPC bridgekhez, vagy rendszerkozeli frontendekhez. Mire gondolok: pl. Xen gepek managementje. A Xen-hez van egy faja Python API, ezt viszonylag gyorsan es konnyen ki lehet dobni egy webes feluletre (akar csak egy webes API formajaban).
-- 

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

Egyebkent Ruby-ban/Rails-ben az kezd el programozni, akit nem zavarnak az eros konvenciok. Pl. minden Rails alkalmazasnak van egy kotott felepitese, amit ugyan at lehet varialni, de ezzel csak magadnak okozol 1) fejfajast 2) plusz munkat, ugyanis _minden_ epit erre. De ott vannak az elnevezesi konvenciok is, a routing-controller-modell mapping haromszoge nagyon fel tud borulni, ha valaki elkezd egyenieskedni. Meg a valtozo elnevezesekre is van konvencio, legalabbis ami a controlleren beluli instance valtozokat illeti.

Aki ebbe bele tud szokni, elfogadja es raall az agya, az boldog ember. A tobbieknek meg ott van a PHP.
-- 

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

( MrPrise v | 2012. 12. 05., sze – 19:13 )

Aki használható Ruby-t támogató editort keres, annak ajánlom figyelmébe a sublime 2-t. Szerényen csak text editornak titulálják, pedig ettől azért több. Ingyenesen lehet használni (de nem is drága). Támogat egy rakás más nyelvet is a Ruby-n kívül és nagyon gyors.

( wachag | 2012. 12. 06., cs – 12:15 )

Jython-ra is ránézhetsz. Már kevésbé vacak, mint volt.