Ask HN: Is Perl dead? - <AUTHOR> I've been noticing that Perl doesn't get mentioned that much anymore in articles, blog posts, HN threads, etc.
A current example is the "Who's hiring" thread which is now on HN: Most of the requirements are C/C++/Java/PHP/Python/Ruby, and almost none are for Perl.
However, this is not just about hiring. In almost anything I read, there is barely a mention of Perl anymore.
FYI, I use Perl extensively for text file parsing and processing, and I'm not familiar with Python or Ruby, but it seems that these two languages are "winning the war" against Perl (although I assume some of you may dispute that these two languages are even comparable to Perl, for a variety of reasons)
Is my general observation correct?
Will Perl 6 be able to turn things around, or is it too late? <comment><USER2> (Second try at this)

First, anyone who says that Python or Ruby is not even comparable to Perl is full of it or very mistaken. They are close enough that we quickly run into the narcissism of small differences [1].

Second, in my experience HN ranges from uninterested to hostile when it comes to Perl. I read lots about Perl, but many of the blogs or forums I frequent are Perl-centric. My point is simply that you shouldn't judge by "what you read" if what you read is a function of what you choose or who you follow.

Third, and most importantly, the Perl5 community doesn't seem anywhere near dead. Off the top of my head, I'm particularly happy with a slew of new tools for working with Perl and CPAN: cpanm[2], perlbrew[3], cpan-outdated[4], pmuninstall[5], cpansearch [6] (written in C, but obviously made for the Perl community). There's also Plack[7] for modern Perl webapps. Finally, consider the whole Modern Perl[8] movement.

[1] <http://en.wikipedia.org/wiki/Narcissism_of_small_differences>

[2] <http://github.com/miyagawa/cpanminus>

[3] <http://github.com/gugod/App-perlbrew>

[4] <http://github.com/tokuhirom/cpan-outdated>

[5] <http://github.com/xaicron/pm-uninstall>

[6] <http://github.com/c9s/cpansearch>

[7] <http://plackperl.org/>

[8] <http://github.com/chromatic/modern_perl_book>

