Discussione:Linguaggio di programmazione

	Questa voce rientra tra gli argomenti trattati dal progetto tematico sottoindicato. Puoi consultare le discussioni in corso, aprirne una nuova o segnalarne una avviata qui.
Informatica bar di progetto monitoraggio voci

	La voce è stata monitorata per definirne lo stato e aiutarne lo sviluppo. Ha ottenuto una valutazione di livello sufficiente (agosto 2018).
B Lievi problemi relativi all'accuratezza dei contenuti. Informazioni esaustive nella gran parte dei casi, ma alcuni aspetti non sono del tutto approfonditi o altri non sono direttamente attinenti. Il tema non è stabile e potrebbe in breve necessitare di aggiornamenti. (che significa?) B Lievi problemi di scrittura. Qualche inciampo nello stile. Linguaggio non sempre scorrevole. Strutturazione in paragrafi adeguata, ma ancora migliorabile sotto alcuni aspetti. (che significa?) C Seri problemi relativi alla verificabilità della voce. Carenza di fonti attendibili. Alcuni aspetti del tema sono completamente privi di fonti a supporto. Presenza o necessità del template {{cn}}. La delicatezza del tema richiede una speciale attenzione alle fonti. (che significa?) B Lievi problemi relativi alla dotazione di immagini e altri supporti grafici nella voce. Mancano alcuni file o altri sono inadeguati. (che significa?)
Monitoraggio effettuato nell'agosto 2018

	Linguaggio di programmazione è stata una voce in vetrina. Consulta le varie procedure di valutazione per eventuali pareri e suggerimenti.
28 ottobre 2005: la voce è stata sottoposta a valutazione e inserita in vetrina. Vedi votazione 3 giugno 2007: in seguito a una valutazione è stata rimossa dalla vetrina. Vedi votazione

In questo articolo, molto approfondito, manca però un aspetto fondamentale che caratterizza i linguaggi di programmazione, ovvero l'esistenza di una semantica formale ben definita e descrivibile matematicamente; ciò è, in effetti, la principale differenza tra un linguaggio di programmazione e un linguaggio naturale. Qualcuno se la sente di aggiungere qualche riga?

leggo "In realtà Scheme, SML e Lisp non sono Linguaggi funzionali puri, anche se permettono di programmare in stile funzionale." ... ma ovviamente mi cheido... e come li distinguo? Perchè non lo sono? Come sono quelli che lo sono? ecc

Caratteristica fondamentale di TUTTI i linguaggi funzionali è l'esprimibilità (oltre che denotabilità) delle funzioni o lambda-espressioni. I linguaggi imperativi NON hanno tale proprietà: le funzioni sono solo denotabili, ma non esprimibili, ovvero la valutazione di un'espressione non restituisce mai un valore di tipo funzionale né tanto meno di tipo di ordine superiore.

Strano, leggo questa voce nella VETRINA e trovo delle affermazioni piuttosto strane...

Non è vero che tutti i linguaggi abbiano _almeno_ variabili _ed_ istruzioni: sono concetti praticamente presenti assieme solo nei linguaggi imperativi.

Non è corretto porre i linguaggi ad oggetti come sottocategoria dei linguaggi imperativi. Ad esempio, OCaml è un linguaggio funzionale ad oggetti e, tra l'altro, ha una implementazione del modello ad oggetti molto più ricca di molti linguaggi imperativi ad oggetti (si pensi all'ereditarietà multipla).

Non mi sembra affatto una voce "da vetrina": il livello del contenuto è piuttosto elementare. Confrontate pure con l'equivalente di Teknopedia.org...

Se ti aspettavi un trattato di 750 pagine sui linguaggi di programmazione è ovvio che sei rimasto deluso (e continuerai ad essere deluso, temo: un articolo di enciclopedia non è il luogo per un esame teorico approfondito della materia). Questa è una panoramica che intende dare, a chi non ce l'ha, una idea di cos'è e come funziona un linguaggio di programmazione. Quindi è bene che sia elementare, anzi secondo me c'è anche troppa roba. --Kormoran 11:28, 10 ott 2006 (CEST)[rispondi]

Per quanto riguarda variabili e istruzioni, confermo: tutti i linguaggi li possiedono. Se conosci un linguaggio che non ha variabili o che non ha istruzioni sono veramente curioso di conoscerlo, e anzi ti pregherei di dirmi qual'è... --Kormoran 11:28, 10 ott 2006 (CEST)[rispondi]

