I confronti linguistici sono significativi? [chiuso]

Mi piace paragonare i linguaggi di programmazione!

Confronto java con una brezza calda con un tocco di pioggia

Confronto C # con la bella giornata primaverile con le nuvole bianche e soffici per mantenere il cielo felice

Confronto C con una mazza in una stanza piena di vetro

confronta C ++ con un sacco di mazze in un mondo di cristallo

Confronto VB con un vecchio giocattolo a molla che affonda in una vasca da bagno

Confronto PL / 1 con un'incudine arrugginita, imbullonata al suolo

come li confronti?

Penso che Stroustrup sia completamente corretto. Adeguatamente, confrontare due lingue per i loro meriti tecnici richiede sufficiente familiarità con entrambi per scrivere codice idiomatico e utilizzare gli stessi schemi di progettazione normalmente usati dai programmatori che sono molto produttivi in entrambe le lingue. Qualcuno che non ha quel livello di conoscenza di entrambe le lingue può vedere cose che non sono esplicitamente fornite dal linguaggio con cui non ha familiarità, e presuppongono che ci sarebbero problemi di conseguenza.

Ad esempio, qualcuno che non usa Python su base regolare può presumere che gli utenti di Python abbiano regolarmente problemi a causa del rientro. Oppure qualcuno che non ha familiarità con Common Lisp può guardare alla mancanza di librerie levigate, ma non sa che l'FFI è abbastanza potente da scrivere wrapper per le librerie C con uno sforzo nominale. Qualcuno che non ha familiarità con Ruby può vedere la mancanza di tipizzazione statica e assumere errori di tipo sarebbe un grosso problema. Infine, qualcuno che non ha familiarità con Haskell potrebbe vedere la mancanza di incarichi e assumere che non possa gestire lo stato.

Ora tutto ciò presuppone che le lingue vengano effettivamente confrontate solo in base ai loro meriti tecnici.

Una lingua è uno strumento. Detto questo, ho già visto strumenti davvero scadenti. Nessuno vuole lavorare con un martello la cui testa è soggetta a volare via e colpire un altro falegname nello stomaco. Allo stesso modo, se hai notato che il martello del tuo collega era in quella forma, probabilmente non te ne vergognavi quando lo stavano usando.

È anche importante capire veramente quale strumento sia. Non è possibile utilizzare un cacciavite e un martello in modo intercambiabile (anche se alcuni cercano disperatamente). Al diavolo non puoi nemmeno usare tutti i martelli in modo intercambiabile; hai bisogno di una slitta per alcune cose, una mazza per gli altri e una virata per altri ancora. Se usi lo strumento inappropriato, nel migliore dei casi, farai un lavoro peggiore, nel peggiore ti ferirai o un collega.

In altre parole, il confronto linguistico è utile in quanto può prevenire incidenti sul lavoro. Prendendo il sopra di metafora; è difficile sapere senza paragonare se una determinata lingua è una mazza da slittino, un cacciavite, un dremel o una sega da tavolo, perché (a differenza degli strumenti fisici) non si può davvero dire semplicemente guardando. Devi pensare alle funzionalità che offre, vederle in azione (provando a leggere pezzi significativi di una grande base di codice scritta in esso), e idealmente, prova anche tu da solo. Attenzione a non commettere l'errore di scrivere solo Cobol in Python (per esempio). È necessario utilizzare la nuova lingua in modo idiomatico, il che significa impararlo bene. Questo è probabilmente il motivo per cui Bjarne dice che la maggior parte delle persone non si impegna abbastanza per un utile confronto.

Il tipo di confronto che inizia con "Mi piace Blub" e continua con "Beh, mi piace Blub ++" è completamente inutile. Se si finisce per selezionare una lingua, tutto ciò che realmente ti dice è chi è più persuasivo in un dato gruppo e / o quale società linguistica ha il budget pubblicitario più grande. Se analizzi ciò che una lingua può fare, quali compiti sono adatti e dove i suoi difetti sono senza ricorrere a argomenti irragionevoli o pregiudizi personali, allora può essere davvero utile.

Questo, tranne in alcune eccezioni rare (e - raro - come in "accade una o due volte nella vita di un sistema solare") di solito porta a guerre di lingua, in una variante più o meno strong e molto raramente lascia alcune conclusioni pratiche e utili.

Le lingue sono strumenti, non religioni. Non paragoni un martello con un cacciavite, ma usi quello che si adatta al tuo compito & modo di pensare / educazione / livello di astrazione necessario di più. Inoltre, dal momento che quello che fa il confronto è distorto dal fatto che conosce almeno uno dei due, o almeno preferisce uno dei due, è difficile trovare un criterio veramente oggettivo per il confronto (esistono eccezioni). / p>     

Se consideriamo le lingue come prodotti e tutti gli sviluppatori come il mercato, possiamo trarre alcune conclusioni interessanti:

1. I prodotti non sempre competono. Ad esempio, Haskell non risolve gli stessi problemi di Java che non risolvono gli stessi problemi di Assembly che non risolve gli stessi problemi di Prolog. Uno sviluppatore, in diverse situazioni, può utilizzare tutte queste lingue. Il confronto implica la competizione per la superiorità. Pertanto, non ha alcun senso confrontare le lingue che non competono.
2. La visibilità sul mercato significa che il prodotto ha già dimostrato di essere utile a qualcuno. Cioè, puoi confrontare Ruby e Python tutto quello che vuoi - le persone lo fanno sempre. In qualche modo, questo non sembra cambiare la mente di nessuno (o se lo fa, lo stesso numero di persone cambia idea nell'altra direzione). Nei modi che contano, Ruby e Python sono equivalenti. È come due gigantesche aziende di soda che fanno confronti "scientifici" dei loro prodotti. Uno studio mostra che la Coca-cola è superiore mentre l'altra mostra che la Pepsi è superiore. Anche se i dati sono affidabili, non significa nulla. Sappiamo tutti che sono bibite perfettamente buone (linguaggi di programmazione) e che si appella più o meno ai miei gusti personali.
3. I confronti linguistici sono una forma di marketing geek. Se ci fosse un posto perfettamente obiettivo per iniziare un confronto, potrebbero essere utili. Certo che non c'è. Qualcuno che si preoccupa di fare un confronto sta cercando di confermare un pregiudizio esistente. Stanno provando a vendere una lingua. Di nuovo, se C ++ è così brutto o VB è così brutto o Erlang è così cattivo, perché le persone li usano? Puoi fare tutte le richieste che vuoi, ma ciò non impedisce loro di essere utili. La nostra ipotesi è che le persone siano troppo stupide per vedere la verità di fronte a loro, ma è probabile che il "mercato" sia più complesso di quanto pensiamo. I confronti ci dicono di più sulla persona che fa il confronto di quanto non facciano sui prodotti da confrontare.

Stroustrup è completamente corretto.

La maggior parte dei "confronti linguistici" sono eseguiti con un risultato specifico in mente, che è quello di "mostrare" che uno è "superiore" all'altro.

Spesso questo significa scrivere una parte di codice in entrambe le lingue e misurare le prestazioni dell'eseguibile generato, scrivere una lingua ottimizzata e l'altra deliberatamente per prestazioni scadenti. Questo è il modo in cui il mito "Java è lento" viene perpetuato. I "test" per "dimostrarlo" vengono scritti deliberatamente per non misurare le prestazioni dell'esecuzione del codice Java ma il tempo di avvio della JVM. Prendete ad esempio una semplice operazione matematica e passatela 100 volte, fatelo in Java e C ++, compilate la versione C ++ con l'ottimizzazione attivata, la versione Java senza i flag di ottimizzazione, quindi eseguite entrambe le versioni eseguibili. La classe Java verrà eseguita molto più a lungo dell'eseguibile C ++, semplicemente a causa del tempo di avvio della JVM. Questo non mostra che "Java è lento" ma che il tempo di avvio della JVM significa che Java non è lo strumento adatto per processi in esecuzione molto brevi (nessuno dei due linguaggi interpretati o altro richiede il caricamento di un runtime). Se il test fosse stato scritto correttamente per un periodo di diverse ore con basi di codice e sistemi di compilazione che utilizzavano livelli equivalenti di ottimizzazione, i risultati sono abbastanza diversi (probabilmente mostrando prestazioni piuttosto simili).

E questo è solo un esempio (che mi è familiare)

Come project manager, devi fare dei confronti per scegliere la lingua in cui il tuo software sarà codificato. I criteri potrebbero non essere tecnici:

• La lingua è adeguata per l'attività
• La lingua è disponibile su tutte le piattaforme di destinazione
• Qualità, affidabilità e costo dei compilatori
• Sono disponibili programmatori che conoscono questa lingua, sono competenti, costosi, creativi