hatmatrix

A lot of the early, absolute advantages of Fortran (numerical precision, non-aliasing) has been adopted by C.

However what still makes it a great choice is that it still a relatively simple language compared to C, and maps mathematical formulas to code very well. Inelegant code will still run reasonably fast (which is not the true with C) - so all of these points make it actually a good language when the program is being written by domain experts (i.e., scientists) rather than professional programmers or software engineers.

But doesn't this reduce the required amount of farmland?

Don't most researchers fall into this category?

Julia's Tidier.jl ecosystem is getting there too. It uses macros to mimic this 'special' evaluation framework of R, so the code is also readable in a similar way.

There was XLISP-STAT before R, but the scientists have spoken. They don't like the parentheses.

cries in org-mode

Do you have an idea whether these are specific types of problems that is giving Julia poorer performance? From what I recall, people were reporting better speeds with Julia than with Numba (e.g., [1]). My impression was that you are basically able to bring more of your code to LLVM with Julia than Numba, so it would make sense.

[1] https://gerritnowald.wordpress.com/2022/10/03/simulating-rot...

That study must have compared beginners in LaTeX and MS Word. There is a learning curve, but LaTeX will often save more time in the end.

It is an old language though. LaTeX is the macro system on top of TeX, but now you can write markdown or org-mode (or orgdown) and generate LaTeX -> PDF via pandoc/org-mode. Maybe this is the level of abstraction we should be targeting. Though currently, you still need to drop into LaTeX for very specific fine-tuning.

Yeah I started using GitLab for the same reason and also that FSF "approved" of its CE version. But doesn't hosting private repos on GitLab and using public repos on GitHub just give GitHub that much more monetizable value?

But then you lose the readability that is the core defense of MATLAB/Octave. Ok so NumPy is readable, but less pleasantly so.

It's one of those languages that outgrew its original purpose, as did Python IMHO. So non-matrix operations like string processing and manipulation of data structures like tables (surprisingly, graphs are not bad) become unwieldy in MATLAB - much like Python's syntax becomes unwieldy in array calculations, as illustrated in the original post.

An understated advantage of Julia over MATLAB is the use of brackets over parentheses for array slicing, which improves readability even further.

The most cogent argument for the use of parentheses for array slicing (which derives from Fortran, another language that I love) is that it can be thought of as a lookup table, but in practice it's useful to immediately identify if you are calling a function or slicing an array.

Indeed, there are many high-quality alternatives (sometimes described as "MATLAB clones" back in the day) that never gained bigger traction.

Among modern alternatives that don't strictly follow MATLAB syntax, Julia has the biggest mindshare now?

GNU Octave, as a superset of the MATLAB language, was (is) most capable of running existing MATLAB code. While Octave implemented some solvers better than MATLAB, the former just could not replicate a large enough portion of the latter's functionality that many scientists/engineers were unable to fully commit to it. I wonder whether runmat.org would run up against this same problem.

The other killer app of MATLAB is Simulink, which to my knowledge is not replicated in any other open source ecosystem.

What's the business model?

fft.m is the more obvious example of the closed source algorithm here. You open it and it just says

% Built-in function.

The algorithms written in C and compiled by mex are the "built-in" ones that are not viewable.

How about fft? If you open fft.m, you get just a commented file that ends with

% Built-in function.

If the algorithm is implemented as a compiled mex function, then you cannot inspect its details.

The move to USB-C is actually great for compatibility across machines. Europe has a directive for companies to implement USB-C to reduce e-waste from chargers.

It's worth considering what nextgen really would be, but probably VSCode and its forks will dominate for the time being. I recall Steve Yegge predicting that the next IDE to beat be the web browser, and this was around 2008 or so. It's not the reality, but took about 10-15 years for it to actually happen, even though there were earlier shots at it by like Atom.

There is an AI-integrated IDE called Erdos...

https://www.lotas.ai/erdos

What are some difference between the education tooling around Racket and that which enables "industrial" applications Common Lisp is known for?

As for the tooling, julia-snail on emacs is supposed to be like SLIME for Lisp. But sounds like that isn't your main gripe. Having to load so many packages is a indeed a pain, but it does suggest the core language is rather minimal...

Does this also apply to commutative operations in general?

Do we have enough rare earth metals to provide storage for the AI boom?

It doesn't happen so frequently in practice, which is maybe why it's not felt equally by everyone in the community. I've followed some discussions on this topic and the current solution is, as you say, to place the onus entirely on the user. There is another faction that wants to support the user through the IDE to warn them of errors they might be making, and others that want to implement formal specifications that catch the errors during specifications. It's not an easy problem to fix and therefore the "simplest approach" as you describe remains the leading solution.

In this debate there seems to be a pervasive impulse to point out "that specific problem doesn't exist anymore," and to their credit the developers are generally good at responding to serious problems.

However, the spirit of the original post was about the lack of safeguards and cohesive direction by the community to find ways to preempt such errors. It's not an easy problem to solve since Julia's composability and flexibility adds complexity not encountered in other languages. The current solution is, 'users beware', while there are a few people working on ways to enforce correct composability. I think it's best to acknowledge that this is an ongoing issue and that it's not a problem anymore because the specific ones pointed out are fixed.

I should have been more precise in my language - it's not numerical correctness but composability correctness. They won't appear in a simple example like the one you provided, but more complicated ones are provided in the original post - in the example it partially centers around how getindex should be used with a particular struct and so on.

True, actually they are good in following up on numerical correctness, so I should be rephrase 'correctness in computation' to 'correctness in composition' - the types of bugs that arise from mashing a lot of modules together. On the one hand it's not a Julia issue but a package ecosystem issue.

I think you're actually even more active in the Julia community so maybe I don't have to summarize the debate but these are the types of traits and interface packages being developed that are meant to formalize how modules can be used and extended by others.

https://github.com/rafaqz/Interfaces.jl

https://discourse.julialang.org/t/interfaces-traits-in-julia...

> one author's algorithm can be composed with another author's custom data type

This is true, and it's a powerful part of the language - but you can implement it incorrectly when you compose elements together that expect some attributes from the custom data type. There is no way to formally enforce that, so you can end up with correctness bugs.

The greater issue that there is still no way to prevent those types of composability bugs.

I say this as a huge Julia fan, but the point is not the specific bugs in the article, but the culture of not prioritizing correctness in computation. The initial response by many (not all) in the community was look, those specific bugs are fixed; all languages have bugs; more importantly - look at the benchmark speeds of these computations! Which only reinforced this negative perception.

My understanding is that it's a difficult problem to solve, and there are people working on traits/interfaces - but these are still peripheral projects and not part of the core mission to my knowledge. In practice, composability problems arise seldomly, but there is no formal way to guard against it yet. I believe there was some work done at Northeastern U. [1] toward this goal but it's still up to the user to "be careful", essentially.

[1] https://repository.library.northeastern.edu/files/neu:4f20cn...