Re: Speaking of Forth..



Well, apart the fact that the 4004 JSR stack has a maximum depth of three levels.
I would like to see a forth implemented with a 3-levels stack :-)
Ciao Francesco
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"has"? "had"!
Perhaps you could do it by emulating "Push" and "Pop" routines for a larger stack, as the proponents of the Cosmac seem keen to do?!
Bwahahahahahahahaha!

levels.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I don't think Forth would survive long in today's re-entrant, address independant code world on a decent op sys. The vector system would require a routine to intrepret addresses relatively and would slow the standard call and return techniques built into modern CPUs right down to a crawl. We may as well implement it on the 1802 then.
(extra text trimmed for 1802 people) LOL
wrote in message

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

INTJ, Strong Introvert, extreme Intuitive Thinker, very moderate J.

True to a degree. It's hard for me to imagine a Forth program which is flat, with no definitions to speak of. However, my one example earlier in this thread is so short it is almost flat. Of course, it wasn't much of a system, just a single "driver" to handle a single sonar ranger. It was written as it was specifically so it could be modular, and work with a larger system.

In C you never change or extend the language. Consequently, that makes it pretty much non extensible, so yes, that would be less.
C++ is arguably extensible with its OO stuff.

By comparison, I would call it only moderately conducive to modular programming.
The natural human tendency to clump concepts is about 7 plus or minus a few. Some people can handle more, some less. First evidence for this can be found by naming all the popular idealized shapes, in order of their sides. Okay, 1= point, 2=line, 3=triangle, 4=square or rectangle, 5=pentagon, 6=...ah... star of david ....ah... hexagon, 7=...ah... ...ah... not sure, ...ah... don't tell me, maybe I can remember some latin and figure it out... ...ah... 8=stop sign (octagon) 9=...ah... ...ah... ...ah... ...ah... round of course! all round from there on out. Why? because we have trouble with clumping larger groups in our internal mind space.
Hence we are very comfortable remembering 7 digit phone numbers. We are all challenged to remember 10, so we tend to mentally store them in two groups, area code, and the familiar 7 digits, as an example.
As another indication of the mental match, think how many words in the dictionary take around seven words to describe their meaning. To demonstrate this I decided to pick some word at random and see if I could make my case. I went to an open Browser, which happened to be on an ebay page, and saw at the top, "Search". So I'll take that for my example. I go to dictionary.com http://dictionary.reference.com/search?q=search 1.. To make a thorough examination of; look over carefully in order to find something; explore. 2.. To make a careful examination or investigation of; probe: search one's conscience for the right solution to the problem. 3.. Law. To make a thorough check of (a legal document); scrutinize: search a title. 4.. 1.. To examine in order to find something lost or concealed. 2.. To examine the person or personal effects of in order to find something lost or concealed. 5.. To come to know; learn. Look at def 1. Although there are many words in def 1, there is a grouping to convey meaning, and repetition to enforce the meaning:
To make a thorough examination of; (6 words) look over carefully in order to find something; (8 words) explore. (1 word)
Now def 2.
To make a careful examination or investigation of; (8 words) probe: (1 word) search one's conscience for the right solution to the problem. (10 words)
And so on. You can go through the other definitions. I hope you can see the loose, emerging pattern from this very short and arbitrary selection. The human mind is not terribly rigid on the number of words needed to define another, but there is a general pattern of using short phrases of 7 plus or minus a few words to define a new word.
Now advanced Forth programmers often discuss (okay, argue) about the correct size of a definition in the language. The general concensus (such as there is) is that Forth words (procedures) should generally follow the natural language pattern.
So Forth programs are generally written to be pyramided with concepts named every few words, about 7 being ideal.
If C programs were normally filled with functions with 7 or so references in them, I would say, yes, it is very condusive to modular programming. But I doubt you can show me much in the way of C programs which are written to this style. I think it would be more correct to say, C allows modularity, but does not encourage it to occur in a natural language style.

and any other language that allows one to create callable

You don't see a significant difference between Forth calls and other languages that allow calls? Hummm...
Well, how happy would you be with your C language (or others) if in order to use any of the existing functions of the language you had to call them? So to add something you'd have to do +(a,b) or to increment some variable you had to call ++(i). Yet every additional procedure you add to C you have to make a specific function call usually with parameters, etc., etc.
By comparison, every procedure added to Forth becomes another intregal part of the language. You can use it the same as the original language functions. So + and PING are on an equal footing. To me that's a pretty remarkable difference.

Notice all of these are still C-like. ping() can be identified by the parens as a function. The = is the only way to make assignments.
In Forth, the language can "morph" to be anything you like. For instance I could redefine "=" to be "is_now_assigned_from" if I wanted, and your last example line there would become
distance is_now_assigned_from get_echo
which has completely lost its variable, reserve-word, function-call origins and approaches English-readable self-documenting text.
If you don't see that as a rather unique power to make an application package read as a more natural language... I guess I will not be able to explain, and we can agree to disagree.

Granted.
The stack is a huge stumbling point for some. Personally, I take as little note of it as possible in my programming. I encourge the use of variables rather than stack. Here I vary in orientation from other Forth experts.
One of my missions is to introduce to IsoMax(TM) a GUI interface which completely hides the stack from the user. I think I may have already mentioned, all compilers must take the code to RPN, in order for the machine to work. By presenting the algorythm as a 2D tree, the computer can see RPN and the human can imagine mid fix, and both understand the same algorythm in quite different ways.

Exactly the same can be done in Forth. I encourage use of variable, because of the human clumping issues, it becomes very difficult for humans to track more than a few things at a time.

Yes, perhaps.

Surprizing. Assigning blame is certainly appropriate to judging, as the name Judgement itself suggests. Well, they say we treat these as prefered, and less prefered modes of thinking. We use them both to varying degrees. I myself nearly split the J/P. And looking at the described personalities for the INTJ and the INTP, I can see myself in both of them.

Ah ha. I think I might now understand the crux of our miscommunication. You are objecting to blueeyedpop's comments thinking he is saying C programmers produced bad C. I don't.
I think what blueeyedpop has been refering to is C programmers producing nothing useful. They didn't produced bad C. They didn't produce enough C. Specifically, they didn't finish.
If I were to translate for blueeyedpop, when he says, "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", I would say his point is he's seen teams spend months working on something which is not completed and management was told it was unattainable, which he could have (and then even has to demonstrate his point) completed in a matter of days in Forth. He's not nauseated by the code. He is only considering one small aspect of the code - it doesn't work! He's instead nauseated at the cost to the company, in wages, market opportunity, and lost revenue. He can correct me if I'm wrong, but I've heard him speak of this many times.

True enough, but what are your measures of good and bad? If one programmer write a program in a week, and another in a month, and both perform adequately, is there a standard to say which program is good and which one is bad? There are many. We could compare code size, and elegance, and CPU useage, maintainability, clever naming of variables, readabiility of comments etc., etc. But if both programs are adequate, then there is one prominent measure of good and bad. The one that took longer to write cost too much!

Well, if productivity is a measure of quality, then I very much disagree.
If we were most productive in machine code, there'd be no assemblers. If we were most productive in assembler, there'd be no high level language. And so on. I would suggest one of the most significant measures of the power of a language is how much programming can be done in how short a time. Productivity is a key measure of power, and the language used or its particular syntax makes a huge difference in quality.
For instance, if the subject is "What If" business model charts, then any moderate Excel programmer will beat the pants off any excellent assembly language programmer, in man-hours invested vs. useable output (mythological "John Henry" type examples aside!).
If the subject is interactive interfacing to hardware level controls, (robotics specifically) I'm of the opinion there is nothing I've found to be better than Forth. But again, that's a bias based on the focus of 20 years of my "life's work", so it should not be surprizing I hold such an opinion, nor should it be assumed I say it lightly or without pertinent experience.
Randy M. Dumse www.newmicros.com Caution: Objects in mirror are more confused than they appear.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sun, 13 Jul 2003 16:00:37 -0400, Randy M. Dumse wrote:

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):
    http://twirl.mcc.ac.uk/hfiles/aaaadgu.html
I especially like the description of BASIC :-)
Cheers, -Brian
--
Brian Dean, snipped-for-privacy@bdmicro.com
BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
<big snip> 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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Yes, overloading and such for C.
The same double edge in Forth. There are many swords here, most have at least one edge.

Close enough.
I don't recognize the ** as a commonly available operator (integer at least), but really no biggie, if I needed it I could easily write it to work with your code exactly as written.

Yes. As would "**", if I wanted to add "**" to my code to run your code untouched.

