I think exactly the opposite, actually.
Most programmers don't just write lines of code for no reason. They generally stop when the problem is solved.
So, you might be able to simplify new programs, but I wouldn't put a lot of money on it. The programmer would have had to miss something architecturally up front for that to be the case. It happens, but it's not that common.
So, you might be able to simplify production programs. Maybe, but those have a lot of bug fixes already implemented. And they encode the political state of the entity that built it (see: microservices). So, a program that has existed a while may not encode the current political system, but I don't think fixing that is making things simpler.
So, you might be able to simplify legacy programs. Perhaps, but those have a LOT of business state encoded in them--much of which is still used occasionally but you won't know that until you do a deep dig on the code. That rule for disbursements to Civil War descendants is there because the system still needed it up until a couple years ago.
Oddly, the best way I have found to simplify computer systems is to give the humans more power. Humans are good at exceptions; computers not so much. This is, sadly, anathema to modern programming and modern political/corporate structures.
It is very, very common indeed. Seldom is software created with all the requirements and complexities of the problem known upfront. In fact, very often the process of development of the software itself reveals all the different ways in which the original specifications were imprecise and not completely thought through. And new features and requirements get added onto later all the time.
Software is created in an iterative process of feedback and development. At each stage, the programmers takes the shortest, most straightforward approach to solve the problem. When the programmers are not careful (or just lazy) they inadvertently add dependencies that shouldn't exist and make the whole thing more complex. Of course, any single infraction seems innocent enough, but eventually you almost always end up with software that is much more complex than it needs to be.
Here is a talk on how software is too complex all the way from 2006. I am more than confident that the problem has only gotten worse in last 15 years.
https://www.kernel.org/doc/ols/2006/ols2006v1-pages-441-450....
> At each stage, the programmers takes the shortest, most straightforward approach to solve the problem.
Unfortunately, this is the often the best case. There’s a point in the life of most good programmers where they can’t help but to massively over engineering everything they make, adding pointless interfaces and abstractions everywhere, to chase the dream of reusability. This mindset will utterly bury your capacity to iterate.
I once saw a Java method trail to initialise something which was 19 levels deep - each level just making one method call to the next abstraction. You couldn’t just trace it in the IDE - lots of those calls called an interface method or something, so you had to hunt down the implementer. But it got worse. There was also a method trail alongside it for cleaning up that context. It had the same 19 levels deep trail, but after all that work the final callee was an empty function.
If only. Over-engineering is definitely a thing. And programmers definitely miss something more often than not, even when over-engineering. Or even: especially when over-engineering.
But you could be a some. But if you were a some it would mean that there was no possibility of actually removing the some from the statement because it actually did describe accurately that there were somes that could avoid it.
So it is sort of a Gödelian joke.
"Some can manage to get the thing done by avoiding the complexity, geniuses remove the complexity for everyone"
Charles H. Moore, e.g. -- the 25% pulls its weight.
Yes, and it's often the best feature of the software, as far as the sale teams is concerned, because it allows them to sell concultancy fees or because it satisfies the customer by matching 100% it's crappy requirements (which they don't really need).
Of course it is, in fact it is pretty much all-pervasive in our field, even in very successful software companies - which makes me question whether removing it is as valuable as people make it out to be.
You can spend 5 years customizing off the shelf ERP software to do insane things because John in accounting and Jane in HR won't budge from weird processes they built over the decades... Or you can use that opportunity for business transformation, simplify their processes and their program, save money, reduce errors, improve responsiveness and timeliness, and generally make it a win win win.
Not all complexity can be reduced of course. I can imagine self driving cars, rocket science, etc are all about critical edge cases.
But when it comes to business, and particularly back office processes (where a huge amount of IT goes) , a lot of complexity is unnecessary. Each company each department each person is certain they are special, unique, and their requirements are paramount and unchangeable. But if you move around a bit you'll come to believe otherwise.
The only reason complexity is prevalent is due to a shortage and geniuses (and also a shortage of "Some" too, if we're going by Alan Perlis' quote).
Geniuses invent new ways to get both. Those ideas permanently move the trade off curve outwards.
In programming, some abstractions which have done this are: Operating systems (Abstracting away the hardware), Grace Hopper’s invention of program libraries, high level languages and compilers, HTTP and JSON, tcp/ip (replacing custom transmission protocols), and there’s lots more. Calculus and the Arabic numeral system are examples in mathematics. (It’s insanely difficult to multiply using Roman numerals!)
He made the point (I think) that you do want simplicity, you don't want simplistic. That is: it should be able to do all the things you want to, but in an easy to use manner.
Worth striving for I believe.
To me, simplicity means that there's clarity of purpose for each component and how it interfaces with other components. A large system can still be simple if the interactions and interfaces between the different components are reasonably well understood and justifiable. I think thoughtful UI design is how you prevent complexity. The UI for developers and software is the API.
When you start adding features and instead of generalizing you simply (heh) add a special case to allow two unrelated components to communicate, and then another, and another, until the two components become dependent on each other such that neither can do anything without the other; then you have a complex system, and the "UI" for the developer is worse because it's full of seemingly random elements in random places that only do one very specific thing.
How many of us get to work at such lofty problems though?
>Calculus and the Arabic numeral system are examples in mathematics.
Eye roll. Of course reducing complexity is the very essence of mathematics. Let us not pretend that software engineers are mathematicians.
How many of us choose to work on such lofty problems? You can work on whatever you want, whenever you want. But lofty, unproven ideas don’t pay Google salaries. Your career is a choice, not a prison.
And of course most software engineers aren’t mathematicians. We’re talking about genius - and most of us are a long way from that. Most of us are lucky if we manage to invent a couple complexity reducing concepts in our entire careers.
But lots of great computer science ideas have “come down the mountain” from mathematics adjacent work. Functional programming wasn’t invented by C lovers like me. But I love closures, pure functions, and map / filter / reduce. This stuff makes certain problems lovely. And we wouldn’t have any of this without mathematically minded CS.
That is why software engineers are seldom rewarded at their companies for "removing complexity", only for finishing projects.
But that doesn't mean you should always work on features. If anything, it only means that feature-bloat is doubly bad, not only adding logic and binary size, but imposing opportunity cost.
Most users hate features. Nobody has ever sworn at their computer because they had to make a mess in Excel to use VLOOKUP() before XLOOKUP() was invented (even though I love XLOOKUP()). Plenty of swearing happens because the computer just won't respond or it's taking whole minutes to send each email when you're trying to leave work on Friday night.
Of course, my point was that it is usually not beneficial to worry about performance until that happens. And when it does, improving the performance of the product becomes a project in its own right. Misbehaving parts of the software are diagnosed and fixed, usually by introducing even more complexity.
Okay, I'll bite.
What are the faulty assumptions that cause text editing widgets to be so complicated?
Presentatuon is huge too, How do we render a pasted newline into a single line block? Where do you put the cursor if someone pastes a block of Arabic text into your multiline input? What do you display if your font doesn't have the character they've copied and pasted from another source?
There's also just the basic stuff of "every keypress/chord equals a new character" - I have an app that I use every day that renders Ctrl + backspace rather than deleting the word?
Then there's input considerations; Macos uses alt for per-word navigation, windows uses Ctrl. Do you support the OS input type, or do you support a popular editor bindings (emacs) and how do you differentiate between an input to display and an input to take a navigation from? What about mobile? Most boards support input gestures, and autocomplete suggestions. How do you know to modify your current context over appending it to your input?
Finally, what about non-renderable input? If you're modifying a rich text string, how do you escape from a block, or how do insert between two separate blocks?
This. My name is Kayodé Lycaon. Note the é... how many places don’t support it? Some people consider names to be sacred and changing the spelling is more than a little offensive. Even UTF-8 can’t represent all characters in use. I believe there are Japanese names that can’t be represented by its character set.
I get it’s technically difficult but so many places treat people who are different as edge cases to be optimized away.
Over the course of my life and in my thirties especially, I've watched a lot of movies.
The Cursed Computer Iceberg Meme
https://gizmodo.com/youre-drawing-icebergs-all-wrong-1846329... https://joshdata.me/iceberger.html
I'll try to create an unobtrusive watermark
Ps: I just sent this to everyone I know.
It most commonly afflicts organizations with management that insists upon KISS interactions from their direct reports, but then micromanages the details when the going gets tough (scrutiny from higher layers). Some of the more common phrases you will hear in these interactions is, "I don't understand why this has to be so complex", or "Give me the 50 thousand meter/foot summary". They elevate their mental model of the domain to a level where they cannot resolve the granular details.
Analogous to the lack of optical resolution of any telescopes (including Hubble) we have to see the American flag on the moon [1]. You need a very massive bandwidth (the telescope diameter) to resolve those details, but then you trade off for increased processing time (analogy breaks down here).
Surprised Pikachu when they drill down, and the requirements explode in complexity. With most successful, highly-refined systems, it isn't the primary requirement that should be the focus of planning (Microsoft Word is just a text editor, how hard can it be!?). It is all of the 1% of features 1% of the market/stakeholders want that deliver 80% of the value proposition of the system to them. Stacked together, all those "corner cases" add up the value of the overall system, and add up the complexity. It isn't just a heap of features binned together; the team has to make sense of how it all fits together.
[1] http://curious.astro.cornell.edu/about-us/45-our-solar-syste...
It took years of working as a software engineer to begin to appreciate just how deep that is.
Fixed-width ASCII terminals didn't work for virtually anyone except English-speaking users.
Turns out the entire world needs to use computers.
That's a "need". Not "allowing".
But at a higher scale it’s purely incidental complexity: you only need one direction for all languages. All languages are linear. No language uses direction to encode meaning. Direction in language is just “stuff starts one place and ends in another”.
Balkanization of the encodings is not a good thing. Imagine if every city had a different color for a traffic stop light. Why not? Maybe it’s a matter of cultural pride. What if every country had its own network protocols? Imagine what a nightmare internet would be.
But thankfully we had common sense in few cases. In many others we don’t.
And Unicode is full of incidental complexity itself. Did we really need skin color emoji. Who is yellow here? Anyone being brightly yellow perchance? No. We had the perfect abstract color for emojis.
But now we have to deal with this shit.
Even WITH all the Unicode support that currently exists in the computing world I don't know of a single computer language that isn't based on English in ASCII. I guess you could count APL there (or perl!).
Unfortunately those are the times right now. We, the most adaptable and intelligent species on the planet, have become used to bragging about not having to adapt or know a lot. We sure do have really strong opinions about everything, though.
Someone who wants to program computers will most likely learn functional English, just because of how much content on that subject is in English (the "lingua franca" of computers).
But someone in Mongolia who wants to text his mom has no inclination to learn a whole new language just to handle the limitations of ASCII. And if you want to sell him a phone you'll meet him where he is.
(This doesn't even begin to touch the "it's not fair" aspect that people like to point at.)
This is why I mentioned the metric system, and what not. Every time throughout history when we decided to unify, the advantages VASTLY, and I mean VASTLY have outweighed the short-term drawbacks.
In fact I'd say, one of the biggest test for us as species is that we can fully understand, internalize and implement this concept. Because we always reach for the short term. Short term profits over long-term strategy in the enterprise. Short term economy benefits over long-term climate impact. And so on and so on.
Someone in Mongolia won't have to switch overnight. Someone in Mongolia may gain the option to have it both ways until they're used to it, and eventually there will be unification. That's basic change management.
Change management is a necessary art to survive and to thrive.
Except you're not even including the value of diversity in your argument.
"Unity" also leads to groupthink and monocultures which are less resistant to new challenges. Unity comes with costs you're ignoring.
Languages aren't just an encoding, but an entire paradigm of thinking. Eradicating linguistic differences eradicates entire perspectives.
Languages aren't just measuring systems. Culture is embedded in them too.
For proof, look up the etymology of a random set of words. They come from all over the world.
This is literally pride over encodings. It’s superficial, petty, and ignorance makes it seem profound and important.
I speak two languages fluently and they really are two different modes of thinking. That's why translation is an art, not a science, and for literary stuff it's quite difficult.
https://en.wikipedia.org/wiki/Non-English-based_programming_...
A few of the languages on the list are designed precisely to be unreadable.
So you just said all non-English speakers use right-to-left? No, the direction isn't what's confusing me, rather the fact you're trying to score a cheap outrage comment, but actually wrote non-sense no matter which direction you read it.
How about maybe educate yourself a little, and rephrase your question to reflect reality, and we can have an intelligent conversation about it.
Most of the world uses left-to-right and top-down (yes look around when you go out and notice all the vertical logotypes in English around the city). Right-to-left is relative minority. If you have democratic thinking and we gotta vote for it, the winner is obvious. Yet, I'd rather learn to read fluently English in right-to-left than the current mish-mash of "whatever".
Also read about Korean. It was a top-down right-left language, today it's written left-right. People are surprisingly adaptive, you know, it's supposedly our top advantage as a species. No one is born with "right-to-left" grafted in their DNA. We honestly gotta tone down the ignorance in these discussions.
My native language isn't English, by the way. And I don't mind adapting.
You are proposing that we teach millions-billions of people a new way to write, rather than teach a few hundred thousand at most how to write computer programs that accommodate existing ways of writing.
Like maybe you underestimate how genuinely ridiculously hard of a problem it is to get billions of people to do anything! It would take literal decades of work by multiple governments and unimaginable amounts of money! Getting 10 people to agree on a favorite programming language is hard enough. Teaching a city full of kids a new way to multiply numbers takes 1000s of hours of prep, planning, syllabus development etc. by teachers. Just imagine how much harder this is.
Certainly I can see how nice it would be if the whole world used the same date format, same language, same metric system etc.
But from a practical point of view, making systems to accommodate the way people do things is 1000s of times cheaper and easier than getting them all to change.
But the main point is still obvious and true: how would you like it if another country was a dominant technological power and we all had to re-learn to read and write English backwards precisely like that to use computers?
No need to get snarky about it. Comments like "maybe educate yourself a little" are against HN guidelines. [1]
Also, Korean is different because the characters represent entire syllables, so legibility isn't impaired as much by direction. CJK scripts have historically been flexible in direction in a way that Latin scripts never have been.
I'd actually like it.
You know, thanks to this we have Murican Internet that's the same stack everywhere. How would YOU like it if "Internet" was just your country?
We gotta disentangle this obsession with encodings as some kind of national cause for pride. Encodings are INCIDENTAL. Encodings are LEARNED. You weren't born reading right-to-left or left-to-right and you can switch both in surprisingly short amount of time, if you bothered.
It's far less effort and cost for developers to accomodate the world's existing scripts, than it is for the vast majority of the world's population to re-learn how to read and write a new script.
By orders of magnitude.
And obviously, it's not just direction that differs from English but a whole host of other aspects as well.
The percentage of the world population involved in script adaptation and language translation is really quite tiny. Consumers vastly, vastly, vastly outnumber producers.
Not to mention that we have things like automated translation that are "good enough" for many cases as well.
Whereas learning a new language to fluency, for most adults, takes about ten years.
But they don't. That's precisely why the text input handling is so difficult, because it has to solve it for all apps. How many apps have you worked on that has had to create their own text input system from scratch? I think for most developers that's zero.
Like the article said in the end:
>The necessary complexity here is immense, and this post only scratches the very surface of it. If anything, it's a miracle of the simplicity of modern programming that we're able to just slap down a <textarea> on a web page and instantly provide a text input for every internet user around the globe.
That's the short-term analysis. But this is not a short-term impact change. And in the long-term, things turn around.
If as a species, we can't think long-term, we're basically doomed.
I think an interesting example here is Chinese which is traditionally written top-down-right-left but these days is just as if not more commonly written left-right-top-down. There seems to be almost no push for supporting vertical text while its just assumed that RTL is a must, why is that?
- Asian languages needed special encodings, 256 characters weren't sufficient.
- It was impossible to work with different languages in the same document, each codepage only covered some character/alphabet.
- There was no 'safe subset': Unicode codepoints 0-127 are exactly ASCII, which means that ASCII is compliant utf8. The same wasn't true at the time.
https://www.charset.org/charsets/iso-8859-6
There’s no single byte encoding for Chinese, Japanese, or Korean though.