Firstly, Hiccup is Clojure (so basically server only). Cloact is ClojureScript, that compiles to javascript (so browser, node.js, etc).

Secondly, Hiccup produces strings. Cloact typically creates DOM elements, through React, that change every time a component rendered. But it can also produce an HTML string using the same data, to pre-render a page on the server using node.js.

Thanks, again :)

Yes, exactly, Cloact tries to stay really close to plain React. But since it allows you to separate data from rendering, undo should be quite trivial to implement (if you keep all your application data in a single cloact/atom)...

Yep sounds right to me. The other reason I did Om the way I did was to keep the door open for more React optimizations that Om can drive which are more work if you remain close to the React model - particularly only reconciling the specific children that changed in a list instead of iterating over them like React does.

One thing I can't figure out is why they need to be cloact/atoms and not just regular atoms. Is it because cloact/atoms are observable?

In a way. Using regular atoms you can only get a callback when they are modified, but not when they are deref'ed.

You could still use regular atoms, though, with some extend-type magic. But then you risk messing with non-Cloact code in horrible ways...

I've been playing with React a little bit, and so far I like the experience a lot.

Rendering is incredibly quick, since React only touches the parts of the DOM that have changed. Components are very lightweight, so you can break down the UI in as many, self-contained parts as you like.

And you can do pretty much anything you like without ever having to use a single selector or DOM manipulation. That means that you only need classnames for CSS.

The only downside I've discovered so far is the extra tooling required to use the embedded HTML, and lacking compatibility with other tools, but I suppose that will become better with time.

Favorite part:

"Since the only computer language Richard was really familiar with was Basic, he made up a parallel version of Basic in which he wrote the program and then simulated it by hand to estimate how fast it would run on the Connection Machine."

I would've hoped someone of Feynman's level would've easily picked up a better language.

Someone like Feynman is capable of inventing a new language for parallel computing and correctly simulating its execution by hand.

That's a much more impressive skill than just learning another language.

I don't think so. He didn't invent a new language, but extended an existing one. And I simulate what a program does in my head all the time when debugging (including multithreaded stuff, but I agree that's hard).

Feynman may have found the arbitrary nature of syntax for a new language a tedious learning exercise.

I think their problem is much worse than just being a question of improving data quality. They seem to get data from a lot of very different sources, and those simply do not fit together.

For example, in Stockholm Apple's map still shows most buildings as lying in the middle of some street. On the other hand, only relatively few businesses seem to be located in some kind of building. There seem to be quite obvious, and systematic, errors all over the place.

Something like this would make a great addition to CoffeeScript.

It meshes pretty well as is. If only I could get rid of the strings and redundant arguments.

  mymap = pattern {
    '_, []' : -> []
    'f, [x, xs...]' : (f, x, xs) -> 
      [f x].concat mymap(f, xs)
  }

It shares a lot of the same splat/rest/destructuring syntax.

Check out LiveScript's implicit switch syntax:

http://gkz.github.com/LiveScript/#switch

That's along similar lines, but more like guards in Haskell: http://en.wikibooks.org/wiki/Haskell/Control_structures

Last I heard, jashkenas was not a fan of adding such.

"... [P]attern matching inspired by static languages is a particularly poor fit for JavaScript (and by extension CoffeeScript), because types are extremely weak in JS." -jashkenas [1]

"[... P]attern matching is not nearly as useful in a language without rich types [...]" - jashkenas [2]

I'm on that reddit thread, respectfully disagreeing with him.

[1]: https://github.com/jashkenas/coffee-script/issues/1419#issue...

[2]: http://www.reddit.com/r/programming/comments/er0qj/coffeescr...

Thou shalt not use the name of software failure in vain.

Now, if they only could sort out the iPhone app as well. It uses a lot more CPU (and corresponding battery) than other audio players (probably due to its Vorbis use), and skips as soon as the os is busy doing something else.

The new app is a universal binary which also includes iPhone updates, so it might be worth downloading the update and seeing if it fixes any of your issues.

It doesn't seem to fix anything, unfortunately, as far as I can tell after a quick test.

Indeed! The current iPhone app is very buggy...

No problem. It's lists all the way down.