Exactly this. The non-composability and non-standardization of GUI tooling is my main issue with them ; having the same toolkit available to solve every problem takes some doing but is ultimately more efficient.
That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.
Floating point value stored multiplied by 10^8. That gives you a huge integer, but it's extremely accurate, especially for US denominated currencies. Easily transformed into floating point numbers for reporting/etc.
One of the reasons why a source-based system like Gentoo is particularly nice is that you can compile your binaries with debug flags, so if you hit bad behavior you can inspect, write a patch, compile into your running system, and then push the same patch upstream.
I barely have to do it, but imho, this is how software should work and what running a computer should feel like.
I think the "net" does a lot of heavy lifting for a box like this - e.g. you do all the important work on a remote server, and only do basic maintenance work on the laptop itself.
4.8 also seems like a regression and using it from the chat GUI results in 4.6 no longer showing up. If someone from anthropic is here, is it possible to readd 4.6 in the "other models" dropdown ? I feel like I got a bit baited/switched here.
I think it's just nice to have things in a central place ; no one's really gotten decentralized tech right and things like discoverability, interaction, job running, etc. is really nice to have in one place.
Mastodon and email are the closest I've felt to a distributed system that works, but for oss stuff ... I think we're getting closer, but it's still a very hard problem to solve.
Opus definitely pushes me to ignore problems. I've had to tell it multiple times to be thorough, and we tend to go back and forth a few times every time that happens. :)
There's something interesting I've found about my interactions with the AI - I use it as a thought-partner. I don't ask it to solve a problem for me (well, first at least!) I think about it as a tool to work with, engage with the problem, and spit out a result that I then test and review.
I see it as part of the feedback loop, and it speeds up some of the mechanical drudgery, while not removing any of the semantic problems inherent in problem solving. In other words, there's things machines are good at, and things humans are good at - if we each stick to our strengths, we can move incredibly fast.
I agree with this. I've been able to tackle projects I've been wanting to for ages with LLMs because they let me focus on abstractions first and get over the friction of starting the project.
Once I get my footing, I can use them to generate more and more specialized code and ultimately get to a place where the code is good.
I appreciate this way of programming - also, if I may, in the age of auto-complete I think it's okay to have verbose variable naming. Imho, it's perfectly fine to have quad, quadVelocity, dragMagnitude, etc.
I see this a lot in the wild, though - as an honest question (not trolling!) why do people still shorten their variable names in place of having a terse descriptor ?
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.
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.
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.
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.
That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.