graue

How do you get the 1.1 update for the ZTE Open? Does it need to be downloaded over the air, i.e., won't work if you're using the Open with wifi only?

Thanks, this is why I read all the bad comments on HN: in hopes of seeing a very informative one like this :)

I'll just point out that this:

> The Graph Stores do seem to play better with Java.

was likely a dealbreaker for Diaspora, since they were a small team without, I'd assume, Java experience. Also the nature of the project virtually requires an open-source database so Stardog would've been out. With SQL you have not one but several free and open-source implementations that are battle-tested and work well with just about any programming language out there. That makes SQL a better choice for many projects even if a graph store would map more neatly onto their problem domain.

You've piqued my interest around the state monad specifically, and I just added a long but promising-looking article on it[1] to my reading queue. However:

> Sometimes the "monad patterns" will appear in a language under another name, or will be used "under the hood" to implement a particular API. Clojure/Script's `let` for example is essentially the Identity Monad; and its `for` is very much akin to the List Monad (the same is true for list comprehensions in other languages).

I knew this from reading monad tutorials. And yes, certainly there exist useful things that happen to be monads. But I question the usefulness of explicitly pointing that out and saying, "Here's a monad library. I'm going to use this monad library to build X. You can use all the normal monadic functions on X, because it's a monad", as opposed to putting the monad stuff to the side and just building X. What would you gain from building `let` or list comprehensions atop a monad library? Would it be worth the users you'd confuse? The concept of monad is far too abstract to be intuitive to most people, so there is a cognitive cost to making people think about them.

1. http://brandon.si/code/the-state-monad-a-tutorial-for-the-co...

> optional static typing

https://github.com/clojure/core.typed

> multimethods

http://clojure.org/multimethods - also, arguably better for many use cases: http://clojure.org/protocols

> native and efficient executables

Clojure performs much better than popular web development language implementations like Python, Ruby or Node.js. See http://www.techempower.com/benchmarks/ People have found it performant on harder problems: http://clojurefun.wordpress.com/2013/03/07/achieving-awesome... And it's possible to produce executables that depend only on the JVM, which is just as easy as fully-native for deployment.

I grant you the one about the Common Lisp condition system. I wasn't familiar, but reading about it (http://c2.com/cgi/wiki?CommonLispConditionSystem), it does look intriguing. Apparently something inspired by it is available as a Clojure library, but the last commit was 10 months ago, and I hadn't heard of it till now: https://github.com/scgilardi/slingshot

As a Clojurist not familiar with Dylan, that sounds awesome, but then it also just sounds like Clojure. What does Dylan add to the mix?

I'm reading their "Why Dylan?" page:

http://opendylan.org/documentation/intro-dylan/why-dylan.htm...

and I don't see anything that makes me want to go run and install it. I'm already used to dynamic, garbage-collected, infix programming languages that can be used in a functional style. Heck, JavaScript is one. Integers and strings are objects, cool, but how does that help me prototype faster or write more maintainable code?

Even in the best year (2008, $3269) this isn't remotely enough to live on. That's less than $9 a day, and that's an exceptionally high payout! In 2012 it was $2.40 a day. Maybe you could live on that in India or Vietnam, but not in the U.S.

From the article:

> Some folks say graph databases are more natural, but I’m not going to cover those here, since graph databases are too niche to be put into production.

Have you used a graph database to good effect? Which one, and for what?

I have a friend who as a learning exercise wrote a toy search engine implementing PageRank — inherently a graph problem. We paired on setting up Neo4j, the only open-source graph database we could find with a working Python API, but found it fiddly and hard to get help. She then switched to SQL (Postgres, I think) and reported faster progress.

Facebook themselves use MySQL[1], so between that and my own first/second-hand experience, I'd call it far from obvious that a graph database is the most appropriate way to store social information. If you're going to criticize the OP for not considering them, it would be nice to offer some justification.

1. https://www.facebook.com/notes/facebook-engineering/mysql-an...

In what circumstances is it the best choice? I get the impression that monad libraries in dynamic languages are basically toys, or are written to show off. If I'm wrong, I'd love to see examples of how you used them in a ClojureScript project, why (other than novelty value) you chose them over other approaches like atoms, and how they worked out in practice.

This just sends five bucks — it isn't tied to a specific drinking establishment or brewery, or even to beer. Totally not the same.

After a great article on what looked to be a handy tool, this part disappointed me:

for this particular task, XPath is actually considerably slower than the pure-Ruby implementation. Interestingly, that's not true if you take out the <br> part and only look for text at the beginning of paragraphs. My guess is that the following-sibling axis is the culprit, since it has to select all the following siblings of the br tags, and then filter them down to only the first sibling.

I was hoping selectors were lazy, in which case, selecting all the following siblings but then immediately filtering that selection down to the first would be cheap. Lazy or not, can there really be no efficient way to do the equivalent of jQuery next()?

Can't help but notice Costolo touting stuff that used to be good about Twitter but that they've since messed up.

"Users can follow only the things they want to follow."[1] But now the mobile app shows push notifications for irrelevant events, like 3 people you follow following another person. Can't turn it off. So no, users are no longer in full control of what they see.

"The 140 character limitation means information flows at a high velocity." Except now with auto-expanding pictures you only end up seeing like 2 tweets at a time on a phone screen. This change is a serious compromise to the core Twitter experience, giving images undue extra weight and making it harder to scan.

He even brags about having third-party clients! Yup, which they have deliberately forced into providing a second-rate experience[2], and sucked the oxygen out of that market completely by capping number of users.

What all these changes have in common is that they make Twitter more like Facebook. I understand the reasoning, of course: More events shoved in users' faces = more engagement. Auto-displayed pics = improved discoverability for new users. Killing third-party clients = can claim tweets look and work the same everywhere, as Costolo also mentions. But what does it all add up to? A streamlined, embeddable Facebook with a smaller length limit?

Maybe I'm too annoyed with Twitter's devolution to see this rationally as an investor. Or perhaps I'm reading too much into the first two changes I mentioned, which could, after all, be reverted. But to my jaundiced eye, they show the company's on a clear path of tossing out its unique strengths, becoming just another social network also-ran.

1. Quotes paraphrased since the video player won't let me rewind to check exact wording.

2. https://twitter.com/manny_neira/status/300437233993912320

You're describing a cultural and economic shift towards collectivism and away from individualism, which, to me, seems no more likely than basic income.

I think it may take decades for basic income in America to go from unthinkable, to radical, to controversial, to reasonable, to seemingly inevitable, to reality. But that's all the more reason to start talking about it now. Let's get the ball rolling!

Ah, your wording was ambiguous. I thought you meant, in this situation:

    ...
      X
        Y
    ...

since Y is one indentation level deeper than X, prepend parens to Y. But you meant "since there exists Y such that Y is one indentation level deeper than X, prepend parens to X".

That doesn't explain the third line. Your rule would result in

    (if condition
      (1)
      (else-clause))

trying to call 1 as a function, which is an error.

I've gotten in that habit as well, but then, I'm a neat freak when it comes to git, always using `git add -p` and filtering out any unrelated changes into different commits. I'm often dismayed how sloppy other programmers are with git :)

Commit messages like "Ugh, I really need to commit more often. Did X, Y, Z, and maybe some other stuff." make me cringe. Those people need this change the most!

Offtopic: I didn't know about `git branch -v`. Not something I needed enough to go looking for it, but nifty and good to know! Always learning more Git tricks :)

Ha. I just got a ZTE Open, mostly to hack on. It's cool, but not ready to be my primary phone yet.

On that note, I have to wonder if the buyers of these super-sized Android phones are like 80% male or what. Women have much smaller hands than men. This hit home for me when I bought winter gloves in a "women's extra-large", because the store was out of "men's small". They're two different labels for the same size! For me, the Nexus 4 works fine, but if it were any bigger, or my hands any smaller, it'd be awful hard to use one-handed. Five inch phones seem to be excluding half the market.

While I suspect most Lispers are shaking their heads and muttering, I actually like this. Seems to preserve the benefits of homoiconicity while reading more like natural language.

I would try it if there were a Clojure-compatible flavor (the {} conflicts with hashmap syntax) with a Leiningen plugin to convert it to regular Clojure when building. Kind of a CoffeeScript to Clojure's JS.

Edit:

Wait a sec, how does it know to prepend an open paren to the second line (the if) but not to the third line (body of the if)? Each one is indented. Does it have special, hardcoded knowledge of the 'if' form?

This looks a little problematic to me because the preprocessing isn't following an obvious rule. It brings to mind the big downside of CoffeeScript — the cleverness required to allow such natural-looking code can also lead to unexpected results in edge cases.

I never use either. I open Firefox and tap my search terms into the awesome bar.

