Comment by Jtsummers | Hacker News Reader

Comment by Jtsummers | Hacker News Reader

Parent Full thread

Fortran has seen major changes over the 64 years it's been in use. I feel that Emacs Lisp has had a much slower evolution (though admittedly I've only used it for about 20 years, I can't comment on how much it changed prior to that).

In particular, the biggest change I'm aware of with Emacs Lisp (the language) is that we now have lexically scoped variables. The biggest change to its implementation has been a push towards native compilation (much improved performance, I like it). The language has, otherwise, largely remained the same.

In some regard, this can be seen as a consequence of having a decent base language. Where Fortran's original version became increasingly indecent as time went on, Emacs Lisp seems to have held up better thanks to a stronger foundation. That doesn't mean there isn't room for improvement.

In particular, the things that (my opinion) are still missing from the language are:

1. A good concurrency model. CSP, actors, I don't care but it needs to exist. Paired with the native execution we're getting now, this would greatly improve the real and perceived performance of the system.

2. A real module system. I'm not talking about a package manager, but moving things into module scopes a la Common Lisp packages. The prefixed names for functions and variables is a hazard. Even if you leave every symbol exported by default so that you don't lose visibility to module internals it would be better than now. It would also open up a lot of opportunities like the potential to run multiple versions of the same package side-by-side.

> Fortran has seen major changes over the 64 years it's been in use.

And yet most Fortran programmers reject/ignore those changes and stick to Fortran 77. When I was in academia, I couldn't find a single person writing Fortran code in anything newer than 77.

My experience with that convinced me that many academic Fortran users are cargo cult programmers to the extreme. They're "taught" by examining the code written by their advisor's advisor's advisor who may have properly learned F77 back in 1980, but no one else did.

Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66). Specifically, that's the version that got structured programming elements added to the language. Having once inherited some pre-F77 code (well, it was F77 by the time I got it, but was started before then and that was obvious by its almost complete lack of structured programming), I can say that F77 is a substantially improved language over the prior versions.

> Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66).

That's because FORTRAN is one of the oldest languages, and you'd expect lots of changes as the whole field develops. If you use that as a metric, most languages will appear stagnant. Python hasn't changed much in the last 20 years, for example.

Yep, folks often fail to distinguish between old and OLD.

One might think Eclipse IDE is old. But Fortran predates the three-point seatbelts. The Vietnam War. Berlin Crisis. The Space Race.

Interesting, my experience was the opposite, everyone (1) was writing Fortran 95'ish. Might not have been the most beautiful code, but they took extensive advantage of the major F95 features like modules and array syntax.

(1) Except that one old beard who was convinced F77 was the ultimate, and everything newer was crap.

> 1. A good concurrency model.

This is definitely the biggest pain point, especially as people go to expand their use of Emacs (e.g. with Doom, adding more modules and integrations, one has to be careful to lazily evaluate config blocks to avoid loading everything at startup).

Even without such extensive configs, working on a large repo with a slow I/O (e.g. some network mount) with magit will cause large pauses once a command finishes if it has to refresh the magit buffer, or trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.

I do at least look forward to Emacs 28, which iirc is going to get native-comp (although that is already available as an experimental branch perhaps?).

Native comp was merged to the mainline a few months ago. It's behind a config flag `--with-native-compilation`. There is not yet an official release that includes it, but it's fairly common for people to run Emacs built from the mainline source.

> trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.

Please try `org-ql` and `helm-org-ql`; these newer search tools perform better than `org-rifle` and generally supersede it.

Reply on news.ycombinator.com