jd

Interesting study that leads to a mundane/obvious conclusion. In the final paragraph it says:

   These results go against some long held beliefs [...]
   that societies require specialisation to be productive
   and efficient. However, D'Orazio thinks that, at least 
   for biological purposes, the new model will set a
   standard for future work.

In the cookie shop example -- wouldn't you say that an employee who can both make and sell cookies is still very specialized? Two specializations perhaps, but specialized nonetheless. Even if you don't take the second order benefits (that having several specializations leads to better insight/productivity in both tasks) into account any model that claims that specializing in one single thing is the optimal division of labor is clearly wrong.

In math-speak: the commonly held belief is that for any society without division of labor you can get to a better/more productive society by introducing some version of division of labor. The belief was never that for any society you can get a more productive society by increasing the division of labor. (Obviously false because specialization itself bears a cost [education, etc] and the marginal benefit of additional specialization decreases the more specialized somebody is, therefore there must be a point where additional specialization is actually harmful instead of beneficial. This contradicts the claim that specialization is unconditionally good.)

Mathematical model: nice.

New or counter intuitive results: not as far as I can tell.

If you're worried about that you can always expire either when time limit is exceeded (say, 2 weeks) or download limit (downloaded 5 times?). Or you can make download times degrade when the file is downloaded more frequently -- the 100th download will go at 10kb/sec instead of 10mb/sec. There are so many creative solutions that you don't need to put any rules in place now.

Also, I think most of us (myself included) worry about abuse too much. If people start abusing your service you will have the data to deal with it effectively -- you'll think of a solution because you'll have to. And if it turns out people aren't taking advantage of a friendly download policy -- then the service ends up being more useful for honest users.

It also works like that in the Netherlands.

Thymer might just be what you're looking for.

It has intuitive data entry (easy as paper), support for projects, clearly seperates personal todos from work tasks. (So you can use the same todo system for personal matters and billable hours) and much more. Of course you can also generate reports (which you can customize to an extent). Focus on simplicity and usability -- drag and drop where possible, undo for every task, and so on.

Currently in private alpha -- beta coming soon. If you're interested, check it out at http://www.thymer.com

