HN Explorer

Ask HN: What's missing for a true deterministic abstraction layer?

1 points by jeanpah ↗ HN
If I wanted to develop a system but in such a way that implementation is abstracted away but the same spec always yields the same system, so we as humans still understand the system and not it's implementation: what is missing? What is stopping us from such language, visualization or construction method?

Llms are not deterministic and can implement the same spec in diferent ways or slight variations, how can we get deterministic approach so we can gain development speed and accountability over our systems? Can something like that exists ?

7 comments

[ 6.0 ms ] story [ 22.3 ms ] thread
josh-wrale
Look at "purely functional programming" and the rough edges of it.
sargstuff
** simple response:

  Absolute/unchanging clarity of purpose/intent/interation between various dynamic levels/groups in an ever changing world.

  Unified audience and/or obsolescence- airplane demo[0].
  Obsolescence lot easier to acheive than 100% unified audience. No effort required for obsolescence.
** esoteric response:

  By definition, system(s) approach or systematic approach?  Both provide flexibility ( framework of abstractions ).  Flexibility and absolute determanism are opposing concepts.

 Programming language(s) & related software environments[1] could be seen as a lot of attempts at reconciling flexibility and absolute determanism. (independent of ever chaning cpu intrinsics used over years X86/amd vs. theory CISC/risc/arm/mips & and various programming levels[2]) 

  related concepts: NP != P; C language spec[1] (vs. lisp machine vs. lisp running on conventional von von-neuman hardware )
** static/dynamic response:

  Theory/what  - Unused system(s) haven't been introduced to implimentation variations.  

  Practice/how - Used Systematic approach(es) will wind up with intrinsic implimentation variations to resolve mismatches between theory/practice.

  Each will break when appropriately used.
** snarky:

   Keep it simple, split the difference and use vm/webassembly for testing/debugging, skip the implimentation & theory to get albsolute "determinism".
----------------------------

[0] : https://meyerweb.com/other/humor/osair.html

[1] : https://en.wikipedia.org/wiki/List_of_programming_languages

[2] : https://medium.com/@hannah.scherz.23/layers-of-abstraction-i...

[3] : https://www.geeksforgeeks.org/c/c-programming-language-stand...

verdverm
I've built something like this, check out the code gen feature

https://hofstadter.io | https://github.com/hofstadter-io/hof

It's built around CUE + text/template (template authoring is the more painful part)

sargstuff
Ah, deterministic abstraction layer vs. workflow framework vs. ide.

So much for always use lambda expressions in macros and never have to worry about mutex issues.

> What's missing for a true deterministic ....

agreed upon common reference monoid / starting point

> What is stopping us from such language, visualization or construction method?

Gleam / Ada Spark going main stream.

verdverm
I use CUE as the deterministic abstraction layer and generate Go/TS from that, but any language can be generated because it is piped through a text/template rendering engine.

Deterministic workflows are more challenging because they are more complex in nature, as soon as you start interacting with the world outside of a pure language itself.

[deleted]
(comment deleted)
sargstuff
Way more than typical HN reply.

Business view of lims/dal:

DAL (diagnostic assembly line system - compliance) passes things up to LIMS (information management system - accountability/tracking through process life cycle) & ERP (like SAP). Industry/company policies / regulations set what is considered a deterministic resolution for a LIMS/ERP process item aka successful process life cycle completion and/or what needs to be done for a non-deterministic / incomplete life cycle process. Information from or not received from one or more DAL's or other sources may/may not contribue to a non-deterministic outcome/resolution.

Contrived example: "Oh man, music data strucures are a rabbit hole." : https://news.ycombinator.com/item?id=50200065

Project didn't have a deterministic way to figure out if individual songs being added already esisited in 'database'. Song(s) packaged differently so 'same' audio song need multiple methods to figure out if already in database. Not all computation methods / automated methods for finding songs were 'available'. aka no code to determinsticily go through all various ways to find duplicates.

Vs program acoustid provides a unique identifying 'fingerprint' (DAL level item) passed to LIMS -> beets/musicbrains. LIMS then uses unique identifying 'fingerprint' as a way to associate other addition DAL level data (artist, record lable, what else released with). Undiscussed, what if 2 recored lables released same song? LIMS might contain information on which format to keep/convert to if two song fingerprints are the same). Missing information on to ignore file format or convert to a specific file format would lead to a non-deterministic result of only difference between 'identical' song fingerprints was song file format. Different formats (file & recording) do generate different quality recordings. LIMS level usually is level sort/resolve conflicting data from DAL's.