Newsgroup: it.comp.dotnet
Titolo: Ad ogni linguaggio il suo compito

Salve,
.NET supporta tanti linguaggi ma stando anche agli esempi di codice che si 
trovano su MSDN, mi pare di capire che quelli "ufficialmente supportati" da 
Microsoft siano:
C#, C++, 
VB.NET
, F# e JScript.
C# � il linguaggio principale che consente di fare quasi tutto.
C++ consente di scendere pi� a basso ma in concreto, prestazioni a parte, 
quando � necessario?
Mi pare che i driver (non i  firmware) adesso si possano scrivere anche in 
C# com UMDF
VB.NET
 mi pare che invece possa essere pienamente sostituito da C#
F# dovrebbe servire nei casi in cui � preferibile un linguaggio funzionale.
E quali sarebbero questi casi?
Inoltre mi pare che anche C# stia iniziando a supportare tale paradigma
JScript oltre a sostituire JavaScript nella creazione di pagine web 
dinamiche lato client, in cosa � usato?
Credo di averlo visto anche nella scrittura di gadget per la sidebar.
Insomma questi 5 linguaggi fornisco un set completo per il programmatore?
Saluti 

 Insomma questi 5 linguaggi fornisco un set completo per il programmatore?
A mio avviso la conoscenza dei linugaggi è la parte minimale.
Parlndo di developer (e non di architect), la cosa più importante e 
complessa è quella di conoscere le tecnologie, e saperle amalgamare.
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/

 complessa è quella di conoscere le tecnologie, e saperle amalgamare.
Grazie per le risposte! 

 complessa è quella di conoscere le tecnologie, e saperle amalgamare.
FWIW, su questa consentimi di dissentire: per me un developer deve
sapere appunto "sviluppare", il che vuol dire che gli occorre non solo
un base tecnica ma anche e ancora prima una base concettuale,
altrimenti *quali* problemi potra' mai risolvere? E' solo dopo aver
acquisito quel bagaglio fondamentale, cioe' quel minimo di
autoconsapevolezza professionale, che eventualmente ci si specializza:
per esempio sulla parte architetturale/tecnologica, o al contrario
sulla parte concettuale/di analisi.
(Oppure, caso molto piu' frequente, uno lascia perdere e si mette a
fare il development-/product-/team-manager, ruoli per i quali e'
richiesto *non* avere competenze tecniche, bensi' solo psico-socio-
markettare... ovvero il global sell-and-buy, ovvero la coperta psudo-
friendly del global kill-and-lie. Con buona pace per le prossime
generazioni.)
-LV

 sulla parte concettuale/di analisi.
Credo che Raffaele abbia affermato quanto detto prima, perché .NET fornisce 
talmente tante tecnologie che la conoscenza del linguaggio passa in secondo 
piano. 

 piano.
Di nuovo, e per quel che vale: dissento da quel punto di vista.
-LV

 (Ed e' solo un esempio fra mille.)
Almeno un framework (ad esempio QT) è sottointeso. 

 (programmazione concorrente)?
Diciamo che stanno nello stesso ambito. :-)
Cosa intendi per "sostituire"?
Ciao,
Giulio
-- 

 (programmazione concorrente)?
Si ma fa molto di più perché F# è stato pensato per essere "realistico" 
cioè supporta anche la programmazione imperativa (C# like) che è 
indispensabile per usare le classi di base.
Una applicazione reale+complessa difficilmente riuscirai ad esprimerla 
con uno dei linguaggi di cui sopra.


 generazioni.)
LOL, quoto, ma questo lo fa lo sviluppatore di fine carriera (che non 
corrisponde necessariamente all'età che ha).


 corrisponde necessariamente all'etï¿œ che ha).
Io ho fatto quel lavoro lï¿œ quando avevo 26-27 anni. Non dico un anno passato 
ad usare soltanto Microsoft Project (e Word, Excel, ..), ma quasi (buona 
parte del resto lo passavo a cercare di sincronizzare, convincere e mettere 
d'accordo le varie "risorse", umane o meno). Poi, prima che riuscissi ad 
offuscare abbastanza quell'esperienza nel mio CV, me l'hanno offerto altre 
volte (l'ultima volta una multinazionale, LOL).
Comunque un'esperienza, almeno so che se proprio non mi volesse piï¿œ nessuno 
come sviluppatore, un altro lavoro lo so fare, ed anche abbastanza bene :))
-- 
ale
http://ale.riolo.co.uk
 

 Cosa intendi per "sostituire"?
Se F# va bene per fare gli stessi compiti 

 uno dei linguaggi di cui sopra.
Infatti quelli mi sembrano piï¿œ "accademici". 

 In ambito .net, vale lo stesso discorso con clr, wcf, wf, wpf, etc. etc.
Fissato un linguaggio, (sotto)intendevo anche il "corredo tecnologico" 
necessario (conoscenza dell'OS su cui sviluppi, un certo livello di problem 
solving algoritmico, etc..). 

 come sviluppatore, un altro lavoro lo so fare, ed anche abbastanza bene :))
:) intendiamoci, non c'è nulla di male a fare un mestiere diverso ... 
nello sviluppo software non bastano solo i dev.
L'unica figura che negli anni e in tutta solitudine si è costruita una 
cattiva reputazione sono i markettari :)


 solving algoritmico, etc..).
ok, ma tieni conto che tipicamente il developer cresciuto nelle 
universitï¿œ non va oltre al linguaggio. Per questo ï¿œ una distinzione 
importante di cui tenere conto.


 nello sviluppo software non bastano solo i dev.
Ma la differenza tra
software engineer e software architect quale sarebbe?
Tu sei qualcuna di queste ? :P 

 tenere conto.
Io definisco programmatore solo chi è appassionato, non chi ha superato 
esami perché necessari alla laurea e/o chi svolge tale lavoro solo perché 
prima o poi vuole raggiungere qualche ruolo dirigenziale in cui non vedrà 
più una riga di codice. 

 Tu sei qualcuna di queste ? :P
Sei in vena di domande rischiose eh :D
Io di fatto svolgo entrambi i mestieri a seconda di quello che serve al 
cliente. A gennaio sono trent'anni che scrivo codice (ero ragazzino 
quando ho iniziato, giusto per non darmi del vecchio :D) e ancora mi 
piace farlo, perciò mi sento molto vicino alla prima delle due.
Ovviamente con il passare del tempo acquisisci esperienza e ti trovi a 
svolgere anche il secondo senza che qualcuno ti assegni il titolo di 
lup.mann. sul biglietto da visita ;-)


 riga di codice.
vero, ma anche chi ï¿œ appassionato ed ï¿œ appena uscito dall'universitï¿œ a 
volte si lascia prendere dall'euforia ... ;)


 volte si lascia prendere dall'euforia ... ;)
Chi pensa che con le sole conoscenze acquisite all'università possa 
sviluppare programmi è un po' come il neopatentato che pensa di poter 
correre in F1. 

 Una volta acquisite queste conoscenze ... non bastano.
Cosa manca ancora a parte conoscenze specifiche che riguardano l'ambito in 
cui il software dovrà operare e che il programmatore non può conoscere a 
priori ma sarà uno specialista a fornirle (tipo conoscenze contabili per un 
programma di contabilità)? 

 in F1.
:)


 programma di contabilità)?
L'esperienza ti insegna tante cose che non si imparano diversamente. 
Questo vale sia nella fase progettuale che nello scrivere codice. 
Potremmo metterci a fare una lunga lista ma non sarebbe mai esaustiva. 
Ogni mestiere ha le sue malizie, ricordiamoci che siamo artigiani e il 
mondo industriale è ancora lontano.


 e il  mondo industriale è ancora lontano.
E cosa farebbe il programmatore che lavora con un approccio industriale?
Scriverebbe programmi in serie? :D 

 Se F# va bene per fare gli stessi compiti
Non saprei.
Erlang e Lisp sono entrambi linguaggi funzionali ma... li useresti per 
le stesse cose? ;-)
Ciao,
Giulio
-- 

 stesse cose? ;-)
L'idea era sempre quella di individuare un numero di linguaggi piů basso 
possibile per poter fare piů cose possibili.
Magari F# (e a quanto dice Raffaele sembra di si) consente di lavorare negli 
ambiti tipici di quei linguaggi funzionali. 

 programma di contabilit�)?
Lo sviluppo di un prodotto SW è qualcosa di più multidisciplinare di 
quanto spesso si creda. IMVHO il successo di un prodotto dipende sia da 
COME fa quello che deve fare (responsabilità di sviluppatori, tester, 
solution architect e tutta la roba da nerdoni che ci piace tanto), ma 
anche da COSA faccia. E l'analisi del dominio non è detto che richieda 
competenze da sviluppatore (e affini). L'esempio della contabilità che 
hai citato è lampante: mi reputo uno sviluppatore mediocre, ma non ho 
idea di cosa sia una fattura. :-) Come la mettiamo?
Ciao,
Giulio
-- 

 mettiamo?
