Alternately, a truely open Java could include a Free compatibility test suite, allowing many of the existing reimplementations to certify that they are indeed compatible with Sun's reference version.
I'm not sure that Java is strongly typed, though. For example, if I didn't know better, I'd expect that Java containers would hold type information. At least C++ generics allow this. (Java generics don't count. If all I wanted were shorter code without any kind of compile time safety, I could write my own preprocessor to cast to and from Object!)
I think that's not the real issue though.
I can find you dozens of Perl programs that use global variables willy-nilly, have no documentation, expose a wide range of security problems, have massive code duplication, reinvent well-known wheels badly, and show no evidence of design, maintenance, or care.
I'm not sure how static typing can fix any of those problems.
I can also find you dozens of Perl programs that have comprehensive test suites, well-factored code, sane and useful documentation, and well-designed APIs which have had code contributions from multiple authors.
Again, I'm not sure that dynamic typing worked against those projects. In fact, I personaly find it much easier to write test code in languages that allow allomorphism!
I agree that there's terrible code in serious systems and that people ought to be more careful and disciplined. I disagree that static typing is the way to enforce that. If you're worried what novices might do with powerful features, I think it's better to teach them how and when to use those features well than to remove those features from the language, where even the experts can't use them.
There are some fundamentally defined tenants of good programming however and they include strong typing for one.
I think Lisp hackers might well disagree, along with people who program Python and Ruby and, if they're honest, C, C++, Java, and C#. See ManifestTyping on the C2 Wiki for a fuller discussion.
I have seen bad code in Perl, but I've seen it in many, many other languages. Perhaps a more interesting question is "Does Perl encourage sloppy programming or does it allow people who aren't concerned about so-called software-engineering to do productive things?"
I pity the people who try to read your comment but don't understand the words "subset" and "programs" or independent clauses joined by semicolons. Therefore, English is a write-only language.
No. It's that no one can take away your right to fork the software, your right to use the software as you see fit, your right (or your proxy's right) to examine and change the software if you desire, and your right to redistribute the software, as long as you allow other people the same rights.
That's true; there's a lot of diversity between Linux distributions. It's well worth keeping that in mind.
I meant something else, however. The more people who run Linux, the more motivation hardware developers will have to write or to help to write drivers. Things are much better now than they were five years ago. I think this will continue.
Additionally, the idea of the CLR is language neurtrality
Sure, that's the idea, but the actual situation is that only languages that act like C# or Java run well on the CLR. It's certainly possible to emulate continuations and closures and coroutines atop the CLR, but you'll lose a lot of speed and probably a lot of flexibility that way.
Unless the CLR suddenly gains several new features not present in C#, Perl, Python, and Ruby will likely never run well -- or fully -- on it.
Red Hat EL is along the same lines. I don't see anyone making a bad guy out of them.
I don't expect Red Hat to push their own semi-open programming language and libraries as the real target for writing applications on RHEL, then, in the future, swap out the free Linuxy bits for an expensive, proprietary operating system.
Actually, we were talking about Roles (though not calling them that) before that paper was written. It was good fortune that two members of the design team caught Andrew Black's presentation of the paper and sent it along to Larry with a note saying "This must be a good idea; Smalltalkers are thinking about it too!"
True, the arrow does have a nice visual effect. Of course, it's also two characters compared to one -- and it's nice to make common things short and sweet.
It's a long way from "I couldn't install the software on my machine" to "The developers don't care about me or my operating system".
The developers may not even have had access to Mac OS X!
I work on some open source software that I'd like to make available to Windows users, but I don't have a Windows box nor a Windows compiler. I rely on other people who do to report errors and help me debug things. I don't have to do that, but I want to.
If the author presents these points as reasons why end-users aren't adopting open source software but they're true of much proprietary software as well, then she hasn't really answered her question.
Her points may be very valid, but in that case her conclusion is not.
Python, Perl/Parrot, Ruby, etc. don't offer the native compiled code performance that is critical for desktop apps.
I'm not sure that's a universal truth. In some cases, such as math-intensive data processing, Perl, Python, and Ruby's primitives are probably too heavy for very fast processing, yes. (I think Parrot has an amazing edge there, but time will tell.) In many other cases, the desktop apps I use spend a lot more time waiting for events than anything else.
What advantage does a "pre-compiled" program have over a "compiled from source every time" program in that case?
Is that really such a barrier to adoption in big businesses? I can see the barrier for home users and small businesses, but I'd expect big businesses to have their own installation guidelines contrary to OEM practices.
Slashdot Mirror
Alternately, a truely open Java could include a Free compatibility test suite, allowing many of the existing reimplementations to certify that they are indeed compatible with Sun's reference version.
Go ahead and take the code from 1991. Next year you can have the code from 1992. In 2017, you can have code written today.
(Please note that I don't hold copyright over any part of the Linux kernel.)
I'm not sure that Java is strongly typed, though. For example, if I didn't know better, I'd expect that Java containers would hold type information. At least C++ generics allow this. (Java generics don't count. If all I wanted were shorter code without any kind of compile time safety, I could write my own preprocessor to cast to and from Object!)
I think that's not the real issue though.
I can find you dozens of Perl programs that use global variables willy-nilly, have no documentation, expose a wide range of security problems, have massive code duplication, reinvent well-known wheels badly, and show no evidence of design, maintenance, or care.
I'm not sure how static typing can fix any of those problems.
I can also find you dozens of Perl programs that have comprehensive test suites, well-factored code, sane and useful documentation, and well-designed APIs which have had code contributions from multiple authors.
Again, I'm not sure that dynamic typing worked against those projects. In fact, I personaly find it much easier to write test code in languages that allow allomorphism!
I agree that there's terrible code in serious systems and that people ought to be more careful and disciplined. I disagree that static typing is the way to enforce that. If you're worried what novices might do with powerful features, I think it's better to teach them how and when to use those features well than to remove those features from the language, where even the experts can't use them.
I think Lisp hackers might well disagree, along with people who program Python and Ruby and, if they're honest, C, C++, Java, and C#. See ManifestTyping on the C2 Wiki for a fuller discussion.
I have seen bad code in Perl, but I've seen it in many, many other languages. Perhaps a more interesting question is "Does Perl encourage sloppy programming or does it allow people who aren't concerned about so-called software-engineering to do productive things?"
I pity the people who try to read your comment but don't understand the words "subset" and "programs" or independent clauses joined by semicolons. Therefore, English is a write-only language.
Minor nitpick: that's the price of distributing GPLd code to which you do not hold the copyright.
Think of it as a deterrent. "Not only are murder, theft, and rape wrong, but if you're caught, you might have to share a cell with a spammer!"
Perhaps his brain is too full to hold both what he just learned and the community's contact information.
No. It's that no one can take away your right to fork the software, your right to use the software as you see fit, your right (or your proxy's right) to examine and change the software if you desire, and your right to redistribute the software, as long as you allow other people the same rights.
That's true; there's a lot of diversity between Linux distributions. It's well worth keeping that in mind.
I meant something else, however. The more people who run Linux, the more motivation hardware developers will have to write or to help to write drivers. Things are much better now than they were five years ago. I think this will continue.
Are you sure it's not the other way around?
That's as neat as punching random people in the street because they might punch you.
Remember, die hard fans write fanfic! I certainly don't want that.
Sure, that's the idea, but the actual situation is that only languages that act like C# or Java run well on the CLR. It's certainly possible to emulate continuations and closures and coroutines atop the CLR, but you'll lose a lot of speed and probably a lot of flexibility that way.
Unless the CLR suddenly gains several new features not present in C#, Perl, Python, and Ruby will likely never run well -- or fully -- on it.
With the exception of Ruby, they all use virtual machines -- just like Java.
DS9 was pretty good, but I liked the Defiant better when it was called the White Star.
I don't expect Red Hat to push their own semi-open programming language and libraries as the real target for writing applications on RHEL, then, in the future, swap out the free Linuxy bits for an expensive, proprietary operating system.
I can't extend Sun the same goodwill.
Yeah, but you have to keep spending money on the PS2 to buy new games. Wouldn't that make it more expensive in the long ...
Wait, nevermind.
Actually, we were talking about Roles (though not calling them that) before that paper was written. It was good fortune that two members of the design team caught Andrew Black's presentation of the paper and sent it along to Larry with a note saying "This must be a good idea; Smalltalkers are thinking about it too!"
True, the arrow does have a nice visual effect. Of course, it's also two characters compared to one -- and it's nice to make common things short and sweet.
It's a long way from "I couldn't install the software on my machine" to "The developers don't care about me or my operating system".
The developers may not even have had access to Mac OS X!
I work on some open source software that I'd like to make available to Windows users, but I don't have a Windows box nor a Windows compiler. I rely on other people who do to report errors and help me debug things. I don't have to do that, but I want to.
If the author presents these points as reasons why end-users aren't adopting open source software but they're true of much proprietary software as well, then she hasn't really answered her question.
Her points may be very valid, but in that case her conclusion is not.
I'm not sure that's a universal truth. In some cases, such as math-intensive data processing, Perl, Python, and Ruby's primitives are probably too heavy for very fast processing, yes. (I think Parrot has an amazing edge there, but time will tell.) In many other cases, the desktop apps I use spend a lot more time waiting for events than anything else.
What advantage does a "pre-compiled" program have over a "compiled from source every time" program in that case?
For now. What parts of it really require Linux underneath, though, and not Solaris?
Is that really such a barrier to adoption in big businesses? I can see the barrier for home users and small businesses, but I'd expect big businesses to have their own installation guidelines contrary to OEM practices.