Re: Structured Programming using Forth

Paul E. Bennett wrote:
Werty comes up with dreams that programmers would tend to like, or at
least near-programmers. Programming with interlocking symbols that
only fit together the right way and that intuitively show what they
do. Wouldn't it be wonderful if you could do that! I had the idea of a
Forth editor that would display stack inputs and outputs as colored
lines, and when you type a word (or drag the icon) it draws the lines
to it and from it, and shows you if there's an obvious type error.
When there are 4 stack items and the word only uses two then the other
two would go under the word and stay down until some other word was
ready to use them. It was the same sort of idea except not nearly as
bold.

This is an idea that was written up in Forthwrite some years back in an
article by Gordon Charlton. A great idea but no one at the time saw a way
to accomplish it. If someone does manage to produce such an editing system
then please tell us (I can imagine it might be a bit like the National
Instruments VI editor).

Part of what is being described here has another name: a strongly typed language. Having two symbols that represent some computation that can only fit together the right way...

int sum(int x, int y) { return x + y; }
sum("42", rgbaColor);

* error in argument 1: expecting int got array of char
* error in argument 2: expecting int got struct rgba

Werty's future... today! It's found in C, C++, Java, C#, the Pascal family, and so on. Slap on a visual interface, hire a anthropologist to come up with a culture-neutral symbology (in my mind the hardest problem the solve), and presto.

The problem with werty's ideas isn't that they are so futuristic and bizarre to be unimplementable. The problem with werty's ideas is that they have been done before-- endlessly-- and programmers have found them to be less than satisfying environments.

There is another problem with werty's messages-- that they end right at the point where it might get interesting. Visual programming languages based on the imperative procedural models we have now absolutely sucks as an idea. Other models, such as data-flow architectures are a much better match to a visual representation.

Oh well. Ideas are cheap -- and yet when you don't have one, how
expensive it is! I'll offer a Werty-like idea that I presented here
years ago and didn't do much with myself. I claim that mostly, having
a sea of processors for a program isn't much more use than having a
sea of programmers for a project. You need a way to organise them. And
one traditional way to organise programmers is with the "surgical
team" approach. Each member of the team gets a specific job that they
do well. You might want each team member to have specific training for
their particular job, too.

Chuck is with you there. Intellasys are working on the hardware for the sea
of processors already.

And like I've said before, the hardware of Intellasys? Who cares. Their use of Forth? Big deal. The hardware and software are trivia compared to the *real* problem, which is providing the programmers with the tools and a model to effectively use the hardware. Programming the SEAforth processor involves a whole bunch of skills that many programmers haven't dealt with before.

How will I break my computation up so it most efficiently maps to multiple processes? How will I actually allocate those processes to physical processors, given that only adjacent processors can communicate with each other? What kind of communications are appropriate in such a system? What kind of tools will be provided to help me debug systems that may have 24 concurrent and asynchronous processors?

Everyone is getting excited over the dribbles of information from Intellasys. I'll get excited when I see the tools, models, and training that they offer to actually make their hardware live up to the promise.
.

Relevant Pages

  • Re: !p+, and thank you Jeff
    ... traditional Forth programmers, ... It is why our hardware can be simpler and our software can ... It was fun trying to write small and fast ... ANS Forth looks the way it does is because of Pentium ...
    (comp.lang.forth)
  • Re: Sound after upgrade to 11.1
    ... And many people have no problem with sound -- whereas ... I've been using SUSE since 7.0 and have heard the same complaints at ... to strenuously test their OS on *every possible combination of hardware ... There are thousands of programmers working on the kernel and all the ...
    (alt.os.linux.suse)
  • Re: Sound after upgrade to 11.1
    ... I've been using SUSE since 7.0 and have heard the same complaints at ... of hardware available*. ... There are thousands of programmers working on the kernel and all the ... Linux is *still* a largely volunteer environment. ...
    (alt.os.linux.suse)
  • Re: hardware errors, do C and Forth need different things in hardware?
    ... Unix as the software traffic cop for the hardware traffic ... It doesn't matter that the vast array of micros being used in embedded systems don't have any operating system on the target. ... To you, C programmers have a "mindset" that forces them to require an operating system on the target, and write code that is far above the bare metal. ...
    (comp.lang.forth)
  • Re: [opensuse] Re: Goodbye to suse and why not stay, The Linux Wall
    ... (By which I mean us programmers and software ... inscrutable software and hardware does not call for a ... quality software and hardware is reminiscent of what caused the crisis ... in the U.S. auto industry in the eighties. ...
    (SuSE)