Stavo appunto escludendo lacune conoscitive di tale tipo :) 

 cattiva reputazione sono i markettari :)
E i piemme? :-)
Ciao,
Giulio
-- 

 qualità del codice (soprattutto in termini di manutenibilità).
quoto
-- 
.A
GUISA - 
http://www.guisa.org
UGIdotNET - 
http://www.ugidotnet.org
Read my blog at: 
http://blogs.ugidotnet.org/pape

 E i piemme? :-)
Quale dei due? :)
Il program manager ï¿œ quello buono :D
Il product manager ï¿œ il tecnico commerciale e si salva a pelo pelo ... 
sempre che sappia mantenere un briciolo di credibilitï¿œ, cosa che in 
questo periodo ï¿œ una dote moooolto rara :)
Ciao


 Scriverebbe programmi in serie? :D
Un assemblatore di moduli prefabbricati, con una limitata possibilità 
di fare danni ... l'equivalente dell'operaio sulla catena di montaggio.
Oggi qualsiasi linguaggio GPL (General Programming Language) è 
potenzialmente distruttivo.
I DSL (Domain Specific Language) invece vanno nella direzione 
dell'industrializzazione.
E qui il discorso diventa superlungo ...


 accettare il fatto e rimboccarsi le maniche.
Vivo e lavoro a Londra da quasi 4 anni, ed e' esattamente la stessa
cosa. L'unica differenza e' che qui sono tutti un po' piu' onesti e
tranquilli, ovvero non ti provano ad in**lare proprio ad ogni angolo
di strada come avviene regolarmente da noi, il che ovviamente e' gia'
sufficiente a fare *tutta un'altra qualita' della vita*. Ma per il
resto e' esattamente uguale: e d'altra parte non potrebbe essere
altrimenti, visto che questo e' proprio il centro di emanazione dello
schifo globale, altrimenti detto la capitale di questo impero di
babbuini idioti e mortali. Non c'e' produzione, non c'e' investimento,
non c'e' programma ne' futuro, non c'e' cultura, non c'e' arte ne'
spirito, ne' popoli o tradizioni, ne' niente di niente di niente di
niente, manco la musica c'e' rimasta: ormai e' solo il produciti-
fottiti-crepati di un pianeta di orfani senza passato ne' futuro.
-LV

 corrisponde necessariamente all'età che ha).
Da queste parti (Londra e dintorni) ormai a dirigere gli uffici di
produzione software ci mettono gli sbarbatelli neo-laureati in
computer science. Ti lascio immaginare il delirio: permanent
emergency! Oltre al permanent asilo nido nonche' la nooooia, mortale
come tutto di questo impero. (Se poi sono multinazionali, ci mettono
proprio gente che meno ne sa e ne vuole sapere, piu' la mettono a
dirigere.)
D'altronde, saro' presuntuoso, ma e' anche grazie al sottoscritto se
il concetto di produzione software ancora conserva qualche barlume
della sua anima ingegneristica. D'altronde basta mezzo cervello per
svergognare questa banda di babbuini. E non ho nessuna intenzione di
tirare i remi in barca.
-LV

 Vivo e lavoro a Londra da quasi 4 anni, ed e' esattamente la stessa cosa.
In quali Paesi europei un programmatore se la passa meglio secondo voi? 

 E qui il discorso diventa superlungo ...
Sei a favore della super specializzazione? 

 sommato non hai neanche tutti i torti...
Io sono convinto che la capacità di modellazione e problem solving 
algoritmico sia la cosa più importante e anche quella che deve essere innata 
nell'individuo, e che l'esperienza può solo potenziare, e non creare dal 
nulla. 

 creare dal nulla.
