I came across this in the archives:

	>The widely shared belief (among both Forthies
	>and outsiders) that every "real" Forth programmer hacks together
	>his own compiler/interpreter/programming environment also makes
	>the Forth community look frivolous or at best naive. Most people
	>who program for a living know that there are more useful ways to
	>spend their time than building their own programming environment --
	>the key to productivity is leveraging off other peoples' work.

	HERESY in the Forth community!  Imagine... NOT coming up with
	your own CASE statement or local variable implemetation?  Use
	OTHER PEOPLES TOOLS?  Yuccch!

	One thing you can count on in the Forth community... try
	to establish a standard ANYTHING, and all that will happen
	is others will come up with their own implementation, defeating
	the purpose of standardization.

Why is this?

I mean, I'm usually quite happy to program in other languages without
building my own interpreter or compiler. For instance with Ruby, the
only time I even considered it's implementation was when I was
learning how it's class structure was organised, and that was only
because some of my references talked about the internals.

Now with Forth, it seems like every step along the way makes me think
about writing my own implementation! A couple of months back I
designed (in outline) a prototype based OOPS for forth, and before I
could finish it I was planning how to write a forth in it! I  mean,
words are just objects, right? More recently I've been a little
obsessed with data flow models. After realising that a fully
paralisable pipes and streams architecture was a little bit overkill
to read a terminal input I discovered how nicely this approach maps to
forth using the stack as a data-flow channel, and then quite suddenly
I realised I'd reimplemented a crude forth interpreter.

It's like an itch that I just have to scratch!

I've been trying to learn standard forth as a programming language,
rather than a system implementation, I really didn't want to write my
own, at least not yet! But now I feel compelled to do so, in order to
really understand the standard. I believe that one of the intensions
of the standard was to definine an implementation independent
language, but still, there seem to be a few areas that scream out to
me 'implementation' rather than 'intension'.  At least, I hope, if I
do roll my own forth, these areas will be more clearly defined for me.

Forth isn't the only language where people will write their own
implementations of course, it seems to be a fairly common experience
with people learning lisp, and perhaps some other relatively pure
languages. So I thought that maybe the fact that the essential forth
model is small enough to be readily understood in one chunk might have
something to do with it. But maybe there's another explanation: also,
because the core concepts are so simple, the language doesn't get in
your way when thinking about a problem. So naturally, when your
thinking about the 'problem' of forth you come up with something like
forth as a solution.

I'm not sure where I'm going with this, I guess I wish I could just
stop at the 'forth is simple' bit! Anyway.

Regards,
Emma

ember@dyeforit.co.uk wrote:
> I came across this in the archives:

>         >The widely shared belief (among both Forthies and
>         >outsiders) that every "real" Forth programmer hacks
>         >together his own compiler/interpreter/programming
>         >environment also makes the Forth community look frivolous
>         >or at best naive. Most people who program for a living know
>         >that there are more useful ways to spend their time than
>         >building their own programming environment -- the key to
>         >productivity is leveraging off other peoples' work.

>         HERESY in the Forth community!  Imagine... NOT coming up
>         with your own CASE statement or local variable
>         implemetation?  Use OTHER PEOPLES TOOLS?  Yuccch!

>         One thing you can count on in the Forth community... try to
>         establish a standard ANYTHING, and all that will happen is
>         others will come up with their own implementation, defeating
>         the purpose of standardization.

> Why is this?

Well, I'd be careful not to assume that everything in c.l.f. is true.
After all, there is a Forth standard.

> Forth isn't the only language where people will write their own
> implementations of course, it seems to be a fairly common experience
> with people learning lisp, and perhaps some other relatively pure
> languages. So I thought that maybe the fact that the essential forth
> model is small enough to be readily understood in one chunk might
> have something to do with it.

Well, right.  Programming language design and implementation is
interesting, and Forth gets you started.  It's much less of a learning
curve than for example C, whose implementations are very complex.

[ A digression: Once you get going, Forth seems easy and almost
obvious, but really it isn't: language design, in particular, requires
a combination of technical knowledge and good taste.  Forth evolved
over a long period of time, and the result is a distillation of a lot
of experience of using it to write applications.  That's why it's
important that Forth, Inc have always combined application writing and
Forth system development. ]

> But maybe there's another explanation: also, because the core
> concepts are so simple, the language doesn't get in your way when
> thinking about a problem. So naturally, when your thinking about the
> 'problem' of forth you come up with something like forth as a
> solution.

That too.

Andrew.

ember@dyeforit.co.uk wrote:
> I came across this in the archives:
> 
> 	>The widely shared belief (among both Forthies
> 	>and outsiders) that every "real" Forth programmer hacks together
> 	>his own compiler/interpreter/programming environment also makes
> 	>the Forth community look frivolous or at best naive. Most people
> 	>who program for a living know that there are more useful ways to
> 	>spend their time than building their own programming environment --
> 	>the key to productivity is leveraging off other peoples' work.
> 
> 	HERESY in the Forth community!  Imagine... NOT coming up with
> 	your own CASE statement or local variable implemetation?  Use
> 	OTHER PEOPLES TOOLS?  Yuccch!
> 
> 	One thing you can count on in the Forth community... try
> 	to establish a standard ANYTHING, and all that will happen
> 	is others will come up with their own implementation, defeating
> 	the purpose of standardization.
> 
> Why is this?

It isn't.  I don't know who wrote that, but the vast majority of Forth 
programmers are using existing systems to do serious programming.  There 
are a number of popular Forth implementations, both open-source and 
commercial, all of which have many users.

Indeed, some people are interested in doing their own implementations 
because (as Andrew says) it's easier in Forth than many languages, and 
some find it an intriguing intellectual exercise.  But most people who 
have real work to do start with the existing implementation closest to 
their application needs.

And (also as Andrew says) most of the popular implementations do follow 
the ANSI/ISO Forth standard.

People write a lot of silly things on Usenet groups.

....
> 
> Now with Forth, it seems like every step along the way makes me think
> about writing my own implementation! A couple of months back I
> designed (in outline) a prototype based OOPS for forth, and before I
> could finish it I was planning how to write a forth in it! I  mean,
> words are just objects, right? More recently I've been a little
> obsessed with data flow models. After realising that a fully
> paralisable pipes and streams architecture was a little bit overkill
> to read a terminal input I discovered how nicely this approach maps to
> forth using the stack as a data-flow channel, and then quite suddenly
> I realised I'd reimplemented a crude forth interpreter.
> 
> It's like an itch that I just have to scratch!
> 
> I've been trying to learn standard forth as a programming language,
> rather than a system implementation, I really didn't want to write my
> own, at least not yet! But now I feel compelled to do so, in order to
> really understand the standard. I believe that one of the intensions
> of the standard was to definine an implementation independent
> language, but still, there seem to be a few areas that scream out to
> me 'implementation' rather than 'intension'.  At least, I hope, if I
> do roll my own forth, these areas will be more clearly defined for me.

I would strongly recommend that you write some applications in Forth 
before trying to design your own Forth.  There's a lot more there than 
meets the eye.  Would you attempt to design and build an automobile 
before learning to drive?

There are books on Forth available (some of which I've written), that 
will be helpful in learning how to use Forth effectively.  Neither the 
Standard document nor "rolling your own" will teach you nearly as much 
as either the existing books or your experience as a user or (ideally) both.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On May 2, 10:12=A0am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> After all, there is a Forth standard.
Yes, so very true. Although my 4tH started out as my interpretation of
what Forth should be, Wil Baden convinced me that in order to be to be
successful, alignment with ANS-Forth is required. True, there are
still some ANS-Forth quirks I refuse to implement (because they defeat
the design objectives of 4tH) I keep a close look of where ANS-Forth
is going and align with it wherever possible or required.

> Well, right. =A0Programming language design and implementation is
> interesting, and Forth gets you started. =A0It's much less of a learning
> curve than for example C, whose implementations are very complex.
True again. Even to be a successful C programmer you need to know what
is going on under the hood to some extent. "Advanced C" gave me that
knowledge. Forth is much easier in that respect. You can write a Forth
parser from scratch very easily, which is much harder to do for C.
Code generation is much harder as well.

In short, any idiot can built a Forth compilers and many idiots
have ;-) ;-)
(Present company included.. ;-)

But there are several other considerations I want to give you:

(a) If you do it for an intellectual exercise ONLY, you'll find you
get bored very quickly after you've developed it. You might not even
see it to the very end (a full implementation). Please, keep it for
yourself, DON'T dump it on the internet - or even worse - Sourceforge
or Freshmeat. There are numerous half-baked Forths on the internet,
buggy, without any documentation. These "implementations" give Forth a
BAD name, a toy for geeks, unprofessional.

(b) If you DO want to publish it, be aware that a full project will
require dedication. Proper documentation (don't just rely on the
tutorials on the web unless you made a vanilla implementation), proper
project management and supporting a community. This takes TIME and a
long time investment.

(c) There are SO MANY Forth compilers on the web, what does yours have
to add? Think about that before you engage your project. If there
really no Forth that suits your needs? We got embedded Forths (4tH,
Ficl, Atlast), small Forths (eForth, RetroForth), professional Forths
(SwiftForth, iForth), big Forths (gForth, bigForth), native code
Forths (4thcmp), OS specific Forths (Win32Forth, FPC, amforth),
vanilla Forths (ThisForth, PFE), etc. etc. (Excuse the ones I did not
mention - the listing is just an illustration). If you want to fill a
niche, think WHAT niche you want to fill.

I started my 4tH over fifteen years ago. I thought it would take me a
year or so and then move on. I'm still on it. ;-)

Hans Bezemer

Elizabeth D Rather <erather@forth.com> writes:
>I would strongly recommend that you write some applications in Forth 
>before trying to design your own Forth.  There's a lot more there than 
>meets the eye.  Would you attempt to design and build an automobile 
>before learning to drive?

