Forth Reusability Flames

Forth has a very different unit of reuse than most other languages: source code.

Other languages that emphasize reuse of source code rather than compiled object files: Perl, Python, Smalltalk

Forth tends to either see the whole world as under its entire control, or lives on an island within the real world, on which it conceals itself from the outside.

In the first case, Forth controls everything, so there's no need to define anything that would be out of its direct control: source code sharing is then deemed good enough. Toasters and embedded systems in general fall in this category.

Source code sharing is only "good enough"? In what way is source code sharing inferior to having only compiled binaries to "share"?

Because as soon as you do provide source code you just gave yourself an excuse - for not finishing the product -- the user will extend it anyway - not debugging it -- the user has the source, he can do whatever he fancies - not spend time designing -- the user can rearchitect all what he wants

If you were providing a binary interface only, then you would need to spend time defining and testing things

So a brittle, unchangeable, platform-specific interface is better than a portable one that can evolve to better serve the user's needs? And spending time defining binary interfaces is better than spending time writing useful code? And a hidden implementation is better than one the user can inspect and modify? And since when does availability of source remove the need for debugging and testing?

You might want to check into this thing called ExtremeProgramming. I think there are one or two pages about it on the wiki. Unchangeable interfaces are considered to be bad, and looking at source code and changing it when necessary is considered to be good.

In the second case, as advocated by ChuckMoore, why trust some moron written binary when you should have access to the source code in the first place?

This and that leads to the sad truth that there's no such thing as a "foreign interface" system in Forth (even though many adhoc counter-examples abound). Forth mantra #2 is thus "Have source code, will reimplement".

Exactly what do you mean by this? Most Forths are perfectly capable of interfacing with operating systems, libraries, or whatever else is needed. Sure, there is no "standard foreign interface", but neither is there for most other languages.

Again, what "C, Perl or Python" doesn't have is no excuse for not providing it if it turns out to be needed. Because of Forth stance on the universe, "Me, Forth, I am in control", it is very unusual to either call a DLL or have a Forth DLL that just implements the bits you need to be called from some other language.

Other languages don't have it either, but that doesn't matter--Forth is still bad!

 Like "C".

 ;-) ;-) ;-)

If you can point me to the section of the C language standard that defines the foreign interface, I'll concede your point. I don't think it exists. The fact that C implementations and other languages work together is due to implementors creating their own binary interface standards. Forth implementors have joined in on this as well.

 Or, for that matter, any language for which an OMG defined CORBA IDL
 mapping exists ???

 ;-( ;-( ;-(

I use Forth all the time to call DLLs and other libraries. I think you have a narrow view of what Forth is.

You will interest me the day I can call your Forth stuff from my C/Java/ Python land. My view may be narrow, but at least I can use each language for what it is better at:

Il y a une raison pour laquelle j'�vite de parler fran�ais sur Wiki: m�me si le fran�ais est ma langue maternelle, et m�me si j'y tiens certainement autant qu'un anglophone a son anglais, le fran�ais n'est pas tr�s efficace pour v�hiculer mes idees dans le contexte de l'industrie de l'information.

From which it follows that I want to be able to use whatever is best suited for the task at hand, be it Forth or otherwise. Unfortunately, it is very difficult, to say the least, to call anything I might have written in Forth from any other planet.

See my point now?

You mean 'the day I can call Forth from my C/Java/Python land in one particular way' Not all RPCs have to be in the form of DLLs and it's pretty easy to implement them in Forth. DLLs happen to be problematic for most (but not all) Forth compilers.

-- verec

Yet it would be unfair to say that Forth Land is entirely composed of autistic Forthers with obvious lack or need for communication skills, quite the opposite: they spend their time ReinventingTheWheel (big, squared, colored, in 4D space,...) and enjoy bragging about it in news://comp.lang.forth for months at a time.

Unfortunately, I have to agree with this one. :)

But then again, since you claim the Forth is unreadable, unportable, and unreusable, it would naturally follow that every Forth programmer has to reimplement everything entirely from scratch. As this is not the case, it follows that there is something wrong with your thesis.

First, being unreadable, unportable, and unreusable does not mean useless in any way. Secondly, yes, you are right, most Forth programmers have, at one point or another reimplemented at least partially their own Forth and, BTW: that's exactly ChuckMoore stance!

ForthReusability