What's something difficult programmers make look easy?
tomaszs2.medium.comDoing anything repetitive with a large amount of data by virtue of knowing about for-loops. There have been so many times where people wanted something done to a million users/objects/whatever and were surprised that I got back in 5 minutes. One of them even muttered the words "I thought that would take you all day", when actually 3 of the 5 minutes were spent getting a cup of coffee.
My brother was given lines to write as a punishment in the early 80s. He wrote a for loop in basic and printed the result. The teacher didn’t know any better and was happy to accept the printout. Assuming he’d typed it all from scratch.
Or maybe he knew, but pretended that he didn't. Lines are a waste of time, and serve little purpose besides punishment. Writing code is a much better use of that time.
If I was a teacher, I think that's how I would react. The next punishment would be handwritten though, or something else, you only get one shot with that trick.
I admit that in the early 80s, most teachers were not very savvy with computers, so it is possible that he really believed your brother typed it all. But also keep in mind that teachers are pretty good at smelling bullshit, and it is pretty obvious that when pupils do things in an unusual way, it is not to make it harder on themselves, so he probably knew that there was some trick and just let it pass. I mean, these are just lines, nothing worth persecuting clever kids for.
> Or maybe he knew, but pretended that he didn't.
1980s, before most people had computers.
A teacher. The kind who'd make a kid do repeated writing "to teach them a lesson." That teacher playing "make believe" about anything.
> But also keep in mind that teachers are pretty good at smelling bullshit
Even in the 80s, teachers weren't exactly rocket scientists. Rocket scientists would have been familiar with computers.
Similarly, I was tasked with counting every file in a folder and its subdirectories as a punishment at a job on campus as an undergrad.
I plonked out a Bash oneliner in a couple minutes and gave the result. My disgruntled superior had me do it again by hand.
Ah, you had the knowledge to solve the problem using bash, but had not the wisdom to sit on the answer and surf the web until a plausible amount of time had passed :)
Write one line. Copy and paste it to make two lines. Copy and paste _those_ to get four lines, etc.
I had a colleague at a previous workplace who had studied game design at university unaware of what a for loop was when I showed him. It boggled my mind!
Sadly, I've interviewed enough people that this doesn't surprise me in the least.
> How to workaround too little RAM problem? Let’s load pixel graphics if player is far away and call it mip mapping
Hold up, mip mapping is not a way to save RAM in fact it consumes more RAM because not only do you need to have the full-size texture in RAM you also need to keep smaller copies in RAM.
What it does save on is memory bandwidth, because you don't need to sample from the full-size texture for objects that are far away. And it improves visual quality, since you can use expensive scaling algorithms to produce high-quality downscaled copies.
>Hold up, mip mapping is not a way to save RAM in fact it consumes more RAM because not only do you need to have the full-size texture in RAM you also need to keep smaller copies in RAM.
While that's how it's mostly used today, mipmapping refers to storing scaled-down versions of the same texture along with the original texture. You don't have to load all of them to RAM (or VRAM). You can simply store the mipmaps on a hard drive, and only load the required mip levels to the GPU, thus saving VRAM. This way, you are using mipmaps as texture LODs. Think about satellite images of Google Maps.
>What it does save on is memory bandwidth, because you don't need to sample from the full-size texture
Not exactly. It does save memory bandwidth, because you're sampling less texels and reducing cache misses, not because you're sampling from a smaller texture. You're simply not downscaling the texture on the fly, instead using precalculated downscaled pixel values.
Mip mapping was originally developed neither for bandwidth nor memory reasons, but for texture filtering.
in early games it was a metod to save RAM too, for a short time but it did. Because you didn't have to store all mip map parts in the RAM
How does storing more copies of the same texture save ram?
Of course one can drop the higher resolution textures, but AFAIK that technique came long after mipmapping, as it requires high cpu-to-gpu bandwidth, which wasn't there in the earlier days.
Right. Mipmapping is different than simply using lower levels of detail textures. Mipmapping is when you store the full level of detail plus progressively lower levels of detail (always adding up to 33% more data) so that the correct LOD texel can be looked up depending on the required rendering detail. You're using more memory for higher quality (and sometimes faster) rendering.
What is it when you have the detail texture loaded in such a way that you can say "get every second byte (or whatever)" to get the half size, and so on?
IIRC some CPUs were good at that kind of memory access, but most were not.
Some implementations of mipmapping store a single medium-resolution image and either sample fewer pixels or duplicate neighboring pixels when drawing. You don't need extra memory for that. Literally just mapping a subset of the pixels from the texture stored in memory.
When enough pixel duplication occurs you may want to enqueue a request for a higher resolution texture to be loaded into memory and let the resource pool decide. You can see this in effect in some older games where you're able to "outrun the horizon/frustrum" so to speak or when too many objects spawn and the level of detail is terrible for a while until the game catches up. Otherwise this is just a most-recently-used cache. Mipmapped textures can either be many prescaled static copies on disk or precomputed from the single full resolution asset on disk while loading a level.
That's just level-of-detail on top of mipmapping. Mipmapping requires strictly more textures for the same level of detail.
laughs nervously while trying to get performant 2D rendering of large tilemaps in their first game
I can barely begin to imagine all the pain involved in creating AAA games. Decades of whitepapers to read and build upon only to get to a point where consumers aren't downright angry at the quality of graphics being given to them.
That seems surprising, and I've been a game dev before I switched to mobile.
How large is a "large" tilemap?
And what is it that makes them particularly hard in the AAA space?
My grid right now is 144x144, so about 20,000 tiles. Things were working OK in iOS Safari when just using colors to draw the tiles, but the browser started crashing when I tried upgrading to image sprites.
Turns out the trick is to not submit each individual tile to the GPU. You have to roll them up into larger, chunked meshes and submit those meshes to lessen the impact.
I'm sure this is game dev 101, but I've never been close enough to the GPU to have to actually care about this sort of stuff. I cut my teeth learning the performance characteristics of the DOM not the GPU.
I wasn't trying to imply that I was making an AAA game. Just that, from the outside, it seemed like the difficulty would be in designing game mechanics, making something actually fun, marketing, etc., but in reality there's an ever-steepening technical learning curve when you want to deliver nicer looking stuff. When I look at how many days I've spent working on my game, and how terrible it looks, and then I look at something like Cyberpunk 2077... I struggle to conceive how we as humans were able to create those levels of graphics in a timeframe that allows for the game to be profitable.
https://github.com/MeoMix/symbiants btw. Feel free to browse the code (or come volunteer! I've got a few other HNers tinkering alongside me these days)
People assume that all the difficult video stuff is 3D and that 2D is "solved" but it's actually quite an issue to do it well and fast.
The Factorio dev blog has some of the issues encountered, and rendering speed for Dwarf Fortress in ASCII mode has been an issue in the past.
Oh cool, I didn't realize Factorio had such an extensive dev blog. I see it goes back over a decade! It'll be a treat to read through this :)
And ugh, I can believe it with DF. I'm trying to deliver something with similar quality graphics and naively thought that setting the bar so low would make that aspect of the project "free" :)... but it's about the journey not the destination and it is so rewarding making all the little micro-improvements over time. So, I'll stick with it and hope to get quicker as I gain more experience.
To be fair, Cyberpunk 2077 took 500 people 11 years and 400 million dollars, and even then when it dropped it was barely in a playable state. It seems more fair to compare modern AAA games to movies than indie games, in terms of the cost and resources that go into them. Although with movies, they're actually finished when they release (George Lucas and Steven Spielberg notwithstanding.)
But as someone who can mess around with tilemaps all day but still can't work in Blender, or rig a model, or understand OpenGL or shaders, I feel your pain.
I would argue that difficult programmers don't make anything look easy.
Shouldn’t there be a "that" between "difficult" and "programmers" in the title to make parsing less ambiguous? I’m not sure if adding it would be grammatically correct
(Non native speaker)
Yes. Or at the very least a comma in the same location.
I read it this way twice before I read it as the OP intended.
Making six figures (by sheer luck of the fact that their work scales better than most jobs, including most harder jobs)
This. I feel fortunate that I didn't start out in tech - I didn't become a programmer until I was 30. I'd been working since I was 15 or so, so I'd had about 15 years of experience in various industries.
I think a lot of devs who go into comp-sci and land into tech right after college have very little understanding of how hard life can be outside of tech. This isn't an easy industry, but goddamn it's so much better than the vast majority of other options out there.
Yup. When I get frustrated I just take a deep breath and then remember how relatively easy and well compensated this career is compared to just about anything else - for me, anyway.
I think this hints at another truth though: If you switch your metric to up-weight happiness and down-weight material rewards, it moves down the rankings IMO.
Believe it or not, I know some people who essentially never get frustrated by their work, while making a decent wage. In some of these cases, they also don't have the "is what I'm doing useless or even actively harmful" ennui that is prevalent in the software industry.
I try to remind myself that some of my pay is compensation is for frequent frustration.
I worked in biology before going into tech. Dear lord its so much easier to scale your labor in tech. I have manually genetically engineered multiple types of organisms. It's insanely tedious.
To the extent that if I ever went back, I would probably immediately focus on roboticizing most of the work.
Reminds me of the recurring conversation on HN about how people should stop driving cars and just walk everywhere.
It's like, yeah, in an ideal world, all 8+ billion humans could pick up craft coffee as they stroll 5 minutes to their big tech employer who doesn't actually care when they show up. There's legitimate criticisms for how cities have been designed, but going further by vilifying car owners in the present and suggesting everyone could just walk or ride a bike to work is a level of being out of touch that only Silicon Valley types could achieve. Even politicians aren't as brazen with such silliness. As if the rest of the world can choose where their employer is located, how far their groceries are, or how much child support they have.
Just be a tech bro, bro.
This has also been something I’ve noticed, and I share your sentiment. It really is an opinion, strongly held, born out of massive ignorance.
What do you think about public transport vs. personal cars?
> it's so much better than the vast majority of other options out there.
The journey towards enlightenment or personal growth is highly individualized and subjective, making comparisons with others is not only unhelpful but also irrelevant.
Certain kinds of comparisons can be unhelpful. Others can be illuminating, often instilling a sense of gratitude and humility.
Better in terms of effort to money.
Programming isn't hard. It isn't easy either, but it isn't hard.
I think the thing about programming is that so much of the "old" world misunderstood how it was hard. There is a lot more creative process stuff involved with programming, and not nearly as much that is codified, that you need to study, as in other fields like physics. And so, it gives people wide leeway to footgun themselves. Just as much, going the other way, it puts a premium on the ability to think and reason in abstractions, to which point, we don't have as strong a "liberal arts" for the STEM world as we do for the literary / humanities / cultural world.
So yes, on one hand, programming is not as hard as physics (to make one example of it). But on the other hand, I knew a person or two doing research in physics who complained how much their work was held back because their colleagues didn't appreciate the effort it took to process all the data that came from their experiments. Folks didn't appreciate how critical all that code was to their research. We see this sort of dynamic replicated throughout the rest of the world.
Programming isn't hard if you exclude debugging as being a different activity.
I think it elevates it to the level of other STEM fields, but I wouldn't put it over wrapping your head around Lagrangians or figuring out where the noise in your experiment is coming from.
What'd I'd say though is that managing the process of shipping software isn't easy. e.g. building AWS was probably not easy. But then again, building a tokamak or a stellarator is not easy either.
You can get help with Lagrangians; they are not your original work; other people understand them.
In debugging there are situations in which nobody can help you. There are people with good debugging skills, but only you know that code.
There are no papers or books about the bug in your program.
I spent a summer in college working construction as a general laborer, making $20/hr. I was rich!! ...and every person on the jobsite said "stay in school, don't do this full time".
I've never experienced that same end-of-day exhaustion before or since doing construction (and I was a fit & healthy college student).
No matter how bad my day is, sitting at my desk and typing for a LOT of money, I know it's better than many alternatives.
> 1981 A first 3D game called Tempest is published
Battlezone is actual 3D, and 1980.
I'm not saying that is first, either, just that 1980 < 1981 and that Tempest is more of a form of 2.5D. (I remember it being an interesting, fast-paced game with good sound, but fundamentally it's just Space Invaders rolled into a tube.)
> How to workaround too little RAM problem? Let’s load pixel graphics if player is far away and call it mip mapping:
MIP mapping is not primarily a RAM problem solving device. It's a way of precomputing the shrinking of texture images for when they appear in the distance, so that they don't have to be antialised on the fly.
Thus is a CPU saving device, and requires extra storage. However, not much more! The half-size texture needs only 25% more storage, and the quarter-size another 6.25% or so.
The renderer has to consider the depth and index into the appropriate scale of the texture. I don't remember all the details, but I see to remember that it's dynamic. Like when the textured surface is in deep perspective, the distant pixels are derived from the smaller scale data, while the near part from the larger scale.
It could save RAM if we can avoid the detailed textures for objects that require them and are all far away. I.e. lazily load the detailed texture as the objects are approached, and free the memory when they recede again.
Tempest is indeed a terrible example:
- it's a static perspective view, less complex than sprite based 2D
- it's implemented on a vector screen, where the cathode ray gun is drawing the lines instead of the software, not a bitmapped one
- almost everything can be precalculated and only vertex locations need be stored
Of course it's still a creative game, but not very hard to implement.
It should be noted that Battlezone wasn't actual 3D since everything happened on a fixed plane, but it had dynamic rotating shapes and the like so much more advanced.
"Create an account to read the full story."
What game developers are good at is not making slow programs. Everything else, from point of sale to web pages to phone apps, gets slower and slower.
> What game developers are good at is not making slow programs.
That isn't true. Many games, even really popular/enjoyable games, have really poor performance for what they do. And much of the performance that does exist is thanks to the people who work on the engine and not the game itself.
I'm not sure the average game-dev is any better at writing performant software than the average non-game-dev.
I do find it amazing how much leeway other industries have when it comes to performance compared to my native industry of gamedev. I'm constantly thinking about how to structure things to avoid dynamic allocations at all costs, reduce memory footprints, reduce branches, on top of balancing usual concerns like readability, extensibility, etc. This often means forgoing abstractions as often as is reasonable.
My coworker, bless him, who comes from a background in the financial industry once added a feature that involved making copies of 5 vectors of strings. Both the vectors and their strings were regenerated every single tick from c strings that permanently resided in memory, by way of multiple concatenations for each string. Profiling informed me we were now making some hundreds upon hundreds (sometimes thousands) of (re)allocations every 16.7ms. I diplomatically pointed out the wastefulness and he (partially) fixed the issue by changing 2/5 of the getter functions to return a reference. I could tell he was quite annoyed with me, and didn't really understand the issue. It's just allocating memory, how bad could that be?
Unless you're Rockstar North:
https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
First of all ray tracing was invented well before real-time rendering.
Second of all, all these difficult things are difficult things that game ENGINE developers are responsible for tackling nowadays.
In the 90s and early 2000s, most of the people building engines were laying down games at the same time, which is very much akin to building a railroad while running the train. For most folks (like me; I'm developing an indie VR game on the side) this is all handled by Unreal, Unity, or Godot.
I've tried to build a simple game engine in the past... you wind up reinventing the wheel a lot...
The think about programming that always gets me, is how things that sound very hard, can be very easy...
and things that sound very easy, can be very hard or impossible.
"the main lesson of thirty-five years of AI research is that the hard problems are easy and the easy problems are hard." https://en.wikipedia.org/wiki/Moravec%27s_paradox
“And check whether the photo is of a bird”
I also like the “uncrop” photo enhancement from Red Dwarf.
Editing a shared multimedia document in near real-time with colleagues on four different continents. I still marvel at this now-commonplace task.
Debugging. It takes hours to pinpoint exact cause of anything more complex than a toy program, especially when the bug requires a combination of factors to manifest. In most situations its much harder to debug code that you didn't write, but it appears as if debugging is "easy" because people do it on their own code.
Bonus(appear easy to do, but are actually hard): Micro-optimizations that target a specific platform: a combination of CPU-compiler-OS factors.
Porting software: There are tons of subtle unportable things and assumptions that hide under the surface.
Rewriting X in Y:lots of footgun and like inexact translation in natural languages can cause subtle bugs.
Makefiles and shell scripts: they look so simple, but try debugging a moderately complex makefile or shell scripts. Bash is especially sinister example.
Anything that talks to a closed/blackbox API or close-source library: the dependence on code that you can't debug in general.
Maintaining software in general as it grows in complexity.
Parsing
Constrained geometry for CAD tools like Fusion360
Um… programming?
Honestly, grab a random human and sit them next to you while you code a bubble sort algorithm or a prime number finder to see what I mean.
Can I say how much I hate Medium these days? Remember when it didn't suck and was doing such a good job of not sucking that all sorts of very serious people created Medium accounts to start blogging? What the hell happened, Medium?
I started reading this story, got about halfway down, and the story stopped and I got this big centered H2 reading "Create an account to read the full story."
Fine, I want to read the rest. I create an account. I go back to the story. Now the story still stops at the same place but the big centered H2 has changed to "Jorgi, read this story from Tom Smykowski — and all the best stories on Medium" and there's an "Upgrade" button. That was not our deal, Medium! You said I could create an account to read the full story.
So I click the button and it takes me to the signup page, of course on the "pay annually tab," with a small white button on a white background that reads 'monthly' for other options. Fuck you, Medium.
More articles hosted on Medium means more time I save by never reading them.
I now use archive.ph to read these types of article now. Medium as a platform is awful and the constant nag to signup just puts me off so much.
So you're using a page that stole my article. Thank you
Ooo, nice, thanks!
They needed to make a profit.
The article is available for free. Just use the link at the top. It's not paywalled
My friend, this is a paywall: https://imgur.com/a/8t36SKt
This is why you should get various browser extensions that cut through this nonsense.
There's not much good content on medium anyway. Most of it is shallow and lacks any real subsistence. The rare useful post is out numbered 10-to-1 or even 100-to-1 or more by shallow blog spam and other noise.
I can only imagine substack will end up the same in a few years time. These platforms get all hyped up and end up drowned in spam and low quality stuff when they go mainstream.