In Forth new words take up one cell to instantiate a call in the final program. What would it be in C? Wouldn't there be an opening of a stack frame, transfer in of variables, a machine code call, a transfer of variables out, and a stack frame clean up?

Oh, I hadn't thought about the C #define in years. Essentially a one-pass, preprocessor substitution, isn't it?

Many (me too) like to redefine CONSTANT in Forth to be IS. Gives more readability. e.g.
360 IS COMPASS-LIMIT

Mostly what we've been discussing above falls into "nuances" of the languages. What do you think of the suggestion Forth programmers are faster than C programmers?

If you can show me were I said Forth programmers missed deadlines, I'll consider your argument. I believe I said, Forth is an amplifier. A good programmer can write very good code, a bad programmer can write really bad code.

Yes, I seem to be saying that. It's not a double standard if the Forth programmers actually did finish long ago and are sitting on the beach with their toes in the sand, eh? Mike mentions an actual event: three programmers, three months, asking for many times that more to finish; Mike three days, done. That would be long gone, wouldn't it?
Charles Moore, the inventor of Forth, often says he looked at his life, and how program developments were taking several years to finish. He thought to him self, that means he's only going to get to work on 10 or so projects in his carreer. He says he invented Forth with a a hope he might work on hundreds of projects in his life.

I believe now it is because you cannot concieve that using one language vs. another, in a given domain of problems, can cut programming time by 10x.

Didn't you add the clown part?
I believe what Mike meant by "flailing" is they were: trying lots of approaches, finding lots of problems, making lots of noise, having lots of meetings, and complaining loudly how hard a problem it was, saying it would take about another year. I wouldn't characterize that as "clowning" but as pretty much a "normal product cycle".
If you think they are clowns, because Mike actually wrote a program which did what they were trying to do in three days, well..., that's your interpretation, isn't it?

No no. This is not a hypothetical. It is not an issue of they "can't". This is an actual experience, something that happened - history! There is no implication here about what they can and can't get done. There is only the fact that after months of trying, a team of three programmers working in C "didn't" get done.

Again, "can't" doesn't apply. "Didn't" is all that matters.
Mike got tired of watching them drawing their salaries and sliding the project out, so he "did" what they were saying they couldn't do, and it only took him a few days to do so.

Show me where I did that please, particularly the clown part.

The reason you've encountered resistance, is because of your injection of straw men into the argument. What you have above is that you've tried to state you opinion that his opinion is wrong. Which would be fine if it was his opinion. It isn't.
You create a strawman when you say, "Blueeyedrop's characterization that useful work using C is a rare event". I assure you, blueeyedpop's holds no such position. Go back and find evidence of your claim about his claim. Show me where.
I don't think he has anything against C. It's just not what he prefers, and he has a reason, and it is based on his personal observation, and the history of his own personal experience.
I don't have anything against C. I have about the same experience as he does, where Forth and C were compared.
I think I can speak for both of us if I say, C is fine, and ordinary. I might even go further and say, I'm glad C is out there. It fits many programmers thinking much better than the language I prefer, so indeed, they can be programmers in some language, even if they aren't as fast as I am.
But they can never hope to get things done as quickly, or as elegantly, or with as little resources, etc., as I can in Forth, within the limited domain of programming problems I have chosen for myself.
Outside that domain? I might even use C (and have actually) for certain problems. (Particularly ones where a team is needed, because it is so rare to find compatible thinking types who can handle the power of Forth to such advantage.)
A parallel: Out in my garage, I have a Lotus Europa. It weighs almost the same as a VW Bug of the same vintage. Both have one stearingwheel. Both have four wheels. Both have four cylinders. The engine is in the back in both. They even get comparable gas mileage. But the Lotus does straightaway speeds the Bug can only acheive in free fall, after driving off a cliff.
I happen to like the Bug (particularly the new one; my wife and I are considering buying one). But despite similarities, if I want to go fast, I would choose the Lotus. Now the Lotus has its own set of disadvantages. It is a bit harder to drive than the Bug. You don't see lots of them. Not everybody can handle it. Easier to make mistakes and have specatular accidents. But it was my everyday driver for about 6 years. The Bug is slower, bigger and perhaps safer.
Would you readily disagree if I said I got somewhere twice as fast in the Lotus as some guys in a Bug did? I might say, when I passed them they were failing the Bug for all they could get out of it. Would you argue I just said Bug drivers are clowns? or they couldn't get anywhere driving one? I hope not.
Same here. If you can't allow people to even express their personal experience and observations without saying they're bashing something... aren't you insisting on a revisonist history to fit your own biases? or protect your world view from the possibility there is another way of doing things, that might actually be faster or better?

