I wouldn’t take it as far as paying allows demands.
Neither would I.
Paying implies exchanging money for something the other party is selling, and would require the other party (the maintainer) to sell it. Shoving $20 in someone’s face is a donation, not a payment.
I just refused donations for myself. I would never claim a donation gives someone any special right to demand something.
Having been on the maintainer side of a popular project once before, I’ve pretty much just taken the mindset of “if you owe them nothing, then they owe you nothing”. Basically, pay them, or stop making demands (though suggestions and bug reports are usually welcome by maintainers).
Incidentally, this is why I didn’t accept donations for that project (though I have nothing against donations in general, of course). I didn’t want to even feel a sense of responsibility to maintain a project I knew I’d eventually burn out from.
If you know a faster/better way to sort byte arrays in Java/Clojure let me know!
I don’t know much Clojure, but this should be doable in Java. I would be interested in seeing the results of sorting the data via both quicksort and heap sort. I’m not sure what sort Clojure defaults to, but if the distribution of IDs is uniform, then I’d imagine the downsides of heap sort are pretty much universal to all sorts you’re likely to use, which makes it more interesting here to me.
At the very least, Clojure’s docs seem to say that sort is stable, which isn’t needed here (we know all IDs are unique). You can probably gain performance just by switching to a performant unstable sort, just in general.
With computer languages, we define colors with red, blue, and green.
It’s actually more complicated than this. We specify a color space, then define the color through parameters relevant to that color space. For example, it’s not uncommon to define a color in CSS in Oklab, which could look like 40.1% lightness at (0.1143, 0.045). It’s also common to define colors relative to other colors. Color space is also not just “well this value maps to this other value in RGB”. Different color spaces represent different spectrums of visible light, and you can represent colors in one space that you can’t in another space.
So “when does green become black” is even more complicated to answer.
Ambiguity is a bitch. Usually when it comes down to “is this color X or Y”, the follow-up question is “does the foreground have a contrast ratio of at least 4.5:1 against the background”. If not, then whether the color is X or Y doesn’t matter. You need a different color.
Anyway, natural language does not map well to machine code. There’s too much ambiguity, and you lose out on the chance to answer the questions you didn’t specify answers to that come up when actually writing the code yourself. An interactive approach would take just as much effort as just writing the code itself.
Imagine this: instead of reading other people’s code and then trying to parse their intentions form [sic] it, you read the documentation to understand their intentions and then you read the code. You no longer have to strain yourself trying to understand what someone wrote for another audience (the machine). They’ve already explained it for you.
The best implementation of this I’m aware of is the Entangled bi-directional tangler. A tangler extracts code from your documentation and distributes it across the appropriate source code files. It’s [sic] bidirectionality means you can use it to write code embedded in documentation, but then also edit that code normally which it then propagates back into the code blocks in the documentation. This allows programmers to use existing tooling for testing, refactoring, and code formatting without special support for literate programming.
The best built-in implementation for this that I’ve seen is Rust’s doctests. You write a block of code in your documentation. Then you run cargo test. The code gets compiled and executed as part of your tests, and panics get reported as failures. You can also mark code blocks as should_panic, compile_fail, ignore, etc if needed.
I’d love to see tools like this in other languages. Write the docs next to the code, but compile the docs as well and make sure they actually work. This is sort of what Entangled seems to do, but ideally more entangled with the build process.
it may be underestimating how tightly coupled syntax and language is.
From a CS perspective, syntax is a major part of a programming language. A syntax (or formal language) is defined essentially as an alphabet and the sequences of words constructed from that alphabet that are allowed in the language. Programming languages combine the syntax, which can be defined formally through BNF (for example), with the semantics they enforce. Semantics include things like “types”, “modules”, or even “lifetimes” potentially.
Where you can try to decouple it is between the syntax and the semantics. In fact, this is not without precedent. For example, the JVM and the CLR both allow arbitrary syntaxes to be compiled and executed on them, and both have many languages that can be seamlessly integrated together that all compile to the same intermediate representation. Here’s a project compiling Rust to the CLR if you want an extreme example, though more practical examples for the CLR would be C#, F#, and Visual Basic (which can all use each other’s defined types, methods, etc).
So basically, what you might be looking for is a common “intermediate language” for languages. We actually have one already though, and that’s the C ABI. I think a better ABI could exist though, ideally one which allows more information to be shared across boundaries. Still, that’s where I’d start looking more into this, maybe with inspiration from the JVM or CLR.
The row-level locking and SKIP LOCKED seem like appropriate features for a SQL-based DBMS. I find it odd that it’s not more common, actually. Even MSSQL doesn’t make any promises about locking just a row and might decide to lock a whole page instead, from what I read anyway.
NOTIFY/LISTEN might be scope creep though. I’m not really sure what led to it being implemented.
Not a TUI (unless you count shells as TUIs), but if you use Nushell, you can also query SQLite directly from Nushell.
Anyway, I love how this looks. It’s simple and stays out of your way.
I swear Postgres always has new features whenever I look at it again.
I was building a system for long running durable job queues with multiple workers and of course Postgres has a solution for that. You can do row-level locking in a transaction to “reserve” jobs for the duration of that transaction, and you can use SKIP LOCKED to skip over reserved jobs so workers don’t block each other. There’s also LISTEN and NOTIFY if you want pub/sub to track when jobs complete, for example.
While I like the goal of this, why not errata the existing spec to allow GET requests to have bodies? Would that be too much of a breaking change?
I also want to add that Nix gives you the ability to do this at the tooling level. While I’m not going to say everyone should go install Nix, do seriously consider that or devcontainers or some other kind of solution to ensure that you don’t get hit by tools you rely on becoming compromised suddenly (PSA: if you use AUR, seriously read that thread). As long as you can pin a specific version of each tool you use, whether by creating a shared image, by pinning a nixpkgs commit, or whatever, you shouldn’t have anything suddenly change on you.
For me, it’s not about reaching zero dependencies. But having dependencies that we cautiously agreed upon.
The following section about SBOMs covers what I’m about to say, but I want to add to it. Most (all?) major ecosystems include lockfiles that let you control exact dependency versions and look at them. Always be explicit when updating the lockfile.
What do you find hard about it?
For me, what made it take so long to learn and really understand was that it’s different from most modern programming languages. It’s not C, C++, or based on my own experiences, C#, JS, Java, etc. Approaching the language as someone who’s really into C# made it difficult to throw away that experience to learn something completely new, whether because I now had to wrap my head around lifetimes or because I can’t have one type inherit the fields and methods of another.
Eventually, if you keep sticking to it (and have interest to do so), you’ll learn how the language was designed to be used, and why it was designed that way.
Reading source code is your friend, by the way. If you want to learn the language, you should spend at least as much time reading code others have written as you also spend writing code. This can be as simple as “go to definition” on some imported function from a library you’re using. Try to understand how that code works, and eventually you’ll even begin to form opinions on what works well vs. what doesn’t. Heck, you might find yourself opening PRs against something like Tauri in no time.
From the author’s own website, they left AWS to join their current company as VP of Software (whatever that title means but seems obvious that it’s software related). My immediate assumption would not be that this person is clueless about software development. Maybe they are, but assuming that from the start is just engaging in bad faith.
Refusing to engage with someone is not gatekeeping.
You show up to a party and talk to a group talking about using LLMs to make software to try to make friends. They look at you. You are a developer, but you don’t specifically work in financial services so they just ignore you. In fact, they say out loud at the party “hey you don’t know jack shit about anything because you don’t work in financial services”. The whole discussion they’re having has nothing to do with financial services.
You don’t consider that gatekeeping?
Also, I think their point was not that AGI will never happen, it’s more that it doesn’t matter whether it happens or not, because AI/AGI will not solve our problems
This exactly. AGI can never solve people problems because those problems are inherent to people. Social problems, for example, don’t magically disappear because you have a magic box that does everything.
I think we are further from AGI than people think. I doubt I will live to see it.
I would go far enough as to say that most people alive, if not all, definitely won’t see AGI in their lifetime. That’s of course besides the point, but still…
to restrict access to (something of value, such as information, knowledge, or resources) in order to exert power or control over a person or group
The person I was responding to was restricting the author’s access to the conversation by publicly refusing to engage with them over a trivial, irrelevant matter. So if that’s not gatekeeping, then clearly they’re calling the author a clueless idiot, which is just plain rude.
This is literally the premise of the article.
The person I responded to stopped reading because the author doesn’t have specific domain knowledge of financial services.
So someone who isn’t an expert in implementing financial services isn’t allowed entry into a discussion about LLMs in software develoment? Weird gate to keep, but sure.
I could see “well this doesn’t apply to the financial space” as an argument, though I wouldn’t really buy that in this case. But “fuck off you don’t have the specific domain knowledge of this other dude” is a weird bar to set.
I actually did. The GitHub mobile app conveniently leaves that out unless you open the commit directly:
You also own it from a copyright perspective. Any code you write yourself is your own, and GitHub is only given a license to use it when you choose to upload it there (and if you use GH Copilot I guess). You are free to copy and distribute your own code however you want with no regard to anybody else’s wishes. You may even choose to charge money for access to your code if you want.
The two are completely incomparable. Still, it’s a well-deserved jab at Sony, though somewhat of a pot-and-kettle situation when accounting for MS as a whole.