Hacker News new | past | comments | ask | show | jobs | submit login

I didn't claim it was. That's one of the tradeoffs you make in exchange for a simpler, more forgiving programming model (and the ability to do serious work in a REPL or notebook). However, given that Julia programs can be mostly type inferred before execution, it is possible to check for this kind of error before running a program. There have been some projects to do exactly that [1] [2], and I suspect that once Julia reaches 1.0, we'll focus more effort on static analysis tools.

The point is that you don't need a static language to get many of the benefits of types, you just need your language that allows you to express type-based properties. One of the way to do that is to have a set of formal rules for deriving the type of every expression in a program, but that's not actually necessary.

[1] https://github.com/astrieanna/TypeCheck.jl

[2] https://github.com/tonyhffong/Lint.jl




Being able to get these errors without running the code is almost all the benefit.

It enables a whole class of highly effective program manipulations that are just unavailable to a non-statically-checked language.


The claimed benefit is getting the error earlier and "at the location the erroneous value is inserted." That's exactly what happens in a dynamic language with typed collections – but, as I admitted, not at compile time. Is it better to get an error at compile time? Sure, but most of the benefit comes from the error being raised at the erroneous insertion and not later when the value is used by some completely unrelated code. Hence, my claim of getting most of the benefit. Now there are certainly other arguments to be made about "highly effective program manipulations", but that's not the case being presented by the author here.


Those other "highly effective program manipulations" include refactoring and modifications which involve changing parameter and return types. While I understand what you're saying, to myself it's pretty clear that there's a wide gap between these two scenarios:

* Changing the collection's type and not knowing until runtime -- when your program crashes -- that it's being used wrong.

* Changing the collection's type and the program refusing to compile until all usage is corrected.

Because of this, I don't agree with the most modifier you're attempting to apply. The difference to me is confidence. In the former, how confident am I that I didn't miss a use-case on some branch? Considering that the program will crash or otherwise fail to operate, that seems like something I want to be pretty confident about.

It's very useful to have something telling you that everything looks OK. That something can be testing, but why rely on writing good tests when we have formal proof systems available?


You did...

> For example, most of these advantages apply to Julia as well...

and then you listed it as an advantage.


The advantage OP was referring to was that you could force a type warning at all, as opposed to PHP, JS etc where typed arrays don't exist (notwithstanding Uint32Array and such).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: