odipar

I was once into 68k so I may be rusty, but shouldn't it be move.w d1,(a0)+ (increment the target address after each step)?

The most impressive demo ever: https://www.youtube.com/watch?v=mgXRXDfQ0xw in only 4kb! Image seeing this demo back in the 80's: it would be close to sorcery!

Identity doesn't imply 'value' equality, that's the whole point of mutability! Conversely, two objects can have the same 'value' while having different identities. Values and objects are different beasts.

My take is that identity doesn't imply mutability, if you version objects. It could well be that your are looking at an old version of an object, using its unique identity combined with its version (number).

Objects refer to other objects using their (immutable) identity. In turn, resolving identities to objects requires (version) scope which can be in the past or present.

CodeQL is another datalog with the domain of code analysis as its use case. Too bad you cannot create a custom fact database with CodeQL. Otherwise, the implementation of CodeQL is pretty advanced and efficient.

Okasaki got me interested in confluently persistent data-structures, way back in the 2000s.

They seem magical! To be able to combine data from the past with current data, efficiently!

They are almost always trees, with the exception of skip-lists, with all operations O(log(n)), .

After creating my own programming language Enchilada that is based on immutable data structures, I started considering what I deemed "next level":

Uniquely represented confluently persistent data structures

Combined with a Merkle tree encoding of such uniquely represented data structures (they are almost always trees), you can efficiently and incrementally authenticate them. Think 'block chain' on steroids, with incremental cryptographic hashes. Or torrents, if you are into that kind of thing.

As always it is the journey that matters (writing), not the outcome (the essay).

For example, students could record their writing of an essay with a keylogger or something.

Additionally - with the use of some advanced zero-knowledge algos or crypto timestamp provenance - it should be possible to prove that they have written the essay, without revealing their recording.

SeqHash

This data structure is an immutable, uniquely represented Sequence ADS (Authenticated Data Structure) with various interesting use cases.

It is based on a novel hashing scheme that was first introduced with SeqHash.

See http://www.bu.edu/hic/files/2015/01/versum-ccs14.pdf) by Jelle van den Hooff , a brilliant young researcher back then.

SeqHashes are uniquely represented Merkle Trees that also represents a sequence. Concatenation of two SeqHashes is O(log(n)). In turn, the cryptographic signing of SeqHashes is O(1) as each tree node carries a cryptographic hash.

Of course, for each node to carry a hash incurs a hefty overhead but that can be alleviated by (lazily) grouping nodes into buckets (turning it in some kind of BTree).

SeqHashes also don't support splitting in O(log(n)) like for example AVL trees.

I've created an Btree version of SeqHash that also allows splitting SeqHashes in O(log(n)) called SplitHash.

See: https://github.com/odipar/spread/blob/master/src/main/scala/...

big brain really like post. lesson learn is deep!

"(best grug brain able to herd multiple big brain in right direction and produce many complexity demon trap crystals, large shiney rock pile!)"

I also personally think CUE hits a sweet spot. The union (pun intended) between types and values (both sets) is really a game changer!

CUE is indeed not trivial to implement, especially its intricate semantics are tricky. I work an a CUE alternative, called ReSeT to really understand the semantics better.

See: https://old.reddit.com/r/ProgrammingLanguages/comments/uukxv...

Visual is all nice and all, but I really fancy the 'computational' model of spreadsheets which is very easy to learn and apply IMO.

My latest find is the CUE language, which I believe is the first 'typed' version of a spreadsheet (in disguise). CUE is like spreadsheets, but on steroids!

Here is an example: https://cuelang.org/play/?id=r4VXwbEG185#cue@export@yaml

Another interesting fixed-point (16 bit) division 'algorithm' is with log and exp tables, with a well chosen base :).

consider a and b being 16 bit fixed-points (at the 10 bit position) then:

c = a/b

is:

al = log(a) (log table lookup)

bl = log(b) (log table lookup)

c = exp(al - bl) (exp table lookup)

...so basically 3 table lookups and 1 subtraction.

this method that has been used to do fast 3d->2d projections on a Atari ST (68000 processor): https://www.atari-forum.com/viewtopic.php?f=1&t=5696

No Stinking Loops! http://www.nsl.com

Is it just me or are Java Modules hard to create and use?

I found it pretty confusing to get them to 'work', especially with libraries that are not module enabled.

