32

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.

Jay Elston
  • 2,680
  • 22
  • 30
123iamking
  • 431
  • 4
  • 7
  • 12
    I interpreted that as critique against letting the programmer do things like freely allocate and free memory and that sort of "protection", but I'm not sure if that was the point he was trying to make. – Kayaman Nov 09 '17 at 14:07
  • 15
    I'm not sure exactly, because the article he's quoting from seems to be dead, but it seems like he's saying that Java and C# are missing a number of C++'s more 'dangerous' or controversial features, like multiple inheritance or template metaprogramming. – GoatInTheMachine Nov 09 '17 at 14:07
  • 3
    The context of the quote is missing (the link is 404), so the only thing you will get here is people guessing at what he probably meant, or (more likely) people just presenting their own opinion. If you actually want to know the context, i.e. what is on the lost page, the best bet is probably to write the author directly, or maybe try to find the lost page through the wayback machine or similar. – JacquesB Nov 09 '17 at 14:45
  • Just FYI - Oracle might not own Java in the near future: https://blogs.oracle.com/theaquarium/opening-up-ee-update – FGreg Nov 09 '17 at 16:29
  • @GoatInTheMachine: You can do multiple inheritance in Java and C#; it just requires a lot of unnecessary plumbing. – Robert Harvey Nov 09 '17 at 16:36
  • 2
    The statement is missing the point in that, **even if you can handle it, you don't always want to expose every possible aspect of software development** in a language. Sure you may not have a problem reading memory management code, but other developers may not be incredibly excited to maintain that code. **Its similar to the concept of encapsulation.** Also C# does let you access quite a bit of stuff through, compiler directives, special attributes, and reflection, not that one should use those things, though. – Mark Rogers Nov 09 '17 at 17:19
  • 32
    For your own good, pay no attention to the people who think that a language must have all the features of C++ to be considered "real" and "complete". Pay no attention to the people who think that type safety, memory safety and well defined behavior are "training wheels". Correctness is becoming the most important aspect of software in most industries and the people who take pride in not caring about it will soon become irrelevant. – Theodoros Chatzigiannakis Nov 09 '17 at 18:35
  • 1
    @TheodorosChatzigiannakis *yes*. – Tobia Tesan Nov 09 '17 at 21:07
  • @RobertHarvey The implementation of default methods in interfaces starting with Java 8 means multiple inheritance has become quite easy to use in Java, at that. – JAB Nov 09 '17 at 21:44

7 Answers7

