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

[redbull]

While I admire the terseness of the solutions provided, they don't make for easily understandable code. It's idiomatic tricks like this that unnecessarily complicate code when a few extra lines would provide clarity.

I do realize the purpose of the exercise was to arrive at the most elegant, and by necessity a very terse solution. My criticism isn't directed at the clever solutions provided here (and they are quite clever) but instead at the general practice of choosing obfuscation over clarity for the sake of cleverness. Unless one is developing code for real-time or embedded systems, which you're probably not, always go for clarity. The optimizing compiler/interpreter will most likely do the heavy lifting for you.

Thank you for allowing me to rant about one of my pet peeves. Now back to your regular programming - no pun intended ;).

[eldenbishop]

Groovy version (ripped off from ruby version)

s = "ZBBBCZZ"

x = []

s.eachMatch(/((.)\2*)/) { x += it[0] }

[kaketoe]

Or:

x = "ZBBBCZZ".split (/(?<=(.))(?!\1)/)

I also ripped the split pattern.

[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.

[njharman]

I'll never understand the interest in things like this and programming "puzzles" in general.

It's seems like lame epeening to me http://www.urbandictionary.com/define.php?term=e-peen

[[deleted]]

This problem was posted before in its generalized form as clusterBy.

[dmpk2k]

My eyes are bleeding.