perigrin

They actually have had the existing URLs working via `search.mcpan.org` for several years now, this is really just a matter of dropping the `m`.

I'm biased, I've release bits for Moose but ... Django, React, Rails, Spring, : can you tell what they are used for from the names? Does this mean that Python, Javascript, Ruby, and Java are "drawn towards unreadability than readability by attracting a kind of mindset that wanted [them] to be more 'fun'"?

In fact Moose, Catalyst, Starman, etc were all projects specifically named more fun _becasue_ their authors saw other communities not naming things "DBIx::Class" or "ExtUtils::MakeMaker" and wanted to bring some of that fun to Perl.

I ask all my node questions in #axkit-dahut. :p

Well ... there is ether.

`cpanminus` should install from BackPAN automatically if you ask for an explicitly older version. `cpanfile` and Carton do a fairly decent (IME YMMV) job of locking versions.

There was a little. Mostly stevan and Yuval going "oh god not that".

Javascript lacks the "packages" part of the mix, it uses Prototypal inheritance rather than Class based inheritance.

If you squint you can view prototypal inheritance as class-based-inheritance-where-everything-is-a-singleton ... but you really need some alcohol to deal with the headache you get from squinting that much.

> So I don't think it is fair to call it just a retail business.

Fair enough, I was actually assuming it was basically similar to my wife's pottery business. She has a retail location (studio space) but a good portion of her revenue comes from what would be the equivalent of wholesale sales. She does field trips and after school programs. The two compliment each other, and while you can survive with just a retail location (most of her industry does) ... the fact that all but two of the local pottery shops have shut down in the last three years suggests how difficult that is.

> As with any business you need to do your planning first, prepare for an extended period without profit, etc going in (and have capital investment of your own to make it work).

I'm pretty sure that is the gist of what I was trying to say. The original comment, and the general theme of comments like this, suggests that all you need is enough "balls" to just do it. I'd suggest that most people who actually start businesses to change careers do it because they don't know what they're in for. Anecdotally that seems to be the case from everything I've heard since I first started thinking about running a business. In that context I stand by my assertion that opening a business _simply because_ you're tired of your old career is foolhardy.

"Heck, starting a software business and decided to grow to your first hires and worrying about making payroll is just as taxing."

