Why is Clojure dynamically typed?

I enjoy reading about different programming languages. I am currently studying Scala, but that does not mean that I am not interested in Groovy, Clojure, Python and many others. All these languages ​​have a unique appearance and some characteristic features. In the case of Clojure, I do not understand one of these design decisions. As far as I know, Clojure pays much attention to its functional paradigm and pretty much forces you to use immutable "variables" where possible. So, if half of your values ​​are immutable, why is the language dynamically typed?

Clojure website reports:

First of all, Clojure is dynamic. This means that Clojure is not just what you compile and run, but something you can interact with.

Well, that sounds totally weird. If the program is compiled, you can no longer change it. Of course, you can "interact" with it, for which user interfaces are used, but a website definitely does not mean a neat "dynamic" graphical interface.

How Clojure Benefits from Dynamic Typing

I mean the special case of Clojure, and not the general advantages of dynamic typing.

How a dynamic type system helps improve functional programming

Again, I know the pleasure of not spilling "int a" all over the source code, but type inference can ease most of the pain. So I just wanted to know how dynamic typing supports the concepts of a functional language.

+50
dynamic language-design functional-programming clojure paradigms
Feb 24 2018-11-21T00:
source share
6 answers

I agree that a purely functional language can still have an interactive read-eval-print-loop and will have an easier time with the output type. I guess Clojure wanted to attract lisp programmers by being "lisp for jvm" and decided to be dynamic like other lisps. Another factor is that type systems should be designed as the very first step of the language, and faster for language developers to simply skip this step.

+11
Feb 24 2018-11-21T00:
source share

If the program is compiled, you can no longer modify it.

It is not right. On image-based systems such as Lisp (Clojure, can be thought of as a dialect of Lisp) and Smalltalk, you can change the compiled environment. Development in such a language usually means working with a working system, adding and changing function definitions, defining macros, parameters, etc. (Adding compilation and loading tools to the image).

This has many advantages. Firstly, all tools can directly interact with the program and there is no need to guess the behavior of the system. You also do not have long pauses for compilation, because each compiled block is very small (it is very rare to recompile everything). NASA JPL once fixed a running Lisp system on a probe hundreds of thousands of kilometers in space.

For such a system, it is very natural to have type information available at runtime (this is what dynamic typing means). Of course, nothing prevents you from doing type checks and type checks at compile time. These concepts are orthogonal. Modern Lisp implementations can usually do both.

+21
Feb 24 '11 at 23:26
source share

Well, first of all, Clojure is Lisp, and Lisps have traditionally always been dynamically printed.

Secondly, in the excerpt that you quoted, Clojure is a dynamic language. This means, among other things, that you can define new functions at runtime, evaluate arbitrary code at runtime, etc. All of these things are difficult or impossible to do in statically typed languages ​​(without plastering in place).

Another reason is that macros can greatly complicate debugging type errors. I believe that creating meaningful error messages for type errors generated by macro-generated code would be a rather difficult task for the compiler.

+14
Feb 24 2018-11-21T00:
source share

Clojure is Lisp with its macro system and the philosophy of code as data , and this philosophy is unlikely to get along with a static type system. For example, what will be the type of such a list:

(defn square [x] (* xx)) 

?

However, if you need static typing, Clojure will solve this with type hints .

+7
Feb 24 2018-11-21T00:
source share

Because this is what the world / market needs. It makes no sense to build what has already been built.

I heard that the JVM already has a statically typed language;)

+5
Feb 25 2018-11-11T00:
source share

Some reasons:

Dynamically typed languages ​​are more flexible and faster to work with.

As the name implies, dynamic languages ​​are more dynamic, and this is huge because the language does not interfere with your rhythm while exploring ideas and solving design problems. In many cases, strong types just slow down performance (who cares if a string is a string when I'm at the top of the abstraction?).

The hardest part in a programmer’s life is to manage the complex process of expressing a domain (and its semantics) using software components (simple and easy-to-read components). Strong type languages ​​add liitle value in this process.

I think that more and more programmers find dynamic languages ​​more pleasant to work with, and pleasure is very important in any work.

Strong types of languages ​​are a kind of premature optimization, and this is a serious flaw.

Alternatively, you can add “types” to clojure when the overall structure is completed using the specification. Ideally, the language should allow the gradual insertion of types into code, and you can do this with the specification.

-one
Jun 09 '19 at 19:37
source share



All Articles