janosdebugs

For OpenTofu specifically, having DI for implementing state encryption would have been really nice. Of you look at the PR, a lot of code needed to be touched because the code was entirely procedural. Of course, one could just make a global variable, but that is all sorts of awful and makes the code really hard to test efficiently. But then again, this is a 300k line project, which in my opinion is way beyond what Go is really good for. ContainerSSH with 35k+ lines was already way too big.

Yes-ish? Slices are this weird construct where they sometimes behave like references and sometimes not. When I read the explanation, it always makes sense, but when using them it doesn't. For me the rule is: don't reuse slices and don't modify them unless you are the "owner" of the slice. Appending to a slice that was returned to you from a function is usually a pretty good way to have a fun afternoon debugging.

Not the parent, but I find that doing dependency injection or defensive programming results in a lot of boilerplate. Custom error types are extemely wordy. The language also doesn't allow for storing metadata with types, only on structs as tags, which seriously hampers the ability to generate code. For example, you can't really express the concept of a slice in a slice containing an integer needing validation metadata well. You'll need to describe your data structure externally (OpenAPI, JSON schema, etc) and then generate code from that.

On the note of contributing to open source: please contribute to a project you personally use and care about.

You said you hate the industry, so I have to assume you want to build a business. Unfortunetely, people don't pay for programming skills. They pay for you to solve a problem or to entertain them. In essence, to get better at programming, you'll have to build products and solve the problems that come with them. Too many bugs? Learn testing. System crashes at night? Better monitoring, logging, etc. Features take too long? Better architecture. Algorithms and programming exercises are the easy part, productizing something, running something in production is the hard part. There is no book, course, or other material that can give you the understanding of what it means to build production-grade software. You can read countless stories on how you should write your code (clean code, TDD or whatever) and how you should operate your production system (DevOps, IaC, containers, and so on) but will this really apply to you? Doubtful. Start small, fix problems and fail a lot to learn what the true painpoints are and how to solve them. I met a lot of people who just tried to follow "current best practices" without any understanding as for the reason and the result almost always way a horrible moster of an architecture that fell over at the first sign of trouble.

Everyone with experience has their own style and preferences. For example, I like to write very defensive and modular code because I really hate chasing down bugs or getting up at night due to a production failure. Most people I meet don't like my code because writing code with that much test coverage and deliberate APIs takes time, so day-to-day I have to make compromises, but I will always push in that direction. Others push in other directions because of their own personal experiences. As long as there is communication, the end result is always worth it. However, if you were to follow only my advice, you'd likely become terribly locked in and think that programming is terribly boring. So don't listen to me, gather your own experiences and use learnings from other people to supplement your view of programming, but never let their view replace yours.

People are notoriously bad at describing their actual problems. Most of the time, they will describe their perceived solutions. What's worse, even of you get to the bottom of their problem, they won't describe their procedures that they follow day by day. This is because to them it's trivial, on the level of muscle memory, but to you as an outsider it won't even occur to ask about it unless you actually see what they are doing. By just talking to people, no matter how many hours, you'll be missing a lot of context and your product will be bad.

Be an assistant at a law firm for 3 months would presumably cut it. Domain knowledge for something like this is not optional.

You are asking for them to spend a considerabe amount of their time on you. If you wrote me a super short mesage about my field (not medicine), I might feel too that this will be 30-60 minutes of my time wasted on a likely sales call.

On the other hand, if you write me a longer message, explaining your background and position, give me all the background info, and let me answer via email, I might be more inclined to help, assuming you demonstrate that you at least have some understanding of the field.

Alternatively, you could offer to pay people for their time, which is not something sales people typically do.

I found that LLMs tends to emit training data when you ask it simple questions, such as "connect a MySQL server". In one of my experiments it emitted a StackOverflow example 1:1, including the mistakes that were made there (no/faulty error handling). Regardless if it is legal to use code in such fashion, more experienced coders tend to rewrite the code an LLM emits, so it's less likely to lead to actual problems down the line. I've seen a lot of less experienced people take LLM-generated code and use it as-is, which can lead to problems.

In case of an open source project one of the main problems with LLMs is that if a contributor does contribute infringing material, inadvertently or not, the project will be left holding the bag for it. The contributor may disappear because all that's known about them may just be an alias and an email address. This is especially true if a project doesn't have the backing of a large, well-funded organization that can fight out legal battles on behalf of the contributors. The legal situation on Internet-trained LLM usage isn't clear and I can totally understand a small, underfunded project not wanting to go up against large corporations. I think respecting the project maintainers wishes in this case is the right thing to do.

