AFAIK private industry is not required to pre-fund pension plans. That is one of the competitive disadvantages against the USPS. (IMHO pension plans, if offered, should be pre-funded, and not 'owned' by the company so they can't be raided, and not funded by the company's own stock. But that's another topic.) See a comment higher up for the list of things that USPS is not allowed to do by Congress - including setting rates, and other things that other companies can do.
IANA EE, but IIRC that's true only for radiated fields. If you can consider the Earth itself as a resonant conductor, then the rules are somewhat differently applied. In present-day applications, another example is any conductor or waveguide. I imagine that he was looking at the entire Earth+atmosphere in those terms. And there is some evidence that some of his work in that area was successful at least in part.
+1. I was thinking about posting this myself. One of my early geek influences was a book I read in grade school about Steinmetz. The Wikipedia article does not really present the significance of his work. As I recall even Tesla's AC would not have been successful in the long term, without some of the contributions of Steinmetz. He was playing with generating 120 KV 'lightning' and collecting lightning from towers before Tesla. Also his personal history is interesting. (He refused to get married because he had an inherited dwarfism that he did not want to pass on.)
Actually, using revenue + profits might be interesting - say 2.5% of revenue + 15% of profits. This would get _some_ tax out of a company that has low profits (such as grocery chains - they typically run low profits but huge cash flows so return on equity is good) and a company that has high (unhidable) profits. That is, if one believes that companies pay taxes at all vs. those who say that the taxes are just passed through to the customer.
Or, as the old saw goes, the IRS has a new tax form. It's very simple, just one question: "How much did you make? Send it in."
Law can be viewed as an attempt to impose/construct a partially-complete logical system for managing interpersonal conflict. Of course, the language in which it is written is rife with ambiguity and other issues. So in principle, lawyers (which includes pretty much all judges and at least 1/2 of legistlators IIRC) should be able to follow along pretty easily.
Of course any attempt to impose a rational system (much less a logical one) on reality will suffer from Incompleteness.
Nowadays the recommended method of coding is to use variable names and function names that are self-descriptive. Given that, it seems to me that the code is pretty much the natural way anyone might write it. Google did say that they copied it, but really, how else might one write it? It's definitely the level of a first year programming course. The only interesting bits are (IIRC) the use of a ToIndex that is one more than the length, to eliminate a bit of arithmetic in the loop. So were they inclined to dissemble, Google could have claimed that it's just a coincidence.
A bit of history provides some useful background. During WWII, the area near Pittsburgh PA produced more steel than the rest of the world combined. (But those mills were mostly built with 19th century technology. They were at the 'prime of life' and would have been obsolete soon even without the war.) Steel mills and other heavy industry throughout the rest of the world also were largely destroyed by bombing from one side or the other - mostly Allied bombing of German and Japanese steel mills. So after the war US industry, and particularly US steel, were the only ones still able to produce products. We then lent money to all parties (the Marshall Plan), with the proviso that they had to spend the money on US goods. The boom of the 1950s was the result of this and some other policies (the GI bill was another). This amounted to a postwar bubble.
One of the things that those other countries did was build new steel plants, using the latest technology. By the end of the 1950s these new plants were coming online, able to make steel for much lower prices. At that point the US steel industry, still based on late-19th century mill technology, became completely obsolete. The US steel companies, still competing with each other as well as the rest of the world, could not justify spending $zillions to essentially compete against themselves, while it was well worth while for other countries to develop their own industries, as they were starting from a zero base. This is a classic problem that results in constant turnover in many/most/all industries - it rarely seems like a good idea to build your own competition looking at the short term - all it does is spend money to reduce profits- but it's often a good idea to come in from outside and build the competition to the entrenched, inefficient market leader..
Since the 1970s there have been quite a few new, smaller mills built here using the latest (IIRC NUCOR was one of the first examples) but they still have to work hard to compete with the lower costs elsewhere - lower wages, lower land prices, etc. So it's an uphill battle, and that kind of dominance after WWII was a one-time deal.
One of the side-effects of the loss of those two-mile-long mills in the Pittsburgh area is that the side has become clean. When I lived there (early 1990s) the Carnegie Library and Museum was being scrubbed. The building had been black for 80 years or so. After scrubbing it turned out to be blond! I saw pictures from the 1950s where it was too dark and smoky to see across the street in downtown Pittsburgh. And those big mill areas along the rivers are now available to be turned into parks, housing, light industry, clean industry, whatever. But of course, there aren't many jobs. The population of Pittsburgh now is about 1/3 what it was in 1965. Houses are (or at least were) cheap.
I think that happens a lot. It happened to me. I co-founded an imaging company back in 1983 based on my idea for connecting a high speed CCD camera to an advanced workstation - bleeding edge stuff at the time. A few months later the company was already doing well, and my associate (a sales guy) and I brought in a new CEO who brought some VC money with him. I left in frustration three years later as the CEO was mismanaging the place horribly, although he did mange to keep bringing new investment money into the company. The history of the company as of a year or two after that was how the CEO had taken an interesting project by a couple of engineers and single-handedly created a company to bring it to fruition - literally our efforts merited part of a single sentence in a ten page history.
The last laugh was that after I left (I had been VP of R&D), in the next two years they went through seven VPs of R&D (I guess I wasn't doing such a bad job!), and spent most of the 1990s fighting a series of battles against financial types who were trying to force them into bankruptcy - people that the CEO had originally brought in to invest in the company. The financial shenanigans were rather distressing to me. In a short conversation about 1999, the CEO of the then-defunct company agreed that the three major things I had recommended, and he had rejected finally triggering me to quit, were all correct - but as he said, "I hadn't been forceful enough to convince him!" - sigh. And he spent ten years fighting in court instead of doing other fun things.
I still feel there was a good legacy. My track record in managing the engineering side was that we were technically successful on every project, usually under budget, and had excellent morale. I'm still friends with folks that I originally hired there. And we did some really great work in vectorizing, OCR and entity recognition for large format maps and drawings. We even did some work on constructing 3D models from sets of 2D drawings. We could generate terrain models from USGS maps. I got to tour the Space Shuttle External Tank manufacturing facility, and we built image processors that were two orders of magnitude faster than anything else out there, using chips from the cruise missile program (credit where credit is due - that hardware and a lot of the original code behind the OCR and other recognition capability was done by the Visual Understanding Lab of Bob Thibadeau, research professor at Carnegie Mellon). Of course, all that can now be done by any common desktop in software.
Just to continue this thread, it's been said that the original Emacs was written in TECO, the DEC-10 editor, which also had full access to the operating system's deepest function calls. TECO makes Emacs look like a paragon of user interface perfection. IIRC one of the TECO commands was 'delete line', and the upper case version of the same command was 'reboot' - a rather brute force method of deleting a line.
For those inquiring minds, Here's the link. A quote might be sufficient:
TECO does not really have syntax; each character in a program is an imperative command, dispatched to its corresponding routine. That routine may read further characters from the program stream (giving the effect of string arguments), change the position of the 'program counter' (giving the effect of control structures), or push values onto a value stack (giving the effect of nested parentheses). But there is nothing to prevent operations like jumping into the middle of a comment, since there is no syntax and no parsing. A classic essay on computer programming, Real Programmers Don't Use Pascal, suggested that a common game for TECO fans was to enter their name as a command sequence, and then try to work out what would happen. The same essay in describing TECO coined the acronym "YAFIYGI", meaning "You Asked For It You Got It" and thus being the antitheses of WYSIWYG ("What You See Is What You Get").
Oddly enough, when I worked for Perq I modified the Sketch program, which also had a transcripting feature, to transmit the data over the LAN to another workstation. It worked both directions so two people could draw simultaneously on both copies of the document.:)
Of course that Sketch program only did black lines & patterns on white background. But it worked fine, even on the early 3 Mbit Ethernet. I would speculate that, using some of the modern ways of modeling shapes (nurbs, quadratic surfaces, etc. - stuff that is used to generate 3D curves,...) it would not be that difficult or space-consuming in the modern context of memory and disk space. Considering that the brush is moving at human speeds, I think the computer could be constructing the numerics for saving without working too hard. There is a limit, of course. But it's not necessarily required to save every point, only a function that can reconstruct those points.
I know some F500 companies do that. Chevron, for example, back in the late 1990s had their own custom version of Windows. (I haven't been there since, so I don't know if it's still true.) they would also fire you if you opened the computer, or loaded any software onto it. They pushed new software onto your machine any night they felt like it.
It reminded me of Mordor when I visited the company.
Related example - old Harley Davidsons leaked oil all the time but would last essentially forever, requiring maintenance the whole time. My 1982 Honda 900 Custom never leaked oil, required minimal maintenance and everything fell apart at the same time at 100,000 miles. Engineering can do that. In the extreme, the folks who build race cars and race boats etc. keep taking weight out of a part until it breaks, then add a bit more weight back in. It only has to last long enough to finish the race - everything else is a waste. I personally prefer some maintenance and a vehicle that could last long enough to justify the amortized environmental cost of the resources.
I was just talking with someone whose two-year-old knows how to get into her iPhone and play games on it. Pretty much self-taught. Occasionally calls random numbers in France, which isn't so good.
I recall the highly-tweaked VMS that we used back in the day had two nice features regarding files. File saving could be set up so that each version of the file was saved with a trailing semicolon and a version number, so you could go back to any of those versions. Of course modern version control is better. The other was a nice owner-group-project permissions system (Unix has a poor relative mechanism). As one moved between projects in the day one just did a 'change project' (rather like chgrp on Unix), and the access to the files would change. Also the system accounted for time and cpu etc. on that basis, so projects could be billed accordingly for one's own time and resource usage.
That application would be an excellent candidate for change control. Every change should be tracked, including the IP address from whence it came. An audit trail, IOW. Just in case.
Back in the day, the Perq workstation's text editor had a modification transcript that it kept. If bad things happened, you could 'play' the transcript, and watch yourself work. If, for example, the system lost power, when you restarted the transcript would contain every change typically up to the last block write, so you'd have lost maybe only the last half dozen changes.
One time I was in the zone, and edited a file for almost 30 hours without saving (dumb, but hey...) The machine went south, and I lost it all. But I was able to play the transcript back and only lost a half-hour's work. I actually asked the Vim forum about ways to do this, and the nice folks there suggested ways it could be implemented as a plug-in but I haven't pursued it - my own laziness abounds.
Funny thing, I sometimes suspend my GVim session and go home from work. Then I come back in the morning, and I can use 'undo' back a few steps to remind me where I left off, then go forward to the end so I can continue. Of course I saved before I left... usually!
He does have a narrow point - old radios had buttons that physically pushed in, and only one could be in at a time. A rather complicated mechanical linkage accomplished this. Now the state is identified by something in the display, typically.
I know that there are pieces of equipment around my house that have physical buttons that pop in and out according to which one is set but I can't think what they are offhand.
well, they don't physically jump in and out, but I think every car radio still has preset station buttons.
Which reminds me - I still miss the old Apple keyboards with the physical Caps Lock key. Since that's a special case of setting a state, it was very nice to have that tactile feedback. Little lights in arbitrary places do not suffice.
Just make them all the same shape. Avoids confusion, all that pesky learning. Just guess what it does! If you guess right, the file is saved. If not, it sucks for you! Just to make things interesting, change their positions randomly.
Which, oddly enough, is partly why it is so successful. English is the 'open source' of languages. Anybody can 'edit' it, adding new terms, letting others fall out of usage. It adopts features from every other languages shamelessly, squeezing them in anyplace where they kinda make sense. It is an example of the 'bazaar' method of design. It will never be pure, never by clean, never be well-structured, but it will continue to muddle through.
To the point, a quote from Andrew Jackson: "It's a damn poor mind that can only think of one way to spell a word!" - perhaps the earliest example of the sentiment more recently expressed regarding Perl: "There's more than one way to do it."
My only gripe with this is that I have to wait for a result even on todays machines. There's no good reason it couldn't be fast on a 15 year old Pentium let alone one made last year. Is it really choking on the data set of a single application menu or is there more to it then that?
wandering off topic, I'll speculate (or rather, educatedly-guess) that this is the unintended consequence of highly nested object-oriented programming. All of that object creation for each menu, then each item in the menu costs.
AFAIK private industry is not required to pre-fund pension plans. That is one of the competitive disadvantages against the USPS. (IMHO pension plans, if offered, should be pre-funded, and not 'owned' by the company so they can't be raided, and not funded by the company's own stock. But that's another topic.) See a comment higher up for the list of things that USPS is not allowed to do by Congress - including setting rates, and other things that other companies can do.
IANA EE, but IIRC that's true only for radiated fields. If you can consider the Earth itself as a resonant conductor, then the rules are somewhat differently applied. In present-day applications, another example is any conductor or waveguide. I imagine that he was looking at the entire Earth+atmosphere in those terms. And there is some evidence that some of his work in that area was successful at least in part.
+1. I was thinking about posting this myself. One of my early geek influences was a book I read in grade school about Steinmetz. The Wikipedia article does not really present the significance of his work. As I recall even Tesla's AC would not have been successful in the long term, without some of the contributions of Steinmetz. He was playing with generating 120 KV 'lightning' and collecting lightning from towers before Tesla. Also his personal history is interesting. (He refused to get married because he had an inherited dwarfism that he did not want to pass on.)
Yes. See
'Double Irish With a Dutch Sandwich'
- used by Google, Apple, etc.
Actually, using revenue + profits might be interesting - say 2.5% of revenue + 15% of profits. This would get _some_ tax out of a company that has low profits (such as grocery chains - they typically run low profits but huge cash flows so return on equity is good) and a company that has high (unhidable) profits. That is, if one believes that companies pay taxes at all vs. those who say that the taxes are just passed through to the customer.
Or, as the old saw goes, the IRS has a new tax form. It's very simple, just one question: "How much did you make? Send it in."
Law can be viewed as an attempt to impose/construct a partially-complete logical system for managing interpersonal conflict. Of course, the language in which it is written is rife with ambiguity and other issues. So in principle, lawyers (which includes pretty much all judges and at least 1/2 of legistlators IIRC) should be able to follow along pretty easily.
Of course any attempt to impose a rational system (much less a logical one) on reality will suffer from Incompleteness.
Nowadays the recommended method of coding is to use variable names and function names that are self-descriptive. Given that, it seems to me that the code is pretty much the natural way anyone might write it. Google did say that they copied it, but really, how else might one write it? It's definitely the level of a first year programming course. The only interesting bits are (IIRC) the use of a ToIndex that is one more than the length, to eliminate a bit of arithmetic in the loop. So were they inclined to dissemble, Google could have claimed that it's just a coincidence.
A bit of history provides some useful background. During WWII, the area near Pittsburgh PA produced more steel than the rest of the world combined. (But those mills were mostly built with 19th century technology. They were at the 'prime of life' and would have been obsolete soon even without the war.) Steel mills and other heavy industry throughout the rest of the world also were largely destroyed by bombing from one side or the other - mostly Allied bombing of German and Japanese steel mills. So after the war US industry, and particularly US steel, were the only ones still able to produce products. We then lent money to all parties (the Marshall Plan), with the proviso that they had to spend the money on US goods. The boom of the 1950s was the result of this and some other policies (the GI bill was another). This amounted to a postwar bubble.
One of the things that those other countries did was build new steel plants, using the latest technology. By the end of the 1950s these new plants were coming online, able to make steel for much lower prices. At that point the US steel industry, still based on late-19th century mill technology, became completely obsolete. The US steel companies, still competing with each other as well as the rest of the world, could not justify spending $zillions to essentially compete against themselves, while it was well worth while for other countries to develop their own industries, as they were starting from a zero base. This is a classic problem that results in constant turnover in many/most/all industries - it rarely seems like a good idea to build your own competition looking at the short term - all it does is spend money to reduce profits- but it's often a good idea to come in from outside and build the competition to the entrenched, inefficient market leader..
Since the 1970s there have been quite a few new, smaller mills built here using the latest (IIRC NUCOR was one of the first examples) but they still have to work hard to compete with the lower costs elsewhere - lower wages, lower land prices, etc. So it's an uphill battle, and that kind of dominance after WWII was a one-time deal.
One of the side-effects of the loss of those two-mile-long mills in the Pittsburgh area is that the side has become clean. When I lived there (early 1990s) the Carnegie Library and Museum was being scrubbed. The building had been black for 80 years or so. After scrubbing it turned out to be blond! I saw pictures from the 1950s where it was too dark and smoky to see across the street in downtown Pittsburgh. And those big mill areas along the rivers are now available to be turned into parks, housing, light industry, clean industry, whatever. But of course, there aren't many jobs. The population of Pittsburgh now is about 1/3 what it was in 1965. Houses are (or at least were) cheap.
I think that happens a lot. It happened to me. I co-founded an imaging company back in 1983 based on my idea for connecting a high speed CCD camera to an advanced workstation - bleeding edge stuff at the time. A few months later the company was already doing well, and my associate (a sales guy) and I brought in a new CEO who brought some VC money with him. I left in frustration three years later as the CEO was mismanaging the place horribly, although he did mange to keep bringing new investment money into the company. The history of the company as of a year or two after that was how the CEO had taken an interesting project by a couple of engineers and single-handedly created a company to bring it to fruition - literally our efforts merited part of a single sentence in a ten page history.
The last laugh was that after I left (I had been VP of R&D), in the next two years they went through seven VPs of R&D (I guess I wasn't doing such a bad job!), and spent most of the 1990s fighting a series of battles against financial types who were trying to force them into bankruptcy - people that the CEO had originally brought in to invest in the company. The financial shenanigans were rather distressing to me. In a short conversation about 1999, the CEO of the then-defunct company agreed that the three major things I had recommended, and he had rejected finally triggering me to quit, were all correct - but as he said, "I hadn't been forceful enough to convince him!" - sigh. And he spent ten years fighting in court instead of doing other fun things.
I still feel there was a good legacy. My track record in managing the engineering side was that we were technically successful on every project, usually under budget, and had excellent morale. I'm still friends with folks that I originally hired there. And we did some really great work in vectorizing, OCR and entity recognition for large format maps and drawings. We even did some work on constructing 3D models from sets of 2D drawings. We could generate terrain models from USGS maps. I got to tour the Space Shuttle External Tank manufacturing facility, and we built image processors that were two orders of magnitude faster than anything else out there, using chips from the cruise missile program (credit where credit is due - that hardware and a lot of the original code behind the OCR and other recognition capability was done by the Visual Understanding Lab of Bob Thibadeau, research professor at Carnegie Mellon). Of course, all that can now be done by any common desktop in software.
Just to continue this thread, it's been said that the original Emacs was written in TECO, the DEC-10 editor, which also had full access to the operating system's deepest function calls. TECO makes Emacs look like a paragon of user interface perfection. IIRC one of the TECO commands was 'delete line', and the upper case version of the same command was 'reboot' - a rather brute force method of deleting a line.
For those inquiring minds, Here's the link. A quote might be sufficient:
TECO does not really have syntax; each character in a program is an imperative command, dispatched to its corresponding routine. That routine may read further characters from the program stream (giving the effect of string arguments), change the position of the 'program counter' (giving the effect of control structures), or push values onto a value stack (giving the effect of nested parentheses). But there is nothing to prevent operations like jumping into the middle of a comment, since there is no syntax and no parsing.
A classic essay on computer programming, Real Programmers Don't Use Pascal, suggested that a common game for TECO fans was to enter their name as a command sequence, and then try to work out what would happen. The same essay in describing TECO coined the acronym "YAFIYGI", meaning "You Asked For It You Got It" and thus being the antitheses of WYSIWYG ("What You See Is What You Get").
Oddly enough, when I worked for Perq I modified the Sketch program, which also had a transcripting feature, to transmit the data over the LAN to another workstation. It worked both directions so two people could draw simultaneously on both copies of the document. :)
Of course that Sketch program only did black lines & patterns on white background. But it worked fine, even on the early 3 Mbit Ethernet. I would speculate that, using some of the modern ways of modeling shapes (nurbs, quadratic surfaces, etc. - stuff that is used to generate 3D curves, ...) it would not be that difficult or space-consuming in the modern context of memory and disk space. Considering that the brush is moving at human speeds, I think the computer could be constructing the numerics for saving without working too hard. There is a limit, of course. But it's not necessarily required to save every point, only a function that can reconstruct those points.
I know some F500 companies do that. Chevron, for example, back in the late 1990s had their own custom version of Windows. (I haven't been there since, so I don't know if it's still true.) they would also fire you if you opened the computer, or loaded any software onto it. They pushed new software onto your machine any night they felt like it.
It reminded me of Mordor when I visited the company.
That could make for a very interesting theme. :) 'Jesus' on the save button, 'Dawkins' on the close-without-saving. :D
Related example - old Harley Davidsons leaked oil all the time but would last essentially forever, requiring maintenance the whole time. My 1982 Honda 900 Custom never leaked oil, required minimal maintenance and everything fell apart at the same time at 100,000 miles. Engineering can do that. In the extreme, the folks who build race cars and race boats etc. keep taking weight out of a part until it breaks, then add a bit more weight back in. It only has to last long enough to finish the race - everything else is a waste. I personally prefer some maintenance and a vehicle that could last long enough to justify the amortized environmental cost of the resources.
I was just talking with someone whose two-year-old knows how to get into her iPhone and play games on it. Pretty much self-taught. Occasionally calls random numbers in France, which isn't so good.
I recall the highly-tweaked VMS that we used back in the day had two nice features regarding files. File saving could be set up so that each version of the file was saved with a trailing semicolon and a version number, so you could go back to any of those versions. Of course modern version control is better. The other was a nice owner-group-project permissions system (Unix has a poor relative mechanism). As one moved between projects in the day one just did a 'change project' (rather like chgrp on Unix), and the access to the files would change. Also the system accounted for time and cpu etc. on that basis, so projects could be billed accordingly for one's own time and resource usage.
That application would be an excellent candidate for change control. Every change should be tracked, including the IP address from whence it came. An audit trail, IOW. Just in case.
Back in the day, the Perq workstation's text editor had a modification transcript that it kept. If bad things happened, you could 'play' the transcript, and watch yourself work. If, for example, the system lost power, when you restarted the transcript would contain every change typically up to the last block write, so you'd have lost maybe only the last half dozen changes.
One time I was in the zone, and edited a file for almost 30 hours without saving (dumb, but hey...) The machine went south, and I lost it all. But I was able to play the transcript back and only lost a half-hour's work. I actually asked the Vim forum about ways to do this, and the nice folks there suggested ways it could be implemented as a plug-in but I haven't pursued it - my own laziness abounds.
Funny thing, I sometimes suspend my GVim session and go home from work. Then I come back in the morning, and I can use 'undo' back a few steps to remind me where I left off, then go forward to the end so I can continue. Of course I saved before I left ... usually!
He does have a narrow point - old radios had buttons that physically pushed in, and only one could be in at a time. A rather complicated mechanical linkage accomplished this. Now the state is identified by something in the display, typically.
I know that there are pieces of equipment around my house that have physical buttons that pop in and out according to which one is set but I can't think what they are offhand.
well, they don't physically jump in and out, but I think every car radio still has preset station buttons.
Which reminds me - I still miss the old Apple keyboards with the physical Caps Lock key. Since that's a special case of setting a state, it was very nice to have that tactile feedback. Little lights in arbitrary places do not suffice.
Just make them all the same shape. Avoids confusion, all that pesky learning. Just guess what it does! If you guess right, the file is saved. If not, it sucks for you! Just to make things interesting, change their positions randomly.
Experts agree... the English language is fucked.
Which, oddly enough, is partly why it is so successful. English is the 'open source' of languages. Anybody can 'edit' it, adding new terms, letting others fall out of usage. It adopts features from every other languages shamelessly, squeezing them in anyplace where they kinda make sense. It is an example of the 'bazaar' method of design. It will never be pure, never by clean, never be well-structured, but it will continue to muddle through.
To the point, a quote from Andrew Jackson: "It's a damn poor mind that can only think of one way to spell a word!" - perhaps the earliest example of the sentiment more recently expressed regarding Perl: "There's more than one way to do it."
My only gripe with this is that I have to wait for a result even on todays machines. There's no good reason it couldn't be fast on a 15 year old Pentium let alone one made last year. Is it really choking on the data set of a single application menu or is there more to it then that?
wandering off topic, I'll speculate (or rather, educatedly-guess) that this is the unintended consequence of highly nested object-oriented programming. All of that object creation for each menu, then each item in the menu costs.
Emacs FTW!! :D (old farts will know what I mean.)