of possible interest

of possible interest

[Marco]

Is another VM necessary for resource-constrained embedded devices?
Ada mentioned

http://www.embedded.com/showArticle.jhtml?articleID=187000395

Re: of possible interest

[Ludovic Brenta]

"Marco" <prenom_nomus@yahoo.com> writes:
> Is another VM necessary for resource-constrained embedded devices?
> Ada mentioned
>
> http://www.embedded.com/showArticle.jhtml?articleID=187000395

Quite interesting indeed.  For embedded software, Aonix are promoting
a new, unproven, proprietary development and run-time environment
derived from Java, a notoriously unsafe language, while at the same
time admitting that Ada has been just fine for these environments for
23 years.

Don't waste your time reading this PR crap. Instead, go re-read the
papers from Praxis and AdaCore; these papers will be worth your while
because they will improve your skills as a programmer.

If I were Praxis or AdaCore, I'd be sure to send articles praising my
Ada-based products to embedded.com.

-- 
Ludovic Brenta.

Re: of possible interest

[Georg Bauhaus]

On Thu, 2006-05-04 at 21:26 +0200, Ludovic Brenta wrote:
> "Marco" <prenom_nomus@yahoo.com> writes:
> > Is another VM necessary for resource-constrained embedded devices?
> > Ada mentioned
> >
> > http://www.embedded.com/showArticle.jhtml?articleID=187000395
> 
> Quite interesting indeed.  For embedded software, Aonix are promoting
> a new, unproven, proprietary development and run-time environment
> derived from Java,

I'd not be so sure about this. If you actually look at the
things Aonix offers under the heading "Java", you will notice
a number of familiar items. One has the qualification Raven,
for a start...

The "Java" has @AnnoTations that let me speculate they do use
their Ada experience to build something that is more marketable
yet incorporates lots of Ada, and possibly more, even when
this is not syntactically apparent.

>  a notoriously unsafe language,

They don't just use Java, really, considering names like
@StaticallyAnalyzable in their language. An ahead-of-time
compiler is not the same thing as a JIT, either.

>  while at the same
> time admitting that Ada has been just fine for these environments for
> 23 years.

I'm curious whether there isn't a financial incentive: The J-word
sells much better than the A-word, so how do we find a compromise
between {}s and language rigor, for display software of smartphones
or ticket machines, etc.

I also do not understand your qualification of the "development and
run-time environment derived from Java". It's Eclipse AFAICT, so
neither exactly unproven nor totally black-box-proprietary stuff,
seen from a Java perspective.

OTOH, what's the effect of 'Img on Ada?


Georg 

Re: of possible interest

[Ed Falis]

On Thu, 04 May 2006 19:30:27 -0400, Georg Bauhaus <bauhaus@futureapps.de>  
wrote:

> The "Java" has @AnnoTations that let me speculate they do use
> their Ada experience to build something that is more marketable
> yet incorporates lots of Ada, and possibly more, even when
> this is not syntactically apparent.

Certainly they do, though Kelvin is not an Ada guy (he is a good and smart  
guy, though).

Former Aonix employee, before they bought Newmonics,

- Ed

Re: of possible interest

[Ludovic Brenta]

Georg Bauhaus writes:
> On Thu, 2006-05-04 at 21:26 +0200, Ludovic Brenta wrote:
>> Quite interesting indeed.  For embedded software, Aonix are promoting
>> a new, unproven, proprietary development and run-time environment
>> derived from Java,
>
> I'd not be so sure about this. If you actually look at the
> things Aonix offers under the heading "Java", you will notice
> a number of familiar items. One has the qualification Raven,
> for a start...
>
> The "Java" has @AnnoTations that let me speculate they do use
> their Ada experience to build something that is more marketable
> yet incorporates lots of Ada, and possibly more, even when
> this is not syntactically apparent.

I haven't found these on the FAQ, but you make it sound like they've
actually "embraced and extended" the Java language. If that's the case,
then I can only conclude they've partly fallen into the trap of "yet
another language" which the paper criticised.

> >  a notoriously unsafe language,
>
> They don't just use Java, really, considering names like
> @StaticallyAnalyzable in their language. An ahead-of-time
> compiler is not the same thing as a JIT, either.
>
> >  while at the same
> > time admitting that Ada has been just fine for these environments for
> > 23 years.
>
> I'm curious whether there isn't a financial incentive: The J-word
> sells much better than the A-word, so how do we find a compromise
> between {}s and language rigor, for display software of smartphones
> or ticket machines, etc.

Of course there is a financial incentive.  That was precisely the cause
of my ire: they seem to be favouring marketing over engineering. They
have an aura as a provider of top-of-the-line technology for
top-of-the-line embedded systems. They could use that aura to persuade
the masses to use good Software Engineering tools. Instead, they
promote Java-based tools. By doing this, they might gain customers, but
they've lost their aura and soul. They encourage businesses to hire
Java coders instead of software engineers and to lower their standards.

Besides, what are they hoping? Do they really want to compete against
hordes of Java "me-too" tool providers?

