jsankey

If you think this doesn't matter in practice, consider Apple vs Google Voice on the iPhone. Apple rejected (or "didn't approve") voice, leaving iPhone users with no way to access it. Users would be better off if Google could have hosted a Google Voice package external to the app market.

First and foremost, I don't have to jailbreak my phone to install apps not "approved" by Google/the carrier/whoever. I can download an APK from anywhere.

Secondly, the code is open. This does matter in practice, because there are people who can and do take advantage of this to create modified versions (e.g. Cyanogen). If Google decides not to take a particular direction, but enough people want it, it can happen.

Thirdly, it's not tied to one hardware manufacturer. Apple may make great hardware, but they attack a certain target market, which not everyone fits into.

Finally, although your argument about carriers has some truth, it misses a couple of points. It's not like iPhone users are exempt from all carrier restrictions - why can I tether via my Android phone yet iPhone-owning friends cannot? And there is nothing about Android that forces you to use a certain carrier (ironically, in the US, it's iPhone users that have no choice of carrier). I purchased my phone on T-Mobile in the UK, now I use it on another carrier in Australia, no problem.

I think the problem with Clojure (and perhaps Groovy too), is that the compiler/runtime for the language invades the traces. If you look at the example given in the original post, almost the entire trace is Clojure plumbing. That's the real issue, and it's not the fault of the Java stack.

For security reasons you’re unable to use the Back, Forward and Refresh buttons in your browser.

Uh, ok...

Having said that, Google are heavily reliant on the Java platform, so they must have at least considered how they can protect the platform if necessary. Could they fork OpenJDK? Or at least support a fork? They certainly have the resources to do it, and Oracle's early moves don't bode well for a cooperative solution, so I wouldn't be surprised. Perhaps they will use the current litigation as a test re: the possible patent issues, although by the time that is resolved it may be too late to make a move...

That's a big if. For most projects, the work is not that difficult in a technical sense. The hard parts are accurate communication and managing change over time. IMO these factors are much more likely to cause project failure than some pure technical hurdle.

Wow, I'm pretty shocked that someone who already owns and runs a business would not take care of something so basic when setting up a new business.

"That means brevity. As Seneca said, “Truth hates delay.”"

"An unnecessary global variable is not just an invitation to "bugs; if it’s overexposed, it’s lying"

"If it’s a playlist, call it a playlist. Don’t call it a set. Tell the truth."

The connection here is shallow: the author has merely found a way to work truth into each description. Maybe it's better to just accept that there are multiple axes of goodness (which further makes us realise sometimes they are in conflict).

Great engineers, even in other fields, aim for the best results using constrained resources. Compromise is a key skill.

The hardest part would be having some way to quantify the debt. But you could, at least, make a record of the corners cut, and make any accumulation extremely visible to management. Does anyone know of anything like this?

They might struggle to get people to sign up when there is doubt about the service surviving. But that cat is already out of the bag, and as I alluded to earlier they could also play this to their advantage (charging now is not a money-grab, it's simply a matter of keeping a valuable service viable).

After taking so many knocks, it's easy to be disheartened. But why not at least give this a go? It doesn't involve a large engineering investment - just charge for what you already offer! When the alternative is shutting down, where existing users need to move on anyway, you might as well. Those users might appreciate the value of what they have now that it is about to disappear...

What an utter waste of effort! For more time spent doing grunt work, you give slower and less complete feedback to your customers (platform developers in this case). There may be some information they don't want in a public tracker, but I'm betting it's:

- a lot less information than they think; and - much easier to manage in a different way, as opposed to maintaining two bug databases!

If you are thinking of the latter, or both, maybe you should consider having a couple of layers of customisability. It would be nice to allow simple customisations (colors, logos, even basic layout) without getting into templates. Perhaps with a GUI, but possibly even just something standard like CSS. Even as a technically minded person, I would balk if I had to learn some custom syntax to achieve things like this.

Then underneath you could have a full templating system. If users want full control, they should understand it will come with a learning curve. Even for this, consider starting from a known base (e.g. Django templates), and just building convenient constructs that fit your site (e.g. custom tags for common tasks).

You have to hand it to the few that believed, and put in the work to reach critical mass...

I don't see why the initial implementation couldn't be simpler. Wouldn't the simple implementation have similar performance to the status quo (i.e. using if statements), with the immediate benefit of cleaner syntax? In fact, why should this level of optimisation be part of the JSR at all? It sounds like something the JVM implementers could optimise without any change to the way the switch works. Tying it to the JSR makes the spec more complicated, delays an initial version and forces this optimisation to be prioritised over others.

http://www.time.com/time/magazine/article/0,9171,1916286,00....

(Building a Media Empire Around I Can Has Cheezburger)

The quality of the results depends a lot on the amount and quality of the input (how well it represents what you are really trying to match). A single example string is unlikely to get you far - you would certainly need multiple matching examples. So I think this approach works best when you already have an example corpus to work from, rather than providing input manually. If you're going to spend effort providing a lot of input, then you'd probably be better off spending at least some of that effort in providing hints or possible regex answers.

Further, there are many possible regexes that would match an input set, so the algorithm also needs some way to evaluate them and choose the better candidates. In my case I used some ideas from information theory (such as MML), which actually worked reasonably well. But this is a computationally hard problem, so even with an objective measure of the optimal regex you won't necessarily be able to find it.

... I think by focusing on this communication, the code becomes inhertitly (sic) better, because you think more deeply about the abstractions and layering you are doing ...

Explaining a problem (or solution) definitely helps me understand it better (or even realise that I don't fully understand it). Interestingly, you might find that the act of commenting refines your code to the point where some or all of the commentary becomes unnecessary - it's served its purpose. So sometimes the feedback loop might have a few iterations to get to the most clear and concise form of code + commentary.

Eventually I wised-up and dropped that habit :).

- Pros and Cons: when I have too many answers, I try to make it objective by drawing up the pros and cons and seeing where that takes me.

- Simplify: like a lot of developers, I can be prone to over-analyse when I am stuck on an issue for a while. So I remind myself to try simplifying the problem. Often by dropping a layer of flexibility the problem is a lot easier to solve. If I really need the flexibility, I can add it later when I have greater understanding.

- Take a Break: sometimes I’m just trying too hard, and need to step back. I work from home, so a short walk outside is a welcome break. Actually getting away from the computer relaxes the grey matter. The vitamin D doesn’t hurt either.

- Explain the Problem: very often I find that while I’m explaining the problem, I see it in a different way. If not, the input of another person usually throws a different perspective on the issue. If there’s nobody to bother immediately, just writing down an explanation can help.

- Switch Gears: this works when I’m getting frustrated by a lack of progress. By switching to a small, unrelated task, I can Get Something Done and develop some new momentum. This also serves as a break from the original problem.

- Write Some Tests: I don’t practice TDD all the time, but when I’m stuck trying to understand how things work, writing some tests first can be very illuminating. Having tests in place also gives gratifying feedback as I finally start to crack the underlying problem. I find this works best for really tough technical issues, where good test coverage is even more important than normal.

- Write Some Code: if I have a partial solution, even if I know it is ugly or inadequate, sometimes I’ll just plow ahead anyway. Actually working through a throwaway implementation is better than standing still, as it turns up all the little details. I’m happy to throw that code away since I know the alternative was not getting anywhere.

That said, it would be best for people to check more thoroughly first, to avoid any wasted effort!