8ren

I didn't see any ads, probably because of adblock. And given the nature of its conceit, I didn't expect an attribution. I just came across it and thought HN would appreciate it.

vapor, where?

aside: has anyone read a good discussion of Codd's original relational paper? http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.... Thanks!

I'm confused by his five example for "1.2.3. Access Path Dependence" (page.378), where an app would fail if the data representation changed, because I think an app using a relational store would also fail if the relations were organized differently. I can see some possible resolutions, but the paper doesn't address the issue...

I concede that it's hard to assess a proposed approach when it doesn't actually exist yet; but I think that if you raise an issue with the existing approaches in a paper, it's reasonable to also assess your own proposal with respect to that issue.

e.g. maybe he imagined automatic views to convert the underlying relations (so that different relations are identical if they represent the same information...); or a manual conversion layer with views (but the same could be done for the other store!); or maybe he was only thinking of different physical representations when he wrote that part and it didn't occur to him that different relations also might be used

EDIT http://www.aisintl.com/case/library/Date_Birth%20of%20the%20...

I think he's saying that while the relational model has the same problem of retaining compatibility for old apps when it evolves, it this is * easier * to do this with the relational model. ie. the "number of access paths" for old apps becomes "excessively large" for non-relational models. He talks a bit about the complexity of representing different queries later on, but somewhat obliquely and doesn't draw the connection (and I don't quite follow what he means in the second last paragraph of section 1.5, where he mentions n!, 2n-1 and n+1 - I understand it so little, that I think there might be a typo).

Ah! He seems to have addressed it more directly in a previous, less-cited IBM-only paper from 1969... to which I happen to have a link right here: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.173.5...

No, just referencing a well-known event; but it seems you're right that he's not teaching that course any more http://news.ycombinator.com/item?id=531490

However, he did say that starting off with python makes an undergraduate’s initial experiences maximally productive in the current environment. http://cemerick.com/2009/03/24/why-mit-now-uses-python-inste...

fun fact: norvig switched to python (for his textbook) http://news.ycombinator.com/item?id=1803815

It's horses for courses (or ophidia for courses in this case).

I don't know if business people do a lot of scripting (if any) in spreadsheets, because it side-steps the ease-of-use GUI of spreadsheet in favour of a programmer's UI...

Is it really true that business people use R directly? Being in Forbes is consistent with it...

I recall that SQL was intended to be used by business people... and it probably has been, sometimes; but I don't think it happens much. The days of early adoption might have differed, through appealing to the more adventurous business people (as R might be now).

One thing I know for a fact: business people use spreadsheets. I think making something that easy to get things done in is an incredible achievement. As an example, I think PHP has approached but not attained it.

Language you think in is constraining... unless your language is the best that could ever exist. Of course, if you can only think in it, you couldn't imagine anything better.

Mathematical notation might be a better language to think in than any programming language; but even that is constraining - since mathematicians are constantly inventing new notation, and many mathematicians think in pictures or even... intuition.

Of course, he really meant for coding; I just wanted to note the bigger picture.

And Sussman switched to python. Religious wars are for followers, not Creators.

I've started trying to narrow the scope of features required for launch, where the minimum set of features is not with respect to the full set I want, nor with what customers might need, nor what will differentiate me from competitors - but the minimum set that would make it have some use, to some customers.

It doesn't matter if other products are more useful; nor if that minimum set expresses the really cool goal I have, or the essence of my approach. Just that it be some use to some one.

I think of this a little bit like a strategy for proving theorems: if you haven't got time to prove the thing you are aiming at, but you need to publish something, you can always restrict your assumptions and goal to what you can manage, and prove that. Now you have a base you can build on.

everything > something; but something > nothing

That link suggests "the beginning of the end" is from Shakespeare - do you know which work? I only know it from Churchill, and assumed it was his.

9. prozvonit is to prank, in slang I've heard & used here in Australia.

bonus: tingo - "to borrow things from a friend's house, one by one, until there is nothing left" in Pascuense language of Easter Island http://en.wikipedia.org/wiki/Adam_Jacot_de_Boinod#Career

  Whatever you can do, or dream you can, begin it.
  Boldness has genius, power, and magic in it!

I think he covers this in his last paragraph: If you are betting on emerging trends it is better to keep your burn low and runway long.

Yes, the harder I work, the luckier I get. I think of a startup as a game with a 1-in-10 chance - but you can play as often as you like. The odds of failing n times in a row is .9^n - so the odds improve fast. And of course hopefully you'll learn something general along the way to improve your odds, and leverage specific money/tech/contacts/market presence too. If you're persistent, failing begins to look extremely unlikely.

What can stop you (apart from giving up) is if you can't (or won't) learn some key thing, or can't (or won't) do some key thing. Which is why having mentors/colleagues is very helpful (for learning); and having co-founders and being able to employ/outsource/team-work is very helpful (for doing).

We currently have two Zones in Manchester, UK - we plan to launch additional regions in separate geographical locations throughout Europe and the US in due course. http://beta.brightbox.com/beta#faqs

The Innovator's Dilemma is full of inspirational stories of markets discovered retrospectively. An example off the top of my head is honda motorcycles being used as off-road recreational vehicles - this market was discovered by a sales rep observing customers doing it. This could only be apparent some time after the product was created, and sold.

Another is Xerography being rejected by IBM after careful (and accurate) market assessments. The market significance only appeared after Xerography was actually in use. (from The Billions that Nobody Wanted.)

So when pundits (not cdixon) tell you it's impossible to discover a market retrospectively, they are simply wrong. But they're right that it's risky; and that it's much safer to launch with buyers waiting (of course!). I think the key take-home is that: a business needs customers. (Sounds obvious? Yet it's a perennial downfall of engineer-lead startups.) Finding customers (aka marketing) is at least as much work as creating the product in the first place. To put it in perspective: if creating the product takes a few prototypes over a few months or years, it's probably reasonable to put comparable effort into marketing: a few markets and 4 P's over a few months or years. The danger is when you exhaust yourself engineering it, and collapse at the finish line - just when the second marathon starts, of marketing it. (of course it's even better to run both marathons simultaneously... to torture the metaphor).

I like the idea of Zones on different continents.

Not only can this provide faster responses for each continent, but it also enables peak times in one time-zone to be supplemented by resources in off-peak time-zones. Though I guess the latter is true of any cloud infrastructure, even if centralized.

IMHO the difficult part is seeing the commonality of those edge cases. That requires firstly knowing about the edge cases, and secondly seeing the problem (the commonality of those cases). The final step is a solution, which is where the maths comes in (or might).

Anecdotally, it seems fairly common that maths is independently re-invented by people applying it - famously for relativity, IIRC. That's because the maths guys don't actually know about the applications.

