Apple does not pay 30% on dollar transactions - they don't pay stripe-like processing fees. They are a high-volume seller with a great deal of negotiating leverage and financial savvy, they've been selling $1 digital goods since 2003. They probably pay some sort of per-transaction fee and percentage fees but it wouldn't add up to 30%. Take a look at the range of fees here -
You're not really stacking your long-run odds any more than you're stacking your odds by playing the lottery a lot. The odds are stacked in favour of anyone who submits a lot and submits early rather than in favour of someone who submits well.
I'm not sure what you mean by submitting "early", or what experience you're drawing on here (your account has submitted zero stories!), but am pretty sure that the odds favour a user who submits a lot that is good [1] and that the latter is where the emphasis should be. We're also working on systems to amplify this effect, so it is going to get more true with time. The point as far as karma goes is not to be attached to any one post, but rather to play for the long run.
1. What counts as good on HN: stories of intellectual substance that many good hackers would find interesting.
I guess I just found the response "submit more, it evens out in the end" a bit glib (as is, 'your account has submitted zero stories'). I do have some experience submitting stories as well as plenty of just reading and commenting on the site. It seems to me the current system amplifies negative tendencies like being 'first to post' or reposting variants of the same story.
I'm perfectly happy to take your word that you're working on something better.
It doesn't really say much about developer productivity. What are you comparing this to? You might also be forgetting the insane number of (many 'enterprise') products Netscape was trying to churn out at the time. See:
The browser alone with all of its extra doodads ran on three radically different platform families (Windows 95/NT, Mac OS, Several proprietary Unixes). And that's just the browser. Throw in running one of the top traffic sites at the time.
The internet advertising market which drives a lot of the revenue at many current similar startups was far smaller and less mature, as well. It's difficult to see how we can draw any sensible conclusion about developer productivity from all this.
There should be a "NSFW" equivalent for articles with potentially harmful levels of smug. (I've read a lot of articles by jwz over many years, and he is how he is, but still...)
This seems like an oddly reductive take, to me. It's possible to appreciate the pluck and ingenuity while being utterly dismayed by the lack of judgement and self-reflection. And this dismay need not come purely from some misplaced urge for opprobrium.
His broken moral compass and naive sense of entitled victimhood are preventing him from leveraging his talents to find the kind of work that he wants. You can easily be misguidedly "relentlessly resourceful". Just like you can be both fascinated and saddened to see it happen.
I agree with your first paragraph. It's not only possible to see multiple sides to this, it's sane. But you may have missed my point, which is that comments in the thread tended to take one side or the other.
Your second paragraph, I think, goes way too far. I don't believe you have nearly enough information to make that judgment. In fact, you can't have it, because it mostly depends on what the author learns (or doesn't learn) from his mistakes, which means it depends on the future.
On rescanning the thread, you probably right about the first bit.
And we are definitely reacting to each others' notions of how bothered one ought to be by his behaviour.
'Broken moral compass' may be a little harsh but I think you are perhaps swayed too far by the display of resourcefulness and the 'virtualness' and triviality of the setting. I'd see it differently if he were a 14 year old kid, figuring out how the world works. But he's an adult (with a spouse and a mortgage) who more or less tried to extort the developers of the mmorpg into giving him a job. This seems like sufficient information to conclude that he has rather poor ethical judgement or at least, a great deal of ethical obliviousness.
It reminds me a bit of a part of 'Reflections on Trusting Trust' that is rarely cited or recalled - open it up when you have a chance and re-read the last three paragraphs of the last section 'Moral'.
It's not really 'autonomous driving' so you might be overestimating the safety factor implied by the term 'autopilot'.
I'm not a car person or expert in the field but I've done a little bit of work on automotive systems. As the other responders pointed out these systems are designed to, ECC or not, do things like (at the slightest sign of inconsistency or error)
- reset and recover very quickly
- enter reduced functionality or failsafe modes
- fully disable themselves and anything that might cause you to rely on them
They're fundamentally built around the eventuality of them failing and with consideration of the things that need to happen when they fail. They don't usually rely on 'well, we'll just put in a somewhat more reliable component'.
Do you really believe the author of a paper explicitly about investigating the technical advantages of OO which also happens to touch on Haskell and ML is simply clueless about functional programming? And this ignoramus has somehow faked his way to the position of director of CMUs Software Engineering PhD program.
This seems like a stubbornly obtuse way to not engage in the paper's arguments.
Indeed; I have had the pleasure of having correspondence with Dr. Aldrich in the past. I had interest in implementing a static compiler for CMU's Plaid programming language, but found Go sufficient at the time. He also became involved with development of the Wyvern programming language. Nonetheless, he is well versed in programming language design and theory as that is his area of interest. It would be hard to imagine any related ignorance on his part.
Jonathan aldrich does come from the UW side of PL, which leans toward objects (a bias I share as well). But he knows his FP. Still, I'm not much for arguments by authority; either you see a proper comparison in the paper or not (I haven't looked closely enough). What both William and Jonathan both seem to miss, however, is more a discussion on object thinking, which I think would make the difference between OOP and fp more clear from a design perspective.
I don't think this is really an argument from authority since I'm not saying 'he's right because he has a PhD and teaches at a renowned university'. I'm saying that assuming he's ignorant of FP given both what he says in the paper and his background is silly and shallow.
It's not really fair to say that Aldrich 'misses' a discussion of object thinking, he just chooses to put the focus of that particular paper elsewhere - this is from the intro
Some of the advantages of object-oriented programming may be psychological in nature. For example, Schwill argues that “the object-oriented paradigm...is consistent with the natural way of human thinking” [28]. Such explanations may be important, but they are out of scope in this inquiry; I am instead in- terested in whether there might be significant technical advantages of object-oriented programming.
and
This success raises a natural question:
Why has object-oriented programming been successful in practice?
Everyone reads these papers from different perspectives, so it's quite easy to say someone missed something (fair or not).
My criticism is that an analysis of OOP is incomplete if you avoid looking at...objects. It's like saying, we are going to ignore the objects themselves, and just focus on the technical features of the objects to see what the technical advantage of these features are. It is very reductionist...while objects favor a more holistic manner of thinking.
We probably (broadly) agree more than disagree. One reason FP/OOP comparisons are difficult is that FP is closely related to a mathematical formalism while OOP isn't and can't be. I think the tack he's taking is 'can we explain the popularity of OOP in terms of "technical" or really, "practical programming/software engineering" advantages'. It's a tricky needle eye to thread.
The objection 'that approach can't lead to useful insight' is a reasonable one but I don't think he's taking the approach out of ignorance or because he spaced out on something while typing it up - it's a deliberate choice, whatever its merits.
Given the difference in both OOP and FP, I agree it certainly would be an interesting contrast to explore. Especially now, as FP is becoming more mainstream.
I really need to sit down and write that essay, but I always have better things to write and design essays are difficult to sell. A lot of the FP programming that goes on is just weak OOP with some immutability, closures, and list comprehensions. The real hardcore FP avoids not only mutation, but also aliases and identifiable objects. Object thinking is impossible in that context because nothing can have a name (beyond rolling your own GUIDs); it really is different.
> Do you really believe the author ... is simply clueless about functional programming?
I believe that his paper's descriptions of technical advantages of OO are not actually about OO, and instead are about FP and interfaces -- what he calls "service abstractions".
Notice this: when he describes ADTs, he glosses over their power; when he describes the evolution of object code, he glosses over the evolution of interfaces; when he describes messaging, he glosses over protocol endpoints.
IMHO his paper mostly glosses over all the actual technical advantages of OO vs. other approaches, namely OO state encapsulation, OO black boxing, OO inheritance, and OO composition.
He writes that the "key technical characteristic" of OOP is dynamic dispatch, and "is essential to supporting independent, interoperating extensions". OOP's key technical characteristic is not dynamic dispatch -- it's black boxing of data + state + methods. Moreover, dynamic dispatch is not essential to supporting extensions as he claims. To top it off, FP easily does dynamic dispatch by using higher level functions and type classes if you like.
I'm not. I'm not saying anything about the quality of his argument, I'm talking about the stridently poor quality of your initial one which boils down to 'he doesn't know what he's talking about'. I think that's trivially and factually refutable.
I do think what he's trying to argue is both interesting and difficult and I'm not sure I'm entirely convinced by it. It doesn't merit 'he's clueless' and saying that does a disservice to both the paper and the discussion here.
Your later, concrete objections are actual objections but I don't feel I've understood the paper well enough to engage in them. I'd only say I'm also unsure whether they're really about what the paper is about. The fact that many, in fact most, programming formalisms and paradigms are largely isomorphic is both well-understood and rarely a source of practical insight, which is the stated goal of the paper.
[I guess this is now also a reply to a post that was heavily edited while I was replying to it]
What you're describing is almost a definition of editorializing which you're asked not to do, in titles. The readers can figure it out themselves. Additionally you can comment on the thread yourself and point out parts you think are particularly salient.
It is uncharitable and I generally find your 'I flagged this' comments useful, despite being at odds with the holy guidelines.
But ignore the meaniepants bit - the commenter has a point - "I flagged, then I unflagged it [etc]" is unintentional drama-generating fluff. You could have just said "The title makes it sound like a purely political story but it's really a Mike Bostock thing and worth a read"
http://www.cardfellow.com/blog/credit-card-processing-fees/