Is Programming Becoming a Lost Art?

Pages: 1234
closed account (zb0S216C)
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'll admit to agreeing with Linus Torvalds on some points, such as:

Linus Torvalds 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."


Linus Torvalds wrote:
"In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C."


Linus Torvalds wrote:
"And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up..."

Is programming still considered an art in your eyes? despite that fact that most languages now do almost everything for you? I'll say it as it is: I don't like languages that do things implicitly (such as garbage collection). I'm starting to drift away from C++, and back to C because of this.

By the way, C++11's lambada expressions are terrible, but that's my opinion. Am I another Linus?

Wazzak
Last edited on
Not going to weigh in on this, as I'm far too inexperienced with "real" programming.

Just like to state that Linus Torvald seems like the kind of nerd that enjoys making dramatic statements because it makes him feel ballsy. Every quote from him I read is overly hyperbolic and exagerating the situation simply for "effect".
not lost b/c of guys like this http://www.youtube.com/watch?v=N8elxpSu9pw&feature=relmfu

also why drift away from c++ if you know how ::operator new/delete works?
Last edited on
Yesterday I met a guy who is building a multi-touch surface into his kitchen table completely from scratch, with the OS built from the vanilla linux kernel. On his own. Because he can.

As long as there are people like him programming will still be an art. Also, to quote my self circa my last year of highschool:
taking six hundred pictures of your converse shoes through the sepia filter on your iphone makes you a photographer artist like microwaving cup ramen makes me a gourmet chef.
Last edited on
the question should be are you a good computer scientist/software engineer. If yes then nothing else matters, if no then you'll never be satisfied.
closed account (z05DSL3A)
The language is just the tool of the programmer in the same way that a pencil is a tool of an arts. A pencil is very easy to use but does not make the operator an artist, so an easy language does not make the user a programmer.
closed account (zb0S216C)
DeXecipher wrote:
"also why drift away from c++ if you know how ::operator new/delete works?"

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. For example, C++'s constructors are sometimes unnecessary, as are the destructors, but they get called anyway. With C, you're forced to do things C++ would seemingly do implicitly, and that forces you to learn how it does it in order to prevent things from going wrong. 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.

@xander337: That's the sort of programmers we need more of, and less of these: "I let the compiler optimise my code for me, so I don't have to do it."

Wazzak
Last edited on

I've noticed that every language that's released is making the programming field become more, and more easier

That's necessary. It's a nonsense to create a GUI application in assembly for desktop use.
1
2
3
"In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C."

This, for example, it's bullshit if you're not developing an OS.

Also, even if something is easier through libraries/new languages/etc., you have to know how low-level things anyway. I could use SetPixel() 10'000 times in a row or I could memcpy();
It's not about C or C++, libraries or no libraries, abstraction or no abstaction.
It's about knowing what you're doing.
closed account (zb0S216C)
mlpnkobji wrote:
"This, for example, it's bullshit if you're not developing an OS."

I disagree. C++ has features that are coupled with performance overheads. Features like virtual functions, and ctors & dtors suffer from some unwanted overhead.

mlpnkobji wrote:
"Also, even if something is easier through libraries/new languages/etc."

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. How will somebody learn to build containers and what not if they use somebody else's? I'm not saying don't use libraries, I'm saying show some interest in the implementation.

mlpnkobji wrote:
"It's about knowing what you're doing."

Most don't even care how something gets done, as they just want it to be done and dusted.

Wazzak
I don't want to touch Linus's old BS with a ten-foot pole, but to reply to the rest:

Framework wrote:
Is programming still considered an art in your eyes?

It's an art, it's a science, and it's an engineering field. As it has been since the 60s.

despite that fact that most languages now do almost everything for you?

That's not relevant at all: the dumbest assembly and the smartest 5GL (if one is ever built) have room for creativity and artistic expression. Higher level languages allow a whole lot more, in my opinion - there's simply more concepts to work with.

I'll say it as it is: I don't like languages that do things implicitly (such as garbage collection). I'm starting to drift away from C++, and back to C because of this.

C does a whole lot implicitly: I've seen compilers effortlessly merge and transition between calls to strcpy() and explicit loops, for example, or replacing printf() with more appropriate output functions, not to mention the usual expression reordering and strict aliasing. It's just as fluid as C++.
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.

They're "easier" because it helps deal with ever greater complexity.

And in my opinion, it's not "an art" having to deal with details that aren't part of the problem you're solving. Even if it's about optimization: optimize the algorithm. That's where the art is at.

By the way, C++11's lambada expressions are terrible, but that's my opinion.

Ha ha! Lambadas! Yes, I would call them ugly... but they've been overdue. The algorithms library needed them long before 2011.
closed account (zb0S216C)
Catfish2 wrote:
"They're "easier" because it helps deal with ever greater complexity."

It's that "making things easier for the programmer" is what draws substandard programmers. That's the sort of thing that needs to stop. If we only used C for programming projects, the majority (if not all) of substandard programmers wouldn't be eligible to work on the project, and only the ones who actually know what their on about will be eligible.

Catfish2 wrote:
"And in my opinion, it's not "an art" having to deal with details that aren't part of the problem you're solving. Even if it's about optimization: optimize the algorithm. That's where the art is at."

Working on a low-level requires a lot more knowledge than programming on a high-level.

Cubbi wrote:
"Higher level languages allow a whole lot more, in my opinion - there's simply more concepts to work with."

I find that most of these "concepts" simply get in the way, and create more unnecessary work. I prefer to work with raw knowledge on a low-level, and and stripped overhead, rather than working with my head in the ground, and letting the compiler do things that should be done by the programmer.

Cubbi wrote:
"It's just as fluid as C++."

I'm not saying C is as stiff as a plank, I'm saying C++ have unnecessary overheads. The good thing about C is that you have to know what you're doing in order to get something done correctly. Relying on the compiler too much is not healthy. Programmers should be learning how the compiler does things, and not passing it by without a second thought.

Wazzak
Last edited on
It's that "making things easier for the programmer" is what draws substandard programmers. That's the sort of thing that needs to stop.

I believe you fail to see the bigger picture: a programming language helps you express your problem in a way that the computer can solve it for you.

A substandard programmer can still be an expert in another field, relevant to the project.

So what is this about? The fact that truly knowing the machine inside out isn't a requirement anymore? Why is that a bad thing? I made a point in the previous post: ever increasing complexity warrants the need for "easier" languages.
closed account (zb0S216C)
Catfish2 wrote:
"So what is this about? The fact that truly knowing the machine inside out isn't a requirement anymore? Why is that a bad thing?"

Knowing the architecture is what programming is all about, in my opinion. At least, it was. Now, though, people have become so used to these fancy languages that brush the details under the carpet, and they say: "No need to worry about the details." It's this protection from the nitty gritty that makes programming a trivial task, and not something you can feel proud of, because everyone can do it, and there's no challenge.

Wazzak
Programming will never be a trivial task, because the art of programming is not about telling the computer how to shift registers around, it's turning a real life problem into something a computer can understand.
Addendum: And higher level languages simply give the programmer more options to do this. The real problem still lies in developing the algorithm.
Last edited on
If we only used C for programming projects, the majority (if not all) of substandard programmers wouldn't be eligible to work on the project

I feel that there's a greater tendency to hire substandard C programmers, because the language is perceived as "easy", while in fact it requires far greater discipline and attention to detail than any other production language: do an overflow test by invoking the overflow ( if (n > n+1) abort(); ) and you're dead (the test is compiled out). Do a null pointer test after dereference,, and you're dead (likewise).
Last edited on

It's that "making things easier for the programmer" is what draws substandard programmers. That's the sort of thing that needs to stop. If we only used C for programming projects, the majority (if not all) of substandard programmers wouldn't be eligible to work on the project, and only the ones who actually know what their on about will be eligible


What's the problem, man? Just don't hire them.
closed account (zb0S216C)
Cubbi wrote:
"while in fact it requires far greater discipline and attention to detail than any other production language"

That's exactly the sort of thing a programmer needs. With languages becoming ever higher, you need no where near as much discipline and attention to detail, because the compiler tucks all of the details away.

I feel like Linus now.

Wazzak
It is beneficial that "higher" languages allow you to focus more on the big picture. Because otherwise you'd be wasting brain cycles with the big picture and the small details. Which only makes your task harder; is that the kind of challenge you want?
Working on a low-level requires a lot more knowledge than programming on a high-level.


Not necessarily. In the lowest level, all your basically doing is adding and subtracting. But why should the programmer need to concern themselves with doing billions upon billions of the most basic arithmetic operations?

Working on a lower level, once you have the knowledge of the basics, is actually pretty simple and requires very little knowledge.

The more difficult concepts and innovation come in with higher level languages, because at the lowest level, it's not even really possible as so much of your mind must be devoted to tedious dumb operations.

Now C and C++, let you use pointers and don't use garbage collection, which I suppose is mostly what makes them lower level than most other languages. But that doesn't make it really that low level does it?

Pointers are really a super basic thing, which you can learn in about 10 minutes. Memory allocation, is pretty simple as well, and really is just a high level abstraction anyways. You just tell the computer what you want it to do for you. The actual operation is really quite dumb and your interface too is an abstraction still, but Having to concern yourself with thousands of dumb operations, and keeping track of it all can be a waste of your time when you have more complex and much larger problems to solve.

Here is a quote from MIT's course notes for their EECS 6.1 course.

Whether proving a theorem by building up from lemmas to basic theorems to more specialized
results, or designing a circuit by building up from components to modules to complex processors,
or designing a software system by building up from generic procedures to classes to class libraries,
humans deal with complexity by exploiting the power of abstraction and modularity. Without
such tools, a single person would be overwhelmed by the complexity of a system, as there is only
so much detail that a single person can consciously manage at a time.
Modularity is the idea of building components that can be re-used; and abstraction is the idea that
after constructing a module (be it software or circuits or gears), most of the details of the module
construction can be ignored and a simpler description used for module interaction (the module
computes the square root, or doubles the voltage, or changes the direction of motion).
Given basic modules, one can move up a level of abstraction and construct a new module by
putting together several previously-built modules, thinking only of their abstract descriptions,
and not their implementations. And, of course, this process can be repeated over many stages.
This process gives one the ability to construct systems with complexity far beyond what would be
possible if it were necessary to understand each component in detail.
Any module can be described in a large number of ways. We might describe the circuitry in a
digital watch in terms of how it behaves as a clock and a stopwatch, or in terms of voltages and
currents within the circuit, or in terms of the heat produced at different parts of the circuitry. Each
of these is a different model of the watch. Different models will be appropriate for different tasks:
there is no single correct model. Rather, each model exposes different dimensions of the system,
allowing us to explore many aspects of the design space of a system, and to trade off different
factors in the performance of a system.
The primary theme of this course will be to learn about different methods for building modules
out of primitives, and of building different abstract models of them, so that we can analyze or
predict their behavior, and so we can recombine them into even more complex systems. The same
fundamental principles will apply to software, to control systems, and to circuits.

Last edited on
Pages: 1234