5 ms·

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

by jack9 9y ago

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.

moron4hire 9y ago
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.
- sametmax 9y ago
  Depends of the system. Google/Dropbox/Instagram/Facebook/Mozilla use cases are not most people use cases. (Plus they do use Python anyway)
  - cwyers 9y ago
    Gudio has worked for Google and Dropbox.
  - moron4hire 9y ago
    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.
js8 9y ago
> 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.
- pyrale 9y ago
  You still have encapsulation interests, as a matter of namespacing or interface building, in functional languages.
  - js8 9y ago
    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.
- yen223 9y ago
  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#collections.somenamedtuple._make 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.
adrianN 9y ago
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.
emodendroket 9y ago
> 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.
wvenable 9y ago
> 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.
- zephyrfalcon 9y ago
  """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.
  - wvenable 9y ago
    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.
    - pseudalopex 9y ago
      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?
      - wvenable 9y ago
        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.

by jack9 9y ago

moron4hire 9y ago

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.

sametmax 9y ago
Depends of the system. Google/Dropbox/Instagram/Facebook/Mozilla use cases are not most people use cases. (Plus they do use Python anyway)
- cwyers 9y ago
  Gudio has worked for Google and Dropbox.
- moron4hire 9y ago
  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.

js8 9y ago

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

pyrale 9y ago
You still have encapsulation interests, as a matter of namespacing or interface building, in functional languages.
- js8 9y ago
  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.
yen223 9y ago
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#collections.somenamedtuple._make 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.

adrianN 9y ago

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.

emodendroket 9y ago

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

wvenable 9y ago

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

zephyrfalcon 9y ago
"""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.
- wvenable 9y ago
  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.
  - pseudalopex 9y ago
    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?
    - wvenable 9y ago
      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.