Feel free to respond here

I/we tend to use bb as a better Makefile so something around that would be good 🙂

What are the design ideas behind bb? What compass do you use to make decisions?

I’d like to hear your thoughts around how to contribute productively to open source. I feel like I’ve learned a lot contributing to Neil about the social aspects, and how to structure a “piece of work” as PRs. Plus “let’s not make things complicated if we don’t have to”.

I’m also interested in whether there’s a system behind all your open source projects. Do you loose track? No? Is that just plain old experience? Or do you use “I want to make a small library” as the “first meaningful thing”? I get the impression that cherry and clj2el just started as simple things, and you figured “we can open source this”. What level of “readyness” should a thing have before one invites others to play? Is there a difference between “I want to help make this” and “I want to use this”?

good questions :)

The inclusion of a library in bb (think httpkit vs clj-http) may become a consideration regarding the lib's usage outside of bb. In other words, our project favors httpkit and has moved off of clj-http just for uniformity's sake. Any positive or negative thoughts on babashka serving as a sort of "tastemaker" in this way?

I think bb is possibly the lowest entry set up for getting into clojure. I know you have covered this before, but starting from scratch to running program. One aspect that slightly confuses me about bb is the use of namespaces. I can run a 'script' without any name space but there are times when a namespace helps. Project setup s different if you use namespaces. Other aspect would be when you use bb in a bash script and when you use shell from within a bb script. Recently I tried to convert a bash script to bb and emulating things like grep and sed and awk where not that straight forward - thoughts. thanks.

@U4C3ZU6KX Thanks. I think what may confuse some people is that you need a classpath for bb to find namespaces on. By default the classpath is empty. But if you set it to . you can just use namespaced scripts in the current working directory. We can talk in another thread about this if you want.

I'd stress how easy it is to begin contributing to this language and it's ecosystem, and how welcome you're made to feel when you do it! In contrast most other languages out there

'Scaling borkdude' (to add on to teodorlu's points) would be another interesting one

🙂

If there's any meaningful update on Java on Truffle at this point and how that can broaden bb's use cases, would be interesting.. but I had a look at that project recently and it's hard to see where it's at

Finally on use cases, bb's stating use case is 'scripting' but I will often use it while developing a clojure/ mixed library. The instant repl startup and overall feeling on greater snappiness at the repl is compelling. So 'developing' is the key (secret) use case for me

'PRs welcome!' is a good summary of my first two points, and needs to be on the next bb t-shirt!

So many good decisions that went into making babashka such a joy to work with - well done @U04V15CAJ!

➕ on babashka.process and babashka.fs. First I thought Bash had the upper hand, processes and files are exactly what bash is made for. Now I come to prefer these two Clojure libraries with some Clojure glue / data transformation code.

@U3X7174KS The question of why bash is so widely used for scripting recently came up on the Future of Coding slack, and I think the answer might be helpful here: > There were better shells for writing scripts before bash , but they were generally regarded as less pleasant to use interactively (completions, forward/backward search, &c). Because most people spend more time composing little one-liners at the command line than writing scripts — an activity that favors those interactive features — bash became increasingly popular. Once people were used to using bash syntax for one-liners, they preferred to just keep using it in small scripts, despite its many shortcomings as a programming language. Ubiquity was ultimately driven by Linux making it the default shell, which had to do with GNU/licensing preferences.

One of the non-goals (explicitly mentioned from the start in the README) of bb is to replace existing shells like bash. It wants to replace the scripting language, not the shell.

Aaaah, that makes sense. Bash is indeed quite pleasant to use interactively. Thanks! I might have to join that slack.

The "I don't like the language but it's here anyway, so let's use it for more things" sounds a bit like JavaScript's history as well ;)

Bash is easy ("ready-at-hand") and I don't blame people for liking it. But also, with babashka we can code circles around bash people – like 2x, 10x faster, plus it takes longer to hit the complexity ceiling where you don't understand anything anymore

I still like bash, but you have to know when to stop

like, when hitting a (nested) if / else, I usually give up ;)

"should this be -z or -eq ..." those kinds of things I only remember by looking at past scripts..

I start all scripts with babashka now, even if bash is more familiar With bb, when I encounter a problem, I learn and understand; the next time I'll know what to do. In bash, on the other hand, I don't learn anything other than workarounds.

