I suppose it could indeed be jarring if you're not already used to languages which use 'end' to terminate blocks, but after awhile your brain will just start to treat 'end' synonymously with '}' and all will be right with the world.
Maybe someone can justify why a 3 character word (end) doesn't really matter. But can someone give an argument on how it adds value versus one character (a bracket), or zero characters (visible at least), a tab?
You can certainly argue that '}' is language-agnostic and therefore a better choice, and I wouldn't disagree with you. But 'end' is by no means an arbitrary choice for a character sequence that ends a block.
The crux of the issue is the signal to noise ratio. The more noise there is (syntax), the more difficult it is to pick up the signal (the semantics).
begin some code some more code end
It's easier to read.
PS: And in regards to your last statement, maybe "end"s aren't seen very much anymore is because language designers' agree with me, not that somehow my opinion is influenced by the syntax of modern languages.
If you just think about it, that is much more likely than what you are proposing.
As to the benefits of not using `{}` for blocks, pairs of ASCII brackets are one of the most precious commodities in programming language syntax design. Wasting them on blocks is not ideal. For example, C++ was out of brackets to use for template parameters, and had to use `<>` instead—despite the syntactic clash with their meaning as less than and greater than operators. This has caused no end of parsing problems and irregularities in C++ and related languages and has only been made to work because they're all static languages with separate "expression context" and "type context" and inequality operators don't make sense in type contexts. In a dynamic language, there's only one context and you can't distinguish the use of `<>` as brackets from its use as inequality operators based on that. Julia uses `()` for function calls (pretty important), `[]` for array indexing (also pretty crucial), and `{}` for type parameters.
Using indentation is a fairly clever choice but not without its drawbacks. It causes lots of problems with cutting and pasting code. It means that your IDE cannot generally autoformat or autoindent your code for you. There are also many people who find the "trailing off into space" visual appearance of Python code unsettling and prefer the symmetry and closure provided by `end` or other block delimiters.
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).
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.
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#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.
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.
Yes, easy to write. Seriously, I can type short words like end just as quickly as I can type shift-}, two keys off in the extremes of the keyboard layout.
I think it gets a bad reputation from languages like bash that have a horribly inconsistent mix of `fi`, `end`, `esac`, and require opening words like `then` and `do`, which people can argue about where to place.
end worked great in pascal and matlab, and it works great in julia as well.
By sharing block delineation with variable namespaces, the language creates a whole bunch of problems (a block identifier is essentially a newline followed by a “end” vs the much simpler “}”).
Also, the more english centric a language becomes, the harder it is to learn for non-english language speakers.
Moreover, words are used for variable names, while symbols are disallowed is many/most languages. By having block delineaters share the variable namespace, you detract from the readability of the language (as well as restricting variable names as I mentioned earlier).
One might ask: Does any of this matter in the scheme of things? The fair and honest answer is: not really, it’s a minor syntactic difference. But I firmly believe using words to end blocks is still inferior, even if it’s not a big difference.
Block delineation in Julia doesn't require the newline. You can just throw a ` end` at the end of the line. Often you'll see folks put the `;` line delimiter there, too, to make things super-clear (as that's generally how you delineate multiple expressions on the same line), but it's not required for an `end`.
And while it is indeed a little sad that you can't use `end` as a variable name, we make the most of it by using it to also represent the last index in an indexing expression like `A[end]`.
So, yeah, not a big deal at all, but very few of your detractions even apply in the first place. :)