Novizio

On 7/6/06, Pietro M. [email protected] wrote:

Scusa chiaro, ma come fai a definire Java datato?
Java: 23 maggio 1995
ruby: 24 febbraio 1993

non si tratta di una questione cronologica. mi potevo esprimere meglio.
Java
sarà più giovane, ma ruby si tiene meglio :slight_smile:

intendevo datato come ‘ha fatto il suo tempo’. Ruby il suo tempo inizia
a
farlo ora… probabilmente negli anni 90 sarebeb stato insopportabilmente
lento.

(In questo periodo poi che vecchietti come List e Smalltalk vengono

riesumati… ora aspetto di veder tornare in auge Forth e poi posso

sto iniziando a mettere le mani su lisp e haskell in questi giorni…

servono per lavoro ed ignoro altre cose, ovvero, se ti serve per

lavorare con le MFC, il linguaggio che usi è il C++ di inizio/metà
anni 90, non la bestia che ne esce attraverso il template
metaprogramming[1]).

pensi ad alexandrescu? come lo trovi?

Java è ben documentato, esistono ottimi tool di sviluppo free ed è

meglio di altre cose che circolano. E’ il caso imparare questo come

true. grande documentazione, ottima ed enorme
comunità.


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

bhe il C ormai è ovvio per quanto la gente vi è affezionata ormai è vecchio,
idem C++. Java secondo me non è poi così datato e cmq è ottimo per imparare
l’ Object Oriented.

Cmq il detto impari C++ o C e impari tutto è sempre buono, sono i più
ostili, gli altri poi vengono più facili.

PS: quanto mi piace sta mailing dadasdsadsa

----- Original Message -----
From: “chiaro scuro” [email protected]
To: “ruby-it” [email protected]
Sent: Wednesday, July 05, 2006 10:29 PM
Subject: Re: [ruby-it] Novizio

non concordo con il C. anche se è buono a livello educational per vedere
come gestire la memoria, etc. C/C++ stanno diventando sempre più quello che
era l’assembly qualche anno fa.

java è ok. ha il vantaggio di essere facile e documentato, anche se molto
datato.

On 7/5/06, stb [email protected] wrote:

From: “David W.” [email protected]

[email protected]n.invalid
http://lists.ruby-it.org/mailman/listinfo/ml


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

2006/7/6, chiaro scuro [email protected]:

On 7/6/06, Pietro M. [email protected] wrote:

lavorare con le MFC, il linguaggio che usi è il C++ di inizio/metà
anni 90, non la bestia che ne esce attraverso il template
metaprogramming[1]).

pensi ad alexandrescu? come lo trovi?

Per che vuole avere degli incubi di notte:
http://www.amazon.com/gp/product/0201704315/002-3874017-7404827?v=glance&n=283155

A parte gli scherzi, non ho mai avuto la necessità di sfruttare C++ in
quel modo. Quando uso C++ spesso lo faccio su piattaforme dalle
risorse ridotte[1], con compilatori non totalmente ISO compliant
(Windows CE con eVC3.0 / 4.0).
In pratica per arrivare a quei livelli dovrei utilizzare solo C++ per
parecchio tempo. Questo si scontra con la realtà (negli ultimi tre
mesi ho sviluppato in Java, XSL-FO(?), javascript e C++).

Java è ben documentato, esistono ottimi tool di sviluppo free ed è

meglio di altre cose che circolano. E’ il caso imparare questo come

true. grande documentazione, ottima ed enorme comunità.

