Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy(stackoverflow.com)
stackoverflow.com
Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy
http://stackoverflow.com/questions/14636178/unsure-if-i-understand-transactionawarepersistencemanagerfactoryproxy/14636231#14636231
79 comments
The problem is not the name, but the ridiculous overdesign of which it is a symptom.
At which point I bring you the story of the king's toaster [1] (which is a cautionary tale, not an aspirational story, just in case that should be unclear to anybody).
------------------------------------------------
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said.
The king asked, "How would you design an embedded computer for it?"
The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years.
With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes and waffles; pork divided into sausage, links and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes.
The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself'. The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs.
Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too.
We must not forget the user interface. The lever that lowers the food lacks versatility and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface.
When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it and the message 'Booting UNIX v. 8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook.
Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king had the computer scientist thrown in the moat, and they all lived happily ever after.
[1] http://www.ee.ryerson.ca/~elf/hack/ktoast.html
At which point I bring you the story of the king's toaster [1] (which is a cautionary tale, not an aspirational story, just in case that should be unclear to anybody).
------------------------------------------------
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said.
The king asked, "How would you design an embedded computer for it?"
The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years.
With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes and waffles; pork divided into sausage, links and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes.
The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself'. The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs.
Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too.
We must not forget the user interface. The lever that lowers the food lacks versatility and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface.
When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it and the message 'Booting UNIX v. 8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook.
Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king had the computer scientist thrown in the moat, and they all lived happily ever after.
[1] http://www.ee.ryerson.ca/~elf/hack/ktoast.html
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 problem with this.
See what I said below about how much I prefer JPQL and Spring Data... Personally, I really do not have a problem with this.
> Some problems are complex and require complex solutions.
And yet some very complex solutions were solved with very simple languages, before Java was conceived.
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.
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 leaves (instances).
So we're stuck with these complicated compile-time rules for defining everything in terms of a procedural language. We come up with complicated templates and generics for getting one set of methods to work with two types of data. Objects are needlessly serialized and deserialized to pass between systems, and programmers are needlessly spending time writing such methods.
I'm surprised that scala's paradigm of having actors work on data hasn't caught on more. When you separate them from the start, new modules are way easier to right, and integration time drops to near zero.
So we're stuck with these complicated compile-time rules for defining everything in terms of a procedural language. We come up with complicated templates and generics for getting one set of methods to work with two types of data. Objects are needlessly serialized and deserialized to pass between systems, and programmers are needlessly spending time writing such methods.
I'm surprised that scala's paradigm of having actors work on data hasn't caught on more. When you separate them from the start, new modules are way easier to right, and integration time drops to near zero.
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.
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.
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.
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.
I would say that all of those languages, while "officially" C-like (as Go is), all stray much further from C than Java or C++ (as Go has). Particularly Perl, Python, and Ruby, which are dynamically typed which singlehandedly eliminates neutralizes a great deal of "C's baggage".
I wouldn't describe C# as a language that I like, but I think it too has benifited from breaking the mold of C more than Java did (though I attribute most of it's superiority to its designers simply making better decisions in several places). Named and optional arguments stand out in my mind as ways C# did something that had no precedence in C, while Java still has not. (There is that double squiggly bracket trick, but you have to admit that is pretty shoddy).
I wouldn't describe C# as a language that I like, but I think it too has benifited from breaking the mold of C more than Java did (though I attribute most of it's superiority to its designers simply making better decisions in several places). Named and optional arguments stand out in my mind as ways C# did something that had no precedence in C, while Java still has not. (There is that double squiggly bracket trick, but you have to admit that is pretty shoddy).
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')
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')
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.
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.
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.
For better or worse, Java has much simpler semantics.
Java is one of the most complex computor languages in existence, so unless your comparing it to English I really don't see where your comming from. Don't believe me try an make a compiler some time.
PS: THE Java® SE 7 Edition of The Java Language Specification describes all the features that have been added to the Java programming language in Java SE 7. It also integrates changes made to the Java programming language under maintenance since the Third Edition in 2005. http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf. It's 670 pages long.
PS: THE Java® SE 7 Edition of The Java Language Specification describes all the features that have been added to the Java programming language in Java SE 7. It also integrates changes made to the Java programming language under maintenance since the Third Edition in 2005. http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf. It's 670 pages long.
THE Java® SE 7 Edition of The Java Language Specification [is] 670 pages long.
Unfortunately, among the major industrial programming languages, that is far from the longest specification out there. Moreover, some of the major industrial programming languages don't even have a standard reference specification. Notwithstanding its length, the Java spec is actually fairly efficient and well-organised in comparison.
Unfortunately, among the major industrial programming languages, that is far from the longest specification out there. Moreover, some of the major industrial programming languages don't even have a standard reference specification. Notwithstanding its length, the Java spec is actually fairly efficient and well-organised in comparison.
Ok, if your going to ignore 98% of all programming languages out there and focus on say the most popular 20 it's not that bad. However, there is a long tail to programming languages and some of them are actually simple, strait forward, and still useful for large progects even if not the 'Enerprise CRUD' variety.
I'm not disagreeing with your point about the long tail. I'm just saying that there are other languages that, by this metric, are significantly more complicated than Java, yet which don't get drowned under the weight of design pattern abstraction idiom pattern architectures. It seems whatever causes that effect in Java is not (only) how complicated the language is.
I think a lot of that crap is missing language features. If java 1.0 let you pass around functions at least as well as c# then many of those patterns would not have been worth talking about.
Java is not a complicated language.
Unfortunately, Java is also not a very powerful language. Many of those OO gymnastics are only relevant because the language isn't expressive enough to achieve the same results in a simpler, more direct way. Java is the language where design patterns in the Gang of Four sense first became popular, and it's often been suggested that design patterns indicate missing language features.
Unfortunately, Java is also not a very powerful language. Many of those OO gymnastics are only relevant because the language isn't expressive enough to achieve the same results in a simpler, more direct way. Java is the language where design patterns in the Gang of Four sense first became popular, and it's often been suggested that design patterns indicate missing language features.
> it's often been suggested that design patterns indicate missing language features.
Exactly right. In previous decades, had they been using modern terminology, calling conventions would no doubt be covered by plenty of "design patterns". We don't speak of calling conventions that way now because languages provide that for us.
Exactly right. In previous decades, had they been using modern terminology, calling conventions would no doubt be covered by plenty of "design patterns". We don't speak of calling conventions that way now because languages provide that for us.
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.
So far the best any known language can do is statically rule out just a few classes of low-level mistakes.
And if we actually used those languages, we would probably be seeing much lower bug rates in production software already and we could start looking into what else could be improved next. Unfortunately, most of the popular industrial languages don't even get that far. :-(
And if we actually used those languages, we would probably be seeing much lower bug rates in production software already and we could start looking into what else could be improved next. Unfortunately, most of the popular industrial languages don't even get that far. :-(
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.
Paradoxically, this assignment has given me a great deal of respect for the idiots who conceived of the damned thing in the first place.
If you decide to bump up the intensity with a strong statement or two, you'll need to be more clear on who exactly it applies to. The idiots who conceived the damned assignment? Or the ones who conceived the damned JVM?
>At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself'.
the perceived elegance of this approach makes junior CS college student eyes glow when s/he first hears about it, and that glow continues for, in the best case, at least a decade after college.
the perceived elegance of this approach makes junior CS college student eyes glow when s/he first hears about it, and that glow continues for, in the best case, at least a decade after college.
> Long names are a Good Thing as far as I'm concerned. Having spent FAR more time than I care to admit working with IBM crap that uses name like QXMGRTBL and QWRKQITM, I'll take TransactionAwarePersistanceManagerFactoryProxy any day... and twice on Sunday.
Seems like a bit of a false dichotomy. It is reasonable to expect clear and descriptive names that do not reach the level of verbosity that seems to be idiomatic in Java.
Seems like a bit of a false dichotomy. It is reasonable to expect clear and descriptive names that do not reach the level of verbosity that seems to be idiomatic in Java.
idiomatic? ( I am unfamiliar with the meaning of "idiomatic" in this context, I suspect this is programming language jargon? )
Idiomatic in this context is a synonym of "typical". It's possible to write Java with shorter class names, but they typically tend to be long.
"Up to expected standards" or "how it is generally seen" I suppose.
So for a more neutral example, CamelCaseClasses are "idiomatic" in Java, whereas classes_with_underscores are not. You could do either but the first is considered a more "correct" way to write Java, and is what you tend to see in the wild.
So for a more neutral example, CamelCaseClasses are "idiomatic" in Java, whereas classes_with_underscores are not. You could do either but the first is considered a more "correct" way to write Java, and is what you tend to see in the wild.
Maybe... personally I find most of the carping about Java class names to be hyperbole. This is one of the more extreme examples you'll find (especially in common use) and, again, if you look at what it actually does, the name is descriptive and reasonable.
As to whether or not the whole persistence mechanism is "over-engineered", well... that's a separate question. I can see some of the arguments for it, but when I look at how much easier my life is with JPQL and Spring Data and the auto-generated JPA classes, versus hand-coding raw JDBC calls and raw SQL, I'll take the former every time. And I, for one, like transactions, and the way Spring lets me annotate my Service Facade classes to manage transactions for me.
As to whether or not the whole persistence mechanism is "over-engineered", well... that's a separate question. I can see some of the arguments for it, but when I look at how much easier my life is with JPQL and Spring Data and the auto-generated JPA classes, versus hand-coding raw JDBC calls and raw SQL, I'll take the former every time. And I, for one, like transactions, and the way Spring lets me annotate my Service Facade classes to manage transactions for me.
Oh, the names are always descriptive and can be justified. You don't see things like "VeryNiceClassLoaderClassThatIMadeInJuly", it is only ever things that are justifiable.
The problem is that when you read modern code in other modern languages everything tends to be shorter, still descriptive, and still justifiable. It is something that you can't help but notice if you regularly use multiple languages.
The problem is that when you read modern code in other modern languages everything tends to be shorter, still descriptive, and still justifiable. It is something that you can't help but notice if you regularly use multiple languages.
Nothing should exist anywhere in any discipline, medium, or realm that requires that many words to name.
Also, we all have this conversation periodically about the sadness of Spring complexity. They always go the same way - https://news.ycombinator.com/item?id=4550374
Also, we all have this conversation periodically about the sadness of Spring complexity. They always go the same way - https://news.ycombinator.com/item?id=4550374
I went to Jameco and just grabbed the name of a part at random, "Phototransistor IR Chip Silicon NPN Transistor 2-Pin T-1".
I'm curious, how do you propose that part be named? I mean, sure, you can call it part #112176. That's a name with fewer words. The part number is preferable for, say, ordering from a catalog. But when actually designing a device that uses that part? Well, at some point, I need to know what it is. And what it is is a "Phototransistor IR Chip Silicon NPN Transistor 2-Pin T-1".
Sometimes in engineering you just need some really specific thing, and it makes perfect sense for a really specific thing to have a really specific name.
I'm genuinely curious: what is the argument behind your conjecture that nothing should exist that takes so many words to name? Should that phototransistor not exist?
I'm curious, how do you propose that part be named? I mean, sure, you can call it part #112176. That's a name with fewer words. The part number is preferable for, say, ordering from a catalog. But when actually designing a device that uses that part? Well, at some point, I need to know what it is. And what it is is a "Phototransistor IR Chip Silicon NPN Transistor 2-Pin T-1".
Sometimes in engineering you just need some really specific thing, and it makes perfect sense for a really specific thing to have a really specific name.
I'm genuinely curious: what is the argument behind your conjecture that nothing should exist that takes so many words to name? Should that phototransistor not exist?
Ouch. Great point. I'll make an attempt here, but understand that you have me on my heels :)
If I look around my office I see lots of things that I could name with that many words, because they're composed of a number of really important properties. The reason they're composed of all of those properties is to serve some purpose, and their name tends to reflect that purpose.
So I guess I'd ask if all of the properties in that part name reflect some holistic idea and suggest a name based on that. But I know I'm probably wrong. The people who make that part may not really know why all those properties are together.. in as much as they have customers that use it for lots of different things. It'll probably end up in things that haven't been invented yet, who knows.
Or maybe we could come up with a holistic name, but because it was unspecific we wouldn't know exactly what it did, and anyone about to purchase that part would have to read the spec-sheet (source code, to briefly exit our analogy).
Let's say we built a device that included that thing. What would we call it when traversing the schematics? We'd probably call it the phototransistor, because everything else is detailed enough to be 'source code'.
You caught me being hyperbolic, though. You're right. Some things deserve complicated names, I still definitely don't think any of those things are classes in Spring though. That shit's cray.
If I look around my office I see lots of things that I could name with that many words, because they're composed of a number of really important properties. The reason they're composed of all of those properties is to serve some purpose, and their name tends to reflect that purpose.
So I guess I'd ask if all of the properties in that part name reflect some holistic idea and suggest a name based on that. But I know I'm probably wrong. The people who make that part may not really know why all those properties are together.. in as much as they have customers that use it for lots of different things. It'll probably end up in things that haven't been invented yet, who knows.
Or maybe we could come up with a holistic name, but because it was unspecific we wouldn't know exactly what it did, and anyone about to purchase that part would have to read the spec-sheet (source code, to briefly exit our analogy).
Let's say we built a device that included that thing. What would we call it when traversing the schematics? We'd probably call it the phototransistor, because everything else is detailed enough to be 'source code'.
You caught me being hyperbolic, though. You're right. Some things deserve complicated names, I still definitely don't think any of those things are classes in Spring though. That shit's cray.
Yeah, I definitely don't think all long names are justified. I'm a huge fan of simplicity, and prefer short, simple, and direct code. With regards to Spring, especially, I do tend to agree that some of the very long class names are that way just due to incidental complexity, rather than complexity innate to the problem space itself.
"Phototransistor IR Chip Silicon NPN Transistor 2-Pin T-1" is a great name for a part that a human somewhere needs to read and understand what it's for. If that were a piece of Computer code it might be better off being named:
Silicon::Chip::Transistor::NPN::Photo::IR
and then 2-pin and T-1 might be properties on it.
The key word here might be "namespacing". Or it might be something else.
Silicon::Chip::Transistor::NPN::Photo::IR
and then 2-pin and T-1 might be properties on it.
The key word here might be "namespacing". Or it might be something else.
Personally, my ability to understand a line of code drops off quickly when it word wraps, and if it wraps twice I have to stop and massage my eyes.
That's the main problem with obscene verbosity in variable naming, at least to me.
That's the main problem with obscene verbosity in variable naming, at least to me.
mindcrime has been a victim of a ... Stockholm syndrome.
Java does not own the monopole on this one...
Ever heard of kBluetoothAMPManagerCreatePhysicalLinkResponseAMPDisconnectedPhysicalLinkRequestReceived
or
__AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_5
or
cairo_atsui_font_face_create_for_atsu_font_id_REPLACED_BY_cairo_quartz_font_face_create_for_atsu_font_id
?
Ever heard of kBluetoothAMPManagerCreatePhysicalLinkResponseAMPDisconnectedPhysicalLinkRequestReceived
or
__AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_5
or
cairo_atsui_font_face_create_for_atsu_font_id_REPLACED_BY_cairo_quartz_font_face_create_for_atsu_font_id
?
I'm not familiar with the first or the third, but the second example you cited is working as intended. No 3rd-party developer ever types this (and I don't know if anyone at all ever types this or if it's machine-generated), and the long name is meant as a form of documentation for anyone reading the header file.
Remember that Sun led by example.
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter, anyone?
http://javadoc.bugaco.com/com/sun/java/swing/plaf/nimbus/Int...
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter, anyone?
http://javadoc.bugaco.com/com/sun/java/swing/plaf/nimbus/Int...
It's an internal, automatically generated class. No programmer is ever going to use it.
That has to have been automatically generated, no?
in an internal, unfinished, maybe even experimental (see com.sun.java.* rather than java.*) bit of code that other people in the thread are saying was auto-generated.
I don't really see that class as a problem.
I don't really see that class as a problem.
Alternatively, this is why Java needs a real namespace mechanism. "package" doesn't cut it. See: namespaces in C# or C++, or alternately modules in ML.
One thing I like about DI implemented in a language itself is that is that it negates the need to make factories in all cases. So, essentially, imagine if Java had C# style namespace and this was done using Guice-style DI.
One thing I like about DI implemented in a language itself is that is that it negates the need to make factories in all cases. So, essentially, imagine if Java had C# style namespace and this was done using Guice-style DI.
bind(Persistance::Manager.class).toProvider(
new Provider<>() {
public Persistance::Manager get() {
new Persistence::Manager::TransactionAware();
}
});I've come back to Java recently via Play Framework. To my surprise, Java can be a joy to use, so long as you avoid old-school frameworks, like Spring, entirely.
I'm starting to look more at play on the side, except for the SCala stuff I keep seeing, as long as I can use it from Java and not have to deal with Scala's weird syntax then I think Play could be the new best hope (since it's not clear what Google plans to do with GWT - which rocked).
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 )
I always thought it's rather self explanatory. Reading a text without distance between the words requires more effort. Capital letters don't help much for that. Underscore gives a space between the words, which allows more fluent reading.
It might be self-explanatory, but there's a vast gulf between self-explanatory and correct.
In this case it's not only correct, it's easy to test.
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...)
* 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...)
It's just what you're used to. I'd say the opposite.
Spaces between words got added to Latin over a thousand years ago. I figure there must be a reason that change occurred.
ThisIsMyClassType
thisIsAnInstanceOfMyClass
this_is_some_ruby_or_kernel_c_i_copied_from_stack_exchange
_thisIsAFunctionParameterHavingBeenPassedIn
THISISACONSTANTDONOTCHANGE
THIS_IS_A_FRIENDLIER_ENUM
_____how_many_spaces__in_this_var
EDIT: Aaaand then there is the JS approach:
http://mathiasbynens.be/notes/javascript-identifiers
thisIsAnInstanceOfMyClass
this_is_some_ruby_or_kernel_c_i_copied_from_stack_exchange
_thisIsAFunctionParameterHavingBeenPassedIn
THISISACONSTANTDONOTCHANGE
THIS_IS_A_FRIENDLIER_ENUM
_____how_many_spaces__in_this_var
EDIT: Aaaand then there is the JS approach:
http://mathiasbynens.be/notes/javascript-identifiers
Not necessarily a "Java" problem so much as it is a Spring problem.
It's not limited to Java. We have a rule in Chromium where if your class name contains the same word twice you have to do a shot.
This is obviously trolling but I'll take a stab at actually answering the question, based on the javadoc[0]. (I have never used Spring or JDO and haven't done Java server-side programming since 2002.)
The JDO framework has an interface called PersistenceManagerFactory that is used to... well, create objects that manage persistence. Spring has its own thread-bound PersistenceManager abstraction that you need to fiddle with when you're doing transactions. This class lets you use the former's interface but decorated with the latter's behavior, so code that is designed for JDO doesn't need to be modified to call the Spring APIs explicitly.
(Am I close??)
[0] http://static.springsource.org/spring/docs/2.0.7/api/org/spr...
The JDO framework has an interface called PersistenceManagerFactory that is used to... well, create objects that manage persistence. Spring has its own thread-bound PersistenceManager abstraction that you need to fiddle with when you're doing transactions. This class lets you use the former's interface but decorated with the latter's behavior, so code that is designed for JDO doesn't need to be modified to call the Spring APIs explicitly.
(Am I close??)
[0] http://static.springsource.org/spring/docs/2.0.7/api/org/spr...
Who keeps changing the title, it was "And this, dear children, is why Java should stop taking drugs"?
Quoting part of an article as the title is not necessarily editorialization, and when the link is not actually an article, but a SO question, the original "title" may not be particularly interesting or informative.
Obviously inventing provocative titles simply to spark a flame-war is not on, but in this case the title was humorous (and interesting). The new title which is literally someones question on SO seems out of place on the front page, and not really the point of discussion.
Interesting titles can form part of the culture of a site like this, and over-zealous editing of titles damages the sense of community. It's probably the thing I dislike most about HN right now.
Quoting part of an article as the title is not necessarily editorialization, and when the link is not actually an article, but a SO question, the original "title" may not be particularly interesting or informative.
Obviously inventing provocative titles simply to spark a flame-war is not on, but in this case the title was humorous (and interesting). The new title which is literally someones question on SO seems out of place on the front page, and not really the point of discussion.
Interesting titles can form part of the culture of a site like this, and over-zealous editing of titles damages the sense of community. It's probably the thing I dislike most about HN right now.
The original title was garbage. The only thing at all it told me was that the article was somehow related to Java. I did click on it when it was the original title, and was very disappointed to see it was just a bad answer (which has at this point been deleted by the SO mods) to a stupid question.
The new title, on the other hand, tells me this is going to be about absurdly long factory classes, almost certainly using Java, and that I should probably be expecting humor rather than, say, a long article about an obscure interaction in Java that produces amusing results (which is what I had hoped I was getting with the original title).
It also happens to be the title of the linked "article" as well, which I believe is what HN says you should be using rather than editorialized titles.
The new title, on the other hand, tells me this is going to be about absurdly long factory classes, almost certainly using Java, and that I should probably be expecting humor rather than, say, a long article about an obscure interaction in Java that produces amusing results (which is what I had hoped I was getting with the original title).
It also happens to be the title of the linked "article" as well, which I believe is what HN says you should be using rather than editorialized titles.
I've always maintained that java itself is not so bad. It's the things people have done with it that make angels cry. People are the problem, not java. Leave java alone.
Languages aren't just syntax rules; they're ecosystems. And unless you want to build everything from scratch, you're going to need to use libraries and frameworks from that ecosystem, and you'll have to play by their rules. Further, you'll probably end up impedance-matching your code to those frameworks, just to make your architecture cleaner. Later, you'll seek help on some aspect of your project and most of the respondents' advice will follow the basic patterns of How Java is Written. Then you're going to hire additional programmers with lots of Java experience to help you build it, and they'll come with a bunch of notions on what the best practices are. So I'm not sure there's a practical distinction between "Java itself" and "things people have done with it". Java is people.
That's not so bad. If you haven't seen the Windows 8 API documentation yet, you should go ahead and have a laugh: http://msdn.microsoft.com/en-us/library/windows/apps/br21137...
When most of your method/class names overflow your table of contents' width, you've got a serious problem.
When most of your method/class names overflow your table of contents' width, you've got a serious problem.
The problem here isn't their class names. It's that everyone at the empire decided to go metro a few years back and made a bunch of sites like msdn a pain to use but with a nicer font and color pallet.
My guess is no one bothered to include UX in their annual commitments when they got the memo for the design change.
My guess is no one bothered to include UX in their annual commitments when they got the memo for the design change.
I don't understood the question either...
I mean, it has so much jargon on it, that what I felt is what I think my mom feels when I am talking with my dad...
I read, and re-read, and read again... And the only thing that I would think was: "omgwhy? wtf? WHY THIS EXISTS IN FIRST PLACE???"
I mean, it has so much jargon on it, that what I felt is what I think my mom feels when I am talking with my dad...
I read, and re-read, and read again... And the only thing that I would think was: "omgwhy? wtf? WHY THIS EXISTS IN FIRST PLACE???"
The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. - Joe Armstrong, inventor of Erlang.
People are so easily trolled. This looks like a generated class name in Spring.
knowing absolutely nothing about language design (and not many languages) other than occasional experiments in notepad... is there no language which attempts to allow spaces, maybe with quotes, for better legibility?
like instead of
like instead of
org.springframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy
org.'spring framework'.orm.jdo.'transaction aware persistence manager factory proxy'
I personally think that's worse. The original declaration is easier to read and immediately recognisable as to what it is, I can see clearly that it's a namespace and a class. The second version would require me to think.
In PHP you can have non-alphanumeric variables like so:
$org->{'spring framework'}->orm->jdo->{'transaction aware persistence manager factory proxy'}
use org\{'spring framework'}\orm\jdo\{'transaction aware persistence manager factory proxy'};For my money, "ObjectFactoryCreatingFactoryBean" is the most mind-blowing class name ever authored, especially when you realize it is actually useful on occasion!
And I thought C++ led to complex abstractions.
It makes me wonder if it was just accident that Java developed this way, or if it could have been an xml free, simple interface language.
It makes me wonder if it was just accident that Java developed this way, or if it could have been an xml free, simple interface language.
Reminds me of one of mine: http://stackoverflow.com/q/137060/12048
Wow. Naming really is importantant.
https://news.ycombinator.com/item?id=5944101
:)
https://news.ycombinator.com/item?id=5944101
:)
How did this post's title not get auto-modified?
I kind of preferred the original title on HN that quoted a comment:
"And this, dear children, is why Java should stop taking drugs."
"And this, dear children, is why Java should stop taking drugs."
The only bit about this that even strikes me as a little bit unreasonable is the "Proxy" bit at the end. Not sure why you need another level of Proxy on top of TransactionAwarePersistenceManagerFactory, but it's not like you type that name particularly often. Most likely it's referenced once in a Spring config file somewhere, and given a bean name of "persistenceManagerFactory" which is what would be referenced in code once at most. Hell, probably not even that... that's probably wired into another bean that just gives you the PersistenceManager... which you might not actually ever reference in code either, since Spring can auto generate JPA implementation classes that use JPQL queries, etc., and eliminate the need for most hand coding of anything JPA related.
OK, sure, just to look at it, at first blush, the name looks long and silly, but when you actually think about what it is and how it's used, it's not exactly a big deal.