Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
You're wrong: efficiency comes from good algorithm design, not fiddling with the details (UNLESS you're writing low-level code, when C does still have advantages). There's no reason why someone who was `born and raised on Object Oriented [sic] Programming' will not understand algorithm design as well as the next C programmer.
A C programmer who `adopts' C++ may well write awful C++ programs; to use C++ properly requires a different attitude.
It's NOT a simple matter of learning the new syntax.
Until you understand this, you have no hope of writing good C++ programs, and should stick to C.
Re:Can someone give 1 good reason to use C++ over
on
Who's Afraid Of C++?
·
· Score: 1
No, you've misunderstood my (careful) post.
Whatever Linus Torvalds says (and I don't HAVE to follow what he says, just as you don't HAVE to follow what I say!) applied to the Linux kernel.
Now, the Linux kernel is written in C.
C is not C++.
Therefore the comments made by Linus Torvalds do not apply to C++.
(quite apart from the fact that I disagree with them anyway... but they aren't relevant here).
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
I still think you're wrong.:-)
(i) It's NOT a fault of the paradigm, it's a fault of the implementation. There is no reason implicit in the philosophy of object-orientation why a program written in this style should take more space than a proogram written in a convential procedural style.
(ii) The object-orientated approach doesn't by itself lead to sloppy programming. On the contrary, if it's understood and carried out thoughtfully it leads to very elegant and well-written programs. But if someone who still thinks in a convential procedural way comes to an object-orientated language and instantly tries to use the new features without adjusting his mindset, then sloppy programs are likely to result.
But there is nothing intrinsic in the pardigm of object-orientated programming that says this is so.
See my longer post on the subject elsewhere in this thread.
It's RIGHT, because
(i) it's less work for you, giving you more brain-power to deploy on the problem in hand
(ii) it's less work for someone reading your code, giving them some chance of understanding it (oh, the joys of open source software...!)
(iii) it's conceptually preferable, since the type declaration is close to the first use of the variable, and so you can quickly check you aren't using the wrong variable in a certain context
etc. etc... see other post.
If you DON'T make use of this feature when writing C++ code, and insist on calling all local variables i, j or k, then I seriously doubt the veracity of your statement `I can code fairly good C++ code'. Don't forget, C++ isn't just C with extra bits of syntax. It's a different language, requiring a different style of `coding'.
By the way, it's "optimiser" (or at a push "optimizer"), not "optomizer".
(I've chosen to draw a discreet veil over your reference to BASIC)
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
You're right, C++ is fairly hard to learn properly; I don't really think it's terribly suitable for a first language.
I *still* think it's preferable to C, but maybe that's because I too am familiar with it enough to overcome the various `gotchas' you mention.
Incidentally, Haskell is not really hard to learn. It decomposes into various subsets in a very clean way. I wouldn't recommend beginners learn much about monads, for example, or modules, or some of the other more esoteric features. The first six chapters of Richard Bird's book ("Introduction to Functional Programming", Prentice Hall 1998) teach a very rich, very expressive but very syntactically simple subset of the language, which is most beguiling!
I'm sorry - I'm with you all the way on the discrete maths, and that C++ isn't necessarily the best starter language, but this is daft!
If you took your `I don't depend on the optomizer' (sic - it's actually spelt `optimiser', or I suppose `optimizer' if you're from the USA) viewpoint to it's logical conclusion, then you'd write everything in assembly, because any sort of (useful) compiler contains some sort of optimisation.
While that's fun for a while and for small programs (I've hand-writte quite a lot of ARM assembler in my time) it's impractical for anything more.
The optimisers in modern compilers are good. (even the one in GCC!;-) ).
But even this misses the point. The coalescing of local variables is such a fundamental `optimisation' for a C++ compiler that I don't think it can really be considered part of the `optimiser'. Performance without it would probably be fairly atrocious.
Relax, compiler writers aren't out to get you!
As an aside, have you ever written in C++ or used a modern C++ compiler?
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
No, a bunch of experienced C++ programming writing C++ code will produce the best program. Being a C expert is of little benefit when writing C++ - they share some syntax, but have completely different programming paradigms.
So `a bunch of people who don't understand C writing C++ code' may not be a disaster, if that bunch of people are in fact experts at writing C++.:-)
Also, the size issue: 50MB of memory? This DOES NOT HAPPEN any more. Modern implementations of C++ give object code that's about as space efficient as the equivalent C code. (I didn't make this up, read the C++ FAQ for the details, or it could be somewhere on Stroustrup's page).
Re:Can someone give 1 good reason to use C++ over
on
Who's Afraid Of C++?
·
· Score: 1
I can't help feeling you're missing the point.
Using just variables `i,j,k' in a function is NOT a good idea.
Firstly, it requires YOU to carefully manage their use, ie. to ask yourself (and answer) questions like "does variable i have a meaningful value at this point in the code, or can I use it for something new?". I contend that one should not have to deal with these kinds of details when programming; they have absolutely nothing to do with the problem in hand. Moreover of course it leaves you very vulnerable to simple human error (and we've all done it wrong at some point...).
Secondly, the names `i,j,k' give someone reading the code no clue as to what the variables stand for. This may not bother you when you are polishing your implementation of algorithm X, but when someone is reading the code AS A WHOLE it can be extremely disorientating. I'm aware that the general `Linux habit' is to give local variables rather terse names, but generally they give at least some clue as to their utility, if a slightly subliminal one. The names `i,j,k' on the other hand give no clue.
Thirdly, there is no ADVANTAGE to restricting yourself this way. Any half-decent optimising C++ compiler will re-use local variables where possible, so you'll probably end up with exactly the same performance (space and time) as you would if you worried about it all yourself. (Believe me, this is STANDARD fare for compilers - it really is simple). Also, (good) compilers don't make mistakes, and they can spot optimisations that even the most astute human would find elusive.
Fourthly and finally, it is highly advantageous in terms of readability and just plain common sense to have the declaration of a variable near to the first use of that variable. This helps prevent type mistakes, and reminds you again exactly what the purpose of the variable is, without having to look at the beginning of the function (which could be a fair way higher up).
There are advantages of C over C++ for some applications, but this really is not one of them.
Have I convinced you?
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
Incidentally, I don't agree with you that C++ constitutes an `extremely problem-domain tool'; it's just a little further along the road to the problem domain that plain C.
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
Believe me, I KNOW the advantages of a functional approach (as noted lower down in these discussions, I'm a Haskell man at heart!). In an ideal world we'd all be writing pure FP code and none of this would be an issue!
I take all your points about C++, but I don't feel that they really prove my original point to be `nonsense': to some degree, C++ is closer to the problem that C.
(Or perhaps more accurately, C++ allows you to get closer to the problem more easily than does C).
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
I don't really understand what you're talking about here, but what I think you're saying is that you can get the same things done quicker/`better' in [something like] C than you can in [something like] C++.
This may be true for small programs, but it DOES NOT SCALE.
Probably I could implement the FFT algorithm just as easily in C as I could in C++, and it might be subjectively `better' (faster perhaps, but would it be as readable?). However, programs aren't just a string of algorithms; they are in some sense more than the sum of their parts.
Talking about C giving better ways to get to a result than does C++ tends to neglect such considerations of scale and complexity.
So, everyone should start by learning Haskell, and *then* come back to Earth (with only a slight bump) and learn the muckier languages of this mortal coil. It's how we do it here at Oxford.
Learning a pure functional language is a little like taking LSD: you get to see God, and nothing else quite looks the same afterwards.
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
But *ALL* problems should be `problem-domain problems', as you put it. The very expression you used is tautological!
I'm not saying C is bad and C++ is good. They both have applications. What I am saying is that for a clean view of computer programming one should choose a paradigm wherein one can reason effectively in the problem domain. In my opinion, C++ allows one to do this (to some degree) and plain C doesn't (without imagination!).
(NB. Perhaps I should have added a smiling face after my somewhat facetious `buddy' remark. It was intended as a light `Anglo/American' witticism. Perhaps I should try this when I haven't got the 'flu...:-) )
The `hacker mindset' (as you put it) is at best irrelevant, and in my opinion highly undesirable. Programming is just applied mathematics (in the literal sense of the term!). One shouldn't encourage new programmers to just mess around until they `produce programs which should be beyond [their] capabilities'; they should instead be encouraged to study the techniques, reason carefully and learn to walk before they try to run.
I recommend `Introduction to Function Programming' by Richard Bird (Prentice Hall, 1998) as a good beginner text to computer programming, for those with a mathematical bent. *Then* buy and digest K&R, or Stroustrup, or any other language-specific book.
The drawback is that once people have seen the `functional light' (as it were) the prospect of muddying their hands with imperative code becomes highly unattractive!
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
I think the idea is that one shouldn't HAVE to learn `how the computer thinks'. One should be able to program in the `problem domain' rather than the `solution domain', and object-orientated languages such as C++ are a step towards being able to do that.
This is probably just a troll, but I must take issue with the statement "lazy programmers use C++". If you mean "programmers who don't want to have to re-code the same hacky stuff every time they want to use a vaguely interesting data structure", then sure, I'm lazy!
Using C++ for a GUI/desktop project like KDE is natural, as such a project is naturally object-orientated (note spelling!).
In my opinion this is a major advantage of QT over GTK+. The latter is superbly done, but can't get away from the `long-name-syndrome' that besets most attempts to do object-orientated stuff in plain C.
[I should point out, I use Gnome myself. But I'm not blind to its faults].
Your statement about the complexity of the code is total nonsense; it's a well-researched fact that C++ code (for large projects like KDE) is generally easier to maintain and quicker to debug than equivalent C code.
(As I said, it's probably just a troll. But these things are important.)
I've read all the posts, and something ELSE is bothering me.
Why the fuck do people keep writing "(tm)" after the words "good thing"? It isn't FUNNY, I can't particularly see any POINT to it, it doesn't MEAN anything, and I was under the impression that trademarking etc. was unpopular in certain quarters of the `Slashdot' fraternity.
The point is, the `operating system' of a console is usually just a thin layer of abstraction between the game and the support hardware.
The Linux kernel, miniature and neat though it is, would surely be overkill in such a context.
Besides, specialist drivers would be needed for whatever custom hardware is on board, and once these are written then a custom console OS is well within reach.
Having said that, the advent of online gaming and other potential uses for consoles (eg. web browsing/email through your TV) would make a rather better case for using a Linux kernel.
(I'm just waiting for the first `Beowulf' comment...:-) )
Slashdot Mirror
You're wrong: efficiency comes from good algorithm design, not fiddling with the details (UNLESS you're writing low-level code, when C does still have advantages). There's no reason why someone who was `born and raised on Object Oriented [sic] Programming' will not understand algorithm design as well as the next C programmer.
A C programmer who `adopts' C++ may well write awful C++ programs; to use C++ properly requires a different attitude.
It's NOT a simple matter of learning the new syntax.
Until you understand this, you have no hope of writing good C++ programs, and should stick to C.
No, you've misunderstood my (careful) post.
Whatever Linus Torvalds says (and I don't HAVE to follow what he says, just as you don't HAVE to follow what I say!) applied to the Linux kernel.
Now, the Linux kernel is written in C.
C is not C++.
Therefore the comments made by Linus Torvalds do not apply to C++.
(quite apart from the fact that I disagree with them anyway... but they aren't relevant here).
I still think you're wrong. :-)
(i) It's NOT a fault of the paradigm, it's a fault of the implementation. There is no reason implicit in the philosophy of object-orientation why a program written in this style should take more space than a proogram written in a convential procedural style.
(ii) The object-orientated approach doesn't by itself lead to sloppy programming. On the contrary, if it's understood and carried out thoughtfully it leads to very elegant and well-written programs. But if someone who still thinks in a convential procedural way comes to an object-orientated language and instantly tries to use the new features without adjusting his mindset, then sloppy programs are likely to result.
But there is nothing intrinsic in the pardigm of object-orientated programming that says this is so.
But it's not wrong, it's RIGHT!
See my longer post on the subject elsewhere in this thread.
It's RIGHT, because
(i) it's less work for you, giving you more brain-power to deploy on the problem in hand
(ii) it's less work for someone reading your code, giving them some chance of understanding it (oh, the joys of open source software...!)
(iii) it's conceptually preferable, since the type declaration is close to the first use of the variable, and so you can quickly check you aren't using the wrong variable in a certain context
etc. etc... see other post.
If you DON'T make use of this feature when writing C++ code, and insist on calling all local variables i, j or k, then I seriously doubt the veracity of your statement `I can code fairly good C++ code'. Don't forget, C++ isn't just C with extra bits of syntax. It's a different language, requiring a different style of `coding'.
By the way, it's "optimiser" (or at a push "optimizer"), not "optomizer".
(I've chosen to draw a discreet veil over your reference to BASIC)
You're right, C++ is fairly hard to learn properly; I don't really think it's terribly suitable for a first language.
I *still* think it's preferable to C, but maybe that's because I too am familiar with it enough to overcome the various `gotchas' you mention.
Incidentally, Haskell is not really hard to learn. It decomposes into various subsets in a very clean way. I wouldn't recommend beginners learn much about monads, for example, or modules, or some of the other more esoteric features. The first six chapters of Richard Bird's book ("Introduction to Functional Programming", Prentice Hall 1998) teach a very rich, very expressive but very syntactically simple subset of the language, which is most beguiling!
LISP isn't an OOP. It's an impure functional language. :-)
I'm sorry - I'm with you all the way on the discrete maths, and that C++ isn't necessarily the best starter language, but this is daft!
;-) ).
If you took your `I don't depend on the optomizer' (sic - it's actually spelt `optimiser', or I suppose `optimizer' if you're from the USA) viewpoint to it's logical conclusion, then you'd write everything in assembly, because any sort of (useful) compiler contains some sort of optimisation.
While that's fun for a while and for small programs (I've hand-writte quite a lot of ARM assembler in my time) it's impractical for anything more.
The optimisers in modern compilers are good.
(even the one in GCC!
But even this misses the point. The coalescing of local variables is such a fundamental `optimisation' for a C++ compiler that I don't think it can really be considered part of the `optimiser'. Performance without it would probably be fairly atrocious.
Relax, compiler writers aren't out to get you!
As an aside, have you ever written in C++ or used a modern C++ compiler?
No, a bunch of experienced C++ programming writing C++ code will produce the best program. Being a C expert is of little benefit when writing C++ - they share some syntax, but have completely different programming paradigms.
:-)
So `a bunch of people who don't understand C writing C++ code' may not be a disaster, if that bunch of people are in fact experts at writing C++.
Also, the size issue: 50MB of memory? This DOES NOT HAPPEN any more. Modern implementations of C++ give object code that's about as space efficient as the equivalent C code. (I didn't make this up, read the C++ FAQ for the details, or it could be somewhere on Stroustrup's page).
I can't help feeling you're missing the point.
Using just variables `i,j,k' in a function is NOT a good idea.
Firstly, it requires YOU to carefully manage their use, ie. to ask yourself (and answer) questions like "does variable i have a meaningful value at this point in the code, or can I use it for something new?". I contend that one should not have to deal with these kinds of details when programming; they have absolutely nothing to do with the problem in hand. Moreover of course it leaves you very vulnerable to simple human error (and we've all done it wrong at some point...).
Secondly, the names `i,j,k' give someone reading the code no clue as to what the variables stand for. This may not bother you when you are polishing your implementation of algorithm X, but when someone is reading the code AS A WHOLE it can be extremely disorientating. I'm aware that the general `Linux habit' is to give local variables rather terse names, but generally they give at least some clue as to their utility, if a slightly subliminal one. The names `i,j,k' on the other hand give no clue.
Thirdly, there is no ADVANTAGE to restricting yourself this way. Any half-decent optimising C++ compiler will re-use local variables where possible, so you'll probably end up with exactly the same performance (space and time) as you would if you worried about it all yourself. (Believe me, this is STANDARD fare for compilers - it really is simple). Also, (good) compilers don't make mistakes, and they can spot optimisations that even the most astute human would find elusive.
Fourthly and finally, it is highly advantageous in terms of readability and just plain common sense to have the declaration of a variable near to the first use of that variable. This helps prevent type mistakes, and reminds you again exactly what the purpose of the variable is, without having to look at the beginning of the function (which could be a fair way higher up).
There are advantages of C over C++ for some applications, but this really is not one of them.
Have I convinced you?
Incidentally, I don't agree with you that C++ constitutes an `extremely problem-domain tool'; it's just a little further along the road to the problem domain that plain C.
Believe me, I KNOW the advantages of a functional approach (as noted lower down in these discussions, I'm a Haskell man at heart!). In an ideal world we'd all be writing pure FP code and none of this would be an issue!
I take all your points about C++, but I don't feel that they really prove my original point to be `nonsense': to some degree, C++ is closer to the problem that C.
(Or perhaps more accurately, C++ allows you to get closer to the problem more easily than does C).
I don't really understand what you're talking about here, but what I think you're saying is that you can get the same things done quicker/`better' in [something like] C than you can in [something like] C++.
This may be true for small programs, but it DOES NOT SCALE.
Probably I could implement the FFT algorithm just as easily in C as I could in C++, and it might be subjectively `better' (faster perhaps, but would it be as readable?). However, programs aren't just a string of algorithms; they are in some sense more than the sum of their parts.
Talking about C giving better ways to get to a result than does C++ tends to neglect such considerations of scale and complexity.
Quite right.
So, everyone should start by learning Haskell, and *then* come back to Earth (with only a slight bump) and learn the muckier languages of this mortal coil. It's how we do it here at Oxford.
Learning a pure functional language is a little like taking LSD: you get to see God, and nothing else quite looks the same afterwards.
But *ALL* problems should be `problem-domain problems', as you put it. The very expression you used is tautological!
:-) )
I'm not saying C is bad and C++ is good. They both have applications. What I am saying is that for a clean view of computer programming one should choose a paradigm wherein one can reason effectively in the problem domain. In my opinion, C++ allows one to do this (to some degree) and plain C doesn't (without imagination!).
(NB. Perhaps I should have added a smiling face after my somewhat facetious `buddy' remark. It was intended as a light `Anglo/American' witticism. Perhaps I should try this when I haven't got the 'flu...
The `hacker mindset' (as you put it) is at best irrelevant, and in my opinion highly undesirable. Programming is just applied mathematics (in the literal sense of the term!). One shouldn't encourage new programmers to just mess around until they `produce programs which should be beyond [their] capabilities'; they should instead be encouraged to study the techniques, reason carefully and learn to walk before they try to run.
I recommend `Introduction to Function Programming' by Richard Bird (Prentice Hall, 1998) as a good beginner text to computer programming, for those with a mathematical bent. *Then* buy and digest K&R, or Stroustrup, or any other language-specific book.
The drawback is that once people have seen the `functional light' (as it were) the prospect of muddying their hands with imperative code becomes highly unattractive!
I think the idea is that one shouldn't HAVE to learn `how the computer thinks'. One should be able to program in the `problem domain' rather than the `solution domain', and object-orientated languages such as C++ are a step towards being able to do that.
And don't call me `buddy'.
Does he mean "queues" when he says "lines"?
What on earth has this got to do with anything?
This is probably just a troll, but I must take issue with the statement "lazy programmers use C++". If you mean "programmers who don't want to have to re-code the same hacky stuff every time they want to use a vaguely interesting data structure", then sure, I'm lazy!
Using C++ for a GUI/desktop project like KDE is natural, as such a project is naturally object-orientated (note spelling!).
In my opinion this is a major advantage of QT over GTK+. The latter is superbly done, but can't get away from the `long-name-syndrome' that besets most attempts to do object-orientated stuff in plain C.
[I should point out, I use Gnome myself. But I'm not blind to its faults].
Your statement about the complexity of the code is total nonsense; it's a well-researched fact that C++ code (for large projects like KDE) is generally easier to maintain and quicker to debug than equivalent C code.
(As I said, it's probably just a troll. But these things are important.)
I've read all the posts, and something ELSE is bothering me.
Why the fuck do people keep writing "(tm)" after the words "good thing"? It isn't FUNNY, I can't particularly see any POINT to it, it doesn't MEAN anything, and I was under the impression that trademarking etc. was unpopular in certain quarters of the `Slashdot' fraternity.
So... why do it?
Why do it?
The point is, the `operating system' of a console
:-) )
is usually just a thin layer of abstraction between the game and the support hardware.
The Linux kernel, miniature and neat though it is,
would surely be overkill in such a context.
Besides, specialist drivers would be needed for
whatever custom hardware is on board, and once these are written then a custom console OS is well within reach.
Having said that, the advent of online gaming and other potential uses for consoles (eg. web browsing/email through your TV) would make a rather better case for using a Linux kernel.
(I'm just waiting for the first `Beowulf' comment...
Just how does this `company' plan to make money?
Will they email the companies saying "at least
one of your links is down; send us a cheque for
x00000 pounds and we'll tell you which"?
Just how?
The ARM chip has the most beautiful instruction set known to man - it really is breathtaking.
All those twats who said writing assembler on a RISC chip was `too hard' (babies) should try coding for the ARM. It's an absolute pleasure.
It's a pleasure.