Olympic Spririt for Forth

[Paul E. Bennett]

In attending this years EuroForth conference in Oxford, it seems that the
community needs to instil the "Inspire a Generation" spirit that pervaded
the London 2012 Olympics event. By this we mean that we need to raise theons
for self expres level of enthusiasm for Science, Technology, Engineering and
Mathematics within the upcoming generations from primary school level
upwards.

There are companies that need the right sort of new-blood intake that not
only has some enthusiasm for the STEM subjects, but also the desire to
continue learning useful skills and techniques to create the technology that
will carry their own generation's aspiration to self expression.

What sort of projects do those members of the list think will be affordable
and inspirational enough to fulfil this goal?

--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[Mark Wills]

On Sep 15, 10:29 pm, "Paul E. Bennett" <Paul_E.Benn...@topmail.co.uk>
wrote:

> In attending this years EuroForth conference in Oxford, it seems that the
> community needs to instil the "Inspire a Generation" spirit that pervaded
> the London 2012 Olympics event. By this we mean that we need to raise theons
> for self expres level of enthusiasm for Science, Technology, Engineering and
> Mathematics within the upcoming generations from primary school level
> upwards.
>
> There are companies that need the right sort of new-blood intake that not
> only has some enthusiasm for the STEM subjects, but also the desire to
> continue learning useful skills and techniques to create the technology that
> will carry their own generation's aspiration to self expression.
>
> What sort of projects do those members of the list think will be affordable
> and inspirational enough to fulfil this goal?
>
> --
> ********************************************************************

> Paul E. Bennett...............<email://Paul_E.Benn...@topmail.co.uk>

> Forth based HIDECS Consultancy
> Mob: +44 (0)7811-639972
> Tel: +44 (0)1235-510979
> Going Forth Safely ..... EBA.www.electric-boat-association.org.uk..
> ********************************************************************

Well, for youngsters, how about a cycle computer? You know... the ones
that tell you your current speed, average speed, distance travelled,
total distance travelled etc. Should easily be possible with a tiny
little embedded Forth board. Would just need some IO (an analog input
for sensing the sensor on the spokes as the wheel turns) some DO's
(for the LCD display), some DI's (for the UI controls (which mode to
select etc)).

It mixes a little bit of math in there too; different wheel sizes
cover different distances per revolution, and the computer needs to
take account of this. That opens up avenues for interesting discourse
as to how that particular problem may be solved without recourse to
floating point math, for example.

It might get them out on their bicycles, too :-)

Just thought I'd punt an idea, for what it's worth!

Regards

Mark

[Anton Ertl]

Mark Wills <forth...@gmail.com> writes:
>Well, for youngsters, how about a cycle computer? You know... the ones
>that tell you your current speed, average speed, distance travelled,
>total distance travelled etc. Should easily be possible with a tiny
>little embedded Forth board. Would just need some IO (an analog input
>for sensing the sensor on the spokes as the wheel turns) some DO's
>(for the LCD display), some DI's (for the UI controls (which mode to
>select etc)).

The input is digital: There's a magnetic switch that is activated by
the passing of the magnet.

The result could not compete with a commercial cycle computer in most
respects: It would consume much more energy, die in bad weather,
probably cost more, be bigger and heavier. You would have to make up
for these deficiencies in some other way, maybe in ways where the
programmability pays off, like being able to compute unusual metrics,
or having a program for interval training or somesuch.

Apart from commercial cycle computers, there is another form of
competition: Smartphone apps.

- 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 2012: http://www.euroforth.org/ef12/

[Mark Wills]

On Sep 18, 1:11 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

Sure, something cooked up by a bunch of kids on a development board
could not compete with a commercial unit, but that's not the point.
The OP asked for ideas to try to inspire youngsters. Given that
Forth's niche is generally seen to be in the embedded arena, I thought
I would make a suggestion in that vien in the hope that Forth would
get a look in!

Smartphone apps... Well, world + dog is writing smartphone apps, so
the same limitation would apply: Very unlikely a bunch of beginners,
however inspired, could produce something of commercial quality.
Still, if it *did* inspire them and get them into the STEM stream,
then hats off!

[Sp...@controlq.com]

On Tue, 18 Sep 2012, Mark Wills wrote:

> Date: Tue, 18 Sep 2012 02:08:31 -0700 (PDT)
> From: Mark Wills <forth...@gmail.com>
> Newsgroups: comp.lang.forth
> Subject: Re: Olympic Spririt for Forth

A good idea, but my son rides BMX bicycles, and spends more time in the
air and inverted ... perhaps a MEMS accelerometer application with Forth
software to chart the "ups and downs" so to speak.

Cheers,
Rob.

[Anton Ertl]

Mark Wills <forth...@gmail.com> writes:
>Sure, something cooked up by a bunch of kids on a development board
>could not compete with a commercial unit, but that's not the point.

That's ok. One just has to make sure the expectations of the kids
match with that. Of course, it's better if there is at least one cool
feature that the self-programmed unit has that the commercial ones
don't. The accelerometer sounds good.

>Smartphone apps... Well, world + dog is writing smartphone apps, so
>the same limitation would apply: Very unlikely a bunch of beginners,
>however inspired, could produce something of commercial quality.

That's certainly much easier; also, the commercial qualities it misses
will be those (like a granny-compatible UI) that the developers don't
care for.

But yes, it's a very differenty kind of project, and one where Forth
probably does not particularly shine.

[Hugh Aguilar]

On Sep 18, 2:08 am, Mark Wills <forthfr...@gmail.com> wrote:
> Well, for youngsters, how about a cycle computer? You know... the ones
> that tell you your current speed, average speed, distance travelled,
> total distance travelled etc. Should easily be possible with a tiny
> little embedded Forth board. Would just need some IO (an analog input
> for sensing the sensor on the spokes as the wheel turns) some DO's
> (for the LCD display), some DI's (for the UI controls (which mode to
> select etc)).
>
> It mixes a little bit of math in there too; different wheel sizes
> cover different distances per revolution, and the computer needs to
> take account of this. That opens up avenues for interesting discourse
> as to how that particular problem may be solved without recourse to
> floating point math, for example.
>
> It might get them out on their bicycles, too :-)

That is a pretty good idea. As Anton pointed out, the input is
digital; there is a switch that gets triggered when the magnet goes
past. You want to debounce the switch, otherwise the cyclist will have
spurts of over 1000 mph.. If all the thing is doing is a running
display of the speed, and a calculation of average speed since trip-
start, then a pretty small low-power processor can be used. You don't
really need Forth for this --- you can use a tiny processor (like the
PIC16) and write in assembly language.

What I wanted back when I did a lot of cycling, was for the computer
to keep a log of my speed and my heartrate. Afterward, it could squirt
this over to a desktop computer where a graph could be plotted. If I
do the same course repeatedly, I could compare my performance from one
time to the next. This would require a bigger processor (PIC24 or
MSP430) and would justify Forth. You would need at least 100 miles
worth of data, and 200 miles would be better.

The average speed is mildly useful because you know if you are ahead
of schedule or are falling behind. If there are hills though, then you
need to be able to compare graphs to have any kind of meaningful
comparison from one run to the next.

[theorigi...@gmail.com]

Hi folks,

> > What sort of projects do those members of the list think will be affordable
>
> > and inspirational enough to fulfil this goal?

FIGnition is an obvious choice!

http://www.fignition.co.uk

It's a £20 Forth-based DIY home micro with a built-in keypad for programming; composite video output; 8Kb .. 32Kb of RAM 0.5Mb Flash and has the same performance as an early home micro (i.e. it runs Forth as fast as an 8-bitter runs machine code).

An explicit goal is STEM clubs in schools; I've sold about 580 so far with about 20% going to education. The great educational thing about FIGnition is that you can solder it together from scratch and because the firmware is so tiny (16Kb) it's possible to understand it from end-to-end: hardware, video driver, audio driver, flash driver, keypad driver, virtual machine, compiler.

-cheers from julz

[ilya74....@gmail.com]

Hello all.

I'm afraid a single project will be not enough to make a seriously influence on the whole situation. Does anybody hope on the such symple device, which can be implemented by hundreds ways? That is Forth specific features, that could be requested? 'Oh, well! That's a good idea, I'll going to write a short program on C/C++ for one of the my lovely MC boards'. I'm sure there are should be a better solution than simple 'one-day embedded projects'.

If you don't agreed you can think I'm ride my bear for vodka while typing this message :)

With best greetings
Ilya Tarasov
Russia, Moscow

[rickman]

What is the processor on this board? I can't find that.

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> What is the processor on this board? I can't find that.

From "What can it do" on its homepage:

FIGnition now also:

Has been performance tested: thanks to its new Forth interpreter written
in AVR assembler it's now 6x to 20x faster than a Jupiter Ace; seriously
faster than any 80s 8-bit micro when running Forth, in fact it runs
Forth at near native machine-code speeds.

So it's using an AVR, not clear what model, but looking at AVR
datasheets can probably identify it.

I notice there is now a TI Launchpad with a Cortex M4, for just $5 intro
price:

https://estore.ti.com/Stellaris-LaunchPad.aspx

However, you don't get to build it yourself.

[rickman]

If you can get one. I ordered the $5 TI Launchpad eval board last week
and my scheduled delivery is sometime just before Christmas.

Rick

[theorigi...@gmail.com]

Hi folks,

> So it's using an AVR, not clear what model, but looking at AVR
>
> datasheets can probably identify it.

It's documented on the build-it page:

http://www.fignition.co.uk/documentation/build-it-rev-e

It's an AtMega168.

> However, you don't get to build it yourself.

Yep; and in the past year, mere hundreds people in the world have actually built their own computer and over 90% of them will have been FIGnitions :-)

Ilya Tarasov wrote:
> Does anybody hope on the such symple device,
> which can be implemented by hundreds ways?

Well, I was just responding to the initial post. Building your own computer *is* inspiring. It's also a Forth-based computer, which is what you want on this forum eh? Like proper computers it doesn't need an external host to do any programming with it. And it's very similar to an early 80s micro, using similar resources.

But the key thing *is* the simplicity, that's what makes it special; because only simple machines can be mastered and understood from end-to-end. How does it benefit kids if their only true experience of programming requires incomprehensible Giga-byte and GigaHertz, multi-core monstrosities? How would they ever grasp it, if even reading the code in the system would take many lifetimes?

And how is it inspirational if every computer we experience is pre-packaged, surface-mount technology that requires a microscope to modify it? It's in some sense impressive, but what does that say about accessibility?

Ultimately, we have to weigh up why kids aren't inspired to program today. Is it because computers aren't cheap enough (though even a netbook is 3x cheaper than a ZX Spectrum in today's money)? Or could it be something to do with them being 10,000 times more complex? Does FIGnition fit the STEM club criteria? (yes) Can you do a substantial amount of a GCSE computer studies on a FIGnition? (yes) Is FIGnition cute and fun? (you bet ;-) ) !

-cheers from julz

[Paul Rubin]

theorigi...@gmail.com writes:
> It's documented on the build-it page:
> http://www.fignition.co.uk/documentation/build-it-rev-e
> It's an AtMega168.

I didn't see anything on that page identifying the part, and the
AtMega168 according to its data sheet has 16k of flash and 1k of ram.
Are you using external flash and ram, or do you mean another part
number?

> But the key thing *is* the simplicity, that's what makes it special;
>because only simple machines can be mastered and understood from
>end-to-end. How does it benefit kids if their only true experience of
>programming requires incomprehensible Giga-byte and GigaHertz,
>multi-core monstrosities? How would they ever grasp it, if even reading
>the code in the system would take many lifetimes?

Low-level programming certainly has its appeal, though it's also
possible to get started at the other end. The computer game "Code Hero"
teaches kids how to program 3D graphics games in Javascript (using those
gigabytes and gigahertz) and is doing pretty well. I don't think it
would be feasible to implement anything like Code Hero with Forth.
Forth has its own applicable areas that are somewhat different.

[Bernd Paysan]

Paul Rubin wrote:
> I don't think it
> would be feasible to implement anything like Code Hero with Forth.
> Forth has its own applicable areas that are somewhat different.

What part of Code Hero would be impossible? Rember: Two of the major
JavaScript engines are partly written in Forth. So the JavaScript part
is totally within reach of Forth.

A lot of people use Forth on embedded systems. These systems have
limited resources and also not many useful libraries. This doesn't mean
Forth is limited to embedded systems. You probably wouldn't expect
Forth to be part of Firefox, but it is.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Sp...@controlq.com]

On Tue, 2 Oct 2012, Bernd Paysan wrote:

> Date: Tue, 02 Oct 2012 20:20:42 +0200
> From: Bernd Paysan <bernd....@gmx.de>

> Newsgroups: comp.lang.forth
> Subject: Re: Olympic Spririt for Forth
>

> Paul Rubin wrote:
>> I don't think it
>> would be feasible to implement anything like Code Hero with Forth.
>> Forth has its own applicable areas that are somewhat different.
>
> What part of Code Hero would be impossible? Rember: Two of the major
> JavaScript engines are partly written in Forth. So the JavaScript part
> is totally within reach of Forth.

Bernd,

Can you provide a link/citation or such which points to the JavaScript
engines which embed Forth? Gekko??

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
>> I don't think it
>> would be feasible to implement anything like Code Hero with Forth.
>> Forth has its own applicable areas that are somewhat different.
>
> What part of Code Hero would be impossible?

The teaching part, if the idea is for kids to implement animated games
with 3d graphics. They can't reasonably be expected to do that by
writing low level Forth code. The underlying JS engine (written by
experienced programmers) could of course in principle be done in Forth.
Then you'd have to re-implement Unity3D and so on.

Note that the existing JS that I know of that uses Forth (Tamarin
Trace), I think uses Forth only as an intermediate form in a certain
stage of compilation, with the main engine written in C++.

[Paul E. Bennett]

theorigi...@gmail.com wrote:

[%X]

> Well, I was just responding to the initial post. Building your own
> computer *is* inspiring. It's also a Forth-based computer, which is what
> you want on this forum eh? Like proper computers it doesn't need an
> external host to do any programming with it. And it's very similar to an
> early 80s micro, using similar resources.
>
> But the key thing *is* the simplicity, that's what makes it special;
> because only simple machines can be mastered and understood from
> end-to-end. How does it benefit kids if their only true experience of
> programming requires incomprehensible Giga-byte and GigaHertz, multi-core
> monstrosities? How would they ever grasp it, if even reading the code in
> the system would take many lifetimes?

As an advocate of elegant simplicity I know that it is sometimes very hard
to recognize it when you see it. However, simple doesn't always mean small
scale systems.

> And how is it inspirational if every computer we experience is
> pre-packaged, surface-mount technology that requires a microscope to
> modify it? It's in some sense impressive, but what does that say about
> accessibility?

I think we need things to be on several different levels. From plug-together
pre-made simple modules through modifiable EVB's to completely packaged high
end systems. All should have their place.

> Ultimately, we have to weigh up why kids aren't inspired to program today.

Which was the main crux of the original post on this thread. What kind of
projects would "Inspire a Generation" of the kids coming through schools
now. Whatever ideas come up we also need to remember that the teaching staff
in schools will also need some help in understanding what they are putting
to the kids and not only do we need kits but also good written material and
teaching support aids.

> Is it because computers aren't cheap enough (though even a netbook is 3x
> cheaper than a ZX Spectrum in today's money)? Or could it be something to
> do with them being 10,000 times more complex? Does FIGnition fit the STEM
> club criteria? (yes) Can you do a substantial amount of a GCSE computer
> studies on a FIGnition? (yes) Is FIGnition cute and fun? (you bet ;-) ) !

There are quite a number of cheap kits out there but which ones are most
suitable. There is the MSP430 Launchpad with 4E4th, which can be got up and
running for about 4 Euros, Arduino's and Raspberry Pi's to name a few. These
cover a range of complexity levels and may suit different age ranges. I
think something like the MSP Launchpad device needs a few kit board that
just plug onto it to give a range of different projects from the simple
starter kit. Judging by the cost constraints of many schools, these
additional boards will also need to be inexpensive.

Thanks for all the contributions so far.

--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>

[Bernd Paysan]

Paul Rubin wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>>> I don't think it
>>> would be feasible to implement anything like Code Hero with Forth.
>>> Forth has its own applicable areas that are somewhat different.
>>
>> What part of Code Hero would be impossible?
>
> The teaching part, if the idea is for kids to implement animated games
> with 3d graphics. They can't reasonably be expected to do that by
> writing low level Forth code.

What about writing high level 3d-turtle graphics code? Forth is not
about writing "dup swap + over !", it is about creating domain specific
programming languages. I found OpenGL to be "way too low-level" for me,
and therefore, I added a 3D turtle graphics in MINOS. It's an awful lot
easier to use than OpenGL.

> The underlying JS engine (written by
> experienced programmers) could of course in principle be done in
> Forth. Then you'd have to re-implement Unity3D and so on.

And what's the reason why this can't be done in Forth? Most things are
done in popular languages, because most people only know one of the
popular languages. This is a social reason why it hasn't been done in
Forth.

> Note that the existing JS that I know of that uses Forth (Tamarin
> Trace), I think uses Forth only as an intermediate form in a certain
> stage of compilation, with the main engine written in C++.

The JIT is written in Forth; the rest is written in C++. That's
probably because the JIT couldn't be written in C++, therefore they
resorted to Forth, not the other way round. There usually is a high
pressure to use "popular" languages both in open source and commercial
projects, and the rest of the browser is written in C++.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> What about writing high level 3d-turtle graphics code? Forth is not
> about writing "dup swap + over !", it is about creating domain specific
> programming languages.

I don't think they want turtle graphics (it's hard for me to understand
how 3D turtle graphics would mean). They want rendered, shaded robots
walking around on the screen, that they can replicate, vaporize, etc.

Anyway, Forth is supposedly an amplifier, helpful to the most skillful
programmers but obstructive to the rest. The idea of Code Hero is that
it teaches everyone to code. It aims to be an equalizer rather than an
amplifier. That's a different philosophy than Forth.

>> Then you'd have to re-implement Unity3D and so on.
> And what's the reason why this can't be done in Forth?

You'd have to ask the Forth programmers who aren't doing it.

> Most things are done in popular languages, because most people only
> know one of the popular languages. This is a social reason why it
> hasn't been done in Forth.

Other languages burn more machine resources to conserve programmer
effort. Most programmers consider this a usually-good trade. Forth
wins in the situations where it's not a good trade.

