cosa vi piace e cosa non vi piace a proposito di linguaggi

[mad_one]

per scrivere meno non è necessario usare più abbreviazioni possibili nel codice, serve pensare molto di più prima di scrivere qualsiasi riga di codice.
Laziness è la parola chiave.

questo è chiaro, d'accordissimo con te.
Mi riferivo soltanto alla prolissità della sintassi , anche se l'intellisense di visual studio mi da un'ottima mano...

[wxyz]

solo io ho l'impressione che ci sia qualcosa di un lievemente ... perverso nella modellazione ad oggetti, che non solo permetta ma promuova una crescita di complessità delle interfacce non sempre giustificata?

sì e nascosta la spazzatura sotto il tappeto dell'incapsulamento, ma riemerge nel "selvaggio west" delle interfacce...

non so... mi sembra troppo aleatorio...

in realtà, mi pare che proprio l'incapsulamento e la possibilità di costruire interfacce disaccoppiate e ricche (anche troppo) siano l'unica cosa veramente riuscita nell'oo; già altre forme di disaccoppiamento richiedono non poche "alchimie", tant'è che mi sembra che i design pattern siano nati anche per fornire un libro di magie (una serie di approcci vagamente standardizzati) ed un vocabolario comune fra maghi...

il riuso del codice tramite ereditarietà l'ho sempre visto usato molto limitatamente, praticamente è raro vedere gerarchie più lunghe di 2-3 archi, inclusa la classe "foglia" delle librerie standard da cui eventualmente si deriva...

non so.... ho l'impressione che la vera ingegneria non passi di qui....

[Ronin]

domanda da buon ingegnere, cosa intendi per "vera ingegneria"?

[Cherno]

Intenderà ingenieria del software..

[wxyz]

si esatto, sweng, ma in genere anche l'ingegneria in genere, quella che non ammette accrocchi inutilmente complicati e "forse funzionanti", o furbate, e che ha attenzione all'insieme del sistema e non solo al singolo dettaglio

l'oo mi sembra una soluzione locale al "casino" locale a blocchi di dati/segmenti di codice, con poca attenzione a come si combinano i pezzi risultanti nel sistema visto nel suo complesso...

non lo so, non mi convince da quel che vedo le problematiche che affrontano i progetti di sviluppo e manutenzione sono esattamente le stesse sia che si usi un approccio procedurale che oo..... quindi.... esattamente, a cosa "serve" veramente?

[Kralizek]

principalmente ad assegnare competenze e responsabilità. Il vantaggio della OO è che, se progettato bene, un terzo può aprire il tuo codice e sapere cosa modifcare perchè la logica impone che una cosa sta in un determinato posto e non in un altro (o cmq i posti sono molti meno che non con la programmazione procedurale).

[Ronin]

per come l'avevo capito io, il vantaggio avrebbe dovuto essere proprio il contrario, che un terzo non aveva bisogno di guardare il tuo codice, per usarlo e referenziarlo... (che ne è del famoso modello "black box"?)

cmq per l'ingegneria "in genere" i linguaggi di programmazione "normali" non trovano grande impiego, giacchè essa per sua natura ha la necessità di trattare un numero elevato di dati, compiendovi operazioni matematiche e statistiche che i normali linguaggi rendono assai urticanti, vista la loro pochezza in tal senso (per tacere della gestione di eventuali strumenti che questi dati leggono...).

quindi, se i calcoli sono semplici (=possiamo permetterci dei tempi di calcolo relativamente elevati) sono ottime le soluzioni tipo foglio di calcolo (Excel+vba), se i calcoli sono complessi e chiamano in causa funzioni matematiche ad alto livello (algebra matriciale, derivate di ordine n, sistemi di equazioni, etc) ci si rivolge a prodotti specifici, tipo matlab; se il punto fondamentale è l'acquisizione/controllo si va su labview.

