Che cosa significa questa affermazione su C # e Java come metà della lingua? [chiuso]

Sobczak non sta parlando di proprietà aziendale. La "mezza" lingua che manca è tutte quelle cose che non si possono fare in molte lingue moderne, anche se come esperto di computer ben informato sa che potrebbe essere reso possibile: ereditato da quante classi desideri. Assegna qualsiasi oggetto a qualsiasi altro senza vincoli di tipo. Controlla l'allocazione e libera le risorse manualmente invece di fidarti del compilatore e del tempo di esecuzione per farlo per lui.

Il fatto è che tutte queste restrizioni sono state inserite nei linguaggi di programmazione per una ragione. Noi abbiamo 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 tenuta manuale, perché il potenziale di fare errori veramente brutti è semplicemente troppo grande per meritare la potenza e l'espressività aggiuntive.

(Ovviamente, questo a volte infastidisce i programmatori che non avrebbero davvero bisogno di quella mano. Le loro lamentele sono a volte legittime, ma la gente è notoriamente cattiva nel valutare le proprie abilità e molti pensano non hanno bisogno di protezioni, anzi, ne hanno davvero bisogno.Non è sempre facile distinguere intellettuali superiori che si sentono trattenuti dalle restrizioni nei linguaggi di alto livello dai codificatori medi che pensano che solo lamentarsi farà sembrano superiori, o che non conoscono meglio.)

Questo è spiegato abbastanza bene in la fonte originale del citazione :

I decided to learn more about C++ and became its faithful passionate - this includes my interest in the way this language is likely to evolve. Moreover, I've noticed that the most high-end and state-of-the-art techniques are needed to develop useful libraries, not the actual applications. Having this in mind, I've tried to write a couple of my own libraries for different purposes (see my download page) and I also try to look over the shoulders of the C++ Boost developers (see my links page) to learn what those high-end techniques are. Spending time on development of libraries that are supposed to be generic and useful at the same time is really demanding. That's why programmers never stop learning.

[…]

I keep playing with C++ and the techniques for writing robust software. To gain wider perspective in the area of reliable software I decided to invest some time in learning Ada (and related stuff), which is a language that seems to be completely abandoned by business even though it was Ada that was really designed for complex and reliable systems. I have to admit that learning Ada was really beneficial for me in the sense that it enabled me to take a more fresh look at my work and development approaches. Most importantly, some of the ideas from the Ada world can be more or less directly applied to C++ with good results in the area of robustness and correctness.

[…]

