4 ms·

Writing Iterators in Julia 0.7

99 points by iamed2 8y ago

invmatth 8y ago
Exciting times for the Julia community!
ChrisRackauckas 8y ago
Good stuff! While it's nice that the change made things cleaner, it's great to see it laid out in a more "why should I care?" fashion.
abakus 8y ago
Code with a mix of Y%#$ and lower_UPPER_CamelCase looks ugly.
- sbjs 8y ago
  Every language looks ugly to someone who doesn't need it ;) I have learned to ignore the inconsistencies in the languages that I have to use, especially if it's for a paying gig. Otherwise I would go crazy! Every single language has them, I'm not kidding.
  - s-shellfish 8y ago
    That's a nice practice
- tejtm 8y ago
  Less so when you see strongly typed system which _you_ authored which is every bit as native as the 'Native' type system we sometimes wish other languages we use in practice had at all.
- invmatth 8y ago
  Fairly subjective, it is easily readable at least.
- ellisv 8y ago
  Just wait until you see Julia's unicode input - you can use pretty emojis instead of ugly "Y%#$ and lower_UPPER_CamelCase"!
- jey 8y ago
  The naming conventions are all very sensible, but I can see how it looks funny if you aren't fluent in Julia.
  - dnautics 8y ago
    In case anyone doesn't know, the Julia convention is: UpperCamelCase: modules & types snake_case: variables and functions This convention is shared, for example, with elixir (also FP Lang) Also bang_functions! By convention, not enforced, indicate that the function may mutate one of its passed parameters. (Taken from Ruby's "be careful with this member function" idiom) @at_sigil: macros (enforced by the language)
    - idunning 8y ago
      Its also very similar to many opinionated Python style guides (minus the !, and where @ is used for decorators [which are a bit meta like macros])
    - simen 8y ago
      Ruby uses the same convention. (excluding macros, and adding question_mark_predicates?) I've seen C++ projects that adopt the same style. I don't see what's so objectionable about it.
- JadeNB 8y ago
  > Code with a mix of Y%#$ and lower_UPPER_CamelCase looks ugly. What is Y%#$?
  - simonbyrne 8y ago
    Well, in Julia it's an incomplete expression (Y is a variable, % is the infix operator for remainder, and # a line comment (the $ is used for string/command interpolation, but is commented out).
    - JadeNB 8y ago
      Given that some of the characters in the original were italicised, I think that there were probably some stars in there that Markdown ate. My question wasn't really what operation it performs or tries to perform, but rather what abakus (https://news.ycombinator.com/item?id=17473616 https://news.ycombinator.com/item?id=17473616) meant by comparison with lower_UPPER_CamelCase.
cutler 8y ago
Someone wake me up when Julia reaches 1.0
- newen 8y ago
  Wouldn't hold my breath even then. They decided to split a lot of functionality in Julia into a standard library, which they will keep changing indefinitely. There goes my hope of Julia having any API stability.
  - KenoFischer 8y ago
    Alternatively, you may see this as a sign that we've thought carefully about which APIs are stable enough to be part of the long term stability guarantees of 1.0, and which APIs are not, making it more likely that we'll able to maintain those guarantees longer. Also, there nothing really special about code that used to be in base, but is now in stdlib other than historical accident. It so happened that we used to ship a git client as part of the language, but the HTTP client was a separate package, despite the latter probably being a lot more useful to users. Packages can and do have their own stability guarantees. With the language itself maturing, I imagine package authors will start taking advantage of this more.
    - newen 8y ago
      Yes I get your viewpoint about long term stability guarantees and feel it's valid to a certain degree. But I waiting for so many years for Julia 1.0 while expecting the entire language (base + stdlib) to have API stability for at least a few years, and hopefully many many years, like Fortran or at least Matlab. Also, I wish you guys would have some overarching philosophy w.r.t API stability in the stdlib. From looking at the github, it seems like the core developers are just delegating API change decisions in the standard library to new people who are not as familiar with the code base, without much discussion at all. I just don't think that is the way the stdlib should be managed.
  - chappi42 8y ago
    With Pkg(3) you can lock library versions (including standard library). As the Julia API won't change in 1.x it won't break after upgrading. You should be fine. On the other hand, as far as I understand, 1.0 means that the API is stable but not that all 'luxury' features (debugger, Atom/VSC code integration, etc) are perfectly working and/or even ready. This will come in future (it needs a stable API).
omaranto 8y ago
This change also fixes the Julia issue that bothered me the most personally: if in a comprehension with nested loops any of the non-outermost ones was over an empty sequence, you'd get an error.

