Can someone enlighten me about the REPL that lispers keep raving about? Isn't it more-or-less the same as the Python REPL?
[flagged]
Doesn't sound too different from Typescript breakpoints attached to a running website with "Hot Module Replacement."
Bringing Clojure programming to Enterprise (2021)
71–80 of 135 posts
Re: Bringing Clojure programming to Enterprise (2021)
#72I'd love to work with Clojure. I have the misfortune of working on something that is stuck on java1.8 and Groovy, part of the issue is the code quality is a disaster (json and xml parsed with regex...). At least with Clojure I'd get to enjoy the repl workflow and usable text editor (emacs). I also just enjoy working with sexps.
The latest clojure still works with Java 8 fwiw... Although I believe they are looking at moving to 17 soon as minimum.
Re: Bringing Clojure programming to Enterprise (2021)
#73Earlier quoted context omitted.
Indeed. For people used to the "typical REPL" from Ruby, Python and alike, the best comparison I've found is this: "Typical REPL" workflow: Have one editor open, have one REPL open, have one terminal open that runs the application. One change is typically: Experiment in the REPL window, copy-paste into your editor, write tests, restart application (lose all state), setup reproduction state, test change. Or something…
Being someone who’s used to the “typical REPL” flow, I’m not sure I grasp what’s going on with the no-restarts. The implications I think I see are: * Clojure is built different in terms of hot code reloading * the REPL is its own application process in languages Ruby or Python, but in Clojure it’s sortof a client for the system Is that right? Is there more to it?
Yeah, Clojure code is typically built with this in mind, and the data structures as well.
So in a JavaScript server, you might have the database connection set in some config/thing you pass around to request handlers to use, and if you change a request handler, you typically stop the entire application, then start it again. Then the database connection (and the entire config in fact) would need to again connect.
In a Clojure application, first you either start the repl from the server, or start the server from the repl, then you might instead keep the database connection in an "atom" that you keep around for as long as you have the repl/server running. And instead of restarting the process when you change a handler, you'd only change the handler.
And yeah, the libraries and ecosystem at large is built with this (mostly) in mind for everything. The language also supports this by letting you "redefine" basically anything in a running Clojure application, which would be harder in other languages.
I've done some experiments years ago for doing the same in JavaScript, and it kind of works, but every library/framework in the ecosystem is not built with this in mind, so you'll be writing a lot of your own code. Which, now with LLMs, maybe is feasible, but can't say it was at the time exactly.
Re: Bringing Clojure programming to Enterprise (2021)
#74Earlier quoted context omitted.
I read comments like these in bewilderment. Have you worked for a company that hasn’t created its own, as you put it “mini language”? Have you worked for a company that doesn’t indulge in over engineering, over abstraction and hidden cost? Do you actually do programming for a job at all?
speaking of bewilderment, i'm not sure at all what you're getting at here. because programmers suck we should make tools that make it easier for them to suck?
We should make it easier for them to suck less. It's like providing free needles. Druggies gonna drug, might as well help them drug safely :)
Re: Bringing Clojure programming to Enterprise (2021)
#75It's good to read that Clojure is getting more and more exposure. I write Clojure fpr my day job and wouldn't want to swap it for anything. The community is small but very helpfull and easy reachable. The learning curve is steap indeed, but very much worth it!
Clojure has some pretty big downsides last i looked: - syntax is hard to read unless you spend a lot time getting used to it - convention for short var names makes it even harder - function definition order makes it even harder - too dynamic for most people's taste - no type safety - the opposite of boring - no clear use case to show it clearly beating other languages - niche with small community and job market - JVM…
This comment is like saying you can appreciate wine, but you think it should have less grapes.
Re: Bringing Clojure programming to Enterprise (2021)
#76Earlier quoted context omitted.
May I ask what your workflow actually looks like? There's been a fair bit of clojureposting over the last few days, and I've decided to jump in and learn. I love the idea of an AI integrated repl (like what Jeremy Howard and team have done with solveit), it's far more in line with my preferred vision of the AI augmented future of coding. Less "swarm of agent" more, "learn with the agent".
Sure! Setup is: - nvim --listen /tmp/nvim — starts Neovim with a socket Claude can connect to - /mcp in Claude Code — enables the Neovim MCP server, gives Claude direct control of Neovim - lein repl in the nvim terminal - Claude reads .nrepl-port, runs :ConjureConnect — REPL is live! The loop is so dope: - Claude writes code directly into my .clj files - Then evals it into the running process via Conjure - Sees the r…
Hmmmm… seeing this workflow makes me wonder if I can do this with Ruby (the integration between agent and repl)
Re: Bringing Clojure programming to Enterprise (2021)
#77Can someone enlighten me about the REPL that lispers keep raving about? Isn't it more-or-less the same as the Python REPL?
Almost exactly, it's mostly how you use the REPL that differs, and then only because of what different editors prioritise. When I'm in Emacs, all my work happens against a running REPL - when I open or save a file, it's reloaded. Any tests loaded in the REPL rerun on every save, within that live instance. If I drop into the debugger, it's against that live instance. I can swap in mock components to a running system,…
I don't know what you meant by pausable background threads in IPython, but if anyone is trying out - I have had some success with VSCode + IPython: https://mahesh-hegde.github.io/posts/vscode-ipython-debuggin... -
(you can theoretically pass "reload": true (or similar option) in launch.json for auto reload, tho I haven't felt the need to use that in my workflows.)
Re: Bringing Clojure programming to Enterprise (2021)
#78Earlier quoted context omitted.
[flagged]
Doesn't sound too different from Typescript breakpoints attached to a running website with "Hot Module Replacement."
Yeah to be honest after trying for many years to understand what is so special about this famous Clojure REPL I struggled to see how it was that different in practice from Python or other languages. In Python you can also highlight a section code and send it to the console to be evaluated.
I think debuggers are just better anyways. When I got into the weeds trying to do this interactive REPL workflow on an actually running webapp it was a big mess. You have to write custom code all the time to basically capture data and save it into global variables, so that you can inspect them (as opposed to a debugger where you can just set a breakpoint and inspect all the variables in the middle of the precise spot in the request-response cycle).
I think maybe this was ahead of its time when it came out in 2008 or got popular in 2010-2015, but nowadays I am not seeing what's specifically more productive about the Clojure REPL than the interactive development experiences available in Laravel, Python, JS, etc.
Re: Bringing Clojure programming to Enterprise (2021)
#79It's good to read that Clojure is getting more and more exposure. I write Clojure fpr my day job and wouldn't want to swap it for anything. The community is small but very helpfull and easy reachable. The learning curve is steap indeed, but very much worth it!
Clojure has some pretty big downsides last i looked: - syntax is hard to read unless you spend a lot time getting used to it - convention for short var names makes it even harder - function definition order makes it even harder - too dynamic for most people's taste - no type safety - the opposite of boring - no clear use case to show it clearly beating other languages - niche with small community and job market - JVM…
These might be theoretical issues that people without experience worry about, but let me share what I've witnessed in practice working almost a decade with Clojure at Nu.
We mostly hired people with no previous Clojure experience. Majority of hires could pick up and get productive quickly. People fresh out of college picked it up faster. I even had a case of employee transitioning careers to S.E., with no previous programming experience, and the language was a non issue.
I can't remember an instance where the language was a barrier to ship something. Due to reduced syntax surface and lack of exotic features, the very large codebase followed the same basic idioms. It was often easy to dive into any part of the codebase and contribute. Due to the focus on data structures and REPL, understanding the codebase was simply a process of running parts of a program, inspecting its state, making a change, and repeat. Following this process naturally lead to having a good test suite, and we would rely on that.
Running on the JVM is the opposite of a problem. Being able to leverage the extensive JVM ecosystem is an enormous advantage for any real business, and the runtime performance itself is top tier and always improving.
The only hurdle I could say I observed in practice was not having a lot of compile time guarantees, but since it was a large codebase anyway, static guarantees would only matter in a local context, and we had our own solution to check types against service boundaries, so in the end it would've been a small gain regardless.
Re: Bringing Clojure programming to Enterprise (2021)
#80Earlier quoted context omitted.
yes it's just my opinion. but Clojure's market share is tiny so there must be something to that. it's not even in the top 50 here: https://www.tiobe.com/tiobe-index/ . Lisp is 26.
If anything, I think that makes Clojure better. Almost no one in the community is doing stuff to serve "lowest common denominator", compared to how most of JS/TS development is being done, which is a breeze of fresh air for more senior programmers. Besides, the community and ecosystem is large enough that there are multiple online spaces for you to get help, and personally I've been a "professional" (employed + freel…
Spinning dwindling adoption as a good thing because it "unburdens community from serving lowest common denominator use-cases" is exactly the kind of of downplaying/deflection of every issue that I'm talking about, which constantly happens in the Clojure community. It's such an unhealthy attitude to have as a community and it holds it back from actually clearly seeing what the issues are and coming up with solutions to them.
Every problem people face is "not a problem" or "actually a good thing" or, maybe if all else fails we can make users feel bad about themselves. Clojure is intended for "well experienced, very smart developers". Don't you know, our community skews towards very senior developers! So if you don't like something, maybe the problem is just that you're not well experienced enough? Or, maybe what you work on is just too low-brow for our very smart community!