Right, so you have the high-level, dynamic part of the language for basic interactive use and the harder to use, fully typed part for the "real" coding.
Except that already exists – you can just use Python and C. The split between high and low-level is exactly the problem that Julia was designed to solve. Bear in mind that this goes well beyond a few type hints. If you wanted this, you'd have to enforce containers always having concrete elements, for example. If it ever made sense to have a container hold multiple types (e.g. in expression trees, markdown etc.), you'd have to write a container type like Nullable for every possible combination, at which point you're just emulating dynamic typing in a ridiculously fiddly way – and you've lost any extensibility you had to boot. I actually can't think of a single language that enforces perfect type stability (and static typing is not the same thing). Haskell comes close, but it's not exactly renowned for its ease of use, which is a priority in Julia's design. If you really believe in this, I encourage you to have a go at implementing something like Markdown.jl in a 100% type-stable way. If you can do it without tripling the code size, halving the flexibility and gaining only a marginal performance benefit, I'll relent, but right now I don't see it. On 3 January 2015 at 14:17, Ariel Keselman <[email protected]> wrote: > > There is type-instability only at global scope, that's the point. So when > you are using the repl (or just using the global scope) you won't have to > write types. My suggestion is only to disallow type-instability at inner > scopes so they become fully statically typed; the next step would be to > statically check functions before compilation, a real static check just > like you would get in say Java or or Haskell. > > The advantages are way more than just linting. You would catch whole > categories of problems at copile time, before your code actually runs. > Imagine finding a problem after your code runs for hrs, or a web server > crash in production due to some untested code.... these things happen. This > would allow way better tooling: the tooling that statically typed languages > have (think Java, C#) is wayyyy better than that of dynamically typed > languages. And I say this even after considering PyCharm. The tools for > statically typed languages allow for safe refactorings, find usages, > definitions, automated documentation which is really sync'd with the code > and much more. > > above I was just trying to demonstrate how some problems that currently > use dynamic typing could easily be converted to be type stable, and hence > statically typed. Yes, with the solution that I demonstrated above, when > using a file name known only at runtime inside a function, you would have > to write down the expected types, which doesn't seem like too much effort: > > myvec = load_vector_from_hdf5_file(filename, vecname, Float64) > > But now you get the advantage that the following code would fail at > compile time: > > for i, v in enumerate(myvec) > println("element number "*string(i)*" is "*myvec[i]) > end > > Of course if you're using the repl you could just use the macro, or if you > want to do more automation at global scope just write a macro instead of a > function. > > Seems to me that the advantages of type stable inner scopes easily > outweighs the inconvenience of having to write a few rare types. Julia can > be really be the 1st interactive language with statically typed guarantees > and tooling. BTW With good enough tooling the IDE could suggest the HDF5 > vector type so in the long run this would represent really little cognitive > effort from the programmer. > > >
