True, but I am convinced that meditation can lead to awakening, which, apparently, involves the cessation of suffering and feeling one with the universe. It's not so far fetched, since our experience is generated by our brains, and similar things can happen on drugs.

Is thinking obsolete too?

It really is readable, to me at least. I just wanted to say that because some people will perhaps read your comment and take it as true, because they too struggle with it at the moment, and then discard Clojure. But I'm just in love with it---yes, the syntax.

I was interested until I noticed it was pay-to-win. Instantly closed the tab.

It is not pay to win. In fact, you can get everything without paying a penny, it just takes longer. For example top players have not paid anything.

No. I love it. It's so simple. Even if Haskell has pretty nice syntax, I found myself resenting it because I needed to remember operator precedence.

For very simple cases there are the threading macros, `->` et al., that you can use like this:

  (-> state 
      (assoc :a val) 
      (update-in [:b :c] f args) 
      (dissoc :d)
      (some-other-fn args))

where :a - :d are keys.

Or you could use monads in much the same way as you would in Haskell; there are libs for that.

Or you could write a new macro (or maybe even function) that does exactly what you want. I did that for a game. It looked like this:

  (call-update-fns game-state hook
    (update-monster-positions)
    (update-monster-ai)
    (let-characters-attack)
    (some-other-stuff))

It would thread the game-state (immutable) through all the functions, and call hook (a function) in between all the functions to send network messages and stuff (to minimize latency), and also collect and return new events that the functions created that I needed to handle (e.g. someone died when the characters attacked). It's almost like the state monad but not quite.

And there's synthread[1] for more complex cases:

   (-> {:a 1 :b 2}
     (->/assoc :a inc)
     (->/as {:keys [b]}             
       (->/when (> b 10)
         (->/assoc :large-b true))))

1: https://github.com/LonoCloud/synthread

Yeah, only Lisp is beautiful. ;)

Big O is not necessarily about execution time. Also, why is it ridiculous to describe execution time as "time complexity"? From http://en.wikipedia.org/wiki/Analysis_of_algorithms "Usually, the efficiency or running time of an algorithm is stated as a function relating the input length to the number of steps (time complexity) or storage locations (space complexity)."

> Also, why is it ridiculous to describe execution time as "time complexity"?

It's unnecessarily different than the normal definition of "complexity." When you say "complex" in normal conversation, you mean "complicated" or "hard to understand." You would never say "the time complexity of getting to the airport is 30 minutes."

It also begs the question. Wrapping your head around the idea of asymptotic complexity is the hard part of understanding big O. Defining big O in terms of complexity doesn't help if you don't understand the concept of asymptotic complexity yet.

I think the best way to explain this, by far, is with a graph.

If the definition uses "complexity" in this way then it's not using it in the "plain English" sense, but in a specialized sense. Quantity isn't complexity.

Branching factor 32 is great for lookups, but isn't it slower for modification? At least, one has to create more array cells in total (31 copies in each node), no?

First of all, O(g(n)) is a set. It is the set of functions f(n) such that there exists positive constants n0 and C, and C*g(n) > f(n) when n > n0.

Second, talking about O(g(n)) does not imply that the time complexity being discussed is the worst-case (or any other case) time complexity. One could for example say that the algorithm A's best-case time complexity is in O(n), and it's worst-case time complexity is in O(n^2).