Comment by jack9 | Hacker News Reader

Comment by jack9 | Hacker News Reader

The first couple points ("encapsulation", specifically no private vars) and interface conflicts are not issues worth complaining about.

More importantly, we have 0 evidence that using private/protected in software is better than not. People like to use them because, as the author notes later in the Type System comments:

"Refactoring. If I’ve got a type system and I’m faced with needing to clean things up, I can put stuff behind an interface and follow the type errors to find everything that needs updating. Often in dynamic languages, even with a decent test suite, extensive changes can be really difficult."

You shouldn't have a workflow of fix failures blindly and private variables contribute to that style of over-reliance on language features instead of actual attention to detail.

That being said, the world isn't perfect and it's common to take this approach if you have a lot of strong language safety features and are under time pressure (who isn't). In my experience, this situation means things are being rushed and/or the developer is burned out to give up such fine grained control over the code.

Are you saying that renaming a method must not be done automatically, but instead you have you grep for the name and figure out yourself whether its the method you want or not? That sounds strange.

Automatic refactoring is essential if you want to avoid adding layers and layers of development sediment to your codebase, imho.

Systems are too large to understand the consequences of our changes. We should be using as many automated tools for figuring out how to make change as possible. "Reasoning about code" only works for academic scale programming.

Depends of the system.

Google/Dropbox/Instagram/Facebook/Mozilla use cases are not most people use cases.

(Plus they do use Python anyway)

Gudio has worked for Google and Dropbox.

No, I'm talking much smaller. Unless all your job is to glue services other people write, the number of things you really need to know to understand a full, non-trivial system are too much for any one person. The only reason any of this works is because we can compartmentalize and choose to ignore whole chunks.

> You shouldn't have a workflow of fix failures blindly and private variables contribute to that style of over-reliance on language features instead of actual attention to detail.

If the project is large enough who knows every place some class is used? Even if you do it in what you claim is the "right" way, the compiler provides a sanity check on your work.

> More importantly, we have 0 evidence that using private/protected in software is better than not.

I think his point, and it's a valid one, is that Python has practically re-invented private members with special underscore handling anyway -- just more half-assed.

We may have zero evidence that private/protected makes software better but programmers, even in languages with no native support for it, seem to out of their way to do it anyway. Perhaps there is something to it afterall.

"""I think his point, and it's a valid one, is that Python has practically re-invented private members with special underscore handling anyway -- just more half-assed."""

It was added more as a kind of "stop gap" for people who complained about the lack of private/protected attributes. That's why it is indeed half-assed. :) And that's also why hardly anybody uses it, especially the double underscore thing.

Ultimately I think the underscore itself is a hack. The need for protected/private members is so great that people will do it by convention anyway if the feature doesn't exist.

If Python developers were truly serious about everything being public there would be no underscored members.

The Python developers' position is that protected/private modifiers are really just convention too. Someone who wants to access a private member in Java can use reflection. We can't stop them, so why pretend?

By definition protected/private modifiers aren't convention as they're part of the language itself.

Convention is something that doesn't exist in the language. You cannot mark properties as private or protected in Python so the convention is that underscore means private or protected. There are no getters or setters in Java so the convention is to use a method with a get/set prefix.

I would argue that such a common programming practice (enforced or not) should not be left to convention.

> More importantly, we have 0 evidence that using private/protected in software is better than not.

I would go further. I think encapsulation (data hiding) is a concept that is slowly being obsoleted by functional programming style, having "naked" (structurally visible to all programs) immutable data types. One of the promises of encapsulation is breaking global state into smaller pieces, but the approach where you avoid state entirely is superior to that.

You still have encapsulation interests, as a matter of namespacing or interface building, in functional languages.

These are different things for a different purpose. Data encapsulation, as defined in OOP, is obsolete, I think.

Namespacing is related to modular programming, which is still useful even in functional programs (it makes sense to group related data and functions together for organizational purposes). Interfaces serve a different purpose yet, to do a dispatch based on type.

Immutable data types are a great idea, but man are Python's implementation of them so bad. Tuples are okay for really simple structures, but the lack of attribute access makes them a little clunky to use.

Fortunately, Python has namedtuples right? Holy shit is it such a pain in the ass to use. The way to declare namedtuples are some of the ugliest code I've seen anywhere, not just in Python.

  Point = namedtuple('Point', ['x', 'y'])

Taking a list of strings to define attributes? Having to write the class name twice? Oh and as an extra fuck you to good coding style, a namedtuple instance has underscored methods that are intentionally meant for public use - https://docs.python.org/3/library/collections.html#collectio...

Fortunately 3.5 introduced the NamedTuple class that sort of fixed everything right? Of course I'm talking about `typing.NamedTuple` class, not `collections.named_tuple` - clearly two different things and definitely not confusing at all. Well, here's how you use that:

  Employee = typing.NamedTuple('Employee', [('name', str), ('id', int)])

Just shoot me now.

3.6 fixed that, but I'm too tired to care anymore. I feel so frustrated just thinking about some of Python's recent daft design decisions. Hugely disappointing considering Python used to be rightfully lauded for having good style.

Sure, Python is not a very functional language and will never be. I liked Python a lot in the past, and still use it as quick tool, because I know it well and its simplicity for practical usage is hard to beat, but the future of SW development is something more like Haskell, in my view.

What I meant was that the author complains that Python does encapsulation badly, because it doesn't have private/public. But that itself is, IMHO, an obsolete view which ignores functional programming.

Reply on news.ycombinator.com