Hacker News Reader

jsankeyon Why I love Common Lisp and hate Java, part II – code examples

I take your point and I may be underrating the impact of verbosity. However, I think you're not quite addressing my point, which is that violating DRY (by not using high level abstractions) is worse than verbosity.

Is it verbosity that is the best measure of complexity, or is it code size? Yes verbosity leads to more code, but it's not the only thing that does. Operating at the wrong level of abstraction also will, and in a way that makes maintenance extremely difficult.

Unfortunately I've not seen any evidence compares the impact of boilerplate vs duplication.

jsankeyon Modern Language Wishlist

Clojure is awesome, but does struggle on the "Good error messages" requirement, which is a problem when you're starting out.

jsankeyon Why I love Common Lisp and hate Java, part II – code examples

Verbosity is not as big a deal as operating at the right level of abstraction. It's much more important to adhere to DRY than to save a few lines of typing. Verbosity can harm readability, but not much in this case (I wouldn't use an anonymous inner class, so it's just a case of passing a GreaterThanPredicate).

jsankeyon Why I love Common Lisp and hate Java, part II – code examples

Sigh. A good Java coder will also "get itchy" when writing two such similar functions. In fact, they'll probably already have a library that provides predicates that make the same level of abstraction trivial. Sure, the code in the predicate, being a whole class, will be a bit verbose, but that's a separate issue.

jsankeyon Dear business people, an iOS app actually takes a lot of work

I wonder how much of this is because iOS apps are typically priced so cheaply. The thinking goes something like "If you can buy quality apps for $1.99 then how much could they cost to make?". Of course some apps make a lot of money at this price point, but it's widely reported that the vast majority make a loss on the developers' time. I suspect even the majority of non-junk apps (which rules out a lot of apps!) make a loss in this sense. If developers aren't valuing their work correctly, how/why would the people hiring them?

jsankeyon 25 Startup Ideas for 2012

And I guess they were, to a disturbing degree, right?

jsankeyon Average Is Over

On the upside, as populations become wealthier and more educated the fertility rate drops. We're a (scarily) long way from things stabilising, though.

jsankeyon Cost breakdown for Stripe, Braintree, Chargify, Recurly and Saasy

I've got no idea why you're being downvoted - perhaps your last paragraph is a little harsh. But you're right, it's odd not to see mention of PayPal. It works, it's inexpensive, and for non-US businesses it's one of the few available options.

jsankeyon Cost breakdown for Stripe, Braintree, Chargify, Recurly and Saasy

Missing from this analysis is which options are available outside the US. I've tried to quicky figure this out for each provider, please correct me if I'm wrong:

  - Braintree: only if doing 3 million+/year.
  - Chargify: in theory yes, if you can find a merchant provider that accepts you with reasonable terms, which isn't easy.
  - Recurly: "Recurly supports SagePay and PayPal in the U.K. and Ireland, as well as Wirecard throughout the broader European Union."
  - Saasy: Yes.
  - Strip: Not yet.

Although it makes sense to start in the US market, it's getting to the point where all most alternatives are US-centric, and there's a big world of us out here that would also love better payment gateways!

jsankeyon The Greatest Running Shoe Never Sold

Regardless of who is right, this is a weak argument. Barefoot may be the natural way to run, but that doesn't mean it's the best. The natural way to handle an infection is your immune system, but you'll be thankful for antibiotics when you need them. In short, it's possible for us to improve on "natural".

jsankeyon Designing "Mute"

In practice, it's a "Mute- all sounds, but don't frustrait me when I try to watch a movie, or need to get to work on time -switch".

This definition is fuzzy, and thus harder to understand, which was my second point.

Theaters, weddings, etc. are absolutely not the only time you want to mute things.

I didn't say these were the only times, I claimed this was the most common use case. Granted, I don't have data to back this up, so perhaps I'm wrong. I'm sure there are plenty of other reasons to mute, this just seems to be the classi case that I anecdotally see the most.

I for one really appreciate that I don't have to think about what state my mute switch is in when I get home hours later and try to watch a YouTube video.

This is hardly a big problem, though, certainly not worthy of confusing behaviour.

The common case is that your alarm is only ever set to wake you up in the morning and your timer is only ever set when you're sitting around, waiting for your dinner to be ready. It's very rare for you to set an alarm or a timer which will affect a quiet group environment.

I agree you wouldn't normally have an alarm/timer set for these times. It's probably a rare mistake, but an embarrassing and costly one! These aren't the only ways that an iPhone will ignore the mute setting, though. This "feature" gives you plenty of ways to shoot yourself in the foot.

jsankeyon Designing "Mute"

The problem I have with the iPhone behaviour is twofold:

1) The most common uses for mute are situations where you absolutely don't want any sound (theatres, weddings, etc). The iPhone behaviour makes it much more difficult to guarantee this than the obvious behaviour.

2) It complicates something that has an obvious default behaviour. It's no longer a mute switch, it's a "mute non-explicitly-requested sounds switch".

I could see the iPhone behaviour being useful -- it's more flexible after all. I just don't think it's worth compromising the common case.

jsankeyon Designing Great API Docs

For this reason I would say you need to automate as much as possible. Maintaining quality documentation is expensive, and although much of it requires a human eye there should be plenty of opportunity for machie verification too.

For instance, code examples (snippets or sample projects) should be actually compiled and tested, automatically, every time the docs or the API itself changes. Think of it as CI for your documentation.

jsankeyon Launching the Kindle Fire was a mistake

The return rate will be high and Amazon will suffer for it.

