71–80 of 110 posts
You could do this with (battle-tested) pomegranate [1] ages ago, which is used by leiningen as the default resolver.
I think you might be missing the main "aha!" of clojure REPLs vs REPLs in non-homoiconic languages: you can very easily execute small parts of the program you're editing without re-typing the code. In emacs, for instance, you often use `eval-last-sexp`, by default bound to C-x C-e. This lets you move your cursor to a particular point in the file, often deep in a function, and get the results of just the form(s) you'r…
but that depends on how the environment is looking at the time.
during development, in scheme, i just have a function (reset) that reloads all the files of an app. sometimes i create a thread and poll the filesystem and reload everything that changed in the last second. that way i never have to C-x anything. if i need to eval a subexp i just jump on the repl and do it.
Earlier quoted context omitted.
When you evaluate a form deep in a function, how do you handle variables that are defined "outside"? How can you evaluate such expressions?
Cider (the clojure plugin for emacs) has a variant that prompts you for the the values for those variables.
I think you might be missing the main "aha!" of clojure REPLs vs REPLs in non-homoiconic languages: you can very easily execute small parts of the program you're editing without re-typing the code. In emacs, for instance, you often use `eval-last-sexp`, by default bound to C-x C-e. This lets you move your cursor to a particular point in the file, often deep in a function, and get the results of just the form(s) you'r…
I can do this in Java and C with the right IDE.
properly written java is a joy.
This post could be summarized as "write as much of your project's tooling as you can in the project's main programming language and the project's main programming language should be Clojure" and I agree wholeheartedly.
I think their point is bigger than that. Historically one of the major points against using Clojure to write your tooling was the slow startup times which are just painful from the CLI. It looks like the clj-exec idea linked to in the article is the secret sauce that makes moving to writing your tooling in Clojure a workable idea, since now you have a unified calling convention for both calling tooling from the REPL…
REPL will not work well with multitheading/futures in Clojure.
Earlier quoted context omitted.
No, Julia and Elixir are the same as Python in that regard (Python is more annoying because of the indentation problem). I was just talking about interactive evaluation of expressions selected in the editor. Although I’ve messed with Clojure a bit, I admit I don’t fully appreciate what you’re describing. I’m a little afraid to find out, frankly, because it sounds seductive.
Julia is much closer to Clojure than to Python in this regard, which brings back the point from above that homoiconity isn't the key ingredient
Earlier quoted context omitted.
This is the draw for Jupyter Notebooks as well. Execute code blocks. I remember when I learned this in Matlab. REPL are super nice for this! I've had a hard time in Java, Fortran, etc. in determining the right development patterns that are used in this space to be productive.
Modern Java (11+) has jshell, which has interactive goodies like tab completion, documentation display, paren/bracket matching, etc.
Earlier quoted context omitted.
The homoiconicity of Lisp is not what gives it this superpower. It is rather Lisp's dynamic nature that actually allows you to keep running your project while also developing it that is crucial - something that Clojure running on the JVM can actually only approximate. For example, in a full CL, you can modify a class that is currently being used, and objects of that class will adjust accordingly (for most modificatio…
i get the magical aspect of repls in scheme and CL. not in clojure. not sure why. so i don't like clojure, but i feel like i should ?? why is that?
Still, personally I have little to no experience with Clojure, so I can't really comment too deeply.