Acum câțiva ani, când am încercat pentru prima dată Rails (deh, era la modă!), eram foarte confuz de erorile criptice, iar ăsta a fost unul din motivele pentru care nu am aprofundat (ăsta și faptul că Ruby e o mizerie semiutilizabilă pe Windows).
Când am început să interacționez cu Node (în mare parte prin intermediul Grunt si Gulp), am avut aceeași problemă: erori criptice, nimic concret și, dacă nu am nici măcar o idee despre ce ar putea fi greșit, este nevoie să sap în cod pentru a înțelege problema (în loc să mă duc direct la problemă).
Se pare că nu sunt eu mai special; și alții au aceeași nemulțumire ca și mine
As I sit here, looking at a stack trace of my coffee-script code, which runs through a ruby-based javascript interpreter sitting on top of the asset pipeline which runs through rails and spits out an error via a gem which globally hooks into the exceptions bubbled up from the depths of hell, and yet the stack trace can only give me a vague file reference and the type of error it is, but not actually point me at the actual error at all […]
…
Platforms like node.js suffer the exact same problems. We need new thinking, not just repackaging of the same old failures. I should be spending time writing code, not debugging a haystack of mutable, dependency-wired mess.
Asta ar putea fi din cauza ca omul e idiot? Nu stiu, intreb si eu, dar cine l-a “provocat” sa aiba asa un dev environment?
Prea cautam explicatii logice cand explicatia e exact in fata noastra: “unii oameni e retarzi”.
LE:
Development felt cool, and this was a big deal given the culture we were used to.
Exact, pentru ca vreau sa fiu cool programand.
ELE:
You started to see jolt-cola drinking wizards unconcerned about their appearance being replaced with skinny-jeans-wearing bearded hipsters, (admittedly I am as guilty of this as any of us). In our company, we would cycle to work in our converted warehouse office space, eschew job titles and hot desk on couches and cafes around the area if we felt like it. Design and code blended as one and the birth of the full-stack developer made them commonplace.
Ceva ca, wait for it, PHP. Multi-threaded PHP, dar tot PHP. </sarcasm>
Ce-i drept, PHP nu are erori chiar asa criptice. Si nu i-ar strica sa suporte multi-threading.
Iar unul din avantajele PHP-ului este faptul ca este facut pentru incepatori. Pana si documentatia lor este scrisa pentru incepatori.
Nota: Nu am lucrat cu Ruby, deci nu imi pot da cu parerea despre documentatia lor, insa documentatia PHP-ului mi-se pare mult mai buna decat cea a Python-ului, cel putin. Node-ul pare sa aiba documentatia (manualul) umpic mai bun(a), din punctul acesta de vedere, dar tot in acelasi stil pare sa fie facuta. Asta din informatiile pe care le detin, cel putin.Va rog sa ma corectati, daca gresesc.
What is this? how to start a flame war thread i.e. take @iamntz with how many apps written in Ruby? add some inflammatory article written by some dude that has barely any idea of what he’s talking about then wait for @dakull to write something in full English saying how stupid all of this is.
Also as a template for flame threads: {random language / framework} is {something derogatory} written by some random douche that wants to get on HN front-page …
Da, este multithreading, insa diferenta este ca extensia respectiva trebuie activata.
Sincer, nu stiam de pthreads… Ma bucur ca au creat-o, dar, stii cum se spune, too little, too late, pare sa fie.
Eu am executat php in paralel fara threaduri de acum 7 ani, si inca merge impecabil si in zi de azi. Folosesc curl_multi, pentru clarificari.
Mi se pare ca @Sapioit s-a exprimat doar ca sa se afle in treaba zicand too little too late, dar nu am rabdare acum sa demontez. O sa trag doar concluzia ca php e un limbaj modern, enterprise-level de peste 10 ani (vorbesc prin prisma experientei personale).
La subiect, ruby e stabil si el, s-au livrat chestii minunate in el. Mie mi se pare slow, motiv pt care am decis sa nu perseverez. Dar ghinionul ruby-ului se numeste javascript, si e greu sa schimbam asta. Vir fi probleme la stabilizarea codului de backend facut in js, pt ca mindsetul cu care trebuiesc abordate notiuni de backend care tintesc la viteza, stabilitate, acalabilitate si predictibilitate e diferit.
@voxspace intenția mea nu e să fac trolling. Sunt alții mai pricepuți decât mine
Eu nu am început nici un proiect în rails, doar am lucrat peste vreo trei-patru (frontend) și toate foloseau asset pipeline și toate erau ridicol de lente. Din punctul meu de vedere, ca rookie, ăsta e the rails way[quote=“voxspace, post:2, topic:3003”]
Exact, pentru ca vreau sa fiu cool programand.
[/quote]
Tind să cred că nu se referă la cum ești perceput de alții ci de cum te simți atunci când programezi (i.e. Rezolvarea unei probleme interesante și provocatoare vs… Nu știu, interogarea db; una este cool, cealaltă…nu prea)
Whoa, ce te-ai aprins așa?
Sunt convins că problemele citate de mine sunt probleme banale după ce te obișnuiești cu ecosistemul (altfel nu cred că ar fi prins RoR atât elan…), doar că eu nu am trecut de noțiunile de bază.
Doar că nu toate link-urile le pescuiesc de pe HN, deci s-ar putea să nu știu despre acele discuții
Asta imi aduce aminte de o discutie cu Vagrant si shared folders care da erau incredibil de incete insa din cauza stratului de virtualizare fara vreo legatura directa cu Rails asset pipeline.
Acum nu am nici cea mai mica îndoială că Windows era o parte a problemei, dar atunci cazurile astea erau destul de puțin documentate (ceea ce mă face să rectific și să spun că sunt de fapt doi-trei ani+ de la ultimele interacțiuni serioase cu mediul RoR).
La momentul respectiv, Vagrant tocmai trecuse de la instalarea din Gem la set up standalone și era prezentat de toți drept salvatorul dezvoltării pe Windows. Ce nu (prea) se menționa era treaba cu viteza…
Deci confirmation bias de acum doi-trei ani? pe scurt: motivul pentru care m-am aprins așa este ca il observ destul de des pe aici apoi apar o serie de preconceptii ce se transforma in buzzwords si FUD precum:
Vagrant avea same issue si pe OS X chiar si acum daca vrei sa faci Rails/Ruby dev pe win. instalezi un Ubuntu full desktop i.e. Ruby a fost intotdeauna legat de *nix, nu prea merge sa dezvolti in Ruby fara asa ceva decat daca iti place sa te chinui singur.
Iar din moment ce am vazut persoane care fac front-end sa faca tranzitia spre asa ceva fara probleme IMHO este un atu al limbajului ca te forteaza sa inveti ceva care iti va fi foarte util mai incolo but I digress.
Se pare ca avem pareri diferite, mie imi place sa cred ca un proiect care azi e mic (pare mic) va fi vandut bine, va “prinde” si atunci cele cateva ore petrecute la inceput in a clarifica niste aspecte vor fi desoebit de valoroase in ansamblu. Toti ne dorim sa aiba succes ceea ce codam, eu prefer sa incorporez asta in cadrul solutiei.
Recunosc faptul ca a trebuit sa caut ce e FUD, si ca nu asta era intentia mea, pentru ca toate afirmatiile pe care le fac vin din propria experienta de a crea aplicatii medium si large-scale (am mai zis pe undeva ca eu nu stiu sa “fac siteuri la metru”, adica eu nu fac 1 proiect / luna, 12/an sau mai multe).
Urmaresc cu interes felul in care javascript penetreaza server-side-ul, si chiar am cateva proiecte in care imi trec arma in arsenal. Dar e inca atat de imatura incat nu putem sa o comparam cu Ruby & al folosite deja in back. Cu RoR m-am straduit vreo jumatate de an pana sa renunt. Am observat ca RoR e in general preferat de cei care livreaza full-stack, adica si interfata, si logica de business, pentru ca acele constrangeri ii ajuta sa implementeze mai rapid. Nu e de neglijat aceasta felie de piata, ceea ce zic eu este ca dupa un anumit nivel de performanta a aplicatiei ceea ce conteaza nu mai e viteza de implementare, si ca exista limbaje de programare care incurajeaza asta de la inceput. Poate nici acum nu m-am exprimat prea bine, dar macar am incercat. Si suntem putin offtopic pt ca o dam in language wars, desi nu am dorit asta. Split thread, @iamntz?
Iarasi confirmation bias. Daca zici exact ce ai zis mai sus doar ca in loc de PHP pui Ruby nu se schimba mai nimic, nu limbajul in sine face ca un proiect sa fie a failed one ci cei care il scriu.
Exista rails-api sau daca esti ca mine folosesti modularitatea inclusa bydefault in Rails si tai ce nu iti trebuie pana ramai cu minimul necesar pt. un API.
Este ca si cum eu as fi incercat jumatate de an Symfony si as zice ca it sucks pentru ca nu mi-a placut ceva la el gen:
Symphony is an attempt to make PHP behave more like Java
