Thinking in Types • Hacker News Board

Re: Thinking in Types

#11

Post by tel » Fri, May 02, 2014, 5:42 PM UTC

laureny wrote: post #7

I'm getting tired of reading: > This is why we hear that Haskell reprise if it compiles, it works. If this were true then functions would not need bodies, you would just define their signatures and move on with life. The truth is that even with its superb type system, Haskell still needs to run your code. Your code might be statically correct but its runtime is up to you. I would prefer it if people rephrased this cl…

Well, as you go to the next steps you can use proof search techniques to do exactly that: write your types and your programs write themselves as the "only possible implementation".

This is already possible sometimes in Haskell so long as we restrict ourselves from pathological values like exceptions and non-termination. In fact, the first place this phrase shows up is Russel O'Connor talking about highly polymorphic lens code.

http://r6.ca/blog/20120708T122219Z.html

This kind of type limitation of possible implementations is called parametricity and is difficult to encounter even in most typed languages as it requires purity.

Re: Thinking in Types

#12

Post by bilalq » Fri, May 02, 2014, 5:42 PM UTC

woah wrote: 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?

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.

Re: Thinking in Types

#13

Post by tel » Fri, May 02, 2014, 5:53 PM UTC

bilalq wrote: post #12

woah wrote: 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?

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.

Re: Thinking in Types

#14

Post by cbeustwatch » Fri, May 02, 2014, 5:56 PM UTC

laureny wrote: post #7

I'm getting tired of reading: > This is why we hear that Haskell reprise if it compiles, it works. If this were true then functions would not need bodies, you would just define their signatures and move on with life. The truth is that even with its superb type system, Haskell still needs to run your code. Your code might be statically correct but its runtime is up to you. I would prefer it if people rephrased this cl…

And you know what I am tired of reading, Cedric Buest?

You trolling every programming language discussion with fake names and sock puppets relating your fake made up experiences with functional programming. Do you have no dignity?

Re: Thinking in Types

#15

Post by [deleted] » Fri, May 02, 2014, 5:58 PM UTC

tel wrote: post #10

Heterogenous lists are always coming up when people try to translate OO ideas into Haskell. It's great that this example used the barrier of heterogeneity as a reason to think harder about their design instead of barreling forward. In particular, heterogeneity causes a form of information loss via type erasure (existential typing). The problem is that this is pretty heavy machinery and is not always well-suited to su…

[deleted]

Re: Thinking in Types

#16

Post by dllthomas » Fri, May 02, 2014, 5:59 PM UTC

laureny wrote: post #7

I'm getting tired of reading: > This is why we hear that Haskell reprise if it compiles, it works. If this were true then functions would not need bodies, you would just define their signatures and move on with life. The truth is that even with its superb type system, Haskell still needs to run your code. Your code might be statically correct but its runtime is up to you. I would prefer it if people rephrased this cl…

Of course it's not at all true that anything in Haskell that compiles works for any task X. It's not even quite true that, setting out trying to build something that accomplishes X, X will always be accomplished as soon as you get it to compile. However, in my experience, it is frequently true that it is surprisingly the case - I put together something somewhat large and it works first time where in another language (that I might even know better) I'd expect to have a few bugs to fix. People joke around, but I don't think anyone actually makes the either of the stronger assertions and expects to be believed, in which case I don't really think there's a problem (but I'm sorry if it bugs you!) - on the other hand, maybe I'm being overly charitable and people really are intending the stronger forms...

Re: Thinking in Types

#17

Post by mindslight » Fri, May 02, 2014, 5:59 PM UTC

platz wrote: post #9

woah wrote: 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?

It's a good question which I think deserves thought, for now I'll just be slightly tongue-in-cheek and link this: http://www.jwz.org/doc/worse-is-better.html

Tongue in cheek? No, it's completely spot-on.

People generally learn by forming patterns from many examples, not by studying the patterns themselves. Attempts to directly communicate abstract patterns generally fails (any school anywhere: "this is boring because we are never going to use it").

Programmers are inherently attracted to building on imperfect abstractions, because that brokenness is something to latch on and set about easily solving (as it's been solved many times before and they don't even need to solve it perfectly). If the abstraction did exactly what they wanted, they would have to recognize that, understand what was given to them, and then confront the essential complexity of their problem that much sooner.

Re: Thinking in Types

#18

Post by dllthomas » Fri, May 02, 2014, 6:00 PM UTC

tel wrote: post #11

laureny wrote: post #7

I'm getting tired of reading: > This is why we hear that Haskell reprise if it compiles, it works. If this were true then functions would not need bodies, you would just define their signatures and move on with life. The truth is that even with its superb type system, Haskell still needs to run your code. Your code might be statically correct but its runtime is up to you. I would prefer it if people rephrased this cl…

Well, as you go to the next steps you can use proof search techniques to do exactly that: write your types and your programs write themselves as the "only possible implementation". This is already possible sometimes in Haskell so long as we restrict ourselves from pathological values like exceptions and non-termination. In fact, the first place this phrase shows up is Russel O'Connor talking about highly polymorphic…

The first place which phrase shows up?

Re: Thinking in Types

#19

Post by Guvante » Fri, May 02, 2014, 6:12 PM UTC

recursive wrote: post #3

woah wrote: 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?

On average, people that don't know much about software development, but want to make software, will do it using a language that has a lower cost to entry. For all the elegance and purity of a language like Haskell, it seems to be completely overwhelming for most beginners. Not all software is created by such people, but I think it explains quite a bit.

Beginners wouldn't have a problem with Haskell, the intermediates are the problem.

If you learned Java or another imperative language, picking up another imperative language is nearly trivial.

Re: Thinking in Types

#20

Post by jarrett » Fri, May 02, 2014, 6:13 PM UTC

woah wrote: 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?

I think the package ecosystem is a big barrier. I code on OS X, and it seems like half the Haskell packages I try to install fail to compile. I always get super motivated to do my next project in Haskell, but then give up when I can't install the required libraries. Maybe the situation is better on Linux.

In any case, I think Haskell will need reliable package management on at least OS X and Linux before most developers consider it a serious choice for real projects.