Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25342 > unrolled thread

C# for Embedded ?...

Back to article view | Back to comp.arch.embedded

Contents

  C# for Embedded ?... Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-04 13:12 +0000
    Re: C# for Embedded ?... Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-11-04 15:16 +0200
      Re: C# for Embedded ?... Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-04 13:39 +0000
      Re: C# for Embedded ?... Jack <jack4747@gmail.com> - 2016-11-04 07:52 -0700
        Re: C# for Embedded ?... Luke A. Guest <laguest@archeia.com> - 2016-11-30 12:47 +0000
    Re: C# for Embedded ?... Dave Nadler <drn@nadler.com> - 2016-11-04 06:44 -0700
      Re: C# for Embedded ?... Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-04 14:30 +0000
        Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 11:54 -0700
          Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 12:10 -0700
            Re: C# for Embedded ?... Mike Perkins <spam@spam.com> - 2016-11-06 14:55 +0000
              Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-06 12:46 -0700
                Re: C# for Embedded ?... Mike Perkins <spam@spam.com> - 2016-11-06 20:48 +0000
                  Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-06 14:25 -0700
          Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-04 12:11 -0700
            Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 15:17 -0700
              Re: C# for Embedded ?... Clifford Heath <no.spam@please.net> - 2016-11-05 09:24 +1100
          Re: C# for Embedded ?... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-11-04 22:38 +0100
            Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 15:12 -0700
              Re: C# for Embedded ?... Clifford Heath <no.spam@please.net> - 2016-11-05 09:21 +1100
              Re: C# for Embedded ?... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-11-05 07:21 +0100
                Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 23:39 -0700
                Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-04 23:52 -0700
                  Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 00:44 -0700
                    Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-05 04:03 -0700
                      Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 04:41 -0700
                        Re: C# for Embedded ?... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-11-06 10:03 +0100
                          Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-06 14:32 -0800
                      Re: C# for Embedded ?... upsidedown@downunder.com - 2016-11-05 15:39 +0200
                        Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 11:12 -0700
                      Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-05 11:35 -0700
                        Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 11:46 -0700
      Re: C# for Embedded ?... Luke A. Guest <laguest@archeia.com> - 2016-11-30 12:47 +0000
    Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 15:37 +0000
      Re: C# for Embedded ?... Tim Wescott <tim@seemywebsite.really> - 2016-11-04 11:32 -0500
        Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 18:19 +0000
    Re: C# for Embedded ?... George Neuner <gneuner2@comcast.net> - 2016-11-04 12:07 -0400
      Re: C# for Embedded ?... David Brown <david.brown@hesbynett.no> - 2016-11-04 17:54 +0100
        Re: C# for Embedded ?... Tim Wescott <seemywebsite@myfooter.really> - 2016-11-04 12:54 -0500
      Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 18:36 +0000
        Re: C# for Embedded ?... George Neuner <gneuner2@comcast.net> - 2016-11-04 22:00 -0400
          Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-04 21:02 -0700
            Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 08:45 +0000
          Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 08:38 +0000
            Re: C# for Embedded ?... George Neuner <gneuner2@comcast.net> - 2016-11-06 04:50 -0500
              Re: C# for Embedded ?... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-11-06 19:49 +0200
              Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-06 19:05 +0000
      Re: C# for Embedded ?... Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-11-06 19:52 +0100
        Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-06 11:10 -0800
          Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-06 22:44 +0000
        Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-06 19:12 +0000
          Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-06 11:33 -0800
            Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-06 22:59 +0000
              Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-06 15:48 -0800
                Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-07 07:45 +0000
                  Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-07 00:09 -0800
                    Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-07 09:56 +0000
                      Re: C# for Embedded ?... Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-11-07 18:38 +0100
                        Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-07 19:17 +0000
                          Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-07 21:29 -0800
                            Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-08 08:07 +0000
                              Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-08 01:00 -0800
                                Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-08 10:19 +0000
    Re: C# for Embedded ?... John Speth <johnspeth@yahoo.com> - 2016-11-04 10:03 -0700
      Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 12:04 -0700
      Re: C# for Embedded ?... Clifford Heath <no.spam@please.net> - 2016-11-05 09:13 +1100
        Re: C# for Embedded ?... Ed Prochak <edprochak@gmail.com> - 2016-11-07 11:16 -0800
          Re: C# for Embedded ?... Clifford Heath <no.spam@please.net> - 2016-11-08 21:39 +1100
            Re: C# for Embedded ?... Ed Prochak <edprochak@gmail.com> - 2016-11-11 15:25 -0800
    Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-04 11:22 -0700
      Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 18:50 +0000
        Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-04 11:58 -0700
          Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-04 12:17 -0700
        Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-04 12:51 -0700
          Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 23:23 +0000
            Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-04 17:35 -0700
              Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 09:04 +0000
      Re: C# for Embedded ?... Wouter van Ooijen <wouter@voti.nl> - 2016-11-04 22:55 +0100
      Re: C# for Embedded ?... Luke A. Guest <laguest@archeia.com> - 2016-11-30 15:55 +0000
    Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 11:48 -0700
    Re: C# for Embedded ?... asdf <asdf@nospam.com> - 2016-11-05 12:40 +0000
      Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 15:48 +0000
        Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-05 11:41 -0700
          Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 20:20 +0000
            Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-05 19:14 -0700
      Re: C# for Embedded ?... upsidedown@downunder.com - 2016-11-05 20:15 +0200
        Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 20:25 +0000
          Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 17:15 -0700
    Re: C# for Embedded ?... Mike Perkins <spam@spam.com> - 2016-11-05 21:04 +0000
    Re: C# for Embedded ?... Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-06 00:31 +0000
      Re: C# for Embedded ?... Dave Nadler <drn@nadler.com> - 2016-11-05 18:11 -0700
    Re: C# for Embedded ?... Luke A. Guest <laguest@archeia.com> - 2016-11-30 12:43 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#25379

On 11/4/2016 11:21 PM, Niklas Holsti wrote:
> On 16-11-04 23:12 , Don Y wrote:
>> On 11/4/2016 2:38 PM, Niklas Holsti wrote:
>>> On 16-11-04 19:54 , Don Y wrote:
>>>> "Big system language" and "memory requirements" and "runtime"
>>>> don't preclude a particular choice.  Consider Ada in your
>>>> above assessment (hardly "small", economical, etc.).
>>>
>>> I challenge you to prove that facile slander of Ada. Ada-the-language is
>>> certainly "larger" than C, but not larger than C++. Ada applications are
>>> comparable in performance and memory needs to C applications. You can
>>> prefer C
>>> if you like, but not for such reasons.
>>
>> Do you consider Ada a "SMALL system language"?
>
> Certainly it it suitable for small systems. Remember, Ada was originally
> designed in the early 1980s, for applications including embedded systems, many
> of which were then quite small by current standards.

And assembly language is suitable for HUGE systems!  As is COBOL, LISP, etc.

Would you *typically* advertise:
     Manufacturer of microwave ovens seeks Ada-fluent developer with
     N years experience?
And:
     Developer of nation-state missile defense systems seeks fluent
     ASM programmer?

You pick tools appropriate to the effort involved and the skillsets of
the folks you expect to hire.  E.g., if the local missile manufacturer
goes out of business suddenly, you can probably pick up a slew of
Ada developers "dirt cheap".  But, barring that, you'd typically not
ask for that expertise and have to retrain them in some other
"commodity" language and development style.

> The emphasis on embedded systems was so strong that some people believed that
> Ada wasn't good for anything else (IMO a false belief, of course).
>
>> I'm not talking about
>> the number of words/constructs in the language -- do you think it is
>> designed with "small systems" in mind?  Would you choose it to
>> implement a microwave oven controller (a half page of "BASIC")?
>
> If an Ada compiler were available, certainly. And a half page of BASIC would be
> a very simple microwave oven indeed (depending of course on how much of the
> functions, safety interlocks etc. are implemented in HW).

A Microwave oven controller is a simple project.  There are essentially
four things that have to be done:
- keep track of time of day
- control the maggie's output power (duty cycle modulate at just above DC)
- keep track of time remaining in cook cycle
- update display/accept keypad input/overrides

Some might have a temperature probe (cook until specific temperature
reached).

Some might have shortcuts (defrost is powerlevel P for time T).

But, the overall function is trivial.

[Note some have an electromechanical DIAL mechanism]

>> Ada is inherently targeted towards "bigger systems" (bigger
>> meaning more complex).
>
> It was designed to *support* such systems -- that was often called "programming
> in the large". But those features of Ada -- in particular the strong modularity
> (packages) and the encapsulation and information hiding features -- are
> entirely source-level, compile-time features and imply no overhead at run time.
>
> One of the goals in the design of Ada was to avoid "distributed overhead" from
> language features that are not used in an application. If your application does
> not need multi-threading, fine, use a run-time system without tasking support.
> If you need only simple multi-threading, use a Ravenscar RTS, and so on.
>
>> Why employ all those capabilities when
>> your overall objective is a "small project"?
>
> Small projects tend to grow, and to need maintenance, sometimes over a long
> time. Readability and maintainability are important and were also explicit
> design goals of the Ada language.

And many small projects are just one-shot deals.  It is wiser to reuse
*designs* than code.  How much code will that next microwave inherit
from the first?
     "We want to allow the user to select a food TYPE to be defrosted..."
     "We want to add a popcorn sensor..."
     "We want to add a full graphic display so the user can surf the web..."

>> Seriously, look at what it takes to implement YOUR microwave
>> oven's controller
>
> I've not seen the code in there, but I suspect that it is rather more than a
> half page of BASIC.

Sit down and *write* the pseudo-code for YOUR microwave oven.
Or your toaster.  Or your HVAC thermostat.  Or your furnace.
Or your keyboard/mouse/etc.

The number of "simple" designs out there greatly exceeds the
number of designs that can significantly benefit from more
capable languages -- esp when you consider the resources
those languages can impose on the unsuspecting developer
(not all employers can afford or hire 'Experts')

> Still, this thread is (or was) not about micowave ovens, but about a
> safety-critical automotive application, which I suspect is larger than a
> microwave-oven controller.

No, the comment to which I replied was an utterance re: C#:
     "So from what I can see, it's a big systems language in memory
     requirements for libraries and run time support. C# also uses
     dynamic memory allocation and garbage collection, another red
     line for the this type of application."
The reference to the "application" was essentially an afterthought,
therein.  My reply, to which you consider slander:
     "'Big system language' and 'memory requirements' and 'runtime'
     don't preclude a particular choice.  Consider Ada in your
     above assessment (hardly "small", economical, etc.)."

I stand by that assertion.

[toc] | [prev] | [next] | [standalone]

#25380

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> The emphasis on embedded systems was so strong that some people
> believed that Ada wasn't good for anything else (IMO a false belief,
> of course).

Famous quote by Larry Wall:

  Plus I remember being impressed with Ada because you could write an
  infinite loop without a faked up condition. The idea being that in
  Ada the typical infinite loop would be normally be terminated by
  detonation.    -- Larry Wall in <199911192212.OAA23621@kiev.wall.org>

> Still, this thread is (or was) not about micowave ovens, but about a
> safety-critical automotive application, which I suspect is larger than
> a microwave-oven controller.

