"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
I would actually go a step further with the thread title: Please don't try to teach if you can't.
When I talk to junior (or senior) folks who are learning to program, it will become evident that I've chosen different tools than what they're learning. So the discussion of tool choice is inevitable, especially if I have to admit that I don't know the language they're learning. My typical advice is to choose something that is presented with good learning tools, and maybe one that has tutorials related to a subject matter that they're interested in.
> I would actually go a step further with the thread title: Please don't try to teach if you can't.
The line between teaching a truth and teaching a self-enforcing belief pattern has not been drawn, and I don't know if it ever will be. You can be an amazing teacher and not even know it (by making horrible mistakes that other people learn from by observation, comparison, abstraction, and analysis). Or you can be a really amazing teacher and never admit it.
> My typical advice is to choose something that is presented with good learning tools, and maybe one that has tutorials related to a subject matter that they're interested in.
That's good advice.
Great points. Thanks.
For a variety of reasons, prior attempts at C++, Ruby, PHP never took hold for me. The main reason was I had no compelling project to complete (I have a few now, related to work). Yet, looking back on these episodes, and the experienced programmers will surely laugh, but getting a basic environment up where you can write code, build and deploy is difficult for the uninitiated, if you start on Windows as I did.
Later, with a mac, I did the first 1/3 of the one-month-rails course, which actually saw me through to creating a working ruby environment. There's lots of domain expertise which makes ruby inaccessible to the newb, not the least of which is that the most common IDE is a glorified text editor. Compare this to all the "spell-check" equivalents in Visual Studio.
anyway, now that I have a foot-hold somewhere in programming, I have a frame of reference to look up (and mostly down) the stack. Looking forward to learning more.
pgbovine nailed it. I learned this lesson from mathematics (I studied math in college and theoretical CS in grad school): the best math teachers always introduced a new concept/idea using a "toy" example. A toy example may not have the full generality of the overarching theory/idea, but it has all the essence without any of the abstract inaccessibility.
I try to apply the same lesson when I teach people data analysis: I learned (through my time as a quant on Wall Street) that a lot of people feel very comfortable in Excel but find other data analysis tools (SQL/R/Python) too abstract/scary. So, instead of telling them "Oh, you should use Pandas with Postgresql" or "that stuff can be done better using R", I show them what the equivalent operation looks like in Excel first, then show them how they can be done in SQL/R/Python (See, for example, this: http://blog.treasuredata.com/2014/12/05/learn-sql-by-calcula...)
Also, if i wanted to make windows programs, Win32 was an impossible beast to me. I, to this day, still have no idea how that mystical beast works even though I've coded a few programs in it. Some of these "frameworks" can be a little code heavy and have lots of technical details (MVVM and WPF come to mind) They are completely overwhelming while php and basic are simple and have little magic. That said, if i were to have a child soon, I would teach her racket using SICP.
My first language was MBASIC on a Kaypro 2, because that's the toy my family had to play with. When I branched out (from QBASIC), I first found assembly—first, for the 8085/Z80, because the public library where I grew up sucks at life.
Thankfully, the Internet happened, and I found information about x86 assembly—but better than that, I finally got my hands on more than one C compiler. Then, I discovered Linux and found Perl and Python. Somewhere in this timeline I also found Java, which turned out to be a great way to bring a 486 to its knees.
I'm glad I took this drunkard path through programming. First, I learned how my machines actually work. More importantly, I learned all languages are made of trade-offs. C++ is nowhere near perfect, but it lets me get work done at the level of abstraction I choose, which turns out to be a win for the things I do. But it's definitely not for everyone or every project.
Most importantly, I got a gentle exposure to programming, followed by a series of challenges that taught me without demoralizing me, allowing me to build myself up to the point where C++ seems like a relatively tame beast.
Edit: One of my favorite books ever (http://www.dspguide.com) presents code in BASIC as a least-common-demonimator language. Even a limited tool like BASIC can do amazing things.
How many times did you lose your work due to a fat-fingered FCTN-= instead of SHIFT-=?
At least that prepared 6 year old me for the adult world of "rm -rf . *".
There weren't that many high/entry-level languages back then, though. The argument that BASIC is terrible notwithstanding, it was often either that or a very low-level language.
I run into a fair amount of programmers these days who never worked with a non-garbage collected language, have never even seen an assembly language listing (let alone written code in assembly), etc who are generally productive but end up being really lost whenever whatever leaky abstraction their language/framework/etc is using inevitably breaks in some way and in this situation if the solution to their problem isn't immediately Google/StackOverflowable they are standing in front of a brick wall because they've never worked in a language or environment that wasn't abstractions upon abstractions over how computers actually work at a fundamental level.
I'm sure there is some amount of get-off-my-lawnism going on here and I know it isn't universal (there are still young kids writing real bare metal bit-banging code, especially in the maker/"IoT" space), but I think that while highly programmer-time-productive languages and frameworks are great we're still at a point where those skipping over the fundamentals the technology is built on do so at their own peril in terms of how effective they can be when things don't go as planned (and in software things rarely go as planned).
Well, there are plenty of microcontrollers running on Javascript/Ruby/etc, so if people are still writing "real" code, it won't be for long.
I'm not suggesting JS/Ruby/whatever code isn't "real" code, but it is pretty common to see people talk about some JS/Ruby/etc code being "bare metal", totally abusing the classic meaning of the term.
Examples (just a couple out of many dozens I've seen over the past few years):
http://video.kiberpipa.org/jsmeet_slavic_performance_optimiz...
Efficient JavaScript is great! But it isn't bare metal programming.
Also people will be writing low-level C/asm code on small devices for quite a long time yet. While it is great that you can get small "IoT"-style devices with the power to run a JavaScript interpreter, such SoCs are still really expensive by "chip whose cost must be factored into every device manufactured" standards.
It's hard to teach this stuff to beginners because it will probably be useless by the time the get good enough at programming to do anything. Add to that the fact that there are probably 15,000 different platforms all doing the same things in subtly different ways .
PS: 'subtly' is a horrible word.
That kept me focusing. And, I learned it and mostly got better grades than the "student" types as well. (B.Sc Computer Systems).
Generally it seems for some of us it is easier to focus once things make sense and has a purpose.
"Studying" seems to be for people with infinte lifespans and neverending funding, I never had any of those and I guess it affects my learning style ;-)