Ovid

Junctions are insanely useful once you get used to them and I use them frequently. Basically, any time you have a list and you're worried the properties of any, all, or none of the list members (hmm, just about all lists), then junctions are often a very clean way of expressing the issue.

    if all(@ages) >= 18 {
        # let 'em in the club
    }

Or:

    if any(@ages) < 18 {
        # don't let 'em in the club
    }

Or:

    if none(@ages) < 18 {
        # don't let 'em in the club
    }

So I use logic like the above quite a bit, however, there are plenty of areas where the above can be better if it's deeply integrated into the language. In this case, as already mentioned, it's auto-threading where appropriate. That's not an easy feature to get right if it's not baked into the language, but it's a huge win if done right.

Perl 6 also has gradual typing baked in. Other languages have gradual typing as a library, but that often fails dramatically (http://blog.circleci.com/why-were-no-longer-using-core-typed...). In Perl 6, because it's built-in, not only are the failures described something Perl 6 can avoid, but there are also plenty of type checks Perl 6 can avoid at run time with integrated gradual typing (imagine that benefit in hot loops).

You could even combine that with native junction auto-threading and presumably have super-fast comparisons where the needs for checking types is eliminated at run time because it's already been done at compile time. If you do that with libraries, it's awfully tricky to get right, if not impossible.

Much of the "hatred" seems to come from those who have a lot of preconceived notions about Perl (either 5 or 6). However, I look at the people who approach the language with curiosity and no baggage, and the reactions I often see range from "that's cool" to "holy shit, that's cool."

I have to take exception to this because part of what I do for a living is teach tech companies how to hire.

The claims are:

1. Performance on our online programming quiz is a strong predictor of programming interview success

2. Fizz buzz style coding problems are less predictive of ability to do well in a programming interview

3. Interviews where candidates talk about a past programing project are also not very predictive

Those claims may be true, but it misses a key point: no matter how well someone performs in an interview, it doesn't mean they'll perform well on the job. In particular, the post talks about hard skills (and does well there), but doesn't talk about soft skills.

It's absolutely true that someone can talk a big game about hard problems they faced that they solved, but failed to mention their use of Google or StackOverflow. So unique coding tests can definitely tell us whether or not a candidate can really code (though the tests need to be tailored to the sort of real work the candidate will face). However, programming is a hard skill (one that is easy to teach), and not a soft skill (one that you tend to learn over time or have a natural inclination for).

Case in point: early on we made the mistake of hiring a very talented programmer on the basis of his reputation and a brief interview. He was a disaster because he was completely unable to work without a very hard set of requirements. In the very rapidly changing, agile, environment we put him in, he flailed badly because he was good at implementing requirements, but he was very bad at projecting himself into the customer's shoes. Later, we put him on technically demanding tasks which required considerable talent, but had no ambiguity, and he was fine. In fact, he was able to implement tasks that would have been very difficult for other developers who were fine in ambiguous environments.

Soft skills are tricky and most employers have no idea how to interview for them. They require an understanding of the actual role someone will be hired for and the set of skills necessary for them to succeed. Are there tight deadlines? If so, can the developer prioritize tasks and make a case for delaying less critical portions beyond the deadline? Is it a rapidly evolving environment which makes it hard to nail down exact behavior? Are you on a team with strong personalities who often disagree and can the dev handle that? Is the developer required to report to non-technical people who have no understanding of technology and can't appreciate what refactoring is?

Or here's a fun one for you aspiring managers: we've had one project with a superstar developer who was so monumentally productive and so brilliant at his work that some very talented developers who worked with him nonetheless had negative productivity at times because they spent so much time playing "catch up" with the superstar and understanding how the project was evolving that they spent more time keeping abreast of the code than developing it. The code was "bus sensitive" because one brilliant developer was so competent. How do you manage that?

These and other soft skills are part of what you really need to evaluate because depending on your work environment, you'll have these and other soft skills as critical skills that a dev will need, but you almost NEVER see interviewers check for these because very few people are trained in interviews.

Pro tip: start reading up about structured interviews. They've been proven via multiple studies to have a strong correlation with employees being successful. Unfortunately, they're harder to conduct and require training to understand them. As a result, companies don't know about them or worse, ignore them, because it costs more money. But what costs you more money in the long run? Taking longer to interview or hiring the wrong person?

The range operator (..) is also pretty cool, since we're all lazy now. Here's an infinite lazy list of prime numbers in Perl 6 (declared as a constant because you presumably don't want to change 'em):

    constant primes = grep { .is-prime }, 1 .. *;

I can't say, but I love what Perl 6 has done. For example, here's a Point class, with read/write, mandatory attributes:

    class Point {
        has $.x is rw is required;
        has $.y is rw is required;
    }

Like many dynamic languages, there's nothing to stop you from assigning the string "foo" to one of those attributes, so let's fix that, but go even further and constrain the X and Y coordinates from -10.0 to 10.0. (Note that a "Rat" is a rational number, so it's perfectly precise and doesn't suffer from floating points imprecision):

    class Point {
        subset PointLimit of Rat where -10.0 .. 10.0;
        has PointLimit $.x is rw is required;
        has PointLimit $.y is rw is required;
    }

So what that's done is allowed the dev to declare a new type, PointLimit, on the fly. It must be a number from -10 to 10. And then we have our X and Y attributes:

    my $point = Point.new( x => -1.2, y => 7.3 );
    $point.x = 3.14;
    $point.y = -22.0; # Boom! Constraint violation

When it's native to the language, it's awesome. When it's bolted on as an afterthought, you get articles like this.

Native gradual typing can be much faster and assuming the language has a decent test suite, cases can quickly be added to uncover those troublesome spots.

Aftermarket gradual typing leads to a lot of information that you could use to significantly improve the performance of the language (hey, we have an int, so let's use native types instead of our language's version), but because they're not native, that typically doesn't happen.

The issue I have with gradual typing in most languages is that it's added after the fact and not native. As a result, the integration isn't native and you start seeing issues like this.

This, incidentally, is one of the reasons I like Perl 6 (http://perl6.org/). It also has gradual typing, but if a third-party library doesn't have a type annotation, that's OK: it will simply fail at run time instead of compile time.

Another reason to like native gradual typing instead of third party gradual typing is that it can be integrated natively into the system instead of being used as an afterthought. Perl 6 has native type infererence to allow for compile time failures:

    $ perl6 -e 'sub foo(Int $x) { say $x }; foo("bob")'
    ===SORRY!=== Error while compiling -e
    Calling foo(str) will never work with declared signature (Int $x)
    at -e:1
    ------> sub foo(Int $x) { say $x }; ⏏foo("bob")

(Yes, that's compile time instead of run time)

What happened above is that the optimizer saw that the call to foo() requires an Int and checks the argument type to see if the call is allowed.

And here's the untyped version:

    $ perl6 -e 'sub foo($x) { say $x }; foo("bob"); foo(3)'
    bob
    3

Interestingly, the Perl 6 core team could allow for powerful type inference with this, but one of the core issues has always been that many languages using type inference have rather opaque error messages because they essentially dump a "proof" of type failure and many struggle to understand them. Thus, the the Perl 6 devs are taking more careful approach, though they know they can do more. For example, this falls back to a runtime failure instead of a compile time failure:

    $ perl6 -e 'sub foo(Int $x) { say $x }; my $name = "Bob"; foo($name)'
    Type check failed in binding $x; expected 'Int' but got 'Str'
      in sub foo at -e:1
      in block <unit> at -e:1

In other words, because it's not sure of the type of $name at compile time, it falls back to run time (though in the simplistic example above, that's clearly not the case). Annotate the $name variable and you get a compile time failure again:

    $ perl6 -e 'sub foo(Int $x) { say $x }; my Str $name = "Bob"; foo($name)'
    ===SORRY!=== Error while compiling -e
    Calling foo(Str) will never work with declared signature (Int $x)
    at -e:1
    ------> t $x) { say $x }; my Str $name = "Bob"; ⏏foo($name)

With this, third-party libraries which don't declare types work just fine, but you get type-safe run time failures. If they do declare types, you often get compile time failures (though it will still fall back to run time, and won't check at run time if it knows at compile time that it works).

