Slashdot Mirror
Perl and .NET
Kaufmann writes "Good old Perl guru Nathan Torkington has an article on O'Reilly's perl.com about "What every Perl programmer needs to know about .NET". It's quite short and, unsurprisingly, favourable to .NET (although not to Microsoft). Points to the SOAP module on CPAN and a bunch of other stuff. It contains a nasty error, though: claims that Java is the only language that compiles to the JVM. Check it out anyway."
It's already released (well, as beta at least). MS sent out the beta kit for Visual Studio .NET about a month ago, anyone can get it and try it out. A few weeks ago, ActiveState released the Visual Perl plugin for VS.NET, along with Perl for .NET.
I'd say .NET already has a strong presence, for better or for worse. The Question really is when it's actually going to be released as a final product.
"We obviously need a new moderation category: (-1, Woo-fucking-hoo)" --Mr. AC
"impossibly inefficient"? It's a "serious abuse"? I beg to differ. It's not like building an XML document and sending it in an HTTP request is an O(n) algorithm or something. Yeah, maybe you can preserve CPU and bandwidth with some pure binary stream protocol, maybe even direct marshalling of your internal data structures. Like, say... many other similar protocols in the past. But you lose intercompatibility, convenience, blah blah blah.
Seriously, it's not that heavy weight. And you DO NOT need to build a DOM tree, there are myriad alternatives, such as event-driven processing of XML for one. XML-RPC is very easy and very simple. I can't speak for SOAP, not having used it, but XML-RPC has performed great in my work. It crosses OS'es, crosses languages, crosses platforms, and leverages protocols and knowledge we already have. This is great stuff.
Honestly, CPU power is cheap. In comparison to my hours producing something and diagnosing problems, CPU power is nothing. People are expensive, computers are getting ever cheaper and more powerful. Hell, cut back on bandwidth by using some of that cheap CPU power to gzip the XML stream as it goes across the network. As far as I'm concerned, fretting over the performance hits (which are really close to negligible from what I see) is silly when faced with how easy things can get.
Where Microsoft betters Sun is that while Java is the only real language that compiles to the JVM, Microsoft intends IL to be cross-language.
It's already been pointed out that this statement isn't true. Here's why, for those of y'all that don't already know. :)
First off, Java isn't the only programming language (or even the only "real" programming language) which works with JVM. One can point to JPython as an example of a language which works with JVM. (Of course there are many out there who think Java isn't a "real" programming language. I'm not going to argue with them too vigorously, execpt to say that if BASIC on the Apple was a real language, then there's no reason why Python shouldn't be, either.)
The second reason, which is more substantial, is that JVM, while not exactly an open standard, is pretty much available to the public. In particular, the byte codes are well-known. While it's not trivial to port a language to a new instruction set, it's far from impossible. The only reason why there isn't, for example, a JPerl, JSmalltalk or JOberon, is because nobody's done the port.
Microsoft does have a vested interest in making .NET as widely useable as possible. That will probably include porting other languages to .NET, and maybe the unthinkable, porting .NET to other operating systems. Then all they'd have to do is keep .NET proprietary (but sell, for example, a standardized .NDK for people who want to port their favorite languages to .NET) and they could make a killing off the platform. Then it would be Microsoft versus Sun. A very ugly battle indeed.
ObJectBridge (GPL'd Java ODMG) needs volunteers.
Finding God in a Dog
It would also be a great way to introduce a lot of people to free software. Once they saw the alternatives to Micro$oft bloatware, they would never go back.
They are plowing ahead so quickly that they will cause their own destruction, and Linux will step in to pick up the pieces and allow people to get work done better.
Even Slashdot wants to hide some things
If I may make myself look smart after other people have corrected my mistakes on other fora: .NET has, at present count over 15 languages that work with it. To be sure, C#, Java and VB are not that different in principle, but languages like Scheme and ML have been integrated as well. This is no mean feat. Legacy code is catered for with COBOL and others. PERL and Python to round up the internet/scripting programmers.
They are so well integrated that an object in one language can be subclassed in another. Early reports are favorable - it remains to be seen if this amount of multi-language integration is a good thing (tm), but it's definitely an experiment to watch.
BTW, .net is thought to be more portable than win32 so it's not inconcievable that MS are contemplating cross-platform as well as cross-language.
MS is allowing third parties to plug in thier own languages, but comercial windows programming language vendors won't exactly be thrilled by the prospect of thier tool being reduced to a plugin for visual studio.
I'm thinking specifically of my favorite toy, Borland Delphi, here - are there any other major Windows programming tool vendors besides Borland any more? Microsoft's genius is that whilst other people may get good at thier game, they are in a postion to change the rules, and periodically they do. This is one of those. No wonder Boland are running for the safety of Linux.
BTW, one of the languages in .net is component-pascal, an OO descendant of Oberon, Modula and Pascal. I have no idea what's really like, or if it's ready to leave the safety of academia yet, but it's a carrot - from a brief glimse it looks nice. Oberon was used to implement an OS, so it can't be that constrictive.
My Karma: ran over your Dogma
StrawberryFrog
My guess is sooner or later we'll get binary XML encoding, then some "preparsed SOAP", and then finally something similar to CORBA - or M$ would switch to CORBA, which is unlikely because it means, gods forbid, Java compatibility
Opinions are mine only and could change without notice.
Obama 2012: our incompetent asshole is slightly less of an incompetent asshole than the other incompetent asshole !
Doing more with less is a good philosophy for a sustainable human existance. SOAP is the opposite. SOAP does the same shit and uses more resources in the process.
Think for a minute on my point. What if you could reduce the number of computers in use in the world by half, and along with that reduce the amount of energy and human effort needed to design, build, and operate those computers, simply by using more efficient software? Would that still pale next to the awesome value of your personal time?
Poor choice of words on my part, sorry for the confusion. See http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml for a great list of languages that compile to the JVM.
--Nathan Torkington
Heh! This will make all current firewalls obsolete as not there will be all of your data going thru the 80 port. To me, this means that the firewall is now useless....
I'll agree that XML-RPC is inefficient compared to CORBA, but you would be surprised at how useable it is. A long time ago I decided that I wouldn't shun a technology because it was billed as slow until benchmarks show it really is too slow for what I am using it for. I used XML-RPC in enterprise medical systems, and it was never shown to be an important bottleneck.
Plus, you can do so much more with it. The area I found it to excel the greatest in was in security. When you are bulding the XML response, you can be choosy as to what fields you include beased on the user in the session. Contrast this to passing an object by value. It becomes an all or nothing prospect.
Then there is the small bonus that testing your client involves writing a static XML file served to it when it makes the call. It makes automated tests a lot easier. This is a good thing for an XPer, like myself.
Another thing is that is does greatly simplify a design. You don't have to force everything into terms of object models. You just think of it as formatted data, formatted however is logical for the call. This really is a great, and better experienced than explained.
One final note (although there are other good things about XML-RPC), if you are making a web applications, using XML-RPC to distribute the system, gives a homogeny to the model. This is a good thing, because it also makes the overall metaphor for the architecture easier to understand.
It is important to note that XML-RPC is not intrinsic to .NET. The systems I've worked on with it have all been J2EE systems. I just finished a JSP taglib, that, among other things, allows you to select blocks of JSP to include based on the Accept tag. It also does XML/XSLT with xalan. With this, you can use the same application logic for HTML, WML, and XML agents. You can use XMl-RPC to call into .NET (I've done this calling into ASPs before .NET) and .NET can call into J2EE systems. And Sun is a large SOAP supporter.
-no broken link
The above is what turns me off of SOAP, XML-RPC, and the like. The actual implementation is impossibly inefficient. To make a SOAP call, one's software must build an XML document and an HTTP request, and send them together. To handle a SOAP request, the software must not only handle the HTTP protocol, but also build a DOM tree from the request body and act on the nodes of that tree. This is a serious abuse of CPU power, and not the way to build a performant system.
I like systems that are easy for programmers, but I also like those systems to have advanced, efficient, performant implementations. The two goals need not conflict.
ObPythonPostInPerlThread:
.NET along with Perl, and it can do SOAP as well. Moreover, JPython already makes Python a Java platform language. In other words, it doesn't matter who "wins" the cross-platform war, Python is already there.
Python will also be part of
Comment removed based on user account deletion
I recently saw a presentation by Microsoft about .NET and they said something along the lines of:
.NET standard libraries.. However, until they do, any app you wrtite on .NET will not work on another platform since the libraries you depend on are not available for that other platform.
.NET is definitely showing a lot of promise and I think it warrants some attention on all fronts; even by the most die-hard GNU & open source & Linux fans.
"Interestingly, because we [Microsoft] are standardizing the common language runtime with a standards body [ECMA], they will *require* us to do two reference implementations. One of them will obviously be Windows (NT + 9x) but the other will be some 'open source' operating system, such as BSD."
Then he stopped, paused for 10 seconds and said "or Linux..". Paused for another 10 seconds and said "or possibly even both".
I asked if standardizing and thus implementing the common language runtime on BSD/Linux would mean just the runtime or also the standard libraries and to that, he replied that it just meant the common language runtime (the equivalent of having the JVM standardized and ported but not the Java core API). He continued that he was very sure the open source community would quickly write their own version of the
Seems to me Java still has an edge but
Hate to burst your bubble, but the O'Reilly book "Learning Perl on Win32" was written by the founder of ActiveState. Also, from the beginning there was always much more development done on the ActiveState port of Perl than the "pure Perl release" you mention. ActiveState was started with a grant from Microsoft, and since its inception it has worked the "pure Perl" people to merge the two products.
Therefore, Microsoft essentially funded the development of Perl for Windows systems, and also came up with the worlds first Perl IDE. ActiveState, essentially a subsidiary of Microsoft, is also releasing the Perl IDE as open-source software for Linux.
I watch the sea.
I saw it on TV.
No, Thursday's out. How about never - is never good for you?
What is it? (according to Jim Farley of O'Reilly)
.NET in various forums are reminiscent of the fable of the three blind men attempting to identify an elephant: It's perceived as very different things, depending on your perspective. Some see .NET as Microsoft's next-generation Visual Studio development environment. Some see it as yet another new programming language (C#). Some see it as a new data-exchange and messaging framework, based on XML and SOAP. In reality, .NET wants to be all of these things, and a bit more.
.NET platform:
.NET and J2EE compare?
t ml
Current ruminations about
First, let's get some concrete details. Here's one cut at an itemized list of the technical components making up the
C#, a "new" language for writing classes and components, that integrates elements of C, C++, and Java, and adds additional features, like metadata tags, related to component development.
A "common language runtime", which runs bytecodes in an Internal Language (IL) format. Code and objects written in one language can, ostensibly, be compiled into the IL runtime, once an IL compiler is developed for the language.
A set of base components, accessible from the common language runtime, that provide various functions (networking, containers, etc.).
ASP+, a new version of ASP that supports compilation of ASPs into the common language runtime (and therefore writing ASP scripts using any language with an IL binding).
Win Forms and Web Forms, new UI component frameworks accessible from Visual Studio.
ADO+, a new generation of ADO data access components that use XML and SOAP for data interchange.
How do
quoted from : http://java.sun.com/features/2000/11/dotnetvsms.h