11ren · HackerTrans

11ren

no profile record

Submissions

How to design a good API and why it matters, Joshua Bloch [pdf]

lcsd05.cs.tamu.edu

4 pointsby 11ren18 tahun yang lalu2 comments

OSDI ‘08: Corey, an operating system for many cores

hnr.dnsalias.net

2 pointsby 11ren18 tahun yang lalu0 comments

CES 2009: 3D video gaming to become a reality next month

tgdaily.com

1 pointsby 11ren18 tahun yang lalu0 comments

Great Depression Inventions (including Xerography)

images.businessweek.com

1 pointsby 11ren18 tahun yang lalu0 comments

A Better Way to Load a Plane

abcnews.go.com

78 pointsby 11ren18 tahun yang lalu58 comments

comments

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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.

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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.

18 tahun yang laludiscuss

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?

18 tahun yang laludiscuss

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?

18 tahun yang laludiscuss

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.

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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.

18 tahun yang laludiscuss

I just created a poll with karma of 196

18 tahun yang laludiscuss

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.

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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.

18 tahun yang laludiscuss

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

18 tahun yang laludiscuss

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?