bitwarrior

Micropayments is something that I think the internet as a whole needs. However, I don't think the mental model people usually have isn't quite "micro" and frictionless enough.

Imagine a world where your web browser essentially contains and controls your wallet. You pre-pay into that wallet, say, $20. I imagine we'll probably also refer to that as "credits" so internationalization isn't so tough. So let's pretend we have 2000 credits. Now, let's start browsing the internet.

You start by conducting a web search. Perhaps there is a mechanism in HTML and the browser that basically say, "Clicking this will cost 1c". We'd probably develop a shorthand, some icon and beside it, it says the price in credits. Imagine a button like [(1c) Search].

Immediately, what is the benefit? The search engine works for you. It's like Kagi in that regard, but you didn't need to set up an account and give them your credit card information. YOU are the customer. There are no ads, they need to compete to make the search results the best, otherwise you're going somewhere else. You're no longer the product.

You see a news article in your search result. Fantastic. You visit the news website - there isn't an ad in sight. Pure news. The article starts with a title, a few lines, perhaps the first paragraph, and to read more, you click that [2c Read the Article] button. You click it, and boom, you see the entire article. No subscriptions, no popups, no ads. You are the customer. The news site wants you to be happy, not advertisers. You.

The news article discusses a new open source project that is really taking off. Cool! You click the link. Looks pretty neat! You download it, toy with it, and find that it's actually pretty useful! You go back to their repo site, and there's a little tip option. Easy peasy. You tip them 100 credits. No signing up for an account at some other site, no entering your credit card, just done and done.

I like the idea of micropayments because it makes the user the customer again. The internet has become incredibly hostile to users since we are, by and large, the product rather than the customer. We need to flip the incentive model. Does it suck to pay for things on the internet? A little. But I'd rather that and get a great experience (and also allow news organizations to have a working business model, etc) than what we have now.

This is somewhat the oldest advice in the book: "Dress for the job you want, not the job you have."

I think the salient point here is that you, as a user, have zero power to reduce hallucinations. This is a problem baked into the math, the algorithm. And, it is not a problem that can be solved because the algorithm requires fuzziness to guess what a next word will be.

Are you sure this even works? My understanding is that hallucinations are a result of physics and the algorithms at play. The LLM always needs to guess what the next word will be. There is never a point where there is a word that is 100% likely to occur next.

The LLM doesn't know what "reliable" sources are, or "real knowledge". Everything it has is user text, there is nothing it knows that isn't user text. It doesn't know what "verified" knowledge is. It doesn't know what "fake data" is, it simply has its model.

Personally I think you're just as likely to fall victim to this. Perhaps moreso because now you're walking around thinking you have a solution to hallucinations.

> The PS3 failed developers because it was an excessively heterogenous computer

Which links to the Wiki:

> These systems gain performance or energy efficiency not just by adding the same type of processors, but by adding dissimilar coprocessors

Modern CPUs have many similar cores, not dissimilar cores.

I think the issue here is with the word "tried" and what that communicates. I think "compared" would be far more appropriate.

You didn't read the article.

Rounded corners? This is the hill you are choosing to die on? How are these trivialities impacting your day to day use of Windows?

I'd say I'm quite the opposite. I'd much rather hear Microsoft working on core technical improvements rather than adjusting the goddamn roundedness of their UI.

Yes

It entirely depends on what the function is receiving.

In your example, assuming we're looking at a React codebase (since this seems to square with React's style of events, etc), the resulting data being set into the updateDate function would be an event.

This, unfortunately, doesn't make any sense for a function by the name of updateDate to receive. I would expect to receive at least a new date to update with in the parameters, or ideally in a functional world, both the state to update and the new date we want applied to it. Anyone thinking they could simply reuse the updateDate function somewhere else is going to be woefully disappointed they largely cannot, since it would have been constructed around receiving an Event object.

In that case, I find the "handle" nomenclature to be very useful, as it appears to be largely shorthand for functions design to handle an _event_ (and we tend to see this pattern being used in various React libraries and documentation). React does have a few of these shorthands it tends to use (such as useEffect largely being short for useSideEffect).

Ultimately, I recommend using both functions. One, a handleClickUpdateDate function (notably not a hyper-generic handleClick function which conveys nothing) that receives the event and pulls out the necessary information out of that event to determine what the date is that the user has selected. It then will call the updateDate function with only that date, which creates a nice, reusable updateDate function if we need it anywhere else.

This roughly squares with the idea of having functions that handle the data transport layer (such as receiving data via HTTP or gRPC, etc) whose responsibility it is to receive those events, pull out the necessary information out of the package, route the request to the correct controller, and ultimately return the result in a shape that satisfies the original transport mechanism. In this case, our handle* function is responsible for receiving the original transport of data, then routes the request through to the appropriate controller which is entirely unaware of the means of data transport.

It also means we have a nice, easily testable unit of updateDate to verify our state modification is working to our liking without needing to assemble an entire Event object.

Anyhow, that's how I think of these things ;p

I'd say we're likely comparing apples to oranges here. It's a common complaint on HN that frontend development is a mess and evolves too quickly, that it isn't "what it used to be". Static pages, small downloads, very little coding overall. What we miss is those kind of sites still exist, but they're not the sites we're complaining about.

Back in the late 90's and early 00's, most websites were largely "brochure" websites. Companies were getting online because they heard about this whole internet thing and they knew they just needed to "get on the internet". You largely saw companies uploading whatever brochure they had basically into a digital one online. Those websites were insanely straightforward. Render a page, static content, the end. Maybe it's a little more dynamic than that, perhaps you're running a basic LAMP stack listing, say, real estate. Query the database, render the page, we're done here. Very little interactivity.

Those websites still exist, but they're likely not the ones we're complaining about. Site's like boeing.com are those traditional brochure sites which deliver very little interactivity. Relatively quick and nimble, the hero image is larger than all the JS they load (and, honestly, they could probably remove most of their JS now - they're using jQuery, modernizer, underscore, stickyMenu, require.js and a bunch of probably unnecessary jquery plugins we can eschew today, but we're here to complain about today, not praise it amirite?).

What we're actually complaining about are usually the interactive sites. Your Twitters, Facebooks, even sites like Reddit that dynamically load content as you scroll, click posts and download more content, comment - all manner of interactivity. Typescript? React? Functional components? Hooks now? Learn Redux? Unlearn Redux? CSS flexbox? CSS grids? My website now has a build process? I used to just edit the PHP file and upload it via FTP. What the hell?

These are not simple "brochure" websites, so yeah, they're more complex. They're applications. And being that they're applications, we shouldn't be comparing them to brochure websites, since they're delivering a completely different experience and have a completely different goal. We should be comparing them to desktop applications and the desktop application development environment, and therefore, comparing their stacks against the likes of C# and WPF, Swift and Cocoa, C++ and Qt or C and GTK.

And compared to those tools, how does the modern web development tool chain stand up? I have no idea, I don't write desktop applications! But what I do know is companies like Slack and Discord have elected to use electron rather than create their products in whatever desktop application framework. VS Code is electron-based and being a Microsoft product they had all the reason in the world not to do that - and it's dominating it is space today. Offerings like Figma, which by all rights one would imagine should have been desktop software elected to be an online tool and has completely shut out the competition.

So if you're going to complain about online applications, don't compare it against an old programming paradigm that would never apply to these products. Compare them against the modern desktop application development experience and let's start the conversation there.

Was just going to post something like this, but didn't know if posting a link to their status page which claims "everything is fine" would be helpful.

I'm unable to resolve their homepage or, more importantly, push or pull repositories at the moment.