15 ms·

I think Python was popular as a general-purpose language first. After all, there was a reason people put so much effort into writing Numpy in the first place.

I think Python was popular as a general-purpose language first. After all, there was a reason people put so much effort into writing Numpy in the first place. I think a lot of people were attracted to the language design, as captured in the Zen of Python (https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/), such as: Explicit is better than implicit. Readability counts. Errors should never pass silently (unless explicitly silenced) There should be one-- and preferably only one --obvious way to do it. In many cases, Ruby has almost the opposite philosophy. There's nothing wrong with that - but I think a lot of people prefer Python's choices.

Loeffelmann 3y ago
> There should be one-- and preferably only one --obvious way to do it. This is so hilariously wrong in python though
- isitmadeofglass 3y ago
  [dead]
- EdwardDiego 3y ago
  Whatever in the NamedTuples do you mean?
  - KptMarchewa 3y ago
    There is also TypedDict, Pydantic, Attrs and dataclasses
    - EdwardDiego 3y ago
      Yep, but couldn't be bothered typing them all :D
- thesuperbigfrog 3y ago
  As evidenced by the unified Python library / dependency management system.
  - shpx 3y ago
    I use pip 100% of the time
    - thesuperbigfrog 3y ago
      >> I use pip 100% of the time What about pipenv, poetry, conda, setuptools, hatch, micropipenv, PDM, pip-tools, ActiveState platform, homebrew, or your Linux / BSD distro's package manager?
      - bsder 3y ago
        As much as I love to rag on things, I would go so far as to say that the big problem with Python packaging is the fact that it tries to manage C/C++ packaging and integration. If Python is only managing Python code, the issues to be solved are VASTLY simpler. Just about anything works. Once it has to deal with dynamic libraries, compiled code, plugins, build systems, etc. the combinatorial explosion just makes life suck.
        thesuperbigfrog 3y ago
        Python is a victim of its own success and versatility. It has become a better "glue code to solve your problem" than many other solutions and so people want to use it everywhere for everything. It gets packaged in many different ways because it gets used in many different ways for many different purposes.
        bluGill 3y ago
        Packaging is a difficult problem and all attempts to simplify things fail to understand how complex the problem is and so fail in some way. (Attempts like .deb do okay by only focusing on a subset of the problem)
- kemayo 3y ago
  There's generally one obvious way to do it. There's almost certainly other ways to do it, and those other ways might be better suited for different specific tasks, but the obvious way tends to exist and be widely usable. Are there some exceptions? Sure.
  - rout39574 3y ago
    I'd suggest "pythonic", rather than obvious, for that sentence. It's one of the ways the community reminds itself of the utility of consistent discipline.
    - kemayo 3y ago
      It's perhaps worth noting that the next line of the Zen of Python is: "Although that way may not be obvious at first unless you're Dutch." (I.e. unless you're Guido.) So it was a bit of a tongue in cheek statement from the very beginning. :D
- rout39574 3y ago
  So I imagine you have that perspective because you started less than 20 years ago. In some ways the idea of the Pythonic Way to do things evolved in opposition to Perl's vigorous advocacy of More Than One Way. Python has been really winning for some time, so it's natural that its ideological discipline has grown ragged. The crop of kids who value options above consistency don't have the scars of the Perl age to inform their prejudices. But Python is -dramatically- better focused, as a community, on finding a Pythonic way to proceed, and then advocating it, than previous cultures.
  - kbenson 3y ago
    > But Python is -dramatically- better focused, as a community, on finding a Pythonic way to proceed, and then advocating it, than previous cultures. I would revise that to be that the pythonic culture of one acceptable way to to is better matched with a lot of good development practices. Perl was also very good at finding a Perl way to proceed. It's just that with Perl that often mean a lot of implicitness and "do what I mean", and multiple ways to do it so you could fit it within your preferred style and tailor it to the current project's needs. That all sounds good until you are confronted with the flip side of the coin, which is that it's harder to understand when looking at something written with those perspectives for the first time or after a long hiatus from the project, which puts a lot of importance on policy and coding standards which saps effort from just getting something done. I love Perl, and it's still the language I write most often for work, and it's no great mystery why Python became preferred.
    - gabereiser 3y ago
      Not just practices, tooling. The whole typing system. Linting to check for mistakes. For the love of black.
      - KptMarchewa 3y ago
        Python's static typing still feels very very clunky and bolted on, and tooling around it was rather bad, like mypy. In general I definitely wouldn't say python tooling was good. It's improving rapidly with ruff tho, just as JavaScript when esbuild appeared.