> I also do not understand your qualification of the "development and
> run-time environment derived from Java". It's Eclipse AFAICT, so
> neither exactly unproven nor totally black-box-proprietary stuff,
> seen from a Java perspective.

The compiler, precompiled libraries and virtual machine are
proprietary. I see they offer a "source code license", though. Probably
quite expensive, but my main gripe is that it still violates Freedoms 2
and 3.

They seem to be trying to get their "extensions" to the language into a
standard. That's good, but in the mean time, if you use these
"extensions" in your programs, you risk becoming a captive customer
anyway. What good is a standard if only one vendor supports it?

> OTOH, what's the effect of 'Img on Ada?

Do you mean that AdaCore is guilty of "embracing and extending", too?
Yes, that's true, but they also provide pragma Extensions_Allowed, so
they can be forgiven :) Moreover, contrary to Java, Ada is quite
suitable for embedded Software Engineering even without  any
extensions.

-- 
Ludovic Brenta.

Re: of possible interest

[Nasser Abbasi]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:8764klwpz5.fsf@ludovic-brenta.org...

> derived from Java, a notoriously unsafe language, while at the same

I heard some bad things about java, mostly complaints about its speed or 
lack thereof.

But never heard Java being described as "notoriously unsafe language" 
before.

If Java is notoriously unsafe language, what will that make C?  :)

What makes you say that java is "notoriously unsafe language"? can you 
please give some specific examples?

If you are referring to it being used for real-time, and the uncertainty it 
brings there due to the GC kicking in and running for some undetermined 
time, making hard-time scheduling difficult, then that is something 
different. Or are you thinking of some other cases/examples?

You can say that java is not suitable for real-time. But that is different 
from saying it is unsafe language. Do you agree?

Nasser

Re: of possible interest

[Larry Kilgallen]

In article <EBh7g.2551$fb2.2534@newssvr27.news.prodigy.net>, "Nasser Abbasi" <nma@12000.org> writes:

> If Java is notoriously unsafe language, what will that make C?  :)

A prototype, after which Java models its syntax.

Re: of possible interest

[Ludovic Brenta]

"Nasser Abbasi" <nma@12000.org> writes:

> "Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
> news:8764klwpz5.fsf@ludovic-brenta.org...
>
>> derived from Java, a notoriously unsafe language, while at the same
>
> I heard some bad things about java, mostly complaints about its speed or 
> lack thereof.
>
> But never heard Java being described as "notoriously unsafe language" 
> before.
>
> If Java is notoriously unsafe language, what will that make C?  :)
>
> What makes you say that java is "notoriously unsafe language"? can you 
> please give some specific examples?
>
> If you are referring to it being used for real-time, and the uncertainty it 
> brings there due to the GC kicking in and running for some undetermined 
> time, making hard-time scheduling difficult, then that is something 
> different. Or are you thinking of some other cases/examples?
>
> You can say that java is not suitable for real-time. But that is different 
> from saying it is unsafe language. Do you agree?
>
> Nasser

Yes, I agree.  By unsafe, I meant type-unsafe.  Specific reasons why are:

- Java does not support user-defined numeric types, only "int", "long"
  and other predefined types which reflect the virtual machine's
  internal types but not the problem domain of the programmer.  This
  allows you to mix apples and oranges, which is unsafe.  Ada
  programmers define their own types such as Number_Of_Apples and
  Number_Of_Oranges, and then the compiler prevents them to mix them,
  unless the programmer has also defined a way to mis them.

- Java up to version 1.4 did not have generics, therefore the entire
  class library is defined in terms of descendants of the Object
  class.  Since everything is an Object, you constantly have to
  perform type conversions at run time.  These are unsafe, because
  they might throw ClassCastException at any point in your program.
  Ada, through the use of generics, allows building type-safe
  libraries.  Even in Java 1.5 which has generics, the class library
  is unsafe because it supports backward compatibility with the unsafe
  Java 1.4.

- Java allows programmer to ignore the return value of functions.
  What if the return value was important?  This is unsafe.

- Java inserts implicit type conversions in too many places.  This is
  unsafe.  Safety-critical sotware only wants *explicit* type
  conversions under control of the programmer.

Additionally:

- There is no way in Java to restrict which features you want to use.

- There is no way in Java to remove the garbage collector and control
  memory for yourself.

- There is no way in Java to avoid dynamic dispatching (see the recent
  thread in this newsgroup on why dynamic dispatching is difficult to
  certify in safety-critical software).

-- 
Ludovic Brenta.

Re: of possible interest

[Frederic Praca]

Le Sun, 07 May 2006 17:56:15 GMT,
Dennis Lee Bieber <wlfraed@ix.netcom.com> a écrit :

> On Sun, 07 May 2006 14:54:47 +0200, Ludovic Brenta
> <ludovic@ludovic-brenta.org> declaimed the following in comp.lang.ada:
> 
> > 
> > - Java allows programmer to ignore the return value of functions.
> >   What if the return value was important?  This is unsafe.
> >
> 	Off-hand -- this is a wash... Ada requires one to /account
> for/ the presence of the return value, but it can still be just as
> easily ignored...
> 
> 	begin
> 		dummy := some_function(some_argument);
> 		--	dummy is never made use of; effectively
> ignored end;
Yes but in this case, everybody knows you explicitly ingore the
return value, you didn't forget it by mistake.

Fred  

Re: of possible interest

[Georg Bauhaus]

On Sun, 2006-05-07 at 22:37 +0200, Frederic Praca wrote:
> Le Sun, 07 May 2006 17:56:15 GMT,
> Dennis Lee Bieber <wlfraed@ix.netcom.com> a écrit :
> 
> > On Sun, 07 May 2006 14:54:47 +0200, Ludovic Brenta
> > <ludovic@ludovic-brenta.org> declaimed the following in comp.lang.ada:
> > 
> > > 
> > > - Java allows programmer to ignore the return value of functions.
> > >   What if the return value was important?  This is unsafe.
> > >
> > 	Off-hand -- this is a wash... Ada requires one to /account
> > for/ the presence of the return value, but it can still be just as
> > easily ignored...
> > 
> > 	begin
> > 		dummy := some_function(some_argument);
> > 		--	dummy is never made use of; effectively
> > ignored end;
> Yes but in this case, everybody knows you explicitly ingore the
> return value, you didn't forget it by mistake.

Does anyone know how relevant this is in practice,
given in mistakes per product, or increased development
cost?

Re: of possible interest

[Ludovic Brenta]

Georg Bauhaus writes :
> On Sun, 2006-05-07 at 22:37 +0200, Frederic Praca wrote:
>> Dennis Lee Bieber <wlfraed@ix.netcom.com> a écrit :
>>
>>> 	begin
>>> 		dummy := some_function(some_argument);
>>> 		--	dummy is never made use of; effectively
>>> ignored end;
>>
>> Yes but in this case, everybody knows you explicitly ingore the
>> return value, you didn't forget it by mistake.
>
> Does anyone know how relevant this is in practice,
> given in mistakes per product, or increased development
> cost?

Not very relevant IMHO, because Ada programmers, knowing that return
values cannot be ignored, design functions in such a way that the
returned value is sufficiently interesting that the caller will not
want to ignore it. In the few cases I've seen where the value is
actually ignored, there was always a comment explaining why, and this
was usually a symptom of poor design of the function.

-- 
Ludovic Brenta.

Re: of possible interest

[Robert A Duff]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Sun, 2006-05-07 at 22:37 +0200, Frederic Praca wrote:
> > Le Sun, 07 May 2006 17:56:15 GMT,
> > Dennis Lee Bieber <wlfraed@ix.netcom.com> a �crit :
> > 
> > > On Sun, 07 May 2006 14:54:47 +0200, Ludovic Brenta
> > > <ludovic@ludovic-brenta.org> declaimed the following in comp.lang.ada:
> > > 
> > > > 
> > > > - Java allows programmer to ignore the return value of functions.
> > > >   What if the return value was important?  This is unsafe.
> > > >
> > > 	Off-hand -- this is a wash... Ada requires one to /account
> > > for/ the presence of the return value, but it can still be just as
> > > easily ignored...
> > > 
> > > 	begin
> > > 		dummy := some_function(some_argument);
> > > 		--	dummy is never made use of; effectively
> > > ignored end;
> > Yes but in this case, everybody knows you explicitly ingore the
> > return value, you didn't forget it by mistake.
> 
> Does anyone know how relevant this is in practice,
> given in mistakes per product, or increased development
> cost?

I doubt it.  Such a scientific study would be pretty expensive.

As usual, all we have is anecdotal evidence, plus some (nonscientific)
reasoning, such as, "It seems to me more readable to have explicitly
ignored results rather than implicitly ignored results".

In languages that allow implicitly ignored results, programmers often
write functions that return rarely-useful results, just because some
result happens to be handy in the function body, knowing that the result
can be easily ignored.  For the above example, in Ada, one might write:

    function Some_Funtion(...) return Integer;
    procedure Some_Funtion(...);

where they both do the same thing, but one returns a sometimes-useful
result, and the other does not.  The "dummy" thing above would be inside
the procedure, rather than scattered all over the place.

- Bob

Re: of possible interest

[David Emery]

There's a lot of anecdotal and probably some documented evidence on large chunks of C code where the return value of a system call was ignored.  Those 2 ATT/Bell Labs studies on common programming errors in C on the 5ESS project documented this as a problem (if I remember correctly) and recommended some solutions (but not the right one, switching to a language with exceptions and where at least syntactically, you had to provide a container for a function return, even if you ignore the result... :-). 

A good compiler should issue a warning in the following situation:

declare
	return_value : error_status_codes;
begin
	return_value := some_function (parameters);
	do_more_computations (parameters);
end;

noting that "return_value" is never used.  That's usually a hint of a problem.

    dave

Re: of possible interest

[Pascal Obry]

David Emery a �crit :
> A good compiler should issue a warning in the following situation:
> 
> declare
>     return_value : error_status_codes;
> begin
>     return_value := some_function (parameters);
>     do_more_computations (parameters);
> end;

> noting that "return_value" is never used.  That's usually a hint of a
> problem.

GNAT does that.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595