zlacker

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+(OP)
> 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+h4
And yet we've all done it.

>>auggie+l5
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+(OP)
That's because you are more familiar with whatever style of code you are used to.

Don't confuse familiarity with readability.

>>exitb+(OP)
> 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+zk
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.

>>exitb+(OP)
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+(OP)
Having written a wordle clone recently, this produces the wrong result, by the way. For example guess SASSY with the answer STICK.

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

>>exitb+(OP)
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

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

>>itisha+XM
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+ld
note how they said grok and not work? this is what oncall looks like, reading code at 2 AM

>>exitb+(OP)
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
      }