If you read the link you originally posted (or at least, tried to post), you discover the same tired and false arguments that tax "protesters" use to claim that the federal income tax does not apply to them, or to just about anyone.
The argument that the federal government only has the power to levy taxes in the zone of its "exclusive jurisdiction", meaning only D.C. and some American possessions, for instance, is completely ludicrous. It is taken as "proof" that almost everyone born in the 50 states is not a citizen for tax purposes.
If you think for just a moment about how much effort goes into developing the tax code by Congress, do you really think that they are doing all this work, sending out all these forms, for something that only applies to maybe one or two million people? Every single member of Congress, who *write* these laws, believes they apply to everyone born in the 50 states. If they made some technical error (given that the 16th amendment actually was ratified, disagreeing with another quite spurious argument from your source), they would have repaired it.
If you don't want to pay taxes, then don't. But don't claim that some tortured reading of the tax code or Constitution or Bible justifies it.
In case you missed it, the link I pointed to also mentioned judges levying multi-thousand dollar fines on people "buggering the courts up" with frivolous arguments wasting everybody's time.
Face reality: the U.S. government has the power to levy taxes on your income and require you to fill out the 1040 form accurately. Not doing so opens you up to all sorts of legal penalties. I suppose if you also knew a bunch of old bank robbers, you'd tell us we should all take our pistols into bank offices and make money the brave way and tax free, too. Didn't you hear? The laws against bank robbery weren't written in the right color ink....
Why don't you go off somewhere and square the circle with a compass and straightedge?
One reason Bermuda is "nice" is that their laws on corporate governance favor management over shareholders much more strongly than American laws do. It's virtually impossible for a shareholder lawsuit to succeed against a Bermuda corporation.
On the other hand, IANA corporate lawyer or tax attorney. BTW, it's the Cayman Islands.
Well, that's perhaps nice in some situations, but the guy probably checked it out for some reason, for instance, to make changes? And he didn't check it back in for some reason, for instance, he wasn't done making changes? And his half-done changes might not be the best thing to put in the code because they might cause more problems than you are ready to deal with anyway.
This C++ template container approach is preferred *within the context of C++*. If you choose C++, then preferring template containers is a no-brainer, and I agree with Stroustrup that templates are essential, even though they were designed in relatively late in the C++ game. That says nothing about what design choices make sense before you have chosen your language of implementation.
One of the problems is that C++ design (and to a lesser extent Java design) require you to create these type and class heirarchies in order to be able to get the compiler to allow you to express your program. When inheritance is the only way to explain restrictions and relationships to the compiler, you end up doing a lot of inheritance.
In more dynamic languages, your class heirarchies can often be a lot less elaborate. You can express type checks that cross inheritance boundaries with ease. In the most difficult cases, in languages like CLOS you can create your own meta-classes that allow you to express things in ways other than inheritance.
Look, if you are dealing with a team that has not divided responsibility for design decisions according to a clear system, then that is your real problem, not the lack of compile-time diagnostics. You're also going to get huge numbers of bugs that the compiler *won't* catch.
The problem with C++ in particular is that it is a bondage-and-discipline language. Everyone on your team has to figure out in advance what chains and barriers are going to be put up in order to allow the problem to be solved within the C++ language.
In a dynamic language, you *choose* what barriers to put in place in order to maintain safety. You aren't forced to put a lot of barriers up that will never be needed.
Also, what people miss is that in Lisp, for instance, a run-time error usually puts you in an interactive debug environment, allowing you to make changes to the program (still alive) using the full power of the Lisp language, and the full resources of your program, in order to find the problem, fix it, and continue execution. This is just now coming to pass in the C++ world, with incremental compilation, etc., but Lisp programmers have had this for decades. When you are developing, you will find the errors, and for production, you can write error handlers that catch these various conditions, log them as appropriate, and specify how execution should continue.
The strategies you use with a dynamic language to prevent and deal with these kinds of problems are different than with static languages like C++. The strategies aren't better or worse, just different. What you gain with dynamic languages is a kind of flexibility that allows you to attack the problem, not the language, and to do so with a maximum payoff for programmer effort. What you gain with C++ is the ability to catch certain types of errors, which aren't really that common, especially as intellisense-type tools are becoming much more widespread. Much of the time, when the compiler complains about type mismatches, you add a cast. The language is forcing you to explain yourself again, not really pointing out a logic error in your program.
The real problems that programmers face are errors of logic, which no language can address, and the ability to express the desired operation, which dynamic languages make much easier than static languages, because they don't require as much unnecessary or redundant description.
However, it's much less flexible than most dynamic languages because your Object is not shared with any other class heirarchy. Unless everyone who might need your stack is willing to inherit from your Object, then they can't fit your mold.
This whole compile-time vs. run-time error business is a red herring.
When you say getting an error at compile-time is better, you are just saying that C++ ensures that your program fits in the straitjacket that you made for it, ignoring the fact that you've made a straitjacket in the first place!
Making a stack which is "int only" is totally specialized. How are you "accidentally" going to write code that asks for something else, if your problem is so focussed that it only needs ints? You really think that using strings by mistake is going to be a major source of bugs?
The real problem is that C++ operations are type-specialized at compile time. C++ compilers, for instance, don't know how to add numbers unless they know the type at compile time. In a dynamic language, the addition operator knows how to add whatever numbers it sees at run-time.
For every set of bugs that a compile-time error catches, there is a corresponding set of desirable program behaviors that become more difficult to explain to the compiler. That's why the whole idea of "design patterns" caught fire in the C++ world. These design patterns are like a phrase book translating your desire into the C++ language. If you have a more flexible language, you don't need a phrase book as often!
For sure. Actually, your sig encapsulates the advantages nicely:
if (!signature) throw std::runtime_error("No sig!");
The template version would give a compile-time error instead - type-safe and no need to to runtime error handling!
Only if the signature presence had to be determined at compile time. How flexible is that?
Re:What I want to know - We need benchmarks!
on
Virtual PC 6 Review
·
· Score: 3, Informative
Actually, I would think that disk access tends to *equalize* emulators with real hardware. After all, your disk access is probably limited by disk latency and bandwidth, and the hard disk on your emulating machine shouldn't be that much slower than the real thing. Furthermore, the data from the hard disk is not going to need much translation between platforms.
What would kill speed is a task where the real processor to be able to execute with code and data both in cache. The emulated processor has to fit the relevant emulator code, emulated processor state, JIT-compiled emulated code, and the program data all in the host machine cache to have any chance at all of keeping up. [Note that Connectix requires L3 cache on the Mac to get the advertised speed improvements.] Even then, the inner loop of JIT-compiled code is probably not as optimized as an inner loop that makes heavy use of processor-specific quirks.
Video speed depends on how well the emulator maps the video calls to hardware on the emulating machine. Virtual PC does not do that for 3D.
With hard drive space so cheap, why not pre-load all kinds of software, each with a unique encryption key (varies for software, computer) and let the user call in with a credit card number to get the key for the software?
This has been tried. I think one of the main problems is that the software gets out of date. Six months from now, there is a new version. You don't want people to keep buying the old version that came with their hard drive. The other problem is probably keeping up with changes at the computer vendors as they upgrade their product mix. The release of a new OS install becomes a retail software situation, and the system probably isn't set up well to do that. Deadlines are hard enough to meet without some marketing-type guy having to update the contract with the software supplier.
From a user perspective, OS upgrades become more difficult. You want to keep all those unused software archives when getting a new hard drive or OS? A hassle.
I'd like to pick up older games like Full Throttle or Sam & Max, or the Infocom collections, without relying on eBay
I don't think this is likely to fly. Most programs, games especially, are not particularly future compatible. Porting software to Mac OS X is feasible with Carbon, but isn't automatic. As soon as you ask for money, you are setting up expectations that the program will actually work, not just on museum-piece hardware.
Think about how little software from the Mac OS 7 era still works on OS 9, much less OS X. There's always some glitch (doesn't work on HFS+ volumes, had some weird implementation of heirarchical menus, etc.)
If the owner of these old games hasn't seen fit to update them for the new platform, this kiosk isn't going to make that much difference in the economics. You still need to pay the developers to go over the code to eliminate bit-rot, for a market that is probably very small.
The main benefit is for retailers, who don't have to keep inventory and shelf space for lots of Mac titles, when they hardly have space for the PC titles they want to carry.
That's a very interesting question. I'm not sure there is a very compelling answer, however.
Some of it is simply fashion: as C grew in popularity, it simply overtook Pascal in the new APIs that were developed. Once Pascal interfaces to the Mac OS became second-class citizens, there was no reason to favor it.
Another part of it is that Pascal was originally a teaching language, meant to indoctrinate structured programming. It deliberately tries to hide machine or OS-level reality with an idealized abstraction. It was not meant as a flexible all-purpose language like C. You couldn't write an OS kernel in Pascal very easily. One specific area in which it lacks flexibility is type conversion. For pointer or scalar (enum & integer) types, it really wants you to pick one type and stick with it. Good for enforcing discipline on software engineering students learning to design structured data types, poor for hackers who need to deal with the not-so-disciplined reality.
Another area where it lacks is file I/O. The standard doesn't really define byte-level results of its file operations, so reading/writing files compatible with other languages/API's depends on vendor extensions, which aren't uniform.
Similarly for structure layout. Although it isn't 100% defined, you can usually convince any C compiler on a given platform to agree with any particular arrangment of bytes in a structure. It's much harder with Pascal. This means that no matter what your OS, C code can be written mostly independent of compiler vendor, or at least with the nastiness hidden in header files.
Pascal also has a pretty inflexible (perhaps a bit clumsy) structure for writing your own libraries (units). In C implementations, you write a bunch of routines, a header file for users to #include, and make a.o file, and you are most of the way there. I.e., any program that doesn't have "main()" defined yet is a library waiting to happen. In Pascal, it is just slightly less convenient.
There are also a couple of omissions. I believe many implementations did not allow functions to return structure types. That's what drove me to C from Pascal many years ago. I believe arbitrary length arrays are also a bit clumsy to work with (not like C where you can have null-terminated arrays and use pointer arithmetic to navigate). Polymorphic types & pointers are clumsier in Pascal (no void* to ignore the differences when you want to.)
In general, Pascal works fine if you are writing a single application that requires only interfaces & libraries that your compiler vendor knew about. TeX by Knuth is an example. His programs (at least of that era) are monoliths, not collections of libraries and interfaces. You need to tweak a few routines to work with a particular vendor/platform, and that's only because Knuth very consciously made it that way.
Once you start working with libraries from multiple sources, the Pascal model begins to strain.
The Pascal folks would say that "Extended Pascal" plus OS-specific extensions in most compilers allow you to overcome all of these. But the extensions only happened after C began spreading like a virus, helped by its exposing all the weaknesses in Pascals that lacked full extensions.
I think the ability of (West) Germany and Japan to recover from fascism/military dictatorship (perhaps Japan's democracy is not the best example of "functioning," but I'll grant you that) after WWII had very little to do with the nuttiness of their wartime leaders, and much more to do with internal societal factors.
Germany and Japan both had been through the Enlightenment---Germany with the rest of Europe, and Japan during the Meiji period---so they were already essentially Western in outlook. They had developed mature, industrial economies.
Japan was a remarkably cohesive society, able to adapt to American occupation (as they had to Western civilization) with remarkably little disruption.
Germany was rebuilt under three-power occupation, with heavy infusions of aid coming through the Marshall plan.
The post-WWII period witnessed something near to a miracle in its ability to bring West Germany and Japan back into the Western world, although we take it for granted now. (Although we still haven't let Germany or Japan be a permanent member of the UN Security Council....)
In Iraq, virtually no aspect of the society (other than their relatively secular outlook) gives much hope that any kind of "democracy" could take root there. Neither does the likely quick exit with minimal financial support (oops, "forgot" the Afghan aid in our budget) the Bush administration will look for after the smoke settles.
Iraq is one of the *least* fundamentalist and *most* secular societies in the Middle East. Currently, it is possibly the least likely to be affected by fundamentalists. An Iraq without a functioning government would certainly be a more fertile area for al Qaeda to recruit.
I'm not defending Saddam Hussein as a sane or even tolerable human being, but your argument is a strawman. Sure, a functioning liberal, secular democracy in Iraq *might* improve things for the Iraqi people (or, it might elect Osama bin Laden as Supreme Leader). But the chance of the U.S. producing a functioning liberal, secular democracy in Iraq is near zero.
Asking if the UN is going to "back up" recent resolutions that were only passed because the US wanted them is a silly question. The UN has inspectors, and they are doing what they can. Are you going to ask the UN to "back up" the numerous "Zionism is racism" resolutions with concrete action as well? Talk is talk and action is action. Don't get the two confused.
The reason the UN is useful is it gives the small countries of the world a stake in the system, and a way to make it feel like they can restrict the actions of the few (one) powerful countries. In the absence of the UN, the countries of the world will feel compelled to group together, excluding the U.S., in order to balance the overwhelming power of the U.S.
Look at what happened to Germany when Bismarck was no longer around to reassure the weaker powers that Germany was not a threat---eventually, every other country was so nervous that they set themselves up to start World War I, which wasn't good for Germany.
Nixon understood, for instance, that China and Russia together would pose too great a geopolitical opponent to U.S. dominance. So he cultivated better relationships with each than they had with each other.
The current administration seems to think that we can offend everybody and basically bully them into being allies because we are on the side of "good." No one else in the world believes, as Bush apparently does, that it is our Christian duty to provide "God's gift" (if it's really God's gift, then why can totalitarians take it away?) of Liberty to the Iraqis.
When we sit back and think that even little countries, not even mentioning China or North Korea, have more resources than al Qaeda, and therefore pose more of a potential threat than this apparently all-consuming menace, we realize that the U.S. has the most to lose in the absence of international order.
Is the U.S. going to occupy the whole Middle East as soon as our huge presence in Iraq gives a oh-so-inviting target for terrorists? Or is the U.S. going to run away from the mess it creates, leaving a cesspool for Islamic fundamentalists?
I think you underestimate the rational basis for "growth" company valuation.
It is true, that in the absence of dividends, which was almost the definition of "growth stock" during the bubble, it is hard to see why holding a stock is worth anything. There is, however, a floor on the value of the stock, which is that some other company could buy 51% of the stock and collect the profits as if they were dividends. Also, at some future time, the growth will slow down, and the company will start to pay dividends as their sector has matured. In the meantime, they ought to be investing their cash in expansion, or get left behind.
The thing that leads to irrationality is when the future revenue growth rates are overestimated, either for the particular company, the overall market segment, or both. Being overly optimistic on the future cash flow in an exponentially growing way greatly increases the present value. A classic cause of this is ten companies, all of which project gaining 50% market share in their fast-growing segment (e.g. long-distance network traffic). Any one company can get enough true believers to value their stock on that basis.
As with any rational formula, Garbage In-->Garbage Out.
You use very judgmental language ("disdain", "little world") to describe a community you are obviously not a member of. (You can't even spell the language name correctly.)
Of course Common Lisp was standardized for the benefit of Lisp programmers, just like C was standardized for C programmers. Should they have made Lisp more like C to please them? Maybe throw away the powerful macros and replace them with #ifdef? Remove bignum support so that they could have good old familiar integer overflow? Or more like Scheme by removing everything not absolutely essential to writing the most skeletal program?
the language creators tried to refrain from trying to standardize things they did not understand or could not understand at the time,
How is this different from Common Lisp? What did Common Lisp standardize that was not very well understood? You seem to be describing a failure of C++, if anything. Templates contained a Turing-complete (but tortuous) language within them, which was hardly understood when the feature was first developed.
I don't know how "little" the world of Lisp programmers can be when it includes things like Orbitz. Lisp programmers worry about Web applications, calling foreign libraries, large databases, numerical performance, data-mining---all sorts of things that other communities worry about as well. Is that a narrow view?
The C/C++ *standards* did not "succeed" in the "real world" in any meaningful sense. The *languages* did, before they were practically standardized.
Think about how much code is out there that wasn't written using the features of C90, how much C code actually makes assumptions about endianess and the size of pointers, and how long it took most commercial C++ compilers to actually implement the spec. What happened was that a huge number of people programmed in something *like* the standard (i.e., were programming in UNIX and Windows, using the most well-supported definition of the APIs, with the tools that existed at the time).
Your last comment means that your definition of "real" certainly differs from mine. Just for curiosity, what do you consider to be a real software project implemented in Scheme (not including Scheme implementations)?
That's not a problem with Lisp, it's a problem with the Common Lisp standard, the Common Lisp community, and Common Lisp history.
There isn't any problem in the Common Lisp standard that prevents Common Lisp implementations from being practical programming environments. The standard simply states what should be the same between implementations, not what should be different in implementations. In fact, virtually every decision behind the standard was based on proven programming practice.
Common Lisp wasn't made a standard in order to take over the world, it was meant to unify various Lisp dialects into one common base. It succeeded, in that most real Lisp programming now happens in Common Lisp.
I suppose you would argue that the C and C++ standards have equal problems with being practical languages?
You can't "opt out" of paper junk mail, because those junk mailers are the ones who pay for the mailman to come to your mailbox and put stuff in for you.
If I got some kind of disease, I'll happily fork over the cash to get it fixed.
That's the key. Not only will you fork over the cash, so will thousands of other people who are not infected by the disease but want a cure to be found. (If this is not so, a lot of charities have some major explaining to do.)
There is nothing stopping this funding mechanism from being put in practice now. Pharmaceutical companies could be run not-for-profit, based on charitable donations from concerned people, spending their money on research and development of drugs, then giving the resulting drugs away for free. This is hardly illegal, but doesn't happen. Why not? Probably because your system doesn't account for the real risks involved.
Why would I give my money to a "Staph Infection Foundation" to develop drugs when there is an exceedingly small chance before hand that they will actually be able to accomplish their goal?
What does happen is that foundations do get formed to support basic research into diseases. Usually chronic, common diseases, such as diabetes, heart disease, cystic fibrosis, cancers, etc. The American Heart Association doesn't have the bucks to develop drugs, although they do support research.
For-profit companies cannot make a profit under your system of "develop it then give it away." Investors will put their money somewhere where it won't produce a guaranteed zero return-on-investment.
Slashdot Mirror
If you read the link you originally posted (or at least, tried to post), you discover the same tired and false arguments that tax "protesters" use to claim that the federal income tax does not apply to them, or to just about anyone.
The argument that the federal government only has the power to levy taxes in the zone of its "exclusive jurisdiction", meaning only D.C. and some American possessions, for instance, is completely ludicrous. It is taken as "proof" that almost everyone born in the 50 states is not a citizen for tax purposes.
If you think for just a moment about how much effort goes into developing the tax code by Congress, do you really think that they are doing all this work, sending out all these forms, for something that only applies to maybe one or two million people? Every single member of Congress, who *write* these laws, believes they apply to everyone born in the 50 states. If they made some technical error (given that the 16th amendment actually was ratified, disagreeing with another quite spurious argument from your source), they would have repaired it.
If you don't want to pay taxes, then don't. But don't claim that some tortured reading of the tax code or Constitution or Bible justifies it.
From a mathematicians' point of view, males and females are *topologically* equivalent.
That of course neglects the crucial difference caused by having your ears (or other body parts) pierced.
Of course, the topological transformation that would demonstrate that equivalence would be *exceedingly* painful.
In case you missed it, the link I pointed to also mentioned judges levying multi-thousand dollar fines on people "buggering the courts up" with frivolous arguments wasting everybody's time.
Face reality: the U.S. government has the power to levy taxes on your income and require you to fill out the 1040 form accurately. Not doing so opens you up to all sorts of legal penalties. I suppose if you also knew a bunch of old bank robbers, you'd tell us we should all take our pistols into bank offices and make money the brave way and tax free, too. Didn't you hear? The laws against bank robbery weren't written in the right color ink....
Why don't you go off somewhere and square the circle with a compass and straightedge?
In case you are in danger of believing in this nut case, consider this link from the IRS also.
One reason Bermuda is "nice" is that their laws on corporate governance favor management over shareholders much more strongly than American laws do. It's virtually impossible for a shareholder lawsuit to succeed against a Bermuda corporation.
On the other hand, IANA corporate lawyer or tax attorney. BTW, it's the Cayman Islands.
Well, that's perhaps nice in some situations, but the guy probably checked it out for some reason, for instance, to make changes? And he didn't check it back in for some reason, for instance, he wasn't done making changes? And his half-done changes might not be the best thing to put in the code because they might cause more problems than you are ready to deal with anyway.
This C++ template container approach is preferred *within the context of C++*. If you choose C++, then preferring template containers is a no-brainer, and I agree with Stroustrup that templates are essential, even though they were designed in relatively late in the C++ game. That says nothing about what design choices make sense before you have chosen your language of implementation.
One of the problems is that C++ design (and to a lesser extent Java design) require you to create these type and class heirarchies in order to be able to get the compiler to allow you to express your program. When inheritance is the only way to explain restrictions and relationships to the compiler, you end up doing a lot of inheritance.
In more dynamic languages, your class heirarchies can often be a lot less elaborate. You can express type checks that cross inheritance boundaries with ease. In the most difficult cases, in languages like CLOS you can create your own meta-classes that allow you to express things in ways other than inheritance.
Look, if you are dealing with a team that has not divided responsibility for design decisions according to a clear system, then that is your real problem, not the lack of compile-time diagnostics. You're also going to get huge numbers of bugs that the compiler *won't* catch.
The problem with C++ in particular is that it is a bondage-and-discipline language. Everyone on your team has to figure out in advance what chains and barriers are going to be put up in order to allow the problem to be solved within the C++ language.
In a dynamic language, you *choose* what barriers to put in place in order to maintain safety. You aren't forced to put a lot of barriers up that will never be needed.
Also, what people miss is that in Lisp, for instance, a run-time error usually puts you in an interactive debug environment, allowing you to make changes to the program (still alive) using the full power of the Lisp language, and the full resources of your program, in order to find the problem, fix it, and continue execution. This is just now coming to pass in the C++ world, with incremental compilation, etc., but Lisp programmers have had this for decades. When you are developing, you will find the errors, and for production, you can write error handlers that catch these various conditions, log them as appropriate, and specify how execution should continue.
The strategies you use with a dynamic language to prevent and deal with these kinds of problems are different than with static languages like C++. The strategies aren't better or worse, just different. What you gain with dynamic languages is a kind of flexibility that allows you to attack the problem, not the language, and to do so with a maximum payoff for programmer effort. What you gain with C++ is the ability to catch certain types of errors, which aren't really that common, especially as intellisense-type tools are becoming much more widespread. Much of the time, when the compiler complains about type mismatches, you add a cast. The language is forcing you to explain yourself again, not really pointing out a logic error in your program.
The real problems that programmers face are errors of logic, which no language can address, and the ability to express the desired operation, which dynamic languages make much easier than static languages, because they don't require as much unnecessary or redundant description.
If you call that flexible, then sure.
However, it's much less flexible than most dynamic languages because your Object is not shared with any other class heirarchy. Unless everyone who might need your stack is willing to inherit from your Object, then they can't fit your mold.
This whole compile-time vs. run-time error business is a red herring.
When you say getting an error at compile-time is better, you are just saying that C++ ensures that your program fits in the straitjacket that you made for it, ignoring the fact that you've made a straitjacket in the first place!
Making a stack which is "int only" is totally specialized. How are you "accidentally" going to write code that asks for something else, if your problem is so focussed that it only needs ints?
You really think that using strings by mistake is going to be a major source of bugs?
The real problem is that C++ operations are type-specialized at compile time. C++ compilers, for instance, don't know how to add numbers unless they know the type at compile time. In a dynamic language, the addition operator knows how to add whatever numbers it sees at run-time.
For every set of bugs that a compile-time error catches, there is a corresponding set of desirable program behaviors that become more difficult to explain to the compiler. That's why the whole idea of "design patterns" caught fire in the C++ world. These design patterns are like a phrase book translating your desire into the C++ language. If you have a more flexible language, you don't need a phrase book as often!
For sure. Actually, your sig encapsulates the advantages nicely:
if (!signature) throw std::runtime_error("No sig!");
The template version would give a compile-time error instead - type-safe and no need to to runtime error handling!
Only if the signature presence had to be determined at compile time. How flexible is that?
Actually, I would think that disk access tends to *equalize* emulators with real hardware. After all, your disk access is probably limited by disk latency and bandwidth, and the hard disk on your emulating machine shouldn't be that much slower than the real thing. Furthermore, the data from the hard disk is not going to need much translation between platforms.
What would kill speed is a task where the real processor to be able to execute with code and data both in cache. The emulated processor has to fit the relevant emulator code, emulated processor state, JIT-compiled emulated code, and the program data all in the host machine cache to have any chance at all of keeping up. [Note that Connectix requires L3 cache on the Mac to get the advertised speed improvements.] Even then, the inner loop of JIT-compiled code is probably not as optimized as an inner loop that makes heavy use of processor-specific quirks.
Video speed depends on how well the emulator maps the video calls to hardware on the emulating machine. Virtual PC does not do that for 3D.
With hard drive space so cheap, why not pre-load all kinds of software, each with a unique encryption key (varies for software, computer) and let the user call in with a credit card number to get the key for the software?
This has been tried. I think one of the main problems is that the software gets out of date. Six months from now, there is a new version. You don't want people to keep buying the old version that came with their hard drive. The other problem is probably keeping up with changes at the computer vendors as they upgrade their product mix. The release of a new OS install becomes a retail software situation, and the system probably isn't set up well to do that. Deadlines are hard enough to meet without some marketing-type guy having to update the contract with the software supplier.
From a user perspective, OS upgrades become more difficult. You want to keep all those unused software archives when getting a new hard drive or OS? A hassle.
I'd like to pick up older games like Full Throttle or Sam & Max, or the Infocom collections, without relying on eBay
I don't think this is likely to fly. Most programs, games especially, are not particularly future compatible. Porting software to Mac OS X is feasible with Carbon, but isn't automatic. As soon as you ask for money, you are setting up expectations that the program will actually work, not just on museum-piece hardware.
Think about how little software from the Mac OS 7 era still works on OS 9, much less OS X. There's always some glitch (doesn't work on HFS+ volumes, had some weird implementation of heirarchical menus, etc.)
If the owner of these old games hasn't seen fit to update them for the new platform, this kiosk isn't going to make that much difference in the economics. You still need to pay the developers to go over the code to eliminate bit-rot, for a market that is probably very small.
The main benefit is for retailers, who don't have to keep inventory and shelf space for lots of Mac titles, when they hardly have space for the PC titles they want to carry.
That's a very interesting question. I'm not sure there is a very compelling answer, however.
.o file, and you are most of the way there. I.e., any program that doesn't have "main()" defined yet is a library waiting to happen. In Pascal, it is just slightly less convenient.
Some of it is simply fashion: as C grew in popularity, it simply overtook Pascal in the new APIs that were developed. Once Pascal interfaces to the Mac OS became second-class citizens, there was no reason to favor it.
Another part of it is that Pascal was originally a teaching language, meant to indoctrinate structured programming. It deliberately tries to hide machine or OS-level reality with an idealized abstraction. It was not meant as a flexible all-purpose language like C. You couldn't write an OS kernel in Pascal very easily. One specific area in which it lacks flexibility is type conversion. For pointer or scalar (enum & integer) types, it really wants you to pick one type and stick with it. Good for enforcing discipline on software engineering students learning to design structured data types, poor for hackers who need to deal with the not-so-disciplined reality.
Another area where it lacks is file I/O. The standard doesn't really define byte-level results of its file operations, so reading/writing files compatible with other languages/API's depends on vendor extensions, which aren't uniform.
Similarly for structure layout. Although it isn't 100% defined, you can usually convince any C compiler on a given platform to agree with any particular arrangment of bytes in a structure. It's much harder with Pascal. This means that no matter what your OS, C code can be written mostly independent of compiler vendor, or at least with the nastiness hidden in header files.
Pascal also has a pretty inflexible (perhaps a bit clumsy) structure for writing your own libraries (units). In C implementations, you write a bunch of routines, a header file for users to #include, and make a
There are also a couple of omissions. I believe many implementations did not allow functions to return structure types. That's what drove me to C from Pascal many years ago. I believe arbitrary length arrays are also a bit clumsy to work with (not like C where you can have null-terminated arrays and use pointer arithmetic to navigate). Polymorphic types & pointers are clumsier in Pascal (no void* to ignore the differences when you want to.)
In general, Pascal works fine if you are writing a single application that requires only interfaces & libraries that your compiler vendor knew about. TeX by Knuth is an example. His programs (at least of that era) are monoliths, not collections of libraries and interfaces. You need to tweak a few routines to work with a particular vendor/platform, and that's only because Knuth very consciously made it that way.
Once you start working with libraries from multiple sources, the Pascal model begins to strain.
The Pascal folks would say that "Extended Pascal" plus OS-specific extensions in most compilers allow you to overcome all of these. But the extensions only happened after C began spreading like a virus, helped by its exposing all the weaknesses in Pascals that lacked full extensions.
I think the ability of (West) Germany and Japan to recover from fascism/military dictatorship (perhaps Japan's democracy is not the best example of "functioning," but I'll grant you that) after WWII had very little to do with the nuttiness of their wartime leaders, and much more to do with internal societal factors.
Germany and Japan both had been through the Enlightenment---Germany with the rest of Europe, and Japan during the Meiji period---so they were already essentially Western in outlook. They had developed mature, industrial economies.
Japan was a remarkably cohesive society, able to adapt to American occupation (as they had to Western civilization) with remarkably little disruption.
Germany was rebuilt under three-power occupation, with heavy infusions of aid coming through the Marshall plan.
The post-WWII period witnessed something near to a miracle in its ability to bring West Germany and Japan back into the Western world, although we take it for granted now. (Although we still haven't let Germany or Japan be a permanent member of the UN Security Council....)
In Iraq, virtually no aspect of the society (other than their relatively secular outlook) gives much hope that any kind of "democracy" could take root there. Neither does the likely quick exit with minimal financial support (oops, "forgot" the Afghan aid in our budget) the Bush administration will look for after the smoke settles.
Iraq is one of the *least* fundamentalist and *most* secular societies in the Middle East. Currently, it is possibly the least likely to be affected by fundamentalists. An Iraq without a functioning government would certainly be a more fertile area for al Qaeda to recruit.
I'm not defending Saddam Hussein as a sane or even tolerable human being, but your argument is a strawman. Sure, a functioning liberal, secular democracy in Iraq *might* improve things for the Iraqi people (or, it might elect Osama bin Laden as Supreme Leader). But the chance of the U.S. producing a functioning liberal, secular democracy in Iraq is near zero.
Asking if the UN is going to "back up" recent resolutions that were only passed because the US wanted them is a silly question. The UN has inspectors, and they are doing what they can. Are you going to ask the UN to "back up" the numerous "Zionism is racism" resolutions with concrete action as well? Talk is talk and action is action. Don't get the two confused.
The reason the UN is useful is it gives the small countries of the world a stake in the system, and a way to make it feel like they can restrict the actions of the few (one) powerful countries. In the absence of the UN, the countries of the world will feel compelled to group together, excluding the U.S., in order to balance the overwhelming power of the U.S.
Look at what happened to Germany when Bismarck was no longer around to reassure the weaker powers that Germany was not a threat---eventually, every other country was so nervous that they set themselves up to start World War I, which wasn't good for Germany.
Nixon understood, for instance, that China and Russia together would pose too great a geopolitical opponent to U.S. dominance. So he cultivated better relationships with each than they had with each other.
The current administration seems to think that we can offend everybody and basically bully them into being allies because we are on the side of "good." No one else in the world believes, as Bush apparently does, that it is our Christian duty to provide "God's gift" (if it's really God's gift, then why can totalitarians take it away?) of Liberty to the Iraqis.
When we sit back and think that even little countries, not even mentioning China or North Korea, have more resources than al Qaeda, and therefore pose more of a potential threat than this apparently all-consuming menace, we realize that the U.S. has the most to lose in the absence of international order.
Is the U.S. going to occupy the whole Middle East as soon as our huge presence in Iraq gives a oh-so-inviting target for terrorists? Or is the U.S. going to run away from the mess it creates, leaving a cesspool for Islamic fundamentalists?
I think you underestimate the rational basis for "growth" company valuation.
It is true, that in the absence of dividends, which was almost the definition of "growth stock" during the bubble, it is hard to see why holding a stock is worth anything. There is, however, a floor on the value of the stock, which is that some other company could buy 51% of the stock and collect the profits as if they were dividends. Also, at some future time, the growth will slow down, and the company will start to pay dividends as their sector has matured. In the meantime, they ought to be investing their cash in expansion, or get left behind.
The thing that leads to irrationality is when the future revenue growth rates are overestimated, either for the particular company, the overall market segment, or both. Being overly optimistic on the future cash flow in an exponentially growing way greatly increases the present value. A classic cause of this is ten companies, all of which project gaining 50% market share in their fast-growing segment (e.g. long-distance network traffic). Any one company can get enough true believers to value their stock on that basis.
As with any rational formula, Garbage In-->Garbage Out.
No, you miss the point!
There is a person who uses a computer to make presentations to customers so that his business can make money.
I've certainly never seen anything like this on Slashdot before!
The consequences are potentially enormous. It might be that this person doesn't even know Perl!
You use very judgmental language ("disdain", "little world") to describe a community you are obviously not a member of. (You can't even spell the language name correctly.)
Of course Common Lisp was standardized for the benefit of Lisp programmers, just like C was standardized for C programmers. Should they have made Lisp more like C to please them? Maybe throw away the powerful macros and replace them with #ifdef? Remove bignum support so that they could have good old familiar integer overflow? Or more like Scheme by removing everything not absolutely essential to writing the most skeletal program?
the language creators tried to refrain from trying to standardize things they did not understand or could not understand at the time,
How is this different from Common Lisp? What did Common Lisp standardize that was not very well understood? You seem to be describing a failure of C++, if anything. Templates contained a Turing-complete (but tortuous) language within them, which was hardly understood when the feature was first developed.
I don't know how "little" the world of Lisp programmers can be when it includes things like Orbitz. Lisp programmers worry about Web applications, calling foreign libraries, large databases, numerical performance, data-mining---all sorts of things that other communities worry about as well. Is that a narrow view?
The C/C++ *standards* did not "succeed" in the "real world" in any meaningful sense. The *languages* did, before they were practically standardized.
Think about how much code is out there that wasn't written using the features of C90, how much C code actually makes assumptions about endianess and the size of pointers, and how long it took most commercial C++ compilers to actually implement the spec. What happened was that a huge number of people programmed in something *like* the standard (i.e., were programming in UNIX and Windows, using the most well-supported definition of the APIs, with the tools that existed at the time).
Your last comment means that your definition of "real" certainly differs from mine. Just for curiosity, what do you consider to be a real software project implemented in Scheme (not including Scheme implementations)?
That's not a problem with Lisp, it's a problem with the Common Lisp standard, the Common Lisp community, and Common Lisp history.
There isn't any problem in the Common Lisp standard that prevents Common Lisp implementations from being practical programming environments. The standard simply states what should be the same between implementations, not what should be different in implementations. In fact, virtually every decision behind the standard was based on proven programming practice.
Common Lisp wasn't made a standard in order to take over the world, it was meant to unify various Lisp dialects into one common base. It succeeded, in that most real Lisp programming now happens in Common Lisp.
I suppose you would argue that the C and C++ standards have equal problems with being practical languages?
You can't "opt out" of paper junk mail, because those junk mailers are the ones who pay for the mailman to come to your mailbox and put stuff in for you.
If I got some kind of disease, I'll happily fork over the cash to get it fixed.
That's the key. Not only will you fork over the cash, so will thousands of other people who are not infected by the disease but want a cure to be found. (If this is not so, a lot of charities have some major explaining to do.)
There is nothing stopping this funding mechanism from being put in practice now. Pharmaceutical companies could be run not-for-profit, based on charitable donations from concerned people, spending their money on research and development of drugs, then giving the resulting drugs away for free. This is hardly illegal, but doesn't happen. Why not? Probably because your system doesn't account for the real risks involved.
Why would I give my money to a "Staph Infection Foundation" to develop drugs when there is an exceedingly small chance before hand that they will actually be able to accomplish their goal?
What does happen is that foundations do get formed to support basic research into diseases. Usually chronic, common diseases, such as diabetes, heart disease, cystic fibrosis, cancers, etc. The American Heart Association doesn't have the bucks to develop drugs, although they do support research.
For-profit companies cannot make a profit under your system of "develop it then give it away." Investors will put their money somewhere where it won't produce a guaranteed zero return-on-investment.