5 ms·

Javascript and Python are very popular dynamic languages, this doesn't make them good dynamic languages. In particular OOP is very much helped by static types.

Javascript and Python are very popular dynamic languages, this doesn't make them good dynamic languages. In particular OOP is very much helped by static types. Clojure would a better example of a dynamic language that would not be improved by adding static typing. Namespaces, functions and immutable data (as well as pervasive use of data instead of wrapping it in classes) lessens the downsides I bump into continuously when doing javascript development.

rbjorklin 9y ago
I’ve tried Clojure a little bit and it seems like a nice language but I’m not convinced by the lack of types. Why wouldn’t you want types? How often can you reuse a function intended for ‘ints’ with some other type? The way I see it types provide important information to anyone reading the code after it was written as well as to the compiler making it possible to catch bugs early and generate more efficient machine code.
- joncampbelldev 9y ago
  One of the big benefits of clojure being dynamic is that everything is data (e.g. a map, set, vector or list). This is what allows reuse. - The vast core library of functions that manipulate those data structures can be used for everything in your program, cos it's all data. - Most clojure libraries take and/or return data, reducing the need for clumsy adaptors, or even worse not being able to get at the data you need cos the library writer was really enthusiastic about encapsulation of everything they thought was of no use to consumers. - You don't have a person class, you have a map with a first name and last name. Now the function that turns first + last name into full name can be reused for any other map with the same keys. (A rather spurious example, but a real one would take a large codebase and an essay to describe) I can only recommend watching some of Rich Hickey's talks, particularly these ones, they're not entirely about types, but they express the above ideas much better than I can: - Simple made easy https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy - Effective programs https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU - Are we there yet? (this one is more about OOP, but unless you're using something like haskell, idris etc its relevant for your type system of choice) https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...
  - wtetzner 9y ago
    > One of the big benefits of clojure being dynamic is that everything is data (e.g. a map, set, vector or list). What about this can't be done with types? Simple parametric-polymorphism gets you pretty far. Row types allow you to handle "maps as records" in a type-safe way. The rest is just having support for some kind of ad-hoc polymorphism so that you can re-use your functions on that small set of types (type classes, ML-style functors, interfaces, protocols, etc.).
    - joncampbelldev 9y ago
      Again, I would refer you to the Rich Hickey talks, I'm not very eloquent on this. I think its about the manual overhead that constructing your hierarchy of types, plus the cognitive overhead of doing all the fancy things in your brackets. I'm familiar with the advantages of type systems (my progression was Java -> Haskell -> Idris) but I found my personal productivity (even in larger systems built in a team) was best in clojure. I didn't feel that the guarantees given to me by the type system were worth the mental overhead, a lot of people feel differently (you amongst them I'm guessing :p) As a closing point, if I were to ever build something that truly had to be Robust in a "someone will die if this goes even slightly wrong" way, I would reach straight for Idris and probably something like TLA+. However most of my development revolves around larger distributed systems communicating over wires, still resilient but in a different way. Mainly I use clojure.spec in core business logic and at the edges of my programs, for generative testing and ensuring that the data flowing through the system is sensible.
  - mbrodersen 9y ago
    The data types in Clojure can be very easily (and better) expressed in (say) Haskell. For example: http://tech.frontrowed.com/2017/11/01/rhetoric-of-clojure-and-haskell/ http://tech.frontrowed.com/2017/11/01/rhetoric-of-clojure-an...
    - joncampbelldev 9y ago
      The main issue is that Haskell is not a data-oriented language by default, this means its no fun to push it to be that. For example, I also have to use java in my job, I use persistent (functional) data structures all the time, but Java is not built for it, its not fun. (Although definitely more fun that using Java's mutable structures, ewww) Also I personally find that to be too much overhead and ceremony in return for some type checking at compile type, as opposed to spec checking at runtime.
- nogridbag 9y ago
  See my comments about Clojure.spec here: https://news.ycombinator.com/item?id=16414942 https://news.ycombinator.com/item?id=16414942 This is all application specific, but for the types of apps I've worked on (large enterprisey OO apps) you often need various bits and pieces of domain data across different methods. So given some function, you either pass in DomainClass1, DomainClass2, DomainClass 3 (using a couple of properties of each) or you define a new class SomeSubsetOfPropertiesClass solely to call that single method. In the former case, the types do not serve as documentation for the reader as it's not clear what shape of the data is required for the function. In the latter case you're duplicating code (the properties and their types) and the class really has no meaning except as a struct to call that method. Now that I've been working with Clojure for a little bit I find I'm able to write much more concise, testable functions and calling them is dead simple since I can work with the raw data, transforming it into the shape I need.
  - skohan 9y ago
    To be fair, the OO example you give just sounds like bad design. It should be entirely possible to avoid having to pass giant bundles of state between different layers of your application, and even if you can't you should be able to define interface conformances on your DomainClass objects to make it clear which of their members are actually relevant in a given case.
    - nogridbag 9y ago
      Absolutely it's bad OO design. Because it's very difficult to do OO right at scale. For a larger application like many I've worked on (thousands of domain classes), it's much less risky to have an anemic domain model than attempt to model a very complex domain properly. I would imagine in the Java world most applications that use ORMs tend to lean towards anemic domain models that simply mirror DB tables.
  - frankpf 9y ago
    What you want to do is possible with a structural type system. In structural type systems, type compatibility is based on the structure of the type instead of the name (as opposed to nominal type systems). An example in TypeScript: interface Named { name: string } class Person { name: string age: number // constructor here } function f(obj: Named) { // do something with obj.name } const joe = new Person('Joe', 25) // Compiles, even though Person has an extra `age` field // Person is structurally compatible with Named f(joe) If you pass f() a class/object that doesn't have a `name` property of type string, the compiler would catch your error.
- flavio81 9y ago
  >I’ve tried Clojure a little bit and it seems like a nice language but I’m not convinced by the lack of types. Why wouldn’t you want types? Clojure has classes and types. How can it be untyped? Machine language is untyped.
hellofunk 9y ago
>> would not be improved by adding static typing Well, that's a matter of opinion, even by long-term Clojure veterans. There is a reason Core.Typed was developed, though it hasn't been maintained recently. The fact that Rich felt the need to give the keynote at the last Clojure conference about the dynamic vs static issue shows that it is still a highly debated topic within the Clojure world.
- joncampbelldev 9y ago
  I think the debate may be leaning towards dynamic. - The aforementioned keynote highlighting the various reasons Rich chose to make it dynamic. - CircleCI (one of the major users and propronents of core.typed) dropping it. - The introduction of spec as an alternative for some of the reasons people use type systems (its certainly not a drop in replacement and doesn't intend to be). - Spec allowing different kinds of verification not possible with a type system on its own.
- mbrodersen 9y ago
  I find it interesting that Rich (and other Clojure people) feel they need to continue defending themselves again and again. While strongly typed language communities usually don't feel the need. There must be some deep doubt in the Clojure community that triggers this.
  - jhhh 9y ago
    I think it's more a acknowledgement of the current state of popularity of languages and an attempt to win people over rather than a manifestation of latent doubt.
  - joncampbelldev 9y ago
    Forgive me, but your comment seems a little disingenuous with the way it generalises the static community (every static language??) vs the clojure community. Many of the comments on this page show why Rich gave the keynote. Because the same advantages of type checking are put forward as a reason to not use clojure over and over. They're not wrong, static typing has advantages, but I see little acceptance of any tradeoffs (or even acceptance that such tradeoffs exist: concretion of information, coupling of distant components by shared types etc etc etc I'm just paraphrasing the keynote). He was highlighting the value proposition and tradeoffs of: being data-oriented, being dynamic and clojure.spec niceness. He felt the need to do this because he clearly felt that some people who were wavering about clojure were unsure why it was dynamic: "can't we have all this great stuff AND static types". He wanted to say "yes quite possibly you could, BUT here's the reasons why I didn't add types".
seanmcdirmid 9y ago
> Namespaces, functions and immutable data (as well as pervasive use of data instead of wrapping it in classes) There are plenty of functional programming languages that believe static typing is a significant added value even under these conditions.
- joncampbelldev 9y ago
  And some believe that the added value is not worth the trade off in mental overhead and ceremony. We are surely both aware of the various, numerous and flame-war arguments for static vs dynamic typing. (For my side I can only recommend Rich Hickey's talk "Effective Programs", he says it better than me) My main point was that dynamic typing should be judged by it's best implementations, not by JavaScript. For example, I would not judge static typing by Java or C++.
flavio81 9y ago
>Javascript and Python are very popular dynamic languages, this doesn't make them good dynamic languages. JS in particular is a very bad example of a dynamic language, the other "very bad" example being classic PHP. This, mostly, because of weak typing. Many of the problems attributed to C, a statically-typed language, are also due to weak typing.

rbjorklin 9y ago

I’ve tried Clojure a little bit and it seems like a nice language but I’m not convinced by the lack of types. Why wouldn’t you want types? How often can you reuse a function intended for ‘ints’ with some other type? The way I see it types provide important information to anyone reading the code after it was written as well as to the compiler making it possible to catch bugs early and generate more efficient machine code.

joncampbelldev 9y ago
One of the big benefits of clojure being dynamic is that everything is data (e.g. a map, set, vector or list). This is what allows reuse. - The vast core library of functions that manipulate those data structures can be used for everything in your program, cos it's all data. - Most clojure libraries take and/or return data, reducing the need for clumsy adaptors, or even worse not being able to get at the data you need cos the library writer was really enthusiastic about encapsulation of everything they thought was of no use to consumers. - You don't have a person class, you have a map with a first name and last name. Now the function that turns first + last name into full name can be reused for any other map with the same keys. (A rather spurious example, but a real one would take a large codebase and an essay to describe) I can only recommend watching some of Rich Hickey's talks, particularly these ones, they're not entirely about types, but they express the above ideas much better than I can: - Simple made easy https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy - Effective programs https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU - Are we there yet? (this one is more about OOP, but unless you're using something like haskell, idris etc its relevant for your type system of choice) https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...
- wtetzner 9y ago
  > One of the big benefits of clojure being dynamic is that everything is data (e.g. a map, set, vector or list). What about this can't be done with types? Simple parametric-polymorphism gets you pretty far. Row types allow you to handle "maps as records" in a type-safe way. The rest is just having support for some kind of ad-hoc polymorphism so that you can re-use your functions on that small set of types (type classes, ML-style functors, interfaces, protocols, etc.).
  - joncampbelldev 9y ago
    Again, I would refer you to the Rich Hickey talks, I'm not very eloquent on this. I think its about the manual overhead that constructing your hierarchy of types, plus the cognitive overhead of doing all the fancy things in your brackets. I'm familiar with the advantages of type systems (my progression was Java -> Haskell -> Idris) but I found my personal productivity (even in larger systems built in a team) was best in clojure. I didn't feel that the guarantees given to me by the type system were worth the mental overhead, a lot of people feel differently (you amongst them I'm guessing :p) As a closing point, if I were to ever build something that truly had to be Robust in a "someone will die if this goes even slightly wrong" way, I would reach straight for Idris and probably something like TLA+. However most of my development revolves around larger distributed systems communicating over wires, still resilient but in a different way. Mainly I use clojure.spec in core business logic and at the edges of my programs, for generative testing and ensuring that the data flowing through the system is sensible.
- mbrodersen 9y ago
  The data types in Clojure can be very easily (and better) expressed in (say) Haskell. For example: http://tech.frontrowed.com/2017/11/01/rhetoric-of-clojure-and-haskell/ http://tech.frontrowed.com/2017/11/01/rhetoric-of-clojure-an...
  - joncampbelldev 9y ago
    The main issue is that Haskell is not a data-oriented language by default, this means its no fun to push it to be that. For example, I also have to use java in my job, I use persistent (functional) data structures all the time, but Java is not built for it, its not fun. (Although definitely more fun that using Java's mutable structures, ewww) Also I personally find that to be too much overhead and ceremony in return for some type checking at compile type, as opposed to spec checking at runtime.
nogridbag 9y ago
See my comments about Clojure.spec here: https://news.ycombinator.com/item?id=16414942 https://news.ycombinator.com/item?id=16414942 This is all application specific, but for the types of apps I've worked on (large enterprisey OO apps) you often need various bits and pieces of domain data across different methods. So given some function, you either pass in DomainClass1, DomainClass2, DomainClass 3 (using a couple of properties of each) or you define a new class SomeSubsetOfPropertiesClass solely to call that single method. In the former case, the types do not serve as documentation for the reader as it's not clear what shape of the data is required for the function. In the latter case you're duplicating code (the properties and their types) and the class really has no meaning except as a struct to call that method. Now that I've been working with Clojure for a little bit I find I'm able to write much more concise, testable functions and calling them is dead simple since I can work with the raw data, transforming it into the shape I need.
- skohan 9y ago
  To be fair, the OO example you give just sounds like bad design. It should be entirely possible to avoid having to pass giant bundles of state between different layers of your application, and even if you can't you should be able to define interface conformances on your DomainClass objects to make it clear which of their members are actually relevant in a given case.
  - nogridbag 9y ago
    Absolutely it's bad OO design. Because it's very difficult to do OO right at scale. For a larger application like many I've worked on (thousands of domain classes), it's much less risky to have an anemic domain model than attempt to model a very complex domain properly. I would imagine in the Java world most applications that use ORMs tend to lean towards anemic domain models that simply mirror DB tables.
- frankpf 9y ago
  What you want to do is possible with a structural type system. In structural type systems, type compatibility is based on the structure of the type instead of the name (as opposed to nominal type systems). An example in TypeScript: interface Named { name: string } class Person { name: string age: number // constructor here } function f(obj: Named) { // do something with obj.name } const joe = new Person('Joe', 25) // Compiles, even though Person has an extra `age` field // Person is structurally compatible with Named f(joe) If you pass f() a class/object that doesn't have a `name` property of type string, the compiler would catch your error.
flavio81 9y ago
>I’ve tried Clojure a little bit and it seems like a nice language but I’m not convinced by the lack of types. Why wouldn’t you want types? Clojure has classes and types. How can it be untyped? Machine language is untyped.

hellofunk 9y ago

>> would not be improved by adding static typing Well, that's a matter of opinion, even by long-term Clojure veterans. There is a reason Core.Typed was developed, though it hasn't been maintained recently. The fact that Rich felt the need to give the keynote at the last Clojure conference about the dynamic vs static issue shows that it is still a highly debated topic within the Clojure world.

joncampbelldev 9y ago
I think the debate may be leaning towards dynamic. - The aforementioned keynote highlighting the various reasons Rich chose to make it dynamic. - CircleCI (one of the major users and propronents of core.typed) dropping it. - The introduction of spec as an alternative for some of the reasons people use type systems (its certainly not a drop in replacement and doesn't intend to be). - Spec allowing different kinds of verification not possible with a type system on its own.
mbrodersen 9y ago
I find it interesting that Rich (and other Clojure people) feel they need to continue defending themselves again and again. While strongly typed language communities usually don't feel the need. There must be some deep doubt in the Clojure community that triggers this.
- jhhh 9y ago
  I think it's more a acknowledgement of the current state of popularity of languages and an attempt to win people over rather than a manifestation of latent doubt.
- joncampbelldev 9y ago
  Forgive me, but your comment seems a little disingenuous with the way it generalises the static community (every static language??) vs the clojure community. Many of the comments on this page show why Rich gave the keynote. Because the same advantages of type checking are put forward as a reason to not use clojure over and over. They're not wrong, static typing has advantages, but I see little acceptance of any tradeoffs (or even acceptance that such tradeoffs exist: concretion of information, coupling of distant components by shared types etc etc etc I'm just paraphrasing the keynote). He was highlighting the value proposition and tradeoffs of: being data-oriented, being dynamic and clojure.spec niceness. He felt the need to do this because he clearly felt that some people who were wavering about clojure were unsure why it was dynamic: "can't we have all this great stuff AND static types". He wanted to say "yes quite possibly you could, BUT here's the reasons why I didn't add types".

seanmcdirmid 9y ago

> Namespaces, functions and immutable data (as well as pervasive use of data instead of wrapping it in classes) There are plenty of functional programming languages that believe static typing is a significant added value even under these conditions.

joncampbelldev 9y ago
And some believe that the added value is not worth the trade off in mental overhead and ceremony. We are surely both aware of the various, numerous and flame-war arguments for static vs dynamic typing. (For my side I can only recommend Rich Hickey's talk "Effective Programs", he says it better than me) My main point was that dynamic typing should be judged by it's best implementations, not by JavaScript. For example, I would not judge static typing by Java or C++.

flavio81 9y ago

>Javascript and Python are very popular dynamic languages, this doesn't make them good dynamic languages. JS in particular is a very bad example of a dynamic language, the other "very bad" example being classic PHP. This, mostly, because of weak typing. Many of the problems attributed to C, a statically-typed language, are also due to weak typing.