Hacker News Reader

Comment by 098799 | Hacker News Reader

I wonder how do people come to a decision that it's a good idea to start their own text editor when vim and emacs exist. For this one my guess is the author is a c/c++ developer and wanted to have their editor cusomizable in their desired language. Would that be enough?

It's also not a common thing for projects like that not to start as FOSS.

View on HN

There's a sizeable cohort of people (that overlaps largely with the "handmade network") who are tired of hearing "don't reinvent the wheel" and see virtue in rebuilding software. I think it's a good attitude personally, since it's _how we get better things_.

    - Fun
    - Learning new things
    - No decades old quirks & constraints through backwards compatibility
    - Same concept with fresh ideas & multithreading

A lot of good reasons imho, which is why I'm also tinkering with my own little editor. In the worst case I'll have learned a ton and have a small collection of useful libraries. Some innovation in modal editing after 30 years might be nice.

> I wonder how do people come to a decision that it's a good idea to start their own text editor when vim and emacs exist.

Vim/Emacs have a huge community and ecosystem, but they aren't exactly perfect. I don't see anything weird about people writing their own editor.

I'd personally love to have a Python-programmable editor a la Emacs, and if I ever write a text editor, it's gonna be like that.

Eh, it's part of the handmade effort. Sometimes building your own tool is just fun.

+ You don't need to learn a bespoke language to customize 4coder (vim_script in vim's case)

> I wonder how do people come to a decision that it's a good idea to start their own text editor when vim and emacs exist.

It's really a smaller decision compared with the point of view that text files as source code are "holding back our tools - https://dion.systems/dion_format.html

So these guys are really thinking big.

If text files are holding you back. Smalltalk exists...

What do you mean by that?

In Smalltalk there is no such thing as source files. Your program is an image which can be freely modified and dumped. Look at Pharo[1] which is a modern Smalltalk environment. You start it up and create classes in the IDE, but never do you create "source files".

[1] https://pharo.org/

"6.18 Saving code in a file" Pharo 9 by Example, page 75

https://books.google.com/books?id=hfpwEAAAQBAJ&lpg=PA75&ots=...

> In Smalltalk there is no such thing as source files...

    $ cat fact.st
    Stdio stdout 
        nextPutAll: 100 factorial printString; 
        nextPut: Character lf.!
    SmalltalkImage current snapshot: false andQuit: true!

    $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st
    93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

I was obviously simplifying it for my explanation as I didn't want to write a story. Yes you can file-out and file-in but thats not the primary mode of operation when working with the IDE.

Look where that wrong explanation leads —

"#1 it's a burden of knowledge to shift from the Unix filesystem to the Smalltalk runtime. There... are no files."

https://news.ycombinator.com/item?id=31474424

"Pharo by Example" doesn't need a wrong explanation —

"It may seem like the image file should be the key mechanism for storing and managing software projects, but in practice that is not the case at all. There are much better tools for managing code and sharing software that is developed in a team. Images are useful, but you should be very cavalier about creating and throwing away images."

"2.5 Saving, quitting and restarting a Pharo session" Pharo 9 by Example, page 14

https://books.google.com/books?id=hfpwEAAAQBAJ&lpg=PA75&dq=p...

Damn, that sounds really cool. The IDE has some amazing features too. The IDE states that you can modify the program while it's running is that actually working well? Cause it seems like a very volatile feature that can go very poorly.

Just because you can doesn't mean you must — it depends on your process.

https://en.wikipedia.org/wiki/Hot_swapping#Software

> The IDE states that you can modify the program while it's running is that actually working well? Cause it seems like a very volatile feature that can go very poorly.

It's actually a paradigm that works well in many programming languages besides Smalltalk such as Common Lisp, but for some reason seems to be forgotten with "modern" and "trendy" programming languages. Except for.... JavaScript!

Yea, being able to customize with C++ is peferable for some people compared to vimscript/lisp/etc. Then you have the issue where emacs and vim can choke under reasonable file sizes. The other part is vim/emacs aren't as performant as they could be

Though good and powerful editors, there are reasons why emacs and vim have a very small user share. (Everyone I know prefer VSCode when not using an IDE.) Even JEdit and Sublime each have a dedicated but a comparatively small userbase.

Proably of the people you know also only a small share is active on HN. At least that's the case for me.

I'd guess amongst HN users the share of emacs and vim users might be higher than for developers in general.

Both are dead in the water architecturally if you want to use a text editor that can render fonts and other graphics at 60 fps on a normal desktop.

You don't need to render anything at 60fps. Emacs is not a game, it only renders when needed and that it does pretty fast.

Reply on news.ycombinator.com