Newsgroup: it.lavoro.informatica
Titolo: Linguaggi statici e dinamici [reprise]

Salve a tutti,
riprendo un vecchio argomento per gli interessati. Il futuro C# 3.0 
(
http://msdn2.microsoft.com/en-us/netframework/aa336745.aspx
) sembra 
andare proprio in questa direzione con l'introduzione della 
dichiarazione generica "var" e la possibilità di estendere "al volo" i 
tipi primitivi. Che ne pensate?
Ciao,
Giulio

Giulio Petrucci ha scritto:

Penso che se lo potevano risparmiare :-)
Siccome queste variabili dovranno obbligatoriamente essere inizializzate 
in dichiarazione, praticamente sono "dinamichega" (*). Il tipo lo decidi 
comunque alla dichiarazione quindi non cambia assolutamente nulla.
(*) forma contratta di "dinamiche una sega" :-)

 ed il fatto che consenta di scrivere codice non managed 
???
Quello è il VisualC++.
Non so se in C# sia possibile scrivere codice unmanaged, io 
personalmente non l'ho mai fatto.
Ciao,
Giulio

 abitudini e la mediocritÃ  di programmazione.
e qui ti sbagli clamorosamente! Limitare la liberta' di espressione per
limitare i cattivi programmatori non mi pare una soluzione furba. La
soluzione e' l'educazione (intesa come apprendimento, studio, esprienza).
Non ci sono cattivi linguaggi (beh, forse Visual Basic... ;-p), solo
cattivi programmatori. Se non sai programmare non sai programmare e le
cappellate le farai sia con tipizzazione statica che con tipizzazione
dinamica con la differenza che chi sa programmare e' statisticamente +
produttivo (sto' cercando i riferimenti, non li ho sottomano) con un
linguaggio dinamico che uno statico...
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 personalmente non l'ho mai fatto.
Non esiste compilatore che consenta da sorgenti C# delle librerie native 
non-clr, anche se in teoria tutto si può fare :-)

 personalmente non l'ho mai fatto.
Si può. 
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 linguaggio dinamico che uno statico...
Quoto, se n'è parlato fino alla morte in almeno 50 NG diversi e non è
mai stato dimostrato che dinamico porta a codice peggiore, anzi.
Flame a parte su quale dei due è meglio è solo una questione di
filosofia e di gusti (un po' come scegliere un linguaggio rispetto ad un
altro se equivalenti nelle funzionalità che ci servono).
Vedi: 
http://www.mindview.net/WebLog/log-0025
http://codecraft.info/index.php/archives/20/


 abitudini e la mediocrità di programmazione.
In base a cosa affermi ciò? Io ho visto tanto di quel buon codice
scritto in linguaggi dinamici che ormai la tua mi sembra una frase da
ignorante (nel senso che ignora il dominio dei linguaggi dinamici)
Opinioni please.



Che è una cagata. Cerco di spiegarmi:
dichiarare i tipi per molti (compreso me) è considerato una rottura e
uno spreco di tempo. I linguaggi dinamici (strongly o weak typed)
determinano il tipo di una variabile da sé. I linguaggi statici senza
inferenza (come C#) vanno aiutati. I linguaggi statici come Haskell
invece non hanno bisogno di dichiarazione del tipo.
Cercare di "migliorare" la situazione togliendo "int" e usando "var" non
giova proprio a nessuno ed è una pezza macroscopica imho.
Un po' come l'auto in C++0x (se non ricordo male). Se l'obiettivo è
quello di rendere la programmazione più agevole, cosa cambia da dover
scrivere "int ciao = 3" o "var ciao = 3" ?
Può essere comodo quando la dichiarazione del tipo è un po' più lunga,
ma è appunto una pezza.
Ci sono molte cose ben più interessanti in C#3.0, come le funzionalità
funzionali (gioco di parole a parte :D)


 non-clr, anche se in teoria tutto si può fare :-)
Ehm, mi sa che ti è rimasto nelle dita un pezzo di frase, puoi dargli un
senso per favore? :D


 scrivere "int ciao = 3" o "var ciao = 3" ?
Oltretutto da ciň che leggo č obbligatorio inizializzare la variabile in 
dichiarazione. Quindi veramente non cambia nulla. Se il tipo lo decido 
comunque in fase di dichiarazione non vedo cosa ci sia di dinamico.

 abitudini e la mediocrità di programmazione.
