Beppu commented, "I sense that you like Java on some level, but I'm not sure why. It seems to stand for everything you stand against."
Here's why I like Java.
* Applets -- I wanted to write stupid little Web games. Same for Midlets; I want to write stupid little Web games for phones.
* C sucks for application development -- Java is a more tolerable alternative to the extremely tedious C approach to writing applications (C's power and speed are nice for writing language interpreters, kernels, database engines, TCP/IP stacks, etc). It's almost impossible to get security alone in C right. Any attempt is a massive undertaking that's ultimately doomed to repeated failures. Java's standard library is better too.
* Strong typing -- I've worked on large projects and I know the value of a good typing system. Of course, ML and Haskell have an even better one. Yes, it can get in the way in Java, but it's just one of those things where a little more work has to go into the code when you're on a large project to avoid much, much more work later on. The vast majority of people whining about the undesirability of a strong typing system are just zealots who are trying to prop up their favorite language which just happens to lack the feature -- the "my language doesn't have it and it works just fine so therefore I/it doesn't need it". The PHP weenies use this flawed argument all the time. I frequently post on this topic, so I'll keep this one short. Go read somewhere else if you want to know exactly what a good type system buys you.
* Java is a static language -- it has the advantage that static languages have: it can easily be compiled down to machine code for really fast apps, such as by gcj. This isn't to say that I like static languages better than dynamic ones, or that I like Java better than Perl because Perl isn't static. That would be dumb. But staticness can be useful sometimes, and when I want it, I consider Java. With Chicken of Scheme and good optimizing compilers for functional languages, this becomes more and more moot each year.
* Perl people hate Java -- I guess it's like handling a poisonous snake -- your fear and revolution is my delight. Java needs to be looked at as just another of God's creatures, not some threat or demonic manifestation, or else we can't relate it to in a healthy, Perl-ish way, and do what we Perl people do: steal all of the best ideas from it and leave the soulless corpse to be devoured by worms. Muahahahaah!!
-scott
When I think of scrottie code, these are the characteristics that come to mind:
When I think of Java code, I think it's:
That's why I find it unusual that someone like you would find reasons to like Java. But if you like it, whatever.
Re:What is scrottie code?
scrottie on 2007-07-27T09:12:26
"I know that you don't actually code in it that much.;-)"
That's key. I can take lots of stuff in small doses, and enjoy it. Just not PHP.
When writing Java, I used to use kaffe and jikes. Both are pretty small, and both are open source and support my old, slow hardware. jikes is extremely fast. kaffe only does 1.1ish or 1.2ish, but at the time you had to program down to that version anyway to support MS's fuxored Java version they distributed with IE. And then compared to Flash, which was barely programmable at all in its first version, everything was a lot more transparent and exposed.
Having a nice large standard class library to play with isn't as much fun as having an expressive language, but it is fun to play with and is rewarding.
And I am kind of an OO snob. Java suits that side of me. It's not the least bit out of place to worry about which classes can see which other classes and what kind of interfaces they're presenting for each other. Boring for most Perl programmers perhaps but most Perl programmers would do well to spend some time ignoring the language itself and just concentrate on design. Spending time in the Java camp is a great way to do that. I enjoy making interfaces, virtual classes, inner classes, and so on and so forth.
Also unlikely PHP, the Java world is large, with lots of culture (even if it isn't my beloved culture of mad scientists) and goings ons.
-scottRe:What is scrottie code?
Aristotle on 2007-07-27T10:43:49
It’s not the least bit out of place to worry about which classes can see which other classes and what kind of interfaces they’re presenting for each other.
Yah.
Re:What is scrottie code?
scrottie on 2007-07-27T20:06:17
No, actually... I intentionally avoided discussion of private, protected, public etc because of this essay. I said "interfaces" and "which classes can see each other", which is in reference not to hiding bits of themselves but simply who has references to who and what the basic topology of the application is. You can hardly invoke the "stay out of my livingroom not because I have a shotgun" argument to justify writing a God Object. Sometimes strong typing makes sense; aside from that, large projects need some design skills.
Interfaces are a way of keeping straight, either in your own head or with the help of the language, which objects, as a cross-section of classes of objects, are going to define certain methods. Get this wrong and the program explodes. Don't put thought into it, and just as bad, assume you were born when a gift from God at sorting these things out when charges are strongly in favor of the opposite, and you'll have a mess that no one wants to touch.
"Who can see who" refers to the Law of Demeter. It seriously negates any befenits to OO if every object in a system is intimate with every other one.
It makes me sick to be associated with a language where I have to defend such simple things... just as sick as it might make you to try to explain to a Java zealot how hashes are really useful and when they're built in to the language, you wind up using them all the time for all kinds of stuff.
-scott
Re:What is scrottie code?
Aristotle on 2007-07-28T00:32:00
You can hardly invoke the “stay out of my livingroom not because I have a shotgun” argument to justify writing a God Object.
But you don’t need mandatory controls if you’re writing a God object either. You won’t understand the need for them until you try to do good OO design, just like a ten-liner can be written without strictures too. Access controls are just another aspect of the sort of design you are talking about.
It makes me sick to be associated with a language where I have to defend such simple things…
As you might have gathered from that post, I’m equally sick of the “no infatuation with enforced privacy” chestnut, which is congruent with the lack of understanding of good OO design that you were complaining about.
Re:What is scrottie code?
scrottie on 2007-07-28T01:18:52
Quick recap.
1. I argued that Perl programmers could benefit from some time spent on OO design, and give thought to things like interfaces and which objects can see which other objects.
2. You object on the grounds that Perl doesn't need forced encapsulation.
3. I clarify that at no point in that point did I argue for forced encapsulation (though I did at another point, but at that point, I was talking about something else). I restate that, ignoring enforced encapsulation, Perl programmers don't do nearly as much reading on or thinking about design and they could benefit from more.
4. You retort that this isn't so, because Perl doesn't need forced encapsulation.
5. I recap [this post], wondering what the fuck.
Beyond a certain point (my clarification), you're just being stupid on purpose so you can keep arguing your conclusion and ignoring the logic that might get you there for the benefit of any wayward readers who can't be bothered to follow along but enjoy the conclusions as if they're proof of something. Trying to avoid you co-opting my blog for the purposes of stupidity turns into a time sink for me from which I cannot help to benefit.
Twit. Get out of my blog. Don't read it, don't post in it. Just go away. And change your nick, too. And if you ever come back here, I'm posting "A Thoughtful Essay on Why Aristotle [sic] is a Great Big Poopy Head".
If I'm going to waste my time clarifying repeatedly for those who who make effort _not_ to understand, let's make it personal.
-scott
-scott
Draft: Why Aristotle [sic] is a Great Big Poopy H
scrottie on 2007-07-28T01:36:11
Every now and then, I post a disclaimer on my blog, saying that I will be extremely mean to anyone who doesn't follow the house rules. I know I can't impose them, but I can be quite mean. So, please don't do certain things on my blog. But first I ask people to go away. Aristotle [sic] made it to this point and continued on, all the while acting oblivious.
This isn't a discussion of whether Perl programmers could benefit from learning more about OO design as it was traditionally taught in the late 80's and early 90's. We (meaning this particular reader) seems to have skipped that point and fixed himself on whether Java is doing anything right or better, concluded that that would be impossible and that life wouldn't be worth living if that's the case, and decided that, by extension, the related comment must be faulty.
There are a few easy things to do in this case. You see them on blog comments all the time. Those who will stop at no length to perpetuate fallicies repeat them endlessly.
I already mentioned starting with the conclusion and deeming the argument (in the traditional sense) invalid based on the conclusion (I don't agree with your conclusion so your logic *must* be wrong!, or, the answer couldn't possibily be three! Check the equation again!).
Another of them is silently translating one argument into an invalid one. If I reference something related to OO and Java, it must also be invalid, just like the "Perl doesn't need forced encapsulation" idea. Even if I made it clear from the onset that I wasn't referencing forced encapsulation in any way. Even if I come back and reiterate in a clarification.
Another approach these weenies use is just steadfastly continuing on in their invalid argument even as their fallicies are pointed out.
To repeat from my rules for posting in my blog, there are correct (yes, logic is a field of study -- "Aristotle" should know that) ways to argue. You can challenge the premises. If a premise turns out to be false, the conclusion is meaningless. The other way is to point out logical errors. Again, logic has been formalized. Writing out an argument in formal notation will clearly reveal logic errors.
Aristotle has chosen to attack the conclusion, not any premise. And rather than argue the validity of the logic, he introduces inferences of his own, which are invalid, and argues them (the straw man argument). No, that point had nothing to do with forced encapsulation.
Aristotle [sic] is a weenie who argues for the point of arguing, or the glory of being right. There is no room in my blog for people like him. Here, we have productive conversations that explore topics and broaden our knowledge -- except when we have to counter attack weenies.
-scottRe:What is scrottie code?
Aristotle on 2007-07-28T03:19:54
What? Where have I been saying that Perl does not need forced encapsulation? First I agreed with you, then I argued twice that Perl does need mandatory controls, and now you tell me I said the opposite. Did you even read what I was saying? Or did you immediately go crosseyed and started looking for a misinterpretation of what you said so you had some grounds to get pissed off again?
I agree that we have a case of someone being a twit here, but it ain’t me.
Re:What is scrottie code?
scrottie on 2007-07-28T06:38:42
Crossed eyes? Perhaps. Let me re-read, in that case.
"Access controls are just another aspect of the sort of design you are talking about."
Okay, they're another aspect of it -- does this mean that good design is pointless because access controls are pointless (which is how I took it) or does it mean that, being a seperate aspect, they're simply related in some ways but not others, and if that's the case, what did I fail to read between the lines?
"I’m equally sick of the “no infatuation with enforced privacy” chestnut"
I probably got lost in the negatives. Lack of infatuation with enforced privacy is a bad thing... what's a chestnut? My bringing the topic up?
Ooooh.. I think I know where I went wrong. Apologies... especially for the drama. You linked to http://lists.canonical.org/pipermail/kragen-discuss/2007-March/001045.html... I started to read it and decided it was a different article and your "Yeah" was ironical. But that's much more interesting. Lack of context and lack of proper attention snuffed this one for me. Sorry about that. I had to read back a long way to figure this out. ... reading this more, you wrote it, and it's very thoughtful.
Ooops. *blush*
-scott
Re:What is scrottie code?
Aristotle on 2007-07-28T07:02:35
OK. I’m glad we got this sorted.
:-) Re:What is scrottie code?
Aristotle on 2007-07-28T01:09:47
Since you often complain about people failing to address the actual argument, I opted to moved all the incidental but off-topic quibbles to a second reply so they don’t get in the way of my real response.
Anyway, I wanted to nitpick the following statements:
Interfaces are a way of keeping straight
I don’t like interfaces in particular. As seen in Java, they fall out of a confusion and conflation of language design goals. Traits/roles are a much superior concept.
But even as far as interfaces go, Java has some strange irregularities; mainly, a class is distinct from an interface, so you can’t say “this class implements the same interface as implicity defined by that other class” – you have to write an explicit interface and use it in both classes. This means the OO designer has to forsee every instance where alternative implementations of the same public interface might make sense.
(A lot of the stupid things in Java tend to lead to this same place: “you need an omniscient designer who knows the needs of all clients ahead of time”. I guess that has some basis in reality when the designer is at Sun Microsystems and what he’s building is the standard library itself; when the designer is just a Java user, though, not so much.)
assume you were born when a gift from God at sorting these things out when charges are strongly in favor of the opposite, and you’ll have a mess that no one wants to touch
Charges are also strongly in favour of your inability to architect software on the drawing board.
I’ve found that designing in the abstract is of limited use. I spend time to think about the decomposition of my problem and the topology, but my designs don’t tend to get particular detailed. I prefer to start writing code soon, because I’ve found that working in the abstract – for me, at least – tends to produce designs that are unimplementable due to conceptual holes.
I also find designing class libraries for reuse is impossible without working code. You don’t know what applications actually need from the library and you don’t know what you need to expose so that subclassing can be done usefully, until you actually try to do it. (Hence the recent saying that frameworks should be extracted from working applications, not designed from scratch in a vacuum.)
All of this comes down to what’s most valuable about computers: they are stupid.
People can reason, so if you give them a flawed explanation they will fill in the blanks. As a result, flaws in mental models go undiscovered. Attempting to render the same explanation in code will relentlessly expose any holes in the reasoning. (See the foreword to Structure and Interpretation of Classical Mechanics . Note also Brooks’ famous “plan to throw one away” – that’s the underlying reason for it.)
The difference is that I try to keep a holistic view of any changes as I go along. I don’t just keeping throwing in things until “it works” (the PHP Way of Life); I think about the implications of any change for the entire design. If I find that I need to do something that violates any of the base assumptions of my decomposition, then I change the design and refactor the existing code to fit the new world view.
All that said, I’m not claiming that one should launch headlong into coding either. That would be a mistake. Doing some design up-front is hugely valuable. The returns diminish very quickly past a certain point, though. Doing design well is a balance between planning ahead and planning behind. Finding that spot takes practice and continuous self-examination.
Most programmers never get there. Or even anywhere close.
But you knew all that.
Re:What is scrottie code?
scrottie on 2007-07-28T01:54:15
Alright, that was slightly better than I had hoped for but I'm unswayed with regards to whether I want to talk to you.
My comment was that Perl programmers should spend more time worrying about interfaces and the structure of the code; your retort was that interfaces are poorly implemented and Perl 6's traits and roles are better. That's great... but it's also completely off topic. The point wasn't "Java is better than Perl". That wasn't even the title of the essay. It seems to be a conclusion you slipped in just so you could (easily) dispute it. Your remark has nothing to do with whether Perl programmers would do well to consider interfaces, spend more time on design, or why I like Java. The discussion has nothing to do with language features at all -- at least that part of it.
Let's recap that one real quick. Recapping again, but quickly this time. Perl programmers should spend more time on interface design. You're saying, no Perl programmers shouldn't (actually you're not even being man enough to give me such a conclusion so I know when I've invalidated it) because Java's implementation of interfaces is somehow subpar. Think about that for a minute. That's laughably irrelavent. It's terrible that this kind of randomness passes for discussion anywhere than in front of the TV when the bong is out.
"I’ve found that designing in the abstract is of limited use." -- aha! That's at least on topic, though probably by accident. Okay, so Perl programmers don't need to spend more time on design because time spent on design is wasted, to paraphrase you (and when someone paraphrases you, you can argue with the correctness of it thought I wouldn't make it a strategy in general). I asserted that Perl programmers do. I could argue it. But I don't want to. Throwing one away and refactoring but not reading books in favor of reading fluffy articles might be adequate. In my experience (which is not valid as a premise), it isn't adequate, and I won't speculate why. Or maybe one of my premises is the well supported opinion that code written in Perl is terrible.
They, let's run with that for a second. The world at large believes that code written in Perl is terrible. I have a survey that strongly supports this [premise]. Input B: Perl programmers can write good code. Either B is false or else Perl is a terrible language that ruins attempts to write good code in it. Which is it?
This stopped being interesting a long time ago. I hope you feel the same way and leave.
-scott
Re:What is scrottie code?
Aristotle on 2007-07-28T04:18:55
My comment was that Perl programmers should spend more time worrying about interfaces and the structure of the code
Which I agreed with. And in the same breath I pointed to one of my posts in another place where I say that Perl programmers chanting “we prefer politeness not shotguns” is misguided, which I think of as being a sign of the same immaturity.
That’s great… but it’s also completely off topic.
Wow, you found the start of my post (where I said all therein was just off-topic quibbling).
:-) You’re saying, no Perl programmers shouldn’t [spend time on interface design]
No, I didn’t say that. Where did I say that? Can you quote me on that? I’d like to see what I wrote that could have been so severely misconstrued that you managed to read it so completely counterfactually.
Because contrarily, I agreed that they should – and wanted to add to that that they should also get over themselves and quit chanting “no shotguns”, something whose value they would more readily understand if they actually did good OO design. I never disagreed with what you said. I’m not sure how on earth you came to the conclusion that I was arguing against you.
When I say that doing design in the abstract is of limited use, I am not saying that it is of no use. What I am saying is that without rendering the design in code, you will put conceptual holes in it that you won’t be able to detect. Separating coding from design is a false dichotomy; you must never stop considering the implications of what you’re doing while coding. No amount of books will teach you this balance (but neither will any amount of blinthely piling code onto code until it “works”).
But anyway, that was incidental; I’m quibbling, not disagreeing.
And I never touched your argument about fluffy articles. FWIW, since the “plan to throw one away” phrase came up: I’ve seen it in an actual hardcopy rendition of the book it is from. Along with all the other writing that’s in the book. In a copy that’s mine. I hope that’s enough said.
I hope you feel the same way and leave.
You know, considering your past travails I have always been sympathetic despite your broken approach to people. I understand (as much as you can understand a stranger on the internet) where that came from, and found your bouts of abrasiveness almost charming more than off-putting.
And I can’t really leave (your posts will continue going into the journals feed and therefore show up in my feed reader) any more than you can ban me here.
But if after the above refutation of your needless huff-and-puffing you still don’t want me stopping by, hey, knock yourself out. I’m content to stay or to go.
Sorry to have tripped your knee.
Re:What is scrottie code?
jdavidb on 2007-07-27T14:04:57
most Perl programmers would do well to spend some time ignoring the language itself and just concentrate on design.Hmm, I think of Perl programmers as actually focusing more on design than the Java I've seen. For a community that values TMTOWTDI, there sure is a lot of emphasis at times on making sure you do things the One True Best Way, which can be good for design. That's one reason I ask Perl programmers questions involving other languages.
I, too, really like interfaces.
:) Unfortunately the Java programmers I've dealt with never use them. :( Re:What is scrottie code?
scrottie on 2007-07-27T19:43:37
Hi jdavidb,
You make some good points.
There is a movement in the Perl community towards clean code (Perl::Critic). We collectively seem to have fallen in love with MVC frameworks. In trying to do things the right way, we obsess over decisions like Mason or Template::Toolkit.
But, compared to the Java camp, we don't read about OODA. (We also don't read about project management methodologies, which is a good thing, IMO.) Rather than going out and buying _Design Patterns_ and _Refactoring: The Art of Improving the Quality of Existing Code_, we read and write fluffy half-assed, dumbed down articles. I could walk into a Perl shop and not see a copy of the actual books anywhere and walk into a Java shop and see a copy on nearly every desk. Those books were overhyped and trendy, but there are a lot of good books out there on OO design. My favorite is _Object Oriented Design Heuristics_. These things are something of a relic of a late 1980's or early-mid 1990's when C++ was unchalleneged for dominance in the application space, so it's not surprising that Java, which many see as the successor to C++, took over the appetitite for those books.
So, there's a movement in the Perl community of wanting to do things the right way, and going through a lot of the motions, there's also a strong element of *only* going through the motions and missing the point at the same time. OODA is a big, complex, hard field. It would do us well to study it a bit rather than wave our hands, say, "oh, yeah, I've heard of that, I think we can do that"... like PHP programmers do when it comes to security. (Yes, PHP is my example of all that is evil and wrong and dangerously ignorant and bizarrely self confident.)
It's good that when we're given specifications for a complex system, we sit down and kick out a simple version of it a matter of days. It's good that we go in try to clean up code. But we're singularly ineffectual at it -- we're as ineffectual at arcitecting something as Java programmers are at kicking out a prototype.
All of this is opinion so it's hard to argue so the best I can do is try to illustrate my point with colorful language.
-scott
Writing Java code, though not particulary painful in the sense that C is painful (core dumps etc.), puts me to sleep.
Re:Not revulsion, in my case.
dug on 2007-07-27T19:20:25
That was a fun read. Thanks for the link.
-- Douglas
Re:I like Java...
Dom2 on 2007-07-27T22:01:18
I've done more Java than Perl in recent times, and it's a lot more bearable with a decent IDE. I use Eclipse, though IDEA is supposed to be better. I've never figured out NetBeans (though the Ruby support in 6.0 means I'll have to take another look).
I'd also say that I find the new language features in Java 5 make a huge difference. I find having a proper foreach loop, enums, etc make it a much more pleasant programming experience.
Got a good snicker out of me for that.
I don't refuse to use anything. I'm about to have to do something in Java, and in fact I've embarked on a program of going through some Java books to shore up my understanding of the language for the future. I still don't have to like it.
