A Forth IDE (crossposted) 
Author Message
 A Forth IDE (crossposted)

Quote:




> > >How is it that the programming community is going forward?

> > Have you used Code Warrior or the Think IDE or a Smalltalk with the
> browser and
> > class windows and variable watches and single stepping and all that?

> No.  I only know of languages that my college is currently teaching, and
> others that I've accidentally run into.  But I've never heard of Smalltalk
> until the last couple of weeks.

> What is it about these languages that make them forward?  I try to remember
> that change and progress don't necessarily coincide.

Smalltalkers:
  here are some Forthers that want info on what an IDE should look like.

Forthers:
  here are some Smalltalkers that'll happily answer questions on the
Smalltalk IDE designs.

Let me start with a blurp comparing Forth with Smalltalk. Please be
aware it is a while since I touched Forth and that I have only used
non-commercial Forth environments.

Smalltalk is a *pure* OO language in the sense that _everything_ is an
object.

Smalltalk has IDE and project mixed much the same as Forth.

Smalltalk saves a project much the same as Forth, it makes a memory dump
called an 'image'.

Where Forth is stack oriented Smalltalk is heap oriented. You can easily
remove stuff without having unused holes in your memory.

Smalltalk is late binding, you can change methods on the fly (while a
project is running).

Where Forth is (usually implemented as) untyped Smalltalk is dynamically
typed, it will throw a Smalltalk level exception when you are trying
things that are not possibe.

Smalltalk has fully automagic garbage collection.

Most Smalltalks have a rigid seperation of the execution engine (VM) and
the object heap. Most VMs are designed to be uncrashable, meaning that
all ambiguous situations are handled at the Smalltalk level. Smalltalk
has no ways to manipulate pointers directly and full array bounds
checking, you cannot reference illegal memory segments.

Where Forth has no syntax Smalltalk has a tremendously simple syntax.
You only have to learn one syntax once. IMO Smalltalk code is more
expressive than Forth code (it _reads_ easier then Forth code).

Smalltalk does not have equivalents of defining/compiling words in it's
syntax. In practice I hardly ever miss it (but sometimes I do ;-). The
compiling and defining mechanisms are visible as (implemented in)
Smalltalk so you do have access to them.

Forth projects have an associated linear source, Smalltalk abandons this
concept completely for coding. In Smalltalk you 'meddle with your image'
until stuff works, in forth you'd be editing source, loading portions,
testing. I perceive Smalltalk development iteration to be faster than
with Forth.

Since Smalltalk is dynamically bound you can call methods before they
exist. This makes it possible to practice 'just in time programing',
*great* for explorative programming sessions.

Smalltalk encourages 'merciless' factoring just like Forth. Smalltalk
also enables merciless re-factoring, something that takes more effort in
Forth.

The Smalltalk IDE is windows based, you have a small window for every
object or concept you are viewing/editing. Viewed objects can customize
their viewer-editor ('inspector') depending on their class. Concepts are
edited by openenig their tool, the central one being the class browser.
This browser has a slew of usefull menu entries to quickly open windows
on other concepts like 'senders of' and 'implementors of' a method. You
can edit objects and concepts _while_ their code is running. (You can
change the IDE _while_ it's running, no reload and restart neccasary!)

There are many Smalltalk implementations, but the one most relevant to
advanced IDEs is Squeak.

Squeak is an open source Smalltalk implementation that is used as a
research/test bed for Smalltalk itself.
It has several IDEs, the traditional classbrowser based IDE and newer
ones like the 'Morphic' IDE (backported from a descendent of Smalltalk
called 'Self').

There is a demonstration for non-programmers of the Morphic IDE in
Squeak by Alan Kay at the end of his presentation 'The Computer
"Revolution" Hasn't Happened Yet!':
  http://www.*-*-*.com/
  (real video, Squeak demo starts at minute 48)

Here is an (often criticized, be warned) table comparing language
productivity:
  http://www.*-*-*.com/

Here is a Smalltalk advocacy site:
  http://www.*-*-*.com/

And here is Squeak:
  http://www.*-*-*.com/

HTH,
  start shooting those IDE questions...

Reinout Heeck
-------------



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)
Quote:
> Smalltalkers:
>   here are some Forthers that want info on what an IDE should look like.

> Forthers:
>   here are some Smalltalkers that'll happily answer questions on the
> Smalltalk IDE designs.