Perl 6 isn't as complex as people make it out to be. I have friends who are race car enthusiasts who could go in to excruciating detail about cars and if you don't know how to drive, it could seem daunting. The reality is that most of us get in to our car and just drive.

That's part of the issue with Perl 6: its proponents get very excited about it and write about all the really cool stuff you can do with it, but for those who don't know the language, it sounds intimidating.

Here's a talk I gave at FOSDEM explaining how day-to-day Perl 6 is fairly straightforward and easier than people think: https://www.youtube.com/watch?v=lpu-3UF_b48

I just want to thank you for the very insightful comments you've made and it will definitely help me reform the background of what I've written. I think that largely my key points about modern corporations are generally on point (particularly lack of innovation and command-and-control structures), but it's clear that I could do better with my analogy than comparing it to post-reformation England.

I knew about co-ops, but many of them that I could were largely agricultural or small stores and didn't resonate with my audience, but perhaps I've done them a disservice. I'll look into Mondragon also, thanks!

Your complaints are interesting (I'm the speaker). That talk was a gross oversimplification in many ways as I've pointed out. Note that the core talk was 35 minutes and no, there's no way that I could give it as fair of a coverage as I would like. Your example of the Magna Carta, however, strengthens my core point (IMHO): nobody thought to end the system and try something new, they were trying to stop the king from acting arbitrarily. For the Peasant's Revolt, the people primarily sought an end to serfdom and the abuse they suffered thereby, but in no way considered that a different system might be better (which is what I kept getting to throughout the talk).

I would also point out that matrix management switches corporate hierarchies from trees to graphs: it doesn't change its fundamental nature of command and control. It's an attempt to tinker with how things are done and frankly, it's about as revolutionary as having car doors open backwards instead of forwards (and in my experience with matrix management, it's just as stupid of an idea).

