3 ms·

> deps.edn Deps is well documented. The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly struc

by dgb23 4y ago

> deps.edn Deps is well documented. The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool. > socket repl over nrepl I personally use Calva (VSCode) which just starts an nrepl based on deps.edn. When writing babashka scripts I start the repl manually and connect to it. Very pleasant experience so far. > Spec seems kind of weird and not well thought out either. I didn't like it at first, but once I got that everything is bottom up I had an AHA moment. Function specs and instrumentation are very powerful. Conform is basically a parser, which can give you a lot of leverage. What bothers me about spec is that it is still not released though.

billfruit 4y ago
Deps may be well documented, but lots of introductory material seems to use lein. Having two systems is more confusing.
- seancorfield 4y ago
  Because a decade ago there was only Leiningen -- so all the books and tutorials (and videos) created in the early days of Clojure had to use it. At work, we started with lein (back in 2011 for our production code), then we switched completely to Boot in 2015, and then we switched completely to deps.edn in 2018. build.clj (tools.build) is a "recent" addition (less than two years since the very first 0.0.1 commit). More and more introductory material is appearing these days featuring deps.edn but given there was a decade of Leiningen usage out there before deps.edn even appeared, the current state of affairs shouldn't surprise anyone. As for more than one system, lots of languages have that situation: consider make -> ant -> maven -> gradle etc.
- puredanger 4y ago
  How do we ever move the world forward if we are only allowed to have one thing?
BaculumMeumEst 4y ago
> Deps is well documented. > The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool. This seems like a contradiction, because if it was well documented you wouldn’t need to look at other people’s configs to see how to use it. My experience with deps.edn is that every time I start a project and make a deps.edn file, I immediately draw a blank and don’t know how to structure it, so I open ones from other projects to start lifting stuff out of them. I still don’t know how to reliably configure a project to use nrepl or socket repl without just using an editor plugin. I definitely have no idea how to use those in conjunction with a tool like reveal. To me, none of that is simple. Simple would be like Emacs’ use-package. With that I know how to add dependencies, specify keybinds, and do initialization and configuration off the top of my head knowing only the name of a package I want to use. And it has really nice documentation with tons of examples. https://github.com/jwiegley/use-package https://github.com/jwiegley/use-package
- sokoloff 4y ago
  The C language is extremely well-documented. It's still helpful to see other people's C code to understand common/useful patterns.
  - BaculumMeumEst 4y ago
    I don't know. I saw tutorials mixing clj -A, -X and -M flags, but what's the difference between them? When do I use each? What's the -r flag do and how do I use it? How do I update my dependencies? How do I build a jar and deploy it? It just always felt like I was running into things that felt basic and the docs didn't have an answer for them. I would see so many elaborate deps.edn files in people's configs and when I tried to look up how they worked I couldn't find anything.
    - ReleaseCandidat 4y ago
      > I saw tutorials mixing clj -A, -X and -M flags, but what's the difference between them? That depends how you define your build targets (called aliases) in deps.edn. And there is also -T to call (public) functions in a namespace (file/program), e.g. when using build.clj - that's for building your jar. -X calls a function that you can define using :exec-fn, :exec-args has it's arguments (usually a map) -M calls the main function ('executes a program', if you will), it's 'normal' (command-line) arguments are passed using :main-opts And btw. `clj` is just a wrapper around `clojure` that runs `clojure` in rlwrap. No need to use this if you do not use the REPL. Here is a (big) template I've just finished yesterday: deps.edn: https://github.com/Release-Candidate/Clojure-Template/blob/main/deps.edn https://github.com/Release-Candidate/Clojure-Template/blob/m... and it's usage: https://github.com/Release-Candidate/Clojure-Template#build-targets https://github.com/Release-Candidate/Clojure-Template#build-... build.clj - build a jar and run mkdocs https://github.com/Release-Candidate/Clojure-Template/blob/main/build.clj https://github.com/Release-Candidate/Clojure-Template/blob/m...

by dgb23 4y ago

billfruit 4y ago

Deps may be well documented, but lots of introductory material seems to use lein. Having two systems is more confusing.

seancorfield 4y ago
Because a decade ago there was only Leiningen -- so all the books and tutorials (and videos) created in the early days of Clojure had to use it. At work, we started with lein (back in 2011 for our production code), then we switched completely to Boot in 2015, and then we switched completely to deps.edn in 2018. build.clj (tools.build) is a "recent" addition (less than two years since the very first 0.0.1 commit). More and more introductory material is appearing these days featuring deps.edn but given there was a decade of Leiningen usage out there before deps.edn even appeared, the current state of affairs shouldn't surprise anyone. As for more than one system, lots of languages have that situation: consider make -> ant -> maven -> gradle etc.
puredanger 4y ago
How do we ever move the world forward if we are only allowed to have one thing?

BaculumMeumEst 4y ago

> Deps is well documented. > The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool. This seems like a contradiction, because if it was well documented you wouldn’t need to look at other people’s configs to see how to use it. My experience with deps.edn is that every time I start a project and make a deps.edn file, I immediately draw a blank and don’t know how to structure it, so I open ones from other projects to start lifting stuff out of them. I still don’t know how to reliably configure a project to use nrepl or socket repl without just using an editor plugin. I definitely have no idea how to use those in conjunction with a tool like reveal. To me, none of that is simple. Simple would be like Emacs’ use-package. With that I know how to add dependencies, specify keybinds, and do initialization and configuration off the top of my head knowing only the name of a package I want to use. And it has really nice documentation with tons of examples. https://github.com/jwiegley/use-package https://github.com/jwiegley/use-package

sokoloff 4y ago
The C language is extremely well-documented. It's still helpful to see other people's C code to understand common/useful patterns.
- BaculumMeumEst 4y ago
  I don't know. I saw tutorials mixing clj -A, -X and -M flags, but what's the difference between them? When do I use each? What's the -r flag do and how do I use it? How do I update my dependencies? How do I build a jar and deploy it? It just always felt like I was running into things that felt basic and the docs didn't have an answer for them. I would see so many elaborate deps.edn files in people's configs and when I tried to look up how they worked I couldn't find anything.
  - ReleaseCandidat 4y ago
    > I saw tutorials mixing clj -A, -X and -M flags, but what's the difference between them? That depends how you define your build targets (called aliases) in deps.edn. And there is also -T to call (public) functions in a namespace (file/program), e.g. when using build.clj - that's for building your jar. -X calls a function that you can define using :exec-fn, :exec-args has it's arguments (usually a map) -M calls the main function ('executes a program', if you will), it's 'normal' (command-line) arguments are passed using :main-opts And btw. `clj` is just a wrapper around `clojure` that runs `clojure` in rlwrap. No need to use this if you do not use the REPL. Here is a (big) template I've just finished yesterday: deps.edn: https://github.com/Release-Candidate/Clojure-Template/blob/main/deps.edn https://github.com/Release-Candidate/Clojure-Template/blob/m... and it's usage: https://github.com/Release-Candidate/Clojure-Template#build-targets https://github.com/Release-Candidate/Clojure-Template#build-... build.clj - build a jar and run mkdocs https://github.com/Release-Candidate/Clojure-Template/blob/main/build.clj https://github.com/Release-Candidate/Clojure-Template/blob/m...