jevndev

It has a double meaning actually! The ship of Theseus reference like you noted and the “Harkinian” part being the name of the king of Hyrule from the CDI games. One of his lines is “Enough! My ship sails in the morning” [0] so the project is also a reference to his actual ship. (Referenced in the projects FAQ [1])

[0] https://youtu.be/JmxGLo_itEY?is=x85epFYBcPeRDxxh

[1] https://www.shipofharkinian.com/faq

For what it’s worth, a common example of the capabilities of c++26 reflection is exactly this use case. I can’t remember where I first saw it, but this article [0] showcases the technique pretty well. It’s opt-in so not the compiler optimization that you’re imagining but still neat that it’s possible

[0] https://brevzin.github.io/c++/2025/05/02/soa/

To clarify, I really do enjoy the premise of the article. I’m a big fan of circuitry-as-art so I was excited to see what new ideas this brought to the table. It’s clear my tone in my original comment made it seem like I was fully disregarding the article and I’m sorry for coming across that way. In retrospect it was very snippy and it shouldn’t have been. I was just very thrown off by the comment in an article that is otherwise taking itself very seriously.

I love ligatures but I wish there was tooling for context sensitive ones. This is a really good example. When developing, I love <= turning into ≤. When running a cli that happens to use <= for the start of its progress bar… not so much

Reasonably certain the practice of naming combinators after birds comes from “To mock a mockingbird” by Raymond Smullyan. Don’t have the book on hand to verify but figured I’d drop it here because it’s a great bunch of logical puzzles

The common argument for a language feature is for standardization of how you express invariants and pre/post conditions so that tools (mostly static tooling and optimizers) can be designed around them.

But like modules and concepts the committee has opted for staggered implementation. What we have now is effectively syntax sugar over what could already be done with asserts, well designed types and exceptions.

This is true about LLMs themselves but the developments behind them have been a boon for robotics. I’m mostly familiar with computer vision so I can’t speak to everything, but vision transformers (ViTs is the term to search for) have helped a ton with persistence of object detection/tracking. And depth estimation techniques for monocular cameras have accelerated from the top of the line raw cnn based models from just a few years ago; largely by adding attention layers to their model.

I agree that they’re not there yet but I don’t want to discredit the benefits of these recent advancements

Unfortunately this practice is prevalent still. Recently I’ve been applying to jobs in the two industries I have experience in (algorithmic robotics and fintech) and nearly half of the companies that I’ve heard back from start with either a timed leetcode problem or an HR interview which is immediately followed by a timed leetcode problem. It’s exhausting.

My least favorite by far is the “multi section” webpage design. Where the page is split into multiple whole-screen sections and scrolling the mouse wheel alternates between either moving between sections or playing the animations of that section. Yes please make my scroll wheel only sometimes actually scroll the page and other times rotate a graphic for way too long thanks

Neat example of the strengths and weaknesses of vibe coding… But if anyone here is looking for a solid browser-based parametric CAD solution, [onshape](https://www.onshape.com) is the best there is. It’s missing a few tools that more complex alternatives have but if all you need is something easy to learn so you can make things to 3d print it’s a good choice

> the definitions are cloudy enough […]

This is one of the biggest traps I’ve seen in code review. Generally, everyone is coming from a good place of “I’m reviewing this code to maintain codebase quality. This technically could cause problems. Thus I’m obligated to mention it”. Since the line of “could cause problems (important enough to mention)” is subjective, you can (and will, in my experience) get good natured pedants. They’ll block a 100LOC patch for weeks because “well if we name this variable x that COULD cause someone to think of it like y so we can’t name it x” or “this pattern you used has <insert textbook downsides that generally aren’t relevant for the problem>. I would do it with this other pattern (which has its own downsides but i wont say them)”.

The “Stop at first level of type implementation” is where I see codebases fail at this. The example of “I’ll wrap this int as a struct and call it a UUID” is a really good start and pretty much always start there, but inevitably someone will circumvent the safety. They’ll see a function that takes a UUID and they have an int; so they blindly wrap their int in UUID and move on. There’s nothing stopping that UUID from not being actually universally unique so suddenly code which relies on that assumption breaks.

This is where the concept of “Correct by construction” comes in. If any of your code has a precondition that a UUID is actually unique then it should be as hard as possible to make one that isn’t. Be it by constructors throwing exceptions, inits returning Err or whatever the idiom is in your language of choice, the only way someone should be able to get a UUID without that invariant being proven is if they really *really* know what they’re doing.

(Sub UUID and the uniqueness invariant for whatever type/invariants you want, it still holds)

Funny enough, he has talked about this exact problem on his podcast “Two’s complement”; Specifically the episode “The future of compiler explorer”. Commenters below are correct that it’s just about how heavily associated his name is with the tool. I just figured I’d also drop this source here because he has a lot of interesting things to say about his involvement with the project

I’ve stumbled into this problem before while drafting a language I want to make*. A lot of the design philosophy is “symbols for language features” and as such import/export is handled by `<~`and `~>`. An example of an exported function:

``` <~ foo := (a: int) { a - 1 } ```

Then at the import site:

``` ~> foo ```

* some day it’ll totally for real make it off the page and into an interpreter I’m sure :,)

