520 karma · joined April 9, 2016
>Watch how the ultra-wealthy in America gradually raised the taxes of the poor and eventually bent the curve downward until they paid the lowest tax rate of all
I just run my code in small batches while developing it, so at every point I already know that it works. This helps writing code that nicely separates into small chunks of functionality, and you basically automatically write tests for it while at it.
This is especially nice when refactoring a large code base. I can already run many small and usable tests in the middle of a refactor (while the program wouldn't even compile in a static language).
In my experience, this greatly helps to improve the quality of the refactor, and makes it much easier to see problems in your refactoring approach very early on.
In a static language, you'd only get these crucial insights after you're done with fixing all compilation errors - which is usually when you're already done with the whole refactor... and after that, you might still have lots of errors in it that you can only find with real tests ;)
That's a pretty weird statement, considering how hard it is to write a complex C++ program error free. I suppose Swift is much better in this regard - But compared to C++, Julia is a bliss and one can easily write huge applications error free, while I had my absolute worst debugging experiences in C++, where it's very easy to create obscure and hard to find bugs.
If you really need to get predictable results and actually know those results - you won't get away with a static type checker anyways, but will have to write & run tests, which then pretty much make it irrelevant whether your language is dynamic or not.
You either need to change the semantic of the language (CPython) or live with a slow JIT for some of the most used features of the language... And changing the semantic of the language is pretty terrible - it fragments your libraries introduces unbreakable borders prohibiting cross package optimizations and extensability, and much worse, CPython is now basically a language that combines the bad stuff of python and C ;) I know, that's a bit too cynical, but coming from a well designed language for JIT (Julia), that's how CPython starts looking to me. You will simply never reach the elegance of a language that was designed from scratch for this.
What I want to point out is, that the whole topic is bigger than "JIT my one slow function and make it fast"! A good read about this topic is: http://www.stochasticlifestyle.com/why-numba-and-cython-are-...
https://github.com/JuliaGPU/GPUArrays.jl/blob/master/src/lin...
Or directly with cuda shfl intrinsics: https://github.com/JuliaGPU/CUDAnative.jl/blob/b249dfd145501...
So the part that gets loaded when you load the language/compiler is what is referred to as Base. So, it's kind of impossible to not have it and it is part of the language. So it's somewhat like asking, what can you do without "importing" integers? (ok, that's a hyperbole, but you get the idea ;) ) But, the source code does get shipped, so you might actually go in there and change stuff if you want, and Julia will pick up those changes - even, to get back to that hyperbole, how integers are defined, since they're implemented in pure Julia. I'm not a 100% sure what you're aiming at, but does that answer your question? ;)
To add some more historical facts to this: before broadcast, we mostly used maps & zips in Julia. Which is not very elegant if you want to write down your math. Even with broadcast, some math nuts still complain that it isn't close enough to the actual math :D So consider, that those people are Julia's user base ;)
And then, someone pretty much implemented broadcast in their freetime and added it as a PR to the Julia language. This is how the language grows, and a large part of that is possible, because it takes relatively little time to come up with a performant implementation of such a difficult problem.
And now we have broadcasting in the language, and maps + zips are indeed less idiomatic... Because anyone who started using the new broadcast immediately thought it was an improvement to "the old ways".
Actually, your sample "solution" is (was?) also a much used pattern in Julia - especially before we had such a powerful broadcast implementation.
So in Julia there is no need either, since it is already implemented much better in Base. I think you're overlooking the actual point of my challenge: it's not that we need a broadcast package, but that a lot of other scientific libraries will need to use similar patterns, to write new packages with new algorithms!
The point is also, that I can go into the Julia repository, and without a lot of time & effort, can improve the current implementation of our broadcast - because it is not that much code and pretty easy to follow.
So, an equivalent in your example would be, if you can quickly implement something like repa or folds in a similar minimal example like my Julia implementation.
If you don't like the details of my challenge, feel free to make a minimal folds implementation from scratch, and show me that the result is fast and composable ;)
I do think, that it is quite showing, that google + tensorflow don't believe in the mix of python + c/c++. I've been working quite closely on the challenges that faces machine learning libraries at the moment, and I can totally see where they're coming from when they're unhappy with the current solution and want to rewrite it in swift. How should I express this in a better way?
You understood that right, it is not :) That's why I wrote, that I'd probably need years to create the same implementation in any other language.
I do think it does have a widespread implication for the ecosystem though, and therefore at some point will also be relevant to newcomers.