Emacs discusses web-based development workflows

Posted Sep 2, 2021 15:09 UTC (Thu) by smoogen (subscriber, #97)
Parent article: Emacs discusses web-based development workflows

There is no one issue with getting contributors to Emacs but a series of 'small' ones starting with the fact that the language it is written in hasn't been taught in most computer science programs for over 20 years. Even in the early 1990's, it was usually only taught as a 'here is language that I got my Phd thesis in and I spent 2 weeks getting compiled on our 'variant' Unix box for this course'. By the 2000's, most students would get a 'here is what it looks like' but nothing beyond that. At this point, the language reads more like Beowulf than Shakespeare to most people who might be interested in coding it. And there is very little in the way of useful communication on how to read it for most people.

Moving workflows, arguing about email versus web, etc ends up as window dressing versus dealing with the harder problem of 'Why LISP in 2021?' and then 'This is how you do more stuff than that hello world tutorial you found on WebArchive from 1993'

Important Notes:
* I do realize there are always going to be people who look at ancient Beowulf text and go 'dang that is so clear and I believe we should go back to talking and writing like that'. However if they aren't able to get a chair at some academy, they end up reading mostly 'modern' fiction like Chaucer or older Latin where there is a larger amount of 'code' written.
* I am not advocating rewriting emacs in some other language. I am trying to say that if you want emacs to be useful make LISP useful to a larger audience for people in 2031 versus 2021 or 2001.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 17:25 UTC (Thu) by karim (subscriber, #114) [Link] (6 responses)

I've been using emacs for as long as I can remember using *nix (25+ years). And you're right, I took a graduate Lisp class in the '90s, which made me realize how I hated that approach to programming (I had learned Forth before that and I actually liked that much more.) Despite having learned some Lisp and despite how long I've used emacs, I have *never* bothered to program anything for it, or try to understand any extensions written for it. Instead, I keep googling for snipets to copy-paste into my .emacs files, and trying to tweak them whenever I need.

The fact of the matter is that emacs will likely continue existing as-is (with its present dev model) until a sufficiently good replacement is found. Personally, I've been shopping around. I haven't found something just yet. Eventually, however, something with a more modern dev model, look and feel, and extensions language that can functionally replace emacs will come along. In the mean time, I'll continue using emacs. But I can't say I care what its developers do at this point, so long as I can continue having the feature set I currently have.

Emacs discusses web-based development workflows

Posted Sep 2, 2021 17:47 UTC (Thu) by smoogen (subscriber, #97) [Link] (5 responses)

Understood.. that is how I have been using emacs. It is hard coded into my brain too much to find most other editors 'useful' to me, but I really 'hate' programming much in it. And yes emacs will probably last for more years in a slowly decaying state. However as all of us 1990's people reach our own 60's.. at some point the 30 year olds running the distros in 10 years or so will say 'why?' and tell us to use something they can support.. [sort of like we did in the 1990's to the people who had editors written in Algol68 or Fortran IV]

Emacs discusses web-based development workflows

Posted Sep 2, 2021 17:52 UTC (Thu) by karim (subscriber, #114) [Link]

We're on the same page.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 6:49 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (3 responses)

As a vim user who has never seriously touched Emacs... my 2¢ is that the language you program your editor in *should* suck (e.g. VimL is an awful language to program in). It discourages you from trying to do anything too ridiculous instead of running a separate program. vim is a tool I start when I want to edit a file. If I want to do something else, I run an appropriate command or write code in a language which is actually reasonable (usually zsh or Python). If I want to modify the contents of a buffer, I use vim's built-in filtering support (see https://vimhelp.org/change.txt.html#filter) and do all the hard parts outside of vim. If for some godforsaken reason I actually want IDE-like functionality, I (grumble and) fire up an IDE. But that is rare in my experience, possibly because SREs are doing a lot of systems orchestration and not a lot of "look at my gigantic Java monstrosity with 50k classes."

Emacs discusses web-based development workflows

Posted Sep 3, 2021 12:58 UTC (Fri) by smoogen (subscriber, #97) [Link] (2 responses)

To be honest, vim is so much closer to emacs that comparing them is more about which keys I press to get to an end of a line versus anything else. [Heck turn on all the bells and whistles and vim will out memory use than 'Eighty Megs And Constantly Swapping' (EMACS)]. But in the end, I have seen more Linux people (from 60 year olds to 20 year olds) use vscode than emacs or vi in the last several years to edit everything from conf files to coding new things. I would not have ever expected that 30 years ago.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 13:36 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> But in the end, I have seen more Linux people (from 60 year olds to 20 year olds) use vscode than emacs or vi in the last several years to edit everything from conf files to coding new things. I would not have ever expected that 30 years ago.

Because by any objective standard, VSCode is really good! It provides a very nice comprehensive, integrated, highly-customizable environment for what a substantial (possibly even a majority) of software developers these days are working on.

VSCode is the all-dancing everything that emacs was once derided for, with the significant advantage that it is implemented in a language that has a substantial developer mindshare (javascript) vs something that was a niche even in its heydey (ie lisp).

But making something so well integrated and polished takes a _lot_ of work. It's probably fair to say that between Google (ie the Chrome/Electron underpinnings) and Microsoft, more money has been invested into VS Code in the past 6 months than emacs has seen in four decades. Heck, the office supply budget for the VS Code team is probably larger than the FSF's annual spend.

Emacs discusses web-based development workflows

Posted Sep 3, 2021 14:41 UTC (Fri) by zdzichu (subscriber, #17118) [Link]

Try this: go to Github, click on any source file and press '.' (dot). This is Microsoft integrating its product, Emacs can't possibly beat that.

Emacs discusses web-based development workflows

Posted Sep 4, 2021 0:28 UTC (Sat) by dvdeug (guest, #10998) [Link] (3 responses)

I don't believe the language is that much of a problem. Yes, it's not a language most people will have learned in school, but it's hardly APL, or even Awk or BLISS. Syntax is trivial, and if you've done some poking around in Scala or ML or Haskell, you've probably got the recursive list thing down. The only time I touched it in school was choosing Common Lisp to solve a problem in OS class, because hey, what better time then now?

I am far, far more scared of the Emacs API than the language. No matter what the language, there's still going to be window-pane-half-shadedp stuff that takes 1 or 3 as the first argument (2 was used on Motif for VAX, and 4 on an uncompleted port to Windows 3.1), and if you pass the left window pane handle to the third argument, there will be hell to pay, but it will be far away from this function. Knowledge is not transferable in or or out; this isn't built like any program besides Emacs, not a standard GTK program or KDE or Java/Swing or JavasScript browser program. I don't know anything about Emacs internals; this is just my fears.

Maybe I'm wrong--I think I do like programming languages more than most programmers--but Emacs Lisp shouldn't be scary to anyone who can hack on Emacs, and I don't think it is; it's just Emacs itself is large, ancient, and comes with a reputation.

Emacs discusses web-based development workflows

Posted Sep 4, 2021 16:57 UTC (Sat) by marcH (subscriber, #57642) [Link]

Trying to learn the language to isolate a crash and understand some tramp issues was fun. OK, surely not everyone's taste of fun but if you're using Emacs you're not "anyone" anyway in the first place.

What I found the most painful was the debugger. I forgot which one(s) I tried but they were horrible. I hope it's not a inherent problem with the language? Any recommendation?

Debuggers are absolutely, totally essential for "drive-by" contributions because they save you from reading a gazillions of lines of code irrelevant to your particular issue. I'm surprised they're mentioned so rarely in discussions like these.

Even with a good debugger I would still not submit patches because employer waiver paperwork etc. but at least I can produce suggestions as close to a patch as possible.

The lack of integration / a "forge" definitely plays a role because of the additional time it takes but if something really really annoys me then I make the effort and send email; I contribute much less but not zero.

Emacs discusses web-based development workflows

Posted Sep 5, 2021 15:26 UTC (Sun) by smoogen (subscriber, #97) [Link] (1 responses)

I should have been clearer about my concern about the language. Finding out about LISP is hard enough, but finding out about how Emacs LISP differs or does things is even harder.

The language is a problem in that the API you are worried about is very tied into the way that Emacs LISP differs from Common LISP. One of the ways that breaks a lot of new programmers is that they go find out about LISP, read Common Lisp, try to get their LISP working with Emacs and run into exactly the perils you are talking about. Unless you really know Emacs LISP, you don't know why they do X or Y or Z.. and a bit of vice versa.. unless you know why the API does X, Y, or Z you can't really understand Emacs LISP.

The issue is that if I were a new programmer and I was told that I could code a mountain of javascript which I can find lots of tutorials, modern howtos, etc for VScode, or a small amount of Emacs LISP to do the same thing.. I would probably start on Emacs LISP and then find out that the mountain I needed to climb was not the amount of code needed to do something, but the twists in my brain which I only needed for this one tool. Then I look around and see everyone else is using VScode and just use that.

I want to say I am not saying that Emacs shouldn't move to some sort of open git repository. Just don't measure the success or failure of it by the number of new people coming into it after a year. Moving to 'git***' isn't going to fix the fundamental issues which make the emacs programmer community small.

Emacs discusses web-based development workflows

Posted Sep 5, 2021 18:40 UTC (Sun) by jem (subscriber, #24231) [Link]

>The language is a problem in that the API you are worried about is very tied into the way that Emacs LISP differs from Common LISP. One of the ways that breaks a lot of new programmers is that they go find out about LISP, read Common Lisp, try to get their LISP working with Emacs and run into exactly the perils you are talking about.

That's hogwash. New Emacs Lisp programmers can't just try their Common Lisp code on Emacs without first learning the Emacs API. Programming Emacs is all about interacting with Emacs functionality, either with the built-in API or interfacing with other Emacs Lisp packages. This requires learning about Emacs's buffers, windows, text search and manipulation, and the functions available for performing these tasks. Emacs can not be used as a drop-in replacement for any other Lisp system because the environment is so different. There is no point in using Emacs as a replacement for a general purpose Lisp programming environment. The difficulties posed by learning the differences between the core language features of Emacs Lisp and Common Lisp are minuscule in comparison.