It takes forever to build up credibility, and a couple of silly open letters and articles to blow it. That may not be just, but such is life.
A lot of ESR's credibility is for the fact that he says what he thinks. He doesn't always sugar-coat his opinions for corporate digestion, and doesn't seem to care if people consider him a nutcase or whatever. I respect him for that.
Many in his position would start to move more carefully, in order to not blow their "hard earned" reputation. Not ESR - he keeps on saying aloud things many of us want to be said aloud. I don't think I have ever strongly disagreed with anything he has written, and nobody listens to me, so it's nice to have ESR saying those things.
ESR-bashing seems to be all the rage at slashdot these days, and I wonder why that is. Are some slashdotters so insecure that the feel threatened when they see someone with a certain amount of self-importance/arrogance? Or are they offended because he is a self-proclaimed gun nut?
Screw that. We need one ESR, one Bruce Perens, one Linus and occasionally even one RMS. Well, we could use a few more Linuses and Bruces. But anyway.
I always thought Sun's tight control over Java was so that they could keep Microsoft from polluting it, using their usual 'embace, extend, extinguish' method.
Well, I guess that threat is gone now. MSFT doesn't even acknowledge that Java exists anymore.
It was widely considered a smart move - feeding it crack would have further aggravated SCO, on the basis of Linux using their methodologies and ideas to bring enterprise functionality to the kernel.
Need to see more files? Decrease zoom on icon view.
Been there, done that. It doesn't work like on windows and KDE, instead the listing becomes "sparse", and the icons are still above the name, instead of the left side where the listing would be much more compact and readable.
As I said before: provide valid points.
I don't know what points I could provide to illustrate the fact that KDE is faster. It just feels faster.
That was all?
Pretty much. If Gnome fixed the points I list in their 2.6 release I would be more than happy to switch. I would prefer using Gnome for ideological reasons anyway...
So gnome 2.4 is buggy? How? Care to explain which outstanding bugs refrain you from using 2.4 on a daily basis?
The keyboard layout switcher doesn't work. I run Gnome 2.4 on Fedora, and haven't seen a fix, so I guess the bug is still here. It renders the system unusable for me.
How does it work better for you?
It's mostly about Konqueror being better than Nautilus. I use "multicolumn" view on Konq to see as many files as possible, and Nautilus doesn't offer that. I can also right-click for "create new file" in Konq, not so for Nautilus. When I use gnome I do pretty much all my file management in a terminal, while using KDE I've actually caught myself *gasp* using the file manager for the desktop.
Right now, I'd place Gnome and KDE as being about equal to eachother. I switched completely to Gnome because I believe that Gnome will continue to surpass KDE.
Have you tried KDE 3.2 beta or rc? I'm currently running on KDE 3.2 rc, and I'm not all that sure whether Gnome will continue (or even start) surpassing KDE. The 3.2 preversions still have some bugs, but boy, is it snappy and sweet! This was the first time a Linux desktop passed winxp in point-and-drool usability.
Gnome is doing alright, I guess, but it still doesn't approach KDE. I'm waiting for Gnome 2.6, hoping it will be snappier (and less buggy) than 2.4. There are no reasons why Gnome wouldn't "win" KDE in the "end", with all the corporate support (at least in spirit, if not developer hours) and superior licensing (LGPL vs. GPL-or-pay-up), but meanwhile, KDE continues to Work Better (tm) and I will continue using it on my home desktop. I give every new version of Gnome a chance, trying to keep using it for a few weeks or so, but I always go back to KDE.
For starters, Konqueror just kills Nautilus. Does Nautilus have a shortage of developers or what is wrong with them? If Konqueror could just be ported to use GTK...
But if you are currently using C or C++, with maybe X for graphics, or Java, then I suggest you stay with those.
Perhaps they might want a more Agile language, instead of clunky C++/Java they are using at the moment? Going with Python, they can retain the scalability while developing code/unit tests/prototypes much faster. Being primarily a C++ programmer, getting to program in Python is extremely liberating. It feels like being able to talk fluently again, instead of measuring every word carefully and then translating them to mandarin china with an unalphabetized dictionary.
All three languages, with their graphics, give you a far richer toolset.
This might be true w/ Java, but not w/ C++. Also, Python libraries are always easier to use and learn in my experience.
Well, most people use python to write scripts that are smaller than what they would write in C++ or java.
Please don't confuse performance and size. Larger systems don't require bigger performance, performance is needed in tight inmost loops. And those you can implement in C while retaining the rest of the Python code.
Python is basically an attempt to merge Perl, TCL/TK and object orientated programming.
No way in hell. Python tries its best to avoid perlisms, and TCL/Tk doesn't even come close. Python has a strongly typed object system with one namespace.
I don't think that we really have to discuss the problems of Perl's "object system"
Perls object system is a hack. Python object system fits like a glove. ISTR that Larry kinda "copied" the objsystem from Python (and not vice versa), but it didn't really fit perl.
or the shortcomings of TCL/TK.
Shortcomings of TCL/Tk have really nothing to do with the topic. Don't try to sneak TCL/Tk into this. This has got to be the clumsiest strawman argument I've seen in a while. Chewbacca lives on Endor?
The result can be seen when you try to program a caller frame instance-preserving continuation in Python.
What do you mean? Closures (or "nested scopes" as they are referred to in the language docs - look them up before whining) work as expected. Can you give an example of the thing you are talking about in a language you know (assuming you know one). Are talking about what Stackless Python is trying to do?
But when the project advances they suddenly notice that python doesn't provide all necessary features and a whole rewrite is in order.
You don't really need "features", you can use libraries to add "features" and the core language is flexible enough for pretty much any tasks.
Python will be ported when the phones become more commonplace, common enough that the porting will be done by the open source community itself, not necessarily Nokia.
I guess choosing Perl for porting is a form of popularity whoring - Perl is more popular that Python, let's port that, even when porting Python would be a more sensible move in technical sense (why would any sane person port such a monolithic awk-sed-workalike to a phone is beyond me). And also in the "open source community" sense; Perl seems pretty much to be a fad that is losing the significance it once has. A has-been, if you will.
Equally possible is that they are doing the port because some perl fans inside Nokia are willing to do it. I guess I'll have to bring this up the next time I deal with Nokians...
If you believe that the browsers themselves adhere to the standards, then you are very naive.
Perhaps not all the standards. But if you write the app w/ standards in mind, and also see that it runs on *some* browser, it is fair to expect the other browser to catch up.
Shouldn't supporting Mozilla be obvious? Web applications should adhere to standards, if they don't, well, they are crappy web applications in the first place. I don't consider this "generous", rather than just fixing their broken applications to work like they should have worked in the first place.
BSD is for those that love Unix. Linux is for those that hate Windows.
Only a total moron would love Unix at times like this. Ever heard of this company called SCO?
Unix is dead, long live Posix!
And BTW, I used to play w/ various BSD's in the past. However, I would be hard pressed to try any of them again, I just don't like the people in the BSD community (well, NetBSD might be an exception, don't know about DragonFlyBSD...). I can't imagine myself being among them, badmouthing Linux at any given opportunity (especially as *BSD benefits immensely from success of Linux, which BSD people don't seem to realize).
Getting a "thumbs up" from Microsoft (which BSD community does, because MSFT can rip them off any time they want) doesn't help either. Enemy of my enemy is my friend, and apparently BSD is not an enemy of MSFT:-).
I'd like to see pros and cons, also benchmarks of Linux 2.6.1 vs. FreeBSD 5.2.
There was a benchmark somewhere a while ago b/w Linux 2.6.0-test* and FreeBSD 5.* (I think it was even linked to at/.). I seem to remember Linux winning FreeBSD in performance, emerging as the fastest Open Source operating system. OpenBSD was the slowest OS by significant margin.
FreeBSD 5.* was still better than Linux 2.4.*, though. But the comparison is not fair, since Linux 2.4.* is a production kernel while FreeBSD 5.* isn't. Apparently the superior performance of FreeBSD is a myth, at least to some extent.
In Java the compiler would check the following definition to ensure that all objects passed to myFunction are of type MyClass or descended from it
That's not Polymorphism, it's plain old static typing.
In a dynamically typed language there can be no such assurances. The best that can be done is to manually implement checks, but this is tedious and time consuming.
There is an assurance that the object has the methods that are called, because calling something that doesn't exist raises an exception.
Additionally, these checks will only occur at runtime, thus complicating the process of debugging.
They don't complicate debugging at all - you see the traceback on exception, and notice what line of code calls a method that doesn't exist. Such errors are trivial to correct, and are not really all that common either (usually typos).
In the end, I suppose it is a matter of preference. Personally, I would rather place the burden of performing these tasks on the compiler.
That's because usually these checks are not made at all in dynamically typed languages. They are simply not needed. It's a tradeoff, really. Dynamically typed languages lose some, and win a lot.
Again, as your experience is with PHP, I would advise you to play around w/ Python a little bit and then reconsider these things. Believe me, I used to think the way you do now before discovering Python.
The is no way of telling whether a particular class is really a descendent of the parent class the polymorphic expression was intended to act upon.
The most derived version of a method gets always called, unless you explicitly request less derived version. Just as in Java.
There is nothing in Python to prevent someone from implementing only half of an interface and trying to use it.
Zope Interfaces can be used to enforce the implementation of all of the interface. That's why they were created.
I usually just do
class Interface: pass
Because I don't really think enforcement is worth the trouble of dragging in the Zope Interface class to the project. In large projects it might be, esp. if a lot of the code will be produced by 3rd party developers.
In answer to your last question, I was using PHP at the time.
Well, that explains your prejudice. PHP is not generally known to scale w/ program size, Python is.
Runtime checks can stop a program if they detect that a contract has been violated (and embarass you in front of the users), but they can't prevent starting a program that may violate contracts.
Testing (esp. Unit Testing) takes care of that.
They also aren't inherited per method.
In general such tests should only be put in the outmost interfaces. But I will reiterate that I don't really believe such tests are necessary, because calling a method with wrong argument type is pretty certain to raise an exception anyway.
Slashdot Mirror
Since when is Sun a friend of open source?
Indeed. What kind of friend sponsors a lawsuit against you in an attempt to hurt you, and still expects you to be his friend?
It takes forever to build up credibility, and a couple of silly open letters and articles to blow it. That may not be just, but such is life.
A lot of ESR's credibility is for the fact that he says what he thinks. He doesn't always sugar-coat his opinions for corporate digestion, and doesn't seem to care if people consider him a nutcase or whatever. I respect him for that.
Many in his position would start to move more carefully, in order to not blow their "hard earned" reputation. Not ESR - he keeps on saying aloud things many of us want to be said aloud. I don't think I have ever strongly disagreed with anything he has written, and nobody listens to me, so it's nice to have ESR saying those things.
ESR-bashing seems to be all the rage at slashdot these days, and I wonder why that is. Are some slashdotters so insecure that the feel threatened when they see someone with a certain amount of self-importance/arrogance? Or are they offended because he is a self-proclaimed gun nut?
Screw that. We need one ESR, one Bruce Perens, one Linus and occasionally even one RMS. Well, we could use a few more Linuses and Bruces. But anyway.
"What can be the VB for Free Software?"
That's easy to answer. Python. Java is too low level for RAD, and quite possibly won't be Free Software in the predictable future.
I always thought Sun's tight control over Java was so that they could keep Microsoft from polluting it, using their usual 'embace, extend, extinguish' method.
Well, I guess that threat is gone now. MSFT doesn't even acknowledge that Java exists anymore.
...would you give away the only technology that might possibly save your company from bankrupcy?
.Net threat. Or are they waiting for .Net to eat 30% of Javas lunch first?
.Net is a choice b/w two evils. Sun could stop .Net on it's tracks by opening up Java.
How do you expect them to cash in on Java?
It would be more beneficial for Sun to open up Java to combat the
As it stands, the choice b/w Java and
the neophyte wrote it in perl
said the birds wouldn't return next spring
it was a long winter
Okay, who's been feeding 2.6 speed?
It was widely considered a smart move - feeding it crack would have further aggravated SCO, on the basis of Linux using their methodologies and ideas to bring enterprise functionality to the kernel.
Need to see more files? Decrease zoom on icon view.
Been there, done that. It doesn't work like on windows and KDE, instead the listing becomes "sparse", and the icons are still above the name, instead of the left side where the listing would be much more compact and readable.
As I said before: provide valid points.
I don't know what points I could provide to illustrate the fact that KDE is faster. It just feels faster.
That was all?
Pretty much. If Gnome fixed the points I list in their 2.6 release I would be more than happy to switch. I would prefer using Gnome for ideological reasons anyway...
So gnome 2.4 is buggy? How? Care to explain which outstanding bugs refrain you from using 2.4 on a daily basis?
The keyboard layout switcher doesn't work. I run Gnome 2.4 on Fedora, and haven't seen a fix, so I guess the bug is still here. It renders the system unusable for me.
How does it work better for you?
It's mostly about Konqueror being better than Nautilus. I use "multicolumn" view on Konq to see as many files as possible, and Nautilus doesn't offer that. I can also right-click for "create new file" in Konq, not so for Nautilus. When I use gnome I do pretty much all my file management in a terminal, while using KDE I've actually caught myself *gasp* using the file manager for the desktop.
Is it faster? fancier? more efficient?
Yes, dunno, yes.
Right now, I'd place Gnome and KDE as being about equal to eachother. I switched completely to Gnome because I believe that Gnome will continue to surpass KDE.
Have you tried KDE 3.2 beta or rc? I'm currently running on KDE 3.2 rc, and I'm not all that sure whether Gnome will continue (or even start) surpassing KDE. The 3.2 preversions still have some bugs, but boy, is it snappy and sweet! This was the first time a Linux desktop passed winxp in point-and-drool usability.
Gnome is doing alright, I guess, but it still doesn't approach KDE. I'm waiting for Gnome 2.6, hoping it will be snappier (and less buggy) than 2.4. There are no reasons why Gnome wouldn't "win" KDE in the "end", with all the corporate support (at least in spirit, if not developer hours) and superior licensing (LGPL vs. GPL-or-pay-up), but meanwhile, KDE continues to Work Better (tm) and I will continue using it on my home desktop. I give every new version of Gnome a chance, trying to keep using it for a few weeks or so, but I always go back to KDE.
For starters, Konqueror just kills Nautilus. Does Nautilus have a shortage of developers or what is wrong with them? If Konqueror could just be ported to use GTK...
I suppose it will give a new meaning to IANAL also.
But if you are currently using C or C++, with maybe X for graphics, or Java, then I suggest you stay with those.
Perhaps they might want a more Agile language, instead of clunky C++/Java they are using at the moment? Going with Python, they can retain the scalability while developing code/unit tests/prototypes much faster. Being primarily a C++ programmer, getting to program in Python is extremely liberating. It feels like being able to talk fluently again, instead of measuring every word carefully and then translating them to mandarin china with an unalphabetized dictionary.
All three languages, with their graphics, give you a far richer toolset.
This might be true w/ Java, but not w/ C++. Also, Python libraries are always easier to use and learn in my experience.
Well, most people use python to write scripts that are smaller than what they would write in C++ or java.
Please don't confuse performance and size. Larger systems don't require bigger performance, performance is needed in tight inmost loops. And those you can implement in C while retaining the rest of the Python code.
Python is basically an attempt to merge Perl, TCL/TK and object orientated programming.
No way in hell. Python tries its best to avoid perlisms, and TCL/Tk doesn't even come close. Python has a strongly typed object system with one namespace.
I don't think that we really have to discuss the problems of Perl's "object system"
Perls object system is a hack. Python object system fits like a glove. ISTR that Larry kinda "copied" the objsystem from Python (and not vice versa), but it didn't really fit perl.
or the shortcomings of TCL/TK.
Shortcomings of TCL/Tk have really nothing to do with the topic. Don't try to sneak TCL/Tk into this. This has got to be the clumsiest strawman argument I've seen in a while. Chewbacca lives on Endor?
The result can be seen when you try to program a caller frame instance-preserving continuation in Python.
What do you mean? Closures (or "nested scopes" as they are referred to in the language docs - look them up before whining) work as expected. Can you give an example of the thing you are talking about in a language you know (assuming you know one). Are talking about what Stackless Python is trying to do?
But when the project advances they suddenly notice that python doesn't provide all necessary features and a whole rewrite is in order.
You don't really need "features", you can use libraries to add "features" and the core language is flexible enough for pretty much any tasks.
Python will be ported when the phones become more commonplace, common enough that the porting will be done by the open source community itself, not necessarily Nokia.
I guess choosing Perl for porting is a form of popularity whoring - Perl is more popular that Python, let's port that, even when porting Python would be a more sensible move in technical sense (why would any sane person port such a monolithic awk-sed-workalike to a phone is beyond me). And also in the "open source community" sense; Perl seems pretty much to be a fad that is losing the significance it once has. A has-been, if you will.
Equally possible is that they are doing the port because some perl fans inside Nokia are willing to do it. I guess I'll have to bring this up the next time I deal with Nokians...
If you believe that the browsers themselves adhere to the standards, then you are very naive.
Perhaps not all the standards. But if you write the app w/ standards in mind, and also see that it runs on *some* browser, it is fair to expect the other browser to catch up.
Shouldn't supporting Mozilla be obvious? Web applications should adhere to standards, if they don't, well, they are crappy web applications in the first place. I don't consider this "generous", rather than just fixing their broken applications to work like they should have worked in the first place.
BSD is for those that love Unix. Linux is for those that hate Windows.
:-).
Only a total moron would love Unix at times like this. Ever heard of this company called SCO?
Unix is dead, long live Posix!
And BTW, I used to play w/ various BSD's in the past. However, I would be hard pressed to try any of them again, I just don't like the people in the BSD community (well, NetBSD might be an exception, don't know about DragonFlyBSD...). I can't imagine myself being among them, badmouthing Linux at any given opportunity (especially as *BSD benefits immensely from success of Linux, which BSD people don't seem to realize).
Getting a "thumbs up" from Microsoft (which BSD community does, because MSFT can rip them off any time they want) doesn't help either. Enemy of my enemy is my friend, and apparently BSD is not an enemy of MSFT
You can't market a 4000+ if Intel has no 4GHz processor.
Umm... yes you can. Most Joe Sixpacks can extrapolate the performance.
I'd like to see pros and cons, also benchmarks of Linux 2.6.1 vs. FreeBSD 5.2.
/.). I seem to remember Linux winning FreeBSD in performance, emerging as the fastest Open Source operating system. OpenBSD was the slowest OS by significant margin.
There was a benchmark somewhere a while ago b/w Linux 2.6.0-test* and FreeBSD 5.* (I think it was even linked to at
FreeBSD 5.* was still better than Linux 2.4.*, though. But the comparison is not fair, since Linux 2.4.* is a production kernel while FreeBSD 5.* isn't. Apparently the superior performance of FreeBSD is a myth, at least to some extent.
Today most PC owners want IM, MP3s and p0rn.
Linux is perfect for such use. Howver, many people want to play games, and Linux kinda sucks at that ATM.
And besider, it's spelled "pr0n".
In Java the compiler would check the following definition to ensure that all objects passed to myFunction are of type MyClass or descended from it
That's not Polymorphism, it's plain old static typing.
In a dynamically typed language there can be no such assurances. The best that can be done is to manually implement checks, but this is tedious and time consuming.
There is an assurance that the object has the methods that are called, because calling something that doesn't exist raises an exception.
Additionally, these checks will only occur at runtime, thus complicating the process of debugging.
They don't complicate debugging at all - you see the traceback on exception, and notice what line of code calls a method that doesn't exist. Such errors are trivial to correct, and are not really all that common either (usually typos).
In the end, I suppose it is a matter of preference. Personally, I would rather place the burden of performing these tasks on the compiler.
That's because usually these checks are not made at all in dynamically typed languages. They are simply not needed. It's a tradeoff, really. Dynamically typed languages lose some, and win a lot.
Again, as your experience is with PHP, I would advise you to play around w/ Python a little bit and then reconsider these things. Believe me, I used to think the way you do now before discovering Python.
The is no way of telling whether a particular class is really a descendent of the parent class the polymorphic expression was intended to act upon.
The most derived version of a method gets always called, unless you explicitly request less derived version. Just as in Java.
There is nothing in Python to prevent someone from implementing only half of an interface and trying to use it.
Zope Interfaces can be used to enforce the implementation of all of the interface. That's why they were created.
I usually just do
class Interface: pass
Because I don't really think enforcement is worth the trouble of dragging in the Zope Interface class to the project. In large projects it might be, esp. if a lot of the code will be produced by 3rd party developers.
In answer to your last question, I was using PHP at the time.
Well, that explains your prejudice. PHP is not generally known to scale w/ program size, Python is.
You can't use true polymorphism.
How come?
You can't enforce inheritance.
Yes you can, if you really want to.
You can't code to an interface, or abstract class.
Of course you can. Check out Zope's Interface, for example.
You can't just look at a function definition and know what type of parameters it contains.
You can write anything you want in the docstring. Nothing prevents you from writing:
""" str,int,int -> int """
These are all the things that will slow you down in six months, and beyond.
What language did you use?
Runtime checks can stop a program if they detect that a contract has been violated (and embarass you in front of the users), but they can't prevent starting a program that may violate contracts.
Testing (esp. Unit Testing) takes care of that.
They also aren't inherited per method.
In general such tests should only be put in the outmost interfaces. But I will reiterate that I don't really believe such tests are necessary, because calling a method with wrong argument type is pretty certain to raise an exception anyway.