E' falso.
naturalmente sei libero di non farteli piacere ma la ragione è sbagliata.

 abitudini e la mediocrità di programmazione.
LOL! Siamo alla sagra della porchetta o su ILI?
-- 
d.

 vaccata di meno ;-).
Se il linguaggio č strong typed i vincoli sono gli stessi.


Se ci hai giocato:
- questi tipi dichiarati con var sono duck type?
- se a e' null, x = a.b.c() o x = a.b.d lanciano eccezioni o assegnano
null? C'e' una maniera semplice per far assegnare null in questi casi
senza dover passare da una eccezione?
--
ale
http://www.riolo.org

 - questi tipi dichiarati con var sono duck type?
Finché C# sarà strong typed a compile time ne dubito.
"The only thing that var changes is that you don't have to declare the
type explicitly - the compiler infers the variable's type. Specifically,
the variable's type will be whatever type its initialization expression
is. (An uninitialized var will cause a compiler error.)"
da 
http://www.interact-sw.co.uk/iangblog/2005/09/23/varisntobject


 comunque in fase di dichiarazione non vedo cosa ci sia di dinamico.
Aggiungo il fatto che magari programmatori poco esperti riempirebbero il
codice di "auto" o "var" rendendo il codice pure peggio :D


 Si può. 
Davvero? a me risulta che si possa scrivere codice unsave (impiegando
ad esempio i puntatori), non che si possa scrivere codice unmanaged. Ma
probabilmente sono io che di C# so pochino. Mi dite per piacere come si
fa? Poi non lo uso, promesso, ma cosi' soddisfo una mia curiosità...
-- 
Ciao!
Luca

 ignorante (nel senso che ignora il dominio dei linguaggi dinamici)
D'accordo, ed č vero anche il contrario. L'ultima porcata scritta con
un linguaggio statico l'ho vista oggi (e l'ho scritta io, 6 anni fa,
mannaggia... :) )
-- 
Ciao!
Luca

 scrivere "int ciao = 3" o "var ciao = 3" ?
In C++? Cambia. Il problema è che se hai codice pesantemente templatico
puoi avere tipi di anche una ventina di caratteri. E diventa *molto*
comodo non dovere scrivere a mano la pappardella :)
Per C# non mi pronuncio, non lo uso come sai.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 vaccata di meno ;-).
Non confondere strongly typed con weakly typed. 
Fra linguaggi dinamici e linguaggi statici, la differenza č solo il
*quando* viene rilevato l'errore.
Poi ci sono fior di linguaggi statici che comunque *non* sono type-safe,
e buona parte dei linguaggi statici comunque hanno comunque fior di
errori che non sono rilevabili staticamente. Per esempio i null object
in Java (o roba analoga). Per cui dobbiamo comunque scrivere test
unitari e compagnia cantante. Test unitari che beccano al volo anche gli
errori di tipo nei linguaggi dinamici strongly typed.
Se hai una cattiva idea dei linguaggi dinamici per colpa di PHP, fai
conto che li i problemi sono dovuti alla tipizzazione debole, non al
fatto che sia dinamica (oltre che a molte altre cause non legate).


 dahttp://
www.interact-sw.co.uk/iangblog/2005/09/23/varisntobject
Se e' cosi' e' semplicemente un inutile appesantimento sintattico.
Peccato, la sintassi per l'espressione lambda non mi e' sembrata male
(anche se tra i tanti esempi letti per il c# 3.0, non ce n'era uno
decente, tutta roba banalissima .. qualche esempio grazioso
sottomano?).
--
ale
http://www.riolo.org

 sottomano?).
Io non ne ho mi spiace


 fa? Poi non lo uso, promesso, ma cosi' soddisfo una mia curiosità...
P/Invoke ti dice niente? Idem per l'unsafe. Sono modi per "wrappare"
codice win32 dentro .NET.
Se invece vuoi andare più in basso c'è C++/CLI che, sempre per sentito
dire o letto, può mixare i due ambienti nello stesso programma


 comodo non dovere scrivere a mano la pappardella :)
Si beh, lo scopo è lo stesso anche in C# immagino :D
'LinkedList<Employee> employees = new LinkedList<Employee>();'
che bello poter usare le liste Python per tutto ;-)
Mi vengono in mente i giorni bui in cui si scrivevano "collection
tipizzate" in C#, hauahua :D


 dire o letto, può mixare i due ambienti nello stesso programma
Si, questo è vero.
Ciao,
Giulio

 senso per favore? :D
