But it's nicer to walk than to drive. Plus, and many people are so inclined, you can go for a beer. As I say, why do you do this to yourselves? The answer "we're addicted to misery" isn't generous on insight;). Though perhaps it's true—the way you let your petty bureaucrats, the TSA, the guys at the social security office treat you, there's some support for it as a theory.
Well, ok, it's been a while since you had a free and fair election. At least on a bad day (or is that a good day) I don't believe either of the last two, either. But I'm serious about the risk aversion. The current administration is backed by a lot of powerful people, and its policy has been very much to move the clock back a century to the time of fighting wars over natural resources, a tried-and-true model that is well understood. The *AA situation is also about holding back the clock. In fact, the long and the short of it is that conservatism is fundamentally conservative, and even the American left is to the right of the other wealthy countries.
Two thoughts on this. First, yeah, why do you guys do that? What is it about Americans that they want their towns to be so mindbogglingly inconvenient? I don't know about you, but I like to be able to, I don't know, pop out for some milk and fresh tomatoes, stroll down to the fountain where the pretty girls walk by, go for a coffee or a beer or an ice cream, perhaps even walk to work! This is supposed to be a democracy—why build such misery for yourselves?
Second, HSTs, like aircraft, connect hubs, not suburbs. Starting and stopping works better than with a plane, but it still puts a hell of a dent in your average speed, which is your selling point. The population density of the US is more than a quarter of that of the EU; that means that the distance between hubs is on average only doubled—and the fact that there's nothing much happening in the midwest only argues in favour of trains by pushing up the density on the sides. Indeed, if we take the (sadly American) argument that we cannot take any risks and we can only deploy technology where we are sure it is justified, well, France has HSTs. If you need a population distribution like that of France to do this thing, then—if I read these maps right—there ought to be HSTs (and I mean like TGV, not Acela) from Boston to DC, from New York to Chicago, and within the states of California and Florida.
Of course, what's really going on is that America just doesn't do infrastructure, because the country is hung up on a psychological model of 'winning' against the 'competition' by holding back your neighbours. That's why businesses talk all the time about 'market share' and in times of difficulty fire R&D and boost marketing. If you built a train system, other people could use it! Perhaps even—OMG—poor people! Then how would I know I was better than them?
(And I'm not making this up. I'm living in San Jose and hearing what the people around me are saying about the light rail, the BART extension, the HST project.)
The fact that the second language is a "bytecode" is relevant in two ways:- (A) It has a well-defined, spatially and temporally stable, syntax and semantics. Have you looked at x86 assembler? (B) You want to do JIT for performance. You don't want to have to parse live object code to do this— especically if your verification is all knotted up with the target hardware semantics. Compilers have middle ends for a reason, and this is the reason.
As to the 'provably impossible'—how much real code have you looked at? How often do you actually see a loop for which there is no convenient termination proof? And how often was that deliberate? It's not a feature that has to work every time to be useful—the power of being able to verify critical cases at almost any cost in programmer effort is worthwhile, because the few critical components are, well, critical.
I'm guessing you're not old enough to know what I'm talking about. Unix acquired the (incredibly painful) termcap layer by backporting out of an application because it was to tat point so lame: it just gave you serial ports and left you on your own. Meanwhile, VMS already had a terminal emulation layer as the driver model for non-native terminals, so software could send VT-100 (thereafter ANSI) command sequences and be done. And modern Un*x terminal emulators do now use this DEC-originated-subsequently-standardised command set almost exclusively. Go and check.
In the old days there was an argument for VMS over Unix that terminal I/O was vastly simpler since the O/S would promise you a standard model—what started out as 'buy our terminals or you're SOL' evolved into 'we'll fake it in the driver if we have to.' In the end, while you never see physical terminals anymore, all the many Un*x software terminal emulators are now emulating VT100s, because it was really the right answer.
Now, this may sound like Microsoft bashing, but I can't help it. I've asked senior engineers at video card companies you've heard of, "I know there's lots of complexity here, but seriously, why isn't there a proper virtualisation layer for all this stuff?" and been told "because Microsoft say they will not certify our drivers any more if we ship one." Anything well-enough specified to be useful to developers could be ported to other O/Ses, you see.
Perhaps Microsoft are slowly changing—people who work there say that they are (even over beer, I mean)—but they have done a lot of harm by their intimidation and systematic opposition to responsible engineering practices (such as documented long-term stable interfaces).
I know this isn't the whole story—as you point out, simply characterising capacity for a PC and its rendering subsystem is an immense challenge—but it's a huge factor. A properly coordinated OpenGL with major O/S vendors insisting on commonality of interface and providing serious, uniform infrastructual support in exchange—that would have been a fine thing. A different corporate culture could have taken us there.
Aargh. Look, we're not talking about the compiler, we're talking about the bytecode verifier. Of course the compiler "carefully constructs" the loops to have the properties they are supposed to have! The bytecode verifier is there to make sure that the compiler isn't lying, and thus it's safe to link the code into the runtime system and execute it. So of course you need to "do that in the first place"—first, because you didn't want an infinite loop unless you wanted an infinite loop (compilers should be correct, d'uh); second, because you don't want malicious code to actually get executed (which was the point of the thread, and once again, d'uh).
Now, there's a sensible argument to be had about whether we want source languages with type systems expressive enough to talk about things like termination properties and deadlock freedom. I'd assert that of course we do and it's about bloody time, but I agree that most programmers are too lackadaisical to even care whether their code is correct, much less have to prove it, and most managers are too stupid to understand that there's a cost/benefit tradeoff between correctness and programmer effort exerted; so I might not win in the marketplace. But it's not sensible to claim that this is a technical constraint on the runtime, or in some sense a waste of effort, or that it won't "work" because this simply isn't true (and it should be obvious that it isn't because, as I pointed out before, we are talking about proof checking not proof generation).
This is all out there in the research literature for you to read... and has been for over a decade.
Of course it can't, "comprehensively." I must say I utterly don't understand the responses I am getting to my comment; it's as if people imagine that the job of a type checker is to derive all possible types that an expression might have. It isn't; it's merely to validate that the claimed proof of the claimed properties of an expression applied.
Think about it. How likely is it that I would have been that I meant what you are pretending I said? Would you design a language that appears to have infinite loops and then outlaws them in the type system (even if that were feasible, which it obviously isn't)? No; you would either design from below a language without nonterminating constructs, or you would design from above a language with greater expressive power, and then verify the properties that each program is supposed to have (which might or might not include termination). In either case, the proof checker is straightforward.
Nobody said you had to solve the halting problem. Sometimes a loop obviously terminates, and sometimes a proof can be supplied along with the code and all the runtime has to do is verify it. We were talking about bytecode condition verifiers, remember, not bytecode all-possible-property provers!
You are wrong. You cannot in general decide in finite time whether a loop is infinite or not, but you can definitely (a) prove that some loops terminate (e.g. "for (i = 0; i almost all practical computation. (The only obvious thing it fails for is writing its own verifier.)
Well, look, this is a weird thing. As a language researcher, the idea of having such VMs as targets is very exciting, but it rests on the assumption of them not being total crap, and we all know that, in practise, this isn't going to happen. To take your example of bytecode verification: you say, well, processes and hardware checks deal with illegal instructions already. Ask a language theorist, and they will say, sure, but bytecode verification can check things like:
there are no infinite loops
your password is not leaked
network protocols are obeyed
your locking discipline is correct
and not only that, but these and all the 'usual' process isolation guarantees can be made without context switch overheads: your code can be fused right into the kernel and run with higher security and reliability than ever before. While your point is taken, your standards of verification and efficiency are way below those of the research literature. (Of course, this is theoretically true of machine code, too, but these verification mechanisms are so intense to write that you really, really want to share all the work among all the target environments, not to mention that you do not want to have to scan and interpret the gnarled object code of most CPUs.)
In reality, however, the virtual machines that are actually deployed are broken in just the same way that the programming languages and operating systems we see deployed are broken in the eyes of researchers: they don't reach far enough. And unfortunately, global robustness properties are all-or-nothing; unlike notation design, there's no half way point where you grit your teeth, ignore the features that are more broken, and use the tool available. One single misfeature destroys the integrity of the edifice.
When it was announced that the Java VM would be bytecode verified and sandboxed, the research community rejoiced, because we thought we were hearing that from smart people and not marketing droids, and it would be true. But somewhere along the line people started adding 'features' without asking the architects about consequences. Such 'real world' VMs tend to get (or be able to get) unfiltered access to the native file system, to choose a random example, and they do it in the absence of a general security verifier (a thing that is, admittedly, much more technical and harder to get right than a mere JIT compiler). 'Useful' in the same way that casting integers to pointers is 'useful': of course, people use it every day, they don't know how to get by without it—but so long to the high ideals of the project.
Fortunately it's 2^128, not 2^64. If it were only 2^64, it wouldn't be future proof at all. You are right, we have to take 34 bits off the top just to index all the users. Actually, we probably have to take 40 bits off the top, if that's what we're doing, because of the administrative haggling problem—different countries always want pre-allocated blocks. Then, of course, people are born and die, form companies with separate identities, and want multiple address spaces for reasons of privacy.
But leaving all that aside, I now have 24 "personal" bits. In reality, I'm not going to assign 2^24 addresses manually; they're going to be allocated by various address allocation mechanisms, and we're going to need a registry of those mechanisms. That's going to take 4, maybe 8 bits to figure out. Ok, so we've got 16 bits left to play with. Now, my plan for the future is to make every single interconnect in every single device with electronics in it serialised, packet-structured and IP-like. Let's give them all addresses. We'll start with macroscopic objects: the light switches in your house, the light bulbs in your car, the sensors in your appliances and burglar alarms, (in an ideal world, an address for each book you own to help you find it, but perhaps that's science fiction), the speakers in your sneakers, the subdevices in your phones and games and music players and so on. Now of course, for your computers. Each of them can soon be expected to have around 1024 processors for graphics and physics, an array of, I don't know, let's call it 8 storage devices at each of 3-8 levels of a storage hierarchy, each composed (for packaging reasons) of 16-64 subdevices. Now we need to take all of that and double it twice because there are logical devices as well as physical devices to contend with. Oh, and we want multicast and anycast addresses for talking to classes of devices. And there are networks! Thousands, perhaps millions, of microscopic routers and switches are gluing this together. They need management addresses at the very least. And, of course, hardware vendors want statically pre-assigned blocks of addresses so they don't have to connect manufacturing directly to a global bureaucracy—and most of them get to around serial number 3 before they go belly up, but they don't give the addresses back because they're still technically an asset in some financial limbo.
And I said that books were science fiction, but maybe not. There's this nice convenient 'large' address space there for the allocating, let's use it with RFID and give a separate address to every can of beans. But we ran out of bits long before doing the beans, if you go back and count.
I didn't even get to the route consolidation problem, and (for mathematical reasons) that would like to eat half the bits off the top. In IPv6, roughly speaking, it does.
See, it was by asking the question 'how many computers can there possibly be?' that we got the fiasco that is IPv4 addressing. The questions we need to ask, are (a) by what processes can address be allocated, and (b) what things are potentially addressable.
Fortunately these questions were asked this time, and 128 bit IPv6 addresses result. I do worry (see above) that it might not be enough—not because we are going to manufacture 2^128 physical objects (though 2^64 network addressable logical objects will happen in my lifetime), but because addresses, in reality, are not serial numbers but little packed data structures.
One final thing I should point out: when I say this, people tend to respond, well, but you're assuming that everywhere is like America. No, I'm not. America is 'developed'—it's given up on deploying infrastructure, its corporate interests are allergic to new ways of doing things. The developing world is still adopting new ideas. The 'developing' world will be studded with cities that make Shanghai and Seoul look old-fashioned within the lifetime of IPv6, and there's some reasonable probability that they will have network addressable buttons, disposable paper T-shirts, balloons (fingers crossed for these being recyclable...). They likely won't be in America, though, because America has already been told what can't be done.
I think you slept through your biology class (or perhaps you went to school in America, where the policy seems to be to lie). In any case, the theory of evolution does not say that the smartest ought to survive; it does not even say that the smartest do survive. It says that those who do survive have the offspring. Even if, for example, they're two feet tall, have no legs, and are as dumb as posts. It's a simple differential equation that (superficially) does naive hill-climbing. We can paraphrase it like this: the survivingest survive. (Sounds simplistic? That's why evolution isn't a mere theory; it isn't even a law. In truth, it's a theorem.)
And if you think that it's somehow implausible that morons and dropouts should have 'real' survival potential (as opposed to 'fake' potential within some socialist pseudo-environment, is I guess what you're thinking, though in what sense the real world is not the real world I can't, I admit, quite grasp), I need only point out to you the President of the United States of America.
Yep. The toppest top monkey of all the top monkeys is an idiot. A grinning face really is all you need, and evolution has apparently got it right again. As measured by success.
[In the graduate level version of this rant we talk about the really interesting mechanisms that genetics has evolved to tunnel good ideas past local aberrations so that they can resurface after periods of transient weirdness. That's the real good stuff of evolution, the metarecursive part, and oddly enough it's the thing that even the 'pro' evolution camp don't seem to want to talk about—but unfortunately you need to know about things like coding theory to understand it, not just differential equations and Big Numbers. Good grief, why are you sub-200-IQ types breeding? With a better chosen population, you'd all find this obvious. It's only a little harder than rocket science!]
You should also add "working around fraudulent, malicious or incompetent 'copy protection' schemes wherein the DMCA is employed as a legal protection of 'snake oil.'" To me, this is the single largest issue: it's stupid to overemphasise the rights of corporate copyright holders at the expense of the citizens, but to pass a law that simply saying that something is a copy protection or encryption scheme makes it so is exactly like legislating that for some purposes pi is 3.
I... think you should travel more. Europe isn't like this. Canada isn't like this. The US is the outlier. The American media perhaps portray it differently, but living there you just don't have the sense that there's just one Boss and he's a lunatic. Speaking from personal experience.
[Cowards: this is not intended as a personal attack. But still...]
You know, it's fascinating. I say, "good god, y'all, don't let the guilty go free, just jail the crooked cops!" and I consistently get the reply "can't be done, corruption is endemic." And this, apparently, from the same population who keep whining about the corruption of the evil Chinese. Wake up, America! You've fallen off the first world!
I think there's a huge confusion in the way people think about this. The prevailing attitude seems to be that the purpose of law is to make money, and that various traps need to be in place to prevent the police making too much money and unbalancing the game.
That's not what law is about.
This person broke the law and was caught. There is no doubt (or no more doubt than usual) that he should be convicted. It is absurd to dismiss any evidence on the basis of how it was obtained—unless the method calls the evidence itself into doubt (entrapment, planted evidence and evidence obtained under torture—which may be very much the same thing—are the obvious examples).
But at the same time professional malfeasance is a very serious thing. A policeman who breaks the law or a records officer who doesn't bother filing an update or a database programmer who takes a job of this seriousness and screws it up—whatever the cause of the confusion—should be in very serious, spend-time-in-prison, trouble. The situation where both the crook and the crooked cop wind up incarcerated is very far from unacceptable.
In California, at least, they've already got the message as regards roadworks: penalties for traffic infractions are doubled as you pass the workers. Let's start doubling the penalties for crimes committed in the course of work, and quadrupling them for those acting as officers of the state.
Of course, this strategy could backfire. I scraped by as a research compiler writer because I was not going to work flipping burgers. Later, I moved to a foreign country when I couldn't find work where I was living. I, too, may be a trifle bigoted when reading the resume of someone who takes jobs that I would expect to make a normal candidate commit suicide from boredom. But it so happens that I practise what I preach.
An alternative strategy might be to explain what was going on. I used to know a mathematician who liked to work in a bucket factory. She said, "It's great! The work is totally mindless, so I can focus on my research." Not my cup of tea, but at least I understand. So what's really the story behind this job?
Oh, and if you say, 'the money,' you lose on two counts. First, I want employees who have some passion for things beyond cash. And second, well, if that is the motivator, aren't there higher paying jobs out there?
Of course, I'm not really so arrogant. I understand that the real world is, well, real. But I wouldn't use up my last chance insulting the interviewer. Not if I wanted to get out of tech sup. Even if you are frustrated and no longer want the job, I should think "I'm afraid I made a mistake in coming here," would do nicely.
Do you know, when I was a kid, pictures of naked children were socially acceptable (after all, kids often didn't wear clothes on the beach, and everyone washes their own kids, right? So you're not seeing anything you haven't seen a thousand times before), and pictures of naked adults were not (because that's just not... right). I think this establishes that, yes, it is possible to ask some questions here. You'll note that I'm not trying to imply any particular answers, but then while politically I oppose the abuse of anyone, my sexual tastes run only to adult women, so I'm hardly in a position to judge this with any sensitivity.
Think. Think is good. Think of the adults, think of the children, think of the society we are trying to engineer, but please, couldn't we try to think?
No matter where the right and wrong lie, you can't build justice out of knee-jerk reactions, and egging people on to visceral responses makes you one of, to be blunt, the enemy. Because, you know, it's that kind of unthinking action on the basis of hormones that we are supposedly trying to fight when we jointly choose to try to limit people's proclivities.
I'm amazed! This is Slashdot, and here I was all ready to do what I usually do: stick my oar in and say, guys! Forget the technology angle, there's an important policy issue here—we should be restricting car use to the competent, not extending it to the incompetent! And what do I find? That's what everyone is saying! Will marvels never cease?
Unfortunately, there's a show-stopping technical issue here that everyone is—quite surreally—overlooking. Use GPS to tell people about roadsigns? What if GPS mis-reports your location? What if you're in a tunnel? What if there's construction? What if, for heaven's sake, the bridge is out, and the sign and the road are not there? Building a system in which people control physical weapons (sorry, vehicles) based on information from an ungrounded virtual reality is criminally insane!
Now, putting directional transponders on road signs so they can identify themselves clearly and reproduce themselves on in-vehicle displays is such an obvious idea that I've been expecting to see it announced as reality at every car show for 35 years. It's an absolutely must-do, supervising-officials-must-be-suicidal-morons-to-miss-it (or evil geniuses up to no good to pretend to miss it) sort of thing. Of course we want that. But it has to be very reliable. Over 99% reliable, because unlike physical street signs, the failure modes aren't ones that we can fix by moving the signs or adding flashing lights. And it has to be a solution that applies to flares and bollards and temporary signage just as smoothly as it does to fixed signage. Use GPS?
I don't, in fact, disagree with you very intensely, and yes, perhaps I spoke too strongly. I do think that there is a real current trend away from teaching subjects according to their own self-determined core values and towards what politicians and industrialists would like, and I truly believe this to be short-sighted, damaging, and not particularly justified by education theory, historical experience, or much else. That's not quite the same as me wanting to launch into untested didactic waters without a lifeboat. And while I agree that 'not born to it' may have been a careless choice of words, I think the genetic and early childhood components are undeniable, and often wish we could get back to the state before technical bookshops filled up with XYZ for Dummies, as if being a Dummy in a field were something to be proud of; because yes, there are those with talent and there are those with determination and they are not always the same people, but equally there are those with neither, and they are not going to succeed at a thing. It remains that for someone to be so unable to relate to Bourbaki (not merely, 'hm, I don't learn well this way,' or 'interesting in historical context but not the way of the future,' or 'not really a textbook but a technical movement masquerading as a textbook' but 'everybody stay away at all costs!'), leads me to believe that, well, this person will have a lot more fun doing something applied.
And I say that as someone who (a) has themselves learned that they have more fun in computing than in pure maths and (b) is very interested in alternate technical developments, alternate methods of presentation, and, well, finding new and different items for the mental toolkit.
Of course Bourbaki isn't the 42. But if someone in the field doesn't respect it, well, that's a little like a biologist dissing Darwin and telling people not to pay attention to him. Yes, mathematicians get to criticise Bourbaki and biologists get to criticise Darwin. They can and they should, or they won't get very far (and indeed wouldn't get much respect from Darwin or Bourbaki). But let's consider the context and the technical meat when we do it, rather than descending to the level of "Five Reasons Bourbaki Is The Worst Thing You'll Ever Read."
I think perhaps you weren't born to be a mathematician. I seriously wish that some of my profs would have STFU'd about the applications and focused on the proofs and proof techniques. If you are studying biology, do you really want half your class hours devoted to what plants look nice in a garden? (Maybe you do, but if so, study gardening instead.) If you are studying software architecture, should the textbook assume that what you really care about is, I don't know, writing keyboard scanners? (Again, you might, but then why not buy a different book?) And do you want your general psych class turned into a course on methods of military indoctrination? It doesn't matter the field, I think we'd benefit from a lot less focus on applications and a lot more on mastery of content. Mathematics most of all, because the cultural content of mathematics is the collection of tools for thinking about pure problems, abstracted from any problem domain. Indeed, the best advances in mathematics come, it seems to me, from abstracting internal mathematical tools away from their original mathematical focus, and thereby making them available to the whole subject, and not just one small field.
As to issues with how theorems are referred to, I think this brings us to the root of the Bourbaki phenomenon. The cult of personality is not so productive in a field whose content is supposedly objective, and naming results after people is a barrier to objectivity in understanding and a barrier to communication. My girlfriend is Chinese. Do you suppose she knows, or cares, about Green's theorem or Taylor series, under those names? But five seconds with a pencil and paper and we are in sync.
Mathematics is not automotive mechanics and it is not pop music! And—I don't mean to be rude here, in making a cultural observation—that was a particularly hard lesson for French academia in particular—though for France we needed to write "it is not the civil service and it is not religion."
Interestingly enough, if you buy a DVD in Canada, you get the FBI warnings, too (it's also region 1). Now that is obnoxious: having a foreign power drool all over your movie watching experience and making like their laws have some bearing. At least in the States you can sit back with some satisfaction and say, yup, I sure used my votes wisely!
Slashdot Mirror
But it's nicer to walk than to drive. Plus, and many people are so inclined, you can go for a beer. As I say, why do you do this to yourselves? The answer "we're addicted to misery" isn't generous on insight ;). Though perhaps it's true—the way you let your petty bureaucrats, the TSA, the guys at the social security office treat you, there's some support for it as a theory.
Well, ok, it's been a while since you had a free and fair election. At least on a bad day (or is that a good day) I don't believe either of the last two, either. But I'm serious about the risk aversion. The current administration is backed by a lot of powerful people, and its policy has been very much to move the clock back a century to the time of fighting wars over natural resources, a tried-and-true model that is well understood. The *AA situation is also about holding back the clock. In fact, the long and the short of it is that conservatism is fundamentally conservative, and even the American left is to the right of the other wealthy countries.
Well, good God, it's as America as I can take. Living in Chicago was more than I could stand.
Two thoughts on this. First, yeah, why do you guys do that? What is it about Americans that they want their towns to be so mindbogglingly inconvenient? I don't know about you, but I like to be able to, I don't know, pop out for some milk and fresh tomatoes, stroll down to the fountain where the pretty girls walk by, go for a coffee or a beer or an ice cream, perhaps even walk to work! This is supposed to be a democracy—why build such misery for yourselves?
Second, HSTs, like aircraft, connect hubs, not suburbs. Starting and stopping works better than with a plane, but it still puts a hell of a dent in your average speed, which is your selling point. The population density of the US is more than a quarter of that of the EU; that means that the distance between hubs is on average only doubled—and the fact that there's nothing much happening in the midwest only argues in favour of trains by pushing up the density on the sides. Indeed, if we take the (sadly American) argument that we cannot take any risks and we can only deploy technology where we are sure it is justified, well, France has HSTs. If you need a population distribution like that of France to do this thing, then—if I read these maps right—there ought to be HSTs (and I mean like TGV, not Acela) from Boston to DC, from New York to Chicago, and within the states of California and Florida.
Of course, what's really going on is that America just doesn't do infrastructure, because the country is hung up on a psychological model of 'winning' against the 'competition' by holding back your neighbours. That's why businesses talk all the time about 'market share' and in times of difficulty fire R&D and boost marketing. If you built a train system, other people could use it! Perhaps even—OMG—poor people! Then how would I know I was better than them?
(And I'm not making this up. I'm living in San Jose and hearing what the people around me are saying about the light rail, the BART extension, the HST project.)
The fact that the second language is a "bytecode" is relevant in two ways:- (A) It has a well-defined, spatially and temporally stable, syntax and semantics. Have you looked at x86 assembler? (B) You want to do JIT for performance. You don't want to have to parse live object code to do this— especically if your verification is all knotted up with the target hardware semantics. Compilers have middle ends for a reason, and this is the reason.
As to the 'provably impossible'—how much real code have you looked at? How often do you actually see a loop for which there is no convenient termination proof? And how often was that deliberate? It's not a feature that has to work every time to be useful—the power of being able to verify critical cases at almost any cost in programmer effort is worthwhile, because the few critical components are, well, critical.
I'm guessing you're not old enough to know what I'm talking about. Unix acquired the (incredibly painful) termcap layer by backporting out of an application because it was to tat point so lame: it just gave you serial ports and left you on your own. Meanwhile, VMS already had a terminal emulation layer as the driver model for non-native terminals, so software could send VT-100 (thereafter ANSI) command sequences and be done. And modern Un*x terminal emulators do now use this DEC-originated-subsequently-standardised command set almost exclusively. Go and check.
In the old days there was an argument for VMS over Unix that terminal I/O was vastly simpler since the O/S would promise you a standard model—what started out as 'buy our terminals or you're SOL' evolved into 'we'll fake it in the driver if we have to.' In the end, while you never see physical terminals anymore, all the many Un*x software terminal emulators are now emulating VT100s, because it was really the right answer.
Now, this may sound like Microsoft bashing, but I can't help it. I've asked senior engineers at video card companies you've heard of, "I know there's lots of complexity here, but seriously, why isn't there a proper virtualisation layer for all this stuff?" and been told "because Microsoft say they will not certify our drivers any more if we ship one." Anything well-enough specified to be useful to developers could be ported to other O/Ses, you see.
Perhaps Microsoft are slowly changing—people who work there say that they are (even over beer, I mean)—but they have done a lot of harm by their intimidation and systematic opposition to responsible engineering practices (such as documented long-term stable interfaces).
I know this isn't the whole story—as you point out, simply characterising capacity for a PC and its rendering subsystem is an immense challenge—but it's a huge factor. A properly coordinated OpenGL with major O/S vendors insisting on commonality of interface and providing serious, uniform infrastructual support in exchange—that would have been a fine thing. A different corporate culture could have taken us there.
Aargh. Look, we're not talking about the compiler, we're talking about the bytecode verifier. Of course the compiler "carefully constructs" the loops to have the properties they are supposed to have! The bytecode verifier is there to make sure that the compiler isn't lying, and thus it's safe to link the code into the runtime system and execute it. So of course you need to "do that in the first place"—first, because you didn't want an infinite loop unless you wanted an infinite loop (compilers should be correct, d'uh); second, because you don't want malicious code to actually get executed (which was the point of the thread, and once again, d'uh).
Now, there's a sensible argument to be had about whether we want source languages with type systems expressive enough to talk about things like termination properties and deadlock freedom. I'd assert that of course we do and it's about bloody time, but I agree that most programmers are too lackadaisical to even care whether their code is correct, much less have to prove it, and most managers are too stupid to understand that there's a cost/benefit tradeoff between correctness and programmer effort exerted; so I might not win in the marketplace. But it's not sensible to claim that this is a technical constraint on the runtime, or in some sense a waste of effort, or that it won't "work" because this simply isn't true (and it should be obvious that it isn't because, as I pointed out before, we are talking about proof checking not proof generation).
This is all out there in the research literature for you to read... and has been for over a decade.
Of course it can't, "comprehensively." I must say I utterly don't understand the responses I am getting to my comment; it's as if people imagine that the job of a type checker is to derive all possible types that an expression might have. It isn't; it's merely to validate that the claimed proof of the claimed properties of an expression applied.
Think about it. How likely is it that I would have been that I meant what you are pretending I said? Would you design a language that appears to have infinite loops and then outlaws them in the type system (even if that were feasible, which it obviously isn't)? No; you would either design from below a language without nonterminating constructs, or you would design from above a language with greater expressive power, and then verify the properties that each program is supposed to have (which might or might not include termination). In either case, the proof checker is straightforward.
Nobody said you had to solve the halting problem. Sometimes a loop obviously terminates, and sometimes a proof can be supplied along with the code and all the runtime has to do is verify it. We were talking about bytecode condition verifiers, remember, not bytecode all-possible-property provers!
You are wrong. You cannot in general decide in finite time whether a loop is infinite or not, but you can definitely (a) prove that some loops terminate (e.g. "for (i = 0; i almost all practical computation. (The only obvious thing it fails for is writing its own verifier.)
Well, look, this is a weird thing. As a language researcher, the idea of having such VMs as targets is very exciting, but it rests on the assumption of them not being total crap, and we all know that, in practise, this isn't going to happen. To take your example of bytecode verification: you say, well, processes and hardware checks deal with illegal instructions already. Ask a language theorist, and they will say, sure, but bytecode verification can check things like:
and not only that, but these and all the 'usual' process isolation guarantees can be made without context switch overheads: your code can be fused right into the kernel and run with higher security and reliability than ever before. While your point is taken, your standards of verification and efficiency are way below those of the research literature. (Of course, this is theoretically true of machine code, too, but these verification mechanisms are so intense to write that you really, really want to share all the work among all the target environments, not to mention that you do not want to have to scan and interpret the gnarled object code of most CPUs.)
In reality, however, the virtual machines that are actually deployed are broken in just the same way that the programming languages and operating systems we see deployed are broken in the eyes of researchers: they don't reach far enough. And unfortunately, global robustness properties are all-or-nothing; unlike notation design, there's no half way point where you grit your teeth, ignore the features that are more broken, and use the tool available. One single misfeature destroys the integrity of the edifice.
When it was announced that the Java VM would be bytecode verified and sandboxed, the research community rejoiced, because we thought we were hearing that from smart people and not marketing droids, and it would be true. But somewhere along the line people started adding 'features' without asking the architects about consequences. Such 'real world' VMs tend to get (or be able to get) unfiltered access to the native file system, to choose a random example, and they do it in the absence of a general security verifier (a thing that is, admittedly, much more technical and harder to get right than a mere JIT compiler). 'Useful' in the same way that casting integers to pointers is 'useful': of course, people use it every day, they don't know how to get by without it—but so long to the high ideals of the project.
Fortunately it's 2^128, not 2^64. If it were only 2^64, it wouldn't be future proof at all. You are right, we have to take 34 bits off the top just to index all the users. Actually, we probably have to take 40 bits off the top, if that's what we're doing, because of the administrative haggling problem—different countries always want pre-allocated blocks. Then, of course, people are born and die, form companies with separate identities, and want multiple address spaces for reasons of privacy.
But leaving all that aside, I now have 24 "personal" bits. In reality, I'm not going to assign 2^24 addresses manually; they're going to be allocated by various address allocation mechanisms, and we're going to need a registry of those mechanisms. That's going to take 4, maybe 8 bits to figure out. Ok, so we've got 16 bits left to play with. Now, my plan for the future is to make every single interconnect in every single device with electronics in it serialised, packet-structured and IP-like. Let's give them all addresses. We'll start with macroscopic objects: the light switches in your house, the light bulbs in your car, the sensors in your appliances and burglar alarms, (in an ideal world, an address for each book you own to help you find it, but perhaps that's science fiction), the speakers in your sneakers, the subdevices in your phones and games and music players and so on. Now of course, for your computers. Each of them can soon be expected to have around 1024 processors for graphics and physics, an array of, I don't know, let's call it 8 storage devices at each of 3-8 levels of a storage hierarchy, each composed (for packaging reasons) of 16-64 subdevices. Now we need to take all of that and double it twice because there are logical devices as well as physical devices to contend with. Oh, and we want multicast and anycast addresses for talking to classes of devices. And there are networks! Thousands, perhaps millions, of microscopic routers and switches are gluing this together. They need management addresses at the very least. And, of course, hardware vendors want statically pre-assigned blocks of addresses so they don't have to connect manufacturing directly to a global bureaucracy—and most of them get to around serial number 3 before they go belly up, but they don't give the addresses back because they're still technically an asset in some financial limbo.
And I said that books were science fiction, but maybe not. There's this nice convenient 'large' address space there for the allocating, let's use it with RFID and give a separate address to every can of beans. But we ran out of bits long before doing the beans, if you go back and count.
I didn't even get to the route consolidation problem, and (for mathematical reasons) that would like to eat half the bits off the top. In IPv6, roughly speaking, it does.
See, it was by asking the question 'how many computers can there possibly be?' that we got the fiasco that is IPv4 addressing. The questions we need to ask, are (a) by what processes can address be allocated, and (b) what things are potentially addressable.
Fortunately these questions were asked this time, and 128 bit IPv6 addresses result. I do worry (see above) that it might not be enough—not because we are going to manufacture 2^128 physical objects (though 2^64 network addressable logical objects will happen in my lifetime), but because addresses, in reality, are not serial numbers but little packed data structures.
One final thing I should point out: when I say this, people tend to respond, well, but you're assuming that everywhere is like America. No, I'm not. America is 'developed'—it's given up on deploying infrastructure, its corporate interests are allergic to new ways of doing things. The developing world is still adopting new ideas. The 'developing' world will be studded with cities that make Shanghai and Seoul look old-fashioned within the lifetime of IPv6, and there's some reasonable probability that they will have network addressable buttons, disposable paper T-shirts, balloons (fingers crossed for these being recyclable...). They likely won't be in America, though, because America has already been told what can't be done.
I think you slept through your biology class (or perhaps you went to school in America, where the policy seems to be to lie). In any case, the theory of evolution does not say that the smartest ought to survive; it does not even say that the smartest do survive. It says that those who do survive have the offspring. Even if, for example, they're two feet tall, have no legs, and are as dumb as posts. It's a simple differential equation that (superficially) does naive hill-climbing. We can paraphrase it like this: the survivingest survive. (Sounds simplistic? That's why evolution isn't a mere theory; it isn't even a law. In truth, it's a theorem.)
And if you think that it's somehow implausible that morons and dropouts should have 'real' survival potential (as opposed to 'fake' potential within some socialist pseudo-environment, is I guess what you're thinking, though in what sense the real world is not the real world I can't, I admit, quite grasp), I need only point out to you the President of the United States of America.
Yep. The toppest top monkey of all the top monkeys is an idiot. A grinning face really is all you need, and evolution has apparently got it right again. As measured by success.
[In the graduate level version of this rant we talk about the really interesting mechanisms that genetics has evolved to tunnel good ideas past local aberrations so that they can resurface after periods of transient weirdness. That's the real good stuff of evolution, the metarecursive part, and oddly enough it's the thing that even the 'pro' evolution camp don't seem to want to talk about—but unfortunately you need to know about things like coding theory to understand it, not just differential equations and Big Numbers. Good grief, why are you sub-200-IQ types breeding? With a better chosen population, you'd all find this obvious. It's only a little harder than rocket science!]
You should also add "working around fraudulent, malicious or incompetent 'copy protection' schemes wherein the DMCA is employed as a legal protection of 'snake oil.'" To me, this is the single largest issue: it's stupid to overemphasise the rights of corporate copyright holders at the expense of the citizens, but to pass a law that simply saying that something is a copy protection or encryption scheme makes it so is exactly like legislating that for some purposes pi is 3.
I ... think you should travel more. Europe isn't like this. Canada isn't like this. The US is the outlier. The American media perhaps portray it differently, but living there you just don't have the sense that there's just one Boss and he's a lunatic. Speaking from personal experience.
That's interesting. I understand that, and I still don't understand it. Maybe some brain cells died since I was at school.
[Cowards: this is not intended as a personal attack. But still...]
You know, it's fascinating. I say, "good god, y'all, don't let the guilty go free, just jail the crooked cops!" and I consistently get the reply "can't be done, corruption is endemic." And this, apparently, from the same population who keep whining about the corruption of the evil Chinese. Wake up, America! You've fallen off the first world!
I think there's a huge confusion in the way people think about this. The prevailing attitude seems to be that the purpose of law is to make money, and that various traps need to be in place to prevent the police making too much money and unbalancing the game.
That's not what law is about.
This person broke the law and was caught. There is no doubt (or no more doubt than usual) that he should be convicted. It is absurd to dismiss any evidence on the basis of how it was obtained—unless the method calls the evidence itself into doubt (entrapment, planted evidence and evidence obtained under torture—which may be very much the same thing—are the obvious examples).
But at the same time professional malfeasance is a very serious thing. A policeman who breaks the law or a records officer who doesn't bother filing an update or a database programmer who takes a job of this seriousness and screws it up—whatever the cause of the confusion—should be in very serious, spend-time-in-prison, trouble. The situation where both the crook and the crooked cop wind up incarcerated is very far from unacceptable.
In California, at least, they've already got the message as regards roadworks: penalties for traffic infractions are doubled as you pass the workers. Let's start doubling the penalties for crimes committed in the course of work, and quadrupling them for those acting as officers of the state.
(Probably help a lot with the economy, too.)
Of course, this strategy could backfire. I scraped by as a research compiler writer because I was not going to work flipping burgers. Later, I moved to a foreign country when I couldn't find work where I was living. I, too, may be a trifle bigoted when reading the resume of someone who takes jobs that I would expect to make a normal candidate commit suicide from boredom. But it so happens that I practise what I preach.
An alternative strategy might be to explain what was going on. I used to know a mathematician who liked to work in a bucket factory. She said, "It's great! The work is totally mindless, so I can focus on my research." Not my cup of tea, but at least I understand. So what's really the story behind this job?
Oh, and if you say, 'the money,' you lose on two counts. First, I want employees who have some passion for things beyond cash. And second, well, if that is the motivator, aren't there higher paying jobs out there?
Of course, I'm not really so arrogant. I understand that the real world is, well, real. But I wouldn't use up my last chance insulting the interviewer. Not if I wanted to get out of tech sup. Even if you are frustrated and no longer want the job, I should think "I'm afraid I made a mistake in coming here," would do nicely.
Do you know, when I was a kid, pictures of naked children were socially acceptable (after all, kids often didn't wear clothes on the beach, and everyone washes their own kids, right? So you're not seeing anything you haven't seen a thousand times before), and pictures of naked adults were not (because that's just not ... right). I think this establishes that, yes, it is possible to ask some questions here. You'll note that I'm not trying to imply any particular answers, but then while politically I oppose the abuse of anyone, my sexual tastes run only to adult women, so I'm hardly in a position to judge this with any sensitivity.
Think. Think is good. Think of the adults, think of the children, think of the society we are trying to engineer, but please, couldn't we try to think?
No matter where the right and wrong lie, you can't build justice out of knee-jerk reactions, and egging people on to visceral responses makes you one of, to be blunt, the enemy. Because, you know, it's that kind of unthinking action on the basis of hormones that we are supposedly trying to fight when we jointly choose to try to limit people's proclivities.
I'm amazed! This is Slashdot, and here I was all ready to do what I usually do: stick my oar in and say, guys! Forget the technology angle, there's an important policy issue here—we should be restricting car use to the competent, not extending it to the incompetent! And what do I find? That's what everyone is saying! Will marvels never cease?
Unfortunately, there's a show-stopping technical issue here that everyone is—quite surreally—overlooking. Use GPS to tell people about roadsigns? What if GPS mis-reports your location? What if you're in a tunnel? What if there's construction? What if, for heaven's sake, the bridge is out, and the sign and the road are not there? Building a system in which people control physical weapons (sorry, vehicles) based on information from an ungrounded virtual reality is criminally insane!
Now, putting directional transponders on road signs so they can identify themselves clearly and reproduce themselves on in-vehicle displays is such an obvious idea that I've been expecting to see it announced as reality at every car show for 35 years. It's an absolutely must-do, supervising-officials-must-be-suicidal-morons-to-miss-it (or evil geniuses up to no good to pretend to miss it) sort of thing. Of course we want that. But it has to be very reliable. Over 99% reliable, because unlike physical street signs, the failure modes aren't ones that we can fix by moving the signs or adding flashing lights. And it has to be a solution that applies to flares and bollards and temporary signage just as smoothly as it does to fixed signage. Use GPS?
Sorry, my brain just exploded.
I don't, in fact, disagree with you very intensely, and yes, perhaps I spoke too strongly. I do think that there is a real current trend away from teaching subjects according to their own self-determined core values and towards what politicians and industrialists would like, and I truly believe this to be short-sighted, damaging, and not particularly justified by education theory, historical experience, or much else. That's not quite the same as me wanting to launch into untested didactic waters without a lifeboat. And while I agree that 'not born to it' may have been a careless choice of words, I think the genetic and early childhood components are undeniable, and often wish we could get back to the state before technical bookshops filled up with XYZ for Dummies, as if being a Dummy in a field were something to be proud of; because yes, there are those with talent and there are those with determination and they are not always the same people, but equally there are those with neither, and they are not going to succeed at a thing. It remains that for someone to be so unable to relate to Bourbaki (not merely, 'hm, I don't learn well this way,' or 'interesting in historical context but not the way of the future,' or 'not really a textbook but a technical movement masquerading as a textbook' but 'everybody stay away at all costs!'), leads me to believe that, well, this person will have a lot more fun doing something applied.
And I say that as someone who (a) has themselves learned that they have more fun in computing than in pure maths and (b) is very interested in alternate technical developments, alternate methods of presentation, and, well, finding new and different items for the mental toolkit.
Of course Bourbaki isn't the 42. But if someone in the field doesn't respect it, well, that's a little like a biologist dissing Darwin and telling people not to pay attention to him. Yes, mathematicians get to criticise Bourbaki and biologists get to criticise Darwin. They can and they should, or they won't get very far (and indeed wouldn't get much respect from Darwin or Bourbaki). But let's consider the context and the technical meat when we do it, rather than descending to the level of "Five Reasons Bourbaki Is The Worst Thing You'll Ever Read."
I think perhaps you weren't born to be a mathematician. I seriously wish that some of my profs would have STFU'd about the applications and focused on the proofs and proof techniques. If you are studying biology, do you really want half your class hours devoted to what plants look nice in a garden? (Maybe you do, but if so, study gardening instead.) If you are studying software architecture, should the textbook assume that what you really care about is, I don't know, writing keyboard scanners? (Again, you might, but then why not buy a different book?) And do you want your general psych class turned into a course on methods of military indoctrination? It doesn't matter the field, I think we'd benefit from a lot less focus on applications and a lot more on mastery of content. Mathematics most of all, because the cultural content of mathematics is the collection of tools for thinking about pure problems, abstracted from any problem domain. Indeed, the best advances in mathematics come, it seems to me, from abstracting internal mathematical tools away from their original mathematical focus, and thereby making them available to the whole subject, and not just one small field.
As to issues with how theorems are referred to, I think this brings us to the root of the Bourbaki phenomenon. The cult of personality is not so productive in a field whose content is supposedly objective, and naming results after people is a barrier to objectivity in understanding and a barrier to communication. My girlfriend is Chinese. Do you suppose she knows, or cares, about Green's theorem or Taylor series, under those names? But five seconds with a pencil and paper and we are in sync.
Mathematics is not automotive mechanics and it is not pop music! And—I don't mean to be rude here, in making a cultural observation—that was a particularly hard lesson for French academia in particular—though for France we needed to write "it is not the civil service and it is not religion."
Interestingly enough, if you buy a DVD in Canada, you get the FBI warnings, too (it's also region 1). Now that is obnoxious: having a foreign power drool all over your movie watching experience and making like their laws have some bearing. At least in the States you can sit back with some satisfaction and say, yup, I sure used my votes wisely!