Da non sottovalutare poi che la comunità Java è molto attenta a quanto
accade nell’ambiente e si sta muovendo per acquisire le idee migliori
in circolazione.
Ma questo si lega ad una mia convinzione: una cosa è il linguaggio
Java (e non mi fa impazziere particolarmente) ed un’altra cosa è la
JVM (e questa si che mi piace):

  1. groovy + grails [http://groovy.codehaus.org/ +
    http://grails.codehaus.org/]
  2. Trails [https://trails.dev.java.net/]
  3. jRuby (e pare riesca, nelle ultime versioni, ad eseguire RAILS)
    [http://jruby.sourceforge.net/]

Saluti
Pietro

  1. Molta gente dice che C++ può essere utilizzato senza penalizzazioni
    rispetto al C (in termini di velocità e dimensione del codice). Ne
    sono convinto anch’io. Credo solo che per poter ottenere questi
    risultati si debba conosce il C++ molto, molto bene.

Sono davvero molto contento del funzionamento di questo forum, ti fa
sentire parte di qualcosa…
Siete tutti molto gentili, ed è un piacere leggere i vostri commenti sui
più svariati linguaggi.
Sopratutto per chi “tratta” concetti tanto ostici quali la
programmazione è molto importante poter contare su un gruppo di
aficionados come voi.

Thanks again!

2006/7/6, chiaro scuro [email protected]:

Per che vuole avere degli incubi di notte:

http://www.amazon.com/gp/product/0201704315/002-3874017-7404827?v=glance&n=283155

Se però devi per qualche motivo lavorare in c++ questo libro non è affatto
male. ostico non c’è dubbio, ma rivoluziona il modo in cui vedi il c++.

Concordo, non ho questo libro nella mia biblioteca, ma il motivo è
legato principalmente al fatto che non ho avuto la necessità di
sfruttare C++ a quei livelli per lavoro ed il C++ non è per ora nella
lista dei linguaggi con cui gioco nel mio tempo libero (tempo
libero?).
Comunque i libri di quella serie sono, a mio parere, i migliore per
C++ (ne ho un paio, Accelerated C++ e Exceptional C++ e sono veramente
buoni) e poi l’aforisma di B. Pascal riportato all’inizio dei libri è
uno dei miei favoriti.

Ma qui stiamo andando pesantemente OT… chiedo scusa agli altri
frequentatori della lista.

Ciao
Pietro

On 7/6/06, Pietro M. [email protected] wrote:

http://www.amazon.com/gp/product/0201704315/002-3874017-7404827?v=glance&n=283155

Se però devi per qualche motivo lavorare in c++ questo libro non è affatto
male. ostico non c’è dubbio, ma rivoluziona il modo in cui vedi il c++.


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

On Wed, 5 Jul 2006 22:17:23 +0200, stb wrote:

Java è eccezzionale come linguaggio ad oggetti e oltre ad essere
molte semplice ha una documentazione bellissima.

Eccezionale nel senso che le eccezioni rompono veramente le palle eh…
La documentazione vero, bella (ma è più una questione di libreria che
di linguaggio).

Riguardo al “semplice” io userei semmai la dicitura “inutilmente
complesso”.

Insomma, grosso modo se dovessi descrivere Java con due parole userei
“occasione sprecata”.

chiaro scuro wrote:

non concordo con il C. anche se è buono a livello educational per vedere
come gestire la memoria, etc. C/C++ stanno diventando sempre più
quello che
era l’assembly qualche anno fa.

A me capita spesso di ringraziare la sorte di aver programmato parecchio
in C.
Nel senso che con il C ti imbatti in quelle cose davvero di basso
livello dove il singolo bit conta… ed e’ un tipo di conoscenza che
prima o poi torna utile
Ad esempio qualche giorno fa dovevo capire come mai dei caratteri
venivano fuori sballati, ed esaminando bit a bit e’ uscito fuori che era
l’encoding UTF-8 di una cosa latin-1.
Insomma, lo vedo come qualcosa di piu’ di un linguaggio didattico… e
poi se uno si fa prendere dal gusto della ottimizzazione manuale e’ un
linguaggio che offre molto.
Detto cio’, se cosi’ tanta gente non trovasse ragionevole, nel XXI
secolo, programmare in C, internet sarebbe un posto molto piu’ sicuro.
Il problema e’ che scrivere programmi corretti in C e’ veramente
difficile, quasi inumano.

java è ok. ha il vantaggio di essere facile e documentato, anche se molto
datato.

In effetti, io ho capito la programmazione ad oggetti con java. Anche
qui, trovo piuttosto incomprensibile il successo commerciale di cui
continua a godere.

Per il resto, condivido l’impostazione “un linguaggio di basso livello,
uno OO puro, ed uno funzionale”. Non sono sicuro del fatto che
l’eleganza di ruby sia percettibile da parte di chi non ha gia’
programmato in diversi linguaggi, e purtroppo non me la sento neanche di
scommettere sul suo successo…la storia dei linguaggi per elaboratore
e’ costellata di ottime idee naufragate commercialmente!

Ciao

Q: “Lei e’ un nichilista?” A: “Io non sono niente” (E.M.Cioran,
nell’unica intervista da lui concessa)

On Wed, 5 Jul 2006 22:45:39 +0200, stb wrote:

Java secondo me non è poi così datato e cmq è ottimo per imparare l’
Object Oriented.

Se ho capito quello che intendeva chiaro scuro (nel caso concordo) è
che Java è nato vecchio. È un linguaggio cronologicamente della stessa
generazione di Ruby, ma come “linguaggio” è davvero più vecchio. Più
ingessato.

Cmq il detto impari C++ o C e impari tutto è sempre buono, sono i più
ostili, gli altri poi vengono più facili.

Non sono del tutto convinto. In C si prendono per esempio un sacco di
cattive abitudini che levarsele quando si passa a C++ non è affatto
banale (lo ho visto tante volte e lo ho vissuto anche io). Spesso molte
cose per cui C++ ha una sua feature particolare, vengono gestite con un
C + classi che è davvero triste.

Iniziare con C++ è poi spesso un problema, si finisce anche per non
appassionarsi per la serie di “piccoli problemi” (non problemi per un
programmatore esperto, ma gatte da pelare per un novizio). Usare
librerie esterne, per dirne una, è tutto fuorchè banale. In pratica
bisogna imparare anche ad usare gli autotools e combriccola cantante.
Per non parlare della costrizione statica a cui le menti sono spesso
sottoposte :slight_smile: [ ma in questo Java è peggio, IMHO ].
Molti programmatori C++ e Java non si convinceranno mai che pur non
avendo i tipi i programmi Ruby funzionino anche se su larga scala, come
non accettano che i test – che vanno fatti comunque – prendono
benissimo quel tipo di errori.

Ah… e riguardo ai test, abituarsi a scrivere i test prima è un
vantaggio incredibile. E ambienti come C e C++ che non lo rendono ne
facile ne invitante…

Io credo che il modo migliore di imparare sia Ruby o Python. Uno
capisce cosa vuole dire programmare, programmare ad oggetti. A quel
punto può decidere di immergersi in altri paradigmi.

Concordo anche sul fatto che imparare un linguaggio funzionale (e
magari uno dichiarativo) apre la mente.

On Thu, 06 Jul 2006 18:14:31 +0200, Luca S.G. de Marinis wrote:

Non sono sicuro del fatto che l’eleganza di ruby sia percettibile da
parte di chi non ha gia’ programmato in diversi linguaggi, e
purtroppo non me la sento neanche di scommettere sul suo
successo…la storia dei linguaggi per elaboratore e’ costellata di
ottime idee naufragate commercialmente!

Infatti IMHO non lo è. E molte delle cose “più fighe” di ruby vengono
sfruttate più che altro da utenti mediamente smaliziati. Ma è comunque
un buon oggetto con cui lavorare, anche in versione “base”.

On Thu, 6 Jul 2006 09:17:53 +0200, Pietro M. wrote:

Scusa chiaro, ma come fai a definire Java datato?

Tenendo conto che ObjectiveC è del 198x (tipo 1984 o giù di li) e che
gli sviluppatori di Java conoscevano ObjectiveC, che ObjectiveC non ha
sostanziali problemi prestazionali (i suoi problemi più grossi sono la
mancanza dei namespace – quanto mi fa incazzare – ed eventualmente
uno scarso uso delle eccezioni nella libreria standard – ovvero non ci
sono --), beh, non posso che definire Java vecchio.

Invece che essere un passo avanti, è un passo indietro. Se avessero
preso ObjectiveC, gli avessero dato una sintassi un po’ più “comoda” (a
me piace la sintassi di ObjectiveC, ma a molti da noia), avessero
aggiunto namespace, abbandonato la separazione degli headers, aggiunto
le eccezioni, magari già che c’erano pure i blocchi e cosette del
genere, adesso starei programmando in Java, non in Ruby.

Durante la scorsa Java Conference ho avuto l’opportunità di fare delle
domande a Gosling (l’inventore di Java) a riguardo delle lacune che il
suo
pargolo ha nei confronti dei linguaggi dinamici e funzionali quali Ruby,
lisp, e via dicendo.

Gosling ha detto cose semplici ma estremamente corrette:

  1. L’obiettivo del linguaggio Java era quello di creare un linguaggio
    molto
    simile al C++ dove però fosse più difficile incasinarsi la vita con
    puntatori, memory leak etc etc, non fare un linguaggio totalmente
    nuovo o
    totalmente OO come Ruby. E’ stato messo come must il fatto che tutti i
    programmatori C++ potessero passare agevolmente a Java. Data la mole di
    persone che programma in Java oggi, direi che l’obiettivo è stato
    raggiunto
    con enorme successo.

  2. Non è che per quelli della Sun Java è perfetto così, semplicemente non
    possono cambiarlo radicalmente per via dell’enorme user base. Ruby è
    addirittura più vecchio, ma avendo molti meno utenti e applicazioni in
    produzione risulta più semplice evolverlo nel tempo. E’ quello che ha fatto
    e che sta ancora facendo (Ruby 2 all’orizzonte?)

  3. E’ facile criticare. Le specifiche di Java sono dettate dal Java
    Community Process. Se avete delle idee su come migliorare Java perchè non
    fate un piano serio e avanzate una Java Specification Request? Se al
    pubblico piace poi le cose vengono fatte (come è accaduto per generics,
    annotations e sta avvenendo per groovy)

Intendiamoci, io adoro Ruby, ma non vedo perchè bisogna buttarsi in
battaglie di religione. Sono linguaggi nati in ambienti diversi, con
scopi
diversi e hanno campi di applicazione ottimali diversi. Punto. La
disciplina
che ti fai con il design by contract di Java oltretutto ti salva un pò da
tutte le cazzate che puoi fare con Ruby se non sei un guru… (se uno ci
va
giù di moduli inclusi dinamicamente, metaclassi e via discorrendo non è che
il codice diventi poi tanto leggibile)

E oltretutto le bollette (e le birre che mi bevo con chiaroscuro) le
pago
ancora con Java, anche se spero di invertire la tendenza :wink:

Insomma, grosso modo se dovessi descrivere Java con due parole userei

“occasione sprecata”.

Che intenti per “occasione sprecata”? In che modo secondo te l’occasione
poteva essere sfruttata meglio mantenendo fede ai constraints che hanno
avuto?

Un’abbraccio sincero a tutti.
Paolo

PS: Questa è una delle mailing list con il livello qualitativo più alto che
mi sia capitato di frequentare, mi dispiacerebbe scadere di stile
facendo
gli estremisti talebani…

On Sat, 8 Jul 2006 02:00:54 +0200, Paolo Donà wrote:

Durante la scorsa Java Conference ho avuto l’opportunità di fare delle
domande a Gosling (l’inventore di Java) a riguardo delle lacune che il suo
pargolo ha nei confronti dei linguaggi dinamici e funzionali quali Ruby,
lisp, e via dicendo.

Quella a Milano all’università? Dovrebbe essere parecchio interessante.
IMHO Gosling è uno da ascoltare comunque, anche se non si è d’accordo.
Purtroppo mi sembra si sia un po’ commercializzato (nel senso
“tecnico”, nel senso che è un po’ meno hacker e un po’ più “marketing”)

Cosa intendo? Questo è un post di Chad F. su quello che Gosling
dice di Ruby:
http://www.chadfowler.com/index.cgi/Computing/Programming/Ruby/GoslingThinksRubyJustGeneratesWebPages.rdoc,v

In particolare
“PHP and Ruby are perfectly fine systems,” he continued, “but they are
scripting languages and get their power through specialization: they
just generate web pages. But none of them attempt any serious breadth
in the application domain and they both have really serious scaling and
performance problems.”

Finchè queste cose le dice un Java advocate qualunque, mi sta anche
bene. Ma da Gosling mi aspetto un minimo
più di obiettività.

  1. L’obiettivo del linguaggio Java era quello di creare un linguaggio molto
    simile al C++ dove però fosse più difficile incasinarsi la vita con
    puntatori, memory leak etc etc, non fare un linguaggio totalmente nuovo o
    totalmente OO come Ruby. E’ stato messo come must il fatto che tutti i
    programmatori C++ potessero passare agevolmente a Java. Data la mole di
    persone che programma in Java oggi, direi che l’obiettivo è stato raggiunto
    con enorme successo.

E in questo ci sono riusciti. Peccato per la programmazione generica
(che è una delle cose che mi piace di più in C++) che in Java invece
trovo sostanzialmente limitata. D’altra parte mica pretendo, all’epoca
anche i templates di C++ non si sapeva bene come usarli, le
implementazioni erano incomplete, le specifiche non parliamone.
Tuttavia oggi… ma ovviamente la storia non si fa con i se. Inoltre
non ho una comprensione sufficiente della JVM per potere affermare “si,
templates migliori si sarebbero potuto fare”. Dopo tutto gli attuali
generics in pratica non sono visti dalla JVM.

Tornando a noi, ribadisco… avendo visto ObjectiveC (e ribadisco, non
è un mistero che ci si sono ispirati spesso e volentieri), mi chiedo…
siamo sicuri che fosse il caso di pulire e basta il C++ invece che di
infilarci dentro un po’ del meglio di Objective C?
IMHO avrebbero potuto essere più dinamici, ecco tutto.

  1. Non è che per quelli della Sun Java è perfetto così, semplicemente non
    possono cambiarlo radicalmente per via dell’enorme user base. Ruby è
    addirittura più vecchio, ma avendo molti meno utenti e applicazioni in
    produzione risulta più semplice evolverlo nel tempo. E’ quello che ha fatto
    e che sta ancora facendo (Ruby 2 all’orizzonte?)

Infatti. Questo è un enorme problema. Anche perchè appunto in un
linguaggio così statico non è possibile fare sostanziali aggiunte senza
cambiare il linguaggio stesso, magari andando a rompere la
compatibilità.Inoltre credo che siano molto diverse le
comunità.

  1. E’ facile criticare. Le specifiche di Java sono dettate dal Java
    Community Process. Se avete delle idee su come migliorare Java perchè non
    fate un piano serio e avanzate una Java Specification Request? Se al
    pubblico piace poi le cose vengono fatte (come è accaduto per generics,
    annotations e sta avvenendo per groovy)

Qualche idea la ho. Ma comporterebbe tanti di quei cambiamenti che non
sarebbe certo accettata. E poi in fondo trasformerebbe Java in qualcosa
che non sarebbe più Java. Diciamo che io farei di tutto per
dinamizzarlo, ma questo non è necessariamente facile.
Ah… e una cosa che mi piacerebbe davvero tanto (ma qui non ho idea di
come implementarlo… anzi, credo che alla fine non sia neppure
possibile farlo in modo automatico) sarebbe un uso sistematico del
NullObject Pattern.

Ma questo mi piacerebbe pure in Ruby, eh…

E confesso che spesso e volentieri l’obbligo di dichiarare le eccezioni
mi da un pochetto sui nervi :slight_smile:
Problema mio, chiaramente. Per quanto programmi abitualmente anche in
Java, non mi considero davvero un programmatore Java.
Poi queste opinioni sono. Pochi giorni fa un mio collega mi raccontava
di come invece a lui l’obbligo di dichiarare le eccezioni fosse una
delle cose che più gli piacevano di Java, e anzi gli sarebbe piaciuto
vederle anche in C++ e in Ruby/Python (quest’ultima cosa
assolutamente insensata, IMHO, se non a livello di annotazione, ma
allora basta rubydoc).

Intendiamoci, io adoro Ruby, ma non vedo perchè bisogna buttarsi in
battaglie di religione. Sono linguaggi nati in ambienti diversi, con scopi
diversi e hanno campi di applicazione ottimali diversi. Punto. La disciplina
che ti fai con il design by contract di Java oltretutto ti salva un pò da
tutte le cazzate che puoi fare con Ruby se non sei un guru… (se uno ci va
giù di moduli inclusi dinamicamente, metaclassi e via discorrendo non è che
il codice diventi poi tanto leggibile)

Io non è che voglio fare una guerra di religione. Dal mio punto di
vista, Java avrebbe potuto essere molto migliore inserendo capacità
dinamiche opzionali (ribadisco, penso ad ObjectiveC, compilato eppure
quasi interamente dinamico, eventualmente spogliato dalle vestigia C).
Poi fare un “ObjectiveJava” oggi sarebbe poco utile. Ci sono già Ruby e
Python, voglio dire. Sappiamo tutti che la storia non si fa con i se
(beh… questo non è vero in effetti i se giocano un ruolo importante
nel metodo storiografico di Weber, ma questo centra poco).

Riguardo alla metaprogrammazione in Ruby è come le spezie. A piccole
dosi riesce a trasformare un buon piatto in un’eccellente portata. Ma
se abusata rende il tutto un casino di sapori.

A parte che Design by Contract io non lo vedo necessariamente legato a
Java. Anzi, il LSP cerco di applicarlo sempre (quando ha senso).
Personalmente io quel modo di programmare lo avevo già dal C++, prima
di avvicinarmi a Java ( a parte brevi e deludenti flirt in precedenza).

Una cosa che invece mi manca moltissimo in Java è la possibilità di
usare un paradigma RAII. In generale avere variabili automatiche
potrebbe essere un vantaggio strategico. Anche se riporterebbe in Java
alcuni problemi del C++.

Che intenti per “occasione sprecata”? In che modo secondo te l’occasione
poteva essere sfruttata meglio mantenendo fede ai constraints che hanno
avuto?

Mantenendo fede ai constraints… ribadisco, un po’ di dinamismo credo
che avrebbe potuto inserirlo.

PS: Questa è una delle mailing list con il livello qualitativo più alto che
mi sia capitato di frequentare, mi dispiacerebbe scadere di stile facendo
gli estremisti talebani…

Tutt’altro. Ma chiediamoci perchè ci piace così tanto Ruby e se non ci
piacerebbe potere lavorare di più con questo linguaggio anche in ambito
aziendale. E chiediamoci come fare perchè questo accada.

Il giorno 08/lug/06, alle ore 12:40, Enrico F. ha scritto:

In particolare
“PHP and Ruby are perfectly fine systems,” he continued, “but they are
scripting languages and get their power through specialization: they
just generate web pages. But none of them attempt any serious breadth
in the application domain and they both have really serious scaling
and
performance problems.”

Finchè queste cose le dice un Java advocate qualunque, mi sta anche
bene. Ma da Gosling mi aspetto un minimo più di obiettività.

Ho una curiosità da profano di Ruby e forse OT rispetto all’oggetto:
sono impegnato in un’applicazione finanziaria per la traduzione di
flussi provenienti da mandanti esterne alla banca. I flussi in
questione sono file csv da centinaia di migliaia di righe. Per
riuscire ad avere prestazioni accettabili, sono costretto a lavorare
di fino con i thread per suddividere l’elaborazione del singolo
flusso e sfruttare così le macchine multi-processore del cliente.
Ora, un linguaggio come Ruby, che è fortemente basato sulle
espressioni regolari, potrebbe essere un’interessante risposta al
problema della traduzione di flussi. Ma con la soluzione di threading
nativa di Ruby riesco a sfruttare macchine multi-processore con
applicativi singolo processo come il mio?

Grazie e ciao
Jacopo_______________________________________________
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

Tutt’altro. Ma chiediamoci perchè ci piace così tanto Ruby e se non ci
piacerebbe potere lavorare di più con questo linguaggio anche in ambito
aziendale. E chiediamoci come fare perchè questo accada.

Fai una tua azienda… vedi il thread un po’ di tempo fa sulle
startup:-)


David N. Welton

Linux, Open Source Consulting

On Sat, 8 Jul 2006 13:08:27 +0200, David W. wrote:

Fai una tua azienda… vedi il thread un po’ di tempo fa sulle startup:-)

Lo lessi. Purtroppo non è così facile. Qui non siamo in USA.

On 7/8/06, Enrico F. [email protected] wrote:

No. Ruby usa un modello di threading “in user space”. I thread ruby
sono thread dell’interprete, ma non del sistema operativo.

Ho capito. Grazie per la risposta.

Ciao
Jacopo

On Sat, 8 Jul 2006 17:39:36 +0200, Jacopo M. wrote:

Ora, un linguaggio come Ruby, che è fortemente basato sulle
espressioni regolari, potrebbe essere un’interessante risposta al
problema della traduzione di flussi. Ma con la soluzione di threading
nativa di Ruby riesco a sfruttare macchine multi-processore con
applicativi singolo processo come il mio?

No. Ruby usa un modello di threading “in user space”. I thread ruby
sono thread dell’interprete, ma non del sistema operativo.
Suppongo che in ruby ti metteresti a lavorare con più processi (io
peraltro quando possibile preferisco il meccanismo a processi a quello
a thread).

Comunque tornando a noi per quello che ho visto Java è veloce su certe
cose, ma sulla manipolazione di testo e specialmente I/O non lo ho
visto brillare. Potresti farti un prototipino in Ruby e vedere come se
la cava (puoi provare anche Python, un po’ più veloce di Ruby, ma
attenzione a come usi le stringhe: sono immutabili, come in Java,
quindi per esempio usare concatenazioni è una pessima idea, molto
meglio usare cStringIO – scritto in C, molto ottimizzato --).
Il classico per quel tipo di compito una volta credo sarebbe stato Perl
(ma io gli preferisco sia Ruby che Python) e in particolare non avrei
scelto Java (a meno che io non abbia mancato lo scopo delle tue
applicazioni).

Ribadisco… fatti qualche prova (oppure se mi dici che tipo di roba
devi maneggiare, magari ci do un’occhiata io) e vediamo. Ah… e
definisci anche “performances accettabili”. :))

Se poi fosse roba XML potresti rivolgerti a XSLT. Un mio amico
(perlista) ci lavora tantissimo, e dice che usando solo XSLT riesce ad
ottenere performances incredibili. Poi chiaramente la cosa non si
applica al tuo caso, visto che sei in csv, era solo per la cronaca.

Fai una tua azienda… vedi il thread un po’ di tempo fa sulle startup:-)

Lo lessi. Purtroppo non è così facile. Qui non siamo in USA.

Si, ma non e neanche impossibile!

http://www.pandemia.info/2006/06/07/lintervista_a_segnalocom_sulla.html

IMO una delle cose diverse negli states ela mentalita di "si puofare!". Non e facile aprire un’azienda neanche la... e sempre un
rischio.


David N. Welton

Linux, Open Source Consulting

On Sat, 8 Jul 2006 16:31:25 +0200, David W. wrote:

IMO una delle cose diverse negli states ela mentalita di "si puofare!". Non e facile aprire un’azienda neanche la... e sempre un
rischio.

Chiaramente. Anche se in qualche modo qua mi sento “frenato”. Per non
parlare di vari problemi con mutui e compagnia se uno vuole mettere su
casa. Insomma, certo si fa, se si vuole.
Ma non è una scelta per nulla “facile”.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs