I noted in my most recent progress report for TheFleet that I have a bad methodology while programming.1 One issue is I begin to implement programs before having a good understanding of what their entire structure should look like. The larger problem is I don't fully map out plans before executing them: I write articles without outlines, disassemble computers without having necessary tools, cook new meals without recipes, go to the store without a shopping list, etc. These attempts to shortcut to a goal is the hallmark of stupidity through laziness.
The "figure it out while you go" mentality is costly when programming. Testing and fixing bugs takes time; it's a huge waste if that time goes into a script that doesn't even solve your problem. The CL development environment enables bad behavior because it reduces the friction for compiling and executing small chunks of code. Sending functions into the snappy repl can make you feel like you're doing a whole lot when in reality you're getting nothing done.
For tasks like cooking there is a clear delineation between the planning step and the execution step. However the line between mapping out a problem and writing a program to solve it is fuzzy. What is a program if not a formally defined plan?
The syntax of lisp allows for perhaps the most terse possible text representation of an abstract syntax tree. Thus it might be a good exercise to make a flow chart of what TheFleet needs to do in the form of an ast.2 But TheFleet's implementation requires concepts that I am not sure belong in that notation, like threads running functions that handle random inputs at random times in the future. So I am not certain this is a worthwhile exercise.3
As a final thought, I'd like to mention my personal understanding of the folly of using Common Lisp on a modern day machine. The beauty of lisp is its ability to neatly express solutions to closed problems. But is there a benefit from a CL program that is "15% shorter" than its python equivalent if it takes 471,556 additional lines of sbcl to be able to use it?
~/sbcl-1.4.14$ cloc ./
1833 text files.
1743 unique files.
364 files ignored.
http://cloc.sourceforge.net v 1.64 T=9.72 s (153.2 files/s, 62448.5 lines/s)
---------------------------------------------------------------------------------------
Language files blank comment code
---------------------------------------------------------------------------------------
Lisp 1095 39905 75460 426310
C 105 4480 7760 31973
C/C++ Header 134 1146 1847 5423
Bourne Shell 63 767 1185 4029
Assembly 11 721 1775 2825
D 45 0 0 319
make 24 75 60 278
HTML 5 10 0 185
CSS 3 41 11 184
Pascal 1 0 0 23
Windows Module Definition 3 0 0 7
---------------------------------------------------------------------------------------
SUM: 1489 47145 88098 471556
---------------------------------------------------------------------------------------
- I have ~no methodology, just a long list of stuff I know not to do. [↩]
- As in draw one in my notebook. [↩]
- And also I'm not certain whether lisp is the best language to implement the program in either. That said I don't plan to switch my choice of language mid project. (Although if I used python would I really be switching? I did write the web scraper for netsplite.de that grabbed the networks and their hostnames and ports in python. The only function I've written so far that was actually "in lisp" imo, was make-groups)
(defun make-groups (lst group-size) "Breaks up lists into length group-size sublists, if the length of the list is not a multiple of group-size the last sublist will have a length of (mod (length lst) group-size)" (cond ( (null lst) nil) ( (< (length lst) group-size) (list lst) ) (t (append (list (subseq lst 0 group-size) ) (make-groups (subseq lst group-size) group-size) ) ) ) )[↩]
Well, um, while we're using blunt instruments...
And that doesn't even get you a compiler.
Well then, lol.
My reasoning for not noting the lines of python was : afaik python is used to implement various parts of linux so it's bundled in the OS anyways. Thus as it stands using CL means you need to add a binary formed from 471,556 LOC while using python (although also obscenely large) does not require adding a new binary to the os.
It's not really, not for anything fundamental. I do wonder now what those 24k lines in the kernel tree are for; probably some kind of testing or documentation tools or the like, but not required for the main build. Portage and yum and other higher level tools use it, sure. So like Perl, it's included by default on many systems, so may feel like a lighter dependency. I guess it depends whose environment you're trying to optimize for. But at least from the angle of understanding your own code, going with the crowd doesn't buy you much.