Pre-merger they would be more likely to push winamp. Post-merger either winamp gets buried, or, more likely winamp picks up SDMI "features", streaming advertising, etc. Then winamp loses mp3 format capabilities because of "piracy concerns". No reason to kill the program when its user base can be pushed into SDMI...
With all this talk about who owns what wires, what percent of the press is owned by whom, how these outlets will possibly get control of such and such content, everyone seems to have forgotten the reality of why these mergers take place.
While it's easy to see that Company A has such and such a share of some market and Company B has such and such a share of some other related market that company C (=A+B) will have both shares and will be bigger, etc., so company C is "more powerful" (translated "probably going to make more money") companies generally (especially big companies like these) don't undertake these sorts of mergers unless there is a specific reason.
Such reasons are usually of the form "If we do not buy that company then their new product will erode our dominance in market X", "our other competitor is beating us by using their Y technology, we'll buy this third company and get the same technology", "we need to sell product Z to strengthen our core business, and their customer base is the perfect market," etc.
Consider this: Time Warner owns immense amounts of copyrighted content -- music, movies, literature, etc. They are one of the big players in this "lock down the MP3's/mpegs/online distribution"-shove-SDMI-down-your-throat "piracy" (bootlegging?) battle. Nobody in their right mind is going to use SDMI over a free mp3 (or mp3-like) format. Why allow the robber-barons of the content kingdom to extend their outmoded royalty/distribution monopoly? Time/Warner realizes this, and they realize that the only way to keep those $ flowing is to get SDMI (or something very similar) into the hands of the mass consumer. How does one do that? Find a large body of mass consumers and shove it in their faces. Make it easier than the alternative.
The biggest body of captive mass consumers sheepish/idiotic enough to accept that SDMI is an easy way to get their music online is the body of AOL subscribers. While partnering with AOL may do the job, buying them out ensures control over distribution in their medium, and will ensure that no non-SDMI system will appear as an alternative to an AOL subscriber. When the base of 20 million (?) AOLers is locked into SDMI then SDMI becomes a de facto standard. A few years down the road and ideally (for T/W) this will be the case for video content as well. And, the perfect target audience has already been recruited by AOL. Hell, now that they own Netscape, and M$ will play ball they can just put SDMI in the browsers too. "Boss, it's a win-win".
I doubt many on this forum believe that the US is the source for full-strength encryption. As a matter of fact, much of the good Open crypto comes from outside the US, because the writers don't want to lose their code to some ludicrous US export regs. I believe the tide turned some time ago and would wager (though it's hard to quantify this) that more strong crypto is written outside the US than inside. That may sound ludicrously US-centric, but some years ago the US was the source for a number of the major crypto algorithms, implementations, and crypto-$$$.
If the US were to drop their crypto regulations altogether many projects would benefit -- distributions could include crypto without having to worry about whether the end-user is in the US or not, OpenBSD could ship a simpler "here's the crypto" distribution [well, I think we're all still waiting for the damn RSA patent to expire so we can get on without jumping through those hoops as well], and a large body of American programmers could actually contribute some code and peer-reviewing to the international crypto codebase. I realize to a degree this is an oversimplification (there are other countries with bad crypto policies as well, so removing USA's regulations would not be a panacea), but the world situation definitely improves without these sorts of silly barriers.
I suppose a centralized procmail filter database would be feasible... hmm....
I'll go you one better (because if you're procmailing, the spammer has already wasted your resources) and point you to the MAPS Realtime BlackHole List.
have you ever tried to get something other than windows to work with pppoe?
Yes. With some elbow grease it works under Linux and OpenBSD. Probably works under FreeBSD and NetBSD also. But, it's gonna take a bit of the old RTFM.
Re:BoneFlower, did you read the Moderator Guidelin
on
China Banning Win2k
·
· Score: 2
"Inappropriate" is undefined and used intentionally vaguely in your post. Information exists outside/. in case you weren't aware -- which is why posts which present insight (correct or incorrect) from outside the 1-click-from-slashdot radius may be moderated up.
The intent of the moderation system is not to evaluate the factual correctness of posts (given that most posters can't do this for themselves, and moderators are posters,...). The purpose of moderation is to rank posts via scores so that the more interesting, useful, funny, and informative posts have high scores, while the crap, flames, trolls, etc., have lower scores. A post [ such as the one to which I am currently replying ] can be factually WRONG and deserve a high score on the basis of these criteria (not that your post deserves a high score, but it does not deserve to be down-moderated, because it is "interesting" although completely boneheaded). If the post is off-topic then it should be moderated so. If the post is factually incorrect (or correct for that matter) but interesting or insightful it should be moderated so. How many times do people have to tell you to read the moderator guidelines before you click the friggin link?
As you have said, you function for quite a while (5 or 6 years i think you said) without knowing the full syntax of the language...therefore YOU CANNOT READ OTHER PEOPLES PERL CODE until such 5 or 6 years learning and memorzing every possible dorky way (many of them sparsely documented, two lines in "Programming Perl" on page 238 perhaps and nowhere else) of doing something is complete.
If you'll check what I wrote you'll find I didn't say I was still learning Perl syntax after 5 or 6 years (damn, man, I'm not so stubborn not to have given up on the language by then if that were true!). The syntax takes very little time at all. Familiarity with the functions and library suite don't really take all that long. Probably after a year I'd never seen any new functions, and very few new things on CPAN of use to me (well that might be stretching it a bit, since CPAN does keep improving to this day).
The things that one learns after 5 or 6 years with Perl are very advanced techniques -- an occasional idiom, advanced data structure manipulations, more and more perlguts (2 years ago I was embedding perl interpreters in C and C++ programs, and linking in libraries (including SUID PVM libraries) -- ever see a C++ module which instantiates a Perl interpreter which embeds more C modules? fun stuff), distributed objects (think Perl CORBA), etc.
I can't remember having that much trouble with Perl syntax, to tell the truth. Maybe it's harder for some than others. I have seen garbage code by junior programmers in all languages. And gurus are gurus. The nice ones use comments that say things like "deep wizardry. do not touch." and mean it. When you spend enough time to see why then you really appreciate their handiwork.
I don't really spend much time looking up syntax for Java applications. Java's syntax *is* simple. But the language is contorted. Additionally, Perl actually is portable where Java has purported to be (this is the subject of too many holy wars for me to want to rehash). I stopped using Java, not because the language is bad, but because the current implementations are horrible, and Sun's behavior over the past 2 years has been unforgiveable.
Then use them where they are necessary. Do you see anywhere that I said that one should use Perl where it is not warranted. By all means, the people one hires should be as capable and flexible as possible. One think that you seem to assume is that Perl programmers are only Perl programmers. Why, I'm not certain. I also program in C, C++, Java, lisp (and scheme), ml, various flavors of assembly, awk, a number of scripting languages, even VB and VC++, and more. Most of the good Perl programmers I know are generally good programmers and can say the same. They also cost more than a 1-language programmer. I personally have not learned Python because I know Perl, they fill some of the same niches, and my time is valuable. One day I may learn Python beyond the trivial knowledge I currently have of it and hopefully I will find it as easy to learn as Perl.
The reason you haven't relied on anecdotal evidence for your arguments is that you haven't relied on evidence for your arguments. You actually haven't relied much on reason either, so the term "argument" is debatable. Your best tactic so far has been to try to appear to misconstrue the words of others so that you can argue against what you choose for them to have said.
The fact of the matter is that I am in no better position to say that Perl is easier to learn than Python than you are in a better position to say that Python is easier to learn than Perl.
My evidence, however, is anecdotal in only the trivial sense that all evidence presented in this forum is anecdotal since it is accounted by someone else. My experience with Perl and its use far exceeds your 31337 K1dz implications. Not only do I make very good money as a developer, have years of experience with professional Perl development, but I have also taught Perl for a living, and have wide experience with the experiences of others who have learned and used Perl.
And I still stand beside the claim that Perl is easy to learn and powerful to use. Presumably so is Python. Wonderful. At least you being a rabid Python user ensures that I won't ever have to deal with your sorry ass on a project.
I'm not going to spell out the list of all the people in the past I have seen learn and use Perl, their backgrounds, whether they maintained code written by what types of programmers, which books they might have read, whether they used Cyrillic as their alphabet of choice, etc., to make you understand what I have been trying to say in this now-tired-ass-thread:
- I have seen a wide range of perl users, programmers, and students, and my opinion (having at one point learned Perl myself, and having dealt with Perl in a number of different capacities) is that Perl is easy to learn, is very powerful, and very flexible. - there is a big difference between hacking up some scripts and seriously using/maintaining/designing-in Perl (I even spent about 20 minutes somewhere in this thread pointing that out) - Perl is not a panacea. Perl has its place and its uses. There is no panacea. - It takes work to learn. There is no welfare state in technical education: you either put in the hours and learn (this is true for everything -- the fact that some languages are easier to cut-and-paste programs than others does not imply that the cut-and-paster is a programmer by any stretch of the imagination). It is my opinion that most of the Perl naysayers in this thread have been just such cut-and-paste "programmers".
Hardly. Read the comment. Insert Python where you see Perl if you can't figure it out. For any large project you are "locked in" to some degree to certain technologies for various components. you have to make a commitment to languages somewhere -- and hopefully the choices are educated. For a large project you will likely get locked in to a very small number of languages. If Perl is one of them then you will need good Perl programmers.
My claim is that since I have had a lot of experience on a lot of projects for a lot of people doing a lot of Perl programming -- having seen an uncountable number of Perl programmers from newbies to gurus -- that your claim is unsubstantiated. Perl is actually empirically one of the easier languages to learn, and one of the easiest languages in which to learn how to write powerful programs. I've seen kids, PHBs, Wall Street traders, carpenters, arrogant C programmers, etc., learn Perl without complaint.
First, a company with non-trivial in-house software development needs should be prepared to get competent coders and competent designers, which may be found to varying degrees within the same employee(s). I'm not implying that a company must hire a QA team, certified software engineers, and programmers with Ph.D's [ well, you wouldn't find many of those anyway, but that's another discussion entirely ], but before hiring programming resources the company should have a clear idea of their needs and directions before spending their money.
Perl is an easy language to use. Any given 5-person+ company probably has Perl-capable employees (the comment about Perl books being on Wall Street desks has a lot of truth to it because even non-technical people find Perl incredibly useful). To increase efficiency in the company, find places where math and paperwork is being needlessly done by hand, apply some Perl, and a limited amount of efficiency increase will probably arise. Hiring a programmer to do Perl will probably result in more efficiency increases. Having little idea of what a company needs and hiring a cadre of Perl programmers (or any language) is probably a recipe for disaster.
Given a company that knows where it wants to go technically, which has or hires people which actually design the software to fulfill those needs and has experienced programmers which write the software in Perl (the language under discussion, but this holds true for most languages):
the code written will be optimized for the criteria important for the company
the code written will take advantage of advanced features of the language to provide flexibility, and to provide the optimizations desired (modularity, sophisticated regular expressions, XS access to shared objects, persistence, network transparency)
the code written may implement non-trivial algorithmic approaches to solve optimization problems
the code may contain sophisticated data structures
There are reasons a company chooses Perl as an implementation language in a large project (such as the hypothetical one being described), and they hire experienced programmers to execute it [hopefully]. The guy arguing that he gets confused about the use of greater-than-signs in while loops should never be allowed to touch the code for this project, because he can only screw it up. This is assuming that (as it should be) the code is as well-documented and cleanly written as possible.
Yes, the company is now "locked in" to hiring good Perl programmers to maintain this code. If it is feared that there is a problem with obtaining these people (over and above the problems we all have obtaining good people in this market anyway) then they should use a different language which has more available programmers. The fact that the company is "locked in" to having to get good programmers is nothing unique to Perl -- it is a hallmark of a good system which, if it was truly needed, is generating some substantial benefit for its owners.
If the company did not need this quality product then they shouldn't pay for it. I happen to get paid for being one of the people that designs and helps write such products, and a number of these have been in Perl (and because of this more of them probably will be in the future). The companies pay good money for my work (as well as all the other people I work with) because they want sophisticated code that solves difficult problems. I am not trying to toot my own horn -- there are hundreds of thousands of people doing the same thing I am for the same reasons.
The bottom line is that companies need to evaluate their needs well before throwing money at technical problems. This is independent of a good language like Perl.
And Spanish uses those weird little upside down punctuation marks, and what's with those brackety quote things? And Russian, what's with that oddball alphabet? When I look at an R I expect it to face the other way!
If you don't know the language, either learn it, or don't expect to know it. Perl has a different syntax than [ pick your favorite non-Perl language ] that's why it's Perl and not some other language. If you read the first couple of chapters of "Learning Perl" (much less any of the excellent and more advanced O'Reilly books on the subject, on the front of which you might have even seen Tom's name were you not too busy trying to figure out why those idiots left the "a" out of "Pearl") you'll get a perfectly good introduction to the operators, syntax, types, and some of the basic idioms of perl programming.
Perl is non-trivial, easy to learn, and powerful. Since TMTOWTDI you can learn a subset of the language and be perfectly effective forever, but you can also continue learning more about the language and become a better programmer. I have been programming in Perl for 5-6 years now and am still learning new things (and my programs become more robust and more portable). There's no magic "Perl pill" to swallow, there's no book that will teach you Perl in 21 days or 24 hours, but you can be programming usefully in Perl in 24 hours without much of a problem.
It seems to me that you are an outsider/newbie to Perl who was dismayed at the differences between Perl and your current favorite languages. I don't know much about python (and yes I've actually written some programs in it), and have never really gotten keen on it and could probably post a comment like yours about Python in a similar forum, but I know that there are a lot of python users who write good programs (Zope being one of my favorites), so there's no point in me ignorantly knocking an apparently good product.
People seem to think that they have an inalienable right to sit down in front of a program written in a language with which they are vaguely familiar and begin hacking someone else's code - and bitch when the language is not trivial enough to do that. While I am all in favor of languages with simple syntax (C, Python), or languages for morons (VB comes to mind), when I choose to code a project in Perl I don't expect some Perl newbie to maintain my code later -- because I know Perl well and I use the advanced features of the language for their power. If you don't want to take the time to learn Perl then go program in any of the zillion other languages available; but don't claim to be "just another perl hacker" or expect to be able to maintain good Perl code.
I'm with you on this one. This is like a bad Charleton Heston soliloquy from the 4th or 5th Planet of the Apes sequel.
I particularly like:
"We need recyclable technologies...", oh, so that would be: "...that is what our culture will be like, at its heart, in its bones, in its organs. A gizmo culture.... Since gizmos are easily outmoded and inherently impermanent, their most graceful form is as disposable consumer technology."
hmmm... or how about: "Artists, dont be afraid of commercialization. The sovereign remedy for commercialization is not for artists to hide from commerce." because, well, of course, "The channels exist now to give creativity away, at no cost, to millions. "
And to tell you the truth, those are the coherent parts of this manifesto.
When I meet a guy talking like this in a bar he's generally about to get thrown out by the barkeep. On the street he's usually about to hit someone up for $, or try to give away some brightly colored books about a new god noone can pronounce. Maybe I should stop mincing words: c-r-a-c-k-p-o-t.
And when mozilla allows Netscape 5.0 (I work with the code daily -- don't tell me it's not coming because I know how good it is), and sites begin actually following the W3C standards and IE won't render properly you know what?
We'll forget that you were high and mighty about using Microsoft garbageware, and welcome you into the fold as a user of OSS software. Of course, you're free to stick with IE if you'd like, but it won't be our fault when you begin getting locked out of sites. Choice is important. I respect that.
The point (other than that this story is crap and shouldn't be on/. anyway) is that an incredibly high percentage of sights are viewable on all browsers -- it is the rare sight which is actually not usable due to browser or platform. To exclude a priori a large set of browsers is stupid (and reeks of gross mismanagement or being in bed with the monopolists). Eventually the shoe will be on another foot and the MS/IE arguments won't hold water for anyone else either.
Here's a correlation-buster for ya: Wall Street. Investment banks, hedge funds, brokerage houses. Trading desks. Running on Solaris systems. Browser: Netscape.
I worked there. I talked to people. Yes there are some NT shops, but even the travelling techs from Bloomberg/Bridge will tell you that the serious shops aren't on Windows.
I'll (once again) relay one of the major problems with Sun's recent (i.e., since late 1998) Java path: client-side portability.
When Sun announces in a press barrage in 1998 how they are dedicated to bringing Java WORA to all the major platforms, with an emphasis on Linux, repeating this emphasis every 4-6 months, but keeping platforms incompatible and releases out of sync it introduces measurable delays in design, development, testing, and deployment of Java-based client-side products.
Abandonment of Java as a platform, even for very competent developers, designers, QA, and administrators (don't forget that part of the cost of developing large projects is the cost of setting up development/QA platforms), is non-trivial and results in lost time.
Server-side Java's time may be here, but realistically, there have been and continue to be better server-side solutions. Once you remove the client interface it becomes simple to find useful implementation languages -- the majority of which are faster wrt to both runtime and development time than Java.
About 15 years ago a friend and I (while in grade school) called the Royal Greenwich Observatory (from Kentucky) to set our watches by the official observatory clock -- so we could be exactly on GMT (ah the days before I knew about NTP!). We ended up talking to the janitor there (it was about 3am there) who finally (after some pleading) shambled off to take a look at the clock, shambled back and told me, "it's about 3:15".
I don't know where you French get off with this UTC time, but over here we all know that GMT is the only real time.:-)
The reason there is so much Java bashing on/. is that Java's client side has not been WORA yet, Sun's PR is awful and has systematically pissed off and alienated much of the Open Source contingent -- which is the bulk of the/. contingent -- particularly recently but steadily over the past year, and in spite of all this bashing there seem to be an endless stream of Sundrones willing to spew the same "but it really is WORA (so long as you're on Win32 or Solaris), and it's not so slow (if you've got a quad processor Xeon or a quad Ultra2), and Sun really isn't out to screw everyone to the wall just to make a $...".
I myself have posted repeatedly on Java issues. My companies have lost months due to Sun and its dicking around with Java. Fortunately we had the insight to get off the Java wagon a few months ago before things got really stupid. For those who can get Java to work for them: great. For those trying to make Java work for them: good luck. For those considering Java: spend your time more wisely and find an alternative -- if you don't have reason to be sorry now I can guarantee you Sun will give you reason within the next few months.
Slashdot Mirror
Pre-merger they would be more likely to push winamp. Post-merger either winamp gets buried, or, more likely winamp picks up SDMI "features", streaming advertising, etc. Then winamp loses mp3 format capabilities because of "piracy concerns". No reason to kill the program when its user base can be pushed into SDMI...
While it's easy to see that Company A has such and such a share of some market and Company B has such and such a share of some other related market that company C (=A+B) will have both shares and will be bigger, etc., so company C is "more powerful" (translated "probably going to make more money") companies generally (especially big companies like these) don't undertake these sorts of mergers unless there is a specific reason.
Such reasons are usually of the form "If we do not buy that company then their new product will erode our dominance in market X", "our other competitor is beating us by using their Y technology, we'll buy this third company and get the same technology", "we need to sell product Z to strengthen our core business, and their customer base is the perfect market," etc.
Consider this: Time Warner owns immense amounts of copyrighted content -- music, movies, literature, etc. They are one of the big players in this "lock down the MP3's/mpegs/online distribution"-shove-SDMI-down-your-throat "piracy" (bootlegging?) battle. Nobody in their right mind is going to use SDMI over a free mp3 (or mp3-like) format. Why allow the robber-barons of the content kingdom to extend their outmoded royalty/distribution monopoly? Time/Warner realizes this, and they realize that the only way to keep those $ flowing is to get SDMI (or something very similar) into the hands of the mass consumer. How does one do that? Find a large body of mass consumers and shove it in their faces. Make it easier than the alternative.
The biggest body of captive mass consumers sheepish/idiotic enough to accept that SDMI is an easy way to get their music online is the body of AOL subscribers. While partnering with AOL may do the job, buying them out ensures control over distribution in their medium, and will ensure that no non-SDMI system will appear as an alternative to an AOL subscriber. When the base of 20 million (?) AOLers is locked into SDMI then SDMI becomes a de facto standard. A few years down the road and ideally (for T/W) this will be the case for video content as well. And, the perfect target audience has already been recruited by AOL. Hell, now that they own Netscape, and M$ will play ball they can just put SDMI in the browsers too. "Boss, it's a win-win".
If the US were to drop their crypto regulations altogether many projects would benefit -- distributions could include crypto without having to worry about whether the end-user is in the US or not, OpenBSD could ship a simpler "here's the crypto" distribution [well, I think we're all still waiting for the damn RSA patent to expire so we can get on without jumping through those hoops as well], and a large body of American programmers could actually contribute some code and peer-reviewing to the international crypto codebase. I realize to a degree this is an oversimplification (there are other countries with bad crypto policies as well, so removing USA's regulations would not be a panacea), but the world situation definitely improves without these sorts of silly barriers.
I'll go you one better (because if you're procmailing, the spammer has already wasted your resources) and point you to the MAPS Realtime BlackHole List.
Yes. With some elbow grease it works under Linux and OpenBSD. Probably works under FreeBSD and NetBSD also. But, it's gonna take a bit of the old RTFM.
The intent of the moderation system is not to evaluate the factual correctness of posts (given that most posters can't do this for themselves, and moderators are posters, ...). The purpose of moderation is to rank posts via scores so that the more interesting, useful, funny, and informative posts have high scores, while the crap, flames, trolls, etc., have lower scores. A post [ such as the one to which I am currently replying ] can be factually WRONG and deserve a high score on the basis of these criteria (not that your post deserves a high score, but it does not deserve to be down-moderated, because it is "interesting" although completely boneheaded). If the post is off-topic then it should be moderated so. If the post is factually incorrect (or correct for that matter) but interesting or insightful it should be moderated so. How many times do people have to tell you to read the moderator guidelines before you click the friggin link?
If you'll check what I wrote you'll find I didn't say I was still learning Perl syntax after 5 or 6 years (damn, man, I'm not so stubborn not to have given up on the language by then if that were true!). The syntax takes very little time at all. Familiarity with the functions and library suite don't really take all that long. Probably after a year I'd never seen any new functions, and very few new things on CPAN of use to me (well that might be stretching it a bit, since CPAN does keep improving to this day).
The things that one learns after 5 or 6 years with Perl are very advanced techniques -- an occasional idiom, advanced data structure manipulations, more and more perlguts (2 years ago I was embedding perl interpreters in C and C++ programs, and linking in libraries (including SUID PVM libraries) -- ever see a C++ module which instantiates a Perl interpreter which embeds more C modules? fun stuff), distributed objects (think Perl CORBA), etc.
I can't remember having that much trouble with Perl syntax, to tell the truth. Maybe it's harder for some than others. I have seen garbage code by junior programmers in all languages. And gurus are gurus. The nice ones use comments that say things like "deep wizardry. do not touch." and mean it. When you spend enough time to see why then you really appreciate their handiwork.
I don't really spend much time looking up syntax for Java applications. Java's syntax *is* simple. But the language is contorted. Additionally, Perl actually is portable where Java has purported to be (this is the subject of too many holy wars for me to want to rehash). I stopped using Java, not because the language is bad, but because the current implementations are horrible, and Sun's behavior over the past 2 years has been unforgiveable.
YMMV of course.
The fact of the matter is that I am in no better position to say that Perl is easier to learn than Python than you are in a better position to say that Python is easier to learn than Perl.
My evidence, however, is anecdotal in only the trivial sense that all evidence presented in this forum is anecdotal since it is accounted by someone else. My experience with Perl and its use far exceeds your 31337 K1dz implications. Not only do I make very good money as a developer, have years of experience with professional Perl development, but I have also taught Perl for a living, and have wide experience with the experiences of others who have learned and used Perl.
And I still stand beside the claim that Perl is easy to learn and powerful to use. Presumably so is Python. Wonderful. At least you being a rabid Python user ensures that I won't ever have to deal with your sorry ass on a project.
I'm not going to spell out the list of all the people in the past I have seen learn and use Perl, their backgrounds, whether they maintained code written by what types of programmers, which books they might have read, whether they used Cyrillic as their alphabet of choice, etc., to make you understand what I have been trying to say in this now-tired-ass-thread:
- I have seen a wide range of perl users, programmers, and students, and my opinion (having at one point learned Perl myself, and having dealt with Perl in a number of different capacities) is that Perl is easy to learn, is very powerful, and very flexible.
- there is a big difference between hacking up some scripts and seriously using/maintaining/designing-in Perl (I even spent about 20 minutes somewhere in this thread pointing that out)
- Perl is not a panacea. Perl has its place and its uses. There is no panacea.
- It takes work to learn. There is no welfare state in technical education: you either put in the hours and learn (this is true for everything -- the fact that some languages are easier to cut-and-paste programs than others does not imply that the cut-and-paster is a programmer by any stretch of the imagination). It is my opinion that most of the Perl naysayers in this thread have been just such cut-and-paste "programmers".
I'm sorry that you don't understand this.
Perl is an easy language to use. Any given 5-person+ company probably has Perl-capable employees (the comment about Perl books being on Wall Street desks has a lot of truth to it because even non-technical people find Perl incredibly useful). To increase efficiency in the company, find places where math and paperwork is being needlessly done by hand, apply some Perl, and a limited amount of efficiency increase will probably arise. Hiring a programmer to do Perl will probably result in more efficiency increases. Having little idea of what a company needs and hiring a cadre of Perl programmers (or any language) is probably a recipe for disaster.
Given a company that knows where it wants to go technically, which has or hires people which actually design the software to fulfill those needs and has experienced programmers which write the software in Perl (the language under discussion, but this holds true for most languages):
There are reasons a company chooses Perl as an implementation language in a large project (such as the hypothetical one being described), and they hire experienced programmers to execute it [hopefully]. The guy arguing that he gets confused about the use of greater-than-signs in while loops should never be allowed to touch the code for this project, because he can only screw it up. This is assuming that (as it should be) the code is as well-documented and cleanly written as possible.
Yes, the company is now "locked in" to hiring good Perl programmers to maintain this code. If it is feared that there is a problem with obtaining these people (over and above the problems we all have obtaining good people in this market anyway) then they should use a different language which has more available programmers. The fact that the company is "locked in" to having to get good programmers is nothing unique to Perl -- it is a hallmark of a good system which, if it was truly needed, is generating some substantial benefit for its owners.
If the company did not need this quality product then they shouldn't pay for it. I happen to get paid for being one of the people that designs and helps write such products, and a number of these have been in Perl (and because of this more of them probably will be in the future). The companies pay good money for my work (as well as all the other people I work with) because they want sophisticated code that solves difficult problems. I am not trying to toot my own horn -- there are hundreds of thousands of people doing the same thing I am for the same reasons.
The bottom line is that companies need to evaluate their needs well before throwing money at technical problems. This is independent of a good language like Perl.
If you don't know the language, either learn it, or don't expect to know it. Perl has a different syntax than [ pick your favorite non-Perl language ] that's why it's Perl and not some other language. If you read the first couple of chapters of "Learning Perl" (much less any of the excellent and more advanced O'Reilly books on the subject, on the front of which you might have even seen Tom's name were you not too busy trying to figure out why those idiots left the "a" out of "Pearl") you'll get a perfectly good introduction to the operators, syntax, types, and some of the basic idioms of perl programming.
Perl is non-trivial, easy to learn, and powerful. Since TMTOWTDI you can learn a subset of the language and be perfectly effective forever, but you can also continue learning more about the language and become a better programmer. I have been programming in Perl for 5-6 years now and am still learning new things (and my programs become more robust and more portable). There's no magic "Perl pill" to swallow, there's no book that will teach you Perl in 21 days or 24 hours, but you can be programming usefully in Perl in 24 hours without much of a problem.
It seems to me that you are an outsider/newbie to Perl who was dismayed at the differences between Perl and your current favorite languages. I don't know much about python (and yes I've actually written some programs in it), and have never really gotten keen on it and could probably post a comment like yours about Python in a similar forum, but I know that there are a lot of python users who write good programs (Zope being one of my favorites), so there's no point in me ignorantly knocking an apparently good product.
So why are you?
People seem to think that they have an inalienable right to sit down in front of a program written in a language with which they are vaguely familiar and begin hacking someone else's code - and bitch when the language is not trivial enough to do that. While I am all in favor of languages with simple syntax (C, Python), or languages for morons (VB comes to mind), when I choose to code a project in Perl I don't expect some Perl newbie to maintain my code later -- because I know Perl well and I use the advanced features of the language for their power. If you don't want to take the time to learn Perl then go program in any of the zillion other languages available; but don't claim to be "just another perl hacker" or expect to be able to maintain good Perl code.
I particularly like:
"We need recyclable technologies...", oh, so that would be: "...that is what our culture will be like, at its heart, in its bones, in its organs. A gizmo culture. ... Since gizmos are easily outmoded and inherently impermanent, their most graceful form is as disposable consumer technology."
hmmm... or how about: "Artists, dont be afraid of commercialization. The sovereign remedy for commercialization is not for artists to hide from commerce." because, well, of course, "The channels exist now to give creativity away, at no cost, to millions. "
And to tell you the truth, those are the coherent parts of this manifesto.
When I meet a guy talking like this in a bar he's generally about to get thrown out by the barkeep. On the street he's usually about to hit someone up for $, or try to give away some brightly colored books about a new god noone can pronounce. Maybe I should stop mincing words: c-r-a-c-k-p-o-t.
I second that emotion. p?
Hey, thanks Microsoft! (never thought I'd say that!)
We'll forget that you were high and mighty about using Microsoft garbageware, and welcome you into the fold as a user of OSS software. Of course, you're free to stick with IE if you'd like, but it won't be our fault when you begin getting locked out of sites. Choice is important. I respect that.
The point (other than that this story is crap and shouldn't be on /. anyway) is that an incredibly high percentage of sights are viewable on all browsers -- it is the rare sight which is actually not usable due to browser or platform. To exclude a priori a large set of browsers is stupid (and reeks of gross mismanagement or being in bed with the monopolists). Eventually the shoe will be on another foot and the MS/IE arguments won't hold water for anyone else either.
Here's a correlation-buster for ya: Wall Street. Investment banks, hedge funds, brokerage houses. Trading desks. Running on Solaris systems. Browser: Netscape.
I worked there. I talked to people. Yes there are some NT shops, but even the travelling techs from Bloomberg/Bridge will tell you that the serious shops aren't on Windows.
Moral: big money uses Netscape.
I'll (once again) relay one of the major problems with Sun's recent (i.e., since late 1998) Java path: client-side portability.
When Sun announces in a press barrage in 1998 how they are dedicated to bringing Java WORA to all the major platforms, with an emphasis on Linux, repeating this emphasis every 4-6 months, but keeping platforms incompatible and releases out of sync it introduces measurable delays in design, development, testing, and deployment of Java-based client-side products.
Abandonment of Java as a platform, even for very competent developers, designers, QA, and administrators (don't forget that part of the cost of developing large projects is the cost of setting up development/QA platforms), is non-trivial and results in lost time.
Server-side Java's time may be here, but realistically, there have been and continue to be better server-side solutions. Once you remove the client interface it becomes simple to find useful implementation languages -- the majority of which are faster wrt to both runtime and development time than Java.
Welcome to the cult of right-minded Linux users.
Down with the whining lamers!
I don't know where you French get off with this UTC time, but over here we all know that GMT is the only real time. :-)
I myself have posted repeatedly on Java issues. My companies have lost months due to Sun and its dicking around with Java. Fortunately we had the insight to get off the Java wagon a few months ago before things got really stupid. For those who can get Java to work for them: great. For those trying to make Java work for them: good luck. For those considering Java: spend your time more wisely and find an alternative -- if you don't have reason to be sorry now I can guarantee you Sun will give you reason within the next few months.
IMHO he did do something nice just for its own sake.
Give it a rest.