sondaggione

[xabraita12]

sondaggio su che linguaggio di programmazione consigliate per iniziare a programmare a uno che è veramente alle prime armi le scelte sono visual basic,C,C#,C++,Pascal,Python

[71104]

io ho votato immediatamente C# ma solo perché nell'altro thread hai detto che il tuo scopo è scrivere un videogame, altrimenti avrei detto Java o Python.

chi è che ha votato C? :fagiano:

[PGI-Bis]

Votato Java.

[naoto84]

Votato C. Comunque se si tratta di iniziare a programmare da zero le opzioni C++ e C si potrebbero praticamente unificare (un qualsiasi libro che affronti i fondamenti con il C++ avrà tutti i primi capitoli sulla programmazione procedurale).

Staccato di poco come secondo voto Java.

[cdimauro]

Come già detto nell'altro thread, la risposta è a dir poco scontata: Python. :cool:

E al posto del sondaggio sarebbe più interessante presentare un problema e vedere in che modo viene risolto coi diversi linguaggi di programmazione che ognuno di noi conosce, per mostrare quello che meglio si presta a essere la soluzione al tuo dubbio. ;)

[ndakota]

forza sostenitori del c++ facciamoci sentire :D

[cdimauro]

Magari dimostrando perché il C++ sarebbe da consigliare per INIZIARE a programmare, rispetto a linguaggi come Python. ;)

[Lyane]

Manca sempre il Fortran nei sondaggi......:cry:

[Baronerosso9]

forza sostenitori del c++ facciamoci sentire :D

hem...:mbe: :confused: ....non so perchè...ma terrei precisare che non è un sondaggio al più bel linguaggio o un sondaggio su " quale è il tuo linguaggio preferito"....il sondaggio chiede quale linguaggio sia più appropriato per iniziare a programmare da zero...ora....visto che il c++ è un'estensione del c...non vi pare ke allora se proprio di c nn se ne può fare a meno è bene che inizi col c basilare...cioè il c stesso:D ?
ps.cmq xabraita12 sono sicuro che quando sarà finito il sondaggio sarai + confuso di prima....sarà solo una mia idea?...perchè nn ci facciamo un sondaggio pure su questo??:p :D :D

[Ziosilvio]

Python.

Eventualmente con PyGame.

[^TiGeRShArK^]

python ovviamente :p
Direi anke ruby se non fosse per la documentazione bastardissima :mad:
E cmq da due mesetti a questa parte c'è anke jruby 1.0 ke è l'equivalente di jython :Prrr:

[cdimauro]

Già. Chissà come mai tutta questa voglia di compilare in bytecode per farlo eseguire da una JVM, ma senza usare il linguaggio per cui è nata... :asd:

P.S. Real Programmers don't need comments-- the code is obvious. :cool:

[cdimauro]

Manca sempre il Fortran nei sondaggi......:cry:
Real Programmers use Fortran. Quiche Eaters use Pascal. (http://www.pbm.com/~lindahl/real.programmers.html) :asd:

[cdimauro]

hem...:mbe: :confused: ....non so perchè...ma terrei precisare che non è un sondaggio al più bel linguaggio o un sondaggio su " quale è il tuo linguaggio preferito"....il sondaggio chiede quale linguaggio sia più appropriato per iniziare a programmare da zero...
Esattamente. I buoni programmatori dovrebbero imparare innanzitutto a rispettare alla lettera i REQUISITI del problema che gli è stato posto. Quindi evitare di uscire fuori dal seminato sarebbe "cosa buona e giusta". ;)
ora....visto che il c++ è un'estensione del c...non vi pare ke allora se proprio di c nn se ne può fare a meno è bene che inizi col c basilare...cioè il c stesso:D ?
Come ti dicevo nell'altro thread, bisogna vedere cosa s'intende per basilare.

Io potrei dirti che per me basilare è che un linguaggio permetta di programmare a oggetti (senza contorsionismi, cioé potendo disporre di costrutti sintattici allo scopo).
In questo caso il C++, pur essendo un superset del C (e già solo per questo non si capisce perché ancora oggi c'è gente che usi il C :doh: ), sarebbe l'UNICA possibilità fra C e C++. ;)
ps.cmq xabraita12 sono sicuro che quando sarà finito il sondaggio sarai + confuso di prima....sarà solo una mia idea?...perchè nn ci facciamo un sondaggio pure su questo??:p :D :D
Se leggerà attentamente le risposte e ci rifletterà per benino sopra, alla fine dovrebbe avere le idee decisamente più chiare. ;)

[ndakota]

hem...:mbe: :confused: ....non so perchè...ma terrei precisare che non è un sondaggio al più bel linguaggio o un sondaggio su " quale è il tuo linguaggio preferito"....il sondaggio chiede quale linguaggio sia più appropriato per iniziare a programmare da zero...ora....visto che il c++ è un'estensione del c...non vi pare ke allora se proprio di c nn se ne può fare a meno è bene che inizi col c basilare...cioè il c stesso:D ?
ps.cmq xabraita12 sono sicuro che quando sarà finito il sondaggio sarai + confuso di prima....sarà solo una mia idea?...perchè nn ci facciamo un sondaggio pure su questo??:p :D :D


io a scuola sono partito dal C++ e non ho avuto problemi quindi non vedo perchè non debba essere considerato anche come linguaggio per inziare. e come qualcuno ha già detto è inutile che parta dal C perchè qualsiasi libro prenda vedrà la parte procedurale finchè non si imbatterà in classi e oggetti.

[franksisca]

java

[71104]

(e già solo per questo non si capisce perché ancora oggi c'è gente che usi il C :doh: ) i casi in cui non se ne può fare a meno sono quelli in cui bisogna interagire con delle componenti esterne scritte in C. per esempio, esempio tra l'altro che ribadisco spesso, un driver per Windows difficilmente può essere programmato in C++, e credo che sia del tutto impossibile programmarlo in qualsiasi altro linguaggio. così come ribadisco questo esempio allo stesso modo ribadisco che si tratta di situazioni sporadiche e che il 90% dei rimanenti casi in cui la gente scrive in C sono semplicemente casi di gente stupida o inesperta. a me personalmente è capitato di vedere tanto la prima quanto la seconda :D

[71104]

io a scuola sono partito dal C++ e non ho avuto problemi quindi non vedo perchè non debba essere considerato anche come linguaggio per inziare. 1) il motivo l'hai scritto più avanti
2) mio padre ha iniziato con l'assembly di qualche processore trogloditico e ci si è trovato bene, non vedo perché non debba essere considerato anche come linguaggio per iniziare.

qualsiasi libro prenda (di C++) vedrà la parte procedurale finchè non si imbatterà in classi e oggetti. appunto

[cdimauro]

io a scuola sono partito dal C++ e non ho avuto problemi quindi non vedo perchè non debba essere considerato anche come linguaggio per inziare. e come qualcuno ha già detto è inutile che parta dal C perchè qualsiasi libro prenda vedrà la parte procedurale finchè non si imbatterà in classi e oggetti.
Io sono partito dal linguaggio macchina e non ho avuto particolari problemi, ma non per questo consiglierei di seguire la stessa strada per iniziare a programmare. :p

I motivi per cui è meglio non iniziare con C++ et similia li ho esposti qui http://www.hwupgrade.it/forum/showpost.php?p=18281282&postcount=35 qui http://www.hwupgrade.it/forum/showpost.php?p=18285611&postcount=39 e qui http://www.hwupgrade.it/forum/showpost.php?p=18285736&postcount=41

Per il resto, sarebbe interessante cos'avrebbe il C++ di meglio da offrire per chi inizia a programmare rispetto a Python. ;)

[71104]

Per il resto, sarebbe interessante cos'avrebbe il C++ di meglio da offrire per chi inizia a programmare rispetto a Python. ;) come, non lo sai? è molto più potente, c'è l'aritmetica dei puntatori :asd:

EDIT - ha dimenticavo, è anche più veloce e PERFORMANTE, anche se purtroppo un'anticchietta più lento del C :rotfl: :rotfl: :rotfl:

[cdimauro]

i casi in cui non se ne può fare a meno sono quelli in cui bisogna interagire con delle componenti esterne scritte in C. per esempio, esempio tra l'altro che ribadisco spesso, un driver per Windows difficilmente può essere programmato in C++, e credo che sia del tutto impossibile programmarlo in qualsiasi altro linguaggio.
Già il fatto che il C++ sia un SUPERSET del C sarebbe sufficiente a dimostrare che può fare ALMENO tutto quello che fa il C. :cool:

Per il resto, se serve interagire con subroutine scritte in C è facile uscirsene fuori con degli extern "C" messi al posto giusto (con delle routine a fare da "ponte" verso i due linguaggi).
Personalmente qualche mese fa ho lavorato per un po' per integrare il supporto allo standard H324M (quello dei telefonini 3G) ad Asterisk (una sorta di centralino) che è scritto interamente in C, ma tutto il mio codice (mi occupavo del protocollo H245) era in C++, fatta eccezione per alcuni tipi e funzioni che ho dichiarato con extern "C" per renderli accessibili da Asterisk, appunto. ;)
così come ribadisco questo esempio allo stesso modo ribadisco che si tratta di situazioni sporadiche e che il 90% dei rimanenti casi in cui la gente scrive in C sono semplicemente casi di gente stupida o inesperta. a me personalmente è capitato di vedere tanto la prima quanto la seconda :D
Per quanto scritto sopra, quella percentuale può arrivare tranquillamente a 100. :p

Il C++ bisogna saperlo usare (come per tutte le cose) e non c'è niente, ma proprio niente, che si realizza col C che non possa essere fatto col C++ (generalmente meglio :D ). ;)

[cdimauro]

1) il motivo l'hai scritto più avanti
2) mio padre ha iniziato con l'assembly di qualche processore trogloditico e ci si è trovato bene, non vedo perché non debba essere considerato anche come linguaggio per iniziare.
appunto
Io propongo il linguaggio macchina e le schede perforate per iniziare: non c'è niente di meglio della conoscenza della macchina al livello più basso che ci possa essere (per un programmatore). :asd:

[71104]

Già il fatto che il C++ sia un SUPERSET del C sarebbe sufficiente a dimostrare che può fare ALMENO tutto quello che fa il C. :cool: d'accordo ma non credo che servirebbe a molto utilizzare il C++ per scrivere un driver quando il 90% del codice dovrebbe essere scritto all'interno di routines del tutto procedurali. e tra l'altro non potresti neanche usare new e delete per allocare gli oggetti, quindi i costruttori e i distruttori non verrebbero chiamati implicitamente. sarebbe necessario sovrascrivere gli operatori new e delete ma ti assicuro che sarebbe una fatica inutile.

[71104]

Io propongo il linguaggio macchina e le schede perforate per iniziare: non c'è niente di meglio della conoscenza della macchina al livello più basso che ci possa essere (per un programmatore). :asd: tante volte non si fosse capito il punto 2 era ironico :sofico:

mi sa che dovrei iniziare ad usare pure io la mitica firma di trallallero :asd:

[cdimauro]

come, non lo sai? è molto più potente, c'è l'aritmetica dei puntatori :asd:
http://www.codesourcery.com/archives/arm-gcc/jpgN3AIEcFooO.jpg

http://en.hakin9.org/magazines/2/0/tut_1/img/lazyjoe_03.jpg

Queste sono in dotazione coi linguaggi non managed :asd: :asd: :asd:
EDIT - ha dimenticavo, è anche più veloce e PERFORMANTE, anche se purtroppo un'anticchietta più lento del C :rotfl: :rotfl: :rotfl:
Si chiama ansia da prestazione, e ne sono particolarmente affetti i programmatori che usano linguaggi non managed. :asd: :asd: :asd:

[cdimauro]

d'accordo ma non credo che servirebbe a molto utilizzare il C++ per scrivere un driver quando il 90% del codice dovrebbe essere scritto all'interno di routines del tutto procedurali. e tra l'altro non potresti neanche usare new e delete per allocare gli oggetti, quindi i costruttori e i distruttori non verrebbero chiamati implicitamente. sarebbe necessario sovrascrivere gli operatori new e delete ma ti assicuro che sarebbe una fatica inutile.
Lo so bene, ma il C++ non è soltanto il C con le classi aggiunte. ;)

[cdimauro]

tante volte non si fosse capito il punto 2 era ironico :sofico:

mi sa che dovrei iniziare ad usare pure io la mitica firma di trallallero :asd:
L'avevo capito e, infatti, avevo rilanciato. :p

[PGI-Bis]

Insomma, è andato in vacca anche il sondaggio :D.

Il vero programmatore che non scrivi i commenti potrebbe fare un passo in più ed evitare anche di scrivere il codice: farebbe un grandissimo piacere a tutti i falsi programmatori che poi devono manutenere l'immondizia che ha scritto.

[71104]

Queste sono in dotazione coi linguaggi non managed :asd: :asd: :asd: sai che dovrebbero fare? dovrebbero riscrivere il gcc in Python :sofico: :sofico: :sofico:

Si chiama ansia da prestazione, terminologia; qui all'EUR si chiama idiozia acuta :asd:

[71104]

Insomma, è andato in vacca anche il sondaggio :D.

Il vero programmatore che non scrivi i commenti potrebbe fare un passo in più ed evitare anche di scrivere il codice: farebbe un grandissimo piacere a tutti i falsi programmatori che poi devono manutenere l'immondizia che ha scritto. il sondaggio è andato in vacca ma tu mi pare che ti stai divertendo a peggiorarlo :Prrr:

[cdimauro]

Insomma, è andato in vacca anche il sondaggio :D.
E' prassi ormai quando si parla di queste cose. :p
Il vero programmatore che non scrivi i commenti potrebbe fare un passo in più ed evitare anche di scrivere il codice: farebbe un grandissimo piacere a tutti i falsi programmatori che poi devono manutenere l'immondizia che ha scritto.
Mumble. Scrivere commenti per descrivere ciò che fa codice è del tutto superfluo. Comunque su questo molto è stato detto e non credo sia il caso di tornarci (vedi precedenti con fek). ;)

[k0nt3]

mi sa che viene fuori rumore bianco da questo sondaggio :fagiano:

[cdimauro]

sai che dovrebbero fare? dovrebbero riscrivere il gcc in Python :sofico: :sofico: :sofico:
Tanto è già lento di suo e nessuno se ne accorgerebbe (ma almeno sarebbe più facile da manutere e più comprensibile :p). :asd:
terminologia; qui all'EUR si chiama idiozia acuta :asd:
Vale solo per gli studenti? :angel:

[71104]

Lo so bene, ma il C++ non è soltanto il C con le classi aggiunte. ;) considerando che tutta la libreria standard in kernel mode è inaccessibile, e considerando che in C99 è possibile dichiarare le variabili in mezzo al codice e nelle intestazioni dei for e se non erro esiste anche const, tra le cose fondamentali (spero di non dimenticare nulla) mi pare che rimangano solo i references e i namespaces, due cose delle quali si fa facilmente a meno. certo, se magari a uno gli viene in testa di raggruppare alcune funzioni in un namespace e altre in un altro allora basta che rinomina i suoi files con l'estensione .cpp, ma non vedo che vantaggi potrebbe dare la cosa: tanto ti assicuro che un driver WDM un casino è e un casino rimane, per tutti i namespaces che tu possa fare :asd:

ora che ci penso mi pare che esista anche la possibilità di applicare i templates anche a semplici funzioni oltre che classi: in effetti questa è una cosa che potrebbe tornare utile se per esempio si volessero implementare degli array che crescono dinamicamente (dal momento che <vector> non si può usare).

[71104]

Tanto è già lento di suo e nessuno se ne accorgerebbe (ma almeno sarebbe più facile da manutere e più comprensibile :p). :asd: esatto :read: e sarebbe stato anche impossibile produrre uno screenshot con un segmentation fault :)

Vale solo per gli studenti? :angel: ricordi quando ho scritto che nella mia esperienza mi è capitato di vedere sia stupidità che inesperienza? per la seconda avevo in mente studenti, ma per la prima professori :fagiano:

[marco.r]

edit: ridondante

[71104]

