VOTE!!! Forth or no Forth, that is the question...
mklrobo
Posts: 420
Thanks for your vote!
Would you use forth, or not?
If so, which version would you use, and why?
if not, why?
I will need you help in navigating my use of Forth.
I appreciate everyone's input!
Would you use forth, or not?
If so, which version would you use, and why?
if not, why?
I will need you help in navigating my use of Forth.
I appreciate everyone's input!
Comments
Overall I think Forth's interactivity has appeal, but I still prefer C. Sorry Forth guys.
Sorry... C guys.
Cluso,
Yes, and you'll be more busy if you adopt a primitive unhelpful language.
Loopy,
You'd be less busy if you adopted a more sophisticate helpful language.
No need to be sorry, why would the C, or other language users, be worried about how you waste your life?
If I need the things that Forth offers (to me), interactivity, rapid prototyping, some strange internal satisfaction, then I would use Forth.
If I found some really cool Spin objects that did what I needed, then I would use Spin.
Likewise if I found really cool C code, I would use C.
If the Propeller isn't the right processor then you pick something else and adopt/adapt to its language offerings.
Personally, if I just want to play around or feel like investigating things, I use Forth (it's a genetic defect and I've learned not to fight it)
If I have a box of nails and want to put some pieces of wood together, I will use a hammer. If I have the screws and want a stronger joint, then it is screwdriver time.
If I just wanted to put things into wood, then a hammer and nails will be more enjoyable in the long run than a box of screws and a screwdriver (hammering is much easier on the wrists than twisting a screwdriver)...but I do have this really neat screw gun that I use on flooring that is just a blast to use!
Different horses for different courses......the right tool for the job and all that stuff!
Life is too short to just sit in one box because years ago someone sat you in that box or told you it was the right box to be sitting in.
The world is too diverse and full of wonder to not explore and learn!
I wrote much on that "right tool for the job" theme in the other thread where mklrobo brought it up.
It's a good excuse for a quick language riot though:) So this time I though I'd just go for the grenades.
C, Spin, and Forth are Smile! You should all program in SNOBOL!
The polls so far, seem to indicate the Forth is good for dedicated applications, because those special apps have libraries that are in the projects
best interest.
steppers and motors - PropForth
stand alone systems for terminal, game, etc purposes. - Tachyon Forth.
Loopy and Cluso99, which Forth do you use? Thanks.
all the different dialects. You just can not fit every library you want, into the prop, at one time, to do a decent job.
If this is so, then, if the programmer is programming a multilevel application, he will need different forths for each
app, then linked together as one. This would suggest that all Forths have a comm link library, then the specialized
library for the specific function. Could have a standalone forth, a robotic forth, etc, but all in the same family to
function in a mosaic, controlled by a heirarchey, if necessary. Comments?
I like pfth because it is essentially standard forth with a few necessary propeller commands, and Dave has done a nice job of making it understandable. I've used it interactively to learn how to work with cogs and pins and counters and to interface serial devices to the prop. And it is just so easy to write a library of functions without a lot of overhead and extra steps. Everything I've done in forth I could have done (not interactively) in Spin or C, but I'm still trying to get up to speed with Spin (so many ways to do the same thing), and using C requires the use of libraries that are somewhat cryptic (as to what/how they are doing), although I was recently shown where the more basic propC functions can be found.
The limiting feature with pfth is its speed. For example, interfacing with the Pixy color tracking camera, pfth was just too slow, and I was told that Spin would also be limiting. So I'm working more with C, which for that application is very very much faster, but I still have my issues remembering braces and semicolons (much less when/how to use * and & variables).
I'd like to learn tachyon because of its speed, but it is different enough from standard forth to be jarring, and I'm not having an easy time picking it up -- probably have to dedicate some time to concentrate on it until it becomes more familiar. I'd like to work with propforth also, but it also has the non-standard forth issues. With both versions, I don't mean the propeller features, which of course are not in the standard, but changes to the forth language - simplest example, differentiating upper and lower case.
tom
Why can't we have object oriented Forth?
I mean just to make Forth even more hideous, as if that were possible, we could have the Smile backwards syntax of Forth plus the total unmanageability of multiple inheritance and the unmaintainability of the ridged class hierarchy from C++!
Then we could write code like this:
par1 par2 par3 \ Leave some parameters lying around on the stack. \ Hope we can find them later! class1 \ Push a class on the stack class2 \ Push another class on the stack extend \ Combine the 2 parent classes into a child \ (multiple inheritance) new \ Replace the child class on the stack \ with a new instance of it method1 \ Call a method on the new instance \ using those parameters we hope are in the \ right place now!I will leave it to the reader to suggest a nice syntax for the class definitions.
Ok, that caught my eye.. Tachyon just got moved up my list a bit.
I theory here is that the win is spending less time talking/chatting/arguing about which language to use and try them all!
My list is still so long that I'll never get it completed before P2 arrives.
Awesome!!! SNOBOL fight in August!!!!!
Hmmm......I wonder how much Prolog you could fit into a Prop????
Except I seem to have spent a ridiculous amount of time learning different languages. Turned out to be mostly an unproductive waste of time. For a long time it seemed that every project I joined required learning a new language. Coral, Ada, PL/M, C, C++, JavaScript, a bunch of assemblers and even some lisp and Java at some points in the dim and distant past. Not to mention that whilst studying there was BASIC, Algol and Fortran.
Of course to get productive in any language requires you be familiar with not just the language but also the morass of libraries that can come with it. Often a much bigger task.
It's probably a good idea not to bother trying to learn more than a few languages and specialize in one. Make them as different as possible so as to get new ideas rather that just learn new syntax for what is basically conceptually the same.
Might I suggest:
1) Some assembly language or other just so you get a feel for how CPUs work.
2) Forth so that you might be happy about the other languages you are going to meet below, nothing gets worse than this.
3) C for it's basic, common or garden structured programming approach.
4) C++ for it's object orientedness
5) Lisp or Scheme for that funky list processing approach.
6) Standard ML so you can understand the insanity of those functional programming geeks.
7) JavaScript for it's prototypical nature. Nirvana at last. So easy.
http://www.muppetlabs.com/~breadbox/bf/
David, Oh my God. And I thought I was joking....
How did you do those class definitions?
I have used PropForth and pfth. In fact, I have done quite a bit with pfth helping a fellow with a kinetic sculpture that needed rather precise lookup tables for stepper motors. He got what he wanted and found that the interactive quality extremely useful in verifying what was going on with quite a few hall effect sensors. The project deployed multiple cogs that started and stopped at different times.
I suppose all this could be done in C, but it wasn't.
Pfth was very helpful in allowing me to learn more about PASM and Propeller architecture. I generally feel that C might do more to insulate the user from both those factors.
C certainly seems more useful in terms of larger programs and aspects such as floating point maths and large data schemes.
I just feel that Forth, PASM, and C make one more well-rounded.
You really need to do more research before you make such generalizations about ALL the languages and their strengths and weaknesses.
I've used all 3 and I won't make generalizations as to which is better for what beyond this (in my experience):
1) PropForth has the best multi-propeller support built in. It is fun to fire up multiple Propellers and hop from COG to COG relatively transparently. It's the oldest and really does have an large collection of add-ons packaged with it. It is slower. The Forth code that makes up the system is well documented and easy to read (if you can read Forth) and you can learn a lot about the implementation from reading through the code.
2) Tachyon is wicked fast and has some great hardware support and some really nice features that need to be explored more. Peter has been cranking out some wonderful examples and new features. It's becoming my "go to" play Forth. The Forth code that makes up the system is well documented and you can really a lot about programming effective, functional Forth from reading through the sources.
3) pfth - is the most "standard", has very well documented and easy to read PASM source code and was ported to the P2 so it has some advantages for experimentation and play. It is implemented as a classic Forth and reading through its PASM and Forth sources are a great learning experience.
I'm not a professional and do this for love, not money so my outlook is dramatically skewed from most who need to put food on the table!
(Apparently, I need to read less code and write more code!
Gforth has it (in 3 flavors, of course)
A good test for pfth ANS compatability - Object pfth!!
Let me fix that for you Heater: "Probably best to rest up and go to bed with some nice hot Java(script)."
C.W.