Taking a step back, or maybe it's forward?

[Red Squirrel]

That's true it's easier to write a crappy C++ app compared to a crappy managed app.

Though the optimization is another good point. managed apps rely on all sorts of DLLs and junk. In fact I remember coding something in Borland C++, was an entire project for school. i compile the app, bring it to school, ERROR, turned out I needed a crapload of DLLs that came with the compiler. This is the same with MFC and other MS specific apps. You need dependancies (normally the .net framework) for it to run.

A properly coded C++ app won't have many dependancies, if any, making it easy to deploy.

 

[Markbnj]

That is the way of thinking that leads to sloppy, inefficient coding. The mentality that just because we have abundant system resources, we don't need to worry about optimizing the code...just to whatever works and get it done asap. I have a feeling a lot of small applications start out this way, but as they grow the fundamental "laziness" begins to result in code-bloat, which in turn leads to a slow, buggy application that hogs resources unnecessarily.

I just have to disagree with your stereotypes. As someone who has spent hundreds of hours pouring over legacy C/C++ code (on my last job, nearly 3 million lines of it written over 20 years for a huge point of sale system) I have never seen anything to indicate that the use of lower-level languages encourages people to write better code. You might _just_ argue that the harder languages produce better programs because fewer (and better) programmers are equipped to use them, but it just doesn't work out that way in practice.

In actuality, when primitive, generic operations like memory management, string handling, etc., are implemented once by language experts and then reused - taken out of the hands of the average programmer - then what we get is overall much better code, because all those average programmers didn't have to make individual decisions about things that are now standardized. In the Windows world, for example, .NET has resulted in _far_ more robust Windows applications than unmanaged code writing to the Win32 API. That API is still there for the vanishingly small percentage of apps that really can't afford the overhead of garbage collection, or whatever.

I don't mean to jump down your throat personally, but this is an attitude that I find prevalent among young geeks of a certain stripe these days, and it makes me laugh. The idea that harder == better is just a fallacy.

 

[Crusty]

Originally posted by: RedSquirrel
That's true it's easier to write a crappy C++ app compared to a crappy managed app.

Though the optimization is another good point. managed apps rely on all sorts of DLLs and junk. In fact I remember coding something in Borland C++, was an entire project for school. i compile the app, bring it to school, ERROR, turned out I needed a crapload of DLLs that came with the compiler. This is the same with MFC and other MS specific apps. You need dependancies (normally the .net framework) for it to run.

A properly coded C++ app won't have many dependancies, if any, making it easy to deploy.

When you deploy a .NET solution you can package the .NET runtime with the installer, although the default action of an MSI is to not install your solution until all dependencies are installed. Not to mention that .NET is coming pre-installed most of the time these days.

In fact, I find deploying a .NET application very simple and easy, can't say for legacy C++ apps though... not what I do .

Even so, deployment capabilities shouldn't be a concern unless your project is to develop new deployment techniques.

 

[chronodekar]

Originally posted by: Markbnj
The idea that harder == better is just a fallacy.

I can't decide what I think of this. I agree that harder != better. For the mainstream/average programmer, I'd say they are better off in a managed environment or framework.

But, anyone who does go into low-level programming (and sticks with it) should be respected. Usually, those are the guys who KNOW how to bring in efficiency to a program. But more often than not, their UI (user-interface) skills are next to rock bottom.

On the other side, the guys who know how to create good UI's don't really care how things underneath work. BUT, they do know how to get more users to their application!

It's hard to find someone who can do both well. Really hard.


A side note, I work in the embedded field. So we need a lot of low-level guys. For the most part, anything more than that, there are hardware limitations.

 

[Markbnj]

Originally posted by: chronodekar

Originally posted by: Markbnj
The idea that harder == better is just a fallacy.

I can't decide what I think of this. I agree that harder != better. For the mainstream/average programmer, I'd say they are better off in a managed environment or framework.

But, anyone who does go into low-level programming (and sticks with it) should be respected. Usually, those are the guys who KNOW how to bring in efficiency to a program. But more often than not, their UI (user-interface) skills are next to rock bottom.

On the other side, the guys who know how to create good UI's don't really care how things underneath work. BUT, they do know how to get more users to their application!

It's hard to find someone who can do both well. Really hard.


A side note, I work in the embedded field. So we need a lot of low-level guys. For the most part, anything more than that, there are hardware limitations.

