Indeed, we may be seeing Perl's reign in certain areas coming to an end. Java, PHP and Ruby have taken over when it comes to developing web apps. The regular expression support of languages like Python, Ruby, and even C# trump that of Perl.
While Perl was once a great innovator, today it is increasingly becoming a thing of the past. What were once great benefits of Perl have become standard features in many other languages. And unfortunately, Perl has failed to stay a step ahead of the game. The Perl 6 delays have not helped it at all. Indeed, while Perl will surely be used for decades to come, it is quite rapidly losing its place as the glue of the open source world. Python and Ruby are quickly taking over, if they haven't already done so.
It's not an issue whether we all want Larry to take over Perl again. It's more a matter of whether or not he wishes to resume such leadership. And judging by his past statements, he is not interested in that. He wants Perl 6 to be a community effort, as it has been.
As it says on the Perl 6 home page: "Perl 5 was my rewrite of Perl. I want Perl 6 to be the community's rewrite of Perl and of the community." - Larry Wall, State of the Onion speech, TPC4
Indeed, those who resort to insults during debates are most likely in the wrong. It's one of those things we see time and time again. One such example could very well be this instance of Jack Thompson debating a 14-year-old child. Another notable example is that of the KOffice developer who resorted to insulting a long time KDE and KOffice user during a discussion of the future of the KOffice project.
I'm over here on the other side of the Atlantic, so perhaps that's why I haven't heard of this Jack Thompson fellow. Who exactly is he, and why should I care what he has to say?
Indeed. That's why RedHat is a distribution to be avoided. I don't trust their support to be worthwhile when they press ext3 as an enterprise-grade filesystem. I'll stick with distributions such as Debian, which do offer support for the filesystems which are used for intensive tasks.
I care what he or she thinks. I care what you think, too. But when you think that nobody cares whatever he or she thinks, then I know you are wrong. Because I care.
Even if it is a partial list, XFS and JFS are two of the major Linux filesystems. It'd be like leaving out FAT32 support out of a list of filesystems that Windows supports. They're just too major to be left out.
Actually, I have several children. They're all adults now, too. And to top it off, I was correct. That's probably why the KOffice developer had to resort to insults, rather than the truth, in our discussion.
Re:Not only is it a fantastic editor...
on
Vim 6.4 Released
·
· Score: 1
Why use the half-assed less when you have have the real VIM? The memory requirement differences between the two are basically irrelevant these days, and speedwise they're indistinguishable.
Not only is it a fantastic editor...
on
Vim 6.4 Released
·
· Score: 4, Interesting
... but it is also a fantastic pager. Using it instead of less or more to quickly scan over source code is a blessing! Indeed, you get the syntax highlighting of a GUI editor, but without the overhead. You can view files instantly from the command line, and they're very nicely formatted.
Re:Yes, but is it better than emacs??
on
Vim 6.4 Released
·
· Score: 1
Gregory John Casamento is not a stupid man by any means. Indeed, he is responsible for some amazing work. Take Gorm, for example. It brings the cutting edge development techniques of NeXT to Linux and other non-NeXT/non-Apple systems.
If I was wrong then it would have been more than acceptable for that KOffice developer to point out that I was incorrect. However, I was not. I was completely right. That's why he had to resort to insults in his discussion with me. Since I was wielding the truth, he had to rely on childish namecalling.
Regardless, it was a very unprofessional act to perform. At least there are others on the open source community who do set a good example for the other developers.
Re:Yes, but is it better than emacs??
on
Vim 6.4 Released
·
· Score: 2
Perhaps the use VIM for the same reason you seem to enjoy using NeXTSTEP-styled systems: they just find it works for them. It allows them to be as productive as they can be.
Only if they find a good way of doing it.
on
Vim 6.4 Released
·
· Score: 1
Indeed, finding out a "nice" way of doing it is essential. Nothing is more of a hassle than having Eclipse or the Visual Studio IDE autocomplete a keyword, identifier, and so on, incorrectly. Going back and correcting its error can take three or four times the amount of time it would've taken to type in the text manually.
At least it's possible that it would not be enabled by default.
That's not surprising.
on
Vim 6.4 Released
·
· Score: 2, Insightful
I mean, it is the 6.4 release. Many projects typically do not add features after a major release. It's the minor point releases that focus on fixing bugs. So in this case it's the fourth round of bugfixes.
I saw it on the OpenSolaris site back on October 14th. I read it then, and now a few days later I can comment on it here.
I just want to say thanks.
on
Vim 6.4 Released
·
· Score: 5, Insightful
I want to say thanks to all of the VIM developers who have helped create such an amazing piece of software. Indeed, I don't think we can even begin to consider how much other software has been written by developers using VIM.
It mainly has to do with historic reasons. Until a few months ago, Solaris was a proprietary, closed source system running only on Sun's SPARC-based hardware, and on some x86-based systems (albeit with fairly poor hardware support). Sun had very little reason to perform ports to other platforms, and since the source code was not available to others under an open source license, such ports were not performed by a third party.
But we're seeing that change now. There's a PowerPC port in the works, for instance.
Indeed, if that is the case, then it is no surprise that the FreeBSD developers have not dedicated resources towards performing a port, even if it isn't integrated within the core FreeBSD codebase. They're known for engineering a solid operating system, and such shenanigans as you describe do not lead to well implemented designs.
The article is purely technical, and does not focus on topics (like licensing) that often lead to flamewars and other disagreement. Indeed, it is written in such a way that only the technical issues are discussed, rather than ideological issues.
Indeed, the professionalism of the Solaris and FreeBSD developers can serve as a model for the entire open source community. Now, it's not surprising that the Solaris developers project a very professional image, considering their business roots. Many of the FreeBSD developers are professional consultants, who know how to properly deal with clients.
Indeed, the instance of the KOffice developer who went around publically insulting a long time KDE and KOffice user is a perfect example of the sort of unprofessional behaviour that should be avoided.
One thing you do not see from the Solaris and FreeBSD developers is insults directed at their users, clients and customers. There may be internal squabbling between the developers, but as true professionals they will keep this between themselves.
If they were going from the specs then there is no reason for them to have had to resort to using a GPL'ed implementation as a reference, as the parent poster was suggesting they did.
I know plenty about ReiserFS. Had you read my post you would have understood that the problem is not with the concepts and algorithms of ReiserFS. The problems are not with the idea nor the Linux implementation, but instead with trying to tack the Linux implementation onto the FreeBSD kernel.
You cannot take code from two radically different projects, stick them together as is being proposed by others, and then have it magically work. You could run into issues with the FreeBSD file buffering subsystem, for instance. Code that may work perfectly under Linux may very well fail under FreeBSD. And you can't have filesystems failing.
It's a problem of merging two distinct and different codebases, not a problem with ReiserFS itself.
Slashdot Mirror
Indeed, we may be seeing Perl's reign in certain areas coming to an end. Java, PHP and Ruby have taken over when it comes to developing web apps. The regular expression support of languages like Python, Ruby, and even C# trump that of Perl.
While Perl was once a great innovator, today it is increasingly becoming a thing of the past. What were once great benefits of Perl have become standard features in many other languages. And unfortunately, Perl has failed to stay a step ahead of the game. The Perl 6 delays have not helped it at all. Indeed, while Perl will surely be used for decades to come, it is quite rapidly losing its place as the glue of the open source world. Python and Ruby are quickly taking over, if they haven't already done so.
It's not an issue whether we all want Larry to take over Perl again. It's more a matter of whether or not he wishes to resume such leadership. And judging by his past statements, he is not interested in that. He wants Perl 6 to be a community effort, as it has been.
As it says on the Perl 6 home page:
"Perl 5 was my rewrite of Perl. I want Perl 6 to be the community's rewrite of Perl and of the community." - Larry Wall, State of the Onion speech, TPC4
Indeed, those who resort to insults during debates are most likely in the wrong. It's one of those things we see time and time again. One such example could very well be this instance of Jack Thompson debating a 14-year-old child. Another notable example is that of the KOffice developer who resorted to insulting a long time KDE and KOffice user during a discussion of the future of the KOffice project.
I'm over here on the other side of the Atlantic, so perhaps that's why I haven't heard of this Jack Thompson fellow. Who exactly is he, and why should I care what he has to say?
Indeed. That's why RedHat is a distribution to be avoided. I don't trust their support to be worthwhile when they press ext3 as an enterprise-grade filesystem. I'll stick with distributions such as Debian, which do offer support for the filesystems which are used for intensive tasks.
No, I don't smoke cigarettes, thank you.
I care what he or she thinks. I care what you think, too. But when you think that nobody cares whatever he or she thinks, then I know you are wrong. Because I care.
Even if it is a partial list, XFS and JFS are two of the major Linux filesystems. It'd be like leaving out FAT32 support out of a list of filesystems that Windows supports. They're just too major to be left out.
Actually, I have several children. They're all adults now, too. And to top it off, I was correct. That's probably why the KOffice developer had to resort to insults, rather than the truth, in our discussion.
Why use the half-assed less when you have have the real VIM? The memory requirement differences between the two are basically irrelevant these days, and speedwise they're indistinguishable.
... but it is also a fantastic pager. Using it instead of less or more to quickly scan over source code is a blessing! Indeed, you get the syntax highlighting of a GUI editor, but without the overhead. You can view files instantly from the command line, and they're very nicely formatted.
Gregory John Casamento is not a stupid man by any means. Indeed, he is responsible for some amazing work. Take Gorm, for example. It brings the cutting edge development techniques of NeXT to Linux and other non-NeXT/non-Apple systems.
If I was wrong then it would have been more than acceptable for that KOffice developer to point out that I was incorrect. However, I was not. I was completely right. That's why he had to resort to insults in his discussion with me. Since I was wielding the truth, he had to rely on childish namecalling.
Regardless, it was a very unprofessional act to perform. At least there are others on the open source community who do set a good example for the other developers.
Perhaps the use VIM for the same reason you seem to enjoy using NeXTSTEP-styled systems: they just find it works for them. It allows them to be as productive as they can be.
Indeed, finding out a "nice" way of doing it is essential. Nothing is more of a hassle than having Eclipse or the Visual Studio IDE autocomplete a keyword, identifier, and so on, incorrectly. Going back and correcting its error can take three or four times the amount of time it would've taken to type in the text manually.
At least it's possible that it would not be enabled by default.
I mean, it is the 6.4 release. Many projects typically do not add features after a major release. It's the minor point releases that focus on fixing bugs. So in this case it's the fourth round of bugfixes.
I saw it on the OpenSolaris site back on October 14th. I read it then, and now a few days later I can comment on it here.
I want to say thanks to all of the VIM developers who have helped create such an amazing piece of software. Indeed, I don't think we can even begin to consider how much other software has been written by developers using VIM.
It mainly has to do with historic reasons. Until a few months ago, Solaris was a proprietary, closed source system running only on Sun's SPARC-based hardware, and on some x86-based systems (albeit with fairly poor hardware support). Sun had very little reason to perform ports to other platforms, and since the source code was not available to others under an open source license, such ports were not performed by a third party.
But we're seeing that change now. There's a PowerPC port in the works, for instance.
Indeed, if that is the case, then it is no surprise that the FreeBSD developers have not dedicated resources towards performing a port, even if it isn't integrated within the core FreeBSD codebase. They're known for engineering a solid operating system, and such shenanigans as you describe do not lead to well implemented designs.
The article is purely technical, and does not focus on topics (like licensing) that often lead to flamewars and other disagreement. Indeed, it is written in such a way that only the technical issues are discussed, rather than ideological issues.
Indeed, the professionalism of the Solaris and FreeBSD developers can serve as a model for the entire open source community. Now, it's not surprising that the Solaris developers project a very professional image, considering their business roots. Many of the FreeBSD developers are professional consultants, who know how to properly deal with clients.
Indeed, the instance of the KOffice developer who went around publically insulting a long time KDE and KOffice user is a perfect example of the sort of unprofessional behaviour that should be avoided.
One thing you do not see from the Solaris and FreeBSD developers is insults directed at their users, clients and customers. There may be internal squabbling between the developers, but as true professionals they will keep this between themselves.
If they were going from the specs then there is no reason for them to have had to resort to using a GPL'ed implementation as a reference, as the parent poster was suggesting they did.
There was no mention of XFS or JFS for Linux. Indeed, for certain server applications those filesystems prove to be very effective.
I know plenty about ReiserFS. Had you read my post you would have understood that the problem is not with the concepts and algorithms of ReiserFS. The problems are not with the idea nor the Linux implementation, but instead with trying to tack the Linux implementation onto the FreeBSD kernel.
You cannot take code from two radically different projects, stick them together as is being proposed by others, and then have it magically work. You could run into issues with the FreeBSD file buffering subsystem, for instance. Code that may work perfectly under Linux may very well fail under FreeBSD. And you can't have filesystems failing.
It's a problem of merging two distinct and different codebases, not a problem with ReiserFS itself.