Oh damn I'm jealous 🙃

Kraftwerk are great

I still have tickets to see kraftwerk, for a show that was originally scheduled for march 2020 😅 It got postponed several times for obvious reasons, but maybe this year it will actually take place!

that's exciting i hope it comes together splendidly

Ok, this post is amazingly based on personal opinion instead of anything... > Perl offers a very straight-forward code flow, and Perl code offers simplicity and control Does it? The "if error resume next" that's default to perl, the weird @{$board->{thing}} I had to make on my tic-tac-toe example, the implicit $_ and functions not receiving params and instead having to use shift to keep "feeding" params when called beg to differ. The regex operator sets global variables for capture groups, and there's no way to have any "functional approach" to it. > Perl emphasizes the get what you want the way you want philosophy. What exactly does this means? Then, the article boils down to a lot of cherry-picked examples of Perl vs other languages, some fair, some not, and some incredibly incorrect and wrong in more ways than one...

My personal opinion, being a frequent writer of ~1000-line Perl and Python programs, but not being an expert in either language, is that Python is a more readable Perl, with very similar performance and target use cases.

whichever is easier to copy from the readme!

What’s your intuition? What is your concern?

Preamble: I think if I use a coordinate, then the coordinate should give some sort of context other than making my import longer to type. I'd expect to find a 404 page at http://foo.github.com and the project's wiki/blog page at http://foo.github.io. On the other hand, I'd expect to find the source code at http://github.com/borkdude/foo, so I think both not terribly helpfuul. So it's a 🤷 for me.

I prefer the latter because it maps to the web page you can publish from the project (which maybe is the seed of an ownership verification scheme)

Are both links going to github?

Yes

I started out using com.github.* but have used io.github.* for new libraries. Purely coincidentally, my com.github.* libs are published on Clojars and my io.github.* libs are git-only 🙂 I would use io.github.* going forward for any new libs. I think at the time I started using com.github.*, GitHub pages were still being published to but that stopped being true at some point (and now they're only on *.)?

That's correct re pages

I feel like the most common mistake when asking for help on clojurians slack is writing questions like "what's the best way to do X?" without providing any context. I wonder if it would be useful to have a suggested format for asking questions in #beginners. This is just off the top of my head so I'm sure it could be improved, but maybe something like: > What are the options for doing X? > > The reason I'm trying to do X is to solve problem Y. <extra context here>. > > So far, I've tried U, V, and W, but it's not working for Z reasons.

Yeah, I've also noticed that a few times. I want to help, I just ... well, I don't have any idea where to start. There are no assumptions or questions I can answer in a reasonable timeframe. I like Eric Raymond's guide to asking questions: http://www.catb.org/~esr/faqs/smart-questions.html

You mentioned that being patient for them to reply on their schedule which is great. I would also add: When you do get a response, drop whatever you're doing to check their response in case either of you have follow up questions.

Interrupting your own workflow to engage with their help is going to be much more efficient and is way to respect their time.

I would also add a suggestion to say thanks and follow up with how it turned out. If someone offered you advice, thank them and let them know whether or not it worked.

> I would also add a suggestion to say thanks and follow up with how it turned out. I commented a bit on that here: > [...] Then demonstrate that you’ve taken their advice to heart before you ask again. Next time you need help, first share how you benefited last time. You’re grateful, after all! Show them that the time invested in you was well spent. Then ask for something else that they can easily give you. I guess I kind of imply that the question asker should wait until the next interaction to say thanks, or even reply. Which wasn't really the intention.

Everyone's writing style is different, but I think adding short headers might make your points a little punchier. It also makes the post easier to scan. For example: > Make it Easy > I choose to assume that people are fundamentally good. People do want to help you. They just have an infinite number of other things they could do too. Experts in particular. They can choose to help you. Or help someone else, advance their field, or spend time with friends and family. > > Respect their time > Therefore, respect their time. Don’t chat to make the time pass. Make it exceptionally easy to help you. Where are you stuck? How can they help you? How can you minimize the amount of time required to get you unstuck? > > Be Patient > Do that. Make sure they can reply to you on their own schedule, when they have time. Don’t assume this is the regular easy-going conversation you prefer with your friends. If the relationship turns casual, sure, welcome that. But don’t require that. Make casual interaction an option they can choose to take. > > Say Thanks > By making it exceptionally easy to help you, you maximize your chance to get an initial reply. Then demonstrate that you’ve taken their advice to heart before you ask again. Next time you need help, first share how you benefited last time. You’re grateful, after all! Show them that the time invested in you was well spent. Then ask for something else that they can easily give you.

@U7RJTCH6J I took a stab at rewriting the "say thanks section". Old: > By making it exceptionally easy to help you, you maximize your chance to get an initial reply. Then demonstrate that you’ve taken their advice to heart before you ask again. Next time you need help, first share how you benefited last time. You’re grateful, after all! Show them that the time invested in you was well spent. Then ask for something else that they can easily give you. > > Repeat, and you might gain a mentor. New: > By making it exceptionally easy to help you, you maximize your chance to get an initial reply. Did their advice work? Were you able to solve your problem? Let them know! This is likely not the first time they’ve helped someone. By sharing how you benefited from their feedback you are helping them become better mentors. Show them that the time invested in you was well spent. Then ask for something else that they can give you easily. > > Repeat, and you might gain a mentor. Does that address what you meant? Pushing out the change now.

Really appreciating your feedback, by the way 😄

https://clojurians.slack.com/archives/C03RZGPG3/p1657747379969359?thread_ts=1657744863.222139&cid=C03RZGPG3 I agree that more stucture would make the text more easily digestible. Though with headings "make it easy", "respect their time", "be patient" and "say thanks" I feel like I'm taking the imperative stance of "this is me telling you how to interact with others". Or "here's how you ask questions online". Which is a bit more in the direction of "Do these four things to get AWESOME FREE help online" than I'd prefer. With the sub headings "make it easy", "respect their time", "be patient" and "say thanks", a toplevel heading of "Interaction value differential" wouldn't really be right. :thinking_face:

Yea, makes sense. The example headers I used are very peppy and buzzfeedy.

Although, if you wanted to add a cute cat picture to accentuate each paragraph... 😛

I think one of the principles of good communication (which includes asking for and giving help) is cognitive empathy, that is, being aware of what the other person knows and (crucially) doesn't know. Of course gratitude and politeness should be the other aspects needed for any satisfactory interaction.

Agreed! > being aware of what the other person knows and (crucially) doesn't know I'd also add being aware of the other person's motivation. What are they interested in? What do they like?