E' probabilmente l'unico caso in cui ha senso riscriversi tali operatori, trovo che sia utilerrimo anche se si volessero scrivere delle versioni di new e delete che tracciano i blocchi allocati ed avvisano per esempio di eventuali memory leak o di doppie delete o altri errori.

anche se in effetti per un singolo driver e' un po' overkill. Piu' che altro immagino (non ho mai programmato driver) che non sia disponibile la libreria standard, giusto ? che io sappia no; sorry, non mi va di Googlare :p la pigrizia è tiranna

[cdimauro]

considerando che tutta la libreria standard in kernel mode è inaccessibile, e considerando che in C99 è possibile dichiarare le variabili in mezzo al codice e nelle intestazioni dei for e se non erro esiste anche const, tra le cose fondamentali (spero di non dimenticare nulla) mi pare che rimangano solo i references e i namespaces, due cose delle quali si fa facilmente a meno. certo, se magari a uno gli viene in testa di raggruppare alcune funzioni in un namespace e altre in un altro allora basta che rinomina i suoi files con l'estensione .cpp, ma non vedo che vantaggi potrebbe dare la cosa: tanto ti assicuro che un driver WDM un casino è e un casino rimane, per tutti i namespaces che tu possa fare :asd:

ora che ci penso mi pare che esista anche la possibilità di applicare i templates anche a semplici funzioni oltre che classi: in effetti questa è una cosa che potrebbe tornare utile se per esempio si volessero implementare degli array che crescono dinamicamente (dal momento che <vector> non si può usare).
Già, e poi ci sarebbero anche le funzioni annidate e l'overloading degli operatori e delle funzioni su cui non ci sputerei sopra, eh! ;)

[cdimauro]

esatto :read: e sarebbe stato anche impossibile produrre uno screenshot con un segmentation fault :)
Ci riuscirebbero lo stesso. :asd:
ricordi quando ho scritto che nella mia esperienza mi è capitato di vedere sia stupidità che inesperienza? per la seconda avevo in mente studenti, ma per la prima professori :fagiano:
As usual, insomma: è così in tutte le università. :(

[71104]

Già, e poi ci sarebbero anche le funzioni annidate e l'overloading degli operatori e delle funzioni su cui non ci sputerei sopra, eh! ;) funzioni annidate? :|
questa non l'avevo mai sperimentata :mbe:

[k0nt3]

http://www.codesourcery.com/archives/arm-gcc/jpgN3AIEcFooO.jpg

http://en.hakin9.org/magazines/2/0/tut_1/img/lazyjoe_03.jpg

Queste sono in dotazione coi linguaggi non managed :asd: :asd: :asd:


http://lists.w3.org/Archives/Public/www-validator-css/2006Dec/att-0048/CLI_NullPointerException.png

[71104]

Ci riuscirebbero lo stesso. :asd: dovrebbero scrivere una libreria nativa in C++, anzi no in C :sofico:, chiamata segfault.dll o segfault.so che provochi apposta il segmentation fault :asd:

già mi immagino l'entry point in Visual C++ per la versione Windows:

__declspec(noreturn) void segfault(bool bluescreen);


:rotfl:

[71104]

http://lists.w3.org/Archives/Public/www-validator-css/2006Dec/att-0048/CLI_NullPointerException.png ULLALLA', scusami cdimauro ma questo è scacco matto!!! :D :D :D :D

EDIT - vabbè no, in realtà per essere scacco matto bisognerebbe trovarne una in Python :asd:

[cdimauro]

funzioni annidate? :|
questa non l'avevo mai sperimentata :mbe:
Ma non eri un pascaliano anche tu? Col C++ le hanno introdotte nel linguaggio, e sono decisamente comode (quando posso le uso anche in Python :D ). :p

[71104]

Ma non eri un pascaliano anche tu? Col C++ le hanno introdotte nel linguaggio, e sono decisamente comode (quando posso le uso anche in Python :D ). :p si lo ero, ma non sapevo che in C++ si potesse fare esattamente questo:

void blah() {
void doh() {
}
}


edit - infatti non si può, non col g++ almeno a quanto pare... :mbe:
devo aver capito male :mbe:

[cdimauro]

ULLALLA', scusami cdimauro ma questo è scacco matto!!! :D :D :D :D

EDIT - vabbè no, in realtà per essere scacco matto bisognerebbe trovarne una in Python :asd:
Non vedo perché: coi linguaggi managed non è possibile accedere ad aree di memoria non opportunamente allocate, tanto meno scriverci sopra qualcosa. ;)

Incappare in una variabile non inizializzata o con un valore diverso da quel che ci si aspetta non comporta nessun "segmentation fault" o "access violation", perché non si accede, appunto, ad aree di memoria non consentite.

In Python se scrivo questo:

x = None
x()

ottengo questo:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable

Oppure con

x[1234567]

ottengo:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is unsubscriptable

Ma, ripeto, non siamo di fronte ad alcuna violazione di aree di memoria.

Lo stesso, ovviamente, vale per Java e il famigerato NullPointerException. ;)

[71104]

Non vedo perché: coi linguaggi managed non è possibile accedere ad aree di memoria non opportunamente allocate, tanto meno scriverci sopra qualcosa. ;)

Incappare in una variabile non inizializzata o con un valore diverso da quel che ci si aspetta non comporta nessun "segmentation fault" o "access violation", perché non si accede, appunto, ad aree di memoria non consentite.

In Python se scrivo questo:

x = None
x()

ottengo questo:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable

Oppure con

x[1234567]

ottengo:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is unsubscriptable

Ma, ripeto, non siamo di fronte ad alcuna violazione di aree di memoria.

Lo stesso, ovviamente, vale per Java e il famigerato NullPointerException. ;) anche le access violations sono eccezioni: il meccanismo di Structured Exception Handling di Windows e quello di gestione delle eccezioni di Java saranno anche molto diversi tecnicamente, ma concettualmente sono la stessa identica cosa!

ciò che si evince dallo screenshot postato da k0nt3 è la seguente cosa: è vero che in Java non esistono i dangling pointers, ma purtroppo esiste ancora il male del null :D

[cdimauro]

si lo ero, ma non sapevo che in C++ si potesse fare esattamente questo:

void blah() {
void doh() {
}
}


edit - infatti non si può, non col g++ almeno a quanto pare... :mbe:
devo aver capito male :mbe:
Hai ragione, ricordavo male: non fanno parte del C++. Le avevo viste implementate in qualche compilatore C comunque, forse il GCC. Per questo le ho citate.

[marco.r]

ciò che si evince dallo screenshot postato da k0nt3 è la seguente cosa: è vero che in Java non esistono i dangling pointers, ma purtroppo esiste ancora il male del null :D
Concordo... un linguaggio non dinamico dovrebbe impedire riferimento a puntatori nulli proprio grazie alla tipizzazione. Dal punto di vista logico "Foo o nulla" e' un tipo diverso da "Foo" e basta. Probabilmente a causa della sintassi C-like in Java si intende il primo caso, mentre sarebbe piu' corretto il secondo

[marco.r]

Hai ragione, ricordavo male: non fanno parte del C++. Le avevo viste implementate in qualche compilatore C comunque, forse il GCC. Per questo le ho citate.

Ho appena guardato. E' in effetti un' estensione del GCC, che pero' vale solo per il C e non per il C++.

[cdimauro]

anche le access violations sono eccezioni: il meccanismo di Structured Exception Handling di Windows e quello di gestione delle eccezioni di Java saranno anche molto diversi tecnicamente, ma concettualmente sono la stessa identica cosa!

ciò che si evince dallo screenshot postato da k0nt3 è la seguente cosa: è vero che in Java non esistono i dangling pointers, ma purtroppo esiste ancora il male del null :D
Che però, ribadisco, è ben diverso dall'accesso a una qualunque area di memoria, che è impossibile con linguaggi managed.

Un conto è un puntatore sballato che può puntare ad un'area di memoria qualunque, e di cui ti puoi accorgere subito come pure dopo molto tempo (e magari il problema viene fuori soltanto con compilatori diversi e/o facendo girare l'applicazione su piattaforme diverse) e tutt'altra cosa è chiedere a un linguaggio managed di usare NULL come riferimento a qualcosa (può essere una funzione, il metodo di una classe, una lista, ecc. ecc.) per lavorarci. ;)

Giusto per far capire meglio la cosa, il codice managed lo posso far girare anche su un processore del tutto privo di MMU e/o di meccanismi di protezione della memoria, e si comporterà sempre allo stesso modo (leggi: trovo NULL come valore di una variabile che dovrebbe essere una lista, e mi blocco perché non posso proseguire con l'operazione di estrazione di un suo elemento), mentre con un'applicazione scritta in un linguaggio non managed sullo stesso sistema potresti non accorgerti mai del bug presente nella tua applicazione (che, quindi, rimarrebbe bacata), se non tramite un qualche effetto collaterale che dovesse spuntar fuori (se sei fortunato :D ).

Io le vedo come cose nettamente diverse.

[cdimauro]

Questo m'era sfuggito. :D
dovrebbero scrivere una libreria nativa in C++, anzi no in C :sofico:, chiamata segfault.dll o segfault.so che provochi apposta il segmentation fault :asd:
Esattamente. :p
già mi immagino l'entry point in Visual C++ per la versione Windows:

__declspec(noreturn) void segfault(bool bluescreen);


:rotfl:
:D :D :D

[cdimauro]

Concordo... un linguaggio non dinamico dovrebbe impedire riferimento a puntatori nulli proprio grazie alla tipizzazione. Dal punto di vista logico "Foo o nulla" e' un tipo diverso da "Foo" e basta. Probabilmente a causa della sintassi C-like in Java si intende il primo caso, mentre sarebbe piu' corretto il secondo
Potresti essere più chiaro, cortesemente? Non riesco ad afferrarne il significato.

Grazie

[k0nt3]

Che però, ribadisco, è ben diverso dall'accesso a una qualunque area di memoria, che è impossibile con linguaggi managed.

Un conto è un puntatore sballato che può puntare ad un'area di memoria qualunque, e di cui ti puoi accorgere subito come pure dopo molto tempo (e magari il problema viene fuori soltanto con compilatori diversi e/o facendo girare l'applicazione su piattaforme diverse) e tutt'altra cosa è chiedere a un linguaggio managed di usare NULL come riferimento a qualcosa (può essere una funzione, il metodo di una classe, una lista, ecc. ecc.) per lavorarci. ;)

