9 ms·

What's frustrating is people who think that they can radically simplify something without knowing anything about it. The same people think they can implement a

What's frustrating is people who think that they can radically simplify something without knowing anything about it. The same people think they can implement a text editor in 1000 lines of code because that's how the first text editors were made. Why can't we go back to those simple days? We can't because modern software handles cases that those didn't. For example, rendering and editing text seems straightforward until you look closer. Text Rendering Hates You (https://gankra.github.io/blah/text-hates-you/ https://gankra.github.io/blah/text-hates-you/) and Text Editing Hates You Too (https://lord.io/blog/2019/text-editing-hates-you-too/ https://lord.io/blog/2019/text-editing-hates-you-too/) are two amazing reads that analyze this in detail. They explain the hidden complexity to the vast majority of us who never knew. We simply slapped down a <textarea> or <EditText> and called it a day. If we tried to reimplement this stuff from scratch, we would likely start with a simple implementation, then tack on bits when we tried to handle issues like right-to-left layouts, Unicode, emoji, anti-aliasing, text overlapping and so on. All this before getting into implementing features that Dennis Ritchie didn't have to, like supporting plugins, releasing on multiple operating systems, accessibility or even syntax highlighting. Problems already known to and tackled by existing text editors today. If you look at work outside of your area of expertise and you feel like starting a sentence like "why don't you just ...", then reconsider. If the person you're talking to is halfway competent (they probably are), they've already considered what you're about to say. "Have you considered using less memory/CPU or removing this feature that I personally don't need?" Why yes, we have. (This is from a post I wrote earlier - Software Isn’t Bloated - https://blog.nindalf.com/posts/software-isnt-bloated/ https://blog.nindalf.com/posts/software-isnt-bloated/)

alpaca128 5y ago
All those people don't realise tools like curl did start with few lines back then. And after the first two minutes of testing the devs started adding additional code to handle failures, invalid inputs, different platforms, different versions of a standard etc. One can write a lot of things in 100 lines if it doesn't have to meet higher standards than a basic chat app tutorial in the "getting started" section of a programming language.
- craftinator 5y ago
  > One can write a lot of things in 100 lines if it doesn't have to meet higher standards than a basic chat app tutorial in the "getting started" section of a programming language. I'd argue that even a basic chat app is massively complex, only that all the really complex parts have already been solved. I once tried to write one on the LOWEST level I could. Realized after a month that there were not enough hours left in my life to finish it.
  - baud147258 5y ago
    really, we're standing on the shoulders of giants
    - craftinator 5y ago
      Or possibly just standing on the shoulders of people standing on the shoulders of people standing on...
      - Aeronwen 5y ago
        Shoulders with legs, all the way down.
galoisgirl 5y ago
This is "Falsehoods programmers believe about names" all over again.
bonaldi 5y ago
Second link is a 404 fyi
- piva00 5y ago
  It's just borked due to formatting, it's adding `)are` to the end of the URL, if you remove it on the address bar it loads :)
  - DonHopkins 5y ago
    "I could rewrite hn's url parsing regex!" -not me ;)
- nindalf 5y ago
  Fixed, thanks for pointing it out.
ezequiel-garzon 5y ago
And in fact even the "simplest" editors seemed to take quite some time even for our heroes. Ken Thompson has stated [1] that he devoted a week out of a month for what I understand was the first version of ed(1): [...] [my wife] was gone a month to California and I allocated a week each to the shell, to the operating system, the shell, the editor, and the assembler, to reproduce itself [...] [1] https://www.princeton.edu/~hos/mike/transcripts/thompson.htm https://www.princeton.edu/~hos/mike/transcripts/thompson.htm
- bombcar 5y ago
  An editor seems insanely simple until you realize that computers really don't like "inserting" data into existing data in memory, and then you're staring down the barrel of continuous memcpys.
  - DonHopkins 5y ago
    Mind the gap! https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Gap.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... https://en.wikipedia.org/wiki/Gap_buffer https://en.wikipedia.org/wiki/Gap_buffer
  - vardump 5y ago
    Weird. First idea that came to my mind was to use a linked list of lines.
    - arc-in-space 5y ago
      Close, but not ideal - lines are occasionally very long, and you're wasting nodes on sequences of newlines. There's a number of useful data structures that can do this well, like a 'rope'.
    - ahefner 5y ago
      It works. Many editors have used this approach.
    - dvfjsdhgfv 5y ago
