• 0 Posts
  • 29 Comments
Joined 5 years ago
cake
Cake day: May 31st, 2020

help-circle
  • There can also be circumstances where you have to offer people a natural-looking key for general consumption. You can’t put UUID’s on car plates for example.

    Often times, the first section of the UUID is unique enough. With certain UI design choices, one can encourage users to normally work with that, while having the full UUID available in a detail view or from a copy-button.

    Another strategy I quite like, is to have the UUID as the definitely-always-unique identifier, and then have a separate name, which either the users can enter or we generate something like random adjective+animal.

    But yes, neither of those strategies would work for car plates.


  • Hmm, interesting idea, to ask the user to provide the overall intent by making them edit/write the plan, since the LLM can’t do intent.

    But man, we’ve recently had a number of programming beginners join us in our relatively large codebase, and I’ve basically had to write such a plan, i.e. step-by-step instructions, for them many times.

    It just means that I go through the whole codebase and have to think everything through, without doing it myself.
    It often took similarly long do that, and formulate instructions, as it would have taken me to write the code myself. Because obviously we’re using a high-level programming language, so there’s not many detail problems which are easier to describe in a natural language.

    It’s also incredibly difficult to provide correct instructions that way, since I don’t get to read the existing code while I write the code.
    And reviewing their code to figure out what came from it, that binds even more time.

    So, yeah, it really doesn’t sound like this LLM thing would save me time either…







  • Well, the alternative to “Rust” here is not another programming language, but rather another game engine.

    Because ultimately, most game engines will be implemented in either C++ or Rust, for performance reasons, and C++ itself isn’t terribly better at iteration speed than Rust.

    The C++ engines have simply already invested decades into abstractions, like an ECS architecture, higher-level APIs and scripting languages. There’s nothing inherent to Rust which prevents these abstractions from being built into game engines, it just hasn’t been around for that long.



  • It’s quite common for LLMs to make use of agents for retrieving factual information, because the text processing is just garbage for that.

    For example, basic maths is not something you can do with just text generation.
    So, you hook up some API or similar and then tell the LLM before the user prompt: “For calculating maths, send it to the API at https://example.com/calc and use the response as a result.”

    The LLM can figure out the semantics, so if the user asks to “compute” something or just writes “3 + 5”, it will recognize that this is maths and it will usually make the right decision to use the API provided.

    Obviously, the specifics will be a bit more complex. You might need to give it an OpenAPI definition and tell it to generate an OpenAPI-compatible request, or maybe even offer it a simple script that it can just pass the “3 + 5” to and that does the request.
    Basically, the more work you take away from the LLM, the more reliable everything will work.

    It’s also quite common to tell your LLM to just send the prompt to Google/Bing/whatever Search and then use the first 5 results as the basis for its response. This is especially necessary for recent information.



  • Ephera@lemmy.mltoProgramming@programming.dev...
    link
    fedilink
    arrow-up
    3
    ·
    8 months ago

    Yeah, my word choice was quite deliberate there, because there’s this other full-fledged programming language, which is also often less verbose than PowerShell, called Microsoft Java C#.

    There is some nuances, which don’t make this quite as hard-cut, but in far too many cases, PowerShell is just an objectively worse choice than C#.

    (And I’m not saying that C# is a particularly good choice, but since it can also make use of the .NET APIs, it is particularly easy to argue that it’s better than PowerShell.)


  • Ephera@lemmy.mltoProgramming@programming.dev...
    link
    fedilink
    arrow-up
    9
    ·
    8 months ago

    I’m mainly annoyed by Scala not being more popular, because Kotlin is popular (obviously for political reasons) and I really don’t feel like it’s simpler.
    Namely, it implements a similar number of features, but because it’s not yet as mature of a language, there’s tons of weird rules how you can’t use these features, because they basically haven’t implemented that yet.





  • Hmm, interesting. The documentation tells me, it creates a new Option value, and allocating memory every time someone just wants to look at a value could be pretty bad.

    But I guess, an Option of a reference never needs to allocate memory, because it’ll either be a pointer to a value (Some) or a pointer to null (None). Right?

    Well, that explains why it’s technically possible.
    As for why Option<&str> is preferrable then:
    It hides away your internals. Your caller should only care whether they can get the value or not (Some vs. None), not what the precise reason is. That reason or your internal structure might change.

    @larix


  • Ephera@lemmy.mltoRust@programming.devsince: my first project
    link
    fedilink
    arrow-up
    21
    ·
    edit-2
    8 months ago

    I took a very quick look at the code and one thing I noticed, is that you’re using &String.

    For a parameter in a function, you always want to use &str instead, as explained here: https://doc.rust-lang.org/book/ch04-03-slices.html#string-slices-as-parameters

    I believe, it’s also not a thing to return &String (nor to store it in a struct). I don’t have as solid of an explanation for it, it’s just not something I see much in Rust code (and in the chapter above, they do use a &str as return value, too).
    Maybe someone else can weigh in on that.

    The same applies for:

    • &[] rather than &Vec
    • &Path rather than &PathBuf
    • &OsStr rather than &OsString

    I would also recommend using Clippy. I think, you can just run cargo clippy and it’ll work.
    It’s a linter and will tell you lots of code style issues (like using &String as a parameter).
    If you’ve never run it, it might spit out a lot of warnings at first, but working through them can teach you quite some things.