[LHN91]

Let me try to present my argument in another form. If the programmer label is that vague and it's related to that "problem", how would making it less vague solve it?

In the case you presented we can already narrow down the specialization those programmers have and their areas. Hell, we just did, embedded systems programmer and "dude who dabbles into programming" (or for those of you who want a serious title, lets just call him applications programmer).

The fact that we already have names and labels for the various things we have been talking about would suggest that this labelling business is not the problem, whatever that problem is.

And coming back to the author, using the programmer label is not the same as using a scientist one. One programmer can with some training do the job of another programmer. The same can't be said of a physicist to a botanist.


P.S.
Joining Polpolion, I've got a Masters in Computer Science, where the course work was supposedly network heavy, my thesis was about AI/game theory, and now I'm trying to do research on OS architecture and trying to extend stuff about my thesis on my spare time.

I suppose that's entirely fair. I guess what I feel is the part that maybe the article would have been better served to focus on would be the societal perception of the term "programmer". Those who don't know anything about programming would be quite likely to not know of the division in the discipline, and assume that all programmers are just programmers.

I'm in the 3rd year of my Uni's Bachelor of Computing degree (which has SoftEng and CompSci as sub-disciplines). EDIT: Thus, admittedly I have far less experience than you. Ours focuses on covering paradigms, in a way; they start us off in straight ANSI C, and then in second year give you Java, 68k Assembly, C99, Python, and PostgreSQL. I'm also currently in a course on Legacy systems, and in there we're work with Fortran, Ada, and Cobol, primarily modernizing say Fortran77 to Fortran95.

[Ghostavo]

But don't we treat other disciplines the same way?

Physics is a large field and yet if someone says they're a physicist we don't bat an eye.

The same for biology, medicine, etc.

[Dragon]

Physics are enough of a "dark art" that most people don't inquire further unless they're also interested in physics. Also, the "basics" are simple enough that you could expect most physicists to be familiar with them. I'm only running into "wrong specialization" problems when asking my teacher about really obscure/recent/complicated topics (well, I guess you shouldn't expect a high school physics teacher to be an expert astrogator, even if it's an elite school).

Programming is different, in that there's a lot of languages and specializations, sometimes completely unconnected. While you could expect a dentist to know how to patch up a leg wound, or from a microbiologist to have a general knowledge of how a digestive tract works, a programmer could easily specialize in C++, but know next to nothing about LUA of Java.

[Ghostavo]

Programmers also have "basics" as you call them. Every programmer knows (or should know) basic flow control mechanisms or data structures for example.

Also, I assume that the more people are familiar about a subject, the wider they feel the area really is. Since everyone in this thread seems to have familiarity computer science, it's natural that we all feel that computer science is a vast vast place, while other disciplines may not feel as vast. And what you consider simple is also effected by your familiarity with the area.

Try asking your dentist about dermatology.

[karajorma]

But that's the thing, dentists know not to try to give advice to dermatologists.

[Dragon]

Programmers also have "basics" as you call them. Every programmer knows (or should know) basic flow control mechanisms or data structures for example.

On the other hand, the implementation of these basics can vary widely, much more than in physics. A better analogue for programming might be linguistics. There's a "basic theory", which includes how tenses, word gender, declination (a concept unknown in English and difficult to explain, but present in Latin and Slavic languages) and other such things work. The precise implementation, however, varies. For example, in Polish there are only three times, but you have to wrap your head around declination. Same with programming. The basic concept of a data structure might be the same across various languages, but how do you define it depends on the language.

But that's the thing, dentists know not to try to give advice to dermatologists.

Perhaps it's because medicine is a very old science, while programmable machines exist only for about 90 years, and that's including the Colossus (the very first one, used during WWII).
Programming as we know it (for a quite liberal value of "as we know it") exists for about 40 years at most. It's a science that didn't had too much time to evolve and set any rules in stone. Also, in medicine the specializations are quite clearly defined, not to mention it's nature means it has to be deadly serious. I would be less surprised if an astrophysicist tried to advice a nuclear physicist on how he should approach his research though. People who think "If you don't do it my way, you're doing it wrong." might happen in any science.

[Ghostavo]

Programming predates computers.

Ada Lovelace comes to mind.

[jr2]

Programming predates computers.

Ada Lovelace comes to mind.

Well, programming sort of equals creating flowcharts for devices, following certain rules of communication (language) that the device / or compiler flowchart software on the device is made to follow.

