Newsgroup: it.lavoro.informatica
Titolo: verbosità vs. espressività

Premessa: discussione da macchinetta del caffè.
 
Alla macchinetta del caffè, appunto, è nata una bonaria discussione con 
un collega sui linguaggi di programmazione. Riassumendo le tesi sono le 
seguenti:
 
Tesi del collega: i linguaggi di programmazione tipo Java (ettepareva) 
imperativi e ad oggetti, sostanzialmente verbosi, sono più facilmente 
debuggabili perché bene o male il codice segue una logica più "umana".
 
Tesi mia: è vero l'esatto contrario anzi in generale meno righe di codice 
significano meno bug. Naturalmente a parità di BUONE conoscenze sul 
linguaggio, ovvero se un programmatore non conosce Clojure piuttosto che 
(in misura minore) Scala è normale avere difficoltà a leggerlo, più di 
quelle che può avere chi non conosce Java. 
 
Voi che ne pensate? Naturalmente il primo che risponde "dipende" verrà 
spedito dritto nel quinto cerchio degli accidiosi :-)

 Voi che ne pensate? Naturalmente il primo che risponde "dipende" verrà 
 
Dipende
 
(eh beh, impossibile resistere :) )
 
IMHO ognuno si trova meglio con determinati linguaggi e modi di operare e molto dipende dall'esperienza personale.
Ad esempio io Java lo odio, lo uso ma quando posso preferisco il vecchio caro C o C++.
E trovo piu' facilmente bachi e problemi con i linguaggi che conosco meglio che con quelli "pensati per essere user friendly".
Quindi spannometricamente direi che concordo con la tua tesi.
Spannometricamente perche' per me non e' una questione di numero di linee di codice, ma di come la mente di una persona lavora.
Ovvero non esiste nessun "trucco" o "procedura" che favorisca l'identificazione di bug, in qualsiasi linguaggio. Conta solo la conoscenza del linguaggio, l'esperienza accumulata (facendo una marea di errori) e l'essere predisposti per una particolare logica su cui il linguaggio si basa.
 
C'ya
   STeve


Hai ovviamente ragione tu, specialmente nel caso di linguaggi funzionali che per altro
usano largamente funzioni pure e tentano di evitare side effects quando possibile.
Chi sostiene il contrario ha probabilmente un problema di alcool.
 
  ngw

 spedito dritto nel quinto cerchio degli accidiosi :-)
 
Penso siano questioni molto interessanti se affronate seriamente.

 Penso siano questioni molto interessanti se affronate seriamente.
 
La discussione era seria anche se affrontata alla macchinetta del caffè. 
Si parlava di un progetto a divenire a delle scelte tecnologiche fra cui, 
appunto, il linguaggio da adottare. 
Purtroppo il collega è anche colui che è deputato a decidere, per cui 
nonostante le argomentazioni alla fine si farà come dice lui. 
 
La cosa che trovo frustrante è che queste scelte non vengono fatte perché 
nel pregresso c'è una casistica di successo, anzi. 99 su 100 la scelta 
ricade su Java senza una motivazione tecnica concreta ma solo perché è la 
scelta più rassicurante per chi la fa. Con Java si usa manodopera a più 
basso costo. E comunque in caso di fallimento la scelta di Java non è mai 
sul banco degli imputati, ha l'aureola del linguaggio che usano tutti e 
peranto se il progetto va a ramengo la colpa ricade su chi si è sporcato 
le mani e non ha saputo fare meglio. 

 basso costo. CUT
 
E allora le aziende che usano .net sono equiparabili agli
importatori ed utilizzatori di schiavi africani del '700 e '800.
 

 le mani e non ha saputo fare meglio.
 
Permetti, le due cose non stanno insieme. Dato un progetto, posso scegliere uno strumento migliore o peggiore, MA l'eventuale fallimento, a meno che lo strumento non sia MOLTO specifico, non è legata mai allo strumento impiegato.
 
Io sto portando avanti un progetto. Ho scelto Python, perché è patrimonio aziendale, come strumento, ma avrei potuto scegliere Java, Ruby, C#, quel che vuoi tu, sarebbe cambiato nulla. Se ho fatto un lavoro pessimo, e il progetto fa acqua da tutte le parti, è destinato al fallimento che si usi Python, Java, C#,...
 
-- 
Ciao!
Luca

 strumento impiegato.
 
Quindi scusami, per capire, nel caso in cui tu dato un progetto scegli lo 
strumento peggiore invece del migliore cos'è che ti aspetti come 
conseguenza (estrema, ma neanche troppo)? 

 conseguenza (estrema, ma neanche troppo)?
 
Che cosa significa 'strumento peggiore'? Stiamo comunque parlando di strumenti d uso generico, facilmente adattabili a qualsiasi situazione. 
Se il tuo progetto è un CMS e scegli il Cobol come strumento, magari qualche dubbio potrebbe venire. Ma mi sembra non sia questo il caso prospettato.
 
-- 
Ciao!
Luca

 Permetti, le due cose non stanno insieme. Dato un progetto, posso scegliere uno strumento migliore o peggiore, MA l'eventuale fallimento, a meno che lo strumento non sia MOLTO specifico, non è legata mai allo strumento impiegato.
 
Si e no. Non trovo corretto equiparare tutti i linguaggi (o meglio i loro patrimoni di librerie, framework, rcc.) come se fossero tutti equivalenti in tutti i possibili ambiti.  
Poi devi anche valutare i costi in soldi, tempo, ecc., ovviamente. E non è detto che, calcolato qui ed ora, il costo in senso lato col linguaggio X sia più o meno eguale a quello del linguaggio Y.
Semprechè poi si usi un unico linguaggio per fare tutto, cosa spesso non vera, per cui le cose si complicano di molto.


Capisco, ma la vedo difficile confrontarsi fruttuosamente con qualcuno
che associa il modello operazionale di un linguaggio imperativo a quello
"umano". Si tratterebbe di spiegargli che il cervello non funziona come
una rete di indirizzi e locazioni di memoria con tanto di informazioni
processate e sovrascritte, quanto piuttosto come un sistema associativo
che fa continuamente pattern matching senza che noi dobbiamo
preoccuparci (a livello conscio) dei "dettagli meccanici" della facceda...
Rischi di far prima a cambiare lavoro! (si scherza ovviamente)


Ma gli schiavi disposti per file a sgobbare nei campi come primitiva 'a
version del .Net concurrent and parallel garbage collector non sono
forse una questione di antropologia teatrale?

 processate e sovrascritte, quanto piuttosto come un sistema associativo
 
 
http://www.sciencedaily.com/releases/2013/09/130923175935.htm
 
:)
 
In realta' sciencedaily e' una rivista divulgativa, e la ricerca orgininale -ovviamente- e' molto piu' cauta rispetto a quanto sciencedaily scrive. Nei fatti sono ipotesi, piu' o meno supportate da dati, ma comunque ipotesi. I metodi d'indagine correnti non sono in grado di dare "in vivo" un quadro esatto della situazione, e qui ci sarebbe da scrivere un'enciclopedia. Tant'e' vero che per capirne di piu' l'UE ha stanziato qualche mese fa *bilioni* di euro per mettere in piedi un modello realistico, e il NIH ha seguito a ruota con un progetto simile. In realta', c'e' una corrente di scettici che per un motivo o per l'altro non crede che il progetto possa riuscire ad andare in porto. L'unica cosa certa e' che di come funziona il cervello non si conosce abbastanza! ;-)
 
 

 preoccuparci (a livello conscio) dei "dettagli meccanici" della facceda...
 
 
Stai dicendo che il concetto di "umanità" di un linguaggio non esiste proprio, oppure che esiste ma non si applica a Java, in quanto imperativo, ma piuttosto a <nome linguaggio> (sostituire con quello più "umano")?
 
 
 


E' interessante e a prescindere non avrei comunque dovuto scrivere
"funziona", visto che poco prima parlavo di "modello". Forse sostituendo
con "il modello operativo del cervello, così come da noi percepito, non
funziona come una rete di indirizzi..." si capisce meglio il senso di
quello che volevo dire. 

 L'unica cosa certa e' che di come funziona il cervello non si conosce
abbastanza! ;-)
 
E non lo capiranno mai...
 
"Due cose sono infinite: l'universo e la stupidità umana, ma riguardo l'universo
ho ancora dei dubbi."
 
Albert Einstein
 
 


Sto dicendo che "umana" è stato molto probabilmente buttato lì per caso,
semplicemente intendeva "una logica per me più familiare/a cui sono
(stato) abituato". Certo senza altri dettagli sulla discussione non
possiamo esserne sicuri, ma per esperienza il 98% delle volte a pensarla
così ci si prende.


Ma è un modo per dire che le persone non ragionano e fanno le loro scelte su 
base emotiva?
Perché altrimenti non capisco.
Per me il ragionamento umano è procedurale.
Con sufficienti librerie sviluppate e tarate sul singolo problema da 
risolvere, un linguaggio procedurale alla fine non non potrebbe essere una 
semplice chiamata a una sorta di DoThis() con un po' di parametri (anche di 
tipo complesso) a corredo? E giù a scalare per il codice all'interno delle 
librerie?
Mi verrebbe da dire che il problema dei linguaggio procedurali è che vengono 
usati subito per implementare nel mentre ci si chiarisce (forse) la logica 
che sta dietro al problema da risolvere e quello che esce rappresenta il 
codice finale.
Ma non capisco perché con logica chiarita, un linguaggio procedurale non 
possa essere altrettanto chiaro da comprendere rispetto ad uno puramente 
funzionale.
Boh
 
 
 

 Boh
 
Ho l'impressione che l'inghippo sia nel tuo "logica chiarita". Fin
quando si resta ad un livello di complessità basso siamo
daccordo. Appena inizi a salire, hai bisogno di astrazioni sempre più
potenti, efficaci e su cui sia il più semplice possibile ragionare.
 
La domanda che mi farei io allora non è cosa manca a Java o C# rispetto a
Betalang, quanto piuttosto cosa in Java o C# mi limita al salire della
complessità.


Appunto, io non saprei dare una risposta.
Certamente dipenderà dal fatto che ho praticamente esperienza zero sui 
funzionali, a parte SQL e le lambda di C#.
Cosa limita C#? 
 

 così ci si prende.
 
Messa così, sono d'accordo.  

 si che si discute, finalmente.
 
Un attimo. Se si propone un nuovo strumento (nel caso, linguaggio) in un ambiente lavorativo, dove la gente non lo fa per divertimento, allora è chi propone che deve dare valide motivazioni per l'innovazione. Non il contrario.
Ed aggiungerei: motivazioni ben adeguate e comprensibili in quell'ambiente.

 l'innovazione. Non il contrario.
 
Io non conosco altri motivi se non quelli di natura economica per usare
una tecnologia al posto di un'altra. Ogni scelta che faccio o che
propongo quando mi viene chiesto di esprimermi al riguardo ha come
obiettivo il time to market e l'abbassamento dei costi di sviluppo.
Ovunque abbia lavorato, si è sempre e solo discusso di software reale,
mai isolatamente di idee (per quanto interessanti magari possano
essere). Questo comporta una tra le seguenti:
 
- il management locale da il via a sperimentare con diversa tecnologia;
- uno sviluppatore interno (tipicamente al di fuori del working time)
  mette su qualcosa di funzionante e poi chiede di considerarlo;
- un contractor esterno mostra software scritto precedentemente e
  relativi vantaggi annessi.
 
Queste ho visto, altre vie non ne conosco. 
 
L'ipotetico interlocutore del mio esempio di prima, invece, tutto questo
non l'ha visto. Lui ha usato solo A ma vuole sentenziare anche su B.
Ovvio che io avendo esperienza concreta sia su A che su B, quando lo
sgamo lo tronco. E io di questo parlavo, di discussioni tra addetti ai
lavori - non di proposte e di chi deve dimostrare cosa.
 
 
(per rispondere invece a tuo appunto:)
Nel caso invece io debba proporre qualcosa a qualcuno interessato,
ovviamente non saprei come altro fare se non mostrando su base concreta
(software funzionante e reports di progetti passati pertinenti, etc.)
i vantaggi economici che avrebbe.