Also, from my experience, it seems like (and this isn't a strong opinion) doing competitive high school debate teams turns people into Overconfident Oscars.

> "This behavior may be surprising, but it is generally consistent with Datomic’s documentation. Nubank does not intend to alter this behavior, and we do not consider it a bug."

When you say, "situations leading to invariant violations" -- that sounds like some kind of bug in Datomic, which this is not. One just has to understand how datomic processes transactions, and code accordingly.

I am unaffiliated with Nubank, but in my experience using Datomic as a general-purpose database, I have not encountered a situation where this was a problem.

The javadoc for slf4j's Logger.debug implies that the JIT cannot be relied on for this:

http://slf4j.org/apidocs/org/slf4j/Logger.html#debug(java.la......)

"This form avoids superfluous string concatenation when the logger is disabled for the DEBUG level"

I think that means if you call Logger.debug("a"+"b"), the string concatenation happens even if DEBUG logging is disabled. But maybe JITs have improved since that javadoc was written, or the author was not aware of how smart JITs are.

I would be curious to know if there is a JIT expert who could weigh in on this question.

For example, consider logging libraries. It's useful to have statements like log.debug(someSlowFunction()) in your code. In LISPs it's really easy to create a (debug) macro that generates empty code when you don't want debug logging turned on. In other languages, you have to wrap the arguments in a function to avoid extra runtime costs, and even then you can't avoid the "if debug" conditional at runtime. All those anonymous function wraps add clutter, and that clutter accumulates. There are many other cases where having advanced language features greatly helps gluing together libraries.

Another aspect is the tooling. When I am considering a new library, I like to try it out in the REPL. In Clojure I can quickly start calling library functions, and use the (time) macro to get a sense of how long they take to evaluate. Not all popular languages are amenable to this kind of REPL-driven experimentation with libraries.

Not only does the language impact how you use libraries, but it also impacts what libraries may exist. Some libraries are simply not possible to write in less powerful programming languages. In LISP this would include any library that uses a macro. For example, Clojure was able to introduce core.async as a library, providing an async facility similar to what golang offers. But in most languages you wouldn't be able to implement that as a library.

Another major example is reagent vs. react. The concise hiccup representation supported by Reagent is only possible because of design decisions that went into Clojure. JavaScript users are stuck with JSX, which is less concise, and in my opinion far less good.

Another issue that arises when using libraries is whether or not the language has a static type system. Without getting into the age-old flamewar about static vs dynamic typing, I'll just note that popular languages differ in this dimension, and this has a big impact on what it's like to glue together libraries.

So overall, I think this essay undersells the benefits of LISP. Even if you spend all day gluing together libraries, LISP makes that much better by improving how you can call libraries, how you can quickly experiment with them, and even what kinds of libraries can exist.

As best I can tell, this is like phpMyAdmin for Datomic. But the cool and unique thing about Hyperfiddle is that in addition to writing queries and seeing the results, you can customize the result display using markdown or even arbitrary clojurescript code. Then you can generate forms to input new data (based on the schema of the database), connect it to more clojurescript, and before you know it you've built a web app. Because the whole thing is web based, you can send a link to your "fiddle" (web app) to other people, and they can use it without knowing anything about programming. This is all without git, editing text files, or even thinking about deployment or hosting. I think that's all pretty cool.

In most situations, this would be dangerously powerful, especially running on a production database. But Datomic has unique facilities for speculating "what if I transacted this" (which is how the hyperfiddle staging area works). Datomic also has powerful undo and time-travel options, which makes it much less terrifying to hyperfiddle it.

It's also cool that hyperfiddle queries/views/code are all stored in Datomic, so you get a sort of version control type layer built-in.

I think this is a cool vision for making it much quicker to develop lightweight database-backed web apps. Obviously the current state of hyperfiddle needs a lot of work on the UI and home page to explain this all.

I don't speak in any official way for ClojureScript, but as an enthusiast, I wish this author had chosen a different URL to make that more clear.

Other ideas to mitigate the confusion: using a different logo in the corner; prefixing the html I recently used this algorithm in a project. For anyone looking for a high-quality Java or Clojure implementation, I would recommend:

https://github.com/timothypratley/munkres (Clojure)

Which wraps:

https://github.com/kevin-wayne/algs4 (Java)

http://www.http-kit.org/http-kit-clean-small.html

You and I probably just have different values on this matter. Your comment implies that conciseness is merely "nice", so I'm guessing you just don't value that aspect of code as highly as I do.

Comments URL: https://news.ycombinator.com/item?id=14445597

Points: 119

# Comments: 12

Comments URL: https://news.ycombinator.com/item?id=14368350

Points: 1

# Comments: 0

    (defn f [a b]
      (let [res (join "," (sort (distinct (mapcat keys [a b]))))]
        (if (empty? res) "" res)))

The way David and I were able to win it in 2003: at that time, robot positions were stored as two doubles (x,y). You could move yourself by a precise amount or read the precise x,y position of another robot, each in only 1 bytecode. So instead of using broadcastMessage(String), checking that no other team was trying to screw with our messages, all of which took lots of bytecodes to get right. Instead of that, our robots communicated through the low bits of double values in their positions. Kind of like bees dancing for each other. This gave us enough of an edge to beat out all the other players. This was 100% David Greenspan's idea, by the way. I just worked hard to help code it up.

MIT classes are supposedly a lot of hard work, but at that point I had never worked as hard on anything as I did on our BattleCode player.

https://github.com/flatland/drip/issues/36

Here's my workaround to use drip to start up lein repls instantly:

https://gist.github.com/4103370

Should work with lein1 & lein2.