7 ms·

Many Emacs advocates fall for the trap of apologizing for why Emacs is not Unixy, as though it were some sort of defect. They should celebrate the fact that Ema

Many Emacs advocates fall for the trap of apologizing for why Emacs is not Unixy, as though it were some sort of defect. They should celebrate the fact that Emacs doesn't come from the Unix tradition of small, composable tools and "doing only one thing and doing it well". It is rooted in the ambitious work of the MIT Artificial Intelligence lab, the LISP programming language, and the single user MIT Lisp Machine that essentially booted up to a LISP REPL.

gkya 11y ago
Unix has a big flaw: through the pipes pass random data. It's up to the receivers to interpret it. Lisp gives you the possibility to easily structure your data and pass it around, plus the ability to pass programs around. Other than this, the unix way and the lisp way are nearly parallel, though in lisp "command line utility" is called a "procedure".
- pjmlp 11y ago
  Hence why I love the idea of REPL as shell as used in the Xerox PARC and ETHZ OSes. Only Powershell comes closer to how this was used.
  - qznc 11y ago
    Every (Unix/terminal) shell is a Read-Eval-Print-Loop. The difference is the data structure which is passed around. Is it bytes, Cons, or objects?
    - pjmlp 11y ago
      No, every UNIX shell is a poor Read-Eval-Print-Loop when compared to what Xerox PARC machines allowed in terms of interaction with the running OS. UNIX shells don't allow to call functions declared in .so, execute scripts applied to elements selected with the mouse, apply functional algorithms over data. Well, you can write external commands in another programming language, but then it isn't a REPL anymore.
    - gkya 11y ago
      A lisp repl is not any repl. First, the homoiconicity of the lisp syntax allows you to sumbit structures of arbitrary complexity to the listener, and reuse output from it, even submit it back as code to execute. Second, the error handling mechanism allows you to interactively choose how to resume, and the way the repl and the image work, allows you to redefine the ill code before resuming, which is incredibly useful and intuitive. Say I have an url, and a loop that reads some data from that url, suddenly an error happens, the resource url is changed and I have to update. If I was using slime through emacs, I would be taken to the debugger, which shows me the options to resume. While that debugger is there, I can switch to the source file, tweak the variable for the url, evaluate it, switch back to the debugger, and hit the key for retry. I would have fixed the code without having to stop the program (not even behind the scenes, like with tools that watch the program and restart it). And also within the debugger, in either of Elisp debugger and Slime debugger, I can do many things, among which peek into the locals, copy stuff from there and use in my program to explore the problem. I have heard that in a space mission, NASA programmers were able to fix a spacecraft that was in space, from earth, via connecting to its lisp image over the network. What do you do when you have to debug a pipeline? You do not have direct access to the data that flows, you need special tools to examine core dumps, and you have to have had enabled saving the dumps beforehand, you need to verify that the command syntax is correct, you have to understand what each program emit, and make sure you filter out all irrelevant data like logging etc., you don't know which part of the pipeline failed, where, you don't know if it is a wrong parameter or the program has a bug. And in order to fix bugs in programs that make up the pipeline, you have to know in whatever language the buggy one was implemented: </var/log/my-service.log ag 'Response: 505' | sed 's#(<timestamp>) (<path>) Response: (\d{3}) (\w+)#\1,\2,\3,\4#' | python create_report.py --output-to latex > /tmp/report.tex && latex /tmp/report.tex && dvi2pdf /tmp/report.tex && [ -f /tmp/report.pdf ] && sh /home/gkya/utils/mail_report.sh --report /tmp/report.pdf In this command line at least six different languages are in use. I just made it up, but it doesn't seem far-fetched to me.
- qznc 11y ago
  So Emacs/Lisp gives you a Unix in your Unix.
  - gkya 11y ago
    No it gives me something better than unix in my unix.
  - cema 11y ago
    Rather, it gives you something in many ways similar to Unix and not necessarily in Unix.