That's an interesting comparison.  In the early days automobiles were
so unreliable that one had to understand a lot about how they are
built if you wanted to drive them (and lots of people did pay drivers
instead of driving themselves).  They were also relatively simple so
that one could repair them with common tools.  Nowadays cars contain
lots of black boxes and repairing them often is a matter of replacing
a black box.  Forth is probably more like early cars (except in
reliability:-), as it allows access to the internals, whereas many
other languages are more like modern cars in their black-box-like
usage model.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

ember@dyeforit.co.uk wrote:

> I came across this in the archives:
..... 
> 	One thing you can count on in the Forth community... try
> 	to establish a standard ANYTHING, and all that will happen
> 	is others will come up with their own implementation, defeating
> 	the purpose of standardization.
> 
> Why is this?

Forth is designed to be simple. So people *can* make their own
implementations and call it Forth. So some people will do that.

> Now with Forth, it seems like every step along the way makes me think
> about writing my own implementation! A couple of months back I
> designed (in outline) a prototype based OOPS for forth, and before I
> could finish it I was planning how to write a forth in it! I  mean,
> words are just objects, right? More recently I've been a little
> obsessed with data flow models. After realising that a fully
> paralisable pipes and streams architecture was a little bit overkill
> to read a terminal input I discovered how nicely this approach maps to
> forth using the stack as a data-flow channel, and then quite suddenly
> I realised I'd reimplemented a crude forth interpreter.
> 
> It's like an itch that I just have to scratch!

Because you can. And Forth encourages you to keep things simple. If you
did those projects in other languages you'd end up with a module you can
add on top. But in Forth you could redesign the Forth compiler with
those as central concepts, and the final result would probably be
simpler than Forth with extra stuff crusted on top. And you might get
something that was worth having, you might get a Forth that was simply
better. It's possible. Maybe some new concept that hasn't been put into
the kernel of the language would make things click better.

If all you want is to get your work done then you'll use what you have.
But Forth has evolved because people keep fiddling with it and finding
improvements. It's better than it was 30 years ago.
 
> I've been trying to learn standard forth as a programming language,
> rather than a system implementation, I really didn't want to write my
> own, at least not yet! But now I feel compelled to do so, in order to
> really understand the standard. I believe that one of the intensions
> of the standard was to definine an implementation independent
> language, but still, there seem to be a few areas that scream out to
> me 'implementation' rather than 'intension'.  

Yes, there are little rough edges that come from implementation tricks
that people were unwilling to lose. I think the most intrusive of them
come from Forth's 16-bit background. On a 16-bit system it makes sense
to do the arithmetic as much as possible so that unsigned results come
out the same as negative results. If you get the same bit-pattern, use
it either way! So for many purposes the range of numbers is not {-32768
... 32767} or {0 .. 65535} but instead {-32768 .. 65535}. That's worth a
little bit of extra effort.

On larger systems adding half a bit to the range is not valuable, but we
still have the old tools. It particularly affects DO LOOPs which are
designed so they'll work correctly and efficiently for any combination
of signed or unsigned inputs. 

> Forth isn't the only language where people will write their own
> implementations of course, it seems to be a fairly common experience
> with people learning lisp, and perhaps some other relatively pure
> languages. So I thought that maybe the fact that the essential forth
> model is small enough to be readily understood in one chunk might have
> something to do with it. But maybe there's another explanation: also,
> because the core concepts are so simple, the language doesn't get in
> your way when thinking about a problem. So naturally, when your
> thinking about the 'problem' of forth you come up with something like
> forth as a solution.

The language is simple enough, and simple enough to change, that you
don't think of it as a given you can't change. 

Usually you can redefine any word in the language just by making a new
definition with the old name. You can test out how the new version works
for your own code. And if it seems like a good thing, it isn't a
tremendous step to incorporate it into a Forth compiler. Some Forth
compilers are small and simple, smaller and simpler than many
applications. Not so hard to change.

And so Forth evolves. This is a good thing in the long run. But it
doesn't get your work done in the short run. It's easy to think that
Forth has more of that than we need. Maybe if other languages made that
easier, there wouldn't be so much of a pent-up need released when people
try Forth.

Jonah Thomas <jethomas5@gmail.com> wrote:
> Forth is designed to be simple. So people *can* make their own
> implementations and call it Forth. So some people will do that.

I would say Forth is designed to be *malleable*.  Simplicity is one
(critical) aspect which must be preserved in order to keep the thing
malleable.  Under specification is one way to preserve simplicity; what
you code can be the synthesis of what you need from a layer of
abstraction interacting with what's the best way to implement that
layer.

The base Forth system itself is just another layer, and to the extent it
has remained simple, it is malleable.  You can take one and change it,
or cook your own.  It is very powerful to be able to morph your system
all the way down to the bottom.  When needed.

Some people do so when it's not needed.  Some people do a bad job doing
it, even when it is needed.  I suspect that in a world of massive,
complex software systems, Forth is one of the last places where
top-to-bottom malleability is even a possibility.  So almost nobody has
any experience working with such possibilities, and thus we see a lot of
inept approaches.

I don't think we need to castigate such behavior.  The only way to do it
well is to try, and learn, and try again.  I would like to see more
simple, malleable software systems, and don't mind seeing people trying
their hand at it.

Regards,
Andy Valencia

On Fri, 1 May 2009 21:38:27 -0700 (PDT), ember@dyeforit.co.uk wrote:

>I came across this in the archives:
>
>	>The widely shared belief (among both Forthies
>	>and outsiders) that every "real" Forth programmer hacks together
>	>his own compiler/interpreter/programming environment also makes
>	>the Forth community look frivolous or at best naive. Most people
>	>who program for a living know that there are more useful ways to
>	>spend their time than building their own programming environment --
>	>the key to productivity is leveraging off other peoples' work.
>
>	HERESY in the Forth community!  Imagine... NOT coming up with
>	your own CASE statement or local variable implemetation?  Use
>	OTHER PEOPLES TOOLS?  Yuccch!
>
>	One thing you can count on in the Forth community... try
>	to establish a standard ANYTHING, and all that will happen
>	is others will come up with their own implementation, defeating
>	the purpose of standardization.
>
>Why is this?

The first part is just wrong. The response is just taking the mickey.
Both sound as if they are talking about 20 years ago.

Yes, there are lot of Forth systems out there. That's because writing
a simple Forth is a viable one-person project. Whether the result is
worthwhile except for self-education is another matter. You won't
learn very much from it unless you have already written several
substantial Forth applications. Forth is a very subtle language.

>It's like an itch that I just have to scratch!
....
>I'm not sure where I'm going with this, I guess I wish I could just
>stop at the 'forth is simple' bit!

Forth is conceptually very simple. Its implementation does not
have to be, but it has to preserve the presentation of Forth to
the user. You'll learn far more by contributing to a modern 
Forth and talking to people who have done it before.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
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.mpeforth.com - free VFX Forth downloads

