2 ms·

> In regards to you the use of brackets, array indexing and function calls can use the same syntax: lisp and scala seem to manage just fine. There's a lot of un

> In regards to you the use of brackets, array indexing and function calls can use the same syntax: lisp and scala seem to manage just fine. There's a lot of unnecessary syntax in a lot of languages that doesn't really serve any purpose (besides historical). Yes, Matlab does this too. However, not syntactically distinguishing array indexing from function calls has problems in a language that provides as much array functionality as Julia does. The classic example in Matlab is that when the interpreter sees `a(b(c(end))))` it needs to dynamically look up whether `c` is an array or not to decide if the `end` refers to the length of `c` or not, if not then it has to check if `b` is an array or not, etc. That would be even worse in Julia since the question of "is it an array or not" can be somewhat fuzzy. It's perfectly possible to implement an array-like type that uses indexing syntax and does not subtype AbstractArray. In Julia, when you see `log(v[end÷2])` it's syntactically unambiguous that this means `log(v[length(v)÷2])` which is only possible because of the distinct syntax for array indexing and calling functions. There are other where this distinction is essential as well, such as broadcasting [1]. [1] https://docs.julialang.org/en/v1/manual/arrays/index.html#Broadcasting-1 https://docs.julialang.org/en/v1/manual/arrays/index.html#Br... > I actually agree with you on the last part, I do find python's tab indention unsettling. I just think it's better than using "end"s. Ok, well we made the opposite judgement—we found `end` preferable to indentation. When you create a language you get to pick syntax that appeals to you. > I'm not trying to argue about any particular syntax. Just that, syntax should be as concise as possible and not include extra identifiers that confuse the eye. > As an aside, I also think that programming languages should probably use less words, and more symbols, as it lets people who are familiar with other spoken languages to more easily adopt them. > Also, using more keywords (like end), restricts the name space of variable names. You may appreciate K and other APL derivatives, although they are not known for their readability. But they certainly don't favor English speakers over anyone else.

ChrisRackauckas 8y ago
>However, not syntactically distinguishing array indexing from function calls has problems in a language that provides as much array functionality as Julia does. The best example is probably the differential equation solution type in Julia. When you have a solution `sol`, the interface gives you `sol[i]` as the values in the solution's time series and `sol(t)` the continuous solution of the differential equation. This are natural ways to describe both the discrete array-like and continuous function-like nature of an ODE's numerical solution, and that syntax wouldn't be possible without distinguishing a function call from indexing.

ChrisRackauckas 8y ago

>However, not syntactically distinguishing array indexing from function calls has problems in a language that provides as much array functionality as Julia does. The best example is probably the differential equation solution type in Julia. When you have a solution `sol`, the interface gives you `sol[i]` as the values in the solution's time series and `sol(t)` the continuous solution of the differential equation. This are natural ways to describe both the discrete array-like and continuous function-like nature of an ODE's numerical solution, and that syntax wouldn't be possible without distinguishing a function call from indexing.