Flessibilità e incoerenza, sovrapposizione di non sicurezza?

Question

Flessibilità e incoerenza, sovrapposizione di non sicurezza?

#1 da (1 voti)

1

Ultimamente stavo facendo delle ricerche su diversi linguaggi di programmazione. Mi interessava in particolare imparare le caratteristiche uniche dei linguaggi di programmazione popolari e le situazioni in cui queste risorse brillano. Credo che questo possa aiutarmi a decidere quale linguaggio utilizzare a seconda del problema da risolvere.

Ho scoperto che molte lingue che offrono un alto livello di flessibilità ("può adattarsi a requisiti nuovi, differenti o mutevoli") sono anche incoerenti, per esempio in JavaScript (solo un esempio, senza offesa a js people), gli argomenti di una funzione possono essere manipolati o nominandoli nella dichiarazione della funzione (approccio classico):

function max(x,y)

O utilizzando la variabile arguments :

function max() {
    if (arguments[0] < arguments[1])
        return arguments[1];
    else
        return arguments[0];
}

c = max(1,2);

La variabile arguments è utile per molte situazioni come l'overloading delle funzioni, tuttavia, sconfigge lo scopo della funzione prototyping (che è quella di fornire informazioni sulla funzione), e ho visto molti esempi JavaScript in cui la variabile argomento viene utilizzata nonostante non ce n'è bisogno, il che rende il codice più difficile da comprendere e da correggere.

So che questo dipende molto dagli utenti della lingua, ma di solito il codice scritto in una lingua che offre alta flessibilità tende ad essere pericoloso, difficile da capire, ottimizzare e eseguire il debug.

La flessibilità e l'incoerenza si sovrappongono? Come fanno i designer di lingue a fare la scelta?

Modifica: non sto criticando un particolare linguaggio qui, mi concentro piuttosto sulla relazione tra flessibilità, sicurezza, coerenza dei linguaggi di programmazione.

design programming-languages

posta Pindexis 17.03.2013 - 05:19

fonte

1 risposta

Leggi altre domande sui tag design programming-languages

In che modo lo sviluppo di app per Windows Phone 8 è diverso da Windows Phone 7.x? Vs. a disponibilità elevata Ridimensionamento del cloud

score 1 · Answer 1

Non penso che la flessibilità e l'incoerenza si sovrappongano o abbiano una relazione naturale 1: 1. Di più su questo in un po '.

Come per la tua altra domanda, suppongo che i progettisti di linguaggi facciano queste scelte nello stesso modo in cui fanno qualsiasi altra scelta; confrontando i pro e i contro e decidendo quale è il più adatto per la lingua e il problema. L'incoerenza è una truffa, ma ci sono dei professionisti che la superano.

Ad esempio, nella tua domanda specifica sulla parola chiave argomenti, è molto utile in un contesto funzionale in cui si applicano argomenti alle chiamate di funzione. In effetti, la documentazione per l'applicazione indica tale. Altrimenti dovresti in particolare scorrere gli argomenti che potresti non avere nemmeno nominati. Questo può essere un vantaggio significativo.

Si consideri:

function f() { console.log(arguments); }
f(); // [ ]
f(1, 2, 3); // [1, 2, 3]

In JavaScript, il legame tra gli argomenti denominati avviene automaticamente in base alla posizione, ma è possibile fornire qualsiasi numero di argomenti a qualsiasi funzione. A causa di questo comportamento, non sembra incoerente fornire una funzionalità per interagire con gli argomenti arbitrari. Inoltre, è possibile visualizzare l'argomento named binding come caso speciale; zucchero sintattico su var arg1 = arguments[0]; ecc.

Per quanto riguarda la flessibilità e l'incoerenza, penso che siano principalmente due misurazioni separate delle modifiche. Non ho alcun riferimento alle discussioni sulle due forze, tuttavia, in C #, ad esempio, potresti aumentare la flessibilità dei vincoli generici fornendo meccanismi per limitare i generici ai delegati o alle enumerazioni. Questo è completamente coerente con la lingua esistente.

Si dà il caso che spesso un prezzo da pagare per la flessibilità sia incoerente, ad esempio, C ++ 11 ha aggiunto dichiarazioni di tipo "return return" semplicemente per supportare lambdas e un paio di altre caratteristiche di inferenza del tipo in fase di compilazione. Questo era completamente incoerente, ma ha permesso una nuova dimensione di flessibilità che è stata ritenuta abbastanza importante da consentire l'incoerenza.