Giusto per far capire meglio la cosa, il codice managed lo posso far girare anche su un processore del tutto privo di MMU e/o di meccanismi di protezione della memoria, e si comporterà sempre allo stesso modo (leggi: trovo NULL come valore di una variabile che dovrebbe essere una lista, e mi blocco perché non posso proseguire con l'operazione di estrazione di un suo elemento), mentre con un'applicazione scritta in un linguaggio non managed sullo stesso sistema potresti non accorgerti mai del bug presente nella tua applicazione (che, quindi, rimarrebbe bacata), se non tramite un qualche effetto collaterale che dovesse spuntar fuori (se sei fortunato :D ).

Io le vedo come cose nettamente diverse.
tutto quello che hai detto però è irrilevante ai fini di imparare a programmare... in pratica volevo dire che "spostare" il problema non significa risolverlo.
dal punto di vista didattico i segmentation fault sono del tutto equivalenti ai null pointer: due modi diversi per dire che qualcosa non funziona e non si sa perchè :read:
python ha comportamenti anche più imprevedili di java per via del fatto che non viene fatto nessun check delle variabili in fase di compilazione e tutto è rilevato a runtime

[PGI-Bis]

null è la minima estensione del lattice, la sua esistenza è un bene e la controparte NullPointerException è quasi una meraviglia (dovrebbe essere checked, come tutte le eccezioni ma hanno avuto il cuore tenero).

Sui commenti, la faccenda ha dell'incredibile. Non ricordo precedenti discussioni in merito: forse le ho rimosse, come certi traumi d'infanzia.

L'acqua bagna, il fuoco scotta e non si commenta ciò che il fa il codice: è un'evidenza logica. Chi legge il codice al minimo conosce il linguaggio, altrimenti non leggerebbe ma vedrebbe e basta. Per questa ragione è superfluo il commento:

/* Creo la variabile intera x a cui assegno il valore 3 */
int x = 3;

Non perchè il codice si autocommenta ma perchè chi lo legge conosce il linguaggio dunque commentare il significato che hanno gli enunciati secondo il linguaggio usato è contraddittorio coi requisiti imposti dalla lettura del testo (presuppongo che Tizio conosca il linguaggio e poi descrivo le sue regole: c'è qualcosa che non va).

La questione è se il significato degli enunciati secondo le regole del linguaggio sia anche l'unica informazione necessaria per la comprensione del messaggio.

La risposta è certamente no. No per la natura della comunicazione. Mi fermo qui perchè la conoscenza dei sette elementi della comunicazione è cosa certamente nota ad ogni programmatore.

[marco.r]

Potresti essere più chiaro, cortesemente? Non riesco ad afferrarne il significato.

Grazie

Intendo dire che, perlomeno dal mio punto di vista, una variabile di un certo dovrebbe sempre puntare ad un oggetto valido, e non ammettere valori "nulli".
Un conto e' rappresentare un oggetto, un altro segnalarne l'assenza.
Ad esempio

Nulla vieta di forzare l'assenza di null con un wrapper, ma per me dovrebbe essere il comportamento di default visto che risparmia un sacco di errori senza complicare troppo la vita di chi e' abituato a sfruttare questa "feature".

Un esempio di linguaggio che si comporta in questo modo e' Haskell, in cui il "null" esiste, ma solo come valore di un particolare tipo, per cui se ad esempio voglio implementare il lookup per una tabella che mappa String in "Foo", non ritorno un valore "Foo", ma "Maybe Foo" perche' c'e' la possibilita' che non l' abbia trovato.

In Java "basterebbe" rendere obbligatoria l'inizializzazione con la dichiarazione o, per le classi, nel costruttore, e introdurre un oggetto parametrico apposito ( da usare tipo Maybe<String> ? ).

Qualcuno probabilmente inorridira' all'idea di usare un oggetto quando si puo' usare semplicemente un puntatore nullo, per via del costo aggiuntivo in termini di performance, ma io non mi preoccuperei. Innanzi tutto perche' con un po' di furbizia tale costo si riesce a minimizzare, e poi perche' in tutti gli altri casi ho la garanzia che il puntatore non e' mai nullo, cosa che permette al compilatore un maggior numero di ottimizzazioni.

[k0nt3]

comunque sia oltre al null c'è anche il casting delle variabili. tutte cose su cui prima o poi un programmatore alle prime armi sbatte la testa esattamente come l'avrebbe sbattuta con i segmentation faults (che poi non è mai morto nessuno per un segmentation fault :fagiano: ).
per non parlare del passaggio di variabili quando queste sono oggetti! :eek: (perchè in questo caso devi capire il concetto di puntatore senza averne mai visto uno nemmeno in fotografia)
[PROGRAMMATORE ALLE PRIME ARMI]
"ommioddio chissà cosa succede!! HEEEEEEEEELP!!!"
[/PROGRAMMATORE ALLE PRIME ARMI]

ciononostante ho votato pascal

ps. inoltre pare sempre più evidente che il risultato del sondaggio sarà rumore bianco

[^TiGeRShArK^]

comunque sia oltre al null c'è anche il casting delle variabili. tutte cose su cui prima o poi un programmatore alle prime armi sbatte la testa esattamente come l'avrebbe sbattuta con i segmentation faults (che poi non è mai morto nessuno per un segmentation fault :fagiano: ).
per non parlare del passaggio di variabili quando queste sono oggetti! :eek: (perchè in questo caso devi capire il concetto di puntatore senza averne mai visto uno nemmeno in fotografia)
[PROGRAMMATORE ALLE PRIME ARMI]
"ommioddio chissà cosa succede!! HEEEEEEEEELP!!!"
[/PROGRAMMATORE ALLE PRIME ARMI]

ciononostante ho votato pascal

ps. inoltre pare sempre più evidente che il risultato del sondaggio sarà rumore bianco
Il classcast exception grazie ai generics ( per quanto a volte letteralmente orribili ) viene rilevato al compile time.
Per il fatto dei nulll..
Mi spiegate come fare a far funzionare questo codice?

result = getTable("Prova")
formatTable(layoutTable, result)

Se result è null? :stordita:
E in teoria potrebbe essere anche un comportamento perfettamente lecito nel caso in cui il programmatore volesse stampare nel caso di risultato nullo una tabella con la formattazione nulla ma con tutti i valori di default per le varie colonne.
Per me eliminare i NullPointer a livello di linguaggio java è semplicemente impossibile dato che a volte gli oggetti null possono avere un loro uso per come la vedo io.

[cdimauro]

tutto quello che hai detto però è irrilevante ai fini di imparare a programmare... in pratica volevo dire che "spostare" il problema non significa risolverlo.
dal punto di vista didattico i segmentation fault sono del tutto equivalenti ai null pointer: due modi diversi per dire che qualcosa non funziona e non si sa perchè :read:
Questo, però, suona più che altro come la definizione di "bug". ;)
python ha comportamenti anche più imprevedili di java per via del fatto che non viene fatto nessun check delle variabili in fase di compilazione e tutto è rilevato a runtime
Un controllo c'è di sicuro, ed è quello sull'utilizzo di una variabile prima che sia stata inizializzata.

Per il resto, dipende sempre da quello ci fai, visto che in Python una variabile non è strettamente legata a un dato, per cui può memorizzarci qualunque cosa. Esempio:
def Print():
for x in Value:
print x,

Value = [1, 2, 3]
Print() # OK, stampa "1 2 3" (senza virgolette)
Value = 1
Print() # Errore: elemento non iterabile
Value = 'Ciao'
Print() # OK, stampa "C i a o" (senza virgolette)
Value = None
Print() #Errore: elemento non iterabile
In soldoni, nessuno t'impedisce di utilizzare variabili precise per tipi ben definiti, ma nel momento in cui lo fai è chiaro che puoi andare incontro a problemi come quelli che saltano fuori dal pezzo di codice che ho postato. ;)

[cdimauro]

null è la minima estensione del lattice, la sua esistenza è un bene e la controparte NullPointerException è quasi una meraviglia (dovrebbe essere checked, come tutte le eccezioni ma hanno avuto il cuore tenero).
Potresti essere più chiaro (mi sa che oggi non è proprio giornata :p), cortesemente?
Sui commenti, la faccenda ha dell'incredibile. Non ricordo precedenti discussioni in merito: forse le ho rimosse, come certi traumi d'infanzia.
Possibile. Ne parlò fek tempo fa, anche qui in Programmazione (inutile dire che in Diamonds ha ripetuto il concetto innumerevoli volte :D).
L'acqua bagna, il fuoco scotta e non si commenta ciò che il fa il codice: è un'evidenza logica. Chi legge il codice al minimo conosce il linguaggio, altrimenti non leggerebbe ma vedrebbe e basta. Per questa ragione è superfluo il commento:

/* Creo la variabile intera x a cui assegno il valore 3 */
int x = 3;

Non perchè il codice si autocommenta ma perchè chi lo legge conosce il linguaggio dunque commentare il significato che hanno gli enunciati secondo il linguaggio usato è contraddittorio coi requisiti imposti dalla lettura del testo (presuppongo che Tizio conosca il linguaggio e poi descrivo le sue regole: c'è qualcosa che non va).
Questo è ovvio, ma nel caso del pezzo di codice che hai posto non è sufficiente per rispondere alla domanda: "a che serve x?" Pur essendo evidente che è una variabile di tipo intero a cui gli viene attribuito valore 3.
La questione è se il significato degli enunciati secondo le regole del linguaggio sia anche l'unica informazione necessaria per la comprensione del messaggio.

La risposta è certamente no. No per la natura della comunicazione.
Se ho capito bene, la domanda che ho posto prima sul significato di x risponde allo stesso quesito.
Mi fermo qui perchè la conoscenza dei sette elementi della comunicazione è cosa certamente nota ad ogni programmatore.
No, pur essendo un programmatore non ne ho mai sentito parlare (a questo punto dovrei incazzarmi con l'università).
Hai qualche link sull'argomento, o al limite, se hai tempo e voglia, potresti spiegare quali sarebbero?

Grazie :D

[ndakota]

dai su che forse si riesce a farli arrivare tutti alla pari :D

[cdimauro]

Intendo dire che, perlomeno dal mio punto di vista, una variabile di un certo dovrebbe sempre puntare ad un oggetto valido, e non ammettere valori "nulli".
Un conto e' rappresentare un oggetto, un altro segnalarne l'assenza.
Ad esempio

Nulla vieta di forzare l'assenza di null con un wrapper, ma per me dovrebbe essere il comportamento di default visto che risparmia un sacco di errori senza complicare troppo la vita di chi e' abituato a sfruttare questa "feature".

Un esempio di linguaggio che si comporta in questo modo e' Haskell, in cui il "null" esiste, ma solo come valore di un particolare tipo, per cui se ad esempio voglio implementare il lookup per una tabella che mappa String in "Foo", non ritorno un valore "Foo", ma "Maybe Foo" perche' c'e' la possibilita' che non l' abbia trovato.

In Java "basterebbe" rendere obbligatoria l'inizializzazione con la dichiarazione o, per le classi, nel costruttore, e introdurre un oggetto parametrico apposito ( da usare tipo Maybe<String> ? ).

Qualcuno probabilmente inorridira' all'idea di usare un oggetto quando si puo' usare semplicemente un puntatore nullo, per via del costo aggiuntivo in termini di performance, ma io non mi preoccuperei. Innanzi tutto perche' con un po' di furbizia tale costo si riesce a minimizzare, e poi perche' in tutti gli altri casi ho la garanzia che il puntatore non e' mai nullo, cosa che permette al compilatore un maggior numero di ottimizzazioni.
No, non c'è di che inorridire perché è evidente che in queste condizioni un compilatore genera codice più efficiente (salterebbero tutti i controlli che aggiunge automaticamente per vedere se un oggetto è "nullo" prima di utilizzarlo).

Il punto però è un altro: questo comportamento (costringere a inizializzare una variabile) è SEMPRE desiderabile? Ovviamente lasciando perdere linguaggi come Python in cui una variabile può contenere dati di qualunque tipo che cambiano dinamicamente.

Su questo ho qualche dubbio, ma "a naso" mi sembrerebbe di sì.

[cdimauro]

comunque sia oltre al null c'è anche il casting delle variabili. tutte cose su cui prima o poi un programmatore alle prime armi sbatte la testa esattamente come l'avrebbe sbattuta con i segmentation faults (che poi non è mai morto nessuno per un segmentation fault :fagiano: ).
Questo vale esclusivamente per i linguaggi per cui esiste il concetto di casting. ;)

In Python non c'è, ad esempio: puoi soltanto convertire un valore da un tipo ad un altro (posto che esista qualche costruttore che sia in grado di farlo). :p
per non parlare del passaggio di variabili quando queste sono oggetti! :eek: (perchè in questo caso devi capire il concetto di puntatore senza averne mai visto uno nemmeno in fotografia)
Non vedo perché andare a scomodare sempre i puntatori. Infatti si parla spesso di "valori" e "riferimenti", a seconda del caso / contesto.

In Pascal abbiamo questi casi:
type
PInteger = ^Integer;
procedure Qui(Valore: Integer);
procedure Quo(var Valore: Integer);
procedure Qua(Valore: PInteger);
Il primo è un passaggio per valore e il secondo per riferimento.
Il terzo è sempre un passaggio per valore, ma il valore trasportato è un puntatore a un dato di tipo Integer. Questo, però, è ben diverso dal passaggio per riferimento. Infatti puoi scrivere:
var
X: Integer;
begin
X := 1;
Qui(X);
Quo(X);
Qua(@X);
Qua(nil);
end;
Ma NON puoi scrivere:
Quo(nil);
;)
[PROGRAMMATORE ALLE PRIME ARMI]
"ommioddio chissà cosa succede!! HEEEEEEEEELP!!!"
[/PROGRAMMATORE ALLE PRIME ARMI]

ciononostante ho votato pascal
Mah. Nonostante a scuola abbia iniziato con questo bel linguaggio, non convidivo la scelta (per quello che ho scritto in precedenza, e in particolare nell'altro thread).
ps. inoltre pare sempre più evidente che il risultato del sondaggio sarà rumore bianco
Perché, come avevo già detto, la questione è stata mal posta.

Molto meglio sarebbe stato aprire un thread in cui si pone un problema, e si sottopongono le soluzioni nei diversi linguaggi di programmazione che conosciamo per vedere quello che lo risolve in maniera più semplice e comprensibile. ;)

[PGI-Bis]

Lattice: teoria dei tipi, preso l'insieme dei dati computabili un tipo di dato si crea con la definizione di un insieme di operazioni applicabili. Il sottoinsieme così creato è detto bolla. In un sistema di tipi, l'insieme delle bolle è detto lattice. La minima estensione del lattice è l'insieme vuoto che è per definizione elemento di ogni bolla e, dunque, compatibile con ogni tipo. Tale insieme vuoto è espresso nei vari linguaggi con l'elemento nil, null, nihil eccetera. La massima estensione del lattice è invece la radice del sistema dei tipi. Ad esempio in Python la minima estensione del lattice è None e la massima è (credo) Object.

Bisognerebbe arrabbiarsi con le università. Non lo so, io non ho fatto informatica. Ma se è vero che non esiste una cattedra di informatica comparata allora molto si spiegherebbe.

Quanto ai sette elementi della comunicazione, rompo la tradizione che mi vede sbrodolare fiumi di parole in thread altrui. Devo rimandarti ad un libro di grammatica perchè non ho collegamenti internet da dare. Uno qualsiasi va bene. Una cosa affascinante della grammatica è che la sua versione moderna esiste da circa tremila anni. E' tra le più antiche e solide fondamenta del sapere.

[cdimauro]

Mi spiegate come fare a far funzionare questo codice?

result = getTable("Prova")
formatTable(layoutTable, result)

Se result è null? :stordita:
E in teoria potrebbe essere anche un comportamento perfettamente lecito nel caso in cui il programmatore volesse stampare nel caso di risultato nullo una tabella con la formattazione nulla ma con tutti i valori di default per le varie colonne.
Per me eliminare i NullPointer a livello di linguaggio java è semplicemente impossibile dato che a volte gli oggetti null possono avere un loro uso per come la vedo io.
Dipende da quello che ci vuoi fare. Nessuno t'impedisce di crearti un'istanza ad hoc per indicare un valore "nullo" da restituire quando un elemento non viene trovato.

In questo modo potresti sempre sapere se c'è una qualche condizione "speciale" (l'assenza del dato), ma col pregevole vantaggio di non avere mai a che fare con valori (o puntatori) nulli. ;)

Sempre se ho capito bene il concetto che voleva far passare Marco, eh! :p

[k0nt3]

Questo, però, suona più che altro come la definizione di "bug". ;)
esatto, non esiste linguaggio di programmazione che non ti fa sbattere la testa. per cui trovo sbagliato sconsigliare il C per via del "segmentation fault" significa soltanto spostare il problema senza risolverlo

Un controllo c'è di sicuro, ed è quello sull'utilizzo di una variabile prima che sia stata inizializzata.

un pò pochino.. di solito uno che impara ad andare con la bicicletta inizia usando delle rotelle per non cadere :p

Per il resto, dipende sempre da quello ci fai, visto che in Python una variabile non è strettamente legata a un dato, per cui può memorizzarci qualunque cosa. Esempio:
def Print():
for x in Value:
print x,

Value = [1, 2, 3]
Print() # OK, stampa "1 2 3" (senza virgolette)
Value = 1
Print() # Errore: elemento non iterabile
Value = 'Ciao'
Print() # OK, stampa "C i a o" (senza virgolette)
Value = None
Print() #Errore: elemento non iterabile
In soldoni, nessuno t'impedisce di utilizzare variabili precise per tipi ben definiti, ma nel momento in cui lo fai è chiaro che puoi andare incontro a problemi come quelli che saltano fuori dal pezzo di codice che ho postato. ;)
mi spieghi a cosa serve poter assegnare alla stessa variabile qualsiasi tipo di dato? in C con le union si può fare questa cosa dichiarando però esplicitamente i tipi di dato, mentre in java la questione è risolta usando le interfaccie
in poche parole non mi sembra che python ne tragga qualche vantaggio da questo aspetto

[cdimauro]

Lattice: teoria dei tipi, preso l'insieme dei dati computabili un tipo di dato si crea con la definizione di un insieme di operazioni applicabili. Il sottoinsieme così creato è detto bolla. In un sistema di tipi, l'insieme delle bolle è detto lattice. La minima estensione del lattice è l'insieme vuoto che è per definizione elemento di ogni bolla e, dunque, compatibile con ogni tipo. Tale insieme vuoto è espresso nei vari linguaggi con l'elemento nil, null, nihil eccetera. La massima estensione del lattice è invece la radice del sistema dei tipi. Ad esempio in Python la minima estensione del lattice è None e la massima è (credo) Object.
Sì, è corretto.

Dalla definizione che hai dato il concetto di "elemento nullo" di cui parlava Marco non sarebbe applicabile, visto che dipende strettamente dal tipo di dato con cui si sta lavorando (ne dovrebbe esistere uno per ogni tipo di dato).
Bisognerebbe arrabbiarsi con le università. Non lo so, io non ho fatto informatica. Ma se è vero che non esiste una cattedra di informatica comparata allora molto si spiegherebbe.
Ne ho sentito parlare, ma ai miei tempi non c'era nella mia università.
Quanto ai sette elementi della comunicazione, rompo la tradizione che mi vede sbrodolare fiumi di parole in thread altrui. Devo rimandarti ad un libro di grammatica perchè non ho collegamenti internet da dare. Uno qualsiasi va bene. Una cosa affascinante della grammatica è che la sua versione moderna esiste da circa tremila anni. E' tra le più antiche e solide fondamenta del sapere.
Ma LOL. Vedo un po' quello che riesco a trovare non appena ho un po' di tempo per cercare qualcosa. :p

Grazie per le spiegazioni. :)

[k0nt3]

Questo vale esclusivamente per i linguaggi per cui esiste il concetto di casting. ;)

In Python non c'è, ad esempio: puoi soltanto convertire un valore da un tipo ad un altro (posto che esista qualche costruttore che sia in grado di farlo). :p

il fatto che sia implicito non significa che non c'è

Non vedo perché andare a scomodare sempre i puntatori. Infatti si parla spesso di "valori" e "riferimenti", a seconda del caso / contesto.

perchè gli oggetti sono puntatori in fin dei conti, se non capisci i puntatori non capirai nemmeno gli oggetti (fino in fondo). mi sembra molto più semplice capire cosa succede passando come parametro il numero 6 piuttosto che l'oggetto Automobile che è qualcosa di complesso.

Mah. Nonostante a scuola abbia iniziato con questo bel linguaggio, non convidivo la scelta (per quello che ho scritto in precedenza, e in particolare nell'altro thread).

era solo la mia opinione, non penso la verità assoluta

Perché, come avevo già detto, la questione è stata mal posta.

o forse perchè è una domanda senza una risposta esatta

Molto meglio sarebbe stato aprire un thread in cui si pone un problema, e si sottopongono le soluzioni nei diversi linguaggi di programmazione che conosciamo per vedere quello che lo risolve in maniera più semplice e comprensibile. ;)
sarebbe come scrivere "ciao quanti anni hai?" in 20 lingue diverse e cercare di stabilire qual'è la lingua migliore
eppure qualcuno continuerà a parlare aramaico antico :fagiano:

[cdimauro]

esatto, non esiste linguaggio di programmazione che non ti fa sbattere la testa. per cui trovo sbagliato sconsigliare il C per via del "segmentation fault" significa soltanto spostare il problema senza risolverlo
No, piuttosto si tratterebbe di eliminare una classe di problemi, e pure piuttosto rognosa da risolvere. ;)
un pò pochino.. di solito uno che impara ad andare con la bicicletta inizia usando delle rotelle per non cadere :p
Ma proprio per questo Python è anche un linguaggio fortemente tipizzato. Al contrario del C. ;)
mi spieghi a cosa serve poter assegnare alla stessa variabile qualsiasi tipo di dato? in C con le union si può fare questa cosa dichiarando però esplicitamente i tipi di dato, mentre in java la questione è risolta usando le interfaccie
in poche parole non mi sembra che python ne tragga qualche vantaggio da questo aspetto
Dipende sempre da quello che si vuole ottenere. Esempio:
for x in [1, 2, 3]: # Stampa "1 2 3" (senza virgolette)
print x,