Huh. After trying this in Chrome it seems a lot less pointless. I wondered why you needed a JS library just to console.log a list of strings :)

(Apparently they modified it to degrade to that after you posted.)

That would seem to be a harder problem for the NSA. First, it has to be an active attack, modifying data in transit rather than merely siphoning it off — probably tougher to cover their tracks in that case. Second, automatic updates are presumably cryptographically signed by the publisher, so the NSA also has to steal or crack the private signing key. Third, how do you target the backdoored version of the software so certain groups/people get it and others don't? CDNs don't work that way.

In the end, it seems much more practical to sneak a backdoor into the software at the source.

I thought you were wrong about that, but when I went looking for a source, I found out you're right. As of June, major email providers other than Google did not support encryption for inbound emails[1]. That's disappointing.

Note there's no technical reason they couldn't. Also, Fastmail.fm, while arguably not really a major player, is an exception, supporting encryption on inbound emails since 2009[2].

I just verified this via http://www.checktls.com. A later blog post in 2010 says Fastmail enabled it for outbound email as well. So mail sent from Gmail to Fastmail or vice versa is encrypted between the two providers.

It's a start. I really thought I had read something about Microsoft enabling this on their email service, too, but I must be misremembering. All we can do is hope more big providers turn it on.

1. http://news.cnet.com/8301-13578_3-57590389-38/how-web-mail-p...

2. http://blog.fastmail.fm/2009/04/16/opportunistic-ssltls-encr...

Mozilla can't stay relevant catering only to users willing to make that compromise, because they are so few.

No guarantee, but the same team was successful at getting Opus (audio codec) adopted as MTI for WebRTC. http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6...

On a purely technical level, Opus' performance blew the pants off the other options, which surely helped. If Daala can repeat that performance I think they have a good chance.

Rust is about long-term strategy. They need it to build Servo, and they need Servo so they have a state-of-the-art browser engine in 5 years.

An unbelievable amount of effort has gone into optimizing Gecko, with impressive results, but ultimately it's an aging, legacy codebase. More importantly, neither Gecko nor WebKit/Blink are ready for a manycore world. As Brendan Eich puts it[1]:

The multicore/GPU future is not going to favor either WebKit or Gecko especially. The various companies investing in these engines, including us but of course Apple, Google, and others, will need to multi-thread as well as process-isolate their engines to scale better on “sea of processors” future hardware.

There’s more to it than threads: due to Amdahl’s Law both threads and so-called “Data Parallelism”, aka SIMD, are needed at fine grain in all the stages of the engine, not just in image and audio/video decoding. But threads in C++ mean more hard bugs and security exploits than otherwise.

I learned at SGI, which dived into the deep end of the memory-unsafe SMP kernel pool in the late ’80s, to never say never. Apple and Google can and probably will multi-thread and even SIMD-parallelize more of their code, but it will take them a while, and there will be productivity and safety hits. Servo looks like a good bet to me technically because it is safer by design, as the main implementation language, Rust, focuses on safety as well as concurrency.

1. https://brendaneich.com/2013/02/why-mozilla-matters/

Ugh, why do people do that to begin with? :( I've had Web Audio for a while since I'm on the Aurora channel, and there's so many demos that refuse to work for no reason.

I try to do my part by submitting pull requests that fix it, when possible, but most of those pull requests have been sitting ignored for months.

Clearly more people need to be educated that user-agent sniffing = bad.

You may be thinking of Clojure and ClojureScript — with a J. It's confusing naming, but those are different, and are not Google products.

In this thread, we're talking about Google's Closure (with an S) Library. Google also makes a Closure (with an S) Compiler, but it's more of an optimizer — it "compiles" from JavaScript to optimized JavaScript.

So, this is not exactly related, but I see that you also work on Firefox OS, and I assume part of the reason for this project is to improve location services on FxOS.

I got a ZTE Open to play around with, and was disappointed to find that it can't figure out where I am. Of course, I know it's a cheap phone and the OS is only in version 1.0. So if the location were a little inaccurate, or took a long time to come up, I would understand. But it literally never gets my location at all. (I live in NYC.)

Why do you think that would happen? And tying it back into this project, how soon do you think FxOS end-users will start seeing improvements from what you're doing?

OK, I can see the case for that nitpick. Perhaps neither implementation is particularly "polished" in this regard, and the JVM one just happens to fail faster due to a statically-typed host environment. Polished or not, though, the end result is Clojure being more helpful when you make typos/newbie mistakes.