162

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.)

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 67
    This is my *goto* answer. – Neil Nov 09 '17 at 14:10
  • 71
    Also I would add that there is no such thing as superior intellects who don't need the restrictions. It's always safe to assume that everybody messes up sooner or later. And usually the superior the intellect, the bigger the blunder. – Neil Nov 09 '17 at 14:16
  • 29
    There's a bit more to Java and C# than simply preventing people from shooting themselves in the foot. Managing memory took a significant amount of developer time and effort before garbage collection came along, for example, and it's hard to do manual memory management correctly. Garbage collection improves programmer productivity. – Robert Harvey Nov 09 '17 at 16:52
  • 12
    @RobertHarvey I 100% agree. Being a long time C++ programmer, I was skeptical of automatic memory management when moving to C#. Once I got past that, it was incredibly liberating to just not have to worry about it 99% of the time. It freed up my brainpower to think about other issues instead. – 17 of 26 Nov 09 '17 at 16:55
  • 4
    Sometimes even if you don't need the hand-holding, it still just lets you get your work done quicker in this case, and the code will more closely model its overall intention. – Panzercrisis Nov 09 '17 at 17:16
  • 8
    "Assign any object to any other without type constraints."... So, `dynamic`? – Arturo Torres Sánchez Nov 09 '17 at 17:32
  • 2
    Some of the omissions from Java (like unsigned bytes) have no good justification. Many others, however, exist for the purpose of improving runtime efficiency without allowing code to violate the invariant that live storage of object-reference type must never be overwritten with anything else. If `Cat` has a field `favoriteToy` of type `CatToy` at offset 8, and `Dog` has an `int` field `slobberCount` at the same offset, storing a reference to `Cat` into variable `x` of type `Dog` and then saying `x.slobberCount++` would cause that `Cat` to hold a corrupted object reference. – supercat Nov 09 '17 at 17:51
  • 1
    If the validator knows that a variable `x` of type `Dog` cannot possibly hold a reference to anything other than a `Dog`, then it can process `x.slobberCount++` using an integer-increment instruction without having to first check the type of `x`. Because of array covariance, writes to array elements are stuck checking the type of the array being written, but in most cases having the type rules solidly in the language improves run-time efficiency by avoiding the need for constant type checks. – supercat Nov 09 '17 at 17:54
  • 1
    @RobertHarvey In addition, the removal of unnecessary features can make it possible or easier to do more things below the layer of abstraction. These kinds of arguments about taking away toys were made about [RISC](https://en.wikipedia.org/wiki/Reduced_instruction_set_computer) but it seems silly now. – JimmyJames Nov 09 '17 at 17:55
  • @supercat A good example of the point I mean to make. – JimmyJames Nov 09 '17 at 17:56
  • 2
    A C++ programmer has the freedom to assign the address of a stack allocated object to a field of a heap allocated object or rather has the freedom to bow to the power of the factual by not doing it. In contrast, the Java programmer has the freedom to link objects in whatever way, while the JVM still allocates and deallocates objects faster than C++ (today, mind that the quote is a decade old). Of course, it’s not always that comparable, but I like to say it like, the C++ programmer has the “power” to decide between two object allocation mechanisms, both less efficient than Java’s (on average)… – Holger Nov 09 '17 at 18:06
  • 6
    `if(level=1)` is not valid java but is valid c. in java it fails to compile but in c it compiles and runs differently than what you probably expected. If you meant to do it, this expression allows more concise code but most likely you did not mean to do this. – emory Nov 09 '17 at 18:18
  • One can always code in *vanilla C* when necessary, and link to the rest of the application. – Pieter Geerkens Nov 09 '17 at 18:24
  • 1
    @Neil *goto* considered harmful. (But not by me!!) – RonJohn Nov 09 '17 at 23:59
  • 1
    When I started with C# I felt it was getting in my way. After using it for some years I came to see that almost all the stuff I lost didn't matter. The one thing that I do consider missing is read/write access to binary files is quite awkward. What I ended up doing no doubt took at least 10x as long as the older Delphi version--but both versions were actually IO bound anyway, the extra CPU time basically only offends me, it doesn't slow it down noticeably. – Loren Pechtel Nov 10 '17 at 04:01
  • Your last paragraph seems a bit condescending. Would you like to revise it? – Infiltrator Nov 10 '17 at 05:36
  • @Neil : unless you are developing real-time applications where sub-microsecond accuracy is necessary. Then it is literally impossible to do it purely in Java or C#. – vsz Nov 10 '17 at 05:49
  • @vsz I never mentioned Java or C#. Not sure where you're coming from. – Neil Nov 10 '17 at 07:27
  • 3
    Translation: Because he has failed to realize the value in automating repetitive, error prone tasks. In other words, he doesn't understand what his profession is about. – jpmc26 Nov 10 '17 at 07:47
  • @Neil : they are the examples in the question for languages with restrictions. – vsz Nov 10 '17 at 12:16
  • @Infiltrator I don't see it as condescending. It's pretty much factual/neutral. – JimmyJames Nov 10 '17 at 15:22
  • 1
    This answer broadly addresses technical limitations of Java and C# but does not mention any actual "missing" feature besides multiple inheritance. References, pointers, templates, etc. are all crucial tools that one misses sorely when coming from C++. Also, C++ never permitted "assigning without any type constraints", and "controlling allocations and frees" has been a code smell since the dawn of the language. – Quentin Nov 10 '17 at 16:50
  • 1
    You talk about the "bad half" of the language that makes it more error prone, but miss the "good half", which is probably referred to by the quote. There are good things in C++ that would make C# and Java better, for example, the ability to specify if an object is allocated on the heap or stack, without changing the data type. – Frank Hileman Nov 17 '17 at 01:58
34

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.

Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
  • 18
    Ironically, he dislikes C the exact same reason he like C++, it is very open, allowing a lot of power and a lot of errors. – GreySage Nov 09 '17 at 16:21
  • 8
    He considers C++ to be more expressive than Python – benxyzzy Nov 09 '17 at 17:04
  • 12
    @GreySage That caught my eye too... C is too error prone but C# doesn't give you enough power? C is that far removed from C++? C# doesn't have "unsafe" corners that give you more control? Interesting mix of opinions thats for sure... – WernerCD Nov 09 '17 at 17:12
  • 10
    @WernerCD can't really tell about unsafe C#, but C and C++ have pretty much nothing in common, except that you can beat a basic C90 snippet into a valid C++-ish snippet on which the compiler won't choke. – Quentin Nov 09 '17 at 19:23
23

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.

GoatInTheMachine
  • 442
  • 4
  • 7
  • 6
    I agree with your position in the last paragraph. C++ should be called the "Fountain of Exploits". – Caleb Mauer Nov 09 '17 at 16:57
  • 3
    Also to complement your 2nd paragraph, both Java and C# heavily cribbed C and C++ syntax for various reasons, including enticing existing C/C++ developers with the promise of a lower learning curve. As they've matured, they've added their own features and have their own flavor, but in their early days, it was easier to view them as "C++ but less powerful" since they were more directly positioned as an alternative to C++. – Harrison Paine Nov 09 '17 at 19:44
12

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.

Nat
  • 1,063
  • 1
  • 8
  • 11
  • static classes may be a poor choice of a missing feature seeing as Java still doesn't have them (the C# kind). Unless this is a jab at Java? – user253751 Nov 10 '17 at 00:05
  • 1
    @immibis Not an intentional stab at Java, but, jeeze, really? `static` classes seem like such a primitive feature; I kinda imagined that they pre-dated instanced classes. – Nat Nov 10 '17 at 00:20
  • 2
    Seems like saying that piston-engine jets predated jet-engine jets; a "non-instanced class" is generally called a *module* or *namespace* , except in languages where all code has to be inside a class. (Or calling a bicycle a manual automobile, or calling a landline phone a stationary cellphone, or ...) – user253751 Nov 10 '17 at 00:22
  • @Nat - Having static classes is nice, but not having them changes absolutely nothing. You can just make all members of the class static, and all that you lose is a few kinds of compiler errors if you forget that the class was intended to remain static. – Jirka Hanika Nov 10 '17 at 12:24
  • @JirkaHanika Yeah, I'm not a huge fan of `static` classes in most cases anyway. Honestly I picked it as a feature to call out because it seemed really simple, primitive part of C#; I didn't consider that they weren't in Java. – Nat Jan 04 '18 at 11:42
  • @Nat - Got you. My guess is that even some really really simple features that were already known from Java or C++ or Delphi or whatever languages the C# designers liked still didn't make it to C# as of .NET 1.1 for the reason of too many priorities - especially if they felt like they could be added anytime later. It's simple to explain what a "static class" is, but it's some work to make every tool aware of the new metadata bit and of its allowed and forbidden combinations with any other metadata. – Jirka Hanika Jan 04 '18 at 13:23
3

He was complaining of the lack of language features which enable fine-grained control. These include tools for

  • Enforcing immutability (such as the C++ const keyword)
  • Controlling object lifetime and ownership
  • Controlling memory usage, copying and allocation style

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).

