>> ... underestimating the money they will come from ads in the future.
I would like AI to focus on helping consumers discover the right products for their stated needs as opposed to just being shown (personalized) ads. As of now, I frequently have a hard time finding the things I need via Amazon search, Google, as well as ChatGPT.
Good luck with that. Every supermarket I've been in has those stupid baskets or racks of stuff blocking the aisle and their data must show that it gets people to buy a little more of that stuff even though it makes me quite resolved to never buy the shit they're forcing me to look at in order to go get the five things I really need.
The tech industry has such inefficiencies nearly everywhere. There's no good explanation why an AI model that knows so much could be smaller than a typical OS installation.
I could once optimize a solution to produce over 500x improvement. I cannot write about how this came, but it was much easier than initially expected.
>> Our research this year also found that AI can act as a "mirror and a multiplier.” In cohesive organizations, AI boosts efficiency. In fragmented ones, it highlights weaknesses.
This is interesting -- It's helping in some cases and possibly worsening in some others. Does anyone have the details? (I haven't looked into the report as yet.) Thanks.
No OP, but I've also used Angular, React, Vue, Solid and Svelte in real world projects and my default choice is Vue, because it's on par with Solid and Svelte (and with Vue Vapor those three are basically the same) but with the larger ecosystem (vuerouter, vueuse, nuxt, nuxt-ui, primevue, nuxt-content, ...). I must also say that React was by far the most unpleasant and unproductive to use.
I keep reading unpleasant without any arguments. React is simple by nature, what made it unpleasant and unproductive?
Granted I mostly do work on Shopify apps, so most of the heavy work has been done for me, I just put components together. This works fine, and I'd rather do this in React than e.g. Angular due to the small scale of the apps. Then again web components would've also been fine.
Perhaps "simple by nature" is not at the top of everyone's mind.
Simple is great until you build something complex, or need to create a large reactive UI that is not a simple CRUD fetcher. Things like non-linear video editors, 3d editors, games, things with a large component tree that takes work to plan, build, and non-trivial to re-arrange thereafter.
Your "simple by nature" framework with one-way binding and render-the-whole-tree-when-something-changes now means you spend more time coding (fighting) React than you do your application logic. You could have focused on improving algorithms, but nah you're stuck architecting hooks, context providers, state management, and adding libraries that cement you deep into the React hole.
I think React developers all secretly want to use Solid but they're stuck using React at work, and just chant React is the best React is the best React is the best
Yeah, it's one of my bugbears that a framework like React is built to solve a niche problem (running an enormously big and complex app like Facebook for an audience where timing is critical), and then gets doled out for everyone, even though most web apps have much lower requirements.
Not ultra experienced with react, but I have shot myself in the foot just because the way react is made compared to other frameworks:
- infinite loop due to re-rendering on the render function (it happens every single time i come back to react)
- using useEffect when not required
- nested object updates (dunno if this is still an issue)
- class vs whatever the name is (className?)
Overall as another comment said I feel more fighting against react pitfalls than focusing on my application's logic. That really takes a toll in productivity as part of your brain loses a small portion of 'RAM'/cognitive load as you need to make an active effort to not shoot yourself in the foot. I guess most people get used to it, but for me it just never clicks knowing there are similarly performant frameworks with way more friendly APIs.
> React is simple by nature, what made it unpleasant and unproductive?
It isn't "simply by nature" at all. I have lost so much time battling through the minutiae of the different use...() hooks, trying to figure out either why something never updates, or updates too often, or updates but the state is stale etc etc. I never run into issues like this at all with Vue. Things update simply and predictably for me.
I've stopped being interested in frontend frameworks after Vue/React but I agree. I find JSX with its mix of JS and HTML rather weird. I prefer Vue's abstractions and the readability of its template syntax. It's also rather easy to add it without a compilation step for some interactivity or app-like behaviour on a web page. More complex applications using a bundler work as well as our company is developing and maintaining a 100k LOC webapp too. In the end I'd prefer it if browser would provide a native API for two-way binding, components or templating and maybe state management as well.
I have by far the most experience with Vue, but I'm a bit ambivalent about Vue3, and often still write in a Vue2 style.
Svelte looked pretty nice, but before I had a chance to really proficient, that codebase got re-written in Solid. Solid seemed to have the benefits of React-compatibility without so much brain-hurt.
Is tbat saying that all software should be free? And extending beyond software, that all books, art, movies, etc., should be free to copy? Likewise, would it be fine for anyone to use any other company's logo?
Is this saying that it is an either-or situation? Ideal would be a device that can be written fast when needed, but can also hold. Is there some more fundamental thing at a pixel level that links agility with retention?
E Ink uses microscopic ink bubbles that gets attracted to positive and negative voltages. The ink stays around when attraction stops, holding image. But the ink also require much stronger force than regular LCDs to move around.
LCDs use articulation of liquid crystal chemicals that change shape thus polarization upon application of voltages. They tend to slowly deform back to "the other" state when voltages are removed, and also tend to chemically break down if not moved back to the neutral state. LCDs are driven in pseudo-alternating current for this reason, and never held at either extremes for long time, for this reason.
So you can drive E Ink at 75Hz or whatever, it'll just take more power than it takes LCD to do so, and the last pixel states will persist. Or you can leave LCDs at extremes and disconnect the power, but it will lead to degradation if intentionally used that way.
What you can't do is 1) "watt per frame" figures of LCD, with 2) persistence, and 3) long life. (1, 3) is LCD, (2, 3) is E Ink, (1, 2) is LCD abused as if it's E Ink at expense of rapid degradation, and (1, 2, 3) is the holy grail.
Are LCD screens driven on a pixel by pixel basis, or is the entire screen driven on each refresh? Because the article says they're only causing changed pixels to refresh.
If so, you're probably still right when it comes to watching a video or something, but e-ink could be more efficient for drawing, writing, or reading.
IIUC, display controllers normally iterate rows and columns like a double for loop. The outer loop increments the row counter, inner one increments the column, and the voltage meets at the current pixel at pixels[i * j]. Most LCD controllers don't take pixel(i, j) or pixel[i * j] as the input, but expects a synchronize() signal to reset both counters followed by transfers of either row[width] in rows[height] or pixels[width * height].
The bare panel, for both LCD and EPD, would consist of a pair of glasses vapor coated with transparent indium tin oxide, chemically etched as bunch of horizontal lines on the first one and vertical in the other one, with corresponding choice of fluids suspended inbetween. It would be possible to wire a custom fabricated controller onto those row and column electrodes to drive individual pixels. I guess that is what is being done here.
I had worked on mirasol technology. I believe the colors on newer prototypes were much better than any e-reader tech till date. The issues were related to manufacturing most importantly.
Yes - I think that's the one the OP recommended. Great read. Gives a superb historical overview and the reader can follow the twists-and-turns of discovery. You get to 'know' the scientists as they battled the Quantum. Sets the scene before delving into other books that teach the actual Math etc.
I would like AI to focus on helping consumers discover the right products for their stated needs as opposed to just being shown (personalized) ads. As of now, I frequently have a hard time finding the things I need via Amazon search, Google, as well as ChatGPT.
reply