Cosa significa questa affermazione sul fatto che C # e Java siano la metà di una lingua? [chiuso]

Nell'articolo: Perché POCO , c'è questa frase:

Maciej Sobczak dice bene: "Non mi piace quando qualcuno mi dà la metà della lingua e mi dice che è per la mia protezione".

Non capisco cosa significhi, anche se C # è di proprietà di Microsoft e Java è di proprietà di Oracle , non significa che posseggano metà del linguaggio, vero? Non ho trovato alcuna prova per provare quella frase e sono davvero curioso di questo. E ancora più curioso della parte "per la mia protezione".

Sobczak non sta parlando della proprietà aziendale. La "mezza" lingua che gli manca è tutte quelle cose che non puoi fare in molte lingue moderne, anche se come esperto di computer ben istruito sa che potrebbero essere rese possibili: ereditare da tutte le classi che desideri. Assegna qualsiasi oggetto a qualsiasi altro senza vincoli di tipo. Controlla l'allocazione e libera le risorse manualmente invece di affidarti al compilatore e al runtime per farlo per lui.

Il fatto è che tutte quelle restrizioni sono state introdotte nei linguaggi di programmazione per un motivo. Abbiamo fatto abbiamo lingue che hanno permesso tutto questo. Nel corso del tempo abbiamo scoperto che il programmatore medio sta meglio con una certa quantità di restrizioni e di tenuta della mano, perché il potenziale di fare errori davvero cattivi è semplicemente troppo grande per valere la potenza e l'espressività aggiuntive.

(Ovviamente, questo a volte infastidisce i programmatori che non avrebbero davvero bisogno di così tanta mano. Le loro lamentele sono a volte legittime. Ma le persone sono notoriamente cattive nel valutare le proprie capacità, e molti che pensano di non aver bisogno delle garanzie fanno, in anzi, ne hanno davvero bisogno. Non è sempre facile distinguere i veri intellettuali superiori che si sentono frenati dalle restrizioni nei linguaggi di alto livello dei programmatori medi che pensano solo che lamentarsi li renderà superiori o che non lo sanno meglio.)

Questo è spiegato abbastanza bene nella fonte originale della citazione :

Ho deciso di saperne di più sul C ++ e ne sono diventato fedele appassionato - questo include il mio interesse per il modo in cui questa lingua probabilmente evolverà. Inoltre, ho notato che sono necessarie le tecniche più avanzate e all'avanguardia per sviluppare utili librerie , non le applicazioni reali. Tenendo presente questo, ho provato a scrivere un paio delle mie librerie per scopi diversi (vedi la mia pagina di download) e provo anche a guardare oltre le spalle degli sviluppatori di C ++ Boost (vedi la mia pagina dei link) per sapere cosa tecniche di fascia alta sono. Trascorrere tempo nello sviluppo di librerie che dovrebbero essere generiche e utili allo stesso tempo è davvero impegnativo. Ecco perché i programmatori non smettono mai di imparare.

[...]

Continuo a giocare con C ++ e le tecniche per scrivere software robusto. Per ottenere una prospettiva più ampia nel campo del software affidabile, ho deciso di investire un po 'di tempo nell'apprendimento di Ada (e cose correlate), che è una lingua che sembra essere completamente abbandonata dal business anche se era Ada che è stata davvero progettata per complessi e affidabili sistemi. Devo ammettere che l'apprendimento di Ada è stato davvero utile per me, nel senso che mi ha permesso di dare uno sguardo più nuovo al mio lavoro e ai miei approcci di sviluppo. Soprattutto, alcune delle idee del mondo Ada possono essere più o meno direttamente applicate al C ++ con buoni risultati nel campo della solidità e della correttezza.

[...]

