continuazione da "imparare a programmare"

[^TiGeRShArK^]

Originariamente inviato da DioBrando

A me sembra che in queste discussioni stia un po' sfuggendo il quadro di insieme.
Ed il quadro di insieme ci dice che Java è diventato obsoleto e superato in diversi campi applicativi.

ma anche no
Ad oggi la diffusione di java in ambito enterprise non ha eguali.
E non dimentichiamo la nuova linfa vitale fornita dalla grandissima base di utilizzatori, tra cui ad esempio il Google Web Toolkit, usato per applicativi quali Google Maps e che è anche capace di girare in modalità offline risolvendo così uno dei + annosi problemi di AJAX.
Quindi sinceramente tanto superato non mi pare

Negli anni 90, soprattutto la prima metà, è stato direi rivoluzionario con i suoi concetti, nella capacità di Sun di scorgere le potenzialità del World Wide Web prima degli altri e di approfittare del suo boom per veicolare la piattaforma Java nella quasi totalità dei computer (desktop) in giro per il mondo.

e ad oggi mi pare sinceramente MOLTO + probabile che su un comune pc sia installata una Java VM piuttosto che python o ruby

Si sono talmente seduti, che mentre nuovi linguaggi e metodologie di sviluppo prendevano piede (.NET, PHP, Python, Ruby...), il modello di Java e la sua architettura sono rimaste fondamentalmente sempre quelle, da quando Gosling e soci pubblicarono le prime specifiche.

Java e .Net si sono "scambiati" + volte caratteristiche e credo che continuino a farlo in futuro.
Ognuno cerca di prendere il meglio dal competitor e penso che salti subito agli occhi la grande similarità tra Java e C#

E ora il ritardo tecnologico accumulato è evidente. Talmente evidente che negli ultimi mesi, dopo anni di silenzio, abbiamo assistito alla presentazione di
- la convergenza verso l'Open Source
- JAX-WS 2.0, JAXB 2.0, JAXP e STAX (tutte specifiche volte a colmare le "lacune" in ambito AJAX)
- JavaFX: linguaggio di scripting server-side
- Quaere, l'alter-ego di LinQ (progetto NET che ha ormai quasi 3 anni), che quindi dovrebbe permettere la modellazione OO di accesso ad una base di dati

JavaFX è client side e le migliorie maggiori applicate ai web services secondo me sono state quelle fornite tramite le anotations
E quindi non vedo cosa ci sia di male a migliorare il linguaggio

Cominciamo per esempio dalla (annosa) questione dell'ereditarietà multipla.
CUT

io personalmente preferisco molto di + le interfacce all'ereditarietà mutipla

L'hype spropositato che si è generato in questi anni e che ha dato vita a falsi miti ( del calibro de "Java è portabile", "Java è multipiattaforma", "Java ha rimosso i difetti di C++ e quindi è virtualmente immune da difetti", oppure "la decadenza prestazionale, seppur sia un linguaggio interpretato, è ininfluente, rispetto ai benefici"), è scemato e gli sviluppatori, sia freelance che in seno alle aziende, hanno fatto scelte oculate che tenessero conto del rapporto costi/benefici, nel caso di un utilizzo della piattaforma Java.

bhè...
che Java sia portabile, multipiattaforma e che abbia rimosso diversi difetti del C++ credo sia innegabile.
Come è altrettanto innegabile che con l'avvento del JIT e l'abbandono definitivo dell'interprete della VM le prestazioni sono molto + vicine al C++ di quanto si pensi e cmq sono senz'altro molto superiori a python/ruby, SOPRATTUTTO quando si ha a che fare con i multi-core, che checchè se ne dica si stanno diffondendo moltissimo viste le varie riduzioni di prezzo di AMD e INTEL (e cmq parlando di applicazioni di una certa grandezza ovviamente).

