Live data from Hacker News

Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

stackoverflow.com

71–80 of 80 posts

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#71
post #64
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.

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…

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.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#72
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.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#73

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.

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.

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?

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#74

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. 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 Trans…

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

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?

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#75
post #64

Earlier quoted context omitted.

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…

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.

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.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#76
post #75

Earlier quoted context omitted.

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.

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.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#77

Earlier quoted context omitted.

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

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 i…

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.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#78

Earlier quoted context omitted.

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 i…

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…

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.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#79
post #75

Earlier quoted context omitted.

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.

Re: Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy

#80

Earlier quoted context omitted.

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

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 i…

"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.

Post reply on HN