10 ms·

I'm a quite happy Julia user, however I feel there are still some warts in the language that should have warranted a bit more time before banging 1.0 on the bad

I'm a quite happy Julia user, however I feel there are still some warts in the language that should have warranted a bit more time before banging 1.0 on the badge. Exception handling in julia is poor, which reminds me of how exceptions are (not/poorly) handled in R. Code can trap exceptions, but not directly by type as you _would_ expect. Instead, the user is left to check the type of the exception in the catch block. Aside for creating verbose blocks of boilerplate at every catch, it's very error prone. Very few packages do it right, and like in R, exceptions either blow up in your face or they simply fail silently as the exception is handled incorrectly upstream by being too broad. Errors, warnings and notices are also often written as if the only use-case scenario is the user watching the output interactively. Like with R, it's possible but quite cumbersome to consistently fetch the output of a julia program and be certain that "stdout" contains only what >you< printed. As I use julia also a general-purpose language to replace python, I feel that julia a bit too biased toward interactive usage at times. That being said, I do love multiple dispatch, and julia overall has one of the most pragmatic implementations I've come across over time, which also makes me forget that I don't really like 1-based array indexes.

Q6T46nT668w6i3m 8y ago
Yeah, I agree with your comments about error handling. It’s far from ideal in non-interactive contexts. It’s especially disappointing since you could easily imagine something like Julia replicating Python’s success at transitioning code from interaction (e.g. Jupyter notebook) to production. I initially defended the choice, but I now agree that 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success.
- peatmoss 8y ago
  > 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success. I’m curious as to why this is a problem outside numerical computing. From my perspective, this is consistent with a long history of mathematics dealing with matrices that predates electronic computers. 0-based arrays are popular because C decided to deviate from what had previously been standard in math and in Fortran. Is there a reason other than aesthetic preference and habit that makes 0-based indexes better for computing in non-numerical contexts? I realize both indexing standards are arbitrary and boil down to “that’s the way grandpa did it,” however 1-based indexing grandpa is way older and more entrenched outside computing circles. EDIT: I suppose with Julia it’s not that important, as other commenters have pointed out that you can choose arbitrary indexes.
  - kgwgk 8y ago
    > the technical reason we started counting arrays at zero is that in the mid-1960’s, you could shave a few cycles off of a program’s compilation time on an IBM 7094. The social reason is that we had to save every cycle we could, because if the job didn’t finish fast it might not finish at all and you never know when you’re getting bumped off the hardware because the President of IBM just called and fuck your thesis, it’s yacht-racing time. http://exple.tive.org/blarg/2013/10/22/citation-needed/ http://exple.tive.org/blarg/2013/10/22/citation-needed/
    - peatmoss 8y ago
      Wow, I hadn’t seen this before. The history of this feud goes back before C. Thank you for a fascinating read!
      - jandrese 8y ago
        Even Dijkstra weighed in on this: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
        e12e 8y ago
        I've always found this a rather weak argument - he even implies that 2...12 is at least as clear (it being the starting point of the text). I also thought I'd seen a longer text focusing more on the counting/indexing. I still don't see the appeal of "element at zero offset" vs simply "first element". I do agree that < vs <= etc can get messy. But outside of now fairly archaic programming languages I don't see the need. Just use a construct that handles ranges, like "for each element in collection/range/etc". (Or for math, "pattern matching" (or "for n in 1..m").
        disgruntledphd2 8y ago
        I believe that may be cited in the article (but its not in an obvious place :) )
    - 8y ago
- deleted 8y ago
  [deleted]
- renox 8y ago
  > I initially defended the choice, but I now agree that 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success Especially since it would have been very easy to 'do it like Ada' and allow any start index by default (I have use Lua and it's really annoying to use an extension language with 1-index when the base language is 0-indexed)
  - kleff 8y ago
    Even Visual Basic (of all things) allowed you to set it with Option Base. Never really understood why its not supported in more languages...
    - pjmlp 8y ago
      Because due to UNIX's adoption every programming language needed to be like C. Until then Fortran, Lisp, Algol, Pascal, Basic never had any big issue with indexes.
    - oxinabox 8y ago
      because the whole Option Foo stuff that Visual Basic had, is a hideous global state thing that makes it hard to reason about code without checking for what it's options were set to. Programming languages should not be configurable in that kind of way.
  - jebej 8y ago
    You can use whatever start index you like: https://docs.julialang.org/en/stable/devdocs/offset-arrays/#man-custom-indices-1 https://docs.julialang.org/en/stable/devdocs/offset-arrays/#... For a pre-baked solution: https://github.com/JuliaArrays/OffsetArrays.jl https://github.com/JuliaArrays/OffsetArrays.jl
    - renox 8y ago
      The problem is the default behaviour: in Ada you can use whatever you want, in Julia the default is 1-based which is quite controversial.
- ChrisRackauckas 8y ago
  This is what 0-based indexing looks like in data analysis: >In order to read a csv in that doesn't have a header and for only certain columns you need to pass params header=None and usecols=[3,6] for the 4th and 7th columns: https://stackoverflow.com/questions/29287224/pandas-read-in-table-without-headers https://stackoverflow.com/questions/29287224/pandas-read-in-... Just reading that hurts me.
  - dangom 8y ago
    This is very much a non-argument. Call the columns the 4th and 7th is as arbitrary as calling them the 3rd and the 6th. Again, 0-based indexing exists to fit a purpose: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW... In my opinion, reading `a = b[1:n-1]` hurts much more than reading `a = b[:n]`.
    - coldtea 8y ago
      >Call the columns the 4th and 7th is as arbitrary as calling them the 3rd and the 6th. No, that's their ordinal position, and how 8 billion non-programmers would refer them as in any everyday setting. That's also how programmers would refer to them if it wasn't for a historical accident. What's more, that's also how programmers refer to them when they talk between then and not to the machine ("check the 3rd column" not "check the column at the index of 2").
    - e12e 8y ago
      a = b[1..n]?
    - DNF2 8y ago
      The equivalent of `a = b[:n]` is `a = b[1:n]`. And I don't think you can get around admitting that there is a fundamental ambiguity in the spoken statement "Take a look at the fourth column!" in a zero-based index system. You always need a follow-up question to clarify whether you mean "everyday informal speech fourth" or "zero-index fourth."
      - 8y ago
- ScottPJones 8y ago
  Three years ago, when I found out about Julia (and quickly fell in love with the language), I not happy at all about the 1-based indices and column-major storage, and at the time, a lot of the responses I got were along the lines of "Julia is for mathematicians, and 1-based indexing and column major are just fine for us". Now, Julia is able to have indices with any base that you want, and can handle row-major storage as well (thanks to Tim Holy's great work). Why is anybody concerned about this anymore? Julia can do whatever you want, you shouldn't be stuck with languages that can ONLY do 0-based indexing.
29galoseats 8y ago
I had a similar reaction about this being a little premature. On the other hand, I'm wondering if this will help a little with the dependency hell that's caused me to drift away from Julia over the last year or so. At first I was fairly excited about Julia, and greatly preferred it over R or Python for numerical work, library resources aside. It was fast and I liked the language design itself. Over the last year or two, though, I've had recurring problems with trying to install and use packages, and them failing at some point due to some dependency not working. Sometimes the target package itself won't install, but most of the time it's some lower-level package. It's more frustrating than not having packages available, because it creates some sense that packages are available, when they're not. At first I looked at it as some idiosyncratic case with one package, but it's happened over and over and over again. Basically in this time I've given up on Julia, because there's such a huge discrepancy between what it looks like on the surface and what it looks like in practice, once you get out of certain limited-use cases, or when you're not coding everything yourself from the base language. (Related concerns about misleading speed claims have been raised, although my personal experience in that regard has been mixed, because my experience overall has been pretty good in some critical performance cases, but there have also been some wildly unpredictable exceptions that act as bottlenecks... but it's still much better than R or Python). When I've tried to figure out what's going on with dependency hell, usually it's because some package that was previously working with a earlier version is no longer working. So maybe stabilizing the language will help that?
- celrod 8y ago
  Because there are a lot less packages with binary dependencies, I've overall had less problems than work R. Most packages are pure Julia, and there you shouldn't face issues. With the new binary builder, binaries should be another note, so long as you download an official Julia binary, or built Julia from source in the same way those binaries are made (eg, build OpenBLAS with gfortran 7).
- vorpalhex 8y ago
  Package management is a really-really-really difficult problem that is far from solved. Not to say that your critiques are invalid (quite the opposite), but Julia is just now hitting 1.0 - by contrast Node/NPM have been around quite a bit longer and still have terrible package issues they're working to solve. If you can, try and find a few hours to help pitch in and solve the package problems, even if it's just updating docs or updating deprecated-but-useful packages.
ChrisFoster 8y ago
In 0.7 I put quite a lot of design effort into the logging system to allow log records to be redirected in a sane way. It's by no means a complete system, but I think the changes were worthwhile and the core infrastructure is now in place to allow consistent and structured capture of messages from any package which uses the Base logging interface. Exception handling is indeed somewhat of a wart with the core system not having changed much since very early on. I think there's still some serious design work to do and the core people take it seriously. On the other hand, I suspect that numerical codes don't want to use exceptions for much other than "panic and escape to an extreme outer scope". So a lot of the scientific users are probably content for the time being.
simonbyrne 8y ago
I don't think _any_ language has got exception handling handling right yet, despite a lot of effort. The problems are particularly apparent in parallel and multithreaded programs. That said, I am optimistic Julia will have a good solution at some point: contextual dispatch, a la Cassette.jl, enables just the sought of interventions you want for error handling. I'm not quite sure what the result will look like, but I imagine you will see some experimentation in this direction in the near future.
KenoFischer 8y ago
Exception handling is one of the few subsystems that hasn't really had a revamp. It's probably one of the areas that'll get a good bit of thinking post 1.0.
- StefanKarpinski 8y ago
  Also: not allowing the expected `catch e::ErrorType` syntax leaves it open for a better design without breaking existing code which means it can be done in the 1.x timeframe instead of needing to wait until 2.0. This is why that syntax hasn't yet been added with the expected meaning. Related: https://github.com/JuliaLang/julia/issues/7026 https://github.com/JuliaLang/julia/issues/7026
realSlavojTrump 8y ago
This is most certainly an area that needs improvement. You can get around some of the pain of haning error types in catch statements if you are comfortable paying the price for a locally defined function: result = try Something() catch err h!(e)=throw(e) h!(e::MethodError) = SomethingElse() h!(err) end This pattern works well if an error case should return a default value and all others should throw.

Q6T46nT668w6i3m 8y ago

Yeah, I agree with your comments about error handling. It’s far from ideal in non-interactive contexts. It’s especially disappointing since you could easily imagine something like Julia replicating Python’s success at transitioning code from interaction (e.g. Jupyter notebook) to production. I initially defended the choice, but I now agree that 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success.

peatmoss 8y ago
> 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success. I’m curious as to why this is a problem outside numerical computing. From my perspective, this is consistent with a long history of mathematics dealing with matrices that predates electronic computers. 0-based arrays are popular because C decided to deviate from what had previously been standard in math and in Fortran. Is there a reason other than aesthetic preference and habit that makes 0-based indexes better for computing in non-numerical contexts? I realize both indexing standards are arbitrary and boil down to “that’s the way grandpa did it,” however 1-based indexing grandpa is way older and more entrenched outside computing circles. EDIT: I suppose with Julia it’s not that important, as other commenters have pointed out that you can choose arbitrary indexes.
- kgwgk 8y ago
  > the technical reason we started counting arrays at zero is that in the mid-1960’s, you could shave a few cycles off of a program’s compilation time on an IBM 7094. The social reason is that we had to save every cycle we could, because if the job didn’t finish fast it might not finish at all and you never know when you’re getting bumped off the hardware because the President of IBM just called and fuck your thesis, it’s yacht-racing time. http://exple.tive.org/blarg/2013/10/22/citation-needed/ http://exple.tive.org/blarg/2013/10/22/citation-needed/
  - peatmoss 8y ago
    Wow, I hadn’t seen this before. The history of this feud goes back before C. Thank you for a fascinating read!
    - jandrese 8y ago
      Even Dijkstra weighed in on this: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
      - e12e 8y ago
        I've always found this a rather weak argument - he even implies that 2...12 is at least as clear (it being the starting point of the text). I also thought I'd seen a longer text focusing more on the counting/indexing. I still don't see the appeal of "element at zero offset" vs simply "first element". I do agree that < vs <= etc can get messy. But outside of now fairly archaic programming languages I don't see the need. Just use a construct that handles ranges, like "for each element in collection/range/etc". (Or for math, "pattern matching" (or "for n in 1..m").
      - disgruntledphd2 8y ago
        I believe that may be cited in the article (but its not in an obvious place :) )
  - 8y ago
deleted 8y ago
[deleted]
renox 8y ago
> I initially defended the choice, but I now agree that 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success Especially since it would have been very easy to 'do it like Ada' and allow any start index by default (I have use Lua and it's really annoying to use an extension language with 1-index when the base language is 0-indexed)
- kleff 8y ago
  Even Visual Basic (of all things) allowed you to set it with Option Base. Never really understood why its not supported in more languages...
  - pjmlp 8y ago
    Because due to UNIX's adoption every programming language needed to be like C. Until then Fortran, Lisp, Algol, Pascal, Basic never had any big issue with indexes.
  - oxinabox 8y ago
    because the whole Option Foo stuff that Visual Basic had, is a hideous global state thing that makes it hard to reason about code without checking for what it's options were set to. Programming languages should not be configurable in that kind of way.
- jebej 8y ago
  You can use whatever start index you like: https://docs.julialang.org/en/stable/devdocs/offset-arrays/#man-custom-indices-1 https://docs.julialang.org/en/stable/devdocs/offset-arrays/#... For a pre-baked solution: https://github.com/JuliaArrays/OffsetArrays.jl https://github.com/JuliaArrays/OffsetArrays.jl
  - renox 8y ago
    The problem is the default behaviour: in Ada you can use whatever you want, in Julia the default is 1-based which is quite controversial.
ChrisRackauckas 8y ago
This is what 0-based indexing looks like in data analysis: >In order to read a csv in that doesn't have a header and for only certain columns you need to pass params header=None and usecols=[3,6] for the 4th and 7th columns: https://stackoverflow.com/questions/29287224/pandas-read-in-table-without-headers https://stackoverflow.com/questions/29287224/pandas-read-in-... Just reading that hurts me.
- dangom 8y ago
  This is very much a non-argument. Call the columns the 4th and 7th is as arbitrary as calling them the 3rd and the 6th. Again, 0-based indexing exists to fit a purpose: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW... In my opinion, reading `a = b[1:n-1]` hurts much more than reading `a = b[:n]`.
  - coldtea 8y ago
    >Call the columns the 4th and 7th is as arbitrary as calling them the 3rd and the 6th. No, that's their ordinal position, and how 8 billion non-programmers would refer them as in any everyday setting. That's also how programmers would refer to them if it wasn't for a historical accident. What's more, that's also how programmers refer to them when they talk between then and not to the machine ("check the 3rd column" not "check the column at the index of 2").
  - e12e 8y ago
    a = b[1..n]?
  - DNF2 8y ago
    The equivalent of `a = b[:n]` is `a = b[1:n]`. And I don't think you can get around admitting that there is a fundamental ambiguity in the spoken statement "Take a look at the fourth column!" in a zero-based index system. You always need a follow-up question to clarify whether you mean "everyday informal speech fourth" or "zero-index fourth."
    - 8y ago
ScottPJones 8y ago
Three years ago, when I found out about Julia (and quickly fell in love with the language), I not happy at all about the 1-based indices and column-major storage, and at the time, a lot of the responses I got were along the lines of "Julia is for mathematicians, and 1-based indexing and column major are just fine for us". Now, Julia is able to have indices with any base that you want, and can handle row-major storage as well (thanks to Tim Holy's great work). Why is anybody concerned about this anymore? Julia can do whatever you want, you shouldn't be stuck with languages that can ONLY do 0-based indexing.

29galoseats 8y ago

I had a similar reaction about this being a little premature. On the other hand, I'm wondering if this will help a little with the dependency hell that's caused me to drift away from Julia over the last year or so. At first I was fairly excited about Julia, and greatly preferred it over R or Python for numerical work, library resources aside. It was fast and I liked the language design itself. Over the last year or two, though, I've had recurring problems with trying to install and use packages, and them failing at some point due to some dependency not working. Sometimes the target package itself won't install, but most of the time it's some lower-level package. It's more frustrating than not having packages available, because it creates some sense that packages are available, when they're not. At first I looked at it as some idiosyncratic case with one package, but it's happened over and over and over again. Basically in this time I've given up on Julia, because there's such a huge discrepancy between what it looks like on the surface and what it looks like in practice, once you get out of certain limited-use cases, or when you're not coding everything yourself from the base language. (Related concerns about misleading speed claims have been raised, although my personal experience in that regard has been mixed, because my experience overall has been pretty good in some critical performance cases, but there have also been some wildly unpredictable exceptions that act as bottlenecks... but it's still much better than R or Python). When I've tried to figure out what's going on with dependency hell, usually it's because some package that was previously working with a earlier version is no longer working. So maybe stabilizing the language will help that?

celrod 8y ago
Because there are a lot less packages with binary dependencies, I've overall had less problems than work R. Most packages are pure Julia, and there you shouldn't face issues. With the new binary builder, binaries should be another note, so long as you download an official Julia binary, or built Julia from source in the same way those binaries are made (eg, build OpenBLAS with gfortran 7).
vorpalhex 8y ago
Package management is a really-really-really difficult problem that is far from solved. Not to say that your critiques are invalid (quite the opposite), but Julia is just now hitting 1.0 - by contrast Node/NPM have been around quite a bit longer and still have terrible package issues they're working to solve. If you can, try and find a few hours to help pitch in and solve the package problems, even if it's just updating docs or updating deprecated-but-useful packages.

ChrisFoster 8y ago

In 0.7 I put quite a lot of design effort into the logging system to allow log records to be redirected in a sane way. It's by no means a complete system, but I think the changes were worthwhile and the core infrastructure is now in place to allow consistent and structured capture of messages from any package which uses the Base logging interface. Exception handling is indeed somewhat of a wart with the core system not having changed much since very early on. I think there's still some serious design work to do and the core people take it seriously. On the other hand, I suspect that numerical codes don't want to use exceptions for much other than "panic and escape to an extreme outer scope". So a lot of the scientific users are probably content for the time being.

simonbyrne 8y ago

I don't think _any_ language has got exception handling handling right yet, despite a lot of effort. The problems are particularly apparent in parallel and multithreaded programs. That said, I am optimistic Julia will have a good solution at some point: contextual dispatch, a la Cassette.jl, enables just the sought of interventions you want for error handling. I'm not quite sure what the result will look like, but I imagine you will see some experimentation in this direction in the near future.

KenoFischer 8y ago

Exception handling is one of the few subsystems that hasn't really had a revamp. It's probably one of the areas that'll get a good bit of thinking post 1.0.

StefanKarpinski 8y ago
Also: not allowing the expected `catch e::ErrorType` syntax leaves it open for a better design without breaking existing code which means it can be done in the 1.x timeframe instead of needing to wait until 2.0. This is why that syntax hasn't yet been added with the expected meaning. Related: https://github.com/JuliaLang/julia/issues/7026 https://github.com/JuliaLang/julia/issues/7026

realSlavojTrump 8y ago

This is most certainly an area that needs improvement. You can get around some of the pain of haning error types in catch statements if you are comfortable paying the price for a locally defined function: result = try Something() catch err h!(e)=throw(e) h!(e::MethodError) = SomethingElse() h!(err) end This pattern works well if an error case should return a default value and all others should throw.