Hacker News Reader

Hacker News

Comment by dmitriid | Hacker News Reader

Parent Full thread

dmitriid

> Does this strike you as idle theoretical self-enjoyment?

It does.

How many PhDs does one require to understand/correct/debug all the :> and :<|> etc.?

View on HN

Speaking from experience, zero.

> debug

But the whole point of a good compiler is that it tells you when you're wrong! (Instead of having to write hundreds of tests (and thousands of Node test runners).)

> :> and :<|>

You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later.

Observe:

    type API = "polls"                                           :> Get  '[JSON] [Poll]
          :<|> "polls" :> Capture "question_id" Int              :> Get  '[JSON]  Poll
          :<|> "polls" :> Capture "question_id" Int :> "results" :> Get  '[JSON]  PollResults

The :> operator separates parts of a path, and the :<|> separates different URL patterns. This is the equivalent of this API from the Django documentation:

    urlpatterns = [
        # ex: /polls/
        url(r'^$', views.index, name='index'),
        # ex: /polls/5/
        url(r'^(?P<question_id>[0-9]+)/$', views.detail, name='detail'),
        # ex: /polls/5/results/
        url(r'^(?P<question_id>[0-9]+)/results/$', views.results, name='results')
    ]

The only difference is it has less regexes in it, is capable of being checked for nonsense by a compiler much smarter than me, and gives you the aforementioned "server for free". I have had URL pattern-match errors with Django in the past, and having your compiler check that there aren't any is excellent.

Easier to maintain? Check.

Easier to read? Check. (If nothing, because of the lack of regexes.)

Defines the response type too? Check.

Easy to refactor? Check! Tired of typing "polls" at the beginning? Just lift it out: turn

    type API = "polls"                                           :> Get  '[JSON] [Poll]
          :<|> "polls" :> Capture "question_id" Int              :> Get  '[JSON]  Poll
          :<|> "polls" :> Capture "question_id" Int :> "results" :> Get  '[JSON]  PollResults

into

    type API = "polls" :> 
             (                                            Get  '[JSON] [Poll]
          :<|>  Capture "question_id" Int              :> Get  '[JSON]  Poll
          :<|>  Capture "question_id" Int :> "results" :> Get  '[JSON]  PollResults
             )

Types are first-class :)

> How many PhDs does one require to understand/correct/debug all the :> and :<|> etc.?

Definitely less than it takes to become comfortable with the quirks of literally everything in JS: perhaps you should give something an honest shot before telling people who have derived real-world benefits from using it in production that it's useless?

> Speaking from experience, zero. You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later.

So, basically, "learn this thing without understanding what it does" :-\

Reminds me of teaching Java to newbies: "oh, just type this syntax, you have to memorize it, don't worry about it".

> Definitely less than it takes to become comfortable with the quirks of literally everything in JS: perhaps you should give something an honest shot before telling people who have derived real-world benefits from using it in production that it's useless?

A real app is not just "hey, memorize this DSL and type it". I've found Haskell unapproachable on multiple occasions. And yes, I've completed my obligatory "Haskell from first principles" and "Learn You a Haskell for Great Good!" :)

Well, Servant isn't introductory Haskell material. My point was to show that the advanced type system features of modern Haskell are useful in the real world, for, e.g. building webapps that real people use and ship to production.

If you've picked up the stuff in LYAH, you're ready to learn what type operators are (that's where :> and friends come from, they're just things like Maybe but written infix, so they're probably defined as

data a :> b = ColonPointyThing a b

or something like that.) Servant then pattern-matches on these types, essentially. For instance, if I can handle an API that serves endpoint A, and one that serves endpoint B, I can handle an API that serves both:

    instance (Handler A, Handler B) => Handler (A :<|> B) where

       handle req = ...

That's the idea.

You'd hardly expect a beginner to pick up, I dunno, using React and Redux on a Webpack hot-reloadable setup on day 1 of "Javascript 101", but React is one of the best ways to sell modern web development (at least when I've been buying).

The problem is basically how to arrive at the "same level" in Haskell and in JS.

Basically: what does it take to define (or even to just understand) a type-level DSL in Haskell, and a sufficiently advanced library in Javascript.

I can take apart almost any JS library and see/understand how it works. How much type-foo do I need to understand Servant? Or any other sufficiently complex Haskell library (a friend of mine has struggled mightily with Yesod and gave up after a month or so).

I'm pretty sure you'll be able to follow the Servant docs, which are quite nice:

https://haskell-servant.readthedocs.io/en/stable/

There are definite advantages, and if you're willing to put in as much work as one, say, unconsciously puts in while setting up JS frameworks, understanding libraries like this is definitely doable. (Without the dissertation.)

The docs are nice, but they complement the code :)

Basically to actually understand what's going on, I'll need to learn DataKinds (at the very least).

And just to implement something as simple as BasicAuth, this is what I have to start with (https://haskell-servant.readthedocs.io/en/stable/tutorial/Au...):

  {-# LANGUAGE DataKinds             #-}
  {-# LANGUAGE DeriveGeneric         #-}
  {-# LANGUAGE FlexibleContexts      #-}
  {-# LANGUAGE FlexibleInstances     #-}
  {-# LANGUAGE MultiParamTypeClasses #-}
  {-# LANGUAGE OverloadedStrings     #-}
  {-# LANGUAGE ScopedTypeVariables   #-}
  {-# LANGUAGE TypeFamilies          #-}
  {-# LANGUAGE TypeOperators         #-}
  {-# LANGUAGE UndecidableInstances  #-}

You rarely need anything beyond regular JS to understand the inner workings of most libraries.

Servant isn't the "simplest" way to get BasicAuth: you get what you pay for.

You can just use one of the raw HTTP servers, like wai or something. They expose an interface not unlike the ones you'll find in, say, Go or C++ or Node or something.

Also:

  {-# LANGUAGE FlexibleContexts      #-}
  {-# LANGUAGE FlexibleInstances     #-}
  {-# LANGUAGE MultiParamTypeClasses #-}
  {-# LANGUAGE TypeOperators         #-}
  {-# LANGUAGE UndecidableInstances  #-}

These extensions only serve to lift a couple of restrictions that the compiler imposes because the original Haskell Report did. DataKinds and TypeFamilies are the real "new ideas" that you need to pick up after a book at the level of LYAH to understand Servant.

> Servant isn't the "simplest" way to get BasicAuth: you get what you pay for.

But that's not what I complained about ;)

It's funny how in a separate thread someone insists that I have to understand the whole concept of a monad, its three laws, read Wadler's paper etc.

In his thread however, it boils down to: oh, just memorise these lines of code, and just blindly copy-paste them wherever.

So, my complaint is: to actually understand what's going in the "simplest way to do BasicAuth" I need a whole lot more than just look at the code.

I need to understand why I need no less than ten (!) language extensions before I even begin to implement BasicAuth. And five of them just to workaround some Haskell limitation based on some report from 1998 (I'm guessing)? What happens when I move on to OAuth? What will I need then?

Also, "oh, you don't really need PhDs in type theory to use Servant" slowly descends to "oh, here are two things regarding types that you'll have to learn". On of them has no useable documentation except some comment on StackOverflow. The other one requires you to be well-versed in type theory.

Hence my complaint about "you need a PhD in type theory to work with Haskell".

> "simplest way to do BasicAuth"

The simplest way to do BasicAuth in Haskell isn't Servant. I feel like you're intentionally misinterpreting what I'm saying.

As for resources, here's a great intro to type-level Haskell:

http://www.parsonsmatt.org/2017/04/26/basic_type_level_progr...

> For some reason, functions that operate on types are called type families.

That's the kind of thing you need to know.

I doubt the average JS user knows how V8 optimizes execution of code, or whatever. That's what your insistent complaints about type theory amounts to: none of the articles I'm linking to mention inference rules or type judgments or what-have-you. That's what all the research papers about Haskell are for, which you do not need to read to use this language. Even advanced Haskellers don't do type theory (category theory, maybe, not type theory). Only a couple of people working on the compiler do.

More DataKinds:

https://stackoverflow.com/questions/20558648/what-is-the-dat...

http://ponies.io/posts/2014-07-30-typelits.html

https://www.schoolofhaskell.com/user/k_bx/playing-with-datak...

> The simplest way to do BasicAuth in Haskell isn't Servant. I feel like you're intentionally misinterpreting what I'm saying.

True, I re-read what you wrote, and argh. I need to learn to read.

> As for resources, here's a great intro to type-level Haskell: > That's the kind of thing you need to know.

So, we're basically returning to the root of my complaints

> I doubt the average JS user knows how V8 optimizes execution of code

Wait. Are you telling me now is that writing a BasicAuth implementation in a "simple library that doesn't require you to have a PhD in type theory" is on the same level of complexity as knowing the inner workings of an advanced Javascript VM?

> That's what your insistent complaints about type theory amounts to: none of the articles I'm linking to mention inference rules or type judgments or what-have-you.

No, they don't.

I'm looking at Servant and its examples. In order to write an extremely simple and basic piece of code, I, as a programmer:

- have to pull in no less than 10 language extensions

- five of those extensions are just workarounds some obscure Haskell rules (?)

- in order to understand just the basics of what's going on in there I need to know why when and where these extensions are used, how they work etc.

What happens the moment I step outside the bare necessities of the extremely simple BasicAuth implementation, for instance?

> More DataKinds:

This exactly what I wrote: as soon as you step outside into a real world of Haskell, oh "here's a list of increasingly obscure things you need to know. Maybe two people on StackOverflow know about them. For the rest, please proceed to your nearest university to obtain a PhD or two".

Your argument seems to be that "Real World Haskell" uses obscure features that I and many others don't understand, thus Haskell is complex. This is true if it is (a) impossible to write "Real World" Haskell without using these features and (b) that these features are truly complex and not just unfamiliar.

An alternative hypothesis to (a) is that Real World problems can be solved by simple Haskell, but more sophisticate Haskell features pay their way often enough that skilled practitioners choose to use them nearly always. I don't know if I completely buy this, but I also don't know that I completely buy that there aren't examples of Real World Haskell that are simple.

Of course (b) is easy to criticize and painful to do so since it'll ultimately be this indefensible argument of "if only you knew what I know then you'd agree with me" which I think is stupid. Unfamiliarity is a complexity since it forces investment on all that would learn it---languages which avoid unfamiliarity are faster and more valuable tools for avoiding forcing that investment.

The only counterargument is a global one: if these techniques _are_ worth the investment then they will over time have an increasingly large impact on the culture of programming at large. Already this is coming true with first class functions, immutable data, preference for stronger typing, option/maybe types. Your personal investment into learning further ideas may be worth it if they pay out over a longer time period either by preparing you for where things are going (speculative) or by diversifying your thought process immediately (less speculative).

So you get people encouraging folks to learn Haskell because they personally have made the judgement that learning these things is great. If you're unconvinced that's a totally reasonable position to take. OTOH, learning new things can be fun and there's at least a small hill of anecdotal evidence that these things can pay their way at times.

> OTOH, learning new things can be fun and there's at least a small hill of anecdotal evidence that these things can pay their way at times.

Life is finite, number of things to learn is near-infinite.

Do I have the lifetime to learn 10 Haskell language extensions to understand how the most basic piece of code works?

Why are you asking me?

If it's to imply that the answer is "obviously not" so as to project it to other readers then why are you trying to answer for them?

Clearly others have decided that what you suggest is either unnecessary or worth it. But it's your choice.

> I doubt the average JS user knows how V8 optimizes execution of code, or whatever. That's what your insistent complaints about type theory amounts to: [...] Only a couple of people working on the compiler [use type theory].

> Wait. Are you telling me now is that writing a BasicAuth implementation in a "simple library that doesn't require you to have a PhD in type theory" is on the same level of complexity as knowing the inner workings of an advanced Javascript VM?

I rest my case. You're not arguing in good faith here, although you seemed to be doing a pretty good job at times. I'm saying that knowing enough to be able to add big new features to the Haskell compiler, like the computer scientists who drive GHC development, is similar to knowing how V8 works. :)

> I'm saying that knowing enough to be able to add big new features to the Haskell compiler, like the computer scientists who drive GHC development, is similar to knowing how V8 works. :)

Once again: THIS IS NOT WHAT I'M COMPLAINING ABOUT

I wonder if you have enough good faith to even see what I'm talking about.

>> Speaking from experience, zero. You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later.

> So, basically, "learn this thing without understanding what it does" :-\

> Reminds me of teaching Java to newbies: "oh, just type this syntax, you have to memorize it, don't worry about it".

I don't think what's recommended is the same.

Let's consider this quote:

--- start quote ---

> :> and :<|> You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later.

--- end quote ---

This is exactly what's recommended: just blindly type these things, your understanding is not required.

It becomes worse. Link: https://news.ycombinator.com/item?id=14890937

You need 10 language extensions to implement the simples things. Answer to that complain?

Oh, five of them are just workarounds [so, just blindly copy-paste them]

Reply on news.ycombinator.com