Is Programming Becoming a Lost Art?
closed account (3hM2Nwbp)
| I don't like languages that do things implicitly (such as garbage collection). |
Agreed, 110%. It's nice to have the option to have such things available, but it's not a good thing to have such things forced on with an angry mob that's ready to lynch you for not following their (sometimes flawed) ways1.
1 - Java
| Pointers are really a super basic thing, which you can learn in about 10 minutes. Memory allocation, is pretty simple as well |
I think the problem is that many programmers don't know, and sometimes don't even care about the low level concepts. I've seen this a lot. The angry mob dictates to them that it's both bad and dangerous to even think about pointers or memory manipulation.
Last edited on
| It's not that. It's the path C++ is taking, is what I dislike. The reason why I'm drifting back to C is because C is so much simpler, not simple as in easy to use, but as in less overhead on common operations. |
A week ago I started a forum that kind of offends C++11, calling it's newly added syntax complicated, obscene, and simply not C++. Some people were offended by that.
I happy to see and experienced and dedicated programmer (something I am not) prefer the simplicity of C over the youngest children of C++!
This is kind of a harsh reply Framework. Please don't take any of this personally. I just can't help but make some observations here...
I don't know why you think that. If you think programming in C# is easy (or at least easier than C), then you must never have programmed in C#.
Scripting languages like Python are going to be a little easier because they're scripting languages... which by their very nature makes them "quick 'n' dirty".
As for whether or not programming is considered an artform, I guess that depends on the person. But I don't know why you'd think people who considered it art before would no longer consider it art now. That seems to be a rather pointless (and bogus) claim.
It's stuff like this that makes me have an extremely hard time taking anything this guy says seriously. Think about what he just said there, and how it makes absolutely zero sense. He's citing the userbase of a language as a reason why the language is poor.
When it comes down to it, Linus is just a C fanboy, and his arguments are paramount to "C is the best, if you like another language more then you are stupid". In a sense he's kind of like C's answer to Bjarne Stroustrup (the often over-quoted C++ fanboy), although IMO Linus is much more childish in his oratories.
I wouldn't take anything this guy says at face value. He is clearly biased to the point where it has blinded him.
That's an arbitrary opinion. All languages do things implicitly. How much implicit automation is the real question here. C++ draws its line a little more on the low-level end of the spectrum than Java does. C draws its line even lower. But they all draw it somewhere.
There are arguments for and against this automation, and both have many valid points. There is no right or wrong answer. The right language for the job depends on many factors... including the team being used.
The syntax is questionable, sure. But the functionality they offer is insanely awesome.
Personally I don't mind the syntax so much. But I can see why so many people think it's ugly.
I'm not sure I understand what you're saying here. If a constructor is not needed for a class, then don't write one for the class. Then there's nothing to call and therefore no overhead.
I see. So you think that before anyone can write any program, they must have full knowledge of how their system architecture, OS, compiler, and runtime libraries all work.
You are starting to sound a lot like Linus. Do you realize that if that really were the case, then nothing would ever get done?
Besides... what do you care about what other programmers do? Do you have to work with sub-standard programmers? If no, then lighten up. If yes, then that's mainly the fault of your employer for doing a lousy job hiring people.
You SHOULD let the compiler optimize for you. Premature optimizations (ie: trying to optimize because you don't think the compiler will do a good enough job) often lead to slower code because you butt heads with the compiler.
Of course you can always turn compiler optimizations off and then rely on your own optimizations alone. But if you do any kind of performance benchmarking you'll quickly see how foolish that is.
If they're unwanted, don't use them.
If they're wanted, the overhead is unavoidable. The C equivilents to ctors (init functions), dtors (destroy functions), and virtual functions (function pointers) are not any faster.
You're basically faulting a language for having too many tools just because you don't know how to effectively use them all.
I'm not surprised. You seem to be one of those "If I didn't write it, it's crap" guys. I used to be like that too. I understand the mentality.
I'm sure Linus is that way too.
Eventually I realized I was wrong. I realized that there were other good programmers out there. It also dawned on me that it was pointless to spend a week writing code for a mundane task that somebody already wrote a lib for. What's more, the lib they wrote was thoroughly tested and proven to work, has more functionality than what I had originally envisioned, is available for more platforms than I would be able to test for, etc.
Also, FWIW, in the professional world you have to get used to using other people's code. And it's sometimes in even worse shape and much harder to understand than most common libraries (except for maybe boost -- that lib is a clusterf$@# -- although it's extremely powerful once you figure it out).
Being adaptable and learning to create with the tools you're given -- that is the art of programming.
I have to ask....
1) What was the largest project you ever worked on?
2) What was the largest team you've ever worked with?
3) How many projects have you worked on where the needs drastically changed halfway through?
Design patterns are huge when you're talking about communication between team members (past, present, and future), and also long term development and maintainability of a program.
To dismiss design patterns because they "get in the way" just gives me the impression that your code is going to be a wretched mess, and that you've never worked on any moderate-to-large sized projects [successfully].
I'm less and less surprised that you prefer C. I'm not saying C is a bad language, but it generally allows/encourages you to write sloppier code.
Pot calling the kettle black. Do you know how a compiler does things? Ever written a compiler? Did you take compiler theory in college (yes that's an actual field of study)?
The whole point of using a high level language like C (read: C, not just C++), is so you are removed from the architecture. You should not be relying on any one specific architecture because that makes your code not portable.
If you want a language that demands you be familiar with the current architecture, you want assembly.
Of course, coding in assembly is less automated, and more difficult. But that's what you're saying you want, right?
| Framework wrote: |
|---|
| I've noticed that every language that's released is making the programming field become more, and more easier, to the point where it's no longer considered an art. |
I don't know why you think that. If you think programming in C# is easy (or at least easier than C), then you must never have programmed in C#.
Scripting languages like Python are going to be a little easier because they're scripting languages... which by their very nature makes them "quick 'n' dirty".
As for whether or not programming is considered an artform, I guess that depends on the person. But I don't know why you'd think people who considered it art before would no longer consider it art now. That seems to be a rather pointless (and bogus) claim.
| Linus wrote: |
|---|
| "It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it." |
It's stuff like this that makes me have an extremely hard time taking anything this guy says seriously. Think about what he just said there, and how it makes absolutely zero sense. He's citing the userbase of a language as a reason why the language is poor.
When it comes down to it, Linus is just a C fanboy, and his arguments are paramount to "C is the best, if you like another language more then you are stupid". In a sense he's kind of like C's answer to Bjarne Stroustrup (the often over-quoted C++ fanboy), although IMO Linus is much more childish in his oratories.
I wouldn't take anything this guy says at face value. He is clearly biased to the point where it has blinded him.
| I don't like languages that do things implicitly (such as garbage collection). |
That's an arbitrary opinion. All languages do things implicitly. How much implicit automation is the real question here. C++ draws its line a little more on the low-level end of the spectrum than Java does. C draws its line even lower. But they all draw it somewhere.
There are arguments for and against this automation, and both have many valid points. There is no right or wrong answer. The right language for the job depends on many factors... including the team being used.
| By the way, C++11's lambada expressions are terrible, but that's my opinion. |
The syntax is questionable, sure. But the functionality they offer is insanely awesome.
Personally I don't mind the syntax so much. But I can see why so many people think it's ugly.
| as in less overhead on common operations. For example, C++'s constructors are sometimes unnecessary, as are the destructors, but they get called anyway |
I'm not sure I understand what you're saying here. If a constructor is not needed for a class, then don't write one for the class. Then there's nothing to call and therefore no overhead.
| What bugs me the most is that most new programmers don't even care how a language does things, they just want it done. That's where the art factor fades. |
I see. So you think that before anyone can write any program, they must have full knowledge of how their system architecture, OS, compiler, and runtime libraries all work.
You are starting to sound a lot like Linus. Do you realize that if that really were the case, then nothing would ever get done?
Besides... what do you care about what other programmers do? Do you have to work with sub-standard programmers? If no, then lighten up. If yes, then that's mainly the fault of your employer for doing a lousy job hiring people.
| "I let the compiler optimise my code for me, so I don't have to do it." |
You SHOULD let the compiler optimize for you. Premature optimizations (ie: trying to optimize because you don't think the compiler will do a good enough job) often lead to slower code because you butt heads with the compiler.
Of course you can always turn compiler optimizations off and then rely on your own optimizations alone. But if you do any kind of performance benchmarking you'll quickly see how foolish that is.
| I disagree. C++ has features that are coupled with performance overheads. Features like virtual functions, and ctors & dtors suffer from some unwanted overhead. |
If they're unwanted, don't use them.
If they're wanted, the overhead is unavoidable. The C equivilents to ctors (init functions), dtors (destroy functions), and virtual functions (function pointers) are not any faster.
You're basically faulting a language for having too many tools just because you don't know how to effectively use them all.
| That's the thing; I have a major resistance to pre-built libraries. Every time I try to use a library, I get annoyed with it and end up removing it. |
I'm not surprised. You seem to be one of those "If I didn't write it, it's crap" guys. I used to be like that too. I understand the mentality.
I'm sure Linus is that way too.
Eventually I realized I was wrong. I realized that there were other good programmers out there. It also dawned on me that it was pointless to spend a week writing code for a mundane task that somebody already wrote a lib for. What's more, the lib they wrote was thoroughly tested and proven to work, has more functionality than what I had originally envisioned, is available for more platforms than I would be able to test for, etc.
Also, FWIW, in the professional world you have to get used to using other people's code. And it's sometimes in even worse shape and much harder to understand than most common libraries (except for maybe boost -- that lib is a clusterf$@# -- although it's extremely powerful once you figure it out).
Being adaptable and learning to create with the tools you're given -- that is the art of programming.
| I find that most of these "concepts" simply get in the way, and create more unnecessary work |
I have to ask....
1) What was the largest project you ever worked on?
2) What was the largest team you've ever worked with?
3) How many projects have you worked on where the needs drastically changed halfway through?
Design patterns are huge when you're talking about communication between team members (past, present, and future), and also long term development and maintainability of a program.
To dismiss design patterns because they "get in the way" just gives me the impression that your code is going to be a wretched mess, and that you've never worked on any moderate-to-large sized projects [successfully].
I'm less and less surprised that you prefer C. I'm not saying C is a bad language, but it generally allows/encourages you to write sloppier code.
| Programmers should be learning how the compiler does things, and not passing it by without a second thought. |
Pot calling the kettle black. Do you know how a compiler does things? Ever written a compiler? Did you take compiler theory in college (yes that's an actual field of study)?
| Knowing the architecture is what programming is all about, in my opinion |
The whole point of using a high level language like C (read: C, not just C++), is so you are removed from the architecture. You should not be relying on any one specific architecture because that makes your code not portable.
If you want a language that demands you be familiar with the current architecture, you want assembly.
Of course, coding in assembly is less automated, and more difficult. But that's what you're saying you want, right?
Last edited on
@Framework:
It seems to me that your beef with higher level languages is that they don't require you to manually clean up. You said a lot about garbage collection and ctors/dtors, but I didn't really notice any other specific points on the topic... just a lot of conjecture.
So if that's the case let me try to put this in perspective.
1) Cleanup is not optional.. not even in C.
Every malloc must have a matching free or you get a memory leak, right? So what difference does it make if you manually put the free() in there, or if the compiler/garbage collector automatically does it when the object no longer exists?
Doing it manually doesn't magically make it faster. It just makes it easier to screw up/forget.
2) Cleanup is a small fraction of programming
How much time do you spend actually writing cleanup code? I'm guessing it's not very much.
So you are claiming that C# is "easier" and by extension "less artful" than C because you don't have to type
Considering the infrequency of cleanup code... can you see how ridiculous that sounds?
It seems to me that your beef with higher level languages is that they don't require you to manually clean up. You said a lot about garbage collection and ctors/dtors, but I didn't really notice any other specific points on the topic... just a lot of conjecture.
So if that's the case let me try to put this in perspective.
1) Cleanup is not optional.. not even in C.
Every malloc must have a matching free or you get a memory leak, right? So what difference does it make if you manually put the free() in there, or if the compiler/garbage collector automatically does it when the object no longer exists?
Doing it manually doesn't magically make it faster. It just makes it easier to screw up/forget.
2) Cleanup is a small fraction of programming
How much time do you spend actually writing cleanup code? I'm guessing it's not very much.
So you are claiming that C# is "easier" and by extension "less artful" than C because you don't have to type
free(ptr)? Is that about the jist of it?Considering the infrequency of cleanup code... can you see how ridiculous that sounds?
Last edited on
closed account (3hM2Nwbp)
Can't help but interject here but...
I've had to recode a particular system from Java to C++ where a garbage collector paused the application's business logic for ~15 seconds when it reached a critical point in its execution. Current garbage collection technologies aren't a viable solution for large scale real-time applications...at least not yet.
*Case in point:
Manual resource cleanup doesn't necessarily make if faster...but at least you have some predictability.
On another note: Since object cleanup is not predictable with a garbage collector, clean-up methods that should run during destruction / finalization / whatever you want to call it must be ran explicitly when the object's lifetime logically ends, rather than implicitly, when its lifetime actually ends. That's a whole 'nother can of worms... Ah what am I talking about? Java programmers would call explicit cleanup at an object's lifetime's end a bad design and club you on the head for it.
| So what difference does it make if you manually put the free() in there, or if the compiler/garbage collector automatically does it when the object no longer exists? |
I've had to recode a particular system from Java to C++ where a garbage collector paused the application's business logic for ~15 seconds when it reached a critical point in its execution. Current garbage collection technologies aren't a viable solution for large scale real-time applications...at least not yet.
*Case in point:
Manual resource cleanup doesn't necessarily make if faster...but at least you have some predictability.
On another note: Since object cleanup is not predictable with a garbage collector, clean-up methods that should run during destruction / finalization / whatever you want to call it must be ran explicitly when the object's lifetime logically ends, rather than implicitly, when its lifetime actually ends. That's a whole 'nother can of worms... Ah what am I talking about? Java programmers would call explicit cleanup at an object's lifetime's end a bad design and club you on the head for it.
Last edited on
No, just another thing showing how lazy the world is becoming. We are wanting things that do everything for us so we can get quick results with little work and programming is just following suit. I mean, compare programming now to what it was in its infancy. Programmers had to create, allocate, and release memory and now languages are getting so you do the first and it releases the memory for you. I'd venture a guess that if programmers still had to code in binary or assembly only that there would be a lot less programmers now than there are. :(
Last edited on by closed account z6A9GNh0
| When it comes down to it, Linus is just a C fanboy |
As an aside, he isn't even that, just read his opinions on pointer aliasing. He's a fan of "portable assembly" kind of C (somewhat understandingly, since that's what the linux kernel requires)
@ Luc Lieber:
You are correct. That's actually one of the reasons I don't like GC either.
So maybe my statement does not apply to GC, but it should still apply to the concept of a C++ destructor.
I never understood this mentality.
If you are talking about individual lives (ie: people not wanting to work, but rather spending time at home)... DUH. Preference to live life is not laziness, it's normal. You don't live for your work, you work to live. People who have it the other way around are kind of screwed up in the head.
And if you are talking about work productivity... then on what planet is taking extra time to do needlessly more (and more error prone) work considered more favorable than getting the job done more quickly and with fewer mistakes?
For example... at my current job, there are times when a common task needs to be done on a large data set. One such instance of this was I had to build a series of XML files for a certain product based on specifications given to me in a formatted text file. Manually generating the XML by hand was one option, but I chose to write a tool so it would be automated. Does that make me lazy?
Then other people I worked with had to do the same task so I gave them a copy of my tool. Does that make them lazy?
Also, I wrote the tool in a high level language with a lot of preexisting libs and compiler automation instead of doing it all "myself". Does that make me lazy?
If you said "yes" to any of the above... virtually every employer in the world would disagree with you.
Don't confuse "doing things the easy way" with "laziness". They are two very different concepts.
Your point? Why is that better than how it is now?
You're right. That would really suck, wouldn't it? We'd have like 1/1000th of the software available to us as we do now... and hardware probably would not be anywhere near as capable either. We'd probably all still be using Apple ]['s or something.
I'm sure glad the world isn't like that.
You are correct. That's actually one of the reasons I don't like GC either.
So maybe my statement does not apply to GC, but it should still apply to the concept of a C++ destructor.
| BHXSpecter wrote: |
|---|
| No, just another thing showing how lazy the world is becoming. We are wanting things that do everything for us so we can get quick results with little work and programming is just following suit. |
I never understood this mentality.
If you are talking about individual lives (ie: people not wanting to work, but rather spending time at home)... DUH. Preference to live life is not laziness, it's normal. You don't live for your work, you work to live. People who have it the other way around are kind of screwed up in the head.
And if you are talking about work productivity... then on what planet is taking extra time to do needlessly more (and more error prone) work considered more favorable than getting the job done more quickly and with fewer mistakes?
For example... at my current job, there are times when a common task needs to be done on a large data set. One such instance of this was I had to build a series of XML files for a certain product based on specifications given to me in a formatted text file. Manually generating the XML by hand was one option, but I chose to write a tool so it would be automated. Does that make me lazy?
Then other people I worked with had to do the same task so I gave them a copy of my tool. Does that make them lazy?
Also, I wrote the tool in a high level language with a lot of preexisting libs and compiler automation instead of doing it all "myself". Does that make me lazy?
If you said "yes" to any of the above... virtually every employer in the world would disagree with you.
Don't confuse "doing things the easy way" with "laziness". They are two very different concepts.
| Programmers had to create, allocate, and release memory and now languages are getting so you do the first and it releases the memory for you. |
Your point? Why is that better than how it is now?
| I'd venture a guess that if programmers still had to code in binary or assembly only that there would be a lot less programmers now than there are. :( |
You're right. That would really suck, wouldn't it? We'd have like 1/1000th of the software available to us as we do now... and hardware probably would not be anywhere near as capable either. We'd probably all still be using Apple ]['s or something.
I'm sure glad the world isn't like that.
Last edited on
If you don't want to take advantage of the features that are there, simply don't use them. If you think all of the features in a language are bloated and add excessive overhead, then don't use the language. Move down to assembly. Program how you want to.
Nothing forces you to use a language that was designed to take the backend off of the programmers should so they can explicitly focus on designing their applications.
Compare a simple calculator in C++ to Assembly (I know next to nothing about Assembly). You must code in every single jump. The code in Assembly can become fairly large just to do something simple. Now, add the features of a very simple scientific calculator in there. Add features to have the calculator solve for a variable. What begins to happen to the Assembly code? It becomes more and more unreadable (I already believe it's unreadable to begin with), constantly having jumps in and out, while the C++ code still looks just as elegant as it did in the simple version. Now add a GUI...
Case in point, if you don't want features in a certain language, don't use them. If you think the language is filled with nonsense, then switch languages (that's why I moved away from JAVA).
Programming is, and always will be an art form. Compare programming as a hobby to hobby artists. Look at the different forms of art that any artists can create. Most of us would say, hey, that's not art, he just put a soda can on his dogs head and took a picture, but to other's that is some of the best art there is. Now move that logic over to the programming aspect. I believe that anyone who can program in Assembly (and create something wonderful) is an artist, but that doesn't mean someone can't do the same thing in JAVA, C, C++, C#, LISP, etc. You take the tools you're given and make your program your own. Be happy with what you've created.
I will be the first to admit, I look up to most of your guys. I have been following this thread since Framework started it. I agree and disagree with a lot of the comments that were said, but those are my opinions. I still look at programming as being something you should enjoy. If you really enjoy it, you'll expand your knowledge like I have. You'll constantly be looking for WTFs in the language, WOWs, and Ohhhs. It's part of the learning process. And if any one of you believe you are done learning, you really don't know what programming is about.
Sorry for the rant, but I feel that the fighting is better served teaching rather than arguing semantics with each other. Enlighten us with why specifically you think that garbage collectors are bad (like BHXSpecter did) englighten us as to why you think C++ is a worse C, not a better C. Explain to the other person what C++ offers over C, how the type checking alone in C++ makes it worth using over C, not to mention the OOP structure of the language, the added features, and cleverly masked workarounds to poor C coding techniques.
You guys are extremely brilliant and every time I make a new thread and one of you post to it, I get all excited inside, just because I can't wait to see what advice you gave me, criticism, or even just a good job.
Nothing forces you to use a language that was designed to take the backend off of the programmers should so they can explicitly focus on designing their applications.
Compare a simple calculator in C++ to Assembly (I know next to nothing about Assembly). You must code in every single jump. The code in Assembly can become fairly large just to do something simple. Now, add the features of a very simple scientific calculator in there. Add features to have the calculator solve for a variable. What begins to happen to the Assembly code? It becomes more and more unreadable (I already believe it's unreadable to begin with), constantly having jumps in and out, while the C++ code still looks just as elegant as it did in the simple version. Now add a GUI...
Case in point, if you don't want features in a certain language, don't use them. If you think the language is filled with nonsense, then switch languages (that's why I moved away from JAVA).
Programming is, and always will be an art form. Compare programming as a hobby to hobby artists. Look at the different forms of art that any artists can create. Most of us would say, hey, that's not art, he just put a soda can on his dogs head and took a picture, but to other's that is some of the best art there is. Now move that logic over to the programming aspect. I believe that anyone who can program in Assembly (and create something wonderful) is an artist, but that doesn't mean someone can't do the same thing in JAVA, C, C++, C#, LISP, etc. You take the tools you're given and make your program your own. Be happy with what you've created.
I will be the first to admit, I look up to most of your guys. I have been following this thread since Framework started it. I agree and disagree with a lot of the comments that were said, but those are my opinions. I still look at programming as being something you should enjoy. If you really enjoy it, you'll expand your knowledge like I have. You'll constantly be looking for WTFs in the language, WOWs, and Ohhhs. It's part of the learning process. And if any one of you believe you are done learning, you really don't know what programming is about.
Sorry for the rant, but I feel that the fighting is better served teaching rather than arguing semantics with each other. Enlighten us with why specifically you think that garbage collectors are bad (like BHXSpecter did) englighten us as to why you think C++ is a worse C, not a better C. Explain to the other person what C++ offers over C, how the type checking alone in C++ makes it worth using over C, not to mention the OOP structure of the language, the added features, and cleverly masked workarounds to poor C coding techniques.
You guys are extremely brilliant and every time I make a new thread and one of you post to it, I get all excited inside, just because I can't wait to see what advice you gave me, criticism, or even just a good job.
closed account (zb0S216C)
| Disch wrote: |
|---|
| "If you think programming in C# is easy (or at least easier than C), then you must never have programmed in C#." |
I have, and hated every second of it. The fact that you have to use the .NET framework is stupid, and not forgetting the fact that it's slow.
| Disch wrote: |
|---|
| "Scripting languages like Python are going to be a little easier because they're scripting languages... which by their very nature makes them "quick 'n' dirty"." |
I don't have a problem with scripting languages, and I agree that scripts should be "quick and dirty."
| Disch wrote: |
|---|
| "That seems to be a rather pointless (and bogus) claim." |
I disagree. People change, as do their views.
| Disch wrote: |
|---|
| "If a constructor is not needed for a class, then don't write one for the class. Then there's nothing to call and therefore no overhead." |
It still behaves as if it was a function call with no arguments, and just a return statement. It's still a function call, and function calls, even the ones that don't do anything, have some overhead, such as push start & return addresses.
| Disch wrote: |
|---|
| "So you think that before anyone can write any program, they must have full knowledge of how their system architecture, OS, compiler, and runtime libraries all work." |
Would one not create better programs if they did?
| Disch wrote: |
|---|
| "The C equivilents to ctors (init functions), dtors (destroy functions), and virtual functions (function pointers) are not any faster." |
At least they are purely optional, and not implicit like ctors & dtors.
| Disch wrote: |
|---|
| "It also dawned on me that it was pointless to spend a week writing code for a mundane task that somebody already wrote a lib for." |
I enjoy it, and feel a sense of accomplishment. Not to mention gaining insight on how something works.
| Disch wrote: |
|---|
| "1) What was the largest project you ever worked on? 2) What was the largest team you've ever worked with? 3) How many projects have you worked on where the needs drastically changed halfway through?" |
1) Kernel.
2) I don't work as a programmer. I'm a hobbyist programmer, but a serious one.
3) A few times, actually.
| Disch wrote: |
|---|
| "Do you know how a compiler does things?" |
I'm studying it currently.
| Disch wrote: |
|---|
| "Of course, coding in assembly is less automated, and more difficult. But that's what you're saying you want, right?" |
Yes. C and Assembly work together like a well-oiled machine.
| Disch wrote: |
|---|
| "It seems to me that your beef with higher level languages is that they don't require you to manually clean up. " |
It isn't just clean up. If you do things without assistance, you learn to do things (that can go wrong) correctly. If you use all of these fancy garbage collection systems, you become dependent on a feature that may, or may not actually be available in the future. What will you do then?
| BHXSpecter wrote: |
|---|
| " Programmers had to create, allocate, and release memory and now languages are getting so you do the first and it releases the memory for you. I'd venture a guess that if programmers still had to code in binary or assembly only that there would be a lot less programmers now than there are." |
I agree.
| Volatile Pulse wrote: |
|---|
| "If you think all of the features in a language are bloated and add excessive overhead, then don't use the language." |
That's why I'm starting to drift away from C++ and back C. The fact that it does so many things implicitly with overhead is annoying. With C, those pretty features are not there, and therefore, is more lightweight.
| Volatile Pulse wrote: |
|---|
| "Be happy with what you've created." |
If I had written a game in C, I'd be really happy with my self. If I had written the same game in C++ or C#, I'd feel like I didn't have a hand in it, because the compiler did most of the work for me. Where's the fun in that?
Wazzak
Last edited on
| I have, and hated every second of it. The fact that you have to use the .NET framework is stupid, and not forgetting the fact that it's slow. |
I'm not really a fan of .NET myself. But my original point was that making a program in C# is not really any easier than making it in C. The overall concept is the same, just the language (and libraries) are different.
You still have to approach all the same design, syntax, performance problems in each language.
| I disagree. People change, as do their views. |
My point was that you don't really seem to have any basis to think that people stopped thinking of programming as an art form. Did someone come up to you and say "I used to think programming was an art form, but I don't anymore" or something to that effect? If not, then where did you get this idea from?
| Would one not create better programs if they did? |
Sure they would. But if that were actually a requirement to programming... then there'd only be a tiny fraction of programmers around (and by extension a tiny fraction of programs).
The purist "everyone should know everything" attitude that seems to be common among hobbyist developers is simply unrealistic. It may seem noble in that they want people to be better programmers. But in reality it ends up just being elitist snobbery.
Linus is a great example. He's a huge snob. I would absolutely hate to have to do any kind of work with that man. Likewise I'm sure he wouldn't want to work with me.
| It still behaves as if it was a function call with no arguments, and just a return statement. It's still a function call, and function calls, even the ones that don't do anything, have some overhead, such as push start & return addresses. |
That's not true. Try compiling with optimizations turned on. Empty function calls get omitted. It's a pretty basic optimization in both C and C++.
| At least they are purely optional, and not implicit like ctors & dtors. |
Again... that's not true. Ctors and dtors are also optional in the sense that you don't have to write them into classes. If you don't need them, don't put them there. That's one of the fundamental rules C++ was built on... you don't have to pay for what you aren't using.
| I enjoy it, and feel a sense of accomplishment. Not to mention gaining insight on how something works. |
I enjoy it too, sometimes. It can be a lot of fun. As for a sense of accomplishment... I get that much more from creating a functioning program rather than yet-another-linked-list that nobody is going to use/care about.
But even though it's fun... it isn't necessarily productive. To dismiss someone as being lazy or to accuse them of not knowing how xxx container works because they opt to use an existing lib for the implementation rather than write their own is kind of crazy. (I know you weren't the one to use the word "lazy", I'm kind of speaking to other people as well here).
That said... I do agree that understanding how containers work is important for writing efficient code. And those programmers that do understand the containers tend to be better programmers overall.
But that simply doesn't translate to "you should write your own implementation instead of using a lib". There are a dozen reasons why using a pre-made lib is preferable.
It's almost as if you're confusing academia with professionalism. Writing a linked list to understand how they work is a good (and extremely common) exercise in school. But in the real world, it's nearly pointless to do it. (at least, pointless from a productivity standpoint. Not pointless in a "how do you want to spend your time" standpoint if that's what you enjoy doing).
| 1) Kernel. 2) I don't work as a programmer. I'm a hobbyist programmer, but a serious one. 3) A few times, actually. |
I must admit I'm a little surprised by your answer to #1. I didn't expect that.
Though I shudder to think of how your code looked for something as complicated as a kernel if you didn't use any design patterns.
| It isn't just clean up. If you do things without assistance, you learn to do things (that can go wrong) correctly. If you use all of these fancy garbage collection systems, you become dependent on a feature that may, or may not actually be available in the future. What will you do then? |
Well for starters the GC is built into C# so if you are writing C# code it will always be there. There's exactly 0% risk of it not being there in the future. There's a bigger risk of the entire language disappearing -- but that is true of any language (including C).
And secondly... what would you do then? I guess you'd learn to code without a garbage collector. As I mentioned before... adaptability is a big characteristic of a good programmer.
And lastly... if the lib does not allow things to go wrong... why should you care about all the ways they could go wrong in your own implementation? There comes a point when extra knowledge about implementation details is not very useful.
| That's why I'm starting to drift away from C++ and back C. The fact that it does so many things implicitly with overhead is annoying. With C, those pretty features are not there, and therefore, is more lightweight. |
You're talking out of your ass and/or spewing conjecture.
I challenge you to name one thing in C++ that makes it less "lightweight" than C. Ctors/dtors don't count because as I've already mentioned they are optional and if you don't use them they have exactly zero overhead.
I'm OK with you preferring C to C++... that's fine, and I'm not trying to change that. But your reasons for doing so should at least be based in reality.
| If I had written a game in C, I'd be really happy with my self. If I had written the same game in C++ or C#, I'd feel like I didn't have a hand in it, because the compiler did most of the work for me. Where's the fun in that? |
I'm sorry, but this statement is just ..... ugh.... words fail me.
If "most of the work" for your game was writing data containers... then you'd have a point. Although that would be a very simple and boring game.
In the case of C#, if "most of the work" is writing data containers and code cleanup... then you'd have a point. But still I don't think that's most of the work in any game.
Most of the work is design. C++ and C# don't design things for you.
And if you are talking about something other than cleanup or standard containers... then I am at a loss because I don't know what else you think C++ or C# automatically do for you.
Besides... this mentality is foolish. Great people stand on the shoulders of their predecessors. Great accomplishments are achieved by piggybacking on other great accomplishments.
If everyone had to do everything from scratch... the world's accomplishments would be limited to what can be achieved in a single lifetime.
If you can't take pride in your work simply because you didn't manually set every individual bit of the binary, you really need to adjust your attitude. Get over it or else you'll be perpetually disappointed with yourself, and/or you will only accomplish a fraction of what you're capable of.
Last edited on
I don't really understand why you chose C as your arbitrary "Low Level Enough" point. C is a rather high level language, especially with all of the optimizations your compiler will do you for.
Why not write in assembly? Or you could write out the binary file yourself using a hex editor. Or even better, design your own CPU, and re-arrange the transistors to "write" your programs.
http://xkcd.com/378/
Why not write in assembly? Or you could write out the binary file yourself using a hex editor. Or even better, design your own CPU, and re-arrange the transistors to "write" your programs.
http://xkcd.com/378/
Framework,
Here's a thought:
Is it possible that programmers might gravitate to a language/s that suits them? Someone might really like .NET, someone else Pascal, others might like LISP. Perhaps you have grown to like C / Assembler because it suits your ideas of what programming is about, you like how it works, it's efficiency, you feel that the knowledge required makes it an art to write good code, and it suits you to use it for what you are doing project wise. Maybe low level programming suits you better than other types of programming - some guys just love getting into the nitty-gritty of kernels - other people might hate it with a passion.
Now all that is fine, but other people might have different ideas, based on their personal experience, the job they are trying to do, their level in terms of knowledge.
The other thing is that different languages can be more suited to different tasks. C might be just the thing for some app, C++ for something else, Java for something else. They all have their pro's and con's.
I don't think it is fair to label coders, using a modern language such as C++, as less artistic or dumber than those who use lower level languages. Something like that was probably said by assembler programmers of C programmers when C was new. The VAX people probably didn't like the UNIX people, the list goes on ....
Any way maybe it horses for courses - carry on doing what suits you.
Here's a thought:
Is it possible that programmers might gravitate to a language/s that suits them? Someone might really like .NET, someone else Pascal, others might like LISP. Perhaps you have grown to like C / Assembler because it suits your ideas of what programming is about, you like how it works, it's efficiency, you feel that the knowledge required makes it an art to write good code, and it suits you to use it for what you are doing project wise. Maybe low level programming suits you better than other types of programming - some guys just love getting into the nitty-gritty of kernels - other people might hate it with a passion.
Now all that is fine, but other people might have different ideas, based on their personal experience, the job they are trying to do, their level in terms of knowledge.
The other thing is that different languages can be more suited to different tasks. C might be just the thing for some app, C++ for something else, Java for something else. They all have their pro's and con's.
I don't think it is fair to label coders, using a modern language such as C++, as less artistic or dumber than those who use lower level languages. Something like that was probably said by assembler programmers of C programmers when C was new. The VAX people probably didn't like the UNIX people, the list goes on ....
Any way maybe it horses for courses - carry on doing what suits you.
@Framework:
If I may say so...
It sounds to me like you prefer C because it has simpler syntax and because you don't care about (or don't like) the OOP support C++ offers.
If that's the case... then that's what you should be saying. Because that is a perfectly legitimate and reasonable thing to say. Nobody would fault you for it.
But this other nonsense you're going on about... like C++ being too automated and programmers not understanding their architecture well enough -- it all sounds to me like you're rationalizing. It's as if you're trying to fabricate proof to show why C is better than C++.
You don't have to do that.
If I may say so...
It sounds to me like you prefer C because it has simpler syntax and because you don't care about (or don't like) the OOP support C++ offers.
If that's the case... then that's what you should be saying. Because that is a perfectly legitimate and reasonable thing to say. Nobody would fault you for it.
But this other nonsense you're going on about... like C++ being too automated and programmers not understanding their architecture well enough -- it all sounds to me like you're rationalizing. It's as if you're trying to fabricate proof to show why C is better than C++.
You don't have to do that.
closed account (zb0S216C)
| Disch wrote: |
|---|
| "But in reality it ends up just being elitist snobbery." |
Is it wrong and inhuman to want programmers to actually know what happening in their code? It's all about expectations and wishful thinking. Expectations if you're an employer, wishful thinking if you're anything else.
| Disch wrote: |
|---|
| "you don't have to pay for what you aren't using." |
What about the implicit declaration of virtual functions? If a programmer unwillingly overrides a function of a base class, the base class' function is declared virtual implicitly, and therefore, creates a virtual table; thus creating overhead. It's those sort of things that annoy me. Sure there's the final keyword, but where was that prior to C++11?
| Disch wrote: |
|---|
| "I get that much more from creating a functioning program rather than yet-another-linked-list that nobody is going to use/care about." |
Then we're on two different wave-lengths. I enjoy writing libs, even though I only use them personally.
| Disch wrote: |
|---|
| "why should you care about all the ways they could go wrong in your own implementation?" |
Each bug and/or flaw you encounter, the less likely you are to encounter it again. Every time I write something, I find something that needs to be fixed, and that's what I enjoy, and that's what programming is all about, in my opinion.
| Disch wrote: |
|---|
| "I challenge you to name one thing in C++ that makes it less "lightweight" than C." |
The virtual table, the god awful lambada expressions - pretty much anything that's not from C. Sure, if you don't use them, there's no difference. But when you avoid all of those fancy features, you're left with C.
| Disch wrote: |
|---|
| "If "most of the work" for your game was writing data containers... then you'd have a point. Although that would be a very simple and boring game." |
That depends completely on the story and game mechanics, not the game's implementation.
| DeXecipher wrote: |
|---|
| "its all about the big pictur." (sic) |
In your eyes, what is the big picture? I'm thinking I should curl my tongue, keep my mouth shut, sit back, and see "lazy" programmers trample over what I think's artistic programming. I can't do that.
Wazzak
I hope I'm not missing out on the point here, but as far as I can tell C++ lambda functions are simple, without real overhead, and may as well be in C.
They seemed like a natural development of C++ at the time and still do, whether you use them with the STL algorithms or within your own code!
EDIT: By the way thanks for everyone that's posted in this thread, it's been quite interesting hearing about everyone's opinions (and perhaps misjudgements) of C++.
EDIT2: I will, however, back anyone up who thinks the lambda notation is nasty. Out of interest, how would any of you have done this?
They seemed like a natural development of C++ at the time and still do, whether you use them with the STL algorithms or within your own code!
EDIT: By the way thanks for everyone that's posted in this thread, it's been quite interesting hearing about everyone's opinions (and perhaps misjudgements) of C++.
EDIT2: I will, however, back anyone up who thinks the lambda notation is nasty. Out of interest, how would any of you have done this?
Last edited on
| Is it wrong and inhuman to want programmers to actually know what happening in their code? It's all about expectations and wishful thinking. |
In their code? No, that's not unreasonable.
In other peoples code that they are using? Yes, that is unreasonable. Libraries tend to be black boxes and don't need to be fully understood in order to be used (and often, you shouldn't try to fully understand them because the exact implimentation of them may change).
In the case of standard containers, the concept of how the container works, and stores and accesses data is enough. Knowing exact implementation details does not really help you use it more efficiently.
| What about the implicit declaration of virtual functions? If a programmer unwillingly overrides a function of a base class, the base class' function is declared virtual implicitly, and therefore, creates a virtual table; thus creating overhead |
Yes, you're right. I guess if you accidentally write inefficient code you will have inefficient code.
Sarcasm aside, I see your point, and it is valid. C++ does certainly allow for this to happen. Though I would argue that it's more of a logic error than a performance error... since if you don't want a function to be virtual and it ends up being virtual, that could be a huge bug.
| Then we're on two different wave-lengths. I enjoy writing libs, even though I only use them personally. |
I guess so. Personally I find it to be much more rewarding to complete a complex program/lib that other people might actually use. Another implementation of a trivial container class somehow seems so much less fullfilling.
But that's all personal preference. To each his own.
| the god awful lambada expressions |
Lambda expressions (not lambada, which is a dance) can pull their context off the stack. The overhead of passing the context is equal to (and potentially smaller than) the overhead of a normal function parameter. All the lambda has to do to get context is push/pull the current stack pointer.
That issue aside, lambdas are no more expensive than a normal function.
And that's assuming the lambda isn't inlined. If it is inlined the performance hit is zero. Though lambdas, by their nature, are typically used as callbacks and therefore will not be inlined.
| That depends completely on the story and game mechanics, not the game's implementation. |
You're missing/dodging my point.
You said C++ does most of the work for you. I'm saying that claim is nonsense. The only thing C++ does for you is provide container classes so you don't have to write them yourself. The basic containers used by a game accounts for maybe 1% of the total effort/work you have to put into a game... and that's if the game is pretty small.
I fail to see how that 1% constitutes "most of the work" by your standards.
Last edited on
closed account (o1vk4iN6)
| framework wrote: |
|---|
What about the implicit declaration of virtual functions? If a programmer unwillingly overrides a function of a base class, the base class' function is declared virtual implicitly, and therefore, creates a virtual table; thus creating overhead. It's those sort of things that annoy me. Sure there's the final keyword, but where was that prior to C++11? |
What ? Do you mean if the base class has a virtual function and the same function is created in an inherited class it will become virtual ? Isn't that your job to know what your language is doing ? I can say the same thing about implicit type conversion in C, if it was a strongly typed language it would be safer. Same goes for:
|
|
There are many things wrong with C and saying features shouldn't exist in C++ because they aren't "safe" is nothing short of laughable.
Last edited on
I was going to bring that up @ xerzi, but in all fairness it is a performance issue whereas the issues with C are just downright bugs. So it's apples and oranges.
Sorta ... the virtual function thing could also be a considerable bug depending on the circumstances. Though it's not likely.
EDIT: to clarify I'm not saying the C language is bugged, I'm saying that accidental mis-coding results in bugs (vs. resulting in a performance penalty)
Sorta ... the virtual function thing could also be a considerable bug depending on the circumstances. Though it's not likely.
EDIT: to clarify I'm not saying the C language is bugged, I'm saying that accidental mis-coding results in bugs (vs. resulting in a performance penalty)
Last edited on