(In case it wasn't obvious -- this is a shameless plug)

Of course I wasn't searching for "catastrophe". I've read the book. It's better than the youtube clip.

Googled around - these are my findings.

1. The Fed publishes -several- press releases every day. They report on the most mundane issues (meeting times, etc) up to their financial decisions. So this event must have been mentioned in a press release.

2. The best match I found was this one: (http://www.federalreserve.gov/newsevents/press/monetary/2008...). If it is about the same event, they described the crisis as "elevated pressure in U.S. dollar short-term funding markets." Response: $180 billion dollar increase in swap lines by the Fed.

This press release was posted on Sept 18th this year, the date of the supposed catastrophe.

3. I couldn't find a single reputable news source or agency that even hinted at a possible catastrophe.

For your amusement, Google "federal reserve 550 billion" and watch the Ron Paul references fly by. Considering the lack of supporting evidence I think it's safe to say the world wasn't about to end on Sept 18th this year.

But the first definition doesn't make much sense does it?

For example: if you're in good shape you can run up a flight of stairs without any effort. But is getting in shape laziness? Not by any sane definition.

I'm sure you can think of a dozen other analogies, but they all illustrate the same thing: educating yourself, improving your tools, getting in shape are not laziness but the opposite.

And I think that's what original author meant. There is conflict between the definitions, and only the second definition indicates laziness.

The podcast covers unit testing and code quality at 45 minutes in or so. I haven't listened to the entire podcast, so I may have gotten this wrong, but it seems like Joel and Jeff made only nuanced statements. No unqualified remarks like "testing is bad" were made, I think.

Joel and Jeff mention that code quality doesn't matter much from a _business_ perspective. In Jeff's case - does the code quality of StackOverflow's internals matter? Probably not. There's no critical information there - so security is not an issue. It makes sense to me that time spent on features is going to be appreciated more by the users than time spent on code quality.

As for the unit tests - I don't think they mean to say that unit testing is a waste of time in general. From what I understand they're saying that unit testing isn't "real actual work". You write unit tests to save yourself debugging and regression testing effort later. If you consider unit tests intrinsically valuable you may end up writing tests for every getter and setter, and that's just a waste of time. They also mention that unit-tests themselves have to be maintained and updated, and if architectural changes break a significant percentage of unit tests then you have to put a lot of effort in fixing your tests.

The .NET framework was even mentioned as an example where high code quality is incredibly important and where all interfaces should be extensively unit- and regression-tested by Microsoft.

> I’m starting to wonder if anyone should be using any of their products.

So happy users of Fogbugz and StackOverflow should leave because Joel and Jeff are too pragmatic?

"Pirates of Silicon Valley" is -much- better than Triumph. Both are must-sees.

When you look at the bottlenecks in opcode throughput for virtual machines it's almost always lousy branch prediction. Using a branch table instead of a switch block is not going to make much of a difference in any realistic program. The CPU has no idea which function is going to get called next so it can never fully use all the advanced look-ahead mechanisms.

For those interested, look at all the performance improvements made in the ocaml and perl and clisp interpreters. There is a lot of low hanging performance fruit left in the Python interpreter - the question is whether it's worth plucking. For instance, python can get a dedicated accumulator (I don't think it has one now) and you can introduce new opcodes that combine functionality of frequently occurring opcode sequences. For instance, python now has a LOAD_CONST and BINARY_ADD instruction, but not LOAD_COST&ADD instruction like clisp.

By combining the functionality of two instructions into one you're essentially saving an opcode dispatch. Saving a jump is going to make a bigger difference than making a jump faster. So that's where I think the python guys should focus on if they really want to improve performance.

The build system on *nix. make, gmake, autoconf and related tools are really terrible.

1.

The cons here are pretty big. Your target customer is somebody who will solve most problems with google and 3 lines of bash/perl/etc scripting. The generic .NET software shop pays for this kind of software - *nix people don't.

I've written a few more paragraphs about this, and subsequently deleted them. It all really boils down to one thing: it's a bad idea. A lot of fun to write, but there's no money to be made.

2.

It's very hard to get any kind of competitive advantage here. If your idea works somebody else will do the same thing and charge less for the service. Also you will spend most of your time managing your (invariably unreliable) overseas contacts, leaving you no time to do anything else. This seems to be the kind of company that is fun in the beginning, and then turns into a nightmarish chore.

3.

I kind of like this idea. You have domain knowledge here, and already a few potential customers (or at least companies that can give you some feedback.) It's a niche, and there's still money to be made. Best idea so far.

I've been in the situation you've described (and I've been part of the problem). And yes, it can be really frustrating. Some teams don't work. And sometimes a single person makes or breaks a team. This is fascinating by itself, but a bit off topic.

The big difference is that online the reader to writer ratio is way different. Online, when somebody points out that a hash-map insert is amortized O(1) instead of O(1) hundreds or thousands of people benefit.

When the contractor tries to convince you that a scattered shower is different from a heavy mist (even though you're not in the least interested) nobody benefits. It's just noise.

I think that most people who are confrontational and critical online are just like that in person. People can be quite blunt face-to-face, and are perfectly OK with it when people are blunt to them. Blunt interaction has the big advantage that you never have to second guess what a remark means. Consider how many relations (between friends/colleagues/etc) break up because somebody reads too much in a simple remark. The most tactful people also tend to be those who (needlessly) worry the most about what other people say. I say this just from personal experience, so YMMV - but it's worth considering.

As for the Mr. Spock argument, I think that has a much more mundane explanation. I, like most people, read far more on the internet than I write. But when I read I read to learn. Therefore, I want to be reasonably sure what I read is correct. Because of the Mr. Spocks amongst us I can read the comments and use that to figure out if the blogger made any sense. More often than not the comments reveal serious flaws in the blogger's post. It is this interaction between blogger and Spocks that leads to better understanding. Both for visitors like me and the blogger.

So the Spocks fight against the pollution of the internet by incorrect statements%. It's a futile fight, but I believe it's a noble one. Frankly, I think posting uninformed and wrong comments is far more inconsiderate than pointing out to all future readers that such a comment is uninformed or wrong.

%) You called it an internet maxim in another post.

I think the "What about X" approach often comes across as condescending. It translates to "I figured out what's wrong with it in 2 seconds, but maybe, if I give you a few hints you'll see it too.". I've noticed though that people who don't like criticism (become defensive, etc) respond better to the "what about X" approach.

You suggest tactlessness should be dropped. But plain language is almost by definition tactless. Tact is something you add on top of your opinion/statement because you don't want to hurt somebody's feelings. Adding boilerplate tact is bound to give you poor results when it's not sincere. You're emphasizing the good parts merely because you don't want the other person to become defensive. Not because you think the good parts really need emphasis. When I use the "what about X" approach I often feel insincere because I can't directly get to the point. I end up respecting the person I'm talking to less for having to take the insincere route.

To give another example of boilerplate tact: often people advice to combine a compliment and a criticism with "and" instead of "but". Instead of saying "I like the layout, but I think that column should be wider"." you're supposed to say "I like the layout -and- I think that column should be wider". It's so obviously insincere.

I think it's pretty clever. The memory fragmentation caused by incessant consing leads to gc phase after gc phase. Their ORO trick prevents this, and as a bonus improves cache locality. They report they also have a true mark and sweep phase to take care of the corner cases.

Does their ORO scheme have any significant downsides?

Debunk misses the point of original article. It was a cache performance test. You'd expect almost identical performance in C# and C++ for the reasons the original author explained.

Original author responds: http://systematicgaming.wordpress.com/2009/01/04/performance...

I've seen how seriously some providers/hosting companies treat backups. Let's just say that deleting backups to free up space for new accounts was considered perfectly OK.

I completely agree it is something you -want- to outsource, because, exactly as you say, it's not something you want to spend time on. But you depend on your servers so completely that you become completely dependent on your provider.

What if your provider goes bankrupt? You'll have to move your server / move the data and nobody knows how it used to work. At that point you have very few options left. What if a tech decides to upgrade the kernel and the server doesn't boot anymore? Oops. In general, the linux techs aren't paid very well, are often overworked, are expected to fix problems at any point in the night and they don't particularly care about your server (no more than they care about the 100 servers next to it). Now add root access to the mix and watch what happens.

If nobody in your startup team knows how to administer a server then you're taking a risk. A big and unnecessary one.

ps: saying something like "an optimized Postgres install" makes no sense. Optimization is for specific tasks. So unless the techs know exactly what kind of queries you run they can't do much optimization. They can however, easily cripple sql performance.

The drop in replacement is slower than CPython. Likely to change in the future, but still.

Take a look at the PyPy FAQ. They're using annotations, type inference assumptions, and so on. PyPy seems to be focused on a Jit-able subset of Python. It's not a project that can one day be transparently included in the new Python release.

JavaScript and Python are not that dissimilar. So we see similar results with JavaScript. People want performance, so a lot of projects are started where people attempt to JIT JavaScript - but in the 14 or so years of JS's existence JavaScript is still several orders of magnitude slower than less dynamic languages. Java and C# have never been as slow as JavaScript is today. Will JIT-ing JavaScript help? Sure. But -great- results? I wouldn't go that far.

I've heard this claim several times, but there seems to be very little evidence to support it.

The fast native code Lisp compilers such as SBCL and Lispworks sacrifice correctness for speed. You can fully expect the VM to crash when you give incorrect hints to the compiler. This is obviously unacceptable for languages such as Ruby and Python. I don't know of any serious Lisp JIT compilers.

Smalltalk has never had decent performance as far as I know - not even with a JIT backend. Not compared to Java/C# with JIT compilation at least.

So yes, my claim is that languages such as Python and Ruby are inherently slower than languages such as C# and Java. The less information the compiler has to work with, the fewer optimizations can be made.

Python's implementation is focused on code readability. One of Guido's initial goals was that no matter how insane the input, the interpreter must never crash. His emphasis on simple and clear code (and an intuitive bytecode) gets in the way of performance.

The Ruby interpreter is quite terrible, but a lot of people are trying to make it better. Give it a couple of years.

Also, you imply that both implementations are really naive. They're not. With languages such as Python and Ruby there is much less to gain with JIT compilation than with Java. Suppose you have this Python program:

    def trivial(a, b):
        return a + b

What can the JIT optimize? The function call? Not always, because the function can be redefined during runtime (unlike with Java and .NET). Can the function be inlined? No. Can the function call frame be stack-allocated? Well, maybe, at a significant complexity cost: most scopes in Python are essentially closures so you have to treat carefully there too (upward funarg problems). Obviously the "+" function call can't be optimized much, because you don't know the types of "a" and "b". And even if you did it wouldn't help much.

Not done yet!

Even IF you optimize everything using the NBOCK (Non Braindead Omniscient Compiler Kit). Now you know that you're dealing with integers, and you know where the function is defined, and you know the function's definition is not going to change, and you know all function arguments can be declared locally and you know only integers will be passed to and returned from the function. Can you now transform it into a few MOV instructions? Alas, no.

Maybe the integers will overflow. And if they overflow you either want to throw an exception or allocate additional space and transform the integer to a heap-allocated large integer. (And you have to do all the necessary cache invalidation.)

So even if you are omniscient there is no low-hanging fruit. In the end even the logic of adding two integers is sufficiently complex that it warrants its own C function and inclining becomes only marginally useful.

When you take mundane issues such as maintainability, flexibility, and portability into account there are very few reasons left for building a JIT compiler for Python. Note that all these optimizations are viable (to an extent) with languages such as Haskell, C# and Java.

> You think that top software engineering graduates in New York City make $26k per year? Recalibrate! Recalibrate!

Oops, mental typo. Thanks for the correction.

I doubt it has a good ROI via recruiting, etc. Joel mentioned he spent more than a million on improving the interior design. No recruiting is going to make up for that, any time soon#. And in a few years Fog Creek will move to a different location again - at which point they'll have to build a new high end office.

So really, this seems to be a case of spending money to improve quality of life. The other benefits, such as for recruiting and PR are just a nice side effect.

#) Assuming 50 employees, over 5 years, the costs are roughly $4000 per employee per year. That's maybe 15% of their salary, probably less. Given the choice, I would probably give up 15% of my salary to work in a nice place with good food, a good view, good equipment, and so on.

The usual arguments against using money as motivation are that (a) money is not enough to keep you motivated during the "darkest of times" and (b) even if you get there the money will probably not make you happy.

But Mark Cuban _was_ motivated enough to take his company public. And Mark Cuban likes to make extravagant purchases (e.g. The Dallas Mavericks). In a nutshell - he seems to enjoy the billionaire's lifestyle. So money was probably the right motivational force for Cuban.

Also Recommended: Gates, by Manes and Andrews. It doesn't score high on a literary scale but it really captures the thrill of starting a company. It also covers the partnerships between MS and Apple without passing judgment.

By saying the universe has an arbitrary state before the Big Bang you're also assuming the universe has _a_ state before the Big Bang. But perhaps the universe had no state at all.

A variable is a piece of memory and always has _a_ value. The value may be arbitrary, the value may be unknowable, but we know at least one thing: that at any point in time a variable has exactly 1 value.

Quote:

   In fact, the most effective anti-piracy software development strategy is the simplest one of all:

   1. Have a great freaking product.
   2. Charge a fair price for it. 

Is he joking? The World of Goo is a great freaking product. And The World of Goo is fairly priced at $20. And yet the piracy rate is still at 82% or so. So where does Jeff base his "in fact" anti-piracy claim on?

What you're saying makes perfect sense, but that isn't what Yegge is saying at all. You're saying the state of the universe may or may not be sensible before the Big Bang, but it's unknowable so speculation is pointless. What Yegge is saying is that it's like an undefined variable: the state is totally arbitrary. But we don't even know if the universe could be anything before the Big Bang.

> But one way or another, all systems are embedded systems. [...] host systems often overlap and even cooperate. A city is composed of many interleaved subsystems. So is your body. It's not always a simple containment relationship. Systems are made of, and communicate with, other systems.

So now the definition of "embedded system" is essentially a "thingy". Thingies overlap and cooperate, thingies are made of and communicate with other thingies.

That's not very enlightening.

I have no idea what the purpose was of the 3000 (?) word analogy between Mario Cart, a fish tank and embedded systems. And also it's unclear how the "holes" (data channels) are related to reflection and metaprogramming.

And finally, I don't see how he can be so certain the state of the Universe was "undefined" before the big bang. Maybe the Universe had a definite and sensible but (to us) unknowable state before the Big Bang.