Per chi pensa che Ror sia un giocattolo

Ciao a tutti,
gli scettici pongono spesso la domanda se Ror sia adatto ad applicazioni
“enterprise” o sia piuttosto un giocattolo. Il link seguiente credo
risponda
bene al quesito.

http://www.bluefountain.com/business/in-the-final

Ciao
Maurizio

On 1/23/07, maurizio maurizio [email protected] wrote:

Ciao a tutti,
gli scettici pongono spesso la domanda se Ror sia adatto ad applicazioni
“enterprise” o sia piuttosto un giocattolo. Il link seguiente credo risponda
bene al quesito.

http://www.bluefountain.com/business/in-the-final

Interessante, ma e` un po’ ambiguo per quanto riguarda il ruolo di
rails:

“uses the Ruby on Rails web framework as the web front end”

Buono in ogni caso, comunque.


David N. Welton

Linux, Open Source Consulting

è un pò off-topic, ma mi stupisce sempre il termine ‘linguaggio
giocattolo’. ho l’impressione che sia un termine usato più per attaccare un
avversario con argomenti irrazionali ed emotivi che per identificare
veri
problemi… secondo voi cosa rende un linguaggio ‘giocattolo’?

oltre al fatto che rails è fatto e pensato per il web(basti vedere tutte
le astrazioni che si usano, io per ora ne conosco ancora poche e ogni
volta rimango impressionato) inoltre giusto ieri qualcuno sul chan irc
ha mandato un link con dei benchmark e rails era al secondo posto
distaccato di poco mentre per esempio php aveva tempi non dico doppi ma
quasi.
Poi vabbe secondo me è il solito discorso, chi usa un linguaggio lo ama
in tutto e difficilmente ne ammetterà la sua inferiorità in qualche
campo, anche se magari poi un’ altro framework ha qualche cosina in più
da una parte ma in meno dall’ altra.

vorrei inoltre sottolineare che il linguaggio di sviluppo non è forse
così fondamentale per un’ applicazione di successo, amazon se non
sbaglio è un miscuglio di linguaggio per esempio. Insomma conta la
sostanza e non la forma(o linguaggio di programmazione), poi vabbe
questi son sempre discorsi molto generici ma a grandi linee la penso
così.

PS: per chi vuol farsi una panoramica di RoR consiglio di scaricare lo
speech di Paolo D. presente sul sito di radio radicale, oltre ad
essere stato un talk molto piacevole ha espletato molto bene cos’è
rails.

Saluti Andrea

maurizio wrote:

Mi scuso se sono stato OT, volevo solo proporre un esempio per quando
viene detto che con Ror non sono mai state create applicazioni “vere”.
L’accusa di essere un giocattolo viene spesso rivolta anche al Python:
forse vengono considerati in questo modo quei linguaggi considerati a
torto o a ragione “semplici” rispetto al c++, java ect…o che non hanno
uffici marketing potenti dietro le spalle :-)))

Ciao
Maurizio

Mi scuso se sono stato OT, volevo solo proporre un esempio per quando
viene detto che con Ror non sono mai state create applicazioni “vere”.
L’accusa di essere un giocattolo viene spesso rivolta anche al Python:
forse vengono considerati in questo modo quei linguaggi considerati a
torto o a ragione “semplici” rispetto al c++, java ect…o che non hanno
uffici marketing potenti dietro le spalle :-)))

Ciao
Maurizio

On Jan 23, 2007, at 11:40 AM, stb wrote:

vorrei inoltre sottolineare che il linguaggio di sviluppo non è forse
così fondamentale per un’ applicazione di successo, amazon se non
sbaglio è un miscuglio di linguaggio per esempio. Insomma conta la
sostanza e non la forma(o linguaggio di programmazione), poi vabbe
questi son sempre discorsi molto generici ma a grandi linee la penso
così.

I migliori linguaggi sono quelli in cui la distinzione tra
forma e sostanza si assottiglia al punto che diventano praticamente
la stessa cosa. E non e’ un discorso generico :slight_smile:
Un esempio di prevalenza della forma sulla sostanza potrebbe essere
Java.
Un esempio del tutto opposto potrebbe essere C.
Linguaggi come Ruby, Python e Smalltalk IMHO sono piu’ validi di altri
perche’ hanno trovato un buon equilibrio fra i due aspetti, e in questo
senso sono abbastanza “equivalenti” tra loro.
Per cui se uno mi dice che preferisce Python a Ruby non ho problemi,
alla
fine e’ questione di gusti ed esperienze personali. Ma se uno mi dice
che preferisce PHP,
allora qualche piccolo dubbio sulla sua validita’ di programmatore mi
viene :slight_smile:


Stefano C.
[email protected]

On 1/23/07, Stefano C. [email protected] wrote:

forma e sostanza si assottiglia al punto che diventano praticamente
che preferisce PHP,
allora qualche piccolo dubbio sulla sua validita’ di programmatore mi
viene :slight_smile:

Tut, tut… un po’ di elasticità. Ogni linguaggio ha il suo
perché.Anche se Rails dà la birra a Php per velocità di sviluppo, Php dà
molte meno preoccupazioni quando è il momento di fare il deploy. Con
Rails devi strapparti i capelli a decidere fra Mongrel, load balancer,
fastcgi, lightttpd e non so che altro. Con Php copi i file sul server
e hai finito :slight_smile: Fin che sta su Apache sta su anche Php.

E il linguaggio C ha certamente il suo perché. Tanto per cominciare
Ruby è implementato in C e non in Ruby. E il sistema operativo che
sto usando in questo momento è scritto in C. Sarebbe alquanto
complicato scriverlo in Ruby. Sarebbe lo strumento sbagliato.

M

On 1/23/07, Stefano C. [email protected] wrote:

I migliori linguaggi sono quelli in cui la distinzione tra
forma e sostanza si assottiglia al punto che diventano praticamente
la stessa cosa. E non e’ un discorso generico :slight_smile:

che bella definizione!

in ruby hai la possibilità di manipolare la forma rendendola vicina alla
sostanza meglio che in molti linguaggi mainstream.

se non lo avete già letto: Domain Driven Design di Evans. Mi ha cambiato
la
vita.

On Tuesday 23 January 2007 20:25, Matteo V. wrote:

Tut, tut… un po’ di elasticità. Ogni linguaggio ha il suo perché.
Anche se Rails dà la birra a Php per velocità di sviluppo, Php dà
molte meno preoccupazioni quando è il momento di fare il deploy. Con
Rails devi strapparti i capelli a decidere fra Mongrel, load balancer,
fastcgi, lightttpd e non so che altro. Con Php copi i file sul server
e hai finito :slight_smile: Fin che sta su Apache sta su anche Php.

E il linguaggio C ha certamente il suo perché. Tanto per cominciare
Ruby è implementato in C e non in Ruby. E il sistema operativo che
sto usando in questo momento è scritto in C. Sarebbe alquanto
complicato scriverlo in Ruby. Sarebbe lo strumento sbagliato.

Non ci sono storie, C (e anche C++, perchè no?) rimangono sempre e
comunque il
riferimento per quanto riguarda la programmazione di sistema, se non
altro
perchè in Ruby/Python/Perl/Smalltalk/Java(si pure lui) e tutti gli altri
non
possono gestire tutto ciò che serve a bassissimo livello :slight_smile:
Altrimenti non sarebbero linguaggi ad alto livello, no? :smiley:

Tornando a bomba, si, per me RoR è un giocattolo, ma nel senso che è carino,
simpatico e divertente oltre ad essere potente, per quanto mi riguarda
è la
serie “technic” dei mattoncini lego :smiley:

Il giorno mar, 23/01/2007 alle 23.54 +0100, Francesco P. ha
scritto:

Non ci sono storie, C (e anche C++, perchè no?) rimangono sempre e comunque il
riferimento per quanto riguarda la programmazione di sistema, se non altro
perchè in Ruby/Python/Perl/Smalltalk/Java(si pure lui) e tutti gli altri non
possono gestire tutto ciò che serve a bassissimo livello :slight_smile:
Altrimenti non sarebbero linguaggi ad alto livello, no? :smiley:

Attento a non farti sentire dagli sviluppatori di questo sistema:
http://www.oreillynet.com/digitalmedia/blog/2006/07/squeaknos.html

:wink:

Giovanni

Tut, tut… un po’ di elasticità.

Quello e` un altro linguaggio ancora;-)


