C / C++ skills

You're just stupid or misinformed. C# and .NET are protected by patents. Sun does have ultimate control over the langauge but that's not a problem. They see it as their quest to ensure all Java versions remain compatible so vendors don't add extensions of their own.

Like I said, the patents make Mono virtually worthless and a complete waste of time. Parts are patented and the .NET API probably isn't open-source (a compiler without a library isn't much good). No corporation in its right mind will deploy Mono for fear of being sued by Microsoft.

I personally think that the complete C# / .NET circus is a complete waste of time and money but they're plenty of airheads in corporations who follow the pied piper Microsoft blindly. In the end, corporations which use open-source and Java will be spending a lot less money on their IT infrastructure and therfore make more profits than their .NET-using counterparts. Ergo, they die and open-source wins, it's a law of nature.

--
Posted via a free Usenet account from http://www.teranews.com

And there's nowhere to go to for C# / .NET as there are already over a billion mobile phones running Java already. Java has this market completely cornered and there's no way .NET can ever catch up, so they're not even going to try. Aside from that, any push of .NET would most likely be tied to some form of Windows Mobile, which is totally unacceptable for mobile phone manufacturers. And running .NET on top of Linux isn't something is likely to tackle anytime soon.

--
Posted via a free Usenet account from http://www.teranews.com

Well said, sir! And as I understand it, you can also run Mono on Windows.

I agree wholeheartedly. I think I introduced C# into this conversation by expressing the wish that someone would come up with a well-defined subset of it for use in embedded systems -- keep the clean syntax and semantics but cut away some of the higher-powered features.

I did not claim C# is good for small embedded systems as it stands.

That is why I like Pascal-like languages (including C#, which has C-like syntax but Pascal-like semantics).

C is better than assembly language, but not a lot better. Most of the unreliability of software as we know it is due to C, with its lack of bounds-checking, uninitialized pointers, etc.

Uh, mono?

Kelly

I disagree. Most of the unreliability of software is down to poor design and poor coding. Don't blame the tool; blame the workman.

I'm not a fan of languages that provide me with a nappy whether I want one or not. My ideal language is neutral and expressive; C suits me fine. And even the most nappy-laden language would still produce buggy code when driven by a sloppy coder.

(That's not to say that the principles of defensive programming could not be better implemented in a future language. But, fundamentally, defensive programming is a Good Thing in any language.)

Steve

Nope! Put up or shut up - just cite a patent number to prove your point.

But then you might also consider ECMA standard 334 (C#) and 335 (CLI). The standards are free, and the use of the standards is free. Any company or individual is completly free to build and sell products conforming to the standards without any kind of permission or royalties.

Do you need Microsoft to certify that your compiler works - nope, that's none of their business. It's between a compiler maker and their customers to determine if they did a good job. If anyone wants to pay a fee to a third party company to certify their work that's up to them, but you can't pay Microsoft to do that. Keep your money.

The only protected aspects of .net are the ones not covered by these open standards. Both the C# language and the core .NET runtime are completely open and free.

They're happy to charge a fee to prove compliance. and they also like the royalties. The words "open standard" are nowhere to be found in Sun's Java vocabulary.

Eric

It was in 1977 :-)

The forum doesn't look very active but I'll give it a go when I get a minute.

Careful, it might have been you! I'll have to wait for the boss to come back from his holiday before I can find out where it came from.

It could do with a better section on it in the manual really. I'm sure I'm not the first person to have problems with this.

There have been several attempts made in the last decade to bring a subset of C++ into the embedded world.

Embedded C++ lacked:

? Templates ? Multiple inheritance ? Exception handling ? Runtime type information ? New cast syntax ? Namespaces

EC++ was offered by several embedded tools vendors

There are a lot of reasons why I think that EC++ failed to become a wide spread development language of choice.

1) Wrong subset mix 2) Cost of development and maintenance makes very good implementations of EC++ expensive in a cost sensitive world. 3) Creation of a new language in a language weary development community. (Why not full C++ My favourite feature is ... ) 4) It wasn't from lack of promotion