I just wanted to make clear I am not arguing for the sake of arguing. It's not a "my sports team can beat your sports team" level of enthusiasm. If I can manage to "feed" myself for these many years, and could have chosen something else if I thought it were better, then there is more than casual commitment. I've made my money where my mouth is. I appreciate your trying to understand.

Let the flamers go. An intelligent discussion is the only thing worth reading on these news groups, and they rare enough to be pursued, and the wiffs of smoke are best ignored.
We can stop if you like. When I write in a news group, it is for the one I'm writing, and the many who read.

Yeah, it's cute. Everyone gets a poke in the ribs there, somehow connected to their foibles.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
<Snip>
Random thoughts:
The only really bad languages that I have found are the human languages, as far as programming is concerned.
I still use PIC C from time to time, as well as Assembly on the PIC. I use the BasicX24 in some of my products, as well as Lisp, C++, in addition to FORTH.
Really, as I have stated before, as far as bad programming is concerned, LabView is the pitts. It copmpletely messes with my ability to type in code. If I didn't get so much suff done with it so quickly, I wouldn't use it. LabView projects include image processing, vibration analysis, motion control, engineering calculation. If I had to choose the worst language to teach programming style, it would be LabView. If I had to choose a language to teach programming concepts to programmeing hopefulls, it would be LabView.
I believe that FORTH didn't gain popularity, because it is so difficult to standardize something that is built to expand it's own lexicon. Every time you sit down at a FORTH console, you start build nifty little helper words to do ease things along. The problem is, sooner or later, there will be many people approaching the same tasks, and developing their own little helper words. Then when it comes time to decide to incorporate those helper words, everyone has a different idea how these things should behave. The problem is, it is part of the language to do these things.
In C, you have libraries, but they are just that, a library. They exist on their own, and are specific to a purpose, and in effect a platform in their core implementation. In FORTH, you are instantly changing your vocabulary when you define a new word in the dictionary. If you ever read Sci-Fi, you often come across futuristic lingo that the characters commonly use. You can't very well expect these words to come in to the common vernacular. Yes there are minor exceptions like "beam" as in "beam me up Scotty", but I, as an avid writer, cannot hope to get any words I make up, to be accepted by society, until after I win a Pulitzer Prize ;^) .
The thing is, the core of FORTH, is a low level language, just a hairs bredth away from Assembler. Then you add the specific words to standardize it, and you have a higher level language. When you are done with your task, it is a high level language.
So, lets assume a few things ( this is not meant to be a comparison to any language either actual of fictional, it is an enumeration. ) FORTH is interpreted at the command line( remember line numbered basic ? ) FORTH is compiled in it's execution. FORTH can be a powerful tool ( like a scalpel in the hands of a surgeon. ) FORTH can be a dangerous tool ( like a loaded weapon in the hands of a lower primate. ) FORTH is similar in implementation to Assembly language. FORTH is more human readable than Assembly. FORTH can be written to be very english like. FORTH can be an operating system, and a debugging environment. FORTH sometimes requires a concerted effort to develop in concert with other programmers. FORTH has a track record of high end applications. FORTH has general documentation available. FORTH has a standard. FORTH has free/inexpensive versions available for a wide variety of platforms from embedded microcontrollers to Lego, Palm Pilot, 68hc11, to the PC FORTH is modular in nature. FORTH implementations can be purchased for many thousands of dollars with lots of advanced features. FORTH for embedded systems allow the insertion of low level code into high level language.
See for yourself: Palm Pilot: http://www.quartus.net/products/forth/ $69.95 + free eval http://www.delosoft.com/ $45.00 + free eval
Embedded http://www.newmicros.com $39.00 for 8051 board with FORTH $99.00 for 56805 DSP + many more http://www.rfc1149.net/devel/picforth Free forth for the Pic
Windows http://sourceforge.net/project/showfiles.php?group_idU294 free
Lego http://www.hempeldesigngroup.com/lego/pbForth /
AVR http://www.ram-tech.co.uk/avr.htm http://www.mpeltd.demon.co.uk/irtc.htm
The reason I like NMI' is that for $99.00, I get a dsp chip, with the language on board. Their series of modular boards are brilliant. I have used QUARTUS, WIN32 forth, and LMI FORTH as well, and they are also nifty.
I see nothing wrong here with using this as an embedded language, especially for robotics.
Professionally, I find myself working on projects with 1 to 5 year development cycles. These are often developed serially, since you can't really parallel develop a lot of these things, so when is my turn up at bat, I must be nimble.
Professionally, I must produce product that is robust. Being able to plug into an IsoPod, and evesdrop and orchestrate while things are running, is stuff out of the ICE age (pun intended)
Just my way of earning a living, and having fun. Opinions expressed are not necessarily those of anyone else, your mileage may vary. Intelligent, non demeaning, non libelous responses are welcome.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Lab View, like FORTH, is dangled like a carrot in front of the programming ignoramuses of this world - the hardies. Whereas trivial sales programs can be demonstrated quickly (although I have thought it to be vaguely insulting to the intelligence of any hardy by inviting him to "wire-up" his circuit with a mouse); any program of any complexity very rapidly becomes unmaintainable because of topographical problems. HP's VEE is even worse, because what might be a simple block-structured IF statement in any other language, comprehensible with the merest of brief glances, becomes like the child's puxxle where you have to determine which fisherman has actually caught the fish!

