[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 20505



File: 1480290807568.png (140.61 KB, 300x300, animegirlreadscode.jpg)

No.20505

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?

  No.20506

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.

  No.20507

>>20505

Not often. I probably should, but it's hard to read large chunks of other people's code. You have to get a feel for the codebase, and that takes forever.

  No.20508

>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

  No.20513

>>20508
Since I don't write a ton of C...

What's so odd about those GNU sources?

  No.20515

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

  No.20516

>>20513

Check it out yourself, but I find the non-GNU versions to be much more readable in all cases. GNU tools often feel kind of abandonwarey.

  No.20517

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.

  No.20518

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

  No.20559

>>20513
GNU code is obfuscated.

  No.20626

>>20508
That indentation makes me sick.

  No.20628

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.

  No.20634

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

  No.20637

>>20515
>The difference should be obvious.

Well, not really as the lack of funtions make it shorter and the "sandbox" implementation is strange.
if (pledge("stdio", NULL) == -1)
err(1, "pledge");

>>20634
This echo is builtin to bash? I see Chet Ramey as author.

  No.20643

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.

  No.20645

>>20626
Are you referring to the Forth program? If so, what's wrong with the indentation?

  No.20646

>>20645
I'm talking about the indentation in the GNU program.

It's unreadable.

  No.20650

>>20646
Yeah, GNU indentation is actually awful.

Seriously, what were they thinking?

  No.20656

>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

  No.20664

>>20656
Indeed. Scheme code is also pretty easy to read (unless said code calls call/cc or one of its friends - then you're in for a fun ride).

The hardest code to read is J code. You thought Haskell was bad...

  No.20665

>>20559
I once tried to contribute to a GNU project. It almost made me think closed source was a good idea

  No.20668

>>20665
As i know contributing to gcc isn't a walk in the park. GNU is really wide so i'm sure there are newbie friendly projects too. Worth to note that they are really serious about holding copyright on the contributors work.

  No.20670

>>20665
I know the feeling, I too tried to read some GNU code (specifically: gnugo) and I was shocked that it would be so damn unreadable.

  No.20765

File: 1481634742081.png (143.07 KB, 200x113, 9b49dd_2532879.jpg)

Are you a bad enough dude to write post-it notes in binary?

  No.20768

>>20765
>not writing all your notes as hex dumps
do you even hax?

  No.20774

>>20650
GNU started at MIT where Lisp was prevalent at the time, their coding style stems from that. That's why it looks so shockingly different from other source posted.