Fog Creek Software
Discussion Board




.NET *is* Java

Software Development magazine has had an interesting couple of articles concerning Eiffel under .NET. (Not sure if the articles are online...) Anyhow, reading about how the Intermediate Language is written made me think that .NET is fundamentally the same as Java.  MS has made a bit of packaging improvements with metadata and assemblies, but the IL is very much like the JVM and the class libraries seem rather similar to Java's.

One big thing touted for .NET is the multi-language interoperability. Joel claimed that this was a false feature because the languages all have to end up working the same way and the only difference is the syntax. The article about Eiffel shows that that's not completely the case: Eiffel has multiple inheritance, a big thing that the IL does not directly support. The Eiffel folks even figured out a clever way to make their multiple inheritance play nicely with the other .NET languages that don't support it.

Back to my initial point, though. The Java Virtual Machine can handle multiple languages well, too. Jython is probably the best example, because it is compiled and interoperates quite nicely with the JVM. (And it does multiple inheritance, too!) Sun certainly never promoted multi-language possibilities with the JVM, however... so MS can claim this as a benefit and Sun cannot, despite the similarity between MSIL and the JVM.

If Sun had chosen to use native widgets rather than drawing their own with Swing, you might see a lot more people writing desktop apps in Java.

Kevin Dangoor
Tuesday, May 07, 2002

& everything old is new again...


http://cne.gmu.edu/itcore/virtualmachine/history.htm

Johnny Simmson
Tuesday, May 07, 2002

Not a very complete history, doesn't even mention p-code.

PeterM
Tuesday, May 07, 2002

"doesn't even mention p-code"

You say that like it's a bad thing :)

Brad Clarke
Tuesday, May 07, 2002

The multiple language feature of .NET seems to be more of a bullet-point item (i.e. to make the feature list longer) than anything else. There are several features of it that make me think you wouldn't really want to use it.

My impression is that you need your developers to be familiar with C# (Java) and the .NET frames in addition to their own language syntax to understand how to write applications. Because the .NET languages are constricted to a Java-like model writing in any language other than C# (or J#?) may be more confusing than useful.

Walter Rumsby
Tuesday, May 07, 2002

