Wrote autocoder for the IBM 7070 at Brown University in September 1965. Wrote a little PHP today.
In between: IBM/360 Assembler, FORTRAN, PL/I, PL/S, BASIC, Bruin, Pascal, Modula-2, COBOL, Forth, Snobol, Jovial, CMS-2, HAL/S, Javascript, AN/UYK-20 assembler, and the best by far of all of them: Ada.
I can't speak for Alice, but I'm getting sick and tired of having to do half of the encryption in the world. Most of the time it's just Lorem Ipsum anyway. I do this by moving rocks around in a desert, you know. It's not fun.
Lockmart is complicated. My division of Unisys was bought by the Carlyle group, which also bought IBM's Federal Systems division, combined the two, and sold the result to Loral. They stirred in some other fragments of defense contractors and sold the result to Lockheed. I'd left Unisys before they sold us, so was surprised to get a call from Lockheed asking why I wasn't drawing my pension. Those two shards of Unisys and IBM had some very good people in them, something I knew both from working in the Unisys group and overseeing the IBM group when I was at MITRE.
I was in the Ada community starting with Strawman in the mid-70s. A fair amount of our language design was intended to overcome the failures of management by both DoD PHBs and contractor PHBs. Ultimately, military use of Ada faltered because of the desire of the defense industry to de-skill the programming task. They wanted to pay C++ coder salaries, not software engineer salaries. Ada survives in places that want to do highly-reliable, life-critical systems, increasingly in Europe rather than here.
I'm unclear how widespread deployment of this weapon would have altered the course of any of the wars we've waged during my lifetime.
And I'm 68 years old.
PARC was wonderful at the conceptual stage, but never could do the hard work to come up with a viable product. I was involved in the effort to make the Alto workstation, Ethernet, and Xerox printer into a commercial word processing system suitable for the office (OIS in El Segundo). We discovered quickly that the software produced by PARC was at the level of a grad student's thesis project; it was no more than 10% of a finished product. For example, the MESA compiler had been declared ready for commercial use because it was able to compile itself. It was a wonderful language, served as a basis for Modula-2, Java, and Ada, but the compiler itself was usable only by compiler writers.
Xerox PARC produced wonderful, important concepts, but I'm unable to think of a single important commercial product that came from there. Dynabook is just another example.
One of the first hypertext processors, a WYSIWYG text system written at Brown U. in 1967-1969, had a feature called an Electric Blackboard that allowed the user to build tables of numbers with various kinds of automatic summing/averaging of the rows and columns. You could select an individual entry with the light pen (IBM 2250), change it, and the calculated entries would automatically update. I've heard that this feature was used to establish prior art when VisiCalc and SuperCalc were duking it out in court a decade later. The feature used the expression evaluation engine from the BRUIN language, an interactive language interpreter also developed at Brown.
One of the undergraduates working on the project was Bob Wallace, later an early employee of Microsoft and developer of PC-Write and the concept of shareware.
I've been involved with Ada since the DoD-1 "Strawman" requirements document. A couple of points I haven't seen mentioned in these comments:
1. Ada lets me say clearly what my code is supposed to be doing in the code itself; I don't have to write coding tricks, I don't have to write comments that explain what the code really does. I can write code that I can read a year from now or some other coder can read ten years from now and we'll both know what it does. Sure, I can still write obscure, obfusticated code, as can anyone who doesn't care about the long term, but it lets me do it right if I want to. Other languages fall short of this.
2. Ada turned out to be a language for software engineers, not coders. The two guys who were its chief architects, Jean Ichbiah of Honeywell and Tucker Taft of AdaCore, were/are consummate software engineers (Jean did the first version, Ada83, died about 5 years ago; Tucker did Ada95, 2005, and 2012). In general, the more educated and experienced you are as a software engineer, the more you'll like Ada.
3. In my opinion, the military use of Ada failed because good Ada programmers are not psychologically suited to work for big defense contractors. Likewise, big defense contractors don't want to pay people who write code the kind of money that good Ada programmers are worth. So they hire five cheap coders instead and it takes them seven times as long to do the coding. (It's a good thing that funding for Defense is unlimited.)
4. Ada also suffered from the COTS (Commercial Off The Shelf) fad that swept the military in the 90's. If any coding was needed and possible, it tended to be Visual Basic or C++. The closest we got was PL/SQL (Ada-derived).
Will Ada ever make a come-back? Probably not; the urban legends about it being complex, designed by a committee, and militaristic will overcome its ability to be more reliable and cheaper over the life-cycle. I can only hope that all the life-critical software I encounter -- airplanes, medical equipment, my 2021 self-driving Toyota -- is coded in Ada.
I was involved in a project to make PARC products -- the Alto, Ethernet, and laser printer -- into a commercial product in the mid-to-late 70's, at Xerox in El Segundo. The hardware was amazing; I remember the thrill when they wheeled my Alto into my office, pushed aside a ceiling tile, and connected it to a big black cable called the Ethernet. It was quite obviously a minicomputer, not a microprocessor-based personal computer, similar to Digital's PDP-8 and the DG Nova-2 (as Animats said above). I'd used a mouse years before at Englebart's, so it was great to see a manufactured version, but disappointing that it lacked Doug's chord keyboard and three mouse keys for typing ASCII in binary. We knew nothing about the costs of the hardware; we were concerned with the software.
And the software stank. All of the pretty demos running on the Alto were coded at the grad-student level, utterly unusable for a commercial product. For example, the MESA compiler, for the language in which some of the software was written, had been tested only to the extend that it would compile itself. (Most of the Alto s/w was coded in BCPL. Fun facts: the predecessor of C was B; its successor should have been P and the one after that L.) The OIS project to commercialize the Alto blew up to a few hundred people and just as quickly blew away on an early Santa Ana.
I would suggest that Xerox as a company and PARC as a specific part of it failed because they were unable to write commercial-level software.
We've actually known about the radiation problem for quite some time. We plan to use it on/. commenters who have at any time posted anything about elevator music, pushing all million buttons, or people farting in the elevator.
Everything I've read about the Space Elevator idea declares that the Centre of Mass of the entire system *must* be in Geostationary orbit
Everything you've read has been wrong; you could be a Firesign Theater cover. By my calculations, the "center of mass" of a 100,000 km SE -- the point at which half of the mass is higher and half is lower -- is at about 83,000 km. This has absolutely nothing to do with anything. The SE is not in orbit, not geostationary orbit or any other kind.
The SE is held up by centrifugal force acting on all of its mass, and pulled downward by the Earth's gravity also acting on all of its mass. Gravity drops off quickly as you get higher (inverse square) and centrifugal force builds up slowly (linearly). At 35,800 km up (GEO), the two are equal and opposite. So we have to get enough mass far enough beyond GEO so that the total centrifugal force is greater than the total gravitational force. That's why the counterweight has to be so far beyond GEO. (At 100,000 km, the counterweight is feeling an effective gravity of -0.05 g.)
Note, too, that centrifugal force has to exceed gravity by at least 20 tons of force, because the SE has to be pulling up on the anchor ship with at least that much strain. Otherwise when we roll out a 20-ton climber and hang it on the ribbon, it'll just sit there on the deck and, instead of pulling itself up, will pull the whole thing down.
Red Mars talks about a space elevator the diameter of a Sequoia, weighing millions or billions of tons. The NASA-proposed space elevator will be a ribbon a meter wide and the thickness of a piece of saran wrap. If it falls, it'll flutter down to the ground. Most of the Equator is ocean, so some fish might momentarily think that night has fallen. Where it "hits" land, it may get tangled in some trees or even buildings. Approximately the environmental impact of a NYC ticker-tape parade.
The climbers going up the SE will be the size of a small bus, about 10 tons, and will go up one per day. It's unlikely any will come down the SE; standard reentry procedures are much cheaper for that. The very first thing we'll do with an SE is build another, and then another; after a decade or two, there'll probably be a dozen SEs sticking out from the Equator. The first one may cost $10 billion, but the second will be 20% of that.
Pluto and Charon seem to be mutually tide-locked, just as the Moon is to the Earth. If the Earth were also tide-locked to the Moon, the Moon would always be visible from one side of the Earth and never from the other.
You could run a cable from a stationary anchor on Pluto to one on Charon, except for the fact that Charon's orbit isn't a perfect circle. The two always face each other, but they move closer and further apart during each orbit.
The Space Elevator is not/will not be in orbit!!None of it! No part of it! There will be a small section, 35,800 km from the ground, that happens to be traveling at the same velocity and in the same direction as would a satellite in orbit at that point. We can climb up to that level, let go, and just drift around; that point corresponds to what's called Geosynchronous Orbit. Everywhere else if we let go we fall away from the SE. The parts of the SE below that point are traveling slower than orbital velocity where they are, and those above it are traveling faster than orbital velocity. If you go high enough and let go, you'll fall all the way to Mars.
The SE is a rock on the end of a very, very long string, being whirled around by the Earth's rotation. That's what keeps it up -- what's sometimes called centrifugal force. Pulling inward/downward on the string doesn't cause the rock to fall; if the rock is whirling fast enough, it won't even be pulled down, and when you stop pulling, the rock is still there. There's no real notion of "center of mass" of the SE as a whole. The majority of the mass is well above GEO.
The "rock" will actually be all the construction machinery that was used to build the SE, a few hundred machines that climb it and add a tiny bit of material all along its length while they're going up. They will have a total mass of about 650 tons and be at an altitude of 100,000 km. The CNT ribbon will have a mass of about 950 tons. We'll be able to send up a 20-ton climber with a 13-ton payload every four days, or a 10-ton climber with a 6.5-ton payload every day. (Gravity falls off so quickly that a given climber is down to 50% of its weight when it's 2600 km up. That's what makes it possible to send up smaller climbers more often than you'd expect.)
AT&T Bell Labs invented UNIX, C, the transitor, and countless other things... Google has a great text searching program. They didn't even really "invent" it either.
UNIX is Multics (from MIT) cut to the bone; C is BCPL with hints of FORTRAN and Algol. The transistor is... well, ever build a crystal radio? They did invent the AN/UYS-2.
On the other hand, twenty years from now we'll all have wireless Google links embedded in our skulls.
IBM 7070 -- 5000 words of ten decimal digits each, with a cycle time of ten microseconds (0.0001 GHz). Disk storage: we don' need no stink'n disks. It had an attached IBM 1401 I/O processor so that it wouldn't have to use its blinding speed to do paper tape reading and printing. Cost maybe $5 million in today's dollars. (Brown University, 1965)
When I was at Prime in the early 80's, there was talk about acquiring a little company on the West Coast that was making pizza-box computers. The software people were mostly in favor, seeing the machines as being a good platform for Primos (sometimes described in those days as "Multics in a matchbox"). The hardware people were opposed, however, and they eventually prevailed. PR1ME itself failed to prevail; I've always blamed the stupid way they spelled their name.
I started punching assembler onto cards for the IBM 7070 in 1965, did graphics and hypertext with Andy van Dam at Brown (both of those turned out to be useful in the long term). Since then I've worked all over the world doing (mostly) interesting projects from Spacelab to Sonar. So now I'm 60, know maybe three dozen languages, and have designed and implemented literally a hundred systems -- I can do it in my sleep. If you need, say, a complex web system with 20K lines of PHP and SQL driving PostgreSQL in two months, I'm your last, best hope, but it'll cost you. My best customers are those who've tried to do the project in-house with punk-kid programmers or by out-sourcing to India.
It's not really about programming ability, you know. It's having a wide and deep familiarity with a lot of different design and implementation approaches, being able to talk to users and IT managers, and having a sufficiently-long attention span.
I used an old refrigerator compressor to pump up a small tank (~2 cubic feet), taking about two hours to do so. Then I released the compressed air through a hand-carved lucite chamber in the correct spiral shape. Got about 50 C temperature differential on the two output arms, for about 30 seconds. This was in 1962.
A space elevator would be about the cheapest way up in theory provided you write of the energy cost of building the damn thing over a long lifetime.
The energy cost of building the first space elevator would be approximately that of five Delta IV launches or three STS launches. The energy cost of building the second and subsequent ones would be a small fraction of that because (obviously) you'd use the first one to do so. Energy costs are minor.
Unless, of course, you're talking about the science fiction version of a space elevator, the multi-billion-ton beanstalk. Note too that each space elevator sequesters about a thousand tons of carbon.
I can't think of any sense in which any of the LaGrange points, either Earth-Moon or Sun-Earth, could be called "chokepoints." A tiny, tiny fraction of possible orbits and trajectories go through or near them, but there's no problem at all in avoiding them, and no reason any such avoidance would be more expensive.
We do have probes at the S-E L1 and L2 (I think) points; S-E L2 is the planned location for the Hubble follow-on, the James Webb Space Telescope. (Btw, it's about 1.5 million kilometers away from Earth). E-M L1 would be very useful for a Lunar-anchored space elevator, as would E-M L2 to a lesser extent. (The L1 elevator would be held up by an entirely different principle than a terrestrial SE.)
Describing the LaGrange points as intersections in space where gravitational and centrifugal forces balance out to provide orbital stability is pretty useless; that's true of any point on any stable orbit. It's pretty much the definition of "orbit."
Does anyone, anywhere ever review code for readability? We all know that code reading, be it in eXtreme programmer pairs or more formal CMM processes, is as close as we've come to a Silver Bullet for programming. With all that review going on, does anyone have built into their processes a review specifically for how easy or hard the code is to understand?
I worked for a great little company named SofTech many years ago, where we developed an analysis and design methodology named SADT (aka IDEF-0). One of the important parts of it was a set of steps to make sure that the documents being produced were readable and understandable, under the philosophy that something that was correct but impossible to understand was a lot less useful that something that was wrong and understandable. For the latter, you could tell it was wrong and figure out how to make it correct.
It's always seemed to me that this is one of the major parts missing from Open Source. Note that this makes moot the question of whether you make it understandable by writing lots of comments or by using a good programming language; either one will pass the test.
Wait, the error's a layout error in a spreadsheet that you created? (Or at least listed the contents of?) So you weren't commenting on the article at all, but merely showing us how to make an error in a spreadsheet? Why then did you quote part of the article? The obvious implication of what you wrote was that the article was in error, which it was not. You can't make an error in spreadsheet layout/presentation if you don't have a spreadsheet.
Btw, my opinion of the Y2K incident, based on 39 years in the field, is that it wasn't "silly." We anticipated the problem, made a roughly-accurate estimate of the consequences of not fixing it, and then we fixed it. That's why the predictions didn't come true.
Slashdot Mirror
Wrote autocoder for the IBM 7070 at Brown University in September 1965. Wrote a little PHP today. In between: IBM/360 Assembler, FORTRAN, PL/I, PL/S, BASIC, Bruin, Pascal, Modula-2, COBOL, Forth, Snobol, Jovial, CMS-2, HAL/S, Javascript, AN/UYK-20 assembler, and the best by far of all of them: Ada.
I can't speak for Alice, but I'm getting sick and tired of having to do half of the encryption in the world. Most of the time it's just Lorem Ipsum anyway. I do this by moving rocks around in a desert, you know. It's not fun.
Lockmart is complicated. My division of Unisys was bought by the Carlyle group, which also bought IBM's Federal Systems division, combined the two, and sold the result to Loral. They stirred in some other fragments of defense contractors and sold the result to Lockheed. I'd left Unisys before they sold us, so was surprised to get a call from Lockheed asking why I wasn't drawing my pension. Those two shards of Unisys and IBM had some very good people in them, something I knew both from working in the Unisys group and overseeing the IBM group when I was at MITRE. I was in the Ada community starting with Strawman in the mid-70s. A fair amount of our language design was intended to overcome the failures of management by both DoD PHBs and contractor PHBs. Ultimately, military use of Ada faltered because of the desire of the defense industry to de-skill the programming task. They wanted to pay C++ coder salaries, not software engineer salaries. Ada survives in places that want to do highly-reliable, life-critical systems, increasingly in Europe rather than here.
ERAM is written in Ada.
I'm unclear how widespread deployment of this weapon would have altered the course of any of the wars we've waged during my lifetime. And I'm 68 years old.
Xerox PARC produced wonderful, important concepts, but I'm unable to think of a single important commercial product that came from there. Dynabook is just another example.
One of the first hypertext processors, a WYSIWYG text system written at Brown U. in 1967-1969, had a feature called an Electric Blackboard that allowed the user to build tables of numbers with various kinds of automatic summing/averaging of the rows and columns. You could select an individual entry with the light pen (IBM 2250), change it, and the calculated entries would automatically update. I've heard that this feature was used to establish prior art when VisiCalc and SuperCalc were duking it out in court a decade later. The feature used the expression evaluation engine from the BRUIN language, an interactive language interpreter also developed at Brown.
One of the undergraduates working on the project was Bob Wallace, later an early employee of Microsoft and developer of PC-Write and the concept of shareware.
1. Ada lets me say clearly what my code is supposed to be doing in the code itself; I don't have to write coding tricks, I don't have to write comments that explain what the code really does. I can write code that I can read a year from now or some other coder can read ten years from now and we'll both know what it does. Sure, I can still write obscure, obfusticated code, as can anyone who doesn't care about the long term, but it lets me do it right if I want to. Other languages fall short of this.
2. Ada turned out to be a language for software engineers, not coders. The two guys who were its chief architects, Jean Ichbiah of Honeywell and Tucker Taft of AdaCore, were/are consummate software engineers (Jean did the first version, Ada83, died about 5 years ago; Tucker did Ada95, 2005, and 2012). In general, the more educated and experienced you are as a software engineer, the more you'll like Ada.
3. In my opinion, the military use of Ada failed because good Ada programmers are not psychologically suited to work for big defense contractors. Likewise, big defense contractors don't want to pay people who write code the kind of money that good Ada programmers are worth. So they hire five cheap coders instead and it takes them seven times as long to do the coding. (It's a good thing that funding for Defense is unlimited.)
4. Ada also suffered from the COTS (Commercial Off The Shelf) fad that swept the military in the 90's. If any coding was needed and possible, it tended to be Visual Basic or C++. The closest we got was PL/SQL (Ada-derived).
Will Ada ever make a come-back? Probably not; the urban legends about it being complex, designed by a committee, and militaristic will overcome its ability to be more reliable and cheaper over the life-cycle. I can only hope that all the life-critical software I encounter -- airplanes, medical equipment, my 2021 self-driving Toyota -- is coded in Ada.
I was involved in a project to make PARC products -- the Alto, Ethernet, and laser printer -- into a commercial product in the mid-to-late 70's, at Xerox in El Segundo. The hardware was amazing; I remember the thrill when they wheeled my Alto into my office, pushed aside a ceiling tile, and connected it to a big black cable called the Ethernet. It was quite obviously a minicomputer, not a microprocessor-based personal computer, similar to Digital's PDP-8 and the DG Nova-2 (as Animats said above). I'd used a mouse years before at Englebart's, so it was great to see a manufactured version, but disappointing that it lacked Doug's chord keyboard and three mouse keys for typing ASCII in binary. We knew nothing about the costs of the hardware; we were concerned with the software.
And the software stank. All of the pretty demos running on the Alto were coded at the grad-student level, utterly unusable for a commercial product. For example, the MESA compiler, for the language in which some of the software was written, had been tested only to the extend that it would compile itself. (Most of the Alto s/w was coded in BCPL. Fun facts: the predecessor of C was B; its successor should have been P and the one after that L.) The OIS project to commercialize the Alto blew up to a few hundred people and just as quickly blew away on an early Santa Ana.
I would suggest that Xerox as a company and PARC as a specific part of it failed because they were unable to write commercial-level software.
We've actually known about the radiation problem for quite some time. We plan to use it on /. commenters who have at any time posted anything about elevator music, pushing all million buttons, or people farting in the elevator.
The SE is held up by centrifugal force acting on all of its mass, and pulled downward by the Earth's gravity also acting on all of its mass. Gravity drops off quickly as you get higher (inverse square) and centrifugal force builds up slowly (linearly). At 35,800 km up (GEO), the two are equal and opposite. So we have to get enough mass far enough beyond GEO so that the total centrifugal force is greater than the total gravitational force. That's why the counterweight has to be so far beyond GEO. (At 100,000 km, the counterweight is feeling an effective gravity of -0.05 g.)
Note, too, that centrifugal force has to exceed gravity by at least 20 tons of force, because the SE has to be pulling up on the anchor ship with at least that much strain. Otherwise when we roll out a 20-ton climber and hang it on the ribbon, it'll just sit there on the deck and, instead of pulling itself up, will pull the whole thing down.
The climbers going up the SE will be the size of a small bus, about 10 tons, and will go up one per day. It's unlikely any will come down the SE; standard reentry procedures are much cheaper for that. The very first thing we'll do with an SE is build another, and then another; after a decade or two, there'll probably be a dozen SEs sticking out from the Equator. The first one may cost $10 billion, but the second will be 20% of that.
You could run a cable from a stationary anchor on Pluto to one on Charon, except for the fact that Charon's orbit isn't a perfect circle. The two always face each other, but they move closer and further apart during each orbit.
The SE is a rock on the end of a very, very long string, being whirled around by the Earth's rotation. That's what keeps it up -- what's sometimes called centrifugal force. Pulling inward/downward on the string doesn't cause the rock to fall; if the rock is whirling fast enough, it won't even be pulled down, and when you stop pulling, the rock is still there. There's no real notion of "center of mass" of the SE as a whole. The majority of the mass is well above GEO.
The "rock" will actually be all the construction machinery that was used to build the SE, a few hundred machines that climb it and add a tiny bit of material all along its length while they're going up. They will have a total mass of about 650 tons and be at an altitude of 100,000 km. The CNT ribbon will have a mass of about 950 tons. We'll be able to send up a 20-ton climber with a 13-ton payload every four days, or a 10-ton climber with a 6.5-ton payload every day. (Gravity falls off so quickly that a given climber is down to 50% of its weight when it's 2600 km up. That's what makes it possible to send up smaller climbers more often than you'd expect.)
On the other hand, twenty years from now we'll all have wireless Google links embedded in our skulls.
(I wanted just to say that one word five times, but the "compression filter" didn't like it. Not a reader, apparently.)
IBM 7070 -- 5000 words of ten decimal digits each, with a cycle time of ten microseconds (0.0001 GHz). Disk storage: we don' need no stink'n disks. It had an attached IBM 1401 I/O processor so that it wouldn't have to use its blinding speed to do paper tape reading and printing. Cost maybe $5 million in today's dollars. (Brown University, 1965)
Sun + Apple = Schnitz (dried apples) You get cider by crushing apples, not drying them in the Sun.
When I was at Prime in the early 80's, there was talk about acquiring a little company on the West Coast that was making pizza-box computers. The software people were mostly in favor, seeing the machines as being a good platform for Primos (sometimes described in those days as "Multics in a matchbox"). The hardware people were opposed, however, and they eventually prevailed. PR1ME itself failed to prevail; I've always blamed the stupid way they spelled their name.
It's not really about programming ability, you know. It's having a wide and deep familiarity with a lot of different design and implementation approaches, being able to talk to users and IT managers, and having a sufficiently-long attention span.
I used an old refrigerator compressor to pump up a small tank (~2 cubic feet), taking about two hours to do so. Then I released the compressed air through a hand-carved lucite chamber in the correct spiral shape. Got about 50 C temperature differential on the two output arms, for about 30 seconds. This was in 1962.
Unless, of course, you're talking about the science fiction version of a space elevator, the multi-billion-ton beanstalk. Note too that each space elevator sequesters about a thousand tons of carbon.
We do have probes at the S-E L1 and L2 (I think) points; S-E L2 is the planned location for the Hubble follow-on, the James Webb Space Telescope. (Btw, it's about 1.5 million kilometers away from Earth). E-M L1 would be very useful for a Lunar-anchored space elevator, as would E-M L2 to a lesser extent. (The L1 elevator would be held up by an entirely different principle than a terrestrial SE.)
Describing the LaGrange points as intersections in space where gravitational and centrifugal forces balance out to provide orbital stability is pretty useless; that's true of any point on any stable orbit. It's pretty much the definition of "orbit."
I worked for a great little company named SofTech many years ago, where we developed an analysis and design methodology named SADT (aka IDEF-0). One of the important parts of it was a set of steps to make sure that the documents being produced were readable and understandable, under the philosophy that something that was correct but impossible to understand was a lot less useful that something that was wrong and understandable. For the latter, you could tell it was wrong and figure out how to make it correct.
It's always seemed to me that this is one of the major parts missing from Open Source. Note that this makes moot the question of whether you make it understandable by writing lots of comments or by using a good programming language; either one will pass the test.
Btw, my opinion of the Y2K incident, based on 39 years in the field, is that it wasn't "silly." We anticipated the problem, made a roughly-accurate estimate of the consequences of not fixing it, and then we fixed it. That's why the predictions didn't come true.