Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

Re:Unsure if I understand TransactionAwarePersistenceManager... by jrochkind1 on Friday June 28, 2013 @07:49PM (#5960935)

I'm not sure that's it -- ruby also has a heavy evidence on classes, but encourages entirely different sorts of solutions. Sometimes for better, occasionally for worse, but rather than argue about that, my point is just _different_ -- if emphasis on classes was what led to designs like Java, ruby would lead to em too, but it doens't, so it much be something else.

I do like the way jfb suggests using the concept of 'affordances' with languages/environments, to analyze what sorts of code they encourage. But to really do that, we'd have to actually identify these specific affordances, which i'm not sure how to either.

(And as far as your particular line of argument -- does anything in a processor know what an 'actor' is either? If not, I believe you that you find 'actor' a better abstraction than 'class', but it must not have anything to with either one being something the lower-level computer architectural abstractions 'know about')

[ Parent | on HN ]

Re:Unsure if I understand TransactionAwarePersistenceManager... by jfb on Friday June 28, 2013 @07:54PM (#5960951)

I think software as a discipline (design, implementation, analysis) has a lot to learn from more traditional areas of UI research -- by which I mean design in the Donald Norman sense. Living off in the universe of Platonic forms of e.g. patterns for organizing patterns for organizing data is fascinating, but eventually we have to pause our theorizing and start inspecting the way humans come to grips with theory.

There's a saying that one can write COBOL in any language, but nobody is born itching to POST INCREMENT C BY ONE. A given technology has a spirit; that spirit guides the usage of the technology; and people who use that technology, and share a sufficiency of that spirit, will find a welcoming home. That spirit is intrinsic to the technology; changing Java to not rely on Simula style classes for code namespacing would destroy Java -- it'd be something very different, and the usage of this new language would mean entirely new styles of conceptual organization.

I'm not taking a stance in this post on the aesthetics of the various ways to organize programs; but I do think that the forensic exercise of determining the -- I dunno, zeitgeist? -- of a technology is an interesting, rich one.

[ Parent | on HN ]