Yves Surrel
2004-08-18 08:32:13 UTC
Hello
I am a long user of Forth, since I discovered it in the early '80s
when it had to be downloaded from a tape to my 6502-based "Oric 1". I
have always stuck to Forth as I recognize it as clever, simple,
powerful and unlimited. However I also used Delphi, I am a certified
developer in Labview (a scientific software by National Instruments,
http://www.ni.com), I had a look to TCL/Tk, Java, Python...
I am a scientist, not a developer. For me software is a tool, not a
goal. I expect to spend minimum time to achieve what I want. I am
looking for the simplest and most powerful solutions, not fighting for
a particular "chapel". That's why I use Labview for some needs, which
is undoubtedly simple and powerful (graphical programming)
I love the Mac from the beginning, but had to develop for Wintel
because it is an industry standard (don't ask me _why_ it became a
standard, as I always heard people complaining about it...). So I used
Win32Forth these last years to develop a software which is now used in
a professional application (basically image processing for quality
control in manufacturing industries).
The architecture is the following. I separated the calculation kernel
from the human interface, thanks to the ability of Win32Forth to
generate DLL's very easily. I developped the first version of the
interface with Delphi. The forth DLL has a single entry point which
expects a string to be interpreted. So the interface can use all the
power of forth very easily. If a new call is needed, it suffices to
send the appropriate string to the forth interpreter. The DLL needs
not be changed, which is very practical.
For team working, this separation is excellent: some guys work on the
interface and I work on the kernel, and there is no mixture. The fact
that the programming language is not the same helps keeping
functionalities well separated. Different human interfaces can be
developped depending on the client requirements: e.g; a "laboratory"
one, giving full access to all possibilities, even giving access to a
forth terminal, thus providing the user a full object-oriented
development system with interpreter, compiler, decompiler, assembler,
disassembler, debugger (all this in a <1Meg DLL!), or a "blue collar"
one with a red button "Go" and an indicator: green (test passed OK) or
red (test failed).
My concern is today: what about system-independence, more precisely
Wintel-independence? As you probably knows, Win32Forth and Mops are
very close. I mostly used the former, I mentioned why, although I have
a very good feeling about Mops (e.g. Mops allows multiple inheritance,
W32F does not).
I regret that both systems are too intricately relying on 1) the
processor type 2) the operating system 3) the windowing system. I
would be very happy with an architecture with layers separating:
-the interface to the processor (I recognize that in general there is
a single file gathering all assembly code definitions for @, !, etc,
so this "layer" mostly already exists)
-the interface to the operating system;
-the interface to the windowing system and user input-output.
Why reinvent the wheel? Java could be a good way to have a windowed
interface to a forth kernel, not depending on a particular OS. Is it
an interesting challenge to be able to build the visual interface in
forth? In my opinion: _no_ because there are freeware tools that allow
to build it more easily and quickly. (ForthForm in the Win32Forth
world is nice, yet limited and... Windows-specific...). JBuilder you
can download free from Borland corresponds to lots of engineer-years
of development. Why not use that? Have a look at JEdit, developped in
Java: it works and looks fine on Mac OS X and Windows. Very
convincing.
I really would be happy with a forth development going towards:
-melting all good features from win32Forth and Mops into a single
system-independent "resource" (shared library or something more
clever...), so that the (too small) communities of forth developpers
can work together (this is really needed!);
-development of a system-independent RAD (rapid application
development) allowing the use of the system-independent Forth above
(maybe it suffices to use JBuilder and implement some Java classes to
make the appropriate calls and callbacks...). I mention Java, it may
be Tcl/Tk or wxPython or whatever.
Remember that the modern trend in programming is the MVC
(model-view-controller) architecture, where roles are well defined and
separated in different software entities.
I post also this message to http://groups.yahoo.com/group/win32forth/
Cheers
Yves
I am a long user of Forth, since I discovered it in the early '80s
when it had to be downloaded from a tape to my 6502-based "Oric 1". I
have always stuck to Forth as I recognize it as clever, simple,
powerful and unlimited. However I also used Delphi, I am a certified
developer in Labview (a scientific software by National Instruments,
http://www.ni.com), I had a look to TCL/Tk, Java, Python...
I am a scientist, not a developer. For me software is a tool, not a
goal. I expect to spend minimum time to achieve what I want. I am
looking for the simplest and most powerful solutions, not fighting for
a particular "chapel". That's why I use Labview for some needs, which
is undoubtedly simple and powerful (graphical programming)
I love the Mac from the beginning, but had to develop for Wintel
because it is an industry standard (don't ask me _why_ it became a
standard, as I always heard people complaining about it...). So I used
Win32Forth these last years to develop a software which is now used in
a professional application (basically image processing for quality
control in manufacturing industries).
The architecture is the following. I separated the calculation kernel
from the human interface, thanks to the ability of Win32Forth to
generate DLL's very easily. I developped the first version of the
interface with Delphi. The forth DLL has a single entry point which
expects a string to be interpreted. So the interface can use all the
power of forth very easily. If a new call is needed, it suffices to
send the appropriate string to the forth interpreter. The DLL needs
not be changed, which is very practical.
For team working, this separation is excellent: some guys work on the
interface and I work on the kernel, and there is no mixture. The fact
that the programming language is not the same helps keeping
functionalities well separated. Different human interfaces can be
developped depending on the client requirements: e.g; a "laboratory"
one, giving full access to all possibilities, even giving access to a
forth terminal, thus providing the user a full object-oriented
development system with interpreter, compiler, decompiler, assembler,
disassembler, debugger (all this in a <1Meg DLL!), or a "blue collar"
one with a red button "Go" and an indicator: green (test passed OK) or
red (test failed).
My concern is today: what about system-independence, more precisely
Wintel-independence? As you probably knows, Win32Forth and Mops are
very close. I mostly used the former, I mentioned why, although I have
a very good feeling about Mops (e.g. Mops allows multiple inheritance,
W32F does not).
I regret that both systems are too intricately relying on 1) the
processor type 2) the operating system 3) the windowing system. I
would be very happy with an architecture with layers separating:
-the interface to the processor (I recognize that in general there is
a single file gathering all assembly code definitions for @, !, etc,
so this "layer" mostly already exists)
-the interface to the operating system;
-the interface to the windowing system and user input-output.
Why reinvent the wheel? Java could be a good way to have a windowed
interface to a forth kernel, not depending on a particular OS. Is it
an interesting challenge to be able to build the visual interface in
forth? In my opinion: _no_ because there are freeware tools that allow
to build it more easily and quickly. (ForthForm in the Win32Forth
world is nice, yet limited and... Windows-specific...). JBuilder you
can download free from Borland corresponds to lots of engineer-years
of development. Why not use that? Have a look at JEdit, developped in
Java: it works and looks fine on Mac OS X and Windows. Very
convincing.
I really would be happy with a forth development going towards:
-melting all good features from win32Forth and Mops into a single
system-independent "resource" (shared library or something more
clever...), so that the (too small) communities of forth developpers
can work together (this is really needed!);
-development of a system-independent RAD (rapid application
development) allowing the use of the system-independent Forth above
(maybe it suffices to use JBuilder and implement some Java classes to
make the appropriate calls and callbacks...). I mention Java, it may
be Tcl/Tk or wxPython or whatever.
Remember that the modern trend in programming is the MVC
(model-view-controller) architecture, where roles are well defined and
separated in different software entities.
I post also this message to http://groups.yahoo.com/group/win32forth/
Cheers
Yves