AHHHH AHHHH... dove sono le variabili nell'Assembler?

I linguaggi logici e quelli funzionali puri NON hanno istruzioni, e questo mi sembra abbastanza evidente...

Falso. Una clausola Prolog è una istruzione a tutti gli effetti. Probabilmente tu non la consideri tale perchè non è imperativa, ma è una istruzione: dopo la sua esecuzione, lo stato del calcolo (=l'insieme globale dei dati del programma) cambia. Stesso discorso per i linguaggi funzionali. --Kormoran 08:51, 7 nov 2006 (CET)[rispondi]

L'esempio che ha scelto, Kormoran, gioca a suo favore perché Prolog non è un linguaggio puramente dichiarativo, quindi non è un controesempio valido. Ogni linguaggio dichiarativo, per definizione, non possiede strutture di controllo di flusso. --SoujaK (msg) 13:29, 9 gen 2014 (CET)[rispondi]

Ecco... bravo... guarda caso per il Prolog si evitano come la peste le semantiche a transizione di stati... e si usano invece quelle basate sui modelli di Herbrand! Dal tuo punto di vista, TUTTO E' ISTRUZIONE perche' valuti i linguaggi SULLA MACCHINA CONCRETA che e' chiamata ad eseguire il codice oggetto: ma questa è una grossa confusione dei livelli di astrazione, non credi? Lo stesso vale per i linguaggi funzionali, che derivano direttamente dal lambda-calcolo: MI DICI DOVE SONO LE ISTRUZIONI NEL LAMBDA-CALCOLO????

E, di grazia, dove si dovrebbe valutare un linguaggio di programmazione se non su una macchina concreta???

Sulla macchina astratta (= supporto runtime per linguaggi compilati, macchina concreta + interprete per linguaggi interpretati). Mi sembra ovvio.

Per quanto riguarda il lambda-calcolo, è prima di tutto un formalismo matematico, e come tale non ha ovviamente istruzioni, ma solo passaggi algebrici. Ma, implementato in un linguaggio di programmazione, il lambda-calcolo viene eseguito tramite istruzioni. Un conto è la matematica e un conto è la programmazione. Se speri di programmare un computer in base a formule matematiche stai fresco... le cose non funzionano così.

Beh, il paradigma di programmazione funzionale è molto vicino a "programmare in base a formule matematiche"...

Per quanto riguarda il Prolog, l'uso dei modelli di Herbrand si è affermato nel tentativo di manipolare la conoscenza astraendo dalle procedure di calcolo. Il problema è che non è possibile astrarre dalle procedure di calcolo durante la programmazione... che riguarda, caso strano, l'implementazione pratica e concreta di dette procedure.

Ti rispondo anche sull'assembler (sei sempre tu, immagino): in Assembler tutte le locazioni di memoria sono delle variabili a disposizione del programmatore: perfino quelle in ROM, se vogliamo, possiamo considerarle variabili statiche (più statiche di così!). Dal tuo punto di vista, probabilmente, non sono variabili perchè non hanno un bel cartellino con su scritto il nome e il tipo. Ma lo sono ugualmente.

Scusami se insisto, ma una locazione di memoria NON è una variabile. Si può dire che una variabile è implementata, sulla macchina concreta, tramite una sequenza di locazioni di memoria (ma anche questa è una banalizzazione che salta a piè pari la gestione delle gerarchie di memoria), ma di certo una variabile è un concetto astratto (= identificatore + valore contenuto) ben distinto da quello di locazione di memoria.

Detto questo, io ho di meglio da fare nella vita che dar da mangiare ai troll, per cui smetto di risponderti... av salùt --Kormoran 03:22, 7 apr 2007 (CEST)[rispondi]

Non è mia intenzione trolleggiare. Mi sembrava di avere fatto osservazioni pertinenti, no? Non mi permetto di toccare il testo della voce, desidero solo cercare di discutere SERENAMENTE su alcuni punti. Guarda che il tuo lavoro fin qui è stato notevole! Sono le pagine buone quelle che meritano di essere discusse, e mi spiace di poterlo fare solo saltuariamente.

E' completamente fuorviante valutare un linguaggio di programmazione su una macchina astratta, e te lo dimostro: è possibile implementare con un computer deterministico tradizionale la simulazione di un computer quantistico (è già stato fatto). Un computer quantistico può risolvere facilmente problemi NP completi (è stato dimostrato). Quindi secondo il tuo ragionamento siamo a cavallo: basta programmare la macchina virtuale quantistica e fregarcene di quella reale sottostante. Peccato che quella che fa veramente i conti sia la macchina REALE, e che quindi il calcolo impiegherà i tempi biblici che impiega normalmente sulle tradizionali macchine deterministiche... la macchina virtuale è essa stessa un programma, e il suo peso si somma a quello del programma scritto dentro di essa. --Kormoran 21:44, 22 apr 2007 (CEST)[rispondi]

Scusami, forse mi sono spiegato in modo poco chiaro. Io non parlavo degli aspetti di complessità computazionale, che sono indipendenti dal linguaggio ma inerenti la classe di problemi. Parlavo invece di quale macchina considerare per descrivere un linguaggio di programmazione.

Quando dico macchina astratta, mi richiamo ad un modello usato nella "Teoria dei Linguaggi Formali": ogni macchina astratta M(i) ha il suo "linguaggio macchina" L(i). Tramite L(i) è possibile scrivere un altro linguaggio L(i+1), il quale definisce una nuova macchina astratta M(i+1), il cui "linguaggio macchina" è proprio L(i+1). Estendendo il procedimento, ciò porta alla definizione di una gerarchia di macchine astratte M(0), ..., M(n), ognuna con il proprio linguaggio L(0), ..., L(n).

Normalmente si ha:

<M(0),L(0)> è il livello della macchina fisica, il cui linguaggio è descritto in termini di porte logiche e flip-flops;

<M(1),L(1)> è la macchina firmware, il cui linguaggio è il linguaggio di microprogrammazione (che è infatti "scritto" in L(0))

<M(2),L(2)> è la macchina assembler, il cui linguaggio è il set di istruzioni della CPU (che sono implementate in L(1))

<M(3),L(3)> è il livello delle primitive del sistema operativo o entry points delle "chiamate di sistema", nel caso di sistemi operativi monolitici, implementate in L(2)

ecc...

Un COMPILATORE, dato un programma P(i) scritto in L(i), genera un programma P(j), scritto in L(j), j<i, semanticamente equivalente a P(i). Il codice oggetto P(j) è poi eseguito sulla macchina astratta M(j) (e, chiaramente, tale esecuzione niente altro è che una INTERPRETAZIONE di P(j) tramite i meccanismi che implementano L(j) sulle macchine astratte sottostanti!).

NB: solitamente il "codice oggetto" prodotto dal compilatore è scritto in L(j), j maggiore di 1 (e raramente j=2, anche dopo il linking; più spesso, ma non sempre, j=3).

Proprio per questo motivo la specifica semantica del linguaggio L(i) e, quindi, le sue caratteristiche NON sono ben descrivibili sulla macchina fisica, ma sulla MACCHINA ASTRATTA M(j), ovvero su quella ove viene eseguito il codice oggetto (nel caso di compilazione) o su quella su cui è eseguito l'interprete (nel caso di interpretazione).

Purtroppo il taglio di questa mia precisazione mi sembra troppo teorico e poco adatto ad essere messo nella wiki, a meno che non si voglia stravolgere l'attuale pagina, e non credo proprio sia giusto farlo: il taglio che hai dato tu alla voce mi sembra buono e divulgativo. Ma spero che tu tenga in considerazione questo mio appunto, perché dire che "tutti i linguaggi hanno variabili" significa davvero voler analizzare i linguaggi sulla macchina fisica, ed è fuorviante! Chi impara a programmare con linguaggi funzionali puri sa benissimo che non usa variabili ma identificatori, e il concetto è davvero diverso: essi non sono legati a valori mutabili nel corso di esecuzione del programma! Capisco che il concetto è poco digeribile per chi non si occupa di programmazione funzionale, ma ti assicuro che è sbagliato dire "bene, questi linguaggi non definiscono alcun concetto di variabile; ma sono comunque poi compilati e il codice oggetto usa le variabili, quindi anche questi linguaggi hanno le variabili".

Saluti cordiali.

Questo ragionamento non regge, Kormoran. Una macchina astratta quantistica è sensata a prescindere dall'esistenza di macchine concrete quantistica: è un modello oggi utilizzato per la teoria dei linguaggi e della complessità. La differenza prestazionale tra tale macchina astratta e una macchina concreta classica (quelle odierne, insomma) ovviamente sussistono, ed altrettanto ovviamente si manifesteranno in fase di compilazione o interpretazione dalla prima alla seconda.

Il che non è affatto strano e la discrepanza è nota a chiunque lavori, in ambito teorico, appunto, con semantiche o modelli formali che siano legati a macchine astratte quantistiche.

Un simile e celebre caso di discrepanza fra teoria che precede la pratica avvenne per il paradigma attuale: la classe delle funzioni matematiche effettivamente computabili sono state caratterizzate diversi anni prima che il primo calcolatore Turing-completo fosse realizzato.

--SoujaK (msg) 13:29, 9 gen 2014 (CET)[rispondi]

La tua precisazione è infatti decisamente teorica, ma interessante. Potrebbe valere la pena creare un articolo apposta per esporla. Il formalismo a macchine astratte mi pare utile per studiare alcune proprietà dei linguaggi, tipo se sia o meno possibile ottenere una vera equivalenza semantica date due coppie {M(i), L(i)} e {M(k), L(k)}, magari appartenenti a due diverse gerarchie di macchine astratte (problema generalizzato del porting?). Non conosco i linguaggi funzionali, quindi non posso dire nulla di specifico, ma da programmatore sarei parecchio sorpreso se nei linguaggi funzionali tutti gli identificatori in tutti i possibili programmi "legali" mantenessero sempre lo stesso significato semantico iniziale (non parliamo di valore, che probabilmente è un concetto troppo specifico). Magari in linea di principio sarebbe pure possibile scrivere un linguaggio funzionale così, ma sarebbe anche utile?

Il difetto maggiore di questo formalismo, ai fini di questo articolo, è che come tu stesso hai rilevato è troppo lontano da quella che è la sostanza pratica dei linguaggi di programmazione. Dal tuo punto di vista è ovvio che i file .OBJ sono una coppia {M(n), L(n)} intermedia che sta fra il linguaggio macchina e il codice sorgente, ma un tizio che si sta scrivendo un "hello world" sul PC (e parecchi altri più esperti di lui, me compreso fino a poco fa) non la pensa così... anzi per lui quel passo intermedio nemmeno esiste, a livello di linguaggio di programmazione. Vedo ora che esiste un articolo Teoria dei linguaggi formali, che per giunta è pure un misero stub: lì questo tipo di argomenti sarebbero perfetti! :-) --Kormoran 19:32, 25 apr 2007 (CEST)[rispondi]

