jaen

That site/app doesn't have a single piece of information about who's running it, what the privacy policy is (besides some AI slop in the FAQ section) etc. etc. - and you're supposed to put business-critical information into it (according to its demo)?!

Why are you recommending something so sketchy?

Those TFLOPS numbers are quite useless as they are "marketing peak TFLOPS". There's usually a 10-100× difference between that and actual computational capabilities in meaningful general workloads.

It only makes sense to compare specific, well-calibrated benchmarks, such as Linpack, which is what I did.

What is this based on? Where did the content come from? It looks quite LLM-generated TBH.

Not quite, the Earth Simulator in 2003 had 35.86 Linpack TFLOPS, 10TB of RAM and 700TB of disk.

That's still almost three orders of magnitude from the iPhone 12 (0.02 Linpack TFLOPS, 4GB RAM, 256GB storage).

That's assuming every developer can get the same AI efficiency boost and contribute meaningfully to any feature, which is unfortunately not really the case.

Seniors can adjust, but eg. junior frontend-only devs might be doomed in both situations, as they might not be able to contribute enough to business-critical features to justify their costs and most frontend-related tasks will be taken over by the "10x" seniors.

No, it's not, that links to a different page, this is a blog post.

HTML+JavaScript-based statically hostable apps (eg. presentations) can't use paths as deep links, since there's no standard for simple static hosting or URL rewriting (even 30 years later). Oh well.

Was fun and kind of meditative locking in like that – I noticed that the anti-glare coating on my screen introduces a visibly larger Δ than the later stages of the game (kind of a dithered "cloud" noise), making it quite a challenge. 0.0021 oneshot.

That didn't answer or reply to the original question... Security is orthogonal to performance.

My question was, how is the performance better? (as implied by the word evaluations)

