Re: Speaking of Forth..

"Randy M. Dumse" wrote [snip]

I agree. " 2+3=5" was *not* how we were first taught. Instead, first we would write the "2", next we would write the "3" underneath it, lastly we would perform the operation (in this case "+"). Sounds to me like we were first taught something much closer to RPN...

-Doug

Lot's of do's and don't there, your sudden highness. Sorry, I don't respect the concept of someone-out-of-the-blue telling me what to do, and what not to do. I'll return the favor with a bit of advice. Don't be so silly.

As far as Forth in business, perhaps you think all those Sun Sparc stations shouldn't have a place in business, because they rely on Open Boot, which is, oh yes, a derivative of Forth, without which they couldn't boot up.

And then we should require everyone to abandon PostScript, which made Adobe one of the highest-grossing-per-employee software companies in the world.

And then we'd have to tell FEDEX to stop using their terminals their drivers rely on. You know, the ones that positively, absolutely help FEDEX get it there overnight.

Just to mention a brief few...

You are certainly not the boss of me, despite your imperial bravado. For my part, I am a self made businessman, with 20 years experience as President/CEO, with a company which has averaged more than a million per annum for more than a decade. I have to wonder if you are the boss of anyone, and how you can imagine you can speak for the business world. If you want to be credible, tell us what position you have in business, that you imagine you can tell others not to "bring Forth into the business world, we don't have time", particularly since 1) it is already there, 2) and has been the past 20+ years, and 3) saving business time and money is one of the key reasons many of them consider the use of it "a trade secret".

Me, very slight extrovert, very strong Intuitive Thinker, very strong P.

It's hard for me to imagine anyone creating a non-trivial C program that is flat, also.

Oh, do you mean operator overloading? Some consider that to be a double edged sword in the C++ world.

The language features are there to be taken advantage of. Not everyone chooses to do so.

[snip]

Well, I just checked the source code on my FreeBSD Unix system (which comes with all the source) and did a quick scan through the sources for most of the system utilities that are usually found in /bin, /sbin, and /usr/bin. These sources make up the normal commands that you expect on a Unix system such as 'find', 'route', 'cp', etc. In nearly all cases I looked at, the 'main()' routine was very short - all it did was collect command line options, set flags, and the dole the work out to other routines, which themselves doled work out. The bulk of the code was pretty easy to follow. Function names seemed to be chosen pretty well so that I could tell what the function was likely doing without having to read its source. And there were plenty of comments, even though the code was very readable to begin with. In summary, I have no trouble at all understanding what this code is doing; this is code not written by me or to my normal programming style by people I do not know, most of it written many years ago.

Well, you've explained it, and I think I understand what you are saying, but I don't find this to be a huge difference.

If I say (please correct my forth if I don't get it quite right, it's been a while):

:sphere_volume 2 ** pi * 4 * 3 / ;

or in C I write:

double sphere_volume(double radius) { return pow(radius,2) * pi * 4 / 3; }

In forth, you now say:

7 sphere_volume

In C, you can say:

sphere_volume(7);

In FORTH, sphere_volume becomes part of the "dictonary", I think that's the term. In C, sphere_volume becomes part of the symbol table. What's the _fundamental_ difference?

Maybe I'm missing your point completely, but in C you can do that like this:

#define is_now_assigned_from =

distance is_now_assigned_from get_echo();

But to me, that is far less readable.

Oh, and in case the parens really bother you, you could do this, but I can't imagine why you would want to:

#define get_echo __the_real_get_echo();

distance is_now_assigned_from get_echo

In most computer languages, punctuation is imporant. It helps to remove ambiguity and helps to make the language parseable by a machine. I've seen some people change the curly brackets in C to be "THEN" and "END" like so:

#define THEN { #define END }

I just don't see the point, though. This doesn't change the language. Perhaps it makes it a little easier on the person that wrote it that way. Maybe they are trying to make C look like Pascal. Whatever - more power to 'em.

Perhaps we will, but there still must be something I'm missing that is obvious to you. Perhaps some OO'ness that I'm not aware of or something.

The forth stack doesn't really bother me. But I'm equally adept using an RPN calculator as an infix calculator which seems to be the metric in this thread. As a preference, I prefer RPN.

