• 1 Post
  • 29 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle












  • Our group did a two-part Microscope-like after a “season” of 14 sessions to wrap up a ton of loose ends and set up the next season. It was super satisfying to zoom in on only what the players wanted to see and resolve.

    Our first session of January is going to be another Microscope session too, we’ve got a giant pointcrawl to backtrack and see the fallout of our action or inaction.








  • It’s interesting, the results here are way different than the Code Golf & Coding Challenges Stack Exchange. I would never expect Haskell to be that low. But after looking at code.golf, I realize it’s because I/O on CG&CC is more relaxed. Most Haskell submissions are functions which return the solution.

    Sidenote: I like the CG&CC method, it’s semi-competitive, semi-cooperative.

    • all languages welcome
    • almost all users post “Try it Online”/“Attempt This Online” links
    • most users post explanations under their submissions
    • often people will post solutions beginning with “port of user1234’s excellent Foolang answer” when there’s a clever shortcut someone finds
    • or people will post their own solution with “here’s a solution which doesn’t use user1234’s algorithm
    • or people will add comments to answers with minor improvements

    IMO It’s geared towards what is the best part about code golf: teaching people about algorithm design and language design.


  • This has never stuck with me, and I hadn’t thought about why until now. I have two reasons why I will always write ${x}_$y.z instead of ${x}_${y}.z:

    • Syntax highlighting and shellcheck have always caught the cases I need to add braces to prevent $x_ being expanded as ${x_}.
    • I write a lot of Zsh. In Zsh, braces are optional in way more cases. "$#array[3]" actually prints the length of the third item in array, rather than (Bash:) the number of positional parameters, then the string 'array[3]'.