(also the original post was about exposing all sorts of random ops via a file system which are accessed via general shell tools most of the time, so pretty likely there's basically zero added security...)

(I'm not upset at all, I'm confused.)

Lovely bag of tricks. Abstractly, representing differences seems to make a lot of problems easier / more general.

For more weird stuff, see eg. regular expression derivatives, differential dataflow.

That does require designing the language grammar in a certain way, in particular, there should not be any optional elements in any productions used by statements on the right-hand side (otherwise it's ambiguous whether to terminate the statement or continue to the next line) that can also start a statement. Most languages violate that.

"where the context indicates that a command or definition cannot terminate at that point" is trivially unsuitable for C-like languages, `if`-`else` already violates that, since an `if` can terminate before the `else` by that definition (imagine splitting `else` to a new line).

An actually workable definition would be "unless the end of line occurs at a point where the current expression can not be terminated or the next tokens are not parseable as a separate statement", which is almost the definition of semicolon insertion in JavaScript....

But JavaScript has exactly the problem of the ambiguity since both braces (via object literals) and parentheses (via expressions-as-statements) can start a statement and those are ambiguous with eg. blocks and function calls, respectively.

Actually no, there's no "ROM", that's just the name for the code that gets loaded into RAM. Even the article talked about self-modifying code...

It's a Von Neumann machine with no instruction cache coherence instructions. JITs for these are not trivial to produce due to every memory store potentially invalidating the JIT code, so you need clever solutions to make that invalidation extremely fast.

TypeScript has row polymorphism at home.

Grandparent is an LLM/agent, so what can you expect... sigh.

People building these Rube Goldberg contraptions: Do you actually run evaluations if this is any better at all than eg. giving it access to a Python REPL, or just toughing it out with random tools composed via shell scripts?

Why would an LLM be better trained to access Redis via a FS vs. a native library API?

Makes no sense.

What's the physics solver used here? This demonstration quickly runs into common problems associated with overly simplistic solvers/integrators where everything starts to become unstable and "vibrate" / "twitch".

That's just making things harder to write by disabling useful features.

Always using `select`s can actually be MORE inefficient than using predictable branches, as for a select both sides of the conditional must be evaluated, while for non-divergent "warps", masking+branching skips the instructions entirely.

It's not hard to learn that `if` has a performance cost depending on its divergence (every GPU programmer already knows that) - sure, it's harder to quantify, but it can be strictly better than select, so this is actually inviting inefficiency in certain workloads.

The page literally says it's not written in C, instead a memory-managed compiled dialect of PHP called Zephir...

Cool, although more ILP (instruction-level parallelism) might not necessarily be better on a modern GPU, which doesn't have much ILP, if any (instead it uses those resources to execute several threads in parallel).

That might explain why the original Cg (a GPU programming language) code did not use Estrin's, since at least the code in the post does add 1 extra op (squaring `abs_x`).

(AMD GPUs used to use VLIW (very long instruction word) which is "static" ILP).

For similar languages / compilers in this area:

1. ISPC [1], the Intel® Implicit SPMD Program Compiler also compiles SIMD programs with branches and other control flow efficiently using predication/masking etc.

2. Futhark [2] compiles nice-looking functional programs into efficent parallel GPU/CPU code.

[1]: https://github.com/ispc/ispc [2]: https://futhark-lang.org/

The article already addresses that...

It's not easy and the major compositors (Gnome, KDE) are NOT wlroots based, making this point mostly moot anyway.

This protocol at least has a chance of using a custom WM with an advanced compositor (which wlroots is not).

Personally, I find the "fade-in" animations quite distracting, since I read/think faster than the animations reveal information, so it constantly "interrupts"/"stutters" my thought process.

Animations are usually "serial", while (my) thought is usually "fractal"/"parallel", ie. I quickly take in the entire content, and then start focusing on individual parts according to intuitive salience (or other features).

Instead of animations, visual hierarchy / typography etc. is used by professional designers to convey eg. appropriate reading order.

Yes, "just", mind the context. Are you trying to imply that learning/using an advanced programming language is somehow more complicated than infinite XML slop engineering, which as I said ideally requires knowledge of the same concepts anyway?

Syntactic complexity of natural language is basically solved by LLMs (ie. given an unambiguous natural language statement, it can be translated to any formal language syntax with 99% success), so just wrapping mathematical operators around natural language concepts basically achieves nothing.

The problem is semantic ambiguity, ie. which sense of a noun/verb (concept/operator/function/relation) is meant. The concepts inside the syntax in the paper are still ambiguous.

Also underspecification in general - having a formal syntax does nothing to address this. Both formal and natural language specifications can and commonly are incomplete.

Don't see anything in this proposal to address that. (and any solution probably applies to natural language syntax as well)

The only problem with (formal) natural language syntax these days is that it's a bit too verbose and harder to read (ironically) compared to more math-y/codey ones.

Or... you could just use a programming language that looks good and has great support for embedded domain-specific languages (eDSL), like Haskell, OCaml or Scala.

Or, y'know, use the language you have (JavaScript) properly, eg. add a `sum` abstraction instead of `.reduce((acc, val) => { return acc+val }, 0)`.

In particular, the problem of "all the calculations are blocked for a single user input" is solved by eg. applicatives or arrows (these are fairly trivial abstract algebraic concepts, but foreign to most programmers), which have syntactic support in the abovementioned languages.

(Of course, avoid the temptation to overcomplicate it with too abstract functional programming concepts.)

If you write an XML DSL:

1. You have to solve the problem of "what parts can I parallelize and evaluate independently" anyway. Except in this case, that problem has been solved a long time ago by functional programming / abstract algebra / category-theoretic concepts.

2. It looks ugly (IMHO).

3. You are inventing an entirely new vocabulary unreadable to fellow programmers.

4. You will very likely run into Greenspun's tenth rule if the domain is non-trivial.

I really wish people would read the article, the library does exactly this:

> Okmain downsamples the image by a power of two until the total number of pixels is below 250,000.

I've had success in the past in customizing macOS key bindings using Karabiner: https://karabiner-elements.pqrs.org/

The page literally credits "Open English Wordnet" (based on it) in the sidebar :)

(the link is broken though, it should be https://github.com/globalwordnet/english-wordnet)

Single testcase benchmark, no citations, inventing nonsense terms for trivial concepts like "Synaptic Plasticity", LLM-slop style writing.

Nobody in their right mind would publish this to ArXiv. I suggest looking up and reading guides on how to write a research paper.