One of the things I love about writing code in Go is that it's all
interfaces, no class hierarchies. So it's at least possible. The
embedding feature gets you do something similar to a class hierarchy
(picking up the method set of some other receiver), but you don't get
virtual functions (no callouts to the derived class), and you get as many
embedded objects as you like.
It's not that I really mind class hierarchies as a language feature at all.
The problem is that they're so often misused -- people use them as a way
to mentally chunk concepts, in order to handle the complexity of software.
That seems to lead to classes which're hard to understand, hard to modify
("How's this affect derived classes?"), and hard to reuse.
Packages have the same sort of problem in reverse -- in Java, the package
is an encapsulation scope, but people use them for chunking. So people
wind up having to make things public just because they need to be used from
some other particular package, not because those things are actually
intended to be used by anything else. It'd be better in these situations
to combine things into a single package, but then people think "OMG so many
files in one directory how will I ever wrap my head around it".
I'd love to see a language which explicitly embraces the notion that humans
understand things better when they're broken up into conceptual
hierarchies, without trying to use the conceptual hierarchy for method
inheritance or scoping or anything else -- it should ideally be possible to
refactor the concept hierarchy without having to rewrite any of the actual
code (other than possibly renaming things).
)Rob
On Tue, Jun 24, 2014 at 11:13 AM, Raoul Duke <[email protected]> wrote:
> * biologists all know that hierarchies are crap, but they still use
> them. maybe if somebody can invent the knowledge tools that really
> make slicing and dicing and pivot-tabling and tagging sanely and all
> that jazz really, really work then it would break the mental log jam
> for everybody in all fields. :-)
>
> * i was under the impression that typeclasses in haskell and implicits
> in scala all had some sad problems/limitations either theoretically
> and/or in terms of usability (at least for Regular Joe Programmers
> (but the kind of RJPs Who Are At Least Willing To Look For Something
> Better)). i don't know if they are inherent to the whole idea, or just
> accidentally part of those implementations. herr Wadler
> posted/published that calculus for implicits (e.g. on ltu), so there
> is hope of such warts being better understood and avoided?
>
> * probably most people have limited capacity for dealing with
> complexity. so like: i know that things such as classical hierarchies
> are pure evil in the long run, but i'm not sure i'd be able to really
> grok all the distinctions about other ways to model all the things
> e.g. the smalltalk numerics. and even if i did "get it" i fear that
> most people i have/do/will work with aren't going to care or "get it".
> there are some diamonds in the rough now and then (if i ever hit the
> lottery i have my laundry list of people i've worked with that i'd
> actually really want to hire), but probably a lot more uphill battles
> when it comes to finding and using the better/right abstractions.
>
> so if you can also come up with some rules that help guide people in a
> simple way, that can help. things like "no, really, inheritance is
> disallowed. at least if it is the kind that conflates subtyping with
> code reuse." you might not be able to do the dharma transmission of
> all the alternative better design patterns, but if people are at least
> willing to take on some rule like that then they are perhaps forced to
> reinvent those alternative design patterns. but as long as we say,
> "eschew is-a in favor of has-a" etc but at the same time allow for
> concrete inheritance (and make it seem Ok by doing things like Java's
> Observer/Observable, etc.) then it won't really stick.
>
> i'm not trying to argue against any progress here in this thread, i'm
> just thinking aloud about how we're still stuck with all this stupid
> java-style OO hierarchical junk. probably the easiest way to look at
> it is, "sun spend a buhzillion dollars on marketing and shoved java
> down everybody's throat that way and brainwashed zillions of people
> for decades to come." :-)
>
> * another take on all of this: so what if we write crappy code -- the
> question must not be 'how do we get it right in the first place?',
> since we can't do that often enough / at all, so the question must be
> 'why is it so hard to rejigger everything from lowly refactoring all
> the way through to reimplementing, redesigning, rearchitecting?' if we
> had the tools to slice and dice successfully then who cares how it was
> written, we can always fix it. a guy can dream.
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
