continuazione da "imparare a programmare"

[k0nt3]

Originariamente inviato da cdimauro

In Pascal (Delphi, per l'esattezza) hai già molti degli elementi che ritrovi in Java (oggetti sempre come riferimenti, interfacce, moduli che racchiudono codice, stringhe, e altro), per cui trovo normale che tu non abbia avuto problemi.

ma io non ho mai usato delphi

Originariamente inviato da cdimauro

Io suggerisco di partire dal linguaggio macchina (quindi nemmeno con l'assembly), e in particolare con l'ISA Itanium di Intel.

non è costruttivo rispondere con simili affermazioni. non considero nemmeno il linguaggio macchina perchè evidentemente è solo una provocazione, ma l'assembly non va bene solo perchè richiede conoscenze basilari sull'architettura di una cpu, per il resto non ha niente che non va

Originariamente inviato da cdimauro

Scelgo Perl.

e fai male visto che non è prettamente un linguaggio a oggetti, ma è anche procedurale e funzionale

Originariamente inviato da cdimauro

No no: lasciamo pure ampia libertà, visto che si può scegliere qualunque linguaggio.

ci mancherebbe che le scelte siano obbligatorie

Originariamente inviato da cdimauro

Linguaggio macchina e PERL vanno benissimo per imparare la programmazione strutturata e quella a oggetti.

no non vanno bene

Originariamente inviato da cdimauro

Su questo ho avuto già modo di dimostrare che non hai ancora capito com'è fatto e come funziona Python: ci sono dei messaggi in cui l'ho messo in chiaro, ma evidentemente ti saranno sfuggiti.

ma anche no. so come funziona python

Originariamente inviato da cdimauro

Adesso ci spieghi anche il perché di questa tua frase lapidaria.

banalmente perchè non sono pensati per essere usati in questo modo

[cdimauro]

Originariamente inviato da mad_hhatter

non conoscendo ne' lisp ne' perl non posso dare una risposta piu' precisa di questa: se l'obiettivo e' soltanto far capire cosa sia una variabile, una procedura (o metodo, o funzione) e far capire il concetto di istruzione e di sequenza di istruzioni, allora si', anche la programmazione in linguaggio assembly puo' servire a dare questo tipo di visione...

ma questo tipo di linguaggio non puo' servire ad altro: molto meglio passare ad un linguaggio di alto livello il prima possibile (se non addirittura da subito).

Imparare a programmare e fermarsi soltanto a questi concetti non sarebbe utile: parli già di cambiare linguaggio quando se ne è appena appreso uno per iniziare.

Comunque stai già affermando che qualunque linguaggio non va bene per imparare a programmare, visto che mi dici che sarebbe addirittura auspicabile partire da SUBITO con uno di alto livello: è evidente che la SCELTA del linguaggio, quindi, ha un ruolo fondamentale, al contrario di quello che hai sostenuto finora.

detto questo, se l'obiettivo di mostrare la programmazione strutturata e' soltanto quello di far apprendere l'uso dei costrutti iterativi e condizionali, allora tanto vale passare immediatamente a un linguaggio OO (o funzionale se questo fosse in linea con gli obiettivi didattici...). quello che penso, infatti, e' che costrutti di questo tipo non hanno bisogno di essere dimostrati praticamente: se mi dici che
if (condition)
statement1
else
statement2

significa che se condition e' vera viene eseguito statement1 altrimenti viene eseguito staement2, non credo ci sia molto altro da "far vedere" e che necessiti un esempio di implementazione al calcolatore...

No, l'obiettivo è quello di iniziare a programmare e NON fermarsi soltanto ai primi concetti che si affrontano. Per inciso, visto che a un programmatore servono strutture dati diverse in base al tipo di problema da risolvere, studierei anche quelli più comuni (stringhe, record/struct, array, alberi, grafi, ecc.).

in ogni caso anche questi costrutti sono facilmente descrivili in linguaggio assembly... anzi, trovo che offra una comprensione approfondita di come funzionino tali costrutti, la cui logica e' decisamente semplice.

L'assembly (come il linguaggio macchina) esprime "nativamente" soltanto questi concetti:
- salto incondizionato;
- salto condizionato;
- salto a subroutine;
- salto a routine del s.o. (supportato soltanto da alcune ISA);
- loop (supportato soltanto da alcune ISA).

Costrutti come if/then/else, switch, for, while, repeat, sono a un livello più alto, e non è necessario studiarli per imparare la programmazione strutturata (parlando sempre di assembly e linguaggio macchina).

cio' detto, passando a un linguaggio OO avendo gia' idea di cosa sia un'istruzione, un algoritmo, ecc... non penso ci siano ostacoli nell'instrodurre i concetti propri della programmazione OO...

Concordo.

un metodo probabilmente piu' complesso, ma per nulla assurdo potrebbe essere quello di rovesciare la linea temporale: prima spiegare cosa sia un oggetto, descrivendo la programmazione come ricerca di un modello per una data situazione e solo dopo descrivere dettagli tecnici come il concetto di istruzione, variabile ecc... seppur piu complesso, questo metodo ha il vantaggio di dare prima una visione di altissimo livello al concetto di programmazione, e solo dopo introduce lo studente nei dettagli tecnici della programmazione...

Generalmente si dà un accenno di cosa voglia dire sviluppare un algoritmo.

e' chiaro comunque che un metodo universale non possa esistere, ma vada scelto il metodo piu adatto in funzione di chi e' il destinatario della lezione

Le condizioni le avevo scritte: insegnare a programmare a chi non ha alcuna conoscenza in materia.

La scelta del linguaggio, come anche tu lasci intendere sopra e contrariamente a quello che avevi affermato finora, è MOLTO importante (altrimenti non si capisce per quale motivo si dovrebbe iniziare da subito con un linguaggio di alto livello, come suggerivi).

Io posso anche basare un corso di introduzione alla programmazione, partendo da quella strutturata, interamente sul linguaggio macchina, se la scelta può essere arbitraria, e quindi NON fermarmi soltanto al concetto di dato, variabile e istruzione, ma affrontare (molto più avanti ovviamente) persino il concetto di albero rosso-nero.
Per far questo sceglierei l'ISA dell'Itanium di Intel, un particolare processore VLIW che esegue bundle a 128 bit contenenti 3 istruzioni debitamente sistemate al suo interno (perché esistono NUMEROSE regole e vincoli: le istruzioni non si possono "mischiare" a piacimento).

Bada bene che ho sempre parlato di linguaggio macchina e mai di assembly. Il fatto che la scelta del linguaggio sia ritenuta del tutto arbitraria, mi permette di optare per il primo, e in particolare per l'ISA di cui sopra.

Questo vuol dire anche rinunciare a tutte le comodità che forniscono gli assemblatori, in primis il calcolo degli offset per le istruzioni di salto e i dati, che col primo si devono necessariamente calcolare a mano e soprattutto ricalcolare ogni volta che vengono inserite nuove istruzioni e/o dati oppure ne vengano cancellate alcune.
Un lavoro inumano che personalmente non augurerei nemmeno al mio peggior nemico (visto che c'ho lavorato per qualche tempo e so cosa significhi).

Ma se la scelta è arbitraria, anche quella del linguaggio macchina per la programmazione strutturata è perfettamente valida.

Come pure sarebbe valida quella di Perl per quella a oggetti, visto che offre la possibilità di lavorarci (guarda qui http://perldoc.perl.org/perlboot.html il tutorial per iniziare a programmare a oggetti con PERL; ci sono altri 3 link sul sito che lo affrontano in maniera più approfondita, ma te li sconsiglio vivamente; se hai poco tempo e vuoi farti velocemente un'idea di come si lavora con gli oggetti in Perl, qui http://www.garshol.priv.no/download/...erl.html#id3.5. trovi una rapidissima trattazione).

In definitiva, quello che voglio ribadire ancora una volta è che la scelta di un linguaggio ha, invece, notevoli ricadute, e per questo non è vero che qualunque linguaggio che permetta di esprimere un particolare paradigma va bene, in particolare per iniziare.

L'esempio del linguaggio macchina penso sia piuttosto eloquente, e ti assicuro che quello di Perl non è certo da meno.

[cdimauro]

Originariamente inviato da k0nt3

ma io non ho mai usato delphi

Pensavo di sì, allora per quanto riguarda le classi che usano riferimenti e le interfacce non vale quanto avevo scritto.

non è costruttivo rispondere con simili affermazioni. non considero nemmeno il linguaggio macchina perchè evidentemente è solo una provocazione,

E' chiaro che sia una provocazione, ma la scelta è perfettamente valida sul piano formale, visto che non esistono vincoli e la scelta del linguaggio è libera.

ma l'assembly non va bene solo perchè richiede conoscenze basilari sull'architettura di una cpu, per il resto non ha niente che non va

La scelta dell'architettura non è un vincolo, per cui andrebbe benissimo. D'altra parte quando si inizia a programmare in assembly, una qualunque architettura, anche inventata, la si deve scegliere.

Comunque hai detto che andrebbe bene anche l'assembly, e allora ti voglio vedere a implementare un albero rosso-nero con questo linguaggio (e ringrazia che non t'abbia mostrato il codice di un particolare trie che mi sono inventato una dozzina d'anni fa per comprimere i dati: già in Pascal da implementare mi ha richiesto non poco tempo e codice ).

e fai male visto che non è prettamente un linguaggio a oggetti, ma è anche procedurale e funzionale

E allora? La scelta è perfettamente legittima, visto che permette di programmare a oggetti, e tanto basta.

ci mancherebbe che le scelte siano obbligatorie

no non vanno bene

E perché? Se posso scegliere qualunque linguaggio (hai detto anche tu le scelte non sono obbligatorie), io sulla carta posso scegliere quello che voglio. Se non è così dovresti spiegarmi perché non andrebbero bene.

ma anche no. so come funziona python

In tal caso ci sono dei messaggi che t'aspettano e a cui puoi replicare, visto che ho dimostrato che, invece, non lo conosci.

Ripeto: non basta aver imparato la sintassi, e scritto qualche esercizio per passare un corso per poter affermare di conoscere Python.

banalmente perchè non sono pensati per essere usati in questo modo

Allora spiegaci come sono stati pensati e perché non andrebbero "usati in questo modo".

[mad_hhatter]

Originariamente inviato da cdimauro

Imparare a programmare e fermarsi soltanto a questi concetti non sarebbe utile: parli già di cambiare linguaggio quando se ne è appena appreso uno per iniziare.

In definitiva, quello che voglio ribadire ancora una volta è che la scelta di un linguaggio ha, invece, notevoli ricadute, e per questo non è vero che qualunque linguaggio che permetta di esprimere un particolare paradigma va bene, in particolare per iniziare.

L'esempio del linguaggio macchina penso sia piuttosto eloquente, e ti assicuro che quello di Perl non è certo da meno.

continui a prendere i miei discorsi troppo letteralmente e questo, permettimi, non fa proseguire la discussione perchè mi costringi a cesellare anche l'ovvio: è ovvio che la scelta è arbitraria tra i lianguaggi adatti allo scopo. imaparare a programmare coinvolge molti aspetti diversi e per ognuno può essere meglio un linguaggio piuttosto che un altro...

[cdimauro]

Deformazione professionale.

Mi è sufficiente che tu abbia affermato che esistono dei linguaggi "più adatti allo scopo". Quindi c'è un qualche criterio (per lo più personale, dovuto ad esperienza, studi et similia) che ci permette di valutare se un linguaggio è "più o meno adatto".

Dunque la scelta di un linguaggio piuttosto che un altro per imparare a programmare HA SENSO, e quindi ha pure senso la discussione che è stata fatta finora e che ha portato alla selezione di Java e Python quali candidati "migliori"; fra i quali mi sembra che Python, con le argomentazioni che abbiamo fornito (vedi anche l'intervista a Eckel, che è molto utile allo scopo), si dimostra il più adatto.

[mad_hhatter]

Originariamente inviato da cdimauro

Deformazione professionale.

Mi è sufficiente che tu abbia affermato che esistono dei linguaggi "più adatti allo scopo". Quindi c'è un qualche criterio (per lo più personale, dovuto ad esperienza, studi et similia) che ci permette di valutare se un linguaggio è "più o meno adatto".

Dunque la scelta di un linguaggio piuttosto che un altro per imparare a programmare HA SENSO, e quindi ha pure senso la discussione che è stata fatta finora e che ha portato alla selezione di Java e Python quali candidati "migliori"; fra i quali mi sembra che Python, con le argomentazioni che abbiamo fornito (vedi anche l'intervista a Eckel, che è molto utile allo scopo), si dimostra il più adatto.

che abbia senso è naturale, che sia prioritaria è molto discutibile...

che python sia piuttosto adatto non lo discuto, non concordo invece sul fatto che sia il più adatto, perché ripeto che molto dipende dai contenuti specifici che si vogliono veicolare... detto questo, spero di non aver mai negato che sia un degno pretendente, anche se ho sollevato alcuni problemi nella sua adozione... senza che questo metta java automaticamente al primo posto, non essendo esente da problemi... a me interessa solo far notare come il linguaggio in sè sia secondario rispetto ai contenuti concettuali. tutto qua

[mad_hhatter]

Originariamente inviato da cdimauro

Deformazione professionale.

si ti capisco ma qui non staimo dimostrando un teorema

[cdimauro]

Originariamente inviato da mad_hhatter

che abbia senso è naturale, che sia prioritaria è molto discutibile...

Se devi iniziare una scelta sei obbligato comunque a farla.

che python sia piuttosto adatto non lo discuto, non concordo invece sul fatto che sia il più adatto, perché ripeto che molto dipende dai contenuti specifici che si vogliono veicolare...

Beh, per iniziare e per quanto riguarda i corsi che vengono trattati all'università Python può essere usato praticamente ovunque, grazie alla sua flessibilità e il vasto campo d'utilizzo.

detto questo, spero di non aver mai negato che sia un degno pretendente, anche se ho sollevato alcuni problemi nella sua adozione... senza che questo metta java automaticamente al primo posto, non essendo esente da problemi...

Complessivamente Python mi sembra la soluzione migliore.

Eckel ha trattato diversi punti, fra cui anche quelli di cui hai parlato, per cui t'invito a leggerti quei link.

Anche Guido van Rossum, il creatore di Python, ne ha parlato in un'altra intervista sempre nello stesso sito e se hai tempo ti consiglio di leggere pure quella.

a me interessa solo far notare come il linguaggio in sè sia secondario rispetto ai contenuti concettuali. tutto qua

La teoria da sola non serve a niente: l'informatica richiede, e non poco, la sperimentazione, e quindi una scelta va comunque fatta.

Python ha il vantaggio non indifferente di poter smanettare grazie al suo interprete interattivo, quindi di provare immediatamente quel che ci frulla per la testa.

Io lo uso molto spesso per modellare "al volo" una soluzione a un problema, e dopo che ho la prova che il tutto funziona come penso, ricopio quello che ho scritto e lo incollo nel sorgente in cui mi serve.

Non hai idea di quanto sia comodo e produttivo quest'approccio: è impagabile.

Originariamente inviato da mad_hhatter

si ti capisco ma qui non staimo dimostrando un teorema

Vero, ma c'è un problema di cui stiamo discutendo e come programmatore tendo a fornire una soluzione in maniera piuttosto precisa.

[mad_hhatter]

Originariamente inviato da cdimauro

Se devi iniziare una scelta sei obbligato comunque a farla.

è comune scegliere un linguaggio e portare avanti la teoria basandosi su quel linguaggio... ma la teoria è al di là delle specifiche incarnazioni (= linguaggi). Guardando l'educazione che mi è stata impartita avrei preferito di gran lunga aver avuto una panoramica esaustiva dei paradigmi di programmazione, delle basi concettuali comuni ai vari linguaggi (ad esempio, teoria del paradigma OO), e solo dopo vedere questi principi applicati... viceversa si tende a identificare un concetto astratto con l'implementazione che ne viene data in un dato linguaggio e questo per molti versi è penalizzante... capisco che come approccio è molto complesso, ma col senno di poi avrei preferito una formazione più concettuale (o almeno, ancora più concettuale). ma capisco che possa non essere condivisibile.

Originariamente inviato da cdimauro

Beh, per iniziare e per quanto riguarda i corsi che vengono trattati all'università Python può essere usato praticamente ovunque, grazie alla sua flessibilità e il vasto campo d'utilizzo.

Complessivamente Python mi sembra la soluzione migliore.

capisco il tuo punto di vista, l'unica cosa che contesto è che python sia l'unica scelta buona. probabilmente è miope da parte mia, ma continuo a vedere il typesystem dinamico rischioso per chi comincia da zero e non sa esattamente cosa sta facendo...

Originariamente inviato da cdimauro

Eckel ha trattato diversi punti, fra cui anche quelli di cui hai parlato, per cui t'invito a leggerti quei link.

avevo iniziato a leggerlo, prima e indipendentemente dalla discussione che staimo affrontando, ma per motivi di tempo non avevo concluso la lettura... è un'altra delle decine di cose che ammasso nei miei memorandum delle cose da fare con urgenza

anzi, se mi riposti il link del post di eckel e di guido te ne sarei grato, giusto per non dovermi rispolverare il thread

Originariamente inviato da cdimauro

La teoria da sola non serve a niente: l'informatica richiede, e non poco, la sperimentazione, e quindi una scelta va comunque fatta.

concordo, ma solo in parte... va beh, l'avrai capito: sono un patito dell'astrattismo concettuale e non condivido sempre il motto "prima le cose (apparentemente) semplici".

Originariamente inviato da cdimauro

Python ha il vantaggio non indifferente di poter smanettare grazie al suo interprete interattivo, quindi di provare immediatamente quel che ci frulla per la testa.

Io lo uso molto spesso per modellare "al volo" una soluzione a un problema, e dopo che ho la prova che il tutto funziona come penso, ricopio quello che ho scritto e lo incollo nel sorgente in cui mi serve.

Non hai idea di quanto sia comodo e produttivo quest'approccio: è impagabile.

io invece trovo che per buttar giù un'abbozzo di soluzione ilo computer sia ancora troppo limitante e mi affido quasi sempre a carta e penna...
eventualmente apsso poi per un prototipo.

Originariamente inviato da cdimauro

Vero, ma c'è un problema di cui stiamo discutendo e come programmatore tendo a fornire una soluzione in maniera piuttosto precisa.

beh, come dicevi tu, questo è uno di quei casi in cui perdersi nei dettagli può essere controproducente scherzo, ma immagino tu abbia capito cosa intendo

[cdimauro]

Originariamente inviato da mad_hhatter

è comune scegliere un linguaggio e portare avanti la teoria basandosi su quel linguaggio... ma la teoria è al di là delle specifiche incarnazioni (= linguaggi). Guardando l'educazione che mi è stata impartita avrei preferito di gran lunga aver avuto una panoramica esaustiva dei paradigmi di programmazione, delle basi concettuali comuni ai vari linguaggi (ad esempio, teoria del paradigma OO), e solo dopo vedere questi principi applicati... viceversa si tende a identificare un concetto astratto con l'implementazione che ne viene data in un dato linguaggio e questo per molti versi è penalizzante... capisco che come approccio è molto complesso, ma col senno di poi avrei preferito una formazione più concettuale (o almeno, ancora più concettuale). ma capisco che possa non essere condivisibile.

Anche perché i programmi non sono teoria, ma pratica.

Già sviluppare delle applicazioni è difficile e usualmente subentrano quelle cose fastidiosissime chiamate bug: figuriamoci se ci limitassimo soltanto alla teoria.

Poi non so quanto resisterebbe uno qualunque che inizia da zero a imparare a programmare, limitandosi alla sola teoria: farebbe il botto in poco tempo.

capisco il tuo punto di vista, l'unica cosa che contesto è che python sia l'unica scelta buona.

Non ho detto che è l'unica, ma trovo che sia la migliore per quanto riguarda lo scopo prefisso.

probabilmente è miope da parte mia, ma continuo a vedere il typesystem dinamico rischioso per chi comincia da zero e non sa esattamente cosa sta facendo...

Proprio perché parte da zero farà meno danni: gli mancano le informazioni per pacioccare col codice indiscriminatamente.

Comunque di questo, come ti dicevo, ne parlano bene Eckel e van Rossum.

avevo iniziato a leggerlo, prima e indipendentemente dalla discussione che staimo affrontando, ma per motivi di tempo non avevo concluso la lettura... è un'altra delle decine di cose che ammasso nei miei memorandum delle cose da fare con urgenza

anzi, se mi riposti il link del post di eckel e di guido te ne sarei grato, giusto per non dovermi rispolverare il thread

Certamente. Per Eckel:
http://www.artima.com/intv/aboutme.html
http://www.artima.com/intv/prodperf.html
http://www.artima.com/intv/typing.html
http://www.artima.com/intv/tipping.html

Per van Rossum trovi tutti i link qui http://www.artima.com/intv/guido.html

concordo, ma solo in parte... va beh, l'avrai capito: sono un patito dell'astrattismo concettuale e non condivido sempre il motto "prima le cose (apparentemente) semplici".

OK, però cerca di immedesimarti nel tipo comune. Non so se hai avuto esperienze d'insegnamento, ma con la sola teoria non si va molto avanti.

io invece trovo che per buttar giù un'abbozzo di soluzione ilo computer sia ancora troppo limitante e mi affido quasi sempre a carta e penna...
eventualmente apsso poi per un prototipo.

La carta e la penna le ho usate ben poche volte. A volte utilizzo dei file di testo per annotazioni e todo, ma in generale il mio approccio alla risoluzione di problema è costituito dalla seguenti (macro)fasi:
- meditazione sul problema e individuazione delle possibili soluzioni (è quella in cui spendo più tempo; in ciò sposo la tesi di Nikola Tesla, ribaltando la massima di Edison: il genio è il 99% ispirazione e l'1% traspirazione );
- stesura del codice, facendo ricorso a micro-modelli per i casi che devo trattare.
- testing / simulazione, possibilmente con dati reali.

Ovviamente si tratta di un processo iterativo che vede la loro ripetizione fino al raggiungimento dello scopo.

Da un po' di tempo le ultime due fasi tendo a "fonderle", scrivendo dei test e/o delle applicazioni "di controllo" (questo avviene quando l'applicazione è un server; in questo caso sviluppo sempre parallelamente una o più applicazioni client che testano tutte le API del server, una a una, con dati reali o inventati appositamente).

Per come procedo, come dicevo prima, Python mi è estremamente utile perché mi permette di modellizzare velocemente il problema (ed eventuali sottoproblemi), producendo e testando anche il codice allo stesso tempo, grazie all'interprete interattivo.

beh, come dicevi tu, questo è uno di quei casi in cui perdersi nei dettagli può essere controproducente scherzo, ma immagino tu abbia capito cosa intendo

Onestamente no. Sarà perché non ricordo ciò di cui stai parlando, sarà per la giornata pesante, ma non ci sono arrivato.

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

di meno
Con la trasformata di fourier approssimi il segnale reale con una serie di armoniche che per essere completamente corrispondente al segnale originale dovrebbe tendere ad infinito.
Ovviamente nella realtà si approssima BEN prima di infinito, ma cmq rappresentare ad esempio un'onda quadra nel dominio di fourier degrada abbastanza le informazioni contenute nel segnale originario

Era soltanto un esempio per far capire che passando da una base a un'altra il segnale si conserva!!!

Poi è che chiaro nel mondo reale le cose sono diverse.

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

a me personalmente piace + di python

Poi ovviamente dipende da quello ke ci devi fare..
per stringhe e accesso ai file preferisco python, per programmazione di rete preferisco ruby

Mumble mumble: eppure Python ha un'ottima dotazione (nella libreria standard) anche per questo campo.

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

Perchè in java non si utilizzano?
java.util.List e java.util.Map cosa sono?

Non sono semplici e versatili come gli equivalenti di Python, e devi ricorrere alla libreria standard per usarli.

[PGI-Bis]

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?

D'accordo ma... perchè? Lo chiedo non per pedanteria ma per vero interesse. Dici che è meglio essere concisi a patto di essere chiari. Dunque c'è un limite alla sintesi? Se c'è quale sarebbe e perchè dovrebbe esserci?

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.

Non ho mai negato che Python richiedesse meno codice per produrre lo stesso risultato. Anzi, credo di averlo dato per scontato, sulla fiducia. Dico invece che la maggior parte della sintassi di Java è già presente nell'Hello World e si tratta di una parte necessaria e sufficiente a creare sistemi articolati, nel senso di composti da una pluralità di definizioni. Dico che questo è vantaggioso perchè costringe ad apprendere sin dal primo istante delle forme sintattiche che costituiranno la norma in tutto il resto del percorso formativo sia in Java (classe, metodo) sia nell'orientamento agli oggetti (la classe Java è il mezzo attraverso cui si esprime una definizione). L'hello world di Python usa qualcosa di cui è ignota la natura e la struttura. "print" potrebbe benissimo essere il nome di un operatore elementare su un registro di memoria: "chi è che" print? Potrebbe essere il nome di un comportamento di "hello world"? E' così? "print" è un messaggio di [string]?

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

Stroustrup presentò la sua idea di orientamento agli oggetti nel classico "what is object orientation", pienamente realizzata in C++ se non altro a testimoniare il fatto che egli non soffrisse all'epoca di personalità multipla. Non è l'unica idea di orientamento agli oggetti esistente. Basta una rapida occhiata a The Early History of Smalltalk, di Alan Kay, o Object Oriented Programming in The BETA programming language, di K. Nygaard, per vederne le differenze. Ricordo, brevemente, che la differenza tra l'ederitarietà scandinava e l'ereditarietà americana sta in ciò che per la prima è ereditabile esclusivamente la dichiarazione mentre per la seconda è lo è anche la definizione. Java è "scandinavo" nel momento in cui le interfacce consentono unicamemente il trasferimento dell'insieme di dichiarazioni che formano il contratto (pubblico) espresso nell'interfaccia ereditata ed è "americano" rispetto all'ereditarietà tra classi, con l'intermezzo "bastardo" delle classi astratte.

La ragione per cui Java non possiede l'estensibilità multipla è piuttosto banale: non hanno voluto introdurre una regola in più per decidere quale tra due definizioni superiori avrebbe dovuto essere ereditata dalla definizione inferiore. Essendo le interfacce prive di definizione il problema non si pone (in accordo all'ereditarietà scandinava).

Predicare che la portabilità di Java sia un falso mito significa avere in mano le carte per poterlo dimostrare. Specifiche alla mano, quali norme del linguaggio di programmazione Java ne limiterebbero la portabilità? Ripetere per la Java Virtual Machine. Intendiamo[ci], è possibilissimo che non lo sia e con la massima umiltà chiedo: perchè? Immagino che neppure qui otterrò risposta.

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.

Thinking in Java è un pessimo libro sull'orientamento agli oggetti ed un'orrenda opera sul linguaggio di programmazione Java. La ragione per cui io non scrivo un libro sull'orientamento agli oggetti è che non ho ancora pienamente preso posizione circa un bivio che la prospettiva orientata agli oggetti propone quasi immediatamente, vale a dire se la dipendenza di definizione sia una relazione univoca o biunivoca. Per non sembrare più oscuro del necessario ripeto qui quanto affermai in un'altra discussione: la definizione di oggetto nella prospettiva orientata agli oggetti è "definizione autonoma di una porzione di un universo reale o immaginario" dove "autonoma" è quella definizione che non ne assuma altre come parte di sè. Arrivo a questa definizione partendo da un ipotetico punto di vista umano nella rappresentazione dei fenomeni che c'entra con la programmazione essendo quest'ultima l'attività di rappresentazione della soluzione di un problema in una forma riproducibile attraverso un calcolatore. E mi fermo qui per evitare di scrivere il libro che non posso (ancora) scrivere.

[^TiGeRShArK^]

Originariamente inviato da cdimauro

Mumble mumble: eppure Python ha un'ottima dotazione (nella libreria standard) anche per questo campo.

tranquillo che l'ho provato python per quello che mi serviva..
ma ho risolto prima con ruby
questa può significare due cose:
a) ruby era migliore di python per quello che mi serviva
b) la documentazione di ruby migliore di quella di python e sono riuscito a scrivere quello che mi serviva con uno sforzo minore
Probabilmente la risposta corretta è la seconda..
ma ammetto che questo non è che va proprio a favore di python

P.S. Hai visto il thread della cena dei siciliani in piazzetta?
magari dopo il nubifragio dell'anno scorso a milano potremmo riuscire finalmente ad incontrarci visto che ritorno definitivamente a RC

[cdimauro]

Originariamente inviato da PGI-Bis

D'accordo ma... perchè? Lo chiedo non per pedanteria ma per vero interesse. Dici che è meglio essere concisi a patto di essere chiari. Dunque c'è un limite alla sintesi? Se c'è quale sarebbe e perchè dovrebbe esserci?

a = {'Qui': 1, 'Quo': 2, 'Qua' : 3}

Esprime un concetto ben preciso, in maniera chiara e compatta.
Prova a tradurre lo stesso concetto in un altro linguaggio: Java, SmallTalk, e perfino in assembly / linguaggio macchina.

Cos'è cambiato? La forma, perché il concetto è rimasto esattamente lo stesso.

Qual è la differenza rispetto al codice di cui sopra? Che per esprimere la stessa cosa sono state richieste diverse linee di codice (in particolare con assembly / linguaggio macchina il listato sarebbe piuttosto lungo) che portano a:
- maggior possibilità di bug;
- dispersività nella rappresentazione e comprensione del concetto.

Se vuoi una definizione formale di quello che ho detto non te la posso dare, perché sai bene che nel campo della programmazione si va spesso per esperienza / "best practices". Un po' come quando si afferma che la programmazione orientata è una "cosa buona e giusta".

Non ho mai negato che Python richiedesse meno codice per produrre lo stesso risultato. Anzi, credo di averlo dato per scontato, sulla fiducia. Dico invece che la maggior parte della sintassi di Java è già presente nell'Hello World e si tratta di una parte necessaria e sufficiente a creare sistemi articolati, nel senso di composti da una pluralità di definizioni. Dico che questo è vantaggioso perchè costringe ad apprendere sin dal primo istante delle forme sintattiche che costituiranno la norma in tutto il resto del percorso formativo sia in Java (classe, metodo) sia nell'orientamento agli oggetti (la classe Java è il mezzo attraverso cui si esprime una definizione).

Opinabile. Io preferisco iniziare dai mattoncini basilari per poi arrivare a quelli più complessi, anziché trovarmi di botto un bel po' di nuovi concetti e sentirmi dire: "per adesso devi fare così, perché queste cose poi le affronteremo più avanti".

L'hello world di Python usa qualcosa di cui è ignota la natura e la struttura. "print" potrebbe benissimo essere il nome di un operatore elementare su un registro di memoria: "chi è che" print? Potrebbe essere il nome di un comportamento di "hello world"? E' così? "print" è un messaggio di [string]?

E' un'istruzione, al pari di if, while, for, ecc. che non sono riconducibili a nessun "operatore elementare" o "messaggio" attribuibile a qualche oggetto. Dunque la sua presenza e il suo utilizzo mi sembrano del tutto leciti.

Comunque a partire da Python 3.0 diventerà una funzione come le altre built-in che offre il linguaggio, perché ci sono dei vantaggi non indifferenti nell'averla definita come tale (c'è un documento scritto da Guido van Rossum in proposito che espone le motivazioni).
Questo per sottolineare che, a differenza di linguaggi come Java, la comunità Python non si fa problemi a rompere la compatibilità col passato pur di avere a disposizione un linguaggio che rispecchia una precisa "filosofia".

Stroustrup presentò la sua idea di orientamento agli oggetti nel classico "what is object orientation", pienamente realizzata in C++ se non altro a testimoniare il fatto che egli non soffrisse all'epoca di personalità multipla. Non è l'unica idea di orientamento agli oggetti esistente. Basta una rapida occhiata a The Early History of Smalltalk, di Alan Kay, o Object Oriented Programming in The BETA programming language, di K. Nygaard, per vederne le differenze. Ricordo, brevemente, che la differenza tra l'ederitarietà scandinava e l'ereditarietà americana sta in ciò che per la prima è ereditabile esclusivamente la dichiarazione mentre per la seconda è lo è anche la definizione. Java è "scandinavo" nel momento in cui le interfacce consentono unicamemente il trasferimento dell'insieme di dichiarazioni che formano il contratto (pubblico) espresso nell'interfaccia ereditata ed è "americano" rispetto all'ereditarietà tra classi, con l'intermezzo "bastardo" delle classi astratte.

La ragione per cui Java non possiede l'estensibilità multipla è piuttosto banale: non hanno voluto introdurre una regola in più per decidere quale tra due definizioni superiori avrebbe dovuto essere ereditata dalla definizione inferiore. Essendo le interfacce prive di definizione il problema non si pone (in accordo all'ereditarietà scandinava).

Al di là del fatto che è evidente che non esiste un solo modo di definire cosa sia la programmazione a oggetti, secondo te è un bene o un male il fatto che Java non abbia abbracciato l'ereditarietà multipla?

Concordi, poi, che l'approccio "tradizionale" alla modellazione della realtà facendo uso di oggetti si è rivelato fallimentare?

Predicare che la portabilità di Java sia un falso mito significa avere in mano le carte per poterlo dimostrare. Specifiche alla mano, quali norme del linguaggio di programmazione Java ne limiterebbero la portabilità?

Nessuna.

Ripetere per la Java Virtual Machine. Intendiamo[ci], è possibilissimo che non lo sia e con la massima umiltà chiedo: perchè? Immagino che neppure qui otterrò risposta.

Questa http://java.sun.com/docs/books/tutor...een/index.html quando ho lavorato a Diamonds funzionava soltanto con Windows. Su Linux non andava, e non perché mancasse adeguata accelerazione video.

A parte questo, le implementazioni per Windows x64 non sono complete: mancano delle librerie / funzionalità, e ciò mi ha costretto a dover installare sempre la versione a 32 bit.
Non so se la situazione sia cambiata dall'ultima volta che ho controllato.

Thinking in Java è un pessimo libro sull'orientamento agli oggetti ed un'orrenda opera sul linguaggio di programmazione Java.

Esiste qualche altra opera meritevole?

La ragione per cui io non scrivo un libro sull'orientamento agli oggetti è che non ho ancora pienamente preso posizione circa un bivio che la prospettiva orientata agli oggetti propone quasi immediatamente, vale a dire se la dipendenza di definizione sia una relazione univoca o biunivoca. Per non sembrare più oscuro del necessario ripeto qui quanto affermai in un'altra discussione: la definizione di oggetto nella prospettiva orientata agli oggetti è "definizione autonoma di una porzione di un universo reale o immaginario" dove "autonoma" è quella definizione che non ne assuma altre come parte di sè. Arrivo a questa definizione partendo da un ipotetico punto di vista umano nella rappresentazione dei fenomeni che c'entra con la programmazione essendo quest'ultima l'attività di rappresentazione della soluzione di un problema in una forma riproducibile attraverso un calcolatore. E mi fermo qui per evitare di scrivere il libro che non posso (ancora) scrivere.

Scusa l'ignoranza, ma non ho colto il significato della "dipendenza di definizione".

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

tranquillo che l'ho provato python per quello che mi serviva..

Immagino.

ma ho risolto prima con ruby
questa può significare due cose:
a) ruby era migliore di python per quello che mi serviva
b) la documentazione di ruby migliore di quella di python e sono riuscito a scrivere quello che mi serviva con uno sforzo minore
Probabilmente la risposta corretta è la seconda..
ma ammetto che questo non è che va proprio a favore di python

Non so che dire. Con Python ho avuto la necessità di lavorare soltanto con HTTP/HTTPs, FTP/sFTP, parsing di pagine HTML e di XML, e mi sono sbrigato molto in fretta.

P.S. Hai visto il thread della cena dei siciliani in piazzetta?
magari dopo il nubifragio dell'anno scorso a milano potremmo riuscire finalmente ad incontrarci visto che ritorno definitivamente a RC

Non seguo la piazzetta; al più leggo qualche pagina di cui viene postato il link nel dark side. Comunque vado a buttarci un occhio.

Quando scendi mi farebbe piacere incontrarci, visto che è da un pezzo che rimandiamo.

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

cmq tornando serio per un attimo.. (in effetti sto facendo uno sforzo incommensurabile x essere serio )
Secondo me vale sempre il classico (appena citato tra l'altro ) "The right tool for the right job"
Per progetti di dimensioni medio-grandi (x la mia esperienze e x come vedo io i progetti medio grandi... ovvero sopra le 100k LOC) Java è meglio di python xkè già in compilazione evita di fare cazzate assurde con i tipi,

Beh, c'è da dire intanto che 100mila righe di codice in Python e in Java non sono proprio la stessa cosa , comunque sui tipi è vero che si possono introdurre degli errori a causa della mancanza del controllo statico, ma è anche vero che aumentano enormemente la produttività e la possibilità di avere in tempi brevi un modello che consente di effettuare dei test con dati reali (o creati ad arte) e di individuare velocemente anche eventuali bug introdotti dal "weak typing" di Python.

In ogni caso non vedo problemi a gestire progetti anche con più di 100mila righe di codice in Python. Anzi, il fatto di avere codice compatto e chiaro per me lo pone in un netto vantaggio proprio per questioni di manutenibilità.

xkè alla fine costringe a strutturare il progetto in una maniera ben ordinata (sopratutto usando tools come maven),

Non lo conosco. Per la struttura del progetto, la modularizzazione del codice offerta da Python permette di costruire una gerarchia in maniera molto simile a Java.

xkè lo stile del codice può anche risultare migliore di quello di python usando gli strumenti giusti (ricordate il caro vecchio checkstyle che tanto mi ha fatto bestemmiare, vero? )

Appunto: ha fatto bestemmiare e non poco. Quanto allo stile del codice, preferisco decidere da me: non mi trovo assolutamente nel dover definire le classi con la prima maiuscola e le istanze (e i metodi) con la minuscola invece; è una forzatura che non condivido.

e sopratttto xkè alla fine x il supporto, la documentazione e l'aiuto disponibile alla comunità Java, soprattutto nel caso di bug critici in produzione non ha eguali confrontata con la comunità di python (sempre x quel poco che ho potuto vedere durante la mia esperienza ).

Posso assicurarti che la comunità Python è mooooolto attiva e disponibile.

Sulla documentazione, non sarà ottima come quella di Java, ma almeno non è incasinata e dispersiva.

Però, sempre per quello che ho vissuto finora, non avrei alcuna esitazione a consiglire python come linguaggio per iniziare a programmare...
Imho più un linguaggio è ad alto livello e + permette al programmatore di concentrarsi sugli algoritmi.
E alla fine, parlandoci chiaro, sono quelli la vera parte essenziale della programmazione.
Oltre alla forma mentis ovviamente
Un linguaggio che permette di concentrarsi sui concetti + che sulle righe di codice "inutili" permette di imparare meglio le cose necessarie.

Perfettamente d'accordo, ed è quello che ribadiamo da un pezzo.

L'unica pecca davvero grave che trovo in python è la mancanza di una documentazione adeguata
Cioè, a parte gli ottimi manuali utilizzati per apprendere le basi del linguaggio, poi ci si deve smenare davvero troppo per capire come funziona una maledetta libreria.
E a quel punto, sinceramente, preferisco scrivere + codice in java, mettendoci + tempo, ma impiegando sicuramente meno che per cercare di capire che cacchio voleva fare l'autore di quella libreria con la documentazione criptica

Parli della libreria standard o di quelle "esterne"?

Concludendo...
il percorso ideale per me x iniziare sarebbe il seguente:
Python (o ruby o qualcosa di equivalente) --> Java --> all the rest

Io mi fermo a Python.

[cdimauro]

Originariamente inviato da k0nt3

non sono daccordo sul fatto che più è alto il livello e meglio è.. anche in questo caso le motivazioni sono fragili.

E' da un pezzo che ne parliamo, ma non porti delle argomentazioni. Dicendo che sono fragili non hai portato nessun contributo alla discussione.

i linguaggi come java, python ecc.. permettono di fare in maniera molto più semplice cose abbastanza complesse da fare in linguaggi come C e pascal per esempio.

Bene, ti sei risposto da solo alle obiezioni di cui sopra.

ma quando uno inizia a programmare tipicamente i suoi programmi fanno cose abbastanza stupide come calcolare le soluzioni di un'equazione di secondo grado, calcolare l'ipotenusa dati i due cateti, classificare i triangoli, implementare nibbles ecc..
da questo punto di vista C e pascal sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi e non sul colore della finestra, la disposizione dei pulsanti e altre inutilità varie. invece linguaggi come python e java ti sbattono in faccia sin dall'inizio concetti più avanzati come gli oggetti, le eccezioni ecc.. ovviamente IMHO

Ancora una volta dimostri di non aver capito nulla di Python.

Parli di "concetti più avanzati" quando le cose che hai descritto con Python le risolvi in maniera MOOOOLTO più semplice rispetto a C e Pascal, e te lo posso dimostrare quando voglio.

Mi chiedo quando imparerai a parlare soltanto di cose che conosci veramente.

[k0nt3]

dimostralo pure allora.
io ho detto che le argomentazioni sono fragili in entrambi i sensi (perlomeno intendevo dire), quindi non sono daccordo con chi dice che più è alto il livello e meglio è