[HN Gopher] Simple software things that are actually very compli...
___________________________________________________________________
Simple software things that are actually very complicated
Author : AshleysBrain
Score : 52 points
Date : 2022-05-22 19:56 UTC (3 hours ago)
(HTM) web link (www.construct.net)
(TXT) w3m dump (www.construct.net)
| ivraatiems wrote:
| I agree with the general premise - sometimes "simple" things in
| software are really complex - but not the specific examples. The
| reason for the complexity in the author's examples is that
| they're using web canvases in a way they are not, as far as I
| know, intended to be used. Canvases are for 2D shapes/bitmap
| rendering, not complex text and user interactions. You're having
| trouble because you're reinventing the wheel. Maybe it's
| necessary for your use case, but that doesn't make it shocking
| that it's hard.
| zokier wrote:
| 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 wrote:
| Most 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.
| ivraatiems wrote:
| The 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 wrote:
| Text, 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.
| tester756 wrote:
| http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
| umvi wrote:
| Some of these things are only super hard if you are developing a
| general solution. The general solution to word wrapping across
| all written human languages in use on the planet is indeed
| difficult. But implementing basic word wrap for an HTML5 game
| that only English players will play isn't too hard.
| PaulHoule wrote:
| It's a funny topic for me because last summer I wrote a text
| layout engine for Python because I thought the alternatives
| sucked. I struggled with loading libraries to support vertically-
| oriented Japanese text and then it hit me "these characters are
| all squares... it can't be that hard!" Then there was the gradual
| epiphany that: (1) if you want to use serif typefaces and have it
| look good you have to kern them properly (2) Word, Powerpoint,
| and Adobe tools don't kern properly (3) that's why sans serif
| typefaces are so fashionable these days
|
| Of course I am using this to print cards with custom software and
| it doesn't have to be interactive, reflow, or be useful to anyone
| else.
| froh wrote:
| Yes, and also ligatures, serif fonts love ligatures...
| userbinator wrote:
| I'll offer the counterpoint that it's only complicated if you
| want to make it so. If you only need e.g. monospace ASCII, that
| doesn't take much. Do you really need proportional fonts?
| Vertical layouts? Keming? In my experience, a lot of the time the
| answer is actually "no" --- and thus the simpler (and more
| efficient, less bug-prone) algorithm works just fine.
| FooBarWidget wrote:
| Whether you need them is up to users. If you have Asian users
| then ASCII will not do. No kerning? Why would users put up with
| ugly text rendering? Just to make our lives as developers
| easier?
|
| This attitude reminds me of what someone says about the
| difference between German and Japanese tech. Japanese ones last
| forever because they overdesign their products to avoid
| breaking even when misused, because they are customer-focused.
| Germans are rule-focused, so they design their products
| according to spec. German products also last forever -- if you
| use the product _exactly_ per instructions. But if you make a
| mistake... good luck.
| userbinator wrote:
| "ugly" is entirely subjective.
| remus wrote:
| I think the issue with this approach is that people may nod
| along and day they're happy with these compromises, but in
| reality they don't necessarily understand the trade offs and
| are then surprised when seemingly simple things don't work as
| expected. I'm thinking less of programmers here, who will
| generally understand what these limitations imply, and more of
| less technical users.
| zokier wrote:
| Do you _really_ need more than 1s and 0s? Maybe go back to
| blinkenlights and toggle switches, those are simpler and even
| less bug prone to implement. You can still perform any
| computation you want, but it sure will not be as pleasant as
| having nice ux.
| pdpi wrote:
| I think you're missing the point. These are fundamentally, but
| deceivingly, hard problems. The choice to only solve a subset
| of the problem is almost always the right way forward, but you
| can only make that decision if you understand how hard the
| problem is. A less knowledgeable developer can and will bite
| off more than they can chew with these things.
|
| Contrast with things like interpreters that a are a lot simpler
| to build and work with than most engineers think they are, and
| a perfectly reasonable solution to lots of problems.
| EdSchouten wrote:
| Parsing and displaying a floating point number, a la strtod() and
| printf("%f"). I think that's always the prime example of
| something that looks simple, but simply isn't.
| trhway wrote:
| I think the complexity we handle has stayed the same. It is just
| for the same amount of complexity and mental energy we get more
| functionality these days than decades ago. Text is a good example
| - the same complexity and the same amount of code handles these
| days a huge number of languages whereis decades ago that
| complexity would give you only one.
| kccqzy wrote:
| Somewhat famously, Knuth came up with a dynamic programming
| algorithm for breaking paragraphs into lines with full
| justification (both left aligned and right aligned). Later on
| there are of course further innovations like character protrusion
| and expansion to achieve that optically aligned look without much
| (if any) hyphenation.
___________________________________________________________________
(page generated 2022-05-22 23:00 UTC)