for x in['Qui', 'Quo', 'Qua']: Stampa "Qui Quo Qua" (senza virgolette)
print x,

for x in[1, 2, 3, 'Qui', 'Quo', 'Qua']: Stampa "1 2 3 Qui Quo Qua" (senza virgolette)
print x,
Come vedi ho usato la STESSA variabile per poter iterare sugli elementi di ogni lista, e questo pur essendo composte di tipi diversi, o addirittura con la stessa lista che conserva dati di tipo diverso.

Con gli altri linguaggi nei primi due casi avrei avuto la necessità di dichiarare due variabili diverse; il terzo caso, invece, sarebbe stato impossibile (a meno di creare una classe che dia la possibilità di memorizzare indifferentemente interi o stringhe).

Il vantaggio è l'estrema semplicità.

Poi è chiaro che, per com'è fatto Python, non è soltanto un vantaggio, ma una necessità (vedi terzo caso, appunto). ;)

[PGI-Bis]

I linguaggi amorfi (cioè quelli le cui espressioni non hanno un tipo, come python) hanno un senso nel momento in cui permettono di definire l'appartenenza di un dato ad un tipo a prescindere dalla sua dichiarazione di classe.

E' una cosa notevolmente espressa in Chapel, lingua che Cray sta sviluppando per il progetto Darpa HCPS ma non è l'unico.

In pratica si tratta della capacità di qualificare un dato come appartenente ad un tipo non perchè il dato dichiara di essere un T ma perchè al dato è applicabile un'operazione P.

Come dire che il cane cammina, il gatto cammina, sia il cane che il gatto sono dei camminanti a prescindere dal fatto che il genere dei camminanti preesistesse alla creazione del cane e del gatto.

Può sembrare un'inezia ma risolve l'enorme problema dei ruoli. L'esempio classico è Mario lavora per l'azienda Acme ed è un Ingegnere, è un Dipendente, è un Dirigente.

Molti libri dicono che questa situazione deve essere rappresentata dicendo che Mario lavora per l'azienda Acme ed ha il ruolo di Ingegnere, Dipendente, Dirigente. Ciò consente a Mario di assumere o perdere qualifiche a prescindere dal suo tipo. E' un "trick": in verità il modo umano di vedere le cose non è rigidamente gerarchico, come si riteneva negli anni '60, quando nacque la OOP. E' fluidamente gerarchico. Mario è un Ingegnere, Dipendente, Dirigente, solo che ad un certo punto può non esserlo più. Ecco, qui entra in gioco l'amorfismo.

L'elemento nullo di marco "va bene" (o, meglio, corrisponde alla minima estensione del lattice, poi non è che per questo vada bene o male) perchè è generico. La sua definizione sarebbe "Maybe T", con T dichiarazione di tipo. Se è compatibile con ogni tipo ma inerte rispetto ad ogni operazione allora è anche la minima estensione del lattice. Vale perchè anche i tipi di dato sono a loro volta dati per la teoria dei tipi. In più, con la dichiarazione di tipo, cioè dicendo:

Maybe String

otterremo un dato che è la minima estensione della bolla. Compatibile con ogni dato della bolla ma inerte rispetto alle sue operazioni.

[cdimauro]

il fatto che sia implicito non significa che non c'è
Il fatto è che NON c'è proprio il casting in Python. Il tutto avviene tramite l'uso di opportuni costruttori (o eventualmente con metodi che sono in grado di manipolare oggetti di un certo tipo e che sono in grado di effettuare la conversione a un tipo "base" se se ne presentasse la necessità, ma sempre tramite l'uso di costruttori ad hoc).
perchè gli oggetti sono puntatori in fin dei conti, se non capisci i puntatori non capirai nemmeno gli oggetti (fino in fondo). mi sembra molto più semplice capire cosa succede passando come parametro il numero 6 piuttosto che l'oggetto Automobile che è qualcosa di complesso.
Questa è una cosa strettamente personale. Tra l'altro, come dicevo, non è affatto necessario tirare in ballo i puntatori per spiegare il passaggio per riferimento.
era solo la mia opinione, non penso la verità assoluta

o forse perchè è una domanda senza una risposta esatta
Si può provare a fornirne qualcuna e valutarla, ma se ci si limita a dire "Pascal" (o C, C++, linguaggio macchina :D, ecc.) senza giustificazione, nel thread rimarrà, appunto, soltanto il rumore bianco.
sarebbe come scrivere "ciao quanti anni hai?" in 20 lingue diverse e cercare di stabilire qual'è la lingua migliore
eppure qualcuno continuerà a parlare aramaico antico :fagiano:
Le lingue non hanno tutte la stessa complessità, e dunque facilità o meno di apprendimento. ;)

Ecco perché la domanda è mal posta e suggerivo di procedere con degli esempi.

Poi è chiaro che ognuno, alla fine, potrà continuare a fare quello che vuole. :Prrr:

[k0nt3]

No, piuttosto si tratterebbe di eliminare una classe di problemi, e pure piuttosto rognosa da risolvere. ;)

senza dimenticare che si introducono altrettante classi di problemi ;)
programmare è risolvere problemi, che senso ha cercare di evitarli?

Ma proprio per questo Python è anche un linguaggio fortemente tipizzato. Al contrario del C. ;)

certo, ogni linguaggio ha i suoi pregi e i suoi difetti

Dipende sempre da quello che si vuole ottenere. Esempio:

Come vedi ho usato la STESSA variabile per poter iterare sugli elementi di ogni lista, e questo pur essendo composte di tipi diversi, o addirittura con la stessa lista che conserva dati di tipo diverso.

Con gli altri linguaggi nei primi due casi avrei avuto la necessità di dichiarare due variabili diverse; il terzo caso, invece, sarebbe stato impossibile (a meno di creare una classe che dia la possibilità di memorizzare indifferentemente interi o stringhe).

in C si risolve usando le union e in java usando banalmente (e un pò grezzamente) un array di oggetti. ma qui il problema è che non ne vedo l'utilità :fagiano:

Il vantaggio è l'estrema semplicità.

Poi è chiaro che, per com'è fatto Python, non è soltanto un vantaggio, ma una necessità (vedi terzo caso, appunto). ;)
per il mio modo di vedere le cose più è semplice quello che devi scrivere per ottenere la soluzione e più è complesso il significato di quello che hai scritto
ci vuole un giusto compromesso e mi pare che python sia un pò estremo da questo punto di vista

[Matrixbob]

Ti segnalo d'interesse anche:
Quali linguaggi usate nel vostro lavoro (leggete il primo post per i dettagli)? (http://www.hwupgrade.it/forum/showthread.php?t=1311007)
Cosa preferite: CygWin o MinGW?! (http://www.hwupgrade.it/forum/showthread.php?t=1332090)
[IMPORTANTE] Gli "Integrated Development Environment" che preferite?! (http://www.hwupgrade.it/forum/showthread.php?t=1318098)

[cdimauro]

I linguaggi amorfi (cioè quelli le cui espressioni non hanno un tipo, come python) hanno un senso nel momento in cui permettono di definire l'appartenenza di un dato ad un tipo a prescindere dalla sua dichiarazione di classe.

E' una cosa notevolmente espressa in Chapel, lingua che Cray sta sviluppando per il progetto Darpa HCPS ma non è l'unico.

In pratica si tratta della capacità di qualificare un dato come appartenente ad un tipo non perchè il dato dichiara di essere un T ma perchè al dato è applicabile un'operazione P.

Come dire che il cane cammina, il gatto cammina, sia il cane che il gatto sono dei camminanti a prescindere dal fatto che il genere dei camminanti preesistesse alla creazione del cane e del gatto.

Può sembrare un'inezia ma risolve l'enorme problema dei ruoli. L'esempio classico è Mario lavora per l'azienda Acme ed è un Ingegnere, è un Dipendente, è un Dirigente.

Molti libri dicono che questa situazione deve essere rappresentata dicendo che Mario lavora per l'azienda Acme ed ha il ruolo di Ingegnere, Dipendente, Dirigente. Ciò consente a Mario di assumere o perdere qualifiche a prescindere dal suo tipo. E' un "trick": in verità il modo umano di vedere le cose non è rigidamente gerarchico, come si riteneva negli anni '60, quando nacque la OOP. E' fluidamente gerarchico. Mario è un Ingegnere, Dipendente, Dirigente, solo che ad un certo punto può non esserlo più. Ecco, qui entra in gioco l'amorfismo.
Hai centrato perfettamente il nocciolo della questione. :p

La cosa bellissima di Python è proprio il fatto che sia amorfo, secondo la definizione (e l'esempio) che hai dato.

Tempo fa avevo un problema da risolvere, e mi serviva una classe (da dare in pasto ad alcune funzioni) che permettesse di leggere dati con la stessa interfaccia dei file, ma da una stringa (quindi i dati erano memorizzati in una stringa).
Insomma, quello che in altri linguaggi viene definito MemoryStream, StringStream, o qualcosa di simile.

Al di là del fatto che esisteva il modulo StringIO che esponeva la classe StringIO (e io ero proprio cecato per non vederla, visto che me ne sono accorto soltanto dopo un bel po' di tempo, a cose fatte :p), alla fine mi sono detto: "Quanto sono coglione! Ma non basta che i miei oggetti espongano il metodo read()?" e così ho fatto. :D

A volte le cose più semplici sono le meno ovvie e più sfuggenti, quando si è abituati a ragionare sempre in un certo modo. :muro: :p
L'elemento nullo di marco "va bene" (o, meglio, corrisponde alla minima estensione del lattice, poi non è che per questo vada bene o male) perchè è generico. La sua definizione sarebbe "Maybe T", con T dichiarazione di tipo. Se è compatibile con ogni tipo ma inerte rispetto ad ogni operazione allora è anche la minima estensione del lattice. Vale perchè anche i tipi di dato sono a loro volta dati per la teoria dei tipi. In più, con la dichiarazione di tipo, cioè dicendo:

Maybe String

otterremo un dato che è la minima estensione della bolla. Compatibile con ogni dato della bolla ma inerte rispetto alle sue operazioni.
Chiarissimo. Grazie :)

[k0nt3]

Si può provare a fornirne qualcuna e valutarla, ma se ci si limita a dire "Pascal" (o C, C++, linguaggio macchina :D, ecc.) senza giustificazione, nel thread rimarrà, appunto, soltanto il rumore bianco.

io dico pascal perchè è un linguaggio semplice quanto il C, ma con le rotelle per non cadere :cool:

Le lingue non hanno tutte la stessa complessità, e dunque facilità o meno di apprendimento. ;)

Ecco perché la domanda è mal posta e suggerivo di procedere con degli esempi.

Poi è chiaro che ognuno, alla fine, potrà continuare a fare quello che vuole. :Prrr:
questo mi sembra il punto chiave.. la velocità di apprendimento non è l'unico metro di paragone. altrimenti VB6 è forse il miglior linguaggio in assoluto :doh: (non fatemi bestemmiare per favore :) )

[cdimauro]

senza dimenticare che si introducono altrettante classi di problemi ;)
Nel caso in cui dovesse succedere, bisognerebbe vedere il rapporto costi / benefici.
programmare è risolvere problemi, che senso ha cercare di evitarli?
Perché ci sono problemi più o meno "complicati".
in C si risolve usando le union e in java usando banalmente (e un pò grezzamente) un array di oggetti. ma qui il problema è che non ne vedo l'utilità :fagiano:

per il mio modo di vedere le cose più è semplice quello che devi scrivere per ottenere la soluzione e più è complesso il significato di quello che hai scritto
ci vuole un giusto compromesso e mi pare che python sia un pò estremo da questo punto di vista
Punti di vista, appunto. Nel codice che ho scritto prima vedo un'enorme semplicità che non ne rende assolutamente complesso il significato.
Anzi, la mancanza della definizione del tipo di una variabile permette di far traspire un concetto di elementare comprensione: quello dell'assegnazione di un dato a una variabile.

In C e Java avresti dovuto complicarti, questo sì, la vita per poter gestire sia gli interi che le stringhe, e questo giusto per due tipi: se dovessimo estendere il concetto a QUALUNQUE tipo di dato, capisci bene che la complessità del codice risultante sarebbe decisamente elevata. ;)

[cdimauro]

io dico pascal perchè è un linguaggio semplice quanto il C, ma con le rotelle per non cadere :cool:
Anche per i puntatori e con tutte le loro implicazioni? ;)
questo mi sembra il punto chiave.. la velocità di apprendimento non è l'unico metro di paragone. altrimenti VB6 è forse il miglior linguaggio in assoluto :doh: (non fatemi bestemmiare per favore :) )
Il BASIC ha un suo fascino, ed è un linguaggio managed, ma certamente la versione 6 è abbastanza datata e offre pochi costrutti di alto livello anche soltanto confrontandolo con la versione 2005.

Comunque il problema che poni è diverso. La velocità di apprendimento, e quindi l'assimilazione dei concetti "di base" della programmazione è lo scopo del thread, mentre il "grado di sicurezza" offerto da un linguaggio è tutt'altra cosa (e meriterebbe anch'esso una discussione a parte). ;)

[k0nt3]

quando io dichiaro una variabile so già che tipo di dato deve contenere.. continuo a non capire il senso dell'amorfismo :huh: (per dire.. è difficile che metto un oggetto di tipo Struzzo in una variabile che si chiama dataDiCompleanno)

ps. ma perchè i sostenitori di VB votano e scappano? :asd:

[cdimauro]

quando io dichiaro una variabile so già che tipo di dato deve contenere..
Questo lo puoi fare anche con Python, SE VUOI. E quindi NON cambierebbe nulla rispetto a C, Java, Pascal, ecc.

In più, sempre se vuoi, hai la possibilità di poter "cambiare il tipo" (e in questo caso risolveresti in maniera semplice e veloce il problema del terzo tipo di iterazione che avevo esposto ;)).
continuo a non capire il senso dell'amorfismo :huh:
Leggiti il messaggio di PGI-Bis sull'argomento, perché espone la questione in maniera molto semplice e comprensibile. :)
(per dire.. è difficile che metto un oggetto di tipo Struzzo in una variabile che si chiama dataDiCompleanno)
Questo lo puoi fare con qualunque linguaggio! :p
ps. ma perchè i sostenitori di VB votano e scappano? :asd:
In effetti è alquanto strano, considerato che BASIC è un acronimo con un ben preciso significato. :p

[k0nt3]

In effetti è alquanto strano, considerato che BASIC è un acronimo con un ben preciso significato. :p
non so io non ho mai parlato di BASIC in questo thread :fagiano:

[cdimauro]

EDIT: doppio. :muro:

[cdimauro]

non so io non ho mai parlato di BASIC in questo thread :fagiano:
VB = VisualBASIC, no? ;)

[k0nt3]

VB = VisualBASIC, no? ;)
si e VisualBASIC è diverso da BASIC e anche da VB.NET
meglio precisare

[cdimauro]

VisualBASIC è un'estensione (in genere si preferisce chiamarli "dialetti") del BASIC, e VB.NET è un'estensione del VisualBASIC.

Dunque, quale sarebbe il problema? VB è pur sempre "BASIC".

http://en.wikipedia.org/wiki/BASIC ;)

[Fenomeno85]

io dico c perché è forse l'unico che puoi davvero implementare tutto. Si può partire da cose a basso livello fine ad arrivare a sistemi complessi.
Ovvio è limitato perché manca il filone delle classi e quindi sarebbe limitato e direi C++ ma un vero programmatore come non fa a non essersi incazzato almeno un paio di volte all'inizio perché le liste avevano qualche problema o giocando con i puntatori si sono fatte immense schifezze? :D
Adesso molti dicono JAVA ma a personalmente non piace preferisco l'ambiente .NET. Devo vedere se MOMO vale l'uso di C#.net

