fn

A fun programming languge.

Maybe easier to say what we hate about different languages, than what we love:

Tuning GC.
Formatting code. I don't care about opinions.
Verbosity. Long words used when short words would be fine. My screen is only so big.
Keyboard acrobatics. Code that looks like math. Syntax more like Ruby than C++.
Exception handling. Not try/catch or magic numbers.
Tools (especially compilers and type systems) that put barriers in the way of me solving my problem
- I should be able to compile and run a tiny bit of my program to find out if it works without refactoring the whole codebase, and only when it works should I need to care about all the places that I need to fix
Complex syntax
- I should be able to read the code and understand what's being expressed
  - Counter examples
    - Scala
    - Perl
Significant whitespace
- This breaks in too many situations. Eg. copy/paste, email
async/await
- This is the lowest common denominator of async programming
- Better options include
  - CSP + transducers
  - first class continuations

Things that need to be supported:

Literal data structures (at least maps, vectors/arrays, numbers, strings, nouns, verbs ... maybe sets, queues, stacks?)
- all data is serialisable / round tripable
- by nouns, I mean names for bits of information are not strings. Ie. in JSON

{
  name: "name"
}

the key name is should not be the same as the value "name". They should have distict types.

by verbs I mean names for bits of code that are equally distict from strings (and names for bits of data)
nouns and verbs need to have namespaces the same entity will need to use the same name for different values in different bounded contexts - namespaces fix this

{
  customer.id: "123"
  product.id: "456"
}

all data is immutable
transaction system to handle atomic updates to data in memory
monoidal operations on each of the collection types (identity value + operation)
- need to have a meaningful algebra for combining data
collections lib should be built around transducers (for optional lazy evaluation)
- collections should be persistent functional data structures a la Bagwell/Hickey
  - https://docs.rs/im/latest/im/
  - https://github.com/orium/rpds
mulitple dispatch
- predicate dispatch?
module system
- library fetching
- versioning
- identifying breaking changes
Tail call optimization

Good ideas that could be pilfered:

Content addressable code from unison: https://www.unison-lang.org/learn/the-big-idea/
Commas are whitespace
Common lisp condition system for error handling?

Dumb questions:

Do you need classes for anything other than state machines? Can we avoid "classes" altogether?
- Yes ;P
Use cases for programming tools
- Information processing (eg. take this order, calculate the delivery charge & tax, store it in a db ready for picking/shipping)
  - there are 3 bits to this
    - what an order looks like
    - the domain model of tax calculation, etc
    - the mechanical part of storing for retrieval later
  - standard java style classes are bad at all of this
  - maps / lists / etc are better
    - they have an abstract information model that allows introspection, combination, etc
    - they have occurrence typing and can process information in shapes they didn't know about when created
      - eg. the tax calculation can apply to orders and purchase orders without being re-written if the po has the relevant info in the right place and extra info can just be returned from a function call
    - there's a meaningful implementation of equals
    - RDF has a lot to offer / inform here
    - namespaces on names are really useful
  - everything this does should be a pure function
  - this builds a domain model
  - there should be some kind of schema library to describe and validate the shape of the data
- Mechanical processes
  - essentially this is a state machine
  - eg. writing a web server or updating a db record
  - java style classes are better at this, but not great
  - these can often be built out of smaller pieces but they're generally impure and should provide a transactional way of going from the past into the future
    - examples:
      - CSP (like go channels, clojure.core.async, etc)
      - Clojure's STM / OCaml's ref type
      - Actors (like erlang otp, and scala akka) ( - probably buildable out of the previous two?)
  - These should apply a domain model transactionally to some data
  - This sounds a lot like the disruptor pattern / cqrs / event sourcing as a fundamental design principal
  - support for runtime manipulation of processes and data
    - processes come in a few shapes
      - examples
        
        request / response (+ middleware / interceptors?)
        
        map / reduce
        
        transducers
        
        state machines
        
        concurrent execution
        
        rules engine
        
        logic engine / minikanren / prolog
      - these sound a bit like monads and should be combinable in some way????
- loose coupling
  - a lot of langs have high coupling in their default idioms
    - examples
      - mutable by default collections
      - not differentiating between the name, identity and value of something. ie.

val x = new Customer("Bob") // this says nothing about the immutablity of the Customer object, but says that `x` cannot refer to any other object, which is pointless

    - full coverage pattern matching
      - this is localised polymorphism, if you add a new value to an enum (for example) then that becomes a breaking change to any users of that enum
      - better served by destructuring + generic polymorphism??
    - async/await and other structural patterns

Serialisation
- json is not good enough - needs more data types ... and to be extensible
- code needs to be serialisable - or at least resolvable (content based addressing) - so we can send code to the data
- if we're serialising code, then the compiler needs to be available at runtime
Typo's
- dynamic langs tend to not provide tools that help catch typos
Encapsulation can fuck off
- it only creates problems and solves none
Static analysis
- type systems are both too weak and too strong
  - a map is a function with very specific mappings between it's input and output
    - static analysis should be able to track this and tell you about specific values, not just classes of values
    - see idris / coq and dependent typing
  - static analysis should be optional
    - you should be able to compile and run parts of your program without caring about warnings from a stat.anal tool
    - you should be able to query the stat.anal results for usages / etc
    - stat.anal tools should be canonical - the core lang team should provide "linters"
  - type inference is essential, however you need a different type system different use cases
    - possible use casess:
      - the compiler (if we're targeting wasm, then inferring something is a "Customer" isn't very useful - we need to get down to 64-bit ints)
      - occurrence typing for keys in a map useful for information tracking
Small simple language made out of composable pieces
- the less syntax the better
- the less obscure dsl's the better
- the less difficult reasoning the better
- the core lang should define interfaces for it's core pieces and be built to those abstractions, not concrete types
- starter for 10 as to the bits of the lang that we should build
  - reader (deserialises data and code from some kind of stream not just files, into in memory data structures (AST ?))
  - writer (serialises data and code)
  - resolver - loads code / dependencies (from git???)
  - compiler - compiles in memory data into executable code (macro expansion?)
  - evaluator - evals compiled code - on a wasm runtime?
  - linter
  - core data structures
  - core libs - divided into pure and impure

alexec / fn

fn

About