I would be careful with that. As hardware becomes better and better, it also becomes a good platform for solving ever more complex problems.Originally Posted by sept
Besides,... we aren't forced to use fast programming languages today already. As we weren't 20 years ago or 30 years ago.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
One thing that is often forgotten is that 90% of the time is spent in 10% of the code. This isn't ALWAYS true, but I've seen LOTS of code, and it holds true for a large share of the code I've looked at.
This doesn't necessarily mean that the other 90% isn't worth optimizing, but it's also likely that if the 90% takes twice as long, it won't really make a whole lot of difference.
Of course, 10% of 1 million lines of code is still 100000 lines of code, so may not be so easy to optimize. But in such a large project, it's likely that within those 100000 lines, 10% are responsible for 90% of the execution time, and those 10000 lines shouldn't be too difficult to make run faster if they are written in a RAD language, simply by rewriting those to a more optimized language, such as C or Assembler.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
80/20 are the typically cited numbers. The famous 80/20 rule: 80% of the time spent in 20% of the code, 80% of the bugs in 20% of the code, 80% of the time taken by 20% of the project, and so on.
Or this variant.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
priceless!
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
That is less about the difficulty of the language and more about using the right tool for the job.
Hard concepts don't make for a hard language IMO. Some of the concepts I had to learn for Prolog and Lisp were difficult to put my head around, but that doesn't mean either language was difficult. Heck I know (and tutored) people who thought that the concepts in basic algebra was hard, that doesn't make the math language hard (at least at that level).Also compared to other languages, C/C++ is also very difficult due to the low level, such as pointers, arrays, bounds, etc, etc. Some may have trouble grasping it, but I agree with you that once you get to know it, it's not a difficult language itself.
OMG that was great. Reminded me of:
Kirk: "How long to re-fit?"
Scotty: "Eight weeks. But you don't have eight weeks, so I'll do it for you in two."
Kirk: "Do you always multiply your repair estimates by a factor of four?"
Scotty: "How else to maintain my reputation as a miracle worker?"
Kirk: "Your reputation is safe with me."
But however you look at it, it would seem that all tools for C/C++ is hard to use for GUI programming (unless you count frameworks such as .NET which is technically made from C++). So whatever you do, when using C/C++ to make GUI, you're going to have a hard time, which makes the language difficult to use.
But then again, it's not he language's fault, but the approach that is difficult.
It doesn't really matter what we do, if we do create GUI with C or C++, it will be hard. Which is kindof my point. I don't know how to explain it better... When doing GUI, perhaps another tool is a better choice for the job, as you say.
Absolutely. If, for one, do not find C++ difficult. But to newbies, the language can be seen as difficult. And RAD tools are easier, though that doesn't mean C/C++ is hard.Hard concepts don't make for a hard language IMO. Some of the concepts I had to learn for Prolog and Lisp were difficult to put my head around, but that doesn't mean either language was difficult. Heck I know (and tutored) people who thought that the concepts in basic algebra was hard, that doesn't make the math language hard (at least at that level).
Of course the percentage of processors running a GUI is really low so IMO the GUI arguement is junk.
Heh. There are a few other things that can be a pain, but just basic language isn't difficult.
Never saw a good GUI that wasn't hard to create, no matter the language. I despise GUI programming.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
C++ is not that hard really. It's the const qualifier that is.
Anyways, the complexity of developing for a GUI under C++ is only noticeable when doing straight Win32 programming. But this is not because of the language. It's because the Win32 API is, at the lack of a better word... complicated.
MFC helped but still not that much. 3rd party vendors like Borland and Open Source projects like wxWidgets did IMO a much better job at encapsulating that nightmarish API. My experience with Borland's VCL is limited so I may be disputed on this, which will be fine.
Regardless, apart from the const qualifier, I find C++ concepts easy to grasp, its logic makes sense and it's actually easy to learn. If anything, just an hard language to master.
EDIT: hmm... guess I misunderstood the earlier posts. Seems you fine people are talking of coding a GUI, not coding for a GUI
Last edited by Mario F.; 02-26-2008 at 09:54 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
You mean you find the concept of a volatile static const variable difficult to understand? pfft
Actually, I find it kind of hard to understand why you would make a variable (as opposed to a pointee type) const and volatile, yeah.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Ehm, well, that's not really true. I don't know if I should separate them, though. Coding a GUI and coding for a GUI can both be a pain in C/C++ since there really is no excellent and terrific GUI to do it for you.
You have a signal that is coming from an outside source that can change. So you need volatile so that the compiler doesn't optimize it into registers. However, your section of the program must not change the value. So you make it const.
That is just scary.
But really, const could really run circles around my mind. It was, for me, the hardest concept to understand in C++. Not so much the principle, which is rather - as with all complicated things - simple. It was the implications and the whole new world of const correctness.
Ironically, I only started understanding const and const correctness when I started using const everywhere. I followed the advise of Prelude, I think (can't recall exactly) which went something like this; Fight the beast and const everything. Said and done. Shortly after my sig was born.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
