Newsgroup: it.lavoro.informatica
Titolo: Linguaggi di programmazione

Salve a tutti



parto dalla classica graduatoria dei linguaggi più popolari:



http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html




Chiaro queste sono graduatorie che nel mondo reale non hanno granché 

significato pratico, salvo stimolare qualche riflessione personale. Per 

esempio, mi chiedevo: qual'è la vostra classifica personale di 

"gradimento", quei linguaggi dove oltre a sentirvi forti vi appassionano 

anche nell'affrontare i problemi? Soprattutto quanti di voi lavorano 

correntemente con il linguaggio con cui si trovano meglio?



E una riflessione che mi viene perché il mio linguaggio favorito, Scala  

(che fortunatamente è anche quelli che uso), naviga oltre il trentesimo 

posto di popolarità e francamente la cosa un po' mi sorprende. La 

popolarità dei linguaggi mi pare tenda un po' ad andare di pari passo con 

la semplicità della sintassi/semantica più che con la validità e 

produttività nel contesto. In altre parole i linguaggi più popolari lo 

sono anche nell'altra accezione del termine; semantica semplice, poca 

capacità e poche basi teoriche richieste.


 posto di popolarità e francamente la cosa un po' mi sorprende.



Non ti dovrebbe sorprendere. Scala fa parte di quegli eccellenti 

linguaggi che sono purtroppo ancora una nicchia, e che hanno poche 

probabilita' di riscattarsi



A livello professionale ti consiglierei di abbinare Scala ad almeno un 

altro linguaggio di quelli citati prima



-- 

We are the music makers,

And we are the dreamers of dreams






 produttività nel contesto. 



questo è fuori di dubbio; è evidente che l'essere popolare nell'accezione

di "conosciuto ai più" dipende dall'altra accezione, cioè di essere "alla

portata culturale del popolo".  

in generale è vero la programmazione imperativa, anche se a oggetti, 

è più alla portata di chi non ha un solido background. scala (che anch'io 

conosco) pur essendo multiparadigma ha spiccate caratteristiche di un 

linguaggio funzionale e per chi non ha e/o non vuole farsi una base

teorica diventa assai ostico entrarci. 

comunque per rispondere alla tua domanda: noi abbiamo moltissimi progetti

jee che, molto probabilmente, rimarranno purtroppo tali vita natural 

durante. dico purtroppo perché i progetti web sviluppati con lo stack 

typesafe (play! + scala + akka) avrebbero dato risultati molto più che 

incoraggianti sotto tutti gli aspetti in particolare la produttività e 

il numero di bug in relazione alla complessità del progetto (in java 

questa relazione è di tipo esponenziale).


Come spunto di riflessione, spero non flame, butterei sul tavolo una cosa:

quante università o scuole superiori a tema (perito informatico&c) fanno

partire "l'istruzione" dal C? Quanti si "evolvono" verso il php "perché è

simile al C" (nun me pare ma vabbé...).



Ricordo sempre come molti colleghi provenienti dallo scientifico (dove

andavano di pascal(!)) impazzivano al primo anno non per capire come sia

fatta una coda, uno stack, una fifo, una double linked list, ma per riuscire

a generare qualche mostro di codice misto C/C++ per realizzarla. Alla fine

non si studiava strutture dati, si cercava di realizzare un programma che

girasse, quel che faceva poco importa. Non parliamo poi di organizzazione

dei files, controllo versione, uso dei commenti ecc!



Se si fosse iniziato dal Python, linguaggio che da un lato forza un certo

indent e dall'altro ha una sintassi più semplice del Ruby i concetti di

strutture dati, algoritmi di ordinamento ecc sarebbero stati appresi e

toccati con mano sia pur a livello didattico. Così si è formato un bel po'

di scribacchia-codice abituati a "litigare col compilatore" senza avere mai

una completa visione di un algoritmo.



Mi si è detto che il C "è la base", di cosa non saprei, del funzionamento di

un computer no di certo, alpiù potrei capire l'assembly... Degli OS moderni?

Si ok, allora lo studente di III superiore o la matricola hanno come target

scrivere un OS? Com'è che anche alla fine della specialistica quasi tutti non

sanno manco scrivere un Makefile, non sanno usare una shell e non han manco

ben chiaro come funziona la maggior parte del software che usano? Da un lato

si dice che non c'è tempo per fare "certe cose" (che il tempo lo far di molto

risparmiare) dall'altro si vuol insegnare a far case partendo dalle molecole

anziché dai mattoni...



Come classifica personale dei linguaggi:

 1) Python

 2) Ruby

 3) zsh

 4) C e pari livello, task-dependent C++



Aggiungerei alla classifica anche una considerazione su ciò che c'è intorno

ad un linguaggio: la libreria standard in primis ma anche librerie/framework

terze/i, in Python ad esempio c'è una bella libreria standard, ci sono un po'

di framework a tema rete (da Twisted in avanti) ci sono bindings per le

maggiori librerie grafiche (Qt, GTk, (T)Tk ecc); in Ruby c'è meno scelta ma

lato web c'è Rails che pur non piacendomi è un universo se confrontato a

Web2Py&c... Java ha un mondo di pappe pronte a tema ecc. Questo influenza di

molto se non il "gusto personale" influenza sicuramente le classifiche globali

perché se son di corsa e ho la pappa pronta non ho molta scelta...


 una completa visione di un algoritmo.



Sono d'accordo al 100% con i tuoi due paragrafi precedenti (che ho 

tagliato).



Sono d'accordo in parte anche con quanto scrivi qui sopra; tuttavia, a 

mio giudizio, a livello accademico c'e' bisogno di una maggior purezza 

nell'apprendimento, teoria a discapito della pratica



Pertanto, non che python e ruby non vadano bene, ma dipendesse da me 

insegnerei:



programmazione ad oggetti: smalltalk

programmazione funzionale: haskell

programmazione imperativa/procedurale: modula-2



 l'assembly...



C è nato appunto per sostituire l'assembly.

Il 98% degli altri linguaggi sono nati per altri scopi.



Per questo molti progetti sono scritti in C (e fanno bene):

- Git

- PostgreSQL

- Nginx

- ...



Lasciate perdere il C++: meglio il C oppure uno a scelta tra i tanti 

linguaggi di alto livello come Python.



Programmi in C scritti come si deve (come Nginx) non hanno nulla da 

invidiare a programmi scritti in linguaggi di più alto livello.







Ciao  Manlio


  4) C e pari livello, task-dependent C++



IMHO (e qui non parlo di preferenze, ma di uttilità effettiva):

Indispensabili (per motivi già spiegati):

1) Lisp (qualsiasi dialetto, raccomanderei Scheme)

2) C

Molto importanti (il primo è per imparare l'OOP, ed è una naturale

estensione del C che uno arrivato fino a qui, secondo me, avrebbe dovuto

già imparare *bene*, l'altro è linguaggio funzionale "puro"):

3) C++

4) Haskell

Raccomandabile (per imparare la programmazione logica):

5) Prolog



Avendo imparato bene quelli, uno è in grado di imparare un qualsiasi

linguaggio in breve tempo (esperienza personale: Python in 2-3

settimane, a tempo perso, C# in 2 settimane (vabbe', conoscevo già Java

che è(ra) simile), Erlang in tempi più  o meno paragonabili,...) e ha

tutti i presupposti per essere un bravo programmatore.



Altri linguaggi che raccomanderei (ma qui sono molto soggettivo):

Scala, Python, Clojure (vabbe', è Lisp anche quello, ma ci vuole un po'

di conoscenza delle classi Java per essere produttivo con Clojure),

Perl, Erlang, Ruby, e poi tutti gli altri.

Dal PHP fuggo come dalla peste, per ragioni che penso non sia necessario

elencare... Non mi piaciono neanche (*più*; perché anni fa erano tra i

linguaggi "top" nei quali ho anche fatto progetti importanti):

Visual Basic, Delphi, JavaScript,...

Anche Java, una volta uno dei miei linguaggi preferiti, dopo aver

conosciuto Scala qualche anno fa, mi sta diventando parecchio antipatico.

Vabbe, questi erano gusti personali, solo i primi 5 (soprattutto i primi

2) sono quelli che ho elencato a prescindere dai gusti personali.


 capacità e poche basi teoriche richieste.



In quanto a Scala, a me pare l'ennesimo linguaggio, nella fattispecie

funzionale, che viene partorito non si sa bene per quale motivo.

Almeno in MS hanno avuto il buon gusto di partire da un linguaggio

funzionale già esistente, Ocaml (ottimo), per realizzare il loro F#.

Magari sono partiti da zero per pararsi per qualche ragione di

copyright e quant'altro. Vista l'aria che tira sui brevetti non me ne

stupirei :-)

D'altronde scoprire i linguaggi funzionali solo perchè ce n'è uno che

gira sulla macchina Java mi sembra roba molto terra terra (detto in

generale, non a te in particolare).










 simile al C" (nun me pare ma vabbé...).



Ma al'università non si studia ampiamente Java? Ovvero uno dei

linguaggi più richiesti in ambito lavorativo? Si è quindi

faticosamente raggiunta la tanto agognata contiguità università-mondo

del lavoro, e vogliano già smontarla? :-))

Che è una considerazione scherzosa, ma neppure tanto. Dopo anni di

bombardamento a tappeto degli studiosi javacentrici, oggi si scopre

che il non plus ultra è Ruby o Python. Bah.


 invidiare a programmi scritti in linguaggi di più alto livello.



Concordo. Dipende dallo stile usato, non è mica detto che uno deve per

forza usare lo stile più oscuro ed illeggibile "offerto" da un dato

linguaggio. Inoltre dipende anche dalle librerie/framework di cui si

dispone, e che inevitabilmente si useranno. Nel qual caso C

probabilmente è messo molto meglio di altri, come Python, Ruby, ecc.


 non doveva essere fatto.



Vedo che non hai capito nulla... Intendevo che, volendo creare un

compilatore di linguaggio funzionale per la macchina Java, bastava

attingere da una delle numerosissime sintassi già esistenti (Lisp,

Ocaml, Haskell, Mercury, ecc. ecc.), e non inventarsene l'ennesima di

sana pianta.

E Java non essendo per nulla un ling. funz., che c'entra con il

discorso? Ed inoltre i progettisti di Java ci hanno messo ben 20 anni

a capire che, forse, era meglio usare la sintassi funzionale di Scala

piuttosto che Java? Geni! :-)



PS: al link Scala c'è solo una lista, in verità di sapore realmente

commerciale, delle aziende "lider" che usano Scala. Sul perchè

inventarsi una sintassi nuova, nisba.






 inventarsi una sintassi nuova, nisba.



E' una lista di soluzioni in Scala, realmente implementate in ambiente

di produzione, e se poi segui le tracce (cosa che vedo che non hai

fatto) fino alle fonti ti sarà rivelato anche perché le soluzioni in

Scala erano ritenute più idonee rispetto alle altre (che penso tu

avresti consigliato).


 probabilita' di riscattarsi



Difficile dirlo. Dalla sua Scala ha la diffusione dell'"ecosistema"

J2EE che potrebbe agevolarne l'impiego.



bye!


 sana pianta.



infatti scala attinge da diversi linguaggi che hai citato.

per curiosità dov'è che hai letto che se lo sono inventato di sana pianta?


 Se si fosse iniziato dal Python...



Corsi e ricorsi... quanti anni hai? Io ne ho abbastanza per ricordarmi

che trent'anni fa esattmaente gli stessi discorsi li ho sentiti con il

Pascal come illuminato futuro per la programmazione (sì, lo stesso che

secondo te impedisce di comprendere le strutture dati) e il Basic come

bestia nera. Se campo abbastanza, sono abbastanza sicuro che rileggerò

ancora lo stesso discorso, stavolta con il python come baubau (e sono

anche abbastanza convinto che ci vorrà meno di trent'anni ;^)).

La differenza non sta nel martello, ma nel manico, è questa l'unica

considerazione concreta da fare.



bye!


 inventarsi una sintassi nuova, nisba.



Magari semplicemente perchè proviene dall'ambiente accademico, ed è

stato studiato proprio per innovare (tra l'altro, certo non

radicalmente: di cose "già viste" ce ne sono parecchie). A stare a

sentire te, si dovrebbe ancora lavorare tutti in Fortran, che tanto a

che pro inventare nuove sintassi quando già ce n'e' una che

funziona? :^)



bye!


 ancora lo stesso discorso, stavolta con il python come baubau



L'unica cosa su cui scommetterei è che il C sarà ancora vivo e vegeto.





Ciao  Manlio


 funziona? :^)



E non parliamo mica di Fortran 2008, il più moderno, ma del primo

FORTRAN, nato nel 1957. Tanto se c'era quello, con la sua sintassi, che

bisogno c'era di fare evoluzioni? Quello era già Turing-completo, no? :-)


 generale, non a te in particolare).



non più terra terra di questa tua trollatina.








 nel mondo del SW commerciale.



Scusa, ma da dove hai tirato fuori questa percentuale? Mettendo insieme

C, C++, C#, Objective-C (e non so quale altro "C" mi sfugge) mi sembra

che siamo ancora molto lontano dal numero 95%. O abbiamo idee diverse su

cosa sia "software commerciale"? Io con "software commerciale" (in senso

generico) intendo software generico sviluppato e venduto, non destinato

a un determinato cliente (ovvero sviluppato su richiesta di un cliente)

ma a tutti quelli che hanno qualche interesse di acquistarlo. Quello

effettivamente è il campo dove i vari "C" dominano, ma, secondo me, in

senso relativo e non assoluto, e di sicuro non al 95%. Tutto IMHO,

ovviamente.

Comunque, questa fetta di mercato, "software commerciale", è una fetta

molto inferiore a tutte le altre "fette". Dunque, e anche qui IMHO, uno

può benissimo guadagnarsi il suo pane quotidiano (e mangiare anche bene)

anche evitando i vari "C". Ma C lo ritengo indispensabile per altri

motivi, già descritti nel primo mio post in questo thread, e penso sia

superfluo ripeterlo qui.


 a un determinato cliente (ovvero sviluppato su richiesta di un cliente)



No, io comprendo anche quelli. Per software commerciale intendo tutti

quelli sviluppati per fare soldi e non per ricerca o per diletto,

insomma.



bye!


 L'unica cosa su cui scommetterei è che il C sarà ancora vivo e vegeto.



Ti piace vincere facile ;^)



bye!




 bisogno c'era di fare evoluzioni? Quello era già Turing-completo, no? :-)



ed aveva anche l'indentazione "significativa" esattamente come il

tanto moderno python, a ben vedere ;^)



Bye!


 J2EE che potrebbe agevolarne l'impiego.



diciamo che rispetto all'ecosistema jee la tendenza di scala è rimanerne 

fuori. per esempio 
www.playframework.org/
 è totalmente avulso dalle servlet

api e la scelta pare ben ripagata dalle prestazioni.

quello che indubbiamente è un vantaggio è che scala può attingere da tutto

il parco librerie di java.




 bye!



Sta nel martello, nella sua forma e nel peso, nella lunghezza e nella

robustezza del manico, e anche nella forza e nella tecnica di quello che

batte i chiodi (o quello che �). :-)


 L'unica cosa su cui scommetterei è che il C sarà ancora vivo e vegeto.



Eh, eh...lo dico anch'io. Probabilmente ci saranno nuovi standard, con

migliorie apportate, ma in qualche forma il C (non so nemmeno se si

chiamerà ancora così, ma non importa) lo trovereno probabilmente ancora

fra 30 anni. :-)


 insomma.



Vabbe', direi che mettere insieme Java e PHP con i "vari C" sia un po'

tirata come cosa, e comunque, non penso che si arrivi a 95% nemmeno con

la tua definizione allargata del software commerciale. IMHO.



Vuoi farmi commuovere facendomi pensare ai bei vecchi tempi? :-)








be', la cosa non mi sorprende.

Spesso le cose più popolari sono anche le meno complesse.

Quello che mi mette in testa qualche pensiero, insieme con

questa tua riflessione, è il fatto che io programmo in Java,

e Java appare secondo classificato.

Però un po' mi rincuora il fatto che uso anche javascript e pl/sql,

che sono un po' più giù nella classifica...




 la tua definizione allargata del software commerciale. IMHO.



Ovviamente ognuno ha una visione necessariamente parziale del mercato

e si basa su quello che può ragionevomente estrapolare dal proprio

angoletto. Per quanto mi riguarda, negli ultimi dieci anni

praticamente non ho mai sentito nessun cliente effettivo o potenziale

richiedere una tecnologia diversa dal "gruppone" eterogeneo sopra

citato, e neanche essere disponibile a "proposte" diverse...



bye!






 Vuoi farmi commuovere facendomi pensare ai bei vecchi tempi? :-)



No, meglio finirla qua: siamo tecnomanti, non possiamo indulgere nel

romanticismo dei "bei vecchi tempi", siamo tenuti per missione a

proiettarci nel futuro...



bye!


 api e la scelta pare ben ripagata dalle prestazioni.



Questo non lo sapevo ed è un'informazione interessante (anche se

comunque almeno della JDK ha bisogno). Io però non mi riferivo tanto

alle API quanto proprio ai server: se uno si è già messo in casa un

websphere o qualche altro stack del genere, ci può far girare sopra

un'applicazione scala senza cambiare nulla, il che può essere un punto

a favore (anche dal punto di vista delle installazioni "consigliate"

dalle varie multinazionali, che spesso hanno discutibili liste di

environment "ammessi"). Almeno se ho capito bene.



bye!


 avresti consigliato).



Ah, adesso tocca seguire l'intera catena di link, come la caccia al

tesoro...


 per curiosità dov'è che hai letto che se lo sono inventato di sana pianta?



Ho dato un'occhiata a qualche programma, e la sintassi è  comunque

nettamente diversa da Lisp, Ocaml ed Haskell, che un poco conosco.

Che poi un nuovo linguaggio attinga ad altri già esistenti, vorrei ben

vedere, con le centinaia se non migliaia che già ne esistono. Il che

conferma comunque che potevano attingere in modo meno sparso, e

concentrarsi su un capostipite, così come si ha con Lisp ed ML, per

esempio.




 funziona? :^)



Hmmm, ho nominato Fortran da qualche parte? Forse sei come mr. Bean

che guarda sempre fogli bianchi, perchè legge ciò che sta scritto tra

le righe?? :-)))))))

Secondo te con decine di linguaggi *funzionali* c'è necessità di un

ennesimo esemplare? Per me, no. Non è che imparare nuove sintassi, con

sotto gli stessi concetti, ci arricchisce e ci emoziona, come imparare

nuove lingue :-) Se una sintassi funziona bene si mantiene, punto. Ed

oggi credo sia arduo trovare idee totalmente nuove e di reale valore

in questo campo.

Tra l'altro per Java c'è pure il funzionale Clojure, derivato di Lisp,

ma nessuno se lo fila, a quanto pare. Forse perchè non l'ha

"benedetto" Odersky, o perchè quanto sono fastidiose tutte quelle

parentesi.




 tesoro...



Infatti, l'ho scritto che non mi andava di mettermi io a scriverti link,

perch� sarebbe stato tempo perso. Confermo.

E confermo anche che non sai affatto di cosa stai scrivendo, ne per

quanto riguarda Scala, ne per quanto riguarda altri linguaggi da te

citati, ma a forza di difendere le cazzate che avevi scritto stai

sprofondando sempre di pi� nel ridicolo.


 non più terra terra di questa tua trollatina.



Bè, chiaro, meglio non uscire dal mondo Jvm, fuori è buio e fa

freddo ;-)


 citato, e neanche essere disponibile a "proposte" diverse...



Come hai detto, giustamente, tu, "ognuno ha una visione necessariamente

parziale del mercato". La mia visione č diversa perché molti dei

progetti piů importnati li ho sviluppati anche con altri linguaggi.

Alcuni di questi linguaggi facevano parte delle mie proposte di

soluzioni (che i clienti hanno accetato), alcuni di questi mi erano

chiesti esplicitamente. Qui posso elencarti: Perl, Python, Bash (script

di shell), Erlang, Visual Basic, Delphi,... Con i primi tre faccio

ancora molti progetti, il quarto lo uso occasionalmente, gli ultimi due

li ho lasciati perdere.


 esempio.



Come ho già detto: "Innovazione, questa sconosciuta", aggiungo anche

"evoluzione", "selezione", "best practices", ecc, tutte cose che a te,

mi sembra, siano completamente sconosciute.






 perch sarebbe stato tempo perso. Confermo.



Lp'hai scritto *dopo *aver scritto il link. La volpe e l'uva... :-)



Sarebbe cos� se potessimo dare per scontato che il futuro porta sempre