We did a technical study that showed that efficient C++ on embedded systems was possible. We did a marketing study that showed us that it was unlikely that we could recover the development costs.

w..

mc wrote:

Yes, but C is a culture as well as a language.

I agree. And any language should make it easier to program safely than to program unsafely.

...

Well said. Thanks for confirming the ECMA standard and the openness. If there are patents, presumably they apply to Microsoft's implementation. Are there patents?

It is? That's not really something I've come across. Perhaps I'm missing your point.

Yes and no. Yes, in the sense that the language shouldn't encourage gotchas (in the sense that C++ does, for instance). No, in the sense that I actively don't want things like bounds-checking in my runtimes. I need the compiler to trust me to have done a good job - it should by all means provide all the warnings and Lint-like sanity checks, but it shouldn't presume I need a nappy.

This conversation (and another elsewhere) has got me checking first principles. Broadly, I'm in the Dijkstra camp - I'm not a fan of exceptions, for instance, and they tend (I'm generalising) to encourage dependence on the language, rather than on good design.

As I've said many times before, I separate design from coding. What I need mostly from a language is a means of implementing my coding in a readable, maintainable, and efficient manner. I don't need it to be second-guessing my design.

Having said all that, software *design* is, generally, pretty poor throughout the software engineering field. I frequently have to deal with legacy and/or third-party code, and I often despair... So, failing good design, I would have to agree that a better language helps - for instance BBC-Basic (structured Basic) was a HUGE improvement on classic (e.g. GW-) Basic. But I'd much prefer good design to be better understood and promoted. In this sense, I worry that a nappy-laden language actually reduces the need for good design, IYSWIM.

Steve

Agreed. I've used Delphi since version 1, and TP before that. I've also done a lot of C, mostly with unix and embedded projects. In general you need to spend more time debugging C code, and by a wide margin in some cases.

We don't have a good version of .NET to target small embedded MCUs yet. There was a company making a CLR for embedded targets but they went under because their pricing model wasn't attractive for small companies

There's also an open source CLR for the H8 as used in the first Lego robotics set, but that's pretty weak.

I was thinking of making a CLR for embedded devices, where the JIT would be done on the PC to target the MCU. I'd also consider using static memory allocation, since the small targets I have in mind don't lend themselves well to a background thread or process that manages memory. In many cases with embedded OOP you end up with static classes, instead of instances, since instances aren't needed for simple control applications, and this greatly simplifies memory management. You only allocate static classes once, and you never need to de-allocate them.

I think of C as being mostly a portable assembly language. And that's a good thing when you need to get close to the hardware. C's pointers are both it's best feature and it's worst feature. That's one reason why lint programs are so helpful.

C# allows strongly typed references, which are akin to pointers. And unlike the Java Virtual Machine, the .NET CLR supports the concept to dereferencing pointers, making it suitable as a C target. An embedded CLR could support both C# and C.

Eric

C++ into the embedded world.

[Snipped]

possible.

recover the development costs.

What about D ? This is apparently also an attempt to "fix" C++. There is a GNU D

package, so it would probably already be usable for small 32-bit MCUs.

Regards Anton Erasmus

True, but unfortunately most of the workmen are imperfect creatures. When I was younger I used to claim that my C code was better than other people's C code, but I got embarrased too many times, and that contributed to my gray hair and my currently humble demeanor :-)

Really good Trapeze artists don't need a net, but then, they also don't live as long as the worse Trapeze artists who know they need a net.

Eric

...

That's the culture: "I'm an expert driver so I can ride the motorcycle without a helmet."

...

I like the idea of a small-system CLR and I agree that C is a portable assembly language (and use it as such). I consider it to be a considerably lower-level language than Pascal, for instance.