On May 2, 1:56=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
> em...@dyeforit.co.uk wrote:
> > I came across this in the archives:
>
> > =A0 =A0>The widely shared belief (among both Forthies
> > =A0 =A0>and outsiders) that every "real" Forth programmer hacks togethe=
r
> > =A0 =A0>his own compiler/interpreter/programming environment also makes
> > =A0 =A0>the Forth community look frivolous or at best naive. Most peopl=
e
> > =A0 =A0>who program for a living know that there are more useful ways t=
o
> > =A0 =A0>spend their time than building their own programming environmen=
t --
> > =A0 =A0>the key to productivity is leveraging off other peoples' work.
>
> > =A0 =A0HERESY in the Forth community! =A0Imagine... NOT coming up with
> > =A0 =A0your own CASE statement or local variable implemetation? =A0Use
> > =A0 =A0OTHER PEOPLES TOOLS? =A0Yuccch!
>
> > =A0 =A0One thing you can count on in the Forth community... try
> > =A0 =A0to establish a standard ANYTHING, and all that will happen
> > =A0 =A0is others will come up with their own implementation, defeating
> > =A0 =A0the purpose of standardization.
>
> > Why is this?
>
> It isn't. =A0I don't know who wrote that, but the vast majority of Forth
> programmers are using existing systems to do serious programming. =A0Ther=
e
> are a number of popular Forth implementations, both open-source and
> commercial, all of which have many users.
>
> Indeed, some people are interested in doing their own implementations
> because (as Andrew says) it's easier in Forth than many languages, and
> some find it an intriguing intellectual exercise. =A0But most people who
> have real work to do start with the existing implementation closest to
> their application needs.
>
> And (also as Andrew says) most of the popular implementations do follow
> the ANSI/ISO Forth standard.
>
> People write a lot of silly things on Usenet groups.
>
> ...
>
>
>
>
>
>
>
> > Now with Forth, it seems like every step along the way makes me think
> > about writing my own implementation! A couple of months back I
> > designed (in outline) a prototype based OOPS for forth, and before I
> > could finish it I was planning how to write a forth in it! I =A0mean,
> > words are just objects, right? More recently I've been a little
> > obsessed with data flow models. After realising that a fully
> > paralisable pipes and streams architecture was a little bit overkill
> > to read a terminal input I discovered how nicely this approach maps to
> > forth using the stack as a data-flow channel, and then quite suddenly
> > I realised I'd reimplemented a crude forth interpreter.
>
> > It's like an itch that I just have to scratch!
>
> > I've been trying to learn standard forth as a programming language,
> > rather than a system implementation, I really didn't want to write my
> > own, at least not yet! But now I feel compelled to do so, in order to
> > really understand the standard. I believe that one of the intensions
> > of the standard was to definine an implementation independent
> > language, but still, there seem to be a few areas that scream out to
> > me 'implementation' rather than 'intension'. =A0At least, I hope, if I
> > do roll my own forth, these areas will be more clearly defined for me.
>
> I would strongly recommend that you write some applications in Forth
> before trying to design your own Forth. =A0There's a lot more there than
> meets the eye. =A0Would you attempt to design and build an automobile
> before learning to drive?
>
> There are books on Forth available (some of which I've written), that
> will be helpful in learning how to use Forth effectively. =A0Neither the
> Standard document nor "rolling your own" will teach you nearly as much
> as either the existing books or your experience as a user or (ideally) bo=
th.
>
> Cheers,
> Elizabeth
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> Elizabeth D. Rather =A0 (US & Canada) =A0 800-55-FORTH
> FORTH Inc. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +1 310.999.678=
4
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Hi
 I can't say that I've actually written my own
Forth but I've modified a number of different
Forths for one purpose or another. I strip some here
and add some there for the purpose in mind. Most
often I take a Forth that is a full disk based
and strip it down to a simple interpreter for some
embbeded application. Why I do this is because I
like to work in a consistant environment. I have no
problem moving from one Forth to another as major
steps but while using one, I like to stay with the
same thinking.
 I've put a CMForth on my PC and put a fpc forth
on an embedded box. It is because I can understand
it that I can do this.
 As I've said, I've never actually written one from
scratch, I've modified them often.
 I think the only thing I've inflicked on the world
was a partial Forth. It was a Forth cross compiler
for the ADSP2100. It had a bunch of optimizing features
in it that were confusing to many that looked at it.
I recall Dr Ting looking at it for a while before
he cleared his mind of it and wrote a eForth for
that processor.
 It served my purpose and made fast code and that
was all I wanted.
Dwight

Thank's for all your views. I must stress I didn't really take those
comments seriously, it kind of reminded me of the old joke about real
programmers coding in hex or something. But then I did spend more time
figuring out how to interpret the input myself than how to feed it
into the existing interpreter.

I did however find doing my own terminal input routine useful for
learning part of the linux system interface, probably more so than if
I'd written it in C, In fact I learned a bit about that as well! So
yes there is the forth part, but also the application domain that I'm
interested in.

I'll probably tinker about with it for a bit for fun, but I don't
expect to be inflicting it on the rest of the world!

So what do you think is a good application domain for forth on a
desktop system? I was thinking maybe device drivers, and also for
prototyping. I'd be interested in finding an open source system that
needs contributors. I'm not sure what I could do but I'd like to take
a look. Any ideas?

Regards,
Emma

On May 3, 2:27=A0am, em...@dyeforit.co.uk wrote:
> Thank's for all your views. I must stress I didn't really take those
> comments seriously, it kind of reminded me of the old joke about real
> programmers coding in hex or something. But then I did spend more time
> figuring out how to interpret the input myself than how to feed it
> into the existing interpreter.
>
> I did however find doing my own terminal input routine useful for
> learning part of the linux system interface, probably more so than if
> I'd written it in C, In fact I learned a bit about that as well! So
> yes there is the forth part, but also the application domain that I'm
> interested in.
>
> I'll probably tinker about with it for a bit for fun, but I don't
> expect to be inflicting it on the rest of the world!
>
> So what do you think is a good application domain for forth on a
> desktop system? I was thinking maybe device drivers, and also for
> prototyping. I'd be interested in finding an open source system that
> needs contributors. I'm not sure what I could do but I'd like to take
> a look. Any ideas?
>
> Regards,
> Emma

Prototyping is where Forth shines, and systems like gforth provide a
nice interface to investigate device drivers.  That's also where
Forth's loose their compatibility with each other, but if you are into
Linux, Unix, OSX or cygwin, you might find gforth is very useful.  I
know that I do. ;)

DaR

ember@dyeforit.co.uk writes:
>So what do you think is a good application domain for forth on a
>desktop system? I was thinking maybe device drivers,

Device drivers are normally in kernel space and usually are written in
the same language as the kernel.

>I'd be interested in finding an open source system that
>needs contributors. I'm not sure what I could do but I'd like to take
>a look. Any ideas?

Bug fixes and cleanups in Gforth?-)

Seriously though, just start programming with a system you like.  You
may then find a project you want to work on and contact the
maintainers of the system about it, or you can contact the maintainers
about projects they have on their ToDo list and see if any of them
interest you.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

vandys@vsta.org wrote:

> I would say Forth is designed to be *malleable*.  Simplicity is one
> (critical) aspect which must be preserved in order to keep the thing
> malleable.  Under specification is one way to preserve simplicity;
> what you code can be the synthesis of what you need from a layer of
> abstraction interacting with what's the best way to implement that
> layer.

Nicely said! Thank you.

On 3 May, 08:27, em...@dyeforit.co.uk wrote:
> So what do you think is a good application domain for forth on a
> desktop system? I was thinking maybe device drivers, and also for
> prototyping. I'd be interested in finding an open source system that
> needs contributors. I'm not sure what I could do but I'd like to take
> a look. Any ideas?

Device drivers , how boring. Don't you want to be a bit original ?
Device drivers won't increase the visibility of Forth. Since
you use Linux the obvious place to look for projects is
http://www.fsf.org/campaigns/priority.html but I'm not sure if
they accept contributions in Forth. Is it possible to write in
Forth libraries which can be called from C ?  If yes then you
could write some of the libraries needed entirely in Forth and
the rest of the project can link to your libraries.

How about a Linux remake of Fruity Frank ? This was one of my
favorite games on my old Amstrad CPC 464. Great little game, me
and a friend spent hours playing it. It would take work doing it
but it can definitely be handled by a single dedicated person.
The original game was written by 2 people in Z80 assembly, so
you'd have an advantage writing it in Forth. Here's what the
game looks like:
http://www.youtube.com/watch?v=9h4AtRILEa0

Otherwise how about a decent utility for reading info files ?
One which allows you to mark your position in the document,
allows you to search using regular expressions, remembers your
search history and saves it on termination, basically the
functionality less offers. If you can add some of the vim
functionality even better like for example remembering the jump
history, remembering marks between invocations etc. You would
have a lot of people's (including mine) gratitude if you were to
write something like this since the present info utility is
utter shite.

So there you have it, 3+ suggestions. You want to put Forth to
the test that's the stuff to go for, not device drivers.

On May 3, 12:27=A0am, em...@dyeforit.co.uk wrote:
>
> So what do you think is a good application domain for forth on a
> desktop system? I was thinking maybe device drivers, and also for
> prototyping. I'd be interested in finding an open source system that
> needs contributors. I'm not sure what I could do but I'd like to take
> a look. Any ideas?
>
> Regards,
> Emma

How about a Forth shell at the device driver level, for debugging
other device drivers?

If you are learning, you can try your hand implementing tasks on
Rosetta Code (http://www.rosettacode.org/).

Ian

Spiros Bousbouras wrote:
> Device drivers , how boring. Don't you want to be a bit original ?
> Device drivers won't increase the visibility of Forth. Since
> you use Linux the obvious place to look for projects is
> http://www.fsf.org/campaigns/priority.html but I'm not sure if
> they accept contributions in Forth.

Of course they do (gforth is a FSF project). If I look at the priority 
list: How can Forth increase visibility if it is part of one of those 
projects? E.g. their campaign for a free BIOS cries for Forth 
(OpenFirmware); won't help much, since all the user sees from a free 
BIOS is that it quickly boots. Or Gnash: Adobe's ActionScript 
interpreter apparently contains a part written in Forth (at least their 
free JavaScript engine, which is derived from this ActionScript engine, 
has one). You don't see the Forth when you play a Flash game or try hard 
to block an annoying Flash ad. Skype-replacement? Also invisible to the 
user.

The only point where I think you could make Forth visible to the user is 
the free video software editor. These editors have scriptable renderers 
(Kdenlive uses MLT). If you write such a renderer in Forth, adding your 
own scriptlets might be a good idea to expose Forth to the end-user.

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

Bernd Paysan wrote:
> Spiros Bousbouras wrote:
>> Device drivers , how boring. Don't you want to be a bit original ?
>> Device drivers won't increase the visibility of Forth. Since
>> you use Linux the obvious place to look for projects is
>> http://www.fsf.org/campaigns/priority.html but I'm not sure if
>> they accept contributions in Forth.
> 
> Of course they do (gforth is a FSF project). If I look at the priority 
> list: How can Forth increase visibility if it is part of one of those 
> projects? E.g. their campaign for a free BIOS cries for Forth 
> (OpenFirmware); won't help much, since all the user sees from a free 
> BIOS is that it quickly boots. Or Gnash: Adobe's ActionScript 
> interpreter apparently contains a part written in Forth (at least their 
> free JavaScript engine, which is derived from this ActionScript engine, 
> has one). You don't see the Forth when you play a Flash game or try hard 
> to block an annoying Flash ad. Skype-replacement? Also invisible to the 
> user.
> 
> The only point where I think you could make Forth visible to the user is 
> the free video software editor. These editors have scriptable renderers 
> (Kdenlive uses MLT). If you write such a renderer in Forth, adding your 
> own scriptlets might be a good idea to expose Forth to the end-user.
> 

The fact that Forth may not be visible to the end user doesn't 
necessarily imply that being able to point to aps written in Forth isn't 
helpful.  How many times has someone here challenged us to point to 
publicly available projects written in Forth?  The list of space 
projects that Jim Rash assembled a few years ago is helpful, and Stephen 
and I can point to some of our more prominent customers, but being able 
to list a string of FSF projects would also be very helpful.  It isn't, 
after all, end users that we need to convince: it's managers of software 
projects, project engineers, etc.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On 4 May, 21:53, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Spiros Bousbouras wrote:
> > Device drivers , how boring. Don't you want to be a bit original ?
> > Device drivers won't increase the visibility of Forth. Since
> > you use Linux the obvious place to look for projects is
> >http://www.fsf.org/campaigns/priority.htmlbut I'm not sure if
> > they accept contributions in Forth.
>
> Of course they do (gforth is a FSF project).

Yes, I know that. I was asking whether they accept Forth
contributions for the priority list I linked to above. And I
also asked whether it's possible on Linux to call from C a
library written in Forth. If there's no immediate way to do so
then it suggests another project: create some sort of framework
which makes it possible.

> If I look at the priority
> list: How can Forth increase visibility if it is part of one of those
> projects? E.g. their campaign for a free BIOS cries for Forth
> (OpenFirmware); won't help much, since all the user sees from a free
> BIOS is that it quickly boots. Or Gnash: Adobe's ActionScript
> interpreter apparently contains a part written in Forth (at least their
> free JavaScript engine, which is derived from this ActionScript engine,
> has one). You don't see the Forth when you play a Flash game or try hard
> to block an annoying Flash ad. Skype-replacement? Also invisible to the
> user.

I didn't make it clear what I mean by visibility. Let me give an
example: I'm typing this on a Linux computer. Obviously right
now a number of drivers are running. But I never had to install
those drivers, they came with the computer. So I have no idea
which they are or in what language they are written in. I
presume they are written in C but for all I know some of them
may be written in Forth. On the other hand whenever I install a
package I will pay attention to what language it is written in
because I am interested in this sort of thing. If I have to
compile it I will likely also have a look at the source.

So by Forth visibility I don't necessarily mean that the user
will directly interact with Forth but that the user will be aware
that "this cool programme I'm running right now is written in
Forth". If this user is also interested in computer programming
this might well make a difference.

> The only point where I think you could make Forth visible to the user is
> the free video software editor. These editors have scriptable renderers
> (Kdenlive uses MLT). If you write such a renderer in Forth, adding your
> own scriptlets might be a good idea to expose Forth to the end-user.

--
Shakespeare also predicted structured programming:
"Go to, go to, thou are a foolish fellow. Let me be clear of thee."
Twelfth Night, Act IV, Scene 1.

from http://www.iidb.org/vbb/showthread.php?p=3352214#post3352214

Anton Ertl wrote:
..
..
> That's an interesting comparison.  In the early days automobiles were
> so unreliable that one had to understand a lot about how they are
> built if you wanted to drive them (and lots of people did pay drivers
> instead of driving themselves).  They were also relatively simple so
> that one could repair them with common tools.  Nowadays cars contain
> lots of black boxes and repairing them often is a matter of replacing
> a black box.  Forth is probably more like early cars (except in
> reliability:-), as it allows access to the internals, whereas many
> other languages are more like modern cars in their black-box-like
> usage model.

Hey! The contrast is less than you think, because some cars went for
greater reliability from engineering trade offs too. Lesley
Hounsfield's Trojan car went for a split piston two stroke engine,  a
simple epicyclic gearbox a bit like the Ford model T's, chain drive,
no differential and solid tyres. It annoyes the mechanics because it
never needed expensive repairs, just cleaning around the spark plugs
and ports every so often. There was something of the same design
philosophy as with Forth, in a way. P.M.Lawrence

On 4 May, 22:17, Elizabeth D Rather <erat...@forth.com> wrote:
> Bernd Paysan wrote:
>
> > The only point where I think you could make Forth visible to the user is
> > the free video software editor. These editors have scriptable renderers
> > (Kdenlive uses MLT). If you write such a renderer in Forth, adding your
> > own scriptlets might be a good idea to expose Forth to the end-user.
>
> The fact that Forth may not be visible to the end user doesn't
> necessarily imply that being able to point to aps written in Forth isn't
> helpful.  How many times has someone here challenged us to point to
> publicly available projects written in Forth?  The list of space
> projects that Jim Rash assembled a few years ago is helpful, and Stephen
> and I can point to some of our more prominent customers, but being able
> to list a string of FSF projects would also be very helpful.  It isn't,
> after all, end users that we need to convince: it's managers of software
> projects, project engineers, etc.

Also those who are teenagers now and who in a few years may be
programmers. I hang out on Linux message boards occasionally.
Many users are teenagers and some of them are interested in
programming. So let's see how likely these future programmers
are to encounter Forth. A list of Debian-Lenny packages can be
found at http://packages.debian.org/stable/allpackages
(It will take a while for the full page to load) I did a search
for Forth on the list. Not very reliable because there's no
guarantee that the one line summary of each package will mention
the language the package is written in but for unusual languages
like Forth there is a good chance that it will. Here's the
result of my search:

gforth (0.6.2-7.3) GNU Forth Language Environment
pforth (21-11) portable Forth interpreter
yforth (0.1beta-20) A small freeware Forth environment in ANSI C

Not very inspiring and it's even less inspiring if you stop to
think that a user will not use a Forth compiler/interpreter
unless they are already interested in Forth.

On the other hand if you perform a similar search for Lisp which
is also a "fringe" language you get 203 matches. Here are some
highlights:

araneida (0.90.1-dfsg-6) A programmable web server written and
extended
                                     in Lisp
cl-binary-types (0.90b-3) Common Lisp package for reading and writing
binary
                                      files
cl-geodesics (20010214-9) [contrib] Geodesic equations in Common Lisp
cl-integrate (20021107.3-3) Common Lisp library for integrating
                                          differential equations
cl-reversi (1.0.14-2) Reversi game for Common Lisp
hunchentoot (0.15.7.dfsg.2-2) the Common Lisp web server formerly
known
                                             as TBNL
nethack-lisp (3.4.3-10.6) Text-based overhead view D&D-style adventure
                                     game
stumpwm (1:20080721-2) a Common Lisp window manager

So someone who just browses Linux repositories to see what's
available will see Lisp mentioned a lot more than Forth. Now I
wouldn't expect Forth to be able to compete in the number of
applications with much more popular languages like C or C++ or Java
but is Lisp so much more popular than Forth? Even if you exclude
emacs references from the Lisp list you still get 174 matches.

One might argue that the comparison is unfair and that there are
other websites where one will find a lot more Forth applications
than the 3 which appear on the Debian repositories. But one
would have to be first interested in Forth before searching for
those and the question is how to get people interested in Forth
to begin with. In any case, since those Forth applications exist
there's an even simpler route to increase Forth visibility:
instead of taking the time and effort to write Linux Forth
applications from scratch the creators of already publically
available applications might devote the much less time and
effort to create a Debian (or Ubuntu, or Red Hat) package and
put it onto the repositories.

So there you have it, a simple plan for Forth world domination
;-)

--
Nonsense is nonsense but the study of nonsense is scholarship.
Gershom Scholem

Spiros Bousbouras wrote:
> On 4 May, 22:17, Elizabeth D Rather <erat...@forth.com> wrote:
>> Bernd Paysan wrote:
>>
>>> The only point where I think you could make Forth visible to the user is
>>> the free video software editor. These editors have scriptable renderers
>>> (Kdenlive uses MLT). If you write such a renderer in Forth, adding your
>>> own scriptlets might be a good idea to expose Forth to the end-user.
>> The fact that Forth may not be visible to the end user doesn't
>> necessarily imply that being able to point to aps written in Forth isn't
>> helpful.  How many times has someone here challenged us to point to
>> publicly available projects written in Forth?  The list of space
>> projects that Jim Rash assembled a few years ago is helpful, and Stephen
>> and I can point to some of our more prominent customers, but being able
>> to list a string of FSF projects would also be very helpful.  It isn't,
>> after all, end users that we need to convince: it's managers of software
>> projects, project engineers, etc.
> 
> Also those who are teenagers now and who in a few years may be
> programmers. I hang out on Linux message boards occasionally.
> Many users are teenagers and some of them are interested in
> programming. So let's see how likely these future programmers
> are to encounter Forth. A list of Debian-Lenny packages can be
> found at http://packages.debian.org/stable/allpackages
> (It will take a while for the full page to load) I did a search
> for Forth on the list. Not very reliable because there's no
> guarantee that the one line summary of each package will mention
> the language the package is written in but for unusual languages
> like Forth there is a good chance that it will. Here's the
> result of my search:
> 
> gforth (0.6.2-7.3) GNU Forth Language Environment
> pforth (21-11) portable Forth interpreter
> yforth (0.1beta-20) A small freeware Forth environment in ANSI C
> 
> Not very inspiring and it's even less inspiring if you stop to
> think that a user will not use a Forth compiler/interpreter
> unless they are already interested in Forth.

....

> In any case, since those Forth applications exist
> there's an even simpler route to increase Forth visibility:
> instead of taking the time and effort to write Linux Forth
> applications from scratch the creators of already publically
> available applications might devote the much less time and
> effort to create a Debian (or Ubuntu, or Red Hat) package and
> put it onto the repositories.
> 
> So there you have it, a simple plan for Forth world domination
> ;-)

Yep, it's a golden opportunity for all those folks who want to write 
something in Forth but aren't sure what.  Pick a "wanted" project and do 
it.  Or, for those who already have it, post it.  Just be sure and do a 
good job, so as to improve Forth's reputation rather than confirming all 
those horror stories ;-)

Cheers,
Elzabeth


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On May 4, 6:25 pm, Ian Osgood <i...@quirkster.com> wrote:
> If you are learning, you can try your hand implementing tasks on
> Rosetta Code (http://www.rosettacode.org/).
>
> Ian

This is great! Really, just what I needed to stop focusing on forth
itself, I've started on one of these already!


On May 4, 4:41 am, Spiros Bousbouras <spi...@gmail.com> wrote:

> Otherwise how about a decent utility for reading info files ?
> One which allows you to mark your position in the document,
> allows you to search using regular expressions, remembers your
> search history and saves it on termination, basically the
> functionality less offers. If you can add some of the vim
> functionality even better like for example remembering the jump
> history, remembering marks between invocations etc. You would
> have a lot of people's (including mine) gratitude if you were to
> write something like this since the present info utility is
> utter shite.

This is a great idea! Also it fit's in perfectly with what I've been
doing with terminal i/o (ie figuring out how to do it). I'm going to
give this a go! don't expect miracles though! I hardly ever use the
info system - it's almost always quicker to find an html version that
I can use on the internet!


On May 3, 3:51 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
>
> Bug fixes and cleanups in Gforth?-)

