reasons for failure
graham telfer
People claim many things about particular computer languages. One claim
made of just about every computer language is that learning to program
in it is -- easier, faster, intuitive etc. So why do so many
intelligent people fail to master the skills needed?
I use Forth and want to write an article for FigForth (the UK Forth
magazine) about the reasons that people give up trying to learn how to
program. What might we learn about the shortcomings of computer
languages, and in particular Forth?
Yours Graham Telfer
Elizabeth D. Rather
It is relatively easy to teach Forth to people who have programmed
in other languages. It's very difficult to teach people who have
never done any programming. The reason is that it takes a long
time (a lot of internal re-programming) to "get" the paradigm of
how computers work and what programming means. This has nothing
to do with language. It's a process that university students
spend 6 mos. to a year doing, if they take up programming in
college. Most books on programming languages concentrate on
teaching the language to people who already grasp the paradigm.
Having written several books on Forth, as well as having taught
thousands of students over the years, I know how difficult it
is to deal with this issue. If you undertake to teach at the
level of the total non-programmer, you will spend a vast amt.
of time on things that will be a complete turnoff to those
already past that hurdle, which are probably the bulk of
your market.
It would be nice to get referrals from anyone here to books
that work at this very basic "what is programming all about"
level that can be recommended to the total newbie.
I do remember a story that Kim Harris told many years ago about
teaching beginning programming at a community college. He
started one of his classes on Basic, and the other on Forth.
Midway through the semester he switched languages. The
folks who had started with Basic were delighted to get Forth,
as it was much more powerful. A lot of the ones who started
with Forth dropped out when forced to work with Basic, saying
Basic was a waste of time, they wanted to just go off & use
Forth.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Bernd Paysan
> It is relatively easy to teach Forth to people who have programmed
> in other languages. It's very difficult to teach people who have
> never done any programming. The reason is that it takes a long
> time (a lot of internal re-programming) to "get" the paradigm of
> how computers work and what programming means. This has nothing
> to do with language. It's a process that university students
> spend 6 mos. to a year doing, if they take up programming in
> college.
Like many learning stuff, there's probably a learning window that makes it
easier to learn programming. And Forth is one of the rare languages that
actually make it easy to "get" the paradigm of how computers work.
A lot of languages try to "close the gap" between unexperienced humans and
the computer. Forth doesn't. Therefore, Forth should be more difficult to
teach to people who have inherent difficulties to learn programming at all.
It should be easier to teach for people who don't have these difficulties.
This is backed up by a lot of adult people completely failing to grasp
Forth.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Marcel Hendrix
> Elizabeth D. Rather wrote:
> > It is relatively easy to teach Forth to people who have programmed
> > in other languages. It's very difficult to teach people who have
> > never done any programming. The reason is that it takes a long
[..]
> This is backed up by a lot of adult people completely failing to grasp
> Forth.
This doesn't mean anything. Did they try for weeks on end and fail?
Or did they have one look and gave up immediately (or after half an
hour)?
I can imagine other reasons for 'failing to grasp Forth'. The most
probable being not really wanting to grasp it, or the wrong approach
being used.
Looking at myself, I tried to learn Prolog once but I couldn't get
trough the introductory book (I think it was the book :-)
-marcel
Jim White
> One claim
> made of just about every computer language is that learning to program
> in it is -- easier, faster, intuitive etc.
> languages, and in particular Forth?
One key thing to learn (although it is not particular to Forth) is that
those claims made for each language are only true when the target
application is of the kind for which that language is better suited than
the others.
A corollary is that any claim that any one particular language is better
in every way (or perhaps in any way) than every other language for every
application is false.
Given that as my premise, I don't know what you mean by Forth's
"shortcomings". There are quite a few applications for which Forth is
significantly easier, faster, and more intuitive to use than any other
language. From a commercial/managerial viewpoint, it is instructive to
observe that Forth has been used with great success in many applications
and has shipped in millions of units.
If you are wondering why Forth, with all it's fine qualities, didn't
take over the world, my answer is "Syntax counts". Take the case of
Forth's (somewhat) better known uncle Lisp. Like Forth, Lisp has been
disrespected in all the same kinds of ways. But now here comes XML and
Java and what happens? The world is furiously recreating the same
functionality that Lisp has had for more than twenty years (which
doesn't even take into consideration the twenty years of use it had
before that). And what was the oft-heard rap on Lisp? "Too many damned
right parenthesis" (with Forth it was "Write-only" or the RPN). Yet XML
is being embraced with a syntax that blows up those teeny tiny
parenthesis with whole words bracketed with two angle brackets!
There's no accounting for taste.
Jim
Michael Coughlin
Jim White wrote:
>
> graham telfer wrote:
> > One claim made of just about every computer language is
> > that learning to program in it is -- easier, faster,
> > intuitive etc.
> > ...
> > What might we learn about the shortcomings of computer
> > languages, and in particular Forth?
>
> One key thing to learn (although it is not particular to
> Forth) is that those claims made for each language are only
> true when the target application is of the kind for which
> that language is better suited than the others.
>
I must disagree since Forth is an extensible language that
is easy to implement at a low level. Forth can change itself
into whatever you need for any application at any level. It is
not unchanging and immutable like many other languages.
Unfortunately such an advantage is difficult to use. The
programmer must have what it takes to create good programs to
start with. Forth is an amplifier of its users ability.
If there is something wrong with Forth's syntax then you can
change it. This has been tried many times before. But there is
no particular advantage to doing that. Forth's syntax will let
you do what you need once you get used to it. I don't think it
is a matter of taste. It is a matter of training. Lisp is still
used and highly respected at MIT and Stanford where its inventor
(John McCarthy) worked and taught. What I wonder about Lisp is
not its use of right parenthesis but the question of weather it
can be learned and effectively used by people who are not
qualified to study at a demanding university or be trained by
the leading experts in the field.
I first looked at C, Forth and Lisp at about the same time
after I already knew how to write programs. They all seemed to
be equally useless to me at first. But then I read "Starting
Forth" and immediately saw Forth's superiority. I don't expect
many other people to reach the same conclusion today. Teachers
of other languages have improved their available training
materials while Forth has not.
--
Michael Coughlin m-cou...@attbi.com Cambridge,MA USA
Stephen J. Bevan
> What I wonder about Lisp is
> not its use of right parenthesis but the question of weather it
> can be learned and effectively used by people who are not
> qualified to study at a demanding university or be trained by
> the leading experts in the field.
Lisp, like Forth, has a simple core and IMHO the hardest part about
teaching either is overcoming the barriers that some people
(inadvertently) put up when they are exposed to something different.
Michael Coughlin
Market? What market? Most of the people who I know who use
a computer want to learn to program them. Sometimes this only
means being able to create a web page or understand how to use a
macro command for a word processor. When I tell them if they
don't learn to program the computer, the computer will program
them, they know exactly what I'm talking about. Unfortunately I
can't slip a floppy disk into their machine and give them a
short lesson in programming, using Forth, like I used to be able
to do.
The market for teaching programming to people who have
never done it is vastly bigger than the market for teaching
experienced programmers a new language. But it is a more
difficult task. So isn't that what Forth is for? Making a
difficult job easier?
> It would be nice to get referrals from anyone here to books
> that work at this very basic "what is programming all about"
> level that can be recommended to the total newbie.
I would also like to know what books should be recommended
to beginners. I fear that they will have nothing in them about
Forth. But I hope I'm wrong. Maybe someone will even tell me
about a beginners Forth on a floppy for a current system that I
haven't seen yet.
> I do remember a story that Kim Harris told many years ago
> about teaching beginning programming at a community college.
> He started one of his classes on Basic, and the other on
> Forth. Midway through the semester he switched languages.
> The folks who had started with Basic were delighted to get
> Forth, as it was much more powerful. A lot of the ones who
> started with Forth dropped out when forced to work with
> Basic, saying Basic was a waste of time, they wanted to just
> go off & use Forth.
Is this a good story or a bad one? Does Kim Harris still
teach Forth to beginners? Have any of his students written a
program that I can use? Seems to me it is an example of an
opportunity that existed in the past that has slipped away.
--
Michael Coughlin m-cou...@attbi.com Cambridge, MA USA
J.C.Wren
From:
J.C.Wren <jcw...@jcwren.com>
Date:
Fri, 29 Nov 2002 21:47:05 -0500
Subject:
Confessions of a Forth wannabe (wasRe: reasons for failure)
(beware or rambling and some incoherency...)
This touches on something that I've been thinking about a lot lately.
I've been programming for over 20 years. I'm a hard core assembly/C
person, although I've programmed in several dozen languages (counting
various major flavors of assembly as different). I do webwork,
embedded systems (primarily), and application programming under
Windows and Linux.
I have been a Forth advocate since the days of the Apple II and my
first introduction to Forth by John Draper. However: I'm a lousy
Forth programmer. I hate saying it. I want to use Forth. I want to
write code like Elizabeth and Marcel. But I don't. Why?
Two major reasons: I work on a lot of platforms. Assembly/C becomes
the most common denominator. Yes, Forth *is* available on almost
every platform I've used, but try and convince management that Forth
is the direction to go. Forth, sadly, still carries a bad rap with the
uninformed. Blocks are the primary reason for this. People were
trying to cram as much into a block as possible, didn't comment, and
Forth as a write-only langauge paradigm was born. It was brought on
itself. That overshadowed the power of Forth for a lot of companies.
There are a lot of commercial Forths. I haven't done much research
lately, but SwiftForth seems to be one of the most platform pervasive
Forths out there. I bought a copy of SwiftForth for the PC a few
years ago, but then my time availability shifted and I didn't find
time to start anything. Plus, it seems like I have a short attention
span, and other projects came up that pulled my focus.
Many times I thought about doing a project in Forth, but realized
I could do it quicker in C or Perl (familiarity). And I've also
found that most of the free Forths really don't handle generating
applications well. I've done a couple small things in Zimmers'
FPC (a most excellent Forth, but rather locked into DOS). Generating
ROMable code in a lot of the free embedded Forths is a major pain
in the rear.
I am of the opinion that one of the hardest things to learn about
Forth is when to use immediate words. The assembler is a good
exmaple. Mnemonics are active code. This is contrary to most
ways of thinking for people based in languages like C. Learning
to recognize that A) you *can* do that, and B) *should* do that
are some of the points that make a Forth programmer effective.
Several times I've looked at projects thinking "Jeez, how would I
do this, especially since I'm so unskilled at this?". Then I
realize I'm thinking wrong, that rather than trying to interpet
assembly with Forth (picking a random example), I should design
the words to actually generate code. Of course, this leads to
postifx assemblers, which I really hate, but still, it makes for
a decent example.
The other day I started hunting for Forths for Linux to play around
in again. Half of the ones I found wouldn't compile. Most of the
rest were so poorly documented that it wasn't worth the time to
take apart and figure out what was going on. In fact, I think
many of the PD Forths are written because they could, and once they
generated and executed code, the authors lost interest. PFE seems
the most likely useful candidate to be useful. bigForth was really
intruiging because of it's graphics libraries (something I need
if I'm to do this project I'm thinking of), but the docs are mostly
in German, and being a typical monolingual American, I don't read
German. I did finally settle on iForth (although I think Marcel
needs to support downloading the ISO. Mailing CDs is *so* '90s).
So where does this rambling lead to? How do you teach someone that
the power of Forth is in not just that's a programming language, but
that words are active entities, and the true power of Forth becomes
apparent when you start writing words that just don't DO things, but
ARE things (going back to the assembler example). How do you teach
yourself to recognize those conditions, especially when you're used
to thinking of interpeting in terms of Yacc/Lex? Where are the
brutally honest reviews of various Forth distros, and what makes
them good, and what makes the horrid? Or horridly expensive (sorry,
SwithForth. If you're a real company with a real development
budget and real income, with real management that be convinced
that Forth is the way to go, then the $2500 per platform cost could
be rationlized. For the small contract developer and hobbyest,
gotta look somewhere else).
It's kind of ironic to be a Forth evangilizer, and yet have written
such a phenominally small amount of code. I do have to admit to
taking C.H.Tings Forth for the 8051, making it completely native,
and introducing speed improvements in some areas on the order of
6000% or so (mostly math). But I didn't write anything IN Forth,
I just wound up with Yet Another Forth Interpeter...
I'm interesting in peoples opinions on this. How do you convince
management? What case do you make for maintainability, that when
I get hit by the truck, that they'll be able to find another person
that can support it? Where are the good free tools? (we all believe
Open Source is a Good Thing, right?) Where are the objective
reviews of various Forths, the ones that don't mind stepping on
toes about what's good, what's not, and what doesn't even compile
anymore?
--John
Elizabeth D. Rather
> >>>I want to use Forth. I want to
> write code like Elizabeth and Marcel. But I don't. Why?
>
> Two major reasons: I work on a lot of platforms. Assembly/C becomes
> the most common denominator. Yes, Forth *is* available on almost
> every platform I've used, but try and convince management that Forth
> is the direction to go. Forth, sadly, still carries a bad rap with the
> uninformed. Blocks are the primary reason for this. People were
> trying to cram as much into a block as possible, didn't comment, and
> Forth as a write-only langauge paradigm was born. It was brought on
> itself. That overshadowed the power of Forth for a lot of companies.
>
There's been a lot of very readable block code. IMO one of the
big contributors to the "unreadable" myth was articles in magazines,
where the editors confused things badly by not respecting the spacing
before and after things that looked to them like punctuation.
Plus, some very bad code, but you see that with all languages.
> There are a lot of commercial Forths. I haven't done much research
> lately, but SwiftForth seems to be one of the most platform pervasive
> Forths out there. I bought a copy of SwiftForth for the PC a few
> years ago, but then my time availability shifted and I didn't find
> time to start anything. Plus, it seems like I have a short attention
> span, and other projects came up that pulled my focus.
You can get an update very inexpensively.
> Many times I thought about doing a project in Forth, but realized
> I could do it quicker in C or Perl (familiarity). And I've also
> found that most of the free Forths really don't handle generating
> applications well. I've done a couple small things in Zimmers'
> FPC (a most excellent Forth, but rather locked into DOS). Generating
> ROMable code in a lot of the free embedded Forths is a major pain
> in the rear.
Have you looked at our SwiftX cross-compilers? All the
interactivity of Forth and tiny target programs, too.
> I am of the opinion that one of the hardest things to learn about
> Forth is when to use immediate words.
Very rarely in application development.
> The assembler is a good
> exmaple. Mnemonics are active code. This is contrary to most
> ways of thinking for people based in languages like C. Learning
> to recognize that A) you *can* do that, and B) *should* do that
> are some of the points that make a Forth programmer effective.
> Several times I've looked at projects thinking "Jeez, how would I
> do this, especially since I'm so unskilled at this?". Then I
> realize I'm thinking wrong, that rather than trying to interpet
> assembly with Forth (picking a random example), I should design
> the words to actually generate code. Of course, this leads to
> postifx assemblers, which I really hate, but still, it makes for
> a decent example.
Good commercial Forths nowadays do generate code, and
pretty good code at that. You can concentrate on the application,
don't worry about internals.
It sounds as though you're concentrating on the implementation,
rather than using Forth as a tool to solve real-world problems,
which is what it's designed for.
> ...
> So where does this rambling lead to? How do you teach someone that
> the power of Forth is in not just that's a programming language, but
> that words are active entities, and the true power of Forth becomes
> apparent when you start writing words that just don't DO things, but
> ARE things (going back to the assembler example). How do you teach
> yourself to recognize those conditions, especially when you're used
> to thinking of interpeting in terms of Yacc/Lex?
Have you tried my "Forth Application Techniques" tutorial? Available
at low cost on our web site. Good for leading you into problem-solving
strategies (although the first few problem sets are probably too trivial
for you).
> Where are the
> brutally honest reviews of various Forth distros, and what makes
> them good, and what makes the horrid?
Yes, I'd love to see some reviews, too! There was a book review
recently though.
> Or horridly expensive (sorry,
> SwithForth. If you're a real company with a real development
> budget and real income, with real management that be convinced
> that Forth is the way to go, then the $2500 per platform cost could
> be rationlized. For the small contract developer and hobbyest,
> gotta look somewhere else).
SwiftForth hasn't been that expensive in a long time. It's now
$395 and sometimes on sale. SwiftForth Pro (capable of
recompiling its kernel) is more, but you certainly don't need
that as a learner. SwiftX starts at $495, including a board.
> It's kind of ironic to be a Forth evangilizer, and yet have written
> such a phenominally small amount of code. I do have to admit to
> taking C.H.Tings Forth for the 8051, making it completely native,
> and introducing speed improvements in some areas on the order of
> 6000% or so (mostly math). But I didn't write anything IN Forth,
> I just wound up with Yet Another Forth Interpeter...
To really understand the power of Forth, you need to use it
to solve problems!
> I'm interesting in peoples opinions on this. How do you convince
> management? What case do you make for maintainability, that when
> I get hit by the truck, that they'll be able to find another person
> that can support it?
We have customers who have been using Forth for 20 years,
through upgrades in hardware & software, and through several
"generations" of programmers. They send newbies to take our
courses, buy our books, and sometimes call us in to help. It
worke out well enough.
> Where are the good free tools? (we all believe
> Open Source is a Good Thing, right?) Where are the objective
> reviews of various Forths, the ones that don't mind stepping on
> toes about what's good, what's not, and what doesn't even compile
> anymore?
That would be very helpful to all of us.
Cheers,
Elizabeth
a...@redhat.invalid
> "J.C.Wren" wrote:
>> >>>I want to use Forth. I want to
>> write code like Elizabeth and Marcel. But I don't. Why?
>>
>> Two major reasons: I work on a lot of platforms. Assembly/C becomes
>> the most common denominator. Yes, Forth *is* available on almost
>> every platform I've used, but try and convince management that Forth
>> is the direction to go. Forth, sadly, still carries a bad rap with the
>> uninformed. Blocks are the primary reason for this. People were
>> trying to cram as much into a block as possible, didn't comment, and
>> Forth as a write-only langauge paradigm was born. It was brought on
>> itself. That overshadowed the power of Forth for a lot of companies.
> There's been a lot of very readable block code. IMO one of the
> big contributors to the "unreadable" myth was articles in magazines,
> where the editors confused things badly by not respecting the spacing
> before and after things that looked to them like punctuation.
> Plus, some very bad code, but you see that with all languages.
Indeed, and we fairly frequently see bad code posted in this group. I
reckon that proves it's nothing to do with blocks.
Andrew.
geakazoid
Personally I bought a TRS-80 when it was on sale for $99 at R-*hack in
the 1980s. My best friend said to me, "Why do you want that piece of
*hit?"
I replied, "I want to learn BASIC". And I did. I was able to figure
out with a few books that I could make choices and get simple
statements to run a simple program. When I finally enrolled in a
college course, and I was working a full-time job, the course
clarified my previous hacking and made computer logic simple.
Then, I bought an Atari and got lost in the GUI. I could not visualize
the course code and lost interest in programming. Then Atari went out
of business and I realized, "I better learn to program else I can be
buying software forever and upgrading software that becomes obsolete."
So, some nearly ten years later, I started with C++ and that was a
nightmare. I had learned BASIC and it was simple and C++ was so
strange that although I had years of understanding basics of comuters
I could make neither heads nor tails. Then of course, I took Java as
it becoming vogue. That made the C++ easier. (I was at Borland at the
time so I was now getting my courses as part of my job.)
But, I wanted to design and develop ideas that I had started with
simple logic in BASIC and return to being simple. So, I thought,
"Linux". It took two years of learning scripting and and basic unix
commands to realize that I was inside the Spaghetti Code Monster. I
could learn anything I wanted but could I do anything with it?
Realistically, an end-user needs simple things: word processor,
database, etc... (I am sure I could go on but I am skipping it). I
mean I had things to do outside the box I was configuring out.
Yet, I was also beginning to understand that maybe someday I would
rather build something that I designed than re-build what others had
designed. I thought I was crazy. But then a computer chip designer
noticed what I was doing and said, "Looks like you are getting ready
to design embedded projects."
Ok, I had thought that was a fantasy. I was working on some vision
that all my work was going somewhere. As I observed the Linux
movement, and tried things out like the small linuces. I thought there
is a lot of room for evolutionary creativity.
Occasionally, I looked at the Assembly Language but it was really at
the edge of Advanced Abstraction. So, I had mentioned my design ideas
to a retired programmer who sent me to the SVFIG. He told me that I
could do whatever I wanted with the code - design for any machine and
tha I could re-use my code for any platform once I coded it.
Well, now there was the issue that I had to think backwards. Getting
that stack was not easy. But, after getting it, it makes C/C++ really
treacherous as a lang that you are somehow using it like a child
playing pin the tale on the Donkey. You keep whacking at the code
until you hit it right except instead of breaking the Donkey you want
the Donkey to do something. I would never have visualized a stack with
C/C++. C/C++ hides the machine logic whereas the Forth reveals it. It
seems harder because the programmer is forced to look at the logic and
cannot escape it by pressing a switch on the compiler.
If I want to do something quick, I admit, I cheat. I use my pre-coded
source code tools that have what I need to use. But, while I use
those, I am working on my Forth code and hope that I can prototype my
code with whatever I need while developing my Forth code. But I think
that once I really understand it, then it will be so much easier in
Forth that I will eventually just use it as my main lang.
The drawback I see in Forth is not the ease of learning it. It does
not have the shortcuts that other langs offer. The Rapid Applcation
Development IDEs where you can practially write an application with
really very rudimentary knowledge of the PC. Of course I would not
want someone to engineer a Satellite System with a RAD IDE. But most
programmers are not designing Space Age Craft. We all hate it when we
cannot get the Word Processor to do what we want but Nothing is going
to Fall out of the Sky if we crash Word Perfect. So, I guess there is
not a lot of motivation to learn to be so precise as some Forth
Programmers need to be.
I think the best way to really learn Forth is with projects like the
old Heathkits. Since Forth has a more hands on Engineering Approach it
needs to be learned with the circuitry hands on.
I occurs to me that the Ham Radio Clubs are perfect possible Forth
Programmer material. They love building and rebuilding and sharing
communication systems as well as being in control of their equipment.
http://directory.google.com/Top/Recreation/Radio/Amateur/Homebrew/
I do not think Forth is just a programming language. I really think it
is for AI and requires an interest in interacting with the hardware.
geakazoid
Bernd Paysan
> This doesn't mean anything. Did they try for weeks on end and fail?
> Or did they have one look and gave up immediately (or after half an
> hour)?
Let's take my coworker. I forced him to learn Forth by writing a simulator
for one of our chips, where he did the programming. Later, he wanted to use
the simulator himself productively, which involved writing own code. He
bought this feature, read Starting Forth, and afterwards was able to write
the small and simple code parts that were necessary to make effective use
of the simulator. However, he also tried to understand the simulator code
itself, and failed. His complaint was that Forth builds up on layers of
layers of subroutines.
I think that's the main problem. My coworker is one of those people who
write Fortran code in any language, goto-ladden, with global variables and
all sort of evil stuff, but few subroutines, no abstractions of their own
an so on. The few subroutines he builds and uses himself are standard stuff
like multiplication or wider addition, which isn't available on an 8 bit
processor.
His Forth code were all one-lines, but they weren't nested. It wasn't
necessary, since they did build nicely on the abstractions I created. I
think he simply fails to create abstractions himself, and make good use of
subroutines.
Despite he did write Forth code, and UPN wasn't a problem, he claimed that
he failed to learn Forth. I think he simply failed to learn programming
beyond a certain basic level (or BASIC level ;-).
Rufus V. Smith
"geakazoid" <aze...@dolfina.org> wrote in message
news:6dd87c5d.02113...@posting.google.com...
> I do not think Forth is just a programming language. I really think it
> is for AI and requires an interest in interacting with the hardware.
>
I wouldn't call it "for AI", but I think I know what you mean.
I think of it as an "intelligence mapping" system.
You map your knowledge and way of thinking onto your target
device/system by way of the Forth "language".
You create your own tools and syntax and program structure.
This is probably one of the reasons reading Forth can be
so difficult. People don't think the same way and looking at a
system so totally tailored to one person's way of thinking can
make it less accessible (to others) than a system programmed
in a language that has more prejudices, rules, idiosyncrasies,
presupplied syntax and other baggage. (Ways to force multiple
different ways of thinking into a common mold) But in multi-
programmer projects, sometimes it's better two have two program-
mers meeting halfway at a fixed point, than one programmer
going all the way over into the other's mindset.
Rufus
dwight elvey
>
> People claim many things about particular computer languages. One claim
> made of just about every computer language is that learning to program
> in it is -- easier, faster, intuitive etc. So why do so many
> intelligent people fail to master the skills needed?
Hi
I feel the biggest problem with people learning programming
languages in general is that they are usually swamped with
a lot of words( or commands ) that don't quite match what
they have been used to in common spoken language. Forth like
C has a bunch of meanings to things like & or * that don't
make obvious sense( C even has multiple means for each).
Moving along, there is a second factor. This is when the person
has learned some of the language in question but still has problems
because nothing seems to work. One of the fundamental things that
a programmer needs to know, for both writing code and trouble
shooting bugs, is how to factor a problem. Most that have
done programming for a period of time, that are successful,
do this naturally and don't realize that this is really an
alien way of thinking to the average person.
Now that the person has grasp the basics and is programming
for a number of years, they decide to go off and run a realestate
company or something. Most of these people have a problem
with programming that causes dropouts at all stages. The issue
is that people make mistakes. Many people's ego can't deal
with making mistakes. Most don't enjoy the process of solving
the mystery. All they think about is at first, "I couldn't
have done anything wrong" and later, "How could I have been
so stupid". What makes it worse for them is it is often the
same mistake. Of course, what they don't realize is that this
is human nature. Programming is not your everyday 'find food
and shelter' problem. Mistakes will happen.
Now, on to why I like Forth over most other languages and
I'm willing to deal with the stack in order to use it.
Programming is telling a computer what to do. It is like
making an exacting instruction sequence for the assembly
of some item. It is like "Do this, then this and then that".
With the ability to factor the problem, each of these
steps can be easily abstracted to the level needed to
complete the task. I can work on the top level or switch
to working on the lowest level. I can incrementally test
and find my errors, as I go, while it is still fresh in
my mind, what I expected that part of the code to do.
The Forth syntactical flow is about as straight forward
as it can be. The order that I tell it to do something
is the order it gets done, no tricks, no special parsers.
Dwight
Ulrich Hobelmann
> It is relatively easy to teach Forth to people who have programmed
> in other languages. It's very difficult to teach people who have
> never done any programming. The reason is that it takes a long
> time (a lot of internal re-programming) to "get" the paradigm of
> how computers work and what programming means. This has nothing
> to do with language. It's a process that university students
> spend 6 mos. to a year doing, if they take up programming in
> college. Most books on programming languages concentrate on
> teaching the language to people who already grasp the paradigm.
> Having written several books on Forth, as well as having taught
> thousands of students over the years, I know how difficult it
> is to deal with this issue. If you undertake to teach at the
> level of the total non-programmer, you will spend a vast amt.
> of time on things that will be a complete turnoff to those
> already past that hurdle, which are probably the bulk of
> your market.
Most people just hear simple stupid Java-intro courses at University,
and don't even grasp simple things that make _structure_.
These people will never get the guts of structured coding, unless they
should really try someday.
> It would be nice to get referrals from anyone here to books
> that work at this very basic "what is programming all about"
> level that can be recommended to the total newbie.
A very nice intro to programming is SICP (Structure and Interpretation
of Computer Programs), which uses Scheme (a very clean lisp dialect).
Also since I think most non-programmers (i.e. users) prefer fool-proof
systems to close-to-the-metal ones, which favors sth like Scheme.
Still most Forth intros I've read were written for complete beginners I
think, since in the DOS days there were not many other languages
available anyway (like C dialects are everywhere today), so Forth was
*the* entry to programming for many I think.
> I do remember a story that Kim Harris told many years ago about
> teaching beginning programming at a community college. He
> started one of his classes on Basic, and the other on Forth.
> Midway through the semester he switched languages. The
> folks who had started with Basic were delighted to get Forth,
> as it was much more powerful. A lot of the ones who started
> with Forth dropped out when forced to work with Basic, saying
> Basic was a waste of time, they wanted to just go off & use
> Forth.
I think most Basic dialects are failed attempts at making coding easier.
Forth and Scheme are so much better choices, since they don't shoot you
with tons of features, but build on simple, clean building blocks.
> Cheers,
> Elizabeth
>
Ulrich
geakazoid
> graham telfer <gte...@po.synapse.ne.jp> wrote in message news:<3DE2B7CA...@po.synapse.ne.jp>...
> > Hi
> >
> > People claim many things about particular computer languages. One claim
> > made of just about every computer language is that learning to program
> > in it is -- easier, faster, intuitive etc. So why do so many
> > intelligent people fail to master the skills needed?
>
> Hi
> I feel the biggest problem with people learning programming
> languages in general is that they are usually swamped with
> a lot of words( or commands ) that don't quite match what
> they have been used to in common spoken language. Forth like
> C has a bunch of meanings to things like & or * that don't
> make obvious sense( C even has multiple means for each).
That is true, yet one of the things that helped me to get through to
some understanding was when one programmer explained the programming
language was a language like any spoken language.
We have over 6,000 langs on the planet. There are some commonalities
such as pausing between structures, taking a breathe (as you would if
you were a musician playing a line of music on a flute or horn),
shifts in sounds to emphasize ir de-emphasize pitch, etc... So,
literally learning to speak is quite a complex set of musical ability
for an average human to accomplish.
So, when this programmer explained that there are Sentences and
Sentence Structures, and there were periods and commas, and etc... I
was beginning to identify the logic of a code structure. But, learning
C++ was so complicated because a Sentence is not a Sentence of
developing and Idea; it is a Concept already. It like the difference
between arithmetic and algebra and sometimes calculus.
I think if programming was Human, it would be easier to Identify with
the Code.
> Moving along, there is a second factor. This is when the person
> has learned some of the language in question but still has problems
> because nothing seems to work. One of the fundamental things that
> a programmer needs to know, for both writing code and trouble
> shooting bugs, is how to factor a problem. Most that have
> done programming for a period of time, that are successful,
> do this naturally and don't realize that this is really an
> alien way of thinking to the average person.
Yes, that is why the other people on the planet see the programmers as
Aliens. -)
> Now that the person has grasp the basics and is programming
> for a number of years, they decide to go off and run a realestate
> company or something. Most of these people have a problem
> with programming that causes dropouts at all stages. The issue
> is that people make mistakes. Many people's ego can't deal
> with making mistakes.
That would not be so true if were not for the Consensus Reality always
in Judgement of Everyone's Performance.
Let me give you an example:
I realized I could get As in school if I merely learned how to mimick
the Teachers way of thinking. If it was not a T/F or Multiple Choice
Test, all I had to do was remember the Character of the Teacher and I
would know how to answer questions. I was merely giving them what They
Wanted to Hear.
Late in college, I figured out that I was realizing things that They
did not want to hear. For instance, I gave a term paper on Sociology
that the Socialogical Theory was based upon the Mind of the
Sociologist that we studied and that was his interpretation of Reality
and that he had put everyone into Boxes. That was a good Paper in a
Philosophy class but not for a Sociology class. I had departed from
giving Them what They Wanted. That year my grade average went down a
half point from A to A-.
Now, we are supposed to learn how to Think for ourselves, but how can
we Learn how to think when Our Thinking is Limited by what someone
else Thinks?
It is not really Ego that we are limited by but the Consensus Reality
that states that if we Solve an Issue that No One else sees, we are
strange; if we Solve and Issue that No One else wants to see, we are
really "wierd"; if we cannot Solve an Issue that No One sees, we are
"out there" on a limb; Or if we cannot Solve and issue that No One
wants to see, we are "really lost".
Let's face it: the Mind is an Abstract Concept.
If that is true, then we are merely limited by our own Concepts.
And, in general, most humans do not know how to use their Mind and
thus they do not know how to use Abstract Concepts.
Most don't enjoy the process of solving
> the mystery. All they think about is at first, "I couldn't
> have done anything wrong" and later, "How could I have been
> so stupid". What makes it worse for them is it is often the
> same mistake.
Somehow our culture does not allow for mistakes. If you make mistake
you may not be able to eat and have a home.
Of course, what they don't realize is that this
> is human nature. Programming is not your everyday 'find food
> and shelter' problem. Mistakes will happen.
More and more our food and shelter is based upon programming. -)
If people do not learn how to program their own computers, they will
not be able to keep up with the flow of information that designs,
develops, creates our reality in the New Millenium.
For example: any business that relies on sales will need, now, Palm
tops to take orders in the field. I mean you need to be fast to make
the sales and having a Palm would make you the Survivor of the Fitest
out there in the Jungle of Marketing. A portable advantage of being
able to take names and numbers...
So, you want to really customize your work station, out in the
Concrete Jungle, you should be ready to evolve with the knowledge
based needs. So, of course, you would have to use some programming
language like Quartus Forth to organize the data. You need to be able
to connect to the rest of the herd to get the order to the
headquarters before someone else. -)
I'm making a joke, but I am serious about the speed at which one has
to evolve with the technology in order to survive in this New World.
Programming Languages are going to be like Greek and Latin to the
Academics of the past few thousand years. Organizing our realities
around the Tech Speak of the Modern Techgnosis will make Programming
Logic part of our Human Psyche.
That is why I think Forth has a real competitive edge. It is low level
and high level at the same time. It could be simplied for an end-user
base who would have otherwise been learning Macros of various other
langs. anyway.
geakazoid