3 ms·

>Types are optional For me, this is show stopper which negates all other stuff. After types are optional, then type errors turn into warnings, and you get the

>Types are optional For me, this is show stopper which negates all other stuff. After types are optional, then type errors turn into warnings, and you get the same mess you have in JS. Another annoyance is lack of real generics.

spankalee 12y ago
It's not the same mess as in JavaScript because we have checked mode which enforces the types at runtime. Combined with the static warnings we find this to be very, very effective. I hope you don't just leave warnings in your project :) but if during development you want to try some code path you're pretty sure will work while you have fixed up other paths that have warnings, you should be able to. The philosophy is to make as many errors happen at runtime rather than "compile" time so that you can continue to work with out always having to satisfy the type checker across your whole program. This is one of the productivity advantages of dynamically typed languages. We feel that the combination of dynamic types and checked mode gives you the best of both worlds.
- aliakhtar 12y ago
  > The philosophy is to make as many errors happen at runtime rather than "compile" time This is pretty terrible. I would much rather find out about errors at compile time. Its a lot easier to find the source of the error from within the IDE and fix it, than to debug a runtime error.
  - SteveMcQwark 12y ago
    I can understand where you're coming from since I like static typing as well, but I don't think what you're saying is fair. It's good to be able to statically identify certain classes of errors so that you can, as you say, find and fix them within the IDE rather than having to resort to runtime debugging. What he (?) is saying is that, up until the point where you encounter the error at runtime, the fact that you can statically detect it shouldn't prevent you from running your code. This philosophy is obviously a tradeoff. It's good for prototyping since you don't have to make sure your whole program passes static analysis in order to test a particular code path. On the other hand, if developers get away with leaving such code in a large project (as a work in progress that never gets addressed, for example), this can create a maintenance nightmare. The solution to this is to not let people contribute code to the project which doesn't pass static analysis.

spankalee 12y ago

It's not the same mess as in JavaScript because we have checked mode which enforces the types at runtime. Combined with the static warnings we find this to be very, very effective. I hope you don't just leave warnings in your project :) but if during development you want to try some code path you're pretty sure will work while you have fixed up other paths that have warnings, you should be able to. The philosophy is to make as many errors happen at runtime rather than "compile" time so that you can continue to work with out always having to satisfy the type checker across your whole program. This is one of the productivity advantages of dynamically typed languages. We feel that the combination of dynamic types and checked mode gives you the best of both worlds.

aliakhtar 12y ago
> The philosophy is to make as many errors happen at runtime rather than "compile" time This is pretty terrible. I would much rather find out about errors at compile time. Its a lot easier to find the source of the error from within the IDE and fix it, than to debug a runtime error.
- SteveMcQwark 12y ago
  I can understand where you're coming from since I like static typing as well, but I don't think what you're saying is fair. It's good to be able to statically identify certain classes of errors so that you can, as you say, find and fix them within the IDE rather than having to resort to runtime debugging. What he (?) is saying is that, up until the point where you encounter the error at runtime, the fact that you can statically detect it shouldn't prevent you from running your code. This philosophy is obviously a tradeoff. It's good for prototyping since you don't have to make sure your whole program passes static analysis in order to test a particular code path. On the other hand, if developers get away with leaving such code in a large project (as a work in progress that never gets addressed, for example), this can create a maintenance nightmare. The solution to this is to not let people contribute code to the project which doesn't pass static analysis.