continuazione da "imparare a programmare"

[DioBrando]

Mi ricollego al post fatto in precedenza focalizzandomi su quel che significa "ritardo tecnologico" e ciò che comporta per i programmatori che l'utilizzano al posto delle alternative che sn ormai giunte compiutamente alla ribalta del mondo informatico: il problema principale è nella produttività.


A questo proposito, ho trovato un interessante documento, che mette in luce proprio Python e Java e si focalizza esattamente sulla produttività.

Link

La comparazione viene fatta mettendo in luce sia le caratteristiche che contraddistinguono i 2 linguaggi e gli esempi di codice: praticamente lo stile che abbiamo adottato fino ad ora.


Sostanzialmente buona parte delle cose che troviamo scritte, sono già state trattate nelle pagine prima dei due thread:

concise (aka terse)
"expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous"

compact

In The New Hacker's Dictionary, Eric S. Raymond gives the following definition for "compact":
Compact adj. Of a design, describes the valuable property that it can all be apprehended at once in one's head. This generally means the thing created from the design can be used with greater facility and fewer errors than an equivalent tool that is not compact.

Verbosity is not just a matter of increasing the number of characters that must be typed — it is also a matter of increasing the number of places where mistakes can be made. The Java code on the left has 5 control characters: ( ) { } ; where the corresponding Python code has only one control character, the colon. (Or two, if you count indentation. See below.)

questo a proposito del fatto che la quantità di codice scritto non è vero che è ininfluente ai fini del computo totale degli errori.

Technically, Python has another control character that Java does not — indentation. But the requirement for correct indentation is the same in Java as it is in Python, because in both languages correct indentation is a practical requirement for human-readable code. The Python interpreter automatically enforces correct indentation, whereas the Java compiler does not. With Java, you need an add-on product such as the Jalopy code formatter to provide automated enforcement of indentation standards.

L'indentazione forzata è un requisito necessario in Python che costringe chi scrive codice ad essere per forza chiaro (pena la non esecuzione corretta del programma). Negli altri linguaggi, Java compreso, è un requisito richiesto ma non necessario.
Per cui potremmo trovare, come spesso succede quando leggiamo codice scritto da altre persone, uno stile di indentazione diverso dal nostro, che non ci aiuta nella comprensione del codice.


Parallelamente c'è un'intervista in 3 parti con Bruce Eckel (che tutti immagino abbiate almeno sentito nominare) dove parla di Python e del perchè abbia deciso di switchare da Java, dopo averci lavorato praticamente da quando uscì sul mercato:

Parte I
Parte II
Parte III

I 10 punti enunciati si riferiscono al keynote realizzato qlc tempo prima e di cui potete trovare le slide qui.


Io non credo di essere nessuno ma quando personaggi con un minimo di autorevolezza parlano di "maggior compattezza" e di maggior "sintesi" dal punto di vista espressivo, può venire in mente che forse, dico forse, le idee che abbiamo scritto in precedenza e del perchè sia utile scegliere Python, non siano così campate in aria, anche perchè non ce le siamo inventate noi così di sana pianta, sono caratteristiche proprie del linguaggio, universalmente riconosciute.



Sempre sui ritardi tecnologici che ho menzionato all'inizio, sono convinto che questo si ripercuota non solo nella produttività ma anche nella didattica.
Perchè il requisito di scrivere del buon codice, di abituarsi al rigore e di poter assimilare in fretta i concetti teorici per poi poterli applicare, senza perdersi in dettagli non sempre così importanti, sono comuni a tutti e due gli ambiti.

Oltre alle due fonti citate in precedenza ecco quello che scrive Bertrand Meyer:

il C++ e Java mantengono la sintassi contorta del C. David Clark, dell'Università di Canberra, che ha insegnato usando sia Eiffel che Java, ha recentemente scritto a proposito della sua esperienza come segue:
"La mia esperienza ha provato che gli studenti non trovano Java facile da apprendere. Troppe volte il linguaggio è di intralcio a quello che voglio insegnare. [...] La prima cosa che gli studenti vedono è:
public static void main (String [ ] args) throws IOException
Ci sono circa sei differenti concetti in quella singola linea che gli studenti non sono ancora pronti ad imparare. [...] Il solo modo per leggere un numero dalla tastiera è di leggere una stringa e farne il parsing. Nuovamente, questo è qualcosa che disturba già dalla prima lezione. Java tratta i tipi di dato primitivi (int, char, boolean, float, long,...) in modo diverso dagli altri oggetti. [...] La mancanza dei generic1 significa essere costretti ad un casting continuo se si vogliono usare collezioni di elementi come Stack o Hashtable. Questi sono tutti ostacoli per gli studenti alle prime armi, e li distraggono dagli scopi principali del corso".
Questo è vero anche per i professionisti. Una delle ragioni del successo di Eiffel in grandi progetti industriali è che persone con ogni tipo di background - programmatori, ma anche funzionari di banca, commerciali, matematici, ingegneri, eccetera - possono apprenderlo bene e rapidamente, senza dover padroneggiare costrutti complicati e soggetti ad errori ereditati dal C.

In C++ e Java, come fatto notare da David Clark, i tipi base (interi e simili) sono al di fuori del type system degli oggetti. Questo impedisce di implementare un intero filone di pattern object oriented.

L'assenza dei generic in Java rende la programmazione più complessa e porta a serie inefficienze (come la necessità di riconoscere i tipi a run-time) e, peggio ancora, a mancanza di sicurezza, dal momento che è impossibile fare un completo type-checking statico. In altre parole: possibilità di crash a run-time. Questo è tutt'altro che un problema astratto che interessa i soli puristi.

I cast del C++ rendono la garbage collection impossibile. Il risultato: una gestione della memoria "manuale", il che significa tempi di sviluppo molto più lunghi (e spiega in parte perché il software è sviluppato più rapidamente in Eiffel), un lavoro tedioso e noioso per i programmatori, e peggio ancora numerosi bug nel software a causa di aree di memoria non reclamate e puntatori impazziti.

L'assenza dell'ereditarietà multipla in Java rende impossibile il corretto progetto di sistemi object oriented.

La lista delle concrete, spiacevoli conseguenze prosegue ancora. Non è una questione di purezza in sé, è una questione di costruire software più rapidamente e meglio - in altre parole, di guadagnare se lo si fa nel modo giusto, di perdere denaro altrimenti.


La prima parte sottolineata si riferisce a quel che continuo a sostenere proprio nell'ambito della didattica, quando si sceglie Java come strumento invece per esempio di Python e del fatto che si sia costretti a passare sopra certi argomenti, perchè gli studenti non sono in grado di comprenderli; non prima di aver posto le basi di un qualsiasi corso di programmazione.

La seconda sottolineatura si riferisce invece a quel che Cesare ha + volte sottolineato quando si parla di paradigma OO e della differenza che corre tra il modello proposto da Python e quello Java.

Infine vi è un'annotazione proprio sull'ereditarietà multipla a cui avevo accennato nel penultimo post, ovvero che è difficile pensare ad modello OO compiuto in un progetto Java quando l'ereditarietà multipla non viene consentita (se non attraverso il workaround delle interfacce), perchè aggiungo io, modellare l'universo con una gerarchia basata sull'eredità di un'unica classe, è complesso e spesso fin troppo riduttivo.

[cdimauro]

Un altro post da incorniciare però, dico io, ma proprio Eckel dovevi tirare in ballo?!? Adesso scatenerai la terza guerra mondiale!!!

[PGI-Bis]

Il verbo del programmatore: io dico, tu dici, egli motiva. Esempio:

concise (aka terse)
"expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous"

Perchè è bene essere concisi? Non si sa.

Il pezzo citato del tizio di canberra lo salto a piè pari perchè non vale neppure la pena di commentarlo: qualcuno l'ha detta lunga sapendola corta. E non perchè alcuni dei problemi citati trovino una risposta nelle versioni più recenti di Java: perchè non sono problemi in sè.

Dico infine una cosa che è certamente nota a tutti ma sembra passare inosservata. Secondo la scuola scandinava, il "workaround delle interfacce" si chiama ereditarietà in senso proprio mentre il rapporto che sussiste tra due classi direttamente o indirettamente legate dalla clausola extends si chiama estensione o ereditarietà americana.

