Svetla prihodnost za Ruby?

ima napram pitonu pa phpju je prou fletna. vsaj mene osebno pa me mot, da je zgolj dinamična(rad imam tipizacijo). ampak to je spet religijozen predsodek.RL izkušenj pa nimam kaj perveč. eden od razlogov je tudi da dokumentacija ni ravno na nivoju.

Prepocasen za karkoli izven web pageov, pa se tam bi raje kaj hitrejsega. Zadeva mi tudi idejno ni vsec.
Izredno pomembno za prihodnost jezika je tudi obstoj pravih toolov in knjiznjic.

od enega programerja, ki je delal z njo (rl projekte oz. za siht) sem slisal predvsem, da ima dokumentacijo v kurcu in da je veckrat moral iti gledat izvorno kodo, ker se zadeve niso obnasale tako, kot je mislil, da se bodo in ni nic pisalo v doc...

Glede na to, da ruby podpira duck typing, obstaja kaksno orodje, ki ti analizira kodo in preveri tipe?

MrBrdo je 1. jun 2012 ob 22:55 izjavil:

Dokumentacija ni tako slaba, pa tudi v obliki screencastov in interaktivnih tutorialov.
Če bi rad imel tipizacijo pa si poglej jezik Scala (tega uporabljajo npr. tudi pri Twitterju).

Glede dokumentacije je izgublena sama pri sebi. Podobno kot php ali python. Vcasih v std spacu stvari ne delajo ko je deklarirano. Potem je pa se najbolje poiskat dselujoc primer na internetu pa gruntat. Ampak to je bolj ali manj kronicen pproblem domacih dinamicnih jezikov. Zavoljo tega tudi nekako bolj ljubim trd pristop k jeziku. Ne da so tipi na koncu zgolj okraski k manipulacijam z stringi.
Eh scala... Njen problem je da probajo v std vključit vsako main stream novotarijo. Počas po premoru spet mal šlatam kodo pa nekak sta vsaj zame C in nemerle še vedno nekaj korakov pred drugimi če ne gre za zelo spacifične rešitve.

napsy: za foro sem spisal proof-of-concept za preverjanje tipov: https://gist.github.com/2880057 (glej spodnji del, kako bi potem zgledalo definiranje metode)
dost je hackish, ampak Ruby je tok cool da se to sploh da verjetno bi se dal tud dost bolj optimalno narest...

Zakaj taka fascinacija s temi jeziki, ki so nekako skupaj nametan kup stvari, ki so bile avtorju vsec. Brez moznosti za kakrsnokoli smiselno formalno semantiko in posledicno brez moznosti biti siguren v karkoli. Pa se trivialnih stvari, kot so vsote in produkti ne podpira prav.

Zelim si, da bi ljudje uporabljali jezike, ki uporabljajo vsaj nekaj stvari iz zadnjih trideset let teorije programskih jezikov, ne pa spake.

Ruby all the way!

Ja no za kakšno hardcore procesiranje in backend se strinjam da so strongly typed jeziki bolj primerni. Sam tako za nekaj na hitro poskriptirat, pa za frontend so pa dinamični jeziki res bomba.

@naraguta če castaš tipe v statičnih jezikih delaš nekaj narobe. Osebno se mi skoraj nikoli ne zgodi, da moram castat kar koli.

tedaj če delaš v javo nevem zakaj se sploh trudiš. in če je cel sistem tipizacije bazeran na principu boli me kurac kaj je class, kaj ti le to doprinese v kodi? prekleto da mi ni jasno. class-i oz tipi so tvoji prijatelji in ravno v javi je celo vsa mineštra strogo classificirana. različni patterni in frameworki ne delajo nič drugega kot silijo programerje v neko predivevanje kopulacije tipov med seboj. vsaj pri webu gre tipično za string manipulacije. backend je pa v ejb dosti bolj resno napisan, ampak načrtovan zopet z dobršno mero pretvorb med tipi v mislih. res da ideji včasi zgenerirajo vse interface on the fly, in sam mislim da je to večji del celo pravilen pristop ni pa edini.

če delaš zolj z relacijskimi modeli tvoje razmišljanje še niti ni povsem retardirano. pa še tu primerjava dveh objektov zahteva cast. ali lušćenje lastnosti iz objektov. niti efektno še manj pa elegantno. na kakem noSql torišču pa večinoma precej nerodno. (da se ne daješ s stringi je utvara, objekt ni nič vreden dokler ni neke klasifikacije in java ponuja samo eno vrsto dedovanja, pod naslednje je pa tud štorasta kar se tiče opratorjev, ekvivalenc , etc...) za samo konstrukcijo html + vsebine je to rahlo zamudno. pa če imaš čas in denar niti ne nepremagljiva ovira. to dapa niso konsistentni pa dokler aplikacija dela niti ni problem.
MVC(in različni frameworki) v javi je le mastrubiranje jave na vzorec RoR(ruby on rails).

castaš ne ket te mvc sili v monotono implementacijo. glede operatorjev pa pri kompleksnih štavilih smo kje? če delamo z matrikami(bog neday tabelami)...za 2+2 ne rabim jave ampak kalkulator, matemathico postimo potem ob strani. glede primerjave objektov pa preglej en graf z javo in bruhaj če zadeva ni sestavljena na začetku kot mora bit(razen če spišeš svoj mali db engine in uporabiš nek novi jezik(dsl)). pa še tu svet se spreminja ravno tako pa vzorci in paterni. spring napram ror je pa tako tako... en ta sili delat po nekem vzorcu ror pa vljkučevat stvari v nek zelo preprost layer kateri je hudimana prilagodljiv. spet stvar izbire.

ma spring napram ror je fajn, če delaš vse po vzorcu. ampak ror je simpl spring pa kompleksen, je pa res da spring se smodejno realizera v ideju ravno zato ker je zgolj framework. ror je pa lahek framework kateri manipulera z stringi brez slabe vesti.pa sploh me ne tunakj med dinamike ker me web kot tak ne zanima(itak ne koderam več). ampak dinamični jeziki in sam koncept ima svoje prednosti. katerih pa jaz "na žalost" nisem hotel konzumirat, no ja svoj čas sem spisal povsem funkcionalen portal z gdjem in perlom. za kodirat super(saj ne veš amšak zdelo se mi je boljše kot vsak-a cgi, java in c# kasneje) ampak po dveh letih odsotnosti je bila zadeva zame neberljiva. o javi pa spet ne morem sodit prav iz prve roke, tiste dni ko sem komercialno delal z njo je bil eclipse še visal age developer preview, Together je bila pa še vsaj za moj okus najprimernejši ide(ideje še ni bilo). ma bluzim a se da odpret kako temo o novostih v javi?

Sej nočem težit samo se mi ne zdi primerna tako široka razprava o Javi v tej temi Že smrdi malo po flamewaru.

sherman je 8. jun 2012 ob 22:07 izjavil:

MrBrdo je 8. jun 2012 ob 01:49 izjavil:

Pač tvoje mnenje, očitno si omejen na ne-dinamične jezike... In več kot očitno nisi nobenega dinamičnega prav veliko uporabljal.
Ti kr kucaj v Javi naprej pa good luck Upam da te ne bodo preveč zmotile novosti 7ke.

No ja, ta zakljucek ne temelji na znanih dejstvih. Posledicno je napacen. Od kje si na Javo skocil je tudi misterij. Obstaja kup drugih jezikov z boljsimi sistemi tipov.

Jaz le povem, da ne razumem fascinacije z Rubyem in nasploh fascinacije z jeziki, katerih definicija je bolj ali manj "koda je veljavna cee jo prevajalnik/tolmac sprejme". Posledicno je tezko karkoli resnega povedati o programih napisanih v takih jezikih.

In meni so tudi nekateri dinamicni jeziki vsec, a to nista Ruby in Python.

ma ja pol gremo lohk tud do theorem proverjev , pa pi(join) algebr, sam mislm da je bilo prej vprašanje mišljeno kolk se pa vam zdi rubi kot tak,onkraj taga lahko mi per žulmo neki sitov pa očitno dela.

Ma NASM ti omogoca veliko svobode pri kodiranju. Zdaj ce imas bolj slabega developerja ali pa ce se folk ne drzi nekih dogovorov, potem je vse skupaj nepregledno, zmedeno ... V nasprotnem primeru pa je lahko zelo fino. Pac, with great power comes great responsiblity. Ne recem da ne obstaja slaba stran NASMa.

Hocem reci, da naloga jezika je, da omogoca pisanje netrivialnih programov IN preprecuje napake, ki jih _vsi_ programerji zagresijo in jih znamo ze desetletja lepo kanonicno resit. Ruby kolikor vidim omogoca le nek nabor trikov, ki se zdijo kul, ne preprecuje pa programerjem delati bedastih napak. In vsi programerji delamo bedaste napake, ce jih jezik dovoljuje.

Sej mogoce je v redu za neka specificna podrocja. Ce premetujes nize potem je itak vse bolj ali manj izgubljeno, ker so stringi pac po konstrukciji nestrukturirani.

nebivedu:
http://railsforzombies.com/
http://railscasts.com/
http://ruby.railstutorial.org/ (osebno nisem uporabljal)
knjiga http://pragprog.com/book/rails4/agile-w... jo imam in je super, sem jo bral na WCju (js sm jo naročil iz amazon UK pa ni blo preveč drago, pa če boš kupval pazi da je zadnja izdaja)

also
https://rvm.io/rvm/install/
http://tryruby.org/

MrBrdo je 9. jun 2012 ob 21:35 izjavil:

Treba se je pač zavedat kje je performance sploh važen in tam kjer ni važen veliko raje uporabim kakšen dinamični jezik. Seveda pa ne bom šel neke hardcore matematike in računanja programirat v Rubyju.

Pa saj se ne gre za hitrost izvajanja (ceprav moram priznati, da mi je smesno koliko truda je vlozenega v hitro izvajanje skropucala od jezika, ki je javascript). Gre se za to, da ko imas mogocen sistem tipov in vse skupaj lepo zastavis, tezko napises legalen program, ki ne dela prav. Seveda je potem vprasanje, ce je tvoja specifikacija (torej tipi) smiselna, samo to je vprasanje tudi ce nimas tipov, oziroma imas poor-man's sistem z enim tipom. Zdaj, ce je vecina tvojih tipov osnovnih (torej stevila, znaki, tabele in podobni), potem mogoce ne profitiras veliko, z visjimi tipi pa hitro postane vse skupaj veliko lepse, ce imas na razpolago prevajalnik, ki dokazuje dolocene lastnosti tvojih programov in boljsi sistem tipov imas, bolj netrivialne so te lastnosti.

MrBrdo je 9. jun 2012 ob 22:19 izjavil:

Sej Ruby ima tipe... Samo nima spremenljivk v klasičnem smislu ampak ima containerje, kamor lahko spraviš poljubno spremenljivko, zato container nima tipa. Z malo metaprogramiranja si lahko narediš tudi striktne tipe, če hočeš. Primer: https://github.com/t6d/smart_properties

Ruby seveda je tipiziran jezik (v kolikor to lahko trdimo, ker je izgleda edina specifikacija v obliki interpreterja), le da se tipi preverjajo ko kodo pozenes. Zato moras vec testirat.

MrBrdo je 9. jun 2012 ob 22:19 izjavil:

Sicer se pa jaz raje zanašam na teste in delam po TDD metodologiji, tako da ne rabim compiler errorjev da testiram kodo. Toliko več časa kot ti porabiš v statičnem jeziku nekaj spisat si jaz komot privoščim napisat še teste pa še kak refactor narest.

Staticni tipi so ultimativna stvar v tvojem TDD. S staticnimi tipi prevajalnik _dokaze_ dolocene lastnosti (v logiki, ki ustreza sistemu tipov, ce je le ta smiseln), medtem ko jih ti s testiranjem ponavadi ne, saj testiranje (ponavadi) ni izcrpno. Torej lahko smatras, da ti specifikacija jezika in tipi enostavno predstavljajo teste, ki bi jih sicer moral (povrsno) napisat. To seveda ne pomeni, da testiranje ni potrebno, le da se ga uporabi za stvari, ki se jih ne da specificirat s tipi (kar so mogoce vse stvari, v dolocenih primerih, in potem res ne profitiras nicesar).

MrBrdo je 9. jun 2012 ob 22:19 izjavil:

Drugače pa ne vem kdaj sem imel nazadnje problem da bi eni spremenljivki priredil drugačen tip kot pa sem mislil, tko da mi tisto preverjanje tipov sploh nič ne koristi, razen tega da mam več za pisat, česar pa osebno ne štejem kot prednost.

No, type inference je ze prastara stvar, tako da tisto s pisanjem je malo bosa. Pa zopet se ne gre za to, da bi spremenljivki priredil drugacen tip (mimogrede, s staticnimi tipi imas mirno lahko reference, ki spreminjajo tipe med izvajanjem (v literaturi ljudje temu iz nekega razloga recejo "strong references")). Gre se za to, da ce imas nekaj tipa, recimo, A+B in hoces to uporabit, ne mores to narediti drugace, kot da upostevas obe moznosti (torej inl in inr). Ne gre.

MrBrdo je 9. jun 2012 ob 22:19 izjavil:

Logike ti pa compiler itak ne zna preverit.

No ja, tudi to zna. Ce imas specifikacijo programa napisano v neki logiki/formalnem jeziku, tudi to lahko. Res pa je, da to (zaenkrat) ni realisticno za vecje programe, sploh ker ljudje ne vedo kaj hocejo. Lahko pa, recimo, prevajalnik preveri specifikacijo za take elementarne funkcije kot so obracanje seznamov, sortiranje seznamov, kake numericne funkcije ..., ce je le sistem tipov dovolj izrazen.

Staticni tipi so ultimativna stvar v tvojem TDD. S staticnimi tipi prevajalnik _dokaze_ dolocene lastnosti (v logiki, ki ustreza sistemu tipov, ce je le ta smiseln), medtem ko jih ti s testiranjem ponavadi ne, saj testiranje (ponavadi) ni izcrpno. Torej lahko smatras, da ti specifikacija jezika in tipi enostavno predstavljajo teste, ki bi jih sicer moral (povrsno) napisat. To seveda ne pomeni, da testiranje ni potrebno, le da se ga uporabi za stvari, ki se jih ne da specificirat s tipi (kar so mogoce vse stvari, v dolocenih primerih, in potem res ne profitiras nicesar).

me pa prov zanimajo te kompajlerji. rad bi jih videl. razen redkih izjem so redki kot bele miši v naravi. pa še tam moraš spisat specifikacije.

noraguta je 10. jun 2012 ob 09:41 izjavil:

me pa prov zanimajo te kompajlerji. rad bi jih videl. razen redkih izjem so redki kot bele miši v naravi. pa še tam moraš spisat specifikacije.

No, seveda moras pisati specifikacije, kaj drugega so pa tipi. So pa redki, se strinjam. V Haskellu (bolje receno v GHC z dovolj vkljucenimi -Xdodatki :)) se da marsikaj narediti. Potem je Dependent ML oziroma zdaj ATS, pa Epigram. Coq je po svoje zanimiv, saj lahko pises kriticne dele kode, ki dejansko pocnejo resne stvari in dokazes lastnosti, potem pa iz tega zgeneriras kodo, recimo v Scheme, ki deluje tako kot mora.

@sherman: Haskella ne poznam tako da se ne bi rad samo na podlagi prvega vtisa opredelil... Lahko da mu delam krivico.

Problem je, da dokumentacija zivi vzporedno s kodo in se jo programerju ne da/pozabi/je povrsen pri popravljanju. In seveda je vedno programer kriv, kdo drug bi le bil.

V Rubyju je z dokumentacijo kar vredu urejeno, RDoc ti generira dokumentacijo iz komentarjev v kodi, ki jo potem lahko lokalno bereš ali z ukazom "ri class#method" ali z gem server, ki ti lokalno postavi web server na katerem imaš vso dokumentacijo v HTML obliki (tako od stdliba kot tudi od svojega projekta).
Npr. "ri Array#join" v terminalu:

------------------------------------------------------------------------------
  ary.join(sep=$,)    -> str

------------------------------------------------------------------------------

Returns a string created by converting each element of the array to a string,
separated by sep.

  [ "a", "b", "c" ].join        #=> "abc"
  [ "a", "b", "c" ].join("-")   #=> "a-b-c"

Ne razumem pa, kako je lahko rezultat pravilen, ce dobis nekaj drugega tipa, kot si pricakoval (razen v primeru podtipov? (subtype)).

Zato ker v Rubyju pogosto v kodi namesto da testiramo tip spremenljivke, testiramo samo če ustreza nekem obnašanju ki ga želimo. Npr. če ti dam bolj umeten primer, če imam neko metodo, ki vse kar hoče naredit je da psu reče naj laja, namesto da preverjam ali sem dobil kot parameter objekt tipa Pes, preverim samo če zna ta objekt lajat:

