Live data from Hacker News

Thinking in Types

robots.thoughtbot.com

71–80 of 124 posts

Re: Thinking in Types

#71
post #8
post #2

Seeing so much stuff about Haskell lately, but there seems to be a curious dearth of actual software written in it, if it's so great. How is it that janky hacked together languages like JS and PHP have huge numbers of projects built with them, while a supposedly superior language like Haskell is mostly academic? If it really makes you that much faster, where are the apps?

Well, JS is used because it's the only way to run code on a client system. If there were a byte-code available you can bet people would be using other languages. ASM.js exists, and many languages compile to js at the moment. As for PHP, lots of people still eat at McDonalds. I can't explain why.

> Well, JS is used because it's the only way to run code on a client system.

Not sure what you mean by this - I guess you're assuming the "client system" is always a web browser?

Currently, I'm writing code for a piece of middleware that is a client to a server that models networking equipment. This client then pushes hundreds of thousands of responses into a fast message queue. None of this is written in JS.

Re: Thinking in Types

#72
post #64
post #62

Earlier quoted context omitted.

> write your types and your programs write themselves as the "only possible implementation". But there are only very few type signatures for which this is true, even if you stick to totality.

In practice types often winnow the possible implementations to be a relatively small set. This effect is improved if you also include notions of law-abiding implementations as Haskellers often do. At the end of the day, it's true that implementations (don't yet) write themselves, but, more realistically, that the constraints of type and theory drive you naturally to the correct solutions even if you never once figure…

> law-abiding implementations

Are you referring to category laws?

Re: Thinking in Types

#73
post #13
post #12

Earlier quoted context omitted.

The ecosystem plays a big part in this. NPM is actually a pretty nice package manager to work with. Cabal, on the other hand, took me quite some time to setup and use.

Cabal is actually an extremely nice package manager... it just, like much of Haskell, likes to tell you things won't work far before they fail. In particular, building things with Cabal requires that everything compiles together successfully. This is a much stronger requirement than NPM and has push some more sophistication into the dependency resolution Cabal does.

This is mostly true, but I think we do see more dependency related issues than other languages. My working theory is that this is because we wind up building more small, generally useful packages that get used by lots of things and which can therefore be in conflict. I haven't set out to carefully validate this, though.

Re: Thinking in Types

#74
post #64

Earlier quoted context omitted.

In practice types often winnow the possible implementations to be a relatively small set. This effect is improved if you also include notions of law-abiding implementations as Haskellers often do. At the end of the day, it's true that implementations (don't yet) write themselves, but, more realistically, that the constraints of type and theory drive you naturally to the correct solutions even if you never once figure…

> law-abiding implementations Are you referring to category laws?

Lots of typeclasses have associated "laws" that well-behaved instances are expected to abide by.

Re: Thinking in Types

#75
post #22

On a related note: The article (quite reasonably) avoids discussion of the graphics library, but I want to know more about that side of things. I wish graphics got more attention in the Haskell ecosystem in general. The options right now are pretty dismal. There is quite literally not a single Haskell graphics or GUI package that I've been able to install on OS X. I'd love to use Haskell to build games or desktop GUI…

It's not just OSX, it's a problem (in general) on windows, too. I was trying to create my first haskell project as a web crawler. Every direction I turned I had issues installing libraries to the point where I decided it's a deal breaker because I can't write code on my preferred OS.

Even if they eventually make these transitive dependencies OS agnostic, the libraries that already exist will depend on the versions that aren't.

> I'd be willing to bet that a great many developers like me wanted to try Haskell, but gave up when they found out how many Cabal packages don't compile. I think fixing that would do a lot for Haskell's mainstream acceptance.

Exactly what happened to me.

Re: Thinking in Types

#76
post #40

Earlier quoted context omitted.

Haskell is used in the NYTimes special features group that deploys 60+/yr web apps. http://www.infoq.com/presentations/haskell-newsroom-nyt tldw: - RoR shop, too slow and can't afford to scale simply by spinning up more AWS instances. - Haskell type system results in fewer bugs, less downtime than RoR. - Haskell's Conduit library is great for information flow (e.g. scanning Twitter firehose for breaking stories). - S…

