Top 10 Language Constructs (Forth) 
Author Message
 Top 10 Language Constructs (Forth)

What do you think are the top ten language constructs in Forth?
Please don't answer in terms of OO concepts, but try to restrict
yourself to those statements you really use to cope with your
daily work.

Curious why I'm asking this question? In spite of all requirements
engineering effort we know exactly *how* to solve problems
with computer languages but know fairly, *what* we're doing
during this process.

Regards
Bruno Gustavs



Tue, 31 Dec 2002 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

> What do you think are the top ten language constructs in Forth?
> Please don't answer in terms of OO concepts, but try to restrict
> yourself to those statements you really use to cope with your
> daily work.

I'm not sure if this is what you are looking for, but Forth is mostly
words, and there are few language constructs. Those that are (not
necessarily in that order), are:

10. RPN, i.e. implicit parameter passing on stack with multiple return
values. This allows to factor common parts by just cut&pasting the equal
parts out of the code and replace it by the factor. IOW you can do
"reverse cut&paste programming". Since most languages highly favour
forward cut&paste programming and that tends to code explosion (of code
that's probably slightly deffective and copied all over the place before
the bug is eliminated). It's not a language construct as "IF THEN", but
a sort of meta-language construct.

9. CREATE DOES>. This is a very powerful and lightweight concept to
"curry" data and functions together. I use it in almost any program.

8. The interpreter. If you know how to use it in the final application,
you see how much work is already done and how little things you have to
add to get the real work done. As item 1, it's a meta-language
construct, though it manifests in words as EVALUATE, INCLUDED and such.

7. The interpreter, again, this time to interactively test words. It's a
different feature (and some de{*filter*} environment allows to interactively
test C functions, too), but ultimatavely, using words interactive shows
you the way how to develop an application language that suits item 3.

6. POSTPONE/IMMEDIATE. Generating code is often a good idea, and you
naturally extend your language to fit what you need.

5. IF ELSE THEN, DO LOOP, BEGIN WHILE REPEAT.

4. : <name> ;

3. Create, Variable, Value, Constant, ...

2. Comments like ( .. -- .. ) or \ to the end of line

1. All the other non-immediate words.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.*-*-*.com/ ~paysan/



Tue, 31 Dec 2002 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

> What do you think are the top ten language constructs in Forth?
> Please don't answer in terms of OO concepts, but try to restrict
> yourself to those statements you really use to cope with your
> daily work.

> Curious why I'm asking this question? In spite of all requirements
> engineering effort we know exactly *how* to solve problems
> with computer languages but know fairly, *what* we're doing

                                   ^^^^^^ "faily little" ?

Quote:
> during this process.

> Regards
> Bruno Gustavs

The fact that the compilation mechanism is

        a) included in the CORE wordset;
        b) open to the user

is IMO the most important aspect of Forth.

The next most important is the use of two stacks to separate data
(integers, flags, addresses) from return addresses used by the threading
mechanism. (Look at what happens in Java with its single stack.) Direct
access to the stack(s) is a sine qua non of Forth and truly
distinguishes it from other languages. Among other things it permits
much finer grained decomposition of programs into subroutines, without
(much) loss of performance in subroutine-calling overhead.

Third is the philosophy that things should be computed (executed) rather
than decided. That is, the operation of branching constructs like
IF...ELSE...THEN,  BEGIN...WHILE...REPEAT or DO...LOOP is accomplished
via immediacy--execution during the compilation process.

The stack manipulation and memory manipulation words are not special to
Forth, they are just concealed in other languages. They often appear as
"noise" words in excessively verbose definitions, so good style tends to
find circumlocutions such as VALUE.

Forth permits several forms of self-modifying code--usually a no-no, but
often immensely valuable for certain tasks. One of the simplest is
vectoring, but Forth also allows EVALUATE, a Lisp-like construct. So in
principle postscript and other specialized interpretive languages could
be written in Forth. Not everyone agrees that EVALUATE is good. Wil
Baden uses it, Anton Ertl eschews it--their opinions are cogent and
well-reasoned--probably you can find them archived in deja.com .

