Dustin Getz

For a long time I thought Hyperfiddle's key benefit was strong composition, but I was confused.

Strong composition is not a key benefit (what is the thing the user seeks?), nor a key differentiator (how does it work?), but rather a value (an important belief that shapes one's decision making).

Having teased this apart, now I can pitch the benefit of strong composition in a way that speaks to a user's need:

For savvy product engineering teams with large UI surface area, Hyperfiddle is a domain specific programming language specialized for web UI. It lets you use plain function composition to wire up complex UIs without pain, bugs, or thinking about data plumbing ever. Unlike existing web frameworks that separate frontend and backend, Hyperfiddle's “distributed dataflow” architecture reunites frontend and backend into a coherent reactive expression.

Key Benefits (what is the unique value I get from your thing?)

• plain function composition

• no pain, bugs, or thinking about data plumbing ever

• no schedule slips due to unplanned work

• never have to tell your boss "it doesn't work like that" ever again

• no debugging, no QA/test pain, no JIRA ticket pain
  

Key Differentiators (That's crazy or not credible, how can that be possible?)

• distributed dataflow architecture

• compiler-managed network

• zero plumbing code because it is inferred by the language

• lightweight (5000 LOC for entire stack)

Values (important beliefs that guide us)

• strong composition (lambda)

• personal mastery

Principles (things we hold axiomatic that guide our values)

• uncompromising power

• human potential manifests in individuals

“If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Human potential manifests itself in individuals. To realize this potential, we must provide a medium that can be mastered by a single individual. Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be changed or that is not sufficiently general is a likely source of impediment.” — Dan Ingalls, Design Principles Behind Smalltalk

First, some definitions:

• DAG = Directed Acyclic Graph. DAG is the graph data structure that represents a program with visual flowchart syntax

• AST = Abstract Syntax Tree. AST is the tree data structure that represents a program with textual hierarchical }}}} syntax. E.g. Javascript, Clojure

• LOC = Lines Of Code, this is a quick measure of scale and complexity of a codebase

The four problems:

1. Expressiveness problem – do closures and higher order functions have equivalents in DAG langs? Are DAG langs and AST langs equivalent in expressive power? Do they have exactly matching syntax elements or are there subtle differences?

2. Spaghetti code problem – Commercial web codebases are 10k – 100k LOC with lots of technical debt, visualizing “spaghetti code” as a DAG may not be practical if it merely reveals that everything is connected to everything

3. Logical/physical impedance problem (side-effect problem) – Web codebases are about 10% pure function logic, 90% imperative effect orchestration (streaming backend, client/server data sync, reactive view, fine-grained dom maintenance, error handling and fault tolerance, edge-cases, performance at scale). DAGs are good at logic but what about effects?

4. Density problem – Even for tiny 50 LOC ASTs, the DAG representation may take far more space

An information system is an integration of many data sets that ensure successful completion of a business objective. They help keep data organized and perform analysis, usually converting raw data into useful information for decision making.

Information systems are not standalone, rather they integrate people (users), business processes, and Information Technology (hardware and software) to help people complete their tasks.

Historically, information systems are used mostly by employees inside business organizations rather than independent individuals, because businesses operate processes at a much larger scale that demands computer assistance despite its cost. However, that is changing rapidly.

People make decisions on three levels: operational, management, and strategic. Because information systems are built to serve the needs of people, all six kinds of information systems fall into those three categories.

1. Transaction Processing Systems (operational)

2. Office Automation Systems (operational)

3. Knowledge Management Systems (operational)

4. Management Information Systems (management)

5. Decision Support Systems (strategic)

6. Executive Support Systems (strategic)

1. Transaction Processing Systems

• Billing, banking, hiring, inventory, customer relationship management, payroll, shipping

• Control and management of a service or routine activities

• Reliable, accurate, transactional, safe, secure, accessible to users

• Structured data

2. Office Automation Systems

• Printing, mailing, calendar, email, directory, reports

• Streamline clerical and managerial daily tasks

