On 03/01/12 10:09 AM, Liam Proven wrote:
On 3 January 2012 13:57, Toby Thain<toby at
telegraphics.com.au> wrote:
On 03/01/12 7:14 AM, Liam Proven wrote:
On 3 January 2012 04:16, Toby Thain<toby at telegraphics.com.au> wrote:
On 02/01/12 10:00 PM, Mouse wrote:
>>>
>>>
>>> I consider BASIC to be an excellent beginner's introduction to
"what
>>> is a program?", etc., so long as they are exposed to other languages
>>> immediately after grasping the basic principles.
>>
>>
>> Well, there is the "small" problem that BASIC syntax, data types, and
>> control structures relate poorly to modern languages and even less to
>> powerful abstractions.
>
>
>
> I'm not convinced that's a problem.
>
>> What's wrong with Scheme? Or at worst, Python?
>
>
>
> The same thing that was wrong with the New Math: you don't dump the
> full load of theory on a beginner, not unless you want a very confused
> beginner, or you have the incredible luck to get a Ramanujan or Knuth
> as a student (and if so, honestly, the best thing anyone can do is to
> get the hell out of the way).
Scheme has no more theoretical load than BASIC.
O_o So speaketh a *highly* intelligent, perhaps near-genius-level,
natural programmer.
Of course, I meant to qualify this as: "for a beginner", which is the point
here.
Even worse.
There is a core question here which you seem to be skipping over. Do
you want to teach people to write code, to be able to make a computer
perform new tasks? *Or* do you want to train professional software
engineers? These are not at /all/ the same thing. Indeed I'd submit
that they are barely related.
If you want the latter, then sure, yes, Scheme or Lisp or something
Exactly the reverse. Professional software engineers I've seen around
wouldn't touch Lisp with a barge pole. While, for people who want to get
stuff done elegantly and simply, without irrelevancies, Scheme is ideal.
clever and rather arcane. Start 'em on the hard
stuff so they learn
It's not hard stuff (q.v)
right, in the same way that I learned swordfighting
with a foil, the
feeblest weapon but the one controlled by the strictest rules. If you
can fight foil, then you can move to the less-demanding sabre easily,
and the relatively undemanding ep?e is straightforward; but start with
ep?e and learning the formalities of foil will be much harder.
Since modelling and abstraction are far more
important parts of
"programming" than syntax, BASIC fails completely:
- full of irrelevant lexical bullshit and limitations (line numbers? what
good is this to a beginner?);
Oh come off it! Line numbers went out in 1985, man! Don't judge BASIC
by the crappy implementations of the early 1980s when 8K of RAM was a
lot!
Line numbers are not the issue.
- numbers, strings, fixed length arrays?
that's it?
No, not at all. I would expect at least integers, floats, variable
length strings, multidimensional arrays of any other type, and quite
possibly different lengths of integer and possibly signed and unsigned
forms. Possibly booleans and things as well; maybe a complex type. But
to be a programmer does not mandate being a mathematician. I have
taught programming to people who did not know what a percentage was,
who did not know how to multiply or divide by fractions and so on.
Many people do not need fancy types.
How do I build anything
else? Oh right. I can't.
Again, a limitation only of very primitive, early BASICs, although I
have to say, I never found it a limitation. Have user-defined
structured data types if you want, though.
Can I make a list?
- most BASICs lack structured programming
primitives, so even as an
IMPERATIVE language it fails to teach important patterns from the 1980s
(which might explain some of the code I see around the place);
Again, a limitation of the early 1980s. Not true of any decent BASIC
from about 1983 onwards.
- lacks named functions& procedures (yeah,
some BASICs have a crippled
hack for this; see lexical bullshit above)
See above. Have you actually *seen* /any/ even 1990s BASIC, FFS?
- a fundamental
abstracting/factoring tool.
You'll have to explain what that means.
Functions are a fundamental abstracting/factoring tool. So they better
work well. -> Closures, too.
Now with Scheme,
- you start with a syntax that is not pedagogically toxic;
But is incomprehensible
To you...
and uses bizarre postfix notation.
Not Schemes I'm familiar with.
- you have the breath of a hope of constructing
useful data structures
without artificial limitations which can only frustrate;
Straw man.
- there is the opportunity to introduce more
theoretical load, which is
good. The door is always unlocked to go beyond where one already is.
If you can grasp the basics, pardon the pun, which I doubt most could.
There is nothing here that cannot be taught to a
high school age student.
You have no real experience of actual high-school students, then, I
can see that.
Not true; I know some who are learning Scheme and Haskell with no trouble.
I have
only read a tiny little bit about Scheme but it is virtually
impenetrable to me - and I have years of programming experiences,
And that is EXACTLY what Dijkstra was on about.
Oh bollocks!
Q.v. Dylan:
http://en.wikipedia.org/wiki/Dylan_%28programming_language%29#Syntax
Q.v. Lisp 2 and Elephant, discussed here /passim./
Even John McCarthy himself later conceded that Lisp's syntax was a
major hindrance in teaching it.
Oh, yes, people have been trained to be terrified of it. It's a phantom
fear.
The conclusion YOU come to is that Scheme
isn't relevant to programming.
That is not even remotely /like/ the conclusion that I came to. You
are putting words in my mouth and I *object*, strenuously.
I did not say it was not relevant. I did not say it was a bad thing to
start with. I said it was /too hard/ for the average person, and I
stand by that.
But
in fact the opposite is true: A good part of what you have been
indoctrinated with, from BASIC onwards, *obscures* what is really going on
when you program. Programs are not "sequences of instructions" except at the
absolute bottom-most level.
You have no idea of what any BASIC from even 20y ago is like, as you
have demonstrated, and you also seem to be very unfamiliar with the
limitations of actual ordinary people. For nonspecialists, concepts
such as loops are quite hard at first. Iterative thinking has to be
learned. Starting off utter newbies with prefix notation, CAR and
CADR, lists versus atoms, quoting and lambda calculus is like taking
the play-blocks off a kindergarten class and asking them to build the
cathedral of Notre Dame instead.
We do not need *another* generation of
programmers for whom recursion and
higher-order functions are alien concepts. Worse: Not given proper tools,
mental and literal, for modelling and abstraction. Abstraction, it can be
argued, is the single most important idea to learn as a computer programmer.
Actually, I am sure you're right.
But this misses the strength of the old BASICs of the late 1980s and
1990s: that they brought programming to the common man.
Yes, that's true; but it is 2011. And we are preparing kids whose
careers will peak in 2030.
Sure, we need better developers, but we /also/ need easy, friendly,
fun tools to reintroduce the ordinary Joe to writing programs at all.
Python and so on are far too big and complex for this.
I too learned with assembler, BASIC, Pascal, C,
and so on; but I didn't
really learn anything except how to navigate limitations. Ugh. If only I had
picked up Scheme when I picked up C.
So in fact BASIC did /not/ give you brain damage and stop you learning?
C moreso. I should have picked up something I could learn more from.
Actually none of these are more difficult than
the artificial hurdles BASIC
puts in front of you. Once again you speak from your confessed "imperative
place".
You have shown that you don't actually understand how much BASIC moved
on from the crappy MS BASIC 4 days of 1980.
Now imagine that you had learned Scheme first.
Would you say recursion was
hard?
It isn't. I've written recursive programs. In BASIC. In a good BASIC:
in BBC BASIC V, a very fast, 32-bit BASIC with full support for named
procedures, local variables, passing by reference and value and so on.
I'm very very familiar with BBC BASIC. It can't by any stretch be
compared to a Lisp or ML family language, for example.
How will you program effectively in 2030 without
dealing with higher
order functions, continuations, immutable state? (How can one do it today,
for that matter; only because in software Things Move So Damn Slowly.)
I don't, because I am not a programmer and I don't aim to be.
Kids being educated for a career in software
starting today deserve
something better than BASIC. Things are bad enough already.
They deserve something better than a 1970s BASIC, sure... But even a
late 1980s BASIC would, I submit, be more use than Python or Ruby,
which are too big, too complex and too abstract.
And after that, where will they fill in the missing pieces in their
education?
--Toby