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

Fine, I'll build my own text editor

dbushell.com

Post reply on HN
Print view View original

221–230 of 264 posts

Re: Fine, I'll build my own text editor

#221

Post by anon291 »

kodoman wrote: post #104
cosmic_cheese wrote: post #34

Earlier quoted context omitted.

In general, I find that good defaults are rather undervalued and downplayed in the FOSS world. Configurability is great but without good defaults it can also be a liability. Would-be users will bounce off long before they like the software enough to pore through pages of options.

The terribleness of emacs defaults is over done. I still use p n postfix key combinations to go to previous and next and f b postfix for forwards and backwards, it's just what you get used to, C-w to c-y to kill and yank are also fine and it's not that much to ask the user to change things if they don't like them. Not to mention all the emacs distros that now exist for people who do want a very different configuratio…

Exactly, this my point. If you want to make a great editor, the proper thing to do is start from a good base. Start from emacs and make something like doom emacs or spacemacs, etc. Or start from vim or whatever. Text editing at speed is a solved problem. It's just 'not-invented-here' syndrome. I admit that base emacs may not be everyone's cup of tea... that's fine. Just download one of the many pre-configurations.

Re: Fine, I'll build my own text editor

#222

Post by anon291 »

not-so-darkstar wrote: post #113
anon291 wrote: post #3

I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.

>Text editing is a solved problem. I have this sentence so much. Ken Thompson wrote UNIX using a line-editor (QED), judging by his work does it mean text editing was already solved in the 60s?

The interface of text editors has not substantially changed since the time of interactive editors like VIM and emacs. Line editing is an entirely different paradigm. If you are actually going to change the paradigm with which we edit text away from the grid of characters and cursor approach, then by all means, go ahead and write your own. But if you're just making yet another text input pane, then vim and emacs have that problem solved.

Re: Fine, I'll build my own text editor

#223

Post by anon291 »

eviks wrote: post #61
anon291 wrote: post #3

I am being pushed to use vs code right now by my team, but we already have a fully programmable and scriptable editor called emacs that is 100000x better. I don't understand why everyone just switches to these random tools. Text editing is a solved problem. Most of the supposed advantages of these tools is just a configuration of vim or emacs.

> just a configuration of vim or emacs. So which one?

Whichever you want. There's a million text editors today because people have different approaches. I'm not criticizing having different approaches. I'm criticizing people who start writing their own text editor instead of just building off of established platforms.

Re: Fine, I'll build my own text editor

#224

Post by cmrdporcupine »

ryandrake wrote: post #209
mjr00 wrote: post #202

Earlier quoted context omitted.

> Kind of a bummer that 95% of software engineering is dedicated to creating a padded cell to make sure no one makes a whoopsie instead of doing creative and interesting things. s/software engineering/running a business. I'd much prefer that the people building the bridges and planes I use, or the staff at the hospital I visit, have procedures in place to prevent them from "making a whoopsie" than the space to be cre…

Yea, it's too bad that "making whoopsies" has become such a common occurrence, treated so casually, in what is made out to be a serious engineering discipline.

I mean, all engineering disciplines seemingly build in for margin of error / tolerances. e.g. Bridge, etc. are often overbuilt in case of faults in materials or expected circumstances.

I do agree our profession grapples with complexity in bad ways though.

Re: Fine, I'll build my own text editor

#225

Post by cmrdporcupine »

speed_spread wrote: post #160
atherton94027 wrote: post #127

Earlier quoted context omitted.

Honestly could you blame him for not liking Java in 2007? Between the many layers of abstractions the frameworks used, the exceptions and the sluggishness to compile it was not a compelling stack

Nothing would have prevented building a nice, lightweight system in Java in 2007 had one thrown away the conventions that had infested it at that point. Java's problem never was the language which has been as serviceable as any other since the JDK1.4 days. It is straightforward to compile (no metaprogramming, type erased generics), linking is delayed to runtime and dependencies are all precompiled to bytecode which _…

Java and the JVM does show its age specifically in one era, and that is its OO-dogmatism which it inherited from the 1990s OO wave (i-was-there-gandalf.gif). Even the opcode set in the VM reflects this everything-an-object mentality.

While it's been made to work, the JVM itself isn't the greatest VM for hosting other non-Java-shaped languages because of this.

Re: Fine, I'll build my own text editor

#226

Post by cmrdporcupine »

eloisant wrote: post #173
dist-epoch wrote: post #107

Earlier quoted context omitted.

