mrkgnao

> estabilished idioms

I'll note that The Fine Article is about why one of those established idioms confuses newcomers. Even better, it bites people because the type of an interface needs to be nil for something to work. (Insert appropriate expression of astonishment here.)

Enforcing patterns hiding inadequacies in the implementation works less well than one would imagine, e.g. look at all the languages that Go sought to improve upon and the baggage of "design patterns", GoF-alikes, etc. that they brought with them.

> return early

I was just going off what I found at https://blog.golang.org/error-handling-and-go.

I assume you meant this (in Go-ish pseudocode)?

   result, err := Foo1()
   if not err {
     Panic(err)
   }
   
   result2, err2: = Foo2(result1)
   if not err2 { 
     Panic(err2)
   }

This might allow you to skip the nesting of blocks, but why would you do this when multiple languages exist where you don't have to thread around error messages everywhere? For instance,

   result1 <- foo1
   result2 <- foo2 result1

(Yes, that's Haskell syntax, but you can do things with a similar lack of pain/verbosity/error-prone-ness in many languages.)

> Go is an open language

From what I've seen, this holds only as long as you keep the proposals minimal and restricted to aforesaid hacking around the limitations built into the language. I'm happy to be shown evidence to the contrary: have there ever been any proposals, reacted to in a not-completely-negative way, that were like "uh, maybe we didn't have the right idea about <something basic>, let's do this instead"?

I'll argue there won't be. Every community has a culture: Go's is delightfully warm, friendly, and inclusive, but also surprisingly distrustful of learning that there are easy-to-understand but powerful language features they could be using to write maintainable code without "getting a PhD in type theory from the nearest university" (to strawman a certain [type of] person [I've often encountered when arguing about these things]).

Go has done many things right (aside from the community, good concurrency and really fast compiles come to mind) but language design is not one of them.

> I see no reason that a good proposal and example implementation wouldn't be accepted for addition to go.

I'm sorry to bring the age-old "but generics" thing up, but how do you even implement (what Haskell-alikes call) Functor without parametric polymorphism?

The only ways I see are

a) Elm-style List.map/Array.map/Maybe.map

b) Rust-style Functor/Monad operations on specific types like Result

Which of these do you think Go would be more receptive to?

Does this look like a design mistake or a bit of oversight? There is no excuse why one should have to do

   result, err := Foo()
   if err != nil {
      ...
   }

over and over again in a language designed after 2000. The usual argument is that Go's simplistic design "reduces complexity", yet explaining something basic as why the error handling system doesn't behave the way one expects needs you to know how the compiler represents interface types.

The next decade will see Go adding in most or all the complexity real-world software asks for, without ever admitting that maybe it should've been supported from the beginning without the hacky workarounds.

> Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids[...]

Even though the bit in italics is pretty much the opposite of the "Go/JS pitch", I'll bite.

Sure, learning to code at a high level means you need to take time to learn things (which is the opposite of the pitch). I just don't get why teaching yourself to "navigate the [brokenness]" of a language that was out-of-date the day it was released is preferable to learning to write in an expressive language that won't artificially handicap you or provide you with an arsenal of footguns.

In all the time you were casting to and from interface{}, you could be exploring and using powerful and practical new ideas that make it less likely you'll suffer for failing to check one of those "err"s.

Go is a lesson in how complexity can't be eliminated, only distributed properly from the beginning so that one doesn't have to hack it in later with messy special-casing that needs you to know how the compiler represents things under the hood.

What happened to "lightweight typesystem that reduces cognitive load"?

There are many, many, many "legitimate" "real-world" situations where you need data structures ouside of the two or three Go gives you by default. Queues? Dequeues? Trees, for the love of $DEITY? Tries? Sets?

Effective use of Golang is really teaching yourself to think that anything beyond the language is a useless distraction or some kind of academic pretension. I won't go so far as to call it S________ S_______, but this is textbook Blub.

Mhm, sure, I can go back a couple decades for the sake of argument.

Say I can make do with instances of my data structure for, I don't know, int8, int16, and strings.

