Function application in most languages in which 'f x' means 'apply the function f to the argument x' is left associative.
So `map inc [1,2,3]` is the same as `(map inc) [1,2,3]`.
This is consistent with the fact that -> is right associative.
So in Haskell, we usually say
map :: (a -> b) -> [a] -> [b]
Which is usually interpreted as 'If you give me a function which can turn a's into b's, and then you give me a list of a's, I can give you a list of b's.'
But it is exactly equivalent if we write the type of map like this:
map :: (a -> b) -> ([a] -> [b])
Which I like to read as 'If you give me a function which can turn a's into b's, I can give you a function which turns a list of a's into a list of b's.
It's certainly the case that ML-style languages have a syntax that can be unfamiliar to outsiders, but I would disagree that the syntax is ambiguous. Indeed, Standard ML (another functional language) is one of the few languages to be formally specified.
Okay. I know a lot of languages, but not really functional ones (I have used Haskell, OCaml and Lisp (though that's not like this), but not much and long ago).
Maths is more type-dependent in the absence of parentheses. E.g. sin cos⁻¹ x = sin(cos⁻¹(x)), but A cos⁻¹ x = A × cos⁻¹(x).
By "ambiguous" I mean to people looking at the code. Obviously it's unambiguous and well-defined to the computer.
The rule is simple to learn and perfectly consistent once you know it, even to a human programmer. This is in direct contrast to mathematical notation, which remains ambiguous and context-dependent forever.
While it's been over a decade since I first learnt this style of functional languages, I don't remember being confused by application syntax. It also helps that function application binds more tightly than anything else.
I don't think it's any great indictment that it is not immediately understandable to someone who does not know the rule. There will be lots of other things someone will not be able to understand in a Gluon program, unless they know Gluon. It's perfectly reasonable to expect someone to learn a programming language before they write code in it.
I'm not sure what you mean by "appeal." But, it seems to me that if P = NP, and if we can find a constructive proof of this fact, i.e. someone presents a P-time algorithm A_L deciding an NP-complete language L, the field of CS in a sense would get much less interesting, because although we would have answered arguably the most important question ever posed, there would be much less of a need to research and develop efficient algorithms or approximation strategies. We'd probably just focus on trying to improve the runtime of A_L and the reductions from other NP languages.
Yes every field is of interest to its specialists. But the popular appeal is that comp sci promises the ultimate explanation of a materialistic reality. At least this was its appeal when I chose it for my major, and it drives the religious transhumanism and the AI hype and arguably the funding of IT. But if the public learns seemingly trivial problems are inherently intractable or impossible for computers, that glamorous spectacle will shatter.
I don't use hub much, but I prefer not to alias it even though that's what they recommend as well.
I think it's best to keep them separated so you know what stuff is coming from hub and what's in vanilla git instead. "git" is already synonymous enough with "GitHub" in many peoples' minds without including GitHub-specific functionality in your mental model of the command line client.
Completely unrelated to the article, but I'm curious what people's thoughts are on full-width lines of text characteristic of unstyled HTML.
I've seen some[1] bemoan its impacts on readability and others[2] complain about websites which artificially restrict themselves to (what can be) a narrow slice of the viewport.
I begin to think that nowadays websites are just designed for "zooming in" in mind (very small fonts, too many space etc.).
So maybe we shouldn't complain. These websites are just meant to be zoomed.
Although some web developers are cruel and block zoom with meta tag (I never understood why some developers did that, maybe for trolling people with poor sight?).
Looks like graphics.isManipulating is a gotten variable, not a function. That breaks the kevin clock example and the commented-out part of the piston example.
So `map inc [1,2,3]` is the same as `(map inc) [1,2,3]`.
This is consistent with the fact that -> is right associative.
So in Haskell, we usually say
map :: (a -> b) -> [a] -> [b]
Which is usually interpreted as 'If you give me a function which can turn a's into b's, and then you give me a list of a's, I can give you a list of b's.'
But it is exactly equivalent if we write the type of map like this:
map :: (a -> b) -> ([a] -> [b])
Which I like to read as 'If you give me a function which can turn a's into b's, I can give you a function which turns a list of a's into a list of b's.
It's certainly the case that ML-style languages have a syntax that can be unfamiliar to outsiders, but I would disagree that the syntax is ambiguous. Indeed, Standard ML (another functional language) is one of the few languages to be formally specified.