C# for Embedded ?...

On Sat, 5 Nov 2016 08:38:08 +0000, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 05/11/16 02:00, George Neuner wrote:
>
>> C# was designed to compete head-to-head with Java.  They did this
>> because Sun's lawsuit forced them to abandon J++.
>
>Agreed.
>
>Don't forget that MS already had a reasonably
>good JVM and could have continued to offer Java,
>but decided not to on business grounds and out
>of hubris.

The "business grounds" were Sun suing to stop Microsoft from
distributing their JVM clone.  Sun claimed Microsoft's enhancements
made the J++ machine non-conformant and a copyright infringement.
Microsoft chose drop the product rather than fight about it..

The only "hubris" on the part of Microsoft was daring to make their
JVM better than Sun's.


>> 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.
>
>My understanding is that Com+ is mainly a means of bolting
>together components and passing state (especially transational
>state) between them. The components are usually much larger
>than a class, and can in theory be written in any language
>provided that the /external/ semantics are preserved.

Yes. 

COM+ was an internal project name that shipped as COMv2 with DCOM. The
COM+ name was repurposed to refer to the distributed COM protocol
rather than the implementation.

The connection to transactional services came later.


George

On 04/11/2016 19:10, Don Y wrote:
> On 11/4/2016 11:54 AM, Don Y wrote:
>> Embedded systems come in all different sizes and varieties.
>> Also the "depth" of the embedding varies tremendously
>> (the code running on the Mars Rover is designed to operate
>> in a very different environment than the code that runs
>> the cash registers at your local supermarket!)
>>
>> As do the consequences of failures, etc.
>
> Here's a great "safety critical" application that's essentially
> trivial:  dispensing gasoline!  (a "process" controlled by unskilled
> users:  DRIVERS!)

It may appear that way, but in reality I think you'll find some hardware 
interlock so when the user releases the nozzle trigger, one or more 
valves will close, independent of any software.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

On 16-11-06 11:50 , George Neuner wrote:
> On Sat, 5 Nov 2016 08:38:08 +0000, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>> On 05/11/16 02:00, George Neuner wrote:
>>
>>> C# was designed to compete head-to-head with Java.  They did this
>>> because Sun's lawsuit forced them to abandon J++.
>>
>> Agreed.
>>
>> Don't forget that MS already had a reasonably
>> good JVM and could have continued to offer Java,
>> but decided not to on business grounds and out
>> of hubris.
>
> The "business grounds" were Sun suing to stop Microsoft from
> distributing their JVM clone.  Sun claimed Microsoft's enhancements
> made the J++ machine non-conformant and a copyright infringement.
> Microsoft chose drop the product rather than fight about it..
>
> The only "hubris" on the part of Microsoft was daring to make their
> JVM better than Sun's.

It seemed fairly apparent at the time that Microsoft tried to follow 
their traditional "embrace, extend and extinguish" strategy in order to 
force the open, portable, standard Java off MS-Windows platforms and 
replace it with a Microsoft-owned "MS-Java" limited to MS-Windows platforms.

According to Wikipedia 
(https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish), 
Microsoft did not make a "better JVM", they removed the Java Native 
Interface (JNI) and replaced it with their own "J/Direct" interface, 
harming the portability of Java programs between MS-Windows and other 
systems. Further according to Wikipedia, there were two lawsuits against 
Microsoft over this issue, for which Microsoft paid over US$2 billion in 
out-of-court settlements.

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

Am 04.11.2016 um 17:07 schrieb George Neuner:

> 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].

I can't agree with that assessment.  The reasons C# exists in spite of 
the previously available Java clearly never had anything whatsoever to 
do with computer language design or compiler technology.  C# was not 
initially designed at all; it was cloned from Java strictly for reasons 
of business strategy.  MS has always been afflicted with a really bad 
case of NIH (not invented here) syndrome, so when Java started to feel 
like one of the symptoms of that, their attempt at a cure was C#.

As to language design principles and goals, perhaps the shortest 
explanation of Java's (and thus, by cloning, C#'s) primary concept is 
"C++--".  I.e. they took C++ and removed or at least downsized its more 
problematic constructs.  Most prominently multiple inheritance was 
boiled down to the "interface"/"implements" construct, some of the 
legacy C semantics thrown out, and platform dependencies were moved from 
the language into the VM.

In a comparison between C# and Java for embedded usage I see Java 
several steps ahead.  Java's "Micro Edition" and "Java Card" sub-sets at 
least exist and have some kind of an ecosystem to them.

On 06/11/16 09:50, George Neuner wrote:
> On Sat, 5 Nov 2016 08:38:08 +0000, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>> On 05/11/16 02:00, George Neuner wrote:
>>
>>> C# was designed to compete head-to-head with Java.  They did this
>>> because Sun's lawsuit forced them to abandon J++.
>>
>> Agreed.
>>
>> Don't forget that MS already had a reasonably
>> good JVM and could have continued to offer Java,
>> but decided not to on business grounds and out
>> of hubris.
>
> The "business grounds" were Sun suing to stop Microsoft from
> distributing their JVM clone.  Sun claimed Microsoft's enhancements
> made the J++ machine non-conformant and a copyright infringement.
> Microsoft chose drop the product rather than fight about it..

That's the tradition embrace-extend-etc modus operandi.

> The only "hubris" on the part of Microsoft was daring to make their
> JVM better than Sun's.

It wasn't better, and later HotSpot was much better.

I remember a time when the MS JIT converted multiplication
into addition, so that unjitted 6!=720, but jitted 6!=21


>>> 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.
>>
>> My understanding is that Com+ is mainly a means of bolting
>> together components and passing state (especially transational
>> state) between them. The components are usually much larger
>> than a class, and can in theory be written in any language
>> provided that the /external/ semantics are preserved.
>
> Yes.
>
> COM+ was an internal project name that shipped as COMv2 with DCOM. The
> COM+ name was repurposed to refer to the distributed COM protocol
> rather than the implementation.
>
> The connection to transactional services came later.

I thought so; pleasant that my understanding wasn't too
inaccurate. However, that makes any comparison between
COM+ and a JVM pretty meaningless.

Hans-Bernhard Br&ouml;ker <HBBroeker@t-online.de> writes:
> As to language design principles and goals, perhaps the shortest
> explanation of Java's (and thus, by cloning, C#'s) primary concept is
> "C++--".  I.e. they took C++ and removed or at least downsized its
> more problematic constructs.  Most prominently multiple inheritance
> was boiled down to the "interface"/"implements" construct, some of the
> legacy C semantics thrown out, and platform dependencies were moved
> from the language into the VM.

From James Iry's "Brief, Incomplete, and Mostly Wrong History of
Programming Languages":

    1996 - James Gosling invents Java. Java is a relatively verbose,
    garbage collected, class based, statically typed, single dispatch,
    object oriented language with single implementation inheritance and
    multiple interface inheritance. Sun loudly heralds Java's novelty.

    2001 - Anders Hejlsberg invents C#. C# is a relatively verbose,
    garbage collected, class based, statically typed, single dispatch,
    object oriented language with single implementation inheritance and
    multiple interface inheritance. Microsoft loudly heralds C#'s
    novelty.

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html

The rest of the history is hilarious too.

On 06/11/16 18:52, Hans-Bernhard Br�ker wrote:
> Am 04.11.2016 um 17:07 schrieb George Neuner:
>
>> 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].
>
> I can't agree with that assessment.  The reasons C# exists in spite of the
> previously available Java clearly never had anything whatsoever to do with
> computer language design or compiler technology.  C# was not initially designed
> at all; it was cloned from Java strictly for reasons of business strategy.  MS
> has always been afflicted with a really bad case of NIH (not invented here)
> syndrome, so when Java started to feel like one of the symptoms of that, their
> attempt at a cure was C#.

Precisely.


> As to language design principles and goals, perhaps the shortest explanation of
> Java's (and thus, by cloning, C#'s) primary concept is "C++--".  I.e. they took
> C++ and removed or at least downsized its more problematic constructs.  Most
> prominently multiple inheritance was boiled down to the "interface"/"implements"
> construct, some of the legacy C semantics thrown out, and platform dependencies
> were moved from the language into the VM.

I can't agree with that assessment. :)

If you look at the original Java whitepaper, it is /extremely/
clear that Gosling looked at and understood a wide range of
computer science theory and practice, and selected just the
right set of features that "play well" with each other.

That whitepaper, the clarity of its vision and exposition,
was the reason I (and others) rapidly jumped on board the
Java bandwagon.


> In a comparison between C# and Java for embedded usage I see Java several steps
> ahead.  Java's "Micro Edition" and "Java Card" sub-sets at least exist and have
> some kind of an ecosystem to them.

I looked at Java Card 15 years ago, and it is such a
small subset of Java that it is as similar to Java as
JavaScript is to Java. In addition the execution
environment is so (necessarily) limited that there's
no real benefit to having Java.

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> I looked at Java Card 15 years ago, and it is such a small subset of
> Java that it is as similar to Java as JavaScript is to Java. 

It's a useful enough subset for its intended applications, such as
payment cards.

> In addition the execution environment is so (necessarily) limited that
> there's no real benefit to having Java.

The main benefit compared with earlier systems was the security model,
which allowed applets running in the cards that were isolated from each
other and whose communication to the outside was controlled by the
communication object passed into the applet.  There was some formal
verification work done on the security model iirc.

On 11/6/2016 7:55 AM, Mike Perkins wrote:
> On 04/11/2016 19:10, Don Y wrote:
>> On 11/4/2016 11:54 AM, Don Y wrote:
>>> Embedded systems come in all different sizes and varieties.
>>> Also the "depth" of the embedding varies tremendously
>>> (the code running on the Mars Rover is designed to operate
>>> in a very different environment than the code that runs
>>> the cash registers at your local supermarket!)
>>>
>>> As do the consequences of failures, etc.
>>
>> Here's a great "safety critical" application that's essentially
>> trivial:  dispensing gasoline!  (a "process" controlled by unskilled
>> users:  DRIVERS!)
>
> It may appear that way, but in reality I think you'll find some hardware
> interlock so when the user releases the nozzle trigger, one or more valves will
> close, independent of any software.

You do realize that you can latch the nozzle "on"?
And, that there is no guarantee that the user will have
it positioned *in* the filler neck of a vehicle (so the
"full" backpressure sensor will disengage that latch)?

I.e., a malevolent user at an unattended gas station
could latch the nozzle on and walk away, flooding the
area with fuel.  Or, the backpressure sensor could fail.
(when addressing safety critical/mission critical/etc.
applications, you have to PLAN on failures and decide
how you will address their inevitability)

[This was one of the issues we had to address when accommodating
unattended operation of the pumps.  You'll note that most service
stations either operate in prepay or semiattended mode -- though
we have electric and LNG/propane dispensaries, here, that are
completely unattended]

On 06/11/2016 19:46, Don Y wrote:
> On 11/6/2016 7:55 AM, Mike Perkins wrote:
>> On 04/11/2016 19:10, Don Y wrote:
>>> On 11/4/2016 11:54 AM, Don Y wrote:
>>>> Embedded systems come in all different sizes and varieties.
>>>> Also the "depth" of the embedding varies tremendously
>>>> (the code running on the Mars Rover is designed to operate
>>>> in a very different environment than the code that runs
>>>> the cash registers at your local supermarket!)
>>>>
>>>> As do the consequences of failures, etc.
>>>
>>> Here's a great "safety critical" application that's essentially
>>> trivial:  dispensing gasoline!  (a "process" controlled by unskilled
>>> users:  DRIVERS!)
>>
>> It may appear that way, but in reality I think you'll find some hardware
>> interlock so when the user releases the nozzle trigger, one or more
>> valves will
>> close, independent of any software.
>
> You do realize that you can latch the nozzle "on"?
> And, that there is no guarantee that the user will have
> it positioned *in* the filler neck of a vehicle (so the
> "full" backpressure sensor will disengage that latch)?
>
> I.e., a malevolent user at an unattended gas station
> could latch the nozzle on and walk away, flooding the
> area with fuel.  Or, the backpressure sensor could fail.
> (when addressing safety critical/mission critical/etc.
> applications, you have to PLAN on failures and decide
> how you will address their inevitability)
>
> [This was one of the issues we had to address when accommodating
> unattended operation of the pumps.  You'll note that most service
> stations either operate in prepay or semiattended mode -- though
> we have electric and LNG/propane dispensaries, here, that are
> completely unattended]

Most pumps limit how much fuel can be dispensed. I doubt you would use 
software alone to limit the fuel and you would have a mechanical device 
to measure flow and cut off accordingly.

I agree with you entirely on the planning of various risk control 
measures for a variety of scenarios. We're probably singing from the 
same hymn sheet though approaching from different directions.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk