mrkgnao

Pointfree style uses composition (among other operators), currying, and partially applied functions, but it refers to something distinct from the sum of those concepts/features.

Consider the following function of two parameters, written in Haskell/PureScript syntax:

   f x y =  g x (m (h y))
         = (g x . m . h) y

We can now eta-reduce/partially apply f instead in the definition (which is possible because f is curried by default):

   f x   = g x . m . h

If I were using pointfree style at all (which I almost never do), this is where I'd stop. However, you can go the whole hog and strip out all the arguments:

         = g x . (m . h)
         = ((. (m . h)) . g) x

   f     = (. (m . h)) . g

I've made use of everything you listed, but it's only when you go this far that your function is truly free of "points".

Is this a hammer question, or one of e.g., concrete vs. wood?

Clear, readable value-level Haskell is an underappreciated joy. What are you using this for, if anything?

Oh, thanks for the correction.

It would appear that my knowledge is out of date: did Rust use something closer to H-M in the past? (Going off of https://github.com/rust-lang/rust/pull/15955 here.)

Rust uses Hindley-Milner type inference. OCaml uses Hindley-Milner. Swift apparently uses a variant of the system with more features.

None of these make use of monads or anything rooted in category theory.

https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...

HM is a type system that also gives you an algorithm to infer types without having to do the "List<Integer> foo = new ArrayList<Integer>()" dance from languages without type inference. That's it. It has nothing to do with category theory.

In view of some replies downthread: yes, application-level management is entirely possible with Nix(OS).

Currently, this works best for Haskell, for which there is a sizeable amount (relatively speaking) of Nix tooling available. This is largely because a lot of Nix(OS) users also use Haskell, perhaps because lend themselves to very similar modes of "declarative" thinking.

This is a thorough, excellent guide on how to develop Haskell projects with Nix, including managing non-Haskell dependencies (zlib, SDL, ncurses, and so on):

https://github.com/Gabriel439/haskell-nix/

I only started using NixOS about a month ago, and it's fantastic. The best part is that binary caches are available for almost everything, so the hitherto-painful step where one compiles Haskell dependencies locally has been completely eliminated. The best way I can describe how I work now is "Python virtualenvs, but for everything at once and just so much better".

PS. Gabriel Gonzalez is, in general, someone who makes great documenation. Check out the tutorial for his stream-processing library Pipes: the ASCII art alone is awesome :)

https://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-T...

IIRC discriminated unions are plain C(++) unions with an added type tag, like at the beginning of the article. Brittle, prone to breakage when refactoring, etc. when compared to real sum types.

From the point of view of "onboarding" (aka barriers to entry), as you say, point-and-click is miles ahead of the unfriendly-at-first-glance Vim.

But I'd like to say that I cannot honestly recall an instance where I was in normal mode and ended up pasting something -- I assume you mean Ctrl-V-ing and having the paste interpreted as commands? -- once I got used to it after leaving Sublime Text, which I'd say took me a couple of weeks of hating myself. It's a matter of how much effort one thinks it makes sense to put into learning the editor, but IME there is a significant payoff, even if it is hard-won.

I'm not sure if it's harder for some people to internalize (which is by no means a value judgment; it's why Emacs/ST/Atom/whatever exist and are powerful) but once that is done, one never gets confused about what mode you're in simply because one is almost never in insert mode! "Probabilistically" speaking, you are in insert mode for 0 time. ;)

In any case, I don't hate non-bimodal editors, just hope that the subset of those using them who have not seen Vim for what it is yet do so quickly. (And, of course, there are those who are genuinely repulsed by modal editing, and that's fine!)

I can't speak to "inordinate amount of time screwing around with plugins": I have a plugin for each language I use, and perhaps four or five others. The rest of my init.vim (I use Neovim) is about ... 30 lines long? It's my experience that most (Neo)vi(m) users use little of the power of plain vi -- I know that because I myself was like that for almost three or four years after I started using Vim. (This is ignoring, e.g. large Java projects, where IDE-style code navigation is basically a requirement if you want to get anything done.) But there is definitely a culture where a customized-to-the-hilt editor is seen as something to be proud of, and why shouldn't it? It's what you "live in", isn't it? :)

For those unwilling to click through, I.F. is Ivan Fesenko. Among other things, he wrote this article about Mochizuki's work:

http://inference-review.com/article/fukugen

But how do you write a list with only one element, x (func y) z?

That's not the sense in which it is used most of the time (at least outside of academia). To repeat something I quoted up-thread:

> 'Cultural Marxism' in modern political parlance refers to a conspiracy theory which sees the Frankfurt School as part of an ongoing movement to take over and destroy Western society.

https://en.wikipedia.org/wiki/Frankfurt_School#Cultural_Marx...

Without taking "sides" -- I don't have a horse in the "is postmodernism true?" race -- it bears pointing out that afaict Jordan Peterson doesn't really know what he's talking about when it comes to 20th-century philosophy. Most of his views on postmodernism, and philosophy in general, make absurd claims without actually referring to any philosophical literature. He doesn't even refer to much literature critical of postmodernism (and there is lots of this).

In fact, this pattern of not really knowing what he talks about could be stretched to cover basically everything but clinical psychology (which is what he works in). To quote the man himself[0], in a recent Deepak Chopra moment:

> Proof itself, of any sort, is impossible, without an axiom (as Godel proved). Thus faith in God is a prerequisite for all proof.

Most of his knowledge about postmodernism isn't from actually reading the texts he so dislikes; he just gets it[1] from a self-published/vanity-press book (Hicks' Explaining Postmodernism) that ... just isn't very good. From a review of the book, which could very well be applied to Peterson's videos:

> Second, although it accuses (rightly I think) postmodernism of being too polemical, Hicks' text is itself an extended polemic. Instead of disproving postmodernism, Hicks dismisses it; instead of taking postmodernism seriously and analyzing it carefully on its terms, Hicks oversimplifies and trivializes it, seemingly in order to justify his own prejudice against postmodernism. If postmodernism is in fact untenable, which it very well might be, Stephen Hicks has unfortunately not demonstrated that.

A quick search for his name on /r/askphilosophy will turn up a ton of reasons (from people actually working in philosophy) why anyone is -- to put it charitably -- better served engaging with other critics of postmodernism.

His current popularity is largely due to the controversy around him bravely "sticking it to feminists" by daringly refusing to call trans people by their preferred pronouns. Another reason is his conspiracy-theorizing on "cultural Marxism",

> 'Cultural Marxism' in modern political parlance refers to a conspiracy theory which sees the Frankfurt School as part of an ongoing movement to take over and destroy Western society.[2]

both of which find favor with a section of the right today.

--

[0]: https://twitter.com/jordanbpeterson/status/40520012623631155...

[1]: https://www.reddit.com/r/askphilosophy/comments/6n6rhg/why_a...

[2]: https://en.wikipedia.org/wiki/Frankfurt_School#Cultural_Marx...

I'm currently playing with Reflex, a wonderful functional reactive programming library that lets you compile the same code into into webapps with GHCJS (a JavaScript backend for GHC) or into standalone desktop apps (using WebKitGTK).

It's wonderfully expressive and doesn't feel like you're painfully imitating C++ in Haskell. On the contrary, it's very idiomatic.

https://github.com/reflex-frp/reflex

However, FRP is ... unusual, and takes a bit of time to get the hang of.

Here's a stripped-down todo app "tutorial" in Reflex:

https://gist.github.com/mrkgnao/1a5c06cc1e188f2238c8c11cb74e...

And this is a full-featured TodoMVC in Reflex:

https://github.com/reflex-frp/reflex-todomvc

--

FLTK is a GUI toolkit that has Haskell bindings. It's a very C++-like API, but the library is in heavy development.

https://github.com/deech/fltkhs

The developer is also quite friendly, and I believe there are good docs. Here are a few demos:

https://github.com/deech/fltkhs-demos

Also, GHC does have a C backend, afaik, although it's deprecated nowadays and only available if you build it yourself in "unregisterised mode", which people do when porting GHC to a new architecture.

Pandoc, the "universal document converter", is a good example of a large, feature-complete Haskell project in wide use.

https://pandoc.org/

Most people who use it aren't aware it's written in Haskell!

The extensive README is also a pretty good intro to how one can do crypto (as in cryptography: get off my lawn!) in Haskell using the excellent cryptonite library.

For those who won't click through to TFR:

    > import Crypto.Number.Hash (SHA3_256)
    > import Crypto.PubKey.ECC.ECDSA (sign, verify)
    > import Crypto.PubKey.ECC.Generate (generate)
    > import Crypto.PubKey.ECC.Types (getCurveByName, SEC_p256k1)
    
    > let msg = "hello world" :: ByteString
    > let secp256k1 = getCurveByName SEC_p256k1
    > (pubKey, privKey) <- generate secp256k1
    > sig <- sign privKey SHA3_256 msg
    > verify SHA3_256 pubKey sig msg
    True

And compiles are really, really fast. (It's an OCaml thing, I gather.)

Oddly enough, s/high school English/mandatory Bible reading in Catholic school as a third-grader/ and it's the same for me.

This comment is a fine Proustian madeleine, if I may :)

Making HTTP requests is the same thing as having rays of light reflect off the storefront, I'd say.

> C_major D_minor E_minor F_major G_major A_minor B_diminished C_major

A good way to see where this comes from is to note that the major scale with C as the tonic ("root") note is

    C D E F G A B

(the white keys on a piano), and starting at any note in the sequence and taking every other note (for a total of three) gives you three-note chords called "triads":

    C    = C E G (skip D, take E, skip F, take G)
    Dm   = D F A
    Em   = E G B
    F    = F A C
    G    = G B D
    Am   = A C E
    Bdim = B D F

The intervals between successive notes are (major or minor) thirds, hence these chords are constructed by ascending (moving up the scale) in thirds. The Wikipedia page does a good job of explaining how you can construct chords like this:

https://en.wikipedia.org/wiki/Triad_(music)

You can take four notes at a time instead of three to get seventh chords.

I've been playing for quite some time, and have also known bits and pieces of theory for about the same amount of time, but I've never really applied the latter to my playing until recently. I'm getting into playing Bach and so on and find that I'd really like to understand, e.g. Roman numeral analyses, and being fluent in basic theory and how it "looks" on your instrument is key to this.

You're right, thanks for catching this. See my edit.

Edit: ignore this, it's false. Proof:

https://www.reddit.com/r/Guitar/comments/1cgrdq/ama_this_is_...

I don't know how this stuck with me for so long, I've practically known it to be true for as long as I've been playing. Huh.

---

Interesting bit of trivia I learned long after I stopped using his resources: Tommy Emmanuel is his father.

> so the language accepted by GHC today is often called GHC Haskell for disambiguation

s/by GHC today/by the newest available GHC/

There was a 1998 "Haskell Report" which formally defined Haskell-the-language. This version of Haskell is called Haskell 98 (sort of like C++98). There is also an updated version released in 2010, which defines an expanded language called Haskell 2010.

https://www.haskell.org/onlinereport/

https://www.haskell.org/onlinereport/haskell2010/

The purpose of these documents is to specify what an implementation of Haskell 98 or 2010, respectively, should support. Just like the analogous standards published for the C and C++ languages, the Haskell reports make no reference to any specific implementation.

The most popular implementation of Haskell is the GHC compiler. (In fact, in reality it's the only compiler anyone uses, with very few exceptions. For better or worse, Haskell is a one-implementation language at present.) GHC accepts a greatly expanded language compared to what the reports specify, including a large number of language extensions that can be turned on with flags. (sort of like how Clang or modern GCC accept C++11/14). There are minor changes from one version to another, so the language accepted by GHC today is often called GHC Haskell for disambiguation.

What GP is pointing out is that almost everyone using Haskell today writes in the language that GHC accepts today instead of sticking to some official standard.

If you want to learn Haskell, you don't need to worry about this at all. All reference materials and books teach modern GHC Haskell, which is also what is used by practically all Haskell users. As noted before, very few people use non-GHC compilers (usually it's just the people implementing or testing them) and you're very unlikely to encounter these implementations.

That's gracious of you. :)

Again, at the risk of repeating myself, it's not Haskell, it's "many languages other than Go, of which Haskell is one I'll be using by way of example".

(I'm not sure why you made that edit, but I've made a mental note of what the last bit said. Arguing on the internet is a difficult, if useless, skill, and I'd hate to be tiresome.)

I use Haskell examples because that's the language I'm most comfortable with, but, e.g. the Result type used in Rust is another example of how this can be done better.

https://rustbyexample.com/std/result.html

Ergonomic error handling or generics/parametric polymorphism aren't "Haskell methodologies". Go is one of a very small number of languages that have been designed in the last decade and lack features like this.

The reason I participate in HN comment threads about Go is largely how entertaining I find comments strenuously rationalizing Go's inadequacies. In one (very recent but definitely memorable) case[1], I was told that

> You [should] first reconsider your need to make a generic data structure and evaluate on a case by case basis.

[1]: https://news.ycombinator.com/item?id=14970919

Apologies. In any case, monadic errors in Haskell allow you to make "failing early" automatic. Even a simple use of optional types can make a difference. For instance, here you're failing with the same error every time, like here:

    a, err := squareRoot(x)
    if err { handle(err) }    
    b, err := log(a)
    if err { handle(err) }   
    c, err := log(b)
    if err { handle(err) }

you can just use an optional ("Maybe") type: write a, b, and c with types like

    a :: Double -> Maybe Double
    

and then do

    a <- squareRoot x
    b <- log a
    c <- log b

If the computation of a fails, the whole computation fails. The compiler takes care of all the error-checking plumbing. I think the ergonomics of this common kind of situation are really suboptimal in Go, which to my knowledge doesn't support anything remotely similar.

I'm sadly too young and ignorant of CS/technology history to be well-acquainted with the "old times". (It's something I intend to fix.)

Even so, I'm all for praising the good things that Go does: if nothing, because of the tremendous mindshare it's getting and the number of people it reaches.