Discussione:
studiare il linguaggio macchina del commodore 64
(troppo vecchio per rispondere)
triller
2007-09-01 09:47:49 UTC
Permalink
salve, avrei una domandina da porvi. sono un nostalgico dei vecchi arcade
degli anno 80. per intenderci , quelli che giravano sul commodore 64. ho
sempre desiderato di cimentarmi nella programmazione di questi giochini 2d.
non mi va' l'idea di servirmi di quei software per la creazione semplificata
di videogames. ma vorrei realizarli in linguaggio macchina, propio come
venivano fatti originalmente. ma haime non conosco assolutamente questo tipo
di linguaggio.e quindi dovrei iniziare a studiarlo. la mia domanda e', lo
studio di questo linguaggio puo' servire anche ad altro? ,cioe'
professionalmente in qualche campo?.o al limite per capire meglio alcuni
concetti di programmazione dei linguaggi moderni?. chiedo questo perche' mi
sembra tempo sprecato studiarlo solo per realizzare vecchi giochini.
nibble
2007-09-01 10:11:03 UTC
Permalink
Post by triller
salve, avrei una domandina da porvi. sono un nostalgico dei vecchi arcade
degli anno 80. per intenderci , quelli che giravano sul commodore 64. ho
[CUT]
Post by triller
concetti di programmazione dei linguaggi moderni?. chiedo questo perche' mi
sembra tempo sprecato studiarlo solo per realizzare vecchi giochini.
I concetti di programmazione li impari anche con l'assembly per 8088.
Se vuoi un consiglio procurati un vecchio libro di Sacha-Norton
(quello dell'antivirus) che si chiama "Linguaggio Assembly per PC
IBM". E' molto datato ma � la migliore introduzione che abbia mai
letto sull'argomento. Se hai difficolt� nel trovarlo clicca su questo
link: http://www.elettropedia.org/assembly.htm

dove troverai delle lezioni in gran parte prese paripari dal libro in
questione.

Poi se vuoi approfondire l'argomento: "The Art of Assembly Language"
di Randall Hyde (2003)
ciao.
Luca Pascali
2007-09-01 10:16:25 UTC
Permalink
Post by triller
salve, avrei una domandina da porvi. sono un nostalgico dei vecchi arcade
degli anno 80. per intenderci , quelli che giravano sul commodore 64. ho
sempre desiderato di cimentarmi nella programmazione di questi giochini 2d.
non mi va' l'idea di servirmi di quei software per la creazione semplificata
di videogames. ma vorrei realizarli in linguaggio macchina, propio come
venivano fatti originalmente. ma haime non conosco assolutamente questo tipo
di linguaggio.e quindi dovrei iniziare a studiarlo. la mia domanda e', lo
studio di questo linguaggio puo' servire anche ad altro? ,cioe'
professionalmente in qualche campo?.o al limite per capire meglio alcuni
concetti di programmazione dei linguaggi moderni?. chiedo questo perche' mi
sembra tempo sprecato studiarlo solo per realizzare vecchi giochini.
Puoi programmare in C (tanto è quasi la stessa cosa :-) ).
Comunque l'assembly può servire quando si programmano routine di basso
livello relative ad uno specifico processore (generalmente per embedded
o per alcuni tipi di device driver).
Anche la regola del "lo faccio in assembly per avere migliori
prestazioni" ha iniziato a perdere valore. Scrivere un programma in C
permette di avere del codice veloce e snello quasi quanto scriverlo in
assembly (nel caso di un programmatore assembly che conosca il suo
lavoro) o decisamente migliore (nel caso di un programmatore assembly
alle prime armi). I compilatori, infatti, sono molto ottimizzati e fanno
il loro sporco lavoro abbastanza bene.

Dal punto di vista didattico, invece, reputo che imparare a programmare
in assembly abbia molto valore. Nessun artificio dei linguaggi di alto
livello come garbage collection, tipi per le stringhe, ecc (il C non è
un linguaggio di alto livello, ma si piazza poco sopra l'assembly).

Implementare algoritmi (o per iniziare semplici funzioni) in assembly è
una buona scuola per capire bene come funziona il processore e quindi
trattarlo come si deve.

Se poi volessi cimentarti sui vecchi Commodore, prova a vedere Vice. È
un emulatore di C64 C128 C16 e Vic20. (bei ricordi :-) )

Luca
triller
2007-09-02 16:09:21 UTC
Permalink
Post by Luca Pascali
Puoi programmare in C (tanto è quasi la stessa cosa :-) ).
ma del c ce ne una sola versione, o piu' versioni, come il c++?
io non conosco il c/c++ nel c#, ma sono pronto ad imparare
almeno uno di essi. secondo te', potrei pogrammare anche col c++
come con il c, gli arcade che mi piacciono tanto?, oppure e' piu'
indicato il c? ad esempio, leggo su' internet, che c'e' un c++ visuale
e un tipo non visuale, naturalmente se' va bene anche il c++ mi ci
vorra un complilatore del c++ non visuale vero?

