@Edward de Jong / Beads Project

Most of the time spent programming is fixing errors, and anything that helps reduce programmer error should be encouraged. What does it mean to multiply PI by "hello"?

That doesn't fit my experience in the slightest. Most of my time spent programming is figuring out the design of my system. The most time-costly class of "error" would be uncertainty about what exactly I want to build, which manifests as building something experimentally, playing with it, realizing it's not quite what I want, repeat. For instance, types can't help me decide if I want to implement my graphics library using SVG or WebGL. Sure I make errors — we all do — but I discover almost all of them almost immediately, and they're trivial to fix. Something like PI multiplied by "hello" isn't nearly as nefarious as "I misunderstood the linear algebra and now I'm getting weird looking results when I convert a rotation into a skew+scale", which I don't believe a typical type system can help with.

I think it’s fascinating that programmers have such different subjective experiences of what the task of programming is like. I suspect that at least some of them might correspond to objective differences in what their process is like, but I’m not sure.

I only use dynamic languages, I'm the only programmer on my team, and I largely get to pick my own projects. So... surely not typical, but when it comes to the things I build and the languages I use (mostly Rails and JavaScript these days), totally typical.

I curse when I spend several minutes tracking down a typo in JavaScript but I agree that I don't run into a PI + "hello" issue. Jonathan Blow mentioned that when he started his JAI language that memory safety was explicitly not a goal because it's not an issue he runs into often in his personal workflow. He believes he's pretty experienced and disciplined about that kind of stuff and doesn't want to have to jump through the hoops or give up the perf that most languages that try to make memory safety a priority end up adding to the experience. I can see both sides. I wish I didn't have to pick one.

No one is contradicting each other, we all want the system to help point out fundamentally wrong computations. Rails narrow the scope. You achieve safety through context and abstraction boundaries that are well understood and you can focus on the business problems were most of the challenge arises. Abstraction, composition and opt-in need to be as fluid with types as code or else there not worth the cost. Efforts like Lamdu, hackett and Hazel are exactly what we need to keep exploring. Describing them just as static type system is like referring to me and Brian Shaw as weight lifters, technically true, but not very helpful if you want to know how to pick in tug of war. 🙂

people who write in dynamic languages all the time develop muscle memory for the things that keep them safe. and there are also tools like linters that provide some degree of static safety. folks that program in static languages develop muscle memory for how to navigate the restrictions of the type system and how to extract meaningful info from type errors. i'm still biased towards static typing, especially as type systems continue to gain expressivity and ergonomics, but it's obviously true that dynamic language coders can produce reliable systems at scale

Yes, but there are also divides. I got my start with dynamic languages, but make a lot of errors that could be caught by a type system in them. Either I make more of them than other programmers, or I’m more annoyed by them.

that happens to me too, but i also have gotten very accustomed to the guarantees i get "for free" in static languages, so i dont have that muscle memory. scare quotes because there is a cost. it's very worth it to me, but clearly everyone doesn't feel that way. but maybe it's also i'm cognitively not as good as some people at enforcing dynamic typing discipline.

I think @Ivan Reese’s original statements ring true for "designing a system from scratch as a solo developer" (which does seem to be his experience). I think it flips once you have to interact with code that isn't in your own short-term memory; or change a previously-made decision. Strong types tell you immediately which pieces don't fit, which is a hard (sometimes intractable) problem if you don't have the entirety of the software in your head. I'll reiterate what I've said in another thread, which is that "labelling types" is a task that I think the machine should do, not the programmer. It's currently a burden on the programmer, because the compiler has basically no control over what text is appearing in the programmer's editor. A language (i.e. a visual one) where the editor and the compiler are the same software could plausibly take over this task and relieve the burden on the programmer.

while i agree, it's not always so simple. i've seen plenty of inscrutable statically typed codebases. the types can and do help, but they can also add a lot of noise and indirection, too.