OT Programmazione - rolling release - chunk 1 2015

[M.A.W. 1968]

Se la mettiamo così anche APL e J oppure R sono "poco diffusi". Ciò non toglie che siano estremamente utili per alcuni task.

Se poi consideriamo anche che tra i linguaggi "più conosciuti" ci sono dei disastri come java, visual basic e PHP il quadro è decisamente completo... citando Réné Guénon: "L'avis de la majorité ne peut être que l'expression de l'incompétence". Il che si allinea perfettamente con il pensiero di un altro grande, Godfrey H. Hardy: «Stare con la maggioranza non vale il tempo di un uomo intelligente. Per definizione, c'è già abbastanza gente per farlo.».

La minore diffusione di un linguaggio comporta ormai quasi unicamente una riduzione della base di codice liberamente disponibile. Considerazione puramente quantitiativa, che nulla dice in ordine alla qualità di tale codice (di norma inversamente proporzionale alla diffusione, si pensi solo alla quantità di idiomi demenziali presenti in miriadi di esempi C e C++ e per controesempio alla superiore qualità media del codice non liberamente disponibile, i.e. lavori commerciali sottoposti a non disclosure) e soprattutto in merito alla reale qualità, applicabilità, utilità del linguaggio in questione.

[MySQL]

...
La minore diffusione di un linguaggio comporta ormai quasi unicamente una riduzione della base di codice liberamente disponibile...

Non è proprio così, ci sono altre considerazioni.
La qualità del compilatore (o interprete), ad esempio.
Soprattutto librerie di IO, GUI e interfacciamento con database vari, che in un "mondo moderno" rappresentano spesso una parte assai significativa, possono facilmente far scartare un linguaggio (sulla carta) ottimo, ma che richiede uno sforzo 10x o anche 100x per ottenere risultati sovrapponibili.

A mio modestissimo parere è l'intelligenza (ed esperienza) dello sviluppatore a far la differenza sempre e comunque, il linguaggio è poco più che un mezzo per ottenere un fine

[MItaly]

La qualità del compilatore (o interprete), ad esempio.
Soprattutto librerie di IO, GUI e interfacciamento con database vari, che in un "mondo moderno" rappresentano spesso una parte assai significativa, possono facilmente far scartare un linguaggio (sulla carta) ottimo, ma che richiede uno sforzo 10x o anche 100x per ottenere risultati sovrapponibili.

^this. Durante le recenti peregrinazioni per la ricerca di un linguaggio adeguato a riscrivere un'applicazione medio-grande il grosso dei linguaggi non sono stati scartati perché di per sé non siano dei bei linguaggi, ma per carenza di toolkit decenti e incertezza sul futuro dell'ecosistema a medio-lungo termine. Poi se un'azienda è sufficientemente grossa da potersi permettere di prendersi sulle spalle il mantenimento di tool grossi come un compilatore e toolkit (GUI, rete, serializzazione, ...) seri tutto si può fare, ma in genere le risorse sono quelle che sono (oltre al fatto che l'investimento ha senso solo se ci si aspetta di avere un ritorno significativo rispetto all'uso di strumenti mainstream).

A mio modestissimo parere è l'intelligenza (ed esperienza) dello sviluppatore a far la differenza sempre e comunque, il linguaggio è poco più che un mezzo per ottenere un fine

Questo è sempre vero, però è anche vero che avere a disposizione strumenti più potenti (o comunque, impostati in maniera diversa) ti cambia la maniera di approcciare i problemi. Personalmente da quando in un paio di applicazioni siamo passati allo standard più recente del C++ vedo che tanta roba la scrivo in maniera diversa, più con un'impostazione da programmazione funzionale che OOP (portando idiomi che ho visto/usato in Python, Erlang e Lua).

[Scara95]

Mh, era proprio quello che dicevo su chi condanna la programmazione funzionale e poi è felice per le ultime features del linguaggio X principalmente OO

(Non sto parlando di te ovviamente MItaly)

[MySQL]

^this. Durante le recenti peregrinazioni per la ricerca di un linguaggio adeguato a riscrivere un'applicazione medio-grande il grosso dei linguaggi non sono stati scartati perché di per sé non siano dei bei linguaggi, ma per carenza di toolkit decenti e incertezza sul futuro dell'ecosistema a medio-lungo termine. ...

Bhè in effetti la risposta c'è, e si chiama C.
E' brutto da dire, ma la stragrande maggioranza dei programmi C funziona ancora (più o meno) senza tanti cambiamenti anche dopo 40 anni, e realisticamente, continueranno a farlo.
Come si può notare non ho messo C++, anche per il "disastro" della portabilità già precaria tra il mondo Win e *inix, per non parlare di embedded, con l'ulteriore strato di disastro (clang)

Non per nulla ho scritto "quasi unicamente" per tagliar corto. Ci sono interi testi dedicati ai criteri ingegneristici per la scelta dei linguaggi di programmazione nei più vari contesti progettuali, dall'embedded al datawarehousing, dal gestionale all'eidomatica e ai CAD/CAM...

Appunto, per ingegneri
Comunque sono per lo più scelte non dico teoriche/accademiche, ma... teorico/accademiche, giacchè normalmente si "vive" in un ecosistema in cui il programma X deve funzionare su Y,Z e colloquiare con A,B,C.
E, arrivati a quel punto, l'albero viene prunato brutalmente a davvero poche foglie, per collassare quasi sempre nel singoletto C

[Scara95]

Bhè in effetti la risposta c'è, e si chiama C.

[Altre soluzione sono] scelte non dico teoriche/accademiche, ma... teorico/accademiche

E, arrivati a quel punto, l'albero viene prunato brutalmente a davvero poche foglie, per collassare quasi sempre nel singoletto C

C C C C C

E il sacro java per cui bisogna pregare (spero che il suo sia sarcasmo).

Edit. Ad ogni modo non interverrò più sull'argomento dato che la discussione è diventata sterile da quando si parla per dogmatismi.

[M.A.W. 1968]

Non è proprio così, ci sono altre considerazioni.
La qualità del compilatore (o interprete), ad esempio.

Non per nulla ho scritto "quasi unicamente", per tagliar corto: in quel contesto mi premeva unicamente sottolineare che la "popolarità" di un linguaggio dice quasi nulla sul suo valore intrinseco, anzi spesso testimonia il contrario (coding monkeys, pasticcioni e amatori sono di un ordine di grandezza più numerosi dei programmatori professionisti). Si sa che ci sono interi testi dedicati ai criteri ingegneristici per la scelta dei linguaggi di programmazione nei più vari contesti progettuali, dall'embedded al datawarehousing, dal gestionale all'eidomatica e ai CAD/CAM... nelle realtà più organizzate occorre sempre giustificare in modo estensivo, per iscritto e sotto la diretta responsabilità del project manager, le scelte di linguaggi, compilatori, interpreti, ambienti runtime - in modo "difendibile", anche legalmente, contro eventuali obiezioni di revisori, certificatori, periti eccetera. Specialmente nei mercati più severamente normati, è ovvio, ma non solo.
I criteri sono vari e numerosi, anche se spesso poco quantificabili, perché coinvolgono il fattore umano e quindi la disponibilità e il costo di "esperti" in uno o più linguaggi. Se interessa parlarne, l'argomento è comunque piuttosto vasto.

java addirittura disastro??

Mi limito a citare Dijkstra in merito, senza aggiungere altro...

[MySQL]

Non capisco molto bene, qui mi serve aiuto per comprendere meglio la semantica.

It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits. This circumstance makes the choice of first programming language so important

e anche questo

Finally, in the specific comparison of Haskell versus Java, Haskell, though not perfect, is of a quality that is several orders of magnitude higher than Java, which is a mess (and needed an extensive advertizing campaign and aggressive salesmanship for its commercial acceptance). It is bad enough that, on the whole, industry accepts designs of well-identified lousiness as “de facto” standards.

[M.A.W. 1968]

Non capisco molto bene, qui mi serve aiuto per comprendere meglio la semantica.

Non è particolarmente difficile. Il grande Dijkstra era un irriducibile sostenitore del logicismo-formalismo, inteso come prassi matematica rigorosamente assiomatica: nonostabte l'apparenza, una posizione leggermente diversa da quella di Hersh (da lui più volte criticato) che dal canto suo vede la matematica come "costruzione sociale" puramente formale, e nettamente diversa dall'empirisimo-fallibilismo alla Lakatos-Borwein-Chaitin-Wolfram che invece ci appartiene e ci diverte assai di più.

Dunque Dijkstra procede in modo rigorosamente assiomatico: "Java fa schifo" è appunto un assioma del suo sistema di pensiero. E del mio, si parva licet.


Per l'altra questione, nel mainstream l'eventualità che qualcuno venga a contestare, a posteriori, la scelta di un linguaggio a causa di un incidente veramente grave è pressoché nulla. Si è quindi liberi di usare altri, più prosaici, criteri di scelta. In altri mercati è invece obbligatorio dimostrare di avere applicato dei criteri asseverati (peraltro qui la ricerca interna delle multinazionali surclassa di gran lunga quella accademica nella produzione di regole e criteri selettivi pragmatici) anche nelle scelte di base della implementazione.

Comunque in media gli ingegneri italiani sanno poco e nulla di software engineering (e per fortuna, vista la generale scarsa plasticità mentale dei soggetti a causa dello sclerotismo degli insegnamenti, vedi sopra nel thread). Si tratta invero di una traduzione piuttosto infelice, più o meno come quella di "operations research".

[MySQL]

Dunque Dijkstra procede in modo rigorosamente assiomatico: "Java fa schifo" è appunto un assioma del suo sistema di pensiero. E del mio, si parva licet.

Bisogna stare attenti a sostenere certe opinioni, su questo forum. Java è meraviglioso ed è il primo linguaggio da scegliere in ogni caso, anche per un incontro del III tipo con gli alieni.

Comunque in media gli ingegneri italiani sanno poco e nulla di software engineering ...

Anche qui il rischio-rogo è piuttosto elevato