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

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.

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

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.

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

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.

Cool post but kinda dated. It's not wrong as such but of it were written today I would expect a lot more context and depth around various aspects.

E.g. Apache Arrow.

E.g. Julia's constellation of different dataframe (Tables.jl) libraries that are mutually compatible.

E.g. efforts at standardizing dataframes in python.

E.g. tidyverse etc in R

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)

Window registry issues have been a thing.

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

Scientific and technical computing.

---

Not saying you can't do this stuff in rust. I mean its turing complete.

But contrast the description of Rust: A language empowering everyone to build reliable and efficient software.

vs Julia Julia is a high-level, high-performance dynamic language for technical computing.

Julia is for doing "technical computing". Things like simulations, problems where you need to apply a bunch of math. Its easy to write math in julia. The syntax is designed for it (like look at code for manipulating matrixes). The semantics are designed for it (multiple dispatch is the thing you need for efficient linear algebra for example. Specializing on each combination of matrixes)

Something like that is the idea. Silicon area is what costs money. Use as little as possible while still being fast enough to beat the clock-rate of your system. PSO's are way better than brute force. but yeah.

It was a purely academic work for a masters level CS unit. I had just finished a masters level electrical engineering unit on silicon circuit design. Where the final project was to design an adder that minimized silicon used (and thus cost) while also being faster enough. And the hard bit is that you want big thick doped regions for high conductivity, but also the bigger the area the more paracidic capacitance. And so there are some tricks the to find good sizes, like progressive sizing and stuff. But afaik there is no actual answer, at least not one we ever learned. So a lot of trial and error went into it. It was a hard project.

And so then I did this CS unit where the project was "Do something interesting with a particle swarm optimizer". And i was like "lets solve this". and once I saw the results, i was like "this is actually really good", and so the lecturer and I wrote a paper about it.

It is a real problem. Minimizing silicon area subject to speed. I bet the big integrated designers have there own tricks for it that i don't know about. To do it really well you need to miminal the real area so also need to solve layout (which is a cool cutting and packing problem). (and ther are also nth order effects, like running traces over things can cause slow downs, because electromagnetism reasons) I bet a bunch of folk on HN know this problem much better than i do though. probably something bad in my solution, but i think it illustrates the utility

fair enough. I can't say i've seen inside how things things are made. Julia definately has cutting edge for DEs. I doublt LTSpice does, but ORCAD etc might.

A modern circuit simulator, that has a fully featured programable API, that can be run from a real modern programming language, would be a dream. Every simulator i have used has been pretty limited in that way, or at least those features were not well advertized. Even the insanely expensive ones. I mean the most expensive ones (like $100K liscense type deals, like Cadence) are if anything even less modern from a user interaction perspective.

My first academic paper (https://www.oxinabox.net/publications/White2015PsoTransistor...) was based on doing a search over parameters for the transistors being used in a circuit. The way that whole thing work was by string mangling the netlist file to update the parameters. Triggering the simulator on the commandline. Getting it to output a CSV of the signals. Parsing that CSV, and detecting edges and then measuring timing that way. Then throwing it at a particle swarm optimizer to fine a new one. That sucks from a user experience. It's a super cool way to solve problems though. that would be so easy with a real API.

Further, with julia being a differnetiable programming language, rather than having to use a particular swarm optimizer to search, I could have been differentiating it, and using some sophisticated gradient descent like LBGFS etc.

I hope that some of the general tools like this will be an outcome of this project.

This seems very promising to me One big part of circuit simulation is solving differential equations. That's the whole inducer, resistor, capacitor thing. Julia has hands down the best toolkit for differential equation solving. Most circuit simulators today are going to be using old methods invented in the 60's-80's. Neglecting the state of the art developments.

Someone made a blog post recently comparing the time to simulate with LTSpice vs writng and solving the system in Julia https://klaff.github.io/LTSvDEQ_1.jl.html this is a very simple circuit, and they still got a 100x speed up. Sure that is neglecting the time it takes to actually extract the differnetial equetion from the circuit. But from what i hear that kind of thing is something this DARPA project will be working on. And sure LTSpice isn't state of the art. But still I find this indicative and promising.

Strong agree. I will use the command line for basics, commit, push, pull, simpler rebases.

But it I am going to be cherry picking a commit onto a backport branch, or splitting up one branch into two, or doing an interactive rebase, or (as said) committing some parts of s file but not others, I want a GUI