3 ms·

Julia is a very pleasant language to work with. The type system, multiple dispatch, and package system all make it into top 10 of design. The only change I wou

by pbohun 5y ago

Julia is a very pleasant language to work with. The type system, multiple dispatch, and package system all make it into top 10 of design. The only change I would recommend is to have a way to distinguish between creating and setting a variable. Without this distinction it is very easy (especially for someone with dyslexia) to misspell a variable and accidentally create a new one instead of assigning a value. Something like this would be nice: var x = 5 or even something like Go: x := 5

blipmusic 5y ago
Please, yes! It may sound dumb, but such a "simple" change (simple conceptually, can't speak of the dev challenge involved) change would be an enormous quality of life increase to me. I've ended up looking into scoping rules and what not when bug-hunting because of this, but often just ended up going back to a language with stricter syntax around variable creation (goes for moving away from Python etc as well). The more the code, the bigger of an issue this becomes.
- porker 5y ago
  I third this. It'd make such a difference for me.
- davnn 5y ago
  Would you be willing to provide an example where this becomes a problem? Probably unpopular opinion, but I don‘t think this should be a problem for structured applications and hints at a more fundamental design problem.
  - blipmusic 5y ago
    > Would you be willing to provide an example where this becomes a problem? It's not a specific example, as much as every piece of code where mutability is involved. I don't have a LOC number in mind, but it could be for blocks/local scopes. IMO syntactic explicitness helps clarity and thus bug hunting/maintenance, and I feel tooling shouldn't be an alternative for dealing with, albeit subjective, syntactic shortcomings. > this should be a problem for structured applications and hints at a more fundamental design problem Frankly, I don't see how introducing an explicit hint that a variable is created can ever be a bad thing. Explicit lack of mutability is also something I'd like to have (e.g. 'let' vs 'var') - sometimes I want to make sure not to accidentally change a value. We will shoot ourselves in the foot at some point, so a syntax that allows for a check whether I can actually change a value further down can only be a good thing. I absolutely do not trust myself. :) When things go wrong for this reason (difficult to spot typo etc) I may waste time on investigating whether blocks are actually leaky or not etc - I have issues with Python syntax for the same reason. Going in the other direction, I like Rust's perhaps overly verbose "let mut" much better, since this has other consequences for explicitness (mutable references '&mut X' vs immutable references '&X'). No special tooling or IDE required to spot this, I can 'cat' the code in a terminal and it's still obvious. I absolutely don't think Julia or Python should "go Rust", since their dynamic nature is a strength, especially so in academia where notebooks are popular. But a simple "I'm creating a variable" should IMO be a nice visual cue to any developer.
    - davnn 5y ago
      Thanks for your answer! I think it‘s a tradeoff between syntactic simplicity and explicitness. I enjoy languages like Scala or Rust that are more explicit, but I enjoy Julia as well (partly because of its simplicity).
  - patrick451 5y ago
    It comes up all the time 100 line one-off scripts in python. You start off with 10 lines that you're iterating on. You move some snippet to a function, don't de-dupe your variable names from the global scope, and you get a bug where you thought "x" was scoped to the function, but wasn't actually defined in the function so you're using the global "x". Yes, this could be fixed by moving the global statements into a main() function, but this breaks your repl workflow and you have to resort to breakpoints in main().
lmc 5y ago
Perhaps this is something that could be fixed with a tooling, rather than language change? E.g. Syntax highlight a different a colour if it's the first use of a variable.
sundarurfriend 5y ago
This has been discussed before, and the tl;dr is that it's unlikely to happen. The discussion here[1] gives a sample of the implications and thought processes behind it, considering what it would mean to have := in different contexts, but the conclusion was: > It’s just an interesting thought experiment — we can’t practically do this even in a 2.0 release. It would be a massively breaking change: we would need to disallow implicit declaration of locals by assignment, which breaks all Julia code everywhere. I also think that what we do now is good and less annoying for new users since they will be accustomed to just assigning to initialize and declare new locals if they are coming from Python, R, Matlab or Ruby (to mention just a few). (What isn't mentioned explicitly is that this would also break a lot of macro code which accepts assignment-like syntax, which would have to deal with this new type of node in the AST and make decisions about how to handle it.) The good news is that, as Stefan mentions in a thread linked from there, you can already do `local mylongvarname = 5` as an explicit variable creation syntax; and Julia has good enough tooling to parse it (and is getting even better ones as we speak) that you can disallow assignment to any variable that you haven't seen before with a `local` declaration, with a linter-like step. So the linter will error on a later `mylngvarname = 42`. It's not the language itself adding it as a feature - so code inherited from elsewhere likely won't have it, and you might have to get buy-in from your team - but it's probably as close as you can get to what you want. [1] https://discourse.julialang.org/t/why-no-operator-for-initializing-variables/62949 https://discourse.julialang.org/t/why-no-operator-for-initia...

by pbohun 5y ago

blipmusic 5y ago

Please, yes! It may sound dumb, but such a "simple" change (simple conceptually, can't speak of the dev challenge involved) change would be an enormous quality of life increase to me. I've ended up looking into scoping rules and what not when bug-hunting because of this, but often just ended up going back to a language with stricter syntax around variable creation (goes for moving away from Python etc as well). The more the code, the bigger of an issue this becomes.

porker 5y ago
I third this. It'd make such a difference for me.
davnn 5y ago
Would you be willing to provide an example where this becomes a problem? Probably unpopular opinion, but I don‘t think this should be a problem for structured applications and hints at a more fundamental design problem.
- blipmusic 5y ago
  > Would you be willing to provide an example where this becomes a problem? It's not a specific example, as much as every piece of code where mutability is involved. I don't have a LOC number in mind, but it could be for blocks/local scopes. IMO syntactic explicitness helps clarity and thus bug hunting/maintenance, and I feel tooling shouldn't be an alternative for dealing with, albeit subjective, syntactic shortcomings. > this should be a problem for structured applications and hints at a more fundamental design problem Frankly, I don't see how introducing an explicit hint that a variable is created can ever be a bad thing. Explicit lack of mutability is also something I'd like to have (e.g. 'let' vs 'var') - sometimes I want to make sure not to accidentally change a value. We will shoot ourselves in the foot at some point, so a syntax that allows for a check whether I can actually change a value further down can only be a good thing. I absolutely do not trust myself. :) When things go wrong for this reason (difficult to spot typo etc) I may waste time on investigating whether blocks are actually leaky or not etc - I have issues with Python syntax for the same reason. Going in the other direction, I like Rust's perhaps overly verbose "let mut" much better, since this has other consequences for explicitness (mutable references '&mut X' vs immutable references '&X'). No special tooling or IDE required to spot this, I can 'cat' the code in a terminal and it's still obvious. I absolutely don't think Julia or Python should "go Rust", since their dynamic nature is a strength, especially so in academia where notebooks are popular. But a simple "I'm creating a variable" should IMO be a nice visual cue to any developer.
  - davnn 5y ago
    Thanks for your answer! I think it‘s a tradeoff between syntactic simplicity and explicitness. I enjoy languages like Scala or Rust that are more explicit, but I enjoy Julia as well (partly because of its simplicity).
- patrick451 5y ago
  It comes up all the time 100 line one-off scripts in python. You start off with 10 lines that you're iterating on. You move some snippet to a function, don't de-dupe your variable names from the global scope, and you get a bug where you thought "x" was scoped to the function, but wasn't actually defined in the function so you're using the global "x". Yes, this could be fixed by moving the global statements into a main() function, but this breaks your repl workflow and you have to resort to breakpoints in main().

lmc 5y ago

Perhaps this is something that could be fixed with a tooling, rather than language change? E.g. Syntax highlight a different a colour if it's the first use of a variable.

sundarurfriend 5y ago

This has been discussed before, and the tl;dr is that it's unlikely to happen. The discussion here[1] gives a sample of the implications and thought processes behind it, considering what it would mean to have := in different contexts, but the conclusion was: > It’s just an interesting thought experiment — we can’t practically do this even in a 2.0 release. It would be a massively breaking change: we would need to disallow implicit declaration of locals by assignment, which breaks all Julia code everywhere. I also think that what we do now is good and less annoying for new users since they will be accustomed to just assigning to initialize and declare new locals if they are coming from Python, R, Matlab or Ruby (to mention just a few). (What isn't mentioned explicitly is that this would also break a lot of macro code which accepts assignment-like syntax, which would have to deal with this new type of node in the AST and make decisions about how to handle it.) The good news is that, as Stefan mentions in a thread linked from there, you can already do `local mylongvarname = 5` as an explicit variable creation syntax; and Julia has good enough tooling to parse it (and is getting even better ones as we speak) that you can disallow assignment to any variable that you haven't seen before with a `local` declaration, with a linter-like step. So the linter will error on a later `mylngvarname = 42`. It's not the language itself adding it as a feature - so code inherited from elsewhere likely won't have it, and you might have to get buy-in from your team - but it's probably as close as you can get to what you want. [1] https://discourse.julialang.org/t/why-no-operator-for-initializing-variables/62949 https://discourse.julialang.org/t/why-no-operator-for-initia...