3 ms·
Are there any simple software things that are actually very simple? I feel like tons of the very basic things that have been core software tasks for ages still
by zokier 4y ago
Are there any simple software things that are actually very simple?
I feel like tons of the very basic things that have been core software tasks for ages still have surprising amount of complexity and depth to them when you'd expect them to be simple. Stuff like text (basically anything), math (real numbers), 2d graphics (efficient high-quality vector graphics still seem like a pipedream), sorting (we just had a thread about improving sorting in postgres!), files (infamous fsync issues), color, etc just seem to constantly come up as problems when you'd think we had solved them already 20 years ago.
- syntheweave 4y agoMost software things become simple when you can define them down into an enumeration of possibilities. For example, if my text problem were "display these preformatted strings in a single resolution and layout" there would be no requirement on their encoding or processing and I could do whatever I like, even hardcode them or store them as image assets. Games have done this trick since forever because they have a tremendous capacity to soak up more and more static content, and much of the core tech in a game engine is in finding the ideal representations to efficiently load and present that content while carefully minimizing the dynamic behavior that would entail a general-purpose solution. The problem for software in the larger view of things is always that we've defined the problem with sufficient generality that it has to accommodate all the depth, because we don't know who is using the software or what they want from it. The medium is never "set in stone" so the tools are forever adapting to a new use case. And just when you think you've modelled every possible aspect of the data, some other way of doing it will come up. And it's not a right thing either to think "OK, I'll just solve the most general thing I can think of now so that I don't deal with it later" because then you just have a wide field of untested edge cases and no coverage of the thing you didn't anticipate. Like, take image editing software as an example. They all let you draw things freehand. Many support pressure sensitive stylus input. But the way they interpret that input is all over the map: different sensitivity curves, stabilization algorithms, brush behaviors and so on. There's no winning the battle by defining the most general engine for freehand drawing and painting, because what the user craves most of all here is the path to "just works" defaults. Thus in every sufficiently developed editor, an enumeration of possibilities appears again, but as a configuration letting you browse presets.
- _gabe_ 4y ago> Games have done this trick since forever. Text rendering is still a very complex task in modern games unless you're using an engine (and even then the complexity is still there it's just hidden). I'm not aware of any recent releases that stored all their text as hard coded images. Most games will at the very least create a predefined charset, render each character to a bitmap or sdf as part of the loading using something like freetype or stb_truetype, cache the bitmaps or sdfs to a hash map with a lookup ID and all that stuff, upload the images to a texture on the GPU, perform some sort of layout scheme when rendering the text in the game world or HUD (which includes things like figuring out the kerning for different characters, line wrap, and all the other fun stuff). Like somebody else mentioned, nothing is simple. Even a bitmap font from the 80s was wayyy more complex then it would be today because of all the optimizations you would have to create to make sure it was fast, and the extreme lack of modern rendering utilities that we have today.* *I wasn't alive in the 80s, so this is just based on the videos I've seen of what we had then and articles/books I've read about what programming was like then.
- __del__ 4y agobitmapped fonts are pretty damn simple, but you can compress them by storing only the pixel distances to the next inversion from 0 -> 1 or 1 -> 0 along scanlines
- ivraatiems 4y agoThe issue with many of these things is that they aren't simple, not really, it's just that our brains are super good at them and computers are almost entirely unlike our brains. Human brains are able to do things like read context clues and extrapolate from them. It just makes sense, for example, to wrap your lines to the space available on a given piece of paper. But a computer doesn't know what a "line" or "space" or a "piece of paper" is. It has to be told, via a mathematical abstraction, which a human must devise. That is, any adult human being carries around an absolutely massive amount of mental context which they are capable of applying to every situation nearly automatically, without realizing it. All of the things you mention are tasks any sufficiently educated human can do easily - draw a shape? sort some things? do math with fractions or complex numbers? - because you can teach a human a general concept and then assume their brain will do the work of applying it to new situations, breaking it down, etc. 2 + 2 on a TV screen is exactly the same as 2 + 2 in a notebook is exactly the same as two sheep + two sheep in the field. But until someone invents strong general AI (hehe), computers just aren't gonna have that skillset.
- armchairhacker 4y agoText, math, 2d graphics, sorting, files, color are simple as long as you don’t care about the most optimal version. Everything the author mentions in the article can also be done “simply”, if you use monospace, ASCII, ignore mobile, etc. For example, text is just a null-terminated char array if you only support ASCII, or short or int array to support other languages and more symbols. To render the text, just loop over each char and index into an array to get a bitmap of a monospace font. Your text may look a bit ugly and take up more memory than necessary, but it’s passable, and 40 years ago it’s what we did. There are some problems like TSP and Chess where there is a simple brute-force solution, but its not “passable” because it takes impossibly long, so you need a more optimal complex solution. And then there’s the iconic “seems simple but actually really hard” problems like generalized image recognition or walking; they are “simple” to humans and animals, but a remotely half-decent solution took a long time even with giant super-computers, and it’s still only half-decent.
- OJFord 4y agoThose things only have 'complexity and depth' once you really get into them though, I think? And the level at which that occurs has probably got more complex/deep as time's gone on. It's almost tautological, I can't really see that that would ever not be the case for anything. Kicking a ball is bloody easy, but soccer's played at a high level by extremely trained extremely paid people. (I'm far from a fan, fwiw, but I think it's a clear example.)
- JoshCole 4y agoImmutable data comes to mind as something relatively simple. There is a world of complexity for working with it in a fault-tolerant and efficient way, but from a structural perspective an immutable bit of data is one thing rather than many things and it is only that thing and can only be that thing forever. This strikes at the very core of what simplicity is meant to be, not in the sense of ease, but in the sense of not being complexity.
- lbriner 4y agoIsn't the issue that humans will never accept something is finished. People have spent many years sorting many things but at some point someone suddenly decides (for good or bad) that sorting could be better, that files could be done differently, that ext4 is no longer suitable for scenario X and they start inventing something new. Most of these things probably die after a while if they are ever really well-known but if you work for some FANG (or whatever it is now!) company, you might have enough resource to force the new way of thinking onto everyone else so that FOMO kicks in unless you are also using the new best thing. In so many cases, people get religious about differences that might affect Google or Amazons bandwidth usage but no-one elses (like using a new image format). I wonder how many developers, particularly web developers, actually know for certain which parts of their system are unreasonably slow and actually need to change?