Re: Speaking of Forth..



I once had my company car publicly removed by one of those. Then the silly girl had to lend me hers to go and fix an Encad plotter up in Newcastle. I spent the whole trip picking my nose and wiping it on the controls. I stopped for lunch on the way back and didn't notice I'd trodden in dog doo.
C'est la vie
Robin G Hewitt
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
You know, I really don't get this FORTH will make you think differently stuff. I've written programs in FORTRAN, PL/1, COBOL (when it was done on cards), BASIC, C, PASCAL, FORTH, about 7 or 8 different CPU assembly languages and I really don't see all THAT much difference.
Basically a computer moves data from here to there. Higher level languages cover up many of the details, which is a good thing when you have a big project. The lower level languages leave more of the details up to the programmer, which is good if you're working with a microcontroller.
Most of the differences I see are stylistic. In PASCAL it's PROC/ENDPROC, in C it's {}. You develope your program the same way, though, declare your variables, write your subroutines, write a main program that calls those routines. It's all about where your data goes and how it gets there.
Different languages handle details differently making them better suited for particular jobs. COBOL handles large records better than FORTRAN did, so buisnesses used it for book keeping. FORTRAN handled math better than COBOL, so that's the language scientist used.
I wrote a FORTH kernal for the PSoC (see previous posts) because I wanted a language I could write on my Palm Pilot. I could have written on in BASIC, I guess, but useful BASIC interpreter is big if it's fast or slow if it's small. FORTH is pretty small for what it does and very fast. It is also pretty uncomplicated to write.
When I write a program in FORTH, however, I do the same thing I would do if I wrote it in C. I decide what the data is and where it will be located. I write subroutines that handle the different tasks I need to be done. Then I write a main program that ties it all together.
I will say that FORTH makes it easier to follow good programming practice. You tend to write your code in small peices that are easy to test and easy to follow. My earlier BASIC programs tended to be spagetti code that took a long time to debug and were impossible to follow if I looked at them after a break. But, I also see the same tendency in writing in C or PASCAL.
chris in napa
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I completely agree. Language is just a means to convey an idea or concept. This holds true for programming languages as well. The nice thing about FORTH, is that it is a language creation language. You build what you need. Where other languages are written to do exactly what you need, and even named after their target audience, ( BASIC, COBOL, LISP, FORTRAN ), FORTH lets you build what you need.
The reason why LabView spoiled me for other languages, is that it's organization is graphical in nature, and has caused my text based programming to atrophy.
As a side note, you had ought to look at IsoMax on the IsoPod. If has it's roots in FORTH, but is moving towards being a language more specific to the hardware capabilities of the IsoPod, thus enabling users to move past the nitty gritty of talking to the hardware. It also has introduced state machine flow control, and multi-tasking.
Mike
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Giovanni Moretti wrote:

Yes, Forth is one of those under recognized languages that is great for embedded control. I worked for Forth, Inc. (founded by the inventor of Forth) back in the 80s. We helped FedEx get their handheld package scanner fielded in Forth in a few man months effort after they had tried unsuccessfully for over a year and a half in C. They became big fans of Forth. It is still used in a lot of place today such as the open firmware in the Sun workstations and recently on the NEAR spacecraft (along with Ada) which made a soft landing on the asteroid Eros even though it wasnt designed to be a lander.
As Leo Brodie (author of Starting Forth and Thinking Forth) once said, You rarely write a serious application in Forth you create an application specific language in Forth and then write the application in it. This is much like what Randy has done with IsoMax you hardly realize that it is Forth but you can create some amazing (and fast) multitasking applications in it using very little memory.
I glad to see there are still some software savvy people around who recognize the power of this language.
Jerry -- ---------------------------------------------------------------------------------
-- Jerry Petrey -- Senior Principal Systems Engineer - Navigation (GPS/INS), Guidance, & Control
-- Raytheon Missile Systems - Member Team Ada & Team Forth -- NOTE: please remove <NOSPAM> in email address to reply ---------------------------------------------------------------------------------
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Jerry Petrey @raytheon.com>" <"jdpetrey<NOSPAM> wrote in message

embedded
in
Forth
year
lot of

recently on

asteroid
"You
specific
like what

can
little
recognize
-------
Control
-------
I heard a rumor that LabView was written in FORTH. Do you know anything about 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. 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. Even better is that every time I do something, it makes the next thing happen even faster.
One of the real joys of Randy's FORTH and IsoMax, is that they are so compact, that they live on the chip, compiler and all. No PC required, just a terminal program.
Mike
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
--
chris in napa

> One of the real joys of Randy's FORTH and IsoMax, is that they are so
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

word -

The whole thing is even neater when you get an advanced Forth Operating system, working with advanced hardware.
Here's your PING program, chris, on the IsoPod(TM).
HEX : PING D D47 ! ( TMRC0 HIGH 0 D4D ! ( ZERO TMRC1 CNTR REG. 5 D47 ! ( TMRC0 LOW 0080 D4F ! ( SET FOR FALLING EDGE CAPTURE 7880 D4E ! ( IP/16 TMRC1 INPUT ; EEWORD
EVERY C350 CYCLES SCHEDULE-RUNS PING
: RANGE D4A @ 127 / . ." in." ;
This short program, PING, operates a Devantech SRF04 utrasonic ranger. It strobes one output, while setting up a timer to measure the time to an falling edge. Simple Forth manipulation of the timer registers, with more comments than program by far. The short form of the same thing without the comments is just a single line.
: PING D D47 ! 0 D4D ! 5 D47 ! 0080 D4F ! 7880 D4E ! ; EEWORD
The EEWORD after the ";" tells the compiler to move the last definition from RAM into Flash (or EEPROM on older systems).
The EVERY line schedules PING to run 100 times a second in an interrupt driven background task. This is the IsoMax(TM) method of making what we call: Virtually Parallel Machine Architecture (VPMA). Other hardware can be managed on the same periodic schedule, and to the foreground, it's all "automatic".
The EVERY line starts PING interactively. With one more line I could have autostarted this word PING, and then it would become a semi-permanent feature of the system, which started up every time you turned your 'Pod on.
The advanced features of the timer allow it to detect the return pulse edge, and capture the time of flight of the pulse in the register at hex $0D4A without further processor intervention.
The RANGE word will give you the distance in inches to whatever the ranger is looking at, any time you want it.
In fact, RANGE is a new part of the language. If you did a WORDS list of the various things the language knew how to do, RANGE would now be at the top of the list, PING just below it, and the other elements of the language following below that.
Have you ever seen a system which required so little source code to add on something as complex as an ultrasonic range finder, but also installs the range finder into the system for repetitive background ranging, and gives you interactive access to the fresh results at any moment you might like to query it, by extending the functions the language itself knows how to do?
Sorry, Forth Rant coming on...
It's this kind of incredible power that makes Forth such an amazing language. The people who don't learn it never have a clue this kind of power exists, and struggle along with their clunky programming languages, ignorant of any such alternative is even possible, let along available in embedded single chip computres for more than 20 years!
So again, back to the original question of the OP, yes, Forth changes the way you think about things. A good exposure of Forth is a cure for artifical dumbness.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Well that's sort of my point. I think FORTH is a great language for microcontrollers. I wrote a routine for the SRF04 for my PSoC in FORTH. I was really surprised how easy it was. The problem is the FORTH program for the PC that will read and use the data from the SRF04 (via the PSoC or STAMP or whatever). The details are maddeningly difficult.
--
chris in napa
"Randy M. Dumse" < snipped-for-privacy@newmicros.com> wrote in message
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, 10 Jul 2003 00:30:05 -0400, Blueeyedpop wrote:

Do you think maybe that might be more a failing of the "programmers" than of the language? Unskilled workers can really make a mess of any tool. I've heard some pretty bad sounds come from a piano at the hands of a novice, but I wouldn't claim that the piano is at fault.
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

Here is an analogy. Relate programming languages to chemestry. some languages are long chains of molecules, some are shorter. Assembly language would be like building with quarks and other elementary particles. FORTH is like building with elements like Hydrogen, Oxygen, etc.
If I want to build something, I might be able to start out with big chains of molecules, or I just build out of the elements I need. No need to try and get big chains of hydrocarbons together to build chrome steel, and no need to assemble quarks, muons, leptons into something useful either.
Well, bizzare analogy, but what do you expect, i have been up since 5:30 a.m., and it's 11:00 p.m. now.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 11 Jul 2003 02:58:55 -0400, Blueeyedpop wrote:

Sure. And don't get me wrong - I'm not knocking forth. I've used it. I've even implemented something similar (in C, oddly enough). I did this while I was a poor C.S. grad student while working for my old physics professor. He had some software called ASYST (or something like that - it was a long time ago, maybe I'm showing my age), which was forth based. I wrote some low level routines for him to control some of his laboratory data aquisition equipment. Basically, they could just call something like 'aquire' with the desired parameters pushed onto the stack and it would do all the initialization and sampling and leave the results on the stack, which they could then feed into FFT routines, plotting routines, etc. No big deal.
I thought this was pretty cool, but there's no way I could afford the $3000 ASYST package (at that time). So I wrote my own forth interpretter which operated similarly.
But still - you have to create your own "libraries" of routines, right? Either that, or use someone elses. That's what I did for my old physics professor. I wrote the low level routines which become the building blocks for more advance programs.
But C is no different. If your coworkers are re-inventing the wheel all the time, they need to learn about the C librarian - an integral part of the C tool kit. If they are not utilizing libraries, either ones they write themselves, or those available from other sources, they are not really utilizing the power of the C language. No C programmer that I know would dream of re-implimenting anything from the standard C library as long as it did what they wanted. But the power of C allows you to do that if you choose to, for whatever reason you may have. Likewise, you can easily construct library routines to do all of your application specific tasks. You tuck these off into a library and never think about them again, you just call them when you need them, and you reuse the library from application to application. The linker is even smart enough to know which ones to include into the image so that you don't waste precious memory space on routines that will never be called.
Again, I'm not knocking forth. It's ok. But let's not unfairly bash other languages. Otherwise, pretty soon we'll debating the virtues of 'vi' vs. 'emacs' :-)
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
Oh, I didn't think you were knocking FORTH. My point was, that all languages which do certain things very well. To me, FORTH is the language of the jack of all trades type, that's all. For instance, When I need to do PC based measurement and computing, I use LabView exclusively. When I need to squeeze the very last drop of performance out of a PIC, I use assembler. When I need to throw something together that moves motors, or grabs analog, or uses R/C servos, I use an IsoPod.
The key is adaptability. I adapt to the needs of the project.
Mike

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

Interesting point, and good question. Certainly to compare two languages you need some sort of standard.
But I've seen what blueeyedpop mentions over and over, some Forth programmer knocking 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.
This could still be the programmers, and not the language though. Perhaps the only programmers who choose to program in Forth are those who can think in radical and non linear ways. Those who prefer the less powerful linear languages will not pick up an advanced tool.
I've often said Forth was like an amplifier, it makes a good programmer really really good, and allowed a bad programmer to make code that was much worse.
Using your musical analogy, I remember starting band, kids who wanted to play something, and showed little talent wound up with the drums. Those who were musically brilliant got more difficult instruments, like the violin, which when mastered gave them much more ability to express themselves.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 11 Jul 2003 10:46:34 -0400, Randy M. Dumse wrote:

Wow. That's a pretty harsh assessment of everyone else.
By "less powerful linear languages", vs non-linear are you referring to support for multiple concurrent threads of control, i.e., time slicing? Is forth inherently parallel by design? I'm not a forth expert, I have only a passing knowledge, but I'm not aware of thread support at the language level.
Personally, I find programming with threads far easier than not for many problem spaces. Especially in robotics, I find that the problems being solved naturally involve many (several) relatively independent threads of control that do their own thing, most of which are event driven, and interact with each other occasionally, perhaps with their operations being reigned in by a supervisor thread of control.
This is easily done in C. Just pick any one of the thread libraries available for your processor of choice, or write one - it's not that hard. Heck, I even provide one that I wrote on my web site. Using threaded and event driven designs is just not a big deal.

Interesting. When someone makes a mess of forth, you blame the programmer. But when someone "flails" in another language (to use Blueeyedrop's term), you blame the language.
Forth is fine. I'm not debating that. But so are C and a host of other languages. Just as Blueeyedrop is obviously skilled in forth, many folks are highly skilled with C. I wouldn't condemn forth because I saw someone write bad code in it.
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

I guess you can read "offense" into that if you wish, but you have to make the assumptions 1) I meant Forth is the only advanced language, which is not contained in my statement, 2) and by affirming the consequent, therefore everyone not using Forth is automatically a bad programmer, which is also not there.
I suggest there is a bias: programmers tend to choose the tools which match their thinking style. Forth might be a powerful tool or choice for those who think intuitively (non linearly) and abstractly (indirection through pyramided definitions). But then, you might expect such a position, when someone speaks of their life's work. I wouldn't have focused on Forth based microcontrollers for 20+ years, unless I saw something special about it over other tools.
Have you heard of Myers-Briggs personality typing? This is a method of identifying personality type by testing for prefered thinking styles. They isolate bipolar preferences on four separate parameters. Inversion/Extroversion, Intuition/Sensation, Thinking/Feeling and Judgment/Perception. If you wish to explore these concepts there are on line tests at several locations: http://www.humanmetrics.com/cgi-win/JTypes2.asp http://www.advisorteam.com/temperament_sorter/register.asp?partid=1
Testing of the general population shows about 1/4 of all people are Intuitives, and 3/4 are what they call Sensing. http://keirsey.com/pumII/ns.html Intuitives thinkers tend to "hop around". Sensing thinkers have trouble following them, and think they're adled, unfocused. Sensing thinkers tend to be linear and very thorough, taking things point by point and step by step, checking for correctness at each point. Intuitive thinkers get bored by them. Neither thinker is good or bad, but just different.
Now I hope you can see my point, that these two styles of thinkers will probably prefer different programming tools. Sensing thinkers will want to approach a problem like a single path, that goes from start to finish. (Hence, my use of the word "linear".) Their programming style is methodical, deliberate and detail oriented. OTOH, Intuitives like to encapsulate concepts into modules, separate, and independent. They like to hook these together in pyramid style.
For example: In reading others code in any given language, you may have noticed, some people use long procedures, a long main, with everything spelled out down the line, with a very shallow calling structure (if any). Another will fragment his code using many separate subroutines and calls all over, until you loose track of what routine does what. You may have already seen this S and the N personality type extremes in program.

No, not at all. Multiple concurrent threads of control is not the concept I am refering to at all.
Extensibility is closer to the point.
In most procedural languages, your code at the beginning looks pretty much like your code at the end. Your working entirely in the language as provided. You might find an assignment statement at the top third of the code that looks identical to another assignment statement at the bottom of the code.
In Forth, you program by extending the language. You create a language that will do the things you want, a fragment at a time. The end of the program is generally written in the "language" of the previous definitions.

have
No Forth is not parallel by design.
I've added that in IsoMax(TM), but that's a different story.

I agree. We are not at odds on this point.

make code that was much worse.

(Side note: Another comment on personality types: your injection of blame into this discussion suggests you are a "J" personality type, one prefering judgement. A "P" personality type, one prefering perceiving or data gathering, would be interested in finding out the details of the differences, and not if one or the other could be assigned blame. http://keirsey.com/pumII/jp.html )
I do not think that is a fair summary, given what I said. I compared two programmers working in the same language, one good (meaning effectual, fast, and efficient), one bad (meaning not always effectual, slow, and inefficient). The suggestion was the divergence of the two programmers output in Forth would be more readily obvious than most other languages.
By musical parallel again, a fair base drum player and a mediocre one are not that much different sounding. If they have any competence at all, one might have to listen quite critically to pick up the subtle differences. A fair violinist, and a mediocre one, sound vastly different, and the comparison is painfully obvious.
With the drum, there are fewer parameters; basically timing and amplitude. With the violinist, there are a myriad of additional control parameters which must be mastered; finger positioning, bow control, pitch, timbre, intonations, etc., etc.
For this, I am not blaming the violinist and the bass drum, nor am I blaming the violin and the drummer.

Agreed.
--
Randy M. Dumse
www.newmicros.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

...
Very interesting discussion. I know that the programming language you happen to use significantly affects the thinking and solution-seeking process.
My very first computer was a wire-wrapped single-card contraption I built using an Intel 8080 microprocessor. Programming was done by means of a hexadecimal keypad and a hexadecimal LED display. In this case, programming required very careful planning and hand-documentation of the program. You had to reduce the physical programming task to data entry. Exploration and creativity was seriously constrained by the tools and, yes, the "language" being used. Here FORTH would have made an incredible productivity/creative-freedom difference ... I just didn't know it existed at the time.
C, of course, is very popular. It is still pretty "raw" in that it does not inherently have advanced constructs and operators that permit a higher level of abstraction to be utilized. For example, matrix manipulation, vectors, etc. Yes, there are libraries, but that's not the point here. You could achieve the same in assembler by purchasing somebody's library and making the appropriate subroutine calls. What I'm talking about is the "out of the box" language defining a completely different thinking space.
LISP is a language that let's you approach things in a different way. When you program using LISP your brain is using a different process to arrive at a solution. For example, you don't need to bother with the mechanics of iterating through a list with "for" or "while" loops, index variables, etc.
C++ ... well, I've had a love-hate relationship with this language. A non-trivial C++ procject requires that you do a tremendous amount of design planning before code line #1 is written. Inheritance and polymorphism are great ... but if you don't get the lower-level classes right you get to have the pleasure of going back and fixing chunks of your inheritance tree. Still, used properly, it can be a bit like FORTH in that you build tools with which to get the work done.
Of all the languages I've been exposed to over the last twenty years I have to say that I still think that APL is, by far, the closest to allowing a shift from the mechanics domain (loops, counter variables, declarations, etc.) to the problem domain. In APL, if you need to transform a 3D coordinate matrix through various transformations ... well, you just do it. Matrix and vector manipulation is just as easy as scalar operations. Let's say you have the XYZ coordinates of the end effector of a robot arm in the base's coordinate reference frame (the table or whatever the robot is mouted to). Now, imagine that you want to transform these coordinates to the refence frame of the robot's wrist. This is some pretty basic linear algebra. Nothing to write home about. And, if you know it, there shouldn't be much to think about either. In APL, you could accomplish this in a single line of code. From problem to solution without getting lost in mechanics. That most certainly changes the way you think and, unless exposed to it you will, more than likely, never think that way --at least not consciously.
To add to the musical analogy. When you start to learn to play classical guitar you will probably do so on a cheap $99 plywood production guitar. Nothing wrong with that. You can certainly learn a lot with it. As you progress you find that a plateau is reached and your skills don't seem to improve. What's happening is that the instrument is not allowing you to see what can be achieved. The next step is a $300 to $500 guitar. Big difference. Now you can start to feel and explore things you never would have with the cheap guitar. And then, of course, come the real guitars, anywhere from $3,000 and up ($30,000 is not unheard of for concert guitars). What these instruments can do is not easy to describe. What is clear though, is that your thinking changes and with that your skill. This isn't a perfect analogy, but it illustrates a basic point of a lot of human activities: as the tools improve, your skills, understanding and thinking are enhanced. Take the guitar story and apply it to car racing, sailing, flying, diving, painting, building homes, etc. Or take fabricating furniture with hand tools as opposed to CNC equipment. It's the same story. Why should programming be any different?
I happen to think that we need substantially better tools. The fact that we still carve out programs using ASCII (or textual) entry is ming blowing. Does anyone truly believe that the future of artificially intelligent machines will be created by a bunch of guys slaving away writing ASCII source code and doing such things as declaring variables for a "do" loop or specifying "include" statements? The tools used in that thinking/execution need to graduate up and out of the dark ages into symbolic/graphical languages that will allow a significantly different level of reasoning to be applied to increasingly complex problems.
To be sure, FORTH isn't the answer either, but it is one of those languages that tries to say "hey, what if we don't do things THAT way?".
Personally, BTW, I refuse to use non-RPN calculators. To the point that my wife has had to learn to use my HP calculators, because that's all we have at home.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

My bad...
The problem I see constanty, is fighting with ICE, compiler configuration, RAM/ROM/FLASH mapping. I suppose these would happen in any language. I am just never exposed to them when I use NMI's boards. I attributed this to language, rather than environment.
Mike
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
As an amateur, do whatever makes you feel rewarded, and FORTH is ideal for that. Just don't bring your FORTH toy into the business world - we don't have time to sort out toys!
That's where FORTH has its business market - with people who are trying to do a professional programmer's job, but who are not up to it, and can't be bothered to get trained properly.
FORTH is an assembly language for a two-stack machine. If you want high speed - program in assembler. If you want a high level language, use one of the many variants of C where modern compiler optimisations will produce machine code that you'll be hard pressed to beat in the same timescale. Don't produce programs in what is essentially an interpreter for a fictitious assembly language!

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

That's pretty much my own point of view.
I see here people trying to prove how FORTH (or even LISP!) is wonderful, but I fail to see it used in any "serious" professional work.
Another important point is: any routine in FORTH is practically unreadable. If you want high readability / reusability, just use a high-level language like C. I'm not an expert in FORTH, but I fail to see how you can work without structured types of data and still think it's better than assembly language.
As to LISP, for whatever you gain in terms of "shortcuts" (functional approach, no direct iterative loops, etc), you lose a lot, because basically, anything written in LISP becomes totally obscure a couple days after you wrote it (not to mention it's painfully slow to execute).
Both are essentially interpreted languages, and again I'm not convinced of the practical use of interpreted languages in an embedded environment. Besides, they both are essentially stack-based, which makes them difficult to use when the resources are scarce. You have to constantly monitor the stack depth, which can be a real pain on any decent project.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Your posts had me drop my jaw with amazement. You probably couldn't be farther off than the opinions you've expressed. An observation. Not criticism. Everyone is entitled to their own beliefs and --within your own context-- they are perfectly valid.

Characterizing FORTH (or any other language or tool) as a "toy" is tantamout to not having a realistic view of business and, perhaps, what "professional" means. There are many, many factors that lead to decisions when developing a product. With the project's parameters well-defined the range of choices is constricted and, ultimately, one hopes to make the right one. FORTH has it's place, still today, in industry, science and enterprise. It is a powerful tool if chosen for the right project. It is far from being an amateur "toy", in fact, you will probably find that there are less "amateur" FORTH programmers than there are C or Basic hacks.
I personally know of several professional/industrial products that are written entirely in FORTH and have been supported, maintained and evolved over a period of fifteen years with great success. We are not talking about toys here, I'm talking about $30,000 to $600,000 pieces of equipment. Is that professional enough? Further to that, the fellow that started one of the companies later sold the product to a third party for many, many millions of dollars. He will tell you that he couldn't have done it without FORTH due to the productivity gains it provides a small team when compared to alternatives.
The same sort of thing applies to APL. Here's a language that most "professionals" don't know even exists, yet, chances are, that your credit card statements, insurance policy data, stock investments and other financial transactions are being processed using massive APL applications. The financial and banking communities are still some of the largest users of this language. Yet, what do "professionals" know about it? Nothing. I wouldn't have been exposed to it myself if, well over twenty years ago, a Physics professor of mine hadn't lobbied the whole class to take his APL class instead of FORTRAN 77. He had made a deal with the CS department to provide equal credit. Most of us went for it. I'm glad I did.

That's rather elitist and way wrong my friend. I don't know where you are coming from intellectually, but I guarantee you that you are dead wrong in thinking this way. There have been FORTH systems built into spacecraft for heaven's sake. What? Are you going to call those people amateurs? Nonsense. Respectfully. Nonsense.

Nope.
Not necessary. You can achieve wonderful results using C. Assembler, in most cases, should be the last resort.

That could be true. Although the term "high-level" is, in my opinion, misused when speaking of second-generation languages.

You simply know nothing about FORTH.

I guess you also don't know much about what's out there either. Let's see, since inception AutoCAD --proabably the most extensively used CAD system in the world-- has used a version of LISP (called AutoLISP) at the embedded programming language for customization, extension and enhancement. I started with AutoCAD version 1.2 back in the early eighties (on an 8006/87 CPM system!). Since then I've ammased quite a collection of AutoLISP code that makes AutoCAD a very powerful tool in the context of my work. But, I'm nobody. Perhaps the largest single application space for AutoCAD is architectural. There are millions upon millions of lines of AutoLISP code in thousands of COMMERCIAL applications available to artchitects (and others) using AutoCAD. All of this is written in AutoLISP (or VisualLISP), supported, maintained and commercialized professionally.
You are way off base. Way off.

Mathematics is unreadable to someone who doesn't take the time to study the subject. So, what's your point?

Well, you see, from your C perch you seem to have forgotten that your structured data types are nothing more than a sequence of bytes (or words) in linear memory space that, by convention or design, is accessed and used in a certain way. What's the difference between a vector, matrix and tensor (> 2 dimensions)? In memory, practically none. In usage, loads. In FORTH you can have all the structured data types you want. In fact, you could implement things like nested arrays (a tree-type structure with each branch/element being anything from a singleton to an n-dimensional array). Nothing prevents you from doing that. The tools are right there for you to use.

Hmmm, don't want to bother to learn? How can something written by a skilled person become "totally obscure" in a couple of days? If you are just a hack, maybe. But, if you know the language, never. I have extensive FORTH and AutoLISP that I have been using and maintaining for nearly twenty years. I have shared this code with others as well. The secret is, like with any other language, comments and documentation. C or C++ can be just as much of a pain in the butt to decipher (for a non-trivial project) if not properly documented. That applies to any language.

Listen, please refrain from voicing strong opinions witout knowing the subject. It doesn't make you look very smart. Do you know how FORTH works? Do you know what a threaded interpretive language (TIL) is about? Do you know about compilation time and execution time differences and the tokenizing process? To be sure, there's overhead associated with thread navigation, and this is a performance hit that must not be ignored. Some microprocessor architectures are better hosts for TIL's, of course.
To get back into business considerations. The factors are time-to market and cost. If an interpreted language (say, Basic) allows a developer to get a product --say, a sprinkler controller-- out quickly and at a reaonable cost (say cheaper tool, inexpensive Basic-equipped chips, etc.) then the language is perfectly applicable and appropriate for that embedded system, assuming functional/performance targets are met.
Twenty years ago I had some of the same strong opinons you are voicing here. I was, in retrospect, myopic, one-track-minded in thinking. After so many years of real-life and being involved in various business ventures you realize that after all the smoke and bullshit clears out the only thing that matters is to deliver a product faster, cheaper and better than the other guy. Period. You win the race by showing-up first. You use whatever tools or means you have available to get there. Who cares how you do it? Well, the programmer that can't bother to see outside the cubicle will proabably fight stupid battles for things that are ultimately driven either by emotional attachement or the lack of desire to be open to possibilities. In general, I've found that some of these engineers/programmers can't be bothered to understand their position in the food chain. No, this isn't a negative connotation, to the contrary. For the end-user/client/customer to consume the work product of an enterprise the teamm players must all understand just how important their role in this food-chain is (in taking raw materials to produce a "consumable" product). To not be open to consider the merit of alternative tools or ways of doing things does not do the enterprise any good, in fact, it could dangerously hinder the ability to produce something that end-users can consume. If, for example, I was a programmer in a team who absolutely insisted on using FORTH for an image processing project instead of C++ I would be acting in a myopic, selfish or egocentric emotionl basis as opposed to having the team's/mission's best interest at heart. Don't get so stuck on what you think is best. There is no "best". All you have are choices.

Not so. For your own edification, you might want to learn a bit about the language.
Again, a prerequisite here is to choose the right tool for the job. All of my image processing tools are written in C++. Here classes, inheritance and polymorphism provide levels of abstraction (and, ultimately, power) that would be painfully difficult to achieve with FORTH (and most other languages, for that matter). So, C++ is the right choice for me and for that application class.
I've also written a ton of tools an utilities in Visual Basic. I've acually written a nice little simulation of an SDRAM controller in Visual Basic instead of using Verilog because I felt I needed a level of graphical display I couldn't easiley get with Verilog. I later implemented that controller in a Xilinx FPGA in Verilog by using the Visual Basic state machine as my guide. Tools for the job. That's all. It would be a lot more painful a process to do this with C++ due to the structural work you have to do in order to arrive at an adequate class architecture. FORTH and Assembler, for me, are my preferred tools for embedded work. C is available as well, of course.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
  Click to see the full signature.
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.