Live data from Hacker News

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

media.emacsconf.org

21–30 of 272 posts

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

#23
post #2

Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…

Spending time on your tools instead of your work is not a sign that you need to change your tools - it's a sign that your work sucks.

Yeah, I don't understand this theory that if your tools are at all configurable or learnable you'll be compelled to waste time yak-shaving them. I think you're right that the problem is with the stuff you're NOT doing. I use emacs every day, but there's a ton of stuff I don't use emacs for because the investment to become proficient in the emacs solution won't pay off in my circumstances. There's a middle way between writing code in nano and getting lost trying to program emacs to do your job for you.

As with everything (programming languages, build tools, optimization, etc.) there are people who go much further into the rabbit hole of text editors than you could practically justify in your own work, but 1) they might be doing it for some intrinsic satisfaction rather than out of delusion, and 2) thank goodness for people like that, because they build and improve a lot of the software we benefit from.

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

#24
post #2

Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…

> I'm not going to make the world a better place by configuring my editor

I think this covers work of most programmers. Doesn't matter if time is spent writing editor config or production code...

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

#25
post #2

Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…

Spending time on your tools instead of your work is not a sign that you need to change your tools - it's a sign that your work sucks.

Or that your tools (as currently configured) are insufficient to the task of doing your work.

If you wonder why a woodworker hasn't finished the chair, a completely valid answer is "all the edged tools you gave me were dull".

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

#26
post #22

Emacs - the editor that STILL doesn't have a simple way to duplicate the current line?

Different editors have different patterns of usage. I find I roughly speaking never duplicate lines, so why would this be a problem?

I constantly find myself duplicate lines in vim (shift+y). You've never had to edit a line that's really similar to another?

Or when debugging, I don't want to change the old code, so I copy the line, comment it out, and work with the duplicated line.

You've never had to do that?

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

#27
post #2

Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…

But I mean, that's not Emacs fault?

It very well could be. Attempting to either adapt yourself to emacs, or emacs to you, can take a long time, and may also fail.

Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.

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

#28
post #8

So the slides say... > Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system. Is that really true? I've really enjoyed concurrency in D. http://jordi.inversethought.com/blog/advent-of-d/#day18 How much better can it be? And yes, D's concurrency is also based around types.

Frankly, not that much. Rust can primarily protect against memory usage race conditions, it can't catch most kinds of deadlocks or other concurrency issues.

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

#29
post #3

(from the slides) >I learned Emacs in September, 1983 >It is now November, 2019 >...that’s over thirty six years! >An amazingly long time. Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it. I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental im…

The main reason I quit Emacs was the lack of context and semantically aware code completion and re-factoring tools. Such tools are invaluable productivity boosts for me. I have never gotten that to work in Emacs to a satisfactory degree.

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

#30
post #8

So the slides say... > Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system. Is that really true? I've really enjoyed concurrency in D. http://jordi.inversethought.com/blog/advent-of-d/#day18 How much better can it be? And yes, D's concurrency is also based around types.

> How much better can it be?

Rust guarantees that a data-race is a compilation error.

D.. does not guarantee anything.. a data-race won't even give you a run-time error..

So... since going from D to Rust is going from zero to all guarantees, I think it is fair to say that Rust is technically infinitely better.

FWIW this is not D's fault, most safe mainstream languages do not guarantee the absence of data-races (e.g. Java doesn't guarantee that either).

Post reply on HN