-1
secondo me di innato non c'è proprio niente: è solo il duro studio a
fare la differenza (quindi, conta anche se e come si è fatta
l'università, ovviamente)... e poi mi pare che già uno sicuramente più
intelligente di me una volta ha detto che "Genius is 1% talent and 99%
percent hard work...".

 percent hard work...".
A parte che quei riferimenti in percentuale credo vadano considerati 
diversamente.
E anche se effettivamente fosse l'1%, è una componente "illuminante" che ti 
da la possibilità di sfruttare molto meglio il restante 99%. 


Personalmente ritengo tutta l'europa allo stesso livello.
Non che altrove esistano i paradisi ma per quello che ho visto qui 
siamo al minimo.


 Sei a favore della super specializzazione?
Sono due cose differenti che risolvono problemi diversi.
I linguaggi GPL sono orizzontali e più potenti
I linugaggi DSL sono verticali, immensamente meno potenti e risolvono 
problemi molto specifici.
Il problema oggi è di capire quando diventa vantaggioso investire sullo 
sviluppo di un DSL (ma è un argomento di cui si parla troppo poco e che 
ha ovviamente dei costi)


 sommato non hai neanche tutti i torti...
Ho parlato di tecnico perchï¿œ si parlava delle competenze di un 
developer e quali linguaggi dovesse conoscere. Come conseguenza ho 
fatto una distinzione sul termine 'linguaggio'.


 questo periodo è una dote moooolto rara :)
Onestamente non ho mai capito la differenza. :-)
Ciao,
Giulio
-- 

 fottiti-crepati di un pianeta di orfani senza passato ne' futuro.
Quoto. La mentalità da "capitalismo terminale" è quella che ti forza a 
ragionare solo sul breve termine. E questo - IMVHO, sia chiaro - si 
riflette anche negli attori coinvolti nello sviluppo SW: non me ne frega 
nulla di avere un sw manutenibile, leggibile, elegante, con un sorgente 
*BELLO* da leggere, con una suite di test automatizzati da paura e ben 
documentato *MA* mi interessa solo che funzioni. Che poi, 'sto 
"funzioni" non significa nulla, preso così (e questo giusto per tornare 
IT, anche se devo dire che condivido la tua analisi socio-economica su 
tutta la linea).
Ciao,
Giulio
-- 

 la tua analisi socio-economica su tutta la linea).
Ciao Giulio,
Mi preme una precisazione. Pur condividendo il fatto che il cliente 
guarda solo al risultato, dissento dalle motivazioni che portano a 
questo.
Eleganza, manutenibilità, documentazione sono tutti *valori* importanti 
di un progetto. È semplicemente per ignoranza che non vengono 
considerati.
Come conseguenza la mancanza di questi elementi si rivelano dei grossi 
costi "nascosti" che ritornano come boomerang.
Qui la "La mentalità da 'capitalismo terminale'" secondo me non c'entra 
proprio nulla, è solo pura ignoranza e da un punto di vista 
imprenditoriale ci stanno pure perdendo.


 Onestamente non ho mai capito la differenza. :-)
http://stackoverflow.com/questions/1150982/program-manager-vs-product-manager
:)


 imprenditoriale ci stanno pure perdendo.
Certi "costi" li vedi solo alla lunga, mentre i costi della qualita',
per quanto alla lunga sono guadagni, nell'immediato sono appunto
costi, ed e' *solo come tali* che vengono rubricati.
E' chiaro che sono piu' miopi di un branco di talpe orbe dalla
nascita, ma e' anche chiaro che non c'e' piu' spazio per fare
nient'altro, a meno di non fare prima una rivoluzione socio-politico-
economica per davvero (e spedire un bel pacco di gente nello spazio
siderale, alla conquista della polvere di stelle che gli si accumula
nel cranio vuoto).
D'altronde oggi gli unici affari che pagano sono appunto la truffa e
lo sfruttamento altrui (e chi pensa altrimenti e' un ingenuo nella
migliore delle ipotesi!). I prodotti *non devono* funzionare... che e'
gia' cosi' da quasi mezzo secolo per quanto riguarda la produzione
industriale di massa, ora l'unica non tanto sostanziale differenza e'
che si e' passati alla colonizzazione e allo sfruttamento
dell'immaginario... sempre e rigorosamente con prodotti, idee,
tecniche, teorie, storie e filosofie intrinsecamente false e fallate,
in modo che questo stupido uomo-mai-umano mai e poi mai potra'
risvegliarsi dal suo suoi sogni bagnati.
E la nostra economia uccide; e la nostra medicina uccide; e la nostra
politica uccide; e la nostra cultura uccide; e la nostra storia
uccide; e la nostra liberta' e' davvero l'ultima delle beffe in testa
a mezzo pianeta che muore di sete e fame e ad un altro mezzo che fa la
guerra a tutto cio' che si muove per un pezzo di fica in piu'.
E tu ancora mi stai a che il capitalismo terminale non c'entra e che
e' il cliente ad essere poco lungimirante... altro tema peraltro gia'
affrontato.
Vabbe', ciao!
-LV

 affrontato.