Riapro la questione che è stata dimenticata dopo che l'anonimo e Kormoran hanno convenuto fosse troppo teorica. Non sono d'accordo ed ho risposto ai due punti principali affrontati nella discussione precedente. Mi piacerebbe che rimuovessimo l'affermazione, che reputo falsa, sulla necessità della presenza di variabili ed istruzioni in ogni linguaggio di programmazione sia rimossa. Vorrei pure che correggessimo ed estendessimo tutto l'incipit del secondo paragrafo, per non limitare la voce a considerare i linguaggi procedurali/imperativi. --SoujaK (msg) 13:29, 9 gen 2014 (CET)[rispondi]

da quando il php sarebbe un linguaggio di SCRIPTING?!?!?!?!?!!

oddio... ve lo dico in veste di professore universitario...

Se ce lo dicevi in pigiama e pantofole era esattamente lo stesso. Comunque confermo anche questo: PHP, Javascript, JScript, VBscript sono tutti linguaggi di scripting. Lo sono perchè: 1) Gli eseguibili di questi linguaggi sono gli stessi file sorgente, non precompilati o preprocessati in alcun modo prima dell'esecuzione; 2) Tutti vengono interpretati dal server web, o direttamente o tramite un modulo apposito; 3) Sono pensati e realizzati specificamente ed esclusivamente per lo scripting di pagine web e non esistono altre applicazioni di tali linguaggi al di fuori di questo ambito. Sono curioso: secondo lei, signor professore, perchè il PHP non sarebbe un linguaggio di scripting, e che cosa sarebbe in realtà? --Kormoran 21:11, 13 ott 2006 (CEST)[rispondi]

