The Common Language Infrastructure (CLI) is the ECMA standard that describes the core of the .NET Framework world. The Shared Source CLI is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification. This implementation builds and runs on Windows XP, the FreeBSD operating system, and Mac OS X 10.2. It is released under a shared source initiative.
Shared Source CLI 1.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
77 Comments
2002-11-06 11:45 pm
2002-11-07 2:15 am
2002-11-07 3:04 am
2002-11-07 5:07 am
2002-11-07 6:04 am
2002-11-07 6:43 am
2002-11-07 8:44 am
2002-11-07 10:34 am
2002-11-07 10:53 am
Anonymous
@ Solar:
“My point is that your claim of Microsoft dominance of the desktop diminishing because alternatives gain popularity is not true.”
If lots of people start using other OSs, MS domination on the desktop will diminish. I think in this way.
“The Java hype is almost over. Linux job openings were rare two years ago, and close to non-existent today. When I look at job openings today, I see C# and .NET liberately splattered all over them.”
I do not think in this way. At least, what I see here is that only the firms already have MS based systems are moving to .NET. Some of them are moving to J2EE world. Here for instance, Java and Linux based jobs boomed in the last two years.
“.NET is a Java killer and the browser war reiterated in one.”
.NET cannot be a Java killer, since there are people and firms who won’t use .NET, just because it is from MS. I know a lot of people around here thinking in that way. For instance, I am planning to have my own company next year, not big, 50 developers maybe, and will not have any Windows computers. Maybe one for testing. I will use Linux / MacOSX and Java.
@ Mauerj:
> You are right that Java is the only real cross platform language, “give me a break. Was Mozilla written in Java? Linux? the BSDs?”
First of all, we were talking about VM based environments, second, using Java is much efficient than using C/C++ IN CERTAIN CASES, and leads to much faster implementation. “C/C++ and Java” is not “apples to apples”.
> “If you are writing an app in .NET targeted for a particular OS and you want people to actually use it, you probably should use an API that provides a native UI specifically for that OS. Targeting Linux? Use GTK#. Targeting Windows? Use Windows Forms. Targeting both? Use both.”
OK, tell me the point which makes lots of Linux users excited is true or not. MS has an .NET application written for Windows.Forms. Can you run it on Linux? If MS changes .NET and does not give extensions to ECMA, will you be able to run new .NET applications on MacOSX?
> “You can provide a native look and feel for each OS without giving up your choice of language as you would with Java.”
This is funny. Language of choice makes sense in the case that the languages that you are talking about are radically different. .NET languages are the same language with different syntax.
@ Anonymous Poster:
> So I accept that .NET’s byte code is prepared in a more language generic way, but actually, it is .NET’s biggest disadventage at the same time. It is not possible to create a byte code format which can handle every language, simply because there are many different type of languages. In order to “fit” these languages into CLI, these languages are changed, in my opinion, crippled. “Oh really now? Please explain why this “impossibility” would apply byte coded virtual machine and not any programmable machine? Are they not equivalent in function? So you mean that there is some class of program that is impossible to express in a byte coded environment? It certainly is possible but is worth the effort?”
Basically, it is too complex to create a byte coded virtual machine which would handle all the languages. It is certainly possible, and means creating a HUGE virtual programmable machine and creating emulator for it on all the known platforms. This is hard to do and not efficient approach from many perspectives. Anyway, do you think .NET VM is that? If so, answer my question: DO YOU THINK THAT I MAY NOT FIND A LANGUAGE WHICH IS NOT POSSIBLE TO TURN INTO .NET LANGUAGE? If you prove that .NET is capable of implementing all the languages, I say yes, this is IT. If you say that I can find some, this means it is not possible to fit all the languages into .NET, hence, .NET implementation of the language is crippled to fit into .NET.
>They are not the original languages anymore. COBOL.NET for instance, is NOT COBOL. “This might relate more to the particular implementation of COBOL.NET and not the CLI itself. For instance the SML.NET implementation is 99.9% compatible with SML’97 ( http://www.cl.cam.ac.uk/ Research/TSG/SMLNET/ ) which is an anecdotal proving my point 
.”
99.9% is not 100%. Show me a COBOL implementation for .net which is 100% COBOL.
>Actually, .NET has only one language, and it is CL (Common Language). All the .NET languages are different syntactical flavors of CL. All are restricted by the offered capabilities of CL. “They are only restricted as regards to the way they can interoperate with other languages. There is no restriction of how a language operate internally but they cannot rely on these features being available in other .NET clients.”
There are restirictions on languages regards to the way they can interoperate with other languages? Oh, its true. “There is no restriction of how a language operate internally?” So you mean that I cannot find a language which can not be implemented in .NET again? Interoperability between languages also have lots of restrictions. Look, we are not talking about possibilities here. I examined .NET languages. SIMPLY DEAR, THEY ARE CRIPPLED. Its all. Another point is that, it was not my point. CL is not a language of ALL the other possible languages. It is pure and simple fact I guess. It is an abstaction, and has limits. All the .NET languages DO have the LIMITS that CL has. This is all.
>It is also possible to implement different languages on top of JVM, and there are 200 or so already implemented. But, Sun for instance, do not promote it, since using one common language makes sense. “Could you please provide some linkage listing these 200 languages? ”
Here : http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html
>”I think writing different parts of the same application in different languages is a very, very, very bad idea. Ever heard of tower of Babylon? It will lead to a horrible maintenance nightmare, and productivity will lower significantly.” Will it? Well hate to dissappoint but I have been interoperating different languages in the same system on many occations without it putting big hurdles in the way. The only problem is that I am usually restricted to a feature set that can be described (if I am lucky) by C. With .NET this restriction is limited by the CLI which, you must agree with, is a far more capable than the C language and it’s library conventions.
Hate to dissapoint? Don’t worry, you did not! I’m not gonna forget my nightmarish experiences with projects spanned to couple of languages just because you say you have been doing it merrily. It is your opinion. Anybody who has managed a large project would know what I am talking about. Do you suggest that you can much more easily manage and maintain a project written in 3 languages THAN the same project written in one language? Actually, please do not make me remember the nightmarish projects in which I had to extend systems written with part VS VB and part VS C++.
>You are right in thinking that different problems may be handled better in different languages, but this do not apply to .NET, since all the .NET languages are really the same language with different syntax. “Yet again, they only need to maintain “compatibility” with the .NET conventions if they are meant to be used by other .NET languages. If they are strictly internal nothing is stopping me from using some language specific feature.”
Stop changing the subject. The question here is: Can you implement EVERY LANGUAGE CREATED ON THE WORLD WITH .NET “AS THEY ARE” or “NOT”?
2002-11-07 10:54 am
Anonymous
@ Will:
“The real power of .NETs CLI is the not so much that you would be able to write your program in multiple languages, but that you’ll be able to use more modules and libraries written in other languages. The CLI interface is much richer than the .DLL, and also a bit more granular than COM objects.
So, no, it’s not really smart to write your own project in N different languages, but now it’s a lot more probably that someone will write a library in SML.NET that will be easily integrated into a VB.NET program.
This was, of course, possible before, but now it’s just even easier to do.”
We Java community did never had such a problem. 
We have only one language. For lower level bindings, we use JNI if we have to.
@RevAaron:
“There are many languages that exist on the JVM and many that are for .NET and the CLI. However, there exists one major difference between the JVM and .NET in this respect: on .NET you have transparent inter-op between languages, and on the JVM, most of these languages are in their own little world. In .NET, I could write a new app in Smalltalk. I could call methods written in VB, make new classes with the superclasses being originally written in Perl (whose superclass is in turn C#). On the JVM, most of the languages that run on it can subclass Java classes and call Java functions and methods, but that’s about it. I can’t use Kawa to extend a project and subclass classes written in Jython. To be able to connect Kawa and Jython, I’d have to write a bunch of code on both sides, in Scheme and Python. It’d end up being almost as much work as doing the same thing on a non-JVM based system, the real hardware.”
First, in .NET you cannot write a new app in Smalltalk, because it will be Smalltalk.NET, which is not Smalltalk. You can not make new classes with the superclasses being originally written in Perl, since it is Perl.NET etc. Anyway, in Java world, there are no problems like that since we have only one language. There are also options like JPython etc.
“Unlike on .NET, most language implementations exist on the JVM as either a) toys; b) experimental research (the JVM is a passable platform for CS researchers); or c) for scripting Java, as a means of pulling away from annoying development cycle, syntax, or other shortcomings of Java.”
Go figure.
“The JVM was designed to run Java. It’s incidental that other languages can be coerced into running on it. On the other hand, the CLR was designed (albeit by Microsoft) to accomodate the running and inter-op of many languages. That’s not to say that the CLR doesn’t have plenty of flaws, but at least Microsoft is pointed in the right direction, with room to grow or fix the problems with the CLR- more than can be said of Sun’s Java.”
Yes, CLR was designed (albeit by Microsoft) to accomodate the running and inter-op of many languages, but it is also a disadvantage. MS’s approach has room to grow or fix the problems? Where do you know? How can you be so sure? Are you taking MS history as example? As happened with other MS products? )
Oh! I have to work!
2002-11-07 11:44 am
2002-11-07 12:36 pm
2002-11-07 1:02 pm
2002-11-07 4:34 pm
2002-11-07 4:40 pm
2002-11-07 4:41 pm
2002-11-07 5:18 pm
2002-11-07 5:19 pm
2002-11-07 5:49 pm
2002-11-07 6:21 pm
2002-11-07 7:34 pm
2002-11-07 8:24 pm
Anonymous
@ mauerj
Just when I thought you knew something, you proved me wrong. I honestly do not know why I even reply to your false information. Lets see, where to start…
Lets see here, truely compiled programs are converted from ASM to pure binary, 1’s and 0’s. Or converted from whatever language to pure binary. Does .NET do this? No. VB? No. Oh wait?? It’s MSIL!! Wow! Anybody can read that. How nice. Its like anybody can read ASM, the difference is that ASM actually compiles into a real binary. IL is just intepreted… You “think” you have a grasp here? No.
I could of sworn #D had a debugger.. ok, I was wrong 
JIT compiling pretty much means squat. It still requires the framework to run… which is a just a fricken huge glorified runtime library. It makes VB6’s runtime look like a baby. i-n-t-e-r-p-r-e-t-e-d.
I dont really care about Java much. Never had a use for it, so I believe you on the Java end
Keep them coming..
2002-11-07 9:02 pm
2002-11-07 9:39 pm
2002-11-08 2:49 am
2002-11-08 6:28 am
2002-11-08 8:42 am
2002-11-08 9:38 am
2002-11-08 4:34 pm
Anonymous
> VS.NET doesn’t even have Refactoring support.
Given a choice between the two, I would much rather have VS.NET’s debugging than some glorified Find & Replace.
> It is bloated and slow,
I disagree.
> and comes with a huge price tag.
You get what you pay for.
> I will only say, .NET does not have Perl,
> Eiffel, and COBOL. It has Perl.NET, Eiffel.NET, and
> COBOL.NET.
And your point is… ?
Let’s pick on Eiffel since they are the wierdest in my opinion. Someone writing an app in Eiffel.NET has all the language features they would in “normal” Eiffel, like multiple inheritence, design by contract, etc. It’s an example of a very non-C# (or non-VB) language that the CLR supports just fine.
> You can also find compilers for these languages for the
> Java VM.
Where? The languages I mentioned are all supported commercial products. Eiffel Software isn’t offering Eiffel for Java VM; Fujitsu isn’t selling COBOL for Java VM; ActiveState has no Perl for Java VM…
> Where do you know that oh-the-great-language-of-the
> future will fit into .NET CLI?
Well, I’ve seen it. I’d tell you about it but then I’d have to kill you.
> No VM is generic enough to host all different type of
> languages.
Then how would a real machine do it?
2002-11-08 4:57 pm
2002-11-08 4:59 pm
2002-11-08 5:53 pm
Wow – there are a lot of libraries missing from the CLI, which is in the .NET framework!
I hopw that people now realize why the .NET framework will never become crossplatform, when so little is in the standards…
Whaw…support for Mac OS X 10.2 !! That’s neat.
Dude nobody is stopping Mono or DotGNU (or whoever is creating C#/CLI implementations) to include the missing bits from the CLI into their implementation: aka ADO.NET, ASP.NET, System.Windows.Forms etc. Heck….Mono is doing that.
I wouldn’t be too surprised if the next version of Office is coded in .NET, and that the .NET framework by then is ported to MacOS X. Just a thought.
1 – Trademark issues (Windows, ADO, ASP, .NET, Microsoft.VisualBasic Namespace, etc)
2 – System.Data.SqlClient is a client for SqlServer 7.0 – they *cannot* recreate it, they can fake it using odbc or reverseengineer it – but in any event, it will most likely not perform *exactly* as the Microsoft one
3 – uhmm lots more, I just can’t remember
look, I am not flaming – I am just having some serious concerns with Microsofts definition of crossplatform…
CLI *is* crossplatform, as shown by the 3 platforms implemented on by Microsoft. But .NET just isn’t and will never be, since the Mono project will always be lagging behind…
But I thought OSS was bad and less secure than commerial closed source software?
At least MS pretend they have competition now.
I tried to find the actual liecense on the site, but failed, anyone know if there is anything to stop compiling this on an unsupported platform for personal use?
“I wouldn’t be too surprised if the next version of Office is coded in .NET, and that the .NET framework by then is ported to MacOS X. Just a thought.”
Office 11 will not be coded in .NET for various reasons (but AFAIK it will include APIs for managed code). The most importend one: porting and testing the HUGE code base would cost many many years.
I think this is a step in the right direction for MS – I’m also impressed how sample code is included for using other GUI toolkits…
I like C#, its a nice language. Hopefully we can see powerful C# GUI apps on platforms other than Windows soon
If you really want the full dotnet on other platforms you better help it happen. Coding or financing is a good start
Oh please, come on. Microsoft is releasing just enough of their technology that Mono et al. take the bait, so the Linux people can get hooked on C# and CLI.
The really juicy stuff (Passport…) is withheld, so that to get the “full XPerience”, you need Windows.
That scheme might not work for informed geeks, but it sure as hell increases the value of Windows as “comfort zone” and the reputation of Linux to be “second best” if you want to communicate with the rest of the world.
TCPA et al. will then do the rest.
The nice thing about it is, US Court just recently displayed they are not interested in stopping Microsoft, and who else could?
Linux? With Mono, Linux will be just another CLI platform sans the means to offer the “full XPerience”. Smell the fish, you are being hooked.
{I don’t consider this post to change anything.}
Unlike, say, Java Swing, System.Windows.Forms and other parts of the .NET library are closely tied to the Windows API. That means that other operating systems that recreate it will have to recreate much of the API, too. For this reason, the Mono project has decided to implement System.Windows.Forms using the WINE libraries. So what you will get when you compile your C# application from Windows on Linux is the combination of a cloned C# JIT compiler, a cloned MS class library and a cloned MS API. Doesn’t sound like a very stable working environment to me, but we’ll see. Non-graphical apps should work much better.
At least it’s also possible to develop Mono apps using GTK#.
Hi there,
if I follow the link, I come to a MSDN-Downloadpage. If I click on Software-Development there is only the beta of CLI available which runs with FreeBSD but not with MacOSX.
So what is the correct link, or did the archive dissapeared as suddenly as it came?
Greeting from Anton
Mono project will always lag behind minimum 1/2 years. They are not able to implement all the .NET anyways. There are reasons for it:
Windows.forms is based on Win32. It is very hard to implement it on other platforms, moreover, MS has patent rights on it and some other important parts of .NET. They would never let it go cross platform. I am working with MS consulters here, and even they confirm that it will not be cross platform.
Moreover, MS has already extending .NET, and nobody knows if they will give the further extensions to the framework to ECMA. This is a very clever trick: In this way, the programs written on Linux for .NET may work on Windows, but the programs written on Windows with the new version of the .NET cannot run on Linux. Nice eh? But I am sure that Miguel de Icaza already thought about this.
Moreover, .NET has many classes related with their world domination plan’s part called Passport. Which is also illegal to implement.
MS is letting Mono right now, since it is currently helping them against Java. They can say .NET is cross platform. If something serious happens on Linux related with .NET, MS will act immediately.
Free BSD version for instance, legally can be used only for education purposes, and it is again not complete .NET.
Mac version? Just another hoax.
The only cross platform option based on VM that can be used today is Java. It started to shine even on client-side, for instance http://www.eclipse.org
Mono project or DotGnu project try to give Linux plateform and other Open Source plateform a great implementation of .NET.
By looking at their websites (http://www.go-mono.com) (http://www.dotgnu.org/) project are going well…
But has anyone has a test experience with them ?
Is there any test articles, I should read ?
What will be the main use of .Net : Server apps (like J2EE) or Client Apps for Windows (like applets, activeX etc…) ?
I downloaded the whole file
15736461 Nov 6 12:50 sscli_20021101.tgz
But their tarball is corrupted (typically microsoft)
> tar xzvf sscli_20021101.tgz
[snip]
tar: Skipping to next file header…
gzip: stdin: invalid compressed data–crc error
tar: child returned status 1
> gunzip sscli_20021101.tgz
gunzip: sscli_20021101.tgz: invalid compressed data–crc error
Microsoft really is corrupted!
You are right that Java is the only real cross platform language, but Eclipse is not 100% pure java. Eclipse uses SWT, a widget library that is native. It’s build quite nicly and is available on a lot of platforms but it is not Java. I am a big Eclipse fan because of it; it makes client-side Java doable…
isnt cli the amiga command prompt?
>isnt cli the amiga command prompt?
That too – Command Line Interface
Eclipse’s SWT is a GUI library. You cannot say Eclipse is not Java because of SWT uses native widgets. It is one way of doing it. Why do you think there are different JVM implementations for different platforms? Eclipse is fully written in Java. It is a Java program.
Some browsers have a nasty habit of uncompressing gzipped tarballs during download. Have you run the ‘file’ command against the tarball to make sure it’s actually compressed?
Just because things doesn’t come out of Sun does not mean it is not “pure” java.
Like SWT, AWT also uses naitive bindings below the framework.
JFace/SWT and Swing/AWT as pretty much the same thing. The only difference is that that the naitive to Java ratio is more on the naitive side for SWT.
The Java client side world is pretty open. It seems that Sun is working hard on optimizing Swing in the newest JDK version. That explains why Swing applications crash with the newest JDK and un-updated graphics drivers.
The Eclipse approach is comming on fast, but still has the disadvantage that it is not so well understood by developers who had 5 years learning the Swing framework.
But altogether I belive that .NET will replace MFC/VB and M$ will keep ruling the desktop for a long time to come.
/Lazlo
“That explains why Swing applications crash with the newest JDK and un-updated graphics drivers.”
What Swing applications crash with the newest API? Actually, I found the Swing performance and stability the best ever reached in the latest JVM version.
“The Eclipse approach is comming on fast, but still has the disadvantage that it is not so well understood by developers who had 5 years learning the Swing framework.”
This is not true at all, since SWT is pretty easy to learn. As a proof, you can check out the plug-ins implemented for Eclipse. There are more than 150 plug-ins already developed by coorporations + open source organizations + individuals.
http://eclipse-plugins.2y.net/eclipse/index.jsp
I also agree that .NET will replace MFC/VB, especially in the coorporations already deep in MS shit. For the new comers, there are options like Linux.
The desktop will be ruled by MS for some more time, but it also will change in the future, since alternative operating systems such as Linux started to gain popularity especially in the last 2 years, and the hw/sw firms started to invest in it.
The adoption of alternative OSs will also bring anourmous importance to environments capable of producing cross platform compatible programs. They were not very much important in the past, since everything was Windows basically, thus creating Windows client programs were the most valuable skills in the job listings. This is not the case now. Cross platform compatibility is becoming more and more important. This is why Java and Linux are powerful together. They form a perfect synnergy which MS afraids of so much.
@ Hauser:
> Mono project or DotGnu project try to give Linux
> plateform and other Open Source plateform a great
> implementation of .NET.
They try to give a *partial* implementation of .NET. As croanon correctly observed: Mono allows to write .NET applications on Linux that will run on Windows. It will *not* make sure that .NET applications written on Windows will run on Linux, unless the implementors specifically tested against Mono.
Who wins? Microsoft. (Don’t you see it? That’s just another case of J++, only the other way round.)
Then on the other hand there’s Richard Stallman trying to dissuade using UDI (Uniform Driver Interface) on Linux because it would allow Windows to benefit from drivers written by the Open Source community… while *that* would be something that would *really* benefit the alternative OS’ scene…
(I am not at all surprised that Microsoft tried to pull it off, and not much surprised that someone – Mono – fell into the trap. What actually *does* surprise me is the number of people actually cheering to it. But then, I was surprised by the cheer about the AmigaOS 4 PPC too… Now please *don’t* flame me on that Amiga statement. 😉 )
@ croanon:
> The desktop will be ruled by MS for some more time, but
> it also will change in the future, since alternative
> operating systems such as Linux started to gain
> popularity especially in the last 2 years, and the
> hw/sw firms started to invest in it.
Erm, care to name alternative operating systems *aside* from Linux (and it’s close *BSD relatives) that gained popularity, with hw/sw firms starting to invest?
Personally, I am standing outside of *both* the Windows *and* the Linux camp. I am interested in creating a *really* alternative OS. Guess what? The FSF/GNU gives me just as much of a headache as Microsoft.
I could elaborate, but I see Eugenia cracking the whip already… *ouch* {ducks} *ouch*… 😉
Not sure I agree with your argument completely.
One of the purpose of Mono is “to create a powerful foundation for many languages to inter-operate.” – See their FAQ @ “http://www.go-mono.com/faq.html#msft“. So even if Microsoft changes their stuff as a pure Linux development tool Mono would still be useful.
Setting the GUI issue aside for a moment, for me (as a Windows developer) there is STILL a compelling reason to consider Mono – ASP.NET. I am very excited about the prospect of developing my web apps in Windows and being able to port them to Linux/Apache.
Just my 2 cents worth..
> The desktop will be ruled by MS for some more time, but
> it also will change in the future, since alternative
> operating systems such as Linux started to gain
> popularity especially in the last 2 years, and the
> hw/sw firms started to invest in it.
“Erm, care to name alternative operating systems *aside* from Linux (and it’s close *BSD relatives) that gained popularity, with hw/sw firms starting to invest?”
I meant mainly Linux, BSD and MacOSX.
They are gaining popularity very fast. Now you can see many people are choosing Linux as their default OS, and lots of people are buying Macs thanks to Apple’s great HW designs and SW quality. Compare how many Linux users were there 5 years ago and how many Linux users are there now. The shift is not linear, but exponential. After 5 years, Linux will have a very important position in the IT world. Actually, it already has on the business front. But after 5 years, I think we will start seing lots of commercial Linux programs for home usage on the shelves, which is not possible today apart from couple of exceptions.
This is why I am saying cross platform compatibility and Java is important. Take it from whatever perspective, Java is the only option in creating cross platform systems, and it is working quite well.
@erktrek:
“One of the purpose of Mono is “to create a powerful foundation for many languages to inter-operate.” – See their FAQ @ “http://www.go-mono.com/faq.html#msft“;. So even if Microsoft changes their stuff as a pure Linux development tool Mono would still be useful.”
Yes it will be useful only on Linux, but there are alternatives minimum as good as, .NET, such as Java, with which you can run your program NOW, on Mac OSX, BSD, Linux, Solaris, Windows 9x/NT/XP etc, BeOS, etc.
“Setting the GUI issue aside for a moment, for me (as a Windows developer) there is STILL a compelling reason to consider Mono – ASP.NET. I am very excited about the prospect of developing my web apps in Windows and being able to port them to Linux/Apache.”
You don’t need to wait actually! There is a better option! Write your web apps in the one you like from the following JAVA based web application framework list: J2EE, Echo, Struts, Open Symphony, Tapestry, Velocity, Expresso etc. You don’t need to port them to another OS, just run them on Linux, Windows, BeOS, Solaris, MacOSx etc, NOW!
For instance, Tapestry is very similar to ASP.NET as a web application framework, but it was there before ASP.NET. If you wanna check it out, here is its address:
http://tapestry.sourceforge.net/
The biggest advantage of .NET is the CLI and not the framework. Sure the framework is nice but it isn’t the primary reason why .NET kicks ass. Since the byte code format isn’t bound to a particular language like Java byte code it can be targetted by many different languages and couple that with the fact that platform specific components are a tad easier to use in .NET than Java (mostly because you can specify your own calling conventions) it’s easier to integrate .NET components into already existing systems.
Just the fact that I can write different parts of my applications in different languages and transparently use these different parts makes my mouth start to water. It’s really a great boon to software development to have this feature since programming languages differ in their way they treat a problem domain and if you can pick the language best suited for a particular domain your productivity will go up.
@ anonymous poster:
“The biggest advantage of .NET is the CLI and not the framework. Sure the framework is nice but it isn’t the primary reason why .NET kicks ass. Since the byte code format isn’t bound to a particular language like Java byte code it can be targetted by many different languages and couple that with the fact that platform specific components are a tad easier to use in .NET than Java (mostly because you can specify your own calling conventions) it’s easier to integrate .NET components into already existing systems. ”
I so accept that .NET’s byte code is prepared in a more language generic way, but actually, it is .NET’s biggest disadventage at the same time. It is not possible to create a byte code format which can handle every language, simply because there are many different type of languages. In order to “fit” these languages into CLI, these languages are changed, in my opinion, crippled. They are not the original languages anymore. COBOL.NET for instance, is NOT COBOL.
Actually, .NET has only one language, and it is CL (Common Language). All the .NET languages are different syntactical flavors of CL. All are restricted by the offered capabilities of CL.
MS had to do it in that way, since they had to support their previous languages, such as VB. VB.NET for instance, is not VB. I can show you many VB developers going mad with VB.NET. I don’t think that MS wants multiple languages also. This is why they give importance to only one language, their Java clone, C#. If MS wanted, VB.NET could have the same spectrum of capabilities with C#, but it does not. MS want to move MS coders to C# slowly.
It is also possible to implement different languages on top of JVM, and there are 200 or so already implemented. But, Sun for instance, do not promote it, since using one common language makes sense.
“Just the fact that I can write different parts of my applications in different languages and transparently use these different parts makes my mouth start to water. It’s really a great boon to software development to have this feature since programming languages differ in their way they treat a problem domain and if you can pick the language best suited for a particular domain your productivity will go up.”
I think writing different parts of the same application in different languages is a very, very, very bad idea. Ever heard of tower of Babylon? It will lead to a horrible maintenance nightmare, and productivity will lower significantly. You are right in thinking that different problems may be handled better in different languages, but this do not apply to .NET, since all the .NET languages are really the same language with different syntax.
@ erktrek:
> One of the purpose of Mono is “to create a powerful
> foundation for many languages to inter-operate.” […]
> So even if Microsoft changes their stuff as a pure
> Linux development tool Mono would still be useful.
One of the purposes of UDI is to create a driver environment where you can use the very same source code to compile a driver binary for different CPU platforms. So even if it weren’t for the benefit that such a driver binary would be useful for *other* OS architectures, as a pure Linux driver architecture UDI would still be useful.
Yet still RMS considers it a danger that stuff people would write for Linux could be used for Windows – Windows gains more than Linux does.
The very same arguments (regardless of wether I agree with them, which I don’t on the driver thing) hold true for Mono, don’t you think?
> I am very excited about the prospect of developing my
> web apps in Windows and being able to port them to
> Linux/Apache.
What happened to PHP, Perl, Python, JavaScript, Java?
@ croanon:
> I meant mainly Linux, BSD and MacOSX.
> They are gaining popularity very fast.
Beautiful. But I remember correctly MacOS market shares did *not* increase the last few years.
So let me restate my question: Which “alternatives” *besides* Linux/*BSD gained popularity?
None.
And Linux/*BSD isn’t exaclty new, it’s merely a reiteration of Unix. If you don’t like Unix any better than Windows, “alternatives” are rarer than ever.
I feel it every day when I talk to people about creating an OS alternative. “Why bother, there’s Linux”… 🙁
With Mono coming up, Linux simply helps cementing the fact that .NET (and that includes Passport, for christ’s sake!) will become the pervasive architecture. With some help from Intel’s TCPA and the US courts, under the cover of “security”, that means absolutely zero alternatives in ten years from now – Linux will either hop on board with the (financial) help of Red Hat and SuSE, all the rest will be left in the dust because they simply cannot afford to get TCPA licensed.
I hope I can reiterate this in years to come without losing the motivation to actually carry through with my own project – since I don’t like the prospect of being glued to Linux any more than Windows.
It simply feels like Amiga Inc. one scale larger. Things start looking really bleak and the crowd is cheering.
I drop out of this thread now before getting tarred and feathered for doomsaying.
From this page it seems that Java has a LOT:
http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html
Ok, some are interprenters, but even if you count them out I bet it still has more.
There is a XSLT to byte code compiler just to mention one cool and useful thing.
And btw. if the CLI is so language independent why is it that the new versions of JScript.NET, VB.net looks so much like C# with different keywords ???
/Lazlo
> I meant mainly Linux, BSD and MacOSX.
> They are gaining popularity very fast.
Beautiful. But I remember correctly MacOS market shares did *not* increase the last few years.
So let me restate my question: Which “alternatives” *besides* Linux/*BSD gained popularity?
None.
And so what? What exactly is your point? Are you trying to prove that WORA is not important? Or are you trying to prove that even it is important, CLI has implementations on Linux, MacOSX, BeOS, and Windows already?
1. If you think that WORA is not important, I must say you that it is your personal opinion. I think that it is important today, and gaining importance with every passing day.
2.
Mono is not full .NET implementation. There will be no .NET implementation on Linux, which will handle all the .NET framework. It is not possible for 2 main reasons: 1. Technical difficulties. For instance, Windows.Forms is based on Win32 widgets. It is very hard to realize it on any other windowing system. 2. MS is holding patents. Mono can make GTK binding, but once again, it is useless on many other platforms. It can be good on Linux, but why should I develop my program using Mono, when I know that if I do it with Java, it will run on many other OSs, and it is more robust?
There is Rotor for BSD, which is again not .NET implementation, and its usage is restricted for educational purposes.
There is no .NET MacOSX implementation that I know of. There are some attempts, light years back from the MS’s .NET, hence completely useless. Java, on the other hand, is supported very well on MacOSX. Even Apple prepared a special binding between JVM and OS, so that Swing programs may take advantage of hw accelleration. Java 1.4.1 version is recently announced, and will be available FULLY before the new year.
I absolutely agree with you on your thoughts related with Linux though.
@Solar
What happened to PHP, Perl, Python, JavaScript, Java?
They are fine, provided you have experience in those technologies (I do use Javascript). Being a small business owner, I gotta stick with what I know while occasionally making small technological leaps as things progress. From my admittedly narrow perspective it is more compelling to be able to leverage knowledge I already have versus learning a new set of alternate technologies.
@ croanon:
> What exactly is your point?
My point is that your claim of Microsoft dominance of the desktop diminishing because alternatives gain popularity is not true.
To cite from the post I was originally referring to:
> The adoption of alternative OSs will also bring
> enourmous importance to environments capable of
> producing cross platform compatible programs.
> They were not very much important in the past,
> since everything was Windows basically, thus
> creating Windows client programs were the most
> valuable skills in the job listings. This is not
> the case now. Cross platform compatibility is
> becoming more and more important. This is why
> Java and Linux are powerful together. They form
> a perfect synnergy which MS afraids of so much.
I dispute that claim. The Java hype is almost over. Linux job openings were rare two years ago, and close to non-existent today. When I look at job openings today, I see C# and .NET liberately splattered all over them. For reasons already pointed out, even by yourself, .NET is not what I’d call a “cross-platform approach”, it’s cross-platform Windows bait (as was J++, only ore successful).
You say that .NET isn’t the holy grail. Agreed.
You say that Linux and Java are strong players to nag on Microsoft dominance. Disagreed.
I worked for a company that just recently switched a VBA/Access application to Java. Right now, they are training most of their development staff in .NET and C#. Come on, smell the fish. .NET is a Java killer and the browser war reiterated in one.
> 2 – System.Data.SqlClient is a client for SqlServer 7.0 –
> they *cannot* recreate it, they can fake it using odbc
> or reverseengineer it – but in any event, it will most
> likely not perform *exactly* as the Microsoft one
http://www.freetds.org/
TDS is the protocol SQL Server and Sybase use to communicate. It’s not Mission Impossible. Mono already has a SqlClient implementation talking with SQL Server.
Coming from a Java proponent, I wouldn’t be griping about things performing *exactly* the same, as the varying Java implementations certainly don’t.
> You are right that Java is the only real cross platform
> language,
give me a break. Was Mozilla written in Java? Linux? the BSDs?
@Solar part II
Sorry, posted to soon (and late)…
Your other comment about cross platform technologies (like UDI and possibly Mono) aiding Microsoft is interesting. I guess it’s a perspective thing. Since Microsoft is already a dominant player why would it matter? If the Mono initiative works out even for just the non-gui stuff won’t there then be a huge new pool of potential developers for Linux? Seems like Linux has a lot more to gain versus Ms picking up a few (relative to their existing dev base) extra developers/apps.
> Windows.forms is based on Win32. It is very hard to
> implement it on other platforms, moreover, MS has patent
> rights on it and some other important parts of .NET.
> They would never let it go cross platform. I am working
> with MS consulters here, and even they confirm that it
> will not be cross platform.
So why haven’t they sued Mono? They’ve run an interview with Miguel de Icaza on MSDN for Christ’s sake. MS hasn’t shown any intention to sue, nor do they have any history for that. You must be confusing them with Apple or Sun or something.
Regardless, people bitching about Windows.Forms are missing the point.
Different platforms have different UI characteristics. Someone using Mac OS X doesn’t want to use a program with a Windows feel, for example. One-size-fits-none tools like Swing aren’t a solution for that (not a good one at least from the user’s perspective).
If you are writing an app in .NET targeted for a particular OS and you want people to actually use it, you probably should use an API that provides a native UI specifically for that OS. Targeting Linux? Use GTK#. Targeting Windows? Use Windows Forms. Targeting both? Use both. You can provide a native look and feel for each OS without giving up your choice of language as you would with Java.
There is benefit to having a consistent platform to code against, not having to build a different set of plumbing for each OS you’re running on, etc. There is plenty of code in an app that is not UI-specific. But, it can only go so far or you end up homogenizing everything. Why have more than one OS if everything is going to be the same?
A cross platform API for UI is going to be a lowest common denominator, and that’s not what .NET is about. .NET is about providing a consistent runtime environment where you are able to leverage strengths unique to a particular platform. You can see that now with Windows-specific features in MS’s implementation AND with Linux-specific features in Mono.
I so accept that .NET’s byte code is prepared in a more language generic way, but actually, it is .NET’s biggest disadventage at the same time. It is not possible to create a byte code format which can handle every language, simply because there are many different type of languages. In order to “fit” these languages into CLI, these languages are changed, in my opinion, crippled.
Oh really now? Please explain why this “impossibility” would apply byte coded virtual machine and not any programmable machine? Are they not equivalent in function? So you mean that there is some class of program that is impossible to express in a byte coded environment? It certainly is possible but is worth the effort?
They are not the original languages anymore. COBOL.NET for instance, is NOT COBOL.
This might relate more to the particular implementation of COBOL.NET and not the CLI itself. For instance the SML.NET implementation is 99.9% compatible with SML’97 ( http://www.cl.cam.ac.uk/Research/TSG/SMLNET/ ) which is an anecdotal proving my point
.
Actually, .NET has only one language, and it is CL (Common Language). All the .NET languages are different syntactical flavors of CL. All are restricted by the offered capabilities of CL.
They are only restricted as regards to the way they can interoperate with other languages. There is no restriction of how a language operate internally but they cannot rely on these features being available in other .NET clients.
It is also possible to implement different languages on top of JVM, and there are 200 or so already implemented. But, Sun for instance, do not promote it, since using one common language makes sense.
Could you please provide some linkage listing these 200 languages? The perhaps most famous of the languages I am aware of is the Java Icon implementation, JCon ( http://www.cs.arizona.edu/icon/jcon/ ), which you can probably can agree with, was less than a stellar success. Or to quote from the technical report:
“Java bytecode is designed as a target for the Java source language. As such, it omits features that cannot be
expressed in Java source. Two omitted features would have been useful for generating more efficient code
from Icon sources: static method references and reference arithmetic. <snip>”
As you maybe aware both of these features are expressable in the .NET CLI with direct support within the byte code format itself. If we should continue with the anecdotals
.
I think writing different parts of the same application in different languages is a very, very, very bad idea. Ever heard of tower of Babylon? It will lead to a horrible maintenance nightmare, and productivity will lower significantly.
Will it? Well hate to dissappoint but I have been interoperating different languages in the same system on many occations without it putting big hurdles in the way.
The only problem is that I am usually restricted to a feature set that can be described (if I am lucky) by C. With .NET this restriction is limited by the CLI which, you must agree with, is a far more capable than the C language and it’s library conventions.
You are right in thinking that different problems may be handled better in different languages, but this do not apply to .NET, since all the .NET languages are really the same language with different syntax.
Yet again, they only need to maintain “compatibility” with the .NET conventions if they are meant to be used by other .NET languages. If they are strictly internal nothing is stopping me from using some language specific feature.
Excellent comments. You (and mauerj) are one of the few posters who understand .NET. I recommend the others read (or re-read) http://arstechnica.com/paedia/n/net/net-1.html.
-G
It’s quite amusing reading about all you TrollDot kids proclaiming that Linux’s marketshare is growing quickly.
Have you looked at the figures? Neither Apple’s nor Linux’s marketshare has increased over the last year or two. So much for Linux taking over the world.
And what’s even funnier is how 4 or 5 years ago you people were predicting that Microsoft would fall and Linux would be THE desktop OS by 2000-2002. Strange, I haven’t seen that happen.
The real power of .NETs CLI is the not so much that you would be able to write your program in multiple languages, but that you’ll be able to use more modules and libraries written in other languages. The CLI interface is much richer than the .DLL, and also a bit more granular than COM objects.
So, no, it’s not really smart to write your own project in N different languages, but now it’s a lot more probably that someone will write a library in SML.NET that will be easily integrated into a VB.NET program.
This was, of course, possible before, but now it’s just even easier to do.
Have been reading the entire thread, and also part of the article at ArsTechnica, seems to be so many interesting issues around .NET.
I think what .NET tried to offer, technology wise, could be promising; language neutrality and Assembly provides many benefits to code-reuse and flexible library linking, and there are many features implemented as MS had learned from Java. Of course I also read about the concern of MS controlled platform and development environment and as such.
There are some issues, however, I think still worths considering besides MS behind it:
1. Language neutrality sounds a cool idea, but how’s the actual implementation? Seriously it seems cool for all components to interoperate with each other, but is it really good performance wise, debugging wise, and maintenance wise?
If MS wants others to move to C#, perhaps they should say so right out from the start, I don’t really think promoting two rather opposite development strategies (single language vs multiple language with compatible objects) is good; it could really confuse development managers: What to do if somehow the actual implemented/compiled object work not so good with one from another language? Should programmers continue to code in different languages and wait for MS (to crank out another .NET release) to handle and improve the object interoperability? Or get them to code in the same language again so that maintenance will become less of an issue?
2. How about the speed of executing the code? How is the users experience running the web app developed? So much focus are on how fast apps can be developed, but the quality of the apps, as well as security, have gone unmentioned. Maybe there are other articles covering this issue.
3. Is replacing Java actually a good idea? I am not a Java developer, perhaps other coders and programmers can comment on this. Is something that can’t be done with Java, can be done really good with C# on .NET? I imagine we will at least lose some cross-platform support as I don’t think MS will be enthusiastic to support platforms other than Windows. So what will we actually gain in sacrificing other platforms?
mmm, first of all, nobody who has even half a brain would code in DotNet.
1.) Fact: VS.NET comes with a decompiler (into MSIL) for all of your decompiling needs/wants. This works on EVERY SINGLE DotNet application.
2.) Fact: You can decompile dotnet programs into their native language, and even into other dotnet languages with relative ease.
3.) Fact: There is no such thing as DotNet languages, such as VB.NET, C#.NET, etc. They are just syntaxes, in which the “compiler” translate the syntax into MSIL, then “compiles”. The catch is.. it never truely compiles.
4.) Fact: Whenever you create a program with DotNet, and distribute it to anybody, you have effectivly given out the source code to your program.
mmm, what we really need is a true cross platform programming language, that actually compiles, since DotNet does NOT do that. Delphi/Kylix comes to mind.
Actually, there is very little “native” code in SWT, the vast majority of it is written in Java on a given platform. The last bit of that statement is the key. Almost the entire widget-set is written specifically for a given platform so it can manage the OS specific nature of the windowing system. A new port simply needs to abide by the contract of the interfaces to the classes. This coupled with the fact that SWT is driven by layout managers instead of static layouts, allows for a given SWT application to look exactly like a native application.
In fact, the native interfaces in the SWT are required to be a 1:1 mapping to OS level calls. For example, in Photon, the Button class invokes OS.PtCreateWidget() which simply is a JNI that calls PtCreateWidget(). This works out very well and allows most of the work to be done in Java.
The only cross platform option based on VM that can be used today is Java. It started to shine even on client-side, for instance