4 ms·

1. The standard doesn’t guarantee double float arrays will be efficient. Most implementations do it (CCL SBCL CMUCL ECL LW ACL SCL ...), except for a few unpop

1. The standard doesn’t guarantee double float arrays will be efficient. Most implementations do it (CCL SBCL CMUCL ECL LW ACL SCL ...), except for a few unpopular implementations. Seven do what you want, but a couple don’t. What gives? Julia has neither a standard nor more than one implementation. 2. No efficient parametric/ad hoc polymorphism. You can get far with inlining. You can also use libraries specifically built with this in mind. But you’re right, it’s not a built-in feature. But scientific codes are generally not super polymorphic anyway. Look at all the FORTRAN. But besides that, Lisp let’s you build the language you want to use, and have it interoperate for the rest of the ecosystem. If you are surprised that building a language is work, then Lisp may not be the choice for you. If you’re willing to design the language you want for numerical computing, Lisp has the essential data types and primitives to allow you to do that, even portably. If you want off-the-shelf features of Julia, then using Julia is more optimal than Lisp. If you want a language that will readily adapt without changing under your feet, without risking your programs not working 2, 10, or 25 years from now, then Lisp might be a good choice.

baldfat 9y ago
For DSL (DOmain Specific Languages) I use R for my data work. For general computing I use to be a Python and Lua person but now I use Racket, because I can create my own DSL for what I am doing. https://beautifulracket.com/ https://beautifulracket.com/ I totally get the reason why he would go to Julia for doing data jobs. Data structures and already done libraries are very valuable.
lucozade 9y ago
Scientific programming is heavily polymorphic. You just need to look at the interface to most well used libraries like BLAS. Fortran and C conventionally deal with this by adding the relevant type signature to the function name. Scientific programming is also, regularly, polymorphic in 2, (often parametric) types. This heavily motivated the design choices in Julia esp the multiple dispatch infrastructure that is descended from Dylan.
- reikonomusha 9y ago
  Most scientific codes are in the end working on large arrays of floats. There are exceptions, but many scientific codes don’t at all resemble, say, general purpose template libraries. You can make them generic, but it’s not often you gain anything at all.
  - lucozade 9y ago
    That's not true. At all. Almost all scientific libraries resemble template libraries but with bespoke, exposed name mangling and significant portions of the internal data structures specified in comments. They do this, not because it's inherently a good thing, but because the advantages of using Fortran or C have outweighed the disadvantages. But where that's not true, for example in end user computing, Fortran has not been popular for decades. What the Julia devs are attempting to do is to design a language that has the ergonomics of a Matlab or R to make scientific programmers productive whilst having the performance of a Fortran or C. They have a sophisticated type and dispatch system to help bring these goals together. Now, their current focus appears to be more on the R/Matlab replacement than on becoming the language of choice for HPC, say. So the steady state performance is unlikely to be competitive at scale as yet. Maybe they won't get there. Maybe the decisions they've made mean that it's effectively impossible to eek out those last few percent so we'll still have a 2 language model. I don't know but I applaud them for trying. More, I applaud the way they have gone about their development: focus on usage, actively learning from other languages, very little linguistic dogma. I hope they succeed.
    - one-more-minute 9y ago
      You should check out the Celeste project [1]. Julia is a more than viable option for HPC. https://juliacomputing.com/case-studies/celeste.html https://juliacomputing.com/case-studies/celeste.html
      - lucozade 9y ago
        I was aware, but thank you for the link. The fact that it can be used in an important use case is a necessary but not sufficient condition that it can replace the incumbents. Same goes for end user computing. Now, it gives me great confidence that, without the apparent short term focus of the core devs in this field, there has been such progress as Celeste. This is a good sign that the fundamentals are right. But I'm probably more encouraged that the community are focused on user experience and delivering an environment that scientists want to use. This is essential, IMO, and appears to be working well.
shiro 9y ago
> Lisp let’s you build the language you want to use, and have it interoperate for the rest of the ecosystem. I suspect this strength of Lisp could have undermined improvement of Lisp compilers in long term. That is, the fact that programmers can customize the language to run efficiently for their applications put less pressure to make the existing compiler better, compared to the languages that don't give programmers such flexibility. I've worked on performance-sensitive commercial Common Lisp applications. We employed heavy macrology so that optimal instructions were generated in the performance critical regions. Effectively, it was reimplementing part of the compiler to deal with out domain-specific meta information such as parameterized types. It worked, but came with the cost of maintenance--as if we were maintaining another layer of the compiler. It was a burden. I'm sure there have been such effort spent in many other places and eventually abandoned. Meanwhile, languages that give less power to the programmers, put lots of efforts to improving the compiler and/or the language that work more effectively with the improved compiler, and over a few decades, they have quite sophisticated compilers. I still mostly use Lisp-family languages at work, but sometimes wonder if the power could have adverse effect in long term.
- flavio81 9y ago
  This is an excellent reply and I think it goes to the crux of the problem you were facing. Perhaps, then, Julia makes sense in those cases. Or, it's time for an enhanced Common Lisp implementation targeted specifically for scientific computing. I agree that one thing is "extending the language" and other is "implementing things that the compiler should have given me. "
  - lispm 9y ago
    'Scientific computing' is a wide area. One recent shot at is CLASP, especially to reuse scientific computing tools from the C++ world: https://github.com/drmeister/clasp https://github.com/drmeister/clasp
  - reikonomusha 9y ago
    SBCL is already suitable for scientific computing. All that's needed are good engineers who can write good libraries.
