sergio masci wrote:

> You forgot the "conformance" aspect. Ada is a registered trademark of
> the US DoD. 

Yup, didn't think of that. Definitely a killer.


> Yes I can see where you are comming from. So what would you say to a
> programmer who points at your generated code and laughing says "I
> could have done that in half the number of machine code instructions"
> using C. If your C "successor" is going to stand any chance of
> competeing with C, it's got to generate code that's at least on a par
> with it.

If it's competing on its turf, then yes. If I can say "I have developed
the application in 10% of the time it would have taken to develop it in
C", then it depends. That's probably the reason why C (and assembly) is
not that popular with bigger systems, notwithstanding its popularity
with smaller systems.


>> It seems a certain part of the engineering population thinks that
>> ladder logic is an adequate way to describe their control problems,
>> yet ladder logic compilers are definitely unpopular with the micro
>> crowd. There seem to be groups that have different views of what is
>> the easiest way to describe a problem.
> 
> Yes but most people that like ladder logic are not expert programmers.

Most people, and even most programmers, are not expert programmers (by
definition... :)

There is a place for languages that can be used by domain experts
efficiently, so that they don't need expert programmers to solve their
problems. What we do when we solve a problem with a microcontroller and
C (or assembly, or Pascal, or even XSBC :) is often a "hack", in the
absence of a better solution; the real solution would be something that
allows the domain expert to do it herself.


> But most problems can be broken down into much smaller well defined
> processes such as search, sort, append, remove etc. which a language
> should be able to apply to basic data types such as lists, sets,
> heaps, arrays, strings etc. For any really complex not yet thought-of
> domains we have libraries. I am so fed up with the notion that we
> need libraries for everything, that the language needs to be so
> rediculasly simply as to not be able to understand types such as
> lists, strings, dynamic array etc. when these types are so common and
> well understood. 

I for one never understood this "war" between language and libraries. I
don't really care that much whether C++ has a decent array type built
into the language or whether there are the C-style arrays for backwards
compatibility and as a decent solution there is std::vector from the
standard library. The standard libraries are, at least with C and C++,
part of the language specification. 

Then there are those cases where I still code my own containers, because
for the one or other requirement, the standard containers don't fit my
bill. Probably no language built-in container can do it all; there too
many different sets of requirements with different solutions.

You probably have a point with strings (in C and C++), but there is the
dreaded backwards compatibility that sooner or later hits everything
that is used for long enough, and so C is pretty much stuck with the
half-assed string implementation it has. In C++ there is std::string,
which works for many cases well enough (and again I don't really care
that much that this is from a library).


> I think if you look at a high level language like Java or even the
> executable produced by something like a C++ compiler, you will find
> that the native machine code being executed is not the problem - the
> problem is all the dynamic memory management that is going on.
> Objects being created and destroyed just so that trivial operations
> can be performed without impacting on other objects.

You're probably right. Heap management and garbage collection, pointer
and reference mechanics, support for polymorphism and virtual functions
-- all in microcode, directly executed, wouldn't that be nice? But by
judging from the 

> Personally I think if you really want to optimise a processor to
> execute high level code more efficiently then it needs an evaluation
> stack (kind of like FORTH) [...]

FORTH again... shouldn't it have had more success? :)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist