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)

4+ years of professional experience, last 3+ years independently exploring original ideas, e.g.:

* 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)

4+ years of professional experience, last 3+ years independently exploring original ideas, e.g.:

* 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)

Programming since 2004, Master of Engineering in Computer Science, 4+ years of professional experience, last 3+ years exploring original ideas, e.g. https://xtao.org/ | https://jevko.org/ | https://xtao.org/last.html

    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)

Programming since 2004, Master of Engineering in Computer Science, 4+ years of professional experience, last 3+ years exploring original ideas, e.g. https://xtao.org/ | https://jevko.org/ | https://xtao.org/last.html

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)

Programming since 2004, Master of Engineering in Computer Science, 4+ years of professional experience, last 3+ years exploring original ideas: https://xtao.org/ | https://jevko.org/ | https://xtao.org/last.html

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)

Programming since 2004, Master of Engineering in Computer Science, 4+ years of professional experience, last 3+ years exploring original ideas: https://xtao.org/ | https://jevko.org/ | https://xtao.org/last.html

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...

Edit: actually, the issue you mention does not occur in EDN. If you put an odd number of elements in a map, you'll get an error. So that's another error-checking mechanism. My comment below was written before I realized this. Still, it remains relevant, as it shows how a format can be designed with minimal redundancy without sacrificing the goods.

***

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]
            ]
        ]
    ]

Now if we delete `id` we will get a syntax error. And yet no commas, no colons, no quotemarks! Only square brackets. Minimal redundancy.

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]]]]

[0] More on that here: https://news.ycombinator.com/item?id=35675811

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 put a syntax-highlighted version and some more details in this gist[1].

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]

that does not contain any nested brackets is a simple tree which contains "foo bar baz" as its sole value (called a suffix).

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]

3 simple trees together -- they are subtrees of a top-level tree.

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

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

The linebreaks don't change the tree structure, they are inserted purely for readability.

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]]

You have 3 pairs.

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]]

Still 3 pairs.

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]

into:

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

in this manner you could transform:

  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,...]
  ]]

into:

  <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>

Notice that here I used a convention where names which end with "=" become XML attributes, whereas names which don't become children.

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,...]
    ]
  ]

You can remove all whitespace and it's still unambiguous.

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.]
  ]

This is one of the things it was designed with in mind.

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.

Note that 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]
    ]

The second variant is very much like HTML: text here is primary and interleaved with markup in []:

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

This variant also separates the attributes and tag from the children, much like HTML. However the attributes are technically not restricted to being flat strings. If we weren't translating to HTML, we could have attributes with tree structure.

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