
Is Typed Clojure worth the trouble? - jonpither
http://blog.juxt.pro/posts/typed-clojure.html
======
Quanttek
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

~~~
Skinney
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.

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

~~~
Skinney
Yeah. They are not really necessary in a Javascript VM that is optimized for
these sort of languages anyway.

~~~
swannodette
This is not entirely accurate, the ClojureScript compiler actually internally
propagates type information for further optimization. And nothing precludes a
Typed ClojureScript which feeds even more information to the compiler.

------
nmrm2
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.

~~~
JadeNB
> Tests aren't verification, and they cannot demonstrate correctness (without
> being exhaustive).

Agreed, but it's important to note that there's very little that _can_
demonstrate correctness. Most type systems by themselves don't; as Pierce
describes it in TAPL, "[a] type system is a syntactic method for automatically
checking the absence of _certain_ erroneous behaviors" (emphasis mine). It's
possible that, in a dependent type system, those certain behaviours will be
sufficiently many that you can prove the correctness of a program
specification, but even a rich system like Haskell's usually doesn't offer
such guarantees (just consider `tail []`; or, for an example that's not just a
Prelude wart, `take n xs`).

~~~
nmrm2
It's difficult to demonstrate full functional correctness. However, it is
pretty easy to demonstrate partial correctness. Most tests -- even if they
were completely exhaustive -- correspond to partial correctness rather than
functional correctness.

------
arh68
I like how:

\- first, the ClojureScript REPL whines at smelly coercions out of the box

    
    
      cljs.user=> (+ 1 "2" nil)
      WARNING: cljs.core/+, all arguments must be numbers,
          got [number string] instead. at line 1 <cljs repl>
      WARNING: cljs.core/+, all arguments must be numbers,
          got [number clj-nil] instead. at line 1 <cljs repl>
      "12null"
    

\- second, the author kind of hints you should be using schemas & coercion
already (so as to desmellify)

\- third, you can typecheck a codebase incrementally

Also, I really thought I'd see that quote about 100 functions operating on a 1
data structure easier to grok than 10 functions operating on 10 different data
structures. Of course, it's nicer when that 1 data structure (or even the 10)
has a schema instead of being void *.

------
jstuxx
Doesn't Clojure already have optional static type annotations like Common
Lisp? I thought it did when I looked through the tutorials.

In Common Lisp you can define pretty much any type (with deftype), you can
define algebraic types and even value dependent types. Once you add full type
declarations to your code, you will get warnings for inconsistent and violated
type declarations.

------
sebastianconcpt
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.

~~~
boothead
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 of the flub paradox article are wrong
[http://steved-imaginaryreal.blogspot.co.uk/2015/06/the-
flub-...](http://steved-imaginaryreal.blogspot.co.uk/2015/06/the-flub-
paradox.html)

~~~
sebastianconcpt
Thanks for the downvotes, I was referring to things beyond FP. The type system
is a set of early restrictions (as opposing to late restrictions or runtime or
late bound). But now you mention it, I'm curious about if you think the type
checker allowed you and your team to reach the goals of the project faster or
not.

~~~
dllthomas
I had a system in C, with a goal of extremely low latency. This involved a
small collection of threads, each serving a different role. Project goals
would periodically change, and I would find myself needing to move some
functionality from one thread to another. With some creativity, I was able to
enlist the help of the type checker in assuring that a particular function ran
only on a particular thread. This sped me up tremendously, as my tooling would
point me to inconsistencies rather than having to reason them out myself.

