Language aesthetics do matter. Broadly it seems like we've accepted that "c like" syntax - including brace-delimited blocks and zero-based indexing - should be the norm for programming languages. Any language which goes in a different direction should have a very strong reason to do so, because any deviation will be an obstacle for adoption.

I share your frustration with the `end` keyword - it's just needlessly verbose, and for something used so frequently it makes sense to be as terse as possible.

I have some similar quibbles with Rust syntax: I know it's a minor issue, but I'm really disappointed that snake_case was adopted. It's just ergonomically inferior to camelCase in every measure. It's one more character to type for every word, and on top of that, on a US keyboard, the underscore character is a pinky key way far away from the center of the keyboard. Making this one of the most frequently typed characters in the language makes no sense.

snake_case is a lot more readable than CamelCase, which is a huge benefit ergonomically. The keyboard layout is no big deal, one can easily change it or use shortcut-based autocomplete. Rust does use CamelCase for type identifiers, trait identifiers and enum constructors, and the contrast with snake_case also aids readability.

I disagree that it's "a lot" more readable. I have read a lot of camelCase code in my lifetime, and I can count on zero hands the number of times I ever had an issue parsing code due to the use of camelCase.

Keyboard remapping seems like an extreme solution, and I don't want to train my fingers in such a way that when I sit down at a different workstation that doesn't have my .vimrc I can't type rust anymore.

You don't need snake_case for contrast. You can use lowerCamel and UpperCamel to denote the same levels of significance. SCREAMING_SNAKE is fine for constants because they don't get used all that often, but rust maps the hardest-to-type case to the most-frequently-used, which in my opinion is an ergonomic failure.

CamelCase is terrible as soon as you have an abbreviation in your function (like "DB"). I run into this extremely frequently at my place of work.

> CamelCase is terrible as soon as you have an abbreviation in your function (like "DB").

Yeah someone always wants to capitalize abbreviations/acronyms weirdly, or treat camel case like it was title case in handling short words or...

Getting people to be consistent with snake case is much easier, for some reason.

It really depends on your naming conventions. If you consistently treat acronyms in the same way as regular words (i.e. "XmlReader", "IoStream" etc), then there's no practical difference with "xml_reader" and "io_stream".

Sorry to be pedantic, but PascalCase is different from camelCase.

I use an ergodox keyboard with a custom Dvorak based layout. Underscore is pretty prominent, analogous to the 4 key with no modifiers.

It makes a huge difference, so much so that using camelCase feels like a huge drag.

Qwerty is frankly awful for programming. I encourage everybody to look into alternate layouts.

So would you seriously suggest that programming languages should be optimized for extremely rare, niche keyboards rather than the standard that ships with virtually every laptop which nearly 100% of coders will be using?

They are clearly not suggesting that.

I would argue that `end` is a much better choice than both the Python approach and curly braces: https://erik-engheim.medium.com/the-case-against-curly-brace...

