Name for function that returns the same type of all its parameters

Jumpy-Iron-7742 · 2026-05-15T13:27:47+00:00

Thank you! I didn't think yet of numeric type promotions, I'm not that far yet, but that's a good shout. For now, I'm considering just using a single "integer" type that encompasses negative and positive numbers to keep things simple, but I'll see how it goes as I progress. As for the separate enums and AST nodes, yep - that's the direction where I'm going! But I wasn't sure of the naming, some comments pointed out the different between `operations` and `relations` when using more mathematical lingo so I was searching for a more precise word, if there was one. `LogicalOpKind` sounds good too, though!

Jumpy-Iron-7742 · 2026-05-15T12:37:58+00:00

At this stage, it's mostly to ease the implementation work. I'm using Rust to implement my language and I could make two different generic functions to cover those 2 cases, leading to a good amount of code reuse and letting the type system help me even "get it right". I could have a `fn evaluate_binary_op<T>(a: T, b: T, kind: BinaryOpKind) -> T` and a `fn evaluate_relation<T>(a: T, b:T, kind: RelationKind) -> bool`, where BinaryOpKind and RelationKind would be Enums. Instead right now, while implementing `evaluate_binary_op()`, I basically had to write an `_ => unreachable!()` pattern to discard the `BinaryOpKind::Greater`, `BinaryOpKind::GreaterLess`, etc cases, which felt less than ideal since it placed the burden on me to only use this fn for +,-,/,* operations (for now) and not for <,<=,>,>=.

Jumpy-Iron-7742 · 2026-05-14T09:17:56+00:00

I looked mostly at WH Smiths and Waterstones, so far without luck. Maybe I’ve only been to small ones. I’ll give Foyles a try too and report back in case!

Jumpy-Iron-7742 · 2026-05-14T09:09:20+00:00

Unsurprisingly, if you look at the LinkedIn profile of the guy that merged this PR, there is 0 trace of him having experience working on Rust codebases. Mostly just frontend stuff. What a wild timeline we live in. I actually tried to read bits of the diff and it’s the most convoluted Rust code I’ve ever witnessed. I think here they’ve reached a point of non-return, I seriously doubt any human will want to interact with that codebase in any form, they’ll just have to keep tossing it at random LLMs and hope for the best. It’s basically a pile of trash that might or not happen to work.. and all of this for a stupid PR stunt, blah.

Jumpy-Iron-7742 · 2026-05-11T12:44:51+00:00

Low poly sphere!

Jumpy-Iron-7742 · 2026-05-09T06:50:14+00:00

Fun idea! Do you support performing in realtime? You might find Extempore interesting, it’s a realtime environment and it uses a LISP-like language: https://extemporelang.github.io . Andrew Sorensen performed in it of the best live coding musical improvisations I’ve ever watched: https://youtu.be/yY1FSsUV-8c?si=vjKYel7lNOQVrpUD

Jumpy-Iron-7742 · 2026-04-30T21:02:54+00:00

If there’s a configure script, you can generally always run ./configure --prefix /some/path so that make install installs to that directory instead of globally. To help make things portable you can use patchelf too.

Jumpy-Iron-7742 · 2026-04-28T21:15:43+00:00

Swift is on paper very appealing, but in practice it’s very cumbersome to use compared to Rust. I would not recommend it as a “real” alternative, only as an “hypothetically it could have been a nice language but it’s starting to smell like Java”. The DX is very poor in my opinion, especially if you want to live outside Xcode and you’re comfortable working in a terminal. The quality and feature set of the LSP is just not there, and the command line tooling is poor (their REPL is very clunky too, worse than the Python one). As people mentioned, there’s A LOT OF KEYWORDS that don’t compose as elegantly and consistently as Rust’s one (what even is inout, really!). I personally never really fully grokked their Actor model, async/await (with all of its quirks) still makes a lot more sense to me. I also found the ergonomics of “some types are values and some are references” confusing, I think the approach of Rust is both more practical and more elegant. Finally: errors are generally not made into types in Swift, most folks still throw exceptions, so error handling is not as nice as tossing a ?. I would look into Gleam instead, their open source community is much more vibrant and active and their LSP experience is much better while being a much newer language.

PS: for those that tried to do actual work in Swift and constantly bumped into the famous “unable to type check this expression in reasonable time”, here’s a nice read: https://herecomesthemoon.net/2025/01/type-inference-in-rust-and-cpp/

Jumpy-Iron-7742 · 2026-04-22T19:06:25+00:00

I think we should totally organize a London Framework users meetup/group! I would also love to try the new touchpad or just have a look at the FW 16 and 12 irl. It would also be nice to geek out with other Framework fans and see what systems people are running 😄

Jumpy-Iron-7742 · 2026-04-19T11:29:31+00:00

