ugrás a tartalomhoz

New PHP to Ruby Reference

Török Gábor · 2008. Már. 21. (P), 08.35
php.net mintájú referencia a PHP-függvények Ruby-s megfelelőiről
 ■
1

Állat jó ez a szájt, de ezt már lehet, hogy mondtam.

Fraki · 2008. Már. 21. (P), 10.22
Állat jó ez a szájt, de ezt már lehet, hogy mondtam.
2

aha

Fekete Ferenc GDA · 2008. Már. 21. (P), 10.46
aha,már mondtad:) vagy valaki más, nem emlékszem.
3

Hi

exodus · 2008. Már. 22. (Szo), 00.04
Tudtok valami pozitivat is mondani a Rails Ruby mellet?
En a c - stilusu programozasi nyelveket kedvelem, de szeretek uj dolgokat tanulni viszont a ruby nem fogott meg.
Lattam par demot de az hogy egy sorban elhelyezett parancs szekvenciakkal megoldott, rovid kod altal megoldott algoritmus megoldas nem nagyon hatott meg es nem is gyozott meg.
4

Hát, pedig a rövidség erény.

Fraki · 2008. Már. 22. (Szo), 02.59
Hát, pedig a rövidség erény.
5

nem

Fekete Ferenc GDA · 2008. Már. 23. (V), 02.01
engem meg a c és a php nem fogott meg, mert rohadtul nem szeretek feleslegesen (és sokat) gépelni:)
6

+1

Joó Ádám · 2008. Már. 23. (V), 13.41
Ott a pont :)
7

Váltás

vbence · 2008. Már. 23. (V), 14.36
A C szintaxist nagyon sokan ismerik és tudják használni. Akár azt is mondhatnám, hogy kiállta az idő próbáját. Szerintem szerencsésebb megközelítés lett volna ha kibővítik az alap szintaxist, így lassan rá lehetne szokni a frissebb eszközökre. (Ahogy pl a JavaScript generációi is csinálták).
8

A szintaktika a lehetőségek kifejezésének eszköze

Török Gábor · 2008. Már. 23. (V), 14.57
JavaScript nyelvtana mihez hasonlít? C-hez sem, de Javához sem. Vagy éppen mindkettőhöz annyiban, hogy Algol derivált szintaktikájúak. A Ruby sajátos nyelvtana teszi pont azt lehetővé, hogy például funkcionálisan (funkcionális gondolkodásmóddal) lehessen benne programozni.
11

Hibákhoz vezet

Joó Ádám · 2008. Már. 23. (V), 22.28
Szerintem csak összezavar, és könnyebben vezet hibákhoz.
13

Hibák

vbence · 2008. Már. 23. (V), 22.56

var x = new Object ();
x.width = 300;
x.height = 200;
vagy

var x = {width: 300, height: 200};
Miért vezetne hibákhoz, ha az új módi mellett azért még használhatod a régit is?
15

Mit lehet, mit nem

Joó Ádám · 2008. Már. 24. (H), 02.07

getElementsByTagName('p')[0]
A fenti működőképes JavaScriptben, de PHP-ban nem. Nekem beletelt egy időbe és némi frusztrációba, mire megjegyeztem.
17

És az, hogy...

vbence · 2008. Már. 24. (H), 11.14
$ kell minden változó elé? Vagy, hogy . helyett -> oprtátort kell használni? De nem tudom mennyire lett volna könnyebb az életed, ha a JS és PHP két teljesen különböző nyelv lett volna, mondjuk a PHP a pascal szintaxisát követné...

Én at mondom, legyenek új vezérlő szerkezetek, legyenek rövidítések, de mindezt (nagy részét) meg lehet csinálni a C szintaxis kibővítéseként is.

Úgy próbálok példálózni, hogy nem túlzottan simerem a ruby-t, de láthatóan irtózik a zárójelektől. Itt egy példakód:
"a\nb\nc\n".each_line{|l| print l}
valóban rövidebb, mint a JS párja (nem 100%an egyezik)
"a\nb\nc\n".each_line(function (l) { print l } );
de a zárójelként hazsnált pipe karaktertől kilel a hideg. Ha mondjuk okosítani szeretnénk a JS-t:
"a\nb\nc\n".each_line(l){ print l };
...ez egy lehetőség a sok közül.

