Is Typed Clojure worth the trouble? • Hacker News Board

Re: Is Typed Clojure worth the trouble?

#11

Post by michaelochurch » Mon, Jun 22, 2015, 2:22 PM UTC

boothead wrote: post #3

sebastianconcpt wrote: post #2

Type checkers are an automated solution for the problem of not having good teammates. If you don't have that problem you won't benefit that much from type checking and might have many other huge advantages.

That's nonsense frankly. I've worked with an excellent team of Haskellers before I don't think we'd have been anywhere near as good without the type system. I'd agree that having an awesome team gives you a lot of other advantages, and actually FP is a huge opportunity to build that team for start ups. FP tends to attract the kind of people who make up a great team. It's for this reason that I think the conclusions o…

I'd agree that having an awesome team gives you a lot of other advantages, and actually FP is a huge opportunity to build that team for start ups. FP tends to attract the kind of people who make up a great team.

Yes, absolutely. It's amazing how overlooked this fact seems to be, by many. Languages aren't that hard to learn, so excluding the really awful ones (e.g. Java for anything other than code that has to be on the JVM and has to be fast) the "familiarity" aspect is minuscule. Programmers learn new languages quickly. What does matter is the community and the quality of programmer you'll attract based on the tools you use and the signals that your tools send about who makes decisions.

Re: Is Typed Clojure worth the trouble?

#12

Post by nmrm2 » Mon, Jun 22, 2015, 2:28 PM UTC

TheCoelacanth wrote: post #8

sebastianconcpt wrote: post #2

Type checkers are an automated solution for the problem of not having good teammates. If you don't have that problem you won't benefit that much from type checking and might have many other huge advantages.

Type checkers are an automated solution for having a human brain.

Of course, so are calculators :-)

Re: Is Typed Clojure worth the trouble?

#13

Post by nmrm2 » Mon, Jun 22, 2015, 2:36 PM UTC

I am impressed by the fact that Typed Closure is a lot of things in addition to language design -- library development, editor/tool development, even community engagement and evangelism.

> Clojure codebases typically rely on tests to verify the correctness of the code.

OT, but this is a pet peeve of mine. Tests aren't verification, and they cannot demonstrate correctness (without being exhaustive). Clojure codebases typically rely on tests to mitigate the risk of runtime errors.

Re: Is Typed Clojure worth the trouble?

#14

Post by erdeszt » Mon, Jun 22, 2015, 2:38 PM UTC

chimprich wrote: post #10

dmead wrote: post #4

Earlier quoted context omitted.

that is static typing FUD. if it takes you a few days or weeks to learn to use the type checker and it saves you from expensive runtime errors later, then whats the problem?

The problem is the overhead in adding typing. The time taken to learn the type system is a one-off but static typing has running costs in slowing down development, discouraging exploratory programming, extra cognitive load in reasoning about the type system, and "false positives" in disallowing otherwise correct programs. It does nearly eliminate a class of bugs - this is wonderful, but the bugs it does eliminate ten…

Do you have any evidence to prove this? I've read a few papers that disagree with your opinions...

Re: Is Typed Clojure worth the trouble?

#15

Post by Quanttek » Mon, Jun 22, 2015, 2:41 PM UTC

A slightly unrelated question: Are there any plans to make the compiler "aware" of the type annotations, so we could have performance improvements? Basically Typed Clojure going a similiar route as asm.js

Re: Is Typed Clojure worth the trouble?

#16

Post by cantankerous » Mon, Jun 22, 2015, 2:45 PM UTC

chimprich wrote: post #10

dmead wrote: post #4

Earlier quoted context omitted.

that is static typing FUD. if it takes you a few days or weeks to learn to use the type checker and it saves you from expensive runtime errors later, then whats the problem?

The problem is the overhead in adding typing. The time taken to learn the type system is a one-off but static typing has running costs in slowing down development, discouraging exploratory programming, extra cognitive load in reasoning about the type system, and "false positives" in disallowing otherwise correct programs. It does nearly eliminate a class of bugs - this is wonderful, but the bugs it does eliminate ten…

What about the cognitive load of chasing down things like null reference errors, which in some strongly typed languages don't even exist? And no, they're not always fairly obvious to find, especially when you're fixing somebody else's code.

Re: Is Typed Clojure worth the trouble?

#17

Post by Skinney » Mon, Jun 22, 2015, 2:54 PM UTC

Quanttek wrote: post #15

A slightly unrelated question: Are there any plans to make the compiler "aware" of the type annotations, so we could have performance improvements? Basically Typed Clojure going a similiar route as asm.js

For Clojure, I know there has been talk about this. Clojure allows you to insert Type Hints, which allows Clojure to remove reflection in certain cases, which improves both runtime and compile speed. Typed Clojure should be able to insert Type Hints automagically for you since you provide type information anyway, although it doesn't do that today.

For ClojureScript there really isn't any performance optimization to be done, as far as I know. asm.js doesn't really help out high-level functional languages like ClojureScript.

Re: Is Typed Clojure worth the trouble?

#18

Post by Skinney » Mon, Jun 22, 2015, 3:01 PM UTC

cantankerous wrote: post #16

chimprich wrote: post #10

Earlier quoted context omitted.

The problem is the overhead in adding typing. The time taken to learn the type system is a one-off but static typing has running costs in slowing down development, discouraging exploratory programming, extra cognitive load in reasoning about the type system, and "false positives" in disallowing otherwise correct programs. It does nearly eliminate a class of bugs - this is wonderful, but the bugs it does eliminate ten…

What about the cognitive load of chasing down things like null reference errors, which in some strongly typed languages don't even exist? And no, they're not always fairly obvious to find, especially when you're fixing somebody else's code.

The keyword being "some". I've rarely had any problems with null/nil reference errors in Clojure, because nil is treated both as false and as the empty list, so most of the time you do the right thing in case of nil. You also don't call methods on objects, but send values to functions, which eliminates a large source of NPE right there.

Clojure is also a compiled language. So things like calling a function with the wrong arity, and calling a variable/function that doesn't exist are caught at compile time. This is, by far, the most common runtime bugs I've experienced in Javascript and Python, due to spelling mistakes in and out of refactoring.

Re: Is Typed Clojure worth the trouble?

#19

Post by bostonOU » Mon, Jun 22, 2015, 3:03 PM UTC

Skinney wrote: post #17

Quanttek wrote: post #15

A slightly unrelated question: Are there any plans to make the compiler "aware" of the type annotations, so we could have performance improvements? Basically Typed Clojure going a similiar route as asm.js

For Clojure, I know there has been talk about this. Clojure allows you to insert Type Hints, which allows Clojure to remove reflection in certain cases, which improves both runtime and compile speed. Typed Clojure should be able to insert Type Hints automagically for you since you provide type information anyway, although it doesn't do that today. For ClojureScript there really isn't any performance optimization to b…

I believe ClojureScript only supports boolean type hints/performance optimization. Other type hints are "supported" but don't do anything.

Re: Is Typed Clojure worth the trouble?

#20

Post by Skinney » Mon, Jun 22, 2015, 3:08 PM UTC

erdeszt wrote: post #14

chimprich wrote: post #10

Earlier quoted context omitted.

The problem is the overhead in adding typing. The time taken to learn the type system is a one-off but static typing has running costs in slowing down development, discouraging exploratory programming, extra cognitive load in reasoning about the type system, and "false positives" in disallowing otherwise correct programs. It does nearly eliminate a class of bugs - this is wonderful, but the bugs it does eliminate ten…

Do you have any evidence to prove this? I've read a few papers that disagree with your opinions...

Probably based on personal experience. For me, whenever I start a project from scratch I usually start with the most dynamic environment I can find, then hack away until I have something that resembles the functionality I need, before locking it down. In the beginning of a project I don't care if something is 100% correct, I just want to see what my idea looks like, and what I actually need. I don't want to deal with synchronizing my types with a database schema, or make sure the JSON I send to the server satisfy the type system. I really don't care about interfaces or abstract classes or whatnot, I just want to retrieve the value I know to be in the object I got. Then, when I have a working'ish prototype, I can start nailing it down with types, assertions, tests and contracts.

Of course, people are different. Some people do all of this on paper before writing a single line of code. Others plan by making types and interfaces, then proceed to implement those. I just like making prototypes.