3 ms·

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

> "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_programming_in_haskell.html 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-datakinds-extension-of-haskell https://stackoverflow.com/questions/20558648/what-is-the-dat... http://ponies.io/posts/2014-07-30-typelits.html http://ponies.io/posts/2014-07-30-typelits.html https://www.schoolofhaskell.com/user/k_bx/playing-with-datakinds https://www.schoolofhaskell.com/user/k_bx/playing-with-datak...

dmitriid 9y ago
> 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".
- tel 9y ago
  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.
  - dmitriid 9y ago
    > 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?
    - tel 9y ago

dmitriid 9y ago

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

tel 9y ago
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.
- dmitriid 9y ago
  > 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?
  - tel 9y ago