altra domanda, ma il c# e' un evuluzione del c++ o e' un altra cosa
distinta?
Post by Luca Pascali
I compilatori, infatti, sono molto ottimizzati e fanno
il loro sporco lavoro abbastanza bene.
parlando di c++ qual'e' il milgior complilatore, leggo in giro che il
dev-c++
e' free, ed e' buono, ma ce ne sono anche di meglio a pagamento, qual'e' il
migliore? vorrei uno non propietario della microsoft. almeno su' questo
linguaggio
vorrei essere dipendente dalla mamma :-)
Post by Luca Pascali
Dal punto di vista didattico, invece, reputo che imparare a programmare
in assembly abbia molto valore. Nessun artificio dei linguaggi di alto
livello come garbage collection, tipi per le stringhe, ecc (il C non è
un linguaggio di alto livello, ma si piazza poco sopra l'assembly).
si ho deciso che mi dedichero anche a imparare assembly, pero' darei
precedenza a uno di questi 3 c/c++/c#, cosi faro' anche un investimento :-)

ma il c++ e' da ritenersi un linguaggio a baso livello come il c ?
Post by Luca Pascali
Implementare algoritmi (o per iniziare semplici funzioni) in assembly è
una buona scuola per capire bene come funziona il processore e quindi
trattarlo come si deve.
Se poi volessi cimentarti sui vecchi Commodore, prova a vedere Vice. È
un emulatore di C64 C128 C16 e Vic20. (bei ricordi :-) )
Luca
triller
2007-09-02 16:12:43 UTC
Permalink
Post by triller
vorrei essere dipendente dalla mamma :-)
pardon volevo scrivere indipendente :-)
Luca Pascali
2007-09-02 18:42:05 UTC
Permalink
Post by triller
Post by Luca Pascali
Puoi programmare in C (tanto è quasi la stessa cosa :-) ).
ma del c ce ne una sola versione, o piu' versioni, come il c++?
Esistono diversi standard. Bene o male, oggi, vanno quasi tutti sullo
stesso. Quello che cambia sono le librerie di contorno.
Post by triller
io non conosco il c/c++ nel c#, ma sono pronto ad imparare
almeno uno di essi. secondo te', potrei pogrammare anche col c++
come con il c, gli arcade che mi piacciono tanto?, oppure e' piu'
indicato il c? ad esempio, leggo su' internet, che c'e' un c++ visuale
e un tipo non visuale, naturalmente se' va bene anche il c++ mi ci
vorra un complilatore del c++ non visuale vero?
altra domanda, ma il c# e' un evuluzione del c++ o e' un altra cosa
distinta?
Programmare un arcade non è proprio banale. Ci sono tante cose di cui
tenere conto.
La differenza tra "visuale" e "non visuale", poi, mi sembra sia più
legata alla creazione delle maschere grafiche, oppure ad una più mera
questione di nome (come Borlad ha scelto il prefisso "Turbo")

Comunque il C, secondo me, è da imparare. Nel mondo viene ancora
richiesto molto e molti linguaggi imperativi hanno derivato la loro
sintassi dal C.
Il C++ ha in più del C il supporto per una programmazione ad oggetti.
Il C# è una ulteriore evoluzione che ha portato ad un linguaggio
veramente di alto livello, imperativo e orientato agli oggetti.

Quale sia migliore per gli arcade, non saprei.

Hai 3 approcci differenti.

In C hai un approccio imperativo procedurale. Niente oggetti, ma
strutture dati. La memoria è tua e te la gestisci tu (per richiamare uno
slogan degli anni '70), con il rischio (spesso alla base di bachi grossi
e grossolani di sicurezza) che ti dimentichi di deallocare la memoria,
oppure ne allochi una certa quantità e poi sfori (classico con le stringhe).

In C++ hai un approccio imperativo misto tra procedurale ed ad oggetti.
Riesci a fare tante cose, ma hai ancora il problema della memoria che è
completamente in mano tua.

In C#, invece, hai un approccio imperativo ad oggetti e non procedurale.
Finalmente hai un garbage collector che si prende la briga di liberare
la memoria se non è più necessaria, dei sistemi di monitoraggio della
memoria (che riduce la possibilità di andare oltre allo spazio
allocato), un tipo per le stringhe (nè il C, né il C++ ce l'hanno, in
C++ ci sono alcune librerie come QT, ecc che si creano il loro tipo
stringa) e non hai più i puntatori (una delle cose più comode e
pericolose del C).

,NET, la tecnologia che sta dietro a C#, è molto legata al mondo M$.
Esiste un progetto, Mono, sviluppato da Novell che ha come scopo quello
di portare i vantaggi di .NET al mondo non-Microsoft. Vediamo come va.
Post by triller
Post by Luca Pascali
I compilatori, infatti, sono molto ottimizzati e fanno
il loro sporco lavoro abbastanza bene.
parlando di c++ qual'e' il milgior complilatore, leggo in giro che il
dev-c++
e' free, ed e' buono, ma ce ne sono anche di meglio a pagamento, qual'e' il
migliore? vorrei uno non propietario della microsoft. almeno su' questo
linguaggio
vorrei essere dipendente dalla mamma :-)
distinguiamo tra IDE e compilatori.
Dev-c++ è un ide.
Visual Studio è un ide.

Con VS ti becchi anche il compilatore di mamma M$ per il/i linguaggio/i
per cui l'IDE è pensato.

Per programmare basterebbe anche notepad o altro editor minimale. Gli
IDE sono un'ottima cosa perché ti aiutano (con la colorazione,
l'evidenziazione delle parentesi, il riconoscimento dei nomi di funzioni
e variabili, ecc) nella scrittura del codice.

"Il migliore" è un concetto che in informatica non ha senso.
Esiste una cosa migliore per qualcuno in un determinato contesto.