It's a truism for our industry that if a new approach really is significantly better (eg. x10) in practice, it will be adopted. You don't need to convince people; you just beat them. OTOH, there's a common wish to over-automate: to spend a week saving a second, and then it turns out to not handle the very next case. So, some people don't like to use frameworks because they are too constricting (don't handle all the cases in practice); and some (Alan Kay) even say if you can build your own infrastructure, you should.

Mathematical ideas usually only work on their own assumptions - a difficult part is matching those assumptions to an application. Though maybe this isn't a problem for the generics example.

There's also incidental practical issues, like the need to ship, then of back-compatibility, resulting in a current Java implementation that can't express List<Circle|Rect> (you need an explicit Shape interface/superclass). Although *ML has proper algebraic data types, does C# do it properly? I don't know.

Text-only version of cache (Full version also isn't loading) http://webcache.googleusercontent.com/search?q=cache:16XHnrP...

It is by logic we prove, it is by intuition that we invent. - Henri Poincaré

That makes sense, but people really like to see a future before investing (money or sweat).

Sun's revenue came from workstations, which got disrupted by PCs. Everything else drove that.

Still worth reading the book.

The crucial point isn't that it's a technology disruption, but a business disruption, in the sense that (1) customers of the new technology have different needs (or ranking of needs); (2) vendors of the new technology need to supply it in different ways.

One example from the book, on disk drives, is that in moving to smaller disk drives that were more popular in laptops, (1) for customers who valued small physical size and mechanical robustness over storage size and cost per MB; (2) the manufacturers of which came out with new models twice as quickly as the previous size (incumbent organizations found it difficult to change all their internal procedures to adapt to this new rhythm, new sales channels, new customer demographic - everything changes, both "build something" and "that people want", not just the tech).

Because it's not a technology problem, but a business problem, the proposed solution is not a separate tech lab, but a separate business unit - one that can be happy with tiny sales, and that can be organized by the needs, ranking of needs, and rhythms of the new market.

[It seems to me that sadly, this amounts to a startup, which the incumbent owns; this will save them financially, but won't save their organization.]

A current example is ARM CPUs in smartphones, which appear to have disrupted intel x86 architecture. But I hesitate to count intel out - they've been around the disruption cycle a few times (having invented the microprocessor and integrated circuit).

OK... I'll just note that that's not a specific criticism of CatB.

I found CatB extremely useful. I've heard a lot of hate for esr's work, and I'm curious about it. Perhaps it's just backlash, from his previous very high popularity.

So, could you elaborate with specific criticisms of CatB?

Great article! Some asides on MVP, inspired by this line:

[Marketing is] everything- product, price, placement, and promotion. Start thinking about these things before you launch, learn from them, and iterate quickly before wasting a lot of time and money.

Since "product" is part of "marketing", it would be nice to include it in the iterative cycle. Instead of working it out before launch, launch prematurely, and work out the product simultaneously with the rest of the marketing. That is, "release early, release often", and iterate the whole thing. This helps for those products that you didn't know you needed until you saw it. It worked for me for a software library; I haven't tried it with an application.

Reflection: the idea of "assessing the market first" is waterfall-style, even though it is agile-style within that stage. The idea of "pivoting" attempts to incorporate an iteration, but at a much longer time-scale. It would seem better to be even more agile, by assessing the market with the product within each iteration, and pivoting within each iteration. This would need instant prototyping; and rapid feature changes (for pivots). One obstacle is that software takes too long to build, and too long to adapt. Consider: if you could make a prototype as easily and as quickly as a webpage to gather email addresses, wouldn't it be better to do that? If you could create different feature sets that would appeal to different markets as quickly and easily as making different landing pages, wouldn't that be better? Like "A/B testing for products".

Sounds like a hacker-philosopher's stone? While we can't eliminate essential complexity, only accidental complexity (by Brooks) and so it's hard to make much progress in this for general programming, for the subset of programming which is SaaS websites, we have already made great progress, with frameworks, RoR, AppEngine etc. It could be made much easier, if we focussed on the goal of an initial prototype, where bugs and lack of features don't matter, provided you get feedback on them (eg: have a "search for help" facility, and store the searches). Then, you can iterate and change direction quickly. The task is to seek traction. You don't need to hit it perfectly (like the iPhone), but just to get a nibble, and then you adjust. At first, you just want to know where the fish are.

Of course, product features are only part of marketing, and you also need to iterate quickly on graphic design, copywriting, adwords and so on. And pivoting may be intrinsically slow, because it takes time for your message to diffuse, be trialled, be adopted, word of mouth etc - though twitter, facebook etc may also speed this up too.

Oracle owns Java. They will attempt to turn it into a profit center. The Google suit is one example. Another way is to make their database/s and products perform better, by integrating them more tightly with Oracle's version of Java (which includes BEA System's version) - analogously to MS making Office apps perform better under Windows.

Sure, it's against the concept of a public spec, and OpenJDK; and it might not work, or at worst fragment the Java standard and destroy much of its value - but I can't see how Oracle could help themselves from doing this. It's inevitable.

Not exactly: many languages are open; my focus was on the ease/speed tradeoff.

Haskell and the ml family only have ease-of-use for people who think higher order predicate calculi have ease-of-use - some of whom will vigorously argue that everyone should find them easy-to-use.

(I don't know enough scala to form a judgment, but I haven't heard it being touted as primarily having ease-of-use, in contrast to Python and Ruby.)

Java is Oracle stack, C# is MS stack, objective-C is Apple stack.

Is there an opportunity for an open language with similar VM ease-of-use/performance tradeoffs - or is hardware now fast enough for the ease/speed of dynamic languages to fill that gap (Python, Ruby, Javascript, ...)?

"Do the simplest thing that could possibly work" - then move on to the next thing. This is going to be painful for you to not stay to "perfect" it (it will take some courage) but bear in mind the following:

It's surprising how often the extra bits you were worried about turn out to not actually occur, once you've learnt more from the initial version, you've understood it better and therefore designed a better approach.

The first version is to understand the problem. The next version (a rewrite) is to understand the solution. Call them "exploratory drafts" if you like.