ivanb

Most if not all the terrorist-related deaths are attributed to The Troubles that ended in - you guessed that - 1998. It is not possible to attribute the deaths or lack thereof to corporal punishment.

Regardless of what side you take, time is the judge. It does not care about what you consider right or wrong. It will show which societies will prosper and which will go extinct.

It would be nice to refactor some of these. Vas deferens and laryngeal nerve look like easy pickings. Leave me my ear-wiggling. Any last bit of expression matters.

I'm dreading the horror of genetic manipulation it would open. The gene editing craze feels like it is right around the corner.

Btw I meant quasi-mutations of course. So every quasi-mutation conses. Alright.

Big-O is one thing. Big constant factor, heap fragmentation and cache locality are other useful characteristics of data structures.

Balancing trade-off is crucial in software design. It would be nice if the documentation listed the trade-offs of the structures compared to their native implementations. I imagine at least every mutation is consing? There are also larger fixed and slow-growing overheads in various operations.

Besides, one can easily code a skill+script for detecting the problem and suggesting fixes. In my anecdotal experience it cuts down the number of times dumber models walk in circle trying to balance parens.

This is fantastic! Godspeed.

It is not easy to tell because lparallel's documentation website has rotted away just the same as cl-user.net. Does anyone remember this beautiful wiki of CL libraries?

Anyway, it looks like lparallel is nice and has some very useful concurrency primitives, but it doesn't have lightweight scheduling, unlike Go. So no cheap async work with many open sockets, cheap context switching, better cache utilisation, simple language constructs and mental model for async tasks. Besides, Go has M:N scheduler. It has all these async benefits but in addition all the threading benefits. Such things can only be properly done by the implementation.

>Yes, but that would be a CL violation

Let's be brave and deviate from the standard, preferably in a backward-compatible way, to provide the best achievable DX.

The CL committee, however smart it was, could not think through all the nooks and crannies of the system. Let's continue where they left off and progress.

The same way threads are different from goroutines, green threads, JS event loop etc.

Coalton is nice but it requires a wrapper around every form you feed a REPL or around the whole file.

If on the other hand SBCL had a more powerful type system or extension points for a pluggable type system...

Hijacking the thread, the JetBrains plugin for Common Lisp had not been maintained since 2023. I forked it and vibed it back to life.

You don't need Emacs. Feel free to enjoy Common Lisp in your regular IDE.

https://github.com/ivanbulanov/SLT/releases

It is probably the best Common Lisp compiler when it comes to type checking. However, it leaves a lot to be desired. For example, it cannot specialize an element type for lists. With lists being the go-to structure, if you attempt to (declaim) every function, you will immediately see how vague and insufficient the types come out compared to even Python.

The ability to specialize list parameter types would greatly improve type checking. It would also help the compiler to optimize lists into unboxed arrays.

Please don't tell me that static type checking doesn't lend itself to CL. The ship has sailed. It does work with SBCL rather well, but it can be better.

Some may blame the Common Lisp standard. It indeed doesn't specify a way for list specialization, but the syntax is extensible, so why not make it as a vendor extension, with a CDR? AFAIK CDR was supposed to be to Common Lisp what PEP is to Python.

I would use vectors and arrays, but in CL ergonomics is strongly on the side of lists. For short structures vectors and arrays don't make sense.

I think it is also a time to outgrow the standard and be more brave with extensions. A lot has changed since the standard. It is still very capable, but as powerful as CL is, some things just cannot be practically implemented in the language and have to be a part of the runtime. Yes, I'm talking about async stuff.

So I got the idea to see how difficult it would be to bolt on async runtime to SBCL. To my surprise the project is hosted on awfully slow SourceForge and project discussions are still happening on mailing lists. Sorry, but I am too corrupted by GitHub's convenience.

That explains why Opus was so dumb yesterday. It walked in circles on tasks it used to one-shot. With these companies and services you never know what product you are actually getting regardless what is said on the tin.

We all can google. Have you tried to install the plugin? It doesn't support the current version of the IDE and as the last commit was 8 months ago there is no hope it will get such a support soon.

One thing this specific feature was letting me do is seeing when Claude Code takes a wrong turn, read a wrong memory MD file. I used to immediately interrupt and correct its course. Now it is more opaque and there is less of a hint at CC's reasoning.

That 500x313 screenshot of the desktop does not help any argument.

