jsunderland323

That’s interesting to hear and I think I arrived at a similar homiconic IR state for my tool too. I think there are some problems you might run into if you’re doing any sort of relational cascading but this sounds sane and like a good approach. Thank you for sharing!

> 2) I’ve thought about this problem a lot. Like to a very unhealthy degree… To the extent that I’ve been working on a visual dvcs full time for over a year, that interops visual programming tools with textual codebases that use textual version control. When you say you solved this, is it because you expect users of your tool to be able to understand and reason about however you’re storing your state to disk? Xcode does this with the infamous project.pbxproj and it still causes immense merge conflict pain to this very day (and it’s one file), on the other end of the spectrum, large game studios have basically forgone dvcs to use shader editors at scale. If your language tool is simple enough to reason about textually, doesn’t that limit the utility of your language? I don’t mean in the sense that you make it deliberately hard to reason about your ast equivalent but presumably it wouldn’t take much complexity before a bad merge conflict could break relations and make malformed states. How do you handle that without writing a hand rolled merge driver for each vcs you support?

In my humble opinion this is kind of the breaking point of almost all higher order programming tools. I think it’s also the reason most “no-code” or “design-to-code” tools feel like a sham to engineers. I’d love to hear how you overcame merge conflicts for your tool, I’m skeptical, but I’m all ears.

I hear what you’re saying. I think in the abstract it seems like an unnecessary helper function. But in a historical context it makes sense.

About a year before hooks was introduced it was discovered by multiple teams that inline anonymous JSX functions could create big performance issues. This was particularly felt in react native development. The solution back then was to do the whole .bind(this) to your callback methods in your react classes.

Because of this (my guess) is the react team wanted to make it extremely obvious how you could use closure state as opposed to private method callbacks when they went intro hooks, without teams having to worry about taking a performance penalty with inline callbacks. It was not obvious to me (and I’m sure many others) when hooks came out that you could memoize functions before rendering.

Again, I get the redundancy point and maybe at this point it could be deprecated but I think you have to think about where the community was before hooks.

My mother is American. Her parents met during ww2 in Brazil, where my grandfather was stationed. So maybe it was a lie that permeated those involved with the war at the time. I accused her of spreading fake news this morning after reading this and she couldn’t recall where she had heard it.

I just asked my wife, who is from Hong Kong, if she had heard this as a child and she said she had not. Her grandparents were really young during the war and Brits and Cantonese were pretty segregated until after ww2, so it might make sense that this didn’t reach her family.

Damn. My mom told me carrots would improve my eyesight when I was little and I've lived with this my whole life. This article ruined my sense of accomplishment after eating carrots but I loved it.

I think I really needed to add more context to this comment. This is on me, again sorry. I was really saying this in regards to the part of the comment regarding dvcs and general accessibility.

What I was trying to say is in regards to the artist/lawyers (let’s generalize this to anyone who does not know how to code or could not meaningfully interpret a plain text or binary diff of a certain document type), you can have a user friendly dvcs that has structured conflicts but you need that system to understand more than plain text/the file system. It needs to know the schema of the thing it is merging to be meaningfully diffable or perform three way merges.

What I mean by structured conflicts is conflicts that do not break the editor’s interpretation of the document state. When you’re writing source code in vim/whatever IDE you use, the editor state is entirely decoupled from the runtime of your merge conflicts (git and vim do not need to know the semantics of the programming language you are writing source code in to work), so a syntax error in a merge conflict doesn’t prevent you from fixing the syntax error or resolving the conflict. The trickiness to structured version control is that the merge conflicts must be resolvable within whatever is serving as a medium of editing the document. So in structured editors, you can have conflicts in a document but they have to still be semantically interpretable while in a conflicted state.

This is not possible in pijul/git or any generic file based vcs without an editor that can be provided a schema to interpret the document type it is merging. Sure you can write your own diff and merge drivers but this becomes cumbersome fast and is extremely uninteroperable.

However, this is entirely possible, I’ve been working on a system that does this very thing for a year. Happy to show you if you want to see.

I think the bigger question is Why on earth would you would want a dvcs like this to exist when you have plenty of centralized version control systems to cater to people who aren’t technical?

Philosophically there are quite a few people who care about not having their work gated by subscription plans/centralized players. I’m relatively indifferent to that side of things but I do like having local access to all my documents.

The bigger thing to me is that it allows non-technical people to do work that can be used to generate semantically correct code. The document types themselves can also interoperate, which makes things like centralizing static asset generation very useful if you share assets across multiple client codebases. This also means you can let a copy translator, do things like create rich text translations without needing them to edit things like a stings.xml or a .po file and worry about them botching syntax. Designers can put all icons into a document and generate themes and palette code for engineers to consume that work across any client type. Sure you can do all those things in isolation with centralized software providers but without a commit sha to point to, these tools become kind of unviable to engineers since they aren’t idempotent (or offline first). Moreover many code generation tasks end up becoming very product and organization specific, so the system needs to provide a generalized way for anyone to create their own diffable document type.

I think there’s a host of other benefits gained but my motivations for the tool I made came from problems that arose at my first company when dealing with translations, feature flags and building a good dark mode. I also think merging is the best way to handle collaborative editing and there is little reason aside from the syntax errors that arise in plain text conflicts for the general concept of dvcs to only be accessible to software engineers.

Sorry for ranting. Hope that clarifies what I meant.

Sorry, I was replying in the context of GP’s original comment with regards to general accessibility. Agreed git has a lot of other problems.

Yes. That’s the whole problem. If you don’t crack that it’s useless

I’d be happy to demo a work in progress if you want to see a structured dvcs. This is a surprisingly tricky problem. There’ve been quite a few attempts throughout the years at a structured/visual dcvs but it’s almost impossible to solve without also building a schema language, an offline browser, and a package manager/app registry. There’s murmurs in some of the offline first/CRDT communities that suggest other solutions but I haven’t seen anything structured and viable emerge. Anyway, let me know if you want to chat. I’ll put my email in my bio

I agree. I thought this was a substack competitor for the first minute.

This is lovely

Do you mean literally deleting your last commit? That would break a lot of the guarantees gained from the append only graph that git exploits for nearly everything it does. I think undo is too ambiguous in the context of vcs that it would be risky to introduce as a part of the cli api. What would you expect undo to do?

If you’re doing collaborative trunk based development then you’re only cherry-picking. So far Dave Farley is the only person I’ve ever heard advocate for this but it does have its place in the universe. Cherry picking is not destructive to history fwiw.

There’s absolutely nothing wrong with rebasing/squashing/amending/resetting heads on personal feature branches. In fact, it’s a pretty good practice if you make messy history and can make PRs less of an eyesore. I think the confusion comes up about when destructive history operations are appropriate because the git cli client does not have a concept of protected (shared) branches vs feature branches.

As long as you keep history destructive operations away from shared branches, you’re good.

Or better yet, find new language that makes sense. Anything not employing w3c standards probably shouldn’t be described as a successor to the web at all.

I think most of SV is pretty crypto disillusioned at this point.

It feels as though the only people into it in SV in 2023 are the people shilling it, which are not that profitable of a cohort after all.

I was mostly venting into the void (sorry). I admittedly don't know the first thing about antitrust.

But to your earlier point: > On the other hand, the case that Google is going to make (and which I think is going to be really hard for the government to overcome) is this: we (google) give our product away for free and so do our competitors. What’s more, the cost of switching search engines is literally zero: just type Bing instead of Google.

Don't you think the counter argument to this, is, "No it's not that easy to just go to bing when you buy out the default search on rivals' browsers and operating systems and have the browser and mobile os with the world's largest market shares"? I get that the attack here is directly on search but it would be surprising to me if this wasn't part of the case. It seems insane to bring this case if there isn't a component focused on the browser and OS conflict of interest in search.

I don’t think the problem is Google being the best at search. The problem is that you cannot possibly have your user or customer’s best interest at heart when you own the most dominant browser and smartphone os by market share AND when you’re a search engine and ad exchange. Owning those lower level parts of the stack (os and browser), which are network effects loaded, is the anti-competitive piece.

