Roma – La Software and Information Industry Association ( SIIA ) ha conferito il premio “Peter Jackson per l’Innovazione” a Brewster Kahle, creatore di Internet Archive .
Peter Jackson è stato chief scientist di Thomson Reuters e consigliere della SIIA . Nella sua carriera ha svolto diverse ricerche sull’intelligenza artificiale.
Il premio in suo onore è destinato alle “persone che hanno avuto un profondo impatto sulla tecnologia e l’informazione e ispirato l’intera industria di contenuti digitali”. ( C.T. )
leggi i 18 commenti
-
Le solite idee inutili!
Esiste gia un linguaggio per tale scopo e non e' java! si chiama "D"!!! informatevi! supporta: codice nativo, scope(exit) (oltre che eccezzioni) che semplifica la gestione degli errori, contract programming, unit test integrati, compile time execution, costrutti per la programmazzione parallela...-
Re: Le solite idee inutili!
Quello della Digital Mars? Me lo ricordo!Il compilatore è closed, ma il front-end è open, ed è stato implementato anche sul GCC (così ne esiste anche una versione open)Peccato che sia poco diffuso (e quindi poco supportato), perchè è promettente.
-
-
Riassumendo:
un linguaggio multipiattaforma che semplifica la gestione dell'allocazione della memoria, che controlla i puntatori, votato al parallelismo... praticamente Java con librerie per il parallelismo... a che pro tutto questo sforzo per creare l'ennesimo nuovo linguaggio (con tutto l'ecosistema di sviluppo) che non apporta NULLA che già non esista di stra-collaudato??????????????-
Re: Riassumendo:
- Scritto da: Axel
un linguaggio multipiattaforma che semplifica la
gestione dell'allocazione della memoria, che
controlla i puntatori, votato al parallelismo...
praticamente Java con librerie per il
parallelismo... a che pro tutto questo sforzo per
creare l'ennesimo nuovo linguaggio (con tutto
l'ecosistema di sviluppo) che non apporta NULLA
che già non esista di
stra-collaudato??????????????beh nuovi paradigmi programmatori, agile coding, nuovi modelli di business, web-on-the-road... insomma, bisogna reinventare la ruota ogni 10-15 anni.-
Re: Riassumendo:
- Scritto da: attonito
- Scritto da: Axel
un linguaggio multipiattaforma che semplifica la
...
praticamente Java con librerie per il
parallelismo... a che pro tutto questo sforzo per
creare l'ennesimo nuovo linguaggio (con tutto
l'ecosistema di sviluppo) che non apporta NULLA
che già non esista di
stra-collaudato??????????????
beh nuovi paradigmi programmatori, agile coding,
nuovi modelli di business, web-on-the-road...
insomma, bisogna reinventare la ruota ogni 10-15
anni.Forse che Rust compila in binario e non in bytecode, genera codice compatibile con il c/c++?Come dire: il meglio di C7C++/Java tutto assieme!-
Re: Riassumendo:
- Scritto da: UbuPinguino
genera codice compatibile con il
c/c++?Scusa ma cosa significa che genera codice compatibile con il c++?-
Re: Riassumendo:
- Scritto da: Nome e cognome
Scusa ma cosa significa che genera codice
compatibile con il
c++?Linkabile -
Re: Riassumendo:
Basta paragonare il consumo di RAM tra JAVA e applicazioni native per mettere il JAVA nel bidone.Applicazione in JAVA che mostra un form vuoto: 56MB di RAMApplicazione in C++ che mostra un form vuoto: 12KB di RAM -
Re: Riassumendo:
- Scritto da: Nome e cognome
Basta paragonare il consumo di RAM tra JAVA e
applicazioni native per mettere il JAVA nel
bidone.
Applicazione in JAVA che mostra un form vuoto:
56MB di
RAM
Applicazione in C++ che mostra un form vuoto:
12KB di
RAMApplicazione in assembly che visualizza una form vuota -
ancora meno Kb di RAM.Quindi, seguendo il tuo discorso logico, dovremmo buttare anche C++ nel bidone.Ti sei mai chiesto perché questo non avviene? -
Re: Riassumendo:
- Scritto da: Paul
- Scritto da: Nome e cognome
Basta paragonare il consumo di RAM tra JAVA e
applicazioni native per mettere il JAVA nel
bidone.
Applicazione in JAVA che mostra un form
vuoto:
56MB di
RAM
Applicazione in C++ che mostra un form vuoto:
12KB di
RAM
Applicazione in assembly che visualizza una form
vuota -
ancora meno Kb di
RAM.
Quindi, seguendo il tuo discorso logico, dovremmo
buttare anche C++ nel
bidone.
Ti sei mai chiesto perché questo non avviene?Forse Intel non venderebbe più e i "point and click programmerZ" resterebbero disoccupati? :D -
Re: Riassumendo:
- Scritto da: brain
- Scritto da: Paul
- Scritto da: Nome e cognome
Basta paragonare il consumo di RAM tra
JAVA
e
applicazioni native per mettere il JAVA nel
bidone.
Applicazione in JAVA che mostra un form
vuoto:
56MB di
RAM
Applicazione in C++ che mostra un form
vuoto:
12KB di
RAM
Applicazione in assembly che visualizza una form
vuota -
ancora meno Kb di
RAM.
Quindi, seguendo il tuo discorso logico,
dovremmo
buttare anche C++ nel
bidone.
Ti sei mai chiesto perché questo non avviene?
Forse Intel non venderebbe più e i "point and
click programmerZ" resterebbero disoccupati?
:DSì perché i programmatori C++ sono tutti "point and click programmerZ", tu sei l'unico genio al mondo che riesce a scrivere tutto il software direttamente di assembly. (rotfl)(rotfl)(rotfl)(rotfl)(rotfl) -
Re: Riassumendo:
- Scritto da: e contribuis ca
- Scritto da: brain
- Scritto da: Paul
- Scritto da: Nome e cognome
Basta paragonare il consumo di RAM tra
JAVA
e
applicazioni native per mettere il JAVA
nel
bidone.
Applicazione in JAVA che mostra un form
vuoto:
56MB di
RAM
Applicazione in C++ che mostra un form
vuoto:
12KB di
RAM
Applicazione in assembly che visualizza una
form
vuota -
ancora meno Kb di
RAM.
Quindi, seguendo il tuo discorso logico,
dovremmo
buttare anche C++ nel
bidone.
Ti sei mai chiesto perché questo non avviene?
Forse Intel non venderebbe più e i "point and
click programmerZ" resterebbero disoccupati?
:D
Sì perché i programmatori C++ sono tutti "point
and click programmerZ", tu sei l'unico genio al
mondo che riesce a scrivere tutto il software
direttamente di assembly.
(rotfl)(rotfl)(rotfl)(rotfl)(rotfl)genio leggi dall'inizio: giava :D -
Re: Riassumendo:
Tra un programma in C e un in C++ c'è differenza, effettivamente se scritto in C occupa ancora meno memoria.Tra C e assembly la differenza non c'è affatto.Anzi (ma questo cambia a seconda del programmatore....) con le ottimizzazioni automatiche del compilatore, è probabile che a scrivere in C si ottenga un risultato migliore che a scrivere lo stesso programma direttamente in asm.Lo stesso concetto non si applica se confronti il JAVA col C e nemmeno col C++ -
Re: Riassumendo:
- Scritto da: Nome e cognome
Tra un programma in C e un in C++ c'è differenza,
effettivamente se scritto in C occupa ancora meno
memoria.
Tra C e assembly la differenza non c'è affatto.
Anzi (ma questo cambia a seconda del
programmatore....) con le ottimizzazioni
automatiche del compilatore, è probabile che a
scrivere in C si ottenga un risultato migliore
che a scrivere lo stesso programma direttamente
in
asm.
Lo stesso concetto non si applica se confronti il
JAVA col C e nemmeno col
C++E' probabile, ma non è detto. Infatti moltissimi applicativi fino a poco tempo fa contenevano blocchi in assembly per ottimizzare al meglio certe procedure. Il motore grafico di Quake 3 è un esempio.Il punto comunque era che confrontare due linguaggi di programmazione paragonando esclusivamente l'utilizzo della memoria, e dire X è meglio di Y perché consuma meno RAM, è una delle cose più stupide che si possa fare. -
Re: Riassumendo:
- Scritto da: Paul
- Scritto da: Nome e cognome
Basta paragonare il consumo di RAM tra
JAVA e applicazioni native per mettere
il JAVA nel bidone.
Applicazione in JAVA che mostra un form
vuoto: 56MB di RAM
Applicazione in C++ che mostra un form vuoto:
12KB di RAM
Applicazione in assembly che visualizza una form
vuota -
ancora meno Kb di RAM.
Quindi, seguendo il tuo discorso logico, dovremmo
buttare anche C++ nel bidone.No, prima dovremmo vedere quanti k e' la differenza.
Ti sei mai chiesto perché questo non avviene?Perche' nessuno si mette a scrivere il programma in asm, e chi lo fa si accorge che e' uguale o cambia di 1k quindi nasconde tutto... -
Re: Riassumendo:
- Scritto da: krane
- Scritto da: Paul
- Scritto da: Nome e cognome
Basta paragonare il consumo di RAM tra
JAVA e applicazioni native per mettere
il JAVA nel bidone.
Applicazione in JAVA che mostra un form
vuoto: 56MB di RAM
Applicazione in C++ che mostra un form
vuoto:
12KB di RAM
Applicazione in assembly che visualizza una
form
vuota -
ancora meno Kb di RAM.
Quindi, seguendo il tuo discorso logico,
dovremmo
buttare anche C++ nel bidone.
No, prima dovremmo vedere quanti k e' la
differenza.
Ti sei mai chiesto perché questo non avviene?
Perche' nessuno si mette a scrivere il programma
in asm, e chi lo fa si accorge che e' uguale o
cambia di 1k quindi nasconde
tutto...Prova a scrivere un demo da 256 BYTE in C ;) -
Re: Riassumendo:
- Scritto da: krane
No, prima dovremmo vedere quanti k e' la
differenza.Seguendo il suo discorso si evince che un linguaggio di programmazzione automaticamente diventa migliore di un altro se produce applicativi che consumano meno RAM.Anche una scimmia capirebbe che più ci sia astrae dall'hardware e più si realizzano linguaggi di programmazione meno efficienti.Ma ovviamente ci sono tantissimi vantaggi nell'usare un linguaggio di alto livello.La sua è la solita affermazione da Punto Disinformatico, e seguendo questo ragionamento allora dovremmo buttare via ogni linguaggio di programmazione e tornare a scrivere codice macchina.
Perche' nessuno si mette a scrivere il programma
in asm, e chi lo fa si accorge che e' uguale o
cambia di 1k quindi nasconde1 KB di RAM non fa la differenza, ma anche 50 MB non fanno la differenza su una macchina che ne 4 GB installati.Tutto dipende dal contesto, dai requisiti, dai costi di sviluppo e da quelli di mantenimento. -
Re: Riassumendo:
- Scritto da: Paul
- Scritto da: krane
No, prima dovremmo vedere quanti k e' la
differenza.
Seguendo il suo discorso si evince che un
linguaggio di programmazzione automaticamente
diventa migliore di un altro se produce
applicativi che consumano meno
RAM.
Anche una scimmia capirebbe che più ci sia astrae
dall'hardware e più si realizzano linguaggi di
programmazione meno
efficienti.
Ma ovviamente ci sono tantissimi vantaggi
nell'usare un linguaggio di alto
livello.
La sua è la solita affermazione da Punto
Disinformatico, e seguendo questo ragionamento
allora dovremmo buttare via ogni linguaggio di
programmazione e tornare a scrivere codice
macchina.
Perche' nessuno si mette a scrivere il
programma
in asm, e chi lo fa si accorge che e' uguale
o
cambia di 1k quindi nasconde
1 KB di RAM non fa la differenza, ma anche 50 MB
non fanno la differenza su una macchina che ne 4
GB installati.
Tutto dipende dal contesto, dai requisiti, dai
costi di sviluppo e da quelli di mantenimento.E considererei anche il fatto che se io avessi scritto la stessa frase 15 o 20 anni fa dopo due secondi mi sarebbe arrivato qualcuno con il listato in asm scritto al volo e testato a dirmi quanti k fanno.Mentre ora evidentemente si esce a comprare un altro banco di ram per poter dire: non c'e' problema :D
-
-
-
-