So, I imagine that flowcharts have been around for quite a while, just now they are being used for machines, and machines aren't too aweful good at inferring what is actually meant (although, even with human intelligence, you still run into language barriers and interpretation issues, which is why you can get two different building from the same set of blueprints if two different architects build them.

Perhaps what the problem is is that some programmers are a bit closed-minded?  Experts in any area can become that way.  Life is a process of learning, and even when someone is an expert, that does not entitle them to close their mind to new information and theories and simply spout their brilliance.  Even if they are 100% correct, there are still things to be gained from learning others' perspectives of the same truth.  In addition, it is hard to learn from someone who does not try to break things down to your level and instead, simply lectures on 'the way things are' without bringing you through at least an outline of how they came to that conclusion. (I suppose, sometimes a teacher doesn't have enough time to even give a bare skeleton of the reasoning behind their teachings, however, one would hope that at least there would be references in the textbook / lesson notes).

...Rambling, sorry. 

[castor]

One programmer can with some training do the job of another programmer. The same can't be said of a physicist to a botanist.

I think you are oversimplifying it quite a bit. For example, imagine you'd been writing whatever scripts for web sites the last 10 years, and then apply for a job as hardware driver developer for modern GPUs. The botanist could well have a degree in physics before you'd be producing something useful..

[Ghostavo]

I don't think think it's that big of a difference, although to be honest, I can't conceive how a programmer cannot have experience with lower level languages, even if it's just making an hello world program.

Maybe I expect programmers to be (much more) educated and held to a higher standard.

[Nuke]

i approach programming from a hobbyist point of view. but im just as at home programming a mirocontroller in asm as i am programming a game engine in lua. and even thats not enough, i have to get into how a cpu works, how digital logic works, how to build a flipflop from discrete transistors or how to use logic gates to do math. i probibly dont count as a programmer because im not formally trained in that discipline and i do not work in that field. im not really all that intrested in web programming or java, but im pretty sure i could pick it up if i ever had the desire to, or a project demanded it (internet accessible robots anyone?). so im not a programmer, but i do have a knack for writing code that works.

[Tomo]

One programmer can with some training do the job of another programmer. The same can't be said of a physicist to a botanist.

I think you are oversimplifying it quite a bit. For example, imagine you'd been writing whatever scripts for web sites the last 10 years, and then apply for a job as hardware driver developer for modern GPUs. The botanist could well have a degree in physics before you'd be producing something useful..

I don't think think it's that big of a difference, although to be honest, I can't conceive how a programmer cannot have experience with lower level languages, even if it's just making an hello world program.

Scripting languages are as different to hardware drivers as it's possible to get!

Nuke is very good with the Lua scripting language used in FSO, yet I bet he doesn't think he could learn the necessary to write notable parts of a functional and stable hardware driver for a modern GPU in a year.

I've also got experience in both low-level MCU and high-level Windows application development - and I know I couldn't write notable parts of a modern GPU driver without several years of training.

This is exactly the kind of thing that the original article is talking about.
You have stated the belief that scripting languages and hardware driver development are sufficiently similar to cross-train someone in a short course.

This is bunk, as anyone who has done extensive work in either field should know.

However, unfortunately the media, and many others who ought to know better still hold that belief - and because they repeatedly say that kind of thing, the general public come to believe it as well.

