Hacker News Reader

Comment by lou1306 | Hacker News Reader

I agree that overcomplicating code is bad, but then again, what is "simplistic"?

Let's talk Python. To me, using comprehensions is way simpler than loops. Using

  for i, item in enumerate(my_list):
    # do some stuff with i and item

is way simpler than

  for i in range(len(my_list)):
    # do some stuff with i and my_list[i]

And still, I bet that most C/Java folks will look at these things with disdain.

Also, higher-order functions. They do sound strange, at first. And yet they're a great tool to combine simple pieces of code. I'm starting to think that "elegance" is just the ability to build complex interactions of simple elements. Think chess, or languages like Lisp and Smalltalk, or Euler's identity.

View on HN

You probably want to use the conceptually simplest construct your language / standard library offers. In Python that's enumerate. In C, that'd be the standard for loop. In Java that'd be the enhanced for loop. People reading your code, familiar with the language, should have to learn as little as possible to understand it.

I could make an awful enumerate implementation in C:

    #define enumerate(item, array) for (int i = 0; i < sizeof(array)/sizeof(array[0]); i++) { item = array[i];
    #define enumerate_end }
    ...
    enumerate(int number, numbers)
        printf("Number is %i\n", number);
    enumerate_end

...But then everyone reading it would have to go read my enumerate definition, whereas they'd understand the regular for loop immediately.

I think higher-order functions are a great tool when they're used to remove complexity. The tricky part is that your reader needs to already understand how they work. If adding the definition of a higher-order function would make your code longer than simply not using it, I think it's a bad case to use it.

The first is Pythonic code. I'm guessing the author isn't talking about conventional code, but a more agnostic point of creating complexity for complexity sake, which, unfortunately, is a very common issue.

The other way can also be a problem. If you are manually writing out range(len(stuff)) in Python on all your loops, you are writing code that is complicated, overly verbose, difficult to understand, and error-prone.

Actually I don't think he was successfully making that agnostic point.

It's more like: don't gold plate it, and don't use abstractions that you learnt later.

Not gold plating things seems obvious. I think there's a TDD advocate who has an example of when he created a wiki that stored its data in a text file. Purely by accident. But it worked perfectly for his use case; he didn't actually need to fire up the latest distributed NoSql blah blah blah. And perhaps that's something worth considering.

Not using abstractions learnt later in life tho. I think that's a problem. It took me years of contorting my head to fit in some of the customary Haskell abstractions like monads and functors. Today I probably couldn't describe them accurately, but I'm sure I benefit from when I think in terms of them. For instance, it seems that the code is better if I write a method which accepts an object then does something, vs writing a method which might accept an object, then tests for null, and if not null it does something. (And similarly for looping constructions for instance. You write a more superficial level of code that knows about nulls or arrays and a deeper level of code which doesn't. Directly thinking "monad" literally helps me here.) It's simpler, but it's not at all more simplistic.

And so at this point, I want to distinguish between complex/complicated and simple/simplistic. Things which are complicated or simplistic are bad because they're simpler or more complex than they should be. Things which are complex or simple are inevitable and complaining about them is unproductive, like complaining about the weather.

Counter: This is what incrementally leads to voodoo Perl scripts that only the one magician who wrote it can read. Sure all those tools are great individually. But nobody else knows what they are, so maintaining it is impossible.

In a trivial example like this, between two similar executions, I'd tend toward the C-like one for readability. Only use the language feature if it really saves a lot of lines or abstractions etc.

So java8 if I could rewrite 100 lines of code so that a whole function is just one lambda and nothing else, sure go for it. That's just a StackOverflow away for anyone. But I wouldn't toss in a lambda with a bunch of (insert new language feature) all on one line. I wouldn't expect another programmer to know all that yet.

For me, any talk about what is the best way to loop over or enumerate an array is not the most helpfull in talk about code simplicity. Using a loop, an enumeration, or a functional map, should not really matter that much, most of the time they all do similar things. I would think that any intermediate programmer recognizes them. Thinking too much about which is better, is just loosing time better spend elsewhere.

Reply on news.ycombinator.com