~§~ Sempre E Solo Lei ~§~

[Fenomeno85]

VisualBASIC è un'estensione (in genere si preferisce chiamarli "dialetti") del BASIC, e VB.NET è un'estensione del VisualBASIC.

Dunque, quale sarebbe il problema? VB è pur sempre "BASIC".

http://en.wikipedia.org/wiki/BASIC ;)

VB6 e VB.NET da quello che ho visto sono due mondi differenti.

~§~ Sempre E Solo Lei ~§~

[k0nt3]

VisualBASIC è un'estensione (in genere si preferisce chiamarli "dialetti") del BASIC, e VB.NET è un'estensione del VisualBASIC.

Dunque, quale sarebbe il problema? VB è pur sempre "BASIC".

http://en.wikipedia.org/wiki/BASIC ;)
mm può essere ma non mi sembra il caso di accomunare linguaggi così diversi come GW-BASIC e VB sotto la stessa etichetta
VB ha quel tipico approccio orientato agli eventi che (ad esempio) GW-BASIC non ha
allo stesso modo VB.NET non è una versione di VB, ma proprio un linguaggio differente

[cdimauro]

io dico c perché è forse l'unico che puoi davvero implementare tutto. Si può partire da cose a basso livello fine ad arrivare a sistemi complessi.
I linguaggi Turing-completi sono equipotenti. ;)
Ovvio è limitato perché manca il filone delle classi e quindi sarebbe limitato e direi C++ ma un vero programmatore come non fa a non essersi incazzato almeno un paio di volte all'inizio perché le liste avevano qualche problema o giocando con i puntatori si sono fatte immense schifezze? :D
I veri programmatori devono risolvere problemi, col miglior rapporto costi / benefici.
Adesso molti dicono JAVA ma a personalmente non piace preferisco l'ambiente .NET. Devo vedere se MOMO vale l'uso di C#.net

Mono. Comunque .NET non è C#. Esiste anche Python per .NET, ad esempio (chiamato IronPython), e tantissimi altri linguaggi che sono stati portati per questo framework.

[cdimauro]

VB6 e VB.NET da quello che ho visto sono due mondi differenti.
Dipende da come li vedi. In parte sono compatibili (ed esistono tool che permettono la conversione delle applicazioni dal primo al secondo), ma è "quello che c'è sotto" che è completamente diverso (il secondo è basato sul framework .NET, appunto, che differisce non poco dalla classica piattaforma win32).

Comunque rimangono sempre dialetti del BASIC, e il secondo è largamente compatibile col primo (diciamo che la compatibilità dipende spesso dalle porcate che sono state fatte :D).

[cdimauro]

mm può essere ma non mi sembra il caso di accomunare linguaggi così diversi come GW-BASIC e VB sotto la stessa etichetta
Li possiamo accomunare definendoli "BASIC"
VB ha quel tipico approccio orientato agli eventi che (ad esempio) GW-BASIC non ha
E' chiaro che ci sono delle differenze, altrimenti sarebbero la stessa cosa.
allo stesso modo VB.NET non è una versione di VB, ma proprio un linguaggio differente
Ne è un'estensione, e come linguaggio conserva una buona compatibilità col precedente.

[k0nt3]

Ne è un'estensione, e come linguaggio conserva una buona compatibilità col precedente.
questo significa qualcosa in VB?
Public Class ExampleClass

Public Shared Sub Main()
System.Console.WriteLine("Hello, World!")
End Sub

End Class
alla faccia della buona compatibilità :fagiano: comunque è OT

[cdimauro]

Leggi bene: avevo detto "come linguaggio" (che era sempre il contesto della discussione su BASIC et similia).

L'esempio che hai postato, poi, fa uso di una funzione della libreria standard di .NET, per cui è a dir poco ovvio che in VB non significhi nulla. :rolleyes:

[k0nt3]

Leggi bene: avevo detto "come linguaggio" (che era sempre il contesto della discussione su BASIC et similia).
allora avevo letto bene:
"Public Class ExampleClass" non significa niente in VB

[k0nt3]

e aggiungo che qualsiasi programma valido scritto in VB non è un programma valido scritto in VB.NET e viceversa.. difficile dire che uno è l'estensione dell'altro

[71104]

e aggiungo che qualsiasi programma valido scritto in VB non è un programma valido scritto in VB.NET e viceversa.. difficile dire che uno è l'estensione dell'altro se è per questo oggi si è anche detto che C++ è un sovrainsieme del C. notoriamente falso, ma solo a causa di qualche banalità semantica, tipo questa qua:

char asd[3] = "lol";

non mi ricordo se era in C++ che la stringa veniva troncata e in C che dava errore in compilazione o viceversa, comunque il punto del discorso è che bisogna ragionare in termini di sovrainsiemi dal punto di vista concettuale e/o funzionale.

[cdimauro]

allora avevo letto bene:
"Public Class ExampleClass" non significa niente in VB
Mi spieghi come puoi partire dal VB.NET e pretendere che il VB6, che è il linguaggio più vecchio, riconosca la nuova sintassi per definire una classe?
e aggiungo che qualsiasi programma valido scritto in VB non è un programma valido scritto in VB.NET e viceversa.. difficile dire che uno è l'estensione dell'altro
Qui stai nuovamente spostando la discussione dal LINGUAGGIO alle APPLICAZIONI.

Fermo restando che VB.NET come LINGUAGGIO è per BUONA PARTE compatibile con VB6, ho scritto che esistono dei wizard per portare una vecchia applicazione sul nuovo ambiente (che ovviamente non possono funzionare in tutti i casi).

Mi dici cosa c'è di non chiaro in quello che ho scritto, cortesemente?

[cdimauro]

se è per questo oggi si è anche detto che C++ è un sovrainsieme del C. notoriamente falso, ma solo a causa di qualche banalità semantica, tipo questa qua:

char asd[3] = "lol";

non mi ricordo se era in C++ che la stringa veniva troncata e in C che dava errore in compilazione o viceversa, comunque il punto del discorso è che bisogna ragionare in termini di sovrainsiemi dal punto di vista concettuale e/o funzionale.
L'avevo scritto io qui http://www.hwupgrade.it/forum/showpost.php?p=18289470&postcount=21 che il C++ è un superset del C, ma, se leggi bene la frase, avevo detto che
può fare ALMENO tutto quello che fa il C
Da ciò, sempre se l'italiano non è un optional, non mi pare che abbia detto che un sorgente scritto in C può essere tranquillamente compilabile da un compilatore C++.

Infatti ho usato la parola FARE, e non a caso.

Pesiamole bene le parole, quando scriviamo, e possibilmente facciamo lo stesso quando leggiamo.

[k0nt3]

Mi spieghi come puoi partire dal VB.NET e pretendere che il VB6, che è il linguaggio più vecchio, riconosca la nuova sintassi per definire una classe?

se VB.NET è un'estensione di VB però potrei pretendere il contrario (cosa non vera però)

Qui stai nuovamente spostando la discussione dal LINGUAGGIO alle APPLICAZIONI.

nono io parlo proprio di linguaggio, un qualsiasi sorgente scritto in VB non è valido in VB.NET

Fermo restando che VB.NET come LINGUAGGIO è per BUONA PARTE compatibile con VB6, ho scritto che esistono dei wizard per portare una vecchia applicazione sul nuovo ambiente (che ovviamente non possono funzionare in tutti i casi).

Mi dici cosa c'è di non chiaro in quello che ho scritto, cortesemente?
esistono anche programmi che traducono il VB in linguaggio macchina, ma non per questo direi che uno è l'estensione dell'altro.
tra l'altro teoricamente qualsiasi linguaggio si può tradurre in qualsiasi altro linguaggio e quindi tutti i linguaggi sarebbero uguali e questo thread sarebbe da chiudere.

ps. comunque sia i wizard di cui parli richiedono abbastanza spesso interventi manuali

[cdimauro]

se VB.NET è un'estensione di VB però potrei pretendere il contrario (cosa non vera però)

nono io parlo proprio di linguaggio, un qualsiasi sorgente scritto in VB non è valido in VB.NET
Infatti ho detto che VB.NET ha una buona compatibilità con VB6 a livello di linguaggio. Il che NON vuol dire che un qualunque sorgente VB6 sia compilabile con VB.NET.
esistono anche programmi che traducono il VB in linguaggio macchina, ma non per questo direi che uno è l'estensione dell'altro.
tra l'altro teoricamente qualsiasi linguaggio si può tradurre in qualsiasi altro linguaggio e quindi tutti i linguaggi sarebbero uguali e questo thread sarebbe da chiudere.
Se è per questo esistono delle incompatibilità fra versioni successive di Python, ma non per questo ci si sogna di dire che la versione 2.5 non sia un'estensione della 2.4, la 2.4 della 2.3, e così via.

Capita, e non di rado, che la COMPATIBILITA' fra versioni successive dello stesso linguaggio e/o compilatore NON sia garantita per alcuni aspetti del linguaggio e/o librerie standard. Ergo: sorgenti che prima compilavano con la nuova versione non lo sono più.

Tornando al VB, il fatto che sorgenti VB6 non siano compilabili con VB.NET nulla toglie al fatto che quest'ultimo sia un'estensione del primo, e ne mantenga comunque una buona compatibilità (sempre a livello di linguaggio).
ps. comunque sia i wizard di cui parli richiedono abbastanza spesso interventi manuali
Non mi sembra di averlo negato e, anzi, da quello che ho scritto traspare che la traduzione non funziona sempre.

[xabraita12]

mi consigliate un compilatore C:rolleyes: :mbe:

[xabraita12]

qualcuno conosce il D sembra un linguaggio innovativo e per come ne parlano sembra potente, evero?

[k0nt3]

mmm non sembra mica male! quasi ci do un'occhiata :D ma forse qualcosa di più rodato è meglio per l'inizio

[Matrixbob]

mi consigliate un compilatore C:rolleyes: :mbe:

GCC su Linux
MinGW o CygWin su Win XP
CygWin su Win Vista

[cdimauro]

mi consigliate un compilatore C:rolleyes: :mbe:
Visual Studio C++ .NET 2005 Express Edition è molto diffuso, oppure Turbo CBuilder 2006.

Entrambi sono gratuiti, sono degli ambienti RAD molto potenti e permettono di sviluppare codice comodamente.

[cdimauro]

qualcuno conosce il D sembra un linguaggio innovativo e per come ne parlano sembra potente, evero?
E' un grosso passo avanti rispetto al C, introduce diverse cose che non si trovano neppure nel C++ (esempio: moduli e programmazione "by contract"), ma purtroppo è scarsissima la sua diffusione (io non conosco neppure un compilatore per questo linguaggio. Links are welcomed! :p)

[k0nt3]

E' un grosso passo avanti rispetto al C, introduce diverse cose che non si trovano neppure nel C++ (esempio: moduli e programmazione "by contract"), ma purtroppo è scarsissima la sua diffusione (io non conosco neppure un compilatore per questo linguaggio. Links are welcomed! :p)
basta andare sul sito ufficiale ;) http://digitalmars.com/d/dcompiler.html

[cdimauro]

Mumble. Strano. E' passato parecchio tempo da quando mi sono interessato al D, ma non ricordavo nessun link da cui scaricarlo.

Grazie! :)

[71104]

Links are welcomed! :p ORROREE!!! :eek: :eek: :eek: :mc:

:sofico:

[71104]

Visual Studio C++ .NET 2005 Express Edition è molto diffuso, oppure Turbo CBuilder 2006.

Entrambi sono gratuiti, sono degli ambienti RAD molto potenti e permettono di sviluppare codice comodamente. in Visual C++ 2005 Express però l'ambiente RAD è utilizzabile solo tramite Managed C++. se usi C semplice (come chiedeva lui) devi usare per forza Win32 nudo e crudo oppure fare una CUI. c'è da dire anche che la versione Professional mette a disposizione l'editor di risorse col quale è possibile creare dialog boxes in maniera RAD (che poi possono essere gestite anche solo in C tramite Win32), ma è un RAD estremamente limitato in confronto al designer delle Windows Forms.

[71104]

tra l'altro teoricamente qualsiasi linguaggio si può tradurre in qualsiasi altro linguaggio palesemente falso, suvvia...

e quindi tutti i linguaggi sarebbero uguali e questo thread sarebbe da chiudere. se anche ciò che hai detto prima fosse vero non implica che il thread debba essere chiuso.

[marco.r]

In pratica si tratta della capacità di qualificare un dato come appartenente ad un tipo non perchè il dato dichiara di essere un T ma perchè al dato è applicabile un'operazione P.

Come dire che il cane cammina, il gatto cammina, sia il cane che il gatto sono dei camminanti a prescindere dal fatto che il genere dei camminanti preesistesse alla creazione del cane e del gatto.

Da matematico con basi di informatica teorica abbastanza limitate, non sempre riesco a seguirti nei tuoi discorsi piu' teorici... detto questo il discorso che fai tu non mi sembra limitato solo ai linguaggi che chiami amorfi. Haskell, a cui accennavo sopra, permette di operare in modo analogo. Dovendo fare il controllo dei tipi durante la compilazione bisogna specificare un po' di cose, ma funziona egregiamente.
In pratica definisci delle "classi" (che hanno poco a che vedere con le omonime della OOP) di tipi che soddisfano alcune proprieta'. Supponendo che i camminanti di cui sopra siano quelli che hanno un certo numero di zampe e possono camminare, lo potresti definire in questo modo

class Camminante a where
cammina :: a -> IO ()
zampe :: a -> Int

salvo poi specificare per ogni tipo come questo avviene

instance Camminante Gatto where
cammina gatto = ...
zampe _ = 4

La cosa interessante e' che le queste proprieta' sono qualcosa di piu' generico di un metodo di una classe OOP, visto che il tipo di cui si parla potrebbe apparire nelle proprieta' come semplice parametro di un altro tipo, o come tipo di ritorno di una funzione.
Ad esempio la classe "Read" e' quella dei tipi che possono essere "letti da stringa", e il tipo che si definisce entra in gioco solo come risultato della lettura !

class Read a where
read :: String -> a

Abituati ai classici linguaggi orientati agli oggetti la cosa puo' apparire strana ("come faccio a sapere il tipo di ritorno se il l'argomento e' sempre una stringa?"), eppure funziona, e bene direi.
D'altra parte il type system di questo linguaggio si basa su studi piu' recenti rispetto a quelli della OOP (si parla degli anni '80) e probabilmente piu' vicini ai concetti che esprimevi prima.


L'elemento nullo di marco "va bene" (o, meglio, corrisponde alla minima estensione del lattice, poi non è che per questo vada bene o male) perchè è generico. La sua definizione sarebbe "Maybe T", con T dichiarazione di tipo. Se è compatibile con ogni tipo ma inerte rispetto ad ogni operazione allora è anche la minima estensione del lattice. Vale perchè anche i tipi di dato sono a loro volta dati per la teoria dei tipi. In più, con la dichiarazione di tipo, cioè dicendo:

Maybe String

otterremo un dato che è la minima estensione della bolla. Compatibile con ogni dato della bolla ma inerte rispetto alle sue operazioni.
Qua proprio non ti seguo, per cui dovro' documentarmi su quello di cui parli (almeno per arrivare a capire di cosa parli :D). Nel frattempo, visto che mi sembra mi stia dando ragione, diciamo che sono d'accordo. :D

[cdimauro]

Riflettendoci, l'unica cosa non mi quadra rispetto alla definizione di lattice e della sua minima estensione è che questa dovrebbe essere elemento di ogni bolla, mentre nel caso che tu esponevi ogni bolla ha la sua minima estensione, che quindi non è compatibile con tutte le bolle.

Vediamo cosa dice PGI-Bis a riguardo. :)

P.S. Haskell mi sembra interessante, ma non mi aggrada la sua sintassi. :Prrr:

[cdimauro]

ORROREE!!! :eek: :eek: :eek: :mc:

:sofico:
:wtf: Ehm, onestamente non l'ho capita... :stordita:

[cdimauro]

