4 ms·

It's nice to have complex build/test setups with deep directory structures, I'm really happy this stuff exists and is being enhanced, but the flexibility kinda

by geokon 5y ago

It's nice to have complex build/test setups with deep directory structures, I'm really happy this stuff exists and is being enhanced, but the flexibility kinda adds a barrier to getting started. It's also important to be able to just drop into a REPL, load some libraries and go. I think the coolest thing in the pipeline is going to be `add-libs`: https://insideclojure.org/2018/05/04/add-lib/ https://insideclojure.org/2018/05/04/add-lib/ I made a little orgmode literate demo that is selfcontained (no deps.edn) and even produces some inline SVG https://geokon-gh.github.io/literate-clojure.html https://geokon-gh.github.io/literate-clojure.html I hope this gets added into `core` and single file Clojure programs become a norm. Right now you still need to add tools.deps.alpha into your default user deps.ends for things to work. If this stuff gets into core you could finally send someone a file/gist and they could run it directly. I think that'd really improve the Clojure ecosystem. You can imagine sharing one-file issues/demos/examples and people don't need to reproduce your local setup or clone a whole repo

capableweb 5y ago
> I'm really happy this stuff exists and is being enhanced, but the flexibility kinda adds a barrier to getting started Clojure (seems to me at least) has always preferred to cater to professionals who want to learn languages, tools and concepts deeply rather than being quick to learn. So naturally, the ecosystem tends to lean towards simple tools you use as building blocks rather than one-size-fits-them-all ala Ruby on Rails. This does make it harder to get started with Clojure, but once you've taken the time you to learn everything, it really pays off.
- geokon 5y ago
  The tools pay off for sure but even once you know how to use deps.edn and company, I'd argue you still really need quick one-file programs. It's not just about education (though that's important as well). I think the top two use-cases are scripts and issues. Issues, .. well you want to be a nice dev and post issues with some sample code that reproduces the problem.. but you don't want to have make a whole repo (and then have it floating around on your github indefinitely?) just to show an issue/problem that takes 20 lines of code. So then most people end up copying the problematic code into the github issue text box.. and... it sorta kinda works? but not really. Neither you nor the library maintainer can actually copy and run the code now, so you both end up squinting at it and trying to guess what went wrong. It's just a mess. Even if you make a repo, then how do you get feedback? Other people need to fork and upload their own versions of your demo repo? It's just too heavy handed. For scripts and quick hacks you want to bang out code quickly. Open up a new file and write .. slurp some files, massage some data, look at some values .. maybe spit out a plot etc. And you want to be able to quickly look over them 2 months later and see what the hell you did. You want to be able to send and share them easily. It really needs to be all in one file otherwise it's just too much of a hassle. I think the final killer features of `add-libs` that I'm appreciating more as I use it - is that since you can add libraries right in the REPL dynamically you never need to modify your deps.edn and reboot CIDER! It seems minor, but restarting CIDER just always sucks.. and at least for me it breaks the "flow". You loose all the state you had (if you're poking around you can have lots of little variables around) and you loose all your command history. You can only modify your workflow so much to accommodate the inevitable occasional CIDER reboots.
  - monsieurbanana 5y ago
    Babashka fills the scripts / one-file programs niche rather well. It comes with many built-in libraries[0], add-libs equivalent, and very fast startup time [0] https://book.babashka.org/#libraries https://book.babashka.org/#libraries
puredanger 5y ago
gists are git repos and can contain multiple files. Since clj supports git deps, you've been able to use them as deps for a long time. Example gist: https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632f3351f8 https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632... Run it: clj -Sdeps '{:deps {a/gist {:git/url "https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632f3351f8.git https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632..." :sha "116ac594c922be6ed9d3366f5ac89ed2b0a082f5"}}}' -X foo/bar :name '"Alex"'
- geokon 5y ago
  that's pretty cool! I guess gists are a bit fancier than a normal pastebin. They don't really advertise it and they don't even display the sha hashs. I didn't realize that :) and thank you for the demo. With the`:paths ["."]` you flatten the project and minimize the example size. It would make demos look much better In the end it's not quite as ergonomic as using `add-libs`, but it something that works today. Hope`add-libs` makes it into core some day. Having one-file programs would really take away the remaining friction of sharing code. PS: thank you for your help on ask.clojure.org the other day. I got your book and am looking forward to reading it
  - puredanger 5y ago
    add-libs is definitely still on the future list!
    - geokon 5y ago
      Looking forward :) I just know getting things in core is difficult b/c understandably you wanna keep most things out in utils libs. But if you wanna have launchable scripts/code-snippets then having to ask people to append -Sdeps blahblah complicates things a bit btw, I had a question about dependencies resolution that's always been a bit mysterious for me from: https://insideclojure.org/2018/05/04/add-lib/ https://insideclojure.org/2018/05/04/add-lib/ "Additionally, this code is not just blindly adding dependencies you ask for but is actually considering them in the context of the dependencies already on your classpath. So if for example, you already had a version of org.clojure/data.priority-map above, it would do the dependency resolution in the context of that version and not resolve to or add a new version to the classpath." If you have libraries A and B and they depends on library C. Say A has it tagged at version v1.234 and B has it tagged at v1.345. From the doc's glossary it sounds like it will just get the latest version and hope nothing breaks. https://clojure.org/reference/deps_and_cli#_glossary https://clojure.org/reference/deps_and_cli#_glossary I haven't had it happened, but I could imagine a scenario where you add library B and library A starts to misbehave. And if I understand correctly, there is no way to have multiple versions of a library in the path. Is that right? I know in C++ world this is a big unspoken issue. Package managers usually just mash things with the latest version and hope it works, while some build systems (like Hunter) will modify symbols so you can link to two copies.

by geokon 5y ago

capableweb 5y ago

> I'm really happy this stuff exists and is being enhanced, but the flexibility kinda adds a barrier to getting started Clojure (seems to me at least) has always preferred to cater to professionals who want to learn languages, tools and concepts deeply rather than being quick to learn. So naturally, the ecosystem tends to lean towards simple tools you use as building blocks rather than one-size-fits-them-all ala Ruby on Rails. This does make it harder to get started with Clojure, but once you've taken the time you to learn everything, it really pays off.

geokon 5y ago
The tools pay off for sure but even once you know how to use deps.edn and company, I'd argue you still really need quick one-file programs. It's not just about education (though that's important as well). I think the top two use-cases are scripts and issues. Issues, .. well you want to be a nice dev and post issues with some sample code that reproduces the problem.. but you don't want to have make a whole repo (and then have it floating around on your github indefinitely?) just to show an issue/problem that takes 20 lines of code. So then most people end up copying the problematic code into the github issue text box.. and... it sorta kinda works? but not really. Neither you nor the library maintainer can actually copy and run the code now, so you both end up squinting at it and trying to guess what went wrong. It's just a mess. Even if you make a repo, then how do you get feedback? Other people need to fork and upload their own versions of your demo repo? It's just too heavy handed. For scripts and quick hacks you want to bang out code quickly. Open up a new file and write .. slurp some files, massage some data, look at some values .. maybe spit out a plot etc. And you want to be able to quickly look over them 2 months later and see what the hell you did. You want to be able to send and share them easily. It really needs to be all in one file otherwise it's just too much of a hassle. I think the final killer features of `add-libs` that I'm appreciating more as I use it - is that since you can add libraries right in the REPL dynamically you never need to modify your deps.edn and reboot CIDER! It seems minor, but restarting CIDER just always sucks.. and at least for me it breaks the "flow". You loose all the state you had (if you're poking around you can have lots of little variables around) and you loose all your command history. You can only modify your workflow so much to accommodate the inevitable occasional CIDER reboots.
- monsieurbanana 5y ago
  Babashka fills the scripts / one-file programs niche rather well. It comes with many built-in libraries[0], add-libs equivalent, and very fast startup time [0] https://book.babashka.org/#libraries https://book.babashka.org/#libraries

puredanger 5y ago

gists are git repos and can contain multiple files. Since clj supports git deps, you've been able to use them as deps for a long time. Example gist: https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632f3351f8 https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632... Run it: clj -Sdeps '{:deps {a/gist {:git/url "https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632f3351f8.git https://gist.github.com/puredanger/cbcdd9f54deb7fb7309fdd632..." :sha "116ac594c922be6ed9d3366f5ac89ed2b0a082f5"}}}' -X foo/bar :name '"Alex"'

geokon 5y ago
that's pretty cool! I guess gists are a bit fancier than a normal pastebin. They don't really advertise it and they don't even display the sha hashs. I didn't realize that :) and thank you for the demo. With the`:paths ["."]` you flatten the project and minimize the example size. It would make demos look much better In the end it's not quite as ergonomic as using `add-libs`, but it something that works today. Hope`add-libs` makes it into core some day. Having one-file programs would really take away the remaining friction of sharing code. PS: thank you for your help on ask.clojure.org the other day. I got your book and am looking forward to reading it
- puredanger 5y ago
  add-libs is definitely still on the future list!
  - geokon 5y ago
    Looking forward :) I just know getting things in core is difficult b/c understandably you wanna keep most things out in utils libs. But if you wanna have launchable scripts/code-snippets then having to ask people to append -Sdeps blahblah complicates things a bit btw, I had a question about dependencies resolution that's always been a bit mysterious for me from: https://insideclojure.org/2018/05/04/add-lib/ https://insideclojure.org/2018/05/04/add-lib/ "Additionally, this code is not just blindly adding dependencies you ask for but is actually considering them in the context of the dependencies already on your classpath. So if for example, you already had a version of org.clojure/data.priority-map above, it would do the dependency resolution in the context of that version and not resolve to or add a new version to the classpath." If you have libraries A and B and they depends on library C. Say A has it tagged at version v1.234 and B has it tagged at v1.345. From the doc's glossary it sounds like it will just get the latest version and hope nothing breaks. https://clojure.org/reference/deps_and_cli#_glossary https://clojure.org/reference/deps_and_cli#_glossary I haven't had it happened, but I could imagine a scenario where you add library B and library A starts to misbehave. And if I understand correctly, there is no way to have multiple versions of a library in the path. Is that right? I know in C++ world this is a big unspoken issue. Package managers usually just mash things with the latest version and hope it works, while some build systems (like Hunter) will modify symbols so you can link to two copies.