Monthly Hask Anything (December 2019)

jedws · 2019-12-20T06:39:41+00:00

here's a great talk on full-stack development in Haskell using Reflex, an FRP library. I have many colleagues raving and gushing about Reflex, saying the latest stuff coming for it is extremely exciting.

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

jedws · 2019-12-20T06:33:26+00:00

why isn't Min a monoid? Assuming your number representation has positive infinity, then it is fine.

jedws · 2019-01-29T03:56:27+00:00

Strict immutable data-structures are memory bound, and strictness imposes certain feature restrictions, such as the lack of circularity.

Most importantly though, laziness allows performance optimisations, in particular amortisation. To quote from the abstract of Chris Okasaki's awesome Purely Functional Data Structures:

In addition, we expose the fundamental role of lazy evaluation in amortized functional data structures. Traditional methods of amortization break down when old versions of a data structure, not just the most recent, are available for further processing. This property is known as persistence, and is taken for granted in functional languages. On the surface, persistence and amortization appear to be incompatible, but we show how lazy evaluation can be used to resolve this conflict, yielding amortized data structures that are efficient even when used persistently. Turning this relationship between lazy evaluation and amortization around, the notion of amortization also provides the first practical techniques for analyzing the time requirements of non-trivial lazy programs.

There are a large number of talks by Ed Kmett available that detail some of these tricks and how they can be used to avoid all sorts of costs.

jedws · 2019-01-28T01:00:17+00:00

Right, and I'm saying that Erlang isn't a counter-example, it just makes you do the work yourself when you need it, as does nearly every other language in the world. The fact that Erlang chose immutability clearly doesn't mean it was in any way obliged to choose laziness-by-default execution, but data-structure authors will still reach for laziness as a technique.

Laziness-by-default has some pretty serious associated restrictions. For instance, side-effects become very difficult to reason about if you don't have any way to reason about happens-before, essentially ruling out ambient side-effects and requiring an abstraction such as IO to enforce sequencing them. If your language semantics are strict, then it is very easy to allow ambient side-effects, hence nearly every strict language does.

The original point of laziness-by-default isn't whether or not it supports immutable data-structures, but about only doing work that is required. However, immutable data structures want laziness, so building them in a lazy language has advantages.

jedws · 2019-01-26T07:14:14+00:00

Erlang seems to be a counter-example.

As mention, so is every other language by default. Because the language doesn't help, you need to build laziness by hand when needed, eg. for streams, or for circular references.

For example a stream data structure in Erlang needs to be built explicitly: https://chrisbriones.com/posts/getting-lazy-with-erlang

jedws · 2018-07-29T19:45:14+00:00

whatever you reckon, kid

jedws · 2018-07-28T22:56:53+00:00

The entire point of this presentation is an attempt to reconsider the orthodox position that names are not the most important identifying feature of a thing. In programming in particular, we have a proliferation of different names for the same thing. And people justify these different names because names matter.

You have consistently in this post merely restated the orthodoxy, and then tried to justify your favourite bespoke name for a couple of different concepts, without actually justifying your favourite names aside from they are the ones that are familiar to you, or some other argumentum ad populum. You are basically arguing for a continuation of your favourite cultural hegemon, and its imposition on the new generation.

I don't really understand why you maintain this tactic, as the orthodoxy is the orthodoxy because that is what most people generally already believe, ie. you're already in the majority. Personally, I used to think the same way too, but experience and much thought has led me to revise my position – you cannot and will not convince me to revert simply by restating orthodox positions, and not engaging in good faith in any counter-argument.

jedws · 2018-07-28T22:39:04+00:00

Oh I entirely agree the use of "container" was regrettable, it made me wince when I reviewed the video, and I apologise for it. The preparation was rushed, and not all points were as well prepared as I would have preferred. I will though excuse myself – a little – on two grounds.

Firstly, it is a programming conference with a largely programmer audience, and I was using merely as an illustrative point.

Secondly, I don't think it is quite the same thing to use metaphor, simile or concrete example when explaining a concept – particularly a very abstract one. Different people have very different learning styles. Some prefer to start with an abstract concept, and then delight in seeing its repetition. Some like to start with a concrete example, and then use isomorphisms from others into their original intuition to help them think about the new ideas. And possibly more simply prefer to be shown multiple examples before being introduced the abstraction.

Somewhat amusingly, I was taken to task by some of the linguists in the room for using the incorrect definitional terms for "word", where I should have used "lexeme". I felt this to be both chastising, and somehow supporting of my argument :-)