Persze ha nem szerted a c szintaxist, szived joga. Itt egy új nyelv, garbage collectionnel meg társai, egy lelkes csapattal maga mögött. Lehet neki örülni.
18

A pipe nem simán a zárójelet helyettesíti, hanem a lambda...

Fraki · 2008. Már. 24. (H), 14.08
A pipe nem simán a zárójelet helyettesíti, hanem a lambda fv-ek paramétereit jelöli, ami egy speciális eset, és jobb nyelvekben külön szintaxissal támogatják. A JS is efelé fejlődik, de nem úgy, ahogy mutattad. A te verzióddal az a gond, hogy nem látni, hogy a két zárójeles (sima és kapcsos) blokk egy egység volna, továbbá megbontja azt a szabályt, hogy a fv-hívás paramétereinek zárójelek közt kell lennie. Egy lépéssel hátrébb:

"a\nb\nc\n".each_line((l){ print l });
A sok zárójel összezavarja kicsit a képet. Inkább meghagyták a hosszadalmas "function" szót, és a blokkhatáró kapcsos zárójeleket faragták le, meg a "return"-t. Ez nem annyira idegen a nyelvtől, mert a blokkhatárolókat a vezérlőszerkezetekben eddig is el lehetett hagyni (egy parancs esetén).

Ebből a manőverezésből is látható, hogy a lambdázáshoz nagyon is szerencsés jól elkülöníthető szintaxist rendelni. A Python szintén külön kulcsszóval oldja meg, a Rubynak viszont már alacsonyabb szinten be van építve a nyelvtanába, és ezt épp a saját lexikai jel teszi lehetővé. (A pipe egyébként a logikai/matematikai nyelvből van átvéve.) No és persze ez az egész arra is rávilágít, milyen nagyon része a nyelv filozófiájának a metaprogramozás. Annyira, hogy a rubyban még a rövidített JS- vagy a python-szintaxis is zavaróan verbóz lenne.

És ugye tudjuk, hogyha már ilyesmikről esik szó, akkor jobb nem gondolni a php-ra, mert az olyan, mintha tériszonyosként lenéznénk a mélybe...
10

gépelés

Hodicska Gergely · 2008. Már. 23. (V), 18.48
Nem hiszem, hogy egy programozási nyelvet az alapján kéne megítélni, hogy mennyit kell gépelni. Ha ez számítana, akkor mindenki Perl6-ban nyomná. A programozási munka nem számottevő része az az idő, amíg begépeled a szöveged, szóval a rövidség önmagában szerintem nem erény.

Ha valami tetszett a Rubyban az inkább a kifejező készsége, de egyenlőre úgy látom, hogy nem terjed annyira a nyagyterhelésű oldalak esetében, illetve a pont a Twitter kapcsán lehetett arról is olvasni, hogy egy ilyen jellegű oldal esetén azért már a RoR sem annyira szép és jó, eléggé sok mindent magadnak kell megírni ahhoz, hogy egy jól skálázható rendszert kapj.


Üdv,
Felhő
12

A gépelési mennyiség ugyan talán nem a legrelevánsabb...

Fraki · 2008. Már. 23. (V), 22.42
A gépelési mennyiség ugyan talán nem a legrelevánsabb aspektusa a rövidségnek, hanem, mint írod, például a kifejezőkészség, csak hát végülis az előbbi mégiscsak következik az utóbbiból.
14

ehhez kapcsolódva

yaanno · 2008. Már. 24. (H), 01.48
Hadd linkeljem ide a top100 listát - ezek közt szép számmal vannak nagy terhelésű oldalak. Ezzel nem azt mondom, hogy pl. jelenleg egy java környezethez mérhető stabilitásról lehet beszélni, de úgy tűnik, hogy a Rails is kezd az enterprise felé nyitni, ill. amennyire tudom, készülőben van egy java szerű virtuális környezet, ami megdobhatja a ruby további térhódítását. Én drukkolok neki :)
19

top 100

