capyba

Your last sentence describes my thoughts exactly. I try to incorporate Claude into my workflow, just to see what it can do, and the best I’ve ended up with is - if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better.

Even just some AI-assisted development in the trickier parts of my code bases completely robs me of understanding. And those are the parts that need my understanding the most!

I wish I knew more about cattle to add to the analogy but I do very much appreciate it as is.

I’ve been a longtime competitive athlete and my best deadlift was 545 lb. I’ve been in many gyms in my life and I’ve only met maybe a dozen men lifting more than say 350 or so.

Expecting the “average” man to get to a 400 or even 300 lb deadlift is absurd. Sure, most people could be in better shape but a 4 plate deadlift is much more strength than most people need… and more than most people’s bodies can safely handle regularly. The risk of serious injury rises exponentially when you put on weight like that.

Building and maintaining strength, especially into the older ages, is certainly important but not to the levels you describe here. I suspect your comments here are based on neither personal experience nor proper education and training.

tkinter is the best kept secret in the Python std lib.

Pair it with numpy and matplotlib (two external dependencies that personally I consider part of Python itself), and you’ve got 80% of an interactive scientific simulation environment.

What exactly is an “AI working competency”? How to have a conversation with a chatbot? How to ask a chatbot a question that you confirm with a Google search and then confirm that with a trusted online reference and confirm that with a book you check out of the library three weeks later?

Perhaps the world is going the direction of relying on an AI to do half the things we use our own brains for today. But to me that sounds like a sad and worse future.

I’m just rambling here. But at the moment I fail to see how current LLMs help people truly learn things.

Same here! That’s a great blog with a lot of good advice.

Hearing someone proudly describe themselves as a libertarian always reminds me of the ol’ twitter quote that goes something like “libertarians are like house cats - fiercely self-assured of their own independence, yet completely reliant on a system they don’t appreciate or understand.”

I’d argue that in many of these instances, less is far more.

I want my car to just be really good at being a car, reliably get me from A to B. A Bluetooth connection to the stereo system is nice, but I don’t need a freaking 20” phablet right next to my face when I’m driving.

When I go to a website, I’m usually looking for information, to read something. I don’t often want fancy scroll and animations, I just want clear readable text free of distractions.

More and more these two examples seem to be going away, we’re losing the plot of what the point of these things are.

I feel for the author. I do both mechanical and software engineering and I’m in this career(s) because I love making things and learning how to do that really well. Been having the most difficult time accepting the idea that there isn’t a good market for people like us - artisans, craftsmen, whatever the term might be - who are obsessive about exceptional quality and the time and effort it takes to get there. In this day and age, and especially when LLMs look ever more like they can produce at least a cheap, dollar store approximation of the real deal, “doing things really well” is going to be relegated to an ever more niche market.

Radiation does not work “incredibly well”, especially at the temperature range of interest. Forced convection (what every large terrestrial electronics system uses, from gaming laptops to terrestrial data centers) is orders of magnitude more efficient at pulling heat out of electronics than radiation. Normally electronics generate heat in a very small area relative to the entire package size, and conduction+radiation offers many practical issues to efficiently dissipating that heat to deep space.

Source: many years of practical engineering experience solving this exact problem.

Agreed that some level of gatekeeping and some level of friction to protect quality are useful things.

I only personally know one Rust programmer (works in scientific HPC) and he’s fantastic, but in general I do get the sense that most Rust devs migrated from JS and are just now figuring out “omg strong typing and compiled code native to the client hardware is really nice!” and think it’s a ground breaking revelation.

Saying this as someone who is cautiously optimistic about Rust for my own work.

Honestly hadn’t even thought of that - easy to say “more is better, right?” or miscalculate what the dose should be.

Yea, I think this is a bit half-baked. Either the journalist doesn’t know how diabetes is treated with insulin therapy, or it’s meant for people with T2D who are only on a basal dose (unsure how common that is).

There are ‘classic’ insulins like intermediate/regular that act over longer duration and are meant to be taken once a few times a day. Though they’ve generally been phased out with the rapid+long acting approach because that matches insulin needs of the body better.

Interesting… though seems to be limited to basal insulin doses. The basal/bolus paradigm using pens or pump (both injections) can’t really go away without a ‘smart’ insulin that stays in the bloodstream, inactive, and only reacts to changing glucose levels.

This, 100%. I forget the specific numbers but regardless, the kinetic energy of a thing with that much mass, even moving at a very slow speed, is off the charts. Designing a bridge or protections for a bridge to survive that would at a minimum be cost prohibitive, if even possible with today’s materials and construction technologies.

The processing capability of today’s CPU’s and GPU’s is insane. From handheld devices to data centers, the capability to manipulate absurd amounts of data in fractions of a second is everywhere.

It’s not the hardware, it’s the algorithms.

As someone who takes insulin every single day and lives in mild fear of an overdose, the idea that it was once used to intentionally induce hypoglycemic comas as an “psychiatric treatment” is a terrifying concept to me.

This works really well in mechanical engineering, too. We don’t necessarily use tickets specifically, but planning out work or a design upfront with a small audience saves a lot of time and wasted effort.

On some level this is just basic project planning, which in my view is an underdeveloped skill in most modern engineering teams. In the case of the ‘empty ticket’, it’s project planning but at a lower level. Not every bit of work needs this, but many would benefit, especially when the taskee is at a more junior level.

I wholeheartedly support this approach. Nearly every major project requires a team, not an individual, and coordinating and collaborating are basic functions of getting things done.

Is this sort of thing widely known ahead of time before purchase, ie signing some T&C’s?

My car is >10 years old, which feels like a lifetime right now, given the rapid pace of change in car tech (notice I didn’t say “progress”). It doesn’t even have a backup camera. I’ve done all sorts of basic maintenance on it by myself. In some ways I’m terrified of buying a newer car today because it seems like I won’t be able to do that and I’d have to deal with an always on modem and other owner-hostile features (note that I didn’t say “user”).

I want to drive a car, not rent a computer on wheels. It pains me when I see people write things like “CarPlay didn’t work, this vehicle is trash” like they forgot what the thing was supposed to do for them in the first place.

Are there manufacturers that don’t widely do this?

Interesting, how so? I’ve had really good success with the autovectorization in gcc and the intel c compiler. Often it’s faster than my own instrinsics, though not always. One notable example though is that it seems to struggle with reduction - when I’m updating large arrays ie `A[i] += a` the compiler struggles to use simd for this and I need to do it myself.

Interesting, in what domain? My work is in scientific computing as well (finite elements) and I usually find myself in the opposite situation: SIMD is very helpful but the added complexity of using a GPU is not worthwhile.

Which came first, the nvidia drivers, or the super-necessary local models that wrote those drivers?

Given the “blazingly fast” branding, I too would have thought this would be in stable Rust by now.

However, like other commenters I assume it’s because it’s hard, not all that many users of Rust really need it, and the compiler team is small and only consists of volunteers.

This article is specifically about the implementation of SIMD in Rust, not other languages.

All you're doing is passing an argument of the incorrect type to your function. The exact same thing fails to compile in C:

``` #include <stdio.h>

typedef struct { int value; } Feet;

typedef struct { int value; } Meters;

void hover(Meters altitude) { printf("At %i meters\n", altitude.value); }

int main() { Meters altitude1 = {.value = 16}; hover(altitude1); Feet altitude2 = {.value = 16}; hover(altitude2); } ```

``` error: passing 'Feet' to parameter of incompatible type 'Meters' 20 | hover(altitude2); ```

Coming from a dynamically typed language (Python, etc), this might seem like a revelation, but its old news since the dawn of programming computers. A C language server will pick this up before compile time, just like `rust-analyzer` does: `argument of type "Feet" is incompatible with parameter of type "Meters"`.

Did you not know this? I feel like a lot of people on message boards criticizing C don't know that this would fail to compile and the IDE would tell you in advance...

I couldn’t agree more. It feels “squishy” to me. The only statically typed, compiler languages I have a lot of familiarity with are Rust, C, and C++, and they all have different sort of warts.

C with some sort of module system and the tooling of Rust would be really nice.

Forgive me - much of the article went over my head so I’m trying to understand: this article is excellently written, but I’m struggling to understand why a `Vec<u8>` wouldn’t have sufficed? And disregarding the first question, is there a way to extend this to floats, for instance if I have a collection of values that I know will never exceed the bounds of +/- 10.0 with 1e-6 precision, can I use this technique for more efficient storage of them?

Nothing about this is moving goalposts - you and/or the person(s) conducting this study are the ones being misleading!

If you want to measure time to complete a complex task, then measure that. LOC is an intermediate measure. How much more productive is "55% more lines of code"?

I can write a bunch of garbage code really fast with a lot of bugs that doesn't work, or I can write a better program that works properly, slower. Under your framework, the former must be classified as 'better' - but why?

I read the study you reference and there is literally nothing in the study that talks about whether or not tasks were accomplished successfully.

It says: * Junior devs benefited more than senior devs, then presents a disingenuous argument as to why that's the senior devs' fault (more experienced employees are worse than less experienced employees, who knew?!) * 11% of the 55% increase in LOC was attributed directly to LLM output * Makes absolutely no attempt to measure whether or not the extra code was beneficial

“ Productivity (measured by the number of lines of code produced) increased”

The LLM’s better have written more code, they’re a text generation machine!

In what world does this study prove that the LLM actually accomplished anything useful?