Tao of the MachineProgramming, Python, my projects, card games, books, music, Zoids, bettas, manga, cool stuff, and whatever comes to mind. |
Front page Last 10 archives 2003-09-20 2003-09-27 2003-10-04 2003-10-11 2003-10-18 2003-10-25 2003-11-01 2003-11-08 2003-11-15 2003-11-22 Category archives bettas books CCGs Charm esoterica Firedrop games general ideas internet Kaa linkstuffs Lisp manga music Mygale Nederland nostalgia programming Python SGI switch Wax Zoids :: Search All posts ...by category ...by date :: About me :: Oasis Digital :: Resume :: GeoURL :: RSS :: Atom |
Objects of desireFor a better document than yesterday's, see Survey of Object-Oriented Programming Languages. It deals with different notions of "object orientedness". Sometimes people claim that language X has "better OO" than language Y, which really makes no sense, because there are so many flavors of OO. There is no "golden standard of object orientedness". The survey also describes a number of OO languages. It doesn't mention Python or Ruby, for some reason. I can think of some other languages that could have been in the list... OCaml, CLOS (OK, not really a language, more of a subsystem), ObjectPascal, maybe even ElastiC. However, the languages that the article does talk about, cover practically all important OO concepts and types. De kritiek van HansUnderstanding Object Oriented Programming. An article that illustrates, or attempts to illustrate, the different mindset for OO programming (vs, say, procedural programming.) The problem it describes seems easy enough. "The problem to be solved is to output a value judgment about operating systems. The assumptions being (of course) that UNIX is good and Windows is bad." :-) The so-called "hacker solution" basically gets the name of the OS, then uses some if statements to print a string. ("Unix is good", "Windows is bad".) So far, so good. However, the author criticizes this: "While this solves the problem, it would not be easy to modify in the future if the problem changes. In particular, if we need to add new operating systems, we need to extend the if structure. If we want to add additional functionality for each operating system, we would likely see this expand to nested if statements. This would get unwieldy over time. Thus, the hacker has solved the immediate problem, but made little progress on future evolution of the program." Later on, the "sophisticated object oriented + patterns solution" creates a whole bunch of code... 7 classes in 7 files. That's a lot of code for a simple "problem" like this. Not counting empty lines, this weighs in at over 80 lines, where the "hacker solution" took 19. A big difference for code that does essentially the same. However, the author doesn't think so: "Here we have maintainable code. To add a new OS, like the Mac OS, we just add a new class and add its registration to the factory. To change the functionality we change the OS classes. To add new functionality, we either modify the OS classes, or extend them." Uh, yeah. The first solution, using ifs, is bad, because you have to add an extra if statement, and that can "get unwieldy". The last solution is good, because all you have to do is to add "just" a class. Right. And this is "more maintainable"?! If this article illustrates anything, then it's the irrational notion that if and switch statements are bad, and gratuitous classes are good. A prime example of why and how code gets bloated beyond proportion. My pragmatic solution would be like the "hacker"'s, except when different boxen have demonstrably different behavior... e.g. a UnixBox does certain things differently than a WindowsBox, etc. Nothing was said about that in the problem description, however, so I consider the OS name just a property, an attribute, a trivial detail even... certainly not worthy of building a class hierarchy. Let the flames begin, although I doubt that there are many Pythonistas who use OO like in this article. AntilogAntilog is a simple module to read and query HTTP log files. Hacked up because my site uses Analog, which is OK, but I would like to see more information than it displays (e.g. not just the top 40 referrers, but all of them, etc). Normally this would be a simple case of changing the config file, but unfortunately I don't control the server, and have no permissions to change that file. So now I just download the access log and inspect it with Antilog. :-) Test test...Starting with this post, my weblog's comments are powered by pycs.net. For the older posts, I'll leave the Haloscan comments up... for now. Kudos to Georg Bauer for telling me how set this up. While I was at it, I replaced the φ for the permalink as well. Comment systems?Lately I haven't been happy with the comment system that my blog uses, powered by Haloscan. Take this page, for example. Many posts show up as having 1 or 0 comments, yet when you click on the link, there are several. (The metaclass post, for example.) In other places, the comments simply disappeared, yet I never deleted any. Maybe Haloscan comments expire after a certain period and I didn't read the fine print. However, that doesn't explain that the number of comments is displayed incorrectly. Does anybody know a better system? My blog is client-based, so I am forced to use a separate server-based comment system. I am looking for something more reliable, obviously. Suggestions are welcome. OCamlI always wanted to learn more about (O)Caml, but earlier attempts ended prematurely due to the lack of a good tutorial. I suppose the default tutorial is decent, but it was unsuitable for me, since it almost immediately dives into serious math and mathematical concepts. 1) Fortunately, the other day I found a better tutorial. It doesn't eschew the math stuff (after all, that is one area where functional languages shine), but it works from a different viewpoint. It assumes that you're familiar with a mainstream language (C, C++, Java, Perl) and goes from there. Particularly useful is that it explains some of the stranger OCaml features. At first glance, Caml may seem like a Lisp with a different syntax. At a superficial level, that may be true, but one crucial difference between those two languages is typing. Lisp has dynamic typing; Caml's typing is static, and on top of that it's ultra-strong. Stronger than Python's; Python doesn't allow "12" + 3, but it does allow 1.0 + 2 (float + int), and OCaml doesn't allow even that. It has special operators for ints and floats: e.g., for addition, there's In spite of this, Caml's is not a "get in your way" strong typing. Declarations are (usually?) not necessary, and you can still write functions that accept multiple types (although this is done differently than in Python, or C++ for that matter). In return, Caml uses this type system to implement some niceties not typically found in most other languages. Type inference, for example, and pattern matching. Another nice feature is that Caml, like Haskell, has currying built-in. You can call a function with fewer arguments than required, resulting in a new, curried function. For example: # let add a b = a + b;; (* add two integers *) val add : int -> int -> int = <fun> # add 3 4;; - : int = 7 # let addone = add 1;; (* curried function *) val addone : int -> int = <fun> # addone 9;; - : int = 10 As for readability... coming from Python, I find Caml rather difficult to read. This is partially because of the liberal usage of "line noise" characters, often without intuitive meaning. There's All in all, OCaml is a very interesting language. Its concepts are often very different from Python (or C, Java, etc), allowing for a different programming style, and different solutions. Anyway, I'm not quite done with the tutorial yet, so I'll probably be back with a second post. 1) Fine malt links
from the useless-hacks-deptYesterday's pseudo-image was generated by pic2html. This cool but utterly useless program came to be when I was trying to write something to convert ANSI art. You know ANSI art... pretty pictures in text mode with colors, drawn by ANSI escape sequences. If that still doesn't ring a bell, go to the acid.org archives. Note that viewing ANSIs requires a special program, or a DOS/Win9x box with ANSI driver enabled. Anyway, it's very difficult to display ANSIs as HTML, because of the difference in fonts. ANSIs relied on the old DOS font, with line drawing characters, etc. I did write an ANSI-to-HTML converter (kinda like pic2html), and I did find a font that emulates the DOS characters... sort of. But the resulting HTML still wouldn't be suitable for inclusion in web pages, since 99.9% of the readers would not have this font, and see a bunch of gobbledygook. Ceci n'est pas une image |