Absolutely, both that and the dogfooding are compelling arguments :-) On 21 October 2016 at 20:04, Colin Yates <colin.ya...@gmail.com> wrote:
> "making me sad" is unsustainable - problem solving with 1s and 0s is > hard enough as it is without using demotivating tools :-). > > On 21 October 2016 at 18:40, Colin Fleming <colin.mailingl...@gmail.com> > wrote: > > I tried it a couple of years ago, and my impressions were more or less > the > > same as CircleCI's here. I found the type annotation burden much higher > than > > using a typed language such as Kotlin, the type checking was very slow > and > > the boundary between typed and untyped code was really onerous. Ambrose > has > > done some great work recently though, so I should check it out again. > > However my general feeling is that retrofitting something like Typed > Clojure > > onto an existing language is always going to be more difficult and > fraught > > with problems than having a language which was designed with the types in > > mind in the first place. > > > > Another possibility which I haven't had time to explore properly is Allen > > Rohner's spectrum. > > > > Honestly, the easiest solution to my problem is probably just to use > Kotlin, > > which was designed by JetBrains for almost exactly my use case, has great > > IDE support, and has a lot of smart people working full-time on it. > However > > that has a couple of problems: 1) it would make me sad and 2) I would no > > longer be dogfooding Cursive all the time, which is a valuable source of > > finding bugs during development. But at least I'd be spending all my > time on > > developing Cursive features, and not chasing NPEs or investigating all > this. > > > > On 21 October 2016 at 19:20, Josh Tilles <merelyapseudo...@gmail.com> > wrote: > >> > >> Out of curiosity, did you try Typed Clojure? It certainly has its rough > >> edges, but you sound willing to bear the burden of annotating code with > >> types (at the top-level, at least) and I think its treatment of Java > interop > >> does what you want: unless instructed otherwise, the typechecker assumes > >> that arguments to Java methods must not be nil and that any Java method > may > >> return nil. > >> > >> On Thursday, October 20, 2016 at 8:39:04 AM UTC-4, Colin Fleming wrote: > >>> > >>> I recently spent a bunch of time researching exactly this. My > motivation > >>> was that my main project, Cursive, suffers from a ton of NPEs which I > find > >>> very difficult to manage. I wanted to see how difficult it would be to > have > >>> a typed Clojure-like thing, using something similar to Kotlin's type > system. > >>> Kotlin uses a type system which is similar to Java and has Java > interop as a > >>> primary goal, which I would also need since Java interop is essential > to me. > >>> It fixes a bunch of flaws in the Java type system and adds new > features like > >>> nullable types, which I now find it difficult to live without. > >>> > >>> Before anyone asks, spec is not useful for me because it relies heavily > >>> on generative testing to increase your confidence in your functions. I > can't > >>> use generative testing because my application is tied to a large Java > >>> codebase which I cannot model to any useful degree. Essentially, spec > >>> recommends runtime tests at the boundary of your system, and nearly my > >>> entire system is interop boundary. I'm not interested in runtime checks > >>> except where absolutely necessary - Kotlin does this for me > transparently, > >>> spec doesn't. > >>> > >>> Here's a short list of my findings. I'm happy to expand on any of these > >>> points if anyone is curious. It bears repeating - Java interop is > >>> non-negotiable for me, and that makes a lot of this harder than it > would be > >>> otherwise. > >>> > >>> Disclaimer: I'm no programming language expert. This was hard for me, > and > >>> a surprising amount of it was new to me. I'd appreciate any > corrections or > >>> clarifications. > >>> > >>> Type systems are hard. I for one didn't appreciate the complexity that > >>> goes into making them easy to use. Don't be fooled by the 20-line > >>> implementations of Hindley-Milner. > >>> In particular, generics are very hard, and variance for generic objects > >>> (i.e. the intersection of generic objects and OO) is the source of much > >>> difficulty. > >>> Type systems are split into two main camps - nominal typing (like Java, > >>> where the types are identified by names) and structural typing, where > the > >>> type of an object is defined by it's "shape", like Go's interfaces. > >>> One of the major benefits of Clojure is its heterogeneous collections, > >>> a.k.a. "just use a map". This is very difficult to maintain in a > type-safe > >>> manner without losing most of the benefit. > >>> There are two main things I was interested in from a type system - type > >>> checking (i.e. making sure that your program's types are correct) and > type > >>> inference (working out what the types of things are from the code, so > you > >>> don't have to annotate everything). Type checking is relatively > >>> straightforward, but type inference can be very hard indeed. > >>> Much of the complication comes from the need to interop with Java. > >>> ML-style interface essentially doesn't work if you want to maintain > >>> compatibility with Java since it cannot be interfaced in a useful way > with > >>> nominal OO systems. In particular, method overriding is basically > impossible > >>> to represent. > >>> #6 implies that you cannot have a language with good Java interop and > >>> global type inference, i.e. you will definitely be annotating your > function > >>> parameter types, and your function return types. I'm ok with this > since IMO > >>> it's a good practice anyway. > >>> Once you start thinking about the fact that you no longer have > >>> heterogeneous collections, and start thinking about what the > alternatives > >>> would look like, you start to realise that you'd end up with basically > the > >>> ML family style of data types - homogeneous collections, typed tuples > and > >>> ADTs. I'm actually ok with that too, since they're a very nice set of > >>> primitives and I think they probably represent 95% of how people use > >>> Clojure's collections anyway. > >>> Structural typing seems like it might be a good fit for something like > >>> Clojure's maps. However, mixing structural and nominal typing and OO > seems > >>> to be the path to madness. > >>> > >>> I think that's it. This is still a project I'd like to tinker with at > >>> some point, but I think it's fair to say that I dramatically > underestimated > >>> the amount of work a useful Java-compatible type system would be. I > still > >>> think it seems like a nice point in the language design space though, > which > >>> is curiously unfilled on the JVM (some of you may have noticed that I > >>> basically want F# with nullable types). > >>> > >>> Cheers, > >>> Colin > >>> > >>> On 16 October 2016 at 00:14, Didier <did...@gmail.com> wrote: > >>>> > >>>> I know a lot of people like to say how unhelpful Java like static > typing > >>>> is, and only more powerful type systems of the ML family add value, > but I've > >>>> been wondering recently if for Clojure it wouldn't make more sense to > simply > >>>> extend the type hints to enable an optional Java like static typing > scheme. > >>>> > >>>> It is my understanding that ML style static typing is incredibly > >>>> difficult to add properly and without compromise to a dynamic > language. That > >>>> doing so limits the scope of type inference, rendering the task of > adding > >>>> type info more tedious then in ML languages themselves. > >>>> > >>>> ML style static typing provide enhanced safety grantees, but seem to > add > >>>> too much complexity to Clojure to be practical. What about a Java like > >>>> static typing scheme though? > >>>> > >>>> I haven't found in practice that the safety of Clojure was an issue, > as > >>>> the REPL workflow tend to promote quite a lot of testing. So I'm not > too > >>>> worried about needing the state of the art of provable correctness > for my > >>>> programs. What has been a biggest cause of issue to me was > refactoring and > >>>> shared code base across a team. Those last two use cases are actually > pretty > >>>> well handled by Java like static type checking. Is it a powerful type > >>>> checker, not really, but it enables most trivial type errors to be > caught > >>>> early, and it allows easier integration points for other devs to > follow, as > >>>> well as documentation for functions, better tools support and easier > >>>> refactoring, while also enabling performance optimizations. > >>>> > >>>> I have limited knowledge in typing systems, and have no idea how easy > it > >>>> is to implement them, but as a user of Clojure, I feel like I would > find an > >>>> optional Java like static typing a great addition, one that I am more > >>>> willing to use and benefit from then Typed Clojure's more complex ML > style > >>>> type checking. > >>>> > >>>> What do other think? > >>>> Can anyone with better knowledge tell me if this would be feasible or > if > >>>> adding such gradual typing system is effectively as hard as adding ML > style > >>>> type checking? > >>>> > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "Clojure" group. > >>>> To post to this group, send email to clo...@googlegroups.com > >>>> Note that posts from new members are moderated - please be patient > with > >>>> your first post. > >>>> To unsubscribe from this group, send email to > >>>> clojure+u...@googlegroups.com > >>>> For more options, visit this group at > >>>> http://groups.google.com/group/clojure?hl=en > >>>> --- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "Clojure" group. > >>>> To unsubscribe from this group and stop receiving emails from it, send > >>>> an email to clojure+u...@googlegroups.com. > >>>> For more options, visit https://groups.google.com/d/optout. > >>> > >>> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from this group, send email to > >> clojure+unsubscr...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/clojure?hl=en > >> --- > >> You received this message because you are subscribed to the Google > Groups > >> "Clojure" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to clojure+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