Take a look at some rubyquiz.com problems sometime, and ask how you
would do them if you were being paid per delivered solution. Of course
they can all be solved in Forth, but for the most part they can be
solved much more productively in other languages. (I did a few of them
as Haskell exercises).

>> (Tamarin Trace)

> The JIT is written in Forth; the rest is written in C++.

What do you mean by "the JIT is written in Forth"?

> That's probably because the JIT couldn't be written in C++, therefore
> they resorted to Forth, not the other way round.

If Forth was the language they "resorted to" rather than their first
choice, that fits the general picture of Forth's virtue as being able to
go to places where other languages can't, rather than it being able to
deliver comfort and style in the places where other languages can.

> There usually is a high pressure to use "popular" languages both in
> open source and commercial projects, and the rest of the browser is
> written in C++.

But they are aiming to rewrite the browser in a language (Rust) that
currently has even fewer users than Forth. They see Rust as having
enough technical advantages over C++ that it's worth the change. They
don't see Forth that way, it's pretty safe to say.

[theorigi...@gmail.com]

Hi Paul,

> > It's documented on the build-it page:
>
> > http://www.fignition.co.uk/documentation/build-it-rev-e
>
> > It's an AtMega168.
>
> I didn't see anything on that page identifying the part

From the page, 5th bullet point after the first image:

"• A plastic tube containing 3 chips: An AtMega168, a Microchip 23K640 8Kb SRAM and an AMIC A25L040-F 4Mbit Flash Chip..."

User's programs run Forth from Serial RAM, at speeds comparable with machine code on an 8-bit micro (60 to 300 KIPs).

Paul E Bennett wrote:

> > I think we need things to be on several different levels.

Indeed, I did qualify the previous paragraph in my post by saying "And how is it inspirational if every computer.."

> > There are quite a number of cheap kits out there but which ones are most

> > suitable. There are quite a number of cheap kits out there but which ones
> > are most suitable.

The question really is why don't kids program today and the key message with all the kits its that you need a multi-Giga everything to learn to program, because the microcontroller kits need a modern host computer and a Ras-Pi is a modern computer (albeit built from mobile phone components).

It's that assumption I think needs challenging. Whereas my generation could start programming within a second of powering on their computer this generation won't touch any code without having an incomprehensible underlying system behind it. It's true an MSP430 kit itself is simple, but the host/target environment isn't. Or rather, imagine if it was back in the early 80s and the ZX81 was becoming available, but instead of being able to turn it on and program it directly you needed to hook it up to a micro-VAX II supermini computer; learn its job control language and a DEC VAX Pascal to Z80 cross compiler before squirting your programs across serially to the Sinclair.

Would my generation have seen that setup as a hurdle? Yes, it's a massive hurdle at the system level, language level, development environment level and host-target level. And if the alternative was a pocket-VAX computer which worked the same way it'd still be pretty much the same challenge.

But this is what we're planning to deliver to today's kids; hardly anyone seriously questions whether its the sheer complexity of modern systems: the end-to-end environments we're offering that makes them a hindrance.

So, although simple doesn't always mean small-scale, in practice our large-scale systems and their associated environments are incomprehensibly complex... and we know that

(a) whereas a high proportion possibly at the high point, up to 25% of kids were learning to program to some degree in the 80s, less than 1% do today.

and (b) If I / we were faced with the VAX scenario I described above, it would count as a serious hurdle to learning to program.

Yet we still believe complex, modern systems are the only way.

> The computer game "Code Hero"
> teaches kids how to program 3D graphics games in Javascript (using those
> gigabytes and gigahertz) and is doing pretty well.

I've heard of MIT's Scratch; MS's Kodu and another Java-based (essentially a library) for teaching kids to code games. I hadn't heard of "Code Hero", so I'll have a look. Nevertheless, I'm scratching my head on why javascript would be a good intro for children's programming (it involves pretty complex syntax and semantics to begin with, wrapped inside another language and kids do have hurdles to get over when learning the syntax for arduino sketches, i.e. hurdles compared with learning Basic on an early 80s computer) and intuitively I'd guess it's mostly about plugging pre-written blocks of code together; because there must be a lot of work going on behind the scenes to mask the complexity of 3D graphic games. But I will have a look.

-cheers from julz

[Paul Rubin]

theorigi...@gmail.com writes:
> From the page, 5th bullet point after the first image:
> "• A plastic tube containing 3 chips: An AtMega168,

Aha, thanks, I was looking for the string "AVR".

> User's programs run Forth from Serial RAM,

I think you mean static ram (SRAM).

> this generation won't touch any code without having an
> incomprehensible underlying system behind it.

They now how to launch a browser. All the infrastructure under it is
buttoned up so it doesn't have to be comprehensible. Do you know how
the chips inside the Fignition work? It's the same thing.

> It's true an MSP430 kit itself is simple, but the host/target

> environment isn't.... DEC VAX Pascal to Z80 cross compiler before

> squirting your programs across serially to the Sinclair.

That presumes your goal is to program a remote embedded computer, which
I'd say is a fairly advanced topic. Beginning programmers are better
off programming their PC directly, in friendly coding environments with
good error reporting and so on.

> But this is what we're planning to deliver to today's kids; hardly
> anyone seriously questions whether its the sheer complexity of modern
> systems: the end-to-end environments we're offering that makes them a
> hindrance.

It's those kids who usually end up explaining computers to their
parents, so it can't be too much of a hindrance to them.

> So, although simple doesn't always mean small-scale, in practice our
> large-scale systems and their associated environments are
> incomprehensibly complex... and we know that

Surely a much more natural way would be allowing just talking to the
computer, like on Star Trek. That involves computers with speech
recognition, natural language understanding, etc. In other words, stuff
even more powerful and complex than the stuff you're complaining about,
so we don't have it yet.

> I hadn't heard of "Code Hero", so I'll have a look.

www.primerlabs.com/codehero .

> I'd guess it's mostly about plugging pre-written blocks of code
> together; because there must be a lot of work going on behind the
> scenes to mask the complexity of 3D graphic games.

It starts out that way. As you get deeper and deeper into it, you get
to see and modify what's making it actually work. The technical
implementation is very clever in how it lets you do that.

[theorigi...@gmail.com]

Hi Paul,

> Aha, thanks, I was looking for the string "AVR".
> > User's programs run Forth from Serial RAM,
> I think you mean static ram (SRAM).

The Microchip 23K640 is an 8-pin SPI Serial RAM chip which is run at 10MHz giving 0.9µs/byte read speeds and is pipelined with Forth instruction execution.

> > this generation won't touch any code without having an
> > incomprehensible underlying system behind it.

> They know how to launch a browser. All the infrastructure under it is

> buttoned up so it doesn't have to be comprehensible. Do you know how
> the chips inside the Fignition work? It's the same thing.

Yes, I actually do know how the chips work. I have a research degree in Computer Architecture from Manchester University and I do understand the purpose abstraction and encapsulation, nevertheless we make gross oversimplifications when we assume that because we've made computers easier to use then the abstractions somehow work for learning to code. If they were, we'd expect more kids to be coding than ever (because Javascript is only a click away), but in practice we find progressively fewer kids learn; and of those who do and go onto enter University to study Computer Science have a poorer grasp of coding and when they graduate, are on average just not as good.

It's easy to see why when you look. We think that wrapping the abstraction issue up with "launch a browser" deals with the question of user complexity, but it doesn't. When I launch Firefox I'm presented with a user environment that's actually pretty complex (compared with an early 80s machine). At that level, it's not, in truth, all hidden. If I then start to learn to code using Firefox and Javascript I'd head to the Tools menu which gives me 8 sub-options from "Web Developer" all of which present me with a development environment more complex than an early 80s micro on top of a language that's more complex. It's only a 'click' away and the tools are more 'powerful', but it's far more of a hurdle overall. I could of course go to a link where I'm presented with a wrapper for Javascript and learn it that way and again that's another layer I'd be going through in order to code. All of this, in every form, is more complex than for this generation of kids' forbears. They literally switched on a BBC micro and typed: 10 PRINT "I'm Fab!" <return> RUN which, by any measure is less of a hurdle.

> > It's true an MSP430 kit itself is simple, but the host/target
> > environment isn't.... DEC VAX Pascal to Z80 cross compiler before

> That presumes your goal is to program a remote embedded computer, which

Posters were comparing FIGnition with an MSP430 or Arduino in the previous post on the basis that they too were simple, I was arguing that they aren't, because the end-to-end environment is complex. FIGnition isn't a remote embedded machine and is as simple to code to, because you can use it and program it just like an early 80s computer.

> Beginning programmers are better
> off programming their PC directly, in friendly coding environments with
> good error reporting and so on.

The question is what constitutes a 'friendly coding environment'. Even modern kids oriented environments look friendly and glossy, but really they are sophisticated environments that present more practical end-to-end hurdles to learning programming than computers from previous generations.

> the end-to-end environments we're offering that makes them a
> > hindrance.

> It's those kids who usually end up explaining computers to their
> parents, so it can't be too much of a hindrance to them.

Again, this isn't actually true. Firstly, children are often able to explain how to *use* modern computers to their parents (though I think this is less the case than 20 years ago), but they aren't explaining computers themselves. Again it's the fallacy of conflating usability with comprehensibility, which is borne out because in fact 10x fewer kids today learn to code, compared with their parents. They're far more in love with tech, but far less able to code it, and this points to the opposite: modern tech is a hinderence in that respect.

> > So, although simple doesn't always mean small-scale, in practice our
> > large-scale systems and their associated environments are
> > incomprehensibly complex... and we know that
> Surely a much more natural way would be allowing just talking to the
> computer, like on Star Trek. That involves computers with speech
> recognition, natural language understanding, etc. In other words, stuff
> even more powerful and complex than the stuff you're complaining about,
> so we don't have it yet.

I'm not convinced. Modern systems are very usable, but importantly, unambiguous. Natural language processing for computers would make programming an ambiguous activity; it would involve the same problems as when customers specify systems to programmers. Besides, NLP is always a bit more complex than current tech ;-)

> It starts out that way. As you get deeper and deeper into it, you get
> to see and modify what's making it actually work. The technical
> implementation is very clever in how it lets you do that.

Well, I said I'd have a look, I'll do that at some point.

-cheers from julz

[Bernd Paysan]

Paul Rubin wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>> What about writing high level 3d-turtle graphics code? Forth is not
>> about writing "dup swap + over !", it is about creating domain
>> specific programming languages.
>
> I don't think they want turtle graphics (it's hard for me to
> understand how 3D turtle graphics would mean).

Then read it up. If you google for "3d turtle graphics", my papers on
the subject show up as item 2 and 3 (German/English) on Google.

> They want rendered, shaded robots
> walking around on the screen, that they can replicate, vaporize, etc.

Yes, that's the next layer up. It's quite easy to use the 3D turtle to
create animated objects; one of the examples I've written is an animated
swap dragon.

To create a game for children this thing certainly needs more polishing,
no argument about that.

> Anyway, Forth is supposedly an amplifier, helpful to the most skillful
> programmers but obstructive to the rest. The idea of Code Hero is
> that it teaches everyone to code. It aims to be an equalizer rather
> than an amplifier. That's a different philosophy than Forth.

I don't know what's wrong with you guys, you and Rod... Am I really
babbling gibberish? I said the essence of Forth is to create domain
specific languages. A teaching aid such as this game is a domain
specific language. You don't program the game in "low level Forth", you
program it in a domain specific language written in Forth that makes the
task easy to do.

Anyways, a friend of mine teaches Forth to young students, most of them
with learning difficulties. He succeedes. I don't think Forth is an
amplifier in the sense that it leaves bad programmers behind. It is an
amplifier in the sense that it makes people more productive, the vast
difference between good and bad programmers show up in every language,
not just Forth. It leaves people behind who are unwilling to learn,
because Forth is too different to them, and they already had a traumatic
experience of learning a difficult programming language.

This is all not the case with children. They haven't learned another
language before, and they are accepting everything, no matter how weird
you think it is.

>>> Then you'd have to re-implement Unity3D and so on.
>> And what's the reason why this can't be done in Forth?
>
> You'd have to ask the Forth programmers who aren't doing it.

I only know one single Forth programmer who writes 3D games in Forth:
Gerald Wodni. And he was rather new to Forth when he started writing
his game. It can be done, it is not even difficult when a novice can do
it. Again, I think I wrote gibberisch, because you didn't understand a
word of my rhetorical question.

*Of course* you have to reimplement something like Unity3D or a
framework with similar intent if you want to make 3D games in Forth. It
has been done, it can be done.

> Other languages burn more machine resources to conserve programmer
> effort. Most programmers consider this a usually-good trade. Forth
> wins in the situations where it's not a good trade.

We had some sort of this discussion with type systems. We here don't
think that a statically checked type system is a good trade-off.

> Take a look at some rubyquiz.com problems sometime, and ask how you
> would do them if you were being paid per delivered solution. Of
> course they can all be solved in Forth, but for the most part they can
> be solved much more productively in other languages. (I did a few of
> them as Haskell exercises).

I've seen such puzzles, they usually are done in a way to specify the
problems so that the built-in features of the language (like regexps)
make them easy to solve. You can have regexps with Forth (Gforth comes
with a regexp package), but you usually don't solve problems in Forth
with regexps all over the place.

However, looking at one of these puzzles shows that this isn't always
the case, like

http://rubyquiz.com/quiz69.html

There, one author uses PostScript to draw the solution (he actually
draws the spiral, not the rectangles):

0.8 0.4 0 setrgbcolor
newpath
0.0 0.0 moveto
5.0 0.0 5.0 180 90 arcn
5.0 0.0 5.0 90 0 arcn
0.0 0.0 10.0 0 -90 arcn
0.0 5.0 15.0 -90 -180 arcn
10.0 5.0 25.0 -180 -270 arcn
10.0 -10.0 40.0 -270 -360 arcn
-15.0 -10.0 65.0 -360 -450 arcn
-15.0 30.0 105.0 -450 -540 arcn
50.0 30.0 170.0 -540 -630 arcn
50.0 -75.0 275.0 -630 -720 arcn
-120.0 -75.0 445.0 -720 -810 arcn
stroke

This is a remarkable similar approach I would use to solve this problem
in Forth (I would probably use a much more regular output and rotate the
coordinate system by 90 degree each step to achieve this). And his
solution is touted as particularly interesting, even for the Ruby guys
there who don't know nothing about PostScript.

>>> (Tamarin Trace)
>> The JIT is written in Forth; the rest is written in C++.
>
> What do you mean by "the JIT is written in Forth"?

Is this difficult to understand? The code that transforms tokenized
JavaScript into machine code is written in Forth.

>> That's probably because the JIT couldn't be written in C++, therefore
>> they resorted to Forth, not the other way round.
>
> If Forth was the language they "resorted to" rather than their first
> choice, that fits the general picture of Forth's virtue as being able
> to go to places where other languages can't, rather than it being able
> to deliver comfort and style in the places where other languages can.

It's the comfort of "being at home". Many people *only* know one single
programming language, and don't feel at home with any other, and also
don't want to learn any other, because it was already too hard to learn
that single language.

