HN user
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. :)
I don't understand how the unix philosophy is rigid ? Can you explain a bit more ?
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.
Tangential - what do people do faster in vscode than on the terminal ?
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.
TEX Shinobi - I have many of these and they are excellent: https://tex.com.tw/products/shinobi?srsltid=AfmBOoqVuwqI9Ot2...
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.
I haven't yet seen any compelling reason to move off of X11. It's been years since I've checked - what's the current state of the art ?
Or, even, "I see X Y Z is happening, that doesn't seem in line with the question, can we discuss it further ? "
I go a step further on "dumb code". Write code that is easy to reason about, understand, and grok the implications of.
I spent a ton of time doing support and engineering on a trading desk, where our SLA for an outage was somewhere in the range of 30 seconds to 5 minutes. Having super simple code that makes it easy to understand what the code problem is (if not necessarily the business problem) lets you move on with life and let the business keep moving.
The truth is that most companies won't pay for the extra productivity that you create for yourself, but they will happily take it for free.
Fantastic way of putting it. Know this is a low-effort comment, but that's a great way to describe why over-extending yourself outside of the context of the overall mission isn't a good thing to do.
Agreed with the sibling posts. Ubuntu isn't a great experience - it feels seamless until it breaks, and then it's just a world of pain.
Debian/Mint/etc. are all good distros, but if you're willing to step up the learning curve just a bit, I'd definitely suggest Gentoo. I've been using it as my daily driver for several years now and it's made me feel like I'm actually in control of my machine (compiling all your code with debug flags so you can attach gdb when it's behaving weird so you can write a patch?! And then submit it to get sucked into upstream!? Yes please!). There's definitely a little work up front, but it's without a doubt the best experience I've had with Linux and I'd recommend it if you're up for it.
There's some of these that I think are overkill, sure, but I like the simplicity of some of them - sidenotes, progress bar, etc. Just little things that give you that much more information about what's going on. Gwern's page, to me, is too much.
My personal favorite mixture of style and implementation of these features is jefftk.com - simple, fast, but gives a ton of information in an unobtrusive way.
That's right. You have a prefix that lets you use page up page down in any pane you've got currently selected.
It's about modal editing and the editing commands/paradigm inherent in that.
Agreed with the siblings, you're describing emacs! :)