Google as a default to other browsers doesn’t bother me. It’s the being the ad broker, the exchange, the browser, the os and the search engine that are problematic. They have demonstrated over two decades that they cannot protect the interests of either their users or the ad buyers. Disabling cookies is essentially meaningless when you’re forced to sign into your browser or os. Absolutely no ad exchange can act in the interest of their users’ privacy when they have a browser or os that mandates you to sign in. And yes, even ad buyers get screwed by Google’s exchange (Google’s real customers). There are many fraudulent publishers that stack ads but get paid out for false impressions, Google still collects on fake impressions and has little interest in decreasing the fraud since they have a 30% take on the impressions.

The ideal outcome is that chrome is spun off, android is spun off, and the ad exchange is spun off. Google can keep its suite of productivity tools and search engine and run ad words. That’s a completely reasonable and still extremely valuable business that is highly defensible. I think their interests can align with their users and customers in that scenario. As it is right now, I don’t think you can have the business model they have and not have serious conflicts of interest with users and advertisers.

Just update it to say cognitive dissonance instead of cargo culting and you’re good =D

It’s not a bad article, you’re just talking about something that isn’t cargo culting

I second this. I think we’re confusing cognitive dissonance with cargo culting in this article.

Cargo culting is blindly copying something without understanding the mechanistic behavior of the thing being copied. Plenty of cargo culters end up convinced after following the recipe but the planes don’t show up.

Cognitive dissonance on the other hand is about not updating your beliefs when there’s overwhelming verifiable evidence to the contrary.

I think the two can go hand in hand. Hype cycles in tech suffer from both but I think they’re distinctly different things.

Sorry, I made my comment in jest. I guess it didn’t land well.

Yeah, I can see the resource planning overlaps. I’m glad it worked out for your friend!

I feel like taking a job where people take meth to drive for 3 days without sleep is probably the weirdest way to overcome JavaScript fatigue.

This is really well said. I’ve been trying to articulate this point for a long time. I think the boundary is between things that are temporal or bounded by real time and space vs things that are time independent and state based. Oracles always suffer from this problem even if the authoritative representation is another digital thing. For example the whole NFT url swapping thing. Similarly this comes up in version control a lot when your code depends on things that are unversioned, the commit state may be idempotent but the application is not.

Re: bank account fees. I think OC was just making the point that one institutions’ lack of security practices gets passed to the entire system as a way to offset fraud costs, we all universally eat this stupid cost.

An example of this is chargeback fraud on marketplaces. The way the fraud works is someone buys a bunch of credit card numbers off of the dark web due to some websites’ bad security practices and a data breach. The fraudster then ATOs a merchant account on some marketplace platform or makes a fake account, e.g. Doordash, Airbnb, Shopify, etc. The ATO is usually possible because some subset of the merchants of the platform use the same passwords on another website that has been compromised, again, some data set is sold on the deep web. The fraudster then either has to change the payout method of the marketplace merchant account, which they can usually do by ATOing an acquiring bank that they can access the funds in some way, again due to another external institution with tenuous security practices.

Finally the fraudster charges all the stolen credit cards and in most cases leaves the platform taking the liability. This results in the platform pushing up take rates against their merchant accounts, which almost always gets passed back to the consumers of the service (us) by increasing the prices of the service.

The problem with passwords is that we expose ourselves to everyone else’s negligence. You might handle passwords with all the best security practices to be known but you expose yourself and your users to every other system’s incompetence. It wasn’t until I saw this play out, that I understood passwords aren’t just a disservice to the negligent compromised user but really to the whole ecosystem of the internet that partakes in password authentication.

Yes, there is always a trade off in security and friction. This has always been true. But if we know passwords are faulty and essentially useless, why continue with such a bad practice? To reduce friction to a maximal extent? By that logic we might as well throw out the concept of security altogether. Why not just make it so a user only has to enter their email/username and nothing else? Let me know how that goes for you. I think webauthn is likely the sustainable, long term solution but we’ve got a ways to go before some of the inane thinking around password preservation dies out.

