4 ms·

"Dynamically-typed" often leads to "hard to refactor", which in turn slows down your iterations at a certain (surprisingly low) amount of code. This may still b

by vog 9y ago

"Dynamically-typed" often leads to "hard to refactor", which in turn slows down your iterations at a certain (surprisingly low) amount of code. This may still be less annoying than Java (especially before 1.8), but: Have you ever refactored code in OCaml? (or SML, or Haskell, for that matter) This is a breeze! It's mostly the ecosystem that drives me to Python and/or JavaScript.

mbrock 9y ago
Haskell with Aeson and Lens starts to approach convenience when dealing with deep JSON structures, but it's still kind of messy and arcane compared to JavaScript—in my opinion as a Haskell coder since 2004 who went to Chalmers, studied advanced functional programming, learned Agda, and works with Haskell full time. After years of learning I'm quite proficient with Haskell, and of course I recognize its enormous benefits, but I still totally understand the choice to use Node rather than Haskell, just like I also understand the choice to use bash for a lot of things! I think Haskell is a transition language that will be replaced soon enough, because its warts and deficiencies significantly hinder learning and adoption. TypeScript is probably a way more pragmatic choice for most people who want the majority of the benefits of a static type system.
- vog 9y ago
  > I think Haskell is a transition language that will be replaced soon enough What do you have in mind when you say that? One of the existing contenders? (SML, OCaml, Rust, Elm) Or something completely different?
  - mbrock 9y ago
    Okay, that's premature speculation because I don't have anything concrete in mind! It's just a premonition I have of Haskell getting more complex while still tied to backwards compatibility and suddenly there's a new kid in town. Maybe it will be something like Elixir is to Erlang or Reason to O'Caml, like, reusing the GHC runtime and GHC Core but with a new syntax and standard library.
  - hajile 9y ago
    SML 2.0 is the best candidate IMO. Rust isn't a competitor as it's too close to metal and too verbose (great for those kinds of things, but not for everything). Elm has nice libraries (though not even all the the standardized web APIs are supported yet). It also gets rid of Haskell's lazy evaluation, so reasoning is easier. It doesn't have type classes though (and misses many advanced features). The side effect question isn't great either IMO (I believe side effects are necessary for real-world code). SML would benefit from a little more syntax (borrow a couple good ideas from Ocaml), but is very simple to learn and despite the simplicity, has an amazingly powerful type system. While it could gain some benefit from type classes, at least it isn't lazy, allows side effects, and is immutable by default (but allows mutation if you need). It doesn't have classes like Ocaml or F#, but I don't consider that to be a loss. It has sane operator rules (and overloading which is important for native-feeling APIs). SML is very fast (thank you mlton) and unlike Ocaml, doesn't have to lose all its performance when you need 32 or 64-bit integers for something. Unlike Ocaml, there are actually working multi-threading implementations like poly-ml (mlton has an experimental one like Ocaml). It's worth noting that because there is a standard, you don't have one implementation/company that defines the spec. The big flaws of SML are adoption, libraries, and the need for some extra syntax (there is work on this that is ongoing). In the grand scheme of things, it's in a very good position for a language that isn't that popular.
rmrfrmrf 9y ago
If you intentionally code JS with referential transparency in mind, then this type of refactoring is just as esay, if not easier.
- vog 9y ago
  Would you mind to elaborate? How does "having referential transparency in mind" protect against typical refactoring errors, such as an unexpected "undefined" value due to a typo in a field name? (Of course you could argue that you don't need OCaml for that, as TypeScript or Flow can prevent this, too. But then the argument of using "dynamic" JavaScript instead of static types is moot.)

by vog 9y ago

mbrock 9y ago

Haskell with Aeson and Lens starts to approach convenience when dealing with deep JSON structures, but it's still kind of messy and arcane compared to JavaScript—in my opinion as a Haskell coder since 2004 who went to Chalmers, studied advanced functional programming, learned Agda, and works with Haskell full time. After years of learning I'm quite proficient with Haskell, and of course I recognize its enormous benefits, but I still totally understand the choice to use Node rather than Haskell, just like I also understand the choice to use bash for a lot of things! I think Haskell is a transition language that will be replaced soon enough, because its warts and deficiencies significantly hinder learning and adoption. TypeScript is probably a way more pragmatic choice for most people who want the majority of the benefits of a static type system.

vog 9y ago
> I think Haskell is a transition language that will be replaced soon enough What do you have in mind when you say that? One of the existing contenders? (SML, OCaml, Rust, Elm) Or something completely different?
- mbrock 9y ago
  Okay, that's premature speculation because I don't have anything concrete in mind! It's just a premonition I have of Haskell getting more complex while still tied to backwards compatibility and suddenly there's a new kid in town. Maybe it will be something like Elixir is to Erlang or Reason to O'Caml, like, reusing the GHC runtime and GHC Core but with a new syntax and standard library.
- hajile 9y ago
  SML 2.0 is the best candidate IMO. Rust isn't a competitor as it's too close to metal and too verbose (great for those kinds of things, but not for everything). Elm has nice libraries (though not even all the the standardized web APIs are supported yet). It also gets rid of Haskell's lazy evaluation, so reasoning is easier. It doesn't have type classes though (and misses many advanced features). The side effect question isn't great either IMO (I believe side effects are necessary for real-world code). SML would benefit from a little more syntax (borrow a couple good ideas from Ocaml), but is very simple to learn and despite the simplicity, has an amazingly powerful type system. While it could gain some benefit from type classes, at least it isn't lazy, allows side effects, and is immutable by default (but allows mutation if you need). It doesn't have classes like Ocaml or F#, but I don't consider that to be a loss. It has sane operator rules (and overloading which is important for native-feeling APIs). SML is very fast (thank you mlton) and unlike Ocaml, doesn't have to lose all its performance when you need 32 or 64-bit integers for something. Unlike Ocaml, there are actually working multi-threading implementations like poly-ml (mlton has an experimental one like Ocaml). It's worth noting that because there is a standard, you don't have one implementation/company that defines the spec. The big flaws of SML are adoption, libraries, and the need for some extra syntax (there is work on this that is ongoing). In the grand scheme of things, it's in a very good position for a language that isn't that popular.

rmrfrmrf 9y ago

If you intentionally code JS with referential transparency in mind, then this type of refactoring is just as esay, if not easier.

vog 9y ago
Would you mind to elaborate? How does "having referential transparency in mind" protect against typical refactoring errors, such as an unexpected "undefined" value due to a typo in a field name? (Of course you could argue that you don't need OCaml for that, as TypeScript or Flow can prevent this, too. But then the argument of using "dynamic" JavaScript instead of static types is moot.)