TehPers

The high-level directory structure looks reasonable, but every language and build tool has its own recommended structure that people should use instead. For example, by default, cargo looks for a src/main.rs or src/lib.rs as an entrypoint. uv expects one of a couple different project structures before you need to touch the pyproject.toml. C# will create namespaces for each of these nested subdirectories if you don’t carefully configure it in your .csproj file. And so on.

It’s best to just use whatever’s recommended for your environment by your tools. Maybe this directory structure works well for Guile Scheme, but I wouldn’t touch it at all if I were writing Rust.

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.

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.