The parser proceeds well. I'm currently refactoring the code to be more modular and robust, as well as cleaner. I have my own subpackage in the solution, and I'm going to fill it with as many files as I need to make the architecture pretty.
In terms of functionality, I wasn't able to accomplish anything over the weekend. If you must know, I instead wrote a GPU raytracer for rendering 3D fractal geometry, complete with distance estimators, Phong shading, and frustum clipping. Woe that this isn't a graphics project.
However, I had planned on doing that; the parser will still be advanced in time for the next client meeting on Wednesday. Positioning will be in place. In fact, I anticipate, the way things are going, for the parser to be just about completed, with minor functionality to be added as new features are made accessible by the GUI.
Meanwhile, GWT is being snarky again. Actually, strictly speaking, not "snarky". That word is closer to "sassy" or "cheeky", and at least implies some level of sophisticated defiance. No, GWT is being outright stupid. My primary complaint right now (because I'm not so directly working with it) is that it's not robust. It takes like ten seconds to start up, and when it does, half the time there's some internal error. I've found that restarting Eclipse usually helps. But, I am frustrated that something that's supposedly super-awesome can't even get out the starting gate when you try to use it. And, I'm immediately suspicious of something that runs differently each time. It brings to mind thread contention issues and broken dependencies. And I'd be worried about that except GWT is necessarily single-threaded. . . . which still leaves the question: why can't GWT work perfectly every time? Is that too much to ask?
It brings up an interesting point about software engineering. I consider myself much more a computer scientist and programmer, instead of a software engineer. The difference is subtle, but I talk about it a bit here.
Nevertheless, I continually get the feeling that for some reason my code is inherently better than code produced in the "real world". It is endlessly annoying to have to work around someone else's bug in a library, or to write wrappers around broken APIs so that they're usable. Yet somehow, for some reason, my code always manages to be fast, flexible, and, above all, robust. I frequently (weekly or so) receive emails from satisfied users of my libraries praising their "beautiful API[s]" and robustness. In one coder's words:
". . . the API is cleasn[sic], crisp[,] and compact--yet still powerful. Your code is astoundingly bug-free and my only problem[s] come from me being completely retarded. Using your code is like breathing freely."I myself hardly ever have the opportunity to send such mails. I typically send bug reports.
The point is not to demonstrate that I'm a better person or something--the issue is one of design. Better-designed code tends to work better. Do I just pay more attention to that than other people? These questions go through my head rather more often than I'd normally care to admit, and they are of particular relevance as I rework the parser. Group members: you may expect robust, powerful, and well-designed code.
But it all brings me back to GWT. I'm not going to speculate on why it can't reliably start, but it suffices to say that it makes debugging extremely annoying, so long as "extremely" is VERY strongly emphasized. I think I may start a separate project, and run the parser on GWT objects that have been saved out and serialized. I wager it would be faster--though, the way things are going, I wouldn't be (too) surprised if GWT has some meaningless constraint that prevents you from doing this.
I also found a curious little method Canvas.getInnerHTML(), which appears to return a whole lot of nonsense. It looks like some of it might be useful, but it's clearly no substitute for real parsing. Which reminds me, back to that design thing: one good design principle is to avoid name collisions. I solve this with namespaces, and by naming my functions and classes intelligently. At the very least, prefixing with some easy to recognize identifier. In Java, the evidently accepted solution is to use different capitalization, because apparently that's so much cleaner. On right, what Eclipse has to say about the unrecognized symbol "HTML". Terse and uniform APIs? Mmmmm no. |  |
So, project-wise and in sum: the parser will be next to done by Wednesday. Furthermore, it will live up to my standards of design. GWT is annoying. We'll see how it plays out.
Ian
No comments:
Post a Comment