Julia Package Ecosystem Pulse
pkg.julialang.org
pkg.julialang.org
I recently attended a Software Carpentry instructor training session and witnessed a breakout between social scientists using R and natural sciences people using Python. Julia will have "made it" when orgs like SWC can start reasonably offering Julia sessions that draw both communities.
1. I really don't like how the entire standard library is included in the default namespace. I know this is how MATLAB does it, but my function names are constantly colliding with built-in ones.
2. The documentation is hard to navigate. I'm used to MSDN. Compared to that, providing huge pages of functions with a sentence or two of prose and no examples is not that helpful.
3. Plotting tools need work. Gadfly produces beautiful output but interactivity is weak (you can only zoom in on Y-axis) and it chokes when you tell it to plot a lot of data. It should downsample based on display resolution... I should be able to tell it to graph 100,000 points without crashing my browser.
I'm sure you know this, but the casual drive-by reader may not.
Functions with the same name aren't a collision. The parameter types of your function and a builtin of the same name all have to match in order for there to be a collision.
In julia "module" introduces a namespace: http://julia.readthedocs.org/en/latest/manual/modules/
> I really don't like how the entire standard library is included in the default namespace. I know this is how MATLAB does it, but my function names are constantly colliding with built-in ones.
This may not be obvious, but if you don't use a name from the standard library, then you are free to use it yourself since bindings imported by `using` are done lazily. For example:
julia> e = "some message"
"some message"
julia> Base.e
e = 2.7182818284590...
julia> println(e)
some message
julia> Base.e
e = 2.7182818284590...
On the other hand, if you don't assign to `e` then you can use the built-in definition of `e` like so (in a new session): julia> e
e = 2.7182818284590...
If you want to use both your own `e` and `Base.e` then you do need to qualify `Base.e` – but this is exactly the same in any other language – if you use the same name from two different namespaces, you have to qualify them. Making the standard library namespace smaller or more granular wouldn't help in any way.> The documentation is hard to navigate. I'm used to MSDN. Compared to that, providing huge pages of functions with a sentence or two of prose and no examples is not that helpful.
I definitely agree that our documentation isn't up to the standards of Microsoft. Pull requests are always welcomed and are a lovely way to give back. Over time the documentation will get better – I suspect we're already doing fairly well given the age of the language.
> Plotting tools need work. Gadfly produces beautiful output but interactivity is weak (you can only zoom in on Y-axis) and it chokes when you tell it to plot a lot of data. It should downsample based on display resolution... I should be able to tell it to graph 100,000 points without crashing my browser.
I'm curious what plotting system does actually let you plot 100,000 points without choking. Automatic downsampling would certainly be a nice advanced feature, but the mature plotting systems I'm familiar with do not do this. For example, neither R nor matplotlib do. Is there some Microsoft plotting library that does?
Datagraph for OS X handles ~1 million points without breaking a sweat, and it's an interactive GUI application.
Edit: For anyone who's interested, an indicative problem is this: http://stackoverflow.com/questions/21113030/async-thread-dea...
numba forces you into certain ways of writing code to achieve significant speed ups, but usually that's not too restrictive.
If you are used to writing numerical python code, you'll feel write at home in Julia - especially with the amazing PyCall module.
(alternatively, you might be able to use Python's asynccore module to create an asynchronous listener and yield back to Julia)
http://www.amazon.ca/Software-Ecosystem-Understanding-Indisp...
The word is ubiquitous now, but if you think about it, it's a bit of a funny way to refer to software, with allusions to predators, prey, producers, consumers, and population dynamics.
https://books.google.com/ngrams/graph?content=open+source&ca...
However, with data smoothing, it makes it appear is if the term existed before 1998:
https://books.google.com/ngrams/graph?content=open+source&ca...
http://julia.readthedocs.org/en/latest/manual/modules/?highl...
I haven't read up on Julia yet, so I'm curious.
I think this is clever in the abstract, but in practice, it's a lot of headache for very, very little gain and a lot of added confusion.
The main Julia team is a bunch of incredibly smart and dedicated guys who know a lot more about designing language than I do, but I think this was a case of trying to be too clever for your own good.
I think it's largely a matter of taste though! I just think that having a directory layout that reflects the code structure makes it easy to browse things at a glance, provided there's not too much magic in the __init__ files.
Julia's position so far has been that files and modules are entirely unrelated to one another. Modules are namespaces, and files are messy things on a disk. Hooray! You can organize your code however you want!
The problem is that I don't want to decide how to organize my code. I want to write the code to some best practices that have been thought up by someone who deeply understands their implications. Julia doesn't have these yet. I hope that it does one day.
Then there's the pattern of having a few large modules as opposed to many small ones; I can see how that would seem strange if you're used to a more object-oriented style, but it's pretty common in more functional languages.
You're right in that most projects include files into one large modules. Not every body like a it, but it does work for many codebases.
If you want however, nothing prevents you from having separate modules per files.You could also create hierarchical modules, and store the files in a matching heirarchy of directories.
As a young language, some programming patterns are still being experimented on by the purveyors of the language. But I don't think the module system is fundamentally weak in this respect.