Reputation
80,168
Next tag badge:
288/100 score
18/20 answers
Badges
8 235 330
Newest
 Good Answer
Impact
~553k people reached

Mar
16
comment Granular versus terse coding
@Mr.Wizard Regarding the second reply of yours: I certainly remember that many times going more granular was revealing to me certain hidden inner structure. But mostly those were points of generalization, within the larger code piece. It would take me some time to find a good example of this, because in many cases I only have a final simplified result and don't already remember my path to it - but this happened to me regularly, and I will try to find some case for which I would remember a full development path.
Mar
16
comment Granular versus terse coding
@Mr.Wizard So anyway, most of the points I just made are usually relevant when one deals with larger pieces of code. The biggest difference with smaller isolated problems is that most code pieces of larger code bases are connected via larger context. And the biggest problem is to make code such that one does not have to keep all that context in mind when reading a particular piece of code. As I mentioned already, for any single isolated problem going too granular would be an overkill. The redundancy I mentioned can only be seen when you collect a bunch of similar problems.
Mar
16
comment Granular versus terse coding
@Mr.Wizard 5. ... granular functions reveal certain inner structure, which leads to significant code simplifications k. Sometimes granular functions may lead to code that reveals those generalization points I was mentioning in my general answer on code complexity.
Mar
16
comment Granular versus terse coding
@Mr.Wizard 4. ...propagated properly through entire code (such as changes of types / number of arguments for some functions), since I can insert argument checks and post-conditions easier. e. It also makes debugging much simpler, both because functions can throw inner exceptions with the detailed information where the error occurred, and because I can access them easier in running code, even when they are in packages. f. Granular code is often more extensible, because I can frequently add more functionality by overloading some of the granular functions. i. As I mentioned already, sometimes ...
Mar
16
comment Granular versus terse coding
@Mr.Wizard 3. ... DSL code, and allows me to grasp the semantics of what is being done easier. To clarify this point, I should add that when your problem is a part of a larger code base, you often don't recall it (taken separately) as clearly as when it is a stand-alone problem - simply because most of such functions solve problems which only make sense given a larger context. Smaller granular functions make it easier for me to reconstruct that context locally without reading all the big code again. d. I can better protect code from regression bugs (i.e. bugs coming from changes not ...
Mar
16
comment Granular versus terse coding
@Mr.Wizard 2. Granularity helps me on several levels, some of which I already mentioned. a. It helps to conceptually divide code into pieces which for me make sense by themselves, and which I view as parts deserving their own mental image / name. b. It helps to better understand the code after a while, because I may not remember exactly what was the idea behind the solution (well-chosen names help here), as well as which data structures were involved in each transformation (signatures help here). c. It helps to separate abstraction levels: the code combined from granular pieces reads like ...
Mar
16
comment Granular versus terse coding
@Mr.Wizard 1. I will refrain from adding replies to your replies to my answer, since I think that SE doesn't have the right format for this sort of discussions, but will try to briefly reply in comments here. For your first reply: I think the truth (for me at least) is somewhere in the middle. Not all my code looks as granular as presented in that example - in some sense, it was an intentional exaggeration to illustrate the point. In practice, the degree of granularity I use is usually mostly determined by the DRY principle - so that no essential blocks of code are repeated, even small ones.
Mar
16
awarded  Nice Answer
Mar
15
comment Granular versus terse coding
@AntonAntonov That's great! Too bad I won't be able to see it until tomorrow - I am off to sleep. But I will surely enjoy it tomorrow.
Mar
15
comment Granular versus terse coding
@AntonAntonov So please go ahead and post your answer. I am not sure I will post my answer on DSLs as a separate one - it may become a part of larger ones. We could then later combine the DSL answers into a single one, if we see that that would be advantageous.
Mar
15
comment Granular versus terse coding
@AntonAntonov That would be great! The more of that stuff we have there, the better! And I am sure you will have the stuff that we all could learn from!
Mar
15
comment Granular versus terse coding
@AntonAntonov Actually I will probably add an example of a DSL to one of my posts on large code. Personally I am very enthusiastic about DSLs, and think that this is a very underused area in the context of Mathematica programming. Surely, there are internal DSLs in Mathematica, but this technique has not been promoted as an effective programming technique to the end users.
Mar
15
comment Granular versus terse coding
This is exactly how I interpreted it anyway. Because in reality, of course I use both styles. But the utility of terse code has been emphasized by many (@Mr.Wizard being one of the most prominent proponents of this style), while granularity has not. And as I tried to explain in my answer, I view both approaches as complementary. In my view, they apply to somewhat different parts of the space of programs, and don't compete head on as much as it may sound from the formulation of this question.
Mar
15
revised Granular versus terse coding
added 662 characters in body
Mar
15
comment Granular versus terse coding
Just to be clear, there are parts of code where I don't use the "extreme granularity" approach - usually those are functions which implement certain "engines" (however small), and where parts interact too tightly (e.g. are entangled by complicated scoping structure) so that decoupling them will bring more harm than good. One such example was a dtraverse function in the same post (although even there I tried to make it as granular as possible), another is e.g. withRedefined function from this post. @Mr.Wizard
Mar
15
comment Granular versus terse coding
@rcollyer Thanks, this is it!
Mar
15
comment General strategies to write big code in Mathematica?
@AntonAntonov I think this is a very important topic which hasn't been discussed virtually anywhere in the Mathematica - related public resources. Thanks for your contribution too!
Mar
15
comment General strategies to write big code in Mathematica?
@JacobAkkerboom I am most happy to provide them. This is an important topic, and I am surprised that this question hasn't been asked long time ago. I do hope to find time to work some more on the answers, since there still is a bunch of stuff I consider useful which I did not add here yet.
Mar
15
revised General strategies to write big code in Mathematica?
Fixed a few mistakes noted by Jacob in comments
Mar
15
comment General strategies to write big code in Mathematica?
@JacobAkkerboom Thanks for careful reading! You are right on all points. The probabilities indeed are constant, and the wording I will also change. As to the proposed simplification in your previous comment, this is correct, but I will probably leave the code as it is, both due to the packed array - related complication, and also because in the current version, the generation of variants (not steps, actually, the name is a bit misleading) is decoupled from actual steps, and only depends on probabilities.