You rarely see Forth in academia. You will get your C/C++/Java class
there (depending on your age, now it's Java), and that's it. Some
academic circles will teach you Scheme or Haskell, but very few will
teach you Forth; Forth is typically considdered as a "non-language" by
these academic types, because it has nothing of interest to them - no
syntax, no type system. It is just not complicated enough to study.

>> There usually is a high pressure to use "popular" languages both in
>> open source and commercial projects, and the rest of the browser is
>> written in C++.
>
> But they are aiming to rewrite the browser in a language (Rust) that
> currently has even fewer users than Forth. They see Rust as having
> enough technical advantages over C++ that it's worth the change. They
> don't see Forth that way, it's pretty safe to say.

Rust visually resembles C and Ruby, two very popular languages. They
feel at home. It's not that they have to relearn a lot. Rust has one
huge advantage over C++, and one that is very important considering the
main problem in Firefox is memory leaks: It has a garbage collector.

Yes, I agree that a garbage collector is probably the one single most
important feature any language or toolkit must have when you write a
browser in it. My approach would be to write a garbage collector as
part of the inevitable OOP system you also need for writing a browser.

Writing good Forth programs is not about "swap dup + over !", as I
already wrote. It's about writing the tools to make the actual
programming of the system easy, and about redefining the problem so that
writing the tools become easy. So you better use Forth for something
like net2o, where you can redefine how the syntax of the page looks
like, and you don't have to use HTML5. I think HTML is broken by
design, as witnessed by the many "simple" markup languages people have
invented since, which are more easy to write by humans and more easy to
process by computers.

Something roughly equivalent to JavaScript in terms of what you can
achieve with it (probably much more) would be a natural outcome of that
development. Probably with a "nice C-like syntax" to not alienate
people who only feel at home when they smell curly brackets and
semicolons.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>I think HTML is broken by
>design, as witnessed by the many "simple" markup languages people have
>invented since, which are more easy to write by humans and more easy to
>process by computers.

Which markup languages do you mean? I have used some web fora in
recent times that use BBCode, which is just HTML 2.0 (plus tables from
IIRC 3.2) with square instead of angle brackets. The idea here is
apparently that they want the user to be able to do some layout
markup, but they want a restricted what the users can do (not sure why
you need square brackets for that, though).

The main problem with HTML is that there are so many of them.

[Pablo Hugo Reda]

>
> Yes, I agree that a garbage collector is probably the one single most
>
> important feature any language or toolkit must have when you write a
>
> browser in it. My approach would be to write a garbage collector as
>
> part of the inevitable OOP system you also need for writing a browser.
>
>

if you need a garbage collector, sure you have a garbage generator.

IMHO forth not need GC or OOP.

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> with square instead of angle brackets. The idea here is
> apparently that they want the user to be able to do some layout
> markup, but they want a restricted what the users can do (not sure why
> you need square brackets for that, though).

Sanitizing HTML is very difficult. If they use angle brackets they have
to be ultra-careful that the user can't sneak something malicious
through the sanitizer. It's easier to just convert all < characters to
&lt; and do markup in a syntax that starts from zero and adds safe
capabilities, rather than starting with something dangerous and trying
to subtract from it. The syntax looks like HTML for the comfort of
users already familiar with HTML.

[Bernd Paysan]

Pablo Hugo Reda wrote:
> if you need a garbage collector, sure you have a garbage generator.

Of course you have, it's the web pages out there you load into your web
browser. They quickly become garbage when you move on to the next page.

> IMHO forth not need GC or OOP.

For some problems, they are the natural solution. I don't think you got
me: This is an *extension* to Forth within the application domain.
It's not part of the core of Forth.

[Bernd Paysan]

Anton Ertl wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>>I think HTML is broken by
>>design, as witnessed by the many "simple" markup languages people have
>>invented since, which are more easy to write by humans and more easy
>>to process by computers.
>
> Which markup languages do you mean?

All those attempts at Wikis, the YAML stuff and similar; there are tons
of them. Too many, as well.

> The main problem with HTML is that there are so many of them.

The main problem with HTML is that it is both unsuitable for humans to
write it nor for computers to parse it (the half-defective one the
humans are able to produce).

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> Then read it up. If you google for "3d turtle graphics", my papers on
> the subject show up as item 2 and 3 (German/English) on Google.

I get somewhat different search results but it did find your dragon
graphics article, which is nice. Thanks.

> I said the essence of Forth is to create domain specific languages...

> You don't program the game in "low level Forth", you program it in a
> domain specific language written in Forth that makes the task easy to do.

Well, I have to reserve judgment about how feasible this is until I
actually something like it. The dragon graphics article seemed to show
the low level Forth that I'm used to. In order to compare to Javascript
(or Python, Scheme, etc). the DSL would need:

- Some kind of OOP system (ok, this one has been done in Forth many times)
- Good runtime type checking (static checking not needed). For example,
passing the wrong number of args to a function should signal an error.
I think that doesn't fit so well into Forth's exposed-stack style.
- Garbage collection (Anton did this but I don't know if it's widely used)
- Convenient syntax for writing nested data structures

Lisp and JS do all of the above pretty well. It seems to me that if you
do it as a Forth DSL, it's not so Forth-like any more.

> This is all not the case with children. They haven't learned another
> language before, and they are accepting everything, no matter how weird
> you think it is.

I've heard similar things about Haskell, that it has a "steep unlearning
curve".

> *Of course* you have to reimplement something like Unity3D or a
> framework with similar intent if you want to make 3D games in Forth. It
> has been done, it can be done.

Well, I'd want to see an example so I can compare its sophistication to
something like Unity3D.

>> Other languages burn more machine resources to conserve programmer
>> effort. Most programmers consider this a usually-good trade.

> We had some sort of this discussion with type systems. We here don't
> think that a statically checked type system is a good trade-off.

Type systems are a rather different trade-off and I can understand
preferring dynamic types. I still use Python all the time myself.
Forth though has no machine-checked types at all, so you have to be very
careful to avoid type errors, or else spend a lot of time tediously
debugging.

>> Take a look at some rubyquiz.com problems sometime

> I've seen such puzzles, they usually are done in a way to specify the
> problems so that the built-in features of the language (like regexps)

Some of the rubyquiz problems are Ruby-specific but as you saw, others
are not particularly language-specific. A lot of them require some
reasonable features for handling strings, but that's what a lot of
non-embedded programming is like these days, so it can't be considered a
special feature. There are many things to dislike about C++ but it does
make handling strings easier than in C.

> http://rubyquiz.com/quiz69.html
> There, one author uses PostScript to draw the solution..

> This is a remarkable similar approach I would use to solve this problem
> in Forth

Yes that particular solution would be pretty workable in Forth.

>> What do you mean by "the JIT is written in Forth"?
> Is this difficult to understand? The code that transforms tokenized
> JavaScript into machine code is written in Forth.

Well, other meanings are possible, and my impression had been that Forth
was basically the intermediate language that got compiled, rather than
the implementation language of the compiler. I will have to take a
closer look. Of course it's possible to write a JIT compiler in C++ or
even in C. LuaJIT is exactly that.

> It's the comfort of "being at home". Many people *only* know one single
> programming language, and don't feel at home with any other,

Oh, I'd say if they were implementing Javascript in C++ then they must
know both of those languages pretty well. I'm really a bit puzzled
about why they would have written the JIT translator in Forth and
will have to check it out, it sounds interesting.

> You rarely see Forth in academia. You will get your C/C++/Java class
> there (depending on your age, now it's Java),

Java was a 1990's thing and I hope it's gone from academic curricula.
MIT switched from Scheme to Python, which is a good choice for
introductory programming. CMU uses ML, but it's aimed at CS students
who already have some programming knowledge.

> Rust visually resembles C and Ruby, two very popular languages...
> Rust has one huge advantage over C++,...: It has a garbage collector.

It's not just the curly braces and GC since Java has both of those.
Rust is really a more advanced language than Java or C++.

> Writing good Forth programs is not about "swap dup + over !"... So you

> better use Forth for something like net2o, where you can redefine how
> the syntax of the page looks like,

I've looked at net2o a little and it's interesting, but again it looks
like the low level Forth that I'm used to.

> I think HTML is broken by design, as witnessed by the many "simple"
> markup languages people have

You could google "naggum xml" but make sure there are no kids present ;-).

> Something roughly equivalent to JavaScript in terms of what you can
> achieve with it (probably much more) would be a natural outcome of that
> development. Probably with a "nice C-like syntax" to not alienate
> people who only feel at home when they smell curly brackets and
> semicolons.

Why not use Javascript directly in this case? I don't see what Forth
contributes to the picture.

[Bernd Paysan]

Paul Rubin wrote:
> Well, I have to reserve judgment about how feasible this is until I
> actually something like it. The dragon graphics article seemed to
> show the low level Forth that I'm used to.

You can always mix in the low level Forth in any DSL.

> In order to compare to
> Javascript (or Python, Scheme, etc). the DSL would need:
>
> - Some kind of OOP system (ok, this one has been done in Forth many
> times)

The 3D turtle is actually a class, and the functions are methods...

> - Good runtime type checking (static checking not needed). For
> example,
> passing the wrong number of args to a function should signal an
> error. I think that doesn't fit so well into Forth's exposed-stack
> style.

I did some significant effort to have all the frequently used words of
the 3D turtle take only one or two arguments. If you program with
typically 5-10 arguments per function, the automatic check is much more
vital. Don't do that.

> - Garbage collection (Anton did this but I don't know if it's widely
> used)

No, it's not widely used. Such a DSL would probably combine the OOP and
the GC, so that all objects are managed, and you still can program
"native unmanaged" code underneath.

> - Convenient syntax for writing nested data structures

Maybe, but I don't see why you would need them. You want animated
objects; these are *nested programs*, not *nested data structures*.

Lisp has the "program is data" meme. Forth has the opposite meme: "data
is program". In a typical Lisp program, you would have your robot
described something like this:

(body (left arm) (right arm) (left leg) (right leg))

In Forth, you write a program which draws the robot, you don't write an
interpreter for complex nested robot data structures. The program is
nested.

> Lisp and JS do all of the above pretty well. It seems to me that if
> you do it as a Forth DSL, it's not so Forth-like any more.

Forth DSLs don't have to be Forth-like.

>> This is all not the case with children. They haven't learned another
>> language before, and they are accepting everything, no matter how
>> weird you think it is.
>
> I've heard similar things about Haskell, that it has a "steep
> unlearning curve".

Indeed.

>> *Of course* you have to reimplement something like Unity3D or a
>> framework with similar intent if you want to make 3D games in Forth.
>> It has been done, it can be done.
>
> Well, I'd want to see an example so I can compare its sophistication
> to something like Unity3D.

You know that we don't do the "breakfast machine" in Forth. We try to
write to the point, not to all possible future extensions. We can
extend our systems as we go.

The homepage of Glforth (Gerald Wodni's game engine) is here:

http://www.complang.tuwien.ac.at/anton/lvas/stack-abgaben/07w/glforth/

> Type systems are a rather different trade-off and I can understand
> preferring dynamic types. I still use Python all the time myself.
> Forth though has no machine-checked types at all, so you have to be
> very careful to avoid type errors, or else spend a lot of time
> tediously debugging.

No, you just write your program piecemeal, and debug a few additional
word at a time. Furthermore, we don't really have that many types in
Forth, so the most likely confusion is between integers and floats.

> Some of the rubyquiz problems are Ruby-specific but as you saw, others
> are not particularly language-specific. A lot of them require some
> reasonable features for handling strings, but that's what a lot of
> non-embedded programming is like these days, so it can't be considered
> a special feature.

I probably would use string.fs from Gforth; it's not really difficult to
add reasonable string handling to Forth.

> There are many things to dislike about C++ but it
> does make handling strings easier than in C.

C is the horror in string handling ;-).

> Well, other meanings are possible, and my impression had been that
> Forth was basically the intermediate language that got compiled,
> rather than the implementation language of the compiler.

IIRC, it's sort-of both.

> I will have to take a
> closer look. Of course it's possible to write a JIT compiler in C++
> or even in C. LuaJIT is exactly that.

Maybe it's just a skill issue. When you look for people who know how to
compile code quickly at run-time, you will find more Forth programmers
than C programmers.

>> It's the comfort of "being at home". Many people *only* know one
>> single programming language, and don't feel at home with any other,
>
> Oh, I'd say if they were implementing Javascript in C++ then they must
> know both of those languages pretty well. I'm really a bit puzzled
> about why they would have written the JIT translator in Forth and
> will have to check it out, it sounds interesting.

As I said, it's probably a skill issue. Just look for people who have
experience in incrementally and quickly compiling code at run-time, and
you end up finding Forth implementers.

>> You rarely see Forth in academia. You will get your C/C++/Java class
>> there (depending on your age, now it's Java),
>
> Java was a 1990's thing and I hope it's gone from academic curricula.

TU Munich is still using Java for the introduction course. They say "or
similar", so probably you can get through with Python or so...

>> Rust visually resembles C and Ruby, two very popular languages...
>> Rust has one huge advantage over C++,...: It has a garbage collector.
>
> It's not just the curly braces and GC since Java has both of those.
> Rust is really a more advanced language than Java or C++.

Somewhat, yes. But it's still an ahead-of-time compiled language. I
don't consider ahead-of-time compiled languages (as only option) as
"advanced". Less retarded, maybe, is the right word.

>> Writing good Forth programs is not about "swap dup + over !"... So
>> you better use Forth for something like net2o, where you can redefine
>> how the syntax of the page looks like,
>
> I've looked at net2o a little and it's interesting, but again it looks
> like the low level Forth that I'm used to.

net2o still has only the network layer implemented. Nothing of the
higher level stuff I'm thinking about has become code yet.

>> I think HTML is broken by design, as witnessed by the many "simple"
>> markup languages people have
>
> You could google "naggum xml" but make sure there are no kids present
> ;-).

Hehe. Some words are pretty strong ;-).

I think the evolution of TeX has a remarkable teaching: Text markups
evolve to turing complete languages. TeX did. As did HTML, with the
addition of JavaScript and DOMs to the mess. Both became messy, because
both didn't anticipate what would happen. There were several attempts
to get TeX reimplemented in a real programming language that is also
available to escape to during the typesetting process itself; LuaTeX is
by far the most successful of these attempts (it actually is a very
usable TeX engine).

I'm usually not trying to reinvent wheels which are actually good. So
maybe I will just use Lua as the high level scripting language for
net2o.

[Paul Rubin]

theorigi...@gmail.com writes:
> The Microchip 23K640 is an 8-pin SPI Serial RAM chip

Oh, interesting, SRAM (term used in the web page) usually means "static".

> which is run at 10MHz giving 0.9µs/byte read speeds

Do you mean cycles per byte?

> If I then start to learn to code using Firefox and
> Javascript I'd head to the Tools menu which gives me 8 sub-options

Sure, that's a terrible way to code. Try something like Geany with
Python, or maybe Logo or something like that. I just mean it's easier
to program with something that manages low-level details for you (such
as memory allocation) more than Forth does.

> They literally switched on a BBC micro and typed: 10 PRINT "I'm Fab!"
> <return> RUN which, by any measure is less of a hurdle.

You're complaining about the boot-up delay of modern pc's? Yes it's
annoying, but people including kids are used to it. I just leave mine
running all the time (its idle power consumption is maybe 10W), partly
because it keeps my network connections open.

