Language Inhibits Refactoring

As a special case of LanguageChoiceImposesSocialStructure, we find that some computer languages, by their very design, inhibit refactoring. That is, the design of the language makes it difficult to improve the design of the program after the fact, without changing its behavior.

Examples: Related: MissingFeatureSmell


A computer language which inhibits refactoring encourages BigDesign. A computer language which makes small changes costly inhibits explorative programming and prototyping, and thus encourages BigDesign. This is most often symptomatic of the ``We Design, You Code'' types of outfits. Thus, perhaps LanguageChoiceImposesSocialStructure. In a social structure where information flows downwards from a pyramid, manifestly typed languages like CeePlusPlus are a natural choice, where information gloms into a BigBallOfMud, LispLanguage or SmallTalk would be a better choice.

The last sentence there seems to be saying the opposite, i.e. that social structure imposes, or at least influences, language choice. (It may not be a complete coincidence that after the company that I work for was purchased by a larger, more hidebound corporation, the decision was made to rewrite our Smalltalk product in C++.) My own opinion is that it cuts both ways. An organization with a minimum of rules is more likely to choose an DynamicallyTyped language like Smalltalk. Smalltalk in turn encourages a freewheeling, do-your-own-thing style which has an impact on the organization's culture.


...inhibit refactoring...

I wonder what language was in the OP's mind when he wrote this. Never came upon a language that inhibited refactoring. The only thing that really inhibits refactoring is the anxiety to introduce errors while refactoring.

A: Specialized languages tend to inhibit refactoring.

Relational Database Stored Procedures often have arbitrary limitations on size, nesting level (number of nested calls allowed), and data structures. And, communication with host programs is usually quite limited. Sybase/SQLServer don't allow the call stack to be more than 16 levels deep. In practice, things get unreliable beyond 12.

I've hit size limitations on Sybase and Ingres procedures/triggers. -- JeffGrigg

In COBOL it's easy to refactor flow of control, but data is a problem because it all must be global to the program. You can break a program into separate programs (or even multiple programs in one file, as of COBOL-85), but the complete lack of user defined types (as of COBOL-85) makes it almost impossible to pass data around between programs. OK, maybe you can use "copy members" (COBOL's version of #include files) to simulate user defined types, but it ain't pretty. (...not to mention resulting in programs that would be scary for 99.999% of COBOL programmers who might see it.)

Old versions of FORTAN and BASIC lacked user defined types. Early versions of BASIC lacked parameterized function/subroutines; try global variables and GOSUB. PICK Info/BASIC imposed a severe performance penalty on each call to a parameterized subroutine (...which were always "external" and "dynamically linked.") Life was difficult.

Don't get me started on dBASE-II or dBASE-III: Limits on number of variables, total size of all data, no local variables, and more... -- JeffGrigg

Refactoring SQL can be an interesting experience. (Also, you may or may not be refactoring the database design at the same time, to solve SQL problems.)

However, I've found that refactoring is possible in all languages I've ever used. It may be more or less difficult, but it's always possible, and always worthwhile. -- JeffGrigg

"Inhibit" can mean "absolutely forbid", or it can mean "discourage". I think this page is about the second meaning but some authors are using the first.

Storing data in a relational database can make refactoring difficult, because it's difficult to refactor the data in the database.

The actual syntax of saving data, changing table structure, and creating new tables with a new design is annoying enough, but most large organizations also impose procedural complexity: All work that changes a relational database in any way must be done through some other independent group. (No exceptions allowed, typically.)

There are good reasons why database work should be done by a separate DBA group, but it does inhibit refactoring.

If you think of the structure of the database as just another piece of code, then a separate DBA group is a form of code ownership: they own the database-structure code. See RefactoringWithRelationalDatabases for more.


I would probably list assembly language as a language that inhibits refactoring. Assembly based program often uses direct manipulation of registers and it can be quite difficult to keep track of what goes where. It also makes it quite difficult to see similar functions for reduction. Refactoring is still worthwhile, but the language does tend to make it a few degrees more difficult.

EditText of this page (last edited July 8, 2010) or FindPage with title or text search