Learning vocaubulary

On Sun, Feb 08, 2009 at 07:40:18PM +0300, Aleksej Saushev wrote:
>
> I can tell you for sure, that Forth is inextricable set of words
> without any classification and even relations inside.

It is inflationary language like this that does us all a disservice.  
Forth is not an inextricable - impossible to be disentangled - set of words,
your code might be, but colorforth, at its heart, is about 32 words which
define the VM, and all of the other words can be defined using just these
words. The forth I currently run has 36 words, and all of the other words 
are written in them.  It is very comprehendisble if you build it bottom up.

As for classification, well, the conventional system of classifying words
in forth is to stick them on the same page (or set of pages).  This is 
really no different from how anyone else classifies code using files or
other forms of metadata.  Comments are afterall just comments.

Failure of programmers to write readable code is not indicative of what
can be achieved with a language.  This is no different from someone failing
to classify each method and class in your Smalltalk IDE of choice.  This
is especially true when you file-in old code. 

I can also write seemingly inextricable sets of words in English watch: 
	
	"Jay's flight back makes money."  

Now you can try to get the meaning of this sentence, but it depends on a
lot of contextual factors that make it meaningless out of context.  You
don't need to know every possible relationship, just a few key factors,
such as Jay is a contract pilot.

This holds true of Smalltalk, as well as, Forth.

> All of implementations known to me put almost everything into FORTH
> wordlist.

Actually, it was for a period all the rage in mega-forths to stick words 
in lots of little dictionaries, and emulate the utter insanity of other 
languages.  Luckily with colorforth, there is a move towards going back 
to using a small base dictionary, and only loading those words your app 
actually need. 

> In Smalltalk you can learn relations between objects
> and classes, in Forth you can't do it, all you can is to resort
> to external tools, not written in Forth in most frequent case,
> and external documentation, which may be outdated or otherwise
> not reflect the reality.

You can learn relationships between words in forth easily.  In 
gforth, you can simply say:

	see word

And presto, you get the full listing for the word.  Even better
in the case of primatives you can get a full source listing of
the assembler!

see drop 
Code drop  
( $3E77 )  mov     eax , dword ptr 3A6AF [ebx]  \ $8B $83 $AF $A6 $3 $0 
( $3E7D )  mov     dword ptr [eax] , ebp  \ $89 $28 
( $3E7F )  add     dword ptr 20C [esp] , # 4  \ $83 $84 $24 $C $2 $0 $0 $4 
( $3E87 )  add     ebp , # 4  \ $83 $C5 $4 
( $3E8A )  mov     esi , dword ptr FC [ebp]  \ $8B $75 $FC 
( $3E8D )  mov     eax , esi  \ $89 $F0 
( $3E8F )  jmp     eax  \ $FF $E0 
end-code
 ok

Colorforth in the 2a family also has this wonderful feature where you
can say:

	find word

And then search through all of the source for ever instance of that word
by simply pushing f over and over again.

I mean seriously, do you think you can't learn the relationships
between words in Forth using tools that are there? It is like saying you
can't learn how Smalltalk code works because you refuse to open the
system browser.
	
> There isn't much complexity in object-oriented design. 

Well judging by the amount of literature written on the subject, the size of
the industry that it has spawned, and the fact that most people can't agree
on what OO actually means, http://www.paulgraham.com/reesoo.html 
I for one would beg to differ. Smalltalk, as a syntax, isn't very complex, 
but the class hierachies and object memories people produce with it are often 
insanely so.

> Most problems exist in your head only,

This is a statement which borders on being a tautology, doubly so since 
the concepts we are talking about exists only in our heads.

> because you have learnt another ways to
> structure programs or haven't learnt it at all, or you have learnt too
> many ways of being object-oriented (late vs. early binding, class vs.
> prototype) and you simply can't focus on single one, because you can do
> any of them in Forth. 

Could you please elaborate on how one can "learn too many ways of being
object-oriented".  It sounds like you are saying one can be too experienced 
or one can understand too much.

> When teaching anyone, it is important to focus
> attention on one single way of doing things, otherwise you don't reach
> any useful effect.

Actually, that flies directly in the face of much of modern ecducational
thinking:

http://books.heinemann.com/shared/onlineresources/08894/08894f6.html

This is not to say that concepts like "whole math" are correct, with its
fuzzy math, but more the Montesori approach can apply.  Humans learn best
in context, and as such you often need to teach multiple things at once. 
This is especially true when learning a language, and Forth is a language
(or maybe a language family) like English or Spanish or Greek.

As with most of these things, one can teach a kid all they need to know
to write a useful program in Forth in a matter of a few hours.  But it will
take years to master all off the intracies of the hardware/software 
combination.   To learn the vocabulary used in any language can take years,
Smalltalk is no exception to this rule.

Dave

PS. I've written more for-profit Smalltalk code over the years than 
for-profit Forth code. I just happen to view OO as a set of useful 
techniques in certain contexts, and view the ever increasing levels of 
religiousity to be the problem.  But just because I'm writing a colorforth 
with OO in it, doesn't mean that I think that OO is a panacea.