Clearing up the FUD on CLI/Mono

newer
DHCP,DNS and hostname, Alphabet...

Steven T. Hatton

11 Nov 2005 11 Nov '05

19:23

There seems to be a misconception that the CLI, C#, and C++/CLI are owned by Microsoft. This is not, AFAIK, the case. These are ECMA standards. Among the contributors to these standardization efforts is Novell Inc. This site has some links to the official specs: http://www.dina.kvl.dk/~sestoft/ecma/ This site deals with C++/CLI, and is, AFAIK, funded by Novell: http://www.mono-project.com/CPlusPlus Steven

Show replies by date

Kai Ponte

12 Nov 12 Nov

17:56

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Friday 11 November 2005 11:23 am, Steven T. Hatton wrote:

...

There seems to be a misconception that the CLI, C#, and C++/CLI are owned by Microsoft. This is not, AFAIK, the case. These are ECMA standards. Among the contributors to these standardization efforts is Novell Inc. This site has some links to the official specs: http://www.dina.kvl.dk/~sestoft/ecma/

Yes, the C# and CLI were submitted to the ECMA back in '01 or '02, fairly soon after they announced .net. They hoped that someone like Miguel would come along and write a competing product to VS.net so that they could say it was an "open" standard. I'm actually using this information in my arguments at work as to why we should move from VB to C# (as opposed to moving to VB.NET). I have been patiently explaining that we could leverage the C# to run on our new mainframe (IBM z890) as back end or middleware while running C# clients on the desktops (mostly running Windows). -- kai www.perfectreign.com linux - genuine windows replacement part

Steven T. Hatton

18:30

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Saturday 12 November 2005 12:56 pm, Kai Ponte wrote:

...

Yes, the C# and CLI were submitted to the ECMA back in '01 or '02, fairly soon after they announced .net. They hoped that someone like Miguel would come along and write a competing product to VS.net so that they could say it was an "open" standard.

I'm actually using this information in my arguments at work as to why we should move from VB to C# (as opposed to moving to VB.NET). I have been patiently explaining that we could leverage the C# to run on our new mainframe (IBM z890) as back end or middleware while running C# clients on the desktops (mostly running Windows).

My brief exposure to Mono indicated to me that it's not yet all there. That was a few months back, but it's hard for me to believe they've made the kind of progress it would take to get it polished. Quite honestly, I'm not sure C# is the best thing going for the CLI. As much as I dislike the idea of corrupting C++ in spirit and form, I have the impression that C++/CLI may prove the better language. It's ironic that Microsoft is not touting this technology when a few years back they went out of their way to destroy the browser market for a company that had the lead in platform abstraction. http://www.mozilla.org/projects/nspr/reference/html/index.html Qt also provides some of the same functionality the CLI provides. One thing Qt has going for it is that it is already reasonably functional on Windows. That it is functional on Linux/Unix is axiomatic. There is even a port of the KDE to Windows. That's right folks! You CAN run the KDE on a Windows box. http://kde-cygwin.sourceforge.net/ Mind you, this is not the TrollTech official Windows Qt distribution. I find Qt quite nice to work with. It took me a bit of getting used to, but once I got the hang of it, I started to perceive the underlying unity of the toolkit. Not to say I'm an expert by any means. It's a lot simpler than Java. That means that sometimes I have to build things that Java would provide for me. OTOH, some of what Java provides is fairly difficult to figure out. For instance, their tables and trees. Steven

Steve Graegert

20:00

New subject: [SLE] Clearing up the FUD on CLI/Mono

On 11/12/05, Steven T. Hatton wrote:

...

On Saturday 12 November 2005 12:56 pm, Kai Ponte wrote:

...
Yes, the C# and CLI were submitted to the ECMA back in '01 or '02, fairly soon after they announced .net. They hoped that someone like Miguel would come along and write a competing product to VS.net so that they could say it was an "open" standard.

I'm actually using this information in my arguments at work as to why we should move from VB to C# (as opposed to moving to VB.NET). I have been patiently explaining that we could leverage the C# to run on our new mainframe (IBM z890) as back end or middleware while running C# clients on the desktops (mostly running Windows).

My brief exposure to Mono indicated to me that it's not yet all there. That was a few months back, but it's hard for me to believe they've made the kind of progress it would take to get it polished. Quite honestly, I'm not sure C# is the best thing going for the CLI. As much as I dislike the idea of corrupting C++ in spirit and form, I have the impression that C++/CLI may prove the better language.

What would be the rationale behind using C++ in .NET?

...

It's ironic that Microsoft is not touting this technology when a few years back they went out of their way to destroy the browser market for a company that had the lead in platform abstraction. http://www.mozilla.org/projects/nspr/reference/html/index.html

Don't see any parallelism here. Could you please elaborate on your thoughts.

...

Qt also provides some of the same functionality the CLI provides.

Really? What would that be? Are you talking about language bindings?

...

I find Qt quite nice to work with. It took me a bit of getting used to, but once I got the hang of it, I started to perceive the underlying unity of the toolkit. Not to say I'm an expert by any means. It's a lot simpler than Java. That means that sometimes I have to build things that Java would provide for me. OTOH, some of what Java provides is fairly difficult to figure out. For instance, their tables and trees.

Besides Windows Forms, which has a eliminated a lot of the Swing problems, Java is one of the most powerful and easy to use platforms for GUI development. While Qt and C++ can't compete in this discipline, speed of execution is unmatched, of course. IMHO, for development of native UNIX applications, C/C++ is still the one and only tool, although I prefer GTK+ over Qt, but that is another issue. \Steve

Kai Ponte

21:56

New subject: [SLE] Clearing up the FUD on CLI/Mono

I'll reply to both Steve and Steven. On Saturday 12 November 2005 12:00 pm, Steve Graegert wrote:

...

On 11/12/05, Steven T. Hatton wrote:

...
On Saturday 12 November 2005 12:56 pm, Kai Ponte wrote:

...
Yes, the C# and CLI were submitted to the ECMA back in '01 or '02, fairly soon after they announced .net. They hoped that someone like Miguel would come along and write a competing product to VS.net so that they could say it was an "open" standard.

I'm actually using this information in my arguments at work as to why we should move from VB to C# (as opposed to moving to VB.NET). I have been patiently explaining that we could leverage the C# to run on our new mainframe (IBM z890) as back end or middleware while running C# clients on the desktops (mostly running Windows).

My brief exposure to Mono indicated to me that it's not yet all there. That was a few months back, but it's hard for me to believe they've made the kind of progress it would take to get it polished. Quite honestly, I'm not sure C# is the best thing going for the CLI. As much as I dislike the idea of corrupting C++ in spirit and form, I have the impression that C++/CLI may prove the better language.

What would be the rationale behind using C++ in .NET?

AFAIK, there isn't one really. We've breached the idea of usin C++ in .net but realized quickly there's almost no value.

...

...
It's ironic that Microsoft is not touting this technology when a few years back they went out of their way to destroy the browser market for a company that had the lead in platform abstraction. http://www.mozilla.org/projects/nspr/reference/html/index.html

Don't see any parallelism here. Could you please elaborate on your thoughts.

Honestly never heard of NSPR. I somehow doubt that was the rationale for destroying Netscape's market share. IIRC, it was simply a matter of survival. If MS didn't have a browser that they couldn't dominate with then Sun, et. al. would grab more market share.

...

...
Qt also provides some of the same functionality the CLI provides.

Really? What would that be? Are you talking about language bindings?

I'd like to find out, too. I appreciate Qt and will make it my next language to use. I've never used C++ but will soon learn. I've moved from VB (since '93) to PHP and Java and am ready to take on either C# or C++. I really like the Qt and KDevelop interface designers. Once I finish my current Java project (donutmonster.com) I'll move onto a C++ learning project.

...

...
I find Qt quite nice to work with. It took me a bit of getting used to, but once I got the hang of it, I started to perceive the underlying unity of the toolkit. Not to say I'm an expert by any means. It's a lot simpler than Java. That means that sometimes I have to build things that Java would provide for me. OTOH, some of what Java provides is fairly difficult to figure out. For instance, their tables and trees.

Besides Windows Forms, which has a eliminated a lot of the Swing problems, Java is one of the most powerful and easy to use platforms for GUI development. While Qt and C++ can't compete in this discipline, speed of execution is unmatched, of course.

Powerful, yes. Easy, ha! :) I dunno. I'm still struggling with it. Of course, I've been lazy the past few years doing stuff without strong typing in PHP and ASP before that.

...

IMHO, for development of native UNIX applications, C/C++ is still the one and only tool, although I prefer GTK+ over Qt, but that is another issue.

Of course, I've yet to see a decent looking GTK+ app. LOL! -- kai www.perfectreign.com linux - genuine windows replacement part

Steven T. Hatton

13 Nov 13 Nov

00:01

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Saturday 12 November 2005 03:00 pm, Steve Graegert wrote:

...

What would be the rationale behind using C++ in .NET?

C++/CLI is an ECMA standardization effort.

...

...
It's ironic that Microsoft is not touting this technology when a few years back they went out of their way to destroy the browser market for a company that had the lead in platform abstraction. http://www.mozilla.org/projects/nspr/reference/html/index.html

Don't see any parallelism here. Could you please elaborate on your thoughts.

It's a platform abstraction layer. To some extent Mozilla - which is what the Netscape browser has always been called - provides a programming environment in which code can be run portably. At the time Microsoft dumped IE on the market to starve Netscape Communications of development capital the actual "(compile once) run anywhere" was implemented with Java, and JavaScript. But the ability to port C and C++ code between platforms, and the idea of a platform-independent component interface are very much like what the CLI provides.

...

...
Qt also provides some of the same functionality the CLI provides.

Really? What would that be? Are you talking about language bindings?

No. I'm talking about portability features, and more.

...

Besides Windows Forms, which has a eliminated a lot of the Swing problems, Java is one of the most powerful and easy to use platforms for GUI development. While Qt and C++ can't compete in this discipline, speed of execution is unmatched, of course.

I really can't agree with that. I find Qt very easy to work with. Then again over the past two years I read TC++PL, and several other books on C++ carefully.

...

IMHO, for development of native UNIX applications, C/C++ is still the one and only tool, although I prefer GTK+ over Qt, but that is another issue.

Gtk+ is not C++. Qt _is_ C++. Steven

Anders Johansson

00:20

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Sunday 13 November 2005 01:01, Steven T. Hatton wrote:

...

On Saturday 12 November 2005 03:00 pm, Steve Graegert wrote:

...
What would be the rationale behind using C++ in .NET?

C++/CLI is an ECMA standardization effort.

Don't stare yourself blind at standards. The main issue is patents FWIW, I consider c++ to be one of the worst languages ever to not be designed. java in many ways is what C++ wanted to be, and with gcj's ability to compile to native code, it isn't that bad at performance

Bruce Marshall

00:29

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Saturday 12 November 2005 07:22 pm, Anders Johansson wrote:

...

FWIW, I consider c++ to be one of the worst languages ever to not be designed.

Hoo-rah!!

Randall R Schulz

00:35

New subject: [SLE] Clearing up the FUD on CLI/Mono

Anders, On Saturday 12 November 2005 16:22, Anders Johansson wrote:

...

On Sunday 13 November 2005 01:01, Steven T. Hatton wrote:

...
On Saturday 12 November 2005 03:00 pm, Steve Graegert wrote:

...
What would be the rationale behind using C++ in .NET?

C++/CLI is an ECMA standardization effort.

Don't stare yourself blind at standards. The main issue is patents

FWIW, I consider c++ to be one of the worst languages ever to not be designed. java in many ways is what C++ wanted to be, and with gcj's ability to compile to native code, it isn't that bad at performance

I'd think you'd not be given to folklore about program efficiency. Static compilation to native code as gcj (or conventional C++) does it is _not_ the best way to optimize performance. Java's so-called JIT (it's really on-demand) native code compilation has optimization opportunities not available when only static program analysis is possible. For all practial purposes and for a sizeable majority of programs, Java is every bit as fast as C++ and what's more, the opportunities for optimization of C++ are more played-out than are those for Java, which is still improving its performance characteristics. Randall Schulz

Anders Johansson

00:59

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Sunday 13 November 2005 01:34, Randall R Schulz wrote:

...

I'd think you'd not be given to folklore about program efficiency. Static compilation to native code as gcj (or conventional C++) does it is _not_ the best way to optimize performance. Java's so-called JIT (it's really on-demand) native code compilation has optimization opportunities not available when only static program analysis is possible.

Well, gcc has more to offer than just static compilation, although the new stuff isn't really ready yet. But the profiling that you can do in later versions of gcc has a lot of the same characteristics as JIT I do know that a lot of the comments about java efficiency are exaggerated, but it does still have overhead when you run it in the JVM

...

For all practial purposes and for a sizeable majority of programs, Java is every bit as fast as C++ and what's more, the opportunities for optimization of C++ are more played-out than are those for Java, which is still improving its performance characteristics.

Well, that's a little backwards, since if it's possible to do in a java system it's certainly possible to do for C/C++, and you'd still have the overhead of the JVM I just think the gcj option to compile a native executable is pretty cool

Jerry Feldman

01:09

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Sun, 13 Nov 2005 02:01:28 +0100 Anders Johansson wrote:

...

On Sunday 13 November 2005 01:34, Randall R Schulz wrote:

...
I'd think you'd not be given to folklore about program efficiency. Static compilation to native code as gcj (or conventional C++) does it is _not_ the best way to optimize performance. Java's so-called JIT (it's really on-demand) native code compilation has optimization opportunities not available when only static program analysis is possible.

Well, gcc has more to offer than just static compilation, although the new stuff isn't really ready yet. But the profiling that you can do in later versions of gcc has a lot of the same characteristics as JIT There are other compilers who do much more aggressive optimizations, such as inter-procedure optimizations or dynamic optimizations.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Steven T. Hatton

01:45

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Saturday 12 November 2005 07:34 pm, Randall R Schulz wrote:

...

I'd think you'd not be given to folklore about program efficiency. Static compilation to native code as gcj (or conventional C++) does it is _not_ the best way to optimize performance. Java's so-called JIT (it's really on-demand) native code compilation has optimization opportunities not available when only static program analysis is possible.

I don't see how you can possibly achieve at runtime what a C++ compiler achieves. First of all, you have to have the JVM running. That, in itself is overhead. There is no Class object in C++. Templates don't exist at runtime. You can write C++ in such away that you have very few pointers, and thus very little indirection overhead. You simply cannot do that with Java. What a good C++ compiler produces from well written code is extremely lean.

...

For all practial purposes and for a sizeable majority of programs, Java is every bit as fast as C++ and what's more, the opportunities for optimization of C++ are more played-out than are those for Java, which is still improving its performance characteristics.

GCC 4's C++ compiler produces significantly faster compile code than previous versions. The new move semantics will continue to offer improvements. Furthermore, proper code design can have a profound impact on performance. Steven

Steven T. Hatton

01:18

New subject: [SLE] Clearing up the FUD on CLI/Mono

On Saturday 12 November 2005 07:22 pm, Anders Johansson wrote:

...

On Sunday 13 November 2005 01:01, Steven T. Hatton wrote:

...
On Saturday 12 November 2005 03:00 pm, Steve Graegert wrote:

...
What would be the rationale behind using C++ in .NET?

C++/CLI is an ECMA standardization effort.

Don't stare yourself blind at standards. The main issue is patents

FWIW, I consider c++ to be one of the worst languages ever to not be designed. java in many ways is what C++ wanted to be, and with gcj's ability to compile to native code, it isn't that bad at performance

I'll have to disagree with you. There are a few C features of C++ that Stroustrup says he would rather have foregone, but he states very clearly that Java is _not_ what he would have designed had it not been for C compatability. C++ is a very carefully designed language. It is not as easy to use as Java for a person who has not carefully studied it, but when you do learn C++, you can often express things very concisely and elegantly. Java's answer to memory leaks is garbage collection. C++'s answer is RAII. RAII requires you to think about what you are doing at a more fundamental level. That may take more work, but the end result is typically much better design. You may want to look at _The Design and Evolution of C++_, by Bjarne Stroustrup. Steven

Randall R Schulz

06:29

New subject: [SLE] Clearing up the FUD on CLI/Mono

Steven, On Saturday 12 November 2005 17:17, Steven T. Hatton wrote:

...

...

Java's answer to memory leaks is garbage collection. C++'s answer is RAII. RAII requires you to think about what you are doing at a more fundamental level. That may take more work, but the end result is typically much better design.

I love answers of the form: If you were just omnicient, it wouldn't be a problem. GC is not an answer to "leaks" (which are bugs), it's a system of automatic storage management. Storage management is ubitquitous in programming. It's incumbent upon a language runtime to provide good support for it. C++ says "I'll give you a built-in, uniform mechanism to dynamically allocate storage, but you're on your own for keeping track of every single allocation you make and if you don't give it back to me, your program will slowly suffocate or take over the host on which it's running." What kind of attitude is that for a language designer to take toward the users? C++ storage leaks are Murphy's Law in operation. The design of the system affords a failure mode, so the occurrence of that failure mode is predictable. Java designs the failure mode out at the language level, hence it does not occur. And just how does RAII and auto-pointers deal with cyclic structures?

...

You may want to look at _The Design and Evolution of C++_, by Bjarne Stroustrup.

Steven

Randall Schulz

Steve Graegert

12 Nov 12 Nov

19:42

New subject: [SLE] Clearing up the FUD on CLI/Mono

On 11/12/05, Kai Ponte wrote:

...

On Friday 11 November 2005 11:23 am, Steven T. Hatton wrote:

...
There seems to be a misconception that the CLI, C#, and C++/CLI are owned by Microsoft. This is not, AFAIK, the case. These are ECMA standards. Among the contributors to these standardization efforts is Novell Inc. This site has some links to the official specs: http://www.dina.kvl.dk/~sestoft/ecma/

Yes, the C# and CLI were submitted to the ECMA back in '01 or '02, fairly soon after they announced .net. They hoped that someone like Miguel would come along and write a competing product to VS.net so that they could say it was an "open" standard.

I'm actually using this information in my arguments at work as to why we should move from VB to C# (as opposed to moving to VB.NET). I have been patiently explaining that we could leverage the C# to run on our new mainframe (IBM z890) as back end or middleware while running C# clients on the desktops (mostly running Windows).

This is something we (the team I am working with) are currently evaluating. The Mono platform has proven to be quite stable and most of our server-side components (.NET Remoting, no COM/DCOM here) have successfully been ported to Mono running on a SuSE 9.2 system. Except for the applications relying on web services we are very optimistic to be able to offer some of our products by the end of Q2 2006 as an alternative to Windows based environments. \Steve

6746

Age (days ago)

6748

Last active (days ago)

List overview

Download

14 comments

7 participants

participants (7)

Anders Johansson
Bruce Marshall
Jerry Feldman
Kai Ponte
Randall R Schulz
Steve Graegert
Steven T. Hatton