📖
A General Introduction to Contextual Programming
  • A General Introduction to Contextual Programming
  • Chapter 1 - Thinking Contextually
    • 1.1 What is a Paradigm?
    • 1.2 What is Contextual Programming?
  • Chapter 2 - Creating Context
    • 2.1 Organizing Data
    • 2.2 Decorators
    • 2.3 Adaptation
  • Chapter 3 - Evaluating with Operations
    • 3.1 Hello World!
    • 3.2 Expanding on 'When'
    • 3.3 Operation Hierarchies
  • Chapter 4 - Reacting with Behaviors
    • 4.1 Revisiting Hello World!
    • 4.2 From 'When' to 'Whenever'
    • 4.3 Working with Buckets
    • 4.4 Expanding Purpose
    • 4.5 Adapting Behaviors
  • Chapter 5 - Abstracting Evaluations
    • 5.1 Compositions
    • 5.2 Operables
  • Chapter 6 - Abstracting Contexts
    • 6.1 Contracts
    • 6.2 Context Identifiers
  • Chapter 7 - Looking to What's Next
    • 7.1 Final Thoughts
    • 7.2 Additional Resources
Powered by GitBook
On this page
  • A Way of Thinking
  • Imperative Programming
  • Declarative Programming
  • An Analogy
  • Influence on Languages
  • Paradigm-Specific
  • Multi-Paradigm
  • In Practice
  1. Chapter 1 - Thinking Contextually

1.1 What is a Paradigm?

A Way of Thinking

In the field of programming, a paradigm defines a way of thinking. There are many programming paradigms and sub-paradigms (often referred to still as their own paradigms). The relationships between the different paradigms are often described in a (mostly) tree-like structure, where more specific paradigms descend further down the tree. At the highest level, most sub-paradigms fit under one of two paradigms.

Imperative Programming

The programmer is thinking about 'how' to explicitly solve the problem. This may include the individual operations of an algorithm or how different data structures may be managed/related.

Declarative Programming

The programmer is thinking about 'what' steps will solve the problem; they are considering in what way the solution can be described but they aren't as concerned with the actual operations of a specific algorithm or exactly how the data is shaped.

An Analogy

Sometimes it can be helpful to have an analogy for these kinds of abstract concepts, as such, consider the following:

A person travels a long way, seeking to better understand the difference between high-level programming paradigms. Eventually, the person reaches a small temple seated on top of a large hill. Behind the temple is a beautiful pond. Within the temple is a wise programmer who has retired here.

The person asks the programmer whether they can teach them about programming paradigms. The programmer looks out at the pond and asks the person to tell them something specific and true about the pond in its current state. The person looks at the pond for a while, and watches as a number of ducks land in the pond.

The person turns to the programmer and says, "There are seven ducks in the pond."

The programmer replies, "That is correct." then pauses before continuing.

"What did you do to determine this truth?" the programmer asks.

"I counted the ducks." replies the person.

"How did you count them?"

"One at a time, noting which ones I had already counted. I had considered mentally grouping them by 3s though, and then counting the groups and adding the remainder." (Note there are two algorithms here, the second of which leverages what could be a data structure.)

"It appears you already understand programming paradigms. You declared to me what you did and described your imperative through how."

Influence on Languages

Programming languages are often categorized by the paradigm(s) that they enable a programmer to follow.

Paradigm-Specific

Some languages define themselves by one or more paradigms to permit a programmer to better specialize in the methodologies of those paradigms. often target specific use cases to solve specific problems.

Multi-Paradigm

Other languages encompass many paradigms without necessarily defining themselves by any specific one. are multi-purpose and are intended to enable a programmer to use the language more generally.

In Practice

When actively developing, a programmer may not be consciously thinking in terms of any specific paradigm, and indeed, a programmer may often switch between paradigms throughout the process of solving a problem. Depending on the language, a programmer may also develop or use libraries that enable their language to better accommodate concepts of a paradigm that the language does not inherently support. All of this can create the impression that defining paradigms is not very valuable beyond academia or when first learning to program.

However, the distinction can be important to help programmers structure their thoughts and have a guiding approach to solve a specific problem. Some examples may be:

  • Manipulating a lot of mostly static data where bug-free maintainable code is a priority? Look to more Declarative practices, perhaps more specifically Functional Programming concepts.

  • Do you have specific use cases of limited and well-defined data that you need to extract information from? Look again to more Declarative practices, perhaps more specifically Logic Programming concepts.

  • Are you working with a lot of persistent but highly variable data? Consider more Imperative practices, perhaps more specifically Object-Oriented Programming concepts and even more specifically some of its design patterns that can help manage that data.

Recognizing what patterns of thinking will help solve the problem at hand can lead to more efficient development and long-term benefits for the project. Paradigms give programmers a way to structure these patterns, which enables easier learning and application of concepts, as well as innovation in the field of programming.

PreviousA General Introduction to Contextual ProgrammingNext1.2 What is Contextual Programming?

Last updated 11 months ago