akeefer

For many novice developers, web development imposes its own barriers to entry. First of all, you need some server somewhere, which means you need to know something about servers, maybe have some sysadmin skills, and likely that you'll have to make some sort of ongoing cash outlay for it. Secondly, if you want to get paid you need to figure out how to process payments, or at the very least what ad network you want to attempt to embed.

On the dead simple end where you just want essentially a blog with ads, it's easy. On the not-so-simple end, where you want to build an application you can charge money for, the app store model is very straightforward. You don't have to make any decisions about servers or hosts, do any sysadmin work, worry about traffic spikes and scalability, and your cash outlays (aside from development time) are all upfront and totally predictable. Similarly, payment processing is already there and handled for you. And lastly, you don't have to worry about SEO or distribution channels because you don't have a choice in the matter.

It's easier to put up a web page somewhere than to build an app for the app store . . . but for a large number of people building an app for the app store is much simpler than putting up a web application. And that, I think, is a big reason why the app store exploded.

But if the heavy users of their services are costing them more than they're making, and generally degrading the quality of the service, that argument doesn't really hold up. I'm going to assume that, like most similar business models (including gym memberships and all-you-can eat buffets), AT&T relies on light data users paying for more than they use in order to subsidize heavier data users that use more than they pay for. Encouraging people to become heavy users that are an overall cost to the business so that they stick around longer would seem like the classic "we lose money on each one, but we make it up in volume" sort of mistake.

It would be like encouraging people to eat more when they go to an all-you-can-eat buffet by giving them doggy bags to take home as much as they want, on the theory that then they're more likely to come back. If you're losing money on those people you don't really want them to come back.

It's obviously an open question as to exactly what their costs per user are for light versus heavy users of data, but I'm going to infer from their recent actions that they've decided that at the moment supporting heavy users of data isn't such a great business to be in.

My understanding is that many of them fled following the Cuban Revolution and subsequent nationalization of property; the ones who were in Cuba at the time are likely either very old or dead by now, but presumably their descendants still harbor resentment over it. From the associated Wikipedia article:

"Cuba began expropriating land and private property under the auspices of the Agrarian Reform law of May 1959. Cuban lawyer Mario Lazo writes that farms of any size could be and were seized by the government. Land, businesses, and companies owned by upper and middle class Cubans were also nationalized, including the plantations owned by Fidel Castro's family. By the end of 1960, the revolutionary government had nationalized more than 25 billion dollars worth of private property owned by Cubans."

The angry Cuban ex-patriots are generally from that middle or upper class that had their property nationalized.

Unfortunately there's a large, politically-influential group of Cuban exiles in Florida. In pretty much every recent presidential election cycle, Florida has been a crucial swing state that could go to either side, so neither party has wanted to upset that group by normalizing relations with Cuba. From a political standpoint there's a lot to lose and nothing to gain from it, unfortunately.

I've personally interviewed way, way too many people with impressive-looking CVs that couldn't code worth anything. Some people probably exaggerate their experience and some people I've seen end up in manager/"architect" roles that don't require actual coding and seem to forget how.

Also, when you're hiring, you're getting a skewed picture of the overall programming population. Suppose (to make the math easy) that there are 100,000 programmers in the world, 90% of which are employed. So that leaves 10,000 programmers in the candidate pool. Most of the top 20% of those will be able to get a job from a referral and not go through a "normal" hiring process, so if you're screening resumes you're now down to the next 80%. But that's the bottom 80% of the 10% that's looking for a job. Of those, some are competent people between jobs or looking for a change, but a lot of them are just in the bottom 10% of the overall skill level, are basically unhirable, and are semi-permanently on the job market because of that.

To make another simplification, if you and I both screen 100 resumes in the same area, there's a reasonable chance that the 10 best candidates we see are different since they go off the market so quickly, but that the 10 worst candidates we see are the same, since they stay on the market. And unfortunately, some of those totally unhirable people have good-looking resumes.

Well said. Lack of focus is often more of a danger to a company than lack of good ideas, and that goes double for startups.

Don't forget about audio. Even where the appropriate video output is available, many PC's lack any audio output other than a minijack.

I didn't start programming until college (aside from screwing around with my TI-85 when I was bored in class), and it hasn't really set me back at all. If it's something that makes sense to you and you can think algorithmically, you'll do fine no matter when you start.

I often encounter the assumption that all "good" programmers start early in life and/or that all "good" programmers have an innate drive to build things and that's why they got into programming in the first place. (I think the two assumptions are related). And while it's true that many good programmers meet those two criteria (probably the majority), they're not universally true.

There are other reasons to love programming besides just the end result; I myself was drawn to it because I'm fascinated by the intellectual challenge of taming and organizing complexity, and of the way program construction can be seen as a series of rapidly-evaluated scientific hypotheses (i.e. "I think I can do X this way" and a short while later, relative to pretty much any other discipline. you have confirmation or rejection of that hypothesis).

I did, however, leave school with a bit of a complex precisely because I don't fit the traditional grew-up-tinkering-with-computers mold for software engineers. I thought that all those other people must be better than me, or be lightyears ahead of my skillset, or that because I came to the profession differently I must be somehow inferior or have a lower ceiling on my abilities. It took me a couple of years of programming professionally to realize that wasn't the case and to be confident in my abilities.

Anyone with the right set of cognitive skills can do fine in a college CS program regardless of their background, and anyone who has the skills to make it through a college CS program and who enjoys what they're doing will do fine as a professional programmer if they're willing to keep learning, regardless of their prior background. (And I don't mean to imply a CS program is by any means the only way to go, merely that someone with no prior background who goes through such a program will likely be fine.)

They broke in his door because no one was home, and they'll pay for the damage. That's pretty much SOP when executing a warrant.

I believe that the contention of the police is that perhaps the facts aren't all public. They want to know exactly what exchanges too place between Gizmodo and Hogan (or whoever Hogan's go-between was), and I think that's reasonable. Did they ask where the phone came from? Did they ask if attempts had been made to return it? Do the dates of those correspondences match up with the stories both sides are telling? Etc.

You honestly think that Apple would deliberately hamstring javascript performance on the iPad so that people have to use native apps? I think it's pretty ludicrous to think they'd do that: their sales of the iPad are directly, heavily affected by perceived performance of the device. If it's slow, people won't buy it.

How many extra apps do you think that move would make people buy: 2? 5? So you think they'd cripple performance and lose hundreds of thousands of sales so that they can get people to spend an extra $20 or so at the app store, of which they'll get all of $6? If they wanted your extra $6 that badly they'd just up the price on the device.

I just don't understand this constant assumption that every decision Apple makes is anti-competitive and designed to achieve lockin. Isn't it way more rational to assume that they want to make the device as good as possible because they make money by selling devices, and that their decisions are primarily driven by that motive?

How exactly is that exclusion anti-competitive? Presumably Apple wants JS to be fast on the iPad just as much as anyone else does, and would only exclude something like that for a good reason.

Keep in mind that JDK7 (and a version of JDK6) is open sourced and GPL licensed at this point.

The discrimination against male nurses isn't overt, it's much more subtle: male nurses are the subject of jokes and people act as if there's something inherently effeminate and un-masculine about the profession. There's a general societal attitude that "nursing is for women" that certainly discourages men from entering the profession.

It's a personal taste thing, honestly. Language features aren't free to users: as a user, you need to understand the behavior, so if there are two possible behaviors that's something else to learn.

There are two different use cases here: lambdas (which may be true closures) and user-defined control constructs. In the first case, I'd argue that you want the declaration semantics to be as close as possible to a normal function definition. You should be defining a function, so return returns from that function, and break/continue statements can't have targets outside the function. For control constructs, you want the code to appear as if its inline, so you want non-local return semantics. I.e. you want it to behave as if it's not actually in a separate function at all.

So I think those are two different constructs, and things get confusing when you conflate the two. At the very least if you want to have those two constructs, make them look different enough that users don't confuse them. Java was going to go the wrong way there on their initial closure proposal (the => versus ==> thing) and make things that look like lambdas behave like in-line statements. Ruby kind of goes the other way and makes everything look like a bunch of statements within the body of something else in contexts (like the reduce() method) where what you really want or would expect is a lambda. If I write "return x + y" in the body of my argument to reduce(), I expect that to be the value of the reducer function, not to exit the function that was calling reduce(). But at least in Ruby a block is always a block and always has the same semantics, even if those semantics seem inappropriate for many use cases.

But again, it's personal taste as to which of those, or both, you want to add to a language. In my personal opinion user-defined control statements aren't all that useful and you can fill most of the needs with language-defined control constructs. But it's a tradeoff the language designer has to make, and there's no one right path.

I think a clearer way to put the distinction is that in Ruby, blocks serve both as lambdas AND to let you define new control structures (that are thus analogous to for loops). Combining the two lets you do things that you can't do just with lambdas, and if you want to make an argument as to why blocks are flexible that's the right argument to make. For example, to wrap file access in the appropriate open/close functionality while still letting you return early via the block.

Unfortunately, it can also result in some serious confusion on the part of a programmer that wants to think of them as lambdas. Java was originally going to do something similar and have two types of lambdas in 1.7, one using => and the other using ==> to indicate the non-local return semantics, and I think it would have confused a ton of people.

If you have a filter that takes a predicate function, for example, you might naively do (excuse my incredibly-rusty-and-thus-totally-syntatically-mangled-Ruby):

some_list.filter() |x| do if (x.foo) return true else return false end

In this case, you'll end up returning from the outer function, NOT just returning a true/false value for filtering. To do that, you have to just do:

some_list.filter() |x| do if (x.foo) true else false end

And rely on the way that things you might otherwise think of as statements are expression values in Ruby. But what if my predicate function is really complicated, and I want to end the block early? Um . . . too bad. Better put that in its own function and call that function from your block.

I'm sure that in practice those aren't major issues for people used to Ruby idioms and behavior, but from someone new to Ruby they can really trip you up.

Ugh. I've always hated the non-local returns in Ruby blocks. They massively clutter up my mental model of a block as an anonymous function, where a return statement should return from the block's function, not the enclosing function.

It seems like it adds in a lot of potential confusion and diverges from any other closure/lambda implementation in any other language without adding much value.

I think it's a reasonable argument, but it's perhaps not stated as well as it could be. It's a response to the (presumed) justification from Apple that they want to do this because cross-compiled applications are often low-quality. So the argument is that if Apple wanted to weed low-quality applications out of the app store, then they should do that based on the quality of the applications, rather than based on the implementation techniques.

Clearly, though, the fact that the app store is already flooded with low-quality applications is indicative of the fact that Apple hasn't been doing that, which makes that justification seem totally bogus: if they really cared about low-quality applications, they could have done something about it long ago without restricting cross-compilation techniques. And if they wanted to put a stop to it now, they could still do it without restricting cross-compilation.

So to extend your analogy: if you want to weed the garden, then pull the weeds already. No need to have this strange level of indirection that will result in removing only a small number of the weeds while also eliminating plenty of flowers.

invokestatic is used for invocation of static methods, where there's no "this" pointer on the stack. By definition those calls are also statically dispatched. invokespecial is to statically-dispatch a call to a virtual method, and is used both for constructor invocation (the construct is implicitly a method named "<init>") and also any time you call super.foo(), since you're explicitly specifying the target method and wouldn't want that call to dynamically dispatch back down to your subclass. invokevirtual and invokeinterface both dynamically dispatch instance method invocations; invokevirtual is used for method calls to a concrete type while invokeinterface is used for calls to interface methods. The primary difference is performance-related: invokevirtual can be more heavily optimized because it's a call to a known class or one of its subclasses, so the VM can do things like store the vtable offset for the method. invokeinterface is invoking the method on some unknown object every time, so it has to be looked up each time (though technically if it's always the same implementation, in practice invokeinterface should be about as fast, since you'll just end up with a guard clause and then a direct invocation of the actual target method). For purposes of a method handle invocation, I'd imagine that invokevirtual and invokeinterface should behave the same, i.e. they just dynamically dispatch.

Currently the Method object in Java always does dynamic dispatch for instance methods and static invocation for static methods, and there's no way to do mimic invokespecial via it.

From the list of partners, it looks like they're all basically either handset manufacturers or content providers, which is . . . interesting. Microsoft and Apple are noticeably absent, and not too surprisingly there aren't any Linux-related organizations on there either. Their "Why" page for partners specifically targets chipset vendors, OEMs, operators, content providers and developers, and end users.

So it certainly doesn't look like they're going out of their way to play nice with browser or OS developers, or that they're trying to open up the actual implementation: the program seems more geared towards getting Adobe's software onto devices, getting hardware acceleration from chipsets, and getting content providers and developers to deliver content in their formats.