- jacurtis 3y ago
  That was the one mantra from the zen of python that I always laugh at too. Because my #1 complaint with python is that there are so many ways to do the same thing. It sounds nice in theory if you are a new developer because you can create your own voice in python and character. For example, lets say I gave a simple coding puzzle (think leetcode) to 10 python engineers. I would get at least 8 different responses. A few might gravitate around similar concepts but they would be significantly different. By comparison if I gave the same puzzle to some Go engineers, all of the responses would be probably very close to identical. This sounds fun as a new engineer, like this is an argument for using Python. But as you get older and more experienced you will likely find yourself hating the flexibility of python because as you scan any decent size codebases, you start to be able to identify entire parts of the codebase and who wrote them, without even needing to do a git blame. I am currently an SRE manager who works in a very polyglot environment (primarily Node/js, bash/sh, python, and Golang with just enough java thrown in to ruin your day). When I read through python codebases, I can identify exactly who wrote it, even past employees. Then when you need to fix it, you often have to adapt to that style as you fix a bug or add an updated feature. This is a little true with Bash because you will see certain engineers always lean towards sed and others towards awk and grep to solve problems depending on their strength, but it is less significant. However, in our Go codebases, everyone writes nearly identical code. I've been writing Python for over a decade and I still learn new features of the language every week or month. Just this week I had to dive into the `ast` library (abstract syntax trees) which was a native module I haven't ever touched before. By contrast, I haven't had to learn any new core syntax and tools of Go and Bash in a long time. You have a fairly small set of syntax and that's it. The power comes in how you use that small set of tools, not learning a new language module. Again, the infinite flexibility sounds nice. But in a corporate environment the strictness of other languages is actually a benefit because it keeps everyone following the same path. I truly believe the mantra from zen of python: > There should be one-- and preferably only one --obvious way to do it Sadly, Python lost this tradition far before I ever became acquainted with the language. And the python3.10+ mentality of supporting everything forever is only going to make it worse overtime.
  - lmm 3y ago
    Either you move with the times or you become obsolete. 20 years ago Python codebases were clean and consistent, but language design has moved on, and Python has - barely - kept up with it, so now you have people who know the new ways and people who know the old ways and various stages in between (and it's not like they didn't try ditching backward compatibility, but that didn't work out well either). Go has the luxury of starting 20 years later and being a lot less ambitious, but it'll happen to Go too in time.
- dragonwriter 3y ago
  IMO, its not “hilariously wrong” in Python. Note that as written the priority is that every use case has at least one obvious approach, and that a secondary priority is that there should be a unique obvious approach. People often seem, however, to misread it as “there should be only one possible way to perform any given task.” Which, yes, is hilariously false for Python, but also not what it says.
- bsder 3y ago
  You're young enough to have never dealt with write-only Perl code ... Be glad.
  - lelanthran 3y ago
    > You're young enough to have never dealt with write-only Perl code ... How young does one have to be for that to be true? As recently as 2017 I was employed at a place where there was a significant amount of perl code, as part of the build system (ugh) for the C code, and generating html (for some other system).
- imiric 3y ago
  I like Python, but most of the Zen has always been a meme, and not a guideline of design principles of either the language, or software written with it. Besides the one you mention, I also find the "Explicit is better than implicit" line to be against everything Python stands for. The language is chock full of implicit behavior, and strongly encourages writing implicit code. From the dynamically typed nature of the language itself, to being able to define dunder methods that change the behavior of comparison and arithmetic operators. I really like Go partly because of this. Not only does the language itself stictly follow the explicit over implicit and TOOWTDI principles, but it encourages or even enforces them on the programmer.
  - vonwoodson 3y ago
    It is absolutely not a meme, it's [PEP 20](https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/). Just because some people don't take it seriously, it's definitely a part of the language's soul.
    - danShumway 3y ago
      I'm from the outside looking in so don't take me too seriously because I tried Python and bounced off of it; there's very likely elegant parts of the language that I never really internalized because I didn't spend enough time working with it. But speaking as someone who tried Python because I agree with principles like "have one right way to do things" and "be explicit", my initial impression working with language is that much like real souls, Python's soul is metaphysical, unobservable, and doesn't seem to interact much with the physical world in an observable way ;) If I had to list some of my main criticisms of Python it would be that the language seems to have way too much implicit behavior and seems to have way too many ways of doing everything. I'm going to say something heretical, but it was weirdly enough early Javascript that I found to be a lot more consistent and explicit[0]. Type casting was a disaster of course, dates and the standard APIs were a complete mess, but beyond that it was rare for me to look at Javascript code and think "I have no idea what the heck that is doing." But it happened all the time in Python, it took me a while to get used to things and I still feel generally less capable in Python than I do in other languages that I've spent less time working with. There's so many little syntactic tricks in the language that are... convenient, but I resent having to memorize all of them. [0]: Until it started messing around with classes and const and Symbols and crap -- the language is probably much harder to learn now than it used to be in the past, but I don't know because I'm disconnected from new users now. But certainly having 3 ways to declare a variable now probably doesn't help new users. ---- As an example, just this weekend I tried to convert a Python codebase from 2.0 to 3.0 and was immediately hit by needing to resolve implicit casting rules about integers, buffers, and strings that were all different now. Python has this weird thing where sometimes it does implicit casting behind the scenes and sometimes it doesn't? There's probably a rule about it, but it's never been explained to me. So then I wanted to figure out the best way to handle converting a string of hex values into a manageable format so I searched that up and got advised that I should use `struct.unpack` except to be careful because that would give me a tuple instead of a list and also would require me to pass in the length, so instead I should actually use `map(ord, s)`, which prints out something that certainly seems to look like a list, but is not subscriptable, which is not a thing that I knew that I needed to care about but apparently do because the program broke until I cast it back to a list. And probably what I should have done was list comprehension from the start? But it wasn't clear to me if I could do list comprehension on a string or not since I do know that strings in Python technically aren't lists, they're sequences, and anyway list comprehension was not what people were suggesting. And I know it's unfair because this is very beginner stuff in the language, but my immediate thought was, "oh right, Python. Of course when my debugger prints out something that looks like an array of values it might be one of 3 or 4 different types behind the scenes, all of which will error for subtly different reasons. It was silly of me not to see this coming." Again, fully aware that this is basic stuff that would completely go away with familiarity with the language, but like.. oh my goodness my kingdom for having one array type that just works everywhere and one iterable quality that supports the same manipulations everywhere no matter what the underlying type is. I'm trying to do quick scripts, if I cared about these distinctions and if I cared enough about performance to need multiple ways to have a list of values, I'd have written this in Rust or at least C# or some fully typed lower-level language. There doesn't need to be this many ways in a scripting language to say "I have an ordered collection of values." I'm not saying you're wrong, I suspect you're right. I suspect the underlying language is much more elegant than what I'm seeing. All I'm saying is just that the initial impressions of Python for people like me who are really inexperienced with the language are anything but the PEP 20 list -- the impressions are the opposite, it's exactly why I bounced off of Python so hard. And I don't think that's individuals doing something weird, that seems baked into the language? Individuals didn't give Python 4 different ways to represent a sequence of values. I don't think it's a few coders' fault that I'm constantly seeing syntax in Python where having the code look prettier seems to be the priority over making it understandable or explicit? Again, take it with a grain of salt, just... I don't know, I always laugh when I see the PEP 20 linked because it's so contrary to how I think the language looks to new users. I could compare this to something like Lisp, which I am also extremely inexperienced with and extremely bad at writing, but when people talk about Lisp having simple rules, I think, "yeah, I see that. I see the system that you're talking about and I see the consistency you're talking about." With Python I just don't see it, the initial impression makes it feel like a language written by graphic designers trying to create something that's pretty rather than systemic.
- felipetrz 3y ago
  There is always one obvious way to do things in Python, but it happens that what's obvious varies from person to person.
  - fuzztester 3y ago
    Like those various personal subsets of C++ :)
- chaxor 3y ago
  Far faaaar better with respect to this than R though at least.
- nwallin 3y ago
  Yeah. It is now. It didn't used to be though. People would wax poetically about how pythonic some codebase was and sing the praises of idiomatic python. There was an ideological war between Python ("there should be one--and preferably only one--obvious way to do it") and Perl. ("there's more than one way to do it" or TIMTOWTDI, pronounced "Tim Toady") Generators and comprehensions and decorators and `functools` are all relatively new.
- harpiaharpyja 3y ago
  I feel like the entire industry has adopted Python's approach here, so probably Python doesn't stand out on this point as much as it did in the early days. Compare Python to C/C++, where even just getting a working binary from source is fraught with many competing tools. Or boost vs std and whatnot. Others have already pointed out the contrast with Perl.
- cdchn 3y ago
  Not really. For the core language this applies. This does not extend to 3rd party libraries, obviously, since anyone is free to reproduce whatever someone else already doing better, if they want.
- throwawaymaths 3y ago
  That was then. Python does much much less explicitly anymore these days, either.
- exhuma 3y ago
  This held up much better in the earlier days of Python. Sooner or later every sufficiently popular programming language is confronted with the dilemma of either breaking backwards compatibility and/or adding "alternative ways to do things" Pathlib is an interesting one. It even has a correspondence table [1]. The introduction of pathlib made sense because it is just much nicer to use. But you couldn't drop the equivalent functionality in the "os" module for backwards compatibility. It's just far too widely used. The is no magic bullet for this one. Either you accept introducing duplication in your language or you go through a hard change (f.ex. the Python 2 to 3 change). The softest way to migrate might be to flag functionality as deprecated and give users a fairly long time (talking years) before dropping it. But no matter how much time you give the users there will be users who won't change until it's too late. So there really isn't a winning path for this one. [1]: https://docs.python.org/3/library/pathlib.html#correspondence-to-tools-in-the-os-module https://docs.python.org/3/library/pathlib.html#correspondenc...
- michaelcampbell 3y ago
  I like also the idea of explicit>implicit, but then you see Django. I hate significant whitespace though. I can work with it, I get it, I still don't like it.
- sacado2 3y ago
  Back then (in 2004) the most popular programming languages were PHP, Perl, C++ and Java. Java was pretty focused (and even then, there was the distinction between int and Integer, between []int and ArrayList, etc.) but C++ and (especially) Perl were driving people crazy because there were thousands of ways to do the same thing. And nobody had any respect for PHP's design so let's not even talk about that one.
dylan604 3y ago
>I think Python was popular as a general-purpose language first. What were their choices though, Perl? It's easy to see why Perl lost out. Other than PHP, I don't really know of any other JIT scripting languages they could have chosen.
- Gualdrapo 3y ago
  I knew about Python in 2006 or so when got into Linux, and at that time (when Python 2 was a thing, iirc it just came out) it was very popular between the FOSS world for doing apps and GUIs (I even toyed a lot with PyGTK), whereas I felt Perl was much more about more "serious" stuff like text processing and kind of a sh language with steroids. I just barely heard about Ruby and wasn't sure what it was its purpose - I just heard about its "gems" but not about Rails. Still as both Python and Perl were FOSS I supposed their niche and user base were going to be around it, as many things FOSS at the time. At 2008 I started my graphic design studies and I just pretty had to forgot about programming (which in hindsight if I had kept doing it I would have a very strong programming background and maybe my life would be much better now, but it is what it is) - but was very surprised to discover around 2011 or so that it seemed _everyone_ was using Python. Like I just blinked and it took over the world somehow.
- dmarchand90 3y ago
  Perl and python have opposite philosophies with regards to standards. Python prefers a standard "pythonic" way, while perl had its "there is more than one way to do it". It would seem that having a standard is more popular.
  - dylan604 3y ago
    Yeah, there's the ongoing Perl joke about writing a script that works today, but not understanding how it works tomorrow. Too much one-liner type stuff that did not allow for maintainability
    - SoftTalker 3y ago
      That’s any code I haven’t looked at for a while, to be honest. I can’t count how many times I’ve looked at code I wrote or bug tickets I fixed and have absolutely no memory of doing it. It’s almost like the act of committing flushes the local storage in my brain.
CTmystery 3y ago
Only one of the items in your "such as" list is unique to python's philosophy, and that is "there should be one way to do it". Ruby embraces the many ways to accomplish something, it's true. However, the three others are not unique to python. Ruby especially embraces "readability counts". And I can't think of anything in the ruby language itself that is implicit over explicit. Perhaps you are thinking of rails and comparing that to python.
- ysavir 3y ago
  Ruby has implicit return values for methods, but unless I'm wrong, so does Python.
  - kstrauser 3y ago
    Python's only implicit return value is the default `None`.
    - ysavir 3y ago
      Thanks! Adding that to the things I've learned (or unforgotten, I guess is more accurate)
  - dragonwriter 3y ago
    Python has a default None return, Ruby returns the value of the last expression. Neither (except maybe the None case in Python) is really implicit, Ruby is just an expression oriented language while Python is statement-oriented. OTOH, in Ruby the keyword “return” is superfluous except for altering control flow for an early return, while in Python it is the mechanism for supplying a return value.
    - KptMarchewa 3y ago
      > Python has a default None return, Ruby returns the value of the last expression. I would really hate this feature in a language without strong static typing.
deleted 3y ago
[deleted]
KerrAvon 3y ago
No, that’s self-important bullshit. These are just evidence that Python really suffers from people in that community not using any other languages.
skeletal88 3y ago
There are just too many ways to do things in Ruby. How many forms for an if-else or for loopin can you name in Ruby? Just as the simplest example. Monkeypatching is also awful for readability. Explicit imports are way more readable than things appearing into current namespace implicit kind of stuff like it happens with Ruby
- aae42 3y ago
  I've been writing Ruby daily for years and never written a `for` loop
  - stouset 3y ago
    Started Ruby in 2007 and have used it professionally essentially nonstop. I have also never written or seen a for loop. I don’t even think I could correctly guess the syntax of it.
- BobbyJo 3y ago
  Python fixtures anyone?
- nextos 3y ago
  > There are just too many ways to do things in Ruby I think this is not completely true. Ruby is conceptually very simple. It's not C++ or Perl. Everything is an object, and everything is done through method calls. There is also extensive support for functional programming, so iteration is performed via filter/map/reduce and similar high order functions. Besides, the block/proc/lambda design makes it easy to turn APIs into DSLs. For those reasons, Ruby gives the closest experience to programming with Scheme I have ever experienced outside the Lisp world.
- twobitshifter 3y ago
  Monkeypatching exists in both ruby and Python.
  - nijave 3y ago
    It does but it's generally considered a bad practice in Python (and many other languages) and a feature in Ruby.
tshaddox 3y ago
> I think Python was popular as a general-purpose language first. That matches my memory as well. I can't find any references, but I seem to remember a quote going around way back circa 2008 that goes something like "Ruby is popular because it's the language used to write Rails; Django is popular because it's written in Python."
dragonwriter 3y ago
> I think Python was popular as a general-purpose language first What I understand is that Python was popular in the anglosphere as a general purpose language first, Ruby was somewhat popular in Japan earlier as a general purpose language but didn't become popular in the anglosphere until Rails.
- felipetrz 3y ago
  I was actually surprised when I found out they made a web framework in "the RPG Maker XP language".
treis 3y ago
I think this is it. Love Ruby as a language. Have grown to hate the way Ruby developers write stuff. Stuff ends up with so much abstraction and indirection. End up yearning for a simpler time when you could write code that just did what you needed it to.
- JohnBooty 3y ago
  I've seen that in Rails projects too. They're often way more complicated than they need to be. My rule of thumb is for a medium or large project that one probably shouldn't mess with the dynamic and meta bits of Ruby unless writing a framework and maybe not even then.
