alxmng

Hmm maybe I misunderstand. All the rules must be applied to fixpoint or elimination, for every input right? And the larger the program (rule set) the worse the performance since more rules must be evaluated at each “tick” of the program, unless you play tricks with ordering rules.

I think the issue is performance. A true term rewriting system has to essentially operate on text, right?

What I've noticed is if there's 1 product, 500 sellers will buy the product on Alibaba, create 500 different "brands", and when searching Amazon it appears there's thousands of products but it's actually a handful of the same product white labeled by many different sellers. The actual number of unique products in many categories is quite low but there's thousands of listings.

This is essentially the RPC vs REST debate. Do you want your API to be a schema of data types (REST), or a list of function signatures (RPC)?

There's plenty of available gardening space in unused yards. Ask your neighbors if you can garden their unused yard in exchange for them getting a cut of the produce or flowers.

Check out the paper "Dedalus: Datalog in Time and Space". It formalizes a Datalog to include time, specifically to handle async behavior. It explores exactly what you seem to be doing here.

Did you consider writing a nicer language that compiles to Nix? A "friendly" tool on the outside with Nix inside.

When I first started the project, URLs needed certain constraints enforced in my business logic. So I thought "Great, let me create a type for URLs". This is the type that parses URLs from user input and gets marshaled/unmarshalled to the DB.

Then I needed to ingest RSS feeds. So I found a library that handled that for me. Except that library uses another type for URLs. Uh oh. What should I do? I could change my URL type to be a wrapper type around both types, or write code to convert between the types. I chose to convert. Now I'm writing code to shuffle between the types where this RSS parsing module is used.

Then I needed to make HTTP requests. So I pulled in a library to handle HTTP requests. Of course, that library uses another type for URLs (from another library it depends on). Great. Now I have 3 types for a URL.

Then I needed to parse XML... and you know where this story is going.

So now my codebase has many different URL types.

The type-a-holics will say: "This is actually good! Each implementation of the URL type might have slightly different constraints, and the type system makes this all explicit. You should be grateful you spend half of your development time fiddling with types. The fact that `unpack . decodeUtf8` is littered around your codebase isn't code smell, it's the splendor of a type system that's saving you from yourself. You should learn to love the fact that you have to deal with String, Text, and ByteString and 4 URL types to fetch and parse an RSS feed. Otherwise your software would be full of bugs! Silly developer."

One day I finally woke up from this type nonsense. There's integers, rationals, strings, lists, and maps. The end.

This is my experience as well. Referential transparency and immutability have many advantages, with few disadvantages (if any). Type checking is great as a way to enforce constraints. However, nominal types create unnecessary incompatibility and endless type shuffling every time you want to make even simple changes. I maintain a web app written in Haskell and there’s 3 or 4 different types for URLs in the codebase, even though there’s no real difference between them. Nominal typing is terrible for code reuse via third-party modules. So many hours wasted wrapping types or shuffling between them.

A functional language with a simple set of structural types would be the sweet spot for me. Clojure is probably the closest to this.

What's productive? Measured in purely financial terms selling cigarettes, junk food, and fentanyl is productive. Figuring out how to get teenagers to scroll TikTok all day is productive.

... What people are suggesting is to take money from some productive enterprises and put it towards other productive enterprises such as education, medicine, public infrastructure, etc. Enterprises which have more benefits beyond simply increasing the bank account of entrepreneurs and fund managers.

One option is to outlaw asking for a tip at a place of business. No screen prompting for a tip, no slot on a receipt to accept a tip, etc. Nothing could be displayed conditional on purchase (such as a receipt, a PoS terminal, etc.)

Any details? What part is AI generated? Which model? What tools? What was the process?

I find it helpful to first assess uncertainty.

1 = I’ve done this before

2 = Someone else in the organization has done this before

3 = Someone outside the organization has done this before.

4 = Nobody has done this before

1 and 2 can be quickly estimated by referring to past work.

3 and 4 must be broken down into small tasks that are estimated.

And when breaking things down into tasks to estimate, keep in mind coding is only around 1/4 of the work to produce software. There’s tests, documentation, revisions, planning, and communication.