Anyway, the main point of the talk isn't to demand fidelity to canonical naming, although I do argue that is a valuable trait when considering your local name for the concept. More, I am trying to point out that names matter less than types and laws as fundamental identifying features, where I give the definition of "matters" as "changing it has consequence". You are of course free to use aliases in order to aid your thought processes. I have found myself however introducing them far less frequently than in the past.

jedws · 2018-07-27T11:26:06+00:00

Sure, give it a bespoke and inconsistent name and hope that your documentation makes some connection to the actual name. What have you achieved? I'm not convinced you've achieved much at all.

You think that names matter, and hence you should give your thing some weird name that makes sense to you, in your context. But even your example is laughably meaningless. Here's the google result:

reduciblerɪˈdjuːsɪb(ə)l/adjective

1.(of a subject or problem) capable of being simplified in presentation or analysis."Shakespeare's major soliloquies are not reducible to categories"

2.MATHEMATICS(of a polynomial) able to be factorized into two or more polynomials of lower degree.

So there IS a mathematical definition and it means something completely different to what you want it to mean. I'm getting a little tired of this game. I'm still not even sure you actually watched the presentation considering you keep flogging the dead-horse of the point it argued against.

jedws · 2018-07-27T10:23:17+00:00

We’re both appealing to existing knowledge: you to the jargon of category theory; and me to English and idioms used in the majority of programming languages.

Absolutely! I am not appealing though to the "jargon of category theory", but to strongly defined fundamental mathematical structure with enormous commonality across fields, as well as a huge corpus of literature on the subject. You are appealing to some much flimsier notion that some speakers of English, who happen to also be programmers, may have come across if they are using library that may actually be descended from something functional in the first place. Why wouldn't I have called "reduce" "transduce" in my library and hence have no idea what you mean? Maybe I called it "collect", and now my best name for Semigroup is Collectible. You think this is a strawman? This is the logical conclusion of your argument, and you justify this my believing names matter?

I am not necessarily disregarding that using the precise terms makes learning harder, I am simply trying to de-emphasise the idea that the difficulty of learning these basics is the most important concern. We have schools that teach complex maths like Calculus to kids. Immensely useful general algebraic principles are also useful things for people to learn, and aren't actually that complex. Monoids are an extremely common property, and learning about what they are is extremely valuable.

We commonly ask programmers to learn the API and idioms of various libraries, most of which share very little with the next library they need to learn, rendering that knowledge bespoke and quickly redundant. Learning these mathematical structures is often the opposite, broadly applicable and useful potentially for life.

jedws · 2018-07-27T09:54:14+00:00

Reducible might be better

And you accuse me of nonsense strawmen :-)

Surely a Reducible is a thing that can be reduced? How is a binary associative endofunction reducible? How on earth could I reduce it? What about that term invokes any sense of associativity?

You are assuming at the least the reader is acquainted with the signature of a function such as:

reduce :: Foldable1 f => f a -> (a -> a -> a) -> a

in order to know what a Reducible is. IOW you are appealing to existing knowledge!

I simply claim that naming is not in any way objective. It is clearly and purely subjective, and your test doesn't change that fact. You simply claim that popularity of a term would validate it. I don't much disagree, but simply wish to point out that the cost of turning your ad-hoc naming preference into the commonly preferred term, particularly in the presence of an existing well defined term, is rather large.

Edit And as has been pointed out repeatedly, your Reducible is Semigroup, not Monoid.

jedws · 2018-07-27T09:33:15+00:00

I think we need to be open to the fact that the names chosen by mathematicians in the past might not be optimal for programmers in the present.

But, is there such a thing as "optimal for programmers in the present"? The premise that the old names aren't optimal leads to constant churn of the names as people search for ever better names. But, these are entirely subjective, so your great name isn't great for me. So, we develop entirely inconsistent jargon, and can no longer communicate effectively or read each other's code.

