6 ms·

My Blub language has been PHP. While the language has been getting better over the years, especially with the introduction of types, I still felt at one point t

My Blub language has been PHP. While the language has been getting better over the years, especially with the introduction of types, I still felt at one point that I wasn't growing. I had a try at Haskell, and failed miserably. I tried OCaml, but still something felt unnatural to me, although what really intrigued me was the sound type system and the guarantee that if it compiles, then it's probably going to run well. I then tried Elixir, and I love it. I think Elixir is a wonderful transition language, but something that I wouldn't mind keeping close in my toolstack. The Actor model, immutability, pattern matching, meta programming, these are all concepts that uppended my way of thinking. PHP/JavaScript array sort functions feel so weird to me now for doing the sorting directly on the variable. But to be honest, I wish Elixir had types. I don't trust myself writing functions that can return different things.

eru 6y ago
Erlang has some type annotations. Not sure whether they made it over to Elixir?
- ghayes 6y ago
  Dialyzer is fully integrated into Elixir, yes. But again, it’s optional typing.
  - innocentoldguy 6y ago
    I know how to use Dialyzer and am quite proficient with it. I cannot say, however, that it helps me in any way. I think strong typing is a crutch for bad programmers and I've yet to encounter anything in my 30+ years of programming to change my mind.
    - eru 6y ago
      There's two sides to it: First, there's only so much I can hold in my brain at once. If the computer can do some of the tedious busy work, let it. Second, the first perspective talks about catching errors and oversights. A sufficiently non-bad programmer could make do without. But static typing also allows for some programming techniques that wouldn't work without. As a silly example, Haskell makes heavy use of overloading-by-return-type. You just don't the information about what return-type is expected available dynamically, it needs to be static. There's also lots of optimizations that are safe only when the compiler knows more about your code. (Of course, a sufficiently non-bad programmer could write directly in the machine language of every processor she's writing code for..) In practice, typing helps me a lot with eg exhaustiveness checking for my pattern matches. The type system that dialyzer exposes is pretty weak. So not a good standard to measure all of typing against.
    - technion 6y ago
      Dialyzer solves certain problems for me that still exist in many "typed" languages. A great example is pos_integer(). In something like Typescript I can use "number", but that doesn't assert I can't receive a negative number, or a zero.
      - eru 6y ago
        In general, you'd need something like dependent types for solving this properly. Like eg Agda has.
        wwright 6y ago
        Ada has this without general dependent types AFAIK
        mcguire 6y ago
        Yes and no. The definitions are in the type system, but the checks are done at runtime, just like you would do manually. You don't really get the benefit of typing. The reason I can say that: you don't have to provide proofs that a value has to be positive to get things to compile.
        eru 6y ago
        Checks at runtime are also a good idea, but yes, very different from static dependent types. There's some interesting work on making such contracts work well in a lazy language with higher-order functions.
    - Smaug123 6y ago
      Strong typing can be a crutch for bad programmers in the same way that a prosthetic leg can be a crutch for an amputee. The world record 100m men's sprint for double-leg-below-the-knee amputees is now frozen at 10.57s (record set in 2013); omitting Usain Bolt who is clearly freakishly good even among world-class sprinters, the 100m world record is 9.74s. I am very happy to use strong static type systems.
    - pdpi 6y ago
      There are type systems out there that allow you to model more than "is a string, is a float, is an int". There are CVEs for use-after-free bugs in Firefox, IE, the Linux kernel and more. Rust's type system helps prevent those. There are CVEs for double-free bugs in OpenSSH, OpenSSL, and Kerberos. Again, Rust's type system helps prevent those. There are CVEs for null dereferencing in the Linux kernel, CUPS, and OpenSSL. Many languages have type systems that help preventing those. There's many more classes of bugs that can be prevented by judicious use of robust type systems. Dismissing strong, static typing as "a crutch for bad programmers" is just plain wrong. All of this, of course, assumes the only use for static types is preventing issues. Algebraic data types actually allow you to write simpler, more concise code in languages that support them. Typeclasses make for a whole model of polymorphism that's just incredibly painful to implement in languages that don't support them.
      - AnimalMuppet 6y ago
        > Dismissing strong, static typing as "a crutch for bad programmers" is just plain wrong. No, it's correct. The problem is that innocentoldguy doesn't realize that he is a bad programmer. (That's not an attack on him - we all are bad programmers.) So here we are, bad programmers. Here's this crutch - or, less negatively put, here's a tool that can help. Maybe we can be somewhat better bad programmers if we use it.
        pdpi 6y ago
        I get your point, but if we're all bad then "bad" loses its meaning. I'm definitely a better programmer than many of my peers, and worse than a whole bunch of others.
        AnimalMuppet 6y ago
        We're bad, not in comparison with each other, but in comparison to the external standard of "good enough that we don't need a crutch". In fact, if you want to be a better (less bad) programmer, learn to use the available crutches more effectively.
    - pdimitar 6y ago
      That depends on what kind of software you have worked on. I also got quite far with dynamic languages in the last 10 years but at one point the static strong typing helps you a lot in making invalid state impossible at compile time. Growing complexity kind of mandates a static strong typing at one point. Sure, complexity can be managed and reduced -- and distributed among smaller projects (i.e. splitting big projects) -- but even that has a limit.
  - pdimitar 6y ago
    Dialyzer also takes a while to get used to and for several teams I've been in the initial cost of learning turned out to not outweigh the theoretical savings won by it. There are other more modern libraries that defer the errors to runtime but also make them much more clear (like `norm`). Libraries like `boundaries` can also help you enforce, a-hem, boundaries in your code and making sure that you write less spaghetti code. I personally stick to Dialyzer in personal projects but it's an uphill battle to constantly keep it happy while OCaml / Rust / Haskell will just immediately yell at you with a well-described error (well, Rust anyway, the other two can be vague sometimes).
- pdimitar 6y ago
  Yep, there's `dialyxir` which is a very heroic wrapper effort to translate Dialyzer's messages to something more readable and manageable. Even with that though sometimes you get real head scratchers no matter which of both you use.
rkangel 6y ago
I personally believe that Elixir is an excellent 'gateway' functional programming language because it is dynamically typed. Learning OCaml and especially Haskell (I've done some of both) requires understanding a complex type system and learning how to encode what you want in it. On top of that you have to learn to code in the 'functional' way - representing your data, pure code, recursion (or reduces), higher order functions etc. When you write Elixir you eliminate most of the type system stuff, and you just have to learn to code in a functional way. There is surprisingly little 'language' to learn - functions, tuples, lists, maps, modules and that's about it. There is then the OTP (processes and supervisors) side of it, but that's separate (and if you're writing a web backend in Phoenix, mostly ignorable). We're just (hopefully) wrapping up a 9 month project with a team of about 8, none of which had written much Elixir before the start (a background of mostly C). It has been a very smooth process, and definitely the right choice of language.
- pdimitar 6y ago
  I sorely lack Elixir's easy entry experience while I am getting better and better at Rust. :( And I'll look for ways to use it at my $dayjob. Rust is an excellent language but I feel that for some pieces of our stack Rust is kind of a bazooka in a scenario where a 9mm pistol would do.
  - rkangel 6y ago
    I could see an argument where Rust is performant and low level enough that you can use it at the bottom of the stack, and has good enough abstractions that it's productive to use higher in the stack. There are certainly benefits to using one language for everything, but this logic reasoning relies on you having a team that is very familiar with it, and having your bits of tooling and libraries worked out for your setup.
    - pdimitar 6y ago
      Yep, exactly. Lower-level languages however also give you much more foot-guns. These days my ideal app is written in Elixir for almost everything due to the insane parallelisation and fault-tolerance that it offers (and the copy semantics that make shared memory bugs impossible) with Rust sprinkled at the critically important-to-be-fast places -- like working with sqlite3 for example. All of that could be achieved with Rust or any other language really. But it requires tons of tooling, CI/CD jobs, Git hooks, static analyzers, linters, formatters etc. And a good chunk of all that doesn't even exist for many languages. So I prefer to make my own blend that has the important advantages at the right places.

eru 6y ago

Erlang has some type annotations. Not sure whether they made it over to Elixir?

ghayes 6y ago
Dialyzer is fully integrated into Elixir, yes. But again, it’s optional typing.
- innocentoldguy 6y ago
  I know how to use Dialyzer and am quite proficient with it. I cannot say, however, that it helps me in any way. I think strong typing is a crutch for bad programmers and I've yet to encounter anything in my 30+ years of programming to change my mind.
  - eru 6y ago
    There's two sides to it: First, there's only so much I can hold in my brain at once. If the computer can do some of the tedious busy work, let it. Second, the first perspective talks about catching errors and oversights. A sufficiently non-bad programmer could make do without. But static typing also allows for some programming techniques that wouldn't work without. As a silly example, Haskell makes heavy use of overloading-by-return-type. You just don't the information about what return-type is expected available dynamically, it needs to be static. There's also lots of optimizations that are safe only when the compiler knows more about your code. (Of course, a sufficiently non-bad programmer could write directly in the machine language of every processor she's writing code for..) In practice, typing helps me a lot with eg exhaustiveness checking for my pattern matches. The type system that dialyzer exposes is pretty weak. So not a good standard to measure all of typing against.
  - technion 6y ago
    Dialyzer solves certain problems for me that still exist in many "typed" languages. A great example is pos_integer(). In something like Typescript I can use "number", but that doesn't assert I can't receive a negative number, or a zero.
    - eru 6y ago
      In general, you'd need something like dependent types for solving this properly. Like eg Agda has.
      - wwright 6y ago
        Ada has this without general dependent types AFAIK
        mcguire 6y ago
        Yes and no. The definitions are in the type system, but the checks are done at runtime, just like you would do manually. You don't really get the benefit of typing. The reason I can say that: you don't have to provide proofs that a value has to be positive to get things to compile.
        eru 6y ago
        Checks at runtime are also a good idea, but yes, very different from static dependent types. There's some interesting work on making such contracts work well in a lazy language with higher-order functions.
  - Smaug123 6y ago
    Strong typing can be a crutch for bad programmers in the same way that a prosthetic leg can be a crutch for an amputee. The world record 100m men's sprint for double-leg-below-the-knee amputees is now frozen at 10.57s (record set in 2013); omitting Usain Bolt who is clearly freakishly good even among world-class sprinters, the 100m world record is 9.74s. I am very happy to use strong static type systems.
  - pdpi 6y ago
    There are type systems out there that allow you to model more than "is a string, is a float, is an int". There are CVEs for use-after-free bugs in Firefox, IE, the Linux kernel and more. Rust's type system helps prevent those. There are CVEs for double-free bugs in OpenSSH, OpenSSL, and Kerberos. Again, Rust's type system helps prevent those. There are CVEs for null dereferencing in the Linux kernel, CUPS, and OpenSSL. Many languages have type systems that help preventing those. There's many more classes of bugs that can be prevented by judicious use of robust type systems. Dismissing strong, static typing as "a crutch for bad programmers" is just plain wrong. All of this, of course, assumes the only use for static types is preventing issues. Algebraic data types actually allow you to write simpler, more concise code in languages that support them. Typeclasses make for a whole model of polymorphism that's just incredibly painful to implement in languages that don't support them.
    - AnimalMuppet 6y ago
      > Dismissing strong, static typing as "a crutch for bad programmers" is just plain wrong. No, it's correct. The problem is that innocentoldguy doesn't realize that he is a bad programmer. (That's not an attack on him - we all are bad programmers.) So here we are, bad programmers. Here's this crutch - or, less negatively put, here's a tool that can help. Maybe we can be somewhat better bad programmers if we use it.
      - pdpi 6y ago
        I get your point, but if we're all bad then "bad" loses its meaning. I'm definitely a better programmer than many of my peers, and worse than a whole bunch of others.
        AnimalMuppet 6y ago
        We're bad, not in comparison with each other, but in comparison to the external standard of "good enough that we don't need a crutch". In fact, if you want to be a better (less bad) programmer, learn to use the available crutches more effectively.
  - pdimitar 6y ago
    That depends on what kind of software you have worked on. I also got quite far with dynamic languages in the last 10 years but at one point the static strong typing helps you a lot in making invalid state impossible at compile time. Growing complexity kind of mandates a static strong typing at one point. Sure, complexity can be managed and reduced -- and distributed among smaller projects (i.e. splitting big projects) -- but even that has a limit.
- pdimitar 6y ago
  Dialyzer also takes a while to get used to and for several teams I've been in the initial cost of learning turned out to not outweigh the theoretical savings won by it. There are other more modern libraries that defer the errors to runtime but also make them much more clear (like `norm`). Libraries like `boundaries` can also help you enforce, a-hem, boundaries in your code and making sure that you write less spaghetti code. I personally stick to Dialyzer in personal projects but it's an uphill battle to constantly keep it happy while OCaml / Rust / Haskell will just immediately yell at you with a well-described error (well, Rust anyway, the other two can be vague sometimes).
pdimitar 6y ago
Yep, there's `dialyxir` which is a very heroic wrapper effort to translate Dialyzer's messages to something more readable and manageable. Even with that though sometimes you get real head scratchers no matter which of both you use.

rkangel 6y ago

I personally believe that Elixir is an excellent 'gateway' functional programming language because it is dynamically typed. Learning OCaml and especially Haskell (I've done some of both) requires understanding a complex type system and learning how to encode what you want in it. On top of that you have to learn to code in the 'functional' way - representing your data, pure code, recursion (or reduces), higher order functions etc. When you write Elixir you eliminate most of the type system stuff, and you just have to learn to code in a functional way. There is surprisingly little 'language' to learn - functions, tuples, lists, maps, modules and that's about it. There is then the OTP (processes and supervisors) side of it, but that's separate (and if you're writing a web backend in Phoenix, mostly ignorable). We're just (hopefully) wrapping up a 9 month project with a team of about 8, none of which had written much Elixir before the start (a background of mostly C). It has been a very smooth process, and definitely the right choice of language.

pdimitar 6y ago
I sorely lack Elixir's easy entry experience while I am getting better and better at Rust. :( And I'll look for ways to use it at my $dayjob. Rust is an excellent language but I feel that for some pieces of our stack Rust is kind of a bazooka in a scenario where a 9mm pistol would do.
- rkangel 6y ago
  I could see an argument where Rust is performant and low level enough that you can use it at the bottom of the stack, and has good enough abstractions that it's productive to use higher in the stack. There are certainly benefits to using one language for everything, but this logic reasoning relies on you having a team that is very familiar with it, and having your bits of tooling and libraries worked out for your setup.
  - pdimitar 6y ago
    Yep, exactly. Lower-level languages however also give you much more foot-guns. These days my ideal app is written in Elixir for almost everything due to the insane parallelisation and fault-tolerance that it offers (and the copy semantics that make shared memory bugs impossible) with Rust sprinkled at the critically important-to-be-fast places -- like working with sqlite3 for example. All of that could be achieved with Rust or any other language really. But it requires tons of tooling, CI/CD jobs, Git hooks, static analyzers, linters, formatters etc. And a good chunk of all that doesn't even exist for many languages. So I prefer to make my own blend that has the important advantages at the right places.