From 422f30b91b35deebf74852254c5cc43d4f93fe67 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Thu, 28 Apr 2022 11:04:04 -0400 Subject: =?UTF-8?q?=E2=80=A2Eval=20doesn't=20exist=20except=20in=20dzaima/?= =?UTF-8?q?BQN?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/doc/paradigms.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/doc/paradigms.html b/docs/doc/paradigms.html index 38093372..5542f213 100644 --- a/docs/doc/paradigms.html +++ b/docs/doc/paradigms.html @@ -19,6 +19,6 @@

BQN has excellent support for tacit or point-free programming, with trains 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.

BQN uses namespaces as modules to organize code; the only possible interaction with a module is by its exported variables. There doesn't seem to be a name for this paradigm, but there should be.

BQN supports object-oriented programming only incidentally. This is not as bad as it sounds, and programming with objects in BQN can often feel pretty similar to other object-based languages. The main differences are that objects don't have a this property to pass themselves into functions, and there's no built-in way to find the class of an object. There is also no support for inheritance, which is not unheard of in the object-oriented world.

-

BQN does not support metaprogramming such as macros or reflection, except with very crude techniques like •Eval. Functions describe computations and can easily be written, passed around, and applied: they can fill in for any use of macros or generics in a C-like language. If desired, it's easy to use lists as S-expressions to form structures that can be easily manipulated and also evaluated—roughly, embedding Lisp in BQN.

+

BQN does not support metaprogramming such as macros or reflection, except with very crude techniques like •BQN to evaluate a string. Functions describe computations and can easily be written, passed around, and applied: they can fill in for any use of macros or generics in a C-like language. If desired, it's easy to use lists as S-expressions to form structures that can be manipulated and also evaluated—roughly, embedding Lisp in BQN.

BQN does not yet have support for concurrent programming. It's likely that its strict approach to lexical scoping and encapsulation make it a good fit for concurrent execution, but designing such a system is not a priority. In contrast, array operations are ideal for parallel computing, including SIMD or GPU computation. To enable highly-parallel algorithms, the implementation must evaluate primitives (or combinations) using these algorithms, and the programmer must use primitives that have been implemented in this way. It would be possible to define a subset of BQN that restricts the programmer to code with an efficient parallel implementation, but BQN itself does not have any such restrictions.

BQN doesn't support logic programming or computer algebra, although its inferred properties might be considered a very rudimentary form of either of these. It doesn't support dataflow programming.

-- cgit v1.2.3