Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment Re:Yes and? (Score 1) 88

C is, essentially, a good portable assembler. It's barely a compiler at all, which is why it could fit on really small 8-bit systems.

For that matter, Byte once ran an article where they implemented most of C in M68000 assembler macros, so that it ACUTALLY was assembler. It wasn't all of C, just most of it, and it was too clumsy to actually use (M68000 assembler code was as readable and much more efficient), but it worked.

For that matter, LifeboatC, an i8080 compiler, really was a translator from C to assembler (a translator, not exactly a compiler) to the point that if you knew what you were doing you could drop assembler instructions in the middle of your C code and have them work properly. It emitted assembler code or (I believe, it's been awhile) could directly build an executable. But C is much more similar to M68000 assembler than i8080 assembler, so LifeboatC was rather of a tour de force. It wasn't a full K&R C, but it was quite close.

So I consider C a portable assembler, and as such quite good. I don't think of it as a good compiler language. At this point in time a good computer language needs to handle unicode characters quite well. Vala has potentials, if it ever matures. Similarly D (Digital Mars D) has potentials. If you don't need speed, Python is a good choice. Soon a good computer language will also need to handle parallel processing gracefully...but so far I haven't seen any contenders for this. Even C will do it if you don't demand grace and elegance.

P.S.: I no longer consider assembler a reasonable thing to require...either of myself or of anyone who isn't implementing things at the hardware level. C is as close to that as I consider reasonable, and even C is limiting. The complexity of code anyone can write is limited, so any complexity you can push off onto your tools should be so pushed...unless you are a tool designer or builder, or, to a much lesser extent, evaluator.

Comment Re:Lies, damned lies, and statistics (Score 1) 203

Yes, but while the physicists admit that the "dark" things are error factors, they handwave about gravitons not being found when and how they were predicted. (OTOH, the orbital loss of energy fits the graviton equations just fine, so something really odd is going on. But I have my doubts as to whether it's gravitons as normally calculated. Perhaps the graviton is an unstable particle, but what could it break up into? For that matter, could that have any connection to "dark energy" and "dark matter").

I think the graviton is just as much a placeholder as is "dark matter" or "dark energy". All describe places where equations that normally work don't match what we see.

Comment Re:Wait a minute. (Score 1) 203

Well, it's one of the sorts of errors peer-review is supposed to catch. And I guess that in this case it eventually did. Compare this to free-market idealism which is also supposed to be caught (there is no free market, there never has been a free market, and it wouldn't even be meta-stable if it existed for an hour somewhere). But this is wiggled around by using terms that are not subject to observation or test. Peer-review is supposed to catch this kind of thing too, but it hasn't in the last 200 years. Too many people find it too attractive an idea, so objections are ignored and ill-defined terms are accepted, and so is lack of a decent experimental test. (I'm not even asking for a controlled test here.)

Because of this, economics is basically a form of theology. It's actually worse than metaphysics.

Comment Re:Why would anyone be shocked? (Score 2) 203

It would be *extremely* difficult to run controlled experiments in economics. For one thing, just try to find two identical populations to run your test on. There are *WAY* too many plausible variables.

N.B.: That doesn't mean I don't think that most economists are politicians grinding an axe. It means that the ones who are trying to do decent economics studies would have a really hard problem even if they weren't being drowned out in noise that's essentially theological.

Comment Re:ZFS is nice... (Score 1) 262

Uh, that doesn't work. The problem is that doing exactly what you've written down is contriving to avoid your copyright responsibility by deliberately creating a structure in someone else's work which you believe would be a copyright insulator. If you went ahead and did this (I'm not saying that you personally would be the one at Ubuntu to do so), I'd love to be there when you are deposed. Part of my business is to feed attorneys questions when they cross-examine you. I have in a similar situation made a programmer look really bad, and the parties settled as soon as they saw the deposition and my expert report. See also my comment regarding how Oracle v. Google has changed this issue. You can't count on an API to be a copyright insulator in any context any longer.

Comment Re:ZFS is nice... (Score 1) 262

I think you need to look at this in the context of the appeal of Oracle v. Google. We had a concept of an API being a boundary of copyright based on 17 CFR 102(b) and elucidated by Judge Walker's finding in CAI v. Altai. That stood for a long time. But Oracle v. Google essentially overturned it and we're still waiting to see what the lower court does in response.

Comment CDDL and GPL don't mix (Score 3, Informative) 262

Regardless of what Ubuntu has convinced themselves of, in this context the ZFS filesystem driver would be an unlicensed derivative work. If they don't want it to be so, it needs to be in user-mode instead of loaded into the kernel address space and using unexported APIs of the kernel.

A lot of people try to deceive themselves (and you) that they can do silly things, like putting an API between software under two licenses, and that such an API becomes a "computer condom" that protects you from the GPL. This rationale was never true and was overturned by the court in the appeal of Oracle v. Google.

To downgrade the human mind is bad theology. - C. K. Chesterton