Jump to content
Objectivism Online Forum

Objectivist Guidelines In Programming?

Rate this topic


Cbaoth

Recommended Posts

Hi Guys,

As a programmer I have been going over in my mind the idea of applying Objectivist principles to the process of making computer programs. I am currently reading The Fountainhead and find Rand's application of Objectivism to the field of architecture fascinating and compelling.

I am interested if the experienced Objectivists/programmers here have any objectivist principles they go by in there field of programming and if this goes against the grain of how programming is currently taught in formal institutions?

- David

(Edited to capitalize "Objectivist/m" - sNerd)

Edited by softwareNerd
Link to comment
Share on other sites

I am interested if the experienced objectivists/programmers here have any objectivist principles they go by [...]

I am an Objectivist in the sense that I agree with all of the principles of Ayn Rand's philosophy as far as I have studied it. What do you mean by "objectivist"? How does "objectivist" differ from "Objectivist"?

Link to comment
Share on other sites

Paraphrasing something Jennifer said in a seemingly unrelated post: Objectivism actually has nothing to say about [programming], apart from "apply ...reason"

With that caveat...

... Some people (I think there was a post here) have speculated that an understanding about concept-formation can help in proper logical/conceptual modelling.

... When it comes to certain things about the management of programmers, there are certain things that might raise a warning flag to an Objectivist: ideas like "ego-less development" and "pair-programming"

What aspect of programming were you thinking of? The process of writing programs or something broader -- e.g. managing the process?

Edited by softwareNerd
Link to comment
Share on other sites

softwareNerd:

I guess I was thinking of the actual code design,writing process itself. If you were going to compare good code to good buildings I would imagine you would aim for the cleanest, most efficient solutions with no spurious unnecessary code.

Link to comment
Share on other sites

If you were going to compare good code to good buildings I would imagine you would aim for the cleanest, most efficient solutions with no spurious unnecessary code.

That would definitely be one of the key principles.

Some other ones I recommend:

  • Establish a hierarchy of values with regard to the desired properties of your code, such as: speed, memory usage, terseness of the source, reusability, object orientation, locality of reference, and so on. Do not hesitate to trade a lesser value for a greater one.
  • Use blank lines to divide your code into small sections that can serve as conceptual units. Prefix each non-trivial section with a comment that summarizes what it does.
  • Choose an easy-to-read coding style and use it consistently.
  • When writing object-oriented code, keep in mind the proper way to form concepts and aim for a close correspondence between your classes and your concepts.
  • Anticipate programming tasks that will occur frequently and create generalized solutions for them.
  • Make sure you think through every possible path of execution and verify its correctness.
  • Whenever you modify something in your code, integrate it with all the rest of the code so that everything continues to function properly.
  • Divide your code into independent units with well-defined behavior in order to facilitate the above two activities.
  • When learning a new language or API, use induction: first look at some example code to see what it achieves and how, then read the formal specification so you can always be certain about what your code does.
  • Steer clear of all arbitrary considerations, including any technological fads, coding style dogmas, unsubstantiated anticipations of future requirements, and doubts of your competence to maintain your code.

Link to comment
Share on other sites

Excellent points CF.

Let me also try to respond to the "derivation from principles" approach that Cbaoth asked for, with the caveat that I'm writing as in a "top of the mind" discussion.

Software is written by programmers to achieve a particular task. So, if one were to work from first principles, one would have to consider two aspects:

1) Value: How well does the software achieve its task?

2) Cost: How much money does it cost to develop and run the software?

When considering these two, it is important to have the appropriate time-perspective (e.g. something is cheap now, but will cost you a lot in the long run; or, something may be useful only years from now, but adds significantly to current costs). When one is focussing on program design and programming, one is focussing more (but not entirely) on the Cost part of the decision. One is assuming that the specifications of functionality (i.e. value) are mostly correct.

Software is still nowhere near buildings in the sense that a specification can be created and executed by 'workers', leaving the "value-side" of the equation to the architect. Many software projects -- particularly brand-new development -- work more like a spiral: attempting to execute the solution raises further questions about the problem and may result in a redesign of the solution. A good programmer must therefore always be a bit of an architect himself, asking questions akin to: are you sure that window should go here? wouldn't that place give them a better view?

That said, suppose we use a perspective of a programmer who has a specification for what a program ought to do, and has a general idea about the amount of time that can be spent on the programming. Given that perspective, what principles does a programmer use when creating the program?

I think that, given that narrower perspective, the programmer focusses on costs. So, the next question is: what are the types of costs to be considered?

1) The proximate cost of getting the program from being an idea to being used by users.

2) Second, today's programs will have errors (bugs), regardless of what the zero-defect people say (this is related to the "spiral" issue above). So, a second cost is the ongoing cost of finding and fixing bugs.

3) If (as is mostly the case) the program will be around for some years and will be changed and improved, there is the future cost of doing so.

4) There are other things that might be considered "costs" (e.g., how much of computer resources a program needs, but are mostly better viewed as parts of the specification).

The points #2 and #3, above, would imply that it is worth spending some extra effort today to avoid too much time being spent in the future. The same is true even of #1, because the progession from idea to version 1.0 is not a straight line. It has it's own little bug-finding (#2) and functionality improving (#3) cycles within it.

Given the above background, let me address the three specific points you raised:

cleanest, most efficient solutions with no spurious unnecessary code
"Clean": In order to reduce the cost of maintaining and improving a program, one of the considerations is to write it so that it is "clean" (which really means "neat", which really means "well-organized", which really means "easily understood by a human being").

No "spurious unnecessary" code: Not sure what you mean by this. Do you mean code that is duplicated? [There are good aspects and bad aspects to having common code and components, but I'll leave that for another post.]

Efficient: This is actually an aspect of functionality/value rather than cost. (i.e. Inefficient programs could increase costs to the user. Costs to the developer are increased only to the extent to which the developer has to run the program in order to test it. An efficient program increases the value being offered by the developer to the user.)

Most (if not all) of the excellent points that CF has made can probably fit into a heirarchy that explains why it is "a good thing".

Link to comment
Share on other sites

  • 2 weeks later...

There is an article here that discusses the similarities between Object Oriented Programming and Objectivist Epistemology. According to the article, Objectivist Epistemology corresponds almost exactly to the concepts of OOP. You might find this to be an interesting answer to your question.

Link to comment
Share on other sites

...the similarities between Object Oriented Programming and Objectivist Epistemology.  ...
Similary, an earlier thread on this forum contained a speculation that there was a similarity to database design.

In one sense, of course there is a similarity: both database modelling and object modelling are trying to "model" something in the "real world". "Concept formation" is fundamental to those processes. I put the term "concept formation" in quotes, because when one is modelling for software, one is only forming concepts in the context of the computer system one is developing. In that context, however, concept formation is not just a part of the model, it is the essence.

However, I do not see how the concept-formation in the context of database or object modelling is closer to the Objectivist theory of concept-formation than (say) Aristotelian or Platonic theories. How would an object-model created by a Plato-fan differ from one created by an Objectivist? Would the former try to model things as they are without considering the purpose and context of the model? Maybe they would... I don't know.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...