If I want to start a python environment (I use IDLE sometimes, a fairly
primitive IDE) I just click a toolbar icon and I bet it launches faster
than the BBC micro powers up. The startup delay is barely noticable,
maybe 1/4 of a second on my laptop (I'm sure the SSD helps).

> Posters were comparing FIGnition with an MSP430 or Arduino in the
> previous post on the basis that they too were simple, I was arguing
> that they aren't, because the end-to-end environment is
> complex. FIGnition isn't a remote embedded machine and is as simple to
> code to, because you can use it and program it just like an early 80s
> computer.

There are Forth environments like 4e4th that you can flash onto the
Launchpad or Arduino, and then just point a terminal at them. How is
Fignition different? And don't you have to boot your PC in order to
start the terminal program before you can type to the Fignition board?
Anyway, the professional Forth systems like Swift also operate as
cross-compilers to tethered targets, so that method still has virtues.

I still don't understand the notion that embedded boards are good for
learning programming as a raw beginner. They're good at the next level,
if you want to write low level code or control actual hardware.

> Even modern kids oriented environments look friendly and glossy, but
> really they are sophisticated environments that present more practical
> end-to-end hurdles to learning programming than computers from
> previous generations.

Have you ever seen Minecraft? It's a scriptable game, and kids get
fanatical about programming it. Code Hero is partly inspired by it.

[ken...@cix.compulink.co.uk]

In article <7x391ws...@ruckus.brouhaha.com>, no.e...@nospam.invalid

(Paul Rubin) wrote:

> They can't reasonably be expected to do that by
> writing low level Forth code.

Well HiSoft Forth came with turtle graphics and I remember versions of
Basic which included sprites and collision detection even IIRC one which
used 3D objects. There was also one or two MMRPG which used Forth as the
scripting language. I can remember when children were expected to
program in Logo.

Ken Young

[ken...@cix.compulink.co.uk]

In article <7xbogk7...@ruckus.brouhaha.com>, no.e...@nospam.invalid

(Paul Rubin) wrote:

> They want rendered, shaded robots
> walking around on the screen, that they can replicate, vaporize, etc.

I very much doubt that those are written from scratch there will be
some sort of of object editor. I have used Delphi and you do not need to
to program to design a user interface. You will need to code to various
bits like what to do with the input but the basic layout is drag and
drop and possibly altering properties with the property editor. The IDE
generates the code needed to actually display the form or forms.
WinForth also comes with a forms editor to simplify things.

Ken Young

[Paul Rubin]

ken...@cix.compulink.co.uk writes:
>> They want rendered, shaded robots

> I very much doubt that those are written from scratch there will be
> some sort of of object editor.

Yes, Unity3D. But there is a lot of programming possible in the game,
including low level programming. I last talked to the developers about
a year ago so I don't know how much of what they were considering
actually made it in. But there were some very audacious concepts on the
boards.

[Hugh Aguilar]

On Oct 2, 5:59 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Paul Rubin wrote:

> > Bernd Paysan <bernd.pay...@gmx.de> writes:
> >>> I don't think it
> >>> would be feasible to implement anything like Code Hero with Forth.
> >>> Forth has its own applicable areas that are somewhat different.
>
> >> What part of Code Hero would be impossible?
>
> > The teaching part, if the idea is for kids to implement animated games
> > with 3d graphics.  They can't reasonably be expected to do that by
> > writing low level Forth code.
>
> What about writing high level 3d-turtle graphics code?  Forth is not
> about writing "dup swap + over !", it is about creating domain specific
> programming languages.  I found OpenGL to be "way too low-level" for me,
> and therefore, I added a 3D turtle graphics in MINOS.  It's an awful lot
> easier to use than OpenGL.

One of my first programs for the C64 was a 4D turtle graphics program.
The turtle could move in W, X, Y and Z axis. The program showed a 3D
image with the parallel lines going to a vanishing point in the
background. It was possible however to rotate the perspective to see
the underlying 4D object from various angles.

I did that when I was 18 years old, so it should be possible for the
youths described in this Olympic Spirit project.

[Hugh Aguilar]

I totally agree --- GC and OOP are not for Forth. If you need GC or
OOP for your program, then Forth is the wrong language to be using.
There are much more appropriate languages.

Straight Forth will only be for micro-controller development (it will
include HostForth that runs on a desktop-computer, but the only
program ever written in HostForth will be the TargForth cross-
compiler). Straight Forth won't be a general-purpose language. I will
recommend Racket as a "sister language" for writing desktop-computer
software programs that are related to micro-controller programming
(typically utility programs for working with data that comes from or
goes into the micro-controller).

Using Forth on a desktop-computer makes about as much sense as using
Scheme on a 16-bit micro-controller --- none!

[theorigi...@gmail.com]

Hi Paul,

> > The Microchip 23K640 is an 8-pin SPI Serial RAM chip
> Oh, interesting, SRAM (term used in the web page) usually means "static".

They're usually referred to as Serial SRAM chips.

> > which is run at 10MHz giving 0.9µs/byte read speeds
> Do you mean cycles per byte?

9 cycles at 10MHz is 0.9µs. (9/10MHz = 0.9µs).

> > If I then start to learn to code using Firefox and
> > Javascript I'd head to the Tools menu which gives me 8 sub-options
> Sure, that's a terrible way to code. Try something like Geany with
> Python, or maybe Logo or something like that. I just mean it's easier
> to program with something that manages low-level details for you (such
> as memory allocation) more than Forth does.

Actually, you were claiming the complexity was hidden behind all the abstractions so coding is as easy as launching a browser. It's true that features like automatic memory allocation will help when coding, but the reality is that the end-to-end complexity is still the biggest hurdle the kids have to face. For example your alternative suggestions: Geany with Python / Logo etc illustrate my point. If all this complexity was truly hidden why would I want 'Geany' with Python? Surely Python would have hidden *all* the complexity and Geany would be unnecessary? Surely Python, given its size and level of abstraction, would be a better Logo than Logo?

The thing is that it must be our modern, complex systems that are the hurdle. Javascript used to be literally a menu-option away (View->Page Source, but now it's a sub-option), but kids just don't click it. I guess it's too much effort, but if they did, they'd be faced with a pretty hairy mass of script that'd put over 95% of them off. They don't then do a search for programming languages, find Python's already on their computer and drop down to a command line and then do another search to find tools to make its hostile interactive environment friendlier and then come across Geany or Logo or whatever.

> > They literally switched on a BBC micro and typed: 10 PRINT "I'm Fab!"
> > <return> RUN which, by any measure is less of a hurdle.
> You're complaining about the boot-up delay of modern pc's?

I think it's possible to see, given the context and the fact I didn't mention PC boot-up times, I'm talking about the overall, end-to-end level of complexity. Long boot up times are just symptomatic and keeping systems on sleep allieviate this somewhat, but the hurdles are still there, compared with early 80s systems. And early 80s systems were brilliant at getting kids to code; at least 10 to 20 x more effective than any combination of languages and environments on modern systems.

One would think that given the 'friendliness' and level of programmer help (e.g. code completion, syntax highlighting, abstraction, managed memory etc) and wads of resources, languages and IDEs that every kid would be a coder today, (if that was the key factor) because all these things are much better than they were.

But, the one major thing that's different is the complexity. Machines today are 10,000 times more complex and this complexity does leak into every aspect of computing from modern browsers to development environments and languages. Is it possible that this is the primary reason they don't code?

> If I want to start a python environment (I use IDLE sometimes, a fairly
> primitive IDE)

Wasn't it Geany a few seconds ago?

> There are Forth environments like 4e4th that you can flash onto the
> Launchpad or Arduino,

Or AmForth.

> .. And don't you have to boot your PC in order to

> start the terminal program before you can type to the Fignition board?

FIGnition, unlike embedded MCU boards like Launchpad or Arduino, is a whole, self-contained computer with a keypad for programming and video output and boots straight into its programming environment.

I thought it was obvious from the introductory paragraph on the FIGnition home page that with FIGnition you can code on its keypad, directly into the machine as you would with an early 80s micro.

However, on reflection, perhaps it's not obvious enough for some people.

> Have you ever seen Minecraft? It's a scriptable game, and kids get
> fanatical about programming it. Code Hero is partly inspired by it.

Minecraft can also emulate a 6502 using only a million times the resources of the original processor ;-)

-cheers from julz

[Elizabeth D. Rather]

On 10/3/12 10:00 PM, theorigi...@gmail.com wrote:
> Hi Paul,
>
>>> The Microchip 23K640 is an 8-pin SPI Serial RAM chip
>> Oh, interesting, SRAM (term used in the web page) usually means "static".
>
> They're usually referred to as Serial SRAM chips.

By whom? What could be "serial" about SRAM?

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."
==================================================

[Mark Wills]

In the 80's I was lucky enough to be surrounded by home computers in
my home. We first got a TI-99/4A, then a ZX spectrum, then a Commodore
64. Then an Amiga. At one point, we had a Spectrum, a C64, and an
Amiga 500 all at the same time.

With the execption of the Amiga, you could turn them on and be
programming in BASIC in around 1 second. I trudge to the newsagents
once a month and pick up Computer and Video Games (C&VG) and type in
the listings that always promised to be awesome, but were actually
kind of crap. Of course, they would be full of bugs, most type-setting
errors, so much of that month would be spent trying fix the program
that you spent 5 hours typing in. You learned to program. Okay, it was
"just" BASIC, but you learned to program. It was completely
fascinating - getting the computer to do what you wanted it to do.

I contrast that with my own son. He has been surrounded by PC's,
Laptops, Mobile 'phones, Playstations, Wii's and Xbox's. We've had
them all over the years.

He's never once shown even the slightest interest in programming. He
never once asked me how these games worked. I find it a little
strange. When I saw games like Manic Miner on the spectrum, I was
desperate to know *how* they worked. Sure, I enjoyed playing them, but
*I* want to do that too!

Last year, I showed him Forth. I was pretty jazzed that he understood
it. He understood the stack, he understood why + comes after two
numbers, and he 'got' colon definitions the first time I showed him. I
thought I had him. But no. He's not bothered with it since.

I've concluded it's down to paradigm shifts, and when they enter your
life: Perhaps a generation behind me, TV and Radio was the big
paradigm shift. My parents remember when they got their first TV in
the house. I *always* had a TV in my house, so TV and radio is very
"meh" to me. TV and Radio was a big thing to them. A significant
portion of the generation behind me are into HAM radio. My theory is
this is because it became big just when they were at the right age to
grab a hold of it. HAM radio is *their* 80's computers.

A gneration behind them, radio in general was their "80's computers".
They'd build crystal radio sets and it would often foster a life-long
association with radio, many of them progressing to building their own
valve radio sets, and perhaps having a career in electronics, just
like we tinkered with 80's computers and had a career in computers.

What is sad is, that I feel my children haven't really experienced any
big paradigm shift that shape their lives. There's the internet, but
they treat the internet like I treat TV: They grew up with it. It's
nothing special. It's always been there.

I worry for the graduate generation. WHen I worked at Serck Controls,
we'd get graduates who didn't really know what went on inside a
computer. They could program a little in Java. Maybe they wrote a Java
applet (remember those) once. They didn't know much about processors,
registers, assembly language.

THat's okay. You can teach people this stuff. But the really worrying
part is, they're just not that interested, thanks. I would ask them
about "do you wonder how the Java compiler that you're using works? Or
that C compiler?"

"Nah. Fuck that. Someone else's problem".

Someone else's *problem*. Sad.

Who going to write the next generation of compilers? Will it become a
more and more specialist 'art'/science?

Another worrying thing: In my school in the 80's ('85/'86) we actually
had a computer studies class. It was mandatory; part of the
curriculum. We learned BBC basic and wrote simple little programs.
That's all gone. My son recently studied how to make a CD label in his
computer class. Whoop de fucking doo.

[theorigi...@gmail.com]

Hi Elizabeth,

> >>> The Microchip 23K640 is an 8-pin SPI Serial RAM chip
> >> Oh, interesting, SRAM (term used in the web page) usually means "static".
> > They're usually referred to as Serial SRAM chips.
> By whom? What could be "serial" about SRAM?

The protocol used to access them. Microchip Serial SRAM chips use an SPI protocol, e.g. you'd select the chip (by asserting the /SS pin low), then clock in a command to read from a particular address, then the address, then start reading data - it'd get clocked out of the chip one bit at a time, incrementing to the next address after 8-bits until you send a new command. Thus it's Random Access, but serial.

-cheers from julz

> ==================================================

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> with square instead of angle brackets. The idea here is
>> apparently that they want the user to be able to do some layout
>> markup, but they want a restricted what the users can do (not sure why
>> you need square brackets for that, though).
>
>Sanitizing HTML is very difficult. If they use angle brackets they have
>to be ultra-careful that the user can't sneak something malicious
>through the sanitizer. It's easier to just convert all < characters to
>&lt; and do markup in a syntax that starts from zero and adds safe
>capabilities, rather than starting with something dangerous and trying
>to subtract from it.

Yes, that's the right approach, but it does not require square
brackets. I would write a parser that understands the desired HTML
subset and outputs it verbatim, and everything that the parser does
not grok is processed in the same way as BBcode does it (i.e.,
"<"->"&lt;"). This approach works equally well if I use angle
brackets or square brackets for my tags.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd....@gmx.de> writes:
>>>I think HTML is broken by
>>>design, as witnessed by the many "simple" markup languages people have
>>>invented since, which are more easy to write by humans and more easy
>>>to process by computers.
>>
>> Which markup languages do you mean?
>
>All those attempts at Wikis, the YAML stuff and similar; there are tons
>of them. Too many, as well.

I think that we probably would not have them if HTML had not become
way more complicated than HTML 2.0.

>> The main problem with HTML is that there are so many of them.
>
>The main problem with HTML is that it is both unsuitable for humans to
>write it nor for computers to parse it (the half-defective one the
>humans are able to produce).

Humans are able to produce fine HTML if they use tools that show
mistakes (unlike the popular browsers); and they are not able to
produce correct markup code in any notation if they are not given such
tools.

I also find HTML 2.0 pretty suitable to write, and computers have no
problems parsing it. Sure, it's a bit verbose (compared to, say,
LateX), but it's not too bad. A good-enough solution, at least in
these respects. But apparently it was not good enough for "web
designers"; it does not support design, just content.

[Bernd Paysan]

Anton Ertl wrote:
> I think that we probably would not have them if HTML had not become
> way more complicated than HTML 2.0.

People are notoriously bad at abstractions. They want WYSIWYG.
Therefore, these alternative markup languages provide features that a
bulleted list looks like

* item a
* item b

and an enumerated list is

1. first item
2. second item

and the syntax for headline is

headline
========

or

headline level 2
----------------

This sort of type-writer markup seems to be pretty easy to grasp.

I suggest if we had HTML2 and a WYSIWYG editor formular in every
browser, people wouldn't have seen a need for these more visually
pleasant markups. And it's still typewriter, it's still not at all 3rd
millennium technology.

>>> The main problem with HTML is that there are so many of them.
>>
>>The main problem with HTML is that it is both unsuitable for humans to
>>write it nor for computers to parse it (the half-defective one the
>>humans are able to produce).
>
> Humans are able to produce fine HTML if they use tools that show
> mistakes (unlike the popular browsers); and they are not able to
> produce correct markup code in any notation if they are not given such
> tools.

Yes, showing where you made a mistake is a good idea. But people are
much better at these visual markups, they do produce correct code much
more likely, because correct code is visually pleseant there. Incorrect
code isn't. That *does* matter.

> I also find HTML 2.0 pretty suitable to write, and computers have no
> problems parsing it. Sure, it's a bit verbose (compared to, say,
> LateX), but it's not too bad. A good-enough solution, at least in
> these respects. But apparently it was not good enough for "web
> designers"; it does not support design, just content.

Yes, and instead of supporting design (e.g. via CSS), they first
introduced a whole bunch of flashy additions to HTML.

The lession I learned from both LaTeX and HTML is:

* the content is in a free-form markup, i.e. you need to be flexible how
to parse your markup (one single markup notation won't do it)

* the flashy design must be done in a turing complete language,
separated from the content; the flashy designers want animations, they
want to control every pixel. Give them what they want, and make sure
that the content is separated from their design. You want to allow the
user to override the designers choice (what we now have as user-CSS).

I.e. you want to have

content <-> markup parser <-> internal, editable representation of the
content -> flashy display language using OpenGL+GLSL, video rendering,
etc. ("game engine") <- fonts, images, videos, and other resources which
can have a fixed, unflexible render pipeline, or a semi-flexible like
for vector graphics

[Paul Rubin]

theorigi...@gmail.com writes:
> 9 cycles at 10MHz is 0.9µs. (9/10MHz = 0.9µs).

Aha, somehow I didn't notice the "micro" symbol earlier.

> Actually, you were claiming the complexity was hidden behind all the
> abstractions so coding is as easy as launching a browser.

The browser launching example just meant that a lot of complex stuff can
be happening behind the scenes, without the complexity bothering the
user as long as they don't have to deal it directly.

> the reality is that the end-to-end complexity is still the biggest
> hurdle the kids have to face.

Maybe you could say exactly what you mean by "end-to-end complexity".
I'm interpreting it to mean all the complexity that exists in the entire
path from one end to the other, since you're advocating dealing with it
through a very simple implementation. I instead believe that the
complexity exposed at the endpoints matters, but the complexity buttoned
up in the middle doesn't matter as long as it works reliably.

As other examples, consider navigating to some location with map and
compass, compared to using a GPS. Or compare travelling someplace to
deliver a message, compared to emailing the person or using your cell
phone. Do you see what I'm getting at? The buttoned-away complexity of
the GPS system and internet/phone networks is enormous, but they really
do make the exposed part of the task simpler.

> For example your alternative suggestions: Geany with Python / Logo etc
> illustrate my point. If all this complexity was truly hidden why would
> I want 'Geany' with Python?

Geany is a fancy IDE sort of like Eclipse, that handles multiple
languages. I've seen it and it looks nice. I don't personally use it
because the stuff I'm used to (Emacs and IDLE) work well enough that I'm
content to keep using them from familiarity and inertia, but people just
getting started should probably consider alternatives, so I mentioned
Geany.

> Surely Python would have hidden *all* the complexity and Geany would
> be unnecessary?

Python is a language, not a complete environment. The CPython
distribution does come with an IDE written in Python, namely IDLE, but
it's less powerful than fancier ones like Geany. I prefer to use Emacs
for complex development but I know that some programmers like fancy
IDE's. I do sometimes use IDLE for quick experiments and such.

> Surely Python, given its size and level of abstraction, would be a
> better Logo than Logo?

I've never personally used LOGO but I know it's gotten some traction for
teaching little kids. Python might be a bit too complicated.

> And early 80s systems were brilliant at getting kids to code; at
> least 10 to 20 x more effective than any combination of languages and
> environments on modern systems.

How many kids today do you think are coding in Minecraft, compared with
"early 80s systems"? How many do you think are using computers now
compared with the early 80s? Another theory is that both now and then,
kids liked using computers, but in the early 80's the only thing they
could really do with them was code, and today there's far more
possibilities. So that may explain the difference in coding interest,
rather than coding having somehow become more complex.

>> (I use IDLE sometimes, a fairly primitive IDE)
> Wasn't it Geany a few seconds ago?

No, I mentioned Geany but I don't personally use it, as explained above.

> I thought it was obvious from the introductory paragraph on the
> FIGnition home page that with FIGnition you can code on its keypad,
> directly into the machine as you would with an early 80s micro.

No, that's not mentioned. It says there is an 8-key keypad and I see 8
tiny pushbuttons on the PC board pictured, but the idea of entering code
that way wouldn't have occurred to me. It frankly sounds nuts: 80's
micros (Commodore 64 say) at least had real keyboards. I also don't
know about the composite video port--I don't know if modern TV sets
still have composite video input.

> Minecraft can also emulate a 6502 using only a million times the
> resources of the original processor ;-)

You know, that Atmega part in the Fignition purports to be an 8-bit
micro that's sort of a modernized 6502, but how do you know it's not
really a much faster x86 core, running firmware that emulates the AVR
instruction set, eh? ;-)

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> In Forth, you write a program which draws the robot, you don't write an
> interpreter for complex nested robot data structures. The program is
> nested.

So what do you do if you want to describe a few different robots in the
program? Write separate programs for each?

>> compare its sophistication to something like Unity3D.
> You know that we don't do the "breakfast machine" in Forth. We try to
> write to the point, not to all possible future extensions. We can
> extend our systems as we go.

But all the features in Unity3D are there because somebody wanted them.
And if you're making a toolkit for other people to use, I think you
really do have to anticipate their requirements.

> The homepage of Glforth (Gerald Wodni's game engine) is here:
> http://www.complang.tuwien.ac.at/anton/lvas/stack-abgaben/07w/glforth/

This looks nice.

>> Forth though has no machine-checked types at all... spend a lot of time

>> tediously debugging.
> No, you just write your program piecemeal, and debug a few additional
> word at a time.

But then you end up modifying the code and that usually introduces
errors, so you're back to debugging.

> Furthermore, we don't really have that many types in
> Forth, so the most likely confusion is between integers and floats.

Don't forget addresses and xt's, which are easy to get confused with
data. And I don't think Forth's lack of strings, arrays, associative
tables, closures, etc. help its attractiveness to programmers used to
such newfangled conveniences.

> I probably would use string.fs from Gforth; it's not really difficult to
> add reasonable string handling to Forth.

I'd think reasonable string handling absolutely has to use garbage
collection (or at least, C++-style finalization on exit from a scope) to
clean up the intermediate results of complex string manipulation.
If strings.fs does that then it's interesting.

> As I said, it's probably a skill issue. Just look for people who have
> experience in incrementally and quickly compiling code at run-time, and
> you end up finding Forth implementers.

Oh come on, there just aren't that many Forth programmers. Lisp systems
have done on-the-fly compilation since the dawn of time, Java probably
uses the best-known JIT, etc.

>> Rust is really a more advanced language than Java or C++.
> Somewhat, yes. But it's still an ahead-of-time compiled language. I
> don't consider ahead-of-time compiled languages (as only option) as
> "advanced". Less retarded, maybe, is the right word.

Meh, once you've got a fast build system (maybe not possible for certain
styles of C++ but quite reasonable for other languages), ahead-of-time
is fine.

> I'm usually not trying to reinvent wheels which are actually good. So
> maybe I will just use Lua as the high level scripting language for
> net2o.

Probably a reasonable choice. Lua has some traction, has a very nice
embeddable implementation, and is lightweight and efficient. I'm not
that crazy about the Lua language itself but I think alternatives
(mostly Lisp-based, like Guile) will probably stay unpopular.

[Bernd Paysan]

Paul Rubin wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>> In Forth, you write a program which draws the robot, you don't write
>> an
>> interpreter for complex nested robot data structures. The program is
>> nested.
>
> So what do you do if you want to describe a few different robots in
> the program? Write separate programs for each?

Why not? What would you do when you describe robots in a data
structure? Write a separate data structure for each? Of course. You
can factor complex data structures, and you can factor complex programs.
If you think there is a substantial difference between a program and a
sufficiently complex data structure, you just don't get it.

You can have a robot with

4 red arms
green cylinder body
4 black wheels

Is this a data structure or a program? I don't know, I don't care. To
draw the robot, you have to interpret the data structure or to execute
the program.

> But all the features in Unity3D are there because somebody wanted
> them. And if you're making a toolkit for other people to use, I think
> you really do have to anticipate their requirements.

Hm, again, Forth philosophy is slightly different.

a) you don't anticipate future needs (you only take current needs into
account) and
b) you don't bury your tools

This b) is actually done to anticipate future needs *the right way*. If
I make a toolkit, and make sure you can't access *my* tools, I have to
anticipate what you will need, and implement all of that. If I give you
my toolkit-building tools, you can implement your stuff, even though I
didn't anticipate it. I wrote something which allows to easily draw
robots and let them move through a maze, and you use the tools to draw
robots to instead draw plants and flowers, and let the user manage his
or her garden.

>> No, you just write your program piecemeal, and debug a few additional
>> word at a time.
>
> But then you end up modifying the code and that usually introduces
> errors, so you're back to debugging.

I try to make these modifications one little piece at a time, and then
test it, as well. If I don't, if I do a big lump of changes, chances
are high that it doesn't work, and that getting out of that mess takes
more time than unrolling all the changes, and doing them one little step
at a time.

git bisect even automates this sort of debugging - when you have an
automated test for it. It's clearly not unique to Forth. Having
automated tests for the features that already work is a good idea.

I think someone like you, with a good grasp for formal methods, should
look at John Hayes ttester (in Gforth under test/ttester.fs; the
examples in the test directory are of more value than the source code
itself). You complained that Forth doesn't check stack effects. Well,
just add a check yourself:

require test/ttester.fs

: bounds ( addr len -- last first ) over + swap ;
t{ 3 5 bounds -> 8 3 }t

For words with no side-effect, you can simply leave these tests in the
code. When you introduce an error, you see it when you compile next
time.

>> Furthermore, we don't really have that many types in
>> Forth, so the most likely confusion is between integers and floats.
>
> Don't forget addresses and xt's, which are easy to get confused with
> data.

