5 ms·

Why redo something if it works? People are still using Fortran because it works well for certain applications. Just because its old doesn't mean its outdated.

Why redo something if it works? People are still using Fortran because it works well for certain applications. Just because its old doesn't mean its outdated. I could even argue that since Emacs hasn't been phased out (and still has a decent user base) that it does something that other text editors don't (or can't) do.

Jtsummers 5y ago
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.
- BeetleB 5y ago
  > 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.
  - Jtsummers 5y ago
    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.
    - BeetleB 5y ago
      > 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.
      - varjag 5y ago
        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.
  - jabl 5y ago
    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.
- _huayra_ 5y ago
  > 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?).
  - b3morales 5y ago
    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.
  - githubalphapapa 5y ago
    > 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.
tsimionescu 5y ago
Well, Emacs has some major limitations as an editor, places where it really shows its age. Particularly, it is single threaded and this affects many normal uses - for example, while opening a connection to a remote machine with TRAMP, the whole GUI is completely frozen. Similarly with many development tools, such as magit or the excellent lsp-mode (Language Server Protocol support).
- _huayra_ 5y ago
  Exactly, if it wasn't for the community building and maintaining great packages like org/magit/lsp-mode etc, I would've dumped Emacs long ago. Building that as someone who has other responsibilities than editor hacking is just a non-starter, so I stick with Emacs despite it's event-loop-blocking quirks because of it. I wonder if there will be a way to sidestep these limitations or if something in the language semantics would forbid it (e.g. the way Python is basically limited with the GIL because current updates are basically not tolerated by the semantics).
anyfoo 5y ago
Part of my point was that it's difficult to get into (still worth it overall), but another part is definitely that technology has moved on, and emacs often reminds me of its age there. No matter what, emacs still feels "alien" in my OS's desktop interface with its UI concept, and never fully integrates. That's fine if you don't want it to integrate, but I actually like some concepts of my OS's UI a lot, and miss them in emacs. And elisp is not a very good language, born of a time where programming languages still had a long way to go (at least in the mainstream, academically it always seems a bit different to me). They are actively trying to fix things, e.g. the adoption of lexical binding, but the scope of this effort also shows how emacs is a very big ship that is hard to change course. Someone else mentioned lack of proper multi-threading in another comment now, and this is also very noticeable.
- grae_QED 5y ago
  I should have clarified... >Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world. I was really responding to this. You're right though: there are aspects of Emacs that are dated, the UI isn't very spiffy, and I've never dealt with elisp before so I'll take your--and everyone else's--word for that. I was just suggesting that it gets the job done for a lot of people and maybe, as a result, shouldn't be classified as outdated.
  - anyfoo 5y ago
    It's true that I maybe made it seem a bit too much like emacs itself was outdated. But really I think that it is built on outdated paradigms, which hinders its development and presentation a bit. I was fully serious when I said I cannot imagine switching to anything else (and I'm not afraid of switching otherwise), it's still the best we have in my mind.

Jtsummers 5y ago

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.

BeetleB 5y ago
> 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.
- Jtsummers 5y ago
  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.
  - BeetleB 5y ago
    > 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.
    - varjag 5y ago
      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.
- jabl 5y ago
  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.
_huayra_ 5y ago
> 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?).
- b3morales 5y ago
  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.
- githubalphapapa 5y ago
  > 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.

tsimionescu 5y ago

Well, Emacs has some major limitations as an editor, places where it really shows its age. Particularly, it is single threaded and this affects many normal uses - for example, while opening a connection to a remote machine with TRAMP, the whole GUI is completely frozen. Similarly with many development tools, such as magit or the excellent lsp-mode (Language Server Protocol support).

_huayra_ 5y ago
Exactly, if it wasn't for the community building and maintaining great packages like org/magit/lsp-mode etc, I would've dumped Emacs long ago. Building that as someone who has other responsibilities than editor hacking is just a non-starter, so I stick with Emacs despite it's event-loop-blocking quirks because of it. I wonder if there will be a way to sidestep these limitations or if something in the language semantics would forbid it (e.g. the way Python is basically limited with the GIL because current updates are basically not tolerated by the semantics).

anyfoo 5y ago

Part of my point was that it's difficult to get into (still worth it overall), but another part is definitely that technology has moved on, and emacs often reminds me of its age there. No matter what, emacs still feels "alien" in my OS's desktop interface with its UI concept, and never fully integrates. That's fine if you don't want it to integrate, but I actually like some concepts of my OS's UI a lot, and miss them in emacs. And elisp is not a very good language, born of a time where programming languages still had a long way to go (at least in the mainstream, academically it always seems a bit different to me). They are actively trying to fix things, e.g. the adoption of lexical binding, but the scope of this effort also shows how emacs is a very big ship that is hard to change course. Someone else mentioned lack of proper multi-threading in another comment now, and this is also very noticeable.

grae_QED 5y ago
I should have clarified... >Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world. I was really responding to this. You're right though: there are aspects of Emacs that are dated, the UI isn't very spiffy, and I've never dealt with elisp before so I'll take your--and everyone else's--word for that. I was just suggesting that it gets the job done for a lot of people and maybe, as a result, shouldn't be classified as outdated.
- anyfoo 5y ago
  It's true that I maybe made it seem a bit too much like emacs itself was outdated. But really I think that it is built on outdated paradigms, which hinders its development and presentation a bit. I was fully serious when I said I cannot imagine switching to anything else (and I'm not afraid of switching otherwise), it's still the best we have in my mind.