• Optimize communication, improve collaboration across departments

• Network of tools, technologies and people

3. Knowledge Management Systems

• Employee training materials, company policies and procedures, FAQs, sales database, competitor database

• Provide access to external information needed by workers who need outside knowledge to complete their roles, i.e. access to competitor data to help sales optimize pitching a customer

• Ensures technical capabilities are consistently integrated across the org

4. Management Information Systems

• furnish reports and data in aggregate form to help management monitor performance, optimize decision making related to organization’s core functions (meet targets and oversee business units)

• Sales summaries, performance data, historical records

• integrated with the org's transactional systems

• semi-structured data

5. Decision Support Systems

• Process information to help managers make the right decisions at the right time, create and gather evidence

• i.e. a bank manager will assess evolving loan trends to determine which yearly loan targets to meet

• Can analyze information that is rapidly changing and cannot easily be determined in advance

• Automated, human operated, or both

• Unstructured data

6. Executive Support Systems

• Senior decision making; like DSS but graphical representation of a broad view

• track internal performance, monitor competitors, pinpoint growth opportunities, see internal compliance issues

• Unstructured data

To answer this we need to follow the money. Who is paying developers, why, and where does the money come from? Then we can see what developers are really being paid to do.

Kinds of software development

• Data intensive cloud applications

• Business intelligence

• Productivity and creativity

• Websites

• Mobile apps

• Games, VR

• Devices / Internet of things

• Systems, Embedded

All of these categories are about people trying to accomplish something real, but using high frequency automation to be bigger/better/faster/cheaper. For example, a video game is a high frequency version of a board game.

Software is about solving problems for people, bigger/better/faster/cheaper

• Developers are not the top of the food chain; entrepreneurs are

• Entrepreneurs identify demand (a large problem so strong and hard to address that people will pay to have it solved for them) and then assume the investment risk of delivering what is demanded

• Entrepreneur's goal is to first figure out a process that reliably delivers the value, then repeat and scale that process bigger/better/faster/cheaper

Entrepreneurs hire developers to scale business processes with software

Three maturity stages of a business process:

1. Manual process (process not yet known) – decisions are made on the fly by humans, error-prone, slow, low volume, still figuring out the processes and necessary data inputs

2. Model of process (i.e. flowchart) – key decision points known, data inputs known, repeatable, faster, fewer errors, higher confidence, lower risk

3. Scale process with software automation – higher frequency/volume, lower risk. Hire developers here. As larger scale reveals new problems and constraints, loop to #2.

(Tons of projects go wrong by writing code before the process is understood. The word "develop" means "to aid in the growth of; strengthen". If you don't have an existing working process to develop, what you're doing is not developing, it's gambling.)

Developers don't create software from scratch, they source and integrate preexisting components

Developer job description:

1. source the best data/modules from the software supply chain (APIs, FOSS)

2. integrate the data/modules by coding software machinery/plumbing that brings all data into one place for business process execution.

3. model business process as logic (data analysis logic, decision making logic, action logic)

Logic (#3) is actually NOT the developer's job

In game development, the logical models are developed not by programmers, but by creatives using light scripting languages. Sometimes this is modeled with "no-code" visual flowchart elements, but much game logic is so straightforward—if statements and functions—that the creative prefers to just code the scripts directly, rather than proxy the exact same logic as a flowchart.

It is the same with websites, mobile apps, business intelligence ... Logic is so straightforward that it is done by creators where possible to avoid the cost of developers.

Unless, like in information systems, logic is interwoven with machinery.

Information systems source and integrate data from so many sources (i.e. UI, APIs, databases, event streams) that the integration plumbing complexity dominates any efforts to unify the data into one place for scripting.

This causes the integration complexity to infect the logical model and they become interwoven. Once this happens, the logical model can only be fully understood by understanding all of the machinery it's interwoven with. Only a developer can do this, a business analyst has no shot.

This is an accident! It would be better if business logic was modeled by business specialists. Your total cost of software development would be massively reduced.