Addresses and xts *are* integers. And they do point to some other data,
which you can inspect - in an ITC Forth, even portably among different
ITC systems (Gforth's stepping debugger works only on Gforth-ITC,
because it uses this fact).

> And I don't think Forth's lack of strings, arrays, associative
> tables, closures, etc. help its attractiveness to programmers used to
> such newfangled conveniences.

Most desktop Forth systems will provide you with most of those features.
There's even a package for closures based on mini-oof, which passes
Knuth boy-or-men test.

If you haven't found Forth strings, arrays, hash tables, etc., by now,
it's because you were looking at an embedded Forth, where all these
features just don't fit.

>> I probably would use string.fs from Gforth; it's not really difficult
>> to add reasonable string handling to Forth.
>
> I'd think reasonable string handling absolutely has to use garbage
> collection (or at least, C++-style finalization on exit from a scope)
> to clean up the intermediate results of complex string manipulation.
> If strings.fs does that then it's interesting.

string.fs uses a transformation model rather than a creation model.
I.e. all you have are global string variables. Most string
manipulations aren't complex, they usually are either adding things to
the end of a string, or search/replace passes through the string, which
transform the string.

Other people have suggested and implemented string stacks. That works
even for cases where you need to create string objects dynamically, but
with a limited scope (like this C++-style finalization). You finally
have to drop it off the string stack when you leave the scope.

>> As I said, it's probably a skill issue. Just look for people who
>> have experience in incrementally and quickly compiling code at
>> run-time, and you end up finding Forth implementers.
>
> Oh come on, there just aren't that many Forth programmers. Lisp
> systems have done on-the-fly compilation since the dawn of time, Java
> probably uses the best-known JIT, etc.

Java's VM has a direct ancestral line to Forth, because Goslin worked on
Postscript before (and Postscript is highly influenced by Forth).

In any case: JavaScript *is* a Lisp, apart of the syntax. It would be
far more natural that the JavaScript engines would use Lisp compilation
techniques, which have been there since the dawn of time. It doesn't,
for whatever reason. Two out of four state-of-the-art JS engines use
Forth. None uses Lisp (ok, we don't know about Microsoft's, this is the
one closed source state-of-the-art JS engine). And there are probably
more Lisp programmers around. But for them, the on-the-fly compiler is
an "others people problem". For a Forth programmer, the compiler isn't.
This is a consequence of "don't bury your tools" philosophy. Therefore,
while you find less Forth programmers than Lisp programmers, you will
find more Forth programmers who can help you to implement a JIT.

Or Forth-influenced programmers who did work on other JITs like JVM.
They are Forth-influenced, because JVM is Forth-influenced.

>>> Rust is really a more advanced language than Java or C++.
>> Somewhat, yes. But it's still an ahead-of-time compiled language. I
>> don't consider ahead-of-time compiled languages (as only option) as
>> "advanced". Less retarded, maybe, is the right word.
>
> Meh, once you've got a fast build system (maybe not possible for
> certain styles of C++ but quite reasonable for other languages),
> ahead-of-time is fine.

Well, most of what you write in Forth is compiled ahead-of-time, too.
However, the good thing is that you aren't limited to that, and you can
do on-the-fly stuff whenever necessary. Like when running simple test
cases as part of the ahead-of-time compilation (shown above), or when
trying out new functions interactively on the terminal. And when
extending the system with features you think are lacking.

>> I'm usually not trying to reinvent wheels which are actually good.
>> So maybe I will just use Lua as the high level scripting language for
>> net2o.
>
> Probably a reasonable choice. Lua has some traction, has a very nice
> embeddable implementation, and is lightweight and efficient. I'm not
> that crazy about the Lua language itself but I think alternatives
> (mostly Lisp-based, like Guile) will probably stay unpopular.

Though Lua does away with most of the curly braces and the semicolons,
and even has multiple return values.

[Elizabeth D. Rather]

On 10/4/12 9:41 AM, Paul Rubin wrote:
> Bernd Paysan <bernd....@gmx.de> writes:
>> In Forth, you write a program which draws the robot, you don't write an
>> interpreter for complex nested robot data structures. The program is
>> nested.
>
> So what do you do if you want to describe a few different robots in the
> program? Write separate programs for each?

Having built one robot, you should have a bunch of high-level robot
tools that you can use for the next. You'll probably add a few and
refine the existing ones; so with every robot you build your toolkit
becomes more powerful and more efficient.

>>> compare its sophistication to something like Unity3D.
>> You know that we don't do the "breakfast machine" in Forth. We try to
>> write to the point, not to all possible future extensions. We can
>> extend our systems as we go.
>
> But all the features in Unity3D are there because somebody wanted them.
> And if you're making a toolkit for other people to use, I think you
> really do have to anticipate their requirements.

It should be possible to design your toolkit at the outset with some
known requirements. But before it can be released, you had better use it
to build a bunch of robots, and get a few other "test users" to build
some, in order to verify that you have the right tools and they work in
the way you intended. In this process you'll almost certainly find that
a lot of your initial expectations weren't quite right.

What does *not* work is to look at other products and design something
to complete, implement that design, and then release it without actually
using it (and having some other folks use it).

