71–80 of 187 posts
Earlier quoted context omitted.
Especially since the text editor in question is `ed`, which is not exactly a pinnacle of utility. We're really comparing apples to moon rockets here.
`ed` was developed in 1969. That's a remarkably uncharitable take, considering `ed` itself and its derivatives (like `sed`) are still useful today.
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.
No more uncharitable than saying that modern developers suck at their jobs because they can't make Sublime Text in the same time as it took Ken Thompson to make ed.
Earlier quoted context omitted.
as I said > Of course, this is not universal and only works with monospace fonts in certain languages. But even then, monospace didn't go away. Most developers are working with code in monospace right now.
Monospace is the more sensible option as an editing medium for symbolic content. It's in having "WYSIWYG" editors that do everything in one modeless widget that we start getting this particular kind of feature creep. And considering how awful it tends to be to navigate a complex word processing task in Word or LibreOffice even now - mystery-meat selections abound - I'm not sure this is the right feature to support al…
Proportional fonts are more aesthetically pleasing and legible (the entire reason for their existence).
When I'm editing "symbolic content", I like it to be easy on my eyes. If I'm constantly re-reading what I've just written, I appreciate the added legibility.
(With the exception of heavily punctuation-based computer code, of course, where monospace results in greater legibility.)
Regarding the vertical cursor movement, back in the day there was an alternative behavior. You can see this in QuickBASIC/QBasic[1]. Here, Microsoft treated the entire screen as a grid. I always thought that was a great UI. It hides the fact that there are line endings (\n on Unix or \r\n for DOS). And why shouldn't it? That's an implementation detail. And as evident by DOS using CR+LF it goes back to the days where…
> you have to type out the spaces/tabs you want to reach the area you what to add text If you move the cursor to an empty area and start typing, should the missing characters be tabs or spaces then? Or NULs? Also, how do you insert spaces/newlines/tabs in between other text? Everything would be implicitly modal. It's good UI for some things, but it's not as good for a general editor like vim. I'm not looking forward…
> should the missing characters be tabs or spaces then?
I'm not sure what QBasic does. But it's irrelevant since they control the format and the display. All Microsoft needed to care about is whether the file displays the same as before when loaded.
But it's really no different than text editors that let you switch a tab character to insert 2/4/8 spaces. If you've ever had the misfortune of working on a code base that allowed both tabs and spaces (fake tabs) then you'll be keenly aware that plaintext has always been modal. Your editor either has to figure out how many spaces to display a tab character, or how many spaces to insert on the tab key. Even line endings, CR+LF vs. LF. I think Mac even just used a single CR once upon a time.
Makefile is another format that is particular about requiring an actual tab character. The first time I "discovered" this I had the urge to toss my computer out the window. That was probably the late '90s when that sort of information was a bit more difficult to come across.
Earlier quoted context omitted.
Sadly, that's not a possible alternative behavior for a world where proportional fonts exist. It's for monospace only.
as I said > Of course, this is not universal and only works with monospace fonts in certain languages. But even then, monospace didn't go away. Most developers are working with code in monospace right now.
I liked doing ANSI art back in the 80s, but that's not really interesting outside of terminal connections to a BBS.
For people involved with technology I think this is a perfect response to "how hard can it be" - no matter if they're discussing how to keep toilet paper stocked or why cURL can be replaced with five lines of shell script - it emphatically shows how complicated something apparently simple can be once you start diving into it.
Regarding the vertical cursor movement, back in the day there was an alternative behavior. You can see this in QuickBASIC/QBasic[1]. Here, Microsoft treated the entire screen as a grid. I always thought that was a great UI. It hides the fact that there are line endings (\n on Unix or \r\n for DOS). And why shouldn't it? That's an implementation detail. And as evident by DOS using CR+LF it goes back to the days where…
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.
I see it the other way. It would be actually orders of magnitude less effort for the rest of the world to learn one standard system/language than to have every app/product/document adapted to every single language/script/whatever in existence
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 on a web page and instantly provide a text input for every internet user around the globe.
For people involved with technology I think this is a perfect response to "how hard can it be" - no matter if they're discussing how to keep toilet paper stocked or why cURL can be replaced with five lines of shell script - it emphatically shows how complicated something apparently simple can be once you start diving into it.
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…
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.
For people involved with technology I think this is a perfect response to "how hard can it be" - no matter if they're discussing how to keep toilet paper stocked or why cURL can be replaced with five lines of shell script - it emphatically shows how complicated something apparently simple can be once you start diving into it.
I think there's some context that matters. I often don't need the full functionality of übertool and can implement the functionality easily because I don't have to worry about 90% of use cases with their associated edge cases. It's dead simple to keep toilet paper stocked in my house. But I would not use the method I use for my house to run inventory for a grocery store chain.