Newsgroup: it.comp.os.dibattiti
Titolo: OT La cultura informatica in Italia

 assembly con qualche facilitazione. [...]
...

):

Che c'e' di errato ?
  ngw
-- 
http://www.tochunky.org


Mi sa tanto che tu non hai capito quello che c'e' scritto
-- 
Work is the curse of the drinking classes.
-Oscar Wilde

> assembly con qualche facilitazione. [...]
VB è un linguaggio di alto livello. Poi magari fa schifo. E ci sono
linguaggi di livello ancora più alto, ma è certamente di livello abbastanza
alto.
Sicuramente quando è nato era un linguaggio di livello piuttosto alto. Ora
è solo che siamo abituati a linguaggi di livello ancora più alto.
Quella del C come assembly con qualche facilitazione è in buona sostanza
una provocazione, ma ha un fondo di verità. C è pensato soprattutto per
essere efficiente e *portabile* (è questo che lo distingue da ASM). 
Certo, tecnicamente un 'assembly' è una cosa ben precisa (e il C non lo è).
Ma resta comunque il fatto che è *estremamente* vicino alla macchina.


Cultura informatica di chi? forse la tua...
Sai cosa si intende con linguaggio di "alto livello" e "basso
livello"?
Guarda che non sono giudizi sulla *bontà* del linguaggio...

 > > assembly con qualche facilitazione. [...]
Forse VOI avete problemi con l'italiano.
[...] VB é un PROGRAMMA di alto livello [...] è diverso che dire
[....] VB é un LINGUAGGIO di alto livello [...]
Poi dire che il C è un ASSEMBLY non ha alcun fondo di verità. Può
essere vicino alla macchina quanto volete ma un ASSEMBLY è un
linguaggio mnemonico che traduce in stringhe comprensibili il
linguaggio macchina e ha con questo un rapporto 1 a 1.
Cavolo, qui non si hanno solo problemi di cultura generale ma anche di
lingua.

 Poi dire che il C è un ASSEMBLY non ha alcun fondo di verità.
Certo... ma probabilmente era un modo sintetico per dire che è di
livello decisamente più basso rispetto a VB... estrapolare due frasi
da chissà quale discorso non è che abbia molto senso...

 Poi dire che il C è un ASSEMBLY non ha alcun fondo di verità. 
E' una cosa detta di frequente. Ed è semplicemente un'iperbole.
-- 
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.

 Ma resta comunque il fatto che è *estremamente* vicino alla macchina.
Per curiosità, esiste un qualche linguaggio che sia una via di mezzo tra il C
e ASM?
-- 
7.  In albergo a Rimini, niente bagni in piscina.  Secondo recenti
statistiche, a Rimini in estate ogni tre secondi c'e' qualcuno che si
chiede: "Perche' dovrei uscire dalla piscina per andare in bagno?".
		-- Daniele Luttazzi, 13 consigli per chi va in vacanza,
		   postata su it.hobby.umorismo [7/13]

 e ASM?
La domanda è abbastanza poco chiara. Cosa vuole dire 'via di mezzo'?
FORTRAN potrebbe essere una risposta (anche di quello hanno detto
'assembly portabile') scherzosa. 
Una risposta seria è che in un sorgente C puoi infilare codice ASM.
Anche se è facile creare codice meno ottimizzato in questo modo, a meno
di non sapere veramente quello che si fa.


 di non sapere veramente quello che si fa.
Si, puoi, ma non e` /assolutamente portabile/ ne` garantito dallo 
standard. Non esiste alcun _asm, __asm__ o similari, sono estensioni 
del compilatore.
-- 
Sensei <senseiwa@Apple's mail>
Haiku of the month:       Three things are certain
                          Death, taxes, and lost data
                          Guess which has occurred.

 del compilatore.
Beh, nell'annesso J dello standard del C99 si trova (a pagina 512):
J.5.10 The asm keyword 
1) The asm keyword may be used to insert assembly language directly into
the translator output (6.8). The most common implementation is via a
statement of the form:
asm ( character-string-literal ); 
Tuttavia asm *non* è una keyword definita fra le altre.
In C++ invece asm è una keyword del linguaggio (presentata nel paragrafo
2.11 e in particolare nella terza tabella). 
Nella grammatica entra anche una asm-definition come tipo valido di
block-declaration.
Quando viene chiarito, nel paragrafo 7.4 dice:
[dcl.asm] 7.4 Theasmdeclaration 
1 An asm declaration has the form 
asm-definition: 
        asm (string-literal ) ; 
The meaning of an asm declaration is implementation-defined.
[Note:Typically it is used to pass information through the
implementation to an assembler. ] 
Ovviamente è una cosa 'implementation' defined, ma tecnicamente non è
un'estensione del compilatore. Semplicemente è implementation defined,
esattamente come l'effettiva lunghezza di un int.


 esattamente come l'effettiva lunghezza di un int.
Yep, anche se nel C traspare 'may be used' e 'most common' che mi fanno 
un po' pensare alla non necessita` dell'uso di 'asm' al posto di 
'__asm__' o altri. Interessante, e chiaramente non portabile in nessun 
modo :)
-- 
Sensei <senseiwa at Apple's mac dot com>
Top 10 Oxymorons:
(Retail product) "Microsoft Works"

 modo :)
D'altra parte avrebbe anche poco senso, tanto cambiando processori,
convenzioni di chiamata e tutto, anche avendo la keyword portabile, non
sarebbe il core.


 sarebbe il core.
Quello che non mi piace e` che anche la keyword non e` stata stabilita, 
ne` la sintassi. Avrebbero potuto almeno definire che ne so
const char ohyeah[7] = "hello\n\r$"
asm (" mov ah, 09h \
       lea dx, ohyeah \
       int 21h \
     ")
Almeno si sapeva come mettere le cose, e cio` che e` dentro asm("...") 
e` completamente ignoto. Scelte dell'ISO committee.
-- 
Sensei <senseiwa at Apple's mac dot com>
We know Linux is the best, it can do infinite loops in five seconds.
(Linus Torvalds)

 e` completamente ignoto. Scelte dell'ISO committee.
Guarda, noi lavoriamo su cose *molto* tecniche riguardo al C e al C++. E
posso dire che il documento è talmente pieno di ambiguità e imprecisioni
da fare paura. Questo è il meno.
Se giri un po' sui ng in inglese dedicati allo standard, c'è da prendere
paura.


 paura.
Io leggo moltissimo da comp.lang.c, ma non da quello che riguarda lo 
standard in se. Credo che le ambiguita` pero` siano inevitabili.
-- 
Sensei <senseiwa at Apple's mac dot com>
Error. Keyboard not attached. Press F1 to continue...
(Real BIOS Error)

 Credo che le ambiguita` pero` siano inevitabili.
Affatto. Se dessero le specifiche usando la semantica operazionale, le
ambiguità non ci sarebbero. Esattamente come in matematica. Beh, anche
la denotazionale andrebbe bene, solo la trovo un po' più matematichese e
meno informatichese.


 meno informatichese.
Le specifiche le danno con le grammatiche, e comunque le ambiguita` 
esistono per forza di cose, purtroppo un sistema di descrizione non 
puo` comprendere tutto ed essere anche consistente.
-- 
Sensei <senseiwa at Apple's mac dot com>
There is no reason for any individual to have a computer in his home.
(Ken Olsen, President, Digital Equipment, 1977)

 puo` comprendere tutto ed essere anche consistente.
No. Una grammatica descrive la sintassi e un piccolo numero di casi
della semantica (la cosidetta semantica statica, tipi, roba così). Ma
non può descrivere interamente la semantica di un linguaggio di
programmazione. Perchè se lo facesse, sarebbe un formalismo
turing-completo, cosa che non è.
Io ti dico che i sistemi di descrizione formali che comprendono tutto ed
sono consistenti *esistono*. Potresti leggerti il libro di Winskel
'Formal Semantics of Programming Languages. An Introduction' edito dalla
MIT Press. Li ti descrive anche i principali.
Il problema è che è ci vuole tempo e attenzione per scrivere in tali
formalismi la semantica di un linguaggio di programmazione. Ma sono un
linguaggio matematico, non ambigui (a meno di non introdurre
*volutamente* l'ambiguità, come nel caso di una implementation defined
behaviour).


 behaviour).
A tua conoscenza hanno mai definito linguaggi standard (ISO, non quelli 
puramente accademici come FL)?
-- 
Sensei <senseiwa at Apple's mac dot com>
There are 10 types of people in the world:
those who understand binary, and those who don't.

 puramente accademici come FL)?
Noi dovremmo avere in giro sparso su un po' di documenti una definizione
quasi completa di C (ma dovrei controllare). Ma quelli che ratificano
gli standard no. Perchč tanto molti programmatori non saprebbero
leggerli.
Eppure č un vero peccato. Data una specifica formale, le cose si
semplificherebbero molto. 
Si fa prima a fare una traduzione 'informale' poi, senza perdita di
informazione. Se poi pensi che ci sono anche linguaggi la cui
definizione č l'interprete... (fino a poco tempo fa Perl era cosě).


 definizione è l'interprete... (fino a poco tempo fa Perl era così).
cough cough cough
Sbaglio o qui fa caldo ? :D
  ngw
-- 
http://www.tochunky.org

 Sbaglio o qui fa caldo ? :D
:) [ ma non l'ho capita, me la riscrivi in ASM Z80? ]


 [ ma non l'ho capita, me la riscrivi in ASM Z80? ]
Trovami la specifica di Ruby :D
  ngw
-- 
http://www.tochunky.org

 Trovami la specifica di Ruby :D
vabbe', ma ruby è relativamente giovane (sventagl', sventagl')
LOL
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it

 Trovami la specifica di Ruby :D
Beh, ah. ROTFL. In effetti hai ragione. Però va anche detto che di Ruby
ci sono almeno quattro interpreti. Quello ufficiale, JRuby, YARV e credo
anche uno per .Net.
Quindi immagino che una qualche forma di definizione (fossero anche gli
unit tests) esiste. Ovviamente è una cosa subottimale. Però *comunque*
quando dai le specifiche a parole lasciano tante quelle ambiguità che un
malato potrebbe fare un compilatore che segue alla lettera lo standard,
ma che per il resto sorprende il programmatore con bachi inaspettati.
