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'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.
|"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."|
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?