[OT]: Il linguaggio Basic al giorno d'oggi

[alka]

Volevo notificare che ho accodato il messaggio di PirataLith su PureBasic in questa discussione, dato che mi sembra in tono e più adatta al contesto rispetto al lasciarla chiusa e isolata sul forum.

Ciao e buona prosecuzione!

[Raffaele]

Provate BLITZ BASIC!

E' uno dei migliori sul mercato, è velocissimo e farà cambiare a molti idea sulla presunta lentezza del Basic...

[alka]

Originariamente inviato da Raffaele
farà cambiare a molti idea sulla presunta lentezza del Basic...

Un linguaggio non può essere "lento" o "veloce", in quanto è solo un linguaggio.

E' il compilatore e l'architettura su cui lavora che determina questo fattore.

Ciao!

[Raffaele]

Originariamente inviato da alka
Un linguaggio non può essere "lento" o "veloce", in quanto è solo un linguaggio.

E' il compilatore e l'architettura su cui lavora che determina questo fattore.

Ciao!

Stiamo parlando del BASIC, e al 90% delle volte sull' 70/80% delle piattaforme, questo viene usato in maniera INTERPRETATA...

I linguaggi interpretati di solito sono lenti per natura, a causa del fatto che l'interprete deve farsi carico di dialogare con il resto dell'architettura soft/hardware mentre "interpreta" (appunto) il programma e lo manda in esecuzione. Ci possono essere interpreti più veloci o più lenti di altri. Quello del Blitz Basic è notevole per come è ingegnerizzato.

Che poi programmi Basic in Quick, GWBASIC, Blitz, o Visual possano essere anche COMPILATI, e girare standalone come qulsiasi eseguibile, magari qualche volta con il PICCOLO aiuto di librerie runtime, questo è un altro discorso.

[oregon]

Originariamente inviato da Raffaele
Stiamo parlando del BASIC, e al 90% delle volte sull' 70/80% delle piattaforme, questo viene usato in maniera INTERPRETATA...

Ma queste percentuali come le hai calcolate?

Attualmente, quali sono gli interpreti BASIC utilizzati che tu conosci?

[PirataLith]

Originariamente inviato da Raffaele
Stiamo parlando del BASIC, e al 90% delle volte sull' 70/80% delle piattaforme, questo viene usato in maniera INTERPRETATA...

I linguaggi interpretati di solito sono lenti per natura, a causa del fatto che l'interprete deve farsi carico di dialogare con il resto dell'architettura soft/hardware mentre "interpreta" (appunto) il programma e lo manda in esecuzione. Ci possono essere interpreti più veloci o più lenti di altri. Quello del Blitz Basic è notevole per come è ingegnerizzato.

Che poi programmi Basic in Quick, GWBASIC, Blitz, o Visual possano essere anche COMPILATI, e girare standalone come qulsiasi eseguibile, magari qualche volta con il PICCOLO aiuto di librerie runtime, questo è un altro discorso.

Per quanto ricordi...

QuickBasic è interpretato (se non erro);
GWBasic è interpretato;
Blitz può essere SOLO compilato (l'interprete entra in gioco in caso di debug);
Visual Basic richiede il runtime sia quando viene interpretato sia quando viene compilato (e non è piccolo per niente);.

Per quanto riguarda le percentuali, se ti fai un giro per internet (per esempio su Wikipedia ti renderai conto per il Basic venne concepito già all'epoca come un linguaggio compilato, e successivamente (grazie a costrutti molto semplici, BASIC appunto) fu più comodo l'utilizzo di un interprete, ma sempre per scopi didattici!

Poi, ribadiamo che non sempre interpretato = male!

Il java, per esempio, è un linguaggio interpretato! Quando si manda in esecuzione un suo eseguibile, questo viene compilato al volo dalla console JIT (appunto, Just In time) ed eseguito!

[alka]

Originariamente inviato da PirataLith
Il java, per esempio, è un linguaggio interpretato! Quando si manda in esecuzione un suo eseguibile, questo viene compilato al volo dalla console JIT (appunto, Just In time) ed eseguito!

E' una contraddizione: quando c'è un JIT che "compila al volo" il bytecode, non è interpretato, ma compilato, appunto.

O mi sbaglio?

La considerazione è un po' offtopic...ma è tanto per chiarire le differenze.

Poi, sono d'accordo che "intepretato = male" sia superficiale: l'interpretazione, benchè più lenta, fornisce determinati servizi; la scelta dell'uno o dell'altra dipende sempre dal peso e dalle necessità che si vogliono dare ai servizi offerti da un eventuale runtime oppure alle performance.

Ciao!

[oregon]

Originariamente inviato da PirataLith
QuickBasic è interpretato (se non erro);

QB era anche compilato.

Originariamente inviato da PirataLith
Visual Basic richiede il runtime sia quando viene interpretato sia quando viene compilato (e non è piccolo per niente);.

Non vedo quale sia il motivo di questa precisazione, fatta da tanti in realta'. Il codice VB puo' esseer compilato come faresti per il C.
Anche il C ha necessita' di un runtime ... basta utilizzare una printf e c'e' la necessita' della msvcrt.dll ... qual e' la differenza?

[PirataLith]

Originariamente inviato da alka
E' una contraddizione: quando c'è un JIT che "compila al volo" il bytecode, non è interpretato, ma compilato, appunto.

O mi sbaglio?

La considerazione è un po' offtopic...ma è tanto per chiarire le differenze.

Uhm... qui si potrebbe aprire un topic apparte (immagino i flame a non finire) ma, se prendiamo per assioma che un eseguibile "COMPILATO" è considerato tale, quando è viene compilato all'atto della creazione fisica dell'eseguibile (Helloworld.exe), allora anche il bytecode di java viene "interpretato".

Poi, boh, alla fine funziona? Bene? E' portabile? E allora, checcefrega? (penso che, appunto, l'interpretazione di codice porta a maggiore portabilità dello stesso di un codice precompilato... java docet!)

Originariamente inviato da oregon
Non vedo quale sia il motivo di questa precisazione, fatta da tanti in realta'. Il codice VB puo' esseer compilato come faresti per il C.
Anche il C ha necessita' di un runtime ... basta utilizzare una printf e c'e' la necessita' della msvcrt.dll ... qual e' la differenza?

La differenza è che il C può funzionare in console e senza runtime aggiuntivi mente il VB, sia per l'esecuzione che la chiusura del sul codice, necessita di alcune chiamate alla Runtime.

[oregon]

Originariamente inviato da PirataLith
La differenza è che il C può funzionare in console e senza runtime aggiuntivi mente il VB, sia per l'esecuzione che la chiusura del sul codice, necessita di alcune chiamate alla Runtime.

C puo' includere staticamente le librerie, questo e' vero, pero' a scapito della grandezza finale dell'eseguibile ... non mi pare che questo sia *sempre* un vantaggio ...

Non capisco cosa intendi per "chiusura del codice" di VB ...