> Let me start with a blurp comparing Forth with Smalltalk. Please be
> aware it is a while since I touched Forth and that I have only used
> non-commercial Forth environments.

<removed blurp>

How fast is smalltalk?  How small is code generated in Smalltalk?  How long
has Smalltalk been around?  What do you mean by "heap-based"?

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:
>How fast is smalltalk?

That depends.  Usually more than fast enough.

Quote:
> How small is code generated in Smalltalk?

That depends.  Typically very small.  However, Smalltalk
systems typically contain a *lot* of stuff and are fairly
big, though nto really by todays standards.

Quote:
>How long has Smalltalk been around?

Since 1972, although the current form dates from circa 1980.

Quote:
> What do you mean by "heap-based"?

All objects are allocated from the heap (except for some
where this is optimized away).

Marcel
--

Java and C++ make you think that the new ideas are like the old ones.
Java is the most distressing thing to hit computing since MS-DOS.
                                          - Alan Kay -



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:
> How fast is smalltalk?

if you work with compareable concepts in C++ or C
most implementations of Smalltalk will win this combat

Quote:
> How small is code generated in Smalltalk?

very, very, very - if you compare the source _and_
generated byte code. because methods tend to be very
small (around three lines) and the bytecode is
very optimized for OO - needs.

Quote:
> What do you mean by "heap-based"?

every object is dynamically created on heap. this
implies the possibility for fast GC and memory
management implementation (much faster as every
malloc/free packet. the reason lies not on the
algorythm, it lies on the whole concept)

--
Greetings from Lake Constance, Germany




Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:

> Um, the "meddle with you image" is something I don't like. This means
> that you have a somewhat working program (image)

You start with a _working_ program provided by the vendor, which
consists of a live set of all the object instances that the vendor
thought was useful.  Among those object instances are the classes
themselves, which are instances of their metaclasses.  Their behaviors
are defined by the set of CompiledMethod instances that have been placed
in each of their MethodDictionary instances.

Quote:
> , and nobody knows how
> it got there.

The Smalltalk vendor for the IDE you are using put it there.

Quote:
> Looks fun to debug it,

You are not expected to debug the vendor's code.

Quote:
> and more so to port it to another
> Smalltalk system.

Copying a vendor's code in that manner would be a copyright violation.

Quote:
> I hope Smalltalk still has the notion of source (with
> comments and all that stuff).

In Smalltalk, you "write" your program by sending messages to the
vendor's live set of existing objects.  The typical result of each
message send is that another object is created.  Anytime an object is
created, it joins the live set of all the object instances in your
image.  The image doesn't discern a difference between the objects you
created, and the objects the vendor created, but you do.

You can reproduce your "program" by taking the vendor image, and
replaying the set of messages that transformed that image into your
"program".  This set of messages can take several forms, some of which
are considered by most Smalltalkers to be Smalltalk "source code".

To port that "source code", you simple make sure that the set of
messages that represent that "source code" can be replayed in a
different vendor's image and produce the same resulting "program".
That's not as hard as it sounds.

Nevin Pratt



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:

> Forth projects have an associated linear source, Smalltalk abandons this
> concept completely for coding. In Smalltalk you 'meddle with your image'
> until stuff works, in forth you'd be editing source, loading portions,
> testing. I perceive Smalltalk development iteration to be faster than
> with Forth.

Um, the "meddle with you image" is something I don't like. This means
that you have a somewhat working program (image), and nobody knows how
it got there. Looks fun to debug it, and more so to port it to another
Smalltalk system. I hope Smalltalk still has the notion of source (with
comments and all that stuff). Chuck Moore abandoned source in OK, and
went back to it, telling us that abandoning source was an error.