Also, there is not support for Java Modules for Scala nor Kotlin. May be we need more tooling and IDE support.

Use case: JavaFX

Yep, CTEs are a huge boon to structure your SQL - use them where you can.

Yes I concur: CTEs is closer to the spirit of relational algebra: every step/expression should yield a table/relation.

As data munging is about combining/correlating/sorting/grouping data, why not have a sound (bag) algebra to do that? Such algebra would give us equational reasoning, proofs, etc.

And consequently: students would be learning an algebra which is easier to learn IMO.

My first encounter with 'SQL' was a course on relational algebra that was taught at my university.

It started out with defining relations as a mathematical construct, and continued with various operators on such relations. Then they continued explaining the various normal forms up the fifth normal form. I was completely out of my depth, but at least it was good and solid theory that could be learned.

What really messed with my head is they then introduced SQL as a 'practical' implementation of relational algebra. I'm still having nightmares where I try to understand nested HAVING statements that where asked at the exams.

Hey relations don't contain duplicates! But that's OK. We should call (modern) SQL 'BAG ALGEBRA'.

hey, I like your work on Paranoid Scientist. I've never come across hyper-properties: is this something you invented?

Regarding hyper-properties: I assume they only work on immutable data values, otherwise it would be hard to manage historical objects so that they can be part of any of the predicates.

I'm working on a similar project that you may find interesting: https://odipar.github.io/manikin/. I may want to include hyper-properties in future releases.

edit: found this on hyperproperties: https://lamport.azurewebsites.net/pubs/hyper2.pdf

I think immutability (or immutable state) adds one big advantage over mutable state: you have access to previous state(s) and the current state.

Immutability is very convenient for checking post-conditions that compare previous states and the current state for certain properties that should hold (temporal properties for example).

In turn, post-conditions guard your states to be sane.

self-plug: you may want to checkout Manikin: it is very similar to Goblins, but with a clear transactional model.

https://odipar.github.io/manikin

Definition of a professional:

"engaged in a specified activity as one's main paid occupation rather than as a pastime".

I wouldn't call fixing azure pipelines without any professional debugging tools a pastime activity.

I really like Eric's work, especially "From Boolean Algebra to Unified Algebra".

His algebraic approach towards building software is really refreshing as it starts with the absolute basics and then slowly builds to a whole framework. Recommended!

Yed has been serving me for almost 15 years.

I think yed's layout algo's are the best in the industry. Also, the extensibility is great (even in the free versions).

I want more formal architecture diagrams: how would they look like?

I also want to know whether my architecture diagram is any good?

Is my diagram too detailed, too abstract? Are there any objective measures, or is it all heuristics?

That said, 'loose' architecture diagrams can help you convey an approach, idea or direction. A strict formalism might kill the take-away message.

Managing state in (standard) FP doesn't compose that well.

Lenses look like a solution to transition 'deep' immutable state, but I find them cumbersome: YMMV.

Object Orientation has excellent composability with regards to state and with minimum fuss.

The step I took is to eradicate mutable OO state, and replace it with a pure OO substrate.

I always was a Sinclair guy, even developed some cracking (tape copier) software back in `80s (youth crime, I know).

I also had friends who owned a C64. Someday, a friend let me listen to another 1 bit sound that was produced by ..... the C64 diskdrive!

I was really flabbergasted by that hack!

I've come full cycle:

0) Procedural

1) OO

2) FP

3) Really started to dislike mutability

4) Developed various FP frameworks

5) Back to pure (immutable!) OO and messages!

Thanks for the reply!

Unfortunately, persistent data structures tend to produce (short-lived) garbage which the JVM is very good at collecting!

So yes, Clojure benefits immensely from the JVM.

It is also an interesting research topic whether (optimised) reference counting would be a better approach.

Regarding objects, there is also a "middle ground" to consider:

Split big (immutable) arrays in smaller ones, connect them with some pointers in between, and you are still cache friendly.

Also, you can do a lot on the application level to reduce garbage, and most Java programmers don't care for that exactly because of JVM.

I like your response, and yes, it was a major oversimplification and I'm sorry for that.

Indeed, it is always about design choices and trade-offs. I can see why BLAS code is important and why Julia is an optimal choice for computation heavy problems.

I don't think you can allocate immutable data structures on the stack.

I've never seen a 10 million entry immutable set on the stack but I could be wrong.