Hacker News Reader

Comment by jcadam | Hacker News Reader

> The trend in programming lately seems to be less to no comments and less to no documentation; and it is killing the joy I take in programming. Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. You can't do anything that hasn't been done before.

Enter Golang... a language smaller than even ANSI C. It's readable because if you've worked with Golang for more than a week, you basically know every language construct you'll encounter.

As an aside, I've found Clojure to be one of the most "readable" languages I've ever seen, in that I can usually just go to the source code if I'm trying to figure out how to use a library I just pulled in from clojars.

View on HN

> Enter Golang... a language smaller than even ANSI C. It's readable because if you've worked with Golang for more than a week, you basically know every language construct you'll encounter.

That's not really what readability is to me. For example, I consider this idiomatic golang code (from the standard library, no less) to be entirely unreadable:

https://golang.org/src/crypto/tls/handshake_messages.go#L297

For me readability is more about suitable levels of abstraction. Languages can affect that by making abstraction longwinded, or expensive at runtime, or hard to compose.

It's ultimately subjective, but I think that code is readable: the variables are well-named and each line says exactly what it does. Abstraction makes it easier for you to think you understand what the code is doing, but if you want to really understand what's going on, you also have to understand how the abstraction is implemented. Straightforward code like this can be understood directly, without having to dig through layers of function calls.

If you think that code is readable, could you correctly write all pre/post-conditions in between statements?

I think that's a little different. Reading code almost never involves analyzing it to that degree. Usually you're just trying to figure out what part is broken or where you need to add some new functionality.

The meaning of an imperative program is given in terms of Hoare triples. If you can't produce such triples on demand, then you don't understand the program in question.

> For example, I consider this idiomatic golang code (from the standard library, no less) to be entirely unreadable

Really? It's a binary parser that's parsing data from a byte array and stuffing the results into a struct, it seems pretty straightforward.

> It's readable because if you've worked with Golang for more than a week, you basically know every language construct you'll encounter.

If you've used Brainfuck for more than 5 minutes, you already know the entire language. Is it the most readable language ever designed?

> I can usually just go to the source code if I'm trying to figure out how to use a library I just pulled in from clojars.

Will a cursory read of the source code either tell you how the library deals with corner cases, or convince you that such corner cases don't exist?

And the source code doesn't tell you why something was done. Why is this message expected to be only 42 bytes long or less? Is there a specification for it? I can see that someone grabs two adjacent bytes, pulls out 12 bits from them and puts them into a variable called "version":

  version = ((data[0] & 0x0F) << 8 | data[1]);

But why? Is this still correct with the current specification of the message format? Who knows! And this is a best case, where "version" is a meaningful variable name.

My thoughts exactly.

> If you've used Brainfuck for more than 5 minutes, you already know the entire language. Is it the most readable language ever designed?

Oh, come on... BF was specifically/pathologically designed to be unreadable.

> Will a cursory read of the source code either tell you how the library deals with corner cases, or convince you that such corner cases don't exist?

Um... no, not really (at least not a cursory glance), but readability certainly helps track down issues later when you do run into an unforeseen corner case. Language choice is all about trade-offs -- if things like this are what is most important to you, perhaps you would be happier with something like Haskell or Ada.

> Oh, come on... BF was specifically/pathologically designed to be unreadable.

I was just exposing a flaw in your “readability” criterion. Another example: you can learn the rules that govern a given cellular automaton in 5 minutes, yet be completely unable to predict what said automaton will do when run.

> readability certainly helps track down issues later when you do run into an unforeseen corner case.

I'd rather not have issues, and always be sure that I've handled everything. Only applied formal logic can help.

> Language choice is all about trade-offs

Normally, understandability trumps all else. The only exception is when it's too badly in conflict with performance.

> if things like this are what is most important to you, perhaps you would be happier with something like Haskell or Ada.

Nah. GHC Haskell and Ada are both ginormous languages that I don't believe anyone could fit into their heads in their entirety. In particular, with GHC Haskell, I don't feel confident saying “this code does exactly what I want and nothing else”, because someone might enable an extension I haven't accounted for, and then hilarity ensues.

(And nobody uses the language specified in the Haskell Report.)

Truly. I used Ada professionally for several years and wouldn't want to go back. Even though programs that compiled had a much higher probability of just working compared to other languages, programming with Ada was both dull (or maybe that's just an Aerospace industry thing) and frustrating (that type system, ugh).

One thing I found while messing around with Haskell is that while learning and writing vanilla Haskell is one thing, deciphering Haskell written by others is quite another, given the propensity of library authors to use language extensions and stuff like TemplateHaskell.

> I don't feel confident saying “this code does exactly what I want and nothing else”, because someone might enable an extension I haven't accounted for

If you have any examples of code that, when an extension is enabled, neither fails to compile nor fails to behave in the same way it would be really interested to see them!

If I were to try to conjure some up the first place I would start would be interactions between scoped type variables and typeclasses.

Reply on news.ycombinator.com