adamscybot
Joined 8 years ago
Karma
79
Submissions
37
Member since
Jan 4
Recent submissions
Comment · 10 months ago
Comment · 2 years ago
One language that comes to mind is ReasonML. It doesn't have runtime checking. It's structural and compile time, but the guarantees are supposedly cast iron. https://reasonml-old.github.io/guide/language/type#design-de...
type thing =
| String(string)
| Bool(bool);
let arr: list(thing) = [];
let add = (item: thing, dst: list(thing)): list(thing) => {
switch (item) {
| String(s) => dst @ [String(s)]
| Bool(b) => dst @ [Bool(b)]
};
};
let newList = add(String("asd"), arr);
Comment · 2 years ago
The "should we use node for the core business logic for my use case" thing is absolutely valid and depends.
But you'd be surprised about the "react for the front end of the CLI" part. I used this thing a whole six years ago in a complex interactive CLI and it came off great to use, maintainable and ergonomic. React is just one framework that proscribes to the "UI as declaritive/composable trees" pattern. And that UI doesn't have to be web based. That pattern works for all UI's I've come across.
Its the pattern that is a good reason to do this. And not react/js landscape. That part is probably a bonus for many though.
Comment · 2 years ago
Odd to see this come up. I used it about 6 years ago to produce a CLI for devs. It worked very well and React concepts map cleanly to pretty much any "UI" target as said targets can also be well represented by declarative & composable trees.
Probably, other Ui frameworks could also map, seeing as the declarative/composable tree pattern is ubiquitous now. So it's important to note it's that pattern which enables this, and not a specific framework.
But React is one of the ones that is also more removed from the web target than others.
Comment · 2 years ago
If you are used to structural typed systems though this actually "feels" expected. Don't get me wrong, I know where you are coming from. But the realisation comes from nominal systems, which are different beasts. As long as it actually evaluates to the expectations in the head of the developers using it, then that's okay.
However, regularly it's not the case -- especially with people moving from nominal systems.
TS can't really be practically nominal when it has to be constrained by its compile target. So I guess it ultimately boils down to an anomaly/criticism born from the legacy of how web standards came about.
Comment · 3 years ago
Interesting internal comms along these lines from 2013: https://www.techemails.com/p/imessage-for-android
Comment · 3 years ago
Right, huge +1 for Chakra. Chakra is basically tailwind but built on react primitives. It feels lot cleaner, and solves most of the issues mentioned.
Comment · 4 years ago
Its back
Comment · 4 years ago
In my experience its often the case the status site does not reflect reality -- until someone intervenes.
Comment · 4 years ago
I know about CSP and iFrames, but I think they aren't ergonomic enough to be used as mechanisms to restrict deps right?
Iframes need a full web context whilst CSP cant target individual code blocks. For example, I might want my code to be able to do alerts, but I dont want dependency x to be able to.
EDIT: Ah I think thats what you meant by your "code in a sandboxed iframe thing". Fair.
Comment · 4 years ago
TBH I think its not because JS somehow fundamentally attracts a different group of people, its probably more like:
- It being web based means you can target this kind of software for maximum "impact"
- NPM dep trees are massive and you generally have thousands of tiny libs. The chance of something like this happening and being noticed goes up therefore.
- NPM ecosystem is a bit more wild west which again leads to increased chance of something like this being able to occur in the first place.
Comment · 4 years ago
The web needs APIs that enables certain blocks of codes to run under specific permission constraints. Such constraints might include ability to read/write to DOM; window.alert; redirecting (well I guess CSP covers that one) etc. At least let us mitigate it.
Comment · 4 years ago
"Depends". The benefits of leaning on open source pays off the majority of the time. Are you exposed to more risk? Yes. Does that mean you shouldnt take that risk? Not really. Otherwise you'd struggle to move quickly and be competitive.
Of course certain things change this balance. Hopefully nuclear power plants dont have NPM in their toolchain. And I believe financial orgs already have quite heavy auditing of dependencies.
Comment · 4 years ago
Amazing! I always wanted Everything + deeper OS integration and this fits the bill.
Comment · 5 years ago
Perhaps give it another try, but with TypeScript. Im a front end dev and yes, I feel the JS pain. I look back at how I used to do things and think "wtf". TS completely changed this and brought it back to sanity.
"All blog posts mentioning feature Y published after September...[more examples]...The three most recent case studies in the finance category...[etc]"
Fairly simple queries. If you're willing to build an MCP server (as they did for their solution), you could just as well build one that reads structured front matter.
"You can't. You'd need to parse frontmatter, understand your date format, resolve the category references, handle the sorting, limit the results. At which point you've built a query engine."
Well that's a scoped problem. Looks like it already exists (e.g., https://markdowndb.com/) and doesn't require moving away from Markdown files in GIT if you want.
Or use something like content collection in astro (https://docs.astro.build/en/guides/content-collections/). Hell, looks like that lets you have the MD files somewhere else instead of git if you please.
The AI-generated points aren't as compelling as the prompter thinks. A new common problem.
Yes, you don't need flatfile-committed raw text for AI tools to work properly, in part because of things like MCP servers. Yes, semantically linked content with proper metadata enables additional use cases.
The next point to make would be "if you use our thing, you don't need to think about this", but instead goes into a highly debatable rant about markdown in git not being able to fulfil those additional use cases on a practical level.
This distracts from the what I imagine is the real intent: "git and markdown files don't come automagically with a snazzy collaborative UI. And yes you can still use AI, and use it well out of the box. If someone tells you you need markdown in git to do x,y,z with AI they are wrong."
Personally, I can get over the "AI writing style", but only if the content still nails the salient point...