4 ms·

This is a good example of why I roll my eyes at most programming language discussions. There is always someone that starts the "language X is SLOW" bandwagon, a

by jwr 5y ago

This is a good example of why I roll my eyes at most programming language discussions. There is always someone that starts the "language X is SLOW" bandwagon, and people hop on. Languages are rarely "slow" or "fast" by themselves. Programs written in those languages can be slow or fast.

simion314 5y ago
>Languages are rarely "slow" or "fast" by themselves. For sure they are, language features will for sure limit the optimizations a compiler/interpreter can do and for sure a language with many levels of abstractions will have to pay the price in performance somewhere. Every-time someone improves the benchmark performance of a slow language that person is not a regular developer, but someone that has a deeper understanding on what happens under the hood, knows how to use profiling tools, maybe knows assembly and most of the time they have to use tricks or advanced patterns. Btw, optimizing some slow language in a hot path with clever tricks or some advanced patterns is fine, it happens all the time, you can;t just switch the project language with 1 click.
- the-alt-one 5y ago
  >language features will for sure limit the optimizations a compiler/interpreter can do For example: Common Lisp has a full numerical tower, meaning it will automatically convert fixed size numbers into bignums (and more cool stuff). This means that an addition has to branch if it can't prove that a result won't overflow from fixnum to bignum. Yes, C also needs to use bignums, but they're on an opt-in basis. In CL they're opt-out. There are more examples of this, often related to the dynamism of your language. The more introspection a language is capable of, the less a compiler designer can do to cheat and optimize your program.
regularfry 5y ago
Yes and no. Some language features can make it incredibly difficult to optimise. I know the JRuby folks had all sorts of fun trying to make method dispatch fast in the face of "well, this method definition can be changed at any time, arbitrarily often, including during execution of the method itself". I know CL must also have solved that problem but I presume the toolkit is sufficiently different that the techniques just don't map.
- pfdietz 5y ago
  A nice mechanism for optimizing such things was given at the last European Lisp Symposium. https://european-lisp-symposium.org/static/proceedings/2021.pdf https://european-lisp-symposium.org/static/proceedings/2021.... (the last paper, by Robert Strandh.)
AllegedAlec 5y ago
I also feel that for 99% of applications, it doesn't matter. Like, yeah, there are a a few areas where hyper-optimized code in some kind of near-bare-metal language is necessary. But most of the time, if you're writing code, the language itself isn't gonna be the deciding factor if something is performant enough for your application. Furthermore, by using a "fast" language, you're then trading your ability to quickly and cleanly implement code that's human readable suffers greatly.
- hajile 5y ago
  There are fast and slow high level languages. JS is at least as high-level as Python, but is WAY faster. Common Lisp is interesting in that it is high-level while lots of implementations (like sbcl) also retaining the ability to drop into lower levels (even assembly) if lots of performance is needed.

by jwr 5y ago

simion314 5y ago

>Languages are rarely "slow" or "fast" by themselves. For sure they are, language features will for sure limit the optimizations a compiler/interpreter can do and for sure a language with many levels of abstractions will have to pay the price in performance somewhere. Every-time someone improves the benchmark performance of a slow language that person is not a regular developer, but someone that has a deeper understanding on what happens under the hood, knows how to use profiling tools, maybe knows assembly and most of the time they have to use tricks or advanced patterns. Btw, optimizing some slow language in a hot path with clever tricks or some advanced patterns is fine, it happens all the time, you can;t just switch the project language with 1 click.

the-alt-one 5y ago
>language features will for sure limit the optimizations a compiler/interpreter can do For example: Common Lisp has a full numerical tower, meaning it will automatically convert fixed size numbers into bignums (and more cool stuff). This means that an addition has to branch if it can't prove that a result won't overflow from fixnum to bignum. Yes, C also needs to use bignums, but they're on an opt-in basis. In CL they're opt-out. There are more examples of this, often related to the dynamism of your language. The more introspection a language is capable of, the less a compiler designer can do to cheat and optimize your program.

regularfry 5y ago

Yes and no. Some language features can make it incredibly difficult to optimise. I know the JRuby folks had all sorts of fun trying to make method dispatch fast in the face of "well, this method definition can be changed at any time, arbitrarily often, including during execution of the method itself". I know CL must also have solved that problem but I presume the toolkit is sufficiently different that the techniques just don't map.

pfdietz 5y ago
A nice mechanism for optimizing such things was given at the last European Lisp Symposium. https://european-lisp-symposium.org/static/proceedings/2021.pdf https://european-lisp-symposium.org/static/proceedings/2021.... (the last paper, by Robert Strandh.)

AllegedAlec 5y ago

I also feel that for 99% of applications, it doesn't matter. Like, yeah, there are a a few areas where hyper-optimized code in some kind of near-bare-metal language is necessary. But most of the time, if you're writing code, the language itself isn't gonna be the deciding factor if something is performant enough for your application. Furthermore, by using a "fast" language, you're then trading your ability to quickly and cleanly implement code that's human readable suffers greatly.

hajile 5y ago
There are fast and slow high level languages. JS is at least as high-level as Python, but is WAY faster. Common Lisp is interesting in that it is high-level while lots of implementations (like sbcl) also retaining the ability to drop into lower levels (even assembly) if lots of performance is needed.