Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

99 comments

mmmmmmmmmm (-1)

Anonymous Coward | more than 3 years ago | (#34661834)

i love cruisy gay sex. sometimes when i'm not expecting it there's a fat asian cock pushing me inside out spurting so hard that i can feel it dripping down my chin. thank you rms, thank you for gnu/linux and gnu/emacs!!!

Perl6 (1)

Monkeedude1212 (1560403) | more than 3 years ago | (#34661868)

The only requirement is that you know how to be nice to all kinds of people (and butterflies)

Reading the Perl 6 page - either they are REAL programmers, or they use emacs.

Re:Perl6 (3)

FooAtWFU (699187) | more than 3 years ago | (#34661920)

Also, I was strongly under the impression that Rakudo was still more of a 'useful, usable, "early adopter" distribution of Perl 6' than a mature, production-ready system.

Mind you, I'd be thrilled to see some nice new stuff in the Perl space. But I work on a software appliance and some of the customers pay tens of thousands of dollars (or more) for it and they do expect a modicum of reliability....

Re:Perl6 (4, Interesting)

Short Circuit (52384) | more than 3 years ago | (#34662088)

I've been playing around with Perl 6 a little this week. Rakudo works well enough that I'll be using Perl 6 where I've previously been using Perl. I find it useful to follow the Perl 6 Planet, as it has a bunch of Perl 6 developers' perspectives and musings as they use the langauge. (For example, one guy wrote his blogging engine in Perl 6, and commented on speed differences between a couple Perl 6 implementations.)

I'm also helped that Larry Wall has been doing active code review of the Perl 6 code [rosettacode.org] over on Rosetta Code, a site I run; it's nice to have an active source of idiomatic code for understanding the language.

Esspweb (1)

Esspweb (1937232) | more than 3 years ago | (#34752230)

Well i think you are absolutely right. But my friend be calm down. Don't take it much serious. Be coooolllll.

Yeah, now try hiring for it. (4, Interesting)

FooAtWFU (699187) | more than 3 years ago | (#34661882)

Yeah, now try hiring for a good OO software engineer to write Perl. The applicant pool isn't spectacularly broad. Not too surprising, I suppose, since most of the positions out there featuring Perl are either QA automation or something titled "Build Engineer". Ruby has all the mindshare these days.

(Hiring ~4 OO software engineers to do Perl. [newtonsoftware.com] Forgive the inane outsourced hiring-management site. Merry Christmas.)

Re:Yeah, now try hiring for it. (1)

Anonymous Coward | more than 3 years ago | (#34661918)

Why bother limiting it by language?

We're a perl shop, and don't really require any applicants to know Perl to come in through the door. Bonus points for knowing functional languages, SmallTalk, Scala, whatever.

There is ramp-up for people to pick up Perl, but if they're good developers it's a pretty negligible period of time. It takes a lot longer to get people to understand the ideas of functional programming they can incorporate in that makes the code significantly easier to use, write and test.

Re:Yeah, now try hiring for it. (2)

FooAtWFU (699187) | more than 3 years ago | (#34661948)

Oh, believe you me, we're not trying to "limit it by language" at all. The challenge is figuring out how to get those good developers (who I imagine are generally thinking "I suppose I'll look for a position at a cool, hip Web 2.0 startup using Ruby on Rails, it's a decent language") and hold their attention for long enough to pitch the position. After that, it's easy enough; there's just a dearth of interest. Hiring good people is certainly possible, but it goes really slowly, even when you have a decent recruiter to work with.

Re:Yeah, now try hiring for it. (3, Interesting)

FooAtWFU (699187) | more than 3 years ago | (#34662178)

I should clarify, actually. We (the dev team) are not trying to limit it by language. Our in-house recruiter, however.... well, he's got different ideas about what we're looking for than we do, and let's just say I've heard rumblings from the head of Engineering which don't bode well for his future. Not that I can take any credit; I'm just now taking over hiring for my department; the battle to make our job posting look half-decent for this round of hiring begins when I get back from Christmas vacation. In the meantime, I'm asking around for tips [stackexchange.com] .

Re:Yeah, now try hiring for it. (3, Insightful)

bzipitidoo (647217) | more than 3 years ago | (#34663176)

Don't be too hard on the recruiter. All his training puts the highest priorities on "skills", and very specific experiences. He wouldn't know a great coder from a good liar who feels that spreadsheet macros are his limit. A person like that shouldn't have been given the job of screening applicants. It's not his fault, it's the fault of management for delegating this crucial function to someone who lacks the background to judge the technical merits of applicants. What tools he has left for making judgments are weak, but it's all he has, so he uses them.

And it's all our faults for focusing far too much on specific languages. We all know that anyone who is good at several programming languages is not going to have a problem picking up a new one. Even programming paradigms are not the big deal they make them out to be. OOP and Functional Programming are not that profound or mysterious. Lot of what is being called functional programming is actually modular programming. But you can't tell any of that to the interviewers. Have to tailor your resume and give yourself a crash course on whatever it is they say they want so you can answer the trivia questions they're using to screen people. I use Perl, but I sure don't have something like all the operators memorized. That's what a reference manual is for, and I have found the Camel book an excellent one.

It never ceases to amaze me that so many companies treat the search for talent as little more than a rigged lottery. Head hunting agencies are even worse. They come up with the craziest, completely subjective, off-the-wall reasons for rejecting people, and then complain that they can't find talent. "Learning on the job" is so pre 1980. "Hit the ground running" or "don't let the door hit your ass on the way out" is the way things have been for a long time now. And they don't want competence alone. Many also seek signs that their choice won't leave, and can be pressured to work harder, maybe has something in the closet that shows he understands the "realities" of doing business and so will not make any trouble for management, by, say, doing any whistleblowing. They want a contradiction-- competence at the job, and incompetence at personal finances so that the employee cannot leave without losing everything. Makes the employee more "reliable".

Cue the job postings for 5 years of experience in Perl 6.

Re:Yeah, now try hiring for it. (2)

DrVomact (726065) | more than 3 years ago | (#34664666)

This problem has been around forever. Management thinks that "managing human resources" is a special and oh-so-useful skill-set—only HR knows how to hire the right people. This results in a situation where both the candidates and the techies who are actually going to be working with the new hire have to circumvent HR. Think of it as an intelligence test. It's usually not much of a challenge.

Re:Yeah, now try hiring for it. (1)

MysteriousPreacher (702266) | more than 2 years ago | (#34665786)

Yeah, I think in hiring that HR need to be focussing on where their skills lie, i.e. not trying ascertain useful technical skills when they lack a sufficient background to do so. I remember my first tech job interview. The HR guy in that case doubted I had the skills to go in to an entry level tech support job, despite my having a a CS degree behind me and a decent background in Unix-likes and Windows systems. Oddly enough after doing tier one for a while I moved on to server, hardware and pro video support.

I don't blame him. It's the overall recruitment process that sucked. One change I've noted is managers and prospective peers being involved in recruitment. Last job I interviewed for I had around four interviews, all with various people in the organisation - some of whom scoped me out pretty well with some casual technical discussions. Didn't get that job but I came away respecting their hiring process.

Re:Yeah, now try hiring for it. (1)

queBurro (1499731) | more than 2 years ago | (#34666462)

totally agree, spotted a '5 years experience in vs2008' last year

Re:Yeah, now try hiring for it. (0)

Anonymous Coward | more than 3 years ago | (#34662634)

You seem to be focused on web developers, hence your comment about Ror. If you're doing Perl these days, you want Devops guys, not web developers.

Re:Yeah, now try hiring for it. (1)

chromatic (9471) | more than 3 years ago | (#34661928)

Have you considered hiring good developers and then teaching them OO Perl? If your workplace uses Moose [cpan.org] , for example, writing good OO Perl 5 is surprisingly easy and effective.

The Moose description says bad things about Perl. (1)

Futurepower(R) (558542) | more than 3 years ago | (#34662104)

This is a quote from the Moose page to which you linked: "The main goal of Moose is to make Perl 5 Object Oriented programming easier, more consistent and less tedious. With Moose you can to think more about what you want to do and less about the mechanics of OOP."

The implication is that, without Moose, Perl 5 is difficult, inconsistent, and tedious.

Is this mistake, "... you can to think more...", indicative of the quality control for Moose?

Re:The Moose description says bad things about Per (2)

chromatic (9471) | more than 3 years ago | (#34662162)

The implication is that, without Moose, Perl 5 is difficult, inconsistent, and tedious.

That inference may go too far. Perl 5's default OO is flexible and powerful, but it goes too far in allowing flexibility and it doesn't promote an obvious best way for most projects. As with any abstraction which offers and takes advantage of defaults, Moose reduces complexity and makes it easier to write consistent and concise code.

... the quality control for Moose?

I'm certain many CPAN contributors will welcome an automated testing system to find non-spelling documentation typos. That'll be a very nice addition to the extensive test suites for Moose and other important CPAN distributions.

Thanks for reporting the typo, though. I'm fixing it in the repository right now.

Re:The Moose description says bad things about Per (1)

Alastair (3224) | more than 3 years ago | (#34662190)

A little unfair.

Without using a framework like Moose (or Mouse even), Perl OO is less consistent (TMTOWTDI) and a bit harder. Moose automates and simplifies things like class accessors etc. so one could say Perl OO is also (potentially) more tedious without it.

Re:The Moose description says bad things about Per (1)

Pe_Ell (855470) | more than 3 years ago | (#34683160)

It also seems to make people load frameworks rather than learn the language. I've fixed a few libraries I found that were using Moose by removing the framework and replacing it with 30 lines of OO code. They loaded another 35 files just to avoid a couple ISA statements and do some input validation. If people bothered to learn the language they could make their code even faster and cleaner. This problem is even worse in PHP. And java seems to require every project to write their own. :/

After many years of excellent work, Perl is dying? (1)

Futurepower(R) (558542) | more than 3 years ago | (#34662060)

My recent experience is that discussions of Perl quickly turn to discussions of Python, after people make statements like, "If it weren't for CPAN, Perl would be dead."

"There's more than one way to do it." [wikipedia.org] translates to, quoting from Wikipedia, "This makes it easy to write extremely messy programs..."

I'm not dead yet! (0)

Anonymous Coward | more than 3 years ago | (#34662156)

Perl is still alive and well on BSD systems :-)

Re:I'm not dead yet! (1)

micheas (231635) | more than 3 years ago | (#34662530)

Perl is still alive and well on BSD systems :-)

Although FreeBSD purged perl from core a long time ago so that people did not have two versions of perl, base and the version from ports for real work.

Re:I'm not dead yet! (1)

ziggyzaggy (552814) | more than 3 years ago | (#34663568)

used for build and ports, but who's writing any new things in it. I make BSD appliance software, but haven't done Perl in six years.

Re:After many years of excellent work, Perl is dyi (5, Interesting)

Junta (36770) | more than 3 years ago | (#34662184)

My experience has been largely:
-if working on existing progress, continue in language it is already in
-if working on new project, what's the language most comfortable for the most developers available

Frequently, the answer continues to be perl, sometimes python, sometimes ruby. Usually, I can't be bothered to care. If it comes down to my call, currently I prefer:
-If planning to use across many OS updates, perl5. Nice and stagnant, not screwing around with how it does things, perl6 threatens this.
-If not expecting a lot of churn on the runtime but active development across random developers coming and going as available, python as it forces readability.
-If expected to work in a barebones as possible generic windows, vbscript, but please no.
-If wanting to work with as few prereqs as possible on Windows server 2008r2/7, then powershell.
-Have gone along with ruby, but have not personally found the magic situation I personally prefer it for above all other possibilities.

Re:After many years of excellent work, Perl is dyi (1)

sourcerror (1718066) | more than 3 years ago | (#34663612)

I think Ruby beats Python in features only in rare cornercases, which aren't that hard to do Python either. When you already know Python there's not much motivation to learn Ruby. They're too similar.

Re:After many years of excellent work, Perl is dyi (2)

chengiz (998879) | more than 3 years ago | (#34665264)

This is my experience as well. However, in my case the definition of project is a bit loose:
- Someone wrote a script in perl and left the company.
- Someone else needs to make Improvements to this code but they dont know perl. Even though the original code is written in as clear and readable perl as possible, they automatically think perl is hard. This is in fact company policy now. They write a python script and make a system call to it from the perl code. Soon there are two, three... seven python calls in the perl code.
- Someone now wants to break the perl code up, so now there are python calls in the perl code and perl calls in the python code.
- Someone wraps this up in a shell script.
- Someone else learnt bash and not sh so they make bash calls in this code and it no longer works on non linux architectures.
- Someone who knew the original developer calls him and they enjoy a wry laugh.

That is sadly true... (0)

Anonymous Coward | more than 3 years ago | (#34668050)

Even putting aside 'legacy' interop, I see people writing perl call sed via backticks to do some substitution or similar thing, seemingly forgetting they are already in a rich language and that backticks are relatively expensive.

Also, ditto on the perl readability. While it's possible to write hard to read code, it's also possible to write perl code as readable as any other language. It's just harder in python to write hard to read code (though not impossible).

Tips for perl programmer sanity:
-Avoid the use of $_ in most cases. You can spare the keystrokes for the sake of readability, there is a high chance at some point your loop will get nested/long and $_ becomes hard to follow. Similarly, get captured variables into recognizably named variables ASAP.
-Be consistent about code indentations and be generous with line breaks.
-If your sub is going to take more than one argument, use named arguments as the means to interface.
-Beware of some perl conveniences like 'map'. I generally avoid it in favor of more generally understood loops, though I think map would be an interesting operation for automatic parallelization. If the latter is possible or map is otherwise more efficient, then comment those with how it would look as a loop.

No one will read, but I thought I'd toss that in.

Re:That is sadly true... (0)

Anonymous Coward | more than 3 years ago | (#34674198)

> Beware of some perl conveniences like 'map'.

Hardly a perl convenience. There's hardly a high level language that doesn't have such a construct, and languages like python go a step further and build it into the syntax via list comprehensions. If you're constructing a new array from another array, then map is what you want.

Loops can be controlled manually, they have loop variables that may leak out, and so on. Maps avoid all of that. Yes, you can use higher level constructs to create super-dense impenetrable code, but you can even do that with loops in perl.

Re:After many years of excellent work, Perl is dyi (5, Interesting)

grcumb (781340) | more than 3 years ago | (#34662510)

My recent experience is that discussions of Perl quickly turn to discussions of Python, after people make statements like, "If it weren't for CPAN, Perl would be dead."

That's not too far from the truth, if you understand that statement to be analogous to "If it weren't for the US dollar, the American economy would be dead." It may only be one thing, but it's a pretty big thing.

"There's more than one way to do it." [wikipedia.org] translates to, quoting from Wikipedia, "This makes it easy to write extremely messy programs..."

No grasshopper, you fundamentally misunderstand the implications of that statement. Show me a problem in which there isn't more than one way to do it, and I'll show you a problem you haven't grokked properly yet. Perl is a language without ideology. If programming languages were religions, perl would be closer to atheism (sorry Larry) than to anything else. Yes, it sometimes does cast people adrift because they're forced to accept that there is no final arbiter, that sometimes choices do come down to indulging one's biases. The difference here is that we recognise that, and that you have no one to blame for the biases except yourself.

For a good programmer, this is one of the paths to enlightenment.

To abuse the ideology metaphor a little further, perl is democratic (and borderline anarchic) because it does not criminalise stupidity. Likewise, it doesn't always protect you from yourself. If you really want to do things a certain way, the language probably won't stop you, and might even help you.

And if you still don't get the freedom that perl provides, feel free to vacate the green space in front of my domicile. I'm not going to force you off, but I might laugh at you if you stay.

Re:After many years of excellent work, Perl is dyi (0)

Anonymous Coward | more than 3 years ago | (#34675304)

TMTOWTDI is a big problem for perl. And I'll explain why.

1) Any problem of much sophistication has more than one way to solve it, in terms of algorithm. These differences are essential, and worthwhile. Then there are the differences introduced by perl, just because the designers had a "sure, if you want" attitude to almost everything. These differences are a pointless way of adding complication for complication's sake.

2) Perl is like 10 languages rolled up into one (as a direct consequence of TMTOWTDI). When you write perl, you can use any of the 10, and you'll be fine. But if you're working on code that's had more than one contributor, you're going to get a mishmash of the 10 that require you to learn and relearn the same things, pointlessly.

Re:After many years of excellent work, Perl is dyi (1)

thetoadwarrior (1268702) | more than 3 years ago | (#34664884)

You could say that about any language. Seriously, who would use Java if it didn't have a huge wealth of useful libraries like apache commons?

Re:Yeah, now try hiring for it. (3, Informative)

Short Circuit (52384) | more than 3 years ago | (#34662100)

If you're looking for Perl 6 coders, you might try their IRC channel, #perl6 on Freenode [perl6.org] .

Re:Yeah, now try hiring for it. (1)

SW6 (140530) | more than 3 years ago | (#34662228)

Perl software development is a seller's market, and that job ad is rubbish and fails to pique interest. It's a bland description with no indication of benefits or salary on offer. In fact, it's even less detailed than the crap Perl job ads that pimps spam me with me on a daily basis. Lack of detail implies there is little good to say about the job. Is that the impression you want to give?

Answer this simple question: Why the bloody hell should I quit my current gig and come and work for you? Then put that answer in the job description.

Re:Yeah, now try hiring for it. (3, Informative)

Anonymous Coward | more than 3 years ago | (#34662250)

I've been a build engineer since the mid-80's. My first exposure to Perl was in 1989. The last line of Perl I wrote was in 2005. I spent a year deciding on which direction to go... Python or Ruby. I went with Ruby as my primary scripting language, and have brought Ruby and Rails into 5 companies to build engineering infrastructure. The reason I went with Ruby was due to its simplicity, power, DSL support, and Rails, and both the Ruby and Rails community. In Silicon Valley I found that when working with people that are coding in Java, they are in most cases going to script with a well accepted OO language like Python or Ruby. For me, both Ruby, Rails and their communities has had a huge influence on my coding and development practices.

Re:Yeah, now try hiring for it. (1)

Burnhard (1031106) | more than 3 years ago | (#34662336)

I have to maintain Perl scripts for our website (I'm otherwise a C++/.NET developer) and I have to tell you that I'm not surprised you can't find an engineer who actually wants to do it for a living. It's the kind of language only someone with Asperger's Syndrome could love.

Re:Yeah, now try hiring for it. (1)

bcrowell (177657) | more than 3 years ago | (#34663326)

Yeah, now try hiring for a good OO software engineer to write Perl. The applicant pool isn't spectacularly broad. Not too surprising, I suppose, since most of the positions out there featuring Perl are either QA automation or something titled "Build Engineer".

Well, I would say it's not too surprising for a different reason: perl 5's support for OO is ugly and bolted on, so anybody who's a real enthusiast for OO probably isn't using perl. Although perl 6 is designed so that OO isn't ugly and bolted on, perl 6 is still very much at the language-hackers-and-early-adopters phase, so it's not at all surprising that there are not a lot of people in your applicant pool using it.

I like perl 5, and I still do a lot of my programming in it. But realistically if OO is your thing, or if OO is the right tool for a particular job, then perl is the wrong choice. The right choice would probably be either python or ruby. Although ruby is still far less mature than perl 5, it's far more mature than perl 6.

The great reason to choose perl 5 for a new project today is the quality of the implementation. It's very efficient and has a very low incidence of bugs.

Re:Yeah, now try hiring for it. (1)

chromatic (9471) | more than 2 years ago | (#34666458)

... if OO is the right tool for a particular job, then perl is the wrong choice. The right choice would probably be either python or ruby.

If Perl 5's default OO is the wrong choice, how is Python's OO the right choice? Syntactic differences aside, they're the same system.

Re:Yeah, now try hiring for it. (1)

bcrowell (177657) | more than 2 years ago | (#34666596)

If Perl 5's default OO is the wrong choice, how is Python's OO the right choice? Syntactic differences aside, they're the same system.

Syntactic sugar is important. Another difference is that in python, ruby, and perl 6 everything is an object, but in perl 5 everything is not an object. I can see various design trade-offs inherent in the everything-is-an-object decision, but, e.g., in ruby one big benefit is that the namespace is clean and the structure of the libraries is very logical and easy to understand. Cf. perl 5, where basically you just have a ton of functions that are thin wrappers for everything in the traditional C/Unix toolbox.

Re:Yeah, now try hiring for it. (0)

Anonymous Coward | more than 3 years ago | (#34664048)

Yeah, now try hiring for a good OO software engineer to write Perl. The applicant pool isn't spectacularly broad.

I've always seen perl as a tool to assist one in quickly getting stuff in the done pile. When it comes to parsers, utility functions, converters, prototyping..etc sometimes a few lines of perl code is worth hundreds of lines of non-interpreted code. Time is money - knowledge of perl or another interpreted language with similar feature set is valuable especially when the main software development effort is not based on perl.

Re:Yeah, now try hiring for it. (1)

Greg Lindahl (37568) | more than 3 years ago | (#34664720)

Blekko's search engine and NoSQL database are written in Perl. We haven't had problems hiring experienced, smart Perl people, and we've also had no trouble getting experienced Python people to learn Perl.

Re:Yeah, now try hiring for it. (2)

hxnwix (652290) | more than 3 years ago | (#34664906)

Large OO Perl systems tend to be complex, slow sacred cows into which people who should have known better invest their careers. Arguing for total replacement of old VB applications is easy, but there is always great reluctance to rip out Perl messes. Only a desperate or foolish person would want to accept an invitation to someone else's Perl horror show.

Once the people responsible for the Perl disaster leave, it will be easy to find people interested in engineering something that isn't rubbish.

Ruby? Really? (1)

walterbyrd (182728) | more than 3 years ago | (#34665080)

Ruby has all the mindshare these days.

I think I've heard of Ruby. Wasn't that popular around 2005?

Seriously, all the mindshare? Really?

Re:Yeah, now try hiring for it. (0)

Anonymous Coward | more than 3 years ago | (#34675278)

Ruby has all the mindshare?

Um. Not really: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Perl (5, Funny)

emijrp (1754328) | more than 3 years ago | (#34661894)

The only language that looks the same before and after RSA encryption.

Re:Perl (5, Funny)

FooAtWFU (699187) | more than 3 years ago | (#34661972)

My favorite line of Perl code ever was in a validator somewhere. It checked whether something was a valid IPv4 construct (something netmask related, I forget the specifics) by passing it to the library, and seeing whether the library threw up or not.

return !$@;#%

Yes, the last 40% was purely gratuitous.

Re:Perl (0)

Anonymous Coward | more than 3 years ago | (#34662308)

Hilarious!

Re:Perl (1)

mvdwege (243851) | more than 3 years ago | (#34665016)

That's not a really ofuscated construct. If you know the common 1-character variables, then you know $@, as that is one of the most commonly used ones.

I like the sense of humour displayed by the programmer; but his joke is a bit misaimed, as it only reinforces the standard stereotype of Perl.

For the non-Perl programmers here: $@ is the variable holding the return code of the most recently called function. This return statement thus returns the boolean negated version of that code. The ; ends the return statement, and # is the commment marker, just as in C. The % is therefore a comment, creating the joke.

Mart

Re:Perl (1)

Pe_Ell (855470) | more than 3 years ago | (#34683338)

For mart and everyone else, $@ is populated by eval. So if an error occurs the error message is there. So what he describes would be like this:

sub check {
my $ip = shift;
eval{ &lib::function($ip) };
return !$@;
}

So if $@ is null it returns true. Otherwise false since ! is a condition operator. And they can do false by calling "die" in that lib::function. But yes, that is rather silly. I'm hoping they couldn't control the other code for some reason. :)

Re:Perl (1)

mvdwege (243851) | more than 3 years ago | (#34683760)

I simplified. Of course $@ is set by eval, but that requires a bit more in-depth explanation than I was willing to give.

Of course, this being slashdot, there'd have been someone along to provide that anyway. Thanks.

Mart

Re:Perl (0)

Anonymous Coward | more than 3 years ago | (#34746426)

The # character is not a comment marker in C. It is for many shell scripting languages, though. /* */ is for old K&R style or multi-line C/C++ comments, // for single line C++ (& newer C compilers)

Re:Perl (1)

Anonymous Coward | more than 3 years ago | (#34662180)

The only language that looks the same before and after RSA encryption.

In typical programming, when a comment block accompanies some procedure explaining
what that does, this comment is a short paragraph and the code - a bulky flowing construct.

Perl, on the other hand, is very dense and with many idiosyncrasies. For example:

# Count the number equal letters (in same positions) in two strings a and b.
$n =()= ($a ^ $b) =~ /\0/g;

There is another art characterized by terse, overloaded semantics, tenuous connotations.
It is called poetry. Not everyone can write poetry. Not everyone can read poetry.

Re:Perl (0)

Anonymous Coward | more than 3 years ago | (#34664088)

Flamebait? Maybe, but there might be some truth to it... and the comment above about Aspberger's.

Re:Perl (1)

after.fallout.34t98e (1908288) | more than 3 years ago | (#34664106)

# Count the number equal letters (in same positions) in two strings a and b.
$n =()= ($a ^ $b) =~ /\0/g;

outside of =()=, I find that code to be pretty simple:

($a ^ $b)

$a bitwise xor $b (thus the result contains \0 in each char that is the same)

/\0/g

regex looking for null chars in a string

($a ^ $b) =~ /\0/g

thus this returns a list of null chars

My guess is that this =()= set of operators causes the $n variable to be the result of the list evaluated in scalar context (resulting in the length of this list).

Indeed if you look closely you can see that that is 2 assignment operators and an empty list. You could rewrite it as:

$n = () = ($a ^ $b) =~ /\0/g;

thus:

() = ($a ^ $b) =~ /\0/g;

() = causes the regex to be matched in a list context. Had you straight up written $n=($a..., then $n would be given either true or false. It is slightly confusing that you are using the empty list as an lvalue, but then again this is perl. This empty list means you don't care about the matches, only that the matching is done in list context. The final assignment evaluates the resulting list in scalar context, returning the length of the list.

I would have written it as:

$n = ($a ^ $b) =~ tr/\0//;

because actual regex matching is not necessary here.

Re:Perl (1)

mvdwege (243851) | more than 3 years ago | (#34665024)

I'm always struggling with forcing context, but surely this could have been written as ($n) = ($a ^ $b) =~ /\0/g;? By parenthesizing $n you'd force list context, right?

Mart

Re:Perl (0)

Anonymous Coward | more than 2 years ago | (#34665846)

=()= is the goatse pseudo-operator. ()= causes assignment in list context from the RHS of the equal sign. Now the tricky bit is realizing that you can assign into an empty list, and that that assignment itself has a return value. List assignment in scalar context returns the number of elements on the RHS. So if we take $foo =()= (1,2,3), this breaks down into () = (1,2,3) wihich in scalar context evaluates to 3.

Re:Perl (1)

mvdwege (243851) | more than 2 years ago | (#34667380)

Oh bugger.

Of course you're right; the object of the given example is to have the final evalution in scalar context, to get the length of the intermediate list.

See what I mean about struggling with forcing context?

Mart

Re:Perl (2)

DrVomact (726065) | more than 3 years ago | (#34664710)

In typical programming, when a comment block accompanies some procedure explaining what that does, this comment is a short paragraph and the code - a bulky flowing construct.

Perl, on the other hand, is very dense and with many idiosyncrasies. For example:

# Count the number equal letters (in same positions) in two strings a and b. $n =()= ($a ^ $b) =~ /\0/g;

Yes, but you do not have to write it like this. You can choose a more readable, more explicit way to write this in Perl. I always try to avoid excessive cleverness when I write code; one reason is that I'll forget what it does, and have to figure out all over again. Trying to squeeze as much trickery as you can into a single line of code is just a kid's game.

Re:Perl (0)

Anonymous Coward | more than 3 years ago | (#34662606)

No, Malbolge [esolangs.org] would be a better fit for that. To wit:

The first "Hello, world!" program written in it was produced by a Lisp program using a local beam search of the space of all possible programs.

Re:Perl (1)

Xyrus (755017) | more than 3 years ago | (#34663686)

The only language where comic book swear words will beat you at tic-tac-toe.

Perl Golf (1)

goombah99 (560566) | more than 3 years ago | (#34664070)

If you don't know what perl golf is, time to treat yourself to some mind blowing perl. Perl golf is a challenge to complete a give set of algorithms in the fewest (key) strokes. Consider the Buroughs Wheeler algorithm, which is what bzip uses. How many keystrokes should that take to write? how about 55?
http://perlgolf.sourceforge.net/cgi-bin/PGAS/post_mortem.cgi?id=11 [sourceforge.net]

Mind blowing. Also informative as well.

I love perl. It has it's problems but I love how it's such a mutable language and how simple the core language is. It has one of the thinnest O-reily guides for a language that has Regex, Databases, and hashes built into it.

I never actually understood how objects actually work or the difference between a column and row database stucturce till I wrote in perl objects. The mind blowing thing to me is that to go from non-onject oriented perl to objected oriented perl, only two changes were made to the language: bless() and @ISA. it's uncanny that that's actually true for all languages. add those and your object oriented. This means for example, that you can start tommorrow writing object oriented fortran 77 just by implementing those two functions. If you don't believe me then you are like I was: you don't understand how object oriented programming actually works. And For those of you wondering: a row data base is the same as a perl object based on a blessed hash (how python does it behind the scenes) and a column database is a perl object based on a blessed scalar.

Anonymous Coward (-1)

Anonymous Coward | more than 3 years ago | (#34661898)

There's 2 minutes of my life I'll never get back

Troll FAIL (-1)

Anonymous Coward | more than 3 years ago | (#34661904)

Evaluator comments on your recent troll submission:

Summary: FAIL.

Details:

You have to use one of the key nouns or verbs in the title to get credit for a successful troll.

You passed up some very obvious double-entendres there and your attempt at subtlety with the RMS reference fell flat, lacking humor and lacking any legitimacy as a personal attack, both of which can give you points if executed well.

Remedial action: Go back and retake Freshman Trolling 101 and try again no sooner than the end of next semester.

meh (1)

Anonymous Coward | more than 3 years ago | (#34661924)

I use perl on occasion, I prefer it over php, python, ruby, whatever the language of the day is. But perl 6? Should have called it perl vista. Cleaning up some of the cruft and inconsistencies in perl was a good idea. It has 23 years of features added on. Instead, they managed to make it worse. Good job, guys.

Re:meh (1)

Ant P. (974313) | more than 2 years ago | (#34665686)

Since you're so sure of yourself, you should have no problem explaining what's worse about it, right?

I love Perl, but (3, Insightful)

Anonymous Coward | more than 3 years ago | (#34662000)

The thing that kills me about the Perl culture is that the delusions of what things mean to the non-Perl world.

This article is yet another example of that. Larry writes about Camelia representing so many points, which sound fantastic but are complete bollocks. Perl6.org, and specifically Camelia, do not say "fun", or anything about sterile environments or anything about clarity.

What it says is that in 23 years, the old Perl guard still hasn't figured out that making something that looks completely stupid makes people think you are completely stupid.

Everything looks completely stupid that comes out of Perl6.

Nobody really even knows what Perl6 is (even O'Reilly) and then randomly people point out Rakudo Star. This looks like the community is fractured (which it isn't, but it looks that way at a glance, which is all people are getting.)

I'm saying all this as a Perl hacker. I do love Perl, I think it's great, but all of this is basically turning Perl into something like Furries. The people involved seem to not think there is anything wrong, but every other person in the world makes faces at them.

I can't imagine being involved in that good thing Scala really is all those things Larry wishes Camelia represents.

Re:I love Perl, but (2)

chromatic (9471) | more than 3 years ago | (#34662032)

Perl6.org, and specifically Camelia, do not say "fun", or anything about sterile environments or anything about clarity.

I question this.

The argument that "No one will ever take a programming language seriously because it has a cartoon butterfly for a logo! Are you six years old?" says a lot more about the arguer than the logo or the language or the community. At least it suggests to me that I would not enjoy working with the person making that argument.

Re:I love Perl, but (1)

Anonymous Coward | more than 3 years ago | (#34662116)

Well, if that was actually what I said you may have a point.

Unfortunately that wasn't what I said, nor what I intended.

My point is simple: The Perl (specifically the old guard) community constantly puts out statements that only the Perl community understands or agrees with.

In this case, it's "Camelia represents fun, organic growth, clarity, etc." that is being proffered as a statement of intention. Camelia, like most Perl endeavors, fails to represent those things.

It completely astounds me that so many smart people can constantly fail to understand a point. If you put something that looks stupid out there, and say it represents all these things that it quite frankly doesn't, it makes you look foolish.

You guys are trying to be the artist and the art critic, and it fails. And everytime someone brings this up, they're scorned because they don't "get the message".

If you use dog shit for an envelope, nobody wants to read the letter.

Re:I love Perl, but (1)

chromatic (9471) | more than 3 years ago | (#34662182)

Camelia, like most Perl endeavors, fails to represent those things.

Perhaps to you.

Do you speak for everyone outside of what you've defined as "the Perl community"?

Re:I love Perl, but (1)

putaro (235078) | more than 3 years ago | (#34664712)

I'm outside the Perl community and I agree with him. Maybe you should get out more often?

Re:I love Perl, but (1)

chromatic (9471) | more than 2 years ago | (#34666258)

I'm outside the Perl community and I agree with him.

I'm sure some people agree with that sentiment. I don't agree that most or all people do.

Re:I love Perl, but (1)

FoolishOwl (1698506) | more than 3 years ago | (#34663998)

If you use dog shit for an envelope, nobody wants to read the letter.

Butterflies are widely regarded as more pleasant than dog shit.

Re:I love Perl, but (1)

Hognoxious (631665) | more than 3 years ago | (#34729286)

Given the large number of flies[1] that exist, I doubt that is actually true.

[1] the non-butter variety.

Re:I love Perl, but (2)

TimToady (52230) | more than 3 years ago | (#34662044)

The grinch detector seems to be working well here.

Re:I love Perl, but (1)

Anonymous Coward | more than 3 years ago | (#34662758)

Agreed. My first thought when I saw Camelia was: "That looks dumb, oh well." But when I first saw a post complaining about it I suddenly saw her as the most beautiful thing in modern programming. (Runner up: colon syntax used with closure arguments. JS needs this.)

Rambling, barely coherent, self-indulgent. (3, Insightful)

BitHive (578094) | more than 3 years ago | (#34662026)

I suppose I learned a lot about the Perl community though.

Re:Rambling, barely coherent, self-indulgent. (5, Insightful)

grcumb (781340) | more than 3 years ago | (#34662564)

I suppose I learned a lot about the Perl community though.

Larry may sound glib most of the time, but if you took the time to look, you'd see method in his madness. He chooses to make his points lightly, because that's an important part of the message. Perl as a language is designed to reflect the idiosyncrasies of the human brain. It treats dogmatism as damage and routes around it. As Larry wrote, it is trollish in its nature. But its friendly, playful brand of trollishness is what allows it to continue to evolve as a culture.

Strip away the thin veneer of sillyness and you'll see that everything I've written has been lifted directly from Larry's missive. Just because he likes to act a little silly doesn't mean he's wrong.

One of the worst things a programmer can do is invest too much ego, pride or seriousness in his work. That is the path to painfully over-engineered, theoretically correct but practically useless software that often can't survive a single revision. Perl as a language isn't immune to any of these sins, but as a culture, it goes to some lengths to mitigate against them.

Re:Rambling, barely coherent, self-indulgent. (1)

siglercm (6059) | more than 3 years ago | (#34665298)

Perl as a language is designed to reflect the idiosyncrasies of the human brain.

I call shenanigans. Did a quick Google search. The only page I could find using words vaguely like these to refer to Perl is this one. (Isn't Google amazing? It's already indexed this article thread....)

So, you're telling us that as Perl grew from a simple string manipulating scripting language, Larry built into its design syntax and methods which mirror the way programmers' wetware minds work? That is... grandiose... to say the least.

He may say TMTOWTDI, but he (apparently) doesn't say Perl is designed to play off of the brain's foibles...?

Re:Rambling, barely coherent, self-indulgent. (0)

Anonymous Coward | more than 2 years ago | (#34665892)

Larry is a trained linguist and he applied natural language principles [wall.org] to the design of Perl.

The interaction between the structure of natural language and the structure of the human brain/mind is a big topic in the realm of linguistics. Try googling for terms like Language Acquisition Device or Neurocognitive Linguistics.

Personally... (-1)

Anonymous Coward | more than 3 years ago | (#34662086)

I hack all my yogurt

Surprised nobody mentioned yet (5, Insightful)

toby (759) | more than 3 years ago | (#34662132)

That /. is written in Perl.

Re:Surprised nobody mentioned yet (1)

El_Muerte_TDS (592157) | more than 3 years ago | (#34662188)

And it was written by the other 999 monkeys. (The other one eventually wrote a Java program).

Re:Surprised nobody mentioned yet (-1)

Anonymous Coward | more than 3 years ago | (#34662382)

Ah, that would explain it!

Re:Surprised nobody mentioned yet (1)

Ant P. (974313) | more than 3 years ago | (#34663072)

I tried looking at slashcode once, out of curiosity. It's a scary dark place and I'm not going back there again.

Re:Surprised nobody mentioned yet (1)

ayvee (1125639) | more than 3 years ago | (#34663872)

That /. is written in Perl.

Ah. This explains a lot.

Re:Surprised nobody mentioned yet (0)

Anonymous Coward | more than 3 years ago | (#34665076)

and it's broken. a slow broken mess.

perl is 1/2 my age (0)

Anonymous Coward | more than 3 years ago | (#34662468)

Just noticing that perl is half my age. I imagine some perl hackers may be younger than perl.

stability and culture (3, Insightful)

e**(i pi)-1 (462311) | more than 3 years ago | (#34662508)

What I appreciate most about Perl and C is the stability and culture. It is not just a hype which _might_ be around in 10 years. It is one of the languages, which will persist, it is a language I can rely on, just because experience has shown me that. In a rapidly evolving time, it is good to have some things which persist.

Re:stability and culture (2)

ducomputergeek (595742) | more than 3 years ago | (#34663558)

When I first started working with this internet thingy, the options to do anything with user data was your choice of C or Perl. Then I moved on to PHP because that was what a lot of projects and people where using. That's what we did our rapid development of our web app in was MySQL and PHP. A lot of that had to do with the initial client and what they had available on their hosting server. Once the proof of concept was signed off on and we had our funding for the final production product we had the great debate. PHP was the early favourite, but then the question became "Which framework to use?" Ruby on Rails was what all the "cutting edge" folks were pushing for and a couple had mentioned Python. Well for every feature we wanted to create there already seemed to be Perl Module written for that. And some of the stuff was new at the time, like Twitter and FaceBook, yet there were Perl Modules already on CPAN. Plus as part of the long term plan was the requirement that eventually we'd likely be on DB2 and using something like Teradata for data warehousing. With Teradata, your choices with the other languages was ODBC or nothing. Perl had not one, but two DBI/DBD modules for working with Teradata.

We ended up writing all our SOAP and REST API's as well as other "backend" code in Perl. We transitioned from MySQL to PostgreSQL with changing a few dozen lines of code and still running on PostgreSQL for both transaction and data warehousing. It's been stable and fairly easy to maintain simply because once we got it finished, there hasn't been any major changes to Perl. As far as I know, those servers are still all Perl 5.8.x and run day in and day out processing thousands of orders for our clients per day.

The frontend client that most of our customers used was written in PHP. It required fairly extensive rewrite during the PHP 4 - 5 transition and then has required further modifications as a few functions were depreciated [Specifically split()] even from PHP earlier version of PHP to PHP version 5.3. Now that has been replaced by HTML5 + Javascript that talks to the Perl powered API.

Re:stability and culture (1)

Michael Meissner (520083) | more than 2 years ago | (#34665838)

I have perl scripts that date to 1988 or so (perl 1-2 era or 5 jobs ago). By and large most of these have worked over time, but in the mid-90's I did need to edit a few scripts to put a backslash in front of the @ inside of strings. Yes, in many of my .pl libraries, I haven't bothered to change creating variables on the fly and using *pointers instead of using refs and other modern mechanisms.

On one of the camera groups, I mentioned I had perl scripts to manage my images, from download to album creation to updating remote systems. I saw that in the 9+ years I've been doing digital photography, the support infrastructure has grown to 26,000 lines of perl, along with 20,000 lines of my support library.

Similarly, I automate building the GCC compiler, running spec, doing all sorts of tables of comparisons in perl. Most of these have been moved from job to job over the years. It was simple to transform the scripts I had for analyzing x86 compiler output code to powerpc as I moved from AMD to IBM.

I keep everything on my external web server, which supports CVS and ssh, and can update and edit files from any machine, both at work and at home.

Scary (3, Informative)

ornil (33732) | more than 3 years ago | (#34662776)

So I looked at the Perl5To6 Manual, and it gave me a headache. Really, I had to get some medicine just now. There used to be 10 ways to do anything in Perl 5, and in Perl 6 there's 20. And operators are approaching APL in obscureness and number. It has ways of being even more terse at the expense of the maintainer's head possibly exploding. Some changes are very nice and clean up some weirdness, but they compensated for it with a vengeance.

There's macros, and more contexts (where function returns different things depending on how its value is getting used), and meta-operators, and operator overloading on never-before-seen scale, and weird variant types, and ways to embed an enum into any object, even more complicated regular expressions, and so on ...

your a noob if you dont answer in perl compilable (0)

Dan667 (564390) | more than 3 years ago | (#34663246)

!#//bin/local/perl

Re:your a noob if you dont answer in perl compilab (1)

hcs_$reboot (1536101) | more than 3 years ago | (#34663832)

!#//bin/local/perl

Unless I missed the funny part of your message, that line is actually interpreted by the shell.

Re:your a noob if you dont answer in perl compilab (0)

Anonymous Coward | more than 3 years ago | (#34664974)

Dumbass.

Misleading, Perl 6 is NOT available, not done yet (2)

ziggyzaggy (552814) | more than 3 years ago | (#34663554)

Perl 6 spec is still in development, not done yet. Rakudo is an implementation of something that is not done yet, and pugs even less so. Anyone who uses this for any remotely production related is insane. Face it folks, Larry killed Perl.

Re:Misleading, Perl 6 is NOT available, not done y (1)

Ant P. (974313) | more than 3 years ago | (#34663778)

Go ahead and whine all you want. We'll be right over here using the language you pretend doesn't exist.

Re:Misleading, Perl 6 is NOT available, not done y (1)

ziggyzaggy (552814) | more than 3 years ago | (#34691166)

oh, it exists all right. But unusable for serious work, no one is going to hire me to develop in Perl 6.

Not whining, I've done plenty of Perl 5 development over the last 20 years. Sorry to see Larry try to turn Perl 6 into mutant Swiss Army Knife with fold-out condom and umbrella and eggbeater and cuckcoo clock.

the guts of a thousand whales fed through a wood chipper....

Re:Misleading, Perl 6 is NOT available, not done y (1)

DrVomact (726065) | more than 3 years ago | (#34664740)

Perl 6 spec is still in development, not done yet. Rakudo is an implementation of something that is not done yet, and pugs even less so. Anyone who uses this for any remotely production related is insane. Face it folks, Larry killed Perl.

I usually do not use the very latest version of anything on a critical project. The only reason to do this is if the new version has a feature you absolutely cannot do without. Even then, you should be aware that you're taking a big risk. I'd wait for it to age a bit, and maybe use the last known stable version, while other people try out the new stuff. That being said, I find your comment to be a bit on the panicky side. It's a bit early for an obit on Perl.

Perl sadly out of fashion, politically incorrect (2)

wdef (1050680) | more than 3 years ago | (#34664946)

In some circles. I *like* Perl. I work non-coding with experienced C/C++/Javascript/OoP developers. These are desktop/UI programmers mainly with some server side. They use and expect fluency in Python, which I don't know much. Perl OTOH I know quite well. The head programmer knows no Perl. Mentioning that I like and know Perl is like ... well it's just totally irrelevant. Those on the team that know Perl keep quiet about it. Perl seems to be politically incorrect and by default and without trial held to be wrong for it "unreadability". Besides it's not Python is it.

ah, Perl (1)

t2t10 (1909766) | more than 3 years ago | (#34671640)

The language that was better than awk+shell. Didn't have much more going for it than that.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...