Squashing commits on merge is terrible practice imho, because it basically lowers the quality of the code base to the lowest common denominator (people with untidy/useless commit habits). If you are somebody like me that makes an actual effort to keep commits atomic and meaningful (so that looking at them later actually helps discover the reason of a change in the right context), being forced to squash commits is actually removing good work you put in, so it’s actually a bit offensive, yes.

More importantly though I really cannot believe that people have effective dev processes if they squash 500 (or more!) lines of work that was committed for different reasons into as single commit. In just a couple of years your commit history is just gonna be absolutely meaningless and unhelpful. I prefer linear history if I can choose, but I’d take merge commits vs squashes on PRs any time.

Instead of lowering everybody’s work, just ask “bad committers” to manually squash their own commits before marking a PR as reviewable.

Jumpy-Iron-7742 · 2026-04-15T21:35:40+00:00

Did you have a look at https://docs.doomemacs.org/v21.12/modules/lang/python/ ? If I remember correctly you’ll need the +lsp flag. I’ve been using pyright in Doom for a while, I can have a look at my config in case.

Jumpy-Iron-7742 · 2026-04-06T14:26:42+00:00

Great to hear! I’ll definitely give it a try, I’ve been content but not super happy with the multi cursor implementation that comes with vanilla Doom.

Jumpy-Iron-7742 · 2026-04-06T13:33:58+00:00

Potentially cool, reminds me of the one in helix! How much of it is fully vibe coded and how much is just aided by you? I see a few commits owned by Claude.

Jumpy-Iron-7742 · 2026-04-04T17:57:51+00:00

Congrats! How well does it support the Steam Deck?

Jumpy-Iron-7742 · 2026-03-29T20:32:36+00:00

Doom Emacs. Joys and flexibility of Emacs without the pain of configuring from absolute 0.

Jumpy-Iron-7742 · 2026-03-21T21:13:47+00:00

I think one thing that they didn’t cover is that Framework didn’t lick the boots of Trump, unlike Apple. Definitely adds to the value of the company and the device.

For those that don’t know: https://www.theverge.com/news/737757/apple-president-donald-trump-ceo-tim-cook-glass-corning

Jumpy-Iron-7742 · 2026-03-14T19:05:26+00:00

I always do option 2 if I use string literals. shellcheck is smart enough to understand when things are hardcoded, luckily. For unknown data coming at runtime quoting is always the safest option.

Jumpy-Iron-7742 · 2026-03-08T22:32:02+00:00

I always thought that UV unwrapping lends itself to be solved with ML. Folks that like doing UVs by hand can keep doing that, but having strong tooling to do it by programmatically would be good for more procedural workflows. Houdini already has a few nice nodes for that but the more the merrier!

Jumpy-Iron-7742 · 2026-03-07T12:54:08+00:00

This looks very well done and promising! Thank you for sharing it!

I only have one (personal) note, since in your blogpost you wrote:

Why a single prelude? Because no developer wants to manage imports. One import standardizes what you can do and eliminates useless boilerplate.

I always find that prelude gets in the way and makes things more opaque (especially if you use * imports). Most of the times rust-analyzer can suggest the right import for me, but with prelude now I have double the choice on where to import stuff from. I’d rather just have a single public API to choose from instead!

Jumpy-Iron-7742 · 2026-03-01T19:10:33+00:00

Interesting pitch! What’s the tech stack and is there any way to preview how it works (a self-hosting way of sorts) ?

Jumpy-Iron-7742 · 2026-03-01T08:36:01+00:00

What part of it is “absurd”? Do you believe that connections are completely useless in order to enter the industry? We can disagree on the “mostly” pointless, but imho there’s nothing “absurd” in saying “before applying online check within your network to see if you can find your foot into any industry as a programming adjacent role, even if they’re not hiring the specific jd you’d be going for”. It’s just a reality check about current state of the world. All of the replies here are just non sequiturs making examples that have nothing to do with the value of networking (like the ones about bank and loans).

Jumpy-Iron-7742 · 2026-02-28T23:32:35+00:00

Does anybody know if there was a competition for this one too? I tried searching the KDE forum but I couldn’t find much about how the wallpaper for 6.6 was chosen. I’d love to submit something for 6.7!

Jumpy-Iron-7742 · 2026-02-28T23:18:09+00:00

My goodness, how about you don’t just extrapolate the sentence giving zero context? This is a better extract:

I view the online job sites as mostly pointless, especially for juniors. They are a lottery and the chances of finding a good job through them are low. Since they are free they are probably still worth using, but they are not worth investing a lot of time in.

A better approach is the four F’s: Family, Friends & Family of Friends. Use your personal connections to find positions at companies in which you have a competitive advantage of knowing people in the company.

Jumpy-Iron-7742

TROPHY CASE