Programming languages for the very young
m-coughlin
>
> Joe Marshall <prunes...@comcast.net> wrote in message
> <snip>
> > Certainly there are many computer whizzes that could use a
> > little help with their English, but I think there are as many
> > English majors who would benefit from a computer science
> > course (*not* a computer literacy course, but a real
> > programming course). Writing programs is a great way to
> > learn critical thinking.
>
> As critical thinking is for writing good programs.
>
> Currently my academic recommendation for
> "Introduction to Programming" focuses on a
> single language ... Forth ...; And continues thru
> advanced programming. With Forth as a starting focus
> for learning programming, many directions for opportunities
> in /critical thinking/ are opened simultaneously;
> from the lowest levels of assembler and assembly language
> programming thru the highest levels of problem solving,
> in general, and, more specifically, including structured
> programming, functional programming, object oriented design
> and language compiler design ( ANSI Forth is a nearly ideal
> prototyping tool for language design ).
[snip]
There are many good reasons for using Forth. There is one
overwhelming reason for not using it, especially for new or very
young computer students. There is little useful training
material. There is much information on Forth for computer
hackers -- those people who know a lot about computers already,
can reverse engineer code and remember cryptic abbreviations.
Experts in other languages, such as Scheme, Java, Logo, and even
C and C++, go out of their way to write beginners books and
these can be found easily. The only such books on Forth have to
be ordered online. This was not always the case. Twenty years
ago you could go into a bookstore and find the best book on
programming was "Starting Forth" by Leo Brodie. Nowadays Forth
programmers regret the unavailability of such a book on Forth,
but they do not recognize this as the absolute disaster it is.
Forth is a powerful language that enables individuals to
write and publish their own versions of program development
systems. But these are almost always beta versions needing
documentation. No Forth programmer has ever made a package that
could be used in the lower grades to teach children or even (a
much harder job) to teach elementary school teachers something
about programming. It could be done, but there is no Forth
programmer who seems to be interested. It would require a
complete change of emphasis, from writing creative code for
machines to writing clear literature for human beings.
--
Michael Coughlin m-cou...@comcast.net Cambridge, MA USA
Julian V. Noble
Well, Mike, there is a problem here, of the chicken/egg variety.
Because major corporations push C, C++, C#, Java, etc. there are
publishers willing to risk publishing introductory texts for
those languages (as well as others favored by the academic community,
such as Python, Perl, et al.).
But Prentice-Hall did not keep "Starting Forth" or "Thinking Forth"
in print, despite the demonstrated excellence of both books as well
as pretty good sales.
Kelly & Spies's book, "Forth: a text and reference" was also around
for a while, but CS departments showed little interest in giving
courses in Forth. At this U., we had some engineering courses that
referenced Forth, a course in instrumentation taught by Kelly (for
a while), and a course in numerical methods where I used Forth in
front of my classes (admittedly with a FORTRAN-ish front end) so
I could compose programs, debug them, and run them, before the stu-
dents' very eyes. I could not insist that they do their HW in Forth,
however, since it wasn't taught as a language. In fact I had to learn
some C so I could understand and grade their HW. Only a few of the
many students who took PHYS 551 (and saw me do amazing things in
front of the class in real time) took the time to try Forth. The
attitude of the CS department was, shall we say, not conducive
to motivating the average student to learn such an off-beat language.
MIT is a wonderful place--it must be to offer a course in Structure
and Interpretation of Computer Programs, using the book by Abelson &
Sussman, with Scheme as the illustration language. (I am pleased to
see that my alma mater, Caltech, offers a similar course.) Most CS
intro courses in the US employ C or C++, although some use Java and a
few diehards still feature Pascal. AFIK none use Basic, and even
fewer use Forth.
So how is a publisher to find a market for intro course materials
in Forth? Perhaps if some organization pushed it a bit ...
Actually, the tutorials available on the Web, including (blush)
my own, are perfectly adequate to teach an intro course. And
they are free. What one lacks is a coherent set of exercises
and problems. Someone --perhaps someone who wants to see a course
taught-- should write a set of exercises. I leave the task of doing
so as an, ahem, exercise. ;-)
--
Julian V. Noble
Professor Emeritus of Physics
j...@lessspamformother.virginia.edu
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/
"God is not willing to do everything and thereby take away
our free will and that share of glory that rightfully belongs
to us." -- N. Machiavelli, "The Prince".
Yoyoma_2
our apple IIe's in second grade. I know i do.
A small extension to basic is Visual Basic. It is a very simple
language but it will allow young poeple to develop meaningfull windows
application easily.
Its also a "usefull" language in the sense that it is used somewhat in
the development world.
So my vote is something like LOGO for the very young (maby until like
grade 3 or 4) then VB until 11th grade then dwell in c++ or java since
they have the cognitive abilities to do the complex desings needed for
those languages.
Anyway i'me not a psycologist but its just for my own experience growing
up in the internet age.
Feuer
Yoyoma_2 wrote:
> So my vote is something like LOGO for the very young (maby until like
> grade 3 or 4) then VB until 11th grade then dwell in c++ or java since
> they have the cognitive abilities to do the complex desings needed for
> those languages.
Ugh. Logo's OK, but VB? C++? Java? No. Some Schemish language
seems best for children K-12, with some branching out into assembly,
C, Postscript, and/or ML.
David
Yoyoma_2
When i said C++ and java i meant for 11th grade, at 16 years old i
hardly consider them "children". Since by 12th grade they already start
working on there job skills.
VB is an easy language that kids can learn. Its not much harder than
BASIC which we all did as kids. Of course you won't have them doing ADO
database programming or something, but it could be nice to ex: make a
calculator or something.
>
> David
John Doty
<j...@nowhere.virginia.edu> wrote:
> Only a few of the many students who took PHYS 551 (and saw me do amazing
> things in front of the class in real time) took the time to try Forth.
> The attitude of the CS department was, shall we say, not conducive to
> motivating the average student to learn such an off-beat language.
Logo might actually be a better choice here. You can do "amazing things in
real time" with it, but it's better insulated from the messy hardware
details than Forth is. If you're concentrating on teaching the physics
rather than the operation of the machine, I'd go with Logo.
It's a real shame that Logo is seen as a language that's only for the very
young. While it may be the easiest language to get started in, it's a
pretty sophisticated language, interactive and good at encouraging
well-factored code.
As for other languages, there's no excuse for ever teaching something as
crude and backward as BASIC in K-12 or university. Perhaps VB is
appropriate in a trade school.
I think C is essential at some point: it's the lingua franca of compiled
languages. You don't have to like it, but you ought to know it.
C++ is absolutely the worst choice for introducing students to OO. They
don't get it. The complex frills of the language completely hide the
simplicity of the OO concept. Objective-C is much better: a minimalist OO
extension of C that reveals enough of the underlying machinery for
clarity, yet does not tangle the programmer in it.
So, if I were king, here would be my decree:
Teach Logo in elementary school. Continue to *use* it as a tool in
subjects that require computation through high school and university.
Teach Forth in middle school. The purpose is to teach how the hardware
works. Let 'em make robots flail around. Continue to *use* it as a tool in
electronics classes.
Teach C in high school. Gotta have it. With a Forth background, C makes a
lot more sense, because the kids will understand how computer memory
works. The biggest difficulty students have in learning C is understanding
what it is that a pointer actually does.
Teach Objective-C to high school honors students and university students.
Introduce OO without excess baggage.
Finally, close the circle with Lisp. Logo was, after all, an offshoot of
Lisp. After teaching them programming, you teach them to think about
programming.
You don't need to teach anything else. Any student who's been through this
mill should be able to easily pick up additional languages, from assembly
to Mathematica.
--
| John Doty "You can't confuse me, that's my job."
| Home: j...@w-d.org
| Work: j...@space.mit.edu
Jerry Petrey
John Doty wrote:
>
> Logo might actually be a better choice here. You can do "amazing things in
> real time" with it, but it's better insulated from the messy hardware
> details than Forth is. If you're concentrating on teaching the physics
> rather than the operation of the machine, I'd go with Logo.
>
> It's a real shame that Logo is seen as a language that's only for the very
> young. While it may be the easiest language to get started in, it's a
> pretty sophisticated language, interactive and good at encouraging
> well-factored code.
>
>
I would certainly agree with you on Logo. It is a great language for kids (or
even adults). I used to teach some introductory computer classes to kids in
the 8 - 11 years old range using Logo and they loved it and caught on fast.
Read the language inventor's fantastic book "Mindstorms" (by Seymour Papert)
for a fascinating analysis of computers in education, Logo, and the child
learning process.
Jerry
--
---------------------------------------------------------------------------------
-- Jerry Petrey
-- Senior Principal Systems Engineer - Navigation (GPS/INS), Guidance, &
Control
-- Raytheon Missile Systems - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to reply
---------------------------------------------------------------------------------
m-coughlin
>
> John Doty wrote:
> >
> > Logo might actually be a better choice here. You can do "amazing
> > things in real time" with it, but it's better insulated from the
> > messy hardware details than Forth is. If you're concentrating on
> > teaching the physics rather than the operation of the machine,
> > I'd go with Logo.
> >
> > It's a real shame that Logo is seen as a language that's only for
> > the very young. While it may be the easiest language to get
> > started in, it's a pretty sophisticated language, interactive and
> > good at encouraging well-factored code.
> >
>
> I would certainly agree with you on Logo. It is a great language
> for kids (or even adults). I used to teach some introductory
> computer classes to kids in the 8 - 11 years old range using Logo
> and they loved it and caught on fast. Read the language inventor's
> fantastic book "Mindstorms" (by Seymour Papert) for a fascinating
> analysis of computers in education, Logo, and the child learning
> process.
Here's an important point that gets overlooked. The inventor
of Logo wrote a textbook. The inventors of C wrote a textbook so
influential it is just known as " K&R ". The inventor of Forth
never wrote a textbook. Its a difficult handicap to overcome.
A friend, who has a terrible time coping with computers,
just asked me what programming language she should learn to try
to overcome her handicap. I told her to go to the library and
find a book on Logo. I'd rather advise her to study Forth, but
there is nothing she can buy today about Forth that would meet
her needs.
m-coughlin
>
> Prefix, infix or postfix ... Prefix, infix or postfix ...
>
> Feuer <fe...@his.com> wrote in message news:
> <40160648...@his.com>...
I remember learning arithmetic as a child. We started out
having to memorize 1 + 1= 2 all the way up to 12 + 12 = 24.
Then to work with bigger numbers, we changed things around
1
+ 1
__
2
12
+ 12
___
24
and we wrote the + last. Didn't give me much trouble then, not
after memorizing the whole addition and multiplication tables.
So I don't know why there is so much anguish about infix and
postfix notation with programming languages. Must be due to the
brain changing with maturity.
Darin Johnson
> I would certainly agree with you on Logo. It is a great language for kids (or
> even adults). I used to teach some introductory computer classes to kids in
> the 8 - 11 years old range using Logo and they loved it and caught on fast.
The turtle graphics part should be great, even for older learners of
programming. When I first learned in college, and later proctored in
the lab for others, we had turtle graphics, and I think it really
helped. At the very least it gets away from the same old boring
beginner programs where one computes arithmetic or writes a "Hello, my
name is $name" sorts of stuff.
It's simple enough that you can do complicated graphics with very
little work, and without knowing more advanced techniques. You can
also quickly see the results of what's going on, and relate what is
seen with what was written in the program. Ie, I think students learn
what recursion better by drawing factorial curves than by computing
factorials.
Another interesting system for kids might be Lego Mindstorms. It uses
a graphical programming environment (ie, drag blocks around as opposed
to writing code). It might not be good for the "very young" though,
probably better for pre-teen and up. Someone did report though that
their child just wanted to build stuff with the Legos and wasn't
interested in the programming part.
--
Darin Johnson
Support your right to own gnus.
John Doty
<darin_@_usa_._net> wrote:
> The turtle graphics part should be great, even for older learners of
> programming.
Indeed. The key thing is the primitives: turn, move, penup, pendown. This
allows you to build an analytic geometry without a Cartesian grid, better
connected to Euclid's concepts, non-Euclidean geometry, and relativity. Of
course, you could do this in other programming languages as well. You
don't even need a computer (although a computer is certainly useful).
Abelson and DiSessa's "Turtle Geometry" was a wonderful high school
analytic geometry text based on these ideas. By the end of the book, they
had introduced differential geometry without using calculus, and had even
covered a bit of General Relativity. I read it about 20 years ago. There
was fundamentally nothing in there that someone (like me) who's plowed
through Misner, Thorne, and Wheeler's tome wouldn't know, but the approach
was refreshingly simple: I learned a new way to think about geometry from
the book.
Unfortunately, with the current emphasis on indoctrinating students to
score on standardized tests, there is no way such a nonstandard
presentation of geometry could be taught in most high schools.
Yoyoma_2
I agree LOGO is a great language for the very, very young. But as soon
as they get in 7th or 8th grade they will get very bored of it quick. I
wonder why everyone discounts teaching VB. SIMPLE VB can be lots of
fun, its basically BASIC (you can still do print on a form you know :) )
and at least the students can work to a real windows application.
Its not as if kids can't understand to do VB since its so similar and
compatible to BASIC, which we know they understand. Plus at least it
will give them SOME work experience with a programming language.
I still say teaching VB is a good tool for pre-teens and teenagers. But
i also agree that C should be tought around 11th grade or so. to
"graduate" them to a real programming language.
My 0.02 $ CAD :)
Hrvoje Blazevic
>
> I agree LOGO is a great language for the very, very young. But as soon
> as they get in 7th or 8th grade they will get very bored of it quick.
This tells me that you do not really know Logo, so before voicing
opinions like this again, maybe you should check Berkeley Logo and Brian
Harvey's Computer Science Logo Style (downloadable at:
http://http.cs.berkeley.edu/~bh/v1-toc2.html).
-- Hrvoje
m-coughlin
"Julian V. Noble" wrote:
[snip]
> Well, Mike, there is a problem here, of the chicken/egg variety.
> Because major corporations push C, C++, C#, Java, etc. there are
> publishers willing to risk publishing introductory texts for
> those languages (as well as others favored by the academic
> community, such as Python, Perl, et al.).
>
> But Prentice-Hall did not keep "Starting Forth" or "Thinking Forth"
> in print, despite the demonstrated excellence of both books as well
> as pretty good sales.
>
> Kelly & Spies's book, "Forth: a text and reference" was also around
> for a while, but CS departments showed little interest in giving
> courses in Forth.
Forth is not used for CS department applications. I saw
Forth graphically solving the towers of Hanoi and a random
generated maze on the Apple II. I never saw a computer science
paper on how to use Forth to solve these problems, even tho they
are taught in computer science classes.
Physics departments are not always the best places to
learn about practical engineering methods. CS departments are
not always the best places to learn about practical applications
of computers. Scientific computing was taught at Harvard, not in
the CS department, or the math department, but in the astronomy
department. The book "Numerical Recipes in Fortran" came out of
that effort. Computer science is an incomplete field that still
needs to take ideas from many places. It is not a subject like
arithmetic where the basic ideas have been known and tested for centuries.
Computer books are constantly going out of date. They
always have to be revised to keep up with all the changes,
especially ones inspired by better computer books. "Starting
Forth" or "Thinking Forth" will not sell if they are not
revised. I personally would rather have the first edition of
"Starting Forth" kept in print and the ANS-Forth standard become
unavailable, but that would only be the lesser of two evils. The
use of Forth should have inspired people to write more textbooks
instead of less.
> At this U., we had some engineering courses that
> referenced Forth, a course in instrumentation taught by Kelly (for
> a while), and a course in numerical methods where I used Forth in
> front of my classes (admittedly with a FORTRAN-ish front end) so
> I could compose programs, debug them, and run them, before the
> students' very eyes. I could not insist that they do their HW in
> Forth, however, since it wasn't taught as a language. In fact I had
> to learn some C so I could understand and grade their HW. Only a
> few of the many students who took PHYS 551 (and saw me do
> amazing things in front of the class in real time) took the time to
> try Forth.
> The attitude of the CS department was, shall we say, not
> conducive to motivating the average student to learn such an
> off-beat language.
Every computer language is an off-beat way to compute. Ask
mathematicians. They can still do their work without paying much
attention to computer languages. Julian Noble, your course is in
physics, "Methods of Computational Physics". You have to teach
what physicists use to program computers, which is first Fortran
and C, then everything else. In spite of your efforts over many
years, very few physicists use Forth in their work. It is not
good to show computer programming by magic. Physics can't be
done by magic. Everything has to be done with mathematical logic
and precise experiments. It takes a long time to learn; it has
taken a long time to develop the course of study. Computer
programming can't be done by magic either, and it takes the same
effort as physics to teach and learn.
Why should Forth be an "off-beat" language? I think it is
because it has the power to do magic but its users don't fully
realize that is a bad thing.
> MIT is a wonderful place--it must be to offer a course in Structure
> and Interpretation of Computer Programs, using the book by
> Abelson & Sussman, with Scheme as the illustration language.
> (I am pleased to see that my alma mater, Caltech, offers a similar
> course.) Most CS intro courses in the US employ C or C++, although
> some use Java and a few diehards still feature Pascal. AFIK none
> use Basic, and even fewer use Forth.
John McCarthy, while a professor at MIT, started the use of
Lisp and its decedents without a book like Abelson & Sussman and
not as something to teach first year students. The first book on
Lisp I saw at the MIT bookstore was called "The Little Lisper".
It was very simple; hardly fit for a prestigious academic
institution. MIT is a wonderful place because there are so many
people working there to make Lisp and Scheme possible to learn.
The Abelson & Sussman book is online, beautifully typeset, for
everybody to read at http://mitpress.mit.edu/sicp/full-text/book/book.html
A quote from chapter 1,
"Lisp was not the product of a concerted design effort. Instead,
it evolved informally in an experimental manner in response to
users' needs and to pragmatic implementation considerations."
It is bit strange that something as cryptic as Lisp and
Scheme has so much work done to make it accessible, but that is
what it takes. Stranger yet is that something much easier to
understand, like Forth, attracts much less attention in that department.
> So how is a publisher to find a market for intro course materials
> in Forth? Perhaps if some organization pushed it a bit ...
Organization? Publisher? Market? What do these have to do
with computer languages? Publishers don't create markets for
ideas in computing. We don't need a corporate organizations like
IBM to create Fortran and Cobol anymore. Introductory course
materials are created by teachers. Some languages are created by
college professors, like Lisp, Scheme, Pascal and even Basic.
Some languages are created by researchers in industry, like C
and Java. It doesn't make much difference who or where an idea
comes from, its what happens afterward that counts.
> Actually, the tutorials available on the Web, including (blush)
> my own, are perfectly adequate to teach an intro course. And
> they are free. What one lacks is a coherent set of exercises
> and problems. Someone --perhaps someone who wants to see
> a course taught-- should write a set of exercises. I leave the
> task of doing so as an, ahem, exercise. ;-)
Yes, there are nice tutorials for Forth on the web. But by
the time anybody knows how to surf the web they also know C and
Java are computer languages to be learned and things like Scheme
and Forth are safe to ignore. It would be interesting if
computer students could find out about Lisp/Scheme/Logo or Forth
when they first thought about learning programming.
Darin Johnson
> I wonder why everyone discounts teaching VB. SIMPLE VB can be
> lots of fun, its basically BASIC (you can still do print on a form you
> know :) ) and at least the students can work to a real windows
> application.
I've only used VB once, and used it at the same time I used Delphi.
I was distinctly unimpressed, since Delphi did everything better
in all apsects, and had a better underlying language.
BASIC can, and still does, ruin a lot of programming potential. Even
advanced BASICs with structured control constructs still teach bad
programming advice. A student really needs to learn that programs are
structured, have rules, and have styles. I spend a few years teaching
introduction to programming in Pascal, and the students who had
already spent a few years on BASIC inevitably had the hardest time
unlearning their "just scribble something down" habits.
--
Darin Johnson
I'm not a well adjusted person, but I play one on the net.
Ray Dillinger
> BASIC can, and still does, ruin a lot of programming potential. Even
> advanced BASICs with structured control constructs still teach bad
> programming advice. A student really needs to learn that programs are
> structured, have rules, and have styles. I spend a few years teaching
> introduction to programming in Pascal, and the students who had
> already spent a few years on BASIC inevitably had the hardest time
> unlearning their "just scribble something down" habits.
>
Would you say that using machine code directly teaches poor programming
practices? It has most of the same problems as BASIC: it does not force
anyone to use any structure, has no enforcement of any particular style,
and lends itself even more easily than BASIC to egregiously hacky things
like punning on the bit patterns of constants and/or instructions. It
has goto, and conditional goto, but no such thing as, say, subroutine
abstraction.
Before you tell me that assembly has subroutine calls, note that I am
talking about machine code here; I know that there are assemblers which
package up subroutine patterns as macros, but I'm not talking about a
macro assembler language, I'm talking about machine code, or equivalently
a non-macro assembler.
I would say that the unstructuredness of machine code teaches people the
value of consciously imposing plan, structure, and design on a program
rather than relying on the language to do it for them, and thus makes
them *better* programmers.
And while I agree that BASIC is sort of an annoying and pathetically limited
language, I don't see a qualitative difference in what it teaches.
Bear
Darin Johnson
> Would you say that using machine code directly teaches poor programming
> practices? It has most of the same problems as BASIC: it does not force
> anyone to use any structure, has no enforcement of any particular style,
> and lends itself even more easily than BASIC to egregiously hacky things
> like punning on the bit patterns of constants and/or instructions.
Most people learn a higher level programming first, then start with
assembler later. So it's usually not a problem.
However, I did have a boss once who had learned IBM mainframe
assembler as his first and only language for ages. Then he learned
from a "learn C in X days" book. His code was by far the most
atrocious I'd ever seen (such as using strncmp to compare two
characters).
> It
> has goto, and conditional goto, but no such thing as, say, subroutine
> abstraction.
Once you learn about high level programming languages, the subroutine
abstraction is easy to create in assembler. It's not built in, but
knowing to create a proper frame and use the stack for arguments and
temporaries results in much cleaner and more maintainable code than
the person who uses globals or registers for everything.
Which brings up the facet of programming that should be emphasized the
most: maintenance. Almost all programmers spend almost all of their
programming time in maintenance. Ie, fixing up and modifying old
programs. Very often (most of the time?) this includes programs
written by other people. Even throw away use-once programs often get
recycled and develop a life of their own. Thus, being able to write
maintainable programs is an invaluable skill, while writing
unmaintainable messes is an anti-social trait.
> I would say that the unstructuredness of machine code teaches people the
> value of consciously imposing plan, structure, and design on a program
> rather than relying on the language to do it for them, and thus makes
> them *better* programmers.
But do such people learn to program in machine code _first_ and
magically develop higher level plans and structures, or do they borrow
those ideas from languages they learned elsewhere? With a good
teacher, perhaps I could see this skill forming in a person who knew
nothing but assembler, but on their own I doubt any good programming
skills will develop in a vacuum.
> And while I agree that BASIC is sort of an annoying and pathetically limited
> language, I don't see a qualitative difference in what it teaches.
Perhaps what makes the qualitative difference is that most people
learn on their own, with minimal helps perhaps from a harried teacher
or poorly written textbook. Thus the language that encourages good
style while writing small beginner programs will tend to naturally
create better programmers in the long run.
--
Darin Johnson
Laziness is the father of invention
John Doty
<Yoyoma_2@[at-]hotmail.com> wrote:
> John Doty wrote:
No, I didn't write that, you did!
>
> I agree LOGO is a great language for the very, very young. But as soon
> as they get in 7th or 8th grade they will get very bored of it quick.
Do you actually know Logo? It's a powerful, sophisticated language. If you
give 8th graders 4th grade exercises they'll get bored, sure. But give
them appropriate material, and Logo is great.
> I
> wonder why everyone discounts teaching VB.
Maybe because it's a crude, crummy language that encourages sloppy
programming?
Michael D. Ober
"Ray Dillinger" <be...@sonic.net> wrote in message
news:4018234F...@sonic.net...
> abstraction.
>
> Before you tell me that assembly has subroutine calls, note that I am
> talking about machine code here; I know that there are assemblers which
> package up subroutine patterns as macros, but I'm not talking about a
> macro assembler language, I'm talking about machine code, or equivalently
> a non-macro assembler.
>
have machine level SUB and RET instructions. These are the two instructions
required for subroutines. Yes, some assemblers allow you to put the
registers on the SUB call line and the assembler packages the sub for you,
but the underlying stack and register manipulations are done via a hardware
level instruction pair - one to create a new stack frame and one to unroll
it.
As for VB 6, it has a lot of high level memory management features that C
and C++ can't touch. You never have to deal with a pointer except when
referencing Windows API functions that call for a pointer to a buffer. You
also don't have to deal with memory leaks and uninitialized memory on the
heap. You can event force the compiler to require variable declarations
(but not types, unfortunately).
You can write garbage in any language - you can also write maintainable code
in any language. You just have to understand the structure of and how to
implement program design so that the program is maintainable.
Is VB the best language to teach programming, probably not. But neither are
C or C++. VB forces some quirky structures simply because it's not truly
object oriented and it allows global variables (I consider them to be the
data storage equivalent of "GOTO"); C++ because you have to spend a lot of
time thinking about memory management (which is ok if that's what you're
trying to learn). From a standpoint of learning how to structure software
for correctness and maintainability, I'd pick CLU as it only readily allows
one major bad habit - putting your control structures too low in the code.
Mike Ober.
CLU, Scheme, FORTH, Intel Assembler, VAX Assembler, IBM BAL (Assembler), C,
C++, VB, Clipper 5.x, Motorola 68xxx Assembler, Pascal
Joe Marshall
> The last time I looked, all processors except the IBM mainframe processors
> have machine level SUB and RET instructions. These are the two instructions
> required for subroutines.
You only need a conditional branch to get subroutines. It's a pain,
but you can do it.
Michael D. Ober
"Joe Marshall" <j...@ccs.neu.edu> wrote in message
news:3c9yep...@ccs.neu.edu...
Actually, BAL does it with unconditional branches. My point was that
subroutines are part of the stack machine model that just about every
processor uses and that processors support them in machine code.
Mike.
Alex McDonald
news:LDtSb.8$kg.1...@news.uswest.net...
>
> "Joe Marshall" <j...@ccs.neu.edu> wrote in message
> news:3c9yep...@ccs.neu.edu...
> > "Michael D. Ober" <obermd-.@.-alum-mit-edu-nospam> writes:
> >
> > > The last time I looked, all processors except the IBM mainframe
> processors
> > > have machine level SUB and RET instructions. These are the two
> instructions
> > > required for subroutines.
> >
> > You only need a conditional branch to get subroutines. It's a pain,
> > but you can do it.
>
> Actually, BAL does it with unconditional branches.
It's not that mainframes don't have SUB- and RET-like instructions; they do.
Co-incidentally, BAL (Basic Assembly Language) has an op-code called BAL. To
clarify;
BAL <reg>, <address>
Next instruction ip placed in <reg>, jump to <address>. It's _not_ a
straight jump. BAL (the opcode) is an acronym for Branch And Link.
BR <reg>
to return. Much more flexible; you've even got a choice of any of 15
registers. But there's no PUSH/POP-like equivalents for parameter passing as
there's no stack. [ Aside: the standard calling convention uses a register
pointer to parameters with doubly linked frames as register save areas. The
conventional call/return sequence is a little more convoluted than this
simple example; normally R14 and R15 are used as a call/return pair, R1 is
the parameter list pointer. ]
It's the lack of stack support instructions in hardware that's different
(although the x86 still requires OS support in addition). Supporting stack
operations on a mainframe is a pretty trivial job, though.
> My point was that
> subroutines are part of the stack machine model that just about every
> processor uses and that processors support them in machine code.
They're part of the stack-less machine model too.
--
Regards
Alex McDonald
Ray Dillinger
Yeah, okay. I'm not using the "native" subroutine instructions, because
Scheme continuations require a non-stack model of call frames. I honestly
thought those were just macros provided by my macro-assembler, but I
guess not. I am using ASM conditional branches to implement subroutine
calls.
Bear
jmdrake
> Here's an important point that gets overlooked. The inventor
> of Logo wrote a textbook. The inventors of C wrote a textbook so
> influential it is just known as " K&R ". The inventor of Forth
> never wrote a textbook. Its a difficult handicap to overcome.
>
> A friend, who has a terrible time coping with computers,
> just asked me what programming language she should learn to try
> to overcome her handicap. I told her to go to the library and
> find a book on Logo. I'd rather advise her to study Forth, but
> there is nothing she can buy today about Forth that would meet
> her needs.
Well the last time I was in the bookstore I didn't see anything
you could "buy" on Logo either. But, just like Logo, you can
find books on Forth at many libraries. Will some of the info
be dated? Sure. Same with the Logo books.
Regards,
John M. Drake
Michael D. Ober
It's been 20 years since I used Scheme, but I vaguely remember that Scheme
doesn't readily lend itself to subroutines. Scheme programs tend to be tail
recursive, making conditional branching the most efficient method for
subroutine calling.
Mike.
Joe Marshall
> It's been 20 years since I used Scheme, but I vaguely remember that Scheme
> doesn't readily lend itself to subroutines. Scheme programs tend to be tail
> recursive, making conditional branching the most efficient method for
> subroutine calling.
Depends on whether the `standard' calling conventions are callee or
caller saves, and whether callee or caller pops.
Yoel Jacobsen
unreadable after you finish with the turtle graphics games.
I'm playing with Forth with my 6 years old boy (Gforth 0.6.2 over
Solaris, 'stty olcuc' to turn everything to capital letters). I exposed
him to the concept of stack and stack manipulation when he was 5. He
grasped that immediately. Now he *enjoy* to *play* with forth.
The total lack of any syntactic form the absolute simplicity, the
immediacy of reward and the short distance from the hardware (!) make
forth,IMHO, a perfect choice for very young children ( - IMO, long
distance from hardware cause Java programmers to create software that
needs 200MB of RAM and a power-hungry CPU just to start).
To make the picture clear, I use C and Python at work and program with
Smalltalk from time to time.
Yoel
Bernd Paysan
> My experience shows that Logo code tend to become ugly and totally
> unreadable after you finish with the turtle graphics games.
When I started programming, I also started with Logo. After the turtle
graphics stuff (the more complicated was a quite "natural" tree drawing
program), I wrote two games: Mastermind and Battleship. At that time, I
didn't feel the code was ugly and unreadable, but I didn't know anything
else. The 4wins code I wrote in Forth almost two decades later is much more
elegant, though. I attribute that to my experience. I'm also quite sure
that I wouldn't have been able to write a alpha-beta-min-max strategy back
when I started with Logo. The game strategy part for Battleship is much
easier (random moves, tracking impossible moves in Battleship), and I
managed to defeat the computer in Battleship by moving all my ships into
the corners of the area, anyway.
What was ugly with the games was the speed of Logo (Speed Logo on Atari ST).
It was sluggish as hell. I turned over to Forth, because Forth was fast,
and close enough to the machine to actually use native OS functions. Logo,
as typically implemented back then, was a useless toy.
> I'm playing with Forth with my 6 years old boy (Gforth 0.6.2 over
> Solaris, 'stty olcuc' to turn everything to capital letters). I exposed
> him to the concept of stack and stack manipulation when he was 5. He
> grasped that immediately. Now he *enjoy* to *play* with forth.
This is a good example that things that are perceived most difficult to
learn are those where you have to unlearn a lot, and that these things come
much easier to persons who haven't learned the other way before. I remember
that my classmates struggled for years with infix notation. It seems to be
that learning infix is like trying to turn your head inside out; but later,
when you have aquired infix, learning postfix (or prefix) again feels the
same way.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
chris
> Yoel Jacobsen wrote:
>
>> My experience shows that Logo code tend to become ugly and totally
>> unreadable after you finish with the turtle graphics games.
>
> When I started programming, I also started with Logo. After the turtle
> graphics stuff (the more complicated was a quite "natural" tree drawing
> program), I wrote two games: Mastermind and Battleship. At that time, I
> didn't feel the code was ugly and unreadable, but I didn't know anything
> else. The 4wins code I wrote in Forth almost two decades later is much
> more elegant, though. I attribute that to my experience. I'm also quite
> sure that I wouldn't have been able to write a alpha-beta-min-max strategy
> back when I started with Logo. The game strategy part for Battleship is
> much easier (random moves, tracking impossible moves in Battleship), and I
> managed to defeat the computer in Battleship by moving all my ships into
> the corners of the area, anyway.
>
> What was ugly with the games was the speed of Logo (Speed Logo on Atari
> ST). It was sluggish as hell. I turned over to Forth, because Forth was
> fast, and close enough to the machine to actually use native OS functions.
> Logo, as typically implemented back then, was a useless toy.
Bernd's involvement with Forth went further than that : he developed
bigForth, a 32-bit for the Atari ST, TT and Falcon. I still have a copy.
Although I started out with infix languages (Basic, Algol, Fortran) and
only encountered stack-based VMs later (STAB, in 1974), when I finally did
meet Forth it was love at first sight. Above all it was during my "Forth
period" that I came to appreciate the value of good factoring, and of
well-defined interfaces and well-defined functionality.
>> I'm playing with Forth with my 6 years old boy (Gforth 0.6.2 over
>> Solaris, 'stty olcuc' to turn everything to capital letters). I exposed
>> him to the concept of stack and stack manipulation when he was 5. He
>> grasped that immediately. Now he *enjoy* to *play* with forth.
>
> This is a good example that things that are perceived most difficult to
> learn are those where you have to unlearn a lot, and that these things
> come much easier to persons who haven't learned the other way before. I
> remember that my classmates struggled for years with infix notation. It
> seems to be that learning infix is like trying to turn your head inside
> out; but later, when you have aquired infix, learning postfix (or prefix)
> again feels the same way.
I encountered STAB because at that time the University of Strathclyde
(where I was a postgrad) used to teach their CS students STAB first,
followed by Algol 68. (I was assisting the practical classes in Algol 68).
Today that would translate to teaching Forth first, followed by Java. Know
what? If I were designing a programming course (with no Board of Studies to
constrain me) I'd probably do just that.
--
Chris Gray ch...@kiffer.eunet.be
/k/ Embedded Java Solutions
Richard
some abomination like Logo?
http://mysite.verizon.net/vze3jmtr/knr_02.jpg (broadband recommended)
--
"Premature optimization is the root of all evil." - Donald Knuth
Yoyoma_2
> My son's taking to C pretty well, so I figure why mess him up with
> some abomination like Logo?
>
> http://mysite.verizon.net/vze3jmtr/knr_02.jpg (broadband recommended)
>
bet he's gonna like having his name glow in leds :-)
I heard that Wozniack, the guy who worked on the apple, one of his first
labs was making a led array animate the atoms for the first 10 elements
(electrons going around in a bohr-like fashion, i don't think he had the
wierd magnetic quantum number ones going like n=3, l=2, ml=+-1)... ALL
IN LED. This is back in the day so i think he might have had to make
his own counters etc :)
Now THAT is a lab :) Honnestly i think i'me gonna try it one day..
Write a program in Verilog that animates a led array. Could be cool :)
Bernd Paysan
> Bernd's involvement with Forth went further than that : he developed
> bigForth, a 32-bit for the Atari ST, TT and Falcon. I still have a copy.
... and later, I ported bigFORTH to Linux and Windows, and wrote Gforth
(together with Anton Ertl and Jens Wilke).
chris
> chris wrote:
>> Bernd's involvement with Forth went further than that : he developed
>> bigForth, a 32-bit for the Atari ST, TT and Falcon. I still have a copy.
>
> ... and later, I ported bigFORTH to Linux and Windows, and wrote Gforth
> (together with Anton Ertl and Jens Wilke).
And Gforth includes vmGen, which is of much wider applicability. So all
this cross-posting is finally justified. :)
m-coughlin
>
> My experience shows that Logo code tend to become ugly and
> totally unreadable after you finish with the turtle graphics games.
My experience is that any computer code becomes ugly and
totally unreadable unless you go to great effort to carefully
comment it. Logo is not usually commented. Forth is not usually
commented. C code is not usually commented either, but C
programmers feel guilty about that.
> I'm playing with Forth with my 6 years old boy (Gforth 0.6.2 over
> Solaris, 'stty olcuc' to turn everything to capital letters). I exposed
> him to the concept of stack and stack manipulation when he was 5.
> He grasped that immediately. Now he *enjoy* to *play* with forth.
Solaris for a six year old? Don't you have to worry about
child abuse? Oh, wait, you are the system administrator. That
makes a big difference.
Have you learned something that you could publish to improve
the instruction of children in the computer field?
> The total lack of any syntactic form the absolute simplicity,
> the immediacy of reward and the short distance from the
> hardware (!) make forth,IMHO, a perfect choice for very young
> children ( - IMO, long distance from hardware cause Java
> programmers to create software that needs 200MB of RAM and
> a power-hungry CPU just to start).
It is worthwhile to start out teaching a few programming
ideas. But there is more to programming than the simple things
you can show a child with Forth (or Scheme, Logo, Java, etc.).
You forget you are using Solaris. Doesn't it also want 200MB of
RAM and a power-hungry CPU? In the days of alphanumeric
displays, Forth was its own operating and development system.
Nowadays it is a captive to massive operating systems written in
C. I can't even use it to avoid knowing anything about MS-Dos. I
should be able to give a complete beginner a book and a disk and
say you don't have to know anything else to learn to program
except Forth. That was the direction Forth was going at one
time, but not now.
The topic of programming languages for the very young has
to include some consideration for teaching teachers. What does
it take for ordinary people to learn to deal with computers?
What does an adult need to know? Is it different than what a
child needs to know? Are Forth programmers going to answer those
questions, or will some other programmers try to solve them?
> To make the picture clear, I use C and Python at work and program
> with Smalltalk from time to time.
>
> Yoel
>
> jmdrake wrote:
> > m-coughlin <m-cou...@comcast.net> wrote in message
> > news:<4016FAF1...@comcast.net>...
> >
> >
> >> Here's an important point that gets overlooked. The inventor
> >>of Logo wrote a textbook. The inventors of C wrote a textbook so
> >>influential it is just known as " K&R ". The inventor of Forth
> >>never wrote a textbook. Its a difficult handicap to overcome.
> >>
> >> A friend, who has a terrible time coping with computers,
> >>just asked me what programming language she should learn to
> >>try to overcome her handicap. I told her to go to the library and
> >>find a book on Logo. I'd rather advise her to study Forth, but
> >>there is nothing she can buy today about Forth that would meet
> >>her needs.
> >
> > Well the last time I was in the bookstore I didn't see anything
> > you could "buy" on Logo either. But, just like Logo, you can
> > find books on Forth at many libraries. Will some of the info
> > be dated? Sure. Same with the Logo books.
Where I live, I can go to a computer book store and buy
Logo books, at least last time I checked. But, of course, I
live in the same town where Logo was invented, and there are
thousands of students here. There are books on Forth in
libraries, but very few. There is material on the web for
learning programming in every computer language, but not for the
complete beginner, just for somebody who can connect to the web.
There are very knowledgeable people still trying to make Logo
easy to learn, both for children and their teachers.
We spend a lot of time debating the technical details of
writing code. But what really counts is what people who write
useful programs learn first.
Paul E. Bennett
m-cou...@comcast.net "m-coughlin" writes:
[%X]
> The topic of programming languages for the very young has
> to include some consideration for teaching teachers. What does
> it take for ordinary people to learn to deal with computers?
> What does an adult need to know? Is it different than what a
> child needs to know? Are Forth programmers going to answer those
> questions, or will some other programmers try to solve them?
It is often worthwhile seeing if you can offer a local school or
two the opportunity to have you go in to present a talk, a few
practical sessions and perhaps a contest at the end of it. This sort
of thing does take some organising and setting up and you end up
educating the teachers at the same time as you educate the youngsters.
[%X]
> Where I live, I can go to a computer book store and buy
> Logo books, at least last time I checked. But, of course, I
> live in the same town where Logo was invented, and there are
> thousands of students here. There are books on Forth in
> libraries, but very few. There is material on the web for
> learning programming in every computer language, but not for the
> complete beginner, just for somebody who can connect to the web.
> There are very knowledgeable people still trying to make Logo
> easy to learn, both for children and their teachers.
>
> We spend a lot of time debating the technical details of
> writing code. But what really counts is what people who write
> useful programs learn first.
It is important to remember that pulling a systems together deals
with not only the software but has to include hardware issues as
well. For the secondary school pupils it is acceptable to let them
develop their own ideas in order to meet a specification for
something like a maze solving mouse. There is a nice range of
tasks involved, building the mouse from a selection of components,
designing and making sensors, software planning, software design and
code writing and testing. All of this is a good area for Forth and
in such systems it would be easy enough to teach.
A book that many would find useful in their personal library is
Jack Gannsle's "The Art of Designing Embedded Systems". I know that
it does not deal with Forth but the way Jack discusses putting
embedded systems together is very Forth-like in approach (lots of
small routines, incremental development etc). I know that Jack
and myself have discussed a lot of the techniques over the past
10 to 15 years (forget how long really but it is a long time).
Yes, we do need another quality book on applying Forth (a bit more
than the John Matthews "Forth applications in engineering and
industry"). "Starting Forth" and "Thinking Forth" were good for
general technique and approaches to Forth based development. However,
many on here have complained about their age. I, for one, am not too
worried about that. Good books are almost always timeless no matter
what the subject matter.
--
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Yoel Jacobsen
> Yoel Jacobsen wrote:
> >
> > My experience shows that Logo code tend to become ugly and
> > totally unreadable after you finish with the turtle graphics games.
>
> My experience is that any computer code becomes ugly and
> totally unreadable unless you go to great effort to carefully
> comment it. Logo is not usually commented. Forth is not usually
> commented. C code is not usually commented either, but C
> programmers feel guilty about that.
Some langauges tend to become less readable then others. I can
fix/enhance Python code I wrote 4 years ago with almost no comments.
In assembly language it is another story. In Forth you develop the
language of the solution and the great effort is in the choice of
words to implement. Choose wisely and the code will be readable with
no comments at all.
>
> > I'm playing with Forth with my 6 years old boy (Gforth 0.6.2 over
> > Solaris, 'stty olcuc' to turn everything to capital letters). I exposed
> > him to the concept of stack and stack manipulation when he was 5.
> > He grasped that immediately. Now he *enjoy* to *play* with forth.
>
> Solaris for a six year old? Don't you have to worry about
> child abuse? Oh, wait, you are the system administrator. That
> makes a big difference.
I don't teach him Solaris internals. I'm not a sys-admin either. I use
Linux as well. I like systems I can understand..
>
> It is worthwhile to start out teaching a few programming
> ideas. But there is more to programming than the simple things
> you can show a child with Forth (or Scheme, Logo, Java, etc.).
> You forget you are using Solaris. Doesn't it also want 200MB of
> RAM and a power-hungry CPU?
Actually the minimum today is 64MB and an UltraSparc is much less
power-hungry than a Pentium.
> In the days of alphanumeric
> displays, Forth was its own operating and development system.
> Nowadays it is a captive to massive operating systems written in
> C. I can't even use it to avoid knowing anything about MS-Dos. I
> should be able to give a complete beginner a book and a disk and
> say you don't have to know anything else to learn to program
> except Forth. That was the direction Forth was going at one
> time, but not now.
>
Learning to program is learning to factor problems. Forth just does
not stand in the way. I was talking about it with a friend who program
in Java and C++ at work. He told me - why don't you write the program
skelaton and let your child insert input and output statements here
and there?
I think that anyone, a child or an adult learning to program must
completly understand what he is doing.
When my child grow up, I will expose him to Smalltalk/Squeak, which
can enable him to explore the ideas of pure OOP with almost nothing
in the way (minimal syntax, consistency, interpretive).
Yoel
Stephen Pelc
wrote:
>My experience is that any computer code becomes ugly and
>totally unreadable unless you go to great effort to carefully
>comment it.
Agreed.
>Logo is not usually commented.
I haven't seen any for a long time.
>Forth is not usually commented.
Speak for yourself, but certainly not for MPE and many other
Forth shops I know.
>C code is not usually commented either, but C
>programmers feel guilty about that.
I/we look at a lot of Windows and embedded device driver code
in C. Some is good, some is bad. But again and again, whether
code is documented is a house management issue and has almost
nothing to do with the programming language.
Stephen
--
Stephen Pelc, steph...@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
m-coughlin
>
> On Thu, 18 Mar 2004 18:17:44 GMT, m-coughlin <m-cou...@comcast.net>
> wrote:
>
> >My experience is that any computer code becomes ugly and
> >totally unreadable unless you go to great effort to carefully
> >comment it.
> Agreed.
>
> >Logo is not usually commented.
> I haven't seen any for a long time.
>
> >Forth is not usually commented.
> Speak for yourself, but certainly not for MPE and many other
> Forth shops I know.
You and I know Forth can be commented well enough to keep
a project and a software company in business. What I'd like to
have is an example I can show to those who I have met in the
past that do not know this. You did not provide a link to some
examples of properly commented Forth code. Is there some I
should know about?
> >C code is not usually commented either, but C
> >programmers feel guilty about that.
> I/we look at a lot of Windows and embedded device driver code
> in C. Some is good, some is bad. But again and again, whether
> code is documented is a house management issue and has almost
> nothing to do with the programming language.
Very true. When I meet someone who says Forth is a write
only language I tell them that is a fault of management.
Unfortunately these people are involved in management and would
rather place the blame on the language. If the only Forth code
that is easy to read is part of proprietary systems whose source
is not published, then there will be no counter examples to
offset the easily found Forth code that is hard to read.
I don't understand how Forth vendors can't see what a
disadvantage they have over other languages that are taught in
college (such as Scheme) or have a large literature of
instructional material (such as Java and C) that show how to
write readable code to those who are interested.
> Stephen
> --
> Stephen Pelc, steph...@INVALID.mpeltd.demon.co.uk
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
--
Stephen Pelc
wrote:
> You and I know Forth can be commented well enough to keep
>a project and a software company in business. What I'd like to
>have is an example I can show to those who I have met in the
>past that do not know this. You did not provide a link to some
>examples of properly commented Forth code. Is there some I
>should know about?
I have sent you samples in the past. The VFX Forth for Windows
manual is generated from its source code. You know where to
get the evaluation version, which includes some of that source
code, e,g, the multitasker in the LIB directory.