Visto che i vantaggi economici a lavorare bene ci sono, il problema non 
sta nel capitalismo.
Con la stessa logica c'è gente che non spende in unità di backup, e 
questo è capitalismo o ignoranza ...
Mo' stacco e faccio a tutti i più sinceri auguri di buone feste.
Ciao


 imprenditoriale ci stanno pure perdendo.
C'entra perché, dal punto di vista del fenomeno socio-economico, il 
"breve periodo" è bello che passato. Ma all'orizzonte non si vedono 
cambiamenti radicali.
Ciao,
Giulio
-- 

 questo è capitalismo o ignoranza ...
Tutte e due le cose: comprare una unità di backup *OGGI* mi costa 
troppo. Peraltro non è edtto che domani la mia azienda ci sia ancora. :-/
Ciao,
Giulio
-- 

 il problema non sta nel capitalismo.
Come no, tutta colpa del... "cliente".
Ariciao: al candore.
-LV

 un progetto. Č semplicemente per ignoranza che non vengono considerati.
Ma l'azienda che sviluppa che si deve occupare di tutto questo.
Il cliente si fa guidare. 

 Peraltro non è edtto che domani la mia azienda ci sia ancora. :-/
Esistono anche realtà diverse, toccate con mano.


 di cui tu parli non esiste piu' e a rigore non e' mai esistito.
Io sono testimone che esiste ancora.


 Il cliente si fa guidare.
Non sono daccordo. Il mercato è fatto di richiesta e offerta.
Se il cliente non vede il vantaggio (perché non ha la cultura per 
capirlo) di una specifica, è altamente probabile che venga depennato 
dai requisiti.
Finché la cultura informatica non si diffonde a tutti i livelli non ci 
sarà futuro migliore di quanto vediamo oggi.


 sarà futuro migliore di quanto vediamo oggi.
In effetti quando si acquista bisogna sapere quello che si compra, anche se 
si tratta di soluzioni informatiche.
Però non credo si possa pretendere che il cliente chieda informazioni anche 
su come il codice del suo programma sarà scritto, sulle ottimizzazioni 
utilizzate, sul come sarà gestita la memoria, etc...
Penso che il massimo che gli si possa chiedere è una conoscenza sufficiente 
per capire che una determinata tecnologia, anche se costa di più sul 
momento, porterà dei vantaggi nel tempo. 

 porterà dei vantaggi nel tempo.
Quando un imprenditore compra una nuova macchina tessile, stai sicuro 
che sa bene quali parametri valutare.
Prima o poi accadrà anche nel nostro campo (in altri paesi già accade e 
in alcuni ambiti già sta accadendo anche qui).


 utilizzate, sul come sarà gestita la memoria, etc...
E hai ragione: in letteratura si distinguono i requisiti espliciti da
quelli impliciti.
A chi non lo ha, consiglio di procurarsi un buon manuale di ingegneria
del software: meglio se scritto entro e non oltre meta' degli anni
'90, altrimenti non c'e' garanzia...
-LV

 in alcuni ambiti già sta accadendo anche qui).
Il nostro campo semplicemente *non* e' la produzione manifatturiera
(con buona pace fra l'altro del Lean e di tutte le altre amenita' del
genere), e semmai forse un giorno finalmente accadra' che gli
operatori del nostro settore (*noi*) ci risvegliamo dal nostro letargo
auto-indotto e ci *ricordiamo* che esistono parametri di complessita'
e virtualita' tali per cui certi paragoni sono semplicemente e del
tutto *sbagliati*.
Visto che siamo praticamente in tema, ne approfitto anche per
commentare l'ultimo post di luKa sul blog di UGI [*], che' se provo a
commentare li' mi censura. Il mio commento:
   "Ma tu guarda che team di sfigati: la classica situazione da tre
operai e quattro livelli dirigenziali..."
-LV
[*] 
http://blogs.ugidotnet.org/luKa/archive/2010/12/19/the-managers-role-in-agile-again.aspx

 Il nostro campo semplicemente *non* e' la produzione manifatturiera
Non è questo che ho scritto.
L'imprenditore tessile è un esempio di un possibile cliente di un 
software. Arriverà il giorno che comincerà a capire molto bene la 
differenza tra due progetti sofware apparentemente uguali.
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele