10ren

Youtube is improving.

They have votes now. I've seen a few insightful comments there (it depends on what kind of video you're looking at, of course - you being the crucial word here.)

Thanks, I appreciate that and might do it, though I don't yet feel I have more than my write up of 2 months ago: http://news.ycombinator.com/item?id=1508379

Thanks! Domain knowledge - but applying this to a mass market feel a bit mind-bending to me.

Of course, it's still problems and knowledge, and so not qualitatively different from those in a specific niche. I guess the misleading thing is that by the time a mass market is mass, they are well-known (or appear to be). As an example, Youtube was once small. And while the consumers were perhaps (?) easy to understand, the producers (who created the value), were a much smaller group, a more specific kind of person, using specific new tech (mobile phones) with specific problems. And it only later grew into a mass market (though I guess arguably the producers are still "one kind of customer".)

Thanks! Interesting, a strong brand can be a negative.

Further thought: google video was 'better' in that it had higher resolution videos, and it displayed more of them on the screen at once. While youtube had one low resolution video. It was quicker to load and to run, and more suited to slower machines (perhaps especially mobile phones, whence videos oftentimes came?) Google video has always annoyed me in this sense. I note that now, they've increased youtube video resolution (it's 'better'), and also snipe: upgrade to a "modern" browser. Although understandable, it isn't the path to max adoption, and max. network effects

I'm trying to understand. I think youtube beating google was due to network effects: youtube had enough content that it was hard to displace (it was actually more valuable.) Secondarily, it had mindshare (people knew about it.) Possibly, they "understood user behavior and preferences" better (strlen mentioned this intriguing one), and they used this to make it easier to use (slightly more valuable + massively more adoptable.)

Relentless focus on the above factors (content, mindshare, usability) helped them win - have I missed any?

Can you elaborate on "understanding behavior and preferences" with some example behavior and preferences, please?

There are many bases of competitive advantage, but I don't have a clear picture of this one. The main customer-side advantage I see is that your product becomes identified with the idea/technology in the customer mind (perhaps of a tiny niche) - not that it's better than something else, just that it exists. But there's still a problem of getting to this state.

product -> platform -> library -> standard library -> language -> OS -> FPGA -> ASIC -> SoC

"Reaching critical mass" [so customers identify you with the technology/idea] is one way to avoid this.

I try to make rational, reality-based appraisal of the facts, the pros and cons. But this often takes the passion away, and recently I've been wondering if it really is the most intelligent approach.

If you want to find something worth building, get busy living.

The one that inspired the author: No. 7 in A major http://www.youtube.com/watch?v=2UTAmV54OWE

I like this experimental approach, it's like debugging, except you can also edit what inputs you accept. But is it actually accepted by mathematicians as an accurate description of what they do? http://en.wikipedia.org/wiki/Proofs_and_Refutations

Even Alonzo Church published work that was later shown to be logically inconsistent http://en.wikipedia.org/wiki/Lambda_calculus I came across

