Forum comments in chronological order

Anonymous
Thu 6-Dec-2018 03:08

Very smart move, ^ and excellent points.
See here:
https://www.fastcompany.com/40516897/a-new-wave-of-bad-ads-is-hijacking-even-top-tier-websites

Linus,the only reason I allowed Javascript to run from [your awesome] site is so I could post a reply here.
(I also checked the page source-code and it looks like the JS is only used for your comment box, search function and page navigation. To me, that's acceptable use of JS. I block all JS by default, and run Request Policy in all my browsers. These two addins stop dead in their tracks almost all known threats and popups, plus it saves me bandwidth - I'm capped.
I despise pages loaded w/ JS.) ;-)

Anytime a company says you can't modify - or even view - the source-code, HTML, or CSS; RUN !
Don't let their code ever touch your page.

Thank you Linus for using some deductive reasoning and saving yourself - and your visitors - a world of headaches.
I just happened across your site today, and would like to say it's pretty cool.
Thank you for putting it up.
I don't bookmark pages, that can be tracked, but I did pull a copy of one page in .maff, so I can find you again. (Hope you don't mind.)

Pretty cool site. :-)

Anonymous
Tue 11-Dec-2018 09:31

Dialog looks interesting, any chance that the source for Tethered will be released?

Anonymous
Tue 11-Dec-2018 11:34

I know I'm late to the party, but I liked the article. It's a valuable perspective and critique, and I likewise understand the passion sparked by the argument instead.

Speaking as a non-neurotypical programmer, however, I feel the issue is more nuanced: I'm not sure the proposition is as binary as the article seems to paint it. This is my takeaway of the article, as fairly as I can put it:

* Syntax highlighting wrongly shifts the focus from structure to the building blocks themselves. This causes developers to fixate on form rather than function.
* Syntax highlighting offers a shortcut around proper understanding, until that shortcut no longer works and then the student is effectively stymied.
* Syntax highlighting encourages poor habits, such as the aforementioned skimming.
* Syntax highlighting doesn't help in situations where it would be genuinely beneficial, or at least, does not offer a sturdy enough safety net that you can afford to lean on it.

These points are fair, but I feel they are predicated on the notion that this is all that syntax highlighting can offer, particularly for programmers whose brain architecture and thus cognition may differ from that of the norm. I do not consider myself stupid (although that may be the Dunning-Kruger effect talking), but I do quite often feel stupid when faced with the common tools of the profession. To me, the benefits of syntax highlighting go well beyond simply allowing me to tell the difference between an object and a type. I shall forbear from quoting Dijkstra's observations on phrenology, and instead simply observe that given the choice between expending significant cognitive effort on following code execution and instead using that energy to be more productive, I much prefer the second option.

So what does syntax highlighting give me?

* I have ADHD. In addition, my mind is visually oriented: it uses shapes and colors to attach meaning. The way my brain partitions a program is thus a natural fit for a discreet application of color. That way, I don't have to keep the entire program in my skull (I'm a C++ programmer in a legacy codebase: we have hundreds of 7000+ LOC files that all interact in nonobvious ways, and focusing on all those details is simply unviable). It makes the code structure itself distinct to me, which is a very good help when getting my bearings, and prevents my brain from spinning out of control and overfocusing on the wrong things.
* Similarly, I've occasionally experimented with editors that let me move temporarily irrelevant code out of focus. That is a massive boon for me, because I can still easily see where things are, I'm just not forced to pay attention to them, allowing my brain to assign them a smaller portion of my attention.
* The article appears to cast understanding and skimming as mutually opposing phenomena. I would question that. To the contrary, I believe both are necessary in order to advance: it's part of what makes high-level abstractions (leakiness and all) such a powerful concept. When I look for bugs, a total in-depth understanding of all the code that passes under my eye would be detrimental... and likely take years. Instead, I skim, and while syntax highlighting may encourage skimming, I submit that is so for another reason: because it makes skimming viable and a useful tool for quickly evaluating the gist of a given piece of code. For someone such as I, who read code iteratively, it is a godsend.
* Visual Studio represents code that is defined out in a lighter shade than code that will actually run. I have no idea what I would have done if I hadn't had that feature, but I suspect refactoring would simply not have happened.
* The fact that syntax highlighting doesn't solve several preventable bugs is unfortunate. It does not, however, invalidate the concept itself. All it proves is that syntax highlighting falls short of perfection.

So I think there's value in syntax highlighting. It certainly helps me. However, there's a good case to be made against syntax highlighting as it is. On reflection, I've come to realize that the issue rather resembles the criticism levied against Hungarian notation, and that seems to indicate that the problem isn't so much that syntax can be highlighted but that it's often highlighted in the wrong manner and for the wrong reasons. We generally don't garish colors for all the types and objects and keywords.