And I like Forth's simplicity: everything is a subroutine, so you don't
have to wonder about the distinctions between functions, subroutines,
data structures, operators, memory allocators, etc. etc. fortran had way
too many things for me to keep track of. Forth, being extensible, let me
do everything I used to do with Fortran, and made many things easy that
are hard in Fortran.

In my own programming (mostly number-crunching and some computer
algebra) I find I use decision structures like jump tables and state
machines frequently. The words ' ("tick") and , ("comma"), and
CREATE...DOES> are key to constructing them. I only rarely have found
uses for :NONAME and COMPILE, . My use of these constructs can be seen
in some of the programs at my Computational Methods website

        http://www.*-*-*.com/ .{*filter*}ia.edu/classes/551/

under "Forth system and example programs".

--
Julian V. Noble

"Elegance is for tailors!"  -- Ludwig Boltzmann

Note mailing address change

    Department of Physics
    University of {*filter*}ia
    P.O. Box 400714                      <---Required now!
    C{*filter*}tesville,  VA 22904-4714



Tue, 31 Dec 2002 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

> What do you think are the top ten language constructs in Forth?
> Please don't answer in terms of OO concepts, but try to restrict
> yourself to those statements you really use to cope with your
> daily work.

I'm not going to give you a list; I'm sure others will do that. Besides
the other things I like about Forth, one thing that will certainly be
mentioned is the separate data stack. What I really appreciate about
this is that its contents are readily visible and manipulable. How many
other languages can you name which allow a function to have multiple
return values (other than by returning a pointer to a memory region
containing the values)?

- wheels



Tue, 31 Dec 2002 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

>> What do you think are the top ten language constructs in Forth?
>> Please don't answer in terms of OO concepts, but try to restrict
>> yourself to those statements you really use to cope with your
>> daily work.

>> Curious why I'm asking this question? In spite of all requirements
>> engineering effort we know exactly *how* to solve problems
>> with computer languages but know fairly, *what* we're doing
>                               ^^^^^^ "faily little" ?
>> during this process.

>> Regards
>> Bruno Gustavs

>The fact that the compilation mechanism is

>    a) included in the CORE wordset;
>    b) open to the user

>is IMO the most important aspect of Forth.

>The next most important is the use of two stacks to separate data
>(integers, flags, addresses) from return addresses used by the threading
>mechanism. (Look at what happens in Java with its single stack.) Direct
>access to the stack(s) is a sine qua non of Forth and truly
>distinguishes it from other languages. Among other things it permits
>much finer grained decomposition of programs into subroutines, without
>(much) loss of performance in subroutine-calling overhead.

>Third is the philosophy that things should be computed (executed) rather
>than decided. That is, the operation of branching constructs like
>IF...ELSE...THEN,  BEGIN...WHILE...REPEAT or DO...LOOP is accomplished
>via immediacy--execution during the compilation process.

>The stack manipulation and memory manipulation words are not special to
>Forth, they are just concealed in other languages. They often appear as
>"noise" words in excessively verbose definitions, so good style tends to
>find circumlocutions such as VALUE.

>Forth permits several forms of self-modifying code--usually a no-no, but
>often immensely valuable for certain tasks. One of the simplest is
>vectoring, but Forth also allows EVALUATE, a Lisp-like construct. So in
>principle PostScript and other specialized interpretive languages could
>be written in Forth. Not everyone agrees that EVALUATE is good. Wil
>Baden uses it, Anton Ertl eschews it--their opinions are cogent and
>well-reasoned--probably you can find them archived in deja.com .

>And I like Forth's simplicity: everything is a subroutine, so you don't
>have to wonder about the distinctions between functions, subroutines,
>data structures, operators, memory allocators, etc. etc. Fortran had way
>too many things for me to keep track of. Forth, being extensible, let me
>do everything I used to do with Fortran, and made many things easy that
>are hard in Fortran.

>In my own programming (mostly number-crunching and some computer
>algebra) I find I use decision structures like jump tables and state
>machines frequently. The words ' ("tick") and , ("comma"), and
>CREATE...DOES> are key to constructing them. I only rarely have found
>uses for :NONAME and COMPILE, . My use of these constructs can be seen
>in some of the programs at my Computational Methods website

