Open fvasco opened 7 years ago
Io metterei 1 slide per 1 linguaggio con la "annata".
Intendi fare una schermata per ogni linguaggio? Quale data usiamo per Groovy, Scala e Ruby?
La versione 1.0 di Groovy è del 2003, l'esempio proposto di Groovy è su Java 8 e la prima versione di Groovy a supportare Java 8 è la 2.3 del 2014.
Visto che in questo caso avremmo più spazio potremmo annotare il codice per evidenziarne alcune caratteristiche, come il limite nei nomi delle variabili del Basic, le conversioni implicite di Scala?
Posso preparare una bozza, poi chiederei ad ogni autore di sistemarsi la sua schermata come ritiene più opportuno.
I linguaggi sono:
Per la versione Java direi usiamo la vanilla.
Si riesce a realizzare anche una versione in Clojure e Scala 1.0?
Ciao guys,
in primis, vorrei parlare di filosofia: perche'? Quale senso vogliamo dare alla cosa? Perche' mettere a confronto i linguaggi morti con quelli attuali? Una volta che diamo un senso a questa storia ("anche se questa storia senso non ne ha" come direbbe qualcuno :) ) vcredo che tutto il resto (ad esempio quali vincoli mettere al codice o come impostare la "presentazione") possa venire di conseguenza.
Condivido con voi a brainstorming le mie idee:
Rileggendo i vecchi manuali mi sono reso conto dell'ovvio, ovvero di come la reperibilita' dell'informazione che all'epoca non avevo fosse il grande scoglio da superare: leggere riviste di settore, spulciare libri di informatica in pulciose biblioteche, chiedere ad amici nerd era lunico modo. Adesso in due click ho recuperato DOSBox e tutti i manuali del caso. Adesso la risorsa scarsa e' il mio tempo per (finalmente) rileggere quei manuali.
Rivedere tutti insieme questi linguaggi di programmazione ha messo in prospettiva l'evoluzione dello sviluppo software: quando scrivevo in basic mi sembrava che il modo migliore per scrivere software fosse passare all'assembler per sfruttare al meglio le risorse della macchina, cosa che oggi invece non rispecchia assolutamente la realta' che vede come allontanarsi dall'hardware verso nuove astrazioni rappresenti il modo migliore di sfruttare l'hardware che possediamo in modo da contenere la complessita' del dettaglio che occorre gestire.
A valle di quest considerazioni direi che:
in termini di linguaggio c'e' un assordante mancanza: il C. Ovvero la pietra miliare dei linguaggi di programmazione che in una retrospettiva storica non puo' mancare.
credo che il repo ed il progetto manchino di un nome.
credo che la presentazione dovrebbe prendere nella rete sia quei pesciolini che come me possono vivere degli amarcord della loro infanzia, che tutti coloro che hanno vissuto la programmazione in tempi piu' recenti e magari si immaginano poco quanto si scrivesse codice vicino all'hw. In tal senso potrebbe essere carina anche una implementazione in COBOL che a molti sembra solo un animale mitologico e che potrebbero trovarsi di fronte per la prima volta.
Imposterei percio' il tutto con un linguaggio per slide in ordine di tempo mostrando per ogni linguaggio le evoluzioni e il crescente livello di astrazione se possibile con qualche cenno storico, sistemi operativi da batch a time-sharing a cooperative a preemptive multitasking, o il millenim bug, etc).
Una volta finita la carrellata non lunghissima aprirei la discussione cercando le esperienze di ognuno.
Scusate la lunghezza della mail ed il fatto che... non ho il tempo di rileggerla :D Spero che abbia senso.
My two eurocents, -- gk
L'obiettivo della serata è "birra con chiacchiere nerd", questa opera vuole stimolare l'interesse ed il dialogo.
Retroaccademy non è formata da traslocatori ma vuole far rivivere quello che tu hai provato anche a chi ha perso questa occasione.
Il confronto quindi non è una sfida tra linguaggi ma vuole essere una opportunità di dibattito: perché nella versione in Basic le variabili sono di una lettera? Perché usare un Vector
in Java 1?
Mi accorgo con piacere che questo (banale) esercizio sta funzionando bene: accendiamo l'interesse in chi vuol sapere e diamo l'opportunità a chi sa di improvvisare un mini-talk.
Sblendorio ha proposto di far girare il codice per Commodore, stiamo offrendo un giro su auto d'epoca.
Aggiungere i linguaggi su JVM è l'estensione di questa finalità per il contesto JUG.
È vero: manca il C, ma personalmente non sento di avere le competenze per scriverlo. Ti assicuro che già scrivere il codice per Java 1.0 in stile '95 è stato non banale.
Ciao Francesco,
spero di non essere stato frainteso: chiedenso il senso non stavo criticando ma, essendo fuori dalla parte iniziale ma essendomi piaciuta l'idea, non sono a conoscenza del motivo per cui tutto questo sia nato. Mi piaceva comprenderne il senso (so che il senso c'e' ma Vasco mi ha preso la mano 😄) per aiutarvi a proporre idee su come presentare il tutto.
Non ho mai pensato che le persone di retroaccademy siano traslocatori (?) ne' che fosse una sfida tra linguaggi (?) ma come scrivevo e' bello vedere l'evoluzione che la nostra professione ha avuto nel tempo e credo possa interessare molti.
Credo che mettere il C sarebbe importante. Se riesco ne abbozzo un'implementazione sempre che mi ricordi abbastanza,
So per esperienza che mettere in piedi cose come questa richiede sforzo! Per cui grazie del lavoro e di avermi fatto ricordare con un sorriso i cicli di clock andati 😃
Non sei stato frainteso affatto :)
Anzi, se permetti, ti presento una code review del codice. I linguaggi moderni, rispetto ai precedenti, hanno una sintassi molto fluente, questo agevola una scrittura in stile wall of text: comandi diversi concatenati sulla stessa riga.
Sarò retrò ma ritengo che sia più difficile da leggere, nello specifico
ordered.group_by(&:itself).map {|k, v| {k => v.size}}.reduce(:merge)
lo presenterei come:
ordered
.group_by(&:itself)
.map {|k, v| {k => v.size}}
.reduce(:merge)
anche questo
(quicksort(l.select {|n| n < p}) << p << quicksort(l.select {|n| n >= p})).flatten
di fatto è il quicksort su una sola riga :)
Prendile come mie mere considerazioni personali.
Invece toglimi una curiosità, la riga 3
p = l.shift
muta il parametro di input l
?
A fine ordinamento alla lista numbers
manca il primo elemento?
Parto dal fondo: si' p = l.shift
fa letteralmente lo shift di un array mutando anche la lista l
e no non manca nessun elemento. Perche' lo chiedi?
Per quanto riguarda lo stile non so quanta confidenza tu abbia con Ruby ma spezzare le catene di invocazioni su ogni funzione e' molto "javoso" e non fa parte dello stilema di Ruby.
Tieni in conto che la leggibilita' e' neglio occhi di chi guarda e persone abituate a leggere differenti stilemi o che arrivano da differenti background possono pensare che l'altro stilema sia controintutitivo. Difficilmente scriverei codice java con una variabile di una sola lettera mentre in genere in Ruby sono preferibili variabili brevi soprattutto quando sono parametri delle lambda.
Se non lo avessi ancora visto c'e' un talk molto bello sull'argomento di Paolo Perrotta
Giusto per condividere i miei dubbi nella versione Ruby avrei potuto approcciare il codice in maniera piu' OO invece che scriptosa come ho fatto. Il supporto all'OO di Ruby e' splendido e completo (tutto e' un oggetto) ma poi ho pensato che un rubista darebbe molto valore alla semplicita' e dato lo scopo dell'esercizio ho pensato di mantenerlo il piu' semplice possibile.
non manca nessun elemento. Perche' lo chiedi?
Mera curiosità, a prima vista non mi aspettavo che mutasse l'input.
Ma la documentazione fornita dice:
Removes the first element of self and returns it (shifting all other elements down by one).
Se così non fosse non sarebbe necessario aggiungere il pivot
quicksort(l.select {|n| n < p}) << p << quicksort(l.select {|n| n >= p})
Lo shift
sembra quello della Bash, non un rotate
, correggimi se sbaglio.
Se il pivot non fosse rimosso non si potrebbe definire (sempre) il passo n-1
della ricorsione.
PS: Non manca il punto esclamativo alla definizione di shift
?
Se non fosse rimosso l'elemento quello che dici sarebbe tutto esatto, ma... come ti dicevo e' rimosso :) Per cui si', lo shift funziona come quello della Bash.
Il punto esclamativo in Ruby indica (solo come coding convention) i metodi "pericolosi" e spesso vengono annoverati tali quelli che mutano l'oggetto su cui vengono invocati ma non e' una condizione necessaria ne' sufficiente.
La mancanza di punto esclamativo significa che il metodo non e' considerato "pericoloso". Il motivo (ma questa e' una mia educated guess) penso che sia riconducibile al fatto che shift
senza punto esclamativo non avrebbe senso non tenendo piu' fede al suo nome e diventando indistinguibile da un metodofirst
.
Ho provato ad eseguire il codice ruby con la versione di jruby rilasciata in Xubuntu (1.7.22-1ubuntu1) e non funziona, quale versione di JRuby è richiesta ed in che anno è stata rilasciata?
Questa è la versione che ho usato io per far girare il codice:
http://jruby.org/2016/01/26/jruby-9-0-5-0.html
Strano che non funzioni, non mi sembra di aver usato funzionalità del linguaggio particolarmente avanzate.
Grazie, segnato come 9.0.0.0 del 2015.
Bozza presentazione completata
Ho controllato: il metodo itself
è presente solo dalla versione del linguaggio 2.2+.
Si può rendere retrocompatibile con versione precedenti con una piccola modifica.
Fammi sapere se è necessaria.
Dato che siamo passati dalla richiesta di qualche idea sulla presentazione a una code review per un percorso logico a me oscuro, vorrei riprendere un punto dei tre che avevo elencato riguardo la presentazione.
Una delle idee che avevo proposto era quella di dare un titolo al gioco: questa sera mi è venuto in mente "The Imitation Game".
Forse è un po' trito, ma mi sembra essere ficcante in quanto Turing richiama sicuramente la parte retro-academy e l'Imitation potrebbe rappresentare l'imitazione dell'implementazione da un linguaggio all'altro. Vedete voi se vi piace e se ha senso.
Altri due cents. E non si dica che i liguri sono avari 😄 😄 😄
Ho aggiunto la versione C. "The Imitation Game" mi piace come idea di titolo.
Ci stavo lavorando anche io alla versione C ma la ruggine sta facendo muovere i miei ingranaggi molto lentamente. Penso comunque di terminarla per divertimento dato che mi mi sto godendo ogni singolo errore sui puntatori. E ne sto facendo tanti 😸
Grazie per la versione C. Credo sarà significativa nella carrellata generale!
Fammi sapere se è necessaria.
@gicappa non è necessario se vuoi lasciare il livello di compatibilità attuale
The Imitation Game
Ok, anche se questo progetto mi sembra più "The Limitation Game"
La versione del partition
del C è bella complessa!
Bisogna decidere come presentare l'opera.
La struttura ha degli schermi 16:9 su cui potremmo proiettare una presentazione con due linguaggi in confronto. Il confronto è finalizzato alla presentazione dei due linguaggi con l'obiettivo di promuovere l'interesse ed il dialogo tra gli ospiti.
Una prima idea è quella di creare una presentazione da proiettare continuamente su almeno uno di questi monitor.
La prima schermata potrebbe riassumere cosa si è voluto creare, quali linguaggi sono stati utilizzati e chiarire che il codice esposto e le soluzioni adottate hanno il solo scopo dimostrativo.
Le schermate successive presentano le cinque coppie, ad esempio:
Idee?