One thing I haven't seen addressed in the post or comments (sorry if it's there and I just missed it) is for apps and websites that sell non-digital goods to customers.
For returning customers, a customer with an app installed is simply going to have a lot less friction to open the installed app and place an order than a customer who has to open their browser, log in again, and then place the order.
That alone is worth the investment for many companies in making an app, even if a minority of customers actually choose to install the app and keep it installed.
If the website is a PWA, it can be installed to the home screen and look and behave just like a native app. You just tap the icon on the home screen. It will remember your login.
And the upside is that you only have to develop one website (instead of a website and 2 separate native apps for iOS and Android).
Here's my take: "Learning is not supposed to be fun."
"Not supposed to be fun" has a clear meaning. "It doesn't have to be actively not fun" doesn't have a meaning. No one ever says "actively not fun". It's a cop out to pretend like he's not presenting a false dichotomy, and I can see right through it.
I use Github Copilot with PlantUML. I use PlantUML comments to describe what I want the diagram components to show and then the syntax is written for me. I can then edit it pretty easily and iteratively.
Hello, thank you for sharing your thoughts on this topic. I'm currently writing a blog post where the thesis is that the root disagreement between "AI doomers" and others is actually primarily a disagreement about materialism, and I've been looking for evidence of this disagreement in the wild. Thanks for sharing your opinion.
If you look at the backgrounds of the list of people who have signed the "AI Doomer" manifesto (the one urging what I'd call an overly extreme level of caution), such at Geoffrey Hinton, Eliezer Yudkowsky, Elon Musk etc... you will find that they're all rational materialists.
I don't think the correlation is accidental.
So you're on to something, here. And I've felt the exact same way as you, here. I'd love to see your blog post when it's done.
Really? You sound serious. I would recommend rethinking such a claim. There are simpler and more plausible explanations for why people view existential risk differently.
What are those? Because the risk is far higher if you believe that "will" is fundamentally materialist in nature. Those of us who do not (for whatever reason), do not evaluate this risk remotely as highly.
It is difficult to prove an irrational thing with rationality. How do we know that you and I see the same color orange (this is the concept of https://en.wikipedia.org/wiki/Qualia)? Measuring the wavelength entering our eyes is insufficient.
This is going to end up being an infinitely long HN discussion because it's 1) unsolvable without more data 2) infinitely interesting to any intellectual /shrug
> If you need to introduce a new pattern, consider refactoring the entire codebase to use this new pattern, rather than creating one-off inconsistencies.
Putting aside the mis-application of "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four), this suggestion to "refactor the entire codebase" is impractical and calcifying.
Consistency increases legibility, but only to a certain point. If the problems that your software is trying to solve drift (as they always do with successful software), the solutions that your software employs must also shift accordingly. You can do this gradually, experimenting with possible new solutions and implementations and patterns, as you get a feel for the new problems you are solving, or you can insist on "consistency" and then find yourself having to perform a Big Rewrite under unrealistic pressure.
> Putting aside the mis-application of "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four)
This is not in any way a mis-application of the word "pattern". There is no exhaustive list of all design patterns. A design pattern is any pattern that is used throughout a codebase in order to leverage an existing concept rather than invent a new one each time. The pattern need not exist outside the codebase.
> Consistency increases legibility, but only to a certain point.
It's the opposite: inconsistency decreases legibility, and there is no limit. More inconsistency is always worse, but it may be traded off in small amounts for other benefits.
Take your example of experimenting with new solutions: in this case you are introducing inconsistency in exchange for learning whether the new solution is an improvement. However, once you have learned that, the inconsistency is simply debt. A decision should be made to either apply the solution everywhere, or roll back to the original solution. This is precisely the point the author is making by saying "consider refactoring the entire codebase to use this new pattern".
This refactoring or removal doesn't need to happen overnight, but it needs to happen before too many more experiments are committed to. Instead what often happens is that this debt is simply never paid, and the codebase fills with a history of failed experiments, and the entire thing becomes an unworkable mess.
For consistency, the same design problems should have the same design solutions a.k.a. pattern. If you don't value consistency, feel free to take a different approach every time. That will confuse your users. I used to work with a guy, the simple problem of reading a CSV was done using a library, problem sorted. Out of sheer excitement he then rewrote it was with combinator parsers, then as some astronaut architect functional monstrosity, so complex no one else could comprehend it.
This is how not to do it – for same problem, use same solution. I admit that's an extreme case but it's also a real one and illustrates the issue well.
(also patterns are not specific to OO, nor is OO incompatible with a functional style)
Are you replying to the right person? I'm saying that "pattern" need not be restricted to the narrow sense used in the famous "Gang of Four" book[0], not that patterns are inherently bad!
It is not just about legibility. Developers are trying to repeat patterns they see around. If you do not refactor previous places, they will reproduce the outdated pattern. Plus, it makes code reviews frustrating.
the pythagorean theorem is not named after its discoverer, unfortunately, as historians of mathematics have dated its earliest known usage to well before pythagoras
That's very fair. Indeed, my personal favorite version is Indian, and predates Pythagoras.
I was also trying to name something that most people would at least find familiar... maybe there's a different one, similarly universal, that would be more accurate?
i was going to ask if turtlebot was too small for you, but thought i should check the price first so uh, yeah, i'm guessing you're thinking the 250 price point instead of the turtlebot's 1000+
