6 ms·
I preach about using the REPL non-stop to my coworkers and we don't use Clojure. The problem with REPL-driven development is that you need to invest in your set
by jrvarela56 4y ago
I preach about using the REPL non-stop to my coworkers and we don't use Clojure. The problem with REPL-driven development is that you need to invest in your setup - so you have to believe it's worth it. Not even the Clojure REPL works out of the box: you need to make sure your definitions are reload-friendly, Emacs/Calva have to be connected for you to eval stuff with commands, use comment blocks as scratchpad, etc - it's a bunch of little conventions you need to buy into.
That being said, the setup cost is paid pretty quickly. Developers underestimate how much time they waste reloading stuff into place. Updated a function - woops, have to clear the variables I setup and run intermediate steps all over again. Even if you think 'yeah but I just write tests and those run the whole flow' using a REPL is worth it. I work with Rails, use guard and try to keep tests fast by sticking to POROs and still does not beat the interactivity of the REPL.
One workflow that comes close is working with Elm's compiler. Super friendly and interactive; gives you a similar iterative flow as a REPL but in a different context.
- __MatrixMan__ 4y agoIt's good to see this acknowledged. I tried to learn Clojure and appreciated the language but I just couldn't get my vim head around the emacs ecosystem well enough to experience the nirvana. I may well try again.
- Fellshard 4y agoThe vim/evil-equipped distributions go a long way toward helping with this.
- jrvarela56 4y agoI haven't used vim in years but there's a package by Tim Pope: https://github.com/tpope/vim-fireplace https://github.com/tpope/vim-fireplace This is a key piece of the REPL workflow: you rarely type into the REPL, you use commands in your editor to select code and run it in a REPL. The idea is that you eval stuff in the same place you type, and that gets run in the same environment over and over again without having to restart it or redefine the data you're using to iterate your functions.
- delboni 4y agoGive a try to this setup: https://github.com/rafaeldelboni/nvim-fennel-lsp-conjure-as-clojure-ide https://github.com/rafaeldelboni/nvim-fennel-lsp-conjure-as-... It's for neovim, but is using very modern tools and even uses a clojure like lisp to configure the setup.
- __MatrixMan__ 4y agoI will, thanks!
- kgwxd 4y agoI'm a vim head too and tried to embrace emacs, because it seems the de facto standard, but I eventually realized it was dumb to trade my editor of choice for that reason, especially at the same time I'm learning a new language. So I ventured into Fireplace and the paredit equivalent (It's been a while so I forget the name) and I was much more comfortable with that setup. Also, I'm equally as comfortable in "standard" editors, like VS Code, since I have to use Visual Studio for work most of the time (vim plugins are ok, I just don't mind context switching, feels like it keeps the mind sharp). I've tried Calva for Clojure dev in VS Code and I think it's just as nice as the other setups. I don't think anyone using an "alternative" setup is going to miss out on any of the "big ideas" that make Clojure dev so nice. I suggest sticking with vim, at least to start. I've never had the opportunity to use Clojure in production projects but, as an exercise in learning the langue, I did a library that I've had to rewrite for many production systems (can't copy paste across companies), in various languages, over the past 15 years, and I liked the end result of the Clojure version way more than any other. It was objectively shorter and easier to reason about. Even the insane, invalid XML parsing that has to be done to integrate with a third-party interface. Just hope I get to use it, in a pragmatic sense, someday.
- djha-skin 4y agoIt's not as difficult as those who think they are elite would have you believe. Here is my common lisp setup easily adaptable to clojure: https://blog.djha.skin/p/developing-common-lisp-using-gnu-screen-rlwrap-and-vim/ https://blog.djha.skin/p/developing-common-lisp-using-gnu-sc... My thoughts on emacs versus vim and a better approach to trying to get them to be useful for things like common Lisp and Clojure: https://blog.djha.skin/p/emacs-users-im-okay-i-promise/ https://blog.djha.skin/p/emacs-users-im-okay-i-promise/ The main idea is that you don't need an IDE. Most Ides just copy and paste stuff for you into the repl, believing that you're too stupid to learn the commands inside the repl yourself and so they'll do it for you and you'll just learn a bunch of hotkeys. As if learning the hotkeys was easier than just learning the commands. I don't mean to offend anybody but this never made sense to me. Just learn the commands, then you can use the commands from whatever editor you want without having to relearn a bunch of hotkeys switching from emacs to vs code. Being a VIM person, I imagine you're pretty comfortable in the terminal and so will not have a problem just using the repl in one window with vim in the other. Then I just have a few plugins to make it easier to copy and paste between vim and the repl. I will say this, getting an LSP client for Clojure does help, but between that and syntax highlighting I'd say you're good to go.
- djtango 4y agoIt's absolutely NOT production ready but I once wrote a one-liner Vim macro to send clojure forms to the REPL via ncat: https://github.com/djtango/spartan-repl https://github.com/djtango/spartan-repl I tidied it up a little for my personal .vimrc but it works surprisingly well for how little effort it took to configure. One known issue is if the thread of execution spawns a sub thread then exits (because the ncat socket is closed) I was surprised just how lightweight a REPL editor integration could be - simply having a Vim editing experience over a REPL is pretty incredible
- barrell 4y agoI also tried to grok emacs when I started learning clojure. Returning to (neo)vim was one of the best days in my entire career. I now use clojure + neovim thanks to: https://github.com/Olical/conjure https://github.com/Olical/conjure Dead simple to set up and to use!
- nordsieck 4y ago> One workflow that comes close is working with Elm's compiler. Another one is Ruby + Pry. It's magical.
- LesZedCB 4y agocan you send code to pry from your editor? i looked it up but never found anything. i actually took a shot at implementing an nREPL server for ruby but all the editors make too many clojure assumptions.
- nordsieck 4y ago> can you send code to pry from your editor? Honestly, I never really tried, and it's been quite a while since I last touched ruby. Being able to interact with a live system at a breakpoint was amazing enough to me at the time. The REPL was pretty nice from what I recall - much friendlier than irb or the builtin python one.
- DEFEC8ED 4y agoYes, it's possible with inf-ruby-mode in Emacs; C-x C-e at the end of a definition works the way it does for Clojure, though the actual REPL implementation in Emacs never feels seamless the way CIDER does (i.e. it generally requires fiddling around with various config settings whereas CIDER basically Just Works™; it feels more like GUD than a proper REPL).
- abraxas 4y agoHow is this at all different from iPython in say, a Jupyter notebook? Not only is it fully interactive but the Python system gives you rich visualization options for your data and flexibility in how you use it (e.g Colab vs local setup).
- djtango 4y agoIt is pretty similar to the Jupiter Notebook experience which is loved by many the modeller, or before that good old Excel. Interactive development has a decent established history of lowering the bar to entry to computing. Less familiar with Python, but my impression was that Jupyter notebooks weren't so great for nudging you towards better software engineering practices (when compared to the clojure REPL)?
- wodenokoto 4y agoNotebooks are good for exploring a problem, especially questions about data. I also don't think they are great for "software engineering", but as the name suggest, they are for notes, not applications. When developing something closer to a program, I usually write code line by line in a text editor, but basically every line has been developed in the IPython REPL. Sometimes I write a few cells in Jupyter Notebook to learn an API. It is really nice that you can have the output of a call in cell 1 while working on refining that call in cell 2. Once I feel I've learned what is needed, I move the code into a .py file and turn it into a script or a module. Despite of this workflow, I haven't found a great pairing between editor and IPython REPL and I am manually copy-pasting code between the two. RStudio works really well in this regard, but I think that the editor runs on the same R kernel instance as the program you are developing, which makes restarting R a pain.
- jrvarela56 4y agoI have limited experience with Jupyter notebooks and have not tried to implement a working prototype (say, Flask+SQLAlchemy) solely using this environment. The canonical Clojure setup would have you start a REPL when you begin your coding session (or more, could be weeks/months without a restart), edit your source files and use keybindings to evaluate text in block comments. This basic setup can go with addons like Calva (VSCode; can inline the results, like a notebook and has other features) and Portal (can render data structures in different viz formats). For Jupyter: - Does your source have to mimic some sort of literate programming style to keep a certain format expected by the notebook? - If you edit other notebooks, do the cells in your current notebook get updated? - Can the notebook be connected to a production environment to run code using live production data?