4 ms·

Because Pascal. And as Pascal was used as a teaching language, I don't think your 'make code harder to read and harder to write' argument holds. But certainly n

Because Pascal. And as Pascal was used as a teaching language, I don't think your 'make code harder to read and harder to write' argument holds. But certainly nowadays 'end's are not seen often; maybe this has an influence in your statement?

mruts 8y ago
Why do you think that "end" is superior to more lightweight syntax? One might argue that using "end" doesn't really matter, but I am extremely skeptical one could argue it is superior to a curly bracket or a tab in any way at all. 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.
- StefanKarpinski 8y ago
  Given the historical precedent of Pascal, Ruby, Matlab and others, using `end` to close blocks is not exactly controversial or uncommon. 5 of the current top 20 languages on the Tiobe Index use `end` to close blocks versus 11/20 for curly braces and 1/20 for indentation. Most of the `{}` languages are C descendants: using `{}` for blocks is popular because C has been wildly successful, not the other way around. Using `{}` for blocks wasn't some brilliant language design choice that caused the success of C—it was a fairly mundane choice that happened to be made by a language that succeeded for entirely unrelated reasons and the syntax spread from there. 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.
  - mruts 8y ago
    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. 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.
    - StefanKarpinski 8y ago
      > 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.

mruts 8y ago

Why do you think that "end" is superior to more lightweight syntax? One might argue that using "end" doesn't really matter, but I am extremely skeptical one could argue it is superior to a curly bracket or a tab in any way at all. 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.

StefanKarpinski 8y ago
Given the historical precedent of Pascal, Ruby, Matlab and others, using `end` to close blocks is not exactly controversial or uncommon. 5 of the current top 20 languages on the Tiobe Index use `end` to close blocks versus 11/20 for curly braces and 1/20 for indentation. Most of the `{}` languages are C descendants: using `{}` for blocks is popular because C has been wildly successful, not the other way around. Using `{}` for blocks wasn't some brilliant language design choice that caused the success of C—it was a fairly mundane choice that happened to be made by a language that succeeded for entirely unrelated reasons and the syntax spread from there. 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.
- mruts 8y ago
  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. 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.
  - StefanKarpinski 8y ago
    > 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.