If I can indulge in some self-promotion, I have written mountains of code which implements many of Minecraft's behaviors down to the last detail, which may be a more interesting candidate for study:
Seeing Balze3D open-sourced might end up being pretty cool, though.
Sometimes I see people and wonder which of these two things is true:
1. They have no idea what the average developer actually is.
2. They are lying to make it sound like they were elite when they were a freshman in college.
Few people do work that transcends awful character. Very very few people. Steve Jobs is an example, but let's be honest neither you nor I will have the same level of impact to excuse ourselves after treating others terribly.
With that being said, I admire your effort to mend things and the bit of self-reflection in your response.
Bad experiences like this add up, and it's very hard to repair a broken reputation.
We should all so this more often.
I realise I'm replying in context of Sir_Cmpwn specifically (and I have had my own interaction with him in the past on unrelated projects in very sour taste) but it is more common with anybody that promotes an apologetic-but-contact-me attitude. It's an all to familiar trait of people trying to sound good in threads of their topic.
"I'm sorry for making you feel that way."
That's very close to the classical non-apology apology "I'm sorry you felt that way". 
He isn't sorry for his behavior, but sorry that his behavior caused certain feelings. The post he's responding to doesn't mention any feelings, so I assume he meant "Sorry for making you feel that you were pushed out of the scene". He's shifting the focus from his actions (for which he is responsible) to other people's feelings (for which he is not responsible, since he can't control other's feelings).
"If you want to talk, my email is in my profile."
Meaning: Please don't continue talking in public about this.
"I was a jerk the first few years I was involved in the Minecraft scene, and I'm still a jerk all too often today." is the longer sentence preceding it which is 100% a statement about his own behavior. "for making" actually makes the sentence you're quoting about his behavior too, in my interpretation of it.
It's an apology. Maybe you don't think it's a strong one, or a sincere one, or one backed up by corresponding action, but it is one acknowledging damage done, some responsibility for it, and stating a desire to change (unless you have a wildly different interpretation than I do about what, exactly, "I'm still a jerk all too often today" means.)
Also, do you remember me? :D
Nobody is perfect, you’ll always screw up with one person and succeed with another :)
> 1. They have no idea what the average developer actually is.
> 2. They are lying to make it sound like they were elite when they were a freshman in college.
Concerning 1: they might really be living in some kind of filter bubble of really smart people. Smart people often attract and are surrounded by smart people.
I went through a few repos and the result was a weirdly consistent 30-45 LOC(sans tests) daily for a 2-3 person team - at least on the front-end.
Since then I'm sceptical of opinions saying that a 1500 LOC+ project could be put together "within a weekend".
Not saying it doesn't happen, but good projects of this sort have to be rare.
Sitting at a desk for 6-8 hours every weekday with an editor in front of you has this weird demotivating effect. Add to that all the unit tests (and general need for stuff to actually work well the first time), documentation, and not being able to just run off and build what ever you feel like and you get closer to 30-45 LOC.
For a new project, 1500 LOC within a weekend sound possible if the goal is to quickly produce some kind of proof of concept. You would probably spend the following days on redesigning the whole thing, though :)
The "sans tests" metric is in my opinion some kind of cheating to keep the number small.
Let me explain: when I was younger, I was already immensely productive as a programmer. But because I was young and naive, I did not care about testing etc.
When I look at code that I produce today in my free time, I observe that the ratio between test code and normal code is about 6:1. It is similarly hard to produce good test code as it is to produce "ordinary" code.
So by demanding that the code is well-tested, we need a lot more code to solve the same job. If I multiply your upper bound of 45 LOC by my factor of 7 (= 1 + 6), I obtain 210-315 LOC/day. This is much nearer to my experience of 400-500 LOC per day. The remaining difference can be plausibly explained by experience of other team member, time for communication in the team, time for communication with customers, overhead demanded by management, ...
But I agree - a good test suite is going to be much larger than the code it's testing.
By the way, excellent work on Sway. I've been meaning to jump to i3 forever, and decided to move to Wayland on my most recent install. I do have some bug reports to send your way, though, I should get on that.
An above average freshman at an above average university can probably make Sudoku, Tetris or Brick breaker.
Even the smartest students probably won't be able to make.minecraft in a weekend. Maybe as a semester long project. But not a weekend.
Sure "theory-stuff" was often new, because of the self-taught nature of the under-graduates. (I knew what a stack was because I'd done assembly-language coding, but I had no name for something I'd "created" which was a linked-list. Funny story.)
I assume nowadays with the internet people who want to code, can start early if they wish. Even if the lure of the outdoors is strong, and time is short.
With that in mind I'd assume any first-year student could write a system for updating data-files according to simple rules, (i.e. datafixerupper), and manage a simple parsing-class of some kind which would let you tokenize and react to "/send foo bar" input.
A reasonably large tested and complete library is not a project for a few weekends but I think profunctor optics in Java actually is. And much more suitable for a xs freshman than a typical Java programmer.
Looks like nobody properly understood it yet, if it's so hard to explain what it even is.
Yes, there is also Bartosz Milewski having a go at applying category theory to explain why profunctor optics work. But that's not an essential part of understanding them: they clearly do what they are designed to do. This is programming, not physics.
Your description didn't really help me either. Lenses and prisms are just glass objects to me.
Just from thinking about lenses, I guess It could be something that bundles and unbundles function calls... But no idea.
A lens is a "functional reference". Say you have a data structure of some kind. You can create a lens which points at one of the fields. It lets you get and set that field. Because this is functional programming, when you set the field, you get given a new reference to the whole structure (can't change things in place). So, naturally the way lenses are used involves combinining a reference to a structure of type A, a lens which refers to a field within type A, and, if you are setting the field (not getting it) then you supply the new value as well.
The jury is still out on whether writing programs in this style is wise, but the notion of a lens is fixed now.
If they release their game engine, however, that's a different story...
It is an interesting case study. The code has failed to run for myself and the five other people i handed the project to with different configs. There are no tests that validate the project works. Its certainly work to be proud of, insofar as maybe its worked for some subset of people in the past.
Edit: I was excited to work on this code and spent a healthy amount of time reading through all of it to find great places to contribute. After writing a small pr, mostly a throwaway to test the waters, I was greeted with unmitigated assholery by the main devoper and their irc crew. I kept the logs from an irc conversation i had about the pr as a reminder of how not to act towards developers on projects i work on.
There are tests, though, but they only focus on the parts which are fragile or complicated:
Edit: oh, I think I remember you. If I'm right, here's your pull request and the corresponding IRC logs:
Blatant and rude sarcasm: you dont need to answer because a freshman cs student would know the answer.
So sad that it's like average second year in my school's curriculum.
I would be interested in the syllabus that building a 1:1 minecraft would teach.
So for example,
"Minecraft creates the same world each time from a fixed X Byte salt, and uses these well known algorithms for generative landscape production"
Red Blob Games has a lot of good articles covering many of these subjects, here's a few:
No unit tests in sight? Sounds about right.