Actually in my experience it's not. Again about 5 years ago I started my own software company. About a year after that I brought in a friend as a partner. We did consulting for the next few years, and my partner ran into an idea for a product that we couldn't pass up. (We're releasing to our first round of beta-customers this week.) During that time we've had several employees (part-time and full-time), great contracts, not-so-great contracts, and one contract that made me curl up in my bed for a week and refuse to speak to anyone for two days.

My job has still been significantly easier than my wife's over that same period. I've had to deal with maybe a dozen clients, she's had hundreds in the 3 years she's had a retail location. Our operating budget monthly outside of payroll is measured in the hundreds (handful of linodes, github account) her's is an order of magnitude higher. She has to travel extensively around our metro area (we happen to live somewhere with crap public transit so lots of driving), spending some weeks as much as 30hrs in her car alone. I work from home, or when I'm feeling audacious from the park near my kid's school.

Just today she called and told me though that she'd visited a place where part-time employees had to be badged in, and she was incredibly happy to be self-employed seeing that. I've spent the last few days feeling the grass was greener with a salaried job. Knowing your next paycheck is gonna arrive is a really nice luxury. Being able to take two weeks off without having to worry about how you'll make payroll is a really nice luxury.

Listing here for you all the reasons why being self-employed sucks has ironically reminded me that I really am doing this because I want to. So yeah what you're saying overall about finding what need to do and doing that is entirely true for me, but it isn't necessarily "easy". I certainly didn't realize how hard it would be before I started.

So you're saying that they're a "business"?

"there's always an option to pick up a contract or go back on salary"

What do you tell the interviewer who says: "uh, yeah but your experience is all 1-5 years old. Why haven't you committed to github this week?"

We're just arm-chair quarterbacking chromatic's life with our own experiences informing what play is "obviously" the right idea. I know from personal experience that he's a incredibly insightful intelligent person. I suspect that he has weighed all of these options and hopefully he'll find the best solution for his own life.

Actually there have been studies that have shown that while more money doesn't provide happiness, enough money is a pre-requisite. We're not talking a ton, we're talking enough to pay for food, shelter, and some basic form of entertainment.

It's incredibly easy to say "move somewhere cheap, keep your expenses low, and have fun" from the outside. I have been perfectly willing to move for a job. I've changed continents, and failing that moved literally across country (vertically mind you) for another. We even moved when we had a house with a mortgage and rented out the house (at a loss) because the housing market sucked in 2008. Moving that much took a huge toll on my family. We basically decided to stop when my second kid entered school, and my wife opened her retail business. Which is to say, it ain't that simple.

Have you started a retail business? I've watched first hand what it takes. My wife works easily 50% harder than I do, for 50% of what I make on a good day. She has finally gotten to the point where she has three part time employees so she can take one day a week off. She cannot simply 1099 contractors, so she has to worry about witholding, workman's compensation, and employee benefits. She has to deal with upstream suppliers, constantly finding new customers, driving business into her shop as well as subsidizing it with external events. She'd be the first to tell you that without my salary backing up the family ... she would have had to shut her doors several times.

In our industry we lose site of the actual cost to run a mom-and-pop business because we can throw up a website for $20/mo and a long-weekend of work. (Isn't that what the basic premise of the Lean Startup is? Throw something economically cheap together to test the idea and bootstrap sales?) My wife's business has kept expenses low. She buys all her equipment second hand off craigslist (she's a potter not a baker so thankfully a lot of failed hobbyists make the supply on craigslist reasonable). I'd estimate her expenses before payroll are close to $2k-$3k/month for consumables and rent. Most months she breaks even after payroll, and doesn't pay herself an actual salary.

If this description sounds remotely appealing, then by all means stop what you're doing and go that. Programming really is that hateful.

However painting it with the rose-tinted glasses of "You get to interact with more people, get involved in your community, and people can taste the results of your work." belies the actual hard work that building a business is. It elides the fact that there will be nights you will lie awake wondering if you'll make enough sales to pay last month's rent ... let alone this month's rent.

For some people that is still better than what they were doing before, but pretending that all you need is a little more gumption ... I don't know a better word for it than 'disingenuous'.

"For me, the mechanics of budgeting are easy but the psychology of riding the business cycle is difficult." Running a bakery is effectively like consulting except it pays worse. Starting a Bakery isn't courageous ... it's foolhardy.

Sometimes it pays to be foolhardy (lord knows I have been several times), but painting the picture that all of us who may be dissatisfied with our current mid-level careers as technologists would be successful if we just had the courage to abandon a decade and a half of training and effort to chase something new, that's disingenuous.

The first one I presented is the way the Moose documentation calls has, the way the Moose test suite typically calls has, and the way I and most of the rest of the Moose Cabal call has.

The second one isn't common at all, but I have seen people both completely leave out the parentheses:

    has foo => is => 'ro', isa => 'Str', ...;

or treat has as a straight function

    has(foo, is => 'ro', isa => 'Str');

both of which cause Perl::Tidy to do weird things.

You may not realized that's what you saw, but for example all of the Moose documentation uses effectively a nested param:

    has foo => ( is => 'ro' );

is equivalent to:

    has('foo', ('is', 'ro'));

because Moose's `has` sugar is written as a exported function.

Actually (and sadly) for some jobs with Perl that involve codebases older than 2007. That material would be useful. Because, like the languages you mention, deriving object systems from Perl5's rough axioms, was at one point something of a hobby for people.

It might also be useful to add to the disclaimers that many of these things that aren't explicitly documented can be in flux. Parameter passing is currently for example being discussed and may change (experimentally and in a backwards compatible fashion) between the upcoming 5.20 and next year's 5.22 release. It also may not, but I know it's been actively discussed this month.

Some people actually find Perl fits the way they think better than Python does. They may find the culture a better fit, or they're better able to find existing solutions, or they simply prefer the concept of "There's more than one way to do it" over "There should be one – and preferably only one – obvious way to do it." Finally some are better paid to write Perl than they are to write Python.

The reality is any/some/all of the reasons above apply to any combination languages in your question. Might as well ask "Why are programmers still using COBOL rather than Erlang?" Because.

So is Amazon! You're startup buddies!

CPAN is all volunteer. We happen to have a few really good SAs volunteer to keep core infrastructure up (which PAUSE, our upload server, just moved onto) ... but it's still volunteer.

In a word: curation.

Amazon is probably always going to be the most relevant search engine for their site, but the current choice for python searches may not be.

An example similar to python but that I have first hand experience with is Perl's CPAN searches. There are two search engines for CPAN, http://search.cpan.org and http://metacpan.org. DDG's !cpan originally defaulted to the first one, but at the time it's results were not as accurate or informative as the second one. Upon appeal the DDG people switched the default to http://metacpan.org providing everyone who used the !cpan results with what they felt was a better result.

I don't see that they realistically have an alternative.

DuckDuckGo won't ever be able to compete with Google as a general search engine. Google already pretty much solved that problem, and even if they haven't they have a huge head start and a much bigger bankroll. If DuckDuckGo is going to succeed on it's search principles it's going to be as a curated search engine. That's a game where they can still compete with Google.

I completely agree with you about the lack of uniformity in search results. Curation is hard. It requires that a good source exist, that the curators are aware of it, and that it's amenable to being added to your system (technically and legally). Only one of these is under the direct control of the curators.

The reason the Python search sucks in DuckDuckGo the people running the curated Python search have a crappy search engine. Obviously either a better choice doesn't exist (probable), the DuckDuckGo curators don't know about it (very likely), or the better source isn't technically or legally accessible to the DDG curators (unlikely but possible).

Unlike the problems of a crawling and building general search index (where even to enter the market you need to have a massive infrastructure investment), these smaller problems of curation are attackable by a smaller team with limited resources. To improve the search results for !python they won't need to re-engineer their entire crawl/index infrastructure, they will simply need to pick a better third-party source once they are aware of it existing.

I really have to ask if your point is that because a feature isn't universally useful it's automatically pointless?

I've just taken to telling people that "I asked a duck."

Multiple Dispatch however is implemented in the extension MooseX::MultiMethods for various reasons to do with robustness.

This actually isn't true. I know several people who worked on the Perl version of YP and none of them are locked into the industry.

You forgot Fortran, BASIC, SQL, x86 Assembler, HTML, HTTP, TCL, Python, Ruby ... 15 years ago was 1996, we've got a lot of crap to purge.

I'm sorry I completely fail to understand how either of these remarks have any bearing on scalability?

How does the Perl6 project's ability (or lack of) to deliver a project to your undefined criteria for "usable version" have any bearing on the scalability of the ideas involved in either it or Perl5?

Second, in what way does a self-described popularity contest have bearing on the scalability of a language?

I would also love to hear how you would explain http://www.tiobe.com/index.php/paperinfo/tpci/Lisp.html which Alan Kay also talked about during that interview ... far more than the single quote he made about Perl. Note that according to the scale on both the Perl graph and the Lisp graph, Perl's lowest point is roughly equal to Lisp's highest point. The obvious explanation to me is that TIOBE score has almost nothing to do with Alan Kay's comments or opinions as expressed in that interview. So I don't understand what connection you're trying to imply exists here.

Perhaps you had your book on logical inference upside down?

As I pointed out on Gabriel's blog. This quote is six (6) years old at this point. Even if it was arguably relevant at the time (Alan Kay giving witness to an internal transition period in the Perl community), I'm not sure how it's relevant now.

Without specifics on which ideas Perl has that you feel don't scale, and how ... this is merely trolling by appeal to authority.

The last example is a proper noun(-phrase) and wouldn't necessarily follow the "standard" pluralization rules anyway. If you think about it you're not making "Leaf" plural you're making the noun-phrase "Maple Leaf" plural, and who knows what rules apply then.