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

111–120 of 187 posts

Re: Text editing hates you too (2019)

#111

Post by madhadron »

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?

That text is a sequence that we edit by having a cursor into it as opposed to a specialized form of graphics, maybe? We've inherited the controls of a typewriter (which provided a very simple graphical model for a narrow range of languages), but maybe they aren't what we need?

Re: Text editing hates you too (2019)

#112

Post by torstenvl »

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…

You're right that, given a set amount of programming time, working on features versus working on performance is zero-sum.

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.

Re: Text editing hates you too (2019)

#113

Post by qsort »

Groxx wrote: post #91
qsort wrote: post #67

Earlier quoted context omitted.

`ed` was developed in 1969. That's a remarkably uncharitable take, considering `ed` itself and its derivatives (like `sed`) are still useful today.

This is accurate in the same way as saying "a rock chiseled into a wheel with a stick as an axle is still useful today". Or maybe "a mechanical calculator and a book of logarithms is still useful today". Sure, it still exists and still does what it used to do, and its derivatives surround us. But nobody does that any more because nearly everything else is so superior, it'd be ridiculous to do so , except as an art pi…

That's not a fair analogy at all.

sed is basically the stream interface for ed and it's one of the most common unix text utilities, and even ed has its uses today. I remember using it on a machine I was remotely connected to. For some reason the terminal output was garbled and neither vi nor emacs would render properly, but ed worked fine. Obviously you wouldn't use it day to day, and yeah, you wouldn't use if you have any alternative at all, either. But the fact that it still has some form of (admittedly very limited) competitive advantage over modern tools makes it useful to have /bin/ed handy, even if you actually use it once in a blue moon.

Re: Text editing hates you too (2019)

#114

Post by alex_smart »

torstenvl wrote: post #112
alex_smart wrote: post #102

Earlier quoted context omitted.

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…

You're right that, given a set amount of programming time, working on features versus working on performance is zero-sum. 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…

> Plenty of swearing happens because the computer just won't respond or it's taking whole minutes

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.

Re: Text editing hates you too (2019)

#115

Post by recursive »

alex_smart wrote: post #104
ratww wrote: post #96

Earlier quoted context omitted.

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.

Even after removing some, there's still likely to be some less. It seems like it's probably good to remove it, all else being equal.

Re: Text editing hates you too (2019)

#116

Post by ratww »

alex_smart wrote: post #104
ratww wrote: post #96

Earlier quoted context omitted.

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.

Of course it's is valuable. Complexity makes software expensive to make, so removing it is literally worth a lot of money that can be better spent making features. Nobody buys software because it's accidentally complex, they buy it because of features, quality (which is something that's also affected by complexity!), etc.

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

Re: Text editing hates you too (2019)

#117

Post by pcr910303 »

> This is why, on the web, text input and keypresses are separate events. Terminals conflate these two, causing problems.

Yeah, so please don’t create terminal TUIs please. Very disturbing to use TUIs that don’t work with CJK languages at all. Please, please create GUIs instead of TUIs. (I’m not blaming programs reading from stdin and printing data to stdout, but the ones based on ncurse and fill the terminal screen.)

Unfortunately the status quo on text editing didn’t improve since the last time this came up on HN. Unfortunately everything I said the last time[0] still applies…

[0]: https://news.ycombinator.com/item?id=21384596

Re: Text editing hates you too (2019)

#118

Post by recursive »

slver wrote: post #90
KineticLensman wrote: post #64

Earlier quoted context omitted.

my link contains programming languages based on Arabic, Chinese, etc, not just unreadable esolangs

Let’s face it. Your link defeats your own point.

Independent third party here. I don't think it does, and as such, don't think it would really be appropriate to face it.

Re: Text editing hates you too (2019)

#119

Post by recursive »

slver wrote: post #61
crazygringo wrote: post #49

Earlier quoted context omitted.

Pride doesn't even matter here. It's simple economics. 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.

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

Even though we're basically doomed, we can still do a lot of cool and fun things at the moment though.

Re: Text editing hates you too (2019)

#120

Post by Aeolun »

pcr910303 wrote: post #117

> This is why, on the web, text input and keypresses are separate events. Terminals conflate these two, causing problems. Yeah, so please don’t create terminal TUIs please. Very disturbing to use TUIs that don’t work with CJK languages at all. Please, please create GUIs instead of TUIs. (I’m not blaming programs reading from stdin and printing data to stdout, but the ones based on ncurse and fill the terminal screen.…

But uh, I create these UI’s for myself. Why would I consider CJK languages?
Post reply on HN