Our perception of these things (for most, not all) is incredibly fluid, much like our perception of time. Music that moves us tends to have the right "technical imperfections". Too much and it comes off as amateur, too little, and it comes off as sterile.

Even on a production-level, the right amount of harmonic distortion/non-linearity can be a huge benefit to how sounds are perceived. The amount of soft-saturation tooling in modern electronic/in-the-box music production is wild. Almost every modern plugin seems to include some kind of "warmth" control now.

Yet another example how perfect reproduction doesn't sound quite right.

It was the workstation on which I learned Logic Audio before, you know, Apple bought Emagic. I took that machine, running very low latency Reason to live gigs with my band.

Carting around a full-tower computer (not to mention the large CRT monitor we needed) next to a bunch of tube Fender & Ampeg amps was wild at the time. Finding a good drummer was hard; we turned that challenge into a lot of fun programming rhythm sections we could jam to, and control in real-time, live.

Just over a year ago I decided to switch to Neovim. The reason for switching was personal; I was struggling with what I'll call "clutter" in other tools and I wanted a tool that would reinforce, at least lightly, a mode of working that promoted focus on what I was working on, while making it easy to reference other files without loading up my editor with tabs and other visual clutter (buttons/menus) I don't care about most of the time.

I took the advice I seemed to bump into repeatedly: try out vim mode in my current editor before making the plunge.

I really struggled at first. It felt wildly foreign. All the shortcuts were nowhere near to the world I was familiar with.

As I was about to give up, I ran into some advice that was along the lines of "stop trying to memorize shortcuts and start thinking in terms of what you want to achieve" (words and motions in vim-speak).

Your example of [C]hange [I]nner is a great one; that one in particular was life changing. Sure there are some words and motions that do require memorization, but so many others just flow naturally. And once you start thinking in actions, it's easy to see how they can layer on top of each other in really elegant ways.

I'm not even here trying to tout vim-like editors, I'd wager there are many editors that have some semblance of this kind of interaction, but rather to reiterate there's a shift from a PoV of function vs. goal.

Again, I don't think this is "the right way" but rather one of many perspectives that works in context with the phenomenology of me.

- Did someone really make a VC-backed "Rent-a-swag"?

- Did they also go full Saperstein?

Yep. They did.

Over the last few iterations of Sonnet and Opus, anthropic has definitely trained me to ask it to explain something "in detail" (or even "in great detail") when I want as much nuance as possible.

It used to be the inverse - way too much detail when I didn't want it.

I recently had to interact with an idiot wearing meta glasses. There should be a mandatory consent requirement AND an "on air" red led.

- "Ah, great taste my friend."

- "Ah, great pick to start with."

- "Ah, a lovely choice..."

You're absolutely right! But I don't need you to tell me that. ;)

This looks like a really neat project/idea; seeing the road map is exciting too, nearly everything I'd want.

I don't love the brackets syntax, or the [op val1 val2] ([* x x]) style, but I appreciate the attempt at clarity and consistency and none of these things are dealbreakers.

I do wonder why they've leaned so hard into talking about the type system being out of sight. Again, not a dealbreaker, but I feel strongly that explicit typing has a place in codebases beyond "describe something because you have to".

Strongly typed languages strike me as providing detailed hints throughout the codebase about what "shape" I need my data in or what shape of data I'm dealing with (without needing to lean on an LSP). I find it makes things very readable, almost self-documenting when done right.

From their docs about their choices: "The reasoning is simple: types exist to help the compiler catch your mistakes. They do not exist to help you express intent, at least not primarily." This strikes me as unnecessarily pedantic; as someone reading more code than I write (even my own), seeing a type distinctly—particular as part of a function signature—helps me understand (or add strong context) to the original author's goal before I even get to reading the implementation.

I find this doubly so when working through monadic types where I may get a typed error, a value, and have it all wrapped in an async promise of some kind (or perhaps an effect or two).

By the same token many languages allow you to leave out type annotations where they may be simple or clearly implied (and/or inferred by the compiler), so again, I'm not understanding the PoV (or need) for these claims. Perhaps Loon simply does it better? Am I missing something? Can I write return types to stub functions?

From the above blog post: "That's how good type inference feels! You write code. The types are just there. Because the language can see where it's going." Again, it feels strongly geared towards a world where we value writing code over reading/maintaining/understanding code, but maybe that's just my own bias/limitations.

Will follow it closely.

I recently switched to a split columnar layout but not for solely for ergonomics sake - I do the same things as you but with my right hand handling b, g, t, and my left hand moving over to accommodate (with "incorrect" fingering for c, and variable fingering for the whole of the left side).

My choice to move to a split was primarily motivated by a need to reset my typing style and a hatred for where the escape key sits on a keyboard (not forgetting the waste of space that is the spacebar.)

It would be neat if someone would make a zmk / qmk keyboard with five thumb keys where the space bar is. Might be the sweet spot for most.

From the preferences:

- Unlock a next key only when the previous keys are also above the target speed. (This will force you to practice keys that are problematic in context, it's frustrating but very helpful for reinforcement learning. For example, I struggle with B, C, V on my split because I don't use the “correct” fingers for those keys on a standard keyboard.)

- Add capital letters

- Add punctuation characters

- Add words to lessons (move it to the max)

