Introductions to programming suck
-
Ravi Bhavnani wrote:
1984
Ravi Bhavnani wrote:
(a VAX-11/780)
Oooh, you had a VAX? My first experience programming was on a PDP 11 in 1983. I didn't meet a VAX until 1986. (I now own a Micro-VAX from 1986. :cool: ) I agree that programming should be taught from the fundamentals. That's how I'd teach it if I ever teach it.
PIEBALDconsult wrote:
Oooh, you had a VAX?
Heh. I cut my teeth on a Honeywell Multics system in 1980, moved to a Xerox Sigma-9 (yuck) in '81, and then to a VAX in '82. I loved VAX/VMS so much I ended up joining DEC (in '87). Every dev (in the AI group @ Hudson, MA) got their own microVAX, along with access to a cluster of 8600s and 8800s (appropriately named Who, Why, When, Which, Where and How). :) It was a wonderful time... (as are these). :) /ravi PS: I still have my Mass. "VAX VMS" vanity license plate.
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
This is the best introduction to programming I have ever seen. http://drtechniko.com/2012/04/09/how-to-train-your-robot/[^] Wastes no time on silly syntax or computers and gets right to the core of it - logical thinking and problem solving
-
PIEBALDconsult wrote:
Oooh, you had a VAX?
Heh. I cut my teeth on a Honeywell Multics system in 1980, moved to a Xerox Sigma-9 (yuck) in '81, and then to a VAX in '82. I loved VAX/VMS so much I ended up joining DEC (in '87). Every dev (in the AI group @ Hudson, MA) got their own microVAX, along with access to a cluster of 8600s and 8800s (appropriately named Who, Why, When, Which, Where and How). :) It was a wonderful time... (as are these). :) /ravi PS: I still have my Mass. "VAX VMS" vanity license plate.
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Lucky bastadge. :sigh: OpenVMS is the greatest operating system ever, unfortunately (as with BetaMax) being best doesn't earn market share -- being "good enough" at a low price does. I haven't had an OpenVMS job for ten years now. I really only have OpenVMS systems so my skills don't get too rusty.
-
This is the best introduction to programming I have ever seen. http://drtechniko.com/2012/04/09/how-to-train-your-robot/[^] Wastes no time on silly syntax or computers and gets right to the core of it - logical thinking and problem solving
Phil Martin wrote:
logical thinking and problem solving
And that's what it's all about in the end. :thumbsup: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Lucky bastadge. :sigh: OpenVMS is the greatest operating system ever, unfortunately (as with BetaMax) being best doesn't earn market share -- being "good enough" at a low price does. I haven't had an OpenVMS job for ten years now. I really only have OpenVMS systems so my skills don't get too rusty.
-
"I never met a VAX I didn't like." I have. It was a 4000 the dev team used and it was so overworked it couldn't keep time. It lost about fifteen minutes a week and the devs would shout at me because they were always late for meetings. :rolleyes: (I was a system manager so obviously it was my fault.)
-
Phil Martin wrote:
logical thinking and problem solving
And that's what it's all about in the end. :thumbsup: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Like Ravi said, when I learned programming (too many moons ago!) we didn't even have a computer to play with. I recall the first lesson was to devise an algorithm to sharpen a pencil (we had manual pencil sharpeners in each classroom back then). Someone was chosen to do exactly what he was told to do, no more, no less. The rest of the class would start to give directions and then observe the result. After trying to get the guy to walk into the wall or out the door, after trying to sharpen the pencil before it was put into the sharpener, etc., we all had a good idea of how much detail was required to get something done. No objects, no languages, no computer, just an algorithm for something seemly simple. After that, we learned assembly language (IBM 1620) then tackled FORTRAN I.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
Walt Fair, Jr. wrote:
After that, we learned assembly language (IBM 1620) then tackled FORTRAN I.
My first computer too! Assembly language on the IBM 1620... Symbolic Programming System, as it was called. Didn't it have Fortran II rather than Fortran I? That is what I recall. The 1620, modified with 2 additional instructions, was also one of the early real-time computers. IBM called that the 1710 and it was used to synchronize traffic signals in San Jose in an experiment to see if computers could be used for that purpose.
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
Half-disagree. Within reason, language doesn't matter. It just shifts the leven of effect. An important motivation is the ability to change the world, and that's very tedious in assembly. There might be an easy way out: use assembly to control hardware - that's somethign fascinating to many programmers even after decades of doing that. There's another problem, though: The guys doing assembly. I would not want to let any of them near any budding coder pubs.
There are general problems with training programmers: The Architect teaches the mason, the biologist the butcher. There is a huge rift between Comp-Sci and Comp-Do, but they are treated as a continuum. Ideally, we make comp-sci bother more with what matters in practice, and comp-do more open to the teachings of comp-sci1. Unless we achieve that, we may need to clearly separate education for the two. There's no recipe for building software. The industry is immensely dependent on those that "get it", that have - or develop - the knack for making software. HR is unable to tell those apart from those who can't. We are unable to teach how to make software, since we rely a lot on witchcraft and snake oil ourselves.
So I would start off with: Some turtle-graphics-like[^] language very early, just to plant the seed. A mid-abstract, imperative language, to teach the grunt work, and to motivate for planning, miantenance, and further abstraction. A secondary, significantly different language, could even be logic or functional. 1) And it's not entirely comp-sci's fault. We've become very effective at ignoring knowledge that is already availabe for decades, and rather follow the newest fad. Because we are oh so special.
-
Take it from an old fart: there's not much immediate benefit from either.
-
Brings back fond memories of teaching CS101 to freshmen in 1984. In my first lecture, I made the students parts of a human computer - each got an instruction (which they weren't supposed to share with others) and we laboriously walked through a
forloop that counted from 1 to 10. Took close to an hour to get the "program" to finish. I then asked them how long they thought it would take on a mainframe. Responses ranged from "less than a second" to "1 second". I upped the ante and asked what if the loop ran to a 100? A thousand? Ten thousand? Responses were mixed, but nobody was ready for the app to finish running in a few seconds. They were completely blown away. (Learning experience #1: computers are FAST). Next, I made the human computer subtract the index instead of counting up, causing an infinite loop. The kids saw the error right away. We then programmed the mainframe (a VAX-11/780) to do the same thing. Whoops! Infinite loop! (Learning experience #2: computers are STUPID). We didn't write code until week 2. By then, 2 interesting things occured: (1) many students dropped the course and (2) almost all of those who stayed on loved it and got nothing less than a B. It was one of the best experiences of my brief (3 year) teaching career and I was happy to receive an award for being one of the best undergrad instructors at NYIT. :) /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
a human computer
Good concept :)
Ravi Bhavnani wrote:
computers are FAST & computers are STUPID
Made me think of Knight's trading disaster[^]
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Whenever methodologies become productized, objectivity is removed from the equation. -- Mike Myatt
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
Donald E. Knuth[^] the author of The Art of Computer Programming[^] seems to agree: _Why have a machine language? Many readers are no doubt thinking, ``Why does Knuth replace MIX by another machine instead of just sticking to a high-level programming language? Hardly anybody uses assemblers these days.'' Such people are entitled to their opinions, and they need not bother reading the machine-language parts of my books. But the reasons for machine language that I gave in the preface to Volume 1, written in the early 1960s, remain valid today:
- One of the principal goals of my books is to show how high-level constructions are actually implemented in machines, not simply to show how they are applied. I explain coroutine linkage, tree structures, random number generation, high-precision arithmetic, radix conversion, packing of data, combinatorial searching, recursion, etc., from the ground up.
- The programs needed in my books are generally so short that their main points can be grasped easily.
- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird.
- Machine language is necessary in any case, as output of many of the software programs I describe.
- Expressing basic methods like algorithms for sorting and searching in machine language makes it possible to carry out meaningful studies of the effects of cache and RAM size and other hardware characteristics (memory speed, pipelining, multiple issue, lookaside buffers, the size of cache blocks, etc.) when comparing different schemes.
_
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Whenever methodologies become productized, objectivity is removed from the equation. -- Mike Myatt
-
"I never met a VAX I didn't like." I have. It was a 4000 the dev team used and it was so overworked it couldn't keep time. It lost about fifteen minutes a week and the devs would shout at me because they were always late for meetings. :rolleyes: (I was a system manager so obviously it was my fault.)
PIEBALDconsult wrote:
(I was a system manager so obviously it was my fault
Been there, did that. The one time I really enjoyed the job was when I caught a subcontractor snooping around on our machine. I had just become the system manager, and the previous guy had left the entire machine wide open. I added access control lists to project directories and revoked extra privileges granted to just about everyone. The subcontractor screamed like a little girl.
Software Zen:
delete this; -
Half-disagree. Within reason, language doesn't matter. It just shifts the leven of effect. An important motivation is the ability to change the world, and that's very tedious in assembly. There might be an easy way out: use assembly to control hardware - that's somethign fascinating to many programmers even after decades of doing that. There's another problem, though: The guys doing assembly. I would not want to let any of them near any budding coder pubs.
There are general problems with training programmers: The Architect teaches the mason, the biologist the butcher. There is a huge rift between Comp-Sci and Comp-Do, but they are treated as a continuum. Ideally, we make comp-sci bother more with what matters in practice, and comp-do more open to the teachings of comp-sci1. Unless we achieve that, we may need to clearly separate education for the two. There's no recipe for building software. The industry is immensely dependent on those that "get it", that have - or develop - the knack for making software. HR is unable to tell those apart from those who can't. We are unable to teach how to make software, since we rely a lot on witchcraft and snake oil ourselves.
So I would start off with: Some turtle-graphics-like[^] language very early, just to plant the seed. A mid-abstract, imperative language, to teach the grunt work, and to motivate for planning, miantenance, and further abstraction. A secondary, significantly different language, could even be logic or functional. 1) And it's not entirely comp-sci's fault. We've become very effective at ignoring knowledge that is already availabe for decades, and rather follow the newest fad. Because we are oh so special.
I guess you'll like this: On a cultural gap[^] by Edsger W. Dijkstra
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Whenever methodologies become productized, objectivity is removed from the equation. -- Mike Myatt
-
Brings back fond memories of teaching CS101 to freshmen in 1984. In my first lecture, I made the students parts of a human computer - each got an instruction (which they weren't supposed to share with others) and we laboriously walked through a
forloop that counted from 1 to 10. Took close to an hour to get the "program" to finish. I then asked them how long they thought it would take on a mainframe. Responses ranged from "less than a second" to "1 second". I upped the ante and asked what if the loop ran to a 100? A thousand? Ten thousand? Responses were mixed, but nobody was ready for the app to finish running in a few seconds. They were completely blown away. (Learning experience #1: computers are FAST). Next, I made the human computer subtract the index instead of counting up, causing an infinite loop. The kids saw the error right away. We then programmed the mainframe (a VAX-11/780) to do the same thing. Whoops! Infinite loop! (Learning experience #2: computers are STUPID). We didn't write code until week 2. By then, 2 interesting things occured: (1) many students dropped the course and (2) almost all of those who stayed on loved it and got nothing less than a B. It was one of the best experiences of my brief (3 year) teaching career and I was happy to receive an award for being one of the best undergrad instructors at NYIT. :) /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
I would have enjoyed taking classes from you, Ravi!
Software Zen:
delete this; -
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
My first programming class was in FORTRAN and the second was in IBM 360 assembly language. In retrospect the 360 was an odd beast, but it still gave you an appreciation of the 'nuts and bolts' underlying everything. Shortly after that I got a part-time job working as a programmer. I did a lot of work in microprocessor assembly language, and that drove the point home even further. My primary languages today are C# and C++, but I still try to appreciate everything going on underneath.
Software Zen:
delete this; -
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
I agree - for undergrads at least. But many schools teach some sort of programming too - and want to encourage students to select the courses at year 8 or 9 and so go for Gamemaker ans similar - which, frankly, frustrates those that want to program, and simply entertains those that want to play games. I learned 6502 as my first language - and it is an ideal learning language as it is such a simple instruction set. I have also taught using the human computer idea - we used shoe boxes as RAM - and it worked so well, I still had students months later thinking back tot eh shoe boxes whe trying to work out why their program wasn't working! I think you CAN use c# vb .Net etc in an introductory course but it is certainly tricky. I've found it works in schools where students want instant gratification - those that go on to study later are probably best served going back to assembler , though - and the teacher can enjoy the look of amazement as the kids realize just how much the computer is really doing when you write a few lines of high level language.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
I guess you'll like this: On a cultural gap[^] by Edsger W. Dijkstra
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Whenever methodologies become productized, objectivity is removed from the equation. -- Mike Myatt
It's almost as if he got his way, and we are non the wiser :)
-
I've seen tons of people utterly fail to grasp the introduction to programming, and to be honest, I don't really blame them. Many failed to grasp not the syntax of whatever arbitrary language the teachers decided to throw at them (often C++, Java or C#), but the core idea of programming: you're giving the computer a list of instructions that it blindly executes. So I blame the choice of language. The languages commonly used to introduce CS students to programming do not make it obvious what programming actually is, to the beginner it all looks like magic. Especially when OOP is added - without building it on top of something (the way it's usually taught is out of the blue and with flawed real life analogies), that's just pure magic. People who might (I think) otherwise have become decent programmers if they had been taught differently get stuck behind the hurdle of figuring out the core concept for themselves (while getting bogged down in abstract concepts that aren't useful at that stage yet), and give up. IMO a simple assembly language would make a much better first language. It makes the core concept explicit. It's conceptually simple. No confusing abstractions. The syntax is trivial. It really is as simple as a list of instructions. The only problem with assembly (hard-to-manage growth of complexity as projects get bigger) is irrelevant in this situation - you're only going to give assignments for simple straight line code at first, then some conditionals and loops, subroutines if you're brave, nothing unwieldy. ps: I learned z80 assembly as a first programming language so I might be biased.
harold aptroot wrote:
So I blame the choice of language.
First your implicit suggestion is that the language is to blame which entirely ignores the role of the teacher both in teaching and the choice of language itself. Second the concept of programming is difficult because it is something that no one has encountered before they actually learn it. Nothing that they have learned before is like it. Third standard programming languages do not exist to teach. They exist to solve problems. And they were designed with that in mind.
harold aptroot wrote:
People who might (I think) otherwise have become decent programmers
I doubt that. Although it is possible that more people would succeed if teachers were better. All though it would probably only be a small percentage increase.
harold aptroot wrote:
It's conceptually simple. No confusing abstractions.
Which ignores the real difficulty in that one must still get exactly the right sequence the first time for it to work at all. And you might note that there have been languages designed specifically for teaching programming. None of them have been successful in that regard.
-
Half-disagree. Within reason, language doesn't matter. It just shifts the leven of effect. An important motivation is the ability to change the world, and that's very tedious in assembly. There might be an easy way out: use assembly to control hardware - that's somethign fascinating to many programmers even after decades of doing that. There's another problem, though: The guys doing assembly. I would not want to let any of them near any budding coder pubs.
There are general problems with training programmers: The Architect teaches the mason, the biologist the butcher. There is a huge rift between Comp-Sci and Comp-Do, but they are treated as a continuum. Ideally, we make comp-sci bother more with what matters in practice, and comp-do more open to the teachings of comp-sci1. Unless we achieve that, we may need to clearly separate education for the two. There's no recipe for building software. The industry is immensely dependent on those that "get it", that have - or develop - the knack for making software. HR is unable to tell those apart from those who can't. We are unable to teach how to make software, since we rely a lot on witchcraft and snake oil ourselves.
So I would start off with: Some turtle-graphics-like[^] language very early, just to plant the seed. A mid-abstract, imperative language, to teach the grunt work, and to motivate for planning, miantenance, and further abstraction. A secondary, significantly different language, could even be logic or functional. 1) And it's not entirely comp-sci's fault. We've become very effective at ignoring knowledge that is already availabe for decades, and rather follow the newest fad. Because we are oh so special.
peterchen wrote:
There's no recipe for building software. The industry is immensely dependent on those that "get it", that have - or develop - the knack for making software.
HR is unable to tell those apart from those who can't. We are unable to teach how to make software, since we rely a lot on witchcraft and snake oil ourselves.That is overly simplistic. The number of problem domains which software can be applied is vast. And all of those domains require different solutions. And the number of domains keeps increasing at a very rapid rate.