The core ideas do transfer - arrays, loops, decisions and pointers (Except that most scripting languages don't have pointers!) - but all the detail is different.
A good idea in one context in utterly insane in another - eg recursion on an MCU, directly accessing hardware in an application.

[Ghostavo]

One programmer can with some training do the job of another programmer. The same can't be said of a physicist to a botanist.

I think you are oversimplifying it quite a bit. For example, imagine you'd been writing whatever scripts for web sites the last 10 years, and then apply for a job as hardware driver developer for modern GPUs. The botanist could well have a degree in physics before you'd be producing something useful..

I don't think think it's that big of a difference, although to be honest, I can't conceive how a programmer cannot have experience with lower level languages, even if it's just making an hello world program.

Scripting languages are as different to hardware drivers as it's possible to get!

Nuke is very good with the Lua scripting language used in FSO, yet I bet he doesn't think he could learn the necessary to write notable parts of a functional and stable hardware driver for a modern GPU in a year.

I've also got experience in both low-level MCU and high-level Windows application development - and I know I couldn't write notable parts of a modern GPU driver without several years of training.

This is exactly the kind of thing that the original article is talking about.
You have stated the belief that scripting languages and hardware driver development are sufficiently similar to cross-train someone in a short course.

This is bunk, as anyone who has done extensive work in either field should know.

However, unfortunately the media, and many others who ought to know better still hold that belief - and because they repeatedly say that kind of thing, the general public come to believe it as well.

The core ideas do transfer - arrays, loops, decisions and pointers (Except that most scripting languages don't have pointers!) - but all the detail is different.
A good idea in one context in utterly insane in another - eg recursion on an MCU, directly accessing hardware in an application.

I didn't say they were similar, I said that I can't believe any programmer doesn't have experience with any low level language.

For instance, Nuke IIRC, said somewhere he programed micro controllers.

And if you know the core ideas, as you called them, the hard part is just checking references and the respective documentation. Sure, you have to be careful with some stuff because of optimizations and other limitations, but that's with practice.

The original article states that these core ideas are not known. The issue he first tries to tackle is that apparently some [sic]programmers don't know what a heap is.

[karajorma]

I didn't say they were similar, I said that I can't believe any programmer doesn't have experience with any low level language.

I have no experience with assembly. Many other self-taught programmers will also have no experience with it for the same reason I don't, they didn't see any point in learning it.

The original article states that these core ideas are not known. The issue he first tries to tackle is that apparently some [sic]programmers don't know what a heap is.

I didn't have any need to learn what the heap was for the entire time I was a Java programmer. It so happens that I actually knew what the term meant before I even started learning Java but while I was coder in that language it was nothing I had any need to know.

[LHN91]

I believe that every programmer *should* have experience with at least one lower level language, like ANSI C, but that doesn't mean that every one does. Someone who only does GUI programming in say Java would have no explicit need to know much about low level data structures and the like short of knowing how to call their library functions. Even the most basic structures, like lists, are handled by a built in data structure like ArrayLists, that require no knowledge whatsoever of the low level code behind it to use it. Why would a Java programmer, for example, feel a need to explore how to build linked lists if it's always been abstracted away?

[Ghostavo]

I didn't say they were similar, I said that I can't believe any programmer doesn't have experience with any low level language.

I have no experience with assembly. Many other self-taught programmers will also have no experience with it for the same reason I don't, they didn't see any point in learning it.

The original article states that these core ideas are not known. The issue he first tries to tackle is that apparently some [sic]programmers don't know what a heap is.

I didn't have any need to learn what the heap was for the entire time I was a Java programmer. It so happens that I actually knew what the term meant before I even started learning Java but while I was coder in that language it was nothing I had any need to know.

I apologize for you not knowing the key data structure Java uses. And you know, how the garbage collector works and stuff...

Also, a programmer using Java should know how a LinkedList and an ArrayList work because of efficiency reasons. If you are trying to repeatedly access a LinkedList by indexes for instance...


I think I need to repeat myself, not everyone who programs is a programmer, just as not everyone who writes is a writer and not everyone who does math is a mathematician. And just as there are examples of bad writers, there are examples of bad programmers. Hell, there are whole websites dedicated to this stuff.

[karajorma]

I did write and post a response but you know what? **** it.

The rest of us have understood the point under discussion. If you wish to flail around in ignorance and display contempt to those who are only trying to explain something to you, so be it.

[Polpolion]

I'd like to do some flailing, actually. Thanks for giving me this opportunity.

I didn't say they were similar, I said that I can't believe any programmer doesn't have experience with any low level language.

I have no experience with assembly. Many other self-taught programmers will also have no experience with it for the same reason I don't, they didn't see any point in learning it.

The original article states that these core ideas are not known. The issue he first tries to tackle is that apparently some [sic]programmers don't know what a heap is.

I didn't have any need to learn what the heap was for the entire time I was a Java programmer. It so happens that I actually knew what the term meant before I even started learning Java but while I was coder in that language it was nothing I had any need to know.

1) Experience with assembly in and of itself is exactly 0% helpful when writing applications, for the most part. Knowing how your computers work, on the other hand, can pretty useful if you know enough about your compiler to know what it will do with it. Most of the time that happens to come from knowing assembly or having taken a computer organization course at one point or another. Still, compilers work well enough for you to not care about this unless you really need to squeeze out the performance.

2) The article wasn't talking about the heap, it was talking about a heap. Though I could certainly see the confusion the make_heap function would cause if someone knew what the heap was but not what a heap was.

I believe that every programmer *should* have experience with at least one lower level language, like ANSI C, but that doesn't mean that every one does. Someone who only does GUI programming in say Java would have no explicit need to know much about low level data structures and the like short of knowing how to call their library functions. Even the most basic structures, like lists, are handled by a built in data structure like ArrayLists, that require no knowledge whatsoever of the low level code behind it to use it. Why would a Java programmer, for example, feel a need to explore how to build linked lists if it's always been abstracted away?

