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.
Taxes and AML/KYC kill this. People need to surveil their customers in order to comply with legal requirements. As soon as money is involved there's so much bureaucracy people just contract it out to intermediaries like Stripe and by then payments are anything but micro.
The real innovation of cryptocurrency is that it allows people to think outside the box of AML/KYC.
Stablecoins, which not decentralized at all (and thus defeat the entire purpose of cryptopcurrency) are allowed to break the rules by wearing the label of "cryptocurrency", with the implication being that cryptocurrencies are just going to break the rules anyways.
Yeah, BAT was supposed to be exactly this, you'd mine it by browsing and tolerating non targeted ads from your browser and you'd pay it to content creators in lieu of tolerating their targeted ads.
It was a great idea, but I get the feeling that it stalled somewhere along the way.
If I'm publishing something, I want maximum revenue.
If I can guarantee repeat customers then I can make the reader the sole focus, but if I still have to maximise based on capricious trends and search indexing, then I'll probably maximse the payment, the adds, and sell your data as well.
Subscription services are probably the only way, unless we see a consolidation of hosts with a consistent brand and quality, enough to trust a micro transaction will get something of the quality I expect.
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.
Telling the LLM not to hallucinate reminds me of, "why don't they build the whole plane out of the black box???"
Most people are just lazy and eager to take shortcuts, and this time it's blessed or even mandated by their employer. The world is about to get very stupid.
> 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.
Is it the case that all content used to train a model is strictly equal? Genuinely asking since I'd imagine a peer reviewed paper would be given precedence over a blog post on the same topic.
Regardless, somehow an LLM knows things for sure - that the daytime sky on earth is generally blue and glasses of wine are never filled to the brim.
This means that it is using hermeneutics of some sort to extract "the truth as it sees it" from the data it is fed.
It could be something as trivial as "if a majority of the content I see says that the daytime Earth sky is blue, then blue it is" but that's still hermeneutics.
This custom instruction only adds (or reinforces) existing hermeneutics it already uses.
> walking around thinking you have a solution to hallucinations
I don't. I know hallucinations are not truly solvable. I shared the actual custom instruction to see if others can try it and check if it helps reduce hallucinations.
In my case, this the first custom instruction I have ever used with my chatgpt account - after adding the custom instruction, I asked chatgpt to review an ongoing conversation to confirm that its responses so far conformed to the newly added custom instructions. It clarified two claims it had earlier made.
> 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.
There are specific rules in the custom instruction forbidding fabricating stuff. Will it be foolproof? I don't think it will. Can it help? Maybe. More testing needed. Is testing this custom instruction a waste of time because LLMs already use better hermeneutics? I'd love to know so I can look elsewhere to reduce hallucinations.
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.
Mobile CPUs embraced this hardcore; but the problem is that most of those cores don't have the programmer interfaces exposed. The most dissimilarity you get on mobile is big.LITTLE; you might occasionally get scheduled on a weaker core with better power consumption. But this is designed to be software-transparent. In contrast, the device vendor can stuff their chips full of really tiny cores designed to run exactly one program all the time.
For example, Find My's offline finding functionality runs off a coprocessor so tiny it can basically stay on forever. But nobody outside Apple gets to touch those cores. You can't ship an app that uses those cores to run a different (cross-platform) item-finding network; even on Android they're doing all the background stuff on the application processor.
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.
Honestly the Windows UI is kinda annoying, and it did effect my performance until I recently ditched it for linux w/ i3 as the WM... I want something straightforward and to the point. The windows UI peaked at XP, everything else has been inferior.
Microsoft keeps messing with the UI in obviously deleterious ways. If they didn't rewrite the entire interface in 11, no one would be complaining about 11's rounded corners. The very fact that they decided to add rounded corners has likely already distracted from kernel work.
Do you remember when Windows 10 was the last version of Windows? I wish we could go back.
> The very fact that they decided to add rounded corners has likely already distracted from kernel work.
The Windows team is so huge that I wouldn't be surprised if the people writing the shell and the people writing the kernel barely know eachother's names.
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.
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.
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.