Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A talk with Walter Bright about Empire

madned.substack.com

Post reply on HN
Print view View original

81–90 of 102 posts

Re: A talk with Walter Bright about Empire

#81

Post by WalterBright »

spaetzleesser wrote: post #65
WalterBright wrote: post #39

Earlier quoted context omitted.

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.

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.

Re: A talk with Walter Bright about Empire

#82

Post by mike_hock »

fouric wrote: post #35
raverbashing wrote: post #29

Earlier quoted context omitted.

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

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.

Re: A talk with Walter Bright about Empire

#83

Post by holler »

WalterBright wrote: post #3

Walter here! AMA!

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.

Re: A talk with Walter Bright about Empire

#84

Post by vram22 »

WalterBright wrote: post #68
int_19h wrote: post #66

Earlier quoted context omitted.

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.

How does it handle it?

Re: A talk with Walter Bright about Empire

#86

Post by int_19h »

vram22 wrote: post #84
WalterBright wrote: post #68

Earlier quoted context omitted.

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. 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.

Re: A talk with Walter Bright about Empire

#87

Post by int_19h »

WalterBright wrote: post #68
int_19h wrote: post #66

Earlier quoted context omitted.

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.

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).

Re: A talk with Walter Bright about Empire

#88

Post by a1369209993 »

WalterBright wrote: post #38
justin66 wrote: post #25

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.

> 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.

Re: A talk with Walter Bright about Empire

#89

Post by bakul »

WalterBright wrote: post #78
bakul wrote: post #73

Earlier quoted context omitted.

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

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

> 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 :-)

Re: A talk with Walter Bright about Empire

#90

Post by WalterBright »

a1369209993 wrote: post #88
WalterBright wrote: post #38

Earlier quoted context omitted.

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.

> 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.
Post reply on HN