4 ms·

These are good points, but what about considering replaceability as an alternative to maintainability? I personally find dynamic languages allow for easy repla

by gitgud 9y ago

These are good points, but what about considering replaceability as an alternative to maintainability? I personally find dynamic languages allow for easy replacability, as there's less explicit references of types. However this is highly dependent on the system being somewhat modular I suppose.

dnautics 9y ago
This is basically why erlang's hot code reloading would be impossible as a general solution in a statically typed language
- kobeya 9y ago
  You mean like this: http://hackage.haskell.org/package/hotswap http://hackage.haskell.org/package/hotswap Or this: http://hackage.haskell.org/package/dyre http://hackage.haskell.org/package/dyre
  - tree_of_item 9y ago
    15 commits 4 years ago, 121 commits 8 months ago If these things are so good why does no one use them? EVERYONE using Erlang is using the same hotswapping facility. This sort of dynamism is just fighting against the language in an environment like Haskell.
    - naasking 9y ago
      Because Haskell isn't used in the same domains as Erlang, and hot patching full Haskell semantics either isn't needed, or the program is likely already using a DSL for the parts needing well defined dynamism, like the Yi editor, and so hot patching the runtime isn't needed.
    - kobeya 9y ago
      Why would you need to? GHCi supports dynamic code reloading which most people do during development. During runtime there’s not so much of a use case though for most people.
      - kobeya 9y ago
        Replying to myself. There are some use cases though, and in fact my comment points to one of them. Xmonad configurations are themselves Haskell code, and Xmonad does dynamic code reloading to make configuration changes without having to logout. Xmonad rolled their own solution, but "dyre" is a reusable generalization inspired by what Xmonad does. Using Haskell DSL's for configuration of Haskell programs has some significant advantages and dynamic code reloading is essential if the program itself is long-lived or can tolerate no downtime. I don't meant to imply there are no uses ... but outside of configuration or development environments (or real-time routing algorithms in Erlang's case, something I wouldn't advise doing in Haskell) I really don't know what general use cases there are for it. If someone does though, I'd love to learn something new.
    - sitkack 9y ago
      Hot code reloading isn't used in practice to much extent in Erlang codebases either. It exists, in my experience mostly for Dev or emergency patch but not for normal release upgrades. Dynamics with tagged values and pattern matching def make Erlang the easiest to hot reload.
- napsterbr 9y ago
  As long as we are here, with experienced programmers of both "sides", here's a question I've been wondering for some time: is it possible to create a haskell-like type system on an erlang-like language? Erlang has dialyzer, which is great but it's based on optimistic typing. Hot-reloading aside, what would be the issue to creating such language? Maybe some issue with the process pids, which are quite dynamic?
  - naasking 9y ago
    There is no issue. Plenty of typed process calculi exist, and concurrent ML existed back in the late 90s and features channels and processes.
  - Tarean 9y ago
    There is Cloud Haskell[1] which is reasonably close to a Haskell version of Erlang. It forces you to run the same code everywhere while in Erlang you could just hope that the code everywhere is compatible, though. [1] http://haskell-distributed.github.io/ http://haskell-distributed.github.io/

by gitgud 9y ago

dnautics 9y ago

This is basically why erlang's hot code reloading would be impossible as a general solution in a statically typed language

kobeya 9y ago
You mean like this: http://hackage.haskell.org/package/hotswap http://hackage.haskell.org/package/hotswap Or this: http://hackage.haskell.org/package/dyre http://hackage.haskell.org/package/dyre
- tree_of_item 9y ago
  15 commits 4 years ago, 121 commits 8 months ago If these things are so good why does no one use them? EVERYONE using Erlang is using the same hotswapping facility. This sort of dynamism is just fighting against the language in an environment like Haskell.
  - naasking 9y ago
    Because Haskell isn't used in the same domains as Erlang, and hot patching full Haskell semantics either isn't needed, or the program is likely already using a DSL for the parts needing well defined dynamism, like the Yi editor, and so hot patching the runtime isn't needed.
  - kobeya 9y ago
    Why would you need to? GHCi supports dynamic code reloading which most people do during development. During runtime there’s not so much of a use case though for most people.
    - kobeya 9y ago
      Replying to myself. There are some use cases though, and in fact my comment points to one of them. Xmonad configurations are themselves Haskell code, and Xmonad does dynamic code reloading to make configuration changes without having to logout. Xmonad rolled their own solution, but "dyre" is a reusable generalization inspired by what Xmonad does. Using Haskell DSL's for configuration of Haskell programs has some significant advantages and dynamic code reloading is essential if the program itself is long-lived or can tolerate no downtime. I don't meant to imply there are no uses ... but outside of configuration or development environments (or real-time routing algorithms in Erlang's case, something I wouldn't advise doing in Haskell) I really don't know what general use cases there are for it. If someone does though, I'd love to learn something new.
  - sitkack 9y ago
    Hot code reloading isn't used in practice to much extent in Erlang codebases either. It exists, in my experience mostly for Dev or emergency patch but not for normal release upgrades. Dynamics with tagged values and pattern matching def make Erlang the easiest to hot reload.
napsterbr 9y ago
As long as we are here, with experienced programmers of both "sides", here's a question I've been wondering for some time: is it possible to create a haskell-like type system on an erlang-like language? Erlang has dialyzer, which is great but it's based on optimistic typing. Hot-reloading aside, what would be the issue to creating such language? Maybe some issue with the process pids, which are quite dynamic?
- naasking 9y ago
  There is no issue. Plenty of typed process calculi exist, and concurrent ML existed back in the late 90s and features channels and processes.
- Tarean 9y ago
  There is Cloud Haskell[1] which is reasonably close to a Haskell version of Erlang. It forces you to run the same code everywhere while in Erlang you could just hope that the code everywhere is compatible, though. [1] http://haskell-distributed.github.io/ http://haskell-distributed.github.io/