
What is ZIL anyway? - MrRadar
http://blog.zarfhome.com/2019/04/what-is-zil-anyway.html
======
kmill
Looking through a bunch of code in the archive, it was interesting to come
across the macro for TELL, which is used everywhere in games as a sort of
printf, and it has some special printf-like codes to print out names of
objects and such. There are also some functions that have been declared with
DEFINE rather than ROUTINE. Both the macros and the DEFINEd functions use the
features of the greater MDL at will.

What is interesting in particular is how it possibly reveals their setup: they
had a full MDL interpreter running on their workstations, and ZIL is a subset
that could be cross-compiled to a stripped-down target: the Z-machine.

It looks like ROUTINE, OBJECT, ROOM and such are macros (in sources unknown)
that would define standard MDL objects, possibly stored in some structure for
findability. Then, the cross-compiler would be a program that takes these
objects and writes out some Z-code. The workflow probably allowed (1) playing
the games directly in the interpreter without compilation (2) making small
changes to a running game and (3) recompiling the Z-code after having made
those small changes, without needing to reload all the game's source code.

Except for the cross-compilation step, this is the sort of environment the
original Zork would have been written in, and I find it hard to imagine they
would have accepted anything less.

~~~
pinewurst
Except their “workstations” were the likes of VT100 terminals connected to
their DEC-20.

------
bayesian_horse
Maybe there can be a new golden age of interactive fiction using modern NLP
and other AI related technologies?

~~~
jordanpg
I enjoy thinking about the future of IF. I see it as a gaming/storytelling
medium with a simultaneously huge potential but still vast chasms to cross
before it gets there.

NLP etc. has great potential to improve the parsing capabilities, to be sure,
but it's not obvious to me that that will dramatically improve the experience.
Is `pick up the shiny brass thing` really better than `GET LAMP`? IMO, it
might make IF more accessible to non-techy, non-text parser gamers, but that's
about it.

I think the next leap for IF games will involve non-linear stories that are
better suited to the medium. The success of games like "Papers, Please" in
particular has sparked my imagination in this area.

~~~
willvarfar
I recall a Ludum Dare entrant which was an android app that pretended to be a
walkie-talkie to control some security operatives you were telling to search a
building to investigate some noises. Very spooky. And a very good use of some
basic voice parsing and NLP.

~~~
reificator
Link please?

That is an incredibly ambitious concept for a game jam, but it sounds like
they pulled it off?

~~~
klodolph
Game jams are literally the best time to try risky concepts. If it fails,
you’ve spent only a small amount of time, and there’s a good chance that
people will play your game and give you feedback. I can’t think of a better
time to take a risk.

(Note: Parent comment edited risky -> ambitious.)

~~~
reificator
I didn't mean it was a risk in any negative sense. I was just looking for the
word "ambitious" and couldn't find it in my sleep deprived state...

Seriously, I'm so tired I looked up "ballsy thesaurus" and clicked related
words for probably five minutes before I gave up looking and just typed
'risky' hoping it'd be good enough.

------
mratzloff
Very cool! Being an IF collector, I acquired the source code to Restaurant at
the End of the Universe years ago. It's generous to call it unfinished—it's
barely a game. I wasn't sure whether or not I could publish it, but it's great
that this and much more are now available to everyone.

I also have some internal Infocom emails and photos and things. Not sure if
posting those would be welcome by the participants since most of them are
still alive.

~~~
RandomBacon
> Not sure if posting those would be welcome by the participants since most of
> them are still alive.

Genuinely curious... is it okay to post private details of a person once
they're dead? There are things that I want to keep private while I'm alive,
and that I hope stay private when I'm dead. Does other people's curiousity
trump my wishes just because I'm no longer around?

~~~
aidenn0
IANAL, but...

In the US, it's reasonably well established that you have no privacy rights
after death[1].

That doesn't necessarily make it safe to publish details about someone after
they are dead though as property rights do exist through the estate of the
deceased, so you may have to end up defending yourself from a defamation suit.

In terms of it being "okay" there are unwritten rules about allowing some not-
well-defined period of mourning before publishing private details,
particularly ones that reflect poorly on the deceased.

Publishing e.g. private correspondence of people from just 100 years ago seems
completely non-controversial though.

1: [https://en.wikipedia.org/wiki/Post-
mortem_privacy](https://en.wikipedia.org/wiki/Post-mortem_privacy)

------
linsomniac
What does this have to do with the Zfs Intent Log?!? :-)

~~~
myself248
That's what I thought I was coming here to read about. HN article titles are
the worst.

------
zzo38computer
I have not programmed in ZIL or Inform, but have made implementations of
Z-machine, as well as a "Tricky Document" describing various optimizations
that can be used in a Z-machine code (such as Black-Johansen text packing, the
SET->BCOM optimization, storing introduction text in the input buffer, etc).

~~~
taradinoc
Do you like this?

~~~
zzo38computer
I like Tricky Document; that is why I wrote it. (Or do you mean something
else? If you mean ZIL, well, then I don't know a lot about that.)

------
Tepix
Wow, these are layers upon layers of archaic stuff. The article got me curiohs
about Inform7 so i watched the introductory screencast on Vimeo
[https://vimeo.com/4221277](https://vimeo.com/4221277) . I‘m blown away! It
appears to be easy to learn, feature rich and also well documented. Oh and
it‘s also free! If you are interested in IF, go check it out.

------
lousken
FYI the article is not about ZFS ZIL but Zork Implementation Language

~~~
chungy
I too assumed this was going to be about the ZFS Intent Log.

------
mruts
It seems like MDL uses both greater/less than and parens. Is this analogous to
Scheme using both brackets and parens? That is, just for readability?

~~~
jerf
It was the early 80s. Readability wouldn't be invented for about another 20
years or so.

Actually kinda serious. You need to be able to spare the RAM to have the
comments, whitespace, large variables, breaking things nicely into functions,
etc. I've got modules I've documented where the documentation alone would fail
to fit into, say, a Commodore 64's RAM, as plain text. Early 1980s "big iron"
would still be considered on the high end of embedded programming today. (In
the sense that a Raspberry Pi is embedded programming.)

~~~
abecedarius
They developed these on a
[https://en.wikipedia.org/wiki/PDP-10](https://en.wikipedia.org/wiki/PDP-10).
It's not like they were editing/compiling on the C64. Of course targeting
small systems does influence the coding style, but...

~~~
jerf
A top-end PDP, according to that page, could _address_ ~8MB, though I'm sure
they didn't have it for a while; other charts on the internet suggest a top-
end PDP-10 would get up to 33 _mega_ Hz.

8MB for an embedded controller is no great ask and you have to crawl a ways
down the spec sheet pile to get a 33MHz processor nowadays. A top-end PDP-10
would today put it roughly on par with an Arduino [1], although the Arduino
would be a bit short on RAM.

Even if you have the space to spare on comments and long variable names,
you've been raised in a culture that considers those insanely expensive
extravagances.

[1]:
[https://www.arduino.cc/en/Products/Compare](https://www.arduino.cc/en/Products/Compare)

~~~
abecedarius
Here's some code from the 1970s MIT Lisp/PDP-10 culture:
[https://github.com/dhess/rabbit-
scheme/blob/master/rabbit.ls...](https://github.com/dhess/rabbit-
scheme/blob/master/rabbit.lsp)

The indentation and all-caps are not modern, and the MACLISP primitive names
like TERPRI are unchanged from the 60s. Otherwise, the coding and commenting
style would not really raise any eyebrows today.

I first learned of literate programming from this culture instead of Knuth,
e.g.
[https://dspace.mit.edu/handle/1721.1/41983](https://dspace.mit.edu/handle/1721.1/41983)
("The fourth section presents a completely annotated interpreter for AMORD").

I'm just saying yeah, expectations have definitely evolved, but it's not the
case that PDP-10 hackers back then had not yet discovered or valued
readability.

~~~
jerf
Yes, of course some people had that opinion. It was a fringe position back
then, though.

It's less fringe today, but I'm still not sure "code should be optimized for
reading, not for writing" isn't _still_ a fringe position, at least as
evidenced by what people's actions say about their beliefs, rather than their
words. Lip service of that is probably at least not fringe any more, which is
progress of its own sort.

~~~
abecedarius
All I'm saying is that the Infocom Imps developed on a computer that was
plenty big enough for comments and readable names to be no extravagance. The
sources above show it happened in practice and not just in theory. The company
started after they'd been used to this kind of environment for years. (And
they were at least adjacent to actual literate-programming pioneers.)

I'm not saying they were into literate programming, I'm saying it's misleading
here to talk about what coding on the C64 was like.