I've seen several examples where an LLM was used as a tool for accessibility (vision assistance, etc) and I do think that that's going to be one of the areas where it will be most valuable to society as a whole. Unfortunately, the legal system moves slowly and it will be a few more years until this mess gets cleaned up. I also think you are doing the right thing and I wish more people would follow your example. If a particular project deems the risk of using an LLM too high, contributors should follow the wishes of the maintainers and not contribute to that project with the usage of an LLM. Depending on the country, petitioning lawmakers may also help move the needle in the desired direction.

As helpful as it may be, AI can emit verbatim training data where the training data for the particular issue is scarce. I have, unfortunately, seen it myself in an interview take-home assignment where the solution for a particular sub-problem was 1:1 copied from a seemingly obscure chinese blog and had a completely different coding style than the rest. (The rest also had numerous inconsistencies and the solution had AI written all over it.)

For an open source project inadvertently accepting something like that may spell legal trouble long after the original contributor disappeared, so until the legal status of AI-generated code is clarified in court, there are good reasons to ask contributors to limit themselves or completely forego using an AI assistant.

That's althe funny bit, despite aria, I found in testing that some tags still behave differently with screen readers.

True, true, but we did not know this one :)

Thank you very much for this tip, we weren't actually aware that you could use the RenderingServer directly, definitely high on the list of things to test out.

Awesome, thank you, we are definitely going to take a deeper look!

It's up: https://youtu.be/Qw22utZ8IlY

OMG we love that description, that kind of summarizes the game perfectly. (Also: :waveemoji:)

I hated my wife when she made me build the textures for the reading material. I guess I was wrong. :D

Well spotted, no LLM in sight. We published an academic paper on Broomrocket[1]. Currently, it uses spaCy[2] to process the sentence into a semantic data structure and then uses the placement algorithms to create a list of volumes and placement preferences in 3D space. My wife is currently working on replacing spaCy with a custom NLP library in Rust working purely based on formal methods. This will become a larger product suite in the future.

[1]: https://dl.acm.org/doi/10.1145/3648233 [2]: https://spacy.io/

Update: we might have found a way to get the source code DLC downloaded on a Mac: https://steamcommunity.com/sharedfiles/filedetails/?id=32211...

Update: we did a little digging and there might be a way to force Steam to download the source code DLC: https://steamcommunity.com/sharedfiles/filedetails/?id=32211...

Thank you, we've done a little digging and found a way to force Steam to download the depot. We've published a guide here[1] and are currently waiting for a friend with a Mac to test it.

[1] https://steamcommunity.com/sharedfiles/filedetails/?id=32211...

Ohwow, they walked back on it. I guess their analytics were worth more after all.

Yes, the Steam version already includes a native Linux binary and we tested it on both the Steam Deck and Ubuntu 22.04. If you run into any trouble, please let us know.

Now the pressure is on, summer sale it is then.

If you want to link a high profile example, GitHub doesn't have one: https://github.blog/2020-12-17-no-cookie-for-you/

My wife was annoyed at not having released a game for almost a year and she set a hard deadline with the smallest game idea she could think of. It became fun when the game became playable and if we had to do it again, we'd focus on getting to that stage much earlier. The game was finished before the deadline, so we even had time to polish, balance the game mechanics against each other and add a touch interface for the Android release that never happened, but made it into the source code DLC anyway. Previously, we had spent way too much time switching back and forth between Unreal Engine and Godot, not being able to decide or finish anything. Kicking each other's behind to finally get it done also helped a lot.

This may or may not have a connection to reality.

Thank you for the additional confirmation. We have seen the same stats, which is why we didn't buy a Mac so far. We could build it on GitHub actions, but we wouldn't be able to test it that way. However, depending on the game, the target audience may have a higher percentage of Macs. BlockBawks, our upcoming game, may have a disproportionately higher number of Mac users who are interested in the game because it's dealing with a programming topic. Ultimately, I'm afraid you may just be right and getting a Mac Mini may not be worth it.

Thank you very much! If you have a Mac, you may have trouble downloading the source code DLC so drop us a mail if that is the case: make@something.pink

Launch sales seem to be pretty standard on Steam, you can only set it up before the release and you can't change it afterwards AFAIK.