It seems to me that microwave ovens these days would usually be
programmed in C rather than BASIC, but Ada is perfectly well suited for
almost anything C is suitable for.  For that matter, the Arduino was
built around AVR microcontrollers with 1k or 2k of ram, and the
"official" programming language for the Arduino environment was/is C++,
which is even more complex than Ada.

[toc] | [prev] | [next] | [standalone]

#25381

On 11/4/2016 11:52 PM, Paul Rubin wrote:
>> Still, this thread is (or was) not about micowave ovens, but about a
>> safety-critical automotive application, which I suspect is larger than
>> a microwave-oven controller.
>
> It seems to me that microwave ovens these days would usually be
> programmed in C rather than BASIC, but Ada is perfectly well suited for
> almost anything C is suitable for.  For that matter, the Arduino was
> built around AVR microcontrollers with 1k or 2k of ram, and the
> "official" programming language for the Arduino environment was/is C++,
> which is even more complex than Ada.

Note that I'd not claimed microwave ovens WERE coded in BASIC but,
rather, used BASIC as an example of how "complex (simple)" the
application is.

(Too!) Many small applications are still coded in ASM in the
belief that this gives better control over resources/application
size.

We have a MCU controlled *toaster*; wanna bet the application
is two pages of ASM?
     heating_element(ON)
     while (temperature < setpoint) {
        blink_LED()
     }
     eject_toast()
I'd wager the code in our furnace isn't much more complex -- and
there much primarily to report errors for troubleshooting
(blinkenlites)

The complexity of the user interface seems to be a driving factor in
the complexity of the codebase in many deeply embedded products.
I.e., the control algorithms being simpler than the interactions
with the user.

[toc] | [prev] | [next] | [standalone]

#25385

lauantai 5. marraskuuta 2016 9.47.34 UTC+2 Don Y kirjoitti:
> On 11/4/2016 11:52 PM, Paul Rubin wrote:
> >> Still, this thread is (or was) not about micowave ovens, but about a
> >> safety-critical automotive application, which I suspect is larger than
> >> a microwave-oven controller.
> >
> > It seems to me that microwave ovens these days would usually be
> > programmed in C rather than BASIC, but Ada is perfectly well suited for
> > almost anything C is suitable for.  For that matter, the Arduino was
> > built around AVR microcontrollers with 1k or 2k of ram, and the
> > "official" programming language for the Arduino environment was/is C++,
> > which is even more complex than Ada.
> 
> Note that I'd not claimed microwave ovens WERE coded in BASIC but,
> rather, used BASIC as an example of how "complex (simple)" the
> application is.
> 
> (Too!) Many small applications are still coded in ASM in the
> belief that this gives better control over resources/application
> size.
> 
> We have a MCU controlled *toaster*; wanna bet the application
> is two pages of ASM?
>      heating_element(ON)
>      while (temperature < setpoint) {
>         blink_LED()
>      }
>      eject_toast()
> I'd wager the code in our furnace isn't much more complex -- and
> there much primarily to report errors for troubleshooting
> (blinkenlites)
> 
> The complexity of the user interface seems to be a driving factor in
> the complexity of the codebase in many deeply embedded products.
> I.e., the control algorithms being simpler than the interactions
> with the user.

You have mentioned ASM, BASIC and Lisp here as examples of programming languages which can be used to create "tight code" or which can be used as embedded programming languages implementing the microwave oven. Yes, you are right. Why not?

However, there is more in software engineering than just being able to write "tight code" or the language can be used to write a controller for a device.

The languages you have brought up (ASM, BASIC, Lisp) in addition with the C and C++ has very poor type system. The compiler (or the interpreter in case of Lisp or BASIC) nor the runtime environment cannot make sure, for example, that the variables are not assigned values that are outside the intended numeric range, nor the compiler or the runtime environment cannot validate that the table indexes are within the table bounds. Those languages just perform actions without any knowledge whether or not the action was valid or just plain wrong. 

Worst yet, the software engineer cannot specify the valid numeric range of the variables that it is expected to hold. It is also very hard for the humans reading the code to validate that the operations and actions are within the intended boundaries. That is why the programming language needs to have a built-in, strict and rigorous type checking mechanism which is able to automatically validate each and every action, assignment, computation and table access through out the program.

Ada has a very strong type checking system. The SPARK subset of Ada has even an ability to mathematically prove the program to behave as expected.

Ada has automatic, built-in runtime checks for variable and table range checking as the compiler knows what values are allowed for the variable and the table index.

You may argue that the strict type and the run-time checking costs too much. Well, the compilation time type checking doesn't cost anything at the runtime, so no penalty here. You can enable or disable the runtime checks as you will, so you can tune the performance as needed.

Languages like C, C++, BASIC, Lisp or ASM just don't have built-in capabilities and expressiveness that provide the software engineer the power to express his/hers intentions and requirements which will be rigorously checked through out the programming project, nor the compiler enough information the perform rigorous and extensive compilation time and runtime checks.

Br,
Kalvin

[toc] | [prev] | [next] | [standalone]

#25386

