Coding in an absurd reality

1
2
3
4
5
6
7
8
9
10

private static String joinObjectFields(final List<SomeObject> objects, final Character seperator, final SomeObject exclude) {
    StringBuilder builder = new StringBuilder();
    for (SomeObject object : objects) {
        if (object.equals(exclude)) continue;
        if (builder.length() > 0) builder.append(separator);
        builder.append(object.someField);
    }
    return builder.toString();
}
}

1
2
3
4
5
6
7
8
9

joinObjectFields(objects, seperator, exclude) {
    builder = new StringBuilder();
    for (object : objects) {
        if (object.equals(exclude)) continue;
        if (builder.length() > 0) builder.append(separator);
        builder.append(object.someField);
    }
    return builder.toString();
}

[Comment edited on Thursday 7 January 2010 16:09]

1
2
3
4
5
6
7
8

private static string joinObjectFields(List<SomeObject> objects, 
    string separator,
    SomeObject exclude)
{
    return String.Join(separator, objects
        .Where(obj => !obj.Equals(exclude))
        .Select(obj => obj.SomeField).ToArray());
}

[Comment edited on Thursday 7 January 2010 16:26]

1
2
3

def joinObjectFields(objects, seperator, exclude):
    fields = [object.someField for object in objects if object != exclude]
    return seperator.join(fields)

1

return result.substring(0, result.length() - 1);

1

return result[:-1]

[Comment edited on Thursday 7 January 2010 17:25]

1
2
3

function joinObjectFields($objects, $separator, $exclude) {
    return implode($separator, array_diff($objects, $exclude));
}

[Comment edited on Thursday 7 January 2010 17:25]

For extra hatred, consider the necessary changes to the code to enable the same method to join the contents of a different object field.

