NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Mark Hahn, <hahn@neurocog.lrdc.pitt.edu>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
What is scrottie code? (Score:1)
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.
I know that you don't actually code in it that much
Re: (Score:1)
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 progr
Re: (Score:1)
Yah [canonical.org].
Re: (Score:1)
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
Re:What is scrottie code? (Score:1)
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:
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.)
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 [mit.edu]. 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.
Reply to This
Parent
Re: (Score:1)
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 slippe
Re: (Score:1)
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.
Wow, you found the start of my post (where I said all therein was just