Quanto ai dieci punti di Eckel, be', via, cerchiamo di essere seri. I confusi libri di Eckel li abbiamo letti tutti.

[cdimauro]

Non ne ho mai letto uno, ma i 10 punti li trovo AMPIAMENTE condivisibili.
In particolare sulle checked exceptions: formalmente utili, ma che complicano enormemente la vita agli sviluppatori.

Sul fatto di essere coincisi, sono d'accordo con te, ma soltanto perché a mio avviso non basta: bisogna che il codice sia ANCHE chiaro.
Il perché, poi, sia utile è una questione legata puramente all'informazione, a mio avviso: più è lungo il codice più è facile che siano introdotti degli errori, e più è facile perdere di vista il problema che si cerca di risolvere.
Ci piazzo un bel IMHO, giusto per chiarire che si tratta di un mio pensiero.

Sul "tizio di Camberra" non so a cosa ti riferisci.

Mentre sull'ereditarietà, che l'approccio alla programmazione orientata agli oggetti "tradizionale" (ereditarierà singola, eventualmente condita con le interfacce) per cercare di modellare la realtà sia stata un fallimento, mi sembra che l'abbia detto anche tu.

[DioBrando]

Originariamente inviato da PGI-Bis

Il verbo del programmatore: io dico, tu dici, egli motiva. Esempio:

concise (aka terse)
"expressing much in a few words. Implies clean-cut brevity, attained by excision of the superfluous"

Perchè è bene essere concisi? Non si sa.

penso sia un bene come lo è in tutti gli altri campi di espressione linguistica (a parte la politica, dove + si fanno giri di parole senza dire niente e + si appare dotati di personalità e dialettica).
Se si è concisi, a patto come diceva Cesare di essere anche chiari, ci si focalizza sulle idee da esporre senza tanti fronzoli.

"Il dono della sintesi", così lo chiamano no?

Il pezzo citato del tizio di canberra lo salto a piè pari perchè non vale neppure la pena di commentarlo: qualcuno l'ha detta lunga sapendola corta. E non perchè alcuni dei problemi citati trovino una risposta nelle versioni più recenti di Java: perchè non sono problemi in sè.

Nelle versioni successive il problema di presentare, in un pezzo di codice banale qual'è un HelloWorld, strutture che vengono accantonate temporaneamente, mi pare rimanga.
E sarà sempre così a meno che Java non diventi un'altra cosa, che non sia Java.

E questo nella didattica, come ho avuto modo di scrivere + volte, non credo sia il massimo per chi ha voglia di addentrarsi nella programmazione.

Dico infine una cosa che è certamente nota a tutti ma sembra passare inosservata. Secondo la scuola scandinava, il "workaround delle interfacce" si chiama ereditarietà in senso proprio mentre il rapporto che sussiste tra due classi direttamente o indirettamente legate dalla clausola extends si chiama estensione o ereditarietà americana.

Stroustrup lo includiamo nella scuola scandinava?
Perchè non mi risulta sia concorde con questa classificazione.

Quanto ai dieci punti di Eckel, be', via, cerchiamo di essere seri. I confusi libri di Eckel li abbiamo letti tutti.

Al di là del fatto che trovo i punti + che condivisibili, non mi pare i suoi libri siano così confusi.
Thinkin' in Java l'ho trovato un buon libro e non meno "confuso" dei tanti che trattano il medesimo argomento.

Cmq sarei ben felice di trovarne di meglio, chessò magari scritti di tuo pugno, così da poter constatare le differenze.


Il migliore che trattasse Java e l'OO, con un taglio indirizzato al principiante o quasi, è Programmare con Java; anche perchè è l'unico che ho incontrato il quale, seppur redatto da evangelist, non maschera i falsi miti che hanno circondato questo linguaggio e questa piattaforma fin dalla sua nascita.

Un livello di criticità che è merce rara di questi tempi. IMHO naturalmente.

[cdimauro]

Originariamente inviato da DioBrando

penso sia un bene come lo è in tutti gli altri campi di espressione linguistica (a parte la politica, dove + si fanno giri di parole senza dire niente e + si appare dotati di personalità e dialettica).
Se si è concisi, a patto come diceva Cesare di essere anche chiari, ci si focalizza sulle idee da esporre senza tanti fronzoli.

"Il dono della sintesi", così lo chiamano no?

Non è soltanto questione di chiarezza e di compattezza, e la frase che hai scritto e che ho evidenziato IMHO è la chiave di tutto: il programmatore deve prima di tutto MODELLARE la soluzione al problema.

Python permette di farlo in maniera semplice, chiara e veloce: codice compatto, ma non per questo illeggibile (a meno che, come me, non ci si metta i mezzi per renderlo tale ).

L'ho scritto altre volte, ma lo ribadisco nuovamente: la definizione "Python è pseudocodice eseguibile" è azzeccatissima nell'esprimere, in poche parole, cosa significhi lavorare con questo linguaggio.

In soldoni: il vantaggio di una rapida (e chiara) prototipazione del modello, ma che... è già codice finalizzato, di produzione, pronto per essere usato.

[DioBrando]

sì è quel che ripetiamo + o - dall'inizio.
Se si possono trascurare maggiormente i dettagli implementativi e concentrarsi sulla risoluzione del problema, si guadagna in produttività. (e dato che alcuni requisiti poi vengono mutuati anche in ambito accademico, e viceversa, Python risulta una buona scelta anche come strumento in un corso di programmazione)

L'articolista del primo link parla di un aumento di 5 volte tanto.
Ora, io non saprei quantificare, anche perchè occorrerebbe una statistica non basata sull'esperienza di una sola persona, però il fatto IMO resta.

E sintesi non vuol dire povertà dal punto di vista della semantica: questo è un punto importante.


"pseudocodice eseguibile" è carina, non l'avevo mai sentita.
Opera tua o presa in prestito?

[cdimauro]

Presa in prestito, ma non ricordo chi e dove l'ho letta. Comunque il malefico Eckel ne parla qui http://www.artima.com/intv/tipping3.html pure lui.

Sulla produttività aumentata di 5 volte (e più), per la MIA esperienza posso confermare.

[DioBrando]

Originariamente inviato da cdimauro

Presa in prestito, ma non ricordo chi e dove l'ho letta. Comunque il malefico Eckel ne parla qui http://www.artima.com/intv/tipping3.html pure lui.

Sulla produttività aumentata di 5 volte (e più), per la MIA esperienza posso confermare.

Non sò se l'hai letta lì per la prima volta, ma Alex Martelli, lo sviluppatore che avevo citato in precedenza ( e di cui hai letto anche tu il "modesto" curriculum") ne parla proprio in questi termini:

Link

Python � praticamente pseudo-codice eseguibile


Tra () il libro citato da Eckel, Programming in Python è un buon libro a riguardo. Forse non proprio adatto per i principianti, ma decisamente un buon libro.

[cdimauro]

No, non l'ho letta lì (peccato per i caratteri accentati che sono sballati, perché quella guida di Martelli mi sembra piuttosto semplice e concisa), ma in qualche articolo (in inglese) che m'è capitato tempo fa.

Programming in Python non lo conosco.

[mad_hhatter]

Originariamente inviato da DioBrando

[...]

l'arroganza che poni in alcune delle tue frasi comincia un po' a infastidirmi, francamente.
cio' premesso, e' abbastanza evidente che usiamo gli stessi termini riferendoci a cose sufficientemente diverse... per te fondamenti1 indica qualcosa che non corrisponde al corso di cui io sto parlando e che contiene, invece, un'introduzione alla programmazione, alle strutture di dati, alla teoria della complessita' algoritmica. In questo percorso lo studente inizia a familiarizzare con i concetti di variabile, istruzione, ecc applicati al linguaggio assembly in modo da vedere le interazioni con l'hardware sottostante e avere una idea semplificata di quale sia lo scopo di un compilatore. Acquisiti questi rudimenti, allo studente viene presentata la programamzione OO con una definizione semplice e intuitiva dei concetti fondamentali di oggetto, classe, interfaccia, ecc...
a me non pare che, per fare un paragone, al corso di analisi1 il professore prima di introdurre le funzioni faccia giocare gli studenti con le 4 operazioni... al contrario fornisce la definizione rigorosa del concetto di numero, di operatore, ecc... e questo non mi pare sconvolgente, ma anzi molto importante per gettare le fondamenta che reggono l'intera impalcatura del corso.

tu dici: "l'introduzione può avvenire fin da subito.
Ma un conto è la definizione e la presentazione, un altro conto è spiegare come questi concetti vengono utilizzati."

ti rispondo, molto semplicemente, che anche la spiegazione del loro uso puo' passare per vari gradi di approfondimento, non vedo dove stia il problema, ad esempio, nell'accennare un paio di esempi d'uso di un modificatore di accesso senza per forza presentare l'intero impianto normativo che ne sta alla base.

poi continui dicendo: "annotazione che personalmente ho trovato superflua perchè nessuno si è mai sognato di dire o di pensare che la pratica possa sostituire la teoria, quando si tratta di imparare a programmare..."

ti rispondo, tralasciando il tono da te usato, che non e' per niente superflua come annotazione perche' non esiste un modo univoco di suddivedere e dosare teoria e pratica... e' infatto possibile che persone diverse diano un connotato diverso alla parola "teoria".

continuando, dici:
"Hai cominciato col dire che prima và insegnata la teoria e poi l'applicazione, che insieme alla scelta del linguaggio, è una fase secondaria.
Quando ti è stato fatto notare che questo metodo non funziona perchè uno studente dopo che si trova imbottito di nozioni senza applicarle, poi semplicemente perde interesse nella programmazione, e che il metodo + sensato è quello di procedere passo passo con piccoli esempi e la spiegazione teorica, hai detto che "era quello che intendevi".
Al che, ti ho risposto che se era questo il tuo pensiero, era una contraddizione: non potevi infatti affermare che la scelta del linguaggio fosse secondaria, perchè non sarebbe possibile poi far vedere come le strutture sintattiche interagiscano tra loro, senza scrivere del codice (in un X linguaggio)."

ti faccio notare che per mettere in pratica i concetti esposti in un corso di introduzione alla programmazione un qualunque linguaggio va bene perche' non e' il linguaggio in se' l'oggetto della didattica. quindi non esiste contraddizione nel dire che la teoria risulta piu' efficacie se accompagnata da qualche esercizio e contemporaneamente che il linguaggio adottato per costruire gli esempi e' una questione secondaria (posto che il linguaggio sia adatto allo scopo).

infine, scrivi:
"Il confronto tra i due "Hello World" era mirato a far vedere come, mentre in Python, ci si può concentrare maggiormente sulla parte algoritmica perchè il linguaggio è sintetico ma ricco dal punto di vista espressivo, con Java invece, un principiante si trova a dover utilizzare PER FORZA costrutti di cui all'inizio non potrà capire lo scopo nè il come interagiscano tra loro.

Avrà un quadro generale di cosa sia la POO, conoscerà la definizione di classe, ma non sarà in grado di capire come si utilizza, come si istanzia, di cosa si compone, perchè gli mancano appunto le basi.

Quindi qual'è il senso di imbottire di concetti uno studente, se poi l'applicazione pratica seguirà una progressione differente?
Per me nessuno."

io ripeto che nella definizione di oggetto, classe, ecc non vedo nulla di trascendentale per uno studente universitario di una facolta' di informatica... tant'e' che dopo l'Hello World ci e' stato presentato un piccolo esempio, molto semplice, ma molto formativo, di oggetto, di interazione tra oggetti, ecc... e ripeto che la cosa non ha suscitato il minimo scandandalo negli studenti...

e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose anzi, ne e' avido e non vuole dolcificanti sintattici perche' non gli interessa la produttivita', gli interessa la conoscenza scientifica degli oggetti che gli vengono presentati

[D3stroyer]

beh, io da studente a c++ capito, ora sto facendo fatica a capire come far dire "hello world" a java

[cdimauro]

Originariamente inviato da mad_hhatter