99 points by iamed2 8y ago

Exciting times for the Julia community!

Good stuff! While it's nice that the change made things cleaner, it's great to see it laid out in a more "why should I care?" fashion.

abakus 8y ago

Code with a mix of Y%#$ and lower_UPPER_CamelCase looks ugly.

sbjs 8y ago
Every language looks ugly to someone who doesn't need it ;) I have learned to ignore the inconsistencies in the languages that I have to use, especially if it's for a paying gig. Otherwise I would go crazy! Every single language has them, I'm not kidding.
- s-shellfish 8y ago
  That's a nice practice
tejtm 8y ago
Less so when you see strongly typed system which _you_ authored which is every bit as native as the 'Native' type system we sometimes wish other languages we use in practice had at all.
invmatth 8y ago
Fairly subjective, it is easily readable at least.
ellisv 8y ago
Just wait until you see Julia's unicode input - you can use pretty emojis instead of ugly "Y%#$ and lower_UPPER_CamelCase"!
jey 8y ago
The naming conventions are all very sensible, but I can see how it looks funny if you aren't fluent in Julia.
- dnautics 8y ago
  In case anyone doesn't know, the Julia convention is: UpperCamelCase: modules & types snake_case: variables and functions This convention is shared, for example, with elixir (also FP Lang) Also bang_functions! By convention, not enforced, indicate that the function may mutate one of its passed parameters. (Taken from Ruby's "be careful with this member function" idiom) @at_sigil: macros (enforced by the language)
  - idunning 8y ago
    Its also very similar to many opinionated Python style guides (minus the !, and where @ is used for decorators [which are a bit meta like macros])
  - simen 8y ago
    Ruby uses the same convention. (excluding macros, and adding question_mark_predicates?) I've seen C++ projects that adopt the same style. I don't see what's so objectionable about it.
JadeNB 8y ago
> Code with a mix of Y%#$ and lower_UPPER_CamelCase looks ugly. What is Y%#$?
- simonbyrne 8y ago
  Well, in Julia it's an incomplete expression (Y is a variable, % is the infix operator for remainder, and # a line comment (the $ is used for string/command interpolation, but is commented out).
  - JadeNB 8y ago
    Given that some of the characters in the original were italicised, I think that there were probably some stars in there that Markdown ate. My question wasn't really what operation it performs or tries to perform, but rather what abakus (https://news.ycombinator.com/item?id=17473616 https://news.ycombinator.com/item?id=17473616) meant by comparison with lower_UPPER_CamelCase.

cutler 8y ago

Someone wake me up when Julia reaches 1.0

newen 8y ago
Wouldn't hold my breath even then. They decided to split a lot of functionality in Julia into a standard library, which they will keep changing indefinitely. There goes my hope of Julia having any API stability.
- KenoFischer 8y ago
  Alternatively, you may see this as a sign that we've thought carefully about which APIs are stable enough to be part of the long term stability guarantees of 1.0, and which APIs are not, making it more likely that we'll able to maintain those guarantees longer. Also, there nothing really special about code that used to be in base, but is now in stdlib other than historical accident. It so happened that we used to ship a git client as part of the language, but the HTTP client was a separate package, despite the latter probably being a lot more useful to users. Packages can and do have their own stability guarantees. With the language itself maturing, I imagine package authors will start taking advantage of this more.
  - newen 8y ago
    Yes I get your viewpoint about long term stability guarantees and feel it's valid to a certain degree. But I waiting for so many years for Julia 1.0 while expecting the entire language (base + stdlib) to have API stability for at least a few years, and hopefully many many years, like Fortran or at least Matlab. Also, I wish you guys would have some overarching philosophy w.r.t API stability in the stdlib. From looking at the github, it seems like the core developers are just delegating API change decisions in the standard library to new people who are not as familiar with the code base, without much discussion at all. I just don't think that is the way the stdlib should be managed.
- chappi42 8y ago
  With Pkg(3) you can lock library versions (including standard library). As the Julia API won't change in 1.x it won't break after upgrading. You should be fine. On the other hand, as far as I understand, 1.0 means that the API is stable but not that all 'luxury' features (debugger, Atom/VSC code integration, etc) are perfectly working and/or even ready. This will come in future (it needs a stable API).

omaranto 8y ago

This change also fixes the Julia issue that bothered me the most personally: if in a comprehension with nested loops any of the non-outermost ones was over an empty sequence, you'd get an error.