Follow Slashdot stories on Twitter


Forgot your password?
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Re:The problem with neural networks (Score 1) 45

I don't mean to suggest that "anything goes" will become the motto of software testing(at least not more than it is today); but unless all the neural networks deliver extraordinarily erratic behavior despite all effort to the contrary, I agree that it will be a difference of degree(we will test them a lot more rigorously than humans); but not of kind(humans also experience 'edge case' behavior, whether it be an aneurysm hitting them at the hardware level, a psychotic break, a murder-suicide, some ill-conceived plan that involves plowing into a group of pedestrians, whatever).

We have less historical familiarity with these hypothetical computer systems, so we'll want to test them more carefully; but unless something makes them fundamentally more unknowable and unpredictable than people, my suspicion is that we'll decide to put up with some uncertainty if the alternative is not getting to use the new toys. We don't(and rightly so) put up with uncertainty in life critical systems merely because we want to save a few bucks or shave a few months off development; but if the only entrants are big, hairy, not-really-comprehensible designs that isn't the choice. It will be "you can have this now, or you can hope that we actually understand the problem at a much deeper level within not more than a few generations." There will be grumbling; but unless a real breakthrough allows us to have our toys and understand them, we'll opt for the toys.

Comment Re:Would prefer to know before the transplant. (Score 1) 13

Presumably depends on the location: major population centers or noted transplant hospitals can probably get the runner-up in pretty quickly(if they aren't already hospitalized because of the effects of needing a lung, there's nothing like the prospect of horrible death to get somebody moving); and presumably the ethics of not providing the original first-in-line with an organ that will kill him and giving it to #2 instead are pretty straightforward.

If the donor hits a tree and suffers massive head trauma out in some rural area, logistics may become considerably more challenging. Even for effectively unlimited money you can only get transport lined up so fast.

Comment Re:Can you do this pre-mortem? (Score 1) 13

My (layman's) understanding is that viability is a factor of interaction between the recipient and the donor organ, not merely a function of the donor, so would be tricky to label ahead of time.

For grafts where they have the luxury of (relatively) large amounts of time, and a non-fatal donation process(like bone marrow), they will screen for recipient/donor suitability ahead of time; but for donor organs where the donor is supposed to die first, time is very, very, limited and supplies are extremely tight. Much harder to preemptively do any substantial testing and a much greater incentive to shovel the organs into someone before they expire, since odds are good that that person won't get a second chance.

That's why this high speed method is so valuable: since the organs are so scarce, you don't want to waste one if it will just kill the patient anyway; but the clock is ticking from the time the organ becomes available until it becomes nothing but meaty medical waste.

Comment Re:Avoid INTERCAL (Score 1) 363

Avoid INTERCAL job postings at all costs.

So, you mean the fact that I wrote a c-intercal parser that used obscure opcodes to actually perform the interweave and or and xor isn't a good thing to put on my resume?

Also, my favorite obscure language is LIRL, and that has NOTHING AT ALL TO DO WITH ME BEING THE AUTHOR... rather, it's an interesting concept of, "what if Perl raped LISP and LISP was forced by the republican state government to carry that baby to term?"

The answer is: implied parentheses. To be clear, the language is absolutely context sensitive...

Comment Re:Actually, the common saying... (Score 1) 283

I ended up booting into DOS directly for most of these reasons.

Oddly, I barely even use 95... went straight from 3.x to 98. Where I still booted into DOS to do my gaming.

Ah... back in the day... I had to tetris my drivers to make sure I had enough conventional and XMS memory for the game I wanted to play... BOTH WAYS!

Comment Re:Sorry, but Apple still deserves most of the cre (Score 2) 283

Eject a disk by moving it from my desktop to the trash with all the files I want to delete? Makes sense.

Well, to understand this, you have to recall that early Macs had to be able to run off of a single floppy drive. Users might buy a hard drive or a second floppy drive (or if they had a dual-floppy SE, a third floppy drive for some reason) but it couldn't be relied on. Yet they still had to be able to tolerate having the OS disc ejected at times.

So there was a distinction between physically ejecting a disc while keeping it mounted (which was represented onscreen by a greyed out disc icon) so that you could copy to it, and both physically ejecting _and_ dismounting a disc.

The formal way that you were supposed to do this was by using menu commands. The Eject command was for eject-but-keep-mounted while the generally ignored Put Away command was for eject-and-dismount. It was also possible to use Put Away on an already greyed out, ejected-but-mounted disc icon.

User testing showed that this was inconvenient, and one of the OS developers eventually created a shortcut for the Put Away command, which was to drag a disc icon to the trash. It wound up being so popular that it shipped.

Apparently there had been some thought at the time about changing the Trash icon into some sort of Eject icon in the case of ejecting a disc, but apparently this was felt to be confusing or too difficult, so it wasn't done. In OS X the idea was revisited, and now the Trash icon does turn into a standard Eject icon when you're dragging a disc.

In any case, in real life, whatever confusion dragging disc icons to the trash might have caused, everyone got over it basically immediately.

Switching tiled applications makes the one menu bar change? Sure. It's not like moving the cursor half the screen for each click is a waste of time.

It's not; since there's nothing above the menubar, you can just slam the mouse up. It turns out to be faster and easier than having multiple menu bars. The Mac and Lisa groups did consider per-window menubars, but having tested the idea, it was rejected. For example, here's some polaroids of a screen from 1980 showing a Lisa with a menu attached to the bottom of a window: Later that year, the menu had moved to the top of the windows: And early the next year, it finally settled at the top of the screen:

Comment Re:What's the real problem? (Score 1) 196

For security purposes, it's not unreasonable to suggest that Mr. Big Picture Strategy Guy not be given read/write access to everything he is expected to be planning; that makes his credentials unbelievably valuable to an attacker and if he is in the position of needing to twiddle individual configurations all the time the organization hasn't actually made him the Big Picture Strategy Guy; but widespread read access would be a much harder request to reasonably deny: Anyone who is supposed to be strategizing needs to be able to see the world; and forcing him to wait 48 hours and work from a secondhand report compiled by minions every time he has a question about what the world looks like now is going to waste a lot of everybody's time.

Unless his mandate is strictly "Design us a new system so we can forklift upgrade this whole goddamn place!"(which would be deeply satisfying; but legacy infrastructure never dies that easily); expecting him to work in a black box is unrealistic; but he doesn't necessarily need(or even want to be stuck with) the ability to actually commit his proposed changes to every last widget out there.

In a five year period we can get one superb programming language. Only we can't control when the five year period will begin.