- qznc 11y ago
  So Emacs/Lisp gives you a Unix in your Unix.
- liotier 11y ago
  So, JSON passed between a bunch of Javascript things from Github means that the browser is the new EMACS ?
  - yvdriess 11y ago
    Maybe if it would be sending AST in JSON, not recommended though :)
  - jarcane 11y ago
    The article more or less makes this precise comparison. "Do everything in Emacs" isn't really so different from "Do everything in the browser." Arguably, modern browsers are more heavyweight and complex at that. They certainly eat a hell of a lot more RAM than my Emacs ever does.
    - mundanevoice 11y ago
      True, But they also do much more things than Emacs does.
      - tempodox 11y ago
        If you really believe that you haven't understood emacs at all.
        jarcane 11y ago
        Ironically, the only thing Emacs can't seem to do these days is be a browser. ;)
        to3m 11y ago
        https://en.wikipedia.org/wiki/Emacs/W3 https://en.wikipedia.org/wiki/Emacs/W3 https://en.wikipedia.org/wiki/Eww_%28web_browser%29 https://en.wikipedia.org/wiki/Eww_%28web_browser%29 I don't believe there is any Javascript support, though, so you'll be out of luck for many modern pages...
- tempodox 11y ago
  Emacs has a big flaw: It's just too fucking complicated and inconsistent. Unix, otoh, can do everything emacs does AND it has a half-decent text editor (vim).
  - gkya 11y ago
    Your comment has a big flaw: it assumes that the grandparent comment is comparing emacs and unix, whereas lisp and unix were compared. If your reading skills are like this, anything is complex for you. And afaik emacs is not a sexual being. And if you think that unix is simple, easy and consistent, your unix fu is probably just adding a fancy prompt to your bashrc. Try ls: how do you sort dirs before files? The first thing you ask is whether it is gnu ls or sth else. Try man, the first question is which format. Make? Same story. I want to get notified for changes in a directory: each unix has its own incompatible thing. And these are the very basics.
- mveety 11y ago
  You just need to have a standard data structure marshaling format. Lisp gives you the ability to easily structure data, but it doesn't enforce any single way to structure it.
lispm 11y ago
Unix may have a tradition of small, composable tools. But Unix at the same time has a tradition of large, non-composable and long running tools. The X11 server is such a thing. Many GUI applications under Unix are working that way. From Framemaker to the big gui-based CAD applications. Don't let them tell you that Unix was developed to ONLY run small composable tools and that this is the only true way to use applications under Unix. If you look at Mac OS X as a Unix, the typical application has a GUI, only one instance is running, it works for multiple documents and often users keep them running for a long time. When browsing the web, one would not leave Safari/Firefox/Chrome after each web site visit...
- woodruffw 11y ago
  X was designed to replace W, which ran on the V System (which is not related to System V or UNIX in general). It does not come from the UNIX tradition - it is a port. Plenty of monolithic software runs on modern Unices, but very few can be traced back to a tradition of monoliths.
  - _yosefk 11y ago
    What did the Unix tradition of composability though pipes produce though that was more complex than grep, to put it in an exaggerated form? It sorta seems that the classical Unix approach breaks down for big tasks, hence in practice big programs do not follow it. "...and the eulogy was delivered by Perl", as Pike put it. It's a bit crazy to call Emacs bloated these days; vim is big, too, so is Eclipse, so are most useful programs. I don't like Emacs one bit, but its size is the last thing that bothers me.
    - lazyjones 11y ago
      > What did the Unix tradition of composability though pipes produce though that was more complex than grep, to put it in an exaggerated form? netpbm? Actually, once upon a time, there was a web browser called "Chimera", it used external commands to handle many types of files. For example, it used djpeg to load inline JPEG images.
- 11y ago
tadfisher 11y ago
I always thought of Emacs as my shell. All my UNIXy tools are just piped into this crazy customizable shell's STDIN.
shanth 11y ago
> "doing only one thing and doing it well". Emacs does only one thing. And does that one thing very well - "Extensibility"
tempodox 11y ago
You practically took the words out of my mouth. I was about to say that for gainful emacs usage, all I need is a Lisp machine. But since Unix is the reality, I'm staying with vim.

gkya 11y ago

Unix has a big flaw: through the pipes pass random data. It's up to the receivers to interpret it. Lisp gives you the possibility to easily structure your data and pass it around, plus the ability to pass programs around. Other than this, the unix way and the lisp way are nearly parallel, though in lisp "command line utility" is called a "procedure".

pjmlp 11y ago
Hence why I love the idea of REPL as shell as used in the Xerox PARC and ETHZ OSes. Only Powershell comes closer to how this was used.
- qznc 11y ago
  Every (Unix/terminal) shell is a Read-Eval-Print-Loop. The difference is the data structure which is passed around. Is it bytes, Cons, or objects?
  - pjmlp 11y ago
    No, every UNIX shell is a poor Read-Eval-Print-Loop when compared to what Xerox PARC machines allowed in terms of interaction with the running OS. UNIX shells don't allow to call functions declared in .so, execute scripts applied to elements selected with the mouse, apply functional algorithms over data. Well, you can write external commands in another programming language, but then it isn't a REPL anymore.
  - gkya 11y ago
    A lisp repl is not any repl. First, the homoiconicity of the lisp syntax allows you to sumbit structures of arbitrary complexity to the listener, and reuse output from it, even submit it back as code to execute. Second, the error handling mechanism allows you to interactively choose how to resume, and the way the repl and the image work, allows you to redefine the ill code before resuming, which is incredibly useful and intuitive. Say I have an url, and a loop that reads some data from that url, suddenly an error happens, the resource url is changed and I have to update. If I was using slime through emacs, I would be taken to the debugger, which shows me the options to resume. While that debugger is there, I can switch to the source file, tweak the variable for the url, evaluate it, switch back to the debugger, and hit the key for retry. I would have fixed the code without having to stop the program (not even behind the scenes, like with tools that watch the program and restart it). And also within the debugger, in either of Elisp debugger and Slime debugger, I can do many things, among which peek into the locals, copy stuff from there and use in my program to explore the problem. I have heard that in a space mission, NASA programmers were able to fix a spacecraft that was in space, from earth, via connecting to its lisp image over the network. What do you do when you have to debug a pipeline? You do not have direct access to the data that flows, you need special tools to examine core dumps, and you have to have had enabled saving the dumps beforehand, you need to verify that the command syntax is correct, you have to understand what each program emit, and make sure you filter out all irrelevant data like logging etc., you don't know which part of the pipeline failed, where, you don't know if it is a wrong parameter or the program has a bug. And in order to fix bugs in programs that make up the pipeline, you have to know in whatever language the buggy one was implemented: </var/log/my-service.log ag 'Response: 505' | sed 's#(<timestamp>) (<path>) Response: (\d{3}) (\w+)#\1,\2,\3,\4#' | python create_report.py --output-to latex > /tmp/report.tex && latex /tmp/report.tex && dvi2pdf /tmp/report.tex && [ -f /tmp/report.pdf ] && sh /home/gkya/utils/mail_report.sh --report /tmp/report.pdf In this command line at least six different languages are in use. I just made it up, but it doesn't seem far-fetched to me.
qznc 11y ago
So Emacs/Lisp gives you a Unix in your Unix.
- gkya 11y ago
  No it gives me something better than unix in my unix.
- cema 11y ago
  Rather, it gives you something in many ways similar to Unix and not necessarily in Unix.
qznc 11y ago
So Emacs/Lisp gives you a Unix in your Unix.
liotier 11y ago
So, JSON passed between a bunch of Javascript things from Github means that the browser is the new EMACS ?
- yvdriess 11y ago
  Maybe if it would be sending AST in JSON, not recommended though :)
