YcombRegBroken

Callbacks all the way down. I blame 42% of my recent gray hair on callbacks.

Any time you are the subject of prejudice, it is a source of stress. While it isn't at the level of a classic civil rights struggle, it still exists.

What prejudice? As the article says, if you look like the profile of a "bad tipper", you get shitty service. If you don't order alcohol/desserts/appetizers, shitty service. Split a large portion to not waste food? Shitty service.

It's a shitty system.

I swear I'm not a grammar nazi, but I did just spend the past 10 minutes thinking about ideal user interfaces for zombies and vampires. Thanks for that...

You are 100% correct. If it was just scaling, you wouldn't have companies like Paypal switching to a "cool" open plan layout that the employees hate but the managers get a thrill from.

Open plan = less productivity, higher stress and more sick days. Yet, it remains the new hotness. Drives me nuts.

Ok, look, I understand that you spent a lot of time learning Haskell, and desperately want that time to not have been in vain. You have to back off the preaching though. The conversation you joined wasn't about Haskell. You barged in and made it about Haskell. On the way, to justify your comments, you have put forth some pretty ridiculous claims. Go being dynamically typed, Haskell being 30-50% quicker to develop in, glossing over the valid points about it being more difficult to learn, etc...

We get it. You don't like Go. Some of us do, and would rather have a productive discussion about how to take advantage of it's features and avoid the traps rather than get into a pointless debate about a language that we are highly unlikely to ever use. (after this discussion, I certainly never will)

You are giving the Haskell community a bad image with this kind of behavior, and I kindly request that you not reply to any more of my comments with anything to do with Haskell.

I'm a little confused here. You realize that Go is also statically typed, right? I'm not sure where any debate about dynamic languages started. The points you make about static vs dynamic are valid, just not relavent at the moment.

It's funny, too, how you talk about "implementing a red black tree" like it's an everyday occurrence. I'm guessing you are a teacher/researcher (in which case this entire discussion makes much more sense). On any application team I've worked with (in the valley or out), implementing a binary tree from scratch would require extreme justification and literally have to be the only way possible to solve the problem.

I'm not a haskell expert (obviously), but the time it takes me to parse things like this is time I would rather spend reading 5-10x the number of lines and getting the meaning right away.

  let loeb x = fmap ($ loeb x) x in 
  loeb [ (!!5), const 3, liftM2 (+) (!!0) (!!1), (*2) . (!!2), length, const 17]

(btw, I have no idea what the hell this does. Something to do with spreadsheets, apparently. I found it on http://www.haskell.org/haskellwiki/Blow_your_mind, which has enough cleverness to make me want to cry)

I've seen cleaner and more readable code in production haskell, but this sort of thing happens enough that I'm very cautious.

Haskell (and most of the other languages mentioned) is exceptionally clever. This, above all else, is it's downfall. For me, especially when tasked with building a high productivity development team, clever code is a ticking time bomb. It's easy to write, but hard to maintain and modify. It requires more mental ram to analyze any given piece of code, and is much more difficult for multiple programmers to contribute to. It's tiny, to be sure, but, again, I think that is negative, not a positive. Maximum clarity is not minimal code.

Go, on the other hand, is not clever. It's boring as hell, honestly. This is a Very Good Thing® when it comes to building out a dev team, and I feel, the single biggest reason Google put the resources into creating it.

As for the crashing, of course I see some dangerous areas. Educating developers on avoiding a small regions of pitfalls is much easier than managing a team of clever coders though.

Round 4 of these tests is what triggered my dive into Go this past month, and it has been a revelation. If you add in the concurrency capabilities, the language simplicity, and nice balance between overly terse syntax (Python one liners...) and overly verbose typed languages (Java), the whole package is even more impressive.

The only real thing I think it is missing is a "high productivity" application framework like Rails to elevate it from "damn, I'm impressed" to "it would be ill advised to use almost anything else".

</reluctant fanboy rave>

Very interesting demo. I would suggest inverting the click to drag direction. Almost every other drag to pan interaction, from google maps to touch devices, uses the opposite mode. Very jarring and counterintuitive.