- month13 3y ago
  Delving into a gem sometimes makes me lose faith in ever using dependencies again.
- philsnow 3y ago
  100%. You can absolutely still just use off-the-shelf Ruby-the-language to get things done, without involving Rails at all, but at this point I think it would be just as weird as using awk or perl for writing a command-line program. I love tons of things about Ruby, like first-class/syntactic symbols and especially the pervasive and intuitive (in my opinion) use of blocks in the standard library.
wslh 3y ago
I remember entering in Python because you have slices and other syntax sugar stuff that makenyou think other programming languages were making you life miserable on purpose! Also, the batteries included in the standard libs was incredible when you needed to use the ACE/TAO monster in C++. Finally, interfacing with native code via SWIG enables you to quickly use critical optimized code. Obviously, other programming languages captured Python power since then.
mr_toad 3y ago
> There should be one-- and preferably only one --obvious way to do it. There’s not even one obvious flavour of Python to use.
- BobbyJo 3y ago
  It's hard for me to name a problem domain that doesn't have 3 different python packages doing the same thing three different ways, each more clever and less understandable than the last.
  - psunavy03 3y ago
    Why TF would you name an HTML parser BeautifulSoup?
    - nijave 3y ago
      I Googled it, apparently it comes from this https://en.m.wikipedia.org/wiki/Tag_soup https://en.m.wikipedia.org/wiki/Tag_soup
      - psunavy03 3y ago
        OK, I get it, but when I'm trying to write automation for a shop that isn't natively Python-savvy (long story short, it made sense when I started a side project which evolved), if I use that library and ever move on, I now have to document in comments or somewhere WTF "BeautifulSoup" means. Because of some rando's inside joke they thought was funny.
        Lammy 3y ago
        This is actually one reason I prefer the Ruby ecosystem — whimsy is still welcome. The world has enough Noun Manager projects.
        psunavy03 3y ago
mumblemumble 3y ago
Well, also, if you're going to write something like Numpy, Python is the most hospitable language for it. C extensions really are a superpower of the language. It would not be easy to achieve a similarly effective result while working through a more standard-issue foreign function interface.
sanderjd 3y ago
I've used both ruby and python extensively, and I don't actually consider them to be any different, really, on any of these points.
jbergens 3y ago
This sounds like an idea without any real data. For people to prefer one they had to try both and I guess especially data science people just took the most common language in their field. People seem to forget or miss that it took many, many years for Python to become popular outside data science. If it had just been clearly better or easier that transition should have gone much faster. As someone else mentioned, at one point universities started using Python as an introduction language. I am still sad that they did not choose Ruby or js but here we are.
bmitc 3y ago
> I think Python was popular as a general-purpose language first. Is that true? My understanding was that it was a scripting language first (still is), but then got taken up by data and science people and various other niches. Then some education books and courses, like the Artificial Intelligence: A Modern Approach and later MIT and other university adopters. And all of that began to snowball where Python was either the only or main language people knew, so they started using it for everything indiscriminately.
unlucio 3y ago
LOL yeah, while the principles listed in the Zen are good advices and practices, unfortunately most of them don't really depend on the language its self but rather on whoever writes the code and their implementation choices. Of those few that depend on the language too bad python violates pretty much all of them. Starting with the very 1st and 2nd line, where significant white spaces (one of the worst idea ever in programming, if you ask me) make block limits implicit in the indentation rather than explicit int he code with clear delimitation marks (brackets, for instance), making in return most of the source code written in it look quite ugly, and as dyslexic I can add not very accessible. Let alone the horrible experience while iterating on a piece of code: 99% of the time you're briefly stopped by and error simply because in the iteration some lines got commented out and now the damn thing throws a fit for the indentation. Not really practical in my experience. The reason why one language is more used then others at any given times it's way simpler and more bound to humans than the languages them self: - fashion trendes - laziness - sloth Most of the people out there writing code and "increasing numbers for any given language" have no real idea of why they started with one language rather then some other one, they never really dig deep enough to actually made an informed choice, and most will keep using a single programming language because they "don't feel the need to learn a new one", aka: I'm too lazy to ever go deep enough the only language I know, let alone learning a new one. And it's the market's fault: we spent the last decade or more taunting how many bagilions programmers will be needed, how anyone can get a great life by simply learning a bit how to code, etc. None gave a fuck about quality, the only goal being cheapening and cheapening the Software Developer profession, until neural networks came about and indirectly revealed the truth: we haven't being rising SW developers/engineers/etc, most of them were just Code Typist copying out of stack overflow. If something like copilot or chatGPT can substitute them, it means there wasn't much value there in the 1st place. In 2007, Jeff Atwood made the quote that was popularly referred to as Atwood's Law: “Any application that can be written in JavaScript, will eventually be written in JavaScript.”, and that's NOT a good thing, it's just the epitome of the state of the industry. In python's case it's luck was google: python (like go, for instance) is a convenient language for system automations, let's say a more sane versions of what perl was mostly used for in the past (if you notice, lots of python Zen's ideas are attempts to fix perl's insanity). Google has lots of system engineering going on, lots of people using (and abusing) python, and a single repo where everything ends up into, and when they started making neural networks with them, python got fashion for making neural networks. Anyone and their dog wanting to try out some kind of machine learning (10+ years ago) would find a tutorial in python, and tensorflow sealed the deal. Yes, numpy and pandas did have quite a bit of weight into luring the Math Community into using python, but there's nothing inherent in python that makes them possible, they could have being made in any other language. For instance haskel and lisp are way more approachable from a math stand point, they're just not in fashion any more
2-718-281-828 3y ago
> I think Python was popular as a general-purpose language first. After all, there was a reason people put so much effort into writing Numpy in the first place. what general purpose? that's just a buzz word. especially back then shipping python apps was never a viable option compared to binaries compiled from c/++ or java. there never was such a "general purpose".
barrkel 3y ago
I don't buy this at all. I think it's path dependent. The language differences aren't big enough to dominate over ecosystems and libraries. Ease of integration with C can make a bigger difference than significant whitespace. Etc. Personally I think Python is an exceptionally ugly language for one as popular as it is (the magical underscore identifiers really bug me, and I think list comprehensions are deeply inferior to monadic chaining - there's a reason nobody copies them but everyone got LINQ envy). But it's clear from a perusal of code in the areas where Python dominates, data science and machine learning, that aesthetics are very far from people's minds. They'd be using Javascript if it had the libraries available.
smitty1e 3y ago
> There should be one-- and preferably only one --obvious way to do it. It looks too late for 3.13[0] Maybe they can channel the BDFL in the Packaging[1] thread for version Pi. [0] https://docs.python.org/3.13/whatsnew/3.13.html https://docs.python.org/3.13/whatsnew/3.13.html [1] https://discuss.python.org/c/packaging/14 https://discuss.python.org/c/packaging/14
lionkor 3y ago
> Readability counts. In what way is numpy readable?
- chthonicdaemon 3y ago
  It's designed to be familiar to people who know Matlab. Matplotlib bears the same burden. Sometimes you have to start with something that's familiar to users and slowly change when you have people on board.

