- 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
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.
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.
Don't you think including huge external libraries like that defeats the spirit of showing things that are 500 lines or less?
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.
Though external library size can be important, does it come into play when talking about your own code structure?
> 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.
This is a working title; we'll use this input at late-binding when we finalize what we're going to call this.
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".
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.)
'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.
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.
https://upload.wikimedia.org/wikipedia/commons/5/50/RosAsmTr...
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 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...
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.
Edit: Could we take the convention on HN to always link to the README in a github repo? In this case that would be:
#readme { order: -1; }
You could add that to the page style (using a browser plugin).
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host, port))
s.send(request)
response = s.recv(1024)
s.close()
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.
Edit: An older version?
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?
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).