Comments for Embedded in Academia

Comment on Procedural Decomposition by Ramon Creager

Ramon Creager — Sat, 18 May 2013 15:30:07 +0000

I agree with Max Lybbert. When the use of functional decomposition makes code easier to read and reason about than not using it, people will use it. To this end a Minix FS driver and C is perhaps not a great choice of a learning vehicle. Use instead a functional language where using decomposition is a clear-cut advantage (the availability of all those wonderful higher order functions that take a function as a parameter, for instance). Also, use a language in which the non-use of functional decomposition quickly leads to a mess. I’ve been using Project Euler (http://projecteuler.net) to hone my Clojure skills and I’ve found that trying to solve problems inline quickly leads to a parentheses-ridden mess (Clojure being a Lisp), whereas using functional decomposition is the “lazy” approach that leads to a short and concise solution. This technique readily becomes a habit: my attempts on Clojure have made me a better Python and C/C++ programmer, even though I had already made a point of using decomposition long before learning Clojure.

Comment on Foothill Sunset by Raimondas Sasnauskas

Raimondas Sasnauskas — Mon, 13 May 2013 11:07:07 +0000

Beautiful.

Comment on Procedural Decomposition by regehr

regehr — Thu, 09 May 2013 15:13:53 +0000

Davetweed, I agree about screen size, but it’s a super rough guideline anyhow.

Regarding vertical whitespace, this is something I struggle with as a coder. When I go back to clean up some code, I usually find that the blank lines that seemed useful earlier are actually totally spurious. I think that as I write code I use them as sentence breaks but when I read code I more want them to be paragraph breaks, if you see what I mean.

Comment on Procedural Decomposition by davetweed

davetweed — Thu, 09 May 2013 14:20:26 +0000

It’s quite interesting that several people talk about fits on a “screen” as if that’s standardised. At work everyone has reasonably big (22 inch LCDs) while in personal projects I work on on the train I’ve got a maybe 7.8 inch netbook screen. (One of my pet hates is people who put blank lines every four/five lines of code within a procedure without there being any strong reason for the grouping. For me, this actually makes it harder to see the meaningful structure because it adds spurious “signal”, and if you’re going to put a blank line there why not actually put a comment in the line expressing just what the this “region” of code is dealing with?)

Comment on Procedural Decomposition by Jon

Jon — Thu, 09 May 2013 10:05:35 +0000

Good post. I don’t teach, but as a seasoned developer this resonates with me.

Just a coffee thought here…. perhaps an IDE that shows a mark if the cyclomatic complexity (or a combination of complexity metrics) of a function exceeds a configurable threshold could help. This could be accomplished with a standalone static analysis tool, but I think a tight feedback loop would be apropros when teetering on the edge of one’s cognitive capacity, as is the case when developers are faced with this situation. This would not solve the problem, but perhaps aid in “catching [yourself].”