I've been working on my own web app DSL, with most of the typing done by Claude Code, eg,
GET /hello/:world
|> jq: `{ world: .params.world }`
|> handlebars: `<p>hello, {{world}}</p>`
describe "hello, world"
it "calls the route"
when calling GET /hello/world
then status is 200
and output equals `<p>hello, world</p>`
It is absolutely amazing that a solo developer (with a demanding job, kids, etc) with just some spare hours here and there can write all of this with the help of these tools.
FWIW if someone wants a tool like this with better support, JetBrains has defined a .http file format that contains a DSL for making HTTP requests and running JS on the results.
That is impressive, but it also looks like a babelfish language. The |> seems to have been inspired by Elixir? But this is like a mish-mash of javascript-like entities; and then Rust is also used? It also seems rather verbose. I mean it's great that it did not require a lot of effort, but why would people favour this over less verbose DSL?
Yes, exactly! It's more akin to a bash pipeline, but instead of plain text flowing through sed/grep/awk/perl it uses json flowing through jq/lua/handlebars.
> The |> seems to have been inspired by Elixir
For me, F#!
> and then Rust is also used
Rust is what the runtime is written in.
> It also seems rather verbose.
IMO, it's rather terse, especially because it is more of a configuration of a web application runtime.
> why would people favour this
I dunno why anyone would use this but it's just plain fun to write your own blog in your own DSL!
The BDD-style testing framework being part of the language itself does allow for some pretty interesting features for a language server, eg, the LSP knows if a route that is trying to be tested has been defined. So who knows, maybe someone finds parts of it inspiring.
This is an infix operator commonly used to define the Thrush combinator, which transcends Elixir (or any other programming language). It is effectively:
I like the pipe approach. I build a large web app with a custom framework that was built around a pipeline years ago, and it was an interesting way to decompose things.
The more the words,
the less the meaning,
and how does that profit anyone?
Ecclesiastes 6:11
---
“We, and I personally, believe very strongly that more information is better, even if it’s wrong. Let’s start from the premise that more information, more empowerment, is fundamentally the correct answer.”
Eric Schmidt
If you want the patent holders to lose, NPEs or otherwise, then you want to fight through litigation and not the incredibly high bar set by the IPR. IPRs are expensive, time consuming and difficult. I've mainly seen them used strategically to encourage the court to grant a stay. Continuing litigation by focusing on invalidity contentions in response to infringement contentions is a better path forward.
A successful IPR will most likely need multiple forms of prior art. Each prior art must cover every independent and dependent claim of the patent in question, either through anticipation or combined obviousness.
Typical infringement contentions will not cover every claim and are therefore easier to defend.
LLMs are both analytical and synthetical. Provide the context and "all bachelors are not married". Remove the context and you are now contingent on "is it raining outside".
The biggest problem I've had with Kurzweil and the exponential growth curve is that the elbow depends entirely on how you plot and scale the axis. With a certain vantage point we have arguably been on an exponential curve since the advent of Homo Sapiens.
GET /hello/:world
|> jq: `{ world: .params.world }`
|> handlebars: `<p>hello, {{world}}</p>`
describe "hello, world"
it "calls the route"
when calling GET /hello/world
then status is 200
and output equals `<p>hello, world</p>`
Get your potential code reviewers involved before you even start coding. Keep them abreast of the implementation. When it comes time for a review they should be acquainted with your work.
This. Absolutely this. The PR should be the final step in the process. Never the first. Ambushing people with PRs and then demanding their attention is a massive time and mood sink. It is ineffective and counter-productive. You may as well just commit to main, and honestly, in so many situations I think that's perfectly rational thing to do, so much about PR culture is theatre.
This seems like a bit of an over exaggeration. A pull request isn’t just a chunk of code thrown at people. it’s an entire process with a Title , description, pipeline checks that all come together to say I want this in another branch.
As the PR author it should be your job to:
* Self Review the PR
* Ensure you adhere/fulfill to all the expectations and requirements a PR should have before it’s pulled out of draft
* That all pipeline test pass
* That for a given request X there is test that validate X, Not X , and edge cases of X and are ran in the pipeline.
* Has a clear description of what you’re changing/adding/removing, why, how, and the rollout plan , roll back plan , & the risk level.
The peer review process should make the reviewer engage in a rubber duck process to review their code , loop the team in for changes that can change their mental model of how a system they own works, and to catch things that we might not catch ourselves.
I feel like this is a good use of standups rather than just status updates. "I have started working on X" should ideally be accompanied by "I am planning on doing this using Y and Z" if there is any chance that it could be contentious. There should ideally be no contentions, but the moment any questions come up, they should be tabled for a post-standup huddle amongst the relevant stakeholders.
If you don't do standups, just do the same thing ad-hoc on the team chat channel.
Larger tasks and discussions are probably the purview of RFCs.
This might be why I'm finding a lot of these comments so confusing. Because what you're saying here is how I've always operated.
If the first time your reviewer sees what decisions you've made is when the review happens, then of course it will be overwhelming if the merge request is large.
If you keep your reviewer in the loop, and have bounced implementation ideas off of them, then the review basically just becomes a sanity check.
LLMs are pretty good at greenfield projects and especially if they are tasked with writing something with a lot of examples in the training data. This approach can be used to solve the problem of supply-chain attacks with the downside being that the code might not be as well written and feature complete as a third-party package.
Not for the parser, only for the demo server! And I guess the dev dependencies as well, but with a much smaller surface area. But yeah, I don't think a TypeScript compiler is within the scope of an LLM.
https://williamcotton.com/articles/introducing-web-pipe
And the DSL itself (written in Rust):
https://github.com/williamcotton/webpipe
And an LSP for the language:
https://github.com/williamcotton/webpipe-lsp
And of course my blog is built on top of Web Pipe:
https://github.com/williamcotton/williamcotton.com/blob/mast...
It is absolutely amazing that a solo developer (with a demanding job, kids, etc) with just some spare hours here and there can write all of this with the help of these tools.