TrackerFF 5y ago
"What's frustrating is people who think that they can radically simplify something without knowing anything about it." This type of mentality is also rampant in the world of entrepreneurship - Theranos et.al Sure, it's good to get new eyes on some problem, but it's the hubris that can kill.
- Frost1x 5y ago
  If you want to see extremely toxic, combine this mentality from the business side with confirmation bias from developers who think the same way. You get development efforts with massive scope people brush off as nothing. I've worked with a lot of these sort of groups where someone entrepreneurial understands enough to think they can simplify and improve something. Then they get a developer, two, or small team that agree. They start the undertaking or even worse, do the work under contract for someone else where they have contractual deliverables. Some way in they start to realize just how shortsighted and cavalier they were about brushing off uncertainties they either knew or didn't know about. "It can't be that hard! It's just software, it's all virtual! We don't need a bunch of capital! We just need a little bit of math! ... " All those uncertainties start to become quantities and they realize the absolute pit they dug themselves into. At that point they look for someone to swoop in and cleanup their mess. Usually it takes careful reading of the contract deliverables with liberal interpretation of what is stated and how those things can be minimally met. You really need people familiar with the types of software and systems involved and needed to achieve your goals to narrow down these uncertainties. If you don't then you're digging your own grave.
dqv 5y ago
>If we tried to reimplement this stuff from scratch, we would likely start with a simple implementation, then tack on bits when we tried to handle issues like right-to-left layouts, Unicode, emoji, anti-aliasing, text overlapping and so on. This is why I always try to look back as far as I can in a source's history to see how it started. It at least gives me a sense of the amount of work it takes to get from simple to mature.
moron4hire 5y ago
This is what I think of whenever I see someone taking a dogmatic stance on function length, conditional nesting depth, functional purity, OO-purity, etc. "Here's a person who has never worked on text rendering, text editing, GUI event systems, image decoding, etc." I have a chunk of code for implementing pointers, cursors, button clicks, and drag-and-drop in games. It's some of the gnarliest code I've ever written. It's also some of the most resistent code to "good design patterns" I've ever seen. I've written it and tweaked it and rewritten it and thrown it away and started from scratch and it always comes out the same. When you're dealing with things that have to meet long-established user expectations, it's always going to be full of little edge cases that you can't abstract away.
spaetzleesser 5y ago
"why don't you just ...", We also saw this with COVID. Plenty of people with no knowledge in infectious disease stating that the public solution was stupid and wrong but instead the obvious, simple and effective solution would be to "just do ....". Personally if that happens at work and somebody (often managers) tells us to solve a difficult problem by "why don't you just..." I usually tell them the code is available and they "can just do it" themselves. So far I have never had any takers.
- lanstin 5y ago
  Yeah the inner source mode is useful in several ways. “That sounds interesting, we welcome pull requests” — much nicer than “there are about three fundamental things you are overlooking.”
craftinator 5y ago
> What's frustrating is people who think that they can radically simplify something without knowing anything about it. I run into this problem with my manager a lot, who knows just enough to get himself in trouble. There's probably a term for it, but I call it the "complexity trap". He sees a problem, thinks he has an "aha!" moment, and tells me about a simple solution, and asks me to implement it. This solution, of course, disregards most of the complexity inherent in the problem. Complex problems require equally complex solutions, and if the solution is simple, it disregards the complexity of the problem, either shoveling down the ladder of abstraction, or hoping for some future state where it's not as complex.
- hedora 5y ago
  I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude. It has the effect of short circuiting the complexity of the problem, because it defines all the corner cases in a compact form. Interface with sloppy spaghetti systems can usually be hidden away at the edges of the system. The main problem is that less experienced engineers invariably come in and say, “A ha! I have a special corner case that doesn’t fit the abstraction.” and then try to add copy paste methods, boundary violations, and so on. As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave. HP printer drivers are a famous example of the sort of complexity reduction I’m talking about. They used to copy the entire source tree for each printer (font rasterizer, dithering algorithms, and all), then assign a full time team to maintain it. Eventually they had many thousands of full time engineers maintaining the result, and print quality was still terrible across the product line. The open source drivers reverse engineered the printers, and factored out as much common logic as possible. The printer specific code was then reduced to just implementing the wire protocol and device geometry stuff. At that point, they had better output than HP, with 1% the developer resources. Someone at HP did the same thing internally, reimplemented all the drivers in a unified way, and was promptly promoted to the executive team.
  - craftinator 5y ago
    > I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude. I agree, though this is generally limited to singular problems, and usually becomes harder to implement the higher up the abstraction train you go. I've found this especially true in business logic, where you don't know what the requirements or even end goal is; by the time you're ready to apply some nice mathematical based optimizations at a high abstraction level, doing so often requires a lot of work exposing all of the information you need from lower abstraction layers. All comes down to planning. > As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave. This is specifically why I mentioned my manager haha, who will both come up with crazy edge cases that in many cases don't even apply, and will come up with "aha!" solutions to problems that ignore major edge cases. Perks of not working for a software company. Very interesting history on the HP printer drivers, thanks for sharing that. I do remember some of the evolution that they went through, from the Linux perspective, and it was amazing how that tangled mess just started to magically work, circa 2008 if I remember right.