Come compilatori, invece, gcc lo trovi su tutte le architetture e tutti
i sistemi operativi, quello che fa la differenza sono le librerie di
contorno.
Per sviluppare programmi per mamma M$, i suoi IDE e i suoi compilatori
vanno bene (VSexpress è gratuito come anche l'SDK, limitati, ma
gratuiti, anche MSDN è ora gratuita. Preparati, però, a scaricare
qualche giga di roba O_o)
Post by triller
Post by Luca Pascali
Dal punto di vista didattico, invece, reputo che imparare a programmare
in assembly abbia molto valore. Nessun artificio dei linguaggi di alto
livello come garbage collection, tipi per le stringhe, ecc (il C non è
un linguaggio di alto livello, ma si piazza poco sopra l'assembly).
si ho deciso che mi dedichero anche a imparare assembly, pero' darei
precedenza a uno di questi 3 c/c++/c#, cosi faro' anche un investimento :-)
ma il c++ e' da ritenersi un linguaggio a baso livello come il c ?
Più ad alto livello rispetto al C, ma non so se classificarlo come alto
livello.
Hai ancora i puntatori, una dipendenza dei tipi dall'architettura per la
quale compili (compresa la differenza tra little-endian e big-endian),
non hai un tipo stringa nativo, devi essere tu ad allocare e deallocare
la memoria.

Comunque, ad oggi, C e C++ sono ancora molto richiesti. Più di Java.
Vale la pena investire in C# in quanto M$ sta decidendo di abbandonare C
e C++ per lo sviluppo di sw per Windows (il solito modo approssimativo e
miope di lavorare tipico degli americani)
Comunque conoscendo il C (e bene gli algoritmi in C) e il C++ (e anche
qui algoritmi in paradigma ad oggetti) non dovresti avere poi problemi
per imparare altri linguaggi. Almeno fintanto che rimani tra i linguaggi
imperativi.

[...]
Post by triller
Post by Luca Pascali
Luca
crxor 666
2007-09-07 17:43:58 UTC
Permalink
Post by Luca Pascali
Il C# è una ulteriore evoluzione che ha portato ad un linguaggio
veramente di alto livello, imperativo e orientato agli oggetti.
Sul fatto che sia un' "evoluzione" poi ci sarebbe da discutere.
Tipicamente non sono d'accordo. Sono due linguaggi *diversi*, C# è solo
più recente.

Esattamente come non definirei Java un'evoluzione di C++
(un'involuzione, semmai). A questo punto non saprei come piazzare C#, a
seconda di come lo piazziamo con Java.
Post by Luca Pascali
In C++ hai un approccio imperativo misto tra procedurale ed ad oggetti.
Preferisco dire che è *multiparadigma*. Essere *esclusivamente* ad
oggetti è uno svantaggio, che porta a cose discutibili e innaturali come
dovere usare una classe fittizia per fare rientrare dalla finestra le
vecchie funzioni.
Post by Luca Pascali
Riesci a fare tante cose, ma hai ancora il problema della memoria che è
completamente in mano tua.
1. Il problema della memoria in mano tua è un falso problema, una volta
che apprendi il paradigma RAII.

2. C++ *resta* un linguaggio di livello medio basso.

3. C# non è che si 'elevi di molto'. Anzi.
Post by Luca Pascali
un tipo per le stringhe (nè il C, né il C++ ce l'hanno, in
C++ ci sono alcune librerie come QT, ecc che si creano il loro tipo
stringa)
Ma hai mai dato un occhio alla libreria standard di C++?
Post by Luca Pascali
Esiste un progetto, Mono, sviluppato da Novell che ha come scopo quello
di portare i vantaggi di .NET al mondo non-Microsoft. Vediamo come va.
Diciamo che non mi fiderei tantissimo.
Post by Luca Pascali
Per programmare basterebbe anche notepad o altro editor minimale.
Si, ma già che ci siamo suggeriamo qualcosa di decente. Che so, Emacs,
vim, TextMate. Magari qualcosina per Windows.
Post by Luca Pascali
Gli
IDE sono un'ottima cosa perché ti aiutano (con la colorazione,
l'evidenziazione delle parentesi, il riconoscimento dei nomi di funzioni
e variabili, ecc) nella scrittura del codice.
In effetti tutto questo lo fanno anche la maggior parte degli editor da
me menzionati. Lasciando stare Emacs che si configura, in effetti, come
un IDE.
Post by Luca Pascali
Più ad alto livello rispetto al C, ma non so se classificarlo come alto
livello.
Assolutamente no, alto livello no di certo. Non oggi. Come non
collocherei ad 'alto livello' C# o Java.
Sono linguaggi di 'livello medio'. C++ di per se sarebbe un linguaggio
di livello medio-basso, tuttavia sapendolo usare come si deve (ovvero
*non* come viene insegnato sui manualetti Deitel), si ritrova pure lui
come linguaggio di livello medio.
Post by Luca Pascali
Hai ancora i puntatori, una dipendenza dei tipi dall'architettura per la
quale compili (compresa la differenza tra little-endian e big-endian),
non hai un tipo stringa nativo, devi essere tu ad allocare e deallocare
la memoria.
Ma è vero che C++ non ha un tipo stringa *nel linguaggio* (che vuole
dire che non ha un 'letterale stringa C++'). Tuttavia ha un tipo stringa
nella libreria standard. Che, per lavorarci, è esattamente la stessa
cosa. Mettiamo poi insieme il fatto che il letterale stringa viene dal C
*e* ci puoi inizializzare le std::string e abbiamo chiuso il cerchio.

Chiaramente con std::string non allochi e deallochi nulla. Idem se usi i
fior di contenitori della libreria standard. Insomma, se uno vuole usa
C++ 'male', liberissimo. Ma se lo usa bene, buona parte dei problemi
menzionati non sussiste.

L'inghippo di C++ è che è uno dei linguaggi più complessi da imparare ad
usare *bene*. Ha tante features diverse e bisogna saperle incastrare.
Post by Luca Pascali
Comunque, ad oggi, C e C++ sono ancora molto richiesti. Più di Java.
No. Assolutamente no. C e C++ *sono* molto richiesti. Ma Java lo è di
più. Il fatto che il 95% dei lavori per cui richiedono Java non mi
interessi, è un altro discorso. Esattamente come è un altro discorso il
fatto che se posso non lavoro in Java tout court.

Ma il fatto è che con Java offrono più lavori. Non solo: per lavorare in
C o in C++ bisogna sapere quello che si fa. Per Java si trovano anche
tanti lavoracci, d'altra parte è talmente verboso...
Post by Luca Pascali
Vale la pena investire in C# in quanto M$ sta decidendo di abbandonare C
e C++ per lo sviluppo di sw per Windows (il solito modo approssimativo e
miope di lavorare tipico degli americani)
Mah. È tanto che dicono che MS abbandona C e C++. Io invece vedo che MS
sta cercando sempre più di fare interagire C++ con .Net e che al momento
buona parte del loro sw sia tutt'ora in C++.
Post by Luca Pascali
Comunque conoscendo il C (e bene gli algoritmi in C) e il C++ (e anche
qui algoritmi in paradigma ad oggetti) non dovresti avere poi problemi
per imparare altri linguaggi. Almeno fintanto che rimani tra i linguaggi
imperativi.
Anche se partire da C o peggio da C++ è la strada più dura.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
Roberto Montaruli
2007-09-07 18:05:53 UTC
Permalink
Post by crxor 666
Anche se partire da C o peggio da C++ è la strada più dura.
Partire dal C o dal C++ e poi passare ad altro e' dura perche' una volta
acquisita la padronanza con il C e col C++ il resto disgusta.
crxor 666
2007-09-07 19:02:15 UTC
Permalink
Post by Roberto Montaruli
Partire dal C o dal C++ e poi passare ad altro e' dura perche' una volta
acquisita la padronanza con il C e col C++ il resto disgusta.
Mi pare un punto di vista assai miope. Pur non reputandomi un guru di
C++, mi ritengo discretamente skillato, e in effetti ancora più in C.

Eppure il resto, lungi dallo schifarmi, mi attrae e lo apprezzo assai.
Adoro Haskell, per esempio. Non sono un Lisper, ma è un'altro linguaggio
che apprezzo tantissimo. Sono perfino riuscito a farmi piacere Prolog.
E adoro Python e Ruby. Ah, e sicuramente me ne sono scordati parecchi
fra quelli che 'apprezzo'.

Non solo: su icl.c++ un po' di tempo fa ci si lamentava scherzosamente
della 'fuga' di molti poster storici verso it.comp.lang.python. Tanto
per dire.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
Roberto Montaruli
2007-09-07 20:27:33 UTC
Permalink
Post by crxor 666
Post by Roberto Montaruli
Partire dal C o dal C++ e poi passare ad altro e' dura perche' una volta
acquisita la padronanza con il C e col C++ il resto disgusta.
Mi pare un punto di vista assai miope.
Quando ti abitui a poter fare tutto e il contrario di tutto, e poi ti
ritrovi ad avere a che fare con linguaggi pesanti e limitativi, altro
che disgusto.
crxor 666
2007-09-07 22:33:37 UTC
Permalink
Post by Roberto Montaruli
Quando ti abitui a poter fare tutto e il contrario di tutto, e poi ti
ritrovi ad avere a che fare con linguaggi pesanti e limitativi, altro
che disgusto.
Io trovo limitativo dovere scrivere diverse linee di codice per quello
che con un altro linguaggio faccio con una, per dire.

Per non parlare di quanto trovo limitante il tentativo di C++ di
convincermi che devo essere paranoico *verso* i miei colleghi
sviluppatori (il buon vecchio Naggum non perdona).

Detto questo per considerare 'pesante' e 'limitativo' Python o Ruby, ce
ne vuole. Per non parlare delle stesse considerazioni applicate a Lisp,
Haskell o OCaml. Ma direi soprattutto a Lisp.

Permettimi di dire che da quanto scrivi sembrerebbe che forse hai molta
esperienza con C++, ma altro non hai visto.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
crxor 666
2007-09-07 22:42:29 UTC
Permalink
Post by Roberto Montaruli
Quando ti abitui a poter fare tutto e il contrario di tutto, e poi ti
ritrovi ad avere a che fare con linguaggi pesanti e limitativi, altro
che disgusto.
Io trovo limitativo dovere scrivere diverse linee di codice per quello
che con un altro linguaggio faccio con una, per dire.

Per non parlare di quanto trovo limitante il tentativo di C++ di
convincermi che devo essere paranoico *verso* i miei colleghi
sviluppatori (il buon vecchio Naggum non perdona).

Detto questo per considerare 'pesante' e 'limitativo' Python o Ruby, ce
ne vuole. Per non parlare delle stesse considerazioni applicate a Lisp,
Haskell o OCaml. Ma direi soprattutto a Lisp.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
Roberto Montaruli
2007-09-08 09:28:37 UTC
Permalink
Post by crxor 666
Post by Roberto Montaruli
Quando ti abitui a poter fare tutto e il contrario di tutto, e poi ti
ritrovi ad avere a che fare con linguaggi pesanti e limitativi, altro
che disgusto.
Io trovo limitativo dovere scrivere diverse linee di codice per quello
che con un altro linguaggio faccio con una, per dire.
Esatto.
E' molto limitativo dover scrivere
MID(a$, 3, 1)
quando puoi scrivere
a[2];
che e' anche molto piu' comprensibile.

Oppure e' limitativo dover scrivere

IF a=1 THEN
b=1
ELSE
b=0
END IF

quando in una sola riga puoi scrivere

b = (a==1) ? 1 : 0;

Quindi concordi con me quando dico che una volta raggiunta la padronanza
del C il resto e' pesante e limitativo.
crxor 666
2007-09-08 11:19:02 UTC
Permalink
Post by Roberto Montaruli
Quindi concordi con me quando dico che una volta raggiunta la padronanza
del C il resto e' pesante e limitativo.
ROTFL. Io ci ho anche provato a fare un discorso serio.
Comunque il mondo non è fatto solo di C++ e Basic, eh. Ma fa lo stesso.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
Roberto Montaruli
2007-09-08 19:34:19 UTC
Permalink
Post by crxor 666
Post by Roberto Montaruli
Quindi concordi con me quando dico che una volta raggiunta la padronanza
del C il resto e' pesante e limitativo.
ROTFL. Io ci ho anche provato a fare un discorso serio.
Comunque il mondo non è fatto solo di C++ e Basic, eh. Ma fa lo stesso.
Al di la' della facile ironia, pure io sono disposto a fare un discorso
serio.

Riesci a pormi qualche esempio concreto in cui si riesca a fare qualcosa
con qualche linguaggio in modo piu' semplice che in C?
Parliamone.

Intanto nel frattempo mi e' pure venuto in mente quanto sia potente la
printf per produrre un output formattato, cosa che ho sempre sofferto in
tutti i linguaggi che non implementano una funzione in grado di
interpretare la formattazione come fa la printf(), tanto per spezzare
un'altra lancia in favore del C e affini.
Lawrence Oluyede
2007-09-08 22:08:02 UTC
Permalink
Post by Roberto Montaruli
Riesci a pormi qualche esempio concreto in cui si riesca a fare qualcosa
con qualche linguaggio in modo piu' semplice che in C?
Cioè, è una domanda seria questa? Dimmi che stai scherzando.
--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
crxor 666
2007-09-09 08:10:18 UTC
Permalink
Post by Lawrence Oluyede
Cioè, è una domanda seria questa? Dimmi che stai scherzando.
Io credo che si faccia prima con un esempio. Ma non me ne vengono in
mente di buoni. O troppo piccolo o troppo 'scripting' o troppo grossi.
Pensavo al quicksort in Haskell, ho pensato pure ad una traccia di
webspider in Python. Se no avrei da recuperare una macchina virtuale +
compilatore di espressioni aritmetiche per suddetta macchina virtuale in
Prolog (il tutto in meno di 100 righe).
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
crxor 666
2007-09-09 08:10:17 UTC
Permalink
Post by Roberto Montaruli
Al di la' della facile ironia, pure io sono disposto a fare un discorso
serio.
In primo luogo, se tu pensi ad una cosa come Basic e Pascal, non saprei
cosa dirti: sono tutti linguaggi più o meno dello stesso livello del C,
eventualmente meno comodi.

Io invece parlo di linguaggi particolarmente diversi. Ho nominato
linguaggi di alto livello, linguaggi con un paradigma dichiarativo
funzionale e linguaggi con un paradigma dichiarativo logico. Stiamo
parlando di bestioline parecchio differenti da quello cui puoi pensare
se hai in mente Pascall o Basic (o analoghi, ho solo nominato due
linguaggi molto conosciuti diversi da C).
Post by Roberto Montaruli
Riesci a pormi qualche esempio concreto in cui si riesca a fare qualcosa
con qualche linguaggio in modo piu' semplice che in C?
Parliamone.
Esempi di che ambito? Ho sostanzialmente l'imbarazzo della scelta.
L'inghippo di domande poste così è che, per l'appunto se scelgo un
esempio 'piccolo' sembra una puttanatina 'da scripting', se scelgo un
esempio un po' meno piccolo per fare qualcosa di significativo dovrei
comunque mettermi a scriverlo.

IMHO si fa prima se ci accordiamo se tu hai presente alcuni dei
linguaggi di cui ho parlato (in caso contrario l'idea te la fai in modo
eccellente guardando sul web).

D'altra parte ti confesso che sono molto stupito. Una domanda del tipo
'mi fai vedere che esiste qualcosa che si fa più semplicemente in Python
che in C, oppure in Haskell che in C' è allucinante; la risposta
dovrebbe essere ovvia guardando i linguaggi stessi.

E nota che questo non è un argomento del tipo 'C fa schifo'. È solo un
argomento del tipo: in Python fai prima. Perchè? Perchè lavori ad un
livello più alto, non ti devi curare dei vari dettagli implementativi e
tutto.

Come se qualcuno ti chiedesse di dimostrargli che lavorare in C è più
produttivo (anzi, che in almeno un caso lavorare in C è più produttivo)
che farlo in asm.
Post by Roberto Montaruli
Intanto nel frattempo mi e' pure venuto in mente quanto sia potente la
printf per produrre un output formattato, cosa che ho sempre sofferto in
tutti i linguaggi che non implementano una funzione in grado di
interpretare la formattazione come fa la printf(), tanto per spezzare
un'altra lancia in favore del C e affini.
Ti faccio alcuni esempi. Python, Perl e Ruby *non* sono linguaggi affini
al C. Ruby *ha* una funzione printf che si comporta come quella del C.
Idem Perl. Python va oltre: la stringa stessa ha un operatore % che data
una stringa di formattazione 'printf-style' e gli argomenti ti genera la
stringa. In pratica è la snprint built-in nel linguaggio.

Questo solo per nominarne alcuni. Haskell pure ha una printf.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
Roberto Montaruli
2007-09-09 08:51:53 UTC
Permalink
Post by crxor 666
Post by Roberto Montaruli
Al di la' della facile ironia, pure io sono disposto a fare un discorso
serio.
In primo luogo, se tu pensi ad una cosa come Basic e Pascal, non saprei
cosa dirti: sono tutti linguaggi più o meno dello stesso livello del C,
eventualmente meno comodi.
Io invece parlo di linguaggi particolarmente diversi. Ho nominato
linguaggi di alto livello, linguaggi con un paradigma dichiarativo
funzionale e linguaggi con un paradigma dichiarativo logico. Stiamo
parlando di bestioline parecchio differenti da quello cui puoi pensare
se hai in mente Pascall o Basic (o analoghi, ho solo nominato due
linguaggi molto conosciuti diversi da C).
Io invece sto parlando della stessa funzionalita' operativa, medesima,
identica. Stesso contesto.
Sto parlando della programmazione in ambito client-server su server IIS,
dove potendo utilizzare indifferentemente ASP o JSP, nonostante sia
immensamente piu' pratico, comodo, veloce, sicuro, utilizzare JSP,
l'azienda impone ASP (e qui tralascio volutamente di esternare il mio
parere in proposito per evitare la censura).

