I’m going for zig and gerbil this year! Love AOC for learning new langs a day at a time :)

Dang, haven’t heard of this, looks pretty cool!

I’m going to try to use both zig and gerbil. Usually i use clojure, so might fallback to that as well. I started doing puzzles from 2015 this week, and that’s been fun so far

In fact i did not know that! Thanks for the vid, will check it out!

It was pointed out to me i should add OOP. Burn it all down!

I think you’re right re:oop - let’s throw that in there too.

One problem is naming things - bad names/naming conventions can start things off in a bad direction, so you spend forever figuring one out… but do you really need this thing you’re naming after all?

Maybe the hot-take is more like: All code is bad, so less code is better…. what should we drop first?

Sorry, I liked this hot-take setup and I’m shooting from the hip a bit. Maybe i actually mean objects/classes, not types? Can’t everything just be a bag of key-values, like in clojure?

I have been building mostly prototypes (games and wm-tools) for a year, so most of my context is getting things working to see if they are useful rather than locking them down.

I thought about my argument a bunch, and while i have alot of complaints, it all sounds like non-specific whining to me, so i’ve decided to give up.

types and unit-tests have their place. Fine! I admit it! i was pushing a hot-take I’ve had on a few occasions, and I’m glad to see this programming community is alive and well! If you need me I’ll be in my clojure repl.

Fair! Naming is hard, but maybe that’s no excuse for not defining a thing

I suppose i should at least caveat by saying i don’t by any means advocate for all dynamic langs over statically typed, and i agree types/unit tests are necessary for most languages. So please don’t make me write python over rust!

You can get the benefits of types/unit-tests via static analysis on a per-function basis with clojure and a library like malli, and for me that hits a minimalist sweet-spot.

Very happy to share this hot-take :) Definitely code-base and team-size are a huge factor, and I mostly work on my own projects, so each project is very different. still, I expect to get downvoted into oblivion by the last decade's influx of typey-langs and -devs.

I think most love for types is folks being happy they don't need to assert on the input to every function, i.e. static analysis and reduced unit-tests. It's hard for me to not see types as asking folks to pre-design their entire system (by defining types first!), before you've even started writing a few functions, which are actually what the system should codify (behaviors, integration tests). It's also frustrating b/c types don't guarantee that the system does-the-thing, only that the type-system and compiler are happy, so it's like pleasing the wrong boss, or some metaphor like that.

I like to work with behavior directly in functions, which should be the same regardless of the type passed in. Unfortunately most dynamic languages have their flaws (js,python,etc), so this kind of opinion suffers b/c of those languages... similar to type-favoring opinions suffering b/c of langs like typescript.

Nil-punning makes me very happy - that's a hill I will actually die on. Almost every project i've worked on, there's no reason to go out of the way to specifically handle every case of not the right input or oh-no-it's-null! Whenever you have null, you just return null from this function too, and guess what, everything's fine - no need to crash and blow up b/c one thing wasn't there. Mostly this is a complaint about things completely crashing for no reason, rather than being incomplete (i.e. some data missing) but still working for the user.

Anyway, lots of different use-cases, and use the right tool for the job, etc etc. types and unit tests are useful for some things.

100%! It was mind-blowing to realize lisps are actually syntactically simpler than all the non-lisps so popular today

Takes a bit of love from editor standpoint unfortunately, so most devs will just never attempt that hurdle

Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.

Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.

Just to share a perspective from erlang/elixir: pattern matching to filter for only happy-path inputs and the principle of “letting it fail” (when the inputs don’t match the expected shape) works really well in some paradigms (in this case, the actor model + OTP, erlang’s 9 9s of uptime, etc). In that kind of architecture you can really only care about the happy path, because the rest is malformed and can be thrown away without issue.

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