Can you learn to become a good programmer?

[adssse]

I read this quote from Bill Gates (yes I know, not my favorite person but...) on Coding Horror.

"Bill Gates: No. I think after the first three or four years, it's pretty cast in concrete whether you're a good programmer or not. After a few more years, you may know more about managing large projects and personalities, but after three or four years, it's clear what you're going to be. There's no one at Microsoft who was just kind of mediocre for a couple of years, and then just out of the blue started optimizing everything in sight. I can talk to somebody about a program that he's written and know right away whether he's really a good programmer."

http://www.codinghorror.com/blog/

Although I believe that there are those that are naturally more inclined to programming I tend to disagree that you cannot become a good programmer through years of effort. It made me curious of others opinions on whether if you are an average programmer if you can work hard and become very good or if it is simply something you 'either have or you dont'.

[Note360]

He is wrong. I am still in my first year of really programming though. However, you cna learn anything though. However, you will have to work REALLY hard

[pmasiar]

I tend to disagree that you cannot become a good programmer through years of effort. It made me curious of others opinions on whether if you are an average programmer if you can work hard and become very good or if it is simply something you 'either have or you dont'.

Bill is right on the money :-) - you cannot learn the programmer's mindset.

You cannot learn to be good programmer exactly like you cannot learn to be good piano player or actor or pro tennis player. Certainly you can learn to play but in many cases you will stay intermediate, never advancing to pro. And article you linked has link explaining why (http://www.codinghorror.com/blog/archives/000635.html)

BTW programming language oriented squarely to programming pros is Forth (http://en.wikipedia.org/wiki/Forth_%28programming_language%29) - very high-level, very unforgiving, and extremely productive in skilled hands.

[lloyd mcclendon]

Bill is right on the money :-) - you cannot learn the programmer's mindset.

You cannot learn to be good programmer exactly like you cannot learn to be good piano player or actor or pro tennis player. Certainly you can learn to play but in many cases you will stay intermediate, never advancing to pro.

i agree, you can work your *** off but if you don't have any natural ability you'll only be mediocre. being great at anything comes from a combination of talent and working your *** off.

[amo-ej1]

Well I kinda agree though. But the issue is not skill, the issue is interest.

Some people are into programming for the money without any motivation of any kind. Some people are into programming because they enjoy it, they enjoy the searching, the live for programming. When you talk to somebody who has written something and enjoyed writing it, you will easily notice this in a conversation since they will recall lots of things about it and because they will probably be proud of what they have done. The first group of people will be happy that they earned they money doing it and have forgotten most of it already.

And it 's simple. thing that you like to do will be things you do better, so you'll easier learn things you like to learn than things you dislike etc etc etc So all this has nothing to do with programming skill but has everything to do with motivation.

[g8m]

You're programmings skills are not important.

What's important is that you can communicate. So if you are good with people, you are a professional programmer. You will be hired. No matter how bad your code is, no matter how many mistakes you make.

If you are a good programmer but a poor communicator and you made a mistake, all hell breaks lose. If you are a good communicator, with good social skills, people will not see you're shortcomings, like bad coding and so.

Just my 2 cents.

[akudewan]

IMO, there are two ways of achieving anything:

1) Genius: If its already in your genes, (meaning if you are a natural)
2) Hard Work: If you work very hard, and if you love what you are doing, then you'll definitely succeed.

People can change they way their minds work, if they try hard enough..

[gh0st]

I don't often agree with Bill Gates but I think he kind of has a point here. Of course you can continue to learn new languages and platforms forever, nobody knows everything but I do think that some people have more of an aptitude for it. You can't learn to have talent.

I play the guitar and I have improved a lot since I was a kid but nobody can teach me how to be Jimi Hendrix, I can get books to try and learn some of his songs but I just don't have it in me to play like that. It's not my style. Nobody can teach me to play like Hendrix if I haven't got the talent to start with. That's not to say I'm not a mean guitar player though :D I'm more Pete Townshend than Hendrix in style :cool: ;) :guitar:

I think that's what Gates is saying, nobody can teach you to have a talent for programming. You might have the talent and not know it until someone brings it out of you but it's gotta be in there to start with.

You never stop learning in life though, I know I don't anyway :D

EDIT: That's not to say that people can't be good at something if they really try hard and work. Talent is no use without application. If you do your best then that's all you can do, your best might be better than some genius's half baked effort.

[DaveArb]

I disagree with Gates' quote. I know that today I'm certainly a better programmer than I was 10 years ago, and 10 years ago I was a better programmer than I was five years before that.

Gh0st wrote: "I play the guitar and I have improved a lot since I was a kid but nobody can teach me how to be Jimi Hendrix"

I don't disagree with that, but would you describe Jimi Hendrix (or even Townshend, I guess ;)) as a "good" guitarist? If the Gates quote was changed to whether you're a superstar, one of the best hundred in the world, programmer or not, I'd be inclined to agree with him then. Talent vs. skill, there's a place for both IMO.

[yaaarrrgg]

So all this has nothing to do with programming skill but has everything to do with motivation.

I agree.... I think it's funny in the U.S. very few people can remember what a penny looks like. Is Lincoln facing left or right? Despite seeing the coins our entire life, we generally don't know, and frankly don't care to :)

[gh0st]

I disagree with Gates' quote. I know that today I'm certainly a better programmer than I was 10 years ago, and 10 years ago I was a better programmer than I was five years before that.

Gh0st wrote: "I play the guitar and I have improved a lot since I was a kid but nobody can teach me how to be Jimi Hendrix"

I don't disagree with that, but would you describe Jimi Hendrix (or even Townshend, I guess ;)) as a "good" guitarist? If the Gates quote was changed to whether you're a superstar, one of the best hundred in the world, programmer or not, I'd be inclined to agree with him then. Talent vs. skill, there's a place for both IMO.

