Emacs has the visual substitution feature. I found it cool when I first learned about it, but after two hours, reached the conclusion that I liked to see the bare text and not deal with yet another abstraction layer in my mental models.
@mkitti: thank you. The mention of Eclipse always reminds me of Jason Fruit’s words “the word “Eclipse” in a programming context (or a literary one, for that matter) fills me with dread; in my mind, Eclipse is a pig strapped to a dog strapped to a whale.” @NightMachinary: That’s cool, but yes, even I’d want to see the actual text. My suggestions were more along the lines of retaining familiar syntax across languages and having a smoother typing flow. Anyway, on a “prettify” note, there’s somebody who actually put symbols into d3.js code (var λ = spherical[0], φ = spherical[1], cosφ = Math.cos(φ);). See the d3_geo_cartesian function in this page.
To be clear about the mathematical syntax, unicode is fully accepted in Julia and we have a unicode entry mechanism using LaTeX names and tab completion:
julia> ϕ = π/6; cos(ϕ)
0.8660254037844387
julia> λ = 3
3
julia> τ = 2π
6.283185307179586
julia> τ/2
3.141592653589793
julia> for color ∈ ["red","blue","green"]
println(color)
end
red
blue
green
I do like being able to use Unicode characters in Julia, however, I fail to see the point of using ∈ instead of in in Julia, especially for for loops (I think it makes a bit more sense for set operations).
I think everybody understands what in means, and how to enter it with their REPL or editor. ∈ takes four characters to type even with the Julia REPL instead of 2.
It takes 3 bytes instead of just 2 in the file.
In my opinion the major appeal of ∈ over in comes when negated. I rarely use it for loops, but I’m rather unconcerned about the extra bytes in the file or the extra characters to type.
I find the notion that angle brackets are objectively better here quite fanciful. This syntax has caused huge problems in languages that use it, e.g. that when you nest it, >> conflicts with the right shift operator. And is it really so weird and unconventional to think that maybe < means “less than”? It is probably also impossible to implement in a dynamically-typed language, where the compiler doesn’t have any type information at parse time. (Some might mark that as a point against dynamic typing, but I take the opposite conclusion.)
Otherwise, thank you for taking the time to write up your impressions, and I hope you’ll stick around for julia 2.0 when we can entertain more radical ideas — but I also hope you decide that syntax is not where most of the action is
People have been using Unicode in Julia successfully for years. In my opinion all the Python answers slamming Unicode there are just post-hoc rationalizations: “Python doesn’t support this properly so it must be better not to use it, right? Right?!?” Julia code based on mathy papers where the notation in code matches the notation is much easier to read and review than code that awkwardly spells out greek names in ASCII. What those SO answers seem to miss is that code doesn’t live in isolation.
I am not sure what these “problems” are, and how that discussion is relevant here. Apparently at least 95% of the answers are from people who never used a language+IDE with nice native Unicode support, so the “imagine” what it feels like and conclude that they wouldn’t like it.
This is like reading a conversation between people who just heard about bicycles, and reason that the rider must inevitably fall over.
I can kind of relate to the fact that languages conceived before, say, 2000 lack native Unicode support in code. Conversely, for languages designed after 2010 not supporting it is the weird choice — you almost have to make a conscious effort to disallow it.
The only time you’d need it negated is in precisely the case where I did say (for set operations) where it does make more sense to use. not(a in b) is rather a pain to read, a \notin<tab> b is exactly the same to type (and yes, the file is also a bit smaller!).
My point for for loops, etc. is simply why make it harder to understand for most people when it isn’t even shorter/easier to type? What are the pros in that case? I’m afraid some people use it then just because they can, and to seem “cooler”, at the expense of readability and maintainability of the code.
I don’t recommend Emacs for Julia. It’s great for some languages (e.g., Clojure, coq), shines for any language that has no mainstream IDE support (e.g., zsh), and plain-text (org-mode seems unparalleled). But Emacs can’t compete with Julia’s VSCode extension. That extension has superb support: hover documentation, smart goto definitions, profiling (@profview), great auto-complete, debugger, … .
If you want to try Emacs, I recommend starting via doom.