flavio81 9y ago
After reading shiro's comment below and a the comments made by Tamas (the article author), i think i understand in more depth the essence of the problem, and there's a pointed criticism made by the author: Due to performance considerations, they have a necessity for having the compiler deeply understand parametric types and apply the code optimizations accordingly. Thus in this case Julia is a sane choice, unless some valiant, progressive Lispers want to fork one of the implementations and create a new Common Lisp implementation focused on high performance scientific computing...
flavio81 9y ago
>You can get far with inlining. You can also use libraries specifically built with this in mind. This implementation of parametric types for Common Lisp looks nice: https://github.com/cosmos72/cl-parametric-types https://github.com/cosmos72/cl-parametric-types It allows you to do templating which additionally declares the (parametrized) types, so the compiler can optimize accordingly. Worth a look.

baldfat 9y ago

For DSL (DOmain Specific Languages) I use R for my data work. For general computing I use to be a Python and Lua person but now I use Racket, because I can create my own DSL for what I am doing. https://beautifulracket.com/ https://beautifulracket.com/ I totally get the reason why he would go to Julia for doing data jobs. Data structures and already done libraries are very valuable.

lucozade 9y ago

Scientific programming is heavily polymorphic. You just need to look at the interface to most well used libraries like BLAS. Fortran and C conventionally deal with this by adding the relevant type signature to the function name. Scientific programming is also, regularly, polymorphic in 2, (often parametric) types. This heavily motivated the design choices in Julia esp the multiple dispatch infrastructure that is descended from Dylan.

reikonomusha 9y ago
Most scientific codes are in the end working on large arrays of floats. There are exceptions, but many scientific codes don’t at all resemble, say, general purpose template libraries. You can make them generic, but it’s not often you gain anything at all.
- lucozade 9y ago
  That's not true. At all. Almost all scientific libraries resemble template libraries but with bespoke, exposed name mangling and significant portions of the internal data structures specified in comments. They do this, not because it's inherently a good thing, but because the advantages of using Fortran or C have outweighed the disadvantages. But where that's not true, for example in end user computing, Fortran has not been popular for decades. What the Julia devs are attempting to do is to design a language that has the ergonomics of a Matlab or R to make scientific programmers productive whilst having the performance of a Fortran or C. They have a sophisticated type and dispatch system to help bring these goals together. Now, their current focus appears to be more on the R/Matlab replacement than on becoming the language of choice for HPC, say. So the steady state performance is unlikely to be competitive at scale as yet. Maybe they won't get there. Maybe the decisions they've made mean that it's effectively impossible to eek out those last few percent so we'll still have a 2 language model. I don't know but I applaud them for trying. More, I applaud the way they have gone about their development: focus on usage, actively learning from other languages, very little linguistic dogma. I hope they succeed.
  - one-more-minute 9y ago
    You should check out the Celeste project [1]. Julia is a more than viable option for HPC. https://juliacomputing.com/case-studies/celeste.html https://juliacomputing.com/case-studies/celeste.html
    - lucozade 9y ago
      I was aware, but thank you for the link. The fact that it can be used in an important use case is a necessary but not sufficient condition that it can replace the incumbents. Same goes for end user computing. Now, it gives me great confidence that, without the apparent short term focus of the core devs in this field, there has been such progress as Celeste. This is a good sign that the fundamentals are right. But I'm probably more encouraged that the community are focused on user experience and delivering an environment that scientists want to use. This is essential, IMO, and appears to be working well.

shiro 9y ago

> Lisp let’s you build the language you want to use, and have it interoperate for the rest of the ecosystem. I suspect this strength of Lisp could have undermined improvement of Lisp compilers in long term. That is, the fact that programmers can customize the language to run efficiently for their applications put less pressure to make the existing compiler better, compared to the languages that don't give programmers such flexibility. I've worked on performance-sensitive commercial Common Lisp applications. We employed heavy macrology so that optimal instructions were generated in the performance critical regions. Effectively, it was reimplementing part of the compiler to deal with out domain-specific meta information such as parameterized types. It worked, but came with the cost of maintenance--as if we were maintaining another layer of the compiler. It was a burden. I'm sure there have been such effort spent in many other places and eventually abandoned. Meanwhile, languages that give less power to the programmers, put lots of efforts to improving the compiler and/or the language that work more effectively with the improved compiler, and over a few decades, they have quite sophisticated compilers. I still mostly use Lisp-family languages at work, but sometimes wonder if the power could have adverse effect in long term.

flavio81 9y ago
This is an excellent reply and I think it goes to the crux of the problem you were facing. Perhaps, then, Julia makes sense in those cases. Or, it's time for an enhanced Common Lisp implementation targeted specifically for scientific computing. I agree that one thing is "extending the language" and other is "implementing things that the compiler should have given me. "
- lispm 9y ago
  'Scientific computing' is a wide area. One recent shot at is CLASP, especially to reuse scientific computing tools from the C++ world: https://github.com/drmeister/clasp https://github.com/drmeister/clasp
- reikonomusha 9y ago
  SBCL is already suitable for scientific computing. All that's needed are good engineers who can write good libraries.

flavio81 9y ago

After reading shiro's comment below and a the comments made by Tamas (the article author), i think i understand in more depth the essence of the problem, and there's a pointed criticism made by the author: Due to performance considerations, they have a necessity for having the compiler deeply understand parametric types and apply the code optimizations accordingly. Thus in this case Julia is a sane choice, unless some valiant, progressive Lispers want to fork one of the implementations and create a new Common Lisp implementation focused on high performance scientific computing...

flavio81 9y ago

>You can get far with inlining. You can also use libraries specifically built with this in mind. This implementation of parametric types for Common Lisp looks nice: https://github.com/cosmos72/cl-parametric-types https://github.com/cosmos72/cl-parametric-types It allows you to do templating which additionally declares the (parametrized) types, so the compiler can optimize accordingly. Worth a look.