NO DEFAULT SYNTAX
To the above I would add that numbers are verbs. A number does "put
yourself on the stack". All tokens therefor have an implicit action. There
is therefor no need for a syntax, and so there is no default syntax.
Things can be acted upon as soon as they are extracted from the input
stream. Words can change the default syntax, and the input buffer is
anyone's to use. This is startling when you see what you can do with it.
RPN isn't a syntax, it's JUST DO IT.

RPN is understandably somewhat off-putting, but it's right up there with
two stacks and the integral compiler for keeping things efficient. I'm
writing a language based on Forth, but very different, and I haven't
even considered making it not be RPN.

SUCCINT VIRTUAL MACHINE
Forth can be a machine, or a virtual machine. The ANS Forth Standard, if I
read it right, expresses a range of such machines as Standard. For any
particular instance of a Forth, standard or otherwise, the machine in
question is utterly un-ambiguous. The value of that is hard to express.

NO `PUNCTUATION'
As a style matter, Forth doesn't attempt to make an artificial distinction
between punctuation and "other". Most languages sortof assume that
puntuation marks are somehow distinct from letters and underscore. They
certainly aren't to a computer. This is a stylistic limitation Forth
lacks.

Forth's downsides are;
        it models a machine that doesn't run well natively on most normal
        CPUs, but the hit is not as bad as most other "interpreters". This
        "impedance mismatch" becomes a huge advantage if you happen to have
        a Forth engine for a CPU, which I believe are fundamentally
        superior to register machines. This is indicative of the
        programming ability of the author of Forth, Chuck Moore. He wanted
        a better language, and his better language inately implies a
        genuinely superior CPU.
        If you have a commodity one-stack CPU, we are blessed with
        wonderful commercial optimizing Forth compilers, which I personally
        tend to consider an additional concept to Forth itself, but
        certainly a valuable enhancement for viability in the highly
        competitive global mission-critical bla, zay, woof and/or WOOF,
        as the case may be.

        Forth namespace tends to explode. "Keep it simple" means have
        jillions of little "it"'s.  

        Having the threader, the definer of new words, AKA the
        compiler, integral to the interpreter and the virtual machine
        is bewildering. It's a full axis on understanding Forth that
        is absent elsewhere. CREATE/DOES> that Julian mentioned means you
        also have control of the threader as well as the rest of the
        language. CREATE/DOES> is also perhaps the "If you get that, you
        got it." of Forth.
        Having said that, that axis isn't really absent elsewhere.
        Programming in a batch-compiled language like C is invariably
        fraught with wondering what the compiler will do with
        such-and-such construct. Forth just makes it explicit, but it's
        tricky, and a bit more of an initial hurdle type thing.

        Forth's design implies that you can get at the guts of it. I
        believe this openness and flexibility has played to Forth's
        disadvantage in the commercial marketplace so far.

        In general, Forth suffers from extreme flexibility.

Note that Forth's essence is utterly antithetical to a listing of discrete
features. RPN works with 2 stacks which works with the fact that it's an
interpreter and a "compiler" etc. etc. etc. Listing the features is like
saying a great historic chess game had some pawns, some bishops, a couple
kings...

Rick Hohensee

- Show quoted text -

Quote:

>     http://www.*-*-*.com/ .{*filter*}ia.edu/classes/551/

>under "Forth system and example programs".

>--
>Julian V. Noble

>"Elegance is for tailors!"  -- Ludwig Boltzmann

>Note mailing address change

>    Department of Physics
>    University of {*filter*}ia
>    P.O. Box 400714                      <---Required now!
>    C{*filter*}tesville,  VA 22904-4714



Wed, 01 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

> Forth's downsides are;
>         it models a machine that doesn't run well natively on most normal
>         CPUs, but the hit is not as bad as most other "interpreters". This
>         "impedance mismatch" becomes a huge advantage if you happen to have
>         a Forth engine for a CPU, which I believe are fundamentally
>         superior to register machines.

That's wrong. Forth is as good for running on a register-oriented CPU as
other languages like C or Fortran. It just takes the same amount of work
to write an optimizing compiler backend for Forth as for any of the
other languages (you save a lot of time on the frontend, though),
something most Forth authors are reluctant to do, because they have
better things to do.

Anton Ertl has several papers about Forth native code generation on
http://www.complang.tuwien.ac.at/projects/forth.html, which you really
should read.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/



Fri, 03 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)


Quote:

> > Forth's downsides are;
> > it models a machine that doesn't run well natively on most
normal
> > CPUs, but the hit is not as bad as most other

"interpreters". This

Quote:
> > "impedance mismatch" becomes a huge advantage if you happen
to have
> >  a Forth engine for a CPU, which I believe are fundamentally
> >  superior to register machines.

I see two statements here. The first is that Forth does not take
full advantage of the architectural features of registers based
machines.  The second statement is that Forth engines are
fundamentally superior to register machines.

The first statement has been made by other people.  As I recall
the way Wil Baden explained this one time was that some algorithms
require juggling a bunch of parameters and that these may be
difficult to express in Forth.  Wil has stated that these sort
of problems are more easily expressed in some other language
than Forth where the stacks only provide easy access to things near
the top of the stacks and where access to a bunch of parameters
can become ugly.

I think that is the point that was being made about Forth and
register machines.  Not that Forth can't compile efficiently
on register based machines, but rather that Forth does not take
full advantage of all the features on these machines.  Because
Forth uses the stack notation it is not always the best match to
register based machines.

Now as to Forth machines being superior to register machines
the statement requires a lot of context in which superior has
a definition.  I think the simplest interpretation is that
the match between Forth and Forth machines is
superior to the match between Forth and register machines
because Forth may not take full advantage of the register
based designs.  In that context it seems like a very defensible
statement.

Of couse superiority is an opinion.  In the context of cost,
power consumption, performance/cost, ease of programming (in Forth),
and things like that I would agree that Forth machines are superior
to register based machines.  But it is just my opinion.  I also
think register based machines are superior for things other than
Forth so I think the statment needs a lot of context to have any
real meaning.

Quote:
> That's wrong. Forth is as good for running on a register-oriented CPU
as
> other languages like C or Fortran. It just takes the same amount of
work
> to write an optimizing compiler backend for Forth as for any of the
> other languages (you save a lot of time on the frontend, though),

but the issue is not just the internals of the compiler, but the
Forth source code itself.  Stack based notations are just not the
easiest way to express all programs.

Quote:
> something most Forth authors are reluctant to do, because they have
> better things to do.

I think the issue is more writing Forth code than writing Forth
compilers.  Despite the fact that I prefer Forth for what I do
I don't think it is the best way to express everything.

Quote:
> Anton Ertl has several papers about Forth native code generation on
> http://www.complang.tuwien.ac.at/projects/forth.html, which you really
> should read.

I think the issue is not so much code generation as the nature
of expressing algorithms in terms of stack use. Forth machines map
well to Forth, but Forth does not map well to everything.  Register
machines map well to Forth, but I question if Forth maps as well
to register based machines.

--
Jeff Fox   UltraTechnology
www.UltraTechnology.com

Sent via Deja.com http://www.deja.com/
Before you buy.



Fri, 03 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)


Quote:
> What do you think are the top ten language constructs in Forth?

I like some of the answers I have seen.  Mine would be:

1. Stacks.   One for data, one for return, possibly more.
2. Words.    Words and spaces, colon definitions (little syntax).
3. Blocks.   Simple custom drivers to hardware.

4. Factor.   Factor the solution to match the problem.
5. Focus.    Focus on the problem being solved.
6. Fun.      Half the fun of Forth is doing it your own way. (C.M.)

7. Think.    View from above, build from below, consider everything.
8. Avoid.    Avoid unsolvable problems seemingly blocking your path.
9. Abstract. Abstract where useful, specialize when it is useful.

10. Choose.  Good, Fast, Cheap, Standard: Pick two or three.

--
Jeff Fox   UltraTechnology
www.UltraTechnology.com

Sent via Deja.com http://www.deja.com/
Before you buy.



Fri, 03 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

>Register
>machines map well to Forth, but I question if Forth maps as well
>to register based machines.

What do you mean here?

--
http://sc3d.org/rrt/



Sat, 04 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:



> >Register
> >machines map well to Forth, but I question if Forth maps as well
> >to register based machines.

> What do you mean here?

Register machines map well to Forth because they have more than
enought resources to do everything demanded by Forth.  Their
instruction set is more than rich enough to provide efficient
implementation of a Forth virtual machine.  The use of registers
to cache stack cells, control stack cells etc. provides for very
high performance of Forth on these machines.

Forth may not map as well to register machines because they
have features that may not be exploited by Forth.  In particular
they can juggle many parameters at once since addressable
registers operate as very fast addressable memory and provide
a mechanism to cache the most valuable variables in a function.

The optimization techniques needed to take advantage of this
style of hardware are different than the optimization techniques
used to optimize stack use.  The mismatch between the simplicity
of the Forth virtual machine and the complexity of register
based machines means that register machines are good for Forth
but that Forth my not be the best choice on register based
machines.

Personally I prefer a simple compiler on simple hardware to
be able to do the same things with less work all around.  I
can understand that if you choose hardware that is 1000x
more complex that the software will also have to be more
complex.  If you choose Forth software that is 100 or 1000x
more complex to match the complex hardware it can take more
advantage of the power hidden in the software.  But other
people are using software that is 1,000,000 times larger
to take full advantage of the hidden power in the hardware.

One can use some of very complex hardware by using simple
software.  It may be of some advantage for productivity to
use this approach but it doesn't squeeze the last of the
juice out of the hardware.  One still has to pay for all
the transistors even if one's approach to software only uses
a few of them.  I recognize that if one pays for the hardware
up front that one can consider paying for the effort to pay for
software that uses the features of register machines that
are not elligantly expressed in Forth.

A good example of the problem is that when people copy
programs from that enviroment into Forth they say they
have the same functionality but they may give up 99% of
the performance by doing this.  They are paying for all
the transistors but only using a small percentage and
thrashing variables in memory if they use code that is
not factored for stack use.  The huge difference between
register speed and memory speed means that caching the
stack but not variables in registers may slow things down
by 100 times.  This type of software on this type of hardware
cries out for multi-pass optimization techniques with careful
variable to register assignments.

--
Jeff Fox   UltraTechnology
www.UltraTechnology.com

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 04 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

>> Forth's downsides are;
>>         it models a machine that doesn't run well natively on most normal
>>         CPUs, but the hit is not as bad as most other "interpreters". This
>>         "impedance mismatch" becomes a huge advantage if you happen to have
>>         a Forth engine for a CPU, which I believe are fundamentally
>>         superior to register machines.

>That's wrong. Forth is as good for running on a register-oriented CPU as
>other languages like C or Fortran. It just takes the same amount of work
>to write an optimizing compiler backend for Forth as for any of the
>other languages (you save a lot of time on the frontend, though),
>something most Forth authors are reluctant to do, because they have
>better things to do.

>Anton Ertl has several papers about Forth native code generation on
>http://www.complang.tuwien.ac.at/projects/forth.html, which you really
>should read.

>--
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://www.jwdt.com/~paysan/



Sat, 04 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

>> Forth's downsides are;
>>         it models a machine that doesn't run well natively on most normal
>>         CPUs, but the hit is not as bad as most other "interpreters". This
>>         "impedance mismatch" becomes a huge advantage if you happen to have
>>         a Forth engine for a CPU, which I believe are fundamentally
>>         superior to register machines.

>That's wrong. Forth is as good for running on a register-oriented CPU as
>other languages like C or Fortran. It just takes the same amount of work
>to write an optimizing compiler backend for Forth as for any of the
>other languages (you save a lot of time on the frontend, though),
>something most Forth authors are reluctant to do, because they have
>better things to do.

>Anton Ertl has several papers about Forth native code generation on
>http://www.complang.tuwien.ac.at/projects/forth.html, which you really
>should read.

OK, I will. This is about batch-compiling Forth right? That ain't Forth.
It may be important, etc., but it's not "Forth" in the basic sense.

I think it's great that it's possible, profitable for a few of you, etc.
I don't think Forth is going anywhere by being "just as good as C".
I admire Forth for the things about Forth itself that are wildly superior
to batch compilers. All this native code optimizing vanishes on a Forth
machine, but it makes widespread use of Forth machines less likely.

etc. etc.

Rick Hohensee
bla zay woof WOOF

- Show quoted text -

Quote:

>--
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://www.jwdt.com/~paysan/



Sat, 04 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)


Quote:
>All this native code optimizing vanishes on a Forth machine,

I don't agree with that.  There are many possible implemenations
of Forth machines.  Many different native code optimization
techniques can be applied to various designs.

Some of it is just the preference of the programmer.  A simple
Forth can be used on a simple chip but one can also use a
complex Forth with lots of optimization tricks.  Having done
both on simple machines I personally came to feel that I could
do all the same optimizations myself in simple code that I
could put into a sophisiticed optimizing compiler that I was
not personally gaining enough by using that approach to prefer
it.  But I can understand that there is value to using more
standard looking code and more sophisticated compiling
techniques.

It is hard to make blanket statements about Forth hardware
just as it is about Forth software.  There are so many variations
possible that there will be lots of excepts to any statements
that are not qualified with a specific context.

I have done ANS optimizing compilers and simple machine Forth
on different machines.  Both approaches have their values.
I prefer one but it doesn't make the other vanish.

Quote:
>but it makes widespread use of Forth machines less likely.

> etc. etc.

I would not agree with that either. Only in the sense that if
people focus so much on one approach that they will refuse to
even look at other approaches would this sort of thing be true.
I think people designing simple machines with simple software
can benefit by learning tricks used  on the complex machines
and complex software.  They can add them to their bag of tricks
and use them where applicable.  The same applies in reverse.
There is still a lot of unexplored territory.

--
Jeff Fox   UltraTechnology
www.UltraTechnology.com

Sent via Deja.com http://www.deja.com/
Before you buy.



Sat, 04 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Forth)

Quote:

>A simple
>Forth can be used on a simple chip but one can also use a
>complex Forth with lots of optimization tricks.  Having done
>both on simple machines I personally came to feel that I could
>do all the same optimizations myself in simple code that I
>could put into a sophisiticed optimizing compiler that I was
>not personally gaining enough by using that approach to prefer
>it.  But I can understand that there is value to using more
>standard looking code and more sophisticated compiling
>techniques.

..

Quote:
>I think people designing simple machines with simple software
>can benefit by learning tricks used  on the complex machines
>and complex software.  They can add them to their bag of tricks
>and use them where applicable.  The same applies in reverse.
>There is still a lot of unexplored territory.

So, if you happen to have an optimising compiler, you can look at what it
does and maybe you'll pick up some tricks from it.  Even if it isn't a great
optimising compiler.  Even if it isn't a very good optimising compiler,
provided it knows some tricks that you don't think to apply.

On the other hand, if you use tricks that didn't come naturally to you, they
probably won't come naturally to other people either.  So your code will get
harder to read.  

Maybe the most readable code has to be written in Visual Basic.  
Well-written VB code can be read by any programmer, and even nonprogrammers
can mostly pick out the meaning.  If readability is the only important thing
maybe some sort of pseudo-code would be particularly readable.  And if
readability is the most important but you'd like it to run also, then VB
might still be the best.  

And only when some combination of other criteria are collectively as
important as readability should you use anything else.



Sat, 04 Jan 2003 03:00:00 GMT  
 
 [ 124 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9]

 Relevant Pages 

1. Top 10 Language Constructs (Smalltalk)

2. Top 10 Language Constructs (Modula2)

3. Top 10 Language Constructs (Oberon)

4. Top 10 Language Constructs (Eiffel)

5. undefined variables (was Top 10 Language Constructs (Modula-2))

6. Top 10 Language Constructs (Scheme)

7. Top 10 Language Constructs (Ada)

8. Top 10 Language Constructs (Cobol)

9. Top 10 Language Constructs (Fortran)

10. Top 10 Language Constructs (Phyton)

11. Top 10 Language Constructs (Prolog)

12. Top 10 Language Constructs (Lisp)

 

 
Powered by phpBB® Forum Software