It is absolutely very much effort to specify the type when reading an hdf5
file. Simply because it may not be known at compile time.
By the way, the array dimension is in various applications also a dynamic
parameter not known at compile time. I once had to dispatch these
uncertainties to a template based C++ (image reconstruction) library. It
became a scary capsulated if/else construct that increased the compile time
by a factor of 10.
Julia gives me very much flexibility here and once the file is read, the
actual calculation is fast due type stable functions that are called.
Am Samstag, 3. Januar 2015 15:17:14 UTC+1 schrieb Ariel Keselman:
>
>
> 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.
>
>
>
