frognibble

The goal of this trick is to reduce the memory required when the argument to the count function is a lazy sequence. When iterating through a lazy sequence, the items in the sequence are realized and retained by the sequence.

The code clears the stack slot for the count method argument. If the object referenced by the argument is not referenced elsewhere, then the object is eligible for gc during the execution of the count method. In the case where the argument is a lazy sequence, this changes the memory requirement from the entire realized sequence to a single item in the sequence.

This trick is employed everywhere in the Clojure implementation where a lazy sequence might be retained. It's not specific to the count function.

Because Servlet 3.0 does not dictate how an application suspends or resumes request handling, I wouldn't say that Servlet 3.0 introduces event based request handling (other than the first invocation of the handler as in Servlet 1.0).

I guess one can claim that any suspend and resume logic in the application is a form of eventing, but it's different from node.js in that it's not pervasive through the application. It's also different from node.js in that the server infrastructure is not involved in the "events".

Threaded does not imply one thread per connection. As an example, Java Servlet 3.0 allows a request handler to suspend and resume execution of a request handler on a thread. This feature allows the application to relinquish the thread for the occasional long operation and use blocking threaded code for most other code. Threaded applications written in this style can support a large number of concurrent connections with modest resource use and no callback spaghetti.

Models like Java Servlet 3.0 allow threaded servers to handle a large number of concurrent connections. Are there other reasons why threaded servlets are slow or not scalable?

Most web applications don't have a large number of concurrent connections because they application request handlers do not block for a long time. The resource use for thread stacks is very modest for these applications even without a suspend & resume feature.

I keep hearing assertions that threaded can be slow or does not scale. Can somebody describe the reasons here or point to a good document on the subject?

I often see "scalable" and "fast" used interchangeably in these discussions. These are different concepts. Is the contention that threading is not as scalable as evented, not as fast as evented, or both?

Here's the previous discussion on Paul Tyma's presentation: http://news.ycombinator.com/item?id=1546711

The code handles concurrency the same way that redis handles concurrency. It's single threaded.

Javascript might not even be the best language for the browser. The browser programming model was set in stone years before significant applications were built in the browser. If we had a choice about the browser programming model, then it seems likely that better programming models would have emerged based on the experience.

F.lux adjusts the color of your computer's monitor to match the time of day. It's warm at night and like sunlight during the day.

I've been using F.lux for a couple of months on OS X. The orange color at night looked a odd to me at first, but now I don't notice it.

F.lux can help you sleep better: http://www.stereopsis.com/flux/research.html

I'd like to see the code used in the benchmarks before drawing conclusions from this work. Programming Java NIO is tricky. It's possible to make some mistakes and still have things "work". One example mistake is setting the write op on the selection key when there's nothing to write on the socket channel. This bug will cause the typical select loop to consume 100% of a core. The code stil works, but is much slower.

I think it depends on what you are doing. If the app has a single logical thread of execution, then sequential code is easier to understand than a series of callbacks. If the app executes steps in parallel with forks and joins, then a state machine implemented with callbacks can be easier to understand.

The typical web app falls in to the former category: validate input, read from cache, maybe read from database, maybe write to database, generate response.

I suspect that Google used email addresses because they already have tools for managing that namespace.

Perhaps you meant to say that the framework used in this example is not ready. I didn't see anything about Clojure the language that makes the example complicated.

As far as the framework is concerned, the example shows how to build a production deployment of the application. The author is not showing a toy teaser application. There are a lot of details there, but these are things that you would want to know if you actually want to run a production server.

The email address is not displayed on the profile page.

A user can customize his or her profile URL with an email address. The settings page clearly states that the email address is publicly discoverable if the email address is used in the profile URL.

There are a few usable libraries for building web apps in Clojure (Compojure is an example). These libraries are not as comprehensive as libraries in other languages and the communities are small as you noted. That said, I wouldn't describe the experience as painful. Some of the libraries are pleasant to use.

I agree with your comment regarding Clojure's concurrency constructs. I am building my web app to run on more than one machine. I have not yet had a need to use any of the concurrency constructs.

It looks like it has all the basic photo editing features in addition to the gimmicky features like stickers. It seems useful to me if you don't have Photoshop (and you are using Picasaweb).

This is exactly how I work with Clojure. Emacs is not required to develop in Clojure.

The LAME MP3 encoder uses technology covered by patents. The LAME developers distribute the code in source code form only. The developers say that it is legal to distribute the code because the source code is a description of the patent and not a working implementation of the patent. See last question at http://lame.sourceforge.net/tech-FAQ.txt for more info.

You don't need special db adapters for Tornado. Idiomatic Tornado apps only use async when blocking on an external event (fetching a page from other site, waiting for another user to do something). Db and file system blocking is handled by running more instances of the Tornado application.

Here's an earlier thread on the topic: http://news.ycombinator.com/item?id=1485947

I think the awards are designed to keep people from leaving for startups, not to motivate people to do better work.

Once an employee has a certain amount of financial security and a track record of making things happen (traits shared by a number of Google employees), the employee might be motivated to leave for a startup where there is an opportunity for a big payday. The Google awards provide an opportunity for a big payday while staying at Google.

Pastafarian, so I voted nonreligous.

Tornado achieves concurrency using async network IO and multiple instances per core.

What are the limitations described by Mandelbrot? Does Mandelbrot show that active investing produces better returns than passive investing?

I recommend that you read the book "A Random Walk Down Wallstreet" before you invest in individual stocks. The book argues that you will be better off investing in broad index funds.

nginx

re 1: Bret Taylor addressed db queries in the video on Tornado (the video is on Facebook, but I cannot find the link). If you run more than one instance of Tornado per core and you have a decent load balancer in front of the instances, then short blocking calls to the db work just fine. If your db calls are taking a long time, then it might be better to speed up the queries with caching or query optimization before worrying about async.

I like this approach because I prefer writing app logic in a straight line instead of in callbacks. The code is easier to understand and debug.

For those tuning in recently, the original title of this post was "Posterous Hypocrisy".

The hacker Bret Taylor and his team created a way to output all of a user's data in JSON format: http://developers.facebook.com/docs/api

The problem is that many Java libraries feel over-designed compared to similar libraries for other languages. Java is the only place where you will find a class like FrogNibbleAdapterFactoryFactory :)

I also had trouble getting started with Clojure because I was distracted by the official getting started documentation. I had smooth sailing once I decided to develop Clojure code the same way I develop Python code:

- Edit code in plain Vim.

- Run Clojure from the command line.

I have a single directory where I download the appropriate jars. I ignore Ant, Maven, Leiningen and all that other fancy stuff.