These are chat archives for evhub/coconut

Nov 2016
Eshan Singh
Nov 30 2016 13:01
Some FP programmers, including me, feel that a lot of the advantages of Haskell don't actually come in FP itself, but in its really strong type system. Hell, I still don't understand what Monads actually are, but I still find the use of the Maybe monad very useful. I don't have to complicated about it. (Still, to each their own, which is why the types are going to be optional, kind of like a gradual typing system). Even IO operations are encapsulated in the type system. I definitely agree that Python, and Coconut by extension, should be an approachable language. So this change is obviously going to be completely optional, because there's a divide in FP programmers there. I think the main appeal for me of #200 is adding a good, strong type system that's completely optional with some sort of "power user" features. I think that'll be useful for the people who want to take advantage of it as well as the multitude of awesome libraries for data science and machine learning and really everything else that are there.
Eric Anderson
Nov 30 2016 22:02
My reaction wasn't to #200 at all, which might have been confusing. I was reacting to (my interpretation of) @eshansingh 's text "It has a really good type system similar to Haskell's and a way to make real ADTs and typeclasses. I would really like for a lot of these things to be in Coconut". If you start talking about ADTs and typeclasses to Joe Python-Programmer you're going to get a blank stare and maybe a "cool" (with an implicit "I suppose, maybe, if I knew what all that was about and what it's good for re: my job..."). I speculate, but I think that even some of the current features of Coconut, such as pattern-matching and TCO and immutable data structures and lazy evaluation will require a bit of a learning curve, but they're a form of FP-bait that's not too scary and not too alien and not too big an ordeal to get one's head around, not too discouraging/daunting for an ordinary Pythonista. If you start talking about how Coconut provides "strong typing" and ADTs and typeclasses ... well ... you'll find most devs have some other work, some deadlines to meet, so ... That's 100% speculation of course. Another story: we have a smallish Python Meetup here, I attended one a few months back, maybe 20 people who work for the newspaper (Django), or who work on data pipelines or who do ops scripting. One of the guys gave a nice tutorial on generators, lazy eval, and touched a bit on coroutines. I expect that nobody in the group had ever worked with coroutines (myself included), most had probably heard of generators (possibly had not used them) and to half they were new concepts. Quite a few, maybe >50%, were still stick on Py27 due to employer mandates or library issues. I conceivably could walk into one of those meetups and do a presentation of Coconut and stand a chance that it would be understood at some level. I could describe a 1:1 mapping on the whiteboard between "how you'd do this in Python" vs "how you'd do the same thing in Coconut but more elegantly and naturally" and it would probably be understood/appreciated and I think there's a good chance that many would at least go to the website and check it out. But if I dropped words and phrases like "strong typing" (which many dislike) and "abstract data types" and "typeclasses", people would start looking away and checking their cell phones for messages and generally grin-and-bear it until the end of the talk and thereafter forget the whole thing. And remember, the Meetup folks would be the top 10% who actually cared about Python as a language ... what of the other 90% back at the office? With the very limited resources the project has, I'd hope the emphasis would be on making something the 10% could be enthusiastic about and the 90% could see some value in and even get management to buy off on if only as an experiment, assuming experimentation was in the budget. Bringing "advanced" concepts from Haskell et. al. into Coconut is going to be a deterrent to ordinary devs and will IMO require effort on the part of the @evhub and friends that could be spent elsewhere to greater effect. It also occurs to me that "adding a good, strong type system", even if optional, might be a huge task. I have zero experience in compiler or type system design and implementation, but I think there's a good reason the Scala compiler has always been so slow ... there's a lot of work it has to do. My own opinion is that Python's type hinting is a great thing, a great middle-ground that allows one to use linters (or not) without burdening the language with even optional compile-time type checking. #200 is probably a completely cool idea .. but "strong" static typing in the language and new advanced FP widgetry will be solutions in search of a problem for the above mentioned 90%.
Eric Anderson
Nov 30 2016 22:12
I'd like to add that at that meetup there was definitely some interest in FP. Kind of funny - the presenter (whose day job was mostly bash scripting) mentioned how after doing FP-style work, having to do OO style work left him feeling "dirty". I know the feeling. There are, I think, quite a lot of fish in the water, meaning FP-curious mainstream Python devs, but they need bait that looks pretty obviously yummy and not too dangerous to bite into. My experience with Coconut leads me to think that it could be that bait as long as it doesn't go off the rails by adding a lot more cognitive burden to it.