4 ms·
You can't legislate against poor taste. Community norms help but there's always exceptions. It's interesting to consider Python which - generally - has strong
by andybak 8y ago
You can't legislate against poor taste. Community norms help but there's always exceptions.
It's interesting to consider Python which - generally - has strong community norms against excessive abstractions and too much magic.
There are some notable exceptions. I believe Twisted was regarded as "UnPythonic" and I've heard complaints about asyncio. Interestingly both are related to the same problem space.
I'm sure there are other examples of inscrutable pyramids of abstraction but Python also has many examples of good, readable abstractions.
Maybe it's not abstraction that's the problem but poor judgement? What makes one language sprout AbstractSingletonProxyFactoryBeans and another not? I'm not sure if correlates directly to "ability to create abstractions" - I think there's a human element.
- marcosdumay 8y ago> What makes one language sprout AbstractSingletonProxyFactoryBeans and another not? On this case, it's the lack or availability of alternatives. You can't take away every feature that isn't the strictest possible OOP and expect people to create expressive and simple code. Remember that those things were created by the best professionals around, and won the selection of best practices and standard open source tools. People do not write singletons in Python because it has actual static variables. Any moderately complex Python code is full of factories, but people don't even notice because they are actually just a function declaration around the same code that would be there anyway. There is a lot of "writing too the interface" that Java people do with abstract classes, but it comes nearly automatically with duck typing. And for the "bean" part people just use dictionaries. Go people seem to be taking the wrong lesson from those things.
- jacques_chester 8y ago> What makes one language sprout AbstractSingletonProxyFactoryBeans and another not? Missing features that enable higher levels of composition and abstraction. Such as, for example, generics. If you look at the usual punching bag in these discussions, Spring, you will see that as Java added features, the implementations became simpler. Java's design hypothesis was: if we take away these features, median programmers won't blow their feet off accidentally. But it turns out that to get things done you need well-above-median programmers to provide tools, APIs, frameworks, leverage and that in turn, they will need to find a way to do it. In the case of Spring that's been marked by a slow retreat from heroics into progressively simpler approaches as and when Java itself allowed for them. Spring 5, for instance, sets Java 8 as the minimum, and they went through the whole framework refactoring, cleaning up, cutting down and so on wherever that baseline allowed them to. Disclosure: I work for Pivotal, which sponsors Spring, though on unrelated software. But I've spent a lot of time with Spring folks. They are smart.