<comment><USER3> For a while, maybe 5+ years ago (7? I can't remember clearly) it seemed like Perl was stagnating a little. This was about the time Ruby really seemed to take off, and some neat Python projects appeared (e.g. Gentoo Linux).

Now, even though the core language hasn't changed, there seem to be all sorts of clever Perl modules appearing which take advantage of a lot of Perl's highly flexible nature.

I really like Ruby myself, and really hate Python (even though I have to use it at work) but when the other languages fail me, I can almost always turn to Perl in a pinch and get it to do what I want. I also have to admit that the potential power of Perl6's syntax is a little astonishing; I think I would pick Perl6 over Ruby, for example.

<comment><USER4> > really hate Python

Why?

<comment><USER5> I can't speak for him, but it looks a lot like my pre-code scribbles. As someone who takes pride in being a fleshware translator of pseudo-code to real-code, I feel indignant at the sight of executable, Englishy specification.

High praise or a heavy put-down?

Also, I seem to hold the Guy Steele languages in highest regard, and consider the rest passable toys. C, Common Lisp, Scheme, Java, Fortran .. somehow they feel _real_. You crack open the spec and you're quickly welcomed into an intelligent dialog with the best minds in systems programming. I read several chapters of the Java spec last night and learned more about the language in one night than weeks of "googling" Ruby. The GSL-school of specification is precise, uses a well established vocabulary, and explains the syntactic and semantic rules of the language, along with their required execution environment. Not a word is said about add-on packages, installation crap, compiler internals or how to fork the language on github.

Compare these two and see what I mean:

<http://docs.python.org/reference/index.html>

[http://java.sun.com/docs/books/jls/third_edition/html/j3TOC....](http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html)

See how much more detailed the Java specification is; although the language has more features, the spec manages to be much more succinct and precise. The Python spec is littered with references to "CPython" and the internals of an specific compiler.

<comment><USER6> You are the first person I've encountered that thinks ill of the fact that Python reads like pseudo code.

In my mind, it does it in a way that remains succinct and strict, thus avoiding the abomination of "enlishy" code (AppleScript, SQL to some extent, etc.)

<comment><USER5> It was an earned compliment, given in reluctance.

</comment></comment></comment></comment></comment></comment><comment><USER7> No, it isn't dead by a long shot. We're just busy doing stuff. Core development (including the release frequency) has been more active than it has been in years. Most of the new developments happen around things like Catalyst and Mojo (Web Frameworks), Moose (OO and Meta-OO), Plack (Web Application Deployments), KiokuDB (Object-Graph storage), syntax extensions, Dist-Zilla (release management) and others. The testing and documentation "movements" are still strong and getting stronger. The toolchain is still being improved (telemachos named a few good examples). If you want to take a look at what the community is doing, I'd suggest reading the IronMan planet at <http://ironman.enlightenedperl.org/>

</comment><comment><USER8> There aren't many people using Perl for web applications, but there's lot of other (and in my opinion, more rewarding) work being done in it: email security, bio-informatics, "devops" (infrastructure as code) tooling. In addition, from what I know, Amazon still uses it extensively. Generally, however, these jobs (e.g., my last one in an email security company) usually combine Perl and C/C++ rather than being purely in Perl.

That being said, Ruby is close enough to Perl to where it would not be difficult for you to pick it up and in all likelihood you'll actually enjoy it (especially if you're been writing clean, object oriented Perl). If there's a Ruby-based job that interests you, go for it.

I personally, "moved on" (for non-trivial personal projects) onto Scala and OCaml: I actually like static typing (when there's type inference to reduce verbosity) and the mixed paradigms and "terse syntax" in these languages appeal to my Perl hacker DNA. The fact they're also blazingly fast means I don't have to "go down" to C++ (really, not all that hard in Perl with XS): the scalability of these languages (being suitable to whole variety of tasks, from simple scripts, to full systems) also appeals to me.

<comment><USER9> My experience is nearly the opposite, Modern Perl for me is a wonderful language to write web applications in. Nearly everybody I speak with regularly is developing some web based application in Perl. Then again thats what I do for a living so my glasses are definitely rose tinted.

Sites like the BBC iPlayer system, and Omni Hotel's booking application are large public examples of Perl applications, Magazines.com is another. At the smaller end of the fence I worked on ParkingMobility.com, a REST system written in Perl with multi-platform clients (including iPhone), was written using Catalyst and the KiokuDB Object Persistence engine.

You have moved on, but so has Perl. Moose for example has had heavy influences from OCaml, Scala, CLOS, Smalltalk, and others. It provides anywhere from "some" (Moose has Type Constraints but not inferencing for example) to much if not more (Moose's implementation of Traits can provide state unlike Scala's from what I know) of the features of other languages.

The rivalry between Perl5 and Perl6 means that more and more of these features will be expressed. For example, I've seen some proof of concept code for implementing Moose's type system at the core language level (my Int $i = 'One'; # boom!). With a properly motivated hacker and the right direction this could turn into an excellent dynamic type system, or even a semi-static system similar to the one Perl6 is implementing. Having this kind of a type system makes lot of Web programming tasks much simpler to implement (and eliminates a whole range of security holes).

The current momentum in the community has me very excited for the future of Perl.

</comment></comment><comment><USER10> _FYI, I use Perl extensively for text file parsing and processing_

Yeah, me too, but that's the issue. It's great at that. Great at quick and dirty command line hacks. Hell, most of my PhD code was written in Perl. (Something I take a perverse satisfaction in.)

But it's not great for rapid webapp development, it's probably harder to hire people, there are fewer libraries and interfaces and open source toolkits, etc - so people like me moved from Perl to Python (it's a really easy jump).

I still use my old perl scripts now and again, but even for quick and dirty stuff I tend to use Python - just in case I want to come back to it later and have a chance of understanding what the hell I wrote. :)

(Aside: One of my summer internships was on the web backend team at my university's Engineering lab. We wrote an object oriented student class administration system, in Perl. It was quite probably the most hideous piece of software engineering I've ever seen...)

<comment><USER11> > from Perl to Python (it's a really easy jump)

I disagree. Python is _incredibly_ restrictive when you're used to perl. I would be so frustrated if I went that direction.

<comment><USER12> Odd. Around 2004, I switched from Perl to Python for all the same tasks, and I barely noticed: it was a matter of weeks before I was just as fluent in Python as I had been in Perl. What's your experience been like?

<comment><USER11> I went from python to perl, I'm just imagining based on what I know of each.

</comment></comment></comment></comment><comment><USER13> For what it's worth, a quick search on dice.com gives the following:

      - perl: 4448 results
      - python: 1988
      - ruby: 1087

So I don't know... apparently there are still many jobs out there that require Perl. It may be that people use it less for new projects, though.

<comment><USER14> Here's a graph with postings for jobs.perl.org from jan/2002 to aug/2010:

<http://bit.ly/bFuh7x>

(source <http://jobs.perl.org/about/stats>)

<comment><USER15> Look like Rails took a big bite out of Perl jobs?

<comment><USER16> In 2008? I can think of other explanations for a drop in hiring around then.

<comment><USER17> Hey, wasn't that the year the economy started to go south? .... Obviously, people stopped employing people in Perl, and the economy took a steep dive because of it!. Use Perl! Save the economy!.

( nb. for people with no sense of humour, this was a stab at people who don't understand that correlation != causation )

<comment><USER15> Calm down guys, I counted the years wrong - I thought the drop was taking place in 2006-7, when Rails was growing quickly. Also, it was a guess, which was why I used a "?"

</comment></comment></comment></comment></comment></comment><comment><USER18> "Dead perl" reminds me of when Bill Clinton said "you just don't get it" to Bush 41. Essentially meaningless, yet devastatingly true.

So, some interesting tidbits to add to this "conversation":

1\. Perl developers are older (on average) than those of other trendier languages. They were there at the dawn of the web. They are more experienced. They are also less expensive. But who wants to be an old-timer who gets paid less?

2\. There is a negative feedback situ between developers choosing what technology to learn based on what companies are running on, and companies choosing a technology to run on based on what developers are learning. This sort of tragic loop is a social cancer which takes leadership and risk to overcome.

3\. CPAN completely kills the competition. It might have something to do with perl, but it doesn't matter. This thing is outstanding, one of the 5 best things in software engineering... period. If you don't get this, you are deluding yourself and need to take a closer look at it.

4\. Perl6 is going to blow the doors off the hinges because it is even more hacker-friendly than perl5 (which is ludicrously hackable).

5\. Perl is dead to you.

</comment><comment><USER19> Perl 5 is mature, and Perl 6 is pre-release, but they're different languages with the same name for branding purposes.

Perl 6 is a really promising language with tons of cool features, and some similarities to Perl 5. It will pick up hype when it's 100% finalized, even though you can use it now.

Perl 5 (popularly known as "Perl") is old enough to be on the other side of "cool", but it's a perfectly good language, especially if you use CPAN.

<comment><USER16> > Perl 6 is pre-release...

Rakudo Perl 6 has had _34_ releases.

> It will pick up hype when it's 100% finalized....

That must be Perl 5's marketing problem then, because it's not finalized either.

<comment><USER19> Wikipedia: As of 2009, multiple Perl 6 implementations are under development, but none are considered "complete". As noted in the history section the language design itself is still subject to change. No implementation will be designated as the official Perl 6 implementation; rather, "Perl 6 is anything that passes the official test suite."[12]

If that's changed, you should probably go update that. "Pre-release" is generally understood as a synonym for "not complete", right? There's no complete, finished implementation of the Perl 6 spec, right? Is the spec itself finished?

It's like you can't say _anything_ about Perl (either one) on Hacker News, not even mildly complimentary things, without someone jumping on perceived slights.

<comment><USER16> > If that's changed, you should probably go update that.

If that weren't against Wikipedia policies, I would. Then again, I don't consider Perl 5 "complete" either, whatever "complete" means.

> There's no complete, finished implementation of the Perl 6 spec, right? Is > the spec itself finished?

No to both, but why does that matter? There'll be a Perl 6.1 spec and a Perl 6.2 spec and so on. Meanwhile, people who find a Perl 6 implementation usable for their purposes will use it and people who don't won't. Fortunately, every release is more usable to more people.

As for "pre-release", I don't believe in playing linguistic existential games. Software exists or it doesn't. You've released it or you haven't. It does something or it doesn't. Perpetual betas and alphas and pre-releases and unstable versions and (even) release candidates are for people who lack the courage to release good software.

As for "perceived slights", insinuating that Perl 6 doesn't exist or isn't useful because the spec isn't "complete" (whatever that means) or no single implementation is "finished" (whatever that means) or no one has said "This particular release of this particular implementation is stable for every domain and every purpose and everyone who might ever want to use it" is awfully silly and (in my mind) deserves a challenge.

<comment><USER19> You're being evasive, which is equal parts amusing and irritating. Maybe Perl 6 is an exercise in deconstructing the concept of a software product ever being done?

As long as the official language specification refers to Perl 6 in the future tense, I will as well. Take it up with Larry Wall.

For those of us who don't play linguistic existential games, BTW, Perl 5 has been "done" since 1994. I think most of us recognize that you can continue maintaining and updating software after it's done/finished/released. It appears the Perl 6 community has been innovative in the discovery that you can release software before it's done or finished and go Derrida on someone's ass for implying that an incomplete implementation of a draft specification is, in fact, incomplete.

<comment><USER9> And yet, the fine people on p5p keep making changes to something you're trying to claim is "done". You suggest elsewhere that "done"ness is a 100% thing. If Perl5 keeps changing, and it was 100% done in 1994 ... something is really inconsistent with the universe.

chromatic's pedantry is a symptom of people like us ignoring the fact that even a language like TeX will only be done when the author decides it's done (Knuth's death for example). That and he's a grumpy-butt sometimes. Perl6 is a fully-functional language in that you can write useful (for some value of useful) scripts in it. The specification is undergoing radical changes, but then as I've pointed out the Perl5 specification is undergoing changes that some consider "radical" (if you doubt this, read threads on perl5-porters sometime ... look up the debate(s) about the "feature" pragma).

Valid complaints about Rakudo being an unfinished implementation of Perl6 are better centered around things like it doesn't pass 100% of the Spec tests yet. The Rakudo developers will (I'm pretty sure) own up to this, and point to the fact that they're working hard on it and that patches are welcome. That doesn't mean that Rakudo * was in some way "Pre Release". I don't recall anybody using the term "Pre" when talking about the Rakudo * release. The terms I remember are "early", "useful", "useable","for developers". If we as non-members of the Perl6 community go about continuing to imply that Perl6 is somehow less than released in a way for developers to generate useful and usable applications, we're gonna have the grumpier members of the Perl6 community call us on it.

It looks to me like you have a unique opportunity to contribute most effectively to Perl6 moving from being what you consider pre-Released to Released. You can submit a doc patch to change the tense in the Perl6 documentation.

<comment><USER19> I _did_ say, "I think most of us recognize that you can continue maintaining and updating software after it's done/finished/released."

Whether a software project is release-quality or not is a rather basic concept to everyone else. It can be intellectually tempting to try and deconstruct these basic concepts, but more often than not it's an exercise in evasion rather than illumination. Perl 6 (or Perl 6.0.0 for the pedantic) is a work in progress--at some point in the near _future_ , the spec and implementations will be "done" to a point where everyone will agree that this is Perl 6.0.0, every implementation that matches the spec and passes the tests is Perl 6.0.0, and work will begin on Perl 6.1. Perl 5.0.0 reached that state in the _past_ \--16 years or so in the past to be precise. There's a distinction here that's dishonest to evade.

If the Perl 6 community is more interested in using linguistic evasion and deconstructing the concept of the finished release more than they're interested in actually making a finished release though, I'd best leave it to them. Maybe this is what Larry Wall meant about the postmodernism. Who knows? My mind is still blown by the observation that you have to doubletalk your way around the idea that Perl 6 hasn't reached 6.0.0 final yet.

<comment><USER16> _It can be intellectually tempting to try and deconstruct these basic concepts...._

I'd like to see a unified theory of version numbers while you're at it. It'd be nice to account for Ubuntu, OpenBSD, Mplayer, Microsoft Windows, Mac OS X, the Linux kernel, and TeX at minimum. After that, care to decipher what "beta" or "alpha" or "pre-release" means?

 _If the Perl 6 community is more interested in using linguistic evasion...._

I'd take your argument at all seriously if it were more honest, say either "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" or "It shouldn't have taken ten years to release Rakudo Star." Those are debatable positions.

Arguing "But it doesn't _really_ exist because you didn't releeeeeeease- release a fiiiiiinished-finished version!" is precisely the epistemological- linguistic ticky tackery you claim to decry. Even so, it matters not at all in the real world because there will be a new release next month and the month after that and the month after that ad utilitarian, and you're welcome to use it at any point when it's useful to you.

<comment><USER19> _I'd take your argument at all seriously if it were more honest, say either "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" or "It shouldn't have taken ten years to release Rakudo Star." Those are debatable positions._

Actually, I clarified what I meant in a previous post, when I characterized Perl 6 implementations as "incomplete implementation[s] of a draft specification". I didn't say it didn't exist, just that it exists in a non- final, pre-released state. Some people call them betas, some people call them release candidates, some people call them pre-release, and you try to cleverly evade the fact that every Perl 6 implementation is an incomplete implementation of a draft spec, but a rose by any other name and so forth.

I actually expect that some Perl 6 implementation will meet a finished 6.0.0 spec within the next 5 years. But none does currently. Which is a roundabout way of saying "it's not done yet", which is apparently doubleplusungood to state so directly.

I got into this trying to say good things about Perl. I guess you've shown me the error of my ways. If I'm going to have everything I say about Perl on Hacker News trolled by defensive Perl fanbois, I might as well trot out the old "explosion in an ASCII factory" joke again.

Edit: The problem is, you're seeing criticism where there was really none there. All I made was a statement of fact--Perl 6 isn't done yet. I've even clarified what I meant by "not done yet"--the spec is draft and the implementations are incomplete even against that spec. I think that's a reasonable definition of "not done yet", don't you? I never said anything about how long it's taking or whether implementation and spec will ever meet, you just projected those criticisms onto me because you're defensive about the issue. That's bad faith. Fuck, man, I even said Perl 6 would be done in the near future! How the hell do you get from that to projecting "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" onto me? Are you even reading my comments or am I talking to myself here?

<comment><USER16> _... you try to cleverly evade the fact that every Perl 6 implementation is an incomplete implementation of a draft spec._

Nonsense; even the release announcements say that directly.

 _All I made was a statement of fact--Perl 6 isn't done yet._

I wouldn't have objected if you'd written that. Characterizing software we've released on schedule for almost three years running as something thrown out in the world incomplete, ahead of an "official" release (whatever "official" means) is, I believe, incorrect and unhelpful.

<comment><USER19> I think we got 2 posts in before I clarified that's what I meant by "pre- release", and here you are still objecting a day later.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> I'm surprised nobody has provided this link yet.

Perl is Dead. Long Live Perl. [http://www.oreillynet.com/onlamp/blog/2007/08/perl_is_dead_l...](http://www.oreillynet.com/onlamp/blog/2007/08/perl_is_dead_long_live_perl.html)

It's an essay from 2007, but I think it's still relevant today.

</comment><comment><USER21> Hmm... define dead? I see a lot of cool programming concepts and computer science coming together in Perl 6- too much for me to know how to use it effectively or rationally. To me Perl is going from terse parsing and glue language to something more like Haskell- I don't think of Haskell as dead just because it's not used as a quick scripting language- I assume Haskell will keep creating cutting edge stuff that eventually filters down into "lesser" languages.

Now, on the other hand, if I had actually taken the time to become a Perl monk, and good grasp enough of the awesome stuff coming down the line and know exactly how it would fit into real-world problems- Perl wouldn't even be close to dead to me. I'm sure there are a lot of people out there that are in that group. I'm jealous but not quite enough to actually try to get up to speed on it.

If it's not dead to you then I would recommend having no hesitations using it. It'll certainly be supported, and libraries... I mean, I don't know of anything that comes close to touching CPAN yet (dunno how Perl 6 fits in there). For me, though, it's dead as an alternative unless I see something amazingly compelling that I can't get elsewhere without similar learning investment.

</comment><comment><USER22> I blogged about this on my use.perl.org/~scrottie blog. Perl's supply lines have been cut: grade school language courses don't teach it; those teach Flash, Squeak, and other things. High-school age hackers go for things like PyGame. College classes teach Java or Microsoft technologies, depending on who they're getting money from (sadly). Only a couple of Universities still teach Scheme as part of SICP. Self-taught Web programmers go the low road of PHP or Ruby for the high road. There are companies that use Perl but the work tends to be maintenance (which no one wants to do) or else they hire small, crack teams of experienced Perl programmers, not bothering with trying to invest in novice or intermediate programmers.

Perl launched to fame by being able to talk to a bunch of databases and being easily (for the time) bindable to binary libraries, as well as having great low level access to the OS, as well as being a direct upgrade path for sed, awk, bash, csh and so on. Now people don't care about upgrading old shell scripts and don't understand awk's idioms, sadly -- everyone wants yet another C, and every other language talks to the various databases and binds to C libraries just as well plus have better toolkits for creating games.

Perl 5 is dead in the sense that COBOL is dead: all of the work is maintenance work; there are no entry level or intermediate positions; experts can still find work and will be able to for a long time.

Perl 6 does lots of great stuff but that alone isn't enough. Without a PyGame, Rack, and lots of other pieces, it's just a neat language design. Whether Perl 6 kicks ass very much still depends on where people take it. In a very real sense, Perl 6's success depends on _me_. I need to port Continuity to it (and its native coroutines!). I need to take more features from Seaside and show them off. I need to play with SDL stuff and make good abstractions. Busy, busy, busy!

-scott

</comment><comment><USER23> The bad news is that Perl isn't dead for sure. Languages tend to stick around for a while.

For myself, I regret all the time I've spent learning and using it. Perl and C++ are languages for those who don't know better. I know because I've used both extensively. Powerful text handling facilities? Perl? You are kidding: Emacs Lisp burns it with a blow.

Now down-vote me like ants gone mad. If you have less than ten years of experience "struggling" with code, and you haven't learned a bunch of languages beyond mainstream ones, then you just can't understand.

> A current example is the "Who's hiring" thread which is now on HN: Most of > the requirements are C/C++/Java/PHP/Python/Ruby, and almost none are for > Perl.

C/C++/Java/PHP/Python/Ruby? Really? I was expecting HNers to be a little more innovative.

<comment><USER24> > C/C++/Java/PHP/Python/Ruby? Really? I was expecting HNers to be a little > more innovative

Care to explain?

<comment><USER23> Sorry. I should have deleted Python, Ruby - and maybe PHP for close to the metal web programming - after having copied the line. Regarding C/C++/Java, I was expecting HNers to prefer more agile languages and/or exploiting some other language's features to gain a competitive advantage.

<comment><USER25> PHP isn't low-level; it just makes you do everything yourself.

<comment><USER23> I thought it was low-level because I've read its frameworks tend to be faster (CodeIgniter comes to mind).

</comment></comment></comment></comment></comment><comment><USER26> > Will Perl 6 be able to turn things around, or is it too late?

Community plays a large role here, I think.

The Perl community (both 5 and 6) overall has a practical can-do attitude. This attracts users.

Perl 5 seems to have more grumpy (though still helpful) users.

Perl 6 has Larry and lots of courteous, friendly, and helpful users. It's a community you want to be a part of.

The Python community has a "no, you're wrong -- that's not Pythonic" feel to it which I think turns a lot of users off to Python.

So, I think Perl 6 does have a chance. Personally, I'd probably be more on- board with Perl 6 if it didn't look so darn complex.

</comment><comment><USER27> It is a very useful tool that serves many needs.

It isn't "dead" anymore than the Norwegian language is "dead".

It might just not be your first choice for your next project.

<comment><USER28> > It isn't "dead" anymore than the Norwegian language is "dead".

It's just pining for the fjords?

Kidding aside, it still does well here:

<http://www.langpop.com/>

Although if you put Ohloh and Freshmeat at 0, it does significantly worse.

</comment></comment><comment><USER29> Duck Duck Go has a lot of perl in it, and it's a somewhat trendy discussion topic on HN.

I think most of the reason we don't care is because DDG's strengths have nothing to do with Perl -- except for maybe how easy it is to deploy/keep running and regular expressions.

</comment><comment><USER30> Most of my friends in bioinformatics still use Perl extensively, and it's the primary language in a couple of QA groups I know people in. I don't know that it'll ever be "hot" again, but it's certainly still a production language.

</comment><comment><USER31> Language is a tool. Certainly, some people will create literature and others are merely hacks. Some languages will be conceptually cleaner, some more pure, and some an amalgam of expressions "borrowed" from other languages.

No, Virginia, Perl is not dead. Not as long as there is more than one way to do it, or a hacker trying to finish something that was due yesterday.

Perl, as we know it, might pass from this earth. But the spirit it embodied, that first we should use duct tape to build on the work of others then write glue to make it stick, that getting-things-done was the primary goal --- this is too close to the core of our restless selves. A thousand years from now, there will be some startup somewhere with an urgent need and a hacker that strokes his chin and says, "I think I could write that in Perl[1]..."

[1] replace "perl" with your favorite language. Pick the right tool for the job. Sometimes means "the tool you are most familiar with", but that says more about you than about the language.

</comment><comment><USER32> If perl is dead, could you please stop having threads about whether it's dead every month? TIA.

</comment><comment><USER33> amongst webapp developers, yeah. But amongst SysAdmins? Python still has a long ways to go before it reaches the stability of perl, though it's gaining. Also, CPAN is awesome. I don't know of another language that has a cpan-like tool that measures up to CPAN.

SysAdmins are slow to discard a good tool; hell, some of us still use bash. Perl 5 has been dominant for most of my career in this arena, and things will be quite slow to change.

I do see that Python is beginning to replace perl in the places where perl5 replaced bash in the earliest parts of my career... I remember back in the late '90s it was common to maintain two versions of perl on a system. Now, perl5 is stable... you almost never need more than one version of it, but I see systems (especially RHEL systems) with more than one version of python (sometimes more than two. Gah!)

<comment><USER2> _hell, some of us still use bash_

As opposed to what? (Do all the cool kids now use zsh? That's my best guess.) Bash just had a major release, as well as a point-upgrade to that. How is Bash now a poster child for out-of-date good tools that people won't let go of?

<comment><USER34> I suspect that the grandparent meant "write shell scripts".

<comment><USER2> Duh (aimed at myself). Right, sorry. Whew. I got scared there for a minute that I was so terribly behind the times (insofar as I still use Bash as my primary shell).

</comment></comment></comment></comment><comment><USER35> My thoughts... coming from someone who has been working with Perl for basically a decade at various companies, and have had the pleasure of working with Perl experts like Tim Bunce (author of DBI) and Randall Schwartz (author of various Perl books, including the camel book).

a) Perl was used for EVERYTHING web-related in the early 2000s, but other languages and tools have come around to supplant it.

Several commenters have already said, "oh man I had to deal with this legacy perl code and it was awful," and yeah, that's a common experience and makes them think, "Perl is a terrible legacy language, I can't wait to trash it on my Ruby mailing list tonight." The negativity propagates and then people like you wonder, "is Perl dead?"

b) Web frameworks are one of those tools where frameworks like Rails and Django have all the hype. If you want to whip up your startup idea into a minimum viable web application, the trendy choice is Rails or Django. I've used Perl web frameworks like Catalyst and I'll be the first to admit banging out your "It's like Facebook... But For Cats!" startup idea is a lot faster in Rails or Django.

c) As Steve Yegge said in one of his blog posts:

'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.'

In my experience (which of course is just as anecdotal at Steve's), this is very true. Zed Shaw writes yet another blog post blasting whatever technology crawled up his ass and died, and we just smirk and update our modules on CPAN. But while that means we're not getting caught up in the "narcissism of small differences" (to refer to an earlier commenter), it also means we're not part of the noise on the web. There will probably never be a "Perl is a Ghetto" blog post written, and while that's obviously a good thing, it can also lead to the perception that, "man, nobody's talking about Perl, nobody's even bashing Perl, is it dead?"

d) That said, in my opinion these languages don't hold a candle to Perl when it comes to back-end engineering. We love talking about startups here at HN and thus, we talk a lot about startup problems and their solutions. But if your startup actually grows into a real company, you're going to encounter problems like, "we need a system to allow our analysts to manage our SEM campaigns and reconcile our cost and revenue" or "this partner doesn't have an API so we need to spider their interface to get the daily data and import it into our data warehouse." And any company that dismisses Perl as an option for those problems just because of (a) (b) and (c) is doing their company a disservice.

TL;DR -- Perl's strengths don't match the trendy topics on communities like HN, but it still has real value for real business problems.

</comment><comment><USER36> I would say that it is absolutely not, at least in my experience. In my lab, which is a bioinformatics lab, perl is still being used heavily. Perl is a great tool for dealing with text files, and little pieces of code that you need to do something quick.

</comment><comment><USER37> Read the following and stop asking:

<http://www.modernperlbooks.com/mt/index.html>

</comment><comment><USER38> There are some big and new projects in Perl out there (BBC iPlayer for one – which is an enormously high-traffic site).

The real issue is that a language dies when new people stop learning it. Python's the language-du-jour of programming education (and has a strong position in science as a Matlab replacement, thanks to Numpy), Ruby's got Rails to give it momentum, PHP has Wordpress and Drupal as gateway drugs, Clojure and Scala are the JVM's great hopes, F# is the CLR's, and C#, Java and C++ will give you access to a lot of jobs.

Where are the new Perl programmers – in bulk – going to come from?

<comment><USER16> > Where are the new Perl programmers – in bulk – going to come from?

The world of non-programmers, same as always.

</comment></comment><comment><USER39> Perl was the first programming language that I really liked using. Before perl i had programmed in basic and pascal and that wasn't very fun.

One of the best aspects of perl is the rock solid runtime, they have really gotten that right. Many of the newer languages like java, python & ruby have VMs that turn belly up after a varying amount of time, but perl just keeps running.

I prefer coding in ruby or clojure and I don't really like the object orientation syntax in perl. I'm looking forward to try out perl6.

<comment><USER7> You might like Moose (<http://search.cpan.org/dist/Moose/lib/Moose.pm>). It's built on top of--and is compatible with--plain Perl OO, but provides a whole lot more and has grown a nice, big community. There's more information (presentations, articles and stuff) on <http://moose.perl.org/>

</comment></comment><comment><USER40> The Perl jobs mailing list frequently has a dozen or more jobs internationally a week. I'd say no, Perl is far from dead, despite it not having the sexy factor it once did.

</comment><comment><USER41> I also use Perl (5 of course) for text processing but also for some binary file modifications. Just for playing with algorithms I use Python. I still wouldn't like to have to use the "wrong" of them for the given purpose.

Personally I don't expect Perl 6 to have a noticeable impact soon, I've read about it and I've never thought "that's what I've been missing all the time."

Let me tell you what I'm really missing -- something even simpler than Python which would allow me to draw the random graphical things with basic interactive possibilities but with the ease of old Basic languages. I've used tkinter a few times but every time I have to make something new I just discover I've forgot all the illogical things I had to do the last time, and the old source is not of much help, I know I'll have to spend trying a lot just to make something simple, so I lose the will to even start again...

</comment><comment><USER42> I love perl, and I don't want to see it be dead, but there aren't enough libraries relating to my interests (games).

<comment><USER43> You should really check out the SDL bindings for Perl. It's getting to the point where the dev versions are almost comparable to PyGame. There's some really cool stuff going on.

<comment><USER42> I had checked them out about a year ago and they couldn't even draw a line on the screen :\

<comment><USER44> Weird, considering that the very well-known free game Frozen Bubble is written in SDL/Perl...

<comment><USER7> It's now also on CPAN by the way at <http://search.cpan.org/dist/Games- FrozenBubble/>

I'm not really a game developer or have any idea about SDL, but from the Perl feeds I read (I think this instance was from Planet Iron Man) I gather that the SDL development was recently revitalized. They have their website at <http://sdl.perl.org/> and since the Latest News entry at this time is from the end of August, it seems up-to-date.

<comment><USER45> YouTube is full of Frozen Bubble movies. See for example <http://www.youtube.com/watch?v=5nUkly7AkFs> , someone completing level 70.

</comment></comment></comment></comment></comment></comment><comment><USER11> No. I wrote the bulk of my intern project this summer in perl.

</comment><comment><USER46> I'm currently writing a web application with perl catalyst...

</comment><comment><USER47> This is a question, but isn't it used fairly often in the finance industry?

<comment><USER48> Are you suggesting that this could explain certain events in the past?

<comment><USER47> As others stated for me, to parse large text files of data.

</comment></comment></comment><comment><USER49> I think there's still a vibrant perl community out there, but I wouldn't say the perl community is growing. I don't know that I'd use dead or alive but maybe "plateaued".

</comment><comment><USER50> Not if you include Asia. It's huge there, especially in Japan.

<comment><USER51> Bigger than Ruby? Really?

<comment><USER37> That is hard to say. I would lean toward "yes" because Perl has had longer to ferment there. It is a hard call because Ruby "comes from" Japan, so it is hard to make a definitive statement on this question.

</comment></comment></comment><comment><USER52> As strlen already mentioned perl is big in the e-mail and infrastructure world. I write perl code for our e-mail filter and/or infrastructure frequently. But our webui is developed is developed in rails and qooxdoo. So I guess, it boils down to right tool for the job and trends of the day.

</comment><comment><USER53> I don't think Perl is dead, as computer languages are significantly harder to kill than zombies. I would not at all be surprised if some critical infrastructure that must run lets a bunch of people gets killed is written in PDP 9 assembler. Just seams to be the nature of the beast.

</comment><comment><USER54> Isn't duckduckgo written in Perl? Thats one huge application right there.

</comment><comment><USER55> I'd much rather search/replace a huge string in Perl than in C++. Perl's hugely optimised.

</comment><comment><USER51> In summary: not dead yet because of all the legacy code and because of the "Modern Perl" movement.

However: many of us believe that Perl's day has come and gone and that truly modern languages like Ruby and Python have supplanted it. Absolutely true for me; I never use Perl when I can use Ruby -- not because of political reasons, but because Ruby is more elegant, readable, and concise.

As always, YMMV.

<comment><USER16> > ... truly modern languages like Ruby and Python have supplanted it.

In what ways?

Certainly not in testing culture, nor available libraries, nor the power of features such as language extensions or object systems, nor in flexibility.

Screencasts, perhaps?

</comment></comment><comment><USER56> If this really isn't trolling, check jobs.perl.org instead.

As others have written, Python and Ruby fill the same niches and have about the same features.

</comment><comment><USER57> The most widely used spam filter was written in Perl - <http://spamassassin.apache.org/>

Spend a couple of minutes thinking about why on in Java or C++ (the answer is - tons of modules it uses).

Now try harder question - why not in Ruby or Python? ^_^

The world is the way it is, because it got that way. ^_^

</comment><comment><USER58> Short answer: Yes.

</comment><comment><USER59> Learn Python and you'll notice why perl doesn't make sense.

<comment><USER51> Perl makes sense. It's a matter of degree of sense, and personal opinion. Python's use of semantic white space doesn't make any sense to me. But I know plenty of sane people who disagree with me.

<comment><USER60> Python's "semantic whitespace" is syntax that gives meaning to a common pattern in code. Most code that way by convention anyway. If that pattern has meaning then curly braces can be used for something else (in python's case: dictionary literals).

Hope it makes more sense now, even if you don't prefer that style.

<comment><USER51> It makes logical sense (i.e. I understood the meaning of the whitespace- delineated blocks). I'm really just saying I don't prefer the style.

</comment></comment></comment></comment><comment><USER61> ...its total lack of movement is due to it bein' tired and shagged out following a prolonged squawk.

...actually, it's probably pining for the fjords.

      http://www.mtholyoke.edu/~ebarnes/python/dead-parrot.htm

</comment><comment><USER62> I guess: yes.

The only place i see it is in some old scripts running at customers and they ALWAYS are a nightmare, unmaintainable, horrific, spaghetti code that oftern enough makes me want to poke my eyeballs out. Mostly, the customer agrees with me, but usually those scripts are too big to be replaced quickly... :/</comment>


HTC's Peter Chou: We Don't Pay Apple $6-$8 per Android Phone - <AUTHOR> http://mashable.com/2012/11/20/htcs-peter-chou-we-dont-pay-apple-6-8-per-android-phone/

<comment><USER2> I knew it the day these speculations began. I believe Apple could be paying HTC more than what HTC is paying apple themselves, only because the number of patents don't matter, but the quality of the patents do matter.

Even a judge once said[1] that Apple will have a hard time convincing everyone that Apple doesn't infringe on two of HTC's patents, which is why I believe this settlement occurred in the first place.

If you've used a HTC Android phone before, you'll realize they make some of the market's amazing high-quality android phones. Unfortunately, their financials aren't that great for some reason though.

[1][http://www.bloomberg.com/news/2012-09-06/htc-patents- challen...](http://www.bloomberg.com/news/2012-09-06/htc-patents-challenged- by-apple-probably-valid-judge-say.html)

<comment><USER3> HTC had a clear advantage 2-3 years ago but misplayed their leap by their model naming confusion. After "Desire HD", (which I still own) I could not recommend anything to my friends due to model naming confusion. Samsung was clearer and you knew Galaxy S,2,3 was the flagship. HTC One series tries to solve it but simply added more options and it seems to be too late. Even Sony has a better chance moving forward, I bet.

<comment><USER4> This is one of the biggest issues in Android phones to date, there are several names for every model phone based on market, carrier, and included feature set. This confuses the hell out of consumers. Compared to the iOS phones which go by a single name iPhone and a single capability moniker (3, 3G, 4, 4S, 5) with an intuitive versioning scheme (bigger numbers are better, number + letter is "better" than just "number") I noticed Google trying to do this with the Nexus brand (although they have Nexus + size rather than version/generation)

<comment><USER5> To be fair, the Nexus 4 is based on the size and the release number (it's the fourth Nexus phone).

</comment></comment></comment></comment><comment><USER6> It's an interesting public statement with no actual content.

Let's break it down:

* I think that these estimates are baseless

* and very, very wrong.

* It is a outrageous number

* I'm not going to comment anything on a specific number

* I believe we have a very, very happy settlement and a good ending

All of these things could be true if HTC was paying $20 per phone or $5.99.

</comment><comment><USER7> Is it bothering anyone else that the picture talking about paying Apple 6-8 bucks for Android has a Windows phone by HTC? Did they not notice the obvious windows logo on the bottom of it? Really no one had a picture of an iPhone next to an HTC Android phone?

</comment><comment><USER8> Yeah, they are paying Microsoft for a Windows 8 phone license which then goes unused so they don't get sued.

Like to use rounded edges? Want to use open source? Too bad.

[http://betanews.com/2011/09/28/microsoft-extracts-android- ta...](http://betanews.com/2011/09/28/microsoft-extracts-android-tax-from- samsung/)</comment>


Two Providers of Secure E-Mail Shut Down - <AUTHOR> http://bits.blogs.nytimes.com/2013/08/08/two-providers-of-encrypted-e-mail-shut-down/?smid=tw-share&_r=0

<comment><USER2> "please re-open the servers just that we can recover the info!!!" -> maybe the gag order is in place, and when you open your email they get the mail.

</comment><comment><USER2> They are imo doing the right thing.</comment>


Ask HN: Looking for Some Advice - <AUTHOR> Thank you hn for everything! I appreciate all inputs.
I am a new ECE PhD graduate and I never felt more lost in my life. 1) I don't remember anything I learned during my undergraduate degree. I remember some things, but it feels substantially less than what I knew during that time. 2) I feel slow sometimes; it sometimes takes me a while to figure something out or to look at from a different angle. 3) I am currently working in my field of study but I focus on another field during work after hours. I enjoy the other field as a hobby.
Bottom line is, I don't feel sharp although I'm in my late 20s. Should I be worried about my future in tech? Or does anyone else go through the same thing ? Do you remember everything from undergrad sharply? Do you ever feel "slow"?
Thanks! <comment><USER2> I stopped school after my undergrad. I have forgotten nearly all of it. Hell, I've forgotten most everything I've ever learned. I don't recall a lot of the early seasons of any of the shows I enjoy. I'm slower to learn new things, slower to implement things, slower working out, and the list goes on. People still consider me smart and highly productive and enjoy working with me. Turns out that while I don't recall specifics often enough, I have developed ways of working that scaffold what I know. "Standard operating procedure." I can still think through systems, debug hard problems, sling code, work great with teams, delegate, ask for help, mentor, mentee, learn new things (albeit slower than before, and it has to provide value, usually quickly), teach, etc.

I'm slower. I'm more experienced. I'm doing great.

You say you feel slow and not as sharp. I'd equate this to typing speed. If you were typing 90wpm and got slow and errored more, would that stop a career in tech? I work with a guy who hunt and pecks when typing with two fingers. He is a fantastic developer and doing great.

If you enjoy it and people enjoy working with you and you are productive, then you will be fine.

</comment><comment><USER3> I firmly believe that learning is not about remembering facts but about shaping your thinking. Surely there are professions where having facts ready is important, but relatively few. It's for a reason that many employers don't care too much _what_ you studied, as long as you graduated (or have something else to prove your character). You'll have to learn on the job anyway; what they want is someone with the right attitude and who knows how to approach a problem.

Feeling slow is definitely familiar, while everybody else seems more than satisfied with my results. I'm still trying to always get better at what I do, but at the same time I remind myself not to sweat it. The internet makes it too easy sometimes to see top performers, and mainly their good aspects. Doing average gets you a long way, and a bit better than average a very long way. Stop comparing yourself to others. Just do your best. It's most probably enough.

Having hobbies that differ from work is something I'd consider healthy.

</comment><comment><USER4> Do you sleep enough? Are you sure?

Do you sleep well? Are you sure?

Do you have a sleep disorder? Are you sure?

For me, answering "are you sure?" on all of those questions involved talking to a sleep specialist and the answer was no. Working through all of those problems was life changing.

<comment><USER5> I would add

do you get regular cardio exercise

Do you eat well

To that list

</comment></comment><comment><USER6> I'm in similar situation: also a new ECE PhD graduate, working in my field of study, and also working on an exciting side project after hours, in a different field. I'm 41, started PhD program at 35, long after I forgot almost everything I learned as an undergrad.

I'm not sure I fully understand your worries though. What do you want your future in tech to be? What do you want to accomplish? The key is the drive to build something. Are you motivated enough to succeed? Is your hobby project exciting enough to keep you up at night (or would you rather be watching Netflix)?

Regarding the sharpness - no, I don't feel any less sharp than when I was 20. I don't think the 20 yo version of me would be faster to solve hard research problems I'm struggling with currently, both at work or the side project. Sharpness is not a function of age, it's a function of your current state - physical (exercise, sleep, eat well), emotional (find the drive!), and mental (solve puzzles, read books, talk to smart people, try new things).

</comment><comment><USER7> Why is remembering materials from your undergrad degree the meter of "how smart am I?" What a strangely arbitrary scale.

> Do you ever feel "slow"?

Very often. I wake up, and feel as if I haven't slept at all. During those times, my memory literally fails me. The other day, I couldn't remember the term "thin provisioning," about which I was drilling a current coworker a few months ago at an interview. So though the concept is trivial to me, I just couldn't find the words to describe it.

And yet, even in that state, I sit down, and code, debug issues, write code... I still get my shit done. I spend less time in the kitchen talking to coworkers, though.

A better question is, why do you feel you shouldn't feel "slow"? What should make you feel "fast" that you've acquired during your couple years of studying?

</comment><comment><USER8> You probably retained more than you realize, but I can tell you that I've been coding for about 25 years now and I constantly refer to documentation for the tools I use.

"I don't feel sharp"

Don't equate not knowing how to do something with being inept. Making something from scratch that's not been made before is often an adventure into the unknown that requires a lot of trial and error. It's often our job to figure out how to do it. For me, that's the fun part, but the journey to get there can sure make you feel dumb as a bag of hammers.

That's because there are almost always a lot of ways to do it both wrong or better. But the truth is you just need to find one way that does it. "Improvements" are future tense. So you focus on the problem in hand and move along a step at a time.

I've learned to seek help as soon as I get stuck, as opposed to a hardheaded "keep tossing mud to see what sticks" approach. A few days of that can make you feel stupid real good.

It was ego that prevented me from learning that lesson sooner. Ego can take a pounding when you're hard headed. So toss ego aside and start looking for and asking for help as soon as you hit a wall. My experience since is there are very few problems without solutions, or at least partial solutions you can build upon.

You probably do know where to start looking for answers to questions and help for most of the issues you'll ever run into, and that's what will keep the progress going on whatever you're working on.

If you think about it, finding the answers is what you really learned how to do in school, and you still know how to do that, and you always will.

I'll also offer that you work on something for you. Grab a raspberry pi and one of the projects for it that looks fun and diddle with it. It's exercising. It keeps you sharp and builds confidence. Make something and share it.

That said, I've got some Pi projects I did a few years ago that I glance at now and wonder how the hell it works because I forgot, but if I dive back into them it comes back to me.

So just dive in. You'll be welcomed.

<comment><USER7> > I constantly refer to documentation for the tools I use

I feel the same. At the same time, in my case, I'm quite sure it's because I don't pay enough attention. If you refer to the docs just to copy-paste something, you'll remember exactly how to get there (the important part) and not what you copy (the implementation detail).

If you want to change it, pay attention to the actual details. You'll be amazed how much you can remember.

</comment></comment><comment><USER9> "Slow" is relative, and quite common in an academic environment. I find that after entering the industry, with people from no/poor academic backgrounds, I feel really fast. If you work somewhere with higher standards, you'll feel slow again.

Learning seems more like a skill/technique than an aptitude. It's not just grades, but learning in a way that it sticks.</comment>


Pysandbox - a configurable Python sandbox - <AUTHOR> https://github.com/haypo/pysandbox/

<comment><USER2> I'm not sure what this does what Zope's Restricted Python doesn't do already, except possibly be more performant. Zope's module requires no patches and is being widely used.

I had a good experience implement this Restricted Python (unrelated to the restricted mode in Python) as a flexible sandboxing for (mostly) untrusted users. I say mostly, because DoS attacks are still possible; these are paying users and just need to be kept in their own sandbox away from others' data. There's a OS level memory restriction and runaway processes are killed by signals.

The Zope module works by compiling all insecure code, restricting some things that are hard to secure and otherwise turning: foo.bar = quux.baz into approximately: set(foo, "bar", get(quux, "baz")) -- where you provide the get and set function, so you can verify no attributes that are bad are accessed. No access to anything start with _ is allowed, and there are a few other odd restrictions like no augmented assignments.

This process has about 40% performance penalty however, depending on how often your verifiers need to get called during the code execution. This applies only to code you explicitly compile with their compiler, so insecure python code called from that context execute without penalty (or security!)

Because of the way my system is setup, the untrusted code interacts with some secure objects, so I have an ACL system where objects can declare that untrusted code can do X but cannot do Y to them.

<comment><USER3> It sounds like a really interesting business. What do your customers use the python code for? Are they developers themselves?

<comment><USER2> Our customers develop online questionnaires. Most of those are stock controls which don't require any logic, like asking a question about the user's about age. Sometimes you need simple or complex control logic, e.g. display these additional questions only to users that meet certain criteria, like 18-25 Males who know at least 3 out of 7 competing products. The casual users might select that from a GUI, the more expert might enter the Python code directly.

The complex control logic might be: plug in the responses to those questions into giant matrix with thousands of coefficients to segment users into groups.

It can get even more extreme; we even had one user who wanted to use a 200,000-line C function to determine this segmentation, apparently that was some neural network output from a program called "Salford Predictive Miner".

<comment><USER3> Thanks for the explanation.

</comment></comment></comment></comment><comment><USER4> Configurability is generally a bad idea for a sandbox. Here the configuration seems to allow whitelisting a few extra modules that do not allow working around the sandbox, but increase the attack surface for bugs in the implementation (because they are implemented with syscalls, ad-hoc native code, or interpreter assistance for example).</comment>


Human-competitive results produced by genetic programming (Open Access) - <AUTHOR> http://www.springerlink.com/content/92n753376213655k/

<comment><USER2> These results are always impressive.

The main problem in my opinion is that most genetic algorithms perform a kind of local search in the genotype space. A large part of the problem is therefor to find a way of encoding which makes the target function smooth with respect to the target function being optimized.

That in itself is a significant intelectual feat in many cases. So one should not be fooled into thinking we can now just plug any given problem into a GA and get brilliant results. Human input is still very much required.

<comment><USER3> Not sure what you mean by "local search", but GAs (/GP) are used precisely when the target function is unsmooth (otherwise basic hill-climbing algorithms such as backpropagation in neural nets could be used). The search heuristic of GAs (mutation, crossover, fitness-proportionate reproduction) is pseudo-random and very analogous to simulated annealing, where we start out very random then coalesce on our best guesses.

However I do agree that the smoothness of a target function under a particular encoding is key to evolutionary methods. I think the No Free Lunch Theorem implies that for every target fitness function, there is an encoding that makes it smooth and an encoding that makes it purely random, and everything in between.</comment></comment>