But we *can* use it to lace the source with actual meaning, and this is particularly fine if the compiler and editor can use it to dispense with what would otherwise be useless and mentally taxing makework.

Eleas
Björn Paulsen
Tue 11-Dec-2018 11:39

(The above screed was mine. Unfortunately the login window lapsed.)

Anonymous
Tue 11-Dec-2018 17:44

if I have an object in a closed transparent container how do I override the default 'you can't reach obj' take fail message?

(instead of [take *]) doesn't seem to work in this case (scope?)

lft
Linus Åkesson
Wed 12-Dec-2018 09:35

The "can't reach" message is printed by (refuse $), which is invoked before instead-of. So you can override refuse with a negated rule:

~(refuse [take *]) %% Don't refuse to take this object.

Eleas
Björn Paulsen
Wed 12-Dec-2018 10:15

When I was younger, I had this idea that you needed enthusiasm to carry a project. I've now come to believe that's wrong. Enthusiasm is fine, but it can't be your foundation, because it's fickle.

So my take on it is this: if you have an idea for some project, don't be afraid to structure it, to ponder it, to build test cases. You may feel as if that kills the magic, but I think that if your enthusiasm for the specific idea is that fragile, then it wouldn't have survived long enough to carry the project to completion anyway.

Anonymous
Thu 13-Dec-2018 11:55

Is it possible to suppress implicit actions temporarily.
For example
1.dropping something in a held container first tries to take the object before dropping.

2. putting something into something where the first something is in a held container tries to take before putting in

If I know that the take will always succeed can I suppress the first trying to take reporting.

lft
Linus Åkesson
Thu 13-Dec-2018 22:54

Yes, there are several ways. You can override the before-predicate for that particular case, with a negative rule. For each particular action:

~(before [drop $X])
        ($X is #in $Y)
        ($Y is #heldby $Z)
        (current player $Z)

But many actions invoke a common predicate, '(ensure $ is held)', and you can add a new rule to that one instead:

(ensure $X is held)
        ($X is #in $Y)
        ($Y is #heldby $Z)
        (current player $Z)

When the given conditions are true, your rule will succeed, and this prevents the later rule definition in the library from executing.

Eleas
Björn Paulsen
Fri 14-Dec-2018 11:30

The Cloak of Darkness example seems bugged under 0.15. Attempting to go somewhere yields a crash:

Eleas
Björn Paulsen
Fri 14-Dec-2018 11:34

This is odd. I get the same error when running the first example in chapter 5. I'm running the win32 version of dialogc on Windows 10, in case that matters.

Eleas
Björn Paulsen
Fri 14-Dec-2018 11:44

I've now checked each release of the compiler, and found that moving between rooms only works under release 0b/01. Later than that leads to the fatal error described above.

Anonymous
Fri 14-Dec-2018 12:18

Not sure if it's related but I only get the error when using Gargoyle. Frotz doesn't give the error. (latest versions Windows 10)

Eleas
Björn Paulsen
Fri 14-Dec-2018 12:54

Thank you. Can verify. Does anyone know the best way to pass a bug report to one of the maintainers?

lft
Linus Åkesson
Fri 14-Dec-2018 13:47

This looks like a Dialog bug. Thanks for reporting; I'm on it!

lft
Linus Åkesson
Fri 14-Dec-2018 14:36

Fixed in 0c/04.

Anonymous
Tue 18-Dec-2018 12:05

Can I reference an object variable from within the scoring options?
(increase score by (#object variable))

lft
Linus Åkesson
Tue 18-Dec-2018 13:14

As a general rule, queries can't be nested; they don't even have return values.

(Confusingly, rule heads may contain nested expressions, but that is a special case of syntactic sugar.)

But output can be communicated using ordinary parameters. To take the output from one query, and use it as input in another, you would write the queries one after the other. Then you'd use a variable to carry the value.

Assuming you have a predicate ($ has score $) that assigns a score to every object:

        (#object has score $X) %% Here, $X becomes bound (i.e. to the output).
        (increase score by $X) %% Use the value of $X as input.

Anonymous
Wed 19-Dec-2018 01:41

I thought i was the only one listening to his stuff in 2018

Anonymous
Sat 22-Dec-2018 12:08

Oh my gosh you made these? I saw some tutorials and awesome videos of people playing 'em online and ordered the Arcade, seeing them instantly made me think back to your bitbuf and the really cool demo of it you put out. Awesome to have some tech you designed, great job man :)

Anonymous
Sat 29-Dec-2018 20:10

Thanks for an informative article. I really learned something!
-Tom