DedSec Project

Language index — DedSec Project

Language index 111 curated language or dialect introductions, categorized below. Array programming languages - APL — Programming_Languages/Array/APL.md - BQN —…

111 curated language or dialect introductions, categorized below.

Array programming languages

Smart contract languages

Configuration languages

Creative computing

Databases and data languages

Learning languages

Esoteric programming languages

Functional programming

Game scripting

General-purpose programming

Hardware description languages

Historical and enterprise languages

Logic programming

Proof assistants and dependent types

Quantum programming

Scientific and numerical computing

Automation and shell scripting

Graphics shader languages

Systems and low-level programming

Web and typed web languages

The examples are introductory and version-dependent. Keep lessons updated against official specifications; the catalog is not exhaustive.

Using the programming workbooks without repetitive boilerplate

The booklets concentrate on the particular syntax, invariants, counterexamples and laboratory problems of each language. Use this shared method once rather than copying its paragraphs into every page.

  1. Describe the environment. Record compiler/interpreter version, OS, runtime backend and permissions. A snippet can be valid in a dialect but invalid in a different release.
  2. Isolate the claim. Identify which source expression, state transition, type, proof, shape or memory operation you wish to understand. Predict output before running.
  3. Maintain a control. Save the provided starter unchanged. Execute experiments in a separate scratch file, using synthetic data and local/test environments.
  4. Test both sides. At minimum cover normal input, an edge value and an intentionally invalid case. A rejected input needs an explainable failure, not a disabled check.
  5. Record the evidence. Keep source, exact command or host action, observed output, error diagnostic, and a one-sentence explanation. Compilation alone does not establish runtime correctness or safety.
  6. Review platform differences. GPU shader hosts, hardware simulators, proof checkers, blockchain sandbox chains and proprietary IDEs each have capabilities that differ from ordinary shell execution.
  7. Extend only after verifying. Add a test before an optimization. Re-check behavior for Unicode, numeric limits, empty inputs, resource lifetimes or authorization where relevant.

Each workbook has one concrete technical focus. Its neighboring Mastery Pathway, Practical Code, and Technical Notes files (when present) provide complementary material, not a second copy of the same narrative. If a language has no known runnable example for a target platform, mark it as unverified rather than inventing results.