C can be a powerful tool ( like a scalpel in the hands of a surgeon. ) C++ can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Pascal can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Delphi can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Dartmouth Basic can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Visual Basic can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Assembly language can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Machine code (Yup!) can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Fortran can be a powerful tool ( like a scalpel in the hands of a surgeon. ) CORAL can be a powerful tool ( like a scalpel in the hands of a surgeon. ) PL/M can be a powerful tool ( like a scalpel in the hands of a surgeon. ) RTL/2 can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Macro languages can be a powerful tool ( like a scalpel in the hands of a surgeon. ) ALGOL can be a powerful tool ( like a scalpel in the hands of a surgeon. ) COBOL can be a powerful tool ( like a scalpel in the hands of a surgeon. )
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 15 Jul 2003 13:58:40 -0400, Randy M. Dumse wrote:

I wasn't sure if that was standard FORTH or not. I see that I implemented that in my "FORTH" interpreter as I wrote it around 12 or 13 years ago. Incidentally, I dusted it off and it compiled on my Unix box with no warnings or errors and works as expected.

Transfer of variables out usually does not happen in C. Even if some variables are passed in by reference, they are simply C pointers that are passed "by value" and are not treated as special with regard to function calls. I.e., when the function returns, no copying of values occurs - the stack pointer is usually just adjusted to throw away the passed in variables off the stack. If the function returns something, that is usually returned in a CPU register, if possible.

Yep. Normally used for constants, parameterized macros, etc.

It's interpretted - that can generally be an advantage to getting started quickly. "hello world" is the traditional first program in C or in a new toolset, new processor, etc. There's nothing special about the actual program, just that it should be simple, like blink an LED or something. It's purpose is to familiarize oneself with the toolset, by going through the process of creating an image and downloading that to the target system. But that's usually a one-time thing. After you learn to use the tools, you just don't think about it anymore.
I can see it's interactiveness being an advantage while debugging and trying things out, of course. But only a little more so than C, but I guess that would also depend on the efficiency of downloading code to the target environment. With my Atmel AVRs, typical time from making a program change (to add debug code for example) to having it running on the target is around 10 - 30 seconds or so depending on program size. I don't consider that to be terribly constraining.
But perhaps I'll explore this further by writing a FORTH interpretter for my AVR boards. I've already got one that I wrote many years ago, though my tendency would be to rewrite it since I didn't write my original one with a small architecture in mind. Just Googling a bit comes up with several available for the Atmel AVRs, so I'll have to consider whether writing or adapting my own is worth it or not. The nice thing about doing it yourself is you give yourself the freedom to add extensions. For example, I really like multithreading, and would want to include that facility. And I do enjoy implementing languages ... I've almost talked myself into it. Anyway, something for me to consider.
Regarding FORTH, it being highly interactive - do you sometimes find yourself making lots of changes directly on the target platform? Don't you run the risk of losing your work if you happen to zap a board or something before you get a chance to download the changes? I presume most FORTH based systems provide a way to download their contents after one of these sessions. Also, what about locking the code? Sometimes that's a concern if you do an application you might want to make sure someone else can't go in and change the code, or read out your code and make your work available to others without your permission. I'm sure most vendors address these issues in some way.

I try to be careful not to generalize on just a few data points. Projects fall behind for a myriad of reasons. Projects succeed for a myriad of reasons. 99% of the time it comes down to the people. Seems like successful projects follow certain individuals.
I have no idea of any details of the project in question, so it may be the developers skills or their personalities couldn't work well together, or it could be the management, or any host of problems with their development process. You say it is because they use C, yet I am not convinced.
I'd be real hard pressed to finger C as the problem unless the compiler / linker was so buggy that the developers spent most of their time tracking down compiler bugs instead of spending their time actually doing development. If that's the case, they should stay away from that C compiler vendor in the future. But again, not knowing any details, I have to say there is no way I can know. And, in general, I'm not one to blindly accept what someone else says, especially when my internal "suspicious statement alarm" is blaring. I don't have enough data to say what the problem with that project was, but Blueeyedrop did indicate that the problems tended to be more with ICE, compiler options, RAM/ROM/FLASH mappings, etc. This tends to lean in the direction that the developers aren't familiar with the tool environment or the chosen MCU processor, or perhaps the development tools are buggy. Perhaps they are working with a new processor and the tool set is not all that mature and has "issues."
Another possibility: was Blueeyedrop's solution complete? I find that the "core" of most applications is actually very simple and can be implemented in a short amount of time. But turning that into a production application ready to set onto the shelf of your favorite retail outlet is a whole other ball of wax. Perhaps Blueeyedrop wrote the "core", and not the polished app?
Or, it could be that Blueeyedrop is exceptional. One of the commonalities that seems to be recurring is that Blueeyedrop seems the one that can do in hours what most other programmers can't do in weeks or months. Maybe he is just one of those rare individuals that can code circles around most folks, and he just happens to make whatever tool he uses look really good. The fact that he has won Emmy's and has patented several inventions, tends to support that, anyway.
Or, it could be due to a combination of factors. Based on what I've heard, Blueeyedrop is obviously exceptional. And the state of the other toolset used is questionable. This raises doubt in my mind that the crux of the project's problems are because it was being programmed in C.

Nope.
Yes, sorry. Retracted. But that is the mental image I had. I've never seen "C'ers" flail. But I've seen inexperienced programmers flail, in just about any language or development environment they happen to be programming in at the time. That made me think of "clowning," but I shouldn't have implied that you actually said that. My bad.

It sounds to me like decision by committee, not a terribly efficient process. It's not at all surprising to me that 1 exceptional developer can run circles around 3 average. In fact, having the 3 together is a disadvantage! I'll take 1 exceptional any day of the week.

Were they contracted to do the work? After project completion, would they then be required to look for work elsewhere? Perhaps they were actually _motivated_ to drag the work out.
You see? You say it is because of C. I'm not convinced.

It's not? When we choose the words we do we imply certain meaning, even if we don't spell it out explicitly. When Blueeyedrop says that "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", there are lots of implied meanings there. A prominent one is the implication that C programmers can't get useful work done. Thus, that's just as good as Blueeyedrop saying "C programmers can't get useful work done", even though he didn't use those exact words.
With apologies to Blueeyedrop for me repeating that again since he has already recanted it twice. I didn't invent that as a "strawman", it was an implied meaning of the original post to which I responded.
And yet again, I only said that there could be another explanation, because I know for a fact that C programmers can be productive, that has been my experience. And Blueeyedrop did recant the statement.
But you keep saying - no no, it really is the fact that they are using C and not FORTH, even though Blueeyedrop has recanted the original statement, stating other reasons.
Cheers, -Brian
--
Brian Dean, snipped-for-privacy@bdmicro.com
BDMICRO - Maker of the MAVRIC ATmega128 Dev Board
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
There is one problem with writing a FORTH interpreter for AVRs, the lifespan of the FLASH ROM. Form what I can see AVR's can only be reflashed about 1000 times. While that seems like a lot, you could kill your ROM pretty quickly if you're not careful.
There is an AVR FORTH that uses a serial EEPROM to hold the user's dictionary. Sort of like a BASIC STAMP. I can't imagine that it's very fast however.
It's too bad. I think that AVR's architecture would make it pretty easy to write a FORTH kernal and the Mega chips have a healthy amount of SRAM for stacks and variables.
--
chris in napa
>
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Now we are beyond nuances and talking about significant differences. Yes, Forth's interactivity is the key to the programmers productivity.