When programmers write a data structure abstraction to be used by everyone everywhere they just guess what kind of workload it will have and choose the most optimal structure for that workload. With a linked list, if you spend all your time doing random accesses you're wasting loads of time. That's the problem with abstracting things. Unless you know exactly how it's going to be used, someone is going to be using it sub-optimally, when a different structure would work much better. Every programmer that has a degree should have taken a data structures and algorithms class at one point and should know generally which structures work when, but if they're stuck with a mystery box structure that doesn't work so well then they can't be helped. So really the only time you should be using abstracted structures is if performance isn't your biggest concern. tl;dr different situations calling for different approaches is why abstraction can't work in the most optimal way.

So if you don't know how to write optimal Java code and you're a java coder, you definitely have things to learn that require breaking abstraction.

[karajorma]

I'd like to do some flailing, actually. Thanks for giving me this opportunity.

Since you asked nicely.

1) Experience with assembly in and of itself is exactly 0% helpful when writing applications, for the most part. Knowing how your computers work, on the other hand, can pretty useful if you know enough about your compiler to know what it will do with it. Most of the time that happens to come from knowing assembly or having taken a computer organization course at one point or another. Still, compilers work well enough for you to not care about this unless you really need to squeeze out the performance.

I won't deny that there are times when I've found knowledge of what goes on under the hood very useful. What I find objectionable is that you need that knowledge in order to be a good coder. Or that everyone who is a programmer has it.

Besides if you're at the point where you're playing around with compiler flags in order to squeeze out performance in Java, maybe you need to think long and hard about why you ended up in that position in the first place.

The article wasn't talking about the heap, it was talking about a heap. Though I could certainly see the confusion the make_heap function would cause if someone knew what the heap was but not what a heap was.

That should teach me to re-read the article again before replying to it. Still the point about abstraction is still valid.

As is my point that sometimes a little knowledge can actually be dangerous. I've seen no end of times when someone has written a convoluted function because they wanted to optimise the speed based on some abstraction-breaking rule they knew. And of course when you profile that function against the one written by someone ignorant of that rule you find the speed difference to be minimal or even that the complicated function is actually slower.

When programmers write a data structure abstraction to be used by everyone everywhere they just guess what kind of workload it will have and choose the most optimal structure for that workload. With a linked list, if you spend all your time doing random accesses you're wasting loads of time. That's the problem with abstracting things. Unless you know exactly how it's going to be used, someone is going to be using it sub-optimally, when a different structure would work much better. Every programmer that has a degree should have taken a data structures and algorithms class at one point and should know generally which structures work when, but if they're stuck with a mystery box structure that doesn't work so well then they can't be helped. So really the only time you should be using abstracted structures is if performance isn't your biggest concern. tl;dr different situations calling for different approaches is why abstraction can't work in the most optimal way.

So if you don't know how to write optimal Java code and you're a java coder, you definitely have things to learn that require breaking abstraction.

But do you? Why is it breaking abstraction to simply learn linked lists are slow for random access but good for sequential access? I'm not saying knowing that stuff isn't useful, it certainly helps you remember why it is slower to insert in the middle of a vector compared with a linked list. But why do you have to know anything beyond whether an operation is O(n) or O(1)? Why do you have to understand the internal structure?

Edit : some days I really should proof read.

[Polpolion]

As is my point that sometimes a little knowledge can actually be dangerous. I've seen no end of times when someone has written a convoluted function because they wanted to optimise the speed based on some abstraction-breaking rule they knew. And of course when you profile that function against the one written by someone ignorant of that rule you find the speed difference to be minimal or even that the complicated function is actually slower.

Yeah. The thing about this is that if people do these crazy optimization we're talking about and get a good change in performance they're usually either in the main part of the program or in really common functions, which should scream "reconsider your design" to the people trying to do the optimization.

But do you? Why is it breaking abstraction to simply learn linked lists are slow for random access but good for sequential access? I'm not saying knowing that stuff isn't useful, it certainly helps you remember why it is slower to insert in the middle of a vector compared with a linked list. But why do you have to know anything beyond whether an operation is O(n) or O(1)? Why do you have to understand the internal structure?

You really don't have to know exactly how it's implemented, but personally I'd say that if things are implemented in such a way that you yourself need to remember how to access your data in the structure then you're breaking the abstraction. If people want to index my linked lists they can write their own functions to do it.