I think I was perceiving the blame to originate from you; yes, that seems to match our types :-) I.e., when it comes to FORTH, you blame bad coding, missed deadlines, etc, on the programmer, but when it comes to C, you seem to be saying that, if instead they'd used FORTH, they'd be finished long ago and would now be sitting on the beach with their toes in the sand.

And I said that is a double standard.

That would fit into the category of bad code, of course. By bad code, I don't mean that it doesn't match my programming style, or the variable names are too short. I mean, first and foremost, the code doesn't perform as required. Part of "perform" entails time to completion, so if the code is not functional within a reasonable amount of time, or within budget or whatever, it's still bad code, no matter how pretty it is. I've been using the term "bad code" to encapsulate all that.

So I think we are in agreement in this respect. So we must still be miscommunicating somewhere.

Here's where things stand, in my view. Several folks were discussing FORTH and its virtues. No big deal, some folks reminisce about the good old days. Blueeyedrop, in the process of expounding the virtues of FORTH and anything that begins with Iso*, does so by trying to paint a picture of C programmers as a bunch of "flailing" clowns that can't get any useful work done, with the implication that they can't get any useful work done because they are using C and not FORTH and Iso*. At that point, I offered another point of view, that there could be another reason that they can't get useful work done. You back up and reinforce the "flailing clown" image, bringing in personality traits and all sorts of things. You seem to insist that FORTH is the next best thing since sliced bread, and truly is a marvel to behold. My position is that FORTH is pretty cool, but regarding the sliced bread and marvel thing, I just don't get that from it.

I've tried to state my position a few times: that Blueeyedrop's characterization that useful work using C is a rare event, is unfair to say the very least. But we seem to not be making a whole lot of progress. I see the thread has already devolved a bit into FORTH bashing by other folks which is too bad - not my intent. But we are where we are because of C bashing by Blueeyedrop, to which I stated my alternative view. And I see you and several others were quick to defend FORTH (and rightly so). But again, I see a double standard in that when I seek to ever so mildly defend C from your (Blueeyedrop's, actually) bashing, you still are adament that the bashing justified, and continue with the notion that C is inept for getting real work done.

And here we are.

You've said a couple of times that FORTH has been your life's work. You obviously feel strongly about it. So lets just leave it at that. I don't see much good coming from continuing like this.

But sometimes we shouldn't take ourselves so seriously, and with that in mind, here's a little page that I find amusing (hopefully no one takes too much offense - it describes programming languages in terms of women):

I especially like the description of BASIC :-)

Cheers,

-Brian

Whoa, Lots to reply to there...

In essence,

I recanted my position slightly in a previous post. Upon examination of the tools and techniques on some of my co-workers. It was really the tools, and not the language that was such a hold up. They just happen to espouse C so vhemently, in conjunction to their way of doing things, that got carried away. For the record in my original post, I stated:

"I get really nauseous at work when I see the C'ers flailing about, and then I come along and crank out month long projects in days. It has gotten to the point where the other engineers come to me for the "quickies" like test fixtures, because I turn around something in IsoMAX in a couple of hours."

This is a personal feeling. I do the quickies, because I have configured my style of operating to allow this. FORTH is but a part of it.

I did not refer to them as "clowns". They are highly capable, just not terribly efficient, and for a variety of reasons. Again, my bad there.

As far as language is concerned, If you are familiar with Randy's FORTH products, you will know that the compiler lives on the machine.

This means that after: :sphere_volume 2 ** pi * 4 * 3 / ;

you can then ask the compiler to do the following:

7 sphere_volume , and get an answer on the command line, much as you can set and read variables, or test words that you have defined.

In IsoMax, you can go one step further, and have software running in the background, while programming in the foreground. I do not know of any other microcontroller language available that can do that.

If Randy had chosen C instead of FORTH to be the system of choice, there would certainly be some differences between Randy's C and standard C, but Rand'y C would have been infinitely more useful.

IsoIsoIso. Yeah, I love the IsoPod, but in truth, when Randy suggested it to me, I suggested that he do the IsoPod in BASIC, citing it's wider acceptability. After lengthy debate, he convinced me that it would infinitely mere utilable based on FORTH.