evoluzione e miglioramenti. Senza andare nei dettagli e rischiare di

scatenare flame, dico solo quello che mi pare che sia abbastanza

condiviso come idea, che C esiste da pi� di 40 anni ed � ancora il

linguaggio numero 1 per delle ben precise ragioni, mentre molte cose

spacciate per innovative sono sparite come meteore.



Giusto per completare la spiegazione della mia frase scritta prima: Io

mi ricordo degli anni 80 come anni di eccellenza, di efficenza, dove,

con le risorse limitate dell'epoca, si puntava sulla qualit� e

sull'efficenza, e uno si dava da fare per spremere e razionalizzare fino

all'ultimo bit dei sistemi di allora. Giusto per dirti, Ho imparato di

pi� dai programmi in assembly che infilavo in quei 4 kb (si, 4 kb!)

della RAM del Commodore 64, a partire dall'indirizzo OxC000 (49152) dopo

il BASIC interpreter, che in tutti i linguaggi e su tutte le piattaforme

con le quali ho lavorato dopo... E la cosa pi� importante: quello (e

anche le esperienze simili con Spectrum) mi dava talmente tanta

soddisfazione che nessuna tecnologia dopo ha potuto avvicinarsi a

quello. Vuoi che non abbia nostalgia di quei tempi? Certo, questo non

significa che vorrei che tornassero (e non mi metto di certo ora a

programmare su un emulatore C=64), ma a volte quando mi capita di

lavorare sul codice scritto dagli altri dove le risorse del sistema

vengono inutilmente sprecate, e il codice � scritto a ca**o di cane, non

posso fare a meno di ricordarmi di quei tempi.


 Lp'hai scritto *dopo *aver scritto il link. La volpe e l'uva... :-)



Un link che a una persona intelligente sarebbe bastato. Non mi andava di

scrivere *dopo* altri link, tanto avevo capito (e me lo dimostri di

nuovo) che con te sarebbe stato tempo sprecato.


 mi sembra, siano completamente sconosciute.



Innovazione diverso da moda. Nessuno imponeva a nessuno di perseverare

con Java se fuori c'erano linguaggi diversi, più efficienti, o, guarda

caso, innovativi. Almeno su questo sarai d'accordo.

Invece bisogna aspettare rassegnati per anni fintantochè, ari-guarda

caso, il creatore di Java arrivi con la sua nuova proposta funzionale,

e fiat lux. Contenti voi.






 Contenti voi.



Non so per altri, ma io sono contento.




 nuovo) che con te sarebbe stato tempo sprecato.



Certo, certo. Hai pienamente ragione. D'ora in poi seguirò sempre con

piacere l'intero albero che si diparte dai link qui postati, senza

limitarmi banalmente ed ottusamente a leggere la pagina del link

stesso. Grazie del prezioso suggerimento.



Ma tu pensa, dopo 60 anni c'è ancora chi progetta linguaggi innovativi

mettendoci dentro il fortraniano "for", come accade in Scala. Devono

essere dei reazionari sclerotizzati.. Avrebbero almeno potuto

scriverlo "rof" :-))




 PHP, mettiamo i vari C tutti insieme)



Posso chiedere perche' ?



Lo chiedo essendo uno che, tanti anni fa, ha iniziato la carriera proprio

da questi, [in particolare il secondo ]) e quando l'ha finita (l'anno

scorso), l'unica cosa che si e' visto chiedere e' stato sempre uno di

questi (il primo)



Puo' anche darsi che il fatto che la mia carriera sia finita, sia anche

una dimostrazione del fatto che non conviene scegliere questi linguaggi,

ma mi piacerebbe capire il perche' delle tue scelte (in particolare

perche' non java, che comuqnue mi pare molto richiesto).



Ciao,

Marco.





-- 



