akeefer

The problem is precisely that it's too difficult for grassroots volunteer groups to put measures on the ballot, while at the same time being too easy for well-funded private interests to get things on the ballot, which has resulted in the current distorted use of the initiative system.

Most initiative signatures are not collected by volunteers, they're collected by paid signature gathering organizations. And that's the problem the article was getting at: that anyone with enough money can get an initiative on the ballot by paying people to collect signatures, and once something's on the ballot, they can spend enough money to try to persuade people to vote for it. As a result, rich people and organizations can effectively buy legislation, or even constitutional amendments. That's not how the initiative process was intended to be used, but that's what we've got.

I'd also challenge you, if you're a fan of California's initiative system, to take a look at all the initiatives that have passed over the last 10 years or so. Now, remove the ones put on there by the state legislature (which is a lot of them), and of the remaining ones, ask yourself: how many of these represent a positive, populist change versus how many of them represent some corporate special interest or populist outrage attempting to do something that is more properly the responsibility of the legislature (like, in my opinion, the three-strikes law or sex-offender laws) or even just out-right discriminatory laws (like the various illegal immigration ones that have passed)? My personal calculus has been that the initiative process has, on balance, done more harm than good.

As was already pointed out elsewhere, using per-capita $ numbers instead of percentage-of-GDP is fairly misleading, and if you use percentage-of-GDP it's more like 19th for California; I didn't feel the need to point that out again. So California isn't particularly exceptional in the amount of their revenues. Those numbers were likely also for prior to the economic bust; I'd be interested to see where they fall for 2010-2011. Remember, for 2008, there were no budget problems for CA; our revenue has cratered since then because we're so reliant on personal income.

I also made the point that the shift from property taxes to income taxes made the budget harder to balance by destabilizing revenue. California's problems are often caused by revenue volatility, and the state's budget is fine during booms and blows up during busts. States that rely more on property tax and less on income tax have much more stable revenues. I don't believe that's something that you've find much controversy on among either researchers or academics.

And your counter-argument around "everyone has to compromise" is, I'm afraid, just straight-up incorrect. Sure, everyone has to compromise. The point is that the more votes you have to get on board, the more watered down it gets. The budget you get with a 2/3 majority required is demonstrably worse than the budget you would have gotten with a 51% majority, because getting those extra 16% on board almost certainly required a bunch more one-off compromises to individual legislators. If you've seen the CA budgetary process in action, you'll know it worked pretty much exactly like that, and pretty much every year involved a late budget and some holdout congressman demanding pork for his district in exchange for his vote. Imagine how much already has to go on to get the vote to 51% on any given budget, and then just add a bunch more of it.

>>> "So California's problems are not because of direct democracy."

Saying someone else's arguments for X aren't good isn't the same as making an argument for not X, and you've totally failed to do that.

There have historically been two major issues in California: Prop 13 itself, and the 2/3 requirement for budgets. Prop 13 has not only made it difficult to raise taxes as necessary, it's forced the state (and municipalities) to rely on less-stable, less-efficient methods of financing. Property taxes are historically a much more stable source of revenue for states than income taxes, and states that rely heavily on income taxes (like California) tend to have less stable revenues than states that rely more on property taxes. Prop 13 forced California to rely more and more heavily on income taxes, destabilizing its revenue. The 2/3 requirement to pass a tax has also made that basically impossible, so initiatives are financed through even-more-expensive bond measures. Also note that Prop 13 helped shift the tax burden away from corporate property owners (since corporations can live forever, they never have to transfer property), further drying up a source of revenue for the state. So while the best analysis I can find indicates that the initiative "earmarks" of funding are at worst a minor hindrance, Prop 13 is really the elephant in the room, and it couldn't/wouldn't have happened outside of the initiative process. But without it, we wouldn't be talking about the initiative process as an issue, because the CA budget wouldn't be such a mess.

Meanwhile, the 2/3 budget requirement also made things a mess by historically making it impossible to get a budget passed without compromising/buying off enough legislators to get it through. Since everyone knows the majority party needs every last vote to get things through, they can all hold out for their pet concessions, making it impossible to come up with any kind of a responsible, honest budget. Thankfully that issue was sort of resolved by another initiative this past year, though by not addressing the tax side of the equation it's only a half-measure: spending cuts can now be done with a simple majority, but revenues can only be increased by a 2/3 vote, which means that the legislators are basically trying to balance the budget with only half the available options.

I'd also say that the hardest part isn't the parsing itself per se, it's error reporting and recovery. Showing parse errors as someone types in an IDE, for example, requires an order of magnitude more sophistication than simply handling valid productions does.

