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

I truly enjoy working on projects that includes both areas, interesting tech and woodwork :)

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

I still don’t understand how someone looked at that clause and did anything but giggle. I am always genuinely surprised when I encounter adults who think evil is well-defined enough for these purposes. Genuinely, I think this is a serious gap in my ability to empathize with other engineers and I am not sure what to do about it.

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)` ?

Julia is not object-oriented. If you want to dispatch on the type of action, you include it in the method signature.

Actually, callable structs are a common pattern in Julia, and are not in opposition to multiple dispatch.

You are probably thinking of dot-method syntax, like this

  object.action()

Might make it easier to dispatch on both the object and the action? Just a wild guess.

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

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)

> Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented.

Yes, and? That is how a port is.

When FastAI for swift was a thing (is it still a thing?) it was (is?) using Swift For TensorFlow, not PyTorch. https://www.fast.ai/2019/03/06/fastai-swift/

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.

The body of the post is similar in tone:

"Ah, whitespace. Another reason why Python is garbage. In a sane language scope delimiting is done with curly braces, or BEGIN and END keywords, or something similar."

Is tabs vs braces (vs spaces) relevant with current IDEs and linters which format code perfectly?

In short, No. Maybe when people had the same fight over vim/emacs back in the day.

so is this satire?

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