`end` marks of blocks of code much more clearly than curly braces. It is also requires fewer keyboard taps. To type {} requires holding down four keys in total (shift-[ twice). end is just three key strokes.

But more importantly is saves curly braces for other uses where it is more needed.

Typing braces is basically a gesture. You hold the shift key with left pinky, and roll right ring finger pinky over open and close brace, then tap back arrow and return to get you inside the block. End is three distinct key presses.

Also braces have a nice symmetry, which is also convenient for parsers and tooling to count opens and closes.

I also think "end" is just more visually noisy. Braces are a symbol, so it's easy to filter them out when you're looking at code, but a trail of "end"s takes up more real-estate than is semantically justified.

Yeah, I'm very glad we saved curly braces for type parameters in julia. I really dislike the use of <these> in static languages.

Sigh, <> isn't the only way, D (as usual) has a very simple and clever solution f!(types)(parameter)

Maybe it's just my julia indoctrination speaking but I find that rather ugly.

In julia, f!(types)(parameter) means that f! is a mutating function acting on types which returns a closure which is then called on parameter.

We just write Type{paramemer}

> "We just write Type{paramemer}"

It seems odd to say "we just write" for some arbitrary choice with its own tradeoffs; {} mean a set in Python or a literal array initialiser in C# or a scriptblock in PowerShell or a dfn in Dyalog APL or a JSON dictionary, etc. With only a limited set of whatever symbols happened to end up on a US ASCII keyboard 40+ years ago, there is heavy competition for them, it's why J broke the symmetry of pairs and went for two-character symbols, why PowerShell went for comparators like -gt and -lt, why C# has => which is completely different from <=, why << is not a double application of less-than but is bit shifting ...

To act like there's an objectively better use for {} is to miss how many tradeoffs there are, and how many things people want symbols for out of a standard keyboard.

I never said it was objectively better.

My point was just that we find Type{parameter} to be nice pleasing syntax, and so reserved the curly braces for that.

Of course it’s not objectively better, that’s a dumb attitude towards syntax.

What's the difference to you for using {} vs <>?

< and > are comparison operators for checking if something is less than or greater than something else.

This is okay in a static language where there are special slots for a type where only a restricted subset of things can happen. You'd know at the parser level that the < and > are referring to the type meaning or the operator meaning.

In julia, types are values and values can live in types, and arbtrary operations can happen in a type.

E.g. I can write Tuple{1 < 2} which just becomes the type Tuple{true}, i.e. a Tuple Type with paramemter True.

I feel like this is a solvable problem. For instance you could require parens in the case of expressions using < or > characters.

Or you could just not use them for type parameters. That's also a solution for what it's worth. I think the curly braces look better as type params anyways imo.

That's not a particularly convincing blogpost - for example you don't need square brackets for indexing, one of Ken Iverson's changes going from APL to J was to see indexing as just another function application and remove square bracket syntax from it. Grouping arithmetic expression is worsened by complex precedence rules, APL always evaluating right-to-left and all operators having the same precendence changes how that works as well (even though it does have grouping parens too). Then complaining that "<>" are used in mathematical expression, but not being annoyed by "main()" in a function declaration or the "?" and ":" used in the complex type expression?

Seems to me that "end" is one of the worse available choices; if we're going for keywords, why not make them "endif", "endfor", "endwhile" (or "wend") which makes it explicitly clear what each of:

        end
      end
    end

is ending.

Because it doesn't really help as soon as you get repeated nesting, which isn't all that uncommon.

I love Julia in general, but yeah, I hate `end`.

Re: 0-indexing vs 1-indexing. If you use 0-indexing, you turn off a lot of non-engineering scientific programmers. My personal experience is that 0-indexing is better for more engineering applications, while 1-indexing is better for math. I'm a weirdo in that I don't seem to mind either one though.

> you turn off a lot of non-engineering scientific programmers.

I think you mean "non-CS engineers". CS is a minuscule branch of engineering. Plenty of chemical, mechanical, civil (and so on) engineers had their whole education doing maths and programming with 1-indexing.

> I'm a weirdo in that I don't seem to mind either one though.

You are not, as an outsider this is one of the less appealing parts of practical CS, endless bickering about non-substantive issues which most of the time boil down to a matter of personal preference (see also tabs vs spaces, vim vs emacs, react vs vue, golang vs rust and on and on and on...)

I don't understand why Julia didn't do like Fortran and Ada and allow any starting index. E.g., a(-5:5, 0:3).

In case you didn’t know, Julia does in fact have arbitrary indexing!

https://docs.julialang.org/en/v1/devdocs/offset-arrays/

I mean, Julia is flexible enough that it's pretty easy to implement arrays with different indexing schemes that have the same performance as built-in arrays: https://github.com/JuliaArrays/OffsetArrays.jl

Is there an example of where 1 is better for math, or is it just a familiarity thing?

Zero based indexing came from early requirements to address things in arrays using offsets.

Subsequent languages don’t have this issue, and when you think about it, it causes a weird disconnect: 1-based indexing corresponds exactly with how you think about and see elements in a collection. 0 based indexing-despite how comfortable one gets with it requires additional arithmetic.

It’s a relic from the past, and unless you’re doing the very specific thing of indexing via offset instead of position, there’s no reason to hang onto this anachronism.

Most math books are written in a way where 1 is the first element. So if you take math examples and translate to code, it works more naturally.

Also this is how you talk normally. You don't talk about the zeroth-column or zeroth-row in daily speech. You talk about first column and first row.

Only reason 0 based indexing make sense to me is because I began programming as a teenagers and was forced to get accustomed to it. But I remember struggling with it. Yes when working with memory, pointers etc it is more elegant. But if you are not, then I think 1-based indexing looks better.

As a trivial example, if you want to get the sum of the first n numbers, that's `sum(range(n+1))` in Python. Or if you want to get all the prime numbers <= n, find the triangular numbers, etc. In general you end up with a lot of `n+1`s and it's easy to lose track or miss some, and end up with a silent, non-crashing error that produces the wrong result because you're accidentally leaving out the last element of your input.

Linear algebra is the most practically consequential one - and suffice it to say, it’s not a coincidence that BLAS, LINPACK, and LAPACK were all written in one-based languages. Matrix indexing is one-based, and beyond the issue of translating notation from equations, IIRC there is even a slight performance difference in some cases.

I believe what it really comes down to is that, just as zero-based really is more natural for offsets (zero offset means the first position, great for pointers), one based really is more natural for counting [and _sets_] (when your index is n that means you have counted n elements up until now).

I think your pain points with Julia are real, but they don’t bother me too much. I mostly use Lisp languages, enjoy but am not so good with Haskell, so I am very flexible in syntax. I shared the dislike for 1 based indexing, but when I recently started evaluating Wolfram/One and Language, my limited experience with Julia and Octave made Wolfram’s use of 1 based indexing OK.

I love experimenting with programming languages but I don’t like recommending languages just as I don’t like recommending movies: I figure that everyone has their own tastes, and that is a good thing.

If it's just the syntax and muscle memory you are quibbling about, you can use python to write code and then transpile it to Julia. Link to github in my other comment in this article.