La ragione sta nel mezzo... anzi, 2/3 per il (sedicente) professore:

1) significa solo che PHP è un linguaggio interpretato.

2) significa solo che un server web può generare pagine interpretando direttamente (o tramite un modulo di interpretazione) un sorgente PHP.

3) è forse l'unica, vera, motivazione valida: in PHP posso scrivere qualsiasi applicazione, ma è nato per il Web. Intendiamo, allora, "scripting"=="ad hoc"? Può essere.

I punti 1, 2 e 3 sono nè più nè meno la definizione di linguaggio di scripting. Se qualcosa nell'acqua ha la forma di un'anatra, si muove come un'anatra e starnazza come un'anatra ci sono ottime probabilità che sia un'anatra. Volendo argomentare ancora, esistono programmi diversi da un server web che usano PHP? No. Esistono compilatori che prendano un codice sorgente PHP e lo traducano in un file eseguibile per una specifica piattaforma? No, e per un ottimo motivo: PHP non ha primitive che gli consentano di interfacciarsi a un sistema operativo. E' un linguaggio pensato e realizzato per girare in un contesto preciso (cioè è un linguaggio "ad hoc", come giustamente osservato). Potrebbe essere diversamente? Certo: le primitive si potrebbero creare, il compilatore e le librerie di sistema si potrebbero scrivere.
Ma il linguaggio sarebbe qualcosa di diverso da quello che è ora, perchè dovrebbe affrontare problemi che ne richiederebbero una revisione (multitasking, multithreading, socket, gestione della memoria, accesso al file system: tutte cose che nel contesto attuale sono "invisibili", a carico dell'ambiente di esecuzione), e inoltre dovrebbe confrontarsi con i livelli di efficienza offerti dal C e dagli altri linguaggi di programmazione di sistema, perdendo in parte il suo vantaggio. Quindi, IMHO e per come stanno le cose ora, PHP e compagni sono dei linguaggi di scripting. --Kormoran 08:46, 7 nov 2006 (CET)[rispondi]

Concordo con Kormoran, anche se un dubbio ce l'ho: il problema sembra essere la parola scripting. Originariamente individuava quei linguaggi usati per scrivere previ programmi (scripts, appunto) usati specialmente in ambito sistemistico per automatizzare compiti "pallosi"; poi ha incluso anche la generazione dei CGI per il web, e quindi anche il PHP, dato che "sempre per il web è", potrebbe stare in questa categoria. Ma è anche vero che oggi i programmi in PHP non sono più dei semplici script, almeno nel senso della "dimensione" (...non che gli script CGI fossero brevi...).

Propongo pertanto di precisare che storicamente i linguaggi di scripting avevano una "area d'uso" ristretta, oggi si è ampliata, i linguaggi stessi (PHP) sono più complessi, ecc... oppure è meglio a questo punto distinguere direttamente tra linguaggi all-purposes e linguaggi specific-purpose, inserendo in quest'ultimi i linguaggi per web (PHP) e i linguaggi di scripting di sistema? Che ne pensi, Kormoran?

Saluti cordiali

ps: sono quello della discussione sopra "in generale", un giorno (tempo e voglia!) mi registrerò, scusate...

Per favore, togliete dalla lista dei linguaggi ad oggetti il Visual Basic.. Non implementa tutti i meccanismi tipici della programmazione ad oggetti (incapsulamento,ereditarietà, polimorfismo), quindi si può ritenere che non appartenga a questa categoria. Grazie

E' vero, il VB non ha tutte le caratteristice "classiche" di un linguaggio ad oggetti. Ma ha gli oggetti, proprio come definiti dalla teoria: un'entità software dotata di identità, comportamento e stato. Quindi VB tra i linguaggi ad oggetti ben ci sta.

Saluti cordiali

Ci sono alcune inesattezze nella classificazione e manca la descrizione dei linguaggi funzionali. Inoltre: nella voce Programmazione_funzionale, correttamente si legge: I programmi puramente funzionali (...) non richiedono variabili e non hanno effetti collaterali e sono di conseguenza automaticamente thread-safe., per cui alcune affermazioni nella pagina debbono essere riviste.

--193.109.204.41 10:46, 17 apr 2007 (CEST)[rispondi]

Non è corretto sostenere che "La compilazione è la norma per tutti i linguaggi di programmazione di uso generale; ma esistono le eccezioni, come il linguaggio Java, che applica un ibrido fra le due soluzioni". In realtà, la soluzione ibrida è la più comune, visto che la maggior parte dei compilatori non produce codice nativo, ma un codice intermedio interpretato dal run-time support. Questa non è certo una novità (è la soluzione adottata fin dai tempi del Lisp...)

Ho riformulato il paragrafo cercando di chiarire e dettagliare meglio, anche se non concordo che la soluzione ibrida è la più comune, affermazione vera in alcuni contesti (e probabilmente sarà sempre più vera in futuro) ma che non condivido in assoluto (C++, ad esempio). Ciao, Salvatore Ingala (conversami) 11:45, 18 apr 2007 (CEST)[rispondi]

I compilatori (ma NON tutti) compilano il codice in due passi: da codice sorgente a codice oggetto e da codice oggetto, tramite il linker, a codice macchina. Nessun programma compilato è distribuito in codice oggetto: solo sotto forma di file eseguibile composto da codice macchina e dati. Le uniche a essere distribuite come codice oggetto sono, per forza di cose, le librerie, che però non sono programmi completi. Dire che "la soluzione ibrida è la più comune" è semplicemente falso. Correggo l'articolo. --Kormoran 21:29, 22 apr 2007 (CEST)[rispondi]

Beh, dal punto di vista teorico (le macchine astratte, v. mia nota sopra...) non c'è praticamente mai la "compilazione pura". Ma nel senso comune, si intende "compilato" un linguaggio il cui codice oggetto è costituito da codice macchina, che eventualmente incorpora delle chiamate a system calls: quindi secondo me ha ragione Kormoran, essa è la soluzione oggi più comune.

Saluti cordiali

Secondo me, non è il caso di citare nell'introduzione il T. di Bohm-Jacopini. In effetti, tale T. riguarda la formulazione di algoritmi prendendo in considerazione prettamente il paradigma imperativo, per cui non ha senso citarlo in una introduzione generale ai linguaggi di programmazione: altrimenti potrebbe sembrare che *tutti* i linguaggi debbano possedere un costrutto sintattico, p.es., per la "sequenza", e chiaramente ciò non è necessariamente valido né per linguaggi logici, né per linguaggi funzionali. --81.121.77.2 21:01, 22 apr 2007 (CEST)[rispondi]

Concordo, va rimosso poiché si riferisce a linguaggi sequenziali.

Saluti cordiali

Noto che questa pagina inizia con alcune (lunghe e piuttosto polemiche) discussioni che sono sfociate nel "trolleggiare" e non hanno avuto un effetto positivo sulla voce. Poiché esse sono relative a questioni riguardanti linguaggi funzionali (a me non troppo noti), sarebbe opportuno che l'estensore di tali discussioni formulasse una proposta di miglioria della voce! C'è qualche esperto di tali linguaggi che si fa avanti? saluti a tutti i wikipediani --81.121.77.2 21:06, 22 apr 2007 (CEST)[rispondi]

Sono state aggiunte tre immagini alla voce, che prima ne era priva. Avrei alcune perplessità:

• Non si poteva scegliere come prima immagine quella di un linguaggio poco poco meno commerciale (e meno obsoleto)? Qualsiasi cosa ma non il Basic vi prego... Questa pagina non si chiama "Storia dei Linguaggi di programmazione", per cui non siamo obbligati a mettere in bella vista (come fra i più importanti) un bel sorgente di codice Basic, la cui versione più conosciuta è quella appartenente ad una multinazionale chiusa come lo è la Microsoft... Possiamo anche inserire qualche linguaggio che oggi è utilizzato, o magari qualsiasi linguaggio che appartenga alla comunità software (Java, Perl, Python, Ruby, qualcosa di Open insomma!...). --Boz (msg)
• Seconda e terza immagine: non mi sembrano troppo rilevanti per il testo.
• Ma il vero problema è la prima immagine: non sono affatto convinto che possa essere considerata di pubblico dominio come detto su Commons. Anche le costole dei libri IMHO hanno un design grafico che dovrebbe essere tutelato da diritto d'autore, al pari della copertina. Se qualcuno più competente di me non mi smentisce temo che dovremo toglierla.

--Francesco (All your base are belong to us) 00:23, 14 mag 2007 (CEST)[rispondi]

• beh purtroppo che immagini rilevanti si possono trovare? ad esempio uno screen di MS visual studio, uno dei compilatori oggi più usati? per quanto riguarda la copertina, non mi pare che la superficie mostrata sia tale da violare un copyright; comunque l'immagine non l'ho caricata io, ma era già presente su commons. --Xander what do you want? 07:38, 14 mag 2007 (CEST)[rispondi]

Sì, hai ragione, infatti la seconda e la terza immagine non sono un vero problema. Rimango sempre un po' perplesso sulla prima: ho visto che l'immagine è su Commons, ma anche loro non sono infallibili. Chiedo allo sportello informazioni. --Francesco (All your base are belong to us) 08:46, 14 mag 2007 (CEST)[rispondi]

Dubito che la fotografia di una libreria si possa dire costituisca violazione di copyright. Secondo quest'ottica anche la fotografia di una città con delle insegne (tipo questa o questa) sarebbe violazione poiché contiene dei loghi commerciali registrati, ed anche la fotografia di una o più automobili (tipo questa) poiché contiene i loghi della casa produttrice. In due parole: va bene l'attenzione al copyright ma non esageriamo ;-). --Lucas 09:26, 14 mag 2007 (CEST)[rispondi]