No, that's fast, particularly compared to the compile assemble EPROM half hour jaunts of the past. Forth really stood out as an almost instantaneous feedback then.
Now the update cycles are fast. But when it comes to a quick question, you still can't touch Forth. If I want to know what is on a parallel port, I just look. If I want to see a string in memory, I just dump it. You get all the advantages of ICE with Forth, and the ability to write one-liner programs to test ideas. Conventional systems still just can't emulate that interactivity.

I mostly work in an editor, and a serial downloader / terminal emulator. If I get carried away with an interactive session, I can go back and capture the buffer, edit out the false steps, and drop that into my developing source code. So no. I have few problems with loosing efforts.

If most think Forth is unreadable at a source code level, taking off the names makes the compiled code about as obscure as you care to imagine. Security by obscurity, for certain. All my Forth's can compile headerless code. It cuts code size by about another half (depending on programmer style).

Unfortunately, there aren't many opportunities to do direct comparisons between the use of two languages. All the data points I have personal knowlege of, came out strongly in Forth's favor, so this previously mentioned situation is not unusual.

The most convincing case for my personal experience base (at least to my thinking) came when I was a consultant to Eagle Signal, who made traffic lights. This was back in '83. Originally, they had a 1MHz 6801 that ran their lights, programmed in Forth by a single programmer. As modules were added, the program grew. Eventually they had to go to a 2MHz 6801. They were concerned because their traffic program was 7K and the total program size with the communications modules was over 32K and rising, and they were having to go faster and faster. They'd either gone to a 2MHz 6809, or were thinking about it.
When I came in as their consultant, I looked at the code and concluded it desparately needed some factoring, because 60 times a second, they were checking everything. They even check to see if it was midnight, Feb 28th, on a on a leap year, every 60th of a second. (Once a day should have been enough!) So I told them how to get their program back in order by doing a real time executive.
They accepted my proposals, and so asked me to head a team to rewrite the program, but do it in C, because they couldn't find Forth programmers. Well, the C version of my "improved" traffic module in Whitesmith C turned out to be 13K, up from 7 in Forth. So, I looked bad. I checked myself by writting my traffic module in Forth on my own time. It came down from the 7K Forth they had to 4.5K, about 1/3 the size of the C program. I wasn't wrong about the methods used being smaller, faster and more efficient.
So, anyway, they eventually turned the project over to someone else, and I left. Last I heard, about a year later, they had expanded the team to something like a dozen programmers, and had to go to a 10MHz 68008, and were over 108K of compiled code and climbing, to get the same traffic light they had when in Forth. And they'd spent more man years doing this behemoth, than they'd spent on the original Forth programmer to write, and then maintaining it, for years to begin with.

I am. I found C object to be 3 to 4x bigger, and needed a much faster, more powerful processor to run on, and took many more man years to get done. Again, actual experience, a1:1 comparison, not hypothetical paraboley.
So I have my personal experience, and many other second hand observations from those in the Forth community I trust to represent situations honestly, who have similar experiences. Now I want to repeat something I said early on; "some Forth programmer knock... out a solution in days, when a team of programmers struggles to do anything near the scope in months. Now, whether you can blame it on the programmer, or on the language, gets less likely when you see the same pattern repeated across many programmers and many situations."
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
What is one "cell", 1 byte? 2? 4? 8? 16?
A lot more than a 3-byte JSR?
Transfer in and out of variables? Isn't this done before and after the "cell", as in, "A B + !C" of Forth,
in contrast to the C = Add(A, B) of HLL?
Seems to be the same overhead!
The setting and clearing of the stack frame (which may be optimised out anyway if compilation is all to registers), is part of the code of the CALLED routine and not part of the overhead of the caller. If you mean the tidying up of the stack, as opposed to the stack frame, this is done in C and is caused by the variable no of parameters that are possible. Not done in Pascal or other HLL.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

A cell is whatever it takes to hold a system address. In 8 and 16-bit Forth's it's usually two bytes. BTW, the 16-bit model of Forth was exceeded about 10 years ago for systems which could take advantage of it. Our 332 Forth and IsoMax are 32-bit.