During the last 14 years of using Forth, my development methods have
changed with the increased computer speed. Nowadays, loading the whole
application and having a separate editor process is much better suited
than incremental development. The "incremental" doesn't help you
anything performance-wise, since the whole project compiles in a blink
of an eye (at least with Forth's simple syntax). Since Smalltalk is
about as simple to parse as Forth, I expect about the same is true with
Smalltalk.

The dynamical binding of OOP is nice, though. I can do the same in my
OOP extension to Forth, and while Forth doesn't reclaim dictionary
memory if you redefine a method, you still can use that e.g. to give the
GUI a new appearence ("theming") on the fly.

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



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:


> > Forth projects have an associated linear source, Smalltalk abandons this
> > concept completely for coding. In Smalltalk you 'meddle with your image'
> > until stuff works, in forth you'd be editing source, loading portions,
> > testing. I perceive Smalltalk development iteration to be faster than
> > with Forth.

> Um, the "meddle with you image" is something I don't like. This means
> that you have a somewhat working program (image), and nobody knows how
> it got there. Looks fun to debug it, and more so to port it to another
> Smalltalk system. I hope Smalltalk still has the notion of source (with
> comments and all that stuff). Chuck Moore abandoned source in OK, and
> went back to it, telling us that abandoning source was an error.

A Smalltalk development image holds the source and that is what you
edit, not hex codes with colorization.

Most implementations have their complete source included.
Most Smalltalks also maintain a human readable changes log that can be
replayed into a pristine image in case you lose control of your image.
The way of packaging projects is very vendor specific, but most supply a
binary exchange format.

Since Smalltalk enables frequent refactoring the images actually *are*
fun to debug compared with all other environments I know.

Quote:
> During the last 14 years of using Forth, my development methods have
> changed with the increased computer speed. Nowadays, loading the whole
> application and having a separate editor process is much better suited
> than incremental development. The "incremental" doesn't help you
> anything performance-wise, since the whole project compiles in a blink
> of an eye (at least with Forth's simple syntax). Since Smalltalk is
> about as simple to parse as Forth, I expect about the same is true with
> Smalltalk.

A project I'm currently working on takes 10 minutes to initialize so I'm
rather glad that I can keep the image alive between code changes.

IMO Smalltalk compiling is relatively slow, but since we only compile on
a per-method base it happens in a blink of an eye even on older
hardware.

Back to the IDE

In Smalltalk I have the habit of keeping several 'editors' open, some on
code, some on domain objects.

I can influence the system _while_ it is running by directly
manipulating my application's objects in their respective inspectors or
by compiling code in the class browser or the de{*filter*}.
Recompiling an existing method means actually replacing the code. The
original code gets garbagecollected once there are no references to it
left.

All of the inspectors and a lot of other tools contain a textarea where
arbitrary pieces of code can be selected and an inspector opened on the
result of evaluating it (in the context of the object being viewed,
binding to variables etc).

Here's a page with screenshots of Squeak most of whitch show a
classbrowser and a workspace. The latter is a tool with only a textarea
to evaluate code snippets in the global context. No inspectors in these
screenshots though.
  http://www.*-*-*.com/

Quote:

> The dynamical binding of OOP is nice, though. I can do the same in my
> OOP extension to Forth, and while Forth doesn't reclaim dictionary
> memory if you redefine a method, you still can use that e.g. to give the
> GUI a new appearence ("theming") on the fly.

Well, Smalltalk does this all the time on a VM geared towards doing this
all the time. There are some nifty tricks that can be done to optimize
polymorphic dispach dynamically, making it faster than the dispatch
implementations common in OO add-ons to languages.
I experimented a bit with breaking number crunching routines out into a
C coded dll. I experienced a factor 5 increase in speed in my case
(tight loops around a single floating point operation).

In your example you seem to want to change the appearance by altering a
method.
In my Smalltalk environment I instantiate a new UILookPolicy and a new
UIFeelPolicy and plug them into the UI system. The way I do it is by
selecting the appropriate policy in a menu in my preferences tool.
But I could rather easily do it in code as well because Smalltalk has
powerfull tools to get to both the implementation and the using code,
making it easy to get it up and running fast.

Is there a screenshot or description of the current state of the art of
IDEs in Forth?

Reinout
-------



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)
Hi

Quote:
> The dynamical binding of OOP is nice, though. I can do the same in my
> OOP extension to Forth, and while Forth doesn't reclaim dictionary
> memory if you redefine a method, you still can use that e.g. to give the
> GUI a new appearence ("theming") on the fly.

I'm not familiar with forth nor with your OOP extension,
so I have a question. did your OOP extension include
inheritance ? I'm looking for an alternate between Smalltalk
and C.

--
Greetings from Lake Constance, Germany




Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:
> There are many Smalltalk implementations, but the one most relevant to
> advanced IDEs is Squeak.

> Squeak is an open source Smalltalk implementation that is used as a
> research/test bed for Smalltalk itself.
> It has several IDEs, the traditional classbrowser based IDE and newer
> ones like the 'Morphic' IDE (backported from a descendent of Smalltalk
> called 'Self').

The Morphic Gui has certainly has a wonderful look and feel. But I wouldn't
say that the IDE is terribly revolutionary, although I do love the way it
looks.

I'd say that Dolphin has more genuine innovation IDE-wise. For instance,
there's the protocol browser, which allows you to declare and track
interfaces independent of inheritance - multiple interfaces per class are
allowed, providing an excellent work around for the lack of MI.There's also
a very strong package browser, that allows you to bundle changes to the
image into packages and mangae them in a traditionally Smalltalk IDE way.
Squeak lacks both of these facilities, and they make a difference on the
fundamental level of how you use the system, rather than how pretty it is.

And then there are Dolphin's wizards and other ways of generating
grunt-code. Normally I *hate* wizards, but yesterday one of these things ate
Microsoft's Scripting Engine file system, or some such VB-ish thing, and
turned it into a set of decent, browsable, Smalltalk classes for me. This I
can more than live with. Squeak lives on non-Smalltalk OSes, but tries to
ignore the fact. Dolphin co-opts its host. Hence Squeak is incredibly
portable, while it's my Dolphin lets you get jobs done on Windows much
faster. How much of this is relevant to Forth, I don't know.

That said, Squeak IS a lot of fun. It will be a lot more fun when someone
writes real documentation for Morphics, of course...

Quote:
> Here is an (often criticized, be warned) table comparing language
> productivity:
>   http://www.spr.com/library/0langtbl.htm

Yes, if you read the small print you'll find that some of these languages
were assessed from "experience" (ie the prejudices of one of the tables'
authors were consulted) and others by reading about them (great for academic
toy langauges, which are only discussed by their proponents). The only thing
worse than using any of these methods individually would be to match and mix
them for different languages, so that there's no consistency at all. Except,
well, you could then fail to say which language was evaluated by which
method. Oh - that's exactly what they did.

Jonathan

Quote:

> Here is a Smalltalk advocacy site:
>   http://whysmalltalk.com/

> And here is Squeak:
>   http://squeak.org/

> HTH,
>   start shooting those IDE questions...

> Reinout Heeck
> -------------




Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:

> I'm not familiar with forth nor with your OOP extension,
> so I have a question. did your OOP extension include
> inheritance ?

Yes, certainly. OOP IMHO must have inheritance (with a single
inheritance tree, that's good enough), data encapsulation (instance
variables), and polymorphism (via late binding). Overloading (i.e. early
bound methods with the same name for different classes) is just an
optimization, and should be available if performance is important. My
OOP extension also features information hiding, and I've implemented
interfaces (IMHO better than multiple inheritance) in the ANS Forth
compatible version (not backported to the bigFORTH version yet).

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



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:

> Most implementations have their complete source included.
> Most Smalltalks also maintain a human readable changes log that can be
> replayed into a pristine image in case you lose control of your image.

Well, that looks much better than just "meddle with your image".

Quote:
> IMO Smalltalk compiling is relatively slow, but since we only compile on
> a per-method base it happens in a blink of an eye even on older
> hardware.

Why? Smalltalk's syntax is rather straight-forward (expression ::=
object | object method expression*), and since it only generates
non-optimized byte-code, there's hardly anything difficult to do.

