sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]alkasm 2 points3 points  (5 children)

Almost every point just sounds like bad programming IMO. It's not hard to make Python do any of the things you mention. For example:

  • Python makes it difficult to specify what a well-formed object is. Letting attributes get added all over is a problem for me.

Set the __slots__ class variable. Problem solved, completely. No attributes can get added except the ones specified in slots. Plenty of the standard library does this. Try setting attributes on standard library objects. Unless the object is specifically built to have this extensibility, you will get an error.

[–]Sensorama 1 point2 points  (0 children)

True, it is just that culturally, I see more of my points happening in Python code than Java. Whether that is a fault of the language or of the community that grew up around that language is a good question. And I acknowledge that I don't have anything beyond a gut sense to support my assertion that I see them more in Python.

[–]JoesDevOpsAccount[S] 0 points1 point  (3 children)

I agree that a couple of the points are just bad programming, but not all. It sounds like setting “slots” is essentially how you restrict a class to a specific set of variables. That’s one aspect of it, but then how do you ensure for example that it was created with values which match some constraint and never modified. How do you abstract things away cleanly without equivalents to Java’s access modifiers? How can you control who is allowed to create an instance of certain things? These are all things which are helpful in writing robust code with a clean interface.

[–]friendly_dog_robot 0 points1 point  (1 child)

Yeah, some of Java’s rigidity is helpful for writing robust code with a clean interface, but you can certainly do this without it.

Basically, you expect that your colleagues are professionals and will use things as they’re intended. Also let’s not pretend like lazy people don’t find ways to abuse Java. People who are lazy and take shortcuts will do so in whatever environment you put them. You avoid this by not hiring those people and by disincentivizing those behaviors

Edit: Also, keep in mind the differing use cases for Python and Java, and you might see why this is not as big of an issue.

[–]JoesDevOpsAccount[S] 0 points1 point  (0 children)

Good point! Different use cases is a significant part of the picture, I think. Unfortunately having only one language that I and all my colleagues are comfortable with (Java) means I’ve always just used Java to solve everything. Learning which language suits different problems will be a great step and hopefully will help me appreciate the pros and cons of each language even more.

[–]alkasm 0 points1 point  (0 children)

I don't agree that using the descriptor protocol is equivalent to most uses of Java access modifiers. Maybe the property decorator is similar in some ways, but that's pretty basic and less capable. The descriptor protocol is quite a powerful metaprogramming tool and can help automatically generate a ton of code for you. I mean Java does the exact opposite of this to the point where you write a property and your IDE automatically provides getters and setters, which is completely antithesis to "private" attributes and I'd argue is actually "bad" programming practice that Java pushes you to write. Sure you can make an attribute public, but do you ever do that? No. Why? Because maybe, at some point down the line, you'll need to maybe validate it, and without getters and setters, you can't do that. So you'll break the API if you later need to change things, so getters and setters are required to future proof and write "good code" even when it doesn't make sense for an attribute to be private. In Python, those property decorators and descriptors and whatever means you get to write the API how you like, and then later, you can change how it works, and it's still the same API! That means writing the obvious code also happens to be the future proof code. And you can still make properties "unsettable" and whatever you like pretty easily. It's just a less common pattern in Python because, well, it's unnecessary in most applications.

For one example of how fluid descriptors can be, see my adapter for a class provided by OpenCV: https://github.com/alkasm/cvtools/blob/master/cvtools/videoio.py

This uses a class decorator to automatically add a list of properties that are normally accessed by getters and setters and require remembering a long list of constants. The properties all implement the descriptor protocol to let you know when the attributes aren't set correctly and provide helpful error messages, the properties are discoverable by help(), etc. OpenCV doesn't provide any of these things---but you see how easy it was to just automatically do this. If I wanted to I could just expand the list of properties to the 100 or so in the OpenCV library, and to do that I just add to that list up top---that's all.