• Filtering (not processing the exclude value)
• Mapping (mapping SomeObject instances to a value that's showable)
• Folding or reducing a list of values to a single value (in this case, a String)

1
2
3
4
5
6
7

joinFields exclude field sep
 = intercalate sep . map (show . field) . filter (/= exclude)
{-       ^             ^                    ^
         |             |                  step 1, filtering
         |           step 2, mapping
       step 3, reducing the list to a single value
-}

1
2
3

-- equivalent definition without eta-reduction
joinFields exclude field sep objects
 = (intercalate sep . map (show . field) . filter (/= exclude)) objects

1

joinFields :: (Eq a, Show b) => a -> (a -> b) -> String -> [a] -> String

[Comment edited on Thursday 7 January 2010 18:07]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

FORM join_objf
    USING pt_objects TYPE ltt_someobject
          pc_separator TYPE c.
          po_exclude TYPE lt_someobject
    CHANGING ps_return TYPE string.

    DATA lo_object LIKE LINE OF pt_objects.
    
    LOOP AT pt_objects INTO lo_object.
        IF NOT lo_object = lo_exclude.
            IF ps_return IS NOT INITIAL.
                CONCATENATE ps_return
                        lo_object
                INTO ps_return SEPARATED BY pc_separator.
            ELSE.
                ps_return = lo_object.
            ENDIF.
        ENDIF.
    ENDLOOP.
ENDFORM.

[Comment edited on Thursday 7 January 2010 19:21]

The python code is a nice example of overuse of syntactic sugar in a language. Creating separate syntax for every little use case leads to this.

It's rather typical for functional languages.

May also be one of the reasons why functional languages aren't popular.

Personally I'd rather read and maintain the java code than your python code.

1

intercalate sep . map (show . field) . filter (/= exclude)

[Comment edited on Thursday 7 January 2010 20:26]

quote: RayNbow

This function takes 4 arguments, namely the value to exclude, a field selection function, a String seperator (not a character as in your original function), and finally the list containing the objects.

And to add to the language comparison:


Ruby:

1 2 3

def join_object_fields(objects, separator, exclude) objects.delete_if{|o| o == exclude }.join(separator) end

1
2
3

def join_object_fields(objects, separator, exclude)
   objects.select{|o| o != exclude }.join(separator)
end

I strongly disagree. List comprehensions are not a "little use case". Why do you think things like set-builder notation, LINQ, SQL, etc. exist? We'd like to be able to clearly and succinctly express operations over collection-like structures.

I'd classify Python as an imperative OO language with a few functional features, rather than a functional language.

Anyway, I'd like to know how you came to the conclusion that syntactic sugar is typical for functional languages? Syntactic sugar can also be found in imperative languages (e.g. string literals in C, foreach in Java, yield in C# and Python).

1
2
3

for(tpTerm <- typeOf(term);
            (from, to) <- isTArr(tpTerm);
            _ <- isEqual(from, to, "some text")) yield from

Excel is the most popular functional language.

Haskell example

[Comment edited on Thursday 7 January 2010 21:14]

>The python code is a nice example of overuse of syntactic sugar in a language. Creating
>separate syntax for every little use case leads to this.

I strongly disagree. List comprehensions are not a "little use case". Why do you think things like set-builder notation, LINQ, SQL, etc. exist? We'd like to be able to clearly and succinctly express operations over collection-like structures.

public void testJoinExclude(){
assertEquals("1, 2, 4", joinExclude(Arrays.asList(1,2,3,4), 3, ", "));
}

public <T> String joinExclude(final List<T> objects, final T exclude, final String separator){
List<T> rs = new ArrayList<T>(objects); // don't touch the original
rs.remove(exclude);
return StringUtils.join(rs, separator);
}

It may very well be easy to understand f you're used to Haskell, but at the moment, it's gibberish to me. In Python you could also write

*snip*

But then I really prefer the list comprehension . I'm not at all convinced that purely functional code, involving the usual maps, filters and reductions, is in fact usually easier to understand.

1

intercalate sep [show (field obj) | obj <- objects, obj /= exclude]

1
2
3
4
5
6
7
8
9

-- usual math notation:
(f . g)(x) = f (g(x))

-- Haskell eschews parentheses and uses 
-- juxtaposition instead for function application:
(f . g) x = f (g x)

-- (Math on the other hand eschews multiplication 
-- operators and uses juxtaposition instead)

1

(h >>> g >>> f) x

1
2

infixl 0 |>
x |> f = f x  -- NB: this pipeline operator is predefined in F#

1

x |> h >>> g >>> f

Notice the link made by "It's" in my sentence. It should be read as "overuse of syntactic sugar is typical ...". I'd like to add that by this i mean obscure syntactic sugar with all sorts of special symbols.

1
2
3
4
5
6
7
8
9

-- Syntactic sugar         Desugared
----------------------------------------------
[1,2,3,4]             =    1:(2:(3:(4:[])))
[1..4]                =    enumFromTo 1 4
[1..]                 =    enumFrom 1

(+4)                  =    (\x -> x+4)
(4+)                  =    (\x -> 4+x)
-- (NB: the slash stands for lambda)

1
2
3
4
5
6
7

var foo = from n in ns 
          from m in ms 
          select n + m; 

// is equivalent to:
var foo = ns.SelectMany(n => ms, 
    (n, m) => n + m);

For example this scala code:

*snip*

Add any more syntactic sugar and your language starts to resemble Brainfuck.

Name the most popular languages of recent decennium/decennia:
C
C++
Java
C#
(and even older stuff that has to be maintained, can be ignored further)
See what they have in common?

The C-like syntax amongst other things. Ever noticed how the C-like syntax is easy to read?

It's almost English.

Try to read functional languages (or the parts of other languages with functional features) out loud: you'll understand what i mean.

1

[show (field obj) | obj <- objects, obj /= exclude]

You are well aware of the fact that this is ridiculous. 99% of the functions in Excel is just basic math and doesn't even come close to what a functional programming language does differently from imp languages. A3 = A2 * 5/9 works in a non-functional imp language as well.

Give people a course in Java and Haskell and show them that code and the java equivalent. Have a guess which version will be understood faster. I am willing to bet plenty of money on java.

1

intercalate x = concat . intersperse x

1

concat . intersperse sep . map (show . field) . filter (/= exclude)

Don't worry: closures are coming in Java 7.