So, how have I just spent my afternoon? Debugging a 646 line Javascript monstrosity from hell thats what. I fixed the problem but all I can say is - yuk. Unfortunately I don't have (a)the time (b)the patience or (c)the authority to re-write the fscker.
First PL/SQL, now Javascript - so when do I get to work on some Perl code again?
Sigh.
Imho the problem with EcmaScript (and its JavaScript deviant variants) is not so much that it's a bad language -- it has limits and faults, but so do all the other ones -- but more that it's a language that was taken over by people that know nothing of programming (and that's not taking into account differing implementations if you're coding for the web at large).
I've developed a rather large (several thousand lines) EcmaScript app for a thin-client (using SVG of course) with little prior EcmaScript knowledge and I must say that it was a rather pleasant experience. Of course, I was writing a codebase from scratch and I was relying only on sane implementations (ie the Mozilla engine for 1.5, which is also what is present in Adobe's SVG viewer). ES has cool things such as a type system that allows you to simulate what it misses most (especially classes/namespaces), Perl compatible regexen, built-in exceptions, and quite a few other neat things. Coupling that with the amazing flexibility of the SVG viewer, I don't think I ever built a GUI that communicated with a server using XML messages so fast. I don't use it much these days, but I am certainly looking forward to ES 2.0.
The thing that really drove me mad is that some DHTML stuff wasn't erroring out, it just wasn't displaying stuff. An utter hair pulling experiance.
I can't wait for my copy of the rhino book to come, I've had to make do with an old 1.0 reference for a while now (I didn't even know we were up to version 1.4 now!)
Mozilla
vek on 2002-05-17T04:56:27
Javascript console++
I've also been playing with "venkman"[1] - their Javascript "debugger" for the past couple of days.
[1] That's such a cool "blast-from-the-past" name, I used it for a cron account recently - the first words from my sysadmin: "isn't that the guy from Ghostbusters?"
;-)
My latest bugaboo was a relatively insane bit of embedded SQL. It was intended to update a product's property. (I still don't know what that means or entails.) It checked to see if it was actually deleting the property, so it could insert NULL. It checked to see if it had to update a key, where it did something else special. It eventually updated either a long or a short character column.
The tricky part is, it interpolated the property name and the new property value into SQL embedded in a heredoc, built up over several statements through a couple of if/else couplets. When I noticed it was declaring a temporary stored procedure (yes, local to the SQL statement) just to check the keyness of the property, I was disturbed.
Then I hit a row of doubled-up single ticks, a home-rolled quoting menace that hid the true horror: to save from having to check to see, on the Perl side, if the column held a short or a long string -- something already known by the time this was called -- he passed the column type to the SQL, did some text manipulation in SQL, and returned SQL from the first SQL call so Perl could send the generated statement back to the database.
Only one of the four or five possible outcomes resulted in SQL coming back.
This was the same guy who wrote an 1100 line stored procedure with the time-honored procedure of cut and paste and still managed to misspell a hardcoded category name several different ways... and people are surprised when the data's inconsistent.
