11

There's something that has been bothering me for some time about the response to some answers here on Ask Ubuntu, and came to my attention again on this post. My answer, while working and achieving desired results, has been critiqued because it's apparently "cryptic" and "lengthy".

I've consulted the help page and here what is says (emphasis added):

Read the question carefully. What, specifically, is the question asking for? Make sure your answer provides that – or a viable alternative. The answer can be “don’t do that”, but it should also include “try this instead”. Any answer that gets the asker going in the right direction is helpful, but do try to mention any limitations, assumptions or simplifications in your answer. Brevity is acceptable, but fuller explanations are better.

In other words, an answer should be solving a problem and adding value, while brevity is only icing on the cake. Thus, I would like to know what the community thinks. Does length of a solution matter? What is the limit to which we define "cryptic" answers?

I don't necessarily seek a "solution" but I do want to see what the community thinks on this matter.


My view on the matter

While I do admire brevity of certain answers, I don't see a valid reason to critique a working solution based on the length. "Cryptic" is also a very abstract concept. A regular expression can be cryptic to someone who has never touched Perl or sed, while completely obvious to a seasoned professional.

The opposite is also true: an explicit solution can be confusing and obscure for someone unfamiliar with the language used in the answer, the algorithm, or the idea of the approach. What's more confusing to me is the "cryptic" being used where answer has explanations of the concept and details of an answer.

But in either case, I don't see how length and "cryptic-ness" are related to actually getting the job done and delivering value to OP. Discussing merits of approach, suggesting improvements, and suggesting more idiomatic approaches is fine, but automatically dismissing an answer for being less pretty than something else seems entirely wrong.

Regular users of Code Golf site will recognize that there are often really illegible, but short answers. And Code Golf is specifically aimed at that - shortest amount of bytes wins. But it's not how our site is supposed to work. Or is it ?

  • I agree with what I think you are saying, but could you clarify? Are you talking about code (eg sed wins golf but python is readable) or about the whole answer (Elian Kagan vs Gunnar Hjalmarsson)? – Zanna May 21 '17 at 5:47
  • @Zanna yes, I'm talking about code, not the answer body ( that could be spinned off into a separate topic itself ). – Sergiy Kolodyazhnyy May 21 '17 at 5:53
  • 1
    Maybe I should have made the ;-) more bold, but I wasn't seriously criticizing your answer in my comment. I just put my surprise in words about you presenting a command of about twice the length the others were and claimed that awk would be easier to use here than sed. You had my upvote anyway. – Byte Commander May 21 '17 at 11:19
  • Brevity is good. If you can answer in two paragraphs, don't write 15 paragraphs. If you can write good code in 10 Python lines, don't write 40 C++ classes just because you like seeing the STD lib slow down all the things. But legibility is extremely important. If your code of 10 lines is readable to people other than yourself then it's great. If you cut it down to 7 lines of write-only code then it's bad. – Andrea Lazzarotto May 25 '17 at 15:05
  • (Actually, I'm wondering if I should turn my comment into an answer... but you know, it's quite brief... :P) – Andrea Lazzarotto May 25 '17 at 15:07
13

Every case is different but broadly speaking I tend to like and upvote answers I can understand and test or verify myself. Clarity and not brevity is what I care about, because ease of understanding increases helpfulness. Often, though not always, clarity and brevity go together. Cryptic is in the mind of the beholder... but there are often worse ways and better ways to approach the same problem with regard to factors like resource efficiency, maintainability, security and so on. Everyone knows cat file | grep foo is worse than grep foo file - why call two programs when you can call one? On the other hand, sometimes adding complexity adds value, and multiple solutions clearly explained have great value for future reference. A Stack Exchange answer is not just for the OP.

Often, the longer the answer is, depending on the language, the more effort the reader (depending on her background) has to put in to understand the code. Add to this that active users are possibly more likely to be familiar with basic command line utilities like sed than scripting languages like Ruby, and I guess it adds up to another reason why shorter answers tend to get more upvotes: scarcity of time and energy.

Voting is up to the voter. Everyone has their preferences, and as the comments about 'pythonicness' on the answer of Jacob Vljim's you linked to suggest, in a community of people using the same tools, preferences are all the stronger! The preference for simplicity and "elegance" in the STEM world and beyond is unlikely to change any time soon...

  • 3
    This is a great answer! – Pilot6 May 21 '17 at 8:56
8

I'm a bit biased. Along with a number of other users, I really cut my teeth here on questions, with a like for the really complicated scripting exercises.

I can see your point, but I have some of my own...

  • They answer a question, fix a problem. "13/10 They're all good answers, bront."
  • Some of this stuff is really educational. I know there's also a lot of repetition but I've learned techniques from people, and taught myself quite a few tools just to answer this stuff.
  • Showing everybody that that you're the cleverest sausage in the pack is fun.
    Fun means people stick around. This is something we want to foster more than chase off.
  • Occasionally, doing things in different ways makes a huge difference. Here's the best example I can think of (even if it is on Unix.SE). Performance matters if you're processing tons of input so I worked through everybody else's answers and added a few of my own to find the very best way of executing the answer. It also spawned a blog post where somebody essentially taught me all about buffering in C for high performance.

    So I would completely defend the use of a Python script, even for something small like that. Python performs really well at a load of stuff and is still eminently legible (unlike C, and C++). It's also a lot easier to unpick and adapt for other people.

I think there's one key difference between these sorts of questions and code-golf: somebody comes here with a real problem... We just get carried away answering it. I think that's okay but, I can see why it might seem like an excess to somebody with no interest in it.

  • 1
    Such a good point; fun really matters :) – Zanna May 22 '17 at 20:26
5

In my opinion, brevity (or shortness of the answer) isn't an important thing for Ask Ubuntu, rather it's harmful for sites like this. Ask Ubuntu generally is a support site for users of Ubuntu, many of whom are completely newbies. So answers should be as explicit and elaborated as they can be (without crossing the border of becoming boring)

I usually try to tailor my answer according to the OP's experience/expertise level. But generally try to make it suitable for the majority user's level.

Ubuntu is considered one of the most user friendly desktop distributions of Linux, and in fact it's Ubuntu that made the Linux desktop friendly. So, we should try to maintain that characteristic.

In short, I consider understandability of an answer is far more important than cleverness or length. I prefer Clarity over Cleverness

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .