buffyoda's comments

HaskellBook.com will teach you quite a number of them. :)

The Reddits for the different functional programming languages are a good place to hangout (and a frequent source of blogs and videos on these topics), and for FP in non-FP languages, there are good Github communities (e.g. http://github.com/fantasyland/, no association with FIOL).

I'd also humbly suggest that LambdaConf 2017 (May 25-27) is a great place to learn more about functional programming. There will be a special two-day LambdaConf workshop prior to the conference that introduces the basics of functional programming (no background knowledge), another that is aimed at a slightly more experience audience, and then at the subsequent conference, plenty of workshops and sessions to learn many of these topics (and others).

It's a journey, but everyone can get there if they have the interest. Most of the resources out there (blogs, videos, even e-books) are free, and the remainder are low-cost if you are already working in tech.

Good luck and please just let any of us lurker functional programmers know if you need a hand. :)

Free monads can be inspected "up to the first lambda", which is always at least one operation in, and it's what enables things like purely functional mocking. However, other free structures, such as free applicatives, can be completely introspected:

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

The point is that free monads allow introspection up to the information-theoretic limit (obviously you can't inspect a program whose structure depend on a runtime value), while transformers do not allow any introspection at all.

That's why not everyone's a functional programmer. :)

That helps quite a lot, although for several, it's more programming-by-name than programming-by-semantics.

I'd like to be able to say the end angle has to be less than the start angle, that the unit has to be radians (AKA unit-less :), the unit of radius & that negative values are sensical, and so forth; and have all these properties checked by a compiler.

Which I can do in some modern languages, surprisingly. :)

I'm a big fan of the philosophy that "Every literal in a program is a bug." :)

But I know what you're getting at! Personally, I'm a fan of programming with units and dimensions, and safely representing the distinction between absolute quantities and relative quantities.

That doesn't mean I'd want an infinite number of "float" values for all possible units and dimensions, however; just a powerful enough type system I can give myself some help at compile-time for properly threading sensical values through my programs.

Indeed, that's the whole point of inversion of control, is pulling the control out of the caller and into the callee. That's the primary reasoning benefit of functional programming.

A church encoded boolean is precisely isomorphic to every language's standard booleans (modulo strictness, perhaps) and doesn't offer any benefits; you're still forking the program based on the information content of a single bit.

Let's take the following function invocation, which can be expressed with Boolean literals or Church encoded booleans, I don't care:

  match true false

If you want to determine the significance of the boolean values passed to this function, it does not suffice to go to the definition of 'true' or the definition of 'false'.

Now take something like this:

  match caseInsensitive contains

Even though I have used descriptive names here, it's almost beside the point; I could just have easily have used nonsense names:

  match foobar quux

If you want to know what 'foobar' means, you can go to its definition, and see how it preprocesses a string and a pattern. You don't have to guess about the meaning of a bit.

As a result, the semantics of 'match' and its parameters are all communicated more clearly, with less room for error, and much more generality.

There need not be any syntactic overhead: it is merely the replacement of some flag with a lambda which cleanly encapsulates the effect that would otherwise be encoded in the flag. The way you invoke the function is the same, but instead of twiddling bits to get what you want, you pass functions whose meaning does not require (as much) subjective and possibly error-prone interpretation.

Note this also objectively simplifies the functions themselves, because they formerly contained conditional logic, but once you rip that out and give them no choice (invert the control!), they have less room to err, which makes them easier to get right, easier to maintain, and easier to test.

There is also another way to view the issue: with booleans, we first encode our intentions into a data structure (at the caller site), and then we decode the data structure into intentions (at the callee site).

Well, why are we packing and unpacking our intentions into data structures? Why not just pass them through?

Indeed, we do that by pulling out the code and propagating it to the caller site (possibly with names so you don't need significantly different syntax and can benefit from reuse). Then our code more directly reflects our intentions, because we're not serializing them into and out of bits.

I think the general principle applies to more than booleans, but it's easiest to see with booleans.

Compose (now IBM) has been in this business for quite some time. If true, will be interesting to see if MongoDB can outdo them.

Take it with a grain of salt, but here:

http://www.aptuz.com/blog/is-postgres-nosql-database-better-...

Thank god for N1QL. MongoDB should study and emulate what you folks are doing, instead of inventing yet a 4th query language to pile on top of all the other crap.

Well, you might start off down that path, but eventually you'd find that if you try to execute analytics via PostgreSQL via FDW via Multicorn via MongoDB, you're only able to push conjunctions of simple relational operators on original (non-derived) fields in the source collection.

What that means is virtually any query will end up executing (via PostgreSQL via FDW via Multicorn via MongoDB) by first pulling out all (!) the data from all (!) source collections, relocating it to MongoDB, and then executing the query. Possibly, in fact, these full collection scans might be repeated multiple times, especially for nested data, crosses, and other types of operations.

And then you'd decide that "solid engineering decision" wasn't so solid after all. Then hopefully you'd quit MongoDB and go work on PostgreSQL full time. ;-)

I think ToroDB is super cool, and I wish your project the best of luck! You can't go wrong building something on PostgreSQL. :)

That said, PostgreSQL FDW is NOT a great option for MongoDB analytics. Not only is the data model so different that you lose the ability to answer many types of questions, but Multicorn supports only basic pushdown (conjunctions of simple relational operators on original columns).

What this means is that analytics via PostgreSQL via FDW via Multicorn via MongoDB suffers from (a) very poor expressive power, and (b) ridiculously slow performance, since nearly any type of query will require at least one full table scan on all the source tables (in some cases, especially with arrays, many more full table scans may be required for a single query!).

Better off just using ToroDB. Am I right? :)

If you're interested in how much computation gets pushed down into the MongoDB database, versus how much gets pulled back into PostgreSQL, you can find some examples here:

http://slamdata.com/blog/2015/12/08/nosql-analytics-for-mong...

Warning: It's not pretty.

SlamData (http://slamdata.com) is open source and lets you perform analytics on data in MongoDB.

The 2.0 version will have data visualization baked in, but the current one doesn't have that just yet. :(

Unfortunately, of all the things I did at Precog, I'll probably be remembered most for that post, at least among developers. ;)

As these things often do, it led to many more user signups and a massive spike in web traffic, but ultimately I don't think it had much effect on the business one way or the other.

The branded version is free for all cases (even OEM), and you can download the JS if you want (although you won't get updates & bug fixes).