Lots of HyperCard stacks are in use today, in all sorts of places - businesses, doctor's offices, museums, and more. Currently there seem to be no plans on Apple's part to update HyperCard to run natively under Mac OS X.
Everyone seems to read this as "Apple is dropping support for HyperCard." Let's take a few seconds to analyse the situation.
There are thousands upon thousands of HyperCard stacks out there, developed for the last fifteen years. A safe estimate would indicate that the vast majority were developed more than three years ago.
OS X is support on boxes shipped with G3s and G4s. These are all boxes developed in the past three years or so. By one of the few appropriate applications of Moore's Law, these machines are from 1 to 1000 times faster than the boxes used to develop and deploy the HyperCard stacks, which are mostly UI-bound anyway.
There's not a significant enough performance hit for Classic apps for these HyperCard stacks to be slower than they were originally. It's still pretty doggish, but it is in Apple's best interests to improve Classic.app and MacOS.app to lure customers away from their old boxes. As it is, even though it's slower than it should be, remember the environment for which they were developed, and remember that almost all of them are not computationally demanding.
Not from what I infer, based on your views. "From each according to his abilities, to each according to his needs," sounds like something other than Capitalism.
For equivalent purposes, the difference is minimal, and not worth the effort, since it's presentation code anyway. You shouldn't be mixing your presentation layer with your business logic.
As for the difference between C++ vs. assembly, C vs. asm is probably a better analogy, as it is a one-step difference. (C is basically just a really nice macro assembler:-)) Your statement is mostly a myth in this day and age, anyway. A decent C compiler can produce faster code than hand-written assembly on most modern platforms, for anything greater than a microscopic example.
I beleive the database server and other libraries that you call out to make a much larger impact in speed.
We have an application constructed in a similar fashion: JSP/Servlet in the presentation tier, custom appserver for object persistence and business logic at the backend, talking to Oracle. Under load, the cpu profile was 70%/25%/5%.
Apparently, all the string manipulation in the presentation layer (parsing requests and generating responses) had a much higher resource requirement than the pure-object or database components. Oracle wasn't even sweating, but we've worked hard not to make it do so, given the expense of JDBC.
php, optimized with zend's optimizer will outperform jsp by about 15%
Be careful with that kind of generalization, unless you're going to post references. There's a huge variation in jsp engine performance. This is a vendor benchmark site (so take it with a grain of salt, especially where their product is concerned), but you can see how wide the range of performance can be between JSP/Servlet engines.
You'll need to drive screws into the sides of your head, then, to keep your glasses from falling off.
Re:Hovercraft design questions
on
What is 'IT'?
·
· Score: 1
Other articles about Kamen have reported that his company has developed a small prototype Stirling-cycle electrical generator. Since Stirling engines can use efficient multi-fuel external combustion. A practical Stirling generator would be light weight, efficient, and clean. He could use his own generator to power his device.
There are two problems with this:
1) There wouldn't be much point in the amount of secrecy this has demanded if it was as simple as stringing together his current patents and articles to form some composite invention. Since it's assumed he doesn't want people to find out about it, it's going to be a bigger leap than that.
2) More importantly, in the Wired article, he talked about using a briefcase-sized Stirling engine to power a cell phone. Do you know how big it (or an array of them) would have to be to move my 150lb carcass?
Saddam has obviously been using a pseudonym while trolling for information! He's probably been using us for years, asking about the suitability of various non-computer computers as components of a beowulf cluster!
Sort of. Jesus spoke both Hebrew and Aramaic. All serious jewish scriptural study at the time was done in Hebrew, with a tiny amount of Aramaic.
It would be like, speaking Spanish with your family at home, or when you go out drinking with your buddies, but speaking, reading, and writing in English at work.:-)
Actually, we have patents so that people will feel safe revealing the secrets of their technology, knowing they will have protection from competition for a few years.
It's not to provide incentive for people to find other routes to a solution, but rather, so that they can avoid having to reinvent the wheel -- in exchange for waiting a few years. Short-term innovation is stifled to further long-term innovation.
In the past (and in other fields), when the timescale for innovation was longer, this worked effectively. In the computer industry, especially with software, the timeframes assigned to patents can constrict innovation.
Slashdot Mirror
You get paid by the line, don't you?
It sounds like a nice idea, but using a glove or a touchscreen for hours will kill your arm.
See gorilla arm
NeXT never used microkernel Mach. That was one of the things Apple did, to move from Mach 2.5, which was a monolithic kernel.
The first person to mention Quake loses a testicle.
Umm, that would be you. I'll trust you to do the right thing.
Lots of HyperCard stacks are in use today, in all sorts of places - businesses, doctor's offices, museums, and more. Currently there seem to be no plans on Apple's part to update HyperCard to run natively under Mac OS X.
Everyone seems to read this as "Apple is dropping support for HyperCard." Let's take a few seconds to analyse the situation.
There are thousands upon thousands of HyperCard stacks out there, developed for the last fifteen years. A safe estimate would indicate that the vast majority were developed more than three years ago.
OS X is support on boxes shipped with G3s and G4s. These are all boxes developed in the past three years or so. By one of the few appropriate applications of Moore's Law, these machines are from 1 to 1000 times faster than the boxes used to develop and deploy the HyperCard stacks, which are mostly UI-bound anyway.
There's not a significant enough performance hit for Classic apps for these HyperCard stacks to be slower than they were originally. It's still pretty doggish, but it is in Apple's best interests to improve Classic.app and MacOS.app to lure customers away from their old boxes. As it is, even though it's slower than it should be, remember the environment for which they were developed, and remember that almost all of them are not computationally demanding.
I am a capitalist.
Not from what I infer, based on your views. "From each according to his abilities, to each according to his needs," sounds like something other than Capitalism.
No, we have to destroy the cows. You'll be milking your dog. Just be sure it's female.
by Anonymous Coward
No shit.
For equivalent purposes, the difference is minimal, and not worth the effort, since it's presentation code anyway. You shouldn't be mixing your presentation layer with your business logic.
:-)) Your statement is mostly a myth in this day and age, anyway. A decent C compiler can produce faster code than hand-written assembly on most modern platforms, for anything greater than a microscopic example.
As for the difference between C++ vs. assembly, C vs. asm is probably a better analogy, as it is a one-step difference. (C is basically just a really nice macro assembler
We have an application constructed in a similar fashion: JSP/Servlet in the presentation tier, custom appserver for object persistence and business logic at the backend, talking to Oracle. Under load, the cpu profile was 70%/25%/5%.
Apparently, all the string manipulation in the presentation layer (parsing requests and generating responses) had a much higher resource requirement than the pure-object or database components. Oracle wasn't even sweating, but we've worked hard not to make it do so, given the expense of JDBC.
php, optimized with zend's optimizer will outperform jsp by about 15%
Be careful with that kind of generalization, unless you're going to post references. There's a huge variation in jsp engine performance. This is a vendor benchmark site (so take it with a grain of salt, especially where their product is concerned), but you can see how wide the range of performance can be between JSP/Servlet engines.
JSP's are pretty robust, but slower than pure servlets (which are also robust)
????
JSPs are compiled into servlets. Admittedly, they may be slower than intentionally-coded servlets, but after the first call, they are servlets.
Never mind that the badge-tracking system is three or four years old, and has been discussed in the media, and then discarded as old news.
I'm sure you're not presenting this as anything other than a gross hack. :-)
Your solution would require the installation of X libraries on all machines using your binaries.
In case you wanted to read what RMS had to say about that (among other things).
;>)
I was looking to see if Andy Tai's statement was true (it was stated so tersely I took it to be an unwarranted attack.
Unfortunately, the USPS will no longer deliver these. According to rule 917.243(b) in the Domestic Mail Manual, when a business reply card is "improperly used as a label"--e.g., when it's affixed to a brick--the item so labeled may be treated as "waste."
God Bless Cecil Adams.
You'll need to drive screws into the sides of your head, then, to keep your glasses from falling off.
There are two problems with this:
1) There wouldn't be much point in the amount of secrecy this has demanded if it was as simple as stringing together his current patents and articles to form some composite invention. Since it's assumed he doesn't want people to find out about it, it's going to be a bigger leap than that.
2) More importantly, in the Wired article, he talked about using a briefcase-sized Stirling engine to power a cell phone. Do you know how big it (or an array of them) would have to be to move my 150lb carcass?
'Nuff said.
That's dynamic. The version I have here says meta name="DATE" content="2001-01-03 19:42:38".
Saddam has obviously been using a pseudonym while trolling for information! He's probably been using us for years, asking about the suitability of various non-computer computers as components of a beowulf cluster!
The bastard!
Sort of. Jesus spoke both Hebrew and Aramaic. All serious jewish scriptural study at the time was done in Hebrew, with a tiny amount of Aramaic.
:-)
It would be like, speaking Spanish with your family at home, or when you go out drinking with your buddies, but speaking, reading, and writing in English at work.
Actually, we have patents so that people will feel safe revealing the secrets of their technology, knowing they will have protection from competition for a few years.
It's not to provide incentive for people to find other routes to a solution, but rather, so that they can avoid having to reinvent the wheel -- in exchange for waiting a few years. Short-term innovation is stifled to further long-term innovation.
In the past (and in other fields), when the timescale for innovation was longer, this worked effectively. In the computer industry, especially with software, the timeframes assigned to patents can constrict innovation.
Back in the box with your Apple ][+, or at least upgrade to a ][e.