Wes Toleman
  • 972
  • 7
  • 9
  • 5
    This is very confused. Pointers (in the logical sense exist in Java) you just can't screw around with them. The whole point of simplifying the model is to allow for more guarantees. The logic that you can assume more about code in a language will less restrictions is backwards. More restrictions -> more guarantees. – JimmyJames Nov 09 '17 at 18:02
  • 1
    @JimmyJames the phrase means that, even though all java classes have implicit (yuck, btw) reference semantics, you can't have an actual pointer. For example, there's no way to get a "reference" to a reference. This cripples the language in several places, sometime requiring insane workarounds (see `Map.merge` when you simply want to update a value in a map). – Quentin Nov 09 '17 at 19:29
  • 3
    @JimmyJames: Some kinds of useful guarantees cannot be practically offered without imposing certain restrictions. Further, some useful optimizations may require imposing some restrictions. Some languages, however, impose pointless restrictions which don't offer any useful guarantees to programmers and shouldn't be required to perform useful optimizations. Some restrictions are simply bad. – supercat Nov 09 '17 at 21:35
  • 3
    @JimmyJames: On the other hand, some of the more fundamental restrictions of Java and "safe-mode" C# let them offer a very *useful* guarantee that C++ can't: any reference (what in C++ would be a pointer) that is ever observed to identify a particular object will never be observed to identify anything *else*. – supercat Nov 09 '17 at 21:39
  • 3
    Can you provide some quotes to support your answer? For example, AFAIK, the page doesn't mention `const`. It *does* mention "functional programming", however, the language he uses as example is Scheme, which is *not* a pure functional language (in fact, the designers of Scheme are careful to avoid the use of the word "function" and talk about "procedures"), so it seems he is using the "first-class subroutines" interpretation of FP and not the "referential transparency" one. – Jörg W Mittag Nov 10 '17 at 00:11
  • @JimmyJames, I've added more about the semantics of pointers, objects and references. Is that clear yet or should I expand further? – Wes Toleman Nov 10 '17 at 01:32
  • @Quentin Fancy tricks like having references to references can make you feel cool but in real professional software development, these types of 'programming in the small' features (or the lack thereof) have very little impact. – JimmyJames Nov 10 '17 at 15:07
  • @supercat I'd like to see a little more clarification on "In C++ it is not unreasonable to expect a reference to be valid and non-null." This seems to imply it's an expectation and not a guarantee but then you imply is a guarantee in the next sentence. On a side note, a [non-null](https://blogs.oracle.com/java-platform-group/java-8s-new-type-annotations) constraint is available in java. I wouldn't blame you for considering it a hack. – JimmyJames Nov 10 '17 at 15:12
  • "In Java you just have the pseudo-object-pointer. By conflating these and eschewing true pointer semantics the object model is less clear." I believe the opposite. Because Java's model is simple, it's more clear. You also need to realize that this simplification allows for things like moving objects around in memory. I don't think Java is perfect. I am aware of it's warts but the simplicity of references passed by value is a plus in my book, not a problem. – JimmyJames Nov 10 '17 at 15:18
  • @JimmyJames being able to simply write `map.at(key) = value` instead of stuffing all of your logic backwards in a lambda sounds far from a "fancy trick" IMO. Maybe the fact that something as basic as a reference-to-reference is seen as a "fancy trick" is a problem in itself. – Quentin Nov 10 '17 at 16:38
  • @Quentin [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) was absolutely aware of this feature and deemed it unnecessary/undesirable. You are free to believe it was a mistake but his peers are few. The best way to set values in a map isn't something I spend a lot of time thinking about but I am curious as to why you need `map.at(key) = value` when (as far as I can tell) `map.put(key, value)` would do the exact same thing. The `merge` method encapsulates a lot more logic than simply setting a value. Is there something about this that I am missing? – JimmyJames Nov 10 '17 at 16:56
  • @JimmyJames Indeed, the complete case would be something like `auto &v = map.at(key); if(v.something()) v = ...;` -- this couldn't be done before `merge` without performing two lookups, and with `merge` it requires a complex higher-order function. Not something I'd expect to wield when a reference would have done just fine. – Quentin Nov 10 '17 at 17:01
  • @JimmyJames but whether or not the absence of (C++-style) references in Java is a wise choice, the question was "why would womeone call Java half of a language", and this kind of missing pieces is the answer. – Quentin Nov 10 '17 at 17:02
  • @Quentin 'yuck' would seem to be a judgement, no? Anyway, `putIfAbsent` would seem to do the trick there. The `merge` method doesn't seem to be indicated by your use case. Honestly I've long found the Map interface to be deficient. Being able to retrieve the `MapEntry` by key would eliminate the need for these special-case methods. It's really beyond the scope of comments, but what your approach does is break encapsulation. I think you are missing that these kinds of things create problems on large scale development projects with long lifetimes. – JimmyJames Nov 10 '17 at 17:19
  • @JimmyJames hence the "by the way" and parentheses. I'm not the last one to rail against Java, but in all fairness I have used it for some time and have spent most of my time frustratingly bumping into missing stuff that I'm used to, especially references and templates. I don't see how the reference would "break encapsulation" though. A `map` is just a container, why wouldn't I be able to access and modify *my* object that I put in? – Quentin Nov 10 '17 at 17:25
  • @Quentin A map doesn't need to be a container. For example, I can implement a map that has no local memory storage. Perhaps each `put` is sending data to a web service. What would `at()` provide in that implementation? You are assuming a concrete implementation but `Map` is an abstraction. – JimmyJames Nov 10 '17 at 17:34
  • @JimmyJames interesting, I didn't think about that. This could still be done with a proxy object and some operator overloading (did I rant about operator overloading yet? ;)), but this is getting contrived. I think I've largely made my point :) – Quentin Nov 10 '17 at 17:40
  • @Quentin Right, you can support these things but the language becomes more and more complex and that makes it harder to understand. And this is not contrived. I've made Map classes that wrap ResultSet instances or use reflection to call underlying methods on arbitrary objects. It's OK for different languages to have different design philosophies. I like Python but most of the things I like about it I would never want added to Java. – JimmyJames Nov 10 '17 at 18:15
  • @JörgWMittag the original source does not mention any language features, the missing half is not specified however I have elaborated on what that half may have been. – Wes Toleman Nov 11 '17 at 05:20
1

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 :

  • More risks to have bugs due to those unnecessary things.
  • More development cost, managing memory and testing it take time and so money!

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.

Walfrat
  • 3,456
  • 13
  • 26
  • The real cost of multiple inheritance lies in the fact it's not possible to uphold both of the following guarantees: (1) If a member of base-class `B` is overridden in middle class `M`, then `B`'s version of that member will only be accessible through `M`'s override; (2) given any reference of type `T`, converting it to any super-type and back to `T` will yield a reference equivalent to the original. Both of those guarantees are useful, and supporting multiple inheritance would require giving up at least one. – supercat Nov 10 '17 at 18:25
-1

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!

Akumaburn
  • 131
  • 3
  • this doesn't seem to offer anything substantial over points made and explained in prior 5 answers – gnat Nov 09 '17 at 20:45
  • 1
    `They exist not so much to protect the programmer from him/herself, but rather to protect the programmer from other programmers!` or is it to protect other programmers from the programmer? – Tobia Tesan Nov 09 '17 at 21:09
  • @TobiaTesan That too :) – Akumaburn Nov 09 '17 at 21:12