What sane manager would allow development in more than 1 language?
release 1-
features a,b,c done in C++.net
(programmers all quite, replaced by C# wizards!)
release 2-
features d,e,f done in C#
(programmers all quit, replaced by ... C#,C++,VB.NET Wazrds)

even if your are part of the "in-house" world, Imagine 20 little system components all written in different .NET languages!!!!, by different accountants trying to get into tech!!!! (twilight zone music)

Daniel Shchyokin
Wednesday, May 08, 2002

Java has multiple language support as well.  I've recentrly discovered Jython.

The great thing is that Jyton complements Java, rather than just being syntactically different.

Prototypes can be thrown together in Jython, and then incrementally moved to Java.  It's a good setup.

Ged Byrne
Wednesday, May 08, 2002

"What sane manager would allow development in more than 1 language?"

That's not really the point.  .NET allows a sane manager a choice of which language to use - it doesn't mean you have to use more than one, although in some cases you may want to.  It is about choice.

The Java world pretty much dictates you have to use Java, any code you have in other languages is now obsolete and must be rewritten in Java, any components in other languages you want to use, cannot be used unless they are Java.

Most sane managers will pick a single language for development, be it C#, VB or Eiffel(!), but they have a choice of integrating components written using other languages.

For languages such as Eiffel, Fortan etc, .NET could provide a huge opportunity as once they have an IL compiler for the language, users of the language have access to the .NET class libraries, the Visual Studio IDe, the Visual Studio debugger, etc etc.

Ade B
Wednesday, May 08, 2002

<< If Sun had chosen to use native widgets rather than drawing their own with Swing, you might see a lot more people writing desktop apps in Java >>

Wasn't it the case with AWT ?
If I get it right, they *were* using native peers for GUI but then they had more then enough "It looks different on this OS" problems. And they also had to find a common denominator to the feature set of all platforms.
That's when they started to use Swing.

Evgeny Goldin
Wednesday, May 08, 2002

>> If Sun had chosen to use native widgets rather than drawing their own with Swing, you might see a lot more people writing desktop apps in Java

> Wasn't it the case with AWT ?

That is exactly what AWT is: a wrapper over the native objects.  Good grief.

Nat Ersoz
Wednesday, May 08, 2002

If you're talking about Java's GUIs, you need to consider 3 things:  AWT, Swing, and IBM Eclipse.  For a really quick explanation, look at the below link, under "The Standard Widget Toolkit."
[ http://www-106.ibm.com/developerworks/java/library/j-nativegui/?loc=dwmain ]

* AWT is just the basic underlying platform widgets
* Swing is the very versatile, skinnable GUI that can mimic underlying platform's GUI
* Eclipse is a reasonably crossplatform way of using complex native widgets, mimicking them if not available

Java guy
Wednesday, May 08, 2002

Completely off topic, but the article Johnny posted the link to neglects the Z-Machine. The virtual computer all Infocom games (think: ZORK) ran on so they could program once and run on any computer. I think there was quite a bit more diversity back then too - basically everything there is now (dos based, unix based, and mac) and more (atari, commodore, etc.).

I now return you to your regularly scheduled relevant discussion.

MarkTAW
Wednesday, May 08, 2002

>For languages such as Eiffel, Fortan etc, .NET could
> provide a huge opportunity as once they have an IL
> compiler for the language, users of the language have
> access to the .NET class libraries, the Visual Studio IDe,
> the Visual Studio debugger, etc etc.

except the fact that it is not possible to create even a decent optimized Fortran compiler towards .NET.  That's the whole problem - .NET really works only with OOP type languages - otherwise it sucks.  Guess how many physicist would like to recompile thaier code to Fortran.NET just to make it way slower.

Tekumse
Wednesday, May 08, 2002

I have this disturbing feeling that everyone talking is missing extreme amounts of information on .NET.  I've been doing quick research the last couple days, and there are some strategies open for using Fortran with .NET.

* Hints to the JIT may let it optimize better
http://mail.gnome.org/archives/gnome-hackers/2002-February/msg00051.html

* Don't compile Fortran to .NET -- instead use .NET as an extension platform for your Fortran.  This seems to be the strategy Mono is taking; other possibilities are using COM interfaces or SOAP.  Since I have never used these interfaces, I don't know the performance characteristics.

Again, I've never programmed for the MS platform, so my grasp is suspect.

Java guy
Wednesday, May 08, 2002

What is then the big deal about .NET if one could do just the same with COM or CORBA?

Obvously what M$ tries to push is not what you are saying.  The same way there is some java to COM/.NET bridges but the M$ agenda is to write java and compile it to .NET, not just call .NET objects from you java app.

The whole point is that you might want to have a user interface in .NET(VB, C#, etc.) that uses for actual computations Fortran. This means that you Fortran code need to be recompiled under .NET so that you can call it from VB or C#.  And by doing that you lost all the advantage of Fortran because it will run shitty under .NET.

If you're using Fortran, you are, most likely, bashing numbers.  This is also in a market where your are going to spend $1k to $2k for your compiler & libraries. The question isn't, "which is fastest for my platform," but "which is fastest for my budget."  That is the lesson to be learned from the whole MS Visual Fortran which now rightly extinct.

Tekumse
Wednesday, May 08, 2002

"This means that you Fortran code need to be recompiled under .NET so that you can call it from VB or C#."

Simply not true. Let me ask you this question - suppose you wanted to put a Java UI on a Fortran number-cruncher. What would you have to do then? Well, you have two choices:

1) Rewrite your fortran code in Java - bye bye speed (the only reason to write *anything* in Fortran)

or

2) Compile your Fortran code to a library of some sort, then write JNI stubs so the Java code can call out to it.

Writing JNI is a nightmare.

Under .NET, you've also got two choices:

1) Recompile in Fortran.NET. Yes, you lose speed, but at least you don't need to rewrite everything in a different language.

or

2) Write your Fortran code as a DLL (fairly easy to do). And then JUST CALL IT from your .NET app.

You don't need to deal with manually writing interop layers. You don't even need to write a COM object. All you need to do is expose a function in a DLL (which could be as simple as "void Go()").

The Java world is ashamed of the platforms they run on. Therefore it's very hard to break out of the sandbox to talk to legacy code.

In .NET, there's no such shame - you can call existing code all day long very, very easily.