He created Go because he believed that the average Google programmer is too stupid to program in C++, and he didn't like Java, the other language created to address this problem.

To be fair Java was created in a world where you'd run hundreds on services on a single server, run them in application server with a persistent JVM running. Now with containers, running Java apps in containers isn't great because of that JVM layer. Memory management, JVM boot time, etc. There are many things I dislike in Go as a langage but create a high level language that compiles to native makes sense in the clou…

I mean, I don't think there's nothing intrinsic to the JVM design on paper that requires this memory model. Just to the specific extant JVM implementations out there.

I haven't kept in touch with what has been happening in the Java world since I stopped working in it (uh, probbly 15 years ago) but you'd think someone would have come along at this point and created a lighter weight JVM solution that starts faster and manages memory in a more container-friendly way.

Re: Fine, I'll build my own text editor

#227

Post by cmrdporcupine »

cestith wrote: post #217
tripledry wrote: post #151

Earlier quoted context omitted.

They are probably referring to what Rob said in a presentation. "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be e…

This sounds like he's discounting Lisp, Scheme, OCaml, and Haskell in favor of something that's more of a safer, fresher take on the C language for his target group. The real competition for a language like Go these days are Rust, Zig, maybe D or Swift. Python, Fortran, JS, TypeScript, PHP, Julia, and such are mostly used in other niches. Common Lisp, Scheme, Haskell, OCaml, Objective Pascal, Ada, and several more ar…

Rust development was already in the air a bit at the time that Go made its debut. And in a shape at the time that was arguably more Go-shaped than what it became (did not have borrow checker yet, and had a managed runtime and GC option as well I think).

I personally think hubris led to Pike not working with others in the industry and Go bears the stamps of some very unfortunate idiosyncratic decisions as a result. The error handling in particular is awful. Refusal to admit parameterized types (until forced to, later) another.

I like to imagine an alternate reality where Google and Mozilla had birthed something together halfway between Go and Rust. I think the world really still needs something like this for server development; parametrized types, ML-influenced type system, proper strictly typed error handling and pattern machine like Rust / ML; native code production like both; but with GC and fast compilation and a good powerful standard library like Go.

Closest to this out there might be OCaml, I dunno. Maybe Swift.

Re: Fine, I'll build my own text editor

#228

Post by tredre3 »

bigstrat2003 wrote: post #35
nxc18 wrote: post #14

Earlier quoted context omitted.

If you work on web tech (and who doesn’t these days?) VS Code has the advantage of using the same tech stack you’re already familiar with. If you need to debug a problem, just open devtools. If you want to run a performance profile, do the same. If you want to fix a bug in the extension you’re using, just open a PR and fix it. It is a very flexible system and still quite fast and easy to configure. I’ve been trying Z…

VSCode's problem isn't that it's slow, it's that it's bloated . It takes a bit over 1GB memory (in my testing) to open the same files that Sublime can do in just 200-300 MB. In my book, it is simply not acceptable to waste my memory like that.

VSCode at least has the excuse of being a full web browser, explaining (but not justifying!) its bloat.

What's Sublime's excuse for needing 300MB to open a text file?

Re: Fine, I'll build my own text editor

#229

Post by tredre3 »

ycCantCode wrote: post #218
serchinastico wrote: post #122

Earlier quoted context omitted.

Where do you get he used AI?

The generated code and comments with emoji are very obvious

Emojis have been over-used by javascript developers for decades. Long before LLMs, the README of any javascript project was filled with emojis. A non trivial amount of projects even add emojis to their git messages!

As unpleasant as emojis are in this context, they aren't a reliable tell about AI.

Re: Fine, I'll build my own text editor

#230

Post by genxy »

speed_spread wrote: post #160
atherton94027 wrote: post #127

Earlier quoted context omitted.

Honestly could you blame him for not liking Java in 2007? Between the many layers of abstractions the frameworks used, the exceptions and the sluggishness to compile it was not a compelling stack

Nothing would have prevented building a nice, lightweight system in Java in 2007 had one thrown away the conventions that had infested it at that point. Java's problem never was the language which has been as serviceable as any other since the JDK1.4 days. It is straightforward to compile (no metaprogramming, type erased generics), linking is delayed to runtime and dependencies are all precompiled to bytecode which _…

When the Java people showed up to Python, they brought a bunch of that FrameworkFactoryItis with them, it was looking pretty bleak for a couple years. The culture that springs up around a language is as important as the language itself, even more so. It spreads to the libraries, and in turn the applications.
Post reply on HN