the top games were excellent this year! I think b/c the theme was interesting and expectation-reverseing. i struggled to get something on theme done... most of my ideas implied smart ai/behavior (e.g. interacting with an autonomous player character), which i decided was too big a rabbit hole for 2 days... it's impressive to see how far people got on some of these
russmatney
I'm interested! I've been curious about haxe recently, after seeing it was used to build Dead Cells and Papers, Please (and others: https://haxe.org/use-cases/games/)
A fun one!
In my experience, learning a new language makes you much better at the languages you already know, and each one you learn is an easier challenge than the last - it helps me understand what is shared across programming vs what is a specific style (or wart) in a language I already know. So I definitely recommend exploring widely!
In general, I'd encourage you to follow your gut and curiosity - whatever you're most interested in will end up being less effort/more fun, and likely the most/best growth for you - so, scratch that itch!
Some different options that you might take a look at:
My favorite by far is Clojure - it's practical and minimal and can be used for everything (full-stack + scripting), and interactive programming is really nice (vs the typical write + compile/run-the-world loop). Unfortunately, learning to read/write lisps is a bit mind-bending and tooling-intensive, so expect to invest time in your tools before you can really get going with it. (Connecting to a running repl from your editor is an excellent paradigm for writing code, but it's really on you to manage and debug the tools that support that workflow, and that's just difficult at the beginning.)
Elixir is another modern option that'll teach you some new patterns/paradigms, like the actor model (via OTP) and pattern matching. I'd be writing more elixir these days if I hadn't found Clojure :)
Haskell is totally different and quite difficult, but generally worth it. It's especially difficult to pickup without a mentor/team to learn it with. It can be very minimal and will change the way you think about functions and types (it did for me, anyway). I don't find it to be very practical (i've become quite opinionated about strict types), but I know folks who do. I wrote a post about using 'lenses' in Haskell a few years ago, a glance at some of the code will show you how different it is from other languages: https://medium.com/@russmatney/haskell-lens-operator-onboarding-a235481e8fac
Rust is increasingly popular, and for good reason - plenty to find on this, large community, definitely not bad choice at all from the sound of your path so far.
Nice. Classic rust reimplementation.
The simple and probably better answer is that you can just vim ~/.zsh_history
and search for/delete the lines directly.
Buuuuut! I wrote zsh command for doing exactly that a few years ago (in my dotfiles, but i've pasted it below as well):
################################################################################
# Delete from history via fzf
################################################################################
# https://superuser.com/questions/1316668/zsh-bash-delete-specific-lines-from-history
function delete-command () {
# Prevent the specified history line from being saved.
local HISTORY_IGNORE="${(b)$(fc -ln $1 $1)}"
# Write out the history to file, excluding lines that match `$HISTORY_IGNORE`.
fc -W
# Dispose of the current history and read the new history from file.
fc -p "$HISTFILE" "$HISTSIZE" "$SAVEHIST"
# TA-DA!
print "Deleted '$HISTORY_IGNORE' from history."
}
function pick_from_history () {
history | fzf --tac --tiebreak=index | perl -ne 'm/^\s*([0-9]+)/ and print "$1"'
}
function delete_from_history () {
delete-command "$(pick_from_history)"
}
It uses fzf
to filter and select a command to delete. It's cool but might be slow b/c you're doing it one at a time. It also may depend on your zsh config (i think the history
command i'm using there comes from ohmyzsh, but i'm not too sure).
Interesting, syncing history across machines is pretty cool. While writing this I went looking for my yabai logs helper as an example, but of course, it's on my other machine, haha
Security (sharing secrets from that history) comes to mind, so I feel compelled to mention that adding a space
before a command is a pattern for preventing it from being stored in history, though I think I had to opt-in to that in my zsh config: setopt HIST_IGNORE_SPACE
Feedback loops are super important! For momentum, for reducing burnout, for implementing/debugging, everything. I think of it mostly as a tooling problem - the point of maintaining and improving your tools is to maintain/improve your feedback loops.
For me it's about this question: How quickly and easily can you verify that the code is doing what you think it's doing?
This is what I love about writing Clojure - you can write and evaluate abritrary bits of code (functions, expressions) without leaving the editor. Invoke a keybinding to send the current expression to the running repl, and the resulting value is returned, and can be interactively explored/walked in the editor. It makes for a fun interactive dev-loop, and is a nice way to design a solution to some problem. (A caveat is that getting into a working repl is non-trivial, as it's dependent on your editor+plugins. It takes a bit of learning and unfortunately isn't beginner-friendly.)
Vim and emacs are also excellent for improving you feedback loops - both take some investment and some discomfort in the beginning, but ultimately you get out what you put in, and soon you can imagine and realize better workflows without much effort (adding your own functions, keybindings, hydras, etc). VSCode and other editors are also hackable, to some extent.
Mostly I think it's important to hack on your tooling on a regular basis, at least once a week or so.
My old boss used to say he expected us to keep 'sharp knives' (as in cooking). I think companies should make time for the devs to work on tooling to improve these feedback loops - it's the hiccups in the workflow that build up and lead to burnout/fatigue. Smooth workflows can actually be energizing instead of energy-draining!
Yes! I love using x (and xs) for functions over whatever the thing is (or things are).
Nice work!
Tauri is great. I haven't built a proper app with the nice native backend features, but i wrote a wrapper for passing a url on the command line, which lets you run an arbitrary web app like it's a native one: https://github.com/russmatney/clove
Very happy to have something lightweight!
every time i'm playing some old guilty pleasure that isn't 'actually good' (think: just wanted to play a jock jam for a moment), i worry about the influence on next week's discover weekly....
I think of this as interactive development, or repl-driven development. You can work this way today in Clojure (frontend, backend, and lately even for scripting via babashka), and with lisps in general - the syntax lends itself to sending expressions to the repl and returning values to your editor.
It’s really the best way (my favorite, at least) to program that i’ve found for exactly the reasons you mentioned - it’s excellent for debugging and ensuring the behavior of small functions with minimal overhead.
Types are frustrating because they lock things up and they don’t guarantee behavior, which is really all a program cares about. I feel similarly about unit tests… it’s extra code locking up your behaviors, so make sure they’re what you actually want! A general problem with types is that you have to commit to some shape early, which can lead to premature design and basically some arbitrary DSL when you just needed a couple functions/transformations. Feels like the problem of OO at times.
On the other side, the trouble (beyond people generally not wanting to read/learn lisps, which is unfortunate) is that repl-driven dev requires that you take care of your tools, which means there’s a tough learning curve and then some maintenance cost for whatever editor you want to use.
At a career-level scale, in my opinion, the investment is well worth it, but it’s a tough thing to figure out early in your career. I expect most devs with a couple years of js/python see types and feel like it’s a huge relief, which is real, and maybe types make sense at a certain team size…
I think people should spend time in several different languages and paradigms - it makes the ones you go back to make more sense :D