"Young people occasionally ask me whether language X is something they'll need to make computer games, or what they should learn if they want to become programmers. And what language should we teach in school?"
Thought I'd post this here. Full article by a current programmer for Funcom (Anarchy Online): http://enno.homeunix.net/index.php?itemid=224
>>100
Elevator controllers.
> Except you don't want to teach people powerful languages as their first language.
Why the hell not? First you (I assume you're >>94) argue you can learn C in "little bite-size increments", now you claim you shouldn't do such a thing in another language?
Regardless, the relevant issue here is as thus: it has less to do with the power of a language, and more with its learning curve. And you can do a lot in Python without using its generators. How much can you do in C without pointers? This isn't even the same ballpark...
> damn near all of system-level software in modern Unix-like operating systems
May I be the first to point out that most of said system-level software need not be written in C? Indeed, the world might have been better off if a more powerful language had been used (and a less shitty library that thinks we're still in the era of the PDP and VAX). Think of all that wasted productivity.
Furthermore, >>100 is bang on. When was the last time you looked for employment?
Pascal reeks of old, but I'd still teach Pascal first. It's simple and straight to the point of the first paradigm one should learn - traditional/imperative/structured programming.
Then I'd move on to C and see things from a low-level standpoint, and from it I'd go to Python which is a pretty good, clean language IMO.
I just wouldn't teach Python first because it deals with more complex things (objects, references, lists, etc.) which you are bound to stumble upon if you do anything with it. Besides, people might think less of it if they see it first, or they may never discover the good stuff it has.
As for OO, no OO for starters, that's a bad idea; and much less Java, which is a crappy language with a crappy API that's going to get students nowhere.
> How much can you do in C without pointers?
Without pointers, not much. Without pointer arithmetic, lots and lots.
It's not really pointers that are hard. It's the pointers-to-base-types and pointer arithmetic that is hard. You can teach a whole lot by just ignoring the existence of these things. As long as you treat pointers to system structures and objects as opaque types, you've basically got what Java has, and nobody says Java is too hard because it uses object references.
Sooner or later you have to learn these things, but you don't have to learn them right away. The learning curve shouldn't suffer if you don't go our of your way to make it hard.
> Without pointer arithmetic, lots and lots.
In C, [] is pointer arithmetic. Would you live without arrays?
Pointers aren't hard, but they require you to be agile enough to think of them, and have pretty clear concepts of variables and memory organization. For example, if somebody thinks ***a is more complex than **a, he needs to improve on this.
>>103
I think you should really have a functional language as the second or third. Teach some easy scripting language like Python or JavaScript as a first language, then C and a functional language as the second or third. That sort of balanced mix will get people to be able to think about programming from a variety of perspectives.
That's what it is, but you don't have to know that. You can pretend it's just a magic array index operator, until you reach the point where you're ready to deal with it in more detail.
That sort of approach will also mean each new language is as hard as the first one, since you can't carry over most of your earlier knowledge. If you're smart, you'll probably take it in your stride, but if you're smart you're going to learn this stuff sooner or later anyway. If you're not so smart, you're just learning a bunch of stuff that won't really benefit you and that you would be better off without.
Of course, I think functional languages are largely a waste of time (except maybe as a warning as to why you shouldn't let failed maths majors do CS).
Newsflash: Learning can be hard. Programming is a hard subject. Learning a hard subject is extra hard. Some people will have trouble with it, sure, but they should maybe pick an easier subject.
And really, I do not think you know what you're talking about when you dismiss functional programming. Maybe you haven't worked on projects big enough to understand the need for abstraction? ... Sure, Haskell and Scheme are not the world's most practical programming languages, but techniques from functional programming are invaluable, and they can help you write clear, effective code even in C.
>>106
To tell you the truth, I'm not terribly sure what's a better idea - to start from a more theoretical point of view then build downwards or to start with a more low-level point of view then build upwards.
However, I wouldn't call Python simple for a few reasons; I'd rather start with JavaScript.
I dismiss functional programming for the one single reason that it is not practical. It doesn't matter how mathematically elegant it is, if you can't use it to write real-world code it's just theoretical wanking. But let's not start up that discussion again - look through some of the older threads for more on that.
>>110
Though it wouldn't be a bad idea to teach it. It's a bit of an enlightening experience, and you can use some functional constructs in real world, practical, down-to-Earth multiparadigm langauges such as Python or Ruby.
Then wouldn't it be better to teach how to use those constructs in those languages? A lot of students I know don't get enlightened from learning a functional language, they get annoyed, and will want nothing to do with those afterwards.
There's nothing inherently impractical about functional programming. It's quite possible to write "real-world" code in a functional language just as easily as it is in a procedural one. Or rather, it's just as easy in a language that's mostly functional. Of course it's ridiculous to program in a completely functional way, just as it's ridiculous these days to program in a completely procedural way. There's lots of benefits to programming functionally, as long as you don't adhere to the paradigm beyond all reasonable logic.
But this brings up an important point regarding attempting to teach functional programming: There's no reason to use a language like scheme or haskell if all you want to do is teach a paradigm; you can program functionally in python or perl too. Maybe not to as great a degree, but much more than one might expect.
On the flip side of that coin, though, is the fact that so-called functional languages like lisp don't adhere you to a functional paradigm either. You can program procedurally in lisp if you want; actually, you can pretty much do anything you want in lisp. That's one of its perks. Moreover, there's plenty of real-world code written in common lisp, and enough libraries and support that it's just as easy to write actual code in lisp as it is in perl or any other language, for the most part. So as far as functional programming goes, if you're concerned about practicality then you're thinking about the issue in the wrong way.
No, I agree entirely that functional programming methods are useful in languages that aren't purely functional. It's just the purely functional languages that I can't stand, because they elevate dogma above everything else.
C++ is the way to go in 99% of all real world applications. Learning script languages isn't nearly as useful.
If by "real world applications" you mean "GUI apps under Windows", sure. But that's hardly all real world apps.
>>115
Has never been a sysadmin.
C++ really is a pretty bad language. It's so big that people normally learn a subset of the language and program in that. Which can work great, until you try to collaborate with other programmers, and they use a different subset. I won't deny that C++ is useful, but the situations where you need it are becoming less and less, and I think that's a good thing.
>>115
Eh, what? A good number of my real world applications are indeed written in C++, but I'm also running lots of low-level software written in plain C, and lots of high-level scripts and applications written in PHP, Python, Perl, and ugh Java.
>>115
moar liek 30% amirite? i speculate that 30% is taken up by c programs, 20% is taken up by high level scripting/interpreted languages and the other 20% taken up by other compiled languages.
I have no idea what language should be teached, but I definitely know which language should be learned first: one you can start using right away, where you can experience your first successes one hour after starting fooling around, where experimenting with stuff is easy.
That means:
Obvious candidates are Python and Ruby, and both have the added advantage of being used in the real world.
>>115
Definitely, because unlike your time, these CPU are really expensive!
Going only by your description, Visual Basic really is a much better choice than either of those.
Compiled languages don't necessarily constitute not being able to learn quickly and be able to reach success within an hour.
For example, QBasic is a compiled language, yet, IMO, easier to gain quick success than Python or Ruby.
>QBasic is a compiled language
But QBasic progs could only be run from inside the QBasic IDE, no? I don't think this truly counts as compilation, in the sense that it doesn't build a stand-alone application.
>>122
I think there's too much magic involved in those visual languages for a beginner to feel that he makes things happen, to understand what is going on.
>>123
I shouldn't have said "no compilation", more that it's important that the process is no more complicated than write and run - no setup before, no waiting after.
>>124
QuickBasic can compile. They're probably thinking of that.
I was of course not seriously suggesting Visual Basic, I just wanted to see what argument you would use against it.
You did say "As high-level language as possible". But then you dismiss Visual Basic as too magic. But isn't all high-level constructs magic? Are you sure you don't mean "suitably high-level", in that case?
"I'm against Visual Basic, now I just need some arguments against it for every practical purpose"
>>127
Yes, I should have stated my idea without big words. Basically, I think that for a beginner, it's important to feel in control.
I think that when you run a small script that writes something to a terminal, you feel more in control than you'd feel displaying it in a window using a visual language and its impressive IDE. (even if a lot is involved in displaying stuff to a terminal - it's purely on the psychological level)
Of course, I'm not arguing that using a GUI is a problem, only that keeping things simple is good because the learner feels in control.
But of course the best argument against VB is that it's a bad language that will teach you bad habits.
Picking up a language when you really need it is easy once you can already code, so I think that for a first language quality is more important than real-world usage, and choosing as a first a good language that is also used in the real world is better since mastering it will be a good investment.
My opinion is to remove the barriers to entry and needless frustrations. As I said in >>121, it's not that good an argument for what language should be teached, but I think it makes sense for which language somebody should decide to learn first: making the experience painless keeps you motivated.
>>128 i'm support vb but in back i hate them
I am this close to issuing one of our very, very rare bans for you.
Not only do you post shit in every thread, start new useless shitty threads, but now you are impersonating other posters.
Stop it NOW, or face the consequences. Understand?
>>102
I can make my argument well enough without your strawmen, thank you very much.
My point was that pointers, though much maligned in this limpy-wristed era of Java and oodles of other heavy leather mittens languages, aren't that hard to teach given an audience that is acquainted with something like MIPS assembly. In fact to someone who knows what a memory address is, a pointer is just a hint for the compiler to produce code that offsets the pointer in a type-specific way. Consider that many universities teach assembly to EE/CS students before they go into higher-level languages.
It's not that I don't see the utility of having a language like Python. But teaching something like that to a student without making clear what the correlation between machine instructions and programming language constructs is only serves to produce a class of people who prefer to think of e.g. compilers as magic and consider the use of a debugger something that only gurus have the skills to do; if it didn't work when they typed it out from the Great Big Cookbook of Black Magic then it's never going to.
What's the better way to teach someone to program computers effectively, then? Top-down, where you tell him that references are magical and exceptions Just Happen and generators are deep magic for when you grow up (close your eyes and think of England, and don't have too much fun because God is watching)? Or bottom-up, by letting the students figure the hows, whys and whats of abstraction out for themselves (or not, in which case there's always a market for COBOL grinders...)?
This all reminds me about a post on some forgotten message board about a young programmer who wanted to get into x86 assembly but was concerned that he might permanently fuck up his computer by accident. He explained that he had read somewhere that this could happen if one wasn't careful. Perhaps something like this is going on with pointers, today? "Ooh eek it's scary, it's frightening, it's something that Sun says is evil and outdated and hello, 1994 calling, they'd like their pointers back!".
(And sorry about the necropost.)
> aren't that hard to teach given an audience that is acquainted with something like MIPS assembly
Which implies that they learned MIPS assembly earlier. That conflicts a bit with teaching C as a first language.
> Consider that many universities teach assembly to EE/CS students before they go into higher-level languages.
EE? I wouldn't be surprised. For what they do assembly is already a fairly high level.
CS? I'm not familiar with any university teaching assembly first.
> He explained that he had read somewhere that this could happen if one wasn't careful.
With good reason, I'd say. I don't recall MASM and TASM coming with libraries, which left you with several hazardous options.
So you want to write to files, do you? cue evil laughter
> > He explained that he had read somewhere that this could happen if one wasn't careful.
> With good reason, I'd say. I don't recall MASM and TASM coming with libraries, which left you with several hazardous options.
> So you want to write to files, do you? cue evil laughter
it's still nearly impossible to permanently fuck up a computer with software. and in those rare cases where it is possible, it's usually because of a hardware bug.
Well, there was the legendary destruction of monitors. In 1994 there were probably still a few vulnerable ones floating around. Having said that, yes, you're right.
My main worry when fooling with assembly was destroying my data. Fortunately it never happened, although I did end up with a non-booting machine several times.
C, just the cross-compatible stuff...If they learn BASIC first, they won't go back, I'd know...
Two problems here. At least.
1st. Students shouldn't be buried. It's inefficient & demoralizes 'em. This implies smallish lang, smallish ref doc, good tools, eg an IDE. Rules out trad bare editors for command line save/compile/debug/edit... cycle. The Stockholm syndrome may demand we make 'em suffer, but computing is too important for us to indulge.
2nd The lang chosen should not teach bad habits. EWD has a real point. LISP's littered with parens, APL is a terseness too far, & Forth requires simultaneous concern w/ contents of the stack & much higher level issues like getting correct information to (or from) disk. Java is so careful it's a feather pillow -- you're buried in fluff, teaching newbies bad expectations. Ditto many of the special purpose languages, eg for Web work. C's syntax is ad hoc and confusing (so's PERL), and pointer artihmetic (as in C) is a bug farm. C was built for a group who used it were the intellectual peers of Thompson and Ritchie. Few of us are, and no students can be expected to be.
3rd Don't force teachers to reinvent wheels, eg first class teaching materials. They should already be available. Algorithms are a central issue in coding, and part of teaching a first lang should be an appreciation of algorithm design and evaluation. The lang should'nt be so difficult algorithm structures and mechanisms are obscured.
MUMPS, PILOT, LOGO, are all small, but too special purpose or too unusual. APL, Prolog, Simula are too far from the mainstream to carry over much to actual problems. C++, Ada, PL/1, Smalltalk, and Java are too large for a first lang. Intercal, and other Retro-Computing Museum wierdies are only for the self-masochistic; sort of like COBOL and Fortran. Maybe as comic relief? The functional langs (and partial ones like LISP) are too exotic for a first lang, even if they are theoretically cool. Assemblers (for any CPU) are too detailed to be even partially plausible. Even MIX. One of the BASICs might be adequate (I think not VB in any form), but they tend to have some specialized feature that's been over stressed and so aren't very general purpose.
I'd suggest Modula-2. There's a truly superb text, by KN King, in print and in use for a very long time. A very large point in most teaching situations. It's a small lang (the Modula-2 Report is slim, was specified in BNF (a chance for some teaching about lesing/parsing), and has no obscure syntax like C's operators. Obfuscated code is next to impossible; students won't acquire bad habits in the Dijkstra EWD498 sense. Yet it has both pass-by-value and pass-by-reference (w/o going thru memory mapping/allocation/deallocation; none needed to make a pedagogic point), and has access to bare hardware if needed to show device register operations. Data types offered are fine to illustrate programming interaction with the gritty reality of underlying bits. Both are good things, in some intro courses and for some purposes. And it has a sort of multi-programming (the coroutine and monitor provisions) which can be a useful entry into teaching a bit about concurrency. This will help introduce processes, threads and such, if needed.
If Modula 2 is not on, perhaps as insufficiently OO, try Oberon (or Oberon 2). Full OO, just not the Java, C++, or Smalltalk way. The Oberon Report is much smaller still, for those concerned. Oberon and its relatives are almost as clear in their code (though a newbie can twist anything into a pretzel). Lots of free versions, and even an entire operating system/lang/utilities collection for Intel as well.
My favorite term-long project is to require students to read Mythical Man Month (Brooks) to inject some reality, and to translate most of the code in Software Tools (1st RatFor edition) into the lang they're learning. Groups work on diff chunks to allow the whole thing to be done in a term. With more care and thought, in two terms. When they're done, or as extra help, I have them implement/compare some of the algorithms in Sedgewick.
You're forgetting one incredibly important thing: Nobody wants to learn something useless. It doesn't matter how educational it is, if you can't make "real" programs in it, people will complain non-stop about having to put in the effort to learn something they can not use later on.
>>139
Yeah, agreed. I was going to post, "But hey, CVSup is written in Modula-2", but it turns out that's Modula-3. (http://www.cvsup.org/faq.html#notc)
>>138
I don't understand your "buried in fluff" complaint. Explain?
Ignoring that one, what about Lua (http://www.lua.org/)? It's simple, approachable, and has real-world use as an embedded scripting language.
>>140
You'd think the garbage collector would take care of all that fluff.
I'm guessing Lua, Python, etc. were covered by "many of the special purpose languages." Is 'sane programming languages don't make the coder deal with memory management' a bad expectation?
I don't think that's a bad expectation. It's important to know how memory management works and many of us in this thread have agreed that C is a good second or third language. However, for first learning to program, one should not have to face the bookkeeping.
>>138
your comment about no student should be expected to be the intellectual peer of someone or other is short sighted. better by far to aim too high and fall short than to aim too low and never advance past success.
the best intellects in the world had to learn once upon a time; you'll never add to the pool if you go around preaching defeat before anyone even starts.
>>139,143
If the goal was introduction into thinking in computer logic, then languages that give the user quick and satisfying results such as logo and squeak and kid's programming language are great. Languages such as Pascal are fine too. If the goal was to teach them to think in terms of computer science level algorithms, then you use a lower level language along the lines of C. If the goal was to teach the person how to become a general purpose programmer, eg. a junior level programmer of a company IT software project, use a higher level language that assists in not wasting the programmer's time by not requiring them to think in low level. Languages such Ruby or C# or Python are great for this.
> it's still nearly impossible to permanently fuck up a computer with software. and in those rare cases where it is possible, it's usually because of a hardware bug.
Unless you are using a BIOS designed by some kind of wacky monkeys, accidentially flashing the BIOS is pretty much impossible.
For me, it depends on what you're teaching: to program, or about programming. In teaching to program, there is a huge class of languages (including C/C++, Java, C#, Python, Ruby, etc.) which offer variations on the same experience (mutable state, strict evaluation, etc., etc.). I'd like to think that my pedagogy will be more important in teaching my students to program than the tools we use.
When teaching about programming, on the other hand, I think that there are significantly fewer options. Depending on the school, many of the students won't have any experience with code that isn't imperative/OO. If you're going to teach about programming (an introduction to PL theory, for example) then you either need an extremely rigourous and flexible language, or you need lots and lots of languages. For me, I'd choose to go with Haskell (though Scheme [witness: SICP, the Reasoned Schemer, etc.] and CL will be able to handle all of the same techniques and content, just with much reduced safety, and Oz is perfect for such an approach [witness: van Roy and Haridi, 2004. Concepts Techniques and Models of Computer Programming.]) for the sole reason of monads. Implementing imperative, OO, non-deterministic, and logic programming yourself really helps get to grips with their intricacies. Furthermore, many students won't have used a language with a strong type system before (no, C/C++, Java, etc. don't count); the main reason people rail against type-checking is that their only experience is of Java's rather pathetic type system. Algebraic data-types, pattern matching, type-classes, and type inference give a much more compelling case for type-checking than anything from the C/C++, Java, etc. world.
To link this back to the original question, I don't see why the first case (teaching to program) and the second (teaching about programming) must necessarily be distinct. I plan to try a "fundamentals" approach to teaching programming (in Haskell) next year if I can get a good set-up and presentation figured out in time.
> I'd like to think that my pedagogy will be more important in teaching my students to program than the tools we use.
To an experienced programmer, switching languages is like switching pants. One easily forgets that this is most definitely not so for a novice programmer, and the particulars of the language are indeed very important.
As for the rest of the argument, I'd opine that functional languages are great for teaching functional programming. For teaching about programming in general, I am pretty sure your first option of using many languages is the only really useful choice.
>>149 DQN is that-a-way ->
Start with C or assembly language to show people how the machine actually works on the lowest level, then show JAVA to see a language on a very high level [good for software engineering concepts], then introduce various popular languages like Python, Perl, etc..
I wouldn't call Java a particularly high-level language...
it wouldn't call you one either
Well, Java does implement a lot of the drawbacks of high-level languages!
In addition to those of low-level language, and some it made up itself.
>>147
Saying that Common Lisp and Scheme can do all that Haskell can do is like saying that PL/I can do everything Lisp can do.
*summons the dead
I like the notion of introducing the concepts of programming first, using languages such as Smalltalk (Squeak), Python, Ruby, Perl, Scheme or what have you. Leave out the complicated low-level stuff at first to get them a general feeling of what it is like to write and think in code. Then you can introduce a 2nd language such as C or C++ to teach them about efficiency and real-world applications, as suggested already, but with a twist: combine both languages.
My idea is this: if you taught them one language, finished it and then started with another, the students might forget about the first ("Hey, we're not using language 1 anymore, time for some garbage-collection of my brain to make space for the new one haha pun."). Like Waha said, learning another language when you only know one is hard, since you don't have the fundamental concepts abstracted and safely stored away in your brain. Since both high-level (1st) und low-level (2nd) languages are useful in the real world, why not complement each other?
Ruby, Python, Perl, Scheme (guile) and other languages have C APIs to hook code into the interpreter. The students could, e.g., learn to optimize certain programs in C while retaining the maintainability or whatever of their high-level programs or how to use external libraries to make the task at hand easier. They don't need to to this all the time, just often enough to understand why knowing the right tool for the job is important.
I know this sounds somewhat abstract, but hey, I'm not a teacher.
if you dont mind a suggestion, it wasnt too long ago i was student myself n i remember the biggest fault when they started to teach was nothing but theory. even if we did code alot, me n most of the ppl in the class started to feel like "whats the point?, sure i can make my puter write hello world 5000times but what use is that to me?". so i was thinking maybe it'd be better to start with a lang that makes it easier to understand the uses, what i'm talking about is webbased langs like php. php is abit lax with variable declarations n such but it is alot like c++ and if your students already have learned html it would be alot easier for them to see the uses of programming.
last point also, dont even try to have them learn oop right off the bat it'd confuse them alot i imagine..
>>157
you were in the wrong class
>>158
Yes, he was. OOP from the beginning? Was your teacher mad?
As for what lang, I'd definitely say Python. It's, as 157 (or Ninereeds, bah) said, a "lang that makes it easier to understand the uses" (it's actually pretty much like php, but even easier to read and code).
My first language was Pascal. I mean, come on! Why would someone teach a language wich has no use? When I moved to C... T_T it got really hard. But, as I see it, Python is even easier to code than Pascal, it has several times its power, is opensource, is multiplataform, is non obligatory oop (not like Java, wich would just be ridicolus to teach to newbies) and can incorporate C. When your students become strong on Python, then you can give them C, C++, a little Java, and PHP, ASP, CGI or what ever application lang you desire. They'll use Python until they die, tho ^^.
There's a couple of great textbooks i'd recommend if you decide to use pithon:
http://www.amazon.com/How-Think-Like-Computer-Scientist/dp/0971677506
That also can be found for online reading at its website,
http://www.ibiblio.org/obp/thinkCS/python/english/
2. Python Programming for the Absolute Beginner, by Michael Dawson
http://www.amazon.com/Python-Programming-Absolute-Beginner-Michael/dp/1592000738
I don't know if there is a online reading site for it, but it's a fantastic adquisition. It might be the fest python book ever, because it's fun to read and all ^^.
What's wrong with Pascal?
Start with teaching them that a programmer's job is to solve problems. Teach em logic and how to think. Then let them code, I'll recommend python for the coding part.
>>160
Sorry if I was a bit harsh with Pascal, but... well, it's hard to apply it on real life. You might find yourself using Object Pascal with Delphi, Kylix (wich is Delphy, after all) or Lazarus, but... well, why would you want to use something like that if you can construct it with a simpler, multiplataform (that is, also in Mac OS) language?
That's why I rather to use Python.
>>161
You certanely are right.
That kind of reasoning only makes sense to someone who can already program and has forgotten that they once did not know how. If you do not know what tools you have or how they work, you can never learn how to solve problems with them.
FIRST you learn to use the tools, THEN you learn how to apply them.
I've never used Delphi, but everyone I know who used it loved it.
Apparently Free Pascal incorporated most of Delphi's features, and it's cross-platform. The binary it produces are quite efficient too.
Getting a job with Pascal, particularly outside of maintenance, is another thing though, which is a bit sad.
I'm a big noob in programming, and actually it's the first time I visit /Programming/ here on 4ch, but what I can say is that playing a little with RPGMaker before knowing anything about programming made it incredibly easier. RPGM is way simpler, there's no comparison, but it introduces you to the computer way of thinking (like with variables).
Plus, you can make games.
warota.
RPG maker is Ruby right? can we call it a toy language now?
>>163
teach them to think and solve problems and they'll teach themselves to rtfm
You're still thinking as someone who already knows how to program. You can't teach someone to "think and solve problems" with just words.
Do you think you can teach a man to paint without him ever touching a brush? Do you think you can teach an architect how to design and build a house without him ever trying to draw one? Do you think you can teach a car mechanic how to repair any car without ever letting him touch a car first?
C, perl and/or shell scripting
Once the student decides on their track, get more specific:
Higher level - C++, Java, OOP, etc.
Web Db - MSSQL, MySQL, Oracle
Web - Perl, PHP, Python (iffy, it's falling out of use), ASP.net, put coldfusion on hold for now. Rails might be on the curriculum in 5 years if it's still alive. Java's a valued skill and javascript is a plus even for the backend programmer to know.
Low level - ASM, C, etc. natch.
Games? Java, OOP, Graphics, graphics with C, ASM, etc. It's a whole subset of programming IMO.
>>168
I'm thinking as someone who taught themselves qbasic at lunchtimes out of an old c64 basic manual and the builtin help because they wanted to learn, not because someone held their hand and made them do exercises.
Nobody made you, but you did by yourself.
How much would you have learned if you hadn't had a basic manual and the builtin help, but instead a book on algorithm design?
>>171
who said anything about books on algorithm design?
>>168
Bah. You can't give him a brush and expect him to paint right away, right? You have to tell him how to move the hand. There's a reason the theory is called "The basics"
I'm replying to the people who say stuff like
> Start with teaching them that a programmer's job is to solve problems. Teach em logic and how to think. Then let them code, I'll recommend python for the coding part.
and
> teach them to think and solve problems and they'll teach themselves to rtfm
here.
python is the bob ross of programming languages
It, uh, it has happy binary trees?
>>176
do not traverse happy binary trees!
by far the best option in my opinion is python, as it is almost as easy as a pseudo-code.
On the contrary, easy is what you want to avoid when teaching people. They have time to become jaded and satisfy their comfort-seeking weakling needs later in their careers (if any).
Therefore assembly is the best language to teach to newbies. Teaching implies guidance, which combined with something supposedly scary like pointers or complete lack of typing besides "byte, word, longword, quadword" will produce a kind of confidence that Java programmers can only dream of. Once "bare to the C library" assembly has been used to study the basic concepts of computer programming, higher-level languages may be taught with the promise of the compiler catching type-safety errors and not having to do function calls and register spills by hand.
Contrast the end product of a survivor of such a course with the sort who's ever been taught "heavy gloves so you don't hurt yourself" languages like Java and (as some in this thread propose) Python. Which one would you rather hire? The old-school guy who's got confidence out the arse, or the scaredy-cat Java grinder who has nightmares about the big bad NullPointerException and who doesn't understand why the garbage collector won't catch his file descriptor leak?
I guess that is why Logo is used to teach kids in elementary school and kindergarten.
As far as your perfect candidate question, I think that I would hire this guy http://norvig.com/21-days.html
Now, he is 'the old school survivor' maybe because there was no Python back then, but with his extensive experience, he is still recommending Python. Just like me ;)
'become jaded and satisfy their comfort-seeking weakling needs later in their careers'
that was a nice try...
whatever!
Hey, I couldn't find pointers, garbage collections, and descriptors leaks in logo http://el.media.mit.edu/Logo-foundation/logo/programming.html
Shell I call them and tell them to change their curriculum. Their kids just wont have any confidence without those things, and won't be able to produce anything good in future.
Hey! Why isn't gravity being thought with Einsteins relativity stuff as well Newton/Leibniz's calculus, but only starts with more trivial examples, like some apple falling on someone's head. All those educators, what were they thinking?
Quit yer mumblin' and provide me with counterarguments.
>>179
Unfortunately, teaching isn't just about imparting knowledge. You also have to maintain the interest of your students. Assembly programming is tedious and unrewarding- new programmers won't care that it's an excellent way to learn the fundamentals and practice basic algorithm design, they want to do something other then screw around in text mode. This is why Logo is considered great for teaching; its easy-as-pie graphic functions make learning the concepts somewhat more exciting for kids.
Try running your assembly super-programming course, but don't be too surprised when 90% of it drops after the first two weeks and re-enrolls in "Making 3D Games in Visual Basic.NET 101."
>>185
signed
Python will be the most obvious answer since it is almost as easy as a pseudo-code. After they learned Python by heart, learning other languages will come naturally.
>>185
I think 90% of people just can't program. The basic concepts come easily to some and are extremely difficult for others to wrap their minds around. I don't claim this to be fact, but it's my experience, and from what I've read, I'm not the only one with that experience.
So, there's something to be said for an interesting and engaging class, true, but there's also something to be said for one that weeds out the people who just aren't cut out to be programmers.
Oh, to make this clear, though, I completely agreed with your first paragraph.
You should learn penuscode first
i think python would be best. make them program something they will use.
Everyone thinks something would be best. I think emacs lisp or LOGO are a good thing to learn first. I also think old micro-basic would be good except it's impossible to get at anymore (unless you use an emulator).
I miss the good ol' days of hacking at Nibbles with QBasic. In DOS.
Qbasic was all right, but wasn't quite as immediate as LOGO or lisp (or even other basics). As a result, I think ipython http://ipython.scipy.org/ would probably be a better choice than Qbasic simply because it's more interactive.
QuickBasic had an immediate mode. The online help was fantastic (F1 any keyword and a up pop cross-linked discussions and examples), and you could stop/resume a program anywhere without changing the source (including on errors), and a host of other goodies.
Not exactly Genera- or Smalltalk-quality, mind, but something most languages implementations nowadays are nowhere near doing. A pity.
I forgot to add you could stop the program and change the source too before resuming. At least in interpreted mode anyway.
QuickBasic's problem is it's long in the tooth and mostly irrelevant.
> The online help was fantastic
Very yes. Very, very yes.
I may have grown to hating Basic dialects with a passion, but I must owe my entire passion of programming to that help.
Although Python does have a help() function in its interpreter, and the REPL encourages experimenting more than QBasic's Immediate pane, it still has much to improve before it's immediately accessible to the newest aspiring hacker.
(Especially Nibbles. Python needs a Nibbles -- with code that's stupidly simple to understand.)
By the way, Pascal was meant to be compact and have a small compiler. Its BNF grammar is about half a page long. It used to be the favorite for compiler design courses. A subset, PL0, has a compiler with source you can read through pretty easily. The author, Wirth, did not intend that you use Pascal for commercial projects. He designed Modula-2 and Oberon for that.
>>45 just as use of variables shouldn't need to be taught in mathematics at a university
...just...just stop. Right now. That wasn't funny.
I'll bet you don't even have a clue what the difference is between variables that express arbitrariness and those that express generality. Arbitrary variables and general variables. And if you want to step into the realm of formal logic, you'll need to further divide up your variables with adjectives like "free" and "bound."
Varibles shouldn't be taught...that's a good one. Perhaps you'll say next that methods of proof don't need to be taught either? Let's just leave mathematical induction to intuition, shall we? Good luck proving complicated proofs that way.
The post you are replying to is three years old.