Loeffelmann 3y ago

> There should be one-- and preferably only one --obvious way to do it. This is so hilariously wrong in python though

isitmadeofglass 3y ago
[dead]
EdwardDiego 3y ago
Whatever in the NamedTuples do you mean?
- KptMarchewa 3y ago
  There is also TypedDict, Pydantic, Attrs and dataclasses
  - EdwardDiego 3y ago
    Yep, but couldn't be bothered typing them all :D
thesuperbigfrog 3y ago
As evidenced by the unified Python library / dependency management system.
- shpx 3y ago
  I use pip 100% of the time
  - thesuperbigfrog 3y ago
    >> I use pip 100% of the time What about pipenv, poetry, conda, setuptools, hatch, micropipenv, PDM, pip-tools, ActiveState platform, homebrew, or your Linux / BSD distro's package manager?
    - bsder 3y ago
      As much as I love to rag on things, I would go so far as to say that the big problem with Python packaging is the fact that it tries to manage C/C++ packaging and integration. If Python is only managing Python code, the issues to be solved are VASTLY simpler. Just about anything works. Once it has to deal with dynamic libraries, compiled code, plugins, build systems, etc. the combinatorial explosion just makes life suck.
      - thesuperbigfrog 3y ago
        Python is a victim of its own success and versatility. It has become a better "glue code to solve your problem" than many other solutions and so people want to use it everywhere for everything. It gets packaged in many different ways because it gets used in many different ways for many different purposes.
        bluGill 3y ago
        Packaging is a difficult problem and all attempts to simplify things fail to understand how complex the problem is and so fail in some way. (Attempts like .deb do okay by only focusing on a subset of the problem)
kemayo 3y ago
There's generally one obvious way to do it. There's almost certainly other ways to do it, and those other ways might be better suited for different specific tasks, but the obvious way tends to exist and be widely usable. Are there some exceptions? Sure.
- rout39574 3y ago
  I'd suggest "pythonic", rather than obvious, for that sentence. It's one of the ways the community reminds itself of the utility of consistent discipline.
  - kemayo 3y ago
    It's perhaps worth noting that the next line of the Zen of Python is: "Although that way may not be obvious at first unless you're Dutch." (I.e. unless you're Guido.) So it was a bit of a tongue in cheek statement from the very beginning. :D
rout39574 3y ago
So I imagine you have that perspective because you started less than 20 years ago. In some ways the idea of the Pythonic Way to do things evolved in opposition to Perl's vigorous advocacy of More Than One Way. Python has been really winning for some time, so it's natural that its ideological discipline has grown ragged. The crop of kids who value options above consistency don't have the scars of the Perl age to inform their prejudices. But Python is -dramatically- better focused, as a community, on finding a Pythonic way to proceed, and then advocating it, than previous cultures.
- kbenson 3y ago
  > But Python is -dramatically- better focused, as a community, on finding a Pythonic way to proceed, and then advocating it, than previous cultures. I would revise that to be that the pythonic culture of one acceptable way to to is better matched with a lot of good development practices. Perl was also very good at finding a Perl way to proceed. It's just that with Perl that often mean a lot of implicitness and "do what I mean", and multiple ways to do it so you could fit it within your preferred style and tailor it to the current project's needs. That all sounds good until you are confronted with the flip side of the coin, which is that it's harder to understand when looking at something written with those perspectives for the first time or after a long hiatus from the project, which puts a lot of importance on policy and coding standards which saps effort from just getting something done. I love Perl, and it's still the language I write most often for work, and it's no great mystery why Python became preferred.
  - gabereiser 3y ago
    Not just practices, tooling. The whole typing system. Linting to check for mistakes. For the love of black.
    - KptMarchewa 3y ago
      Python's static typing still feels very very clunky and bolted on, and tooling around it was rather bad, like mypy. In general I definitely wouldn't say python tooling was good. It's improving rapidly with ruff tho, just as JavaScript when esbuild appeared.