Python as a language does not lend itself to the same syntatic abuses as either Scala or C++ (or, for that matter, Perl). While you can certainly do some sketchy things, there's a pretty strong Python tradition of there being one standard way to do something, which is one of the language's strengths in my opinion, especially as you scale it up to larger projects. I'd also suggest that 100k is not a particularly large project; it's reasonably on the order of what a good developer can more or less be familiar with, and the real problems with expressive abuse come into play an order of magnitude or so above that that level, where it's impossible to be familiar with everything. Hence why the article was talking about the problems with bringing Scala into an existing, large project; if your code base is 10k LOC it's not nearly as problematic as if you have 1MM LOC, because with 10k you can reasonably remember anything (and obviously 100k is somewhere along the continuum).

If you'd said you worked on a 1MM LOC C++, Scala, or Perl project where you didn't have to establish strict coding standards to avoid the code base descending into madness, I'd be pretty shocked.

Note that by using a technique known as escape analysis, a virtual machine like the JVM can detect that the lifetime of an object is such that it doesn't leave the context of a particular method and then stack-allocate the object implicitly. That may seem like a limited optimization, but when you combine it with method inlining it gets a lot more useful. I believe the optimization is turned off by default in the Sun/Oracle JVM but can be enabled via the -XX:+DoEscapeAnalysis option. For programs that allocate large numbers of short-lived objects, it can make a significant performance difference.

As could all of ours . . . however, many of us in the enterprise space don't have much choice as to the form of data we have to consume from outside services, so the point of making good low-friction tools part of the language (with no code generation) is to let you interact with those things without going completely insane.

Guidewire Software - San Mateo, CA (mid-peninsula in the Bay Area, for non-natives)

We do core systems for insurance companies. No longer a startup (we're about 9 years old), but still privately held and doing very well financially.

The core work is in Java, but the platform is mostly a proprietary stack, including the Gosu language that we've recently open-sourced (http://gosu-lang.org) and are still actively developing.

We need developers on our applications and our platform, as well as product managers and QA. http://www.guidewire.com/careers for more details.

Feel free to e-mail me directly (akeefer@guidewire.com) if you're interested or have any questions (I'm the tech lead on our platform team).

I did my BA in philosophy (focusing mainly on ethics and political philosophy) and my MS in computer science, and I personally found the mix to work incredibly well, though not in the obvious way many people expect (which tends to be around epistemology and logic on the philosophy side and AI on the computer science side).

The point of a philosophy education is not to teach you anything in particular; there's no body of knowledge to absorb in the same way that there is for math or any scientific or engineering discipline. At most, you can treat a philosophy education as a history course focusing on the history of human thought (which is why, in response to some other posters, it's important in philosophy to study the past, even if no one believes such things anymore: it's more like history than physics).

The really valuable thing for me, however, was learning the process itself: how to make assumptions and pre-conditions clear and separate them from the rest of your thinking, how to make arguments clearly and fairly, how to break complex questions or topics down into smaller pieces and the put them back together, how to not take it personally when someone disagrees with you. A philosophy course of study will also make you a better, clearer writer and communicator. (And yes, sure, there's plenty of room for BSing and incomprehensibility in there, but if you take that away from a philosophy course you're missing out.)

All those skills translate and complement computer science very well. At its core, the process of software engineering (as opposed to just programming) is the art of taking something really complex and breaking it down into the right set of components: ones that are large enough to be useful, but small enough to be correct, and with the right relationships between them. Taking a large program or problem and breaking it down like that is basically exactly the same set of skills that you develop when you study (and do) analytic philosophy. Being able to clearly separate assumptions, facts, conjecture, predictions, and arguments is also a key skill in a domain like CS where thinking outside the box, as it were, is always important, and where the rules and possibilities change so rapidly. And of course, it never hurts to become a better writer: I've worked with and known some brilliant engineers who were far less productive than they should have been simply because they couldn't present their ideas clearly enough to other people, and there's simply no way to get a team to all work in the same direction if they don't all share the same vision. A brilliant idea that no one else understands because it's been poorly communicated is usually fairly worthless.

As an aside: I know PG doesn't seem to think he got much value out of his philosophy classes, but I wonder if his essays would be as clearly thought out and put together as they are without it. I certainly know my own writing would be far less clear (and far less rigorous) if I hadn't done my BA in philosophy and if I'd just focused on CS.

