A good Refactoring can transform a kludgy WL code-base into a thing of pristine coherency but how to do so consistently?
$\begingroup$
$\endgroup$
3
-
$\begingroup$ Given its multiple programming paradigms and conintual influx of new constructs, the WL seems ideally placed to leverage Robert W. Floyd's following insight (yet there seems a general lack of explicit examples/codification for this process). $\endgroup$– Ronald MonsonJun 12, 2016 at 2:50
-
$\begingroup$ If the advancement of the general art of programming requires the continuing invention and elaboration of paradigms, advancement of the art of the individual programmer requires that he expand his repertory of paradigms. In my own experience of designing difficult algorithms, I find a certain technique most helpful in expanding my own capabilities. After solving a challenging problem, I solve it again from scratch, retracing only the insight of the earlier solution. I repeat this until the solution is as clear and direct as I can hope for ... $\endgroup$– Ronald MonsonJun 12, 2016 at 2:51
-
$\begingroup$ ... Then I look for a general rule for attacking similar problems, that would have led me to approach the given problem in the most efficient way the first time. Often, such a rule is of permanent value. Robert W. Floyd. $\endgroup$– Ronald MonsonJun 12, 2016 at 2:52
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
6
Main activity
In functional programming languages refactoring is considered a main activity. Ideally we derive a new language that fits the problem we want to solve. (E.g. see the preface of "On Lisp" or the article "The Roots of Lisp".)
This observation obviously does not help when we inherit code, or we have to adapt or re-design old code (because of changes in the language or our understanding).
Big Ball of Mud
The article "Big Ball of Mud" gives well researched diagnoses and prescriptions of when and how to do refactoring. It is a good answer of the request:
[...] transform a kludgy WL code-base into a thing of pristine coherency but how to do so consistently?
Using that article, we identify how we ended up with the code we want to refactor, and then utilize the given prescriptions.
The article uses a patterns language. (Partially explained, I guess, that the authors are from the same university as one of the Gang of Four.)
For MSE discussions that include using software design patterns in Mathematica / WL see these answers of "General strategies to write big code in Mathematica?":
Leonid's preamble to a large answer,
I have used the patterns in "Big Ball of Mud" to refactor large scale air-pollution FORTRAN IV code (that was fairly large) into components of an object-oriented C++ framework.
answered Jun 12, 2016 at 3:48
-
$\begingroup$ Hell, if I can read and understand my own code 24 hours later, it's prefactored enough for me ;=} , and +1 for great references. $\endgroup$– ciaoJun 12, 2016 at 4:03
-
$\begingroup$ @ciao Thanks! Did you start programming education with Perl? $\endgroup$ Jun 12, 2016 at 4:19
-
1$\begingroup$ Actually, APL and Lisp were first languages, and with the former it really was the case if you understood it the next day you were writing legible code... $\endgroup$– ciaoJun 12, 2016 at 4:24
-
$\begingroup$ @AntonAntonov Thanks for the handy overview and useful links. I wholeheartedly concur with the first two sentences of your answer but I also feel that learning how to put them into practice is perhaps not as readily met with the provided MSE links as initially suggested or perhaps that it could be. Also, I would that argue that rather than "This observation obviously does not help when we inherit code, or we have to adapt or re-design old code (because of changes in the language or our understanding)" I would instead say that this observation does help and in fact ... $\endgroup$ Jun 12, 2016 at 7:55
-
$\begingroup$ .. this is what defines refactoring since "inheriting", "adapting", "redesigning" code is what needs to take place on an ongoing basis for any sufficiently large code-base. It's almost as if refactoring takes place at two levels, at a lower level in making code snippets more readable but at a higher level in designing the entire architecture. The first can perhaps be illustrated in a MSE answer but for the latter, I wonder if one has to see a poorly designed architecture transform into a cleaner one via refactoring - which for "big code" is admittedly hard to do in "small code". $\endgroup$ Jun 12, 2016 at 7:55