7 ms·

Much praise!! These guys have incredibly good taste. Almost every single thing I can think of that I want in a programming language, they have it. All in the on

by wbhart 15y ago

Much praise!! These guys have incredibly good taste. Almost every single thing I can think of that I want in a programming language, they have it. All in the one language! The fact that it has parametric types, parametric polymorphism, macros, performance almost as good as C, good C/Fortran interop, 64 bit integers and an interactive REPL all in the one language just blows my mind. I wasn't able to tell if it is possible to overload operators, which is another thing essential to mathematical code. I was also unsure why the keyword end was needed at the end of code blocks. It seems that indentation could take care of that. I also didn't see bignums as a default type (though you can use an external library to get them). However, all in all, I think this is the first 21st Century language and find it very exciting!

ludwigvan 15y ago
I think they are aiming for smooth transition for MATLAB users. They also have 1-index based arrays as opposed to 0-index .
- wbhart 15y ago
  It would certainly be nice if there was an option to use 0 based indices in blocks of code. It's understandable in that they are pitching at the technical community, and many mathematical papers and books are written with 1 based indices. But I am a mathematician who prefers 0 based indices.
  - fijal 15y ago
    It seems like both 0 and 1 based arrays is asking for trouble :) I would prefer 0-based, but still prefer 1-based to mixed or optional.
    - javajosh 15y ago
      We are scientists and so willing to compromise, yes? So how about 0.5-based arrays? :)
      - Danieru 15y ago
        Only if it is in base .5
  - ViralBShah 15y ago
    Actually, it is quite easy to implement 0 based indices or any other indexing scheme in julia, since all the array indexing code is implemented in julia itself. https://github.com/JuliaLang/julia/blob/master/j/array.j#L157 https://github.com/JuliaLang/julia/blob/master/j/array.j#L15... I personally would find multiple indexing schemes confusing both for usage as well as to develop and maintain. Given that 1 based indexing seems to be a popular choice among many similar languages, we just went ahead with that.
    - chancho 15y ago
      Have you looked at the Haskell Ix class? http://www.haskell.org/onlinereport/ix.html http://www.haskell.org/onlinereport/ix.html It generalizes the choice of 0 or 1 to an arbitrary starting index. So when you create an array you specify not just where it ends but also where it begins. This lets you do neat things (consider a filter kernel with range [-s,+s]^n instead of [1,2s]^n) and the extra complexity it adds can be hidden when not needed using for-statements or higher order functions. Nobody uses it because the implementation is not very efficient and Haskellers have a chip on their shoulder about performance. It subtracts the origin and computes strides on every index, but you could easily avoid this by storing the subtracted base pointer and strides with the array. Of course when you go to implement it you'll see light on 0-based indexing :)
    - wbhart 15y ago
      The problem with changing it in the library is that you'd also have to change it everywhere arrays are used in Julia itself. The only way I could think to manage it would be a pragma which switches 0-based on for a given file. But this is doubtlessly not trivial. Or there is the less elegant option of introducing a new operator for 0-based arrays. But this is liable to cause confusion I think.
  - svdad 15y ago
    Perl still has this with $[ but it's deprecated as of 5.12.
- maximilian 15y ago
  Fortran is 1-index as well. I think MATLAB gets its notational style from Fortran.
  - ludwigvan 15y ago
    Actually, broadly speaking, I think math (think summation etc.) in general is usually 1-index based while programming is 0-index (due to memory locations so that the array index also points to the first element?). Also see Dijkstra's take on the matter: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF for
    - StefanKarpinski 15y ago
      At first we were going to use 0-based indexing, but it made porting any Matlab code over very hard, which defeats a large part of the purpose of having Matlab-like syntax in the first place — to leverage the large amount of Matlab code and expertise that exists out there. However, as I've used it more and more, 1-based indexing has really grown on me. I feel like I make far fewer off-by-one errors and actually hardly ever have to think about them. This has led me to conclude that 1-based indexing is probably easier for humans while 0-based indexing is clearly easier for computers.
      - wbhart 15y ago
        Many divide-and-conquer algorithms seem to be easier to express with 0 based indexing, whereas quite a few array operations seem to be better with 1 based indexing. I can certainly understand and appreciate the different points of view, I just personally always think about algorithms with 0-based arrays.
        warmfuzzykitten 15y ago
        As does anyone trained in the C tradition, but it's annoying, too, to have to translate 1-based math formulas to the C convention. Having recently used Octave for the Stanford online ML class after a couple decades of C, C++ and Java, I doubt programmers will have trouble with the mental transition.
- TheoLib 15y ago
  A number of programming languages allow an arbitrary range of indices for an array, including Ada, Fortran 77, and Pascal. See the "Specifiable Base Index" column in this table at Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)#Array_system_cross-reference_list http://en.wikipedia.org/wiki/Comparison_of_programming_langu...
