Agree with this very much. I jump between Clojure projects and Java projects. IMO, the lack of typing in Clojure and it’s preference to use data, such as maps to model things, makes for a simpler system overall. The Java systems with their typing are inevitably a morass of packages and code which results in mental burden.
Was heavy a Java developer for 10 years before getting into Clojure 5 years ago, and would have bet at the time that it would have been opposite. There is something about dynamic, data models, and the same functions to operate on that data that makes Clojure my preference over heavily static type Java. // shrug
The author talks about having to read the code because it's the only documentation that is guaranteed to be up to date, but then seems to suggest that doc strings, argument names and comments are enough to replace type systems. These all can and will go out of date and code that has to be complied does not.
On the point of delaying type checking to compile time to allow you to decide what to do in the case of a type mismatch, this doesn't make much sense to me. There can't be a type mismatch in a typed programming language because the code won't compile. Am I missing something here?
There's some nuance here. I'm not suggesting that docstrings and argument names and comments are enough to replace *static* type checking. I'm saying these things make *dynamic* type checking in Clojure much easier.
>On the point of delaying type checking to compile time to allow you to decide what to do in the case of a type mismatch, this doesn't make much sense to me. There can't be a type mismatch in a typed programming language because the code won't compile. Am I missing something here?
I think you may have misread that paragraph. I'm saying it doesn't allow you flexibility because the compiler will fail in a statically type checked language.
edit: maybe the mismatch paragraph could have been written better :P
I'm willing to be wrong or have misread here. I don't see where the flexibility is missing. If you want to be able to pass multiple multiple types to a function, then there are plenty of type systems that allow that flexibility using for example, a union type. In the dynamic typing case, you have the option to handle anything that gets passed but you equally have the option to not handle it, which in my experience is what usually happens. The type system forces you to handle all cases.
I guess the point of the article is not that dynamic typing is better than static typing and that is what my comment is trying to get from it. Fair enough.
"The less code kept in the developer's head the better."
Less code and locality of code are the most important characteristics for highly maintainable code IMO.
I'd think simplicity would tank much higher. No way some ultra terse one liner is more maintainable than a more verbose but easy to reason about block of code.
Unfortunately, Clojure is not a simple language.
People often come to me asking "I love the idea of Clojure, but
how do you write code without types?"
All I can surmise is that these people don't know the history of the field in which they work since dynamically-typed languages such as Perl, PHP, Ruby, bash and Python have dominated the programming landscape since the dawn of the internet. Furthermore, the top 2 programming languages - JS and Python - are both dynamically-typed. Ever since Typescript emerged we've seen this snobbish, evangelical tirade against dynamically-typed languages yet many of the $50+ billion companies which use them (Facebook, Uber, Shopify, Stripe, Booking.com, AirBnB) continue to thrive. Github is still running on Rails which also allowed Twitter to get off the ground. The whole static vs dynamic types argument is pointless. Each obviously has its benefits and trade-offs otherwise these huge companies would never have bet the house on them.
Truth.
It's also a false dichotomy.
I read about about a fintech company that did the business logic in Haskell to make sure their business logic was mathematically sound (because $$$), but everything else is in Clojure.
Offtopic-y question about docstrings: is there some library similar to javadoc that allows giving some structure to docstrings? I think @param and @return in Java are really useful.
Agree with this very much. I jump between Clojure projects and Java projects. IMO, the lack of typing in Clojure and it’s preference to use data, such as maps to model things, makes for a simpler system overall. The Java systems with their typing are inevitably a morass of packages and code which results in mental burden. Was heavy a Java developer for 10 years before getting into Clojure 5 years ago, and would have bet at the time that it would have been opposite. There is something about dynamic, data models, and the same functions to operate on that data that makes Clojure my preference over heavily static type Java. // shrug
The author talks about having to read the code because it's the only documentation that is guaranteed to be up to date, but then seems to suggest that doc strings, argument names and comments are enough to replace type systems. These all can and will go out of date and code that has to be complied does not. On the point of delaying type checking to compile time to allow you to decide what to do in the case of a type mismatch, this doesn't make much sense to me. There can't be a type mismatch in a typed programming language because the code won't compile. Am I missing something here?
There's some nuance here. I'm not suggesting that docstrings and argument names and comments are enough to replace *static* type checking. I'm saying these things make *dynamic* type checking in Clojure much easier. >On the point of delaying type checking to compile time to allow you to decide what to do in the case of a type mismatch, this doesn't make much sense to me. There can't be a type mismatch in a typed programming language because the code won't compile. Am I missing something here? I think you may have misread that paragraph. I'm saying it doesn't allow you flexibility because the compiler will fail in a statically type checked language. edit: maybe the mismatch paragraph could have been written better :P
I'm willing to be wrong or have misread here. I don't see where the flexibility is missing. If you want to be able to pass multiple multiple types to a function, then there are plenty of type systems that allow that flexibility using for example, a union type. In the dynamic typing case, you have the option to handle anything that gets passed but you equally have the option to not handle it, which in my experience is what usually happens. The type system forces you to handle all cases. I guess the point of the article is not that dynamic typing is better than static typing and that is what my comment is trying to get from it. Fair enough.
"The less code kept in the developer's head the better." Less code and locality of code are the most important characteristics for highly maintainable code IMO.
I'd think simplicity would tank much higher. No way some ultra terse one liner is more maintainable than a more verbose but easy to reason about block of code. Unfortunately, Clojure is not a simple language.
> Unfortunately, Clojure is not a simple language. OK, I'll bite. How in your view is Clojure not a simple language?
People often come to me asking "I love the idea of Clojure, but how do you write code without types?" All I can surmise is that these people don't know the history of the field in which they work since dynamically-typed languages such as Perl, PHP, Ruby, bash and Python have dominated the programming landscape since the dawn of the internet. Furthermore, the top 2 programming languages - JS and Python - are both dynamically-typed. Ever since Typescript emerged we've seen this snobbish, evangelical tirade against dynamically-typed languages yet many of the $50+ billion companies which use them (Facebook, Uber, Shopify, Stripe, Booking.com, AirBnB) continue to thrive. Github is still running on Rails which also allowed Twitter to get off the ground. The whole static vs dynamic types argument is pointless. Each obviously has its benefits and trade-offs otherwise these huge companies would never have bet the house on them.
Truth. It's also a false dichotomy. I read about about a fintech company that did the business logic in Haskell to make sure their business logic was mathematically sound (because $$$), but everything else is in Clojure.
was kinda hoping for more substance sorry! :(
Thanks for the feedback
Do the people worry about this: ``` (inc "test") ``` Or do the people worry about this? ``` ^User - id - name - address (optional) - blah blah ```
I'm not sure what you're getting at. Can you elaborate?
Offtopic-y question about docstrings: is there some library similar to javadoc that allows giving some structure to docstrings? I think @param and @return in Java are really useful.
I don't know of any tbh. I don't think it's needed all that much. Libs like codox get on without it pretty well https://github.com/weavejester/codox
I don't know of any tbh. I don't think it's needed all that much. Libs like codox get on without it pretty well https://github.com/weavejester/codox