Yeah you're right I suppose, what I think is a "good" guitarist or "good" anything for that matter is subjective. Everyone has their own tastes and preferences. I don't agree 100% word for word with the Gates quote but what I took as the underlying sentiment I would agree with.

I've only been programming for a few years and I learn new stuff all the time, I recently learnt Python which I didn't know anything about a year ago. I think there is a distinction between having knowledge and ability to apply that knowledge though. Everyone has their own level they're comfortable at and there should be room for everyone definitely.

I suppose I would say a "good" programmer IMO is one who gets the job done and accomplishes what they set out to. Not necessarily who can do it fastest or with the least lines of code or whatever people use to challenge each other these days :D

[tkjacobsen]

He just says that because he haven't met any good programmers working for microsoft..... ;)

[LordHunter317]

Programming isn't a skill that requires a large amount of innate talent, so he's largely wrong. Innate talent can help make it eaiser, but everything that talent would cover would be learned.

The same is true of engineering: it's a taught profession. No engineer goes to school knowing how to thing like an engineer. Yet the process is succesfully taught to thousands every year.

[Note360]

I still believe that you can accomplish the feat even if your not born that way. However, it will require intrest, working your *** off and amongst others seeing things differently. The seeing things differently can be learned and is what makes a good programmer. It cannot be learned in the common sense but it can be accomplished.

Also your wrong about becoming a good musician whoever posted that. Sometimes the best musicians are those who aren't innate. Did you know that Miles Davis used to be booed off stage. HE worked hard and became one of the best musicians. I would also agree that having intate abilities is a cripple because it can make you lazy, kinda like how rich people are crippled.

[Wybiral]

Music has two edges, being able to write good music, and being able to play good music.

Writing good music is something that is hard to develop, it's mostly innate. Sure, you can study music theory, learn a bunch of scales and chords and harmonic relationships... But that isn't going to help you write good, original music.

Being able to play good music is different... It's a mechanical process, it's muscle memory. There are plenty of musicians who simply play music that others write or orchestrate. This does come with practice, anyone can learn how to PLAY an instrument.

My point is this... Any musician who learns to use scales and knows how to play their instrument can play good music and would fit in very nicely with an orchestra or band... Even if they aren't always pumping out original ideas all day.

Any programmer can learn the basics and learn their languages well enough to type what they are told to. Solving problems in programming is like a professional musician being told "play a solo in harmonic minor to the D key" they don't have to be passionate or even original if they can go by the book and play music that fits.

Most programmers do just that... They are members of an organized orchestra playing music by the book. I think anyone can eventually learn to do that. Sure, it takes practice and knowledge, but anyone can learn...

I don't think everyone is able to design completely innovative software or come up with completely original new ways of doing things (like Hendrix was with the guitar)... I think that's a natural thing, not that market research doesn't have a lot to do with that in most companies (and musicians for that matter). But that's not really what the industry and companies like Microsoft are looking for in a programmer...

[LordHunter317]

Writing good music is something that is hard to develop, it's mostly innate. Sure, you can study music theory, learn a bunch of scales and chords and harmonic relationships... But that isn't going to help you write good, original music.Yes, it is. All masters in every artistic field have had intense training in the technical side of it. And it improves their work.

That's true of everyone I know personally who practices a creative art: writing, photography, painting, and dance. All of them have natural talent but formal training has greatly improve their skills, sometimes immensely so.

The progression is quite clear looking at my girlfriend's freshmen year photography versus her current stuff.

Being able to play good music is different... It's a mechanical process, it's muscle memory.Actually there is still innate talent there; much of what we call talent is simply greater natural physical ability.

Plus, there are many people who can play multiple instruments and can transition and learn new instruments eaiser than others, so I think in both cases you're erring too far to the extreme.

Solving problems in programming is like a professional musician being told "play a solo in harmonic minor to the D key" they don't have to be passionate or even original if they can go by the book and play music that fits.Most problems in programming cannot be solved that way, despite the popularity of design pattern books in the modern age.

They're design problems. Design problems cannot be solved with canned solutions; even when they can be you still have to go through the entire design process (as a matter of due diligence if nothing else).

I don't think everyone is able to design completely innovative softwareComing up with innovative ideas is irrelevant. You're reach out to a creative spot well beyond where a programmer or even a software engineer enters in. That's not to say that they cannot do such things, but it's certainly not a requirement.

My creative thought at coming up at new, innovative ideas is terrible. Yet, it hasn't slowed my course of study one iota.

[adssse]

I have enjoyed reading all of your thoughts on this subject and hope to read more. I wasnt sure anyone else would find this interesting, but it made me think. I recently graduated from college and am in my first programming job. I dont really feel that I am a great programmer, but have a desire to become better. I find myself reading programming books and discussing topics in my free time and like to believe that this will help me to become better. I also see other programmers that I work with who are much more experienced and generally seem to be 'better' due to this. I often ask questions and try to pick their brain to attempt to gain more knowledge. Overall I agree that possibly one of the most important qualities of a programmer is an interest in what they do.

[Note360]

Hmm, I am not sure if the innate ability is inborn or came across. Technically any one can do anything and that is what it comes down to. I wouldnt say that "only certaint peopel can do this" or anything. Lets put it to you this way, a composer can start off being bad. However, they can become the best composer in the world if they come across sort of a revelation. People change. I wouldnt say that what people are born with is all they got.

[LordHunter317]

Hmm, I am not sure if the innate ability is inborn or came across.Some is clearly inborn. Not everyone can have the physical reflexes to hit a 90+ MPH fastball, no matter what. Conversely, there's probably no one who can do it without serious training either.