I think the places where I mostly still touch bash is in clj-kondos and babashka installer scripts

one other benefit that bb gives me in other projects is that those scripts run in all platforms including Windows

I think you could get bash to run on Windows (cygwin or so) but there's always some thing that's different

And even where bash runs on multi-platforms there can be confusing differences and incompatibilities in tooling. The fact that babashka can also remove these un-fun mysteries from scripting is another awesomeness.

You mention stack traces in that discussion, but note that stack traces in bb due to interpretation work quite different from JVM Clojure. Have you tested whether your bb workaround works as desired?

it works perfectly fine, just hoping to get back some performance

Well yeah in JVM Clojure you can't create custom exception types, so you have to write .java. This is not possible in bb. So I think there aren't many alternatives to your approach

farolero's main building block is the Signal, which is used extensively as a means of early exiting and control flow

What are you going to use farolero for, splint? Note that such libs may have impact on performance in bb as well

But if you don't care much about it and the script/project works quite fast, then it's all good. Just something to be aware of.

I thought I'd see how it works as I've been struggling/annoyed with error handling in Splint (as seen in your recent issue (that I need to publish the new release for oops))

Using more dependencies is also going to affect startup time. Keeping things more "vanilla" will work best for bb. In terms of errors that probably means: 1 Don't throw, but return exception values 2 Or embrace ex-data and just work with that

but at the end of the day it's just a matter of trying out

Yeah, i've played with farolero before but not for anything meaningful and this is a somewhat fresh codebase so using it is pretty easy

there's also slingshot which is quite popular

When creating a new project for Babashka using Cursive, which project type should I choose?

Yes :) https://www.etsy.com/listing/1241766068/babashka-clj-kondo-nbb-shirt

Done and done!

wonders if this should be his first tattoo

I take no responsibility for that :)

does clojure not default to „src“ only? Same default would be least surprising to me

clojure -T defaults to "." but other clojure invocations default to "src" -- the latter is based on the default :paths in the "root" deps.edn (inside tools.deps).

Yes, clojure defaults to src but I think most newcomers aren't even familiar with that and just expects scripts to work on the top level

planck for example has .:src as the default classpath maybe for this reason

or we could improve the error message when a namespace could not be found and the classpath is empty ;)

I think, for a scripting tool, I'd expect "." TBH. I think there's a potential for confusion if it was ".:src"...?

yeah, I think . would be a good choice, if the classpath is not specified otherwise.

but some people will read clojure tutorials and would expect src to work by default like with deps.edn

for #C029PTWD3HR I went with .:src from the start

Hmm, and another data point would be Joyride which has its scripts in scripts but pulls libraries from src by default... :thinking_face:

I think for someone like this, making their first steps with babashka: https://github.com/somecho/utility-scripts I think they would indeed be trying to require scripts from the local dir if they haven't read any further docs yet

So I'll start adding the local dir as the "fallback" classpath in one of the next releases

(https://github.com/babashka/babashka/issues/1555)

Hmm, one downside of adding . to the paths is that when creating an uberjar, it zips up the whole directory

Great! :) Some feedback on the README: it would help me get going faster if there was a

(require '[farolero.core :refer [handler-case signal]])

Good point! I'll get that in there.

While you're here, I was very explicit about using :farolero.core/blah throughout most of the readme, and only use ::far/blah later. Should I move to just using the alias as a part of adding that require with an :as far in it? Would that still be clear enough about them all being namespaced keywords in the farolero namespace?

yeah, I think alias is good. A rule I keep more or less for my own readme is that you should be able to copy paste the code in a REPL

@U04V15CAJ thanks to your suggestion I just went through and updated all the references to be easy to work with from a repl. Thanks a lot for the feedback!

@U02NJTR0718 stdout/err as string?

Yes

(process/sh "ls -la")

with shell:

(shell {:out :string :err :string :continue true} "ls -la")

with process:

@(process {:out :string :err :string} "ls -la")

they all make use of the same underlying code, but have different defaults. sh is the closest to what you asked

Thanks borkdude! Amazing to get a response from the source so fast :) "$" seems to work the same as well.

True:

@($ {:out :string :err :string} ls -la)