Quote:
> Well, Smalltalk does this all the time on a VM geared towards doing this
> all the time. There are some nifty tricks that can be done to optimize
> polymorphic dispach dynamically, making it faster than the dispatch
> implementations common in OO add-ons to languages.

Well, the add-ons I know have a vtable approach, where polymorphic
dispatch means: fetch vtable pointer, add literal to that, fetch method
pointer, call that. I.e. x86 assembler

mov  tmpreg,0(OP)
call method(tmpreg)

where a good optimizer certainly can eliminate some of the loads to
tmpreg, or at least schedule it so that the extra costs are hidden.

Quote:
> Is there a screenshot or description of the current state of the art of
> IDEs in Forth?

http://www.*-*-*.com/

but the screenshot is only the interface builder part (not a complete
IDE - there's also a class browser, source editors, command line
interface, de{*filter*}, etc.). My initial plans were to allow in-place
editing and changing code of the running system, but it turned out that
hitting the "run" button is so fast that you don't really want it. Forth
is also quite crash-prone, so you better have your IDE unaffected of the
crashes of the app in development.

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



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:

> There are many Smalltalk implementations, but the one most relevant to
> advanced IDEs is Squeak.

How so? While Squeak certainly is relevant to that topic, it is quite a
stretch to say that it is "most relevant". The major commercial dialects
like VisualWorks, Dolphin and (especially) VisualAge are also very relevant
to this topic.

