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.