4 ms·

> For example, when writing an Elm program I might at some point decide that users should have an admin flag. I will then try to use that flag in a function at

by spion 10y ago

> For example, when writing an Elm program I might at some point decide that users should have an admin flag. I will then try to use that flag in a function at which point the compiler will tell me that I have failed to add it to the User model. I will add it to the model at which point the compiler will tell me that I have failed to account for it in my main update function. This beautifully explains why types are so useful. I don't know if the number of bugs goes down, but it sure is useful to have an assistant check all the implications of a change I want to make, and does that in a second.

tommyd 10y ago
Absolutely agree, this is one of the biggest benefits I have found since I started working with Typescript (that, and the ease of refactoring). Of course Flow/Typescript's approach to typing isn't as complete as Elm's, but you can still gain some of the benefits by using one of them; and for many of us, introducing Flow/TS at work is a lot more likely to happen than introducing Elm.
- catnaroek 10y ago
  Ironically, Elm's type system is actually one of the simplest out there. No subtyping (unions or intersections), no flow-sensitive typing, just plain first-order type constructors, Hindley-Milner type inference and nice records. Much of the complication in Flow and TypeScript's type systems comes from the need to accommodate existing JavaScript idioms.
  - tommyd 10y ago
    Good point. I suppose what I meant was more that types are at the core of Elm and pervade every part of the language, whereas TS/Flow are adding types on top of a dynamic language and there are parts where it may be difficult or impossible to maintain type safety to the same degree (especially when interacting with non-TS/Flow code)
    - catnaroek 10y ago
      Sure. As a member of the extended ML/Haskell family, Elm is inherently typeful, whereas in TS/Flow types are opt-in. But, as it turns out, pragmatically, typefulness actually limits the extent to which a language can become complicated, because the complexity ends up showing in the type system, and that's useful feedback for the language designer that he or she is going in the wrong direction. OTOH, the designer of a non-typeful language can “hide the ball” by not reflecting complexity in types.
    - seanmcdirmid 10y ago
      No one has really figured out nominal subtyping + type parameters with good type inference support. The best we can achieve seems to be scala, which still requires more type annotations than many are comfortable with.
      - deleted 10y ago
        [deleted]
      - imtringued 10y ago
        I'm not sure what you're talking about. Can you please elaborate?
        ufo 10y ago
        The real issue is not nominal vs structural typing. Its the subsumption rule (which says that you can freely use a subtype anywhere a supertype would be expected). Mixing subtyping with subsumption and parametric polymorphism (type parameters) is really very difficult though. From a theoretic point of view, type inference and type checking are harder. From an usability perspective, the programmer now has to deal with variance annotations (for example, in Java `class List[+T]` means the T parameter is covariant) and bounded polymorphism (for example, things like <? extends T> in Java).
pjmlp 10y ago
They go down and also allow for doing good AOT code generation to native code in the languages that have such toolchains, whereas dynamic languages really need a JIT. After working on a startup that had a server architecture similar to AOL Server and also seeing some heavy Zope deployments (late 90's), I never got to understand the use of dynamic languages for large codebases.
- klibertp 10y ago
  > whereas dynamic languages really need a JIT Dylan? Honestly asking - I used the language a bit but I didn't read anything on its implementation(s).
  - pjmlp 10y ago
    Lisp also has good AOT compilers, but you need to provide the necessary (optional) type annotations. So in the end you end up with code that looks no different than from static languages. With ML-like type inference and dynamic type support, there is hardly any disadvantage with static type languages and you get the tooling support. Dynamic languages can have very nice tooling, and we are yet to regain what was possible in Xerox and Genera environments, but your environment needs a live image of the code to produce good results, hence JIT.
- KallDrexx 10y ago
  It's weird. I can't imagine working on large (and critical) code bases in dynamic languages just from pats experiences on working on those systems, yet the project I'm working on now (that has the potential to be critical if the MVP goes well and I can put it in production) I've resigned to using Elixir. Even though I keep getting bit by bugs that a proper type checker would catch (Dialyzer is not sufficient for some of these bugs unfortunately) the problem is such a perfect use case for the BEAM VM that I don't really have a lot of choice without increasing the complexity by a lot.

by spion 10y ago

tommyd 10y ago

Absolutely agree, this is one of the biggest benefits I have found since I started working with Typescript (that, and the ease of refactoring). Of course Flow/Typescript's approach to typing isn't as complete as Elm's, but you can still gain some of the benefits by using one of them; and for many of us, introducing Flow/TS at work is a lot more likely to happen than introducing Elm.

catnaroek 10y ago
Ironically, Elm's type system is actually one of the simplest out there. No subtyping (unions or intersections), no flow-sensitive typing, just plain first-order type constructors, Hindley-Milner type inference and nice records. Much of the complication in Flow and TypeScript's type systems comes from the need to accommodate existing JavaScript idioms.
- tommyd 10y ago
  Good point. I suppose what I meant was more that types are at the core of Elm and pervade every part of the language, whereas TS/Flow are adding types on top of a dynamic language and there are parts where it may be difficult or impossible to maintain type safety to the same degree (especially when interacting with non-TS/Flow code)
  - catnaroek 10y ago
    Sure. As a member of the extended ML/Haskell family, Elm is inherently typeful, whereas in TS/Flow types are opt-in. But, as it turns out, pragmatically, typefulness actually limits the extent to which a language can become complicated, because the complexity ends up showing in the type system, and that's useful feedback for the language designer that he or she is going in the wrong direction. OTOH, the designer of a non-typeful language can “hide the ball” by not reflecting complexity in types.
  - seanmcdirmid 10y ago
    No one has really figured out nominal subtyping + type parameters with good type inference support. The best we can achieve seems to be scala, which still requires more type annotations than many are comfortable with.
    - deleted 10y ago
      [deleted]
    - imtringued 10y ago
      I'm not sure what you're talking about. Can you please elaborate?
      - ufo 10y ago
        The real issue is not nominal vs structural typing. Its the subsumption rule (which says that you can freely use a subtype anywhere a supertype would be expected). Mixing subtyping with subsumption and parametric polymorphism (type parameters) is really very difficult though. From a theoretic point of view, type inference and type checking are harder. From an usability perspective, the programmer now has to deal with variance annotations (for example, in Java `class List[+T]` means the T parameter is covariant) and bounded polymorphism (for example, things like <? extends T> in Java).

pjmlp 10y ago

They go down and also allow for doing good AOT code generation to native code in the languages that have such toolchains, whereas dynamic languages really need a JIT. After working on a startup that had a server architecture similar to AOL Server and also seeing some heavy Zope deployments (late 90's), I never got to understand the use of dynamic languages for large codebases.

klibertp 10y ago
> whereas dynamic languages really need a JIT Dylan? Honestly asking - I used the language a bit but I didn't read anything on its implementation(s).
- pjmlp 10y ago
  Lisp also has good AOT compilers, but you need to provide the necessary (optional) type annotations. So in the end you end up with code that looks no different than from static languages. With ML-like type inference and dynamic type support, there is hardly any disadvantage with static type languages and you get the tooling support. Dynamic languages can have very nice tooling, and we are yet to regain what was possible in Xerox and Genera environments, but your environment needs a live image of the code to produce good results, hence JIT.
KallDrexx 10y ago
It's weird. I can't imagine working on large (and critical) code bases in dynamic languages just from pats experiences on working on those systems, yet the project I'm working on now (that has the potential to be critical if the MVP goes well and I can put it in production) I've resigned to using Elixir. Even though I keep getting bit by bugs that a proper type checker would catch (Dialyzer is not sufficient for some of these bugs unfortunately) the problem is such a perfect use case for the BEAM VM that I don't really have a lot of choice without increasing the complexity by a lot.