The Fire currently has over 8000 reviews on Amazon with an average rating of 3.9. Over 5500 of those reviews give the device 4 or 5 stars. Something tells me the average Fire customer does not have such high expectations.

jsankeyon If you gaze into nil, nil gazes also into you

I don't think that nil accepting any method and returning nil fixes this problem at all. It certainly shifts it. Sometimes enough to stop it from biting you, but only by accident. Other times, the shifting just makes it that much harder to figure out what is going on.

Fundamentally, if you're not explicitly aware that something might be nil you won't always be making the right choices. The Objective-C behaviour just allows you to get lucky some of the time. Frankly I'd prefer if it just blew up in my face immediately.

jsankeyon If you gaze into nil, nil gazes also into you

This argument just seems like a step along the path to static typing. If you're using Ruby, haven't you already decided that you prefer the simplicity of a dynamic language to the safety of static types? So why start to add half-baked typing to your code? It seems like it just puts you in an uncomfortable middle ground.

jsankeyon Maybe Americans aren't dumb enough to keep buying houses?

That's not a conservative option for someone in the US, as it leaves you exposed to forex risk.

jsankeyon It Takes Courage To Delete Code

Ii doesn't take courage. Just a little experience tells you that code you delete is less code to maintain. And if you want to build anything non-trivial, maintainability is absolutely critical.

I love deleting code.

jsankeyon Apple Hiring a Team to Build "the Future of Cloud Services"

Unfortunately openness probably won't matter in the short term. If it works, and untethers iOS devices from Macs then people will use it. There is hope, however, that open wins in the long term, and Apple will eventually have to play along.

jsankeyon Things overheard on the WiFi from my Android smartphone

Unfortunately it's too easy for people just to hit the OK button at install time without thinking about it/realising what they are agreeing too. Whilst the user has to take some responsibility for this, maybe it would be more obvious if the system prompted the user the first time an application tries to use some permission. Then they would see the context in which, e.g., their location is accessed.

jsankeyon Let us pay for this service so it won't go down

You must own any data that’s irreplaceable to you.

An interesting additional point given the ongoing trend towards web apps and storing data "in the cloud". Note that "own" in this sense means you need to be able to export it in a standard way (e.g. access via IMAP). I don't see a lot of enthusiasm for this from the big sites out there. I can only hope that users start to realise the value in this and begin demanding more control of the data they are creating.

jsankeyon Node.js Guide

Unfortunately trailing commas still break IE7, which I wouldn't yet classify as old enough to ignore.

jsankeyon What is Stack Overflow's business model?

I'm not so sure SO will lead to a smaller pie. The walled nature of EE limited its appeal to the largest part of the audience (the people looking for answers). So although their business model was more direct, they were basing it on a smaller corpus, with fewer viewers. An indirect (advertising-based) model over a much larger number of eyeballs could well make for a larger pie.

The challenge for SO is to see if they can maintain a high quality corpus as they scale, so people will keep producing and consuming their answers.

jsankeyon Stack Overflow now accept anonymous edits

From the original post:

To prevent noise and friction, your change must be more than 6 characters

So, unfortunately, some of those infuriating typos will not be possible to fix. Reducing noise has benefits, but it also seems like these trivial errors are perfect for casual users to spot and fix. And it's possible that noise will actually be increased by people making spurious changes to cross the 6 character threshold.

jsankeyon Stack Overflow now accept anonymous edits

Stack Overflow may focus on people who program, but through Stack Exchange they are trying to diversify into Q&A for any topic. It seems inevitable there will be some overlap with Quora, and right now it looks like they're in a land-grabbing phase.

jsankeyon The road to faster tests

It is important to remember that you are changing the code (and probably the tests) at the same time, so your coverage data is getting stale. So you can only "mostly" predict which tests to run, which is somewhat useful but can also make these cut down runs misleading.

jsankeyon Editing your Google Docs on the go

My guess is it comes down to performance. Froyo brought the V8 JS engine to Android, with a "2-3x times improvement in JavaScript performance vs 2.1":

http://android-developers.blogspot.com/2010/05/android-22-an...

jsankeyon My Favorite Engineering Interview Question

An idea I've tried a bit in the past (and would like to try more, given the chance): ask a question that you don't know the answer to. This shifts the power balance of the interview - you don't automatically have the answer over the candidate. You also don't have your mind closed by your expected answer(s). Both of these make the resulting discussion more comparable to how you will work with a colleague, which is what you are trying to test the candidate for, after all.

Doing this requires more effort and guts from the interviewer, but it's still easier than being on the other side of the desk. Finding a supply of suitable questions is probably the trickiest part - you could try looking up some problems from competitions just prior to the interview, or you could perhaps take a real problem you are trying to solve at that point in time (abstracted as required).

jsankeyon Nordstrom's 75-word employee handbook

However, new hire orientations now provide this card along with a full handbook of other more specific rules and legal regulations, as the way Nordstrom operates has changed.

Hopefully the 75-word card still sets the tone, and the full handbook is just to satisfy the bureaucrats.

jsankeyon Apple and the future of Java

There don't seem to be many. But I believe it has been used quite extensively in internally-developed applications, never intended for the mass market. The same goes for Swing as well.

So although end consumers might not see them, it will certainly take a long time for SWT or Swing to die. These are the same class of applications that are keeping IE 6 alive, after all.

Does this matter to Apple? I doubt it's significant, as most of these applications are probably running on Windows desktops already. Probably more significant is the legion of Java developers that have been vocal proponents of Macs over recent years. The numbers of such developers might not be so great in an absolute sense, but the amount of noise they create is disproportionate. And, more importantly, they are more motivated to build interesting stuff for the platform they use.