djedr

    Location: Poland
    Remote: yes
    Willing to relocate: no
    Technologies: JavaScript, TypeScript, HTML, CSS, Scala, open to learning something new, e.g. about AI, ML, LLMs
    Résumé/CV: https://djedr.github.io/resume.html
    Portfolio: https://djedr.github.io/projects.html
    Email: darius.j.chuck (gmail)

* https://jevko.org/ -- Jevko (jeff-ko /ˈd͡ʒef.kəʊ/) is a versatile minimal syntax for encoding tree-structured information as human- and machine-friendly text.

* https://xtao.org/last.html -- two extremely minimal programming languages I have created, which are both minimal versions of Alonzo Church’s lambda calculus, inspired by John Tromp’s Binary Lambda Calculus (BLC).

Also looking for research funding, e.g. https://jevko.org/activitypub.html

SEEKING WORK

    Location: Poland
    Remote: yes
    Willing to relocate: no
    Technologies: JavaScript, TypeScript, HTML, CSS, Scala, open to learning something new, e.g. about AI, ML, LLMs
    Résumé/CV: https://djedr.github.io/resume.html
    Portfolio: https://djedr.github.io/projects.html
    Email: darius.j.chuck (gmail)

* https://jevko.org/ -- Jevko (jeff-ko /ˈd͡ʒef.kəʊ/) is a versatile minimal syntax for encoding tree-structured information as human- and machine-friendly text.

* https://xtao.org/last.html -- two extremely minimal programming languages I have created, which are both minimal versions of Alonzo Church’s lambda calculus, inspired by John Tromp’s Binary Lambda Calculus (BLC).

Also looking for research funding, e.g. https://jevko.org/activitypub.html

SEEKING WORK

    Location: Łódź, Poland
    Remote: yes
    Willing to relocate: no
    Technologies: open to learning, most comfortable with JavaScript, TypeScript, HTML, CSS, maybe Scala; details in resume
    Résumé/CV: https://djedr.github.io/resume.html
    Email: darius.j.chuck (gmail)

    Location: Łódź, Poland
    Remote: yes
    Willing to relocate: no
    Technologies: open to learning, most comfortable with JavaScript, TypeScript, HTML, CSS, maybe Scala; details in resume
    Résumé/CV: https://djedr.github.io/resume.html
    Email: darius.j.chuck (gmail)

SEEKING WORK

    Location: Łódź, Poland
    Remote: yes
    Willing to relocate: rather not
    Technologies: open to learning, most comfortable with JavaScript & relateds; details in resume
    Résumé/CV: https://djedr.github.io/resume.html
    Email: darius.j.chuck (gmail)

My goal is to continue that as an independent creator and make a living this way. Looking for things compatible with that goal.

    Location: Łódź, Poland
    Remote: yes
    Willing to relocate: rather not
    Technologies: open to learning, most comfortable with JavaScript & relateds; details in resume
    Résumé/CV: https://djedr.github.io/resume.html
    Email: darius.j.chuck (gmail)

My goal is to continue that as an independent creator -- I'd like to make that my full-time job. Looking for things compatible with that goal.

For any lurkers out there, I just created/published the next, even more extreme iteration of this called λDNA: https://xtao.org/blog/ldna.html

Enjoy.

Made this last year, inspired by @jart's SectorLambda[0] implementation of @tromp's Binary Lambda Calculus[1]. Since then I had an idea of how to translate the language into a 5-instruction "linear" (as opposed to tree-structured) machine code which can be nicely visualized. Finally implemented this idea, resulting in a minimal IDE/debugger. Just published a working version of that[0].

Pretty fun stuff. :D

[0] https://justine.lol/lambda/

[1] https://tromp.github.io/cl/Binary_lambda_calculus.html

[2] https://xtao.org/blog/nukleus.html

offering more evidence for the theory that life on Earth was seeded from outer space.

This hypothesis seems to be getting more and more traction. There is an excellent recent video on topic from Kurzgesagt [0].

Interesting that neither the video nor the article uses the name panspermia[1] to refer to the hypothesis. I wonder why that is. Wikipedia also states that "[the fringe theory] is also criticized because it cannot be tested experimentally". Can't it? If we ever find an organism based on DNA compatible with organisms on Earth, wouldn't that validate it?

[0] https://www.youtube.com/watch?v=JOiGEI9pQBs

[1] https://en.wikipedia.org/wiki/Panspermia

fitzJSON: a JSON-compatible format optimized for configuration.

https://github.com/xtao-org/fitzjson

Another revelation: lambda calculus can be reduced down to 4 primitive operations[0].

I had this revelation after a pilgrimage into the land of Binary Lambda Calculus[1], a binary encoding of lambda calculus that represents variables with numerical (de Bruijn) indices[2] in unary.