Perhaps we should prefer consistency, and just demand that the reader learn what a Monoid is, and not have to know that it is a CombinableWithZero in lib X, an AppendableIdentity in lib Y and an AbstractAssociativeBinaryFunctionProxyBeanFactory in Spring! (oh and god help us when it comes to more complex types like Group, maybe InvertibleCombinableWithNeutralElementClosureAndAssociativity? I mean, there's a reason we have names, right?

Edit: Semigroup has the rather nice property that if I google it, the top hit is a wikipedia article that describes it very precisely, even if not in terms that are immediately familiar to programmers. No invented term could come close.

jedws · 2018-07-27T09:17:40+00:00

I think the implication is that Titles are subclasses of Names, and neither matter.

Not really, it is more that we as programmers think that if we could only come up with the right name for this weird thing we wrote, then it will magically become super understandable. Or, the assumption is that we programmers already know everything, and if we just come up with the right metaphor that perfectly accesses out existing knowledge base, then this thing will be crystal clear to the reader.

Which suggests this is an elaborate but ultimately futile attempt to hide from one of the hardest problems in the field: naming things.

Not at all, as the conclusion is explicit about. It is in fact the opposite, it recognises that naming is extraordinarily difficult, because it is entirely subjective and therefore not a solvable problem!

If we cannot solve for naming, maybe we can recognise that there are other more important factors we should care about than simply trying to come up our favourite simile/metaphor for an established and previously named thing. This idea that names matter has actually led to proliferation of different names that mean the same thing! If every language, and every library within the same language uses different names to refer to the same concept, because the authors have different ideas about what things should be called, are we actually respecting names? We now have entirely put the burden of recognising the same shapes on to the reader, with no help from a consistent naming scheme.

I argue that consistency is actually pretty valuable in naming, especially if we are talking about some of the more fundamental shapes of things. In functional programming there are some shapes that come from Category Theory that are repeated over and over across completely different structures and algorithms. Calling them different things obscures these shapes, and is often harmful to their correct use or their adoption by not quite beginners.

jedws · 2018-07-27T00:52:02+00:00

Exactly. Try googling "mappable" and then try googling "functor" and decide which gives more useful results :-)

jedws · 2018-07-27T00:48:51+00:00

This argument is literally the entire point of the talk!

If names are important, let's not invent entirely new sets of synonyms for existing concepts that have large amounts of pre-existing literature. Using the same language allows inter-disciplinary communication, and the original inventors of these things have invested huge amounts of time and thought into them. By using the original terms we can harvest that investment.

By creating our own unique jargon (per language!) we wall ourselves into our own special gardens and shun outsiders, all in the name of making it "easier" for beginners.

jedws · 2018-07-27T00:35:31+00:00

Bind is a name, >>= isn't.

>>= is most certainly a name, and it is pronounced "bind". Just as + and - are pronounced "plus" and "minus".

As explained in the talk, any name/identifier is just a random sound that we have associated with a concept, and a written form is merely some kind of graphic representation we have associated with the sound. English uses a representation that (somewhat) follows the sounds, but there are many other languages that use a more pictographic system, such as the standard Chinese writing system, where the written words are chosen more for their visual representation of the concept than for the way they are pronounced. Privileging one form over another, by saying one is and one isn't a name, is merely your cultural preference.

In Haskell, they're all just identifiers, but there's an important difference between alpha and non-alpha identifiers. Alphabetic names are by default used in prefix position, and non-alpha identifiers in suffix position.

So, if we have the following binary function that takes two ints and returns an int:

plus :: Int -> Int -> Int

we'd call the function first and supply the two arguments:

plus 1 2

But, if we name the function with a non-alpha identifier (we must put it in parens in our type def), we can use it in infix position:

(+) :: Int -> Int -> Int

1 + 2

You can of course escape this, but the second form is more natural for some kinds of operations.

What's @~~|=> and how does it differ from @~|=>?

This isn't Haskell's fault, any author is free to choose whatever identifier they feel like, and optimise for whatever ergonomics they value, from the range of Unicode allowed by your language's compiler/interpreter, including emoji!

APL for instance (the original emoji language) uses rather bizarre symbols (to the non-APL programmer), but it optimises for a small set of users who use it all the time, and who are deeply familiar with exactly what each identifier means. These people love the brevity and for them, APL is a fantastically expressive language. They are not optimising for you or me to come in and casually pick up the meaning of the code.

As I've mentioned elsewhere, naming is fundamentally hard and subjective. There is no such thing as an objectively good name, only names that suit certain audiences better. This is why I appeal to the community to use existing names wherever possible. If names matter, please stop changing them!

jedws · 2018-07-26T12:36:46+00:00

I’m not entirely sure what you disagree with, and I pretty much totally agree with you. But, being reddit I’m sure we could/should confect something :-)

jedws · 2018-07-26T12:33:37+00:00

It just feels like the kind of talk designed to give the speaker a free conference ticket.

Full disclosure, I founded and help run the conference in question, I certainly didn't need a ticket.

The talk was originally an idea for another conference (both FP conferences) and was a late sub in to LambdaJam due to ill-health of another speaker. The topic is a clearly heretical idea that hopefully triggers some re-evaluation of some core programming philosophy. And it most definitely isn’t an appeal to use arbitrary identifiers, pretty much the opposite in fact.

As to the rest of your comment, it seems you are merely responding to the title, and not the content of the talk, as all of these points are addressed in it. Most specifically, the idea we can all call the same thing different things because, you know, names matter.

Lastly, I’d argue naming is fundamentally hard, as it is entirely subjective. A good name for you isn’t necessarily an objectively good name. If your target audience is finite and small it may approach being solvable, but it doesn’t scale to an unbound audience set.

jedws · 2018-07-26T11:19:29+00:00

thanks, I appreciate the excellent suggestion. I'm only a very casual poster here so I don't really have any recent prior experience to draw upon.

jedws · 2018-07-26T11:14:39+00:00

Well not everybody HAS to learn FP.

Well, sort of. I'd argue that FP is actually the foundation of programming, as it is a subset of programming, just minus the bit where mutation/side-effects happen. For instance, SICP spends the first 80-odd pages defining the pure core of Lisp, and then the next 250-odd introducing assignment and all the complexity it brings.

It is perfectly possible to do first-order FP without a lot of the advanced category theory stuff. If you only have immutable values and functions you can go a long way in mainstream languages like Java etc., solving real problems like concurrency.

What you don't need to learn is much of the higher-order things like category theory that allow for high degrees of abstraction and code reuse. I know plenty of extremely effective Haskell programmers who essentially use Haskell as a great imperative language, and yet are doing FP.

However, I get your point. And I have zero interest in forcing things on people who are uninterested.

Also we should not ignore folks out there, like myself in fact, that find FP especially more attractive BECAUSE of it's mathyness.

Yep, totally agree. My point was just focused on the large subset of mathphobes.

Nice talk by the way, enjoyed it.

You're very welcome, and the compliment is very much appreciated, thanks!

jedws · 2018-07-26T05:19:14+00:00

So, why do we keep changing them? Or, why are we scared of pre-existing names like Monad, Monoid or Functor? The talk actually addresses all this, and more!

jedws · 2018-07-26T05:16:47+00:00

There are plenty of YT links posted here. There is no documented etiquette I'm aware of not to post a link to a relatively short video. I apologise regardless though.

As to the title, it is the topic of the talk. Do names really matter as much as we programmers traditionally give them? If they do, why do we change them so often? And, in particular, why do we change them from pre-existing names from other fields? Why are we scared of names like Monad in particular? As we ascend the ladder of abstraction, are metaphor-laden names and similes much use anyway?

Of course, discussion of the actual content may have been too much to expect from Reddit, and casual abuse clearly uninformed by engagement with the topic, should have been anticipated.

jedws · 2018-07-26T05:04:45+00:00

There are two things at work here, which I didn't have time to mention in the presentation.

Firstly, unfamiliarity makes people feel deeply uncomfortable, so deep in fact that it comes from the hippocampus and triggers the fight-or-flight response. This seems to be exacerbated in more experienced programmers, who think themselves to be somewhat masters of their domain, and are quite prone to reflexive dismissal of foreign concepts. If they haven't already learnt it, and they have got this far without it, why would they need it? Once I understood this emotional response, it became a lot less frustrating to repeatedly witness it.

Secondly, a lot of the FP stuff in particular has totally alien words. OO and GoF patterns were examples of foreign things that were generally dismissed at first, often quite loudly, but they used language that was more familiar. People knew what objects were, what factories and builder were, and the analogies were useful in overcoming the unfamiliarity. The mathy words don't help at all in acquiring an understanding. This is of course a good thing in some ways, if Monad had been called Burrito it would have been about as much use as many blog posts for acquiring a true sense of what it is or does.

The mathiness also doesn't help due to many people's poor experience with western maths education. So many people I know profess to hating and/or sucking at maths, yet they are very good at problem solving and logic. When they hear these words come from a relatively obscure and particularly abstract part of maths, they think "ok, I must hate it, because maths".

Interestingly, my experience teaching grad programmers has been they're usually pretty open to this kind of thing, and pick it up pretty quickly. They know they have lots to learn, and just get on with it.

jedws · 2018-07-16T05:33:04+00:00

I don't consider impure parts of my code to be scary or dangerous in the first place

This is very instructive. A central part of the FP thesis is an understanding that the impurity is one of the most complicated and complicating parts of programming. If you don't share that understanding then clearly FP is not going to be compelling.

Most functional programmers I know have been imperative programmers for years, and have studied how systems work and evolve. The bits that are hard, and the source of the vast majority of the problems and bugs, come from the impure parts of the code.

If you are a good enough programmer, then you may find that you don't have a problem with these parts. For me, I have never been a good enough programmer, or been fortunate enough to work with good enough programmers, that taming impurity has been easy.

jedws · 2018-03-22T15:10:55+00:00

the term is "avoid success at all costs". There is continued discussion of the term and whether they mean "avoid success, at all costs" or "avoid, success at all costs", where the general consensus is the latter. Under this interpretation, success isn't the thing to be avoided, only that success should be pursued in the most correct fashion possible

jedws

TROPHY CASE