Wintel

[blaisepascal]

Blaisepascal -

Re bloated C++, Java, C#

There are separate issues - semantic clarity, expressiveness, and size of language. For big jobs and experienced programmers a big language may provide needed expressiveness that allo9ws more concise and checkable code - but only if the sematics are clear.

cut for clarity
So you have either a small language which which is limited, or a big language which provides support for all these paradigms. The key is whether you can combine the different types of support needed without losing semantic clarity and concisivness. If not, best with the more limited language.

Exactly.

[MSimon]

Tom,

I think a lot of compilers. I think like everything else they should be small and simple.

C compilers violate the KISS principle. In addition you never know what they are going to do to your text. In the C projects I worked on we were always trying to outguess and outsmart the compiler. And we were always up against the stack thrash and the limitation of C of only being able to implicitly pass one value as the result of a function. Thus you get a proliferation of temporary variables of varying duration. Or worse global variables of varying freshness.

And the need for variables for passing more than one value makes recursion difficult.

And don't even get me started with having to write a prototype so the compiler knows how a function should work. A kluge if there ever was one.

FORTH compilers are not only simple they are easily extensible.

C is not very good for hard real time. You can make it work. It is a battle. Programmers should not be battling their language.

Late answers are wrong answers. A problem I was always fighting in C. To make it fast functions had to be long to avoid the stack thrash. However that violates the principle of short easily testable functions. Six or eight IF THENs that pass numeric values and you are hard pressed to test the function.

[MSimon]

blaise,

FORTH is small. It is simple. It is not limited. Anything missing from the compiler can be added with relative ease. Which is why it is called an extensible language.

You tailor the language to the problem not the problem to the language.

FORTH may not be good for everything. But for real time there is none better that I have found.

[MSimon]

There is currently an interesting debate between the "runtime debug" programmers - extreme programming, "test as specification", interpretive quick an dirty dynamically typed languages. And the "static debug" CS programmers: static typing & top-down design aided by formal declaration of data structures etc.

Here is how I used FORTH:

Quickly try a number of options. Pick the best. Formalize it.

This is especially helpful where the way a chip functions is not well documented or ambiguous. I used FORTH on C projects where FORTH was not allowed in the final code this way. We avoided a LOT of problems with this method. The code I used was throw away.

The problem with too much formalization in the beginning is that it is easy to program yourself in a corner when the complier does not work in an expected way or by coding you reconceptualize a problem so that the program is more efficient. C is hell because it does not work well when you run up against a compiler problem. Or for quick and dirty - try stuff - methods.

FORTH does require a LOT more programmer discipline to turn out good final code. But the rule these days is that programmers MUST learn discipline even in C. Discipline should not be compiler enforced. That is the sloppy way to get good results and often leads to bad results.

I go back to the project I mentioned above. I wound up with a working program much faster than the C guys with less time and money effort AND my code was self documenting because I chose my WORDS (names) very carefully. With my hired programmers I had to enforce disciple for the final code in my usual heavy handed way for a few weeks. After that they knew what I wanted and I hardly had to say a word.