Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Taking another look at .NET

By Dacta in News
Sun Jul 16, 2000 at 09:55:18 AM EST
Tags: Please Choose a Topic (all tags)
Please Choose a Topic

Now that the hype from MS's .Net launch has died down somewhat, I thought I'd take a look at what it offers. (This will be of more interest to programmers than most other people)

My original impression of .Net was that all it was about was using SOAP (XML over HTTP) as a transport mechanism for DCOM objects. That, in itself is a farily nice thing to have. It allows you to, for instance call VB onjects on a Windows 2000 box from a Perl program on you Linux box, or to use Java with the same VB objects.

Then I went and read some MS developer articles about .Net. I was impressed, to say the least.


Part of .Net does mean using SOAP, but it is a whole lot more than that.

.Net is a framework for building internet applications in any language. I know that sounds like marketing speak, but I can't express it any other way.

It includes a run-time engine that interprets and/or compiles byte code (in a language called "Internal Language" or IL). This is similar to a Java Virtual Machine except that (a) it is not cross platform compatible and (b) it is designed from the start to be used by multiple languages.

Microsoft's new version of Active Server Pages (ASP+) use this runtime engine to allow you to code them in any language that targets the .Net run time language.

However, not only can you use your favourite language to target the .Net platform, you can use that language from MS's Visual Studio - with full intergrated debugging, breakpoints, everything.

Once you are that far, you can call objects written in other languages using your language, and debug them all at the same time. If you step into the call of an object written in another languge (which you have the source code for) Visual Studio will let you debug that, too.

.Net also includes new GUI/WUI (Web User Interface) object models called WinForms and WebForms respectivly. They allow you to write Web based code in the same way you write a conventional GUI program.

As you can see, I'm pretty impressed by all this stuff. I'm not blind, though - I can see the problems. The .Net virtual machine need to be targeted by you favourite language, and for some languages this might mean changes - for instance, you can not fully use Multiple Inheritance.

The list of languages supporting .Net is already pretty impressive, though: COBOL, Eiffel, Haskell, Mercury, ML, Oberon, Perl, Python, SmallTalk, and Scheme as well as VB, C++ and C#.

Personally, I think .Net is more compelling than Java from the developers point of view. I'd much rather be tied to one platform and have a choice of languages that be tied to one language and have a choice of platforms that the application will (mostly) run on.

This is especially the case now Java is focusing more on server side programming - lets face it - if you write your Java program for Solaris you are unlikely to switch to Windows. Even if you do, it is likely you are going to have to make almost as many changes as you'd make switching a clean C++ or Perl program across.

Then there is Perl or PHP on Linux. If we forget the moral aspect, why would anyone choose this platform (at least for high end websites)? It is probably a little more reliable that Windows 2000 (although that gap is coming down), and it is definatly cheaper. However, it is easier to find programemrs for ASP+ - now all the Perl programmers can write for that, too.

I'm worried that .Net is another MS thing that the Open Source world is ignoring because they don't understand it. I don't see any projects that support server side object oriented programming on Linux in your choice of language. (I realise that Python can produce Java byte code, but I consider that an exception).

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o read some MS developer articles about .Net
o Also by Dacta


