Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #25342 > unrolled thread
| Started by | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| First post | 2016-11-04 13:12 +0000 |
| Last post | 2016-11-30 12:43 +0000 |
| Articles | 20 on this page of 91 — 22 participants |
Back to article view | Back to comp.arch.embedded
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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-04 21:02 -0700 |
| Message-ID | <87fun6ingd.fsf@nightsong.com> |
| In reply to | #25376 |
George Neuner <gneuner2@comcast.net> writes: > 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. This is apparently a real issue, but I'm not sure why, since tail calls can be compiled into jumps. I wonder how Scala, Clojure, and Frege (all JVM functional languages) deal with it.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-05 08:45 +0000 |
| Message-ID | <T_gTz.1460023$7k5.1262276@fx38.am4> |
| In reply to | #25377 |
On 05/11/16 04:02, Paul Rubin wrote: > George Neuner <gneuner2@comcast.net> writes: >> 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. > > This is apparently a real issue, but I'm not sure why, since tail calls > can be compiled into jumps. I wonder how Scala, Clojure, and Frege (all > JVM functional languages) deal with it. ISTR it is to do with the lack of specific JVM instructions. There are plans to add new instructions like "invokedynamic" but they don't seem to get anywhere. (I'm out of touch on the specifics, and what has/hasn't been added) I suspect their importance is reduced by new features being added to Java that are claimed to give many of the advantages of functional programs. I haven't formed an opinion as to whether such additions are worth it, but fear they might enable people to write even more incomprehensible code. History shows that languages tend to start out simple, pure and comprehensible, but mutate into a less comprehensible mish-mash that attempts to be all things to all people. Java is not immune to those tendencies.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-05 08:38 +0000 |
| Message-ID | <QTgTz.2327542$SA.940694@fx44.am4> |
| In reply to | #25376 |
On 05/11/16 02:00, George Neuner wrote:
> 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++.
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.
> 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.
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.
That's very different in scope and objectives to the JVM.
> So it's true that Java arrived before C#. It's not true that JVM
> arrived before (what became) CLR.
Translation: something came before the JVM and turned
into something else after the JVM arrived. Shrug :)
Most things are an evolution of what went before,
and things are continually "repurposed" in the light
of changing environment. If you want to go down that
route, you'll need to consider Smalltalk, Oak, ANDF
and many other initiatives.
Java arrived and was remarkably usable very quickly.
Within six months of its arrival, I was able to buy
a library that instantly gave me interactive 2D and 3D
charts/graphs - something that C++ didn't manage in
10 years!
C# and the CLR came years later, not that that
is particularly important.
>> 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.
There are many different languages that compile
down to the JVM, with many different characteristics.
Many are commercially important.
>> 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#
That was primarily a business/marketing decision,
based on the need to support historic code (an MS
strength) and to claim ubiquitous applicability
(poor, very debatable).
Otherwise it is somewhat true, but the consequence is
that you explicitly destroy all the valuable
guarantees that the managed environment provides.
That's a bad tradeoff, IMNSHO.
>> 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.
Depends on the problem at hand. IMNSHO, in the
absence of any requirements and constraints,
Java is the best application language.
But people should always identify their
requirements and constraints and use a screw,
pop-rivet, nail, glue as appropriate.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2016-11-06 04:50 -0500 |
| Message-ID | <b0ut1c1vnro7chpr2qbt12fj2dueln8ona@4ax.com> |
| In reply to | #25382 |
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
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-11-06 19:49 +0200 |
| Message-ID | <e898puFfcnvU1@mid.individual.net> |
| In reply to | #25404 |
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
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-06 19:05 +0000 |
| Message-ID | <L9LTz.1075270$%E.435586@fx39.am4> |
| In reply to | #25404 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2016-11-06 19:52 +0100 |
| Message-ID | <e89cg5Fgaf2U1@mid.dfncis.de> |
| In reply to | #25349 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-06 11:10 -0800 |
| Message-ID | <87oa1sh1a9.fsf@nightsong.com> |
| In reply to | #25410 |
Hans-Bernhard Brö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.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-06 22:44 +0000 |
| Message-ID | <SmOTz.195927$BH.36835@fx27.am4> |
| In reply to | #25412 |
On 06/11/16 19:10, Paul Rubin wrote: > Hans-Bernhard Brö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. Oooh, that's /good/. And funny :) 1983 - Bjarne Stroustrup bolts everything he's ever heard of onto C to create C++. The resulting language is so complex that programs must be sent to the future to be compiled by the Skynet artificial intelligence. Build times suffer. Skynet's motives for performing the service remain unclear but spokespeople from the future say "there is nothing to be concerned about, baby," in an Austrian accented monotones. There is some speculation that Skynet is nothing more than a pretentious buffer overrun.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-06 19:12 +0000 |
| Message-ID | <_gLTz.2631165$3%1.1454156@fx40.am4> |
| In reply to | #25410 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-06 11:33 -0800 |
| Message-ID | <87k2cgh08s.fsf@nightsong.com> |
| In reply to | #25413 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-06 22:59 +0000 |
| Message-ID | <UAOTz.1075296$%E.7299@fx39.am4> |
| In reply to | #25414 |
On 06/11/16 19:33, Paul Rubin wrote: > 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. Just so. But the security model (the only "interesting" bit of Javacard) isn't specific to Javacard. ISTR there being other languages for programming smartcards. Aside: I'll _contend_ that the only useful thing that can be stored in a javacard is a magic number. When the card is used, that magic number is transmitted to a server, and a database defines the number allows. Corollary: there's no need for complex on-card logic.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-06 15:48 -0800 |
| Message-ID | <878tswgog0.fsf@nightsong.com> |
| In reply to | #25420 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > Aside: I'll _contend_ that the only useful thing that can be stored in > a javacard is a magic number. There are many javacard applications including pki tokens, payment cards, and a few billion phone sims. Most of them involve 2-way communication and crypto.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-07 07:45 +0000 |
| Message-ID | <liWTz.462116$4I.319786@fx24.am4> |
| In reply to | #25421 |
On 06/11/16 23:48, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> Aside: I'll _contend_ that the only useful thing that can be stored in >> a javacard is a magic number. > > There are many javacard applications including pki tokens, payment > cards, and a few billion phone sims. Most of them involve 2-way > communication and crypto. > Maybe, but what is stored on the card, and why is that essential?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-07 00:09 -0800 |
| Message-ID | <874m3jhft4.fsf@nightsong.com> |
| In reply to | #25424 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > Maybe, but what is stored on the card, and why is that essential? Typically user credentials including a cryptographic signing key. The key has to be encapsulated in the card so it can't be copied. It's instead used to sign a challenge presented by an external device. For example, smart cards are used to authenticate some cable TV set-top boxes. If you could duplicate a card, you could use the second one to watch cable shows without paying. There was a huge technical arms race between cable TV companies and cable pirates where pirates developed more and more sophisticated ways to copy cards, and card manufacturers designed progressively fancier countermeasures. Smart cards now have all kinds of obfuscation and tamper-resisting features to prevent extraction of the keys in the card.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-07 09:56 +0000 |
| Message-ID | <CdYTz.203778$dW4.29623@fx25.am4> |
| In reply to | #25426 |
On 07/11/16 08:09, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> Maybe, but what is stored on the card, and why is that essential? > > Typically user credentials including a cryptographic signing key. The > key has to be encapsulated in the card so it can't be copied. It's > instead used to sign a challenge presented by an external device. For > example, smart cards are used to authenticate some cable TV set-top > boxes. If you could duplicate a card, you could use the second one to > watch cable shows without paying. And that is /precisely/ the kind of magic number that I was thinking of when I wrote: On 06/11/16 22:59, Tom Gardner wrote: > Aside: I'll _contend_ that the only useful thing that > can be stored in a javacard is a magic number. When > the card is used, that magic number is transmitted > to a server, and a database defines the number allows. > Corollary: there's no need for complex on-card logic. Whether the server is local or remote is uninteresting in this context. /Neither/ requires sufficient on-chip logic to make Java worthwhile. The JavaCard app is so small that it would be easy to write in assembler! Any support environment implementation would only be written once, by the card manufacturer, and could be written in any convenient language. So yes, the security aspects of JavaCard are beneficial, but they are scarcely a killer advantage.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2016-11-07 18:38 +0100 |
| Message-ID | <e8bshgF45v0U1@mid.dfncis.de> |
| In reply to | #25429 |
Am 07.11.2016 um 10:56 schrieb Tom Gardner: > On 07/11/16 08:09, Paul Rubin wrote: >> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> Maybe, but what is stored on the card, and why is that essential? >> >> Typically user credentials including a cryptographic signing key. The >> key has to be encapsulated in the card so it can't be copied. It's >> instead used to sign a challenge presented by an external device. > And that is /precisely/ the kind of magic number that I > was thinking of when I wrote: No, it's not. The crucial difference being that the actual magic number is _never_ever_ transmitted to any server.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-07 19:17 +0000 |
| Message-ID | <yr4Uz.2382$gP.387@fx31.am4> |
| In reply to | #25433 |
On 07/11/16 17:38, Hans-Bernhard Bröker wrote: > Am 07.11.2016 um 10:56 schrieb Tom Gardner: >> On 07/11/16 08:09, Paul Rubin wrote: >>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>> Maybe, but what is stored on the card, and why is that essential? >>> >>> Typically user credentials including a cryptographic signing key. The >>> key has to be encapsulated in the card so it can't be copied. It's >>> instead used to sign a challenge presented by an external device. > >> And that is /precisely/ the kind of magic number that I >> was thinking of when I wrote: > > No, it's not. The crucial difference being that the actual magic number is > _never_ever_ transmitted to any server. True, but surely a different magic number (derived from the hidden magic number) /is/ transmitted. The derivation is not sufficiently complex to benefit from having Java in the card: either there is hardware assistance or it is highly optimised assembler. Which brings us back to the question of whether there is any processing in the card that is sufficiently complex to warrant Java or another OOP+libraries. On 06/11/16 22:59, Tom Gardner wrote: > Aside: I'll _contend_ that the only useful thing that > can be stored in a javacard is a magic number. When > the card is used, that magic number is transmitted > to a server, and a database defines the number allows. > Corollary: there's no need for complex on-card logic. Whether the server is local or remote is uninteresting in this context. /Neither/ requires sufficient on-chip logic to make Java worthwhile. The JavaCard app is so small that it would be easy to write in assembler! Any support environment implementation would only be written once, by the card manufacturer, and could be written in any convenient language. So yes, the security aspects of JavaCard are beneficial, but they are scarcely a killer advantage.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-07 21:29 -0800 |
| Message-ID | <87zilafsk2.fsf@nightsong.com> |
| In reply to | #25438 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > True, but surely a different magic number (derived from the hidden > magic number) /is/ transmitted. The derivation is not sufficiently > complex to benefit from having Java in the card: either there is > hardware assistance or it is highly optimised assembler. Wait, you were the guy saying C++ is dangerous and now you're saying to write critical security applications in assembler? :-O > sufficiently complex to warrant Java or another OOP+libraries. What does "sufficiently complex" mean? If I have to write a hello world program I have no trouble using C++ or some other huge language for it. Is C++ "warranted"? Probably not, but using it doesn't cost me anything, so what the hey. Similarly, Javacard is a fairly simple bytecode interpreter and virtual machine. The interpreter consumes some program rom on the chip, and there is some ram overhead for the applets and their data, but it's not that big a fraction of the chip cost. > The JavaCard app is so small that it would be easy to write in > assembler! Part of the Javacard vision (I don't know how much it caught on, but it gets at least some use) was to have multiple applications on the card, that can't access each other's data. Assembly code would be able to get at everything in the card instead of just that application's data. You need some kind of application sandboxing and the Java applet model works nicely for that. > Any support environment implementation would only be written once, by > the card manufacturer, That locks you in with that card manufacturer, while you can move your javacard code around between cards easily. > and could be written in any convenient language. You mean like Java? ;-)
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-08 08:07 +0000 |
| Message-ID | <5JfUz.11422$8o1.6940@fx14.am4> |
| In reply to | #25445 |
On 08/11/16 05:29, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> True, but surely a different magic number (derived from the hidden >> magic number) /is/ transmitted. The derivation is not sufficiently >> complex to benefit from having Java in the card: either there is >> hardware assistance or it is highly optimised assembler. > > Wait, you were the guy saying C++ is dangerous and now you're saying to > write critical security applications in assembler? :-O Please read what I wrote. I did not suggest writing the /application/ in assembler. Frequently the crypto routines are written in highly optimised assembler (even if that optimisation is done by tweaking the C and compiler flags, and examining the object code :) ) That's not a problem since all aspects of the algorithm are well defined and the algorithm itself is simple. Those characteristics mean writing the crypto routines in assembler is very tractable and often beneficial. Having said that, my suspicion is that the /applications/ on JavaCards are so simple that they /could/ be coded in assembler - but I wouldn't push that point. It could be easily countered by outlining an application that was /necessarily/ too complex for that to be reasonable. >> sufficiently complex to warrant Java or another OOP+libraries. > > What does "sufficiently complex" mean? If I have to write a hello world > program I have no trouble using C++ or some other huge language for it. > Is C++ "warranted"? Probably not, but using it doesn't cost me > anything, so what the hey. Sigh. Please use some common sense about what "sufficiently complex to warrant" might mean. Hint: a googling leads to the first definition of warrant as a verb: "justify or necessitate (a course of action)." >> The JavaCard app is so small that it would be easy to write in >> assembler! > > Part of the Javacard vision (I don't know how much it caught on, but it > gets at least some use) was to have multiple applications on the card, > that can't access each other's data. Assembly code would be able to get > at everything in the card instead of just that application's data. You > need some kind of application sandboxing and the Java applet model works > nicely for that. I agree with that assessment. I would be interested in whether there are any real-world cases of multiple applications for different corporations on the same JavaCard. Different corporations is necessary, if you think about it. >> Any support environment implementation would only be written once, by >> the card manufacturer, > > That locks you in with that card manufacturer, while you can move your > javacard code around between cards easily. Yes, in theory. I wonder how often that is a benefit, in practice. >> and could be written in any convenient language. > > You mean like Java? ;-) Yes, as one of several.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web