Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

stackoverflow.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#51

Post by redthrowaway »

wldlyinaccurate wrote: post #32
mindcrime wrote: post #20

Earlier quoted context omitted.

It's an amusing story and a good cautionary tale, no doubt. But not all complex designs are over-engineering. Some problems are complex and require complex solutions. And sometimes complexity in one place is just a way of moving it from somewhere else, because somebody thought that tradeoff made their life better. See what I said below about how much I prefer JPQL and Spring Data... Personally, I really do not have a…

> Some problems are complex and require complex solutions. And yet some very complex solutions were solved with very simple languages, before Java was conceived.

Well, yes and no. I make no claims as to the validity of your arguments, but having spent the last two weeks writing a static bytecode verifier for the JVM, I'm prepared to say that it is, at minimum, more complex than I'd like it to be.

Paradoxically, this assignment has given me a great deal of respect for the idiots who conceived of the damned thing in the first place.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#52

Post by jfb »

jrochkind1 wrote: post #49
casual_slacker wrote: post #43

Earlier quoted context omitted.

The heavy emphasis on classes is what is strange about it. Many programmers don't realize the strangeness since they've used classes their entire careers. A class isn't really a procedural concept. Nothing in a processor knows what a class is. It's more of a modeling language with an assumption that you'll architect your program to group similar methods into abstract trees of domain concepts, with your data at the le…

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 'a…

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.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#53

Post by jlgreco »

casual_slacker wrote: post #43
jfb wrote: post #36

Earlier quoted context omitted.

Java is not a complicated language. Something about its affordances pushes developers into these giant labyrinthine swamps of abstraction violation, but the language isn't that complicated, either syntactically or semantically.

The heavy emphasis on classes is what is strange about it. Many programmers don't realize the strangeness since they've used classes their entire careers. A class isn't really a procedural concept. Nothing in a processor knows what a class is. It's more of a modeling language with an assumption that you'll architect your program to group similar methods into abstract trees of domain concepts, with your data at the le…

If I had to pin down Java's problem on one thing, I would say that its problem is really C.

Or more accurately, the problem is that Java was a new language shoehorned into being "like" a language that was never meant to hold the concepts that Java demands. In some cases this manifests itself in more syntactical ways; C's pragmatic but unsophisticated approach typing works well for C, but starts to become a real burden when you start adding more sophisticated concepts onto the language. (Were generics really a concept that were ever appropriate for something like C? Generics deserve a more considered treatment; a language with structure and syntax designed with them in mind.) In other cases the impact is more clear but inexplicable; "In Java Everything is an Object"(tm)... except for the things that are not.

The end result is a language that is ugly and clumsy to work with without some pretty advanced tooling, all for reasons that really have no business being real problems. Shameful (primarily cosmetic) flaws forced upon Java by the business decision: "make it reminiscent of C".

I have the same complaint about C++. Had Java and C++ not burdened themselves with the design requirement of looking like C, they would be much better languages. Languages that stray further from the mold, like Scala or Go (I am thinking particularly of their abandonment of C inspired defines, in favor of a more Pascal approach), are more pleasant to work with for it. Perhaps this damages adoption.. but that is another matter I think.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#55

Post by mpyne »

jfb wrote: post #36
wldlyinaccurate wrote: post #32

Earlier quoted context omitted.

> Some problems are complex and require complex solutions. And yet some very complex solutions were solved with very simple languages, before Java was conceived.

Java is not a complicated language. Something about its affordances pushes developers into these giant labyrinthine swamps of abstraction violation, but the language isn't that complicated, either syntactically or semantically.

As a mainly C++ developer, I agree with you 1000%

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#56

Post by prodigal_erik »

wldlyinaccurate wrote: post #32
mindcrime wrote: post #20

Earlier quoted context omitted.

It's an amusing story and a good cautionary tale, no doubt. But not all complex designs are over-engineering. Some problems are complex and require complex solutions. And sometimes complexity in one place is just a way of moving it from somewhere else, because somebody thought that tradeoff made their life better. See what I said below about how much I prefer JPQL and Spring Data... Personally, I really do not have a…

> Some problems are complex and require complex solutions. And yet some very complex solutions were solved with very simple languages, before Java was conceived.

Except they weren't solved. After fifty years of trying, the number of programs we've produced that work correctly (no bugs and certainly no "undefined behavior") is damn close to zero. So far the best any known language can do is statically rule out just a few classes of low-level mistakes.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#57

Post by jfb »

mpyne wrote: post #55
jfb wrote: post #36

Earlier quoted context omitted.

Java is not a complicated language. Something about its affordances pushes developers into these giant labyrinthine swamps of abstraction violation, but the language isn't that complicated, either syntactically or semantically.

As a mainly C++ developer, I agree with you 1000%

Exactly: C++ (or Scala, to pick a JVM example) is a complicated language. There are a lot of rules, and they interact in subtle ways, and therefore that's a real opportunity for spooky action-at-a-distance stuff.

For better or worse, Java has much simpler semantics.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#59

Post by DougWebb »

jlgreco wrote: post #53
casual_slacker wrote: post #43

Earlier quoted context omitted.

The heavy emphasis on classes is what is strange about it. Many programmers don't realize the strangeness since they've used classes their entire careers. A class isn't really a procedural concept. Nothing in a processor knows what a class is. It's more of a modeling language with an assumption that you'll architect your program to group similar methods into abstract trees of domain concepts, with your data at the le…

If I had to pin down Java's problem on one thing, I would say that its problem is really C. Or more accurately, the problem is that Java was a new language shoehorned into being "like" a language that was never meant to hold the concepts that Java demands. In some cases this manifests itself in more syntactical ways; C's pragmatic but unsophisticated approach typing works well for C, but starts to become a real burde…

I don't think I agree with your analysis. C# was originally designed to look a lot more like Java than Java ever looked like C, but it hasn't been hampered by that and has evolved to be a much more advanced language than Java has. It also doesn't have the over-engineering culture that Java has (aside from a number of "Enterprise-Class" add-on libraries Microsoft has tried to push out.)

The same could be said about Ruby and it's relationship to Perl and Python. It has cultural roots in those languages, but is often regarded to be better rather than worse. (As a die-hard Perl developer I disagree, but I don't hold a grudge.) All three are also considered to be C-like languages too, and they don't suffer the problems Java has.

One could argue that Java's problem was that it was designed for programming VCRs, DVD players, and Cable-TV boxes, and similar equipment, but the got stretched and pulled into environments it just wasn't ready for. That, plus Sun's hyper-aggressive marketing machine to turn Java into the language-for-everything, created the beast that it has become.

My personal view is that Sun turned Java into a programming language for charge-by-the-hour consultants. The culture of over-engineering exists because it takes a lot more time to design software that way, more time and larger teams to implement software that way, and specialized hard-to-transfer knowledge to maintain that kind of software. This all benefits the consultants and hurts the companies paying for the software to be built, which only makes sense if Sun was intentionally pushing Java that way.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#60

Post by philh »

veesahni wrote: post #12
shmerl wrote: post #9

Camel notation looks awful with so many words. C++ style with underscores is way more readable.

snake_case is 20% easier to read ( reference: http://bit.ly/11T1FWY )

Glancing at the first page of that study, it looks like

* People trained mostly in camelCase (also, nonprogrammers) read camelCase more accurately, but snake_case faster. (Previous study which I didn't follow up.)

* People trained mostly in snake_case read both of them equally accurately, but snake_case faster. (But, grand total of fifteen participants.)

(I find this mildly surprising: I seem to read snake_case slightly slower than normal text, and camelCase slightly faster, just based on the pauses between words. But camelCase would be easier to lose myself in. I find hyphenated-words easiest to read, but not many languages permit them...)

Post reply on HN