4 ms·
I share this sentiment. As a user, I have found some relief by switching to a very simple setup with just a WM (XMonad), a browser (Firefox+vimperator), Emacs a
by nextos 10y ago
I share this sentiment. As a user, I have found some relief by switching to a very simple setup with just a WM (XMonad), a browser (Firefox+vimperator), Emacs and a terminal (urxvt, which I only use occasionally).
Previously, even though I used Emacs as an editor, the idea of moving functions that correspond to applications (like mail reading) into an editor looked clunky and even dirty to me.
But I grew disillusioned of the Unix ethos. While it works well for composing very simple programs, it fails to deliver on most other things. For example, Mutt is a great mail user agent. But it is very difficult to customize beyond its author's original intentions using its own little configuration DSL. And scripting it from your shell does not lead anywhere. This happens with many other nice Unix utilities.
In contrast Emacs, understood as a text-mode Lisp machine, is at odds with this approach. The code you write is as first class as the code you run from whatever module you import. Everything is alive, integrated, and can be changed.
As a programmer, I am moving towards more and more abstract application domains for the same reason. Mathematica, PyMC or Scheme allow me to ignore all the horrid details the OP describes and work at a higher level.
- shakna 10y agoI love the ethos of Scheme. The language has ways that the program is expected to do things, such as named let and syntax-rules, but is flexible enough to get out of your way if you have a different idea, such as defmacro. I wish that the rest of my userland would be as flexible.
- nextos 10y agoYou can always use Emacs and treat all low level things as plumbing. Eventually Emacs will hopefully switch to Guile Scheme. In any case Emacs Lisp is a pretty good language and would not feel clumsy to an Scheme hacker, I think. You can have a pretty modern userland with Org, Gnus or mu4e, pdf-tools, etc. I have recently switched to GuixSD after 2 years toying with NixOS. All dirty Systemd plumbing fades away and gets replaced with a minimal service manager written in Scheme, GNU Shepherd. Plus all packages are defined in Scheme. It's very refreshing. I hope one day we get to see a cleaner kernel, ABIs and compilers. Things have gone a bit out of hand.
- shakna 10y agoI'd rather not have Emacs as my environment. I really wish that something like Gnome worked as well as Emacs to be customiseable and extendible, and in fact that everything in /bin would share a cohesive, modular and programmable interface, preferably Scheme, but I'll settle for something sensible. Emacs, and to a lesser extent, sch, are a nice first step to making a nice environment. But they still feel ten years old, or more. I use TUIs, and appreciate them. But VLC and my window manager should be beholden to the same level of control and interactivity. And yes, I am never satisfied tweaking my system to my preferences, because I always hit roadblocks before I get there. (I am totally fine with the kernel, and compilers and the like using "dirty" code -> that's one of the easiest ways to reach a damn fast system.)
- lispm 10y agoI don't think GNU Emacs has a plan to switch to Scheme. https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs > Guile-based Emacs is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile. One Emacs Lisp engine replaced by another. > Lastly, it will become possible to write Emacs extensions in Scheme instead of Elisp That means Emacs Lisp remains the implementation language and the extension language. Guile provides the base machine and Guile Scheme becomes another extension language. Somewhen in the future.. Personally I think that project is misguided anyway, since it would be much smoother to use some Common Lisp as an implementation language (Common Lisp and Emacs Lisp both are based on Maclisp). But Common Lisp is not popular with RMS.
- saywatnow 10y ago> Scheme > the rest of my userland One of the reasons I eventually got fed up with Scheme is that interfacing it with the rest of my userland was really quite hard. IO, subprocesses, networking just weren't as smooth as Unix wanted them to be. Everything had to be wrapped in lists before the "big ball of snow" could do magic with it. Later I discovered Tcl. upvar and uplevel are not syntax-rules or defmacro, but they give you very similar power in practice - I won't say more or less arcane, just different. IO, events and subprocess management are all right there. Best of all, EIAS (everything is a string) makes communicating with the outside world as natural as it should be. It helps that Tcl got tailcall and lambda shortly after I arrived :).
- TeMPOraL 10y ago> upvar and uplevel are not syntax-rules or defmacro, but they give you very similar power in practice - I won't say more or less arcane, just different. IO, events and subprocess management are all right there. Makes me wonder if one could port those Tcl features to Scheme / CL via the macro facility, thus having the cake and eating it too?
- saywatnow 10y agoUnfortunately, no. At least not with anything resembling R6RS scheme. upvar/uplevel give you dynamic access to the calling context, which is at odds with scheme's insistence that compilation must be possible, including the erasure of all names. Tcl is at the other extreme: everything is late-bound, (very nearly) everything is introspectable. It is possible to go the other way though ... [1] doesn't go as far as macros, but (provided you don't believe in compile-time/run-time separation) upvar/uplevel could take it there! No call/cc is possible in Tcl, but coroutines can express more limited forms of continuations. And when Oleg calls out call/cc as a poor primitive, I'm comfortable giving it up :). [1]: https://wiki.tcl.tk/22049 https://wiki.tcl.tk/22049
- astrange 10y ago> In contrast Emacs, understood as a text-mode Lisp machine, is at odds with this approach. The code you write is as first class as the code you run from whatever module you import. Everything is alive, integrated, and can be changed. I think it's really interesting that Lisp developers like everything to be powerful, but only one of these exists: https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_most_power https://en.wikipedia.org/wiki/Rule_of_most_power Not that I like writing in least-power programming systems (let's say Python here), but it's easier to trust anyone else's programs in them.
- shakna 10y agoMost LISPs don't give you the most power. They are usually GC'd, and usually don't have access to directly modify memory, like you can with anything in the realm of C. The foot-gun the give you is expressiveness, which allows you to make code unintelligible, rather than power to do anything that you feel like. (I'm not aware of any surviving LISP that would allow you to modify the structure of how cons cells are generated, for example). There's certainly power in expressiveness, but it isn't the godlike power of C, where you can potentially damage hardware. That, I think, is why we don't have a "Rule of most power".
- lispm 10y agoMost actual Lisp systems can access random memory and define C-like memory structures. Otherwise they would not be able to integrate with other software. See for example: http://www.sbcl.org/manual/index.html#Foreign-Function-Interface http://www.sbcl.org/manual/index.html#Foreign-Function-Inter...
- dleslie 10y agoI dislike when things are called rules, but are neither natural constraints or enforced by authority; these are, at best, suggested behavior.
- mncharity 10y ago> Everything is alive, integrated, and can be changed. Every few years it seems, I become confused. I write some prototypical javascript, which goes well, and I'm puzzled: "Wait, why hasn't javascript become at least smalltalk-like in being alive, integrated, and deeply changable?" Explanations based on developer ignorance pale with the passing years, and with the active tool-building community. Then I have to mock some browser api, and I remember. Browser javascript - language of a hundred primitives types. A few language primitives, Object, and hundred browser types doing a half-assed job of pretending to be objects. Instead of "get it right, and then write a fast path", browser dev seems to be "write the fast path first, and then pretend we're done". :/ (Yes, Smalltalk has issues scaling complexity - I didn't say scales well.) Ah well. At least it makes it easy to watch for a language that isn't crippling. Energetic rapid phase transitions are hard to miss.
- gcb0 10y agowhy do you say mutt follows the unix philosophy?
- yjftsjthsd-h 10y agoIn fact, let me go one step further: If mutt does not nicely interoperate with other programs using streams of text then it does not follow the Unix philosophy.
- duerrp 10y ago> just a WM (XMonad), a browser (Firefox+vimperator), Emacs > and a terminal (urxvt, which I only use occasionally) Exactly my setup... now if only Firefox would not peg a CPU core or two in the background and slow down to a grind ever so often... (despite NoScript, uBlock origin etc.)
- sametmax 10y agoThe nightly build is realllllly fast. It starts getting the result of their years of work to speed things up. But it's incompatible with some addons. E.G: lastpass will freeze the browser for a few seconds.
- proaralyst 10y agoFirefox is currently working on Quantum which should do what you're asking it to.
- dredmorbius 10y agoI've heard variants of that line for ... about 20 years now.
- Chattered 10y agoThis is pretty much my setup but I still use the terminal a lot. What are you using instead? eshell? ansi-term? Or do you find you don't need terminals much generally?