http://inform7.com/extensions/Emily%20Short/Computers/source...
I especially like the section that implements "search engines", building off of the terms defined in the chapters leading up to it.
http://inform7.com/extensions/Emily%20Short/Computers/source...
Michael Callaghan's fixed-point math extension is less prose-like but worth a peek. It shows how some of the more traditional programming language features can be translated to Inform (eg. explicit loops with ranges as repeat with X running from 1 to 7).
http://inform7.com/extensions/Michael%20Callaghan/Fixed%20Po...
Wow. Programming is so faddish! I know this, but it's still surprising. What other problems that we're struggling with have been basically solved, in some currently unpopular corner?
Yes, sadly; and this is because programming languages, like spoken languages, live and die by their community. And it's harder to cross-pollinate programming languages since all changes must be backwards-compatible with existing source text. Language interop is usually terrible. You can't easily bring just a bit of Inform into an application.
This is very slowly improving with the popularity of compile-to-llvm, compile-to-CLR, and compile-to-JS as intermediate targets.
The other factor in faddishness is ahistoricity; the most energetic and community-orientated people are young, but interested in building their own new wheels while overthrowing the old wheel order.
It's easier to write code for a small system than to read code for a large system.
It takes some time working with it to realize all the cool things it does for you. It's definitely worth spending a little time with.
I wrote HL in Inform 7. Could I have written the game in a more traditional IF language, such as Inform 6? (I6 is C-like.) Answer: yes, but it would have been a bunch more work and a lot more frustrating and painful.
The English-ish syntax of I7 takes some getting used to. Yes, you have to free yourself of any attachment to brevity. I7 code is verbose. The hidden benefit is that it's very easy to skim through and re-read. All code is write-once-read-many-times, right? You may be comfortable with "gruecount++", but "increase the grue counter of the location by one" is just as intelligible (and more so for people who didn't grow up on C).
The real strength, for me at least, is I7's rule dispatch model. Big swatches of HL's code look like this (yes, an exact quote):
Ritual-processing rule for rit-speaking anaphylaxis-word when at RSChymicStart and the bound of rstate is the retort and the reservoir comprises grey-acid-subst and the retort contains exactly perfect-diamond: [...]
I've got hundreds of these little code snippets, and I trust the compiler to stitch them together into a working state machine. If this were I6, I'd have to write giant functions and collect these snippets together -- in the right order, etc. If this were an OO language, I'd go crazy deciding what object each snippet is a method of. I7 just takes the above and runs. (Okay, I have to worry about the rule ordering a little, but I7 mostly gets it right.)
(You can see that I've forced some brevity in, by careful definition of the words "at" and "comprises" and "contains exactly". I like hyphenated-symbols too. Those are personal style choices.)
Once you've gotten your head around a few of the foibles, it's a lot less like writing a program and a lot more like just writing a book. In any case, agreed heartily with parent, it's a lot of fun to play around with!