5 ms·

This 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 l

• zelphirkalt 6y ago
  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.
  • laretluval 6y ago
    Boring, unchanging syntax is a plus.
• mumblemumble 6y ago
  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.
  • julienfr112 6y ago
    you mean has been greatly exaggerated ?
• zelphirkalt 6y ago
  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.
  • fnord123 6y ago
    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/msg03277.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m... [2] http://elementsofprogramming.com/ http://elementsofprogramming.com/
    • smabie 6y ago
      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.
  • smabie 6y ago
    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.
• duckerude 6y ago
  Python is likely to get pattern matching in 3.10, at least: https://www.python.org/dev/peps/pep-0622/ https://www.python.org/dev/peps/pep-0622/
  • silviogutierrez 6y ago
    Alas, not as an expression. Just a statement. I couldn't disagree more with that decision.
    • fermienrico 6y ago
      Why?
    • marvy 6y ago
      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.)
• ggregoire 6y ago
  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.
  • freehunter 6y ago
    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?
    • musingsole 6y ago
      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.
• cutler 6y ago
  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.
  • vasili111 6y ago
    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.
  • helgie 6y ago
    Natively parallel? From https://docs.julialang.org/en/v1/base/multi-threading/ 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).
• heavyset_go 6y ago
  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.
  • smabie 6y ago
    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.
    • heavyset_go 6y ago
      > What advantages does Python have over Julia? You can get paid to write it and there is a mature library ecosystem around it.
      • smabie 6y ago
        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.
        • vasili111 6y ago
          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.
        • 6y ago
• madelyn 6y ago
  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.
• fnord123 6y ago
  >implement flatten yourself https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.collapse https://more-itertools.readthedocs.io/en/stable/api.html#mor...
• canjobear 6y ago
  > 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?
  • smabie 6y ago
    Just call it from Julia.
  • aberdysh 6y ago
    https://github.com/FluxML/Torch.jl https://github.com/FluxML/Torch.jl
• cageface 6y ago
  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.
  • gverrilla 6y ago
    I'm new to programming, and started a project recently using Python. What other languages you recommend that would be better?
    • FridgeSeal 6y ago
      Julia is pretty great and has significantly saner package management.
    • vasili111 6y ago
      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.
    • cageface 6y ago
      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.
      • itsjzt 6y ago
        What brought me javascript from python was: - functions were defined with `function` keyword instead of `def` - variables were declared with `var`
• tastyminerals 6y ago
  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.
• tucnak 6y ago
  You don't look like you would enjoy Go.