Linkstew

2008 Prediction 4: PHP Problems - "A large part of the problem PHP has is that it's evolved substantially over time and doesn't force you to program in a certain way: you never know if you're getting clean object-oriented code or nasty procedural code" [From Commentor Chris Adams]

The thing I find ironic about this comment is that it forgets functional programming completely, which kind of just emphasizes how bad PHP is at it.

Recently I've been looking into other languages and talking about them with friends, but we keep coming back to the same realization: for all of its warts, we're always going to always have a soft spot for Perl. Here's just one of the many perlisms I'd miss in another language:

    # create a new CGI object with three levels of masking:  
    # defaults get masked by parameters, and parameters get masked by overrides
    my $cgi = new CGI( {  %$defaults_ref,
                          %$parameters_ref,
                          %$overrides_ref,
                       } );

Joel on Software - Making Wrong Code Look Wrong

I'm almost totally convinced. The next time I'm in a position to affect a coding convention, I'll reference this article. And hopefully by then, we'll have tools that can check hungarian "types."

Biculturalism (UNIX culture vs Windows culture)

Add ESR's "The Art of Unix Programming" to my list of books I need to read. It sounds highly intriguing.

Love, Hate, and Objective C

I still want to really learn Objective C (I've dabbled), but I still haven't found an application I'm really enthused about applying it to.

Today was a long hot day of trying to work around HTML's shortcomings using JavaScript, only to end up hating JavaScript even more and fixating on how useless HTML's form tag is.

"The form tag!?" you might ask.

Granted, there's an awful lot wrong with HTML, but as a web developer, the form tag (and the input tag) are the only things I really care about at the end of the day -- and unfortunately, the form tag sucks.

So, if I could change one thing about HTML, I'd move the "action" attribute from being an attribute of the form tag to being an attribute of a submit input tag. Then, it wouldn't matter that HTML can't deal with nested form tags, because I could just submit to different actions depending on which button was pressed.

Now don't get me wrong: Java's stack traces are really useful, and I'd far rather see something like

Exception in thread "main" java.lang.NullPointerException
        at Shuffles.main(Shuffles.java:18)

than see something like

Segmentation Fault (core dumped)

But it's just the "Segmentation Fault" half that sucks. The "core dumped" half, on the other hand, is something I really wish java would do. Just finding a stack trace in the logs tells me where something went wrong, but when you have innumerable combinations of clicks and data, "where" isn't always good enough. Without some extra information about what data caused the exception, sometimes it can be really damn hard to fix.

Ideally, java would be able to print a stack trace and dump core. If the problem the stack trace pointed at wasn't glaringly obvious (which it is, most of the time), then I could load up the core and figure out what exactly about the data was bad, and attempt to determine if it was just some transient error (which it seems to be, more often than not). It seems like java's reflection or serialization abilities are powerful enough that it could dump a lot of state information (and call it "core") and allow you to poke at it later. But it just doesn't seem like something anyone realizes they could use.

I can't even put into words how crazy it makes me that java doesn't require { }'s around its control blocks.

if ( bool )
     if ( bool2) 
          something();
     else 
          somethingelse();
else
     shootme();

That's completely valid and perfectly awful in java. I'm regularly looking at a lot of new java code at work, and every time I come across that it takes me a few extra seconds to read it. And the people who wrote the code seem awfully fond of that six-character saving construction. They also don't always indent it usefully, so I frequently find myself reading the wrong else at first glance. Also, without the { }'s, how is my editor supposed to highlight the matching curly to help me see where a block is?

While I completely understand the argument that control structures take a single statement, and a single statement can either be a semicolon terminated line or a block containing multiple statements, that doesn't make it right. Look how much easier this is to read:

if ( bool ) {
     if ( bool2) {
          something();
     } else { 
          somethingelse();
     }
} else { 
     shootme();
}

Arguably, the problem I'm having is actually that people just didn't indent their code well, and not that they didn't use curlies. Python doesn't require curlies, and its control structures tend to be reasonable readable thanks to forced indentation. While Java never could have gotten away with adding forced indentation (very few C programmers ever would have tried java in the first place, then), it probably could have gotten away with requiring curlies, and that would have helped enforce a little extra readability.

I'm so glad perl requires { }'s in that context. Perl's something() if bool; construction is also pretty kickass, and much better thanks to its lack of an "else." But then again, perl also has elsif, which is a fairly questionable design decision in the control structure domain.

Since I've been using java at work, I've been having some serious problems with semicolons; I'm pretty sure I've had more errors thanks to unterminated statements than anything else.

Hans's Top Ten JSP Tips

In particular, the first sentence of item 7 and the first sentence of the third paragraph of point 9 are particularly salient for me, because those are exactly what I've been dealing with lately.

But JSP aside, "Don't put SQL in the scrip / modularize all of your database calls" seems so obvious to me that it might as well be Databases 101. Sigh.

Only if your time is free...

Possibly being faced with the very issue of potentially having to buy my own IDE when my one month IDEA trial expires, I found this meta-article short on useful information, but close to home none-the-less.