I count myself fortunate to not know much about C++, in spite of that being the language I learned in college (4-yr degree). One of the many details I was blissfully unaware of was multiple inheritance. In fact, I didn't know that C++ supported multiple inheritance until I read about Java interfaces. A statement similar to "interfaces are Java's response to multiple inheritance in C++" usually appeared in the introduction. That inspired me to read about multiple inheritance in C++, but when I encountered the term "virtual base class", I decided to give up on that. The moral I learned was that, as with biology, tangled-up inheritance trees don't work well in practice.
When I started to pick up Python, I was startled to find multiple inheritance sitting right there in plain view, and no one was complaining. Actually, I could have found multiple inheritance in Perl, but that would have never happened because I only used objects in Perl; I never implemented them (is that like saying, "I never inhaled"?). This is a clear instance of the oft-observed difference in values between these languages and Java. In Java, you make the language simple enough that programmers, especially those on teams other than yours, won't mess the code up by abusing complicated features. In these other languages born from scripting, you make the language capable of anything, or at least extendible, so the programmer can do whatever he wants to get his job done. The relevant quote is "easy things easy and hard things possible".
The reason I bring up multiple inheritance now is because of a great blog post by chromatic about Roles: Composable Units of Object Behavior. The concept of object roles is slated for Perl 6. chromatic goes into great detail about how roles basically work as a middle ground between Java interfaces and C++ multiple inheritance. Squint enough and one might even think of it as AOP for classes. There's no reason someone couldn't accomplish a subset of the same effects in existing OO languages using a design pattern or two, but as chromatic explains, there are benefits to having roles built into the type system. Having roles built-in means that an interface and a default implementation don't need to be a matched pair, as in Java, but a single unit that can be applied to a class and checked at compile time or at run time. I still think I would rather have one class, parameterized by constructors into specific objects, and perhaps combined with another class using the decorator pattern, rather than one class parameterized by many roles into many classes. But maybe I'm stuck in the wrong paradigm. Roles seem like a great answer to the quandary of multiple inheritance. Leveraging the compiler is good. Code reuse is good.
Tuesday, September 12, 2006
Sunday, September 10, 2006
spoilers ahoy over at the Lost Blog
Not much to add here, just wanted to point over to the latest entry over at the Lost Blog. If any page ever deserved the disgustingly cute adjective "spoilerific", it would be this one. Not only does it have a list of informative tidbits from all over, but it either has or links to the information from the "Lost experience" game.
On a more general note, I've been stuck on Lost since seeing the "Walkabout" episode. I purposefully avoided the first few episodes because of my violent aversion to the herd mentality. (One of the surest ways to keep me from doing something is to tell me that "everybody's doing it"). The great work they do on the show, from the camera work to the acting to the writing, mixed with fascinating backstories and a huge list of unexplained phenomena, has kept me riveted. Not every episode is good, but for me, at least, there's something inside each one that makes it redeemable. I only care to see an episode of 24 once, but episodes of Lost hold up incredibly to repeated viewing.
Oh, and my personal take on the island is that there's some serious mind-control experiments going on. Too many of the characters have had eerie visions, dreams, or hallucinations for there to be any other explanation. The show does have its trippy parts...
On a more general note, I've been stuck on Lost since seeing the "Walkabout" episode. I purposefully avoided the first few episodes because of my violent aversion to the herd mentality. (One of the surest ways to keep me from doing something is to tell me that "everybody's doing it"). The great work they do on the show, from the camera work to the acting to the writing, mixed with fascinating backstories and a huge list of unexplained phenomena, has kept me riveted. Not every episode is good, but for me, at least, there's something inside each one that makes it redeemable. I only care to see an episode of 24 once, but episodes of Lost hold up incredibly to repeated viewing.
Oh, and my personal take on the island is that there's some serious mind-control experiments going on. Too many of the characters have had eerie visions, dreams, or hallucinations for there to be any other explanation. The show does have its trippy parts...
Friday, September 08, 2006
peeve no. 242 is free pdf printing in hp-ux
I had a lot of masochistic fun over the past few days trying to find the right combination of program and arguments to perform free pdf printing in the HP-UX system at work. I tried acroread first, obviously, but any attempts to run it resulted in complaints about the missing libgfk_pixbuf shared library.
Believe it or not, the HP-UX machine is not used for graphical tasks. At all. Any GUI programs are immediately out, not merely because I, the grunt programmer, have no direct access to the servers, but especially because I was looking for how to print a batch of pdfs from a script. Perhaps we could use one of the remote X session utilities, but it's definitely not a priority; it's a server, for Bob's sake.
I remembered ghostscript at this point, and happily enough the HP people have a binary package for it. I installed it, looked over the man page for a little bit, and started with the device/output file combination that seemed the most applicable. No good. So I attempted some other combinations, pulled up the ghostscript online documentation for my version, and began a ritual of 1. entering a command, 2. going to the printer, 3. viciously crumpling the useless printer output, 4. going back to the cube.
After too much of this, I admitted to myself that I knew nothing. I looked up the spec for the printer. PCL is good, but PostScript is not. That explained some of my trouble...I went back to the ghostscript online docs, but this time I searched for PCL. Oh joy. For this version of ghostscript, I read this: "Ghostscript as distributed includes the PostScript interpreter; there are also interpreters for PCL 5e, PCL 5c, and PCL XL, which are not currently freely redistributable and are not included in the standard Ghostscript package." But I chose to ignore this, so I started a new general web search. Finally, I came upon a SUSE manual that gave the magic combination: use device "ljet4" and output to a temp file, then print the temp file. What a productive way to spend my time...
Believe it or not, the HP-UX machine is not used for graphical tasks. At all. Any GUI programs are immediately out, not merely because I, the grunt programmer, have no direct access to the servers, but especially because I was looking for how to print a batch of pdfs from a script. Perhaps we could use one of the remote X session utilities, but it's definitely not a priority; it's a server, for Bob's sake.
I remembered ghostscript at this point, and happily enough the HP people have a binary package for it. I installed it, looked over the man page for a little bit, and started with the device/output file combination that seemed the most applicable. No good. So I attempted some other combinations, pulled up the ghostscript online documentation for my version, and began a ritual of 1. entering a command, 2. going to the printer, 3. viciously crumpling the useless printer output, 4. going back to the cube.
After too much of this, I admitted to myself that I knew nothing. I looked up the spec for the printer. PCL is good, but PostScript is not. That explained some of my trouble...I went back to the ghostscript online docs, but this time I searched for PCL. Oh joy. For this version of ghostscript, I read this: "Ghostscript as distributed includes the PostScript interpreter; there are also interpreters for PCL 5e, PCL 5c, and PCL XL, which are not currently freely redistributable and are not included in the standard Ghostscript package." But I chose to ignore this, so I started a new general web search. Finally, I came upon a SUSE manual that gave the magic combination: use device "ljet4" and output to a temp file, then print the temp file. What a productive way to spend my time...
Friday, September 01, 2006
.Net: He will join us or die
Have I become a mere link blog? One of those newsy blogs that's constantly linking elsewhere and making snide comments, with no original content? How can I justify my existence if I'm just one more "talking head" poring over RSS feeds? What--ah, screw it.
Somehow I ended up at Lisp is sin while I was following a thread along the warp and woof of the Web. I'm glad I did. Sriram's main point is the same one that many others make: over time, everyone is rediscovering the features of Lisp. Sriram's unique spin is that the .Net side of the house may get there sooner. Some evidence: Linq, lsharp, fsharp (which I've reported on in other posts), anonymous delegates, iterators (what the rest of the world calls "generators"). In the example from the blog, the C# 2.0 delegate keyword appears to be the stand-in for lambda. Does a C# 2.0 anonymous delegate form a true closure, with its own lexically-scoped copy of the variables in effect at the time of definition? I don't know. At work we're not yet using 2.0, because our vendor isn't.
Once you finish digesting that link, which is long and informative, read this pdf document by Erik Meijer about how functional programming has reached (will reach) the masses in the form of Visual Basic. I don't know what to believe in anymore...
For Sriram, Lisp is sin because it tempts him to flirt with it over and over again, but without leading to deep, lasting satisfaction. According to him, because of obstacles like a steep learning curve and a lack of libraries, Lisp in its current state cannot thrive in the mainstream. In fact, people have foretold its death for years. A .Net advocate far more militant than Sriram might say, "Lisp and its brethen, or at least the features therein, will join .Net or die." (By the way, I personally believe that popular programming languages never die; they just get reincarnated).
Bonus link: It's not as if Joel on Software needs me linking to it, but in Language Wars he takes a pretty definite stance: for serious, scalable, maintainable, productive Web development, you have merely a handful of choices, but as long as you choose from that group, you can just use whatever you're most comfortable with since the alternatives are about equally capable. Python is "half" on his list, but Ruby and Lisp and Perl are not. Admittedly, I'm not in a cutting-edge startup (far from it), but I don't think he's giving the up-and-comers enough credit. This conservative, enterprise, entrenched approach to Web development has a great deal of inertia, so we shouldn't be surprised if something else shiny and new sneaks up from behind and takes over, like Java did to C++.
Somehow I ended up at Lisp is sin while I was following a thread along the warp and woof of the Web. I'm glad I did. Sriram's main point is the same one that many others make: over time, everyone is rediscovering the features of Lisp. Sriram's unique spin is that the .Net side of the house may get there sooner. Some evidence: Linq, lsharp, fsharp (which I've reported on in other posts), anonymous delegates, iterators (what the rest of the world calls "generators"). In the example from the blog, the C# 2.0 delegate keyword appears to be the stand-in for lambda. Does a C# 2.0 anonymous delegate form a true closure, with its own lexically-scoped copy of the variables in effect at the time of definition? I don't know. At work we're not yet using 2.0, because our vendor isn't.
Once you finish digesting that link, which is long and informative, read this pdf document by Erik Meijer about how functional programming has reached (will reach) the masses in the form of Visual Basic. I don't know what to believe in anymore...
For Sriram, Lisp is sin because it tempts him to flirt with it over and over again, but without leading to deep, lasting satisfaction. According to him, because of obstacles like a steep learning curve and a lack of libraries, Lisp in its current state cannot thrive in the mainstream. In fact, people have foretold its death for years. A .Net advocate far more militant than Sriram might say, "Lisp and its brethen, or at least the features therein, will join .Net or die." (By the way, I personally believe that popular programming languages never die; they just get reincarnated).
Bonus link: It's not as if Joel on Software needs me linking to it, but in Language Wars he takes a pretty definite stance: for serious, scalable, maintainable, productive Web development, you have merely a handful of choices, but as long as you choose from that group, you can just use whatever you're most comfortable with since the alternatives are about equally capable. Python is "half" on his list, but Ruby and Lisp and Perl are not. Admittedly, I'm not in a cutting-edge startup (far from it), but I don't think he's giving the up-and-comers enough credit. This conservative, enterprise, entrenched approach to Web development has a great deal of inertia, so we shouldn't be surprised if something else shiny and new sneaks up from behind and takes over, like Java did to C++.
Wednesday, August 30, 2006
the Java closures that aren't
I admit to not reading the much-blogged closures proposal all the way through for the simple reason that I use Java version 1.4.2 at work (frankly, I have little to no say in the matter). I'm still waiting to throw out xdoclet for language-level annotations.
Nevertheless, I'm still glad to read Java Closures? Or just functors? Or just confusion? . Antonio does a great jorb defining real closures and functors, and thereby skewering the value of the proposed Java "closures". I especially appreciate this because I am consistently annoyed whenever people refer to a mere anonymous code block as a closure. Back when I used Perl more, I remember understanding code blocks (and references to code blocks) just fine, but having trouble understanding closures. I suppose it's a fine line, since languages with anonymous code blocks probably have lexical context and allow the code access to it, but try to answer the question "can someone create a full closure in Python?" and see how complicated the difference can be.
I didn't know about C++ functors until now. Of course, the term functor also represents a different technique in ML languages...*sob*
Nevertheless, I'm still glad to read Java Closures? Or just functors? Or just confusion? . Antonio does a great jorb defining real closures and functors, and thereby skewering the value of the proposed Java "closures". I especially appreciate this because I am consistently annoyed whenever people refer to a mere anonymous code block as a closure. Back when I used Perl more, I remember understanding code blocks (and references to code blocks) just fine, but having trouble understanding closures. I suppose it's a fine line, since languages with anonymous code blocks probably have lexical context and allow the code access to it, but try to answer the question "can someone create a full closure in Python?" and see how complicated the difference can be.
I didn't know about C++ functors until now. Of course, the term functor also represents a different technique in ML languages...*sob*
Tuesday, August 29, 2006
is haskell hot or not?
So, Haskell is one of those languages that I keep hearing great things about, but I'm still not convinced enough to take a long, serious look at it. A use.perl.org journal entry by Ziggy makes Haskell sure smell like nirvana. Then I see something like Algebraic Topology in Haskell over at dzone.com, and Damian Conway's turn of phrase from another context, "brain-meltingly complicated", comes to mind. Maybe the moral here is that once you adjust to monads and lazy evaluation and other unique features, you can use Haskell to manage any level of complexity you wish--there is no artificial limit on expressiveness. But I'm only speculating. The usual caveat applies: if you write your software too cleverly, you just might have to maintain it for life. Don't forget another factor too: a powerfully expressive language without the particular libraries you need simply isn't as practically useful as a lesser language with those libraries. On a common VM platform, any language can use any library, so this is admittedly becoming less of a concern.
Ziggy's post is really about a perceived (I don't believe that the majority of developers out there truly care at this point) mainstream rise of functional programming. He (she?) links to Joel on Software's Can Your Programming Language Do This? as an example, which by the way is a brilliantly concise but easily understood explanation of how convenient some functional programming features can be. I must say that I would prefer Ruby versions of his code snippets. Ziggy also links to Kingdom of Nouns, which I've commented on before. I wonder if the people who use Ruby as a poster child of not being a kingdom of nouns are self-aware enough to notice that everything in Ruby is a noun (object)?
Bonus observation: Adam Bien's Weblog says that you shouldn't compare Javascript/Ruby to Java. Why? Because as I said in "clash of programming language civilizations", the values are different.
Ziggy's post is really about a perceived (I don't believe that the majority of developers out there truly care at this point) mainstream rise of functional programming. He (she?) links to Joel on Software's Can Your Programming Language Do This? as an example, which by the way is a brilliantly concise but easily understood explanation of how convenient some functional programming features can be. I must say that I would prefer Ruby versions of his code snippets. Ziggy also links to Kingdom of Nouns, which I've commented on before. I wonder if the people who use Ruby as a poster child of not being a kingdom of nouns are self-aware enough to notice that everything in Ruby is a noun (object)?
Bonus observation: Adam Bien's Weblog says that you shouldn't compare Javascript/Ruby to Java. Why? Because as I said in "clash of programming language civilizations", the values are different.
Saturday, August 26, 2006
the two species of programmers
Along the same lines as that "clash of programming language civilizations" post, I have long had the idea that there are two basic species of programmers. I have no hard evidence for this blurry distinction, but only my own experience and hyperactive generalization. I'm also sure that I'm not the only one to have stumbled upon this. Anyway, in alphabetical order, the two species: linguistic and mathematical.
- Linguistic. This species spells correctly most of the time. In fact, the linguistic can often be observed lecturing or poking fun at the mathematical's egregious spelling errors. Per its name, the linguistic has excellent language intelligence or aptitude, and perhaps may study little-used languages like Esperanto. The linguistic may be good at abstract algebra, but may not be as quick as the mathematical when it comes to, say, listing the first 23 prime numbers. A program is a series of sentences and clauses for a linguistic. Functional programming may come more naturally to the linguistic than the mathematical. The linguistic may take excessive pleasure in the logical elegance of a program's design. He or she may be more apt to comment "if the computer can't run my beautiful program efficiently, then that's the compiler or interpreter's problem". Top-down or UML-style design may be a preferred mode of operation for the linguistic.
- Mathematical. This species often has difficulty spelling correctly. But to the mathematical, correct spelling doesn't really matter so long as the idea gets communicated. Per its name, the mathematical has excellent mathematical intelligence or aptitude, and may know practical trivia about timekeeping. The mathematical's intuitive feel for numbers allows for good estimation, such that the mathematical can arrive at an answer but have trouble explaining how he arrived at it. A program is a series of individual calculations for a mathematical. A mathematical would view the statement a = 5 + 2 to be "add 5 to 2 and store the result in a", while a linguistic would view the same statement as "define a to be the evaluation of the expression 5 + 2". Assembly programming may come more naturally to the mathematical than the linguistic. To the mathematical, complex program design is not necessarily a joy; to the contrary, it may be more likely to obscure the real functioning of a program. He or she may be more apt to comment "perfect theroetical purity isn't worth anything if it doesn't adequately solve this particular problem in the real world". Bottom-up or eXtreme Programming may be a preferred more of operation for the mathematical, in which program modularity evolves naturally.
Wednesday, August 23, 2006
commentary on personality traits of the best software developers
Personality Traits of the Best Software Developers seems fairly insightful and honest. Some of the many comments also make some good points, although enumerating more and more desireable personality traits is really tangential to the original post. The author, Rob, condensed the most essential traits into an exceedingly compact list. Other traits are fine, but simply not as worthy of inclusion.
Naturally, I believe that I have the described traits, and furthermore that the four traits have a characteristic in common: a focus on reality (the code's effects) as opposed to a mere focus on idealized abstractions (the code itself). Developers focused on reality don't dream up a solution, code it, and then see how it turns out. Developers focused on reality 1. consider possible problems ahead of time (pessimistic trait), 2. believe that each problem is a logical effect from a root cause in the code (angered by sloppy code trait), 3. create and stick to a long-term plan that protects them against real threats (long term life planners trait), 4. keep abreast of as much reality as they can (attention to detail trait).
Of course, I can't help adding in a couple other traits that I value: 1. curiosity, 2. creativity. Developers with those two traits always have more alternatives available to them in any given situation. Ever play a game called Mindtrap? It has cards with short little puzzles, each of which has no obvious solution until the listener stops limiting his answers with assumptions and preconceptions. Life is Mindtrap.
Naturally, I believe that I have the described traits, and furthermore that the four traits have a characteristic in common: a focus on reality (the code's effects) as opposed to a mere focus on idealized abstractions (the code itself). Developers focused on reality don't dream up a solution, code it, and then see how it turns out. Developers focused on reality 1. consider possible problems ahead of time (pessimistic trait), 2. believe that each problem is a logical effect from a root cause in the code (angered by sloppy code trait), 3. create and stick to a long-term plan that protects them against real threats (long term life planners trait), 4. keep abreast of as much reality as they can (attention to detail trait).
Of course, I can't help adding in a couple other traits that I value: 1. curiosity, 2. creativity. Developers with those two traits always have more alternatives available to them in any given situation. Ever play a game called Mindtrap? It has cards with short little puzzles, each of which has no obvious solution until the listener stops limiting his answers with assumptions and preconceptions. Life is Mindtrap.
Tuesday, August 22, 2006
clash of programming language civilizations
Why yes, the title of this post is sensationalist and even a little insulting to the real, violent culture clashes in the world. Thanks for noticing.
A few days ago I pointed to a blog posting that I saw through the use.perl.org feed. This time, I'll be pointing to blog postings through the javablogs.com feed. (I'm subscribed to those feeds because I frequently use Java and Perl at work. Outside of work, I experiment with whatever.) A proposal to add closures to Java has brought out some interesting arguments for the status quo. Java 5 Language changes were a bad idea even argues that the status quo, Java 5, isn't all that much an improvement over previous versions. Here are two quotes from there, one short, one long: "Verbosity is a good thing(tm)!", "Encapsulation is very important and is defined using several levels of hiding: class, package, protected and public... Simple and powerful. Why is this powerful? Because I can rely on the scope and find the usage of X (X being a field or method) within his scope far more easily.".
What I find so intriguing is that the same valued characteristics this blog used to support an exceedingly lean, simple Java are what Java detractors routinely trot out as arguments for Java being weak, wordy, and over-engineered. The same characteristics! It's as if one person's language vice is another person's language virtue. Contrast the above quotes to quotes from the dynamic-typing, stop-calling-us-scripting-languages camp: "do what I mean (DWIM)", "convention over configuration", "the first postmodern computer language". With values this different, neither "side" even has an agreed-upon ruler for comparing their...er, syntax.
This clash in values is even more dramatic when you start considering examples. About Microsoft's "Delegates" transparently explains why Java chose not to have delegates. One blogger compared Hani's Bile Blog to some of the oh-so-friendly Ruby resources, and got some surprisingly shrill replies in spite of the fact that one's attitude has no correlation to one's programming language. A blog entry which is not so tongue-in-cheek is Our long Java nightmare. He says this isn't an anti-Java rant, but with a title like that, I wonder what would be. An irritated individual over on javalobby has the legitimate complaint that Ruby users keep discussing Ruby on Java sites. There's even a guy who feels compelled to argue that Java is not in the midst of a close battle with the Next Big Thing.
Another twist on this deep clash in philosophy is the group who works in Java for a living, and is recreating (mostly server-side) Java development "from the inside". Truth be told, if you want to use closures along with Java-ish syntax, you can just use Groovy right now and use Grails to develop a website around an EJB 3 object. Web service development isn't that hard at all if you use Glassfish. Even sticking with Eclipse is easier than it used to be with Callisto. If you prefer VB-like development, you may be able to do that sometime in the future. Want the source for the language implementation, so you can solve the most obscure bugs? It's on the way. Java programmers are not buffoons. Whether they cash in on it or not, they (we?) know how hard it has been to get things done in Java.
Conclusion? There is none. The rationale behind a choice of programming language is up to you, or your managers. Which punctuation marks or paradigm a language uses is only part of the equation..."it's how you use it". As Ovid explains, Perl probably wouldn't have the reputation it does if people used it better. More to the point, in another place Ovid advises his readers to ignore language holy wars and use the language whose strengths best fit your problem.
I would also advise that rather than choosing 1. the side of Turing Machines and statefulness and efficiency and static typing, or 2. the side of lambda calculus and statelessness and runtime interpretation and deferred typing, pick both. Think laterally. Use a convenient RAD language for most of the program and a speedy language for the parts that are a performance bottleneck. Use a language that can check types at run time OR compile time. Use a language that is functional but statically typed, like F#. There doesn't have to be One Language to Rule Them All, as long as there is One Interoperable Platform To In the Darkness Bind Them. But it certainly is entertaining to watch the two programming language civilizations clash.
A few days ago I pointed to a blog posting that I saw through the use.perl.org feed. This time, I'll be pointing to blog postings through the javablogs.com feed. (I'm subscribed to those feeds because I frequently use Java and Perl at work. Outside of work, I experiment with whatever.) A proposal to add closures to Java has brought out some interesting arguments for the status quo. Java 5 Language changes were a bad idea even argues that the status quo, Java 5, isn't all that much an improvement over previous versions. Here are two quotes from there, one short, one long: "Verbosity is a good thing(tm)!", "Encapsulation is very important and is defined using several levels of hiding: class, package, protected and public... Simple and powerful. Why is this powerful? Because I can rely on the scope and find the usage of X (X being a field or method) within his scope far more easily.".
What I find so intriguing is that the same valued characteristics this blog used to support an exceedingly lean, simple Java are what Java detractors routinely trot out as arguments for Java being weak, wordy, and over-engineered. The same characteristics! It's as if one person's language vice is another person's language virtue. Contrast the above quotes to quotes from the dynamic-typing, stop-calling-us-scripting-languages camp: "do what I mean (DWIM)", "convention over configuration", "the first postmodern computer language". With values this different, neither "side" even has an agreed-upon ruler for comparing their...er, syntax.
This clash in values is even more dramatic when you start considering examples. About Microsoft's "Delegates" transparently explains why Java chose not to have delegates. One blogger compared Hani's Bile Blog to some of the oh-so-friendly Ruby resources, and got some surprisingly shrill replies in spite of the fact that one's attitude has no correlation to one's programming language. A blog entry which is not so tongue-in-cheek is Our long Java nightmare. He says this isn't an anti-Java rant, but with a title like that, I wonder what would be. An irritated individual over on javalobby has the legitimate complaint that Ruby users keep discussing Ruby on Java sites. There's even a guy who feels compelled to argue that Java is not in the midst of a close battle with the Next Big Thing.
Another twist on this deep clash in philosophy is the group who works in Java for a living, and is recreating (mostly server-side) Java development "from the inside". Truth be told, if you want to use closures along with Java-ish syntax, you can just use Groovy right now and use Grails to develop a website around an EJB 3 object. Web service development isn't that hard at all if you use Glassfish. Even sticking with Eclipse is easier than it used to be with Callisto. If you prefer VB-like development, you may be able to do that sometime in the future. Want the source for the language implementation, so you can solve the most obscure bugs? It's on the way. Java programmers are not buffoons. Whether they cash in on it or not, they (we?) know how hard it has been to get things done in Java.
Conclusion? There is none. The rationale behind a choice of programming language is up to you, or your managers. Which punctuation marks or paradigm a language uses is only part of the equation..."it's how you use it". As Ovid explains, Perl probably wouldn't have the reputation it does if people used it better. More to the point, in another place Ovid advises his readers to ignore language holy wars and use the language whose strengths best fit your problem.
I would also advise that rather than choosing 1. the side of Turing Machines and statefulness and efficiency and static typing, or 2. the side of lambda calculus and statelessness and runtime interpretation and deferred typing, pick both. Think laterally. Use a convenient RAD language for most of the program and a speedy language for the parts that are a performance bottleneck. Use a language that can check types at run time OR compile time. Use a language that is functional but statically typed, like F#. There doesn't have to be One Language to Rule Them All, as long as there is One Interoperable Platform To In the Darkness Bind Them. But it certainly is entertaining to watch the two programming language civilizations clash.
Saturday, August 19, 2006
make a combinator from a MOP
Where would I be without RSS? In Firefox, you can make a Live Bookmark folder from a feed, then put that folder into the bookmarks toolbar folder. Turn on the bookmarks toolbar from the view menu, and then you have one-click access to checking up on your feeds.
This technique is most handy for sites that aggregate or host many blogs but offer one, combined feed. It was through the use.perl.org Most Recent Journals feed that I found the provocatively titled post Moose::AutoBox - Ruby ain't got nothin on us . The more that I investigated what Stevan wrote about, the more impressed I was by what he's working on. Moose::AutoBox, strangely enough, uses an autobox module and Stevan's Moose module to enable runtime modification of methods to call on Perl's builtin types. The runtime object modification happens through the Moose module, which as I understand it is for providing a nicer interface to the Class::MOP module. And the Class::MOP module is an implementation of a Meta Object Protocol for Perl 5 objects. It came about because he wanted to use some Perl 6 object features in Perl 5 (he's not alone; there are other modules out there for doing Perl 6-ish stuff in Perl 5).
I'm skeptical about the usefulness of a class morphing at runtime, but once again I admit to not ever doing it. I simply haven't found a need for it in the software I write. Actually, I don't use plain old reflection or introspection much either. It seems to me that a combination of interfaces and runtime composition of objects can accomplish the effect of changing a class's behavior at runtime, but in a cleaner and type-safe way (see strategy or command or dependency injection design patterns). In fact, reading Stevan's post reminded me of a different post I read a while back on Oreilly, Is a Java macro language enough? . It's good reading, and it discusses both a MOP and Lisp-style macros for Java. I think he concludes that bolting on such sophisticated features at this stage in the game would result in a more complicated language, when what we want is to make Java easier not harder to work with.
Back to Stevan's post. He shows an example of using the Code part of Moose::Autobox to apply the Y combinator, which is part of the module, to an anonymous code block to make it recursive. What's the point of this in a language that supports recursion in the usual fashion: by using the function name inside its definition? There is none, unless you really, really don't want to name your recursive function for some reason...like if you're defining it on the spot so you can pass it to a higher-order function. Anyway, if you're curious about the Y combinator like I was, be prepared to read many parentheses in links like this ruby example, or this Scheme example . The Scheme link is about several abstract topics, but the Y combinator is at the bottom. They don't teach this stuff in Java class, people. They just don't.
This technique is most handy for sites that aggregate or host many blogs but offer one, combined feed. It was through the use.perl.org Most Recent Journals feed that I found the provocatively titled post Moose::AutoBox - Ruby ain't got nothin on us . The more that I investigated what Stevan wrote about, the more impressed I was by what he's working on. Moose::AutoBox, strangely enough, uses an autobox module and Stevan's Moose module to enable runtime modification of methods to call on Perl's builtin types. The runtime object modification happens through the Moose module, which as I understand it is for providing a nicer interface to the Class::MOP module. And the Class::MOP module is an implementation of a Meta Object Protocol for Perl 5 objects. It came about because he wanted to use some Perl 6 object features in Perl 5 (he's not alone; there are other modules out there for doing Perl 6-ish stuff in Perl 5).
I'm skeptical about the usefulness of a class morphing at runtime, but once again I admit to not ever doing it. I simply haven't found a need for it in the software I write. Actually, I don't use plain old reflection or introspection much either. It seems to me that a combination of interfaces and runtime composition of objects can accomplish the effect of changing a class's behavior at runtime, but in a cleaner and type-safe way (see strategy or command or dependency injection design patterns). In fact, reading Stevan's post reminded me of a different post I read a while back on Oreilly, Is a Java macro language enough? . It's good reading, and it discusses both a MOP and Lisp-style macros for Java. I think he concludes that bolting on such sophisticated features at this stage in the game would result in a more complicated language, when what we want is to make Java easier not harder to work with.
Back to Stevan's post. He shows an example of using the Code part of Moose::Autobox to apply the Y combinator, which is part of the module, to an anonymous code block to make it recursive. What's the point of this in a language that supports recursion in the usual fashion: by using the function name inside its definition? There is none, unless you really, really don't want to name your recursive function for some reason...like if you're defining it on the spot so you can pass it to a higher-order function. Anyway, if you're curious about the Y combinator like I was, be prepared to read many parentheses in links like this ruby example, or this Scheme example . The Scheme link is about several abstract topics, but the Y combinator is at the bottom. They don't teach this stuff in Java class, people. They just don't.
Subscribe to:
Posts (Atom)