Hodicska Gergely · 2008. Már. 24. (H), 14.41
Hát ebben a top 100-as listában kb. a Twitter az egyetlen, és ő is csak a 642 (bár valszeg a Twitter igazából előrébb van ténylegesen, csak náluk elég nagy százalék az API hívás, amit az Alexa nem nagyon tud mérni). Ebből nem az derül ki, hogy nagyon hasznánák a Top oldalak között. De igazából arra akartam csak utalni, hogy oké, hogy a RoR alap esetben rengeteg dolgot megspórol nekünk, de a Twitter kapcsán azt lehetett olvasni, hogy elég rendesen bele kellett nyúlni ahhoz, hogy egy skálázható rendszert tudjanak kapni.


Üdv,
Felhő
21

nem jó példák :)

yaanno · 2008. Már. 24. (H), 14.55
Egyetértek veled, és a lista sem a legjobb példa volt :) A Jobster talán megfelelőbb példaalkalmazás lett volna.
26

skálázható

Fekete Ferenc GDA · 2008. Már. 24. (H), 21.12
Az van ,hogy a ruby/rails/merb/stb. skálázható.

Pl itt egy top 10-es facebook alkalmazás, 300 millió pi-vel havonta.

Na, most megint pedobtam egy kis csámcsogni valót.
28

ellenkezője?

Hodicska Gergely · 2008. Már. 24. (H), 21.52
Az van ,hogy a ruby/rails/merb/stb. skálázható.
Na az van, hogy senki sem állította az ellenekzőjét. :) Csak annyit, hogy ha ilyen rendszerről van szó, akkor azért elég sok előnyét elveszti a RoR. És ezt a Twitter egyik fejlesztője mondta, az idevágó rész kiemelve:
The common wisdom in the Rails community at this time is that scaling
Rails is a matter of cost: just throw more CPUs at it. The problem
is that more instances of Rails (running as part of a Mongrel
cluster, in our case) means more requests to your database. At this
point in time there’s no facility in Rails to talk to more than one
database at a time. The solutions to this are caching the hell out
of everything and setting up multiple read-only slave databases,
neither of which are quick fixes to implement. So it’s not just
cost, it’s time, and time is that much more precious when people can[’t]
reach your site.None of these scaling approaches are as fun and easy as developing
for Rails. All the convenience methods and syntactical sugar that
makes Rails such a pleasure for coders ends up being absolutely
punishing, performance-wise. Once you hit a certain threshold of
traffic, either you need to strip out all the costly neat stuff that
Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move
the slow parts of your application out of Rails, or both.

Lehet rajta csámcsogni. ;)


Pl itt egy top 10-es facebook alkalmazás, 300 millió pi-vel havonta.
Ez most mire példa? (Ez lehet kb. a Twitter napi forgalma. ;) Illetve a Facebook napi fogalmának 1/6-a).


Üdv,
Felhő
16

Lásd fent

Joó Ádám · 2008. Már. 24. (H), 02.11
Lásd a fenti példát a vbencének írt válaszomban. Én azért jobb szeretem, ha nem kell két sorba írnom és feleslegesen létrehoznom egy változót. (Kódkiegészítést sem használsz?)
20

array return dereferencing

Hodicska Gergely · 2008. Már. 24. (H), 14.52
Hát ez pl. valóban jól tudna jönni, de ezzel együtt is az a véleményem, hogy nem ezen fog múlni. Pont nézegettem ezt a rubyforphp oldalt, és nem az lett a benyomásom, hogy hú de mennyivel kevesebbet kell gépelni, sőt sok esetben a PHP kód volt rövidebb.

Ami nekem tetszik, hogy szebben átgondolt az API, illetve hogy minden objektum, ami miatt néha lehetne egyszerűbben, kicsit rövedebben is fogalmazni, de mondjuk könnyű átesni a ló túloldalára is.

Kódkiegészítést sem használsz?
Hát nem értem itt a sem-et, mi az amit még nem használok? Másrészt meg ez ebben a témában kicsit öngól. Pontosan a kódkiegészítés miatt nem nagyon fog érdekelni, hogy XY dologhoz esetleg többet kéne írni, illetve az ismétlődő dolgokra meg úgyis kódtemplateket fogok használni.