Display: Sort:
Taking another look at .NET | 38 comments (27 topical, 11 editorial, 0 hidden)
Ahh, but there is an open source option (4.00 / 2) (#7)
by haakon on Sun Jul 16, 2000 at 04:16:26 AM EST

Have you heard of Jabber? It is an XML based messaging system. It's killer app is Instant Messaging but the vision for the system, by some of the developers are way beyond that, just read this article for one persons .Net style vision for Jabber.

As much as it sounds impressive... (4.60 / 5) (#9)
by Imperator on Sun Jul 16, 2000 at 04:34:23 AM EST

...I think we need to look at Microsoft's track record for delivering on their hype.

For a start, most of MS's technical efforts flop. Some gain wide acceptance anyway, but many of them (e.g. ActiveX, MSN*, Photo*, various APIs) never gain the momentum they need to achieve dominance. Remember that for each Word, there are a half dozen Bobs. Microsoft is so large they can afford failures when they get an occasional success to exploit. They can fire a shotgun into the future and buy the next round with whatever they hit.

Additionally, Microsoft has no interest in providing compatibility with other systems. This is not only a social concern but also a technical one. By the time they shove something resembling a working .Net platform out the door, writing MS-only code will be risky. The relative decline in popularity of MS operating systems will be overshadowed only by the success of a Mozilla-based browser (and platform) from Netscape.[1] IMHO, Microsoft at a crucial juncture has made the mistake of neglecting Office to pursue a relatively XP market. If they had pushed their Office dominance with proprietary network protocols instead of IE, they might have secured another five years of hegemony.

Finally, MS lacks support in the industry. Though this might seem obvious (to Oracle employees) or ignorant (to Symantec employees), Microsoft's zenith of support has passed. Companies that once could be relied on to deliver Windows-only software and hardware now are making tentative steps (or in some cases, confident leaps) to other operating systems. MS now sells software in almost every profitable category, so there are few niches left where it is possible to sell Win32 software without risking the wrath of Gates.

I am forced to conlude that .Net will be an expensive failure.

[1] AOL, which owns Netscape, currently uses IE to keep an icon on the desktop of the default Win9x installation. When it comes, the switch from IE will seem a bolt from the blue to the business world, as they have been lulled by IE's success.

Re: As much as it sounds impressive... (3.00 / 1) (#17)
by skim123 on Sun Jul 16, 2000 at 01:11:54 PM EST

If this does end up failing it will cost Microsoft its entire business. Microsoft is betting the bank on this new wave, and every product group is going that way (and hard). If this flops a year from now, Microsoft is fucked. This is more like a system-level change, like adding COM support to Windows.

My bet is that it catches on all right, and Microsoft is still around a year from now.

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


[ Parent ]
Um, but you can have multiple languages with the J (4.00 / 2) (#13)
by Anonymous Hero on Sun Jul 16, 2000 at 11:08:02 AM EST

Haven't you heard of JPython? Take a look at <a href=http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html>Languages for the Java VM to see a big list of other languages.

Um, but you can have multiple languages with the J (3.00 / 1) (#14)
by Anonymous Hero on Sun Jul 16, 2000 at 11:09:33 AM EST

Haven't you heard of JPython? Take a look at Languages for the Java VM to see a big list of other languages.

(your tag parser needs work; it rejected my anchor tag because it didn't have quotes around the href value)

Tag parsing is correct... (5.00 / 1) (#19)
by Pete Bevin on Sun Jul 16, 2000 at 05:58:54 PM EST

>(your tag parser needs work; it rejected my anchor tag because it didn't have quotes around the href value)

And so it should do. The HTML standard explains why: see w3.org.

[ Parent ]

No Java support? And haven't they ever heard of CO (4.00 / 2) (#15)
by Ricdude on Sun Jul 16, 2000 at 11:55:01 AM EST

I think that until this supports Java it's doomed to implementation only by the very curious and the herds of microsoft-only programmers (moo).

CORBA provides all this cross-platform, cross-architecture, cross-language stuff already, and is a great way to separate client and server sides of a distributed application. Here. Today. Lots of vendor support from many companies. Free and Freely available versions abound. And it supports Java.

Some day, the industry will realize that just because a company says a new technology is the greatest thing since procedural code, doesn't mean it is. And more importantly, doesn't mean they should reallocate their resources to change everything overnight.

Re: No Java support? And haven't they ever heard o (none / 0) (#25)
by cypherpunks on Mon Jul 17, 2000 at 03:56:33 PM EST

> I think that until this supports Java it's doomed to implementation only by the very
> curious and the herds of microsoft-only programmers (moo).

Oh to have such problems. The number of programmers developing for Windows is larger than the number of programmers developing for Java. Throw in the larger, and (slightly) more consistent behavior of Win32, not to mention market share, and many other variables, and it's not hard to see why this won't significantly change in the next 5 years (or more).

> Some day, the industry will realize that just because a company says a new technology
> is the greatest thing since procedural code, doesn't mean it is.

But that day won't come until we've managed to shoot all the marketing people. :)

[ Parent ]
What would be really cool (2.00 / 1) (#16)
by skim123 on Sun Jul 16, 2000 at 01:08:48 PM EST

First off, I have had a couple months to play around with ASP+, it is really cool, as is the whole new architecture. Since the architecture uses a form of bytecode that all languages share, I really wonder how hard it would be to create a runtime for other platforms that could interpret/use this bytecode.

What would be really cool would be if Microsoft itself did this! Wouldn't it just rock to buy Office 11 and have one CD and have it able to run on just about ANY platform!?!?! Now, you might ask, why would Microsoft do this? Well, the probably wouldn't, unless the gov't splits them up and the Office group goes off and does this...

Oh well, a pipedream, I know, but it would be cool nevertheless.

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


.NET and Java (4.40 / 8) (#18)
by Pac on Sun Jul 16, 2000 at 02:33:01 PM EST

Let me try to desconstruct this nicely. I hereby swear I will try my best not to let it show I am laughing out loud.

It includes a run-time engine that interprets and/or compiles byte code (in a language called "Internal Language" or IL). This is similar to a Java Virtual Machine except that (a) it is not cross platform compatible and (b) it is designed from the start to be used by multiple languages.

Microsoft spent the first years after the development of Java FUDing us with every argument it could think of against Virtual Machnes. How come it now changes its mind so radically?

But then again, let us see. It gives us a Virtual Machine capable of generating bytecode for many languages (not just Java) but incapable of generating cross-platform code. Why on earth would I want it? If you are stuck with Windows you can perfectly well let your VB programmers do the ASP and your C++ programmers do COM objects to perform the hard work. Why would you want to kill the difference here, probably in favour of the least efficient technology?


Once you are that far, you can call objects written in other languages using your language, and debug them all at the same time. If you step into the call of an object written in another languge (which you have the source code for) Visual Studio will let you debug that, too.

First, you can already do it. Second, do you really want your VB programmers debugging that C++ COM+ component?

The list of languages supporting .Net is already pretty impressive, though: COBOL, Eiffel, Haskell, Mercury, ML, Oberon, Perl, Python, SmallTalk, and Scheme as well as VB, C++ and C#.

Impressive? Eiffel,Haskell, Mercury, ML, Oberon, SmallTalk, and Scheme taken together must have something between one and five thousand developers worldwide. Python and Perl are crossplatform languages already geared towards this kind of thing. VB, C++ were already there. C# is a Microsoft copy of Java. Oh, well, now we can bring the COBOL guys from the mainframe basement and let them mantain the web site...

I'd much rather be tied to one platform and have a choice of languages that be tied to one language and have a choice of platforms that the application will (mostly) run on.

Do you realize this feeling of yours can only hold true if you only need to develop against one platform, specially if this platform is Windows (because Unix apps, specially Web apps, are generally far easier to port)?

lets face it - if you write your Java program for Solaris you are unlikely to switch to Windows. Even if you do, it is likely you are going to have to make almost as many changes as you'd make switching a clean C++ or Perl program across.

Sorry, but I think you have never done such a thing. It is very important to be able to make the same code base run on Unix and Windows. As for this being as difficult as porting a C++ program, you don't have the faintest idea of what you are talking about. Perl, OTH, will usually run in both platforms without changes.

Then there is Perl or PHP on Linux. If we forget the moral aspect, why would anyone choose this platform (at least for high end websites)?

[And Python. And C++ used with some cross-platform libraries.] As for why would one choose Linux instead of Windows, this answer is usually "Mu". I trade Linux for Solaris or AIX (usually Solaris), but I only use Windows if the client forces this choice (in which case Linux was never an option).

I think the VM and the C# thing are just another nasty blow from MS in Java. I also think it won't work. There too many Java developers out there now, the remaining portability problems are being addressed and the VMs are gaining performance each day. As for .NET as a platform, it is still undecided if it is marketing or truth. I would like to see some running code before commiting to such a beast. It would not be the first time MS would start talking frantically about a marvellous new technology just to forget all about it two months later.

Evolution doesn't take prisoners


Cross Platform (2.00 / 1) (#20)
by Anonymous Hero on Sun Jul 16, 2000 at 09:02:20 PM EST

Once you are that far, you can call objects written in other languages using your language, and debug them all at the same time. If you step into the call of an object written in another languge (which you have the source code for) Visual Studio will let you debug that, too.

First, you can already do it. Second, do you really want your VB programmers debugging that C++ COM+ component?

Why shouldn't a VB programmer be able to at least try and debug a C++ component? You could use the same arguement against something like Linux or Apache: Do you really want your Student programmer debugging you webserver or opearting system?

Sorry, but I think you have never done such a thing. It is very important to be able to make the same code base run on Unix and Windows. As for this being as difficult as porting a C++ program, you don't have the faintest idea of what you are talking about. Perl, OTH, will usually run in both platforms without changes.

But why is this important? I think the point was that the platform the application runs on is at least as an important choice as the language it is written in, if not more so.

[ Parent ]

Re: Cross Platform (5.00 / 1) (#21)
by Pac on Sun Jul 16, 2000 at 09:28:53 PM EST

Why shouldn't a VB programmer be able to at least try and debug a C++ component? You could use the same arguement against something like Linux or Apache: Do you really want your Student programmer debugging you webserver or opearting system?
You are talking about two completely different things. [this is a very simplified example] The student trying his/her hand at some kernel function in Linux will submit it for peer review. Eventually, if us lesser entities find it worth, Linus, Alan Cox or someone else at the inner circle will say if it is good enough to be included or not. No company has the manpower of the Open Source efforts.
What will happen is that your would-be C++ programmers will start to introduce bugs in the software, some of them subtle enough as not to break the whole thing at once. This way lies Hell.

But why is this important? I think the point was that the platform the application runs on is at least as an important choice as the language it is written in, if not more so.
If I would say something about it, I would say that being cross-platform is far more important than the language it is written in. It is a given that almost any application can be written in almost any of the general languages. So you develop it with the language more adequate to the people you have. If it is a Java shop, do it in Java, if you have lots of Perl guys around, do it in Perl.
But porting an application to another platform, if it was not written in portable language to begin with, is a major nightmare. It is one of the most important points that led to java development and to the prevalence of very portable script languages for Web development (Perl, PHP, Python).
Also,Web application must be specially resilient to political conditions. Your company may suddenly decide to change ISPs, and so your formerly Unix app must now run in NT (or vice-versa). This happens all the time. If you haven't planned for it, you have to code it all over again.

Evolution doesn't take prisoners


[ Parent ]
Re: Cross Platform (none / 0) (#24)
by Anonymous Hero on Mon Jul 17, 2000 at 03:50:10 PM EST

> No company has the manpower of the Open Source efforts.

The manpower of Open Source software has been heavily over-inflated. There are a finite number of eyeballs in the world. Of these, there is a small subset of people that have the training or background necessary to be considered programmers. Of these, there is a small subset that are willing and able to work on Open Source projects (be it professionally or on personal time). And there are a large number of projects to draw eyeballs to. While an individual can work on multiple projects, doing so further limits his productivity on any given project, as his time is limited. As a consequence, the "sexiest" projects (OS's, kernels, GUI's) tend to get the most eyeballs, while other "open source" projects may only have a few developers contributing in any way. While the idea may sound good in theory, there are real world limitations to the gains that any software development system can achieve.

[ Parent ]
Re: Cross Platform (none / 0) (#26)
by spiralx on Mon Jul 17, 2000 at 04:04:31 PM EST

The student trying his/her hand at some kernel function in Linux will submit it for peer review. Eventually, if us lesser entities find it worth, Linus, Alan Cox or someone else at the inner circle will say if it is good enough to be included or not.

Eh? You're arguing against something that was never said. You said you wouldn't want your VB programmers debugging into VC++ code, and he said how is that different from a student programmer debugging into the Linux kernel? Nothing about submitting code in his post at all.

Even if these VB programmers did find a bug in the VC stuff and try and fix it (which is really unlikely), how is this any different from said student programmer trying to hack the kernel himself? They can both do it locally but to get the change applied globally they are going to have to submit it somewhere.

Oh yeah, and your many eyes argument isn't really that valid when it comes to the kernel, since there are only a small number of developers involved with coding and maintaining it. And as for all the people who build their own kernels, how many of them have either the skill or the time to read the source code? There's not as many eyes as some people would like you to think.


You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
[ Parent ]

Re: Cross Platform (none / 0) (#38)
by Therac-25 on Fri Jul 21, 2000 at 09:45:38 AM EST


The difference is is that the student programmer is likely a C/Unix programmer (knowing most University courses), and he's debugging C/Unix code - same language, etc.

A VB programmer trying to debug C++ is a different thing entirely.
--
"If there's one thing you can say about mankind / There's nothing kind about man."
[ Parent ]
Exactly! (4.00 / 1) (#29)
by Anonymous 242 on Tue Jul 18, 2000 at 08:05:31 AM EST

But why is this important? I think the point was that the platform the application runs on is at least as an important choice as the language it is written in, if not more so.

Why on earth would anyone intentionally choose a vm that is restricted to one platform, Windows, which takes away having a choice for which platform to run on? Choosing Java (or Perl or PHP or Python ...) leaves open the choice of platform. The platform most suitable for the task at hand can be chosen and (assuming the programming was done intentionally) ported with a minimum of trouble. For example, a client that I work with is farming out the porting of 1,000,000+ lines of code written in C++ for Solaris to AIX. Thus far, there have been very few compatibility issues.

And for what it's worth. IBM's Visual Age for Java will allow the programmer to compile to server side native executables on a half a dozen or so different Unices. Java doesn't necessarily mean a vm. The vm is only the most popular platform for Java.

But the key thing to keep in mind is that .Net is still vapor. In the press release I read, Bill Gates mentioned something like a three to five year roll out. In the meantime, programmers around the world will continue to deliver robust solutions in Java, Perl, Python, PHP, etc.....



[ Parent ]
A VB programmer debugging C++ code? (none / 0) (#35)
by marlowe on Wed Jul 19, 2000 at 02:57:10 PM EST

I doubt that the average VB programmer would be competent for such an undertaking.

Anyway, people who program at the scripting language level shouldn't have to be concerned with details of the platform. That's an entirely different level of abstraction.

-- The Americans are the Jews of the 21st century. Only we won't go as quietly to the gas chambers. --
[ Parent ]
Why only Windows? (2.00 / 1) (#22)
by baka_boy on Mon Jul 17, 2000 at 02:26:14 PM EST

--- begin cynicical but heartfelt analysis ---

The thing that I don't understand is Microsoft's refusal to let Windows die. They really could have at least another five to ten years of monopolistic glee if they would realize that the desktop OS is now a commodity. It almost looked like they got it, when they used IE as a loss-leader to tie people to their idea of what the web should look like. I shuddered when the rave reviews of IE 5 for the Mac started coming out, for one simple reason: the browser is the new OS, so far as the end user is concerned.

Just look at the release cycles, feature wars, and marketing hype that surround any serious browser contender these days: Mozilla, the eighth wonder; IE, the steady incumbant; Opera, the euro-roadster; etc., etc. When every new file manager's local views begin to look like HTML, we know that the hyperlinked, graphical navigation style of the web has become the new standard.

So, all MS really has to do is lean on the browsers. Give Windows away, open the source, burn the EULA's; it doesn't matter, so long as they control what people see through their browser window. No web or application server is worth a damn if its output doesn't render properly. What's that? You want to set up a Linux cluster to serve your snazzy new B-2-B web service? Fine -- you'll just have to sign on the dotted line for a rental license to the new XML-based, SOAP compatible, 256-bit encrypted, NDA-covered, Exchange/IE/.NET protocol.

It seems to me that splitting MS can only make them twice as dangerous: the OS group, saddled with being the scapegoats, can die noisily, drawing all the attention from the quiet, respectable boys humbly working away at IE 6 and the new Exchange Server. Next thing you know, MS-Apps will have suddenly had a banner quarter, and have captured 95% of the US market for browsers, application servers, and groupware! But, of course, they will have learned from the wise men in Washington: now that those nasty OS boys are out of the picture, everyone can play in the Microsoft sandbox!

--- end analysis ---


Re: Why only Windows? (none / 0) (#23)
by cypherpunks on Mon Jul 17, 2000 at 03:38:27 PM EST

The thing that I don't understand is Microsoft's refusal to let Windows die. They really could have at least another five to ten years of monopolistic glee if they would realize that the desktop OS is now a commodity.

Hmm...the dominant desktop OS is Windows. Next up is MacOS. Be doesn't have the market share. And I've yet to find a version of UNIX that holds any real value as a desktop OS. Linux doesn't do it for me (sorry, but I've had too many "kernel attempted to free NULL pointer" errors to even consider running it anymore). The BSDs are nice server/firewall OS's, but not desktop OS's. Be is sweet, but the apps aren't quite ready yet (NOTE: I haven't tried GoBe yet). MacOS has a really nice interface, but the underlying engine is still lacking (and yes, I know that Mac OS X should change this). As crappy as Windows can be (hell, it won't even install on one of my machines), it still presents a better overall experience as a desktop OS than most of the rest of what's out there.

Just look at the release cycles, feature wars, and marketing hype that surround any serious browser contender these days: Mozilla, the eighth wonder; IE, the steady incumbant; Opera, the euro-roadster; etc., etc. When every new file manager's local views begin to look like HTML, we know that the hyperlinked, graphical navigation style of the web has become the new standard.

And yet another crappy defacto standard get's installed. Somebody please shock me and come up with something original and useful.

[ Parent ]

glad to see positive comments (1.00 / 1) (#27)
by mbharrin on Tue Jul 18, 2000 at 02:35:23 AM EST

I'm glad to see some positive comments about .NET besides those from http://www.microsoft.com or the w2k-friendly websites. I watched the 5 webcasts from 6/22/00 and was blown away. This is some really cool stuff. Until then I had been firmly in the Java/UNIX world (10+ years on UNIX, less on Java :) and had never given MS a second look. Those boys in girls in Redmond definitely have been keeping busy -- i've spent many days just digesting all of this and i don't even have my hands on c# or the .NET framework yet.

To the poster who mentioned CORBA... try looking into COM+. CORBA has been around for quite some time and never really took off like it could have. Why should we stick to a poorly accepted and expensive technology? have you priced a developer's license for CORBA lately? beaucoup bux.

Re: instability in Windows. I can't comment on the pre-win2000 scene, but it's hard to believe that linux is any more stable than a properly set up and properly maintained win2000 server, especially when clustered. the stuff just works.

re: c# as a Java clone. one could make the argument that since both Java and C# aimed to be a simpler C++ that both languages would end up looking the same. but yes, i see your point. :)

Sun: one language, many platforms.
MS: one platform, many languages.

-m.

Re: glad to see positive comments (none / 0) (#32)
by Anonymous Hero on Tue Jul 18, 2000 at 03:21:04 PM EST

Why should we stick to a poorly accepted and expensive technology? have you priced a developer's license for CORBA lately? beaucoup bux.
Well, try TAO, ORBit, MICO or any of the other free ORBs at Free CORBA website?

[ Parent ]
Non-cross platform bytecode (3.00 / 1) (#28)
by RedGuard on Tue Jul 18, 2000 at 07:20:55 AM EST

> It includes a run-time engine that interprets and/or
> compiles byte code (in a language called "Internal
> Language" or IL). This is similar to a Java Virtual
> Machine except that (a) it is not cross platform
> compatible and (b) it is designed from the start to be > used by multiple languages.
>
Even x86 machine code is cross-platform in the sense
that you can emulate it, I'd be suprised if MS have
managed to write a non-cross platform bytecode.
Perhaps the non-portability comes from the dependance
of .net programs on Windows only COM objects.

.NET *is* cool (2.00 / 1) (#30)
by jmason on Tue Jul 18, 2000 at 12:14:10 PM EST

... at least in the design stage, and if you buy MS' "one platform to rule them all" point of view.

I hope the Open Source world does write a .NET-a-like. It can happen; there's a lot of people with an open-source mindset writing server-side code at the moment, in a multitude of languages, and they can see these problems too, and will be able to see the benefits of writing something cool like this.

BTW -- regarding flames: MS are the masters of FUD and vapo(u)r -- but this is good technology. Whether they deliver or not is irrelevant to this story; what is relevant is whether or not the Open Source world can come up with something comparable or better before .NET's Q3 2001 (iirc?) delivery date ;)

I think now that someone's come up with a specification, we might start seeing some evolution from Perl, Python or PHP in those directions. And that will be good!



whatever (4.00 / 1) (#31)
by stimuli on Tue Jul 18, 2000 at 01:16:32 PM EST

This is especially the case now Java is focusing more on server side programming - lets face it - if you write your Java program for Solaris you are unlikely to switch to Windows. Even if you do, it is likely you are going to have to make almost as many changes as you'd make switching a clean C++ or Perl program across.

Oh how wrong you are. In my company for instance, our Servlet based platform is being ported to run on many Unices as well as NT. You see, our customers who run Solaris don't want NT, and our NT customers don't want to hire a bunch of Unix folks.

Odd how that works.
-- Jeffrey Straszheim

CORBA (2.00 / 1) (#34)
by Dacta on Wed Jul 19, 2000 at 02:16:09 AM EST

A lot of people are suggesting CORBA as a competitor to .NET and Java.

It's not - yet. It has been around for a long time, true, but it isn't really in the same market.

CORBA is a standard for remote objects, and that is all it is - there is none of the standardised framework for building robust component based applications. COM+ and EJB are component standards and frameworks.

For instance, both COM+ (or COM and MTS) and EJB offer standard and highly scalable ways of managing database connections. There is nothing in the CORBA standard that offers that kind of thing.

In late 1999 the OMG approved the CORBA Component Model which does go some way towards filling these kind of gaps. Unfortunatly, no vendor has supported it yet, so you can't actually use it - unlike most of the EJB and COM+ standards. (And yes, much of the COM+ stuff you can do now using COM, MTS and ASP.)

Read Roger Sessions June 20 newsletter for some intro on this.

Infact, read all of his newsletters if you really think none of the MS stuff is good. He's biased in favour of MS, but he really does know what he's talking about. (He used to be on the OMG technical board.)

I had a look at Jabber, too.... I think that is a LONG way off being a competitor. (BTW, has anyone actually got WinJab to compile? It seems to be missing a lot of stuff from CVS. I've left a message about it on SourceForge, but no reply as yet).

Requires massive compiler extensions (none / 0) (#36)
by aphrael on Wed Jul 19, 2000 at 03:23:58 PM EST

I've been reading various slide shows given at the recent professional developer's conference related to .NET and C#. It's all a little fuzzy (powerpoint presentations usually aren't that detailed technically), but the impression i'm getting is that compiler vendors have to modify their compilers to generate metadata for objects, which are then bound into the executable as resources, and accessed via the common language runtime. This allows the intermediary layer to completely replace most of COM, and serve the object to the client --- which must also be generated by a compiler that knows how to read the metadata and map it onto a language-specific object. If this is true (and, as I said, the slides certainly imply it), then what MS is attempting to do is to create a standard for *runtime type information* generated by compilers on the windows platform. I'm not convinced that (a) that's a good thing, or (b) that other compiler vendors will go along.

My god... (none / 0) (#37)
by Anonymous Hero on Thu Jul 20, 2000 at 12:14:59 AM EST

MS is giving us the ability to write web applications in any laugage we like??

You mean, i couldn't write web apps in C,Perl,Python,Java,C++,LISP,Modula-2,Pascal,bash,or even assembler before??

And pray tell, why would i want to develop with any of these languages in a development environment that doesn't even have a fucking 'Word Wrap' function???

Ever tried writing complex ASP, where you have long lines of HTML (cos breaking them with CRs fucks up tables) in Vis Studio??

Its shit, the whole MS programming paradigm is shit.

.NET is shit, and fucking IE with it's security holes and huge service packs is shit too.

I thank my stars i have spent the time getting to the point where i can be more productive with Linux than Windows.





Taking another look at .NET | 38 comments (27 topical, 11 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!