Da quando HTML è diventato un linguaggio di programmazione? --Furriadroxiu 22:08, 14 mag 2007 (CEST)[rispondi]

perchè non dovrebbe esserlo? da definizione:

In informatica, un linguaggio di programmazione è un linguaggio formale dotato di una sintassi ben definita per scrivere programmi per calcolatori, 
in una   forma più vicina al linguaggio umano scritto: l'alternativa sarebbe scrivere direttamente le istruzioni nel codice macchina del particolare 
processore, un compito improponibile per programmi meno che semplicissimi.

o no? è un linguaggio di markup, ma pur sempre un linguaggio ;) --Xander what do you want? 22:15, 14 mag 2007 (CEST)[rispondi]

sintassi ben definita per scrivere programmi per calcolatori. Se un documento HTML è un programma per calcolatori allora HTML è un linguaggio di programmazione ma io lo vedo più come un linguaggio di formattazione. IMHO sarebbe concettualmente più corretto discernere i linguaggi di programmazione come sottoinsieme dei linguaggi informatici (comprendenti anche il linguaggi di markup). Non è mia intenzione imbarcarmi in inutili polemiche, perciò chiudo qui il mio intervento, volevo solo esprimere una mia perplessità. --Furriadroxiu 22:32, 14 mag 2007 (CEST)[rispondi]

