4 ms·

I think the first section confuses a couple of things. First, a program can be compiled (static) or interpreted (dynamic) as stated in the article. However, th

by charriu 11y ago

I think the first section confuses a couple of things. First, a program can be compiled (static) or interpreted (dynamic) as stated in the article. However, that does not mean that you can't have a dynamic type system in a compiled language, or vice versa. Also, if you add type inference, the examples given for variables in dynamic languages are perfectly valid examples for variables in a language with a static type system (the type would just be defined on first assignment).

oxymoron 11y ago
Static and dynamic are theoretically unrelated to compiled or interpreted. The reason why it seems like these two are the same is that it's much harder to implement a compiled version of a dynamic language than an interpreted dynamic language, although I'm sure it's been done. There are plenty of interpreted static languages though. I'm missing a discussion of weak vs strong in the article though. Visual Basic might be statically typed but it does have implicit type coercion which gives it a very different feel from — say — C#.
- xigency 11y ago
  The only difference for me is how often I need to cast types so I guess that's kind of lost on me.
  - oxymoron 11y ago
    Sure, that's what it comes down to. Languages with implicit type coercion do have a set of bugs not found in strongly typed languages though, but the additional safety of a strong language is -- like you say -- gained at the expense of writing casts. That does seem like a trade-off worth discussing in an article about programming language design.
    - hvidgaard 11y ago
      C# allows you to do implicit casts when you do not lose information, e.g. int to long. I cannot remember the last time I had to cast to something where I would potentially lose information. However, I don't think manual casting is a cost at all - it's more of a guide telling you something in the design is wrong, or a reminder to make a comment of why you do it. And for any long maintanence projects, you want to catch all the bugs you can as early as you can.
- KC8ZKF 11y ago
  Common Lisp is an example of a compiled dynamic language.
  - bigtunacan 11y ago
    As is JavaScript
    - sklogic 11y ago
      No, they're very far away from each other on the dynamism scale. There is absolutely no point in trying to compile JavaScript statically, but yet it works very well for Common Lisp. The opposite is also true, smart tracing JITs won't do much for Common Lisp, but shine for JavaScript.
      - bigtunacan 11y ago
        I was just adding on that JavaScript is another example of a dynamic language that is compiled (using JIT in this case) rather than strictly interpreted such as the MRI implementation of Ruby.
        bigtunacan 11y ago
        Since both this and my parent post on JavaScript being compiled were downvoted without comment I can only make the assumption this is because someone came along who believes this is not the case. So first I will link out to this StackExchange doc that does a pretty good job of describing this. http://programmers.stackexchange.com/questions/138521/is-javascript-interpreted-by-design http://programmers.stackexchange.com/questions/138521/is-jav... The JavaScript specification says nothing about the language being interpreted or compiled. Today; most current versions of major browsers use a just in time compiler to handle JavaScript. V8 (Chrome & Nodejs), SpiderMonkey (Firefox), Chakra (InternetExplorer), Carakan (Opera), JavaScriptCore(Webkit/Safari) For more information take a look at the Wiki entry for EcmaScript engines. https://en.wikipedia.org/wiki/List_of_ECMAScript_engines https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
      - 11y ago
- qznc 11y ago
  > it's much harder to implement a compiled version of a dynamic language No it is not. All major dynamic languages can be compiled usually JIT. Every major browser has a JIT compiler for Javascript. Python, Ruby, and Lua have JIT-compiled forks/reimplementations. The difference of JIT vs ahead-of-time compilation is irrelevant for the high level of the article.
  - sklogic 11y ago
    > All major dynamic languages can be compiled usually JIT. JITs are profoundly different from standalone compilers. And are many times more complicated. > The difference of JIT vs ahead-of-time compilation is irrelevant for the high level of the article. No it's not irrelevant. JITs are starting to kick in at a very different point than the static compilers: they've got a path trace, runtime type information and profiling information, while the static compiler only got an AST. JITs can do gradual refinement, and for this they may implement multiple different compilation techniques. Static compiler must do all it can at once, there is no other chance to improve.
- vidarh 11y ago
  It's harder to compile, period. But's it's in many ways easier to compile a dynamic language than a static language, as you can implement a single mechanis for defining classes and calling methods. That mechanism can often be very similar to how it would be in an interpreter. What is harder is to achieve the same performance jump from interpreted to compiled. Exactly because the "naive" approach to compiling dynamically typed languages gives you similar machinery to a well written interpreter, while for static language the "naive" approach often gets you much more efficient results.
xigency 11y ago
Yes, but those are all tasks which the compiler has to do when compiling source. So after a programmer has written code but before it can even run. Really any run time could completely disregard types, it just might lead to a huge number of failure cases. These generalizations are there for us to start to get things to work. When programming languages add features like these, especially 10 or 20 years after they were developed, they definitely feel tacked-on and if you inspect how they work, it's not pretty. If it's an interesting quirk then it might be an example to study.

by charriu 11y ago

oxymoron 11y ago

Static and dynamic are theoretically unrelated to compiled or interpreted. The reason why it seems like these two are the same is that it's much harder to implement a compiled version of a dynamic language than an interpreted dynamic language, although I'm sure it's been done. There are plenty of interpreted static languages though. I'm missing a discussion of weak vs strong in the article though. Visual Basic might be statically typed but it does have implicit type coercion which gives it a very different feel from — say — C#.

xigency 11y ago
The only difference for me is how often I need to cast types so I guess that's kind of lost on me.
- oxymoron 11y ago
  Sure, that's what it comes down to. Languages with implicit type coercion do have a set of bugs not found in strongly typed languages though, but the additional safety of a strong language is -- like you say -- gained at the expense of writing casts. That does seem like a trade-off worth discussing in an article about programming language design.
  - hvidgaard 11y ago
    C# allows you to do implicit casts when you do not lose information, e.g. int to long. I cannot remember the last time I had to cast to something where I would potentially lose information. However, I don't think manual casting is a cost at all - it's more of a guide telling you something in the design is wrong, or a reminder to make a comment of why you do it. And for any long maintanence projects, you want to catch all the bugs you can as early as you can.
KC8ZKF 11y ago
Common Lisp is an example of a compiled dynamic language.
- bigtunacan 11y ago
  As is JavaScript
  - sklogic 11y ago
    No, they're very far away from each other on the dynamism scale. There is absolutely no point in trying to compile JavaScript statically, but yet it works very well for Common Lisp. The opposite is also true, smart tracing JITs won't do much for Common Lisp, but shine for JavaScript.
    - bigtunacan 11y ago
      I was just adding on that JavaScript is another example of a dynamic language that is compiled (using JIT in this case) rather than strictly interpreted such as the MRI implementation of Ruby.
      - bigtunacan 11y ago
        Since both this and my parent post on JavaScript being compiled were downvoted without comment I can only make the assumption this is because someone came along who believes this is not the case. So first I will link out to this StackExchange doc that does a pretty good job of describing this. http://programmers.stackexchange.com/questions/138521/is-javascript-interpreted-by-design http://programmers.stackexchange.com/questions/138521/is-jav... The JavaScript specification says nothing about the language being interpreted or compiled. Today; most current versions of major browsers use a just in time compiler to handle JavaScript. V8 (Chrome & Nodejs), SpiderMonkey (Firefox), Chakra (InternetExplorer), Carakan (Opera), JavaScriptCore(Webkit/Safari) For more information take a look at the Wiki entry for EcmaScript engines. https://en.wikipedia.org/wiki/List_of_ECMAScript_engines https://en.wikipedia.org/wiki/List_of_ECMAScript_engines
    - 11y ago
qznc 11y ago
> it's much harder to implement a compiled version of a dynamic language No it is not. All major dynamic languages can be compiled usually JIT. Every major browser has a JIT compiler for Javascript. Python, Ruby, and Lua have JIT-compiled forks/reimplementations. The difference of JIT vs ahead-of-time compilation is irrelevant for the high level of the article.
- sklogic 11y ago
  > All major dynamic languages can be compiled usually JIT. JITs are profoundly different from standalone compilers. And are many times more complicated. > The difference of JIT vs ahead-of-time compilation is irrelevant for the high level of the article. No it's not irrelevant. JITs are starting to kick in at a very different point than the static compilers: they've got a path trace, runtime type information and profiling information, while the static compiler only got an AST. JITs can do gradual refinement, and for this they may implement multiple different compilation techniques. Static compiler must do all it can at once, there is no other chance to improve.
vidarh 11y ago
It's harder to compile, period. But's it's in many ways easier to compile a dynamic language than a static language, as you can implement a single mechanis for defining classes and calling methods. That mechanism can often be very similar to how it would be in an interpreter. What is harder is to achieve the same performance jump from interpreted to compiled. Exactly because the "naive" approach to compiling dynamically typed languages gives you similar machinery to a well written interpreter, while for static language the "naive" approach often gets you much more efficient results.

xigency 11y ago

Yes, but those are all tasks which the compiler has to do when compiling source. So after a programmer has written code but before it can even run. Really any run time could completely disregard types, it just might lead to a huge number of failure cases. These generalizations are there for us to start to get things to work. When programming languages add features like these, especially 10 or 20 years after they were developed, they definitely feel tacked-on and if you inspect how they work, it's not pretty. If it's an interesting quirk then it might be an example to study.