4 ms·

> ... it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conv

by brabel 5y ago

> ... it goes well beyond any Lisp/Scheme (and many modern languages) in terms of having a practical but expansive ecosystem with a strong set of idiomatic conventions. Does it, really?? Common Lisp is an ANSI Standard, I don't know how you get a more "strong set of idiomatic conventions" than that. And it's been "done" for 20 years now! People continue to use it just as it is, and there's very little pressure to change it because it simply works! You're trying to justify a new wave of "modern" languages with a very weak argument... just call it for what it is: you want "cool", hyped languages to succeed despite the fact they offer nothing that the CL standard did not 20 years ago.

tho23u4i23o4 5y ago
In fairness, the CL spec being quite old, has a fairly dated type system. Obviously, CL is still blazing fast compared to Python, but it can't easily do the kind of things that Julia or even C++ can when it comes to numerical programming. You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this.
- medo-bear 5y ago
  > You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. also here is the similar library in common lisp [1] [0] https://github.com/JuliaGPU/CUDA.jl https://github.com/JuliaGPU/CUDA.jl [1] https://github.com/takagi/cl-cuda https://github.com/takagi/cl-cuda
  - eigenspace 5y ago
    > this is not the job of compiler writers Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development team can produce while working together. > in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. This is mostly false. First of all, there's a huge amount of numerical programming infrastructure in Base julia and it's standard library. There is even more outside of the base/stdlib, but the stuff inside is quite diverse and robust. Second of all, CUDA.jl is a very weird thing to point to for your example. CUDA.jl is essentially a compiler plugin for julia that hijacks it's normal compilation pipeline for specified code and then causes it to emit GPU specialized instructions to LLVM which then compiles a binary. If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that (but note, this is a rather dumb definition of 'wrapping').
    - medo-bear 5y ago
      why do you presume that's what the GP meant? your post is much more detailed than his anyway, i know very well that julia has a great standard numerical library. it is a language catered to that community so it better have a rich standard library. my point is that functionality does not need to in the standard library in order to be useful or impactful. i don't think i need to prove my point but take numpy (or any other famous numerical package from the python ecosystem) as an example >Second of all, CUDA.jl is a very weird thing to point to for your example i work in machine learning so it is a very important package for me > If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that and CL is not. point is that you need to learn LLVM in order to dig deeper, if you so wish
bmitc 5y ago
This type of response is also why Common Lisp isn’t more popular. :) Having a standard has little to do with how people write code, which is what I meant by idiomatic conventions. Elixir is not a “cool, hyped” language in the sense that you mean. Elixir is basically a wrapper around Erlang and OTP, which is an old technology (much older than ANSI Common Lisp), that provides several improvements in terms of developer tools and frameworks. It’s not just the next “cool” thing. It’s an incremental improvement on an old and tested technology to bring that technology to more developers. It has also been embraced by the Erlang community.
- brabel 5y ago
  > This type of response is also why Common Lisp isn’t more popular. :) What does a response from a blunt commenter like me has to do with the success of CL? Do you mean CL users are prone to responding like me? I would say users of any language that's being dismissed as being old would react similarly. > Elixir is basically a wrapper around Erlang and OTP Yes, I know, I was going to say that Elixir itself is nothing new as it's just Erlang with a more palatable syntax on top... nothing really new, Erlang is about as old as Common Lisp.
  - bmitc 5y ago
    I'm not dismissing Common Lisp. I've actively searched for and applied to jobs that advertised using Common Lisp. I just don't see the Common Lisp community rallying to make it more cohesive (and thus more popular and attractive), which is fine, but it means it won't get used outside of enthusiasts bringing it into niche pockets of companies. I have the same complaints with F#, which is one of my favorite languages, because there are just too many libraries/frameworks that are just one-off side projects of a single developer. (There are of course separate reasons for F#'s lack of uptake.) If the entire Common Lisp ecosystem is as good as people say it is, then I don't see why it couldn't go through a path like Erlang did with Elixir and even so without a syntax change (just a nice bundling of the ecosystem and tooling) instead of just relying on war stories of its use and telling people they just don't get it.
    - 5y ago

