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