lainchan archive - /λ/ - 20505
[ Return /
Go to bottom ]
File: 1480290807568.png (140.61 KB, 300x300, animegirlreadscode.jpg)
Do people actually read code? Do you?
I frequently see people recommending others to read programs, especially well written programs, but I never hear anyone say that they've just read this great piece of software, come check it out.
So I guess the question is, do people read others' code? If yes, is it actually useful? What are some good code to read? If no, why do they recommend doing it? Why are they not doing it? Is it useless, is it too hard?
I frequently see people recommending others to read programs, especially well written programs, but I never hear anyone say that they've just read this great piece of software, come check it out.
So I guess the question is, do people read others' code? If yes, is it actually useful? What are some good code to read? If no, why do they recommend doing it? Why are they not doing it? Is it useless, is it too hard?
I read code when I come across it, usually to see the different ways people go about solving problems. It's actually the way I learned to code, reading examples and different algorithms to learn different concepts.
>Do people actually read code? Do you?
Yes. I do.
>I frequently see people recommending others to read programs, especially well written programs, but I never hear anyone say that they've just read this great piece of software, come check it out.
Any one of the nice one-liners written in APL comes to my mind.
>So I guess the question is, do people read others' code? If yes, is it actually useful? What are some good code to read? If no, why do they recommend doing it? Why are they not doing it? Is it useless, is it too hard?
Yes. I do consider it useful, as reading a good book may help an author.
Donald Knuth has written some nice programs. Chuck Moore has also written some nice programs. GNU sources aren't necessarily good, but are educational in their own right.
For Donald Knuth, look at TeX or TAOCP.
Donald Knuth is credited with inventing literate programming, so a literate program is designed to be read and learned from.
For Chuck Moore, observe this implementation of the MD5 algorithm on a GreenArrays chip:
www.greenarraychips.com/home/documents/greg/AN001-141023-MD5.pdf
I found this very educational, but this references many other documents based on the chip and whatnot, so this will be the manner of document you will read, then read again after having read more of the GreenArrays documents. Regardless, it's a fascinating look at how to implement and make parallel MD5 and similar algorithms efficiently on an interesting machine type, as the chips are effectively dataflow machines.
For GNU, look at the GNU echo source and feel strange of it:
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/echo.c
Yes. I do.
>I frequently see people recommending others to read programs, especially well written programs, but I never hear anyone say that they've just read this great piece of software, come check it out.
Any one of the nice one-liners written in APL comes to my mind.
>So I guess the question is, do people read others' code? If yes, is it actually useful? What are some good code to read? If no, why do they recommend doing it? Why are they not doing it? Is it useless, is it too hard?
Yes. I do consider it useful, as reading a good book may help an author.
Donald Knuth has written some nice programs. Chuck Moore has also written some nice programs. GNU sources aren't necessarily good, but are educational in their own right.
For Donald Knuth, look at TeX or TAOCP.
Donald Knuth is credited with inventing literate programming, so a literate program is designed to be read and learned from.
For Chuck Moore, observe this implementation of the MD5 algorithm on a GreenArrays chip:
www.greenarraychips.com/home/documents/greg/AN001-141023-MD5.pdf
I found this very educational, but this references many other documents based on the chip and whatnot, so this will be the manner of document you will read, then read again after having read more of the GreenArrays documents. Regardless, it's a fascinating look at how to implement and make parallel MD5 and similar algorithms efficiently on an interesting machine type, as the chips are effectively dataflow machines.
For GNU, look at the GNU echo source and feel strange of it:
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/echo.c
>>20513
I'm not him, but I suggest comparing GNU code with competing implementations. The difference should be obvious.
OpenBSD echo: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/echo/echo.c?rev=1.10
Plan9 echo: https://9p.io/sources/plan9/sys/src/cmd/echo.c
I'm not him, but I suggest comparing GNU code with competing implementations. The difference should be obvious.
OpenBSD echo: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/echo/echo.c?rev=1.10
Plan9 echo: https://9p.io/sources/plan9/sys/src/cmd/echo.c
I read the repositories of the people I follow on github. A while ago I downloaded the source code of Quake III just to see how they did everything in C.
I just like seeing how others have solved certain problems, almost peeking into their brain so to speak. It probably hasn't dramatically helped me as a programmer but I enjoy it just the same.
I just like seeing how others have solved certain problems, almost peeking into their brain so to speak. It probably hasn't dramatically helped me as a programmer but I enjoy it just the same.
>>20513
The GNU echo implementation is heavily optimized and has many features, but is also very long.
Some people find this strange, although I don't care, actually. It's a good example of what a GNU program is, asides from GNU Hello, though.
A GNU program I regularly read source files from is Emacs, as this is very useful for writing extensions, as it locates the sources for functions and other objects for me.
The GNU echo implementation is heavily optimized and has many features, but is also very long.
Some people find this strange, although I don't care, actually. It's a good example of what a GNU program is, asides from GNU Hello, though.
A GNU program I regularly read source files from is Emacs, as this is very useful for writing extensions, as it locates the sources for functions and other objects for me.
I just like knowing how things work. if i cant visualize whats going on I really like to pour look at the source. mostly I read code if some program does somthing quicker or produces somthing more complex than I would guess beforehand.
>>20513
For reference / comparison
GNU http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/echo.c
272 lines
OpenBSD echo: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/echo/echo.c?rev=1.10
64 lines
NetBSD
http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/echo/echo.c?rev=HEAD&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
81 lines
FreeBSD
https://github.com/freebsd/freebsd/blob/master/bin/echo/echo.c
142 lines
Solaris / Illumos
https://github.com/illumos/illumos-gate/blob/f7877f5d39900cfd8b20dd673e5ccc1ef7cc7447/usr/src/cmd/sh/echo.c
148 lines.
Plan9 echo: https://9p.io/sources/plan9/sys/src/cmd/echo.c
40 lines
Toybox
https://github.com/gfto/toybox/blob/master/toys/posix/echo.c
96 lines
Apple
https://opensource.apple.com/source/shell_cmds/shell_cmds-149/echo/echo.c
137 lines
Suckless
http://git.suckless.org/sbase/tree/echo.c
24 lines.
Unix V5 (if you trust the github poster)
https://gist.github.com/fogus/1094067#file-0-unix-fifth-edition
10 lines
Busybox
https://git.busybox.net/busybox/tree/coreutils/echo.c
348 lines.
Wine
http://source.winehq.org/git/wine.git/blob/1d09a3587814b6d6e424641a6274d7877f48cd67:/programs/cmd/builtins.c
38 lines for the function, 4836 total.
MS-DOS 2
https://github.com/BlastarIndia/msdos/blob/0e5f0c8f8d8d4e471358303da44486bffe48715d/v20source/TUCODE.ASM
21 lines for the function. 290 for the file.
ReactOS
https://doxygen.reactos.org/df/dae/shell_2cmd_2echo_8c_source.html
135 lines
Posix specification
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
172 lines or 105 lines with the blank lines excluded.
I realise total lines is a terrible metric, but if you look at the versions of the software above the are POSIX compliant and have less lines than the specification itself vs the ones that have more, you have the opportunity to learn some interesting things about different ways and motivations for solving the same problem.
There is also the following related discussion http://stackoverflow.com/questions/3290683/bloated-echo-command and https://news.ycombinator.com/item?id=9087824
GNU coding style vs Linux Kernel coding style is a separate flame war, and determining coding styles from reading small sections of code isn't trivial.
http://aosabook.org/en/index.html is also worth taking a look as is http://rosettacode.org/wiki/Rosetta_Code to look at the different impact using different languages have on completing the same task.
For reference / comparison
GNU http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/echo.c
272 lines
OpenBSD echo: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/echo/echo.c?rev=1.10
64 lines
NetBSD
http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/echo/echo.c?rev=HEAD&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
81 lines
FreeBSD
https://github.com/freebsd/freebsd/blob/master/bin/echo/echo.c
142 lines
Solaris / Illumos
https://github.com/illumos/illumos-gate/blob/f7877f5d39900cfd8b20dd673e5ccc1ef7cc7447/usr/src/cmd/sh/echo.c
148 lines.
Plan9 echo: https://9p.io/sources/plan9/sys/src/cmd/echo.c
40 lines
Toybox
https://github.com/gfto/toybox/blob/master/toys/posix/echo.c
96 lines
Apple
https://opensource.apple.com/source/shell_cmds/shell_cmds-149/echo/echo.c
137 lines
Suckless
http://git.suckless.org/sbase/tree/echo.c
24 lines.
Unix V5 (if you trust the github poster)
https://gist.github.com/fogus/1094067#file-0-unix-fifth-edition
10 lines
Busybox
https://git.busybox.net/busybox/tree/coreutils/echo.c
348 lines.
Wine
http://source.winehq.org/git/wine.git/blob/1d09a3587814b6d6e424641a6274d7877f48cd67:/programs/cmd/builtins.c
38 lines for the function, 4836 total.
MS-DOS 2
https://github.com/BlastarIndia/msdos/blob/0e5f0c8f8d8d4e471358303da44486bffe48715d/v20source/TUCODE.ASM
21 lines for the function. 290 for the file.
ReactOS
https://doxygen.reactos.org/df/dae/shell_2cmd_2echo_8c_source.html
135 lines
Posix specification
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
172 lines or 105 lines with the blank lines excluded.
I realise total lines is a terrible metric, but if you look at the versions of the software above the are POSIX compliant and have less lines than the specification itself vs the ones that have more, you have the opportunity to learn some interesting things about different ways and motivations for solving the same problem.
There is also the following related discussion http://stackoverflow.com/questions/3290683/bloated-echo-command and https://news.ycombinator.com/item?id=9087824
GNU coding style vs Linux Kernel coding style is a separate flame war, and determining coding styles from reading small sections of code isn't trivial.
http://aosabook.org/en/index.html is also worth taking a look as is http://rosettacode.org/wiki/Rosetta_Code to look at the different impact using different languages have on completing the same task.
I wouldn't be able to do my job without reading code, as I'm fixing bugs and memory leaks in a relatively old system.
>what are some good code to read
generally C/C++ codebases behind large framework projects are hardto read yet most obligatory, new types are generally truncated to a few cryptic characters in whatever VM system they're implementing like a browser or the emacs driver. FOSS is suffering because our core C libs were mostly built and maintained by people who watched the programs grow line-by-line, function-by-function; that said running through git commits sequentially is a tedious but educational solution to that.
Lisp and python programs are (usually) an easy read, specifications of functions for both are extremely well documented in their respective hyperspecs.
Haskell programs are usually unfathomably unreadable unless you have the patience to master their clusterfuck of glyphs and whatever new definitions each library summons from the depths of hell.
the best documented code I've read is the source of TatOS, its the bare bones of what you need to make an 32-bit x86 OS capable of modifying itself and each function is commented well. It includes primitive USB drivers so running through those functions and researching the technologies used in them on wikipedia or whatever will give you an basic understanding of hardware code and a primer for exploring the linux kernel or any other OSs.
https://github.com/tatimmer/tatOS/tree/master/usb
generally C/C++ codebases behind large framework projects are hardto read yet most obligatory, new types are generally truncated to a few cryptic characters in whatever VM system they're implementing like a browser or the emacs driver. FOSS is suffering because our core C libs were mostly built and maintained by people who watched the programs grow line-by-line, function-by-function; that said running through git commits sequentially is a tedious but educational solution to that.
Lisp and python programs are (usually) an easy read, specifications of functions for both are extremely well documented in their respective hyperspecs.
Haskell programs are usually unfathomably unreadable unless you have the patience to master their clusterfuck of glyphs and whatever new definitions each library summons from the depths of hell.
the best documented code I've read is the source of TatOS, its the bare bones of what you need to make an 32-bit x86 OS capable of modifying itself and each function is commented well. It includes primitive USB drivers so running through those functions and researching the technologies used in them on wikipedia or whatever will give you an basic understanding of hardware code and a primer for exploring the linux kernel or any other OSs.
https://github.com/tatimmer/tatOS/tree/master/usb
File: 1481634742081.png (143.07 KB, 200x113, 9b49dd_2532879.jpg)
Are you a bad enough dude to write post-it notes in binary?