
500 Lines or Less - divkakwani
https://github.com/aosabook/500lines
======
debo_
Hi, I'm the editor of 500Lines. Thanks for posting this! A few notes:

\- Code golf was strictly discouraged throughout the review process. When
authors were faced with implementing functionality poorly to fit more in, we
generally cut scope instead.

\- 500 lines was selected as a limiting criteria because it is easy to specify
and understand. You will see that the chapters written e.g. with Clojure do
"more" (for some definition of more), but that does not make the lessons
learned in the other chapters less interesting.

\- The "or less" moniker is grammatically a bit offensive but sounds cute on
paper, so we kept it.

\- If you'd like to learn more about the philosophy or story behind this
volume, Ruby Rogues hosted us a little while ago: [https://devchat.tv/ruby-
rogues/256-rr-reading-code-and-the-a...](https://devchat.tv/ruby-
rogues/256-rr-reading-code-and-the-architecture-of-open-source-applications-
with-michael-dibernardo)

\- The print version of this book (and the official launch on aosabook.org)
should happen sometime in the next 4-6 weeks. You can follow this issue if
you'd like to know when that happens:
[https://github.com/aosabook/500lines/issues/212](https://github.com/aosabook/500lines/issues/212)

~~~
avar
The first thing I looked through, the pedometer/ directory, has a project that
itself may be <500 lines, but is using compressed versions of JS libraries
like highcharts.js & jquery.js.

Don't you think including huge external libraries like that defeats the spirit
of showing things that are 500 lines or less?

~~~
rtpg
I don't think so. Would you rule out things like the python standard library?

Though external library size can be important, does it come into play when
talking about your own code structure?

~~~
Karunamon
Only if you assume it to be bug free in a way that your code will never
expose.

------
banthar
From:
[https://github.com/aosabook/500lines/blob/master/ci/code/hel...](https://github.com/aosabook/500lines/blob/master/ci/code/helpers.py)

    
    
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((host, port))
        s.send(request)
        response = s.recv(1024)
        s.close()
    

Is that correct use of TCP? It seems to rely on response not being fragmented.

~~~
DSMan195276
It's definitely not right as far as the C interface is concerned - and Google
indicates that the Python interface doesn't do anything extra. That said, it
probably does generally work considering the small size of the messages,
especially if the dispatcher is run locally. It's unlikely that a two-byte or
ten-byte message would get fragmented, though it technically could - and
that's all that is sent by the dispatcher.

That said, this should be a loop that combines all the responses until you
receive a response of length zero, indicating EOF. The actual code to
correctly handle this is really simple if you don't do any extra error
handling - but it's not obvious if you haven't done some socket programming
before.

This code will probably work until the dispatcher and clients are expanded
upon, resulting in more complex messages that eventually lead to sporadic
fragmentation.

------
divkakwani
Here is a link to the pdf:
[https://dl.dropboxusercontent.com/u/29696071/500L.pdf](https://dl.dropboxusercontent.com/u/29696071/500L.pdf)

~~~
arve0
This is "The Performance of Open Source Applications", not "500 Lines or
Less".

Edit: An older version?

~~~
divkakwani
This is 500L indeed. Don't know why the cover says POSA.

------
amelius
Offtopic. Why, in github, is the README always below the repository files, if
the first thing you want to read about a project is the README?

Edit: Could we take the convention on HN to always link to the README in a
github repo? In this case that would be:

[https://github.com/aosabook/500lines/blob/master/README.md](https://github.com/aosabook/500lines/blob/master/README.md)

~~~
marssaxman
I considered Github links to be essentially content-free noise for several
years because I did not know about their "README.md" convention. I think that
people who live and breathe github probably don't realize how confusing their
interface can be to a newcomer.

~~~
mjrbrennan
You didn't think to just scroll down?

~~~
marssaxman
I didn't know to scroll to the bottom, as I had never used github and was
unfamiliar with its interface. I thought it was basically just a prettier
version of the classic auto-generated "index" page for a directory, so it
didn't occur to me that there would be more to it than the file list if I
scrolled down.

~~~
pc86
> _I didn 't know to scroll to the bottom_

If only there was some sort of bar that could indicate your relative position
on the page. Maybe in the same spot on all websites to make it easy to see.
Maybe even part of the browser!

In all seriousness this seems much less a GitHub issue and much more about how
well you computers.

~~~
marssaxman
It is an issue of expectations and affordances. If there's no clue that what's
at the bottom is going to be different than what's at the top, and what you're
seeing at the top is not giving you anything useful, why would you scroll
further and waste your time seeing more of it? Perhaps for some people that is
natural, but different people navigate unfamiliar spaces in different ways.

What you see when you open a github project page is a file directory. If you
have no pre-existing reason to believe the page is something more than it
appears to be, it's reasonable to believe that the page you're looking at is,
in fact, just a file directory. There is nothing on the page which suggests
that it also contains a readme file viewer, hidden underneath.

I didn't scroll because the directory structure suggested to me that one would
navigate by digging around to see what was inside. After the first couple of
times I tried this without getting anywhere, I wrote github off as a waste of
time, and after that I simply closed such links immediately. It might have
been easier to discover README.md from some later link with a smaller
directory, where a smaller amount of scrolling down might have revealed it,
but by then I was no longer looking.

------
Bromskloss
Is there a compiled version somewhere? I don't think I will be able to build
this on my phone.

~~~
satai
Early Access: [http://aosabook.org/en/500L/](http://aosabook.org/en/500L/)

~~~
drauh
The embedded images seem to be broken.

------
sien
This is a really interesting book by some brilliant people.

I wonder if the problems selected are the ones that many people would select
though.

What would people here select as, say, the top 5 or 10 things to write in a
short amount of code. Say perhaps in 1K lines of code.

A web browser? A compiler? A simple relational database?

~~~
zem
interpreter for an interactive fiction language

------
falcolas
> canonical problem in software engineering in at most 500 source lines of
> code

I'll reserve judgement of the book for when its in a form I can easily read,
but this seems to come up on the wrong side of the "less isn't always more"
line.

I can implement a lot of logic in 500 lines of code, but I won't be able to go
back a month later and understand any of it, at least not without rebuilding
the logic from scratch. And I certainly can't also implement the safety
checks, corner cases, and tests in that line quota.

I would personally think there is more value in showcasing a single complete
and well commented solution instead of a slew of partial solutions with "the
error checking left as an exercise to the reader" (I'm not sure if this phrase
is in the book, I plucked it from any number of poor college textbooks).

~~~
fermigier
You probably misread the intent of the book editors and writers. As @debo_
wrote above: "Code golf was strictly discouraged throughout the review
process. When authors were faced with implementing functionality poorly to fit
more in, we generally cut scope instead."

------
exabrial
How about a competition to see who can write the clearest code for the next
guy, in minimal lines of code?

~~~
voltagex_
Sometimes optimising for the least lines of code leads to _less_ clarity than
being a bit more verbose and explaining yourself better.

I still haven't quite worked out the code vs comments ratio.

~~~
exabrial
Couldn't agree more.

------
archos1
*500 Lines or Fewer

[https://en.wikipedia.org/wiki/Fewer_vs._less](https://en.wikipedia.org/wiki/Fewer_vs._less)

~~~
arsenerei
From your reference.

> However, descriptive grammarians (who describe language as actually used)
> point out that this rule does not correctly describe the most common usage
> of today or the past and in fact arose as an incorrect generalization of a
> personal preference expressed by a grammarian in 1770.

> Many supermarket checkout line signs, for instance, will read "10 items or
> less"; others, however, will use fewer in an attempt to conform to what is
> incorrectly perceived as required by the prescription although this is in
> fact a clear case of hypercorrection as explained in Pocket Fowler’s Modern
> English Usage.

> Less has always been used in English with counting nouns. Indeed, the
> application of the distinction between less and fewer as a rule is a
> phenomenon originating in the 18th century.

------
genos
Looks like there's code in different languages, so the arbitrary 500 line
count gets even more hazy. As an extreme case, consider 500 lines of APL vs.
Java.

------
nine_k
500 lines of _what?_ 500 lines of APL / J / Q is enormous; 500 lines of
Haskell / Scala / Ruby is quite a mouthful, 500 lines of Java or C is rather
moderate, and 500 lines of assembly is precious little.

Also, since a line of code can contain zero or more statements, something like
cyclomatic complexity, or just statement count, could give a better measure.

(Edited: fought autocorrect.)

~~~
chrisseaton
What on earth do you think this is? It's not a research hypothesis. Nothing is
being measured. It's a clever way to get people to show that ideas many people
think are beyond their understanding can be illustrated in just a few lines of
code.

'Cyclomatic Complexity of N or Less' would work against that goal as it says
nothing about length and is hard to explain.

What a mindless criticism of a worthwhile project.

~~~
nine_k
I'm actually all for books like this.

