6 ms·

Walter -- you've been in the game a long, long time. One of the first (the first?) commercial C++ compilers. 1. As a 20-something whose first (real) experience

Walter -- you've been in the game a long, long time. One of the first (the first?) commercial C++ compilers. 1. As a 20-something whose first (real) experience coding was Visual Basic in Visual Studio 2008, I'd be interested to hear your thoughts/take on "lessons we've forgotten" or things programmers nowadays think is something new, but is just an old thing being re-discovered/re-branded. 2. Also interested to hear your take on software bloat. I grew up on Windows XP, maybe it's the nostalgia, but I feel like both the responsiveness and usability of apps has declined, despite a x1000 fold increase in computer resources. I can't help but get this sense of both awe and disgust that when I was a little kid, programs were written with so much more efficiency. The peak of absurdism for me was when I sent both an SNES emulator and an SNES game ROM as a Discord chat message attachment to my wife the other night. The ENTIRE PROGRAM took up less space than a picture of a houseplant from my cellphone! (Just 4MB, out of the 8MB limit for message attachments). What're your thoughts here? Are we doomed? -------- By the way, I <3 D. It might not have a very big ecosystem, or huge backers, but as a LANGUAGE I can think of almost nothing I enjoy writing more. (Though if there were an official LSP/tooling in-tree so that IDE intellisense worked when using UFCS syntax that would be life-changing. Currently, I restrict myself from using post-fix functions at all because they break Code-D's intellisense, so it's a waste of one of the best features =/ ) Maybe Stefan Koch's new "reflect" thing that spits out the JSON-looking AST can be useful for this? I'm not super knowledgeable though.

WalterBright 5y ago
Thanks for your thoughts. I'm not sure about lessons forgotten, but there are definitely lessons never learned. One is the use of macros in programming languages. Macros are one of those great ideas that seem almost miraculous. They provide immense power to the programmer. Unfortunately, the dahk side of macros inevitably consumes the user. The macros inevitably become so confusing, pervasive and complex that the author winds up inventing his own undocumented mess of a language, unusable for anyone else. For example (one of my favorite anecdotes!) back in the 90s a friend of mine worked at Microsoft. A manager showed him a program written in assembler that needed a bug fixed. Several programmers had been assigned to it one after the other, and they all failed. It seems the original implementer, who had since left the company, had invented his own macro language using MASM, Microsoft's macro assembler. Nobody could figure it out. My friend said "I can fix that" and fixed the bug and checked it in in two hours. The manager, astonished, asked him how he figured it out. He said "I didn't figure it out. I disassembled the object code using Walter's disassembler that turns it into assembler source code, found the bug, fixed it, and checked in the new asm source code!"
- B1FF_PSUVM 5y ago
  > One is the use of macros in programming languages. Macros killed the Lisp. They never noticed.
  - WalterBright 5y ago
    I'm not experienced with Lisp, but I've heard that as well. A project will essentially invent its own language with the macros, and once the original developers leave nobody else wants to learn those macros, they want to use their macros. And so the project dies.
    - lispm 5y ago
      That's a myth. Actually there are lots of project with domain specific languages and in the case of Lisp they are often directly embedded. Having OO- or functional interfaces to learn is not much different from learning macros. USING the macros is not a problem. MAINTAINING them might be a problem, because new people might have a hard time understanding to work with a language which has meta-level programming directly integrated. There are more languages which now are adding some kind of macro facility (example Rust), so there might be now more programmers getting familiar with meta-level programming with macros. Projects like planners for public transport use special language extensions and if they have a market, they go for a long time. Other example, a specialized CAD system will have its own language extension for expressing generative CAD operations. Sometimes there are projects which are replaced with different technology. For example a web store generator. But there the domain technology typically changes that some of these sites have three technology transitions in a few years. Every project owner has new tool preferences, influenced by the market. It might look like that old code is not understood, but the problem is actually that the code is no longer fashionable. Writing enterprise applications is largely done by Java and not C++. The reason to replace an enterprise application with one written in a newer language (like Java) has many reasons: technology no longer seen as fashionable, fewer trained developers available, trained developers to expensive, age bias, new libraries not available for the older language, etc.
    - aidenn0 5y ago

WalterBright 5y ago

Thanks for your thoughts. I'm not sure about lessons forgotten, but there are definitely lessons never learned. One is the use of macros in programming languages. Macros are one of those great ideas that seem almost miraculous. They provide immense power to the programmer. Unfortunately, the dahk side of macros inevitably consumes the user. The macros inevitably become so confusing, pervasive and complex that the author winds up inventing his own undocumented mess of a language, unusable for anyone else. For example (one of my favorite anecdotes!) back in the 90s a friend of mine worked at Microsoft. A manager showed him a program written in assembler that needed a bug fixed. Several programmers had been assigned to it one after the other, and they all failed. It seems the original implementer, who had since left the company, had invented his own macro language using MASM, Microsoft's macro assembler. Nobody could figure it out. My friend said "I can fix that" and fixed the bug and checked it in in two hours. The manager, astonished, asked him how he figured it out. He said "I didn't figure it out. I disassembled the object code using Walter's disassembler that turns it into assembler source code, found the bug, fixed it, and checked in the new asm source code!"

B1FF_PSUVM 5y ago
> One is the use of macros in programming languages. Macros killed the Lisp. They never noticed.
- WalterBright 5y ago
  I'm not experienced with Lisp, but I've heard that as well. A project will essentially invent its own language with the macros, and once the original developers leave nobody else wants to learn those macros, they want to use their macros. And so the project dies.
  - lispm 5y ago
    That's a myth. Actually there are lots of project with domain specific languages and in the case of Lisp they are often directly embedded. Having OO- or functional interfaces to learn is not much different from learning macros. USING the macros is not a problem. MAINTAINING them might be a problem, because new people might have a hard time understanding to work with a language which has meta-level programming directly integrated. There are more languages which now are adding some kind of macro facility (example Rust), so there might be now more programmers getting familiar with meta-level programming with macros. Projects like planners for public transport use special language extensions and if they have a market, they go for a long time. Other example, a specialized CAD system will have its own language extension for expressing generative CAD operations. Sometimes there are projects which are replaced with different technology. For example a web store generator. But there the domain technology typically changes that some of these sites have three technology transitions in a few years. Every project owner has new tool preferences, influenced by the market. It might look like that old code is not understood, but the problem is actually that the code is no longer fashionable. Writing enterprise applications is largely done by Java and not C++. The reason to replace an enterprise application with one written in a newer language (like Java) has many reasons: technology no longer seen as fashionable, fewer trained developers available, trained developers to expensive, age bias, new libraries not available for the older language, etc.
  - aidenn0 5y ago