(come appunto l'estensione di funzionalità tramite la semplice aggiunta di nuove librerie, per esempio nel caso dei dizionari)

Sono nel framework sin da java 1.2.
E x me java prima di quella versione non era propriamente ben fornito degli strumenti giusti.
E cmq non vedo il punto dato che anche in python sono state introdotte innumerevoli possibilità passando da una release alla successiva.
è la naturale evoluzione dei linguaggi e non mi pare proprio una cosa negativa.

[cdimauro]

Originariamente inviato da k0nt3

dimostralo pure allora.

Certamente. Ecco qua:

print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"
a = float(raw_input('Inserire il coefficiente a: '))
b = float(raw_input('Inserire il coefficiente b: '))
c = float(raw_input('Inserire il coefficiente c: '))
Delta = b ** 2 - 4 * a * c
RadiceDiDelta = complex(Delta) ** 0.5 
x1 = (-b + RadiceDiDelta) / (2 * a)
x2 = (-b - RadiceDiDelta) / (2 * a)
print "Le soluzioni dell'equazione sono", x1, 'e', x2

il programmino per la risoluzione di un'equazione di secondo grado (poi possiamo passare anche agli altri esempi che hai fatto: io sono a disposizione).

Adesso fammi vedere come lo faresti in C o in Pascal, visto che sostenevi che "sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi".

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 è

Continui a parlare di "fragilità", ma a non portare niente come argomentazione. Aria fritta insomma.

Vatti a rileggere tutto quello che abbiamo scritto e, se hai qualcosa da dire, quota e contesta pure.

[^TiGeRShArK^]

Originariamente inviato da mad_hhatter

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

se la documentazione è sufficientemente buona e si è appresa a dovere la programmazione ad oggetti allora si, dovrebbe essere semplice e immediato.
O almeno x me di solito è così.
Certo tra l'iniziare a programmare in un linguaggio e saperlo usare al meglio ce ne passa, ma quantomeno le basi dovrebbero essere di immediata comprensione.

[k0nt3]

Originariamente inviato da cdimauro

Certamente. Ecco qua:

print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"
a = float(raw_input('Inserire il coefficiente a: '))
b = float(raw_input('Inserire il coefficiente b: '))
c = float(raw_input('Inserire il coefficiente c: '))
Delta = b ** 2 - 4 * a * c
RadiceDiDelta = complex(Delta) ** 0.5 
x1 = (-b + RadiceDiDelta) / (2 * a)
x2 = (-b - RadiceDiDelta) / (2 * a)
print "Le soluzioni dell'equazione sono", x1, 'e', x2

il programmino per la risoluzione di un'equazione di secondo grado (poi possiamo passare anche agli altri esempi che hai fatto: io sono a disposizione).

non gestisci la divisione per 0 e poi sono sufficienti le radici reali nel caso di delta minore di 0 (anche se non lo avevo specificato era sottointeso). tipicamente infatti è un esempio utile per via del fatto che si imparano a usare le condizioni (se il delta è minore ecc..)
per il resto niente da dire a parte che raw_input come dice il termine stesso è grezzo

Originariamente inviato da cdimauro

Adesso fammi vedere come lo faresti in C o in Pascal, visto che sostenevi che "sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi".

in C o in pascal scrivi giusto in paio di righe in più, ma la differenza è che dichiari le variabili con il loro tipo e le istruzioni fanno una cosa alla volta (non come raw_input che scrive sullo schermo e prende in input dei caratteri).
per me rimane preferibile il pascal però, perchè con il C bisognerebbe usare già i puntatori. il problema del python è che come tu stesso hai detto tutto è un oggetto, solo che questo non è visibile al programmatore (almeno in un primo momento)

Originariamente inviato da cdimauro

Continui a parlare di "fragilità", ma a non portare niente come argomentazione. Aria fritta insomma.

Vatti a rileggere tutto quello che abbiamo scritto e, se hai qualcosa da dire, quota e contesta pure.

qua è tutta aria fritta dalla prima all'ultima pagina, solo voi non l'avete capito

[mad_hhatter]

Originariamente inviato da ^TiGeRShArK^

se la documentazione è sufficientemente buona e si è appresa a dovere la programmazione ad oggetti allora si, dovrebbe essere semplice e immediato.
O almeno x me di solito è così.
Certo tra l'iniziare a programmare in un linguaggio e saperlo usare al meglio ce ne passa, ma quantomeno le basi dovrebbero essere di immediata comprensione.

perfettamente d'accordo, era quello che intendevo

[cdimauro]

Originariamente inviato da k0nt3

non gestisci la divisione per 0

Dalle mie parti un'equazione di secondo grado non può avere il coefficiente pari a 0.

e poi sono sufficienti le radici reali nel caso di delta minore di 0 (anche se non lo avevo specificato era sottointeso).

Le radici reali ci sono soltanto se il delta è maggiore o uguale a 0.

Quelle complesse sono ugualmente le radici dell'equazione.

tipicamente infatti è un esempio utile per via del fatto che si imparano a usare le condizioni (se il delta è minore ecc..)

Le condizioni s'imparano a usare subito? Non mi pare.

Quello che ho postato è una soluzione perfettamente valida al problema:

"Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"

com'era chiaramente attestato nella prima riga del codice.

Non c'erano altri vincoli, se non che l'equazione dev'essere di secondo grado.

Quindi le soluzioni complesse erano incluse, visto che sono soluzioni dell'equazione; non era specificato da nessuna parte che avrei dovuto estrarre soltanto quelle reali.

per il resto niente da dire a parte che raw_input come dice il termine stesso è grezzo

scanf invece è di una chiarezza estrema, vero?

Comunque sempre per la tua gioia raw_input() diventerà input() in Python 3.0 (sempre se non ricordo male).

Prova a chiedere al comitato dell'ANSI C se cambiano scanf() in inputf() o simile...

in C o in pascal scrivi giusto in paio di righe in più, ma la differenza è che dichiari le variabili con il loro tipo e le istruzioni fanno una cosa alla volta (non come raw_input che scrive sullo schermo e prende in input dei caratteri).

Non ci sarebbe soltanto quella differenza. Prova a realizzare l'equivalente del programma che ho postato, in C e Pascal, e poi ne riparliamo...

per me rimane preferibile il pascal però, perchè con il C bisognerebbe usare già i puntatori.

Ah, adesso rottamiamo pure il C, che era fra quelli "migliori" per risolvere questo tipo di problema. Vabbé...

il problema del python è che come tu stesso hai detto tutto è un oggetto, solo che questo non è visibile al programmatore (almeno in un primo momento)

Ti ho già spiegato cosa significa "paradigma di programmazione" applicato a Python, diversi messaggi fa.

qua è tutta aria fritta dalla prima all'ultima pagina, solo voi non l'avete capito

Dimostralo: comincia a quotare le parti che sarebbero aria fritta, confutandole.

[^TiGeRShArK^]

Originariamente inviato da k0nt3

non gestisci la divisione per 0 e poi sono sufficienti le radici reali nel caso di delta minore di 0 (anche se non lo avevo specificato era sottointeso). tipicamente infatti è un esempio utile per via del fatto che si imparano a usare le condizioni (se il delta è minore ecc..)
per il resto niente da dire a parte che raw_input come dice il termine stesso è grezzo

ehmm..
veramente non ci sono divisioni per zero se l'equazione è nella forma ax^2 + bx + c

qua è tutta aria fritta dalla prima all'ultima pagina, solo voi non l'avete capito

perchè aria fritta?
in C ti saresti fatto 2 palle così a scrivere quel codice...
o no?

[cdimauro]

No, perché C e Pascal "sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi".

[k0nt3]

Originariamente inviato da ^TiGeRShArK^

ehmm..
veramente non ci sono divisioni per zero se l'equazione è nella forma ax^2 + bx + c

perchè aria fritta?
in C ti saresti fatto 2 palle così a scrivere quel codice...
o no?

niente vieta di assegnare il valore 0 al coefficiente a, perciò la divisione per zero ci può essere.
è aria fritta perchè l'ho già spiegato che la scelta del linguaggio con cui iniziare non è una cosa oggettiva. inoltre anche volendo non si può fare un confronto tra linguaggi perchè non ci è dato sapere quali caratteristiche sono bene e quali sono male, e nel caso quanto bene e quanto male. ogni linguaggio è un opportuno compromesso di caratteristiche ed è inevitabile visto che molte caratteristiche sono in contrasto fra loro.

ecco le due palle che mi sono fatto

#include <stdio.h>
#include <math.h>

int main()
{
    float a, b, c;
    float delta;

    printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\n");
    printf("inserire il coefficiente a: ");
    scanf("%f", &a);
    printf("inserire il coefficiente b: ");
    scanf("%f", &b);
    printf("inserire il coefficiente c: ");
    scanf("%f", &c);

    delta = b*b-4*a*c;

    if(delta < 0)
    {
        printf("l'equazione non ha soluzioni reali");
    }
    else if(delta == 0)
    {
        float x = -b/(2*a);
        printf("l'equazione ha un'unica soluzione reale: %f", x);
    }
    else
    {
        float x1 = (-b-sqrt(delta))/(2*a);
        float x2 = (-b+sqrt(delta))/(2*a);
        printf("l'equazione ha due soluzioni reali: %f e %f", x1, x2);
    }

    return 0;
}

un programmatore sta cosa se la mangia a colazione più righe ma il risultato è diverso, anche perchè imparare a programmare non è fare la gara a chi scrive meno righe. altrimenti avrei fatto così (vi risparmio la soluzione su una riga ):

#include <stdio.h>
#include <math.h>

int main()
{
    float a, b, c;
    printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\ninserire il coefficiente a: ");
    scanf("%f", &a);
    printf("inserire il coefficiente b: ");
    scanf("%f", &b);
    printf("inserire il coefficiente c: ");
    scanf("%f", &c);
    printf("le soluzioni sono: %f e %f", (-b-sqrt(b*b-4*a*c))/(2*a), (-b+sqrt(b*b-4*a*c))/(2*a));
}

a voi sembra difficile?
il pascal è preferibile per il solo fatto di non richiedere l'uso del puntatore, ma sono dettagli

[PGI-Bis]

Originariamente inviato da cdimauro

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

Esprime un concetto ben preciso, in maniera chiara e compatta.

Togliamo "ben preciso", "in maniera chiara" e "compatta" perchè non vuol dir nulla. Resta "esprime un concetto". E questo non lo revoco in dubbio.

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.

Io la vedo un pelo diversa. In assembly cambia la prospettiva, in Smalltalk è identico, in Java, per fortuna, manca una sintassi speciale e si interviene a colpi di invocazioni di metodo su un oggetto.

Qual è la differenza rispetto al codice di cui sopra? Che per esprimere la stessa cosa

Altro è l'effetto di quella parte del programma altro è ciò che è necessario comunicare per ottenerlo.

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;

La quantità di codice non è direttamente correlata alla quantità di bug. E posso anche provare a convincertene. Scrivi per cento volte

print "hello world"

Quanti bug ci sono in quelle cento linee? Induttivamente, se ti chiedessi di scriverlo centomila volte quanti errori commetteresti? Io dico zero. La quantità di codice è di per sè irrilevante.

- 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".

Io non voglio una definizione formale nè voglio una ragione ottenuta citando Tizio o Caio. Io chiedo le tue ragioni. Perchè, secondo te, meno è meglio. Voglio sapere quando la rappresentazione di un concetto si può dire "dispersiva" e quando no, quando è dispersiva la comprensione, cosa è un concetto... per te.

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".

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.

Non dovrebbero apparirti leciti tanto quanto non lo appaiono a me in Java. Se prendi Smalltalk, anche i se e i ma sono messaggi da inviare ad oggetti.

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".

Io lo vedo come un punto a sfavore.

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?

Java dispone di ereditarietà multipla ed estensione singola. Io avrei preferito che, per chiarezza, le classi fossero state evitate in favore della possibilità di dichiarare un oggetto, a mo' di singleton, come in scala. Basti pensare all'imbarazzo in cui si trova chi debba rispondere alla domanda "ma che differenza c'è tra un'interfaccia ed una classe totalmente astratta"? La risposta è nessuna: è un punto in cui due strumenti del linguaggio si sovrappongono.

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

No. L'approccio tradizionale all'orientamento agli oggetti è quello, per intenderci, di Design Pattern: solo un'altra prospettiva da applicare ai fenomeni perchè... diavolo non si sa perchè. Che questa sia la tesi tutt'oggi dominante è chiaro sol che si leggano i capitoli relativi all'orientamento agli oggetti dei molti libri che trattano di programmazione. Sai che non è la tesi a cui io aderisco. Io perseguo l'ideale della prospettiva orientata agli oggetti come applicazione del punto di vista di un qualsiasi essere umano alla realtà e dico che questo approccio è superiore perchè risparmia una trasformazione di prospettiva - da come io vedo le cose a come devo vederle per poter scrivere un programma. E' una superiorità logica, incontrovertibile. Col grande problema dell'incertezza sugli esatti contorni del modo umano di vedere le cose.

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.

E' un problema che mi incuriosisce perchè per ogni funzione "nativa" le librerie Java forniscono anche un meccanismo per determinare la presenza del supporto. Oso dire che un codice Java correttamente scritto non dovrebbe incontrare problemi nella gestione del caso "modalità fullscreen non disponibile". Si tratta in ogni caso di una questione di librerie e non di lingua o tecnologia, altrimenti basterebbe citare Java3D per ridurre l'alveo dei sistemi operativi supportati ad una manciata.

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.

Questo è un problema di risorse necessarie allo sviluppo di una versione della piattaforma Java. Ma se qualcuno dichiara mitologica la portabilità di Java il minimo che si può pretendere prima di stendersi ai piedi del blaterante di turno è che dichiari cosa impedirebbe l'esistenza di una piattaforma Java su sistemi diversi da quelli esistenti. Non mi pare eccessiva come pretesa.

Esiste qualche altra opera meritevole?

Sull'orientamento agli oggetti quello che io preferisco è Object Oriented Programming in The BETA programming language, con particolare riferimento al capitolo sul "conceptual framework". Sul linguaggio di programmazione Java non vedo alternative a The Java Programming Language, di Gosling e altri. Mi acchiappa anche l'ultimo Java - Mattone dopo mattone.

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

Devi aver rimosso. Tipo un trauma . Ne avevamo già parlato. Ricordi quella faccenda del "ma che diavolo è un oggetto? Un oggetto è una definizione autonoma, la definizione di un oggetto può richiedere altre definizioni, in tal caso oggetto sarà l'unione di tutte le definizioni richieste più la definizione richiedente eccetera eccetera... Ti sovviene alla memoria?

[PGI-Bis]

Originariamente inviato da cdimauro

con le argomentazioni che abbiamo fornito

Eridaje. Se qui qualcuno ha fornito argomentazioni vi assicuro che a me sono sfuggite. Quanto a Eckel, sul dizionario alla voce "argomentazione" mi risulta sotto "contrari".

[cdimauro]

Originariamente inviato da k0nt3

niente vieta di assegnare il valore 0 al coefficiente a, perciò la divisione per zero ci può essere.

Lo vieta la matematica: non si parlerebbe di equazioni di secondo grado, altrimenti. Nel programma è specificato a chiare lettere, e non mi risulta che esistano equazioni di secondo grado con coefficiente "a" pari a zero.

è aria fritta perchè l'ho già spiegato che la scelta del linguaggio con cui iniziare non è una cosa oggettiva.

A giudicare dai numerosi esempi che abbiamo tirato fuori finora, sembrerebbe che sia importante, invece.

Comunque su questo avevamo già parlato (anche con te, che però hai preferito abbandonare velocemente questo ramo della discussione) e avevo anche suggerito di utilizzare il linguaggio macchina dell'Itanium di Intel per il paradigma imperativo, Lisp per quello funzionale e Perl per quello a oggetti.

Sei d'accordo che è tranquillamente possibile utilizzare questi linguaggi per iniziare con quei paradigmi?

inoltre anche volendo non si può fare un confronto tra linguaggi perchè non ci è dato sapere quali caratteristiche sono bene e quali sono male, e nel caso quanto bene e quanto male.

Non ti capisco: sii più chiaro, cortesemente.

ogni linguaggio è un opportuno compromesso di caratteristiche ed è inevitabile visto che molte caratteristiche sono in contrasto fra loro.

Sei sempre più difficile da capire.

ecco le due palle che mi sono fatto

#include <stdio.h>
#include <math.h>

int main()
{
    float a, b, c;
    float delta;

    printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\n");
    printf("inserire il coefficiente a: ");
    scanf("%f", &a);
    printf("inserire il coefficiente b: ");
    scanf("%f", &b);
    printf("inserire il coefficiente c: ");
    scanf("%f", &c);

    delta = b*b-4*a*c;

    if(delta < 0)
    {
        printf("l'equazione non ha soluzioni reali");
    }
    else if(delta == 0)
    {
        float x = -b/(2*a);
        printf("l'equazione ha un'unica soluzione reale: %f", x);
    }
    else
    {
        float x1 = (-b-sqrt(delta))/(2*a);
        float x2 = (-b+sqrt(delta))/(2*a);
        printf("l'equazione ha due soluzioni reali: %f e %f", x1, x2);
    }

    return 0;
}

un programmatore sta cosa se la mangia a colazione più righe ma il risultato è diverso,

Infatti il risultato non è affatto lo stesso: ti sei mangiato le radici complesse e coniugate, che sono possibili soluzioni di un'equazione di secondo grado, al pari delle altre.

Da notare, comunque, che hai dovuto aggiungere degli #include per poter utilizzare alcune funzioni di libreria, e col significato tutt'altro che semplice da apprendere. Questo per dovere di cronaca.

anche perchè imparare a programmare non è fare la gara a chi scrive meno righe. altrimenti avrei fatto così (vi risparmio la soluzione su una riga ):

#include <stdio.h>
#include <math.h>

int main()
{
    float a, b, c;
    printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\ninserire il coefficiente a: ");
    scanf("%f", &a);
    printf("inserire il coefficiente b: ");
    scanf("%f", &b);
    printf("inserire il coefficiente c: ");
    scanf("%f", &c);
    printf("le soluzioni sono: %f e %f", (-b-sqrt(b*b-4*a*c))/(2*a), (-b+sqrt(b*b-4*a*c))/(2*a));
}

print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"
a = float(raw_input('Inserire il coefficiente a: '))
b = float(raw_input('Inserire il coefficiente b: '))
c = float(raw_input('Inserire il coefficiente c: '))
print "Le soluzioni dell'equazione sono", (-b + complex(b ** 2 - 4 * a * c) ** 0.5) / (2 * a), 'e', (-b - complex(b ** 2 - 4 * a * c) ** 0.5) / (2 * a)

Cinque righe. E anche su una riga il codice sarebbe comunque inferiore e sempre più leggibile.

a voi sembra difficile?

Rispetto a Python lo è di gran lunga.

il pascal è preferibile per il solo fatto di non richiedere l'uso del puntatore, ma sono dettagli

No, il Pascal è preferibile anche perché non devi ricorrere a nessuna funzione di libreria, e le procedure Write/ln e Readln sono decisamente più leggibili e facile da usare rispetto a printf e scanf.

[cdimauro]

Originariamente inviato da PGI-Bis

Togliamo "ben preciso", "in maniera chiara" e "compatta" perchè non vuol dir nulla. Resta "esprime un concetto". E questo non lo revoco in dubbio.

Va bene.

Io la vedo un pelo diversa. In assembly cambia la prospettiva, in Smalltalk è identico, in Java, per fortuna, manca una sintassi speciale e si interviene a colpi di invocazioni di metodo su un oggetto.

Altro è l'effetto di quella parte del programma altro è ciò che è necessario comunicare per ottenerlo.

Il concetto che è stato espresso è sempre lo stesso: si tratta della definizione di una mappa/dizionario.

La "comunicazione" di quel che si sta facendo, invece, avviene in forme diverse.

La quantità di codice non è direttamente correlata alla quantità di bug. E posso anche provare a convincertene. Scrivi per cento volte

print "hello world"

Quanti bug ci sono in quelle cento linee? Induttivamente, se ti chiedessi di scriverlo centomila volte quanti errori commetteresti? Io dico zero. La quantità di codice è di per sè irrilevante.

Il numero di bug per righe di codice è una metrica molto usata nella valutazione del defect ratio di un'applicazione.

Portare un esempio in cui tale misura è pari a zero nulla toglie alla realtà speriementale, con applicazioni reali, che dipingono un quadro ben diverso (che ho riportato io).

Ti faccio anche presente che applicando lo stesso principio che hai esposto (partire da codice "sicuramente senza bug" e combinarlo ad libidum), induttivamente dovremmo poter costruire un'intera applicazione, complessa quanto si vuole, che in linea teorica dovrebbe essere sempre priva di bug, ma ho il non vago sospetto che qualche rogna prima o poi capiterà.

Io non voglio una definizione formale nè voglio una ragione ottenuta citando Tizio o Caio. Io chiedo le tue ragioni. Perchè, secondo te, meno è meglio. Voglio sapere quando la rappresentazione di un concetto si può dire "dispersiva" e quando no, quando è dispersiva la comprensione, cosa è un concetto... per te.

Per me un concetto è la rappresentazione di qualcosa che ha determinate proprietà. Linguaggi diversi (ma anche programmi diversi) permettono di rappresentarlo utilizzando una diversa quantità di informazione.

Sempre per quanto mi riguarda, rappresentare qualcosa con meno informazioni aiuta nella comprensione del quadro generale in cui sono collocati questi concetti: faccio meno fatica a tenere traccia di ciò che sto facendo.

Il tutto senza rinunciare alla chiarezza e alla leggibilità (in soldoni: roba come whitespace o brainfuck sono da scartare).

Più aumenta la lunghezza del codice, più la rappresentazione e la comprensione di un concetto tendono a disperdersi.
Nuovamente cito il caso dell'assembly: per rappresentare la stessa cosa ho bisogno di molte più istruzioni, e la comprensione di ciò che sto facendo diventa più problematica.
Viceversa, con Perl posso esprimere le stesse cose in maniera molto più compatta, ma a scapito di chiarezza e leggibilità.

Ricapitolando, per quanto mi riguarda il codice dovrebbe essere quanto più compatto, ma senza rinunciare a chiarezza e leggibilità.

Questo è il mio punto di vista. C'è qualcosa che non va in quello che ho scritto?

Non dovrebbero apparirti leciti tanto quanto non lo appaiono a me in Java.

A me appaiono perfettamente leciti: anche in Java esistono delle istruzioni che NON rappresentano scambi di messaggi fra oggetti.

Se prendi Smalltalk, anche i se e i ma sono messaggi da inviare ad oggetti.

In SmallTalk non esistono istruzioni?

Io lo vedo come un punto a sfavore.

Io lo trovo molto comodo, invece: mi basterebbe sostituire la funzione "built-in" print() con una mia per poter "reindirizzare" tutte le parti di codice che ne fanno uso.

A parte questo, non vedo perché sarebbe un punto a sfavore (se non per una maggiore immediatezza e semplicità della forma attuale): print diventerebbe un oggetto come un altro in Python, quindi rendendo il linguaggio più coerente da questo punto di vista.

Java dispone di ereditarietà multipla ed estensione singola. Io avrei preferito che, per chiarezza, le classi fossero state evitate in favore della possibilità di dichiarare un oggetto, a mo' di singleton, come in scala. Basti pensare all'imbarazzo in cui si trova chi debba rispondere alla domanda "ma che differenza c'è tra un'interfaccia ed una classe totalmente astratta"? La risposta è nessuna: è un punto in cui due strumenti del linguaggio si sovrappongono.

Le interfacce non possono contenere attributi però, mentre le classi astratte sì: la differenza, quindi, c'è.

Non conosco Scala, per cui non so di cosa parli in quel contesto.

Comunque non hai risposto sull'ereditarietà ed estensione multipla: ti piace? Non ti piace? Ed eventualmente perché.

No. L'approccio tradizionale all'orientamento agli oggetti è quello, per intenderci, di Design Pattern: solo un'altra prospettiva da applicare ai fenomeni perchè... diavolo non si sa perchè. Che questa sia la tesi tutt'oggi dominante è chiaro sol che si leggano i capitoli relativi all'orientamento agli oggetti dei molti libri che trattano di programmazione. Sai che non è la tesi a cui io aderisco. Io perseguo l'ideale della prospettiva orientata agli oggetti come applicazione del punto di vista di un qualsiasi essere umano alla realtà e dico che questo approccio è superiore perchè risparmia una trasformazione di prospettiva - da come io vedo le cose a come devo vederle per poter scrivere un programma. E' una superiorità logica, incontrovertibile. Col grande problema dell'incertezza sugli esatti contorni del modo umano di vedere le cose.

Certamente, ma Python si avvicina di più al tuo ideale di prospettiva orientata agli oggetti: ti dà una maggior libertà di definire cos'è un oggetto e in che modo "risponde" a certe requisiti / caratteristiche, potendo anche cambiare "comportamento" dinamicamente.

E' un problema che mi incuriosisce perchè per ogni funzione "nativa" le librerie Java forniscono anche un meccanismo per determinare la presenza del supporto. Oso dire che un codice Java correttamente scritto non dovrebbe incontrare problemi nella gestione del caso "modalità fullscreen non disponibile". Si tratta in ogni caso di una questione di librerie e non di lingua o tecnologia, altrimenti basterebbe citare Java3D per ridurre l'alveo dei sistemi operativi supportati ad una manciata.

Questo è un problema di risorse necessarie allo sviluppo di una versione della piattaforma Java. Ma se qualcuno dichiara mitologica la portabilità di Java il minimo che si può pretendere prima di stendersi ai piedi del blaterante di turno è che dichiari cosa impedirebbe l'esistenza di una piattaforma Java su sistemi diversi da quelli esistenti. Non mi pare eccessiva come pretesa.

Se ci fai caso sul linguaggio di per sé non ho avuto nulla di dire: Java lo trovo portatile ovunque, tanto quanto Python o altri.

Ma hai parlato anche di VM, e qui non ero d'accordo sulla portabilità e ti ho fatto un paio di esempi che mi sono venuti in mente. Tutto qui.

Sull'orientamento agli oggetti quello che io preferisco è Object Oriented Programming in The BETA programming language, con particolare riferimento al capitolo sul "conceptual framework". Sul linguaggio di programmazione Java non vedo alternative a The Java Programming Language, di Gosling e altri. Mi acchiappa anche l'ultimo Java - Mattone dopo mattone.

OK grazie. Li metto nel "must be read".

Devi aver rimosso. Tipo un trauma . Ne avevamo già parlato. Ricordi quella faccenda del "ma che diavolo è un oggetto? Un oggetto è una definizione autonoma, la definizione di un oggetto può richiedere altre definizioni, in tal caso oggetto sarà l'unione di tutte le definizioni richieste più la definizione richiedente eccetera eccetera... Ti sovviene alla memoria?

Purtroppo no, e non è questione di trauma: è proprio la mia memoria che dimostra ancora una volta di essere alquanto scarsa (per la disperazione di mia moglie, che comunque ormai ha perso le speranze di un mio miglioramento).

Originariamente inviato da PGI-Bis

Eridaje. Se qui qualcuno ha fornito argomentazioni vi assicuro che a me sono sfuggite.

Te ne sparo una sinteticamente: con Python è possibile modellare velocemente e in maniera semplice un problema, mantenendo il codice compatto, chiaro e manutenibile. Ci si focalizza sul problema.

Quanto a Eckel, sul dizionario alla voce "argomentazione" mi risulta sotto "contrari".

ROTFL. Mi fai morire.

Tanto le checked exception sono peggio del cancro dello scrivano, anche se non lo ammetterai mai.

[k0nt3]

Originariamente inviato da cdimauro

Lo vieta la matematica: non si parlerebbe di equazioni di secondo grado, altrimenti. Nel programma è specificato a chiare lettere, e non mi risulta che esistano equazioni di secondo grado con coefficiente "a" pari a zero.

allora il tuo programma non sta alle leggi della matematica (e nemmeno il mio ma ora l'ho corretto )

Originariamente inviato da cdimauro

Comunque su questo avevamo già parlato (anche con te, che però hai preferito abbandonare velocemente questo ramo della discussione) e avevo anche suggerito di utilizzare il linguaggio macchina dell'Itanium di Intel per il paradigma imperativo, Lisp per quello funzionale e Perl per quello a oggetti.
Sei d'accordo che è tranquillamente possibile utilizzare questi linguaggi per iniziare con quei paradigmi?

ho già risposto. il linguaggio macchina richiede la conoscenza dell'architettura della cpu, lisp è ok per quel che ne so mentre perl non è un linguaggio prettamente a oggetti, quindi no

Originariamente inviato da cdimauro

Non ti capisco: sii più chiaro, cortesemente.

Sei sempre più difficile da capire.

è facile: qualsiasi affermazione atta a dimostrare la superiorità di un linguaggio su un altro è aria fritta

Originariamente inviato da cdimauro

Infatti il risultato non è affatto lo stesso: ti sei mangiato le radici complesse e coniugate, che sono possibili soluzioni di un'equazione di secondo grado, al pari delle altre.

non le ho mangiate, semplicemente non le volevo. comunque sei tu che ti sei mangiato un paio di controlli
questo è completo:

#include <stdio.h>
#include <math.h>
#include <complex.h>

int main()
{
    float a = 0, b, c;
    float delta;

    printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\n");
    while(a == 0)
    {
        printf("inserire il coefficiente a (diverso da 0): ");
        scanf("%f", &a);
    }
    printf("inserire il coefficiente b: ");
    scanf("%f", &b);
    printf("inserire il coefficiente c: ");
    scanf("%f", &c);

    delta = b*b-4*a*c;

    if(delta > 0)
    {
        float x1 = (-b-sqrt(delta))/(2*a);
        float x2 = (-b+sqrt(delta))/(2*a);
        printf("l'equazione ha due soluzioni reali: %f e %f", x1, x2);
    }
    else if(delta == 0)
    {
        float x = -b/(2*a);
        printf("l'equazione ha un'unica soluzione reale: %f", x);
    }
    else
    {
        float _Complex x1 = (-b-csqrt(delta+0*I))/(2*a);
        float _Complex x2 = (-b+csqrt(delta+0*I))/(2*a);
        printf("l'equazione ha due soluzioni complesse: %f%fi e %f+%fi", creal(x1), cimag(x1), creal(x2), cimag(x2));
    }

    return 0;
}

Originariamente inviato da cdimauro

Da notare, comunque, che hai dovuto aggiungere degli #include per poter utilizzare alcune funzioni di libreria, e col significato tutt'altro che semplice da apprendere. Questo per dovere di cronaca.

dai non è difficile..

Originariamente inviato da cdimauro

print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"
a = float(raw_input('Inserire il coefficiente a: '))
b = float(raw_input('Inserire il coefficiente b: '))
c = float(raw_input('Inserire il coefficiente c: '))
print "Le soluzioni dell'equazione sono", (-b + complex(b ** 2 - 4 * a * c) ** 0.5) / (2 * a), 'e', (-b - complex(b ** 2 - 4 * a * c) ** 0.5) / (2 * a)

Cinque righe. E anche su una riga il codice sarebbe comunque inferiore e sempre più leggibile.

Rispetto a Python lo è di gran lunga.

peccato che non si vince niente

Originariamente inviato da cdimauro

No, il Pascal è preferibile anche perché non devi ricorrere a nessuna funzione di libreria, e le procedure Write/ln e Readln sono decisamente più leggibili e facile da usare rispetto a printf e scanf.

ho sempre consigliato pascal infatti, ma anche imparare il C non è la fine del mondo

[cdimauro]

Originariamente inviato da k0nt3

allora il tuo programma non sta alle leggi della matematica (e nemmeno il mio ma ora l'ho corretto )

Ci sta benissimo: i requisiti sono quelli di avere i coefficienti per un'equazione di secondo grado, e libri di testo di analisi ecc. alla mano, dev'essere diverso da zero.

ho già risposto. il linguaggio macchina richiede la conoscenza dell'architettura della cpu,

Si tratta di sempre di scegliere, quindi va bene.

lisp è ok per quel che ne so mentre perl non è un linguaggio prettamente a oggetti, quindi no

Dove sta scritto che per imparare a programmare a oggetti serve un linguaggio "prettamente a oggetti"? L'importante è poter programmare con questa prospettiva. Quindi Perl va bene.

è facile: qualsiasi affermazione atta a dimostrare la superiorità di un linguaggio su un altro è aria fritta

Veramente parli di "bene", "male" e "compromessi".

Per il resto, il contesto era quello di "iniziare a programmare", e la scelta dev'essere ben ponderata. Altrimenti torniamo al discorso di cui sopra su linguaggio macchina, Lisp e Perl.

non le ho mangiate, semplicemente non le volevo.

Un'equazione di secondo grado prevede SEMPRE delle soluzioni, e il tuo programma non le calcola tutte.

comunque sei tu che ti sei mangiato un paio di controlli

Non mi sono mangiato niente: vedi sopra e/o un qualunque testo di analisi, geometria et similia.

questo è completo:

#include <stdio.h>
#include <math.h>
#include <complex.h>

int main()
{
    float a = 0, b, c;
    float delta;

    printf("Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c\n");
    while(a == 0)
    {
        printf("inserire il coefficiente a (diverso da 0): ");
        scanf("%f", &a);
    }
    printf("inserire il coefficiente b: ");
    scanf("%f", &b);
    printf("inserire il coefficiente c: ");
    scanf("%f", &c);

    delta = b*b-4*a*c;

    if(delta > 0)
    {
        float x1 = (-b-sqrt(delta))/(2*a);
        float x2 = (-b+sqrt(delta))/(2*a);
        printf("l'equazione ha due soluzioni reali: %f e %f", x1, x2);
    }
    else if(delta == 0)
    {
        float x = -b/(2*a);
        printf("l'equazione ha un'unica soluzione reale: %f", x);
    }
    else
    {
        float _Complex x1 = (-b-csqrt(delta+0*I))/(2*a);
        float _Complex x2 = (-b+csqrt(delta+0*I))/(2*a);
        printf("l'equazione ha due soluzioni complesse: %f%fi e %f+%fi", creal(x1), cimag(x1), creal(x2), cimag(x2));
    }

    return 0;
}

Ti sei salvato in calcio d'angolo: complex.h è stato introdotta soltanto con l'ANSI C99.

dai non è difficile..

Ma dico: hai provato a confrontarlo con la versione Python che ho postato? Non è difficile, ma è decisamente contorto.

peccato che non si vince niente

Mi serve per confermare ancora una volta che la scelta del linguaggio per imparare a programmare è importante, e finora non mi sembra ci sia niente di meglio rispetto a Python.

ho sempre consigliato pascal infatti, ma anche imparare il C non è la fine del mondo

Lo è: è fra i più brutti, contorti e inutili linguaggi della storia dei linguaggi di programmazione.

Ah, dimenticavo: per Delta = 0 si hanno DUE soluzioni, reali e coincidenti.

[^TiGeRShArK^]

Originariamente inviato da k0nt3

niente vieta di assegnare il valore 0 al coefficiente a, perciò la divisione per zero ci può essere.

si, lo vieta esplicitamente la traccia dell'esercizio (o il requisito del problema se preferisci).

print "Calcolo delle radici di un'equazione di secondo grado nella forma aX^2 + bX + c"

Come fa ad essere un'equazione di secondo grado se il coefficiente a è uguale a 0?
Nel caso in cui quel coefficiente sia uguale a zero è semplicemente un'errore di chi ha inserito i dati.
Si potrebbe criticare il fatto di non avere introdotta una gestione delle eccezioni per presentare meglio all'utente l'errore da lui commesso..
ma mi pare che il discorso non verteva sulla forma dell'errore da presentare all''utente quanto piuttosto sulla risoluzione di equazioni di secondo grado.
Se poi si vuole estendere il programma per risolvere equazioni di grado diverso dal secondo quello è un altro requirement che non è stato in alcun modo specificato.

[k0nt3]

Originariamente inviato da ^TiGeRShArK^

si, lo vieta esplicitamente la traccia dell'esercizio (o il requisito del problema se preferisci).

la traccia era calcolare le soluzioni delle equazioni di secondo grado, il che lascia spazio a ogni tipo di ambiguità (compresa quella sui numeri complessi). fatto sta che io posso inserire il valore 0 e quindi in realtà sto considerando un'equazione di primo grado al contrario di quello che dice la traccia
non facciamoci un processo su sta cosa.. l'unica specifica era che l'equazione doveva essere di secondo grado (quindi con a <> 0)

[cdimauro]

Originariamente inviato da k0nt3

la traccia era calcolare le soluzioni delle equazioni di secondo grado, il che lascia spazio a ogni tipo di ambiguità (compresa quella sui numeri complessi).

Senti, le equazioni di secondo grado in forma aX^2+bX+C=0 non me le sono certo inventate io, e matematicamente sono degli oggetti BEN FINITI: hanno il coefficiente "a" diverso da zero e ammettono SEMPRE due soluzioni (reali e distinte, reali e coicidenti, o complesse e coniugate).

Il problema, quindi, era BEN POSTO, e la soluzione che ho proposto ASSOLUTAMENTE CORRETTA.

fatto sta che io posso inserire il valore 0 e quindi in realtà sto considerando un'equazione di primo grado al contrario di quello che dice la traccia

Questo caso non ricadrebbe nel dominio del problema, per cui ciò che succede non è affar mio.

Il "contratto" stipulato fra programmatore e utente è chiarissimo: si parla di equazioni di secondo grado. In QUESTO contesto il programma funziona alla perfezione.

non facciamoci un processo su sta cosa.. l'unica specifica era che l'equazione doveva essere di secondo grado (quindi con a <> 0)

L'unica specifica è che il programma provvede a fornire le soluzioni (SEMPRE, visto che esistono in ogni caso) di un'equazione di secondo grado (che per definizione NON può avere il coefficiente "a" pari a zero). Punto.

Io, da buon programmatore, mi sono attenuto strettamente e perfettamente al problema.

[Guille]

Originariamente inviato da cdimauro

Senti, le equazioni di secondo grado in forma aX^2+bX+C=0 non me le sono certo inventate io, e matematicamente sono degli oggetti BEN FINITI: hanno il coefficiente "a" diverso da zero e ammettono SEMPRE due soluzioni (reali e distinte, reali e coicidenti, o complesse e coniugate).

Il problema, quindi, era BEN POSTO, e la soluzione che ho proposto ASSOLUTAMENTE CORRETTA.

Questo caso non ricadrebbe nel dominio del problema, per cui ciò che succede non è affar mio.

Il "contratto" stipulato fra programmatore e utente è chiarissimo: si parla di equazioni di secondo grado. In QUESTO contesto il programma funziona alla perfezione.

L'unica specifica è che il programma provvede a fornire le soluzioni (SEMPRE, visto che esistono in ogni caso) di un'equazione di secondo grado (che per definizione NON può avere il coefficiente "a" pari a zero). Punto.

Io, da buon programmatore, mi sono attenuto strettamente e perfettamente al problema.

In astratto potrei anche darti ragione ma a patto che nell'ultima affermazione sostituisci buon programmatore con bravo coder

[k0nt3]

Originariamente inviato da cdimauro

Si tratta di sempre di scegliere, quindi va bene.

Dove sta scritto che per imparare a programmare a oggetti serve un linguaggio "prettamente a oggetti"? L'importante è poter programmare con questa prospettiva. Quindi Perl va bene.

stai cercando di travisare quello che ho detto. io ho detto che prima di imparare un linguaggio bisogna avere una conoscenza teorica del paradigma a cui il linguaggio fa riferimento. nel caso di perl non mi basta conoscere la programmazione a oggetti perchè supporta anche altri paradigmi, ma in linea di principio niente mi vieta di iniziare dal perl (a parte che devo conoscere più di un paradigma)
considerare il linguaggio macchina ha poco senso perchè per prima cosa è un linguaggio di natura diversa e richiede la conoscenza dell'hardware su cui gira.
in ogni caso l'asm (non il linguaggio macchina) può essere una scelta se si è interessati a questo tipo di programmazione e si conosce l'architettura della cpu.

Originariamente inviato da cdimauro

Veramente parli di "bene", "male" e "compromessi".

Per il resto, il contesto era quello di "iniziare a programmare", e la scelta dev'essere ben ponderata. Altrimenti torniamo al discorso di cui sopra su linguaggio macchina, Lisp e Perl.

bene, male = aria fritta

Originariamente inviato da cdimauro

Un'equazione di secondo grado prevede SEMPRE delle soluzioni, e il tuo programma non le calcola tutte.

un'equazione di secondo grado prevede sempre delle soluzioni complesse, ma non sempre delle soluzioni reali. visto che non era specificato era corretto anche il mio

Originariamente inviato da cdimauro

Non mi sono mangiato niente: vedi sopra e/o un qualunque testo di analisi, geometria et similia.

nel senso che è utile dividere i casi a seconda del delta. serve a imparare a programmare, altrimenti l'esempio non serve a niente

Originariamente inviato da cdimauro

Ti sei salvato in calcio d'angolo: complex.h è stato introdotta soltanto con l'ANSI C99.

praticamente l'hanno aggiunta ieri

Originariamente inviato da cdimauro

Ma dico: hai provato a confrontarlo con la versione Python che ho postato? Non è difficile, ma è decisamente contorto.

dove è contorto

Originariamente inviato da cdimauro

Mi serve per confermare ancora una volta che la scelta del linguaggio per imparare a programmare è importante, e finora non mi sembra ci sia niente di meglio rispetto a Python.

e dove sta scritto che il linguaggio più adatto a imparare è quello che richiede meno righe? è un'affermazione senza senso

Originariamente inviato da cdimauro

Lo è: è fra i più brutti, contorti e inutili linguaggi della storia dei linguaggi di programmazione.

ai posteri la dimostrazione

Originariamente inviato da cdimauro

Ah, dimenticavo: per Delta = 0 si hanno DUE soluzioni, reali e coincidenti.

non mi sembra il caso di fare dell'umorismo