11ren

At least one of the links for a paper links to a GoogleTM search for it.

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

BTW: just noticed HN automatically adds a [scribd] link for a pdf. Convenience and cross-promotion in one. :-) (edit added pdf warning)

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.

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

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)?

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.

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?

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?

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.

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

1. That glow ground effect is pretty much what I was thinking, except, for the glow source to not be visible itself - you just see a mysterious glow from under the bike.

Easy enough to shade the sides (perhaps with a reflective surface, so as to not waste the light). Of course, being more visible makes it better - just doesn't look as cool (IMO).

But also, it doesn't give a sense of the space around the bike. That was the main idea I got from the original article, of a projected "lane" - it's not to make the bike more visible, but to display a cushion of space around it (a territory), so cars don't drive too close.

2. I meant it was illegal what I do (which is to ride between the parked cars and single lane of the road. Also a danger of a parked car's doors opening). I agree with your other points (esp route taken!)

1. That glow ground effect is pretty much what I was thinking, except, for the glow source to not be visible itself - you just see a mysterious glow from under the bike.

Easy enough to shade the sides (perhaps with a reflective surface, so as to not waste the light). Of course, being more visible makes it better - just doesn't look as cool (IMO).

But also, it doesn't give a sense of the space around the bike. That was the main idea I got from the original article, of a projected "lane" - it's not to make the bike more visible, but to display a cushion of space around it (a territory), so cars don't drive too close.

2. I meant it was illegal what I do (which is to ride between the parked cars and single lane of the road. Also a danger of a parked car's doors opening. I agree with your other points (esp route taken!)

I've used vi for 20 years now (gosh), and it's only in the last few weeks that I've actually started using it properly. One example is that I wanted to save in fewer keystrokes; like ZZ, but without quitting. I came up with this for my .vimrc:

  :map ZA <Esc>:w<CR>

I find the vim help very intimidating (with every possible feature and then some), but it turns out to be really simple to create your own commands. I also made ctrl-N go to the next file (ctrl-P for the previous file), because I do that a lot.

I just created a poll with karma of 196

I saw David in Florence, and I was amazed to see that they also had on display the prototypes for David. There were 3 or 4 or so. From memory, they were all massive blocks of marble, though some just had an arm or leg sticking out. I guess these are called "studies" or drafts. A bit more heavy-weight than a study for a painting.

If he could permit himself to start over several times, I can too.

OK, your empiricism beats my theorism.

Thinking of my own experience (I've ridden daily for a couple of years), the only two close-calls I've had are from a car that's in front of me, when it suddenly sees a parking spot, and swerves across, almost side-swiping me.

I could probably avoid this by riding in a full car lane, instead of to the left of it (between the lane and parking spaces), but it seems wasteful to take up a whole car lane (and I can't pass cars then). Also, what I'm doing may be illegal, as it's not marked as a bike lane.

(Bonus: fog/glow is more visible when raining.)

I find 40 hours is much more productive if spread over several weeks. Maybe one's unconscious works on it the rest of the time.

I love doing projects like this, but I tend to get ugly code, since I'm aiming at getting something working quickly (and experimenting with different approaches).

One barrier for me is that the cleanness of the code arguably doesn't matter in a project like this, so the time feels wasted. But, in reality, I'm creating sample code, that I do come back to later, to see how I did things. Like a personal text book. When the code is ugly and hard to follow, it is less useful as sample code. Thinking of it as sample code removes that barrier (that cleanness doesn't matter).

I've started to spend time cleaning up code, and uncluttering it, as I go - but I find it takes an extraordinary amount of time...

hey, that's really cool. I like your point that it's lateral visibility that matters. But I think in practice, the side of the bike is visible only for a very short time (as a car passes it), and the driver is looking forwards (not to the side). The bike needs to be visible from behind.

Another projection idea is a downward-facing rear light - perhaps angled so that the light reflected from the road hits the eyes of the drivers behind?

> The end result of this thinking is sloppy products that don't work, are hard to use, or are unreliable

But won't competition take care of that... if the market really does care about those metrics?

There's a counter-argument to multi-cores being the next IT revolution: although they seem to be the way to faster performance, faster performance isn't needed.

Data point one: the rise of the netbook. They have slower, single-core processors, and are fast enough for most of the mainstream stuff people want to do: web, email, word-processing. Netbooks are getting faster (and this is needed for some webapps e.g. that musical score webapp is a little sluggish on my eee PC). But what is more important in a netbook is weight and battery life - that is what is needed. Performance isn't needed.

Data point two: even in video games, the wii console is the most successful of the present batch. It is unusually low powered even for single-core (and in coincidence, one of its competitors, the PS3, is multi-core). Performance isn't needed.

Data point three (an exception): some applications do need performance (weather simulation; google server farms), but these are already multi-core, and have been for a long time (the core used to be in separate computers, but the app was multi-core).

I'm arguing that most of the mainstream market can't absorb faster performance (and the high-performance market has already solved the problem).

Ripe for Disruption?: It's common for whole industries to overshoot what is needed, in terms of the particular metric they have worked at improving for years. Their corporate organization, product development and marketing are based on improving that aspect, and selling that aspect. When the basis of competition shifts, you get a new set of leaders, because the old ones can't adapt.

With malleability, I think you're talking about low-level control, where you work directly in terms of the data structures that will be serialized as JSON. You might be translating between the domain data structures and the JSON structure; or they might appear direction as JSON. This is malleable in that you tweak it however you want; and it's simple in that you have direct access to everything. You can do validation in the same way. If something goes wrong, you have all the information available to deal with it as you see fit.

The wire format doesn't affect this approach - it could be JSON or XML. However, JSON and data structures maps cleanly, because it's an object format already. To do the same thing with XML requires an extra level, and you get a meta-format like xmlrpc, which is pretty ugly.

So I think you're talking about a kind of object serialization, with object-to-object data binding.

XML Schema is an attempt to factor out the grammar of the data structures, so that they can be checked automatically, and other grammar-based tasks can be automated. I think this is a worthy quest, succeed or fail. One specific failing we discussed was error messages.

I'm trying to grasp your point of view, and presenting what I think it is, so you tell me if I got it right or not (assuming you see this reply).

Incidentally, I was just parsing some XML Schema documents, and the error messages were more helpful than I expected - it gave the rule of the grammar that was causing problems. However, this rule looked like it was taken from the English specification of XML Schema, when it could be (and should be) automatically inferred from the machine readable version of the grammar (i.e. the XML Schema for XML Schema documents).

yeah, if you don't like it, change it (you could even put them on a USB stick or a server somewhere so you could install them on a new machine quickly). That one could change it honestly didn't occur to me til you said it.

There's the favourite DOS->unix:

  alias cd..="cd .."

yes! thanks,