jevndev

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

> 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 :,)