I think Java may be part of your problem. I don't speak it myself, but I know that it's a programming language designed to produce reliable code from large teams of mediocre programmers, rather than concise code from a few wizards; that it is extremely verbose and obstinately object-oriented by design; and that it has such a large library of toolboxes and libraries (with, as you've seen, have hyper-operational documentation) that programming in it has been described as "approach[ing] problem-solving like a plumber in a hardware store". It seems like the kind of language that, were I forced to produce programs in it, I'd end up writing programs in scripting languages to produce Java programs instead of writing in Java directly. So that's one idea! Write code generators or preprocessors in Python or the like, to factor out all the boilerplate code. Or write in Jython if you can get away with it.
From: ShadowSpy | Posted: 4/26/2012 8:30:12 PM | #003
How exactly do you approach your projects?
My strategy is generally to start on the hardest part first. You know how all but the easiest programs have some bits which are relatively mindless and others which are more difficult, for reasons intellectual (coming up with the right algorithm requires thought) or practical (there's a poorly documented feature you'll need to use, or you'll need to build an interface to two disparate systems). Begin by making that work. If the problem is both sufficiently difficult and sufficiently general, it can help to write a test suite before you start on the program proper. Once you have the hard stuff down, the rest is just cleanup and filling in the gaps, which is more gratifying than it sounds because it yields tangible results quickly once the hard stuff's done.
Any tips on improving?
Hmm. For me, one of the biggest differences between code I like and code I don't like is functional versus object-oriented or procedural style. That is, I prefer higher-order functions and deeply nested expressions over series of simple statements and loops:
Example 1:
bool $picked_blue = ($blue_on_right xor $picked_left);
(vs.)
bool $picked_big;
if ($blue_on_right)
{if ($picked_left)
{$picked_blue = 0;}
else
{$picked_blue = 1;}}
else
{if ($picked_left)
{$picked_blue = 1;}
else
{$picked_blue = 0;}}
Example 2:
sd = sqrt(
sum(map(lambda x: (x - mean(v))**2, v))
/ len(v) )
(vs.)
sd = 0
for x in v:
sd += (x - mean(v))**2
sd = sqrt(sd / len(v))
A functional style feels much more like saying what I mean, whereas a procedural style feels like stuttering. It's both easier for me to read and pleasanter for me to write.
Although this might sound obvious, don't neglect the opportunity to abstract away repetitive details into a function. It amazes me that people are comfortable doing fiddly SQL statement construction, binding, and execution in the middle of their application logic. I use the nifty Perl modules DBIx::Simple and SQL::Abstract and define functions liberally so I can say things like
my @u = $o->getrows('User', sn => $o->{sn});instead of
my $sth = $o->{db}->prepare('select * from User where sn = ?', $o->{sn});
my $results = $sth->execute;
my @u = $results->hashes;, although if I had to do it the latter way, I would, of course, instead write it as:
my @u = $o->{db}->prepare('select * from User where sn = ?', $o->{sn})->execute->hashes;
---
"Ratio tile, the wish power are together with you."