L'HTML (Hyper Text MARK-UP Language!) è notoriamente un linguaggio di markup e non di programmazione, definisce il contenuto e l'aspetto della pagina, non una serie di istruzioni che il processore dovrà eseguire. E' ovvio che per essere visualizzato un processore dovrà ben eseguire qualche comando, ma non è sicuramente l'HTML a definirlo. Poi, IMHO, se l'HTML forre un linguaggio di programmazione allora lo sarebbero anche quelli utilizzati da programmi come Micro$oft Word o (meglio) Open Office nei .doc o nei .odf :-). QT-1 16:46, 6 lug 2007 (CEST)[rispondi]

Concordo, l'HTML non è un linguagio di programmazione --Kormoran 12:13, 7 lug 2007 (CEST)[rispondi]

Il riferimento è un errore grossolano. Il teorema afferma (qui banalizzo, semza entrare nei dettagli di computabilità) che ogni algoritmo può essere descritto con un linguaggio con strutture di sequenza, ciclo, alternativa; ma non significa affatto che tutti i linguaggi debbano possedere tali costrutti.

Confermo. E lo possiamo vedere anche qui Moongateclimber 12:16, 25 mag 2007 (CEST)[rispondi]

Mi chiedevo se il linguaggio di scripting del mIRC possa essere incluso in questa lista, avendo una sintassi propria e ben definita, ma non utilizzabile per scrivere programmi veri e propri, si possono scrivere delle estensioni per il mIRC. Attendo quindi una vostra risposta. — Questo commento senza la firma utente è stato inserito da Alchimista di Cristallo (discussioni · contributi) 19:09, 21 lug 2007 (CEST) (CEST).[rispondi]

