wwalker3

If I know that an author doesn't want me to copy his book, I won't copy it. It's not a matter of law or monopoly, it's just politeness.

It's a reiteration of a sentiment I've seen a lot recently: "My livelihood doesn't depend on copyright, so I'll feel free to violate yours."

Are people really so unconcerned about the livelihood of others? Each of us is already free to give away the fruits of our own labors -- but why insist that others must do the same?

I apologize for any offense. I don't mean to imply that all "backwoods Christians" are really baffled by Hinduism -- I also know some of the type you mention, the serious students who learn ancient Greek.

I was using the "backwoods Christian" stereotype to make a point in a (hopefully) humorous way, that people who are totally wrapped up in their own worldview often completely fail to understand the point of other worldviews, and don't even realize they're missing the point.

For what it's worth, I was raised in the back woods, and grew up around the kind of people I caricatured (who were thankfully always a minority). But since intent is hard to convey on the Internet, it would have been wiser for me to use talking animals like Aesop, or something else less likely to offend.

Lambda the Ultimate discussing object-oriented programming is like backwoods Christians discussing Hinduism. "What do them folks need all them gods for anyways? An' that one Krishna, why's he look like a blue baby? Ah guess some folks'll believe anything!"

It just seems pointless to constantly profess such dismay and amazement at how clueless other peoples' programming paradigms are. Is there anyone who really doesn't believe there's more than one self-consistent, sensible way to write code?

Not quite the same. Your Mazda shift lever's manual slot doesn't disappear when you're in automatic. You can still sign a draft contract, it's just not binding.

In the software case you explained, the interface changes so you can't even try to do the wrong thing. On real-world objects, you can always try to do the wrong thing, it just doesn't work.

This is a mind-blowing and cool idea as others have said, but the idea of an object whose methods change depending on their internal state is a bit counter-intuitive.

Real-world objects don't have this property -- it would be like the gas tank hatch disappearing from my car after I fill it up, and reappearing once I drive around for a minute.

I think this objection still misses the point. In my vector rotation example, a vector object's internal state is just three floating-point numbers. Even for this simple and well-understood object, "v.rotX( 30 ); v.rotY( 30 );" can give a different internal state than "v.rotY( 30 ); v.rotX( 30 );".

However, I do agree with you that it's easy for bad programmers to create objects that are counter-intuitive and difficult to understand. It's up to the programmer to insure that an object isn't encrusted with dozens of badly-thought-out methods with no obvious paradigm for how to use them.

The author's objection to data encapsulation seems to be that for an object X, the internal state produced by "X.a(); X.b();" may be different from that produced by "X.b(); X.a();".

But this behavior is exactly what makes an object. Programmatic objects are supposed to be analogous to real-world objects. If I shift my car into first gear, then turn the key to start the engine, I get very different results than if I do the reverse.

Even abstract mathematical objects like vectors and matrices work this way. If I rotate a 3D vector twice, the final direction it points depends on the order I do the rotations in.

