Minimal object containing this commit
Commit Diff
commit b6e0b197086e538e8a5403691f2de8060173391211c43231e972a141f9f0eb67
Author: yihanwu1024 <yihanwu1024>
Date: Mon Jan 8 00:00:00 2024 +0000
create article with some thoughts about software integration
diff --git a/1b80fe7dce80898966a260b85d3533ce428738f5da3d147f7b73b6c1d62e1d1d b/1b80fe7dce80898966a260b85d3533ce428738f5da3d147f7b73b6c1d62e1d1d
new file mode 100644
index 0000000..4988e5c
--- /dev/null
+++ b/1b80fe7dce80898966a260b85d3533ce428738f5da3d147f7b73b6c1d62e1d1d
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="1b80fe7dce80898966a260b85d3533ce428738f5da3d147f7b73b6c1d62e1d1d">
+<title>Permeating Language</title>
+<para>Language shared across theories; the start of nontrivial integration.</para>
+<para>Integration is always <emphasis>applied</emphasis>—not pure science or mathematics.</para>
+<include xmlns="http://www.w3.org/2001/XInclude" href="ef1992a8b9e8494e6dc92234ec50bfac98e68d397cf64e5dec7dadbb2f626718"/>
+<include xmlns="http://www.w3.org/2001/XInclude" href="66f3b8e92884ca8803ab8703794a992bcf41f929d6591022c939e7668380e285"/>
+<include xmlns="http://www.w3.org/2001/XInclude" href="bb98fe705667743d269453edfa784978f9b0094dbde25629a881687562948b34"/>
+</section>
diff --git a/3ca0086a4ffc524bf4425c315c5cede2878c630b89061bb423aeb9633bce2f06 b/3ca0086a4ffc524bf4425c315c5cede2878c630b89061bb423aeb9633bce2f06
new file mode 100644
index 0000000..02c41b5
--- /dev/null
+++ b/3ca0086a4ffc524bf4425c315c5cede2878c630b89061bb423aeb9633bce2f06
@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="3ca0086a4ffc524bf4425c315c5cede2878c630b89061bb423aeb9633bce2f06">
+<title>Formal Language</title>
+<include xmlns="http://www.w3.org/2001/XInclude" href="ca7c7d0bd996ecb1711546a959e4fca297e6d9f49e085e9bc5acd205384011f1"/>
+<include xmlns="http://www.w3.org/2001/XInclude" href="5455844c7f430c19a7ec6bd911cb003c42fd782a7167ea2e574fe5971d2dd97e"/>
+<include xmlns="http://www.w3.org/2001/XInclude" href="a9c9a30b9dc7ad78025907baf6ba614acf758ce5be94bfb58199b2f81180e7ed"/>
+</section>
diff --git a/5455844c7f430c19a7ec6bd911cb003c42fd782a7167ea2e574fe5971d2dd97e b/5455844c7f430c19a7ec6bd911cb003c42fd782a7167ea2e574fe5971d2dd97e
new file mode 100644
index 0000000..1f32aa2
--- /dev/null
+++ b/5455844c7f430c19a7ec6bd911cb003c42fd782a7167ea2e574fe5971d2dd97e
@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xml:id="5455844c7f430c19a7ec6bd911cb003c42fd782a7167ea2e574fe5971d2dd97e">
+<title>Generalization</title>
+<para>A first way to integration is generalization.
+When given many different data that are not immediately interoperable, it is sometimes possible to generalize them into a single concept with more moving parts; then the original ones become degenerate cases.</para>
+</section>
diff --git a/66f3b8e92884ca8803ab8703794a992bcf41f929d6591022c939e7668380e285 b/66f3b8e92884ca8803ab8703794a992bcf41f929d6591022c939e7668380e285
new file mode 100644
index 0000000..7319b89
--- /dev/null
+++ b/66f3b8e92884ca8803ab8703794a992bcf41f929d6591022c939e7668380e285
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xml:id="66f3b8e92884ca8803ab8703794a992bcf41f929d6591022c939e7668380e285">
+<title>Naming</title>
+<para><emphasis role="strikethrough">Naming things is too difficult in programming, so I am going to give up naming them.</emphasis>
+Naming things with what we consider as a name has unintended consequences.
+Each object we want to name usually needs a longer description between theories, but short names are still necessary for us to speak within one theory.
+In the end we cannot avoid “levitating” these names if we want the system to be fully open to integration.
+It does more than just eliminating naming conflicts.</para>
+<para>See the other article, <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="51879e1b92b94e99adada564e0094bdaa961fd98764a4ba4998ad54e89ee2159">UID Everything!</link></para>
+</section>
diff --git a/a9c9a30b9dc7ad78025907baf6ba614acf758ce5be94bfb58199b2f81180e7ed b/a9c9a30b9dc7ad78025907baf6ba614acf758ce5be94bfb58199b2f81180e7ed
new file mode 100644
index 0000000..1b4775b
--- /dev/null
+++ b/a9c9a30b9dc7ad78025907baf6ba614acf758ce5be94bfb58199b2f81180e7ed
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xml:id="a9c9a30b9dc7ad78025907baf6ba614acf758ce5be94bfb58199b2f81180e7ed">
+<title>Frame of Reference</title>
+<para>One very concrete, <emphasis role="strong">approachable yet fake</emphasis> class of integration problems.</para>
+<para>3D modeling software use different conventions for the X, Y, Z axes.
+Earth’s longitude has an arbitrary zero.
+Different measurement scales are established for the same (classical) universe, and the one we are using has little metaphysical significance.
+But these systems are not always designed with coordinate conversion in mind; they have their very “native” convention.
+To integrate them is to tell what coordinates are equal, but without forcing everyone to use a canonical convention.</para>
+<para>The above is not a real integration problem; actual integration problems rarely appear in one environment.
+If I work with world-scale data, I have no problem deciding on using latitude and longitude all the time.
+If I have a smaller setting that is, say, a building on the ground using Cartesian coordinates, and want positions converted back and forth, there is a mathematically straightforward way.
+But it is not conceptually straightforward in the first place.
+For example, the use case possibly makes it conceptually invalid to operate on something 1,000 km away from that building’s coordinate system.
+A conceptual difference, although possibly small, should exist in an integration problem of the nontrivial category: the components to be integrated originally had different purposes.</para>
+</section>
diff --git a/bb98fe705667743d269453edfa784978f9b0094dbde25629a881687562948b34 b/bb98fe705667743d269453edfa784978f9b0094dbde25629a881687562948b34
new file mode 100644
index 0000000..9e04bc7
--- /dev/null
+++ b/bb98fe705667743d269453edfa784978f9b0094dbde25629a881687562948b34
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xml:id="bb98fe705667743d269453edfa784978f9b0094dbde25629a881687562948b34">
+<title>Application Programming Interfaces (APIs)</title>
+<para>The concept of application programming interface is typically defined as “a set of defined rules that enable different applications to communicate with each other” (<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.ibm.com/topics/api">IBM</link>).
+Usually we can imagine a set of library functions, or REST server, or system calls.</para>
+<para>A good characterization of the concept of API has been extremely challenging.
+A few arguments have helped or clarified the goal:</para>
+<itemizedlist>
+<listitem>
+<para>APIs are more than data interfaces.
+They can also pass functions (such as signal handlers and higher-order functions) and metadata (such as a type to be used in a template).</para>
+</listitem>
+<listitem>
+<para>All APIs use verbs explicitly or implicitly, most common of which are put and get.
+This verb may have been encoded as a request type or even port number.</para>
+</listitem>
+<listitem>
+<para>A successful analysis must work regardless of what endpoints (server, client, or more exotic) an API has.</para>
+</listitem>
+<listitem>
+<para>A successful analysis must be compatible with both real-world and abstract data.</para>
+</listitem>
+<listitem>
+<para>The common notion of API requires it being exported by the programmer.
+Presently, a software is by default not integrable; it executes uninterrupted on its own without breakpoints.
+Any integration requires additional, explicit mechanisms.
+But even if the programmer never considers exposing an API, it can still conceptually obtain.
+To continue this discussion we shall include all potential APIs, whether or not they have been implemented by the developer.
+This has the additional benefit of stripping away the directionality and intended use of the program.</para>
+</listitem>
+<listitem>
+<para>Exporting an API is usually trivial once the programmer has it in mind.</para>
+</listitem>
+<listitem>
+<para>Human intuition about the API plays a huge role.
+In fact, APIs exist for humans to use.</para>
+</listitem>
+<listitem>
+<para>Protocols are also APIs.
+They should be properly characterized.</para>
+</listitem>
+</itemizedlist>
+<para><emphasis role="strong">Claim 18ef4a0e.</emphasis><emphasis>An API is a coherent cross-section of a program.</emphasis> An API conceptually obtains at a certain place in software, if there correspondingly exists an acceptable coherence criterion.
+This acceptance is completely up to a model understood by a human.</para>
+<para>Incidentally, Robert Kowalski: Algorithm = Logic + Control.</para>
+<para>Within an unintegrated program, the language is consistent because its author made it so.
+The process used to arrive at coherence is abstracted away from its API, but is still part of a reality described by the program.
+Its integration with other programs will describe reality as conforming to both components.
+The API transfers this coherence between components, using external information such as human attestation to form a bigger picture of reality that is more than the sum of its parts: the components can now “expect” (although not being made to), that the data passed in conforms to new criteria resulting from this integration.
+This information exists only in the mind of the developer.</para>
+</section>
diff --git a/ca7c7d0bd996ecb1711546a959e4fca297e6d9f49e085e9bc5acd205384011f1 b/ca7c7d0bd996ecb1711546a959e4fca297e6d9f49e085e9bc5acd205384011f1
new file mode 100644
index 0000000..fb8f666
--- /dev/null
+++ b/ca7c7d0bd996ecb1711546a959e4fca297e6d9f49e085e9bc5acd205384011f1
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xml:id="ca7c7d0bd996ecb1711546a959e4fca297e6d9f49e085e9bc5acd205384011f1">
+<title>Computation</title>
+<para>How can some layperson easily program?
+Would this require them to learn a programming language?
+Such perspective places too much attention to, metaphorically, how software is built from the logic gates.
+Computation has no such nature.
+Any formal and sufficiently expressive language is capable of generating correct structures pertinent to the subject matter.
+The word “formalization” in the usual sense is exactly what is needed to derive such a language.</para>
+<para>Ideally, a programming language should be able to express this language of business logic as closely as possible; it should never require workarounds.
+But of course at the same time, programmers must not feel obligated to use as many language features as possible.</para>
+</section>
diff --git a/d69595f0d62231719e0995b13a0b00fb6fd8590680e50fe64abf05403baa4dc5 b/d69595f0d62231719e0995b13a0b00fb6fd8590680e50fe64abf05403baa4dc5
new file mode 100644
index 0000000..ed9c430
--- /dev/null
+++ b/d69595f0d62231719e0995b13a0b00fb6fd8590680e50fe64abf05403baa4dc5
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="utf-8"?>
+<article xmlns="http://docbook.org/ns/docbook" xml:id="d69595f0d62231719e0995b13a0b00fb6fd8590680e50fe64abf05403baa4dc5">
+<title>Thoughts on Software Integration</title>
+<include xmlns="http://www.w3.org/2001/XInclude" href="d89bce2a56e89878f3b40ccc829b22707d633f1bc56ff3d8aecad2e003d18f55"/>
+<include xmlns="http://www.w3.org/2001/XInclude" href="f3a55b5b7626d733baabf06d9c381e42ca6dc74888e767b31820e8009f3d4ba4"/>
+<include xmlns="http://www.w3.org/2001/XInclude" href="3ca0086a4ffc524bf4425c315c5cede2878c630b89061bb423aeb9633bce2f06"/>
+<include xmlns="http://www.w3.org/2001/XInclude" href="1b80fe7dce80898966a260b85d3533ce428738f5da3d147f7b73b6c1d62e1d1d"/>
+</article>
diff --git a/d89bce2a56e89878f3b40ccc829b22707d633f1bc56ff3d8aecad2e003d18f55 b/d89bce2a56e89878f3b40ccc829b22707d633f1bc56ff3d8aecad2e003d18f55
new file mode 100644
index 0000000..8a160ac
--- /dev/null
+++ b/d89bce2a56e89878f3b40ccc829b22707d633f1bc56ff3d8aecad2e003d18f55
@@ -0,0 +1,21 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="d89bce2a56e89878f3b40ccc829b22707d633f1bc56ff3d8aecad2e003d18f55">
+<title>The Problem</title>
+<para>People have been writing adapter code since the first software, and into every next software.
+There are many ways to phrase the problem.</para>
+<itemizedlist>
+<listitem>
+<para>Software, which is built “from the ground up”, is usually not integrable.
+But natural language always finds a way to work.
+How can we design a software system where the human power of natural language is exploited deeply enough, so integration becomes natural?</para>
+</listitem>
+<listitem>
+<para>Everything a computer processes is formal.
+We only need humans to intervene at the right places so it works as we want.
+Where?</para>
+</listitem>
+<listitem>
+<para>If we are willing to give up optimization, can a good framework of software integration exist?</para>
+</listitem>
+</itemizedlist>
+</section>
diff --git a/ef1992a8b9e8494e6dc92234ec50bfac98e68d397cf64e5dec7dadbb2f626718 b/ef1992a8b9e8494e6dc92234ec50bfac98e68d397cf64e5dec7dadbb2f626718
new file mode 100644
index 0000000..9611daa
--- /dev/null
+++ b/ef1992a8b9e8494e6dc92234ec50bfac98e68d397cf64e5dec7dadbb2f626718
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xml:id="ef1992a8b9e8494e6dc92234ec50bfac98e68d397cf64e5dec7dadbb2f626718">
+<title>Protobuf, <foreignphrase>etc</foreignphrase>.</title>
+<para>When I used <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://protobuf.dev/">Protobuf</link> for the first time I realized it was some kind of secret weapon in development.
+It allows programmers to define a data interface once, then use it across languages, and between endpoints.
+It is powerful not only because it lets you skip writing the same definition in different languages, but also use the exact same definition across languages, eliminating inconsistencies due to language features.
+While it is less expressive for static data than actual programming languages, semantic stability is where it wins the game.</para>
+<para>There is a further point in this semantic stability.
+Because Protobuf can deserialize directly to an object, there is no need to use a factory design pattern or any processing specific to the protocol.
+The factory design pattern indicates a semantic discrepancy between endpoints.
+By plugging directly into the semantics of the business logic, the project contains less crap of both code and semantics.</para>
+</section>
diff --git a/f3a55b5b7626d733baabf06d9c381e42ca6dc74888e767b31820e8009f3d4ba4 b/f3a55b5b7626d733baabf06d9c381e42ca6dc74888e767b31820e8009f3d4ba4
new file mode 100644
index 0000000..4147488
--- /dev/null
+++ b/f3a55b5b7626d733baabf06d9c381e42ca6dc74888e767b31820e8009f3d4ba4
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="utf-8"?>
+<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="f3a55b5b7626d733baabf06d9c381e42ca6dc74888e767b31820e8009f3d4ba4">
+<title>Most Valid Arguments Yet</title>
+<itemizedlist>
+<listitem>
+<para>Different natural languages can convey the same meaning; there is no point of deciding on a “standard” natural language.</para>
+</listitem>
+<listitem>
+<para>If everything is to be integrated as effectively as natural language, its system must be extremely inclusive—even forcibly so.
+At least any well-formed idea must be expressible.
+But at the same time this system should <emphasis>do</emphasis> nearly nothing.</para>
+</listitem>
+<listitem>
+<para>Considering that well-formed ideas are possible without having to resort to a “formal system”, a “formal system” is not what we are directly looking for.
+Here, “formal system” falls into what I found to be a narrow sense, <emphasis>viz.</emphasis> logic, type systems, <emphasis>etc.</emphasis> Designing a formal discourse does not require that level of generalization, however this is not a declaration of their unfitness.</para>
+</listitem>
+<listitem>
+<para>Applied computation happens on a theory which has the world as a model.
+Such computation is never the world as it is in itself.</para>
+</listitem>
+<listitem>
+<para>The human intelligence, not any static theory of language, has always been accomplishing integration tasks.</para>
+</listitem>
+<listitem>
+<para>
+<emphasis role="strong">Claim c99b5b66.</emphasis>
+<emphasis>There exists no tool to humanity which is not <link xlink:href="https://en.wikipedia.org/wiki/Polymorphism_(computer_science)">polymorphic</link>.</emphasis>
+</para>
+</listitem>
+<listitem>
+<para><emphasis role="strong">Claim 18ef4a0e.</emphasis><emphasis>An API is a coherent cross-section of a program.</emphasis> An API conceptually obtains at a certain place in software, if there correspondingly exists an acceptable coherence criterion.
+This acceptance is completely up to a model understood by a human.</para>
+</listitem>
+<listitem>
+<para>The true nature of integration is obscured by the complications of imperative communication, error handling, lack of imagination, and building too hastily from existing blocks.</para>
+</listitem>
+</itemizedlist>
+</section>