8,005 karma · joined October 10, 2007
I've worked on a few fun projects, including satellite defense for the DoD, a couple of big Lisp webapps, and large distributed systems.
If you need to reach me: {myusername}@gmail.com
Some of me online:
https://github.com/smanek
https://twitter.com/smanek
http://arantaday.com/
http://lambda-the-ultimate.org/
http://www.stefankrause.net/wp/
http://mechanical-sympathy.blogspot.com/
http://www.cowtowncoder.com/blog/blog.html
http://highlyscalable.wordpress.com/
http://perspectives.mvdirona.com/
Had to write my own bitmap processing library, since couldn't find anything fast enough off the shelf :-D Handled alpha blending, file i/o, etc (checkout the bitmap.lisp and color.lisp files in the repo).
Here's a video of it 'evolving' a picture of John McCarthy (best individual from each generation): http://www.youtube.com/watch?v=-_VFZ_ON0A8
And here it is doing the Mona Lisa: http://www.youtube.com/watch?v=S1ZPSbImvFE
She's often considered the face of the irrational exuberance behind the first dot com boom/bubble.
Rating many companies that subsequently lose 90-100% of their market cap as 'strong buys' is a pretty scary track record. IIRC, her portfolio of 'outperforms-or-better' lost ~80% of their value in one year.
Granted that the 'market can remain irrational longer than you can stay solvent', etc so she may not deserve all the scorn heaped on her (I haven't done the research to know ...)
My hope is that it will only take a day or so to deploy it, once it's ready.
I would expect it to solve most of your performance problems for the foreseeable future (at the very least, by letting you scale horizontally and move the DB, frontends, and memcaches to separate boxes - plus ending memory leaks/etc by moving most of the data off the MzScheme heap).
The obvious downside is that it would use your (or someone at YC's) time. First to merge the changes I make to http://ycombinator.com/arc/arc3.tar into the production code, then to buy/setup some extra boxes and do the migration. We're probably talking, roughly, a day. It also has the unfortunate side effect of costing HN's src some of its pedagogical value, since it adds external dependencies and loses 'purity'.
Been looking for an excuse to learn arc for a while now ...
On a several decades/century scale it's worthwhile to funnel at least a few percent of GDP into basic science research[1]. But, in any given quarter/year, it's almost certainly a net loss. The trick being that every few decades, you'll get nuclear power, the transistor, etc[2].
Or, as a 'local' example: non-trivial number theory had basically no benefit for centuries but humanity kept 'investing' resources into it - which a short term optimizer wouldn't. Then, cryptography came along and it suddenly 'paid' for the entire field a dozen times over.
[1]: Research is sort of like early stage VC - but with funds that pay out over 70 years instead of ~7.
[2]: I would love to write about many more examples in much more depth, but will omit for the sake of brevity. I roughly feel like the newtonian mechanics was directly responsible for the industrial revolution, relativistic physics for the nuclear age, quantum mechanics for the computer age (with similar analogues in the biological sciences).
For OS's, Tanenbaum (http://www.amazon.com/Modern-Operating-Systems-Andrew-Tanenb...) is popular.
'Math' is broad - if I can recommend only one book to cover all of Math I'd probably say 'The Road to Reality' (http://www.amazon.com/The-Road-Reality-Complete-Universe/dp/...). More practically (for the subset of math most programmers are likely to care about), you'll do fine with one good discrete math book and one linear algebra book. Throw in one each on Stats, Abstract Algebra, Calc (up to ~diffeq), and Real Analysis (in roughly that order) if you're a bit more ambitious ;-)
I like to use HL Mencken as inspiration.
I wish I had kept in better touch with him. He will be missed.
Personally, I use (and prefer) LastPass to this approach.
Look at Norvig (Google's head of research, and AI-demigod) at al's paper "The Unreasonable Effectiveness of Data."
The first hit on searching for the quote explains its history: http://quoteinvestigator.com/2010/08/27/master/
Seriously, stop being overly PC. You're just being annoying.
The problem with an imprecise GC is that having an integer that looks like a pointer, could prevent an object from being freed.
- Shaw's opening volley: http://web.archive.org/web/20080103072111/http://www.zedshaw... [lots of stupid personal flames - but his technical points are consistent with what I remember from the time]
- DHH's response: http://david.heinemeierhansson.com/posts/31-myth-2-rails-is-...
- I can't find a copy of shaw's actual response, but here's the relevant HN thread: http://news.ycombinator.com/item?id=364659
The salient point (quoting Zed):
"""
Now, DHH tells me that he’s got 400 restarts a mother fucking day. That’s 1 restart about ever 4 minutes bitches. These restarts went away after I exposed bugs in the GC and Threads which Mentalguy fixed with fastthread (like a Ninja, Mentalguy is awesome).
If anyone had known Rails was that unstable they would have laughed in his face. Think about it further, this means that the creator of Rails in his flagship products could not keep them running for longer than 4 minutes on average.
Repeat that to yourself. “He couldn’t keep his own servers running for longer than 4 minutes on average.”
"""
I've never been much of Ruby/Rails guy - but my understanding is that everyone had to restart Rails a few times an hour cause the memory leaks were so bad in those days.
It sounds crazy (and it is!) - but it often works reasonably well in practice. SBCL (one of the most performant Common Lisp implementations) has an 'imprecise gc' that works the same way - and I've seen reasonably heavily stressed processes with uptimes in the weeks/months.
Remember, even a few years ago (before fastthread, etc) a reasonably loaded Ruby on Rails app couldn't stay up for more than ~10 minutes w/o memory leaks forcing a restart (DHH said 37Signals as doing ~400 restarts/day per process, IIRC) because the runtime was such a piece of crap. Yet, many people still used it to solve real problems and make real money.
At least Go's memory leaks are much slower than Ruby's ;-)
The patent issues are regarding Dalvik AFAIK, so I don't see how it's relevant to this discussion ... (although, from what I've heard, it seems like Oracle's being a jerk ...)
If you think that a general purpose language has to be able perform as well as C without calling native code (JNI, FFI, etc), I guess I'd have to agree Java isn't 'general purpose' . But I'd contend neither are Python, Ruby, Erlang, Javascript, etc under that definition. Therefore, that's probably not the right definition, since it excludes most general purpose languages ;-)
Being able to synchronize on any object is actually really efficiently implemented (8 bytes of Object overhead total, neat optimizations like biased locking, etc). And, if you don't want to share state between threads, Java can do pretty clean actors/message passing (http://doc.akka.io/docs/akka/2.0/java/untyped-actors.html) or transactional variables (AtomicRefs are built in). Java concurrency does give you the ability to shoot yourself in the foot if you use it wrong, but so will any sufficiently powerful tool.
Re the JVMs support for FP:
- JVM7 added an InvokeDynamic instruction which I believe addresses your polymorphism concerns.
- It sucks that there isn't a bytecode instruction to allow TCO. But, in practice, many JVM languages will convert recursion to iteration at compile time with constructs like http://clojure.org/special_forms#Special%20Forms--(recur%20e...
- What do you mean by 'fast object allocation'? I'm not familiar with the term ... Creating objects is fairly fast in Java though. A quick test suggests I can alloc around 200 million objects per second on the heap once the code path is JIT'd on my laptop. Incidentally, it's surprisingly tricky to fool the JVMs escape analysis and force a heap (not stack) allocation, without introducing too much extra work in a microbenchmark ;-).
- AFAIK, you're right that closures require an object allocation - but how else would you do it? When I was writing Common Lisp, we had to avoid creating closures in tight loops for the same reason
You're factually wrong about the open-source thing: the primary impl of Java is open source (http://hg.openjdk.java.net/jdk7u/jdk7u). Sure, some impls like Azul might not be - but that's the joy of an Open language with a real spec, anyone can write an impl under any license they choose.
The claim that Objects have 'too much' overhead is subjective - but also basically wrong. Generally Objects in Java have 8 bytes of straight book-keeping overhead, plus padding to get the size of the fields to the nearest multiple of 8 bytes. That's expensive relative to C, but cheap compared to almost any other object oriented, GCd language (and can often be avoided via primitives, escape analysis, etc). For reference, CPython (the main Python impl) has ~30 bytes of overhead on an Int between tag bits, book keeping, etc last time I investigated.
How do you think the Java concurrency model is flawed? Almost any concurrency model I can think of, from Erlang-style message passing (see: Akka) to the new Fork/Join framework can be implemented in Java since its concurrency primitives are complete. I've even done basic impls of STM on AtomicRefs. Frankly, Java has one of the better defined and fine-grained concurrency models I know of. C++ just got a well-defined memory model in the '11 standard IIRC (vs '04 for the JVM).
I'm with you on the functional programming thing - syntax on anonymous inner classes and a lack of type inference make it way too verbose. But it's (largely) fixed via Project Lambda in Java 8. And, in the meantime, there are plenty of great JVM languages (Scala, Clojure, etc) with better support.
I read Cryptography Engineering (its successor) last year, and don't think I remember anything about that ...
I'm sure it discusses standard public key crypto, but it's a huge leap to go from that to a truly anonymous digital currency. Even with blind signatures it's really hard to prevent the 'bank' from maintaining an audit trail. My understanding is that even Bitcoin maintains an auditable transaction trail, so it's still not as good as cash.
PS: s/diety/deity/
PPS: I'd consider it bad form to use an affiliate amazon link there
I think you definitely should learn Go! I spent a few days using it when it first came out, and there are a lot of neat ideas that are worth learning about. I just can't think of a problem that would make me want to use it in production.
FWIW, the HN title was (incorrectly) 'Why I don't want to Learn Go'. I used that title for an unpublished first draft, but s/learn/use/ before making it public. Posterous seems to still be using the old (unpublished) title as the URL (http://arantaday.com/why-i-dont-want-to-learn-go), which is probably where the submitter got the wrong idea from.
I argue that makes a language with has a GC that you can't avoid (as far as I know, it's impossible to allocate an 'object' off-heap in Go) a fairly poor choice for much system level work.
Which means, if Go is to find a niche, it's got to be at a 'higher-level.' And that requires competing more directly against Java or Python - a much higher bar than trying to be better than C.
They've enforced style by mandating committers hook a linter into a git pre-commit hook, and compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part).
I can imagine that not working at Google-scale.
My point with this article is simply that, even if Go's GC catches up to the JVMs (which would be an amazing accomplishment in itself), it would still be too inefficient for serious systems work. I provided several real-world examples to that effect.
If you want benchmarks, check out the numbers from moving some of the critical allocations off heap (and out of the GCs reign) in the Java HBase project: http://www.slideshare.net/cloudera/hbase-hug-presentation