Don't use lisp. Normal people don't like it, it looks weird. I wonder how many projects failed because they were lisp. Normal people: Visits a project page. Sees it's a lisp. Closes page.
I am proudly not-normal, in that case.
Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
211–220 of 340 posts
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#212Don't use lisp. Normal people don't like it, it looks weird. I wonder how many projects failed because they were lisp. Normal people: Visits a project page. Sees it's a lisp. Closes page.
Don't use Math. Normal people don't like it, it looks weird. I wonder how many projects failed because they wanted to use a lot of math notation. Normal people: Visits a project website. Sees it has equations and formulas. Closes page immediately.
That's how it sounds to me. Dismissing Lisp solely based on its syntax (that you're unfamiliar with), is equally irrational as rejecting projects that incorporate mathematical notation.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#213Earlier quoted context omitted.
Emacs has a package manager...
And consequently a lot more friction to users becoming extenders.
"A friction" you say? You can run Emacs, open a scratch buffer and extend it right away. You don't even have to save the damn code, you can try it out immediately. Folks complaining about Emacs being hard without even trying to understand any Lisp, is on the same level of whining about how web-development is so much harder compared to building shit in Squarespace (or something), only because you can't figure out HTML, CSS and Javascript.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#214Realize that VI was the superior editor, give up on the endeavor, print out the code I had already written for emacs, shred it, then set the shredder unceremoniously on fire. For those that downvote me, worth it.
Strategically thinking, after setting the shredder on fire it will be harder to shred the code of the future emacs clones! :D
> Strategically thinking, after setting the shredder on fire it will be harder to shred the code of the future emacs clones! :D
The most realistic future is that emacs begins shipping with a self-shredding feature. C-h s
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#215Earlier quoted context omitted.
And consequently a lot more friction to users becoming extenders.
"A friction" you say? You can run Emacs, open a scratch buffer and extend it right away. You don't even have to save the damn code, you can try it out immediately. Folks complaining about Emacs being hard without even trying to understand any Lisp, is on the same level of whining about how web-development is so much harder compared to building shit in Squarespace (or something), only because you can't figure out HTML…
Compare to when you'd go to use an add-on, and it would be one text file, right on your screen, and you would think:
. o O ( hey, I get some of this, and I can just start tweaking it here... )
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#216Earlier quoted context omitted.
> - Implement better sandboxing and security measures for extensions. Why, pray tell, should this be of any concern at all? Sandboxing is used when the host is concerned about running programs that he doesn't trust. There is no reason that an Emacs package would require security measures around it, unless it were knowingly potentially malware. The only reality in which I could see this is if people were using proprie…
Well, Emacs does ship with a browser (because of course it does, that kind of thing is what makes Emacs so amazing) and we all remember the XZ Utils near-backdoor, so I think that security measures would be useful for people who decide to use a less trustworthy archive like MELPA or who install extensions with package-vc.
The biggest security nightmare that web browsers have to deal with is that they are always continuously running random JavaScript. Emacs' browser doesn't handle JS, which is a good thing for a simple browser. Emacs doesn't share this problem in that the Elisp that you run is all chosen by you, and it's always free and never obfuscated.
I don't really see how the XZ backdoor is relevant to this conversation, since these types of exploits are the fear of server operators, and generally not people who run user programs like Emacs on their desktop. A rogue Elisp function could delete all of the files in your home directory if it wanted to, but people don't really complain about that because being able to delete files is a desirable function.
If you ask me, Emacs is a program where user freedom is and should be the ultimate goal. Adding security features that the user has to jump around 'for his own good' and only really serve as idiot nets are dubiously effective and only hinder this freedom. If someone wants to install a package from a source other than the official archives, then the trust is placed in him to actually look at the source code he's received. Even if you install an official package you should still look at the code, as it's quite useful to know what's going on inside it when you want to configure it or add functionality. The vast majority of packages I use are a single file and tend to not take up more than a few screens, so they are easily understandable.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#217Realize that VI was the superior editor, give up on the endeavor, print out the code I had already written for emacs, shred it, then set the shredder unceremoniously on fire. For those that downvote me, worth it.
That just means you have not reached the point of understanding the philosophy of Emacs. Comparing Emacs and Vim with a one-sided perspective like yours is like saying that motorcycles are better than trains. Sure, they both serve the purpose of reaching from point A to point B, but there's a lot more to it than just that. Similarly, Emacs is far more than just a text editor. Vim's model of navigation is an amazing, beautiful, powerful, and pragmatic idea. Have you ever used it anywhere else than Vim/Neovim? You see, the thing is, there's no such thing as a "vim-plugin", and I'm saying this with confidence of a die-hard vimmer. I've tried them all - different ones - IdeaVim for IntelliJ, Sublime Vim plugins, VSCode extensions, etc. All of them are pretty much filled with laughable deficiencies; they are not even shadows of the actual Neovim experience. With one notable exception, and that is the vim-implementation in Emacs. In Emacs, Evil-mode doesn't even feel like an extension, an afterthought; it feels like it's a baked-in, major feature of the editor. More than that, it can do certain things even better than you can do it in Neovim.
If someone had built a passenger plane with vertical take-off/landing capability, a mere accidental feature of the aircraft that nobody was even supposed to use, I would still respect the heck out of it because the mere presence of it would be proof of ingenious engineering. If you think that "VI is a superior editor than Emacs", I'm afraid you still have a shallow understanding of both.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#218Honestly I think you could go a long way with default evil mode, and updated documentation with evil keybindings in mind.
I hope not. Watching the Emacs ecosystem evolving over the years, I'd wish that most things were not default or built-in but came in packages, and Emacs was a tiny, extremely small core. Packages outside of the Emacs core develop faster, evolve better, foster communities around them, have greater flexibility of choice - where to host them, how to license them, how to structure them, etc. Evil-mode, Magit, Projectile, CIDER, etc., they are all great because they were developed outside of the Emacs' core. I can only imagine how Evil+plugins would've slowly decayed with endless email threads on the Emacs-devel mailing list, where RMS would've annoyed everyone asking "why are we trying to build Vim in Emacs instead of Microsoft Word, I've dreamed about WYSIWYG, and you guys are ruining it...".
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#219Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#220I like emacs for its flexibility and its ability to be a platform for people to build just about any extension. So for this you'd need a solid scripting language. I was never sold on Lisp but it's fine. I'd prefer to see lua; it just makes more sense. The repo-reference stuff works pretty well all things considered. If it were python it would be hell. Crazy side of me would like to see it fully written in a safe(r) l…
> I'd prefer to see lua; it just makes more sense.
To you. To me it wouldn't. If it was Lua, I'd still use Fennel. If it was Javascript, I'd do it in Clojurescript; If it was in C, I'd probably find a way to use Common Lisp or Jannet; If it was Python I'd probably use Hylang or something; if it for whatever reason used JVM (like IntelliJ) or .Net CLR, I'd do it in Clojure.
You see, once you actually grok Lisp, at some point you do become a true "polyglot programmer" - for me switching between different runtimes - JVM, Node, Browser, Native, Lua, etc., is as simple as picking up a different Lisp dialect. Even switching between JS and TS for most programmers is not as simple as for me jumping between different Lisp dialects.
I'm not some indentured servant of one particular programming language, your favorite bits of syntactic sugar and "design patterns" made for one particular PL don't amaze me, don't annoy me, don't make me feel bad or good, I simply don't care. I just want to build shit, and I want it to work. I'm sure if there's an actual God, and he had to explain the universe in written form, it would be in homoiconic scripture - anything, yes, just about anything can be explained in functions, neatly wrapped between parentheses, anything beyond that is fluff made by human pride, simplicity requires less not more.