No, it can operate on a data structure as well. There's string rewriting which does operate on text (but this can be stored in a structure amenable to applying rewrite rules versus brute force copying it or something silly). For term rewriting, there are plenty of efficient ways to store and operate on the information besides just textually.
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.
Yes, that's often the objective. If they're properly written they will terminate, but not all sets of rules may terminate. It's possible for rules to cause divergence or cycles.
A -> A B (1)
A -> B (2)
B -> A
(1) never terminates, always adding a new B on application but not removing the A. (2) doesn't grow, but never terminates since each term is replaced with the other.
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.
You raise a good point, but REST isn't quite declarative, and RPCs isn't quite what I'm proposing.
REST is great but I wouldn't exactly call it declarative, it relies on HTTP verbs, plus there are times when you simply can't express things with pure REST so usually you break the textbook pattern with something like POST /resource/doSomething.
As for RPCs, you have to predefine the operations you want to expose as part of your schema, which is even less flexible than what I'm proposing. Imagine for example that instead of passing a JSON Patch string you'll pass a real JS arrow function (with some limitations, e.g. no closure state). It allows for max flexibility, the user doesn't have to learn any APIs, plus the implementation becomes trivial. It's kind of like SQL without inventing a new language.
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.
The last commit using that approach was https://github.com/256lights/zb/tree/558c6f52b7ef915428c9af9... if you want to try it out. And actually, I haven't touched the Lua frontend much since I swapped out the backend: the .drv files it writes are the same.
The motivation behind replacing the backend was content-addressibility and Windows support, which have been slow to be adopted in Nix core.
I don't think nix is that awful, while there are some tasks that are more difficult or can be a little bit verbose (if you want to play a lot with the attribute sets / lists
or string manip) When using nix most of the time you'll end up just writing bash or using it as a templating language.
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.
I think I'm at the same conclusion. I basically want ocaml but with structural / compile time duck typing of all types (I know about objects but they don't seem widely used). And some sort of reflection mechanism to cover 80% of the cases where you'd reach for ppx / macros (i.e. database interface code gen of types).
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.
Thanks, this is a good example. Coming from a formerly Scala background, which is nearly as obsessed with type safety as the Haskell folks (but now doing mostly Java, Go, Clojure, Python), I get a real laugh thinking back to those sensibilities. Like, people would almost consider it an anti-pattern to look up an element of a list by index because it's not compiler-verified that the list is long enough.
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.
Increased spending is the simplistic solution. Government spending as percentage of GDP is 35%, compared to about 25% in the 50s/60s. Since then inflation-adjusted spending per student has increased by roughly 3X with no measurable increase in test scores. Baltimore spends 21k/yr per student, with abysmal results. College tuition prices have increased far more than inflation, in large part due to federal student loans. The USA spends more on healthcare as a percentage of GDP than any other country, with insane markups on routine procedures. The California High Speed Rail project has taken 15 years to do environmental reviews and lay a few miles of track in the middle of nowhere, all while costs have grown to more than 128B from its initial estimates of 10B.
Giving money to ineffective organizations is throwing good money after bad. I'd love to see competent government that can effectively use funds, but I'm not seeing a lot of evidence for it these days. There needs to be deep reform and anti-corruption efforts. Good luck doing that without the status quo powers pulling out all their dirty tricks.
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.)