What is the Go way to implement a generic data structure that can't be trivially realised by wrapping a couple maps and arrays into a struct (without using interface{} and throwing away the safety Go's type system, such as it is, provides)?

Elliptic curves are "generalized modular arithmetic" only in the sense that they involve a different kind of addition law (the set of points on a nice EC is a group).

Also, you can look at the points on an elliptic curve where you allow the coordinates to be real, complex, rational, or even the integers mod p (any field will do), so the last choice gives you a closer link with modular arithmetic. It's best to treat ECs as their own weird, wonderful beasts!

Neither is well-posed.

Humans, contrary to what they may tell themselves, are not effective, impartial judges of "merit". Diversity initiatives correct for this deficiency.

In general, number theory is notorious for containing many questions that are accessible to a layperson but whose proofs rely on arguments that are so difficult that even the basic idea of how the argument works takes many years of study.

Fermat's last theorem is an example, because it can be shown to be equivalent to, among other things, a very deep statement about elliptic curves (yep, the same thing The Fine Answer is about!) that Andrew Wiles proved.

https://en.wikipedia.org/wiki/Modularity_theorem

So what do I mean by "well-connected"? Elliptic curves are associated with

a) number theory - many questions about number theory boil down to finding points on elliptic curves with rational coordinates

b) algebraic geometry - elliptic curves are very "nice" from this point of view, and they are complicated enough that you can say interesting things, but not so complicated that you can't say anything

c) complex analysis - over the complex plane, an elliptic curve is a torus. You might have seen how a torus can be formed by identifying opposite edges of a square, and an elliptic curve is hence "a quotient of C by a square lattice". Modular forms, which are creatures of complex analysis with deep applications to number theory, are naturally defined in this framework.

and many more things I don't know about. They're in a sort of "sweet spot" and act as a bridge between multiple parts of mathematics.

For anyone looking to learn more about elliptic curves, which are astoundingly "well-connected" as math topics go, here's a good book that should be accessible to anyone with some calculus under their belt:

https://www.amazon.com/Elliptic-Tales-Curves-Counting-Number...

It's not a textbook, which is both good and bad. In my case, it did a good job whetting my appetite for more!

A really well-written and not-extremely-difficult undergrad textbook on elliptic curves:

https://www.amazon.com/Rational-Points-Elliptic-Undergraduat...

(Non-affiliate links, just so you know.)

Um, isn't that "constant-time in practice"? (Something like log-star.) Am I missing some matter of convention here?

You're welcome! http://haskellbook.com/ is the currently recommended book and is worth looking at when you start learning.

A lot of the ideas used in everyday Haskell originated in category theory (similarly to how all our programming languages eventually come from Turing machines, the lambda calculus, and so on), but command over the mathematical ideas is absolutely not required to "get into Haskell" or even to use it productively and fluently. It is certainly something you should look into if you want to

a) know why some things are done the way they are (in case you're not satisfied with "this works!"), or

b) if you want to find inspiration to write a certain kind of library: Haskell is one of the few languages that has, as I like to call it, "over 50 years of documentation".

--

To elaborate: a category is a bunch of objects, and functions (morphisms) between the objects. The types in a language like Haskell form a category (called Hask in this case) where the objects are the types and morphisms from one type to another are the functions that go from the former to the latter.

A lot of things done in Haskell are instances of general constructions from category theory applied to Hask. Comfort with these general constructions certainly helps to illuminate many ideas.

For example, the great trifecta of Haskell abstractions comprises three interfaces ("typeclasses") called Functor, Applicative, and Monad, which are used everywhere. Each of these corresponds to a concept from category theory: for instance, what a Haskeller calls a "Functor" is what is categorically called an "endofunctor on Hask". Among users of the language who know any category theory at all, most have some familiarity with things at the level of what I've just said, but not much more. A knowledge of category theory at any higher level (like in the linked repo) is not at all common, statistically.

Also, not many of the common libraries are based on deep categorical ideas (lens [0] is an important exception) but even then, knowledge of the mathematics is useful if you want to dig into how the ideas are implemented, not if you're happy just using them. Learn as little or as much as you'd like.

[0] https://github.com/ekmett/lens/wiki/Examples

(Python would be harder for this than Java.)

This link posted a couple days back may be of interest:

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

Shaadi.com owns a number of related websites targeted at particular Indian communities. I live in Kolkata and ads for bengalimatrimony.com are everywhere (in a manner of speaking).

The use of monads is a side-effect (ha!) of committing to purity throughout a language, and that's what FP is being equated to: pure statically-typed FP.

(You can argue about how justified that is, of course. I'm not going into that, but you might want to see what John Carmack has to say[0]. No, he doesn't end by saying "we should all convert to the church of Haskell now", but he does talk about how large-scale game programming refactors are made easier when you're working with no (or very disciplined) side effects.)

Monads are not the only way to deal with effects while keeping purity, although they were the first discovered and so on: algebraic effect systems as in Koka[1] (and as simulated in Idris or PureScript) are another alternative. Koka infers effects, so it's probably easier for a C-family programmer to pick up (I know little about it, though).

[0]: https://www.youtube.com/watch?v=1PhArSujR_A

[1]: https://www.microsoft.com/en-us/research/project/koka/

It won't satisfy the properties you've come to expect from the implementations you know for lists, optionals (Maybe), and so on.

Suppose you're going over some code, where you have something of the form

   xs >>= someFunction

(where xs is a list) and you change someFunction to "return":

   xs >>= return

Then you'd expect, from experience, that you can rewrite this to just

   xs

(which you can check works with all the monads you know about) but that doesn't hold for this wonky definition of the Monad instance for lists. Indeed, note that return for lists has the definition

   return x = [x]

so, with our bad >>=,

   [1, 2, 3] >>= return
   = concat (reverse (map (\x -> [x]) [1, 2, 3]))
   = concat (reverse ([[1], [2], [3]]))
   = concat [[3], [2], [1]]
   = [3, 2, 1]

which is not the same as [1, 2, 3].

https://wiki.haskell.org/Monad_laws

What about KaTeX? It doesn't suit my needs (I need to use the unofficial Xy-pic extension for commutative diagrams) but few users have those constraints, and KaTeX is significantly faster.

Huh, nice.

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

The unpleasantness arises when writing Monad instances that don't follow the laws. Setting your disingenuity aside, try using

  xs >>= f = concat (reverse (map f xs))

or

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

(I don't know how JS works, but you get it) instead of

    xs >>= f = concat (map f xs)

and enjoy refactoring your code, blissfully and consciously ignorant of the laws that make a monad a monad. The laws aren't just supposed to enrich the "life of the mind".

Ah. That derives both "ToJSON" and "FromJSON", as Aeson calls them. Cool!

For people interested in Prolog-like DB systems:

https://github.com/agentm/project-m36

> Unlike most database management systems (DBMS), Project:M36 is opinionated software which adheres strictly to the mathematics of the relational algebra. The purpose of this adherence is to prove that software which implements mathematically-sound design principles reaps benefits in the form of code clarity, consistency, performance, and future-proofing.

I can imagine :) I think over in Rust-land it's something like

   #[derive(FromJSON)]

isn't it?

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

> Haskell is used by Chase Bank.

Also a ton of other financial services companies: Morgan Stanley, Standard Chartered, and so on. Facebook has, in the recent past, hired a lot of well-known Haskellers. Bunch of hedge fund-ish things do too. Jane Street uses OCaml and does a lot of AdWords targeting at Haskell users :P

I don't know a shred of "type theory" (although I'm interested): you probably mean something else. Monad transformers aren't even categorical abstractions; they evolved from the needs of Haskell users.

> Haskell has always been and remains a language not opposed to testing multiple theories of language and types design

There, fixed that for you. Seriously, why don't you make a good-faith effort to dive into Haskell (as opposed to learning just enough of the jargon to be able to troll with apparent seriousness) before lambasting the things that make it a joy to work with?