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.
Since this thread has turned into a frat party I will just ask whether you have any real information yet? As you can see everyone here is VERY helpful, some help themselves more than others
BTW, have a look at the Forths yourself and ignore the descriptions as they don't seem very accurate. For example I have a lot of stepper and PWM motor control software written with project pages for Tachyon Forth which I developed because I originally used PropForth to try to do this with, so the Youtube videos I did refer to Propforth rather than the final product. However Tachyon Forth is not a demonstrator, it is a realtime embedded Forth that I use in my paying commercial applications and I share some of those projects in my links page (at the end of the intro page).
Yes, because I find it helps me work interactively and at a low level without having to learn/use PASM (something I intend to do.)
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
I think you will find that the fast SPI opcodes of Tachyon will make it a breeze to communicate with the Pixy. Remember that speed test where Spin and Propforth were way too slow to update 264 RGB LEDs over SPI? Tachyon updated all these in 2.66ms without a trace of assembler.
Anyway the reason I was really responding was the disbelief that upper/lower case are mentioned as "factors" in grasping the language. I'm used to Linux and it is case sensitive although I prefer to put my action words and opcodes in capitals to differentiate between variables, constants for instance. Makes it so much easier to read knowing that a word just by seeing it's lower case is just leaving a value for instance. I'm familiar with many languages and Forths but forgive me if I ask what is so "jarring" about Tachyon? I mean the Propeller itself is jarring, but in a good way (once you get to know it).
(I don't try to hide the Propeller in the language, I make the language suit it).
:cool: It appears that people have used any forth for any number of any applications. If there was
a singular intent of the authors, it was not followed. One possible solution is to have a base forth, then
provide downloadable libraries to constuct your own propeller project. Instead of a Forth that
is concentrated on motors/ steppers, and constricted to that purpose, the programmer could
add the libraries that was desired. The only constriction is the memory used. A base language
of that particular forth could be used, and libraries installed on the propeller. The "tweeking"
out of the installation would be the burden of the programmer. Comments?
:cool: It appears that people have used any forth for any number of any applications. If there was
a singular intent of the authors, it was not followed. One possible solution is to have a base forth, then
provide downloadable libraries to constuct your own propeller project. Instead of a Forth that
is concentrated on motors/ steppers, and constricted to that purpose, the programmer could
add the libraries that was desired. The only constriction is the memory used. A base language
of that particular forth could be used, and libraries installed on the propeller. The "tweeking"
out of the installation would be the burden of the programmer. Comments?
I think you are talking through your hat, the authors know their single intent and I know I have followed through. There is no Forth that is concentrated on motors/steppers or constricted in those respects for instance, that's sheer bunkum to make such a statement. As I mentioned in another post you are probably better off trying out these Forths yourself, I mean there they are, freely available, and only you yourself can be the final judge of which is better for your task or not at all. After trying them out in your application you could then provide some actual and useful feedback which may then be considered.
:cool: It appears that people have used any forth for any number of any applications. If there was
a singular intent of the authors, it was not followed. One possible solution is to have a base forth, then
provide downloadable libraries to constuct your own propeller project. Instead of a Forth that
is concentrated on motors/ steppers, and constricted to that purpose, the programmer could
add the libraries that was desired. The only constriction is the memory used. A base language
of that particular forth could be used, and libraries installed on the propeller. The "tweeking"
out of the installation would be the burden of the programmer. Comments?
You really need to understand Forth and the ideas behind building a Forth application. Read "Starting Forth" and "Thinking Forth" both by Leo Brodie and available on the web and also actually sit down with one or more Forths and play. Read through Peter's great introduction and play with Tachyon and then come back and we can talk. Until then, your generalizations and strict categorizations about Forth are meaningless and misleading to others that don't know anything about Forth.
Your proposal of a Mil-spec Forth is ludicrous if you don't understand the language and how it is used to develop INTO an application.
I think you will find that the fast SPI opcodes of Tachyon will make it a breeze to communicate with the Pixy. Remember that speed test where Spin and Propforth were way too slow to update 264 RGB LEDs over SPI? Tachyon updated all these in 2.66ms without a trace of assembler.
Anyway the reason I was really responding was the disbelief that upper/lower case are mentioned as "factors" in grasping the language. I'm used to Linux and it is case sensitive although I prefer to put my action words and opcodes in capitals to differentiate between variables, constants for instance. Makes it so much easier to read knowing that a word just by seeing it's lower case is just leaving a value for instance. I'm familiar with many languages and Forths but forgive me if I ask what is so "jarring" about Tachyon? I mean the Propeller itself is jarring, but in a good way (once you get to know it).
(I don't try to hide the Propeller in the language, I make the language suit it).
The upper-lower case example was used because it is the most obvious. As I said I find it jarring because I'm not used to reading forth that way. Also the words you've defined for using the prop are different than the one's I've used with pfth, which are similar to those I've used in other forth programming I've done. One of the things I like about forth is that it allows (encourages) different styles and ways of doing things. However, a different style can be jarring. I tend to be verbose in my forth, Tachyon is concise. I believe with some initial effort and taking time to work through the more complex examples, I'll become more comfortable with it. I've been reading the Tachyon thread (I'm about 2/3rds through it, and have run most of the examples in your intro. I had read the thread you mentioned and 2.66ms is the reason I feel it's worth the effort.
I expect to be posting questions in the Tachyon thread.
Frankly, I find people that desire to use just one language rather naive.
I prefer to take the position that I use Forth when I want a language that is interpreted and I use PASM, C, or Spin when I want a language that is compiled.
Much depends on the kind of project or problem I am exploring.
I have used PropForth, Pfth, and Tachyon.... So far, I feel most comfortable with Pfth.
I wouldn't not exactly say PropForth is well-documented. It is more likely that I say 'Well.... it is documented.' One can bury themselves in a documentation project. PropForth taught me that I needed to read the source code to get all the answers. And so I switched to pfth where I actually understood the source code.
eForth is an interesting deployment of Forth and reading its documentation in comparision to Pfth is very helpful. One really begins to learn what an 'inner interpreter', an 'outer interpreter', and the 'stacks' do. It gets easier once you have some idea of what makes it work and how the dictionary is managed.
My preference has not been for ultimate performance so much as a Forth that could be studied with an eye toward learning how to make my own. Pfth remains the best for that. Tachyon is likely the high flyer. PropForth is a bit too ambitious.
So abstaining doesn't count? So far less than a dozen people care enough to even offer an opinion. That tells me a lot.
Just for the record: "Forth is a waste of time." There are plenty of good languages to learn. I've written programs in at least 17 scripted, interpreted, compiled, AND BACKWARDS languages.
Why do YOU think Forth would be a good choice as the target/primary language for your Mil-Spec distribution?
What experiences do you have with Forth in general or Forth on a Propeller that makes it THE choice for a development language?
:frown: I am starting to get a headache, just thinking about Forth.(like Heater)
I am trying to acertain whether to invest time in writing a Forth adaptation. I do need a primary language, for the infrastructure
that I have in mind.(its a secret, don't tell anyone).:thumb:
After reviewing this thread, I have developed questions from their perspective.
I have to consider the real-world results; Peter J. has implemented Tachyon Forth, and retained a profitable investment. That can not be ignored, so
in that case, Forth has merit, in relation to the propeller.(examples in this forum.) It seems that alot of people like his work, as demonstrated in his thread.
So delve deeper, into the architeture;
The propeller has 8 "cogs" which are seperate processors, with a video generator. The I/O pins can be accessed by any cog, which could cause control
problems. It would seem intuitive to divide the processors into work groups.( Half processing and comm; the other dedicated to real world I/O.)
I will have to analyze the original objectives of forth, Vs. the architecture of the propeller to acquire a clear scope. Example; Forth sides with Hewlett Packard
in the Reverse Polish Notation processing of math; Is this in the best interests of the propellers memory/architecture? Are demands of the Forth's directives
in the best interest of the propeller, to add strength to the processing, and take headaches away from the programmer?
To answer the second question, No, I am no where near an oasis of expertise in the Forth language, like Peter J. That is why I have asked people in the forum, who are
more skilled than I.We all depend on each others' insight, and no one is an island.
Thanks again, I appreciate your insight.
Heater has some good suggestions;
1> do not waste time learning too many languages
2> a few languages, focus on syntax that is conceptually the same.
Heater suggested Forth++ in sarcasim, but David Betz had made an object oriented Forth, called DEC PDP-10 in approx 1978.
Mindbots suggested Gforth, an open source Forth associated with the GNU project.
I appreciate the guidance.
I'm not sure if you counted me as a "yes" vote but I would not use Forth on a system that has an ARM processor and runs Linux. I would use PropGCC or maybe Spin.
I am trying to acertain whether to invest time in writing a Forth adaptation. I do need a primary language, for the infrastructure that I have in mind.
This is nuts. If you have an application in mind just get on an write it. You could probably of had a prototype up and running in the time it has taken you to um and ah about how to create a custom Linux OS to distribute in on or which Forth dialect you want to butcher to write it in.
With a bit of experience you will already have a feeling for such things as "Is Forth or Spin or BASIC going to be too slow or do I need a compiled language like C or even assembler?"
Without that experience you will just do it anyway and when it proves to slow or otherwise unworkable you will either give up or find a better solution.
The last thing the world needs is YAFFD. "Yet Another F*****g Forth Dialect". I find it very hard to believe that the magic "infrastructure" you want to build actually requires a whole new language to implement it.
...its a secret, don't tell anyone...
And there in lies the problem. Nobody knows what it is you actually want to accomplish. So it is impossible to advise.
I would not use Forth if it was the only language available to program the last remaining collection of logic devices cobbled together into a computer after the end of the nuclear devastation of the third world war.
This is nuts. If you have an application in mind just get on an write it. You could probably of had a prototype up and running in the time it has taken you to um and ah about how to create a custom Linux OS to distribute in on or which Forth dialect you want to butcher to write it in.
With a bit of experience you will already have a feeling for such things as "Is Forth or Spin or BASIC going to be too slow or do I need a compiled language like C or even assembler?"
Without that experience you will just do it anyway and when it proves to slow or otherwise unworkable you will either give up or find a better solution.
The last thing the world needs is YAFFD. "Yet Another F*****g Forth Dialect". I find it very hard to believe that the magic "infrastructure" you want to build actually requires a whole new language to implement it.
And there in lies the problem. Nobody knows what it is you actually want to accomplish. So it is impossible to advise.
Actually I'm pretty much sick and tired of the constant bad mouthed Forth bashing that goes on, and on threads that are specifically Forth, this even turns me off the esoteric and quirky Propeller chip too. You lot must be really really insecure. For once and for all put your money where your big bad mouth is and show us all how we can run with the fantabulous magic dare-not-challenge C, what I'm running now in Tachyon Forth with my SD filesystem and network servers etc on a plain old Prop with room left over for a sizable app too.????????? (So benchmark demos don't cut it)
I would not use Forth if it was the only language available to program the last remaining collection of logic devices cobbled together into a computer after the end of the nuclear devastation of the third world war.
Yeah, we'll just have to hope that enough working logic devices are left to run Lisp.
Actually I'm pretty much sick and tired of the constant bad mouthed Forth bashing that goes on, and on threads that are specifically Forth, this even turns me off the esoteric and quirky Propeller chip too. You lot must be really really insecure. For once and for all put your money where your big bad mouth is and show us all how we can run with the fantabulous magic dare-not-challenge C, what I'm running now in Tachyon Forth with my SD filesystem and network servers etc on a plain old Prop with room left over for a sizable app too.????????? (So benchmark demos don't cut it)
You can't. That's why I said that if I had to run on such a limited platform I might well consider Forth. However, the OP was asking about a system that runs Linux on an ARM and, while it is very possible to run Forth on such a system, I don't think I'd choose to. I'd prefer to run a higher level language. That's just my opinion of course. I wasn't saying Forth was bad. I just ordered Elizabeth Rather's book on Forth to help me learn how to program Tachyon. I just said that I wouldn't be likely to choose it if I had the hardware resources for a higher level language.
I will not be voting and if elected I will not serve.<g>
I am studying on whether the C language taken in college or the UNIX I learned enough to be dangerous with while working an assignment will be the best choice to go with the latest Intel chip.
I would not use Forth if it was the only language available to program the last remaining collection of logic devices cobbled together into a computer after the end of the nuclear devastation of the third world war.
Yep, it's a fair cop, pre-meditated Forth bashing, guilty as charged.
I cannot speak for the other Forth bashers present but in my defence I offer this:
1) None of this is meant so serioulsy. People rib each other all the time about language choices, editor choices, OS choices, code formatting styles and so on and so on. I like to think of it as a bit of light hearted bun fighting as I said earlier. A play ground "bundle" as we used to say back in school.
2) I do not bash Forth on Forth threads. Or at least I don't think I have done so for a long, long time. I respect that Forth people have Forth things to discuss, like any other thread, and don't need the pointless interruptions of a gate crasher.
3) This is not a Forth thread. We were invited here to discuss "Forth or no Forth" to quote the threads title. I just happen to be on the "no Forth" side of the discussion.
4) I do not understand what the "esoteric and quirky" nature of the Propeller has to do with a programming language debate.
5) I do not understand what my insecurity or otherwise has to do with a programming language debate.
6)
For once and for all put your money where your big bad mouth is and show us all how we can run with the fantabulous magic dare-not-challenge C, what I'm running now in Tachyon Forth with my SD filesystem and network servers etc on a plain old Prop with room left over for a sizable app too.????????? (So benchmark demos don't cut it)
Conversely can you show us how to write a Fast Fourier Transform for the Propeller in Forth?
No this is not just a bench mark, it has been used in a number of real apps.
7) I should have done what I thought about doing when this thread opened, deleted my original reply to mklrobo where he originally brought all this up and pasted it here. In that post I actually have a lot positive to say about Forth.
Edit:
8 ) Peter, I just noticed that in that quote of me you included whilst reprimanding me for Forth bashing I did not actually have any Forth bashing.
I'm not sure if I was counted as a yes or no vote. I will say that I've never bashed Forth, and even started the CS-101 Forth thread. It's an interesting language and I can see the appeal.
Now here's a thought. Lisp has been described as the ultimate high level language, while Forth has been described as the ultimate low level one. So can you write a Lisp interpreter in Forth? That would be mind bending.
I'm not sure if I was counted as a yes or no vote. I will say that I've never bashed Forth, and even started the CS-101 Forth thread. It's an interesting language and I can see the appeal.
Now here's a thought. Lisp has been described as the ultimate high level language, while Forth has been described as the ultimate low level one. So can you write a Lisp interpreter in Forth? That would be mind bending.
I'm sure that would be possible but it would require finding someone who liked both Forth and Lisp. That might be a trick. :-)
, what I'm running now in Tachyon Forth with my SD filesystem and network servers etc on a plain old Prop with room left over for a sizable app too.????????? (So benchmark demos don't cut it)
Very interesting.
One of the "strengths" of forth is Reverse Polish Notation, which adds numbers in a weird way, but more efficent. Even HP calc enthusiasts do
not like this. This may cause havoc at the processing level, stressing out most programmers. I would guess that Peter J. has adapted this technique, and probably others,
to process data(video, comm, etc) in an efficent way. That may be one way to account for the incredible speed and efficency. Worth looking into.
What? That is the total opposite of what I have been hearing for decades. HP calculator enthusiasts love RPN. That is why the buy HP calculators. Which traditionally were pretty expensive. What other possible reason would there be to be an HP calculator enthusiast?
mklrobo, if you're asking whether Forth should be included in your MS Linux distribution disk, then I would say yes. Include all of the Propeller Forths -- Tachyon, pfth and PropForth. However, if you are asking whether your MS Linux OS should be written in Forth, then the answer is obviously no.
Yep, it's a fair cop, pre-meditated Forth bashing, guilty as charged.
I cannot speak for the other Forth bashers present but in my defence I offer this:
1) None of this is meant so serioulsy. People rib each other all the time about language choices, editor choices, OS choices, code formatting styles and so on and so on. I like to think of it as a bit of light hearted bun fighting as I said earlier. A play ground "bundle" as we used to say back in school.
2) I do not bash Forth on Forth threads. Or at least I don't think I have done so for a long, long time. I respect that Forth people have Forth things to discuss, like any other thread, and don't need the pointless interruptions of a gate crasher.
3) This is not a Forth thread. We were invited here to discuss "Forth or no Forth" to quote the threads title. I just happen to be on the "no Forth" side of the discussion.
4) I do not understand what the "esoteric and quirky" nature of the Propeller has to do with a programming language debate.
5) I do not understand what my insecurity or otherwise has to do with a programming language debate.
6)
Conversely can you show us how to write a Fast Fourier Transform for the Propeller in Forth?
No this is not just a bench mark, it has been used in a number of real apps.
7) I should have done what I thought about doing when this thread opened, deleted my original reply to mklrobo where he originally brought all this up and pasted it here. In that post I actually have a lot positive to say about Forth.
Edit:
8 ) Peter, I just noticed that in that quote of me you included whilst reprimanding me for Forth bashing I did not actually have any Forth bashing.
Always trying to be "smart" (for a nice word), the trouble with your "joking" is that you don't let up, you just intensify it to the point of vulgarity. Perhaps you could be constructive and demonstrate how C or Spin might be better suited somehow. That would never be annoying, it's something beneficial to all forum members. After all these years it might be too late to retrain that part of your personality which might be fun if we were sparring and having a beer in a pub together (thirsty now), although perhaps in this forum you could try moderating yourself.
As for your "challenge" you should know me, that's no challenge at all and before when you touted this as the case for C vs Forth it didn't bother me one bit, I was busy enough writing code that I could actually use. Now that P2 is close (image at least) I do have a need for an FFT, so in just around about an hour I have written a 256 point 16-bit signed complex FFT although I am still in the process of testing and optimizing it. However the challenge was thrown out to you to implement the filesystem and network severs (no demos) plus room to spare in C, something that would be really useful for Prop C users and promoting the Prop in education etc. Are you up to it my fine friend?
[FONT=courier new]TACHYON
Propeller .:.:--TACHYON--:.:. Forth V24140723.0130
ok
0149 ok
0150
00:00:06 End of source code, 0151 lines processed and 0000 errors found
MODULES LOADED:
35C1: FFT.fth Fast Fourier Transform - 256 point 16-bit signed complex - PBJ 140807
1900: EXTEND.fth Primary extensions to TACHYON kernel - 140723-14OO
NAMES: $5BB7...74CC for 6421 (223 bytes added)
CODE: $0000...4159 for 10308 (2968 bytes added)
CALLS: 0418 vectors free
RAM: 6750 bytes free
[/FONT]
Comments
Since this thread has turned into a frat party I will just ask whether you have any real information yet? As you can see everyone here is VERY helpful, some help themselves more than others
BTW, have a look at the Forths yourself and ignore the descriptions as they don't seem very accurate. For example I have a lot of stepper and PWM motor control software written with project pages for Tachyon Forth which I developed because I originally used PropForth to try to do this with, so the Youtube videos I did refer to Propforth rather than the final product. However Tachyon Forth is not a demonstrator, it is a realtime embedded Forth that I use in my paying commercial applications and I share some of those projects in my links page (at the end of the intro page).
All in the best possible taste of course:)
I think you will find that the fast SPI opcodes of Tachyon will make it a breeze to communicate with the Pixy. Remember that speed test where Spin and Propforth were way too slow to update 264 RGB LEDs over SPI? Tachyon updated all these in 2.66ms without a trace of assembler.
Anyway the reason I was really responding was the disbelief that upper/lower case are mentioned as "factors" in grasping the language. I'm used to Linux and it is case sensitive although I prefer to put my action words and opcodes in capitals to differentiate between variables, constants for instance. Makes it so much easier to read knowing that a word just by seeing it's lower case is just leaving a value for instance. I'm familiar with many languages and Forths but forgive me if I ask what is so "jarring" about Tachyon? I mean the Propeller itself is jarring, but in a good way (once you get to know it).
(I don't try to hide the Propeller in the language, I make the language suit it).
a singular intent of the authors, it was not followed. One possible solution is to have a base forth, then
provide downloadable libraries to constuct your own propeller project. Instead of a Forth that
is concentrated on motors/ steppers, and constricted to that purpose, the programmer could
add the libraries that was desired. The only constriction is the memory used. A base language
of that particular forth could be used, and libraries installed on the propeller. The "tweeking"
out of the installation would be the burden of the programmer. Comments?
I think you are talking through your hat, the authors know their single intent and I know I have followed through. There is no Forth that is concentrated on motors/steppers or constricted in those respects for instance, that's sheer bunkum to make such a statement. As I mentioned in another post you are probably better off trying out these Forths yourself, I mean there they are, freely available, and only you yourself can be the final judge of which is better for your task or not at all. After trying them out in your application you could then provide some actual and useful feedback which may then be considered.
You really need to understand Forth and the ideas behind building a Forth application. Read "Starting Forth" and "Thinking Forth" both by Leo Brodie and available on the web and also actually sit down with one or more Forths and play. Read through Peter's great introduction and play with Tachyon and then come back and we can talk. Until then, your generalizations and strict categorizations about Forth are meaningless and misleading to others that don't know anything about Forth.
Your proposal of a Mil-spec Forth is ludicrous if you don't understand the language and how it is used to develop INTO an application.
The upper-lower case example was used because it is the most obvious. As I said I find it jarring because I'm not used to reading forth that way. Also the words you've defined for using the prop are different than the one's I've used with pfth, which are similar to those I've used in other forth programming I've done. One of the things I like about forth is that it allows (encourages) different styles and ways of doing things. However, a different style can be jarring. I tend to be verbose in my forth, Tachyon is concise. I believe with some initial effort and taking time to work through the more complex examples, I'll become more comfortable with it. I've been reading the Tachyon thread (I'm about 2/3rds through it, and have run most of the examples in your intro. I had read the thread you mentioned and 2.66ms is the reason I feel it's worth the effort.
I expect to be posting questions in the Tachyon thread.
Tom
I prefer to take the position that I use Forth when I want a language that is interpreted and I use PASM, C, or Spin when I want a language that is compiled.
Much depends on the kind of project or problem I am exploring.
I have used PropForth, Pfth, and Tachyon.... So far, I feel most comfortable with Pfth.
I wouldn't not exactly say PropForth is well-documented. It is more likely that I say 'Well.... it is documented.' One can bury themselves in a documentation project. PropForth taught me that I needed to read the source code to get all the answers. And so I switched to pfth where I actually understood the source code.
eForth is an interesting deployment of Forth and reading its documentation in comparision to Pfth is very helpful. One really begins to learn what an 'inner interpreter', an 'outer interpreter', and the 'stacks' do. It gets easier once you have some idea of what makes it work and how the dictionary is managed.
My preference has not been for ultimate performance so much as a Forth that could be studied with an eye toward learning how to make my own. Pfth remains the best for that. Tachyon is likely the high flyer. PropForth is a bit too ambitious.
5 FOR using Forth;
6 AGAINST using Forth.
As more people weigh in, the stats will change.
Heater has some good suggestions;
1> do not waste time learning too many languages
2> a few languages, focus on syntax that is conceptually the same.
Heater suggested Forth++ in sarcasim, but David Betz had made an object oriented Forth, called DEC PDP-10 in approx 1978.
Mindbots suggested Gforth, an open source Forth associated with the GNU project.
I appreciate the guidance.
Why do YOU think Forth would be a good choice as the target/primary language for your Mil-Spec distribution?
What experiences do you have with Forth in general or Forth on a Propeller that makes it THE choice for a development language?
So abstaining doesn't count? So far less than a dozen people care enough to even offer an opinion. That tells me a lot.
Just for the record: "Forth is a waste of time." There are plenty of good languages to learn. I've written programs in at least 17 scripted, interpreted, compiled, AND BACKWARDS languages.
:frown: I am starting to get a headache, just thinking about Forth.(like Heater)
I am trying to acertain whether to invest time in writing a Forth adaptation. I do need a primary language, for the infrastructure
that I have in mind.(its a secret, don't tell anyone).:thumb:
After reviewing this thread, I have developed questions from their perspective.
I have to consider the real-world results; Peter J. has implemented Tachyon Forth, and retained a profitable investment. That can not be ignored, so
in that case, Forth has merit, in relation to the propeller.(examples in this forum.) It seems that alot of people like his work, as demonstrated in his thread.
So delve deeper, into the architeture;
The propeller has 8 "cogs" which are seperate processors, with a video generator. The I/O pins can be accessed by any cog, which could cause control
problems. It would seem intuitive to divide the processors into work groups.( Half processing and comm; the other dedicated to real world I/O.)
I will have to analyze the original objectives of forth, Vs. the architecture of the propeller to acquire a clear scope. Example; Forth sides with Hewlett Packard
in the Reverse Polish Notation processing of math; Is this in the best interests of the propellers memory/architecture? Are demands of the Forth's directives
in the best interest of the propeller, to add strength to the processing, and take headaches away from the programmer?
To answer the second question, No, I am no where near an oasis of expertise in the Forth language, like Peter J. That is why I have asked people in the forum, who are
more skilled than I.We all depend on each others' insight, and no one is an island.
Thanks again, I appreciate your insight.
With a bit of experience you will already have a feeling for such things as "Is Forth or Spin or BASIC going to be too slow or do I need a compiled language like C or even assembler?"
Without that experience you will just do it anyway and when it proves to slow or otherwise unworkable you will either give up or find a better solution.
The last thing the world needs is YAFFD. "Yet Another F*****g Forth Dialect". I find it very hard to believe that the magic "infrastructure" you want to build actually requires a whole new language to implement it. And there in lies the problem. Nobody knows what it is you actually want to accomplish. So it is impossible to advise.
Actually I'm pretty much sick and tired of the constant bad mouthed Forth bashing that goes on, and on threads that are specifically Forth, this even turns me off the esoteric and quirky Propeller chip too. You lot must be really really insecure. For once and for all put your money where your big bad mouth is and show us all how we can run with the fantabulous magic dare-not-challenge C, what I'm running now in Tachyon Forth with my SD filesystem and network servers etc on a plain old Prop with room left over for a sizable app too.????????? (So benchmark demos don't cut it)
I am studying on whether the C language taken in college or the UNIX I learned enough to be dangerous with while working an assignment will be the best choice to go with the latest Intel chip.
I think we need to get this on t-shirt!! :0)
Yep, it's a fair cop, pre-meditated Forth bashing, guilty as charged.
I cannot speak for the other Forth bashers present but in my defence I offer this:
1) None of this is meant so serioulsy. People rib each other all the time about language choices, editor choices, OS choices, code formatting styles and so on and so on. I like to think of it as a bit of light hearted bun fighting as I said earlier. A play ground "bundle" as we used to say back in school.
2) I do not bash Forth on Forth threads. Or at least I don't think I have done so for a long, long time. I respect that Forth people have Forth things to discuss, like any other thread, and don't need the pointless interruptions of a gate crasher.
3) This is not a Forth thread. We were invited here to discuss "Forth or no Forth" to quote the threads title. I just happen to be on the "no Forth" side of the discussion.
4) I do not understand what the "esoteric and quirky" nature of the Propeller has to do with a programming language debate.
5) I do not understand what my insecurity or otherwise has to do with a programming language debate.
6) Conversely can you show us how to write a Fast Fourier Transform for the Propeller in Forth?
No this is not just a bench mark, it has been used in a number of real apps.
7) I should have done what I thought about doing when this thread opened, deleted my original reply to mklrobo where he originally brought all this up and pasted it here. In that post I actually have a lot positive to say about Forth.
Edit:
8 ) Peter, I just noticed that in that quote of me you included whilst reprimanding me for Forth bashing I did not actually have any Forth bashing.
Now here's a thought. Lisp has been described as the ultimate high level language, while Forth has been described as the ultimate low level one. So can you write a Lisp interpreter in Forth? That would be mind bending.
Very interesting.
One of the "strengths" of forth is Reverse Polish Notation, which adds numbers in a weird way, but more efficent. Even HP calc enthusiasts do
not like this. This may cause havoc at the processing level, stressing out most programmers. I would guess that Peter J. has adapted this technique, and probably others,
to process data(video, comm, etc) in an efficent way. That may be one way to account for the incredible speed and efficency. Worth looking into.
I have learned alot, but I have a terrible headache!
Heater, never argue with a Forth Fanatic: "Even Angry Get Get"!
Ross.
Always trying to be "smart" (for a nice word), the trouble with your "joking" is that you don't let up, you just intensify it to the point of vulgarity. Perhaps you could be constructive and demonstrate how C or Spin might be better suited somehow. That would never be annoying, it's something beneficial to all forum members. After all these years it might be too late to retrain that part of your personality which might be fun if we were sparring and having a beer in a pub together (thirsty now), although perhaps in this forum you could try moderating yourself.
As for your "challenge" you should know me, that's no challenge at all and before when you touted this as the case for C vs Forth it didn't bother me one bit, I was busy enough writing code that I could actually use. Now that P2 is close (image at least) I do have a need for an FFT, so in just around about an hour I have written a 256 point 16-bit signed complex FFT although I am still in the process of testing and optimizing it. However the challenge was thrown out to you to implement the filesystem and network severs (no demos) plus room to spare in C, something that would be really useful for Prop C users and promoting the Prop in education etc. Are you up to it my fine friend?