zlacker

"is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?)"

As just one person who has written a great deal of functional code, it reads well to me. I think because I am used to reading it "inside out"? Reading lisp-likes is probably helpful.

Take 'color' for example. It opens with a 'cond', with three branches. First branch is if the idx-th position in word is the same as letter, return green. Second branch is if the word includes the latter at all, yellow. Otherwise we're grey.

That took me a few seconds to grok. Just one anecdote for you. Don't think you're broken but reading/writing this kind of code even a little bit will change the way you see code IMO.

>>trento+(OP)
This is the function that confused the person you respond to, ported to Python:

    def color(word, letter, idx):
        if word[idx] == letter:
            return GREEN
        elif letter in word:
            return YELLOW
        else:
            return GREY

I know which one I'd prefer to grok at 2AM with alerts going off.

>>exitb+gp
> I know which one I'd prefer to grok at 2AM with alerts going off.

At that time I'd just opt for sleep. Or sex. Or drink. Reading code doesn't belong to things one should do at 2AM.

>>mirolj+xt
And yet we've all done it.

>>auggie+Bu
No. We didn't. At least not we all.

That's just a myth spread by a few workaholic programmers. Luckily, there are enough 9-5 programmers to clean up the mess created by those 2AM committers.

>>exitb+gp
That's because you are more familiar with whatever style of code you are used to.

Don't confuse familiarity with readability.

>>trento+(OP)
> It opens with a 'cond', with three branches. First branch is if the idx-th position in word is the same as letter, return green. Second branch is if the word includes the letter at all, yellow.

This is a tangent, but I've been thinking about how I feel when the conditions of an if-else ladder rely on the order they're listed in.

This is an example; if you swapped the order of those branches around, the coloration would become incorrect.

I'm a little happier when the conditions are described completely, such that swapping the order of the checks doesn't change which of them evaluate false or true, but it's also true that that can add quite a bit of complexity over an order-sensitive set of conditions.

Thoughts?

>>exitb+gp
> I know which one I'd prefer to grok at 2AM with alerts going off.

I hate meaningless statements like this. This means nothing, other maybe that you know Python. 20 years ago people might have said that about Python - I even know many people today who would say that about Python.

>>freila+PJ
I was in a "101" undergrad compsci class the first year the program used Java (1997, I think?) and so this asst prof was showing a simple example of some Java syntax.

I had been programming in C for a while, learning from K&R, to build ray tracing input files and that sort of thing so I was kind of disappointed but whatever, I was a mature student who had rediscovered computers a couple of years before (had a C64 in the 80s) and was just happy to be there.

Anyway, this guy in the back yells out "I could do that in 2 lines of Q-BASIC" or something to that effect (Q-BASIC was definitely part of his pithy one-liner). Little did I know he was representing so many of the people I would encounter over the next decades.

>>thauma+NE
I mean if the checks are expensive and it's on hot path, then that's wasteful.It might also require then to use more nesting of IFs which isn't necessarily nicer.

>>thauma+NE
Having the order matter and matching the first `true` branch makes for more readable and less-wordy if statements. Otherwise when you have two conditions which have any overlap, such as A and B, for the A branch you need to add `and not B` and for the B branch you need to add `and not A`. This can create very long expressions. Having them evaluate in order and only match the first true one makes this unnecessary.

>>exitb+gp
Honestly both read about the same to me, and I'm largely unfamiliar with Clojure. The main difference appears to be the 3 `str` callouts, which appear extraneous as the following version works just the same:

    (defn color [word letter idx]
      (cond
        (= (nth word idx) letter) :green
        (str/includes? word letter) :yellow
        :else :gray))

Interesting that even with the `str` callouts removed, the function still appears to work on other datatypes such as:

    (def s (seq ("test1"))

A lazy sequence, but one Clojure still allows to be indexed over in O(1) time. That's probably what the `str` conversion was trying to speed up.

Python, meanwhile, fails on lazy input as it isn't indexable.

    word = (c for c in "test1")

I guess I'll be checking out Clojure this weekend.

>>exitb+gp
Having written a wordle clone recently, this produces the wrong result, by the way. For example guess SASSY with the answer STICK.

>>exitb+gp
I do definitely get more 2AM alerts going off when I work with Python, so it's got that going for it.

>>exitb+gp
And here's what cond could look like in Python syntax:

    def color(word, letter, idx):
        cond:
            word[idx] == letter: return GREEN
            letter in word: return YELLOW
            True: return GREY

>>thauma+NE
You could do something like this in Clojure:

    (first (filter identity
                   [(and (condition-three) (action-three))
                    (and (condition-one) (action-one))
                    (and (condition-four) (action-four))
                    (and (condition-two) (action-two))]))

And you could write a macro to do it with nice syntax. A bit more work and you could parallelize it.

You probably wouldn't want to most of the time, but if the conditions are slow to test but otherwise inexpensive, it might be a useful optimization.

>>mirolj+BC
I'll invoke a no true Scotsman argument here.

>>itisha+dc1
I'm guessing that str allow it to work when the inputs are symbols? So that they are compared as strings rather than by identity. There could be more than one symbol named "foo"; if you want those to compare the same, you can't use regular symbol equality.

Or possibly the code even uses non-symbols for some of the arguments. Suppose that letter is sometimes the integer 1.

>>mirolj+BC
note how they said grok and not work? this is what oncall looks like, reading code at 2 AM

>>exitb+gp
Kotlin time (since we're in the JVM context for Clojure)

    fun color(word: String, letter: Char, idx: Int) =
      when (letter) {
        word[idx] -> GREEN
        in word -> YELLOW
        else -> GRAY
      }