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
Ironic I write this because I'm done early with my APCS work... and there's nothing wrong with not knowing something as long as you don't pretend you do, then go and try to find out said thing...
This page: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml offers a nice overview of languages built on top of Java. Some of them (e.g. AspectJ and JPython) are very interesting. The JVM can already interoperate with COM (i.e. embedding java in visual basic is dead easy) so consequently all the languages on top of Java can use it as well. Assuming .Net builds on top of com, java .net interoperability is already there. No doubt Sun or someone else (voyager?) will fill in the missing pieces (if any) soon after .net is released.
Jilles
Oh man that's funny MS actually going to deliver some cross platfrom thingie. That's just rich. Thanks for making me laugh so hard.
This is a good point, even if it's from an AC. We should be skeptical of Microsoft's claims in this regard, given their long history of promising new technologies in order to retard the market and then ultimately not delivering. Also, consider that Microsoft really has very little motivation to provide a truly cross-platform development environment, but strong motivation to provide a competitor to Java.
If .NET is successful (and it may very well be if the technology is as cool as some people are saying -- and we know Microsoft's name will get it some serious attention even if it's crap) and if MS can keep control of it, I predict that MS will make sure that the non-Windows versions always lag just a little behind the Windows version, making it possible to argue that Windows is the better platform for .NET software.
Then again, maybe MS is finally deciding that, in the long run, locking your customers in is a bad business practice. IBM managed to learn that lesson and has become a staunch supporter not only of open platforms and Java, but even of open source software (not that DB2 will be GPLed anytime soon).
Nahhh... IBM had to get beaten severely about the head and neck before learning that lesson. MS has barely been bloodied...
Outside a dog, a book is a man's best friend. Inside a dog, it's too dark to read. -- Groucho
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Java failed (or at least is failing) because Sun focused Java on one langauge. Whether or not that one language can do everything you want is irrelevant, there will always be people (and lots of them) that won't like your language and want to use something else.
.NET.
While it's true that lots of languages can now target JVM's, this is not widely known, and for the most part the people that do know it say "so what? The JVM is dead".
Microsoft solved this problem by making the language a preference choice from the beginning. By emphasizing the CLR and IL from the get-go. Sure, C# has gotten lots of coverage, it's not the primary focus of
.NET has become a platform, instead of an environment or language in most peoples eyes. And one other thing, MS has submitted C# and the CLR to the ECMA for standardization, something that Sun said it would do, but then refused at the last minute (several times).
IMO, Microsoft is doing the right thing here. I know it's hard to trust them, and you probably shouldn't, but you can still recognize a good thing for being a good thing.
If you need web hosting, you could do worse than here
I suspect you don't understand the value of firewalls.
You can still stop external computers from initiating connections to local computers. No need for the whole world to see my intranet web server. So blocking incoming port 80 is still valuable. Maybe I have a public web server behind my firewall, I can block incoming port 80 for all destinations except my public web server. The rule of thumb that you should firewall all incoming ports you don't need remains useful.
This leaves outgoing ports. If you open HTTP, a desperate enough program or user can always sneak out through the port. If it's possible to tunnel IP over DNS, it's darn well possible to tunnel IP over HTTP.
All you've lost is your false sense of security.
Search 2010 Gen Con events
"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. "
Not really. Just don't fill out the data members that you don't want to. Perhaps include a mechanism for checking which ones are valid. Or, use a map/dictionary data member. You can be as selective as you like with CORBA objects, and there are many ways you can implement that.
The end user gets applications written faster, that do more, install easier, and have fewer bugs. That's about it - the same benefits the end user gets with every big improvement in developer tools and back-end tech.
Oh yes, we have a winner here! Because as everyone has noticed the bug count on new software has been declining in the last decade due to the big improvements in developer tools.
Yes, we finally have it, THE SILVER BULLET!
And I have a bridge to sell you...
Implementing a half-working version of Python for .NET and an actual production ready version of Python for .NET are two very different things.
.NET is at best an admirable academic attempt. Its so far from actually being useful for anything that it is quite laughable that you are applauding all of the cross language support for .NET.
.NET is a language neutering wreck of a platform. The real meat and potatoes of these languages under .NET have been stripped away. You are left with a few looping constructs and the MS's common language runtime classes which do EVERYTHING.
The code for Python under
IMO,
And Sun is a large SOAP supporter.
A large supporter? What do you base this on? The last I checked Sun hasn't done anything noticeable with regards to SOAP.
In fact, the OASIS group just recently rejected SOAP as their transport protocol and I believe Sun is a large supporter of that effort.
They've also announced the early access release of the JAXM API (XML messaging) so I'm wondering where you're getting this "large SOAP supporter" point of view...?
I completely agree. I've just completed a projected that benefitted from XML. I developed a plug-in for third party tools. We used an XML based document as way for those tools to pass data to my stuff. This saved us a lot of effort: we didn't have dilly-dally around with syntax, we could just get on with semantics; we didn't have to write parsers; they were able to test their output before I was ready to use it through the XML DTD and third party parsers; we saved a lot of time in testing too; they were able to get up to speed on our data file format much more quickly, and didn't have to worry about quirks.
"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.
The perfect article to unveil my new .sig!
"And like that
Microsoft has already submitted .NET (well, at least C# and the CLR (the CLR is the VM)) to the ECMA for standardization.
If you need web hosting, you could do worse than here
Thanks! Now it's all making more sense... and you did it all without using a single cuss word. Whaddya know? ^_^
Why are you assuming people want what Linux has to offer over what Windows does? If you truly believe that Linux is a better OS then you are completely unaware of what most people want in an OS. The power user and developer community is very small.
.NET may become cross-platform, but that won't stop people from using Windows. You should really stop bashing MS just for the sake of it. .NET is an amazing platform to develop for and if it does become cross-platform it will revolutionize the way most professional developers write web applications. If .NET doesn't become cross-platform then it will be neglected by all but VB and ASP developers.
The global economy is a great thing until you feel it locally.
And anywho, it always fastest to just code everything up in assembly. You just have to decide where you draw the line between ease of implementation and speed of execution. I don't mind drawing it above and XML parser and HTTP client server.
As for HTTP, most firewalls will let it through so sys admins won't have to start opening up new ports for this newborn system.
There are other ways of doing this, such as CORBA. Look how that caught on like wildfire!
Nah - perl support is just a concession - a PR move of sorts.
.NET is open - see - it can use perl!" while surrepticiously "enhancing" the support for C# and VB - so more .NET developers will start moving over from perl to C# (I can't see VB being big with perl people, no matter how hard I try) for the added features/support.
.NET stuff. I doubt it - but it could happen.
M$ adds support for their new C# language, and for Visual Basic (their 'we're going to shove this down your throat whether you like it or not' language), and perl.
M$ controls C# and VB. It doesn't control perl. Basically they'll say "Hey -
At least, that's probably how M$ is looking at it.
It's entirely possible that this will go the other way and perl will become the standard language for
M$ doesn't need to make it's own perl - it just has to shoulder it out of the way.
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
"Not Real" languages: Tcl, Haskell, Lisp, Scheme, BASIC, LOGO, Eiffel, Smalltalk, COBOL, Ada. More at Programming Languages for the Java Virtual Machine
Strange, you just described .NET. Amazing.
.NET allows you to mix both bytecode (IL) and native code. And it's a standard (or will soon be, as soon as the ECMA approves it).
C++ for
If you need web hosting, you could do worse than here
"ActivePerl has all the problems you'd expect from a Microsoft-oriented product, requring forced upgrades of Microsoft software. (Requires NT Service Pack 5, Internet Exploder 5, Microsoft Installer 1.1, etc.) "
So? What do you want? Support for Windows 3.1? You have to draw your line somewhere when it comes to compatibility. They just happen to have chosen a spot that is between major releases of NT. It's a balancing act: make your life hard as a developer by not using newer technologies, or piss off a diminishing subset of users. I could complain that as a Slackware v2 user, that everything these days requires an upgrade to glibc!
If .NET doesn't become cross-platform then it will be neglected by all but VB and ASP developers.
Possibly true, but that still is a metric-buttload of developers. Where I live, it's a lot easier to find work doing that then even Perl.
The Linux community really must get on board with this. IMO trying to outdo Microsoft might be possible by actually riding it's coattails on this one for a while. A web service implemented on Win2k for a bazillion dollars in hardware/license fees, etc. that could be implemented easier, cheaper and faster on Linux would be a reason to switch for a lot of people.
As somebody firmly in the Windows world, it is my feeling a lot of people don't approach Linux/BSD, etc. because it is hard for them to make the correlation between the stuff that they do/use/build with Windows and how you would do things on Linux/BSD. Lots of Windows developers got their start writing macros in Excel in VBScript.
Just a thought. Jeff
How long did you think blocking a port would sustain security? Ultimately, all traffic coming across the wire will have to be scanned, likely by highly adaptive heuristics that will attempt to discern the intention of the bits coming across. In this sense, SOAP may be useful - at least with a standard for encapsulating RPC over HTTP, we can strengthen this heuristics pre-emtoively, as the standard is being advanced.
Can anyone point me at the definition of MSIL (Microsoft Intermediate Language)? I can find plenty of overviews of it but no detailed definition such as would be required to write a Linux back-end for it.
Thanks!
It's about interoperation between the languages. JVM only supports the Java object model. No accomodations have been made for any other languages. If you want to interoperate, it can get quite difficult -- basically everyone ends up writing Java (even if it is Java in Scheme or Java in Perl).
You are also completely wrong about C++. Microsoft lets you use C++ to interoperate with .NET. You can use all of C++ (it gets generated
as binary code) and then at the edges you can use
a restricted subset to interface to .NET code (actually the restricted subset is an extension
on the side known as Managed Extensions for C++).
The switching from native code to bytecode is done for you. The .NET bytecode supports (unverifiable, but useful) instructions to do raw
pointer manipulations which mean you can access
C++ data structures from bytecode.
Your claim that there are "no major problems" is complete bullshit. The only language that compiles into JVM without problems is Java. Every language that is based on recursion has to jump through hoops just to do procedure calls. (Scheme, Lisp, Prolog, Haskell, etc). Languages with by-reference parameter passing are screwed too, they have to use crummy temporary classes (Ada, Pascal). Real dynamic method dispatch is very painful too (Python, Smalltalk).
The page listing 130 systems that implement existing languages based on the JVM fails to mention that they all suck. Doing the same on .NET sucks too, but it sucks significantly less. Microsoft have made *some effort* and have actually spent several *million dollars* getting
the feedback of 3rd party languages. Sun just
turn to 3rd party languages and say "you are
ruining our 100% Java policy -- go away!".
I know it's normal on slashdot to post about things you have only heard about 3rd hand, but since it's the holiday season perhaps people could take a little more time to read before they post. At least go back and read the other slashdot articles about .NET.
You're making the cardinal sin of judging the final products speed and memory requirements by it's beta. Chances are, .NET currently has a 4:1 debug/code ratio or more.
Come back and complain when it reaches the release candidate stage instead of barely out of Alpha.
If you need web hosting, you could do worse than here
IMNSHO SOAP is really only created because of the troubles firewalls give IIOP (protocol of CORBA) and other non-HTTP protocols. It is really just a means to go around stale security arrangements. The XML-part is just included for the buzz-word compliancy. BTW: Does anyone know if SOAP support copying object by value? In that case I guess I will not take long before we see RMI over SOAP (if Sun doesn't want to implement it, IBM will). BTW2: Does anyone know whether Microsoft is using SOAP 1.1 or 1.2 for .NET. As I have understood 1.1 is still Microsoft proprietary.
Uh no. The standard libs are VERY platform dependent as they wrap around things such as sockets, the windows gui with buttons, windows, scrollbars etc., graphics, sound, threads.. All of that is completely different on each platform. It will NOT fall into place in fact it's the exact opposite.
ODBC came first, and is, for all intents and purposes, the closes thing to a SQL driver standard that exists.
DAO was really just the first go at an object oriented ODBC.
ODBCDirect was in response to the poor performance of ODBC.
RDO was a mistake.
OLE DB (despite it's crappy name) is actually a very good system.
ADO is merely a COM interface on top of OLE DB to create data collections and the like. For all intents and purposes, ADO uses OLE DB, as will ADO+)
RDS - Anything with the word Remote in it is a mistake, dont' use it (at least from MS).
If you need web hosting, you could do worse than here
So? It's just an HTTP POST request. The XML document is probably less than 500 bytes long. It's no more expensive than POST-ing a typical HTML form (which is what browsers do for a living).
:)
500 bytes is a huge IIOP packet. The same semantic could probably be expressed using 1/10 of a bandwidth in CORBA.
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. So? Acting on the request itself (e.g. "buy 10 roses") is likely to be 100x slower than building the DOM tree.
But that's only if you want "to buy roses". What if you want to stream video? Or have real-time quake session? Because if all you want is to buy roses, frankly I don't see what's wrong with the current HTML-Form post.
DOM trees get built all the time for HTML documents. Why is building an XML DOM tree any worse?
Why do you insist on comparing this to HTML? HTML was never designed for RPC. IIOP is.
The point is that while SOAP may not be the most lightning-fast way to accomplish a particular remote method invocation, it is extremely scalable and flexible.
How is it more scalable or flexible then CORBA? Any proof?
SOAP, XML and HTML encoding is just a waste of bandwidth and latency for people who get confused by binary protocols.
Not suprised. Linux has, what, 4% of the market share? Why would they care? I bet you never heard them mention the Amiga either.
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
I have tried Visual Studio .NET + the Visual Perl plugin + the Perl to IL compiler. I have to say it's all pretty neat, assuming you are running Windows.
I fear the dark side of MS, and actually far prefer vim to an IDE, but this stuff works in a pretty compelling way. Perl is a pretty good glue language in it's own right, but if you wanted to call functions from C++, Java or VB from the same Perl code, well you would be pissing up a rope. Seems like you could actually do that with .NET. Additionally, it seems like the C# and IL specs are open enough to reverse engineer (if that's still legal) and create open source versions.
If you ask me, and you didn't, people should be catious but there is a lot they are dong right.
Er.. CLI is Common Language Infrastructure, not Interface. The CLI includes the CLR.
If you need web hosting, you could do worse than here
Here is a good definition of .NET the basis of it I found on a messageboard somewhere but I've modified it a bit:
What is .NET? In a nutshell, it is an architecture for allowing multiple languages to create executables which work on any platform (like Java, though with more multi-language emphasis). It is built with internet protocols as a foundation for intercommunication (SOAP is simply a technology to allow objects to be called over HTTP using XML as a serialization protocol).
The framework includes standards for code packaging and distribution as well as security, something made easier by the completely self-describing nature of MSIL (Microsoft's analog to Java bytecodes(stand for Intermediate language)).
Practically on windows this works much the same as activeX components. except instead of being registered.dll's they are code compiled into the IL with and XML wrapper exposing their methods/properties.
Technologies such as ASP+ and WinForms are BUILT on .NET technologies, but are NOT .NET, something which is often confused in the Microsoft documentation.
I think kawa will compile scheme to jvm :-) I have looked into some jvm assemblers as well!
Did you mount a military-grade, variable-focus MASER on an unlicensed artificial intelligence?
The article makes the very inaccurate claim that .NET differs from JVM's in being cross-language. JVM's allegedly only support Java as a language, according to the writer.
This is nonsense. There are literally dozens of languages you can use to target JVM's right now. Two of my favorites are JPython (Jython) and NetRexx. But there are plenty of others, such as functional languages, Jacl (a version of TCL), Basics, and various other special things. About the only thing missing from the list of languages that target JVM's is Perl (perhaps this informs a bias of the articles).
Take a look at: Languages for the Java VM for more information.
Buy Text Processing in Python
Consider-- a distributed application invoking methods on objects using HTTP as the transport. It's going to be difficult to near-impossible to properly eliminate this stuff at the network perimeter.
At least existing RPC protocols utilize unique transports I can allow or deny easily.
-- Cerebus
I don't know much about DOM,COM,SOAP,.NET,C#, but I'm sure if it's Microsoft it's
1) A new, improved & innovative implementation of something someone else created 15 years ago
2) A new, improved & innovative implementation with lots of fresh undebugged code that nobody is responsible for, least of all Microsoft
3) A new, improved & innovative scheme to ensure that each cpu is running licensed code by 'phoning home' to central control, somewhat like a grand global version of the old Netware "there another server with my serial #" alarm (Office is already starting to do this, with a "you MUST electronically register this product, or it will cease to run after 50 times")
4) The usual code to "detect and complain" about foreign, non-Microsoft products via complex, baffling error messages to give the impression that the OTHER code is at fault and how wonderful everying would be if you would only use genuine, interlocking, Msft products.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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 !
So first .NET is a way to require subscription fees to use Windows and Office
.NET thing also an attempt to get people to pay subscriptions for software that has been traditionally paid for once?
Is this true? MS's site addresses some of the technical details and vision issues, which may or may not have substantial merit, but is this
Contrast both SOAP and Corba to Styx/9P, the object protocol of Inferno and Plan 9, also available for other environments as a product which at least used to be called InfernoSpaces. It was available as Java classes and C libraries for several development environments.
See The Styx Architecture for Distributed Systems, Styx/9P-search on Google, a real life example of an interface to remote functionality, Styx manual pages, Inferno home and Plan 9 home.
You just mount all your remote procedures as a hierarchy of files. You call them by opening them and writing to them. You receive the results by reading them. You can inherit / modify / augment / restrict functionality of a set of procedures / files by mounting file sets (objects) as a stack / union directory, where the topmost names hide the lower names.Listing, naming and accessing of "remote objects" become trivial. Permanent and transient objects look the same, and just like regular files. Commands are usually issued as text content. So bindings to functions are language independent.
Optional authentication, data integrity and confidentility are built in, and can be configured at run time, transparent to the programmer.
Anssi Porttikivi / app@iki.fi
> Java failed (or at least is failing) because Sun focused Java on one langauge
In what way has Java failed?
By hijacking HTTP (which extant firewalls treat liberally) You're making it much more difficult to selectively allow traffic based on its purpose.
Don't worry, sysadmins. SOAP mandates the use of a "SOAPAction" HTTP header in every call. Firewall admins can filter SOAP requests based on the value of this header.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Exactly! JVM byte code was designed with one language in mind - Java. If those other JVM compilers weren't total crap, wouldn't you think we had some decent legacy software running in JVM by now? If MS really delivers on cross-language and cross-platform aspect, Java has no chance of surviving.
XML is hugely more expensive to parse than even multipart/form-data, much less application/x-www-form-urlencoded.
Even if it is (which I doubt), the parse time is typically dwarfed by the time it takes to actually execute the request, so it doesn't matter.
HTTP is stateless, and the first thing every application does is roll its own half-baked session state management
This frustrates me too, but you can hardly blame it on SOAP. It's just a fundamental conflict between HTTP (stateless) and OOP (stateful).
Constructing a SOAP request using printf() would be an absurd waste of time. Anyone with a clue will use a toolkit library, and a toolkit that generates SOAP request documents could generate IIOP/ASN.1/DCE/JRMP requests just as easily.
Okay, let's come back here in a year. You can then count up all the publicly availble IIOP/ASN.1/DCE/JRMP services, and I'll count up all the SOAP web services. The proof's in the pudding, and I'm pretty sure this pudding's gonna be made out of SOAP.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
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?
There goes the neighborhood.
Note that ActivePerl isn't entirely free software:
ActivePerl is freely distributable. However, ActiveState puts considerable time, effort and resources into developing and further enhancing ActivePerl. Charges for commercial redistribution of ActivePerl reflect our time in establishing the agreement and, if you have difficulty meeting our marketing requirements, any lost opportunities that we have in our market.
This would seem to be a clear violation of the GPL.
1) CORBA object can be made stateless too, you know. It's up to a system designer. Inability to use state actually is a big disadvantage in some systems as performance suffers and implementation gets complicated. CORBA gives you a choice. SOAP doesn't.
You can implement a stateful architecture on top of SOAP, it just doesn't force you to. I guess it's just a question of whether it's easier to add state to SOAP or remove state from CORBA. You may be right about CORBA in theory, but in practice SOAP is so simple that its rapid adoption will simply render the question moot.
2) With SOAP you need at least a full blown web server and XML-DOM parser. ORB-runtime usually is just a shared library.
Okay, but in a few years, every friggin' toaster sold by Target will have a "full blown" web server and an XML parser. Just about every server on the Internet today is already listening for HTTP on Port 80. What's the big deal?
3) IIOP can be tunneled through HTTP as easily as anything else. There are plenty of IIOP/HTTP gateways. Why reinvent the wheel when this is so easy?
Okay, but then where are all the CORBA web services on today's Internet? For one reason or another, people are not doing this. You tell me why.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
One way or another, CORBA still needs to deal with the basic problem of object serialisation. Which would seem to be close to functionaly equivalent to building a DOM tree.
There was a lot of talk about SOAP at JavaOne last year. This was before Microsoft put the SOAP stake in the ground of .NET. There have been quite a few indications from Sun that they feel XML-RPC is going to be a large part of the furture of distrubuted computing and have given more credibility to SOAP than the OMG standard (even the OMG is making CORBA XML-connectable).
As an aside, the XML-Apache group has some SOAP stuff, too. People aren't thinking of it as a Microsoft thing. Just a distributed thing.
-no broken link
To get rid of the problems of resizing (different graphics resolutions, different fonts and font sizes), layout managers as used in Java's AWT or Swing are a good solution. You specify how items like buttons, text fields etc. are laid out in a visual component and the rendering is done automatically by the manager. You'll need a while to get used to it, but then you never want to go back to pixel-based GUI construction.
I'm using Netscape now, and I hate it. Mozilla crashes every three seconds (DISCLAIMER: that is an exaggeration). Last time I tried Konqueror, I almost puked (and so did my computer). IE, quite unfortunately, seems to be the best of all the evils, but it still crashes.
I'm afraid there's no such thing as a good web browser. They don't exist.
for the record, the OS specific stuff is in a separate module. And just as webforms will adapt itself to work with whatever server/browser combo it encounters, winforms will adapt to whatever client environment it's being run in.
so they tell me.
--
Peace,
Lord Omlette
ICQ# 77863057
[o]_O
Also, I should have noted that IBM gave its SOAP implementation to Apache. It's now at the Apache site.
I think the big advantage for XML-RPC over CORBA is that ideally all of a company's processes will use XML - for EDI type exchanges, for datastores, for in-house apps - and now for XML-RPC. This means developers only need to learn one system for all these applications.
Are perl programmers so fiercely anti-java that they will rally around and support A MICROSOFT AGENDA in order to make it go away? This is a dangerous set of priorities for one to have. Theres lots of other ways to send procedure calls via XML, including the competing, Sun-supported ebxml standard. And no reason why there cant be perl modules for that also. If youd prefer have everything be controlled by Microsoft and be rebooting Windows servers all day, rather than having to write some occasional Java code along with your Perl, then you're sick in the head.
Microsoft may be better on public relations there but no on substance. Perl could easily be compiled into Java byte codes (in fact, there is a project around to do just that), just like Python, Smalltalk, Scheme, Basic, Modula, Pascal, and lots of other languages are. While the JVM is most natural as a target for a Java compiler, it is a pretty universal runtime for safe languages, and most of them can be compiled into it without major problems.
And when it comes down to the one area where Microsoft could genuinely differ, compilation of C++, they fail to deliver what they promise: only a restricted subset of C++ is compiled into their intermediate language; you could do the same for compiling a restricted subset of C++ into the JVM.
If you want more information on language for the Java VM, look here. It lists about 130 systems that implement existing languages based on the JVM.
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
I can verify that Per Bothner's Kawa does indeed compile Scheme to JVM bytecodes. There's no intermediate Java code and no need to write out a .class file. You can even do it interactively. I know that it's working because with a JIT compiler, if I make an error in a BRL page, "compiled code" shows up in the stack trace.
Before XML was buzzworded, I had developed a XML-like structure for saving data in a program I was writing (no, I'm not going to apply for a patent on it :-P). The program used plug-ins, and as the final version would have allowed user-created plug-ins, I needed to be able to account for versioning of the plug-ins. But I also needed to recognize what to do when a plug-in couldn't be found, if it didn't critically affect the program.
The XML structure allowed me to do this easily:
the data was in a tree, with keywords that started and ended each 'branch'. Certain keywords were guarenteed to work (ie not part of the plugin part), and data for a plugin identified itself as a string. If that string couldn't be matched with a plugin, the file was 'forwarded' until the end of the plugin data was id'ed. Same thing with versioning in plugins... if data from a newer plugin was not understood by the older one, then the plugin could fastforward into the file to get past that extraneous data.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
If anything, .NET saves PERL from obscurity.
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....
Also worth noting that Xerces is not the fastest Java based SAX parser in the west ( or the east for that matter ). In some tests I've done the Crimson parser originally from Sun, also available from apache is much faster than Xerces, say twice as fast. Oracles parser is also of comparable speed to Crimson.
So you could get even better numbers.
Gudge
The IL (is this different from MSIL?) instruction set seems to be documented in Part 3 of the C# and Common Language Infrastructure draft standard .
:-)
At first glance, it looks pretty detailed - I guess we won't know if it's detailed enough to implement the CLR on Linux until someone tries it
DTDs are extinct
coupled with the meaningless complexity of the DOMs
qualify this statement. How is the DOM overly complex? Are you aware of SAX, literally a Simple API for XML??
Interesting point. I thought many firewalls already inspected HTTP headers for this sort of stuff, but I guess not. Have to admit that I'm not a firewall expert. I can tell you for sure that SOAPAction was designed with this intent in mind. At least SOAPAction is case-sensitive, so you don't have to worry about that.<grin>
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Good philosophy: "doing more with less" -- but less of what?
What the market deems to be most expensive: Human effort.
Sorry, but I think you're way off base. By your argument we should still be hand-rolling assembly language programs.
We (as humans) don't have the cognitive capacity to make new levels of complex software unless we leverage abstraction and indirection to "stand on the shoulders of giants", so to speak - those who CAN specialize in writing protocols and compilers and languages.
Go back to making your fire with flint...
-Stu
I think more people are sick of your B.S. than other people's.
LISP is a language that's over 40 years old, has been used widely, and only in recent times has become less popular.
CORBA is extremely widely adopted throughout various enterprises in the world -- way moreso than XML and SOAP are. Naturally, XML will probably eclipse this eventually, but probably NOT using SOAP.
Get YOUR facts straight before you launch a clueless rant.
-Stu
Y'know, a year or two ago, this post would have been modded UP a couple of points ("Insightful" or "Informative").
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
A requirement of the EJB 1.1 spec is that all RMI calls must go over RMI/IIOP.
RMI is just an interface.. the wire protocol mattered less once IIOP supported pass-by-value.
-Stu
I have recently looked at Eiffel# for example, it is only a single-inheritence version of Eiffel!!
You can call this an Eiffel look-alike if you wish but for me it is not Eiffel..
I hope that the other # language are less castrated than Eiffel...
Semantics is what is interesting, but after parsing XML, DOM does not provide rich or useful semantics for manipulating hierarchical data.
> Next thing you know we'll be drawing to our screens with .PDF
Of course Mac OS X does just that. Quartz, it's new graphics API, is based on PDF.
I don't understand this - SAX and DOM parsers are canned by various vendors already.
Semantics is what is interesting, but after parsing XML, DOM does not provide rich or useful semantics for manipulating hierarchical data.
You should look at the Sun project to bind elements directly to objects. This is presume is your holy grail - binding arbitrarily complex data types to fully maleable objects directly.
Keep in mind that .NET "can" use SOAP for talking between objects. That does not mean that you MUST make this your protocol of choice. You CAN also use other commnications plugins, and send the data in various binary formats over various protocols. And if none of them meet your needs, write your own plugin for it. Read up on the remoting section at MSDN. Don't flame without the facts.
KDE already has a decent browser. You can also use Netscape, if you are so civic minded.
.Net is important. That's why Microsoft is supporting it, and that's why Linux needs to support it.
.Net, that's where the money is.
Just so you know, Microsoft is very concerned about the state of Windows. If they weren't they would be dumping hundreds of millions of dollars into it every year. Even Microsoft realizes though that eventually the OS will do pretty much all that it can on an individual machine. It's not there yet, but soon it will be.
.Net is Microsofts answer to the death of enforced obsolescence. The Linux community needs to get on this particular bandwagon because they are, in essence, in the same boat as Microsoft. Eventually the market for Linux won't grow anymore because people will find that these machines already do everything that they want them to do.
.Net is the strategy that gets OS companies and platforms around this because it allows companies to group computers and information together in ways that nobody has ever done. That's why
Forget about the browser crap, the browser isn't anything really important, and it will get better. Dump more time and efort into interfacing with
Beware the wood elf!!!
You may or may not like .NET, but SOAP web services are very likely to be the architecture for distributed, cross-platform, firewall-friendly development in the near future.
Check out XMethods for live examples.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Thanks for the quotage, but, uhhh... Why should I or my company care?
Seriously. Not flaming or trolling. Sounds great and all, but what we have is a description of the means, not the ends. (An all too common situation in technology.)
For example: I chose Gnome over KDE (back during KDE 1.1 or 1.2, so this probably is no longer valid) because Gnome was prettier and had better themes. Who gives a crap about CORBA?
Will any of this make things easier for the end-user?
(Sorry, just read Mythical Man-Month and am starting on the Lunatics are in Charge of the Asylum. I'm beginning to feel that the end users are REALLY being left out)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Perl for .NET
.NET
.NET Framework Community Website
.NET Developer Center
.NET platform.
Python for
ASP.NET
and of course,
MSDN
FWIW, asp.net and gotdotnet.com are supposedly running the
... Microsoft ActivePerl shows up in Visual Studio.
--
Both you and the original poster have completely missed the point of .NET. Shame on you. It's not about any one language being the Offical Language of .NET. It's about providing a platform that can be cross-platform (though it's true MS is only building the platform for MS OSen, it's possible to port the platform and thus gain the benefit of apps built to it). The list of languages supporting the .NET CLR is positively huge (don't have a link right now), and includes C#, VB, and Perl, along with managed C++, Python, Haskell, Lisp, and many other not-so-useful languages, including Java (kinda like the JVM is supported by a number of not-so-useful languages, specifically Java).
The moral of the story? Don't expect to see an "Official" language of .NET. That's not the point. That's never been the point, and never will be.
Deadly accurate my friend. With every single type of horribly implemented app going over 80 it's the end of the firewall as we know it.
War is necrophilia.
To make a SOAP call, one's software must build an XML document and an HTTP request, and send them together.
So? It's just an HTTP POST request. The XML document is probably less than 500 bytes long. It's no more expensive than POST-ing a typical HTML form (which is what browsers do for a living).
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.
So? Acting on the request itself (e.g. "buy 10 roses") is likely to be 100x slower than building the DOM tree. DOM trees get built all the time for HTML documents. Why is building an XML DOM tree any worse?
The point is that while SOAP may not be the most lightning-fast way to accomplish a particular remote method invocation, it is extremely scalable and flexible. Just like web browsing. Or maybe you think the web is already a serious abuse of CPU power?
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Perl is under the Artistic License, not the GPV.
http://www.bullnet.com
>>For one thing, nobody can describe what .NET really is. It's a framework! No, it's a protocol! No, it's a platform! No, it's a floor cleaner! No, it's a dessert topping!
.NET doesn't have a clear vision of what it will be doesn't mean it won't be worthy.
People used to say that about Windows. It's an operating system! No, DOS is the operating system, Windows is a GUI.
A lot of great ideas start out as one thing and end up something else. And yes, I think Windows was a great idea. No one forced all those people to prefer it over Mac OS or OS/2.
And no one stopped Sun from coming out with an affordable version of Solaris that could run on Intel.
So just because
Marjo Wycam, Master of the Programming Arts
500 bytes is a huge IIOP packet. The same semantic could probably be expressed using 1/10 of a bandwidth in CORBA.
Yeah, but CORBA is much heavier than SOAP. SOAP is just a wire protocol, not a full-blown distributed object architecture. CORBA is more powerful, but it requires much more of the participants and is less scalable. All you need to do SOAP is XML and HTTP.
What if you want to stream video? Or have real-time quake session?
I agree with you here -- don't use SOAP. SOAP is for loosely-coupled applications, not real-time.
Because if all you want is to buy roses, frankly I don't see what's wrong with the current HTML-Form post.
What's wrong is that (as you said farther on) HTML was not designed for RPC. SOAP is. HTML is great for browsing, but's it's lousy for application-to-application interaction. So if you're using a browser to buy roses, by all means, use HTML over HTTP. But if you want to expose a programmable object that implements a BuyRoses(int Number) method, who wants to "screen scrape" the resulting HTML page to look for the paragraph/table/whatever that contains the confirmation number that gets sent back?
Why do you insist on comparing this to HTML?
I'm comparing SOAP to HTML because you're complaining that XML over HTTP is a waste of resources. I'm merely pointing out that it's no more a waste of resources than HTML over HTTP, which is the foundation of today's Internet.
HTML was never designed for RPC. IIOP is.
I never said HTML was designed for RPC. I'm saying that HTTP makes a fine transport protocol for RPC, and that SOAP over HTTP is no more expensive than HTML over HTTP.
How is it more scalable or flexible then CORBA? Any proof?
Well, aside from requiring ORBs and God-knows-what-other supporting software, CORBA (implicitly) implements a stateful programming model. SOAP doesn't.
I'll throw your challenge back at you. If CORBA is so scalable and flexible, where are all the video-streaming, Quake-playing CORBA servers on the Internet? I can point you to firewall-friendly SOAP web services that are exposed on the public Internet today. Are there any such services implemented using CORBA?
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
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
Excuse me, but wtf does "performant" mean?
Code that "performs well"? Performs *what* well?
That is so vague; the kind of language that comes from marketing types, not from engineers.
If you mean "fast", say "fast". If you mean "uses memory efficiently" say that. If you mean something else entirely, or a combination of things, say that.
You obviously haven't tried to get high speed net connectivity 30,000 feet from a phone company central office...
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
... since it defines a set of interfaces that use resource handles that only make sense on Windows).
Microsoft has the COM, which (along with the "DCOM" extensions) allows everything that comes with CORBA. The COM allows Java compatibility, there's just an intermediate interpreter-object that allows the execution of java objects. The reason to go with SOAP over OLE/COM (I suppose) is that OLE/COM is specific to Windows (at least OLE is
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
Have you even been behind Raptor Firewall? :-(
HTTP is the ony way to communicate with the outside world if the Raptor is in between
Whenever you are using UDP, TCP to ports other than 80 and 443 or even TCP to port 80 which is not HTTP there will always be unhappy users.
The end user gets applications written faster, that do more, install easier, and have fewer bugs. That's about it - the same benefits the end user gets with every big improvement in developer tools and back-end tech.
-- Jeff Paulsen
I'm not at all convinced the .NET stuff has anything going for it other than whatever marketing millions Microsoft can throw at it.
.NET really is. It's a framework! No, it's a protocol! No, it's a platform! No, it's a floor cleaner! No, it's a dessert topping!
.NET These are universalized "solutions" to problems which cannot be addressed on a universal scale. The component frameworks (CORBA, COM and, it seems, .NET) try to resolve an essentially unresolvable issue, which is that the network world is complex. The inability of any of these frameworks to conclusively address latency, replicability, security and other problems in the realm of distributed network resources is indicated in their rapid and unstable evolution, and eventual diversion to one of two fates: either oblivion (SAA) or some localizable usage that does not correspond to the original dramatic claims made for universality.
.NET will make a lot of money for Microsoft and a whole generation of programmers, consultants and hypesters. But what value does it offer that less tightly coupled, less rigidly doctrinaire approaches don't?
For one thing, nobody can describe what
Frankly, if something like this can't be described so ordinary mortals can understand what it is, maybe it isn't anything to begin with.
I think Microsoft has finally reached the point where IBM was in the mid-1980s wth SAA. Anyone here remember the late unlamented SAA, the framework/protocol/platform/etc. that was Finally Going To Tie All the Pieces Together? "Just say LU 6.2 and run like hell, baybee."
Sure, there are parts of ".NET" that might actually be useful. But the notion of some kind of universal intermediate level language is JUST PLAIN HOOEY.
If someone else like, you know, IBM or Sun, were trying to do this, I could say, "OK, nothing to see here, time to move along."
But this is Microsoft we're talking about, the same company that didn't put real arrays into Visual Basic until release 6. And Microsoft has a crappy, crappy track record for these framework exercises. Let me illustrate with a little example series:
ODBC
DAO
ODBCDirect
RDO
OLE DB
ADO
RDS
Do I make myself clear? This way lies madness.
CORBA and COM are both bad enough. I reach diametrically opposed conclusions to those of Miguel de Icaza concerning CORBA, component frameworks in general, and the overall thrust of
Really, the whole approach is just wrong. These are top-down "solutions" being imposed on already complex and messy landscapes, not even on blank tablets. Even a cursory understanding of self-evolving systems shows that this simply won't work.
No doubt,
--------
Bill Gates Is My Evil Twin.
ActivePerl has all the problems you'd expect from a Microsoft-oriented product, requring forced upgrades of Microsoft software. (Requires NT Service Pack 5, Internet Exploder 5, Microsoft Installer 1.1, etc.) The pure Perl release for Win32 seems to have been killed off, unless you build it from the sources. No current pure Perl binary distribution for Windows is available from the main Perl site or from CPAN.
Now the "ActivePerl" books will start to appear, seducing programmers into using the Windows-only features. It's Microsoft's "engulf and devour" as usual.
Processor power is cheap as long as you have it enough. If 2 GHz is not enough for you it is not cheap at all.
SMP boards, non-Intel processors, coolers, cases - all this comes to the next price level.
And yet you have to worry how to use it effectively. A cluster is as slow as a single computer if you don't care how to distribute the tasks properly.
XML is a standard. Standards are good. You can parse XML with off-the-shelf libraries (for just about any programming language under the sun. Lisp included no doubt). You can get off-the-shelf tools for working with XML.
If .NET gains strong market share, MS is then in a position to say "Well, for version 6, we're supporting this special, enhanced Perl, called PerlMS."
But like I said, I'll believe it when I see it.
--
--
You sure got a purty mouth...
So first .NET is a way to require subscription fees to use Windows and Office, and now it's some kind of intermediate programming language?! >_< I dunno, whatever it is (probably both) it sounds like a Very Bad Thing(TM)...
IMHO, SOAP is preferable to CORBA (or RMI) and from what I've heard about it UPnP seems a little preferable to JINI. Maybe some engineers are changing MS from within...
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.
oh, cool: if I bring steak to the XML BBQ, I can have steak.
Smart companies put their external web server in a "DMZ" (neither fully inside or fully outside) where it is protected from the Internet (except port 80 of course) and has limited or no access to the internal network.
Just because it CAN be done, doesn't mean it should!
I believe, although I am not positive, that IL code is translated to native code at load time, then the native code is run. Therefore there is an initial penalty at the beginning, but not a continued one like in Java.
With any remote call the following sequence need to occur:
- marshal parameters on client
- Open a socket to server
- Receive / unmarshal params on the server
- Create/invoke object
- Marshal return values and write to socket
- Unmarshal on the client.
Marshalling becomes negligible. Web servers and XML parser are being further optimized by the day. XML can be very efficiently parsed without creating a DOM using SAX checkout http://xml.apache.org. Combine an apache module with Xerces parser and you will have one fast socket listener (web server)/ marshaler(SAX parser) that is very easy to use. Write some test code an you too will be a SOAP believerThink of XML as LISP for COBOL programmers. ... ) instead of <thingee> ... </thingee>
LISP is a bit more concise with (thingee
On what horribly broken network are your CORBA calls taking 100ms? Across the public internet at peak time, perhaps, but with CORBA calls using OmniORB on a 100mbps local network I get echo responses in about 1ms.
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
I don't think this is gonna fly, its got the body of a perfect bird but i don't think it has enough 'wingspan' to reach the right points in the market. Its gonna need alot of pros over Java, and similar technologies now for everyone to accept it as a standard. Are there anyways to gradually upgrade to a system such as this or will it be a total replacement?
Why is putting words between angle brackets
.PDF.
revolutionary? Did we want a way to represent
hierarchical information in a way that it
could be easily manipulated and checked for
validity?
Maybe I am wrong, but couldn't you do that with
LISP? Just send your data across in lists and
let a tiny lisp interpreter figure out what to
do with it.
And HTTP? This is our lightning fast protocol
for object communication? Next thing you know
we'll be drawing to our screens with
Oops.
Comment removed based on user account deletion
If anyone cares, I wrote an article for OsOpinion.com which gives my view on all this.
- adam
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
Are you honestly telling me we should drop all the progress made with XML and think of some newfangled LISP mechanism??? Ever heard of DSSSL? Know anyone who uses it???? There's your answer.
As for HTTP, sure its showing age, but you show me a protocol that has become as succesful as quickly as HTTP.
No one cares how whiz bang your technology is if no one adopts it - hence CORBA and LISP.
100ms+ is for a full text search or database query that returns 100+ records that requires post processing takes at least that long. I would agree that CORBA is faster than SOAP for an echo, but for calls that take any sort of process time like a LDAP or DB query SOAP would come out in the wash, especially when the HTTP connection is kept open.
People from application server companies such as BEA recommend kepting the objects on the same server as the serverlets.
I'll have to check out OmniORB, thanks. What are the differences between calls that do processing other than echo?
Since many firewalls are setup to not allow CORBA ports so we have two ways of calling out search service, one via CORBA for intranet, and one via SOAP for internet.
you are on the right track, but your criticism is misguided; you have obviously never used XML. XML does not make hierarchical information easy to manipulate. XML is the most complex system imaginable for manipulating simple tagged hierarchical information. While the angle bracket bit seems simple enough, the wacky syntax of DTDs, coupled with the meaningless complexity of the DOMs makes a combination that subtracts value in direct proportion to the markup added. It is truly a mark-down language.
People might also read this and get the impression that you can't do SOAP with Java. There's a couple of SOAP implementations for Java, most notably the one from IBM alphaWorks.
.Net looks pretty interesting to me, and Perl support gets me even more interested. But I Don't Do Windows(TM). I'm a Mac OS and Unix guy, currently using the OS X beta quite a bit. Am I going to be able to do serious .Net development? Is there even going to be a .Net implementation for non-MS OSes? All of this .Net stuff is rather irrelevant to me and I imagine to most of the open source community if .Net is going to be just another way to write Windows apps.
--
This space unintentionally left unblank.
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