Regarding getting much worse in the real world; IMO this isn't discussed enough. When you're relearning muscle memory, it's a very different beast to copy what you see (focused only on where your fingers are) as opposed to focusing on your thought and your fingers just “go there”. I, too, have found my speed plummet at first; at some point I decided to just go cold turkey and suffer being rather slow – trading it for eventual mastery.

In my case, because I was such a phenomenally sloppy typist, sometimes what felt slow was likely just as quick as a result of making fewer mistakes on the new split layout where my behaviour was forced to be better.

My current fuzzy find key combinations include:

ff: fuzzy find, limited to current project

fc: fuzzy find (c)ode -> expand search scope to all projects

fg: fuzzy find (g)lobal -> let's just search my entire home folder

I imagine I'd have to limit it to the first and remap 'fg', I use 'gf', 'gc', 'gg' for the grep versions of these commands.

Either way, very cool.

Random edit: It's also how I learned the word obsequious.

It's almost as if, as tool use and planning capabilities have expanded, Claude (as a singular product) is having a harder time coming up with simple approaches that just work, instead trying to use tools and patterns that complicate things substantially and introduce much more room for errors/errors of assumption.

It also regularly forgets its guidelines now.

I can't tell you how many times it's suggested significant changes/refactors to functions because it suddenly forgets we're working in an FP codebase and suggests inappropriate imperative solutions as "better" (often choosing to use language around clarity/consistency when the solutions are neither).

Additionally, it has started taking "initiative" in ways it did not before, attempting to be helpful but without gathering the context needed to do so properly when stepping outside the instruction set. It just ends up being much messier and inaccurate.

I have to regularly just clear my prompt and start again with guardrails that have either: already been established, or have not been needed previously / are only a result of the over-zealousness of the work its attempting to complete.

It's easy to tout big learning gains when you have to build a tool that administrators will buy (substitute the non-educator buyer persona for your school/board/system here.) And for administrators to pay for something, you must design a tool with, you guessed it, numbers that go up.

Learning often doesn't work like that when what you want to teach, ultimately, is how to learn (assessment for learning / developing cross-curricular competencies / visible learning etc. etc.)

I left the industry, disenchanted—no, despondent. No one really cared about providing educators a great tools and great content designed around them and their learners.

Hey, you know what, instead of providing the best learning experiences possible, let's just teach our students how to use Google or Microsoft's Office Suite so little Jenny can get a head start on those TPS reports.

Yeah, I'm salty. AMA.

1. I use a custom domain.

Turns out that there are two competing features, not-at-all documented. If you use a catch-all, like I do, AND use specific addresses for sending, the two are incompatible to some degree. Which is bonkers.

Example: with a catchall I can create any address I want (and I do). Some store wants an email for a big discount, cool, here's a throwaway. Buying something online, here's a throwaway.

Now sometimes, I need to reply using that throwaway. Turns out in Proton, this triggers a gotcha. As soon as I add the throwaway email to my list of email addresses for sending, I enter a world with a limit of 10 max.

That's fine, I can disable them right?

Nope, it turns out if I disable them in order to add aothers, Proton blocks those addresses *even though I have a catch-all*. WHAT?? Worse, if I try to delete the addresses, Proton will also delete the associated messages in my Inbox/folders. Excuse me?

2. What really pushed me away: Search.

Whatever proton is using under the hood is easily the worst search experience I've ever had from a mail product, and I use Thunderbird on my work machine.

Notable: Proton Bridge. I get why, but it's just terrible.

So many rough edges. Just not worth it.

For whatever reason, the FP-first approach it allows me to use, matches how I like to think about problems. For comprehensions for handling complex types, easily, feel like a superpower.

When I started (and I started out of necessity, inheriting a number of old Scala 2/Play 2.x codebases), it felt like a big mistake. Weeks of banging my head around abstractions I didn't yet understand, or immutability-first approaches that were different from my (limited) python experience had me terrified. It eventually clicked. For my first year, I committed to write some Scala every single day; it was worth it.

Though to be fair, two years with the language versus ten is a big difference, so I very well could be completely wrong here. It's just like, my opinion, man.

Would I enjoy writing any language after putting in a lot of dedicated seat time? I don't know. I certainly didn't fall in love with Python the same way - but I'm willing to admit I could be doing it wrong.

That said, a number of the concerns in the post are valid. There's some spread between Scala2 and Scala3, related libraries, tooling, and a few surprising gotchas. Testing frameworks are bit fragmented with Scala2 and 3 support. However, I've not found it nearly as horrible and the joy of being able to work with what is working has outweighed the occasional "WTF" cost (often measured in "time wasted" lol).

I can't speak to the IDE issues the author is noting, I don't use IntelliJ. I've found Metals + Neovim to be truly wonderful on the whole, and it's pushed me to be even more aware of the underlying tooling I'm using.

Scala's 3 enums, opaque types (and now named tuples) are just a few changes that have made Scala 3 pretty wonderful to work with. It doesn't seem to me like Scala3's release is a failure. The real word is messier than a well-written function. ;)

One thing I've found, not at all mentioned in the article, is how welcoming the Scala community is, whether by necessity or virtue (why not both?). They're open to accepting help, willing to mentor/teach, engage in reasonably thoughtful discussion (from my experience), and seem to be willing to support each other.

Scala also pushed me to start learning Rust. Some of their shared heritage and style made it an interesting target for my desire to learn a language for a few embedded systems projects I'm working on.

So is it a dying language? I don't know if I really care. I'm incredibly grateful it exists.

PS - ScalaJS is both fun and cool. I love that someone wanted to make this a reality.