|
|
 Up |
|
|
  |
Author: John DotyJohn Doty Date: Oct 5, 2006 15:11
J Thomas wrote:
> I think maybe it would be more useful (or very useful in combination
> with a new Forth) to have great applications that let brand new users
> do impressive things.
I agree 100%%. Applications are what it's all about. You've given an
example from TCL. Let me comment on what I think Python has to teach us
here.
Python straight out of the box is almost useless. There's a VM, a
compiler, and a subtle and powerful module import facility. Essentially
nothing else. But, there are *thousands* of published modules that
customize it for almost any application area. A user can import a module
or three and hit the ground running on an impressive app.
Neal Bridges wrote:
> Off the top of my
> head -- Ed's floating-point output routines (thanks again, Ed!); Wil
Baden's
> Mersenne Twister, CRC, and many others; Len Zettel's bignum package; Brad
> Eckert's floating-point routines; Bernd Paysn's x86 assembler; the x86
> disassembler from McKewan, Zimmer, et al; the FSL; the list goes on.
|
| Show full article (3.36Kb) |
|
| | 65 Comments |
|
|
Author: Neal BridgesNeal Bridges Date: Oct 5, 2006 17:01
"John Doty" whispertel.LoseTheH.net> wrote in message
news:feadnTutTr25HrjYnZ2dnUVZ_t6dnZ2d@wispertel.com...> Neal Bridges wrote:
>> Off the top of my
>> head -- Ed's floating-point output routines (thanks again, Ed!); Wil
> Baden's
>> Mersenne Twister, CRC, and many others; Len Zettel's bignum package;
Brad
>> Eckert's floating-point routines; Bernd Paysn's x86 assembler; the x86
>> disassembler from McKewan, Zimmer, et al; the FSL; the list goes on.
>
> But for every one you can name here, a Pythonian can name 10-100
> published modules. Why is this? I think there are two reasons, one
> cultural, the other technical.
|
| Show full article (1.31Kb) |
|
| | 52 Comments |
|
|
Author: J ThomasJ Thomas Date: Oct 6, 2006 05:29
John Doty wrote:
> Python straight out of the box is almost useless. There's a VM, a
> compiler, and a subtle and powerful module import facility. Essentially
> nothing else. But, there are *thousands* of published modules that
> customize it for almost any application area. A user can import a module
> or three and hit the ground running on an impressive app.
....
> But for every [ portable Forth app] you can name here, a Pythonian can name 10-100
> published modules.
>
> So, I imagine a Forth that, like Python, has only a VM, a compiler, and
> an import facility when it starts up.
It would be good for it to also have a CLI or a GUI + pulldown menus
etc. So you don't need to leave your Forth environment to call up Forth
routines. (In this context I'd consider the difference between an
interpreter and a compiler that compiles a line of source and executes
it, an implementation detail.)
|
| Show full article (2.98Kb) |
| no comments |
|
|
Author: George HubertGeorge Hubert Date: Oct 6, 2006 06:46
John Doty wrote:
> J Thomas wrote:
>
>> I think maybe it would be more useful (or very useful in combination
>> with a new Forth) to have great applications that let brand new users
>> do impressive things.
>
> I agree 100%%. Applications are what it's all about. You've given an
> example from TCL. Let me comment on what I think Python has to teach us
> here.
>
> Python straight out of the box is almost useless. There's a VM, a
> compiler, and a subtle and powerful module import facility. Essentially
> nothing else. But, there are *thousands* of published modules that
> customize it for almost any application area. A user can import a module
> or three and hit the ground running on an impressive app.
>
> Neal Bridges wrote:
>
>> Off the top of my ...
|
| Show full article (5.35Kb) |
| 1 Comment |
|
|
Author: JamesJames Date: Oct 6, 2006 06:59
First, Python has a lot more built-in functionality than Forth: lists,
dictionaries, file I/O, objects, iterators, sorting, unicode, elaborate
string manipulation, unlimited size integers, etc. You don't import
modules to use any of these features.
Second, to make this work I think you'd need to divorce Forth's
low-level nature. Have a memory management system that isn't just a
flat dictionary and address space. Check memory accesses. To get
people focused on writing useful modules, you need to keep them
thinking at the problem level, and not in terms of low-level details.
I'd argue that Factor is already a "21st century Forth," in that it
follows the spirit of Forth (simplicity, access to internals of system,
preference for stack manipulation rather than local variables).
|
| |
| 2 Comments |
|
|
Author: Aleksejj SaushevAleksejj Saushev Date: Oct 6, 2006 07:12
"George Hubert" yahoo.co.uk> writes:
> John Doty wrote:
>> J Thomas wrote:
>>
>> I agree 100%%. Applications are what it's all about. You've given an
>> example from TCL. Let me comment on what I think Python has to teach us
>> here.
> Surely Python is a single implementation (assuming it exists on all
> available architectures), so such restrictions can be applied and
> guaranteed to work. Forth is made up of many implementations, using
> different strategies, for many different architectures, so there are
> bound to exist things that work on some systems, but not others.
> Similarly different systems will work better with a particular
> implementation of something, so it makes sense for systems to include
> optimised (for that system) versions of common things. Forth systems
> don't have to include everything in a pre-compiled executable; they can
> provide optional code in a loadable form, it's down to what their users
> prefer.
|
| Show full article (1.55Kb) |
| no comments |
|
|
Author: Aleksejj SaushevAleksejj Saushev Date: Oct 6, 2006 07:21
"James" gmail.com> writes:
> First, Python has a lot more built-in functionality than Forth: lists,
> dictionaries, file I/O, objects, iterators, sorting, unicode, elaborate
> string manipulation, unlimited size integers, etc. You don't import
> modules to use any of these features.
> Second, to make this work I think you'd need to divorce Forth's
> low-level nature. Have a memory management system that isn't just a
> flat dictionary and address space. Check memory accesses. To get
> people focused on writing useful modules, you need to keep them
> thinking at the problem level, and not in terms of low-level details.
Forth has file I/O and dynamic memory management, what it lacks
is elaborated higher level conventions. E. g. there are
"save-mem" (Gforth) and "heap-copy" (SP-Forth & derived) for
almost the same thing. There's no common designation for
big-endian/low-endian conversion etc.
|
| |
| no comments |
|
|
Author: George HubertGeorge Hubert Date: Oct 6, 2006 07:37
Aleksejj Saushev wrote:
> "George Hubert" yahoo.co.uk> writes:
>>> John Doty wrote:
>>> J Thomas wrote:
>>>
>>> I agree 100%%. Applications are what it's all about. You've given an
>>> example from TCL. Let me comment on what I think Python has to teach us
>>> here.
>
>> Surely Python is a single implementation (assuming it exists on all
>> available architectures), so such restrictions can be applied and
>> guaranteed to work. Forth is made up of many implementations, using
>> different strategies, for many different architectures, so there are
>> bound to exist things that work on some systems, but not others.
>> Similarly different systems will work better with a particular
>> implementation of something, so it makes sense for systems to include
>> optimised (for that system) versions of common things. Forth systems
>> don't have to include everything in a pre-compiled executable; they can
>> provide optional code in a loadable form, it's down to what their users ...
|
| Show full article (1.46Kb) |
| 1 Comment |
|
|
Author: Aleksejj SaushevAleksejj Saushev Date: Oct 6, 2006 07:44
"George Hubert" yahoo.co.uk> writes:
> Aleksejj Saushev wrote:
>> "George Hubert" yahoo.co.uk> writes:
>>>>> John Doty wrote:
>>>> J Thomas wrote:
>>>>
>>>> I agree 100%%. Applications are what it's all about. You've given...
|
| Show full article (1.72Kb) |
| no comments |
|
|
|
|
|
Author: John DotyJohn Doty Date: Oct 6, 2006 09:24
James wrote:
> First, Python has a lot more built-in functionality than Forth: lists,
> dictionaries, file I/O, objects, iterators, sorting, unicode, elaborate
> string manipulation, unlimited size integers, etc. You don't import
> modules to use any of these features.
Yes, the Python VM is a high level abstraction. Whether that's a feature
or a deficiency depends on what you're trying to accomplish.
>
> Second, to make this work I think you'd need to divorce Forth's
> low-level nature. Have a memory management system that isn't just a
> flat dictionary and address space. Check memory accesses. To get
> people focused on writing useful modules, you need to keep them
> thinking at the problem level, and not in terms of low-level details.
But a key advantage of Forth is that you can work on *any* level. Give
that up, and you might as well not bother with Forth at all.
|
| Show full article (1.21Kb) |
| no comments |
|
RELATED THREADS |
|
|
|
|
|
|
