Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My 1992 view of the problems of computer programming in 1992

blog.plover.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: My 1992 view of the problems of computer programming in 1992

#21

Post by Sharlin »

KptMarchewa wrote: post #5

The definition of "passable compiler" in 1992 must have been very different from what it is today; while third year students write interpreters and compilers, nobody would call them useful or passable.

Languages were simpler (except for certain ones, like C++ which was a beast even in 1992), and incredibly complex and magical optimizers weren’t yet a thing, never mind a feature expected of a "passable" compiler. One could still write a reasonable non-optimizing Pascal or C89 compiler in a weekend more or less, and it would be both faster to write (thanks to more expressive languages) and faster at compiling (thanks to itself being compiled by an optimizing compiler) than in 1992!

Re: My 1992 view of the problems of computer programming in 1992

#22

Post by senfiaj »

Someone wrote: post #15
adamddev1 wrote: post #10

How did we get so much better at writing compilers? Was it a better understanding of how to make syntax trees with ADTs etc?

I think significant improvements are - not writing compilers in assembly - not requiring overlays - knowing how previous compilers produced fast code (Web search doesn’t give me conclusive answers, but that Fortran compiler may have been the first to do loop unrolling and common subexpression elimination) - having way more memory, CPU and disk available - possibly: spending less time looking at optimizations. I expec…

Writing an optimizing production ready compiler doesn't seem to be an easy task, even today. I mean you can fork a compiler or look at the code, but maintaining your own one alone doesn't seem to be realistic.

>> - not writing compilers in assembly

Sure, but you still generate the machine code, right? You still have to master the instructions and their specifics of the target CPUs.

Re: My 1992 view of the problems of computer programming in 1992

#23

Post by bigfishrunning »

senfiaj wrote: post #22
Someone wrote: post #15

Earlier quoted context omitted.

I think significant improvements are - not writing compilers in assembly - not requiring overlays - knowing how previous compilers produced fast code (Web search doesn’t give me conclusive answers, but that Fortran compiler may have been the first to do loop unrolling and common subexpression elimination) - having way more memory, CPU and disk available - possibly: spending less time looking at optimizations. I expec…

Writing an optimizing production ready compiler doesn't seem to be an easy task, even today. I mean you can fork a compiler or look at the code, but maintaining your own one alone doesn't seem to be realistic. >> - not writing compilers in assembly Sure, but you still generate the machine code, right? You still have to master the instructions and their specifics of the target CPUs.

> Sure, but you still generate the machine code, right? You still have to master the instructions and their specifics of the target CPUs.

You do, but self-hosted compilers tend to have two huge benefits:

1) they tend to be easier to reason about, being written in a high-level language

2) they exercise the code, and usually even seldom-used parts of the code, to make problems more noticeable

Re: My 1992 view of the problems of computer programming in 1992

#24

Post by senfiaj »

bigfishrunning wrote: post #23
senfiaj wrote: post #22

Earlier quoted context omitted.

Writing an optimizing production ready compiler doesn't seem to be an easy task, even today. I mean you can fork a compiler or look at the code, but maintaining your own one alone doesn't seem to be realistic. >> - not writing compilers in assembly Sure, but you still generate the machine code, right? You still have to master the instructions and their specifics of the target CPUs.

> Sure, but you still generate the machine code, right? You still have to master the instructions and their specifics of the target CPUs. You do, but self-hosted compilers tend to have two huge benefits: 1) they tend to be easier to reason about, being written in a high-level language 2) they exercise the code, and usually even seldom-used parts of the code, to make problems more noticeable

But once you have written in assembly, you could start to write the next version in the higher level language. The first version (written in assembly) doesn't necessarily have to produce the most optimal code, just good enough and correct. Most of the improvements can be done in the self hosted compiler (in a higher level language). So this period did not have to last many years.

Re: My 1992 view of the problems of computer programming in 1992

#25

Post by dTal »

Sharlin wrote: post #21
KptMarchewa wrote: post #5

The definition of "passable compiler" in 1992 must have been very different from what it is today; while third year students write interpreters and compilers, nobody would call them useful or passable.

Languages were simpler (except for certain ones, like C++ which was a beast even in 1992), and incredibly complex and magical optimizers weren’t yet a thing, never mind a feature expected of a "passable" compiler. One could still write a reasonable non-optimizing Pascal or C89 compiler in a weekend more or less, and it would be both faster to write (thanks to more expressive languages) and faster at compiling (thanks…

I dunno, Chez Scheme is from 1985 and remains today one of the most magically optimizing compilers for a dynamic language in existence... kind of makes you wonder how we went so far wrong with Python.

Re: My 1992 view of the problems of computer programming in 1992

#27

Post by fsmv »

adamddev1 wrote: post #10

How did we get so much better at writing compilers? Was it a better understanding of how to make syntax trees with ADTs etc?

I think the reason writing a compiler is easy today is the theory I learned in compilers class. How to do context free grammars, the concept of abstract syntax trees, the pattern of writing a recursive descent parser and having a lexer that only looks one symbol ahead and has a peek function. On top of that we have experience with lots of languages and type systems to draw from when constructing a new one.

I was just doing some research and apparently all of this stuff was invented around the late 60s and so in the 70s it was still new and by the 90s it was standard practice. The dragon book came out in 1986 and spelled it all out in one place.

Today we have the benefit of knowing the right ideas to use from the start and confidence that if you follow the formula it will all work out.

Re: My 1992 view of the problems of computer programming in 1992

#28

Post by jcranmer »

adamddev1 wrote: post #10

How did we get so much better at writing compilers? Was it a better understanding of how to make syntax trees with ADTs etc?

The author is comparing a 1990 hypothetical compiler to a 1970-ish compiler. The late 1960s and early 1970s are essentially when all of the foundational parser theory gets laid down. By the late 1970s, we're getting into autoparallelization and autovectorization research. Monotone dataflow analysis was developed in the 1970s as well. To be a little bit glib, basically what happened is compiler theory is really birthed starting in the 1970s; if you wanted to track down most of the techniques in the Dragon book, I suspect the vast majority of them originate in that timeframe.

There is a second shift that occurs around 2000-2005-ish, which is the transition of optimizing compilers from an instruction-based semantics to a more value-based semantics, in that modern optimizers make no real attempt or guarantee to preserve the structure of code. For example, an if statement may happily be converted into an expression lacking an if entirely.

Re: My 1992 view of the problems of computer programming in 1992

#29

Post by hectdev »

amelius wrote: post #26

I never hear anyone talk about big-O notation anymore ... Nowadays it's all about optimizing the same old algorithms but on a GPU.

It is fun when debugging slow code and you see a for loop in a for loop. Feels rewarding to sort that out.

Re: My 1992 view of the problems of computer programming in 1992

#30

Post by fsmv »

> We don't really know how to program yet, or how to manage our programs. We don't really know what we want to say or how to say it. We don't have good computer languages for expressing what we want to computer to do. We don't know how to think about programming.

I think this is still true today. Software is only just starting and there is a lot of room to find better ways of doing things.

Post reply on HN