David N. Welton

Linux, Open Source Consulting

On Jan 23, 2007, at 8:25 PM, Matteo V. wrote:

Tut, tut… un po’ di elasticità. Ogni linguaggio ha il suo perché.
Anche se Rails dà la birra a Php per velocità di sviluppo, Php dà
molte meno preoccupazioni quando è il momento di fare il deploy.

Non hai mai dovuto lottare con un server apache+mod_php inondato
di richieste che che comincia a produrre solo pagine bianche
e errori 500 e poi si porta giu’ la macchina, immagino.

Con
Rails devi strapparti i capelli a decidere fra Mongrel, load balancer,
fastcgi, lightttpd e non so che altro.

La fai piu’ complicata di quel che e’.

Con Php copi i file sul server
e hai finito :slight_smile:
Fin che sta su Apache sta su anche Php.

Mi sa che immaginavo bene :slight_smile:
Una cosa e’ avere un deploy semplice (nel caso di php, banale).
Un’altra e’
gestire una macchina operativa con tutti i problemi che cio’ comporta.
Magari con Ruby devi pensare un po’ di piu’ inizialmente a quale
soluzione
adottare, e studiare un po’ di piu’, ma poi diventa una passeggiata.

E il linguaggio C ha certamente il suo perché.

Ah beh, non c’e’ dubbio.

Tanto per cominciare
Ruby è implementato in C e non in Ruby.

Beh, Smalltalk e’ implementato in Smalltalk…

E il sistema operativo che
sto usando in questo momento è scritto in C. Sarebbe alquanto
complicato scriverlo in Ruby. Sarebbe lo strumento sbagliato.

E’ talmente ovvio che non ti do’ nemmeno ragione :slight_smile:
Pero’ il mio discorso non e’ cosi’ peregrino se qualcuno ha sentito
il bisogno
di far evolvere il C in qualcosa di piu’… “pulito”, diciamo:

http://www.digitalmars.com/d/


Stefano C.
[email protected]

On 1/24/07, Stefano C. [email protected] wrote:

On Jan 23, 2007, at 8:25 PM, Matteo V. wrote:

Tut, tut… un po’ di elasticità. Ogni linguaggio ha il suo perché.
Anche se Rails dà la birra a Php per velocità di sviluppo, Php dà
molte meno preoccupazioni quando è il momento di fare il deploy.

Non hai mai dovuto lottare con un server apache+mod_php inondato
di richieste che che comincia a produrre solo pagine bianche
e errori 500 e poi si porta giu’ la macchina, immagino.

Effettivamente no. Che php cominci a restituire errori è un conto, ma
se ti cade il server, mi sa tanto che è stato mal configurato Apache.
Non c’è motivo per cui inondando di richieste la porta 80 debba cadere
la macchina, a meno che Apache non sia configurato per prendere più
memoria di quanta ce ne sia.

Con
Rails devi strapparti i capelli a decidere fra Mongrel, load balancer,
fastcgi, lightttpd e non so che altro.

La fai piu’ complicata di quel che e’.

Beh, è più complicato che con php. In php praticamente non c’è niente
da scegliere.

adottare, e studiare un po’ di piu’,
Sì, è questo che dicevo

ma poi diventa una passeggiata.

Ti credo sulla parola… non ho ancora gestito un servizio Rails che
abbia un minimo di traffico.

Matteo

On Jan 24, 2007, at 12:33 PM, Matteo V. wrote:

Effettivamente no. Che php cominci a restituire errori è un conto, ma
se ti cade il server, mi sa tanto che è stato mal configurato Apache.
Non c’è motivo per cui inondando di richieste la porta 80 debba cadere
la macchina, a meno che Apache non sia configurato per prendere più
memoria di quanta ce ne sia.

Appunto. I problemi veri del deploy sono questi, e sono piu’ o meno
gli stessi
per tutti.

Beh, è più complicato che con php. In php praticamente non c’è niente
da scegliere.

Preferisco avere piu’ di una scelta, grazie :slight_smile:

Ti credo sulla parola… non ho ancora gestito un servizio Rails che
abbia un minimo di traffico.

Allora forse questa lettura ti potra’ interessare:

http://poocs.net/2006/3/13/the-adventures-of-scaling-stage-1


Stefano C.
[email protected]

On Jan 23, 2007, at 11:54 PM, Francesco P. wrote:

Non ci sono storie, C (e anche C++, perchè no?) rimangono sempre e
comunque il
riferimento per quanto riguarda la programmazione di sistema,

Tant’e’ che per esempio in MacOS X se vuoi fare programmazione di
sistema
ti fanno usare Objective-C (che e’ molto piu’ vicino ai linguaggi “alti”
che al C), guarda’ un po’ :slight_smile:


Stefano C.
[email protected]

On 1/24/07, Stefano C. [email protected] wrote:

Beh, è più complicato che con php. In php praticamente non c’è niente
da scegliere.

Preferisco avere piu’ di una scelta, grazie :slight_smile:

qui dipende molto dal dominio in cui lavoriamo.
ci sono delle volte in cui voglio poter scegliere… di non scegliere :slight_smile:

in realtà voglio scegliere solo quello che riguarda il mio core business
in
quel momento, il resto diventa disturbo cognitivo.
in questo senso capisco la scelta di tools semplificati.

On Wednesday 24 January 2007 09:36, Stefano C. wrote:

On Jan 23, 2007, at 11:54 PM, Francesco P. wrote:

Non ci sono storie, C (e anche C++, perchè no?) rimangono sempre e
comunque il
riferimento per quanto riguarda la programmazione di sistema,

Tant’e’ che per esempio in MacOS X se vuoi fare programmazione di
sistema
ti fanno usare Objective-C (che e’ molto piu’ vicino ai linguaggi “alti”
che al C), guarda’ un po’ :slight_smile:

Perdonami, ma non mi pare proprio che darwin sia scritto in obj-c :slight_smile:

Il giorno gio, 25/01/2007 alle 01.54 +0100, Francesco P. ha
scritto:

Perdonami, ma non mi pare proprio che darwin sia scritto in obj-c :slight_smile:

E perché non dovrebbe? Objective-C è un superset del C…

:wink:

Giovanni

Il kernel di MacOS X è scritto in C. Il “subsystem” BSD pure. Carbon è
scritto in C. Cocoa è scritto in obj-c.
Essendo ObjC un superset del C immagino che uno potrebbe dire che
tutto MacOSX è scritto in C, ma crea forse più confusione che altro…

ti fanno usare Objective-C (che e’ molto piu’ vicino ai linguaggi “alti”
che al C), guarda’ un po’ :slight_smile:

Perdonami, ma non mi pare proprio che darwin sia scritto in obj-c :slight_smile:

E perché non dovrebbe? Objective-C è un superset del C…

:wink:

Il giorno mer, 24/01/2007 alle 12.54 +0100, chiaro scuro ha scritto:

ci sono delle volte in cui voglio poter scegliere… di non scegliere :slight_smile:

in realtà voglio scegliere solo quello che riguarda il mio core business in
quel momento, il resto diventa disturbo cognitivo.
in questo senso capisco la scelta di tools semplificati.

Esatto. E’ questo il motivo per cui http://rubyonrails.org è scritto in
php :wink:

Giovanni