- Bromskloss 15y ago
  Actually, the main reason I want to do away with Matlab and Octave is that I can't stand the 1-indexing! When voicing that opinion among collegues, I have heard no-one disagree with me. If you are actually stuck with this in Julia as well, I don't think I will have anything more to do with it.
cheald 15y ago
When reading through the manual, I was struck at how similar the language seems to be to Lua, at least superficially. Lua also has 1-based arrays. Heh.
- marshray 15y ago
  I noticed that too. The language syntax seemed uninteresting, which is not really a bad thing but what's the case for the need for a whole 'nother language in that category?
- moonchrome 15y ago
  >64 bit integers I don't think lua has integers ie. like Javascript everything is a double, that can be changed by redefining a macro and recompiling AFAIK but it's still one global numeric type (and you can't change it for luajit).
  - cheald 15y ago
    No; there are definitely some major differences between the two languages, but they seem to have a lot of similarities. Julia's obviously made for scientific work, and Lua's a general-purpose scripting language designed to be embedded in a host application, but they seem to have a lot of design constructs in common.
StefanKarpinski 15y ago
Thanks for the incredibly high praise. It definitely is possible to overload operators — operators are just functions with special syntax (see http://julialang.org/manual/functions/#Operators+Are+Functions http://julialang.org/manual/functions/#Operators+Are+Functio...). We don't have bignum support, but adding it via GMP would be fairly easy. Just too many things to do!
- wbhart 15y ago
  Great news about the operators. I didn't see an example of overloading there, but I probably rushed through it a bit quickly. I have been working on and off on a BSD licensed bignum library. Maybe in a few years....
  - StefanKarpinski 15y ago
    If you happened to feel like trying to port it to Julia, it would be fairly doable. All the low-level functionality is there to allow it — bit twiddling operations, growable dense arrays of integers, etc.
    - wbhart 15y ago
      Unfortunately the performance would be poor. This is not a reflection on Julia. Even compiled C is between 4 and 12 times slower than assembly for some bignum operations. Also, LLVM handles carries and certain loop optimisations poorly, so even using LLVM bytecode you can't do much better than compiled C. It would be a massive project to improve this in LLVM (I thought about giving it a go sone time ago but decided it was overwhelming). And that use case is probably too specialised for the improvements to help with much else. Obviously the LLVM backend is fantastic for 99% of use cases and improving all the time. N.B. I am not implying that a good assembly programmer is generically faster than a C compiler. Bignums are a very special case.
      - StefanKarpinski 15y ago
        That makes a whole lot of sense. For myself, I wouldn't even attempt this because it's so much harder and more time-consuming to try to reimplement something like bignums efficiently than it is to just use a stable, mature and fast external library like GMP or CLN — or something like your project if BSD/MIT licensing is a must.

by wbhart 15y ago

ludwigvan 15y ago

I think they are aiming for smooth transition for MATLAB users. They also have 1-index based arrays as opposed to 0-index .

wbhart 15y ago
It would certainly be nice if there was an option to use 0 based indices in blocks of code. It's understandable in that they are pitching at the technical community, and many mathematical papers and books are written with 1 based indices. But I am a mathematician who prefers 0 based indices.
- fijal 15y ago
  It seems like both 0 and 1 based arrays is asking for trouble :) I would prefer 0-based, but still prefer 1-based to mixed or optional.
  - javajosh 15y ago
    We are scientists and so willing to compromise, yes? So how about 0.5-based arrays? :)
    - Danieru 15y ago
      Only if it is in base .5
- ViralBShah 15y ago
  Actually, it is quite easy to implement 0 based indices or any other indexing scheme in julia, since all the array indexing code is implemented in julia itself. https://github.com/JuliaLang/julia/blob/master/j/array.j#L157 https://github.com/JuliaLang/julia/blob/master/j/array.j#L15... I personally would find multiple indexing schemes confusing both for usage as well as to develop and maintain. Given that 1 based indexing seems to be a popular choice among many similar languages, we just went ahead with that.
  - chancho 15y ago
    Have you looked at the Haskell Ix class? http://www.haskell.org/onlinereport/ix.html http://www.haskell.org/onlinereport/ix.html It generalizes the choice of 0 or 1 to an arbitrary starting index. So when you create an array you specify not just where it ends but also where it begins. This lets you do neat things (consider a filter kernel with range [-s,+s]^n instead of [1,2s]^n) and the extra complexity it adds can be hidden when not needed using for-statements or higher order functions. Nobody uses it because the implementation is not very efficient and Haskellers have a chip on their shoulder about performance. It subtracts the origin and computes strides on every index, but you could easily avoid this by storing the subtracted base pointer and strides with the array. Of course when you go to implement it you'll see light on 0-based indexing :)
  - wbhart 15y ago
    The problem with changing it in the library is that you'd also have to change it everywhere arrays are used in Julia itself. The only way I could think to manage it would be a pragma which switches 0-based on for a given file. But this is doubtlessly not trivial. Or there is the less elegant option of introducing a new operator for 0-based arrays. But this is liable to cause confusion I think.
