5 ms·

Lack of proper types is what killed the joy of programming in Elixir for me (I lasted 6 months, hoping I would somehow adapt, but the experience was so miserabl

by wofo 3y ago

Lack of proper types is what killed the joy of programming in Elixir for me (I lasted 6 months, hoping I would somehow adapt, but the experience was so miserable that I decided to move on). I simply can't understand how anyone can be productive in a big codebase without the rigor of static typing, but those people exist, so I guess there must be something about our brains that divides us in the dynamic vs static typing camps.

josephg 3y ago
I’ve swapped back and forth between static and dynamic types a few times in my career. Java and C/C++ to JavaScript (and coffeescript) to typescript and rust. The entire time (30 years at this point) I’ve felt like whatever I was doing at the time was obviously the one true way to program. I feel that now - that what I’ve been doing lately (static typing) is clearly superior. Even for throwaway JavaScript based projects at the moment the first thing I do is install typescript. I’m spitballing on the reason - I don’t know why it’s like this. But maybe it’s because static typing encourages you to write & plan your types first. When you know the data types, all the functions kind of flow around your types and everything feels like it obviously flows from that. With dynamic typing, it’s the reverse. I find myself writing my functions first (top down or bottom up) and then backfilling what arguments and data everything needs to pass around. I run my code a lot more as I develop it to stop bugs creeping in. And because I can run my code at any time. There’s no type checker stopping me from trying things out.
- IggleSniggle 3y ago
  I've recently found a great middle ground for this, using esbuild to drive code as I'm writing it, while my IDE may meanwhile be complaining that all my types are broken. Getting comfortable having "broken" types while something is still in development is a nice middle ground, helping you come back to the hot spots whenever you're ready, and acting as a forcing function prior to commit or push.
ra 3y ago
> I guess there must be something about our brains that divides us in the dynamic vs static typing camps. I've wondered if that's a thing. It seems to be.
d3ckard 3y ago
I believe this as well. I like dynamic typing, because it often feels to me that rigour of static typing is slowing the prototyping phase. Plus overusing types creates a lot of boilerplate. In one of the frontends I've seen adding a boolean field to a form required changing over 10 files - thank you Typescript. On the other hand, sometimes I feel like it has a lot to do with test writing. I feel people enjoy static typing, because you can get a feedback loop catching certain things without writing any tests. If you do write tests, all the type errors get caught pretty immediately anyway, so I just don't see the benefit. Personally, the biggest advantage of dynamic typing for me is the ability to skip formalities for a time. If I want a function that can modify any struct with field "val" in (by, let's say, setting it to zero), I can - and I don't have to do multiple definitions, I don't have to define an interface. Just a function and I am done. If I want to skip error handling for now and only code the happy path, I can - and my program will work (and crash on error, but in some cases it's ok). As the projects get more complex and require higher safety guarantees, static typing helps in ensuring nothing got broken - but nothing beats dynamic typing for prototyping.
- spion 3y ago
  The example is, interestingly possible in TypeScript, at a very cheap cost function modifiesValField(struct: {val: number}) { struct.val = 0; } Structural types and inline interfaces (or as I like to call them inyourfaces) are pretty cool. But I do get your point - although type systems have gotten much less annoying, its not like they're perfect.
- mejutoco 3y ago
  I mostly agree with you. Just wanted to add that in some languages, for example in Typescript, there are ways to say that you do not care about the type for prototyping. For example using :unknown or :any.
  - IggleSniggle 3y ago
    :unknown is great, but the problems come in the middle area; when you have lots of very tight types and are prototyping something that makes use of those things, :unknown doesn't work, and :any can be too expressive, even for your prototype.
spion 3y ago
I've been on both camps, so I'm hoping I can give some insight. Lots of statically typed languages are very strict about their types and have too many of them. You have to admit, when you're trying to build something difficult and focus on getting the business logic part of your program right, the last thing you want to be thinking about is e.g. whether you need a String, ByteString, LazyByteString or any of the other types of strings, and which library decided to accept which one. At some level its definitely useful to distinguish between those, and I'm sure a lot of libraries make sensible choices. But initially in the development of the program its just unnecessary busywork that distracts you from the important bits. In the past, typed languages also made it a bit harder than necessary to create new types, especially in situations where you have serialization and deserialization. And finally, we had to do all this work, and for what? To be unable to prevent the most basic of errors i.e. NullPointerException? You have to admit, it was a hard sell. A lot of things have changed, however. TypeScript makes it really easy to define types, anywhere - inline on the function in the argument, or right above it. You can pretend the type is correct at deserialization time, or you can use libraries like `zod` to both define a validator and a type in the same syntax - its up to you. Rust similarly has powerful and easy to use tools like serde - structs and enums are easy to define, and easy to attach metadata to them quickly to (de)serialize them accurately. Huge differences from the old world of getters and setters and NPEs. When using dynamic languages, there are techniques to make things easier. There is the often mentioned testing, which does help verify a large subset of code paths. Lesser known and more subtle technique is coming up with and following a strict naming convention for properties, for example, and to keep things as consistent as you can in general. This is why you often see so much focus in code reviews about conventions, linting and so on. Nowadays I guess it mostly depends on how good your dynamic language techniques (at the team level) are, as well as what your treshold for type system annoyances is. There are still some annoyances even in the best type systems, but its gotten way, way better.
- akkad33 3y ago
  > you need a String, ByteString, LazyByteString or any of the other types of strings, Out of curiosity, which language do you use where this kind of decision has to be made for daily programming problems?
toolz 3y ago
I'm firmly in the camp that it's all perception. The studies I've seen aren't what I would consider conclusive, but they certainly suggest there is very little difference in the output and bugs of dynamic vs static languages. In my experience, static typing seemed to lend itself to poor testing, maybe some sort of belief that static types were good enough to not need tests that can prevent regressions. So from my point of view the static typing is negative value. It prevents such a low value class of bugs while seemingly incentivizing people to be lax with the most important classes of bugs.
- aerhardt 3y ago
  I literally struggle to read and work with dynamic code. My head explodes when trying to hold return types or the shape of semi-complex data structures in my head, versus having it spelled out. I wouldn't call it an issue of "perception", I really think in my case it's "capability", pure and simple. I've programmed for thousands of hours in both styles, so we're well past the possibility of this being an adaptation problem. I am totally convinced that the advocates of dynamic programming are right, too, just possibly built differently. For example, if I had an order of magnitude more working memory than I have as an individual (I'm assuming that's neurologically plausible), maybe I'd view dynamic programming differently, too.
  - MatthiasPortzel 3y ago
    I’m a proponent of dynamic typing. I’d say the same thing. I don’t have enough working memory in my head to store the compile-time type information about every relevant variable, in addition to the actually important information about what the runtime data could be. The way that I write static-typed code is by imagining how I would write dynamic code to solve the problem, and then additionally imagining what types and type constraints I need to add. I honestly think it’s a kind of an instance of Paul Graham’s Blub Paradox. I know JavaScript and I spent years writing JavaScript. So if you ask me to write TypeScript, well, I write the JavaScript that I want to write and then go back and add types to make the typescript compiler happy. There are a bunch of other things I could talk about. I should write a post.
solidninja 3y ago
Nice to see that I'm not the only one - lasted 9 months trying to adapt to Elixir and couldn't. My background is Scala/Rust with heavy use of effect systems and reliance on writing the types out and then solving the puzzle of how to make everything fit. The tooling is pretty poor due to lack of investment compared to some of the other languages, and the debugging story is not great either. But hey, it works for some.
- lemper 3y ago
  same here, mate. though mine is haskell. I'd rather waiting for gleam to mature enough to mess around with it than to be miserable with the dynamics of the data. I just don't like to guess stuff down the line.
- minton 3y ago
  I found the tooling to be quite nice. In my opinion, it’s better or equivalent to most popular languages (python, ruby). It’s definitely not full-on bumper rails/training wheels like a Microsoft IDE, but it’s obvious they’ve invested heavily in tooling early on.
aerhardt 3y ago
My best programming experience ever has been in OCaml and I love the idea of Elixir, but I can't even bring myself to try it because I know I'm not going to enjoy not having types. Even something as allegedly shitty as Python's type system would do it for me. I'm aware that there are ongoing projects to add typing to Elixir and I'll keep watching out how they evolve.
swader999 3y ago
The only way I've seen it work (rarely) long term is with extensive unit tests and that takes incredible discipline.

by wofo 3y ago

josephg 3y ago

I’ve swapped back and forth between static and dynamic types a few times in my career. Java and C/C++ to JavaScript (and coffeescript) to typescript and rust. The entire time (30 years at this point) I’ve felt like whatever I was doing at the time was obviously the one true way to program. I feel that now - that what I’ve been doing lately (static typing) is clearly superior. Even for throwaway JavaScript based projects at the moment the first thing I do is install typescript. I’m spitballing on the reason - I don’t know why it’s like this. But maybe it’s because static typing encourages you to write & plan your types first. When you know the data types, all the functions kind of flow around your types and everything feels like it obviously flows from that. With dynamic typing, it’s the reverse. I find myself writing my functions first (top down or bottom up) and then backfilling what arguments and data everything needs to pass around. I run my code a lot more as I develop it to stop bugs creeping in. And because I can run my code at any time. There’s no type checker stopping me from trying things out.

IggleSniggle 3y ago
I've recently found a great middle ground for this, using esbuild to drive code as I'm writing it, while my IDE may meanwhile be complaining that all my types are broken. Getting comfortable having "broken" types while something is still in development is a nice middle ground, helping you come back to the hot spots whenever you're ready, and acting as a forcing function prior to commit or push.

ra 3y ago

> I guess there must be something about our brains that divides us in the dynamic vs static typing camps. I've wondered if that's a thing. It seems to be.

d3ckard 3y ago

I believe this as well. I like dynamic typing, because it often feels to me that rigour of static typing is slowing the prototyping phase. Plus overusing types creates a lot of boilerplate. In one of the frontends I've seen adding a boolean field to a form required changing over 10 files - thank you Typescript. On the other hand, sometimes I feel like it has a lot to do with test writing. I feel people enjoy static typing, because you can get a feedback loop catching certain things without writing any tests. If you do write tests, all the type errors get caught pretty immediately anyway, so I just don't see the benefit. Personally, the biggest advantage of dynamic typing for me is the ability to skip formalities for a time. If I want a function that can modify any struct with field "val" in (by, let's say, setting it to zero), I can - and I don't have to do multiple definitions, I don't have to define an interface. Just a function and I am done. If I want to skip error handling for now and only code the happy path, I can - and my program will work (and crash on error, but in some cases it's ok). As the projects get more complex and require higher safety guarantees, static typing helps in ensuring nothing got broken - but nothing beats dynamic typing for prototyping.

spion 3y ago
The example is, interestingly possible in TypeScript, at a very cheap cost function modifiesValField(struct: {val: number}) { struct.val = 0; } Structural types and inline interfaces (or as I like to call them inyourfaces) are pretty cool. But I do get your point - although type systems have gotten much less annoying, its not like they're perfect.
mejutoco 3y ago
I mostly agree with you. Just wanted to add that in some languages, for example in Typescript, there are ways to say that you do not care about the type for prototyping. For example using :unknown or :any.
- IggleSniggle 3y ago
  :unknown is great, but the problems come in the middle area; when you have lots of very tight types and are prototyping something that makes use of those things, :unknown doesn't work, and :any can be too expressive, even for your prototype.

spion 3y ago

I've been on both camps, so I'm hoping I can give some insight. Lots of statically typed languages are very strict about their types and have too many of them. You have to admit, when you're trying to build something difficult and focus on getting the business logic part of your program right, the last thing you want to be thinking about is e.g. whether you need a String, ByteString, LazyByteString or any of the other types of strings, and which library decided to accept which one. At some level its definitely useful to distinguish between those, and I'm sure a lot of libraries make sensible choices. But initially in the development of the program its just unnecessary busywork that distracts you from the important bits. In the past, typed languages also made it a bit harder than necessary to create new types, especially in situations where you have serialization and deserialization. And finally, we had to do all this work, and for what? To be unable to prevent the most basic of errors i.e. NullPointerException? You have to admit, it was a hard sell. A lot of things have changed, however. TypeScript makes it really easy to define types, anywhere - inline on the function in the argument, or right above it. You can pretend the type is correct at deserialization time, or you can use libraries like `zod` to both define a validator and a type in the same syntax - its up to you. Rust similarly has powerful and easy to use tools like serde - structs and enums are easy to define, and easy to attach metadata to them quickly to (de)serialize them accurately. Huge differences from the old world of getters and setters and NPEs. When using dynamic languages, there are techniques to make things easier. There is the often mentioned testing, which does help verify a large subset of code paths. Lesser known and more subtle technique is coming up with and following a strict naming convention for properties, for example, and to keep things as consistent as you can in general. This is why you often see so much focus in code reviews about conventions, linting and so on. Nowadays I guess it mostly depends on how good your dynamic language techniques (at the team level) are, as well as what your treshold for type system annoyances is. There are still some annoyances even in the best type systems, but its gotten way, way better.

akkad33 3y ago
> you need a String, ByteString, LazyByteString or any of the other types of strings, Out of curiosity, which language do you use where this kind of decision has to be made for daily programming problems?

toolz 3y ago

I'm firmly in the camp that it's all perception. The studies I've seen aren't what I would consider conclusive, but they certainly suggest there is very little difference in the output and bugs of dynamic vs static languages. In my experience, static typing seemed to lend itself to poor testing, maybe some sort of belief that static types were good enough to not need tests that can prevent regressions. So from my point of view the static typing is negative value. It prevents such a low value class of bugs while seemingly incentivizing people to be lax with the most important classes of bugs.

aerhardt 3y ago
I literally struggle to read and work with dynamic code. My head explodes when trying to hold return types or the shape of semi-complex data structures in my head, versus having it spelled out. I wouldn't call it an issue of "perception", I really think in my case it's "capability", pure and simple. I've programmed for thousands of hours in both styles, so we're well past the possibility of this being an adaptation problem. I am totally convinced that the advocates of dynamic programming are right, too, just possibly built differently. For example, if I had an order of magnitude more working memory than I have as an individual (I'm assuming that's neurologically plausible), maybe I'd view dynamic programming differently, too.
- MatthiasPortzel 3y ago
  I’m a proponent of dynamic typing. I’d say the same thing. I don’t have enough working memory in my head to store the compile-time type information about every relevant variable, in addition to the actually important information about what the runtime data could be. The way that I write static-typed code is by imagining how I would write dynamic code to solve the problem, and then additionally imagining what types and type constraints I need to add. I honestly think it’s a kind of an instance of Paul Graham’s Blub Paradox. I know JavaScript and I spent years writing JavaScript. So if you ask me to write TypeScript, well, I write the JavaScript that I want to write and then go back and add types to make the typescript compiler happy. There are a bunch of other things I could talk about. I should write a post.

solidninja 3y ago

Nice to see that I'm not the only one - lasted 9 months trying to adapt to Elixir and couldn't. My background is Scala/Rust with heavy use of effect systems and reliance on writing the types out and then solving the puzzle of how to make everything fit. The tooling is pretty poor due to lack of investment compared to some of the other languages, and the debugging story is not great either. But hey, it works for some.

lemper 3y ago
same here, mate. though mine is haskell. I'd rather waiting for gleam to mature enough to mess around with it than to be miserable with the dynamics of the data. I just don't like to guess stuff down the line.
minton 3y ago
I found the tooling to be quite nice. In my opinion, it’s better or equivalent to most popular languages (python, ruby). It’s definitely not full-on bumper rails/training wheels like a Microsoft IDE, but it’s obvious they’ve invested heavily in tooling early on.

aerhardt 3y ago

My best programming experience ever has been in OCaml and I love the idea of Elixir, but I can't even bring myself to try it because I know I'm not going to enjoy not having types. Even something as allegedly shitty as Python's type system would do it for me. I'm aware that there are ongoing projects to add typing to Elixir and I'll keep watching out how they evolve.

swader999 3y ago

The only way I've seen it work (rarely) long term is with extensive unit tests and that takes incredible discipline.