View Full Version : se doveste scegliere ora..
albortola
08-05-2007, 13:12
..che linguaggio cerchereste di imparare??
so che è una domanda un po' troppo vaga, però vorrei sapere quali sono i linguaggi più in voga.
Nella categoria polimorfi Java.
Per gli amorfi Smalltalk.
..che linguaggio cerchereste di imparare??
so che è una domanda un po' troppo vaga, però vorrei sapere quali sono i linguaggi più in voga.
c/c++
SlimSh@dy
08-05-2007, 13:48
Java...
black_sand
08-05-2007, 14:20
python
ps: dipende da quello che ti aspetti di farci....
Ogni volta è una rassegna di tutti i linguaggi esistenti :D. Avanti signori e signore, chi dice Lisp? Qualcuno con Ruby? Nessuno? Fortress al signore là in fondo... :D
NotteSenzaStelle
08-05-2007, 14:31
Ti consiglio c# perchè con un linguaggio puoi fare Windows / Web Application e XML Web services.
Altrimenti java
Ogni volta è una rassegna di tutti i linguaggi esistenti :D. Avanti signori e signore, chi dice Lisp? Qualcuno con Ruby? Nessuno? Fortress al signore là in fondo... :D
Ci penso io :)
Io dico Haskell e/o Erlang.
Mi butti giù l'asse di coppe e bastoni così, come niente fosse.
Rilancio con Chapel e X10, che insieme al già citato Fortress completano la triade.
Ziosilvio
08-05-2007, 17:39
Volendo rimanere nel mainstream: Java.
Volendo fare le cose nel modo più semplice e chiaro possibile: Python.
Volendo fare programmazione funzionale: Haskell.
Più, ovviamente, C e C++ per le parti che devono "correre" davvero.
Volutomitra
08-05-2007, 19:31
Ci penso io :)
Io dico Haskell e/o Erlang.
Beccati questi allora: basic e assembler z80
fdfdfdddd
08-05-2007, 20:20
Objective C così potrai scrivere fantastiche applicazioni con Cocoa :D
Sull'altra sponda ... sicuramente C# e .Net
Purtroppo Java perché ormai sembra un requisito minimo del sistema programmatore, ovviamente ben farcito dai classici C/C++ che per la programmazione di base poco differiscono dal Java.
C'è anche C# con la piattaforma .NET che è di particolarmente interesse. ;)
BrainFuck è valido?
Io direi di no. :ciapet:
Io direi di no. :ciapet:
Qualcuno ha scritto pure Java, per cui direi di si'. :p
In ogni caso penso sia indicativo sia stato proposto Brainfuck prima di VisualBasic... :stordita: :D
La domanda iniziale e' comunque mal posta. Presumo si volesse chiedere "con che linguaggio iniziare oggi", mentre tecnicamente si sta chiedendo a dei programmatori "cosa impararesti oggi" (non un linguaggio diffuso, che probabilmente conoscono gia' e non hanno bisogno di imparare) i quali si stanno pero' orientando con risposte del tipo "qual e' il linguaggio piu' strano che conosci" :mbe:
Qualcuno ha scritto pure Java, per cui direi di si'. :p
In ogni caso penso sia indicativo sia stato proposto Brainfuck prima di VisualBasic... :stordita: :D
La domanda iniziale e' comunque mal posta. Presumo si volesse chiedere "con che linguaggio iniziare oggi", mentre tecnicamente si sta chiedendo a dei programmatori "cosa impararesti oggi" (non un linguaggio diffuso, che probabilmente conoscono gia' e non hanno bisogno di imparare) i quali si stanno pero' orientando con risposte del tipo "qual e' il linguaggio piu' strano che conosci" :mbe:
Giusto! Per questo ho indicato Erlang o Haskell, dato che la strada è sicuramente quella della programmazione parallela spinta dai sempre più presenti processori a più core. Investire energie oggi per imparare un approccio nuovo alla programmazione IMHO pagherà nel prossimo futuro.
se dovessi dira na cosa seria direi ADA95...col senno di poi naturalmente...
se invece dovessi proprio dire na stronzata...magari algol60....o magari imparerei direttamente l'architettura di tutti i processori esistenti e scriverei programmi direttamente in stringhe di 0 e 1
eccomi:sofico:
BABBAGE il linuaggio del futuro (http://www.tlc-systems.com/babbage.htm)
PL/1 (http://www.engin.umd.umich.edu/CIS/course.des/cis400/pl1/pl1.html)
LOGO (http://el.media.mit.edu/Logo-foundation/logo/programming.html)
ADA (http://www.ada-deutschland.de/AE2000/prog/index4.html) direi ADA95..
a parte gli scherzi se sei un niubbo come me
phyton poi un linguaggio tipo java o c++/c#
ps anche questo :sofico: moo moO mOO bellissimi i listati cosi
COW (http://www.bigzaphod.org/cow/)
Giusto! Per questo ho indicato Erlang o Haskell, dato che la strada è sicuramente quella della programmazione parallela spinta dai sempre più presenti processori a più core. Investire energie oggi per imparare un approccio nuovo alla programmazione IMHO pagherà nel prossimo futuro.
Non discutevo questo (secondo me, quando sara' pronto, Data Parallel Haskell sara' qualcosa di fenomenale per lavorare con parecchi core), quanto il fatto che il linguaggio da imparare per il principiante non e' necessariamente lo stesso del programmatore piu' esperto.
Giusto! Per questo ho indicato Erlang o Haskell, dato che la strada è sicuramente quella della programmazione parallela spinta dai sempre più presenti processori a più core. Investire energie oggi per imparare un approccio nuovo alla programmazione IMHO pagherà nel prossimo futuro.
Il mio orologio fa il 2007. Se vi interessa il futuro e la "programmazione parallela spinta", Fortress o Chapel o X10.
Sono i linguaggio sviluppati da Sun Microsystem (Fortress) Cray (Chapel) e IBM (X10) per il programma HPCS (sistemi computerizzati ad altra produttività) della DARPA.
Ovviamente sono tutti e tre orientati agli oggetti. Fortress è il più strambo, X10 è praticamente Java e Chapel è forse il più interessante.
Sun è stata eliminata dalla gara e ha rilasciato Fortress (http://fortress.sunsource.net/) che è ancora in sviluppo.
Per Chapel e X10 ci sono solo le specifiche.
http://chapel.cs.washington.edu/
http://domino.research.ibm.com/comm/research_projects.nsf/pages/x10.index.html
scusate l ot
generate fibonacci sequence
MoO
moO
MoO
mOo
[[ main loop ]]
MOO
[[ print first number ]]
OOM
[[ temp copy of first number ]]
MMM
moO
moO
MMM
mOo
mOo
[[ store second number off in the first position now ]]
moO
MMM
mOo
MMM
[[ move back to temp number ]]
moO
moO
[[ use temp to add to first and store in second in loop ]]
MOO
MOo
mOo
MoO
moO
moo
mOo
mOo
moo
ma non lo conoscevo penso che sia bellissimo:eek: :sofico:
Io direi di no. :ciapet: ma perché sempre tutti a sottovalutare il BrainFuck :O
ma lo capite o no che può rivelarsi un ottimo sistema di security-by-obscurity? :read:
più obscurity di così... :asd:
pensate ad un programma che vuole il seriale, ed il seriale è generato/verificato da un algoritmo molto lungo scritto in BrainFuck ed interpretato just-in-time dal programma stesso (tanto a realizzare un interprete BrainFuck non ci vuole niente...): pensato che esisterebbero ancora i Keygen? :Prrr:
faccio una domanda ot anche se seria
a pgi-bis o chi ne sa qualcosa
quali tra i programmi definiti "esoterici" vale la pena di essere imparato/conosciuto
dasdsasderterowaa
09-05-2007, 15:15
..che linguaggio cerchereste di imparare??
so che è una domanda un po' troppo vaga, però vorrei sapere quali sono i linguaggi più in voga.
io ho iniziato da poco a studiare C#.
E' un linguaggio interessante, sviluppato per il framework .NET, abbastanza richiesto dal mercato del lavoro, ha una sintassi molto simile al C/C++ ma ha qualche complicazione in meno rispetto a quest'ultimo. Diciamo che è un misto tra Java e C++.
Grazie a Mono, un'applicazione scritta in C# può funzionare sia su Windows sia su Linux (le applicazioni girano in una macchina virtuale, il CLR, più o meno come Java).
I programmi scritti in C# hanno una buona velocità di esecuzione grazie alla compilazione Jit (Just In Time) del CLR (il runtime per le applicazioni scritte utilizzando il framework .NET).
Da un punto di vista culturale varrebbe la pena di studiarli tutti.
Lisp pare che sia la fine del mondo. Personalmente quando lo vedo mi vengono i calcoli renali (però sono calcoli lambda!) ma ha un suo fascino.
Tieni sempre presente che col linguaggio non ci fai molto. Il grosso arriva con le librerie e lì son dolori.
Tu prendi un linguaggio meraviglioso come Smalltalk che ha tre regole in croce e forse due parole chiave, dice "oh ma va che meraviglia" e poi scopri che le librerie non hanno documentazione. Niente. Zero. "C'è il codice", ti dicono.
label: aString font: aFontOrNil
"Set the receiver's label and font as indicated"
| oldLabel m aFont |
(oldLabel _ self findA: StringMorph)
ifNotNil: [oldLabel delete].
aFont _ aFontOrNil ifNil: [TextStyle defaultFont].
m _ StringMorph contents: aString font: aFont.
self extent: (m width + 6) @ (m height + 6).
m position: self center - (m extent // 2).
self addMorph: m.
m lock
Ah be', se c'è il codice... graaazie!
Ma non è un caso isolato. Molta della difficoltà nel gestire C++ sta nel fatto che a fronte di una lingua che non è niente di che ti trovi poi ad usare librerie scritte con la tastiera a due pulsanti (uno per natica).
Io dico: occhio. Un conto è sapere il linguaggio e un conto è poterci fare qualcosa. La prima non implica la seconda.
lisp lo conoscevo (passato) a livello autocad e devo dire che era abbastanza :muro:
ma probabilmente è un implementazione diversa dal linguaggio vero e proprio
io intendevo proprio linguaggi esoterici (mi rendo conto di poca utilita)
tipo brainfuck
cow
ecc ecc
franksisca
09-05-2007, 22:52
Assembly:D :D :D :D :D :D :D
Il mio orologio fa il 2007. Se vi interessa il futuro e la "programmazione parallela spinta", Fortress o Chapel o X10.
Sono i linguaggio sviluppati da Sun Microsystem (Fortress) Cray (Chapel) e IBM (X10) per il programma HPCS (sistemi computerizzati ad altra produttività) della DARPA.
Ovviamente sono tutti e tre orientati agli oggetti. Fortress è il più strambo, X10 è praticamente Java e Chapel è forse il più interessante.
Sun è stata eliminata dalla gara e ha rilasciato Fortress (http://fortress.sunsource.net/) che è ancora in sviluppo.
Per Chapel e X10 ci sono solo le specifiche.
http://chapel.cs.washington.edu/
http://domino.research.ibm.com/comm/research_projects.nsf/pages/x10.index.html
Mi sembrano linguaggi abbastanza di nicchia, con un certo bias verso le applicazioni scientifiche. :mbe:
Tra l'altro diverse delle tecniche descritte nei papers di quei tre linguaggi sono utilizzabili anche in haskell (STM ad esempio) , e oggi, non domani. Data Parallel Haskell non e' che una "semplice" estensione (dal punto di vista della sintassi) per poter sfruttare il parallelismo in modo piu' efficiente; il seguente codice
sort :: [:Float:] -> [:Float:]
sort a = if (length a <= 1) then a
else sa!0 +++ eq +++ sa!1
where
m = a!0
lt = [: f | f<-a, f<m :]
eq = [: f | f<a, f==m :]
gr = [: f | f<-a, f>m :]
sa = [: sort a | a <- [:lt,gr:] :]
mi sembra una rappresentazione decisamente elegante e concisa di un quicksort parallelo ( [: f | f<-a, f<m :] e' l'array degli elementi di a che hanno valore <m ). Tra l'altro trattandosi di un linguaggio funzionale e privo di side effects, la maggior parte dei problemi di locking spariscono (in quanto i dati no vengono quasi mai modificati in loco)
Se la cosa incuriosisce ci sono un paio di documenti che spiegano un po' meglio come funziona:
http://research.microsoft.com/~simonpj/papers/ndp/ndp.pdf
http://research.microsoft.com/~simonpj/papers/ndp/NdpSlides.pdf
Lisp pare che sia la fine del mondo. Personalmente quando lo vedo mi vengono i calcoli renali (però sono calcoli lambda!) ma ha un suo fascino.
Tieni sempre presente che col linguaggio non ci fai molto. Il grosso arriva con le librerie e lì son dolori.
Direi che e' una somma di due cose, la disponibilita' di librerie, e l'abilita' del linguaggio nel non fartene sentire la mancanza.
Il Lisp in ogni caso andrebbe studiato non tanto per mettersi a macinare programmi, quanto per capire e imparare alcuni suoi aspetti particolari che risultano interessanti e magari finche' uno non li vede all'opera. Penso in particolare alle macro (quelle di Scheme sono ancora piu' carine in realta') e al multi-dispatching.
Ma non è un caso isolato. Molta della difficoltà nel gestire C++ sta nel fatto che a fronte di una lingua che non è niente di che ti trovi poi ad usare librerie scritte con la tastiera a due pulsanti (uno per natica).
Direi che la quantita' delle suddette libreria sia proprio un'indice del fatto che il C++ e' un linguaggio ostico. Anzi secondo me e' proprio infido.
yorkeiser
10-05-2007, 10:30
Versante lavorativo Java, è il più versatile.
Versante formazione partirei dal c per andare in basso verso l'asm: la completezza di un programmatore sta anche nel capire come funziona la macchina, non solo nel creare strutture logiche.
Ecco il segnale. Sotto con le asce da guerra ragazzi!
RaouL_BennetH
10-05-2007, 11:59
Il mio cent invece:
Attualmente sto studiando Java e C#.
Java sicuramente perchè è già presente e futuro (credo).
Il C# perchè l'ambiente .Net credo sia un buon investimento per le proprie conoscenze future.
Ho qualche piccolissima nozione di C (che a tempo perso continuo a studiare).
Inoltre, investo anche molto del mio tempo libero a studiare i database.
Di sicuro io non farò mai il programmatore nella vita, quindi queste mie scelte (non so se giuste o meno) non sono quindi dettate da motivi professionali.
RaouL.
Java, in tantissimi cercano persone che conoscano bene questo linguaggio.
Poi C# e Visual Basic.
phoenixbf
10-05-2007, 12:25
Per il mio lavoro ovviamente il C++
Java nel mio campo serve e ben poco. Il C++ permette di arrivare all'hardware in modo diretto, dove java non puo' assolutamente arrivare ne' tantomeno avere minimamente le prestazioni che ha un'app compilata in C++ (anche perche il java e' interpretato)
Quindi nel mio campo 3D/OpenGL ad alte prestazioni, il C++ regna sovrano (anche se bisogna stare piu' attenti a puntatori, garbage, etc etc....)
dove java non puo' assolutamente arrivare ne' tantomeno avere minimamente le prestazioni che ha un'app compilata in C++
Azz, avevo parlato di asce da guerra ma qui si passa direttamente alle granate incendiarie.
malbolge? ;)
Fosse concentriche dell'ottavo cerchio dell'inferno dantesco :confused:
Ho l'impressione che ci sia un significato metaforico dietro ma non lo colgo. :fagiano:
Fosse concentriche dell'ottavo cerchio dell'inferno dantesco :confused:
Ho l'impressione che ci sia un significato metaforico dietro ma non lo colgo. :fagiano:
no.. questo:http://en.wikipedia.org/wiki/Malbolge
RaouL_BennetH
10-05-2007, 14:55
malbolge? ;)
essì :) unito a brainfuck (esiste veramente http://it.wikipedia.org/wiki/Brainfuck ) credo siano i linguaggi più facili da imparare :O :cool:
:rotfl:
essì :) unito a brainfuck (esiste veramente http://it.wikipedia.org/wiki/Brainfuck ) credo siano i linguaggi più facili da imparare :O :cool:
:rotfl: guardate che il post #24 era serio :Prrr:
Azz, avevo parlato di asce da guerra ma qui si passa direttamente alle granate incendiarie. ma tu lascialo nella sua ignoranza: se non conosce il JIT che ti frega :asd:
edit - aggiungo: a quanto pare phoenixbf oltre che sparare inesattezze (Java interpretato?) spara anche balle :asd:
su questo forum molta gente ha avuto il grandissimo piacere di conoscere il caro vecchio fek; lui stava veramente nel settore della grafica 3D (e che grafica :eek: ), e non faceva altro che dire l'opposto di quanto detto da lui.
senza contare che phoenixbf da' molto l'impressione di non aver mai sentito parlare del mitico Jake, ovvero Java Quake :D
RaouL_BennetH
10-05-2007, 16:31
guardate che il post #24 era serio :Prrr:
Eh lo so che il post era serio :)
Ho "roflato" solo pensando a come sono scemo sperando di far credere che _per_me_ quei due linguaggi esoterici siano facili ! :)
A momenti manco il visual basic capisco, figuriamose :p
phoenixbf
10-05-2007, 19:00
ma tu lascialo nella sua ignoranza: se non conosce il JIT che ti frega :asd:
edit - aggiungo: a quanto pare phoenixbf oltre che sparare inesattezze (Java interpretato?) spara anche balle :asd:
su questo forum molta gente ha avuto il grandissimo piacere di conoscere il caro vecchio fek; lui stava veramente nel settore della grafica 3D (e che grafica :eek: ), e non faceva altro che dire l'opposto di quanto detto da lui.
senza contare che phoenixbf da' molto l'impressione di non aver mai sentito parlare del mitico Jake, ovvero Java Quake :D
ehhh???
Queste accuse personali adesso, da dove spuntano??
Per tua informazione, io programmo applicazioni OpenGL, ad essere precisi utilizzo OSG (www.openscenegraph.com) una libreria che si appoggia alle OpenGL e sul fatto del C++ non si discute.
Non conosco chi dici te,
ma nella mailing list di OSG ci sono sviluppatori che lavorano nel campo da anni, tra programmatori della NASA, MIT e quant'altro... che la pensano in modo diverso.
Siccome non voglio scatenare flame, ti dico solo:
fammi una applicazione in java che visualizzi in tempo reale un database paginato territoriale multi-layer, che regga milioni di alberi a run-time, e che utilizzi shader.
Perfavore, suvvia.... per queste cose si usa il C++
Java concordo che e' molto bello ed elegante, infatti vorrei impararlo meglio. Ma non si puo' utilizzare in questo ambito spinto.
In ogni caso non comprendo queste accuse personali. E "ignorante" sara' qualcun altro.
Non sai una mazza di me, di cosa faccio, di cosa sviluppo e cosa ho creato in passato. modera i toni.
Segnalato
Io tralascerei la classica entrata a gamba tesa con piede a martello di 71104. Ogni tanto lo fa, non so perchè.
Certi tipi di applicazioni si fanno in C++, è un dato di fatto. Il dubbio che mi attanaglia è: si fanno in C++ per qualità intrinseche dell'ecosistema C++ o si fanno in C++ perchè l'investimento in know how è tale da non rendere economicamente conveniente il passaggio a piattaforme più recenti?
Io punto sulla seconda perchè non ci vedo niente di strano. Posso star qui a pontificare sulla necessità che C++ sia lasciato alla storia. Ma se avessi una software house con 400 programmatori che sanno C++ dirgli "ragazzi, da domani Java" sarebbe, nel breve periodo, uno zinzinello costoso. Sono parecchi diversi già come lingue, figurarsi come piattaforme.
Non trascuriamo questo fatto del vil denaro. Perchè quando sarà Java ad essere obsoleto vedrete che ci sarà chi gli attribuirà le stesse qualità taumaturgiche. Non per qualità proprie ma per i miliardi di dollari che ancora gireranno intorno a quella piattaforma.
Rispondeno seriamente alla domanda, se dovessi decidere quale linguaggio imparare ora, direi senz'altro ruby; ho l'impressione che sarà quello che è stato Java in quest'ultimo decennio: quindi un ottimo investimento.
Rispondeno seriamente alla domanda, se dovessi decidere quale linguaggio imparare ora, direi senz'altro ruby; ho l'impressione che sarà quello che è stato Java in quest'ultimo decennio: quindi un ottimo investimento.
Quoto, è indubbiamente molto intessante...
Rispondeno seriamente alla domanda, se dovessi decidere quale linguaggio imparare ora, direi senz'altro ruby; ho l'impressione che sarà quello che è stato Java in quest'ultimo decennio: quindi un ottimo investimento.
sperando di non generare flame a me Ruby sembra l'ultima moda del web. Noi programmatori ci facciamo sempre affascinare da tutti i linguaggi che introducono qualche novità e Ruby unito a Rails sicuramente ne introduce. Resta da vedere il seguito che avrà.
Dovessi studiarmi un linguaggio sceglierei in base alle mie aspettative:
Php se ho poco tempo e voglio un linguaggio che mi fa fare tutto quello che voglio in poco tempo e con risultati tangibili e che poi all'occorrenza può dare risultati ben più potenti di un semplice scriptino. Il linguaggio più diffuso, trovi tonnellate di codice e milioni di persone pronte a darti una mano.
Java se voglio programmare per forza a oggetti ma non tanto (o non solo) sul web. Un pò di difficoltà iniziale ma comunque largamente utilizzato.
Poi se proprio voglio studiare un linguaggio che ha potenzialità guardarei a Python.
Personalmente ritengo che adesso visto che si fa tutto web-oriented e che (sempre sperando di non scatenare flame) java non è php (o python) e che le applicazioni in java sul web sono un tantino più pesantucce di quelle negli altri due linguaggi studierei uno di questi due linguaggi. Php o Python.
Se già li conosco proverei anche gli altri ma come primo linguaggio sconsiglio Ruby e gli altri perchè potresti correre il rischio di imparare un linguaggio di nicchia che in 10 anni scompare dalla scena (ad esempio ricordo ancora i periodi del "pascal miglior linguaggio del mondo"...):muro:
phoenixbf
10-05-2007, 23:07
ok reset.
Espongo la mia idea in maniera piu' comprensibile:
Mi piace Java, lo trovo molto elegante, lo sto utilizzando ora per creare un web-service per un progetto universitario.
ma nel mio campo (OpenGL e molte chiamate hardware) non e' assolutamente adatto e un eseguibile compilato da puro codice C++ sara' sempre piu performante.
Anche se il C++ ha le sue beghe, sempre attenti sui segmentation fault (e trovare l'errore in 7000 righe di codice non e' sempre facile) e gestire bene l'impronta di memoria.
Fortunatamente OSG, la lib che dicevo prima, fornisce dei puntatori speciali che gestiscono automaticamente le allocazioni/deallocazioni.
Mi piace anche e soprattutto leggere il codice degli altri.
Lo stile con cui e' progettato il tutto, la visione di insieme, col tempo si fa l'occhio anche a "perle" che ti spuntano fuori e pensi: "che bella questa soluzione, molto elegante".
Detto questo (e sorvolando il triste intervento che mi e' stato fatto da 71104...),
Tempo fa mi aveva incuriosito SmallTalk, pero' da quanto ho capito non sta avendo tanto successo...
Di recente sono anche tornato al C, per scrivere sotto linux una app di interfacciamento tra Beryl e il WiiMote della nintendo, la differenza si sente... il C++ mi ha viziato "un po" :)
su questo forum molta gente ha avuto il grandissimo piacere di conoscere il caro vecchio fek; lui stava veramente nel settore della grafica 3D (e che grafica :eek: ), e non faceva altro che dire l'opposto di quanto detto da lui.
non è esattamente cosi...da quel che ho capito (anche leggendo altri suoi post su altri forum), lui spinge per un uso di tencologie agili, e di linguaggi che ti facciano risparmiare tempo di sviluppo. Questo quando le condizioni di lavoro lo permettono.
Nella programmazione 3d pura dell'engine, anche lui si lamentava del fatto di aver bisogno di deallocare oggetti quando lo dice lui, e non quando lo dice il gc(sia di java sia di c#.net).
Questo non toglie che molte parti non time critical si possano fare con linguaggi definiti più produttivi.
Se poi ci sono applicazioni in cui si contano i cicli di clock (quasi letteralmente) java può non essere la soluzione.
Per ogni problemi c'è bisogno degli strumenti più adatti.
Non esiste la killer practice.
ps.fek sarebbe il benvenuto per chiarire le sue idee...chissà mai che ritorni...
essì :) unito a brainfuck (esiste veramente http://it.wikipedia.org/wiki/Brainfuck ) credo siano i linguaggi più facili da imparare :O :cool:
:rotfl:
vi segnalo una pagina http://members.fortunecity.it/kentaromiura/bfpage.html
dove si trova un "dialetto" di brainfuck con alcune aggiunte
e qui il codice #include
void main(int argc,char *argv[]){
FILE *input;
FILE *f1,*f2,*f3;
char p[16000];
long pr[16000];
long s;
int i=7999;
int r;
char c;
for(r=0;r<16000;r++){
p[r]=0;
pr[r]=NULL;
}
r=-1;
if(argc>4)f3=fopen(argv[4],"a");
if(argc>3)f2=fopen(argv[3],"w");
if(argc>2)f1=fopen(argv[2],"r");
if(argc>1)
if((input=fopen(argv[1],"r"))!=NULL){
while(!feof(input)){
fread(&c,1,sizeof(char),input);
/*printf("%c",c);*/
switch(c){
case '+':{p[i]++;break;}
case '-':{p[i]--;break;}
case '>':{if(i<15999)i++;break;}
case '<':{if(i>0)i--;break;}
case '[':{if(r<15999)r++;
pr[r]=ftell(input);
break;
}
case ']':{if(p[i]==0){if(r>-1)r--;}
else {s=pr[r];
if(pr[r]!=NULL)fseek(input,s,0);
break;
}
case '.':{c=p[i];printf("%c",c);break;}
case ',':{scanf("%c",&c);break;}
case 'r':{if(f1!=NULL)fread(&p[i],1,sizeof(char),input);break;}
case 'w':{c=p[i];
if(f2!=NULL)fwrite(&c,1,sizeof(char),f2);break;}
case 'W':{c=p[i];
if(f3!=NULL)fwrite(&c,1,sizeof(char),f3);break;}
case '/':{if(f1!=NULL)fread(&c,1,sizeof(char),f1);break;}
case '\\':{if((f2!=NULL)&&(ftell(f2)!=0))fseek(f2,-sizeof(char),1);break;}
case '?':{if(p[i]!=0)fread(&c,1,sizeof(char),input);}
case 'm':{if(p[i]<=0)fread(&c,1,sizeof(char),input);}
case 'l':{if(p[i]>=0)fread(&c,1,sizeof(char),input);}
case '%':{if(p[i]%2)fread(&c,1,sizeof(char),input);}
case '#':{if(!(p[i]%2))fread(&c,1,sizeof(char),input);}
}
}
}
}
}
ps non ho provato se funziona:rolleyes:
yorkeiser
11-05-2007, 09:33
Spezzo una lancia in favore di phoenixbf: il Java è un linguaggio che permette di fare anche il caffè, ma non è assolutamente adatto per applicazioni grafiche complesse. Chi ha lavorato sulla grafica, specialmente sul 3D, sa bene quanto siano pesanti le operazioni grafiche e quanto conti guadagnare anche pochi cicli macchina negli inner loop, ed è indubbio che il c (col ++ un pelino meno) sia il linguaggio più performante in assoluto, senza ovviamente scendere ai livelli dell'asm.
Qual'è l'ultimo progetto OpenGL che avete scritto in Java? E quale differenza avete notato rispetto allo stesso progetto scritto in C++?
Lo chiedo senza malizia: io non ho mai fatto questa comparazione e non so se la teoria (un programma Java per la piattaforma Java è teoricamente più performante di un programma staticamente compilato, provenga esso da sorgenti C, C++, Fortran o Assembly, per via del JIT e del Garbage Collector) messa in pratica "perda per strada" qualche pezzo.
albortola
11-05-2007, 20:09
grazie delle risposte, non pensavo fosse interessante a tal punto l'argomento.:)
io cmq intendo linguaggi espressamente utilizzati nel mondo del lavoro, anche se a dire il vero non so di certo in che ambito potrò/potrei trovarmi..:rolleyes:
ps: pare a me o il ruby è quasi + semplice del pascal?(ovvio, da quel pochissimo che ho trovato su wikipedia..) :D
dasdsasderterowaa
11-05-2007, 20:16
grazie delle risposte, non pensavo fosse interessante a tal punto l'argomento.:)
io cmq intendo linguaggi espressamente utilizzati nel mondo del lavoro, anche se a dire il vero non so di certo in che ambito potrò/potrei trovarmi..:rolleyes:
ps: pare a me o il ruby è quasi + semplice del pascal?(ovvio, da quel pochissimo che ho trovato su wikipedia..) :D
beh, i soliti: C/C++, C#, Java e Python...
Adesso arrivo io con una banalità (forse :p ) : visto che i linguaggi vanno e vengono, e non è dato (a meno di non chiamarsi Nostradamus e di esercitare la professione di profeti) sapere quale sarà il più diffuso, o usato, o richiesto, o spendibile, o semplicemente "di moda" tra dieci anni, non è forse il caso di porsi la domanda: quale paradigma/filosofia di programmazione è/sarà dominante tra dieci/vent'anni?
Rimango colpito dal fatto che molti chiedano se sia difficile imparare Java piuttosto che C# o C++... e nessuno che chieda come fare ad imparare bene la programmazione OO...
E non dico questo in quanto portatore di un'esperienza illuminante, o di una conoscenza superiore, ma perchè nella mia limitata esperienza personale ho avuto occasione di imparare umilmente quanto sia più difficile programmare ad oggetti che programmare in Java.
(Ah, naturalmente ha ragione da vendere PGI-Bis: conoscere il linguaggio in sè è uno scherzo, la sintassi di Java/C#/C/C++ si imparano in pochissimo (anche perchè, a costo di attirarmi accuse di superficialità, devo dire che sono simili in modo imbarazzante), conoscere le librerie è un altro paio di maniche... io sto cominciando adesso ad orientarmi nelle 1.4 di Java della Sun... e siamo alle 1.6! :cry: ).
phoenixbf
12-05-2007, 04:36
Adesso arrivo io con una banalità (forse :p ) : visto che i linguaggi vanno e vengono, e non è dato (a meno di non chiamarsi Nostradamus e di esercitare la professione di profeti) sapere quale sarà il più diffuso, o usato, o richiesto, o spendibile, o semplicemente "di moda" tra dieci anni, non è forse il caso di porsi la domanda: quale paradigma/filosofia di programmazione è/sarà dominante tra dieci/vent'anni?
.
Ottima domanda.
E la risposta e' difficile ovviamente, adesso come adesso mi sento di dire che l'OO campera' molto a lungo ancora, mi piace come filosofia, elegante, funzionale e soprattutto modulare (questo fattore lo vedo importante anche in vista del trend delle multi-CPU)
Al momento non saprei dire se ci sia un altro paradigma ancora meglio... futuro incerto ;)
^TiGeRShArK^
12-05-2007, 15:11
sort :: [:Float:] -> [:Float:]
sort a = if (length a <= 1) then a
else sa!0 +++ eq +++ sa!1
where
m = a!0
lt = [: f | f<-a, f<m :]
eq = [: f | f<a, f==m :]
gr = [: f | f<-a, f>m :]
sa = [: sort a | a <- [:lt,gr:] :]
:mbe:
a me pare veramente orrido :mbe:
molto meglio imho questo:
def qsort(list)
return [] if list.size == 0
x, *xs = *list
less, more = xs.partition{|y| y < x}
qsort(less) + [x] + qsort(more)
end
in ruby :p
^TiGeRShArK^
12-05-2007, 15:15
Per il mio lavoro ovviamente il C++
Java nel mio campo serve e ben poco. Il C++ permette di arrivare all'hardware in modo diretto, dove java non puo' assolutamente arrivare ne' tantomeno avere minimamente le prestazioni che ha un'app compilata in C++ (anche perche il java e' interpretato)
Quindi nel mio campo 3D/OpenGL ad alte prestazioni, il C++ regna sovrano (anche se bisogna stare piu' attenti a puntatori, garbage, etc etc....)
bhè..
non sono per niente d'accordo.
Innanzitutto il JAVA NON è interpretato.
Secondo punto se fosse così come dici basterebbe scrivere solo le parti critiche dell'applicazione in Open/GL e per tutto il resto si potrebbe anche utilizzare un vero linguaggio interpretato come il Python.
E ricordo che ci sono anche svariati binding Java/Open GL :p
^TiGeRShArK^
12-05-2007, 15:19
Io tralascerei la classica entrata a gamba tesa con piede a martello di 71104. Ogni tanto lo fa, non so perchè.
Certi tipi di applicazioni si fanno in C++, è un dato di fatto. Il dubbio che mi attanaglia è: si fanno in C++ per qualità intrinseche dell'ecosistema C++ o si fanno in C++ perchè l'investimento in know how è tale da non rendere economicamente conveniente il passaggio a piattaforme più recenti?
Io punto sulla seconda perchè non ci vedo niente di strano.
quoto ;)
phoenixbf
12-05-2007, 15:25
bhè..
non sono per niente d'accordo.
Innanzitutto il JAVA NON è interpretato.
Allora non stiamo parlando dello stesso linguaggio:
http://www.vlsilab.polito.it/thesis/alfonso/node87.html
Secondo punto se fosse così come dici basterebbe scrivere solo le parti critiche dell'applicazione in Open/GL e per tutto il resto si potrebbe anche utilizzare un vero linguaggio interpretato come il Python.
E ricordo che ci sono anche svariati binding Java/Open GL :p
Come dicevo prima, in questo campo serve tantissima ottimizzazione, soprattutto hw.
Non sto parlando di giochini OpenGL, sto parlando di app con i contro-co*****ni e gli eseguibili compilati da codice C++ sono piu' performanti.
E lo stesso vale per l'assembler.
Se uno fosse talmente guru e pazzo da riuscire a codificare una app direttamente in assembler, le performance sarebbero ancora superiori a quelle ottenute scrivendola in C o C++.
Ripeto che non sono cose che sostengo solo io, per carita'.
C'e' una intera comunita' di sviluppatori che la pensa come me, e questa e' gente che VERAMENTE mangia codice su codice, pranzo con java e cena con C++ con dessert di Python.
Per me questo discorso finisce qui.
Nel senso che devi portarmi una applicazione scritta in java che fa le stesse identiche cose che intendo io e con eguale performance.
E questo non e' possibile fidati.
Sottolineo che la mia è solo un'ipotesi. Magari c'è un'altra ragione. Magari chi sviluppa quel genere di programmi ha provato a farli con altri strumenti, ha fatto i confronti e ha verificato che per le ragioni X,Y e Z le altre tecnologie non sono concorrenziali. L'hanno fatto... e non l'hanno detto a nessuno. Ma è possibile che l'abbiano fatto.
^TiGeRShArK^
12-05-2007, 15:30
Qual'è l'ultimo progetto OpenGL che avete scritto in Java? E quale differenza avete notato rispetto allo stesso progetto scritto in C++?
Lo chiedo senza malizia: io non ho mai fatto questa comparazione e non so se la teoria (un programma Java per la piattaforma Java è teoricamente più performante di un programma staticamente compilato, provenga esso da sorgenti C, C++, Fortran o Assembly, per via del JIT e del Garbage Collector) messa in pratica "perda per strada" qualche pezzo.
in C++ non ho mai scritto un software OpenGL...
con il C mi limitavo ad accedere con l'inline assembly alla memoria video dato che ai tempi in cui internet non esisteva era un pò difficile procurarsi librerie grafiche che superassero le limitazioni di 320X200 256 colori e 640X480 16 colori :p
Per quanto riguarda Diamonds onestamente ho semplicemente usato le funzioni grafiche scritte da altri... tradotto: non mi sono messo a scrivere il Codice OpenGL effettivo ma mi sono appoggiato ai wrappers a disposizione.
Una considerazione:
Java è effettivamente limitato per le applicazioni Real-Time.
Il problema di Java nell'ambito della grafica 3d imho non dipende dalle scarse prestazioni del linguaggio, ma soprattutto dalla natura inerentemente non real-time del linguaggio.
Se stai facendo dei rendering a video di una scena non ti puoi permettere3 di perdere 500 ms perchè il GC ha deciso che deve rompere le Balle :p
E' pur vero però che esiste una versione Real-Time di Java, ma dal poco che ho visto è termendamente complessa da utilizzare per gestire i meccanismi tipici per le applicazioni real-time.
La soluzione migliore è imho utilizzare linguaggi di scripting per le parti meno avide di prestazioni del codice e andare ancora su C++ per le parti critiche.
Ma in effetti mi sa che è proprio quello verso cui si sta muovendo il mercato :p
phoenixbf
12-05-2007, 15:31
Sottolineo che la mia è solo un'ipotesi. Magari c'è un'altra ragione. Magari chi sviluppa quel genere di programmi ha provato a farli con altri strumenti, ha fatto i confronti e ha verificato che per le ragioni X,Y e Z le altre tecnologie non sono concorrenziali. L'hanno fatto... e non l'hanno detto a nessuno. Ma è possibile che l'abbiano fatto.
Infatti proprio sulla mailing list OSG usci' fuori una discussione del genere, su un porting della libreria in Java.
Pero' fu immediatamente smentito, da varie persone e con diverse argomentazioni, se ho tempo la ritrovo
^TiGeRShArK^
12-05-2007, 15:32
ps: pare a me o il ruby è quasi + semplice del pascal?(ovvio, da quel pochissimo che ho trovato su wikipedia..) :D
Il ruby dal punto di vista della leggibilità è IMHO il miglior linguaggio esistente.
Python lo trovo un pò + complesso.
Ok, siamo entrati nel campo della mitologia della scienza informatica :D.
^TiGeRShArK^
12-05-2007, 15:34
Ottima domanda.
E la risposta e' difficile ovviamente, adesso come adesso mi sento di dire che l'OO campera' molto a lungo ancora, mi piace come filosofia, elegante, funzionale e soprattutto modulare (questo fattore lo vedo importante anche in vista del trend delle multi-CPU)
Al momento non saprei dire se ci sia un altro paradigma ancora meglio... futuro incerto ;)
mmmm..
non conosco le altre filosofie in voga oggi...
Ma il paradigma ad oggetti non lo vedo ancora così in voga in futuro.
Basta ricordare ke l'informatica è in continua evoluzione e non possiamo sapere cosa avremo a disposizione tra 10 anni :p
x questo no nmi sbilancio su scommesse del genere :D
^TiGeRShArK^
12-05-2007, 15:41
Allora non stiamo parlando dello stesso linguaggio:
http://www.vlsilab.polito.it/thesis/alfonso/node87.html
evidentemente no ;)
Compilazione Just-In-Time
Le prime implementazioni del linguaggio usavano una virtual machine che intepretava il bytecode per ottenere la massima portabilità, definita Architecture Neutral. Questa soluzione si è però rivelata poco efficiente, in quanto i programmi interpretati erano molto lenti. Per questo, tutte le implementazioni recenti di macchine virtuali Java hanno incorporato un JIT compiler, cioè un compilatore interno, che al momento del lancio traduce al volo il programma bytecode Java in un normale programma nel linguaggio macchina del computer ospite. Inoltre, questa ricompilazione è dinamica, cioè la virtual machine analizza costantemente il modello di esecuzione del codice (profiling), e ottimizza ulteriormente le parti più frequentemente eseguite, mentre il programma è in esecuzione. Questi accorgimenti, a prezzo di una piccola attesa in fase di lancio del programma, permettono di avere delle applicazioni Java decisamente più veloci e leggere. Tuttavia, anche così Java resta un linguaggio meno efficiente dei linguaggi compilati come il C++, scontando il fatto di possedere degli strati di astrazione in più, e di implementare una serie di automatismi, come il garbage collection, che se da un lato fanno risparmiare tempo ed errori in fase di sviluppo dei programmi, dall'altro consumano memoria e tempo di CPU in fase di esecuzione del programma finito.
+ chiaro ora? ;)
Come dicevo prima, in questo campo serve tantissima ottimizzazione, soprattutto hw.
Non sto parlando di giochini OpenGL, sto parlando di app con i contro-co*****ni e gli eseguibili compilati da codice C++ sono piu' performanti.
E lo stesso vale per l'assembler.
Se uno fosse talmente guru e pazzo da riuscire a codificare una app direttamente in assembler, le performance sarebbero ancora superiori a quelle ottenute scrivendola in C o C++.
assolutamente no.
Con i compilatori attuali le prestazioni di un'applicazione scritta in C++ sono + che sufficienti.
L'assembly viene usato solo per ottimizzare le parti critiche di codice.
Se c'è un metodo che occupa il 40% della CPU e questo metodo è in una porzione dello 0.0001% del codice non mi metto certo a ottimizzare il 100% del codice ma solamente lo 0.0001% critico :p
Ripeto che non sono cose che sostengo solo io, per carita'.
C'e' una intera comunita' di sviluppatori che la pensa come me, e questa e' gente che VERAMENTE mangia codice su codice, pranzo con java e cena con C++ con dessert di Python.
gli ipse dixit non mi osno mai piaciuti :p
cmq ti assicuro che a livello di pranzo e cena (colazione solitamente non la faccio :p) non sono messo male nemmeno io :D
Per me questo discorso finisce qui.
Nel senso che devi portarmi una applicazione scritta in java che fa le stesse identiche cose che intendo io e con eguale performance.
E questo non e' possibile fidati.
Lo so benissimo che non è possibile..l'ho scritto prima :asd:
Il problema è che bisogna ricadere nel caso precedentemente spiegato dell'ottimizzazione.
Se tu hai grandi parti di codice che NON sono soggette a limitazioni prestazionali le puoi scrivere in qualsivoglia linguaggio.
Le parti critiche le devi scrivere nel linguaggio che ti dia il miglior rapporto tempo di programmazione speso/prestazioni ottenute.
E cmq con le versione Real Time di Java magari si sarà un pò + limitati nelle prestazioni... ma a livello di funzionalità, stuttering e cose del genere le due applicazioni sono assolutamente comparabili.
^TiGeRShArK^
12-05-2007, 15:44
Ok, siamo entrati nel campo della mitologia della scienza informatica :D.
ma la cosa + bella è mettersi a programmare in python sul cellulare durante un viaggio in macchina...altro che mitologia... è l'indice del puro rotolamento dei coglioni durante una coda di 2 ore di autostrada :asd:
phoenixbf
12-05-2007, 16:08
+ chiaro ora? ;)
Si ma il punto cruciale sono proprio questi step intermedi (tra l'altro lo dice il testo stesso). io ti parlo di un campo dove una app 3D in base al fatto che ti va a 60 FPS o 50 FPS determina il fallimento del progetto.
assolutamente no.
Con i compilatori attuali le prestazioni di un'applicazione scritta in C++ sono + che sufficienti.
L'assembly viene usato solo per ottimizzare le parti critiche di codice.
Se c'è un metodo che occupa il 40% della CPU e questo metodo è in una porzione dello 0.0001% del codice non mi metto certo a ottimizzare il 100% del codice ma solamente lo 0.0001% critico :p
Percio ho usato la parola "pazzo", non penso esista qualcuno in grado di gestire un intero progetto complesso in assembler...
Anche nei giochi, alcune parti critiche dell'engine sono sritte in assembler.
cmq ti assicuro che a livello di pranzo e cena (colazione solitamente non la faccio :p) non sono messo male nemmeno io :D
Ah beh, anche io mangio tanto :D
ma la cosa + bella è mettersi a programmare in python sul cellulare durante un viaggio in macchina...altro che mitologia... è l'indice del puro rotolamento dei coglioni durante una coda di 2 ore di autostrada :asd:
LOL
cdimauro
12-05-2007, 19:42
:mbe:
a me pare veramente orrido :mbe:
molto meglio imho questo:
def qsort(list)
return [] if list.size == 0
x, *xs = *list
less, more = xs.partition{|y| y < x}
qsort(less) + [x] + qsort(more)
end
in ruby :p
def QuickSort(List):
if len(List) <= 1: return List
Pivot = List.pop()
return QuickSort(filter(lambda x: x < Pivot, List)) + [Pivot] + QuickSort(filter(lambda x: x >= Pivot, List))
In Python :D
Interessante la funzione partition di Ruby. Molto elegante come linguaggio. :)
DvL^Nemo
13-05-2007, 10:00
Ruby, a lavoro qualcuno si sa interessando e ne parlano tutti bene.. ;)
:mbe:
a me pare veramente orrido :mbe:
molto meglio imho questo:
def qsort(list)
return [] if list.size == 0
x, *xs = *list
less, more = xs.partition{|y| y < x}
qsort(less) + [x] + qsort(more)
end
in ruby :p
Non e' poi tanto diverso, soprattutto se si tiene conto che la versione su esposta scala all'aumentare di processori/core. Volendo si puo' rinunciare ad un po' di performance e riscriverlo piu' o meno come segue:
qsort [: :] = [: :]
qsort array = lt +++ eq +++ gt
where
pivot = array!0
lt = qsort [: x | x <- array, x < pivot :]
eq = [: x | x <- array, x == pivot :]
gt = qsort [: x | x <- array, x > pivot :]
Direi che come chiarezza siamo li' (a me piace pure di piu', ma ad un certo punto e' anche questione di gusti).
Tra l'altro le VM di Python e Ruby hanno un po' di problemi nello sfruttare piu' processori, anche se probabilmente queste cose verranno prima o poi sistemate (jpython e jruby ad esempio non dovrebbero aver tali limit).
def QuickSort(List):
if len(List) <= 1: return List
Pivot = List.pop()
return QuickSort(filter(lambda x: x < Pivot, List)) + [Pivot] + QuickSort(filter(lambda x: x >= Pivot, List))
In Python :D
Ha un bug :p
occhio ai side effects
Ok, siamo entrati nel campo della mitologia della scienza informatica :D.
Piu' che di mitologia direi si tratta di campanilismo :p. Ognuno (mi ci metto dentro pure io) tende a dire la sua senza portare molti esempi o prove concrete a sostegno delle proprie convinzioni, e d'altra parte e' difficile farlo.
Per quel che riguarda le mie, devo dire che l'impressione che ho e' che effettivamente i programmi scritti in Java e C# siano in generale sensibilmente piu' lenti di una analoga controparte C/C++, ma che questo non sia dovuto tanto al linguaggio in se, quanto alla catasta di librerie che il programmatore si trova ad dover utilizzare, quasi nessuna pensata con le performance come primo obiettivo. Ad esempio in C++ gli stream di I/O sono molto piu' difficili da estendere, ma le uniche due operazioni costose risultano in pratica essere le operazioni riempimento/svuotamento del buffer.
D'altra parte se non fosse cosi' basterebbe compilare tutto con gcj... piuttosto, soprattutto nel campo delle applicazioni desktop, piu' di qualche applicazione Python da la sensazione di essere piu' "sveglia", anche se magari non e' la piu' veloce in giro.
cdimauro
14-05-2007, 22:05
Ha un bug :p
occhio ai side effects
Onestamente mi sfugge: potresti indicarmi dove starebbe il bug? Grazie. :)
EDIT: penso d'aver capito. :D
def QuickSort(List):
if len(List) <= 1: return List
Pivot = List.pop()
Less = filter(lambda x: x < Pivot, List)
More = filter(lambda x: x >= Pivot, List)
return QuickSort(Less) + [Pivot] + QuickSort(More)
Maledetta fretta. :p
EDIT2: è pure più leggibile. Meglio così. :D
Il problema permane per il ciclo piu' esterno.
Secondo me meglio non modificare la lista, e lavorare in modo piu' "funzionale". In sostanza al posto di
Pivot = List.pop()
io userei
Pivot = List[0]
List = List[1:]
cdimauro
15-05-2007, 22:10
Capito. Grazie. :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.