Why we're supporting Typed Clojure

http://blog.circleci.com/supporting-typed-clojure/

by pbiggar • 13 years ago

212 73 13 years ago

blog.circleci.com

brudgers3• 13 years ago

The paper behind Racket's new contract system which allows optional typing to be determined at runtime or compile time or both and across modules:

http://www.eecs.northwestern.edu/~robby/pubs/papers/oopsla20...

ambrosebs13• 13 years ago

That's insane.

bionerd• 13 years ago

For a very long time I've regarded Racket as a purely educational Scheme dialect not particularly useful for real work. It was only a few months ago that I actually bothered to look at it's (amazing!) documentation [1] and realized how wrong I've been. It's incredible what are the Racket guys doing and what they've already achieved. The Typed Racket [2, 3] is "only" a cherry on top.

[1] http://docs.racket-lang.org/

[2] The Type Racket Guide: http://docs.racket-lang.org/ts-guide/

[3] The Type Racket Reference: http://docs.racket-lang.org/ts-reference/

brudgers3• 13 years ago

I suspect it is done with higher order functions in a manner analogous to what Rich Hickey has done with map and reduce here:

http://www.infoq.com/presentations/Clojure-Reducers

breckinloggins2• 13 years ago

One of the best ways to get people to support optional typing in dynamic languages is to make sure their tools can read those types and provide metadata.

Program verification is cool, but enabling "intellisense" on a hash is even cooler.

pbiggar6• 13 years ago

Indeed. I'm hoping the IDE support will include emacs - it can already do loads of cool things connected to nrepl, but completion on a hash would be amazing.

seanmcdirmid5• 13 years ago

Does emacs support language aware intelliense (auto complete) for any language? I thought the common case was support through CTAGs.

ambrosebs13• 13 years ago

What is intellisense on a hash?

pbiggar6• 13 years ago

Autocompletion on the keys of a hash.

jafaku3• 13 years ago

Typed Clojure is one of the biggest advancements to dynamic programming languages in the last few decades. It shows that you can have the amazing flexibility of a dynamic language, while providing lightweight, optional typing.

I'm sure there have been great advances. But you are showcasing this as if it was a completely new idea, even though PHP has been using it for a long time. Correct me if I'm wrong.

ambrosebs13• 13 years ago

You're correct. Sam Tobin-Hochstadt is the star of the show, and is given a mention in the article, along with his fantastic Typed Racket.

TylerE2• 13 years ago

You're totally wrong. For one thing, PHP coerces WAY too much for any type system to be effective. That's just plain duck typing.

ambrosebs13• 13 years ago

I managed to totally miss the claim that Typed Clojure uses ideas from PHP :/ I'm pretty sure there is no relation.

jafaku3• 13 years ago

What do you mean?

pbiggar6• 13 years ago

OP here. This is substantially different than what exists in PHP. I tried to hint about this when referencing "nominal" vs "structural" in the piece, but you can just about say "I expect the parameter to be this type" in PHP, which is substantially less powerful than this.

seanmcdirmid5• 13 years ago

Gradual typing is not as radical, however, as a fully type inferred language, see:

http://research.microsoft.com/apps/pubs/default.aspx?id=1961...

I think we can go much farther in this area than we have with Hindley Milner. Of course, this is still research, but as long as you are claiming "biggest advance in the last few decades" I might as well just throw this out there.

ufo• 13 years ago

The type system for typed closure is much more powerful and is build on solid PL research. For example, it handles higher order types, union types and has a nifty system for overloading.

emiljbs• 13 years ago

On this note, this doesn't seem to be more powerful than CL:s optional typing, am I wrong?

anaphor5• 13 years ago

I still don't think this is worth supporting if you don't use Clojure. As far as dynamic languages go, I already use Racket quite a bit and as mentioned I can just use Typed Racket if I want, or I can use Racket's excellent contract system for some things (sparingly if I need good performance). Also I doubt it will catch on in the Python community, which is hostile to this sort of thing. JavaScript is perhaps a good use for it but there are already typed languages that run in the browser.

ambrosebs13• 13 years ago

FWIW I've been pushing Typed Clojure in interesting directions that can be directly applied back to Typed Racket. The implementations are so similar that there is good potential for cross pollination.

anaphor5• 13 years ago

Fair enough, it does sound like an interesting research project, I'm just not sure what will come of it. Can you make any speculations about what those directions might be? Or is it too early? Edit: global type inference? I thought that was infeasible for TR and Clojure at the moment?

juandopazo• 13 years ago

Typed Racket and Typed Clojure are major sources of inspiration/reference for typed versions of JavaScript like TypeScript and possibly future versions of EcmaScript.

zcrar70• 13 years ago

Typescript also uses 'gradual' typing. See http://siek.blogspot.co.uk/2012/10/is-typescript-gradually-t... - Siek is referenced in the original post, too.

Clojure's type system sounds more powerful than Typescript's though.

ambrosebs13• 13 years ago

AFAIK Typescript is level 1 gradual typing. Typed Clojure is also level 1, but I'm aiming for level 3.

I guess Typed Clojure is more powerful than Typescript in a few ways, but it's more about how well the type system fits the language. I've never used Typescript, but it seems to fit nicely, with interesting tradeoffs.

dribnet• 13 years ago

Pleased to see Rich Hickey also supporting this. http://www.indiegogo.com/individuals/222990/activities

memracom• 13 years ago

There is already typing in Clojure (and Python and Ruby). It`s called "100% unit test coverage". If you want it, you can have it now.

pbiggar6• 13 years ago

Unit test coverage (as much as I enjoy it, since that's how CircleCI makes all its money) is good, but it can't provide the guarantees static type checking can. Each has its place, and neither replaces the other.

steveklabnik• 13 years ago

I write lots of Ruby, and I downvoted you because this isn't very constructive.

acjohnson552• 13 years ago

Can 100% unit test coverage give you intellisense, real-time warnings, and refactoring capabilities? Nope.

Unit testing is great for verifying that a piece of code works conforms to specification, but typing verifies that you're using a piece of code as expected. Two different things.

tel2• 13 years ago

Coverage isn't the same as enumeration of all possible modes. 100% test coverage might mean that all of your "wiring" fits together, but with dynamic languages it may not as runtime information may affect your types and break things.

100% enumeration of runtime behaviors is another property, far stronger than any non-dependent static types today, but also exponentially more difficult than 100% test coverage.

Good static types are a cheap way to get probably halfway between those two on a log scale.

mcguire• 13 years ago

100% of what? The parameter value space?

heyadayo• 13 years ago

Check out cobra, python inspired -- it already helped developers "realize how great optional typing can be in everyday code": http://cobra-language.com/docs/why/

Great language too if you're down with .NET.

pjmlp2• 13 years ago

This is great news for Clojure.

Based on my experience, dynamic languages without optional typing make large scale enterprise development unbearable.

Sure, one should be writing unit tests, but in the enterprise context those tests rarely do exist, or if they do, either don't test what they should or are so complex that invalidate any re-factoring taking place.

quatrevingts• 13 years ago

Do you have any experience with the inverse statement? That is, have you had a good experience with optional types in an enterprise context?

I'm curious how many runtime errors persist due to the optionality of the type system. Perhaps code standards requiring all "library" code to be typed would be a good balance.

pjmlp2• 13 years ago

Just kind of.

Most enterprise customers I have worked with, favour dynamic languages just for scripting tasks, while using static typed ones for the large scale projects.

By large scale, I mean, projects with at least three development sites, at least 30 developers, all the different set of skills. With lots of attrition.

The only time I saw it working, was in a project done with TCL, which lacks optional types, but everyone on team was a top developer, the team was small, and located on the same open space. So startup world, not enterprise.

cabalamat2• 13 years ago

People interested in optional types for Python may be interested in my @typ decorator that implements them: https://github.com/cabalamat/ulib/blob/master/debugdec.md

Sample:

    @typ((int,float), ret=(int,float))
    def square(x):
        return x*x

Here the parameter x is an int or float, and so is the return type.

It doesn't currently let you compose types, but that wouldn't be too difficult to add, e.g. {str:int} could mean a dictionary whose keys are strings and values are integers.

acjohnson552• 13 years ago

That's okay, but that doesn't seem to help much to verify your type correctness before runtime, which seems to me to be a big part of the benefit of type checking. Also, what you'd really want is something that implements type variables like:

    @typ[A implements *](A, ret=A)
    def square(x):
        return x * x

But I don't know how you'd do that in Python.

BTW, your printargs looks pretty cool! I might just makes something like that for JS...

cabalamat2• 13 years ago

that doesn't seem to help much to verify your type correctness before runtime

I don't think that's possible in Python.

Also, what you'd really want is something that implements type variables

That is possible, you could check what the type of the incoming parameter is and then check that the return value is the same type. I'm not sure that there's an obvious syntax for saying this, but one could always send a string to @typ and have it parse some made-up syntax.

I suspect this would be a lot of effort and it would probably make sens to use a typed language, instead of trying to shoehorn it into Python. I invented @typ so I could quickly document the types in my functions, & with the added advantage that it catches some errors.

your printargs looks pretty cool! I might just makes something like that for JS...

I look forward to seeing it.

dep_b• 13 years ago

There one thing that really stirred my interest:

nil isn’t allowed

If this really is what I think it is (a certain reference to a class can never be nil) then I am really excited. It never made sense to me that someone was able to call a function I wrote that really needed instances with nils instead, so I was forced to check and throw in case they did. It's just not clear and it leads to a lot of unnecessary checking or nil pointer exceptions.

ambrosebs13• 13 years ago

nil is explicit in Typed Clojure, and it's a goal to statically avoid misuses of nil.

This rough screencast describes on aspect to the approach http://vimeo.com/55280915

mseebach• 13 years ago

An introduction to typed clojure (strangely missing from both the blog post and the IndieGoGo campaign):

http://www.clojure.net/2013/03/14/Typed-Clojure/

draegtun• 13 years ago

Perl6 & Rebol are some other examples of dynamic languages which come with optional typing.

NB. And I believe Perl6 in certain cases will/can raise compile-time type errors.

wcummings2• 13 years ago

This guy is a little too souped on optional type-checking. This has existed in erlang for years, in the form of dialyzer (which allows for compile time validation of complex nested data structures), and in any dynamic language a good developer is using pre-checks & post-checks (in the case of js) or a combination of tagged values and pattern matching to ensure type-checking at runtime.

It's a nice feature, but calling it "one of the biggest advancements to dynamic programming languages in the last few decades" is ignorant.

pbiggar6• 13 years ago

OP here. I do actually believe what I said.

Pre- and post-checks are of course possible, but I've rarely seen them used in practice. More importantly, they can't be used to provide any sort of correctness guarantee, which static typing can.

I'm not sure what you mean by tagged values and pattern matching - I know what those concepts are, but I think you're saying they're widely used by good developers? I have not seen evidence for this.

The reason I call it one of the biggest advancements is that it is actually being used in production, has low overhead (both in cognitive load and performance-wise), and actually handles the complexities of duck-typing. It shows that it is practical. (By contrast, Erlang is sufficiently different to most other dynamic languages, both in use case and semantics, that it is difficult to generalize from Erlang to say Python).

wcummings2• 13 years ago

Pre- and post-checks are of course possible, but I've rarely seen them used in practice.

I agree, I wish more people (especially Javascript developers) saw the value of pre (and post!) checking.

The reason I call it one of the biggest advancements is that it is actually being used in production, has low overhead (both in cognitive load and performance-wise), and actually handles the complexities of duck-typing. It shows that it is practical. (By contrast, Erlang is sufficiently different to most other dynamic languages, both in use case and semantics, that it is difficult to generalize from Erlang to say Python).

This is fair, I just meant to point out that conceptually this isn't new, it's just a new implementation. Can you expand a bit on what you said about duck-typing?

ambrosebs13• 13 years ago

I will tiptoe carefully around the issue you're bringing up and point out that the styles of type checking provided by Dialyzer and Typed Clojure are pretty different.

Why we're supporting Typed Clojure

Related Stories