in Visual C++ 2005 Express però l'ambiente RAD è utilizzabile solo tramite Managed C++. se usi C semplice (come chiedeva lui) devi usare per forza Win32 nudo e crudo oppure fare una CUI. c'è da dire anche che la versione Professional mette a disposizione l'editor di risorse col quale è possibile creare dialog boxes in maniera RAD (che poi possono essere gestite anche solo in C tramite Win32), ma è un RAD estremamente limitato in confronto al designer delle Windows Forms.
Allora è meglio che usi Turbo C++ 2006. :cool:

[cdimauro]

palesemente falso, suvvia...
Già. A parte il fatto che non c'entrava col discorso (dal concetto di estensione s'è passato, o per meglio dire mischiato con, a quello di compatibilità & traduzione), se fosse vero avremmo risolto da tempo il problema delle traduzioni da una lingua a un'altra. :p

Ma anche rimanendo in ambito strettamente informatico, proprio il caso su cui puntava il dito, cioé della non perfetta conversione di un'applicazione da VB6 a VB.NET, dimostra la falsità tesi. ;)

[k0nt3]

palesemente falso, suvvia...

tutti i linguaggi di cui si sta parlando sono equipotenti, quindi sarà anche praticamente impossibile, ma io ho detto "teoricamente".

non ho capito in base a cosa uno può dire che VB.NET è un'estensione di VB visto che ogni programma scritto in VB non funziona con VB.NET e inoltre è pure abbastanza complicata la conversione da uno all'altro.

tornando a noi.. ho compilato il mio primo programma in D :Prrr:

[xabraita12]

allora io ora sono passato al C++ perche qua a bologna ma dappertutto compreso internet le risorse sul C sono molto scarsggianti
ho comprato un libro che avevo gia sentito nominare forse anche in questo forum
"fondamenti di C++" di Cay Horstman della McGraw-Hill spero di aver scelto la cosa giusta e per il fatto dell'OOP per ora non ho riscontrato problemi anche se non sono molto avanti e iizio abbastanza velocemente a entrare nell'ottica
dei 3 programmmi che ho provato(Pascal,C,C++) ho trovato il C++ molto superiore rispetto agli altri in globale:libri, risorse , internet e cosa cosi per non parlare poi del fatto che mi sembra un linguaggio molto potente( e infatti lo e)
prima di comprare il libro lo sfogliato un po e ho deciso questo tra altri due uno dell'Apogeo e l'altro non mi ricordo perche e quello che tratta bene il linguaggio dalle basi perfino del computer stesso spiegando dettagliatamente cosa succede quando il linguaggio viene "trasformato" in binario
spero di aver fatto la scelta giusti e i commenti sono ben accetti:Prrr: :Prrr: :read: :spam: :hic: :gluglu:

[cdimauro]

tutti i linguaggi di cui si sta parlando sono equipotenti, quindi sarà anche praticamente impossibile, ma io ho detto "teoricamente".
Anche teoricamente non lo è. Prendi un qualunque eseguibile per architettura x86 e traducilo in uno per architettura PPC, ad esempio.
non ho capito in base a cosa uno può dire che VB.NET è un'estensione di VB visto che ogni programma scritto in VB non funziona con VB.NET e inoltre è pure abbastanza complicata la conversione da uno all'altro.
Semplicemente perché, e lo ripeto ancora una volta, tu mischi assieme il concetto di ESTENSIONE (che era quello a cui mi sono sempre riferito) con quello di COMPATIBILITA' e TRADUZIONE/CONVERSIONE.

A meno che non mi DIMOSTRI che estendere implica NECESSARIAMENTE il mantenimento della compatibilità, ovviamente.
tornando a noi.. ho compilato il mio primo programma in D :Prrr:
Ottimo. Come linguaggio il D lo trovo decisamente più interessante del C++.

[k0nt3]

@xabraita12
da quello che scrivi sembri consapevole e convinto della tua scelta, quindi è la strada giusta ;)
il mio consiglio è quello di non pensare al c++ come un punto di arrivo, ma come un punto di inizio.. per esperienza ti posso dire che si possono prendere brutte abitudini con il c++ proprio a causa della sua estrema potenza
per evitare questo prova java una volta che hai dimestichezza con il c++, il passaggio non è traumatico, ma aiuta ad aprire la mente a nuovi orizzonti
intanto buona fortuna con il c++ :D

[marco.r]

P.S. Haskell mi sembra interessante, ma non mi aggrada la sua sintassi. :Prrr:
La sintassi è probabilmente un po' strana, ma penso sia tra le cose meno ostiche e "spiazzanti" del linguaggio. Sicuramente meno del fatto che in generale i dati non si possono modificare e che il linguaggio sia lazy ( però quando ci si abitua sono proprio le cose che si apprezzano di più ).
Il sistema dei tipi secondo me è un piccolo gioiello, tanto che piace a uno come me che di solito preferisce linguaggi più dinamici come python.

[cdimauro]

La sintassi è probabilmente un po' strana, ma penso sia tra le cose meno ostiche e "spiazzanti" del linguaggio. Sicuramente meno del fatto che in generale i dati non si possono modificare e che il linguaggio sia lazy ( però quando ci si abitua sono proprio le cose che si apprezzano di più ).
Il sistema dei tipi secondo me è un piccolo gioiello, tanto che piace a uno come me che di solito preferisce linguaggi più dinamici come python.
Avendo studiato il Prolog all'università la definizione delle funzioni in Haskell mi ha riportato alla mente quello delle clausole, per cui non mi ha spiazzato più di tanto. :D

Particolare attenzione, invece, va posta al fatto che sia un linguaggio puramente funzionale, per cui concordo con te: bisogna entrare nell'ottica per imparare che i dati sono immodificabili.

Sul sistema dei tipi non so: non ho avuto tempo per approfondire la conoscenza di Haskell (stamattina, dopo aver letto il tuo messaggio, ho leggiucchiato qualcosa dalla paginetta che ho trovato su wikipedia :p).

Comunque Haskell, IMHO, può piacere particolarmente a chi ha una formazione matematica. :)

[71104]

:wtf: Ehm, onestamente non l'ho capita... :stordita: nella frase che ho quotato la parola evidenziata era sgrammaticata :fagiano:

[71104]

tutti i linguaggi di cui si sta parlando sono equipotenti, quindi sarà anche praticamente impossibile, ma io ho detto "teoricamente". avrai anche detto "teoricamente" ma nella frase quotata non hai detto "tutti i linguaggi di cui si sta parlando", hai detto proprio tutti, nessuno escluso (compreso il brainfuck :asd: ).

[k0nt3]

evvabbè facciamo i pignoli adesso :fagiano:

ps. adesso che hai citato brainfuck non citare whitespace mi raccomando

[^TiGeRShArK^]

La sintassi è probabilmente un po' strana, ma penso sia tra le cose meno ostiche e "spiazzanti" del linguaggio. Sicuramente meno del fatto che in generale i dati non si possono modificare e che il linguaggio sia lazy ( però quando ci si abitua sono proprio le cose che si apprezzano di più ).
Il sistema dei tipi secondo me è un piccolo gioiello, tanto che piace a uno come me che di solito preferisce linguaggi più dinamici come python.
in ke senso i dati non si possono modificare? :stordita:

[cdimauro]

nella frase che ho quotato la parola evidenziata era sgrammaticata :fagiano:
Strano, perché la parola esiste: http://www.wordreference.com/enit/welcomed e l'intera frase si trova spesso http://www.google.com/search?hl=it&client=opera&rls=it&hs=S4f&q=%22Links+are+welcomed%22&btnG=Cerca&lr=

[cdimauro]

in ke senso i dati non si possono modificare? :stordita:
Nel senso che, ad esempio, se crei una lista di oggetti, rimane così com'è per l'intera sua esistenza.

Dai un'occhiata qui http://en.wikipedia.org/wiki/Purely_functional

[^TiGeRShArK^]

Nel senso che, ad esempio, se crei una lista di oggetti, rimane così com'è per l'intera sua esistenza.

Dai un'occhiata qui http://en.wikipedia.org/wiki/Purely_functional

capito :fagiano:
certo ke come sintassi è davvero orrida :stordita:

[71104]

Strano, perché la parola esiste: http://www.wordreference.com/enit/welcomed uh oh :|
mi ritiro con disonore :fagiano:

e l'intera frase si trova spesso http://www.google.com/search?hl=it&client=opera&rls=it&hs=S4f&q=%22Links+are+welcomed%22&btnG=Cerca&lr= bisogna vedere di che nazionalità è chi la scrive, visto che l'inglese di questi tempi è parlato da dogs&pigs :Prrr:


chiuso l'OT :stordita:

[marco.r]

capito :fagiano:
certo ke come sintassi è davvero orrida :stordita:
De gustibus..., comunque non giudicherei in base ad una sola funzione (tra l'altro scritta in modo pessimo secondo me...)

[AngeL)]

java :O

[marco.r]

No, non c'è di che inorridire perché è evidente che in queste condizioni un compilatore genera codice più efficiente (salterebbero tutti i controlli che aggiunge automaticamente per vedere se un oggetto è "nullo" prima di utilizzarlo).

Il controllo di solito lo fa l'hardware, per cui finche' non si incappa nel puntatore nullo costi non ce ne dovrebbero essere (almeno penso :p) . Pero' se sai che non sara' mai nullo puoi decidere di allocare direttamente sullo stack un oggetto invece che un suo riferimento, o fare una cosa analoga con i membri di una classe. In realta' si puo' fare gia' ora , ma solo quando si riesce a ricavare queste informazioni dal contesto, ad esempio quando nessun metodo fa "scappare" il puntatore di campo privato (o protected se la classe e' final).


Il punto però è un altro: questo comportamento (costringere a inizializzare una variabile) è SEMPRE desiderabile? Ovviamente lasciando perdere linguaggi come Python in cui una variabile può contenere dati di qualunque tipo che cambiano dinamicamente.

Su questo ho qualche dubbio, ma "a naso" mi sembrerebbe di sì.
Anche secondo me, pero' penso dipenda pure dal linguaggio... in C non ci sono molte alternative pratiche (a parte cambiare linguaggio si intende :D ).

[cdimauro]

Il controllo di solito lo fa l'hardware, per cui finche' non si incappa nel puntatore nullo costi non ce ne dovrebbero essere (almeno penso :p) .
Questo presuppone, appunto, che ci sia l'hardware a effettuare questo controllo, e noi (utilizzatori di PC desktop e/o di workstation et similia) siamo troppo ben abituati da questo punto di vista, ma non è sempre vero; tutt'altro.

Ecco perché un linguaggio managed, in questi casi, garantirebbe una notevole robustezza del sistema.
Pero' se sai che non sara' mai nullo puoi decidere di allocare direttamente sullo stack un oggetto invece che un suo riferimento, o fare una cosa analoga con i membri di una classe. In realta' si puo' fare gia' ora , ma solo quando si riesce a ricavare queste informazioni dal contesto, ad esempio quando nessun metodo fa "scappare" il puntatore di campo privato (o protected se la classe e' final).
Esatto ma, appunto, non sempre è possibile.
Anche secondo me, pero' penso dipenda pure dal linguaggio... in C non ci sono molte alternative pratiche (a parte cambiare linguaggio si intende :D ).
Appunto per questo non capisco come ci sia gente che continua a usare questo linguaggio da trogloditi informatici, visto che ne esistono validissime estensioni.

In ogni caso e tornando al discorso sui "valori nulli per ogni singolo tipo", con linguaggi che non permettono di forzare l'assegnazione di una variabile con un preciso valore, si può sempre ricorrre al Buon Senso (TM) :p e farlo a manina. ;)

P.S. Per quanto riguarda la sintassi di Haskell, come per tutte le cose è una questione di gusti.
A me non piace perché in generale non mi piacciono i linguaggi che usano troppi simboli nella sintassi (qui ci rientrano in massa tutti i derivati del C :D), spesso con significato "di non immediata comprensione".
Preferisco nettamente i linguaggi più autoesplicativi / chiari (es: di Python mi piace il fatto che il costruttore si chiami __init__, e il distruttore __del__: già il loro nome mi dà un'idea di quello che fanno; oppure in Pascal, meglio ancora, si usano le keyword "constructor" e "destructor" rispettivamente).
Insomma, un sorgente mi piace "leggerlo", quasi come se fosse un testo in lingua inglese, quindi senza dovermi contorcere i neuroni cercando di capire cosa fa.

[^TiGeRShArK^]

Questo presuppone, appunto, che ci sia l'hardware a effettuare questo controllo, e noi (utilizzatori di PC desktop e/o di workstation et similia) siamo troppo ben abituati da questo punto di vista, ma non è sempre vero; tutt'altro.

Ecco perché un linguaggio managed, in questi casi, garantirebbe una notevole robustezza del sistema.

Esatto ma, appunto, non sempre è possibile.

Appunto per questo non capisco come ci sia gente che continua a usare questo linguaggio da trogloditi informatici, visto che ne esistono validissime estensioni.

In ogni caso e tornando al discorso sui "valori nulli per ogni singolo tipo", con linguaggi che non permettono di forzare l'assegnazione di una variabile con un preciso valore, si può sempre ricorrre al Buon Senso (TM) :p e farlo a manina. ;)

P.S. Per quanto riguarda la sintassi di Haskell, come per tutte le cose è una questione di gusti.
A me non piace perché in generale non mi piacciono i linguaggi che usano troppi simboli nella sintassi (qui ci rientrano in massa tutti i derivati del C :D), spesso con significato "di non immediata comprensione".
Preferisco nettamente i linguaggi più autoesplicativi / chiari (es: di Python mi piace il fatto che il costruttore si chiami __init__, e il distruttore __del__: già il loro nome mi dà un'idea di quello che fanno; oppure in Pascal, meglio ancora, si usano le keyword "constructor" e "destructor" rispettivamente).
Insomma, un sorgente mi piace "leggerlo", quasi come se fosse un testo in lingua inglese, quindi senza dovermi contorcere i neuroni cercando di capire cosa fa.

io invece odio spassionatamente quei doppi underscore leading e trailing nel phyton :Prrr:
e ruby imho è anke + leggibile :p

[cdimauro]

io invece odio spassionatamente quei doppi underscore leading e trailing nel phyton :Prrr:
Li odiavo anch'io quando ho cominciato a lavorarci. :D Poi li ho apprezzati, e ti spiego il perché.

Python ha una MAREA di metodi speciali per le classi, che permettono di realizzare tutta una serie di cosette interessanti. Essendo metodi speciali, li si poteva trattare in 3 modi diversi:
- riservare delle keyword ad hoc (come fanno C++, Pascal/Delphi, ecc.);
- usare dei normali di metodi (come Ruby);
- introdurre una nomenclatura speciale (come è stato fatto in Pytho, appunto, coi __ all'inizio e alla fine).

Nel primo caso ci sarebbe stato un spreco di keyword e inoltre introducendo col tempo delle nuovo keyword sarebbe compromessa la compatibilità coi sorgenti già scritti che le usano (infatti in Python si cerca di evitare in tutti i modi di introdurre nuove keyword, se non strettamente necessario).

Nel secondo caso i metodi "speciali" si confondono con quelli "normali".

Nel terzo caso c'è la seccatura di aggiungere i __ all'inizio e alla fine, ma in compenso i metodi speciali saltano immediatamente all'occhio. Più ci si lavora, più si apprezza questa scelta, che è veramente comoda.
e ruby imho è anke + leggibile :p
Mah. Io storco il naso, e non poco. Già solo la nomenclatura degli identificatori rende il codice più ostico da leggere (e poi la forzatura di usare nomenclatura diversa per definire classi e variabili non la digerisco proprio).

A parte questo, Ruby è un linguaggio sostanzialmente orientato agli oggetti e nulla di più, mentre Python oltre a ciò offre anche la programmazione funzionale (si fanno cose molto interessanti e divertenti :D) e alla metaprogrammazione.
Con Ruby difficilmente riuscirei a esprimere alcune cose che in Python risolvo in maniera semplice, elegante e veloce (in questo periodo mi sto divertendo con i decoratori, ad esempio :p).

[xabraita12]

wow che successo che ha avuto sto sondaggio anche se ero devo dire che alla fine non lo preso molto di esempio (anche perche e impossibile dato che ancora non ci capisco niente di quello che dite:D :D :) :read: )

P.s.: mi spiegate brevemente cosa e la metaprogarrammazione e la differenza tra linguaggi maamged e non managed?

intanto col C++ va benisismo anche perche tratta molto bene la programmazione ad oggetti e spiega bene cosa e il libro che ho comprato:Prrr: :Prrr:

[AngeL)]

ma non si possono confrontare java e c++, dai...
java > c++ e basta :O

[cdimauro]

wow che successo che ha avuto sto sondaggio anche se ero devo dire che alla fine non lo preso molto di esempio (anche perche e impossibile dato che ancora non ci capisco niente di quello che dite:D :D :) :read: )
Quando tornerai a rileggere il thread fra un po' di tempo ti sarà tutto più chiaro. :p
P.s.: mi spiegate brevemente cosa e la metaprogarrammazione e la differenza tra linguaggi maamged e non managed?
http://en.wikipedia.org/wiki/Managed_code in particolare http://blogs.msdn.com/brada/archive/2004/01/09/48925.aspx
http://en.wikipedia.org/wiki/Metaprogramming
intanto col C++ va benisismo anche perche tratta molto bene la programmazione ad oggetti e spiega bene cosa e il libro che ho comprato:Prrr: :Prrr:
Per la programmazione a oggetti avresti potuto utilizzare la vecchia, ma utile guida che la Borland allegò al Turbo Pascal 5.5 quasi una ventina d'anni fa. Eccola http://dn.codegear.com/article/images/20803/TP_55_OOP_Guide.pdf in inglese. ;)

