aaroniba

To what extent do tight-knit teams adjust their interpretation of confidence levels on an individual basis to reflect their ratio? Like, "Overconfident Oscar expressed a tiny bit of doubt, so he must not really have high conviction at all." Or, "Underconfident Uma expressed slightly more conviction than usual, so we should pay attention."

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.

Yes. Perhaps this is a performance choice for DataScript since DataScript does not keep a complete transaction history the way Datomic does? I would guess this helps DataScript process transactions faster. There is a github issue about it here: https://github.com/tonsky/datascript/issues/366

Yeah, I've used a transaction functions a few times but never had a case where two transaction functions within the same d/transaction ever interacted with each other. If I did encounter that case, I would probably just write one new transaction function to handle it.

I think the article answers your question at the end of section 3.1:

"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.

That's a good point. Even though this would weaken my argument (slightly), I now wonder if modern JITs can completely optimize debug.log(someExpensiveFunction()) into a NOOP if they realize that the argument won't end up being used inside the log function.

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.

Yes lots of programming consists of gluing together libraries, but in my experience languages vary dramatically at how well they do even this.

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.

I have a Boosted Rev and live in Nob Hill in SF with some steep hills. It zooms up all the hills pretty easily.

Like others, it took me a while to understand what this actually does. Even coming from a Clojure+Datomic background.

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 know that algorithmic betting on horse racing is popular in the UK via exchanges like Betfair. Does anyone know if there is an exchange/API for Hong Kong horse racing?

You might think from the URL or logo that this is some kind of official ClojureScript page, but it's not. The official page is clojurescript.org (no hyphen).

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 <title> with "unofficial"; and adding a more prominent link to clojurescript.org titled "Official ClojureScript Page".

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)

I agree there are many considerations when choosing a library, but conciseness does come up. For example, I was recently impressed with how concise http-kit is. The author seems proud of it too:

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.

Yes. You put it better than I did.

This is great. I wish I had this when I was learning reagent.

I've been using Swiss Arrows. https://github.com/rplevy/swiss-arrows

The equivalent clojure code would be:

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

BattleCode was the best thing I did while at MIT, and one of the most unique and rewarding experiences of my life.

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.

It looks like drip does not automatically work with lein:

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.

Yes, it's really faster than biking. I average 12mph on the boosted board. I know because I use a GPS app on my iphone to monitor my rides. This is unfortunately necessary because my prototype board does not have a battery gauge, so I need some idea of how much battery I have left.

I also weave through traffic. I don't know how to evaluate whether it's more or less safe than doing the same thing on a bike or motorcycle, but it doesn't feel any less safe.

I bring it in wherever I go. Haven't had a problem yet.

While grocery shopping, I put it underneath the shopping cart.

I said that.

I realized my world was divided into: places I could walk to, places I could bike to, and places I could drive to.

Where I live (downtown Palo Alto), driving is a hassle because of traffic and parking. Driving is annoying, boring, frustrating, life-wasting... basically I hate driving and use it only as a last resort.

Walking is great, but it's slow. It's really time-consuming to walk anywhere beyond a few blocks.

Biking is pretty fast, but still a bit of a hassle because I have to bring a heavy U-lock and worry about my bike. "Where is my bike and is it OK?" is always in the back of my head, which makes it harder to enjoy whatever I'm doing. Also biking doesn't leave any hands free to carry things.

Now I have a Boosted Board with a 6-mile range. For any trip under 3 miles, it is:

* Faster than walking, biking, or driving.

* More fun.

* No extra hassle, nothing to worry about.

* Leaves 2 hands free to carry stuff like groceries.

So it's opened up this whole 3 mile radius of things around me that I previously wouldn't go to. Now these places feel like they're at my fingertips. It feels like my world got smaller.

I tried those and other location-sharing apps but I couldn't find any that didn't suffer from two problems:

1. They force my contacts to go through many steps, like downloading an app, registering an account, etc. It's hard to get someone to download and setup an app. It's easier to get them to click a link.

2. They force my contacts to share their location 24/7, which I don't need and they don't want. Having users "explicitly provide consent every time" is a feature.

You're right that I should put this in the app description.

