OT: Your accomplishments in 2013 and plans for 2014

[Joseph Rushton Wakeling]

On 12/12/13 01:56, bearophile wrote:
> Look better, Julia aims also at partially replacing Python as golden glue in
> scientific computing, and it seems to have some of the numbers for it. It's
> statically typed, it has type inferencing, a refined type system with
> multi-methods and more, and a good LLVM-based JIT (that's in my benchmarks
> produces a performance no more than 2-4 times slower than D compiled with ldc2.
> If you compile D with dmd Julia is often faster for FP-heavy code. This means
> it's much faster than any Python code).

Is that taking into account stuff like NumPy/SciPy which is C underneath and 
(according to colleagues who use it; I don't) super-fast?

> It's better than Matlab about as much as  D is better than C, and it's already
> better than Python for some things :-) And Julia is currently much more
> flexible than D (there's a REPL, lot of scientific routines in the std lib, and
> the JIT). In two years its easy to write code has allowed lot of people to
> write more standard library than D community has done in 7 years.

Interesting.  I did take a look at Julia after discovering that a colleague used 
it; it certainly has many friendly features, but I found myself worrying that 
some of the "easy" mathematical notation might very readily lend itself to 
unfortunate typos that in turn would generate bugs and wrong results.

That said, when it comes to stuff like MATLAB/Octave you are often not writing 
extended code bases but short and easy stuff for data analysis, so there is much 
less need for concern over this kind of thing.  I imagine the same might apply 
to Julia, which at the same time looks like it should make it easier to develop 
larger-scale stuff if it's wanted, despite the things I'm worried about.