Hacker News Reader

Comment by stcredzero | Hacker News Reader

As it turned out, more flexibility led to devs writing code that others actually struggled to understand.

This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging.

"Clever" should be regarded as a limited resource. Also, the shop should encourage a culture where "clever" with regards to making code easier to understand should be valued above all else.

View on HN

This (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD.

EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]:

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in less symbols?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. "

[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...

I think it is interesting that you left out the very next few sentences, which provide very relevant context:

"I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque."

While I agree with the general sentiment, it's very important to take anything Dijkstra says with a huge grain of salt. He was a mathematician first and foremost. He obsessed about things like a mathematician. Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.

I agree with Dijkstra, the looping constructs of FORTRAN's DO and ALGOL 60 were too baroque. Dijkstra's comments were written in 1977, at that time FORTRAN IV and ALGOL 60's loop semantics were a mess and were common sources of errors.

Without qualification, Dijkstra was one of the greatest computer scientists in our field's short history. While I don't agree with every single one of his ideas, I would encourage budding computer scientists and professional programmers to look over what he accomplished. He most certainly was not unproductive.

Wikipedia says that Dijkstra is known for:

- Dijkstra's algorithm (single-source shortest path problem)

- DJP algorithm (minimum spanning tree problem)

- First implementation of ALGOL 60 compiler

- Structured analysis

- Structured programming - Semaphore

- Layered approach to operating system design

- T.H.E. multiprogramming system (one of the first operating systems)

- Concept of levels of abstraction

- Concept of layered structure in software architecture (layered architecture)

- Concept of cooperating sequential processes

- Concept of program families

- Multithreaded programming

- Concurrent programming

- Concurrent algorithms

- Principles of distributed computing

- Distributed algorithms

- Synchronization primitive

- Mutual exclusion

- Critical section

- Generalization of Dekker's algorithm

- Tri-color marking algorithm

- Call stack

- Fault-tolerant systems

- Self-stabilizing distributed systems

- Resource starvation

- Deadly embrace

- Deadlock prevention algorithms

- Shunting-yard algorithm

- Banker's algorithm

- Dining philosophers problem

- Sleeping barber problem

- Producer–consumer problem (bounded buffer problem)

- Dutch national flag problem

- Predicate transformer semantics

- Guarded Command Language

- Weakest precondition calculus

- Unbounded nondeterminism

- Dijkstra-Scholten algorithm

- Smoothsort

- Separation of concerns

- Program verification

- Program derivation

- Software crisis

- Software architecture

This quote by galactipony is really offensive to me:

> Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.

It is quite clear to me that Dijkstra wasn't "just talking out of [his] ass."

Learn more about Dijkstra at https://en.wikipedia.org/wiki/Edsger_W._Dijkstra or in any resource on the history of Computer Science.

I know about Dijkstra.

I didn't say Dijkstra was talking out of his ass in this case. I'm saying you often can't tell when people like him are talking out of their ass, as they sometimes do. Who would think the inventor of all these algorithms would ever utter a half-formed thought, on a whim? Unthinkable! Yeah... no.

Another distinction you fail to see is that somebody who is great at finding the best or optimal algorithms (i.e. a great theorist) isn't necessarily a productive programmer. To the contrary, perfectionism and productivity are at great odds.

Dijkstra was heavily at odds with real-world programming as it was done, to the point of isolating himself with his work. If we followed his opinions on how to program, we wouldn't get much of anything done.

> Another distinction you fail to see is that somebody who is great at finding the best or optimal algorithms (i.e. a great theorist) isn't necessarily a productive programmer.

I suppose what you're saying here is that there are a lot of business tasks which don't require a great theorist.

I don't think Dijkstra would disagree.

But still, calling Dijkstra an "unproductive programmer"? Really? I'll take one Dijkstra's algorithm over a dozen web apps. And if I can have a patent on it, I can even make a solid business case for that choice.

> If we followed his opinions on how to program, we wouldn't get much of anything done.

And yet, how many man-years of engineering effort could we waste having bad theorists who can quickly hack out LoB code try to re-invent Dijkstra's algorithm?

Perhaps software engineering is a very wide field, and it takes all types?

> To the contrary, perfectionism and productivity are at great odds.

I've learned this the hard way in my career. I always have to fight against taking the extra 20 hours to perfect something when it only took me 1 hour to get to 95% and 95% is more than good enough for the particular task.

I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks.

But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an iterative process. To me it seems Dijkstra specifically aims for languages such as LISP (which, with the renewed interest from Clojure is one of the most oldest successful (semi-) functional programming languages).

"I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks."

It still seems intellectually dishonest to leave it out. Clearly, what Dijkstra in 1972 considers too "clever" may in fact be tools that are now basic building blocks of everyday software. We can all agree that "too clever" is bad. We can't agree on what "too clever" is.

"But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an iterative process."

I'm fairly sure (from what I remember him writing) that he doesn't like it because you can do the same thing with existing constructs, so you'd be adding complexity to the language that isn't strictly necessary. History has shown that actual programmers prefer having for loops like Algol.

"To me it seems Dijkstra specifically aims for languages such as LISP (which, with the renewed interest from Clojure is one of the most oldest successful (semi-) functional programming languages)."

Probably not, or else he would've talked about LISP in a different manner (he does talk about it in an earlier paragraph).

"Programmers prefer loops like Algol":

Yes, programmers prefer it, but the general structure:

`for (init-statement ; boolean-continuation-expression ; iteration-statement) statement;` is syntactic sugar for a specific imperative process (with the iteration and ending expression appended at the end of the block). It does not generalize to other imperative processes, it cannot be transformed into a meaningful expression and it invites 'clever' programmers to do 'too much' in the various for-clauses.

Wrt to LISP, do you mean this part? That seems to align well with my standpoint: use very few basic principles and be stable.

"The third project I would not like to leave unmentioned is LISP, a fascinating enterprise of a completely different nature. With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts."

> We can all agree that "too clever" is bad. We can't agree on what "too clever" is.

Of course we agree. Too clever is "stuff I'm too lazy to understand". What we don't agree is on the definition of I; everyone has their own binding for that symbol, which carries a context for different types of stuff we are too lazy to understand.

Interesting take. 'Too clever' for me is: 'using underlying concepts which have semantics that have a poor mental overhead versus applicability within the domain'.

My working definition of "too clever" is:

If you have to spend time explaining 'what' the code is doing, it is "too clever".

If you have to spend time explaining 'why' the code is doing something.. then "them's the breaks working in a complicated world".

Code should only be as complex as the problem domain.

We can't agree on what "too clever" is.

It's not absolute. It's something to be negotiated at a particular shop.

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras."

-- Alan Kay, The Computer Revolution hasn't happend yet — 1997 OOPSLA Keynote

Could you explain how exactly this quote is applicable to Dijkstra's quote? Which part do you think is arrogant?

Alan seems to make an overly broad statement, which is funny, but also weak.

Correct me if I'm wrong, but was Dijkstra not known for never actually using a computer. He wrote code with pencil and paper. There's a gulf between academic code and the needs of the day to day programmer. That said, I agree with his statement about one liners. Code should be parsimonious. It should never be a puzzle to understand what the code is doing.

I hereby correct you. You are wrong.

Dijkstra decided to program using pencil and paper much later, and mostly because he (like most good programmers) already knew the solution before writing it down.

I correct you again for implying he wrote purely academic code. This is plainly false: for example, he specified part of and implemented the compiler of the Algol-77 language. He implemented one of the first multi-layer (ring-based) OSes.

And then you mention the day-to-day programmer is not in need of academic code. To the contrary! Dijkstra argued that the software crisis (the gap between what computers can do, and what they are actually doing) is caused because day-to-day programmers do not have the right tools and knowledge at hand. In EWD 340, Dijkstra argues this is caused by the mental overhead caused by clever tricks and languages allowing these tricks.

As a professional, I am constantly relating to concepts and code which have an academic basis. Examples are from type theory, lambda calculus, paxos, map-reduce, queueing theory, compression algorithms and many more. I have seen many programming languages, wrote assemblers, interpreters and compilers, worked professionally with imperative, OOP, functional and (higher-order) logical languages, so I dare to say that programming is not about what you can do with the language, but what the language does with you.

While this may have a lot of truth to it, the ironic thing here is you are posting this in response to a Dijkstra quote urging us down the path of humility.

Humility sometimes isn't, as currently discussed in https://news.ycombinator.com/item?id=13480255.

Tricks are fun- little puzzles. But they don't belong in code unless they both (1) significantly (relative you the task) save time and/or resources and (2) are very well explained in comments- like the full non-clever version being left in the code.

I know I'm preaching to the choir here. I know we've all come back to our own code six months later and had to puzzle it out.

Good advice.

More on cleverness from an old AI textbook (Artificial Intelligence Programming by Charniak, Riesbeck and McDermott):

"1.12.5 Cleverness

Avoid it . Clever tricks ... [Lisp specific stuff omitted.]

To paraphrase Samuel Johnson, we advise you to look over your code very carefully, and whenever you find a part that you think is particularly fine, strike it out."

Agreed, but they also complained about map() and flatMap(). I have to think that eventually every developer can understand the more straightforward monads, functors, and Either - which, along with type aliases, IMO, can make code a lot more readable.

I think the more esoteric features should be reserved for complex code, especially if it's possible that those features can prove runtime correctness at compile time and result in easily-composable modules. I wouldn't expect more than one or two developers to need to develop such a subsystem, however, so the "clever" is used in isolation.

The full comment is actually:

> No map, no flatMap, no fold, no generics, no inheritance… Do we miss them? Perhaps we did, for about two weeks.

So they weren't complaining about map and flatMap, they just missed them.

They only missed these features for 2 weeks?

Good for them! Their problem domain is likely so simple and neat that it fits the Go's limited built-in types well, and does not lead to frequent copy-paste programming. If so, Scala has been an overkill.

Lucky bunch indeed. I'm 9 months in and still missing map(), flatMap(), let alone more advanced FP. I guess this is a matter of personal preference, but I definitely consider:

  users.filter(_.active).map(_.email)

to be easier to read (and not a pain in the ass to type) than:

  emails := make([]string, 0)
  for _, u := range users {
    if u.active {
      emails = append(emails, u.email)
    }
  }
  return email

The first style is more explicit about what you want to do, the second style is more explicit about how you want to do it. Go made imperative vogue again, but for me it feels like a throwback all the way to Turbo Pascal. Sure, the Go compiler is really fast, but Turbo Pascal would beat it hands down - on 20Mhz machines with 1MB of RAM.

> Sure, the Go compiler is really fast, but Turbo Pascal would beat it hands down - on 20Mhz machines with 1MB of RAM.

With more features (TP 7)!

completely agree. There is a certain beauty to the first version that once you've learned the concepts it seems a shame to have to write the second one.

The second example is vastly more readable in terms of understanding what it is supposed to do.

I mention this as neither a programmer on either Scala nor Go.

If it is of any relevance, I've been writing code for about 20 years across C, Java, Javascript, PHP and shell scripts. I'm sure other FP developers will roll their eyes to a traditional developer like me but the one-liner you mention is simply not self-explanatory for an outsider when reading it.

"I've been speaking italian, french and spanish for 20 years. I'm sure people who speak germanic languages will roll their eyes to a traditional latin-languages guy like me, but the german sentence you mention is simply not self-explanatory for an outsider when reading it."

The second one is so readable it contains a subtle bug nobody noticed.

What 'subtle' bug ?

It returns 'email' instead of 'emails' which I assume was a typo, which of course the compiler would complain about, are you claiming that a variable name typo is somehow a 'subtle bug' ?

Only other thing I see directly is that 'users' is undefined, but this is a code snippet after all, not a working program.

I think kaoD's point is that more code will always produce more errors, and more code (in the name of "readability") can give more surface area for bugs.

But that would be caught by the compiler. The error would be variable not defined.

Out of curiosity, what specifically do you find unreadable about the first example?

As simple as a distributed, horizontally scalable SQL database, perhaps? (https://github.com/cockroachdb/cockroach).

Those dumb Go programmers and their toy programs (https://quicknotes.io/n/1XB0).

I program since the mid-80's, many of the features in modern languages weren't always available outside research institute walls, and yet we managed to deliver any sort of software with the tools we had at our disposal.

However, now that those features are part of the majority of mainstream languages, I surely don't want to go back to how I used to write software in the first two decades of my career.

Developers have been using C and a bunch of other imperative languages for years. They obviously, created software two order magnitudes more complex than CockroachDB (or Docker, or Kubernetes, or etcd). We used to write entire operating systems in assembly, heavens forbid. Just look at the PostgreSQL codebase (all C) and compare that to cockroach DB.

Being "a better C" was the original battle cry of Go. It's definitely better than C (well, at least for some thing), but it doesn't mean all of these complex C software people used to write are toys.

Go is obviously not a useless toy language either. But that doesn't mean you won't miss features from more expressive languages. The amount of calls for generics from Go users tell a different story.

> The amount of calls for generics from Go users tell a different story

I think it is from Non-Go users who would use Go if only it had generics.

Some of it, probably. But some are probably using Go out of necessity (your company enforces Go), or because they still think Go is their best pragmatic option, lack of generics notwithstanding.

I do competitive programming using Go and sorely miss "generics" so I'm pretty sure that your thought is not entirely correct.

Software can be complex without having very complex types

The guys who wrote CockroachDB never, afaik, tried to write it in Scala, and never told us whether they miss flatMap, generics, or something like that.

They guys from Movio did; their problem domain is likely different.

A for-each loop is only slightly longer, more familiar (just about every language has it), and more flexible - it covers map, flatMap, and reduce. So why have three or more specialized constructs when one will do?

There are cases when the restrictions of map() and reduce() are necessary, most famously for a map-reduce in distributed programming, but that's not really relevant for implementing a simple function.

Map, fold, reduce and friends are statements of intent, and reading a line of transformations composed on multiple maps and such is generally much clearer than reading a series of loops in which you have to figure out intent by looking and what's going on inside each loop.

Also, error density is relatively constant per line of code according to most studies (this is a very general statement, but we can assume that most code just isn't trying to be clever). I've forgotten to add(), append() and drop items inside a loop far more than I've made mistakes inside more functional methods.

I would argue that for loops are imperative, map/fold/etc are more declarative. That leads to various benefits such as less code, fewer bugs, fewer off-by-one errors.

And, man, tail recursion in a language with function head pattern matching (ML family, Erlang) is so much easier to read than any complicated for loop.

(Update: realized afterwards that "foreach" isn't quite the same as "for", but the larger point still stands, mostly.)

No it doesn't, because map, flatMap, and reduce can be lazy, distributed across local processors, or even the network.

They describe the intent of what to do with the data, not how it is done.

Just like using SQL versus an old xBase database to access data records.

And a goto statement is even more general, covering all kinds of looping constructs, exceptions and even the eliminating the need for functions! Why not just use those?

For loops are yet another of these useless abstractions introduced by the academia, this time straight from the design-by-committee language ALGOL 60.

We all know real programmers used gotos.

Technically, reduce covers map, flatmap, filter, etc. It's every bit as flexible as a for-each loop (the only difference is it implies no side effects, but does not guarantee them if the language doesn't).

The very reason those other functional constructs were split out was not due to need, but due to -clarity-. And that same clarity applies to why to use one of those constructs instead of a for-each loop.

The problem with for-each in a lot of languages is that it's a statement, not an expression, so it only works with mutable data.

I'm definitely in camp map/filter/fold, but if you instantiate a list/accumulator, fill/operate on it inside the loop, then consume it, you're essentially writing pure code. The fact that you're doing it on top of mutable foundations doesn't matter (at that scale).

The trouble is that safe mutation and dangerous mutation look very similar. It's possible to write a function that performs safe, locally encapsulated mutation, sure - but it's much harder for a reader to confirm those properties in code review or when debugging compared to just seeing that the code doesn't do any mutation at all.

As long as you get your mutable code right. If there are any unintentional holes in your instantiate/operate/consume box...

There just isn't that much to get wrong in pure for-each loops:

    def filter_broken(widgets):
        broken_widgets = []
        for widget in widgets:
            if widget.is_broken():
                broken_widgets.append(widget)
        return broken_widgets

The actual errors with loops and mutable objects come from complex nested loops, continues/breaks (multi-level ones especially!), extra boolean conditions, and sharing mutable objects between parts of the code base.

I think that overstating the supposed risks of for-loops doesn't help anything. The problem is not that you're going to mess up a simple for loop. It's the ways that your code doesn't compose well that are more problematic. Oh, and the verbosity sucks too.

Hm. Wouldn't your code reverse the order of the list?

Maybe that's right, maybe that's wrong, but it's indeterminate from the code whether it's desired, whereas a filter function and a reverse function would make it explicit.

Append is a function that adds it to the end of the list. (I think my code is working Python, but I haven't actually run it).

Btw: I'd venture to guess that you're not a Python person, and that's why it's not obvious that it constructs the method in the same order. In imperative languages (where Python isn't the perfect example b/c it has filter and list comprehensions), you get so used to these loops that you don't have to worry about questions like that.

If you wanted a reversed list, you'd either name your function appropriately, or call reverse after you run the filter method. It's a little painful to do the first bit.

Yeah, sorry, got my mental model mixed up. I worry about reversing lists a lot since I deal with TCO so much.

> So why have three or more specialized constructs when one will do?

Because having three specialized functions for three specialized operations makes it easier to see what a given piece of code is doing. One function per function.

When I was first introduced to scala my very favorite thing was the existence of map. I'd been using java for a while and missed it dearly

Not allowed to use Java 8?

Didn't exist at the time. While I still prefer scala to java 8, had the latter been available at the time I likely never would have dabbled in scala in the first place, if that makes sense

Sure it makes sense.

I dabble in what sorts of programming languages, but when comes to work, it is mostly C#, Java, JavaScript and some occasional C++, because that is what customers pay for.

Hence why I see a big value in mainstream languages slowly evolving into multi-paradigm ones, as many of us don't have the luxury to move beyond the first class languages of each platform.

side effects ? testing ? decoupling ? (thus reuse)

If your brain is organized enough to write clean for loops then ... maybe. But it's a bit opportunity for problems. At least to me; but then I may not be smart enough.

I think for tasks such as JSON parsing, map and flatmap like functions are really helpful. You write less code and the code is way easier to understand (for those who are familiar with map functions).

That being said, map and flatmap force immutability in some way. So you pay a price for this, either in speed or in memory, even with tail recursion.

I'd much rather deal with concise, clever code that has a sane interface and works, rather than sprawling long winded code where everything is void and the same low level constructs are used everywhere.

And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

>And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

IMO, the answer is people vastly underestimate the cognitive cost of reading code. "Code" rarely exists in a vacuum, the reader has a universe of inputs, outputs, problems, solutions, failures and goals. The cognitive cost of trying to read someone's code is something that must be paid multiple times per day and at one point do you have to wonder - is the gain in expressiveness for a single programmer worth the cognitive cost of the multiple programmers who have to parse that code.

I'd imagine the answer is no - especially for companies that spend more time iterating and patching based on customer feedback than actually designing and architecting systems. My belief is that expressive languages have their place but companies are far more likely to build their software in a "patch-test-iterate" environment which favors less expressive languages.

I'll keep repeating myself: the cognitive cost of "code" is dwarfed by the cost of understanding an application. If a couple esoteric languagn features take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay every time.

Not everyone feels this way, the investment to learn these features may not pay off right away, and if you come from a "move fast and break things" language (python/php/js) it can feel like a waste of time.

> If a couple esoteric languagn features take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay every time.

Issue is that a beginner pre-conditioned long enough on "verboser, imperativer" models/languages, when reading/comprehending such a codebase, has to literally mentally expand every 1 line into 10 upon reading, for quite a while .. some weeks, some months, as more intuitive grasp sets in slowly over time. Probably what happened at OP's quoted company and with the different speeds in comprehending what "clever" (compact) code some of their coders came up with, what they flippantly called "code that was harder to understand by others"..

If a couple of esoteric language features can consistently reduce your codebase tenfold, you might want to rethink how you engineer your apps. Unless you're writing your application in FORTRAN (and I mean the version before 1958 and the introduction of procedural code) or assembly, I doubt there are any two general-purpose languages that show a 10x difference in code size in large applications.

I can't up on this enough. If the line count is low and the interfaces are great I'll forgive all manner of oneliners.

I totally agree. Plus, it keeps job interesting.

Language is important and its expressivness. Babel 17 is must read.

> And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

There are two problems with this argument. First, brilliance in code is not a property of what linguistic abstractions the code makes use of, but the elegance of the algorithm and engineering. I sincerely doubt that no brilliant code had been written prior to the introduction of your favorite linguistic abstractions. Second, even supposing you're right, what difference does that make? If your code's maintainers are dumb, do you think that you could change this reality by making life harder for them, or is it your job to adapt yourself to the reality of the system you're a part of? When creating something for dumb people to use, is it a sign of good craftsmanship to make it harder for them to work with?

Welcome to Haskell ... where clever people write frameworks that even dumb people can't break ;-)

e.g. https://code.facebook.com/posts/302060973291128/open-sourcin...

And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

This is not an absolute, and needs to be answered in the context of the question: "Does my team work?"

> And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

If you ever wonder this, then it's definitely a problem with your code and not the reader. Code that cannot be easily read and understood by others is worthless in any commercial setting.

If you're too numb or stubborn to learn the tools that your programming environment provides for writing higher quality code, I have little sympathy and would suggest that such a person fond another line of work.

If, for instance, someone were writing C# and insisted on hand-rolling for loops in all cases[1], because LINQ is "too hard", that's them being lazy and unwilling to invest a tiny amount of effort in learning more effective methods.

[1] There are some cases where it's more performant to use a plain foreach or bare for, but unless you're in tight loops or dealing with ginormous collections, it's a premature optimization.

Or working in game development with low latencies to achieve high frames per second.

I don't agree that all languages are created equal in this regard. I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness."

For instance, python has never had the problems that ruby or perl had.

I don't agree that all languages are created equal in this regard.

I never said that. I'm only asserting that no language is completely immune, because hubristic cleverness is intermediate to stupidity and genius.

I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness."

Cultural norms can indeed help or hurt.

I've seen Ruby-like Python. Just because Ruby makes it easier to do metaprogramming doesn't mean you can't do it in Python.

Of course it's not impossible.

As the saying goes: it's easier to write code than understand it. Therefore if you write code as cleverly as you can, then by definition you're not smart enough to understand it...

For those that like trivia, the original quote I believe is by Kernighan and it's about debugging code rather than writing it, which I feel makes more sense:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

https://en.wikiquote.org/wiki/Brian_Kernighan

I sometimes optimistically believe that my cleverness will increase over time.

Yes but occasionally there's no other option. I once had to code a parser for a data format with an odd non-BNF grammar with a bunch of special cases. In order to meet the functional requirement for user-friendly error reporting when parsing invalid inputs I was forced to write really clever (in a bad way) code. Fortunately we haven't found any serious defects in it because I don't think I understand it well enough to debug it.

It is okay to write clever code if necessary. Solutions to some problems require it.

Clever code for the sake of being clever is rarely worthy it.

This is one of the extremely cool things about python. There's always one right way to do this, and it's usually pretty obvious. There's also quite clear, standard style guidelines, so code is generally formatted pretty much homogeneously, and tends to be a lot more readable than many other languages.

Per the Zen of Python, there should always be exactly one sensible way to do something, but unfortunately this is not often the case. List comprehension can be achieved just the same with functools, itertools, explicit for loops, etc.

That said, I do tend to have that mantra a little more present in my head when I'm working with Python.

yep... making 'understandable' is really important.

But given that discipline, scala would outshine go since scala has much better typechecking than go - e.g. http://getquill.io/ can typecheck against a running DB schema, etc.

It got really bad the past 10 years or so with the "look at what I can do, ma!" blog posts where someone spends 4 pages violating the language in order to get clicks. It's especially endemic in Ruby-land, I find.

I always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators.

They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse.

Some of their code is so "clever" that I've refactored the line with 7 method calls just to understand what the hell is going on.

Lambdas and fluent syntax make me quiver with fear. In the wrong hands they let you do unspeakable things

> aversion to certain shortcuts like ternary operators.

> They don't understand that unclear code is probably the number one cause of technical debt.

At the same time, verbosity can have an obfuscation quality all of its own. For simple assignment, I find a ternary operator very clear and concise, and much preferable to a 5-9 line (depending on style) if/else for a simple assignment. It also might keep you from using the single statement version of if/else if your language supports it, and that's probably justification in itself given how many problems that's caused in the past.

Specifically, I think:

    usefulMetric = wantComplexCalc ? complexCalc(foo)
                                   : simpleCalc(foo);

is preferable to:

    if ( wantComplexCalc ) {
        usefulMetric = complexCalc(foo)
    } else {
        usefulMetric = simpleCalc(foo)
    }

even if only because it doesn't obscure intent with what is essentially boilerplate.

OP is about Scala, where you write directly what you mean, without special operators:

    val usefulMetric = if (wantComplexCalc) {
      complexCalc(foo)
    } else {
      simpleCalc(foo)
    }

Well, that's only "directly what you mean, without special operators" if you come from a C style procedural background and have already internalized all the special operators you've included there, such as parenthesis and braces. Sure, that's most people, but that doesn't mean they aren't operators.

I'd rather have Python's way of doing it, which plays with the order for the sake of readability:

    useful_metric = complex_calc(foo) if want_complex_calc else simple_calc(foo)

Ruby has something similar, and I can't stand it. I think the conditional is the most important item in the phrase, and it's shoved off to the right. If you lead with the conditional, it becomes immediately apparent that the assignment is predicated on the result of a branch.

Ruby (and Python) likely get that from Perl, which has post conditionals, but with specific qualities to prevent them from too much abuse, and which also prevents them from being used in the way presented here (which is why I didn't trot them out earlier, as much as I was tempted by the "you write what you mean" line). The limitations are that there is no else branch, and it only applies to a single statement, so you can't have a block executed with a post conditional. It leads to usage like so:

    die "Invalid param: please enter a positive number" unless $param1 > 0;
    
    $param2 = 0 unless defined $param2;

    return undef if $param1 and not $param2;
    
    my $foo = 1 if $bar; # This unfortunately creates a closure around $foo and is a big source of bugs.

As much flak as Perl gets, quite a lot of thought went into making it flow similar to how people think and talk (which is no surprise if you know Larry Wall is a linguist by training). There were some missteps, but it was very early in this area, so that's expected.

Perl hung onto too many of its warts for too long to stand a chance of competing with Ruby and Python. Only recently has Perl5 introduced real function parameters instead of unrolling @. Flattened lists are another one but the worst is having to specify "use 5.020;" if I'm using Perl 5.20. They've even carried this "tradition" into Perl6 where you have to specify "use v6;" at the top of EVERY damned script. That's progress? Prefixing every variable with "my" is another one which found its way into Perl6. Why can't an advanced language have default lexical scope?

> Only recently has Perl5 introduced real function parameters instead of unrolling @.

Yet there have been modules that support it for years, and with much more features than what was recently rolled out (which was meant to be conservative).

Here's[1] what I said about this quite a while ago. Named parameters with type checking (unfortunately at runtime). I've been writing Perl using different modules (Function Parameters) which use the same syntax for about six years now (for functions, not all the sugar on Moose objects).

> Flattened lists are another one

Flattened lists never cause me a problem. If they cause someone problems, I think they've never really learned what context is in Perl. Once you know how context works in Perl and had a chance to use it to good effect, I can't imagine this complaint persisting. Perl is fundamentally different than most languages in this respect, even if it looks superficially similar to more procedural languages. This is actually a cause of a lot of problems for novice users, because they assume their experience in C/Algol derivatives will map exactly, and where it doesn't people get frustrated.

> but the worst is having to specify "use 5.020;" if I'm using Perl 5.20

What? You don't have to do that. If you want to use newer features that utilize keywords which may conflict with whatever you've written or whatever modules you are using, then yet, you need to opt into those. Perhaps you would have preferred if it silently just broke?

> They've even carried this "tradition" into Perl6 where you have to specify "use v6;" at the top of EVERY damned script.

No, you don't. If you do, and you run it in Perl 5, it will automatically swap out the interpreter for whatever Perl 6 interpreter you have in $PATH though.

> Prefixing every variable with "my" is another one which found its way into Perl6. Why can't an advanced language have default lexical scope?

The requirement to define your variables is not because it's not lexical by default (it is lexical by default, you can use no strict to see). .It's strictness which is enforced, which has been found by the Perl community to be vastly preferably to automatic instantiation of variables because it prevents bugs, and prevents a lot of confusion. You have to define your variable, because the Perl community found that a more sane default.

1: https://news.ycombinator.com/item?id=11633961

Agreed, plus obviously your "if" statement doesn't do the assignment to usefulMetric. One more way the ternary wins (along with functional languages that use "if"s as expressions).

a "final" declaration (in Java) would have pointed that out through a compilation error ;)

D'oh! Fixed. Thanks. :)

Unfortunately, ternary operators eventually end up like this due to refactoring blindness:

  usefulMetric = wantComplexCalc ? 
                   (complexity > 40 ?
                     superComplexCalc(foo) :
                     regularComplexCalc(foo)) :
                   simpleCalc(foo);

At some point you have to rely on policy and not language constraints. I submit that no language is constrained enough to protect against refactoring stupidity while also being flexible enough to be useful to the average programmer on the average project. If not ternary if, it will be something else. So, do you throw out every alternative method to accomplish the same thing, or do you put policies in place to keep the code sane, such as "no chained ternary operators are allowed" ?

In all honesty, I prefer having rules that have no special-case 'unless' issues. It's too much effort/trouble to remember all the cases where things don't work. I'm a good engineer but a terrible compiler.

I believe part of learning a new library/framework/language is to limit yourself to a certain subset of the API offered. After working with Ruby (the language) and Javascript (the ecosystem), I feel like that's the only way to preserve your sanity and productivity. I don't need to know 4 different ways of creating a lambda in Ruby, selecting 1 that can express the other 4 is good enough.

---

In this case, the rule would be no ternary operators, since they work well unless you nest them or unless you make them long/complicated.

Other examples -

You don't need to wrap if conditions unless you have a multi-line body:

  if (myCondition)
    x = 42;
    y = 23;

Early returns simplify short circuiting logic unless your function becomes too long:

  if (myVariableAtBeginningOfFunction) {
    return true;
  }
  ...
  // 2 screens later
  ...
  if (x == 42) {
    return false;  // why am I not getting false?!
  }

Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy:

  if (person.isStudent) {
    showSchool();
  }

  if (person.age) {
    showBirthCertificate(); // what if age is 0?
  }

> the rule would be no ternary operators

Why not "no nested ternary operators"?

> You don't need to wrap if conditions unless you have a multi-line body

Why not "keep unwrapped if conditions on a single line"?

> Early returns simplify short circuiting logic unless your function becomes too long

Why not "keep functions short"?

> Using a variable as a conditional in javascript to test against undefined works well unless the value can be falsy

Why not "only use conditionals on boolean values"?

I'm not saying your rules are right or wrong, I actually follow a couple of them myself, but your wording implies that other people are simply not following rules, or their rules have a lot of nuances and special cases, but the reality is more likely that their rules are different.

Ultimately we all make different connections and form different patterns in our head. As long as a team can agree on a code style, within a few months everyone starts developing the same cognitive patterns.

It's because it's too easy to lose some of these nuances during refactoring/development blindness. I'd go so far as to say it's inevitable.

If you come into a 3 year old codebase and during the first 2 weeks you need to add extra functionality to a 30-line function with an early return, are you going to refactor the early return? Or are you going to extend it into a 32-line function? What about the new hire after you?

Alternatively, your team has decided to embrace the "only use conditionals on boolean values" philosophy. You're working with a section of code that reads `if (myVar)`. It's been 3 hours, and you don't understand why the code's not working. Suddenly, you realize that at some point `myVar` was refactored from a non-nullable boolean to a nullable number, and someone missed changing this.

And the biggest offender yet - code that is grouped within a file into 'logical sections'. I've never seen this work out. What is a logical grouping for you is a confusing pairing for me. Or maybe it's that I can't immediately grok all 2000 lines of a file I've never seen before, and know where to place the method. This madness around code location is one of the quickest ways to code rot.

---

The perplexing thing to me is that these situations are completely preventable.

If you don't use early returns, scenario 1 won't happen.

Scenario 2 won't happen if you use real comparisons e.g. `if (person.age !== undefined)` (Similarly, `if (person.age != null)` breaks when null and undefined start meaning different things...)

And lastly, a canonical alphabetical/visibility ordering for methods in a file of any length is unambiguous. I don't care what the order is, as long as there is a canonical order.

---

I understand that other teams have their own rules. It's no trouble at all to adjust to things that are purely syntactic differences. But when the rules that are chosen hide lurking semantic pitfalls...I don't know why you'd risk shooting yourself in the foot.

A lot of my strong feelings on code style come from the book Code Complete. I highly recommend that to everyone who hasn't read it. It's filled with examples of confusing/broken code you might inherit, and teaches you how to avoid creating it yourself.

Edit: looks like we hit the HN thread depth limit. Happy to continue this over Twitter, check my profile.

That's just laziness on part of the refactorer. At that point, you need to use an outer if-else statement. Ternary operators are confusing when nested.

what about:

  usefulMetric = wantComplexCalc == false ? simpleCalc(foo)
               : complexity <= 40         ? regularComplexCalc(foo)
               : /* else */                 superComplexCacl(foo)
               ;

Doesn't look much better.

IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do that efficiently. Instead of investing some time into getting used to the peculiarities of the language that they use, they then try to avoid them as "complicated". By lowering a bar too low, and avoiding using these patterns all together, you encourage people to never train their brains to recognize them effortlessly. And by definition of common patterns, they're, well, common, and they'll keep running into them all of the time. Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through.

I'm not saying that one should go crazy with one-liners or uncommon patterns, but things like ternary operators used with reasonably short expressions in a single line of code are totally valid and should be readable to any average dev out there.

Great comment.

Particularly

> Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through.

I stopped contributing to one Powershell repository because author thought that ps is hard and he wanted Get-Process. I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful

Particulary

> Also keep in mind that you're probably bothering others, more skilful ones, with unnecessarily verbose code which is to them harder to quickly scan through.

> I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful

Not sure I can think of too many situations where it would be otherwise.

In general context yes, but if you tell your top contributor that besides doing full day job work for entire year for free (while main author also has commercial offering) he should also babysit "dumb" users (making entire job not fun) and you get the tip multiple times that such behavior will alienate him from the project, you can be sure there is a way better approach to project management. Since I left it, the PRs and issues that nobody looks at started to pile up (I kept both at almost 0) which is extremely important given that project relies on constant PRs and reports by the community.

Here is the meme:

http://content.randomenthusiasm.com/d4ZEVg4VB.jpg

Not exactly profane I would say but what do I know ...

Not profane, but condescending nonetheless and not appropriate in a professional/code review setting.

Its FOSS setting, not a professional setting. Being a jerk to people that do excelent stuff for your project for free is far from appropriate in any setting on the other hand.

Professionalism doesn't get left at the door at 5:00.

>I put a "i am the greates babysiter meme" in PR and that was considered very disrespectful

Sounds like it was disrespectful too.

Your underlying assumption that everyone working on the code will be skilled is wrong in any large team. It's not like it takes a lot longer to read a 3 line if statement than a ternary operator.

Terse code isn't much faster to read, the difference between a 300 and 400 line file isn't significant.

Your attitude of "he isn't 1337 enough to understand my code" is the logic that leads to no comments and horrible to maintain code in the first place

> It's not like it takes a lot longer to read a 3 line if statement than a ternary operator.

It doesn't take a lot longer to sit down and understand how ternary operators work, either. C'mon, it's not differential equations, it's just a notation, and a fairly simple one. It might take a newbie slightly more time at first to understand the logic. We've all been there once, you stop and stare at it for 15 minutes, but after a few times of deciphering it you get used to it. It's not about being 1337 (I surely hope that it's not what's considered elite this days), it's about learning new stuff and any averagely intelligent person can do it. Honestly, would you really hire someone who is not capable to (in a reasonable amount of time) teach him/herself how to read a ternary operator? What programming would that person be capable of doing in future?

One person's clever is another person's clear and vice versa. These conversations are pointless as there is no objective truth on code clarity

This is not really as subjective as you think. Research in software engineering shows that certain structures are more prone to errors than others. We know that higher cyclomatic complexity leads to more bugs, more statements lead to more bugs, and certain usage patterns lead to more bugs.

Smart people can disagree, undoubtedly, but there's a reason why GOTO is considered to be brain cancer and pattern matching is generally considered to be great.

Sure but I'm talking about things like "break things down into lots of small functions to make things more readable!" vs "keeping code together makes it easier to read!" or "make things verbose so it is easier to read!" vs "conciseness makes code easier to read!"

On a lot of those I know what makes code easier for me to read. It's not the same as some of my coworkers. Based on some of your phrasing I suspect we'd agree on a lot of them, fwiw

When the metric used is "easier to read" it becomes far too subjective IMO, things you mentioned are similar but not quite the same

In my experience, very experienced programmers end up converging towards very similar idioms: terse expressions for common patterns, clarity when the domain is complex through verboseness if necessary, and just keeping things as simple as possible unless there's evidence that complexity will reduce technical debt in the future.

I don't really see highly competent devs doing the whole J2EE architecture astronautics anymore, nor using single-char variable names. There's a tendency to write things concisely when simple, and then moving the complexity away to some other place, stashed in its own function, when it reaches a certain mental threshold of complexity. There's a tendency to use the best features languages have to offer, maximizing simplicity through orthogonal features and repeated idioms, while discarding unnecessary cruft; one of the marks of junior devs is their desire to try to fit problems into new idioms just to test out language features or strange design patterns.

Given that human intelligence is fluid but the variance just isn't that high (after all, we all have a similar amount of working memory), common design practices emerge out of this understanding for our limits for reasoning about problems. Exceptions abound in extremely technical and complicated problems (just check out non-trivial linear algebra code or bit-flipping, low-level device drivers), but the most part it just sticks out how things are made to look simple within a finite range of tradeoffs. This has been my experience in my domain of expertise; look at most current web development frameworks and they respect common patterns even in radically different languages that are really about the essence of the request-response cycle, not made-up constructs of additional complexity or a restating of the problem.

> I don't really see highly competent devs doing the whole J2EE architecture astronautics anymore

Yes we do, because the customers and their in-house architects decide how it is going to be, not us.

> nor using single-char variable names

My pet hate.

We had a policy at my last place that any SQL joins alias the table name with a single character alias. The rule resulted in the most insanely confusing stored procedures I've ever seen. Whoever came up with that is a complete idiot

It's a judgment call where small functiosn are more readable than cohesive code.

If the 'idea' of the code isn't easily broken down into abstractions, even mentally speaking, then small functions will just obscure what's actually going on by pointing out all the implementation details that are wound together.

I think the point is that there's a wide range of styles that are readable, but the condition for readability is also related to the skills of the coder to clarify. And that range is ample but also finite.

> but there's a reason why GOTO is considered to be brain cancer and pattern matching is generally considered to be great.

Look at any large C codebase and you will see plenty of goto statements to manage resource cleanup. The problem is using goto in place of structured control flow like loops and if/else. Statements like yours make it seem like there is a conceptual problem with a jump.

Sure there are some cases in C where you want a particular control flow that the language doesn't allow, and goto is the best solution in those cases.

But all the examples of this that I've seen are still structured it's just that the language isn't able to express that structure. The most common examples are jumping out of nested loops (better solved by allowing named loops so you can use break/continue) or jumping immediately to error handling logic (better solved by exceptions, or even just simplistic try/throw/catch).

I do think there's a conceptual problem with arbitrary jumps.

That's why I'm a proponent of code ownership. We should be coding to each others interfaces instead of constantly poking around in the same shared codebase. It just leads to pointless re-writes and low quality - a tragedy of the commons.

https://www.visualstudio.com/en-us/articles/devopsmsft/code-...

Unfortunately sole code ownership increases the bus factor.

Why? The code is still there even when a person leaves.

Code is really hard to work with without the theory that surrounds it, and is alive in the people who worked on it.

Peter Naur - Programming As Theory Building http://pages.cs.wisc.edu/~remzi/Naur.pdf

Legacy shitcode is legacy shitcode. If it's owned by someone at least we can push for a sane interface, which is better than the abandoned communal messes I encounter in the real world.

I'm not sure if this is true.

Scala provides a whole new level of ability for people to write code that can be meaningless to others.

It really is quite different.

And that sort of scala code is extremely meaningful to other folks, which captures my point. I see scala code all the time that would give me an instant headache but there are people who would find that more readable. To each their own, the is to work with people who are at least somewhat aligned to your sensibilities.

Fair enough - but I'll offer this:

+ Any decent developer can read decent code in Java or whatever normal language and get along just fine.

+ Only a few people can deal with Scala - and even fewer if there's a log of specific project Scala weirdness used in a particular program.

So sure - among a narrower set of 'Scala friendly' developers, and possibly within that even narrower set of people familiar with the 'Scala weirdness' of a particular project - those people can 'get along fine'.

The problem is that this can be a pretty narrow set of people.

Scala would have to represent a pretty big advantage to propose it's general weirdness as something to bother with.

I don't think it does - hence the 'de-adoption' of various entities.

My gut tells me it's past the threshold - the 'extra power' offered Scala just isn't quite worth it's weirdness for most things, and so most devs won't learn it ... and so then it becomes less valuable from a business perspective.

It's possible we may have it peak Scala.

We'll see I guess.

That's not what you said. You said others, not most people. The most important aspect is who you surround yourself with. For instance the scala folks at Verizon basically live in the zone you're talking about and it is fine for them even though half the time it makes no sense to me

> They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse.

True, but once get into the length of variable names in iOS and Android development, you're in a whole new territory. 38 character variables have no place in life.

And extreme's like:

outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch

This is 149 character.

The thing is that, shorter names do not help in this case either...

this is a developer problem not a language issue, i've seen "nifty" code in go just as well..

The design of a language/environment can sometimes exacerbate this particular developer problem. Because so much of the power of Smalltalk lay in its powerful debugging, weird proxy stuff had a potent impact.

Some languages make it easy to shoot yourself in the foot with nifty. I found Perl and Scala to be in that camp.

Some languages have footguns and constructs that are error prone.

Reply on news.ycombinator.com