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
455
Joined
3 yr. ago

  • What happens when you import an library written in another language, and one of the functions is a reserved keyword in your language?

    This is already possible in Rust. You can import libraries written with different editions, and there are different reserved keywords across editions.

    The compiler just looks at what language the library was written in and switches internally based on that.

    In my C and C++ example, you'd pass different flags for that library during build time, although I'm not sure how this would work for header-only libraries.

    Edit: I see your reserved keywords example is an issue, and I raise you raw identifiers (r#if in Rust, @if in C#, etc)

    How would collaboration between people with different native languages work?

    Same way it currently does? It's not like everyone who writes code knows English, but somehow they can all write it despite the keywords being in English.

    Who makes sure all language variant have equally good educational resources?

    The community around that programming language would be responsible for this, would it not? This is already a thing people do, though it's impossible to translate all educational resources that exist into all languages. Fortunately we have services that can translate things for us though.

    There's a reason why lingua francas change over time but always exist, and forgetting that will do more harm than good.

    It would do no harm here. People already write code in many languages. In most popular programming languages, you can already name things in Korean, French, Russian, and so on. Documentation for the languages exist already in all those languages. There is literally only one thing that would change: the keywords. It's really not that complicated.

  • This might seem like an obvious question, but wouldn't it be more effective for the README to be in Korean? Not that having it in English too is a bad thing, but people interested in a language with Korean keywords probably can read Korean more comfortably than English (if they can read English at all).

    Anyway, I don't really see why PLs that support UTF-8 idents can't just reserve multiple aliases in different languages for their keywords. Rust is mentioned here, so I'll use that as an example, but Rust could just add a language field to Cargo.toml next to edition that defaults to English (which is what Rust currently uses), and that wouldn't even need a new edition as far as I'm aware. C# could do a field in the csproj file, C and C++ can use compiler flags, and so on.

  • I’m left wondering what the profession is turning into for other people.

    All the code I review looks good at first glance and makes shit up as it goes once you read into it more. We use two different HTTP libraries - one sync, one async - in our asynchronous codebase. There's a directory full of unreadable, obsolete markdown files that are essentially used as state. Most of my coworkers don't know what their own code does. The project barely works. There's tons of dead code, including dead broken code. There are barely any tests. Some tests assert true with extra steps. Documentation is full of obsolete implementation details and pointers to files that no longer exist. The README has a list of all the files in the repo at the top of it for some reason.

    I will admit that I’m more in the naysayers camp, but perhaps that’s from a fear of losing my livelihood?

    People are being laid off because of poor management and a shitty economy. No software devs are losing their jobs because AI replaced them. CEOs are just lying about that because it's convenient. If software devs truly were more effective with these tools, you'd hire more.

    Am I predisposed to see how these tools are lacking? Have I not given them a fair chance?

    That's up to you to decide. Try using them if you want. But don't force yourself to become obsessed with them. If you find yourself more productive, then that's that. If not, then you don't. It's just a tool, albeit a fallible one.

  • people are often nasty when others ask questions they assume to be stupid.

    It sounds to me like you might want to reevaluate the communities you're in. This sounds incredibly toxic.

    And I agree, for simple questions, it can be helpful. I would caution against overreliance on the answers though. Even the best models available today hallucinate regularly. Always verify answers when they are important.

    Also, learning to read documentation directly is a valuable skill to develop. Even if you don't rely on the documentation directly, reading a lot of it will make it easier to write documentation as well.

  • I think the post (well, this translation anyway) is best read as a fantasy rather than associated with reality. It's predicated on a lot of assumptions, including the assumption that AI has the ability to develop large software almost entirely autonomously, that large brands have no means to lock users within an ecosystem, that people will be able to articulate exactly the software they need and how it should be designed, and so on.

    The future being described by this post is the elimination of all roles of software and product development, spanning from developers to designers to even product managers.

    As a thought experiment, it's interesting. It shouldn't be confused as reality, though.

  • Is this even a surprise? Giving away free access to Copilot hemorrhages money and only exists to convert those users into paying customers. It costs them nothing to take away some features from these users.

    The only real ways to prevent this are local hosting (which is much more realistic these days) or an explicit contract stating that the features you want will remain for the duration of the contract. The latter is not an option with GH Copilot, as far as I'm aware, and is basically nonexistent with any modern services.

  • It looks like this was briefly touched in the article, but LLMs don't learn shit.

    If I tell you your use of a list is dumb and using a set changes the code from O(n) to O(1) and cuts out 15 lines of code, you probably won't use a list next time. You might even look into using a deque or heap.

    If your code was written by a LLM? You'll "fix" it this time (by telling your LLM to do it) and then you'll do it again next time.

    I'm sorry, but in the latter case, not only are you mentally handicapping yourself, but you're actively making the project worse in the long term, and you've got me sending out resumes because, and I mean this in the politest way possible, but go fuck yourself for wasting my time with that review.

  • "Small amount" is relative here. Not everybody needs to play Battlefield 6.

    For just programming, 8GB is way more than enough. Even my old work laptop had only 8GB and the issues didn't show up until I had multiple Office products + Teams + a browser open, not from any of my dev software.

  • Couldn't agree more here, 1k dependencies would take a while to build even on my 9950x3d if only due to linking.

    It seems to me like the the issue is the project is either too bloated, or large enough to justify a workstation build. Breaking it into smaller, independent parts would also help here.

  • 8GB RAM isn't a small amount (though by no means a lot). As far as RAM usage goes, the amount you need will scale with project+dependencies size, so for smaller projects, it shouldn't be a problem at all.

    8GB RAM doesn't tell us about the rest of your system though. What CPU do you have? Is your storage slow? Performance is affected by a lot of factors. A slow CPU will naturally run programs slower, fewer hardware threads means less running in parallel, and slower storage means that reading incremental build data and writing it could be a bottleneck.

  • Right now it's no big deal to any AI company because more code means more training for the AI, but will we get to the point that they're happy with code output enough and then turn around claiming they own those?

    At least in the US:

    The vast majority of commenters agreed that existing law is adequate in this area and that material generated wholly by AI is not copyrightable.

    So it seems unlikely that they would be able to claim any ownership.

    As for the rest of your comment (the parts around ownership): you always own the copyright for any copyrightable work you create, including code. When you post on a website, according to the ToS of that site, you're licensing your comment/code/whatever to the website (you need to for them to be able to publish your work on their website).

    Some (many, most depending on what you use) websites overlicense your work and use it for other purposes as well (like GitHub), but in the US the judges have basically ruled that AI companies can pirate whatever works they want without any attempt to license them and still be fine, so the "overlicense" bit is more of a formality at this point anyway.

  • there should be a fork of dotnet.

    Dotnet is maintained by the .NET Foundation and is entirely open source. There are thousands of forks and local clones of the repos under that organization. Rather than hoping someone does this, it'd actually be a huge benefit to everyone for you to create a local clone of the repo and update it now and then, assuming you're worried it might go down anyway.

    telemetry being totally removed

    DOTNET_CLI_TELEMETRY_OPTOUT=1, though it's lame that it's an opt-out and not opt-in. The CLI does give a fat warning on first use at least (which hilariously spams CI output). Opt-in would be so much better though, and opt-out by default is really not great.

    an alternative to nuget.org

    You can specify other package sources as well, so nothing technically stops someone from making their own alternative. That being said, you'd have to configure it for each project/solution that wants to use that registry.

    Setting such a thing up could be insurance in case they pull anything in the future, too.

    The main thing I'd be worried about here is nuget.org getting pulled. As far as I can tell, it's run by MS, not the foundation. That'd be basically the entire ecosystem gone all at once. Fortunately, it's actually super easy to create private registries that mirror packages on nuget.org, and it's actually standard practice to do this at many companies. This means that at the very least it would be possible to recover some of the registry if this happened.


    For a fork, I would think these would be the main goals I'd look for:

    • Default to opt-in for telemetry, or make it local-only. Telemetry should go to a sink owned by the forking organization if sending telemetry is even possible at all.
    • Default package registry should be one owned and maintained by the forking organization. This would be incredibly expensive though, so they'd need funding for this.
    • Organization should be independent, and not funded at all, by MS. Alternatively, MS can provide funds, but not a majority amount - instead, sponsors are limited so that no single sponsor can fund enough of the fork to have independent control over it. In either case, the goal is that no single company has enough control to shift the direction meaningfully themselves.
  • Please cite one example of Microsoft ever giving a fuck about users.

    There aren't many examples, but one that comes to mind is the adaptive controller. It's not cheap, but it's also presumably low volume, and it's unbelievably configurable.

    Outside of that, I'm out of ideas. Usually every good change comes in response to user backlash, from my experience anyway. I've moved over to Linux by now because I'm tired of dealing with what Windows has become.

  • The way it was presented with regards to search engines was that it was supposed to pull data that was more up-to-date than when the model was trained. It does do that, actually, and provides better results too, on average anyway.

    But that's just one domain, and "better" doesn't mean "good" or "accurate". In most domains, at least where I work, we've found that RAG overcomplicates things for little benefit, unfortunately.

  • The way the current systems are trained simply doesn't allow for accepting and adopting new information continuously.

    As further evidence of this, RAG was supposed to enable this. Instead, we've found that RAG was nothing more than an overused buzz-term that has limited applications, and often results in hallucination anyway.

  • Could also do this:

     rs
        
    #[expect(lint, reason = "TODO: #issue")]
    
      

    Edit: to clarify, #issue is an issue number that points to a related issue or task. Could also just explain it inline, but if you have a task tracker, better to make a task instead.

  • Is this an esolang? Could be nice for code golf maybe.

  • Removed Deleted

    Permanently Deleted

    Jump
  • Can't speak for Git, but caching responses is a common enough problem that it's built into the standard HTTP headers.

    As for building a cache, you'd want to know a few things:

    • What is a cache entry? In your case, seems to be an API response.
    • How long do cache entries live? Do they live for a fixed time (TTL cache)? Do you have a max number of cached entries before you evict entries to make space? How do you determine which entries to evict if so?
    • What will store the cache entries? It seems like you chose Git, but I don't see any reason you couldn't start simple just by using the filesystem (and depending on the complexity, optionally a SQL DB).

    You seem locked into using Git, and if that's the case, you still need to consider the second point there. Do you plan to evict cache entries? Git repos can grow unbounded in size, and it doesn't give you many options for determining what entries to keep.

  • For what it's worth, open source dev can also work. If you can commit some time to a project you care deeply about and make regular contributions, that's another form of experience, and I see no reason you couldn't add that as a line to your resume alongside any other work experience.