nosewheelie

Technology, mountain biking, politics & music.

Archive for the ‘Languages’ Category

Nobody *ever* uses map, et. al… (example 3)

without comments

Continuing my nobody *ever* uses series, here’s a Java example.

Consider the following horrible piece of Java code taken from Instinct which finds specifications to run:

private Collection<LifecycleMethod> findMethods(final MarkingScheme markingScheme) {
    final Collection<LifecycleMethod> lifecycleMethodSet = new HashSet<LifecycleMethod>();
    final Collection<Method> methods = methodLocator.locateAll(contextType, markingScheme);
    for (final Method method : methods) {
        lifecycleMethodSet.add(new LifecycleMethodImpl(method, contextType));
    }
    return lifecycleMethodSet;
}

Here’s the same method rewritten using Functional Java, with the conversion function pulled out for clarity:

private Collection<LifecycleMethod> findMethods(final MarkingScheme markingScheme) {
    final F<Method, LifecycleMethod> conversion = new F<Method, LifecycleMethod>() {
        public LifecycleMethod f(final Method a) {
            return new LifecycleMethodImpl(a, contextType);
        }
    };
    final Collection<Method> methods = methodLocator.locateAll(contextType, markingScheme);
    return toFjList(methods).map(conversion).toCollection();
}

The good thing about the above is it expresses succinctly what we’re doing; find the methods we’re interested in and map across them to convert them into another type. The unfortunate things are that we have to convert from a Java collection to a FJ collection (toFjList) and we need to use the clunky Java anonymous inner class as a pseudo first class function.

For comparison, here’s a rough stab (i.e. probably won’t compile) at what it’d look like in Scala, notice that implicits will take care of the conversion for us:

def findMethods(markingScheme: MarkingScheme) =
  methodLocator.locateAll(contextType, markingScheme).map(new LifecycleMethodImpl(_, contextType))

Now isn’t that better?

Written by Tom Adams

July 21st, 2008 at 2:11 pm

Nobody *ever* uses map, et. al… (example 2)

with 2 comments

Today’s Nobody *ever* uses post.

require "netaddr.rb"
CIDR_ADDRESSES = ["192.0.2.1/24", "..."].map {|address| NetAddr::CIDR.create(address)}
in_range = CIDR_ADDRESSES.any? {|address| address.contains?("192.0.2.1")}

But of course nobody ever does this…

Written by Tom Adams

July 8th, 2008 at 11:04 am

Posted in Functional,Languages,Ruby

Tagged with ,

Nobody *ever* uses map, et. al… (example 1)

with 4 comments

Inspired by Daniel’s comment on Tony’s blog, I figured I’d start documenting the times I use “functional” constructs in my everyday work.

Consider this piece of XML, returned from an external web service:

<suggestions>
  <suggestion>
    <suggestion>paddington, NSW</suggestion>
    <location>true</location>
  </suggestion>
  <suggestion>
    <suggestion>paddington, QLD</suggestion>
    <location>true</location>
  </suggestion>
</suggestions>

Perform the following:

  1. Parse out each suggestion, turn it into an instance of Suggestion;
  2. Capitalise the first letter;
  3. Sort by name;
  4. Remove duplicates;

Here’s some Ruby code that does this, parsing by Hpricot:

class SuggestionsParser
  def self.parse(node)
    suggestions = node.search("//suggestions/suggestion").map do |s|
      Suggestion.new(s.at("suggestion").inner_text.capitalise_first_letter, s.at("location").inner_text == "true")
    end
    suggestions.sort.uniq
  end
end

But of course nobody ever does this…

Written by Tom Adams

July 2nd, 2008 at 2:14 pm

Posted in Functional,Languages,Ruby

Tagged with , , ,

A debate about type systems

with one comment

Jay Fields (someone whose comments I’ve come to respect) ignites yet another debate about type systems in Static typing considered harmful.

Given a good test suite the return on investment simply does not justify the use of static typing.

In 5 years, we’ll view compilation as the weakest form of unit testing. — Stuart Halloway

Type verification provides very little confidence that an application works. The little confidence it does provide comes at the cost of being confined by the type system. Verifying types is better than testing nothing at all. But, only verifying types is insufficient for application development.

Now I don’t know a great deal about type systems [1], but I know enough to know that the arguments going around appear to have been formed without knowing a great deal about type theory and what a good type system can do (I’ve heard it called arguing in a bubble).

Phillip Calçado takes it further in Static Types for Long Feedback Cycles?, noting that there has been a debate amongst ThoughtWorkers about this issue. I feel that Phillip also draws some invalid conclusions, such as asserting that a type system cannot ensure that a class fulfils its contract [2]. One of his commentors, David, makes the same comments that I’m making, that a lot of this debate stems from a lack of knowledge about what a type system actually is, talking about more advanced type systems that those we may be used to in our day jobs:

Of course I’m not talking about shonky rubbish like Java or C#’s type system but rather languages which have Hindley-Milner style type systems with inference like Haskell, ML and what not.

For a more reasoned post about this see Ricky Clarkson’s Stop Sitting On The Type Fence. The post is getting a bit old now, and Ricky’s been active in the Scala community, so I’m not sure if he still holds all these views.

My take on all this is that it’s possible to have your cake (static typing) and eat it too (all the goodness that dynamically typed languages provide). To take Scala as an example (Haskell would be better, but my knowledge of it is limited), you get static typing with type inferencing (albeit moderately weak ATM), so a lot of boilerplate goes away. You also get flexibility in the language, so you can write funky DSL style code till your heart’s content. The only thing you don’t have in Scala (as compared to Ruby) is decent metaprogramming, though I’m told there’s work in progress on this front.

For those that want to explore this a bit more, see What To Know Before Debating Type Systems and Types and Programming Languages.

[1] I know enough about type systems to be dangerous.
[2] Actually this is probably technically true, you’d need a theorem prover to do this, and potential need to solve the halting problem, but, we can get closer in practice than say Java’s type system.

Written by Tom Adams

February 7th, 2008 at 1:53 pm

Posted in Languages

Is your IDE tilting at the dynamic language windmill?

without comments

Quite a few programmers love having powerful IDEs. These IDEs perform certain simple refactorings somewhat automatically, they can take a compiled language and make it seem a little more like an interpreted language, they can find certain types of errors as you type…

In short, they do a lot of drudge work on the programmer’s behalf. What’s not to like about this? Nothing. These are useful tools. I have been working with Eclipse lately when editing Java, although I really don’t care one way or another. I like what it does but I’m fundamentally indifferent to its existence.

I find that IDEs are nice, but even the most sophisticated IDEs are… static. They make one-time changes to code. I’m far more interested in languages that let me write code that writes code, in languages that let me write code that doesn’t need a lot of rewriting and fixing across the board when I make a change. (This is just my perspective. I’m still learning a lot about the intersection between theory and practice in programming languages.)

But this is why you’re tilting at windmills when you ask me why I don’t eschew Ruby for Java just so I can “rename class.”

Source: Is your IDE tilting at the dynamic language windmill?.

Written by Tom Adams

October 26th, 2006 at 8:26 pm

Posted in Java,Languages,Ruby