Keeping the syntax and the need to memorise syntax simple

What is intuitive is also very subjective. Using exclamation points ! for indicating mutation is very common in Ruby and some Lisps. They also use question marks to indicate predicates (which I sometimes miss), e.g. Julia’s isempty can in Ruby and some Lisps be written as empty?.

pop(()) would be very confusing, since it corresponds to applying the function pop on an empty tuple ().

12 Likes

Julia is not at the stage of development where changes like this are made. The language has been fully developed, stable and non-breaking for two years since the 1.0 version was released. Even then, disruptive changes like this would not have been considered without very strong cause. For these kinds of changes to be plausible, you would have had to have suggested them some five years ago or more.

Julia uses the quite common convention that types are capitalized. This helps people reading code understand what is happening—which names are types and which are not.

Why is there an exclamation mark for pop !(Array1) ? Why not just pop(Array1) ? The exclamation mark is what we are familiar with as a not operator.

As explained above, Julia uses the convention that function names ending with ! mutate one of their arguments. This convention has been extremely successful and is certainly not something we would consider changing. Like the capitalization convention, it helps people reading code understand what is happening. If a function modifies an argument, it’s quite important that one be aware of that both when writing and reading the code. Also, mutating functions are somewhat dangerous, so it makes sense that they be somewhat harder to type.

Could you please substitute => with : and for specifying the typing, dict<string, int> is so much more accessible on the keyboard, easier to type, readable and looks so much better.

The a:b syntax is already used to construct range objects, so it is not available.

Case usage of functions like SubString() could perhaps be substring() or subString() .

Again, SubString is a type so it is capitalized.

A lot of these requests seem to have to do with wanting to avoid using the shift key, which would really massively reduce the amount of valuable ASCII real estate available (cutting it fully in half). Moreover, they seem to focus on minimizing the effort of typing code, whereas the conventions are designed to help people read and understand code. Since code is written once but read many times, it is far more important to optimize a language to be easily understood than to make it as easy to type as possible. Knowing at a glance which names are types and which functions mutate things are both useful and important. Much more important than avoiding hitting the shift key sometimes.

53 Likes

Ok, if the language is already beyond the point of changing these, there’s no point discussing it any further. Thank you all for giving it fair consideration.

7 Likes

Thanks for the feedback! I hope you enjoy using Julia despite the shifting :grinning:

19 Likes

Note that you and I do not have the same keyboard layouts, and neither do people in many other countries either. Most commonly used keys are awkward to reach on a swedish keyboard.

5 Likes

Not only on Swedish… I hope that makes you feel better. :slightly_smiling_face:

Welcome to the club! Luckily for you, Julia doesn’t have such issues. I want to clarify some things:

You don’t need to always specify types (hello, C++). String, Int64 will be automatically deduced by compiler:

julia> Dict("a" => 10, "c" => 20)
Dict{String,Int64} with 2 entries:
  "c" => 20
  "a" => 10

You don’t like =>? You can replace it with any other available symbol (from How to change => to another symbol?):

julia> const → = =>
Pair

julia> 1 → 2
1 => 2

Regarding this:

Types are generally written in UpperCamelCase, as they are in Julia base / standard library. It’s standard in every modern language to write object type names that way, and base types are in no way more special than any object type you declare in Julia.

That may not satisfy your needs, though. Do you really dislike pressing Shift key? The solution is simple:

julia> const int = Int
Int64

julia> const float = Float64
Float64

julia> int(1.0)
1

julia> float(1.0)
1.0
7 Likes

float is an already defined function, that transforms an integer type to an equivalent float type,of variable size, for example:

typeof(float(BigInt(2))) #bigfloat
7 Likes

Good catch! But the good thing is there are plenty good names still available for @Nav, such as float64.

2 Likes

Or maybe double (Julia actually already defines the alias Cdouble, but I assume that capital C won’t be appreciated much)

3 Likes

You guys are really cool! Changing an operator to another symbol is something I didn’t expect. Nice…as long as I could change it to a colon. Anyway, my focus was not on having to use the Shift key. I know there are conventions and I know how they are useful because programmers maintain code 90% of the time. Debates about convention and readability have stretched on for long. If I could summarize what I was putting forward, it was about being able to type code in a flow without having to reach for any unnecessary keys and to avoid a jagged/uneven appearance in syntax as much as possible. Your suggestions of const float=Float64 are excellent solutions to the problem. Anyway, I feel these issues are going to become irrelevant very soon, because the GPT-3 demonstrations show that in the near future, any IDE with a GPT plugin would be able to auto-generate a lot of boiler-plate code without us having to actually type the entire line.

1 Like

Incidentally, please make a post explaning this in general. I keep repeating explanations like this, and it would be helpful to just link something polite but reasonably authoritative from the core devs when suggestions like this come up.

8 Likes

In addition to the considerations that others have made, putting code into the right case is the perfect job for IDEs auto-completion, if you really want to avoid pressing shift.

5 Likes

Well-designed Julia code often doesn’t have much boilerplate, especially the top-level code you write during interactive work. Generic functions, type inference and duck typing means you often don’t need to put type annotations in your code. Type assertions on variables are hardly ever used.

@anon37204545’s example is illustrative

Constructing arrays can be done without types:

julia> [1, 2, 3]
3-element Array{Int64,1}:
 1
 2
 3

julia> [1.1, 2.2, 3.3]
3-element Array{Float64,1}:
 1.1
 2.2
 3.3

and this generalizes to all types, even user-defined types.

In the cases where you do need to write them out, I think they should stick out.

5 Likes

I can’t stress this enough. I see from time to time comments like this where people suggests changes to languages (not just Julia) to make typing easier: that should be the job of an IDE, not of the language.

10 Likes

Given the number of programming languages a person has to learn to stay relevant in the industry, it brings a bit of what I’d call “syntax fatigue”. Each time I use a new language, I don’t want to have to figure out what characters are used for commenting out lines, what the syntax for a for loop is etc. It’d have been nice if there would be some universal template which could be decided for conventional programming paradigms at least. The newer concepts could have their own special syntax…no issues. And yes, it’d be great if the IDE could take care of most of the headaches.
I agree with Tamas about the creation of a page where the design decisions of Julia are explained. Notion did this during their design phase.

Build institutional knowledge as you go: Given Notion’s early history, Ivan and Simon have special appreciation for institutional memory — what has been tried before, what worked and what didn’t. As far as they’re concerned, nothing should ever be deleted. “I am constantly like, ‘Do not replace that text! Just copy and create a new canvas!’” says Ivan. “In Figma, you open any file of ours and there’s seven or eight canvases all side by side. You see how the words and design evolved between one and the next.”. With that kind of record, people can learn from the mistakes of those who came before them. Notion’s Figma workspace is divided into a granular folder tree structure that makes it simple to navigate to any past project.

1 Like

Sincerely, the only way I see to address the underlying issue (this is Keeping the syntax and the need to memorise syntax simple) in a way that is yet viable to Julia 2.0, and that would, sincerely, solve the largest problem I have with Julia syntax, is to just have a version of each function of the standard library with underscores between every word, so I do not have to remember if it has or not underscores.

Obviously, this also can be done by a package, and if nobody will, someday I will implement this package. It is just a little more than what I believe I would be able to maintain right now.

7 Likes

I think most IDEs, and even simpler editors, take care of some of these already. To take your examples: In VS Code, Atom, Sublime etc. <cmd+/> toggles line comment, for any language supported by the editor. You should also have a for snippet that expands on tab by just typing for. And many more.

Check out snippets in your favourite editor. Some are already there, and you can add others. I particularly like snippets in LaTeX, which is so full of boilerplate.

BTW: What’s up with the flagging of some posts in here? It doesn’t seem like anything is in violation of guidelines, right?

4 Likes

Yeah, the posts are just fine — the flags were erroneously applied by an overzealous spam-catcher bot and immediately dismissed.

8 Likes

Different languages target different use cases so it makes sense that their syntax is not the same. Also, with fixed templates, innovation is harder and one can not improve upon mistakes made in the past, catch up to changing times etc.

I think in most places, Julia does use syntax that is also used by at least a few other languages, but maybe not each individuals favourite language.

2 Likes

We keep excruciatingly detailed institutional history, in the form of the git commit log and issues: https://github.com/JuliaLang/julia. There’s a lot of it, but that’s how much thought and effort has gone into the language you get. Explaining all the design decisions that have gone into Julia would take more time and energy than anyone has to spend. The manual does some of this explaining already.

9 Likes