:) Actually I've been meaning to have a good look into Gforth, I put
it off to begin with so I could focus on the basics. I don't know if
having a specific task to do would help in learning the system, but
I'd be happy to give it a go. My main idea was to write a few small
applications and see if I could port them to other forth systems to
get a grounding in the different systems. Maybe I'll do that and then
see what tasks you have available? I did manage to track down your bug
list on Savanna, but there is only 2 listed and I don't think I could
help with these kind of bugs as I don't have the systems they were
produced on. Do you have a project task list anywhere? or should I
just ask you when I think I'm up to it?


Regards
emma

On May 1, 9:38=A0pm, em...@dyeforit.co.uk wrote:
> I came across this in the archives:
>
> =A0 =A0 =A0 =A0 >The widely shared belief (among both Forthies
> =A0 =A0 =A0 =A0 >and outsiders) that every "real" Forth programmer hacks =
together
> =A0 =A0 =A0 =A0 >his own compiler/interpreter/programming environment als=
o makes
> =A0 =A0 =A0 =A0 >the Forth community look frivolous or at best naive.

That has to be a record number of insulting Forth myths in one
sentance.
Forthies?  Are they like trekies? 40 year old virgins without a job?
It is a suggestion that all Forth programmers are stupid hobbiests
when compared to professionals.

*real* Forth programmers here just means clueless newbie hobbiests
and is designed to simply exclude professionals and people who do
real work.

Hacks is a word with a strong negative connotation today basically
saying that all Forth programmers are criminals.

Hacks his own interpreter/compiler is true of many clueless newbie
hobbiests but tends to not reflect what professionals do.  Most
professionals use a professional Forth written by someone else.
From what I have seen the typical Forth system gets hundreds
or thousands of man years of use before it gets replaced by
a new Forth system.

Everyone knows that these clueless newbies define the stupid
"Forth community" according to c.l.f experts and that professional
programmers or programmers who do more than endlessly write their
own Forth systems do not represent the Forth community in c.l.f.

Everyone knows that the 'best' thing you can say about Forth
programmers, who everyone knows are all clueless newbies, is
that they are nieve.

Six insults to Forth programmers and six myths in one sentence
is above average trolling even for c.l.f.  Of course you can't
take much credit, all you did was dig up the most compact list
of absurd Forth insults and repeat it.

> =A0 =A0 =A0 =A0 >who program for a living

As apposed to the Forth community which is made up of clueless
newbie hobbiests who do not program for a living. ;-)

>         >know that there are more useful ways to
> =A0 =A0 =A0 =A0 >spend their time

Forth is a waste of time?

>         >than building their own programming environment --

That's all the Forth community does according to Forth haters.
They simply deny that most professionals use systems for many
years doing real work and get paid well to do it.  They like
to characterize Forth as just nieve embarrasing clueless
newbies. ;-)

> =A0 =A0 =A0 =A0 >the key to productivity is leveraging off other peoples'=
 work.

And that's why thousands of people use professional Forth to do
professional work and why the systems get promoted, sold, and reused.

> =A0 =A0 =A0 =A0 HERESY in the Forth community! =A0

HERESY is religious intolerance. Forth is not about religion,
charterizing Forth as religious in nature and not logicial is
the job of Forth haters who hate high quality or professional
Forth and so use the term 'Forth community' to mean clueless
newbie hobbiest non-professional idiots who waste their
time and stand in contrast to programmers who get paid
because they don't use Forth.

>Imagine... NOT coming up with
> =A0 =A0 =A0 =A0 your own CASE statement

Coming up with your own CASE statement is a perfect example
of how some people play at trying to move Forth towards C.

The reason why many Forth programmers don't 'come up' with
their own CASE implementation is that the use Forth that
already has a CASE statement or some other similar mechanism
for when they occasionally think it looks good.  The
reason why some Forth programmers don't 'come up' with
their own CASE statements is that their goal is not to
move their own Forth futher towards C.

It is hard to say whether you were quoting a generic
Forth hater who just repeats insulting myths about
Forth or whether you were quoting a Forth professional
who was joking about the behavior of clueless Forth
newbies.  In any event you have nice collection of
anti-Forth sound-bites designed to prevent any
understanding of Forth.

> or local variable implemetation? =A0Use

Locals are the same as CASE except even a bigger
step away from Forth towards C.  Are you complaining
that clueless newbies try to turn Forth into C or
are you denying that professional Forth programmers
even exist?

> =A0 =A0 =A0 =A0 OTHER PEOPLES TOOLS? =A0Yuccch!

Shouting that Forth programmers don't write apps,
just write dumb newbie Forth systems that try to
be more like C is fine.  It addresses what passes
for a 'Forth community' in c.l.f.

People here are often told that there is a much
bigger world that includes lots of professional
Forth programmers who think that the dialog of
the clueless newbies in c.l.f is a bad joke.

> =A0 =A0 =A0 =A0 One thing you can count on in the Forth community... try
> =A0 =A0 =A0 =A0 to establish a standard ANYTHING, and all that will happe=
n
> =A0 =A0 =A0 =A0 is others will come up with their own implementation, def=
eating
> =A0 =A0 =A0 =A0 the purpose of standardization.

Most Forth programmers I know follow standards.  Once in a decade
on in a hundred people try something outside of standard practice
and sometimes the innovation results in moving the art forward.
But it is too easy to complain about the clueless newbies
(c.l.f Forth community) who want to lead before they have a clue
as to where they are going.

> Why is this?

People who hate Forth repeat Forth myths.  They like to characterize
the Forth community as only clueless newbies hobbiests and they must
exclude what Forth professionals do so they just repeat myths that
might actually apply to some tiny fish in the tiny c.l.f pond.

In c.l.f the people who do the least Forth have the most time to
talk trash about Forth.  Because they don't have Forth apps or
even their own Forth systems like other clueless newbies the
best that they can do is complain that all other Forth programmers
are also clueless newbies.  That's why 'that' is.

> I mean, I'm usually quite happy to program in other languages without
> building my own interpreter or compiler.

You don't want to be a clueless newbie in Forth?  If it is a case
of being a professional .... programmer or a nieve clueless newbie
who does nothing productive in Forth for you?  There must be some
reason why doing Forth in a productive and professional manner
is not an option for you.

> For instance with Ruby, the
> only time I even considered it's implementation was when I was
> learning how it's class structure was organised, and that was only
> because some of my references talked about the internals.

Forth programmers are characterized rightly as wanting to understand.
Understanding is generally a good thing.  If you prefer to live only
at one level of abstraction and not have to be distracted by other
details that is fine.  If you prefer Ruby over Forth fine.  Why
troll a Forth newsgroup about Ruby?

> Now with Forth, it seems like every step along the way makes me think
> about writing my own implementation!

You must be at the clueless newbie stage or doing Forth or just
talking about people who do Forth as your hobby like many people in
c.l.f.


A couple of months back I
> designed (in outline) a prototype based OOPS for forth, and before I
> could finish it I was planning how to write a forth in it! I =A0mean,
> words are just objects, right? More recently I've been a little
> obsessed with data flow models. After realising that a fully
> paralisable pipes and streams architecture was a little bit overkill
> to read a terminal input I discovered how nicely this approach maps to
> forth using the stack as a data-flow channel, and then quite suddenly
> I realised I'd reimplemented a crude forth interpreter.
>
> It's like an itch that I just have to scratch!
>
> I've been trying to learn standard forth as a programming language,
> rather than a system implementation, I really didn't want to write my
> own, at least not yet! But now I feel compelled to do so, in order to
> really understand the standard. I believe that one of the intensions
> of the standard was to definine an implementation independent
> language, but still, there seem to be a few areas that scream out to
> me 'implementation' rather than 'intension'. =A0At least, I hope, if I
> do roll my own forth, these areas will be more clearly defined for me.
>
> Forth isn't the only language where people will write their own
> implementations of course, it seems to be a fairly common experience
> with people learning lisp, and perhaps some other relatively pure
> languages. So I thought that maybe the fact that the essential forth
> model is small enough to be readily understood in one chunk might have
> something to do with it. But maybe there's another explanation: also,
> because the core concepts are so simple, the language doesn't get in
> your way when thinking about a problem. So naturally, when your
> thinking about the 'problem' of forth you come up with something like
> forth as a solution.
>
> I'm not sure where I'm going with this, I guess I wish I could just
> stop at the 'forth is simple' bit! Anyway.
>
> Regards,
> Emma

Spiros Bousbouras <spibou@gmail.com> wrote:
> On 4 May, 21:53, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> > Spiros Bousbouras wrote:
> > > Device drivers , how boring. Don't you want to be a bit original ?
> > > Device drivers won't increase the visibility of Forth. Since
> > > you use Linux the obvious place to look for projects is
> > >http://www.fsf.org/campaigns/priority.htmlbut I'm not sure if
> > > they accept contributions in Forth.
> >
> > Of course they do (gforth is a FSF project).
> 
> Yes, I know that. I was asking whether they accept Forth
> contributions for the priority list I linked to above.

Except for the fact that they are listed there, the projects
are no more special than the other ones. And in general, certain
build requirements like dependance on another project are allowed.
So, if you mention e.g. Gforth as a requirement this should be o.k.

-- 
Marc