jacurtis 3y ago
That was the one mantra from the zen of python that I always laugh at too. Because my #1 complaint with python is that there are so many ways to do the same thing. It sounds nice in theory if you are a new developer because you can create your own voice in python and character. For example, lets say I gave a simple coding puzzle (think leetcode) to 10 python engineers. I would get at least 8 different responses. A few might gravitate around similar concepts but they would be significantly different. By comparison if I gave the same puzzle to some Go engineers, all of the responses would be probably very close to identical. This sounds fun as a new engineer, like this is an argument for using Python. But as you get older and more experienced you will likely find yourself hating the flexibility of python because as you scan any decent size codebases, you start to be able to identify entire parts of the codebase and who wrote them, without even needing to do a git blame. I am currently an SRE manager who works in a very polyglot environment (primarily Node/js, bash/sh, python, and Golang with just enough java thrown in to ruin your day). When I read through python codebases, I can identify exactly who wrote it, even past employees. Then when you need to fix it, you often have to adapt to that style as you fix a bug or add an updated feature. This is a little true with Bash because you will see certain engineers always lean towards sed and others towards awk and grep to solve problems depending on their strength, but it is less significant. However, in our Go codebases, everyone writes nearly identical code. I've been writing Python for over a decade and I still learn new features of the language every week or month. Just this week I had to dive into the `ast` library (abstract syntax trees) which was a native module I haven't ever touched before. By contrast, I haven't had to learn any new core syntax and tools of Go and Bash in a long time. You have a fairly small set of syntax and that's it. The power comes in how you use that small set of tools, not learning a new language module. Again, the infinite flexibility sounds nice. But in a corporate environment the strictness of other languages is actually a benefit because it keeps everyone following the same path. I truly believe the mantra from zen of python: > There should be one-- and preferably only one --obvious way to do it Sadly, Python lost this tradition far before I ever became acquainted with the language. And the python3.10+ mentality of supporting everything forever is only going to make it worse overtime.
- lmm 3y ago
  Either you move with the times or you become obsolete. 20 years ago Python codebases were clean and consistent, but language design has moved on, and Python has - barely - kept up with it, so now you have people who know the new ways and people who know the old ways and various stages in between (and it's not like they didn't try ditching backward compatibility, but that didn't work out well either). Go has the luxury of starting 20 years later and being a lot less ambitious, but it'll happen to Go too in time.
dragonwriter 3y ago
IMO, its not “hilariously wrong” in Python. Note that as written the priority is that every use case has at least one obvious approach, and that a secondary priority is that there should be a unique obvious approach. People often seem, however, to misread it as “there should be only one possible way to perform any given task.” Which, yes, is hilariously false for Python, but also not what it says.
bsder 3y ago
You're young enough to have never dealt with write-only Perl code ... Be glad.
- lelanthran 3y ago
  > You're young enough to have never dealt with write-only Perl code ... How young does one have to be for that to be true? As recently as 2017 I was employed at a place where there was a significant amount of perl code, as part of the build system (ugh) for the C code, and generating html (for some other system).
imiric 3y ago
I like Python, but most of the Zen has always been a meme, and not a guideline of design principles of either the language, or software written with it. Besides the one you mention, I also find the "Explicit is better than implicit" line to be against everything Python stands for. The language is chock full of implicit behavior, and strongly encourages writing implicit code. From the dynamically typed nature of the language itself, to being able to define dunder methods that change the behavior of comparison and arithmetic operators. I really like Go partly because of this. Not only does the language itself stictly follow the explicit over implicit and TOOWTDI principles, but it encourages or even enforces them on the programmer.
- vonwoodson 3y ago
  It is absolutely not a meme, it's [PEP 20](https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/). Just because some people don't take it seriously, it's definitely a part of the language's soul.
  - danShumway 3y ago
    I'm from the outside looking in so don't take me too seriously because I tried Python and bounced off of it; there's very likely elegant parts of the language that I never really internalized because I didn't spend enough time working with it. But speaking as someone who tried Python because I agree with principles like "have one right way to do things" and "be explicit", my initial impression working with language is that much like real souls, Python's soul is metaphysical, unobservable, and doesn't seem to interact much with the physical world in an observable way ;) If I had to list some of my main criticisms of Python it would be that the language seems to have way too much implicit behavior and seems to have way too many ways of doing everything. I'm going to say something heretical, but it was weirdly enough early Javascript that I found to be a lot more consistent and explicit[0]. Type casting was a disaster of course, dates and the standard APIs were a complete mess, but beyond that it was rare for me to look at Javascript code and think "I have no idea what the heck that is doing." But it happened all the time in Python, it took me a while to get used to things and I still feel generally less capable in Python than I do in other languages that I've spent less time working with. There's so many little syntactic tricks in the language that are... convenient, but I resent having to memorize all of them. [0]: Until it started messing around with classes and const and Symbols and crap -- the language is probably much harder to learn now than it used to be in the past, but I don't know because I'm disconnected from new users now. But certainly having 3 ways to declare a variable now probably doesn't help new users. ---- As an example, just this weekend I tried to convert a Python codebase from 2.0 to 3.0 and was immediately hit by needing to resolve implicit casting rules about integers, buffers, and strings that were all different now. Python has this weird thing where sometimes it does implicit casting behind the scenes and sometimes it doesn't? There's probably a rule about it, but it's never been explained to me. So then I wanted to figure out the best way to handle converting a string of hex values into a manageable format so I searched that up and got advised that I should use `struct.unpack` except to be careful because that would give me a tuple instead of a list and also would require me to pass in the length, so instead I should actually use `map(ord, s)`, which prints out something that certainly seems to look like a list, but is not subscriptable, which is not a thing that I knew that I needed to care about but apparently do because the program broke until I cast it back to a list. And probably what I should have done was list comprehension from the start? But it wasn't clear to me if I could do list comprehension on a string or not since I do know that strings in Python technically aren't lists, they're sequences, and anyway list comprehension was not what people were suggesting. And I know it's unfair because this is very beginner stuff in the language, but my immediate thought was, "oh right, Python. Of course when my debugger prints out something that looks like an array of values it might be one of 3 or 4 different types behind the scenes, all of which will error for subtly different reasons. It was silly of me not to see this coming." Again, fully aware that this is basic stuff that would completely go away with familiarity with the language, but like.. oh my goodness my kingdom for having one array type that just works everywhere and one iterable quality that supports the same manipulations everywhere no matter what the underlying type is. I'm trying to do quick scripts, if I cared about these distinctions and if I cared enough about performance to need multiple ways to have a list of values, I'd have written this in Rust or at least C# or some fully typed lower-level language. There doesn't need to be this many ways in a scripting language to say "I have an ordered collection of values." I'm not saying you're wrong, I suspect you're right. I suspect the underlying language is much more elegant than what I'm seeing. All I'm saying is just that the initial impressions of Python for people like me who are really inexperienced with the language are anything but the PEP 20 list -- the impressions are the opposite, it's exactly why I bounced off of Python so hard. And I don't think that's individuals doing something weird, that seems baked into the language? Individuals didn't give Python 4 different ways to represent a sequence of values. I don't think it's a few coders' fault that I'm constantly seeing syntax in Python where having the code look prettier seems to be the priority over making it understandable or explicit? Again, take it with a grain of salt, just... I don't know, I always laugh when I see the PEP 20 linked because it's so contrary to how I think the language looks to new users. I could compare this to something like Lisp, which I am also extremely inexperienced with and extremely bad at writing, but when people talk about Lisp having simple rules, I think, "yeah, I see that. I see the system that you're talking about and I see the consistency you're talking about." With Python I just don't see it, the initial impression makes it feel like a language written by graphic designers trying to create something that's pretty rather than systemic.
felipetrz 3y ago
There is always one obvious way to do things in Python, but it happens that what's obvious varies from person to person.
- fuzztester 3y ago
  Like those various personal subsets of C++ :)
chaxor 3y ago
Far faaaar better with respect to this than R though at least.
nwallin 3y ago
Yeah. It is now. It didn't used to be though. People would wax poetically about how pythonic some codebase was and sing the praises of idiomatic python. There was an ideological war between Python ("there should be one--and preferably only one--obvious way to do it") and Perl. ("there's more than one way to do it" or TIMTOWTDI, pronounced "Tim Toady") Generators and comprehensions and decorators and `functools` are all relatively new.
harpiaharpyja 3y ago
I feel like the entire industry has adopted Python's approach here, so probably Python doesn't stand out on this point as much as it did in the early days. Compare Python to C/C++, where even just getting a working binary from source is fraught with many competing tools. Or boost vs std and whatnot. Others have already pointed out the contrast with Perl.
cdchn 3y ago
Not really. For the core language this applies. This does not extend to 3rd party libraries, obviously, since anyone is free to reproduce whatever someone else already doing better, if they want.
throwawaymaths 3y ago
That was then. Python does much much less explicitly anymore these days, either.
exhuma 3y ago
This held up much better in the earlier days of Python. Sooner or later every sufficiently popular programming language is confronted with the dilemma of either breaking backwards compatibility and/or adding "alternative ways to do things" Pathlib is an interesting one. It even has a correspondence table [1]. The introduction of pathlib made sense because it is just much nicer to use. But you couldn't drop the equivalent functionality in the "os" module for backwards compatibility. It's just far too widely used. The is no magic bullet for this one. Either you accept introducing duplication in your language or you go through a hard change (f.ex. the Python 2 to 3 change). The softest way to migrate might be to flag functionality as deprecated and give users a fairly long time (talking years) before dropping it. But no matter how much time you give the users there will be users who won't change until it's too late. So there really isn't a winning path for this one. [1]: https://docs.python.org/3/library/pathlib.html#correspondence-to-tools-in-the-os-module https://docs.python.org/3/library/pathlib.html#correspondenc...
michaelcampbell 3y ago
I like also the idea of explicit>implicit, but then you see Django. I hate significant whitespace though. I can work with it, I get it, I still don't like it.
sacado2 3y ago
Back then (in 2004) the most popular programming languages were PHP, Perl, C++ and Java. Java was pretty focused (and even then, there was the distinction between int and Integer, between []int and ArrayList, etc.) but C++ and (especially) Perl were driving people crazy because there were thousands of ways to do the same thing. And nobody had any respect for PHP's design so let's not even talk about that one.

dylan604 3y ago

>I think Python was popular as a general-purpose language first. What were their choices though, Perl? It's easy to see why Perl lost out. Other than PHP, I don't really know of any other JIT scripting languages they could have chosen.

Gualdrapo 3y ago
I knew about Python in 2006 or so when got into Linux, and at that time (when Python 2 was a thing, iirc it just came out) it was very popular between the FOSS world for doing apps and GUIs (I even toyed a lot with PyGTK), whereas I felt Perl was much more about more "serious" stuff like text processing and kind of a sh language with steroids. I just barely heard about Ruby and wasn't sure what it was its purpose - I just heard about its "gems" but not about Rails. Still as both Python and Perl were FOSS I supposed their niche and user base were going to be around it, as many things FOSS at the time. At 2008 I started my graphic design studies and I just pretty had to forgot about programming (which in hindsight if I had kept doing it I would have a very strong programming background and maybe my life would be much better now, but it is what it is) - but was very surprised to discover around 2011 or so that it seemed _everyone_ was using Python. Like I just blinked and it took over the world somehow.
dmarchand90 3y ago
Perl and python have opposite philosophies with regards to standards. Python prefers a standard "pythonic" way, while perl had its "there is more than one way to do it". It would seem that having a standard is more popular.
- dylan604 3y ago
  Yeah, there's the ongoing Perl joke about writing a script that works today, but not understanding how it works tomorrow. Too much one-liner type stuff that did not allow for maintainability
  - SoftTalker 3y ago
    That’s any code I haven’t looked at for a while, to be honest. I can’t count how many times I’ve looked at code I wrote or bug tickets I fixed and have absolutely no memory of doing it. It’s almost like the act of committing flushes the local storage in my brain.

CTmystery 3y ago

Only one of the items in your "such as" list is unique to python's philosophy, and that is "there should be one way to do it". Ruby embraces the many ways to accomplish something, it's true. However, the three others are not unique to python. Ruby especially embraces "readability counts". And I can't think of anything in the ruby language itself that is implicit over explicit. Perhaps you are thinking of rails and comparing that to python.

ysavir 3y ago
Ruby has implicit return values for methods, but unless I'm wrong, so does Python.
- kstrauser 3y ago
  Python's only implicit return value is the default `None`.
  - ysavir 3y ago
    Thanks! Adding that to the things I've learned (or unforgotten, I guess is more accurate)
- dragonwriter 3y ago
  Python has a default None return, Ruby returns the value of the last expression. Neither (except maybe the None case in Python) is really implicit, Ruby is just an expression oriented language while Python is statement-oriented. OTOH, in Ruby the keyword “return” is superfluous except for altering control flow for an early return, while in Python it is the mechanism for supplying a return value.
  - KptMarchewa 3y ago
    > Python has a default None return, Ruby returns the value of the last expression. I would really hate this feature in a language without strong static typing.

deleted 3y ago

[deleted]

KerrAvon 3y ago

No, that’s self-important bullshit. These are just evidence that Python really suffers from people in that community not using any other languages.

skeletal88 3y ago

There are just too many ways to do things in Ruby. How many forms for an if-else or for loopin can you name in Ruby? Just as the simplest example. Monkeypatching is also awful for readability. Explicit imports are way more readable than things appearing into current namespace implicit kind of stuff like it happens with Ruby

aae42 3y ago
I've been writing Ruby daily for years and never written a `for` loop
- stouset 3y ago
  Started Ruby in 2007 and have used it professionally essentially nonstop. I have also never written or seen a for loop. I don’t even think I could correctly guess the syntax of it.
BobbyJo 3y ago
Python fixtures anyone?
nextos 3y ago
> There are just too many ways to do things in Ruby I think this is not completely true. Ruby is conceptually very simple. It's not C++ or Perl. Everything is an object, and everything is done through method calls. There is also extensive support for functional programming, so iteration is performed via filter/map/reduce and similar high order functions. Besides, the block/proc/lambda design makes it easy to turn APIs into DSLs. For those reasons, Ruby gives the closest experience to programming with Scheme I have ever experienced outside the Lisp world.
twobitshifter 3y ago
Monkeypatching exists in both ruby and Python.
- nijave 3y ago
  It does but it's generally considered a bad practice in Python (and many other languages) and a feature in Ruby.

tshaddox 3y ago

> I think Python was popular as a general-purpose language first. That matches my memory as well. I can't find any references, but I seem to remember a quote going around way back circa 2008 that goes something like "Ruby is popular because it's the language used to write Rails; Django is popular because it's written in Python."

dragonwriter 3y ago

> I think Python was popular as a general-purpose language first What I understand is that Python was popular in the anglosphere as a general purpose language first, Ruby was somewhat popular in Japan earlier as a general purpose language but didn't become popular in the anglosphere until Rails.

felipetrz 3y ago
I was actually surprised when I found out they made a web framework in "the RPG Maker XP language".

treis 3y ago

I think this is it. Love Ruby as a language. Have grown to hate the way Ruby developers write stuff. Stuff ends up with so much abstraction and indirection. End up yearning for a simpler time when you could write code that just did what you needed it to.

JohnBooty 3y ago
I've seen that in Rails projects too. They're often way more complicated than they need to be. My rule of thumb is for a medium or large project that one probably shouldn't mess with the dynamic and meta bits of Ruby unless writing a framework and maybe not even then.
month13 3y ago
Delving into a gem sometimes makes me lose faith in ever using dependencies again.
philsnow 3y ago
100%. You can absolutely still just use off-the-shelf Ruby-the-language to get things done, without involving Rails at all, but at this point I think it would be just as weird as using awk or perl for writing a command-line program. I love tons of things about Ruby, like first-class/syntactic symbols and especially the pervasive and intuitive (in my opinion) use of blocks in the standard library.

wslh 3y ago

I remember entering in Python because you have slices and other syntax sugar stuff that makenyou think other programming languages were making you life miserable on purpose! Also, the batteries included in the standard libs was incredible when you needed to use the ACE/TAO monster in C++. Finally, interfacing with native code via SWIG enables you to quickly use critical optimized code. Obviously, other programming languages captured Python power since then.

mr_toad 3y ago

> There should be one-- and preferably only one --obvious way to do it. There’s not even one obvious flavour of Python to use.

BobbyJo 3y ago
It's hard for me to name a problem domain that doesn't have 3 different python packages doing the same thing three different ways, each more clever and less understandable than the last.
- psunavy03 3y ago
  Why TF would you name an HTML parser BeautifulSoup?
  - nijave 3y ago
    I Googled it, apparently it comes from this https://en.m.wikipedia.org/wiki/Tag_soup https://en.m.wikipedia.org/wiki/Tag_soup
    - psunavy03 3y ago
      OK, I get it, but when I'm trying to write automation for a shop that isn't natively Python-savvy (long story short, it made sense when I started a side project which evolved), if I use that library and ever move on, I now have to document in comments or somewhere WTF "BeautifulSoup" means. Because of some rando's inside joke they thought was funny.
      - Lammy 3y ago
        This is actually one reason I prefer the Ruby ecosystem — whimsy is still welcome. The world has enough Noun Manager projects.
        psunavy03 3y ago

mumblemumble 3y ago

Well, also, if you're going to write something like Numpy, Python is the most hospitable language for it. C extensions really are a superpower of the language. It would not be easy to achieve a similarly effective result while working through a more standard-issue foreign function interface.

sanderjd 3y ago

I've used both ruby and python extensively, and I don't actually consider them to be any different, really, on any of these points.

jbergens 3y ago

This sounds like an idea without any real data. For people to prefer one they had to try both and I guess especially data science people just took the most common language in their field. People seem to forget or miss that it took many, many years for Python to become popular outside data science. If it had just been clearly better or easier that transition should have gone much faster. As someone else mentioned, at one point universities started using Python as an introduction language. I am still sad that they did not choose Ruby or js but here we are.

bmitc 3y ago

> I think Python was popular as a general-purpose language first. Is that true? My understanding was that it was a scripting language first (still is), but then got taken up by data and science people and various other niches. Then some education books and courses, like the Artificial Intelligence: A Modern Approach and later MIT and other university adopters. And all of that began to snowball where Python was either the only or main language people knew, so they started using it for everything indiscriminately.

unlucio 3y ago

LOL yeah, while the principles listed in the Zen are good advices and practices, unfortunately most of them don't really depend on the language its self but rather on whoever writes the code and their implementation choices. Of those few that depend on the language too bad python violates pretty much all of them. Starting with the very 1st and 2nd line, where significant white spaces (one of the worst idea ever in programming, if you ask me) make block limits implicit in the indentation rather than explicit int he code with clear delimitation marks (brackets, for instance), making in return most of the source code written in it look quite ugly, and as dyslexic I can add not very accessible. Let alone the horrible experience while iterating on a piece of code: 99% of the time you're briefly stopped by and error simply because in the iteration some lines got commented out and now the damn thing throws a fit for the indentation. Not really practical in my experience. The reason why one language is more used then others at any given times it's way simpler and more bound to humans than the languages them self: - fashion trendes - laziness - sloth Most of the people out there writing code and "increasing numbers for any given language" have no real idea of why they started with one language rather then some other one, they never really dig deep enough to actually made an informed choice, and most will keep using a single programming language because they "don't feel the need to learn a new one", aka: I'm too lazy to ever go deep enough the only language I know, let alone learning a new one. And it's the market's fault: we spent the last decade or more taunting how many bagilions programmers will be needed, how anyone can get a great life by simply learning a bit how to code, etc. None gave a fuck about quality, the only goal being cheapening and cheapening the Software Developer profession, until neural networks came about and indirectly revealed the truth: we haven't being rising SW developers/engineers/etc, most of them were just Code Typist copying out of stack overflow. If something like copilot or chatGPT can substitute them, it means there wasn't much value there in the 1st place. In 2007, Jeff Atwood made the quote that was popularly referred to as Atwood's Law: “Any application that can be written in JavaScript, will eventually be written in JavaScript.”, and that's NOT a good thing, it's just the epitome of the state of the industry. In python's case it's luck was google: python (like go, for instance) is a convenient language for system automations, let's say a more sane versions of what perl was mostly used for in the past (if you notice, lots of python Zen's ideas are attempts to fix perl's insanity). Google has lots of system engineering going on, lots of people using (and abusing) python, and a single repo where everything ends up into, and when they started making neural networks with them, python got fashion for making neural networks. Anyone and their dog wanting to try out some kind of machine learning (10+ years ago) would find a tutorial in python, and tensorflow sealed the deal. Yes, numpy and pandas did have quite a bit of weight into luring the Math Community into using python, but there's nothing inherent in python that makes them possible, they could have being made in any other language. For instance haskel and lisp are way more approachable from a math stand point, they're just not in fashion any more

2-718-281-828 3y ago

> I think Python was popular as a general-purpose language first. After all, there was a reason people put so much effort into writing Numpy in the first place. what general purpose? that's just a buzz word. especially back then shipping python apps was never a viable option compared to binaries compiled from c/++ or java. there never was such a "general purpose".

barrkel 3y ago

I don't buy this at all. I think it's path dependent. The language differences aren't big enough to dominate over ecosystems and libraries. Ease of integration with C can make a bigger difference than significant whitespace. Etc. Personally I think Python is an exceptionally ugly language for one as popular as it is (the magical underscore identifiers really bug me, and I think list comprehensions are deeply inferior to monadic chaining - there's a reason nobody copies them but everyone got LINQ envy). But it's clear from a perusal of code in the areas where Python dominates, data science and machine learning, that aesthetics are very far from people's minds. They'd be using Javascript if it had the libraries available.

smitty1e 3y ago

> There should be one-- and preferably only one --obvious way to do it. It looks too late for 3.13[0] Maybe they can channel the BDFL in the Packaging[1] thread for version Pi. [0] https://docs.python.org/3.13/whatsnew/3.13.html https://docs.python.org/3.13/whatsnew/3.13.html [1] https://discuss.python.org/c/packaging/14 https://discuss.python.org/c/packaging/14

lionkor 3y ago

> Readability counts. In what way is numpy readable?

chthonicdaemon 3y ago
It's designed to be familiar to people who know Matlab. Matplotlib bears the same burden. Sometimes you have to start with something that's familiar to users and slowly change when you have people on board.