Non si possono confrontare pere con chiodi, ma pere con mele magari si'.
Post by crxor 666
Post by Roberto Montaruli
Riesci a pormi qualche esempio concreto in cui si riesca a fare qualcosa
con qualche linguaggio in modo piu' semplice che in C?
Parliamone.
Esempi di che ambito? Ho sostanzialmente l'imbarazzo della scelta.
L'inghippo di domande poste così è che, per l'appunto se scelgo un
esempio 'piccolo' sembra una puttanatina 'da scripting', se scelgo un
esempio un po' meno piccolo per fare qualcosa di significativo dovrei
comunque mettermi a scriverlo.
Di fatto, almeno nella mia piccola personale esperienza, quando si
tratta di scrivere grossi blocchi di codice elaborativo (quindi non
chiamate alla pappa pronta, ma assegnazione di variabili, cicli, salti
condizionati), tutti i linguaggi si equivalgono, chi piu' chi meno.

E' proprio nelle piccole cose, nella gestione un po' piu' raffinata dei
tipi di dati, nella scansione di liste custom, nella gestione dei files,
che il C (e linguaggi similari) gode di quei piccoli vantaggi che me lo
fanno preferire ai vari linguaggi Basic-like.
Post by crxor 666
IMHO si fa prima se ci accordiamo se tu hai presente alcuni dei
linguaggi di cui ho parlato (in caso contrario l'idea te la fai in modo
eccellente guardando sul web).
D'altra parte ti confesso che sono molto stupito. Una domanda del tipo
'mi fai vedere che esiste qualcosa che si fa più semplicemente in Python
che in C, oppure in Haskell che in C' è allucinante; la risposta
dovrebbe essere ovvia guardando i linguaggi stessi.
Diamine, il Python non e' un sostituto o una alternativa al C, il Python
e' altro.
Il Python me lo puoi paragonare al Perl, non al C.
Post by crxor 666
E nota che questo non è un argomento del tipo 'C fa schifo'. È solo un
argomento del tipo: in Python fai prima. Perchè? Perchè lavori ad un
livello più alto, non ti devi curare dei vari dettagli implementativi e
tutto.
Appunto.
Post by crxor 666
Come se qualcuno ti chiedesse di dimostrargli che lavorare in C è più
produttivo (anzi, che in almeno un caso lavorare in C è più produttivo)
che farlo in asm.
Dipende sempre dal contesto.
A me e' capitato di avere a che fare con un circuito dalle
caratteristiche molto particolari: disponevo di 256 byte (ho detto byte)
di ram, nei quali dovevo farci stare stack e variabili.
Non c'era alterntativa all'ASM, perche' il compilatore C di quel
processore non permetteva una gestione della memoria cosi' raffinata.

E' chiaro che senza limitazioni hardware il C sia decisamente piu'
comodo dell'ASM.
Post by crxor 666
Post by Roberto Montaruli
Intanto nel frattempo mi e' pure venuto in mente quanto sia potente la
printf per produrre un output formattato, cosa che ho sempre sofferto in
tutti i linguaggi che non implementano una funzione in grado di
interpretare la formattazione come fa la printf(), tanto per spezzare
un'altra lancia in favore del C e affini.
Ti faccio alcuni esempi. Python, Perl e Ruby *non* sono linguaggi affini
al C. Ruby *ha* una funzione printf che si comporta come quella del C.
Idem Perl. Python va oltre: la stringa stessa ha un operatore % che data
una stringa di formattazione 'printf-style' e gli argomenti ti genera la
stringa. In pratica è la snprint built-in nel linguaggio.
Questo solo per nominarne alcuni. Haskell pure ha una printf.
Sono infatti linguaggi piu' recenti che hanno preso dal C le cose buone.
Pure per la manipolazione di stringhe Python e compagnia hanno preso
spunto dal C, migliorando immensamente la gestione degli array di
caratteri, vedi gli indici negativi per contare i caratteri dalla fine
della stringa.

Solo il basic e' rimasto indietro di oltre 20 anni con quella
fetentissima funzione MID, e l'ASP dietro a ruota.
crxor 666
2007-09-09 10:05:07 UTC
Permalink
Post by Roberto Montaruli
Io invece sto parlando della stessa funzionalita' operativa, medesima,
identica. Stesso contesto.
Sto parlando della programmazione in ambito client-server su server IIS,
dove potendo utilizzare indifferentemente ASP o JSP, nonostante sia
immensamente piu' pratico, comodo, veloce, sicuro, utilizzare JSP,
l'azienda impone ASP (e qui tralascio volutamente di esternare il mio
parere in proposito per evitare la censura).
Ti confesso che tutta sta roba mi interessa poco. Non lavoro con
tecnologie MS e basta.
Post by Roberto Montaruli
Di fatto, almeno nella mia piccola personale esperienza, quando si
tratta di scrivere grossi blocchi di codice elaborativo (quindi non
chiamate alla pappa pronta, ma assegnazione di variabili, cicli, salti
condizionati), tutti i linguaggi si equivalgono, chi piu' chi meno.
Si, no, dipende. Per esempio gestire le stringhe in C è oggettivamente
più 'complesso' che in Python. In effetti anche i cicli in qualche modo
non sono equivalenti (come 'funzionalità, si, non come 'scrittura').

In C hai in pratica iterazione su una variabile scalare, su un puntatore
(che pure è in effetti una variabile scalare, anche se non a livello
semantico) oppure una 'catena' di puntatori (penso a grafi, alberi,
liste).

I for di Python sono diversi e normalmente la 'logica' di iterazione
viene buttata dentro l'oggetto, non è 'esplicita' nel ciclo. Nel ciclo
sai solo che ti arriva il 'prossimo' per qualche valore di prossimo
dipendente da quello con cui stai operando.

In Ruby addirittura non hai uno 'statement' ciclo, ma tipicamente
'passi' un blocco *dentro* l'oggetto.

Haskell non ha manco i cicli, e te la streghi con funzioni ausiliarie e
ricorsione (e la cosa è pure abbastanza comoda, a seconda di quello che
fai... io lo ho usato per manipolazione di alberi di sintassi astratta,
macchine virtuali, etc etc etc). Prolog come sopra. Non hai i cicli.
Non solo, in Haskell e Prolog non 'assegni' alle variabili.

Insomma, ribadisco, finchè stai con C, Pascall (che pure non mi
dispiace) e Basic[0] la strutturazione del codice è simile e la
'comodità' è altra.

Il vecchio Pascal mancava di operatori cortocircuitati, per dire, la
qual cosa è comodissima. Basic vuole dire tutto e nulla (ultimamente
hanno fatto anche dei Basic quasi decorosi, fuori da MS).
Esattamente come si può paragonare C++ e Java (e io preferisco il
primo).
Post by Roberto Montaruli
E' proprio nelle piccole cose, nella gestione un po' piu' raffinata dei
tipi di dati, nella scansione di liste custom, nella gestione dei files,
che il C (e linguaggi similari) gode di quei piccoli vantaggi che me lo
fanno preferire ai vari linguaggi Basic-like.
Ma non ho alcun dubbio e sono su tutta la linea. Tempo fa volevo
scrivere un piccolo interprete logo per fare un programmino per bambini.
Volevo vedere come si faceva in RealBasic (uno dei Basic 'carini'),
principalmente perchè me ne parlano tutti bene e volevo provarlo pure
io.

Solo per scrivere il tokenizer ho dato nuovi significati al concetto di
bestemmiare. Cioè in pratica il pezzo più stronzo in assoluto era già un
dito in un occhio: ma mica per il fatto che mi devo gestire 'a mano'
l'automa degli stati (la mia è quasi una scelta 'volontaria' in questo
senso, probabilmente lo farò anche se userò C, alla fine, cosa di cui
comunque dubito, vedo ben candidato Haskell, se solo trovo librerie
grafiche con cui sia comodo interfacciarlo -- la tartarughina non
perdona).

In pratica una stringa *non* è una lista di caratteri. E fin qui va
bene: nemmeno in Python lo è. Nel senso che iterando su una stringa ho
stringhette di un carattere. Tuttavia suddetta iterazione in Python è
piuttosto agevole, e il fatto che dal punto di vista dell'object model
quelle siano str e non caratteri non è particolarmente rilevante, visto
che si comportano come fossero caratteri, vuoi per il confronto, per la
conversione ad ascii etc etc etc. In RealBasic *no*. E RealBasic non è
in se e per se malaccio, dopo tutto ha praticamente l'object model di
Java 1.4 'vero' (non alla VB). Beh, non completo, non hai le classi
anonime, per dire. Mi pare.
Post by Roberto Montaruli
Diamine, il Python non e' un sostituto o una alternativa al C, il Python
e' altro.
Il Python me lo puoi paragonare al Perl, non al C.
Beh, io non lo paragonerei nemmeno al Perl. In Python riesci a gestire
progetti di dimensione arbitraria senza grossi problemi di
strutturazione etc. Perl non è altrettanto comodo, IMHO.

Comunque si, fondamentalmente quando uno usa C 'dove va usato', li non
ci userebbe Python. Tuttavia Python ha, per dire, una copertura
praticamente totale degli usi frequenti di Java, oltre che altri ancora.
E ha anche una certa sovrapposizione con C++, quando questo non viene
usato negli 'usi da C'.
Post by Roberto Montaruli
Dipende sempre dal contesto.
Certo. Ma addirittura tu mi avevi chiesto *un* caso in cui fosse più
produttivo, solo che dai tuoi esempio io avevo nasato che tu pensavi a
Basic, mentre io Basic non me lo stavo cagando e pensavo a linguaggi di
ben altro tenore.
Post by Roberto Montaruli
A me e' capitato di avere a che fare con un circuito dalle
caratteristiche molto particolari: disponevo di 256 byte (ho detto byte)
di ram, nei quali dovevo farci stare stack e variabili.
Non c'era alterntativa all'ASM, perche' il compilatore C di quel
processore non permetteva una gestione della memoria cosi' raffinata.
Non ho dubbi eh.
Post by Roberto Montaruli
Solo il basic e' rimasto indietro di oltre 20 anni con quella
fetentissima funzione MID, e l'ASP dietro a ruota.
Vero.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
Lawrence Oluyede
2007-09-07 20:09:38 UTC
Permalink
Post by Roberto Montaruli
Partire dal C o dal C++ e poi passare ad altro e' dura perche' una volta
acquisita la padronanza con il C e col C++ il resto disgusta.
Esagerato, ci son tanti di quei linguaggi e paradigmi là fuori che è un
peccato ignorarli in toto ;)
--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
Luca Pascali
2007-09-07 21:47:54 UTC
Permalink
[...]
Post by crxor 666
Post by Luca Pascali
Riesci a fare tante cose, ma hai ancora il problema della memoria che è
completamente in mano tua.
1. Il problema della memoria in mano tua è un falso problema, una volta
che apprendi il paradigma RAII.
Sul discorso della necessità di garbage collector ci sono state fior di
discussioni.
È come discutere se è meglio la programmazione procedurale o quella
orientata agli oggetti.
Post by crxor 666
2. C++ *resta* un linguaggio di livello medio basso.
Mai definito tale, anzi, ho avanzato dubbi *se* classificarlo come alto
livello.
Post by crxor 666
3. C# non è che si 'elevi di molto'. Anzi.
Certamente più di C e C++. È comunque più slegato dall'architettura
fisica su cui gira il programma. Con il C e il C++ bisogna stare attenti
anche all'architettura cui è destinato il programma per fare scelte di
tipi (nativi) di variabili e altro.