Si può mettere nella sezione Linguaggi di scripting. Hellis 19:07, 21 lug 2007 (CEST)[rispondi]

Non è vero che i linguaggi interpretati producono eseguibili di dimensioni maggiori. Anzi semmai è il contrario! - Anonimo Codardo

i linguaggi interpretati, di norma, non producono codice eseguibile, ma bytecode, come quello della JVM o il .pyc del python. Per "tradurlo" in codice eseguibile, dunque, serve un programma esterno (Py2exe per python, ad esempio). Tradurlo è tra virgolette perché in realtà un tool come py2exe non genera file tradotti in linguaggio macchina, come fa il compilatore C, o ASM, semplicemente prende l'interprete del linguaggio in questione, lo script, e li mette assieme in un unico file, ergo l'eseguibile risulta ovviamente di dimensioni maggiori (un programma python da pochi kb può raggiungere i 5 MB) - Alchimista di Cristallo (msg) 15:19, 2 giu 2008 (CEST)[rispondi]

Quanto detto qui sopra non è vero in generale. A provare ciò basta già il primo esempio storico, il Pascal, fin dalle origini compilato da sorgente a p-code (dal "Pascal Compiler") e da questo con due possibilità: tradurre il p-code in assembler o in liguaggio oggetto (medinate il "Pascal P_translator") e da qui poi in eseguibile, o interpretare il p-code (mediante il "Pascal P_interpreter"). Per inciso l'interprete originale del p-code è stato scritto da Wirth e dalla Jensen.