As for Sears, thank you for that link. Yes, there are definitely going to be cases of companies trying and failing. How does that invalidate the point?

As for your other comments, I'm not going to belabor them, but there's a rich, rich background of people comparing modern corporations to feudalism: https://www.google.fr/webhp?q=corporations%20feudalism#safe=...

Or you can read this interesting one by the former chief economist of Valve Software: http://blogs.valvesoftware.com/economics/why-valve-or-what-d... (if that face looks familiar, it's because he's now the finance minister of Greece).

Again, 35 minutes to give an simplification of the problem and I know there's tons I left out (including co-ops) and there's absolutely no way I could cover it all and still get to the point of that talk.

And sometimes they outsource because it's hard to find expertise in a particular area, or they have a staffing shortage. I am regularly contacted because of that.

If they're outsourcing to save money, I don't want them as a client. As I've said, if they're pinching pennies, they're not focusing on the right area or they're so cash-strapped that they can't focus on the right area. Either way, I don't want that work and unless one of my associates is in a bind, I don't want to make their life miserable either.

And no, I'm not valued on price because even if the clients are in another country, they already know who I am. I been deliberate marketing myself to make that happen. Two books, conferences (including keynote speeches), lots of open-source code, and so on. That's part of what sets me apart from many others in my field: nobody knows who they are. It doesn't mean I'm better than them; it means I'm better known than them. (I apologize if that sounds arrogant, but this has been a deliberate, multi-year strategy to get me where I am).

> 7) Charge more.

I have a small, but profitable consulting company working for clients across Europe and the US. If there's one thing I've learned, it's that if some of the first words out of the client's "how much do you charge?", it's an awful contract. They're focusing on cost, not value.

I don't charge as much as top-tier consulting firms, but I do charge more than most freelancers. Clients generally know who I am by reputation or referrals and they're happy with my work. For clients who want to nickel-and-dime the contract, it's miserable.

Still, my favorite was one client who wanted to pay me far less than what I ask and demanded a fixed bid on a small, two-week contract. I agreed and got finished in three days. He wound up paying a lot more for my work than if he had agreed to my rate up front. I charge more, I get done faster. And that's with documentation and tests.