Üdv,
Felhő
22

Az az oldal főleg api-megfeleltetésről szól, másrészt pedi

Fraki · 2008. Már. 24. (H), 16.23
Az az oldal főleg api-megfeleltetésről szól, másrészt pedig nem közömbös, hogy php->ruby irányú. Így nyilván nem fogsz olyan látványos példákat találni, amik a ruby előnyeit domborítják ki (sőt, természetes, hogy néhány esetben a php marad rövidebb).

Nem tudom például, egy ilyennel mit kezdenél php-ban:
lines.each { |line| line.length }

Kódkiegészítés: ez egy olyan segédeszköz, ami csak részben automatizálja a kóddal való munkát, de az alapvetően mindig manuális és mindig karakterszintű marad. S nem szünteti meg a rövidség jelentőségét. Nagyon sokat számít, hogy oda kell pötyögni azt a plusz $ jelet, ha fölösleges. Meg aztán eleve minek külső támgotásra hivatkozva védeni valamit, ha van annál egyszerűbb, kompaktabb, olvashatóbb...
23

rövid, kompakt != olvasható

Hodicska Gergely · 2008. Már. 24. (H), 17.27
Az az oldal főleg api-megfeleltetésről szól, másrészt pedig nem közömbös, hogy php->ruby irányú. Így nyilván nem fogsz olyan látványos példákat találni, amik a ruby előnyeit domborítják ki (sőt, természetes, hogy néhány esetben a php marad rövidebb).
Nem látom be, hogy miért lenne ez természetes. Meg azt sem, hogy miért ne lehetne akár a foreach-ről is írni itt. (Amúgy foreach($lines as $line) {$line}, azért ez nem annyira átláthatatlan.)

S nem szünteti meg a rövidség jelentőségét.
Szerintem a rövidség nem hordoz önagában semmit. Nem fog valaki ettől könnyebben olvasható kódot írni Rubyban, ez önmagában nem garantál semmit, sőt től nagy korrelációt sem látok a két dolog között.

Nagyon sokat számít, hogy oda kell pötyögni azt a plusz $ jelet, ha fölösleges.
Valóban szörnyű és időtrabló ;), amúgy meg nem fölösleges, hisz PHP-ban ettől lesz valami változó és nem konstans.

Meg aztán eleve minek külső támgotásra hivatkozva védeni valamit, ha van annál egyszerűbb, kompaktabb, olvashatóbb...
Amire eredetileg reagáltam, az a gépelés, ebben eléggé van jelentősége az IDE-nek. Abban egyetértek, hogy az olvashatóságot nem fogja az IDE javítani, viszont mint feljebb is utaltam ré a kompaktság és a rövidség önmagában nem hordozza azt. Sőt itt igazából Ruby esetén van több lehetőséged nem olvasható kódot írni.


Üdv,
Felhő
27

„Nem látom be, hogy miért lenne ez természetes.”

Fraki · 2008. Már. 24. (H), 21.34
„Nem látom be, hogy miért lenne ez természetes.”

Azért, mert ezek nem általános feladatok, hanem az egyik nyelv api-ja a másikkal megvalósítva. Ha fordítva lenne, ruby->php irányú ugyanilyen oldal lenne, ott valószínűleg nem találnál olyan példát, ahol a php rövidebb lenne, ellenben rengeteget találnál, ahol sokkal hosszabb lenne.

A foreach első látásra rendben van, de ha megnézed, ott van mellette a .map (eredetileg erre gondoltam), az .any, az .all stb. amelyek ugyanebbe a paradigmába tartoznak, és a sor bővíthető persze. A php ezek közül egyet valósít meg, két kulcsszót lefoglal rá, a többi legfeljebb api (és máris jöhet a create_function). Az egy nagyon szuper dolog, ha egy nyelv olyan szintaxist kínál, amelyik egy klasszikusan vezérlőszerkezetként felfogott konstrukciót is nyitott paradigmába képes helyezni. Ez csak úgy lehetséges, ha a nyelv annyira a blokkokra épít, mint a ruby.