>> The homepage of Glforth (Gerald Wodni's game engine) is here:
>> http://www.complang.tuwien.ac.at/anton/lvas/stack-abgaben/07w/glforth/
>
> This looks nice.
>
>>> Forth though has no machine-checked types at all... spend a lot of time
>>> tediously debugging.
>> No, you just write your program piecemeal, and debug a few additional
>> word at a time.
>
> But then you end up modifying the code and that usually introduces
> errors, so you're back to debugging.

Sure, all software development is an iterative process. You build some
tools, test them, and then when you use them you find you wish they work
slightly differently. So you make the mods and use them to take the next
steps. Fortunately, the change/test cycle is so short and so easy in
Forth it's far from tedious.

>> Furthermore, we don't really have that many types in
>> Forth, so the most likely confusion is between integers and floats.
>
> Don't forget addresses and xt's, which are easy to get confused with
> data. And I don't think Forth's lack of strings, arrays, associative
> tables, closures, etc. help its attractiveness to programmers used to
> such newfangled conveniences.

I have worked on a bunch of robotics projects in past years. I've never
found confusion of data types to be a problem. As we've discussed
elsewhere, it's trivial to define exactly the kinds of arrays you need.
As for strings, the main thing you encounter in robotics is sequences of
command codes, which are easily defined using the words we already have.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> 4 red arms
> green cylinder body
> 4 black wheels
>
> Is this a data structure or a program? I don't know, I don't care. To
> draw the robot, you have to interpret the data structure or to execute
> the program.

I'd rather that it be data since then I can write code to interpret the
data in multiple ways, and it helps to be able to write data before
starting to write code. E.g. in Python:

programmers = [
{'name':'Bernd' 'languages':['Forth','C']},
{'name':'Elizabeth','languages':['Forth','Fortran']},
{'name':'Paul','languages':['Python','Forth']}
]

I can type that directly into Python and have it create a nested data
structure, without having to write and debug any specialized code. If I
then want to be able to find the users of a given language, I can then
say (e.g.):

def lang_users(lang):
return [p['name'] for p in programmers if lang in p['languages']]

Then to find the Forth users:

>>> print lang_users('Forth')
['Bernd', 'Elizabeth', 'Paul']

This is much harder in languages without such syntax, such as Java. It
has to be done instead with code usually described as "boilerplate" in
an uncomplimentary way.

> If I make a toolkit, and make sure you can't access *my* tools, I have
> to anticipate what you will need, and implement all of that. If I
> give you my toolkit-building tools, you can implement your stuff,

If I'm supposed to implement such stuff myself, why do I want your
toolkit in the first place? Obviously as a FOSS user I want to be able
to extend the toolkit as a last resort, and obviously in the first
releases of a toolkit, the important use cases haven't necessarily been
identified. But after a few iterations I'd expect the toolkit to do
pretty much everything needed, and modularity makes me not want to
maintain my own fork if I can help it.

> I try to make these modifications one little piece at a time, and then
> test it, as well.

OK, so you make a small modification and create a bug, which makes your
test fail. What now? You have to figure out the cause of the bug.
And, I think, this is much easier in a (runtime) type-checked and
bounds-checked language, than something like Forth.

> look at John Hayes ttester (in Gforth under test/ttester.fs;

> require test/ttester.fs
> : bounds ( addr len -- last first ) over + swap ;
> t{ 3 5 bounds -> 8 3 }t

Oh this is nice, and I didn't know about it. I'm going to start using it.

> You complained that Forth doesn't check stack effects. Well, just add
> a check yourself

That's nice for checking at the function definition, but what about
making sure the callers always pass the right stuff?

> Addresses and xts *are* integers.

No really, multiplying two integers is a sensible arithmetic operation;
multiplying two pointers is not.

> If you haven't found Forth strings, arrays, hash tables, etc., by now,
> it's because you were looking at an embedded Forth, where all these
> features just don't fit.

I'm using gforth and I didn't notice any of that in the manual.

> string.fs uses a transformation model rather than a creation model.
> I.e. all you have are global string variables. Most string
> manipulations aren't complex, they usually are either adding things to
> the end of a string, or search/replace passes through the string, which
> transform the string.

Even this sounds like it needs GC.

> It would be far more natural that the JavaScript engines would use
> Lisp compilation techniques,

I think historically, Lisp compilers didn't use tracing JIT's. You'd
write the inner loops of your Lisp program to use known types if you
could, and the compiler would rely on programmer annotations or type
inference to generate optimized code for the types. In cases where the
types were unknown, you'd get runtime dispatch and an efficiency hit.

Today, PyPy, LuaJIT, and the JS compilers all use tracing, so I guess
the trade-offs have changed.

> Though Lua does away with most of the curly braces and the semicolons,
> and even has multiple return values.

My gripe with Lua mostly has to do with the looseness of the type
system, compared to Lisp or even Python.

[Elizabeth D. Rather]

On 10/4/12 3:11 PM, Paul Rubin wrote:
>> You complained that Forth doesn't check stack effects. Well, just add
>> >a check yourself
>
> That's nice for checking at the function definition, but what about
> making sure the callers always pass the right stuff?

A data type check certainly doesn't guarantee you've got the "right
stuff." The only meaningful check is for reasonable range. And the place
to check that is right where the data enters the system (user interface,
device register, etc.), not repetitively in each word, unless
temporarily while trying to track down some stubborn bug.

>> >Addresses and xts*are* integers.

>
> No really, multiplying two integers is a sensible arithmetic operation;
> multiplying two pointers is not.

That would be a programming mistake, and one that would be pretty obvious
early in the test cycle.

I realize that programmers who have felt comforted by syntax/data type
checking compilers feel a little naked getting used to Forth, but with a
little experience you'll understand the Forth programming/testing cycle
and feel more comfortable.

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:
> A data type check certainly doesn't guarantee you've got the "right
> stuff."

This was about stack effect, or correspondingly (in other languages)
making sure that the caller passed the right number of args to the
callee.

> I realize that programmers who have felt comforted by syntax/data type
> checking compilers feel a little naked getting used to Forth, but with
> a little experience you'll understand the Forth programming/testing
> cycle and feel more comfortable.

I've written enough C code in my life to appreciate the difference
between having to find the bug by examining the state of memory with
gdb, and having the Python (etc.) interpreter tell me "wrong number of
args at line 237, called from line 415", showing the source code at each
of those two lines. I see the mismatch, say "oops" and fix the code.
(# of args isn't a good example of this, since C checks that statically,
but you get the idea).

[A. K.]

One of my first Forth programs in my life was assert( .. )
which pretty much worked like Hayes T{ .. }.
I used to use assert( a lot in the beginning. Today my preferred way of
coding critical code sections is still with paper, pencil, and rubber
gum. :-)

[Gerry Jackson]

On 05/10/2012 02:11, Paul Rubin wrote:
>> I try to make these modifications one little piece at a time, and then
>> test it, as well.
>
> OK, so you make a small modification and create a bug, which makes your
> test fail. What now? You have to figure out the cause of the bug.
> And, I think, this is much easier in a (runtime) type-checked and
> bounds-checked language, than something like Forth.

This is made easier by using a test file - see below

>
>> look at John Hayes ttester (in Gforth under test/ttester.fs;
>> require test/ttester.fs
>> : bounds ( addr len -- last first ) over + swap ;
>> t{ 3 5 bounds -> 8 3 }t
>
> Oh this is nice, and I didn't know about it. I'm going to start
using it.
>

Even better are further developments of it by David Williams and Josh
Grams. See
http://www-personal.umich.edu/~williams/archive/forth/utilities/xtester.fs
and associated files and
http://qualdan.com/forth/flex-tester-2012-05-30.tar.gz

These were written for application program development rather than Forth
system testing which was the original aim of the Hayes tester.

Like some others I routinely use a tester like this when writing a
program larger than a few words that I intend to maintain and use. After
all you only have to type a simple test once into a text file instead of
continually typing the same thing when manually testing at the keyboard.
Then just start the Forth up with a command line that includes the test
file - a simple double click in an IDE.

If such a test program is continually added to during development, you
have a regression test available when you've finished. This test program
can then be provided with the program for users e.g. see files
dstrings.fs and dstrings-test.fs at
www-personal.umich.edu/~williams/archive/forth/strings/
dstrings is a strings package with garbage collection - something you
mentioned as being desirable.

--
Gerry

[Elizabeth D. Rather]

On 10/4/12 3:54 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>> A data type check certainly doesn't guarantee you've got the "right
>> stuff."
>
> This was about stack effect, or correspondingly (in other languages)
> making sure that the caller passed the right number of args to the
> callee.

Since DEPTH returns the number of things on the stack, you could test
that. However, since the actual stack depth at any point is
context-dependent (i.e., you never know which things on the stack are
actually parameters for other words, not *this* one), that is strictly a
early-stage debugging tool.

But this is why many systems (including SwiftForth, SwiftX, etc.) have
stack-monitoring facilities. In early-stage testing, if you have a word
that is misbehaving you can type your way through it or use a stepper
and watch the stack behavior.

Such tools are "quality of implementation" issues, not language issues.

>> I realize that programmers who have felt comforted by syntax/data type
>> checking compilers feel a little naked getting used to Forth, but with
>> a little experience you'll understand the Forth programming/testing
>> cycle and feel more comfortable.
>
> I've written enough C code in my life to appreciate the difference
> between having to find the bug by examining the state of memory with
> gdb, and having the Python (etc.) interpreter tell me "wrong number of
> args at line 237, called from line 415", showing the source code at each
> of those two lines. I see the mismatch, say "oops" and fix the code.
> (# of args isn't a good example of this, since C checks that statically,
> but you get the idea).

Different Forths have different programming aids, as I said above. I
suggest you evaluate several different systems as regards programming aids.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>Bernd Paysan <bernd....@gmx.de> writes:
>> 4 red arms
>> green cylinder body
>> 4 black wheels
>>
>> Is this a data structure or a program? I don't know, I don't care. To
>> draw the robot, you have to interpret the data structure or to execute
>> the program.
>
>I'd rather that it be data since then I can write code to interpret the
>data in multiple ways, and it helps to be able to write data before
>starting to write code. E.g. in Python:
>
>programmers = [
> {'name':'Bernd' 'languages':['Forth','C']},
> {'name':'Elizabeth','languages':['Forth','Fortran']},
> {'name':'Paul','languages':['Python','Forth']}
>]
>
>I can type that directly into Python and have it create a nested data
>structure, without having to write and debug any specialized code.

This reminds me of what I do with data in charts written in Postscript.

In simple cases, the data is interpreted directly and drawn right away:

%trad
1
3040561373
3042635978
3043166570
3 copy median3 /scalefactor swap def
median3point mt
%doprims
3106897257
3103339195
3106836628
median3point lt

In more complex cases I put the data in arrays and drawn them later:

/compress
[ 0.0
0.0
29.3
41.5
29.3
0.0
0.0
] def
...
[ /compress /jess /db /javac /mpegaudio /mtrt /jack ]
{ << /bench rot >> begin bars end } forall

Finally, I put the data in procedures that can be used to draw things
or build arrays from the data several times in different ways, if
needed:

/core2 { %smaug
[
100383730 event0x0041008D@0
5370 event0x0041008E@1
5638338384 event0x00410000@0x40000000
3251152763 event0x00410000@0x40000001
100381820 event0x0041008D@0
5180 event0x0041008E@1
1638276480 event0x00410000@0x40000000
840453768 event0x00410000@0x40000001
(primitive) oneword
2400384720 event0x0041008D@0
300006874 event0x0041008E@1
7938302989 event0x00410000@0x40000000
9241083370 event0x00410000@0x40000001
400381976 event0x0041008D@0
5822 event0x0041008E@1
1938271683 event0x00410000@0x40000000
940217000 event0x00410000@0x40000001
(code-def) oneword
...
] /default oneforth
....
} def

/scalefactor 2000000000 def

/oneforth {load exec} def
/oneword {drop sub scalefactor div} def
%select none by default, later change one event and one forth from default
/event0x0041008D@0 {drop} def
/event0x0041008E@1 {drop} def
/event0x00410000@0x40000000 {drop} def
/event0x00410000@0x40000001 {drop} def
/tsc {drop} def
/event0x004100C0 {drop} def
/event0x004100C4 {drop} def
/event0x004100C5 {drop} def
...
<< /results {core2} /event0x00410000@0x40000000 {} >> bars

This selects the event0x00410000@0x40000000 records from the data and
draws a set of bars (for a bar chart). I guess I had to write _and
debug_ all these event* procedures before running the program
successfully. So what. The actual work was elsewhere.

These three steps are actually the evolution of how I write these
charts. The main driver here was to minimize the manual work for
integrating the data coming out of my measurement scripts into the
charts.

>If I'm supposed to implement such stuff myself, why do I want your
>toolkit in the first place? Obviously as a FOSS user I want to be able
>to extend the toolkit as a last resort, and obviously in the first
>releases of a toolkit, the important use cases haven't necessarily been
>identified. But after a few iterations I'd expect the toolkit to do
>pretty much everything needed, and modularity makes me not want to
>maintain my own fork if I can help it.

Yes, Knuth expected users to do their own forks of TeX for specialized
purposes, but this has not really happened, even though there is no
evolution of TeX to speak of (so merging changes back into the fork
would not have been an issue). People just don't want to much with
the internals of an existing program.

OTOH, the success of applications that support scripting and add-ons
shows that, no, you cannot expect a program to do everything that's
needed out of the box, even after a few iterations. So people are
willing to program extensions given a defined interface (e.g., various
packages on top of TeX, such as LaTeX, instead of a fork of TeX).

>OK, so you make a small modification and create a bug, which makes your
>test fail. What now? You have to figure out the cause of the bug.
>And, I think, this is much easier in a (runtime) type-checked and
>bounds-checked language, than something like Forth.

For a small modification, the bug is usually obvious. How can
something else be easier.

Debugging Forth code is usually easy in my experience, certainly for
things that would be caught by a type or bounds checker. But maybe it
takes experience to write programs such that such bugs are easy to
find.

>> If you haven't found Forth strings, arrays, hash tables, etc., by now,
>> it's because you were looking at an embedded Forth, where all these
>> features just don't fit.
>
>I'm using gforth and I didn't notice any of that in the manual.

Strings: http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Memory-Blocks.html

(no docs for Bernds strings package, though).

Arrays:
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Address-arithmetic.html

Hash tables:
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Word-Lists.html

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Anton Ertl wrote:
>> I think that we probably would not have them if HTML had not become
>> way more complicated than HTML 2.0.
>
>People are notoriously bad at abstractions. They want WYSIWYG.
>Therefore, these alternative markup languages provide features that a
>bulleted list looks like
>
>* item a
>* item b
>
>and an enumerated list is
>
>1. first item
>2. second item
>
>and the syntax for headline is
>
>headline
>========
>
>or
>
>headline level 2
>----------------
>
>This sort of type-writer markup seems to be pretty easy to grasp.

I don't find this easier than LaTeX or HTML, and in the end you need
some more "abstract" markup after all, e.g., for links. The wide use
of the HTML-like BBcode also supports my view.

>Yes, showing where you made a mistake is a good idea. But people are
>much better at these visual markups, they do produce correct code much
>more likely, because correct code is visually pleseant there. Incorrect
>code isn't. That *does* matter.

My experience is that at some point visual pleasantness breaks down
and becomes hard to maintain. E.g., links, or comments. So now you
have a language that appears easy at first, and breaks down later.

>The lession I learned from both LaTeX and HTML is:
>
>* the content is in a free-form markup, i.e. you need to be flexible how
>to parse your markup (one single markup notation won't do it)

Your example above is everything but free-form.

[Bernd Paysan]

Anton Ertl wrote:
>>This sort of type-writer markup seems to be pretty easy to grasp.
>
> I don't find this easier than LaTeX or HTML, and in the end you need
> some more "abstract" markup after all, e.g., for links. The wide use
> of the HTML-like BBcode also supports my view.

IMHO the motivation for BBcode is to make it easy to transform into
HTML. The motivations for the other, more visual codes which are also
widely used (like the Wikipedia syntax) is to make it easier.

"more abstract" markup uses more difficult constructs, of course.
Though I consider [url|name] as less cumbersome than <a
href="url">name</a>. The only problem there is with the [url|name]
notation is that some systems actually have a [name|url] syntax ;-).

> My experience is that at some point visual pleasantness breaks down
> and becomes hard to maintain. E.g., links, or comments. So now you
> have a language that appears easy at first, and breaks down later.

So your suggestion is to make everything hard to maintain, not just the
difficult parts? If I would add comments to such a language, I would
use skip-to-eol comments, and use one of the common EOL comments like %,
# or //, which people are familiar with.

>>The lession I learned from both LaTeX and HTML is:
>>
>>* the content is in a free-form markup, i.e. you need to be flexible
>>how to parse your markup (one single markup notation won't do it)
>
> Your example above is everything but free-form.

What I want to say is that the content is *not* in a form mandated by
the browser (which would be fixed-form, fixed to whatever form the
browser accepts), but one mandated by the content-provider (or that
framework). Having the browser provide a fixed parsing program is so
obviously wrong when you look at the current web: Almost everybody who
has user-generated content uses something else than HTML, even when it
is relatively close like BBCode.

So you say "this is BBcode" and the browser fetches a BBcode parser and
uses that to read your content. Or you say "This is a particular Wiki
markup", and the browser uses that parser.

[Albert van der Horst]

In article <6cd04453-c73a-4587...@googlegroups.com>,
<theorigi...@gmail.com> wrote:
>Hi Paul,

>> .. And don't you have to boot your PC in order to
>> start the terminal program before you can type to the Fignition board?
>
>FIGnition, unlike embedded MCU boards like Launchpad or Arduino, is a
>whole, self-contained computer with a keypad for programming and video
>output and boots straight into its programming environment.
>
>I thought it was obvious from the introductory paragraph on the
>FIGnition home page that with FIGnition you can code on its keypad,
>directly into the machine as you would with an early 80s micro.

Indeed, pretty unbelievable. It is beyond me they didn't spare a
5 pin mini DIN connector, so you can plug in a vintage keyboard.
Typical dump prices 1 or 2 euro's. Then of course you can
find them by the wayside.
(I've collected 5 IBM original's, so my stock should last 5 life times.)

>
>However, on reflection, perhaps it's not obvious enough for some people.

It was the first thing I looked for. Do I have to hook up a PC, and
where do I plug it in? But then I'm known for getting at the important
points fast.


>
>-cheers from julz

Groetjes Albert

[theorigi...@gmail.com]

Hi Paul,

> > the reality is that the end-to-end complexity is still the biggest
> > hurdle the kids have to face.
> Maybe you could say exactly what you mean by "end-to-end complexity".

> you're advocating dealing with it through a very simple
> implementation.

Abstraction is great for usability, but not so helpful for understanding. For example, a light switch 'buttons-up' the complexity of the national grid, and it's known they're very easy to operate. But it doesn't mean that we teach electronics using a slightly more detailed version of the national grid. Instead we start with simple, but real, circuits that can be understood.

The problem is that this buttoning up never really works perfectly for two reasons: firstly there's an inevitable conflict between requirements, resources and their implementation. For example, the user-interface for a GPS system is more complex than for traditional map navigation and future needs to support, e.g. congestion re-routing or inter-car collaboration.

Secondly, it's not practical to wait for systems to be completely abstracted before we build on them - in reality there's a continual mix of technologies that expose their heritage at various levels.

But end-to-end complexity can be understood fairly easily. In the early 80s we'd turn on a computer and start coding within seconds. By the mid-80s simple compilers were in vogue so we coded using a edit-compile-run cycle with monolithic programs. Here, conventional tools exposed underlying requirements for performance at the expense of ease-of-development. By the late 80s OS's were becoming more complex and GUIs were being introduced; so there was a need for simple IDEs which supported the libraries and multi-file applications. Here, multi-file projects expose the implementation trade-off between compilation performance and project size requirements. Project development again became more complex.

In the 90s raw APIs were 'buttoned-up' behind OO-frameworks, but today development environments such as Eclipse expect even newbies to handle multiple targets, sdks, simulators, mixed-language project implementations across objective-C/Javascript boundaries; mandatory source control and a plethora of cloud-hosted client-server scripting paradigms.

We can button-up this complexity for users, they just click on an Appstore and suddenly Augmented Reality is at their fingertips. But in the same way we don't teach electronics by diving into the national grid (or a simplified virtual national grid), it doesn't mean the best way is to teach using either fake programming paradigms (e.g. KODU or Scratch) or full-on environments where they just stitch stuff they don't understand together in ways they don't really understand.

You see this in practice, e.g. the previous poster who was shocked that GRADUATES don't understand how computers actually work as it's someone else's problem. But also in the way you don't really want to deceive kids with fake programming.

A good example was Young Rewired State in Birmingham a month or so ago. One of the finalists (a reasonably bright student) had created a Scratch-based app, but you could see that as he stood up he was basically embarrassed about it.

> Geany is a fancy IDE sort of like Eclipse.. handles multiple languages
> .. people just

> getting started should probably consider alternatives, so I mentioned
> Geany.

Indeed, it doesn't get much simpler than Eclipse ;-)

> Python is a language, not a complete environment.

True, it's hard to cram anything better than a crude CLI into 860Kb.

> The CPython distribution does come with an IDE

Hmmm, yes at 23Mb it might just be possible!

> it's less powerful than fancier ones like Geany.

Understandable, it's only 23Mb.

> I've never personally used LOGO but I know it's gotten some traction for
> teaching little kids.

Logo's smart; about as powerful as Lisp, but with a friendlier syntax. It's not totally general purpose, which is probably why it didn't replace Basic, but it is pretty good.

> How many kids today do you think are coding in Minecraft, compared with
> "early 80s systems"?

I really don't know. I do know that about 10 to 20x fewer kids can code at all compared with the mid-80s, despite the far greater numbers of available computers so I guess either it isn't that transferable or Minecraft 'coding' is more like HTML or something.

> Another theory ..in the early 80's the only thing [kids]

> could really do with them was code, and today there's far more
> possibilities.

I think there's some truth in that, though there were plenty of non-programming electronic toys in the day. It's certainly true there's far more distractions on modern systems - it's always far easier to not code than to code for all of us, but the complexity of modern systems (including modern coding systems) plays a huge part from personal experience.

> > I thought it was obvious.. with FIGnition you can code on its keypad

> No, that's not mentioned.

I meant, I now realise it's not obvious, it'll get changed.

> ..It frankly sounds nuts

Surprisingly, it's not though, it's faster than texting and as fast as typing on a touch-screen :-)

> I don't know if modern TV sets.. still have composite video input.

Pretty much all of them still have composite (sometimes multiple inputs) and/or SCART.

> You know, that Atmega part in the Fignition purports to be an 8-bit
> micro that's sort of a modernized 6502, but how do you know it's not
> really a much faster x86 core, running firmware that emulates the AVR
> instruction set, eh? ;-)

Because people have decapsulated AtMega168s and the functional units can be easily seen. But you'd be able to figure it out anyway from the outrageous power consumption; ns-level timing inaccuracies; parts cost (Atmel would probably go bust if they took that approach) etc. Like I'm arguing, almost nothing can be perfectly abstracted ;-)

-cheers from julz

[theorigi...@gmail.com]

Hi Mark,

Just looking at some other posts!

> > Mark Wills <forthfr...@gmail.com> writes:
> > >Well, for youngsters, how about a cycle computer [...features
> > > suggested hardware...]

Yes, that'd be fun. It's a much more practical application than any 555 circuit, could be done with Forth and Arduino could do it pretty easily (you could do both, using AmForth). They can learn a lot about electronic design and could add their own features. Who cares if it's not a commercial solution - it'll help them get out of the hyper-consumerist ethos!

Being inspired in these terms, is all about being able to see that your only choice isn't just to buy prepackaged products.

-cheers from julz

[A. K.]

C'mon --- why on earth should kids learn Forth ???
They can spend their time way better to find their own place in this
everchanging world.

The "target market" for Forth are not bicycle riding kids but
technically oriented young students. For them you can crank up the
complexity of a Forth demo, for instance a house photovoltaic battery
charger or somesuch that is more useful than taping an Arduino board to
a bike handle.

[Howerd]

Hi Mark,

When I was 15 I asked my school if they could by me some bits to make a computer, but they had no idea what I was talking about. That was 1969 - I bought my first computer around 1982 - an Amstrad CPC64.

I do worry about young people these days being so gullible - the power of advertising seems to be strong - and I don't see much judgement or discretion being used, or curiosity about how things really work.

Two questions : do you write a Word document, or do you program it? Do you program in C# or write in C#?

"Programming" in the sense that it is used in the sorts of companies where I work, is less about problem solving and more about fighting the IDE. It follows the corporate structure - interfacing is everything - fit in at all costs.
And of course, what is taught in schools tends to be what is required to get a job later, so its all about using programs, not writing them.

That is why I love Chucks's work - Forth, colorForth and the GA144 to name but three.

Best regards,
Howerd

[Ilya Tarasov]

> Ilya Tarasov wrote:
>
> > Does anybody hope on the such symple device,
>
> > which can be implemented by hundreds ways?
>
>
>
> Well, I was just responding to the initial post. Building your own computer *is* inspiring. It's also a Forth-based computer, which is what you want on this forum eh? Like proper computers it doesn't need an external host to do any programming with it. And it's very similar to an early 80s micro, using similar resources.

Perhaps, if I told I've got a linecard of my own FPGA-based Forth-processors, it makes things easier. It is not necessary to explain me all benefits of Forth in embedded systems. I just want to say that first imagination and 'Wow! -effect' are not enough to provide a valuable results. Simple projects could be a good quick-start for beginners, but they should be followed by more complex ones. So, we should think about teaching course, not about simple device without any specific functions.


> But the key thing *is* the simplicity, that's what makes it special; because only simple machines can be mastered and understood from end-to-end. How does it benefit kids if their only true experience of programming requires incomprehensible Giga-byte and GigaHertz, multi-core monstrosities? How would they ever grasp it, if even reading the code in the system would take many lifetimes?
>
>
>
> And how is it inspirational if every computer we experience is pre-packaged, surface-mount technology that requires a microscope to modify it? It's in some sense impressive, but what does that say about accessibility?

It looks like a mix with platform-independent basic principes (that's good!) and evaluation platforms, which targets a very simple applications. You should to choose, what you want to do - explain something (and you require a comprehensive hardware platform to demonstrate as many features as possible), or implement a low-cost high-volume device.

> Ultimately, we have to weigh up why kids aren't inspired to program today. Is it because computers aren't cheap enough (though even a netbook is 3x cheaper than a ZX Spectrum in today's money)? Or could it be something to do with them being 10,000 times more complex? Does FIGnition fit the STEM club criteria? (yes) Can you do a substantial amount of a GCSE computer studies on a FIGnition? (yes) Is FIGnition cute and fun? (you bet ;-) ) !

In this project, you are talking about a student lab. It requires about 1 hour to explain and implement this device, almost regardless of hardware platform. Also, check the 'rotary encoder' for properly debouncing scheme. Some kinds of these devices uses two optocoupled pairs, which makes a pulses consequently and at a different moments of time. So you simple should wait for second sensor after first and so on. Otherwise, you must filter the leading and trailing bounce sequences.

Finally, I can repeat that this application is too simple for inspiring anybody for a long time.

Ilya Tarasov

[Paul Rubin]

theorigi...@gmail.com writes:
> For example, a light switch 'buttons-up' the complexity of the
> national grid, and it's known they're very easy to operate.

I like your light switch example, and it makes the same point as the
earlier examples I gave.

> there's an inevitable conflict between requirements, resources and
> their implementation. For example, the user-interface for a GPS system
> is more complex than for traditional map navigation

Really it's not. Just key in the address you want to travel to, versus
messing with map books, street-finder indexes, coordinate grids telling
you to jump from one page to another or buy another book, etc. Or
worse, in the nautical case: figuring out how to use a sextant and sight
tables and all that, plus it doesn't work if there is cloud cover.

> and future needs to support, e.g. congestion re-routing or inter-car
> collaboration.

Maps don't do that, the car GPS that I currently use doesn't either, and
it's very helpful regardless.

> But end-to-end complexity can be understood fairly easily. In the
> early 80s we'd turn on a computer and start coding within seconds.

Again you're talking about the boot delay while saying you're talking
about something different. If you get a regular PC to boot in 3-seconds
and auto-start an IDE, what have you lost? Maybe you could just do a
software image that boots a PC or a Raspberry Pi to your favorite IDE.

> multi-file projects expose the implementation trade-off between
> compilation performance and project size requirements.

It's not just compilation performance, it's also general modularity and
manageability of the code. There's no significant loading delay for
reasonable size Python programs but it's still helpful to separate stuff
into different files. But, maybe for initial teaching, this isn't
needed.

>development environments such as Eclipse expect even newbies to handle
>multiple targets, sdks, simulators, mixed-language project

I think this is sort of a Java and "enterprise" thing. I don't think
Java is a good language for beginning programmers.


> [Logo] didn't replace Basic, but it is pretty good.

Basic is pretty dead now, unless VB counts as Basic, and even VB is
pretty dead now, so something replaced Basic.

> I do know that about 10 to 20x fewer kids can code at all compared
> with the mid-80s,

Where on earth do you get numbers like that from?

One impression I do get is that the main app kids are interested in
coding these days is video games, so your product should be able to get
stuff moving on the screen.

> [8-button keypad] it's faster than texting and as fast as typing on a
> touch-screen :-)

Really, your thing will be a lot more usable with a USB host port that
can accept a normal PC keyboard.

[arc]

We all seem to be assuming that kids don't program these days, unlike
the halcyon days of yore when computers had 8 bits, we made our own fun
and used the power of our imagination, we didn't have remote controls,
and there was this thing called discipline.

Are we really sure about this?

(Julz, how do you know that 80s computers were '10-20x more effective at
getting kids to code' ?)

I mean, it seems to me thinking back on it that in my experience it was
uncommon for kids to program in any way whatsoever, and very rare for
them to get beyond simple BASIC or LOGO programs. I never really got
beyond very rudimentary programs, and I'm fairly certain there was
no-one in my year at school who did much more than that, and moderately
sure there was no-one in the years either side of me. Later on I met
people my age who had gotten into programming in a big way as kids or
teenagers, so sure they existed, but I'd put the number at well shy of
1%.

(I see your ancedotes, and i raise you mine)


Maybe rather than something being wrong with either computers or kids
these days, it's just the case that programming is something that
doesn't really interest most kids, never has, probably never will, and
people with the inclination to be real hackers are pretty rare, and,
unsprisingly, well over-represented in this newsgroup.

That's not to say I don't think it couldn't be presented in a way that
would make it more approachable or fun for kids, or whatever, but I
don't think it was really all that approachable or fun (for most kids)
back in the day. Those that did anything beyond the rudimentary were
those few that found it innately interesting and natural.

The one thing I think maybe made it more attractive to program back then
was the fact that the games and even applications available to you were
not actually all that sophisticated, so it was easier to see yourself as
footing it with commercial programs.

-arc.

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> {'name':'Paul','languages':['Python','Forth']}

> This reminds me of what I do with data in charts written in Postscript.
> In simple cases, the data is interpreted directly and drawn right away:

I couldn't follow the Postscript code details but I get the general
idea. It still goes against the usual wisdom that once you figure out
your program's data structures, the code takes care of itself.

Another issue is that Lisp and Python-like languages not only have a
convenient syntax for reading those structures, they can also print them
in a way they can read them back in. So you can easily compute data and
dump it out for later re-import. This is very convenient for fast
interactive development.

>
> OTOH, the success of applications that support scripting and add-ons
> shows that, no, you cannot expect a program to do everything that's
> needed out of the box, even after a few iterations.

I would say here, the toolkit is script interpreter and the stuff
exported to the scripting language, and the application is the user
script. So it's pretty usual in the iterative development of such
frameworks that in early versions, the script system can't quite do what
you want and you have to mess with the internals, such as to export new
functions that scripts can use. But eventually the scripting level
becomes pretty powerful. This happened with Emacs, with browsers, etc.

> Debugging Forth code is usually easy in my experience, certainly for
> things that would be caught by a type or bounds checker. But maybe it
> takes experience to write programs such that such bugs are easy to
> find.

It's well known that such bugs are a perennial drain on development time
and source of exploits in in C and C++ programs. I'm interested to know
if Forth somehow avoids these problems where C and C++ fail. The rest
of the development world dealt with it mostly by migrating to type-safe
and GC'd languages.

> Strings: .../Memory-Blocks.html
> Arrays: .../Address-arithmetic.html

These are very do-it-yourself approaches, to say the least ;-).

> Hash tables: .../Word-Lists.html

This seems to be a way to manage vocabularies visible to the
interpreter, rather than make dictionary-like data objects for use by
programs.

[Bernd Paysan]

Paul Rubin wrote:
>> Debugging Forth code is usually easy in my experience, certainly for
>> things that would be caught by a type or bounds checker. But maybe
>> it takes experience to write programs such that such bugs are easy to
>> find.
>
> It's well known that such bugs are a perennial drain on development
> time and source of exploits in in C and C++ programs. I'm interested
> to know if Forth somehow avoids these problems where C and C++ fail.
> The rest of the development world dealt with it mostly by migrating to
> type-safe and GC'd languages.

We had that discussion a while ago, stdlib strings are broken by design
(and even though people here argue that zero-terminated strings in C are
"optional", people learn this broken string functions when they learn
C).

The solution for this problem is to have string buffers growing and
shrinking with the string. This doesn't require full GC and type-safe
stuff, it only requires resize() of malloc-ed blocks.

The little string words I use for that in Gforth are documented, though
only in the current development branch. I've used them quite often, and
I never had any sort of buffer overflow or alike with them.

I think Forth program development differs in two important ways from C:

* We don't write big chunks of code and then test them. This is done in
C, because compiling takes long, and to debug stuff you need to write a
debug harness etc.; in Forth we change little things and test
immediately.

* We extend the programming language to provide what's missing. C
people use libraries and stick to their libraries even if there are
serious flaws.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
>>> things that would be caught by a type or bounds checker....

>> I'm interested to know if Forth somehow avoids these problems where C
>> and C++ fail.

> We had that discussion a while ago, stdlib strings are broken by design
> (and even though people here argue that zero-terminated strings in C are
> "optional", people learn this broken string functions when they learn C).

It's not just strings, it's every sort of array, in every language
except apparently for Forth. I guess Forth array users can always write
access functions that check bounds, and use those at least during
developent.

> The solution for this problem is to have string buffers growing and
> shrinking with the string. This doesn't require full GC and type-safe
> stuff, it only requires resize() of malloc-ed blocks.

C++ STL strings and vectors do this growing and shrinking, and are
somewhat less vulnerable to these hazards than C stdlib strings, but you
still have memory leaks and double-free errors to deal with.

> The little string words I use for that in Gforth are documented, though
> only in the current development branch. I've used them quite often, and
> I never had any sort of buffer overflow or alike with them.

Cool, I'll look for them.

> I think Forth program development differs in two important ways from C:
> * We don't write big chunks of code and then test them. This is done in
> C, because compiling takes long, and to debug stuff you need to write a
> debug harness etc.; in Forth we change little things and test
> immediately.

I'm not sure how much this really helps: it handles immediate, localized
bugs, but not really bugs involving long-range interaction between
components.

I think Forth applications simply tend not to be of the type that uses
dynamic memory or even strings all that much. The typical profile might
be more like MISRA C. This is perfectly fine of course.

> * We extend the programming language to provide what's missing. C
> people use libraries and stick to their libraries even if there are
> serious flaws.

I'd say if the same stuff turns up missing again and again, it's time to
factor it into the library.

[Bernd Paysan]

Paul Rubin wrote:
> It's not just strings, it's every sort of array, in every language
> except apparently for Forth. I guess Forth array users can always
> write access functions that check bounds, and use those at least
> during developent.

Hehe, the word goes "using bound checking during development is like
using a parachute while still on ground". The development style is
"crash early, crash often"; you might do your bould checking there and
crash, but the application program should rather be robust.

The array function in my string package is auto-expanding the string
array instead of crashing. This goes towards robustness, not towards
crashing.

>> The solution for this problem is to have string buffers growing and
>> shrinking with the string. This doesn't require full GC and
>> type-safe stuff, it only requires resize() of malloc-ed blocks.
>
> C++ STL strings and vectors do this growing and shrinking, and are
> somewhat less vulnerable to these hazards than C stdlib strings, but
> you still have memory leaks and double-free errors to deal with.

That's why I only allow strings to live in global variables (or - when
used within my OOP package - as instance variables of objects which know
how to dispose themselfes).

>> I think Forth program development differs in two important ways from
>> C:
>> * We don't write big chunks of code and then test them. This is done
>> in C, because compiling takes long, and to debug stuff you need to
>> write a debug harness etc.; in Forth we change little things and test
>> immediately.
>
> I'm not sure how much this really helps: it handles immediate,
> localized bugs, but not really bugs involving long-range interaction
> between components.

When our programs have interactions between components, testing that is
part of the testing.

> I think Forth applications simply tend not to be of the type that uses
> dynamic memory or even strings all that much. The typical profile
> might be more like MISRA C. This is perfectly fine of course.

Applications like MINOS certainly are not that common Forth
applications.

>> * We extend the programming language to provide what's missing. C
>> people use libraries and stick to their libraries even if there are
>> serious flaws.
>
> I'd say if the same stuff turns up missing again and again, it's time
> to factor it into the library.

We do that, but our main problem is that we usually don't think the
libraries others have created are any good.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> Hehe, the word goes "using bound checking during development is like
> using a parachute while still on ground".

Yeah, leaving bounds checks active all the time is probably best
practice in most applications.

>> you still have memory leaks and double-free errors to deal with.
> That's why I only allow strings to live in global variables (or - when
> used within my OOP package - as instance variables of objects which know
> how to dispose themselfes).

But now you've got the issue of leaking or double-freeing those objects.
If you've got complex, dynamic data structures, storage management is a
nontrivial issue.

>>> in Forth we change little things and test immediately. ...

> When our programs have interactions between components, testing that
> is part of the testing.

I guess I'm not seeing how this is different from C then. Code change
is not topologically continuous. Sure you can write a new component
bottom-up, but you can't really connect it up to other components til a
substantial amount of the new component is working, and maybe then you
find there you find an interaction problem you hadn't thought of in
advance. What then?

[Mark Wills]

On Oct 8, 6:09 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> The array function in my string package is auto-expanding the string
> array instead of crashing.  This goes towards robustness, not towards
> crashing.

No it doesn't. If it's *auto* expanding then it just hides an
undetected problem. You end up with a program that works fine for a
few hours on the lab bench, but crashes every three weeks in the
field. It goes towards crash later. And I can tell you, from bitter
experience, they are the hardest of all bugs to find, and often end up
never being solved:

"Hey, that plating controller is really great, saved us a lot of money
in copper sulphate solution, but it crashes every three weeks, and we
have to scrap whatever job is in the bath."
"Hmmm... Are you sure it's not some power spike? Is a large pump
nearby switching on or something like that?"
"Dunno. Could be. We're all scratching our heads here! But hey, it's
like only every three weeks or so..."
"Hmmm... Say, how's about we program it to do a reboot at the end of
each job?"
"Yeah. Great idea"

< six months later >

"How's the controller"
"Oh man! Solid as a rock! We just love it! Send us the bill. And
another controller while you're at it!"
"Great"

When the truth is, it's as shaky as hell!

[Mark Wills]

On Oct 9, 5:57 am, Paul Rubin <no.em...@nospam.invalid> wrote:
>
> Yeah, leaving bounds checks active all the time is probably best
> practice in most applications.
>

No. Testing the absolute living shit out of the application to prove
that a bounds error cannot happen is the way. Detecting a bounds error
is very nice in a spreadsheet, or an app to convert GIFs to JPGs or
whatever. It's not really much use on the rocket firing system on the
alignment correction system of a telecommunications satellite. Out of
bounds? Whoop de doo... You're still going to fall out of orbit!

[Mark Wills]

On Oct 9, 5:57 am, Paul Rubin <no.em...@nospam.invalid> wrote:

> I guess I'm not seeing how this is different from C then.  Code change
> is not topologically continuous.  Sure you can write a new component
> bottom-up, but you can't really connect it up to other components til a
> substantial amount of the new component is working, and maybe then you
> find there you find an interaction problem you hadn't thought of in
> advance.  What then?

You re-factor. You change the code.

You know these kind of high-brow discussions are quite entertaining.
They often make me chuckle to myself. Not so much here on CLF, but on
Java websites, or (all the time) in programming books we hear these
kind of every-day programming problems cited as major disasters.

Project Mangler: "Oh no! Johnny had to change the interface of his
object to take an unsingned int instead of an int. CALL THE MEDIA. OH
NASH NASH. WAIL WAIL. HOW WILL WE EVER RECOVER FROM THIS TERMINAL
ERROR? SOMEONE FIRE JOHNNY. HOW COULD HE BE SO STUPID... SEE? SEE?....
IF HE HAD ABSTRACTED THE INTERFACE FROM THE DEFINITION OF THE CLASS
THEN THIS WOULD NEVER HAVE HAPPENED... BUT NO... *NOBODY* LISTENS TO
ME. I TOLD YOU IT WOULD BE A DISASTER. I READ IT IN A BOOK. OH NO!
WE'RE REALLY SCREWED NOW. UP SHIT CREEK. *WE'LL HAVE TO RE-WRITE THE
ENTIRE APP*. OH MAN. I KNEW THIS WOULD HAPPEN..."

Johnny: "Er, it's okay guys. I did the change. Took like 15 mins. God
bless the object browser, eh?"

:-)

The truth is, if you know the app, you can change it. It really isn't
a big deal. Sure, there's a cost. The expense is in the re-testing,
not in the re-engineering.

[Bernd Paysan]

Mark Wills wrote:

> On Oct 8, 6:09 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> The array function in my string package is auto-expanding the string
>> array instead of crashing. This goes towards robustness, not towards
>> crashing.
>
> No it doesn't. If it's *auto* expanding then it just hides an
> undetected problem.

I honestly disagree. What should $+! do other than auto-expanding the
destination string so it can add the requested string? Same with a
string array, which you usually use by converting lines of a file into
an array for random access.

Some of the auto-expanding code I wrote allow to expand one bit at a
time, but not arbitrary writes into the void. This covers pretty well
for what could be an undetected problem.

Having to expand deliberately and manually makes the use of such a
package tedious at the expense of robustness.

> You end up with a program that works fine for a
> few hours on the lab bench, but crashes every three weeks in the
> field. It goes towards crash later. And I can tell you, from bitter
> experience, they are the hardest of all bugs to find, and often end up
> never being solved:

Sorry to say so, but if you don't print out a meaningful backtrace in
case of a crash, you won't solve this sort of problems. Maybe yes, it
only crashes every three weeks and the backtrace goes something like

out of memory error
$[]+!
some function calling that
etc.

So what do you do? Maybe you need to add a little clues in the
backtrace, to show what actually happened, and let it run another 3
weeks to get there... or maybe it's already enough of a hint to show
what's going wrong.

[Paul Rubin]

Mark Wills <forth...@gmail.com> writes:
> The truth is, if you know the app, you can change it. It really isn't
> a big deal. Sure, there's a cost. The expense is in the re-testing,
> not in the re-engineering.

Well, I was just in this situation with a C++ program. I added a
feature and that caused a double-free crash in another part of the
program. I "fixed" the crash but the fix left a memory leak, which also
had to be fixed. Detecting the memory leak required running the program
for a while, which I had to do several times to observe the leak and
test the fix, burning more time.

None of this was a big disaster--it was just a normal part of a day's
development. But with more civilized (i.e. GC'd) languages, this stuff
just doesn't happen in the first place. Programmers can then focus
their efforts more directly at producing visible end results.

If your testing expenses are that large (outside of critical systems),
it could be because too many bugs are getting through your development
process, and maybe you should re-examine your strategy.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:

> Well, I was just in this situation with a C++ program. I added a
> feature and that caused a double-free crash in another part of the
> program. I "fixed" the crash but the fix left a memory leak, which
> also had to be fixed. Detecting the memory leak required running
> the program for a while, which I had to do several times to observe
> the leak and test the fix, burning more time.
>
> None of this was a big disaster--it was just a normal part of a
> day's development. But with more civilized (i.e. GC'd) languages,
> this stuff just doesn't happen in the first place.

And neither, I have to point out, does it happen with a language that
doesn't use dynamic memory allocation. Besides, the analogy in a GC'd
langauge is a memory leak: these are very hard to avoid and happen all
the time.

Andrew.

[rickman]

Really, you think the way to design critical systems is to test them
extensively? Unless you do an "exhaustive" test which means *proving*
it is truly exhaustive, testing can't prove the absence of errors. NASA
demonstrates this on a regular basis with some expensive and spectacular
failures, not to mention the tragic ones. Do you really think their
failures are because they didn't test the "absolute living shit" out of
them?

Rick

[Bernd Paysan]

Andrew Haley wrote:
> And neither, I have to point out, does it happen with a language that
> doesn't use dynamic memory allocation. Besides, the analogy in a GC'd
> langauge is a memory leak: these are very hard to avoid and happen all
> the time.

A lot of people seem to assume that a GC'd language means you don't have
memory leaks, the GC will find and collect all garbage. Though, in
reality, this isn't true. A GC can throw away things that aren't
pointed to by any of the root pointers. However, you can easily have a
situation where you store things in a structure pointed by a root that
you don't actually need anymore. You may, in a GUI, have a map of the
OS window identifiers to the internal window objects, and that map is
alive. If you don't manually remove window objects from that list,
they'll clutter your memory indefinitely.

If you are writing a complex piece of software, like a web browser,
which is by design and specification prone to memory leaks, you better
should add enough debugging code to inspect your memory and see the
reasoning of the GC why objects are alive. If you don't know what's
going on in your program, you are too easily lost.

[visua...@rocketmail.com]

On Saturday, September 15, 2012 11:29:08 PM UTC+2, Paul E. Bennett wrote:
> In attending this years EuroForth conference in Oxford, it seems that the
>
> community needs to instil the "Inspire a Generation" spirit that pervaded
>
> the London 2012 Olympics event. By this we mean that we need to raise theons
>
> for self expres level of enthusiasm for Science, Technology, Engineering and
>
> Mathematics within the upcoming generations from primary school level
>
> upwards.
>
>
>
> There are companies that need the right sort of new-blood intake that not
>
> only has some enthusiasm for the STEM subjects, but also the desire to
>
> continue learning useful skills and techniques to create the technology that
>
> will carry their own generation's aspiration to self expression.
>
>
>
> What sort of projects do those members of the list think will be affordable
>
> and inspirational enough to fulfil this goal?
>
>
>
> --
>
> ********************************************************************
>
> Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
>
> Forth based HIDECS Consultancy
>
> Mob: +44 (0)7811-639972
>
> Tel: +44 (0)1235-510979
>
> Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
>
> ********************************************************************

Thanks Paul!
Three weeks and 78 posts - 25 more than for "The Secret of a Successful Programming Language" - sure a theme which is of interest.

It's a pity that the Forth path may get lost in bloating.
I am missing an offer where to buy this ultimately easygoing low priced Forth board.

Believe me, kids will understand Forth.

When I showed Forth decades ago at the Munich electronica fair, kids told me how to correct my typing after a few lines, programming a bird's chip chip ...
They immediately grasped how it works.
We need to to offer special easygoing tools for the next generations of enthusiastic and engaged Forth programmers education!
These kids are our future clients, and they are eager to learn.

We have to give the opportunity to teach and learn Forth in a new, up to
now unknown, and easygoing fashion.

[rickman]

On 10/9/2012 5:30 PM, visua...@rocketmail.com wrote:
>
> Thanks Paul!
> Three weeks and 78 posts - 25 more than for "The Secret of a Successful Programming Language" - sure a theme which is of interest.
>
> It's a pity that the Forth path may get lost in bloating.
> I am missing an offer where to buy this ultimately easygoing low priced Forth board.
>
> Believe me, kids will understand Forth.

What Forth board are you referring to? There are dozens of
microprocessor boards available at prices anywhere from $4.30 upward.
What about those boards make them inappropriate?

I think the only issue is the software. Someone would need to provide a
software development environment that suits kids.

So what do you want from the board and who will provide the software? I
will be happy to design a board if one is not available.

