wryl

Yep, that's what I meant. Lots of comments, not a lot of time for proofreading!

Hi! Yes! I'm intending on adding an RSS feed at https://wryl.tech/log/feed.rss within the next few days.

I have a habit of hand-writing the markup for the site, so it's missing a few features people expect from things like statically generated sites or hosted blog platforms.

I'm watching this thread for accessibility and feedback, and am taking the suggestions to heart!

It's still really impressive! Comparisons were thrown around to nushell, which is also a really impressive project. I can see the vision and I hope to follow along! :)

With a splash of Joe Armstrong!

This is really, really cool! Definitely going to share this around, I love tools like this. They bring so much visibility into dark spaces.

Thanks for the feedback regarding this, I've been trying to find a middle-ground between my authoring style (writing raw HTML with low overhead, instead of using a static site generator) and "portable readability".

I have a feeling it's just me not annotating the markup correctly, which I am in the process of fixing and porting around!

Thank you very much! Very much in line with the handmade ethos, and I'm hoping to get involved with more handmade (and handmade-like) things in the future. :)

While I sympathize that the stakes don't appear to match up, I am talking about all software, and also taking into account the fact that these frustrations are numerous. It'd be one thing if it was taken in small pieces, small cracks in the stairs, but half of them are missing on average.

I really don't like missing stairs.

We're very removed from the usage of our software, and experience it in short-form (hopefully) actionable signals that we use to inform our development process. We don't get to appreciate the real pain in this "death by a thousand cuts" unless we can somehow switch bodies with a new user.

I see programming as a trade, however, and we do have the power to govern the quality of our software. There are, however, incentives, financial or not, that can get us to look the other way.

Problems surrounding computing education do compound these frustrations, and I sympathize.

Having worked for larger organizations (whatever FAANG calls itself these days, I can't keep track), as well as academia and independent education, I've seen both halves of the "production line" for newcomers to computing.

Something has to change in how we bring individuals into our field. I have some ideas based on my experiences, but you're not in the wrong for feeling frustrated about this. It is the state of things, and many companies are not equipped to handle it, because it's unexplored territory.

Well, that certainly wasn't my intention, but in an environment of "I have a silver bullet and it'll cost you $X", I can understand the sentiment.

At the same time, I do want to show that I have confidence in my ideas. Hubris and confidence must be applied in equal parts.

Thank you for the kind words! "I appreciate them" would be an understatement.

And I agree entirely. Tracking the history of an abstraction will usually tell you its root, though it gets pretty muddy if that root is deep-seated!

Hi! Author here. I think it's important to address certain aspects of this post that people tend to misunderstand, so I'll just list them here to save myself the effort.

* I do not argue against abstractions, but against the unrestricted application of them.

* I do not advocate for a reversion to more constrained platforms as a solution.

* I do not advocate for users becoming "more technical" in a "suck it up" fashion.

The key to understanding the software crisis is the curves of "mastery of a platform" and "growth/release cycles". We have, in the past 40+ years, seen these curves diverge in all but a few sectors. We did not address the crisis when these curves were close in proximity, but the second best time is now.

As for folks calling this clickbait, it is the first in my log, and reflects my thoughts on the situation we find ourselves in as developers. The sentiments are mirrored, in various forms, around multiple communities, some of them based in counterculture.

I do want to deliver some part of the solution to these problems, so I do intend on following up on "I'll show you how". I am a single entity, so give me time and grace.

What's nice about rewriting as a concept is that bolt-on extensions to make things fast don't have to be awkward.

Built-in rules that take priority over user-defined ones, as well as special variables in Devine's implementation, allow us to gain back speed while retaining some idea of purity. We know these operations can be phrased in terms of rewrite rules, so let's shortcut them and use built-in arithmetic in place.

You'd never know the difference! There's also a lovely arithmetic library built by d6 that you may enjoy. It does arithmetic digit-by-digit, and they're continually improving it to run faster.

https://git.phial.org/d6/modal/raw/branch/d6/binary/arith.mo...

Devine and a few others are actually working that out! We're collaborating in the Concatenative Languages Discord server on how to use, extend and improve the language.

Not particularly, no. Nothing specific. The semantics of the language lend themselves well to an implementation in hardware. I had a sketch in VHDL in the time I spent developing this.

This means that the above sample is effectively your "assembly language". There was no gap between your programs and the hardware they ran on.

Modal can be used to write small utilities, games, programming language implementations, type systems.. the list goes on. It's a fully general meta-language that can be used for general purpose programming.

It's a general purpose programming language who's main paradigm is rule-based pattern matching.

A sample.

  <> (-- ?x) ()
  -- (Now we can add comments to what we are doing.)
  -- (Let's add some alternative syntax for defining rules.)
  <> (?x -> ?y) (<> ?x ?y)

  -- (Let's add some boolean operators, 'and' and 'or'.)
  ((true)  && (true))  -> true
  ((true)  && (false)) -> false
  ((false) && (true))  -> false
  ((false) && (false)) -> false

  ((true)  || (true))  -> true
  ((true)  || (false)) -> true
  ((false) || (true))  -> true
  ((false) || (false)) -> false

  -- (Some alternative syntax.)
  (?x and ?y) -> (?x && ?y)
  (?x or ?y)  -> (?x || ?y)

  -- (Let's build an 'if' statement.)
  (quote ?x)    -> (quote ?x)
  (unwrap (?x)) -> (unwrap ?x)
  (unwrap ?x)   -> ?x
  (
    if ?c
      ?t
    else
      ?f
  ) -> (
    if/else ?c
      quote ?t
      quote ?f
  )
  (
    if/else (true)
      quote ?t
      quote ?f
  ) -> (
    unwrap ?t
  )
  (
    if/else (false)
      quote ?t
      quote ?f
  ) -> (
    unwrap ?f
  )

  -- (All together.)
  if ((true) and ((false) or (true))) (
    Hooray!
  ) else (
    Boo!
  )

Howdy.

I'm Wryl, the original author of this language. I sketched it out in late 2018 and played with it in 2019 after seeing some Mill architecture articles floating around. I mostly created it out of spite, thinking "You don't need fancy designs to do high-level things on bare metal!"

At the time, I called it a term rewriting language, which seem a bit of a weaker label than what it is. It's more like a string rewriting system with variables and nested strings, with parentheses acting as the separators for sub-strings.

It got to the point where I could transcribe Quicksort from the Haskell wiki into a fragment of Modal. I stopped playing with it after I had some not-so-fun industry experiences, and declared my work a dead-end.

Devine from Hundred Rabbits managed to get me to talk about it a bit more, and has taken the language far beyond what I could dream of. It's now gone beyond a sketch to a genuine marvel of engineering which is continually being refined as we figure out more idioms. The language is in very good hands.

I'm of the opinion that rewriting is an unexplored paradigm, and that we don't really understand how to build software. Modal was a product of my research efforts, which are still on-going. I hope to bring more projects like this to light. This has been quite fun.