Coconut: Simple, elegant, Pythonic functional programming(coconut-lang.org) |
Coconut: Simple, elegant, Pythonic functional programming(coconut-lang.org) |
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 enough that when I'm doing some ML/stats work in Python, I don't have to rip my hair at because of all the imperative stuff I'm practically forced to do.
Python still feels very much like a 90s programming language, except for maybe the async syntax. I'm not sure what exactly went wrong with the development, but the dev team needs to start shaping up or Python risks becoming completely obsolete in the next 5 or 10 years.
People might say it's hard to develop a language or whatever, but just look at Julia. Superior in every way imaginable and a much younger language. 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.
The Python dev team needs to do something drastic if they want Python to survive. They've been slowly boiled alive by conservatism and a host of missteps. I doubt they'll do anything to save Python, but I hope they at least try. Implementing some Coconut features would be a great start.
Python, for its part, is, first and foremost, a procedural imperative language. With some facilities for object-oriented and functional programming, yes, but its heart and soul are procedural. And, unless we're all ready for a backward-compatibility crisis that's even worse than 2->3, that's not changing any time soon. And that's fine. Despite it not being a paradigm that anyone has considered particularly sexy for a good 30 years now, for the problem domains where Python is most successful, procedural programming is a perfectly good way to work. Perhaps even the ideal one.
If that means that Python doesn't remain one of the world's most popular languages for the foreseeable future, that's fine. I'd honestly rather switch to a new clean language every so often than get stuck permanently on a Frankenstein's monster cobbled together from all of the most popular programming language design trends from every decade of my life. That said, I don't think that Python's existential peril is quite as great as you're making it out to be. It's got a truly impressive amount of staying power. I've spent a good two decades now watching this language repeatedly survive its own death.
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 want to learn new features or new syntaxes, they just want to keep using Python the same way they learned it once. All the people I know who swear only by Python have been using it for 5-10 years and they don't know f strings, type hints, asyncio or the walrus operator (and that doesn't stop them from doing their job, and that doesn't make them bad Python developers). Every time a new version of Python is announced, there is a bunch of comments on HN about how Python has been losing its simplicity for years.
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?
One solution for numerical code at least is to use Numba to JIT-compile (with LLVM, as Julia does) code that can be run without using the GIL, which can be run in parallel on top of Python's threading mechanisms (threading.Thread, concurrent.futures), or with Numba's other options (parallel-for, CUDA kernels, CPU or GPU vectorized Ufuncs/GUfuncs, stencil kernels).
Beyond the GIL and the lack of multi-line lambdas, Python is still a pleasant language to start new projects in.
I'm going to have to disagree with this, Python's packaging and project management is always a pain, and trying to get teammates setup previously with virtual-env/pipenv has always been rockier and slower (performance wise) than it ought to be. Julia has a much, much saner start, as does Rust.
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...
I write Python in a really functional style, and sure I had to define things like `compose` in a module but it works ok.
I find that once code starts getting higher level, you need lambdas less. Ex. You have functions or objects that generate common callbacks you can plug wherever you want.
There's also great functional libraries. Funcparserlib is amazing, and you can wrap sqlalchemy core in a functional way.
Plus there is always Hylang which works perfectly with existing Python code.
You don't have type safety but there's not much stopping you from having a good time with it! At least, in my experience. It's not Haskell though, and never will be.
https://more-itertools.readthedocs.io/en/stable/api.html#mor...
In my opinion this whole generation of slow, dynamic, single threaded languages like Python, Ruby, and PHP only became popular because they were easy to implement and more productive for simple things than the statically typed alternatives of their day. Language design has come a long way since then and we can now do much better.
What is the alternative to pytorch?
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 returns (y, [1,2,3]) here!
map(def (x) ->
y=x+1;
return y
, [1,2,3])
# Right
map((def (x) ->
y=x+1;
return y
), [1,2,3])For functional programming aficionados that still prefer python, don't forget PyToolz [2] or single-source-file underscore.py [3].
[1] https://docs.hylang.org/en/stable/
I'd argue as well, that Nim is actually what a lot of people are looking for when they look at using Go.
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.
I think it operates on the AST in python, which is also nifty.
2016 https://news.ycombinator.com/item?id=11960692
2019 https://news.ycombinator.com/item?id=18815125
and these bits from recent weeks:
The analog in the JS ecosystem would be typescript. Why isn't it just a library, because they wanted to be able to introduce new syntax and new constructs.
The little editor on the homepage shows the "compile to Python" step if you click the little checkbox. It will list the python that the coconut code gets transformed into. The code is relatively readable (for short snippets) and this is the same approach that typescript took for adding new functionality on top of an existing language.
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.)
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.
One more case of Python making good things easier and bad things harder!
Same thing with auto-formatting code as you type: IDEs are toxic you know, you would be more productive with vim.
- functions were defined with `function` keyword instead of `def`
- variables were declared with `var`
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.
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.
You can get paid to write it and there is a mature library ecosystem around it.
And regardless, I wasn't aware that getting paid to program in a language made the actual language itself better.
Now you need to package a Julia application and Python application dependencies, instead of just a Python application.
Also, pyjulia is a Julia binding for Python, used for calling Julia code from Python.
The Python bindings for Julia seem to be library specific[1], and brittle. They require an additional special snowflake layer for Python dependencies[2], bypassing PyPI entirely in favor of Conda.
This means that a lot of packages will not work, and even if they do, some will be prone to crashing and some will be out of date.
> And regardless, I wasn't aware that getting paid to program in a language made the actual language itself better.
I like Haskell, I think it is in many ways a great language. However, I'm not going to start new projects in it, nor will I recommend it to clients. It's difficult to hire for, and hard for professionals to justify adopting for reasons other than personal preferences. A big reason for that is that its ecosystem isn't as mature or diverse compared to other languages.
If there are 10 developers in the world and 5/10 use python, and at the same time there are 100 non-developers-who-code, and 9/10 use python then 95/110 people use python, and most of them are not developers.
I don't know if that is true, but you can't tell it by the SO responses because SO is more popular amongst developers anyway.
EDIT: tho you can see that python is more popular amongst non-devs than amongst devs, as "all respondents" use it at ~42% and devs use it at ~39%.