- jarcane 11y ago
  The article more or less makes this precise comparison. "Do everything in Emacs" isn't really so different from "Do everything in the browser." Arguably, modern browsers are more heavyweight and complex at that. They certainly eat a hell of a lot more RAM than my Emacs ever does.
  - mundanevoice 11y ago
    True, But they also do much more things than Emacs does.
    - tempodox 11y ago
      If you really believe that you haven't understood emacs at all.
      - jarcane 11y ago
        Ironically, the only thing Emacs can't seem to do these days is be a browser. ;)
        to3m 11y ago
        https://en.wikipedia.org/wiki/Emacs/W3 https://en.wikipedia.org/wiki/Emacs/W3 https://en.wikipedia.org/wiki/Eww_%28web_browser%29 https://en.wikipedia.org/wiki/Eww_%28web_browser%29 I don't believe there is any Javascript support, though, so you'll be out of luck for many modern pages...
tempodox 11y ago
Emacs has a big flaw: It's just too fucking complicated and inconsistent. Unix, otoh, can do everything emacs does AND it has a half-decent text editor (vim).
- gkya 11y ago
  Your comment has a big flaw: it assumes that the grandparent comment is comparing emacs and unix, whereas lisp and unix were compared. If your reading skills are like this, anything is complex for you. And afaik emacs is not a sexual being. And if you think that unix is simple, easy and consistent, your unix fu is probably just adding a fancy prompt to your bashrc. Try ls: how do you sort dirs before files? The first thing you ask is whether it is gnu ls or sth else. Try man, the first question is which format. Make? Same story. I want to get notified for changes in a directory: each unix has its own incompatible thing. And these are the very basics.
mveety 11y ago
You just need to have a standard data structure marshaling format. Lisp gives you the ability to easily structure data, but it doesn't enforce any single way to structure it.

lispm 11y ago

Unix may have a tradition of small, composable tools. But Unix at the same time has a tradition of large, non-composable and long running tools. The X11 server is such a thing. Many GUI applications under Unix are working that way. From Framemaker to the big gui-based CAD applications. Don't let them tell you that Unix was developed to ONLY run small composable tools and that this is the only true way to use applications under Unix. If you look at Mac OS X as a Unix, the typical application has a GUI, only one instance is running, it works for multiple documents and often users keep them running for a long time. When browsing the web, one would not leave Safari/Firefox/Chrome after each web site visit...

woodruffw 11y ago
X was designed to replace W, which ran on the V System (which is not related to System V or UNIX in general). It does not come from the UNIX tradition - it is a port. Plenty of monolithic software runs on modern Unices, but very few can be traced back to a tradition of monoliths.
- _yosefk 11y ago
  What did the Unix tradition of composability though pipes produce though that was more complex than grep, to put it in an exaggerated form? It sorta seems that the classical Unix approach breaks down for big tasks, hence in practice big programs do not follow it. "...and the eulogy was delivered by Perl", as Pike put it. It's a bit crazy to call Emacs bloated these days; vim is big, too, so is Eclipse, so are most useful programs. I don't like Emacs one bit, but its size is the last thing that bothers me.
  - lazyjones 11y ago
    > What did the Unix tradition of composability though pipes produce though that was more complex than grep, to put it in an exaggerated form? netpbm? Actually, once upon a time, there was a web browser called "Chimera", it used external commands to handle many types of files. For example, it used djpeg to load inline JPEG images.
11y ago

tadfisher 11y ago

I always thought of Emacs as my shell. All my UNIXy tools are just piped into this crazy customizable shell's STDIN.

shanth 11y ago

> "doing only one thing and doing it well". Emacs does only one thing. And does that one thing very well - "Extensibility"

tempodox 11y ago

You practically took the words out of my mouth. I was about to say that for gainful emacs usage, all I need is a Lisp machine. But since Unix is the reality, I'm staying with vim.