I would say you're clearly exaggerating about this one. There are still a lot of areas where assembler is the only "viable" option, especially in small microcontrollers and DSP-based projects.
FORTH has been indeed used in a variety of "embedded" applications in scientific areas, I'm not denying this. Anyone can go visit http://www.forth.com/ - which is nicely promoting the FORTH language.
As to LISP, unfortunately your example is the one that is off base in my opinion. You should have chosen your example more carefully to make a point. What you are describing is not what I call an embedded environment per se. You are talking about some kind of "scripting" ability built in a commercial software package. We may differ on what we both call "embedded". Clearly, in this kind of area, an interpreted, easy to learn and widely used language can prove very useful. Emacs itself, a very well known text editor package, is almost entirely based on a variant of LISP and can be enhanced this way. I wouldn't say it's the fastest editor around either. But arguably, it's one of the most feature-rich.
I haven't forgotten anything, I would even add that any programmer using C without knowing the underlying facts is a lame programmer.
That being said, data types is one of the things that define a "high-level language". The ability to use abstracted data types is very useful. I don't know how you can really define data types in FORTH. You can implicitly use them, yes, but not with a lot of abstraction.
Of course. Obviously. I'm just saying that the way of expressing data structures (especially when they become complex) is far from explicit using a language like FORTH, and still too "direct" to be called a high-level language.
I have learnt and used LISP in the past. I was probably going a bit overboard using the word "obscure". LISP can be used for pretty much anything, but it's essentially not suited for expressing inherently sequential tasks. It can be done, of course. But it can get very hard to read. In the same vein, PROLOG was advertised as the almighty programming tool in the 80's. I have learnt PROLOG, and as interesting as it was, I wouldn't use it in any embedded work. Just writing a purely sequential task in PROLOG is higly doable, but is exotic to read, to say the least. Of course, that may just be me.
You're right about that, nothing to add here.
I wasn't being rude to you or anyone else in this debate, so I'm not sure why you'd feel compelled to be rude to me.
I said I'm personally not "convinced of the practical use of interpreted languages in an embedded environment".
To begin with, I don't think it was that "strong" of an opinion, since I used the word "convinced". I could have gone like: "interpreted languages are crap", it seems like it would have made no difference to you. Oh well.
Anyway, saying what I said is a double-edged sword: for one, it means that I'm yet to be convinced, but that I'm open to if any solid argument and practical work can prove that to me. Secondly, it means that I'm still *personally* cautious about all the "interpreted languages hype" that's been going on for several years in most areas (I'm particularly thinking about Java, C#, and the like). I have good reasons to remain cautious and have arguments against it *especially* in the embedded world, I'm not going to write a 200-page book here.
Yes, I do know. Again, FORTH is an interesting concept, but there are, in my opinion (again, I only speak for myself), many drawbacks in the way it's executed, for instance we can raise issues about the code execution process in terms of security.
I'm not the one who raised the business considerations. I have to agree with you here. As long, of course, as the result meets a certain quality standard. Unfortunately, time-to-market is sometimes more important than performance. But that's an entirely different debate.
Yes, of course. Choices. Your example is interesting, by the way. You're right, but without being totally "stuck", you can still have your own views about things - provided they are based on something real and not imaginary, provided you can back them up with some *real* arguments, and not "emotional" ones. You can still have opinions, that doesn't necessarily do harm to your team - it can actually be a plus. Either way, all I would say is that if you *knew* that *you* wouldn't do a good job using some tools, you'd be entitled to offer alternatives. There is no absolute best, that's for sure. But there can still be choices that are better for *you* than others. That's also what makes you unique, don't you think? And if you are to dedicate your work force on some project, I still think you're entitled to have a say in the tools you're going to use. That doesn't mean you shouldn't be open to new stuff.
Well, I wasn't going into details. But, FORTH *is* stack-based, you can't claim otherwise, can you? And as long as there is use of a stack as the main storing space, that raises some specific issues. I'm not at all saying that it's an unusable approach.
Yes, you're right. "The right tool for the job" is not always as easy to define as you seem to say, though. Like you said before, there is no best. Besides (using your own arguments), you could always find some engineer who would maybe write a wonderful image processing package in FORTH.
Ultimately, you said it best: "So, C++ is the right choice for me and for that application class."
You can't claim there isn't a subjective part in the choice of tools you're willing to use, you admitted it yourself.
The key words are right here: *for you*.
I may have my own arguments against some tools you use, and likewise you maye have some against the tools I tend to prefer. That's what I call a debate.
No need to make people that don't agree with you 100% look like they are stupid and uneducated. ;)