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

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.

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.

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

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

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

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.

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