Hacker News Reader

Functional is my preferred paradigm. I do a lot of work in Python, too, and often find myself rubbing up against Python's less-than-complete support for FP. That being said, I am quite happy that Python does not have most of this stuff. It's good for a language to pick a paradigm, and stick to it. Trying to be all things to all people is the best way to grow a good language into a great big mushball.

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.

you mean has been greatly exaggerated ?

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 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 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?

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.

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.

I was trying to be gentle in saying it's wrong. Consider https://insights.stackoverflow.com/survey/2019. Python is the second most loved language on a survey where the majority of respondents have 'developer' in their title.

but he's saying a different thing.

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%.

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.

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.)

Why?

Can anything really be done by a single-threaded, GIL-laden, dynamic language trying to compete with a modern, natively parallel, JIT-ed language like Julia? That's a bit apples to oranges, no? Once other languages like Go, Swift, Kotlin, Rust and Julia catch-up with Python's range of data science libraries I'd say Python's days are numbered. Python is the Betmax of programming languages and FP is where the shallowness of its design really shows.

Natively parallel? From https://docs.julialang.org/en/v1/base/multi-threading/ : "Julia is not yet fully thread-safe. In particular segfaults seem to occur during I/O operations and task switching."

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).

I agree with you that Python lacks many useful and advanced features. But that lack of advanced features give it simplicity and because of it much more programmers than for much advanced languages. Many programmers means more packages, more tutorials and bigger community. That is why hard to beat Python, because it's downside (simplicity) give it substantial advantage over more advanced languages.

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 in.

> 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.

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.

I really want Julia to succeed and take place of Python/R/other. But Python has lots of packages and tutorials/book. You can do lots of things in Python. It will be very hard to replace it because of the need to rewrite lots of things and need to learn other language. Many people do not want to learn new language if current one provides solution for a problem that they are facing today.

> What advantages does Python have over Julia?

You can get paid to write it and there is a mature library ecosystem around it.

Why is the ecosystem important when you can just use pyjulia to call any python library you want? In regards to pay, many Python programmers aren't actually paid to program.

And regardless, I wasn't aware that getting paid to program in a language made the actual language itself better.

> Why is the ecosystem important when you can just use pyjulia

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.

[1] https://github.com/JuliaPy

[2] https://github.com/JuliaPy/Conda.jl

The main package for calling Python is PyCall [1]. It uses Conda by default but you can specify your own python location.

[1] https://github.com/JuliaPy/PyCall.jl

You will need new programmers to replace old ones if they leave your company. Now instead of knowing only Python they will need to know Julia (which at the moment is not as popular as Python) so it makes much harder to find new programmers. I really want Julia to take Place of Python/R and others but I think it will not happen in near future.

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...

[2] http://elementsofprogramming.com/

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.

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.

You can definitely implement a lot of functional concepts in Python though.

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.

>implement flatten yourself

https://more-itertools.readthedocs.io/en/stable/api.html#mor...

Python is an uninspired language with one serious design flaw (significant whitespace) that gained a lot of initial momentum because it was better than Perl. Since then it's accumulated new features in a random thrift store sort of process that has resulted in a fairly complex language.

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.

How is significant whitespace a design flaw? Have you ever seen a professionally written program in any language where care in formatting did not extend to having whitespace under control? Gofmt comes to mind. Taking this reality that everyone cares about white space and making it a first class citizen is more of a stroke of genius than a design flaw IMHO.

On the other hand, taking the reality that everyone cares about white space, it makes enforcement of whitespace irrelevant while it makes copying and pasting and auto formatting code very very annoying or even impossible in some cases.

It makes things that are trivial in other languages like copying and pasting chunks of code around or auto formatting code as you type into a very hard problem just to save some delimiters. It looks nice in code samples but sucks in real production codebases.

I am sorry I am replying so late, but seriously: you are copy-pasting code? Don't repeat yourself!

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.

I'm new to programming, and started a project recently using Python. What other languages you recommend that would be better?

I am not fan of the Python but I recommend you stick to Python for your first steps. It has very good community lots of tutorials, books, etc and lots of packages. It is in general a good language for people that are new to programming. After you master Python you may pick other language.

I'd recommend JavaScript unless you want to do something that python is specifically good for like machine learning. JavaScript has its own issues but it's not hard to learn and is used everywhere.

What brought me javascript from python was:

- functions were defined with `function` keyword instead of `def`

- variables were declared with `var`

Julia is pretty great and has significantly saner package management.

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.

> 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.

https://github.com/FluxML/Torch.jl

Julia looks more like Python than a fp language tbo and that was why I staed away. The most elegant fp code I've seen was written in Scala.

You don't look like you would enjoy Go.