Live data from Hacker News

What I Wish I Knew When Learning Haskell

dev.stephendiehl.com

141–149 of 149 posts

Re: What I Wish I Knew When Learning Haskell

#141
post #133

Earlier quoted context omitted.

Look at the thousands of people who learned Haskell and then also felt inspired to write a monad tutorial and publish it on the internet. Your search engine will help to see just how many there are. Contrast with the number of useful applications you can actually install and run that are for some purpose that is not programming. In fact there are more Haskell textbooks you can read than haskell programs you can insta…

> What have you written in haskell that we can use? My three commercial Haskell projects are detailed here[0]. [0]: https://jezenthomas.com/projects/

Wow, these all look like well crafted. What's your web framework of choice with Haskell?

Re: What I Wish I Knew When Learning Haskell

#142
post #141

Earlier quoted context omitted.

> What have you written in haskell that we can use? My three commercial Haskell projects are detailed here[0]. [0]: https://jezenthomas.com/projects/

Wow, these all look like well crafted. What's your web framework of choice with Haskell?

I build everything with Yesod. I'm sure the others are good too; Servant seems great. But this is the one I started with, and it's served me very well for the past few years.

Re: What I Wish I Knew When Learning Haskell

#143

Earlier quoted context omitted.

I agree with this, learning Haskell was transformative for me. It changed the way I approached problems in every other language. I treat learning it as one of the 2 or 3 things that has most influenced my development skills. But the truth is that I still don't feel comfortable writing anything more than toy apps in Haskell. I'm not really sure how to unit test things when I'm passing complex monad transformers around…

> I treat learning it as one of the 2 or 3 things that has most influenced my development skills. If you don't mind, what were the other 1 or 2 things?

Unit testing and TDD

Code Complete 1st edition

Maybe Domain driven design as well

Re: What I Wish I Knew When Learning Haskell

#144

Earlier quoted context omitted.

> I treat learning it as one of the 2 or 3 things that has most influenced my development skills. If you don't mind, what were the other 1 or 2 things?

Unit testing and TDD Code Complete 1st edition Maybe Domain driven design as well

Thanks for the answer.

Re: What I Wish I Knew When Learning Haskell

#145
It's really aggravating that HN goes against it's own culture so thoroughly when it comes to Haskell. We're supposed to comment on what TFA says, not lick our wounds about how Haskell wasn't what we wanted it to be. f you can't contribute to the thrust of TFA how about creating space to listen to people who actually know what they're talking about?

Every single piece of hackneyed received wisdom and FUD in here can be easily countered if you talk to somebody with actual production Haskell experience. Speaking for myself:

- I run a startup that has production applications making money for 4 years now written entirely in Haskell with 6 devs doing nothing but Haskell (as well as engineers working in JS and our own language, Pact, yes, written in Haskell).

- When we need more bandwidth, we work with an all-Haskell consultancy that itself has no trouble finding work and is very successful in their own right.

- Before that, I built a group at a major bank writing Haskell code and getting it out in production, and outperforming Java apps.

- The tired "eww static types aren't for real business" is opinions masquerading as "facts". If you are a half-decent engineer in ANY language you can make your code refactorable for changing requirements. Whining that types makes that harder just shows your own limitations. Any decent programmer working in a strongly-typed system leverages types to make code _more_ refactorable in _less_ time with _fewer_ bugs. But hey these are just our anecdata too. Here's what I'm not doing: spreading FUD about Python or Clojure or JS, I'm too busy loving what I do.

- From a hiring perspective, Haskell programmers as a group offer an immense strategic advantage, and it's mainly _because_ they had to learn Haskell on the weekend and it wasn't handed to them. That shows passion and grit. I've built two teams from scratch now in totally different circumstances and it is simply breezy to find a wide variety of experience levels to craft a team from; they are by far the best teams I have ever worked with, with zero duds. The community is strong and excellent and helps each other out as far as job hunting goes.

Don't blame Haskell if it didn't stick, don't hate on Haskell if you find it intimidating or pointless. If anything, you should be grateful that there is a language that is actually different enough to attract a different kind of programmer, lord knows it's why I'm here: after having jobs in Java, C++, Perl, Ruby, JS, Visual Basic, Hypercard, you name it, it was nice to see that there's a different way to do things. It's really fun, there's always more to learn (not true of every language btw), and finally, it kicks serious ass on the performance side (as GC/runtime languages go).

Re: What I Wish I Knew When Learning Haskell

#146

A few years ago I accidentally deleted my entire Haskell assignment about 1 day before it was due. Within a few hours I rebuilt it from scratch. That's when I realized the power of functional programming. There's no way I have been able to recover that quickly if I had used an imperative programming language. Since that experience I've tried to follow a functional programming style whenever I can. I've realized that…

But it was a programming assignment. Building a thing fast is, outside of very few situations, not a thing to optimize for. Building something to be maintained and evolved over time by non rockstars is far far more important, IMO. Perl is great for ripping through some script quickly but it has problems for long term maintenance.

Though the interesting point here was that it made it easy to write the program fast the second time. While it should be very rare you need to write exactly the same program a second time, and can be a useful thing (albeit a hard thing) to optimize a language for if in writing a program a first time in that language you wind up with such a clarity on the problems you encountered that "solving" them again a second time feels trivial.

Re: What I Wish I Knew When Learning Haskell

#147
post #63

Earlier quoted context omitted.

Won't this have to iterate through linked lists and create multiple new heap allocations on each recursive step? Doesn't that imply n log n heap allocations just to sort a list?

Yes, but due to lazy-evaluation that won't happen until you do something with the sorted list. Your performance may just blow up in some seemingly unrelated place. My biggest problem with Haskell is how GC and lazy-evaluation makes it very difficult to reason about what the hardware is actually doing at a given point. I know there ways to inspect and control it, but I've found myself preferring languages that have si…

Right, by the time you have to control it, you are washing away all the advantages for using it.

Re: What I Wish I Knew When Learning Haskell

#148

What's up with the formatting on this page? In Firefox for iOS (same rendering engine as mobile Safari), all lines but the first one in code listings have 4-character indents, and lines use a larger-than-normal font size seemingly at random.

That's what mobile Firefox does to most of the web.

Not in my experience.

Re: What I Wish I Knew When Learning Haskell

#149

Earlier quoted context omitted.

It might have to do with the fact that webkit is mostly a deprecated browser?

1. Firefox doesn't use webkit. 2. Webkit isn't deprecated. 3. Webkit isn't a browser.

Firefox for iOS does use WebKit.
Post reply on HN