In embedded systems the constraints are a friction that pulls the current technology level back a few years, but eventually you'll be writing those applications in managed code too.

It's precisely the same evolutionary path that every technology takes. Pick anything... computer hardware for example. Fifteen years ago we had to set interrupts and IRQs by hand for most of our hardware, in order to get it all to work together smoothly. Sixty years ago the average automobile needed its spark plugs gapped and the points set every ten thousand miles. Twenty years ago Microwave ovens were hit or miss, and now I just tell mine what kind of food I put in it and it comes out perfectly every time.

The more stuff humans have to do to make something work correctly the greater the chance of a screw-up. It's that simple, yet massive force - the cost of forgetting that you wanted metric, not English units for your Mars lander - that drives technology to automate decision-making.

That's all managed code is: automated decision making. None of the programs I have written have ever had anything to do with memory management. They had to manage memory, but that's not what I was trying to accomplish. The need to manage memory opened up this whole vast terrain ripe for mistakes and added nothing at all to the value of what I was doing. Ditto socket I/O, blocked disk reads, mouse and keyboard I/O, graphics output, etc.

I absolutely reject the idea that not having to manage memory makes programmers sloppy, just as I laugh at the idea that having to manage it makes them good. Managed code is every bit as receptive to elegant, optimized implementations, and in fact I would argue that optimizing a multi-tiered managed code application is a lot more complicated than making a blocked DAC I/O loop run fast and tight in 6k of flash memory.

Beware the romance of the past, or before you know it you're this guy with gray hair sitting in the corner of the conference room muttering "These objects are just like structs."

 

[chronodekar]

Originally posted by: Markbnj
Beware the romance of the past,

THAT made me smile. It's not easy to tell when you're making that mistake, but if you have made it, you'll know 3 months from now.

he,he.

Thanks reminding me.

 

[degibson]

Originally posted by: chronodekar
But, anyone who does go into low-level programming (and sticks with it) should be respected. Usually, those are the guys who KNOW how to bring in efficiency to a program. But more often than not, their UI (user-interface) skills are next to rock bottom.

UI? Do you mean argv?

 

[EricMartello]

I never said that "harder = better", but when the bar of entry is too low...so low that "any idiot" can do it, you end up with expected results. Remember how the internet used to be before "any idiot" was able to access it? Before AOL? It's a double-edged sword - ease of use allows people to benefit from technology that would otherwise be inaccessible to them, but at the same time it opens the floodgates for teh stupid.

Are there crappy apps written in C++? YES! I never said that being able to program in C++ automatically makes you a better programmer - but for the individual who is so motivated to improve, C++ will allow that programmer's abilities to grow without the limitations set forth by shared libraries and frameworks.

Frameworks are great for rapid development but the tradeoff is reduced performance and limited scalability...you really have to work within the framework so you are limited as to what you can do.

A good C++ programmer not only has to know how to code, he/she has to know the system the code is being written for. It's like you need to have some understanding of computers from an engineer's perspective to actually be good. A mediocre programmer will produce mediocre code regardless of the language.

 

[Kirby]

Originally posted by: degibson

Originally posted by: chronodekar
But, anyone who does go into low-level programming (and sticks with it) should be respected. Usually, those are the guys who KNOW how to bring in efficiency to a program. But more often than not, their UI (user-interface) skills are next to rock bottom.

UI? Do you mean argv?

:laugh:

:beer:

 

[Markbnj]

I never said that "harder = better", but when the bar of entry is too low...so low that "any idiot" can do it, you end up with expected results.

Well, first I would dispute that the bar is that low... but then I manage to make a living at this, so perhaps it is. But you're just describing what happens when some technology transitions to the mainstream. I remember when almost every person I met on Compuserve was highly intelligent, literate, and for the most part, not anonymous. Now look at the net. So there are more people programming who don't know how. No question about that at all. All you have to do is try to answer questions on the MS forums for an afternoon to see it.

A good C++ programmer not only has to know how to code, he/she has to know the system the code is being written for. It's like you need to have some understanding of computers from an engineer's perspective to actually be good. A mediocre programmer will produce mediocre code regardless of the language.

The system is ancillary to the objectives of the software for all but a very few application domains. Your position is indistinguishable from my desire that every automobile be equipped with a stick shift and manual clutch so that 50% of the idiots will magically disappear from the highway tomorrow . I'm cynically sympathetic to your aims, but you know what? I don't drive a stick anymore, and I readily admit the massive improvements over the last twenty years in vehicles of all types. I used to dream in C++. My copy of the ARM is signed by Bjarne. But now my knees just hurt from clutching in Jersey traffic .

 

[chronodekar]

Originally posted by: nkgreen

Originally posted by: degibson

Originally posted by: chronodekar
But, anyone who does go into low-level programming (and sticks with it) should be respected. Usually, those are the guys who KNOW how to bring in efficiency to a program. But more often than not, their UI (user-interface) skills are next to rock bottom.

UI? Do you mean argv?

:laugh:

:beer:

My first thought was that I was insulted. Then 5 seconds later, I realized what you meant.

But as far as it goes, I think argc skills of a low-level programmer are top notch. (The ones I see often)

But then again, I've seen some really REALLY pathetic implementations, so I guess idiots exist there as well.

Gone are the days when you could judge a good programmer by their skill-set...

-sigh-

 

[tatteredpotato]

Originally posted by: EricMartello
I never said that "harder = better", but when the bar of entry is too low...so low that "any idiot" can do it, you end up with expected results. Remember how the internet used to be before "any idiot" was able to access it? Before AOL? It's a double-edged sword - ease of use allows people to benefit from technology that would otherwise be inaccessible to them, but at the same time it opens the floodgates for teh stupid.

Are there crappy apps written in C++? YES! I never said that being able to program in C++ automatically makes you a better programmer - but for the individual who is so motivated to improve, C++ will allow that programmer's abilities to grow without the limitations set forth by shared libraries and frameworks.

Frameworks are great for rapid development but the tradeoff is reduced performance and limited scalability...you really have to work within the framework so you are limited as to what you can do.

A good C++ programmer not only has to know how to code, he/she has to know the system the code is being written for. It's like you need to have some understanding of computers from an engineer's perspective to actually be good. A mediocre programmer will produce mediocre code regardless of the language.

I do believe the performance hit is growing smaller and smaller as time goes on. Look at what people can do using XNA (Based off the .NET framework and C#).

Could you get a game to look like Gears of War or Halo 3 with managed code? Perhaps not yet, but the way I see it the performance hit from managed code is just going to get smaller.

 

[EricMartello]

Originally posted by: ObscureCaucasian
I do believe the performance hit is growing smaller and smaller as time goes on. Look at what people can do using XNA (Based off the .NET framework and C#).

Could you get a game to look like Gears of War or Halo 3 with managed code? Perhaps not yet, but the way I see it the performance hit from managed code is just going to get smaller.

It's not so much that the performance hit of managed code is being reduced, rather the available hardware is increasing in performance and coming down in price. I have seen some impressive results with C# - which begs the question, how much better could it be if the managed code overhead was reduced or eliminated?

Consider a modern smartphone - many of which have an OS based on Java or use java applications. I have no doubt that my Blackberry would be a lot less "laggy" if the OS and code were better optimized using C or C++ along with ASM specific tothe device. It's like making a car faster by removing weight rather than adding power.

 

[Markbnj]

Originally posted by: EricMartello

Originally posted by: ObscureCaucasian
I do believe the performance hit is growing smaller and smaller as time goes on. Look at what people can do using XNA (Based off the .NET framework and C#).

Could you get a game to look like Gears of War or Halo 3 with managed code? Perhaps not yet, but the way I see it the performance hit from managed code is just going to get smaller.

It's not so much that the performance hit of managed code is being reduced, rather the available hardware is increasing in performance and coming down in price. I have seen some impressive results with C# - which begs the question, how much better could it be if the managed code overhead was reduced or eliminated?

Consider a modern smartphone - many of which have an OS based on Java or use java applications. I have no doubt that my Blackberry would be a lot less "laggy" if the OS and code were better optimized using C or C++ along with ASM specific tothe device. It's like making a car faster by removing weight rather than adding power.

We had an interesting thread a couple of weeks ago that began with functional programming and ended up getting into the whole performance element. For me the bottom line is that there are very few areas in desktop personal computing where we are short of hardware resources. Intel has to come up with a new way to sell chips, so now it's all about scaling out horizontally, which is very hard to do.

Now with mobiles you've hit the nail on the head. The front-wave of the miniaturization wave is very hardware constrained. That's where high-performance code still matters a ton, that and embedded systems... and some aspects of games.