I've used it in the past but there were subtle interoperability issues with existing python libraries and I gave up.
Coconut: Simple, elegant, Pythonic functional programming
21–30 of 65 posts
Re: Coconut: Simple, elegant, Pythonic functional programming
#22This is cool stuff, but it's kind of sad that Python doesn't have any of this stuff. Apparently the Pythonic way to do anything is to repeat yourself, type a lot, implement flatten yourself, and cripple lambdas so no one will want to use them. It's a shame, because there's no reason why Python couldn't be an acceptable language for FP, like Julia. It'll never be great at it of course (just like Julia), but good enoug…
While I share your opinions, I disagree with the conclusion. I don't think Python doesn't need anything to survive. That's misunderstanding who use Python. The majority of people who use Python love Python and swear only by it. Those people are completely fine with the language not changing or not having the same features than modern languages. They use Python because of how easy it is to get the job done. They don't…
I don't have any numbers to back up what you've said, but I believe it to be true. I also believe (but have no facts to back it up) the statement I'm about to make is true: most of the people who use Python are people who would not call themselves computer programmers.
I also believe it to be true that the majority of people using any kind of technology (not just computers but all technology) like the workflow they use and are comfortable with and don't want to learn new workflows or features, so that's not usually a very good statistic to base any decisions off of.
If those are true, should Python position itself as "the non-programmer's language" or continue trying to be everything to everyone, no matter what the use case?
Re: Coconut: Simple, elegant, Pythonic functional programming
#23OMG there are multiline lambdas!!! https://coconut.readthedocs.io/en/master/DOCS.html#statement... But trying it out, it doesn't even look like python anymore. Especially if you want to nest them a lot like in other callback heavy languages. It requires a lot of semicolons and parens to get past the parsing ambiguity problem: https://stackoverflow.com/questions/1233448/no-multiline-lam... # Incorrect, the lambda retu…
[deleted]
Re: Coconut: Simple, elegant, Pythonic functional programming
#24Folks here probably already know, but any time I see functional and python in the same sentence, I like to remind folks about Hy: https://github.com/hylang/hy
I think it operates on the AST in python, which is also nifty.
Re: Coconut: Simple, elegant, Pythonic functional programming
#25OMG there are multiline lambdas!!! https://coconut.readthedocs.io/en/master/DOCS.html#statement... But trying it out, it doesn't even look like python anymore. Especially if you want to nest them a lot like in other callback heavy languages. It requires a lot of semicolons and parens to get past the parsing ambiguity problem: https://stackoverflow.com/questions/1233448/no-multiline-lam... # Incorrect, the lambda retu…
A more Coconutty way to write this might be:
[1, 2, 3] |> map$(def (x) -> y = x + 1; return y)
Re: Coconut: Simple, elegant, Pythonic functional programming
#26I liked the code examples/snippets.
I use the Hy language (hylang) when I want a Lisp syntax for Python and I also wrote a book on Hy [1] that can be read for free online.
The Python ecosystem, especially for deep learning, is awesome but some of us troublemakers don’t much like Python’s syntax.
Re: Coconut: Simple, elegant, Pythonic functional programming
#27This is cool stuff, but it's kind of sad that Python doesn't have any of this stuff. Apparently the Pythonic way to do anything is to repeat yourself, type a lot, implement flatten yourself, and cripple lambdas so no one will want to use them. It's a shame, because there's no reason why Python couldn't be an acceptable language for FP, like Julia. It'll never be great at it of course (just like Julia), but good enoug…
About FP in Python I always feel like trying and I do make use of some of the ideas, like avoiding a lot of mutation, but the lack of TCO then makes me feel "Meh … it's not so nice actually.". No TCO is in my opinion a huge bummer when trying to do FP.
I think TCO is a party trick. Recursion in FP is almost always about structure traversal. For this iterators are usually better:
1. You separate concerns of traversal and computation.
2. You can reuse a function that takes an iterator and use it on any container. In recursive functions you generally specify the next item in the structure explicitly.
3. You can edit code on functions that take an iterator without accidentally removing the TCO.
I used to believe that iterators and higher order functions were the dual of each other (each can become a 'poor man's' version of the other (cf famous scheme koan[1])). Stepanov's Elements of Programming convinced me (whether that was his goal) that iterators are superior.
[1] http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
Re: Coconut: Simple, elegant, Pythonic functional programming
#28This is cool stuff, but it's kind of sad that Python doesn't have any of this stuff. Apparently the Pythonic way to do anything is to repeat yourself, type a lot, implement flatten yourself, and cripple lambdas so no one will want to use them. It's a shame, because there's no reason why Python couldn't be an acceptable language for FP, like Julia. It'll never be great at it of course (just like Julia), but good enoug…
>implement flatten yourself
https://more-itertools.readthedocs.io/en/stable/api.html#mor...
Re: Coconut: Simple, elegant, Pythonic functional programming
#29Earlier quoted context omitted.
While I share your opinions, I disagree with the conclusion. I don't think Python doesn't need anything to survive. That's misunderstanding who use Python. The majority of people who use Python love Python and swear only by it. Those people are completely fine with the language not changing or not having the same features than modern languages. They use Python because of how easy it is to get the job done. They don't…
I don't have any numbers to back up what you've said, but I believe it to be true. I also believe (but have no facts to back it up) the statement I'm about to make is true: most of the people who use Python are people who would not call themselves computer programmers. I also believe it to be true that the majority of people using any kind of technology (not just computers but all technology) like the workflow they u…
Your second assumption is pretty problematic. While Python is popular with the non-developer crowd, it's not like it isn't itself a professionally used language. And it is used extensively. I've used it as my primary work language for 5 years now in industries from processor design, embedded systems, and now data backends. In all cases, it was the easiest to use language that did the most work. More and more work flows to it because of this.
Re: Coconut: Simple, elegant, Pythonic functional programming
#30Earlier quoted context omitted.
I don't have any numbers to back up what you've said, but I believe it to be true. I also believe (but have no facts to back it up) the statement I'm about to make is true: most of the people who use Python are people who would not call themselves computer programmers. I also believe it to be true that the majority of people using any kind of technology (not just computers but all technology) like the workflow they u…
Your second assumption is pretty problematic. While Python is popular with the non-developer crowd, it's not like it isn't itself a professionally used language. And it is used extensively . I've used it as my primary work language for 5 years now in industries from processor design, embedded systems, and now data backends. In all cases, it was the easiest to use language that did the most work. More and more work fl…
Why is it problematic? I never said or implied that Python should only be used by non-programmers, just that I believe the majority of Python users would call themselves data scientists (or just any kind of scientist I guess) or analysts or traders or accountants or researchers or any other job where writing code is not your job, you just write code to help with your actual job.
The point is, of course those people don't want to have to learn new stuff. They don't care about the code or the language, it is just a means to an end. That's why I left off on the question: should the future of Python be decided by the majority of its users, or by the people who get the deepest use out of the language?
I'm not making an argument either way, just trying to further the conversation around what features Python should get in the future.