Simulating Machines in Clojure | Hacker News Reader

Simulating Machines in Clojure

stopa.io

161 pointsstopachka17 comments

One thing that stuck with me from a good Clojure book(1) is that using < is greatly preferable to using >. Coming from an OO background and reading left-to-right, this made sense to me: list the args from smallest to largest.

(< 1 2 3) ;; true

is a lot more intuitive to me than

(> 3 2 1) ;; true

even if one or more of those literals is replaced with an argument. It’s especially apparent with the two-arg use of the function. This is one of the few places where I still feel like infix notation has an advantage.

This isn’t even a nitpick about the article, just a remark about some cognitive dissonance seeing > used here.

(1) Maybe Elements of a Clojure? Not sure that’s it; it was a book referenced on HN which has a whole chapter on naming things.

This is true in other languages as well, even Clojure's polar opposite, C++, where operator< is canonical tool used for sorting and other things.

The historical preference of < over > seems to be widespread in programming languages, here's a credible sounding explanation of the origins: https://stackoverflow.com/a/12146965

Regardless of the origins, < is just a more natural operation than >. I kind of mean that both figuratively and literally: the most "natural" numbers are the "natural numbers", which follow 1 < 2 < 3... and not 1 > 2 > 3...

I see what you mean. But if we consider endianness and reading direction arbitrary conventions does it still hold? Maybe it does, since in your latter example the reading direction is inverted in any case and endianness applies only intra-number.

Yeah, I was just talking about the mathematical less-than operator. How we choose to represent anything computationally or visually is orthogonal to it.

> (1) Maybe Elements of a Clojure? Not sure that’s it; it was a book referenced on HN which has a whole chapter on naming things.

That's correct.

Both factorizations feel the same to me, without context. Subsequent numbers are greater than the previous ones vs. subsequent numbers are lesser than the previous ones.

What should really matter is how you're "talking" in the code. If you've defined some relationship as y being greater than x, then that's how you should phrase the comparison as well: (> y x). (< x y) would be the same thing logically, but we don't read logically: it requires another mental step to understand that (> y x) and (< x y) are equivalent. It's avoiding those extra steps that gives code a really big readability boost.

I think this is a fun article, really fun little rawing.

But "imagine an SR latch!" is always funny to me in these kinds of explanations. The base circuitry for electronics have really powerful primitives, but if you are coming from first principles then it's like.... where did you get this from? In itself it's a really non-intuitive device, and only starts making sense in a larger context.

It's of course also what we actually do, just I think not something anyone would ever come up with in a vacuum if they were thinking "how do I build computers"

Indeed rtpg -- going deeper, these latches did trip me up!

You may enjoy this question on SE: https://electronics.stackexchange.com/questions/524618/how-d... -- ended up getting a great answer for how this worked beyond the abstractions I was comfortable with.

Plan on using what I've learned to write something about simulating RAM -- that may get us closer to building up the base circuitry

btw, do you have the RSS or Atom feed for your blog? I want to include your Clojure posts into https://twitter.com/planetclojure - drop me email to alexott at gmail, or create a pull request to https://github.com/ghoseb/planet.clojure

thank you

> If you were dropped in a forest…you could create your own computer.

Could you really? I've heard of fun things like water-based logic gates, but even with primitive elements like that it doesn't seem at all easy to come up with anything even mildly useful.

Another option would be pulleys: https://www.youtube.com/watch?v=CNbScb8v-MI

it's a cool way to think about what we take for granted, and definitely the author had a blast reading SICP

Thanks for the kind words grimgrin!

Did you do the entire book in Clojure or just this part? Thinking of forking SICP Distilled and was wondering if there's a reason why it stopped other than the author losing interest.

We went through the whole book :)

https://github.com/nezaj/clj-sicp < here are the answers to the questions we chose to do. Hope it helps in your adventure!

Whilst I like the separation of () and [] etc I am not sure I like the recursive syntax or requirement. A bit ugly.

Reply on news.ycombinator.com