shockeychap 5y ago
Your "Software Isn't Bloated" post reminds me of an old post from Joel Spolsky about how complexity (ie. bloat) creeps in from countless unforeseen edge cases. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... "Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95."

alpaca128 5y ago

All those people don't realise tools like curl did start with few lines back then. And after the first two minutes of testing the devs started adding additional code to handle failures, invalid inputs, different platforms, different versions of a standard etc. One can write a lot of things in 100 lines if it doesn't have to meet higher standards than a basic chat app tutorial in the "getting started" section of a programming language.

craftinator 5y ago
> One can write a lot of things in 100 lines if it doesn't have to meet higher standards than a basic chat app tutorial in the "getting started" section of a programming language. I'd argue that even a basic chat app is massively complex, only that all the really complex parts have already been solved. I once tried to write one on the LOWEST level I could. Realized after a month that there were not enough hours left in my life to finish it.
- baud147258 5y ago
  really, we're standing on the shoulders of giants
  - craftinator 5y ago
    Or possibly just standing on the shoulders of people standing on the shoulders of people standing on...
    - Aeronwen 5y ago
      Shoulders with legs, all the way down.

galoisgirl 5y ago

This is "Falsehoods programmers believe about names" all over again.

bonaldi 5y ago

Second link is a 404 fyi

piva00 5y ago
It's just borked due to formatting, it's adding `)are` to the end of the URL, if you remove it on the address bar it loads :)
- DonHopkins 5y ago
  "I could rewrite hn's url parsing regex!" -not me ;)
nindalf 5y ago
Fixed, thanks for pointing it out.

ezequiel-garzon 5y ago

And in fact even the "simplest" editors seemed to take quite some time even for our heroes. Ken Thompson has stated [1] that he devoted a week out of a month for what I understand was the first version of ed(1): [...] [my wife] was gone a month to California and I allocated a week each to the shell, to the operating system, the shell, the editor, and the assembler, to reproduce itself [...] [1] https://www.princeton.edu/~hos/mike/transcripts/thompson.htm https://www.princeton.edu/~hos/mike/transcripts/thompson.htm

bombcar 5y ago
An editor seems insanely simple until you realize that computers really don't like "inserting" data into existing data in memory, and then you're staring down the barrel of continuous memcpys.
- DonHopkins 5y ago
  Mind the gap! https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Gap.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... https://en.wikipedia.org/wiki/Gap_buffer https://en.wikipedia.org/wiki/Gap_buffer
- vardump 5y ago
  Weird. First idea that came to my mind was to use a linked list of lines.
  - arc-in-space 5y ago
    Close, but not ideal - lines are occasionally very long, and you're wasting nodes on sequences of newlines. There's a number of useful data structures that can do this well, like a 'rope'.
  - ahefner 5y ago
    It works. Many editors have used this approach.
  - dvfjsdhgfv 5y ago

TrackerFF 5y ago

"What's frustrating is people who think that they can radically simplify something without knowing anything about it." This type of mentality is also rampant in the world of entrepreneurship - Theranos et.al Sure, it's good to get new eyes on some problem, but it's the hubris that can kill.

Frost1x 5y ago
If you want to see extremely toxic, combine this mentality from the business side with confirmation bias from developers who think the same way. You get development efforts with massive scope people brush off as nothing. I've worked with a lot of these sort of groups where someone entrepreneurial understands enough to think they can simplify and improve something. Then they get a developer, two, or small team that agree. They start the undertaking or even worse, do the work under contract for someone else where they have contractual deliverables. Some way in they start to realize just how shortsighted and cavalier they were about brushing off uncertainties they either knew or didn't know about. "It can't be that hard! It's just software, it's all virtual! We don't need a bunch of capital! We just need a little bit of math! ... " All those uncertainties start to become quantities and they realize the absolute pit they dug themselves into. At that point they look for someone to swoop in and cleanup their mess. Usually it takes careful reading of the contract deliverables with liberal interpretation of what is stated and how those things can be minimally met. You really need people familiar with the types of software and systems involved and needed to achieve your goals to narrow down these uncertainties. If you don't then you're digging your own grave.

