91–100 of 140 posts
This is just retarded. Tell me the rules first so I can infer on right premises.
If you don't know anything about programming then it is ok to assume a = b as a comparison, so the answer is False?, or that a can be assigned to b? left to right? right to left? who knows? how about assigning just adds the new value to the existing one and removes the assigned value? so a=30 and b=0? What's this int about, interrupt? interfere, interrogate? This is just retarded. Tell me the rules first so I can inf…
I see this largely as a failure of education. You see this issue in many areas and much earlier on like teaching mathematics. In schools there tends to be one method used and that method doesn't suit everybody. I see this at work. I've known programmers who, when they get a new hire, will basically let them flounder. I guess the basic idea is that if you're "good" you'll "figure it out" (with minimal time investment…
Similarly, when learning to be a Jazz soloist, students are encouraged to practice the great solos from Jazz legends of history over and over, by rote - just keep doing it. Eventually an aptitude develops and the student just gets to reach in and feel for why a particular set of notes might be chosen, or a certain ornament here, a pause there. Somehow, this can then develop into their own particular style and personality too, and evolve beyond mere emulation.
As musicians progress, they begin to develop higher and higher level abstractions for music; being able to use subtle nuance to relate complicated lines of melody, harmony and counterpoint is one example. Another practical example is how musicians over time develop better models for music itself. There's a natural progression; a novice will struggle to play even a familiar melody on their one instrument, an experienced musician will be able to play it with ease on more than one instrument - even if they have never played it before on that instrument, a master musician will be able to transpose the melody into a different key, rework it, add nuance ... and so on. At the beginning the novice can only model the ordered movement of fingers, but the master is modeling relative pitch changes, fluid timings, potential note substitutions and so on.
I find programming to be similar. With a range that goes from being able to type in a hello world program in a procedural language, to higher-orders of thinking required to model concurrent functional systems and have a see that a tiny defmacro might be the best way to re-work a whole piece. There is a progression, and it's intrinsically mysterious how the mental models work, but it's clear that they come with practice.
Through this lens, "Talent" might best be thought of as "An innate willfulness for practicing" rather than some genetically encoded aptitude for the task at hand. There are many communities where musical education is essentially mandatory, and near enough to anybody can become a good musician if they are required to practice. Some militaries arbitrarily assign soldiers to pipe regiments, treat it as a learnable task, and make them get on with it - and it works.
It may be well worth looking at how music is thought, and seeing if there are any dividends for the educating of programming.
int a = 10;
int b = 20;
a = b;
int a = 10
a = b
b = a
x = x + 1
What we're seeing here is essentially a pun: the use of '=' for at least three different things (binding, mutation, and mathematical equality). To my knowledge, only Lisp gets this right (although there must be others). For example, in Scheme we would have
(let ((a 10)
(b 20)))
(set! a b)
(= a b)
I'm certainly prepared to believe the hypothesis that some people will just never 'get' programming, but we should consider the possibility that bad notation is part of the problem. Given how entrenched it is, changing notation might be unwise, but at the least we can acknowledge and explain ambiguous notation rather than treating it as self-explanatory.
I've worked with freshman CS students. The aggregate breaks down like this, loosely: 20% succeed, always. Hackers/nerds, basically. 80% might succeed. They don't have the talent. They succeed or fail on teacher's competence and their own hard work and background. 20% fail, always. Cheaters, people who are constitutionally incapable of getting it, misplaced students, people with health issues, etc. The 80% is what a t…
Harder than percentages? Sorry, couldn't resist. :)
10/80/10 would be how I would break it down.
I've been fairly skeptical of this paper ever since reading Alan Kay's rebuttal: http://www.secretgeek.net/camel_kay.asp
I trust Kay much more than these authors on matters of computer science, teaching, or ideas in general.
To expand a bit, I've since mentored over a dozen students and I've found that in most cases of students who couldn't program well, the issue was "further upstream." That is, there was some misunderstanding at a more fundamental level that was preventing them from continuing forward. Once that issue was fixed, they rapidly catch up to where they should be.
Earlier quoted context omitted.
It would be a lot easier to teach CS to 18 year olds if they had stronger foundations in algebra, logic, and abstractions. When "teach a bunch of freshmen to program" is your mission statement then it's perfectly understandable to prefer the students with solid fundamentals.
No, it's not. Sorry to be blunt, but it seems colleges want more and more of their students. Already know how to program and have several jobs under your belt to prove it? Step right in, of course we'll accept you over the schmuck who wasted his high school drawing or playing music. It angers me that what is primarily an educational institution insists on having their students pre-educated. You'd ideally want your st…