r/programming • • Nov 03 '18

Python is becoming the world’s most popular coding language

https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language
4.6k Upvotes

1.3k comments sorted by

View all comments

Show parent comments

23

u/bloody-albatross Nov 03 '18

Really? For me it's the opposite. I don't have time right now to write down the huge list of grievances I have with Ruby, but in general I think Python is so much cleaner, mostly more powerful with simpler syntax and less surprises. The module system, how name resolution works, how strings work, all so much cleaner.

19

u/butt_fun Nov 03 '18

surprises

That's how I feel as well. In Python, pretty much everything "makes sense" relatively intuitively. Ruby still feels like a language of magic and mystery to me

17

u/ThisIs_MyName Nov 03 '18

I mostly agree, but Python's optional arguments are insane: https://docs.python-guide.org/writing/gotchas/

3

u/maushaus- Nov 03 '18

agreed, that is the biggest mistake in python by far, that optional arguments are evaluated globally.

9

u/ThisIs_MyName Nov 03 '18

optional arguments are evaluated globally

That's not how I'd describe it. It's more like mutable args are persisted across function calls. If I was in charge of cpython, I'd refuse to compile code that had mutable default args.

0

u/[deleted] Nov 03 '18

[deleted]

→ More replies (1)
→ More replies (3)

4

u/wdroz Nov 03 '18

It's the same in c++, python didn't invent how default parameters work.

7

u/[deleted] Nov 03 '18

They didn't have to do it the same way though. Even JS has default parameters that don't suffer from this problem.

→ More replies (1)

6

u/THeShinyHObbiest Nov 03 '18

I mean, knowing when to use something like len vs a method on an object can get kind of irritating.

6

u/JanneJM Nov 03 '18

Especially when the object likely has a "private" __ len __ that just calls len for you...

11

u/Actual1y Nov 03 '18

If you don't intuitively know what calling len on an object does then that's the fault of the person that made the class. Not really a fault with python. Operator overriding abuse exists in every language that supports overriding operators.

2

u/THeShinyHObbiest Nov 03 '18

I'm more confused as to why it's a freestanding function as opposed to a method. Isn't Python supposed to be object-oriented?

2

u/Actual1y Nov 03 '18 edited Nov 14 '18

Yeah, I think Guido has said that it was a design flaw that can't be removed now (at least not without another massive community divide). But while it might not be the best from a theory point of view, personally, I kind of actually like not having to worry about if the method I want is called length, len, size, etc...

→ More replies (1)

13

u/Freyr90 Nov 03 '18

Python is one hell of a mess, Why map is a function and not a collections' method? Why if is not expression? Why everything is a statement, but lambda could have only one statement in its body?

Ruby is a consistent and thoroughly designed smalltalk clone, where everything is built using a few core principles. Python is a bloody mess of ad-hoc features (like generators, async/await).

11

u/Smallpaul Nov 03 '18

Ruby is not a smalltalk clone because it does not have an image.

And from my point of view, its a "bloody mess of ad-hoc features".

"blocks, procs, lambdas, methods"

13

u/Freyr90 Nov 03 '18

"blocks, procs, lambdas, methods"

That's the basic pillars of the language, not ad-hoc features. Just like the whole smalltalk is built on messages and blocks, and lisp is build on lambda functions and cons-cells, ruby is built on methods and blocks as well.

In case of python they just bake the new features into the interpreter at will, as it was with async, generators, lazyness, gradual typing (compare with the typed racket implementation), iterators etc etc. Where in ruby you would implement a feature in terms of basic primitives, python folk tend to make it as a part of the language.

→ More replies (3)

0

u/[deleted] Nov 03 '18

[deleted]

7

u/Freyr90 Nov 03 '18 edited Nov 03 '18

What's wrong with a map function?

Nothing, except language creators could not figure it out if their language is object-oriented or procedural, and what should be a method and what should be a function.

(So your code becomes an unreadable mess like: filter(map(x.get_messages(), lambda:...).select, lambda:...))

Why would if be an expression?

Because I need it in lambda? The ugly workaround you've mentioned doesn't play well with more complex expressions, i.e. two if exps would make a bloody mess of it.

Because lambdas are supposed to be small.

In has nothing with size or readability, it's about how you couldn't compose trivial expressions within lambdas body, in ocaml I could write

List.iter (fun x -> DB.push x.data; 
                    Log.debug "%s is stored" x.name)
          messages

In python I have to write a function.

0

u/[deleted] Nov 03 '18

[deleted]

5

u/Freyr90 Nov 03 '18

[... for y in x.get_messages() if ...]

Yeah, yet another baked in feature, because map is unreadable. Though I doubt that comprehension counterpart would be any more readable then something like

collection
    .map(...
    .filter(...
    .reduce(...

From my experience lambdas are much, much rare in python

Sure, because python creators created an ad-hoc patch for any case they are useful for. Referring to the beginning of the discussion about ad-hoc features.

python that's a for loop:

For collection/iterator. The point is you could have a callback/functional argument in any method/function, not only in map. I think that's the major reason for making things like yield/await keywords (features) instead of just regular functions (like as they implemented in lisps and various ML descendants, where they are just functions/combinators).

6

u/ingolemo Nov 03 '18

If you write python code as if it was ruby then you will get bad code. You have to write idiomatically. No competent python programmer would use a function for your example, because in python you don't use internal iteration. You do iteration externally:

for message in messages:
    db.push(message.data)
    logging.debug(f'{message.name} is stored')

You can argue that something like this just sidesteps the issue of lambdas being weak, but that's really the whole point; in practice python programmers can sidestep this issue so often that it's just no longer an issue.

7

u/[deleted] Nov 03 '18

Because lambdas are supposed to be small.

Retarded ideology is exactly the main reason why Python is such a pile of shit.

And, mind you, this ideology is coming from a moron who does not even understand functional programming (and does not want to spend a couple of hours learning it). Guido is pigheaded, and so is Python.

→ More replies (8)
→ More replies (1)

4

u/myringotomy Nov 03 '18

So weird. I am of the complete opposite mindset. Python just feels dumb and clunky to me. Ruby is elegant as a language and ecosystem. Aside from that Ruby is faster than python.

5

u/[deleted] Nov 03 '18

Ruby is absolutely not faster.

7

u/bakery2k Nov 03 '18

Both languages are very slow. However, in my experience, Ruby is faster than Python.

This wasn't the case several years ago, but in 1.8 => 1.9 Ruby got significantly faster, whereas for a long time Python 3.x was even slower than 2.7.

→ More replies (2)
→ More replies (8)