5 ms·

Julia is interesting, but the block syntax is a little off-putting. I'm not sure why someone would design a language that uses 'end' to delineate a block. Curly

by mruts 8y ago

Julia is interesting, but the block syntax is a little off-putting. I'm not sure why someone would design a language that uses 'end' to delineate a block. Curly brackets make sense. Tabs make sense. But 'end'? All it does is make code harder to read and harder to write.

jampekka 8y ago
Because MATLAB. And I don't think that's a very compelling argument.
chappi42 8y ago
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.
yellowapple 8y ago
Ruby and Elixir both made the same decision, and I don't feel like it's had an actual negative impact, for me at least; I've found both languages to be delightfully readable. I haven't dabbled very much in Julia since the pre-1.0 days, but I don't recall it being any more or less jarring. 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.
- mruts 8y ago
  I mean, maybe it's not a big deal. But what value does it add? What if we had a 50 character string of random digits be the terminating identifier for a block? What about 100 characters? What about 200? Syntax shouldn't create visual noise, it should be as lightweight as possible. 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?
  - xiaodai 8y ago
    it's easier to read.
    - mruts 8y ago
      If every sentence ended in an "end" instead of a period, would you posit that that would be easier to read as well? 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).
      - xiaodai 8y ago
        Sentence is not code! According to your logic, when do you see {} in prose? begin some code some more code end It's easier to read.
  - yellowapple 8y ago
mkborregaard 8y ago
Another compelling argument is that {} , while very easy to type on an English keyboard, is highly awkward on keyboards of almost any other language in the world. E.g. I'm Danish and on my Mac { involves flexing the right thumb down to hit right-alt while typing 7 with my middle finger and holding down shift with my left pinky. `end`, though, being actual letters, is completely easy and fast to type (on languages that uses the latin alphabet).
pavon 8y ago
I love the use of end for blocks! It avoids the arguments about brace placement on one hand and problems with space sensitive indention on the other. It is simple, consistent, easy to read and write. 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.
- mruts 8y ago
  I mean, what about auto-generated code? Not only does using words forbid potential variable names, but it makes code generation more difficult as well (as does tabs). A good positive example is Haskell, which uses tab for normal block delineation, but also allows curly brackets (which is usually only used for auto-generated code). 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.
  - 3JPLW 8y ago
    Autogenerated code is very easy in Julia — there is no string processing at all. You can splice things directly into quoted code (working at the literal syntax level) or manually modify the `Expr` representation in a lispy manner (in which case there aren't any `end`s at all). Code generation is _really_ easy, thanks to its lispy inspiration. 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. :)

by mruts 8y ago

jampekka 8y ago

Because MATLAB. And I don't think that's a very compelling argument.

chappi42 8y ago

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.

yellowapple 8y ago

Ruby and Elixir both made the same decision, and I don't feel like it's had an actual negative impact, for me at least; I've found both languages to be delightfully readable. I haven't dabbled very much in Julia since the pre-1.0 days, but I don't recall it being any more or less jarring. 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.

mruts 8y ago
I mean, maybe it's not a big deal. But what value does it add? What if we had a 50 character string of random digits be the terminating identifier for a block? What about 100 characters? What about 200? Syntax shouldn't create visual noise, it should be as lightweight as possible. 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?
- xiaodai 8y ago
  it's easier to read.
  - mruts 8y ago
    If every sentence ended in an "end" instead of a period, would you posit that that would be easier to read as well? 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).
    - xiaodai 8y ago
      Sentence is not code! According to your logic, when do you see {} in prose? begin some code some more code end It's easier to read.
- yellowapple 8y ago

mkborregaard 8y ago

Another compelling argument is that {} , while very easy to type on an English keyboard, is highly awkward on keyboards of almost any other language in the world. E.g. I'm Danish and on my Mac { involves flexing the right thumb down to hit right-alt while typing 7 with my middle finger and holding down shift with my left pinky. `end`, though, being actual letters, is completely easy and fast to type (on languages that uses the latin alphabet).

pavon 8y ago

I love the use of end for blocks! It avoids the arguments about brace placement on one hand and problems with space sensitive indention on the other. It is simple, consistent, easy to read and write. 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.

mruts 8y ago
I mean, what about auto-generated code? Not only does using words forbid potential variable names, but it makes code generation more difficult as well (as does tabs). A good positive example is Haskell, which uses tab for normal block delineation, but also allows curly brackets (which is usually only used for auto-generated code). 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.
- 3JPLW 8y ago
  Autogenerated code is very easy in Julia — there is no string processing at all. You can splice things directly into quoted code (working at the literal syntax level) or manually modify the `Expr` representation in a lispy manner (in which case there aren't any `end`s at all). Code generation is _really_ easy, thanks to its lispy inspiration. 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. :)