It will be mine as well but only because consumer agentic AI became available and good. Only it makes all quirks and hardware incompatibilities bearable. I tell it to investigate the problem and it does an incredible amount of digging to help find the cause and eventually, after several iteration, either fix it or implement a good enough crutch. Even then it takes minutes to hours and I would take months.

What's is the deal with Linux and suspend? It seems only a select few combinations of hardware and software can handle suspend and resume. AMD is commonly praised for their Linux drivers but my all-AMD system crumbles down on power state transitions and especially suspend-resume. I never though words "data", "fabric", "sync" and "flood" can be used together, but now they are a common sight in my logs.

It was so thoughtful of them to use IR tracking. Bed time gaming becomes much easier. I wonder if there was a choice between color passthrough and IR tracking and they chose the latter. Good choice!

The whole area is full of contradictions:

- mechanical keys - reduced movement;

- buy a custom build - have industrial build quality;

- barely any movement - good blood flow;

- avoid rolling - type fast;

- concave keyboards - tenting;

- fewer keys - minimal;

- uniformly shaped keys - touch typing feedback;

- keep hands on the keyboard - move pointer precisely;

- custom layout - conventional shortcuts.

This is ridiculous. I no longer take this field seriously. I get it, we get bored and need a new toy sometimes. Some indeed acquired a medical condition and need medical equipment to type now.

I noticed when I exercise I can sit comfortably on a firm basic stool, and when I don't I become a princess on a pea.

How about we start with the basics? Good posture, correct hand positions, monitor at the right level, exercise, nutrition. Then an IBM Model M would suffice.

One limitation of JSON is its limited set of types. For example, for decimal numbers one has to resort to stringly typing representation because DB connection libraries assume that JSON numbers are floating point. Note that JSON numbers are just sequences of digits, nothing more. There is no attached precision semantic.

Another example is UUIDs. Instead of transferring 16 bytes, the libraries deal with wasteful string representation. I'm sure you can bring another examples.

Nonetheless, for majority of data JSON as DB output format is alright.

Supposedly, Pijul doesn't have the "force-push to trunk" problem. This alone makes it interesting.

I haven't yet given jj a proper trial, so pardon the ignorance. All I've seen are conveniences regarding the working the copy. Besides the subjectively terrible UI, my biggest gripes with Git have to do with collaboration. A rebase may unintentionally overwrite someone's work. A force-push to trunk breaks every other developer's working copy. With "distributed" being in the name of this whole class of VCSes, I would expect that such things just wouldn't happen, but here we are. As I understand it, jj inherits all of these problems and adds better concepts and UI for manipulating the working copy. I'm not sure this alone is a good enough justification for a switch. Of all the Git's features I use a tiny, proven subset and stay on the beaten path. It makes it bearable enough.

In practice e2e tests don't cover all code paths and raise a question: what is the point? There is a code path explosion when going from a unit to an endpoint. A more low-level test can cover all code paths of every small unit, whereas tests at service boundary do not in practice do that. Even if they did, there would be a lot of duplication because different service endpoints would reuse the same units. Thus, I find e2e tests very limited in usability. They can demonstrate that the whole stack works together on a happy path, but that's about it.

I wish manufacturers of ergonomic keyboards would pay more attention to pointing devices. After all, with modern UIs we have to use the pointer. Having a hand jump to a mouse all the time is, at least, distracting.

Another factor is skeletal symmetry. Reaching for a mouse changes the natural balance of posture. I'm not a doctor, but it cannot be healthy over decades. That's why after many years I'm now using the pointing device with my non-dominant hand most of the time. My dominant hand only takes the mouse when I have to do precise or graphic work. This approach makes my back, neck and shoulders feel better.

And the last major gripe I have with most of ergonomic keyboards is how they misunderstand tactile feedback. They try to make all keys feel the same. Glove80 takes it to the limit with its uniform and flat key shapes and identical switches. I don't think this is helpful. Notice how F and J on most keyboards have bumps. Every key should have a bump, a unique shape, a unique surface texture. I want to subconsciously know I hit the right key.

This is the future. Foldable, headless computer-in-keyboard and some glasses. In a sense we are doing a full circle to Commodore 64 form factor.

One overlooked aspect is ergonomics. Laptops are terrible for posture, unlike the poster's HMD setup.

At one point I had a Blackberry Passport and a Pebble. The future looked bright.

My beautiful Pebble Time Steel died of salt water damage, the prior Pebble 2 SE got disintegrated by sunscreen. I have to take ruggedness into consideration.