Currently working on a code formatter and parser for Supercollider's sclang.
Supercollider is an amazing language, but the development tooling is severely lacking - we need good tooling, and now with LLMs in play and my coding ability leveled up from doing GATech's OMSCS, I'm finally able to tackle this.
I'm learning rust while I'm doing this too, so it's been an experience. Fun, though.
This isn't made by developers, that's clear, and I don't think it's going to be very functional. However, I do love the aesthetic and I do love that someone is trying something new.
By new you mean they’re making a 1980s all-in-one keyboard/computer with the 10 key on the wrong side of the keyboard running a version of a familiar-to-most-of-us OS that isn’t at all new looking?
I’m sorry; none of this is new to me except the absurd price tag.
While I agree with your general sentiment, the 10 key being on the "wrong" side could be good, perhaps, in some cases?
Historically I've done some heavy spreadsheet work where the resting position of my hands which minimizes movement is right hand on the mouse, left hand on the 10 keys. On a normal keyboard that has the disadvantage of causing a "closed" posture which isn't entirely comfortable.
Outside of that kind of niche use case though, it definitely feels like a strange choice for developers.
10,000% this. Attaching JIRA tickets, etc. to the commit helps for searching as well. I've worked with a number of people who do not believe in this and it drives me insane ; I try to enforce it, but there's a lot of messages like "fixed bug" that have zero context or detail associated with them.
I don't understand why so many engineers are like this.
Attaching JIRA issues makes a ton of sense for features that are described in JIRA. If we're talking about a bug that was found by a developer, unmotivated by a ticket, it would generally make more sense to just describe the bug directly in the commit message. This is of course not true if the JIRA tickets are used for something else downstream, like informing users of fixed bugs, or tracking changes.
The other issue with tagging JIRA tickets is that junior developers will believe that to be enough (you can just read the ticket) and wont understand why they need to describe the change from a technical angle, when it's already described in JIRA.
Commit messages are immutable. Linking them to a bug ticket gives you a mutable place to record any new information about the bug that you discover in the future. (For example, that it affected more cases than you originally thought, or that the fix caused another bug.) This new information will be discoverable when starting from the original commit (found e.g. by doing a blame on a particular line of source).
To fail to do so is a gigantic missed opportunity in my opinion. You never know when you will need it.
Attaching ticket numbers has always been enforced by automated checks wherever I have worked, so it is not necessary to “try” to enforce it.
Similarly with AI it is fairly simple to have eg a pre-merge check that validates the commit msg is somewhat useful. This could be implemented for example with GitHub org level checks that must run in a PR.
My preferred way of doing PRs/Code Review echoes some of the statements below, but also requires the engineer to do the following:
1) Each PR (even if it's part of a larger whole) can be committed and released independently.
2) Each PR has a description of what it's doing, why it's doing what it's doing, and if it's part of a larger whole, how it fits into the broader narrative.
3) PRs are focused - meaning that QOL or minor bugfixes should not be part of a change that is tackling something else.
4) PRs are as small as possible to cover the issue at hand.
5) All PRs are tested and testing evidence is presented.
6) When a PR is committed to master, the final narrative in step 1) is the Git commit, along with the testing evidence, includes the JIRA ticket number in the headline, and the reviewer in the body of the git commit.
This way we have a clean, auditable, searchable history with meaningful commit history that can help reconstruct the narrative of a change and be used as a guide when looking at a change in, say, a year.
I agree with this up to a point - having consistent code style with some sort of formatter (gofmt, black, clang-format) goes a long way to reducing complexity of understanding because it unifies visual style.
I suggest that a codebase should read like a newspaper. While there is room for op-eds in the paper, it's not all op-eds, everything else should read as a single voice.
My experience is that projects which value code formatters (and similar rulemaking) tend strongly not to have room for "op-eds", FWIW. And conversely the code bases I've seen with the best/cleanest/most-clearly-expressive code tend strongly to be the ones with fewer rules.
I think the one exception there is in some open source contexts (Linux is the archetype) which receive a fire hose of submissions of questionable quality and maintainership. There, you can use adherence to arbitrary rules as a proxy measurement[1] for attention and effort on the part of the submitter. And that I have no problem with.
But the actual value of code formatters is IMHO extremely low in practice, and the cost isn't "high", but is non-trivial.
I get this a bit at my job, and I think there's a difference between making changes (which I do a lot of) and being confident in the changes that you're making. The environment I'm in is completely fault-intolerant, and we're currently hamstrung by our hardware (e.g. no backups/no secondaries/etc.) so changes that we're making have to be well-reasoned and argued before they're put in.
Some people take that as being scared, but it's more like "you have to have made this work and tested it before putting it in."
Agreed. So long as the code hits performance and business goals, there doesn't need to be an emphasis put on "newness" or any other sort of vanity metric - make the code obvious, searchable, and understandable so that in a time crunch or during an outage it's easy to search and find the culprit.
despite the questionable politics of the author, I use mutt-wizard, and using its configs, a simple "v" instead of "o" will open the mail in the open web-browser. I've found this more than acceptable for reading html mail.
I don't use it for work, only personal use, though, so ymmv.
Do you feel like you shouldn't use it because of the author's politics? It's not like he gains anything from you using it. Even if he gained money from it I don't think there's any reason to believe he'd use that money to further those political opinions.
Noticeably it doesn't export Wayland to applications running underneath unless you enable an experimental flag, and half the reason for its existence is that it can be entirely bypassed by related Vulkan layer extension.
For me, the year of Linux on the Desktop was '94. It's been my main desktop at home ever since, and for wor as well the majority of time - but with some obnoxious detours.
Not advocating for 2024 (or 2025) but I still think someday it will, having seen multiple usability and feature improvements. (Not only talking about wayland here)
I'm learning rust while I'm doing this too, so it's been an experience. Fun, though.