In general a well-reasoned article, but I don't really agree with the contention that private APIs should be removed: when you're shipping releases of something infrequently and you want to avoid breaking client code, APIs have to be something you can commit to supporting long-term without significant changes. Keeping APIs private allows you to provide functionality that you want to have without risking a bunch of stuff breaking client-side on upgrade, since you can update your applications to work with your API as needed. Getting APIs right enough that they can be supported indefinitely is really, really hard, and it's not reasonable to expect that every bit of required functionality will be implemented and designed to such a high level of completeness the first time around.

Arguing as a sometimes-utilitarian: people love their iPhones, and their creation has actually brought happiness into people's lives. In all this doom-and-gloom talk about how the iPad will destroy computing as we know it and Apple is the new evil empire, etc. etc., hardly anyone ever seems to weigh the happiness brought to consumers by their devices.

So let's not just focus on the theoretical-hacker-kid-who-will-now-never-learn-to-program, because they're not the only type of person affected by these devices. Are many people's days just a tiny bit happier because they have their iPhone? Yes. (And many people's days are happier because they have a phone that is much better than it would have been had the iPhone never happened). And that should matter too.

It's not quite that black and white: essentially, the laws around "accredited investors" are there to clearly delineate professional investors from more casual investors so that the person receiving the money can be sure that it will count as a private placement exempt from SEC registration requirements. That, in turn, is to prevent scam artists from inducing people to part with their money by "investing" in a private investment that's totally free of SEC registration and oversight. If you wanted to invest in your friend's startup, you could, but if you wanted to fund other third-party startups with which you had no pre-existing relationship, you'd need to register as an accredited investor.

See grellas's excellent summary from a few days ago:

http://news.ycombinator.com/item?id=1221387

As absurd as it seems, laws like this don't come out of nowhere just to make people's lives complicated and miserable: the SEC registration requirements are there to prevent scam artists (of which the 20th century that saw rise to these laws saw plenty), and the accredited investor regulations are a way to clarify the exemptions to those requirements.

Seems like an accurate statement . . . $20 per hour does, indeed, accurately reflect the importance of the position.

Sounds about right . . . any time you're solving a particular problem, things get a lot simpler. You need something to do x and y, so you make something do x and y, and it's pretty easy to tell whether what you've made sucks and x and y or not.

Once you have to handle anything workflow-ish or manage any sort of business process, or any time you have to handle integration to arbitrary external systems, it's very difficult to make anything that doesn't suck. The "right" thing becomes very fuzzy, and there's no one purpose or problem you can use as your rightness criterion, so it all becomes very fuzzy. Things then get worse when some standards committee tries to please everyone, or when business users insist that they want everything to work exactly the way it used to just, you know, with a computer know. And since there's no easy criterion against which to judge the solution, it's an easy slope down towards even more suck.

Making sure that some piece of software doesn't run afoul of an existing patent is basically impossible no matter how many billable lawyer hours you throw at the problem. You'll either come to the conclusion that everything has already been patented and thus you can never build anything ever again, if you read patents broadly, or you won't find anything at all, if you read them more narrowly and throw out the ones that obviously have prior art and should never have been granted.

The only 100% reliable method of patent lawsuit control is software development abstinence . . .

That "irrationality" is fundamental to many types of enterprise software, which is a big reason why most of it sucks. You're codifying hundreds of years of established precedent, often heavily legally regulated in slightly different ways by all 50 states (not to mention foreign countries). The more established precedent there is, the more history in the industry, and the more regulation, the harder it is to write decent software.

Sure, but there will always be people who want or need a great site not just a site (or even a pretty good site), and the former will probably always be much harder than the latter and demand some amount of skill no matter how good frameworks get.

Huh. I've used IntelliJ on Windows for close to 8 years and never noticed any font rendering issues.

What platform did you use IntelliJ IDEA on? I work with about 100 other (highly opinionated) developers that all use it, and I've never once heard someone complain about the font rendering.

It'll be interesting to see whether the negative impact of employers trying to stay below 50 FTE employees is offset by the positive impact of people feeling more free to start or join small businesses that don't yet offer health coverage because they don't have to worry about pre-existing conditions when obtaining individual coverage. It's not an obvious calculation either way.