diff options
Diffstat (limited to 'doc/paradigms.md')
| -rw-r--r-- | doc/paradigms.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/paradigms.md b/doc/paradigms.md index 37189854..b3c691a6 100644 --- a/doc/paradigms.md +++ b/doc/paradigms.md @@ -10,7 +10,7 @@ When programming in BQN, I almost always use array, tacit, and (slightly impure) ## Typing -BQN is a **dynamically typed** language with a coarse [type system](types.md) that only distinguishes types when the difference is blindingly obvious. There is a single numeric type and a single unicode character type. A fast implementation such as CBQN will check to see when it can represent the data with a smaller type than the one offered by the language. BQN usually avoids implicit type conversion, with the exception that many primitives automatically convert atoms to unit arrays. The fact that a data value can be applied as a function to return itself could also be considered an implicit conversion. +BQN is a **dynamically typed** language with a coarse [type system](types.md) that only distinguishes types when the difference is blindingly obvious. There is a single numeric type and a single Unicode character type. A fast implementation such as CBQN will check to see when it can represent the data with a smaller type than the one offered by the language. BQN usually avoids implicit type conversion, with the exception that many primitives automatically convert atoms to unit arrays. The fact that a data value can be applied as a function to return itself could also be considered an implicit conversion. BQN has no "pointer" or "reference" type, and uses **automatic memory management**. Its data types are **immutable** while operations and namespaces are [mutable](lexical.md#mutation); mutable data can create reference loops, which the implementation must account for in garbage collection but the programmer doesn't have to worry about. @@ -20,9 +20,9 @@ Dynamic types and garbage collection introduce overhead relative to a statically BQN is designed for **array** programming. The array is its only built-in collection type and it has many primitives designed to work with arrays. -BQN is okay for **imperative** programming. Blocks are lists of statements. Variables can be modified with `↩`, and while there are no truly global variables, [lexical scoping](lexical.md) allows variables at the top level of a file, which are similar (`•Import` with no left argument saves and reuses results, so that data can be shared between files by loading the same namespace-defining file in each). BQN doesn't directly support **structured** programming (which refers to a particular way to structure programs; it also doesn't have a Goto statement, the "unstructured" alternative when the term was coined). However, its first-class functions allow a reasonably similar [imitation](control.md) of control structures. +BQN is okay for **imperative** programming. Blocks are lists of statements. Variables can be modified with `↩`, and while there are no truly global variables, [lexical scoping](lexical.md) allows variables at the top level of a file, which are similar (`•Import` with no left argument saves and reuses results, so that data can be shared between files by loading the same namespace-defining file in each). BQN doesn't directly support **structured** programming (which refers to a particular way to structure programs; it also doesn't have a Go-to statement, the "unstructured" alternative when the term was coined). However, its first-class functions allow a reasonably similar [imitation](control.md) of control structures. -**Functional** programming is a term with many meanings. Using the terms defined in the [functional programming document](functional.md), BQN supports first-class functions and function-level programming, allows but doesn't encourage pure functional programming, and does not support typed functional programming. BQN uses **lexical scope** and has full support for **closures**. In this way BQN is very similar to Lisp, although it lacks Lisp's macro system. +**Functional** programming is a term with many meanings. Using the terms defined in the [page on functional programming](functional.md), BQN supports first-class functions and function-level programming, allows but doesn't encourage pure functional programming, and does not support typed functional programming. BQN uses **lexical scope** and has full support for **closures**. In this way BQN is very similar to Lisp, although it lacks Lisp's macro system. BQN has excellent [support](tacit.md) for **tacit** or **point-free** programming, with [trains](train.md) and intuitive symbols for combinators making it much easier to work with (in my opinion) than other languages that support this style. It's near-universally considered a poor choice to implement entire programs in a tacit style, so this paradigm is best used as a small-scale tool within a style like functional or object-oriented programming. |