Timeline for Did the IBM 7030 "Stretch" influence the design of PL/I?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 26, 2021 at 22:36 | comment | added | Raffzahn | @wizzwizz4 the first point is about a claim, which has no foundation beside the OP's assumption - quite of an 'armchair historian' thing, if you like that term. Not every random fantasy claim can be debunked by some (more or less authoritative) source - this doesn't make it true in any way. This is where common sense must prevail. The second (after the divider!) is about the rather tedious claim of being 'unnatural' to a /360 - isn't the whole point of a HLL is to be not machine specific? C is, as shown many times, a bad example, as it stems from B which was, on purpose, machine specific. | |
| Jun 26, 2021 at 22:02 | comment | added | wizzwizz4♦ | I don't think this answers the question. (Ref the meta discussion “Can we do something to discourage ‘armchair history’ answers?”.) Just because you or I would design the language that way regardless of the hardware (and, in fact, my toy language for modern machines does work this way, despite no hardware influence), that doesn't mean that's what happened. | |
| Jun 18, 2021 at 15:58 | comment | added | Raffzahn | @alephzero Then it would be interesting to see they analysis why is didn't work. Especially if it's due the language, or specific differences in implementation due different compiler? | |
| Jun 18, 2021 at 15:35 | comment | added | alephzero | "The result is a machine independent definition that allows portage of programs between vastly different architectures without the need to rewrite anything" Cue hollow laughter from anyone who actually tried to do that for non-trivial application code. It simply didn't work. We tried, more that once, with several different target machines and compilers. The success rate was exactly zero (in binary or decimal). | |
| Jun 18, 2021 at 14:36 | comment | added | John Doty | It's entirely possible that there are early documents referring to planned implementations on variable word length hardware. Some who recall the discussions may still be alive. | |
| Jun 18, 2021 at 14:21 | comment | added | Raffzahn | @JohnDotyThen the question is faulty in what it asks for. Something not being an influence can not be proven for anything that happened later than the postulated influence. The main point here is that there is no need for an influence of some (already at that time) exotic machine when the basic idea, as communicated in all documentation, is to be universal and not based on specific implementation. (The only, albeit weak, argument that can be made against the 7030s variable bit length is that precision > 64 bit is allowed - and of course that this as well works with float) | |
| Jun 18, 2021 at 14:08 | comment | added | John Doty | I don't think this answer really addresses the question. We know that the 7030 worked, but failed spectacularly as a commercial product. We know that PL/I worked, but failed (less spectacularly) as a commercial product. Defending the variable bit count idea as sensible doesn't address the question: clearly, both the designers of the 7030 and PL/I, who weren't stupid, thought it sensible. The question isn't whether or why they were wrong, but was there an influence? | |
| Jun 18, 2021 at 13:55 | comment | added | John Doty | Let us continue this discussion in chat. | |
| Jun 18, 2021 at 13:53 | comment | added | Raffzahn | @JohnDoty The same way because McD prevails - cheap and ready available. Same with C and Unix. When one gets the compiler and tools in source, for free, it's easy to invest a lot of time to get it somehow to run (emphasis on somehow). Especially if your department is cash strapped anyway. And the same repeated with the C64. Withotut any doubt a mediocre machine with next to non existent support - but dirt cheap, perfect for people with more time than money. | |
| Jun 18, 2021 at 13:42 | comment | added | John Doty |
I would argue that C's type system is much clearer than PL/I's. Quick, without consulting a manual, if I give you FIXED BIN X;, what is the type of X/3?
|
|
| Jun 18, 2021 at 13:40 | comment | added | John Doty | Then why did all the practically portable C programs out of Bell Labs and Berkeley dominate the space that PL/I was targeted for? | |
| Jun 18, 2021 at 13:35 | comment | added | Raffzahn | @JohnDoty Rare corner case? 12 vs. 16 vs 18 bit Int vs. long vs. short was anything but not a rare corner case. It was daily porting crap. Exactly because there was no clear type system like in PL/I. In PL/I tuning was only needed for performance, not for function. In all cases I encountered PL/I was way less an issue than C. C only became kind of portable after all major architectures became more C compatible. Still, the problems have never been eliminated, only covered by many layers of 'best practice' | |
| Jun 18, 2021 at 13:06 | comment | added | John Doty | C was absolutely not bad at portability compared to PL/I. When UNIX first came out, it was rapidly ported to a variety of architectures with little difficulty (compare to Multics). But I never saw a PL/I program that was practical to run on both GE/Honeywell and IBM hardware. You had to tune your code to the specific machine in PL/I, but C doesn't need that except in relatively rare corner cases. | |
| Jun 18, 2021 at 12:59 | comment | added | Raffzahn | @JohnDoty It seems you issue is about performance of code generated and twisting compiler behaviour. In that case Assembler should be considered, not a language with portability in mind. Something C was notoriously bad at. Of course it pays to use data definitions that match the basic operations provided by a machine - but it only pays out for that specific machine. | |
| Jun 18, 2021 at 12:55 | comment | added | John Doty |
In practice, quite difficult to use. Things like being careful to never let arithmetic promote precision beyond what fit in a register. I recall writing a lot of fixed bin(17) declarations to avoid expensive, extraneous code. Telling learners "never, ever, use / to divide fixed point, always use divide". All kinds of gotchas. C was such a breath of fresh air after that: just give me data types that behave simply, efficiently, and predictably.
|
|
| Jun 18, 2021 at 12:52 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 160 characters in body
|
| Jun 18, 2021 at 12:47 | history | answered | Raffzahn | CC BY-SA 4.0 |