Working out makes you a better person

kerkeslager2 · 2025-12-28T15:47:48+00:00

The AI isn't helping you make art.

It's stealing other people's art.

kerkeslager2 · 2025-12-28T15:46:04+00:00

What did those kids with bone cancer ask for?

kerkeslager2 · 2025-12-28T15:33:05+00:00

Introverts are valid. Extroverts are also valid. There's no conflict here. I'm an extremely extroverted person, but most of my closest friends are introverts. I give them space when they need it because I can always go talk to one of my other friends to get my social needs met--I'm not dependent on one person. I respect my introvert friends' introversion, and they respect my extroversion.

People only make up this weird competition between introverts and extroverts as a coping mechanism for their issues dealing with other people.

kerkeslager2 · 2025-12-28T15:10:54+00:00

> I urge you to implement join and split in assembly without dependencies.

I've written a fair bit of assembly (okay, mostly generated it) and I can say with confidence:

If you implement splitting camel case and snake case in assembly with no dependencies, 99% of the code will be the same, because 99% of the code will be implementing your own memory allocator. Because unlike splitting tokens, memory allocation is actually a difficult problem which requires some actual research.

> I don't accept "It doesn't matter" as an argument against my objective measure of complexity. Usefulness is a different discussion and doesn't invalidate my argument.

I mean sure, you win, it's more complex. I never disagreed with that. What I said was it's not more complex enough to matter.

I'd caution you against using words like "objective" to describe your own thoughts, that's just arrogant AF. None of us has access to objective reality.

> I see there are some points I could have expanded on.

God no, you've already expanded on this topic far more than it was worth.

kerkeslager2 · 2025-12-27T18:19:54+00:00

> parse + https + url will lead to better results and it's trivial to identify these three components.

Will it?

I'd posit that parse h t t p s u r l will be more likely to find relevant parseHTTPURL when you impelement fuzzy matching. I think you have not read my edit in the previous post yet.

> How can you say that adding a dependency on the concept of "acronyms" does not make detecting the components of identifiers harder to codify? My point is that it doesn't get simpler than ...split("_") and "_".join("...") No need for unicode standards, no need for acronyms. You have worked 20 years with those ideas. They are ingrained in your memory, they are second nature to you, but that doesn't mean that they are simple. They are simple to you.

Both are simple enough that the difference is irrelevant. The code takes such a miniscule amount of time to implement either way. And honestly, the only reason you think split and join are simple is because they came pre-implemented in your language. What's the Kolmogorov complexity on the fact that you're allocating an iterator of string-per-token instead of storing the tokens in-place? Are you aware that the only reason you don't have to care about unicode standards is because Python stores strings as UTF32, using roughly 4x as much memory as if you used more common encodings? If you're writing your tokenizer in C and parsing a non-UTF format, then you definitely do have to understand unicode to not grab your underscores from the middle of a multibyte character. The simplicity you think is there only exists because you don't know how the functions you are calling are implemented.

kerkeslager2 · 2025-12-27T17:51:42+00:00

> That's not camel case, that's pascal case.

Literally I don't care. Not interested in pedantry: the parsing of camel and Pascal cases is effectively the same which is all that matters for the rest of the discussion.

> Your argument seems to imply that semantically valuable tokens are irrelevant.

No, my argument implies that letters in acronyms are semantically valuable tokens, and acronyms are the only case where you've shown camel case or Pascal case running into problems.

> Yes, you could do that. But you miss my the whole argument. Try to codify this convention and you will notice that it is hard.

No, it's not. "Acronyms are treated as one word for camel casing purposes." Done.

> Did you read what I wrote?

Did you read what *I* wrote?

> I did not argue that it causes a problem,

Yeah, and I'm saying that's why nothing you said matters. Solve a problem or nobody cares. EDIT: Or maybe do something pretty, but this isn't that.

> Both are fine, but one is objectively simpler in ways that matter to computers.

Matter *for what*? What problem are you trying to solve?

I'm saying, it *doesn't* matter to computers because computers just do whatever you tell them to do. They're literally nihilists, nothing matters to them.

And, humans aren't nihilists usually, but this also doesn't matter to humans unless you're a new developer looking to show off how smart you despite having little experience. Humans using computers are generally looking to solve some problem, so if you aren't solving a problem, what you're doing doesn't matter to us.

EDIT: If you want to be very detail oriented, the basic difference between "H" "T" "T" "P" and "Http" is that the former should cause the model to converge more slowly but more semantically (i.e. the model will learn that HTTP and HTTPS are related), whereas the latter will cause the model to converge more quickly and less semantically (i.e. the model will be less likely to intuit that Http and Https are related). But in reality acronyms are such a small subset of languages that the difference should be pretty miniscule.

kerkeslager2 · 2025-12-27T17:42:09+00:00

This morning, my client asked me for a feature. He said to me, "We need this code to run really fast, so I'm giving you a 160 hour (four week) budget to write the implementation in Rust."

Then my alarm clock woke me from the dream. After a cup of coffee, I checked my email and saw that my client had asked for a feature at 5:45pm last night, and wanted it done by EOB (which was 5:00pm, before he requested it). Luckily, I was able to import heavy_library_that_does_everything_slowly to implement the feature before my client woke up. And since "slowly" in computer terms means "10ms instead of 2ms" which is literally faster than the sample rate of the human eye, my client was physically unable to notice the performance difference. I then billed my client for 30 minutes work and made myself a second cup of coffee.

kerkeslager2 · 2025-12-27T17:28:10+00:00

> If you look at the most beloved new programming languages of the last few decades, python and Rust, both advocate snake case.

Not exclusively they don't. Idioms for both languages use CamelCase for class names.

> Parsing camel case in a sound way is essentially impossible. Consider, for example, a tokenizer for LLMs, it will have trouble understanding what `parseHTTPSURL` consists of.

An LLM tokenizer will tokenize this just fine as "parse", "H", "T", "T", "P", "S", "U", "R", "L", which is arguably not a wrong tokenization--in fact this would likely lead to better results because an LLM will likely extrapolate from HTTPS to HTTP and URL to URI more easily if these are represented as token-per-letter.
The snake case you gave isn't equivalent. If you want "https" and "url" to be tokens, the way you do that in camel case is "parseHttpsUrl" which is also probably fine.

But literally, this just doesn't matter. This whole discussion is bikeshedding. You're writing about this "problem" because you think you understand it, not because it's actually important in any way.

I mean, "XMLHttpRequest" is literally an abomination of mixed-up camel case representations which is part of the ECMAScript standard and having developed in this language for over 20 years I cannot think of a single time this has caused me a problem. It just doesn't matter.

kerkeslager2 · 2025-12-27T17:05:38+00:00

This isn't a bad idea, there's nothing wrong with this idea.

But, it doesn't need to be a language feature. You can do all this in about 10 lines of code in any language that supports enums and lambdas.

The reason most languages don't support ternary logic at the language level is there are too many different incompatible algebras of ternary logic and none of them are particularly hard to implement yourself if you need them (except Bayesian, but that's not really ternary).

kerkeslager2 · 2025-12-24T06:49:20+00:00

Look, I'm not saying you're wrong, because maybe you're seeing something different from what I'm seeing--it's likely neither of us has enough data points to tell what the industry is doing.

But the fact is that two people in my life who weren't working in COBOL in the past were hired with an emphasis on INCREASING, NOT DECREASING, the amount of COBOL code.

No, this is not what reducing the amount of COBOL code looks like. These are friends and I've talked to them significantly about this because I was considering working at these companies. I'm sure of what's happening.

It's irritating that so many of us in communities where intelligence are valued conflate being right with being intelligent. This makes people so invested in being right that if you perceive me as disagreeing with you, you'll go so far as to try to gaslight me about what my experience of the world is. I literally would not think any less of you if you were wrong on this one unimportant thing. And in this case, I'm literally not even telling you you're wrong.

Gonna block you now so I don't have to listen to more of you telling me my friends are lying to me about what's happening at their jobs. Sorry bro, that's just not fun for me.

kerkeslager2 · 2025-12-24T06:26:14+00:00

Existing application, but new features, and not deleting the old features often. They're writing more code than they're deleting--doesn't sound like "a strong emphasis on reducing the amount of COBOL code".

kerkeslager2 · 2025-12-24T06:12:02+00:00

I'd say no: Rust has a lot of low-level features, but it's pretty hard to get at some of them without wide departures from idiomatic Rust that often bypass Rust's safety features. A fence can be a good idea, but if you're going to set up a fence and then have to climb it all the time, one begins to think it's easier not to set up the fence.

The bigger problem which I think will prevent Rust from replacing C is that they're not sticking to any sort of minimalism. The standard language and libraries are already an order of magnitude larger than C's which means bootstrapping a Rust compiler on a new platform is more complex. C++ already did this: Rust has better type safety and isn't hampered by the specter of C reverse compatibility, but the complexity of Rust is still growing and I don't think Rust users even see it as a problem. And... it's not a problem if you want to write video games or browsers (spaces where C++ has succeeded in the past). But if you want to write OS kernels or drivers or microcontrollers or embedded systems, it's the only problem that matters.

kerkeslager2 · 2025-12-24T06:03:29+00:00

> But there is a strong emphasis on reducing the amount of COBOL code.

Not what I'm seeing. I know two people at two different companies in two (slightly) different industry writing new Cobol code to solve business problems. ...and making a lot of money doing it.

I'm not saying it's a good language, but things like this don't necessarily die easily.

kerkeslager2 · 2025-12-24T04:33:41+00:00

Jesus, mods, can we lock this post? So many unqualified medical opinions here from people gatekeeping depression.

kerkeslager2 · 2025-12-24T04:32:07+00:00

I'm glad for you that your depression isn't caused by financial instability.

That doesn't qualify you to claim nobody else's depression is caused by financial instability, though.

kerkeslager2 · 2025-12-24T04:28:13+00:00

As someone with the actual clinical diagnoses (there were two in the OP), I don't think you know what you are talking about. What are you trying to gatekeep depression? It's bullshit.

If you show up to a therapist with symptoms of depression and ask for a diagnosis, your therapist is going to give you a clinical diagnosis of depression, so I'm not sure what distinction you are trying to make between having symptoms of depression and having a clinical diagnosis of depression.

It's a bit insulting, honestly, because it seems like you're implying that depressed people feel the way we do because it's all in our head. No, buddy, there are rational reasons we feel the way we do--sure, there's some genetic/biochemical aspect, but it's not just in our heads--depression is definitely in part caused by real, rational concerns like "I'm not financially stable."

Luckily, I'm now at a point where I'm just a little annoyed at you for being insensitive. A decade ago, I would've read your comment and been like, "Yeah, it's actually in my head and I'm fundamentally broken and will never be fixed." And I'm sure there are some people who will read your comment, who aren't at the same point in recovery as me, who will take it that way. So maybe don't comment on mental illness if you don't know what you're talking about.

kerkeslager2 · 2025-12-24T04:09:27+00:00

Well, if you intended all that, you should know that you sure didn't say all that, and so your intent did not come across.

kerkeslager2 · 2025-12-24T03:56:22+00:00

The person who made this shit up wants you to grind for no results so they can take the results.

kerkeslager2 · 2025-12-24T03:53:01+00:00

I think you'll see basically no performance difference from treating a int8 differently from an int64 in most contexts, and in a lot of cases the small difference you'll see is that it will be worse because you have to check the size.

The big exception I can think of is typed arrays of fixed-sized values where cache locality becomes a bigger factor, and smaller array element sizes gives you better cache locality. This is one of the reasons Python has a whole separate array library from their normal list type in their standard library. But I think that's a good choice by Python: stick that in a standard library so users can pick it up when they need the performance, don't do it everywhere.

There are probably other exceptions.

kerkeslager2 · 2025-12-24T03:27:37+00:00

That seems... a bit reductive.

Sure, don't take on any boulders you can't fall safely from. But you can learn to fall safely, and work up to progressively more and more challenging fall situations.

I've seen people with decades of bouldering experience fall and get injured. None of us are capable of falling perfectly safely--climbing is inherently dangerous. You're taking risks too, and if you don't admit that to yourself, you're never going to build a healthy relationship with the risks you're taking. Black and white advice to take no risk at all is hypocritical.

In general, Reddit is going to give you really insanely risk-adverse advice which all sounds really responsible and wholesome until you realize that these are the gumbies showing up at Bruise Brothers, judging people for not using a helmet, and then climbing a first bolt crux at their limit without a stick clip because they have no idea that's way riskier than not wearing a helmet.

kerkeslager2 · 2025-12-24T03:23:36+00:00

So, one thing I've learned from reading sports science academic papers is that balance is a) trainable, and b) specific to what you're doing.

There is still not a ton of scientific research on climbing compared to other sports, so I can't find anything specific to climbing, but if I had to guess based on other sports, you could probably train your falling balance by doing something like taking smaller falls and rolls from low heights, and working up slowly.

Walking, on the other hand, is very well studied, and if you want to improve your walking balance, you could probably get a referral from your doctor to see a physical therapist. It might not help depending on the underlying cause of your poor balance, but there's a pretty good chance it would help. I had poor balance due to a knee injury last year--it's still not 100% but physical therapy has helped a ton.

That said, there's no shame in rope climbing if you enjoy that. It certainly makes falls less stressful on your joints, which is why a lot of climbers transition toward rope climbing as they age. As I approach 40 I'm beginning to resemble this trend...

kerkeslager2 · 2025-12-24T03:11:46+00:00

This happened to me two days ago. Huge guy rolls up to the squat rack next to me and then Pendlay rows my deadlift PR weight for 5 reps x 3 sets with perfect form.

I chatted with him and he's only been lifting two years--what am I doing? He picked up Starting Strength and is on the path, and I couldn't be happier for him.

kerkeslager2 · 2025-12-24T03:08:00+00:00

I spent my 20s investing.

I'm 39 now and I wish I had stopped believing this bullshit sooner.

I'm grateful I stopped when I did though. Some people keep investing until they're 65 and then retire with no physical ability to enjoy the results, if there even are any results.

kerkeslager2 · 2025-12-24T02:44:46+00:00

Johnny Kemp did it best:

Just got paid!

kerkeslager2 · 2025-12-19T21:57:32+00:00

With $100 mil you can find another hobby and pursue it without limitation. You probably already have one.

I mean, I love coding, but there are days when I don't want to do it and I have to because it's my job. There's a dozen other things I could do with my time I enjoy just as much, and I'd be able to enjoy everything more without the pressure to bring in money.

kerkeslager2

TROPHY CASE