Chris Tavares
Wednesday, May 08, 2002

I'm getting a little bit tired of the 'multiple languages can run on the JVM, too' line. Sun provides one language for the JVM (Java), and only one other language (Jython) has usage that might edge above non-trivial. And unless one of 1) Jython is significantly different from standard Python or 2) The JVM is fundamentally different from the .NET framework in ways that make implementing Python easier, then Jython almost has to suffer from the same performance issues that the Python.NET research compiler does.

On the other hand, Microsoft currently provides 5 languages for .NET (managed C++, C#, Visual Basic.NET, JScript.NET, and J#), and none of them are going away any time soon (not even J#, if the most popular guess as to why it exists -- to make VS.NET usable for introductory CS classes that are typically taught in Java these days -- is correct). Admittedly, it's five roughly similar languages, especially when writing code that maximizes performance, but some of us really do think case sensitivity and semicolons are annoying...

Dave Rothgery
Wednesday, May 08, 2002

I do remember Fortran 77 as my 1st non-modelling programming language, and even then it was useful to interface with C.  I hear now it's common practice to use Python in combination with time-tested Fortran modules.

Take a look at the following link by the creator of Eiffel, under "Levels of Compliance":
http://www.sdmagazine.com/documents/s=738/sdm0011l/0011l.htm

Java guy
Wednesday, May 08, 2002

Chris, you wrote:

-------

Under .NET, you've also got two choices:

1) Recompile in Fortran.NET. Yes, you lose speed, but at least you don't need to rewrite everything in a different language.

or

2) Write your Fortran code as a DLL (fairly easy to do). And then JUST CALL IT from your .NET app.

You don't need to deal with manually writing interop layers. You don't even need to write a COM object. All you need to do is expose a function in a DLL (which could be as simple as "void Go()").

-------

It's already been discussed that writing [language].NET isn't quite as simple as loading the existing [language] source in VisualStudio.NET and recompiling. I suspect achieving point (1) won't be elementary.

With regard to point (2) - if you write your Fortran as a .DLL and use it in your .NET application how does this differ from writing it as a .DLL and using it another context outside of .NET? This doesn't seem to be a feature of .NET, but of Windows.


So what does .NET give you:

- VisualStudio.NET

VisualStudio has always been one of the best IDEs out there, is VS.NET a significant improvement over the previous version?


- VisualBasic.NET and C#

A necessary update to VB and a new language which acknowledges the productivity of Java and Delphi as development platforms.


- Standard APIs for writing web services, parsing XML, etc.

These could have existed independently of .NET.


- WinForms and WebForms.

Having a significant amount of experience with DHTML, CSS, absolute positioning, etc I was extremely unimpressed with the HTML generated by VS.NET.

* It uses style attributes which are not allowed in the XHTML1.0 standard.

* The HTML source is larger than optimal (this IS an issue with HTML because the "pipes" most people use to view web pages are small and unreliable) and elements are absolutely positioned with pixels which is fairly dangerous (how is font resizing supported?).

* Supposedly your .aspxs detect the end-users' browser and generate the most appropriate HTML for their client. This just seems like an unnecessary layer of work for IIS and an unnecessary layer of abstraction for the developer. There's nothing wrong with using standard HTML as intended (i.e. for purely structural markup, and using CSS to control presentation), this is the standard recommended approach and I would have preferred it if Microsoft had spent the money used developing this feature to instead educate developers about standard practices.

* Given the above, isn't there a real risk that VS.NET generated HTML could violate section 508?



.NET isn't a silver bullet - Java isn't a silver bullet.

Therefore .NET is (roughly) Java.

Walter Rumsby
Wednesday, May 08, 2002

Dave,

There is also scripting languages like judoscript and javascript.  LISP and Forth compilers can also be found.  Assemblers are also available.  Anybody know of a good basic.

.Net doesn't do anything that Java doesn't.  Anybody can write any language that can compile for the JVM.

The only difference is that Multiple languages are coming for .Net from Microsoft, and that Microsoft's marketing are pushing it as a feature.

Ged Byrne
Thursday, May 09, 2002

---------------------------------------------------------------------------
The Java world is ashamed of the platforms they run on. Therefore it's very hard to break out of the sandbox to talk to legacy code.
--------------------------------------------------------- Chris Tavares

