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.
If there is something, I haven’t really encountered it yet. I love emacs for julia development and see no reason to change. I mostly use emacs-jupyter in org notebooks as essentially a REPL / scratch space with better history support and then I use Revise.jl to hot-reload code in .jl files that I’m working on.
If you prefer using julia’s built in REPL, then check out julia-repl.
For things like interactive plots and other fancy graphical things that don’t play nicely with emacs, I just use Blink.jl together with Interact.jl to spawn electron windows where I make little GUIs and put interactive plots.
Maybe I need to start looking at emacs-jupyter. The julia-repl is not great for me. Often it sort of leaves droppings around the screen or swallows error messages or things. It’s particularly bad when there are backtraces, which show on the screen but are long enough that when you scroll back… it turns out they first few lines are not there anymore. I’m sure this has something to do with running in a term buffer.
Can I work in emacs-jupyter with julia markdown for Weave files? That’d be cool.
I haven’t tried, but I suspect that if it doesn’t work out of the box it’d be pretty easy to get working. The basic model is that jupyter-emacs will spawn a jupyter kernel and then offer a few different ways for you to send it code. The two ways I’ve experimented with are via Org notebooks and it’s jupyter-repl, both of which are built in.
Basically, if you’re in an environment that jupyter-emacs isn’t configured to work with, all you should need to do is run M-x jupyter-repl-associate-buffer to associate your buffer with a jupyter kernel (it’ll prompt you to spawn one if none are running) and then you can use M-x jupyter-eval-line-or-region to have a line or selected region of code be executed in your associated jupyter kernel. By default, I think the output will appear in a popout buffer, but I that can be configured.
Org notebooks basically provide a convenient (and multi-lingual / multi-kernel) way to do this out of the box, but it shouldn’t be to hard to replicate for your preferred file-type.
I like the idea behind Pluto.jl but I cannot use it. It seems to solve the “problem” of “hidden state” but my nightmare is jupyter actually re-running my cells each time it finds it a good idea to do so (i.e., what Pluto.jl does).
Apologies in advance for going completely off-topic, but you stumbled into my favorite trivia subject: the science of bicycle riding. I’m obsessively compelled to share two potentially mind-blowing factoids. (If someone is tempted to reply, please open a new thread in the off-topic subforum and @call_me so this thread doesn’t get derailed.)
The scientific consensus on exactly how a two-wheeler remains upright is only just beginning to emerge - the knowledge is roughly as new as Julia. Here’s an interesting summary from Nature Magazine in 2016.
Almost everyone can ride a bike, but even so almost everyone is surprised when they learn this: to turn a bike to the left (while remaining upright), you start the turn by rotating the handlebars clockwise. This is called countersteering. Wilbur Wright’s observation from 100 or so years ago remains true today.
Just to second this point. Reactive notebooks are a great example of something which is a little hard to pitch, in that they turn out to be quite transformative for reasons that require firsthand experience to appreciate.
As explained, it’s only a convention, so you CAN not adopt it for your own code (except when calling e.g. pop! but you could wrap it in another function).
I do NOT advice doing that, it’s best to learn and use the convention of a language you use. That said, there are libraries like LispSyntax.jl you might find interesting (and PythonSyntax.jl, but it’s not maintained), I not trying to promote, just show what’s possible. As an exercise you could make your own make your own.
An idea in some languages, at least Nim, is to allow both upper and lower case, you might want the former for readability (for making libraries) but in your own code using such a library allow not exercising the SHIFT key… Someone could propose such for Julia 2.0, I’m just not sure it would be accepted, but you could add that relaxed syntax in a library similar to those above.
FYI: An arrow has been added to Julia. It’s in Julia 1.6 already I think, but if I recall with no defined meaning yet.
I met Hadley Wickham once and asked him about that! Sadly there were reasons (mostly %>% was available to use and it was too much effort to do it in a better way).
Personally I think Julia is easily my favourite language, syntax-wise. There’s very little I don’t like about it (just the lack of underscores in common functions).
The lack of underscores for many functions, esp. where they are of the form verbobject is something that I dislike also. I ended up making a bunch of aliases for the ones for string handling, to make the code more readable (verb_object scans a lot better, IMO).
There are very few things that I dislike about Julia’s syntax, and quite frankly, Julia has been powerful enough for me to come up with pretty easy work arounds (like implementing my own version of string interpolation, based on the \(...) syntax that many modern languages use, that also adds formatting.
It’s hard to think of anything that I disliked, that wasn’t able to be solved because of the power and flexibility of Julia itself (OffsetArrays, PermutedDims, for example).
!