Non mi risulta (ma potrei ovviamente sbagliarmi) che esista un 
compilatore che compili un sorgente C# in un formato eseguibile nativo 
windows (o linux che dir si voglia).
Questo è quello che volevo dire :-D

 programmazione :-)
Oddio:
1) Java e C# sono tanto simili quanto differenti: in C# hai un type system 
single-rooted (ergo: tutto deriva da object, che è il layer supertype) 
mentre Java distingue i tipi valore da quelli riferimento. In C# puoi 
definire sia nuovi tipi valore (struct), sia tipi riferimento (class) mentre 
in java puoi creare solo questi ultimi. L'implementazione dei generics è 
drammaticamente differente (per esempio in C# non hai la type erasure). 
Oltre a differenze strutturali quali queste (dovute alla differenza dei 
runtime sottostanti), hai poi tutta la syntactic sugar: proprietà, operator 
overloading, ... Insomma: diciamo che sono 2 linguaggi che usano il ";" e le 
parentesi graffe :-)
2) C# *non* permette di scrivere codice unmanaged. C# permette di *invocare* 
codice unmanaged usando P/Invoke o COM Interop. Forse ti riferisci al codice 
unsafe, che però è rigorosamente managed
-- 
.A
http://blogs.ugidotnet.org/pape
 

 parentesi graffe :-)
esatta considerazione.
si fa prima a dire in cosa sono simili piuttosto che elencarne le 
differenze :-)
Fra l'altro, la sostanza di alcune differenze (vedi ad esempio 
l'overload degli operatori, ma anche più banalmente le properties e le 
indexed properties) cambiano radicalmente il modo di scrivere i 
programmi, ergo è molto superficiale dire che sono uguali.
Di solito questa è la classica frase per sentito dire :)