OK, ho dimenticato. Ho giurato un giorno di non imparare Java. Ma l'ho fatto. Bene, nella misura in cui mi permette di leggere e scrivere codice funzionante. Ho letto "Thinking in Java" (disponibile on-line, gratuito) e "Core Java" (non online, non gratuito), sono stato anche indirettamente coinvolto in alcuni sviluppi Java e ... Beh, non compro esso. Semplicemente non mi piace quando qualcuno mi dà la metà della lingua e mi dice che è per la mia protezione. È come un martello di carta, reso leggero in modo che nessuno si faccia male quando si colpisce il dito ... Lo stesso vale per C #. Scelgo la mazza d'acciaio, così posso essere sicuro che quando voglio giocare macho, resisterà.
La domanda è: perché così tante persone lo usano (Java, C #, ecc.)? Hmmm ... Forse perché è molto buono in alcuni posti. Ma ci sono situazioni in cui sia la lingua che la libreria mostrano che sono state progettate piuttosto per le applet (inizialmente) che per diventare utility fai-tutto. Promette solo troppo e dà troppo poco per quanto riguarda la tecnologia catch-all. O come soluzione che potrebbe scavare su qualsiasi competizione ..

Mi piace il C ++ quando è necessaria la massima potenza e la prospettiva più ampia. Nei luoghi in cui l'espressività del C ++ non è un must, linguaggi come Tcl o Python sembrano adattarsi al conto. Non solo sono aperti riguardo alla loro evoluzione, ma è possibile estenderli e incorporarli, a seconda delle esigenze particolari. Vedo molte possibilità sognare in quelle tecnologie. Tendo anche ad abbandonare C come linguaggio per la programmazione regolare - questa sembra essere una scelta ragionevole solo come obiettivo per la generazione di codice, altrimenti è troppo soggetta a errori. Oggi Ada è la mia seconda scelta probabile per progetti più seri, a condizione che io abbia la libera scelta (che, sfortunatamente, non è il caso per la maggior parte del tempo).

Quindi, in altre parole, all'autore di quella citazione piace il C ++, e non gli piace Java, e sente che a Java manca metà del C ++. E questo è tutto quello che c'è da sapere su quella citazione.

L'articolo collegato al blog che hai pubblicato è stato rimosso, quindi è difficile essere sicuri, ma come dice Kilian, è probabile che quando dice "metà lingua" significa che C # e Java sembrano C ++ ma con un sacco di caratteristiche e costrutti rimossi per renderli più facili da usare o più sicuri.

Nel 2006, quando questo è stato scritto, quando C # era relativamente giovane e Java era in molti modi immaturo, e quando la potenza contro la sicurezza sembrava un compromesso in cui si poteva sceglierne solo uno, questa non era una posizione totalmente irragionevole da prendere .

In questi giorni questa posizione non è affatto ragionevole. Pensando solo ai linguaggi tradizionali, C # e Java sono maturati enormemente, prendendo in prestito funzionalità da altri linguaggi (in particolare funzionali) per promuovere la scrittura di codice sicuro. Abbiamo anche lingue come Rust e Swift che sono state costruite da zero per farlo.

Se qualcuno guarda in basso una lingua perché ti tiene la mano, o dice che una lingua difficile da usare è in qualche modo una buona cosa, prenderei qualsiasi cosa dicessero con un granello di sale. Devi solo guardare al numero imbarazzante di bug trovati nel codice da cui dipendiamo ogni giorno, scritti dalle menti più brillanti del settore, che sarebbero stati banalmente evitati usando linguaggi "sicuri", per capire perché.

Guardando indietro agli archivi , sembra che questa citazione risalga al 2003 (nonostante l'articolo che la citasse fosse del 2006). A quel tempo, C # era nella versione 1. x , e mancava molte delle sue funzionalità moderne :

Nuove caratteristiche

C # 2.0

• Generics
• Tipi parziali
• Metodi anonimi
• iteratori
• Tipi nullabili
• Getter / setter accessibilità separata
• Conversioni di gruppi di metodi (delegati)
• Co-e contro-varianza per i delegati
• Classi statiche
• Inferenza delegata

C # 3.0

• Variabili locali tipizzate implicitamente
• Inizializzatori di oggetti e raccolte
• Proprietà implementate automaticamente
• Tipi anonimi
• Metodi di estensione
• Espressioni di query
• Espressione lambda
• Alberi di espressione
• Metodi parziali

C # 4.0

• Binding dinamico
• Argomenti nominati e facoltativi
• Co-e contravarianza generica
• Tipi di interoperabilità incorporati ("NoPIA")

C # 5.0

• Metodi asincroni
• Attributi delle informazioni sul chiamante

C # 6.0

• Compilatore-come-un-servizio (Roslyn)
• Importazione di membri di tipo statico nello spazio dei nomi
• Filtri di eccezione
• Attendere blocchi di cattura / finalmente
• Inizializzatori di proprietà automatiche
• Valori predefiniti per le proprietà solo getter
• Membri con espressione corporea
• Propagatore null (operatore null-condizionale, controllo null sintetico)
• Interpolazione di stringhe
• nome dell'operatore
• Inizializzatore del dizionario

C # 7.0

• Fuori variabili
• Corrispondenza del modello
• Le tuple
• Deconstruction
• Funzioni locali
• Separatori di cifre
• Letterali binari
• Restituzioni di riferimento e locali
• Tipi di ritorno asincroni generalizzati
• Costruttori e finalizzatori corposi di espressione
• Getter e setter corposi di espressione

C # 7.1

• Principale asincrono
• Espressioni letterali predefinite
• Nomi di elementi tupla dedotti

- "C Sharp" , Wikipedia (riferimenti e collegamenti rimossi)

È probabilmente più comprensibile che C # sembrasse una mezza lingua in quel contesto, poiché mancava molto di ciò che C # è oggi. È strano pensare che non avesse nemmeno staticlezioni!

Mancavano anche altre cose, dal momento che C # era legato a .NET. Ad esempio, WPF non era in circolazione allora; era tutto WinForms.

Si lamentava della mancanza di funzionalità linguistiche che consentissero un controllo approfondito. Questi includono strumenti per

• Applicazione dell'immutabilità (come la constparola chiave C ++ )
• Controllo della durata e della proprietà degli oggetti
• Controllo dell'utilizzo della memoria, della copia e dello stile di allocazione

Questo mi ricorda una delle mie critiche a Java:

tutto è un puntatore, ma i puntatori non esistono.

Negli oggetti C ++, puntatori e riferimenti sono tre concetti distinti con una semantica chiara. In Java hai solo lo pseudo-oggetto-puntatore. Combinando questi e evitando la vera semantica del puntatore, il modello a oggetti è meno chiaro.

In un programma C ++ ben definito il programmatore può aspettarsi che i riferimenti siano validi e non nulli. A causa del suo modello semplificato, Java non può offrire le stesse garanzie.

I sintomi di questo modello meno chiaro includono il modello di oggetti null e i condizionali yoda come 5.equals(potentiallyNullIntegerReference).

Sono d'accordo con la risposta di @Kilian ma aggiungerò alcuni elementi.

1- In esecuzione su una macchina virtuale non sul sistema operativo

Poiché Java e C # sono in esecuzione su una macchina virtuale, è logicamente prevedibile che non si possa fare esattamente ciò che si desidera quando si è direttamente sul sistema operativo, poiché è probabile che si danneggi qualcosa nella VM. Inoltre, essendo Java orientato come indipendente dalla piattaforma, è ancora più logica.

2- Tonnellate di applicazioni non richiedono che tu abbia bisogno di quel tipo di cose.

Ci sono tonnellate di applicazioni che in realtà non hanno bisogno di te per scavare attraverso molti dettagli, ma se lo fai con una lingua che ti richiede di farlo, ottieni:

• Più rischi di avere bug a causa di quelle cose inutili.
• Maggiori costi di sviluppo, gestione della memoria e test richiedono tempo e denaro!

3- La lingua è fatta su una scelta ponderazione costo / utilizzo / rischi, come ... tutto.

Con C ++ puoi fare praticamente quello che vuoi, questa è la scelta delle persone C ++. Tuttavia, più c'è, più è necessario gestire.

Quindi cose come l'ereditarietà multipla non rinunciano solo al fatto che sono pericolose, ma rinunciano perché implementarle ha un costo (sviluppo, manutenzione), tutto per quello per una funzionalità che raramente viene utilizzata correttamente e può generalmente riscritto in modo diverso.

Metti semplicemente tutte le restrizioni in linguaggi di alto livello come C # e Java per proteggere il programmatore. Esistono non tanto per proteggere il programmatore da se stesso, quanto piuttosto per proteggere il programmatore da altri programmatori!

Quante volte, come programmatori, incontriamo librerie che erano assolutamente terribili nelle loro pratiche di codifica e progettazione ma che siamo stati costretti a usare per un motivo o per l'altro?

Questi programmi hanno in genere i tratti distintivi del vecchio metodo procedurale di programmazione, con mancanza di incapsulamento, un sacco di scritture di memoria diretta con errori di acquisizione o gestione piccoli o nulli. I Segfault perseguono in massa quando tentano di usarli in qualsiasi progetto su larga scala.

È qui che linguaggi come Java e C # sono estremamente utili; non è che a loro piaccia il fatto che non ci permettono di fare tutte le cose ordinate che fanno altre lingue, è che ci godiamo la mancanza di mal di testa che dobbiamo sopportare perché altri programmatori abuserebbero delle cose ordinate che altre lingue possono fare.

Le interfacce meritano qualsiasi tipo di compromesso in termini di memoria o velocità di esecuzione nella mia mente. Spero che tu possa vedere che in qualsiasi tipo di applicazione mission-critical limitata nel tempo, tutte quelle protezioni, una corretta gestione degli errori e in generale la certezza che la memoria non venga sottratta sono buone cose!