Fork me on GitHub

Congratulations on all your hard work. This is a recognition of that.

❤️ 2

Greetings good people! I have a few question on using Calva. Any help would be appreciated. 1. How do I exit or stop the repl session? 2. Is there a way to change the repl prompt? I see that new entries are always made on the line AFTER the repl prompt. This is different from how I am used to repls. 3. Lately I have been seeing vertical bars in the repl prompt. Please see attached picture. Any idea where this comes from? 4. Is there a way to turn off linting — clj-kondo and clj-lsp, etc.? I would prefer to keep it simple with just syntax highlighting, indenting, paredit and send to repl. Thanks for the very well built extension for clojure!!

❤️ 2

4: yes, it's not recommended but possible:

gratitude-thank-you 1

It's possible to add that config on ~/.config/clojure-lsp/config.edn as well


Excellent, thanks!


Hello there! 1. Depends on how you started it. If Calva started it you can kill it by pressing ctrl+c in the terminal where the process is started (a.k.a. the Jack-in terminal), 2. No, you can’t change the prompt. (My advice is to not use it very much at all, and instead use Rich comment blocks.) 3. See 4. Eric beat me to it. Sounds awful to run without the linter, but we’re all different. 😃

gratitude-thank-you 2

Thanks a lot @U0ETXRFEW , this is phenomenal work. Been a long time emacs user. With the advent of Gitpod, Github spaces, etc, VS Code is taking a center stage. Having a high quality tool like Calva available is trememendous, everything simply works out of the box for clojure. I used your Gitpod example as well.

❤️ 1
calva 2

Regarding the REPL window, I see the great value in Rich Comment blocks. However, been writing lisp code for 17 years and I have a specific flow. My ratio of source code to experimental code is probably at least 1:20. I do not want to clutter my source file or use it as a scratch. I rely heavily on the repl window (especially *1,*2 commands), practically live there. I'm sure I'm not the only one with this style of lisp coding.


As for linting, there is great value in it too, especially from consistency, style and learning standpoints. But it is an offshoot of the static language culture and is not strictly necessary for a dynamic programming language with incremental compilation capability. For some experimental or toy projects, it is not worth the hassle at all.


I used to use the repl window more often than I do now, and switched to primarily Rich comment blocks as I find it to be a better workflow. You can either remove experimental code in your source files, or use a dev namespace, and leave all your experimental code, sort of like a journal you can revisit later, which can be helpful. I find it can also be helpful in a professional setting to have experimental code left where coworkers can pick up where you left off or use it as a reference for something else. If you haven’t tried using the Rich comment method for a while as a primary way of working, you might find you like it when you try it. But maybe you have tried it for a while and didn’t like it, or you just don’t want to try it. To each their own. simple_smile In any case, with potentially limited window width within VS Code when split screening, and with potentially long namespaces, putting the code on the next line down from the prompt helps keep the prompt out of the way, and the code more easily in the view port. I don’t think linting is strictly necessary for any type of language. I think there’s great value in it though, even in dynamic languages, and maybe even more so in dynamic languages than statically compiled languages, since we don’t have the compiler to tell us about certain issues before the code is run, and we’re left to find out about them when the code is evaluated (and hopefully the error clearly points to the issue). I could be missing something you are considering though!

👌 2

Hello @brandon.ringe ! Thanks to you as well for developing an excellent well thought out tool for us.

calva 2
❤️ 2

Thanks for explaining why the repl prompt was implemented that way, it makes sense. I like the concept of Rich comments and a useful subset of my explorations will get in there. I'm hesitant to record or manage the entirety of my creative/learning process. I will give Rich Comments an honest and full try. I view linting as strictly necessary for developing in Java and such, for myself. With lisp on the other hand, I develop in very small chunks of incremental compilation/evaluation and don't really need a lot of the linter help. That said, on a common project with multiple other developers, I'd use the linter. I prefer to keep my tooling limited to what I absolutely need for a specific project. I agree we are all different in our preferences and styles. I am learning to be comfortable with the fact I disagree with generally accepted wisdom on a lot of ideas about programming. I even disagree with some of Rich Hickey's fundamental ideas on data and data abstraction. Thanks again.


Thanks for the kind words! ❤️ That’s a fair point about linting, and that’s a good way to develop. I’d say I generally develop that way myself, and maybe I would generally catch many actual problems (that would cause errors) even without the linter pretty early on, but I think sometimes it prevents me from even needing to go through the error-then-fix process, potentially saving me time, but I could be overestimating that savings. I also like the code cleanup suggestions it gives. That’s my preference, though. Everyone should do what they like, at least or especially when it’s just themselves working on the code. How dare you disagree with Rich Hickey! 😄 I’m kidding. Anyway, I hope you continue to enjoy Calva and provide your thoughts and feedback when you feel so inclined.

gratitude-thank-you 1
👌 1

Linting sometimes catches actual logic errors, not only syntax errors. Eg when you don't use a function argument or when you shadow a var or a Clojure built in. Or eg when you don't pass in a collection to map. All of those things the compiler will happily accept.

👍 1

I also use the REPL prompt now and then. For *1 and *2 as you mention, @U02T1BU2EV6,and for the history. It is a nice option to have. Though I think I would use it less if Calva helped me using “fiddle” files easier.

👍 1

*1 and *2 and *e work anywhere though.

☝️ 1

@U0ETXRFEW By fiddle files, do you mean like a scratch file where we can execute arbitrary exploration/experimentation stuff while we are coding and learning?


Hi @U7PBP4UVA 👋 . Thanks for pointing out the benefits and discussion. Catching logic errors like that is nice to have for sure in many circumstances, but I don't believe is necessary in a lisp. Not once have I encountered a real problem with function arguments in dynamic languages, even in a large codebase with dozens of engineers. There has been this very strong culture of pushing for type systems, or just plain checking, catching bugs at compilation time for dynamic languages— I don't subscribe to that view and never will. To my mind, effort and time are better spent on solving the real challenges or having adventures. This kind of a thing can be a strong religious type viewpoint for a lot of us though . Perhaps a quote from Douglas Adams is appropriate 😉. "All opinions are not equal. Some are a very great deal more robust, sophisticated and well supported in logic and argument than others."


In general though, I do believe that having linting as default in Calva or other IDEs is the right, proper and sensible thing. My thoughts/feedback are mainly around the idea that linting is essential and would be crazy not to have on all projects.


> By fiddle files, do you mean like a scratch file where we can execute arbitrary exploration/experimentation stuff while we are coding and learning? I am pretty sure that’s what he means. He’s discussed that concept before with me. This is similar to using a dev file/namespace, which you can do currently. I think if Calva added some support for scratch files it would maybe make it easier to keep them out of your repo/project (maybe?), and also make it easy to create and navigate to them.


I can’t say that I myself feel much of a need for that added feature/support, given that I am used to using comment forms and could also use a dev file, and I don’t have a problem committing the code to the repo. One reason I could see to not commit experimental code would be in an open source project when the experimental code might involve some hard-coded secrets for the sake of convenience and, well, experimentation.


> There has been this very strong culture of pushing for type systems, or just plain checking, catching bugs at compilation time for dynamic languages— I don’t subscribe to that view I don’t really subscribe to that view either. > To my mind, effort and time are better spent on solving the real challenges or having adventures. In my opinion, linting can help avoid silly mistakes when solving real challenges or having adventures.

👍 1

And it doesn’t get in my way.

👍 1

@brandon.ringe Your approach (and I guess Pez's approach as well) of sticking to dev files and comments for exploration is really quite interesting. I'm intrigued and would like to to give it an honest try.

👍 1

With regards to *1 and *2 , I think when using files you don’t need them (though you can use them there), because your previous code is still right at your cursor. You can just thread it (using a thread macro) into the next operation, and “grow” your code/experiment. Once the code is in a form you want to add to your source, just copy it up into a function. Then you can delete it or leave it in the comment form. By the way, the Calva refactor commands for threading are pretty convenient sometimes. Search “thread” in the VS Code command palette to see them.


That makes sense. Do you keep the results of evaluation, for any length of time, inside the rich comments or dev ns files?


I keep the code that returns the results, and I might save some result using def .

👍 1

If I want to save some data from an evaluation (maybe an http response), then I might copy it into a file for later.