questo articolo e` stato inviato via web dal servizio gratuito 

http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it







 invidiare a programmi scritti in linguaggi di più alto livello.



Da programmatore C della prima ora, su questo posso anche concordare

(anzi...). Ma perche' programmi in C++ sarebbero necessariamente peggiori

di programmi scritti ad esempio in C o in Python ?



 Visual Basic, Delphi, JavaScript,...



A.. ecco uno di quelli che non mi venivano in mente: Delphi! Per la

verit'a ci ho lavorato poco comunque.



 



Trovi qualcosa qui:

http://harmful.cat-v.org/software/c++/linus




Per farla breve, C++ è **complicato**.

Spesso si consiglia di usare il C++ solo come subset del C, ma a questo 

punto tanto vale usare il C.







Ciao  Manlio


 ;-)



volendo:

http://www.scala-lang.org/node/168





 Elenca, elenca.



Questo thread � gi� diventato troppo flame-oso per i miei gusti e non

voglio aprire un altro ramo cos�. Se per te PHP e Joomla vanno bene cos�

come sono, continua a usarli. Pace e bene e contenti tutti.


 come sono, continua a usarli.



Guarda, non avevo intenzione di creare flame. Ho semplicemente iniziato a

usarli da quando non faccio piu' l'informatico e non li uso certo a

livelli eccelsi. In ogni caso non ho trovato "problemi insormontabili",

anche perche' uso joomla piu' da utente avanzato che da programmatore

(anche se alla fine mi e' toccato scrivere molto piu' codice di quanto

avrei voluto).

Mi piaceva capire invece cosa non va (rispetto ad altri linguaggi)



 Ciao  Manlio







 punto tanto vale usare il C.



Su questo non c'e' dubbio.


 linguaggio".



Compilatori instabili?

Io ho usato varie release di visual studio (a partire dal 6.0) e non

ricordo problemi rilevanti sulla standard lib o su boost

Idem con g++ che ho peraltro utilizzato per generare codice anche per

architetture arm, con toolchain custom (e quelle si spesso hanno qualche

problemino :)



Linus parlava di instabilita' relativamente alla portabilita' su cui posso

anche credere (anche se non so quanto siano attuali le sue prove).


 "rof" :-))



boh mi sbaglierò ma mi sembra che l'argomento ti stimoli discorsi dimolto 

a bischero.




 stringhe che con le stl sarebbero 10 volte piu' efficenti.



oggettivamente il c è uno dei linguaggi con la semantica più elementare. 

poi che nei domini di utilizzo spesso e volentieri le cose non siano 

affatto semplici è un altro discorso. 

sul resto sono d'accordo, si da per assunto che scrivere direttamente 

operazioni a basso livello favorisca l'ottimizzazione del codice quando 

ovviamente perché ciò avvenga devi essere più bravo ad ottimizzare di chi 

ha scritto la libreria ad alto livello. 


 esempio.



potevano, se avessero avuto le intenzioni di creare un clone di un 

linguaggio esistente. ma non è così. le intenzioni erano riunire 

caratteristiche presenti in diversi linguaggi per cui quello che dici 

semplicemente non aveva alcun senso farlo. visto che c'erano, hanno 

buttato giù una sintassi più espressiva. 

si può sapere perché questa cosa non ti torna o è un segreto?


 J2EE che potrebbe agevolarne l'impiego.



Vero, e' difficile fare una previsione da questo punto di vista.



-- 

We are the music makers,

And we are the dreamers of dreams






 questi (il primo)



naturalmente il tuo caso e' diverso, si sta parlando di chi comincia 

una carriera OGGI, e non quando Java era al top della tecnologia



 [...]





Ciao  Manlio


 libreria ad alto livello.



Sono d'accordo anche io, ed infatti di solito programmo in Python, 

affiancato da C.



Sono anni che cerco un linguaggio intermedio tra Python e C, ma senza 

successo (D, Common Lisp, Haskell, Ocaml): di certo non userei il C++.







Ciao  Manlio


 riscontrato anch'io, soprattutto qualche anno fa.



Io ci sono passato, un circa 10 anni fa.

Dal QBasic ero passato direttamente al C++, ma era una tristezza vedere 

che il 60% (?) delle cose descritte nello Stroustrup [1] semplicemente 

non funzionavano sui compilatori disponibili.



Certo, oggi le cose vanno meglio; ma quanti anni ci sono voluti?



Per questo dicevo che il C++ è complicato.





[1] Nell'errata del suo libro dovresti trovare anche una mia

    segnalazione, giusto per dirti che lo avevo studiato con un certo

    impegno.







Ciao  Manlio


 il fortraniano "for", come accade in Scala.



' Il fortraniano "for" ' ?? Che bestialità è mai questa?!



Non sbagli. Si tratta senza ombra di dubbio di trolling, piuttosto

banale da smascherare per altro.



Il Fortran ha storicamente sempre posseduto essenzialmente lo

statement do-loop, con tanto di (primitiva) possibilità di definire

una label come in:



    do label ...

        ...

label continue



e semanticamente equivalente al for-loop di tipo "tradizionale"

presente in altri linguaggi (il C, ad esempio).



Il for presente in Scala è tutt'altra cosa, visto che si tratta di una

"comprehension" dove l'operatore arrow è un generator. E' chiaramente

falso attribuire l'origine storica di costrutti di questo tipo a

Fortran, tanto più che a tutt'oggi continua a non possederli[*]!

Volendo proprio non rinunciare alla battutella, si sarebbe dovuto

citare CLU, dove per la prima volta è apparso la costruzione d'alto

livello per chiamare un iteratore in un ciclo for.



Parlare quindi di '  fortraniano "for", come accade in Scala ' è

quantomeno risibile, in malafede o meno che sia!.





[*] il "forall" presente da un certo non ricordo quale standard in

poi, non ha niente a che vedere con i vari foreach e for di cui

parliamo, essendo nato per la vettorizzazione dei riferimenti agli

array in ambito high performance etc.



Lascia stare, ha già dimostrato che di tutti quei linguaggi di

programmazione che ha menzionato non conosceva una mazza.

Sta solo trollando (e anche male).


 statement do-loop,



Come ho già scritto, ha già dato parecchie dimostrazioni che di nessuno

dei linguaggi che ha menzionato sapeva una mazza.


 tanto moderno python, a ben vedere ;^)



Battute a parte, che pure hanno scatenato infiniti flaming già

parecchi anni fa. Ovviamente le due questioni sono ben diverse: il

"fixed-format" del Fortran è dovuto a questioni puramente "meccaniche"

dell'epoca di Hollerith. In Python invece la questione è prettamente

*logica*, trattandosi di una diretta derivazione della "Off-side rule"

di Landin vista per prima volta in ISWIM.



Così giusto per precisare su una common misconception - più che altro

per chi non ha mai usato Miranda, Haskell, Occam e compari e si

dovesse chiedere il perchè di certe scelte oggi in Python e F#, ad

esempio.


 del genere?



Purtroppo questo è falso, meglio era vero _in una certa misura_ solo

nelle prime iterazioni di F#. La realtà non è così trasparente e i due

linguaggi sono belli che distinti e separati e si deve fare porting

vero e proprio. L'unica "opzione" indolore è quella di partire dal

sottoinsieme Caml/ML di entrambi - oppure nel caso il software in

questione è stato scritto inizialmente in Standard ML/Caml Light, poi

portato su OCaml (senza troppo uso di preprocessore, functors e

compagnia bella) ed infine destinato al porting su F# (e se il target

finale è Mono, altri problemi all'orizzonte). Ma non è certo la storia

di tutti i progetti.


 capacità e poche basi teoriche richieste.



Che i linguaggi più popolari lo siano (anche) per via di una semantica

"semplice" non mi sembra poi sempre vero: ad esempio, ti basta

iniziare ad abbozzare formalmente una semantica operazionale del

popolarissimo modello di concorrenza di Java per rendertene conto.

Sulle basi teoriche poi, questo gruppo è quanto di più lontano dal

luogo adatto dove discuterne. E ci vorrebbe comunque un mare di tempo.


 Come se il c fosse una passeggiata da imparare.



La sintassi del linguaggio "puro", cioè escluse le librerie standard,

in C è molto più ristretta di quella del C++, considerando che tutto

quello che attiene allo scrivere classi ovviamente in C non c'è.

Mettendo nel conto anche le librerie standard in effetti non saprei se

sono più grandi quelle del C o quelle del C++, intese come numero di

funzioni (o classi e metodi) da "mandare a memoria".




 invidiare a programmi scritti in linguaggi di più alto livello. 

Mai affermato il contrario, semplicemente non ritengo sia opportuno voler

insegnare il C a chi non ha mai visto un listato in vita sua, ancor di più

quando chi insegna conosce la sintassi ma non tutto il resto (e di episodi

a tema sia delle superiori che dell'uni ne ricordo parecchi...), allo stesso

modo ritengo oggi assurdo sviluppare roba tipo una calcolatrice, un super

mini PIM, un client di posta grafico ecc in C od in C++, non c'è nulla di

CPU-bound e tra 100.000 righe di codice e 10.000 penso che le seconde siano

più mantenibili ed evolvibili...


 linguaggio in breve tempo

Un linguaggio a livello di sintassi certo, a livello di libreria standard

c'avrei qualche dubbio come avrei qualche dubbio che sappia gestire la

documentazione nello stile peculiare del linguaggio (javadoc-like, 

rest-text-like ecc) e/o degli strumenti più diffusi (doxygen, sphinx, ...)



Una curiosità per cosa/che motivi ritieni così importante il lisp?


 che il non plus ultra è Ruby o Python. Bah. 

Diciamo che l'idea di Java era una vera rivoluzione, solo che non l'han

capita o voluta capire in troppi, amministrativi SUN per primi... Java

doveva essere la base dello UNIX 2.0, la JVM doveva col tempo diventare

un kernel vero e proprio, il meccanismo di packaging (dai jar all'uso

dei nomi di dominio al contrario alla cache locale ai jnlp senza arrivare

a war/ear) doveva superare il concetto di package-manager/installazione

ecc e le applicazioni dovevano essere il più possibile "distribuite" in

Vero Stile Cloud®©™ alla SUN qualcuno ha capito che la cosa era molto

seria ma non avendo capito cosa fosse s'è limitato a spingere a suon di

dollari il tutto, il mercato e la scelta di essere "vicino" al C++ per

rendere facile la transizione ha fatto il resto...



Python sintatticamente e come libreria standard è oggi quel che il C era

ai tempi di UNIX: un linguaggio strabiliantemente comodo, portabile, con

performance discrete ed una libreria standard completa, non fosse per il

piccolo particolare di non avere un compilatore (o meglio uno vero c'è ma

è fermo da anni)...


 Corsi e ricorsi... quanti anni hai? 

26, ti quoto solo in parte: è vero che il manico è fondamentale, ma oggi

che il manico è molto complesso e mediamente poco efficiente non trovi

che il martello debba compensare? Ricordo al primo anno ad Analisi 1 che

il prof pubblicò un grafico della media dei voti d'esame nel corso degli

anni: per un bel po' di anni era alta, dal 27 in su, poi verso i primi

anni novanta crollava, ben sotto il 18... Dai la colpa alle riforme

scolastiche, al 3+2 a quel che vuoi ma a naso le teste di oggi macinano

meno concetti di quelle di un tempo, per di più la complessità è un bel

po' aumentata: oggi fare GUI, applicazioni concorrenti, di rete ecc è la

norma, un tempo ti accontentavi di terminali 80x25, la rete era roba molto

avanzata da appassionati o gente molto esperta e la concorrenza non si

sapeva quasi cosa fosse...


 proiettarci nel futuro... 

Se mi guardo indietro di tanto in tanto scopro che qualcuno aveva già

risolto un mio problema molto meglio di me :-) la storia fa anche bene

alle volte!


 si può sapere perché questa cosa non ti torna o è un segreto?



Scusa, per quale motivo dovrebbe essere più espressiva la sintassi di

Scala piuttosto di quella di altri? C'è un misuratore? Sempre

considerando la ricchissima platea di linguaggi a cui attingere.

Comunque mi sono imbattuto in Scala   come linguaggio usato nelle view

di  Play. Guarda questo pezzetto:

Scala:

@import helper._

@import helper.twitterBootstrap._

Java:

import play.*;

import play.mvc.*;

Ora dimmi perchè cacchio debbono mettere il trattino basso invece

dell'asterisco. Mi immagino quanti refusi capitano a chi passa

continuamente da Java a Scala. Ecco un'innovazione francamente del

piffero.

Poi sembra che le parole chiave vengono identificate prefiggendole con

la chiocciola, una cosa che troverei orrenda se fosse veramente così

(non ho approfondito).

Trovo più espressive e produttive altre sintassi, ed ho cercato di far

notare che anche entro la Jvm le alternative funzionali ci sono.

Dopodichè ognuno è ovviamente libero di approfondire ed apprezzare ciò

che più gli piace.


 dei linguaggi che ha menzionato sapeva una mazza.



Non ho mai menzionato il Fortran. Attaccati ad altro ;-)




 di tutti i progetti.



Riscrivo pari pari: "molti (non tutti)". Interpretalo (o

compilalo :-))), agitalo e ricomponilo come ti pare, per esempio :

"vero in una certa misura". Il significato in italiano rimane

esattamente quello.




 rendere facile la transizione ha fatto il resto...



Io di Java ricordo che sarebbe servito a scrivere le famigerate applet

da inviare su ogni client, mentre oggi ci fanno i gestionali sui

server.... Non ci scommetterei che queste idee fossero dei manager di

Sun piuttosto che dei progettisti di Java.








 sapeva quasi cosa fosse...



Se scrivevi sotto DOS però si scrivevano vettori di interrupt, che il SO 

ti dava pochino di suo, e avevi:



- il limite di 570 k, e li dentro dovevi stare;

- la possibilità di scrivere GUI che non è detto andassero con tutte le 

schede.



Ora che ci penso, è vero, un tempo mi divertivo molto di più a girare 

bit, ora è tutto troppo semplice... 



;-)



-- 

Ciao!

Luca


 di programmi scritti ad esempio in C o in Python ?



Allora, porcate enormi ne puoi fare con qualsiasi linguaggio conosciuto. 

Riprendendo però in mano il C++ di recente, ho avuto la sensazione che 

la versione attuale sia parecchio differente rispetto a quella originale 

di Stroustrup, e che in realtà ci si sia lasciati un po' prendere la 

mano (come dire, sembra ci abbiano buttato dentro un po' di tutto in 

modo abbastanza disorganico).



-- 

Ciao!

Luca


 punto tanto vale usare il C.



Bah. Le classi e la OOP sono imho grandi comodità. Certo, detto questo, 

molte caratteristiche del C++ possono essere tralasciate.



-- 

Ciao!

Luca


 comunque molto molto piu' complicati del C).



Perché conosci il C. No, per prova provata, la curva di apprendimento di 

C rispetto a Python è più lunga.



-- 

Ciao!

Luca


 Non ho mai menzionato il Fortran. Attaccati ad altro ;-)



Certo che lo hai fatto, nell'altro post di questo thread, dove hai

parlato del 'fortraniano "for"', e anche l� hai fatto una figuraccia da

ignorante.








 dell'asterisco.





Ma � ovvio. Lo fanno in modo che tu possa fare le tue domande e

osservazioni demenziali. Se tua avessi minima idea di cosa sia Scala e

come funziona, sapresti che Scala non ha operatori nel senso stretto del

termine (come non li ha neanche Lisp, o Scheme, o JScheme, un altro

linguaggio del quale parlavi senza aver idee di cosa tu stessi

parlando), ma "*", "+", "-" ecc. sono tutte funzioni. Dunque "*" non

poteva essere usato in Scala nello stesso modo come viene usato in Java,

in quanto � un nome riservato per una funzione, dunque

import play.* significherebbe che deve essere importata la funzione

play.* e per il carattere "jolly" � stato scelto il "_".

Certo che, oltre a essere ignorante sei anche un pirla. E un pessimo troll.








 Per questo dicevo che il C++ è complicato.



Beh, se lo era 10 anni fa, non e' detto che lo sia ancora :-)



Non so come vadano le cose per il C++11 che non conosco molto, pero'

avendo fatto qualche piccola prova con il g++4.7, sembra che non sia messo

cosi' male come nel 2002 nei confronti dello standard di allora.



Certo le mie conoscenze sono estremamente scarse al momento per poter dire

se il livello di copertura dello standard sia buono o meno, ma ricordo che

nel 2002 anche alcune cose banali descritte nel libro di stroustrup non

venivano riconosciute dai compilatori.



Il problema e' che al momento non ho trovato una versione dello stroustrup

(o altri) che descriva lo standard del C++11!!







Ciao,

Marco.



-- 



questo articolo e` stato inviato via web dal servizio gratuito 

http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it







 che più gli piace.



questo è assolutamente pacifico, visto che si parla di preferenze ognuno 

giustamente ha le proprie (anche se te sembri tutt'altro che convinto 

visto che sei intervenuto per polemizzare proprio su questo). però mi 

chiedo: come fai a parlare in termini di paragone se non sei nemmeno in 

grado di distinguere un sorgente scala da un template di play? 


 C rispetto a Python č piů lunga.



Mah... non lo metto in dubbio.  Io ti posso solo dare la prova provata

della *mia* curva di apprendimento. 



Il C avra' una 20-30 keyword (una volta sapevo il numero esatto, ora

non lo ricordo). 

Ai miei tempi la libreria del C si imparava in tempi infinitesimi in

confronto ad esempio alla reference library di python (non parliamo poi

delle varie python recipes e dei cookbook). E te lo dico avendo usato

anche python professionalmente nel 1999-2000, quando sostanzialmente

nessuno lo conosceva ed era molto meno sviluppato di adesso (anche se e'

vero che all'epoca usavo piu' Zope che python).



Tempo di apprendimento di C=1-2 mesi (ma forse anche meno)



Tempo di apprendimento di python: ma, credo di non averlo mai appreso bene

da allora.



Non parliamo poi di J2EE che non sono riuscito ad imparare dopo anni, se

non per quanto riguarda qualcosa inerente ai web services (e al limite

qualche smanettamento abbastanza banale su MDB e code).





E' vero che io venivo da un mondo in cui la soluzione ai  problemi

relativi a molti problemi che si tenta di risolvere usando il  C era nota

(le tematiche del multithreading, il funzionamento dello stack, ecc. erano

problemi quotidiani all'universita', anche dal punto di vista teorico, per

cui questo tipo di problemi, in qualche modo,  avevo gia' imparato ad

affrontarli prima di iniziare a lavorare). Pero' non e' che questi

problemi "di per se" c'entrino molto con il linguaggio, anche se poi

effettivamente il C si usa spesso dove c'e' da lavorare con queste

tematiche.

Puo' essere difficile capire come gestire il multithreading, cosa sia e

come

si gestisca una eventuale preemption, ma questo ha poco a che fare

con imparare il linguaggio (che, di per se', nemmeno ha il concetto

di multithreading, o almeno non lo aveva [non so se ultimamente abbiano

incorporato nella librerua standard qualcosa che lo gestisce]).



 grado di distinguere un sorgente scala da un template di play?



Io sono qui con i popcorn per vedere quanto e' fonda la tana del bianconiglio.

Oh, e Clojure non se lo caca nessuno solo nella testa bacata di qualche ignorante,

e non e' "derivato da lisp", e' un lisp-1, per chi sa cosa vuol dire. E, oh, ha una "sintassi"

in diversa dal common lisp, oltre ad essere un linguaggio totalemente diverso,

anatema!!

LOL



  ngw


 funzioni (o classi e metodi) da "mandare a memoria".



Stai scherzando ?



Il C++ comprende piu' o meno tutte le librerie del C e include inoltre

quelle del C++ (o almeno fino allo standard precedente del C++ era cosi'.

Non so se sia ancora cosi', ma mi meraviglierebbe che avessero tolto dal

C++ le librerie del C).



E, secondo me, le librerie standard del C si imparano anche molto piu'

facilmente ad esempio rispetto alla libreria standard di python (almeno

parecchi anni fa era cosi', ora non saprei, ma mi meraviglierei se fosse

il contrario).



 modo abbastanza disorganico).



Beh, dalla STL in poi, nel C++ di "organico" c'e' sempre stato poco (anche

perche' un linguaggio che si propone di essere multiparadigma e'

probabilmente abbastanza difficile che sia "organico")



 Sun piuttosto che dei progettisti di Java. 

Per l'appunto: erano le idee di Gosling&c, peccato che non le abbiano

fatte capire manco al management SUN... E peccato che la scelta di

"assomigliare" al C++ per "rendere più facile la transizione" abbia

ottenuto l'effetto opposto :-( di Java non mi va proprio l'uso odierno!


 bit, ora è tutto troppo semplice... 

Semplice per modo di dire, nel senso oggi hai molto meno bisogno del

cervello rispetto alle dita, in compenso se non vuoi far porcate devi

aver metabolizzato un bel po' di concetti extra; oggi che IMO il

cervello difetta questo particolare fa la differenza: quanta gente

trovi che si definisce "programmatore Java" e non sa manco cosa sia

javac perché lui "è un professionista, programma con Eclipse e/o

Netbeans"...


 Tempo di apprendimento di C=1-2 mesi (ma forse anche meno) 

Hum, del C come sintassi o anche di chessò POSIX? Perché se conosci solo

quel po' di libreria standard del K&R sicuramente stai bene nei corsi

dell'uni dei miei tempi ma non fai un tubazzo di nulla se non reinventando

la ruota n volte nel mondo reale, per lo meno escludendo il settore super

embedded...


 facilmente ad esempio rispetto alla libreria standard di python

Sfoglia The Python Standard Library by Example di Doug Hellmann, se parli

di numero di cose da conoscere certo, ne hai molte di più, molte di meno

di POSIX comunque...


 Una curiosità per cosa/che motivi ritieni così importante il lisp?



Homoiconicity, lambda calculus e meta-circular evaluation ad esempio,

dovrebbero già bastare per cominciare.


 (o altri) che descriva lo standard del C++11!! 

The C++ Standard Library A Tutorial and Reference Second Edition di

Nicolai M. Josuttis è di fatto un'introduzione al C++11 per chi già conosce

il C++ ed ha una certa esperienza :-)


 dovrebbero già bastare per cominciare. 

Grazie, ma non vorresti mica proporli se non pour parler introduttivo

ad uno studente della triennale no? Se si sarei curioso in che forma:

come riuscire a dare i concetti e nel contempo rendere qualcuno in grado

di operare nel mondo reale in soli tre anni, diciamo anche solo per fare

quelle oscenità chiamate tesi qualche giorno fa (laurea triennale: fai un

sito web così e cosà, usa Joomla, PHP, MySQL ed Apache oppure IIS con

non so che db...)


 di dato sono nativi (wchar_t e bool ad es.) cosa che può confondere i C-isti



I C-isti fermi al C89 per la precisione, essendo bool (la macro, il

tipo è _Bool) e wchar_t compresi nel C90.




 Netbeans"...



Sarà che non sono particolarmente portato per la professione/contesto (web development su 
vb.net
), ma a me sembra che trappole per fare zozzerie varie ce ne siano eccome. Nella mia azienda è rarissimo che ci si metta ad un tavolo a discutere di come sviluppare parti di programma in maniera più approfondita del "deve fare questo e quello", non c'è mai tempo di redarre una qualsiasi forma di documentazione (per un applicativo nato nel 2007) e, secondo il mio modestissimo parere da cooptato non particolarmente convinto della propria adeguatezza, si vede.








credo che questa caratteristica sia abbastanza comune a molte aziende.

Io ho lavorato, sia da interno che da consulente, sia in aziende

grandi che molto piccole, e in base alla mia (limitata) esperienza

direi che questo atteggiamento è piuttosto diffuso nelle grandi aziende:

c'è un progetto da fare, queste sono le funzionalità, questo è come

farle, si fa così e basta. L'importante è che funzioni.



Anche in un'azienda molto piccola succede questo, ma vi sono

anche dei momenti in cui invece ci si mette lì a provare diverse

strade, finché si individua quella che sembra la migliore e si

decide di usare quella. Nelle piccole aziende in cui ho lavorato

ho avuto anche qualche momento così, e una volta ho pure avuto

modo di scrivere un piccolo manuale di navigazione (però di

un sito web, non di un programma).

Invece nelle aziende grandi in cui sono stato a momenti così

non ho quasi mai partecipato.







Io parlo di ambito java, poiché è lì che lavoro, ma immagino

bene che questo discorso valga in generale.




 farle, si fa così e basta. L'importante è che funzioni.



Per quel che vale, io lavoro in una microazienda (<9 dipendenti), e nel reparto programmazione siamo in 4. Non ci sono mai i tempi per operare in tranquillità.



Comunque per non andare fuori tema, le trappole ci sono eccome, e sono di metodo e mentalità, già prima di mettersi a scrivere. Non ho particolare visibilità di come potesse essere la disciplina anche solo una quindicina d'anni fa (diciamo, pre-internet di massa), ma quel che vedo oggi è che se non hai le idee chiare di cosa ti serva, è molto facile realizzare applicazioni che stan su con gli stecchi. Ma bene o male mi sembra che spaceexplorer abbia detto la stessa identica cosa ad inizio argomentazione: è che per quel che vedo io, anche quello è "cervello".


 embedded...





Diciamo che nei primi tempi in cui ho iniziato a lavorare il settore

"super embedded" era piu' o meno il mio (nel senso che i primi tre anni

che ho lavorato, ho lavorato quasi solo ad un simulatore motociclistico

(in particolare alla parte real-time del simulatore. E anche i due-tre

anni successivi magari ho continuato a lavorare a sistemi non esattamente

"standard", tipo sistemi per trasmettere dei dati sui satelliti o cose

simili).



In ogni caso la sola sintassi del linguaggio si impara in 1 settumana. In

un paio di mesi probabilmente impari anche la maggior parte del posix

(specialmente se conosci gia' i problemi da risolvere. Se non sai cosa e'

un semaforo o cosa e' un thread oppure se e' la prima volta che ti capita

di affrontare il problema di sincronizzare due thread magari e' piu'

difficile).



Che poi si debba ogni volta reinventare la ruota e' abbastanza vero, ma in

genere cerchi di riadattare il tuo codice scritto per progetti precedenti

al progetto in corso.



Ciao,

Marco.







-- 



questo articolo e` stato inviato via web dal servizio gratuito 

http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it







 non ho quasi mai partecipato.



Nella grande azienda, se il tuo ruolo e' quello di "programmatore", da te

si aspettano solo che tu produca qualcosa che funziona in accordo alle

specifiche funzionali. Nelle aziende veramente molto grandi, negli ultimi

tempi non ti fanno fare piu' nemmeno i test, tranne gli unit test.





In un'azienda grande in genere funziona cosi':



C'e' il cliente che vuole qualcosa e allora ci sono alcuni che vanno a

parlare con il cliente (a volte ci vanno gli analisti funzionali, a volte

ci va il PM, a volte ci vanno altri, a volte ci vanno combinazioni di piu'

dei suddetti elementi).



In genere chi va a parlare con il cliente produce il documento dei

requisiti funzionali che dovrebbe essere un primo documento di analisi.



Nelle aziende molto strutturate ci sono anche i progettisti che possono

differire dagli analisti funzionali (ci possono essere casi in cui la

raccolta dei requisiti/analisi funzionale la fa l'azienda X mentre la

progettazione la fa l'azienda Y).



I progettisti prendono il documenti dei requisiti (che in genere e'

scritto puramente in linguaggio naturale) e producono dei documenti in cui

i requisiti sono trasformati in use-case, sequence diagram, ecc.



Questi documenti dovrebbero andare in pasto ai programmatori che appunto

producono il codice e fanno gli unit test. I programmatori possono anche

essere lavoratori di un'azienda Z che si e' aggiudicata l'appalto per lo

sviluppo del software ma non quello per l'analisi funzionale e la

progettazione.



Poi ci sono quelli che si occupano del test del software che prendono

l'output dei programmatori e lo testano, progettando i test case e

producendo i report di test e documenti simili.



Tra l'altro in realta' molto grandi puo' accadere che il testing sia

affidato a piu' societa'. Nell'ultima azienda in cui ho lavorato capitava

ad esempio che ci fossero tre ambienti: test, collaudo e produzione (ci

sarebbe dovuto essere anche un quarto ambiente, quello di sviluppo, che

pero' non sempre c'era e quindi i portatili dei singoli programmatori

andavano a costituire l'ambiente di sviluppo). 

Capitava ad esempio che tutto l'ambiente di test fosse affidato ad

un'azienda A (diversa da quella che gestiva lo sviluppo), mentre

l'ambiente di collaudo era gestito da un'azienda B, mentre la produzione

(erogazione)  era sempre gestita da A (in alcuni casi da una terza azienda

C). Quindi tutti i sistemisti e i "test enginers" che facevano

installazione del software in collaudo e relativi test erano diversi da

quelli che facevano installazione e test in ambiente di test o in

produzione



Poi, in altre realta' sempre grandi, mi sono e' capitate anche situazioni

in cui in realta' chi scriveva i documenti di analisi e progettazione non

li dava a chi sviluppava software ma direttamente al cliente finale.

Questo semplicemente perche' tutto (Sia analisi che progettazione che

scrittura software) era affidato alla stessa azienda fornitrice e mentre

alcuni scrivevano i documenti di analisi e progettazione, c'erano i

programmatori che dovevano scrivere il software in contemporanea alla

produzione dei documenti di analisi e progettazione. Quindi quando si

finiva di scrivere i documenti di analisi e progettazione, il software era

gia' stato scritto => i documenti venivano dai dal cliente per fargli

vedere che erano stati fatti (perche' in molti casi e' proprio richiesto

dalla legge, specialmente in aziende pubbliche) ma ai programmatori non

arrivava mai nessun documento,

visto che il software dovevano scriverlo mentre gli analisti scrivevano i

documenti di analisi.



Ciao,

Marco



-- 

Per i lavoratori a bordo dei cacciabombardieri non esistono sabati, ne'

domeniche. Mai un momento di pausa.

"Per costruire 12 ospedali servono 250 milioni di dollari, quel che ci

costano 8 ore di guerra in Iraq...si prendessero un giorno di ferie!".

Gino Strada



 [...SNIP...]



Questa descrizione sembra un sogno :)

Probabilmente mi lamenterei dell'essere rotella di un ingranaggio, ma almeno non mi lamenterei di non sapere cosa devo fare *di preciso*.



Comunque siamo OT: ripeto, il lavorare in questa maniera, per me, è diventato parte integrante del "cervello" che serve avere appena usciti da un istituto di formazione (perché non insegnano il versionamento all'ITI ???), perché la complessità dei progetti di oggi rende difficili ai più la capacità di astrarre tutti gli aspetti di funzionamento, senza un (bel) po' di metodo d'organizzazione.


 aver metabolizzato un bel po' di concetti extra



Voglio spiegare meglio l'affermazione, che corro il rischio di essere 

frainteso. Non pensavo agli strumenti, anche se le limitazioni che 

c'erano sono stare rimosse del tutto.



Io mi rendo conto che, se ho un problema da risolvere, 90 volte su 100 

faccio una ricerca su internet e trovo qualcuno che ha avuto lo stesso 

problema e qualcuno che l'ha risolto. Ovvio che ci devo mettere cervello 

per capire se la soluzione proposta effettivamente è efficace ai miei 

scopi; tuttavia, all'epoca, dato che si aveva accesso a un numero di 

informazioni enormemente inferiore, si doveva andare molto più a intuito 

e di creatività per risolvere un problema che oggi, probabilmente, 

apparirebbe banale.



-- 

Ciao!

Luca 


 non so che db...)



Prendendo in senso più ampio possibile la domanda "come riuscire a

dare i concetti e nel contempo rendere qualcuno in grado

di operare nel mondo reale in soli tre anni". L'unica forma che

riconosco come valida al momento non passa assolutamente per tagli

alla teoria o piani di studio "math-fobici" e più "pratici", ma fa più

o meno:



a) studio della teoria, in modo rigoroso e nella giusta quantità;

b) laboratori pratici e progetti realmente impegnativi;

c) un certo quantitativo di docenti con significativa esperienza nella

industry e messi nei punti/insegnamenti strategici;

d) tutoring e supervision di qualità ove possibile, fondamentale

soprattutto per i corsi più impegnativi

e) 2 (o magari anche 3) internships - idealmente, una per ogni estate

di corso e una subito dopo la laurea.



Si, è il modello delle istituzioni che puoi classificare dall'ottimo

al top e onestamente non vedo come fare altrimenti.



Per un modello più vicino a quello che proponi tu, (sempre se ho

capito bene) una sorta di simil "laurea in software development ", le

idee-chiave da mutuare sarebbero essenzialmente i punti c) e e) - tra

l'altro guarda caso rappresentanti ancora oggi di mancanze croniche

del sistema universitario italiano.


 Tra l'altro con questo vennero introdotte anche diverse *annoyaces per



*annoyances


 problemi quotidiani all'universita', 



Ecco, io vengo da un periodo storico in cui 'ste cose o le conoscevi o 

davvero facevi pochino, almeno sotto DOS. La cosa impressionante è che 

sembra io stia parlando del giurassico superiore, mentre in realtà parlo 

grossomodo del 1990.



-- 

Ciao!

Luca


 ben più rara in linguaggi "di alto livello" (ad esempio i classici python,



Beh, pure con Python. Il trucco è stato incorporare le cose che più o 

meno potevano venire utili, ma se vai a ben vedere molte cose oggi nella 

libreria standard sono nate come progetti indipendenti.



-- 

Ciao!

Luca


 la STL, 



Eggià. Bjarne Stroustrup, The C++ programming language, 1a versione.



In realtà ho usato anche C++ in cui la STL era già presente, ma non l'ho 

mai impiegata (solo qualche volta i template).



-- 

Ciao!

Luca


 grado di distinguere un sorgente scala da un template di play?



A parer mio esprimere un'opinione non significa nè che essa non possa

essere di critica, nè che uno debba farsi un corso sul tale argomento.

Quindi, ti disturba forse il fatto che esprimo un'opinione *di

critica* su Scala? O magari ti disturba che tale opinione nasca da un

"primo contatto" che non è avvenuto come piace a te? Se ti disturba

bè.... e-sti-ca*** :-))))








 qualche smanettamento abbastanza banale su MDB e code).



Scherzi? Dovresti ringraziare tutti i santi del Paradiso di non

esserti spaccato la testa per imparare a memoria tutti i più reconditi

anfratti di tutte le versioni di J2EE, seguendo con entusiasmo i varu

guru mondiali ed in specie quelli che frequentavano (frequentano?)

abitualmente questo gruppo. Salvo poi scoprire che J2EE è ormai

vecchiotto, inflazionato, bisogna sfuggire dalla pazza e cenciosa

folla, ecc.

Ed al posto di J2EE ci puoi mettere altre "parole chiave" di grido,

lascio a te la scelta.

Noto solo che qualcuno, qui, già si dichiara dubbioso, se non proprio

deluso, del Python. Pensa se uno dovesse basare, non dico le sue

scelte professionali, ma quelle su come occupare qualche ora libera

sulle ispirate filippiche che leggo qui a favore o contro certi

linguaggi, tool, ecc. Meglio basarsi sul lancio della monetina.


 tipo è _Bool) e wchar_t compresi nel C90.

Il mio C credo sia fermo alla GaPiL, chiedo venia :-(


 [...]





Ciao  Manlio


 Per un modello più vicino a quello che proponi tu

Quel che propongo è riuscire ad avere alla fine della triennale persone in

grado di installare e gestire una macchina domestica, magari il loro laptop,

conoscere a grandi linee una buona parte delle tecnologie di punta, avere

un'idea discreta di come funziona un'os, saper sviluppare piccole cose,

saper come funziona un impianto elettrico, un cancello, un ascensore, un

servoautomatismo con una minima intelligenza ed avere la forma mentis

"giusta" per poter imparare... Diciamo il background minimo che sarebbe IMO

teoricamente necessario per pensare di iniziare ingegneria informatica...

Quel che non so è come nei due anni di specialistica come formare "ingegneri"

Diciamo che sono "un pelo" negativo sullo stato attuale delle cose...


 [...]





Ciao  Manlio


 [...]



Ciao  Manlio


 e-sti-ca*** :-))))



guarda che a me non disturba proprio nulla. anzi se devo dirla tutta 

trovo il tutto piuttosto divertente. 

e anche te dovresti apprezzare il dibattito, segno che qualcuno ritiene i 

tuoi scritti abbiano dignità di opinione; perché ti garantisco che delle 

volte è parecchio dura non pensare che stai millantando competenze a 

scopo trolling di bassa lega.








 esattamente quello.



Stupidaggini. Il succo di quello che hai detto fin'ora non sta certo

nell'uso ambiguo che fai per l'occasione del quantificatore 'molti',

ma nel fatto che (non sapendo di cosa stai parlando) hai portato un

per così dire falso (monco, direi) vantaggio  a sostegno della tua

tesi già sballata per altri motivi. Inutile adesso nascondersi dietro

dei giochetti.



Un esempio minimale sufficiente a smascherarti:



(1)  1. +. 2.



La (1) è un'espressione di tipo float Caml/Caml Light/OCaml valida. La

stessa genera errore in F#, non avendo il tipo float alcun operatore

"+.". Per converso,



(2)  1. + 2.



è un'espressione di tipo float valida in F#, ma che genera un errore

nel mondo Caml in quanto l'operatore '+' ne aspetta una (di

espressione) di tipo int.



Come farebbe, dunque, l'insieme dei programmi OCaml ed F# _compatibili

a livello di sorgente_, da cui ho appena dimostrato che per cominciare

vanno eliminati tutti quelli che usano espressioni float (e la lista

compelta è lunga: tipi e conversioni, subscript degli array, classi,

sistema di moduli differenti, preprocessore, etc.), ad essere un

motivo di "vanto" tanto da dire "il tuo linguaggio non lo fa"?

Altro che essere un qualcosa di mancante nel mondo Scala, si tratta

piuttosto di un vero e proprio problema risolvibile solo a botte di

colpi di preprocessore, librerie di compatibilità ufficiali e non, e

di un accurato porting per qualsiasi applicazione non banale

(praticamente tutte quelle che sviluppiamo professionalmente oggi in

Caml e derivati).


 generale, non a te in particolare).



Rispondo un po' con ritardo quindi evito di entrare nella polemica visto 

che ti sei già rivelato ed è inutile aggiungere altro. Dico solo che puoi 

stare tranquillo non ho scoperto "i linguaggi funzionali solo perchè ce 

n'è uno che gira sulla macchina Java", su tutte le tue citazioni che hai 

fatto in questo thread, avendo tempo, potrei tranquillamente smontare 

pezzo per pezzo la tua presunta conoscenza, fra l'altro vedo che qualcuno 

ci si è applicato un pochetto (infierendo poco, in verità) riuscendoci 

benissimo.

Buona giornata.


 di Landin vista per prima volta in ISWIM.



Please, cut me some slack ;^)

Era solo una battuta anche molto stiracchiata, non ho una grande

esperienza nè dell'uno nè dell'altro linguaggio ma che le due cose non

fossero paragonabili in realtà ci arrivavo ;^)



bye!



Beh si l'avevo capito che eri ironico :) ho voluto comunque precisare

la cosa in quanto il significant whitespace è storicamente motivo di

infinite discussioni praticamente da sempre, vedi



http://c2.com/cgi/wiki?SyntacticallySignificantWhitespaceConsideredHarmful





 Il mio C credo sia fermo alla GaPiL, chiedo venia :-(



Non conosco, ma nel caso serva per aggiornarsi fino al C99 consiglio

"C Programming: A Modern Approach" di K.N.King -sicuramente il miglior

testo di cui sono a conoscenza per imparare un "C moderno". Quello,

più i draft ISO disponibili gratuitamente in rete e si è a posto. :)


 molte caratteristiche del C++ possono essere tralasciate.



Privarsi della programmazione generica però significa non sfruttare la

caratteristica di astrazione più potente che il C++ mette a

disposizione. Se (e solo se) l'uso del C++ è _effettivamente_ una

necessità per un dato software considerato, non vedo perchè tenerla

fuori (spesso anzi è improponibile).


 > [...]



Nota però che il concetto stesso di object-orientation è così "lasco"

che in pratica ognuno ha nel tempo sviluppato una sua definizione

personale - Alan Kay stesso non fa eccezzione visto che, a voler

essere precisi, la sua stessa "definizione" di "object-oriented" non è

mai stata del tutto chiara ed univoca negli anni.

Una cosa però possiamo dirla con certezza: qualunque sia

l'implementazione moderna che si utilizza, la oop viene presentata

sistematicamente male a chi deve impararla, con tutta l'enfasi

concentrata su classi e ereditarietà quando invece sarebbe molto

meglio introdurla parlando inizialemente solo di stato e message-

passing.


 [...]





Ciao  Manlio


 Diciamo che sono "un pelo" negativo sullo stato attuale delle cose...



Con tutto il rispetto parlando, mi sembrano dei risultati ben sotto la

soglia della *decenza* per un corso di *laurea* in materie

scientifiche e/o ingegneristiche. Non che non abbia mai dovuto aver a

che fare con autentici brocchi o correggere il lavoro di incapaci e/o

svogliati cronici, ma non mi pare assolutamente il caso di auspicarsi

sempre _meno_ dal sistema di istruzione e dalle persone che ne

fuoriescono.



Se le matricole dei corsi di laurea a carattere scientifico si

presentano sempre più impreparate di anno in anno, non sarà certo lo

sminuire (quando non eliminare del tutto) l'insegnamento della

matematica a risolvere qualcosa; semmai si dovrebbe smettere di

insegnare già dalle scuole elementari cretinate come "la

moltiplicazione è l'addizione ripetuta" o "la regola dei segni

dice..." - quello si che porterebbe risultati concreti. Peccato solo

che ai più sembri sempre così difficile fare la cosa giusta.


On Jan 9, 4:34 pm, Manlio Perillo <manlio_perill...@SPAMlibero.it>

wrote:


Onestamente il paragone con Haskell non lo vedo molto, visto che il

"fare di più" in quel caso è tutto "verso l'alto" ovvero verso forme

potenti di astrazione. Ma il risultato è raggiunto partendo

all'opposto, da un linguaggio denso e ricco che richiede si molta più

capacità d'astrazione per essere usato proficuamente

(idiomaticamente?), ma resta non solo domabile anzi è uno dei

prototipi di quei linguaggi in cui diviene piuttosto naturale il

"thinking in".

La complessità del C++ all'opposto, deriva dal fatto di aver poggiato

(sul C) una caratteristica aggiuntiva sopra all'altra fino a quando

non ha iniziato a pendere come la Torre di Pisa. E così mentre

scrivere e pensare in Haskell è un esercizio di logica e deduzione, in

C++ si deve sempre prestare come una sorta di "ingegneristica"

attenzione a tenere tutto sotto controllo - caso perso in partenza

tanto più che addirittura B. Stroustrup stesso in passato prese un

paio di autentiche sviste riguardo lo standard su comp.lang.c+

+.moderated. Se non ce la fa lui, figuriamoci gli altri.



Su D non so rispondere perchè non l'ho mai usato davvero e non lo

seguo, non saprei nemmeno dire se e quanto lo trovi complesso.

Immagino che l'essere partiti buoni 20 anni dopo rispetto al C++ abbia

insegnato qualcosa sul design e soprattutto l'abbia portato ad essere

più unitario e meno "una confederazione di linguaggi". Io dico che non

bisogna sottovalutare nemmeno per un istante il fatto che uno sia

partito come "C with Classes" e l'altro abbia guardato 20 anni dopo al

C++ pensando: "che casino! vediamo cosa tagliare, cosa ricucire, cosa

aggiungere...". Sarebbe comunque un torto verso Stroustrup, con cui

non sono daccordo nemmeno sul contenuto del suo libro da CS1 che

insegna a programmare, ma che resta pur sempre un visionario.



Alla fine mi hai ricordato di D e che ho lasciato in sospeso di farne

la conoscenza, thx :).


 più i draft ISO disponibili gratuitamente in rete e si è a posto. :) 

Grazie, saper dove trovare qualcosa di valido quando serve è molto utile;

nel tempo mi son fatto una piccola "kl" che tra l'altro tiene traccia dei

vari testi "utili" scovati o sentiti, è stata ed è tutt'ora un po' la mia

ancora di salvezza per l'autoapprendimento da non finire come troppo 

spesso vedo (e talvolta, sigh, faccio) a copiare soluzioni da stackexchange

servefault&c!


 che ai più sembri sempre così difficile fare la cosa giusta. 

Con me sfondi una porta aperta, la mia "aspettativa minima" ed il relativo

adeguamento dei programmi è basata su quel che ritengo si possa fare con

chi arriva formato da una certa scuola, se l'input è diverso l'asticella 

dell'output potrà posizionarsi ad altro livello, il ribasso è dovuto al

fatto che non vedo possibile per quanto sia necessaria una riforma valida

delle scuole elementari/medie/superiori, all'università avendo sinora una

certa libertà si potrebbe forse tentare una puntata al ribasso con dei

risultati "spendibili" ad un livello pur molto inferiore a quel che si

auspica normalmente...



Quel che voglio tagliare "della matematica" non sono le equazioni ma la

mania di parametrizzare a livello numerico ogni cosa: non penso abbia

alcuna possibilità di successo organizzare l'istruzione come un'azienda

con manager che stilano diagrammi di Gantt a manetta e misurano con un

qualche modello i risultati di mese in mese di anno in anno. Non penso

un quiz sia più democratico e difficile da sabotare di una commissione

d'esame che dialoga liberamente con un candidato ecc. Questa "matematica"

la vorrei abolire insieme a coloro che la applicano!



Il discorso realtà-modello di qualche paragrafo sopra è proprio questo:

oggi si pensa che una metrica, ovvero misura, sia La Realtà® e ci si

mette a testa bassa a trovare un modo di far aumentare o diminuire una

data variabile nel modello non comprendendo manco che il modello oltre

ad essere un pelo presuntuoso non è la realtà e che forse sentire chi

nel settore ha lavorato per anni *prima* di costruire il modello forse

porta a risultati migliori. 



Spesso dico che bisogna ripartire dal foglio bianco ma non nel senso di

buttar via ogni cosa, esperienza e conoscenze pregresse incluse,

semplicemente nel senso che il livello di complessità attuale è tale per

cui elucubrazioni mentali nel tentativo d'aggiustarlo sono solo rami

secchi dove si perde tempo e denaro. 



Per esempio l'ITIL la vedo come l'apoteosi dell'idiozia: se ho bisogno

di applicare delle linee guida perché non sono in grado di crearne di

mia sulla base di esperienze, teorie e quant'altro che ho studiato e mi

son fatto allora sono un operaio modello Ford. Da quel livello no mi

schiodo e se tale livello è sopra l'ultima ruota del carro vedo la spia

"catastrofe" accesa al punto da bruciarsi...


 la conoscenza, thx :). 

Sinora l'ho solo di sfuggita guardato ma mi stà interessando per un paio

di aspetti (concorrenza e compilazione), più o meno punta a risolvere gli

stessi problemi del C++ che vorrebbe risolvere il D, ha una sintassi IMO

assai meno digeribile del D ma lo sforzo a naso vale la pena: Go by Google.



Se hai voglia c'è un paradigma completamente diverso dal "classico" a tema

smp/calcolo distribuito :-)



La voglia c'è sempre, ma conosco abbastanza bene CSP e la process

algebra già da tempo per la verità (ho anche studiato Limbo e sue

applicazioni con un piccolo gruppo di lavoro) :)



Nota che molte, troppe cose oggi sembrano "novelties" (non è per nulla

una frecciata verso Go, che pure apprezzo non poco, intendiamoci) ai

più per il semplice motivo che tanti lavori di gente come Milner e

Hoare (e relative realizzazioni pratiche, già occam ad esempio è roba

anni '80!) vengono solo marginalmente citati quando invece ci si

dovrebbe ragionare su, ma sul serio. Peccato davvero :/



Personalmente, lavoro in e su STM già da anni, sia distribuito che

non. Ma le domande in questi ambiti sono ancora tutte che belle aperte

(l'unica certezza da tutti, è che un modello prettamente imperativo di

default ha già fallito da tempo).


 servefault&c!



E' un gran bel libro davvero, C89 e C99 trattati in modo completo e

chiaro. Mi pare abbia anche una piccola sezione per le differenze tra

K&R C e C89, nel caso servisse dare un'occhiata a codice piuttosto

"legacy" (c'è un sacco di gran bel codice scritto in K&R C ancora in

giro, soprattutto sistemi operativi per chi è interessato). Fermo

restando che leggere il K&R 2nd ed. e (soprattutto!) farne gli

esercizi resta un must, il King è altrettanto un must (ce ne sono

altri, Hanson, van der Linden, Koenig per citarne qualcuno al volo) se

l'obiettivo è essere forti in C.


 crisi economica!



Non sono daccordo, ma trovando noiose le liste di nomi passo :)



<snip> sul resto ma ho letto tutto, solo non saprei cosa rispondere

nello specifico sutante questioni prettamente più italiane o su alcuni

degli aneddoti che riporti.

Il discorso sulla matematica mi piacerebbe approfondirlo ma non si

parlerebbe davvero di nulla di nuovo alla fine. Restando più IT

invece, l'ultimo Computer Science Curricula[*] è fresco fresco e

contiene molto su cui anche il più disinteressato tra i professionista

dell'informatica potrebbe un pò riflettere e discutere.



[*] 
http://ai.stanford.edu/users/sahami/CS2013/



 anziché dai mattoni...



Il C è considerato (giustamente) come "fondazionale" perchè è una

potente e unificante astrazione sul modello di von Neumann

sottostante. Non puoi certo dire lo stesso dei _vari_ assembly.


 programmazione imperativa/procedurale: modula-2



Come mai? A parte certi ottimi libri tipo il Reasoned Programmer (che

mi pare presentava Modula-2 e Miranda) io non avrei dubbi nel

preferirgli Oberon 2.


 mucchio selvaggio occorre smarcarsi, perché altrimenti è dura andare avanti.



Ma in Italia c'è davvero poca offerta negli ambiti dove C o C++ sono

piuttosto comuni o effettivamente mancano anche un pò i candidati

giusti? "Fuori" ad esempio c'è una fame piuttosto consistente di gente

che possa metter mano a software di sistema - visto spesso tante

posizioni scoperte, mi dicono, da secoli.


 Nota che molte, troppe cose oggi sembrano "novelties"

Ahimé ti straquoto, lo vedo a livello "idee rivoluzionarie" a tema os che

son peggiori implementazioni parziali di idee già implementate molto meglio

e molto più efficacemente in passato... È sempre la storia che non si studia

né si considera...


 ce ne sono altri, Hanson, van der Linden, Koenig per citarne qualcuno al volo

Ignoti: ho letto molto velocemente 21st Century C di Ben Klemens e Mastering

Algorithms with C di Kyle Loudon e non proprio dedicato al C Introduction to

Parallel Computing di Petersen e Arbenz ma considera che il mio livello a tema

sviluppo software è grossomodo quello di una triennale moderna :-(


 professionista dell'informatica potrebbe un pò riflettere e discutere.

Ci darò un'occhiata :-)


 "pseudocodice  eseguibile" è oro. 

Oh! Finalmente mi sento meno solo!


 Oh! Finalmente mi sento meno solo!



Adesso non cantare vittoria troppo presto ;) Io ho iniziato imparando

parallelamente il C e Scheme, concentrandomi sicuramente più sul C

perchè era il linguaggio di Unix e a quello ero interessato. Ma anche

se non sapevo spiegarmi il perchè, avevo in qualche modo intuito che

la loro diversità era la chiave di qualcosa di... molto molto figo :)



La scelta che preferirei, comunque, resta quella di partire da ML

perchè:



- puoi esprimere facilmente buona parte dei concetti matematici

appresi fino a quel punto (e che sono una base comune sicura tra i più

disparati sistemi d'istruzione, a differenza del pensiero algoritmico

imperativo);

- gli algoritmi risultano chiari e i concetti da insegnare per

esprimerli pochi e potenti;

- è ideale per trattare la logica, dalle basi della proposizionale al

theorem proving (a volte certi interlocutori mi costringono a ripetere

a voce alta: "l'Informatica, avete presente?, quella roba sconosciuta

che nasce dalla Logica Formale..." anche quando proprio non dovrebbe

essercene bisogno);

- ci tratti le strutture dati fondamentali come i trees con una

chiarezza e praticità disarmante.



Certo anche Scheme ha parte di questi stessi vantaggi ed altri ancora,

ma gli preferisco ML comuqnue - per me il punto di svolta è stato

l'aver letto "ML for the working programmer" di Paulson (e i libri di

Wadler e Bird). Ma tant'è. Mi "consolo" nell'essere in buona compagnia

delle univ. di Cambridge, Oxford, Edinburgh, etc. e anche diverse

italiane, che ne fanno buon uso prima e dopo l'intro alla

programmazione :)


 sviluppo software è grossomodo quello di una triennale moderna :-(



Ma che importa adesso di questa triennale? Credi che dal vecchio

ordinamento uscissero tutti McKusick e Cutler?

Se sei interessato (prima hai scritto che non sviluppi, ma mi pare che

l'affermazione sia piuttosto in contrasto con gli interessi che sembri

dimostrare: boh!), lascia perdere i libri non c'è male o quelli così e

così e parti dagli imprescindibili e dal codice di uno Unix (consiglio

NetBSD).


Il giorno mercoledì 2 gennaio 2013 01:08:01 UTC+1, Endi Uorrol ha scritto:



Al volo senza pensarci troppo:

C#

VB.NET


C++

ASP.NET


VB

ASP

Pascal

PHP



Al3x



PS: sviluppo al 90% in C++.NET :P


 a quando si parla in due o tre nulla cambia...



Au contraire, è un discorso su come viene insegnato. Anche sul

parlarne in due o tre, si sbaglia a pensarla così. Insegnare bene la

matematica è compito e responsabilità anzitutto del singolo

insegnante. Anche all'interno di programmi più o meno adeguati, più o

meno moderni c'è la possibilità di spiegare nella maniera "meno

matematica" e logica possibile anche le nozioni più basilari. I corsi

sulla didattica dei vari dipartimenti sono necessari ma non

sufficienti, solo il singolo coscienzioso spende le energie

sufficienti per assicurarsi che quello che insegna sia corretto,

preciso e coerente nell'ambito della matematica stessa.


 insegnante.

Hem, mi sa che non ci siamo capiti: non critico "la matematica" né in parte

il modo in cui viene insegnata critico il fatto che oggi si pensi di poter

governare ogni complessità con metodi "matematici/formali" al posto del

non formalizzabile ragionamento/intuizione/convinzione del singolo manager

o docente o in genere persona. Critico che si misuri lo studio in ore, il

concetto di debiti e crediti, i quiz ecc. Per quel che mi riguarda ogni 

esame dovrebbe essere *solo* pratico (progetto, saggio, esercizio personale

ideato dallo studente con lo scopo di dimostrare le sue competenze) ed orale.

Gli esercizi o ancor peggio i quiz la media orale/scritto ecc per me sono

IDIOZIE non utili a garantire un giudizio imparziale ma utili solo a riempir

la bocca di fumo e a permettere ad incapaci di andare avanti od occupare un

certo posto di lavoro.



In estrema analisi critico il pensiero anglosassone che ritengo del tutto

FALLIMENTARE.



Ti faccio un esempio: un ingegnere informatico per me deve essere in grado

di vedere un ponteggio e valutare a spanne se è fatto bene o meno, se il

"telaio reticolare" è ben calcolato oppure no; deve saper analizzare una

proposta commerciale che nulla c'entri col suo lavoro e a spanne valutare

se può funzionare o meno; deve valutare quanto ci vuole e che strumenti

d'uso comune servano a pulire una certa macchia sul pavimento ecc. In altri

termini un INGEGNERE deve SAPER USARE L'INGEGNO. Molto prima di conoscere

il singolo formalismo sviluppato con lavoro e sudore in anni. Un ingegnere

non deve essere una macchina umana che ha metabolizzato un manuale, deve

essere una persona senziente, autonoma, capace di astrazione ed inventiva.

Il lavoro dei suoi colleghi e di tanti altri gli serve conoscerlo ma non

masticarlo e sputarlo, per questo c'è il computer, gli serve la testa, la

visione d'insieme, la capacità d'identificazione del core di qualcosa dal

resto accessorio. L'opposto del nozionismo attuale, della mania di avere

specialisti dell'unghia del mignolo del piede sinistro per capirci.



Ancora in sintesi: voglio da un'ingegnere la capacità di spiegare ad un

avvocato qualsiasi il significato di un integrale multiplo o di un qualche

modello di programmazione concorrente ben prima di saperlo risolvere, per

certe cose ci sono i CAS, per i concetti ci sono i neuroni, se non hai

questi sei solo un computer inefficiente, costoso e delicato...



Questa è la "matematica" di cui parlo, quella del project management, della

ITIL&c, dei diagrammi di Gantt e Pert, dei grafici che coprono con un certo

manto di scienza l'ignoranza de facto nella maggior parte dei casi.


 dimostrare: boh!),

Sono interessato allo sviluppo ma non sviluppo attualmente altro che

script o piccoli software, questi ultimi tutti del genere utility personali

o richieste di qualche amico/parente. Quando ho tempo mi piace studiare,

ed in genere cerco di prepararmi in tutto ciò che mi piace o che può 

riguardarmi, tutto qui.


possibile che cobol sia al 24 posto e vbscript non sia nemmeno tra i 

primi 50 ? ci sono ancora milioni di siti nel mondo in .asp (con 

vbscript) e "alice" o Q sono piu' diffusi ?