I think it is fear rather than shame.  Once you leave the sandbox all of Java's rigid security is null and void.

.Net's security model is still untested.  To be honest I don't know anything about .Nets security model, and I'd be grateful if anybody could point me to a good article.  It will be interesting to see what the hackers make of it.

Ged Byrne
Thursday, May 09, 2002

  "To be honest I don't know anything about .Nets security model, and I'd be grateful if anybody could point me to a good article."

The core of .NET's security model is Code Access Security. The way to look at it is very similar to how Internet Explorer's zones work: you know, Internet Zone can be disallowed to run ActiveX controls, etc. For .NET code it means that depending on where the code is from (i.e. url downloaded from or public key of developer, what directory the code is running from, etc) you can selectively open up the "sandbox" to various sensitive classes such as System.IO.FileStream. It's very extensible so that you can create your own Permission classes and associate them with your classes.

See:
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconcodeaccesssecurity.asp

As long as code is "managed" code, running in the CLR then it's safe. It's just when you go outside into the unmanaged world, then you're out of its jurisdiction – but then again – it requires specific permissions to be able to do this.

Duncan Smart
Thursday, May 09, 2002

Ged > Lots of software exists that almost nobody uses. Non-Java JVM languages, with the possible exception of Jython, are definitely in this category.

Dave Rothgery
Thursday, May 09, 2002

I think you'll find huge use of TCL on JVM, via JACL.  In fact, I'd bet there's more use than Jython, since I can think of one consultingware vendor whose old TCL-plus-C++-extensions product is now TCL-on-JACL.

Rodger Donaldson
Thursday, May 09, 2002

Now I'm way down at the bottom and nobody cares about this issue any longer, but anyway...

I don't think there is anything wrong with the ability to use (and the promotion of this by Microsoft) multiple languages with .NET.

It would be tricky for half of a team to use VB and half to use C#, and I wouldn't recommend it. What it does is give shops that already use one language the ability to jump right in and be productive.

Plus, if you encapsulate everything properly and use web services (or some other non-language specific method) to communicate, different teams can use the language they want and everything will work together.

Glarkonman 2000
Saturday, May 11, 2002

Do you have worked with JAVA and C#? I'm code with JAVA since 2000', and code with C# since 2002.
I think that .NET not IS JAVA, and JAVA is now a "deprecated" language. Security issues lock the java technology, the JAVA API is inconsistent (java, javax, sun, sunx, com.sun, etc, etc)  ... result: .NET is better, more secure, faster and much productive than JAVA.

Rafael
Wednesday, May 05, 2004

"...the ability to jump right in and be productive."

Actually this is not the case with VB.NET, and the reason I searched for why ".NET is Java" in the first place.  Sure, Microsoft offers a migration wizard to port old VB code to the new .NET way of doing things, but this doesn't work moving forward.

The various new versions of Microsoft's Visual Basic products have succeeded, in part, because they were incremental improvements on an earlier standard.  The essential advantage of Visual Basic has always been to remove syntactical and structural requirements of programming, and put most of the design process into the Rapid Application Development realm.  (Call me lazy, but time is money.)  Its ease of use and shallow learning curve  made VB "...one of the most used languages on the Windows platform ...said to represent some 70 to 80% of all commercial development" according to Wikipedia.

I suspect that the .NET framework evolved out of Microsoft's J++ product after Sun rightfully started crying foul.  The bigger-better sandbox (full of someone else's sand) approach is is nothing new to Microsoft, or the rest of the world.  Windows is MacOS is Xerox PARC. 

I must admit that the success of Visual Studio lies in the integration of logic examples, now even from the web, into the IDE.  (Try getting usable code out of the java docs.)  By discontinuing the document and control-oriented methods and properties of Classic Visual Basic, Microsoft abandoned a workhorse and told VB programmers to take a flying leap.  The code examples are their only safety net.

VB.NET is Java, from its coded object orientation and virtual machine, to its library imports, strong typing, single-inheritance, exception handling, threading, operators, string manipulation, casting, arrays, graphic panels, and garbage collection.  I recommend that all VB programmers take a Java class before diving into (ja)Vb.NET.

Christopher Zahrobsky
Tuesday, August 17, 2004

*  Recent Topics

*  Fog Creek Home