What is Forth best at?
Duke Normandin
"Thinking Forth", Mark Bernstein is quoted as follow:
". . . The idea of of "human scale" is, I think, today's seminal concept
in software design. This isn't specifically a Forth development; the
great joy of UNIX, in its youth at least, was that you could read it
(since it was written in C), understand it (since it was small), and
modify it (since it was simple). Forth shares these virtues, although
it's designed to tackle a different sort of problem."
What does Bernstein mean by "it's [Forth] designed to tackle a different
sort of problem [than C]." With the answer to this question, I hope to
zero-in on "what Forth is best suited for?".
For some reason, I had assumed that Forth could be considered a
general-purpose language -- like C, eg. Maybe I was mistaken. I observe
that the IT industry adopted C as opposed to Forth. I'm curious as to
why this happened? Is there *something* inherently counter-productive
about Forth that would have it be shunned by so many? Why has the cream
not risen to the top?
Please no flames! I'm simply trying to get a sense of time and place
here -- some perspective. Maybe the reason is as simple as why VHS won
out over Beta. Or maybe it's more complex than that.
BTW, who is the official Forth "flag-bearer" these days? FIG? IAFR?? Are
either still alive? I see their websites are still warm. Nobody ever
speaks of them though. What's up? TIA....
--
duke | A: Yes. |
| >Q: Are you sure? |
| >>A: Because it reverses the logical flow of conversation. |
| >>>Q: Why is top posting frowned upon? |
Clever Monkey
> In the Epilogue, "Forth's Effect on Thinking" in Leo Brodie's book,
> "Thinking Forth", Mark Bernstein is quoted as follow:
>
> ". . . The idea of of "human scale" is, I think, today's seminal concept
> in software design. This isn't specifically a Forth development; the
> great joy of UNIX, in its youth at least, was that you could read it
> (since it was written in C), understand it (since it was small), and
> modify it (since it was simple). Forth shares these virtues, although
> it's designed to tackle a different sort of problem."
>
> What does Bernstein mean by "it's [Forth] designed to tackle a different
> sort of problem [than C]." With the answer to this question, I hope to
> zero-in on "what Forth is best suited for?".
>
you might get a pretty wide range of answers to that question.
Mostly because...
> For some reason, I had assumed that Forth could be considered a
> general-purpose language -- like C, eg. Maybe I was mistaken. I observe
> that the IT industry adopted C as opposed to Forth. I'm curious as to
> why this happened? Is there *something* inherently counter-productive
> about Forth that would have it be shunned by so many? Why has the cream
> not risen to the top?
>
... Forth, like C is a general-purpose programming language which can be
used to solve a great number of problems.
I'm not sure "shunned" is the right way to look at it. Forth is, like
many languages, a niche language. If not for the very existence of the
Unix system and how close Unix was to early computing in universities C
might be even more of a niche language than it is already becoming.
Both are suited for ideal problem spaces. Those problem spaces may be
ill-defined in some ways, but most people certainly have a feel for the
appropriateness of a tool.
I wouldn't recommend someone use C or Forth to make a web site go, for
example, though both have been used for this purpose. I probably
wouldn't reach for Java or Ruby if I was bit-banging. I'm sure other
people have found a way to make that work quite well.
Duke Normandin
I used the word "shunned" because it almost appears that way, especially
after reading Leo Brodie's book. Doing it the "Forth Way" is such a
no-brainer that I'm wondering *why* Forth has not been accepted. Why
would the IT community not automatically turn to Forth? Why did Linus
Torvald choose C to do his Linux kernel? Why is the microkerneled Minix
written in C and not Forth? Why are there no Forth ports of the monolithic
Unix kernels? I would have though that a Unix clone written in Forth
would be such a "trophy"! I'm just curious! Looking back, it seems to me
that Forth was not always a "niche" language. So what held it back? It
seems to be such an "ideal" general programming tool -- why is nobody
else "seeing" this?
>
> Both are suited for ideal problem spaces. Those problem spaces may be
> ill-defined in some ways, but most people certainly have a feel for the
> appropriateness of a tool.
>
> I wouldn't recommend someone use C or Forth to make a web site go, for
> example, though both have been used for this purpose. I probably
> wouldn't reach for Java or Ruby if I was bit-banging. I'm sure other
> people have found a way to make that work quite well.
I hear you!
pablo reda
why ?
nobody know....
I think FORTH is the BEST programing for EVER.
some people say.. is not good for business and then... not
propagate...I'm not agree with this.
try to talk with some C guru and you feel the guy love the
complication... but when he look a forth source code say.. too
complicated, not understand.
I think now, not more ask this question, simple work my contrib, some
day, in the future, the SO of 5-blueRay what need 5GB of RAM to work
be reemplaced by a 16KB SO writen in forth, for this community sure.
I work in C for living, I like work in Forth but nobody in my city use
FORTH !!
(I have a one person FIG ;)
you can imagine my expectation of the grown of forth.
Andreas Kochenburger
> BTW, who is the official Forth "flag-bearer" these days?
Forthers never line up behind flags !
--
Andreas
-------
MinForth: http://minforth.net.ms/
Paul E. Bennett
[%X]
> BTW, who is the official Forth "flag-bearer" these days? FIG? IAFR?? Are
> either still alive? I see their websites are still warm. Nobody ever
> speaks of them though. What's up? TIA....
Did you mean the web-site at Bournemouth. This is placed there by Peter
Knaggs and the only IAFR references on it do not give any other web-sites
that would apply. They do, however, mention a snail mail address. If you
have a different link I am sure it would be appreciated.
As for what is Forth best used for. I will give my, obviously biased,
opinion. Forth is best used in High Integrity Systems that require sound
certification of the quality, safety and dependability. It's failry useful
for any other type of system too.
--
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Duke Normandin
> Duke Normandin wrote:
>
> [%X]
>
>> BTW, who is the official Forth "flag-bearer" these days? FIG? IAFR?? Are
>> either still alive? I see their websites are still warm. Nobody ever
>> speaks of them though. What's up? TIA....
>
> Did you mean the web-site at Bournemouth. This is placed there by Peter
> Knaggs and the only IAFR references on it do not give any other web-sites
> that would apply. They do, however, mention a snail mail address. If you
> have a different link I am sure it would be appreciated.
>
> As for what is Forth best used for. I will give my, obviously biased,
> opinion. Forth is best used in High Integrity Systems that require sound
> certification of the quality, safety and dependability. It's failry useful
> for any other type of system too.
>
When you say "High Integrity Systems", do you mean or imply that Forth
is extensively used at nuclear reactor sites, eg, or by NASA and other
space exploration agencies, as another example? Or in the robotics
industry? I'm certain I've missed a few Forth niches! ;) If *that's* the
case, than Forth is a *significant* programming language in this planet's
human endeavors.
BTW, I did mean Bournemouth. No, I have no other links.
Duke Normandin
Hello Pablo!
Maybe we should initiate a Skype FIG ;))
I had an old friend (now deceased) who often said to me:
"if you are so smart, why are you NOT rich?"
A current friend asked me the other day:
"if Forth is so good, why is it almost a "dead" language, like Latin?"
I did not know how to answer him!! Yet Leo Brodie's book, and all the
other literature that I've read about the "Forth Way" makes sense to me.
I sense that Lisp and Scheme are suffering for the same reasons -
whatever they are. L8r....
Paul E. Bennett
> On 2007-03-16, Paul E. Bennett <p...@amleth.demon.co.uk> wrote:
>> Duke Normandin wrote:
[%X]
> When you say "High Integrity Systems", do you mean or imply that Forth
> is extensively used at nuclear reactor sites, eg, or by NASA and other
> space exploration agencies, as another example? Or in the robotics
> industry? I'm certain I've missed a few Forth niches! ;) If *that's* the
> case, than Forth is a *significant* programming language in this planet's
> human endeavors.
It has been used in some nuclear facilities, quite a few robotics projects,
banking smart cards and terminals, medical devices, parcel tracking
systems, race cars, airport systems, and even in space. Quite probably it
has been used in more applications than people realise because it could be
the code in so many embedded systems. Whether any of the uses could be
classed as extensive is asking for quite a subjective comparison on too
little data. This lack of data is mostly due to the lack of declaration of
the programming language used for many embedded devices.
> BTW, I did mean Bournemouth. No, I have no other links.
Thanks anyway.
pablo reda
>I had an old friend (now deceased) who often said to me:
>"if you are so smart, why are you NOT rich?"
better that one rich, more people healthy...or better...i am not a
smart guy
lisp is too many (((()))(()()()())))((((()), RPN is better.
you can see the JOY languaje, is a LISP in RPN..very nice
Albert van der Horst
Duke Normandin <dnorm...@bsdrocksperlrolls.com> wrote:
>On 2007-03-16, Clever Monkey <clvrmnky...@hotmail.com.invalid> wrote:
>
>I used the word "shunned" because it almost appears that way, especially
>after reading Leo Brodie's book. Doing it the "Forth Way" is such a
>no-brainer that I'm wondering *why* Forth has not been accepted. Why
>would the IT community not automatically turn to Forth? Why did Linus
>Torvald choose C to do his Linux kernel? Why is the microkerneled Minix
>written in C and not Forth?
Because Torvald put the roof on the house that Stalman built.
That house was written in C. The compiler, the utilities, the drivers,
everything. Torvald would have got nowhere with Forth.
<SNIP>
>I hear you!
>--
>duke | A: Yes. |
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Bruce McFarling
> A current friend asked me the other day:
> "if Forth is so good, why is it almost a "dead" language, like Latin?"
Rumors of Forth's death are greatly exagerated.
It did not achieve the explosive growth of the microcomputer
market as a whole from the mid-1980's on, but it never died.
And if the OLPC project meets its goals, there will be 100m's
new Forth system distributed ... with the large majority of
users completely oblivious to its existence in the device.
Andreas Kochenburger
> Quite probably it
> has been used in more applications than people realise because it could be
> the code in so many embedded systems. Whether any of the uses could be
> classed as extensive is asking for quite a subjective comparison on too
> little data. This lack of data is mostly due to the lack of declaration of
> the programming language used for many embedded devices.
Asking Google doesn't make much sense but anyhow, for fun:
I let google.de browse for "embedded programming language"
#63 SwiftX was the first Forth hit
"embedded system programming language" had no Forth hits on the first 10
pages
In the 21st century there are even Java, Ada, C++ compilers for embedded
devices.
In our DCS the language is decided by the choice of subsystems. On low
systems level it is a specific command language (kind of assembler for
realtime systems) and C, the upper layer uses Java.
We use the drivers and libraries that come along with the boards. So
there is no freedom to chose a language. I believe it is a similar in
most other situations for embedded device programming.
hel...@gmail.com
> Is there *something* inherently counter-productive
> about Forth that would have it be shunned by so many?
There is something very counter-productive that makes other people
more productive. A FORTH program tends to be written in its own
language. So after some lines of code the "original" FORTH languages
starts to fade - you'll hardly see more than some DUPs, DROPs, SWAPs
that you know from your favourite FORTH-book. At the "same point" in a
C-source, the C-programmer usually should be able to see better what
the flow of the program really is - since in C many things (that are
"factored out" in FORTH) are re-written at each point they are used.
So if you have a project with say 100 Programmers involved - all on
different level of experience - something like C tends to be better to
maintain. You could do the same project with say 10 good FORTH
programmers, but if you later want the 11th to join the project, he
has to mentally follow all the work the 10 did, before he can do
something substantial.
-Helmar
Frank Buss
> It has been used in some nuclear facilities
That's interesting, do you have any references? For such safety critical
systems I would assume that they use some formal specification and a
language which supports automatic proving of the program, like SparkADA.
Is it possible to prove the correctness of a Forth program, e.g. like it is
possible for a subset of Pascal with the Hoare logic (
http://en.wikipedia.org/wiki/Hoare_logic ) ?
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Andreas Kochenburger
> Paul E. Bennett wrote:
>
>> It has been used in some nuclear facilities
>
> That's interesting, do you have any references? For such safety critical
> systems I would assume that they use some formal specification and a
> language which supports automatic proving of the program, like SparkADA.
>
> Is it possible to prove the correctness of a Forth program, e.g. like it is
> possible for a subset of Pascal with the Hoare logic (
> http://en.wikipedia.org/wiki/Hoare_logic ) ?
>
I guess that it is not possible to prove Forth programs as a general
rule, eg. because of ?DUP. But I am no mathematician either so I may be
wrong here (And perhaps it is possible by analyzing "decision trees" for
varying stack flow patterns)
Since Forth is as flexible as assembler, and does not support Design by
Contract, everyone has to set up his own software QA policy.
Concerning common programmer mistakes, I find this site interesting
http://www.cert.org/secure-coding/
Paul E. Bennett
> Frank Buss wrote:
>> Paul E. Bennett wrote:
>>
>>> It has been used in some nuclear facilities
>>
>> That's interesting, do you have any references? For such safety critical
>> systems I would assume that they use some formal specification and a
>> language which supports automatic proving of the program, like SparkADA.
>>
>> Is it possible to prove the correctness of a Forth program, e.g. like it
>> is possible for a subset of Pascal with the Hoare logic (
>> http://en.wikipedia.org/wiki/Hoare_logic ) ?
>>
>
> I guess that it is not possible to prove Forth programs as a general
> rule, eg. because of ?DUP. But I am no mathematician either so I may be
> wrong here (And perhaps it is possible by analyzing "decision trees" for
> varying stack flow patterns)
> Since Forth is as flexible as assembler, and does not support Design by
> Contract, everyone has to set up his own software QA policy.
With Forth at the low level being considered a kind of assembler but being
able to stretch its scope to very abstracted levels I consider that formal
mathematical proof of thecode would be extremely difficult unless you
restrict yourself, like they do in all other "safer" languages, to a subset
or pre-qualified constructs that have proven safer in use.
Forth gives you a great deal of freedom and as Andreas states, "everyone has
to set up his own software QA policy" which would also imply that the
management of the development process must also reflect the importance of
the need to get it right.
You can, after all, be quite unsafe in Ada and Prolog (or any other
language) if you do not adhere the rules for building safe systems.
I have been reading the latest Embedded Systems Engineering Magazine (March
2007 edition) that dropped through my door this morning (while having a
leisurely breakfast) and lighted on an article titled "Don't let a File
System let you down". Despite the fact that it is written by a
representative of a company promoting their product for windows based
systems, it makes a lot of sense. The topic is the enforcement of atomic
writes for the data in your file-system (see http://www.esemagazine.com/ in
a couple of weeks time when the article may appear on their web-site).
> Concerning common programmer mistakes, I find this site interesting
> http://www.cert.org/secure-coding/
A useful link Andreas, Thanks. I have bookmarked it for future reference.
Paul E. Bennett
> Paul E. Bennett wrote:
>
>> It has been used in some nuclear facilities
>
> That's interesting, do you have any references? For such safety critical
> systems I would assume that they use some formal specification and a
> language which supports automatic proving of the program, like SparkADA.
Not all system applications in nuclear facilities are Safety Critical and
there are various types of nuclear facility. I have used Forth in three
such facilities myself but cannot say any more than only two of them had
any Safety Critical role and that none of them are directly connected to
reactors (although I would not see that as much of a problem). I programme
in Forth and/or Assembler (but mostly Forth) whenever I have to write the
software.
I have also encouraged some very Forth-like techniques in other systems I
have been involved in where others chose to programme the applications in
different languages. This was due to my ability to demonstrate the
techniques in Forth on hardware I was developing for the company I was
working for at the time.
> Is it possible to prove the correctness of a Forth program, e.g. like it
> is possible for a subset of Pascal with the Hoare logic (
> http://en.wikipedia.org/wiki/Hoare_logic ) ?
Probably not in the way you are thinking of but then it may be difficult to
do that for any language. Formal Methods may be more useful in proving that
you are starting from a sound specification when the specification is
extremely complex to start with.
Most of the systems I deal with I can see ways of making a great deal of
simplification by appropriate factoring and structuring of the system
architecture. Using Forth as the programming language then makes it almost
a trivial exercise to certify the code (word by word) as correct by
inspection and relatively easy to prove correct by test (but constructing
the tests may exercise the grey cells quite extensively).
See also my response to Andreas Kochenburger.
I have given papers on the topic of deleoping High Integrity Systems with
Forth in the Safety Systems Syposium conferences. This paper;-
<http://www.amleth.demon.co.uk/library/papers/scsc/sss98.htm> is online at
my web-site and the paper I gave jointly with Malcolm Bugler at the
EuroForth conference at Schloss Dahgstull is, I think, online at the
EuroForth website hosted by Peter Knaggs at Bournemouth.
Duke Normandin
Hello Helmar...
Makes sense! I can see where Forth could be useful for 1-2 man
bit-banging projects --- like writing device drivers, or the boot loader
on my favorite FreeBSD system.
Duke Normandin
Hello Andreas....
So are you saying that even within the "embedded" niche, Forth is not a
language of choice? ;(
Andreas Kochenburger
> On 2007-03-17, Andreas Kochenburger <a...@nospam.org> wrote:
>> We use the drivers and libraries that come along with the boards. So
>> there is no freedom to chose a language. I believe it is a similar in
>> most other situations for embedded device programming.
>>
>
> Hello Andreas....
>
> So are you saying that even within the "embedded" niche, Forth is not a
> language of choice? ;(
You have to stand on somebody's shoulders. If there is a development
system for your hardware, you use it. If it crashes your project, you
can kick the supplier. When you start developing your own drivers or
your own Forth development system, be ready to bear the consequences.
For me Forth is a good debugging tool, but above the hardware access
level. It can be linked in as C source and provides a script engine (a
bit like LSE) and interactive shell for backdoor inspections. Don't
laugh: DUMP is your friend then.
So Forth is a kind of Swiss Army knife, but not a language of choice
(unless you really do bare bone development, eg. cross-compilation for
embedded targets).
But don't take it as a religious statement. Other people work in other
contexts.
John Doty
> So are you saying that even within the "embedded" niche, Forth is not a
> language of choice? ;(
People working in that niche rarely choose it. Development kits rarely
include Forth (C and Basic are far more common). So it's a niche within
a niche.
My biggest current use of Forth (my LSE64 dialect) is on a desktop
machine that controls custom scientific instruments. It's especially
handy in the phase of the project where you're debugging the hardware
and software together.
--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
Cesar Rabak
> In article <tzCKh.121497$cE3.4856@edtnps89>,
> Duke Normandin <dnorm...@bsdrocksperlrolls.com> wrote:
>> On 2007-03-16, Clever Monkey <clvrmnky...@hotmail.com.invalid> wrote:
> <SNIP>
>> I used the word "shunned" because it almost appears that way, especially
>> after reading Leo Brodie's book. Doing it the "Forth Way" is such a
>> no-brainer that I'm wondering *why* Forth has not been accepted. Why
>> would the IT community not automatically turn to Forth? Why did Linus
>> Torvald choose C to do his Linux kernel? Why is the microkerneled Minix
>> written in C and not Forth?
>
> Because Torvald put the roof on the house that Stalman built.
> That house was written in C. The compiler, the utilities, the drivers,
> everything. Torvald would have got nowhere with Forth.
>
Minix was written by Tanenbaum, not Torvalds...
_My_ interpretation why is this way: it stems C is more "Pascal like"
which used to be the freshman's programming language in Comp Sci courses
thaught at the time those works were in the first edition.
After the initial 'success' it become legacy and with very few
exceptionsš, get never rewritten in another programming language.
--
Cesar Rabak
[1] The ones I recall are OT here
Cesar Rabak
Cesar Rabak
> Paul E. Bennett wrote:
>> Quite probably it
> We use the drivers and libraries that come along with the boards. So
> there is no freedom to chose a language. I believe it is a similar in
> most other situations for embedded device programming.
>
Same situation here. We in our lab we say we don't have 'an echo system
for Forth' for the HW we have to work with.
Bruce McFarling
Ah, but 0.001% of a couple of hundred million is still a noticeable
number.
Bruce McFarling
> Why did Linus Torvald choose C to do his Linux kernel?
Because it was supposed to be a Unix-like kernel, starting as
a rewrite of the Minix kernel, intended to be a Unix-like
system for a PC as a teaching tool.
You aren't teaching people how Unix systems work if you don't
teach them in C. And Unix was the university research system
it was in part because Bell Labs was under monopoly regulation
and could not commercialize Unix, and in any event giving
the early Unix systems away for free for non-commercial
educational uses was more valuable as window dressings a large
regulated private monopoly than the commercial value that it
would have represented.
Its like asking with Burgundy is a province in France, rather
than Isle-de-France being a province of Burgundia. History is
like that.
Cesar Rabak
At least in this corner of the world, the last 'public awareness' of
Forth was the mention of a ROUV that helped to find Titanic had been
programmed in Forth. . . long time ago!
Duke Normandin
*Minix* was/is a teaching tool written by Tannenbaum (sp?) but designed
around a micro-kernel instead of the usual monolithic kernels of various
flavors of Unix. As well, Tannebaum was not teaching C, rather OS
theory and design, etc.
Torvald *was not* writing a teaching tool. As such, he could have chosen
any language to write his Unix-like OS. He chose C, because Minix was
written in C. My point is, if Forth is so overwhelmingly better at
bit-banging, why has it, by and large, been ignored? I would have
thought eg that a small Unix-like micro-kerneled OS would have been easy
to do for a core of Forth developers. All the "plug-ins" to the
microkernel could have been done in Forth as well. Would that not have
show-cased Forth well? That's just one example. Bit-banging GUI screen
would seem to me to be right up Forth's alley. No?? I'm just curious
here. I'm still reading Leo Brodie's book -- and it *still* makes a
whole lot of sense -- in theory. I'm wondering why the IT industry as a
whole hasn't caught on. I'm missing a piece of this puzzle!!
Bernd Paysan
> Why did Linus Torvald choose C to do his Linux kernel?
According to one of Linus' books, he had some exposure to Forth in his
Sinclair-QL days, but he didn't grok it. When you look at how many things
Linus failed to understand (and often still fails to understand), I suggest
the following explanation: Linus is good enough to do the job, and bad
enough to allow lots of other people to contribute at about the same level.
This network effect allows the effort to be large enough to succeed.
Submissions significantly below Linus' level will be rejected, as well as
suggestions above his level.
Example: A few weeks ago, during discussion about asynchronous IO in Linux
(which is still not really useful), someone brought up active messages
(though he called it differently, because he didn't know what it was - some
xxxlets or so). Active messages are interpreted code (threaded code) that
is presented to another process (here: the kernel AIO context), and
executed there. Active messages are decades old, and a way to make
microkernels and clusters work fast and efficient - when you use them, all
the arguments against microkernels fall apart. Linus didn't like them;
discussion more or less closed (maybe they'll reappear in a year or two -
Linus often accepts ideas he rejected some years ago).
Programmers as a large body are very conservative - the en vogue languages
follow a pretty strict and slow evolution pattern from the previous en
vogue language (Perl as exception of the rule - but Perl is already phased
out and replaced by Python and PHP, which are much more C-like). Often
enough, new ideas which make perfectly sense are rejected by a large enough
group to cause significant problems of adaption. E.g. the Gnome project
even rejected C++ as language for their GUI apps, despite it makes so much
sense to use an object oriented framework in this field. Now, they accept
at least C#, but that seems to be because one important Gnome contributor
leads the effort to clone Microsoft's .NET - and one of Gnome's supporting
companies has put quite some money into Mono.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Elizabeth D Rather
Duke Normandin wrote:
> In the Epilogue, "Forth's Effect on Thinking" in Leo Brodie's book,
> "Thinking Forth", Mark Bernstein is quoted as follow:
>
> ". . . The idea of of "human scale" is, I think, today's seminal concept
> in software design. This isn't specifically a Forth development; the
> great joy of UNIX, in its youth at least, was that you could read it
> (since it was written in C), understand it (since it was small), and
> modify it (since it was simple). Forth shares these virtues, although
> it's designed to tackle a different sort of problem."
>
> What does Bernstein mean by "it's [Forth] designed to tackle a different
> sort of problem [than C]." With the answer to this question, I hope to
> zero-in on "what Forth is best suited for?".
Forth was first designed to run real-time applications in
resource-constrained environments (small memory, slow, etc.), although
early-on there was also a mainframe (IBM 360) version for later data
analysis. C was developed to program Unix, a general-purpose OS, in
medium-to-large size computers. Very different set of objectives and
constraints.
Another consideration is that C is a language that remains close to
classical Algol-type language philosophies and style. In creating
Forth, Chuck Moore went back to first principles and re-thought the
whole issue of relationship between human and computer. As a result,
Forth is very idiosyncratic in style (the reliance on an explicit stack
being only the most obvious manifestation of this). That is a major
source of its power and efficiency, but also has probably made adoption
harder for many folks: it "looks funny" and they back off.
> For some reason, I had assumed that Forth could be considered a
> general-purpose language -- like C, eg. Maybe I was mistaken. I observe
> that the IT industry adopted C as opposed to Forth. I'm curious as to
> why this happened? Is there *something* inherently counter-productive
> about Forth that would have it be shunned by so many? Why has the cream
> not risen to the top?
Several things going on here. As others in this thread have noted, C
was distributed with Unix by Bell Labs, a well-known and respected
company, to computer labs in Universities around the country. It
acquired a lot of credibility because of its origins and distribution
channels.
Forth was initially promoted by a small, underfunded start-up company
(FORTH, Inc.) with a very limited promotion budget and no "name
recognition". If Forth had not been as truly superior as it was, it
would never have gone anywhere. Also, the "IT industry" is much more
focussed on the kinds of applications and environments that Unix and C
targeted than the smaller real-time systems that Forth targeted.
Forth was initially developed in a scientific laboratory, and its early
adopters were scientists. Forth continues to thrive there, and in the
related fields of instrumentation and control systems. It has been used
and taught in university engineering and science depts., though rarely
in Computer Science per se. It appeals to pragmatists who are
interested primarily in getting something to work quickly and
efficiently rather than something which is satisfying on a theoretical
level (which would appeal more to the CS folks).
The advent of PCs in the 80's came with a burst of Forth activity,
spurred first by the Forth Interest Group and hobbyists and then a wave
of implementors providing systems to hobbyist programmers. Although
Forth became better-known in this time frame, it also acquired the
reputation of being a "hobbyist toy", which remains a negative in the
minds of some people who haven't seen Forth in any other context.
> Please no flames! I'm simply trying to get a sense of time and place
> here -- some perspective. Maybe the reason is as simple as why VHS won
> out over Beta. Or maybe it's more complex than that.
I hope this helps.
> BTW, who is the official Forth "flag-bearer" these days? FIG? IAFR?? Are
> either still alive? I see their websites are still warm. Nobody ever
> speaks of them though. What's up? TIA....
There really never has been "an official Forth flag bearer". There is a
FIG group still active in the Silicon Valley area and another in
England. There's an annual conference in Europe (EuroForth). The
principal commercial vendors are FORTH, Inc. in the US and MPE in
England, plus active communities around free systems such as gForth and
Win32Forth.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Elizabeth D Rather
...
> So if you have a project with say 100 Programmers involved - all on
> different level of experience - something like C tends to be better to
> maintain. You could do the same project with say 10 good FORTH
> programmers, but if you later want the 11th to join the project, he
> has to mentally follow all the work the 10 did, before he can do
> something substantial.
As it happens, I have managed several such projects using Forth, and
they worked superbly.
Probably the most famous is the control system for the King Khaled
International Airport at Riyadh, Saudi Arabia. It involved a network of
8 PDP-11's and several hundred custom 8086-based computers controlling
over 32,000 points (analog and digital) across a 100-sq mi area. A
prior group working in Fortran, PDP-11 assembler, and PLM (this was
1984) had invested >100 pgmr-years, producing 300,000 lines of code over
a 3-yr period. Only a small fraction of the spec was implemented, and
that didn't meet the performance requirement. I assembled a team of
about 6 very senior, experienced Forth programmers, and undertook to
train a support team of about 10 newcomers to Forth, who then became
part of the team. Starting completely from scratch, we implemented the
entire system in 18 months, passing all acceptance tests. Our version
outperformed the prior group's by a factor of ten, and delivered 3x the
performance required in the contract.
For a team to work effectively, they must adopt and follow shared
standards for coding (format, naming conventions, internal
documentation, etc.). Beyond that, the only Forth-specific issue that a
project manager needs to be aware of is that Forth programmers will
produce a lot more in a shorter time, so it's important to be very clear
as to requirements and module interfaces to prevent someone from going
too far down an inappropriate road before the problem is detected. Good
communication is essential.
Bruce McFarling
> *Minix* was/is a teaching tool written by Tannenbaum (sp?)
> but designed around a micro-kernel instead of the usual
> monolithic kernels of various flavors of Unix. As well,
> Tannebaum was not teaching C, rather OS theory and design, etc.
But as the first high level language used to implement
a minicomputer operating system, and with a range of
OS-oriented public domain code available, surely C was a
fairly natural choice, for historical reasons.
> Torvald *was not* writing a teaching tool. As such, he
> could have chosen any language to write his Unix-like OS.
> He chose C, because Minix was written in C.
Not just Minix, but a wide range of public domain software
available for a Unix-like system was written in C, so the
two first targets for an endogenous toolchain were a
C-compiler and a compiler for the high level language that
the kernel was written in. Writing the kernel in C makes
that one target.
Stephen J. Bevan
> Example: A few weeks ago, during discussion about asynchronous IO in Linux
> (which is still not really useful), someone brought up active messages
> (though he called it differently, because he didn't know what it was - some
> xxxlets or so).
> Linus didn't like them; discussion more or less closed (maybe
> they'll reappear in a year or two - Linus often accepts ideas he
> rejected some years ago).
It wasn't as if he wrote "I don't like syslets, end of discussion".
He explained his thoughts, see http://lwn.net/Articles/222168/, and
why he sees more utility in the fibril approach. He's interested in
practical problems like aoi_read(), not what syslets *could* be used
for. If someone is convinced that syslets are the way, then they can
argue the case by showing the actual syslet programs that are superior
(by some metric) to alternative approaches.
Consequently, I don't think you picked a good example to make your point.
Duke Normandin
I don't disagree with you on any of your above statements. As 15+ years
Unix user I'm aware of *its* history and lore. C was created to create
Unix and all it's "plugins" and "widgets" ;) So maybe I've answered my
own question. Maybe Unix's C infrastructure was so overwhelmingly
pervasive that everybody simply "went with the flow" so to speak.
I should ask Tannebaum why he chose C to write the Minix microkernel and not
Forth. The monolithic kernel players (Bell/BSD/SCO/SUN/HP etc etc) where
almost "stuck" with C, but it seems to me that Tannebaum could have
opted for Forth to write an even "physically" smaller microkernel for
the machines and the constraints of that era. Curious!
Elizabeth cleared the fog a bit when she suggested that Forth did not
enjoy the exposure that C did right from the start. That explains a lot
of things -- but why not "get in the game" and kick some serious ass in
userland? A Forth-based project like XFree86 or X.Org where its all
bit-banging video stuff -- would be a natural for Forth -- would it not?
What am I missing here?
Duke Normandin
> Sorry to be coming in late to this interesting discussion!
>
> Duke Normandin wrote:
>> In the Epilogue, "Forth's Effect on Thinking" in Leo Brodie's book,
>> "Thinking Forth", Mark Bernstein is quoted as follow:
>>
>> ". . . The idea of of "human scale" is, I think, today's seminal concept
>> in software design. This isn't specifically a Forth development; the
>> great joy of UNIX, in its youth at least, was that you could read it
>> (since it was written in C), understand it (since it was small), and
>> modify it (since it was simple). Forth shares these virtues, although
>> it's designed to tackle a different sort of problem."
>>
>> What does Bernstein mean by "it's [Forth] designed to tackle a different
>> sort of problem [than C]." With the answer to this question, I hope to
>> zero-in on "what Forth is best suited for?".
>
[snip]
> I hope this helps.
It did thanks!
>
>> BTW, who is the official Forth "flag-bearer" these days? FIG? IAFR?? Are
>> either still alive? I see their websites are still warm. Nobody ever
>> speaks of them though. What's up? TIA....
>
> There really never has been "an official Forth flag bearer". There is a
> FIG group still active in the Silicon Valley area and another in
> England. There's an annual conference in Europe (EuroForth). The
> principal commercial vendors are FORTH, Inc. in the US and MPE in
> England, plus active communities around free systems such as gForth and
> Win32Forth.
Do you ever see a time when it would make sense for the Forth community
to unite under some sort of structure to facilitate Forth's growth and
survival?
I made some inquiries at the U. of Calgary (in my area) concerning a
local FIG or even an informal Forth group. I was told that there once
was an active and vibrant Forth community here with roots in the
oilpatch. No more! Dead some 15 years. ???????
ken...@cix.compulink.co.uk
Normandin) wrote:
> For some reason, I had assumed that Forth could be considered a
> general-purpose language -- like C,
But is C a general purpose language? Come to that are there any general
purpose languages at all? As I understand it C was written to provide a
language to write operating systems not applications. Fortran was
written for mathematicians and Cobol for business etc.
Ken Young
Duke Normandin
> Duke Normandin wrote:
>> Why did Linus Torvald choose C to do his Linux kernel?
>
> According to one of Linus' books, he had some exposure to Forth in his
> Sinclair-QL days, but he didn't grok it. When you look at how many things
> Linus failed to understand (and often still fails to understand), I suggest
> the following explanation: Linus is good enough to do the job, and bad
> enough to allow lots of other people to contribute at about the same level.
> This network effect allows the effort to be large enough to succeed.
> Submissions significantly below Linus' level will be rejected, as well as
> suggestions above his level.
I agree! Tannebaum would have stronger words than that! I guess Linus
was one of his students for .5 of a semester or maybe longer. There has
always been a question as too how much of Tannebaum's code was used in
the initial Linux kernel. Tannebaum has a webpage(s) on this matter
somewhere. But I'm sure that Linus had *no* inclination to start the
kernel from scratch -- be it in Forth or otherwise.
[snip]
> Programmers as a large body are very conservative - the en vogue languages
> follow a pretty strict and slow evolution pattern from the previous en
> vogue language (Perl as exception of the rule - but Perl is already phased
> out and replaced by Python and PHP, which are much more C-like). Often
> enough, new ideas which make perfectly sense are rejected by a large enough
> group to cause significant problems of adaption. E.g. the Gnome project
> even rejected C++ as language for their GUI apps, despite it makes so much
> sense to use an object oriented framework in this field. Now, they accept
> at least C#, but that seems to be because one important Gnome contributor
> leads the effort to clone Microsoft's .NET - and one of Gnome's supporting
> companies has put quite some money into Mono.
I hear you! Mass momentuum is a powerful force - including its opposite,
lethargy. Bernd, if *you* (et al) can do Minos, the Forth community
should be able to get in the game and do "Forthix" [TM] ;)) Wouldn't
that be cool? Do you think it's do-able?
Duke Normandin
C was written in order to crank out Unix and all the other little helper
programs that Unix relies on to make the computer useful. I'm not a C
programmer although I've hacked some useful C code. C can pretty much
tackle most tasks - some more elagantly than others, depending on the
eloquence of the programmer. :)) I agree that each language is best
suited as a tool to tackle certain categories of tasks. A
general-purpose language to my mind is one whose scope of categories it
can service is broadest.
Cesar Rabak
> On 2007-03-17, Bernd Paysan <bernd....@gmx.de> wrote:
>> Duke Normandin wrote:
>>> Why did Linus Torvald choose C to do his Linux kernel?
> I hear you! Mass momentuum is a powerful force - including its opposite,
> lethargy. Bernd, if *you* (et al) can do Minos, the Forth community
> should be able to get in the game and do "Forthix" [TM] ;)) Wouldn't
> that be cool?
Probably yes, but...
> Do you think it's do-able?
Not with the resources and available volunteers that know Forth.
I feel I'll need to go a little off topic here to present my point, so
bear with me for a few lines:
The Linux kernel is a part of a big system which has been developed
around a lot of GNU tools. There is even a small 'controversy' between
FSF and Linuxers about the way to refer to Linux FSF's preference being
that it always was mentioned as "GNU/Linux".
So besides the existence of the ideas for Minix and some Unix code
commented in books already in C, there is also the availability of the
GNU tools for producing the (which became) Linux kernel.
Linus would have to be very comfortable reading C and doing all the
kernel in Forth but even so, it would have received less contribution
from the community (for device drivers, etc.) to foster the development
of Linux (even thinking of the kernel only).
To add, we have then the FSF Standards
http://www.gnu.org/prep/standards/standards.html#Source-Language suggesting:
<quote>
3.1 Which Languages to Use
When you want to use a language that gets compiled and runs at high
speed, the best language to use is C. Using another language is like
using a non-standard feature: it will cause trouble for users. Even if
GCC supports the other language, users may find it inconvenient to have
to install the compiler for that other language in order to build your
program. For example, if you write your program in C++, people will have
to install the GNU C++ compiler in order to compile your program.
.
.
.
</quote>
--
Cesar Rabak
Stephen J. Bevan
> I agree! Tannebaum would have stronger words than that! I guess Linus
> was one of his students for .5 of a semester or maybe longer.
Guess again.
> There has always been a question as too how much of Tannebaum's code
> was used in the initial Linux kernel.
If one's name is Ken Brown perhaps; he did the obvious thing and
compared Minix with early Linux, the following is a quote from an
article about that work :-
For his research, Mr. Brown hired a University of Maryland, College
Park, student, Alexey Toptygin, to run software that could find
matches between Minix and the early Linux. But there were none. We
know this not because it is in the study -- Mr. Brown conspicuously
omits mention of that. Instead, Mr. Toptygin, appalled by the way Mr.
Brown was ignoring the evidence, posted his work online. (He also
refused his paycheck.)
Howerd
On 16 Mar, 18:53, Duke Normandin <merr...@telus.net> wrote:
[snip]
> What does Bernstein mean by "it's [Forth] designed to tackle a different
> sort of problem [than C]." With the answer to this question, I hope to
> zero-in on "what Forth is best suited for?".
This is a very interesting question ;)
Ask any five Forthers and you'll get at least six answers...
> For some reason, I had assumed that Forth could be considered a
> general-purpose language -- like C, eg. Maybe I was mistaken.
I don't think that C is general purpose, in the way that it is used.
Its true that C is a platform independent assembler (with extra
features) which makes it look "general purpose" in the sense of being
applicable to more than one set of hardware.
But in popular use, C provides an extremely specific "system" , well
adapted to the business environment of the software industry.
A system C provides :
Source code in files
an editor
a compiler
a linker
a platform independent assembler
platform independent libraries ( e.g. maths )
platform dependent device drivers ( e.g. an LCD interface )
a compiled binary ( weakly encrypted ) program delivery system, with
header files
The way C is used in medium to large companies ( who have the money to
support its use ) is to have one or two very well paid "gurus", and 10
to 100 well paid "code monkeys". Since the "code monkeys" can't modify
the language ( except by using #define , typedef etc which must be
controlled! ), their output is readable by anyone - they can't do too
much damage.
The function of the "gurus" is to solve difficult compiler-feature
type problems.
All of this is expensive, so the source code is made proprietary, and
only the compiled ( weakly encrypted ) binaries are exposed to the
outside world.
If you take away any of these features there are negative financial
implications.
OTOH, Forth _is_ completely general purpose - one "code monkey" could
bring down the system e.g. : variable constant ;
Since Forth is so general purpose, you could develop a dialect that
had the same sort of features as C - once you decide to do this you
must ask some difficult questions :
Do you really want RPN? Of course not! You don't want to have to
retrain people away from what they were taught at 5 years old.
Do you allow people to redefine "key words"? No!
How do you export encypted programs, and let the end user access your
functions? Better add header files.
How do you make the language so complicated that only "gurus"
understand it in depth? Make it more abstract.
BTW you need "gurus" to provide a career path for the "code
monkeys"...
If you make all of the required changes you will end up with something
very like C.
If you then do a simple financial calculation, is it worth making
these changes?
We already have C, its the de-facto standard, everybody knows it, its
taught in schools etc...
What you need to do is make languages that look like C, but have
better features - C++ C# Java etc
This is just the policy of "continuous improvement" which you see in
every industry from mobile phones to cars.
Forth is completely different:
A Forth system provides an editor, compiler and interpreter - maybe
not as separate entities.
colorForth does not use files, ANS Forth does.
For a Forth chip the compiler is the assembler.
You may or may not have compiled binary support, so libraries may be
only available in source form, and even if they are pre-compiled, the
compilation process is so simple that reverse engineering is just
about re-inventing sensible names for the functions.
Any "code monkey" can learn Forth in a few weeks, with a complete
understanding of the system.
No "guru" can understand all of Forth - there's always something new
that gets developed for the current application.
Someone who is an expert in a particular problem-domain can be more
productive than a veteran Forth programmer in a matter of weeks or
months, so it makes it difficult to justify the "guru's" salary.
So the "guru" feels unwanted, and goes to a comfortable C-company.
The "code monkeys" have no career path, so they quit programming and
become chartered accountants.
What is Forth good for?
Interacting with complex systems, such as computers.
This is one answer of many I could give...
Regards
Howerd 8^)
winston...@yahoo.com
> In the Epilogue, "Forth's Effect on Thinking" in Leo Brodie's book,
> "Thinking Forth", Mark Bernstein is quoted as follow:
>
> ". . . The idea of of "human scale" is, I think, today's seminal concept
> in software design. This isn't specifically a Forth development; the
> great joy of UNIX, in its youth at least, was that you could read it
> (since it was written in C), understand it (since it was small), and
> modify it (since it was simple). Forth shares these virtues, although
>
> What does Bernstein mean by "it's [Forth] designed to tackle a different
> sort of problem [than C]." With the answer to this question, I hope to
> zero-in on "what Forth is best suited for?".
>
> that the IT industry adopted C as opposed to Forth. I'm curious as to
> why this happened? Is there *something* inherently counter-productive
> about Forth that would have it be shunned by so many? Why has the cream
> not risen to the top?
>
I've been wanting to reply, but I feel my information may not be
correct. So I will pose it in the form of a question, since most of
the Forths of the era when C was winning the marketplace that I know
were FIG.
Was there a commercially available Forth that had a compiler that
compiled to native code?
All the FIG Forths I knew were interpreted. Turbo Pascal defeated UCSD
Pascal on the basis of speed. UCSD Pascal was closer to standard
Pascal, had more features, but lost just on the concept of speed. It
was portable, even.
C had been around for a while, and the compilers always compiled to
native code. Fast was the major reason compilers won the day, and look
at how we still measure based on speed? Only Java goes around saying
"We are more secure!"... For a while, that is all they could say,
until JIT and the inclusion of built-in profilers...
Ben
Andreas Kochenburger
> All the FIG Forths I knew were interpreted. Turbo Pascal defeated UCSD
> Pascal on the basis of speed. UCSD Pascal was closer to standard
> Pascal, had more features, but lost just on the concept of speed. It
> was portable, even.
>
> C had been around for a while, and the compilers always compiled to
> native code.
Apple was nearly dead at that time. The little Turbo Pascal hype was
spurred by the change from home computers to PCs. TP had an innovative
GUI and it was not BASIC. And don't forget the long columns of TI and HP
calculator programs in the PC magazines. Often interesting examples with
graphics (remember sprites?), sound, little games or real-world programs
(eg. mortgage calculation).
Forth programs were rare in the magazines. Mostly just integer math and
esoteric systems programming. How boring.
I remember a German article series where some guys implemented a
fig-Forth compiler in Turbo Pascal. The Pascal part was far more
educating than the Forth part.
winston...@yahoo.com
> winston19842...@yahoo.com wrote:
> > All the FIG Forths I knew were interpreted. Turbo Pascal defeated UCSD
> > Pascal on the basis of speed. UCSD Pascal was closer to standard
> > Pascal, had more features, but lost just on the concept of speed. It
> > was portable, even.
>
> > C had been around for a while, and the compilers always compiled to
> > native code.
>
> Apple was nearly dead at that time. The little Turbo Pascal hype was
> spurred by the change from home computers to PCs. TP had an innovative
> GUI and it was not BASIC. And don't forget the long columns of TI and HP
> calculator programs in the PC magazines. Often interesting examples with
> graphics (remember sprites?), sound, little games or real-world programs
> (eg. mortgage calculation).
Not really a GUI. Text mode, with Extended-ASCII "line" characters.
The compiler seemed more tightly integrated with the editor (I don't
remember even early versions having to access the drive to load the
compiler or editor). UCSD did have the ability to put you back in the
editor on the line with an error during a compile, even though the
compiler and editors were separate programs.
Not sure there was really a difference, except that Turbo was run from
a DOS prompt and UCSD was a different filesystem (at least early PC
versions were).
And yes, I remember sprites. Still have a TI-99 setup in the other
room. TI Forths were interesting because they gave you full access to
the graphics capabilities of the TI-99, that the BASICs did not. And
they weren't just merely "sandboxes" to play with the graphics either,
but full-featured versions of fig-Forth. I remember Wycove came with a
version of "breakout" in the manual. I was really impressed. That
speed couldn't even be approached in BASIC.
> Forth programs were rare in the magazines. Mostly just integer math and
> esoteric systems programming. How boring.
Sounds like not much has changed...
J Thomas
<winston19842...@yahoo.com> wrote:
> Was there a commercially available Forth that had a compiler that
> compiled to native code?
It depends on just what time you're talking about, but in general the
answer is no. For that matter the first native-code compilers didn't
do much if any optimising. After some discussion there was a consensus
that you got the best speed by keeping the top stack item in a
register but not the second stack item.
As late as 1994 Forth experts were saying that it wasn't worth it to
have a Forth graphics standard because even after you supply a bunch
of graphics primitives still the Forth code that calls the primitives
would be too slow to be usable.
> All the FIG Forths I knew were interpreted. Turbo Pascal defeated UCSD
> Pascal on the basis of speed. UCSD Pascal was closer to standard
> Pascal, had more features, but lost just on the concept of speed. It
> was portable, even.
>
> C had been around for a while, and the compilers always compiled to
> native code. Fast was the major reason compilers won the day, and look
> at how we still measure based on speed? Only Java goes around saying
> "We are more secure!"... For a while, that is all they could say,
> until JIT and the inclusion of built-in profilers...
Yes, speed has been considered far more important than its effect on
performance would justify. I never knew of a FIG Forth that was
interpreted, though they had an "inner interpreter" which was a short
stretch of machine code that executed Forth tokens. Far faster than
interpreting text.
It would have made sense to do a lot of coding in Forth and then
translate to C for speed once the implementation was rock-solid
stable, and test the C version against the known-good Forth results.
Provided that increase in speed was considered worth the expense of
the translation. I dunno. It's kind of like the C guys were saying "C
programmers are real professionals, everybody else are weenies. Do it
in C if you want a professional product." And they got away with it,
partly because C gave a result that was faster and because everybody
thought it was harder to program in. If you do something that's harder
to do and that gets better results, you must be better and more
professional, right?
But that's mostly over now. An employer can call a temp agency on
Wednesday and ask for 50 code monkeys and have 50 C programmers
sitting at their terminals on Monday. There isn't so much status in
computer languages now. Now to the extent there's status it's more in
being a developer, in being the sort of manager who can actually get
productive results from code monkeys. I hear things like "We're
running mostly Java, with .NET. We're nimble and our results are
robust. We have 20 programmers working on 35 projects with 28
partners. We shift people to wherever they're needed and they're
productive from the first hour, our team members are interchangeable.
They have to be." If you want more respect than the guys who're
getting outsourced, you need to perform special tricks.
Albert van der Horst
>Albert van der Horst escreveu:
>> In article <tzCKh.121497$cE3.4856@edtnps89>,
>> Duke Normandin <dnorm...@bsdrocksperlrolls.com> wrote:
>>> On 2007-03-16, Clever Monkey <clvrmnky...@hotmail.com.invalid> wrote:
>> <SNIP>
>>> I used the word "shunned" because it almost appears that way, especially
>>> after reading Leo Brodie's book. Doing it the "Forth Way" is such a
>>> no-brainer that I'm wondering *why* Forth has not been accepted. Why
>>> would the IT community not automatically turn to Forth? Why did Linus
>>> Torvald choose C to do his Linux kernel? Why is the microkerneled Minix
>>> written in C and not Forth?
>>
>> Because Torvald put the roof on the house that Stalman built.
>> That house was written in C. The compiler, the utilities, the drivers,
>> everything. Torvald would have got nowhere with Forth.
>>
>
>Minix was written by Tanenbaum, not Torvalds...
I'm not talking about an operating system here. I'm talking
about gcc, ls rm mv find rcs cut split man ....
I'm talking abot a mass-movement involving millions.
If anything the failure of Minix and Tanenbaum demonstrate
the genius of Stalman.
- Minix was never intended to be a commercial contender
in the world of operating systemx
- Stalman started with two tools: emacs and gcc, both crucial
to any endeavour to stand your own in a world of commerce
At that point already he had his mind set: Gnu is Not Unix.
- Tanenbaum had its penchant of gcc: the Amsterdam Compiler
Kit. It was semi-commercial, and in 1998 I was in a situation
to try to get a source licence. It is orphaned to the point
that it is a legal nightmare to even find out who the current
owner is.
(I ended with patching gcc to match the libraries written
for ACK.)
- Compare that to Stalman. Even as a software genius, he didn't
overlook he was on an endeavour that had far reaching
consequences for the society at large.
At a time nobody realized that Intellectual Propery was
going to be an issue, he recruited some of the best legal
minds of left-wing US academia and built and unassailable
legal bastion.
Of course now the ghost is out of the bottle.
Linus only put the roof this, and now everybody is in the house
for decoration and painting. Even if I say only, there is much
merit to Torvalds.
You may compare Stalman to Moore, and see a difference.
>--
>Cesar Rabak
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst
Bernd Paysan <bernd....@gmx.de> wrote:
>Duke Normandin wrote:
>> Why did Linus Torvald choose C to do his Linux kernel?
>
>According to one of Linus' books, he had some exposure to Forth in his
>Sinclair-QL days, but he didn't grok it. When you look at how many things
>Linus failed to understand (and often still fails to understand), I suggest
>the following explanation: Linus is good enough to do the job, and bad
>enough to allow lots of other people to contribute at about the same level.
>This network effect allows the effort to be large enough to succeed.
>Submissions significantly below Linus' level will be rejected, as well as
>suggestions above his level.
There is something good in this. It means that Linux remains coherent.
<SNIP>
>
>Programmers as a large body are very conservative - the en vogue languages
>follow a pretty strict and slow evolution pattern from the previous en
>vogue language (Perl as exception of the rule - but Perl is already phased
In my current job there is some awk, and I was surprised how much
was familiar, from my knowledge of Perl.
>out and replaced by Python and PHP, which are much more C-like). Often
>enough, new ideas which make perfectly sense are rejected by a large enough
>group to cause significant problems of adaption. E.g. the Gnome project
>even rejected C++ as language for their GUI apps, despite it makes so much
>sense to use an object oriented framework in this field. Now, they accept
There is much sense in rejecting C++ for building system applications.
It is way too complicated.
>at least C#, but that seems to be because one important Gnome contributor
>leads the effort to clone Microsoft's .NET - and one of Gnome's supporting
>companies has put quite some money into Mono.
I have tried out C# and it is a decent language. If I disapproved
of their choice, it would be my dislike of Microsoft.
>--
>Bernd Paysan
Albert van der Horst
Andreas Kochenburger <a...@nospam.org> wrote:
<SNIP>
>
>We use the drivers and libraries that come along with the boards. So
>there is no freedom to chose a language. I believe it is a similar in
>most other situations for embedded device programming.
That is why I'm trying to finish the Renesas ciforth compiler,
(after my tax forms :-( ) and get them on the disk that GLYN
supplies with their evaluation boards.
At least those folks are willing, and they provide GNU tools.
That means they are in the business of promoting their chips,
not their compilers. We'll see.
If anybody has ideas about what example programs to provide,
I would be grateful. The problem is of course that an embedded
system is nothing, if not embedded. So the least you have to
add is a row of leds, which makes for illustrative but not
impressive examples.
>Andreas
Bruce McFarling
> OTOH, Forth _is_ completely general purpose - one "code monkey" could
> bring down the system e.g. : variable constant ;
> Since Forth is so general purpose, you could develop a dialect that
> had the same sort of features as C - once you decide to do this you
> must ask some difficult questions:
> Do you really want RPN? Of course not! You don't want to have to
> retrain people away from what they were taught at 5 years old.
Of course you do. Most people didn't learn that stuff very
well anyway, at least not in the US. Don't teach them that
it is a reverse anything, though, teach them that they are
barking commands at the computer rather than "programming"
the computer. I can't tell you how many times I get people
computing 1/((1-c)+ct+m) as (1/(1-c)) + ct + m. Because I
have handed that test back. But I could look at the grades
on that problem and give you a good guess.
> Do you allow people to redefine "key words"? No!
You allow people to define macros, which they define by
going through the process themselves. The system writes the
definition.Of course, the definition that it writes is
: macro-name action_1 action_2 action_3 ... action_n ;
but they don't see that. However, that's why you retain
implicit operands, because it makes for easier and more
efficient definition of the macros.
They can also write conditionals, which are tests and the
macros to execute based on the result of the test.
And of course their own macros and tests are added to the
selection of things they can use to write macros and tests.
> How do you export encypted programs, and let the end user access your
> functions? Better add header files.
Don't. Compete where C is weak, not where it is strong. Leave
everything in plain text. The header file is simply a list of
macro names and compiled tests.
> How do you make the language so complicated that only "gurus"
> understand it in depth? Make it more abstract.
Now the code monkeys are simply the people who know how to clean
up the macros that people have defined for themselves, find
logic mistakes, test boundary conditions, etc.
So the gurus are those who know how to define a new word in
Forth, test its boundary conditions and be able to certify
that it can be added to the set of actions available to the
regular users.
> BTW you need "gurus" to provide a career path for the "code
> monkeys"...
And now you have it.
> If you make all of the required changes you will end up with something
> very like C.
And, no, by making only the required changes and not the
changes that codify folkviews "explaining" that what
happened to happen is what had to happen, you end up with
something dramatically different to C, which is far
better suited to the modern "flat-multitask" corporate
job allocation strategy.
> If you then do a simple financial calculation, is it worth making
> these changes?
Indubitably. You can hire people, and train them to program as
part of their job performance, and then roving troubleshoooters
are both fixing their mistakes and training them to program
better, at their level, and building the company toolkit of
macros that instantiate the company's routine skills. And the
gurus manage the expert system that advises people whether a
particular task has an already tested and debugged macro
available and sampling the distribution of macros to identify
those that can be hardwired into either the underlying open-
source applications that the company uses for its operations
or as trusted Forth code into the scripting shell that the
company wraps around those applications.
Then the advantage that is distributed across the macro system
and the skills distributed among the employees is much more
difficult for a competiter to replicate, even if they get
their hands on the code, so that it is a much more durable
static competitive advantage than provided by obscured
code. And by swinging the static competitive advantage from
closed to open code, you can marry that with the superior
dynamic competitive advantage of working in open code.
Bruce McFarling
Yes, full screen TUI.
Elizabeth D Rather
> On Mar 18, 7:00 am, "winston19842...@yahoo.com"
> <winston19842...@yahoo.com> wrote:
>
>> Was there a commercially available Forth that had a compiler that
>> compiled to native code?
>
> It depends on just what time you're talking about, but in general the
> answer is no. For that matter the first native-code compilers didn't
> do much if any optimising. After some discussion there was a consensus
> that you got the best speed by keeping the top stack item in a
> register but not the second stack item.
Until ANS Forth, which for the first time had no restrictions on
implementation, the predominant style was "indirect threaded code".
That isn't the same as "interpreted" in the sense of classical
interpreted languages (e.g. early Basic, LISP, etc.), but was
substantially faster. Commercial implementations were generally much
faster than FIG Forth (as much as 10x), since they optimized for
performance whereas FIG optimized for code portability and rarely took
full advantage of the host processor architecture.
I never really encountered resistance to Forth based on performance, as
we regularly delivered applications whose overall performance was at
least as fast or faster than C due to design opportunities our systems
encouraged. The main opposition typically took the form of "I never
heard of it", "that's only a hobbyist toy", or "my company only allows C".
> As late as 1994 Forth experts were saying that it wasn't worth it to
> have a Forth graphics standard because even after you supply a bunch
> of graphics primitives still the Forth code that calls the primitives
> would be too slow to be usable.
Totally not true. Well-implemented Forth systems are plenty fast.
FORTH, Inc. had an extensive graphics package in polyFORTH and its
predecessors, and was used for a lot of graphics and image processing
applications.
The reason the ANS Forth committee declined to address graphics was
because "common practice" varied wildly, and it was hard to get a
consensus. Of the several graphics packages in wide use at the time,
there was little commonality in names or even in overall architecture.
A compromise could have been developed, but it would have been costly
and time-consuming, and we felt it more important to get a standard on
the underlying language first.
>> All the FIG Forths I knew were interpreted. Turbo Pascal defeated UCSD
>> Pascal on the basis of speed. UCSD Pascal was closer to standard
>> Pascal, had more features, but lost just on the concept of speed. It
>> was portable, even.
>>...
>
> Yes, speed has been considered far more important than its effect on
> performance would justify. I never knew of a FIG Forth that was
> interpreted, though they had an "inner interpreter" which was a short
> stretch of machine code that executed Forth tokens. Far faster than
> interpreting text.
Correct. Saying that Forth is "interpreted" (meaning the inner or
address interpreter) has always led to a lot of misunderstanding.
...
>
> But that's mostly over now. An employer can call a temp agency on
> Wednesday and ask for 50 code monkeys and have 50 C programmers
> sitting at their terminals on Monday. There isn't so much status in
> computer languages now. Now to the extent there's status it's more in
> being a developer, in being the sort of manager who can actually get
> productive results from code monkeys. I hear things like "We're
> running mostly Java, with .NET. We're nimble and our results are
> robust. We have 20 programmers working on 35 projects with 28
> partners. We shift people to wherever they're needed and they're
> productive from the first hour, our team members are interchangeable.
> They have to be." If you want more respect than the guys who're
> getting outsourced, you need to perform special tricks.
Management frequently uses that excuse. We worked with one company for
a number of years, doing system-level programming while their in-house
Forth guy did most of the application. A change of management caused
the Forth guy to be fired. They asked us for a quote to port the whole
app to more modern hardware. We quoted $30K. They said it was too
much, they could get a $30/hr C programmer to re-write from scratch for
that amount. We wished them luck. Five *years* later they called us in
for some Y2K fixes -- they were still using our system on the old
hardware because $300,000 later the C version still didn't work.
I strongly suspect this myth of interchangeability is just that: a new
team member has to learn a lot more than language to be productive in a
complex existing application.
Anton Ertl
>Frank Buss wrote:
>> Is it possible to prove the correctness of a Forth program, e.g. like it is
>> possible for a subset of Pascal with the Hoare logic (
>> http://en.wikipedia.org/wiki/Hoare_logic ) ?
Sure, you can do it the same way.
>I guess that it is not possible to prove Forth programs as a general
>rule, eg. because of ?DUP.
One usually does not prove a pre-existing program anyway. Instead one
constructs the program together with a proof that the program conforms
to the specification. If a programming language feature (or, more
likely, a particular combination of programming language features)
would break the proof, you just don't use it. However, in general
?DUP is not such a feature; the programmer has a mental model of how
?DUP is supposed to work in the program, and this mental model can be
encoded in the proof annotations; of course, that might still be
painful enough that the programmer would avoid ?DUP anyway.
Going back to a more general level, the main problem with such
techniques is that they only prove the conformance to the formal
specification, but not that the formal specification is correct (and
who has a formal specification anyway?).
Another problem is that for many parts of the program, the program is
so trivial that the formal specification is essentially the same as
the program. The proof stuff helps Only with sophisticated
algorithms, and how often do we program them?
- 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 2007: http://www.complang.tuwien.ac.at/anton/euroforth2007/
John Doty
> Sorry to be coming in late to this interesting discussion!
>
> Duke Normandin wrote:
>> In the Epilogue, "Forth's Effect on Thinking" in Leo Brodie's book,
>> "Thinking Forth", Mark Bernstein is quoted as follow:
>>
>> ". . . The idea of of "human scale" is, I think, today's seminal concept
>> in software design. This isn't specifically a Forth development; the
>> great joy of UNIX, in its youth at least, was that you could read it
>> (since it was written in C), understand it (since it was small), and
>> modify it (since it was simple). Forth shares these virtues, although
>> it's designed to tackle a different sort of problem."
>>
>> What does Bernstein mean by "it's [Forth] designed to tackle a different
>> sort of problem [than C]." With the answer to this question, I hope to
>> zero-in on "what Forth is best suited for?".
>
> Forth was first designed to run real-time applications in
> resource-constrained environments (small memory, slow, etc.), although
> early-on there was also a mainframe (IBM 360) version for later data
> analysis. C was developed to program Unix, a general-purpose OS, in
> medium-to-large size computers. Very different set of objectives and
> constraints.
Not so different. The Bell Labs group had been working on Multics which
was written in PL/I and required a very large mainframe to run. C wasn't
quite as radically good at doing small systems as Forth, but it did
enable a minicomputer to run a system of mainframe capability.
>
> Another consideration is that C is a language that remains close to
> classical Algol-type language philosophies and style.
Indeed. Filtered through a decade of experimentation with that kind of
language. Most importantly, Ritchie threw out most of the bad ideas from
previous attempts to extend Algol.
> In creating
> Forth, Chuck Moore went back to first principles and re-thought the
> whole issue of relationship between human and computer.
He did, but his "first principles" seem to have been more mathematical
than psychological. On the other hand, the Bell Labs group was a spinoff
from MIT's Project MAC ("Man And Computer") which was the brainchild of
a psychologist. Indeed, it seems to me that they followed Licklider's
vision better than his colleagues at MIT did.
> As a result,
> Forth is very idiosyncratic in style (the reliance on an explicit stack
> being only the most obvious manifestation of this). That is a major
> source of its power and efficiency, but also has probably made adoption
> harder for many folks: it "looks funny" and they back off.
I tell my users to just step through, decode word by word. That's easier
in LSE64 than in standard Forth, though, since the flow control is
simpler and there's no STATE.
>
>> For some reason, I had assumed that Forth could be considered a
>> general-purpose language -- like C, eg. Maybe I was mistaken. I observe
>> that the IT industry adopted C as opposed to Forth. I'm curious as to
>> why this happened? Is there *something* inherently counter-productive
>> about Forth that would have it be shunned by so many? Why has the cream
>> not risen to the top?
>
> Several things going on here. As others in this thread have noted, C
> was distributed with Unix by Bell Labs, a well-known and respected
> company, to computer labs in Universities around the country.
A misrepresentation. The Bell Labs group was, naturally, a research
group. They *published*. That was what really got other researchers
interested. Also, MIT and its collaborators (including, in the early
days, Bell Labs) had for years made a big deal about Multics. But Unix
had essentially all the utility of Multics on hardware an order of
magnitude cheaper.
> It
> acquired a lot of credibility because of its origins and distribution
> channels.
Credibility comes from accomplishment.
>
> Forth was initially promoted by a small, underfunded start-up company
> (FORTH, Inc.) with a very limited promotion budget and no "name
> recognition".
How much corporate backing did Python have? How much "name recognition"?
What was its promotion budget?
Forth was better known around 1978 than C. And at least where I was, C
had little credibility: most scientific programming was in FORTRAN, and
systems folks thought PL/I(G) would beat out C eventually. There was a
lot of interest in Forth, especially the STOIC dialect.
If powerful institutions determined our programming languages, we'd all
be using PL/I and Ada.
> If Forth had not been as truly superior as it was, it
> would never have gone anywhere. Also, the "IT industry" is much more
> focussed on the kinds of applications and environments that Unix and C
> targeted than the smaller real-time systems that Forth targeted.
>
> Forth was initially developed in a scientific laboratory, and its early
> adopters were scientists.
Indeed.
> Forth continues to thrive there,
Ridiculous propaganda. It's very lonely being a physicist who still uses
Forth.
> and in the
> related fields of instrumentation and control systems. It has been used
> and taught in university engineering and science depts.,
Much less now than in the past.
> though rarely
> in Computer Science per se. It appeals to pragmatists who are
> interested primarily in getting something to work quickly and
> efficiently rather than something which is satisfying on a theoretical
> level (which would appeal more to the CS folks).
But does it really do that any more? The competing tools have gotten a
lot better, but Forth seems stuck in the 70's. Arrested development.
>
> The advent of PCs in the 80's came with a burst of Forth activity,
> spurred first by the Forth Interest Group and hobbyists and then a wave
> of implementors providing systems to hobbyist programmers. Although
> Forth became better-known in this time frame, it also acquired the
> reputation of being a "hobbyist toy", which remains a negative in the
> minds of some people who haven't seen Forth in any other context.
Lots of hobbyists use C, too. Hasn't hurt it. Linux and Python started
as "hobby" projects. BASIC is still strong.
What sells a computer language to someone like me is accomplishment. If
I go to a scientific meeting and see smart people doing lots of cool
stuff in Python the Python starts looking attractive. Where's the Forth?
I can't find it anymore.
>
>> Please no flames! I'm simply trying to get a sense of time and place
>> here -- some perspective. Maybe the reason is as simple as why VHS won
>> out over Beta. Or maybe it's more complex than that.
>
> I hope this helps.
>
>> BTW, who is the official Forth "flag-bearer" these days? FIG? IAFR?? Are
>> either still alive? I see their websites are still warm. Nobody ever
>> speaks of them though. What's up? TIA....
>
> There really never has been "an official Forth flag bearer". There is a
> FIG group still active in the Silicon Valley area and another in
> England. There's an annual conference in Europe (EuroForth). The
> principal commercial vendors are FORTH, Inc. in the US and MPE in
> England, plus active communities around free systems such as gForth and
> Win32Forth.
>
> Cheers,
> Elizabeth
>
--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
Stephen J. Bevan
> Until ANS Forth, which for the first time had no restrictions on
> implementation, the predominant style was "indirect threaded
> code". That isn't the same as "interpreted" in the sense of classical
> interpreted languages (e.g. early Basic, LISP, etc.),
> ... Saying that Forth is "interpreted" (meaning the inner or
> address interpreter) has always led to a lot of misunderstanding.
Indeed, just as much as saying that LISP is "interpreted". The very
first version of Lisp -- Lisp 1.0 in 1960 -- came with a compiler that
compiled to machine code (the Lisp 1.0 Manual shows how to use the
compiler and what the generated code looked like). It was a
user-choice whether to compile definitions or let them be
interpreted. The distinction was a implementation driven decision in
1960 which became less relevant over time. However the myth that LISP
is "interpreted" persists since people keep repeating it.
Howerd
> > If you then do a simple financial calculation, is it worth making
> > these changes?
>
> Indubitably. You can hire people, and train them to program as
> part of their job performance, and then roving troubleshoooters
> are both fixing their mistakes and training them to program
> better, at their level, and building the company toolkit of
> macros that instantiate the company's routine skills.
Maybe I'm getting cynical with increasing age...
I can really relate to what you are saying, it sounds like companies
should want to develop nuggets of polished macros that can be reused.
Maybe there is a company out there like that, and maybe I should go
and work for them, as an outageously salaried "guru" !
Alas, this is not my experience of companies here in the UK.
Open Source is another business model - I like it better than closed
source - but it relies on the principle that programming is
complicated.
For example, for one of my back-burner projects I need audio
compression/decompression, so I looked at Ogg Vorbis. I still haven't
found the bit in the open source code that actually does anything.
Essentially its encrypted by complication - the wrappers are not human
readable ( at least by this human, in any time scale that makes it
worth while ).
> And, no, by making only the required changes and not the
> changes that codify folkviews "explaining" that what
> happened to happen is what had to happen, you end up with
> something dramatically different to C, which is far
> better suited to the modern "flat-multitask" corporate
> job allocation strategy.
I agree totally with you that this is what _should_ happen, but I have
yet to be convinced that it will...
Regards
Howerd 8^)
Bruce McFarling
> Maybe I'm getting cynical with increasing age...
> I can really relate to what you are saying, it sounds like companies
> should want to develop nuggets of polished macros that can be reused.
I was addressing the financial incentive ... I'm not about
to use the existence of a financial incentive to predict
that firms will necessarily exploit it.
I'm not one of the "economy on Mars" types of economists
who assumes that firms will somehow magically gravitate
toward an optimal outcome just because the potential is
out there somewhere.
I prefer historical evidence regarding patterns of
behavior, and the historical evidence is that firms can
proceed for quite a long while telling themselves that
their current routine is the best possible way of doing
things, until some fringe player stumbles onto a
competitive advantrage something that forces them out
of their routine, or some previous complementary
resource becomes a limiting resource and a new strategic
contest emerges.
And I should stress, more critical than whether something
conveys an advantage is how easily that advantage can be
copied by the competition. Its not the golden nuggets that
would make that system effective, its the fact that the
skills and the benefit of the macros are distributed across
the company, which makes the advantage difficult to copy.
Its the difficulty in copying the advantage that converts
it into a *competitive* advantage.
Bernd Paysan
> There is something good in this. It means that Linux remains coherent.
To some extent, yes. The problems they don't see however remain. The AIO
stuff I mentioned is a mess since the beginning, and it will stay a mess,
unless someone comes along and keeps doing the right thing despite Linus
hates it.
> In my current job there is some awk, and I was surprised how much
> was familiar, from my knowledge of Perl.
Some people said that Perl was replacing sed+awk+bash.
> There is much sense in rejecting C++ for building system applications.
> It is way too complicated.
Yes, but that's not correct for GUI applications, the target of Gnome.
There, *not* using an object oriented framework is way too complicated.
>>at least C#, but that seems to be because one important Gnome contributor
>>leads the effort to clone Microsoft's .NET - and one of Gnome's supporting
>>companies has put quite some money into Mono.
>
> I have tried out C# and it is a decent language. If I disapproved
> of their choice, it would be my dislike of Microsoft.
Another reason would be that Mono is really not a good implementation, it's
slow and memory-hungry. I don't know how good Microsoft's original .NET is,
but the quality of Mono makes C# not a good choice. The most hated Mono
application is Novell's zmd, packaged with SuSE from 10.1 (fortunately, in
10.2, you can completely remove it, and the OpenSuSE community strongly
recommends to do that).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bernd Paysan
> I agree! Tannebaum would have stronger words than that! I guess Linus
> was one of his students for .5 of a semester or maybe longer.
No - Linus studied in Helsinki, and Tanenbaum lectures on the Vrije
Universiteit Amsterdam. Linus used Minix before he started doing some
experiments in protected mode, which led to Linux. The main source of
inspiration was SunOS and the POSIX standard - and certainly the GNU
project.
> There has
> always been a question as too how much of Tannebaum's code was used in
> the initial Linux kernel. Tannebaum has a webpage(s) on this matter
> somewhere. But I'm sure that Linus had *no* inclination to start the
> kernel from scratch -- be it in Forth or otherwise.
Linux is pretty much a kernel "from scratch", but there's (and was) the
whole GNU project around it. Since Linus rejected most of Tanenbaum's
wisdom, there can't be much of Minix inside Linux.
> I hear you! Mass momentuum is a powerful force - including its opposite,
> lethargy. Bernd, if *you* (et al) can do Minos, the Forth community
> should be able to get in the game and do "Forthix" [TM] ;)) Wouldn't
> that be cool? Do you think it's do-able?
For sure it's doable. Question: Is it worth doing? Writing something like
Minos, which runs on popular operating systems is one thing - writing an
operating system and make it somewhat popular is something entirely
different. And don't forget: It would be a Forthix, i.e. something
completely different from a typical Unix kernel. All the POSIX stuff would
be in a library, using kernel interfaces which are quite different from the
way Linux or other Unixes work. Yet, GNU/Linux compatibility would be key
to popularity - if you can make it a complete GNU system with some
advantages over Linux (e.g. performance and reliable real-time features for
media playing), people might use it.
Bernd Paysan
> Bernd Paysan <bernd....@gmx.de> writes:
>> Example: A few weeks ago, during discussion about asynchronous IO in
>> Linux (which is still not really useful), someone brought up active
>> messages (though he called it differently, because he didn't know what it
>> was - some xxxlets or so).
> [snip]
>> Linus didn't like them; discussion more or less closed (maybe
>> they'll reappear in a year or two - Linus often accepts ideas he
>> rejected some years ago).
>
> It wasn't as if he wrote "I don't like syslets, end of discussion".
He said
"Ok, having now looked at it more, I can say:
- I hate it.
I dislike it intensely [...]"
> He explained his thoughts, see http://lwn.net/Articles/222168/, and
> why he sees more utility in the fibril approach. He's interested in
> practical problems like aoi_read(), not what syslets *could* be used
> for.
He doesn't understand a word about what active messages are (well - they are
in disguise here, and called "syslets"). And since he doesn't understand
(or even know) the concept behind it, he doesn't understand how this can be
useful for the user, and that it is *not* a horrid programming interface. I
agree that writing an active message system in Forth is much easier to
program, because you can extend Forth to generate the code for the messages
just the same way as you generate the code for the application itself -
this is far more difficult in C.
And that's why he says that chaining system calls together is "much more
powerful in user space". It's so, because the way you can chain system
calls together in kernel space is severely limited when you do a naive
syslet approach (and probably don't understand anything how to do it more
powerful).
> If someone is convinced that syslets are the way, then they can
> argue the case by showing the actual syslet programs that are superior
> (by some metric) to alternative approaches.
Yes, the code stuff. But I said that's always possible - the idea was
rejected, working code and benchmarks might convince Linus.
> Consequently, I don't think you picked a good example to make your point.
It's a good example. Well, if you are on the same level of understanding as
Linus, every example is a bad example ;-).
Stephen J. Bevan
> He said
>
> "Ok, having now looked at it more, I can say:
>
> - I hate it.
>
> I dislike it intensely [...]"
The "..." hides a lot of detail which anyone is/was free to rebut. If
nobody offers a rebuttal and the discussion ends and that's hardly
Linus' fault. If syslets (or active messages) are such a great idea
then surely someone would step up and make the case for them backed up
by working code?
> And that's why he says that chaining system calls together is "much more
> powerful in user space". It's so, because the way you can chain system
> calls together in kernel space is severely limited when you do a naive
> syslet approach (and probably don't understand anything how to do it more
> powerful).
It is is very easy to say he doesn't understand, quite another thing
to point at patches implementing active messages (i.e. non-naive
syslets) and then pointing at a message where Linus rejects them.
>> If someone is convinced that syslets are the way, then they can
>> argue the case by showing the actual syslet programs that are superior
>> (by some metric) to alternative approaches.
>
> Yes, the code stuff. But I said that's always possible - the idea was
> rejected, working code and benchmarks might convince Linus.
There are plenty of ideas that seem good on paper but fall apart once
you try and implement them or when you do implement them they turn out
not to be as good as was originally thought. Linus has seen more than
his fair share of them over years. That's why ideas without code
generally fall on deaf ears. Once there is code it can be reviewed,
benchmarked ... etc.
>> Consequently, I don't think you picked a good example to make your point.
>
> It's a good example. Well, if you are on the same level of understanding as
> Linus, every example is a bad example ;-).
It would be a good example if Linus rejected "active messages". But
he didn't. He rejected syslets as implemented. That you think he's
missing the big picture about active message is your opinion, not fact.
John Passaniti
> Open Source is another business model - I like it better than closed
> source - but it relies on the principle that programming is
> complicated.
> For example, for one of my back-burner projects I need audio
> compression/decompression, so I looked at Ogg Vorbis. I still haven't
> found the bit in the open source code that actually does anything.
> Essentially its encrypted by complication - the wrappers are not human
> readable ( at least by this human, in any time scale that makes it
> worth while ).
This makes no sense to me. You take a specific example of something
that is inherently complex (psychoacoustic compression of audio requires
a fair amount of sophistication that spans not just programming but
physics and biology) and use it as a very wide brush to paint all open
source as being based on a "principle that programming is complicated."
Open source gives you the code. Open source does not open up your brain
and pour in the specific knowledge you need to understand the code.
That is not based on a principle that programming is complicated. The
*programming* is visible. You can learn from it. The *ideas* behind
the programming may be complicated, but that's hardly a fault of open
source.
Howerd
On 19 Mar, 07:50, John Passaniti <n...@JapanIsShinto.com> wrote:
> Howerd wrote:
> > Open Source is another business model - I like it better than closed
> > source - but it relies on the principle that programming is
> > complicated.
> > For example, for one of my back-burner projects I need audio
> > compression/decompression, so I looked at Ogg Vorbis. I still haven't
> > found the bit in the open source code that actually does anything.
> > Essentially its encrypted by complication - the wrappers are not human
> > readable ( at least by this human, in any time scale that makes it
> > worth while ).
>
> This makes no sense to me. You take a specific example of something
> that is inherently complex (psychoacoustic compression of audio requires
> a fair amount of sophistication that spans not just programming but
> physics and biology) and use it as a very wide brush to paint all open
> source as being based on a "principle that programming is complicated."
Yes, psychoacoustic compression is complex, and I don't really want to
understand it any more than I have to.
What I would expect is that any source code that implements any
complex algorithm should provide a comprehensible _human_ _readable_
interface.
In this case, I would like to see a function that compresses a buffer
and one that decompresses it.
My point is that the effort required by me to find those functions in
"open source" code is of the same magnitude as the effort to
understand how it works and code it myself.
I speak, of course, as a Forth programmer who naturally would rather
re-invent the wheel ;)
> Open source gives you the code. Open source does not open up your brain
> and pour in the specific knowledge you need to understand the code.
Well it should. When whoever wrote the code, presumably they
understood what it was doing.
To be truly "open", surely they should explain what each function
does, to help people understand their work.
> That is not based on a principle that programming is complicated. The
> *programming* is visible. You can learn from it. The *ideas* behind
> the programming may be complicated, but that's hardly a fault of open
> source.
Yes it is. Programmers tend to want to hide their expertise. Maybe I'm
expecting too much, but to me the examples of open source code that I
have looked at are rarely worth the effort. There is still a culture
of obfuscation.
My apologies to anyone who has worked on open source code, and who
takes pride in making it easy to read and useful...
OK John, here's another challenge for you, to be rewarded by the
dessert of your choice, to go with the beverage that I already owe you
( for your work on the Perl version of the magenta variable ) :
Please could you search the Ogg Vorbis code and send me ( a pointer
to ) the file that contains the compression and decompression
functions, and tell me what they are called. I spent an evening trying
to do this and failed. Make a note of how long it takes you, and how
you did it - it could be useful for future projects...
Good luck!
Howerd 8^)
Duke Normandin
> Duke Normandin wrote:
>> I agree! Tannebaum would have stronger words than that! I guess Linus
>> was one of his students for .5 of a semester or maybe longer.
>
> No - Linus studied in Helsinki, and Tanenbaum lectures on the Vrije
> Universiteit Amsterdam. Linus used Minix before he started doing some
> experiments in protected mode, which led to Linux. The main source of
> inspiration was SunOS and the POSIX standard - and certainly the GNU
> project.
>
>> There has
>> always been a question as too how much of Tannebaum's code was used in
>> the initial Linux kernel. Tannebaum has a webpage(s) on this matter
>> somewhere. But I'm sure that Linus had *no* inclination to start the
>> kernel from scratch -- be it in Forth or otherwise.
>
> Linux is pretty much a kernel "from scratch", but there's (and was) the
> whole GNU project around it. Since Linus rejected most of Tanenbaum's
> wisdom, there can't be much of Minix inside Linux.
I went here:
http://www.cs.vu.nl/~ast/brown/
and got the facts! I should have done that *first* before commenting! My
bad!
>
>> I hear you! Mass momentuum is a powerful force - including its opposite,
>> lethargy. Bernd, if *you* (et al) can do Minos, the Forth community
>> should be able to get in the game and do "Forthix" [TM] ;)) Wouldn't
>> that be cool? Do you think it's do-able?
>
> For sure it's doable. Question: Is it worth doing? Writing something like
> Minos, which runs on popular operating systems is one thing - writing an
> operating system and make it somewhat popular is something entirely
> different. And don't forget: It would be a Forthix, i.e. something
> completely different from a typical Unix kernel. All the POSIX stuff would
> be in a library, using kernel interfaces which are quite different from the
> way Linux or other Unixes work. Yet, GNU/Linux compatibility would be key
> to popularity - if you can make it a complete GNU system with some
> advantages over Linux (e.g. performance and reliable real-time features for
> media playing), people might use it.
If it can be crafted to "look and feel" like Unix, than it will not be a
hard sell. If it can be crafted to eliminate some Unix deficiencies --
so much the better. If it can be crafted as a microkernel (maybe a Forth
OS already is that?) , maybe you will follow B. Gates as the new global
IT tycoon :)) The real problem to my mind is: How many red-hot Forth
hackers can you assemble to form a core development team? I'm a long
time user of FreeBSD et al, so I guess I'm familiar with the BSD models
and look to them for inspiration and guidance.
--
duke | A: Yes. |
| >Q: Are you sure? |
| >>A: Because it reverses the logical flow of conversation. |
| >>>Q: Why is top posting frowned upon? |
Tarkin
For an example of what Howerd is talking about,
get the following code, and try it out on any Linux
(I think it might even work on Cygwin) distro.
It's 'Hello, World!', which is supposed to be an
'easy' demonstration...digging through all the
automake files, configs, and even the source, is
an exercise in 'puzzle solving', to misquote
Mr. Moore.
I know *exactly* what Howerd means...digging
through most open-source projects becomes an
adventure in code archeology or navigation,
rather than trying to parse the flow of
algorithms.
As was pointed out earlier (in this thread or
another), GNU or other open-source projects
seem to be encrypted by header files, obtuse
layouts, automake scripts, etc.
just my $0.02,
Tarkin
http://directory.fsf.org/GNU/hello.html
ken...@cix.compulink.co.uk
winston...@yahoo.com () wrote:
> Not sure there was really a difference, except that Turbo was run from
> a DOS prompt and UCSD was a different filesystem (at least early PC
> versions were).
UCSD was a byte code system like Java but without a JITC. Turbo was
native code. I have not used either so cannot comment on the development
environment but Turbo had one big advantage it was cheap. Also the non
standard bits made accessing DOS call much easier at a cost in
portability. The IDE came in with Delphi making it much easier to
produce Windows programs than with anything Microsoft were shipping at
the time. Using some of the demo stuff I produced a working database
program without actually having to write code.
Ken Young
Andrew Haley
>
> For an example of what Howerd is talking about, get the following
> code, and try it out on any Linux (I think it might even work on
> Cygwin) distro.
> It's 'Hello, World!', which is supposed to be an 'easy'
> demonstration..
It's a joke, son.
Andrew.
Clever Monkey
> On 2007-03-17, Bruce McFarling <agi...@netscape.net> wrote:
>> On Mar 16, 3:51 pm, Duke Normandin <merr...@telus.net> wrote:
>>> Why did Linus Torvald choose C to do his Linux kernel?
>> a rewrite of the Minix kernel, intended to be a Unix-like
>> system for a PC as a teaching tool.
>>
>> You aren't teaching people how Unix systems work if you don't
>> teach them in C. And Unix was the university research system
>> it was in part because Bell Labs was under monopoly regulation
>> and could not commercialize Unix, and in any event giving
>> the early Unix systems away for free for non-commercial
>> educational uses was more valuable as window dressings a large
>> regulated private monopoly than the commercial value that it
>> would have represented.
>>
>> Its like asking with Burgundy is a province in France, rather
>> than Isle-de-France being a province of Burgundia. History is
>> like that.
>>
>
> *Minix* was/is a teaching tool written by Tannenbaum (sp?) but designed
> around a micro-kernel instead of the usual monolithic kernels of various
> flavors of Unix. As well, Tannebaum was not teaching C, rather OS
> theory and design, etc.
>
> Torvald *was not* writing a teaching tool. As such, he could have chosen
> any language to write his Unix-like OS. He chose C, because Minix was
> written in C. My point is, if Forth is so overwhelmingly better at
> bit-banging, why has it, by and large, been ignored? I would have
> thought eg that a small Unix-like micro-kerneled OS would have been easy
> to do for a core of Forth developers. All the "plug-ins" to the
> microkernel could have been done in Forth as well. Would that not have
> show-cased Forth well? That's just one example. Bit-banging GUI screen
> would seem to me to be right up Forth's alley. No?? I'm just curious
> here. I'm still reading Leo Brodie's book -- and it *still* makes a
> whole lot of sense -- in theory. I'm wondering why the IT industry as a
> whole hasn't caught on. I'm missing a piece of this puzzle!!
Because Bell Labs used C, and Unix and C was already very well known
among students (including Torvalds) by that point. Any sort of portable
assembler would have done the job Torvalds needed, and people will often
reach for what they know best while still making their own decisions
(e.g., deciding to make what is now known as Linux a monolithic kernel.)
If you are looking for a toolset that allows you to generate a large
amount of object code, from display drivers and serial ports right on up
to user interfaces, and you are already familiar with C then that is
naturally what you might reach for.
Early Forth has a pedigree where it /is/ the OS (in the sense of
providing running programs with resources), since the early
practitioners and designers were working in a world where OS design and
practice (as we know it now) was still in its infancy. Those early
practitioners had different backgrounds and problem spaces that other
people, and naturally grew different toolsets to solve those problems.
These people would see the obvious value in bit-banging UIs using Forth,
but it's not like there is a true distinct advantage over C in a similar
problem space. People reached for the most appropriate tool they were
familiar with.
It is actually the wrong question to ask, "why is Forth not more
popular", and not just because popularity is a slippery metric.
Tarkin
wrote:
It's not funny. It has i18n features and
everything.
And joke or no, it's still a valid example
of *exactly* what Howerd is talking about.
If one were going to do "Hello,World!"
the GNU way, that's what you would get.
I see the 'joke' now, but it's not funny
to me because it's an all-too-accurate
of the GNU developmental model.
TTFN,
Tarkin
Andrew Haley
> On Mar 19, 4:50 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Tarkin <Tarkin...@gmail.com> wrote:
>>
>> > For an example of what Howerd is talking about, get the following
>> > code, and try it out on any Linux (I think it might even work on
>> > Cygwin) distro.
>> > It's 'Hello, World!', which is supposed to be an 'easy'
>> > demonstration..
>>
>> It's a joke, son.
> It's not funny.
Tough. It's still a joke.
Andrew.
Richard Owlett
Sure looks like all the "simple" stuff people tried to attract me to C
in the 70's. Turned me off permanently.
As a counter example of ease of reading and writing Forth a little
personal history. I had read the _BYTE_ issue featuring FORTH and some
_Dr. Dobbs_ articles. My employer had a CAD system built around a Huston
Instruments plotter and a PDP-11 (system was once a Bauch and Lomb product).
I recognized its internal language as "forth-like". A half dozen colon
definitions and I had a system that would take surveyor's field notes
and directly plot them without the intermediate processing that had been
required. Got myself an undeserved label as computer guru.
Clever Monkey
> On Mar 19, 4:50 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Tarkin <Tarkin...@gmail.com> wrote:
>>
>>> For an example of what Howerd is talking about, get the following
>>> code, and try it out on any Linux (I think it might even work on
>>> Cygwin) distro.
>>> It's 'Hello, World!', which is supposed to be an 'easy'
>>> demonstration..
>> It's a joke, son.
>>
>> Andrew.
>
> It's not funny. It has i18n features and
> everything.
>
anyone would normally in order to lampoon" technique. You just don't
get it. This is not your fault, but it does not change the fact that it
is funny.
> And joke or no, it's still a valid example
> of *exactly* what Howerd is talking about.
>
> If one were going to do "Hello,World!"
> the GNU way, that's what you would get.
> I see the 'joke' now, but it's not funny
> to me because it's an all-too-accurate
> of the GNU developmental model.
>
Uh, any system can be obfuscated to a ridiculous point -- even if just
to make a pointed comment. This does not mean that that you are
encouraged to do so.
The complex build and deploy system that the GNU framework defines is
there to make large, interdependent modules build on a great many
platforms. This has the benefits of simplifying the constant
development and testing of those modules on those platforms. If it
serves to obfuscate /simple/ projects, that is not the fault of GNU.
For example, if you absolutely /needed/ to make a multi-platform,
endian-agnostic, locale-specific "Hello World" that ran on nearly any
system under the sun, and could be compiled with nearly any reasonable
toolchain, and you wanted to share that project out to a large,
disparate base of developers, testers and users, you could do a lot
worse than build it within the GNU framework.
Make the tool fit the job. Not the other way around.
Yes, coding to foreign APIs can be hard, but this is why we are paid to
be coders. Usually, all it takes is a few hours of concerted effort to
get enough traction on most APIs. This is a skill that can always be
improved upon, but it is a valuable skill nonetheless.
None of this has /anything/ to do with open source. I've had to code to
all sorts of closed APIs, relying only on documentation and test
programs to figure things out. Hell, I /still/ use test programs to
assist in my understanding of the JVM, and that comes with full source!
You still have to make the effort, and it is only the details of that
effort that really change.
Brad Eckert
> The real problem to my mind is: How many red-hot Forth
> hackers can you assemble to form a core development team? I'm a long
> time user of FreeBSD et al, so I guess I'm familiar with the BSD models
> and look to them for inspiration and guidance.
>
I agree. How do you get Forthers to work together? I think Elizabeth
has given some good examples of establishing coding and interface
standards. That would be a start. Put together a nice web page with
coding standards, proposed words, the DPANS94 reference, links to the
200x effort, the ten rules of Forth, etc. A kind of one-stop place to
go before/while writing new code.
C et al have a lot of built-in "Don't do this" rules based on the
expertise of the language designers. In Forth, so-called good
programming practices aren't forced upon you. You have to adopt them
yourself. Coding standards help here.
Your enthusiasm is refreshing so don't let us discourage you from
trying to herd cats. If the herd has a feeding ground of library code
written to a common standard (whether ANS or almost-ANS) they may be
inclined to hunt there.
Brad
Brad
Bruce McFarling
wrote:
> Tarkin <Tarkin...@gmail.com> wrote:
Its a joke, but its not *just* a joke ... its the
official demonstration of GNU coding standard
(including GNU documentation, so its likely to be
the few Hello World programs every written with 44K
of html documentation as one web page ...
http://www.gnu.org/software/hello/manual/hello.html
... and one web page per node, and both compressed,
and as an info file, and as ASCII text, and ASCII
text compressed, and as a TeX dvi, and as a poscript
file, and as a pdf, *AND* (deep breath) as a
Texinfo source.
Howerd
I have to say I agree with all three of you :
Tarkin : thanks for the support - yes the "hello world" example does
show _exactly_ what I mean.
Andrew : yes the "hello world" example is funny - a 399k tarball is
excessive, and could only be a joke.
C. Monkey : yes, this GNU multiplatform, endian agnostic, locale-
specific program is more about those features, all of which have
nothing to do with open source.
But : just say I want to know how to write a "hello world" program in
C. I find an open source version of it and here's what I have to do :
1. Read the front page and decide which hyperlink I need. I select
"Source tarball" because I have worked in the industry and I know what
a tarball is.
2. I have to de-tar the tarball using WinZip.
3. I look at the 187 files, ignoring anything that has "make" in its
name, and play a hunch that "hello.c" might contain the code I want.
4. I open the file, and play a hunch that the essence of the "hello,
world" program will contain the string "hello" . The third instance is
the one I want, on line 322.
5. I notice that there is also a "hello" string on line 342 - the two
forms are selected at runtime by a variable "t". I scroll back up a
few pages to find that "t" is an int , and is set true by a function
that parses the input stream. I guess that "t" is set true if it there
is a n ASCII 't' on the command line.
6. I realise that I am going to have to RTFM to find out what the
command line arguments do, so I re-scan the 187 files for somthing
that might be a text file - readme catches my eye.
7. I open the readme file to find the following quote :
"The basic algorithm is described in: "The C Programming Language", by
B. W. Kernighan and D. M. Ritchie, Prentice-Hall, New Jersey, 1978;
the program is an enhancement of the one published in that book."
8. I decide to search the darker recesses of my library for the above
book... later...
Jokes aside, I really do want to find an audio compression/
decompression algorithm - the Ogg Vorbis code leads me down a similar
path, the main difference being that I don't have the background to
help give me "hunches". And of course there are many tens, if not
hundreds of C files, any of which could contain the magic code that I
am looking for.
I realised as I wrote this that I am criticising open source software,
and that this isn't allowed.
Clearly, if I am not part of the solution ( to mega-corporations
controlling software development ), I must be part of the problem.
So, again, I apologise to anyone who feels offended by my criticism -
there is no doubt some clear, simple open source code out there...
Apart from the stuff that I have published, of course, but that's in
Forth so it doesn't count. ( <-- joke ;)
Regards
Hwoerd 8^)
On 19 Mar, 19:30, Clever Monkey <clvrmnky.inva...@hotmail.com.invalid>
wrote:
Ed
"Elizabeth D Rather" <erath...@forth.com> wrote in message news:12vork7...@news.supernews.com...
> ...
> Forth was initially promoted by a small, underfunded start-up company
> (FORTH, Inc.) with a very limited promotion budget and no "name
> would never have gone anywhere. ...
Recently the question arose as to what causes a system or ideology
to become 'popular' - is it the concept itself, or is it the actions of
the fervent followers who promote it?
The advent of the microprocessor generated a massive hobbyist
base who were hungry to try out anything. That fertile ground
allowed FIG to be created which then spread the Forth message
far and wide, as did Brodie's now classic 'Starting Forth'.
I still recall reading -
" FORTH is a very unusual language. It violates many cardinal rules
of programming. My first reaction to FORTH was extremely
skeptical, but as I tried to develop complicated applications I began
to see its beauty and power. ... I'll warn you now: few programmers
who learn FORTH ever go back to other languages. "
(Leo Brodie from "Starting FORTH")
Who wouldn't be sucked in by that? If that book had been about C
then I'd probably be a C programmer now :(
The Beez'
> For some reason, I had assumed that Forth could be considered a
> general-purpose language -- like C, eg. Maybe I was mistaken. I observe
> that the IT industry adopted C as opposed to Forth. I'm curious as to
> why this happened? Is there *something* inherently counter-productive
> about Forth that would have it be shunned by so many? Why has the cream
> not risen to the top?
Forth excells IMHO in (what I call) decisionless programming, that is
where not too many IF's and WHILE's are required. Even for the most
elaborate tasks I find myself writing a lot of small, almost
insignificant definitions and after a while, the structure emerges.
Where I can, I use decision tables. This leads to small and easy to
maintain programs.
However, when having a lot of variables on the stack and there are a
lot of decisions to take, Forth becomes murky. E.g. when converting
spaces to tabs or replacing strings. Then the horrors of Forth emerge,
lots of stack acrobatics and (too) many decisions to take.
Since most business processes nowadays are cluttered with exceptions,
Forth shows its ugliest face when trying to tackle those problems. C,
which is designed to hold everything in randomly accessible variables
is much better suited for that. Still, when everything is cleanly
designed, there is nothing that can beat Forth.
Hans Bezemer
Duke Normandin
Interesting! Do you suppose this is one of the reasons this happened:
"Valdocs shipped to beta testers circa late 1982. Beta and initial
production releases of Valdocs' application modules were written in the
Forth programming language while its system-oriented modules (such as
E-Mail and disk utilities) were written in Z-80 Assembly Language. Later
releases of Valdocs' applications were written in the C programming
language." From: http://en.wikipedia.org/wiki/Valdocs
A good idea, but just plain old poor design?
Clever Monkey
> Hi Tarkin, Andrew and C. Monkey,
>
> I have to say I agree with all three of you :
>
> Tarkin : thanks for the support - yes the "hello world" example does
> show _exactly_ what I mean.
>
> Andrew : yes the "hello world" example is funny - a 399k tarball is
> excessive, and could only be a joke.
>
> C. Monkey : yes, this GNU multiplatform, endian agnostic, locale-
> specific program is more about those features, all of which have
> nothing to do with open source.
>
> But : just say I want to know how to write a "hello world" program in
> C. I find an open source version of it and here's what I have to do :
1.) Search for "Hello World" in Google
2.) End up at <http://www.roesler-ac.de/wolfram/hello.htm> after two clicks.
jwsa...@gmail.com
> In the Epilogue, "Forth's Effect on Thinking" in Leo Brodie's book,
> "Thinking Forth", Mark Bernstein is quoted as follow:
>
> ". . . The idea of of "human scale" is, I think, today's seminal concept
> in software design. This isn't specifically a Forth development; the
> great joy of UNIX, in its youth at least, was that you could read it
> (since it was written in C), understand it (since it was small), and
> modify it (since it was simple). Forth shares these virtues, although
> it's designed to tackle a different sort of problem."
>
> What does Bernstein mean by "it's [Forth] designed to tackle a different
> sort of problem [than C]." With the answer to this question, I hope to
> zero-in on "what Forth is best suited for?".
>
> For some reason, I had assumed that Forth could be considered a
> general-purpose language -- like C, eg. Maybe I was mistaken. I observe
> that the IT industry adopted C as opposed to Forth. I'm curious as to
> why this happened? Is there *something* inherently counter-productive
> about Forth that would have it be shunned by so many? Why has the cream
> not risen to the top?
>
> here -- some perspective. Maybe the reason is as simple as why VHS won
> out over Beta. Or maybe it's more complex than that.
>
> BTW, who is the official Forth "flag-bearer" these days? FIG? IAFR?? Are
> either still alive? I see their websites are still warm. Nobody ever
> speaks of them though. What's up? TIA....
> --
> duke | A: Yes. |
> | >Q: Are you sure? |
> | >>A: Because it reverses the logical flow of conversation. |
> | >>>Q: Why is top posting frowned upon? |
IMHO:
Some of the answer is marketing - C, Python, and others have gotten
mindshare regardless of whether they are always the "best" solution
for a particular problem. Some of the answer lies in the history of
the language and the community that supported it: the issues include
fierce antagonism by some members of the Forth community to
standardization efforts that might have made it easier for Forth to
become mainstream, and a tendency on the part of the community to
oversell the language relative to other options. For all its benefits,
Forth's design center is about simplicity and conserving compute
resources - especially memory. From a big systems perspective, Forth
is awkward at string handling and floating point, uses a pretty
primitive memory model, and never formally supported object
orientation, among other issues. From a small sytem perspective it is
probably the first language to get ported to any new CPU, and has an
exceptionally fast development cycle. I am a huge fan of Forth and
have built dialects into several products (as well as contributing
Ficl to the open source community), but believe as many others have
said that a language is a tool, and you need to pick the right one for
the problem at hand.
Bruce McFarling
> However, when having a lot of variables on the stack and there are a
> lot of decisions to take, Forth becomes murky. E.g. when converting
> spaces to tabs or replacing strings. Then the horrors of Forth emerge,
> lots of stack acrobatics and (too) many decisions to take.
Why would you design your string handling words so that
they require a lot of variables on the stack and lots
of decisions to make?
I certainly don't understand from your example, because
designing string handling words that make it easy to
convert from fixed width to space delimited to tab
delimited and back is straightforward. One approach
starts with charscan.txt, another approach starts
with a string stack, neither requires large numbers
of variables on stack or too many decisions to make
at any one point in time. Those are encapsulated
in lower level words so they dissappear from view
when working in the higher level words built from
primitives where we spend most of our time.
Duke Normandin
Thanks for your candor!
Elizabeth D Rather
> On 2007-03-20, The Beez' <han...@bigfoot.com> wrote:
>> On 16 mrt, 19:53, Duke Normandin <merr...@telus.net> wrote:
>> However, when having a lot of variables on the stack and there are a
>> lot of decisions to take, Forth becomes murky. E.g. when converting
>> spaces to tabs or replacing strings. Then the horrors of Forth emerge,
>> lots of stack acrobatics and (too) many decisions to take.
As others have said, if you have "a lot of variables on the stack" such
that things "become murky" you need to re-think your logic and factor
things such that it becomes simpler and more transparent.
>> Since most business processes nowadays are cluttered with exceptions,
>> Forth shows its ugliest face when trying to tackle those problems. C,
>> which is designed to hold everything in randomly accessible variables
>> is much better suited for that. Still, when everything is cleanly
>> designed, there is nothing that can beat Forth.
Having done a lot of business programming in the early days, I did not
find this to be the case. Forth was a fine tool (we wrote several
accounting systems, inventory control, data base management, etc.). We
just didn't find that application domain as interesting as scientific &
industrial apps, so decided to concentrate on those.
>
> Interesting! Do you suppose this is one of the reasons this happened:
>
> "Valdocs shipped to beta testers circa late 1982. Beta and initial
> production releases of Valdocs' application modules were written in the
> Forth programming language while its system-oriented modules (such as
> E-Mail and disk utilities) were written in Z-80 Assembly Language. Later
> releases of Valdocs' applications were written in the C programming
> language." From: http://en.wikipedia.org/wiki/Valdocs
>
> A good idea, but just plain old poor design?
What I heard from some of the Valdocs team members is that the major
problems were inadequate (non-existant) specs, weak project management,
and poor team coordination. Team members were geographically dispersed,
all using different (and mutually incompatible) Forth systems, and were
completely on their own as to the design of their respective modules.
There was a lot of duplicated and wasted effort, and when integration
time came the result was way too large to fit into memory (not to
mention the components not fitting together at all). Also, some of the
programmers were hobbyists who had never worked on a commercial project
before, and simply lacked the skills and disciplines of professionals.
Bad management is the ultimate cause of most software failures. Good
management can succeed with any language, and bad management often
can't. But managers love to blame languages to exonerate themselves.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
John Passaniti
> Yes, psychoacoustic compression is complex, and I don't really want to
> understand it any more than I have to.
> What I would expect is that any source code that implements any
> complex algorithm should provide a comprehensible _human_ _readable_
> interface.
That would be nice. Unfortunately in the real world, open source
projects range from highly professional examples of perfection down to
crappy pieces of garbage. Do the Ogg Vorbis interfaces suck? I have no
idea since I don't use them. My only comment is that it is both unfair
and intellectually dishonest for you to paint all of open source because
you are unhappy with a particular project.
But hey, don't let that stop you! This is comp.lang.forth!
> In this case, I would like to see a function that compresses a buffer
> and one that decompresses it.
You know such a function exists? I don't. Ogg Vorbis is usually used
in a streaming context, and I can easily imagine that instead of an
external buffer a stream-based compression scheme might want to see a
stream and do whatever buffering it needs internally.
But hey, don't let details like the design of a piece of software get in
the way. Clearly, if Ogg Vorbis doesn't have the interfaces that Howerd
expects, it's junk. But hey, don't just stop there. Clearly, you can
make sweeping generalizations about all open source software.
> My point is that the effort required by me to find those functions in
> "open source" code is of the same magnitude as the effort to
> understand how it works and code it myself.
I seriously doubt it. Your statement may be true of a specific open
source project, but I don't see how it logically follows that because
you find fault with a specific open source project that all open source
projects can be painted with such a wide brush.
>> Open source gives you the code. Open source does not open up your brain
>> and pour in the specific knowledge you need to understand the code.
> Well it should. When whoever wrote the code, presumably they
> understood what it was doing.
> To be truly "open", surely they should explain what each function
> does, to help people understand their work.
So because you're a logically consistent man, you would also fault
Charles Moore for his release of the ColorForth source code, since the
assembly-language listing is essentially uncommented, and the supporting
documentation doesn't cover how the kernel works. Surely, he should
explain what each function does to help people understand his work, right?
>> That is not based on a principle that programming is complicated. The
>> *programming* is visible. You can learn from it. The *ideas* behind
>> the programming may be complicated, but that's hardly a fault of open
>> source.
> Yes it is. Programmers tend to want to hide their expertise. Maybe I'm
> expecting too much, but to me the examples of open source code that I
> have looked at are rarely worth the effort. There is still a culture
> of obfuscation.
Programmers tend to want to hide their expertise? Where is the evidence
for this? Because you looked at some unspecified examples of open
source code, now you're not just painting the open source world, but
programmers in general? Geez.
Blind men and elephants. What part of the elephant have you touched today?
> OK John, here's another challenge for you, to be rewarded by the
> dessert of your choice, to go with the beverage that I already owe you
> ( for your work on the Perl version of the magenta variable ) :
> Please could you search the Ogg Vorbis code and send me ( a pointer
> to ) the file that contains the compression and decompression
> functions, and tell me what they are called. I spent an evening trying
> to do this and failed. Make a note of how long it takes you, and how
> you did it - it could be useful for future projects...
I'm not going to do your work for you. That's especially true here
since it isn't clear that whatever you're working on is something you're
being paid for (or could be paid for). It's also not clear to me that
you picked a useful library for your application. Why did you choose
Ogg Vorbis? Seems to me that you would want to choose a library that
was designed for what you want. Is Ogg Vorbis designed for what you
want? How do you know?
It's also not clear to me you understand your own requirements. You for
example want a function to compress/decompress a buffer. What is in the
buffer? What kind of audio? How many bits? What format? What sample
rate? How many channels? If there are more than one channel, how are
they laid out in the buffer? Does the buffer have metadata lurking in it?
So here's a much better approach to your problem than me doing your work
for you: How about you state your requirements so we can (1) judge if
you even know what you want, (2) know if Ogg Vorbis is suited for what
you want, and (3) possibly suggest alternatives that will do what you want.
John Passaniti
> Jokes aside, I really do want to find an audio compression/
> decompression algorithm - the Ogg Vorbis code leads me down a similar
> path, the main difference being that I don't have the background to
> help give me "hunches". And of course there are many tens, if not
> hundreds of C files, any of which could contain the magic code that I
> am looking for.
Doesn't sound like a productive way to find the interfaces you want. If
I gave a damn about any of this, I might start by looking at any
supporting documentation (internal, wikis, etc.) and then try to find
example code that does something kinda sorta like what I want. I might
also go to their project page and see what code calls libvorbis and see
what code is available there.
> I realised as I wrote this that I am criticising open source software,
> and that this isn't allowed.
It's allowed. But instead of the usual comp.lang.forth model of making
unsupported and grandiose statements based on limited experience and
faulty expectation, you might consider raising the bar. Also, criticism
works best when your arguments make sense. Just a helpful hint.
> Clearly, if I am not part of the solution ( to mega-corporations
> controlling software development ), I must be part of the problem.
Huh? Now you're suggesting that open source is the product of
mega-corporations? Umm, in general, no. Much of the efforts of most
megacorporations are still quite proprietary.
> So, again, I apologise to anyone who feels offended by my criticism -
> there is no doubt some clear, simple open source code out there...
> Apart from the stuff that I have published, of course, but that's in
> Forth so it doesn't count. ( <-- joke ;)
Please point to your open source code that you've published. I can't
wait to see the copious documentation you provide that fully explains
all the interfaces and the educates me fully in technologies I don't
understand. Clearly, you'll be providing the gold standard by which all
else should be judged, and I can't wait to see it.
John Doty
Before you can standardize, you need to have gone through enough
evolution that you've reached a satisfactory, stable point. Forth never
got there.
C was very widely used *before* it was standardized. Python has no
standard, but it has a portable implementation.
> and a tendency on the part of the community to
> oversell the language relative to other options.
Every language evangelist does this. All programming languages are much
better than the average ;-)
> For all its benefits,
> Forth's design center is about simplicity and conserving compute
> resources - especially memory. From a big systems perspective, Forth
> is awkward at string handling and floating point, uses a pretty
> primitive memory model, and never formally supported object
> orientation, among other issues.
C has no string support beyond parsing literals. These things are not
the job of the language, but of libraries. Forth is radically
extensible, but it has never fostered much of a library culture.
> From a small sytem perspective it is
> probably the first language to get ported to any new CPU,
I don't think so. C is usually it.
> and has an
> exceptionally fast development cycle. I am a huge fan of Forth and
> have built dialects into several products (as well as contributing
> Ficl to the open source community), but believe as many others have
> said that a language is a tool, and you need to pick the right one for
> the problem at hand.
True.
--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
Elizabeth D Rather
> jwsa...@gmail.com wrote:
...
> Before you can standardize, you need to have gone through enough
> evolution that you've reached a satisfactory, stable point. Forth never
> got there.
That's a matter of opinion. I disagree.
> C was very widely used *before* it was standardized. Python has no
> standard, but it has a portable implementation.
>
...
>> From a small sytem perspective it is
>> probably the first language to get ported to any new CPU,
>
> I don't think so. C is usually it.
C compilers don't usually run on the target. Until recently, Forths
usually did. Forth was the first language on the 1802, 8080, 6800,
6809, 8086, 68000, and several earlier minicomputers many folks never
heard of, such as the IBM Level 6 and a number of others. It was the
first HLL on the Apple Mac in 1984. Manufacturers introduced their
machines with native assemblers and HLL cross-compilers for minis or
mainframes, so it was easy for Forth to be the first HLL to run *on*
those machines.
Nowadays, for the small microcontrollers Forth cross-compilers give
better results than on-board Forths (better user interface, better
debugging tools, more powerful compiler & assembler). And manufacturers
usually don't even release their instruction sets until their C compiler
is ready to go. But there are still some Forths that run on the small
microcontrollers, and no C compilers that do, AFAIK.
Howerd
> Please point to your open source code that you've published. I can't
> wait to see the copious documentation you provide that fully explains
> all the interfaces and the educates me fully in technologies I don't
> understand. Clearly, you'll be providing the gold standard by which all
> else should be judged, and I can't wait to see it.
Does this count as "open source"?
Its written in Forth, there's as much of the source for each project
as I own the copyright to, and it has no licensing restrictions.
But its not on sourceforge, its not tarballed or version controlled.
Criticism always welcome,
Regards
Howerd 8^)
Howerd
On 20 Mar, 21:41, John Passaniti <n...@JapanIsShinto.com> wrote:
> Howerd wrote:
> > Yes, psychoacoustic compression is complex, and I don't really want to
> > understand it any more than I have to.
> What I would expect is that any source code that implements any
> > complex algorithm should provide a comprehensible _human_ _readable_
> > interface.
>
> That would be nice. Unfortunately in the real world, open source
> projects range from highly professional examples of perfection down to
> crappy pieces of garbage. Do the Ogg Vorbis interfaces suck? I have no
> idea since I don't use them. My only comment is that it is both unfair
> and intellectually dishonest for you to paint all of open source because
> you are unhappy with a particular project.
I used the Ogg Vorbis code as an example, and I haven't reviewed every
open source project.
I think its called having an opinion.
My opinion is, that the open source projects that I have looked at all
follow the pattern of the "hello world" example - they are
multiplatform, locale specific, use tar and gz, libraries, and version
control, all of which make it easier to compile the sources, and
harder for a human being ( me ) to understand them.
Maybe I'm criticising open source for failing to provide something it
was never designed to do.
> But hey, don't let that stop you! This is comp.lang.forth!
Yes - comp.lang.forth is a newsgroup where people chat about their
opinions.
This is not a court of law where I have to prove beyond all reasonable
doubt that my opinion is absolute fact.
I've looked at some open source, and its not very good for what I
expected it to be used for. My bad.
> > In this case, I would like to see a function that compresses a buffer
> > and one that decompresses it.
>
> You know such a function exists? I don't. Ogg Vorbis is usually used
> in a streaming context, and I can easily imagine that instead of an
> external buffer a stream-based compression scheme might want to see a
> stream and do whatever buffering it needs internally.
>
> But hey, don't let details like the design of a piece of software get in
> the way. Clearly, if Ogg Vorbis doesn't have the interfaces that Howerd
> expects, it's junk.
Ogg Vorbis is a valient effort to stop corporate control of software
distribution.
No way would I call that junk. The code is perfectly respectable C
code, and documents many key functions.
My complaint is the difficulty of getting to the code through the
"open source" format.
> But hey, don't just stop there. Clearly, you can
> make sweeping generalizations about all open source software.
Yes. Maybe I'm wrong. Surely everyone reading this must know to
question any and all opinions.
> > My point is that the effort required by me to find those functions in
> > "open source" code is of the same magnitude as the effort to
> > understand how it works and code it myself.
>
> I seriously doubt it. Your statement may be true of a specific open
> source project, but I don't see how it logically follows that because
> you find fault with a specific open source project that all open source
> projects can be painted with such a wide brush.
>
> >> Open source gives you the code. Open source does not open up your brain
> >> and pour in the specific knowledge you need to understand the code.
> > Well it should. When whoever wrote the code, presumably they
> > understood what it was doing.
> > To be truly "open", surely they should explain what each function
> > does, to help people understand their work.
>
> So because you're a logically consistent man, you would also fault
> Charles Moore for his release of the ColorForth source code, since the
> assembly-language listing is essentially uncommented, and the supporting
> documentation doesn't cover how the kernel works.
No, because Chuck did not release colorForth as open source, just a
snapshot of his work for those who were interested.
> Surely, he should
> explain what each function does to help people understand his work, right?
That would be nice. But several people are working on this. Its called
team work.
No doubt Chuck has got more urgent projects to spend his time on.
> >> That is not based on a principle that programming is complicated. The
> >> *programming* is visible. You can learn from it. The *ideas* behind
> >> the programming may be complicated, but that's hardly a fault of open
> >> source.
> > Yes it is. Programmers tend to want to hide their expertise. Maybe I'm
> > expecting too much, but to me the examples of open source code that I
> > have looked at are rarely worth the effort. There is still a culture
> > of obfuscation.
>
> Programmers tend to want to hide their expertise? Where is the evidence
> for this?
I have anecdotal evidence.
> Because you looked at some unspecified examples of open
> source code, now you're not just painting the open source world, but
> programmers in general? Geez.
Yes.
> Blind men and elephants. What part of the elephant have you touched today?
The bits I can reach, obviously.
> > OK John, here's another challenge for you, to be rewarded by the
> > dessert of your choice, to go with the beverage that I already owe you
> > ( for your work on the Perl version of the magenta variable ) :
> > Please could you search the Ogg Vorbis code and send me ( a pointer
> > to ) the file that contains the compression and decompression
> > functions, and tell me what they are called. I spent an evening trying
> > to do this and failed. Make a note of how long it takes you, and how
> > you did it - it could be useful for future projects...
>
> I'm not going to do your work for you.
Last night I found the file codepage.c ( and friends ), and also some
documentation online, so I now know that Ogg is the wrapper and Vorbis
is the codec. And I've got the source code...
> That's especially true here
> since it isn't clear that whatever you're working on is something you're
> being paid for (or could be paid for). It's also not clear to me that
> you picked a useful library for your application. Why did you choose
> Ogg Vorbis? Seems to me that you would want to choose a library that
> was designed for what you want. Is Ogg Vorbis designed for what you
> want? How do you know?
>
> It's also not clear to me you understand your own requirements. You for
> example want a function to compress/decompress a buffer. What is in the
> buffer? What kind of audio? How many bits? What format? What sample
> rate? How many channels? If there are more than one channel, how are
> they laid out in the buffer? Does the buffer have metadata lurking in it?
>
> So here's a much better approach to your problem than me doing your work
> for you: How about you state your requirements so we can (1) judge if
> you even know what you want, (2) know if Ogg Vorbis is suited for what
> you want, and (3) possibly suggest alternatives that will do what you want.
The data is 16 bit 22kHz wav format generaic audio. I need it to be
compressed to a ~48kbit/s stream, using ~512 byte buffers.
Then decompressed back again.
I think the MDCT algorithm might be useful here...
Regards
Howerd 8^)
Andrew Haley
> OK John, here's another challenge for you, to be rewarded by the
> dessert of your choice, to go with the beverage that I already owe you
> ( for your work on the Perl version of the magenta variable ) :
> Please could you search the Ogg Vorbis code and send me ( a pointer
> to ) the file that contains the compression and decompression
> functions, and tell me what they are called.
For encoding, oe_encode at encode.c:111 and for decoding ov_open at
vorbisfile.c:736 followed by as many calls to ov_read at
vorbisfile.c:1528 as you need.
The encoding work is done by vorbis_analysis at analysis.c:49 which
dispatches to the actual encoder in mapping0.c.
The decoding work is done by _fetch_and_process_packet at
vorbisfile.c:484, which calls vorbis_synthesis at synthesis.c:26.
> I spent an evening trying to do this and failed. Make a note of how
> long it takes you, and how you did it - it could be useful for
> future projects...
About 20 mins. In order not to spoil the game, first tell us what
tools you used...
Andrew.
J Thomas
wrote:
> Howerd <howe...@yahoo.co.uk> wrote:
> > I spent an evening trying to do this and failed. Make a note of how
> > long it takes you, and how you did it - it could be useful for
> > future projects...
>
> About 20 mins. In order not to spoil the game, first tell us what
> tools you used...
Aha! You can't find the java files you need without java software,
they're hidden among lots and lots of boilerplate. But with the right
tools it's easy.
And you'll have a lot of trouble with Forth block files unless you
have something like a block editor....
When you visit a foreign country you'll have a lot of trouble
communicating unless you have at least a phrasebook. ;)
Howerd
Thanks!
I used Google and EditPlus2.
I was going to use Doxygen, but gave up too soon...
Regards
Howerd 8^)
On 21 Mar, 12:33, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
Howerd
[snip]
> Aha! You can't find the java files you need without java software,
> they're hidden among lots and lots of boilerplate. But with the right
> tools it's easy.
>
> And you'll have a lot of trouble with Forth block files unless you
> have something like a block editor....
>
> When you visit a foreign country you'll have a lot of trouble
> communicating unless you have at least a phrasebook. ;)
Maybe I'm questioning the choice of a "language" that requires such a
complex phrasebook to interpret it...
Regards
Howerd 8^)
Andrew Haley
Aieee! Howerd is top-posting. Say it an't so, Joe!
> On 21 Mar, 12:33, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Howerd <howe...@yahoo.co.uk> wrote:
>> > OK John, here's another challenge for you, to be rewarded by the
>> > dessert of your choice, to go with the beverage that I already owe you
>> > ( for your work on the Perl version of the magenta variable ) :
>> > Please could you search the Ogg Vorbis code and send me ( a pointer
>> > to ) the file that contains the compression and decompression
>> > functions, and tell me what they are called.
[ ... ]
>> > I spent an evening trying to do this and failed. Make a note of how
>> > long it takes you, and how you did it - it could be useful for
>> > future projects...
>>
>> About 20 mins. In order not to spoil the game, first tell us what
>> tools you used...
> I used Google and EditPlus2.
> I was going to use Doxygen, but gave up too soon...
OK, I'll you what I did: I opened oggenc inside gdb and watched what
happened. I was easy; most of the time was finding and downloading
the sources.
Use the tools Luke Skywalker, use the tools...
Andrew.
[ OK, two flippant movie references in a single posting. Sorry. ]
John Doty
>> Before you can standardize, you need to have gone through enough
>> evolution that you've reached a satisfactory, stable point. Forth
>> never got there.
>
> That's a matter of opinion. I disagree.
>
>> C was very widely used *before* it was standardized. Python has no
>> standard, but it has a portable implementation.
>>
>>> From a small sytem perspective it is
>>> probably the first language to get ported to any new CPU,
>>
>> I don't think so. C is usually it.
>
> C compilers don't usually run on the target.
So what? That often mattered 30 years ago, but it rarely matters now.
> Until recently, Forths
> usually did. Forth was the first language on the 1802, 8080, 6800,
> 6809, 8086, 68000, and several earlier minicomputers many folks never
> heard of, such as the IBM Level 6 and a number of others.
That was a *long* time ago. In those days I knew quite a few people
using various Forth dialects. C was rare: I didn't know anyone who was
using it. But times have changed. Forth has largely failed to adapt,
unfortunately.
> It was the
> first HLL on the Apple Mac in 1984. Manufacturers introduced their
> machines with native assemblers and HLL cross-compilers for minis or
> mainframes, so it was easy for Forth to be the first HLL to run *on*
> those machines.
>
> Nowadays, for the small microcontrollers Forth cross-compilers give
> better results than on-board Forths (better user interface, better
> debugging tools, more powerful compiler & assembler).
So tell me again why it matters that C compilers don't run on the target?
> And manufacturers
> usually don't even release their instruction sets until their C compiler
> is ready to go.
That, of course, speaks volumes about the present status of Forth versus C.
> But there are still some Forths that run on the small
> microcontrollers, and no C compilers that do, AFAIK.
Could be, but this would be a stronger statement if you'd give an example.
Jerry Avins
...
> Nowadays, for the small microcontrollers Forth cross-compilers give
> better results than on-board Forths (better user interface, better
> debugging tools, more powerful compiler & assembler). And manufacturers
> usually don't even release their instruction sets until their C compiler
> is ready to go. But there are still some Forths that run on the small
> microcontrollers, and no C compilers that do, AFAIK.
I have SmallC for 68HC11 and 12, and the Intel 8-bitter than shall not
be named. What a drag compared to Forth on the same boards!
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Brad Eckert
>
> Nowadays, for the small microcontrollers Forth cross-compilers give
> better results than on-board Forths (better user interface, better
> debugging tools, more powerful compiler & assembler). And manufacturers
> usually don't even release their instruction sets until their C compiler
> is ready to go. But there are still some Forths that run on the small
> microcontrollers, and no C compilers that do, AFAIK.
>
Modern processors are usually designed specifically to run C
efficiently and the toolchain the manufacturer offers in order to sell
its chips has C. Although it turns out that a good optimizing Forth
does a good job with these chips.
Long-time forthers may tend to get defensive about Forth, but Forth
stands on its own merits. As long as there is a place in computing for
typeless virtual machines, there will be Forth.
Forth doesn't seem to be actively marketed these days. When was the
last time you saw a Forth-related press release, besides Intellasys or
who's Patriot going after this month? I think there is enough
ignorance about Forth that the antagonism has faded and some marketing
would be worthwhile.
Brad
John Passaniti
> I think its called having an opinion.
Lots of people have opinions. There are people who think the world is
roughly 6000 years old. There are people who think the moon landing was
a massive conspiracy/hoax. There are people who think the Holocaust
never happened. There are people who think there were weapons of mass
destruction in Iraq.
Yes, lots of people have opinions. And some of those opinions are stupid.
> My opinion is, that the open source projects that I have looked at all
> follow the pattern of the "hello world" example - they are
> multiplatform, locale specific, use tar and gz, libraries, and version
> control, all of which make it easier to compile the sources, and
> harder for a human being ( me ) to understand them.
How dare communities form around standards and technologies that make
sense to them and their work! The nerve of them! How dare programmers
care about supporting different platforms and locales! I guess they
didn't get the memo that real programmers only have to write code for
English-speaking Americans who know that the radix point is a period,
not a freakin' comma.
You also mentioned libraries and version control: Yes, those damn open
source people will stop at nothing to obscure their code! No libraries!
Don't they know about the wonderful productivity gains of reinventing
wheels? And version control-- clearly no interesting problems are
solved by that so-called "technology."
Of course to be consistent, I assume you will agree that since many if
not most programmers are not familiar with Forth that you will
immediately recast any public code you have into C. After all, it would
make it easier for them to compile your sources, and easier for them
(fellow human beings) to understand the code. Agree?
> Maybe I'm criticising open source for failing to provide something it
> was never designed to do.
I take a jet and land in Brazil. I walk into a restaurant where they
only speak Portuguese and waiter hands me a menu. It's also in
Portuguese and I can't read it. I ask the waiter to bring me a
cheeseburger and fries. He replies in broken English that it's a
vegetarian restaurant.
Clearly, the restaurant is awful. It was hard to understand anything
because they use English, and they didn't even have what I wanted. But
not only is this restaurant awful, I'd say all restaurants in Brazil are
awful.
Sound familiar?
> Yes - comp.lang.forth is a newsgroup where people chat about their
> opinions.
Yes, and it's also a newsgroup where we all *evaluate* those opinions.
You don't seem to like that part. You apparently want to be respected
for having an opinion, but not for the quality of that opinion.
> This is not a court of law where I have to prove beyond all reasonable
> doubt that my opinion is absolute fact.
False premise. Absolute fact is not the standard here. Logically
defending your statements when you are questioned on them is.
> I've looked at some open source, and its not very good for what I
> expected it to be used for. My bad.
Now you're downgrading your opinion. This started with your statement
that open source (quote) "relies on the principle that programming is
complicated" (unquote).
> Ogg Vorbis is a valient effort to stop corporate control of software
> distribution.
> No way would I call that junk. The code is perfectly respectable C
> code, and documents many key functions.
> My complaint is the difficulty of getting to the code through the
> "open source" format.
Flawed argument. If Ogg Vorbis was distributed privately, the quality
of the code wouldn't magically change. Your beef is with the quality of
the documentation of Ogg Vorbis. How you morph that into some grandiose
indictment of open source is not demonstrated by anything you have written.
>> But hey, don't just stop there. Clearly, you can
>> make sweeping generalizations about all open source software.
> Yes. Maybe I'm wrong. Surely everyone reading this must know to
> question any and all opinions.
I certainly wish more people in comp.lang.forth would start openly
questioning the opinions and prevailing assumptions that underscore most
of the discussion here.
>> So because you're a logically consistent man, you would also fault
>> Charles Moore for his release of the ColorForth source code, since the
>> assembly-language listing is essentially uncommented, and the supporting
>> documentation doesn't cover how the kernel works.
> No, because Chuck did not release colorForth as open source, just a
> snapshot of his work for those who were interested.
The essential quality of open source is that the source code is
available. Different open source projects make the source code
available for different reasons. Charles Moore most certainly did
release ColorForth as open source. To say otherwise suggests you're
using a very private and very bizarre definition for "open source."
>> Surely, he should
>> explain what each function does to help people understand his work, right?
> That would be nice. But several people are working on this. Its called
> team work.
Same for the Ogg Vorbis documentation? So incomplete documentation
being filled by a community of volunteers is a good thing when it's
ColorForth, but it's a bad thing when it's Ogg Vorbis. Interesting.
> No doubt Chuck has got more urgent projects to spend his time on.
Not the issue.
>> Programmers tend to want to hide their expertise? Where is the evidence
>> for this?
> I have anecdotal evidence.
Wow, that's compelling.
> Last night I found the file codepage.c ( and friends ), and also some
> documentation online, so I now know that Ogg is the wrapper and Vorbis
> is the codec. And I've got the source code...
Seems relatively inefficient for you to look through code to discover
that when that fact is documented on their web site.
> The data is 16 bit 22kHz wav format generaic audio. I need it to be
> compressed to a ~48kbit/s stream, using ~512 byte buffers.
"wav format" can mean one of several things, but I'll assume you mean
PCM audio, probably signed integer format. You don't say if it's
stereo, so I'll assume mono. You also don't specify what the audio is,
which is important when choosing a codec (is it speech, music, a
mixture). One would also want to know other details like if this needs
to operate in real-time or if it is processing offline. And if it is
real-time, what kind of processor and memory bandwidth do you have.
> Then decompressed back again.
> I think the MDCT algorithm might be useful here...
MDCT (or variations on it) are part of many audio compression standards
and yes, it's obviously useful in that context. The question is if the
specific attributes of MDCT (such as using overlapping buffers) makes
sense to your application.