Giusto ma il mercato indirizza gli sforzi di milioni di programmatori, i quali realizzano anche strumenti di programmazione. Per cui non è detto che quello che cerchi esista già. Al che o lo crei ( sarebbe uno sforzo futile e titanico nel caso di un linguaggio di programmazione ) o accetti quello che c'è. Del resto i linguaggi differiscono nelle astrazioni e nella sintassi. Il primo punto può essere un problema, il secondo è solo questione di abituarsi.
Ad oggi è C il signore dell'embedded. C++ per progetti fatti con hardware un pò più capaci. Basic è inadatto, Pascal ha uno share piccolissimo, Ada è ignoto al 99% dei programmatori.
Nel caso dell'elettronica analogica c'è ben poco da programmare. Per le architetture x86 esiste tutto quanto fatto negli ultimi 40 anni.
L'unico linguaggio del genere è quello che ti crei tu.
Non usare le funzionalità che non ti piacciono.
Beh visto che non hai necessità di creare programmi funzionanti, puoi aprire notepad e scrivere una serie di keyword prese da un linguaggio astratto che ti sei inventato.
Il linguaggio è il modello teorico, compilatore ed interprete sono programmi che implementano il linguaggio.
Perchè non vuoi fare pratica. L'informatica non si studia nozionisticamente.
Perchè? Pascal e C sono in grado di fare le stesse cose. Ciò che dà totale libertà ad un linguaggio sono i puntatori e la relativa aritmetica. Entrambi sono supportati sia da Pascal che da C.
Ed infine si può inserire codice Assembly in un programma Pascal. Direi proprio che si può fare di tutto.
Ci sono altrettanti guru che hanno spiegato perchè invece preferiscono Pascal a C. Un esempio concreto è la codifica delle stringhe.
Mi sa che non stiamo parlando della stessa cosa quando ti riferisci alle librerie. Una libreria è un file esterno ( .o, .so, .dll, .a ) contenente codice macchina in formato oggetto. Questo codice viene linkato al binario principale quando si compila il programma e si crea l'eseguibile. C e C++ necessitano delle informazioni sugli oggetti esterni, informazioni presenti nei file .h, che devono essere inclusi tramite #include. Ma nessuno t'impedisce di non utilizzare nessunissima libreria esterna e scrivere tutto quello che ti serve nel tuo codice.
Il riferimento era all'ambito embedded, dove sfido chiunque a trovare un processore x86. Esistono un paio di board amatoriali e qualche oscuro sistema di controllo della Siemens et similia. Ma niente su larga scala. In passato erano diffuse le cpu 8051 di Intel, ma non erano x86.
No, è un trend che ha preso piede da alcuni anni, tant'è che tutti i linguaggi più diffusi stanno implementando o hanno già implementato elementi di programmazione funzionale.
Non potrebbe mai esserci, perchè il mattone base di tutte le astrazioni è il concetto di funzione.
Avevi citato QuickBasic che non è Qbasic. Qbasic è una versione ridotta e senza compilatore di QuickBasic.
Significa che senza aggiunte esterne hanno tutti le stesse potenzialità.
Non dice niente.
Non mi è chiaro cos'hai fatto allora.
Cioè creare un linguaggio derivato da un altro. Java deriva da C e C++. Nim deriva da Pascal. Go deriva da C, C++ e Java.
Totalmente fuori strada. Stai confondendo il linguaggio come modello di macchina virtuale, con le funzionalità implementate dalla libreria standard e da librerie di terze parti e col compilatore/interprete.
Non necessariamente. Usando le macro LISP si può di fatto implementare un linguaggio ex novo sfruttando il compilatore LISP per compilarlo. Per questo LISP è ancora oggi ritenuto l'apice della piramide.
Occorrono enormi conoscenze. Comunque esiste un libro considerato la bibbia dei compilatori, dal titolo "Compilers: Principles, Techniques & Tools".
Non sono affermazioni un pò presuntuose? In tanti anni ho potuto constatare che avere una mentalità aperta e cercare di capire il perchè i progettisti hanno fatto determinate scelte ( piuttosto che fissarsi e dire che hanno sbagliato perchè a nostro giudizio è fatto male ), alla fine paga e ci arricchisce intellettualmente.
A me LISP sembrava un'assurdità a prima vista. Poi l'ho studiato, usato per un pò e ne ho compreso l'immensa grandezza, ben nascosta dietro una sintassi che sembra ( a prima vista ) folle. Anzi, lì la sintassi proprio non c'è.
Perchè non esiste il concetto di variabile in Assembly e ogni istruzione può accedere ad aree di memoria arbitrarie. Per cui l'assemblatore non ha modo di conoscere in quali aree di memoria si trovano quali dati.
E si può fare anche in altri modi, usando ulteriori rappresentazioni intermedie.
No, in Assembly si possono definire solo gli elementi nelle sezioni dati statiche. Niente è specificabile per quanto riguarda i dati nel heap. Inoltre si può solo specificare la dimensione in bit di una variabile, non il tipo. Per Assembly un boolean e un byte sono la stessa cosa. Per Pascal no.
Astratte?
Il modello di programmazione del x86 è diverso da quello di una cpu ARM. Non esiste il registro AX/EAX/RAX nei processori ARM. Quindi se nel tuo linguaggio usi quei nomi dei registri, quando poi andresti a compilare per ARM, il compilatore che dovrebbe fare? Non può fare le magie.
Ti sfugge il fatto che di una libreria ( nel caso di linking statico ) viene incluso solo il codice effettivamente usato.
Pure in C le librerie sono codice macchina. In Pascal si chiama Unit.
Solo perchè la libreria standard implementa più funzionalità? Ci sono linguaggi che implementano pure la grafica nella loro libreria standard e la includono nel programma forzatamente, senza darti la possibilità di non includerla. Ma ti fanno contento perchè tu non devi mettere #include "pippo.h" e sei convinto che in realtà non stai includendo nessun codice esterno. SBAGLIATO!
E comunque Cobol supporta librerie esterne, e supporta il linking con librerie C-style tramite FFI.
Dappertutto. Intanto sono quei millemila file .dll che trovi sparsi sull'hard disk. Poi ci sono librerie di terze parti disponibili su github e altri siti simili. Per Javascript/Nodejs esiste NPM, per .NET esiste NuGet.
Eh no. CMP sta per Compare cioè confronta. Il confronto in C/C++ è dato da ==
L'if in Assembly è implementato da una delle tante istruzioni di salto condizionato esistenti.
Mai visto una CPU distrutta via software. Ho visto schede grafiche e di rete distrutte, ma mai CPU.
Nè l'uno nè l'altro. La presenza del goto indica proprio che non c'è struttura.
Quel procedure indica una subroutine, per cui è strutturato.
Mica tutti i linguaggi te lo fanno fare. C non lo permette ad esempio.
[CODE]
int main() {
printf("Hello World\n");
return 0;
}
[/CODE]
Come si vede c'è un solo blocco ed è il main.
Modulare proprio no. Per modulare s'intende questo https://en.wikipedia.org/wiki/Modular_programming
Strutturato nemmeno, perchè la struttura implica la separazione dei blocchi, che ha come elemento fondamentale lo scope, cioè la finestra dentro la quale il codice può vedere le variabili. In Assembly tutto è visibile ed accessibile da tutte le parti. Per questo è non strutturato.
Non è la tabulazione che crea la struttura. Il problema è che tu continui a limitarti all'estetica. Non è qualche rientro in più nel listato del sorgente a cambiare cosa le istruzioni possono o non possono fare, nè a stabilire quale modello di programmazione il linguaggio implementa.
