Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Perl and .NET 166

Posted by Hemos from the witty-dept-line-goes-here dept.
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."
This discussion has been archived. No new comments can be posted.

Perl and .NET More

Perl and .NET

Comments Filter:

  • Vaporware? (Score:5)

    by lemox ( 126382 ) on Thursday December 21, 2000 @09:48AM (#1403356)

    It's already released (well, as beta at least). MS sent out the beta [microsoft.com] 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 [activestate.com] plugin for VS.NET, along with Perl for .NET [activestate.com].

    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.

  • 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.

  • 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

  • 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.

    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.

    .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.
  • "
    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 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 [slashdot.org], it's darn well possible to tunnel IP over HTTP [nocrew.org].

    All you've lost is your false sense of 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. "

    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.

    The code for Python under .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.

    IMO, .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.
  • 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 [oasis-open.org] 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.

  • Re:Efficiency (Score:3)

    by deusx ( 8442 ) on Thursday December 21, 2000 @01:20PM (#1403367) Homepage
    "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!
  • Microsoft has already submitted .NET (well, at least C# and the CLR (the CLR is the VM)) to the ECMA for standardization.

  • 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.
  • Hmmm. I don't think HTTP is as much of a bear as it seems. And you certainly don't have to build a DOM tree to parse XML. SAX can do, or you can roll your own that just looks for what you want and ignores the rest.

    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.

  • If it was just "angle brackets" that made the world go round, people would have creamed thier pants when SGML came out and the revolution would have happened years ago. XML is angle brackets with a description of what is inside the damn brackets.

    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.

    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 - .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.

    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 .NET stuff. I doubt it - but it could happen.

    M$ doesn't need to make it's own perl - it just has to shoulder it out of the way.
  • From the article:

    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 [jpython.org] 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 [sourceforge.net] (GPL'd Java ODMG) needs volunteers.

  • Re:RTFA (Score:2)

    by sohp ( 22984 )
    "Not Real" languages: Tcl, Haskell, Lisp, Scheme, BASIC, LOGO, Eiffel, Smalltalk, COBOL, Ada. More at Programming Languages for the Java Virtual Machine [tu-berlin.de]
  • 1) It's MS only - this is blatantly false.

    SOAP might not be MS only, but .NET sure looks like MS only technology. Everything I read from Microsoft couples the .NET concept tightly with existing MS technologies (most of them have '+' attached to them): COM+, ASP+, ADO+.

    So if I'm not on a Windows platform then how the heck is a component depending on ADO+ for its database connectivity going to work on my machine? Who is going to port all this stuff to all the platforms. They're closed proprietary technologies and I've seen no sign from Microsoft that would indicate this is about to change.

    SOAP works across components on heterogenous systems because it's based on XML, but what makes it any more special than several other XML over HTTP solutions? SOAP alone certainly won't make components cross-platform, and neither will C#. A language without libraries and a transport protocol won't be enough. You will need cross platform libraries and in that area MS is several years behind the competition.

    the future medium of all communication is going to be XML over HTTP.

    Hardly. XML over HTTP is very good at integrating services on distributed systems but it certainly won't work for anything that requires high scalability. The overhead of XML will become a factor. I certainly would not recommend doing all communication - from client layer to the web layer to the middle tier all the way to the database in XML. That will just kill any heavily used distributed system. For infrequent data exchange and communication sure, but for those situations any protocol you're able to get through the firewall will work.

    What is more critical for distributed component architectures and their integration is how will the transaction and security contexts be propagated from one component to another in the system. Fail to come up with a very good solution for this, and the .NET will never move out of the homogenous MS W2K network.

  • Strange, you just described .NET. Amazing.

    C++ for .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).
  • "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
  • It would only be a matter of time beofre before tunnled arbitrary proxies over whatever port they liked.

    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.

  • .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 .Net is important. That's why Microsoft is supporting it, and that's why Linux needs to support it.

    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!

  • .NET is not about running programs written in different source languages. You can do that in the JVM. Shit, you can do that on an x86 in hardware.

    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).

    .NET supports much more interoperation. The object model is richer. More parameter passing mechanisms are possible. You can take the address of things. Custom attributes are available to mark interesting things for interop purposes. You can even do a tail call!

    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.
  • 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).

  • 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.

  • .NET might be very good to us (Score:3)

    by Proud Geek ( 260376 ) on Thursday December 21, 2000 @09:39AM (#1403390) Homepage Journal
    If there is a high quality free implementation of .NET on Linux, then a lot of people would have no reason to use M$ Windows at all. All their favourite programs would run great on Linux.

    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.

  • 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.
  • 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!

  • 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 [apollo] for more information.

  • 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.
  • 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.

  • .net and multiple languages (Score:3)

    by StrawberryFrog ( 67065 ) on Thursday December 21, 2000 @10:06AM (#1403398) Homepage Journal
    Perl, Visual Basic and C# can be compiled down to IL.

    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.

  • Re:Efficiency (Score:3)

    by antv ( 1425 ) on Thursday December 21, 2000 @10:06AM (#1403399)
    Well, CORBA is not "impossible for developers to use". See here [omg.org], you create object interface definition using IDL - which isn't any harder than creating XML DTD - and then it is compiled by IDL com piler in binary form. Easy and efficient. Now SOAP seems to - correct me if I'm wrong - at least involve XML parsing, sending data in uncompressed text format, extracting SOAP protocol data from parsed XML query - and all this is encapsulated in HTTP query. Lot's of processing, for, take a note - each SOAP object call. It could be optimized, I suppose - persistent HTTP connection, maybe compressed data for bandwith - but then it's uncompressing overheat, etc - but CORBA does this already.

    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.

  • So first .NET is a way to require subscription fees to use Windows and Office

    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 .NET thing also an attempt to get people to pay subscriptions for software that has been traditionally paid for once?

  • 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 [vitanuova.com], Styx/9P-search [google.com] on Google, a real life example [vitanuova.com] of an interface to remote functionality, Styx manual pages, [vitanuova.com]Inferno home [vitanuova.com] and Plan 9 home [bell-labs.com].

    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.

  • > 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

  • 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

  • Re:Efficiency (Score:3)

    by Jeffrey Baker ( 6191 ) on Thursday December 21, 2000 @02:14PM (#1403406)
    I'm getting pretty tired of programmers claiming that their time is worth more than CPU power. A CPU is a magnificent human achievement, and each one is the result of millions of hours spent by engineers electrical and mechnical, mathematicians, technicians, and line laborers to bring you the power of using the most inefficient RPC mechanism ever devised. The amount of human effort required to make a fast CPU is orders of magnitude larger than the marginal effort expended to understand CORBA as well as SOAP.

    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?

  • I can see where this would have it's uses. For the majority of my stuff, XML-RPC is best because I need to format it to XML anyways, so the RPC pretty much just passes through an XSLT based on the accept mime-types of the caller. That being said, there are definately circumstances that streaming would be preferable.

    I'm not too sure about the "mounting" metaphor. It seems like an extra bit of complexity if it is necessary (i.e. there's no automount for rare RPCs). I can understand why it would be needed for highly used RPCs, just for the efficiency of it. There may also be connection pooling aspects to consider. But I don't know if I agree with keeping the memory overhead of that many mounts.

    Anyways, cool stuff. I'll have to look into it more.

  • Therefore, Microsoft essentially funded the development of Perl for Windows systems, and also came up with the worlds first Perl IDE.

    There goes the neighborhood.

    Note that ActivePerl isn't entirely free software [activestate.com]:
    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

  • Easy and efficient.

    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.

  • From an article on java.sun.com [sun.com]
    "We see that SOAP [the Simple Object Access Protocol] provides part of the answer to meet the requirements of certain categories of service, such as those for subscription-based models. This explains our commitment and participation in the Working Group at the W3C [World Wide Web Consortium] to develop the recommendation for XP, which builds on the initial SOAP work," said Simon Nicholson, Sun's XML standards strategist.

    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 [apache.org], too. People aren't thinking of it as a Microsoft thing. Just a distributed thing.

  • 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.
  • Incidentally, there is a Jacl (Tcl (not Tk) implemented in Java). Nice for testing your java stuff or adding a scripting language to your java app.
  • 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. That is, Perl, Visual Basic and C# can be compiled down to IL.

    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 [tu-berlin.de]. It lists about 130 systems that implement existing languages based on the JVM.

  • "only" language (Score:3)

    by gnat ( 1960 ) on Thursday December 21, 2000 @10:12AM (#1403422)
    I meant that while Microsoft is funding and encouraging other languages to compile down to the IL, Sun never seemed to do that with the JVM. As far as I could tell (and I am the first to admit that I am on the fringe of the Java world), their main push was to have Java be The Language. I'm interested to hear whether they really did encourage other languages to compile to the JVM.

    Poor choice of words on my part, sorry for the confusion. See http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml [tu-berlin.de] for a great list of languages that compile to the JVM.

    --Nathan Torkington

  • The advantage of XML is very subtle, but well suited to any system where your have random-length data fields, with the possibility of some data fields not present in the data file, or the parser not understanding those fields, so that it could skip to the next 'valid' entry.

    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.

  • Re:Enough of XML (Score:3)

    by fear_and_loathing ( 231026 ) on Thursday December 21, 2000 @10:27AM (#1403427)
    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....
  • the wacky syntax of DTDs

    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??

  • what I know of SAX is parsing. who cares about parsing? it's something that should be simple, which it's not with XML, hence the need to used canned parsers.

    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.

  • Re:Enough of XML (Score:2)

    by Anonymous Coward
    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 [microsoft.com]. Don't flame without the facts.
  • KDE already has a decent browser. You can also use Netscape, if you are so civic minded.

    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 .Net is important. That's why Microsoft is supporting it, and that's why Linux needs to support it.

    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 .Net, that's where the money is.

  • 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 [xmethods.net] for live examples.

    -- Brian

  • 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)
  • ... Microsoft ActivePerl shows up in Visual Studio.
    --

  • Re:"only" language (Score:4)

    by bjepson ( 994 ) on Thursday December 21, 2000 @11:43AM (#1403452) Homepage
    Jon Udell's December 18th column [byte.com] addresses the issue you raised, questioning whether it is in Sun's best interest to keep the language and the JVM tightly coupled. The column includes a survey of some of the people who have implemented languages for the JVM.

    --
    Brian Jepson

  • Don't forget, nowadays, people think it's totally normal to reboot a server after changing it's DNS or IP address, or after enabling packet forwarding.

    You don't have to do that anymore with Windows 2000

  • Inefficienct but useable and can do more (Score:5)

    by Fjord ( 99230 ) on Thursday December 21, 2000 @10:49AM (#1403463) Homepage Journal

    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 [extremeprogramming.com], 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.

  • bandwidth is cheap

    You obviously haven't tried to get high speed net connectivity 30,000 feet from a phone company central office...

  • 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.)

    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.

  • Well, that sounds great and all, but you know that Microsoft will work day and night to try and screw us over...

    Although moderators might think it's a flamebait and burn my karma, I will say it:

    We read this kind of crying many many times... Stop crying and help:

    - write good OS code or
    - write documentation or
    - translate existing docs to other laguages or
    - teach Linux in your classrooms or
    - install Linux in your student labs or
    - install Linux in your friend's computers or
    - ... just use Linux and OS software.

    And mainly, accept and do self criticism, M$ might be an evil, but they _do_ also good things, and it's very convenient to recognize what's good and what rubish. OTH, OS developers, sometimes also write craps and bloated software.

    --ricardo

  • I'm not at all convinced the .NET stuff has anything going for it other than whatever marketing millions Microsoft can throw at it.

    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!

    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 .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.

    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, .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?

    --------

  • Perl seems to have gone over to the Dark Side. The official release of Perl for Win32 is now ActivePerl. [perl.com]

    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. [cpan.org]

    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.

  • I think .NET is basically for entirely Microsoft shops, and other hangers-on, who want to graduate from native legacy code, into the WORA/web/standards universe, under Microsoft's protection.

    Where I work, we've been big into Java, J2EE, CORBA, and XML for a while...so it's nothing new to us.
  • I'll believe it when I see it. My real fear is that .NET technology will give MS a foothold into a whole host of development technologies that it can then "embrace and extend" in the manner which we have become so familiar.

    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.

    --

  • Efficiency (Score:5)

    by Jeffrey Baker ( 6191 ) on Thursday December 21, 2000 @09:43AM (#1403481)
    Soap uses HTTP to send XML-encoded instance and method calls on remotely defined objects and receive return values

    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.

  • Your web server will have to be secure. I hate to break it to you, but even as of now, if your web server isn't secure - you are at risk. They can get through your firewall via port 80, compromise your web server and use that as a jumping off point for attacks.

    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.

  • I had the same feeling unit I tested the performance. Comparing SOAP/CORBA/RMI/DCOM/Vanilla RPC with network latency on a 100 baseT network SOAP performs just as good as any other remote object technology. All calls average around 100ms round trip.

    With any remote call the following sequence need to occur:

    1. marshal parameters on client
    2. Open a socket to server
    3. Receive / unmarshal params on the server
    4. Create/invoke object
    5. Marshal return values and write to socket
    6. 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 believer :-)
  • And also, I don't see .NET as a threat but a HUGE opportunity for Linux and some OS languages.

    Does Linux (or xxxBSD) do the right thing with Apache and HTTP? What about HTTP for RPC standard? Isn't sound better than Corba?

    Do you already have a SOAP module for PERL? Isn't Perl (and Python) a good language for building [text, XML] parsers?

    Ooops... How long it will take until you get same modules for Python, PHP, TCL/Tk and the likes?

    Do you think O'Reilly is not interested in compiling Perl to the IL? Do you think it will be slower? Don't think so...

    Do you think is very hard to have in short time a kind of xml-inetd for Unix/Linux/BSD?.

    This will be heaven for many of us.

    --ricardo

  • I agree with practically everything you say, XML is great for exchanging complex data structures with added benefit of error checking, etc. That's what XML was designed to do.

    However, if I understand correctly - I can't find any exact description of what .NET internal structure looks like - M$ is using it for procedure calls.
    XML is a right tool for data exchange, CORBA is right for procedure calls, and I thought we're supposed to use right tool for right job, or even beter, have a choice what to use - Java doesn't force you to use CORBA, you could use XML RPC if you want - heck, it you really need you could send Java class as data and let it run on remote machine, with it's own security manager, if you want - sometimes this is the best solution for distributed systems. But Java gives you a choice. I can't find any evidence that .NET does, hopefully I'm wrong.

    Opinions are mine only and could change without notice.

  • 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.

  • There's absolutely no reason why you can't use a source format (say, IDL) to produce both COM/CORBA and SOAP representations of the same interfaces. We're currently doing that, although not using IDL as the source; it seems to work well, and offers you performance via COM/DCOM where you need it, with interoperability via SOAP when you want it.

  • Fuck. hitting tab + enter is not a good idea :)

    To continue where i left off,

    alot of the people that are badmouthing .net say one of two things:

    1) It's MS only
    this is blatantly false. obviously if people are deploying applications _today_ using SOAP, and the future medium of all communication is going to be XML over HTTP, it is amazingly interoperable. Microsoft isn't stupid. You may not know this, but microsoft has already said that they realize the operating system is becoming a commodity product and in the near future you wont be able to have a dominant role in the industry if all you ship is an OS. With that in mind they're designing future products to be best of breed solutions in an interoperable environement. Either you'll like their products/tools or you wont.

    2) I can do everything VS.NET promises today with open source tools.

    Well, you can, sort of. Afterall, the .NET platform is all about interoperability. THe question is, what will the developer experience be like? How easy will it be for you to the equivlanet of

    dlopen("http://somesitehere.com/greatLibrary.xml ")

    and have it "just work" ? :)

    Don't make any statements about what VS.NET can and can't offer with complete confidence until you've sat down and used it.

  • Python (Score:3)

    by costas ( 38724 ) on Thursday December 21, 2000 @09:45AM (#1403500) Homepage
    ObPythonPostInPerlThread:

    Python will also be part of .NET along with Perl, and it can do SOAP as well. Moreover, JPython [jpython.org] already makes Python a Java platform language. In other words, it doesn't matter who "wins" the cross-platform war, Python is already there.


  • Why is putting words between angle brackets
    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 .PDF.

    Oops.

  • Comment removed (Score:3)

    by account_deleted ( 4530225 ) on Thursday December 21, 2000 @09:18PM (#1403504)
    Comment removed based on user account deletion

  • .NET on UNIX (Score:3)

    by macpeep ( 36699 ) on Thursday December 21, 2000 @09:43PM (#1403507)
    I recently saw a presentation by Microsoft about .NET and they said something along the lines of:

    "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 .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.

    Seems to me Java still has an edge but .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.
  • A few months, ago, I heard a research presentation at my school [brown.edu] from someone from Microsoft who worked on part of the .NET core. It was quite an interesting presentation, and I came away thinking that the .NET thing, if the manage to pull it off successfully, will be quite impressive, technologically.

    The presenter said that MS has plans to port .NET to other platforms in the future, but that the 1.0 release would be just for Windows. After the talk, someone asked about crossplatform considerations, such as byte order and alignment, in the IL VM. He replied that they had made no provisions at all for those issues. Now, my multiplatform programming experience is a bit limited, but I would tend to think that if you don't build something from the start to make it easy to port, it will almost certainly turn out to be hell to port it. Given that, and MS's obvious reluctance to reduce dependence on Windows, I think it will be a very very very long time before we see a high quality implentation of .NET on any free platform.
  • I'm so tired of listening to the wannabes in here coming off with this devil's advocate BS.

    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.
  • The article seems to imply that Sun has standardized on CORBA as the way to do distributed applications with Java. I don't really think that's true. Most distributed Java applications that Sun has created use RMI, which is not CORBA. CORBA just happens to map very easily to Java, which is why there are plenty of implementations for it.

    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 [ibm.com].

  • Re:And you can't turn it off... (Score:4)

    by Pinball Wizard ( 161942 ) on Thursday December 21, 2000 @12:52PM (#1403516) Homepage Journal
    >> Now the "ActivePerl" books will start to appear

    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.

  • .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.

    --

  • What is .NET really? (Score:3)

    by kerb ( 43511 ) on Thursday December 21, 2000 @09:46AM (#1403519)
    What is it? (according to Jim Farley of O'Reilly)

    Current ruminations about .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.
    First, let's get some concrete details. Here's one cut at an itemized list of the technical components making up the .NET platform:

    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 .NET and J2EE compare?

    quoted from : http://java.sun.com/features/2000/11/dotnetvsms.ht ml

  • Re:.NET might be very good to us (Score:3)

    by toofast ( 20646 ) on Thursday December 21, 2000 @09:47AM (#1403520)
    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.

    As the devil's advocate, if Microsoft advance too quickly and Linux doesn't advance quickly enough, people will be generally disappointed with the advance difference in both environments, even if Windows is considered crap. Don't forget, nowadays, people think it's totally normal to reboot a server after changing it's DNS or IP address, or after enabling packet forwarding.

    If too many people see only the Microsoft way, they'll consider that as the norm, and anything else as sub-par.

  • Re:Efficiency (Score:3)

    by Chris Hind ( 176717 ) on Thursday December 21, 2000 @09:48AM (#1403521)
    bandwidth is cheap. processor power is cheap. why should we dick around with formats that are impossible for developers to use? anyway, bandwidth issues will be mitigated by the new binary xml formats that are coming up.

Slashdot Top Deals

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Close