Posts Tagged ‘links’

Links, where Perl is very much alive


Yeah, I guess my weekly links effort didn’t go so well. Nevertheless, I do still collect interesting links, so let’s restart with a less ambitious irregular series of “Links” posts.

Many programmers today consider Perl to be dying. That is because they read too many shiny new Ruby and Javascript blogs, instead of checking out what the Perl community is actually up to. Damian Conway says it way better than I could.

The slogan of the day, of recent years actually, in the Perl world is Modern Perl. Once you’re ready to get started yourself, get brian d foy’s timely new Effective Perl Programming.

And if you miss the good old days of obfuscated Perl, see the nice Hidden features of Perl collection. You will also find some serious, readable and useful tricks.


Weekly Links #2


Conrad Barski and James Webb: Casting SPELs in Emacs Lisp

Conrad Barski’s awesome Lisp tutorial Casting SPELs is now also available in an Emacs Lisp version, edited by James Webb. Even if Emacs Lisp is certainly not the greatest Lisp dialect, it shouldn’t matter much for a beginner’s tutorial and it sure is nice to be able to evaluate everything right in your editor.

ars technica: Tentacular, tentacular!

Cthulhu plucked a manila folder from somewhere within the non-Euclidean geometry of his manbag and dropped it on my desk with a thud.

A geeky, hilarious choose-your-own-adventure story written by Cthulhu. What else could you want for your Easter weekend.

Weekly Links #1


This is the first post in what might become a weekly installment. Like all IT geeks, I read a serious amount of articles online. A lot is not that impressive, but each week, there’s usually a handful of good ones that I’d like to record for myself as well as share with others. So I’m planning to have a Weekly Links post here. To give it a clear structure and to avoid it becoming tedious, I’m imposing some rules on myself: a maximum of three links a week, with a maximum of three sentences of commentary per link. Enough talk, here we go.

Daniel Tenner: How to nap

Napping is not the same as sleeping, and 20 minutes of napping can do a lot of good without making you feel groggy.

Scott Berkun: The cult of busy

Time is the singular measure of life. The person who gets a job done in one hour will seem less busy than the guy who can only do it in five. Being in demand can have good and bad causes. The phrase “I don’t have time for” should never be said.

yield thought: On The Fear of Reading Code

The best analysis I’ve read so far of why programmers don’t want to read others’ code, butwhy you should anyway because it will make you better and your life easier.

Elsewhere: Java generics


This one is basically a write-up of a collection of links about Java generics. Yes, I know, it doesn’t get any more boring. Every Java developer knows this by now, and the cool kids have moved to Scala and Clojure. (I’m working on it, too.) But at work I kept seeing that while the idea is simple, using generics in practice in a useful way is not easy for beginners. So I started tidying up a few bits and pieces I had written for colleagues and had that in my drafts for over a year now, and as I think it’s at least a collection of the best references about generics, here it is.

Let me get it out of the way first: every Java developer should know the Generics in the Java programming language tutorial by Gilad Bracha. Definitely study this first, and that might be enough for most people.

If you’re like me and need another round of explanations and examples to fully get the corner cases, Brian Goetz’s two articles on developerworks are great.

The second article addresses the question

Because the language supports both upper- and lower-bounded wildcards, how do we know which one to use, and when?

Goetz answers

There’s a simple rule, called the get-put principle, which tells us which kind of wildcard to use. The get-put principle, as stated in Naftalin and Wadler’s fine book on generics, Java Generics and Collections (see Resources), says: “Use an extends wildcard when you only get values out of a structure, use a super wildcard when you only put values into a structure, and don’t use a wildcard when you do both.”

Read the article if that concerns you at all, it’s very useful. I particularly like his clear explanation and example for the less often used lower-bounded wildcard:
public static <T extends Comparable<? super T>> void sort(List<T>list) { ... }

Goetz explains the idea behind the wildcard in the example like this:

[…] rather than restricting the domain of sort() to lists whose elements are comparable to themselves, we can go further — we can sort lists of elements that know how to compare themselves to their supertypes, too.

Alternatively we could say the Comparator must be able to compare at least T – if it can compare more, i.e., more generic types, we’ll take that as an added bonus.

Finally, let’s be balanced and mention the big shortcoming of Java generics: the type erasure, i.e., that the generic types are erased by the compiler and are not available at runtime. So, if you have a List and cast it to an untyped List, you can then insert any old Object into it. Mike Stone explains this in detail.