7 ms·

I liked clojure when I dived into it but lack of static typing is a pain especially once you have got used to the wonderful refactoring and code-intelligence ab

I liked clojure when I dived into it but lack of static typing is a pain especially once you have got used to the wonderful refactoring and code-intelligence abilities you get by adopting the tools of static typed programming languages like Java/Go/C#/F#. Also performance!

xyrouter 9y ago
The lack of static typing does not explain why there are so many companies using Python, Ruby and Perl but very few using Lisp. If the lack of static typing was the real cause of the lack of popularity of Lisp then Python, Ruby and Perl also would have been unpopular.
- lenkite 9y ago
  Because each of these dynamic languages offered one feature which was/is the best in the world at the time. Python today has the best numeric computing libraries (numpy and sisters) which make it the most widely adopted language for scientific computing, ML, etc. Ruby had Rails - the web framework that trail-blazed convention over configuration and rapid productivity and was considered leading just a few years ago. Ruby's popularity has waned since then as performance and scalability has become far more critical than plain productivity alone. Perl had the best regex features and reporting facilities fifteen+ years ago. It has lost its crown and is rapidly declining since Perl 6 took forever and is basically a completely different language.
  - cafard 9y ago
    Perl also has CPAN. It had mind-share, as Python seems to have now.
  - Volt 9y ago
    Python enjoyed a whole lot of popularity before the ML trend took off. If that's the best thing going for it, I don't think it really answers the question.
lispm 9y ago
From the dynamic languages the SBCL compiler is something you might want to try. The compiler tells you the usual (?) stuff like missing args, wrong named arguments, missing functions, undefined variables, syntax errors, etc. But Common Lisp has also a (relatively primitive, compared to something like Haskell) type system and the SBCL compiler can make use of type declarations (for compile time type checking and for runtime type errors) and does also do some form of type inference. With SBCL you get all the interactive dynamic features and a compiler which you can use to check your code and make it faster. The compiler can for example tell you which operations it could not optimize and why. Then you can decide if it is worth to put some effort into improving the code - for example by adding better type declarations. Common Lisp also lets you inline code or have some data be stack allocated... Common Lisp also has a sophisticated error system, which allows you to get lots of excellent error reporting and handling.
- YouAreGreat 9y ago
  Type declarations in Common Lisp are unsafe. Violating a declaration at runtime is UB. What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. Common Lisp has very little UB, so the C strategy is harder to execute. SBCL basically first needs to sucker their users into overusing one corner of the language that does have UB, type declarations. They get their benchmarks, at the cost of saturating the ecosystem with code that overuses UB, basically poisoning the ecosystem.
  - kbp 9y ago
    > What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. I sort of see what you're getting at, but I think what SBCL does isn't really comparable to the C situation. The complaint people have with UB in C is compiler-writers treating it as a licence to do very unintuitive optimisations; it uses it as a justification for being extremely hostile to the programmer and then the defence is "well the standard said the behaviour was undefined, why would you think there's "obvious" code for the compiler to emit here?". In the SBCL situation, the standard doesn't guarantee any behaviour around that feature, and SBCL is using it as a licence to be more helpful to the programmer, so I think most of the issues people might have with the C situation don't really transfer. For the great majority of programs, the difference doesn't matter either: breaking type declarations being an error (as in SBCL) vs being undefined (as in portable CL) aren't incompatible, as long as your program doesn't rely on a condition being signalled when you violate a type declaration. I can see how relying on SBCL's interpretation of the standard would cause problems, but when the difference is that SBCL just changed "the behaviour is undefined" to "it is an error", I don't see that introducing a wave of unportable code. > They get their benchmarks Type declarations that can't be statically verified transparently degrade to runtime assertions; I don't think that choice was made to do better on benchmarks. > at the cost of saturating the ecosystem with code that overuses UB, basically poisoning the ecosystem. I don't think there's that much code out there that relies on errors being signalled when it violates type declarations as a part of normal execution (quick, link a few projects that make use of this), certainly not enough to say that trend poisoned the ecosystem.
geospeck 9y ago
There is TypedClojure[1] for static typing in Clojure, but I am not quite sure how good the tooling is though, e.g. refactoring, code-intelligence abilities, etc... [1]http://typedclojure.org http://typedclojure.org
dragandj 9y ago
Clojure has Java's static typing and you can also typehint things explicitly.
- kickopotomus 9y ago
  Clojure 1.9 also introduced spec which allows for more aggressive type restrictions among other things.

xyrouter 9y ago

The lack of static typing does not explain why there are so many companies using Python, Ruby and Perl but very few using Lisp. If the lack of static typing was the real cause of the lack of popularity of Lisp then Python, Ruby and Perl also would have been unpopular.

lenkite 9y ago
Because each of these dynamic languages offered one feature which was/is the best in the world at the time. Python today has the best numeric computing libraries (numpy and sisters) which make it the most widely adopted language for scientific computing, ML, etc. Ruby had Rails - the web framework that trail-blazed convention over configuration and rapid productivity and was considered leading just a few years ago. Ruby's popularity has waned since then as performance and scalability has become far more critical than plain productivity alone. Perl had the best regex features and reporting facilities fifteen+ years ago. It has lost its crown and is rapidly declining since Perl 6 took forever and is basically a completely different language.
- cafard 9y ago
  Perl also has CPAN. It had mind-share, as Python seems to have now.
- Volt 9y ago
  Python enjoyed a whole lot of popularity before the ML trend took off. If that's the best thing going for it, I don't think it really answers the question.

lispm 9y ago

From the dynamic languages the SBCL compiler is something you might want to try. The compiler tells you the usual (?) stuff like missing args, wrong named arguments, missing functions, undefined variables, syntax errors, etc. But Common Lisp has also a (relatively primitive, compared to something like Haskell) type system and the SBCL compiler can make use of type declarations (for compile time type checking and for runtime type errors) and does also do some form of type inference. With SBCL you get all the interactive dynamic features and a compiler which you can use to check your code and make it faster. The compiler can for example tell you which operations it could not optimize and why. Then you can decide if it is worth to put some effort into improving the code - for example by adding better type declarations. Common Lisp also lets you inline code or have some data be stack allocated... Common Lisp also has a sophisticated error system, which allows you to get lots of excellent error reporting and handling.

YouAreGreat 9y ago
Type declarations in Common Lisp are unsafe. Violating a declaration at runtime is UB. What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. Common Lisp has very little UB, so the C strategy is harder to execute. SBCL basically first needs to sucker their users into overusing one corner of the language that does have UB, type declarations. They get their benchmarks, at the cost of saturating the ecosystem with code that overuses UB, basically poisoning the ecosystem.
- kbp 9y ago
  > What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. I sort of see what you're getting at, but I think what SBCL does isn't really comparable to the C situation. The complaint people have with UB in C is compiler-writers treating it as a licence to do very unintuitive optimisations; it uses it as a justification for being extremely hostile to the programmer and then the defence is "well the standard said the behaviour was undefined, why would you think there's "obvious" code for the compiler to emit here?". In the SBCL situation, the standard doesn't guarantee any behaviour around that feature, and SBCL is using it as a licence to be more helpful to the programmer, so I think most of the issues people might have with the C situation don't really transfer. For the great majority of programs, the difference doesn't matter either: breaking type declarations being an error (as in SBCL) vs being undefined (as in portable CL) aren't incompatible, as long as your program doesn't rely on a condition being signalled when you violate a type declaration. I can see how relying on SBCL's interpretation of the standard would cause problems, but when the difference is that SBCL just changed "the behaviour is undefined" to "it is an error", I don't see that introducing a wave of unportable code. > They get their benchmarks Type declarations that can't be statically verified transparently degrade to runtime assertions; I don't think that choice was made to do better on benchmarks. > at the cost of saturating the ecosystem with code that overuses UB, basically poisoning the ecosystem. I don't think there's that much code out there that relies on errors being signalled when it violates type declarations as a part of normal execution (quick, link a few projects that make use of this), certainly not enough to say that trend poisoned the ecosystem.

geospeck 9y ago

There is TypedClojure[1] for static typing in Clojure, but I am not quite sure how good the tooling is though, e.g. refactoring, code-intelligence abilities, etc... [1]http://typedclojure.org http://typedclojure.org

dragandj 9y ago

Clojure has Java's static typing and you can also typehint things explicitly.

kickopotomus 9y ago
Clojure 1.9 also introduced spec which allows for more aggressive type restrictions among other things.