This is amazingly field dependent.
I am from a field where you only cite the most significant tools you use (Machine Learning).
E.g. "We implemented this with a neural network build with TensorFlow (cite). We augmented the data using skew tranforms from Augumentor.jl"
But the convention of other fields is to recursively cite all software that is loaded by your experimental code.
And is strictly required by their journals.
and I am not one to tell other fields what their conventions should be.
Especially not when they give more credit.
> in my days at Amazon Web Services, I saw exactly zero instances of major service releases that, in the opinion of customers, crippled or broke the product. ... the PM could go talk to them and bounce improvement ideas off them. Customers are pretty good at spotting UX goofs in the making.
AWS really does like to "bounce ideas" off customers.
To the extent that I am wondering if we should start billing them for consulting services.
A hour long meeting every other month with 3-4 senior team members adds up.
You can't do it with license.
It causes more harm than it prevents.
See how this played out with the JSON License
https://lwn.net/Articles/707510/
We can assume: noone evil took heed -- because they are evil.
The good on the other hand stood by their principles that even the evil should have free software; and so didn't use it.
Thus causing suffering until it was reimplemented.
My particular prediction for Machine Learning and Data Science is its going to become less and less Python vs R vs Julia.
and more like the situation we have for for web-servers.
Where basically every language has a solid quality webserver.
And like how now if your focus as a company (etc) is on webstuff you'll use Node or something with a excellent webserver and will hire accordingly,
but if you've got a big team that already uses java to make the desktop application, then you are not going to switch to Node (etc) for your new web offering: you will use the also very good TomCat or Jetty.
Similar if you focus on complex modelling you'll use Julia/Python for that and you will just use their webserver libraries to expose it.
The other way round will also occur (and definately already has started but i expect it to be more and more the case.)
You are a web-company wanting to do some ML on some data you won't even think of having a seperate Python/R/Julia program, you will just use the Node equivs (which I am sure today are good, but I don't know them).
Similar for the desktop applications in Java or C# they will just use their own ML / Data Science libraries.
And just like there is indeed a role for specialized web servers like Node, there will still be case where you do want to pull out the big guns and move over to Python/R/Julia.
but those will become rarer and rarer.
I guess you could say it is commoditization of ML/Data Science libraries.
I think particular nice thing about this is that it is a bundle of nice libraries integrated together well, with nice docs.
Those libraries in turn also break down into other nice libraries and so forth (but many don't have does quite this nice) because that is how Julia is.
I can't seem myself ever using FastAI.jl (though I am sure many will).
But I absolutely can see myself using Flux + FluxTraining.jl which nicely brings together TensorBoardLogger and EarlyStopping and several other things.
(https://github.com/FluxML/FluxTraining.jl)
And I can well imagine many will use DataLoaders.jl + Flux.
I feel like this project has nicely rounded out the ecosystem.
Making standard tools where before there were a bunch of individual solutions per project.
(Like I currently do use TensorBoardLogger + Flux directly with my own custom training loop)
Claiming a language is bad such click-bait.
Even when it is valid, it basically will get a lot of attention from haters and fanboys.
It's not a title that leads to interesting discussion.
> it's almost indistinguishable from base R (when you're calling it).
I am very surprised by this.
Given how R is extremely dynamic.
and has things like lazy-evaluation, that you can rewrite before it is called with substitute.
Which I am sure some packages are using in scary and beautiful ways.
Citation for this?
Julia has had a built-in interpretted since 1.0, in 2017
use `--compile=min`, or `--compile=none` to make use of it.
And JuliaInterpretter.jl has been working since 2018.
Both are very slow -- slower than adding in the compile time for most applications.
As I understand it, this is because a number of things in how the language works are predicated on having a optimizing JIT compiler.
As is how the standard library and basically all packages are written.
Julia is going to over time become nicer for scripting, just because of various improvements.
In particular, I put more hope on caching native code than on any new interpreter.
Mostly because, without us really thinking about it, implicitly it was predicated on the premise that the founders would remain largely unemployed for about 6-12 months.
Even through we were looking for work.
And so when most of us found jobs in that time noone really had energy or time for this stuff on the side.
We explicitly determined one day a week to work on this. And kept it up for a while even after people got work.
I was the first to get work and for a while (maybe 3-6 months) I was putting in 5 days on my day job and then 1 more on this.
At some point I quit and formally gifted my share of assets to the other founders (it wasn't really much, we each put in like $100 at the start).
I think it was fully wound up about a year later.
Paid back most of a small arts grant we hadn't managed to spend to the NFP that gave it to us.
For most intents and purposes one can use a (potentially Singleton) type passed as a argument to functions instead of a module containing functions.
And doing that gets you all the tooling and power you could want.
(But probably in a different way to you want it).
Since multiple dispatch takes care of that.
You can compare and contrast MLDatasets.jl (uses submodule per dataset) vs CorpusLoaders.jl (uses a extra type argument per dataset)
I have heard it is to do with how windows antivirus works.
Since the registry is like 10,000 seperate files.
It chokes on them.
I have heard there is an upcoming feature to allow the package manager to work with the registry being kept inside a tarball, which is specifically being added to deal with this
Since 0.7 (which was 1.0 with deprecations)
In julia 0.6 and before it was exactly as bad as described.
(though there were things like Playground.jl to kind of work around it)
> This is not my experience. Even if you code without caring about performance it is way faster than Python.
It is very usecase dependant.
If your Python code is writing lots of loops and scalar processing then naive julia code will trash it.
but if it is basically spending all its time in numpy/BLAS routines then they will be comparable.
and Julia will looks like its not worth it, since compile time makes it overall slower etc.
> Also, it is not any harder to code in than Python.
If you already know Python then it is easier to use what you know.
Furthemore, if you already know Python (or even more so Matlab) it can cause some stumbling blocks.
Some idiomatic code in other languages, (like writing everything as big array operations), is unidiomatic in julia
(since it causes a lot of allocations tht you don't need)
> Your observations in V.B.4 are pretty well understood in circuit design.
Indeed, I am actually surprised the paper doesn't include something like _"This is inline with the well known result for progressive sizing [cites textbook]"_.
It was my first paper, i was worse at writing things then.
:-D
> One thing your analysis didn't include, which actually ends up being quite significant, is the extra capacitance caused by the wires between transistors. This changes the sizing requirements substantially.
Good point. And not easy to model in a SPICE style simulator.
I guess one could maybe introduce explict capacitors and them compute capacitiances by making some assimptions about layout.
1. yeah these are super expensive. Even the cheaper ones are close to a grand a liscense
2. definately got to have a front-end. Writing netlist by hand is suffering.
3. Interestingly (to me) the components are more or less portable between them. With only a little manual writing i have translated components from ORCAd p-spice, to ISpice, to LTSpice. No idea on the liscensing for that. (I suspect the IC manufacturers produce these)
I think speed is very much a question of what kind of thing you are doing.
I agree it often doesn't matter.
and without your 3 points, it certainly doesn't matter
But the convention of other fields is to recursively cite all software that is loaded by your experimental code. And is strictly required by their journals.
and I am not one to tell other fields what their conventions should be. Especially not when they give more credit.