Vero. Passatemi il paragone stirato ma e' un po' come chi programmava in C
e poi si e' messo a usare il C++ senza studiarne veramente le differenze:
il risultato sono milioni di programmi C++ che in realta' sono C salvato
in file di testo con estensione .cpp
La stragrande maggioranza degli sviluppatori Java che usano C# (o gli
danno un'occhiata) finiscono con scrivere programmi in C# "alla Java"
senza davvero studiarne le differenze (e senza sfruttarle ovviamente).
P.S.: non sviluppo (piu') in C# :-)
Luigi
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 PInvoke ti permette di usare librerie native, non di scriverle.
Giusto.


 Questo è quello che volevo dire :-D
A dire il vero c'è. MS .NET compila in bytecode .NET wrappando
l'eseguibile .NET con un PE win32 che si limita a fare il dispatching al
momento dell'esecuzione. Inoltre il JIT genera codice macchina all'avvio
per una esecuzione più rapida. Con tool come ngen.exe puoi generare
eseguibili ottimizzati per la macchina (perdendo la portabilità
dell'eseguibile credo). Che senso avrebbe generare un eseguibile win32
in prima istanza dato che non potrebbe funzionare :D ?
Mono immagino si comporti in maniera simile


 parentesi graffe :-)
Ah ah dovresti leggere le pippe mentali che ci sono sui vari java blogs
per l'introduzione di closure, properties e compagnia bella in Java 7
Io comunque sono dell'idea (non che a me venga in tasca qualcosa) che la
mossa di rendere Java OpenSource potrebbe giovare all'ambiente stesso.
Ok che dall'altra parte c'č Mono ma la situazione č come dire...
leggermente diversa.
ciao!


 senza davvero studiarne le differenze (e senza sfruttarle ovviamente).
Beh obiettivamente è sicuramente più facile la transizione (a livello di
linguaggio eh, l'ambiente è un altro paio di maniche) Java <-> C# che C
-> C++. Poi se uno è uno svogliato in Java lo sarà anche da Python a
Ruby. La prima cosa da fare dopo aver studiato la sintassi è imparare
gli idiomi del linguaggio. Tipo in Ruby nessuno usa le parentesi per
metodi e funzioni se non c'è ambiguità. Puoi scrivere codice corretto
anche usandole ma è brutto da far schifo :D


 dell'eseguibile credo).
ngen può essere eseguito solo sulla macchina di destinazione, e richiede 
comunque che rimanga disponibile anche l'assembly originale: in pratica, 
quindi, non si può usare come "trucco" per distribuire una compilazione 
nativa
-- 
.A
http://blogs.ugidotnet.org/pape
 


ciuz!
-- 
.A
http://blogs.ugidotnet.org/pape
 

 gli idiomi del linguaggio.
Lawrence, non sono d'accordo: le similitudini sintattiche tra i linguaggi 
possono nascondere trappole molto pericolose. Chiedi a tutti i dev VB6 che, 
passati a .NET, hanno continuato a dichiarare le variabili come "Long" 
lamentandosi poi della "lentezza di .NET" (hint: in VB6 Long è a 32bit, 
mentre in 
VB.NET
 è a 64) <g>
-- 
.A
http://blogs.ugidotnet.org/pape
 

 drammaticamente differente (per esempio in C# non hai la type erasure). 
Cosa intendi per "type erasure"?
Ciao,
Giulio

Cosa intendi per "type erasure"?
http://java.sun.com/docs/books/tutorial/java/generics/erasure.html
-- 
.A
http://blogs.ugidotnet.org/pape
 

 mentre in 
VB.NET
 è a 64) <g>
VB6 non è nemmeno ad oggetti, il paragone non è tanto diverso da C ->
C++. Sintassi simile (come VB6 e 
VB.NET
) ma un sacco di cose da imparare
da 0 (quelle più importanti). Lo stesso non si può dire per uno che deve
studiare C# e Java. Il paragone è come Python e Ruby. Di differenze ce
ne sono e parecchie ma uno che conosce bene uno dei due in un paio di
settimane può già essere pratico dell'altro, poi certo, ci vorrà del
tempo per imparare i dettagli e gli idiomi ma non è sta gran pazzia (te
lo dico perché io conosco Python bene e Ruby un po' meno ma non ho avuto
alcun tipo di problema; es. di quirk: in Python la lista vuota è
considerata False in un contesto booleano, in Ruby solo nil e false sono
falsi in un contesto booleano, una volta che lo sai il problema non
esiste)
Io ho sempre parlato di linguaggi e imparare un linguaggio perfettamente
equivalente allo stesso livello di astrazione è una stupidata. Lo sforzo
maggiore sarà per applicare correttamente il linguaggio seguendo le best
practices ecc ecc ma per quello si studia, si legge il codice, si
impara.
Java e C# si sovrappongono per la quasi totalità dei compiti come Python
e Ruby.


 nativa
Dunque perdi la portabilità, è come ricordavo. Grazie


 affermare che sono linguaggi (e runtime) significativamente differenti.
Come ho detto nell'altro post io li ritengo pressoché equivalenti con le
dovute differenze. Il livello di astrazione è lo stesso. Non ho mai
parlato di eguaglianza sintattica mi sembra, ma di eguaglianza
funzionale all'atto pratico.


 
http://java.sun.com/docs/books/tutorial/java/generics/erasure.html
Grazie del link.
A questo punto le domande sono:
1) In C# non le generics non vengono implementate così?
2) Quali sono i vantaggi/svantaggi dei due approcci IYO?
Ciao,
Giulio
--

 codice win32 dentro .NET.
Appunto, cio' che dicevo io. P/Invoke consente di utilizzare - se non
ricordo male, oggetti OLE in un'applicazione .NET. Unsafe ha
completamente un'altro obiettivo (vuoi usare l'aritmetica puntatori?
fai, ma sappi che sono assolutamente afafri tuoi perché io compilatore
nei blocchi unsafe non metto becco).
In conclusione, non è possibile scrivere codice unmanaged in C# (vabbè,
a meno che non passi per ngen, ma quello è un trucco).
-- 
Ciao!
Luca

 della memoria del CLR.
Tutto corretto, tranne questo.
La direttiva unsafe ti consente di utilizzare una parte del linguaggio
che normalmente ti viene sconsigliato di impiegare proprio perché
'unsafe'. Se marchi un blocco come unsafe, ci puoi fare dentro delle
vere porcate (usare puntatori, inizializzarli alla fallo di canide e
poi usarli) senza che il compilatore abbia a dire nulla.
-- 
Ciao!
Luca

 dire...  leggermente diversa.
Mono, purtroppo, è penosamente indietro. Arranca per completare la
compatibilità a .NET 1.1, mentre 2.0 è già maturo. Io spero che venga
raggiunta, ma per il momento sono pessimista.
-- 
Ciao!
Luca

 Si beh, lo scopo è lo stesso anche in C# immagino :D
Possibile. Ma non ho familiarità con C# come dicevo. 
Dipende più dalla pragmatica del linguaggio che dalle semplici
possibilità.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.