It's a great piece, this little gem is the reason why I posted it:
"If you start a startup, don't design your product to please VCs or potential acquirers. Design your product to please the users. If you win the users, everything else will follow. And if you don't, no one will care how comfortingly orthodox your technology choices were."
The trouble with that, of course, is that even though tipjoy pleased users they just didn't have enough of them or enough transaction volume since the market wasn't ready.
What does one do in that case? Keep going (bleeding money) or give up? Lots of startup ideas are so bold that they're clearly early for their time.
I think tipjoys major problem was simply not being integrated in the platforms they were targeting, not that they did not please their users enough. You have to go through all the gates to score, not a subset of them.
And not having enough users is just as much a reason for failure as having dissatisfied ones.
The market is ready alright, it's just that as a third party add on offering a payment service you have to cross one more hurdle.
I'm pretty sure if the tipjoy principle would be implemented from within the network that it would be an instant smash hit.
Because of another thread I looked at PGs list of essays and the title of this one caught my eye, reading it about 2/3rds through I read that bit and thought it more than worth posting, it is very relevant.
Too many startup start out trying to be the perfect bride instead of simply focusing on their users and making a great product. VC capital and other 'good stuff' is so far down the line when you set out that you do not need to spend an ounce of thought on it.
Concentrate on your users, that's where they key to any kind of success is. Once you've done that, no matter how exotic your tech choices were you're halfway there. Better to go off the beaten path and make a stellar product than to end up in mediocrity for playing it safe.
EDIT: parent has been edited, this reply now makes little sense.
Bah. I almost wish this place didn't have points, or at least didn't have them so visible. Just knowing they exist weighs on me, and discourages me from saying what I really think, towards what would be popular. I can't help it.
I know... it's my strong belief that karma works best 'behind the scenes'. Even if the system in general would remain it would be nicer to disable the visible points next to each item & article header.
I wonder if the poster really would feel better with nickb's user id, after all he wouldn't actually be nickb...
More to the point, why would he want to be? What is the actual value of HN karma, outside the confines of one's head? I know none of my friends could care less - in fact they'd probably call me an idiot for spending so much time here. And I would like to think HN members resist judging each other by their karma; except in extreme cases the text should stand by itself.
Still, the system does seem to work(1). Perhaps this eternal fight with the inner "karma farmer" demon is the price we have to pay for effective group moderation.
(1) Unfortunately, there is only one data point, insufficient to form any firm conclusions
I'm not much of a programmer yet, and a lot of the C bashing I read complains about pointers and how necessary they are in C, yet according to this:
"Dynamic typing. In Lisp, all variables are effectively pointers. Values are what have types, not variables, and assigning or binding variables means copying pointers, not what they point to."
They are even more fundamental to LISP. Also if dynamic typing is good and most posts seem to claim it is, and dynamic typing more or less equals pointers which is what this seems to be saying, doesn't that mean using pointers is good? Also, I have seen frequent complaints about C's "static typing", but if using pointers results in dynamic typing, doesn't that suggest that static or dynamic typing is a stylistic choice in C programming?
In this case it's more that ignorance is blindness. That syntax is a feature. The fact that Lisp code is expressed in Lisp data structures makes it easy to write programs that write programs.
Even not as a real lisp guy that's one of the things that I appreciate about lisp and the only time that I've done anything particularly powerful with it: the fact that it's basically a parse tree makes it really interesting for genetic programming.
It seems that the fact that Lisp is a parse tree is what makes it a limiting case. That is, if there's only one canonical structure for representing programs, and Lisp makes it explicit, then any other language that makes it explicit is going to be isomorphic to Lisp.
I'd like to know, though: is that true? Is an abstract syntax tree the only good way to represent programs as data? Has any other expressive way to do this been invented, or do programs always boil down to an AST after the syntax has been stripped away?
I say "expressive" because I can think of at least one other code-as-data representation: binary. But that isn't suitable for programming. If there is another representation that is suitable, but isn't isomorphic to a parse tree, then presumably one could derive from it an analog to Lisp that doesn't simply reduce to Lisp. Until then, though, I think the point that PG made semi-jokingly in the essay, that any language as powerful as Lisp will be a variant of Lisp, has to hold true.
Some day I'd like to research this question (or better, someone on HN could just tell me the answer). If other meaningful representations are possible, surely some must have been invented by now. And if they aren't, then the AST is a considerably more remarkable discovery than people realize.
I don't think that a parse tree is intrinsic -- it's just something that maps well to the languages that we actually use: of course you could translate everything to a turing machine's tape, but that wouldn't be particularly useful.
What would really interest me would be exploring that if human logic fundamentally reduces to a parse tree because of something to do with the language faculty of the mind, and the programming languages that we create tend towards that just because programming languages are built out of the same logical faculty.
Yeah, that's the point. Other representations are possible (binary), but only one has proven suitable for programming. This is presumably because of the way the human mind works. It would be remarkable if it were the only good representation for this. It would also be the reason why Lisp is the limiting case among programming languages, at least when it comes to metaprogramming. But I repeat myself :)
Sure, trees are powerful no matter how you delimit them. Most Lisp hackers would be fine with using {}, [], or <> if they had to. What Lisp hackers like is programming in lists, not parens per se.
I don't see what you're trying to claim. Initially you seemed to be saying that you preferred conventional sytax to sexprs. I pointed out that this meant you had to give up macros. You reply that you could use other characters to delimit sexprs. Sure, but so what?
You're assuming your conclusion: that the languages are equivalent in power and differ only in syntax. If that were true, then sure, one would simply make an arbitrary choice based on taste. But it isn't true. It's profoundly untrue.
The syntax in that first example you quote isn't arbitrary. It's essentially the only notation that exists for representing the structure of a program explicitly in language. Is that valuable? Uh, yeah. It's incredibly valuable. It's worth a lot more than syntax in many cases.
By contrast, the syntax in the second example is arbitrary: the delimiters and operators could just as easily be organized differently. Perhaps this particular organization makes certain programs clearer, but it loses the ability to represent programs in general.
If that doesn't make sense, think of the fairy tale of the goose that lays golden eggs. Everybody's obsessed with their particular golden egg. Lisp - precisely because of the difference visible in those two examples - is the goose.
There's nothing in this that PG didn't already express in his comment. But what you wrote deserves more than one protest :)
That Python code shouldn't work. It needs a 'return', assignments aren't expressions, and assigning to a nonlocal variable in the absence of a declaration just creates a local. (Might be nice if Python did look more like that, though!)
"If you start a startup, don't design your product to please VCs or potential acquirers. Design your product to please the users. If you win the users, everything else will follow. And if you don't, no one will care how comfortingly orthodox your technology choices were."
at about 2/3rd into the essay.