mrkgnao

Yes, you should care about the laws!

They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor. I mean, you can't call something with a "flatMap" method and a "return" method a monad! There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly.

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.

It's code reuse for concepts. Wouldn't you agree that reusing intuition about things is good? It's the same as knowing what big-O is instead of just memorizing "bubble sort is slower than insertion sort, insertion sort is sometimes faster than quicksort but usually not", or knowing what concurrency is instead of memorizing the API of a library in your favorite language.

Demonstrate a pair of tutorials aimed at the same level of reader, one in JS, and one in Haskell, where you end up with a better understanding of the idea of a monad reading the former (as opposed to the implementation of the Monad instance for a list).

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.)

Type classes are basically interfaces from Java. I'm guessing from your other comments that you know Java (and have read LYAH), so this is actually trolling. The majority of people writing the goddamned Haskell compiler don't have PhDs, they're people using it in industry.

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).

Sure! I don't disagree: Haskell learning materials are a far cry from adequate, and we definitely need to learn from, e.g. the Rust/Elixir/Elm communities here. For now, this is worth trying:

http://haskellbook.com/

Also, #haskell on IRC has been, without a doubt, one of the friendliest learning environments I've ever seen. Drop by sometime if the mood strikes you. :)

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?

I hadn't really finished editing my comment then. (I was eating at the time, haha.) I just saw your reply now.

> You need a PhD in type theory to get anywhere.

That is extremely false. Haskell isn't even a good playground for academic type theory -- you'd want Agda etc. for that. The development of the language over the last few years has been characterized by pragmatism and a focus on backwards-compatibility, which is why you can take code from something like ten years ago and have it run without issues on modern versions of the Haskell compiler with little to no modifications. (Let's not talk about how long code written in "modern" JS lasts.)

And I'd really like to see type class constraint resolution with functional dependencies, or Hindley-Milner type checking, or something of that sort implemented in "5-10 lines" of JS.

"There he goes again with his mumbo-jumbo," you say. That's right, you don't need to care about those things to write Haskell. What you meant is implementations of typeclasses ("interfaces") like Monad, Functor, and so on: they don't take much more code in Haskell.

  Array.prototype.chain = function (f) {
    return this.reduce((acc, it) => acc.concat(f(it)), [])
  }

  instance Monad [] where
    xs >>= f = concat (map f xs)
    return = pure

And we didn't even have to go the "this" route! Notice that your 5 - 10 lines of JS don't let you write code that works in any monad, whereas I can easily write

  whenM :: Monad m => m Bool -> m () -> m ()
  whenM cond action = do
    condition <- cond
    if cond then action else pure ()

In Elm, you'd have List.whenM, Array.whenM, Maybe.whenM, ... or a straight-up false type signature like their Eq ones, and in JS, a bunch of prototype methods with no unifying threads.

--

As for an example of why I think Haskell has the right ideas (few of us will say it's the "best language evar"):

I'd really like to see a JS version of the Servant library, which takes an API spec for a server and actually generates a fully functional server from that. Here's a description:

https://news.ycombinator.com/item?id=14149200

Does this strike you as idle theoretical self-enjoyment?

The solution isn't more "pragmatism", it's an actual "incredibly powerful type system" like Haskell's. In my projects JSON decoding is just

    instance FromJSON Foo

and that's it.

I really think the only thing differentiating these static site generators from each other is how pretty the demo site's CSS is. :/

Ivy looks great, though.

Do-notation strikes again.

The Yi editor contains a minimal Emacs-like interface.

https://github.com/yi-editor/yi/

For those who have not heard of him, a good introduction is his set of improvisations on Bach's Goldberg Variations.

"Goldberg Variations / Variations": https://www.youtube.com/watch?v=V8WGcjB6ryI

Discussion: http://dantepfer.com/blog/?p=444

Also, the animations are stringly reminiscent of the work of Stephen Malinowski ("smalin"). The one around 3:00 is similar to the visualization he made for a guitar transcription of Clair de Lune, but the "balls" look like Euler's Tonnetz[0] grids.

Edit: I commented before reading TFA, where this is referenced. Silly me.

[0]: https://en.wikipedia.org/wiki/Tonnetz

That's the way I format my bigger HN comments. Didn't know [this](wasn't) part of the Markdown standard, though. Thanks!

HN doesn't support full Markdown. :(

Here's an overview I wrote a while back.

https://news.ycombinator.com/item?id=14149200

The clear dark pattern here should also have been addressed: Kite is listed with all its shiny features, whereas the alternative simply gets called inaccurate and incomplete. Local analysis does have some clear advantages over Kite, even excluding important privacy concerns. What if you're offline or are in an area with poor network coverage?

https://kite.com/static/media/autocomplete-python-flow.690d3...

The use of dark patterns is more of a policy/"culture" thing that people won't exactly "knock" (although there was a comment on the HN thread last week about this) or demand the removal of, but it does speak to how Kite is willing to operate, not just pre-minimap fiasco, but going forward too.

Edit:

The link to the PR in the post isn't the point here, it's the propensity to write misleading copy targeted at thousands of devs who had never heard of Kite that went unaddressed. Open source is extremely trust-based (how hard was it to believe that a text editor plugin of all things was doing funny things?), and Kite needs to talk about whether it will continue to behave as a potential bad actor.

Right now, all the post contains is an apology for a PR fiasco that occurred due to something akin to a miscalculation, not a deliberate onboarding strategy.

> The problem is that ligature substitution is “dumb” in the sense that it only considers whether certain characters appear in a certain order. It doesn’t have any awareness of the semantic context.

True, which is why Iosevka has language-specific ligatures that a sufficiently smart editor (I think the "JS types", like Atom/VSCode, have CSS for this) can use to ligate (?) intelligently.

You mean the screen flicker is from ... Iosevka? :(

You can probably tweak a couple numbers in parameters.toml or something. I made my own weight in between normal and medium, for example.

"LSP for indentation" :)

Hey! Tech-death isn't what I listen to nowadays, mostly, but it's where I started from. I learned to appreciate complexity in music from there, and branched out to other things. Still do enjoy the occasional Gorguts listen, though.

(Your link is excellent.)

Idris isn't difficult to use for things that don't require tons of library support (since there aren't many libraries to speak of yet), unlike Agda, which is far from a programming language in the usual sense (it's a proof assistant, and you're only really supposed to typecheck stuff with it).

You can just skip messing with the termination checker (just don't mark your functions total) in Idris and write Haskell-ish code. The occasional rough edge aside, it's not hard to write the kind of programs we're talking about here: and if you want to prevent DDoS-like infinite looping, put the "total" annotations back in.

To pick just one: mutable state by default is very difficult to justify as being a decision intended to promote security in a tool that is literally meant to construct financial/contractual instruments.

Related: Christian Muenzner is an extreme metal guitarist who was diagnosed with focal dystonia in his left hand. He was part of Obscura, one of my favorite metal bands ever.

https://en.wikipedia.org/wiki/Christian_Munzner#Focal_Dyston...

--

https://www.youtube.com/watch?v=gAPpXcvGpps

Listen to this from about 4:00 onwards, and tell me if you'd ordinarily be able to guess that the sounds you hear at 4:20 or so came out of a guitar. I wouldn't, at least not at once.

After the diagnosis, he was faced with a, uh, unreliable left hand. There was nothing to do but take his right-hand "tapping" abilities to insane levels. :)

They're called "caller tunes" in India. Used to be really popular a few years ago. Now they're a bit less common.