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

    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

    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)

    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.

Enjoy.

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

Comments URL: https://news.ycombinator.com/item?id=38492324

Points: 4

# Comments: 2

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

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

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

Comments URL: https://news.ycombinator.com/item?id=36640109

Points: 3

# Comments: 0

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

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

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

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

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/