Ultimately, 0 and 1 is all we need. ;)

[0] https://jevko.github.io/writing/2023-07-23-revelation.html -- the pun in the article (I'm the author) fits perfectly into the OP ;D

[1] https://tromp.github.io/cl/Binary_lambda_calculus.html

[2] https://en.wikipedia.org/wiki/De_Bruijn_index

Thanks! :)

https://djedr.github.io/writing.html and https://xtao.org/blog.html

Mostly technical writing about programming [languages] and my projects.

Most popular posts:

* Introducing Jevko: a minimal general-purpose syntax / https://djedr.github.io/posts/jevko-2022-02-22.html / hit on the front page of HN / about a little project I've been working on for years

* Why NOT to add the pipeline operator to JavaScript / https://djedr.github.io/posts/random-2018-01-25.html / I guess this was controversial

And for looser writing/drafts: https://github.com/jevko/writing

Enjoy!

I suppose a bit of both.

I was more directly inspired by Lisps, but I do prefer the original M-expressions and the syntactic choices that REBOL and Red make.

I think placing the operator before the opening bracket better emphasizes its special significance and can reduce nesting for constructs like `f[x][y]` (vs. `((f x) y)` in Lisps). Square brackets somehow seem more aesthetically pleasing to me. And there is a practical reason to prefer them, especially if your syntax uses only one kind of brackets -- square brackets are the easiest to type on an average keyboard.

So REBOL-like syntax is nicer. As were M-expressions. They probably didn't catch on, because they were not minimal enough, compared to S-expressions. And maybe because S-expressions were fully implemented first.

This is one thing I designed Jevko[0][1] for.

If you have an idea for a format or a language and would like to quickly start hacking on the layer above the syntax, Jevko is an option.

It's meant to be even simpler and hackable than S-expressions.

It gets you from a string to a tree in the least amount of steps.

See here[2] if interested.

Happy hacking!

[0] https://jevko.org/ [1] https://djedr.github.io/posts/jevko-2022-02-22.html [2] https://gist.github.com/djedr/151241f1a9a5bc627059dd9b23fc74...

What if we could have minimal redundancy and still be capable of error detection?

Check this[0] out:

    [
        id [0003]
        type [donut]
        name [Old Fashioned]
        ppu [0.55]
        batters [
            batter [
                [
                    id [1001]
                    type [Regular]
                ]
            ]
        ]
        topping [
            [
                id [5004]
                type [Maple]
            ]
        ]
    ]

For a bit more error-checking-thru-redundancy we could analyze indentation (one reason why I recommend C-style rather than Lisp-style formatting) and warn if we detect any inconsistencies.

Ergo: through design magic we can get rid of a lot of the redundancy and increase desirable properties, without trading off much of the positive side.

NB for a machine we could compact the above into:

    [id[0003]type[donut]name[Old Fashioned]ppu[0.55]batters[batter[[id[1001]type[Regular]]]]topping[[id[5004]type[Maple]]]]

As long as we are on topic of JSON alternatives suitable for configuration, I've been tinkering with various minimal syntaxes and formats for a long time, most notably Jevko[0].

One format based on that I've been conjuring up recently would represent the first example from the RON README like so:

    GameConfig[ optional struct name
        window size [[800] [600]]
        window title [PAC-MAN]
        fullscreen [false]

        mouse sensitivity [1.4]
        key bindings [
            up [Up]
            down [Down]
            left [Left]
            right [Right]
            
            Uncomment to enable WASD controls
            ;[
            W [Up]
            A [Down]
            S [Left]
            D [Right]
            ]
        ]
        
        difficulty options [
            start difficulty [Easy]
            adaptive [false]
        ]
    ]

I wonder what you guys think about such a minimal alternative.

[0] https://jevko.org

[1] https://gist.github.com/djedr/4eeac1de466512ec211ff17cfd1f5e...

With XML, the complexity is the baseline, and it only goes up from there. With JSON, the complexity is just an option, the baseline is pretty simple.

Very well put. And we could lower the baseline substantially towards simplicity, even from JSON.

It's pretty clear that a lot of people think this way. Some even seriously try to figure out what such a baseline of simplicity would look like.

There are lots of simple indentation-based designs (similar to YAML) such as NestedText[0], Tree Notation[1], StrictYAML[2], or even @Kuyawa's Dixy[3] linked in this thread.

There seem to be less new ideas based around nested brackets, the way S-expressions are. Over the years, I have developed a few in this space, most notably Jevko[4]. If there ever will be another lowering of the simplicity baseline, I believe something like Jevko is the most sensible next step.

[0] https://nestedtext.org/en/stable/ [1] https://treenotation.org/ [2] https://hitchdev.com/strictyaml/ [3] https://news.ycombinator.com/item?id=35469643 [4] https://jevko.org/

