> Computer programming is still a black art. It's less than fifty years old, and nobody is very good at it yet. We can make better tools than we know how to use.
I don't think this has changed much at all since 1992. Now you can say that it's less than 90 years old, and nobody is very good at it yet.
And most of our profession has already given up on getting any better at it because a machine can spit out code that compiles.
One of the reasons I was so interesting to find this thing I had written was that things had (in some ways) changed so little in thirty years.
Today I was re-reading Donald Knuth's 1974 paper “Structured Programming with go to Statements” where he says:
“At the present time I think we are on the
verge of discovering at last what program-
ming languages should really be like. … My dream is that by 1984 we will see a consensus developing for a really
good programming language (or, more likely,
a coherent family of languages).”
Even the best programmers in the world write a lot of bugs. Yes, there's a spectrum, but on the whole we're not particularly good at writing code as a species. We still do it though because it turns out that even buggy code can be useful.
Compared to building basically anything else in the world, we genuinely are pretty bad collectively at building software. Even the smart seniors.
I find that a lot of flaws are ignored in for example physical structures because they don’t even know. Take construction inspector and walk with him through five buildings. Let me know if he left any building without pointing out any flaws.
Doctors, a lot of stuff is „let’s try this and see how if it gets better”.
Taking complexity of software and limited budget - we as industry are much much better in building anything. We have better tools and better practices.
Business people are mostly running around like chickens without head, can’t even bother to learn how to use Excel properly.
We have GIT, whole testing approach from unit to integration, team organization etc.
Most of the world runs on software as is now and it works and there is much more software in the world than any other structures we built as a species.
I disagree. I think that after 1992, we got memory safe languages that brought a meaningful improvement to the status quo. And after 2015, we've got low-level memory safe languages (Rust, as the major example. There are others, more experimental.)
The average programmer doesn't get better – if anything, we might be getting worse, because the tools allow us to, and the capitalist reality doesn't optimize for great programs or programmers but for more money.
But, at least, the tools are way better than in 1992, and I think we, as a collective profession, have learned a thing or two.
I agree that there has been progress, but if you look at really mature fields and look at the transformations they've been through and the level of understanding that the highest level practitioners have, and compare it to computer programming... I think we were at maybe 2-3% in 1992 and we're maybe up to 7-9% now?
We're still in the alchemy stages. Real masters can do nuclear chemistry.
Another way to look at it: there have been a lot of arguments on this website about whether or not LLMs are conscious. I think they obviously aren't, but I don't think there's anything special about human brains vs computer chips that means that conscious computers is impossible.
I think a "very good" computer programmer should be able to program consciousness. Not program something like an LLM that trains itself into consciousness, the actual process itself.
Indeed, I realized I had my timeline a bit off after posting that. Of course, we have Lisp ca. 1960. (Pascal appeared 1970, but I don't think that's widely considered memory-safe. ML 1973, and that never got a widespread industry use.)
What I mean is: we had memory safe system-implementation languages in wide spread production use only after/around the times of the publication of that memo; importantly, Java.
We had memory-safe experimental programming languages, and scripting languages before that. And of course, around those times, hardware was fast enough that you could start implementing systems with scripting languages (Perl, Python, Ruby, JavaScript)
And the bit I want to correct is, of course, the point is if they are actually used. In that sense, I'd correct the introduction of Rust around 2023-2026 in actual, wide-spread use.
Beautifully written but when the lack of a better compiler gets attributed to rational actions my brain glitched. That’s not fitting my mental model of how big corps operate at all!
Occam’s razor IBM didn’t invest in Fortran I because the internal political environment at the corporation didn’t have the incentives aligned to do so. This is completely orthogonal to whether they could have used a better compiler or not.
IBM has historically been heavily influenced by petty politics. Legacy programs like DOORS (an acquisition, but developed largely afterwards) continue to use UI patterns unlike any other Windows products, which I attribute to their legendary humiliations by Gates.
Letting pride outvote usability is an insane business decision.
> 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.
Fortran H was faster than the fastest punchcard feeder of the time. That bottleneck is unfortunately long gone, without the same magnitude of improvement on the other side. (Physical limits, amazing optimisations, etc.)
Last time I was working with CCE, I was looking at blistering runtime speeds, but six or seven hour compiles. Huge codebase (40mil+ LoC), and the optimisations were great, but not exactly a fantastic dev lifestyle.
I'm disappointed it disappeared without the other side of the equation showing the same scale of improvement. Understandable reasons why it didn't happen, but disappointing.
I went to the University of Arkansas in the fall of 1993, into Computer Systems Engineering, and we were the first freshman class to work on C/C++ as a primary language to be learned, instead of FORTRAN. I still to this day haven't written a single line of that language, but I find it fascinating.
- 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 expect IBM tried hard to make the output of their compiler to match the performance of hand-written assembly
“In particular, the FORTRAN H compiler played an important role in the development of certain kinds of optimization approaches, such as allocating a specific set of registers to hold the values of variables while in a loop. Overall, the compiler had three levels of possible optimization, as Fortran compiler developers had learned early on that the ability to turn off optimization was a necessity, since it drove up compilation times considerability for program runs that often were not going to work anyway. Even with the larger amount of main memory available to it, the FORTRAN H compiler was still organized via a number of overlays.”
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.
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.
I am sure writing a self-hosted Fortran compiler is possible, but it wouldn’t be my first choice for writing a Fortran compiler, even given the Fortran of today.
In the 1970s, it would have been really low on my list, likely below using a macro assembler.
I think you left out an important technical advance: A theory of parsing was developed, parsing was systematized, and automatic parser generators were developed.
Parsing in 1992 was very much a solved problem. In 1974, writing a parser was still hard.
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.
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.
I agree with the overall point of the article, but I feel compelled to be _that guy_ and point out that most of IBM's systems programming involved various dialects of PL/I, not Fortran, and they went through a bunch of different iterations on those compilers and their code generators.
Was going to make a similar comment…most systems programming was in PL/S or PL/X on 370/390 architecture (regardless of the O/S). AIX and OS/2 were mostly in C. AS/400 in RPG. There were some oddball programs in APL. And thousands of internal "tools" in Rexx.
Aside from a few utilities, relatively little of OS/400 was written in RPG. Originally, most of it was written in two different dialects of PL/I. Some Modula-2 was added into the mix, and most of the lower levels were rewritten in C++ when they switched to PPC processors.
> Now a question: Since we're obviously thousands of times better at producing compilers than we were fifteen years ago, so much so that a single undergraduate can write a passable one in four months, why hasn't IBM invested millions of dollars and hundreds of programmer-years to produce a super FORTRAN I compiler that's thousands of times better than the FORTRAN H compiler?
1. For the most common things people will write, we have a plethora of asymptotically optimal choices that have been discovered.
2. Consider any algorithm of roughly linear complexity (this probably applies to N lg N as well): the only way to make it significantly faster now is to improve parallelism (whether making it so the CPU can exploit ILP, running multicore, or running on a GPU). In 1992, you could make things run significantly faster by just waiting until it was 1994.
> In 1992, you could make things run significantly faster by just waiting until it was 1994.
In the late 90s a couple of companies, including Microsoft and Apple, noticed (just a little bit sooner than anyone
else) that Moore's Law meant that they shouldn't think too hard about performance and memory usage... just build
cool stuff, and wait for the hardware to catch up. Microsoft first shipped Excel for Windows when 80386s were too
expensive to buy, but they were patient. Within a couple of years, the 80386SX came out, and anybody who could
afford a $1500 clone could run Excel.
As a programmer, thanks to plummeting memory prices, and CPU speeds doubling every year, you had a choice. You
could spend six months rewriting your inner loops in Assembler, or take six months off to play drums in a rock and
roll band, and in either case, your program would run faster. Assembler programmers don't have groupies.
So, we don't care about performance or optimization much anymore.
— Joel Spolsky, "Strategy Letter VI" (2007)
Also, during that time the computer market grew extensionally as well: there were a lot of people who didn't have a computer, and when they went to buy one, they'd naturally buy one of the more modern, more powerful models. Nowadays, it's mostly people updating their already owned hardware.
I still think about it sometimes, but I don’t think it matters nearly as much nowadays as it did back in the day. Oftentimes I’m working in situations where the all the complicating factors that big O explicitly excludes matter much more now than they used to. Partially because they’re relatively larger (e.g., cost of memory access) and partially because they’ve become variable in a way that they weren’t 30+ years ago (e.g., the cost of a conditional branch instruction).
Also to some extent it’s just that we’ve pretty well standardized on algorithm implementations. Thinking about the relative merits of a BST vs a red-black tree vs a hash table with bucketing or open addressing or whatever just doesn’t happen as often when the standard library has one implementation and not choosing it would cost you a week of implementing testing and justifying the decision to your colleagues.
Big O doesn't capture parallelism well enough and that's really been the push since Moore's Law started to hit diminishing returns on single threaded perf.
I like this. Really paints a picture of what we are progressing towards. The tools we needed to build the tools we need to build. And the fact that it all boils down to getting the computer to do the thing we want it to do and trying to figure out what that is. Makes me hopeful for the future.
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!
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.
People like to say that "languages aren't fast or slow, that's a property of the implementation."
This is true, but the implementation is constrained by the specification. Python is not just dynamic, but in many cases over-specified. If you read e.g. the Common Lisp specification, you will find that things are under-specified in places that leave a lot of low-hanging fruit for an optimizing implementation.
Scheme (particularly prior to R6RS) is so lightly specified as to allow a lot of variation in implementation strategies, even more so than Common Lisp.
for advanced undergrads, the university of michigan (i'm speaking from my own experience here) has a course progression of (1) programming languages for 1st year grad students, (2) compilers for undergraduates, (3) compiler optimization for 1st year grad students. the expectation is that you can write a fast implementation of a simple language (~scheme) on your own, and you have the knowledge to write a simple optimizing compiler for e.g. c89/99 if you were to take it on as a longer project. any compiler written in a semester probably doesn't have enough manpower to be optimized to a point of usefulness, and you'll learn some things only via implementation struggles, but you'll have the capability to try, search for literature to get unstuck, etc. which is cool!
> Computer programming is still a black art. It's less than fifty years old, and nobody is very good at it yet. We can make better tools than we know how to use.
I don't think this has changed much at all since 1992. Now you can say that it's less than 90 years old, and nobody is very good at it yet.
And most of our profession has already given up on getting any better at it because a machine can spit out code that compiles.
One of the reasons I was so interesting to find this thing I had written was that things had (in some ways) changed so little in thirty years.
Today I was re-reading Donald Knuth's 1974 paper “Structured Programming with go to Statements” where he says:
“At the present time I think we are on the verge of discovering at last what program- ming languages should really be like. … My dream is that by 1984 we will see a consensus developing for a really good programming language (or, more likely, a coherent family of languages).”
Hoo boy, was he ever wrong.
It sounds like excuses I hear from junior devs that don’t want to take time to learn existing frameworks and systems.
Juniors just label anything that requires putting effort to understand as „bad”.
There was insane growth in junior dev numbers last 3 decades. It is not like „no one knows”, it is more like there is much more people who don’t know.
Even the best programmers in the world write a lot of bugs. Yes, there's a spectrum, but on the whole we're not particularly good at writing code as a species. We still do it though because it turns out that even buggy code can be useful.
Compared to building basically anything else in the world, we genuinely are pretty bad collectively at building software. Even the smart seniors.
You have any stats on that or just the feeling?
I find that a lot of flaws are ignored in for example physical structures because they don’t even know. Take construction inspector and walk with him through five buildings. Let me know if he left any building without pointing out any flaws.
Doctors, a lot of stuff is „let’s try this and see how if it gets better”.
Taking complexity of software and limited budget - we as industry are much much better in building anything. We have better tools and better practices.
Business people are mostly running around like chickens without head, can’t even bother to learn how to use Excel properly.
We have GIT, whole testing approach from unit to integration, team organization etc.
Most of the world runs on software as is now and it works and there is much more software in the world than any other structures we built as a species.
Bonus watching material:
https://www.youtube.com/watch?v=RhdlBHHimeM
I disagree. I think that after 1992, we got memory safe languages that brought a meaningful improvement to the status quo. And after 2015, we've got low-level memory safe languages (Rust, as the major example. There are others, more experimental.)
The average programmer doesn't get better – if anything, we might be getting worse, because the tools allow us to, and the capitalist reality doesn't optimize for great programs or programmers but for more money.
But, at least, the tools are way better than in 1992, and I think we, as a collective profession, have learned a thing or two.
I agree that there has been progress, but if you look at really mature fields and look at the transformations they've been through and the level of understanding that the highest level practitioners have, and compare it to computer programming... I think we were at maybe 2-3% in 1992 and we're maybe up to 7-9% now?
We're still in the alchemy stages. Real masters can do nuclear chemistry.
Another way to look at it: there have been a lot of arguments on this website about whether or not LLMs are conscious. I think they obviously aren't, but I don't think there's anything special about human brains vs computer chips that means that conscious computers is impossible.
I think a "very good" computer programmer should be able to program consciousness. Not program something like an LLM that trains itself into consciousness, the actual process itself.
We are nowhere close.
We had memory safe languages before 1992.
Indeed, I realized I had my timeline a bit off after posting that. Of course, we have Lisp ca. 1960. (Pascal appeared 1970, but I don't think that's widely considered memory-safe. ML 1973, and that never got a widespread industry use.)
What I mean is: we had memory safe system-implementation languages in wide spread production use only after/around the times of the publication of that memo; importantly, Java.
We had memory-safe experimental programming languages, and scripting languages before that. And of course, around those times, hardware was fast enough that you could start implementing systems with scripting languages (Perl, Python, Ruby, JavaScript)
And the bit I want to correct is, of course, the point is if they are actually used. In that sense, I'd correct the introduction of Rust around 2023-2026 in actual, wide-spread use.
Beautifully written but when the lack of a better compiler gets attributed to rational actions my brain glitched. That’s not fitting my mental model of how big corps operate at all!
Occam’s razor IBM didn’t invest in Fortran I because the internal political environment at the corporation didn’t have the incentives aligned to do so. This is completely orthogonal to whether they could have used a better compiler or not.
IBM has historically been heavily influenced by petty politics. Legacy programs like DOORS (an acquisition, but developed largely afterwards) continue to use UI patterns unlike any other Windows products, which I attribute to their legendary humiliations by Gates.
Letting pride outvote usability is an insane business decision.
> 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.
Fortran H was faster than the fastest punchcard feeder of the time. That bottleneck is unfortunately long gone, without the same magnitude of improvement on the other side. (Physical limits, amazing optimisations, etc.)
Last time I was working with CCE, I was looking at blistering runtime speeds, but six or seven hour compiles. Huge codebase (40mil+ LoC), and the optimisations were great, but not exactly a fantastic dev lifestyle.
> That bottleneck is unfortunately long gone
? You are pro-bottleneck?
I'm disappointed it disappeared without the other side of the equation showing the same scale of improvement. Understandable reasons why it didn't happen, but disappointing.
I went to the University of Arkansas in the fall of 1993, into Computer Systems Engineering, and we were the first freshman class to work on C/C++ as a primary language to be learned, instead of FORTRAN. I still to this day haven't written a single line of that language, but I find it fascinating.
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 expect IBM tried hard to make the output of their compiler to match the performance of hand-written assembly
The best link I could find is https://en.wikipedia.org/wiki/Fortran#FORTRAN_IV:
“In particular, the FORTRAN H compiler played an important role in the development of certain kinds of optimization approaches, such as allocating a specific set of registers to hold the values of variables while in a loop. Overall, the compiler had three levels of possible optimization, as Fortran compiler developers had learned early on that the ability to turn off optimization was a necessity, since it drove up compilation times considerability for program runs that often were not going to work anyway. Even with the larger amount of main memory available to it, the FORTRAN H compiler was still organized via a number of overlays.”
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.
I am sure writing a self-hosted Fortran compiler is possible, but it wouldn’t be my first choice for writing a Fortran compiler, even given the Fortran of today.
In the 1970s, it would have been really low on my list, likely below using a macro assembler.
I think you left out an important technical advance: A theory of parsing was developed, parsing was systematized, and automatic parser generators were developed.
Parsing in 1992 was very much a solved problem. In 1974, writing a parser was still hard.
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.
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.
I agree with the overall point of the article, but I feel compelled to be _that guy_ and point out that most of IBM's systems programming involved various dialects of PL/I, not Fortran, and they went through a bunch of different iterations on those compilers and their code generators.
Was going to make a similar comment…most systems programming was in PL/S or PL/X on 370/390 architecture (regardless of the O/S). AIX and OS/2 were mostly in C. AS/400 in RPG. There were some oddball programs in APL. And thousands of internal "tools" in Rexx.
> AS/400 in RPG
Aside from a few utilities, relatively little of OS/400 was written in RPG. Originally, most of it was written in two different dialects of PL/I. Some Modula-2 was added into the mix, and most of the lower levels were rewritten in C++ when they switched to PPC processors.
> Now a question: Since we're obviously thousands of times better at producing compilers than we were fifteen years ago, so much so that a single undergraduate can write a passable one in four months, why hasn't IBM invested millions of dollars and hundreds of programmer-years to produce a super FORTRAN I compiler that's thousands of times better than the FORTRAN H compiler?
s/FORTRAN I/Mythos/ for the 2026 version of this.
But they did invest billions in a super-Opus, which they called Mythos.
This article is fake.
Intel Fortran Compiler and IBM XL Fortran compilers are still developed and very well funded
I never hear anyone talk about big-O notation anymore ...
Nowadays it's all about optimizing the same old algorithms but on a GPU.
1. For the most common things people will write, we have a plethora of asymptotically optimal choices that have been discovered.
2. Consider any algorithm of roughly linear complexity (this probably applies to N lg N as well): the only way to make it significantly faster now is to improve parallelism (whether making it so the CPU can exploit ILP, running multicore, or running on a GPU). In 1992, you could make things run significantly faster by just waiting until it was 1994.
> In 1992, you could make things run significantly faster by just waiting until it was 1994.
Also, during that time the computer market grew extensionally as well: there were a lot of people who didn't have a computer, and when they went to buy one, they'd naturally buy one of the more modern, more powerful models. Nowadays, it's mostly people updating their already owned hardware.I still think about it sometimes, but I don’t think it matters nearly as much nowadays as it did back in the day. Oftentimes I’m working in situations where the all the complicating factors that big O explicitly excludes matter much more now than they used to. Partially because they’re relatively larger (e.g., cost of memory access) and partially because they’ve become variable in a way that they weren’t 30+ years ago (e.g., the cost of a conditional branch instruction).
Also to some extent it’s just that we’ve pretty well standardized on algorithm implementations. Thinking about the relative merits of a BST vs a red-black tree vs a hash table with bucketing or open addressing or whatever just doesn’t happen as often when the standard library has one implementation and not choosing it would cost you a week of implementing testing and justifying the decision to your colleagues.
It is fun when debugging slow code and you see a for loop in a for loop. Feels rewarding to sort that out.
Big O doesn't capture parallelism well enough and that's really been the push since Moore's Law started to hit diminishing returns on single threaded perf.
I like this. Really paints a picture of what we are progressing towards. The tools we needed to build the tools we need to build. And the fact that it all boils down to getting the computer to do the thing we want it to do and trying to figure out what that is. Makes me hopeful for the future.
AI propaganda crew hasn't rolled on yet today; not seeing the "it's different now, code is cheap/free with AI" messaging yet.
80% of the cost is maintenance, and all software dies so there will always be work to do.
> and all software dies
Can you elaborate?
Dupe: https://news.ycombinator.com/item?id=48622814
This submission was made two days earlier than the one you linked to, it just came back through the second chance pool. Not a dupe.
Both are duplicates of each other.
One was submitted earlier. The other reached the front page earlier.
[dead]
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.
> The definition of "passable compiler" in 1992 must have been very different from what it is today;
It was.
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!
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.
People like to say that "languages aren't fast or slow, that's a property of the implementation."
This is true, but the implementation is constrained by the specification. Python is not just dynamic, but in many cases over-specified. If you read e.g. the Common Lisp specification, you will find that things are under-specified in places that leave a lot of low-hanging fruit for an optimizing implementation.
Scheme (particularly prior to R6RS) is so lightly specified as to allow a lot of variation in implementation strategies, even more so than Common Lisp.
for advanced undergrads, the university of michigan (i'm speaking from my own experience here) has a course progression of (1) programming languages for 1st year grad students, (2) compilers for undergraduates, (3) compiler optimization for 1st year grad students. the expectation is that you can write a fast implementation of a simple language (~scheme) on your own, and you have the knowledge to write a simple optimizing compiler for e.g. c89/99 if you were to take it on as a longer project. any compiler written in a semester probably doesn't have enough manpower to be optimized to a point of usefulness, and you'll learn some things only via implementation struggles, but you'll have the capability to try, search for literature to get unstuck, etc. which is cool!
Very similar at University of Warsaw, at least couple of years ago.
Beautifully written. Was this a note to self. If so amazing.
[flagged]
what do you think of it?