So yeah, don't undercut yourself by charging too little and don't hurt yourself by accepting contracts with those who don't appreciate your value. It's all grief in the end. I walked away from one year-long contract which offered a reasonable rate, but still less than what I charge. To this day I still don't regret that decision, though many would have compromised. My very next contract was my normal rate on a rolling contract. It's been less than a year, but I've already earned more than I would have with the year-long contract and the company is very happy with my work.

(Plus, I used to sell cars and when you sell cars, you quickly learn that the happiest customers are the ones who pay the most)

Damn it! I totally feel your pain. Migrating COBOL to Java has long been one of my pet peeves. The former is procedural with all variables being global and fixed-width and the later is OO (sort of) with lexical variables of variable size. The two do not mix and match well.

Trying to get away from COBOL is actually a three-way problem: technological (as we've alluded to), business (hey, we gotta stop using this shit!), and social (hey, I don't want to touch this shit!). Unfortunately, virtually every solution I've seen focuses on the business or technical issue in isolation, but ignores the others.

I've actually found a solution that solves all of the issues and would make new developers excited to work in COBOL shops, but it's on hold until some technical challenges are surmounted. Frustrating as hell!

OP here.

I really can't say as much as I would like (there's stuff I can't share), but my publisher had a face-to-face with an Amazon rep and internal action was taken. Amazon's investigation is apparently over. The internal position seems to be "we're making money, there are words on pages, so there's no problem here." Amazon's investigation was short and sweet. Some bogus reviewers were removed, but Felicity — one of the worst offenders (http://www.amazon.com/gp/pdp/profile/A1NT2YXTUES4RW/ref=cm_c...) — is still there, despite the obvious fact that these are fake reviews. Many other obviously fake reviews remain. In fact, a new fake book with fake reviewers showed up. I genuinely do not know if this response is because of a careless employee or if Amazon discourages employees from shutting down profit streams.

Ex-COBOL developer here.

In case anyone is wondering if something like this could ever be the "killer app" of COBOL that launches it into modern fame and glory, the answer is "oh god, no."

COBOL isn't a modern language by any stretch of the imagination. For example, advanced math is something that it's particularly bad at. Or do you want to sort some data? Yeah, COBOL will let you sort some data, only if you specify the damned file containing the unsorted data, the file that will hold the data while it's being sorted, the file that will contain the sorted data (http://www.tutorialspoint.com/cobol/cobol_internal_sort.htm). Want to sort an array into another array? Screw you.

However, there's one thing that COBOL is very bad at: unstructured text. Guess what 99% of the Web is?

For example, in their sample code they show this in the working storage section:

     01 the-values.
            05 COW-query-values           occurs 10 times.
               10 COW-query-value-name     pic x(90).
               10 COW-query-value          pic x(90).

Guess what "pic x(90)" means? The "x" means it can contain any data (not just alphanumerics), but the 90 means it must be 90 characters long. In other words, if you have color=blue in your query string, "color" will be 90 characters long (probably padded with 85 spaces), and "blue" will be the same (probably padded with 86 spaces).

Thus, when someone else declares color as "pic x(80)" (note the 80 versus 90), even if the color submitted is "blue" for each, one might be 80 characters long and the other might be 90 characters long and if you don't like it, too bad. Have fun comparing them.

COBOL is still the world's most popular programming language, though, if you look at it in terms of lines of code. Sadly, COBOL programmers are aging and there are fewer devs to maintain their programs (I started hacking on COBOL when I was 30 and I was the youngest developer in my department!).

> Many fake reviews are blatantly fake, and could easily be flagged by a relatively naive set of heuristics.

Yes, that's true, but I think this is a question of scale. Amazon is the world's largest e-commerce site (well, I think they're #2 after Alibaba now) and I've worked on some of the world's largest sites. Even "trivial" solutions become much harder at that scale.

The books aren't about Perl; they're gaming the Amazon system. That being said, it was interesting when you commented about sales rank. Yeah, they sell more than I do, but you can frequently buy the for $0.99, when my sells for a real price. That might make them break even, but since they're (I'm assuming) self-published, they're probably making far more money overall.

This is correct. I was doing well in my career before the book, but it really took off after the book. However, I was already co-author of one book before that, and I blog prolifically, so that skews this.

