cbkeller

Geologist here -- happy to answer any questions about this! The underlying paper [1] and the older one it builds on [2] are both open access. The rj-MCMC for the time-temperature inversion used an existing program from the thermochron community, but we made most of the figures in Julia.

[1] https://doi.org/10.1073/pnas.2118682119

[2] https://doi.org/10.1073/pnas.1804350116

It's true; I think this syntax was probably made more for reading than writing since the main place it appears in the base language is just `Meta.show_sexpr`, but it's still interesting to play around with, and parsing it has some fun properties like that you can use Julia's standard syntax as effectively a preprocessor syntax for the s-expression syntax.

As it happens, in addition to the femptolisp in the Julia parser, there is actually a secret s-expression syntax for Julia itself. There's no built in REPL mode for it, but you can hack one in about a dozen lines: https://gist.github.com/brenhinkeller/44051118c2f9d18b26dc76...

> I’m still not understanding this… why is it so hard to display the birthday date on the settings page?

I tend not to use debuggers very much myself so not speaking on a ton of expertise, but I think it's probably safe to say the Fortran ones are going to be a lot better on that front. There are a few options for debuggers so far, but no parallel ones that I know of yet.

I agree with you that Fortran is running on more than just legacy here. At the same time, I also think Julia has caught up a lot as far as SIMD, multicore, MPI and GPU.

For SIMD, Chris Elrod's LoopVectorization.jl [1] is an (IMHO) incredibly impressive piece of work (which incidentally provides the foundation for I think the first pure Julia linear algebra library competitive with BLAS).

Multithreading is pretty easy with things like `@spawn`/`@sync` and `@threads for` in the base language, as well as super low-overhead multithreading from the Polyester.jl [2] package (which LoopVectorization also uses to provide a version its vectorization macro that'll also multithread your loops in addition to SIMD-vectorizing them).

MPI.jl [3] has been totally problem free for me, though I wouldn't be surprised if the Fortran bindings still have an edge somewhere, and Cuda.jl [4] seems to provide pretty seamless GPU support which should play nicely with MPI.jl's Cuda-aware MPI [5], but I don't work as much with GPUs myself.

[1] https://github.com/JuliaSIMD/LoopVectorization.jl

[2] https://github.com/JuliaSIMD/Polyester.jl

[3] https://github.com/JuliaParallel/MPI.jl

[4] https://github.com/JuliaGPU/CUDA.jl

[5] https://juliaparallel.github.io/MPI.jl/latest/usage/#CUDA-aw...

> Even in Julia.

Unless you're using [Octavian.jl](https://github.com/JuliaLinearAlgebra/Octavian.jl) or such for your linear algebra in place of BLAS. But yes, it is always interesting how many people do not know how much of modern software is built on Fortran!

Ah, gotcha, fair

I feel like if you're going to go monorepo in Julia (which I'm not sure I would, personally), you'd at least want to have multiple modules in that repo. Then you can run tests separately for each module, etc.

> But personally I find OOP ugly and unnatural, and Julia's model elegant and natural.

This definitely fits with my experience. It took me quite a while to really "get" dispatch-oriented programming as a paradigm, but once I started to get it there was no going back.

Yeah, it would definitely be technically possible to build some sort of editor tab-complete for methods of a type ala `methodswith` or etc., someone would just have to step up and build it. The lack of this sort of method autocomplete tooling hasn’t ever been a pain point for me, but evidently is for some.

I haven't seen it done yet, but in principle someone could probably write an editor plugin that gives some sort of autocomplete for method discovery in Julia based on `methodswith` or similar, which would be a nice thing to have!

> "Embrace, extend, extinguish" isn't real and has never happened. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... is full of examples that failed and not a single one that succeeded.

How on Earth did you reach that conclusion? A trivial look at that list:

* Web browsers. -- Worked so well that IE remained the dominant browser for over a decade [1]. Of course, bundling was important here too but without the intentional incompatibilities between IE and Netscape, bundling alone would not have been nearly as effective.

* Office documents. -- Despite .docx files being notionally based on an open standard, to this day, Microsoft office will frequently reject as "corrupted" .docx files that have been edited using other implementations of the OOXML standard (in my experience, particularly when tracked changes are enabled or images are involved). In most such cases in my experience, the sentiment from coworkers is "why don't you just install Word" --- so apparently still working as intended.

* Instant messaging -- seems to have worked pretty well at the time [2] and remained popular for nearly a decade. And while they later lost marketshare to transformationally different technologies (texting, mobile messaging), the competitors against which they used the strategy remain dead.

* Against Java -- Led to major legal action, in which Microsoft was forced to pay Sun >$2B and agree to discontinue the practice in settlements, presumably only because by now people were catching on to the strategy. Failing that, Microsoft just made a separate competing language for cross-platform (AKA "write once run anywhere" :) development and called it.... .NET [3]

> And it's strictly better than Microsoft spending their time enhancing closed-source software, no? That was my question at the end: they could make .NET closed-source

Presumably it is reasonable to assume that they would like to grow the market share of .NET. While more open code is usually good, I would indeed not consider it "strictly better" if their goal in this work is to capture market share against other languages by leveraging the popularity and community that comes with "Open Source", while leaving them in a position where they can then reassert hegemonic control over their language via exactly the pathway being discussed here.

[1] https://en.wikipedia.org/wiki/Browser_wars#First_Browser_War...

[2] https://www.nplusonemag.com/issue-19/essays/chat-wars/

[3] The tagline on https://dotnet.microsoft.com is currently "Free. Cross-platform. Open source." The "Open Source" part of course only added somewhat more recently after the closed-source version failed to dethrone Java. Not that I like Java so much or anything, but you get the point.

The Folds.jl package [1] mentioned in the article is very nicely written, IMHO.

For another alternative to Julia's built-in `Threads.@threads` macro, folks may also be interested in checking out `@batch` from Polyester.jl [2] (formerly CheapThreads.jl), which features particularly low-overhead threading.

[1] https://github.com/JuliaFolds/Folds.jl

[2] https://github.com/JuliaSIMD/Polyester.jl

A closed-source application (dare I say, _extension_) that provides some enhancement to some existing open-source software… How is this at all distinguishable from the second step someone would take in an “embrace, extend, extinguish” strategy?

A bit of googling turns up [1][2], but [2] doesn't seem to have much recent activity (presumably in turn due to Google ceasing active development of S4TF [3]

[1] https://www.fast.ai/2019/03/06/fastai-swift/

[2] https://github.com/fastai/swiftai

[3] https://github.com/tensorflow/swift

Looking forward to trying this out!

Yep!

  help?> Base.Experimental.@optlevel
    Experimental.@optlevel n::Int

    Set the optimization level (equivalent to the -O command line argument) for code in
    the current module. Submodules inherit the setting of their parent module.

    Supported values are 0, 1, 2, and 3.

    The effective optimization level is the minimum of that specified on the command line
    and in per-module settings.

Hopefully eventually

It should be faster for higher-order AD, among other things. Keno talked about some of the theory in [1], but also has a Juliacon presentation later this week.

[1] https://www.youtube.com/watch?v=mQnSRfseu0c

Oh interesting. That would work too, but `*` is really quite nice in the context that string concatenation is properly the associative binary operation of a free monoid.

This is one of the cases where there's sometimes confusion between the semantics of Julia as a language and the practical implementation of Julia -- just like how Julia is dynamically typed as a matter of language semantics, but compiles to a statically-typed intermediate representation as an implementation detail [1].

While it is not part of the language semantics, there certainly is, in the current implementation, a time at which any given method in Julia is (JAOT) compiled (via SSA-form IR, LLVM IR, and finally to native machine code) -- and whether or not types are able to be inferred at this time is sufficiently important that it has its own name: type stability [e.g., 2], with type-stable code being generally a couple orders of magnitude faster than equivalent type-unstable code.

[1] https://stackoverflow.com/questions/28078089/is-julia-dynami...

[2] https://www.juliabloggers.com/writing-type-stable-julia-code...

Oh, I see -- yes, fair enough!

Composability is one of the things the Julia community generally Takes Seriouslyᵀᴹ so definitely don't hesitate to ask if there are two packages that don't play as nicely as you would like!

I'm a bit confused still though why you say it's a "missing" feature, given that as we discussed above, there is absolutely nothing to stop anyone who wants to use the "Python OOP" style of namespacing in Julia from doing so? Most of us don't seem to find it necessary or to prefer it personally, but that doesn't restrict anyone else from choosing it.

Do you have an example of a case where you ran into this in Julia with two packages that you wanted to use together? If the packages are still actively developed, I suspect the developers would be interested to resolve the situation to allow interop.

In Julia it will just dispatch to the correct function.

In other words, one package would define `fit(mymodel::TensorFlowModel)` and the other would define `fit(mymodel:PyTorchModel)`, and then when you call `fit` it'll just dispatch to the appropriate one depending on the type of `mymodel`.

This dispatch-oriented style also allows a shocking degree of composability, e.g. [1], where a lot of packages will just work together, such that you could for example just use the equivalent of PyTorch or TensorFlow on the equivalent of (e.g.) NumPy arrays without having to convert anything.

If you mean "what about the case where both packages just call their model type `Model`", while I've never run into that, the worst case scenario is just that you have to fall back to the Python style explicit Module.function usage (which was always allowed anyways...). And if you if you don't like names being exported, you can always just `import` a package instead of `using` it:

  help?> import
  search: import

  import

  import Foo will load the module or package Foo. Names from the imported Foo module can
  be accessed with dot syntax (e.g. Foo.foo to access the name foo). See the manual
  section about modules for details.

[1] https://www.youtube.com/watch?v=kc9HwsxE1OY

Yes indeed. While Julia does generally eschew the "model.fit(X,Y); model.predict(new_data)" style, it's not because it's functional, it's because it's dispatch-oriented, which is arguably a superset of class-based OO, and even perhaps arguably closer to Alan Kay's claimed original vision for OO than modern class-based OO is.

While you have a valid perspective, the HN guidelines [1] do specifically ask us to assume good faith.

[1] https://news.ycombinator.com/newsguidelines.html

Composability via dispatch-oriented programming, e.g. [1]

It also pretty much solved my version of the two-language problem, but that means different things to different people so ymmv.

[1] https://www.youtube.com/watch?v=kc9HwsxE1OY

In particular, Dylan was one of only a few other languages to Take Multiple Dispatch Seriouslyᵀᴹ