Technologist | Entrepreneur | Teammate
TECHNOLOGIST|ENTREPRENEUR|TEAMMATE
Programming
FINITE STATE MACHINES, EVENTS
PLZEN, D-FLAT
HASKELL
VISUAL/NO-CODE PROGRAMMING
FUDD: platform for high-quality interactive apps

FUDD: it hunts bugs!

Objectives:

  • Development methodology that increases the general quality of software produced and the speed of implementation.
  • Modern tools that tend to have viral deployement.
  • Support virtual world applications, with video, 3D, highly interactive conversations, AR, VR, haptics, etc.
  • General Programming Model that can apply to apps (Android, iOS), web browsers, messaging channels and conference calls.
  • Bugs KISS Fudd... Provide a KEEP-IT-SIMPLE-SIR environment for Haskell as JavaScript has done for Java, which lowers the bar to get more developers jump on the bandwagon and walk slowly up the learning curve while still being decently productive.

Background:

  • Elmer Fudd: he's hunting down Bugs Bunny.
  • His weapon is a lambda-scythe, it smashes bugs away
  • He's goofy, just like the Elm development community and its self-destructing evolution
  • He has a language problem
  • Google has a search language called Elmer Fudd (double check)

Key concepts:
  • Syntax: it's a super-set proper of Elm.
  • Compiler: it's a fork of Brian Carroll's fork of Elm compiler (currently 0.19.1). Uses the maj-version.min-version.elm-version to identify a release. Fudd maj-version starts at 1, given Fudd 0 = Elm.
  • Interpretation:
    • Parsing gives a serialisable AST, which is reversable (ie unparse gives the original text file verbatim).
    • Generation of a canonical equivalent.
    • Translation of canonical equivalent in :
      • JavaScript (reuse Elm), Python
      • C, D, Go, Rust
      • Wasm, Beam
    • Importing is extended to other platforms (eg JavaScript, Python) for easy reusing of existing packages.
  • Kernel: threats the outside world as an state + event + action + update system, as per Elm and Erlang approaches.
  • Connectivity Rules: per-platform rules to expand the compiler understanding of non-Fudd code and the automatisation of interfacing with these other platforms.
  • Unit testing: syntaxic constructs to express to express how to test the code that the compiler and runtime environment will use to increase the quality of new logic (recycles D idea).
  • Debug blocks: syntaxic constructs that contain temporary code that supports the development process but that doesn't belong to the production level code.
  • Interpreter: runs Fudd code in REPL format, as in Python or a browser's console. The interpreter exists in Wasm format to be able for a brownser to access a Fudd file and run it immediately, like JavaScript.
  • Debugger: provides breakpoint at expression level, call stack navigation, variable inspection and modification, REPL for immediate expression execution.
  • Browser library: connects the kernel to a browser / web app runtime environment, and :
    • can connect either at the top level (window) or DOM-entity level,
    • connects to an array of DOM entities so a single piece of logic can operate multiple parts of a page,
    • doesn't duplicate the DOM to a virtual copy, uses morphodom (or better) to embed everythign it needs to work with the active DOM and do optimised incremental modifications,
    • works well with video and webrtc elements,
    • works well with websockets,
    • works well with SVG and Canvas entities and SVG operations,
    • works well with WebGL operations.
  • Documentation: it is thourough on the Fudd platform components to facilitate the rapid development of the platform itself, and it is extensive on the application of Fudd in real-life based on community contributions.
  • Packages: bootstrap by recycling all the packages.elm-lang.org, then:
    • Create a proper database model to idenfity packages with at least the Haskell level of information,
    • Provide an utility for hosting all ASTs and further compilation results for a given release level, with an API for getting a package data (raw, processed). The utility is chainable, ie it can run on the developer's machine, then forward a compiler's request to a department service, which forwards to a hosted service, etc.
    • Support Visual Studio's Language Server Protocol for Fudd.

Open Source Model: sustains Fudd existance through a community-friendly methodolgy, meaning:

  • Learn from the errors of Elm.
  • Provide lots of "where can you contribute today?" pointers, categorised by complexity and impact on the platform.
  • Include lots of tools to hold hands of newcomers and help them provide a first delta and understand the process of incremental improvement.
  • Provide clear benchmarks for a pull request to be incorporated into the project, and review these benchmarks regularly based on a democratic community review.
  • Provide automatic analysis of a code delta to guide developers toward meeting the contribution filter benchmarks as quickly and easily as possible.
  • Provide a clear process for pull request integration: frequency, reaction to the quality of code submitted, etc.
  • Do the release process with multiple level of code quality; the top level is potentially a paid access, while the others are "very good", "ok", "wild" which implies more and more untested or partially implemented features.
  • Provide a storefront for packages (eg extra features, optimised code, etc) so that developers can monetise their efforts and users can judge of the value of the packages vs their cost.
  • Website: Face of Fudd platform. Main characteristics:
    • Built with Fudd + morphodom (DOM incremental update) and (let's say) Servant (http)+ Hasql (sql) + Cloud (distributed) + Hotswap (hot reload) + Ginger (html template) + WebSocket (websockets) + LiveView protocol.
    • Section for enrolling new developers.
    • Multiple case studies of projects that have gained from Fudd.
    • Library of short cartoonish videos, each being a 2-5m tutorial on a topic (a la Blender).
    • Package reviews, to help developers not re-invent the wheel and know about the strength and weaknesses of any package they chose to use.
    • Virtual community events to build positive momemtum and gain from people in the network (ie the anti-Elm situation).

Architecture:

  • fudd-server: extra support for compilation, incremental development on web apps, testing, package management. Its interface is HTTP/websocket, and it offers:
    • Registry and caching for packages.
    • AST serialisation (json/bzip?), and further products of compilation stages.
    • Organised storage and managemet of projects ASTs.
    • Interaction with other platforms tools, packages and themes (eg npm, pip, hugo, git).
    • Chaining for resolving non-cached packages (eg use local server, then dev team server, then dept server, then hosted server).
    • Environment configuration through a nice web interface.
    • Standard local hosting for web apps that rely on resources (eg DB, https, django).
    • Monitoring of all executing resources through a nice web interface.
    • Management of package libraries, building, testing, publishing through a nice web interface.
  • fudd: main tool, takes care of launching build, interpreter, scaffolding, etc. Additionally it:
    • Operates either using command line options, build files or a socket interface that also provides error messages in parsable format.
  • web-server: implements the fudd platform web site.
  • package DB: keeps track of all info for all packages.
  • pkg-server: implements the services for the reference package repository.
  • analyser: studies the code and judge the worthiness of packages (in production and proposed).