[...]
Post by crxor 666
Post by Luca Pascali
Per programmare basterebbe anche notepad o altro editor minimale.
Si, ma già che ci siamo suggeriamo qualcosa di decente. Che so, Emacs,
vim, TextMate. Magari qualcosina per Windows.
Io ho detto quello che è sufficiente.
Anche io mi trovo meglio con Emacs e VI.
Quando mi tocca utilizzare Windows, dove possibile, mi porto dietro
Emacs e GVim. Dove non possibile mi devo accontentare.
Post by crxor 666
Post by Luca Pascali
Gli
IDE sono un'ottima cosa perché ti aiutano (con la colorazione,
l'evidenziazione delle parentesi, il riconoscimento dei nomi di funzioni
e variabili, ecc) nella scrittura del codice.
In effetti tutto questo lo fanno anche la maggior parte degli editor da
me menzionati. Lasciando stare Emacs che si configura, in effetti, come
un IDE.
Con Emacs ci si fa anche il caffè, e se conosci bene il Lisp glielo fai
pure bere :-)
Diverse persone che conosco lo hanno paragonato ad un quasi sistema
operativo.
A parte questo e a parte Emacs, gli IDE (mea culpa, pensavo di averlo
detto) guidano anche alla gestione del progetto, e alla gestione dei
parametri per complazione, linking e debugging.

[...]
Post by crxor 666
Post by Luca Pascali
Comunque, ad oggi, C e C++ sono ancora molto richiesti. Più di Java.
No. Assolutamente no. C e C++ *sono* molto richiesti. Ma Java lo è di
più. Il fatto che il 95% dei lavori per cui richiedono Java non mi
interessi, è un altro discorso. Esattamente come è un altro discorso il
fatto che se posso non lavoro in Java tout court.
Ma il fatto è che con Java offrono più lavori. Non solo: per lavorare in
C o in C++ bisogna sapere quello che si fa. Per Java si trovano anche
tanti lavoracci, d'altra parte è talmente verboso...
Si vede che consideriamo settori differenti.

[...]
Post by crxor 666
Post by Luca Pascali
Comunque conoscendo il C (e bene gli algoritmi in C) e il C++ (e anche
qui algoritmi in paradigma ad oggetti) non dovresti avere poi problemi
per imparare altri linguaggi. Almeno fintanto che rimani tra i linguaggi
imperativi.
Anche se partire da C o peggio da C++ è la strada più dura.
Forse dura, ma non inutile.

Luca
crxor 666
2007-09-07 22:33:37 UTC
Permalink
Post by Luca Pascali
Sul discorso della necessità di garbage collector ci sono state fior di
discussioni.
È come discutere se è meglio la programmazione procedurale o quella
orientata agli oggetti.
Assolutamente. Quello che voglio limitarmi a dire è che RAII è un
paradigma (buono o cattivo) che se usato non ti fa sentire la mancanza
di un garbage collector. O meglio, ci sono *evidentemente* casi in cui
il gc ti manca, esattamente come in un linguaggio gc ci sono casi in cui
RAII sarebbe desiderabile alquanto.

Non a caso Python ha aggiunto un supporto (limitato) per RAII. D pure
sta cercando di supportare entrambi.

Il problema 'della memoria in mano' è invece un problema in C, dove le
cose vanno gestite *veramente* a mano, e mancano pure le eccezioni
strutturate che rendono comoda la vita.
Post by Luca Pascali
Certamente più di C e C++. È comunque più slegato dall'architettura
fisica su cui gira il programma. Con il C e il C++ bisogna stare attenti
anche all'architettura cui è destinato il programma per fare scelte di
tipi (nativi) di variabili e altro.
Vero entrambi: anche se, complessivamente, le questioni legate
all'architettura in cui mi sono imbattuto sono più legate alla presenza
o meno di determinate funzioni e eventualmente alla loro semantica.
Parlo soprattutto di alcune robe ti ambito tipicamente *nix, comunque
abbastanza ben gestite tramite il carrozzone/autotools.