I replied in Markdown here: https://gist.github.com/djedr/4ae1373faa7d43f359a2a245132341...

Hey, just want to say that BLC is a remarkable artifact -- to me it's an art piece in computational minimalism.

I actually got so obsessed with it last year that I worked out a variant of lambda calculus[0] in which, with some trickery, a port of the BLC interpreter could be squeezed into 194 bits.

Which would be only 2 bits more than the intriguing conjecture from your paper[0] says to be optimal:

We conjecture that any self-interpreter for any binary representation of lambda calculus must be at least 24 bytes in size, which would make E close to optimal.

I wonder what are the assumptions behind this conjecture. Surely my trickery broke some of them.

[0] https://xtao.org/blog/last-intro.html

[1] https://tromp.github.io/cl/LC.pdf

The article mentions SICP aka the wizard book. In it, there are a lot of metaphors pertaining to magic and spirits, which IMO makes the book much better than if they weren't there. One of the authors of the book, Hal Abelson, famously said:

There's a good part of Computer Science that's like magic. Unfortunately there's a bad part of Computer Science that's like religion.

This points to perhaps a useful distinction that is to be made here between religion (as in tribalism which leads to holy wars) and mysticism/spirituality/magic (as in deep fascination in search of ultimate truth).

Yes, in Elm or Lisp this would be problematic.

In this syntax though it isn't. Anything between brackets like this:

  [foo bar baz]

In this syntax whitespace is not a separator.

So you can store a single piece of text in such a simple tree.

Now if you want to have 3 pieces of text you do this:

  [foo][bar][baz]

If you want to have 3 of these you do this:

  [[foo][bar][baz]]
  [[foo][bar][baz]]
  [[foo][bar][baz]]

There are no implicit commas or anything.

Each subtree is also potentially a name-value pair. If you insert names before the opening brackets:

  [x [foo] y [bar] z [baz]]

The names themselves are also pieces of text (whitespace is not a separator), so you can have names like:

  [my x [foo] your y [bar] their z [baz]]

