Live data from Hacker News

“It is never a compiler error”

blog.plover.com

261–270 of 280 posts

Re: “It is never a compiler error”

#261

When I was just getting into the industry, I was offered a job from a team at IBM, working on some OS or other whose name I forgot. I was chatting with the head developer about the workflow. He told me that, as the OS was written in a custom programming language, and the OS was the only program ever written in this programming languages, they found that roughly 50% of the bugs they encountered were in the OS code, an…

Comments here seem to indicate a lack of familiarity with IBM's contributions to our field. I used to work at IBM (as an OS architect) and I just thought that I would provide a few interesting tidbits of IBM's history.

IBM designs, builds, and sells computers. Once upon a time half the installed computers in the world were built by and designed by IBM.

## IBM in the Vacuum Tube Age[4] (1942-1963):

These computers were produced in such small numbers and ran primitive OS's that did little more than load programs into memory and handled the a few simple devices (card/paper tape reader and printer).

(1952) IBM 701 -- Defense Calculator (they still called computers calculators)

(1953) IBM 702 -- business computer

(1954) IBM 650 -- first mass produced computer, used a magnetic drum for memory, decimal architecture

(1954) IBM 704 -- first mass produced with floating-point

(1954) IBM 705 -- evolution of 702, for business

(1954) IBM NORC -- Navy Ordnance Research Calculator (most powerful computer in the world for 2 years, 9800 tubes)

(1956) IBM 305 -- first commercial computer with a moving head disk drive

(1958) IBM 709 -- FORTRAN first ran on this computer

## IBM in the Transistor Age[5] (1955-1968):

(1957) IBM 608 -- took years to develop, it was first demo'd in 1954

(1959) IBM 7090

(1959) IBM 1401 -- first computer to sell 10,000 units, eventually about half of the worlds computers were IBM 1401, see [1]

(1959) IBM 1620

(1960) IBM 4020

(1960) IBM 7070

(1961) IBM 7030 Stretch -- supercomputer

(1962) IBM 7094

(1963) IBM 7040

(1964) IBM 7094 II

(1965) IBM M44/44X

(1965) IBM 1130 -- IBM's least expensive computer at the time ($32,000 in today's dollars)

This is where programming languages and OS's get interesting. During this period manufacturers began developing OS's, Programming Languages and Compilers for their customers. Although, some customers in the Vacuum Tube age wrote their own simple OS's to help run their machines the computers of the transistor age had more capacity, were faster, and had a wider range of users. This meant that manufacturers had to provide system software with the computers they sold. Almost all system software of this time was written in assembly language. The first operating system code that I studied was in assembler. Some of IBM's Operating Systems from this time period (see [6]) were IBSYS (originally developed by General Motors to run their 701, IBM took over development of this OS) and the FORTRAN Monitor System for the 709, 7090 and 7094, a tape storage based OS.

I never got to program on any of the vacuum tube older systems although I think I wrote some FORTRAN for a 1401 (it's harder to remember because being a junior programmer I rarely got to even touch these expensive systems, you would drop off your drawer of cards at a window for the "operators" to load into the computer and then, perhaps 30 minutes later you would pick up the printed output at the output window). I used the IBM 1130 in school and for a few of my first programming jobs in FORTRAN. This was with an IBM OS and and IBM FORTRAN.

## IBM in the Modern Computer Age

By the 60's IBM completely dominated the industry which was described as "IBM and the seven dwarfs" (Burroughs, UNIVAC, NCR, Control Data Corporation (CDC), and Honeywell, RCA, and General Electric); IBM's market share was larger than the competitors combined. IBM's continued to produce new architectures and manufacture computers in great variety. Perhaps the most important mainframe architecture ever (in history) was the IBM 360. I've programmed this computer in IBM COBOL and IBM assembly language.

The IBM/360 evolved into the IBM/4300, IBM/370, and IBM/390, and eventually to the z/Architecture in use today on large enterprise installations (see [2]). Over the decades the hardware changed drastically and the evolution of operating systems meant that IBM had to produce many advanced operating systems to run these multi-million dollar systems. (In 1969 a typical IBM/360 model 25--at the very low end of the 360 line cost $1,753,000 in today's dollars, see [3]). Back in the early 70's I programmed on the IBM/360 in assembly language, PL/1, COBOL, and FORTRAN.

In the modern era, IBM also produced a number of midrange systems: System/3, System/34, System/32, System/38, AS/400, and the IBM i. These machines ranged from the low end System/3 designed to run IBM's report generation language RPG to the pioneering System/38.

The System/38 was an interesting machine with an IBM OS that contained an integrated relational database management system. The System/38 didn't have files, it had a single-level store where information where the distinction between memory and external storage was treated as a single unit. The System/38 was also one of the only commercial computers using capability-based addressing. This unique hardware/OS combination supported programming in IBM's RPG III, COBOL, BASIC, and PL/1.

Up until around 1984, IBM designed and wrote it own operating systems for all of its important computers. IBM had a number of important research projects going on in the 1970s and IBM's John Cocke, credited with inventing RISC although others were also working with these ideas around that time (e.g. the CDC 6600 designed by Seymour Cray in 1964 -- I still have the book I used to learn assembly language programming for the CDC 6600 a very interesting machine). John Cocke's work resulted in an experimental system known as the IBM 801. This inspired the development of the IBM POWER instruction set processors. Due to internal competition, the POWER/PC chip was turned into a system that supposedly would not threaten the important mainframe business.

The original Power/PC running Unix (IBM's AIX version) ran on the new hardware design and was supposed to fit in between the IBM/PC business and the IBM mainframe business. The hardware was brand new and being developed when I joined IBM. The OS was to be Unix based and despite the pressure to "make it better" most of the architects fought to keep it consistent with ATT and Berkley Unix. Unfortunately, the hardware was new, the only compilers that could take advantage of the RISC instruction set were research compilers running the PL/8 (a system programming language that was supposedly the 80% of PL/1 needed for system programming). Because the hardware was not stable, development of the OS was done in two layers. A low level hardware layer coded in PL/8 and the rest of the kernel coded in C.

It was a huge undertaking (from my perspective as a new OS architect), but it worked. AIX/Unix proved itself within the corporation and even the mainframe groups have adopted Linux and AIX for some of there systems. I left IBM to start my own company, but I learned a lot working during those exciting times.

A computer that wasn't that important to IBM was the IBM PC. It wasn't originally considered to be interesting enough to even cover it's hardware with adequate patent protection leading to a proliferation of hardware compatible competitors and indirectly to the age of personal computers. Even in the IBM PC world IBM developed OS/2 and operating system that briefly competed with Windows.

## IBM Software

All of these machines had their own, often unique, operating systems. These were written a variety of languages. IBM's PL/1 programming language lived on in the early versions of the low level kernel of AIX, I don't know if it is still there.

IBM has, in my humble estimation, written more OS's, more compilers, and built a wider variety of computers than any company in history. However, I'm open to evidence of the contrary.

[1] https://web.archive.org/web/20101105110749/http://www.comput...

[2] http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainfra...

[3] http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainfra...

[4] https://en.wikipedia.org/wiki/List_of_vacuum_tube_computers

[5] https://en.wikipedia.org/wiki/List_of_transistorized_compute...

Re: “It is never a compiler error”

#262

“The Pragmatic Programmer” refers to this idea as “select() is broken.”

it's a small typo but changes the meaning completely, it's - Select _"isn't"_ broken

You are right that the other way is more prominent, but both phrases appear in the book; for example,

“We now use the phrase "select is broken" as a gentle reminder whenever one of us starts blaming the system for a fault that is likely to be our own.”

That quote appears right above «Tip 26: “select” isn’t broken.»

Re: “It is never a compiler error”

#263
post #253
post #182

Earlier quoted context omitted.

Mainframes had bounds checks. It didn't cost much, but C omitted them. Some of the undefined behavior in C particularly around accesses and overflow could be changed to implementation defined to fix some of the more footgunny parts. Until C 99 C could not vectorize nearly as much as Fortran. C won because of Unix network effects and the PDP, not because it was that good a choice.

Surely someone had checked loads. The IBM 360/370 did not (unless it was some optional thing they sold -- certainly it wasn't part of the basic architecture), so "mainframes" seems rather spun. Likewise, yes, C's floating point calling conventions sucked and Fortran continued to see use in numerics work for a long time. But at the same time no one was writing performance-sensitive vector code for their Cray's in high…

1 and 2 also seem true for Pascal. Network effects are important but they would have worked for any language. Tony Hoare discussed bounds checking on the Burroughs mainframe.

Re: “It is never a compiler error”

#264

Earlier quoted context omitted.

To be fair, I've also lost count of the number of times my compiler has compiled things correctly. ;)

Which, lets not forget, includes several times every time you load a website.

Please don't remind me...

Re: “It is never a compiler error”

#265
post #155

The article mentions another Coding Horror one at the bottom [0]. I found this tidbit from there interesting: "In Code Complete, Steve McConnell cited two studies that proved it: "A pair of studies performed [in 1973 and 1984] found that, of total errors reported, roughly 95% are caused by programmers, 2% by systems software (the compiler and the operating system), 2% by some other software, and 1% by the hardware. S…

There's a story I heard that I can't track down anymore, about a game company that kept getting strange unreproducible errors from customers. They built a RAM test into their game and discovered that most of those errors were coming from bad RAM. 1% of a lot is a lot!

Doom 3 inadvertently did this for me one time. It loads data from pak/zip files and does a checksum verification. Which is how I discovered a defective RAM stick I'd used in a new system build.

Re: “It is never a compiler error”

#266
post #261

When I was just getting into the industry, I was offered a job from a team at IBM, working on some OS or other whose name I forgot. I was chatting with the head developer about the workflow. He told me that, as the OS was written in a custom programming language, and the OS was the only program ever written in this programming languages, they found that roughly 50% of the bugs they encountered were in the OS code, an…

Comments here seem to indicate a lack of familiarity with IBM's contributions to our field. I used to work at IBM (as an OS architect) and I just thought that I would provide a few interesting tidbits of IBM's history. IBM designs, builds, and sells computers. Once upon a time half the installed computers in the world were built by and designed by IBM. ## IBM in the Vacuum Tube Age[4] (1942-1963): These computers wer…

That was an amazing write-up, thank you! That people are surprised IBM made operating systems makes me feel very old.

Re: “It is never a compiler error”

#267

Earlier quoted context omitted.

AWS is nowhere near as reliable as a compiler. We've seen things ranging from "S3 intermittently takes 60 or 120 seconds (or some multiple thereof)" (but apparently only for my buckets…) to spatial indexes in Aurora just flat out didn't work when they were released, to S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404), to ELBs corrupting the HTTP…

> S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404) That's exactly documented behavior: http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction....

Huh. TIL. I swear we searched the docs when we ran into that, and found the same consistency guarantee minus that rather large caveat, but Wayback says that was there at the time. Perhaps we were looking at a different page, but it does appear this is and was documented behavior.

That's a hugely unuseful caveat in practice though. I'd really love to have consistent reads.

Re: “It is never a compiler error”

#268
post #157

There are more compiler bugs than many ever think. From mainframe COBOL compilers to gcc, I have encountered bugs in programs that were a result of what the compiler did. The original source code did nothing special - it was simple code and due to specific optimisations that the compiler performed, inexplicable seemingly random errors would arise. One would have to constrain the optimisations the compiler would do to…

C++ is notorious for exploiting what is technically undefined behavior to produce unexplainable optimization bugs. Undefined behavior is extraordinarily easy to write into your code without knowing it, and once it's there the compiler is free to do any crazy thing it wants. You think it's a compiler bug because turning off the optimizations fixes it, but it's not.

C++ (and its ilk) is a language that I don't touch with a 40 ft barge pole. Irrespective of the aficionados of the language, it is poorly designed in oh so many ways. I would rather program in BF, befunge, or remorse than C++.

Re: “It is never a compiler error”

#269
post #218

Earlier quoted context omitted.

IBM has built several operating systems and programming languages and compilers over the years. Probably more than Bell Labs, actually. It's not so surprising.

Unix and C is more known, so that would be my assumption too. In fact I can't name any IBM made OSes or programming languages.

FORTRAN. A pretty important one.

Re: “It is never a compiler error”

#270
post #233
post #230

Earlier quoted context omitted.

Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A? What would you say, if I told you that this superpower was not basic Q/A? because basic Q/A is what the compiler is passing, all the time. The part you meant with vigour was the job part right? how do you make somebody want your awesome enough to pay you a living wage? It's either apple or Intel, because they are the t…

If you're the kind of programmer who inputs HTML into a comment system that doesn't support it...

I'm not in QA. You obviously head the snark department very well. Expect promotion, but alas, not much more pay.
Post reply on HN