On 11/5/2016 4:03 AM, kalvin.news@gmail.com wrote:
> lauantai 5. marraskuuta 2016 9.47.34 UTC+2 Don Y kirjoitti:
>> On 11/4/2016 11:52 PM, Paul Rubin wrote:
>>>> Still, this thread is (or was) not about micowave ovens, but about a
>>>> safety-critical automotive application, which I suspect is larger
>>>> than a microwave-oven controller.
>>>
>>> It seems to me that microwave ovens these days would usually be
>>> programmed in C rather than BASIC, but Ada is perfectly well suited for
>>> almost anything C is suitable for.  For that matter, the Arduino was
>>> built around AVR microcontrollers with 1k or 2k of ram, and the
>>> "official" programming language for the Arduino environment was/is C++,
>>> which is even more complex than Ada.
>>
>> Note that I'd not claimed microwave ovens WERE coded in BASIC but, rather,
>> used BASIC as an example of how "complex (simple)" the application is.
>>
>> (Too!) Many small applications are still coded in ASM in the belief that
>> this gives better control over resources/application size.
>>
>> We have a MCU controlled *toaster*; wanna bet the application is two pages
>> of ASM? heating_element(ON) while (temperature < setpoint) { blink_LED()
>> } eject_toast() I'd wager the code in our furnace isn't much more complex
>> -- and there much primarily to report errors for troubleshooting
>> (blinkenlites)
>>
>> The complexity of the user interface seems to be a driving factor in the
>> complexity of the codebase in many deeply embedded products. I.e., the
>> control algorithms being simpler than the interactions with the user.
>
> You have mentioned ASM, BASIC and Lisp here as examples of programming
> languages which can be used to create "tight code" or which can be used as
> embedded programming languages implementing the microwave oven. Yes, you are
> right. Why not?

The example offered has nothing to do with "tight code" -- a microwave
oven isn't particularly challenging even with the slowest processor
using an interpreted language!  Rather, it's just matching the
complexity of the problem to the complexity of the solution.  Likewise
wrt costs.

You wouldn't bring a backhoe onto your property to plant daisies.

Nor use a spade to excavate for a swimming pool!

Using a backhoe to plant daisies requires you to hire someone capable of
operating a backhoe.

Using a spade to excavate a swimming pool requires you hire someone
who has a strong back.

You wouldn't use a Cray to control a microwave oven nor an 8b MCU
to process airline reservations -- though BOTH could be done (poorly!)

> However, there is more in software engineering than just being able to write
> "tight code" or the language can be used to write a controller for a
> device.
>
> The languages you have brought up (ASM, BASIC, Lisp) in addition with the C
> and C++ has very poor type system. The compiler (or the interpreter in case
> of Lisp or BASIC) nor the runtime environment cannot make sure, for example,
> that the variables are not assigned values that are outside the intended
> numeric range, nor the compiler or the runtime environment cannot validate
> that the table indexes are within the table bounds. Those languages just
> perform actions without any knowledge whether or not the action was valid or
> just plain wrong.
>
> Worst yet, the software engineer cannot specify the valid numeric range of
> the variables that it is expected to hold. It is also very hard for the
> humans reading the code to validate that the operations and actions are
> within the intended boundaries. That is why the programming language needs
> to have a built-in, strict and rigorous type checking mechanism which is
> able to automatically validate each and every action, assignment,
> computation and table access through out the program.
>
> Ada has a very strong type checking system. The SPARK subset of Ada has even
> an ability to mathematically prove the program to behave as expected.
>
> Ada has automatic, built-in runtime checks for variable and table range
> checking as the compiler knows what values are allowed for the variable and
> the table index.
>
> You may argue that the strict type and the run-time checking costs too much.
> Well, the compilation time type checking doesn't cost anything at the
> runtime, so no penalty here. You can enable or disable the runtime checks as
> you will, so you can tune the performance as needed.
>
> Languages like C, C++, BASIC, Lisp or ASM just don't have built-in
> capabilities and expressiveness that provide the software engineer the power
> to express his/hers intentions and requirements which will be rigorously
> checked through out the programming project, nor the compiler enough
> information the perform rigorous and extensive compilation time and runtime
> checks.
>
> Br, Kalvin
>

[toc] | [prev] | [next] | [standalone]

#25403

On 16-11-05 12:41 , Don Y wrote:

[concerning the suitability of some "large" languages for "small" 
applications]

> The example offered has nothing to do with "tight code" -- a microwave
> oven isn't particularly challenging even with the slowest processor
> using an interpreted language!  Rather, it's just matching the
> complexity of the problem to the complexity of the solution.  Likewise
> wrt costs.
>
> You wouldn't bring a backhoe onto your property to plant daisies.
>
> Nor use a spade to excavate for a swimming pool!
>
> Using a backhoe to plant daisies requires you to hire someone capable of
> operating a backhoe.
>
> Using a spade to excavate a swimming pool requires you hire someone
> who has a strong back.
>
> You wouldn't use a Cray to control a microwave oven nor an 8b MCU
> to process airline reservations -- though BOTH could be done (poorly!)

Those are all false analogies, or at least misleading analogies. There 
are just two questions:

1) can the tool do the required job?

2) are there some draw-backs (e.g. cost, delay) associated with the tool?

