Live data from Hacker News

Emacs: The Editor for the Next Forty Years [video]

media.emacsconf.org

231–240 of 272 posts

Re: Emacs: The Editor for the Next Forty Years [video]

#231
post #214

Earlier quoted context omitted.

It doesn't do any kind of graphical tooling. IDEs also don't waste CPU cycles displaying HTML. C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.

In spite of all your arguments even today most important software powering modern computing are written in C, this speaks volume about its simplicity. I am sure there will still be critical software powered by C 40 years later. Rust will take another decade or two to reach that level of simplicity and ease of use still not sure if it will cross the threshold to replace C, when an average developer needs to spend year…

Yet Google, Apple, Microsoft are driving C's replacement for better alternatives, go figure.

https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

https://security.googleblog.com/2019/08/adopting-arm-memory-...

https://android-developers.googleblog.com/2019/10/introducin...

https://developer.apple.com/swift/#fast

English only became the lingua Franca after the two big wars, and even then, good luck trying to make use of English in some world regions.

I recommend reading a bit about the history of lingua francas since the beginning of mankind.

"The Last Lingua Franca: English Until the Return of Babel"

https://www.amazon.com/Last-Lingua-Franca-English-Return/dp/...

Re: Emacs: The Editor for the Next Forty Years [video]

#232
post #221
post #214

Earlier quoted context omitted.

It doesn't do any kind of graphical tooling. IDEs also don't waste CPU cycles displaying HTML. C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.

Not having graphical tooling is a net positive in my experience. I’m a programmer, not a graphic designer. Also the UI while visually clunky is neat and free of distractions. The only IDE I use these days in IntelliJ for Java - because Java is one of those few languages that really benefits from integrated development. Great as it is, I do find myself having to relearn a few things every year or so, and often having…

I happen to be a programmer that also does graphics, GUIs and GPGPU debugging, graphical display of data structures.

Then there are those architecture design documents, DB tooling integration, bug ticket/source control/task management.

Re: Emacs: The Editor for the Next Forty Years [video]

#233

Earlier quoted context omitted.

> Maybe the buffers could be disjointed from the presentation a bit, and we could have strictly AST-driven major modes Yes, good point, agree that would be a very positive direction. > elisp is indeed pretty crap Ah, I've been enjoying it a lot recently :) But I don't have an excuse to write clojure and I certainly recognize that that's a much more sophisticated thing. What are your biggest criticisms of elisp? Mine…

My main gripe with elisp is the default to dynamic binding, which is in most systems almost never what you want. In Emacs, the dynamic bindings are used for more productive reasons than in generalized programs, but they should still be a conscious choice. When it comes to threads, the elisp datastructures are inadequate because they are mutable. It is possible to write functioning threaded programs with shared mutabl…

Use dash/s/f/ . seq is fine too but dash is pretty much clojure port.

Re: Emacs: The Editor for the Next Forty Years [video]

#234
post #72
post #5

There are lines in my Emacs config files that are older than some of the programmers I work with, so I can relate. Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration. I revisit my setup every couple of years or so, and I always find it is time well spent, as my productivity goes up as a result. I do not know of a better environment for multi-language program…

And it will only get better once it understands LSP, better than it does now. It's a pale copy of VSCode's incredible LSP implementation: for a user, simply clicking the button to install the extension automagically configures a fully functional language environment; even for C++. Most of the time. When last I tried to get decent C++ support working with Emacs, about a year ago, it was still a mess of compiling rtags…

now, one just need to install lsp/eglot and clangd. Done!

Re: Emacs: The Editor for the Next Forty Years [video]

#235
post #5

There are lines in my Emacs config files that are older than some of the programmers I work with, so I can relate. Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration. I revisit my setup every couple of years or so, and I always find it is time well spent, as my productivity goes up as a result. I do not know of a better environment for multi-language program…

I largely agree, though to be fair, I did spend quite a bit of time tweaking my config and learning elisp during the first two years. At the time I was a PhD student and could afford it, but today? not sure. It was quite an investment of time but since I spend my days mostly processing text (code and prose) it paid off spectacularly well. Side note: Emacs is massively underappreciated as a tool for writing prose. So…

Curious, would you care to elaborate about the prose-writing tools? I only ever see things relating to coding in emacs.

Re: Emacs: The Editor for the Next Forty Years [video]

#236
authors seems to not know melpa and is away from emacs news.

eglot is about to ship into emacs core, emasc has pdf reader for decades and remacs is a rewritten of emacs in rust, that had contributiuon from emacs core devs too.

and guile is ready to use into emacs as a alternative to elisp

Re: Emacs: The Editor for the Next Forty Years [video]

#237
post #232
post #221

Earlier quoted context omitted.

Not having graphical tooling is a net positive in my experience. I’m a programmer, not a graphic designer. Also the UI while visually clunky is neat and free of distractions. The only IDE I use these days in IntelliJ for Java - because Java is one of those few languages that really benefits from integrated development. Great as it is, I do find myself having to relearn a few things every year or so, and often having…

I happen to be a programmer that also does graphics, GUIs and GPGPU debugging, graphical display of data structures. Then there are those architecture design documents, DB tooling integration, bug ticket/source control/task management.

Sounds like fairly specialised tools for that stuff.

I typically use a document editor, to you know, write documents ...

Re: Emacs: The Editor for the Next Forty Years [video]

#238

Earlier quoted context omitted.

You're jumping to conclusions when you're associating a syntax tree based program representation with the forced use of a mouse or cumbersome navigation for editing. Nothing could be further from the truth. A completely usable and fast keyboard based editing method for such a program representation is entirely possible. The only downside is that it's harder to create a minimal working version of such a tool compared…

It may be possible, but I haven't seen such a tool. I have seen tools where you edited the syntax tree via a GUI and it was terrible for writing code. It may work better for tree modifications. Text programs are pretty efficent when writing, editing code, because you can access a large number of elements quickly with the syntax. E.g. writing let a = 3 can be much quicker than starting some command palette from the ke…

I am working on one.

Re: Emacs: The Editor for the Next Forty Years [video]

#239
post #207
post #96

Earlier quoted context omitted.

I've been using Emacs' lsp-mode ( https://github.com/emacs-lsp/lsp-mode ) for professional Python development for months now and it's been a great experience. It requires a little more work than I'd like to get it working with virtual environments (making sure the LSP server process is running in your venv, mainly), but I would argue that's a problem with the Python ecosystem, not lsp-mode itself. And for statically…

I've tried lsp for Go and found it a bit lacking at this point. For example, does lsp for Go in Emacs allow searching for the implementers of an interface? Or the interfaces that a type implements? Guru is great with things like that but the switch to modules broke it and it doesn't look like it's ever going to be updated.

> For example, does lsp for Go in Emacs allow searching for the implementers of an interface?

This one is supported - lsp-find-implementations

The other one I am not sure (I am not a go user). If it make sense it will be added to the server.

Re: Emacs: The Editor for the Next Forty Years [video]

#240
post #237
post #232

Earlier quoted context omitted.

I happen to be a programmer that also does graphics, GUIs and GPGPU debugging, graphical display of data structures. Then there are those architecture design documents, DB tooling integration, bug ticket/source control/task management.

Sounds like fairly specialised tools for that stuff. I typically use a document editor, to you know, write documents ...

Sorry I thought we were talking about development tools here.
Post reply on HN