But I have a hard time believing that the biology doesn't play a role when you're talking about the tops in any field. What I do believe is biology plays far less a role in some fields than others. Programming is one of those things, because the thought pattenrs are not generally innate to us, they're learned. They're also not heavily socialzed patterns either: we don't value rationality and logical thought proccesses at a young age because our brains aren't attuned to them. We do value creativity and imagination because there's a narrow window for those portions of our brain to develop.

Also, things we value talent in (e.g., art, atheltics) we've generally being doing for a very long time, so there's likely some hereditary knowledge there.

[xtacocorex]

The same is true of engineering: it's a taught profession. No engineer goes to school knowing how to thing like an engineer. Yet the process is succesfully taught to thousands every year.
I disagree with that, I was thinking like an engineer well before I went to school to be one.

In general, talent has a lot to do with how people excel in life, but something does have to be said about hard work and dedication. You can work hard, but if you aren't dedicated, you won't be successful.

[LordHunter317]

I disagree with that, I was thinking like an engineer well before I went to school to be one.You probably demonstrated some of the thought patterns, but I doubt you thought in an actual rationalized, validated design process.

No one does, even if they think they do. Plus, large aspects that are implied in the process (such as simplifications of models) aren't taught and aren't natural; we don't remove data naturally in a fashion that's safe for design. That's because we do it by arregation, which doesn't generally work for design in the small. It occasionally works for design in the large, but it depends on the design.

[Somenoob]

Just improve your mathematical and engineering skills(by learning and using) and you'll be fine.

[yaaarrrgg]

Writing good music is something that is hard to develop, it's mostly innate. Sure, you can study music theory, learn a bunch of scales and chords and harmonic relationships... But that isn't going to help you write good, original music.

Lennon and McCartney were writing terrible, awful music for years (actually I think ten years), before they started cranking out any of the catchy tunes we know today. Even when they were signed to a record label, the producers noted that they had "no writing ability." If you hear the music they were writing at the time, you might agree. Of course, I think you can usually see hints of talent even at early ages, IIRC McCartney wrote "When I'm 64" when he was 16. But generally, it takes many artists ten years or more to develop into what we know them as.

IMO, what drives some artists to be better than others, in most cases, is an obsession to perfect the quality of work, which almost borders on mental illness (like OCD). Even Mozart remarked that to write good music requires "love" of the art more than intellectual abilities.

[Null Reference Exception]

"I can talk to somebody about a program that he's written and know right away whether he's really a good programmer."

So then a good programmer needs to be able to communicate well. He determines a really good programmer from talking rather than seeing the work.

From CodingHorror:
"Good developers are good at programming. Really good at programming. You might even say fanatically good. If they're anything like me, they've spent nearly every waking moment in front of a computer for most of their lives. And naturally, they get better at it over time."

So over time the good developers get better. But you cant learn to be a good programmer. They must have just woken up one day as good programmers. Then they get even better by sitting at a computer most of their lives. Bit like Superman I guess, he was just naturally had those superpowers. Sorry but I think if you spend most of your life at something and are only "good", your probably just average like the other 97% they claim aren't as fanatically good as them.

What a load of ego stroking BS. Stop talking yourself up, putting others down, and get back to developing software.

And I agree with some others comments, you will do much better at something you are interested in. I think in general you will find those that are great at what they do have a real passion for it. If your hearts not in it then its hard to get the mind in it too.

[pmasiar]

OK, to have meaningful discussion we need to define "good". IMHO value of "good" s/b more than "better than average".