ember@dyeforit.co.uk writes:
>My main idea was to write a few small
>applications and see if I could port them to other forth systems to
>get a grounding in the different systems.

Sound like a good plan.

> I did manage to track down your bug
>list on Savanna, but there is only 2 listed and I don't think I could
>help with these kind of bugs as I don't have the systems they were
>produced on. Do you have a project task list anywhere? or should I
>just ask you when I think I'm up to it?

Another list of bugs (pretty old):

http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/BUGS?view=markup

Two todo lists: Relatively new, concrete, and low-level:

http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/Agenda?view=markup

Quite old (partially stale) and high-level:

http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/ToDo?view=markup

There are also a bunch of things that we have not written up.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Spiros Bousbouras <spibou@gmail.com> writes:
>So someone who just browses Linux repositories to see what's
>available will see Lisp mentioned a lot more than Forth. Now I
>wouldn't expect Forth to be able to compete in the number of
>applications with much more popular languages like C or C++ or Java
>but is Lisp so much more popular than Forth?

According to my measurements
<http://www.complang.tuwien.ac.at/anton/comp.lang-statistics/> Lisp is
quite a bit more popular than Forth.  Also, the environment may have
an influence; on small embedded systems the usage numbers may be
reversed.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Spiros Bousbouras schrieb:
> So by Forth visibility I don't necessarily mean that the user
> will directly interact with Forth but that the user will be aware
> that "this cool programme I'm running right now is written in
> Forth". If this user is also interested in computer programming
> this might well make a difference.

IMO this is a strange idea. Noone but a narrow-minded brush manufacturer 
would evaluate the quality of an oil painting by the tool it was painted 
with.

To be less elliptic: take Scilab. A famous "cool" piece of software. 
Scilab is programmed in a number of different languages, Fortran among 
them. Noone would deduce a better Fortran "visibility" from the success 
of Scilab.

On Fri, 1 May 2009 21:38:27 -0700 (PDT), ember@dyeforit.co.uk wrote:

>I came across this in the archives:
....
>Why is this?
....

Wow. You've been flamed by Jeff Fox without even responding to him!

I suggest that you ignore him. Please do not feel that he
represents anyone else other than himself. Most of us
silently feel ashamed when he behaves like that.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
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.mpeforth.com - free VFX Forth downloads

On May 5, 5:10=A0pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> I suggest that you ignore him. Please do not feel that he
> represents anyone else other than himself. Most of us
> silently feel ashamed when he behaves like that.

Apparently not as silent as we are when you say that it
is "easier and more profitable" to tell people what they
want to hear about a product than it is to be honest about
Forth and tell them what you know actually works best. I am
sure many people feel ashamed when they see you behave like
that but realize that it is just business as usual. They
know that they only have control over whether they perfer
to be honest or to do what is easier and more profitable
for some others when they discuss Forth.

Best Wishes

On 5 May, 22:24, Andreas <a...@nospam.org> wrote:
> Spiros Bousbouras schrieb:
>
> > So by Forth visibility I don't necessarily mean that the user
> > will directly interact with Forth but that the user will be aware
> > that "this cool programme I'm running right now is written in
> > Forth". If this user is also interested in computer programming
> > this might well make a difference.
>
> IMO this is a strange idea. Noone but a narrow-minded brush manufacturer
> would evaluate the quality of an oil painting by the tool it was painted
> with.

I'm not sure I understand your analogy. Is it supposed to be
that
   brush        == programming language
   oil painting == application
? If I got it right then it's more to the point to ask whether
it takes a good brush to produce a good oil painting. IANAP but
I assume it does so if you see a good painting you consider it
likely that it was made with a good brush. If you see a good
application you consider it likely that the language it was
written in is good.

> To be less elliptic: take Scilab. A famous "cool" piece of software.
> Scilab is programmed in a number of different languages, Fortran among
> them. Noone would deduce a better Fortran "visibility" from the success
> of Scilab.

Fortran is already so well known to those interested in
numerical computing that I doubt that any single application
would make a difference. On the other hand if Scilab was written
in Forth I would think it would make Forth more well known to
those interested in desktop programming.

--
Look, is your particular psychosis named after you or your doctor?
  Erik Naggum

On 5 May, 09:23, em...@dyeforit.co.uk wrote:
> On May 4, 4:41 am, Spiros Bousbouras <spi...@gmail.com> wrote:
>
> > Otherwise how about a decent utility for reading info files ?
> > One which allows you to mark your position in the document,
> > allows you to search using regular expressions, remembers your
> > search history and saves it on termination, basically the
> > functionality less offers. If you can add some of the vim
> > functionality even better like for example remembering the jump
> > history, remembering marks between invocations etc. You would
> > have a lot of people's (including mine) gratitude if you were to
> > write something like this since the present info utility is
> > utter shite.
>
> This is a great idea! Also it fit's in perfectly with what I've been
> doing with terminal i/o (ie figuring out how to do it). I'm going to
> give this a go! don't expect miracles though! I hardly ever use the
> info system - it's almost always quicker to find an html version that
> I can use on the internet!

I hardly use info myself since I find it so frustrating. Using
an html document offers you better navigability than info but I
still find it severely lacking compared to what less or vim
offer. Again the problem is that if you are reading a long page
which occupies several screenfuls a web browser does not offer
you a way to mark your place on the page so that you can get
back to it quickly. Or at least I've never encountered one which
does.  So you have to memorise the approximate position on the
scrollbar and later on middle-click on that position to arrive
at that approximate place and scroll up and down until you find
the precise point you want. A right PITA.

Regarding terminal I/O I don't know how sophisticated your own
library is but if you find it's not up to par and want to save
time you can always use curses which was written for this task.

Good luck and may the Forth be with you ;-)

--
God grant me serenity to accept the code I cannot change, courage
to change the code I can and wisdom to know the difference.
Erik Naggum

Spiros Bousbouras <spibou@gmail.com> writes:
>I hardly use info myself since I find it so frustrating. Using
>an html document offers you better navigability than info but I
>still find it severely lacking compared to what less or vim
>offer. Again the problem is that if you are reading a long page
>which occupies several screenfuls a web browser does not offer
>you a way to mark your place on the page so that you can get
>back to it quickly. Or at least I've never encountered one which
>does.  So you have to memorise the approximate position on the
>scrollbar and later on middle-click on that position to arrive
>at that approximate place and scroll up and down until you find
>the precise point you want. A right PITA.

With Emacs info mode if you follow a link and then go back (with <l>)
the cursor is right at the link point.  Concerning HTML,
terminal-based web brosers work in the same way.  And even for GUI web
browsers (which don't have a cursor in read-only text), if I follow a
link and then go back, the page is normally in the same position it
was in originally (unless I changed the window size in the meantime);
at least that's my experience with the browsers I have used (lately
mostly Mozilla).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

On 7 May, 18:00, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> Spiros Bousbouras <spi...@gmail.com> writes:
> >I hardly use info myself since I find it so frustrating. Using
> >an html document offers you better navigability than info but I
> >still find it severely lacking compared to what less or vim
> >offer. Again the problem is that if you are reading a long page
> >which occupies several screenfuls a web browser does not offer
> >you a way to mark your place on the page so that you can get
> >back to it quickly. Or at least I've never encountered one which
> >does.  So you have to memorise the approximate position on the
> >scrollbar and later on middle-click on that position to arrive
> >at that approximate place and scroll up and down until you find
> >the precise point you want. A right PITA.
>
> With Emacs info mode if you follow a link and then go back (with <l>)
> the cursor is right at the link point.  Concerning HTML,
> terminal-based web brosers work in the same way.  And even for GUI web
> browsers (which don't have a cursor in read-only text), if I follow a
> link and then go back, the page is normally in the same position it
> was in originally (unless I changed the window size in the meantime);
> at least that's my experience with the browsers I have used (lately
> mostly Mozilla).

But I wasn't talking about links, I was talking about reading
one long page which may or may not have links. If I find a
point in the page I want to refer to quickly then with less or
vim I press m followed by any letter which makes the letter a
mark for that particular point. For example mb makes b a mark
for that point in the page. Then when I want to return to that
point quickly I will do 'b and I'm right where I want. That's
one functionality I'm missing with info but I have with man
pages which I read with less.

Note that even when following links is involved, which is the
case with info pages, a similar facility would be useful.  Say I
follow links which take me from page1 to page2 to page3 to
page4. If I want to return to page1 I have to click on the back
arrow 3 times. What I want instead is to be able to mark my
position when I am in page1 and with a couple of key presses
return to the point in the page where I placed the mark. It may
be that that point is not the place where the link to page2
exists but some other point which I find especially relevant.

--
I guess I should warn you , if I turn out to be particularly clear,
you've probably misunderstood what I've said.

From a 1988 speech at the Economic Club of New York by Alan
Greenspan, Chairman of the Federal Reserve.

On May 7, 11:12=A0am, Spiros Bousbouras <spi...@gmail.com> wrote:
> I'm not sure I understand your analogy. Is it supposed to be
> that
> =A0 =A0brush =A0 =A0 =A0 =A0=3D=3D programming language
> =A0 =A0oil painting =3D=3D application
> ? If I got it right then it's more to the point to ask whether
> it takes a good brush to produce a good oil painting. IANAP but
> I assume it does so if you see a good painting you consider it
> likely that it was made with a good brush. If you see a good
> application you consider it likely that the language it was
> written in is good.

In the same building I work in is an art studio.  The artist produces
beautiful and intriguing paintings using good brushes, bad brushes,
the side of his hand, rolled-up paper towels, spoons, fallen branches,
an old t-shirt, the tube that the paint came in, a shoelace, and
recently through happy accident, a student tripping and smearing some
of the paint in a peculiar way.

