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