dqv 5y ago

>If we tried to reimplement this stuff from scratch, we would likely start with a simple implementation, then tack on bits when we tried to handle issues like right-to-left layouts, Unicode, emoji, anti-aliasing, text overlapping and so on. This is why I always try to look back as far as I can in a source's history to see how it started. It at least gives me a sense of the amount of work it takes to get from simple to mature.

moron4hire 5y ago

This is what I think of whenever I see someone taking a dogmatic stance on function length, conditional nesting depth, functional purity, OO-purity, etc. "Here's a person who has never worked on text rendering, text editing, GUI event systems, image decoding, etc." I have a chunk of code for implementing pointers, cursors, button clicks, and drag-and-drop in games. It's some of the gnarliest code I've ever written. It's also some of the most resistent code to "good design patterns" I've ever seen. I've written it and tweaked it and rewritten it and thrown it away and started from scratch and it always comes out the same. When you're dealing with things that have to meet long-established user expectations, it's always going to be full of little edge cases that you can't abstract away.

spaetzleesser 5y ago

"why don't you just ...", We also saw this with COVID. Plenty of people with no knowledge in infectious disease stating that the public solution was stupid and wrong but instead the obvious, simple and effective solution would be to "just do ....". Personally if that happens at work and somebody (often managers) tells us to solve a difficult problem by "why don't you just..." I usually tell them the code is available and they "can just do it" themselves. So far I have never had any takers.

lanstin 5y ago
Yeah the inner source mode is useful in several ways. “That sounds interesting, we welcome pull requests” — much nicer than “there are about three fundamental things you are overlooking.”

craftinator 5y ago

> What's frustrating is people who think that they can radically simplify something without knowing anything about it. I run into this problem with my manager a lot, who knows just enough to get himself in trouble. There's probably a term for it, but I call it the "complexity trap". He sees a problem, thinks he has an "aha!" moment, and tells me about a simple solution, and asks me to implement it. This solution, of course, disregards most of the complexity inherent in the problem. Complex problems require equally complex solutions, and if the solution is simple, it disregards the complexity of the problem, either shoveling down the ladder of abstraction, or hoping for some future state where it's not as complex.

hedora 5y ago
I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude. It has the effect of short circuiting the complexity of the problem, because it defines all the corner cases in a compact form. Interface with sloppy spaghetti systems can usually be hidden away at the edges of the system. The main problem is that less experienced engineers invariably come in and say, “A ha! I have a special corner case that doesn’t fit the abstraction.” and then try to add copy paste methods, boundary violations, and so on. As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave. HP printer drivers are a famous example of the sort of complexity reduction I’m talking about. They used to copy the entire source tree for each printer (font rasterizer, dithering algorithms, and all), then assign a full time team to maintain it. Eventually they had many thousands of full time engineers maintaining the result, and print quality was still terrible across the product line. The open source drivers reverse engineered the printers, and factored out as much common logic as possible. The printer specific code was then reduced to just implementing the wire protocol and device geometry stuff. At that point, they had better output than HP, with 1% the developer resources. Someone at HP did the same thing internally, reimplemented all the drivers in a unified way, and was promptly promoted to the executive team.
- craftinator 5y ago
  > I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude. I agree, though this is generally limited to singular problems, and usually becomes harder to implement the higher up the abstraction train you go. I've found this especially true in business logic, where you don't know what the requirements or even end goal is; by the time you're ready to apply some nice mathematical based optimizations at a high abstraction level, doing so often requires a lot of work exposing all of the information you need from lower abstraction layers. All comes down to planning. > As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave. This is specifically why I mentioned my manager haha, who will both come up with crazy edge cases that in many cases don't even apply, and will come up with "aha!" solutions to problems that ignore major edge cases. Perks of not working for a software company. Very interesting history on the HP printer drivers, thanks for sharing that. I do remember some of the evolution that they went through, from the Linux perspective, and it was amazing how that tangled mess just started to magically work, circa 2008 if I remember right.

shockeychap 5y ago

Your "Software Isn't Bloated" post reminds me of an old post from Joel Spolsky about how complexity (ie. bloat) creeps in from countless unforeseen edge cases. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... "Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95."