C# and other OOP languages

[tggzzz]

Then let's say that my observation is that Java programmers appear to have above average problems understanding their programming environment (framework) and leave it at that.

Well, you didn't exactly show any above average knowledge of Java with your rather strange claims of Googles own version of Java.

The interesting thing about observations is that you don't need in depth knowledge to make them.

No indeed. But it does help if you want to make valid observations.

And if Google only wrote their own JVM then they probably had a good reason to do so instead of buying it off the shelve from (at that time) Sun.

Well that's correct except for two facts: Google didn't write their own (they bought a company.), and it isn't a JVM (it is much closer to the .NET philosophy)

[IanB]

Code like that example could work perfectly for years, until it suddenly doesn't.

Not really, because in any professional development environment--I mean workplace environment, not software environment--in any professional development environment the compiler flags would be set to catch that bug.

You have a choice. You can use an angle grinder without eye protection, but if you don't, and if you get hot metal in your eye, it's your fault and not the fault of the angle grinder.

[IanB]

Java is sufficiently powerful that it enables ordinary programmers to tackle far more complex problems than are possible in many earlier languages.

I'm rather inclined to disagree with this statement. To suggest that any language is "more powerful" than another is to underestimate the stupidity of ordinary programmers.

An anti-tank gun is more powerful than a BB gun. Which one is more likely to cause damage in untrained hands?

Java was specifically designed to be the BB gun to other language's anti-tank guns. So why on earth would anyone choose to use Java when they want to get a job done?

[miguelvp]

Code like that example could work perfectly for years, until it suddenly doesn't.

Not really, because in any professional development environment--I mean workplace environment, not software environment--in any professional development environment the compiler flags would be set to catch that bug.

You have a choice. You can use an angle grinder without eye protection, but if you don't, and if you get hot metal in your eye, it's your fault and not the fault of the angle grinder.

You are quite right, maximum level warnings and treat warnings as errors is just the beginning in a professional development environment. That code just wouldn't compile

[SirNick]

Code like that example could work perfectly for years, until it suddenly doesn't.

Not really, because in any professional development environment--I mean workplace environment, not software environment--in any professional development environment the compiler flags would be set to catch that bug.

You have a choice. You can use an angle grinder without eye protection, but if you don't, and if you get hot metal in your eye, it's your fault and not the fault of the angle grinder.

I don't know why I'm surprised, but I should learn never to discount the potential for a simple example to get blown out of proportion.

OK, for the sake of everyone's sanity:

1) IT WAS JUST AN EXAMPLE.
2) There was an intentional, stupid, easily preventable bug in the EXAMPLE code.
3) I was trying to illustrate (with an EXAMPLE) how it's possible for the same (user) input to lead down different execution paths, and how this is not necessarily the fault of the language.
4) Yes, you should always enable the most pedantic, obnoxious warnings you possibly can; then use Valgrind to make sure your compiler didn't miss anything; then run it through unit tests; then peer reviews; then static code analysis or whatever it's called; then throw it away and use managed languages, because that's the only thing that's safe.  Oh yeah, EXAMPLE.

Alright.  Are we good now?   

[miguelvp]

I know it was just an example and it was obvious that was your intention, and only meant like that, I was just pointing out that there are many levels to prevent that, including no warning compiles

[zapta]

Code: [Select]

gcc -o test test.c

Code: [Select]

./test
All clear!

Code: [Select]

./test
All clear!

Code: [Select]

./test
All clear!

Code: [Select]

./test
Error -- aborting.
Now, did I just witness an inconsistency in the language?  Or a bug?

Inconsistency? I see a very consistent result in all runs, an undefined outcome per the language's specification.  ;-)

BTW, it's interesting that nobody mentioned yet Go and Scala, these are the next languages on my todo list. Both are used successfully in actual products.

[tggzzz]

Java is sufficiently powerful that it enables ordinary programmers to tackle far more complex problems than are possible in many earlier languages.

I'm rather inclined to disagree with this statement. To suggest that any language is "more powerful" than another is to underestimate the stupidity of ordinary programmers.

The older I get the less I underestimate their stupidity When I started you had to be interested in the subject and relatively intelligent. Nowadays you only need to be interested in making a living, and the mantra is "everybody should be taught how to code".

Such people should be kept away from keyboards, in the same way I should be kept away from javelins and discuses (discusi?).

Java was specifically designed to be the BB gun to other language's anti-tank guns. So why on earth would anyone choose to use Java when they want to get a job done?

Well, it depends on the job, of course. Bad analogy, of course! A better analogy would be Java=car and, for example, C++=track-laying vehicle.

There are no silver bullets, however much salesmen and fanbois claim otherwise. Similarly there are few complete turds. (But if C++ is The Answer, I think The Question ought to be revisited )

When I first used Java (in 1996/1997), I was stunned at the speed with which many usable libraries became available, and the ease with which multiple libraries from multiple sources could be simply bolted into the same application - and "just work". That was something that C++ had failed to achieve in the 10 years it had been around - and arguably is till true to some extent.

Java (and C#) strike a very good balance between rigidity (e.g. you can't cast a horse into a tank), expressivity (e.g. covariance and contravariance), and not having to fight with irrelevancies implementation artefacts (e.g. GC, although you still have to watch out for self-inflicted "data cancer" and a few corner cases). Never underestmate the power of "control-space" in advanced invironments!

Having said that, the unwise overuse of reflection (in the guise of dependency injection) is starting to negate those advantages.

It is the combination of expressivity, extendability and removal of implentation artefacts that makes the Java class environments so powerful - in the sense they enable larger projects and systems to be tackled. Just as procedural HLLs enabled larger systems than assemblers and macrocodes.

[miguelvp]

Of course that's your opinion. I've been using C++  for the last 28 years or so, and not once I found it constraining in any way.

[tggzzz]

Of course that's your opinion. I've been using C++  for the last 28 years or so, and not once I found it constraining in any way.

"Horses for courses", of course, and for some purposes it is the most appropriate technology.

I wouldn't regard C++ as "constraining" any more than C is "constraining". However, IMNSHO, C++ is not as "enabling" as Java/C#/Smalltalk/Objective-C.

[miguelvp]

Enlighten me what those can do to enable me more than C++/11.

[nctnico]

Enlighten me what those can do to enable me more than C++/11.

I'm not quite sure whether  Java/C#/Objective-C are a step up. I do like to take a look a Lua for embedded software at some point. One of the problems I see with C and less with C++ is that you still need to keep track of variables, types, etc. A more protected environment like a script language run as bytecode (like Lua) would allow to concentrate on implementing the 'business logic' of a piece of software instead of having to worry about cleaning up variables and keeping track of memory. When I program in C++ I try to avoid using pointers as much as possible. I have a habit of checking input value ranges on every module's API and/or public members of a class.

[tggzzz]

Enlighten me what those can do to enable me more than C++/11.

I'm not quite sure whether  Java/C#/Objective-C are a step up. I do like to take a look a Lua for embedded software at some point.

I'd be reluctant to consider Java/C# for embedded small systems, despite the claims of the JavaME salesmen. Lua does look attractive in this area.

One of the problems I see with C and less with C++ is that you still need to keep track of variables, types, etc. A more protected environment like a script language run as bytecode (like Lua) would allow to concentrate on implementing the 'business logic' of a piece of software instead of having to worry about cleaning up variables and keeping track of memory. When I program in C++ I try to avoid using pointers as much as possible. I have a habit of checking input value ranges on every module's API and/or public members of a class.

It is difficult to avoid pointers (or the semantic equivalent references) in OOP programming. It is less difficult if you subset C++ so that you are only using ADT style programming, i.e. not far off C-with-classes. But that, of course, will tend to preclude using many useful libraries, forcing re-invention of yet another wheel.

[tggzzz]

Enlighten me what those can do to enable me more than C++/11.

Nothing, in the sense that it is possible to ride a pushbike from Ireland to India. (As did Dervla Murphy in 1963, famously described in her first book "Full Tilt").

But choosing the faster development tools (or transportation) takes up less of your remaining life. Concentrating on implementation artefacts at the expense of the problem you are trying to solve is rarely a good tradeoff. Unless, of course the journey is more important than the destination.

I don't like reinventing wheels. I like solving newer bigger problems. That's what C++ prevents.

(BTW, are there any fully compliant C++11 compilers yet? IIRC it took 5 years for the first full C++98 compiler to appear. I wonder if the first full C++14 implementation will appear before I retire? )

[Wilksey]

I very rarely use C++ for windows dev unless I need cross platform, even then it's via either QT or WX.

Java holds a large place in the developer world with C# rising.

Look at the TIOBE polls (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html).

I use C nearly every day for embedded work, I don't think you will ever find a more popular language for general programming, for nearly every platform if not every platform there is a C compiler.

What I find funny is that 20-30 years ago nearly every machine you bought came with a version of BASIC, and now BASIC is quite low down the food chain (according to the TIOBE list).

I can't say there is a "right or wrong" language to use for a particular job, if you are used to it, i.e. programming in C/C++ for 30 years, your obvious language of choice is going to be C++ unless a very good reason prevents you from using it.

If you find a language that helps you work faster for quick RAD apps (mine is C#) then use it if it is capable of doing the task.

[miguelvp]

But choosing the faster development tools (or transportation) takes up less of your remaining life. Concentrating on implementation artefacts at the expense of the problem you are trying to solve is rarely a good tradeoff. Unless, of course the journey is more important than the destination.

I don't like reinventing wheels. I like solving newer bigger problems. That's what C++ prevents.

(BTW, are there any fully compliant C++11 compilers yet? IIRC it took 5 years for the first full C++98 compiler to appear. I wonder if the first full C++14 implementation will appear before I retire? )

I can't imagine an example that C++11 prevents me from doing, just because you don't know/like or use the language correctly, it doesn't make it a blocker. And yes, there are fully compliant compilers. But of course MS had to add their flavor for use in WRT that expands the language and specially tailored for WRT for their whole .NET, ActiveX, COM etc, that actually is not too bad (I mean the extension they introduced in their implementation). Win8 is a totally different beast, but you know, at least it's finally evolving.

[vvanders]

Enlighten me what those can do to enable me more than C++/11.

I'm not quite sure whether  Java/C#/Objective-C are a step up. I do like to take a look a Lua for embedded software at some point. One of the problems I see with C and less with C++ is that you still need to keep track of variables, types, etc. A more protected environment like a script language run as bytecode (like Lua) would allow to concentrate on implementing the 'business logic' of a piece of software instead of having to worry about cleaning up variables and keeping track of memory. When I program in C++ I try to avoid using pointers as much as possible. I have a habit of checking input value ranges on every module's API and/or public members of a class.

Most of what makes C# a step up is the environment and the rapid UI tools around it.

I've used Lua in embedded-like projects(~16mb total system memory) to great success. It's got a very wide adoption in game dev circles which usually care very much about execution speed and memory footprint.

[ruffy91]

I really like python as an OOP. It's easy to learn and harder to make errors than in other languages. Just to throw in another language in the mix.

[jeremy]

I'll throw my vote in: Python for anything where speed is not critical. Otherwise c++11 or C where that is not available.

Also, while I appreciate it is not for everyone, complaining that you have to manage types and memory in c++ doesn't make much sense. It is no accident and very specifically designed into the language, because it allows the optimiser to do things that would not be possible in a less strongly typed language. In Java, a 32 bit integer requires 192 bits of memory. In c++, a 32 bit integer requires 32 bits of memory. See https://blogs.oracle.com/jrose/entry/fixnums_in_the_vm

If you want to write something that is truly fast (linear algebra operations, real time graphics, JIT compiler, etc), pretty much your only choices are c, c++ or assembly. Often a mix of all three are used. I believe Linus Torvolds said that in some cases he optimises down to the point where he is shuffling instructions so that they enter the pipeline in a better order. That's the sort of performance I'm talking about here. If you give up strong types and manual memory management, you can't have that level of control anymore.

[miguelvp]

Most of what makes C# a step up is the environment and the rapid UI tools around it.

I've used Lua in embedded-like projects(~16mb total system memory) to great success. It's got a very wide adoption in game dev circles which usually care very much about execution speed and memory footprint.

Not sure what game dev circles. Maybe mobile because on consoles it's all C++ and now C++11.

[jeremy]

Most of what makes C# a step up is the environment and the rapid UI tools around it.

I've used Lua in embedded-like projects(~16mb total system memory) to great success. It's got a very wide adoption in game dev circles which usually care very much about execution speed and memory footprint.

Not sure what game dev circles. Maybe mobile because on consoles it's all C++ and now C++11.

Actually, lots of game engines use Lua because it is easily embedded in a C program. The Lua is usually only for the game logic, not the render loop or anything important like that. Cryengine and world of warcraft comes to mind as examples.

[miguelvp]

I guess if a game cycle is 33.333ms you can use that, but at 16.666ms at full 1080p well it's another ballpark when running on systems under $500 worth of BOM.

But I get it that for just the game loops it could be used to drive the actual engine code, then again most studios have their own scripting languages tailored for their specific game.

Just look at PS3/360 games 8 years ago and the last ones using the same hardware. 8 years of code optimization tailored to a specific hardware platform does that.

[_Sin]

Some studios/engines might have a custom domain specific language (with special mention for those utilising a graphical system rather than text-based programming), but these days many are almost certainly using something standard.

Our engine (running a game engine team being my day job!) has been used in about 200 titles so far, and it's written primarily in C++, with bits of asm, scripting in Lua and tools in C#.

[tggzzz]

Most of what makes C# a step up is the environment and the rapid UI tools around it.

This is spot-on, is equally true with Java, and has to be experienced to be believed. It is also a strong reason not to create another crappy domain specific language (DSL).

There is zero possibility that a C++ environment could ever have a decent refactoring browser with "control-space" and "rename this method and all references to this method". Why? Because of the extreme difficulty of accurately parsing C++ source code, particularly when macros (as they always are) are included in the equation.

[tggzzz]

I really like python as an OOP. It's easy to learn and harder to make errors than in other languages.

... except when you copy/paste, get the indentation wrong, and it still compiles perfectly.