[cdimauro]

ma non si possono confrontare java e c++, dai...
java > c++ e basta :O
print 'Elenco linguaggi equipotenti:'
for Language in ProgrammingLanguages:
if TuringComplete(Language):
print ' ', Language
:Prrr:

[PGI-Bis]

Il fatto che due lingue siano turing-complete è irrilevante. Anche brainfuck è turing completo. Esiste semmai il problema della trappola di turing aka turing tarpit.

[71104]

Il fatto che due lingue siano turing-complete è irrilevante. Anche brainfuck è turing completo. purtroppo non ho ancora avuto modo di studiare questa famigerata turing-completezza all'università, ma diamine questo signor turing aveva dei requisiti di completezza piuttosto bassini per i suoi linguaggi di programmazione :mbe:

[71104]

cioè, mi fate un esempio di linguaggio che non è turing-completo?

[71104]

cioè, mi fate un esempio di linguaggio che non è turing-completo? adesso mi sparano il C++ :asd:

[PGI-Bis]

Basta che sia in grado di emulare una macchina di Turing per essere turing completo. Poichè una macchina di turing è un ciclo reversibile di lettura/scrittura di valori contenuti in una lista di lunghezza indeterminata, il novero delle lingue che non siano turing complete mi pare alquanto esiguo. A parte roba tipo html, css eccetera, ma non credo che a queste si applichi la completezza di turing.

[cdimauro]

cioè, mi fate un esempio di linguaggio che non è turing-completo?
SQL

[cdimauro]

Basta che sia in grado di emulare una macchina di Turing per essere turing completo. Poichè una macchina di turing è un ciclo reversibile di lettura/scrittura di valori contenuti in una lista di lunghezza indeterminata, il novero delle lingue che non siano turing complete mi pare alquanto esiguo. A parte roba tipo html, css eccetera, ma non credo che a queste si applichi la completezza di turing.
No, infatti. Non si applica a tutti quei linguaggi che non permettono di avere le seguenti 3 istruzioni necessarie per poter computare qualunque cosa:
- azzeramento di un registro;
- incremento (di uno) di un registro;
- salto se due registri non sono uguali.

Ovviamente queste condizioni minimali per la computabilità possono essere espresse in altre forme (all'università in Teoria e Applicazione delle Macchine Calcolatrici ho studiato il linguaggio S, che se non ricordo male era dotato soltanto di queste 3 istruzioni, o di qualcosa di simile; adesso è passato troppo tempo e non ricordo esattamente i dettagli).

[cdimauro]

Il fatto che due lingue siano turing-complete è irrilevante. Anche brainfuck è turing completo. Esiste semmai il problema della trappola di turing aka turing tarpit.
Questa non me la ricordo, onestamente.

[PGI-Bis]

La trappola di turing dice che un linguaggio supporta un costrutto se per usarlo non è necessario introdurre enunciati ad hoc. E' il caso, ad esempio, della programmazione funzionale in Java. Pur potendo creare degli oggetti-funzione in Java il linguaggio non supporta le funzioni come tipi di dato perchè il loro uso richiede l'introduzione di una nuova definizione, quella di tipo-funzione. E' solo un esempio, ovviamente, la programmazione funzionale è come un gabinetto senza scarico: sembra che serva a qualcosa ma appena lo usi sei nella cacca fino al collo (che poeta :D).

Comunque, è questa trappola di turing a dirci quanto un linguaggio è tecnicamente diverso da un altro. Tutte le lingue turing complete permettono di creare qualsiasi programma ma non tutte nello stesso modo. Alcune supportono certe caratteristiche, altre richiedono che le stesse siano di volta in volta emulate.

[^TiGeRShArK^]

mmmm...
le Read only right moving Turing Machines sono equivalenti agli automi a stati finiti non deterministici...
Ma la macchina di turing di cui sopra è equivalente ad una macchina di turing normale.. o no? :fagiano:
Non mi ricordo + una mazza di informatica teorica :muro:

[PGI-Bis]

Le macchine in sola lettura unidirezionali sono un'altra cosa. Cioè sono sempre macchine di turing, ma non sono usate per valutare la completezza di turing.

[AngeL)]

print 'Elenco linguaggi equipotenti:'
for Language in ProgrammingLanguages:
if TuringComplete(Language):
print ' ', Language
:Prrr:
non capisco quel volgare linguaggio :O

[71104]

non capisco quel volgare linguaggio :O io per un attimo l'avevo preso per inglese :D

caspita, debbo dire che questo Python mi incuriosisce sempre di più :read:

[cdimauro]

La trappola di turing dice che un linguaggio supporta un costrutto se per usarlo non è necessario introdurre enunciati ad hoc. E' il caso, ad esempio, della programmazione funzionale in Java. Pur potendo creare degli oggetti-funzione in Java il linguaggio non supporta le funzioni come tipi di dato perchè il loro uso richiede l'introduzione di una nuova definizione, quella di tipo-funzione.
Grazie per la spiegazione (sempre molto chiara). :)
E' solo un esempio, ovviamente, la programmazione funzionale è come un gabinetto senza scarico: sembra che serva a qualcosa ma appena lo usi sei nella cacca fino al collo (che poeta :D).
La mia esperienza è diametralmente opposta alla tua. :p

L'apprezzo molto, perché spesso mi permette di risolvere problemi in maniera semplice ed elegante, ma come per tutte le cose sono strumenti che vanno usati sapientemente (a volte m'è capitato di esagerare, e rifattorizzando ho preferito qualche altra soluzione).
Comunque, è questa trappola di turing a dirci quanto un linguaggio è tecnicamente diverso da un altro. Tutte le lingue turing complete permettono di creare qualsiasi programma ma non tutte nello stesso modo. Alcune supportono certe caratteristiche, altre richiedono che le stesse siano di volta in volta emulate.
Chiaro. Infatti leggo spesso di linguaggi "più potenti" di altri e mi cadono le braccia perché formalmente tutti i linguaggi sono, appunto, equipotenti.

Discorso diverso è andare vedere i costrutti che mettono a disposizione per risolvere i problemi. ;)

[cdimauro]

io per un attimo l'avevo preso per inglese :D

caspita, debbo dire che questo Python mi incuriosisce sempre di più :read:
Fai bene perché merita. E poi, come hai potuto notare, la sua sintassi è molto semplice e votata alla leggibilità.

Di recente mi sono ristudiato Ruby, ma le impressioni che avevo avuto circa 3 anni fa (quando mi sono girato attorno per vedere quale nuovo linguaggio utilizzare per il lavoro) sono rimaste immutate: in tanti casi è poco chiaro (criptico, tanto che nei vari documenti di riferimento e libri di programmazione che ho letto lo ammettono gli stessi autori) e troppo "PERL-ish" (http://www.sounerd.com.br/index.php?option=com_content&task=view&id=237&Itemid=43) per i miei gusti. :p

In Python l'approccio è decisamente diverso. La filosofia su cui si basa è quella della leggibilità a tutti i costi, tanto che nella versione 3.0 sarà fatta piazza pulita di tutti i costrutti, metodi, ecc. che permettono di fare le stesse cose.

I casi più macroscopici:
- verrà eliminato l'operatore <> perché c'è già !=;
- per i dizionari verrà eliminato il metodo has_key() perché si può usare l'operatore in che è decisamente più leggibile;
- le stringhe saranno tutte unicode mentre quelle attuali diventeranno "raw bytes";

e tante altre cosucce.

A parte questo, è un linguaggio molto più maturo e "completo".

[cisc]

cdimauro, hai incuriosito anche me con il python:p

Per quanto riguarda l'argomento del thread, io credo che per partire vada bene qualsiasi linguaggio, innanzitutto c'è da ricordare che le difficoltà che si trovano nell'apprendere un linguaggio sono soggettive, inoltre, anche partendo da un linguaggio notoriamente complesso, si deve adottare sempre un percorso graduale...in sostanza prima si comincia ad imparare una parte del linguaggio più semplice, e poi si procede ad aumentare la difficoltà.....a prova di quello che sto dicendo, e la grande diversità di percorsi che sono stati portati a testimonianza in questo thread.....in conclusione, dipende da quale obietti ti poni, se vuoi programmare un sistema operativo:eek: , impari il c, programmi programmi programmi..studi studi studi...e dopo molti anni forse avrai raggiunto il tuo obiettivo.....

[k0nt3]

python è un bel linguaggio, ma continuo a non vedercelo per progetti di medie-grosse dimensioni. da il meglio di se per scrivere plugins e script in generale
ha anche lui i suoi difetti oltre ai suoi pregi (es. protezione dei campi/metodi nelle classi abbastanza grezza)

per il fatto della gente che dice questo linguaggio è più potente di questo ecc.. non credo che abbiano in mente _quella_ definizione di potenza.
è più una questione di riuscire a fare cose di basso livello con meno fatica credo (in java a volte bisogna fare i salti mortali)
io adesso mi sto divertendo con il D e la prima impressione che si ha è che è un linguaggio pensato per essere utile in pratica e non solo in teoria.
un piccolo (ma estremamente indicativo) esempio è il foreach:
foreach (argc, argv; args)
{
// Object Oriented Programming
CmdLin cl = new CmdLin(argc, argv);
// Improved typesafe printf
writefln(cl.argnum, cl.suffix, " arg: %s", cl.argv);
// Automatic or explicit memory management
delete cl;
}
un grosso limite degli iteratori in java è che non si può tenere conto dell'indice dell'elemento all'interno della collezione (a meno che non lo si fa a mano) e questa soluzione è manna dal cielo per quanto mi riguarda

[cdimauro]

cdimauro, hai incuriosito anche me con il python:p
Provalo! :)
Per quanto riguarda l'argomento del thread, io credo che per partire vada bene qualsiasi linguaggio, innanzitutto c'è da ricordare che le difficoltà che si trovano nell'apprendere un linguaggio sono soggettive, inoltre, anche partendo da un linguaggio notoriamente complesso, si deve adottare sempre un percorso graduale...in sostanza prima si comincia ad imparare una parte del linguaggio più semplice, e poi si procede ad aumentare la difficoltà.....a prova di quello che sto dicendo, e la grande diversità di percorsi che sono stati portati a testimonianza in questo thread.....in conclusione, dipende da quale obietti ti poni, se vuoi programmare un sistema operativo:eek: , impari il c, programmi programmi programmi..studi studi studi...e dopo molti anni forse avrai raggiunto il tuo obiettivo.....
Non sono molto d'accordo, per quanto ho già scritto prima: col C et similia sei costretto a conoscere dettagli che come programmatore sono del tutto inutili per risolvere i tuoi problemi.

Nessuno dice che il C non va bene per iniziare, ma soltanto le difficoltà saranno maggiori per chi è a digiuno di programmazione.

Poi linguaggi fortemente tipizzati come Python sono particolarmente "safe": pronti subito a bacchettarti le mani se fai la minima cazzata, così è anche più facile rendersi conto dei propri errori.

Insomma, a livello di FACILITA' di apprendimento credo che non ci sia storia. ;)

[cdimauro]

python è un bel linguaggio, ma continuo a non vedercelo per progetti di medie-grosse dimensioni. da il meglio di se per scrivere plugins e script in generale
Non lo vedi perché non ci lavori tutti i giorni, per cui non puoi apprezzarlo per cose diverse da quelle che hai descritto.

Io sono 3 anni a novembre che uso quasi esclusivamente Python per le mie applicazioni, e ne ho realizzato diverse "non banali".
Nella mia azienda diversi server "critici" sono interamente in Python, ad esempio. Considera che ho pure server che s'interfacciano con macchine di TIM, che macinano migliaia di richieste giornalmente e non battono ciglio. ;)
ha anche lui i suoi difetti oltre ai suoi pregi (es. protezione dei campi/metodi nelle classi abbastanza grezza)
E' normale che sia così: il linguaggio perfetto devono ancora inventarlo. :p

Ma almeno è coerente: sai già che TUTTO è "pubblico", e non ti capita di dichiarare "private" una variabile o un metodo, salvo poi che una qualunque classe discendente la renda pubblica, come puoi fare con Ruby (che è particolarmente avvezzo agli "hack"); oppure creare un "cracker" per avere accesso a tutti i metodi, variabili e proprietà "protected", come puoi fare in Delphi (e probabilmente anche in C++, Java, ecc.).
per il fatto della gente che dice questo linguaggio è più potente di questo ecc.. non credo che abbiano in mente _quella_ definizione di potenza.
è più una questione di riuscire a fare cose di basso livello con meno fatica credo (in java a volte bisogna fare i salti mortali)
Se ne fanno molti di più con C++. :D

Ma è giusto quello che dici: posta in questi termini la cosa assume un aspetto diverso.

Personalmente non sono interessato a cose di basso livello, ma a risolvere problemi, quindi il mio approccio è sempre al più alto livello possibile, e per questo mi trovo particolarmente bene con Python.
io adesso mi sto divertendo con il D e la prima impressione che si ha è che è un linguaggio pensato per essere utile in pratica e non solo in teoria.
Questo vale per qualunque linguaggio che non sia nato per gioco o per "sfida", come brainfuck appunto.
un piccolo (ma estremamente indicativo) esempio è il foreach:
foreach (argc, argv; args)
{
// Object Oriented Programming
CmdLin cl = new CmdLin(argc, argv);
// Improved typesafe printf
writefln(cl.argnum, cl.suffix, " arg: %s", cl.argv);
// Automatic or explicit memory management
delete cl;
}
un grosso limite degli iteratori in java è che non si può tenere conto dell'indice dell'elemento all'interno della collezione (a meno che non lo si fa a mano) e questa soluzione è manna dal cielo per quanto mi riguarda
Ma è un caso particolare. Quando devi scorrere gli elementi di una collezione generalmente t'interessa l'elemento, non l'indice che gli è stato assegnato. Anche perché il concetto di "posizione" (numerica, presumo) può valere soltanto per particolari tipi di collezioni (sequenze, liste), ma non per altre (dizionari, insiemi).

Anche in Python gli iteratori tornano l'elemento e non anche l'indice (sempre per il discorso di cui sopra). Se proprio è necessario assegnare anche un indice, lo si risolve facilmente con l'iteratore enumerate():
SottocategoriaTemplate = '''<s%(id)s>
<sottocategoriaName>%(name)s</sottocategoriaName>
<sottocategoriaValue>%(value)s</sottocategoriaValue>
</s%(id)s>
'''
s = ''.join(SottocategoriaTemplate % {'id' : i, 'name' : Name, 'value' : Value} for i, (Name, Value) in enumerate(Params))
In questo caso il valore della variabile "i" è generato dall'iteratore enumerate, mentre l'elemento (Name, Value) è il valore recuperato dalla lista Params, che è un elenco di coppie chiave/valore. ;)

