Emacs had evil-mode (and terminal support) since forever.
In some cases eshell it's far better than sh, altough anything can be better than POSIX sh. Just try rc under 9front (or, as a demo, under GNU/Linux or OpenBSD). GNU tried to create a better interface to Unix with Emacs (and it shows) and 9front just went further throwing down all the legacy crap to the dust bin creating something better. No X, no ioctls, no sh, no Perl, no C++ (golang works, same people in the end).
I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot. The 90% of these could be rewritten and even expanded and enhanced under Elisp running pretty fast and interfacing much better with Elisp than any other tool.
Ironically GNU on-current-unixes (and outside of Hurd) it's holding GNU and Emacs back, because a nonroot user can do far more stuff (without group permissions) under Hurd than in GNU/Linux. Think something like namespaces, remote mounting devices a la Rclone (and not just drives) and so on with a boosted Elisp interface and org-mode to manage far more stuff under you account than these restricted Unixen. But a paradigm change is needed.
The 9front users already got it, and the GNU Guix people just began doing that under Guile. Who knows, maybe in 15 years Emacs it's rewritten fully under a uber fast Guile with libre RISC-V microcode based CPU's from Taiwan or Estonia or whatever, loading Guile-optimized code on demand for HPC tasks and the like and some others loading a server-balanced microcode (and OS settings) grom a custom Guix config. That would yield a very different computing than the one we are suffering today. It would be the second Golden Age, similar to PDP10+ITS/WAIS creating the path for the literal 60 years of computing where basically Lisp and Forth invented everything or nearly everything.
> I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot.
The problem with doing everything in Elisp is the lack of threading. GNU Find can search down multiple directories in parallel, and an Elisp implementation of Grep would block the Emacs UI while searching. Until Elisp gets threading it will fundamentally be limited to either short bursts of computation or frustrating UX because of blocking (see also frustrations with Gnus).
Jitted Elisp for itself has much more power because of function composability than badly reusing libraries without even a common API like OLE/COM under Windows. You are just creating silos badly interopearting together.
Even 9front has something like 9p, namespaces and everything it's truly a file. Even GNU/Emacs under Hurd doesn't have its full power developed until the GNU people ditch Gnuplot for their own GNU-born capable 3D plotutils and the like.
And today given the speed of jitted Emacs if I were the Calc maintainer I'd try to write a PNG/farfbled (or whatever it's called) plotting tool in pure Elisp, with both TTY and graphical outputs.
Depending on non-GNU, external tools it's holding GNU and Elisp back.
- Purged are gnuplot dependencies with a custom and actual GNU bound 3d plotting software. GNU calc for Emacs should have been working with core Emacs libraries long ago.
- Plotutils extended for 3D should have been mandatory long ago
- GNU made Texinfo not be Texlive dependant for PDF/HTML output.
Texinfo should have been standalone a la mandoc it's under Unix for PDF output.
I loved that game back in the day, it was among Shenmue the game that defined Sega's philosophy. If you think about it, it almost condensed the urban 'need' from people who played Outrun and fake-3D 8-16 bit racing games but never were able to see a single street ingame until the Playstation/PC except for top down/isometric ones, or maybe, crude main highways in arcades without being able to make turns.
Then the PC/PSX game us free roam games such as Road Rash 3D and Driver. Crazy Taxi gave us a whole bigass city full of details (even trainways and tunnels among a subway) instead of a countryside with few buildings here and there. Or, contrry to Driver, CT had cities without being restricted to less than 10 buildings copied and pasted across the map rendering the same store again and again.
Yes, I'm aware of MUDs, text had no restrictions. And games like that low poly free roaming game in the Amiga and that weird city driver in the ZX Spectrum, but the Amiga one was barely a 3D demo with no textures at all and the game looked pretty empty.
As an IBM hobbyist user, picture something worse than VMS in 'hackerdom'. IBM's mainframe OSes are like NT/OS2 taken to the total extreme with objects, because by default you don't see files but objects which might have files... or not.
Imagine the antithesis of Emacs. That's an IBM environment with 3270 terminals and obtuse commands to learn.
I could run a text adventure with a Zmachine emulator under a 6502 based machine and 48k of RAM, with Ozmoo you can play games like Tristam Island. On a Commodore 64, or an Apple II for you US commenters. I repeat the game it's being emulated in a simple computer with barely more processing power than a current keyboard controller.
As the ZMachine interpreter (V3 games at least, enough for the mentioned example), even a Game Boy used to play Pokemon Red/Blue -and Crystal/Sylver/Blue, just slightly better specs than the OG GB- can run Tristam Island with keypad based input picking both selected words from the text or letter by letter as when you name a character in an RPG. A damn Game Boy, a pocket console from 1989.
Not straightly running a game, again. Emulating a simple text computer -the virtual machine- to play it. No slowdowns, no-nothing, and you can save the game (the interpreter status) in a battery backed cartridge, such as the Everdrive. Everything under... 128k.
Claude Code and the rest of 'examples' it's what happens when trade programmers call themselves 'engineers' without even a CS degree.
reply