Org-mode and babel sound like good ideas, but in practice I've found it very finicky to use.
My main problem with it is that, unlike with executing commands in the shell, with org you don't get any progress, and emacs seems to hang while running the command.
For example, running apt update tends to freeze emacs without any progress reporting for a few minutes.
I'm hoping that I'm doing something wrong and that someone can chime in with a suggestion, because I really like org-mode, and I really like the idea of doing devops using it.
Thanks. I've tried that in the past. The problem is still that it doesn't give any feedback on progress.
I still struggle to see how people actually use this with devops on a day to day basis.
I think that some type of integration with tmux would work well - have a running tmux session, and then just queue commands from emacs to that session, instead of running directly through emacs.
If you want to see progress, it should be easy to add a process filter somewhere (I bet there already is a hook for that, but not that hard to do even if there isn't one) and make it display sth. on a secondary buffer. That's the thing with Emacs: if you don't have it, it's very easy to add it.
I've been spending some time over the past few months developing a app for myself and family to help with this.
Basically, what I do is:
- make a list of books that I want to read
- over time, as I acquire the book, I have a tool to split up the book into separate chapters. These chapters are then loaded into the reading app.
- every day, I open the app and it chooses a chapter from a random book for me to read
- as I read, I highlight interesting, useful or difficult sections that I want to remember/study further
- instead of showing me a chapter, the app can also show a list of highlights from a previously read chapter. During this step it asks me to create little quizzes from the notes - either in the form of cloze replacements or simple q&a. Alternatively I can also create reflection questions or daily actions from the notes.
- in addition to the previous steps, the tool then also uses spaced repetition algorithm to review the little quizzes that I created from the books I've read
- every morning it chooses 10 of the actions that I identified and asks me how I am going to implement/practice them today
- every night it asks me how I practiced those actions
It does a bit more than this, but that's the main part. I've already seen great results from doing this, as I've always found the biggest problem with reading is that it tends to be too passive, and having the review and action steps helps alleviate that problem.
I was just looking at semantic-ui-react, and it looked great.
But then I tested their examples on my mobile phone and it looked really bad. It just seemed that it wasn't responsive at all, which really surprised me.
That's actually a pretty good barrier to entry. With emacs/spacemacs, if installing it is too frustrating for you, then configuring and using it is going to be way too frustrating for you.
My opinion is that emacs/spacemacs is more optimized for day to day work, than for the out of box experience. Personally, I'm fine with that, and there are some great editors (like sublime) that work out of the box if you prefer that.
However, the people generally working with/on emacs are not looking for that, they are looking for an editor optimized for customisation. They have already gone through the experience of setting it up, so why would they spend most of their time making it easier out of the box?
There is a cost to everything, and so far most people on emacs side have decided to spend their time on improving it's power, not it's ease of use.
For the most part it is completely optional to configure it and use elisp... it will ask you if you want to install a layer (group of packages) when you open up a filetype that it knows about and can handle. there is some configuration akin to setting up completion backend, linters, formatters etc that are applicable to your language/filetype of choice. The benefit of that is that the external tools are kept external where development of them can continue unimpeded by the development of the main text editor.
similarly, once you get to know the language quirks, it's a decent language that is basically a DSL for text editing. The power you get from being able to lookup how something was implemented by the text editor developers easily is extremely powerful.
If you like vim's idea of modal editing, emacs is 100% all about that. languages are major modes, minor modes are functions and keybindings that can be enabled and grouped together at will. transient buffers are used to send output to and are treated as normal buffers that you can do things to. The architecture and extensiblity of emacs is pretty amazing actually. Every key press is just a function and every key can be rebound based on current context using things like mode maps that get layered on top of everything and have precedence based on where you inserted the binding with sensible fallbacks when required.
Disclaimer: I love vim as a concept but hate viml and the plugins that were hampered by the lame programming language that was designed by bram.
if you have not tried magit and org mode you just don't really understand the power of emacs and the power of having everything be a function. spacemacs just makes setting up that powerful environment fairly painless but it's still a very old architecture with some warts.
The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL.
Instead, you develop code in a file, but constantly evaluate code as you go along.
When I work on a clojure project, I very rarely open the actual REPL, but I am constantly evaluating code and experimenting with different implementations of functions.
Then, when I'm happy with the results, I ask the editor to evaluate and insert the results back into the editor. This then becomes the unit test.
> The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL.
> Instead, you develop code in a file, but constantly evaluate code as you go along.
Yes but what you are describing is hot code replacement and evaluation. You do not need a REPL. For a concrete example Java + JRebel + Debugger (Eclipse calls it Display with a glasses icon) will do that for you.
In my mind a REPL is very much about the input and of course the output otherwise its basically what I mentioned above.
And I think the the article doesn't really go into any new innovation or attempts at making REPLs better (particularly because they mention Bret Victor)... ie better input and better output.
Yes advanced REPLs have history saving capabilities and what not but then they are basically competing with the rest of the editor, IDE and source control.
Really innovative REPLs I think are what Bret shows, as well Squeak, and Racket. Those environments offer really unique input and output.
Racket is a really exciting language, especially with its focus on building small languages to solve problems.
However, where it fails for me is in its lack of interactive development. When I investigated it, there seemed to be no way to actually connect a repl to a running program.
Unlike with common lisp or clojure, with racket if you make changes to your code you have to restart the REPL, which destroys your state.
This was a big disappointment to me, because even python with ipython and autoreload allows for more interactive development.
I suspect that this decision was made because of racket's start as a teaching language, because it is simpler, but way less powerful.
> When I investigated it, there seemed to be no way to actually connect a repl to a running program.
i (poorly) implemented conditions for racket once, including the ability to drop into a repl at the point of error.
so i think you could put in place some macros that would let you get at a repl wherever you wanted. probably not the sort of thing to leave in place all the time, though
> Unlike with common lisp or clojure, with racket if you make changes to your code you have to restart the REPL, which destroys your state.
that's a different issue. i believe matthias has commented on the mailing list (some years back) that the semantics associated with doing something like that are a mess, and that's why they weren't interested in implementing it.
To me, being able to make changes to your code while keeping the current state in the REPL is key to interactive development.
My workflow is generally to build up state, and then experiment with functions on that state until I get the correct output.
This workflow is very natural in Clojure, Common Lisp and even Python (with IPython and autoreload).
However, in Racket you have to restart everything on every change. This works ok for smaller applications, but if for example, your state is a large dataset that you pull from a remote database, it becomes a little more difficult.
There are possibly workarounds, and I'm not saying that Racket is bad because of this. There are definite advantages to this approach, mainly for keeping everything simple and predictable. However, this was a roadblock for me, and the main reason why I didn't spend more time working on it.
I also miss the ability to make changes to code, refresh the browser and instantly see the changes (instead of having to restart the server after each change).
Thanks. Do you know if it works with the module system - for example, if I edit function definition in a module, and then send that module definition to the REPL, would any code using that module start using the new definition?
I believe this is a design decision, because relying on some enormous implicit repl state and updating the code in place is a good way to get yourself into states that are impossible to reach in an actual running program.
Racket is a functional language and it is their belief that you should just make predictable ways to startup your interactive development than rely on the entire state of some repl image.
You're right; it's a conscious decision. I had a little discussion with Eli Barzilay and Matthew Flatt about some related matters a little while back. It was a nice discussion, but image-based or live programming is just not something they found particularly compelling.
It pretty much keeps me from using Racket, and a bunch of other things that are otherwise very nice. Given a choice, I will always choose the tools that support me in building things by modifying programs as they run. I'm just happier and more productive that way.
So one of my axes of optimization is selecting projects that enable me to work that way.
I don't know what this refers to, but it doesn't ring a bell. The most I might have said is that the community in general is not too interested; but personally, this kind of dynamic interaction is something that I very much appreciate. In fact, when I implemented xrepl (which is now the default when you start racket) being able to modify code inside modules was one of the main goals. The only reason I didn't do something like that for Emacs is that my own use of CL/Scheme variants in Emacs was always very simple, but I actively encouraged people to do something similar for Emacs -- and Geiser/Racket-mode are two serious Emacs packages that actually do that kind of interactive use.
I asked you guys about image-saving because I was considering using Racket to build a new version of bard, and I thought I might like to both use image-saving during development and piggyback on a Racket implementation of it for use in bard's runtime. As I recall, you guys wanted to know what I found compelling about image-saving, but you didn't find it as compelling as I did.
I still might build a bard on Racket, but if so, I'll most likely build my own VM and implement my own image-saving solution for it.
Assuming, of course, that there are enough hours in the day, and enough years in a life.
I'm not sure if this is exactly what you are talking about, but with racket-mode in Emacs you can write some program, run it (C-c C-k), then add some s-expr and evaluate only that (C-x C-e) in the current context.
I once delivered a public speaking course to a group of prisoners about to go on parole. It was really eye opening to see how low confidence most of them had, and how bad they were at expressing themselves. In my opinion prisons should be made a lot more like college - make it that prisoners are forced to learn skills instead of being forced to do nothing.
My main problem with it is that, unlike with executing commands in the shell, with org you don't get any progress, and emacs seems to hang while running the command.
For example, running apt update tends to freeze emacs without any progress reporting for a few minutes.
I'm hoping that I'm doing something wrong and that someone can chime in with a suggestion, because I really like org-mode, and I really like the idea of doing devops using it.