When I look at a good oil painting, it is the skill, creativity,
insight, and intuition of the artist that created it.  A "good brush"
is not going to turn a bad artist into a good one, or take a generic
painting turn into a great one.  Good tools do matter, but a tool is
an extension of the artist.  A "good brush" does not jump up into the
air, dip itself into paint, fly to the canvas, and create a
masterpiece.

When I see a good application, the programming language is often near
the bottom of the list of things that made it good.  A good
application comes about from good design and good execution.  In
short, it comes from *people* and their skills.  You don't take poor
design, sprinkle Forth on it, and presto get out a good application.

Early in my career, my focus was on programming.  To me, that was
where the interesting work was at.  Now, 20-whatever years later, when
I hear about a successful application, the programming language used
is mostly an interesting footnote.  Now I find myself asking questions
like how many programmers were involved?  How were they organized?
What methodology did the project managers use?  Did they use any
interesting design patterns?  How did they implement unit and
integration testing?  These are the kinds of questions I find myself
asking now because I find them far more interesting and relevant to me
than what programming language was used.

Spiros Bousbouras <spibou@gmail.com> writes:
>But I wasn't talking about links, I was talking about reading
>one long page which may or may not have links. If I find a
>point in the page I want to refer to quickly then with less or
>vim I press m followed by any letter which makes the letter a
>mark for that particular point. For example mb makes b a mark
>for that point in the page. Then when I want to return to that
>point quickly I will do 'b and I'm right where I want. That's
>one functionality I'm missing with info but I have with man
>pages which I read with less.

Since Emacs has everything, it also has bookmarks, which have that
functionality (and you can use it when reading info with Emacs):

http://www.gnu.org/software/emacs/manual/html_node/emacs/Bookmarks.html

They can even persist from one session to the next.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

On 7 May, 19:57, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> Spiros Bousbouras <spi...@gmail.com> writes:
> >But I wasn't talking about links, I was talking about reading
> >one long page which may or may not have links. If I find a
> >point in the page I want to refer to quickly then with less or
> >vim I press m followed by any letter which makes the letter a
> >mark for that particular point. For example mb makes b a mark
> >for that point in the page. Then when I want to return to that
> >point quickly I will do 'b and I'm right where I want. That's
> >one functionality I'm missing with info but I have with man
> >pages which I read with less.
>
> Since Emacs has everything, it also has bookmarks, which have that
> functionality (and you can use it when reading info with Emacs):
>
> http://www.gnu.org/software/emacs/manual/html_node/emacs/Bookmarks.html
>
> They can even persist from one session to the next.

I was assuming that much but learning Emacs is a serious undertaking
which I'm not prepared to handle at this point in my life. Some day
perhaps but at present I'm hoping that someone will write an
info reader with decent functionality. Apart from that, in typical
Emacs
fashion you have to press a long sequence of keys to achieve the
desired functionality. Counting Ctrl, you must press 6 keys to set a
bookmark and as many to jump to one. I much rather have only 2
key presses.

--
The summary in a previous comment says it best: "I don't think I
could provide spoilers if I wanted to".  I could tell you everything
that happens in Videodrome, and it still will not even slightly
prepare you for the utter bizarreness to be beheld.
      http://www.imdb.com/title/tt0086541/usercomments

John Passaniti <john.passaniti@gmail.com> wrote:
> Spiros Bousbouras <spi...@gmail.com> wrote:

> > ? If I got it right then it's more to the point to ask whether
> > it takes a good brush to produce a good oil painting. IANAP but
> > I assume it does so if you see a good painting you consider it
> > likely that it was made with a good brush. If you see a good
> > application you consider it likely that the language it was
> > written in is good.
> 
> In the same building I work in is an art studio.  The artist produces
> beautiful and intriguing paintings using good brushes, bad brushes,
> the side of his hand, rolled-up paper towels, spoons, fallen branches,
> an old t-shirt, the tube that the paint came in, a shoelace, and
> recently through happy accident, a student tripping and smearing some
> of the paint in a peculiar way.
> 
> When I look at a good oil painting, it is the skill, creativity,
> insight, and intuition of the artist that created it.  A "good brush"
> is not going to turn a bad artist into a good one, or take a generic
> painting turn into a great one.  Good tools do matter, but a tool is
> an extension of the artist.  A "good brush" does not jump up into the
> air, dip itself into paint, fly to the canvas, and create a
> masterpiece.

So good tools do matter, but the tool still is only a tool. 

Poor tools can hinder your work. But good tools can't make up for a lack
of skill. Except when they do. 

It's good to have powerful tools, and tools that are easy to use. But
ease of use has different parts. There's easy-to-use for beginners, and
easy-to-use for experts. When you need to get a lot of beginners up to
speed quickly, then it matters how fast beginners can get productive.
But when you already have a lot of experienced people then it matters
how much boilerplate and workarounds etc they have to do.

I once read about norwegian archeologists who looked at an old-style
plow -- simple -- and the plow that replaced it -- heavier and more
complex -- and they actually tried to use both types in
somewhat-controlled studies. And they found that the older simpler plow
was just as productive once they learned how to use it, but the newer
design was easier to learn. A 5 minute google search didn't turn up a
reference to the paper, and I may have misremembered it. But clearly
ease-of-learning is important for tools.

In principle any turing-complete language can produce any computation
that any other turing-complete language will, right? But in practice you
care about how easily it works, and how well the language discourages
bugs etc. In principle bug-free code can be produced with any language,
given bug-free specifications, yes? But some languages make that harder
than others.

So, a truly versatile artist can make his tools from whatever is
available, if necessary. Make small paintbrushes from shoestrings, get
colors from egg yolks, oxidise iron or copper wire, etc. A versatile
artist can adapt to poor tools and still get results. Still, the tools
do matter.

Jonah Thomas wrote:
> So, a truly versatile artist can make his tools from whatever is
> available, if necessary. Make small paintbrushes from shoestrings, get
> colors from egg yolks, oxidise iron or copper wire, etc. A versatile
> artist can adapt to poor tools and still get results. Still, the tools
> do matter.

A versatile artist doesn't adapt to poor tools, he creates his tools 
himself, if necessary.

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

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Jonah Thomas wrote:

> > So, a truly versatile artist can make his tools from whatever is
> > available, if necessary. Make small paintbrushes from shoestrings,
> > get colors from egg yolks, oxidise iron or copper wire, etc. A
> > versatile artist can adapt to poor tools and still get results.
> > Still, the tools do matter.
> 
> A versatile artist doesn't adapt to poor tools, he creates his tools 
> himself, if necessary.
 
And the constraints may leave him only able to create poor tools that he
uses to their best effect. It depends. You can be versatile on different
levels.

Once I was in a cave that ended at a clay plug. There was air pouring
out of the top of the plugged area, it was obvious that there was more
cave beyond it, but there was only a tiny crawlway through there that
after about 20 feet got just too tight. I wanted to get through, so I
went back with a garden trowel. I took off my hardhat and pack and
crawled to the tight spot and started digging. I could dig with the arm
in front, and then pass lumps of clay down to the arm in back, where
sometimes I could press it into pockets along the side or sometimes just
toss it a little farther. When I was almost buried I'd back out, pushing
dirt out with me. In a few hours I got two body lengths farther into the
crawlway.

Then I brought back some other people to help including one archeologist
who knew about digging. He had a garden hoe with the handle cut down to
four feet and a nylon loop attached to the end, and he had an ammo can
with a long piece of webbing attached, and a big piece of canvas on
another long webbing. He said the first thing was to prepare the site.
So he had two people use the hoe and a shovel to dig out the entrance to
the crawlway. They turned it into stairsteps, so you didn't have to
climb five feet up before you could get into the crawlway. You could
practically walk up. Meanwhile somebody else dug at the first narrow
spot and piled the dirt onto the canvas. When he was ready he came out
and just dragged the canvas with the whole pile of dirt right out after
him. And somebody else dug at the second tight spot, and filled the ammo
can. When it was full he tugged on the rope and somebody dragged it out
and emptied it. Nobody had to dig with one hand in a spot where they
couldn't take a deep breath. In a fairly short time we had the stairway
back five feet, a three-foot-high section that went ten feet, and a
crawlway with no really tight spots that extended an extra thirty feet,
all in reasonable comfort.

There was the disadvntage that if we ever broke through it would be easy
for anybody to follow us. 

I was impressed. Bring powerful tools. Prepare the site. Put a lot of
your effort into making the job easier.

Jonah Thomas wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> A versatile artist doesn't adapt to poor tools, he creates his tools
>> himself, if necessary.
[...]
> I was impressed. Bring powerful tools. Prepare the site. Put a lot of
> your effort into making the job easier.

I forgot to say, that a versatile artist of course also selects his tools 
himself - powerful tools - and knows how to use the tools. That's why only 
bad artists complain about the tools (unless, of course, you disallow the 
good artist to select his tools or bring his toolbox in).

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

Bernd Paysan wrote:
> Jonah Thomas wrote:
>> So, a truly versatile artist can make his tools from whatever is
>> available, if necessary. Make small paintbrushes from shoestrings, get
>> colors from egg yolks, oxidise iron or copper wire, etc. A versatile
>> artist can adapt to poor tools and still get results. Still, the tools
>> do matter.
> 
> A versatile artist doesn't adapt to poor tools, he creates his tools 
> himself, if necessary.

Sometimes true, but there are exceptions. Beginners need the best tools, 
but an experienced practitioner can do fine work with very little. I 
have built circuits with a soldering iron heated by a Bunsen burner, but 
a beginner needs a temperature-controlled iron to avoid discouragement.

As a bellhop at a summer resort hotel, I was given a room in the 
basement -- a nice room, but the door was too big for the jamb and 
couldn't be completely closed, let alone locked. I rehung the door using 
the only tool I had, a pocket utility knife. I would have preferred a 
saw, plane, chisel (for the mortise lock) and screw driver, but I was 
able to make do. Programming is much the same.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:

> Bernd Paysan wrote:
>> A versatile artist doesn't adapt to poor tools, he creates his tools
>> himself, if necessary.
> 
> Sometimes true, but there are exceptions. Beginners need the best tools,
> but an experienced practitioner can do fine work with very little. I
> have built circuits with a soldering iron heated by a Bunsen burner, but
> a beginner needs a temperature-controlled iron to avoid discouragement.

A beginner is not a "versatile artist". Beginners need good tools, but they 
won't make them themselves (maybe the most easy tools to learn - blacksmiths 
usually start with creating a hammer and tongs, but the anvil is never done 
by beginners). I did my first soldering with a not very good soldering iron, 
but it was an all 1/10" pitch through hole board. For 0.5mm pitch SMD 
soldering, I much prefer a better soldering iron, though some SMD mounted 
ICs simply need a large enough ball of tin-solder rolling over all those 
little pins, and you're done.

> As a bellhop at a summer resort hotel, I was given a room in the
> basement -- a nice room, but the door was too big for the jamb and
> couldn't be completely closed, let alone locked. I rehung the door using
> the only tool I had, a pocket utility knife. I would have preferred a
> saw, plane, chisel (for the mortise lock) and screw driver, but I was
> able to make do. Programming is much the same.

Well, maybe. I prefer to take my toolbox with me, at least when programming.

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

Bernd Paysan wrote:
> Jerry Avins wrote:
> 
>> Bernd Paysan wrote:
>>> A versatile artist doesn't adapt to poor tools, he creates his tools
>>> himself, if necessary.
>> Sometimes true, but there are exceptions. Beginners need the best tools,
>> but an experienced practitioner can do fine work with very little. I
>> have built circuits with a soldering iron heated by a Bunsen burner, but
>> a beginner needs a temperature-controlled iron to avoid discouragement.
> 
> A beginner is not a "versatile artist". Beginners need good tools, but they 
> won't make them themselves (maybe the most easy tools to learn - blacksmiths 
> usually start with creating a hammer and tongs, but the anvil is never done 
> by beginners). I did my first soldering with a not very good soldering iron, 
> but it was an all 1/10" pitch through hole board. For 0.5mm pitch SMD 
> soldering, I much prefer a better soldering iron, though some SMD mounted 
> ICs simply need a large enough ball of tin-solder rolling over all those 
> little pins, and you're done.
> 
>> As a bellhop at a summer resort hotel, I was given a room in the
>> basement -- a nice room, but the door was too big for the jamb and
>> couldn't be completely closed, let alone locked. I rehung the door using
>> the only tool I had, a pocket utility knife. I would have preferred a
>> saw, plane, chisel (for the mortise lock) and screw driver, but I was
>> able to make do. Programming is much the same.
> 
> Well, maybe. I prefer to take my toolbox with me, at least when programming.

If course. Sometimes it's not available.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On May 8, 12:27=A0am, Jonah Thomas <jethom...@gmail.com> wrote:
> So good tools do matter, but the tool still is only a tool.
>
> Poor tools can hinder your work. But good tools can't make up for a lack
> of skill. Except when they do.

The point of this extended analogy is to return focus on the software
developer as being fundamentally responsible for the success (or
failure) of a project, not the language.  comp.lang.forth has a long
history of tedious unsupported anecdotes about how project X written
in language Y was floundering, until (usually) a different group of
developers using Forth swooped in and saved the day.  The implication
of these accounts is clear (and is part of the marketing of commercial
Forth vendors)-- Forth is the reason.

A couple employers ago, I was on a team that took over a project that
was failing.  We completed the project before the deadline and under
budget.  The client was very happy with our work and the project was
considered a fabulous success.  At the end of the project, we did our
usual post-mortem analysis and asked ourselves why we succeeded when
the original developers failed.  Was it because were were smarter or
more skilled?  Nope.  Was it the choice of our tools and programming
language?  Nope.  Was it because we had some keen insight into the
problem domain?  Nope.

When we critically looked at it, we determined there were three
reasons we succeeded when the original group failed:

1)  We insisted on building a clear set of requirements, use cases,
and tests.  The original group didn't, so instead of focusing on real
needs, they were just blindly reacting to whatever was in front of
them at the time.  Our taking the time up front to do this make sure
that everyone understood what was being built, so we didn't waste time
going off on a "extended jazz odyssey" because someone thought adding
feature X would be cool.

2)  The original group didn't take the time to come up with a design.
They were just chaotically slapping code together and finding that in
integration, things were failing.  We came up with design, a clear
system metaphor, and we all worked against that.

3)  We had a great project manager who didn't get in the way.  He
tracked progress, identified impediments, and worked independently to
synchronize everyone's needs.  The original group's project manager
basically sat in his office and shouted at the developers how many
days until the next milestone with no real management of the project.

So what saved the day?  It was people, processes, and methodologies.
It wasn't language.  And I'll bet that EACH AND EVERY TIME someone
dares to take a deeper critical look at "Forth saved the day"
anecdotes, they will find the exact same thing.

> So, a truly versatile artist can make his tools from whatever is
> available, if necessary. Make small paintbrushes from shoestrings, get
> colors from egg yolks, oxidise iron or copper wire, etc. A versatile
> artist can adapt to poor tools and still get results. Still, the tools
> do matter.

I fully agree that tools do matter.  It doesn't take a lot of insight
to see that an interactive language like Forth offers a much more
efficient way of working than batch-compiled languages.  It doesn't
take years of experience to understand how being able to create words
on the fly and easily test them would make one more efficient.  It
doesn't require a lot of discussion to work through why building
applications on top of simple and extensible language is a good
thing.  And yes, it isn't hard to believe that the language may
promote a mindset that leads to smaller, faster, simpler systems.

But when you step backward and look dispassionately at the totality of
a successful project, I remain unconvinced that language plays as much
of a role as people, processes, and methodologies.  A role?  Yes.  As
much?  Nope.

In article <71e9aa83-a3bc-46b0-8df9-778b9cf03c81@o30g2000vbc.googlegroups.com>,
Spiros Bousbouras  <spibou@gmail.com> wrote:
>On 3 May, 08:27, em...@dyeforit.co.uk wrote:
>> So what do you think is a good application domain for forth on a
>> desktop system? I was thinking maybe device drivers, and also for
>> prototyping. I'd be interested in finding an open source system that
>> needs contributors. I'm not sure what I could do but I'd like to take
>> a look. Any ideas?
>
>Device drivers , how boring. Don't you want to be a bit original ?
>Device drivers won't increase the visibility of Forth. Since

I beg to differ. I think that there is room for spectacular
improvement of Midi, scanning, image processing, image/character
recognition devices in Linux.
The point is not to do the obvious thing: implementing devices
according to existing interfaces. Instead new devices specifications
must be invented that require a lot of experimenting. I'm quite sure
w.r.t. experimenting Forth will turn out to be superior.

>you use Linux the obvious place to look for projects is
>http://www.fsf.org/campaigns/priority.html but I'm not sure if
>they accept contributions in Forth. Is it possible to write in
>Forth libraries which can be called from C ?  If yes then you
>could write some of the libraries needed entirely in Forth and
>the rest of the project can link to your libraries.

I'm sure a linked library can be written in Forth, as an ELF
library can be written in Forth. But much information is terrible
C-oriented. E.g. it is not uncommon to find a data-type used in
an ELF specification, where the actual size is only defined in
a c-include file, and where this include-file's name and place can
only be found via a canonically installed system development
compiler.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On May 4, 1:25=A0pm, Ian Osgood <i...@quirkster.com> wrote:
> On May 3, 12:27=A0am, em...@dyeforit.co.uk wrote:
>
>
>
> > So what do you think is a good application domain for forth on a
> > desktop system? I was thinking maybe device drivers, and also for
> > prototyping. I'd be interested in finding an open source system that
> > needs contributors. I'm not sure what I could do but I'd like to take
> > a look. Any ideas?
>
> If you are learning, you can try your hand implementing tasks on
> Rosetta Code (http://www.rosettacode.org/).

Specifically, these two pages ought to be of interest:
http://rosettacode.org/wiki/Category:Programming_Tasks
http://rosettacode.org/wiki/Tasks_not_implemented_in_Forth

Mike

Bernd Paysan wrote:
..
..
..
> A beginner is not a "versatile artist". Beginners need good tools, but they
> won't make them themselves (maybe the most easy tools to learn - blacksmiths
> usually start with creating a hammer and tongs, but the anvil is never done
> by beginners).

It's curious that you should mention that. In "The Isles of Unwisdom",
Robert Graves describes a superstition held by mediaeval blacksmiths.
It turned out that they could improvise almost any tools they needed
for making other tools, but making tongs required the use of tongs.
The blacksmiths realised the bootstrapping problem, so they thought
that God must have given the first pair of tongs to Tubal Cain, the
first blacksmith. P.M.Lawrence.

Spiros Bousbouras <spibou@gmail.com> writes:
>I was assuming that much but learning Emacs is a serious undertaking
>which I'm not prepared to handle at this point in my life.

There is no such thing as "learning Emacs".  E.g., I did not know
about bookmarks before this discussion, because I never looked for
them.  So you work with Emacs and learn what you need when you miss
something.

How long does it take you to come up to speed with Emacs?  It took me
less than a day, but if you want to learn the equivalent stuff for all
the vim features you are using, it will probably take you longer.

> Apart from that, in typical
>Emacs
>fashion you have to press a long sequence of keys to achieve the
>desired functionality. Counting Ctrl, you must press 6 keys to set a
>bookmark and as many to jump to one. I much rather have only 2
>key presses.

Of course you are free to define your own key presses.  In particular
in Info mode there are a number of single keys that are not mapped and
that you could use for, e.g., bookmarks.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/