4 ms·

> 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

by 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.
- js8 9y ago
  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.

by js8 9y ago

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.

js8 9y ago
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.