Does anyone really get something useful from this text?
I thought it's something at the level of "Designing Virtual Worlds" by Richard Bartle, but it's just a set of statements like "level should have an entry and the exit" and "don't do bad maps", for some reason labelled "theories", heavily pierced with phrases like "ummm, hard to explain".
You would be surprised how many new mappers don't include a clear exit in their levels.
> heavily pierced with phrases like "ummm, hard to explain".
Good vs bad level design is always subjective as is generally the case in design, for example what is experienced as good or bad it is dependent on the preferences and the experience of the player, perhaps even the setting (competitive vs casual).
In level-design what quantifies a "good level" is very dependent on the game-design decisions learning this is very important to make good levels. For example even q1 and q2 differ in what is good design due to the technical differences of the two games (full 3d rendering in q2) good q1 levels are more fast pace "run and gun" while q2 enemies force a more tactical approach (they take more shots to kill). Even though some of the qualities of good design also overlap between several games, for example there is a overlap in all FPS game levels. Even in the same game multiplayer vs singleplayer maps have very different requirements.
> And for my next trick, I shall <drum roll> attempt to... </dr> ...define the undefinable!!!
While perhaps not perfect I think this article indicates some of the common pitfalls for inexperienced mappers. This is important especially for beginning mappers as it will allow them to grow a sense of good vs bad design quickly.
I think the author also didn't come up with these requirements out of nowhere, these are echoed throughout the (quake) mapping community and I think it is a good effort to put it into text and allow discussion for this particular game.
I didn't read. One issue with BYD (outside of the quality level of the article, which, as I stated, I didn't read) is that they are government subsidized. The bigger issue, that I've read about at least, is that they phone home to China.I don't want my car phoning any data to anywhere, even here in the U.S. I had a car that definitely was phoning home to Hyundai, and I had to sell it for unrelated reasons. I now share a dumb car with my spouse and while I hate having "dumb" features, I silently do a small happy dance since that is one less way I can be tracked (license plate readers and other such tech also happen to be illegal/not a thing here)
I also use an eScooter which is dumb as a brick locally, so definitely doing a double happy dance.
Literally the simplest way to deal with errors (cognitively and character wise). Since AI autocomplete entered the scene, typing this repetitive (for a reason) pattern became not a problem at all (I'm not even talking about post Claude Code era)
> The only resort the consumer of this library has is to parse the string value of this error for useful information.
> typing this repetitive (for a reason) pattern became not a problem at all
Code is read 10x more than it is written. The noise this pattern introduces inhibits reading and rapid comprehension.
Things are getting marginally better now that go has errors.Is and errors.As, and also now that go is starting to get some functional iterators. But go is one of the least quickly-understandable of the modern languages currently in use.
Here is the thing... it's NOT a 'noise'. Untill you see handling 'error path' as noise, you will be trapped in searching magic bullet language solution to hide it. We've all been there.
Your last sentence makes sense only if you consider “happy path” to be what you call “understanding how function works”. A lot of programmers are annoyed that Go forces them to think about “error path” as equally important. Later many say that Go forces you to be the better programmer. But it takes time. In any case, saying “language has a problem” is a wrong frame for thinking about this design choice.
This is something gophers constantly repeat, but it is entirely a self-inflicted issue that other languages more modern than C don’t actually struggle with.
When in Rust, it is explicitly clear when and where errors can come up, and what types of errors I have to deal with. It is far less clear in golang, since there is no help from the type system when I’m using errors.Is and errors.As. Not being verbose doesn’t make error handling any less explicit.
Nobody is upset about having to pay attention to the unhappy path. This is entirely a straw man that gophers fall back to in order to feel like they’re somehow enlightened, shut down conversation, and to avoid having to consider what other people are saying. We are desperately hoping to help you realize that there are other, better ways that don’t come at the ridiculous readability costs inflicted by the anemic golang approach.
It really is okay to stop making excuses and accept that your preferred language has warts. I promise. Nobody will think less of you.
That's not a straw man, it's a valid reply to your first argument about "error handling code being an obstacle to understanding how function works". Why it makes you angry and makes you resort to ad hominem, I don't know, but that's clearly the end of the discussion.
No, it is a knee-jerk response that invariably assumes that a belief that golang’s specific approach is bad is equivalent to believing that errors are of secondary importance, and assumes that anyone who disagrees with the golang approach just doesn’t get how important it is to deal with errors.
You would rather dismiss other perspectives out of hand than actually reflect on how your chosen language might evolve.
In my perspective, this has been the entire historical progression of golang. Everyone vehemently denies that there’s a problem, eventually the language authors address it, and then everyone insists that it’s always been known that they needed to deal with the issue.
I don’t know why this seems to be so endemic to the golang community. Other languages’ adherents seem more than willing to accept the shortcomings of their preferred tools. But gophers continually insist that all the problems are actually strengths right up until it’s fixed and then they retcon their previous beliefs. It’s extremely off-putting.
The only knee-jerking here is this: "When it takes five times as long to figure out how a function actually works".
Don't be surprised by receiving low quality responses when you start off the discussion with ridiculous hyperboles and show poor understanding of the issue at hand.
>> difficulty of writing if err != nil
>Literally the simplest way to deal with errors (cognitively and character wise). Since AI autocomplete entered the scene, typing this repetitive (for a reason) pattern became not a problem at all (I'm not even talking about post Claude Code era)
I agree with you. I don't have problems with the `if err!=nil` syntax.
From my post:
> It’s become something of a meme to bemoan the supposed difficulty of writing if err != nil. I actually won’t make that point because I think it is a very surface level point that has been talked about to death and *I don’t think the ‘verbosity’ of this code snippet is such an issue.*
I apologize if my language was ambiguous on whether or whether not I had a problem with that syntax.
>In his example author could easily use his `progError` type instead.
I agree, but it was my impression that type erasure was more idiomatic. I should have made it clear that I was criticizing that idiom, not the language.
You are right. I should have done my research on that before writing that point. I still think that downcasting isn't the most elegant solution because it defeats the point of using the opaque return type but I agree that it is nowhere near as much of a problem as I thought it was.
The simplest thing is not to do anything but defer to caller to handle it, in languages like Python, Java, JavaScript. Often that is also the only realistic way to an error, especially for library code.
To be fair, the author says it's the "_supposed_ difficulty of writing err != nil" and says that the verbosity isn't an issue here. But he also earlier says that he "[hates] having to write pub all the time in Rust" to denote public visibilities. So typing seven extra characters in one place = tolerable, but four extra characters elsewhere = detestable
Writing `pub` is personally more annoying to me than writing `if err != nil`. I understand that most people don't like how capitalization determines visibility, but I think it actually makes sense when you think about it.
"Quake Brutalist Jam III was created for explicit use with the Ironwail source port, version 0.8.1 and above. If using other engines, especially the Quake Remaster, expect issues."
Tackling layer of complexity often feels like this. I remember 2010 and my frustration of evergrowing complexity of networking backend programming (C++ mainly), and discovering Go. "Go made programming fun again" was a common phrase at the conferences back then.
I feel similar with web-apps development too, except we're not solving complexity here – we just outsorcing it to "AI-developer". None of the deficiencies of web stack are solved here. The worst part is that this complexity of web stack is mainly _accidental_ – i.e. coming from the tooling, not from the problem domain.
It's a 7.2k words piece. You must be reading at 25 words per second.
reply