é fondamentalmente sbagliato a conti fatti parlare di "linguggi compilati" e "linguaggi interpretati" in quanto per ogni linguaggio, anche Java, é teoricamente possibile creare un compilatore e compilarlo. Viceversa, per ogni linguaggio é possibile creare un interprete ed usarlo per eseguire un programma. Il linguaggi sono formalismi, non implementazioni. Altrimenti stiamo parlando di ragioni storiche o di specifici package di sviluppo. --un programmatore a caso

... vi e' una notevole contraddizione con http://it.wikipedia.org/wiki/Plankalk%C3%BCl.... Quale delle due e' corretta?

L'affermazione che il concetto di oggetto software introdotto dal Simula (nel 1967) fosse solo abbozzato è priva di fondamento. Il Simula (67)permette di istanziare le classi, quindi di creare oggetti (anche se in Simula non hanno questo specifico nome) "esattamente" come il Java.

Manca un paragrafo sulla distinzione basica tra linguaggi di programmazione ad alto e basso livello. Manca anche come le istruzioni del linguaggio vanno ad impattare sull'esecuzione da parte dell'hardware cioè sull'instruction set. Posso inserire il tutto...? --151.29.31.215 (msg) 12:58, 19 ott 2012 (CEST)[rispondi]

Ho iniziato a programmare nel 1991 ed ora sono un programmatore senior ed architetto software, e in piú di un ventennio passato tra scuole, Politecnico e mondo del lavoro a vari livelli non ho MAI sentito chiamare il linkaggio di un programma "collegamento". Sará un inglesismo ma allora il 90% delle parole italiane sono "latinismi" o "grecismi". — Questo commento senza la firma utente è stato inserito da 88.98.68.172 (discussioni · contributi) 16:49, 5 giu 2015 (CEST).[rispondi]

"Collegamento" non sarà certamente così diffuso in Italia come è invece linking, ma da una rapida ricerca Deitel lo usa sia qui che qui. Ma anche MSDN qui. D'altronde se è già più comune dire libreria a "collegamento dinamico" per "dynamic linking" allora il solo "linking" è "collegamento". --Rotpunkt (msg) 17:17, 5 giu 2015 (CEST)[rispondi]

..."linker" come diventerebbe, nel caso? --Valerio Bozzolan (msg) 17:23, 5 giu 2015 (CEST)[rispondi]

@Valerio Bozzolan, sarebbe "collegatore", questo credo però che sia veramente quasi inutilizzato. Sempre il Deitel di prima, sempre a pagina 12, usa sì "collegamento" ma poi scrive "Linker" vedi: qui. Qui invece: http://a2.pluto.it/a2/programmazione.p4.pdf (cerca "collegatore" nel pdf) lo si usa. Direi di lasciare comunque "linker". --Rotpunkt (msg) 17:35, 5 giu 2015 (CEST)[rispondi]

In ogni caso mi pare di poter dire che l'italianizzazione "collegamento" è una pratica usata da una fin troppo ristretta frazione di qualsiasi opera a riguardo per poterla appoggiare. Inoltre con ciò si rischerebbe appunto che qualcuno pensi alla parola "collegatore"... --Valerio Bozzolan (msg) 17:44, 5 giu 2015 (CEST)[rispondi]

Il Linguaggio ALGOL nacque nel 1958 e già era dotato di blocchi BEGIN END ed in grado di annidare strutture di controllo come sequenza, selezione, iterazione. Nel 1964 uscì il PL/I IBM è per unire le qualità del Cobol e quelle del Fortran ed anche questo delimitava i blocchi con BEGIN/END ereditati da Algol e successivamente implementati nel Pascal. --Gio90459 (msg) 21:01, 8 lug 2022 (CEST)[rispondi]