(hide navigation)
  • Swedish content
Fund my projects
Patreon
Steady
Forum
Register
Log in
Latest comments
Syndication
RSS feed
Feedback

Forum comments in chronological order

Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.

Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.

Aug 2022

A case against syntax highlighting

Anonymous
Mon 1-Aug-2022 20:10
Syntax-highlighting is a perfect example of a silly "flashy colour" phenomenon that degrades and impairs human concentration. Don't believe me? Go into *any* supermarket on this planet, and watch how *colour* is used to grab and re-direct your attention away from what is on your shopping list.

Very poor closing analogy that ruined an otherwise decent comment.

The coloring of text at the supermarket is specifically designed to call attention to itself and distract away from anything else. That is its entire purpose. There is a whole business called "marketing" built around this concept, which is totally irrelevant to the convo here.

The truth is that this type of subjective argument is as old as time. Any type of tool or feature in a development environment will have its champions and its detractors. I can remember when I started coding (back in the days when Noah was still riding around on his ark), and this same type of argument was going on over whether VT-100 terminals should always stay set at 80 characters wide because the smaller font used in the 132-character wide mode decreased legibility so much that it was distracting and ineffective. Obviously it depended on the eyesight of each individual as to whether that was true or not, but the battle lines were drawn. And the lines continue to be drawn to this day with the arrival of each new technology, programming language, or dev tool.

So if you like syntax highlighting and feel it enhances your dev workflow, use it in good health! If you find the highlighting distracting, by all means turn it off! The compilers and interpreters will be happy with the code either way.

The TTY demystified

Anonymous
Tue 2-Aug-2022 07:54
I'd just like to point out another awesome article about "What happens when you press a key in your terminal?" by Julia Evans (b0rk)
https://jvns.ca/blog/2022/07/20/pseudoterminals/

kind regards
-mrizvic

Dialog

Anonymous
Wed 10-Aug-2022 07:17
You have clearly demonstrated by your work such as Impossible Bottle that Dialog if very capable. As it stands now, is it close to full release or can we expect further beta releases in the future? In particular, can we expect future releases to cause deprecations in the current code? Thank you.

Kernighan's lever

Anonymous
Thu 18-Aug-2022 19:41
If this is all true, a perfect solution would be to debug the program 10 years after you've wrote it...

However, you will be tempted to rewrite it because after those years the code will be rated down into the boring area, so you'll need another 10 years to wait to debug it.

Okay

Dialog

lft
Linus Åkesson
Fri 19-Aug-2022 12:47
You have clearly demonstrated by your work such as Impossible Bottle that Dialog if very capable. As it stands now, is it close to full release or can we expect further beta releases in the future? In particular, can we expect future releases to cause deprecations in the current code? Thank you.

Thanks!

I would say that most of the language is stable, but I do have a few changes in mind that would break compatibility.

The first is to remove the inline style-changing predicates, e.g. '(bold)', because style classes already cover this functionality. Removing the inline versions will simplify the language definition and the virtual machines.

The second is to extend the range of integers to include larger numbers and negative numbers. This will break the current behaviour where e.g. '($ minus $ into $)' fails if the answer would be negative.

Third, I'd like to add built-ins for analyzing and synthesizing words that have a mandatory part and an ending. When that's available, removable word endings can be implemented entirely in library code, and thus removed from the language itself.

I'm also pondering if maybe number should be a subtype of word (so all numbers are also words). This would in my opinion make the language definition more elegant, but it would definitely break old code.

So I don't want to leave beta just yet. But it may be possible to write games that will work with future versions of the language, if the above changes are taken into account.
Anonymous
Sun 21-Aug-2022 17:40
Very nice! Thank you for your thoughtful reply. I am looking forward to future releases.

A Mind Is Born

Anonymous
Wed 24-Aug-2022 21:25
Simply amazing :-)

Dialog

Anonymous
Fri 26-Aug-2022 16:59
Hi Linus,

Thank you so much for working on and sharing Dialog, it got me back to IF again, and I really love how the language itself makes you think out of the box when compared to a considered-to-be standard programming language.

In case you missed it, I've posted a possibly incorrect unification behaviour regarding lists in the Dialog category over at IntFiction, which currently inhibits lists from being more dynamic by being able to apply items to them multiple times.

Regarding numbers, I like that they are regarded as rule head parameters at the moment, they are particularly useful when used as output for queries.

Cheers!

C64 Theremin

Anonymous
Tue 30-Aug-2022 01:00
Amazing. Any plans on sharing the code?

My music on streaming platforms

Anonymous
Wed 31-Aug-2022 21:01
dear Linus, you've made my day super happy with the fact that you are existing and make these wonderful music ♡♡♡