Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)T
Posts
0
Comments
451
Joined
3 yr. ago

  • 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.

  • AI is used to various extents:

    • Some projects do not use AI. The quality of the project is a direct output of the skill and experience of its developers.
    • Some projects use AI lightly. Where AI is used, developers review the output, and it's not trusted to produce large features or even code at all in some cases.
    • Some projects use AI heavily. These projects generally adopt "move fast and break things" mentality which naturally means they both move fast and break things.
    • Some projects are pretty much entirely AI generated. These projects adopt the "break things" mentality. It's like watching someone jogging in place fall over and break both of their legs, and in the process crush someone's pet.

    For a file manager, I would be careful how much I trust AI output.

  • 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.

  • Is it good despite the LLM marketing on the front page? That turns me away whenever I look at it, but I'd be willing to try it if it doesn't shove LLMs down my throat.

  • Of course there's a command for that.

  • 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.

  • I got linked this somewhere else and made it about halfway. Skip the video, go to the bottom of the description, and open the sources list. You're better off just reading those directly.

  • The other problem with subsizing it is that Valve is currently in a price fixing lawsuit and selling a new product for a huge loss probably wouldn't look great for them.

  • And yet this is tame for him.

    It's best when reading his creative prose to extract the meat of it and do your best to ignore the rest. His choice of words is crude at best, but at least he's also suggesting improvements with them rather than just spewing expletives for the sake of it.

    It's by far his biggest flaw, but also one that he's acknowledged and worked on over time at least.

  • 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...

  • Gatekeep (v.):

    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.