Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Text editing hates you too (2019)

lord.io

Post reply on HN
Print view View original

101–110 of 187 posts

Re: Text editing hates you too (2019)

#101

Post by ratww »

bsder wrote: post #79
colllectorof wrote: post #47

Earlier quoted context omitted.

More often than not a problem that looks simple and has insane complexity once you dig a bit deeper is based on some faulty assumptions. Assumptions that either changed over time or never made sense to begin with. The wast majority of software systems out there are significantly simplifiable. However, not all developers are willing to analyze and question fundamental assumptions about systems they deal with. Most, in…

> The vast majority of software systems out there are significantly simplifiable. 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.…

> Most programmers don't just write lines of code for no reason. They generally stop when the problem is solved.

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.

Re: Text editing hates you too (2019)

#102

Post by alex_smart »

edoceo wrote: post #92
alex_smart wrote: post #88

Earlier quoted context omitted.

Does that mean that Geniuses would be terrible software engineers, since removing complexity is seldom the right thing to do business-decision wise?

What? IME removing complexity removes costs. That's a good choice. I can't think of a case where it didn't happen. Of course this only works for the removable complexity, which is discovered through analysis (possibly iterative/recursive)

Time spent removing complexity is time not spent developing features. And your users/clients care more about features than complexity (which is completely invisible to them) or even speed. They don't even care if your app runs 10 times slower than it needs to, as long as it runs at an acceptable speed.

That is why software engineers are seldom rewarded at their companies for "removing complexity", only for finishing projects.

Re: Text editing hates you too (2019)

#103

Post by exporectomy »

notriddle wrote: post #87
colllectorof wrote: post #47

Earlier quoted context omitted.

More often than not a problem that looks simple and has insane complexity once you dig a bit deeper is based on some faulty assumptions. Assumptions that either changed over time or never made sense to begin with. The wast majority of software systems out there are significantly simplifiable. However, not all developers are willing to analyze and question fundamental assumptions about systems they deal with. Most, in…

> More often than not a problem that looks simple and has insane complexity once you dig a bit deeper is based on some faulty assumptions. Okay, I'll bite. What are the faulty assumptions that cause text editing widgets to be so complicated?

Perhaps the assumption by Unicode that we need emoji modifiers instead of just more emojis. All ~2000 valid combinations are enumerated anyway and many require different images so they're effectively different isolated characters.

Re: Text editing hates you too (2019)

#104

Post by alex_smart »

ratww wrote: post #96
alex_smart wrote: post #88

Earlier quoted context omitted.

Does that mean that Geniuses would be terrible software engineers, since removing complexity is seldom the right thing to do business-decision wise?

No, it doesn't, and no, it isn't. As much as some people like to pretend it doesn't exist, accidental complexity is a thing, and reducing it is part of our job. Also, there are ways of removing complexity of processes before they are turned into software, but that requires talking with people and agreeing. Not every program has to do everything.

>accidental complexity is a thing

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.

Re: Text editing hates you too (2019)

#105

Post by josephg »

alex_smart wrote: post #95
bsder wrote: post #79

Earlier quoted context omitted.

> The vast majority of software systems out there are significantly simplifiable. 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.…

>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. 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 imprecis…

Yes exactly.

> 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.

Re: Text editing hates you too (2019)

#106

Post by blake8086 »

oneeyedpigeon wrote: post #89
leoc wrote: post #66

Earlier quoted context omitted.

Alan Perlis' old motivational-poster slogan "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." has a fair bit going for it.

I love that apart from the "Some can avoid it" bit — feels out of place with the rest. Who's "some"? Pithy slogans often come in three parts rather than four; I love the overall message, I think I'd just prefer it with that 25% removed.

You're a genius.

Re: Text editing hates you too (2019)

#107

Post by trnglina »

bombcar wrote: post #31
zaptheimpaler wrote: post #27

Earlier quoted context omitted.

?srekaeps hsilgne-non lla rof sdrawkcab txet lla ekam ot si noitulos ruoy oS

It's not the last time major portions of the world fundamentally changed how they did things to align with the major powers at the time. 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!).

Sure, but not all people who use computers are programmers, and programmers make up a small minority of computer users. Much of the value in computers come from augmenting other workloads. There are no shortage of people composing e-mails and documents, or consuming content, in non-English languages. Probably more than there are fluent English users.

Re: Text editing hates you too (2019)

#108

Post by slmjkdbtl »

alistairw wrote: post #94
slmjkdbtl wrote: post #83

Earlier quoted context omitted.

> This is a ridiculous mischaracterization of what Jonathan Blow was talking about. I watched the full presentation and agree with almost everything he said, but I can't find a part matching the conflict between "Simple text editor Vs. Complicated character encoding scheme / rendering / formatting". How would JB make a text editor that works with any kind of character?

I agree with the sentiment you're getting at about nostalgia for the past sometimes ignores the homogeneity of the people using those systems and how that reduced complexity. I do think there's an argument there that needs to be explored further to identify what is actually simple and hard/complex in computing. However, I think this point about how JB specifically would make one with any type of character is not the…

Yeah I agree making an editor that supports any type of character is not the best way to explore this subject, but I doubt the result of this exploration can solve that editor problem.

I follow a similar mindset of JB and have being making / using my own tools, even my personal character encoding (I have Chinese as my first language and want to use Chinese in my works but Unicode is too messy and it's impossible to make a font that supports thousands of characters so been developing my subset of Chinese that fits in a byte), also my own game engine / renderers / programming language (similar to JB's stack) My experience is these softwares are too personal and not applicable the the real general public. JB also makes personal softwares and won't consider about generality. Personal softwares are inherently better, because the bloat and bad about current state almost all comes from derailed generalization effort. If we take the beautiful DOOM editor and make it general, it'll be real hard to not make it another Unity, and that's the real under-explored problem.

Re: Text editing hates you too (2019)

#109

Post by edoceo »

alex_smart wrote: post #102
edoceo wrote: post #92

Earlier quoted context omitted.

What? IME removing complexity removes costs. That's a good choice. I can't think of a case where it didn't happen. Of course this only works for the removable complexity, which is discovered through analysis (possibly iterative/recursive)

Time spent removing complexity is time not spent developing features. And your users/clients care more about features than complexity (which is completely invisible to them) or even speed. They don't even care if your app runs 10 times slower than it needs to, as long as it runs at an acceptable speed. That is why software engineers are seldom rewarded at their companies for "removing complexity", only for finishing…

Sounds like our companies and clients are very different. As for the feature/maintenance trade-off, a reasonable CBA will show the answer. I don't think it's quite as absolute as you've described.

Re: Text editing hates you too (2019)

#110

Post by alex_smart »

josephg wrote: post #100
alex_smart wrote: post #88

Earlier quoted context omitted.

Does that mean that Geniuses would be terrible software engineers, since removing complexity is seldom the right thing to do business-decision wise?

Most things in life and programming exist on a trade off curve of goodness vs simplicity. Making the thing better means giving up simplicity. Making it simple means removing features people want. 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 i…

>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)

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.

Post reply on HN