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.
588 karma · joined September 29, 2010
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...
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 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.
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.
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
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!
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).
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.
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.
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).
So, could you elaborate with specific criticisms of CatB?
[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.
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.
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.)
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, ...)?
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.