oxinabox

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.

I love how this read me is as much about woodwork as it is about software

> 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.

Right, can't to abstract callable overloads in older versions of julia

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.

Why does Javis use `act!(object, action)` rather than making actions callable structs so you could do `action(object)` ?

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.

> For scripting, interpreted Julia is coming.

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.