Good point, and rubbish-n-roadmaps is very apt (and google says it's original.)

But I did cover myself on this: if you do solve an unsolved problem, all is forgiven. Getting it out into a closed beta can tell you about a large miss earlier, with less investment, and less reputation risk. Of course, it would always be better to do everything right in the first place, if you can afford it. Rubbish-n-roadmaps is the worst approach except for the others.

He also co-authored the Java Language Specification (with James Gosling and Bill Joy.)

The wise are not dogmatic.

Steve Blank's idea (4 Steps) is that a roadmap enables you to ship a breathtakingly low quality product, because it is understood as the first installment in a bigger plan. Customers are really buying the vision, not the initial buggy, slow, undocumented, awkward, feature-missing piece of garbage you shipped in the first version (which is version 0.1, not 1.0)

But why are you shipping rubbish? It's part of getting going as quickly as possible, and iterating and learning. When real people start to use it for real tasks, you'll learn that the missing feature A that keeps you awake is not actually missed; but feature B that you didn't even think of is crucial. There are other advantages: if it truly is an unmet need, people will be so happy to solve some of it, that they won't care about the rest. water when you're dry etc. By shipping early, you'll also be building your market presence (for a new product, the first part of which isn't the quality of it, nor whether it works, but what is it).

The part about learning above is more crucial than you might think: knowledge of secondary user problems that no one else knows about (because they only become clear when people start using a solution) is a competitive advantage. The information is also precisely customized to your product, which makes it easier for you to absorb than for competitors with a different product and approach (which will have its own, slightly different, problems). You have a head start before other hear about these problems, and absorb them, so it's a time-limited competitive advantage. But in the meantime, you're learning the next thing.

The reason you're shipping rubbish is not because you aren't good enough to ship high quality; it's just that high-quality takes a lot longer. You need to have (or acquire) the ability to polish it - once you are sure you have something worth polishing. All that said, your product does need to do something useful; solve some problem (ideally that no one else solves; or no one else does it with some particular quality or tradeoff, that is valuable). It's crucial. With it you win; without it you lose. The quality and polish of other stuff is secondary.

The second section discusses SOAP/REST and XML/JSON, saying that XML Schema attempted to solve two problems (document formats + object wire format), but it predictably became too complex. He claims that we now use REST (not SOAP) and JSON (not XML), so the "impedance mismatch" problem is now solved.

Is this true?

JSON is used mainly where there is Javascript (ie. client side webpages - though that is becoming more and more inclusive these days... almost everything is a webapp (exceptions?)) - but it's schemaless (or typeless). While this is popular (eg key-value NoSQL stores, and dynamic typing in Ruby, Python, Perl), it's not right for everything. If you did want typed data, you'd probably just use XML Schema, since everything is already there.

I ask because of a startup idea based on XML Schema. It could survive XML Schema going away, but I'm not so sure about the apparent long-term trend away from schemas/types altogether. With fast-enough computers to nullify the speed advantage of static types, will the remaining advantage of type-safety be valuable enough on its own - What is the evidence for and against? Even databases are going schemaless (it seems).

If you're nearing or over 30, ask yourself: have you made any fundamental scientific discoveries, conquered any world-wide empires, or founded any major religions? Many are called but few are chosen. And many of the young think they can. But as Steve covers himself, o cynical one, those are the ones who do.

An appeal to youth's vanity, yes; yet also the absolute true.

And let's not forget that there are people at Apple who actually are changing the world, with the "lame" ipod, the doubted ipad, and (the associated) pixar. That adds credibility; and the branding is also of Apple's identity to itself, for passionate workers, and to attract talent.

Not really HN, but reminds me of the lyrics to sweet lullaby

    Young brother, young brother, be quiet
    You are crying, but our father has left us
    He has gone to the place of the dead
    To protect the living, to protect the orphan child

http://www.wherethehellismatt.com/faq.shtml#secondsong

I'm sorry; I didn't mean to dig a pitfall to entrap a helpful fellow traveler. When I noticed that a reading with the last two sentences as separable was misleading, I edited directly. I think the "sadly" part was communicated though, and I've tucked away your remarks for when I'm confronted by a multitasking OS. I think debugging the race conditions would be nightmarish.

Thanks, I appreciate the support, but my opps, you caught my initial phrasing before I clarified to disambiguate: I didn't mean to write an operating system; but to write one in Dijkstra's way (ie by showing - proving - that it works before you write it). ugghh I shudder just saying it.

This story inspired me tonight: reading about how he didn't know if it would work or not, and how he fixed bugs as they arose is true hacking style. And it's definitely a way to get things done. So that's what I did tonight, and made a ton of progress; just hounding down and stomping on bugs mercilessly.

Why wasn't I doing that already? I'd been reading too much Dijkstra, that the "competent" programmer can show whether his code will work or not. It's definitely possible to do it that way, but it's (very sadly) too high a standard for me to reach in reasonable time (or maybe at all), for more than toy problems. Dijkstra used this approach to write a multitasking operating system. I'm pretty sure I couldn't do that.

Oh man you reckon that's poor negotiation skills, wait til you check out this guy http://www.nucalc.com/Story/

EDIT found a video of Ron telling the story in person http://video.google.com/videoplay?docid=-7497796873809571567...

With inflation, that's only doubled: http://www.wolframalpha.com/input/?i=%24100%2C000+1984+%3D

You're right; but I think uprooting the persuasion from its source kills it. Steve didn't use that technique because it was persuasive; he used it because that's what he saw. After that calligraph class that connected so deeply, I bet he became aware of curved corners everywhere; and hated that computers rendered everything squarely... so when he saw fast curves, he grabbed it by the neck. When questioned, he probably spluttered "b-b-but look! all around you! can't you see?!" It's not a persuasion technique; but simply sharing the reality he saw.

Uproot it from reality and use it in isolation, and it has no life in it to persuade. Therefore: improve at seeing, not persuading.

(He'd have been more savvy at persuasion techniques if he'd complimented the poor guy first.)

emacs picture-mode would be handy, otherwise it's difficult to maintain fixed-width. In practice, I have a lot of trouble with it. I think huge maps (those 10x10 ones) could be a problem, simply due to size; paint programs have zoom as standard, and of course the natural size for a pixel is pixel-size. Though I'm certain emacs has arbitrary zoom-mode.

At least he was using a data-driven approach. There's a lot to be said for that (as opposed to coding it), provided you can find a good representation. As Brooks ~ said "show me your flowcharts and I will continue to be mystified; but show me your tables and all will be clear." He's talking about communicating it to another, but a (appropriate...) data-driven approach is also more flexible, simpler and easier to reason about, because it embodies an abstraction and isomorphism of the solution space. Of course, if it turns out insufficiently rich, you'll wish it was code (or at least that it can be supplemented with code.)

A way to implement these ideas reddit-style would be amazing.

Maybe a 2D reddit, so you can add (and vote on) evidence and hypotheses; and then also vote on each intersection (a choice of 5 levels of consistency). Not sure about nesting; would it mean sub-evidence/hyp, commentary, alternative expression, or related evidence/hyp. Perhaps users could work it out, in effect adding dynamic untyped fields, like twitter's @name, with voting for significance. Let the users decide! The UI would look messy, but collapsing fixes it.

To avoid group-think, you could do pseudo A/B-testing, with different votes. Though I don't think users would go for this - and when would the results become "official"? It becomes more stately (stateful); one of the beautiful simplicities of reddit is that the model types/components are constant.

Source code: http://www.mojang.com/compo/metagun/metagun-source.zip (linked from http://www.ludumdare.com/compo/ludum-dare-18/?action=preview...)

I compiled (yucky) with (after unzip + mkdir build):

    javac -cp build src/com/mojang/metagun/{entity,level,screen,}/*.java -d build/
    cp {src,build}/com/mojang/metagun/screen/exposition.txt 
    jar -cf app.jar -C build . -C res .

You need some html to run an applet; App.html just needs this:

    <applet code="com.mojang.metagun.Metagun" archive="app.jar" height="480" width="640"></applet>

Run with:

      appletviewer App.html

New to me (but probably standard to game writers) is: using a png to represent all the maps combined (like 10x10 maps), with each pixel's color representing a game tile type (eg. yellow for oil drum, purple for portal cube, red for spikes, green for signs etc). This representation is really cool, because it looks like what it represents (an isomorphism): you can "see" the level in a png editor, even though what you're seeing is not the actual level.

Another aspect of how the data representation drives the game, is that there are no explicit arcs between game screens - instead, the screen design allows your character to walk off-screen, then that point enables you to transition to the next screen. I guess it's the most obvious way to do it: it's as if you are zoomed into a particular section of the 10x10 maps, and then you can move to adjacent maps. Maybe it's just that I've spent too much time with nodes and arcs recently :-), expecting logical concepts to be explicitly specified, instead of implied by the design. Anyway, there is no sequential index to get to a particular screen; you have to follow the path. Or you can look at that png. eg, the final boss screen is at xLevel=3, yLevel=10 (you can initialize those values in GameScreen.java; and you need to change the player start location too, because now it's not derived from the previous screen: change the last two args in the following new Level line, from 0,0 to 10,10).

But if you have developed something truly ahead of the state-of-the-art, disclosing it gives your competitors a leg-up.

Another problem with patenting it is that it gets more expensive to maintain each year (there are increasing annual fees), so by the end, the total expense would be enormous; hard to justify if there is zero revenue coming in. [I'm going by Australian law here, assuming US is the same] Hmmm..... I wonder if this means that many patents "on the books" have actually expired for this reason, before the full 17/20 years?

IIRC pg has somewhere said that it would be in YC's interest for their startups to become massively profitable (and IPO or whatever), instead of getting bought out early. That is, YC's slice of $20 million is a fantastic outcome for YC... but a slice of $200 million etc would be even better.

This led into a discussion that YC's policy is to just do what is in the startup's interest - if they want an exit, then YC will support that. And after slaving your guts out, pretty soon $20 million in the hand is starting to look pretty dang good! pg mentioned that instead of trying to calculate exactly what is in YC's interest, with so many startups going, the simplest approach is just to do what's in the startup's interest. I think everyone - including pg and future candidates - also feel a lot more comfortable with this approach.

But I have to say: $20 million! That's freakin awesome! It's presumptuous of me, but I feel really proud of you guys. Go go go! And thanks also for posting a figure; that's usually secret.

I think swombat was definitely rude in his first comment calling it a "fart" and "trash". Name-calling is labeling, and is neither accurate nor helpful in a cognitive sense; and is abusive and disrespectful in a social sense; and it appears to be based on a strong personal emotion of anger, rather than an objective appraisal. It has no place in a civil and intellectual forum. But this is the internet. It's never been a civil and intellectual forum, including here, despite what many HN users would like. Even associate professors, when online, do it: http://news.ycombinator.com/item?id=1611007

The best we can do is to seek the grain of truth in what someone says, because they often do have a point, disregard the rest, and not fall into name-calling ourselves. It's just about impossible to stop someone from being rude; but we can stop ourselves from taking it personally. And the most effective way to do that is to fully accept any legitimate criticism they have, and totally discard the rest. The rudeness belongs to them, not to you, and you can bet it causes them all sorts of problem. One should therefore feel sympathy for person who has been rude (including oneself.)

That said, let me unpack what (I think) was meant: by "brain fart", he's upset about the writing itself, and that the ideas have not been thought out carefully. He sees it as carelessness, and is offended. Whereas I see it as a lack of ability, with English not being the authors' first language. But I agree that you and the other authors can improve on this - as he said "you can do better than this".

By "link-bait trash", I think he means that you have written this article for the purpose of getting hits, and not primarily out of interest in the content, nor for a wish to communicate it. From the article, and what you've said here, it does come across that way - but I find it very hard to judge, because of the language issue. Poor communication can lead to all sorts of problems!

He could have written these thoughts out objectively, without name-calling; as a result of not doing that, he has offended you. When a person feels attacked and offended, it is distracting for them, and makes it difficult for them to appreciate the actual content of the criticism (it even tends to pressure people to go against the criticism). Name-calling undermines one's purpose.

I hope the above makes it easier for you to accept the content, and disregard the insult.

You can begin by asking yourself what the purposes of the article were - was getting hits the primary purpose? It might not be "entirely true", but is it partly true? If so, admit it to yourself, and then you can move on. Having an objective and factual perspective makes you (largely) immune to insult.

(BTW: I have a more nuanced view of writing out algorithms. It's definitely useful at times, but it's not always the best one (not crucial or essential). A danger is that writing can concretize your conception of the problem (eg an incorrect assumption); whereas beginning to code can give you information. Have you ever gone to a lot of trouble to get clear on a problem, and then when you start to code it, you immediately realize that you misunderstood it, meaning that all that time was wasted? (and if you've become attached to that misunderstanding, you may fight the evidence, or not even see it, because not open to it). Writing algorithms definitely has its place, it's a mix.)

This space also enables you to time the lights, so you do less accelerating/decelerating, and increases your buffer for breaking, so driving is safer and less stressful.