Earlier quoted context omitted.
Python is likely to get pattern matching in 3.10, at least: https://www.python.org/dev/peps/pep-0622/
Alas, not as an expression. Just a statement. I couldn't disagree more with that decision.
Why?
Coconut: Simple, elegant, Pythonic functional programming
31–40 of 65 posts
Re: Coconut: Simple, elegant, Pythonic functional programming
#32Earlier quoted context omitted.
Python is likely to get pattern matching in 3.10, at least: https://www.python.org/dev/peps/pep-0622/
Alas, not as an expression. Just a statement. I couldn't disagree more with that decision.
Python has a long-standing rule that you can't nest statements inside expressions. In my opinion, this is a good rule for a whitespace-sensitive language. (This is also why lambdas can only be a single expression.)
Thus, making match an expression would imply that each case must also be an expression, which would seriously restrict when you can use match.
(Lambdas already have that problem, but there it's not so bad because you can always use a named function. In this case, you would have to fall back to if/else chains.)
Re: Coconut: Simple, elegant, Pythonic functional programming
#33This 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…
I think "whitespace matters" and Python's quite uninspired way of writing procedure calls make it difficult to really innovate in the syntax area, without breaking backwards compatibility and without causing ambiguity.
Boring, unchanging syntax is a plus.
Re: Coconut: Simple, elegant, Pythonic functional programming
#34This 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…
> I've mostly switched over to Julia except for some legacy Python ML projects, and can confidently say there's no reason at all to start a new project in Python.
What is the alternative to pytorch?
Re: Coconut: Simple, elegant, Pythonic functional programming
#35Earlier quoted context omitted.
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 d…
At least as I'm interpreting it, the substance of the assumption you proposed is not problematic in the slightest. (And I also suspect, but cannot demonstrate, that you are correct.) But specific the words you used to express it bring connotations that you may or may not have intended.
There's a certain perception out there that languages that are primarily used by non-programmers are mostly useful for writing non-programs.
A lot of people who program but don't have "software developer" on their business cards may not realize it, but calling themselves non-programmers invokes certain biases about the values that they bring to the table when choosing a programming language among people who do have "software developer" on their business cards.
Re: Coconut: Simple, elegant, Pythonic functional programming
#36OMG 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…
Wow! That looks awful.
Re: Coconut: Simple, elegant, Pythonic functional programming
#37This 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…
> I've mostly switched over to Julia except for some legacy Python ML projects, and can confidently say there's no reason at all to start a new project in Python. What is the alternative to pytorch?
Just call it from Julia.
Re: Coconut: Simple, elegant, Pythonic functional programming
#38This 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.
TCO isn't really important. It's pretty rare that you ever need to use recursion in FP. the vast vast majority of the time, folds, scans, and maps should be sufficient.
Re: Coconut: Simple, elegant, Pythonic functional programming
#39Earlier quoted context omitted.
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 acci…
I'm not sure exactly what you mean by iterators, but I agree that TCO isn't that important. Like you said, most of FP is the traversal of collections. Map, scan, and foldr/foldl should be sufficient to solve the vast majority of problems.
If you find yourself reaching for TCO, it usually means that you're mission a collection combinator.
I actually find myself using TCO really only when grinding leet code problems in order to achieve n, log n, or n log n complexity. In the real world, it's rarely ever needed. And if it is, you could always use a free monad instead.
Re: Coconut: Simple, elegant, Pythonic functional programming
#40This 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…
This is quite a bit of alarmism without acknowledging somewhat recent facts. Python's parser is being updated to allow for richer grammars, the community has embraced gradual typing, and the project hasn't been very conservative for years now. The withdrawal of Guido as BDFL is quite a step in that direction. Beyond the GIL and the lack of multi-line lambdas, Python is still a pleasant language to start new projects…
I would disagree about it being pleasant, but let's ignore that. What advantages does Python have over Julia? Julia is even simpler than Python at this point, especially for researchers. A lot of non-programmers I know have been switching to Julia, as it's really easy to "write math" in it.