Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
I'm thinking that a talk about what we can learn from other languages would be extremely fun, though it would be tough to go to in-depth in an hour long talk. So here's a snippet of Java:
public static int someMethod (int foo) {
// ... method 1 code
}
public static int someMethod (int foo, int bar) {
// ... method 1 code
}
And here's how that might get replicated in Perl:
sub someMethod {
my $self = shift;
my $foo = shift;
if (@_) {
# method 2 code
}
else {
# method 1 code
}
}
Needless to say, the Perl version has scope for plenty of bugs that the Java version is less prone to.
Or how about some SmallTalk?
hello: times say: text
(times > 100)
ifTrue: [ Transcript show: 'You will get bored!']
ifFalse: [1 to: times do: [:i | (Transcript show: text) cr]]
ifTrue and ifFalse are messages sent to boolean objects. Once I grokked this, I started grepping my OO code for 'if' statements and finding subtle bugs all over the place.
Or some Prolog:
likes('Ovid', 'Perl 5').
likes('Ovid', 'Perl 6').
likes(alice, 'Perl 6').
Extracting information from those facts is trivial in Prolog, but in Perl, often involves annoying while loops and if statements.
In fact, many of my thoughts about such a talk seemed related to "here's how other languages avoid bugs by minimizing procedural code".
Other examples welcome.
Re: What We Can Learn From Other Languages (Score:1)
I'm not sure if the first example is fair. Simple method overloading in Java or C++ is generally used for functions that can take different parameter types, which isn't an issue in Perl, or to have functions with optional parameters which again isn't much of a problem in Perl:
I think that method overloading is more tied to the fact the a language is statically typed and not necessarily something
Re: (Score:2)
Well, you say it's not much of a problem, but look at the snippet you posted:
Can $foo be 0? Your code says 'no', but that might or might not be what you meant. Also, by the time you've finished the $foo line, you no longer can easily tell whether or not you even passed an argument for $foo.
In my original example, the code might do strange things if too many arguments are passed, or if they're n
Re: (Score:1)
Some of these problems could be solved efficaciously with method overloading. Nevertheless, I still think that method overloading is mainly a necessity of static typing. Which for me is a more useful language feature and one that we have learned from since it will be included in Perl 6.
John.
--
Pop-11 / Lisp / Eiffel (Score:1)
Off the top of my head...
Pop-11: Assignment was done with the right-arrow operator.
Which has the advantage (as far as I'm concerned anyway :-) of reading naturally ("10 goes into x") and allowing us to use "=" to indicate equality as god intended, removing all of those "if x=10" type errors.
Pop-11: The "updaterof" idiom (see this example [perlmonks.org]) that gave a nice way of separating access/mutate methods.
Pop-11: direct access to the parser/compiler for the l
Why is the Smalltalk way superior? (Score:2)
I still don't understand why the Smalltalk way of ifTrue: and ifFalse: is superior to if/else. Can you please explain?
Other than that, one thing I can think of is the Scheme/SICP [mit.edu] way of handling linked lists using car, cdr, cons, and recursion. This makes the code much more robust and much less error prone than using pointer games, as is often the case in C. Funnily enough, when I wrote similar code in Common Lisp, the people on #lisp on Freenode told me that I shouldn't use recursive helper functions
minimizing control structures (Score:1)