A talk with Walter Bright about Empire(madned.substack.com)
madned.substack.com
A talk with Walter Bright about Empire
https://madned.substack.com/p/a-talk-with-computer-gaming-pioneer
101 comments
Walter here! AMA!
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.
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.
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!"
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!"
> 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.
This is not limited to macros, but any abstraction.
Let's step back and rewrite the quote:
> The abstractions inevitably become so confusing, pervasive and complex that the author winds up inventing his own undocumented mess of a language, unusable for anyone else.
The key fault that trips up so many talented programmers (if not all) at least some point during their career (and hopefully not continuously, though I certainly know a few cases) is confusing convenience with simple. Convenience is almost always more complex, not simpler. Macros happen to wear their complex hearts on their sleeves.
You can address any of these problems by _addressing the problems_ you succinctly listed: documentation and usability.
Take React for example. It's an abstraction, arguably a new "language", and requires ample documentation and usability concessions to be palatable. You could accomplish this with macros as well.
But like any abstraction, the real problems arise during maintenance, and thus it becomes a Software Engineering problem -- whatever that means. This is where Software Engineering as a poorly-defined pseudo-profession has failed to demarcate itself from simple programming: the quality, maintenance and longevity of living code bases.
The masses unfortunately still don't see the forest for the trees, so I agree that it's something we've never seemed to learn, if perhaps using a broader definition.
This is not limited to macros, but any abstraction.
Let's step back and rewrite the quote:
> The abstractions inevitably become so confusing, pervasive and complex that the author winds up inventing his own undocumented mess of a language, unusable for anyone else.
The key fault that trips up so many talented programmers (if not all) at least some point during their career (and hopefully not continuously, though I certainly know a few cases) is confusing convenience with simple. Convenience is almost always more complex, not simpler. Macros happen to wear their complex hearts on their sleeves.
You can address any of these problems by _addressing the problems_ you succinctly listed: documentation and usability.
Take React for example. It's an abstraction, arguably a new "language", and requires ample documentation and usability concessions to be palatable. You could accomplish this with macros as well.
But like any abstraction, the real problems arise during maintenance, and thus it becomes a Software Engineering problem -- whatever that means. This is where Software Engineering as a poorly-defined pseudo-profession has failed to demarcate itself from simple programming: the quality, maintenance and longevity of living code bases.
The masses unfortunately still don't see the forest for the trees, so I agree that it's something we've never seemed to learn, if perhaps using a broader definition.
So I'm not a fan of metaprogramming or heavy abuse of tricks for convenience either, and I do get and agree with your point!
But for some anecdotal nuance concerning the React example: > Take React for example. It's an abstraction, arguably a new "language", and requires ample documentation and usability concessions to be palatable. You could accomplish this with macros as well.
I feel like the standard before React was just every (web) framework inventing its own templating language, whereas I found React to be really easy to learn, because the way it abstracted things were straightforward and well explained. It's tooling however is one of the scariest things I've ever seen haha.
But for some anecdotal nuance concerning the React example: > Take React for example. It's an abstraction, arguably a new "language", and requires ample documentation and usability concessions to be palatable. You could accomplish this with macros as well.
I feel like the standard before React was just every (web) framework inventing its own templating language, whereas I found React to be really easy to learn, because the way it abstracted things were straightforward and well explained. It's tooling however is one of the scariest things I've ever seen haha.
I recently wrote a React app without using the “create-react-app” tool… just by writing JavaScript code, later TypeScript, and bundling it with Rollup.js.
Doing things this way shows you that the tooling doesn’t have to be complicated. I assume that there are very good reasons why the tooling is complicated—stuff like code splitting, modular CSS, etc. If you’re writing pure JS React and putting the CSS elsewhere, you can squeak by with fairly simple tools.
Doing things this way shows you that the tooling doesn’t have to be complicated. I assume that there are very good reasons why the tooling is complicated—stuff like code splitting, modular CSS, etc. If you’re writing pure JS React and putting the CSS elsewhere, you can squeak by with fairly simple tools.
> This is not limited to macros, but any abstraction.
Disagree here. Unix process, file access api's, programming languages are all abstractions that make life easier.
Disagree here. Unix process, file access api's, programming languages are all abstractions that make life easier.
Disagree. There are abstractions and there are abstractions.
Macros are too big of a footgun of an abstraction. Because they can change the syntax of the language, they can hide functionality in non-obvious ways and they're just another band-aid on top of the languages limitations (the two latter points are especially true for C). And more often than not they're worse than just writing using the languages capabilities.
Yes I'm sure people writing C macros will sit down and document them, and make them usable. Not.
That being said, Rust macros are a world apart from C macros.
Macros are too big of a footgun of an abstraction. Because they can change the syntax of the language, they can hide functionality in non-obvious ways and they're just another band-aid on top of the languages limitations (the two latter points are especially true for C). And more often than not they're worse than just writing using the languages capabilities.
Yes I'm sure people writing C macros will sit down and document them, and make them usable. Not.
That being said, Rust macros are a world apart from C macros.
There are macros, and there are macros.
You've used C and Rust macros. Have you seen Common Lisp macros?
I've read a fair amount of Common Lisp code written by other people, and every time I had difficulty understanding something, it was invariably plain CL, and not a macro.
Maybe C programmers just have difficulty exercising restraint when writing their macros. Or perhaps the design of the language and the macro system (which is basically just text pre-processing) don't mesh well together.
Regardless, I haven't noticed macros being a footgun in CL. Sure, there are doubtless people out there who have abused it (and will continue to do so) - but that's true for every language feature; meanwhile, it doesn't seem like macros themselves are actually a problem, in the sense that they're particularly easy to abuse compared to the rest of the language (a distinction that I might give to C raw pointers, for instance).
If anything, (good - CL) macros are easier to understand than many other features, because they're (usually) referentially transparent functions with a clearly defined input and output that runs once at compile-time, on known data, which you can manually expand and inspect, and they tend to rarely interact with other features of the language. With rare (but useful) exceptions, macros don't involve networking, async, threads, dynamic environments, databases, stack limits, or any of the other strands in the spider-web complexity that tends to make programming hard.
You've used C and Rust macros. Have you seen Common Lisp macros?
I've read a fair amount of Common Lisp code written by other people, and every time I had difficulty understanding something, it was invariably plain CL, and not a macro.
Maybe C programmers just have difficulty exercising restraint when writing their macros. Or perhaps the design of the language and the macro system (which is basically just text pre-processing) don't mesh well together.
Regardless, I haven't noticed macros being a footgun in CL. Sure, there are doubtless people out there who have abused it (and will continue to do so) - but that's true for every language feature; meanwhile, it doesn't seem like macros themselves are actually a problem, in the sense that they're particularly easy to abuse compared to the rest of the language (a distinction that I might give to C raw pointers, for instance).
If anything, (good - CL) macros are easier to understand than many other features, because they're (usually) referentially transparent functions with a clearly defined input and output that runs once at compile-time, on known data, which you can manually expand and inspect, and they tend to rarely interact with other features of the language. With rare (but useful) exceptions, macros don't involve networking, async, threads, dynamic environments, databases, stack limits, or any of the other strands in the spider-web complexity that tends to make programming hard.
In other words, they're a completely different language feature than the one in C that happens to go by the same name.
Lisp macros can get super obtuse, no matter what people tell me. When I have used Common Lisp, I try to avoid them most of the time.
I addressed this in my comment:
> Regardless, I haven't noticed macros being a footgun in CL. Sure, there are doubtless people out there who have abused it (and will continue to do so) - but that's true for every language feature; meanwhile, it doesn't seem like macros themselves are actually a problem, in the sense that they're particularly easy to abuse compared to the rest of the language (a distinction that I might give to C raw pointers, for instance).
Nobody contests that CL macros can get obtuse - but that's not special. You can write obtuse code in any Turing-complete language. Does that mean that we should abolish Turing-completeness? Of course not.
How much Common Lisp have you read and written?
> Regardless, I haven't noticed macros being a footgun in CL. Sure, there are doubtless people out there who have abused it (and will continue to do so) - but that's true for every language feature; meanwhile, it doesn't seem like macros themselves are actually a problem, in the sense that they're particularly easy to abuse compared to the rest of the language (a distinction that I might give to C raw pointers, for instance).
Nobody contests that CL macros can get obtuse - but that's not special. You can write obtuse code in any Turing-complete language. Does that mean that we should abolish Turing-completeness? Of course not.
How much Common Lisp have you read and written?
[deleted]
> another band-aid on top of the languages limitations
Those limitations are real though, and getting in peoples way. I'd also add most language designers would not consider C macros as "real" macros.
Think of abstractions as power tools, you want to use the least powerful one that solves the problem so you don't lose a hand. If you're cutting a string you pull out some scissors, if you're cutting a 10 foot thick steel rod, you grab some hydraulic shears; so it goes with abstractions.
Most people never need macros, the abstraction equivalent of hydraulic shears, because most of the time your problem isn't that difficult. That doesn't mean those problems aren't out there or that macros shouldn't exist.
Those limitations are real though, and getting in peoples way. I'd also add most language designers would not consider C macros as "real" macros.
Think of abstractions as power tools, you want to use the least powerful one that solves the problem so you don't lose a hand. If you're cutting a string you pull out some scissors, if you're cutting a 10 foot thick steel rod, you grab some hydraulic shears; so it goes with abstractions.
Most people never need macros, the abstraction equivalent of hydraulic shears, because most of the time your problem isn't that difficult. That doesn't mean those problems aren't out there or that macros shouldn't exist.
At one point, I decided to unwind all my use of macros in C. I was actually very happy with the result. My code was much better.
Thanks for taking the time to reply Walter, genuinely appreciate it!
I am very sparing even when using mixins/template mixins in D -- the second you do, it ratchets the debugging difficulty up to "11" and becomes am order of magnitude harder to reason about program state.
Great power, great responsibility. I'm an "avoid at all costs" kind of guy, unless you can really justify it.
If C++ didn't have macros (which invariably get abused, along with templates) I think I might not hate it so much. Let us pray that the "constexpr" idea they "borrowed" from you may slowly fix this a little over time ;)
I went through a phase earlier in my dev career where I thought "Metaprogramming is so powerful and cool!", and I've put that behind me now. I just want boring, easy-to-read + maintain, predictable code.
Ironically I used to poke fun at Java and .NET but I've come to appreciate the "stupidity". "Dumb" is easy to understand, "dumb" is easy to maintain. "Clever" is bad.
I suppose while I'm at it, I ought to thank you for all the Digital Mars tools that myself and many others still use today:
https://www.digitalmars.com/ctg/ctg.html
The Digital Mars tools for working with PE/COFF files and libs/binaries are indispensable. I suppose they've helped many tens of thousands of people.
> "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."
I am very sparing even when using mixins/template mixins in D -- the second you do, it ratchets the debugging difficulty up to "11" and becomes am order of magnitude harder to reason about program state.
Great power, great responsibility. I'm an "avoid at all costs" kind of guy, unless you can really justify it.
If C++ didn't have macros (which invariably get abused, along with templates) I think I might not hate it so much. Let us pray that the "constexpr" idea they "borrowed" from you may slowly fix this a little over time ;)
I went through a phase earlier in my dev career where I thought "Metaprogramming is so powerful and cool!", and I've put that behind me now. I just want boring, easy-to-read + maintain, predictable code.
Ironically I used to poke fun at Java and .NET but I've come to appreciate the "stupidity". "Dumb" is easy to understand, "dumb" is easy to maintain. "Clever" is bad.
> "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!""
I suppose while I'm at it, I ought to thank you for all the Digital Mars tools that myself and many others still use today:
https://www.digitalmars.com/ctg/ctg.html
The Digital Mars tools for working with PE/COFF files and libs/binaries are indispensable. I suppose they've helped many tens of thousands of people.
They're certainly indispensable to me! Some of them I wrote for the purpose of understanding the file format. Writing a pretty-printer is a great way to understand.
> 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!"
Nice! But this trick doesn't work when a bad program is written in a HLL! I once speeded up a C++ program that took 3 minutes & was in the critical path for 40-50 engineers. It was badly written and the logic was spread all over the place. It was not fixable so I took the easy way out. I looked at its inputs+outputs, fed various smaller samples to figure out the IO logic and reimplemented it from scratch. The new program ran in 0.5 seconds. It wasn't a difficult problem but nobody wanted to touch the program because it was so badly written.
I think the moral is that bad programmers will misuse whatever features they have access to. The "dark side" is less that of the feature in question and more in the lack of early intervention and proper training! People need to be taught how to use power tools responsibly & judiciously. If you take away all the power tools for the fear of misuse, you will only see mediocre work. Or worse.
Nice! But this trick doesn't work when a bad program is written in a HLL! I once speeded up a C++ program that took 3 minutes & was in the critical path for 40-50 engineers. It was badly written and the logic was spread all over the place. It was not fixable so I took the easy way out. I looked at its inputs+outputs, fed various smaller samples to figure out the IO logic and reimplemented it from scratch. The new program ran in 0.5 seconds. It wasn't a difficult problem but nobody wanted to touch the program because it was so badly written.
I think the moral is that bad programmers will misuse whatever features they have access to. The "dark side" is less that of the feature in question and more in the lack of early intervention and proper training! People need to be taught how to use power tools responsibly & judiciously. If you take away all the power tools for the fear of misuse, you will only see mediocre work. Or worse.
> People need to be taught how to use power tools responsibly & judiciously.
I would have agreed with you long ago. But decades of experience with it shows that:
1. Everyone agrees with that. And then they create a mess. They are generally unable to see the mess. One cannot learn without experiencing failure, and when one cannot see the failure, one cannot learn.
2. Some features are far more susceptible to this than others. Macros are pretty much at the top of that list. Other abominations are nutberger operator overloads, like overloading << to mean input (or is it output? I can never remember, and don't care, either).
There are many things in D meant to block or discourage these kinds of choices. I regularly get pushback on them. All I can say is "I understand exactly where you're coming from, and why you believe I'm wrong. But you haven't been living with this for that long, and will just have to trust me."
3. These also come about from my discussions with managers of programming teams and the problems they have to deal with.
I would have agreed with you long ago. But decades of experience with it shows that:
1. Everyone agrees with that. And then they create a mess. They are generally unable to see the mess. One cannot learn without experiencing failure, and when one cannot see the failure, one cannot learn.
2. Some features are far more susceptible to this than others. Macros are pretty much at the top of that list. Other abominations are nutberger operator overloads, like overloading << to mean input (or is it output? I can never remember, and don't care, either).
There are many things in D meant to block or discourage these kinds of choices. I regularly get pushback on them. All I can say is "I understand exactly where you're coming from, and why you believe I'm wrong. But you haven't been living with this for that long, and will just have to trust me."
3. These also come about from my discussions with managers of programming teams and the problems they have to deal with.
> 1. Everyone agrees with that. And then they create a mess. They are generally unable to see the mess. One cannot learn without experiencing failure, and when one cannot see the failure, one cannot learn.
Hence "early intervention"! Usually one's own experience is not going to be enough but if one can learn from real experts what to avoid and what works well, one can develop a sense. You can get some of that by careful reading of such people's code.
> 2. Some features are far more susceptible to this than others.
True. This happens when the language developer creates a mess! I am reminded of Tony Hoare's "Hints on Programming Language Design".
> 3. These also come about from my discussions with managers of programming teams and the problems they have to deal with.
They should be listened to for the problems they face but not necessarily solutions :-)
Hence "early intervention"! Usually one's own experience is not going to be enough but if one can learn from real experts what to avoid and what works well, one can develop a sense. You can get some of that by careful reading of such people's code.
> 2. Some features are far more susceptible to this than others.
True. This happens when the language developer creates a mess! I am reminded of Tony Hoare's "Hints on Programming Language Design".
> 3. These also come about from my discussions with managers of programming teams and the problems they have to deal with.
They should be listened to for the problems they face but not necessarily solutions :-)
Haha! Yes, every time I hear Lisp and Macros... really, you have to be careful with them. I would say it should be the last resort, and really careful when using them.
> One is the use of macros in programming languages.
Macros killed the Lisp. They never noticed.
Macros killed the Lisp. They never noticed.
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.
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.
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.
I am experienced with Lisp, and this is a case of "Short answer yes with an if; long answer no with a but."
Plenty of junior Lisp developers are so enamored of macros that they over-use them. Particularly since macros in Lisp are so both easy to write, and mentioned as a feature unique to lisp, you see junior developers reaching for that as a their first tool. This leads to there being lots of projects as you describe, particularly projects written by a lone Lisp journeyman developer.
Most Lisp style guides say things like "Don't use a macro when a function will do." Most projects written by more experienced developers (particularly those who have experience working on a team) tend not to end up in this state.
> ...author winds up inventing his own undocumented mess of a language, unusable for anyone else.
For projects in which an embedded language makes sense, documentation is important! Also, again, this is a situation that tends to be peculiar to projects written by lone developers because it's very hard to get away with writing a tool that is unusable by other people if you are surrounded by other people trying to use it.
[edit]
This is also partly an artifact of the post AI-winter community being so small and fragmented. When smalltalk style OO was the next big thing, there were dozens of implementations for it in Lisp almost overnight. Reasonably quickly this whittled down to about 2 or 3 popular ones, some time after which people got together and standardized CLOS from the what was left. Arguably the Lisp community is insufficiently cohesive (and insufficiently funded) these days to maintain something like that that now.
Plenty of junior Lisp developers are so enamored of macros that they over-use them. Particularly since macros in Lisp are so both easy to write, and mentioned as a feature unique to lisp, you see junior developers reaching for that as a their first tool. This leads to there being lots of projects as you describe, particularly projects written by a lone Lisp journeyman developer.
Most Lisp style guides say things like "Don't use a macro when a function will do." Most projects written by more experienced developers (particularly those who have experience working on a team) tend not to end up in this state.
> ...author winds up inventing his own undocumented mess of a language, unusable for anyone else.
For projects in which an embedded language makes sense, documentation is important! Also, again, this is a situation that tends to be peculiar to projects written by lone developers because it's very hard to get away with writing a tool that is unusable by other people if you are surrounded by other people trying to use it.
[edit]
This is also partly an artifact of the post AI-winter community being so small and fragmented. When smalltalk style OO was the next big thing, there were dozens of implementations for it in Lisp almost overnight. Reasonably quickly this whittled down to about 2 or 3 popular ones, some time after which people got together and standardized CLOS from the what was left. Arguably the Lisp community is insufficiently cohesive (and insufficiently funded) these days to maintain something like that that now.
Hello! Came here just to say thank you for my happy professional childhood. I used to closely follow D development since DMD was 0.48. It introduced me to some basic concepts: module system, cow, unit tests, invariant checks, which were somewhat foreign to C++ devs at the time.
I remember how all the mailing list waited for 1.0 finally after 0.99 and… oooow… “announcing DMD 0.100” :)
I was 17 at my first job ever, it was in gamedev, and I promised everyone that D would be the next thing after that clunky C++ in two (maybe three) years. That’s how we should make games \m/
Sadly, it didn’t come to that extent (marketing?). But I am glad to visit dlang.org from time to time and see it evolve, and Walter Bright still rocks, 20 years after.
I remember how all the mailing list waited for 1.0 finally after 0.99 and… oooow… “announcing DMD 0.100” :)
I was 17 at my first job ever, it was in gamedev, and I promised everyone that D would be the next thing after that clunky C++ in two (maybe three) years. That’s how we should make games \m/
Sadly, it didn’t come to that extent (marketing?). But I am glad to visit dlang.org from time to time and see it evolve, and Walter Bright still rocks, 20 years after.
Thanks for such a great game. I remember playing Empire on my Amiga back in the late 80s, it didn't have any of the fancy 3D graphics of my other games but I still played Empire the most. I still play a clone of it frequently on my iPad.
Graphics are great for initial attraction to a game, but it's the gameplay that keeps one's interest.
It's similar to movies. Special effects are momentarily interesting, but it's the plot that overwhelmingly matters.
It's similar to movies. Special effects are momentarily interesting, but it's the plot that overwhelmingly matters.
And characters.
That pretty much sums up American vs. British comedy (televisual anyway) for me.
US: 'momentarily interesting' (resp. funny at the time) - series of one-liners and the like; UK: character development, hard to explain why it's funny, might take 'getting into'.
Green Wing for example - I thought it was absolutely absurd when I first saw it, and it is. But for some reason I went back to it (or was made to) and stuck with it for a few episodes while I learnt to love it. And now I do, it's one of my all-time favourites. And of course I've been back (several times) to watch the first episode(s) again, and they're hilarious too.
Or perhaps a clearer example is the original UK The Office (Ricky Gervais) vs. the US version (Steve Carell). Same rough outline obviously, some of the same (especially early in the remake) storyline and jokes, but somehow even then the humour is very different.
(I'm not hating on the remake, I enjoyed it enough to watch it all once I accepted it's different, and stopped expecting 'The Office' as I knew it. Especially once it found its own path and diverged from the same jokes - IMO - worse delivered.)
US: 'momentarily interesting' (resp. funny at the time) - series of one-liners and the like; UK: character development, hard to explain why it's funny, might take 'getting into'.
Green Wing for example - I thought it was absolutely absurd when I first saw it, and it is. But for some reason I went back to it (or was made to) and stuck with it for a few episodes while I learnt to love it. And now I do, it's one of my all-time favourites. And of course I've been back (several times) to watch the first episode(s) again, and they're hilarious too.
Or perhaps a clearer example is the original UK The Office (Ricky Gervais) vs. the US version (Steve Carell). Same rough outline obviously, some of the same (especially early in the remake) storyline and jokes, but somehow even then the humour is very different.
(I'm not hating on the remake, I enjoyed it enough to watch it all once I accepted it's different, and stopped expecting 'The Office' as I knew it. Especially once it found its own path and diverged from the same jokes - IMO - worse delivered.)
I think it's less that the US doesn't have those, it's just that they have both types, and they also mix them. Seinfeld wouldn't have been half as good as it was without you knowing the character and how they would react to specific situations.
I think part of what you're identifying about first episodes is maybe a difference in style between the US and UK. A lot of UK comedy definitely seems like the characters are pre-baked into the writing and the actor is already mature in the role in the beginning, while in the US it feels like they've left the role a little hollow at first and allow the actors (and future writing) to evolve the role into what it will be. This can make the first episodes feel "off" when you go back to watch them, but I'm not sure it's necessarily a bad way to go if the goal is to find a really good character.
It's also possible that the UK network(s) are amenable to planned out entire seasons while the US networks are more accepting of buying a pilot of a few episodes and seeing where something goes, which would favor some of these approaches in each case.
I think part of what you're identifying about first episodes is maybe a difference in style between the US and UK. A lot of UK comedy definitely seems like the characters are pre-baked into the writing and the actor is already mature in the role in the beginning, while in the US it feels like they've left the role a little hollow at first and allow the actors (and future writing) to evolve the role into what it will be. This can make the first episodes feel "off" when you go back to watch them, but I'm not sure it's necessarily a bad way to go if the goal is to find a really good character.
It's also possible that the UK network(s) are amenable to planned out entire seasons while the US networks are more accepting of buying a pilot of a few episodes and seeing where something goes, which would favor some of these approaches in each case.
I hope it's clear enough that I'm not disparaging US comedy. There's plenty of it I enjoy.
I think a key point I started making but didn't really conclude is that British comedies stay with me; I can quote them, accidentally fall into their characters like an eccentric myself, enjoy them without re-watching them. Monty Python; Fawlty Towers; Reggie Perrin; The Office; Green Wing; Dad's Army; et alia.
I think the closest I can come to that sort of absent enjoyment with US TV comedy is to imagine April Ludgate's (Parks & Recreation) face in reaction to something.
Maybe it's partly that US comedy veers more visual & slapstick? Certainly not all of it, there's very little in general, I commented on that in a recent thread on Airplane!, but that too is American of course. Though I'm not sure how well Fawlty Towers would work audio-only.
I think a key point I started making but didn't really conclude is that British comedies stay with me; I can quote them, accidentally fall into their characters like an eccentric myself, enjoy them without re-watching them. Monty Python; Fawlty Towers; Reggie Perrin; The Office; Green Wing; Dad's Army; et alia.
I think the closest I can come to that sort of absent enjoyment with US TV comedy is to imagine April Ludgate's (Parks & Recreation) face in reaction to something.
Maybe it's partly that US comedy veers more visual & slapstick? Certainly not all of it, there's very little in general, I commented on that in a recent thread on Airplane!, but that too is American of course. Though I'm not sure how well Fawlty Towers would work audio-only.
The first few Seinfeld episodes are pretty lame compared to when the series hit its stride.
I think that's an example of what I'm saying. Rather than the characters being mostly realized by the writing, they let the characters and actors grow into specific parts together.
I have tried that game. I find it a bit too difficult to play without a keyboard. Or just too slow. I am still, after all these years, used to rapidly moving units with the keyboard
Hi Walter, thanks for your time!
Do you play many games nowadays? Which ones?
What do you think is going to be the next big gaming breakthrough? Or the next big genre/theme? (E.g. for economics, it was F2P/IAP, never of which I'm a fan of. Also, city building + survival is really big right now.)
Do you play many games nowadays? Which ones?
What do you think is going to be the next big gaming breakthrough? Or the next big genre/theme? (E.g. for economics, it was F2P/IAP, never of which I'm a fan of. Also, city building + survival is really big right now.)
The itch to write a better language & compiler than anyone else is more compelling!
But I am attracted to full motion simulators that would, say, enable me to drive an F1 car without risk or much investment.
But I am attracted to full motion simulators that would, say, enable me to drive an F1 car without risk or much investment.
If you're into that, I highly recommend you looking up Force Dynamics (a friend of mine) for high quality affordable driving simulators that are really close to actually driving the Real Thing (TM)
https://www.force-dynamics.com/
https://www.force-dynamics.com/
It's sad that we still don't have an idea how to produce high g-forces in a simulator.
The feeling of going with a car through a turn at 2g is incomparable to the simulators we have. Never mind F1 cars that can corner and brake at up to 5g.
The feeling of going with a car through a turn at 2g is incomparable to the simulators we have. Never mind F1 cars that can corner and brake at up to 5g.
I wonder if there's a way to magnetically or electrically stimulate the organ inside our ears that feels accelerations.
Then we would solve this, and also provide more immersion for flight simulators.
Then we would solve this, and also provide more immersion for flight simulators.
It can be done, you'd just need a big playground for the machine - about the size of an F1 track!
With enough money you can actually go to such a “simulator”. There are these guys that run older F1 cars on tracks. The teams provide pit crews and everything else. If you can afford it, definitely a nice hobby!
I got to drive a car with aerodynamic downforce only once and it’s super impressive to feel how it works better the faster you go. Cornering with 2g is also pretty nice.
I got to drive a car with aerodynamic downforce only once and it’s super impressive to feel how it works better the faster you go. Cornering with 2g is also pretty nice.
Sounds like a blast! I took a couple performance driving courses on a racetrack with Formula Ford racers. Scared me pretty good, but I had a fantastic time.
Fear, though, is what kept me from getting decent lap times. With a simulator, that is no barrier.
Fear, though, is what kept me from getting decent lap times. With a simulator, that is no barrier.
Don't forget this very important design issue of motion systems:
https://www.youtube.com/watch?v=ttCXkfjnvvc
Some motion systems are simulating the 'motion' of the car, when they should be simulating the 'forces' on the driver.
For example sustained acceleration to the left because of heavy cornering should generate sustained tilt, so you feel heavier to the left.
The only issue is that the max acceleration that can be simulated is 1G. So a larger acceleration is either clipped or all accelerations are scaled.
My favourite concept is this one: https://www.yawvr.com/
https://www.youtube.com/watch?v=ttCXkfjnvvc
Some motion systems are simulating the 'motion' of the car, when they should be simulating the 'forces' on the driver.
For example sustained acceleration to the left because of heavy cornering should generate sustained tilt, so you feel heavier to the left.
The only issue is that the max acceleration that can be simulated is 1G. So a larger acceleration is either clipped or all accelerations are scaled.
My favourite concept is this one: https://www.yawvr.com/
Empire was one of my favorite games and really got me into strategy games. I even made a clone many years ago just to practice programming. And now D is my favorite language - it just feels natural to use.
So, I just want to say thanks for creating two big influences in my life. I hope you keep working on D, and for what it's worth, I do try to promote it as much as I can.
I do have one question: I contribute to the D Language Foundation through my Amazon purchases and would like know if those types of contributions are helping. And are you getting the support necessary to keep working on the compiler for a long time to come?
So, I just want to say thanks for creating two big influences in my life. I hope you keep working on D, and for what it's worth, I do try to promote it as much as I can.
I do have one question: I contribute to the D Language Foundation through my Amazon purchases and would like know if those types of contributions are helping. And are you getting the support necessary to keep working on the compiler for a long time to come?
Yes, every bit helps. While I took a 100% pay cut to work on D, there are other bills, like hosting service bills. We also have a few paid staff that donations and such pay for.
D is one of the few mainstream languages today that support Design by Contract (https://dlang.org/spec/contracts.html), and I remember it being a prominent language feature all the way to pre-1.0.
The only other major language I can think of that's still actively used is Ada in its more recent incarnations. Eiffel didn't get much traction, and .NET dropped System.Diagnostics.Contracts recently due to lack of usage. C++ had some proposals that didn't go anywhere, if I remember correctly. Java has some AOP-based third party solutions for it, but nothing is in the core language, nor any plans for it.
Why do you think that is? I don't see what's wrong with DbC conceptually, and having (effectively) formalized specs helps both document the code better, and catch bugs.
The only other major language I can think of that's still actively used is Ada in its more recent incarnations. Eiffel didn't get much traction, and .NET dropped System.Diagnostics.Contracts recently due to lack of usage. C++ had some proposals that didn't go anywhere, if I remember correctly. Java has some AOP-based third party solutions for it, but nothing is in the core language, nor any plans for it.
Why do you think that is? I don't see what's wrong with DbC conceptually, and having (effectively) formalized specs helps both document the code better, and catch bugs.
People don't bother using them. Walter gave a hits & misses talk a while back and I believe he classified contracts as a miss.
I do really like them. In certain situations they are actually useful to the optimizer too, saves some branches on array length alignment for example.
I do really like them. In certain situations they are actually useful to the optimizer too, saves some branches on array length alignment for example.
Yes, but why people don't bother using them? It can't just be an aversion to verbosity, since people do write unit tests - many of which could have been contracts instead. And it seems like there's increased interest in preventing bugs through more rigorous static code analysis these days (Rust etc), so why doesn't it come up in that context?
People find it easier to just put asserts into the main body.
The distinguishing feature of Contract Programming is how it handles inheritance. But OOP isn't as pervasive as it used to be.
The distinguishing feature of Contract Programming is how it handles inheritance. But OOP isn't as pervasive as it used to be.
IMO the key insight of contract programming is that contracts belong to the interface; that's exactly why asserts in the main body don't cut it. It needs to be where it's versioned as part of the interface, where the tools treat it as such etc.
OTOH contract inheritance in OOP is really something specific to OOP; but contracts are quite useful even without objects in the picture (e.g. in Ada this is probably more common than not).
OTOH contract inheritance in OOP is really something specific to OOP; but contracts are quite useful even without objects in the picture (e.g. in Ada this is probably more common than not).
>The distinguishing feature of Contract Programming is how it handles inheritance.
How does it handle it?
How does it handle it?
It applies the Liskov substitution principle to it. So preconditions can only be widened in subclasses, and postconditions can only be narrowed.
In simple terms, it means that when you override a method, the override's precondition is automatically OR'ed with that of the superclass, and your postcondition is AND'ed. And ditto for interface inheritance.
In simple terms, it means that when you override a method, the override's precondition is automatically OR'ed with that of the superclass, and your postcondition is AND'ed. And ditto for interface inheritance.
Thanks, that makes sense. IIRC, I read about this either in Bertrand Meyer's book Object-oriented Software Contruction, or in the Eiffel language's docs, some years back, though I may not have known about it as an application of the Liskov substitution principle at the time, or even later, although I did read about the Liskov principle later :)
And I may not have grokked the Liskov principle when I read it, either, but thanks to your reply, I now have a glimmering of what it means, and will look it up again :)
And I may not have grokked the Liskov principle when I read it, either, but thanks to your reply, I now have a glimmering of what it means, and will look it up again :)
Hey Walter. I played a lot with the DOS version of the game that Mark Baldwin worked on (perhaps also a later windows version, although I probably just played the DOS version on Windows). Two things that struck me as "off" at the time were the way calculating the distance when moving units wasn't as consistent or intuitive as it could be when moving diagonally because the board consisted of squares, and that multiple units couldn't be parked in the same place unless they were in a city.
Are these things you'd handle differently today? Are there any games that you think handled this better? A hexagonal board layout seems like it might be a better approach to calculating distance between points, but what about the limit of one unit per one square on the grid?
I love the idea of allowing players to supply a bot to compete against other bots.
Are these things you'd handle differently today? Are there any games that you think handled this better? A hexagonal board layout seems like it might be a better approach to calculating distance between points, but what about the limit of one unit per one square on the grid?
I love the idea of allowing players to supply a bot to compete against other bots.
A hex grid certainly addresses that problem, but since I was limited to text, squares it was!
The one unit per square comes about because it is very difficult to see a "stack" of units in one location. It also made combat trivial, just move into the opposing force's square. No special commands needed.
This wound up working fine, and I was always reluctant to mess with game rules that worked.
The one unit per square comes about because it is very difficult to see a "stack" of units in one location. It also made combat trivial, just move into the opposing force's square. No special commands needed.
This wound up working fine, and I was always reluctant to mess with game rules that worked.
I enjoyed the 4-player flash version of Hex Empire that used a hex grid. User played one team and AI played the other three at various difficulty levels from naive to cutthroat. Was my favorite online game until the recent demise of flash. I would flip through various starting map layouts until I found one I thought one of the three players that didn't go first could win. The first player had a big advantage mostly.
Strategy was always to wipe out the opponent on the near shortest side and then take on the two that started at the opposite longest end of the board. The best games were those that were finely balanced and resulted in a long war of attrition with the outcome influenced a lot by choosing the best micro-level tactics.
https://jayisgames.com/review/hex-empire.php#walkthrough
https://jayisgames.com/review/hex-empire.php#walkthrough
> A hex grid certainly addresses that problem, but since I was limited to text, squares it was!
FWIW, you can do hex pretty well as:
FWIW, you can do hex pretty well as:
# # # # # # # ()()()()()()()
# # # # # # or ()()()()()()
# # # # # # # ()()()()()()()
I was also dealing with a 24*80 display. While your idea works, it would cut the size of map that could be displayed in half.
Similarly a square-grid works fine with a 3/2 cost for diagonals as long as typical movement is much greater than 1 square per turn (3 squares of movement per turn is the minimum to not significantly privilege lateral vs diagonal), but that also greatly reduces what can be displayed on the screen at a time.
Hey Walter, thanks for doing the interview and AMA, how cool!
I was a young teen when my Dad got Empire and began to play it regularly with one of his friends. I would frequently watch them play while trying to learn the game mechanics and strategy, and then later would play the game myself for hours on end.
That time watching and playing Empire was really an introduction to computing and gaming for me and would later lead to a passion for building, RTS/fog-of-war games (e.g. starcraft), and a career building software.
Just wanted to say thanks! Now I need to figure out how to download the game and play it with pops.
I was a young teen when my Dad got Empire and began to play it regularly with one of his friends. I would frequently watch them play while trying to learn the game mechanics and strategy, and then later would play the game myself for hours on end.
That time watching and playing Empire was really an introduction to computing and gaming for me and would later lead to a passion for building, RTS/fog-of-war games (e.g. starcraft), and a career building software.
Just wanted to say thanks! Now I need to figure out how to download the game and play it with pops.
Were you involved with the DOS version of the game? A friend in university had a copy of it on the DOS machine we used to type papers and I got rapidly sucked in after discovering it.
The character mode DOS game I wrote. The graphics one was converted from text to graphics by Mark Baldwin.
Hello Walter!
I'm interested in programming languages and the design of compilers. I'm relatively novice to programming, but languages have long captured my imagination.
Three questions for you: Do you have a blog where I can read about your compiler escapades? have you any advice for the aspiring novice? which is your favorite language, and why?
I'm interested in programming languages and the design of compilers. I'm relatively novice to programming, but languages have long captured my imagination.
Three questions for you: Do you have a blog where I can read about your compiler escapades? have you any advice for the aspiring novice? which is your favorite language, and why?
> where I can read about your compiler escapades?
I don't really have a blog, but when I do write an article I'll link to it on twitter:
https://twitter.com/WalterBright
A collection of articles I wrote a while ago:
https://www.digitalmars.com/articles/index.html
Presentations:
http://www.walterbright.com/
And, of course, the Emperor who will get mad and put another continent under iron control if he's not mentioned:
https://twitter.com/classicempire
I don't really have a blog, but when I do write an article I'll link to it on twitter:
https://twitter.com/WalterBright
A collection of articles I wrote a while ago:
https://www.digitalmars.com/articles/index.html
Presentations:
http://www.walterbright.com/
And, of course, the Emperor who will get mad and put another continent under iron control if he's not mentioned:
https://twitter.com/classicempire
[deleted]
Advice for the novice. Hmm. Best advice I can give is ignore your critics and everyone who tells you it can't be done, you're not good enough, you'll inevitably fail.
Market research has always led me astray. Making things that simply please myself have been far, far more successful.
Which is my favorite language? D, of course! As for why, it's the language I always wanted to program in, though I didn't realize it and it was a process to discover it.
Market research has always led me astray. Making things that simply please myself have been far, far more successful.
Which is my favorite language? D, of course! As for why, it's the language I always wanted to program in, though I didn't realize it and it was a process to discover it.
I've listened to the two interviews you have published, and I intend to work my way through your publications. I'm currently in love with OCaml, but I'm resolving that D should be my next language. Funnily enough, I'd already downloaded it a few months ago; I have a dedicated flash drive for storing compilers, it was a very pleasant surprise to find Walter Bright already chilling in my memory.
I loved the podcast you did with Alexandrescu on GoingNative! The two of you said that you want D to have a million users; how does user accumulation work in programming languages? Intuitively, I'd expect linear growth until some critical point, and exponential thereafter. Do you agree? if so, what do you think that critical mass might be?
Also, on that same podcast, the host evaluated that D is ready for the million users you're shooting for. Do you have any plans to open a software shop or a consultancy to bring D into the industry? I've seen certain other language organizations, like the Haxe folks, do similar.
With regards to D-Lang: why do you ask that contributors assign copyright to you for improvements made to dmd? Is that just so you control the code-base?
Finally, I'd love to see a section of low-hanging fruit for novice contributors to work on. Whatever incentive it's worth: I will personally commit to fulfilling at least one item of any such list, if and when it should ever be published.
I'll be following D-Lang much more closely, I'm very excited to see how it evolves!
I loved the podcast you did with Alexandrescu on GoingNative! The two of you said that you want D to have a million users; how does user accumulation work in programming languages? Intuitively, I'd expect linear growth until some critical point, and exponential thereafter. Do you agree? if so, what do you think that critical mass might be?
Also, on that same podcast, the host evaluated that D is ready for the million users you're shooting for. Do you have any plans to open a software shop or a consultancy to bring D into the industry? I've seen certain other language organizations, like the Haxe folks, do similar.
With regards to D-Lang: why do you ask that contributors assign copyright to you for improvements made to dmd? Is that just so you control the code-base?
Finally, I'd love to see a section of low-hanging fruit for novice contributors to work on. Whatever incentive it's worth: I will personally commit to fulfilling at least one item of any such list, if and when it should ever be published.
I'll be following D-Lang much more closely, I'm very excited to see how it evolves!
I figure critical mass is if I get run over by a bus, D will continue just fine. I don't know what that point is.
Many D community members do consultancy and education. Just drop by the forums and ask!
The copyright assignment thing is just so that the source will be unencumbered and we can ensure it remains fully Open Source.
I never offer suggestions for low hanging fruit anymore, as not a single person took them. I just point at the forums, hang out, and you'll soon find something interesting to work on.
There's also the learn forum:
https://forum.dlang.org/group/learn
Many D community members do consultancy and education. Just drop by the forums and ask!
The copyright assignment thing is just so that the source will be unencumbered and we can ensure it remains fully Open Source.
I never offer suggestions for low hanging fruit anymore, as not a single person took them. I just point at the forums, hang out, and you'll soon find something interesting to work on.
There's also the learn forum:
https://forum.dlang.org/group/learn
cybernautique, we can't contact you on your email listed on your profile {username} (at) bitsoflore (dot) net
Please contact us on morphle (at) ziggo (dot) nl
Please contact us on morphle (at) ziggo (dot) nl
I've replied from a different email address. Please check your spam/junk folder!
Hey Walter,
What were your "salesman" lessons from Empire? What would you do differently today?
I'd do everything different today. Being a nerd, I had absolutely terrible social skills and did everything wrong. I couldn't sell a $20 bill for $10. I've been trying for decades to do better with that.
But the best lesson is to associate with someone who can sell.
But the best lesson is to associate with someone who can sell.
Hi Walter.
I was curious about your opinions on some of the mathey functional languages out there, like Haskell or OCaml or F# or even something more elaborate like Idris or Agda. Do you feel like they should have a place in industry, or just high-level self-indulgence?
I was curious about your opinions on some of the mathey functional languages out there, like Haskell or OCaml or F# or even something more elaborate like Idris or Agda. Do you feel like they should have a place in industry, or just high-level self-indulgence?
I took Erik Maijer's course on Haskell, and enjoyed it quite a bit, though I haven't written a line of Haskell. D makes available a number of functional language things, like transitive immutability, purity, and lambdas. Haskell went a bit too far with minimizing the syntax, as redundancy in syntax makes for better error diagnostics. Otherwise it's a nice language.
I attempted to write some code in OCaml, but failed miserably. My (short) programs would fail with incomprehensible (to me) error messages. Trying different syntaxes just produced other messages. Other than the OCaml book, which I had, I couldn't find any helpful information online. I gave up on OCaml. OCaml may actually be a great language if it had a better compiler and far better documentation.
I know nothing about F#, Idris or Agda.
I attempted to write some code in OCaml, but failed miserably. My (short) programs would fail with incomprehensible (to me) error messages. Trying different syntaxes just produced other messages. Other than the OCaml book, which I had, I couldn't find any helpful information online. I gave up on OCaml. OCaml may actually be a great language if it had a better compiler and far better documentation.
I know nothing about F#, Idris or Agda.
Have you dived much into full body VR and VR social experiences?
That sounds like fun, but I've never tried it.
What kind of projects I need to do and books I need to read to be a good programmer in your point of view?
Writing games are a really fun way to learn to program. The best way to learn how is to find an open source game that you like, figure out how to build it, then start modifying the game to your personal taste.
Learning the basics of writing compilers will be surprisingly helpful for all kinds of programming tasks. The Dragon Book is the best:
https://www.amazon.com/Compilers-Principles-Techniques-Tools...
Too bad the prices are so high for it. The original version is much cheaper:
https://www.amazon.com/Principles-Compiler-Addison-Wesley-in...
Learning calculus is a great way to train your mind to think better.
Learning the basics of writing compilers will be surprisingly helpful for all kinds of programming tasks. The Dragon Book is the best:
https://www.amazon.com/Compilers-Principles-Techniques-Tools...
Too bad the prices are so high for it. The original version is much cheaper:
https://www.amazon.com/Principles-Compiler-Addison-Wesley-in...
Learning calculus is a great way to train your mind to think better.
Thank you for the reply. This is valuable and actionable advice.
Why can one city just build one unit at a time? Is there a game design rationale behind this?
Too many units too fast just seemed to create a logjam where then you'd have your units attack each other just to get them out of the way.
Thank you. This is something the Civ5 designers should have known.
[deleted]
The Computer History Museum really needs to do an interview with Walter to add to their oral histories series. pls halp.
You may not have played the game Empire, but if you've played any computer wargame, you've played something influenced by it. I'm very honored to have had the chance to discuss the development of Empire with Walter!
As mentioned in the article, he is a sometimes-reader of Hacker News, so if people have any follow-up questions, we may just get lucky and have him drop by to answer a few.
As mentioned in the article, he is a sometimes-reader of Hacker News, so if people have any follow-up questions, we may just get lucky and have him drop by to answer a few.
[deleted]
I loved Empire Deluxe so much (by Baldwin & Bright) -- my favorite in the series -- that I once wrote my own private clone. in C and OpenGL. even drew all the bitmap icons and tile graphics myself. went nuts adding extra unit types. now gathering dust on a "disk" somewhere. Tell myself some rainy day I'll resurrect it...
Great interview! I've always thought it was really neat that Walter posts here semi-frequently, and it's really fascinating to get even more of a peek into the mind of such a creative individual.
Now I really need to get serious about starting a project in D so I can learn it properly...
Now I really need to get serious about starting a project in D so I can learn it properly...
I still have plenty of critics :-)
Perhaps from people with a grudge about those sleepless "one more turn" nights ;-)
I take it as vaccination against World of Warcraft, etc.
Thanks, Walter
I take it as vaccination against World of Warcraft, etc.
Thanks, Walter
You're most welcome!
> My interest in Empire is not so much playing it anymore, it's devising a better computer strategy. I'm a lot more experienced in how to do such things today, and the temptation is strong to go do it. But I need to focus on my compiler stuff.
Please, karma grant me this wish: ...
Please, karma grant me this wish: ...
Here's Walter's comment which the OP refers to at the beginning:
https://news.ycombinator.com/item?id=28658090
https://news.ycombinator.com/item?id=28658090
Had no idea WB also wrote Empire! Small world indeed. As so many others have said, thanks for all the good times!
This was a great read, made my day remembering the 'good ol days' when I was so young and games were so fun.
This was a great read, made my day remembering the 'good ol days' when I was so young and games were so fun.
I thought this was gonna be about Bright’s geopolitics.
Nobody cares about my political opinions :-)
This part resonated: my father had various issues over the years (we suspect undiagnosed depression but he refused care) and Empire was one of the games he'd spend days on. Growing up, it took me a while to realize that the problem wasn't the game but the personality trait which lead to that behaviour cropping up anywhere possible.
I found the mention of a Wang word processor interesting as that was one of my dad's employers. They apparently had quite a few management issues but he had some stories about one of their better salespeople — this one guy apparently had legendary expense claims but was also frequently the top performer in revenue. When word processing was a department in a business, it was often run by an older woman who'd come up through the ranks and while they had a high-sounding title they often weren't given a lot of respect by the other department heads and a lot of the other vendors more or less followed that with a take-it-or-leave-it approach. This sales guy would do things like rent a helicopter to take someone from LA to lunch on Santa Catalina to discuss a deal or see how things were working out at an existing company — simultaneously far more than the internal rules allowed but also a tiny fraction of the profits they made from a major company buying Wang hardware globally.