6 ms·

org-babel is a really cool extension of org-mode and Emacs. But it is only useful for Emacs users and therefor useless for any professional use-cases. As much a

by knowhy 6y ago

org-babel is a really cool extension of org-mode and Emacs. But it is only useful for Emacs users and therefor useless for any professional use-cases. As much as I love Emacs expecting people to learn it is a bit too much.

dig1 6y ago
If you look at Emacs/org-babel as a tool, why is it useless for professional use-case? It is just like saying: it is too much for people to learn to use Rstudio/Shiny, yet this is frequently a go-to tool in the scientific community.
dmortin 6y ago
Why would it be useless for non-Emacs users? It's an integrated tool, just like any other tool which you learn to use. You can use it for this purpose while you use some other editor for other tasks. You don't have to use Emacs for everything just because you use a certain application of it.
bloopernova 6y ago
Well, it is possible to run Emacs in batch mode from the command line. Therefore you could have someone create the files as documentation, with instructions on how to run them as a single command. I haven't tried this specifically with org-babel, and as other commenters in the thread state, Terraform/Ansible may not lend themselves to org-babel quite so easily, but it's certainly possible. Although maybe not worth the effort unless you really push hard for a team to document their infrastructure code in this way.
- konjin 6y ago
  I have used emacs with make for this purpose. It works, but the main issue is white space. Any language that has significant white space is liable to break in org mode, and a ton of devops tools are python based, or python like. I've been using guile and noweb, with a tangle I wrote myself, for literate devops on top of Guix and it works better than anything else I've tried.
  - bloopernova 6y ago
    That's really cool, do you have any public examples of the guile/guix code?
zelphirkalt 6y ago
So your point is, that org mode is just inside one tool and therefore one cannot expect everyone else on the team to learn it? I think we can make the same argument for every single tool out there, like one specific IDE or whatever you have. It's just a question of how many people already use Emacs on the team, to make a democratic decision. Or is there some criteria, by which I can sort tools into 2 camps, "OK to force upon coworkers" and "not OK to force upon other coworkers"?
- tronbabylove 6y ago
  I suspect a mandate to use Org could be counter-productive. One of Org's unique advantages is the pliability it has by virtue of running in Emacs. I doubt whether someone who was forced to use it would have the intrinsic motivation to climb the notoriously steep learning curves for both Elisp and Emacs. Subtract Elisp (and with it, the ability to do any debugging or customization) and you're left with stock Org mode running in an inferior text-editor. Maybe stock Org is still enough of an improvement over Markdown that it's worth the overhead of learning Emacs, but I'd have a hard time making that pitch to my coworkers.
tronbabylove 6y ago
Someone tried to liberate Org from Emacs by writing a parser in Rust (see previous discussion on HN [1]), but it looks like the project died unfinished [2]. [1] https://news.ycombinator.com/item?id=19660349 https://news.ycombinator.com/item?id=19660349 [2] https://github.com/org-rs/org-rs/issues/41 https://github.com/org-rs/org-rs/issues/41
wffurr 6y ago
This isn't a system you'd deploy and expect others to maintain. It's a system for developing your playbook and Ansible / Puppet / etc configurations. Emacs is absolutely suitable for the use case of a professional developer writing these things. The literate programming notebook approach is very interesting. Better IMO is to reverse it and write copious comments throughout an idempotent script that you can continually edit and re-execute. In either case, the final product that you share with others are your notes and an actual deployed configuration for a real system, not a config file for an IDE.
monkpit 6y ago
Yeah, a jupyter-style solution is much more accessible IMO

by knowhy 6y ago

dig1 6y ago

If you look at Emacs/org-babel as a tool, why is it useless for professional use-case? It is just like saying: it is too much for people to learn to use Rstudio/Shiny, yet this is frequently a go-to tool in the scientific community.

dmortin 6y ago

Why would it be useless for non-Emacs users? It's an integrated tool, just like any other tool which you learn to use. You can use it for this purpose while you use some other editor for other tasks. You don't have to use Emacs for everything just because you use a certain application of it.

bloopernova 6y ago

Well, it is possible to run Emacs in batch mode from the command line. Therefore you could have someone create the files as documentation, with instructions on how to run them as a single command. I haven't tried this specifically with org-babel, and as other commenters in the thread state, Terraform/Ansible may not lend themselves to org-babel quite so easily, but it's certainly possible. Although maybe not worth the effort unless you really push hard for a team to document their infrastructure code in this way.

konjin 6y ago
I have used emacs with make for this purpose. It works, but the main issue is white space. Any language that has significant white space is liable to break in org mode, and a ton of devops tools are python based, or python like. I've been using guile and noweb, with a tangle I wrote myself, for literate devops on top of Guix and it works better than anything else I've tried.
- bloopernova 6y ago
  That's really cool, do you have any public examples of the guile/guix code?

zelphirkalt 6y ago

So your point is, that org mode is just inside one tool and therefore one cannot expect everyone else on the team to learn it? I think we can make the same argument for every single tool out there, like one specific IDE or whatever you have. It's just a question of how many people already use Emacs on the team, to make a democratic decision. Or is there some criteria, by which I can sort tools into 2 camps, "OK to force upon coworkers" and "not OK to force upon other coworkers"?

tronbabylove 6y ago
I suspect a mandate to use Org could be counter-productive. One of Org's unique advantages is the pliability it has by virtue of running in Emacs. I doubt whether someone who was forced to use it would have the intrinsic motivation to climb the notoriously steep learning curves for both Elisp and Emacs. Subtract Elisp (and with it, the ability to do any debugging or customization) and you're left with stock Org mode running in an inferior text-editor. Maybe stock Org is still enough of an improvement over Markdown that it's worth the overhead of learning Emacs, but I'd have a hard time making that pitch to my coworkers.

tronbabylove 6y ago

Someone tried to liberate Org from Emacs by writing a parser in Rust (see previous discussion on HN [1]), but it looks like the project died unfinished [2]. [1] https://news.ycombinator.com/item?id=19660349 https://news.ycombinator.com/item?id=19660349 [2] https://github.com/org-rs/org-rs/issues/41 https://github.com/org-rs/org-rs/issues/41

wffurr 6y ago

This isn't a system you'd deploy and expect others to maintain. It's a system for developing your playbook and Ansible / Puppet / etc configurations. Emacs is absolutely suitable for the use case of a professional developer writing these things. The literate programming notebook approach is very interesting. Better IMO is to reverse it and write copious comments throughout an idempotent script that you can continually edit and re-execute. In either case, the final product that you share with others are your notes and an actual deployed configuration for a real system, not a config file for an IDE.

monkpit 6y ago

Yeah, a jupyter-style solution is much more accessible IMO