-Eric



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:

> > IMO Smalltalk compiling is relatively slow, but since we only compile on
> > a per-method base it happens in a blink of an eye even on older
> > hardware.

> Why? Smalltalk's syntax is rather straight-forward (expression ::=
> object | object method expression*), and since it only generates
> non-optimized byte-code, there's hardly anything difficult to do.

There's hardly any need to optimize it, so the design is kept simple
and extendable sacrificing some performance.

When parsing a big chunk of foreign code this is usually done only once,
thereafter we use the faster binary formats to store it.

Quote:
> > Well, Smalltalk does this all the time on a VM geared towards doing this
> > all the time. There are some nifty tricks that can be done to optimize
> > polymorphic dispach dynamically, making it faster than the dispatch
> > implementations common in OO add-ons to languages.

> Well, the add-ons I know have a vtable approach, where polymorphic
> dispatch means: fetch vtable pointer, add literal to that, fetch method
> pointer, call that. I.e. x86 assembler

> mov  tmpreg,0(OP)
> call method(tmpreg)

> where a good optimizer certainly can eliminate some of the loads to
> tmpreg, or at least schedule it so that the extra costs are hidden.

But this is 'only' static optimization. One trick I know of is called
'Polymorphic Inline Caches' where an inline case statement is treated as
a cache for recent method lookups. The case statement is dynamically
altered to maximize the chance of a hit in this 'cache'.
Hotspot optimization is used in the Self VM, Im not sure how far these
two techniques penetrated into Smalltalk VMs.

Quote:
> > Is there a screenshot or description of the current state of the art of
> > IDEs in Forth?

> http://www.*-*-*.com/

> but the screenshot is only the interface builder part (not a complete
> IDE - there's also a class browser, source editors, command line
> interface, de{*filter*}, etc.). My initial plans were to allow in-place
> editing and changing code of the running system, but it turned out that
> hitting the "run" button is so fast that you don't really want it. Forth
> is also quite crash-prone, so you better have your IDE unaffected of the
> crashes of the app in development.

Thanks, I hope to find some time to give it a testdrive.

Reinout
-------



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:



> > There are many Smalltalk implementations, but the one most relevant to
> > advanced IDEs is Squeak.

> How so? While Squeak certainly is relevant to that topic, it is quite a
> stretch to say that it is "most relevant". The major commercial dialects
> like VisualWorks, Dolphin and (especially) VisualAge are also very relevant
> to this topic.

Point taken, reading it back I agree that was way to strong an
assertion.

Reinout



Wed, 18 Jun 1902 08:00:00 GMT  
 A Forth IDE (crossposted)

Quote:

> Forth
> is also quite crash-prone, so you better have your IDE unaffected of the
> crashes of the app in development.

In Smalltalk it is customary to have bounds checking, it's programming
model does not allow pointer arithmetic so bad memory references are
ruled out.
Anytime the application crashes a Smalltalk exception is thrown. If the
exception is not caught a default handler kicks in, giving me options to
terminate the app (not the ide) or open a de{*filter*}.
In effect you hardly ever crash the VM (but you can loose control of the
ide).

So what is current practice in Forth, can the execution machinery be run
in a crash resilient mode or is that uncommon?

Reinout



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Export from MSSQL to Acces (crossposted)

2. Borlands FORTH IDE System

3. Forth IDE

4. Q: State of Forth IDE's?

5. A Forth IDE

6. HolonJ - a Forth to Java IDE

7. IDE or Enhanced-IDE?

8. ANNOUNCE: CodeMagic Universal IDE for Win32 (Free Perl IDE)

9. Getting Forth related files (was: Forth primer/teaching Forth)

10. Forth in Forth vs. Forth in assembly language

11. Forth in Forth vs Forth in assembly

12. Forth in Forth vs. Forth in assembly language

 

 
Powered by phpBB® Forum Software