[DNF2]

If you are basically using finished code, your own code is mostly a top-level script, and you mainly need polished functionality and professional support, then Matlab toolboxes and support are very good.

But the language itself is primitive compared to OSS alternatives, so when you need to develop your own software on a larger scale, it falls short.

There is of course a sliding scale between 'user' and 'developer' in any language, but I think that the closer you are to the 'user' end of the scale, the better Matlab looks.

(BTW, I am a daily Matlab user, sorry to say.)

[galangalalgol]

I don't find the language primitive at all. It just has a poor deployment story that consists of "autogenerate to hidious unreadable c c++ cuda or vhdl, or writ it again yourself". It is amazing the autogen even works, which it really does, but that code...

But back to the language. I can typically do a line by line syntax change to get pytorch (julia is a but different but not too much). The resulting matlab sometimes runs faster too. If you avoid globals and write everything vectorized it is all really clean. OO code would be hidious, but I try not to use OO or goto in any language unless there is no other option. I like that arguments to a function are pass by reference unless you write to them, in which case it does a smart copy. Julia syntax looks different sometimes because you don't have to vectorize for performance as in matlab or python, in fact sometimes you shouldn't.

All in all, if the deployment story was solved, I probably wouldn't be trying out Julia. In fact I still prototype in Matlab before implementation in pytorch or julia, its just eaier to get that first thing working.

[DNF2]

Oh, Matlab is pretty bad.

Everything is a matrix, that's horrific (especially the Nx1 vs 1xN ambiguity which pops up all the time). No default argument values (and until recently, no support for keyword args, though they have a bad version now), meaning half your code lines are input parsing. Forced vectorization does the opposite of making code clean, it makes complicated code a lovecraftian mess (unlike Julia, which lets you vectorize efficiently at the top level.) Every function must live in an m-file(#$@&%*!) Everything in your path is in scope :(

The varargin/varargout/nargout mess, with outputs specified in the signature line, instead of proper return statements.

Also, for a language that requires vectorization for performance, there should really be a proper `map`, instead of the mess that is `arrayfun`/`cellfun`/`structfun`. Their arrays are super-limited, no mixed-element arrays (use cell-arrays!), so `[3, [4,5,6], 7]` is just concatenated, while `[3, [4;5;6], 7]` errors (and check out what `[3, "hello", 7]` does(!) or `[3, 'hello', 7]`)

Poor support for integers, 2 is a double(!), and `int8(3)/int8(2) == int8(2)` (yikes.)

Their OOP is actually not that bad, though it's slow. And their graphics system is pretty ok.

Also annoying: now you have two types of strings, old-fashioned 'abc', and new-fangled "abc", which are very different, and sort-of, half-way work together. Though I think moving to the new strings is actually a good move, but painful now.

[galangalalgol]

I want Nx1 and 1xN to act differently. It is a form of type safety. I would be fine with defaulting to Nx1x1...x1 as well and have everything be a tensor where you specify which side all the singleton dimensions proceed. Disagree, but they could do this better, matrix just happens to cover most cases.

I consder default arguments code smell in every language. Or really more foot-guns than code smell. I discourage them whenever anyone will listen. Disagree on this one.

Not super fond of kwargs either but they certainly have their place. If they are going to support it, they should do so well. Agreed

I actually prefer to read vectorized notation, I wish it was more consistently performant in Julia, sometimes the for loops run faster, but they take longer for me to read and understand. The exception is if there is an einsum in there somewhere, or the equivalent auto expansions in Matlab, that takes me a few. Personal preference I guess?

I've never come across a use for mixed arrays, but everytime I come across an api that returns them I begin cursing. Agreed

Typecast rounds instead of floors? That is kinda odd, but not wrong I guess? I haven't ever run across this because I use floor or round explicitly.

In 20 years ivrmever noticed the string thing. I'll jave to read about that, thanks!

[DNF2]

> I want Nx1 and 1xN to act differently.

Yes. Of course you do. The problem is, you never know what you are going to get. What you actually want is a vector, but Matlab has no such thing, so then you have to write your code in a way that anticipates either Nx1 or 1xN, and handle both. Sounds, simple enough, but I have a lot of code lines dedicated to checking and handling row/column orientation. If only there were real 1D vectors!

> I consder default arguments code smell in every language. Or really more foot-guns than code smell.

I don't really understand what you mean here, but the problem is that in Matlab you handle 'default arg values' with `if nargin < 5, par5 = default_value` etc. It's just worse, and it's perfectly idiomatic matlab.

> I actually prefer to read vectorized notation

My argument is actually that vectorization works much more cleanly in Julia. If in Matlab you have `foo`, which calls `bar` which calls `baz`, etc, then you must make sure that each of these explicitly can handle array inputs. You have to think about arrays on every level, including what happens with axis broadcasting (and probably checking 1xN vs Nx1 orientations on multiple levels). In Julia, on the other hand, you can write your functions `foo`, `bar` and `baz` to handle scalar arguments, and then you vectorize the whole thing with `foo.(args)`.

So vectorized code in Julia is much simpler to write, and also simpler to read. (Just to be clear: writing vectorized Matlab code and vectorized Julia code are things I do all day, every day, so I have a decent basis for comparison.)

> sometimes the for loops run faster, but they take longer for me to read and understand.

Loops vs broadcasting should be basically the same for performance, but sometimes you can get extra performance from a loop, by exploiting algorithmic advantages. But a simple vectorization is just a dot away.

> mixed arrays

It's something one generally tries to avoid, but they are often necessary for passing along arguments to inner functions etc. Tuples are great for this, but it doesn't exist in Matlab.

> Typecast rounds instead of floors?

It's odd, but I don't mind. Mainly, I am annoyed that integers are not well supported in Matlab.

> In 20 years ivrmever noticed the string thing

The "strings" are new, a couple of versions back. Of course, you will notice that "string" is actually a 1x1 matrix of strings, so length("hello") equals 1. And indexing into strings is actually indexing into the array of strings. So `str = "hello"` then `str(1)` returns the string itself, and `str(2)` errors.

[galangalalgol]

I don't want 1d vectors to exist, and ideally, I'd want everything to be infinite rank tensors with som clean notation for singletons x N or N x singletons or NxMx singletons etc. The dimension mismatch has caught more errors for me than I could ever possibly count. My functions don't check to see if something is scalar or columnar, I let the error tell the user their mistake. And using a column vector when a row vector is expected is a math error. And the same function usually works for scalar or vector or matrix for the most part.

I do like the dot notation and Julia in general, but I just don't have many complaints about Matlab. Auto expansion maybe. They do allow helper functions in the same file now, finally.

[DNF2]

Well, in many cases, dimension mismatch causes errors, not just lets you find them. And in fact, with the recently-ish introduced broadcasting behavior, you don't even get an error, just surprising dimensional-increasing behavior.

As for "math error", it often is nothing to do with that, you just want a list of values, what should such a list be? Column or row? And often, I'm the user, calling into other people's code that sometimes wants columns, sometimes rows, and behaves surprisingly different for each (sometimes with errors, sometimes not.)

There should be a convention in Matlab about whether fundamentally 1d structures should be columns or rows, but there isn't. (Just for example: reductions work down columns, except when the columns are length-1, while iteration only occurs along rows...)

This is a huge, huge problem in my daily work. I can give many examples, but am on my phone now.

Let me put it like this: if I could change only one single thing about Matlab, I would introduce a proper vector.

[systemvoltage]

Yep, 100% agree. The language is not that great.