ericssmith

"I've written plenty of lisp (Clojure and non-Clojure) and I haven't observed it to be significantly shorter than Scala/Haskell."

Same here. Although I've found Haskell to be noticeably shorter than Scala. But there are trade-offs. Java reads sequentially, top-to-bottom, so when you are new to a piece of code, you trace through it in this linear fashion. And as Paul Graham says in On Lisp (p30), such code 'looks solid and blockish'. But it's approachable, if somewhat long and cluttered. On the other end of the scale is Haskell, which is anything but linear. And with a healthy dose of library-specific operators, it can be quite alien looking. Until you are accustomed to the syntactic patterns, it's pretty hard going. But after that point, it is considerably faster to grok the meaning of the program, as it is entirely clutter free. Clojure (and Lisps in general) is closer to Haskell in its non-linear nature, but without more syntactic help (eg infix operators), it never gets to the compactness of Haskell. And the indentation gets a bit heavier.

The increased LOC in Java is the price you pay for this linearity. But with program complexity and scale, this price can get to be pretty heavy. The same can be said for indiscriminate mutability and side-effects.

"churches spend part of the money on social assistance"

As a vehicle for proselytizing. Organizations that are dedicated to social assistance have reporting requirements that churches don't. It's not transparent at all what churches spend their money on. It's a murky government-sponsored wealth redistribution scheme. Not unlike the financial industry in that regard.

I'm very glad to see articles like this: accessibly written on a topic (types) that in the past may have been considered largely academic, but are now entering mainstream engineering mindshare.

I've been thinking recently about why functional languages and features have been gaining traction in the last half decade. Concurrency & parallelism have often been given as rationales, but I suspect the real reason is the need for programs (and libraries) to behave as intended and the desire to express complicated processes more simply. And the driver for that may be that a 'commodity programmer' mindset for businesses is faltering as the rate of change and complexity of technology increases.

In my hiring experience, readily available programmers are well-versed in the technology of several years ago. This makes sense because they've spent their time maintaining and extending systems designed and built years ago. But as requirements increase and become more exotic (due to competitive business pressure), such systems get used beyond their original design, and become more difficult to work with. I believe a 'testing culture' developed to mitigate this risk (along with the rise of dynamic language use to address the need for development speed). The hope was that the cost of testing (which can be pretty heavy for a business) would outweigh the cost of maintenance. But the overhead incurred may go to trivialities (ie, test that are easy to write) or struggling to implement more complex (and probably more valuable) tests which themselves are prone to trouble. Wouldn't it be nice if the parts of the program did what was intended and that testing be used more selectively to ensure the integrity of the system? I think correctness is one of the things functional programming languages encourage.

Types are an important part of many (most?) functional languages and are arguably an important part of the puzzle of building correct program components. I think we'll see a lot more articles musing on what they mean for engineering.

I want to echo this last remark. We often need to sync with the server and our UI can get to be relatively complex. Backbone is an outstanding tool for us. However, we don't have single page apps (yet) and we've removed any routers from our apps since they were unnecessary.

I believe many of the references on the web regarding Backbone (blogs, tutorials, stackoverflow) actually confuse matters and made my team's learning curve steeper than it needed to be. Also, the Backbone documentation isn't particularly newbie friendly. I strongly advise anyone first looking into Backbone to ignore Routers completely until the relationship between Models and Views is understood, and you've deciphered the patterns that express that relationship.

We also use Coffeescript, which increased the trouble of learning Backbone. But it was well worth the extra head scratching.

I'm a programmer and have two young children. I can't help but be moved to donate as it is relatively easy for me to see myself in his shoes.

The 4 yo was excited about getting a computer, but didn't care at all about using it. She just didn't 'get' the steam locomotive. She was willing to participate (and was interested) in typing characters on the screen and having something happen, but I just didn't have enough at an appropriate level to maintain her interest. I had hoped to work up to the gui and tuxpaint, but we didn't get that far before she completely gave up. I think there would've been (general) merit in this approach, but there's just not enough command line apps that are suited to this age group. The 2yo could also make the train go, but he didn't recognize it as a train. It was probably too fast to decipher the ascii art.

Somewhat strangely, starting the following day, the 4yo started calling her fake baby cell phone a 'computer' and is really in to pretending to do things on it. Crazy stuff like talking about how well she's doing at playing videos games. We don't play any video games in our house. It's as though I unlocked some possibility of having her own computer and her mind is running with it.

Surprisingly, out of all the comments, this one caught my eye. I've been hiring programmers since 2005 that have to maintain or extend PHP systems. In 2005, it was difficult to find programmers that knew only PHP (or Perl, which was still used) who had any familiarity with object-oriented programming. Over time, PHP has bolted on features, and at each point, the vast numbers of available PHP programmers are (understandably) not familiar with those features. And obviously the systems that have to be maintained don't have these features. So the armies of PHP programmers are well matched to the old systems. This eliminates a huge risk to the business -- finding relatively inexpensive developers. This is an often cited advantage of PHP. But only the PHP of 2007 (or so) is relevant.