This looks like an assembler that writes out byte code that a virtual machine runs (where that VM also supports just-in-time optimization and garbage collection). There seem to be a bunch of these for the Java VM that convert "Java assembly code" into valid .class files (http://tinf2.vub.ac.be/~dvermeir/courses/compilers/javaa/ for example).

An interesting idea -- I work with Java and C# every day, but I never thought of writing assembly code for the JVM or .Net VM.

The original seems to be from the Walter and Eliza Hall Institute of Medical Research at http://www.wehi.edu.au/education/wehi-tv/.

I've never seen such a detailed and beatiful animation of this process -- I need to do more research to see how the detailed molecular motions were figured out.

It would be hard to create truly "functional" hardware. A piece of hardware is a real physical object with an internal state which is shared by all accessors and which can change over time. Shared, modifiable state is the exact opposite paradigm from the one that pure functional languages use.

I think this is also why pure functional languages are so hard for "normal" people to understand -- their basic premise is the opposite of the real world around us that's filled with stateful physical objects.

"Time travel" is real, but the only thing you can do is slow down relative to others. The way you describe is a valid method, though some might quibble that it's the accelerations involved that slow down time for you, rather than simply the movement at a high velocity.

You can also "time travel" by moving to an area of higher gravity (per general relativity). Time travels more slowly for you there, so you can let your original location get ahead of you, then go back there to effectively travel to "the future".

Of course, gravitational time dilation is a tiny effect, so you'd have to get near something unhealthy like a black hole to notice much difference.

A common thread to these Malthusianisms is that you can't understand dynamic phenomena by assuming they're static.

Something like the number of hours in a work week isn't just a fixed number; it's got a history behind it and driving forces on it that are needed to make sense of its current and future values.

Aaronson implies that he thinks about these situations by trying to figure out what Nash equilibrium they might settle to, but I think even that concept's not general enough. In the real world, people don't make their minds up once and then stay the same afterwards -- they'll change their behavior over time, and not always towards any equilibrium state.

That's exactly my point -- NaCl would make languages and tools available to web app developers which have already proven their worth in developing complex, graphically intense application interfaces on the desktop.

Perhaps you're replying to a different comment than the one I made? I was talking about the difficulty of creating complex, responsive user interfaces in JavaScript. NaCl (if it works out) seems to open another path for developing interface-heavy apps for the web.

Once technologies like Google's Native Client take off, the web browser becomes merely the installer and updater for my native app.

And it'll be none too soon -- then we can abandon the doomed effort to somehow cobble together huge, powerful apps like Maya and Photoshop out of a mess of JavaScript and XML.

I think Atwood's point that many people are putting unpaid effort into sites that may benefit others is sound. I just don't think it's a calamity, since the time being put in is mostly spare time that the donors aren't expecting payment for.

I'm not sure if the sharecropper analogy holds up. Sharecroppers essentially rent land, paying the landowner back with a share of the crops grown on it. Assuming the crop doesn't fail, both the cropper and the landowner make money.

On most web sites that aggregate user content, the content contributors make no money, and often the web site doesn't either (e.g. Wikipedia, YouTube, Facebook). These are more like online collaborative hobbies, where everyone involved is doing it just because they enjoy it and have some time to spare.

And it's easy to cheat in bartering -- just don't tell the other party that your goods have some hidden flaw.

If I barter you my old laptop that crashes when you leave it on more than an hour, you're going to be mad later when you find out I didn't tell you, and you'll have to appeal to a third party for justice if I'm bigger or stronger than you.

If your code has no bugs, the problem you're attacking is too easy for you.

The best programmers are working on problems that no one knows how to solve yet.

The ratio of things we know to things we don't know is essentially zero. Thankfully that doesn't preclude us from dreaming big and accomplishing great things.

I think the completely comprehensible system has always been an illusion. There's always some cutoff level below which people don't understand (or don't care to understand) the system they're working in.

The old Apple 2 hackers had a great understanding of assembly, but that's because it was the top level of the system to them, the stuff they worked with daily. I doubt most of them understood the PLA that decoded the instructions, or the behavior of the dynamic NMOS logic inside the 6502.

The 6502 instruction set was essentially the API of the processor, and it wasn't above reproach any more than current software APIs are. Many people wished for different addressing modes or additional instructions to simplify common coding tasks.

I agree that the physical printing of news on paper is becoming quaint, but having less print isn't what worries me, it's having less news.

I want to read stories about events all over the world and their meanings, context and history. I want those stories to be written by experts whose full-time job is tracking those stories down and explaining them to me. People like that have to get paid, and it's not clear yet how that's going to happen in the post-newspaper future.

There's always a demand for this sort of news, so I'm sure new businesses will spring up in the future to supply it to me. But it's going to be an annoying few years while it gets sorted out.

I totally agree with these guys that getting out the soldering iron and working on real hardware is satisfying as hell.

But ironically, many hardware engineers like me spend all day writing what's essentially software (Verilog code) and running it in a simulator (VCS). Eventually we send a binary file (GDSII) that represents the chip layout off to the fab, and though we do get real chips back from Taiwan, most of us never lay hands on them.

A very interesting essay about using some types of mathematical surfaces in architecture. The architect chooses surfaces with useful properties, like being able to walk between any two points without turning upside down, and uses them as floors, walls, and ceilings of buildings.

One question he didn't address was why he couldn't just create arbitrary surfaces out of NURBs or some other type of spline. It seems like that would give an architect greater freedom to mold things to his liking, instead of choosing predefined functions and playing with the free parameters. Perhaps he just likes the aesthetics of the rheotomic surfaces?

I can understand this guy's frustration, but he could have better spent his effort commenting the rest of the file properly.

Out of 500 lines, about 30 lines are spent on the rant, and there are almost no comments of any significance anywhere else, not even a file header to explain what the class is and how it should be used.

It's immoral to tempt someone into harming themselves, especially when it also benefits you.

Payday loans tempt the weak with options that help in the (very) short run, but harm in the long run.

The very existence of payday loans encourages self-destructive habits among the poor. Why budget carefully when you can just get a payday loan and kick the can down the road to next month?

And since many payday loan customers get these loans every month, the loans are really just an additional monthly bill for poor people.

I guess it's a simulator in that the bond angles and lengths dynamically rearrange as you add new atoms or yank on existing ones. I'm not sure the results are accurate (compared with density functional theory, Hartree-Fock, etc.), but it looks pretty cool. I assume it's doing some sort of force-based algorithm with an integrator.

Great hackers create great works from within, not from their tools or their environment. Their core competencies are things like relentless self-improvement, not the use of a particular editor or a particular OS.

The author's list of core competencies (fast typing, command line, vim, Linux) sounds more like a list of cultural traits.

Thanks for the clarification, Igor -- my knowledge of this is second-hand, from a friend's description of an interesting project he's working on. I had never heard of compressive sampling or convex optimization before that, and it was eye-opening to see what's possible.