[71104]

cdimauro, che IDE e che compilatore posso usare per programmare in Python, e da dove li posso scaricare?

(domanda fatidica :P)

[71104]

oppure creare un "cracker" per avere accesso a tutti i metodi, variabili e proprietà "protected", come puoi fare in Delphi (e probabilmente anche in C++, Java, ecc.). toglici il "probabilmente" :p

[k0nt3]

ovviamente il foreach è un piccolo dettaglio, ma sono i dettagli che fanno la differenza e il D ne ha molti :)
anche per quel che riguarda il testing e le specifiche ha delle caratteristiche più uniche che rare ;)

[cdimauro]

cdimauro, che IDE e che compilatore posso usare per programmare in Python, e da dove li posso scaricare?

(domanda fatidica :P)
Io uso questo: http://pythonide.blogspot.com/ e mi trovo molto bene.
toglici il "probabilmente" :p
C'avrei giurato, ma non avendone la certezza ho preferito rimanere sul vago. :p

[cdimauro]

ovviamente il foreach è un piccolo dettaglio, ma sono i dettagli che fanno la differenza e il D ne ha molti :)
anche per quel che riguarda il testing e le specifiche ha delle caratteristiche più uniche che rare ;)
Non lo metto in dubbio, ma è produttivo, semplice da usare e leggibile quanto Python (lasciamo perdere la sintassi che può essere una cosa soggettiva)? ;)

[k0nt3]

Non lo metto in dubbio, ma è produttivo, semplice da usare e leggibile quanto Python (lasciamo perdere la sintassi che può essere una cosa soggettiva)? ;)
questo come lo trovi? :cool:
class Date
{
int day;
int hour;

invariant()
{
assert(1 <= day && day <= 31);
assert(0 <= hour && hour < 24);
}
}
sempre tenendo bene a mente che non considero python e D confrontabili per evidenti differenze di target :fagiano:

[cdimauro]

questo come lo trovi? :cool:
class Date
{
int day;
int hour;

invariant()
{
assert(1 <= day && day <= 31);
assert(0 <= hour && hour < 24);
}
}
:mbe: Che c'è di particolare? Gli assert li ha pure il C.
sempre tenendo bene a mente che non considero python e D confrontabili per evidenti differenze di target :fagiano:
Quando c'è da realizzare un'applicazione "generica", è facile che il target di cui parli coincida, per cui il confronto diventa inevitabile. ;)

[k0nt3]

:mbe: Che c'è di particolare? Gli assert li ha pure il C.

il particolare è invariant e non assert infatti (un'altro piccolo dettaglio che risparmia molte righe di codice)

[cdimauro]

il particolare è invariant e non assert infatti (un'altro piccolo dettaglio che risparmia molte righe di codice)
Se invariant ha a che fare con la programmazione "by contract" che offre il D, hai perfettamente ragione. :p

[k0nt3]

Se invariant ha a che fare con la programmazione "by contract" che offre il D, hai perfettamente ragione. :p
esattamente! l'invariante in una classe è qualcosa che dice cosa deve sempre verificarsi in ogni sua istanza affinchè l'oggetto sia consistente, e quando non si verifica viene lanciata un'eccezione.
per fare qualcosa di equivalente bisognerebbe fare un controllo alla fine di ogni metodo che modifica la struttura interna dell'oggetto e lanciare un'eccezione nel caso in cui qualcosa non è consistente
ma non è il solo costrutto di questo tipo presente in D ce n'è anche uno per definire precondizioni e postcondizioni.
tutte queste cose non sono novità assolute, quello che mi stupisce piuttosto è la semplicità con cui sono state integrate nativamente nel linguaggio.

[cdimauro]

Già. Anche per questo lo trovo di gran lunga preferibile al C++.

[cisc]

Be, se si parla di DesignByContract, come non citare eiffel:D a dire il vero lo conosco solo per il suo supporto nativo al DByC......qualcuno che abbia qualche esperienza su questo linguaggio? :stordita:

[k0nt3]

Be, se si parla di DesignByContract, come non citare eiffel:D a dire il vero lo conosco solo per il suo supporto nativo al DByC......qualcuno che abbia qualche esperienza su questo linguaggio? :stordita:
no però ho avuto a che fare con ADA in compenso :cool:

piccolo OT: approposito di Ada.. lei è stata la prima programmatrice nella storia
http://upload.wikimedia.org/wikipedia/commons/2/2e/Ada_Lovelace_1838.jpg
direi che siamo peggiorati un tantino come categoria :stordita:

[71104]

ma che è sta cacata :mbe:

[cdimauro]

Be, se si parla di DesignByContract, come non citare eiffel:D a dire il vero lo conosco solo per il suo supporto nativo al DByC......qualcuno che abbia qualche esperienza su questo linguaggio? :stordita:
Non l'ho mai studiato, anche se mi ha sempre affascinato la sua leggenda.

Quando se ne iniziò a parlare, infatti, circolava la voce che fosse un bellissimo linguaggio, ma che l'allora compilatore Eiffel generasse centinaia di righe di codice C per poche righe di codice nativo (anche per il C++, i primi compilatori della AT&T generavano codice C). :p

[cdimauro]

ma che è sta cacata :mbe:
Non offendere la memoria di Ada, eretico! :read:

[^TiGeRShArK^]

Le macchine in sola lettura unidirezionali sono un'altra cosa. Cioè sono sempre macchine di turing, ma non sono usate per valutare la completezza di turing.

si ma da quel (poco) che ricordo di informatica teorica se non sbaglio ogni classe di problemi poteva essere risolta da una particolare macchina.
La + completa era la macchina di turing non deterministica che era sostanzialmente equivalente alla macchina di turing deterministica ma inifinitamente + veloce.
Quindi c'erano gli automi a stati finiti non deterministici e quelli deterministici.
Se non sbaglio gli automi a stati finiti deterministici potevano risolvere problemi + limitati, come ad esempio il persing di linguaggi regolari.
Ma dato che su wikipedia avevo visto che una macchina di turing di quel tipo era equivalente ad un automa a stati finiti non deterministici mi era venuto un attimo il dubbio sull'effettiva "potenza" degli automi a stati finiti deterministici e non che a quanto ricordo no ndovrebbero essere equivalenti alla macchina di turing....
o sbaglio? :fagiano:

[marco.r]

cdimauro, che IDE e che compilatore posso usare per programmare in Python, e da dove li posso scaricare?

(domanda fatidica :P)

Consiglio anche io SPE, mi sembra il piu' completo disponibile gratuitamente. C'è volendo anche un plug-in per Eclipse, se sei disposto a sopportarne la pesantezza :D.
Se sei sotto windows ti consiglio di usare ActivePython, che trovi sul sito di activestate. E' in pratica python con in piu' l'interfaccia per le api di windows. Il modo più indolore per creare ed eseguire servizi sotto windows :D.
Sempre di ActiveState c'è un bell'ide per linguaggi dinamici (Komodo) peccato che costi. Il solo editor e' gratuito e il suo lavoro lo fa molto bene (in particolare il completamento automatico, che con linguaggi dinamici è molto più difficile da implementare)

[marco.r]

Ma almeno è coerente: sai già che TUTTO è "pubblico", e non ti capita di dichiarare "private" una variabile o un metodo, salvo poi che una qualunque classe discendente la renda pubblica, come puoi fare con Ruby (che è particolarmente avvezzo agli "hack"); oppure creare un "cracker" per avere accesso a tutti i metodi, variabili e proprietà "protected", come puoi fare in Delphi (e probabilmente anche in C++, Java, ecc.).

A difesa degli altri linguaggi :D, direi che "private" e "protected" sono progettati per difendere dall'errore umano e non dalla malizia.

[cisc]

si ma da quel (poco) che ricordo di informatica teorica se non sbaglio ogni classe di problemi poteva essere risolta da una particolare macchina.
La + completa era la macchina di turing non deterministica che era sostanzialmente equivalente alla macchina di turing deterministica ma inifinitamente + veloce.
Quindi c'erano gli automi a stati finiti non deterministici e quelli deterministici.
Se non sbaglio gli automi a stati finiti deterministici potevano risolvere problemi + limitati, come ad esempio il persing di linguaggi regolari.
Ma dato che su wikipedia avevo visto che una macchina di turing di quel tipo era equivalente ad un automa a stati finiti non deterministici mi era venuto un attimo il dubbio sull'effettiva "potenza" degli automi a stati finiti deterministici e non che a quanto ricordo no ndovrebbero essere equivalenti alla macchina di turing....
o sbaglio? :fagiano:
Beh, se non puoi tornare indietro sul nastro, e non puoi scrivere, puoi solo leggere i caratteri di input una sola volta in modo sequenziale e in base alla relazione di transizione cambiare stato....un automa non deterministico :fagiano:

l'inghippo sta che aggiungere tali limitazioni non lascia invariata la "potenza" della macchina, per tutte le varianti di macchine di turing che ho studiato, si è partiti dalla definizione, e si è dimostrato che per ogni macchina "standard" che accetta un particolare linguaggio, è possibile crearne un'altra con la caratteristica x in più o in meno, che riesce a fare altrettante...

[marco.r]

Di recente mi sono ristudiato Ruby, ma le impressioni che avevo avuto circa 3 anni fa (quando mi sono girato attorno per vedere quale nuovo linguaggio utilizzare per il lavoro) sono rimaste immutate: in tanti casi è poco chiaro (criptico, tanto che nei vari documenti di riferimento e libri di programmazione che ho letto lo ammettono gli stessi autori) e troppo "PERL-ish" (http://www.sounerd.com.br/index.php?option=com_content&task=view&id=237&Itemid=43) per i miei gusti. :p

La sintassi di Ruby è decisamente più barocca di quella di Python. Ha il pregio che è un po' più dinamico rispetto a quest'ultimo per cui in alcuni casi si riesce ottenere un risultato analogo o anche più bello. Perlomeno python ha dovuto nel tempo introdurre una serie di funzionalità (come ad esempio i decoratori ) che in Ruby si riescono a implementare col linguaggio stesso


A parte questo, è un linguaggio molto più maturo e "completo".
Indubbiamente.

[cdimauro]

A difesa degli altri linguaggi :D, direi che "private" e "protected" sono progettati per difendere dall'errore umano e non dalla malizia.
E' quel che ho sempre pensato da quando ho iniziato a lavorare con la programmazione a oggetti con Turbo Pascal, ma dopo anni di esperienza (specialmente con Delphi) mi sono ricreduto.

Il problema, fondamentalmente, è che queste (presunte, visto che in alcuni casi si possono facilmente aggirare) protezioni potrebbero andare bene per chi vuole iniziare a formarsi una mentalità da "architetto / designer" di software, ma col tempo è facile che diventino delle forte limitazioni.

M'è capitato non poche volte di avere bisogno di poter "personalizzare" alcune funzionalità di una classe (sia chiaro: senza stravolgerne lo scopo!), e quando ho potuto sono dovuto ricorrere ai cracker (che, di fatto, rendono del tutto inutile il concetto di "protected"), ma nel caso in cui alcune variabili e/o metodi e/o proprietà erano "private" non c'è stato assolutamente nulla da fare.

Qui il problema è chiaramente di design: l'architetto che ha realizzato quella classe avrà pensato bene (!) che per certe funzionalità non ci fosse bisogno di "personalizzazioni", e mi ha chiuso tutte le porte, senza vie d'uscita.

L'unica speranza è che l'architetto sia lungimirante, e che magari abbia implementato un sistema di hook / plugin per fornire la possibilità di personalizzazione della classe in maniera controllata. Ma questo richiede tanto codice in più, proporzionalmente alle funzionalità che si vogliono manipolare in maniera controllata, e non sempre è desiderabile (specialmente per chi queste classi le deve scrivere :p).

Ma sono, appunto, speranze.

Tanto vale, allora, rendere tutto pubblico e dare la completa disponibilità al programmatore di usare le classi come più gli aggrada (eventualmente sarebbe interessante un sistema di warning nei casi in cui alcuni elementi fossero marcati come "privati").
La sintassi di Ruby è decisamente più barocca di quella di Python.
Senza ombra di dubbio. In alcune cose è più semplice ed è innegabile (penso alla dichiarazione dei metodi di una classe, ad esempio, dove non è necessario specificare la parola "self"), ma in generale sono scelte che si pagano con una minor flessibilità e/o chiarezza in altre parti (la dichiarazione di variabili d'istanza, di classe, ecc., sempre per fare qualche esempio; in particolare noto un'incoerenza linguistica per quanto riguarda la dichiarazione di metodi e variabili di classe: per questi ultimi si utilizza il prefisso @@, mentre per i primi si deve specificare il nome della classe seguito dal punto :rolleyes: ), oppure con una duplicazione di funzionalità che non aiuta certamente a una maggior semplicità del linguaggio.

Troppo, troppo, decisamente troppo PERL-ish per i miei gusti. :cry:
Ha il pregio che è un po' più dinamico rispetto a quest'ultimo per cui in alcuni casi si riesce ottenere un risultato analogo o anche più bello.
Onestamente, anche confrontandoli, non mi sembra che Python sia "meno dinamico" di Ruby, eccetto che per alcune cose (esempio: valutazione delle espressioni nelle stringhe double-quoted, come per PHP, PERL, ecc., oppure per la presenza degli operatori % per realizzare degli "shortcut" di altre funzionalità), di cui non sento assolutamente la mancanza (e considerata la mentalità di Guido & co. spero di non vedere mai introdotte nel linguaggio :p).
Perlomeno python ha dovuto nel tempo introdurre una serie di funzionalità (come ad esempio i decoratori ) che in Ruby si riescono a implementare col linguaggio stesso
Mumble mumble. Se ti riferisci all'aliasing dei metodi, in modo da rimpiazzare quelli già esistenti con altri per fargli fare altre cose, questo lo si poteva fare già con Python all'incirca allo stesso modo.

I decoratori hanno aggiunto la "composizione" di funzioni e metodi (nell'accezione classica della matematica) ma in maniera molto più semplice, elegante e... leggibile. "Pythonic", insomma. :p

Questo sempre se ho capito a cosa ti riferivi, eh! ;)

[xabraita12]

up

:D :D non finira mai questo post voglio vedere se ci sono altri votanti

[cdimauro]

Non capisco il perché, visto che comunque hai fatto di testa tua senza seguire i consigli che ti sono stati dati e neppure i risultati di questo sondaggio. :stordita:

[Matrixbob]

La rivincita di C (http://www.pctuner.net/news/13472/La-rivincita-di-C/)

http://www.pctuner.net/info_up/results/_201004/20100407172448_tiobe.jpeg

[Vincenzo1968]

La rivincita di C (http://www.pctuner.net/news/13472/La-rivincita-di-C/)

http://www.pctuner.net/info_up/results/_201004/20100407172448_tiobe.jpeg


Il buon vecchio C è tornato alla posizione numero uno nella top 20 dei linguaggi di programmazione più utilizzati al mondo, scavalcando il rivale Java, che ne aveva occupato il posto per diversi anni.

La classifica tiene conto del TIOBE Programming Community Index e viene stilata mensilmente, fornendo un’indicazione sulla popolarità dei vari linguaggi di programmazione.

La discesa di Java in seconda posizione è dovuta al fatto che il linguaggio ha perso punti a causa di linguaggi di programmazione simili, come JavaFX, che si sta sempre più affermando e sta per entrare nella top 20.

Che dire di tutto ciò? Onore a C, che dopo anni di servizio resta uno dei linguaggi più validi e multipiattaforma di sempre.


:yeah: :winner: :yeah:

[DanieleC88]

:yeah: :winner: :yeah:

:eekk:
Ma allora sei vivo! :D

[Tommo]

Godo perchè Java mi fa antipatia gratis :asd:

Inoltre, epic thread necromancy is epic!

[gugoXX]

Continuo a sollevare grossi dubbi sul significato della statistica di Tiobe.

[Vincenzo1968]

:eekk:
Ma allora sei vivo! :D

:D

[Kralizek]

Godo perchè Java mi fa antipatia gratis :asd:

Inoltre, epic thread necromancy is epic!

http://www.novarata.net/Thread_Necromancy.jpg

questa immagine non stanca mai!