3 ms·

There's nothing more "advanced" about statically typed languages. Static typing and type inference are straightforward and can make implementation details simpl

by KellAG 10y ago

There's nothing more "advanced" about statically typed languages. Static typing and type inference are straightforward and can make implementation details simpler than dynamic languages (because you're greatly reducing or removing the unknowns you have to deal with at runtime). This is assuming you're making a batch-style compiler, as most implementors do, and not an interactive system. If you're focused on benchmark numbers, dynamically typed languages are much more challenging to squeeze performance out of better code generation. You can also add static type inference and consistency checking to a dynamic language, and indeed some systems do in the name of better

jnbiche 10y ago
I meant "advanced static-typing" (e.g, like System F, which is advanced to someone learning PL). Not that it was more advanced, although I think in fact it is from a learner's point of view. It's incredibly simple to throw together a Scheme, or even a more complex interpreted dynamic language. Add in a static typing, type inferencing, and type checking, and that all becomes much more complicated, at least from this learner's point of view. From how highly upvoted my comment is, I suspect I'm far from being alone here. Learning, understanding, and implementing Hindley-Milner by itself was harder for me than learning how to put together a basic interpreter for a simple scheme. And I think a big part of that is the dearth of learning materials for things like Hindley-Milner and related concepts, whereas there are 100 books and tutorials on how to implement a Scheme interpreter in language X. Finally, if you're talking about language performance, then yes clearly it's much harder to squeeze performance out of dynamic languages. But I'm talking about learning exercises here, not production programming languages.
- mafribe 10y ago
  dearth of learning materials for things like Hindley-Milner What's wrong with the original paper [1]? It's really basic and boiled down to the essence (in true Milner style). I give it to all my students interested in typing systems as first paper. (There is a typo on Page 211.) [1] L. Damas, R. Milner, Principal type-schemes for functional programs.
  - dsp1234 10y ago
    Eric Lippert[0] is doing an "excessive explanation" of this paper[1], where he breaks the entire paper down, line by line, with examples that C#/Java people would recognize. It's nice for people like myself who are strong on concepts, but weak on notation. ex: map : ∀α ∀β ((α → β) → (α list → β list)) Which I previously couldn't read, but I could easily explain the concept. [0] - Former C# language designer, Roslyn compiler team, etc. https://www.reddit.com/r/programmerchat/comments/37qwmm/i_am_eric_lippert_a_software_developer/ https://www.reddit.com/r/programmerchat/comments/37qwmm/i_am... https://ericlippert.com/about-eric-lippert/ https://ericlippert.com/about-eric-lippert/ [1] - https://ericlippert.com/?s=excessive&submit=Search https://ericlippert.com/?s=excessive&submit=Search
    - mafribe 10y ago
      Thank you, that's an interesting point. The thought that somebody would not be able to understand the type of map had not occurred to me, because I'm surrounded by people with a strong maths/FP background. Shows just how narrow-minded I am.
mafribe 10y ago
While I agree that compilation of dynamically typed languages is more challenging, inference for advanced typing systems is full of problems: - How to ensure that the inference algorithm is correct. - How to design typing systems that are expressive, yet lightweight, and have enough type inference to be usable in practise. - How to deal with concurrency and parallelism. None of these problems is really solved. In practise even making type inference fast is a challenge, e.g. in older versions of the Scala compiler, type inference was really slow due to implicits.

by KellAG 10y ago

jnbiche 10y ago

I meant "advanced static-typing" (e.g, like System F, which is advanced to someone learning PL). Not that it was more advanced, although I think in fact it is from a learner's point of view. It's incredibly simple to throw together a Scheme, or even a more complex interpreted dynamic language. Add in a static typing, type inferencing, and type checking, and that all becomes much more complicated, at least from this learner's point of view. From how highly upvoted my comment is, I suspect I'm far from being alone here. Learning, understanding, and implementing Hindley-Milner by itself was harder for me than learning how to put together a basic interpreter for a simple scheme. And I think a big part of that is the dearth of learning materials for things like Hindley-Milner and related concepts, whereas there are 100 books and tutorials on how to implement a Scheme interpreter in language X. Finally, if you're talking about language performance, then yes clearly it's much harder to squeeze performance out of dynamic languages. But I'm talking about learning exercises here, not production programming languages.

mafribe 10y ago
dearth of learning materials for things like Hindley-Milner What's wrong with the original paper [1]? It's really basic and boiled down to the essence (in true Milner style). I give it to all my students interested in typing systems as first paper. (There is a typo on Page 211.) [1] L. Damas, R. Milner, Principal type-schemes for functional programs.
- dsp1234 10y ago
  Eric Lippert[0] is doing an "excessive explanation" of this paper[1], where he breaks the entire paper down, line by line, with examples that C#/Java people would recognize. It's nice for people like myself who are strong on concepts, but weak on notation. ex: map : ∀α ∀β ((α → β) → (α list → β list)) Which I previously couldn't read, but I could easily explain the concept. [0] - Former C# language designer, Roslyn compiler team, etc. https://www.reddit.com/r/programmerchat/comments/37qwmm/i_am_eric_lippert_a_software_developer/ https://www.reddit.com/r/programmerchat/comments/37qwmm/i_am... https://ericlippert.com/about-eric-lippert/ https://ericlippert.com/about-eric-lippert/ [1] - https://ericlippert.com/?s=excessive&submit=Search https://ericlippert.com/?s=excessive&submit=Search
  - mafribe 10y ago
    Thank you, that's an interesting point. The thought that somebody would not be able to understand the type of map had not occurred to me, because I'm surrounded by people with a strong maths/FP background. Shows just how narrow-minded I am.

mafribe 10y ago

While I agree that compilation of dynamically typed languages is more challenging, inference for advanced typing systems is full of problems: - How to ensure that the inference algorithm is correct. - How to design typing systems that are expressive, yet lightweight, and have enough type inference to be usable in practise. - How to deal with concurrency and parallelism. None of these problems is really solved. In practise even making type inference fast is a challenge, e.g. in older versions of the Scala compiler, type inference was really slow due to implicits.