For what it's worth, the main points of the article are fairly similar to our reasoning behind the Gosu language's design: type inference helps alleviate a lot (not all, but a lot) of the pain of having to write type annotations in languages like Java, and the addition of the ability to do some kinds of metaprogramming at load time (but not at runtime) gives you a lot of the benefits of the sorts of metaprogramming you traditionally do in a dynamic language like Ruby (again, not all, but a lot of the typical use cases).

There are lots of relatively coherent arguments already floating around the interweb around why composition is generally preferable to inheritance when it comes to code reuse; lots of people have strong feelings both ways.

I should point out, however, that many OO languages (like Java and C++) make inheritance much easier than composition, and as such inheritance seems more useful than it actually is, simply because it's all you've got. In languages that have better syntactic support for delegation and other compositional techniques, the usefulness of inheritance is significantly lessened. In other words, the usefulness of inheritance is more accidental (i.e. because you often don't have other good options) rather than inherent (i.e. because there simply aren't better options that are possible or available in other languages).

San Mateo, CA

Guidewire Software - We do software for the P&C insurance industry, but we build a lot of cool stuff to let us build those systems (like the Gosu programming language, http://gosu-lang.org). We need people both to work on the applications and to work on our platform, including our web framework, our Eclipse plugins, and our ORM layer. The company was founded back in late 2001 and is still privately held, but at this point we're very stable and successful.

http://www.guidewire.com/careers

You can e-mail me directly (akeefer at gmail) if you have any questions or if you don't want to get lost in the HR shuffle. I'm the Chief Platform Architect, so if you end up working in our platform group you'd be working with me.

I enjoy clever ways of approaching problems as much as the next guy, but I would never ding someone in an interview for not coming up with a clever-enough solution. Good software engineering is maybe 99.7% failure-avoidance and 0.3% cleverness. On very rare occasions you need a clever solution, but most of the time you need to solve the problem in a way that you're 100% sure will work, has no nasty failure conditions, and that other competent engineers will understand. If there's no other good solution, or if every bit/cycle matters, then you get to try to be clever, but that happens pretty rarely. I've seen way, way too many problems caused by people using clever solutions for problems that had straightforward-but-less-fun solutions. (And as has been pointed out plenty of times already here, the clever solution in this case is less optimal than a more straightforward one would be). If an interviewer seemed intent on proving they were more clever than me, or on trying to get me to throw out unnecessarily-clever solutions to straightforward problems, it would be a pretty big turnoff.

There is, however, now a company called Numenta that's working on AI using structures they call Hierarchical Temporal Memory that are, in fact, based on trying to model the sort of structures actually found in the brain.

http://www.numenta.com/for-developers/education/general-over...

Talk to Cliff Click (or sift through his blog http://www.azulsystems.com/blogs/cliff) and he will quickly disabuse you of the notion that having bytecode instructions in a processor is a good idea. For optimal performance you want a generic RISC-type processor with good hardware performance for critical things like read-barriers that the bytecode might require; you really don't want to design a processor that directly executes Java bytecode.

There's a whole hell of a lot of optimization that gets done in the JIT layer besides just translating bytecode to machine code, and you want all that stuff to get done in software rather than trying to build it into your processor. Once you've done all that stuff, emitting actual assembly code isn't really the hard part, so you might as well just design a processor that you can make fast, give it a simple general-purpose instruction set, target that instruction set in your JIT, and then add a few special goodies as you need them for things that are really, really hard to do fast without specialized hardware support.

That's kind of one of our explicit design goals with Gosu, honestly: we're not trying to set the world on fire with something no one's ever seen before, but we are trying to make sure that eventually we have a language that is A) has the "good" qualities of Java (whatever you characterize those as), B) is close enough that it's an easy transition for people, and C) provides useful improvements on Java (type inference, closures, first-class scripts, some kinds of metaprogramming). In other words, we'd like it to be a no-brainer for people to prefer Java over Gosu, even for people who really like Java and are scared of, say, Scala or Clojure (let alone some non-JVM dynamically-typed language). Hopefully we'll get there some day . . .

Funny you mention that; the original syntax was actually based on ECMAScript, so the syntactic similarities with ActionScript are not accidental.

We don't work around Java type erasure: if you create some object in Java and pass it off to Gosu, then that information is lost. For Gosu classes that are reified, we actually store the type parameter on the object itself, and it becomes an implicit constructor argument. For generified functions, we pass the type parameter through that's determined statically by the parser. For enhancements on generified Java classes, we also pass through the statically-determined type parameter. I.e. if you have a Gosu class Foo generified on T, when you construct Foo with type param String we'll pass the String type through to the constructor and store it on the object instance so we can retrieve it later. If you have something the compiler thinks is a List of Objects, and you call an enhancement method on List, we'll pass through Object as the type parameter, even if at runtime it's actually a List of Strings. So it's not perfect in its interaction with Java code, but it's usually good enough (and better than losing it entirely). As far as the Java classes we generate go, your generic type Foo has only one class, but as far as Gosu's type system goes, Foo parameterized on Object is a separate type instance from Foo parameterized on String.

Indeed . . . to be fair, back when we decided to rename the language internally, we looked for any existing projects using the name, and we actually contacted the Gosu library guys to make sure they didn't mind us using the name Gosu for our language.

They're both important; beware of trusting the decision making of anyone who suggests otherwise. Rational analyses are almost always by necessity incomplete. There will always be assumptions we think are true that turn out to be false, facts we're unaware of, options we don't consider, or externalities we're oblivious to. Intuition often picks up on those things that we can't obviously articulate, or recognizes patterns that aren't otherwise apparent. On the other hand, people often use "intuition" as an excuse for shooting from the hip, justifying their predispositions, ignoring dissent, or simply being too lazy to do a rigorous analysis.

There's no substitute for doing your best to rationally analyze something, gather data, analyze arguments, etc., and not doing so in a particular situation is simply sloppy decision making. But that's merely one input into a decision making process that can also include things that fall under the category of intuition but which can't easily be articulated: ideas that give you a bad feeling or make you nervous, gut feelings about things, consideration of taste and aesthetics.

In the end there's no substitute for having good judgment, and good judgment and wisdom come from being able to use both rational arguments/data and intuition/feelings to arrive at the best choice.

No, it's based on their extensive analysis of the cases and all documentation associated with those cases that tries to discern if there are even mere allegations by the plaintiff that the patent infringement was due to any manner of copying. Their stats show that, aside from pharmaceutical or chemical patents, the number of patent cases in which copying is even alleged at any point is very small (i.e. a few percentage points).

One could argue that perhaps that low incidence is simply due to people not bothering to allege copying since it isn't relevant to if infringement occurred. The authors suppose that that's unlikely, since copying is highly relevant to the question of whether or not willful infringement occurs, and their limited evidence suggests that findings of copying do in fact tend to lead to findings of willful infringement. To test that hypothesis, they gathered up an additional 102 cases where evidence of copying was found and found that in nearly 2/3 of them copying was alleged by the plaintiff. (pp. 28-29 in the pdf). That would seem to be fairly strong evidence that if a plaintiff has actual evidence of copying they're highly likely to allege copying somewhere in their complaint.

Thus, it's a reasonable conclusion that since only 10% overall of patent litigations involve even allegations of copying (and far fewer for anything outside of pharma or chemical patents), that most cases where there's actual evidence of copying result in such allegations, and that allegations themselves are merely an upper bound on actual copying (since the allegations may well be untrue), that there's actually not much copying going on, which means that most of the inventions being sued over were produced independently rather than through any kind of "copying" or "theft."

This research doesn't tell you much concretely about the benefits of the patent system that might be lost in any potential reform, but it certainly says something about the costs that it imposes right now: clearly lots of people get sued over things they invented independently. In fact, in the overwhelming majority of cases not involving chemicals or pharmaceuticals, the people being sued (and thus punished) are independent inventors. It's hard for me not to conceive of "people getting sued over things they invented/created completely independently" as anything other than a pure cost to society, and the research in this paper makes it pretty clear that most patent lawsuits fall into that category of "pure cost to society."

It also does say something about the "benefits" of the patent system, though less strongly: clearly if the vast majority of people being sued in particular industries are independently inventing things, that means that the knowledge transfer benefits of patents in those industries is likely over-stated by pro-patent lobbies.

Exactly. Funny story there . . . we started our JVM language as interpreted, more or less, and ended up having to write our own not-so-great debugger for it. We decided to compile it down to native java bytecode precisely so we could take advantage of all the native Java tools that work with standard Java-like classes, such as debuggers, profilers, and even just stack traces. That approach doesn't work so well for languages that don't match Java relatively closely (i.e. stack traces in Closure are, I understand, pretty horrific), but for our language it's turned out pretty well.

Indeed, it's the overall "experience" (for lack of a better word) of programming in a particular language that matters. That's influenced by not just the syntax and structure of a language but also by all of the development tools, libraries, frameworks, documentation, and tutorials available, as well as the methods of working that those enable (i.e. REPL versus fast deployment, compilation steps required, ability to reload code on the fly, etc.).

One of the first things you will find out, if you attempt to write a new programming language and then use it for actual production work, is how much users of that language will miss simple, taken-for-granted things like debuggers.

Creating a programming language by itself isn't all that hard. The real work is actually making it usable with good error messages and stack traces, tools like debuggers and profilers, editor support (if you're into that sort of thing), and documentation and specs. All of that (especially good editor support) is easily an order of magnitude more work than a parser and a compiler, and that doesn't even consider libraries you might need to write if you can't interoperate with an established language. (Spoken from personal experience, for what it's worth).

For anyone in the Bay Area that wants to play around with an Arduino, Mitch Altman runs fairly regular workshops (every few months) at Noisebridge up in San Francisco. (https://www.noisebridge.net/wiki/Noisebridge)

One common technique used by agile methodologies (yes, I know that word has a ton of baggage) is to estimate in terms of story points rather than actual hours, days, etc. You start out thinking of a point as "one ideal day of uninterrupted work" to use as an anchoring point, and then for any work you want to do you break that work down into stories that you can estimate work for. If the story is bigger than about 3 points, you break it down further; if you can't estimate it, you do more research so you can.

The important part is not that the estimates match any number of hours per se, but rather than the relative weighting is about right, such that something you estimated as 3 points is, in actuality, about 3 times as much work as something estimated at 1 point, and all 1 point stories are roughly comparable in terms of work.

What you then do is to empirically estimate the actual mapping of points to hours/days as you work by tracking your velocity. In a 40-hour work week, how many points do you actually get done? As you get better at estimating, ideally your velocity becomes more stable, and then you can map from points back to days in order to make scheduling decisions. We switched over project planning and estimation to that strategy on a fairly large project I was leading, and it helped give us much more accurate overall estimates.

Now, that's all easier to do when you're working on a long-term project, you're familiar with the existing code base and the problem domain, etc. such that you can actually break things down into stories and do reasonable estimates.

That said, I think that the general idea of point-based estimation is still useful for you: rather than trying to estimate hours or days, work on getting better at relative estimation using something like points, and then empirically measure your mapping from points to hours to determine your likely schedule and how much you should bill.

My understanding is that there are a few reasons why it can be a bad idea. First of all, prior art seems to be taken more seriously during the re-examinations that happen during lawsuits. If the prior art is presented beforehand and the patent is granted anyway, then that avenue is closed off. In addition, it gives the patent filer more of a chance to tweak their patent to try to work around the prior art and re-file it (often several times) until it gets granted. So you want to only present prior art during the phase of examination during which it's taken the most seriously and when the patent filer doesn't have an opportunity to game the process by refiling over and over again, which usually means waiting until it comes to trial.

Secondly, patent attorneys don't like their clients doing any sort of search of/reading of any patents that could potentially affect their work. If you're found to have knowingly violated a patent, the damages are far greater than if you did it unknowingly. Submitting prior art to try to get a patent thrown out before it's granted would necessarily require researching and reading up on those very patents, so if the patent didn't get thrown out and you were eventually sued for infringing it, you'd be in much, much bigger trouble. Presumably the people who have the incentive and knowledge to bring up that prior art are likely to be involved in the same segment of the industry, which puts them in an awkward position: do you try to get the patent thrown out ahead of time, and be in serious trouble if you fail, or do you hope you don't end up at trial but keep the prior art in your back pocket in case you do?

Perhaps big companies could have a dedicated legal arm to research and challenge such patents at arms-length from their developers and/or keep their developers aware of potential minefields, but for smaller companies you'd be better off avoiding patent searches or research altogether.

That's fairly paradoxical given that patents are supposed to further innovation by giving people an incentive to disclose their inventions, but that's what the software patenting world has come to . . .

Much of it is owned by groups like the Peninsula Open Space Trust or is otherwise an official county or state park. The open spaces along 280 might seem under-utilized, but they're also one of the critical things that keeps the Bay Area from turning into LA, and one of the biggest reasons why the peninsula feels so different from San Jose.

That was true when it first came out; the version shipped with Ubuntu was the 1.6.0_0 version of Iced Tea, which had all sorts of problems. The latest version is fine.

For anyone who's curious, OpenJDK was (if I recall correctly) originally a fork of the early JDK7 code line, but with everything JDK7-specific stripped out. Originally it was fairly buggy, so the initial Iced Tea builds of Open JDK6 weren't really usable for production work, but since Open JDK6 was released most of the bug fixes that have gone into the official JDK6 have also been ported to OpenJDK6, so the current version is now fairly stable and should be comparable in quality to the official JDK.