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 | 11 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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-05 15:48 +0000 |
| Message-ID | <RanTz.290608$EN.471@fx30.am4> |
| In reply to | #25387 |
On 05/11/16 12:40, asdf wrote: > In those contexts even C++ (which runs circles around C#/Java > performance wise) would be a suboptimal choice. Surprisingly to those that have a narrow knowledge of computing research and practice, that's wrong. The core problems are that: 1) lack of GC leads many programmers to be more defensive than is necessary in a managed environment. Typically that manifests itself as "unnecessary copies", which is a real problem since memory is usually the bottleneck nowadays. 2) C/C++ can only optimise what it /guesses/ will happen at runtime. HotSpot optimises what /actually/ happens. If you doubt the efficacy of that, consider the results of the 25 year old "Dynamo" results. The TL;DR is take optimised C running on processor X, then instrument what actually happens at runtime by running it inside a emulator of X running on X. Naturally that is slow. Then optimise the binary and run it inside the emulator of X running on X. Sometimes the *emulated* C binary code is *faster* than the *native* C binary. FFI, see http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html N.B. those that are /very/ interested in low predictable latencies use Java. The "high performance trading" mob are perfectly happy to spend $600m on laying their own trans-Atlantic fibreoptic cable, or buying up and using the old microwave links between Chicago and New York. Why? To shave a few *milliseconds* off the round trip time. They also like to cast the trading /algorithms/ and network stack in *hardware*, i.e. FPGAs. If Java was slow, it would be out the door in an instant; instead it is becoming the normal platform.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-05 11:41 -0700 |
| Message-ID | <8737j5ixb3.fsf@nightsong.com> |
| In reply to | #25389 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > 1) lack of GC leads many programmers to be more defensive than is > necessary in a managed environment. Typically that manifests itself as > "unnecessary copies", which is a real problem since memory is usually > the bottleneck nowadays. C++ avoids that pretty well these days, with move semantics and smart pointers introduced in C++11. If you haven't used it, give it a try. > 2) C/C++ can only optimise what it /guesses/ will happen at runtime. Serious compilers support profile-based optimization these days. > If Java was slow, it would be out the door in an instant; instead it > is becoming the normal platform. It seems to be going out of style in the past few years, though maybe mostly because of Oracle being annoying than technical issues.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-05 20:20 +0000 |
| Message-ID | <ApoTz.121696$%j.14946@fx32.am4> |
| In reply to | #25393 |
On 05/11/16 18:41, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> 1) lack of GC leads many programmers to be more defensive than is >> necessary in a managed environment. Typically that manifests itself as >> "unnecessary copies", which is a real problem since memory is usually >> the bottleneck nowadays. > > C++ avoids that pretty well these days, with move semantics and smart > pointers introduced in C++11. If you haven't used it, give it a try. "Pretty well" is like "only a little bit pregnant". >> 2) C/C++ can only optimise what it /guesses/ will happen at runtime. > > Serious compilers support profile-based optimization these days. I'm out of touch w.r.t. that. I wonder how effective is the support w.r.t Hotspot technology. For realtime embedded work, neither is particularly attractive, of course. And for hard realtime work, even hardware caches present significant problems! >> If Java was slow, it would be out the door in an instant; instead it >> is becoming the normal platform. > > It seems to be going out of style in the past few years, though maybe > mostly because of Oracle being annoying than technical issues. Hah! I'm not going to argue about Oracle; arguably they have worse behaviour than Microsoft ;} What appears to you to be "the new black"?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-05 19:14 -0700 |
| Message-ID | <87y40xgxs5.fsf@nightsong.com> |
| In reply to | #25395 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> C++ avoids that pretty well these days, with move semantics and smart >> pointers introduced in C++11. If you haven't used it, give it a try. > "Pretty well" is like "only a little bit pregnant". Well, it works pretty well in the sense that it gets rid of a lot of cases where you'd have to do it manually. You can of course always still do it manually like before, or you can use shared_ptr which is sort of a poor man's GC. There's also an idea in development for gc'd regions: https://github.com/hsutter/gcpp C++ itself has gc hooks in the language and (independently) the Boehm-Demers gc has been successful in various C and C++ applications. The idea of these systems languages though (C++, Rust, Ada) is to control resources precisely, which is in tension with the concept of gc. > What appears to you to be "the new black"? PenguinOfDoom (from irc #haskell) once said something like "being sophisticated gents, we classify programming languages into sucks and doesn't-suck, and put all of them in the first category". I've never been involved with realtime critical systems (only vicariously interested) but given enough budget I'd consider the commercial Adacore Spark/Ada stuff. I've fooled around a little with the free stuff but for a genuine critical system I'd want their support package. I don't currently understand where complex HRT software is actually needed. E.g. I don't know squat about the subject, but I imagine something like a flight control system being a fast PID jiggling some actuators towards a desired flight vector (this is critical HRT but fairly simple), wrapped in a slower control loop that adjusts the desired vector at maybe a few Hz, i.e. critical and complex, but non-HRT since it's ok if an update is late by some milliseconds now and then. Or the whole airplane would contain a monstrous amount of code (complex) but a lot of it would be stuff like in-flight entertainment (non-critical). There's a youtube video of Adacore founder Bob Dewar talking about the F-22 fighter software (written in Ada). He asked whether fighter plane software was safety-critical and the audience laughed. But then he explained that a passenger airliner is obviously safety-critical and so you have to run everything in a very conservative regime. But the purpose of a fighter is to go out and get shot at (unsafe by definition), and they emphasize performance over safety in other parts of the plane (unstable aerodynamics, driving engines to their limits, etc.) so maybe they should think of the software that way too. However, he says, they don't.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-11-05 20:15 +0200 |
| Message-ID | <n07s1clvcbdusvae3hd1s6btoaukr1ink8@4ax.com> |
| In reply to | #25387 |
On Sat, 5 Nov 2016 12:40:21 +0000 (UTC), asdf <asdf@nospam.com> wrote: >On Fri, 04 Nov 2016 13:12:57 +0000, 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. > >> ... > > >C# or Java (C# is essentially MS/Java) are not suitable for embedded >systems, and in a safety critical environment with very likely also >some realtime constraints, is the worst possible choice ever. >In those contexts even C++ (which runs circles around C#/Java >performance wise) would be a suboptimal choice. With truly safety critical systems (such as nuclear reactors), you throw in as much hardware as required, cost is absolutely not an issue. In this thread, there has been an attitude of claiming that a specific programming language would "solve" any programming safety issues. In practice, the worst errors are made in the design phase, typically written in plain (English) text. Noting that for safety critical projects, there is a _huge_ amount of paperwork done before any single line of a computer programming language line is actually written, For truly safety critical systems, the programming language used, is not really an issue. Even assembly language is quite acceptable due to the huge paper work.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2016-11-05 20:25 +0000 |
| Message-ID | <nfrTz.1462110$7k5.221913@fx38.am4> |
| In reply to | #25390 |
On 05/11/16 18:15, upsidedown@downunder.com wrote: > On Sat, 5 Nov 2016 12:40:21 +0000 (UTC), asdf <asdf@nospam.com> wrote: > >> On Fri, 04 Nov 2016 13:12:57 +0000, 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. >> >>> ... >> >> >> C# or Java (C# is essentially MS/Java) are not suitable for embedded >> systems, and in a safety critical environment with very likely also >> some realtime constraints, is the worst possible choice ever. >> In those contexts even C++ (which runs circles around C#/Java >> performance wise) would be a suboptimal choice. > > With truly safety critical systems (such as nuclear reactors), you > throw in as much hardware as required, cost is absolutely not an > issue. > > In this thread, there has been an attitude of claiming that a specific > programming language would "solve" any programming safety issues. In > practice, the worst errors are made in the design phase, typically > written in plain (English) text. > > Noting that for safety critical projects, there is a _huge_ amount of > paperwork done before any single line of a computer programming > language line is actually written, > > For truly safety critical systems, the programming language used, is > not really an issue. Even assembly language is quite acceptable due to > the huge paper work. While it is /necessary/ to choose the "right" language, it is not /sufficient/ to choose the right language. Anyone that thinks otherwise hasn't thought about the topic!
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-11-05 17:15 -0700 |
| Message-ID | <nvlsq3$hm6$1@dont-email.me> |
| In reply to | #25396 |
On 11/5/2016 1:25 PM, Tom Gardner wrote:
> On 05/11/16 18:15, upsidedown@downunder.com wrote:
>> For truly safety critical systems, the programming language used, is
>> not really an issue. Even assembly language is quite acceptable due to
>> the huge paper work.
>
> While it is /necessary/ to choose the "right" language,
> it is not /sufficient/ to choose the right language.
> Anyone that thinks otherwise hasn't thought about the
> topic!
I'd temper that further:
The right language *features* go a VERY long way towards
the success of meeting a particular requirement set.
(languages just represent particular feature *bindings*
with variations in syntactic sugar)
I.e., even the wrong set of language features doesn't *preclude*
success; it just makes it considerably more of an effort to
attain!
[toc] | [prev] | [next] | [standalone]
| From | Mike Perkins <spam@spam.com> |
|---|---|
| Date | 2016-11-05 21:04 +0000 |
| Message-ID | <nvlhhq$tcd$1@news2.open-news-network.org> |
| In reply to | #25342 |
On 04/11/2016 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 ?... Without knowing more of the architecture, it is not uncommon to have a mix of emmbedded MISRA C on one processor and a higher language for use as a GUI or other network processes on another. The key is to make sure the safety critical component is compact and well tested and can determine and react correctly to any fault, and possibly even restart the second CPU if it behaves incorrectly. In short I would like to know more about the system before passing judgement. If as you say the whole system, including any safety critical component, is written in C# then alarm bells would indeed be ringing. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
[toc] | [prev] | [next] | [standalone]
| From | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| Date | 2016-11-06 00:31 +0000 |
| Message-ID | <nvltlq$18pi$1@gioia.aioe.org> |
| In reply to | #25342 |
On 11/04/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. > I just wanted to thank you all for the replies on this. Tt just confirms the view here and should provide additional evidence for the meeting. Can't say more now, but will try to report back to group later next week... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | Dave Nadler <drn@nadler.com> |
|---|---|
| Date | 2016-11-05 18:11 -0700 |
| Message-ID | <8e3bf208-bba9-4a72-a39a-cc46fd2edf39@googlegroups.com> |
| In reply to | #25400 |
On Saturday, November 5, 2016 at 8:31:59 PM UTC-4, Chris wrote: > Can't say more now, but will try to report back to group later next week... Thanks Chris, Looking forward to hear how this went... Best Regards, Dave
[toc] | [prev] | [next] | [standalone]
| From | Luke A. Guest <laguest@archeia.com> |
|---|---|
| Date | 2016-11-30 12:43 +0000 |
| Message-ID | <31526885.502202488.560105.laguest-archeia.com@nntp.aioe.org> |
| In reply to | #25342 |
Chris <xxx.syseng.yyy@gfsys.co.uk> wrote: > > C# raises alarm bells here for all kinds of reasons, but what do you > think ?... Tell us which cars do we can avoid buying them 😎 Also, tell them to use Ada 2012, far superior.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.arch.embedded
csiph-web