Rick

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> But with more civilized (i.e. GC'd) languages, this stuff just
>> doesn't happen in the first place.
> And neither, I have to point out, does it happen with a language that
> doesn't use dynamic memory allocation. Besides, the analogy in a GC'd
> langauge is a memory leak: these are very hard to avoid and happen all
> the time.

When the language doesnm't feature dynamic memory allocation,
applications (at least of a certain sort) tend to grow it, per
Greenspun's Tenth Law. Memory leaks in GC'd programs happen, but in my
own experience they haven't been that big a problem in Python or Lisp (I
don't know about Java). When they do occur, usually there's a stray
reference to some complex structure, so get rid of that and everything
is solved. This is better than C++ where you have to be much more
careful about what depends on what.

They happen very easily in Haskell as a result of Haskell's lazy
evaluation strategy, and this is one of the most common and serious
criticisms of Haskell. Learning how to avoid them is one of the early
hurdles new Haskell programmers have to get past. There are some decent
tools for detecting them based on runtime profiling. It would really be
better if the compiler could help more, but there are apparently complex
issues involved.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> But with more civilized (i.e. GC'd) languages, this stuff just
>>> doesn't happen in the first place.
>>
>> And neither, I have to point out, does it happen with a language that
>> doesn't use dynamic memory allocation. Besides, the analogy in a GC'd

>> language is a memory leak: these are very hard to avoid and happen all
>> the time.
>
> When the language doesn't feature dynamic memory allocation,

> applications (at least of a certain sort) tend to grow it, per
> Greenspun's Tenth Law. Memory leaks in GC'd programs happen, but in my
> own experience they haven't been that big a problem in Python or Lisp (I
> don't know about Java). When they do occur, usually there's a stray
> reference to some complex structure, so get rid of that and everything
> is solved. This is better than C++ where you have to be much more
> careful about what depends on what.

I don't think it's so clear. With a GC you have to remember to null
references to structures you no longer care about instead of manually
freeing them, but you still have to clean up after yourself. GC
helps, for sure, because you can't access data after it's been freed
and you don't have to worry who else has a reference to your data.
But that's all.

Andrew.

[Paul E. Bennett]

As someone stated in another thread:-

"Dijkstra had once said "Programs are either so simple that they contain
obviously no bugs, or so complex that they contain no obvious bugs".

Forth helps you to create lots of simple words which, even when gathered
together, can still give the facility of remaining simple enough that errors
become obvious (although programming style will have some impact on this).
Even so, it is important to inspect and test each and every word to ensure
they all meet their individual requirements (as you have stated them in the
glossary entry).

Part of the lesson to the younger generation should be how to analyse a
problem and break it down into simpler fully understandable bits. They then
need to explore suitable simple solutions that can build to solve the whole
problem. Forth (philosophy and style) is great for such work.

[Paul E. Bennett]

Probably he was referring to the TMS430 LaunchPad boards and the 4e4th that
can be downloaded to it. The 4e4th web-site is:- <http://www.4e4th.eu/>.
The boards are available from Farnell and probably RS too.

[Mark Wills]

Well, I think you can prove it, but sure, it would be very difficult
to come up with the every possible set of variables, be they hardware
variables, software variables, environmental etc. So, all you can do
is test test test test as extensively as possible, such that it
becomes possible to compute the Probability of Failure on Demand (PFD)
which is at the heart of designing, building, and testing SIL rated
(mission critical) systems.

There are different SIL ratings, depending on what (asset value) or
who (number of lives potentially lost) that must be taken into account
when considering these things. Testing the gear after it's built is
only a part of the process, of course. A lot of effort goes into the
design beforehand to (at least theoretically) mitigate the chances
(chances, i.e. it's all about probability) of things going bad.

Of course, it still happens - things go bad, though looking through
past data (in my industry, the oil and gas industry) there are/were
human factors that contributed to the disaster, rather than simply
machinery going wrong. It seems even in the avaiation industry the
triplex redundant systems are awesomely good at their job, and there
are often human factors involved when we hear of planes crashing (fuel
icing, pilot disorientation etc).

It's an interesting topic!

[visua...@rocketmail.com]

On Wednesday, October 10, 2012 12:27:35 AM UTC+2, rickman wrote:
>
> What Forth board are you referring to? There are dozens of
> microprocessor boards available at prices anywhere from $4.30 upward.
>

I am missing an offer of one of these boards loaded with Forth!

> I think the only issue is the software. Someone would need to provide a
> software development environment that suits kids.
>

That's the point!

> So what do you want from the board and who will provide the software? I
> will be happy to design a board if one is not available.
>
> Rick

Are you able to design an appropriate board which can be sold for 4$ or 4€ ?

I read several comments suggesting to learn Forth programming on a PC, but in my opinion the real Forth domain covers programming standalone microprocessor boards. For beginners there is still a software gap.

Who will provide the software?

[Paul Rubin]

visua...@rocketmail.com writes:
> I am missing an offer of one of these boards loaded with Forth!

Well there is the Fignition board. IIRC the 4e4th folks were offering
Launchpad boards with Forth pre-installed but of course you have to plug
a PC into them.

> Are you able to design an appropriate board which can be sold for 4$ or 4€ ?

Something like this, perhaps, but with even less stuff on it:

http://www.diygadget.com/avr-micro-sd-development-board-atmega32u4.html

> I read several comments suggesting to learn Forth programming on a PC,
> but in my opinion the real Forth domain covers programming standalone
> microprocessor boards. For beginners there is still a software gap.

IMHO microprocessor boards make sense for learning about electronics and
hardware, since you can connect up stuff to the GPIO pins and the like.
Otherwise do a thought experiment: plug in a Forth board and start
programming it through a PC, and ask how you can tell whether the board
CPU is actually doing anything, or if the Forth code you're typing is
actually running on some PC simulation. If you can't tell, why bother
with the board?

Overall I think microprocessor boards are a special topic in programming
and aren't that good a choice as a first topic.

[visua...@rocketmail.com]

On Wednesday, October 10, 2012 3:01:17 PM UTC+2, Paul Rubin wrote:

> visualforth.com writes:
>
> > I am missing an offer of one of these boards loaded with Forth!
>
> Well there is the Fignition board.

I guess you will need some soldering skills to use the 32$ Fignition board?

>
> > Are you able to design an appropriate board which can be sold for 4$ or 4€ ?
>
> Something like this, perhaps, but with even less stuff on it:
> http://www.diygadget.com/avr-micro-sd-development-board-atmega32u4.html

Is this your design?

>
> > I read several comments suggesting to learn Forth programming on a PC,
> > but in my opinion the real Forth domain covers programming standalone
> > microprocessor boards. For beginners there is still a software gap.
>
> IMHO microprocessor boards make sense for learning about electronics and
> hardware, since you can connect up stuff to the GPIO pins and the like.
>

Learning about electronics and hardware will be more and more important:
The next generation of PCs may not have the ability to control hardware of your choice.

> Otherwise do a thought experiment: plug in a Forth board and start
> programming it through a PC, and ask how you can tell whether the board
> CPU is actually doing anything, or if the Forth code you're typing is
> actually running on some PC simulation. If you can't tell, why bother
> with the board?
>

I know this scenario.
Therefore it is totally important to have an Forth-IDE which uses a real Terminal software giving the look and feel of a direct target connection.

There are so many examples on the web about how to switch a LED on and off.
Forth is the only programming environment which makes this task a real easy one.
Meanwhile generating Morse-code is en vogue:
http://www.youtube.com/watch?v=ANZ_zruJ3_0

>
> Overall I think microprocessor boards are a special topic in programming
> and aren't that good a choice as a first topic.

In my opinion learning about electronics and hardware is "the real stuff",
but I have to admit, I am biased. My career was based on learning about electronics and hardware, and for my first Forth project I used RSC-Forth on my own R6511 based microprocessor hardware.

[theorigi...@gmail.com]

Hi,

> I guess you will need some soldering skills to use the 32$ Fignition board?

> Therefore it is totally important to have an Forth-IDE which uses a real
> Terminal software giving the look and feel of a direct target connection.

FIGnition isn't just a microprocessor board - it's a complete computer; a little bit more capable than a Jupiter Ace, though less powerful than a ZX Spectrum. You go one better than the look and feel of a direct target connection, since you program it in-situ using its surprisingly efficient keypad. Forth Programs run from its external RAM not internal Flash as fast as an 8-bit micro runs machine code.

It's not an arduino though it looks very much like that kind of device, it's a whole computer, which requires just a composite video out for a display. And the great thing is that it does the job of being complete computer with a built-in compiler in just 16Kb of firmware, which means, like 80s computers, it can be, built, coded and understood from top to bottom.

It really is great, a neat and unique machine!

-cheers from julz

[theorigi...@gmail.com]

Hi Arc,

Thanks for your comment.

> We all seem to be assuming that kids don't program these days, unlike

> the halcyon days of yore when computers had 8 bits..

> Are we really sure about this?
> (Julz, how do you know that 80s computers were '10-20x more effective at
> getting kids to code' ?)

Of course, there's a tendency to idealise the past, but here I'm basing it on real, but anecdoatal evidence. Firstly for all the flaws that it implies I take my school in the 80s as a representative example. We were in a non-selective LEA (no grammar schools) and I went to a comprehensive school which was certainly not the highest achieving, but was probably in the top 30% (though I don't really know) for the LEA. We had an 8 form intake and during the mid-80s Computer Studies was popular enough to run two classes, which represents 25% of that year.

Obviously some of those taking the subject never learned to program (though the course was pretty programming-oriented) but I know there were others who didn't take the course who did know how to program, so I figure it balances.

I assume that my school wasn't terribly exceptional in that respect, so I guess the average across schools then was unlikely to be < half ours, i.e. < 12.5%, and then I'm pessimistic about it being much better than our 25%. So I deduce 10% to 25% of pupils would do computer studies. Note (McKinsey.pdf): in 1984-1985 there were 13.4 computers / school (on average) enough to run at least two Computer Science classes (because at the time the biggest use for school computers was to teach Computer Studies, because the apps weren't available and since our school had about that number and ran 2 classes, spread out over each week, obviously). So, yes, I think my earlier figures aren't crazy.

But it's also the demography of people who know how to program at least a little from that era, e.g. my sister (who actually trained to do nursery nursing) and her husband (who is a plumber) are both able to do some simple programming involving loops, conditionals, input/output and variables.

Yet whenever you talk to today's kids about programming you really, really just get blank looks (and I've asked quite a number of children over the past 5 or so years). Sometimes this is because kids don't realise you can program computers. Jason Fitzpatrick from the Computer History Museum has a great little anecdote about one of their CHM open days where there was a BBC micro at the entrance allowing you to select a whole bunch of games from a Compact Flash card. And as one dad went past he hit Ctrl-Break and then typed in the classic 10 PRINT "I am Fab ";: GOTO 10 ego program and his son was utterly amazed: not merely because his dad could program, but because it was possible to program a computer at all!

But mostly, it's because they don't know anyone who can, because literally no-one in their school does. But the thing is, this position makes sense. Technology is both far more commonplace today, yet far less accessible and at a gut level, it provides a sense that technology is pre-packaged and therefore you don't and can't mess with it and moreover one becomes blind to the question of programming our devices, because they're a given, it's just magic.

And although the disciplines that makes large-scale software possible are crucial for the industry; they're counter-productive to education and understanding. It's like, we don't teach maths by gluing fancy graphs in Mathematica together and then getting kids to glue even more complex functions; even though Mathematica 'buttons-up' the complexity so you don't have to understand it all. You'd have to be crazy to think you'd teach Maths like that, or to think that only the brightest of kids should delve into concepts like rudimentary arithmetic or numbers themselves.

Similarly, with literature. We don't start kids off with War and Peace.. we could 'button-up' the book by reading it to them or let them peruse the graphic novel version; or just help them identify the easy words; or just get them to express NEW War and Peace novels by gluing chapters together with episodes of Pokemon or something. We start them off (in the UK) usually with Phonics... it's all terribly low-level.

Neither do we assume the best way to teach music is to just hand them a copy of Garageband and get them to stitch samples together. We don't argue that samples and modelled instruments 'button-up' the expertise of virtuoso musicians making learning to play a flute or piano a waste of time: we want children to learn real instruments because it conveys much more valuable skills. We don't argue that no-one needs to know those skills any more, because of all the sampled instrumentation we have. Instead we get kids to fumble with keys, strings and valves and begin generating barely tolerable rasps, squeeks and plonks.

We start by getting young children to master the low-level, dare I say, implementation details, of music and then build it up. We don't give them an iPod for 20 years and then say, "A-ha perhaps now you'd like to have a go with a real instrument" - would we produce ANY decent musicians that way?

Nor do we discount people who favour low-level learning in Maths, language, music, art, science, design, cooking etc. We don't say (with a little smirk): "A-ha, but a flute is still packaged innit? Why aren't you getting them to smelt their own flute or teach them about vibrations / air-pressure, harmonics etc... see, playing the flute is the same as a spin on Ableton live after all!"

When it comes to teaching programming though we suspend those principles and decide they'll learn best using complex systems, systems that cannot be understood. We'll teach them using some kind of Duplo code (special fake, kiddy programming tools), where they're nicely insulated from the machine or force them grind through the complex tools, syntax and concepts we've built up over 30+ years. But the real problem *is* all the insulation: the many layers of magic that cuts us off one way or another.

> I mean, it seems to me thinking back on it that in my experience it was
> uncommon for kids to program in any way whatsoever

> Later on I met
> people my age who had gotten into programming in a big way as kids or
> teenagers, so sure they existed, but I'd put the number at well shy of
> 1%.

So, anecdotally you do have a different experience - was this from the mid-80s too?

> Maybe rather than something being wrong with either computers or kids
> these days, it's just the case that programming is something that

> doesn't really interest most kids, never has, probably never will..

Maybe, but empirical data says that both the number of students taking Computer Science at University has been seriously dropping and the quality of those who do take it, is getting worse. This is the jumping-off point for all the Raspberry PI motivation, because Eben Upton was motivated by noticing the changes at Cambridge; and you can easily find a video by Steve Furber about the same issue. Eben was saying (BBC Micro@30 event) that they were even getting more and more CS students who had NO prior programming experience. A number of Universities have also dropped Computer Science courses, Suffolk Uni being one of them.

Interestingly, the quality of those who graduate in Computer Science is dropping too, relative to the intake. i.e. modern CS courses do a worse job of teaching computing than they did 20 years ago. Why? Could it be because the systems used to teach them are 10,000 times more complex than 30 years ago. Just maybe, maybe?

> don't think it was really all that approachable or fun (for most kids)
> back in the day.

I'm not sure how to respond to this question. Computer programming was certainly more approachable in the 80s, because the UI involved typing lines of code just to get it to even load other people's programs. That is, you couldn't avoid it and it was easy to make (though easy to fix) mistakes on early machines, so you had to understand something of what you were doing. But programming environments lacked 'niceties' you find in modern environments and coding would be scruffy and unmaintainable spaghetti. But that's OK if you're learning: the 'niceties' we have now are there to help manage large-scale development.

But it was certainly fun. Look up the video on kids learning with the Ras-PI, and a version of Snake. Now the interesting thing is that the Python program is just pure text and it runs a text version of Snake, but the (not especially geeky) kids found it exciting. It tells you that getting joy out of programming is about discovery and understanding, it isn't related to the power of the machine you're learning on or the sophistication of the output, the same program could have been done on a 2Kb ZX81 and with better graphics!

And it didn't matter that Snake had been written a thousand times for every platform under the sun to these kids, what mattered was the discovery - and we know, kids actually do love discovering things; given the chance they get the same joy as the previous generation learning the same things! So, I don't think you need to compete with commercial apps to experience that.

-cheers from julz

[Paul Rubin]

visua...@rocketmail.com writes:
>> actually running on some PC simulation. If you can't tell, why bother

> ...Therefore it is totally important to have an Forth-IDE which uses a

> real Terminal software giving the look and feel of a direct target
> connection.

Still doesn't help. The terminal software could be connected to a
loopback port whose other end is driven by the simulator.

> In my opinion learning about electronics and hardware is "the real
> stuff",

Well sure, if the subject is electronics and hardware, then great, it's
the real stuff. If the subject is woodworking, then the real stuff is
the table that the computer is sitting on. If the subject is software
(which is what I thought it supposedly was), the code is the real stuff
and the hardware is like the table. The hardware does something
important but the actual details aren't of much concern to the
programmer.

[Mark Wills]

Brilliant post, Julian. Truly inspiring. Thank you!

Mark

[Andrew Haley]

Mark Wills <forth...@gmail.com> wrote:
> On Oct 10, 5:34?pm, theoriginalsn...@gmail.com wrote:
> [ 176 lines deleted ]

> Brilliant post, Julian. Truly inspiring. Thank you!

Mark, a gentle message: plese trim when replying.

Thanks,
Andrew.

[rickman]

That has little to do with my comment about testing. You can't prove
that a complex system can't fail by testing.

As to your comments about Forth, "No generalization is worth a damn,
including this one", often attributed to Oliver Wendell Holmes, Jr., not
sure if he ever said exactly this. Or to quote Mark Twain, "All
generalizations are false, including this one."

Rick

[rickman]

Proving a system is correct means proving it in a mathematical sense,
rigorous proof. Hard to do with any but fairly simple programs.
Supposedly the reason why "structured programming" is used, or so I was
told in school. As you say the other way it to test all possible
combinations of inputs, an impossible job in any practical sense for
most systems.

> Of course, it still happens - things go bad, though looking through
> past data (in my industry, the oil and gas industry) there are/were
> human factors that contributed to the disaster, rather than simply
> machinery going wrong. It seems even in the avaiation industry the
> triplex redundant systems are awesomely good at their job, and there
> are often human factors involved when we hear of planes crashing (fuel
> icing, pilot disorientation etc).

I'm not sure what this means. There are still problems with systems
that cause accidents or in other cases the problems are caught by the
personnel and the accident avoided, largely because the systems were
tested for the problems that were expected. It is the unexpected that
is the real problem.

Rick

[Paul Rubin]

Mark Wills <forth...@gmail.com> writes:
> So, all you can do is test test test test as extensively as possible,
> such that it becomes possible to compute the Probability of Failure on
> Demand (PFD)

I don't think testing lets you compute the PFD without a priority
presumptions about the distribution of inputs. In particular, in the
post-Stuxnet era, you have to presume that even non-networked control
systems will have to deal with malicious input from attackers who have
studied the system in detail. Apparently the security of an awful lot
of SCADA systems is just pathetic. Testing is good but machine checking
of correctness conditions is also good.

[rickman]

On 10/10/2012 6:52 AM, visua...@rocketmail.com wrote:
> On Wednesday, October 10, 2012 12:27:35 AM UTC+2, rickman wrote:
>>
>> What Forth board are you referring to? There are dozens of
>> microprocessor boards available at prices anywhere from $4.30 upward.
>>
>
> I am missing an offer of one of these boards loaded with Forth!
>
>> I think the only issue is the software. Someone would need to provide a
>> software development environment that suits kids.
>>
>
> That's the point!
>
>> So what do you want from the board and who will provide the software? I
>> will be happy to design a board if one is not available.
>>
>> Rick
>

> Are you able to design an appropriate board which can be sold for 4$ or 4� ?

>
> I read several comments suggesting to learn Forth programming on a PC, but in my opinion the real Forth domain covers programming standalone microprocessor boards. For beginners there is still a software gap.
>
> Who will provide the software?

You can get a $4.30 board right now. Is that good enough?

As to the software, that is my point. Someone needs to do that... do I
have to do it all?

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> You can get a $4.30 board right now. Is that good enough?
> As to the software, that is my point. Someone needs to do that... do
> I have to do it all?

I thought you knew about http://4e4th.eu .

[visua...@rocketmail.com]

On Thursday, October 11, 2012 5:57:31 AM UTC+2, Paul Rubin wrote:

And there is a special link for English readers: http://4e4th.com/

[Anton Ertl]

rickman <gnu...@gmail.com> writes:
>NASA
>demonstrates this on a regular basis with some expensive and spectacular
>failures, not to mention the tragic ones. Do you really think their
>failures are because they didn't test the "absolute living shit" out of
>them?

Yes. E.g.,
<http://en.wikipedia.org/wiki/Hubble_Space_Telescope#Origin_of_the_problem>

- 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 2012: http://www.euroforth.org/ef12/