Recent submissions

Comment · 18 years ago
At least one of the links for a paper links to a GoogleTM search for it.
Comment · 18 years ago
I think the design issues for APIs, DSLs and languages are very similar.

For adoption, the learning curve is very important, and the beginning of this curve is sensible defaults (like Python and Rails), so you can make the common tasks happen fast, while having the power to also do the complex low-level fine-tuning that is less common (and not the first thing you do). There's a learning curve (per user), but also a building curve (per project).

However, common is an attribute of usage, and not intrinsic to the API. You need a lot of users before you know what is common. And, over time, as the world changes, the common tasks change (eg. there are many different internet protocols, but http turned out to be most common).

Comment · 18 years ago
BTW: just noticed HN automatically adds a [scribd] link for a pdf. Convenience and cross-promotion in one. :-) (edit added pdf warning)
Comment · 18 years ago
That is good to hear. It seems that quality (perfection?) is secondary to actually building stuff, making mistakes, improving it, learning. As said in your essay, determination is more important than intelligence. Though "an incurable tendency to build stuff" sounds less depressing.
Comment · 18 years ago
I agree with your points, though I keep coming across variants of rapid prototyping in different fields; and as Fred Brooks told us "build one to throw away".

Is it possible to have a "clear but poorly-defined goal", or are you having a joke? "Fun" is an emergent property - recognizable, measurable but the creation isn't formalizable (though BTW your link mentioned something about game grammars...)

Comment · 18 years ago
I'm curious, what do you mean by "transparently persistent"? Do you mean that you can serialize anything (and so persist it as a file or what have you)?
Comment · 18 years ago
I came across this http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_a... which seems to confirm progn ~ do

I'm just surprised that (it seems) you can do statement-based code in lisp. I thought it all had to be expressions. This feels like cheating. BTW: I can see that progn/do syntactically produce expressions, but the value of all but the last one are thrown away - similar to python in that respect. This seems against the spirit of expressions.

Comment · 18 years ago
I think the layout similarity was an issue; but it seems to me that they just have demonstrated a barrier to entry (a non-product one).

For a product company, 37Signals does a lot of blogging, conferences, a book and so on. I think the guys are good at this, and they really enjoy it. It makes me think that, in a way, 37SIgnals is really an educational/PR company, that happens to make money from their software. If you want something like what they make, you'll need to pay someone to host it - why not them, since they are nice guys?

Comment · 18 years ago
Another Java-style construct: Clojure has a do form, which enables you to consecutively execute the following expressions in the list.

It seems to me a way to sneak statements into the language. Or does lisp have something like that as well?

Comment · 18 years ago
I've calculated this too (the same round numbers too: 10%, 10 years).

He doesn't mention that you might learn something from each attempt (if you stay in the same industry).

I think your success is (virtually) inevitable - unless there's something that you must learn that you won't learn.

Comment · 18 years ago
> probably the best large organization for a real , cs focused, software engineer

Makes sense, it's the only multi-billion dollar business based on an algorithm.

Patent-based businesses seem to encourage fundamental technical research. Consider: Bell Labs (Alexander Graham Bell's telegraphy patent); PARC (Xerography patent); IBM research (many patents).

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton