6 ms·

Crowdfunding for Typed Clojure and ClojureScript

182 points by swannodette 13y ago

brandonbloom 13y ago
Ambrose is doing some super awesome work with Typed Clojure. I'm a big believer in pluggable, optional type systems. Hell, even recovering typeaholics are starting to believe that Gilad Is Right [1]. Ambrose has managed to get me excited about what types can do for me in dynamic languages without bogging me down. There's lots of cool things we can do with types without having them split our language in to two sublanguages (type and term languages), pervading our compilers and runtime environments, and preventing us from doing useful things. If you view types as yet one more tool in your verification toolbox, you gain a lot of freedom. Consider "Type Coverage" as an analogy to "Test Coverage". I shared that idea with Ambrose, and he jumped right on it! [2] With good, community standardized tooling, we can forgo forcing the type system in to our compilers and down the throats of ever programmer, but still reserve the option when we need more confidence in our code. So get behind types as a library and throw a couple bucks at Ambrose so he can continue his work! [1]: http://lambda-the-ultimate.org/node/1311 http://lambda-the-ultimate.org/node/1311 [2]: https://groups.google.com/d/topic/clojure/qiE7PP9uGKg/discussion https://groups.google.com/d/topic/clojure/qiE7PP9uGKg/discus...
- vmind 13y ago
  Making the type system pluggable and a separate pass also means you can do cool things like interfacing your type system with your database [1]. And the Heterogeneous and Value types mean you can be very flexible and precise with your requirements while also coding in a mostly idiomatic Clojure way. (Though things are obviously still raw or unimplemented, the base is looking good and shaping up quickly.) [1]: https://gist.github.com/c-spencer/6569571 https://gist.github.com/c-spencer/6569571 (just a PoC)
  - moomin 13y ago
    Yes, although that's not the only wayh to do these things: F# has type providers, for instance. Although I've been burnt by C# web services and Hibernate often enough to be sceptical of the idea.
    - brandonbloom 13y ago
      Worth pointing out: Type providers, while awesome, are simply code generators that run interleaved with the type checking pass. What's happening in that linked Gist is a bit different: It's generating types signatures that are devoid of their own behavior. In order to recreate type providers (or Hibernate-like things), you'd also need to give a type as a parameter to a macro for code generation. Since you can invoke the type checker at anytime, you can interleave code generation and type checking in much the same way as F#. I don't think it's a good idea to generate code and strongly coupled types at the same time. An alternative approach would be to take some common source data structure, generate code and then generate types to validate that code. Those are two separate transformations, not one like with type providers. Type providers mean that type checking, compilation, and execution are coupled. In this Gist, you could run the code with or without type checking and you could ignore the code generation completely and run type checking for internal consistency. Much more flexible.
- deleted 13y ago
  [deleted]
swannodette 13y ago
Here's IMO a pretty freaking cool snippet of the possibilities, generating a static type from your database - http://gist.github.com/c-spencer/6569571 http://gist.github.com/c-spencer/6569571
- straight_talk_2 13y ago
  F# type providers already do that, also static types from CSV files, REST services and many others.
  - swannodette 13y ago
    I didn't realize this until someone else mentioned it today. Thanks for bringing it up, very cool.
  - ambrosebs 13y ago
    Cool!
  - brandonbloom 13y ago
    I explain how this differs from type providers here: https://news.ycombinator.com/item?id=6462374 https://news.ycombinator.com/item?id=6462374
michaelochurch 13y ago
As a major fan of Clojure and also of the possibilities of static typing, I have to give this campaign major props. I hope it funds. Also, the perks are really cheap compared to the value, including exposure (because even though Clojure is a small community, it's a really strong community).
cgag 13y ago
Backed. Optional typing seems really promising, I'd like to hear more about what kinds of things it can't do though. If you hypothetically do annotate all your code, what are you missing out on by not having pervasive static typing built in like in Haskell? Is it mostly the fact that you're much less likely to go back and annotate all your code or are there deeper trade offs I'm not seeing since I'm not that experienced with strongly statically typed languages? Does anyone know any good resources about the tradeoffs?
- rayiner 13y ago
  It depends on the particular type system. For example in Dylan or Common Lisp (or Dart), annotating all types doesn't guarantee anything about whether you can still have type errors at runtime. In typed-clojure or typed-racket, you have a guarantee that if a type error does happen, it will happen either in dynamically-typed code, or on the boundary between dynamically and statically typed code.
- ambrosebs 13y ago
  Thanks. There are certainly important tradeoffs. Haskell the language and Haskell the type system are designed to prevent many kinds of programming mistakes. Typed Clojure is designed to follow any decisions Clojure makes. For example, it's not a type error to lookup a nonexistent key in a map, so we can't really catch typos in keys. Clojure allows dynamic code loading, so it would be rather fruitless to try completeness checking (and languages like Haskell can do it so much better). You might want to watch my 2012 Clojure Conj talk. I think it touches briefly on this issue. I've always tried to be upfront about the limitations of Typed Clojure. I apologise if that was a bit rambly, it's 5AM :)
- brandonbloom 13y ago
  > kinds of things it can't do The most obvious thing an optional type system can't do is perform implicit searches that affect the semantics of the resulting program. Many of us consider this to be a good thing! > what are you missing out on by not having pervasive static typing built in like in Haskell One example of an implicit search is Haskell's return type polymorphism, where overloading is resolved by solving a logic puzzle to find a function with an unambiguous type signature match. You can get around this problem statically or dynamically: Statically #1: Explicit Search Although probably overkill for something like resolving "read" to "readInteger" vs "readFloat", you can invoke a logic engine on a piece of code. This means that your language needs to support staging constructs, so that you can run code at various "times". Macros give us this, but there are potentially better mechanisms. You'll also need first class representations of previous loaded code, code under observation, the type solver, etc. People do things like this with core.logic in Clojure now: They generate a data structure, solve something about it, then either generate code from the solution or interpret some annotated data structure. Statically #2: Explicit Parameterization Just be explicit and write readFloat instead of read! If you need your code to be generic, you can use macros etc to fill in that slot at compile time. Dynamically: OOP Techniques See "Existential Types". As long as your coding to interfaces instead of concrete types, you can create proxy objects who can perform dynamic dispatch. What is a search problem at compile time is often a key lookup at runtime. This is what happens behind the scenes with generic monad code in GHC and friends anyway: They reify a dictionary of methods and thread that through.
jafaku 13y ago
So why didn't Clojure have this from the beginning? Wasn't that on purpose?
- straight_talk_2 13y ago
  So why didn't humankind go to the stars from the very beginning? Wasn't that it's purpose?
- gw 13y ago
  Clojure is a small core of a language that can be flexibly extended with libraries in ways that other languages would require built-in support for. See core.async for another example of this.
  - jafaku 13y ago
    Oh I see, I didn't know that. Thanks.
- ambrosebs 13y ago
  Most of the research that Typed Clojure is based on didn't even exist when Clojure was created. Rich just made the best language he could, and waited for type theory to catch up, as it were! See this goldmine of papers for Typed Racket http://www.ccs.neu.edu/home/samth/ http://www.ccs.neu.edu/home/samth/
craigching 13y ago
This is probably a stupid question, but I know that Ambrose has written and presented on a type checker written in core.logic. Is this related to that in any way?
- swannodette 13y ago
  Unrelated, Typed Clojure is based on research that went into Typed Racket
  - ambrosebs 13y ago
    Just as cool though! :)
akurilin 13y ago
Is there a list of interesting practical use-cases for this that someone used to regular dynamic Clojure could look at to better understand the benefits?
- ambrosebs 13y ago
  It's invaluable with abstract code that throws around functions. It's also fantastic for documenting your code. Watch "Typed Clojure" 2012 Conj talk, might reveal more about where it's best suited.
mamcx 13y ago
Is weird. If you have static types then want dynamic (I want it with Delphi). If have dynamic then want static (I want it with python). I have thinking in how a language with both could be. For example, say Customer.Name(Str) is static but Customer..Name(?Str) is dynamic. In my experience, is better to have static typing almost all the time and "escape" to dynamic for auto-generate things (like data from a DB) and/or quick experiments...
- r4vik 13y ago
  isn't that what C# does with it's static dynamic type?
  - mamcx 13y ago
    Is different because you need to type your untyped type! I think in just a change in the "." or ".." character. So is not necessary to type the untyped, just change the dot for another thing to bypass the type checking in compile time
stephen 13y ago
I'm not a Clojure guy, but I'd love to see this type of funding for language/tool developers take off. We as an industry/community get so much for free (and expect it these days), that it's ridiculous the only way for devs to get paid to do this is sell support contracts to enterprises (Redhat, Spring, TypeSafe). Or work for companies so embarrassingly profitable (Google) that they can subsidize it. Neither of which is funds being provided to the developers themselves. Not that I want to jump over to an MS-style "pay for everything" approach--open source is great, but seems like there could be a balance/middle ground that we're missing.
- alexatkeplar 13y ago
  Completely agree - very excited to have just sponsored Ambrose's project as Snowplow Analytics. As an industry we need to get much better at acknowledging and supporting the role the technology components "under us" in the stack play in our own products' success; Zed Shaw made this exact point talking about Mongrel in his Why I (A/L)GPL post.[1] So direct sponsorship to developers doing innovative things is great - and Typed Clojure is really innovative, one of the things I'm most excited about at the moment (along with Mesos, Rust and Summingbird). We don't use a lot of Clojure at Snowplow yet - but we use some[2], and we will likely use a lot more with Typed Clojure, because optional typing is such a great fit for ETL work. Keep up the great work Ambrose! [1] http://zedshaw.com/essays/why_i_gpl.html http://zedshaw.com/essays/why_i_gpl.html [2] https://github.com/snowplow/snowplow/tree/master/2-collectors/clojure-collector https://github.com/snowplow/snowplow/tree/master/2-collector...
DigitalSea 13y ago
This is actually a really cool and decent crowd-funding campaign. It looks like it's going to get funded as well, I might even donate a few dollars myself. Aside: Looks like Ambrose is an Australian guy as well. Spotted the accent immediately, as a fellow Australian myself it makes me proud to see another Australian who not only is super smart but has created something that I think is extremely useful. My experience with Typed Closure has been limited, but I think this deserves to be funded.
- ambrosebs 13y ago
  Thanks!
IsTom 13y ago
I hope it turns out better than optional typing for Erlang. I have frustrating memories of using it, which left me sceptic for optional typing features.
riggins 13y ago
my first thought was getting 6 months of his time for 20K seems like an incredible bargain.

182 points by swannodette 13y ago

Ambrose is doing some super awesome work with Typed Clojure. I'm a big believer in pluggable, optional type systems. Hell, even recovering typeaholics are starting to believe that Gilad Is Right [1]. Ambrose has managed to get me excited about what types can do for me in dynamic languages without bogging me down. There's lots of cool things we can do with types without having them split our language in to two sublanguages (type and term languages), pervading our compilers and runtime environments, and preventing us from doing useful things. If you view types as yet one more tool in your verification toolbox, you gain a lot of freedom. Consider "Type Coverage" as an analogy to "Test Coverage". I shared that idea with Ambrose, and he jumped right on it! [2] With good, community standardized tooling, we can forgo forcing the type system in to our compilers and down the throats of ever programmer, but still reserve the option when we need more confidence in our code. So get behind types as a library and throw a couple bucks at Ambrose so he can continue his work! [1]: http://lambda-the-ultimate.org/node/1311 http://lambda-the-ultimate.org/node/1311 [2]: https://groups.google.com/d/topic/clojure/qiE7PP9uGKg/discussion https://groups.google.com/d/topic/clojure/qiE7PP9uGKg/discus...

vmind 13y ago
Making the type system pluggable and a separate pass also means you can do cool things like interfacing your type system with your database [1]. And the Heterogeneous and Value types mean you can be very flexible and precise with your requirements while also coding in a mostly idiomatic Clojure way. (Though things are obviously still raw or unimplemented, the base is looking good and shaping up quickly.) [1]: https://gist.github.com/c-spencer/6569571 https://gist.github.com/c-spencer/6569571 (just a PoC)
- moomin 13y ago
  Yes, although that's not the only wayh to do these things: F# has type providers, for instance. Although I've been burnt by C# web services and Hibernate often enough to be sceptical of the idea.
  - brandonbloom 13y ago
    Worth pointing out: Type providers, while awesome, are simply code generators that run interleaved with the type checking pass. What's happening in that linked Gist is a bit different: It's generating types signatures that are devoid of their own behavior. In order to recreate type providers (or Hibernate-like things), you'd also need to give a type as a parameter to a macro for code generation. Since you can invoke the type checker at anytime, you can interleave code generation and type checking in much the same way as F#. I don't think it's a good idea to generate code and strongly coupled types at the same time. An alternative approach would be to take some common source data structure, generate code and then generate types to validate that code. Those are two separate transformations, not one like with type providers. Type providers mean that type checking, compilation, and execution are coupled. In this Gist, you could run the code with or without type checking and you could ignore the code generation completely and run type checking for internal consistency. Much more flexible.
deleted 13y ago
[deleted]

swannodette 13y ago

Here's IMO a pretty freaking cool snippet of the possibilities, generating a static type from your database - http://gist.github.com/c-spencer/6569571 http://gist.github.com/c-spencer/6569571

straight_talk_2 13y ago
F# type providers already do that, also static types from CSV files, REST services and many others.
- swannodette 13y ago
  I didn't realize this until someone else mentioned it today. Thanks for bringing it up, very cool.
- ambrosebs 13y ago
  Cool!
- brandonbloom 13y ago
  I explain how this differs from type providers here: https://news.ycombinator.com/item?id=6462374 https://news.ycombinator.com/item?id=6462374

michaelochurch 13y ago

As a major fan of Clojure and also of the possibilities of static typing, I have to give this campaign major props. I hope it funds. Also, the perks are really cheap compared to the value, including exposure (because even though Clojure is a small community, it's a really strong community).

cgag 13y ago

Backed. Optional typing seems really promising, I'd like to hear more about what kinds of things it can't do though. If you hypothetically do annotate all your code, what are you missing out on by not having pervasive static typing built in like in Haskell? Is it mostly the fact that you're much less likely to go back and annotate all your code or are there deeper trade offs I'm not seeing since I'm not that experienced with strongly statically typed languages? Does anyone know any good resources about the tradeoffs?

rayiner 13y ago
It depends on the particular type system. For example in Dylan or Common Lisp (or Dart), annotating all types doesn't guarantee anything about whether you can still have type errors at runtime. In typed-clojure or typed-racket, you have a guarantee that if a type error does happen, it will happen either in dynamically-typed code, or on the boundary between dynamically and statically typed code.
ambrosebs 13y ago
Thanks. There are certainly important tradeoffs. Haskell the language and Haskell the type system are designed to prevent many kinds of programming mistakes. Typed Clojure is designed to follow any decisions Clojure makes. For example, it's not a type error to lookup a nonexistent key in a map, so we can't really catch typos in keys. Clojure allows dynamic code loading, so it would be rather fruitless to try completeness checking (and languages like Haskell can do it so much better). You might want to watch my 2012 Clojure Conj talk. I think it touches briefly on this issue. I've always tried to be upfront about the limitations of Typed Clojure. I apologise if that was a bit rambly, it's 5AM :)
brandonbloom 13y ago
> kinds of things it can't do The most obvious thing an optional type system can't do is perform implicit searches that affect the semantics of the resulting program. Many of us consider this to be a good thing! > what are you missing out on by not having pervasive static typing built in like in Haskell One example of an implicit search is Haskell's return type polymorphism, where overloading is resolved by solving a logic puzzle to find a function with an unambiguous type signature match. You can get around this problem statically or dynamically: Statically #1: Explicit Search Although probably overkill for something like resolving "read" to "readInteger" vs "readFloat", you can invoke a logic engine on a piece of code. This means that your language needs to support staging constructs, so that you can run code at various "times". Macros give us this, but there are potentially better mechanisms. You'll also need first class representations of previous loaded code, code under observation, the type solver, etc. People do things like this with core.logic in Clojure now: They generate a data structure, solve something about it, then either generate code from the solution or interpret some annotated data structure. Statically #2: Explicit Parameterization Just be explicit and write readFloat instead of read! If you need your code to be generic, you can use macros etc to fill in that slot at compile time. Dynamically: OOP Techniques See "Existential Types". As long as your coding to interfaces instead of concrete types, you can create proxy objects who can perform dynamic dispatch. What is a search problem at compile time is often a key lookup at runtime. This is what happens behind the scenes with generic monad code in GHC and friends anyway: They reify a dictionary of methods and thread that through.

jafaku 13y ago

So why didn't Clojure have this from the beginning? Wasn't that on purpose?

straight_talk_2 13y ago
So why didn't humankind go to the stars from the very beginning? Wasn't that it's purpose?
gw 13y ago
Clojure is a small core of a language that can be flexibly extended with libraries in ways that other languages would require built-in support for. See core.async for another example of this.
- jafaku 13y ago
  Oh I see, I didn't know that. Thanks.
ambrosebs 13y ago
Most of the research that Typed Clojure is based on didn't even exist when Clojure was created. Rich just made the best language he could, and waited for type theory to catch up, as it were! See this goldmine of papers for Typed Racket http://www.ccs.neu.edu/home/samth/ http://www.ccs.neu.edu/home/samth/

craigching 13y ago

This is probably a stupid question, but I know that Ambrose has written and presented on a type checker written in core.logic. Is this related to that in any way?

swannodette 13y ago
Unrelated, Typed Clojure is based on research that went into Typed Racket
- ambrosebs 13y ago
  Just as cool though! :)

akurilin 13y ago

Is there a list of interesting practical use-cases for this that someone used to regular dynamic Clojure could look at to better understand the benefits?

ambrosebs 13y ago
It's invaluable with abstract code that throws around functions. It's also fantastic for documenting your code. Watch "Typed Clojure" 2012 Conj talk, might reveal more about where it's best suited.

mamcx 13y ago

Is weird. If you have static types then want dynamic (I want it with Delphi). If have dynamic then want static (I want it with python). I have thinking in how a language with both could be. For example, say Customer.Name(Str) is static but Customer..Name(?Str) is dynamic. In my experience, is better to have static typing almost all the time and "escape" to dynamic for auto-generate things (like data from a DB) and/or quick experiments...

r4vik 13y ago
isn't that what C# does with it's static dynamic type?
- mamcx 13y ago
  Is different because you need to type your untyped type! I think in just a change in the "." or ".." character. So is not necessary to type the untyped, just change the dot for another thing to bypass the type checking in compile time

stephen 13y ago

I'm not a Clojure guy, but I'd love to see this type of funding for language/tool developers take off. We as an industry/community get so much for free (and expect it these days), that it's ridiculous the only way for devs to get paid to do this is sell support contracts to enterprises (Redhat, Spring, TypeSafe). Or work for companies so embarrassingly profitable (Google) that they can subsidize it. Neither of which is funds being provided to the developers themselves. Not that I want to jump over to an MS-style "pay for everything" approach--open source is great, but seems like there could be a balance/middle ground that we're missing.

alexatkeplar 13y ago
Completely agree - very excited to have just sponsored Ambrose's project as Snowplow Analytics. As an industry we need to get much better at acknowledging and supporting the role the technology components "under us" in the stack play in our own products' success; Zed Shaw made this exact point talking about Mongrel in his Why I (A/L)GPL post.[1] So direct sponsorship to developers doing innovative things is great - and Typed Clojure is really innovative, one of the things I'm most excited about at the moment (along with Mesos, Rust and Summingbird). We don't use a lot of Clojure at Snowplow yet - but we use some[2], and we will likely use a lot more with Typed Clojure, because optional typing is such a great fit for ETL work. Keep up the great work Ambrose! [1] http://zedshaw.com/essays/why_i_gpl.html http://zedshaw.com/essays/why_i_gpl.html [2] https://github.com/snowplow/snowplow/tree/master/2-collectors/clojure-collector https://github.com/snowplow/snowplow/tree/master/2-collector...

DigitalSea 13y ago

This is actually a really cool and decent crowd-funding campaign. It looks like it's going to get funded as well, I might even donate a few dollars myself. Aside: Looks like Ambrose is an Australian guy as well. Spotted the accent immediately, as a fellow Australian myself it makes me proud to see another Australian who not only is super smart but has created something that I think is extremely useful. My experience with Typed Closure has been limited, but I think this deserves to be funded.

ambrosebs 13y ago
Thanks!

IsTom 13y ago

I hope it turns out better than optional typing for Erlang. I have frustrating memories of using it, which left me sceptic for optional typing features.

riggins 13y ago

my first thought was getting 6 months of his time for 20K seems like an incredible bargain.