• 0 Posts
  • 18 Comments
Joined 2 years ago
cake
Cake day: June 16th, 2023

help-circle
  • I’d say that those details that vary tend not to vary within a language and ecosystem, so a fairly dumb correlative relationship is enough to generally be fine. There’s no way to use logic to infer that it’s obvious that in language X you need to do mylist.join(string) but in language Y you need to do string.join(mylist), but it’s super easy to recognize tokens that suggest those things and a correlation to the vocabulary that matches the context.

    Rinse and repeat for things like do I need to specify type and what is the vocabulary for the best type for a numeric value, This variable that makes sense is missing a declaration, does this look to actually be a new distinct variable or just a typo of one that was declared.

    But again, I’m thinking mostly in what kind of sort of can work, my experience personally is that it’s wrong so often as to be annoying and get in the way of more traditional completion behaviors that play it safe, though with less help particularly for languages like python or javascript.





  • GPTs which claim to use a stockfish API

    Then the actual chess isn’t LLM. If you are going stockfish, then the LLM doesn’t add anything, stockfish is doing everything.

    The whole point is the marketing rage is that LLMs can do all kinds of stuff, doubling down on this with the branding of some approaches as “reasoning” models, which are roughly “similar to ‘pre-reasoning’, but forcing use of more tokens on disposable intermediate generation steps”. With this facet of LLM marketing, the promise would be that the LLM can “reason” itself through a chess game without particular enablement. In practice, people trying to feed in gobs of chess data to an LLM end up with an LLM that doesn’t even comply to the rules of the game, let alone provide reasonable competitive responses to an oppone.





  • incorrect behavior that doesn’t even have the courtesy to throw an actual error.

    To be fair, this can be said of C. A C executable only really forces a crash out when you royally screw up beyond the bounds of your memory. Otherwise functions just return a negative value and calling code that never bothers to check just keep on going.

    Golang is similar, slightly mitigated that if you are assigning any return value from a function, you must also explicitly receive an error and you know full well that you are being lazy if you don’t handle it. Well unless you use a panic/recover scheme but golang community will skewer you alive for casually suggesting that and certainly third party libraries aren’t going to do it that way.


  • Could I write a compiler in C that does this check on a piece of Rust code?

    Well yes, but that code has to be written in Rust. The human has to follow rules to give the compiler a chance to check things.

    C is so simplictic, that if I can write a piece of functionality in C, I must understand its inner workings fully. Not just how to use the feature, but how the feature works under the hood.

    I don’t think that’s particularly more true of C than Rust or even Golang. In C you are frequently making function calls anyway for the real fun stuff. If you ever compile a “simplistic” chunk of C code that you think is obvious how it would compile to assembly and you open up the assembly output, you are likely to be very surprised with what the compiler chose to do. I’ve seen some professional C developers that never actually had a reason to fully understand how the stack works, since C abstracts that away and the implications of the stack don’t matter until you exceed some limitations.




  • Unfortunately, the ecosystem around github has evolved so that most folks centralize their testing and deployment code into being executed on github infrastructure. Frankly a perversion of the decentralized design of git.

    Fortunately for my team, it doesn’t matter because our process requires stuff that can’t be done from github infrastructure anyway, so we have kept the automatic testing and deployment on premise even as github is the ‘canonical’ place for the code to live.



  • From what I call, the advocates kept saying:

    • OnLive was just too soon, the internet needed to be better
    • Google had just so much more resources at their disposal they could make it happen

    Of course, no one ever explained why I would want to pay full price for a game and also have to pay a monthly fee to access it once purchased, which was the most mind boggling facet of Google’s concept to me, even more boggling than trying to make games render server side when the cheapest end user device can just locally render PS3, maybe PS4 level graphics nowadays.




  • There’s not particularly good reason to stop doing it in that scenario either.

    You have an offline technology stack in that elevator that has been doing the job correctly for 20 years. Why take on the expense and risk of changing things that aren’t currently broken?

    It would be crazy if you are building new to resort to that stack, but for an established elevator, why bother?

    Same for some old oscilloscopes at work. I’m not crazy about the choice but I can hardly suggest it would be practical to change it while the oscilloscopes still do their function.

    I would say it’s a problem if the stack is online, but if it is self contained, the age of the software doesn’t make it a problem in and out itself.