I think the key to understanding why people want this is that those people care about results more than the act of coding. The easy example for this is a corporation. If the software does what was said on the product pitch, it doesn’t matter if the developer had fun writing it. All that matters is that it was done in an efficient enough (either by money or time) manner.

A slightly less bleak example is data analysis. When I am analyzing some dataset for work or home, being able to skip over the “rote” parts of the work is invaluable. Examples off the top of my head being: when the data isn’t in quite the right structure, or I want to add a new element to a plot that’s not trivial. It still has to be done with discipline and in a way that you can be confident in the results. I’ll generally lock down each code generation to only doing small subproblems with clearly defined boundaries. That generally helps reduce hallucinations, makes it easier to write tests if applicable and makes it easier to audit the code myself.

All of that said, I want to make clear that I agree that your vision of software engineering Becoming LLM code review hell sounds like… well, hell. I’m in no way advocating that the software engineering industry should become that. Just wanted to throw in my two cents

You are correct. I absolutely missed the "during the school day" stipulation.

Oop, I totally missed the "during the school day" part of the grandparent comment. I totally agree with banning them during the school day. My argument was against the point that the grandparent wasn't making which was banning phones from K-12 students both during and after the school day

Oh I just realized I missed the "during the school day" part of the comment I cited. That's totally my mistake. For what it's worth, I agree with banning during the school day but (although no one is making the point here) I would disagree with banning them from children everywhere always.

> A good starting point would be fully banning all phones for the entirety of the school day in K-12.

Is what I was responding to in the grandparent of your comment

It really feels the same as weed/nicotine/alcohol/sex/other vices. If history has taught us anything, outright banning them only makes them into forbidden fruit. We need to explain (and frequently reinforce) these negative effects of modern phone use so kids can grow up understanding them. Right now, it seems like a lot of people really only start to understand the impacts of this kind of phone use long after they're addicted. Hopefully informing them before that happens would help.

Of course, this kind of thing is easy to do wrong. Programs like D.A.R.E. and THRIVE tried going the way of fear tactics which seems to really not work well. We need to have an open and honest discussion about "yes, this is fun. But it DOES have a bad side" instead.

The last sticking point there is that it assumes people will be rational and come to the conclusion of using with moderation. Hopefully people can be rational... Otherwise I think there's no hope for us in solving the brainrot epidemic.

Im curious about what you're working on. Do you have a repo for the project?

As for optimizations, I figure evolution-designed languages might come up with things that are hard to pattern match for more complex operations.

I feel like a lot of people are forgetting how good llms are at small isolated tasks because of how much better they've gotten at larger tasks. The best experiences I've had with llms all involve sketching out the interfaces for components I need and letting it fill in the implementation. That mentality also rewards choices that lead to good/maintainable code. you give functions good names so the AI knows what to implement. You make the code you ask it to generate as small as possible to minimize the chance of it hallucinating/going off the rails. You stub simple apis for the same reason. And (unsurprisingly) small, well defined functions are extremely testable! Which is a great trait to have for code that you know can very well be wrong.

In time the AI will be good enough design whole applications in this vibe-code-y way... But all of the examples I've seen so far indicate that even the best publicly available models aren't there. It seems like every example I've seen has the developer bickering with the ai about something it just won't get right - often wasting more time than they were slightly more hands on. Until the tech gets over that I'll stick to it being the "junior developer I give a uml diagram to so they can figure out the messy parts".