Yeah, there are many apps that do this in reverse. I was surprised at this, because I find it so much more useful to get someone's location than to share my location.

Thanks, you actually hit on my #1 question: whether people will remember to use the app. I guess we'll see now that it's out there.

Also it should auto-refresh whenever it gets an Apple Push Notification. If the push notification is delayed, then your clicking refresh could show new data.

Thanks for the feedback! The UI is just a webview that refreshes from a server. This is so I can iterate on the UI without going through the app store, but I agree native would be better. I'm thinking of actually using clutch.io in the next version.

I agree with the rest of your feedback as well. Good stuff.

The conclusion I drew from this experience was that I should get over my fear of making mistakes. I could have been more clear on that in the post.

There's probably some optimal level of fear-of-mistakes for any given project. Monorail made me realize my brain was tuned too far in the fear direction. I stand by that generalization.

Most greedy algorithms I've seen do not have a repair step.  But whether I call it "iterate-and-repair" or "greedy" doesn't change the message, does it?  Or are you saying that I shouldn't be surprised that iterate-and-repair works so well on this puzzle?

Cofounder and former CEO of EtherPad here. I appreciate your kind words about our product. Allow me to clarify some aspects of the story.

First, we knew etherpad was more than a toy. We knew people were using it for real work. We had paying customers and thousands of dollars a month in revenue. (Not a lot of revenue, but decent evidence that etherpad was more than a toy).

Second, the relationship between etherpad and appjet is much different from how you characterize it. AppJet was a failing idea. We had like no users. We had spent over a year building this developer platform and we had practically zero developers actually using it. It clearly wasn't working. We were ecstatic when etherpad took off. After etherpad took off, we shut down appjet.com and focused our entire company on etherpad. appjet.com redirected to etherpad.com. It felt great to have a product that people were actually using!

Third, we never thought the Wave product was better than the etherpad product. However, the Wave vision was pretty awesome. Lars' narrative excited a lot of people when he delivered the announcement at Google IO '09. When we met with him, we were dazzled by his vision and the team's optimism. Perhaps we were naive.

The decision to sell to Google was one of the toughest decisions I and my cofounders ever had to wrestle with in our lives. We were excited by the Wave vision though we saw the flaws in the product. The Wave team told us about how they wanted our help making wave simpler and more like etherpad, and we thought we could help with that, though in the end we were unsuccessful at making wave simpler. We were scared of Google as a competitor: they had more engineers and more money behind this project, yet they were running it much more like an independent startup than a normal big-company department. The Wave office was in Australia and had almost total autonomy. And finally, after 1.5 years of being on the brink of failure with AppJet, it was tempting to be able to declare our endeavor a success and provide a decent return to all our investors who had risked their money on us.

In the end, our decision to join Wave did not work out as we had hoped. The biggest lessons learned were that having more engineers and money behind a project can actually be more harmful than helpful, so we were wrong to be scared of Wave as a competitor for this reason. It seems obvious in hindsight, but at the time it wasn't. Second, I totally underestimated how hard it would be to iterate on the Wave codebase. I was used to rewriting major portions of software in a single all-nighter. Because of the software development process Wave was using, it was practically impossible to iterate on the product. I should have done more diligence on their specific software engineering processes, but instead I assumed because they seemed to be operating like a startup, that they would be able to iterate like a startup. A lot of the product problems were known to the whole Wave team, but we were crippled by a large complex codebase built on poor technical choices and a cumbersome engineering process that prevented fast iteration.

I'm grateful for the many lessons learned through the whole experience. And I'm hopeful that the same software engineering and product skills that produced etherpad, combined with the many valuable lessons learned through the Google acquisition, will be able to produce even better products in the future. My cofounder David Greenspan and I have both left Google, so we are not, as you say, stuck in the vortex.

If you have more specific questions, I'd be happy to provide additional clarification.

Ah, I see. Thanks!

The math on increasing the pixel density for iOS touchscreen devices is such that it only works out perfectly if the resolution doubles, like when the iPhone and iPod Touch went from 480 × 320 to 960 × 640. Trust me, it’s double or nothing.

That's interesting. Can someone explain why this is the case?