Now to turn trees like this into something useful, for example XML/SVG, you'd do a little bit of processing on them, e.g. you could transform the names like so:

  my x [foo] your y [bar] their z [baz]

  <myX>foo</myX><yourY>bar</yourY><theirZ>bar</theirZ>

  svg [x=[0px] y=[0px] view box=[0 0 21 21] path [
    fill=[#FFF] stroke=[#146AFF] stroke width=[2] d=[M11.1,1.4l2.4,...]
  ]]

  <svg x="0px" y="0px" viewBox="0 0 21 21"><path
    fill="#FFF" stroke="#146AFF" strokeWidth="2" d="M11.1,1.4l2.4,..."
  ></path></svg>

I have used the same convention here (except I don't bother with transforming names with spaces into camelCase): https://github.com/jevko/specifications/blob/master/easyjevk... to generate this HTML file: https://htmlpreview.github.io/?https://github.com/jevko/spec...

Now I intend to write specifications that codify conventions like this into different formats based on this fundamental syntax of square brackets.

It can be useful for all kinds of things. Its advantage is extreme simplicity and flexibility.

BTW, for clarity I have to say that the format that I used here: https://news.ycombinator.com/item?id=32995047 does a bit more transformations -- it actually sometimes treats whitespace as a separator (e.g. in `svg width[391]` space is a separator). That allows for extreme conciseness, but is not necessary and introduces complexity.

Precisely, or even find a way not to require commas.

Here it is: https://news.ycombinator.com/item?id=33457176

The only solution to this war is no commas!

To roughly translate the first example in the article (I shortened the value of `d`):

  svg [ 
    x=[0px]
    y=[0px]
    viewBox=[0 0 21 21]

    path [
      fill=[#FFF]
      stroke=[#146AFF]
      strokeWidth=[2]
      d=[M11.1,1.4l2.4,...]
    ]
  ]

It's a perfectly viable lightweight syntax for SVG.

See also https://news.ycombinator.com/item?id=32995047

A plain Jevko parser simply turns your unicode sequence into a tree which has its fragments as leaves/labels.

No data types on that level, much like in XML.

Now above that level there is several ways to differentiate between them.

The simplest pragmatic way is a kind of type inference: if a text parses as a number, it's a number, if it's "true" or "false", it's a boolean. Otherwise it's a string. If you know the implicit schema of your data then this will be sufficient to get the job done.

Otherwise you employ a separate schema -- JC in particular has per-parser schemas anyway, so that's covered in this case. If it wouldn't, you'd need to write a schema yourself.

Or you do "syntax-driven" data types, similar to JSON, e.g. strings start w/ "'".

Here is a shitty demo: https://jevko.github.io/interjevko.bundle.html

It shows schema inference from JSON and the schemaless (syntax-driven) flavor.

Jevko itself is stable and formally specified: https://github.com/jevko/specifications/blob/master/spec-sta...

It's very easy to write a parser in any language (I've written one in several) and from there start using it.

However, I am still very much working on specifications for formats above Jevko. I have some recent implementations of the simplest possible format which converts Jevko to arrays/objects/strings:

* https://github.com/jevko/easyjevko.lua

* https://github.com/jevko/easyjevko.js

The schema-driven format that was used in the demo is implemented here:

* https://github.com/jevko/interjevko.js

* https://github.com/jevko/jevkoschema.js

Dare I suggest Jevko[0] as yet another alternative?

  eth0 [
    ip [127.15.34.23]
    flags [[BROADCAST][UNICAST]]
    mtu [1500]
    name ["Gigabit" by Network Interfaces Inc.]
  ]

It's even simpler and more flexible than S-expressions.

Handles deeply nested structures perfectly well. Has only 3 characters to escape (brackets and the escape character).

(I am the author)

[0] https://jevko.org/

That's more like it!

Indeed, markup languages are built around text whereas in JSON/S-expressions/syntaxes designed for expressing data, text is secondary.

The syntax I created is uniquely flexible in that it can be used for both data and markup.

The first variant of the two in my original comment is more data-like, but minimal enough that it works sufficiently well as markup too. Text is a little harder to mark up in this variant than in HTML, as individual text nodes have to be wrapped in []. However this gives precise control over the content of the text nodes and separates indentation and other whitespace of the document tree from whitespace which is intended as actual content:

    [paragraph with a ]
    a [
      href=[...]
      [link]
    ]

    paragraph with a [href[...] a][link]

So we have something simpler and more flexible than both HTML and S-expressions. This is the beauty and value of it.

I hope I can succeed in communicating this to potential users, so they can benefit from it.

Location: Poland

Remote: Ok

Willing to relocate: Maybe

Technologies: would love to learn something new, something exotic would be interesting; recent experience in TypeScript, JavaScript (React + Redux) on the frontend, Scala (Spring, Akka, Play), Java on the backend

Résumé/CV: https://djedr.github.io/resume.html

Email: darius.j.chuck (gmail)

Software engineer with full-stack experience.

Dabbling in minimal syntax, programming language design. Notable original project: Jevko[0] -- a minimal, general-purpose syntax.

Would love to work on something connected to free and open-source software, research, especially programming language R&D. Would love something stable, interesting, that pays the bills, and allows me to freely work on my projects.

My adventures in reverse-chronological order: doing independent original work on my own, before that explored my entrepreneurial impulse, before that tried my luck at a startup working remotely on a productivity app, experiencing turbulence, before that worked part remote part onsite for a nice location technology corporation, and some more corporations onsite before that, one doing outsourcing for the automotive industry, one R&D for healthcare.

My interests include syntax, data formats, structured communication, functional programming languages, web applications and frameworks, and interactive applications, such as simulations or computer games. I am open to exploring new areas, especially at the intersection of art, science, and spirit, such as the AI/machine learning space.

[0] https://jevko.org | recently on the front page of HN: https://news.ycombinator.com/item?id=33287620 | see also https://xtao.org for related writing and djedr.github.io -- my home page

Yes, this is probably the most sensible approach.

Other options would be to ignore everything you don't recognize or ignore all nodes of the form:

  unrecognized tag [value]

You could still display stuff like:

  unrecognized tag [
    [text]
    ...
  ]

But approaches like these would need a good justification.

The element/attribute distinction is because HTML is a markup language, where the primary content is text and markup is used to add structure and metadata.

That may have been the idea, but it falls apart in implementation. Lines between content and metadata get blurred.

Consider attributes like: input/value, input/placeholder, optgroup/label, img/alt, title.

And then elements like: script, colgroup, col, title, noscript, noframes, applet, object, the void elements[0].

Then consider the ability of CSS to add content to elements, including lifting it from attributes[1], and, on the other side, completely hiding element contents.

The line between metadata and data is conventional. It's all data in the end.

But let's suppose it isn't and there is a hard line. Why should the metadata in attributes not be allowed to have structure and be extensible in the same way data is?

You can eliminate attributes to get a simpler format, but it isn't really a markup language anymore, since the distinction between text and markup is removed. It is just a generic data structure, like JSON or s-expressions.

What I'm saying is that HTML-like attributes are not necessary to keep the distinction. You can keep the functionality, simplify things and at the same time make them more flexible.

HTML-like attributes also don't stop people from using the language to describe generic data structures (XML).

On the other side, if JSON or S-expressions had syntax and semantics that made them suitable as markup languages, I don't see a problem with that.

[0] https://developer.mozilla.org/en-US/docs/Glossary/Void_eleme...

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/attr