claim

active

claim:explicitly-parallel-programs-are-not-inherently-harder-to-design-or-understand-than-functional-specifications

Explicitly parallel programs are not inherently harder to design or understand than functional specifications.

C-Linda DNA comparison is comparable in length and clarity to Crystal; pragmatic runtime granularity control outweighs compiler optimization ideals.

Source paper

extracted_from

Artificial Intelligence and Linda in Context

(1989) · Carriero, Nicholas · Gelernter, David

Neighborhood — ranked by edge-count

Communities (2)

community

Design principles for care-centered systems
members_of
Cross-scale frameworks linking spatial patterns, diagrams, and simplicity as expressions of care in design.
Denotational design and interface abstraction
members_of
Applies functional programming principles to UI structure via precise mathematical models, enabling formal verification and revealing computational architecture through interface design.

Frameworks (1)

framework

Pure Functional Programming
contradicts
A paradigm relying on recursion equations without assignment; Linda authors compare it on DNA sequence similarity problem.

Concepts (1)

concept

Linda
supports
The core parallel programming model introduced in this paper, based on tuple space operations and orthogonal to any base language.

Related by similarity (8)

cosine ≥ 0.65 · no typed edge

Entities in the same semantic neighborhood but without a typed relation to this one — candidates for new edges or unrecognized duplicates.

Pure functional languages cannot be the whole story for parallel programming because they fail to provide needed expressivity.claim0.853
Argument that recursion equations are inappropriate for many important parallel programs.
Parallel programming needn't be terribly difficult, but 'thinking in simultaneities' as in message-passing is calculated to make it difficult.claim0.820
Asserts that Linda's uncoupled style reduces cognitive load.
The strengths of all three models (concurrent OOP, logic, functional) are irrelevant to parallelism, and generally unhelpful in dealing with process creation and coordination.claim0.791
Assertion that the popular models add nothing to parallel programming.
Object-oriented concepts are irrelevant to solving parallel programming challenges.claim0.777
Strong assertion that the enthusiasm for 'concurrent object-oriented programming' is misplaced; objects do not inherently help with parallelism.
Object-oriented design is orthogonal to parallelism; 'objects' themselves do not help with parallel programming.claim0.775
Concurrent object systems reduce to message-passing or monitors; objects solve code organization, not concurrency coordination.
Object-oriented programming is powerful and attractive, but irrelevant to parallelism.claim0.774
Claim that OOP per se does not solve any parallel programming problems.
Parallel sub-tasks within skills and across skill families should produce parallel outputs for legibility.claim0.774
In parallel programming, asynchronous communication is far more common than synchronous.claim0.773
Basis for preferring Linda's out (asynchronous) to remote procedure calls.