what would be a good reason to choose Pascal over any other given language?
Since it's a B&D language, you won't get buffer overflow bugs & exploits. (In and of itself, that's a mighty good reason to use Anything But C.)
Since it (well, Turbo Pascal did, so I guess Delphi does, too) knows how long strings are, there's no need for that silly necessity for null-term strings, and all the consequent bugs.
But... since it's a B&D language, there will be other gotchas to struggle with.
The whole idea behind caching and any other memory hierarchy is that it takes advantage of locality of reference,
Yes.
which is explicitly precluded by the stipulation in the great-grandparent that the accesses are random.
Didn't notice that part. I was thinking more of the Original Asker, but in the context of an RDBMS.
If I'm trying to shove as much data as possible into a table, caching will definitely help. And since the table will have to be indexed, caching may help there, too, depending on the keys in the index.
I've been there, you really can't have redundancies when it's just less than 10 of you trying to make this company work.
Understood. I'm thinking, though, from the POV of the small business who would be the (potential) customer.
What would the impact to my business be? Possibly it would be Very Bad.
Thus, if I was Joe Florist who wants a web presense, I'd want to contract with a company that had more than 2 tech people who could manage my system(s).
The front-end gets all the data, then passes it along using a file-based backing-store queueing system to the back-end that posts the data to your permanent store.
This also gives you the flexibility to let the front-end choose which back-end to send it to (usually on another machine).
So one disk can do, as a generous upper bound, 333 random accesses per second. I'll spare you the details of the Poisson distribution, but if you managed to spread these updates randomly over a disk farm, you'd need about 2000/333*e = 16 independent spindles.
Neither seem worthwhile to me unless you are the "only person" who can do this job and you trust no one else in your company or employ to handle the task.
Woe to the company that hires a single-man operation to maintain mission-critical systems.
If he's the only person who can manage these 7 servers, and gets hit by a bus, a whole lot of people are going to be really pissed off.
Hey, 10 years ago, when Win 3.11 and Win95 were the competition, being able to "rub your belly and pat your head at the sam time" was a big plus for OS/2.
anyone else like me fear having anything nuclear in my lap?
Only the stupid people.
Aim a very sensitive geiger counter at yourself, and, lo and behold, you discover that you are radioactive. Even people way out in the boonies like Amazonia, Cambodia, etc. Why? We're made out of carbon, and some carbon is radioactive.
Just last week, I tried to explain to my 15 year old daughter what a punch card was....
I'm sure there's some on Ebay you could buy. And there's pictures galore on the internet.
Besides, if she knows what a byte is, how hard is it to understand, A punch card stores 80 bytes of data on it by punching holes in various specific places on the card. The holes are punched using a big, scary-looking typewriter, and the cards are read by a big, noisy mechanical monster that plugs into a computer the size of our dinner table with a cable the size of your wrist. (Since girls' wrists are, on average, of course, smaller than teenage boys wrists.)
It's been quite a few years but it was somewhere between on error in every 10E5 to 10E6 bits. So it's not unusual to find a mistake in every megabyte read.
I'm surprised, but not that surprised.
Areal densities are so high these days, the r/w heads are so small, and prices are so low, that I also am truly amazed that modern HDDs are made to work.
But then, I remember 13" removable 5MB platters, and 8" floppy drives.
What happens is that the boiling hot water evaporates much more quickly than the room temp water. Evaporation leads to loss of volume... so the tray of boiling hot water actually does freeze more quickly. Give it a try.
Seeing as how the boling water would probably deform the cheap plasic that ice trays are made of, I'd be kinda nervous. Are you old enough to remember metal ice trays?
I wonder if the "amount" of boil makes a difference. I.e., it seems that water at a full boil would evaporate faster than "just starting to boil, just-reached 100oC" water.
It's too bad that my freezer is full. Even if it wasn't, my wife would get pissed if I raised the temperature of the freezer like that.
I would think there would be more issues in converting a 32-bit program into a 64-bit one, rather than having any issues running a 32-bit program on a 64-bit kernel.
In C, the 64-bit integer type is usually called "long long", so the big issue, as usual with C, is pointers and casting.
For 25 years now (starting with the MC68000, VAX, SPARC, etc), pointer has equalled int in bit size on 99+% of all installed systems.
But 64-bit systems have been around for ~15 years, so that's when Unix/POSIX C programmers started paying attention to proper coding practices. The Linux Alpha/SPARC64/PPC64/HPPA ports really acelerated the need to "do it right", because otherwise, the coder would get a stream of bug reports from people using 64-bit systems.
...and quite a few userspace apps were broken on Linux/Alpha (I spent quite a bit of time with Linux on EV5).
But not because of backwards compatibility issues so much as bad code, written by bad coders.
Most all were fixed many years ago. Thank the Debian Project for continuing to build against Alpha, and tracking bugs against it. Upstream then makes their s/w 64-bit clean for everyone.
Of course, if fewer programs were written in C, the problem would be minimized.
Slashdot Mirror
what would be a good reason to choose Pascal over any other given language?
Since it's a B&D language, you won't get buffer overflow bugs & exploits. (In and of itself, that's a mighty good reason to use Anything But C.)
Since it (well, Turbo Pascal did, so I guess Delphi does, too) knows how long strings are, there's no need for that silly necessity for null-term strings, and all the consequent bugs.
But... since it's a B&D language, there will be other gotchas to struggle with.
The whole idea behind caching and any other memory hierarchy is that it takes advantage of locality of reference,
Yes.
which is explicitly precluded by the stipulation in the great-grandparent that the accesses are random.
Didn't notice that part. I was thinking more of the Original Asker, but in the context of an RDBMS.
If I'm trying to shove as much data as possible into a table, caching will definitely help. And since the table will have to be indexed, caching may help there, too, depending on the keys in the index.
I've been there, you really can't have redundancies when it's just less than 10 of you trying to make this company work.
Understood. I'm thinking, though, from the POV of the small business who would be the (potential) customer.
What would the impact to my business be? Possibly it would be Very Bad.
Thus, if I was Joe Florist who wants a web presense, I'd want to contract with a company that had more than 2 tech people who could manage my system(s).
A messaging system would work.
The front-end gets all the data, then passes it along using a file-based backing-store queueing system to the back-end that posts the data to your permanent store.
This also gives you the flexibility to let the front-end choose which back-end to send it to (usually on another machine).
You seem to be presuming that there's no:
our targeted, opt-in e-mail marketing programs.
Opt-in e-mail is not spam. Opt-out email is spam.
Neither seem worthwhile to me unless you are the "only person" who can do this job and you trust no one else in your company or employ to handle the task.
Woe to the company that hires a single-man operation to maintain mission-critical systems.
If he's the only person who can manage these 7 servers, and gets hit by a bus, a whole lot of people are going to be really pissed off.
Interspace Battles (WWII aerial & naval movies)
GL is said to have used WW2 aerial footage when pitching Star Wars back in 1975.
I'd just like to point out that Poland (and Germany, and plenty of others) are NOT in the western hemisphere.
I don't remember anyone claiming that it was...
And yes, I did RTFA.
The hitch in that plan was all those Intranet apps that required IE ... get it?
I'm glad I'm not the only one who thought of that when reading this article.
Hey, 10 years ago, when Win 3.11 and Win95 were the competition, being able to "rub your belly and pat your head at the sam time" was a big plus for OS/2.
Could we use this technology around existing nuclear reactors? They're already throwing off a ton of radiation, beta and otherwise I would imagine.
If it's more efficient than using fission to boil water to spin turbines that generate electricity, then it would be a great idea.
But after looking around the web, I don't think it is.
anyone else like me fear having anything nuclear in my lap?
Only the stupid people.
Aim a very sensitive geiger counter at yourself, and, lo and behold, you discover that you are radioactive. Even people way out in the boonies like Amazonia, Cambodia, etc. Why? We're made out of carbon, and some carbon is radioactive.
Just last week, I tried to explain to my 15 year old daughter what a punch card was....
I'm sure there's some on Ebay you could buy. And there's pictures galore on the internet.
Besides, if she knows what a byte is, how hard is it to understand, A punch card stores 80 bytes of data on it by punching holes in various specific places on the card. The holes are punched using a big, scary-looking typewriter, and the cards are read by a big, noisy mechanical monster that plugs into a computer the size of our dinner table with a cable the size of your wrist. (Since girls' wrists are, on average, of course, smaller than teenage boys wrists.)
It's been quite a few years but it was somewhere between on error in every 10E5 to 10E6 bits. So it's not unusual to find a mistake in every megabyte read.
I'm surprised, but not that surprised.
Areal densities are so high these days, the r/w heads are so small, and prices are so low, that I also am truly amazed that modern HDDs are made to work.
But then, I remember 13" removable 5MB platters, and 8" floppy drives.
What happens is that the boiling hot water evaporates much more quickly than the room temp water. Evaporation leads to loss of volume... so the tray of boiling hot water actually does freeze more quickly. Give it a try.
Seeing as how the boling water would probably deform the cheap plasic that ice trays are made of, I'd be kinda nervous. Are you old enough to remember metal ice trays?
I wonder if the "amount" of boil makes a difference. I.e., it seems that water at a full boil would evaporate faster than "just starting to boil, just-reached 100oC" water.
It's too bad that my freezer is full. Even if it wasn't, my wife would get pissed if I raised the temperature of the freezer like that.
I like the "did you know a cube tray full of room temp water will freeze more quickly than a tray of boiling hot water?" example better.
Does anyone not know that 22oC water will reach 0oC faster than 100oC water?????
The point isn't "this is how to boil ice cubes", but to demonstrate how thermodynamics can be counterintuitive.
http://www-128.ibm.com/developerworks/library/pa-
"In 1979, Motorola introduced the 68000. With internal 32-bit registers and a 32-bit address space, its bus was still 16 bits due to hardware prices"
http://en.wikipedia.org/wiki/Acorn_RISC_Machine
Or better yet, volumetric heat capacity...
The Good Eats episode on How To Thaw A Turkey did a great job of explaining that in layman's terms:
Cool running water melts a ice cube duck faster than a pot of water removed from the stove just as it started to boil.
The main problem with the 16-32 bit transition was the dreaded segmentation
And that was "only" Intel. Everyone else had the brains to build 32 bit systems in the late 70s and early 80s.
regarding Windows since the Microsoft / DEC Alliance days
Windows NT/Alpha put the processor in 32 bit mode.
That's how most OpenVMS code ran for a long time, too.
I would think there would be more issues in converting a 32-bit program into a 64-bit one, rather than having any issues running a 32-bit program on a 64-bit kernel.
In C, the 64-bit integer type is usually called "long long", so the big issue, as usual with C, is pointers and casting.
For 25 years now (starting with the MC68000, VAX, SPARC, etc), pointer has equalled int in bit size on 99+% of all installed systems.
But 64-bit systems have been around for ~15 years, so that's when Unix/POSIX C programmers started paying attention to proper coding practices. The Linux Alpha/SPARC64/PPC64/HPPA ports really acelerated the need to "do it right", because otherwise, the coder would get a stream of bug reports from people using 64-bit systems.
...and quite a few userspace apps were broken on Linux/Alpha (I spent quite a bit of time with Linux on EV5).
... a 32 bit x86.
:/
But not because of backwards compatibility issues so much as bad code, written by bad coders.
Most all were fixed many years ago. Thank the Debian Project for continuing to build against Alpha, and tracking bugs against it. Upstream then makes their s/w 64-bit clean for everyone.
Of course, if fewer programs were written in C, the problem would be minimized.
All the world is not
No, but 99.44% of it is...
If Citibank loses its index of 10,000 customer credit lines due to hardware failure, people give a rats ass.
That's what RAID and backups are for...