From my experience Claude Code is not that bad with Common Lisp and can do REPL-style development. I've been using this MCP server (an older version with some tweaks): https://github.com/cl-ai-project/cl-mcp
(even though I'd probably prefer some MCP-to-swank adapter if it existed)
And this MCP server works quite well for Emacs
https://github.com/rhblind/emacs-mcp-server
There are some issues of course. Sometimes, Claude Code gets into "parenthesis counting loop" which is somewhat hilarious, but luckily this doesn't really happen too often for me. In the worst case I fix the problematic fragment myself and then let it continue. But overall I'd say Claude Code is not bad at all with Lisps
Helm is an abomination, as the whole idea of using a text template engine to generate YAML is. And this vulnerability adds insult to injury ;)
Sorry, just can't really recover from trauma of counting spaces and messing up newlines, etc. when writing Helm templates. You know, Lisp "sucks" because "you need to count parenthesis" (you actually don't), yet Helm is a widely accepted technology where you need to count spaces for (n)indent ;)
I used OpenMPTCPRouter to aggregate 3 LTE connections (via routers connected to directional antenna, with SIM cards from different operators) when I was living in a house in the woods before the war has started I had to leave Russia.
Worked like a charm, giving me up to 180 Mbps or so. May not be that good for aggregating different types of links together, but for using multiple cellular connections it's nearly a perfect solution.
BTW 5G 3GPP specs include MPTCP support, IIRC for aggregating connections going via different gNodeBs (base stations)
Common Lisp has CLOS (Common Lisp Object System), which is quite sophisticated object system with metaobject protocol and multiple dispatch, as a part of its spec. Not that it's smth people need to invent on their own each time
Others mention autonomous mode thing being overhyped somewhat.
But besides, that starts to remind me of home automation in Ray Bradbury's "There Will Come Soft Rains"... There was also a Soviet animation film based on that short story https://www.youtube.com/watch?v=5LNHYz89sNc
Yep. Many complain that with Lisp, you need to count parentheses (spoiler: you don't need to). And then proceed to count spaces for indent/nindent in the charts... That's somehow ok with almost everyone
I grew up in Russia, and ES-1841 was my first computer, too.
Also with a printer, yet no HD.
That was 1990 and I was 10 y.o... Once printed a caricature of one of school bullies using (a Soviet clone of) Turbo Pascal and its turtle graphics facility, resulting in a fight.
My favorite pastime was writing DOS viruses in asm, though... I didn't spread them, just wrote some for fun.
Found some of my virus code written down a couple of years ago https://pbs.twimg.com/media/E-jP39nXEAAve0O?format=jpg&name=...
I find this syntax argument a bit strange nowadays.
There's this extremely popular Kubernetes tool called Helm, which uses go-templated YAML to generate Kubernetes resources.
The template syntax is nothing short of horrible. An endless maze of {{ ... }}s, where it's just too easy to shoot oneself in the foot by using {{- or -}} in wrong place, etc. And on top of that, you literally need to count spaces for nindent (mind you, you don't need to count parentheses while writing Lisp code).
I'd say Lisp syntax is clear as day when compared to your average Helm template.
This company literally makes 1984 possible in Russia, being of tremendous help to the Putin's effort to stifle any internal dissent [1]. Yet the company itself is Cyprus-based [2] and also their employees advertise their involvement with Russian surveillance tech on LinkedIn [3] as if it's some perfectly normal IT activity. Can be something done about it?
BTW they're about to impose (almost) total ban on crypto in Russia exactly b/c of FSB complaints that it's being used to fund the opposition, such as Navalny's followers
Somewhat related: if you're using Common Lisp, and SBCL in particular, please consider sponsoring Stas Boukarev, who is an important SBCL contributor
https://www.patreon.com/stassats
JS is here to stay regardless of the sponsorships, but lispers are few and far between ;)
I did write some DOS viruses back when I was a kid, including a "stealth" one (invisible when reading the infected files via int 21h) and another one polymorphic (encrypted with dynamically generated decoder). I've never spread them, although I did upload another simpler one to an antivirus vendor BBS as a "new virus", so now it's known as "Areopag-480" and such. I thought all of the sources of things I wrote back then were lost when I typed an extra space in "rm -rf ~/something" back around 2000, but recently, while looking through some old books, I've found a piece of code of the stealth virus I wrote around 1992-1993: https://twitter.com/ivan4th/status/1434625057553330178/photo... I didn't have a PC at my grandparents' dacha back then, so I was writing code on paper instead during the summer
Posted a detailed explanation slightly above... Glorytun will not work to well with TCP b/c it doesn't provide separate congestion control for each path like MPTCP does.
OpenMPTCPRouter uses shadowsocks [1] and its ss-redir as a kind of a transparent TCP proxy. The advantage of shadowsocks is that it creates separate outgoing TCP connection for each one it proxies, resulting in substantially better performance than SOCKS. And, of course, shadowsocks has MPTCP[2] support.
The problem OpenMPTCPRouter solves is this: you do
(just a single TCP flow) with 3x50Mbps LTE links, or, better, 80Gbps+40Gbps+30Gbps links and you get a bit less than 150Mbps download speed.
LACP doesn't solve it at all for several reasons.
1) LACP assigns each flow to a single network interface so as to avoid packet reordering
2) Even if you use other bonding mode that can spread the flows over several network interfaces, you'll get low throughput due to the aforementioned reordering and also due to the congestion control, more on that below.
Bonding works well when you have several "equal" links, which is not the case with LTE, where the speed may be quite different across the links and also vary with time.
Last but far from least, there is congestion control mechanism which is present both in QUIC and (MP)TCP, which makes sure the transfer is as fast as possible without harming other connections on the same link(s). This mechanism as it is used in QUIC and plain TCP is not very good at handling multiple aggregated unequal links, so no matter which way you do the aggregation on L2 (bonding) or L3 (things like glorytun), the performance is going to be suboptimal.
What MPTCP does is establishing a separate subflow (think TCP subconnection) for each of the available paths, with its own separate congestion control, and spreading the main flow over multiple subflows byte-by-byte in an optimal way. This gives maximum possible utilization of all of the available links, and prevents the congestion in an optimal way, too.
Sorry for incorrect wording. I don't need multipath to be present in the same spec as the QUIC core. What I meant is when I will be able to have slightly less then 150Mbps over QUIC for e.g. a single file if I have 3x50Mbps connections. MPTCP can do that for me, even if the server doesn't support it as I can use something like OpenMPTCPRouter [1]. I hope multipath QUIC will be able to do that too, but it's not ready for production use yet, if I understand correctly.
I use OpenMPTCPRouter [1]. It's a bit of kitchen sink so I'm thinking of replacing it with something simpler, but the basic idea is that you have a TCP->MPTCP converter running on your router and MPTCP->TCP converter running on some cloud instance.
There are some issues of course. Sometimes, Claude Code gets into "parenthesis counting loop" which is somewhat hilarious, but luckily this doesn't really happen too often for me. In the worst case I fix the problematic fragment myself and then let it continue. But overall I'd say Claude Code is not bad at all with Lisps