DNF2

If you click on the timestamp ("17 minutes ago"), then you will be able to reply below the post.

OK, I don't know that person's situation then, and cannot speak to it. But bullying is definitely against the community guidelines, and my experience is that there's not a high tolerance for rudeness, in fact I think the community is quite conflict shy.

That this happens with some frequency is a pretty big surprise to me, as I said, I follow the community closely.

Is it possible that you know only one side of the story?

I don't know anyone else who got kicked out (that takes a lot). But I know of a situation where someone walked out due to a non-political disagreement. Perhaps that's the one.

I follow the community pretty closely, posters being banned (except pure spam accounts) is something I think I'd notice.

Besides, what can you do if someone walks away from an important package? Should everyone, including collaborators on that package just start from scratch? What?

There's only one person who's been kicked out of the community (in the sense of being banned from the discourse forum), and that was not due to 'political beliefs', but repeated abuse and personal attacks.

Anyway, how can anyone 'take control' of someone's repositories? Was this person kicked out of github too?

I thought you could strip out LLVM now? I don't really know, it's above my pay grade.

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.

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

This part of your criticism seems quite disingenuous. You're simultaneously criticizing them for not improving their code quickly enough, and for changing it too much.

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.

It _does_!

It is quite likely that you have fallen afoul of some of the standard performance 'gotchas', like non-const globals or inadvertently creating type instabilities. Have you consulted the Performance tips?: https://docs.julialang.org/en/v1/manual/performance-tips/

Efficient Julia code should normally look simple and elegant, not 'ugly' (unless you are going into deep optimizations, like manual simd, or some times heavy reliance on in-place operations.)

I think calling it 'deceptive' is problematic. Of course you can write slow code in Julia, like in any language, but did you write code that you think should be fast, but wasn't?

> I don't buy "it's compiling at run time" argument, since other (interpreted) languages do not have this problem.

I'm a bit confused by that statement. Compiled languages have to compile, interpreted don't. What did you mean here?

I'm not experienced with the SciML ecosystem, but they have apparently put huge efforts into improving compilation lag, and this has been going on for quite some time: https://twitter.com/ChrisRackauckas/status/15612780920433254...

Quote: "Coming very soon: a version of DifferentialEquations.jl that fully precompiles the solvers on Vector{Float64}, virtually eliminating the any #julialang #sciml JIT lag."

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

What do you mean? Are you praising them by making the comparison, or saying they are plagiarized?

I really think you should clarify.

Then you should specify. You made a blanket statement about performance, while using the least commonly considered type. If you just say 'performance', most people will assume you mean throughput.

This seems like some sort of magical thinking. Some random person uses a particular word in a personal blog post (there's nothing official about this), and somehow this influences the technical merits of the subject of the blog post.

Can you explain the causal connection here?

You seem to confuse performance and latency. High performance is Julia's main selling point. Latency is its Achilles heel.

It's being very actively worked on however.

No, this is not the fundamental meaning of an index, it is simply the interpretation that you are using to make it easier to deal with for you personally. In my opinion, the fundamental meaning of an index is a number referring to element number `n`, so that `a[1]` is the first element, etc. But I don't begrudge you your working definition.

For some reason, people who are used to 1-based indexing generally recognize that both interpretations are perfectly fine, and that each works well in different contexts. For some other reason, people used to 0-based indexing feel so intellectually superior that they are unable to see the other side of the argument.

The starting offset is encoded in the type domain, btw, and accessible with the `firstindex` function.

But you will still want to calculate indices at runtime, and then out-of-bounds errors will have to be caught at runtime anyway.

That means disallowing indexing with integers, I presume? Since an integer can take the values 0 or 1 equally. And what about the other end of the array. Must every index be restricted by type to be located in the acceptable range?

There are good arguments for using either 0- or 1-based indices. As you should be aware, there are many languages on each side.

While preferring one over the other is perfectly fine, I question the intellectual honesty of anyone claiming incredulity about opposite choice.

How would static types help with that? Whether your indexing range starts with zero or one or something else isn't necessarily encoded in the type domain. `1:length(A)` is just a range of `Int`s.

What do you mean by 'mistake'? How are the Julia devs going to stop someone from defining arrays with configurable indices?

Are you suggesting that the core language should somehow make this impossible? How?

I use Matlab daily, and the plotting is indeed excellent.

But the language itself is a horrible kludgy mess. Most of the development time is spent on input parsing and contorting your code into a vectorized shape.

If Julia followed your recommendation, it would be irrelevant before it ever started.

There is no way for a new language to be useful or relevant unless it brings significant improvements.

But it's not a matter of language design. The 'choose your own indexing' is something you do entirely in libraries.

You can create your own indexing in python too, it will just be slow. The 'sin' of Julia is that it will be fast...

Agreed, one cannot just expect this to be known.

Does type annotations in Python actually catch type errors? I thought they were mainly for documentation.

So you live in a world where there's a fixed number of built-in types hard-coded into your library?

I'm afraid that doesn't cut it in a modern programming context.

First of all, Julia does have union types. But how does that help when the caller gives you a user-defined type?

You list some reasonable criticisms, but how is 'immutable structs are more performant' a valid criticism? That's just because compilers can do more optimizations with immutables. Unless you want immutables to be intentionally hobbled, what exactly do you expect the Julia devs to do about it?

Multiple dispatch with external methods isn't a 'feature' of Julia, it is the central organizing principle that the whole language is built on. And among everyone who actually uses the language there is consensus that it is what makes it good.

Sorry to hear that you failed to implement it back in the day, but that doesn't mean there's anything wrong with multiple dispatch in and of itself. It's just hard to get right. But when it works, it is without doubt the best paradigm for a language that I can think of.

BTW, optional arguments are not 'absent' in Julia, they are absolutely present, and are, in fact, implemented using multiple dispatch.