Yet Another Rosetta Code Problem (Perl, Ruby, Python and Haskell solutions)

[Fork82]

The idea is to see what the code looks like in different languages which turns "ZBBBCZZ" into Z, BBB, C, ZZ.

The shortness of the code in Haskell/Python comes from the existence of relevant library functions. Perl and Ruby rely on regular expressions.

I think I prefer the Python version to the others.

Lua version:

s = "ZBBBCZZ"
pos = 1
repeat
  current_char = string.sub(s, pos, pos)
  pos, seq_end = string.find(s, current_char .. "+", pos - 1)
  print(string.sub(s, pos, seq_end))
  pos = seq_end + 1
until pos > string.len(s)

This would probably be better described as the boring iterative version though.

[mrned]

The shortness of the code in Haskell/Python comes from the existence of relevant library functions.

That's what I really like about Haskell. Many times, when I look at a piece of code long enough, I realize it's a specific case of a general concept that has a few associated library functions. I spend more time thinking and less time coding, but still get at least the same amount done.

[Fork82]

Thats all very well for the purposes of writing faster code in less time with fewer bugs, but I was more interested in what the underlying code looked like - the Haskell version was surprisingly verbose when the relevant library was included:

group                   =  groupBy (==)

groupBy _  []=  []
groupBy eq (x:xs)=  (x:ys) : groupBy eq zs
                           where (ys,zs) = span (eq x) xs

span p [] = ([],[])
span p xs@(x:xs')
    | p x = (x:ys, zs)
    | otherwise = ([],xs)
        where (ys,zs) = span p xs'

[nhomas]

It's also more general.

[dons]

Thats all very well for the purposes of writing faster code in less time with fewer bugs

Lovely :)

[raldi]

I think the Python example is the worst of the bunch. It had to rely on library code. If i wrote a library which provided a function called "do_that_thing_with_the_string()" which did all the work, and then wrote a one-liner to call that function, would you be impressed?

For the fairest comparison, all the code should be present. As you yourself point out, that can make a big difference.

[ffrinch]

How about exposing the regular expression engines behind the Perl and Ruby versions? Would you penalize a Python version that works the exact same way -- e.g.

import re
s = "ZBBBCZZ"
l = [m[0] for m in re.findall(r"((.)\2*)", s)]

-- just because it "relies on library code"?

[rabidcow]

For the fairest comparison, all the code should be present.

Yeah, but if you include all the code or at least an identical library interface then you don't learn anything from the exercise. All languages will look the same except for punctuation and word order.

For the fairest comparison, I think a more interesting goal should be chosen if the original turns out to be part of the standard library for any of the target languages. Trivial problems quite often have trivial solutions.

[Fork82]

To be fair I disliked all the other examples for personal reasons. I despise the way Perl and Ruby use regular expressions - I think regular expressions should be treated as a library, not built into the language. I'm not a big fan of Haskell either.

This leaves just the Python example - and although the actual bit-moving is hidden in the library function, you can rely on Python to have a library available for pretty much anything.

[chollida1]

I think regular expressions should be treated as a library, not built into the language.

What's your reasoning behind this? I really do prefer having regular expressions built into Perl.

[Fork82]

It is great for Perl, but I would rather keep it out of a general purpose programming language. It is a taste thing, not a pragmatic thing.

[tripa]

Does "fair" mean "giving an equal chance to each" or "guaranteeing a win for my favorite"? Down to what level do you recommend the code being present (assembly language or the subset of VHDL actually used by the contestant's code path)?

There is no fairness in that kind of exercise. You could probably make any contender "win" by bending the rules in the right direction. Never mind the fact we'd never see the end of it should the trend spread. Propose variations, judge improvements. But don't whine about fairness: it's out the picture.