Hacker News new | comments | ask | show | jobs | submit login
500 Lines or Less (github.com)
377 points by divkakwani on May 29, 2016 | hide | past | web | favorite | 61 comments

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...

- 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

Skipping over the semantics of the title, and the war over the languages (btw, all programs can be written in one APL line), I thank you and the other authors for your work.

If you are looking for other things to write, I'd like to suggest a simple editor and a text translator to go from one markup to another, which at the end could be combined to be a WYSIWYG editor.

So you don't have to look it up too:

Code golf is a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that implements a certain algorithm.

How can one contribute to this project? I personally ascribe to the belief that there's no better way to learn something than by implementing it yourself and would like to grant what help and background in writing and development I have.

I think the project should highlight quality, meaning review burden, but I think everyone should be encouraged to do their own 500 line repositories and share them (call me crazy but something like hashtags wouldn't be a bad thing for these sort of themed repositories)

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?

To me it seems actively good to include examples that use well-developed libraries, to show the types of tools and abstractions that one can build on. Restricting oneself to a language's standard library may give the false impression that anything worthwhile requires a large bootstrapping effort.

That said, it would be fun to provide, e.g., a 500-line graphing library to show how one might begin building something like highcharts.

I would think not. Is the interesting part of the problem drawing charts? If not, it makes perfect sense have that abstracted away somewhere else.

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?

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

This book(and indeed the rest)is neat! Great work, looking forward to the finished copy.

Will this ever be able as a git book?

I want to know as well

From: https://github.com/aosabook/500lines/blob/master/ci/code/hel...

    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((host, port))
    response = s.recv(1024)
Is that correct use of TCP? It seems to rely on response not being fragmented.

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.

No it is not. You must keep reading from the socket until you have read as many bytes as required - he isn't even checking how many bytes recv returned.

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

Edit: An older version?

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

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:


Well, it's the first thing you want to read about the first time you visit the project. The rest of the time it's probably the last thing you are interested in.

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.

You didn't think to just scroll down?

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.

> 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.

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.

But ... why would I assume that the bottom of the page had meaning when the top did not?

You don't read all the way through the Time Cube page before coming to an idea about the contents.

.repository-content { display: flex; flex-direction: column; }

#readme { order: -1; }

You could add that to the page style (using a browser plugin).

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

I was able to build the PDF on Fedora 23 [1]. Ended up with no front page but the content is there. Not sure if it's supposed to be like that or not.

I also attempted to build the ePub and HTML versions but that didn't work. Commented about this on issue #134 [2].

[1]: https://github.com/aosabook/500lines/files/288427/500L_pdf.z...

[2]: https://github.com/aosabook/500lines/issues/134

The embedded images seem to be broken.

I couldn't build it on my laptop. I'd have to install 3.5Gb of Tex dependencies to do it so I'll pass.

Me, either. Tried on OSX. Thought I'd get away with installing ~ 0.5 Gb when I read up about everything, but still run into problems.

This is a book people. I shouldn't really need to compile it; even if I absolutely must, it should be at least possible, if not fairly straightforward. Disappointing.

It is not finished, so they haven't released a complete version yet, but previews of the individual chapters are on their website: http://aosabook.org/blog/

I was able to build on OS X with Fink's texlive. Output seems to be the same as the PDF already posted here (in a Dropbox link).

No joy on epub, mobi, or html.

> This is a book people. I shouldn't really need to compile it;

As opposed to what, exactly? txt files?

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?

interpreter for an interactive fiction language

> 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).

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."

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

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.

Couldn't agree more.

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.

I guess "less" makes sense if you're talking about the amount of code, rather than about the number of lines.

The 'Fewer' has the advantage of being grammatically correct, but it loses the pleasant alliteration :)

This is a working title; we'll use this input at late-binding when we finalize what we're going to call this.


It's still valid using less, though we could pedantically argue senantics.

Lines of code is often used as a term of expense, or expressing a form of cost associated with technical debt. In that context, saying, "500 Lines or Less", is similar to "$50 or less".

Is there any other way to argue semantics?

Just "500 Lines" also sounds better.

Or even '500 lines, max'.

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.

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.)

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.

I'm actually all for books like this.

Good point. Tangentially, assembly language is extremely modal. Logic can be coded in almost exactly the same number of lines as any high-level language. Compare-and-branch is a single line as in any language.

But compositing data (building argument lists or structured data) can be exhaustingly wordy. A single call with 2 or 3 arguments can take a hundred lines of assembler.

So it all depends.

And even Asm, while traditionally one-instruction-per-line, can have macros and some syntaxes like RosAsm's allow more than one instruction per line:


Oh how I'd like a compilation of 500L APL programs.

I worked on a billing system that was written in APL, maybe 60 functions at 5-10 lines each. The corresponding manuals (one development, one user guide) were both over 300 pages.

Maybe some of the APL mavens can do the existing examples in APL and explain them. The write density of APL is pretty amazing. Depending on what you are doing a clear winner at code golf.

I guess that system could deserve a 4 year cursus to reach understanding. APL breeds fields.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact