Newsgroup: it.comp.programmare
Titolo: Conoscenze che dovrebbe avere uno sviluppatore...

Ciao,
ho provato a stilare un elenco delle conoscenze
che uno sviluppatore Java junior dovrebbe avere
con il livello di conoscenza...:
Ingengeria del software (livello base)
UML (liv. base)
Java (liv. medio), JSP (liv. medio)
XHTML (liv. medio alto), CSS (liv. medio alto)
XML (liv. medio alto)
Javascript (livello base), AJAX (liv. base)
Teoria dei database relazionali (liv. medio)
SQL (liv. medio)
Ci manca qualcosa?
Chissà quanti anni ci vorrebbero per conseguire
tutte 'ste conoscenze...

 tutte 'ste conoscenze...
infatti, i programmatori migliori sono gli elfi (anche se un po' se la
tirano)

 Ci manca qualcosa?
Saper programmare!


Spiegati meglio.


Non e' la conoscienza di un linguaggio che fa il programmatore.
Il linguaggio e' solo uno strumento.
Se sai programmare, la grammatica del linguaggio fai in fretta ad
impararla, che poi adesso ci sono pure strumenti di sviluppo che ti
propinano classi, proprieta' e metodi belli pronti.
Se non sai programmare, puoi conoscere perfettamente la sintassi del
linguaggio, ma partorirai solo aborti.

 SQL (liv. medio)
E perchï¿œ mai, di grazia, uno sviluppatore Java dovrebbe
conoscere XHTML e XML?
E cosa c'entrano Javascript, SQL e AJAX con Java,
sempre di grazia?
E che vuol dire "livello medio, basso, alto"? Cos'ï¿œ, un gioco di ruolo?
Mi sa che non hai le idee chiare su tante cose... :-\

 Non e' la conoscienza di un linguaggio 
Un velato gioco di parole?

 sempre di grazia?
Mi hai tolto le domande dalle dita.
In particolare cos'è la conoscenza medio-alta di XML?

 In particolare cos'è la conoscenza medio-alta di XML?
Presumo intendesse XPath, XSL, XSLT, XSD, XQuery e menate varie che
vengono, oggettivamente, usate piu' in ambiente java che python.

 vengono, oggettivamente, usate piu' in ambiente java che python.
Sia pure come dici, ma uno potrebbe ottimamente sviluppare e programmare 
in Java senza nemmanco sapere un'acca di tutto ciò. Per dire, ODBC si 
può usare anche in Java, per cui conoscere SQL per lavorare con i DB non 
è necessario.
Ma il punto, come diceva Montaruli sopra, è che anche posto che tu non 
sappia SQL, XML o che azz ti chiedono di sapere, la sintassi si impara 
in un attimo. Quello che NON si impara in un attimo è la capacità di 
analisi, la capacità di progettazione. La capacità di lavorare in un 
team. La maturità di non prendere scorciatoie pericolose (copiaincollare 
codice altrui, 
p.es
.) Se uno non ha quelle, può conoscere tutte le 
tecnologie del mondo ma farà sempre porcate.
Senza contare che di tecnologie, sigle e siglette ce ne sono millemila e 
tante ne nascono (e muoiono) ogni mese, a volte solo per moda: anche se 
le conoscenze di un programmatore sono "allo stato dell'arte" ora, non 
lo saranno più fra uno o due anni, se lo stesso non si aggiorna (e io 
datore di lavoro gli darò il tempo e il modo di aggiornarsi? Col 
cavolo... che si arrangi!).
Quindi, se io dovessi cercare uno sviluppatore vorrei sapere in che modo 
analizza e progetta, più che di sapere quante sigle può snocciolarmi. 
Quando avrà bisogno di usare certe tecnologie le imparerà senza 
problemi, se è bravo... se è una rapa potrà pure conoscere le tecnologie 
giuste ma non combinerà niente di buono lo stesso.
Certo, in un curriculum è più impressionante leggere una sfilza di 
sigle... un selezionatore che non capisce una fava di informatica come 
si regolerà secondo voi? :-)

 si regolerà secondo voi? :-)
E' la solita questione questa dei curriculum e io sono anni che
combatto coi mulini a vento.
Io lavoro per una societa' di informatica, e sono uno degli elementi
destinati ad andare presso i clienti finali.
E adesso che sono appena rientrato in sede, a fare un po' di
formazione, in attesa di un nuovo cliente, mi hanno chiesto di
aggiornare il curriculum e di specificare quali linguaggi conosco.
E io ogni volta a discutere con il nostro responsabile del personale
perche' pretende che io inserisca i linguaggi che conosco, e io che
non li voglio mettere perche' non significa niente.
Al massimo potrei elencare i linguaggi che mi e' capitato di usare
nella mia vita professionale, ma che senso ha?
Come se uno che di mestiere fa l'autista dovesse elencare tutte le
marche e modelli che ha guidato in vita sua, come dire che invece
quelli che non ha guidato non li sa guidare.
Il nocciolo della questione e' saper programmare, e che si sappiano
maneggiare i dati.
La sintassi di un linguaggio e' secondaria: i linguaggi sono tutti
uguali da un punto di vista puramente concettuale.

 quelli che non ha guidato non li sa guidare.
Questo è un bel paragone.

 non li voglio mettere perche' non significa niente.
:-)
Cito da un film: "se una ragazza ti chiede di ballare, tu balli".
Credo di aver capito perché lo fai, ma ho la sensazione che sia un 
rifiuto un pò nevrotico... :-)

 uguali da un punto di vista puramente concettuale.
Però non puoi dire di essere ugualmente produttivo in tutti i linguaggi: 
se devo assumere una persona per lavorare in un determinato ambiente che 
richiede un certo linguaggio, prenderò chi lo conosce già bene o chi ha 
bisogno di mesi/anni per diventare produttivo? Il curriculum serve per 
questo, no?
La stima che ho sentito più di frequente dice che per convertire in un 
buon programmatore Java (nel senso più ampio del termine) qualcuno già 
pratico di programmazione in altri ambienti ci vogliono circa due/tre 
anni. Direi che nella maggior parte dei casi è un costo inaccettabile.
Comunque, non sono neppure d'accordo sull'assunto iniziale: conoscere 
diversi linguaggi, che comunque, al giorno d'oggi, non vedo come possano 
essere considerati separatamente dalle relative librerie, ambienti di 
sviluppo, framework di esecuzione, ecc... è sicuramente utile e allarga 
le prospettive di un programmatore.
Ma quando uno sviluppatore passa da un linguaggio che conosce bene ad un 
altro nuovo, per un bel po' di tempo (mesi/anni) tende a trascrivere i 
vecchi idiomi nel nuovo linguaggio, producendo codice meno efficiente e 
  più difficile da mantenere.

   più difficile da mantenere.
Io continuo a ritenere che tu di Programmatori, con la P maiuscola, ne
abbia visti pochi.
Purtroppo mi tocca osservare come certi strumenti che ci sono in giro
oggi, mettano in grado molti a scrivere codice, senza averne la giusta
consapevolezza.
Il codice meno efficiente e piu' difficile da mantenere non e' una
conseguenza del non conoscere il linguaggio, ma del non saper
programmare bene.

 rifiuto un pò nevrotico... :-)
Si! Hai ragione. Ma io insisto!
Dalla mia parte ho la consapevolezza che io so fare bene il mio
mestiere, che mi piace pure, e che non cambierei mai la mia maglietta
di programmatore, con la giacca dell'analista.
Posso anche indossarla la giacca dell'analista, a patto che poi, me la
fanno togliere, e rimettere la mia maglietta di programmatore per
scrivere il codice.

 [...]
Ciao  Manlio


Non mi intendo di aerei, ma sono propenso a credere che uno che e'
gia' pilota per un certo tipo di aereo, ci metta relativamente poco ad
ottenere l'abilitazione per un aereo di un'altra categoria, rispetto
ad uno che non sa volare.
Anche perche' la teoria del volo non cambia da aereo ad aereo.
Ad ogni modo, ho cercato su google per curiosita' quante ore occorrono
per un brevetto di pilota, e ho trovato questa pagina
http://www.capri-helicopters.com/it/scuola-volo-elicotteri
dove dice che dopo 20 ore di volo si ottiene un attestato di allievo-
pilota.
Sembra piu' facile imparare a guidare un elicottero che programmare.

 impararla
Il problema non e' la grammatica. Il problema e' la *semantica* e la
*pragmatica*. Vedo troppi programmatori che scrivono codice orribile a
vedersi per poter credere che sia solo questione di "grammatica".
E no, i linguaggi non sono solo strumenti. I linguaggi sono "il modo di
dire le cose". Lo studio dei linguaggi ti mostra che si possono dire
cose in modi che prima non erano nemmeno pensabili. Certo, se uno
conosce C e Java probabilmente non si rende conto di questa cosa.
E per molti dei linguaggi piu' interessanti la grammatica la si impara
si in fretta, ma ad usarli *bene*, capendo gli effettivi trade-off, i
costi impliciti di ciascuna soluzione etc etc etc e' assolutamente piu'
complesso.
-- 
-riko

 uguali da un punto di vista puramente concettuale.
Il cazzo e una fava. I linguaggi si basano anche su modelli di
computazione diversa, figuriamoci se sono tutti uguali. 
-- 
-riko

 computazione diversa, figuriamoci se sono tutti uguali.
Ma se puoi rappresentare un problema con un diagramma a blocchi,
oppure con un meta-linguaggio, vuol dire che c'e' corrispondenza tra
il diagramma a blocchi e il meta linguaggio.
E se poi codifichi il tutto in C, o in Perl, o in Phyton, o in Java, o
in quello che ti pare, c'e' sempre corrispondenza tra un linguaggio e
l'altro.
Quindi sono uguali.
Potra' averci qualche prerogativa specifica un certo linguaggio, che
meglio si adattera' a svolgere una particolare funzione, rispetto ad
un altro che magari non dispone nativamente di quel tipo di strutture
o oggetti, ma nulla ti vieta di scriverteli.
Non stiamo parlando di efficienza estrema (anche perche' nelle normali
applicazioni aziendali, l'efficienza e' proprio l'ultima cosa), stiamo
parlando di fattibilita'.
E fattibilita' significa che un tipico problema, che e' quello di
prendere un dato da una parte (che puo' essere un database o un
servizio web), elaborarlo, e collocarlo da un'altra parte, puo' essere
effettuato con qualunque linguaggio, se non addirittura istanziando lo
stesso oggetto gia' pronto che fa il lavoro per noi.
Se non ritieni che questo sia vero, scendiamo dall'astratto e
prendiamo un caso specifico.
Magari il caso specifico che soddisfa la tua tesi esiste, e sono io
che non lo vedo, perche' fino ad oggi, tutto quello che mi e' capitato
di fare, si poteva fare a prescindere dal linguaggio.

 Quindi sono uguali.
State argomentando su due piani molto diversi.
In riferimento a questo chart:
http://www.info.ucl.ac.be/~pvr/paradigmsDIAGRAMeng108.pdf
Tu dividi i linguaggi in turing completi e non completi (la riga
tratteggiata, orizzontale in alto).
Da questo punto di vista la maggior parte dei linguaggi sta sotto la
riga, va da se'.
Ma come si usa dire, "it's a bit more complicated that that" - e alcuni
paradigmi di programmazione, rappresentati dai diversi mattoncini,
possono essere implementati nel linguaggio X:
 - in modo diretto, se il linguaggio gia' lo prevede
 - estendento X senza troppo impazzimento
 - richiedendo 4 framework, 20 API e 60 programmatori
Ad esempio, lazy dataflow programming, o software transactional memory..
si' certo, li puoi scrivere anche in COBOL, piu' o meno, in un certo
senso, o forse.. forse...

Quindi sono uguali.
Quindi sono equivalenti, che è un po' diverso da "uguali". Ed è molto
diverso dal passare proficuamente da un linguaggio all'altro in "un paio di
giorni".
Ciao.

 di fare, si poteva fare a prescindere dal linguaggio.
Tu stai ragionando senza definire il concetto di "equivalenza". Se
quello che intendi e' la turing-equivalenza, si. Tutti i linguaggi sono
equivalenti. E sono anche equivalenti alle funzioni calcolabili da 
N -> N e ad un altro fottio di cose. Eppure Emacs ci appare abbastanza
diverso da una semplice funzione da N->N. Incidentalmente, calcolano le
stesse cose.
Questo e' un concetto di equivalenza piuttosto debole: esprime un
concetto fondamentale ed e' importantissima, ma e' molto ingenua
utilizzarla nella pratica della programmazione.
Hai *modelli* di calcolo differenti. Ovvero la macchina astratta che
effettua la computazione e' proprio diversa nel funzionamento. Sopra
questo hai diversi idiomi, diversi modi di strutturare il codice, usando
costrutti fondamentali diversi (iterazione/ricorsione, lazyness, modelli
di concorrenza).
Prendi un programmatore scheme e un programmatore C e dagli da fare un
progetto. Il sorgente risultante non si assomigliera' nemmeno vagamente.
A meno che il programmatore C non si sia scritto un compilatore scheme
oppure il programmatore scheme non si sia scritto un compilatore C.
-- 
-riko

 oppure il programmatore scheme non si sia scritto un compilatore C.
Tra l'altro il programmatore scheme a meno che non sia uno scarpone 
farà il culo di quello C a quadrettoni a correttezza del codice e tempi 
di sviluppo.
Questo dovrebbe tagliare la testa al toro :p
  ngw
-- 
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA  98104  US

 computazione diversa, figuriamoci se sono tutti uguali.
Una cosa perï¿œ ci sarebbe da precisare... d'accordo che C, Delphi e 
Python sono diversi e per passare dall'uno all'altro (con pari bravura) 
ci vuol tempo. Perchï¿œ sono LINGUAGGI.
Perï¿œ se uno conosce giï¿œ il linguaggio in cui lavorare e deve imparare 
solo XML, per dire, "non ci credo" che ci mette mesi a farlo! Ci sono 
tante tecnologie accessorie (le siglette di cui dicevo) che alla fin 
fine, per quello che deve fare un sviluppatore, sono cazzatine...

 fine, per quello che deve fare un sviluppatore, sono cazzatine...
Sull'esempio specifico sono d'accordo con te. Qui si tratta di imparare
una tecnologia, un'API. Se la tecnologia' e' "normale" e l'API ben
progettata, il tempo necessario e' poco. Poi ovviamente posso dirti che
smazzarsi xml con elementtree e' ordini di grandezza piu' facile che
farlo con le API date da, per esempio, Java. Idem fare concorrenza
pesante con Erlang e' una bazzecola rispetto a farlo con Java.
Ovviamente bisogna sapere cosa si sta facendo in entrambi i casi. Poi
ovvio.. uno schemer davanti a XML si mettera' a ridere: perche' tornare
indietro, dira'. E ha pure ragione.
-- 
-riko