A backhoe can be used to plant daisies (well, at least to dig the holes, 
if you don't mind the holes being too large), so perhaps (1) is ok. But 
clearly a backhoe costs more than a shovel, probably will take longer 
(including the time taken to bring the backhoe to the site, and remove 
it afterwards), and will mess up your lawn, so point (2) would argue 
against using a backhoe for this job.

Switching from the analogy to the real subject -- programming an 
embedded system -- it is clear that a "large" language can do "small" 
jobs, and can do them as well (from the functional point of view) as a 
"small" language, even for real-time aspects. So question (1) needs no 
discussion.

Question (2) is more interesting. What are the costs, or other 
draw-backs, of using a "large" language (e.g. Ada or C++)? These costs 
and other issues can apply to the development tools and process 
(non-recurring costs) or to the recurring production costs, in 
particular through the required computing resources in the embedded system.

The cost of development tools varies a lot. There are some no-cost tools 
as well for "large" languages as for "small" languages, and there are 
some expensive tools as well for "large" languages as for "small" 
languages. Of course I grant that there are more no-cost or cheap 
assemblers and C compilers for more targets than there are such Ada 
compilers -- unfortunately. And indeed there is probably a correlation 
here: creating a compiler for a large language is more work than for a 
small language, so one can expect a higher compiler price. However, for 
professional work that cost would be spread over several projects.

The nature and cost of the development process does not depend on the 
"size" of the language, but on the criticality of the application. So 
this point has no bearing.

There remains the question of the required embedded computing resources. 
Don's comment on the suitability of Ada for small applications was 
specifically on the "efficiency" of the language, and I understood him 
to mean efficiency in terms of the generated code size and execution 
speed compared, for example, to C or assembly language. As Ada is a 
traditional imperative, procedural language, usually compiled to native 
machine code, with no implicit need for dynamic memory allocation or 
garbage collection, I continue to object to Don's claim that it is 
inefficient for systems such as the one that started this thread.

For controlling a toaster, if one uses assembly language it is probably 
possible to use an MCU with no RAM, such as a tiny AVR. There is no 
fundamental technical reason why a "large"-language compiler could not 
generate code that runs without RAM, for a very small application, but 
one will probably not find such a compiler. However, once the 
application is large enough to require some RAM, the necessary RAM size 
become more a matter of application requirements and coding style than 
of the coding language -- assuming that the programming system links in 
only the required parts of the language-defined libraries.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

[toc] | [prev] | [next] | [standalone]

#25418

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> Question (2) is more interesting. What are the costs, or other
> draw-backs, of using a "large" language (e.g. Ada or C++)?

It's similar to the issue of using a huge, complex,
infrastructure-dependent device like an automobile to do something
simple, like go to the store to pick up a few electronic parts.  You
could walk or use a skateboard instead, but most people won't think
twice about using a car if the store is further than a km or two.

Or in the software world, a modern web browser is one of the most
complicated single applications out there.  Yet we use them all the time
for looking at 140-character text messages on twitter that were
originally expected to be sent much more simply, by SMS.  What's more,
the 140 character message viewed in a browser is surrounded by a
megabyte or so of javascript cruft that's almost do-nothing, but most
users don't notice it or shrug their shoulders about it.

> For controlling a toaster, if one uses assembly language it is
> probably possible to use an MCU with no RAM, such as a tiny AVR. There
> is no fundamental technical reason why a "large"-language compiler
> could not generate code that runs without RAM, for a very small
> application, but one will probably not find such a compiler. 

See: http://www.lightner.net/avr/ATtiny/projects/README.txt

There's also a special purpose x86 compiler (part of Coreboot) that
generates register-only code (no ram, no stack) to get the x86 boot
process started before the ram controller is initialized:

 http://review.coreboot.org/cgit/coreboot.git/tree/util/romcc?id=HEAD

[toc] | [prev] | [next] | [standalone]

#25388

On Sat, 5 Nov 2016 04:03:32 -0700 (PDT), kalvin.news@gmail.com wrote:

>
>Ada has a very strong type checking system. The SPARK subset of Ada has even an ability to mathematically prove the program to behave as expected.
>
>Ada has automatic, built-in runtime checks for variable and table range checking as the compiler knows what values are allowed for the variable and the table index.
>
>You may argue that the strict type and the run-time checking costs too much. Well, the compilation time type checking doesn't cost anything at the runtime, so no penalty here. You can enable or disable the runtime checks as you will, so you can tune the performance as needed.
>
>Languages like C, C++, BASIC, Lisp or ASM just don't have built-in capabilities and expressiveness that provide the software engineer the power to express his/hers intentions and requirements which will be rigorously checked through out the programming project, nor the compiler enough information the perform rigorous and extensive compilation time and runtime checks.

When designing user/kernel mode switching APIs or similar programs,
you absolutely first things is to check the validity of the call
parameters.   PERIOD. 

Such as if it is accessability from the calling (user) mode.

These annual checks should give a clean well defined (version
independent) error codes.

Letting the program access deeper than that and any run-time error
code could be anything and as such useless.

[toc] | [prev] | [next] | [standalone]

#25391

On 11/5/2016 6:39 AM, upsidedown@downunder.com wrote:
> On Sat, 5 Nov 2016 04:03:32 -0700 (PDT), kalvin.news@gmail.com wrote:
>
>>
>> Ada has a very strong type checking system. The SPARK subset of Ada has
>> even an ability to mathematically prove the program to behave as
>> expected.
>>
>> Ada has automatic, built-in runtime checks for variable and table range
>> checking as the compiler knows what values are allowed for the variable
>> and the table index.
>>
>> You may argue that the strict type and the run-time checking costs too
>> much. Well, the compilation time type checking doesn't cost anything at
>> the runtime, so no penalty here. You can enable or disable the runtime
>> checks as you will, so you can tune the performance as needed.
>>
>> Languages like C, C++, BASIC, Lisp or ASM just don't have built-in
>> capabilities and expressiveness that provide the software engineer the
>> power to express his/hers intentions and requirements which will be
>> rigorously checked through out the programming project, nor the compiler
>> enough information the perform rigorous and extensive compilation time and
>> runtime checks.
>
> When designing user/kernel mode switching APIs or similar programs, you
> absolutely first things is to check the validity of the call parameters.
> PERIOD.

There are many things that "best practices" can bring to (a variety of
different) implementation languages to improve quality/accuracy/reliability.

I use invariants heavily on gazintas and cumzoutas -- in addition
to any other place in the code when I'm sure of expectations.  This
serves both as a way of verifying that the actual implementation
is "as expected" as well as leaving succinct notes for those
who follow regarding the "contracts" that the code makes with
its callers.

Likewise, there are things in the operating environment (e.g., OS)
that can protect against things that no amount of automated checking
or type-checking can enforce.

> Such as if it is accessability from the calling (user) mode.
>
> These annual checks should give a clean well defined (version independent)
> error codes.
>
> Letting the program access deeper than that and any run-time error code
> could be anything and as such useless.

[toc] | [prev] | [next] | [standalone]

#25392

kalvin.news@gmail.com writes:
>>      heating_element(ON)
>>      while (temperature < setpoint) {...
> Worst yet, the software engineer cannot specify the valid numeric
> range of the variables that it is expected to hold....
> Ada has a very strong type checking system. 

I have trouble believing that a sane toaster would have
software-controlled at all.  Most toasters use an electromechanical
thermostat, so when when it reaches the right temperature, the
thermostat trips the spring that pops the toast up.

But, in the old days, that stuff was written in asm, which was even more
typeless than something like BASIC.  These days even in cheap appliances
I suspect C prevails.  

[toc] | [prev] | [next] | [standalone]

#25394

On 11/5/2016 11:35 AM, Paul Rubin wrote:
> kalvin.news@gmail.com writes:
>>>      heating_element(ON)
>>>      while (temperature < setpoint) {...
>> Worst yet, the software engineer cannot specify the valid numeric
>> range of the variables that it is expected to hold....
>> Ada has a very strong type checking system.
>
> I have trouble believing that a sane toaster would have
> software-controlled at all.  Most toasters use an electromechanical
> thermostat, so when when it reaches the right temperature, the
> thermostat trips the spring that pops the toast up.

Ours has a darkness setting, LED indicators, and buttons that act
as presets for:
- frozen
- warm
- bagels
- pastry
- waffle
- cancel (eject)
We purchased it ~15 years ago -- primarily because it was dirt cheap!

<http://kitchen.manualsonline.com/manuals/mfg/sunbeam/6220.html>

> But, in the old days, that stuff was written in asm, which was even more
> typeless than something like BASIC.  These days even in cheap appliances
> I suspect C prevails.

[toc] | [prev] | [next] | [standalone]

#25524

Dave Nadler <drn@nadler.com> wrote:

> While I've used C# for Windows applications I haven't tried it
> on an embedded platform. For embedded projects normally I use C++ 

Good luck stripping it down to run from 256kb flash.

[toc] | [prev] | [next] | [standalone]

#25348

On 04/11/16 13:12, Chris wrote:
> Hi,
>
> I've been invited to a meeting to discuss am automotive like engineering
> project with a high level of safety critical requirements.
>
> They are using Simulink for some of the top level design work, but are
> programming the whole lot in C#, with some of the code already written.
> Not sure at this stage which rtos is being used, if at all.
>
>  From what I've read, C# is a web / application / database programming
> language and a quick look at the Wiki page suggests that the two
> most recent versions are not approved by any international standards
> organisation.
>
> C# raises alarm bells here for all kinds of reasons, but what do you
> think ?...

C# is a big red flag, not only for embedded but also for safety
critical.

Others have made suitable language suggestions, but I'll
note that in safety critical applications the process is
at least as important as the language and libraries.

As with any engineering, it is necessary to consider
not only what will "go right", but what could "go
wrong" - and the latter will often shape the entire
design and design process.

In bad cases, "go wrong" includes lawyers doing "discovery"
to find anything they can latch onto and prove liability.

[toc] | [prev] | [next] | [standalone]

#25350

On Fri, 04 Nov 2016 15:37:22 +0000, Tom Gardner wrote:

> On 04/11/16 13:12, Chris wrote:
>> Hi,
>>
>> I've been invited to a meeting to discuss am automotive like
>> engineering project with a high level of safety critical requirements.
>>
>> They are using Simulink for some of the top level design work, but are
>> programming the whole lot in C#, with some of the code already written.
>> Not sure at this stage which rtos is being used, if at all.
>>
>>  From what I've read, C# is a web / application / database programming
>> language and a quick look at the Wiki page suggests that the two most
>> recent versions are not approved by any international standards
>> organisation.
>>
>> C# raises alarm bells here for all kinds of reasons, but what do you
>> think ?...
> 
> C# is a big red flag, not only for embedded but also for safety
> critical.
> 
> Others have made suitable language suggestions, but I'll note that in
> safety critical applications the process is at least as important as the
> language and libraries.
> 
> As with any engineering, it is necessary to consider not only what will
> "go right", but what could "go wrong" - and the latter will often shape
> the entire design and design process.
> 
> In bad cases, "go wrong" includes lawyers doing "discovery"
> to find anything they can latch onto and prove liability.

I just want to put an underscore here.  I've had the "ADA vs. C" 
discussion with various high-rel types before, and you can pretty much 
divide the answers down to three bins: two are filled by "my language is 
better because it's better", and the remaining one is filled by "get the 
process right, and either C or ADA will do".

I don't think that anyone who is sane would want to use a language like 
Java or C#.

If a failure can injure or kill, you need to use a tool chain and library 
set that's up to the task -- for avionics, they need to be certified to 
the same level of criticality as the code itself; I would treat 
automotive with the same regard.  I don't think you'll find a C# 
compiler, much less a platform on which C# will run, that even comes 
close.

-- 
www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#25354

On 04/11/16 16:32, Tim Wescott wrote:
> On Fri, 04 Nov 2016 15:37:22 +0000, Tom Gardner wrote:
>
>> On 04/11/16 13:12, Chris wrote:
>>> Hi,
>>>
>>> I've been invited to a meeting to discuss am automotive like
>>> engineering project with a high level of safety critical requirements.
>>>
>>> They are using Simulink for some of the top level design work, but are
>>> programming the whole lot in C#, with some of the code already written.
>>> Not sure at this stage which rtos is being used, if at all.
>>>
>>>   From what I've read, C# is a web / application / database programming
>>> language and a quick look at the Wiki page suggests that the two most
>>> recent versions are not approved by any international standards
>>> organisation.
>>>
>>> C# raises alarm bells here for all kinds of reasons, but what do you
>>> think ?...
>>
>> C# is a big red flag, not only for embedded but also for safety
>> critical.
>>
>> Others have made suitable language suggestions, but I'll note that in
>> safety critical applications the process is at least as important as the
>> language and libraries.
>>
>> As with any engineering, it is necessary to consider not only what will
>> "go right", but what could "go wrong" - and the latter will often shape
>> the entire design and design process.
>>
>> In bad cases, "go wrong" includes lawyers doing "discovery"
>> to find anything they can latch onto and prove liability.
>
> I just want to put an underscore here.  I've had the "ADA vs. C"
> discussion with various high-rel types before, and you can pretty much
> divide the answers down to three bins: two are filled by "my language is
> better because it's better", and the remaining one is filled by "get the
> process right, and either C or ADA will do".
>
> I don't think that anyone who is sane would want to use a language like
> Java or C#.
>
> If a failure can injure or kill, you need to use a tool chain and library
> set that's up to the task -- for avionics, they need to be certified to
> the same level of criticality as the code itself; I would treat
> automotive with the same regard.  I don't think you'll find a C#
> compiler, much less a platform on which C# will run, that even comes
> close.

Agreed.

I'd like to add a second underscore...

Getting the process right will, as a side effect,
show that you will almost certainly need to choose
a /subset/ of a language. MISRA C and SparkADA
spring to mind.

Subsets are necessary to avoid the underdefined
parts of languages and toolchains, and to avoid
design practices and patterns that are typically
problematical in various ways.

[toc] | [prev] | [next] | [standalone]

#25349

On Fri, 04 Nov 2016 13:12:57 +0000, Chris <xxx.syseng.yyy@gfsys.co.uk>
wrote:

> From what I've read, C# is a web / application / database programming
>language 

The "application" part is pretty accurate.

C# is designed primarily to be a safe(r) version of C with the
addition of single inheritence objects  [unlike C++ which has multiple
inheritence].  

C# is a managed language with GC - much like Java.  However, unlike
Java, C# has an "unsafe" mode that can bypass the runtime, eschew GC,
and work directly with hardware.

>and a quick look at the Wiki page suggests that the two
>most recent versions are not approved by any international standards
>organisation.

That's probably true.  I haven't paid attention to it.

>C# raises alarm bells here for all kinds of reasons, but what do you
>think ?...

The "alarm bells" I hear are availabiliy and performance of the CLR
runtime on your hardware.  AFAIK, it's only available for Windows and
Linux.  The Mono version might also run on Unix, but I don't know that
for certain.

The "unsafe" mode of C# can do anything C can do ... but IMO there's
no point to C# unless you are going to use objects and GC - and that
requires the runtime.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#25351

On 04/11/16 17:07, George Neuner wrote:
> On Fri, 04 Nov 2016 13:12:57 +0000, Chris <xxx.syseng.yyy@gfsys.co.uk>
> wrote:
>
>> From what I've read, C# is a web / application / database programming
>> language
>
> The "application" part is pretty accurate.
>
> C# is designed primarily to be a safe(r) version of C with the
> addition of single inheritence objects  [unlike C++ which has multiple
> inheritence].
>
> C# is a managed language with GC - much like Java.  However, unlike
> Java, C# has an "unsafe" mode that can bypass the runtime, eschew GC,
> and work directly with hardware.
>
>> and a quick look at the Wiki page suggests that the two
>> most recent versions are not approved by any international standards
>> organisation.
>
> That's probably true.  I haven't paid attention to it.
>
>> C# raises alarm bells here for all kinds of reasons, but what do you
>> think ?...
>
> The "alarm bells" I hear are availabiliy and performance of the CLR
> runtime on your hardware.  AFAIK, it's only available for Windows and
> Linux.  The Mono version might also run on Unix, but I don't know that
> for certain.
>
> The "unsafe" mode of C# can do anything C can do ... but IMO there's
> no point to C# unless you are going to use objects and GC - and that
> requires the runtime.
>

There are two /very/ different meanings of "safe" here.  In typical 
c.a.embedded systems, "safe" means "Code does exactly what the designer 
wants it to do, otherwise someone could be injured or killed".  In the 
world of C#, Java, Windows, etc., "safe" means "is unlikely to have 
serious security flaws that let bad guys steal your passwords and send 
you adverts for small blue pills".

I would not trust C# to be more than mid-level "safe" in its own meaning 
of the word, and that's before anyone writes a line of application code. 
  Neither the tools, the run-time libraries, nor the platforms it runs 
on come anywhere close to c.a.e. "safe".

(The language itself might be all right - as has been pointed out, it is 
the process that has to be safe, not the language.)

[toc] | [prev] | [next] | [standalone]

#25353

On Fri, 04 Nov 2016 17:54:56 +0100, David Brown wrote:

> On 04/11/16 17:07, George Neuner wrote:
>> On Fri, 04 Nov 2016 13:12:57 +0000, Chris <xxx.syseng.yyy@gfsys.co.uk>
>> wrote:
>>
>>> From what I've read, C# is a web / application / database programming
>>> language
>>
>> The "application" part is pretty accurate.
>>
>> C# is designed primarily to be a safe(r) version of C with the addition
>> of single inheritence objects  [unlike C++ which has multiple
>> inheritence].
>>
>> C# is a managed language with GC - much like Java.  However, unlike
>> Java, C# has an "unsafe" mode that can bypass the runtime, eschew GC,
>> and work directly with hardware.
>>
>>> and a quick look at the Wiki page suggests that the two most recent
>>> versions are not approved by any international standards organisation.
>>
>> That's probably true.  I haven't paid attention to it.
>>
>>> C# raises alarm bells here for all kinds of reasons, but what do you
>>> think ?...
>>
>> The "alarm bells" I hear are availabiliy and performance of the CLR
>> runtime on your hardware.  AFAIK, it's only available for Windows and
>> Linux.  The Mono version might also run on Unix, but I don't know that
>> for certain.
>>
>> The "unsafe" mode of C# can do anything C can do ... but IMO there's no
>> point to C# unless you are going to use objects and GC - and that
>> requires the runtime.
>>
>>
> There are two /very/ different meanings of "safe" here.  In typical
> c.a.embedded systems, "safe" means "Code does exactly what the designer
> wants it to do, otherwise someone could be injured or killed".  In the
> world of C#, Java, Windows, etc., "safe" means "is unlikely to have
> serious security flaws that let bad guys steal your passwords and send
> you adverts for small blue pills".
> 
> I would not trust C# to be more than mid-level "safe" in its own meaning
> of the word, and that's before anyone writes a line of application code.
>   Neither the tools, the run-time libraries, nor the platforms it runs
> on come anywhere close to c.a.e. "safe".
> 
> (The language itself might be all right - as has been pointed out, it is
> the process that has to be safe, not the language.)

The process AND the tools, AND the libraries.

In this case I wouldn't trust the tools and libraries unless they were 
independently verified (because Microsoft's idea of verification is "oh, 
you'll buy our stuff if we say it'll work for you -- hey! Guess what?  
Our stuff will work for you!")

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [prev] | [next] | [standalone]

#25356

On 04/11/16 16:07, George Neuner wrote:
> On Fri, 04 Nov 2016 13:12:57 +0000, Chris <xxx.syseng.yyy@gfsys.co.uk>
> wrote:
>
>>  From what I've read, C# is a web / application / database programming
>> language
>
> The "application" part is pretty accurate.
>
> C# is designed primarily to be a safe(r) version of C with the
> addition of single inheritence objects  [unlike C++ which has multiple
> inheritence].

No. It was designed as a response to Java's success, and
was a traditional Microsoft attempt to keep developers on
the Windows platform.

There are two, and only two significant differences
with Java: a different runtime philosophy ("ahead
of time" vs "just in time"/Hotspot optimisation), and
the addition of code marked "unsafe".

The latter destroys the advantages of having a
managed environment, doh!

When we put those points to Anders Hjelsberg
(C#'s designer) a few months before C# became
available, he did not provided a substantive
answer, let alone a rebuttal)

> C# is a managed language with GC - much like Java.  However, unlike
> Java, C# has an "unsafe" mode that can bypass the runtime, eschew GC,
> and work directly with hardware.

You can work directly with hardware in Java
using the JNI interface and C/assembler/ADA/etc.

There is, nominally, a realtime Java, but the
necessary restrictions make it almost completely
unlike Java. There's zero benefit to it over other
languages.

OTOH, when I've needed to create clustered high
availability soft realtime systems (e.g. telco),
then Java is my language of choice.

Java is also favoured in the financial sector,
where they spend /vast/ amounts or money to
shave a few milliseconds latency! Example:
laying dedicated trans-Atlantic fibre optic
cables, resurrecting microwave links between
Chicago and New York, and "blowing" /trading/
/algorithms/ into FPGAs.

Java is not necessarily slow, although like any
language, it can be made slow :)

[toc] | [prev] | [next] | [standalone]

#25376

On Fri, 4 Nov 2016 18:36:13 +0000, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 04/11/16 16:07, George Neuner wrote:
>
>> C# is designed primarily to be a safe(r) version of C with the
>> addition of single inheritence objects  [unlike C++ which has multiple
>> inheritence].
>
>No. It was designed as a response to Java's success, and
>was a traditional Microsoft attempt to keep developers on
>the Windows platform.

C# was designed to compete head-to-head with Java.  They did this
because Sun's lawsuit forced them to abandon J++.

However, if you take a step back and look at the history, another
picture emerges.

Managed C++ (the ancestor of C++/CLI and C#) was released just a few
months after Java - proof that it was in development at the same time.
When the Java (ne Oak) project began, Microsoft already was working on
"COM+", a project to unite COM and OLE with the runtimes of their
popular managed languages: VisualBasic and FoxPro.  When Java
appeared, COM+ already supported VisualBasic, FoxPro and Managed C++.
After Java appeared, the project morphed into CLR and the aim became
to (eventually) support all the Microsoft languages.


So it's true that Java arrived before C#.  It's not true that JVM
arrived before (what became) CLR.


>There are two, and only two significant differences
>with Java: a different runtime philosophy ("ahead
>of time" vs "just in time"/Hotspot optimisation), and
>the addition of code marked "unsafe".

That isn't exactly true either.  JVM does not directly support tail
calls.  CLR does directly support tail calls and so better supports
languages that require them.  F# is an example of this - there is no
ML family language for JVM. 


>You can work directly with hardware in Java
>using the JNI interface and C/assembler/ADA/etc.

C# does not require you to use anything but C#


>OTOH, when I've needed to create clustered high
>availability soft realtime systems (e.g. telco),
>then Java is my language of choice.


The JVM machine is not bad, but I dislike Java the language and I
avoid it whenever possible.  There are better languages to use if you
need to target the JVM.  YMMV.

I don't much like C# either and I'm not particularly a fan of
Microsoft, but I don't support bashing anyone with innuendo and
half-truths.


George

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web