50% more, for a 3-byte JSR compared to a Forth 2-byte pointer.
If you coded to the point that everything was just a call in assembly language, then it would take 3 bytes. In Forth often coded to the point that everything is just a call, only 2 bytes. The Forth Instruction Pointer (IP) moves through these strings. There's a time penalty for the indirection through the thread, but a space savings.
Further, due to the pyramiding, the more you write in Forth the more compact the additional layers tend to become.
As far as set up and take down of variables, that only happens if you use variables. Then it is similar to C. But many times results of one call remain on stack for next call, so less overhead.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

So, you are saying this is not a language you've ever used, personally...
but you did know some people (you didn't like) who did it badly?
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

So what do you use now?
-- Randy M. Dumse www.newmicros.com Caution: Objects in mirror are more confused than they appear.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I ended up using Visual Basic mostly the last many years. It is quite the mess also but can be easy to do fairly dramatic things.
My favourite is still assembler for full control and speed. Once your libraries are written, control type things are just so easy and natural.
In the end all languages end up with a SOAP. (Stack oriented Arithemetic Processor) This is the only way I know to process any mathematical puzzle and lives the RPN style. I just don't feel us, as higher level beings, should have to logic twiddle to solve easy mathematical puzzles. It's not the way we think (maybe habit?)
Forth kind of fell apart when people wanted to do real world things like strings of text and floating point numbers. When the verb precedes the noun the complier knows what to expect on the programme line but when you throw a string of characters or a floating point number or a boolean statement you make a lot of guesses until the verb is in.
As a control language expecting only integer math inputs Forth is probably one of the most powerful (depending how you define it) languages/complilers going. I believe there was a Forth complier with about a 100 byte kernel once and it could become big and fancy but took a lot to get it there. When I weas playing with less than 1K of memory this was important then.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

More interesting than what you use now, and more pertinent to this thread, might be, what did you use first? Was it BASIC?
Your claim you must be fully insane to make RPN work, is overstated, but it certainly indicates your strong personal bias against RPN. An interesting observation through the years, was certain groups seemed to find Forth more natural than others. For instance, Germans and Chinesse took to it quite easily. Many speculated it was because there spoken language was much less mid-fixed than English.
RPN, for those who don't know, stands for Reverse Polish Notation. It's sort of like saying the nouns first before the verb, so a sentence in English would be "You and I" would be presented "You I and" or in math "2 + 3" as "2 3 +".
Many people who used HP calculators liked Forth, because they had already made their peace with RPN.
Which order language is structured in is just a cultural or "mind set" bias. So someone speaking in an odd notation can sound "insane" to someone only comfortable in the notation he first learned. (i.e. Throw the horse over the fence some hay.)
RPN does work. It has to. It is how the machine itself works. Every compiler has to translate whatever notation into RPN at the machine code level. The issue cannot be if it works or not, because that's how the machine works, but if you feel comfortable working in it. And clearly you've indicated you don't.
I'm not wild about RPN myself, but I've made my peace with it. Ever since I learned its how the machine works, and even if I write in mid fixed C (or BASIC) with left hand and right hand values, the end result will be machine code that identifies two parameters first, then performs an operation on them (quintessentially post fix). I often chuckle at the comment "Forth is the only language I know, that uses a human for a preprocessor" but it is pretty much the truth. Well, I'm okay with it, because I have developed my mind to work with this different notation, and appreciate how Forth is small and powerful, and being closer to "how the machine thinks" is okay with me.
I believe that goes to the OP's concerns, that what he learns first would set his bias for further work. Like my example of trike and bike, if you are biased for mid fix notation, you may have trouble thinking differently when using a post fix notation
-- Randy M. Dumse www.newmicros.com Caution: Objects in mirror are more confused than they appear.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Yes, yes. I very much agree. You make two really good points here. To your later, yes you have written the second example in PN or polish notation, where the verb comes first and the nouns come second. But notice how you have to use precidence markers to make it work out. (You used almost the universal precedence markers the "parens".)
The reason that Forth uses RPN, is no precedence markers are necessary. So Forth is deliberately written in the order the machine needs the parameters feed to it.
In your first point you hit the nail, smack dab on the head. We mostly think of math as written on a two dimensional plane. Specifically, the chalk board we learned to do our fist math on. So when we say 2+3 = 5, we are really thinking of our first exposure to math.
2 +3
--
5

and only settling for 1+1=2 as a linear substitution we learned later.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
[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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.