These are chat archives for evhub/coconut

Nov 2016
Evan Hubinger
Nov 29 2016 17:48
@eshansingh I think that's a great idea! Ideally, what I would like Coconut to do is support a Haskell/Hask-style type definition system that compiles to MyPy type definitions, so that the whole thing is optional and statically checkable. That's pretty much what #200 is for--it'd be great if you'd be willing to help out with that!
Eric Anderson
Nov 29 2016 19:56
Personally I'd prefer that Coconut didn't get more complex, didn't become a more esoteric language that only hardcore FP types could understand. Among the reasons that Python has such widespread appeal is that it's an easy-to-learn language for getting things done. Right now, Coconut is a language that allows-me to more easily write functional-style code while leveraging my existing knowledge of Python. It's provided me with a cleaner and more elegant way to do things that I'd already be doing in Python (lazy operations on collections, lambdas everywhere ... ). It's added useful facilities that Python lacks but that anyone who's used another language could see are missing ('what, no switch statements in Python"? "What, I have to write a 'return' statement?). While I could write recursive code in Python already, I couldn't do so in many cases without blowing the stack. Now I can. While it used to be tough to support both Py2 and Py3 users, now it's easy. Coconut is "FP-style programming for the masses", and I'd be very worried if it started going in a more theoretical/mathy direction with new and confusing syntax/semantics rather than focusing on giving the 99% a "better but still approachable Python". By way of analogy, when I got into Scala around 2011 it was a beautiful thing, a Java++ that I could be productive with on day 1. It gave me nifty, easily-understandable facilities like pattern-matching, and did so in a way that a Java dev could grok while not being scary in a way that Haskell might be. And of course Scala had the compatibility and performance story of the JVM as well. I think Coconut has/will-have the very same sort of appeal to mainstream Python devs. Since 2011 I've watched Scala get ever more complex (it used to be they bragged about how small the language def was) and difficult to get one's head around ... and believe me it was difficult to do that even in 2011, coming from a non-FP background. With Scala's conceptual (as in, new stuff I need to understand to use it) bloat and feature-creep, it doesn't surprise me that 1) people are sticking with Java 8+, which gives them FP bits that are useful to the masses like lambdas, and 2) Odersky seems to be going back to the drawing board with Dotty ... "The focus is mainly on simplification. We remove extraneous syntax ... and try to boil down Scala's types into a smaller set of more fundamental constructors. " I realize this is philosophical, and I'm not sure where you, @evhub are interested in going with the language, but my $0.02 is to keep on the path of making a better Python, not on making some kind of transpiled Haskell. And, by the way, I'm not anti-Haskell or anti-hard-core-FP, I just think that Coconut is the solution to a different problem, that of offering workaday FP-style programming to ordinary Python programmers.
Evan Hubinger
Nov 29 2016 21:15

@Nexus6 Well said--and I couldn't agree more! I think simplicity is absolutely essential in language design, if only because otherwise nobody's ever going to use the language. It is written in the Zen of Python

Simple is better than complex.
Complex is better than complicated.

and that is a philosophy I think is absolutely true. I should probably have been more explicit about what my position is on #200, since I really do agree with you here. I think adding Haskell-style type definitions as a breaking change, or in any required non-optional form, would be a really bad idea--if only just because it breaks Coconut's core guarantee that all valid Python is valid Coconut. What #200 looks to add, from my perspective, is nothing more than a better way of writing MyPy type annotations, since those can be very ugly (having to use typing.Callable, in particular, can get very frustrating), which to me exactly fits with my goal (which it seems like you share!) of making FP more approachable for everyday Python programmers.