Nálam a rövidség = jobb kifejezőképesség. Amíg nem esünk túlzásba, addig majdnem egyenlő az olvashatósággal is. (OK, csak majdnem; a túltömörítés egy létező, bár sztem ritka valami. Nekem általában fájdalmas a sok fölösleges referenciaváltozó, és sztem sokan sóhajtoznak néha így, akik szkripteltek már JS/Ruby/Pythonban.)

Az, hogy kevesebbet kell gépelni, tüneti dolog, bár nem elhanyagolható.

„Valóban szörnyű és időtrabló ;)”

Azért az, mert összeadódik.

„amúgy meg nem fölösleges, hisz PHP-ban ettől lesz valami változó és nem konstans.”

Jelentése van, a koncepció fölösleges.
24

Miért nem ezen (ezeken)…

Joó Ádám · 2008. Már. 24. (H), 18.05
Miért nem ezen (ezeken) fog múlni? Vagy pl. a másik, amit nagyon hiányolok (nem tudom, ezzel melyik nyelv hogy áll), az az, hogy nem tudok a példányosítás után közvetlenül tagfüggvényt hívni. Ismét egy sorral többet gépelek.
Apróságokból áll össze az ilyesmi, és ezekre nem fogsz kódkiegészítést vagy sablonokat használni. A másik pedig, hogy én nem is szeretem, ha használnom kell; egyszerűen nem áll kézre.

Ami nekem tetszik, hogy szebben átgondolt az API, illetve hogy minden objektum, ami miatt néha lehetne egyszerűbben, kicsit rövedebben is fogalmazni


Igen, a PHP-hoz képest való következetessége nagyon vonzó tud lenni.
25

program felépítése

Hodicska Gergely · 2008. Már. 24. (H), 20.34
Miért nem ezen (ezeken) fog múlni?
Egyrészt a programozás nem csak gépelésből áll, tehát eleve csak a programozás egy részéről beszélünk, amin szerintem minimálisan lehet nyerni azzal, hogy adott nyelvben lehet-e a függvényhívás után egyből []-t tenni. Szerintem a munkánk nagy része abból áll, hogy megfelelően tagolt programot hozzunk létre, kifejező elnevezéseket használjunk, jól olvasható, könnyen karban tartható legyen kód (plusz adatbázis tervezés, rendszer tervezés, stb.). Ezeken nem fog semmit segíteni ez a pár syntax sugar.

Vagy pl. a másik, amit nagyon hiányolok (nem tudom, ezzel melyik nyelv hogy áll), az az, hogy nem tudok a példányosítás után közvetlenül tagfüggvényt hívni. Ismét egy sorral többet gépelek.
Azért érdemes megnézni, hogy milyen esetekben lehet erre szükséged. Valahol egy kicsit fura, hogy csak azért hozol létre egy objektumot, hogy egyetlen függvényt hívj meg rajta. Nekem erre most két dolog ugrik be: egyik esetben kicsit olyan, mintha egy inkább statikus metódus jellegű dologról lenne szó, másik esetben meg valamifajta singleton jellegű dolog. Egyik esetben az osztályon meg lehet hívni a metódust, másik esetben meg úgyis van valami factory metódus, amin meg már megint lehet egyból metódust hívni.

Igen, a PHP-hoz képest való következetessége nagyon vonzó tud lenni.
Jaja, de ez számomra per pillanat kevés, hogy komolyan nekiálljak Ruby-zni. Tapasztalat azt mutatja, hogy elég jól együtt lehet azért élni a PHP-val is, egyenlőre elég lesz. Szóval nincs semmi bajom a Ruby-val, csak úgy érzem, hogy ezek a plusszok túl vannak dimenzionálva.


Üdv,
Felhő
9

pozitív

yaanno · 2008. Már. 23. (V), 15.03
a rails egy ruby nyelven írt keretrendszer, erről Ferenc sok jót (és rosszat is tuti) el tudna mesélni :)

a rubyról pozitív: objektum orientált programozáshoz tökéletes, kompakt (erre írtad hogy egysoros), átlátható működésű nyelv; beépített hibakeresés és tesztelési lehetőségek; "humanizált" metódusnevek :)