Very good point, but let's not get complacent. Dotnet, like Java, promises to make applications cross-platform with or without the source.
So there is a serious risk is that Linux's current lead in platform flexibility, based on recompiling, could be lost because of the lack of a clear direction for an Open Source VM (Java, partial Dotnet clone, Parrot and others are all in the running).
The real irony is that a VM fundamentally suits Open Source development much better than proprietary, since the intermediate code is typically semantically very close to the source (as uses of the Java decompiler JAD will know).
The good Dr Villanueva highlights the importance of being able to treat programs as information from a rights and liberties point of view, but of course there are many other good technical reasons.
As a matter of interest, is it possible to get your own light source that can emit individual photons? Presumably you need this to demonstrate quantum effects at home?
There's an academic study giving convincing evidence of this but unfortunately I don't have the link handy. It is from an economist at an Australian University.
What should we call it instead? How about Market Segment Code?
>. You're going to be running a completely different set of apps.
>>11 is the starting point, it's going to get a lot more diverse from now.
> Why? It's ported to pretty much every chip in production that can run it.
Nonsense. First you talk about porting apps, then about porting the OS. It doesn't matter how widely the OS is ported, it's the apps that will be separately distributed that count.
Yes, I can confirm that PDAs and phones are already running JVMs. I can also confirm that no PDA or phone anywhere is running a CPU emulator.
I won't bother attempting to convince you that PDAs will be running the same programs as mainstream Linux as you can find that out for yourself with a quick search in Slashdot.
Don't bother coming back with more airy-fairy arm-waving - I'm not interested in vacuous assertions and I'm pretty sure no one else is.
When I get some little music toy app for my PDA, you can bet it's not going to be pre-compiled for all existing platforms. 11 is the starting point, it's going to get a lot more diverse from now.
I really don't think kernel emulators are in the running here - PDAs are constrained enough as it is without the overhead of x86 emulators. Nokia and other phone makers are setting the trend for small devices and compiled binaries are not part of the picture.
But how many people appreciate that Linux is in peril?
Right now, cross-platform code isn't a major issue because
a) embedded or non-x86 Linux isn't that big yet b) people are used to compiling source
but neither of these assumptions will be true in ~4 years. Linux will need a VM, but only Dotnet/Mono and Java will be available, and with the ridiculous hype that Mono is getting, MS could well be in drivers seat. Not a pleasant prospect...
Dear oh dear, some people are hard to please. What shapes would this young fellow like to meet/frag on screen instead of people? Trolls? Amphibious landing craft?
And how dare people dis innovations coming from my home town (no, I'm not on the payroll).
Personally, I think producing a 3D head model from two ordinary pictures is a neat trick. Meeting 'avatars' of friends on line is surreal but definitely entertaining. It'll catch on sooner or later, unlike a lot of crud from the last 2 years...
when Mono becomes mature, and some poor soul does a functional port of things like the Forms library
...and when MS decides not to sue the copiers of their Forms library...
Remember, Forms Dotnet is not standardized, nor are the database APIs - in fact 1000-odd of the 1200 APIs in Dotnet are not standardized or open in any sense.
I agree with the poster - start with PostgreSQL and the like (or a Java database) to build a sensible alternative to Access.
I might as well use an OS written in Java... (no offense to java, but that'd suck.)
Well, probably, now... but actually it's not clear that this will be the case forever. Yes, I will point out that Java gets quite a bit faster with each release, but more importantly the hardware gets more diverse year on year. CPUs with big register files, vector operations, 64 bit operations... there's a fair slew of chips out there already, before Clawhammer & co appear, and I doubt if C compilers are going to optimize for all of them. In fact, that's impossible. So step forward the JIT, the guy that knows your hardware, and even your usage patterns and can optimize for both. It's the only practical solution longterm... convinced anyone?
a) overlaps with Swing, AWT, SWT (and for that matter, WFC) and b) makes users vulnerable to IPR attacks from MS
As you strenously and repeatedly point out, SWT would be an equally bad in duplicating Swing, but only if there were no technical justification for it. However, judging by the number of 'Swing is slow and ugly' complaints here on/., I think you'd have a hard time proving that was definitely the case.
I do not accept that Java is anywhere near as proprietary as Dotnet. The number and size of companies producing Java products (not just products based on Java) is clear proof of that. Yes, Sun and IBM and others have IPR, but they do not constitute an aggressive monopoly, and the worst that can happen is that a product has to license that IPR on the same basis as partner companies. With MS, there's no guarantee of a license at all.
If this bothers you, I would suggest you try Parrot etc. In any event, none of this can make the case for embracing Dotnet.
Yes, Sun benefits from JUnit just as MS benefits from NUnit. However, because of the lead Java has established, and the remote possibility of mainstream Dotnet apps running on Mono, the flow of OSS value is going mostly from Java to C#. Once you and your buddies have helped establish Dotnet as the dominant platform, not because it offers any compelling technical advantage but because you got bored with Java, the Java economy will die off and MS will be in the driving seat of Linux development.
Lastly, in case it isn't obvious, the reason that Kaffe is immature is that high quality JVMs are available for Linux from both Sun and IBM (and soon BEA). In the unlikely event that IBM decided that its $1B investment in Linux wasn't a good idea, Kaffe could be revived. However, this is about as likely as MS supporting the complete Dotnet platform on BSD.
So to sum up, Java should be embraced because:
1) Already mature technically 2) People know it 3) Built-in cross-platform support (no Windows Handles and backslash-only paths here) 4) Linux support from vendors 5) The whole Java platform evolution and IPR is somewhat open. This avoids the trap set by MS where a little bit of the platform is offered to a passive standards body and the rest kept proprietary.
Re:Nicely understated
on
Web Services
·
· Score: 2
Mo. Namespaces allow nothing of the sort - an XML Document cannot contain another XML Document, with or without namespaces.
This is why HP came up with the hack of putting SOAP messages in mutipart-MIME wrappers - this was necessary to pass XML Docs as arguments in a SOAP doc. Your Jabber stream is using a similar wrapper - a wrapper which is not XML.
Cue 100s of language pedants to leap in and say that you are referring to dynamic typing rather than polymorphism. Java is statically typed, which means that it eliminates run-time type errors, unless you use downcasting (or operations that can throw UnsupportedOperation exceptions), but the penalty is that you have to label all your variables with their type, unlike Python.
There's a rather dated discussion here: Object FAQ
Inconsistency is bad wherever. If IBM did SWT for purely political reasons then that's a problem - the jury seems to be out on this one - but that doesn't give others the excuse to arbitrarily duplicate things further.
Because Java was here first, and C# adds nothing from a technical standpoint, you've ended up arguing how OSS developments (JUnit etc.) can enhance a proprietary platform rather than how non-proprietary systems might benefit.
The problem is that we're years away from this relationship being equitable. Applications like Photoshop are not going to be available for Mono for a long time, if ever. Meanwhile, Dotnet gathers developer support with your help.
Hmmm, I think the logic is a wee bit tangled here:
When you say "you don't really care about the type as long as the object supports the operations you expect it to" this is true for the original type of the object - a WeakPinkWobblyHashMap, say - but you do care that it's a Map, because you're about to call Map operations on it.
So you either do this by declaring a Map parameter, or accepting a superclass (such as Object) and downcasting to a Map - which might throw an exception if the object isn't a Map.
It's downcasting that's a problem in all code, but I don't think Java does any worse than any other language in this - templates/generics are the only thing that would help and they can still get very messy.
Personally I don't dislike the
Map m = new HashMap(1024);
style, because of the chance you have to use subclasses on the right, though it is noisier than typical statements in other languages.
Actually, I didn't follow this point. Yes, there's a lot of casting in Java, but that's so you can take advantage of polymorphism - cast from a WeakHashList or whatever to a List and then you can pass it to any List consumer.
Or are you thinking of Objects in Collections - would generic classes / templates help? If so, you shouldn't have too long to wait (for Java, longer for C#.)
Alright, some reasonable points IMHO. Diversity is popular on/., more so than consistency, so I can see how the more is better argument will appeal to many.
However, though it might be possible to merge the JVM and CLR, a merger of the associated libraries is much less likely. In particular, it's hard to justify the effort in swimming upstream and trying to clone Windows Forms for Gtk when IBM is already producing Java SWT for Gtk. What's the point? As soon as you've got a complete clone, you'll get sued - how does that help anyone?
I prefer diversity to be limited to real, technical diversity - Perl vs. Java, or Scheme vs. Visual Basic, or an AST-based IL vs. a bytecode IL. C# and Java are so close that the choice of one over the other won't be based on language characteristics - only the most pedantic advocates would see meaningful differences.
ROFL. I wrote a large portion of the CORBA specifications, as it happens, and was building OO systems in Smalltalk 12 years ago that can still put Java and Dotnet systems into the shade.
But of course these developments are nothing compared to the revolution that would follow the introduction of unsigned ints to Java. Can't wait...
5) It treats them as objects, at least as much as Dotnet does. I thought this was meant to be a comparison?
6) Hmmm... perhaps you'd care to elaborate? Again, examples of more useful polymorphism in C# etc. would be relevant here.
7) You mean like the split between reference types and value types in C#? Indeed. See here for an argument as to which is easier to deal with.
8) Distinguishing types from implementations is a hack? Thanks for the tip - don't forget to pass it on to Jim Rumbaugh next time you see him.
9) What a coincidence - Java happens to be the #1 teaching language so I guess they'll never learn! As a matter of interest, what does the MFC library smell like to you?
Glad you like Jython. A fine example of innovation building on the JVM, unlike Dotnet.
Equal? Not equally mature - or do you seriously want to compare Mono with Sun's 1.4 JVM on Linux? And not equally innovative - Java introduced all the significant advances years ago, Dotnet is pathetically derivative.
So the point is, in case it escaped you, the platform should I be writing my OSS app for is Java. Mono proponents have never demonstrated substantial technical benefits of Mono over Java, certainly not sufficient to justify entanglement with MS's lawyers - it's just a bandwagon.
I don't feel like getting into a big treatise on why the JVM will never be fast
I completely understand your position on that.
>An unsigned datatype? Are you serious? This is utterly trivial.
Utterly trivial unless you're going to do anything serious.
I'll keep it in mind if I find myself doing anything serious in my next 20 years in IT.
Forgotten the OMG already?
on
Web Services
·
· Score: 2
What's the difference between web services, and COM, CORBA and EJB? You are not likely to get a straight answer from the owners of the earlier technologies, because doing so would be tantamount to admiting that they should have begun by agreeing on open standards in the first place.
Perhaps that's why the "owners" joined the OMG, and later Sun's JCP? However, one company refused to participate in these efforts - I wonder who? If you can guess, congratulate yourself that you're more qualified than the author to write the next Web Services column!
Web Services may have some issues when network/security administrators figure out people will be using RPC through the firewall.
Mmmm, yes. Especially when they realize that they can't discriminate based on the target Object (there ain't one).
As we all remember from college, most protocols are layered, which allows encrypted bits to be layered inside routing / security bits, but an XML document can't be layered (it can't contain other XML documents).
Slashdot Mirror
Very good point, but let's not get complacent. Dotnet, like Java, promises to make applications cross-platform with or without the source.
So there is a serious risk is that Linux's current lead in platform flexibility, based on recompiling, could be lost because of the lack of a clear direction for an Open Source VM (Java, partial Dotnet clone, Parrot and others are all in the running).
The real irony is that a VM fundamentally suits Open Source development much better than proprietary, since the intermediate code is typically semantically very close to the source (as uses of the Java decompiler JAD will know).
The good Dr Villanueva highlights the importance of being able to treat programs as information from a rights and liberties point of view, but of course there are many other good technical reasons.
As a matter of interest, is it possible to get your own light source that can emit individual photons? Presumably you need this to demonstrate quantum effects at home?
This is correct - mod up!
There's an academic study giving convincing evidence of this but unfortunately I don't have the link handy. It is from an economist at an Australian University.
What should we call it instead? How about Market Segment Code?
>. You're going to be running a completely different set of apps.
>>11 is the starting point, it's going to get a lot more diverse from now.
> Why? It's ported to pretty much every chip in production that can run it.
Nonsense. First you talk about porting apps, then about porting the OS. It doesn't matter how widely the OS is ported, it's the apps that will be separately distributed that count.
Yes, I can confirm that PDAs and phones are already running JVMs. I can also confirm that no PDA or phone anywhere is running a CPU emulator.
I won't bother attempting to convince you that PDAs will be running the same programs as mainstream Linux as you can find that out for yourself with a quick search in Slashdot.
Don't bother coming back with more airy-fairy arm-waving - I'm not interested in vacuous assertions and I'm pretty sure no one else is.
Because Debian is the exception, not the rule.
When I get some little music toy app for my PDA, you can bet it's not going to be pre-compiled for all existing platforms. 11 is the starting point, it's going to get a lot more diverse from now.
I really don't think kernel emulators are in the running here - PDAs are constrained enough as it is without the overhead of x86 emulators. Nokia and other phone makers are setting the trend for small devices and compiled binaries are not part of the picture.
Ignore it at your peril.
But how many people appreciate that Linux is in peril?
Right now, cross-platform code isn't a major issue because
a) embedded or non-x86 Linux isn't that big yet
b) people are used to compiling source
but neither of these assumptions will be true in ~4 years. Linux will need a VM, but only Dotnet/Mono and Java will be available, and with the ridiculous hype that Mono is getting, MS could well be in drivers seat. Not a pleasant prospect...
Have you noticed that the syntax of Java is rather familiar (C++), and the semantics are not very new either (Simula 67)?
Whereas the VM is remarkably innovative - bytecode verifier, security domains, JIT compilers, advanced GCs.
Care to rethink those thoughts?
Java does not have a built-in arbitrary precision rational type
Nor does COBOL. Perhaps you're thinking of Scheme?
Anyway, COBOL users that have a clue (e.g. the UK Revenue Service) use 128 bit integers for monetary amounts - decimals are, er, pointless.
Dear oh dear, some people are hard to please.
What shapes would this young fellow like to meet/frag on screen instead of people? Trolls? Amphibious landing craft?
And how dare people dis innovations coming from my home town (no, I'm not on the payroll).
Personally, I think producing a 3D head model from two ordinary pictures is a neat trick. Meeting 'avatars' of friends on line is surreal but definitely entertaining. It'll catch on sooner or later, unlike a lot of crud from the last 2 years...
when Mono becomes mature, and some poor soul does a functional port of things like the Forms library
...and when MS decides not to sue the copiers of their Forms library...
Remember, Forms Dotnet is not standardized, nor are the database APIs - in fact 1000-odd of the 1200 APIs in Dotnet are not standardized or open in any sense.
I agree with the poster - start with PostgreSQL and the like (or a Java database) to build a sensible alternative to Access.
I might as well use an OS written in Java... (no offense to java, but that'd suck.)
Well, probably, now... but actually it's not clear that this will be the case forever. Yes, I will point out that Java gets quite a bit faster with each release, but more importantly the hardware gets more diverse year on year. CPUs with big register files, vector operations, 64 bit operations... there's a fair slew of chips out there already, before Clawhammer & co appear, and I doubt if C compilers are going to optimize for all of them. In fact, that's impossible. So step forward the JIT, the guy that knows your hardware, and even your usage patterns and can optimize for both. It's the only practical solution longterm... convinced anyone?
Nope. You're putting words into my mouth.
/., I think you'd have a hard time proving that was definitely the case.
Developing Windows Forms is bad because it:
a) overlaps with Swing, AWT, SWT (and for that matter, WFC)
and
b) makes users vulnerable to IPR attacks from MS
As you strenously and repeatedly point out, SWT would be an equally bad in duplicating Swing, but only if there were no technical justification for it. However, judging by the number of 'Swing is slow and ugly' complaints here on
I do not accept that Java is anywhere near as proprietary as Dotnet. The number and size of companies producing Java products (not just products based on Java) is clear proof of that. Yes, Sun and IBM and others have IPR, but they do not constitute an aggressive monopoly, and the worst that can happen is that a product has to license that IPR on the same basis as partner companies. With MS, there's no guarantee of a license at all.
If this bothers you, I would suggest you try Parrot etc. In any event, none of this can make the case for embracing Dotnet.
Yes, Sun benefits from JUnit just as MS benefits from NUnit. However, because of the lead Java has established, and the remote possibility of mainstream Dotnet apps running on Mono, the flow of OSS value is going mostly from Java to C#. Once you and your buddies have helped establish Dotnet as the dominant platform, not because it offers any compelling technical advantage but because you got bored with Java, the Java economy will die off and MS will be in the driving seat of Linux development.
Lastly, in case it isn't obvious, the reason that Kaffe is immature is that high quality JVMs are available for Linux from both Sun and IBM (and soon BEA). In the unlikely event that IBM decided that its $1B investment in Linux wasn't a good idea, Kaffe could be revived. However, this is about as likely as MS supporting the complete Dotnet platform on BSD.
So to sum up, Java should be embraced because:
1) Already mature technically
2) People know it
3) Built-in cross-platform support (no Windows Handles and backslash-only paths here)
4) Linux support from vendors
5) The whole Java platform evolution and IPR is somewhat open. This avoids the trap set by MS where a little bit of the platform is offered to a passive standards body and the rest kept proprietary.
Mo. Namespaces allow nothing of the sort - an XML Document cannot contain another XML Document, with or without namespaces.
This is why HP came up with the hack of putting SOAP messages in mutipart-MIME wrappers - this was necessary to pass XML Docs as arguments in a SOAP doc. Your Jabber stream is using a similar wrapper - a wrapper which is not XML.
Cue 100s of language pedants to leap in and say that you are referring to dynamic typing rather than polymorphism. Java is statically typed, which means that it eliminates run-time type errors, unless you use downcasting (or operations that can throw UnsupportedOperation exceptions), but the penalty is that you have to label all your variables with their type, unlike Python.
There's a rather dated discussion here: Object FAQ
Inconsistency is bad wherever. If IBM did SWT for purely political reasons then that's a problem - the jury seems to be out on this one - but that doesn't give others the excuse to arbitrarily duplicate things further.
Because Java was here first, and C# adds nothing from a technical standpoint, you've ended up arguing how OSS developments (JUnit etc.) can enhance a proprietary platform rather than how non-proprietary systems might benefit.
The problem is that we're years away from this relationship being equitable. Applications like Photoshop are not going to be available for Mono for a long time, if ever. Meanwhile, Dotnet gathers developer support with your help.
Include me out.
When you say "you don't really care about the type as long as the object supports the operations you expect it to" this is true for the original type of the object - a WeakPinkWobblyHashMap, say - but you do care that it's a Map, because you're about to call Map operations on it.
So you either do this by declaring a Map parameter, or accepting a superclass (such as Object) and downcasting to a Map - which might throw an exception if the object isn't a Map.
It's downcasting that's a problem in all code, but I don't think Java does any worse than any other language in this - templates/generics are the only thing that would help and they can still get very messy.
Personally I don't dislike the
style, because of the chance you have to use subclasses on the right, though it is noisier than typical statements in other languages.
Actually, I didn't follow this point. Yes, there's a lot of casting in Java, but that's so you can take advantage of polymorphism - cast from a WeakHashList or whatever to a List and then you can pass it to any List consumer.
Or are you thinking of Objects in Collections - would generic classes / templates help? If so, you shouldn't have too long to wait (for Java, longer for C#.)
i don't recall this being about C#... if C# sucks as much as java, well, then that's a shame.
See subject. And yes, it's a shame, or at least, a wasted opportunity.
Alright, some reasonable points IMHO. Diversity is popular on /., more so than consistency, so I can see how the more is better argument will appeal to many.
However, though it might be possible to merge the JVM and CLR, a merger of the associated libraries is much less likely. In particular, it's hard to justify the effort in swimming upstream and trying to clone Windows Forms for Gtk when IBM is already
producing Java SWT for Gtk. What's the point? As soon as you've got a complete clone, you'll get sued - how does that help anyone?
I prefer diversity to be limited to real, technical diversity - Perl vs. Java, or Scheme vs. Visual Basic, or an AST-based IL vs. a bytecode IL. C# and Java are so close that the choice of one over the other won't be based on language characteristics - only the most pedantic advocates would see meaningful differences.
ROFL. I wrote a large portion of the CORBA specifications, as it happens, and was building OO systems in Smalltalk 12 years ago that can still put Java and Dotnet systems into the shade.
But of course these developments are nothing compared to the revolution that would follow the introduction of unsigned ints to Java. Can't wait...
5) It treats them as objects, at least as much as Dotnet does. I thought this was meant to be a comparison?
6) Hmmm... perhaps you'd care to elaborate? Again, examples of more useful polymorphism in C# etc. would be relevant here.
7) You mean like the split between reference types and value types in C#? Indeed. See here for an argument as to which is easier to deal with.
8) Distinguishing types from implementations is a hack? Thanks for the tip - don't forget to pass it on to Jim Rumbaugh next time you see him.
9) What a coincidence - Java happens to be the #1 teaching language so I guess they'll never learn! As a matter of interest, what does the MFC library smell like to you?
Glad you like Jython. A fine example of innovation building on the JVM, unlike Dotnet.
Equal? Not equally mature - or do you seriously want to compare Mono with Sun's 1.4 JVM on Linux? And not equally innovative - Java introduced all the significant advances years ago, Dotnet is pathetically derivative.
So the point is, in case it escaped you, the platform should I be writing my OSS app for is Java. Mono proponents have never demonstrated substantial technical benefits of Mono over Java, certainly not sufficient to justify entanglement with MS's lawyers - it's just a bandwagon.
I don't feel like getting into a big treatise on why the JVM will never be fast
I completely understand your position on that.
>An unsigned datatype? Are you serious? This is utterly trivial.
Utterly trivial unless you're going to do anything serious.
I'll keep it in mind if I find myself doing anything serious in my next 20 years in IT.
What's the difference between web services, and COM, CORBA and EJB? You are not likely to get a straight answer from the owners of the earlier technologies, because doing so would be tantamount to admiting that they should have begun by agreeing on open standards in the first place.
Perhaps that's why the "owners" joined the OMG, and later Sun's JCP? However, one company refused to participate in these efforts - I wonder who? If you can guess, congratulate yourself that you're more qualified than the author to write the next Web Services column!
Web Services may have some issues when network/security administrators figure out people will be using RPC through the firewall.
Mmmm, yes. Especially when they realize that they can't discriminate based on the target Object (there ain't one).
As we all remember from college, most protocols are layered, which allows encrypted bits to be layered inside routing / security bits, but an XML document can't be layered (it can't contain other XML documents).