l'arroganza che poni in alcune delle tue frasi comincia un po' a infastidirmi, francamente.
cio' premesso, e' abbastanza evidente che usiamo gli stessi termini riferendoci a cose sufficientemente diverse... per te fondamenti1 indica qualcosa che non corrisponde al corso di cui io sto parlando e che contiene, invece, un'introduzione alla programmazione, alle strutture di dati, alla teoria della complessita' algoritmica. In questo percorso lo studente inizia a familiarizzare con i concetti di variabile, istruzione, ecc applicati al linguaggio assembly in modo da vedere le interazioni con l'hardware sottostante e avere una idea semplificata di quale sia lo scopo di un compilatore. Acquisiti questi rudimenti, allo studente viene presentata la programamzione OO con una definizione semplice e intuitiva dei concetti fondamentali di oggetto, classe, interfaccia, ecc...
a me non pare che, per fare un paragone, al corso di analisi1 il professore prima di introdurre le funzioni faccia giocare gli studenti con le 4 operazioni... al contrario fornisce la definizione rigorosa del concetto di numero, di operatore, ecc... e questo non mi pare sconvolgente, ma anzi molto importante per gettare le fondamenta che reggono l'intera impalcatura del corso.

tu dici: "l'introduzione può avvenire fin da subito.
Ma un conto è la definizione e la presentazione, un altro conto è spiegare come questi concetti vengono utilizzati."

ti rispondo, molto semplicemente, che anche la spiegazione del loro uso puo' passare per vari gradi di approfondimento, non vedo dove stia il problema, ad esempio, nell'accennare un paio di esempi d'uso di un modificatore di accesso senza per forza presentare l'intero impianto normativo che ne sta alla base.

poi continui dicendo: "annotazione che personalmente ho trovato superflua perchè nessuno si è mai sognato di dire o di pensare che la pratica possa sostituire la teoria, quando si tratta di imparare a programmare..."

ti rispondo, tralasciando il tono da te usato, che non e' per niente superflua come annotazione perche' non esiste un modo univoco di suddivedere e dosare teoria e pratica... e' infatto possibile che persone diverse diano un connotato diverso alla parola "teoria".

continuando, dici:
"Hai cominciato col dire che prima và insegnata la teoria e poi l'applicazione, che insieme alla scelta del linguaggio, è una fase secondaria.
Quando ti è stato fatto notare che questo metodo non funziona perchè uno studente dopo che si trova imbottito di nozioni senza applicarle, poi semplicemente perde interesse nella programmazione, e che il metodo + sensato è quello di procedere passo passo con piccoli esempi e la spiegazione teorica, hai detto che "era quello che intendevi".
Al che, ti ho risposto che se era questo il tuo pensiero, era una contraddizione: non potevi infatti affermare che la scelta del linguaggio fosse secondaria, perchè non sarebbe possibile poi far vedere come le strutture sintattiche interagiscano tra loro, senza scrivere del codice (in un X linguaggio)."

ti faccio notare che per mettere in pratica i concetti esposti in un corso di introduzione alla programmazione un qualunque linguaggio va bene perche' non e' il linguaggio in se' l'oggetto della didattica. quindi non esiste contraddizione nel dire che la teoria risulta piu' efficacie se accompagnata da qualche esercizio e contemporaneamente che il linguaggio adottato per costruire gli esempi e' una questione secondaria (posto che il linguaggio sia adatto allo scopo).

infine, scrivi:
"Il confronto tra i due "Hello World" era mirato a far vedere come, mentre in Python, ci si può concentrare maggiormente sulla parte algoritmica perchè il linguaggio è sintetico ma ricco dal punto di vista espressivo, con Java invece, un principiante si trova a dover utilizzare PER FORZA costrutti di cui all'inizio non potrà capire lo scopo nè il come interagiscano tra loro.

Avrà un quadro generale di cosa sia la POO, conoscerà la definizione di classe, ma non sarà in grado di capire come si utilizza, come si istanzia, di cosa si compone, perchè gli mancano appunto le basi.

Quindi qual'è il senso di imbottire di concetti uno studente, se poi l'applicazione pratica seguirà una progressione differente?
Per me nessuno."

io ripeto che nella definizione di oggetto, classe, ecc non vedo nulla di trascendentale per uno studente universitario di una facolta' di informatica... tant'e' che dopo l'Hello World ci e' stato presentato un piccolo esempio, molto semplice, ma molto formativo, di oggetto, di interazione tra oggetti, ecc... e ripeto che la cosa non ha suscitato il minimo scandandalo negli studenti...

e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose anzi, ne e' avido e non vuole dolcificanti sintattici perche' non gli interessa la produttivita', gli interessa la conoscenza scientifica degli oggetti che gli vengono presentati

Se qualunque linguaggio va bene per la didattica, allora si può benissimo partire dal linguaggio macchina e quindi dalle tabelle degli opcode.

Nel momento in cui lo scopo è la didattica, il linguaggio NON può essere di secondaria importanza, perché è chiaro che condiziona, anche pesantemente, i concetti da apprendere e modifica la curva di apprendimento.

EDIT: quotato messaggio di mad_hhatter.

[cdimauro]

Originariamente inviato da D3stroyer

beh, io da studente a c++ capito, ora sto facendo fatica a capire come far dire "hello world" a java

E' evidente che, pur essendo partito da un linguaggio di più basso livello qual è il C++, è colpa tua che non vuoi conoscere a fondo come funzionano le cose (in Java) e ne hai paura...

E mi scandalizzo pure per la tua incapacità a comprendere una cosa banale come un "hello, world" in Java.

[mad_hhatter]

Originariamente inviato da cdimauro

Se qualunque linguaggio va bene per la didattica, allora si può benissimo partire dal linguaggio macchina e quindi dalle tabelle degli opcode.

Nel momento in cui lo scopo è la didattica, il linguaggio NON può essere di secondaria importanza, perché è chiaro che condiziona, anche pesantemente, i concetti da apprendere e modifica la curva di apprendimento.

questi commenti sono privi di senso, in quanto ho espressamente detto che il linguaggio deve comunque assere adatto allo scopo che ci si prefigge... cosi', per esempio, mentre per il concetto di istruzione e di variabile va bene anche soltanto l'assemply, per una didattica che si occupi di OOp non si puo' non adottare un linguaggio OO...

[mad_hhatter]

Originariamente inviato da cdimauro

E' evidente che, pur essendo partito da un linguaggio di più basso livello qual è il C++, è colpa tua che non vuoi conoscere a fondo come funzionano le cose (in Java) e ne hai paura...

E mi scandalizzo pure per la tua incapacità a comprendere una cosa banale come un "hello, world" in Java.

il tuo sarcasmo e' completamente fuori luogo.

in nessun post ho mai affermato che il fatto che la scelta del linguaggio a supporto della didattica sia secondaria significhi che, imparato un qualunque linguaggio, si sia in grado di passare a qualsiasi altro linguaggio in quattro e quattr'otto

[mad_hhatter]

Originariamente inviato da D3stroyer

beh, io da studente a c++ capito, ora sto facendo fatica a capire come far dire "hello world" a java

il fatto di conoscere un linguaggio non implica che l'utilizzo di un qualsiasi altro linguaggio sia semplice e immediato

[cdimauro]

Originariamente inviato da mad_hhatter

questi commenti sono privi di senso, in quanto ho espressamente detto che il linguaggio deve comunque assere adatto allo scopo che ci si prefigge... cosi', per esempio, mentre per il concetto di istruzione e di variabile va bene anche soltanto l'assemply, per una didattica che si occupi di OOp non si puo' non adottare un linguaggio OO...

Quindi posso assumere che per imparare la programmazione strutturata vada benissimo il linguaggio macchina, per quella funzionale il LISP, e per quella OOP PERL?

[cdimauro]

Originariamente inviato da mad_hhatter

il tuo sarcasmo e' completamente fuori luogo.

Non è affatto fuori luogo: ho semplicemente applicato i concetti che hai espresso al messaggio di D3stroyer.

in nessun post ho mai affermato che il fatto che la scelta del linguaggio a supporto della didattica sia secondaria significhi che, imparato un qualunque linguaggio, si sia in grado di passare a qualsiasi altro linguaggio in quattro e quattr'otto

Hai posto dei vincoli precisi:

"e' evidente che chi VUOLE conoscere a fondo come funzionano le cose non si spaventa per certe cose" ecc. ecc.

per cui è evidente che D3stroyer NON vi rientri. Sarcasmo o non sarcasmo, questa è banale logica.

[mad_hhatter]

Originariamente inviato da cdimauro

Quindi posso assumere che per imparare la programmazione strutturata vada benissimo il linguaggio macchina, per quella funzionale il LISP, e per quella OOP PERL?

non lo so, dipende dal tuo scopo