The way it works is simple. Publishers hope to sell about 5,000 or so copies of your typical tech book. That's enough to keep the publisher going, but not enough to really make money for them. The publisher keeps those "filler" books going to keep up street cred and hopes to sometimes land the "killer" book that makes them a nice profit.

I can't share the sales info for my book, but let's just say that I think the book is doing better than one might expect for its category.

If you want to write a tech book, you want to go with O'Reillly. My advance was much larger than what O'Reilly would offer, but they sell more tech books in the long run. However, O'Reilly's Perl book section is saturated and they generally don't take new authors.

What I did to reposition my book was a strategy I wish more tech books would take: I focused on jobs. Instead of teaching every esoteric niche of a language (though I covered it well), I focused very heavily on skills that employers look for. I've been doing this for a long, long time and am very familiar with employer needs, so I was well-positioned to do this. That has led to my book doing better than expected: here's what you need for a job!

I now have a successful Perl consulting firm (http://www.allaroundtheworld.fr/) and that book, while I can't prove it helped, definitely didn't hurt.

Oh, and my publisher has spoken to an Amazon rep and a contact I have in Amazon tells me that they're aware of the situation and are looking into it. I don't have much hope, but who knows?

2000 advance copies? Holy shit! I have the wrong publisher!

(To be fair, they were awesome with me and I had a blast, but damn, 2000 advance copies?)

What's the topic of the book?

That's an interesting thought. I'm pretty sure I could write up a nice grammar to chunk out "interesting" reviews of books. Instead of whining about my book getting buried by fake reviews, maybe I should chuck it and cache in on said reviews!

I'm a consultant, produce plenty of value, have very happy customers, and I don't get called a "dick" too often. Don't pay all of us with the same brush, please :)

(Note: I'm the guy who wrote the post OP linked to)

tl;dr

Damn. That's what I get for writing that late at night with a glass of wine in my hand. Plus, I haven't done COBOL for 15 years :)

I don't understand your question.

At OSCON, there was only a single Ruby presentation this year. Given that Perl, Python, and PHP all had multiple presentations, it seems curious.

A fairly vacuous article, but here's the takeaway:

> The company is taking losses to invest in the future, and Amazon’s 10 percent stock drop today shows that some investors are uncomfortable with that.

While its tough to be sure exactly what motivated that drop, the reasoning sounds accurate. More importantly, it shows a huge part of why public corporations in the US are so broken and may actually be hurting the US's competitiveness.

In a recent study (http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1959125) entitled "The Dark Side of Analyst Coverage: The Case of Innovation", the researchers found that publicly traded companies who attract the attention of financial analysts are less innovative. Why? Share prices.

For many in upper management of these companies, their compensation is tied to share prices. Management works hard to keep their share prices high. Further, if share prices drop too much, the Board might decide it's time to start firing their "inefficient" managers. In a worst-case scenario, if a company has value but their share prices continue to drop, they leave themselves vulnerable to a hostile takeover, thus risking everyone's job.

In a publicly traded company, everyone is working together to prop share prices up. How do they do that? Amongst other things, they're much more risk-averse. Taking a risk is a strong signal to the market that you might fail and they reward you with lower share prices. That's why the above paper found that public companies produce fewer patents and of lower value: everyone is so focused on short-term goals that long-term opportunities are at odds with their mandate of maintaining shareholder value.

Curiously, it looks like public corporations can share the same defect that democracy does: people can vote. Sadly, democracies produce mediocre politicians because average voters have average intellect (duh) and can't evaluate brilliant candidates (http://www.livescience.com/18706-people-smart-democracy.html). Rhetoric takes the place of thoughtfulness and we see this with corporations, too.

Frankly, I have no idea how to avoid these dilemmas but pretending they don't exist is surely not good.

As a guess, I would suspect that the researchers who set up the experiment are more careful about their analysis than NPR is with its reporting. NPR needs to popularize its information, thus ensuring that we, the casual reader, can get a grasp of what's going on. That necessarily dumbs down the content.

Hey, thanks for being so friendly! :) And recruiters have been here for a while.

