Live data from Hacker News

A talk with Walter Bright about Empire

madned.substack.com

91–100 of 102 posts

Re: A talk with Walter Bright about Empire

#91

Earlier quoted context omitted.

> One is the use of macros in programming languages. 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.

Re: A talk with Walter Bright about Empire

#92
post #35

Earlier quoted context omitted.

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 sys…

In other words, they're a completely different language feature than the one in C that happens to go by the same name.

[deleted]

Re: A talk with Walter Bright about Empire

#93
post #6

Earlier quoted context omitted.

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…

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 aut…

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.

Re: A talk with Walter Bright about Empire

#94
post #35

Earlier quoted context omitted.

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 sys…

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.

Re: A talk with Walter Bright about Empire

#95

Earlier quoted context omitted.

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?

Re: A talk with Walter Bright about Empire

#96

Earlier quoted context omitted.

> One is the use of macros in programming languages. 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.

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.

Re: A talk with Walter Bright about Empire

#97

Earlier quoted context omitted.

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…

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.

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

Re: A talk with Walter Bright about Empire

#98

Earlier quoted context omitted.

> 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: # # # # # # # ()()()()()()() # # # # # # or ()()()()()() # # # # # # # ()()()()()()() although unless you're using CJK-width characters, the visual design can be a bit nontrivial.

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.

Re: A talk with Walter Bright about Empire

#99
post #27

Earlier quoted context omitted.

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…

Thank you for the reply. This is valuable and actionable advice.

Re: A talk with Walter Bright about Empire

#100

Walter here! AMA!

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?

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

Post reply on HN