41–50 of 306 posts
The situation with windows is weird. You have to run a powershell script to install. They should just offer a Zip or Exe like every other programming language. https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind...
Leiningen works great on Windows, and Boot is meant to as well (though I don't have first hand knowledge of that).
While we are at it - how do you refactor a mid-sized/large Clojure project?
Long term I can see a more intelligent feedback system powered by codeq helping with static analysis and refactor feedback, like unison but better (using a real DB and open for extension)
Earlier quoted context omitted.
That makes sense but it's not what comes across. The sentence immediately after says that "the language continues to grow". That's what I'm questioning.
That is my impression, especially 2019 seems to have been a turning point after 1-2 years of relative stagnation, but I get that you feel differently. That's why you switched to OCaml ;-)
Last week some nice folks assured me tooling was good in Clojure; and not a total time suck, and so I'm getting ready to take the jump I think... but, one thing I'm still really skeptical about... is embodied in this paragraph: > The way the languages are integrated today, Clojure developers doing full-stack development don’t really have to think about data serialisation/deserialisation. Writing code for frontend and…
Example 1: I'm using Clojure's Spec library for validation. There is code that is used on the browser to validate the input that users enter into forms, and the same exact code is used on the HTTP endpoints that are called when the user attempts to submit the form.
Example 2: I'm using the Tongue library to provide client-side translations of the whole UI, but the same data files and library are used in some cases on the server to generate files that contain translated strings.
Example 3: The web UI logic is written using pure data manipulation (thank the Re-frame library for that) and because of that we are able to unit test it on the JVM without having to go through the complecity of launching and driving a browser on our CI server.
Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…
Earlier quoted context omitted.
Some of it is libraries and frameworks. Some of it is the attention Clojure has paid to ergonomics. A lot of Clojure’s libraries seem to have been built by smart people for mediocre programmers (like me!). Elsewhere in lisp land it can feel like smart people wrote libraries for themselves. For me Racket is probably the closest thing to a decent end-to-end modern lisp experience with decent libraries outside Clojure.…
"I don’t trust Oracle enough to stop pretending that Graal doesn't exist." Did I parse that correctly as: "I don't trust Oracle, therefore I pretend Graal doesn't exist"?
Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…
I agree there's a sometimes frustrating lack of branding and documentation for the one true way of doing things
But I'd be careful what you wish for, Clojure is still fertile land, nothing has come along and crushed all alternatives yet and I think our community is right to think long and hard before promoting the new one true way because most of us are refugees from other languages where it's already happened
Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…
If all you want is a rails thing but with a Clojure twist I'd keep an eye on https://youtu.be/jkx9F-RIFiY I agree there's a sometimes frustrating lack of branding and documentation for the one true way of doing things But I'd be careful what you wish for, Clojure is still fertile land, nothing has come along and crushed all alternatives yet and I think our community is right to think long and hard before promoting th…
Last week some nice folks assured me tooling was good in Clojure; and not a total time suck, and so I'm getting ready to take the jump I think... but, one thing I'm still really skeptical about... is embodied in this paragraph: > The way the languages are integrated today, Clojure developers doing full-stack development don’t really have to think about data serialisation/deserialisation. Writing code for frontend and…
I can attest that full stack (server-browser) Clojure code sharing works very-very smoothly. I've been developing web applications like that for some time now, and apart from less context swithing (because it's the same language on both sides), sizeable parts of the code are cross-compiled to run both on the browser and the JVM with very little or no extra effort. Example 1: I'm using Clojure's Spec library for valid…
Number 3 has me totally stoked; since that's incredibly valuable-- or like a dream to me to be honest, could you speak more about how that works? Is it just from using re-frame (which I'm looking at as I write this)? Is it able to test for visual regressions because of the pure-data UI? Or like how have you found that testing functionality in practice has it been saving y'all a lot of bugs and headaches you think?
Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…
On the other hand, to start with just picking something reasonably mainstream (in Clojure terms) is a perfectly good strategy. The choice will be poorly informed, but that's a given if you're a beginner in any case. And such a beginner isn't really in a place anyway to make this choice for a significant project (for any platform/language).
Once an initial choice is made, it seems to me (so far) pretty easy with leinigen templates & plugins just to get started on something. Time from tool setup to coding hasn't been any longer for me than other things I've learned in recent years.