factorial_recursive <- function(n) {
    if (n == 1) {
      return(n)
    } else {
      return(n * factorial_recursive(n - 1))
    }
  }

then gives:

  (<- factorial_recursive (function as.pairlist(alist(n = )) 
    ("{" (if (== n 1) 
      ("{" (return n)) 
      ("{" (return (* n (factorial_recursive (- n 1))))))
    ) NULL)
  )

https://www.jsoftware.com/

p.s. R is Lisp with a nice syntax. Much more readable and still very powerful.

just my 2 ct

In short: The problem is about whether a solution (of the NS Equations with external driving force) can be found that blows up in finite time. i.e. exhibits infinite velocity at a point even for a viscous flow.

The solution: Take a circular curl ansatz which shrinks in xy-direction and elongates in z-direction and see whether you can find linearized waves so that these waves show a blow up when propagated on the curl. Then prove that the higher orders of the perturbation are regular before the T0 singularity time and you have solved the problem. The external force is just the remainder of the NS-Equation right hand side.

It is a lot of tedious formula juggling of all the higher orders and some singular perturbation expansions. Perfectly suited for algebra systems. OpenAI was using probably python sympy for the formula work and the researchers had to guide the LLM what to do in higher mathematical language.

Here is the paper:

https://cdn.openai.com/pdf/32d9f210-8b73-45e0-91bc-82a30aef8...

when you upload it to chatgpt astra can explain what they do and why it works, have fun.

Can you you give a hello world example in each of them and show where your languages shines?

https://www.fullbucket.de/music/fb3300.html

The PS-3300 is a 3 layer synth with 49 voices where each voice has its own VCO/VCF/VCA. So you end up with 16 voices when you use 3 layers. It has microtunality and a reverb for each of the layers.

Here is a sound demo:

https://soundcloud.com/full-bucket/fr33ze?utm_source=clipboa...

I dont know why apple, samsung and google are not getting it. But I would not even touch one of their products with a 2 feet long pole.

Just my experience and 2 ct.

And one thing: Pebble2 is really really nice, but 200 euro? The Amazfit Bip is (was) 40 euros. Why the price difference?

but you cant ban the math!

the same transformer/attention ideas work great as compressors, function approximators, and surrogate models in physics, chemistry, CFD, etc., where they show up as "PDE‑Transformer", "Neural Operator", or "Hybrid Surrogate Model", and not as "chatbot". ;-)

So even if you outlaw certain AI uses, the core tech will just move into scientific and engineering workflows under different names, where most people won’t recognize it. Would be interesting whether it is possible to write a LLM-like program just using compression and function interpolation algoritms.

just my 2 ct

The (well-known) Sapir–Whorf hypothesis (if dont know it, look it uop) is often invoked for natural languages, but there’s a pretty direct analogue for programming languages: the language you "think in" during solving a problem biases which abstractions and idioms you reach for first.

If you force an LLM to first solve a problem in a highly abstract language (Lisp, APL, Prolog) and only then later translate that solution to C++ or Rust, you’re effectively changing the intermediate representation the model works in. That IR has very different "affordance", e.g.

- Lisp pushes you toward recursive tree/list processing, higher‑order functions and macro‑like decomposition. (some nice web frameworks were initially written in LISP, scheme, etc...)

- APL pushes you toward whole‑array transforms, point‑free pipelines and exploiting data parallelism. (banks are still using it because of perforance)

- Prolog pushes you toward facts/rules, constraint satisfaction, and backtracking search. (it is a very high abstraction but might suit LLMs very well)

OK, and when you then translate that program into C++/Rust/python, a lot of this bias leaks through. You often end up with:

Rule engines, constraint solvers, or table‑driven dispatch code when the starting point was Prolog.

Iterator/functor pipelines and EDSL‑like combinators when the starting point was Lisp.

Data‑parallel kernels and "vectorized" loops when the starting point was APL.

In principle, an LLM could generate those idioms directly in C++/Rust. In practice, however, models are heavily shaped by their training distribution and default prompts. If you just say "write in Rust", they tend to regress towards the most common patterns in the corpus (framework‑heavy, imperative, not very aggressively functional or data‑parallel), even when the language would support richer abstractions.

By inserting a "thinking" step in a different paradigm, you bias the search over solution space before you ever get to Rust/C++. That doesn’t magically make the code better, but it does change which regions of the design space the model explores.

Same would also be true for python which is already a multi-idiomatic language. So it might be a good idea to learn a portfolio of different languages and then try to tackle a problem with a specific language instead of automatically using python/go/rust because of performance.

Something to consider...

p.s. how would a problem be solved when the LLM would have to write it first in erlang? Is it the automatically distributed?

p.p.s. the "design pattern" of the GoF comes automatically to my mind, which might be a good hint to the LLM to use.

Remember, you are the judge whether the code is OK and if you use assembler you might get really performant code, but can you trust it?

Of course it might be a good incentive to learn rust or go. Or challenge yourself to learn something really cool like LISP, COBOL, FORTRAN, APL or J. (just kidding...)

just my 2 ct...

just my 2 ct

https://github.com/sipeed/picoclaw

another chinese coompany m5stack provides local LLMs like Qwen2.5-1.5B running on a local IoT device.

https://shop.m5stack.com/products/m5stack-llm-large-language...

Imagine the possibilities. Soon we will see claw-in-a-box for less than $50.

   import base64
   import hmac
   import struct
   import time

   def totp(key, time_step=30, digits=6, digest='sha1'):
        key = base64.b32decode(key.upper() + '=' \* ((8 - len(key)) % 8))
        counter = struct.pack('>Q', int(time.time() / time_step))
        mac = hmac.new(key, counter, digest).digest()
        offset = mac[-1] & 0x0f
        binary = struct.unpack('>L', mac[offset:offset+4])[0] & 0x7fffffff
        return str(binary)[-digits:].zfill(digits)

Most of the “overhead” and “security nightmare” worries assume the worst possible setup with zero curation and bad ops. That would be messy with any integration method, not only with MCP. Teams that already handle HTTP APIs safely can apply the same basics here: auth, logging, and isolation.

The real value is that MCP stays out of your way. It does not replace your stack, it just gives tools a common shape so different clients and agents can use them. For many people that is exactly what is needed: a thin, optional layer, not another heavy platform.

Mozilla is a strawman for google that they can claim there exists another browser that is not chrome because of antitrust laws. And now that Microsoft forcefeeds win11 user with Edge it will not take long and google doesnt need firefox anymore.

For sure I would give a donation to firefox if they would build a decent browser which listens to the user but not as they do now.

just my 2 ct

In the end AI is a tool that helps everyone to get better but the knowledge and creativity is still in the people not in the input files of chatgpt.