Sorry, I just saw this. I’ll email you now. Happy to share my experience and answer any questions you have.

-Jamie

WRT inheritance, composition solves the diamond problem. It’s really about decoupling interfaces for portability more than code reuse.

I think the big abstraction problem inheritance solves is overrides. I think there’s a lot of FP cargo culting that overlooks the benefits of the ability to override (when used wisely). But aside from that I’m not sure there’s any reason to think inheritance is any more or less polymorphic than composition for a language with sufficient reflection/introspection support. If you lack type introspection it’s a different story. Maybe I’m missing your point though.

Having dealt with the very problem and market you’re thinking of penetrating I would actually walk away right now. Go talk to 5 engineers from POS, delivery, or QR companies. Restaurant owners will tell you whatever you need to hear. This is an exception industry, where I highly recommend talking to industry veterans over restaurant owners. This problem is a siren song to optimistic entrepreneurs and bright eyed engineers that haven’t had their hearts ripped out by one of the most hostile industries to startups.

The whole restaurant industry tech stack is built on closed APIs and POS systems that sometimes have no API. Plenty of POS and delivery services will not even consider granting API access until you have a substantial number of restaurants on your platform. Or charge you 10k-50k for a license to their sdk.

That’s just starting with access.

The next obstacle your product is going to have to deal with is a complete lack of standardization across products and platforms. Omnivore tried to solve this but ended up with a joke of a product.

Menus look easy right? Here are some of the nuances to consider. Does the menu support options or price variations? Variations are things like large medium small. Modifier groups are things like temperature, sides, etc. some POS systems support nested mods, Doordash for example let’s you have up to 7 mods in their API. Consolidating this with a POS that has no support for nested mods, will not be trivial. What about combos? Toast, and Square deliberately chose not to support combos due to the complexity but anyone coming from a Micros systems will demand combos. Are you going to support chits? If so do you have experience with esoteric kitchen printers to test kitchen and receipt printing with? Oh yeah, everyone writes their own proprietary drivers for printing shit, so good luck there. What about when restaurants have entirely different schedules for their delivery menu vs in house menu. How do you plan on handling things like deliberately out of sync holiday menus. Then you have the whole thing of access control. Some items are meant to only be orders by managers and not appear on digital menus. Are you thinking of doing enterprise? Great, you’re going to need to deal with inventory management systems too. Not only, you have to convince those players to integrate into you. These are small examples. If you try to build a universal machine for menus, you are going to have to come up with a generalized menu format that spans nearly 40 years and tens of millions of lives of code of feature creep. Then you’re going to have to deal with convincing everyone to work with you in an industry that’s main form of competitive advantage is anti-interoperability. If you crack this problem, let me know, I wanna invest.

The last thing you’re going to have to contend with is the user. Unless you are going extreme SMB (no margins). Who you sell your tech to will not be who uses your tech. This introduces a myriad of problems. Restaurants are revolving doors. The cost to retrain a new manager and not have your system ripped out by someone who hasn’t used it every 6 months is not a joke. Oh also, get ready to lose your nights and weekends to tech support.

I think so many tech people have walked into the restaurant space with a simple view of the space only to get burned. Myself included. I wish someone on the tech side had sat me down before I started one of these particular projects. The source of truth in a restaurant is whatever is in stock and whatever the manager feels like. Tech wise, it’s mostly the POS and they are extremely verticalized for a reason. Good luck! Hope this helps.

I think part of the point of it is to assure people working on niche problems that embody some of the qualities of what pg is describing as great work. It’s easy to look at the shiny zeitgeist and feel a lot of self doubt if you’re off working on something few outside the niche seem to understand. I’m not sure if this an advice piece as much as an encouragement piece to those readers going through those trenches.

Storybook?

Magic links are great because they essentially eliminate ATO attacks and allow startups to bypass SAML requirements by delegating to the mail provider. I’m 100% willing to forgo efficiency gains of passwords and managers as both a user and developer.

tldr of article; engineering is about trade offs. As humans we are susceptible to hype cycles and financial influences. Now let me tell you about a bunch of things I have personally decided are not worth considering the trade offs of under any circumstance.