The PHP of 2009 might be worthwhile for the creation of business value (and possibly the reduction of maintenance-related risks), but as I said, the easily available programmers have no experience in those features or concepts. The more common scenario is that a particular programmer has experience in some other language that already included those features and doesn't mind working on old PHP systems. Believe me, there are not legions of these people.

And regarding the 'PHP of 2012', the major problem isn't the availability of programmers who have experience in the new features (they almost don't exist). It is the availability on distros stable enough to support an SLA or provide a modicum of security assurances. This problem applies to all languages though. I'm just pointing out that the 'PHP of 2012' is not as much of an option as it may appear.

I have a 34month old and 4yo, and this has inspired me to give them a old machine tonight. They will love 'sl'. I will also try the xmonad and tuxpaint stuff with the 4yo. She will like having her own computer and will be tickled to be 'working' like Daddy. They use an iPad sometimes, but I'll be interested to see how they feel about typing on keys and using a trackpad to paint with (the mouse doesn't get used).

I'm opposed to standardized tests more than most people, however I have to take issue with this article. The author of this article stated early on that this was a 'reading comprehension question', and then goes onto to critique the question as if it was about learning about microscopes. He also says that he 'couldn't figure it out' by guessing. He should've tried reading.

As an aside, I did know the correct answer because I had been trained numerous times on microscope use. I didn't even look at the question until after reading the rest of the article. The test makers wouldn't have been testing my reading comprehension. I suspect this would be true of most people who got the correct answer. Interestingly, anyone who has been trained in taking such tests knows to read the answers first, as well as to guess the correct one. Then scan the actual question to find the relevant bit, as well as the 'trick', if it exists.

Like many people, I believe this author confuses learning with being a student. A student's job is to be a student, and that includes trying to score higher than average on tests by any legal means. Learning is something else altogether, and I have my doubts about being able to get far with that in an institutionalized setting.

Parsec was Haskell's 'killer app' for me, but I tend to do most tasks in it now that involve some kind of data processing. Economical syntax, strong support for function composition, pattern matching, and type classes are the main draws for me. I have also learned to appreciate enforced purity and the abundance of operators, two of the biggest hurdles coming from stateful, imperative, mainstream languages. I prefer a development style in which small, single-purpose 'components' can be built up in the REPL and plugged together. Haskell is very well suited to this. Especially once I realized the GHC compiler was really telling me useful things and not just trying to piss me off. I have a love/hate relationship with lazy evaluation.

I'm looking forward to going through this book. Hudak's 'Haskell School of Expression' is one of the books that helped me understand FP, and Haskell in particular. Multimedia applications are not among my current interests, but there were many subtle nuggets in that book that sharpened my functional viewpoint.

Although 'Haskell School of Expression' is written to be an introductory text, I have trouble seeing it that way, in part because of the multimedia aspect. Graham Hutton's 'Programming in Haskell' is a carefully written beginner text.

Functional programming, and Haskell in particular, reward patience. Hudak's and Hutton's books both have a high impact to time spent ratio. I suspect 'School of Music' will as well.

[EDIT - Just looked through it. It is School of Expression rewritten for music rather than multimedia. Cool]

In my work, I read in XML, parse its elements, attributes, and data, producing new XML. Along with Parsec, Hexpat is well-suited to the task.

I haven't had to parse HTML in Haskell. I use BeautifulSoup for that. I wouldn't be surprised if the Haskell libraries aren't as useful for that kind of thing.

I use hexpat and it works nicely. I wasn't able to get very far with either haxml or hxt before having grief.

That would not be obvious to me. I often have to process quite large and messy XML files and a functional approach works well. I'm not even sure how inserting print statements would be helpful.

" was trying to express my frustration at not being able to insert a little impure code temporarily to tweak behaviour and help with debugging."

Why would you want to do that? Haskell is a functional language. You evaluate expressions, which can be done nicely in GHCI.

When I first learned Haskell, I was also trying to apply my procedural programming habits. Looking back, the pain was a sign of doing it wrong. Once I learned to look at solutions 'functionally', it turned out not to be a big deal, and the resulting code is arguably better. However, it does sometimes become painful going back to procedural languages.

HN threads on this topic already:

http://news.ycombinator.com/item?id=3781829

http://news.ycombinator.com/item?id=2443316

"worst material to write was probably math simply due to the dry nature of the subject"

Math is one the most fascinating, creative, and empowering pursuits of our species.

You've been corrected already on your misinterpretation of the slide without watching the video (at 38:08), but I wanted to add that Simon has repeatedly made the point (including this presentation) that prior to IO Monads, the designers of Haskell were envious of other languages and the slide is repurposed from earlier presentations.