Introductions to programming suck
-
jschell wrote:
Which is why just the education itself is mostly worthless
Hmm. To my mind the education by itself, or being a self-taught programmer without formal education, are both weaker in the long run. A formal education at least tries to show you a range of approaches to solving problems. Unfortunately the education rarely teaches the practical necessities of the workplace. I've worked with several self-taught programmers, and they all share a common attribute: every problem's a nail, and they have a favorite hammer. Their responses are limited, and they often have bad cases of Not Invented Here syndrome. A good education plus an internship with a company that will teach you practical skills is the best of both worlds.
Software Zen:
delete this;Gary Wheeler wrote:
A formal education at least tries to show you a range of approaches to solving problems.
Yes but the "tries" is the issue.
Gary Wheeler wrote:
I've worked with several self-taught programmers, and they all share a common attribute: every problem's a nail...
I have worked in places where everyone had a degree and there was no plethora of advanced thinking there. One of the worst programmers I worked with had two PHDs.
-
harold aptroot wrote:
I said I blame the choice of language
Someone besides the students made that choice. Those people are responsible for the aptness of that choice.
harold aptroot wrote:
That doesn't mean it's inherently impossible.
It does however make it more likely that it is impossible.
-
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`m just glad there`s a Person behind all this, programming! :rolleyes: Where are the step by steps tutorials?:confused:
http://tomtotom1.regfix.hop.clickbank.net http://tomtotom1.tspecial.hop.clickbank.net/?tid=REAL http://www.viralpdf.com/classicedition/index.php?&aff\_id=5183 http://tomtotom1.googlecash.hop.clickbank.net/?tid=SEEME http://tomtotom1.innantech.hop.clickbank.net/?tid=SEESE
-
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.
Z80 -- Luxury , I had to make do with Sinclair Basic. You had to be very gentle with the ZX81 if you that 16K RAM Pack , when you got to the end of the program and pressed that final key with a flourish , the RAM Pack connection flexed and whoosh away went all your work . There was nothing to save to your cassette recorder . Maybe the scrathcy Led Zepplin recordinsg were safe after all. Nostalgia ain't what it used to be ;) Mike
Mike
-
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 consider Assembler not to be a good first language simply because there is very little introductory literature about it, at least none that makes a point of also introducing the general concepts of computer programming. I didn't learn programming until I entered university in the early 80s, and then the first languages were Pascal, then Assembler. I believe the order and choice of languages makes sense, since the first approaches the human-computer interface from the human side, whereas the latter approaches it from the tech/computer side. I am convinced that for someone not familiar with computers, the human side approach is better. But for really understanding computer languages in general, you need to look at the tech/computer side too. My favorite book at that time was COMIC-PASCAL by Helmut-Zwittlinger[^]. The comics therein were of questionable quality, but the real-world analogies used to explain language structures were very well chosen and illustrated. Unfortunately the book is german only (or maybe I should say austrian - it does use some choice words from austrian dialect) P.S.: Many of my fellow students already had learned some language. Usually C=64 Basic, or the equivalent Basic from Apple II, and some even delved into the 6502 Assembly. It didn't make them better students however. To the contrary, they had to unlearn their bad habits and generally had a harder time to learn properly structured programming techniques compared to those unbiased by a priori computer knowledge.
-
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
I remember a team-building exercise (not specific to programming, but it applies) where we told everyone to write out complete instructions on how to make a peanut butter and jelly sandwhich. After giving everyone some time, the presenter would then collect and "follow" the instructions as written without adding "assumed" steps or details. Frequently, this would involve getting to a certain point and not being able to complete it or with humerous results (you have to be willing to get messy). For example: --Take 2 piece of bread. (If did not specify opening the bag, it was ripped open. If they did not specify putting it on the table or plate, parts would be dropped.) --Put peanut butter or jelly on one piece of bread. (Could put the entire jar onto the piece of bread. If they did not say to open the jar, the presenter could tap on jar but not be able to continue. If they did not specify spreading with a knife, it would be done using fingers. Can optionally spread it on both sides of the same slice if they did not specify just one side.) --Put both pieces of bread together. (Could put with messy sides out or bread slices offset by 45 degrees.)
-
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 did an intro for high school students where we made a dessert. It was some sort of an easy made-from-Oreos thing, but they had to split into teams, and then half the team had to give instructions to the other half for making the dessert...and the "computers" had to follow the instructions exactly. So, if they said "empty the sugar" before the cup was over the bowl, well, it landed on the floor. It was messy, but in the end some projects were edible, and I think it said a lot about the precision of thinking as well as about instruction ordering.
JonShops -- Fun really begins with the words, "So what in the World do I do now?"
-
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.
The intro course I took back in 1981 used IBM 360/370 Assembly Language. I think it does show the details of what's happening better than most modern intoductory languages. Perhaps it would be best if intro classes for those serious about programming used a VM and either Assembler or perhaps a new low level language designed for that purpose.
-
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.
The 1620 had Fortran II. If it was a disk system, it was Fortran II-D; otherwise you ran a lot of cards through the card reader. The assembly language (Symbolic Programming System) was similarly either SPS II or SPS II-D. I still have a few Fortran programs on cards in my bedroom closet.
-- Harvey
-
Walt Fair, Jr. wrote:
...After that, we learned assembly language (IBM 1620) then tackled FORTRAN I.
The 1620 had Fortran II. If it was a disk system, it was Fortran II-D; otherwise you ran a lot of cards through the card reader. The assembly language (Symbolic Programming System) was similarly either SPS II or SPS II-D. I still have a few Fortran programs on cards in my bedroom closet.
-- Harvey
Yes, the later versions of the 1620 came with FORTRAN II-D, but earlier versions had earlier versions of FORTRAN. There was no FORTRAN compiler at all on the one we used in high school, and yes, we did run lots of cards through the reader!
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software