OK, I forgot. I swore one day not to learn Java. But I did. Well, to the extent that allows me to read and write working code. I have read 'Thinking in Java' (available on-line, free) and 'Core Java' (not online, not free), I was also indirectly involed in some Java development, and... Well, I don't buy it. I just don't like when somebody gives me half of the language and tells me that it's for my own protection. It's like a paper hammer, made light so that nobody will hurt himself when hitting the finger... The same applies to C#. I choose the steel sledge-hammer, so that I can be sure that when I want to play macho, it will withstand.
The question is - why do so many people use it (Java, C#, etc.)? Hmmm... Maybe because it's very good in some places. But there are situations, where both the language and the library show that they were designed rather for applets (initially) than to become do-everything utilities. It just promises too much and gives too little as for catch-all technology. Or as a solution that could plough over any competition..

I like C++ when maximum power and widest perspective is needed. In places where the expressiveness of C++ is not a must-have, languages like Tcl or Python seem to fit the bill. Not only they are open with regard to their evolution, but one can extend and embed them, depending on particular needs. I see a lot of possibilities dreaming in those technologies. I also tend to abandon C as a language for regular programming - this seems to be a reasonable choice only as a target for code generation, otherwise it's too error prone. Today, Ada comes as my likely second choice for more serious projects, provided that I have free choice (which is, unfortunately, not the case most of the time).

Quindi, in altre parole, l'autore di quella citazione ama C ++, e non gli piace Java, e ritiene che Java manchi metà del C ++. E questo è tutto quello che c'è da sapere.

L'articolo collegato nel blog che hai postato è stato rimosso, quindi è difficile esserne sicuri, ma come dice Kilian, è probabile che quando dice "metà della lingua", vuol dire che C # e Java si sentono come C ++ ma con un sacco di funzioni 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 per molti aspetti immaturo, e quando il potere contro la sicurezza sembrava un compromesso in cui si poteva sceglierne solo uno, questo non era assolutamente irragionevole posizione da prendere.

In questi giorni quella posizione non è affatto ragionevole. Solo pensando ai linguaggi mainstream, 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 linguaggi come Rust e Swift costruiti da zero per farlo.

Se qualcuno guarda giù su una lingua perché ti tiene per mano, o dice che una lingua che è difficile da usare è in qualche modo una buona cosa, prenderei qualsiasi cosa dicessero con un pizzico di sale. Devi solo guardare l'imbarazzante numero di bug trovati nel codice da cui dipendiamo ogni giorno, scritti dalle menti più brillanti del settore, che sarebbe stato banalmente evitato usando linguaggi "sicuri", per capire perché.

Guardando indietro agli archivi , sembra che questa citazione risalga al 2003 (nonostante l'articolo citi che è del 2006). A quel tempo C # era nella versione 1. x , e mancavano molte delle sue funzioni moderne :

New features

C# 2.0

• Generics
• Partial types
• Anonymous methods
• Iterators
• Nullable types
• Getter/setter separate accessibility
• Method group conversions (delegates)
• Co- and Contra-variance for delegates
• Static classes
• Delegate inference

C# 3.0

• Implicitly typed local variables
• Object and collection initializers
• Auto-Implemented properties
• Anonymous types
• Extension methods
• Query expressions
• Lambda expression
• Expression trees
• Partial methods

C# 4.0

• Dynamic binding
• Named and optional arguments
• Generic co- and contravariance
• Embedded interop types ("NoPIA")

C# 5.0

• Asynchronous methods
• Caller info attributes

C# 6.0

• Compiler-as-a-service (Roslyn)
• Import of static type members into namespace
• Exception filters
• Await in catch/finally blocks
• Auto property initializers
• Default values for getter-only properties
• Expression-bodied members
• Null propagator (null-conditional operator, succinct null checking)
• String interpolation
• nameof operator
• Dictionary initializer

C# 7.0

• Out variables
• Pattern matching
• Tuples
• Deconstruction
• Local functions
• Digit separators
• Binary literals
• Ref returns and locals
• Generalized async return types
• Expression bodied constructors and finalizers
• Expression bodied getters and setters

C# 7.1

• Async main
• Default literal expressions
• Inferred tuple element names

-"C Sharp", Wikipedia (references and links removed)

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

Mancava ancora del materiale, dal momento che C # è stato collegato a .NET. Ad esempio, WPF non era ancora in circolazione; era tutto WinForms.

Si è lamentato della mancanza di funzionalità linguistiche che consentono un controllo a grana fine. Questi includono strumenti per

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

Questo mi ricorda una delle mie critiche a Java:

everything's a pointer, but pointers don't exist.

Negli oggetti C ++, i puntatori e i riferimenti sono tre concetti distinti con semantica chiara. In Java hai solo il puntatore pseudo-oggetto. Combinando questi e rimuovendo la semantica dei puntatori, il modello degli 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 oggetto nullo 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 # funzionano attraverso una macchina virtuale, ci si aspetta logicamente che non si possa fare esattamente ciò che si vuole quando si è direttamente sul sistema operativo, perché è probabile che si corrompa qualcosa nella VM. Inoltre, essendo Java orientato come indipendente dalla piattaforma, è ancora più logico.

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

Ci sono un sacco di applicazioni che non hanno davvero bisogno di te per scavare attraverso gran parte dei dettagli, ma se lo fai con una lingua che ti richiede di farlo, ottieni:

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

3- La lingua viene calcolata in base al costo / utilizzo / rischio della scelta, 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 vengono abbandonate solo perché sono pericolose, ma vengono abbandonate perché implementarle hanno un costo (sviluppo, manutenzione), tutto questo per una funzionalità che raramente viene utilizzata correttamente e in genere può essere 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, ma piuttosto per proteggere il programmatore da altri programmatori!

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

Questi programmi hanno tipicamente i tratti distintivi del vecchio metodo procedurale di programmazione, con la mancanza di incapsulamento, un sacco di scritture dirette della memoria con poca o nessuna cattura o gestione degli errori. Segfaults persegue l'integrazione nel tentativo di utilizzarli in qualsiasi progetto su larga scala.

Ecco dove lingue come Java e C # sono estremamente utili; non è che ci piaccia il fatto che non ci lasciano fare le cose belle che fanno gli altri linguaggi, è che ci piace la mancanza di grattacapi che dobbiamo sopportare perché altri programmatori abuserebbero delle cose belle che altre lingue possono fare.

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