Most of the musings on enforcing invalid states with ADTs are impractical when working with real data that needs runtime validation when it enters the system.
Using a schema/spec/type library at runtime that is even more powerful than ADTs is a better investment - or to be less controversial - is an additional investment on top of types.
Yes, it means the compiler can't help you as much, but who has time waiting for a compiler anyways ;)
I find the "make illegal state unrepresentable via types" idea great for software that needs to fly a plane, but for enterprise software not so much. The cost/benefit is not justifiable.
Can someone who's adapted HTMX for a larger app report about front-end-server costs?
HTMX serves fully baked HTML that needs to be created on the back-end (or front-end-facing servers)
That is more processing than sending the raw data to the front-end and baking the HTML there.
It is also more bandwidth (unless the JSON is more verbose than the HTML generated).
Lastly, I can generate different HTML fragments on the front-end from the same client-side state with the data only being transported once.
How is that working out?
Not necessarily. Often it is less. Template engines can be very, very efficient and fast.
Returning JSON almost always requires data/object serialization on the server, this is often slower than direct data/object -> template rendering.
Further, it's not your server but keep in mind the client must de-serialize JSON and render some HTML every time.
Modifying layouts as a result of non-persistent state (light/dark mode, sorting, etc) can usually be handled relatively easily with styles and data- attributes and sprinkles of JS. HTMX works very well with Alpine.JS and similar libraries for more complex situations.
HTMX isn't for every scenario, but it works very very well in many scenarios.
AI - as a discipline - has been around forever (1956), essentially since the birth of Lisp - both with staggering successes as well as spectacular failures that ushered in 2(3?) so-called AI winters.
The author probably just means LLMs.
And that's really all you need to know about the quality of this article.
One could get the impression that the only really really important non-functional requirement for such a thing is to absolutely ensure that you can only call the "good" functions with the "good" payload.
If that is just your team, use whatever tech gets you there quick.
However, if you need to provide some guarantees to a second or third party with your API, embrace standards like JSON, even better, use content negotiation.
This is the first wave of a new generation of Apps which has the potential to replace/enhance the majority of e-commerce websites.
I wouldn't underestimate it - it's the hammer can break up the information silos we've built up around websites/apps.
Why prompt Gertrude(tm) on Ramazon for a specific thing you need, if you can ask ChatGPT to find you said thing along with UIs to purchase it across all e-commerce platforms that agree to play in this market?
because the secret is that the web runs on advertising/targeted recommendations. Brezos(tm) wants you to actively browse Ramazon so he can harvest your data, search patterns etc. Amazon and most sites like that are very not crawl friendly for this reason. Why would Brezos let Saltman get all the juicy preference data?
when PayPal tells you that they already know you and don't require you to log in: that's fingerprint.com behind the scenes.
There are pros/cons.
It should be obvious by now that using any free service of scale is being paid for by your interactions which are made more valuable through fingerprinting.
Trying to circumvent that just makes it more expensive for the rest of us.
>when PayPal tells you that they already know you and don't require you to log in: that's fingerprint.com behind the scenes.
Why use a third party service when cookies can do exactly that? They load their .js from the same domain they set up a cookie and there's no limitation to read that cookie, correct?
The Clojure (or any Lisp) journey is very different, not because of the language per se, but because of the developer experience.
In Clojure, there's no appreciable compilation time.
During my work week I barely, if ever, restart the application I'm working on: I'm working inside of it via a REPL connection.
It's an entirely different ball game and if you just compare language features you are missing out on an incredible interactive coding experience.
Does it scroll? Because I like to scroll around when thinking about my program. I always imagine Lips REPL ppl saying they keep the entire program in their head but that can't be right. That's doing things the hard way.
You have files and editors for your files, eg emacs or vim or vscode.
Your editor is also directly connected to your running application and can compile individual functions or pieces of code to update the application without a full edit/compile/run/test loop. It happens way faster and more interactively while you code. You can directly inspect the running program and its data within that same framework and with the exact same tools and functions you use to code.
To answer another way, you don’t code your application in a REPL, like by line , but with all the tools you’d expect (editor or ide, git, etc) PLUS that live connection to your software.
The nice thing about REPLs is that you can try random snippets code. And as the sibling comments put it, you rarely switch to the prompt interface. Instead you `eval` a bit of code and it got sent to the running state of your program as if you've typed it as the prompt. It's more like brainstorming a program using a mood board.
You kinda have to keep track of the state, but the latter can be easily inspected so there's no need to keep it your head.
You tell your editor to evaluate any arbitrary part of the source file you currently have open, and it does so in the context of your running application without stopping it.
Then you see the result in another pane of your editor.
It's pretty revelatory. You're molding your program while it's running.
Why would anyone trust the output of an LLM, if it is barely better than guessing and much much worse than humans?
GPT-5 shows more impressive numbers, but for that particular task, the precision should be 100% - always. No matter how large the data set is or in which format.
Why are we doing this?
Using a schema/spec/type library at runtime that is even more powerful than ADTs is a better investment - or to be less controversial - is an additional investment on top of types.
Yes, it means the compiler can't help you as much, but who has time waiting for a compiler anyways ;)
I find the "make illegal state unrepresentable via types" idea great for software that needs to fly a plane, but for enterprise software not so much. The cost/benefit is not justifiable.
reply