I don't hate Perl and I'm competent with it, but if I wanted to deal with that level of bookkeeping, I'd probably just write C and be done with it.
Whoa there, dude. Hinting at a comparison of Perl's references to C's pointers is like comparing untying your shoelace to untying the Gordian knot. In fact, comparing something so simple (with a sometimes annoying syntax) with something so confusing that many programmers never master it is so ridiculous that I know that couldn't possibly be what you meant. So what did you mean?
I am a Perl programmer and I'm quite happy with my salary, thank you. Further, I'll likely be moving to London soon and I regularly see Perl jobs at £45,000/year or more (roughly $86,000 on up). Even outside of London I regularly see Perl jobs in the UK for £30K (~ $57K) or more. Those really aren't bad salaries, particularly when you consider that they are starting salaries.
Combine that with the fact that tons of Perl jobs are currently available and many London employers are complaining that they can't find enough Perl programmers (largely due to the FUD about Perl which drives many programmers away), and competent Perl programmers can have their pick of the jobs.
Amen! I've found plenty of great people through that and I, in turn, have picked up great jobs through it. Fortunately the quality of jobs listed there is often very high and Perl programmers who really have a clue pay attention to that site, even when they're not looking for work. It's a great way to spot trends.
This is a valid question. Quite often when we have a robust low-level language generating high-level language (HLL) code, it's extremely well thought out and tested. However, many are dubious about HLL generating HLL code. I suspect (though I can't prove it) that this is because HLL -> HLL tends to be less widely used and thus is less thoroughly tested and less planned. When done properly -- particularly when covering a restricted and well-defined domain -- it can be extremely powerful. When done improperly, it's a nightmare.
Rails has a large enough user base that most common bugs have been eradicated but from what I've seen, it appears to have a problem that many fourth generation languages suffer from: if your problem fits its domain, it's a piece of cake to solve. When your problem doesn't fit its domain, it can be extremely difficult to solve (anyone who's ever worked with the 4GL Easystrieve Plus can readily testify to this). Most web-based apps, though, are simple enough that folks working with Ruby generally don't seem to have much of a problem with it. However, I've heard horror stories about people trying to use their custom model in lieu of what Rails natively supports -- though I've not had first-hand experience.
Compilers and assemblers tend to be general purpose tools which address a fairly wide problem space. HLL -> HLL tools tend to be special purpose tools and trying to get them to solve problems they aren't optimized for can be trying. In the case of Rails, one thing it excels at (CRUD apps) is a well-known problem space and Rails fits quite nicely.
So I have to say that comparing Rails to compilers or assemblers doesn't quite fit simply due to the differing focus of said tools. However, all of them require that someone trying to work with them understand what they're doing (at least at a high level) and that brings down the maintenance burden quite a bit. Personally, I'm quite impressed with Rails and am happy to see it spread.
What the heck do you think you're doing reading the entire thing? This is/. You're supposed to not read it or just read the first couple of paragraphs and then come back here and try and sound like a pundit.
That being said, I fear that many will read that article and take it quite seriously. It always amazes the luddite stances that technologists seem to adopt about their technology.
I used to be a COBOL programmer and the men on my team were outnumbered by the women. Since I've switched over to newer technologies, women are nowhere to be found.
You can read the bug report about Class::Std to get a handle on the problem. You could probably implement inside-out objects manually and save yourself the problems that Class::Std has. If you read through the Class::Std documentation, you can get enough of a handle on what's going to choose your own implementation.
If you read through your post, you see that you talked about Guile a few times and gave no indication that in clicking a link apparently about Guile that I might, just might, have gleaned a bit of insight about why you object to Parrot. If you have bothered to say up front "hey, this has info relevant to my Parrot objections", I would have clicked the link.
Of course, the main points of that link were lack of developer effort (Parrot has tons of devopers compared to Guile though I confess we don't have enough) and the issue of string handling in different languages (a problem that Parrot addressed a long time ago). There's a claim that a CLR will force languages to adopt a common set of semantics. That claim is false. If you pay attention to current Parrot development, you'd know that. Or if you just asked instead of assumed, you'd know that.
If you have anything current to say, we're all ears. Post it to the development lists, though. I really don't want to bother arguing with someone who is attacking a project they clearly have little knowledge of.
Revolutionary (items in parentheses explain why some "common" features are included here):
an improved object system (revolutionary in its approach)
Register-based VM
junctions
roles
rules and grammars
continuations and coroutines (not widespread)
optional typing and type inferencing (other languages typically don't make this optional)
interoperability with other languages including Perl 5 (because of how easy it is)
hyperoperators
unification of blocks and closures
(Before you criticize those things I put in the revolutionary list, you'd have to take the time to read up on them and realize why I put them there rather than just assume that I don't know what I'm talking about. I've programmed in many languages and I have a very good idea of what's common and what's not -- though perhaps I'm just smoking crack.)
Of course, I could make similar comments as yours about Java (I don't know C++ well). Java languished for a long time without regular expressions. Autoboxing in Tiger was an attempt to get around some of the difficulties inherent in typing the container. The latest Dr. Dobb's has an interesting article about functional programming in Java -- something many other programs have allowed for years. Of course, Java still doesn't have closures (that's sooooo 1980's and interfaces were a neat idea which introduced a different set of problems for the ones they solved). Further, Java's decision to type the containers instead of the data means they must focus more on class types than class capabilities, thereby eliminating many of the benefits of allomorphism. And not even get into how ridiculously verbose the language is. I don't play "Perl golf". I take the time to write out clear code. It's still far shorter than equivalent code in Java.
Mind you, just because I list these issues with Java does not mean that I think it's a bad language. On the contrary: I happen to like Java. I sometimes program in it and just as Perl has some benefits over Java, the reverse is often true. Java and Perl are both crazy but Perl is my type of crazy.
Dead in the water? Parrot is being actively developed, has part of its development being funded by NLNet, and has made great strides in showing the power of a register-based virtual machine vis-a-vis a stack-based virtual machine. Further, instead of just being a "Perl only" sort of thing, tons of developers in many languages have become excited about what Parrot can do for them and we have active developers coming in from other languages to help out given how excited they are about this. Of course, as the Parrot grant manager (er, this is a new role for me and one that most don't know about), I perhaps see this more than most but you're welcome to sign up on the development lists and see for yourself rather than just take my word for it.
Of course, if you have any substance to back up your "mental masturbation" comments, feel free to share it. I'm sure there are many developers who would be curious to know why they're wasting their time.
I do agree that pointing out how invalid some criticisms of Perl are does not solve the perception problem. We're trying to figure out a good strategy to deal with this and suggestions are always welcome.
As in: Perl, unique among all other scripting languages doesn't yet have useful parameter lists in function definitions Every time I type somehing like my ($foo, bar, $baz) = @_; I think to myself "lame lame lame".
And later you wrote: I have been a Perl programmer for 14 years now...
I sometimes hear the criticism about Perl's argument handling, but I don't hear that as much as the line noise issue. The fact that you've been a Perl programmer for 14 years means that you are probably more keenly aware of this than most. I've released a module named Sub::Signatures which helps to deal with this (and allows multi-(?:method|function) dispatching (MMD) based on the number of arguments) but because it's a source filter, people are afraid to try it. Frankly, given the reputation of source filters, I can't say I blame them.
In any event, this criticism is perfectly valid and it's one of my strongest complaints about the language. It's inherently tied to the MMD issue so the latter cannot be resolved easily without the former. Another major issue is lack of encapsulation in standard object creation. Class::Std helps to minimize the problem, but it has problems running under persistent environments such as mod_perl, thus limiting its usefulness in the sort of environment which is designed to scale and thus truly needs that encapsulation. These issues combined with a lack of proper introspection capabilities are my strongest complaints. Solving them would go a long way to making Perl a truly robust language.
These issues aside, I specialize in building huge systems in Perl. I have worked on systems that tell Hollywood how much money their movies make while collecting and collating data from thousands of movie theaters across the USA. I currently work on software used by little-known companies such as the Rand Corporation, the World Health Organization and the Congressionally funded Radio Free Asia (they use my employer's software to publish their Web site in 10 different languages). The major requirement for building large systems such as these is having a robust test suite. Given the latter requirement, you can achieve powerful scalability with just about any language capable of it. Fortunately, because I choose to use Perl, I can roll out solid, robust code much faster than Java or C++ programmers. I have some amusing stories about destroying competitors using those languages because they couldn't keep up with our speed of development but NDAs compel me to keep quite:(
As for Parrot and Perl 6, they solve these problems and many more. However, Parrot is revolutionary in its approach and given that that we are a volunteer organization, it is difficult to get qualified full-time developers to solve truly unique problems. Fortunately, we're finally getting there. Perl 6 is worth the wait but those who haven't been following it closely (and perhaps those who have been following it too closely:) are getting frustrated. I don't blame them, but we don't have a huge staff on hand to crank this stuff out the door.
As one of the people who was elected to the steering committee, I don't mind taking a poke at this question.
Many of the complaints about Perl stem from the fact that Perl was a pioneer in getting "dynamically" typed languages before the public eye. It certainly wasn't the first (was LISP the first major one?), but it has been the largest. Unfortunately, because Perl has been blazing a trail it's had many years of going down promising paths only to find them dead ends (pseudo-hashes anyone?). Languages such as Python and Ruby have been happily running down this path and ignoring the trails they already know to lead to oblivion.
This suggests an obvious question: what's wrong with Perl? Well, there's plenty wrong with Perl that I can point out, but interestingly, I've discovered that the complaints which Perl experts have are radically different from the complaints that casual Perl users have (amusingly, many folks who criticize Perl couldn't tell simple Perl and PHP snippets apart).
Just as I have serious complaints with Perl, those who are experts in Ruby and Python probably have serious problems with those languages which do not mirror my own objections. Python, for example, is eliminating the badly implemented lambda function and getting rid of all hope for closures (feel free to correct me if I'm wrong). Ruby has mixins in lieue of multiple inheritance and traded one set of problems for another (trait composition seems to offer the best of both worlds but it hasn't caught on yet). However, those complaints probably reflect my imperfect understanding of those languages and I strongly suspect that those using these languages have other fish to fry.
A big problem with Perl is that it's being taught incorrectly. Few teaching materials really focus on the linguistic basis of the language. Once you really, really understand the linguistic basis, the difference my $foo =... and my ($foo) =... becomes second nature. The idea of "topics" and "topicalizers", though more explicitly stated in Perl 6, are also quite important but not taught well. It's quite natural, but it's such an unusual feature for programming languages that those who come to Perl who pick up the language in a haphazard manner get annoyed at the seeming fickleness of the language even though many of these behaviors are quite predictable if you understand the linguistic underpinnings. That's not to say there aren't quite a few quirks in the language whose behavior is not predictable, but many languages suffer strange quirks and are still widely used.
People complain about Perl's "line noise" characteristics and unmaintainable programs and ignore that much of this stems from heavy regular expression use (yell at regexes, not Perl) and people without a strong programming background finding the language easy to use (yell at those people, not at their tool). Professional programmers who use Perl often build large, robust systems in a fraction of of the time that developers in Java or C++ would. Of course, good programmers are implementing robust test suites, automatic builds and other tools to catch them when the fall.
When all is said and done, were it not for Perl 6, I'd probably start using Ruby. I have really enjoyed Ruby the few times I used it but it had such limited use (prior to Rails) that I didn't want to jump ship.
What the article doesn't point out is the obvious tradeoff. By having an IT department to manage risk, companies enjoy lower risk but the risk profile changes. IT departments will routinely reghost machines with unauthorized software and that, arguably, is a strong benefit. Once users lose enough data from having not backed up their machine prior to it being reghosted, they learn to backup their data more frequently or not install unauthorized software (assuming they have the administrative rights to install that software in the first place.)
What that means, generally, is that problems from unauthorized software will be minimized and other problems will be magnified in comparison. I note that the author of that article didn't offer a solution to this perceived problem.
Perhaps a deeper problem is that IT security represents, to the company, what an economist would refer to as a "public good." Your department will enjoy the protection of powerful firewalls, anti-virus protection and locked down machines even if the costs are not applied directly to your department's budget. As a result, I've frequently seen business departments argue against increased funding for IT security in the mistaken belief that the potentially negative impact on their budget will hurt them. They somehow believe that if they do not pay for the security directly, the IT department will magically find other solutions for those problems.
Only increased employee education about the dangers inherent in their actions seems to be a viable method of reducing this problem.
OK, the question "what's an IT manager?" might sound silly, but it's not. What is his job description? Just because he has a particular job title doesn't mean what he's been hired to do is what you would expect from that title. Those "insignificant tasks" you mention might involve him preparing budget reports to justify your continued employment. Sadly, many technical folk I meet have a poor understanding of business needs (and vice versa).
That being said, if he is truly causing difficulty, you need to document the problems. Have dates and times ready. List what was done and how this caused problems. Speaking from sad personal experience, I've discovered that going in to a meeting without solid documentation of the problems that must be resolved frequently winds up turning into a vague bitch session. Vague complaints tend to be viewed very poorly and can hurt the complainer more than the the target of the complaints.
Regardless of whether or not that is true (I wouldn't swear by it), the point is not whether or not everyone can use the particular version of make I want them to use. It's whether or not the version of make they actually do use is compatible with my Makefile. That's why Java has Ant. That's why Ruby has Rake. That's why Perl has Module::Build. That's why more and more open-source software projects are realizing that make doesn't cut it. Just because you think that GNU make is superior to Solaris make (which behaves quite differently in many cases) doesn't mean that that a Solaris shop will easily convince their admin to install your version of make just because you have a personal preference.
You should read up about the limitations of make and compatability issues of different versions.
make is awful. Different operating systems have different command line syntax, different path separators, limits to command length, etc. And which make are you using? nmake, dmake, bsd make, etc? There are tons of different make programs, many of which are subtly incompatible with one another and sometimes incompatible with different versions of themselves.
So if you can tightly control the operating systems you are distributing to and tightly control the versions of make you are using, make is a fine solution. For those of us who distribute open-source code, make is an absolute nightmare. How many of us want to repond to someone claiming they can't install our software or VMS? Admittedly, some don't care, but I don't want a reputation as someone who distributes non-portable software. (Note, this isn't intended as a flame. Your needs are likely completely different from my own and make may suit them perfectly.)
Why students? As noted, the intent is to draw new programmers into the fold. However, people like me could just have fun milking the situation. If I had $4,500 dollars for every half-finished project on my hard-drive, I could have a blast. However, I've already cranked out a lot of open-source code (and tutorials and full-blown courses) and I'll continue to do so without this incentive.
Or that you'll have to present ID to do all those things listed which, at present, already require presenting an ID?
First of all, there's a difference between an ID that is issued locally and the ID that is proposed. If you read the original, then you would understand how the proposed ID is different and why there are privacy concerns. Further, am I really required to provide ID when flying on an airplane? There's already a well-known lawsuit challenging whether or not this is the case. Is this an airline rule? Is this a law? Who knows? The US government refuses to explain the exact status of this rule citing "security concerns." Thus we, as individuals, are being asked to obey laws that we're not allowed to see and which may or may not be Constitutional. Does having secret laws not strike you as a bit odd?
Frankly, I don't care to have our government exercising its authority without citizens having some say in the matter. In the case of the national ID law that was attached to a military spending bill, debate has been stifled and we're left sitting here wondering if the government will abuse this law, too.
No, they just said you have to identify yourself, not that you hade to produce proof of identity. The dude in that case need only have said "my name is Larry Hiibel". Cripes, don't you people even read what you link to?
I do read what I link to, thank you. Had you bothered to follow the link through to the actual ruling, and had you actually bothered to read it, you would have noticed this little gem:
"[I]nterrogation relating to one's identity or a request for identification by the police does not, by itself, constitute a Fourth Amendment seizure."
So yes, a police officer can interrogate someone and demand to see some form of identification. And while there is a requirement that the police officer's stop be "reasonable" and somehow limited to what is currently being investigated, no probably cause is required. Then, if the request is legitimate and the person refuses, the officer can arrest that individual.
I certainly don't think it's quite as onerous, but it's not too far from it. I did read the article and here's the second paragraph:
Starting three years from now, if you live or work in the United States, you'll need a federally approved ID card to travel on an airplane, open a bank account, collect Social Security payments, or take advantage of nearly any government service. Practically speaking, your driver's license likely will have to be reissued to meet federal standards.
So, any/. folks old enough, like me, to remember how we would react with derision and scorn at the horrifying stories of people in the USSR being required to have "internal passports" for travel and always carry identity papers? Well, just for giggles, how would you define "internal passport" and how is that different from this?
Slashdot Mirror
I don't hate Perl and I'm competent with it, but if I wanted to deal with that level of bookkeeping, I'd probably just write C and be done with it.
Whoa there, dude. Hinting at a comparison of Perl's references to C's pointers is like comparing untying your shoelace to untying the Gordian knot. In fact, comparing something so simple (with a sometimes annoying syntax) with something so confusing that many programmers never master it is so ridiculous that I know that couldn't possibly be what you meant. So what did you mean?
I am a Perl programmer and I'm quite happy with my salary, thank you. Further, I'll likely be moving to London soon and I regularly see Perl jobs at £45,000/year or more (roughly $86,000 on up). Even outside of London I regularly see Perl jobs in the UK for £30K (~ $57K) or more. Those really aren't bad salaries, particularly when you consider that they are starting salaries.
Combine that with the fact that tons of Perl jobs are currently available and many London employers are complaining that they can't find enough Perl programmers (largely due to the FUD about Perl which drives many programmers away), and competent Perl programmers can have their pick of the jobs.
Amen! I've found plenty of great people through that and I, in turn, have picked up great jobs through it. Fortunately the quality of jobs listed there is often very high and Perl programmers who really have a clue pay attention to that site, even when they're not looking for work. It's a great way to spot trends.
You're absolutely right. I had those backwards. Thanks for the catch.
Do you have a beef with compilers and assemblers?
This is a valid question. Quite often when we have a robust low-level language generating high-level language (HLL) code, it's extremely well thought out and tested. However, many are dubious about HLL generating HLL code. I suspect (though I can't prove it) that this is because HLL -> HLL tends to be less widely used and thus is less thoroughly tested and less planned. When done properly -- particularly when covering a restricted and well-defined domain -- it can be extremely powerful. When done improperly, it's a nightmare.
Rails has a large enough user base that most common bugs have been eradicated but from what I've seen, it appears to have a problem that many fourth generation languages suffer from: if your problem fits its domain, it's a piece of cake to solve. When your problem doesn't fit its domain, it can be extremely difficult to solve (anyone who's ever worked with the 4GL Easystrieve Plus can readily testify to this). Most web-based apps, though, are simple enough that folks working with Ruby generally don't seem to have much of a problem with it. However, I've heard horror stories about people trying to use their custom model in lieu of what Rails natively supports -- though I've not had first-hand experience.
Compilers and assemblers tend to be general purpose tools which address a fairly wide problem space. HLL -> HLL tools tend to be special purpose tools and trying to get them to solve problems they aren't optimized for can be trying. In the case of Rails, one thing it excels at (CRUD apps) is a well-known problem space and Rails fits quite nicely.
So I have to say that comparing Rails to compilers or assemblers doesn't quite fit simply due to the differing focus of said tools. However, all of them require that someone trying to work with them understand what they're doing (at least at a high level) and that brings down the maintenance burden quite a bit. Personally, I'm quite impressed with Rails and am happy to see it spread.
What the heck do you think you're doing reading the entire thing? This is /. You're supposed to not read it or just read the first couple of paragraphs and then come back here and try and sound like a pundit.
That being said, I fear that many will read that article and take it quite seriously. It always amazes the luddite stances that technologists seem to adopt about their technology.
I used to be a COBOL programmer and the men on my team were outnumbered by the women. Since I've switched over to newer technologies, women are nowhere to be found.
You can read the bug report about Class::Std to get a handle on the problem. You could probably implement inside-out objects manually and save yourself the problems that Class::Std has. If you read through the Class::Std documentation, you can get enough of a handle on what's going to choose your own implementation.
If you read through your post, you see that you talked about Guile a few times and gave no indication that in clicking a link apparently about Guile that I might, just might, have gleaned a bit of insight about why you object to Parrot. If you have bothered to say up front "hey, this has info relevant to my Parrot objections", I would have clicked the link.
Of course, the main points of that link were lack of developer effort (Parrot has tons of devopers compared to Guile though I confess we don't have enough) and the issue of string handling in different languages (a problem that Parrot addressed a long time ago). There's a claim that a CLR will force languages to adopt a common set of semantics. That claim is false. If you pay attention to current Parrot development, you'd know that. Or if you just asked instead of assumed, you'd know that.
If you have anything current to say, we're all ears. Post it to the development lists, though. I really don't want to bother arguing with someone who is attacking a project they clearly have little knowledge of.
Nice job changing the subject. I see you really don't have much to say. My apologies for wasting your time.
80% catch up? I think your math is off.
Catch up:
Revolutionary (items in parentheses explain why some "common" features are included here):
(Before you criticize those things I put in the revolutionary list, you'd have to take the time to read up on them and realize why I put them there rather than just assume that I don't know what I'm talking about. I've programmed in many languages and I have a very good idea of what's common and what's not -- though perhaps I'm just smoking crack.)
Of course, I could make similar comments as yours about Java (I don't know C++ well). Java languished for a long time without regular expressions. Autoboxing in Tiger was an attempt to get around some of the difficulties inherent in typing the container. The latest Dr. Dobb's has an interesting article about functional programming in Java -- something many other programs have allowed for years. Of course, Java still doesn't have closures (that's sooooo 1980's and interfaces were a neat idea which introduced a different set of problems for the ones they solved). Further, Java's decision to type the containers instead of the data means they must focus more on class types than class capabilities, thereby eliminating many of the benefits of allomorphism. And not even get into how ridiculously verbose the language is. I don't play "Perl golf". I take the time to write out clear code. It's still far shorter than equivalent code in Java.
Mind you, just because I list these issues with Java does not mean that I think it's a bad language. On the contrary: I happen to like Java. I sometimes program in it and just as Perl has some benefits over Java, the reverse is often true. Java and Perl are both crazy but Perl is my type of crazy.
Dead in the water? Parrot is being actively developed, has part of its development being funded by NLNet, and has made great strides in showing the power of a register-based virtual machine vis-a-vis a stack-based virtual machine. Further, instead of just being a "Perl only" sort of thing, tons of developers in many languages have become excited about what Parrot can do for them and we have active developers coming in from other languages to help out given how excited they are about this. Of course, as the Parrot grant manager (er, this is a new role for me and one that most don't know about), I perhaps see this more than most but you're welcome to sign up on the development lists and see for yourself rather than just take my word for it.
Of course, if you have any substance to back up your "mental masturbation" comments, feel free to share it. I'm sure there are many developers who would be curious to know why they're wasting their time.
I do agree that pointing out how invalid some criticisms of Perl are does not solve the perception problem. We're trying to figure out a good strategy to deal with this and suggestions are always welcome.
And later you wrote: I have been a Perl programmer for 14 years now ...
I sometimes hear the criticism about Perl's argument handling, but I don't hear that as much as the line noise issue. The fact that you've been a Perl programmer for 14 years means that you are probably more keenly aware of this than most. I've released a module named Sub::Signatures which helps to deal with this (and allows multi-(?:method|function) dispatching (MMD) based on the number of arguments) but because it's a source filter, people are afraid to try it. Frankly, given the reputation of source filters, I can't say I blame them.
In any event, this criticism is perfectly valid and it's one of my strongest complaints about the language. It's inherently tied to the MMD issue so the latter cannot be resolved easily without the former. Another major issue is lack of encapsulation in standard object creation. Class::Std helps to minimize the problem, but it has problems running under persistent environments such as mod_perl, thus limiting its usefulness in the sort of environment which is designed to scale and thus truly needs that encapsulation. These issues combined with a lack of proper introspection capabilities are my strongest complaints. Solving them would go a long way to making Perl a truly robust language.
These issues aside, I specialize in building huge systems in Perl. I have worked on systems that tell Hollywood how much money their movies make while collecting and collating data from thousands of movie theaters across the USA. I currently work on software used by little-known companies such as the Rand Corporation, the World Health Organization and the Congressionally funded Radio Free Asia (they use my employer's software to publish their Web site in 10 different languages). The major requirement for building large systems such as these is having a robust test suite. Given the latter requirement, you can achieve powerful scalability with just about any language capable of it. Fortunately, because I choose to use Perl, I can roll out solid, robust code much faster than Java or C++ programmers. I have some amusing stories about destroying competitors using those languages because they couldn't keep up with our speed of development but NDAs compel me to keep quite :(
As for Parrot and Perl 6, they solve these problems and many more. However, Parrot is revolutionary in its approach and given that that we are a volunteer organization, it is difficult to get qualified full-time developers to solve truly unique problems. Fortunately, we're finally getting there. Perl 6 is worth the wait but those who haven't been following it closely (and perhaps those who have been following it too closely :) are getting frustrated. I don't blame them, but we don't have a huge staff on hand to crank this stuff out the door.
Patches welcome :)
As one of the people who was elected to the steering committee, I don't mind taking a poke at this question.
Many of the complaints about Perl stem from the fact that Perl was a pioneer in getting "dynamically" typed languages before the public eye. It certainly wasn't the first (was LISP the first major one?), but it has been the largest. Unfortunately, because Perl has been blazing a trail it's had many years of going down promising paths only to find them dead ends (pseudo-hashes anyone?). Languages such as Python and Ruby have been happily running down this path and ignoring the trails they already know to lead to oblivion.
This suggests an obvious question: what's wrong with Perl? Well, there's plenty wrong with Perl that I can point out, but interestingly, I've discovered that the complaints which Perl experts have are radically different from the complaints that casual Perl users have (amusingly, many folks who criticize Perl couldn't tell simple Perl and PHP snippets apart).
Just as I have serious complaints with Perl, those who are experts in Ruby and Python probably have serious problems with those languages which do not mirror my own objections. Python, for example, is eliminating the badly implemented lambda function and getting rid of all hope for closures (feel free to correct me if I'm wrong). Ruby has mixins in lieue of multiple inheritance and traded one set of problems for another (trait composition seems to offer the best of both worlds but it hasn't caught on yet). However, those complaints probably reflect my imperfect understanding of those languages and I strongly suspect that those using these languages have other fish to fry.
A big problem with Perl is that it's being taught incorrectly. Few teaching materials really focus on the linguistic basis of the language. Once you really, really understand the linguistic basis, the difference my $foo = ... and my ($foo) = ... becomes second nature. The idea of "topics" and "topicalizers", though more explicitly stated in Perl 6, are also quite important but not taught well. It's quite natural, but it's such an unusual feature for programming languages that those who come to Perl who pick up the language in a haphazard manner get annoyed at the seeming fickleness of the language even though many of these behaviors are quite predictable if you understand the linguistic underpinnings. That's not to say there aren't quite a few quirks in the language whose behavior is not predictable, but many languages suffer strange quirks and are still widely used.
People complain about Perl's "line noise" characteristics and unmaintainable programs and ignore that much of this stems from heavy regular expression use (yell at regexes, not Perl) and people without a strong programming background finding the language easy to use (yell at those people, not at their tool). Professional programmers who use Perl often build large, robust systems in a fraction of of the time that developers in Java or C++ would. Of course, good programmers are implementing robust test suites, automatic builds and other tools to catch them when the fall.
When all is said and done, were it not for Perl 6, I'd probably start using Ruby. I have really enjoyed Ruby the few times I used it but it had such limited use (prior to Rails) that I didn't want to jump ship.
What the article doesn't point out is the obvious tradeoff. By having an IT department to manage risk, companies enjoy lower risk but the risk profile changes. IT departments will routinely reghost machines with unauthorized software and that, arguably, is a strong benefit. Once users lose enough data from having not backed up their machine prior to it being reghosted, they learn to backup their data more frequently or not install unauthorized software (assuming they have the administrative rights to install that software in the first place.)
What that means, generally, is that problems from unauthorized software will be minimized and other problems will be magnified in comparison. I note that the author of that article didn't offer a solution to this perceived problem.
Perhaps a deeper problem is that IT security represents, to the company, what an economist would refer to as a "public good." Your department will enjoy the protection of powerful firewalls, anti-virus protection and locked down machines even if the costs are not applied directly to your department's budget. As a result, I've frequently seen business departments argue against increased funding for IT security in the mistaken belief that the potentially negative impact on their budget will hurt them. They somehow believe that if they do not pay for the security directly, the IT department will magically find other solutions for those problems.
Only increased employee education about the dangers inherent in their actions seems to be a viable method of reducing this problem.
For those who are curious, the Perl Foundation had 8 Summer of Code projects funded. They were a blast to work with.
OK, the question "what's an IT manager?" might sound silly, but it's not. What is his job description? Just because he has a particular job title doesn't mean what he's been hired to do is what you would expect from that title. Those "insignificant tasks" you mention might involve him preparing budget reports to justify your continued employment. Sadly, many technical folk I meet have a poor understanding of business needs (and vice versa).
That being said, if he is truly causing difficulty, you need to document the problems. Have dates and times ready. List what was done and how this caused problems. Speaking from sad personal experience, I've discovered that going in to a meeting without solid documentation of the problems that must be resolved frequently winds up turning into a vague bitch session. Vague complaints tend to be viewed very poorly and can hurt the complainer more than the the target of the complaints.
"abends"? My God, man! How old are you? Sheesh. I haven't heard that term since I worked on mainframes.
Wait ... how old am I?
Regardless of whether or not that is true (I wouldn't swear by it), the point is not whether or not everyone can use the particular version of make I want them to use. It's whether or not the version of make they actually do use is compatible with my Makefile. That's why Java has Ant. That's why Ruby has Rake. That's why Perl has Module::Build. That's why more and more open-source software projects are realizing that make doesn't cut it. Just because you think that GNU make is superior to Solaris make (which behaves quite differently in many cases) doesn't mean that that a Solaris shop will easily convince their admin to install your version of make just because you have a personal preference.
You should read up about the limitations of make and compatability issues of different versions.
Your complaint belongs in the late 80s or so.
Your defense belongs in the late 90s or so :)
make is awful. Different operating systems have different command line syntax, different path separators, limits to command length, etc. And which make are you using? nmake, dmake, bsd make, etc? There are tons of different make programs, many of which are subtly incompatible with one another and sometimes incompatible with different versions of themselves.
So if you can tightly control the operating systems you are distributing to and tightly control the versions of make you are using, make is a fine solution. For those of us who distribute open-source code, make is an absolute nightmare. How many of us want to repond to someone claiming they can't install our software or VMS? Admittedly, some don't care, but I don't want a reputation as someone who distributes non-portable software. (Note, this isn't intended as a flame. Your needs are likely completely different from my own and make may suit them perfectly.)
For once, an appropriate application of the Soviet joke. Kudos.
Why students? As noted, the intent is to draw new programmers into the fold. However, people like me could just have fun milking the situation. If I had $4,500 dollars for every half-finished project on my hard-drive, I could have a blast. However, I've already cranked out a lot of open-source code (and tutorials and full-blown courses) and I'll continue to do so without this incentive.
First of all, there's a difference between an ID that is issued locally and the ID that is proposed. If you read the original, then you would understand how the proposed ID is different and why there are privacy concerns. Further, am I really required to provide ID when flying on an airplane? There's already a well-known lawsuit challenging whether or not this is the case. Is this an airline rule? Is this a law? Who knows? The US government refuses to explain the exact status of this rule citing "security concerns." Thus we, as individuals, are being asked to obey laws that we're not allowed to see and which may or may not be Constitutional. Does having secret laws not strike you as a bit odd?
Frankly, I don't care to have our government exercising its authority without citizens having some say in the matter. In the case of the national ID law that was attached to a military spending bill, debate has been stifled and we're left sitting here wondering if the government will abuse this law, too.
No, they just said you have to identify yourself, not that you hade to produce proof of identity. The dude in that case need only have said "my name is Larry Hiibel". Cripes, don't you people even read what you link to?I do read what I link to, thank you. Had you bothered to follow the link through to the actual ruling, and had you actually bothered to read it, you would have noticed this little gem:
So yes, a police officer can interrogate someone and demand to see some form of identification. And while there is a requirement that the police officer's stop be "reasonable" and somehow limited to what is currently being investigated, no probably cause is required. Then, if the request is legitimate and the person refuses, the officer can arrest that individual.
I certainly don't think it's quite as onerous, but it's not too far from it. I did read the article and here's the second paragraph:
Further, with the Supremes recently ruling that's it's OK to arrest someone who fails to produce an ID upon demand, this just puts us one step closer.
So, any /. folks old enough, like me, to remember how we would react with derision and scorn at the horrifying stories of people in the USSR being required to have "internal passports" for travel and always carry identity papers? Well, just for giggles, how would you define "internal passport" and how is that different from this?