dwenzek

I have been convinced by the sales pitch https://evmar.github.io/jjtut/pitch/ I will give a try to jj!

Exactly! A very nice explanation of what is and what is not a proof by contradiction is given by R. Harper in "Proofs by contradiction, versus contradiction proofs" [1]

- [1] "https://existentialtype.wordpress.com/2017/03/04/a-proof-by-...

It is always a pleasure to read Daniel Jackson [1].

In this paper, Daniel revisits the ideas developed in his book, "The essence of software" [2]. placing them in their historical context and opening a future for more modular software implementations.

He presents a convincing argumentation on how and why an object-oriented approach does not really contribute to reducing coupling. And his proposal is truly appealing: building an application as a set of external synchronization rules governing the interactions between modules (so called concepts). Each module comes with its own view on the entities of the application domain and provides the actions featuring the concept. Only the synchronization rules of the application relate the entities and actions of these modules.

That said, I'm left wanting more and I will need to take the time to put these ideas in code.

- [1] https://arxiv.org/pdf/2606.27258

- [2] https://bookshop.org/p/books/the-essence-of-software-why-con...

Tomas Petricek introducing the online version of his course "Write your own tiny programming system(s)" at Charles University.

A really appealing menu on interactive programming systems.

A proper doc definitely has to provide the details. However starting with an example or two is a nice way to a give the users a quick overview. Even better when this example is interactive as for redis where you even have an example use case. See https://redis.io/docs/latest/commands/incr/

A nice model solving a quite recurring problem. However this sounds a bit as over-engineering here, as two traits have exactly the same type signature.

I really enjoyed reading this well-written paper that introduces the Rel query language implemented at RelationalAI [1].

One main goal of Rel is to give users the ability to grow the language using libraries [2], say for linear algebra or graph processing. And I'm really impressed by the result. With ability to defines (possibly recursive) relations over relation variables and arbitrary-length tuples, Rel is a nice successor of Datalog.

I also like the oppiniated approach which is to enforce strong data modeling constraints on all relations (6th normal form and identifier uniqueness across entity types). This removes the need for nulls and beyond helps to remove complicated corner cases.

[1] https://relational.ai/ [2] https://docs.relational.ai/getting-started/walkthrough/rel-l...

Great to hear Alistair speaking about hexagonal architecture!

Since long, I love Alistair's books which are extraordinary insightful. As an example, [1] has drastically changed my way of writing specs and even thinking about user-software interactions.

Now, it's good to discover that Alistair is also a great speaker highlighting the key points that will help to understand his point.

[1] https://www.amazon.com/Writing-Effective-Cases-Alistair-Cock...

Just got a quick look, and found a gem: https://github.com/maaslalani/slides

Easy to use, neat and powerful!

Actually, this document is direct to the point with the broad questions agile teams should address to repeatedly deliver the software their users are expecting.

There is also the counterpoint: Compiling without continuations (2017) [1]

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

Beside the rational, what's really great is the list of such blogs: https://lists.eatonphil.com/blogs.html

I'm just a bit surprised that this post says nothing about Heaviside who rewrote Maxwell's equations in the form commonly used today.

According to wikipedia [1], Heaviside significantly shaped the way Maxwell's equations are understood and applied in the decades following Maxwell's death.

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

Thanks for these links!

Austral rational documentation is indeed really interesting. My preference goes into another direction (notably toward expression-based languages), but it's refreshing to read well explained design decisions.

The section about linear types is also a gem to this regard. I would even consider this as a reference source to introduce the motivations and principles behind the Rust type system and borrow checker. Only the syntax would have to be made a bit more rusty.

[1] https://austral-lang.org/spec/spec.html#rationale-linear-typ...

I would not say this is incorrect as there is no definition of `a: condition`.

As being declarative is about expectations, one translation could be:

I expect that "either both a and the condition to be true, or b true and the condition false" once the computation done.

      a when: condition

      b when: not condition

This post assumes that there is consensus around a formal definition of being declarative. This is hardly the case as highlighted by Robert Harper, an academic recognized for his work in the field of programming formalization , in his essay "What, If Anything, Is A Declarative Language?" [1].

[1] https://existentialtype.wordpress.com/2013/07/18/what-if-any...

I only read the first section on monotone fixed points. A real pleasure. Nothing new, but the key ideas explained in simple yet precise terms and examples. It really makes me want to read more.

I just found this quite old paper and it came as a surprise to me to discover that the idea of append-only storage is not 20 years old but more than 40!

The older work I was aware of is on "The design and implementation of a log-structured file system" (1)

So this is with pleasure that I learned that these ideas was around in the 80:

- Deletion considered harmful

- A non-deletion strategy using timestamps

- The importance of accessing past data

- A non-deletion strategy can improve both integrity and reliability

(1) https://dl.acm.org/doi/10.1145/146941.146943

It's amazing to see such a mix of ideas and tools, old and new, academic or not, all arranged in a software thoroughly optimized for accuracy and performance!

Rethinking DB API, viewstamped replication, no dynamic memory allocation, storage fault model, io_uring, zig, deterministic testing ...

It's a real pleasure the hear Joran share his passion.

Really nice!

I like the design choices of Datalog for the query language and Relations for the data model. This contrasts with the typical choices made for graph databases where the word graph seems to make links a mandatory query and representation tool.

What a refreshing post!

So many good points are highlighted: embrace as many as possible ideas without apriori triage, look for ideas in many places, with diverse people, make unexpected connections, add but also subtract, put things into actions, ...

I recognize myself on many points, even I would not pretend to be perfect on these lines - being also tempted to take shortcuts. And this is why this post is refreshing. It encourages me to keep exploring ideas and putting them into motion.

I love this kind of functional design that demonstrates how cascading functions is powerful! The HTML DSL provided as an example is really elegant. It's so amazing to realize these HTML elements are glorified functions.

Thank you for the link! I love this kind of comprehensive blog posts that open a door to a new world. It's worth the time to read those.

And here is a gist that demonstrates how simple it is to implement such a type-safe printf function:

https://github.com/mukeshtiwari/Idris/blob/master/Printf.idr

So many new programming languages that there is a shortage of names ;-)

When I saw the title I thought it was another post for Vale, but no, it's Val!

* Yesterday post on Vale PL: https://news.ycombinator.com/item?id=31786487

OCaml and Haskell parse `a b c d e f` as `((((a b) c) d) e) f`.

I love this idea to check how quickly a candidate can learn: if blocked on some coding/refactoring question, show the candidate how to do it, erase everything and ask him to redo it alone.

One thing I find interesting and original is the idea of flow-based type inference.

Citing the "The Lobster Type System" page [1]:

    Type checking happens in order of function calls,
    i.e. it is much like evaluating the code,
    but with types instead of values.

    var a = nil  // a is a nilable of unknown type
    if ..:
       a = "foo" // a is a nilable string
    if a:        // guaranteed not be nil inside block
       a += "!"  // ok: a is of type string here

Interesting. However, since I'm not a gamer, I find more convincing the post given as a reference https://blog.asmartbear.com/slc.html.

This post is a pearl! I love writing and I think that I'm good at it. However, I still have to learn and this post gives a sound structure. The point I'm struggling the most is to help my teammates growing their writing skills and to make them love writing. I will definitely recommend them this post!