Seriously, though, check my post history. I'm more than just a recruiter — I'm a serious dev and I'm willing to bet I've released more open source code than most people on HN and I can almost guarantee it's more widely used. The reality is that many companies know neither how to source candidates nor how to evaluate them. Being well-known in some tech communities (https://www.google.fr/search?q=curtis+poe+perl) means I can evaluate those candidates and I can also source them.

Yes, recruiters have a poor reputation and there's a reason that many (most?) deserve that, but for companies who can't source candidates, they're stuck. Recruiters, particularly those who specialize, tend to have large pools of "goto" people that companies would never have, meaning that companies who can't find talent have little choice.

The reason recruiters are despised so much is that there's such a low barrier to entry to our field that this depresses quality tremendously. I don't like it either, but we're not all the same. Frankly, I wish there was some way to enforce standards for recruiters and find a way for both employees and employers to "out" bad recruiters.

Search scientist. Amsterdam. Relocation and Visa provided. And I mean real search scientist, not just someone who put together Solr that one time.

We have a client who has a fantastic position which has opened up. They’re searching for you because you’ll be searching for them: they need an expert search engine/data mining specialist and very few people can fill this role.

You’ll have several years of experience with search engines and (preferably) e-commerce, a proven capability to mine data and a Master’s or Doctorate in Statistics, Math, AI, Computer Science or a comparable background. This isn’t for someone who’s just set up Elasticsearch, Solr, or some other search engine (though that helps). It’s for someone who can mine the data of customer searches and provably demonstrate they can create better search results for customers. You won’t be waiting for tasks to do: you’ll be deciding the tasks and how to do them.

How do you exclude a location 500 meters away from the one a customer is searching for but it’s across an international boundary or a river with no bridge? How do you do that in a performant manner? Or maybe searches in different languages should be treated differently based on cultural preferences? And do different categories of customers have different search needs? How would they be categorized and how would different search results impact them? Or maybe you can demonstrate that the above wouldn’t impact sales and you have a better solution?

The possibilities are endless and the position itself is very high level within the company. They’re offering a generous salary, an awesome work/life balance, a generous vacation package and a catch: you have to let them pay to relocate your household (even rats, if you want to) to the heart of Amsterdam, one of the most beautiful cities in the world. If you’re going to be sitting down sketching out how to group customers using adaptive resonance theory, wouldn’t it be lovely to do that while sipping a Grolsh, eating bitterballen, next to a beautiful Dutch canal?

And with 26 days of vacation and 9 public holidays, you’ll have seven weeks off a year to enjoy. Take a relaxing two-week road trip across Europe and return to work with several weeks of holiday left.

Given the extremely high level of expertise needed for this role, our client realizes that the few people who are both capable and willing to accept this role will need a relocation package. And if you have a family, our client will take care of them, too. Have special relocation requirements? As long as you are willing to work in Amsterdam, bring them up and the company will see what they can do. On top of that, you’ll probably qualify for something called the 30% ruling. This is a law passed by the Dutch government to attract top experts like you. When you qualify, you’ll be taxed on only 70% of your salary. The other 30% will be handed to you tax-free, effectively giving you a huge pay rise on top of an already generous salary.

This is a high level position in the company and you’ll be given a lot of autonomy to make things happen. Further, the success criteria for the job are extremely clear and you’ll be given all the tools you need to directly measure your success. The exact nature of the role can potentially be tailored to meet your personal preferences.

The work environment is laid-back, English is the working language, and you’ll be working with other expats with a sense of adventure. Amsterdam is a friendly, low-crime city and almost everyone speaks English fluently, but if you want Dutch lessons, our client will help. Heck, if you have other requirements, bring them and get them on the table. For the right candidate, everything’s open to discussion.

If this sounds interesting and you want more information, contact us at jobs@allaroundtheworld.fr.

This was for a game I was creating, but haven't had time to finish. However, I've seen enough people search for this and seen so many ugly implementations that I thought I would show my ugly implementation.

I'm mostly a backend developer, so I know my CSS and Javascript skills aren't brilliant. I would love feedback on them so I can better improve my skills in this area.