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