Live data from Hacker News

Ask HN: Why did Python win?

news.ycombinator.com

501–510 of 856 posts

Re: Ask HN: Why did Python win?

#501

Earlier quoted context omitted.

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/ ), such as: Explicit is better than implicit. Readability counts. Errors should never pass silently (unless explicitly silenced)…

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

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

Re: Ask HN: Why did Python win?

#502

Earlier quoted context omitted.

Dumb question: I know the built-in typing (import typing) is limited in some ways, but it works pretty fine to cover most basic needs. So what does mypy add? I'm super interested in adding typing to some code we have but I'm just a bit confused by the choices available. Would mypy with pydantic be a good combination or do they overlap?

The two are complementary: the built-in `typing` module only provides type annotations , not type checking . Mypy provides the latter, via the type annotations that you (and others) add to Python codebases. Pydantic overlaps with mypy in the sense that it provides a mypy plugin, but otherwise it's just like any other Python library.

So mypy runs "at run time"? I guess that makes sense, I thought the annotations provided some form of checking too, but now I realize that I should really spend some time to inform myself better :').

Re: Ask HN: Why did Python win?

#503
post #134

Python manages to have decent performance because NumPy uses an APL-like model and it happens to skirt the design flaws (dynamic typing, interpreted). J for instance has a tree-walking interpreter written in C that performs well! Ruby's poor performance hobbles it even in places it's supposed to be good (twitter was rewritten to Scala over rails).

Ruby 3.2.2 is slightly faster than Python 3.11 in quite a few benchmarks. I don't know what data you used to conclude that Python is faster than Ruby unless you're comparing something like Numpy and a Ruby lib which isn't exactly Apples to Apples.

The original question is "why python won". That in 2023 Ruby is 1% faster than Python is irrelevant. Historically, Python has always been faster than Ruby. That certainly didn't help Ruby gain ground over Python.

Re: Ask HN: Why did Python win?

#504
post #378

Earlier quoted context omitted.

Can you explain more about how (you feel) Python is a step backwards? I'm curious if the "steps backward" are syntax level? I feel the Ruby community is very syntax oriented. As evidence of this: I see Ruby developers interested in Elixir and Crystal, languages that are syntactically similar, but technically very different. I do not see Ruby developers interested in Python, even though, if we ignore syntax, Python an…

I really wanted to love Python. As a Ruby programmer I thought Python would be like Ruby, but with a prettier syntax because of the syntactic white space. Unfortunately this turned out not to be the case. Here's my gripes with Python as a Ruby developer that really wanted to love Python: There's a bunch of global functions that should have been methods on objects, like `len()`. OO in general seems slapped on later, a…

> There's a bunch of global functions that should have been methods on objects, like `len()`. OO in general seems slapped on later, as evidenced by the weird double underscores, and the explicit this object as first arguments for methods.

From some angles these are strange, but from where I sit they seem elegant and pragmatic.

The global functions and double underscore methods are part of the same thing: the language defining and enforcing a protocol that many types of objects should support. Other languages do this by having common names (.length() or whatever), but this has problems that the python way avoids:

- it's hard to add new ones because they share the same namespace as user code - they may have different meanings in different contexts (e.g. a line has a length, but isn't iterable) - the language can't enforce the protocol (e.g. len accepts only one argument, checks the result is an integer, and raises the correct exceptions)

For operator overloading, using regular methods with special names is nice because it avoids having special syntax for it, and makes it easier to interactively inspect and experiment with (as you can just call the methods).

The explicit self thing is similar, in that it avoids a load of special syntax: no this keyword, no syntax for static methods, no syntax for superclass calls (until super was added). It even means that there's only really one 'kind' of call.

I can see some confusion about where self actually comes from, but then most languages i've experienced where this is implicit also have corner-cases and awkwardness around it.

IMO these kind of simplifications seem a bit frivolous when looked at in isolation, but end up simplifying your mental model of the language, which helps beginners get more out of it quicker.

> It's nice that function definitions are closures but you can't make them anonymously as function arguments.

I thought this for a while, and it would still be nice in a few situations, but really it's not a burden to name your callbacks, and discouraging overly-clever code isn't a bad thing if you're trying to build an ecosystem that's accessible to as many people as possible. I used to use map/reduce/filter a lot, but most of the time list comprehensions and regular loops end up easier to read.

Re: Ask HN: Why did Python win?

#505

Earlier quoted context omitted.

Before Python got popular, Perl was the most similar popular language. Once I encountered Python, I felt, this is Perl, but done right.

That was my experience. I like Perl. I'm comfortable with Perl. And after about a day of Python, I never wrote another line of new Perl code. There were so many "it can't possibly be that easy, but it is!" moments. Let's write a function to add five to a number: def add_five(num): return num + 5 OK. So, can I pass that function as an argument to another function? def call(func, value): return func(value) call(add_fiv…

Python didn't corner the market there:

  (define (add-five num)
      (+ num 5))
  (define (call func value)
      (func value))
  (call add-five 10)
Admittedly, this was one-of-many examples.

I do wonder how much would be different today if not for the Monty Python gags in the documents.

Re: Ask HN: Why did Python win?

#506
post #31

I first encountered Python around 2000. At the time Perl was more popular in the circles I frequented, and TCL probably about as popular as Python (eggdrop[1] notwitstanding), but Python was growing steadily. I encountered Ruby in the late '00s (as others have noted it made its english-language debut almost a decade after Python started) and Lua was another contender during this time. My memory is that, at least outs…

Before Python got popular, Perl was the most similar popular language. Once I encountered Python, I felt, this is Perl, but done right.

As someone who began his programming career with Perl I've never understood this idea that Python somehow improved on Perl. For a start Ruby is Perl5's most obvious successor. Perl puts Python's text-handling to shame whilst Python's lambda is nowhere near as expressive as Perl's. Python also goes head-to-head with Perl's fundamental philosophy - TIMTOWTDI. If anything Python is the Anti-Perl.

Re: Ask HN: Why did Python win?

#507

Python is only a titan if you include data science. In the web dev world it's dwarfed by Ruby and Node. Some possible reasons are: casual programmers learn python faster, "numpy" is fun to say out loud, and uh, can't think of any more.

There is much more web development going on in Python and Django over Rails.

Re: Ask HN: Why did Python win?

#508
post #505

Earlier quoted context omitted.

That was my experience. I like Perl. I'm comfortable with Perl. And after about a day of Python, I never wrote another line of new Perl code. There were so many "it can't possibly be that easy, but it is!" moments. Let's write a function to add five to a number: def add_five(num): return num + 5 OK. So, can I pass that function as an argument to another function? def call(func, value): return func(value) call(add_fiv…

Python didn't corner the market there: (define (add-five num) (+ num 5)) (define (call func value) (func value)) (call add-five 10) Admittedly, this was one-of-many examples. I do wonder how much would be different today if not for the Monty Python gags in the documents.

Sigh. I know. We are truly walking in the darkness.

When I’m appointed Lord Emperor, we’ll all upgrade back to Lisp.

Re: Ask HN: Why did Python win?

#509

Earlier quoted context omitted.

The two are complementary: the built-in `typing` module only provides type annotations , not type checking . Mypy provides the latter, via the type annotations that you (and others) add to Python codebases. Pydantic overlaps with mypy in the sense that it provides a mypy plugin, but otherwise it's just like any other Python library.

So mypy runs "at run time"? I guess that makes sense, I thought the annotations provided some form of checking too, but now I realize that I should really spend some time to inform myself better :').

No, it's more that pydantic runs "at run time" while mypy not.

Re: Ask HN: Why did Python win?

#510

Earlier quoted context omitted.

The two are complementary: the built-in `typing` module only provides type annotations , not type checking . Mypy provides the latter, via the type annotations that you (and others) add to Python codebases. Pydantic overlaps with mypy in the sense that it provides a mypy plugin, but otherwise it's just like any other Python library.

So mypy runs "at run time"? I guess that makes sense, I thought the annotations provided some form of checking too, but now I realize that I should really spend some time to inform myself better :').

Sort of -- mypy is its own standalone program, and you run it to typecheck your program's type annotations. It does some evaluation of the Python program (specifically imports and some very basic conditional evaluation, among other things), but it never really executes the codebase itself.
Post reply on HN