I just mean that one has to explicitly use ! for a method to be understood as mutating. It’s similar to how the default is struct and mutability is created by mutable struct.
1 Like
I find many of the suggestions here (besides moving assignment away from =) to be focused on improving the writability of Julia and are — in my opinion — at the expense of the readability.
Good programs are read far more frequently than they’re written.
Nearly all these choices (like bang! functions, strong and consistent case conventions, always calling functions with (), etc) are to the benefit of the reader. And I’m grateful for them.
22 Likes
I really don’t like typing out the pair structure over and over (i.e. =>). Fortunately, there are ways around this if you use dictionaries a lot (which I don’t, I usually use NamedTuples for daily work).
function dict(; kwargs...)
d = Dict{Symbol,Any}()
for (k, v) in kwargs
d[k] = v
end
return d
end
3 Likes
You can make the value’s type inferable if you use the iterator constructor instead of filling a Dict{Symbol, Any}:
julia> dict(; kwargs...) = Dict(k => v for (k, v) in kwargs)
dict (generic function with 1 method)
julia> dict(a = 2, b = 3)
Dict{Symbol,Int64} with 2 entries:
:a => 2
:b => 3
4 Likes
Yeah, there’s a lot you could do to improve it. You could also use the : syntax with a pretty simple macro, but my macro-foo is weak and I’m not confidant the thing I’m thinking of wouldn’t have a ton of bugs.
Actually, this can be written more clearly as:
z = isequal(x,y)
I also personally find <- to be esoteric. Besides the need for 3 strokes instead of 1, it mainly is popular in algorithmic contexts and is very rarely used in programming languages.
1 Like
One man’s meat is another man’s poison. So if preferences vary so much, either the language or the IDE could have a layer of abstraction that allows the user to set substitute symbols, in the same way we are can change key mappings in games. Internally, the syntax would remain the same, but what the user sees would be the syntax they prefer. It could probably be expanded to entire statements…for example, let’s say the young version of Bill Gates tried writing a for loop in Julia, the IDE (with the right plugin installed) would allow him to write it in QBASIC style FOR I=1 TO 10, and that line would automatically be converted to Julia syntax internally. I’m aware it’s a lot more complex than it looks, but for simple use-cases, with the right mappings, it could work. It’s high time we had more intelligence and abstraction programmed into compilers or IDE’s.
Time for a new package: Babel.jl!
5 And the LORD came down to see the city and the tower, which the children of men builded.
6 And the LORD said, Behold, the people is one, and they have all one language; and this they begin to do: and now nothing will be restrained from them, which they have imagined to do.
7 Go to, let us go down, and there confound their language, that they may not understand one another’s speech.
8 So the LORD scattered them abroad from thence upon the face of all the earth: and they left off to build the city.
9 Therefore is the name of it called Babel; because the LORD did there confound the language of all the earth: and from thence did the LORD scatter them abroad upon the face of all the earth.
4 Likes
You can call a function with the pipe operator |>
3 Likes
Note that I was not asking for explaining past decisions, but a clarification about the very high bar for proposed breaking changes to the language.
We get well-meaning folks here all the time who propose some breaking syntactic change because they believe it would be nicer. While frequently these things are subjective, few people realize that it simply does not work this way at this stage.
4 Likes
This wouldn’t really impact anyone else, so it’s not a problem for them. But do you really think you would want to use this, over time? In the beginning it could be helpful, but then you would be isolated from other people, there would be problems with manuals, forums, chats, blogs, talks, books, IRL discussions, whiteboard, etc.
And even if you could ‘translate’ all of these by the help of some super-AI, do you think you would learn the language better? My personal WAG is that if you use identical syntax in different languages representing subtly different meanings, it makes them harder to tell apart. I suspect that different syntax makes it easier to learn and remember.
3 Likes
@DNF: The mapped/translated syntax would just be a superficial layer that is visible to the current user. The underlying raw code would be the actual Julia code. So when the code is committed to Git, it’s Julia code that gets committed, so other developers won’t get confused. But when the code is shown to the current user via the IDE, the code is not shown in Julia syntax form. It’ll be shown according to the symbols or syntax the user prefers. It’s similar to how I can change the syntax coloring in my IDE to suit my preferences.
Yes, I understood all of that. The situation you describe is exactly what I was addressing. I was talking about the problems it would cause for you, not for others.
When you see different syntax than others, how will you deal with all those situations where you have to look at ordinary syntax:
4 Likes
A basic understanding of the actual syntax is obviously necessary, and the programmer will learn a bit of that. Moreover, most programming paradigms are pretty much the same, so it’s easy to identify loops, variables etc. of even languages you don’t know much about (I’m not talking of esoteric languages like BrainFuck 
). When the programmer creates the symbol mapping to define their own preferences, they will automatically learn the original language’s symbols. The layer of abstraction just takes away the need to have to deal with the everyday annoyance of specific nuances of syntax that you don’t like. We have colour themes. Think of this as a syntax theme. I remember Netbeans (or the C++ plugin) had a feature for C++, where instead of typing abc->someFunc() I just had to type abc., and Netbeans would convert the . into -> on-the-fly, whenever appropriate.
What I’ve suggested here is just a miniature change compared to what’s actually going to happen in the next decade or so. A GPT-3 trained specifically on programming languages and perhaps trained on speech recognition, could hugely reduce the need for manually typing a lot of code. There’s so much more scope for using Machine Learning to reduce the common issues we go through.
I don’t think that this is a good analogy — syntax does not decompose very cleanly. Eg Julia’s syntax has some interesting corner cases, some of which are disallowed because of ambiguity. This is the same for most languages of reasonable complexity using infix syntax (pure S-expressions of course are an exception, but that can be thought of as no syntax).
Changing the syntax of a language is not as simple as you seem to imagine.
2 Likes
Optimism is good, of course! From my perspective the progress of AI-based ‘smart assistants’ have been much slower than expected over the past several years. Sure, there will be improved tab-completion. But I don’t really anticipate intelligent editors that write your code based on spoken high-level instructions anytime soon 
2 Likes
That has been one of the recurring AI pipe dreams themes since at least the 1980s, in various incarnations.
Personally, I kind of understand the appeal: if you can make machines/algorithms write code, you can get rid of programmers, who can be obnoxious, expensive, and unpredictable
4 Likes
We have a choice. Either accept the status quo or try building something that makes life easier. Especially in cases where programmers have to learn various programming languages just to survive in the industry, it will help to build tools that can take the fatigue out of programming and having to adapt to various languages. Talking to software is already present in the form of Siri, Alexa etc. Even Hololens2 has it in an exciting form (of course I don’t see myself talking while programming. I’d rather type). Yes, Machine Learning and AI in general is hyped up. But in whatever small way it can be implemented and can make life easier for us, let’s take baby-steps to do it. Like I mentioned earlier, Netbeans made life easier for me by automatically substituting the . with a '->` where applicable. If any syntax in Julia or any other language could be adjusted by a plugin according to user preferences, then why not do it? Now that we have better technologies coming up, let’s think of various ways they can be used. As small plugins which we can customize, I definitely see a lot of promise. Sure, it isn’t easy. But ideas will come up eventually.
I think what you are really calling for is a translation layer that would let you type your preferred syntax and then automatically convert that into whatever language you want to use. This is possible for simple problems, but much more difficult when the fundamental principals the language was designed around change (e.g. OOP vs Functional). Your motivation seems to be gaining fluency in as many languages as possible to make yourself more marketable.
Julia’s motivation however is to be so performant and simple to read that it is only language you need. It took syntax inspiration from older languages but ultimately chose the syntax that best fit the language design.
There may be some translation layer out there than can help you not have to learn so many syntactical differences, but if I were you I would focus more on the breadth of problems I can solve with programming than the breadth of programming syntaxes I’ve memorized in order to market yourself.
4 Likes