Again, I am a firm believer of a few concepts.

The right tool for the job. A good programmer is adaptable to the language requirements of a project. Programming language is an artifice to teaching programming. You shouldn't teach C, BASIC, FORTH, until you have taught flow control, the concept of variables, and the concept of conditionals.

mike

I would say you're clearly exaggerating about this one. There are still a lot of areas where assembler is the only "viable" option, especially in small microcontrollers and DSP-based projects.

FORTH has been indeed used in a variety of "embedded" applications in scientific areas, I'm not denying this. Anyone can go visit

- which is nicely promoting the FORTH language.

As to LISP, unfortunately your example is the one that is off base in my opinion. You should have chosen your example more carefully to make a point. What you are describing is not what I call an embedded environment per se. You are talking about some kind of "scripting" ability built in a commercial software package. We may differ on what we both call "embedded". Clearly, in this kind of area, an interpreted, easy to learn and widely used language can prove very useful. Emacs itself, a very well known text editor package, is almost entirely based on a variant of LISP and can be enhanced this way. I wouldn't say it's the fastest editor around either. But arguably, it's one of the most feature-rich.

I haven't forgotten anything, I would even add that any programmer using C without knowing the underlying facts is a lame programmer.

That being said, data types is one of the things that define a "high-level language". The ability to use abstracted data types is very useful. I don't know how you can really define data types in FORTH. You can implicitly use them, yes, but not with a lot of abstraction.

Of course. Obviously. I'm just saying that the way of expressing data structures (especially when they become complex) is far from explicit using a language like FORTH, and still too "direct" to be called a high-level language.

I have learnt and used LISP in the past. I was probably going a bit overboard using the word "obscure". LISP can be used for pretty much anything, but it's essentially not suited for expressing inherently sequential tasks. It can be done, of course. But it can get very hard to read. In the same vein, PROLOG was advertised as the almighty programming tool in the 80's. I have learnt PROLOG, and as interesting as it was, I wouldn't use it in any embedded work. Just writing a purely sequential task in PROLOG is higly doable, but is exotic to read, to say the least. Of course, that may just be me.

You're right about that, nothing to add here.

I wasn't being rude to you or anyone else in this debate, so I'm not sure why you'd feel compelled to be rude to me.

I said I'm personally not "convinced of the practical use of interpreted languages in an embedded environment".

To begin with, I don't think it was that "strong" of an opinion, since I used the word "convinced". I could have gone like: "interpreted languages are crap", it seems like it would have made no difference to you. Oh well.

Anyway, saying what I said is a double-edged sword: for one, it means that I'm yet to be convinced, but that I'm open to if any solid argument and practical work can prove that to me. Secondly, it means that I'm still *personally* cautious about all the "interpreted languages hype" that's been going on for several years in most areas (I'm particularly thinking about Java, C#, and the like). I have good reasons to remain cautious and have arguments against it *especially* in the embedded world, I'm not going to write a 200-page book here.

Yes, I do know. Again, FORTH is an interesting concept, but there are, in my opinion (again, I only speak for myself), many drawbacks in the way it's executed, for instance we can raise issues about the code execution process in terms of security.

I'm not the one who raised the business considerations. I have to agree with you here. As long, of course, as the result meets a certain quality standard. Unfortunately, time-to-market is sometimes more important than performance. But that's an entirely different debate.

Yes, of course. Choices. Your example is interesting, by the way. You're right, but without being totally "stuck", you can still have your own views about things - provided they are based on something real and not imaginary, provided you can back them up with some *real* arguments, and not "emotional" ones. You can still have opinions, that doesn't necessarily do harm to your team - it can actually be a plus. Either way, all I would say is that if you *knew* that

*you* wouldn't do a good job using some tools, you'd be entitled to offer alternatives. There is no absolute best, that's for sure. But there can still be choices that are better for *you* than others. That's also what makes you unique, don't you think? And if you are to dedicate your work force on some project, I still think you're entitled to have a say in the tools you're going to use. That doesn't mean you shouldn't be open to new stuff.

Well, I wasn't going into details. But, FORTH *is* stack-based, you can't claim otherwise, can you? And as long as there is use of a stack as the main storing space, that raises some specific issues. I'm not at all saying that it's an unusable approach.

Yes, you're right. "The right tool for the job" is not always as easy to define as you seem to say, though. Like you said before, there is no best. Besides (using your own arguments), you could always find some engineer who would maybe write a wonderful image processing package in FORTH.

Ultimately, you said it best: "So, C++ is the right choice for me and for that application class."

You can't claim there isn't a subjective part in the choice of tools you're willing to use, you admitted it yourself.

The key words are right here: *for you*.

I may have my own arguments against some tools you use, and likewise you maye have some against the tools I tend to prefer. That's what I call a debate.

No need to make people that don't agree with you 100% look like they are stupid and uneducated. ;)

...

I sincerely apologize if it came out that way. That was not the intention.

You have to admit that coming out and portraying Forth, the programmers that use it and the applications written in the language as amateur toys was just a little off-base given the wide range of commercial applications that the language has attracted. That sort of an assertion at the start of your email is what, in my mind, made everything else you said seem like strong opinion without a solid foundation.

From your post it is clear that you understand that there are no absolutes. And, yes, a lot of it is also subjective. A few points/corrections:

As you pointed out, I strayed off the path with the LISP discussion. I forgot that we were talking embedded. I don't know of any LISP-based embedded systems and I'm not sure it would be a sensible idea at all. I was just talking about the power of a language to modify the reasoning leading to problem resolution.

Well, you have to define the problem space first. If I am doing a project where the project timeline is much more important than absolute performance AND the processor is already fast enough that resorting to assembly coding would be a waste of time assembler is not the right choice. It might be (emphasis on "might") safe to say that a good deal of today's commercial embedded applications are written in C, with inline assebly thrown in for peformance-critical routines. I used to be really sensitive to code bloat. But, look around you, unless you are using the little $0.99 PIC's and similar low-end processors the power, speed and memory capacity of todays embedded processors is mind-boggling compared to just a few years ago. Look at what's been happening to the '8051 family, for example. From 12 clock per instruction cycle to 1~4 in modern clones. Some chips have 64K of RAM and FLASH ... all for $10 in production quantities. So, as a business owner, what would you have your programmers do? Get the project done quickly in C (or Forth, or Basic) and get the product to market quickly or have them diddle with assembly and take twice as long?

That's why I said that assembler should be the last resort. In non-consumer (read: cost-sensitive) applications, I rather replace the microcontroller with a more capable version, spend another $5, $10 or whatever is reasonable and enable the programmers to go as fast as possible with a language above assembler. That's just the business equation intersecting with engineering. Real life.

You simply define a family of words that know how to treat whatever data type you need to operate with. After that it's a piece of cake.

Yeah, it is. What I was thinking about though are applications (and there are a lot of them) where the performance of even the cheapest of todays embedded processors is so far beyond what you need that you might as well use the fastest tool to get the job done, since no perceivable performance penalty will be evident. Does a digital sprinkler controller really need to be coded in assembler? Proabably not. Or how about a little processor that runs a machine's control panel (a bunch of buttons and knobs), probably don't need assembler in this case either. Now, if you are running servo motors for an high-speed industrial machine of some sort, well, that's different. You are almost guaranteed that you will have to use some assembler, if not having to write the entire thing in assembler. Years ago I did a design using a PIC16C56 that needed to squeeze the last bit of performance out of the chip. I didn't have clock cycles to spare. Of course, assembler was the only way to achieve this.

No, of course. But you don't use the stack to store your arrays or structures, it's simply a working space, if you will.

I'm sure that could be the case. But not on my dime, that's for sure! :-)

You bet.

BTW, I'm working on a project as we speak where I made the mistake of using the wrong tool. I wrote this whole application in assembler (Cygnal 8051) and I now wish I had used Forth or C. The application ended-up growing to the point where I know it will be a pain to support and (more importantly) get others to work on it in the future. So ... I'll probably either have to re-write it myself using another language or pay somebody to do so at a later time. Oh well.

Lots (of) Infernal Stupid Parentheses

Yup.....

Stack based assembler approach.....

Push Operand A Push Operand B Add Pop Operand C

Forth style..... A B

• !C (ISTR)

Is there some difference here?

Like all assemblers, if you make an elementary error in register handling, such as popping a return address from the return stack your program fails in a way that is only possible in an assembler.

(Excepting array bound errors in, C, for example)

The seminal ideas in Forth were published in a two-stack computer, the English Electric KDF-9 long before Forth came along.

etc, etc.

Grow up, OM.

How does an architecture that does not have any stack processing at all, be "as close as you can come to a FORTH chip"?

Sure, there are published ways to implement stacks in software, but these typically take a sequence of

6 to 8 instructions to implement, AN INTERPRETATION OF STACK PROCESSING. and interpretation is where I came in.

A rather over-long reply, most of which went unread because it went off the bottom of the page (the tribulations of bottom posting!)

ITYM, _TRIVIAL_ microcontroller systems. There are many microcontrollers on the market, in particular the ARM derivations used in GSM phones which sport several megabytes of on-board program flash and whose program code is produced and maintained by teams of 100 softies.

For _VERY_ obvious reasons, FORTH is not used in these apart from some trivial booting routines produced by electronic engineers who are otherwise untrained as softies.

In my career, I have seen many instances when well-paid electronic engineers became grossly-overpaid junior programmers. The code they produced had the same quality as any other code produced by untrained junior programmers. PE and CEng are no guarantee of coding capability!

That an application is used in space systems is no guarantee that the authors of the program were professionally competent in the software that they themselves wrote to accompany their own hardware creations.

In fact, your example is even worse than I first thought, because before you can even start producing an interpreter for FORTH, you've got to produce an interpreter for a

16-bit machine.

Sure, it's got 16 bit registers, but you can only access them in 8 bit chunks, and to copy one

16 bit register to another, takes a sequence of 4 instructions of the form...

Load Register A Low Byte Store Register B Low Byte Load Register A High Byte Store Register B High Byte

Altogether a very weird and almost unusable architecture, which is unfortunate because it had a full complement of _BOTH_ Branch _AND ALSO_ Skip instructions.

Well, let's at least admit it: the main reason why LISP was even created at first, was the extreme simplicity of the needed underlying interpreter, due to the extreme simplicity of the syntax (really, how much rawer can you get...)

Then speaking of RPN, I have a hard time seeing how "A B +" can be more intuitive than "A+B". It's much simpler to write a RPN expression evaluator though, and that's probably what motivated it in the first place.

I'll take your word for that. I do have somewhere in my paper archives a LISP interpreter written in LISP; probably only half a page of code.

PN evaluation.....

1. PUSH each operand onto operand stack as it is encountered (same process as RPN)
2. IF Operator is higher precedence than previous stacked operators, then PUSH onto operator stack... ELSE POP and execute each operator that is of higher or equal precedence to latest operator then PUSH latest operator onto operator stack.

Do not stack brackets, but make them increase (LH) or decrease (RH) the precedence of all subsequently stacked operators by HIGHEST_PRECEDENCE + 1.

Unaries are dealt with by PHP (Pretty High Precedence!)

It didn't have a stack archetecture exactly, it had 16, 16 bit registers that could be used to point anywhere in the memory. So, on register is the stack pointer, one could be the return stack pointer, one could be the instruction pointer.

In fact, the COSMAC had no gosub command. You were supposed to use threaded code like FORTH. Any of those 16 registers could be the program counter. There was a command that made a specific register the current program counter. If you wnated to do a subroutine you load a register with the address and then made that register the current PC and off you went. Just like FORTH.

The later model of the COSMAC - the 1805 - was designed for FORTH, with a stack pointer, commands like swap and drop ( I think... it's been a while) and other enhancements.

I miss my COSMAC. If I had an EPROM programmer I'd run over to HSC and pick up a few to play with.

I thought so. You know, I've had my HP-12c for almost 15 years now. The best calculator I've ever had. I still have the same batteries! The only times I need another calculator is when I have to find the sine of something. I love lending it out to my students and watching their reactions. If I'm lucky I can get into a disscussion about different ways of dealing with arithmetic. It's great!

The decision was made on hardware grounds - radiation hardened and low-power CMOS; and not on software grounds.

Having made their choice, they were then forced to write an interpreter of some sort to make the device usable.

Hardies, being rank amateurs as softies, go for Forth.