if obj.respond_to?(:bark)

Zdaj tak pristop ima tako prednosti (ne rabiš se drkat z interfejsi) kot slabosti (nimaš tako formalno definirano zahtev), to je potem stvar posameznika ali se mu zdi to dobro ali slabo. Lahko seveda tudi class preverjaš če hočeš, ampak včasih enostavno tega ne rabiš. Seveda če imaš projekt kjer imaš zelo formalno definirane zahteve potem tak pristop mogoče ni primeren. Samo v Rubyju veliko developerjev dela po agile metodologiji kjer načeloma ni tako. Sicer je pa efekt podoben, če bi se zdaj odločil da poleg bark rabim še jump, ali dodam v interfejs metodo jump (in bi dobil potem compiler error), ali pa dodam še check za respond_to?(:jump) in sicer vržem exception - če ima programer teste, bo isto dobil ta exception, edina realna razlika je da namesto da požene compiler požene teste. Pa še praksa je taka da se take spremembe dokumentira in še v changelog doda, pa pri večjih projektih se take spremembe uvajajo postopno prek deprecation warningov, kjer še nekaj verzij hendlaš staro obnašanje, potem pa ga kasneje odstraniš in vržeš exception. Tako da recimo ko dodaš tako spremembo imajo ostali developerji nekaj časa da lahko updejtajo svojo kodo - če pa spremeniš interfejs pa te svobode načeloma nimaš.

@sherman en dober talk na temo ki si jo odprl mogoče se ti bo zdelo zanimivo na začetku govori o ducktypingu in kako ga on uporablja...

Pa tole - ko pritisnem kombinacijo alt gr + B, da bi dobil znak {, mi ga ne izpiše, temveč me pomakne za en presledek v levo. Ko pa pritisnem kombinacijo alt gr + N, da bi dobil }, mi prikaže ukaz clear.

slitkx je 17. jun 2012 ob 01:50 izjavil:

Fantje, punce, ono...se komu sanja, zakaj na Code School Ruby panelu ne prime/prikaže znaka [?
Pa verjetno se bo še kak znak našel.

Poleg tega pa me zanima tudi, čemu vedno, ko pridem s tipkanjem in potrjevanjem ukazov do dna okna, vrže drsnik na začetek (vrh) okna? Tako mi potlej ostane, da ali uporabim clear ali pa ročno povlečem drsnik na dno.

Preklop na angleško tipkovnico. Key bindinge na web pagetu boš bolj težko prilagodil