In the article: Why POCO, there is this sentence:
Maciej Sobczak puts it well: “I just don’t like when somebody gives me half of the language and tells me that it’s for my own protection”.
I don't understand what he means, even though C# is owned by Microsoft & Java is owned by Oracle, it doesn't mean they hold half of the language, does it? I didn't find any evidence to prove that sentence, and I'm really curious about this. And even more curious about the 'for my own protection' part.
Sobczak isn't talking about corporate ownership. The "half" language that he is missing is all those things that you can't do in many modern languages, even though as a well-educated computer expert he knows they could be made possible: inherit from as many classes as you like. Assign any object to any other without type constraints. Control allocation and freeing resources manually instead of trusting the compiler and run-time to do it for him.
The thing is, all those restrictions were put into programming languages for a reason. We did have languages that allowed all this. Over time we found that the average programmer is better off with a certain amount of restrictions and hand-holding, because the potential of making really bad errors is just too great to be worth the additional power and expressivity.
(Obviously, this sometimes annoys programmers who wouldn't really need that much hand-holding. Their complaints are sometimes legitimate. But people are notoriously bad at assessing their own skills, and many who think they don't need the safeguards do, in fact, very much need them. It isn't always easy to tell apart actual superior intellects who feel held back by restrictions in high-level languages from average coders who just think that complaining will make them look superior, or who don't know any better.)
This is explained quite nicely in the original source of the quote:
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).
So, in other words, the author of that quote likes C++, and he doesn't like Java, and he feels that Java is missing half of C++. And that's all there is to that quote.
The article linked to in the blog you posted has been removed, so it's hard to be sure, but as Kilian says, it's likely that when he says "half the language" he means that C# and Java feel like C++ but with a lot of features and constructs removed to make them easier to use or safer.
Back in 2006, when this was written, when C# was relatively young and Java was in many ways immature, and when power vs safety seemed like a trade-off where you could only pick one, this wasn't a totally unreasonable position to take.
These days that position isn't reasonable at all. Just thinking about mainstream languages, C# and Java have matured enormously, borrowing features from other languages (particularly functional) to promote writing safe code. We also have languages like Rust and Swift that are built from the ground up to do this.
If someone looks down on a language because it holds your hand, or says that a language being hard to use is somehow a good thing, I'd take anything they said with a grain of salt. You only have to look at the embarrassing number of bugs found in code we depend on every day, written by the brightest minds in the industry, that would have been trivially avoided by using 'safe' languages, to see why.
Looking back at the archives, it appears that this quote was from 2003 (despite the article citing it being from 2006). At that time, C# was in Version 1.x, and it was lacking a lot of its modern features:
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)
It's probably more understandable that C# seemed like half-a-language in that context, as it was lacking a lot of what C# is today. It's weird to think that it didn't even have static classes!
More stuff was missing, too, since C#'s been tied to .NET. For example, WPF wasn't around back then; it was all WinForms.
He was complaining of the lack of language features which enable fine-grained control. These include tools for
const keyword)This reminds me of one of my criticisms of Java:
everything's a pointer, but pointers don't exist.
In C++ objects, pointers and references are three distinct concepts with clear semantics. In Java you just have the pseudo-object-pointer. By conflating these and eschewing true pointer semantics the object model is less clear.
In a well defined C++ program the programmer can expect references to be valid and non-null. Because of its simplified model, Java cannot make the same guarantees.
Symptoms of this less clear model include the null object pattern and yoda conditionals such as 5.equals(potentiallyNullIntegerReference).
I agree with @Kilian answer but I will add some elements.
1- Running against a Virtual Machine not the OS
Since Java and C# are running through a Virtual Machine, it is logically expected that you cannot do exactly what you want like when being straight on the OS, because you're likely to corrupt something in the VM. Furthermore with Java being oriented as being platform agnostic, it is even more logic.
2- Tons of applications don't require you to need those kind of stuff.
There are tons of applications that really don't need you to dig through that much of details, yet if you do that with a language that require you to do it you get :
3- Language are made on some choice weighting cost/usage/risks, like... everything.
With C++ you can do pretty much what you want, that is the choice of C++ people. However the more there is, the more you need to handle.
So things like multiple inheritance are not given up just on the fact that they're dangerous, they're given up because implementing them have a cost (development, maintenancy), all for that for a feature that is rarely get used properly and can generally be rewritten differently.
Simply put all the restrictions in high level languages like C# and Java exist to protect the programmer. They exist not so much to protect the programmer from him/herself, but rather to protect the programmer from other programmers!
How many times do we as programmers encounter libraries that were downright aweful in their coding practices and design but that we were forced to use for one reason or another?
These programs typically have the hallmarks of the old procedural method of programming, with lack of encapsulation, plenty of direct memory writes with little to no error catching or handling. Segfaults pursue en-mass when attempting to use them in any large-scale project.
That's where languages like Java and C# are extremely helpful; it is not that they we enjoy the fact that they don't let us do all the neat things other languages do, It is that we enjoy the lack of headaches we have to endure because other programmers would abuse the neat things that other languages can do.
Interfaces are well worth any sort of trade-off in terms of memory or execution speed in my mind. I hope you can see that in any sort of time-limited mission critical application, all those protections, proper error-handling and generally being certain that memory isn't being qucked with are good things!