in linea di massima le sovrastrutture che la oop offre (ma anche obbliga ad impiegare) in questi scenari sono del tutto inutili (spesso e volentieri l'insieme dei dati è unico, predeterminato e scarsamente variabile, sicchè un array tipizzato dichiarato globale è perfettamente adeguato a risolvere qualunque problema di interscambio tra le routine).

ecco, quello che mi piacerebbe trovare in un linguaggio (e che oggi come oggi c'è solo in matlab) sarebbe la capacità di eseguire operazioni matematiche anche complesse con dati anche complessi, ad esempio scrivere x=da/dt*b con x, a e b che sono matrici almeno 2d, e ottenere sia la derivata che il prodotto in modo assolutamente trasparente (senza cioè, dover creare una libreria di funzioni apposta, che è un vero delirio).

[Kralizek]

per come l'avevo capito io, il vantaggio avrebbe dovuto essere proprio il contrario, che un terzo non aveva bisogno di guardare il tuo codice, per usarlo e referenziarlo... (che ne è del famoso modello "black box"?)

aspetta...

ci sono 2 "approcci".

Il primo approccio è quello dell'utente di un'ipotetica libreria. In questo caso è esattamente come dici tu. Il "terzo" può utilizzare le tue funzionalità in una maniera che segue la "logica" umana e non solo un grande insieme di funzioni poco correlate tra loro.

Il secondo è quello del manutentore. Se io devo prendere in gestione il tuo codice, sarà molto più facile andare a trovare la funzionalità che mi serve. Ad esempio: se devo "modificare" la funzione per sommare X giorni ad una data, nel primo caso ti basterà modificare un metodo "AddDays()" della classe "Date". Nel secondo dovrai cercare qualcosa che assomigli ad "AddDaysToDate()". Insomma... uno dei side effect della programmazione o-o è che lo trovo molto più ordinato

ADD: Matlab è in java uch:

[Cherno]

Va bè, da qui a dubitare dell'effettiva utilità dell'oo ce ne passa davvero.
Il problema, come sempre in questi casi, è capire quando serve e se serve.

[vaitrafra]

Serve sempre, è un modo di pensare e suddividere in unità funzionali un problema.

[Cherno]

Assolutamente no, serve sempre è una forzatura bella e buona.
Stiamo ritornando sull'accademico?

[Kralizek]

serve per tutto ciò che va oltre l'hello world

ma non è detto che non si possa fare un hello world ad oggetti!

[Ronin]

concordo sul serve sempre, mi sono espresso un po' laconicamente.
ma a 'sto mondo, si deve ottimizzare economicamente, giacchè i software che scriviamo servono a produrre, e non (solo) a giocarci come degli idioti, come ci piace tanto fare...

allora capita che i vantaggi nell'usarla siano insignificanti, mentre i costi dell'utilizzarla eccessivi e ingiustificabili; questi casi, che in molti campi di applicazione sono la stragrande maggioranza, meriterebbero secondo me maggiore attenzione da parte delle case produttrici di software.

@kralizek: tu prova a risolvere un sistema di equazioni alle derivate parziali con java, poi mi racconti... è chiaro che è possibile utilizzare un linguaggio standard per creare funzioni matematiche di quella complessità (altrimenti matlab nemmeno esisterebbe). il punto è che lo sforzo per riuscirci è così mostruoso da essere ingiustificato, per cui è più produttivo pagare e usare matlab.
solo che a me non serve arrivare a matlab, mi basterebbe anche molto meno e già sarei contento; ed è un peccato (o almeno io lo giudico tale) che microsoZZ o chi per lei, non trovi convenienza ad investire su di me e sulle mie esigenze.

[Cherno]

concordo sul serve sempre, mi sono espresso un po' laconicamente.
ma a 'sto mondo, si deve ottimizzare economicamente, giacchè i software che scriviamo servono a produrre, e non (solo) a giocarci come degli idioti, come ci piace tanto fare...

allora capita che i vantaggi nell'usarla siano insignificanti, mentre i costi dell'utilizzarla eccessivi e ingiustificabili; questi casi, che in molti campi di applicazione sono la stragrande maggioranza, meriterebbero secondo me maggiore attenzione da parte delle case produttrici di software.

D'accordissimo.

[vaitrafra]

Allora, cominciamo a fare ordine qui, perchè non si sta facendo nessuna distinzione, in primo luogo, tra situazioni ipotetiche e realtà palpabile.

In una situazione ipotetica, sove ci sono risorse illimitate ma *soprattutto* macchine infinitamente potenti, non ha senso dire che il modello OO fallisce, anzi in questa situazione la suddivisione del programma/progetto in una miriade di sotto-unità funzionali è l'approccio migliore a qualsiasi problema, non solo nel campo della programmazione.

Se comiciamo a vedere le situazioni reali le cose cambiano, ma resta il fatto che il modello OO (in ambienti in cui ha senso che esista naturalmente) è completo e utile sempre, non tanto perchè gli oggetti siano fichi, ma perchè è un modo di pensare, come ho detto sopra, che aiuta a sezionare il problema in più sottoproblemi ed è sempre più facile risolvere 2 problemi affrontabili al posto di uno molto complesso; piuttosto, in seguito all'analisi si può pensare di sostituire le classi con moduli o sottoprogrammi topdown, o strutturati o 10 plc, sceglete voi.

La cosa che mi sembra più trasparire dalle vostre perplessità sul modello è la prassi diffusa di progettare le tipiche soluzioni a problemi di media complessità senza implementare un sistema di documentazione completo.
Nel modello OO, la cosa basilare (oltre alla comprensione delle dinamiche del modello stesso ovviamente) è programmare una documentazione curata, accessibile e a sua volta divisa in entità sempre più granulari man mano che lo schema delle classi diventa complesso. Senza questo prerequisito la riusabilità e la comprensione della gerarchia si vanno a fare benedire vanificando l'altra faccia fondamentale del modello che è la *semplicità di manutenzione*.

Per quanto riguarda la complessitàò delle interfaccie, che ho sentito nominare più di una volta, dovete tenere conto che, ipoteticamente, una buona progettazione OO no dovrebbe prevedere classi con più di una decina di metodi(ma anche meno) e campi. Il fatto è che spesso ci si trova a dover competere con tempi ristretti e modifiche in corso d'opera, ma soprattutto va tenuto conto che una gerarchia di classi molto profonda ed articolata succhia risorse HW.

[vaitrafra]

se il punto fondamentale è l'acquisizione/controllo si va su labview.

Lavori con labview? :O

A che versione si è arrivati? Io ho in giro per l'emilia 3 o 4 banchi di collaudo che automatizzai con labview anni fa! che ricordi, è stato il mio primo lavoro vero

[Kralizek]

@kralizek: tu prova a risolvere un sistema di equazioni alle derivate parziali con java, poi mi racconti... è chiaro che è possibile utilizzare un linguaggio standard per creare funzioni matematiche di quella complessità (altrimenti matlab nemmeno esisterebbe). il punto è che lo sforzo per riuscirci è così mostruoso da essere ingiustificato, per cui è più produttivo pagare e usare matlab.

ma io col java manco l'hello world ci faccio...

volevo dire che matlab, alla fine, è scritto in java

solo che a me non serve arrivare a matlab, mi basterebbe anche molto meno e già sarei contento; ed è un peccato (o almeno io lo giudico tale) che microsoZZ o chi per lei, non trovi convenienza ad investire su di me e sulle mie esigenze.

esistono 2 tipi di marketing informatico:
top-down e bottom-up.

mi spiego:
la prima "top-down" è rappresentata dalla società XXX che fa un'indagine di mercato e ne ricava che serve un programma che fa X, Y e Z. E' questo il caso di programmoni come Office o Matlab. La società lo fa, chi lo vuole se lo compra.

la seconda, "bottom-up", rappresenta invece il cliente che chiama la società e l'incarica della realizzazione del programma che fa J, K e W.

Forse tu rientri nella seconda categoria

[Kralizek]

Il fatto è che spesso ci si trova a dover competere con tempi ristretti e modifiche in corso d'opera, ma soprattutto va tenuto conto che una gerarchia di classi molto profonda ed articolata succhia risorse HW.

Beh dai... una gerarchia molto articolata grava principalmente sullo stack dove sali e scendi da una procedura all'altra. E non sono sicuro che una programmazione procedurale (ovviamente non monoblocco) sia molto più leggera per lo stack.

[Cherno]

Aragorn è tutto molto bello ma la situazione ipotetica, sfortunatamente
non esiste. Pertanto

[Ronin]

Lavori con labview? :O

non più per fortuna...

@kralizek: mi sa che io sono bottom-down : c'ho le mie esigenze, ma troppo pochi soldi perchè qualcuno mi dia retta...

[Kralizek]

@kralizek: mi sa che io sono bottom-down : c'ho le mie esigenze, ma troppo pochi soldi perchè qualcuno mi dia retta...

tralasciando che ho iniziato a programmare a 8 anni perchè mio padre a casa sua non aveva "giocattoli" e mi ha insegnato il QBASIC, nel 95 (a 13 anni), geloso dei pc fighissimi dei miei amici con windows 95, mi feci una mia "parodia" di interfaccia a finestra per il vetusto 286 scritta proprio in basic!

peccato che ho perso il source! era programmato a spaghetti (goto con la pala ) ma leggeva le impostazioni da file e supportava 3 lingue (italiano inglese e francese!!!!
per oppormi al prodotto MS, lo chiama Door!

Nostalgia

[Mithrandir]

si esatto, sweng, ma in genere anche l'ingegneria in genere, quella che non ammette accrocchi inutilmente complicati e "forse funzionanti", o furbate, e che ha attenzione all'insieme del sistema e non solo al singolo dettaglio

l'oo mi sembra una soluzione locale al "casino" locale a blocchi di dati/segmenti di codice, con poca attenzione a come si combinano i pezzi risultanti nel sistema visto nel suo complesso...

non lo so, non mi convince da quel che vedo le problematiche che affrontano i progetti di sviluppo e manutenzione sono esattamente le stesse sia che si usi un approccio procedurale che oo..... quindi.... esattamente, a cosa "serve" veramente?

infatti OO e soluzione ingegneristica non sono mica sinonimi

[Kralizek]

assolutamente!

ma è un sinonimo di "soluzione ingegneristica" scegliere un "paradigma" e seguirlo in tutto e per tutto. le mezze soluzioni portano solo casini!

[vaitrafra]

ma Soluzione ingenieristica non vuole dire un caxzo.

[Kralizek]

boom