- svdad 15y ago
  Perl still has this with $[ but it's deprecated as of 5.12.
maximilian 15y ago
Fortran is 1-index as well. I think MATLAB gets its notational style from Fortran.
- ludwigvan 15y ago
  Actually, broadly speaking, I think math (think summation etc.) in general is usually 1-index based while programming is 0-index (due to memory locations so that the array index also points to the first element?). Also see Dijkstra's take on the matter: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF for
  - StefanKarpinski 15y ago
    At first we were going to use 0-based indexing, but it made porting any Matlab code over very hard, which defeats a large part of the purpose of having Matlab-like syntax in the first place — to leverage the large amount of Matlab code and expertise that exists out there. However, as I've used it more and more, 1-based indexing has really grown on me. I feel like I make far fewer off-by-one errors and actually hardly ever have to think about them. This has led me to conclude that 1-based indexing is probably easier for humans while 0-based indexing is clearly easier for computers.
    - wbhart 15y ago
      Many divide-and-conquer algorithms seem to be easier to express with 0 based indexing, whereas quite a few array operations seem to be better with 1 based indexing. I can certainly understand and appreciate the different points of view, I just personally always think about algorithms with 0-based arrays.
      - warmfuzzykitten 15y ago
        As does anyone trained in the C tradition, but it's annoying, too, to have to translate 1-based math formulas to the C convention. Having recently used Octave for the Stanford online ML class after a couple decades of C, C++ and Java, I doubt programmers will have trouble with the mental transition.
TheoLib 15y ago
A number of programming languages allow an arbitrary range of indices for an array, including Ada, Fortran 77, and Pascal. See the "Specifiable Base Index" column in this table at Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)#Array_system_cross-reference_list http://en.wikipedia.org/wiki/Comparison_of_programming_langu...
Bromskloss 15y ago
Actually, the main reason I want to do away with Matlab and Octave is that I can't stand the 1-indexing! When voicing that opinion among collegues, I have heard no-one disagree with me. If you are actually stuck with this in Julia as well, I don't think I will have anything more to do with it.

cheald 15y ago

When reading through the manual, I was struck at how similar the language seems to be to Lua, at least superficially. Lua also has 1-based arrays. Heh.

marshray 15y ago
I noticed that too. The language syntax seemed uninteresting, which is not really a bad thing but what's the case for the need for a whole 'nother language in that category?
moonchrome 15y ago
>64 bit integers I don't think lua has integers ie. like Javascript everything is a double, that can be changed by redefining a macro and recompiling AFAIK but it's still one global numeric type (and you can't change it for luajit).
- cheald 15y ago
  No; there are definitely some major differences between the two languages, but they seem to have a lot of similarities. Julia's obviously made for scientific work, and Lua's a general-purpose scripting language designed to be embedded in a host application, but they seem to have a lot of design constructs in common.

StefanKarpinski 15y ago

Thanks for the incredibly high praise. It definitely is possible to overload operators — operators are just functions with special syntax (see http://julialang.org/manual/functions/#Operators+Are+Functions http://julialang.org/manual/functions/#Operators+Are+Functio...). We don't have bignum support, but adding it via GMP would be fairly easy. Just too many things to do!

wbhart 15y ago
Great news about the operators. I didn't see an example of overloading there, but I probably rushed through it a bit quickly. I have been working on and off on a BSD licensed bignum library. Maybe in a few years....
- StefanKarpinski 15y ago
  If you happened to feel like trying to port it to Julia, it would be fairly doable. All the low-level functionality is there to allow it — bit twiddling operations, growable dense arrays of integers, etc.
  - wbhart 15y ago
    Unfortunately the performance would be poor. This is not a reflection on Julia. Even compiled C is between 4 and 12 times slower than assembly for some bignum operations. Also, LLVM handles carries and certain loop optimisations poorly, so even using LLVM bytecode you can't do much better than compiled C. It would be a massive project to improve this in LLVM (I thought about giving it a go sone time ago but decided it was overwhelming). And that use case is probably too specialised for the improvements to help with much else. Obviously the LLVM backend is fantastic for 99% of use cases and improving all the time. N.B. I am not implying that a good assembly programmer is generically faster than a C compiler. Bignums are a very special case.
    - StefanKarpinski 15y ago
      That makes a whole lot of sense. For myself, I wouldn't even attempt this because it's so much harder and more time-consuming to try to reimplement something like bignums efficiently than it is to just use a stable, mature and fast external library like GMP or CLN — or something like your project if BSD/MIT licensing is a must.