To a degree I agree, but I believe there are objective claims we can claim about the cognitive load of different syntaxes. I think syntax & semantics are also closely tied, syntax enables/disables semantics in many cases.

If your syntax only allows for positional arguments its very easy to argue thats less readable than a language like jakt which requires named arguments to (nearly) every function & constructor.

I also think the syntax of the language standard api is part of this convo too. Readability is not the same as “easy to reason about”, its related but distinct, id argue its specifically the amount of cognitive load it takes to be satisfied with understanding an isolated function.

That means understanding the basic language semantics, argument order, inferring data structures, keeping track of intermediate values (which gets duplicated x times with recursion). These and more are the trade offs, we can obviously get very skilled at these things but it doesn’t mean all languages are essentially the same.

I agree, I keep wanting to post a parody comment showing a “clearly more readable version” in APL.

The very first syntactic element of the Haskell implementation is

module Trie
    ( Trie
    , empty
    , insert
    , find
    , complete
    ) where

which tells you that it is defining a Trie module that exports a Trie type and empty, insert, find and complete terms (values or constants).

I would agree with this and I wonder what that implies for maintainability. In most projects, code is not something you think very hard about, hammer down in stone and keep it on display in all its awesomeness for the ages (even though I vehemently wish that were the case). The ability to go in, tweak a few details and be done with it is essential, and it seems to me like it would be a lot harder if you first have to grok the intricacies of the entire module before going in and carefully adjusting what needs to be adjusted.

if you read Python types, data Trie a = Trie (Map a (Trie a)) Bool is something like

class Trie:
  children = {} # type: Dict[str, Trie]
  wordEnd = False # type: bool

(though really it’s Dict[any, Trie] but I don’t know how to say that in Python).

The Haskell structure might be clearer if we add some accessors and restrict it to characters:

data Trie = Trie { 
   children :: Map Char Trie
 , wordEnd :: Bool
 }

But the data structure doesn’t tell you what you can do with the data structure (to find out that, you’d typically look at the module exports at the top of the file). This is almost a cultural difference, separating data structures from what you do with them.

I’d put that down to familiarity.

Expressions in pure FP are great because there’s no implicit state to think about. Even if you’re in a monadic context, maybe using the State monad even, it’s all encapsulated in the expression. The only thing to track is closure bindings.

Imperative statements can be brutal. Like with FP you need to track closure bindings, but these can also change between statements! That’s a major, major source of complexity that most programmers have gotten so used to they don’t even question it.

If there is one thing that (pure) FP does better, it’s referential transparency, which is the actual guarantee that an expression (which is the only way to express a program in haskell) is readable in isolation, and replaceable by its computed value.

So it’s definitely a “break down complex expression” problem, which could be eased by using the where syntax in haskell, which is a way to name sub-expressions in a larger one.

hm, typically “expressions” simply means “statement that has a value”. For example, Python has these “yoda conditionals” that allow you to use if as an expression: x = "wtf" if 1 > 2 else "okay". In Ruby you’re able to use the regular if like that as well, because if isn’t a statement: x = if 1 > 2 then "wtf" else "okay" end. Expressions make code more composable in general, which helps a lot with code-generating code (e.g. macros), which is a big reason Lisps prefer expressions over statements.

Overusing the ability to embed expressions in other expressions makes code less readable, that’s true. But it doesn’t have to be. It’s like overusing operator overloading in C++ or something. When a language is more expressive it also allows for more convoluted code.

For example, using intermediate variables is a choice that you can use in FP code just as in more “imperative” code. Not using variables is just a way to show off and make code unreadable, undebuggable and unmaintainable.

it has less specific components & more generic… which I’d argue only hurts readability.

Fully agree on that one though!

I think a way to improve functional programming readability is to use point-free style, or other styles that allow breaking down big expressions into small semantic units that are as easy to understand as statements.

I found OP’s Haskell code a bit obtuse compared to Python. Generally, writing simple statically typed functional code requires a bit more effort.

I’d want the python to look more like Haskell, the Haskell says only what’s needed, nothing more. There’s all sorts of nonsense in the python that just adds noise. __init__? class? def? self? None of these have anything at all to what a Trie is. The Haskell on the other hand sticks to just the data:

insert [] (Trie tries _) = Trie tries True

if I insert an empty work into a known Trie, then the current node must be the end of a word.

insert word@(firstChar : rest) (Trie tries wordEnd) =
    case Map.lookup firstChar tries of
        Nothing ->
            insert word (Trie (Map.insert firstChar empty tries) wordEnd)
        Just trie ->
            Trie (Map.insert firstChar (insert rest trie) tries) wordEnd

Necessarily more complex, because we need to reference more, and do more work, but it is all still completely data oriented - if we insert a non-empty word into a Trie, does the firstChar exist in it? If not, add it to the known mappings, pointing to an empty Trie. If it does, insert the rest of the word into the child node we found.

It might be a bit easier if the author used record update syntax though, to make it clear what is being “changed” between the old and new Tries.

insert [] trie = trie {flag = True}

To understand the python one, you need to keep state in your head - what is node at any given point in time? It’s constantly changing. And if these two pieces of code were actually comparable, i.e., the python code would be used persistently, it would be significantly more complex.

Is any of what I’ve said above “fact”? Not really, it’s mostly opinion, as a Haskell developer for more than a decade, but’s my opinion that to aim for code that looks familiar will limit you to only being able to write the programs you can write in those familiar languages. I would be interested in seeing what the equivalent python code looks like, that allows me to arbitrarily retain references to any previous tree without worrying about data integrity.