The Artima Developer Community
Sponsored Link

.NET Buzz Forum
.NET and Mono: The Libraries, the Framework and the Very Big Fish

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Scott Hanselman

Posts: 1031
Nickname: glucopilot
Registered: Aug, 2003

Scott Hanselman is the Chief Architect at Corillian Corporation and the Microsoft RD for Oregon.
.NET and Mono: The Libraries, the Framework and the Very Big Fish Posted: Jun 11, 2004 1:19 AM
Reply to this message Reply

This post originated from an RSS feed registered with .NET Buzz by Scott Hanselman.
Original Post: .NET and Mono: The Libraries, the Framework and the Very Big Fish
Feed Title: Scott Hanselman's ComputerZen.com
Feed URL: http://radio-weblogs.com/0106747/rss.xml
Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios.
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Scott Hanselman
Latest Posts From Scott Hanselman's ComputerZen.com

Advertisement

Via Gordon, I see that Tim Bray pointed to Jeff Dillon's points on cross platform .NET.  Jim Blizzard chimed in as well.

I like Gordon's brief and complete summary:

The point? If you care about cross platform .NET, there are details you need to pay attention to, and you really shouldn't do dumb things like use the registry. As for "the cost of not being able to do native system programming in pure Java" we already know that pure .NET is a myth, too. [The 80/20 Solution]

With due respect, I'm not getting a few of Jeff's views:

The Java API writers have always been very careful not to introduce an API which does not make sense on all platforms.  This makes Java extremely portable at the cost of not being able to do native system programming in pure Java. [Jeff Dillon]

Which sounds just like the Least Common Denominator point I've made before.  However, while the Java API writers may try to support the LCD, the Java Application Server vendors explicitly promote vendor lock-in by introducing APIS that are App Server specific.  As Jeff wisely points out, there is a cost.  I say it's too high for most.

Microsoft is very open about their goals - Vendor lock-in is a good thing.  Exploit the platform.  Jeff says:

With .NET, Microsoft went ahead and wrote all kinds of APIs for accessing the registry, accessing COM objects, changing NTFS file permissions, and other very windows specific tasks. In my mind, this immediately eliminates .NET or Mono from ever being a purely system independent platform. [Jeff Dillon]

No, it really just eliminates the possibility of using a COM API on another platform.  This will lead to the rise of ".NET Code - Pure Enough for Mono" , and that suits me just fine.

If Microsoft were to truly virtualize the machine, they would have marginalized their investment in the Windows platform. [Me]

I'm not trying to promote bad feelings.  I worked at Nike getting Java over RMI on Solarious to talk to DB2 on a Mainframe - I love all religions, remember:

Scott's Rule of Programming 0x303b: Don't Player-Hate, Integrate.

I'm just trying to remind folks that, by definition, write once, run anywhere, means writing to Least Common Denominator APIS (or introducing "if (!IsMacIE)" code - You may have seen that before on a Write Once technology called HTML/ECMAScript?)

The only difference is that Mono has seen fit to raise the level of the Least Common Denominator API to a reasonable level.  That, combined with common sense like there's no Registry on Linux means that apps like dasBlog can happily be ported to Mono.

Read: .NET and Mono: The Libraries, the Framework and the Very Big Fish

Topic: New Toy: IPOD Previous Topic   Next Topic Topic: UEFA EURO 2004 in Portugal starts on Saturday!

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use