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.
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.
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!"
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.
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.
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.
Disagree here. Unix process, file access api's, programming languages are all abstractions that make life easier.
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.
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.
> 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?
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.
> "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:
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.
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.
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.
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 :-)
Macros killed the Lisp. They never noticed.
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.
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.
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.
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.
It's similar to movies. Special effects are momentarily interesting, but it's the plot that overwhelmingly matters.
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 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 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.
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.)
But I am attracted to full motion simulators that would, say, enable me to drive an F1 car without risk or much investment.
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 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.
Fear, though, is what kept me from getting decent lap times. With a simulator, that is no barrier.
Then we would solve this, and also provide more immersion for flight simulators.
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/
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?
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.
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.
The distinguishing feature of Contract Programming is how it handles inheritance. But OOP isn't as pervasive as it used to be.
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).
How does it handle it?
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.
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 :)
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.
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.
FWIW, you can do hex pretty well as:
# # # # # # # ()()()()()()()
# # # # # # or ()()()()()()
# # # # # # # ()()()()()()()
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'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 don't really have a blog, but when I do write an article I'll link to it on twitter:
A collection of articles I wrote a while ago:
And, of course, the Emperor who will get mad and put another continent under iron control if he's not mentioned:
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 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!
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:
Please contact us on morphle (at) ziggo (dot) nl
But the best lesson is to associate with someone who can sell.
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 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.
Learning the basics of writing compilers will be surprisingly helpful for all kinds of programming tasks. The Dragon Book is the best:
Too bad the prices are so high for it. The original version is much cheaper:
Learning calculus is a great way to train your mind to think better.
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.
Now I really need to get serious about starting a project in D so I can learn it properly...
I take it as vaccination against World of Warcraft, etc.
Please, karma grant me this wish: ...
This was a great read, made my day remembering the 'good ol days' when I was so young and games were so fun.