It's worth pointing out that the presenter's first language was Haskell and he's been coding in it for over a decade. LYAH won't get you from apples to expert in weeks, much less months; more likely years. Consider me skeptical -- needing to build the latest and greatest of Haskell [7.8] from source on a modern Linux distro (CentOS binary with antiquated libgmp.so.3 dependency, seriously?) is a gigantic PITA compared…

IMVUs average spin-up time for new engineers that don't know any Haskell is ~8-15 days.

I don't recommend LYAH and don't think it's an efficient way to learn Haskell at all.

My guide for learning Haskell: https://gist.github.com/bitemyapp/8739525

Should get you going quickly.

Re: Thinking in Types

#77
post #2

Seeing so much stuff about Haskell lately, but there seems to be a curious dearth of actual software written in it, if it's so great. How is it that janky hacked together languages like JS and PHP have huge numbers of projects built with them, while a supposedly superior language like Haskell is mostly academic? If it really makes you that much faster, where are the apps?

Honestly, it seems to me like if you don't understand category theory and type theory well, using Haskell will be either hard or impossible. That's what people who are into Haskell are into, and they seem to be a relatively rare breed. (I have a lot of trouble understanding these subjects, though I continue to try. I still don't know what the hell a monad really is.)

I couldn't really tell you anything about category theory. But I am beginning to grasp monads. (At least in the context of Haskell programs.)

I think the important thing is to see how they work, see what they do.

btw, you might try this video: https://www.youtube.com/watch?v=o6L6XeNdd_k

Re: Thinking in Types

#78
post #2

Seeing so much stuff about Haskell lately, but there seems to be a curious dearth of actual software written in it, if it's so great. How is it that janky hacked together languages like JS and PHP have huge numbers of projects built with them, while a supposedly superior language like Haskell is mostly academic? If it really makes you that much faster, where are the apps?

Honestly, it seems to me like if you don't understand category theory and type theory well, using Haskell will be either hard or impossible. That's what people who are into Haskell are into, and they seem to be a relatively rare breed. (I have a lot of trouble understanding these subjects, though I continue to try. I still don't know what the hell a monad really is.)

>if you don't understand category theory and type theory well, using Haskell will be either hard or impossible

Absolutely not true. I never completed a single credit of university and struggled with high school math. I don't know any type theory or category theory.

Not only am I comfortable in Haskell, I teach Haskell.

Here's my guide for learning Haskell: https://gist.github.com/bitemyapp/8739525

Re: Thinking in Types

#79
post #46

Earlier quoted context omitted.

I'm not sure which issues you're running into, but for what it's worth, I've had a lot better success using the newer cabal sandboxes[1] than just running `cabal install foo` all the time. (If you're from the Ruby world, it acts a lot more like bundler with `--standalone`). Previously, I had more issues with conflicting version constraints which I think is more of an issue with library authors and not necessarily cab…

I'd love to, but Haskell Platform ships with an old version of Cabal that doesn't have sandboxes. The new version of Cabal itself doesn't compile on the Mac. (In keeping with the theme of "nothing compiles.") Edit: At least, I can't get the new version of Cabal/Cabal Install working on my Mac.

I was able to compile Cabal/Cabal Install 1.18 and 1.20 on my Mavericks machine.

Have you sought help from the #haskell IRC channel?

Re: Thinking in Types

#80
post #2

Seeing so much stuff about Haskell lately, but there seems to be a curious dearth of actual software written in it, if it's so great. How is it that janky hacked together languages like JS and PHP have huge numbers of projects built with them, while a supposedly superior language like Haskell is mostly academic? If it really makes you that much faster, where are the apps?

Honestly, it seems to me like if you don't understand category theory and type theory well, using Haskell will be either hard or impossible. That's what people who are into Haskell are into, and they seem to be a relatively rare breed. (I have a lot of trouble understanding these subjects, though I continue to try. I still don't know what the hell a monad really is.)

Just throwing my voice into the chorus, I know nothing about category theory either, and I don't think that hinders learning Haskell.

I do think there is a subset of Haskellers who use category theory to prove certain ideas and they are able to easily express that in code. However I haven't found it necessary to understand the theory behind why something is sound in order to practically use their work in my projects. That says more about Haskell's expressiveness than the target audience to me.

Setting aside years of imperative (and also OO) programming and learning a different approach to solving problems has been the biggest challenge for me, by far. That's why I agree wholeheartedly with https://news.ycombinator.com/item?id=7687200

Post reply on HN