If we think like scientists, we need to beyond waving hands - we need to think in numbers and exact terms - which is SD - standard deviation (http://en.wikipedia.org/wiki/Standard_deviation) and it has rules (http://en.wikipedia.org/wiki/Standard_deviation#Rules_for_normally_distributed_ data)

Let's say "better than average" is more than 1 SD higher than mean. Less than 20% of {normal) population is better than 1 SD over mean.
"Good" is more than "better than average" - let's say it is 2SD over mean. 2.2% of population is 2SD or more over mean.

Another statistics (found, as funny as it is, also in Coding Horror blog (http://www.codinghorror.com/blog/archives/000635.html)): it cites academic research, which found that most people can’t learn to program: between 30% and 60% of every university computer science department’s intake fail the first programming course. And it claims that cause is: most people never build mental model for assignment - even at least 30% of people who are interested in becoming programmer, fail.

Now you can ask: "Why so many forum members disagree?" For a statistician, answer is obvious: forum members are not representative sample of the overall population. It is self-selected sample, and self-selected sample is always suspicious for a statistician. Answers of self-selected sample can tell us nothing about population as a whole and are worthless as science.

Instead, try to get the test provided in linked article to some of your friends and see if the have mental model of how assignment works - and if they have chance to become programmers :-)

[akudewan]

OK, to have meaningful discussion we need to define "good". IMHO value of "good" s/b more than "better than average".

If we think like scientists, we need to beyond waving hands - we need to think in numbers and exact terms - which is SD - standard deviation (http://en.wikipedia.org/wiki/Standard_deviation) and it has rules (http://en.wikipedia.org/wiki/Standard_deviation#Rules_for_normally_distributed_ data)

Let's say "better than average" is more than 1 SD higher than mean. Less than 20% of {normal) population is better than 1 SD over mean.
"Good" is more than "better than average" - let's say it is 2SD over mean. 2.2% of population is 2SD or more over mean.

Another statistics (found, as funny as it is, also in Coding Horror blog (http://www.codinghorror.com/blog/archives/000635.html)): it cites academic research, which found that most people can’t learn to program: between 30% and 60% of every university computer science department’s intake fail the first programming course. And it claims that cause is: most people never build mental model for assignment - even at least 30% of people who are interested in becoming programmer, fail.

Now you can ask: "Why so many forum members disagree?" For a statistician, answer is obvious: forum members are not representative sample of the overall population. It is self-selected sample, and self-selected sample is always suspicious for a statistician. Answers of self-selected sample can tell us nothing about population as a whole and are worthless as science.

Instead, try to get the test provided in linked article to some of your friends and see if the have mental model of how assignment works - and if they have chance to become programmers :-)

Oh yes, you are a good programmer :lolflag:

[lnostdal]

(.. random-rant-mode .. some of you might already have mentioned what i'm posting here; i haven't bothered with reading :P)

maybe the problem people have with assignment has something to do with timing.. i mean; mathematics often seem to talk about declarative "instant" stuff where time isn't involved at all -- like:

3 + x = 5

..which means x must have been 2 all along from "the start" in that little world because of the = sign here is _declaring_ something instead of _doing_ something.. as soon as 3 is changed to 4, x is instantly changed to 1 as long as the = is there balancing up things as a "declaration of all that is true at any given instant in time"; so time doesn't exist because there is never any changes

while in programming one describe steps (non-declarative) that the computer is to do in a thread/sequence of execution over time:


x = 2
3 + x // returns 5


x isn't "always" two here like it is above .. first it does not exist, then it is set to be 2, then it is read and given as an argument to a function + that also takes another argument 3 returning 5 ..prefix notation is great here btw. (+ 3 x) => 5 .. no doubt about what's going on here, + is a function like any other that takes two arguments; simple

you can easily see what's going on:

int a(){ printf("a\n"); return 10; }
int b(){ printf("b\n"); return 20; }
int plus(int x, int y) { printf("plus\n"); return x + y; }
printf("%d\n", plus(a(), b()));


..or in a cooler language (check the bottom of the post for an even cooler version):

cl-user> (defpackage :my-cl
(:use :cl)
(:shadow :+))
#<package "MY-CL">
cl-user> (in-package :my-cl)
#<package "MY-CL">
my-cl> (flet ((a () (write-line "a") 10)
(b () (write-line "b") 20)
(+ (x y) (write-line "+") (cl:+ x y)))
(+ (a) (b)))
a
b
+
30


so things happen in sequence; in steps .. nothing is declared and implied as a truth..


well, so when people see:
a = 10
b = 20

..then..
a = b

they are thinking that this can never be solved to have = "return true" because there are no `x' for them to fill in for it to return true.. something like this would have made sense to them:

a + x = b

"ah! x must here be 10 because 10 + 10 = 20 is true!"

..maybe this is why = and == in languages in the C family can lead to boring bugs in general btw.:

if(a = b) { /* duh */ }
if(a == b) { /* yay */ }

..just babbling here (beer talking?).. programming isn't like mathematics at all IMHO.. there is more timing involved, and programming languages lack rich ways of expressing declarations; they are imperative instead of declarative

(there are examples of programming languages with more declarative support however .. i've been experimenting a bit with prolog implemented in lisp)


edit1:
now, about becoming programmers .. some cannot do it (for any given reason), some can do it, some can do it well, some can do it very well -- and all except the first one can at all times improve in smaller or bigger steps .. there is no "end" in programming

edit2:
another version of the lisp-thingy above .. note that i'm typing (+ a b) .. like both a and b where regular variables:


my-cl> (format t "returned value is: ~A~%"
(symbol-macrolet ((a (progn (write-line "a") 10))
(b (progn (write-line "b") 20)))
(flet ((+ (x y) (write-line "+") (cl:+ x y)))
(+ a b))))
a
b
+
returned value is: 30


btw. this forum totally ruins the indentation which is very important to be able to read lisp ... :(

(*shrug* .. back to interfacing with GTK+ i suppose; C is such a drag)

[undertakingyou]

Great topic. I think one big point is being overlooked. Bill Gates was quoted as having said that (and I'm paraphrasing) you didn't need to learn anything about programing to be a programmer. You just needed to start looking at other peoples code and go from there.
We are really going off about a man who has taken everything he has done, starting with when he was arrested for stealing computer time at a major university, to where he took qdos and reported it to fit on another platform.

Really, anyone can become good at anything. What talent will give you is that it may come easier. But passion to succeed is a talent also, and can cause a person to be great at something they have no talent at whatsoever.

Great post and thoughts :KS

UNDERTAKINGYOU--
------------------------

[LordHunter317]

OK, to have meaningful discussion we need to define "good". IMHO value of "good" s/b more than "better than average".No, it doesn't. "Average" and "good" have nothing to do with each other when discussing quality.

Otherwise, programs like Six Sigma would be pointless. They strive to get acceptable (read: good) quality of everything that falls within six sigmas of variation.

Frankly, based on that error, there's no point in talking about much else in the post, since it all else is invalid based on that. But you make some other errors worth commenting on.

Another statistics (found, as funny as it is, also in Coding Horror blog (http://www.codinghorror.com/blog/archives/000635.html)): it cites academic research, which found that most people can’t learn to program: between 30% and 60% of every university computer science department’s intake fail the first programming course. And it claims that cause is: most people never build mental model for assignment - even at least 30% of people who are interested in becoming programmer, fail.Sure, but that's true of lots of other degrees of study, like engineering. There are a lot of reasons for it, I think. Especially in the United States. I won't go into them because I don't really think they're germane and they're really obvious to anyone who's taking a BS at virtually any institution in this country.

Instead, try to get the test provided in linked article to some of your friends and see if the have mental model of how assignment works - and if they have chance to become programmers :-)The test is flawed. Think about it. Again, it's not hard to see the logical error in what they're purposing. You seem to have missed the basic rule that correlation doesn't imply causation.

For example, if you asked anyone in Circuits 101 to solve a simple RC or RLC circuit, they probably couldn't do it. But by the time they reach Senior status, they do it in their sleep. Basing success on the results when people have no prior knowledge is inherently dangerous.


..just babbling here (beer talking?).. programming isn't like mathematics at all IMHO..CS is a branch of mathematics and pure functional languages can have the properties you describe.

[lnostdal]

..just babbling here (beer talking?).. programming isn't like mathematics at all IMHO..
CS is a branch of mathematics and pure functional languages can have the properties you describe.

yeah, adjust to "..most programming isn't like mathematics.." or "..programming is a different kind of mathematics people usually haven't done before.." or whatever as seen fit in context of the general point i'm trying to describe regarding possible reasons for why this problem shows up for some when learning programming

(hm, that horrible thing that adjusts pop-singers' voices so they are kept within tune comes to mind)

you get the idea; i'm not thinking discrete mathematics here with sets and subsets for what belongs where (programming/mathematics) or even keeping within scientifically ways of reaching conclusions

i'm doing some random social non-formal observation and ranting and leaving it up to sloppy old intuition leading possibly to further stories from other peoples own observations and possible explanations.. in other words i do not know nor understand exactly why some people have problems with understanding assignment but i think it has something to do with the introduction of "time" or "timing"

oh, and i did mention lisp/prolog so i am aware of ways of doing pure functional programming - but that's not the point; there is no point really

cheers :)

[hod139]

CS is a branch of mathematics
This seems overly general too me. Using this reasoning once can say that all the sciences are a branch of mathematics since they all require mathematics of some sorts. For example, would you call a physics a branch mathematics?

[Mrfo]

This seems overly general too me. Using this reasoning once can say that all the sciences are a branch of mathematics since they all require mathematics of some sorts. For example, would you call a physics a branch mathematics?
I dunno, when you get into anything algorithm related you start to see alot of math. I'm finding alot of guys in my CS classes didn't quite expect there to be so much math and are starting to change majors.

[yaaarrrgg]

Instead, try to get the test provided in linked article to some of your friends and see if the have mental model of how assignment works - and if they have chance to become programmers :-)

As a silly experiment, I thought I'd try out a version of the "assignment" test with my 26 month old daughter. I used containers, and different kinds of colored toys. As I was explaining the game, she yelled "MINE!!!!" and grabbed all the toys. :)

So, she failed the test I suppose :) Still, I can't help but think she has some concept of assignment, since then she sorts objects and places them into different containers, and also keeps track of toy locations. She then counted the toys as "8 2 8 2 8". What does this mean?!! :)

IMO, how we measure the actual grasp of the concept versus how well one plays the game is difficult. Measuring the potential to understand is even more difficult...

[LordHunter317]

yeah, adjust to "..most programming isn't like mathematics.." or "..programming is a different kind of mathematics people usually haven't done before.."I wasn't talking about general programming, though I suppose that wasn't clear.

you get the idea; i'm not thinking discrete mathematics here with sets and subsets for what belongs where (programming/mathematics) or even keeping within scientifically ways of reaching conclusionsWhich is rather the problem. In engeering, the lines between math, physics, and engineering are fairly well defined. The lines aren't obviously black and white since the subject matter overlaps and is fluid, but the lines exist.

But the software community refuses to define those lines, both academically and professionally. Most CS programs don't teach computer science, they teach programming. The two are almost seperate spheres.

in other words i do not know nor understand exactly why some people have problems with understanding assignment but i think it has something to do with the introduction of "time" or "timing"With procedural programming? Sure. We really should start with Into to Computer Architecture before teaching programmers a single procedural language.[1][2]

Why? Because the application of procedural languages follows the behavior of the hardware, because that's what they're modeled on. Fundamentally, all imperative languages are based on a fundamental model of a computer that is a sequential circuit with specific, common properties. Even languages that are hardware-"indepedent", like Java, are hopelessly tied to this model: the machine has RAM where you can store code and data, the operating system requires allocation (and therefore deallocation) of resources, function calls are stack-based and stack is a precious resource. And so-on, I could keep going, but you get the idea.

oh, and i did mention lisp/prolog so i am aware of ways of doing pure functional programmingLISP is very multi-disclipinary and Prolog is really a logic programming language. You'd be better off saying Haskell or one of its children, e.g., Erlang. ;)

This seems overly general too me. Using this reasoning once can say that all the sciences are a branch of mathematics since they all require mathematics of some sorts. For example, would you call a physics a branch mathematics?Computer Science is the study of algorithms and their computation. As it turns out, the study of computation theory has nothing to do with its practiced application. The parallel is no different to the study of physics and it's application through engineering.

As I said, the issue is that while engineers, physicists, and mathmaticians all define lines around their studies, the software community refuses to draw such lines as a whole.


[1]Actual computer scientists are different because they're learning different material.

[2]If you're not teaching imperative languages, another path may be worthwhile. Functional languages, especially the purer ones, aren't nearly as tied to the model of computation. For example, a pure functional language requires no allocation of storage for objects, freeing them from the concept of memory. This allows tricks like language-provided exploitation of virtual memory, allowing the language to provide as much memory as possible through backing store, without the code being explictly written to take advantage of windowing.

[g3k0]

I agree with Bill Gates. Programming takes a good degree of problem solving skills. (Aside from hello world). Knowledge of code is fine and dandy but using it is another matter. Theres often a much simpler and efficient way of doing things that is overlooked.

[hod139]

Computer Science is the study of algorithms and their computation. As it turns out, the study of computation theory has nothing to do with its practiced application. The parallel is no different to the study of physics and it's application through engineering.

As I said, the issue is that while engineers, physicists, and mathmaticians all define lines around their studies, the software community refuses to draw such lines as a whole.

I don't agree with your definition of computer science. I would call it the study of computation and computing systems. Computer science has grown to cover more than just an understanding of algorithms and computability theory. It now also requires a basic understanding of a computing system. A computer scientist doesn't have to know how a transistor works (leave that to the EEs), but they are required to know the basic concepts of a computing machine: e.g. pipeline and its hazards, memory and caching algorithms, etc. Computer organization/architecture is a requirement for getting a CS degree.

As for the rest of your post, you have made some interesting points about the relationship between the study and practice. I don't know if I would call it the software community's fault, or just a lack of knowledge from the relative infancy of the science; but I acknowledge the disconnect between what a computer scientist actually is versus what the industry perceives is a problem.

[LordHunter317]

I don't agree with your definition of computer science. I would call it the study of computation and computing systems.No, the study of computer systems is computer engineering.

Computer science has grown to cover more than just an understanding of algorithms and computability theory. It now also requires a basic understanding of a computing system.No, it doesn't. A program of study taught solely in Haskell would require understanding nothing about a computer's physical operation whatsoever.

A computer scientist doesn't have to know how a transistor works (leave that to the EEs), but they are required to know the basic concepts of a computing machine: e.g. pipeline and its hazards, memory and caching algorithms, etc.Actually, they don't have to understand many of those things and the CS majors who are taught that aren't taught it until a 400-ish level.

Normally, you don't have to care one iota because the hardware intentionally abstracts things so you do not care.

Computer organization/architecture is a requirement for getting a CS degree.Then why do the introductory texts used at places like MIT not talk about computer architecture at all?

Seriously, you need to look at actual regulated programs, i.e., CpE programs, to realize how off-base you are here. Then look at the variety in the unregulated CS programs. CpE is not a requirement for CS.

[hod139]

A program of study taught solely in Haskell would require understanding nothing about a computer's physical operation whatsoever.

Luckily, computer science isn't a program of study taught solely in Haskell and treating the computer as a black box. Understanding the functional language paradigm (along with the others) is important, and is part of the study.


Actually, they don't have to understand many of those things and the CS majors who are taught that aren't taught it until a 400-ish level.
Just because it is a higher level course doesn't mean it isn't a requirement. According to the ACM (http://acm.org/education/curric_vols/cc2001.pdf), the CS body of knowledge consists of:

Discrete Structures (DS)
Programming Fundamentals (PF)
Algorithms and Complexity (AL)
Architecture and Organization (AR)
Operating Systems (OS)
Net-Centric Computing (NC)
Programming Languages (PL)
Human-Computer Interaction (HC)
Graphics and Visual Computing (GV)
Intelligent Systems (IS)
Information Management (IM)
Social and Professional Issues (SP)
Software Engineering (SE)
Computational Science and Numerical Methods (CN)(emphasis is mine)
Furthermore, they define a "core" body of CS knowledge consisting of 36 hours from Architecture and Organization. (As opposed to the 43 hours of discrete structures or 3 hours of graphics. The full breakdown is in the pdf.) My point is that while a CS major doesn't need to know the architecture at the same level as an engineer, they are required to have a basic understanding of it.


Then why do the introductory texts used at places like MIT not talk about computer architecture at all?
First of all, a CS degree consists of more than just introductory material. Second, who says MIT is correct in teaching functional programming languages first? Focusing on programming at the exclusion of other topics gives a limited sense of the discipline, enforcing the belief that computer science equals computer programming.


Seriously, you need to look at actual regulated programs, i.e., CpE programs, to realize how off-base you are here. Then look at the variety in the unregulated CS programs. CpE is not a requirement for CS.In an accredited computer science program, the students are exposed to basic architecture/organization (among other areas). Can they design circuits? Do they learn embedded systems? Do they know IC design or fabrication? No, this knowledge is left to the engineers. But they do understand the basic model of processor and memory. Hopefully you can see from the ACM computer science curricula report link that I am not off-base. There is more to CS than just theory of computation.

[LordHunter317]

My point is that while a CS major doesn't need to know the architecture at the same level as an engineer, they are required to have a basic understanding of it.The topics you mentioned aren't introductory in the least. Not in any useful sense on modern systems.

And so? I never said they didn't need any at all, what I said was it wasn't CS curicullum. I rarely need knowledge of advanced data structures but I still had to take a course in it.

It's distinct grey area. Even theroetical physicsts have some understanding of how to apply their theory to reality, though perhaps not as thoroughly as an engineer.

First of all, a CS degree consists of more than just introductory material.The point is, if it's so fundamental, it'd be taught up-front. It's not fundamental at all, which is why it isn't taught up front. It's taught much later, because it's useful knowledge to have but isn't necessary to do most of what is required.

Focusing on programming at the exclusion of other topics gives a limited sense of the discipline, enforcing the belief that computer science equals computer programming. I never said focusing on programming, and precious little of CS program time should be devoted to it.

There is more to CS than just theory of computation.Again, I think you're missing the point. If you're not willing to foward the same argument along other disciplines (e.g., physics and pure EE), then you're being extremely disingenous.

Really, look at the Masters and PhD research if you want proof of what CS is really about. Very little of that has anything to do with machine architecture.

[hod139]

I agree that CS has very little to do with architecture, and I never said, nor meant to imply, that architecture was the emphasis of the degree. The problem is that I said CS is also the study of computer systems, and only gave architecture as an example. I don't know why I got tunnel vision when arguing about computer architecture so instead of continuing down this road, how about some more examples of computer systems.

The typical PC is not the only method of computing now-a-days. There are large clusters, grids, ad-hoc networks, stream computation, all of which a computer scientist has to understand in order to develop efficient algorithms and better models of computation. This is why I grouped computer systems into the definition of CS. If the CS graduate has no idea what the grid computing model is, then they won't be able to develop new algorithms.

[LordHunter317]

I said CS is also the study of computer systems, and only gave architecture as an example.Because computer "systems" is really just architecture? That may be why, IMO.


There are large clusters, grids, ad-hoc networks, stream computation, all of which a computer scientist has to understand in order to develop efficient algorithms and better models of computation.Nope, actually not. Again, abstraction. All of those came as results of CS research when the hardware didn't even exist. You're putting the cart before the horse, historically.


Of the CS graduate has no idea what the grid computing model is, then they won't be able to develop new algorithms.Sure they will, because grid systems are compute-clusters where each node functions on independent sets of data. You study that on a micro scale in introductory algorithms.

[stmdk]

Everyone can show some skill in programming with proper training but it takes an internal fire to go the long haul. What do you need though? In my opinion the following…..

Analytical Mind:

Can you look at a problem from all angles? Can you think logically? If not, even learning programming is going to be tough. If you’re the type of person that absolutely hates mathematics to the point where you avoid it at all costs, forget it.

Skill:

Do you know enough about programming? Have you accumulated enough knowledge? Often it takes years to gain enough experience. Start off small and work your way up.

Resources:

Very few programmers know everything. Instead they have year’s worth of code stashed away in storage that they can refer to quickly or utilize in multiple projects. In my opinion the best programmers are those willing to ask another for some help AND willing to share their code. The internet is a goldmine of information.

Heightened Creativity:

Can you think outside of the box? You must be able to come up with new ideas and venture where other fear to journey. The fundamentals of programming are only a foundation. The beauty you build upon that foundation comes from your own vision.

Mental Endurance:

Can you finish what you start? Do you give up easily? Do you bore quickly when working with long term projects? There are many skilled programmers who just can’t finish what they start. Often they can come up with great ideas and solutions but they’re better off directing a development team than doing the actual coding.



Me? I’m missing the mental endurance. I come up with an idea, work on it for a few weeks and then get distracted by another idea. I don’t finish what I start. I have a hard drive full of half finished projects, everything from games to encryption functions. I even started building an MMORPG that I neither have the time to finish or enough assistance to reach my goal in a reasonable amount of time. :(

[hod139]

Because computer "systems" is really just architecture? That may be why, IMO.

Nope, actually not. Again, abstraction. All of those came as results of CS research when the hardware didn't even exist. You're putting the cart before the horse, historically.

It looks like we are arguing about terminology now. IMO, a computing system is the combination of hardware and software. The design of the hardware is left to the engineers, but the study of the "system" is for CS. I can study the architecture of a PC without knowing how the hardware is actually working (e.g. Harvard architecture).


Sure they will, because grid systems are compute-clusters where each node functions on independent sets of data. You study that on a micro scale in introductory algorithms.This misses my point. Focusing on a single cluster removes the distributed nature of the grid. The main difficulty in grid computing is resource management, and this is definitely not taught in an introductory course.

[LordHunter317]

It looks like we are arguing about terminology now. IMO, a computing system is the combination of hardware and software.Perhaps, but you can consider software 100% independent of hardware virtually always, and you can consider hardware 100% independent of all software but the actual machine language. And you do so in both cases for almost the entire breadth and depth of the respective CS and CpE program.

but the study of the "system" is for CS. Clearly, it isn't. You've yet to forward one example where the hardware is required, despite there being several clearly obvious and classical topics you've missed.

Certainly, parallelization of algorithms is not one.

This misses my point. Focusing on a single cluster removes the distributed nature of the grid.No, it does not. You missed my point. You're also confusing terms.

The main difficulty in grid computing is resource management, and this is definitely not taught in an introductory course.Yes, it is. The issue is how to best parallelize your input data, and parallelization of algorithms is taught at every level of algorithm study.

[hod139]

Clearly, it isn't. You've yet to forward one example where the hardware is required, despite there being several clearly obvious and classical topics you've missed.

Hmm, "Clearly, it isn't", followed by "despite there being several clearly obvious and classical topics you've missed". Are you proving my point now? Or maybe everything isn't as clear as you are trying to force it to be.
And for a classical example, I had mentioned the Harvard architecture. If we instead used the Von Newmann architecture then the design of algorithms would be different. For a more personal example, I was recently dealing with a micro-controller on a robot that had no floating point co-processor, yet I still needed to do floating point math. The design of my algorithms was definitely influenced by the hardware.


You're also confusing terms.
No I'm not. A grid is composed of many clusters of resources. Are you confusing this with cluster computing? That was not my intent.


The issue is how to best parallelize your input data, and parallelization of algorithms is taught at every level of algorithm study.I must (sadly) disagree with this. Typically, a CS student is not taught parallelization until mid to high level classes (e.g. OS, networking or Algorithms). I'm TA'ing a data structures and analysis course (typically the 3rd course in a CS program, 2000 level) and the topics range from lists, trees, sorting, graph algorithms, analysis, and design techniques, but all for sequential processes. No mention of parallelization anywhere. The book is "Data structures and algorithm analysis in C++" by Weiss, and is a very commonly used book for this class. As much as I would like agree that CS students are exposed to parallelization early, they sadly are not.

[LordHunter317]

Are you proving my point now?No, what I'm saying is you're aruging along a strawman, you're not presenting the strongest topics to support your premise.

And for a classical example, I had mentioned the Harvard architecture. If we instead used the Von Newmann architecture then the design of algorithms would be different.They're not. Besdies, there isn't a hardware implementation of Harvard out there that cannot be converted to von Numann. And I've yet to met a programming language, besides the machine language, that makes the distinction. Why? Because it turns out it's totally irrelevant: if you have features that make Harvard implementation impossible, you do not care. And if it is possible, then you still don't care: implementation of Harvard code on a von Numman machine is always possible, since von Numman is a simpler model.

For a more personal example, I was recently dealing with a micro-controller on a robot that had no floating point co-processor, yet I still needed to do floating point math. The design of my algorithms was definitely influenced by the hardware.Converting floating-point to fixed-point math is a systems issue, practically solved and very generally uninteresting.

It's in the nasty corner case of "systems programming", one of the cases I was referring to avoid you're missing.

No I'm not. A grid is composed of many clusters of resources. Are you confusing this with cluster computing? That was not my intent.A grid is a single cluster. The resources of each machine in the grid is considered identical, generally (this isn't true for wide-scale distributed grids such as SETI, but certainly the assumptions in terms of everything but CPU are indeed identical).

Typically, a CS student is not taught parallelization until mid to high level classes (e.g. OS, networking or Algorithms). I was specific in saying Intro to Alogrithms and indeed, it's covered in the 2nd and 3rd chapters of Sedgwick.

No mention of parallelization anywhere.Look again, I bet you missed it.

Certainly if the book talks about O(n log n) anywhere or "divide and conquer", then it's talked about parallelization. If it doesn't, then it's trash.

[hod139]

They're not. Besdies, there isn't a hardware implementation of Harvard out there that cannot be converted to von Numann. And I've yet to met a programming language, besides the machine language, that makes the distinction. Why? Because it turns out it's totally irrelevant: if you have features that make Harvard implementation impossible, you do not care. And if it is possible, then you still don't care: implementation of Harvard code on a von Numman machine is always possible, since von Numman is a simpler model.

I agree that programming languages abstract the underlying hardware away from programmer. But that doesn't mean a programmer should not be aware of the architecture, e.g. caching strategies, byte alignment, pipeline hazards etc. Loop unrolling, binary files, avoiding Read-After-Write (and the many variations) hazards; all of these strategies depend on a basic understanding of the hardware. You keep insisting this is "systems" programming, and I disagree and consider this to be required knowledge of CS as well.


A grid is a single cluster. The resources of each machine in the grid is considered identical, generally (this isn't true for wide-scale distributed grids such as SETI, but certainly the assumptions in terms of everything but CPU are indeed identical).
Grid computing uses the resources of many separate computers connected by a network. You cannot generally assume the resources are the same. CPU speeds, memory, even network connections vary from cluster to cluster. The SETI example is the norm, not a special case. On the other hand, what you described is a computing cluster. In a computing cluster, many (usually identical) machines are connected together on a high speed network.


I was specific in saying Intro to Alogrithms and indeed, it's covered in the 2nd and 3rd chapters of Sedgwick.
And I responded with the typical CS student's introduction to algorithms course, Data Structures and Analysis, and stated how parallelization is not covered by this introductory material; it is delayed until later in their study. A course on algorithms is not introductory material.


Look again, I bet you missed it.
The words parallel* or distributed are not in the index and the table of contents makes no mention of parallel algorithms. So no, parallel algorithms are not mentioned.


Certainly if the book talks about O(n log n) anywhere or "divide and conquer", then it's talked about parallelization.
The book covers run time analysis and "divide and conquer" techniques very well, but I fail to see what this has to do with parallelization. Most parallel algorithms are iterative in nature and a convergence analysis is performed, not Big-Oh analysis. The Big-Oh analysis you mentioned is a worse case estimation of the running time assuming sequential processing.

If it doesn't, then it's trash. This kind of strong-arm arguing will get you nowhere. You can't appeal to your own authority as an informative source and call a book trash. This particular book has been named one of the top 30 computer science books in the 20th century (http://news.fiu.edu/releases/2000/weiss6-28.htm).

[LordHunter317]

But that doesn't mean a programmer should not be aware of the architecture, e.g. caching strategies,Transparent. Only ever matter for HPC scenarios, and then it's still based on poor-ish assumptions for a modern operating system.

byte alignment,Handled by the compiler in most languages, and assisted in C and C++ at least, which is virtually the only places you can care, nevermind want to.

pipeline hazards etc.Always transparent, on purpose.

Loop unrolling,See "byte alignment".

avoiding Read-After-Write (and the many variations) hazards;Architecture-dependent heartache. Handled for you in most VM and interpreted languages.

all of these strategies depend on a basic understanding of the hardware. No, they require a deep and thorough understanding of the specific system you are programming. As such, they're hardly interesting at all to cover at any real length unless it's mandatory knowledge on the way to something else.

You keep insisting this is "systems" programming, and I disagree and consider this to be required knowledge of CS as well.But it's clearly not. Applications in Java or .NET simply cannot worry about this stuff[1]. So can't anything run on a VM, or is interpreted. Some of it cannot be dealt with in userspace--userspace cannot do cache flushes on most architectures, since cache lines aren't tagged to tasks.

By making that statement I've already excluded the most popular langauges and really leaving you with C and C++. I can further trivally show that some of those details are irrelevant to all but certain classes of very minority applications, even further limiting it.

And all of it is architecture-dependent and nasty annoying details. I don't even remember them for the processors I've used, since I've built systems around three different processors in the last 12 months. I look it up if I need it. The value of understanding it generally before I have to deal with it is somewhat questionable at best. Certainly, the understanding of all those things I have I almost never use.

You cannot generally assume the resources are the same.Sure you can. SETI requires minimal RAM and network loading, but it requires a certain amount just the same. It's low on purpose, but they exist nontheless. And a whole grid is a cluster, the definition of cluster is somewhat loose on purpose.

The book covers run time analysis and "divide and conquer" techniques very well, but I fail to see what this has to do with parallelization.Divide and conquer is a primary technique for splitting work for parallelization. The rest is generally taking aggressive advantage of algorithm steps that do not have serial dependencies.

This kind of strong-arm arguing will get you nowhere. You can't appeal to your own authority as an informative source and call a book trash. I didn't. Pay more attention to what I've said. You're being really, really poor at that here.

[1].NET Interop stuff can care, to a limited extent.