Riguardo ai tipi, in effetti non ho mai cozzato in tali problemi. Al
limite se ci vuole serializzazione, ci sono tool che lo fanno per me.

Poi io non sono certo uno del C++ sempre e comunque, anzi.
Post by Luca Pascali
Io ho detto quello che è sufficiente.
Anche io mi trovo meglio con Emacs e VI.
Quando mi tocca utilizzare Windows, dove possibile, mi porto dietro
Emacs e GVim. Dove non possibile mi devo accontentare.
Certo. Dicevo solo, visto che ci siamo, indirizziamolo bene.
Specialmente gvim è veramente ben portato sotto Windows. Emacs,
purtroppo, non altrettanto. IMHO.
Post by Luca Pascali
A parte questo e a parte Emacs, gli IDE (mea culpa, pensavo di averlo
detto) guidano anche alla gestione del progetto, e alla gestione dei
parametri per complazione, linking e debugging.
Vero. Specialmente ai parametri di compilazione, linking e debugging. Il
'progetto' lo vedo sempre più spesso gestito anche dagli 'editor'. Per
esempio il debugger integrato è proprio tipico degli IDE. Idem per il
pitturatore di GUI.
Post by Luca Pascali
Si vede che consideriamo settori differenti.
No, io consideravo il *numero*. Ribadisco, a me il settore maggiormente
coperto da Java non mi cale punto. Resta il fatto che analizzando
*globalmente* le offerte, ne vedo di più per Java.
Post by Luca Pascali
Forse dura, ma non inutile.
Bisogna poi vedere quale sia lo scopo. Per 'imparare a programmare'
(qualunque cosa voglia dire), per esempio mi chiedo se è veramente il
caso. Per 'imparare a progettare' (cosa IMHO inscindibile) forse un
linguaggio più snello e agile aiuterebbe. Per 'vedere' i dettagli
implementativi certo, C aiuta. Ma siamo sicuri che non siano una cosa da
affrontare 'con calma'.

C++ mi sento invece di escluderlo come linguaggio didattico. È troppo
facile imparare ad usarlo in modo atroce, per capire cosa usare quando è
utile un po' di esperienza.
--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
Roberto Montaruli
2007-08-31 11:46:15 UTC
Permalink
Post by triller
salve, avrei una domandina da porvi. sono un nostalgico dei vecchi arcade
degli anno 80. per intenderci , quelli che giravano sul commodore 64. ho
sempre desiderato di cimentarmi nella programmazione di questi giochini 2d.
non mi va' l'idea di servirmi di quei software per la creazione semplificata
di videogames. ma vorrei realizarli in linguaggio macchina, propio come
venivano fatti originalmente. ma haime non conosco assolutamente questo tipo
di linguaggio.e quindi dovrei iniziare a studiarlo. la mia domanda e', lo
studio di questo linguaggio puo' servire anche ad altro? ,cioe'
professionalmente in qualche campo?.o al limite per capire meglio alcuni
concetti di programmazione dei linguaggi moderni?. chiedo questo perche' mi
sembra tempo sprecato studiarlo solo per realizzare vecchi giochini.
Lo studio del linguaggio macchina dei microprocessori e' interessante,
anche se oggio come oggi non mi sentirei di consigliare a nessuno di
perderci troppo tempo.
Chi ha avuto la fortuna di aver vissuto quel periodo d'oro e ha appreso
il modo di scrivere in codice macchina, ne avra' avuto giovamento negli
anni seguenti, ma mettersi ora a ripercorrere quelle orme e' un po' come
mettersi a fare dei graffiti sui muri cercando di imitare quelli
preistorici.

In ogni caso l'utilita' di scrivere procedure in codice macchina puo'
avere senso nella misura in cui non pretendi di leggere input dalla
tastiera e di scrivere output a video, perche' queste funzionalita' sono
maledettamente legate all'hardware delle macchine dell'epoca.
E pretendere di scrivere un videogame vuol dire proprio fare queste
cose: leggere la tastiera (o il joystick) e produrre un output a video.

Oggi come oggi il linguaggio macchina puro serve per scrivere codici di
controllo su impianti che utilizzano quei processori, quindi tutt'altro
che videogames.
Luca Pascali
2007-09-01 12:00:38 UTC
Permalink
[...]
Post by Roberto Montaruli
In ogni caso l'utilita' di scrivere procedure in codice macchina puo'
avere senso nella misura in cui non pretendi di leggere input dalla
tastiera e di scrivere output a video, perche' queste funzionalita' sono
maledettamente legate all'hardware delle macchine dell'epoca.
E pretendere di scrivere un videogame vuol dire proprio fare queste
cose: leggere la tastiera (o il joystick) e produrre un output a video.
Quoto.
Questo è un aspetto veramente importante per il quale sconsigliare la
scrittura di un applicativo utilizzando l'assembly: un tempo i programmi
giravano sul processore, oggi girano sotto sistema operativo (quindi con
una serie di automatismi che astraggono dall'hardware).
In più ci si sta muovendo verso un livello in cui lo stesso "binario"
possa essere eseguito su più architetture (come con .NET/Mono, Java e
qualsiasi altro linguaggio abbia una macchina virtuale e compili verso
bytecode), oppure che possa essere compilato per più architetture (non
parlo solo di Win 32 o 64 bit, ma anche e soprattutto applicativi per
ARM, PPC, e altre architetture, un programma che possa essere
cross-compilato per le varie architetture deve necessariamente
utilizzare l'assembly delle singole architetture il meno possibile e
affidarsi ai compilatori)
Post by Roberto Montaruli
Oggi come oggi il linguaggio macchina puro serve per scrivere codici di
controllo su impianti che utilizzano quei processori, quindi tutt'altro
che videogames.
Dimentichi la scrittura di parti di firmware di dispositivi vari o di
embedded (PIC e quant'altro).
Comunque concordo, tutt'altro che videogiochi.


Però era bello il mondo delle 4kIntro :-)

LP
Continua a leggere su narkive:
Loading...