3 ms·

Simplicity and complexity are not opposites. Things become complex when we attend to multiple simple things at the same time. For example, we have an algorithm

Simplicity and complexity are not opposites. Things become complex when we attend to multiple simple things at the same time. For example, we have an algorithm that requires a key-value store with typical semantic. For the purposes of our algorithm we could simulate that store using an array and straightforward search and insert routines that just loop through the array without trying to be smart. Then we could attend to details of that key-value store and use a more efficient approach, this time without thinking about our original algorithm; or, perhaps, with a clear understanding of its access pattern. In both cases the task at hand won't be more complex than necessary. But if we try to do both at the same time, it will be way more complex. Here the separation is clear, but in real programming it is not clear and to discover these lines of separations is basically the essence of building a system. I think Brad Cox was occupied with that with his Software-IC concept and I kind of share his view that this is yet to happen. Things we build are not as composable as they should be; as they are in other industries.

Mikhail_Edoshin 10mo ago
An example: there is a text "shaping" library that takes a font, an input string and produces a sequence of glyphs to typeset that string. Modern fonts and certain scripts are very complex and this task is not trivial. Now, this particular library takes an UTF-8 string. Which means it has an UTF-8 decoder inside. But a text shaping library does not need an UTF-8 decoder. The product it is used in will certainly have one or, if it works in UTF-16 or, as Python, uses 3-way encoding, may not even need it and thus will have to add an UTF-8 encoding step only to communicate with that library. A simpler design would be to remove that UTF-8 decoder and make the library to accept Unicode characters as integers. If we need UTF-8, it is trivial to decode a string and feed the resulting Unicode into the shaper; if we don't, it is equally trivial to use the library with any other encoding. (I guess I ended up with a slightly different example than I intended.) Anyway, removing an UTF-8 decoder here would result in a simpler and more universal design, although - this is an unexpected development - it may superficially look more complex to many people who have the "standard" UTF-8 string and just need to get the job done.
- mxey 10mo ago
  If this makes the library harder to use because most people will have UTF-8 strings, I’m not sure that’s a win.
  - TeMPOraL 10mo ago
    In other words, circling back to Brad Cox's Software ICs, we're all using devboards and Arduinos instead, because those look simple to newbies and save a little glue work here and there. In hardware world, it's fine to use devboards and Arduinos to prototype things, but then you're supposed to stop being a newbie, stop using breadboards, and actually design circuits using relevant ICs directly, with minimal amount of glue in between. Unfortunately, in software, manufacturing costs are too cheap to meter, so we're fine with using bench-top prototypes in production, because we're not the ones paying the costs for the waste anyway, our users are. (Our users, and hardware developers too, as they get the blame for "low battery life" of products running garbage software.)
    - mxey 10mo ago
      > Unfortunately, in software, manufacturing costs are too cheap to meter, so we're fine with using bench-top prototypes in production, because we're not the ones paying the costs for the waste anyway, our users are. I’m not sure what you’re trying to say - UTF-8 is the standard text encoding by a mile. It’s not a prototype.
      - TeMPOraL 10mo ago
        UTF-8 here is like having a devboard with an USB controller chip, complete with power circuitry and USB port. It could all be high-quality components, it's super useful to have it on the board for prototyping, but in the actual product, you aren't going to ship three devboards wired by SPI, but each carrying some combination of USB, Ethernet, Wi-Fi, Bluetooth controllers and other stuff, all of it disabled/unused, all because you need three ICs and found it easier to order devboards. You're just going to use the ICs you care about, supply the USB controller and port and necessary wiring yourself, and otherwise use minimum amount of extra components necessary. So, in context of Mikhail_Edoshin's example, I'm saying that this "text shaping library" they mention is basically a devboard - full of components not necessary for its core functions. Most software libraries are like that, so applications using them are basically like a device built from wiring up a bunch of devboards.

Mikhail_Edoshin 10mo ago

An example: there is a text "shaping" library that takes a font, an input string and produces a sequence of glyphs to typeset that string. Modern fonts and certain scripts are very complex and this task is not trivial. Now, this particular library takes an UTF-8 string. Which means it has an UTF-8 decoder inside. But a text shaping library does not need an UTF-8 decoder. The product it is used in will certainly have one or, if it works in UTF-16 or, as Python, uses 3-way encoding, may not even need it and thus will have to add an UTF-8 encoding step only to communicate with that library. A simpler design would be to remove that UTF-8 decoder and make the library to accept Unicode characters as integers. If we need UTF-8, it is trivial to decode a string and feed the resulting Unicode into the shaper; if we don't, it is equally trivial to use the library with any other encoding. (I guess I ended up with a slightly different example than I intended.) Anyway, removing an UTF-8 decoder here would result in a simpler and more universal design, although - this is an unexpected development - it may superficially look more complex to many people who have the "standard" UTF-8 string and just need to get the job done.

mxey 10mo ago
If this makes the library harder to use because most people will have UTF-8 strings, I’m not sure that’s a win.
- TeMPOraL 10mo ago
  In other words, circling back to Brad Cox's Software ICs, we're all using devboards and Arduinos instead, because those look simple to newbies and save a little glue work here and there. In hardware world, it's fine to use devboards and Arduinos to prototype things, but then you're supposed to stop being a newbie, stop using breadboards, and actually design circuits using relevant ICs directly, with minimal amount of glue in between. Unfortunately, in software, manufacturing costs are too cheap to meter, so we're fine with using bench-top prototypes in production, because we're not the ones paying the costs for the waste anyway, our users are. (Our users, and hardware developers too, as they get the blame for "low battery life" of products running garbage software.)
  - mxey 10mo ago
    > Unfortunately, in software, manufacturing costs are too cheap to meter, so we're fine with using bench-top prototypes in production, because we're not the ones paying the costs for the waste anyway, our users are. I’m not sure what you’re trying to say - UTF-8 is the standard text encoding by a mile. It’s not a prototype.
    - TeMPOraL 10mo ago
      UTF-8 here is like having a devboard with an USB controller chip, complete with power circuitry and USB port. It could all be high-quality components, it's super useful to have it on the board for prototyping, but in the actual product, you aren't going to ship three devboards wired by SPI, but each carrying some combination of USB, Ethernet, Wi-Fi, Bluetooth controllers and other stuff, all of it disabled/unused, all because you need three ICs and found it easier to order devboards. You're just going to use the ICs you care about, supply the USB controller and port and necessary wiring yourself, and otherwise use minimum amount of extra components necessary. So, in context of Mikhail_Edoshin's example, I'm saying that this "text shaping library" they mention is basically a devboard - full of components not necessary for its core functions. Most software libraries are like that, so applications using them are basically like a device built from wiring up a bunch of devboards.