5 ms·

Someone explain to me why we need a new language here? If they are trying to express ideas - wouldn't any language do just fine? They can 'compile' in an 'opt

Someone explain to me why we need a new language here? If they are trying to express ideas - wouldn't any language do just fine? They can 'compile' in an 'optimized manner' using something else ... But in terms of algorithmic expression? Unless they are writing true 'real time' stuff right for the chip ... why a new syntax?

awm 10y ago
> They can 'compile' in an 'optimized manner' using something else ... Thats actually the issue Julia attempts to solve as highlighted in the article. There are many languages that you can use to express ideas, but when you need the idea to run as fast as possible, you have to rewrite in C/Fortran/etc and then add bindings to to the language. Julia lets you write inline C, which I believe means that you can still express algorithms simply, but with some parts (trivially) optimized. (Not a huge julia user, but thats my take on it)
- edblarney 10y ago
  I understand that - but wouldn't a really smart compiler be able to do the same thing? And if you have to be able to write 'some parts' in C for speed ... then why not just use C? And have nice libs for whatever you are doing? Or intelligently distribute it across processes? I find it hard to believe that the 'financial industry' has performance requirements that have never been encountered in the entire rest of high tech before ...
  - awm 10y ago
    Ah, I see. I'm no expert, but I'd argue the response is "Maybe". I think this is what blaze and pypy try to do with python: they compile it so that certain things are optimized. The harder part is that you have to generally hint for the compiler to truly be the best... WRT to just why not use C, python/R/Julia are MUCH easier to prototype in than C (in my opinion, having used those languages). The "grail" is to be able to prototype quickly, and then identify the hotspots to speed up (which, in Julia's case, would be just inlining with C code).
  - rifung 10y ago
    > wouldn't a really smart compiler be able to do the same thing? Well compilers are tied to the language they need to compile so language choice does still matters. As an extreme example, GHC can be much more aggressive with inlining because it's pure, whereas most other languages don't provide the same guarantees. > And if you have to be able to write 'some parts' in C for speed ... then why not just use C? And have nice libs for whatever you are doing? Yes I think they could do that, but then they'd need people to write and maintain those libraries. My understanding is they want to find something which strikes a better balance between productivity and speed. Having to write your own libraries to do everything is likely considered a productivity loss.
- mauro3 10y ago
  Whilst Julia's foreign function interface is indeed good and it is really easy to call into C, the point is that Julia itself is as fast as C. So you don't need to write any C code to get performance, instead just tune the bottlenecks in Julia itself. For instance, the standard library of Julia [1] is written in Julia itself (and is very performant) and only calls into external C or Fortran libraries where there are well established code-bases (e.g. BLAS, FFTW). Compare this to, e.g., Python or R where much of the standard library is written in C. [1] https://github.com/JuliaLang/julia/tree/master/base https://github.com/JuliaLang/julia/tree/master/base
bwanab 10y ago
One of the ideas behind julia is to get a language that is as expressive as python, with better functional programming capability, that runs at the same order of speed as C. You can't get something for nothing, but it's a really good start.
jernfrost 10y ago
(1) if every programming language was equally good at everything we would not have a multitude of programming languages. And there are always advances in programming language theory and concepts which have not been captured in earlier languages. (2) The semantics of the language put restrictions on what sort of optimizations you can do or how easy they are to perform. Julia has been designed to make it very easy to optimize. E.g. something like JavaScript runs quite fast, but only through a herculean effort by the JIT makers. It's design is terrible with respect to making it easy to create high performance compilers/JIT. (3) What is "new" syntax. All languages have variations in syntax. Wherever Julia differs in syntax from whatever you know it isn't just for the hell of it. There are usually good reasons. Mostly Julia tries to look similar to programming languages familiar to its target group. Where it differs I'd say it is usually to improve on deficiencies in said languages. I am an iOS developer but I write smaller scripts to do custom processing of source code, assets etc. I wrote my scripts in Julia first, but decided to convert to Python afterwards to make it easier to distribute to other people, given that Julia does not come pre-installed. I got to say Julia is WAY WAY nicer to program than python for shell script like stuff. I kept hitting on so many issues when converting to Python that I kept a long list of issues with Python. My takeaway from this experience is that a LOT has happened since Python, Ruby etc was conceived. Julia has been able to tap into all the advances that has happened since then. It has a much smoother REPL environment, much more sensible set of built in functions. More sane naming conventions. And the libraries are built to combine effectively in much better way. You simply need to write much less code when writing Julia because stuff combine so well. While in Python I find myself having to write a lot of glue code to make pieces fit together. So the question is, why stick to a language just because it is well established. I had many more years of experience with Python. But I get the job done much faster with Julia. So why waste extra time on Python just because it is established? That has no inherent value.
- edblarney 10y ago
  "So the question is, why stick to a language just because it is well established." You answered the question yourself: "but decided to convert to Python afterwards to make it easier to distribute to other people" Languages are platforms. They have vast distribution, incumbency, developers, apis etc. - and that has a lot of value. Imagine if you did dev on Julia - how do you hire devs? Julia has a very, very small mind-share - in order for it to reach 'platform status' it really has to cross a threshold, and for that - it has to provide significantly more value. I'm also curious to know 'how much faster' it is - couldn't those performance problems be solved with more horsepower? Developers have a terrible habit of over-optimizing for performance, which usually comes at the cost of complexity. Anyhow - I know little about Julia so I'll hold my tongue, maybe it's the bees-knees ... It'd be great to see some data points.

awm 10y ago

> They can 'compile' in an 'optimized manner' using something else ... Thats actually the issue Julia attempts to solve as highlighted in the article. There are many languages that you can use to express ideas, but when you need the idea to run as fast as possible, you have to rewrite in C/Fortran/etc and then add bindings to to the language. Julia lets you write inline C, which I believe means that you can still express algorithms simply, but with some parts (trivially) optimized. (Not a huge julia user, but thats my take on it)

edblarney 10y ago
I understand that - but wouldn't a really smart compiler be able to do the same thing? And if you have to be able to write 'some parts' in C for speed ... then why not just use C? And have nice libs for whatever you are doing? Or intelligently distribute it across processes? I find it hard to believe that the 'financial industry' has performance requirements that have never been encountered in the entire rest of high tech before ...
- awm 10y ago
  Ah, I see. I'm no expert, but I'd argue the response is "Maybe". I think this is what blaze and pypy try to do with python: they compile it so that certain things are optimized. The harder part is that you have to generally hint for the compiler to truly be the best... WRT to just why not use C, python/R/Julia are MUCH easier to prototype in than C (in my opinion, having used those languages). The "grail" is to be able to prototype quickly, and then identify the hotspots to speed up (which, in Julia's case, would be just inlining with C code).
- rifung 10y ago
  > wouldn't a really smart compiler be able to do the same thing? Well compilers are tied to the language they need to compile so language choice does still matters. As an extreme example, GHC can be much more aggressive with inlining because it's pure, whereas most other languages don't provide the same guarantees. > And if you have to be able to write 'some parts' in C for speed ... then why not just use C? And have nice libs for whatever you are doing? Yes I think they could do that, but then they'd need people to write and maintain those libraries. My understanding is they want to find something which strikes a better balance between productivity and speed. Having to write your own libraries to do everything is likely considered a productivity loss.
mauro3 10y ago
Whilst Julia's foreign function interface is indeed good and it is really easy to call into C, the point is that Julia itself is as fast as C. So you don't need to write any C code to get performance, instead just tune the bottlenecks in Julia itself. For instance, the standard library of Julia [1] is written in Julia itself (and is very performant) and only calls into external C or Fortran libraries where there are well established code-bases (e.g. BLAS, FFTW). Compare this to, e.g., Python or R where much of the standard library is written in C. [1] https://github.com/JuliaLang/julia/tree/master/base https://github.com/JuliaLang/julia/tree/master/base

bwanab 10y ago

One of the ideas behind julia is to get a language that is as expressive as python, with better functional programming capability, that runs at the same order of speed as C. You can't get something for nothing, but it's a really good start.

jernfrost 10y ago

(1) if every programming language was equally good at everything we would not have a multitude of programming languages. And there are always advances in programming language theory and concepts which have not been captured in earlier languages. (2) The semantics of the language put restrictions on what sort of optimizations you can do or how easy they are to perform. Julia has been designed to make it very easy to optimize. E.g. something like JavaScript runs quite fast, but only through a herculean effort by the JIT makers. It's design is terrible with respect to making it easy to create high performance compilers/JIT. (3) What is "new" syntax. All languages have variations in syntax. Wherever Julia differs in syntax from whatever you know it isn't just for the hell of it. There are usually good reasons. Mostly Julia tries to look similar to programming languages familiar to its target group. Where it differs I'd say it is usually to improve on deficiencies in said languages. I am an iOS developer but I write smaller scripts to do custom processing of source code, assets etc. I wrote my scripts in Julia first, but decided to convert to Python afterwards to make it easier to distribute to other people, given that Julia does not come pre-installed. I got to say Julia is WAY WAY nicer to program than python for shell script like stuff. I kept hitting on so many issues when converting to Python that I kept a long list of issues with Python. My takeaway from this experience is that a LOT has happened since Python, Ruby etc was conceived. Julia has been able to tap into all the advances that has happened since then. It has a much smoother REPL environment, much more sensible set of built in functions. More sane naming conventions. And the libraries are built to combine effectively in much better way. You simply need to write much less code when writing Julia because stuff combine so well. While in Python I find myself having to write a lot of glue code to make pieces fit together. So the question is, why stick to a language just because it is well established. I had many more years of experience with Python. But I get the job done much faster with Julia. So why waste extra time on Python just because it is established? That has no inherent value.

edblarney 10y ago
"So the question is, why stick to a language just because it is well established." You answered the question yourself: "but decided to convert to Python afterwards to make it easier to distribute to other people" Languages are platforms. They have vast distribution, incumbency, developers, apis etc. - and that has a lot of value. Imagine if you did dev on Julia - how do you hire devs? Julia has a very, very small mind-share - in order for it to reach 'platform status' it really has to cross a threshold, and for that - it has to provide significantly more value. I'm also curious to know 'how much faster' it is - couldn't those performance problems be solved with more horsepower? Developers have a terrible habit of over-optimizing for performance, which usually comes at the cost of complexity. Anyhow - I know little about Julia so I'll hold my tongue, maybe it's the bees-knees ... It'd be great to see some data points.