I linguaggi di programmazione dovrebbero essere rigidi o lenti? [chiuso]

Diversi tipi di lingue hanno usi diversi, quindi la risposta a questa domanda dipende molto da cosa la userete.

Ad esempio, Perl è un linguaggio molto lento e lo trovo molto utile per la scrittura di script di correzione rapida o di crimpatura numerica. Per progetti solidi e robusti, utilizzo C #.

Devi ottenere il giusto equilibrio per l'utilizzo del target. Più è rigoroso, più tempo hai bisogno di scrivere il codice, ma ottieni maggiore robustezza, riusabilità e facilità di manutenzione.

Quello che cerco in un linguaggio di programmazione (al contrario di un linguaggio di scripting) è consistenza e strong tipizzazione.

Nei linguaggi di programmazione correnti è possibile omettere il punto e virgola per esempio in determinati posti senza diventare ambigui (l'ultima espressione in un blocco {} è uno). Se un linguaggio di programmazione ti consente di omettere i caratteri in questi casi, un programmatore ora ha un problema in più; oltre alla sintassi generale del linguaggio, ora deve sapere in quali casi è consentito omettere anche parti della sintassi.

Questa conoscenza extra non è un problema per il programmatore che scrive il codice, ma diventa un peso per chiunque debba interpretare il codice esistente in un secondo momento (incluso l'autore originale dopo un po 'di tempo).

Il tuo esempio PHP apre la possibilità di bug sottili in un programma quando la costante key verrebbe aggiunta nello stesso contesto. Il compilatore non ha modo di sapere che non è ciò che si intendeva, quindi il problema diventa evidente solo in fase di esecuzione anziché in fase di compilazione.

Ogni luogo dove c'è un po 'di ambiguità, il compilatore deve avere un modo per indovinare il significato del programmatore. Ogni volta che succede, c'è la possibilità che il programmatore significhi davvero qualcosa di diverso, ma non ha la regola della risoluzione ambigua.

Scrivere codice logicamente corretto è già abbastanza difficile. L'aggiunta di ambiguità sintattiche può sembrare "amichevole" in superficie, ma è un invito aperto a introdurre nuovi, inaspettati, bug difficili da debug nella base di codici. In conclusione, sii il più rigoroso possibile.

Dal tuo esempio, hai detto che i punti e virgola sono opzionali in Python e JavaScript. Per Javascript, almeno, questo non è completamente vero. I punti e virgola sono richiesti in JS come in qualsiasi altra lingua della famiglia C. Ma il parser JavaScript è richiesto dalle specifiche del linguaggio per inserire punti e virgola mancanti in determinate circostanze. Questo è ampiamente considerato come una cosa molto brutta perché tende a sbagliare le tue intenzioni e rovinare il tuo codice.

La risposta a quanto sciolto dovresti fare la tua lingua è uguale alla risposta della domanda detta in un accento texano "Quanto ti senti fortunato, punk?".

Tutti non dovrebbero lavorare così duramente per la coerenza della codifica se le lingue non hanno così tante variazioni. Non ci piace quando gli utenti fanno richieste che aumentano inutilmente la complessità, quindi perché dovrebbe essere richiesto ai nostri linguaggi di sviluppo?

La mia preferenza personale è per la capacità di avere il rigore sufficiente per catturare i miei errori di battitura, ma con il minor numero di sostituzioni possibili. Parlo di questo problema al link .

Detto questo, stai progettando la tua lingua per te. Dovresti renderlo come vuoi tu.

Mi piacciono i miei linguaggi per fare ciò che intendo. Generalmente questo è piuttosto difficile da perdere. Mi piacerebbe anche essere in grado di taggare "strict" su un elemento o blocco per poter eseguire il debug / analizzare quell'area limitata.

In genere tendo a cedere al lato di "Cosa mi renderebbe più facile come programmatore". Ovviamente ciò può significare più di una cosa. In Javascript non c'è quasi nessun tipo di controllo, che funziona benissimo fino a quando non si colpisce un bug strano. D'altra parte in Haskell c'è un gran numero di controlli di tipo che mettono più avanti il lavoro ma nascondono alcune classi di bug.

Per essere onesti, vorrei verificare un sacco di lingue per vedere cosa fanno e cercare di trovare una nicchia che nessuno di loro abbia colpito!

Non penso che ci sia un modo giusto e ovvio per farlo, o almeno se non c'è qualcosa che le persone hanno trovato un consenso su ancora. Quindi, creando lingue con diversi sistemi di tipi che stiamo imparando.

Buona fortuna.

Suggerirei che un buon linguaggio di programmazione dovrebbe avere regole rigide, che le implementazioni dovrebbero applicare in modo coerente, ma le regole dovrebbero essere scritte in modo tale da essere utili. Vorrei inoltre suggerire che si dovrebbe prendere in considerazione la progettazione di una lingua per evitare casi in cui la "distanza di Hamming" tra due programmi sostanzialmente diversi è solo uno. Ovviamente non si può ottenere una cosa del genere con letterali numerici o stringhe (se un programmatore che intendeva 123 invece digiti 1223 o 13, il compilatore non può sapere molto bene cosa intendesse il programma). D'altra parte, se il linguaggio dovesse usare := per l'assegnazione e == per il confronto di uguaglianza, e non usare un solo = per qualsiasi scopo legale, ridurrebbe notevolmente le possibilità sia per gli incarichi accidentali che si supponeva che essere paragoni e paragoni casuali che non dovevano essere assegnati.

Suggerirei che mentre ci sono luoghi in cui è utile per i compilatori inferire le cose, tale inferenza è spesso più preziosa nei casi più semplici e meno valida nei casi più complicati. Ad esempio, consentendo la sostituzione di:

  Dictionary<complicatedType1,complicatedType2> item =
    new Dictionary<complicatedType1, complicatedType2()>;

con

  var item = new Dictionary<complicatedType1, complicatedType2()>;

non richiede alcuna inferenza di tipo complicata, ma rende il codice molto più leggibile (tra l'altro, utilizza la sintassi più dettagliata solo negli scenari in cui è necessario, ad esempio perché il tipo di posizione di archiviazione non corrisponde esattamente al tipo l'espressione che la crea, ti aiuterà a prestare maggiore attenzione ai luoghi che potrebbero averne bisogno).

Una delle maggiori difficoltà nel tentare un'inferenza più sofisticata è che possono sorgere situazioni ambigue; Suggerirei che un buon linguaggio dovrebbe consentire a un programmatore di includere informazioni che il compilatore potrebbe utilizzare per risolvere tali ambiguità (ad esempio considerando alcune tipizzazioni come preferibili ad altre), determinare che non contano (ad esempio perché anche se due possibili i sovraccarichi possono eseguire codice diverso, il programmatore ha indicato che dovrebbero comportarsi in modo identico in quei casi in cui potrebbero essere utilizzati) oppure segnalare quelli (e solo quelli) che non possono essere gestiti in uno dei due modi sopra.

Per me, la leggibilità è molto importante.

Per qualcuno che ha esperienza con la lingua, il significato di un frammento di codice dovrebbe essere chiaro senza dover analizzare profondamente il contesto.

La lingua dovrebbe essere in grado di segnalare gli errori il più spesso possibile. Se ogni sequenza casuale di personaggi crea un programma sintatticamente corretto, non è utile. E se le variabili vengono create automaticamente la prima volta che vengono utilizzate, l'errore di ortografia client come cleint non ti darà un errore di compilazione.

Oltre alla sintassi, il linguaggio dovrebbe avere una semantica chiaramente definita, e forse è anche più difficile che decidere una sintassi decente ...

Buoni esempi:

• In Java, "1" è una stringa, 1 è un int, 1.0 è un doppio e 1L è un lungo. Uno sguardo e sai di cosa si tratta.

• In Java, = è il compito. Assegna il valore per i tipi primitivi e il riferimento per i tipi di riferimento. Non copia mai dati complessi o confronta.

• In Java, la chiamata a un metodo richiede parentesi e in questo modo è chiaramente distinta dalle variabili - quindi, se non c'è una parentesi, non è necessario cercare una definizione di metodo, è solo la lettura dei dati.

Cattivi esempi:

• In Java, un simbolo come client può essere praticamente qualsiasi cosa: un elemento del percorso del pacchetto, un nome di classe o interfaccia, un nome di classe interno, un nome di campo, un nome di metodo, una variabile locale e persino Di Più. Spetta all'utente introdurre o obbedire alle convenzioni di denominazione o meno.

• In Java, il punto . è sovrautilizzato. Può essere separatore all'interno del nome del pacchetto, separatore tra pacchetto e classe, separatore tra classe esterna e interna, connettore tra l'espressione di istanza e metodo da richiamare sull'istanza e molti altri.

• In molte lingue, le parentesi graffe dei blocchi if sono facoltative, portando a brutti errori se qualcuno aggiunge un'altra istruzione al blocco (non proprio esistente).

• Operatori Infix: a volte devo fermarmi a un'espressione numerica e pensare seriamente a cosa significa, passo dopo passo. Siamo tutti abituati a scrivere espressioni matematiche in notazione infix come a * b / c * d + e . La maggior parte delle volte ricordiamo la precedenza della moltiplicazione e della divisione oltre l'addizione e la sottrazione (ma ti sei reso conto che non stiamo dividendo per c*d , ma dividiamo solo per c e quindi moltiplichiamo per d ?). Ma ci sono così tanti operatori addizionali con le proprie regole di precedenza e in alcune lingue che sovraccaricano che è difficile tenere traccia. Forse imporre l'uso delle parentesi è stato un approccio migliore ...

Potresti considerare un'analogia con il linguaggio naturale. In email, sei un grammatico nazista? O stai bene con alcuni errori grammaticali, come gli infiniti divisi, le congiunzioni mancanti o i modificatori errati. La risposta si riduce alle preferenze personali.