by brabel 5y ago

tho23u4i23o4 5y ago

In fairness, the CL spec being quite old, has a fairly dated type system. Obviously, CL is still blazing fast compared to Python, but it can't easily do the kind of things that Julia or even C++ can when it comes to numerical programming. You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this.

medo-bear 5y ago
> You can write a lot of macrology to get around it, but there's a point where you want actual compiler writers to be doing this this is not the job of compiler writers (although writing macros is akin to writing a compiler but i do not think that this is what you mean). in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. also here is the similar library in common lisp [1] [0] https://github.com/JuliaGPU/CUDA.jl https://github.com/JuliaGPU/CUDA.jl [1] https://github.com/takagi/cl-cuda https://github.com/takagi/cl-cuda
- eigenspace 5y ago
  > this is not the job of compiler writers Presumably what the GP means is that you can use macros to hack around limitations of CL's type system, such as lack of parametric types, or whatever (very important for good multidimensional generic array code), but they'd rather that the CLOS was just built to be more expressive in the first place, because their local hacks will not be as good as what a language development team can produce while working together. > in julia the numerical programming packages are not part of the standard library and a lot of it is wrappers around C++ code especially when the drivers to the underlining hardware are closed-source [0]. This is mostly false. First of all, there's a huge amount of numerical programming infrastructure in Base julia and it's standard library. There is even more outside of the base/stdlib, but the stuff inside is quite diverse and robust. Second of all, CUDA.jl is a very weird thing to point to for your example. CUDA.jl is essentially a compiler plugin for julia that hijacks it's normal compilation pipeline for specified code and then causes it to emit GPU specialized instructions to LLVM which then compiles a binary. If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that (but note, this is a rather dumb definition of 'wrapping').
  - medo-bear 5y ago
    why do you presume that's what the GP meant? your post is much more detailed than his anyway, i know very well that julia has a great standard numerical library. it is a language catered to that community so it better have a rich standard library. my point is that functionality does not need to in the standard library in order to be useful or impactful. i don't think i need to prove my point but take numpy (or any other famous numerical package from the python ecosystem) as an example >Second of all, CUDA.jl is a very weird thing to point to for your example i work in machine learning so it is a very important package for me > If compiling to LLVM is a 'wrapper around C++ code' then all julia code is that and CL is not. point is that you need to learn LLVM in order to dig deeper, if you so wish

bmitc 5y ago

This type of response is also why Common Lisp isn’t more popular. :) Having a standard has little to do with how people write code, which is what I meant by idiomatic conventions. Elixir is not a “cool, hyped” language in the sense that you mean. Elixir is basically a wrapper around Erlang and OTP, which is an old technology (much older than ANSI Common Lisp), that provides several improvements in terms of developer tools and frameworks. It’s not just the next “cool” thing. It’s an incremental improvement on an old and tested technology to bring that technology to more developers. It has also been embraced by the Erlang community.

brabel 5y ago
> This type of response is also why Common Lisp isn’t more popular. :) What does a response from a blunt commenter like me has to do with the success of CL? Do you mean CL users are prone to responding like me? I would say users of any language that's being dismissed as being old would react similarly. > Elixir is basically a wrapper around Erlang and OTP Yes, I know, I was going to say that Elixir itself is nothing new as it's just Erlang with a more palatable syntax on top... nothing really new, Erlang is about as old as Common Lisp.
- bmitc 5y ago
  I'm not dismissing Common Lisp. I've actively searched for and applied to jobs that advertised using Common Lisp. I just don't see the Common Lisp community rallying to make it more cohesive (and thus more popular and attractive), which is fine, but it means it won't get used outside of enthusiasts bringing it into niche pockets of companies. I have the same complaints with F#, which is one of my favorite languages, because there are just too many libraries/frameworks that are just one-off side projects of a single developer. (There are of course separate reasons for F#'s lack of uptake.) If the entire Common Lisp ecosystem is as good as people say it is, then I don't see why it couldn't go through a path like Erlang did with Elixir and even so without a syntax change (just a nice bundling of the ecosystem and tooling) instead of just relying on war stories of its use and telling people they just don't get it.
  - 5y ago