AI can be quite useful in real-time computation for magnetic confinement. But sure, that's beyond GPT-3's current capability.
880 karma · joined May 1, 2021
How about Quake on Amazon Echo + Alexa? Build it like a Text Adventure but use NLP + Computer Vision to describe the scene and you shoot and move by describing what you want. Great for people with poor vision or has a nostalgia for the 80s.
On the implementation side, I think the article implies that you might need to model the edits by Operation, rather than State? Otherwise, the cost of the undo scales O(N) of the content size, which is not viable.
It works well for Git, which models content by State, using Structural Sharing. But Git has built-in delta compression so the memory footprint is roughly O(1) per operation. I don't think implementing this on the web for a <textarea>, or [contenteditable="true"] is a "minimum" effort.
Challenges I can think of:
1. DOM api exposes state, not operations. You need manual diffing
2. When applying the operations, you need to manually restore cursor positions
3. CJK language IME might inject unwanted intermediate states that must be ignored
Just imagine how in a lawsuit like this, OpenAI can use GPT-3 to generate eloquent court speech with statistical confidence that it can defeat human lawyers? It just comes down to TPU power.
1. Is desktop computing still relevant?
2. Is server CPU market not making enough return?
3. I thought Intel needs talent to bootstrap their US-based fabs.
4. Does this mark the beginning of an end for PC?
2. Framework vs. Library -- Framework calls your code; Library is called by your code. There is clear inversion of control. The article touched on this, but I think it's a very important distinction to call out.
3. Framework makes me think inheritance. Library makes me think composition.
4. Framework is like CPUs. A more powerful CPU is a more powerful CPU, no doubt; but you need more power to bring out the performance. If your company don't have the resource to deal with the maintenance, Framework becomes a liability rather than asset. But if you can sustain it, it should still be a net positive.
5. In addition to the mixing of domain and non-domain concerns, poor Framework bring incomplete abstraction that expands the surface area for reasoning/debugging/maintaining. A good framework should provide the perfect abstraction that frees the developer from having to descend the stacks. I consider programming languages as good "frameworks". So are the layered networking architecture.
6. Watch out for self-fulfilling prophecies. e.g. in the web frontend framework space, a framework might claim it helps solve problem X, but it might also be very cause problem X. Accessibility, Routing, State Management... a lot of these can be solved by using the platform. Before you reach out for a framework, be sure to assess platform capabilities and single purpose libraries first.
7. Reliance on framework can be caused by lack of knowledge. If you are a manager, give your team the time, money, and endorsement they need to learn things, attend conferences, and provide ample budget for training and technical book purchase. They might pay more dividends than a framework does.
Ref: https://blog.documentfoundation.org/blog/2021/11/18/german-s...
Yes, it takes patience and chutzpah, but I can also imagine how satisfying it is to build something from scratch and see all the pieces coming together into a working OS. And if you put your heart (and time) to it, you can build anything from scratch. A lesson the newer generation of developers still haven't fully grasped.
Congrats, good luck, and carry on!
And as a corollary, it could be the Anticipation of difficulty in tackling a daunting task that makes you avoid it, rather than the actual difficulty in tackling.
So, the best way to getting into the flow state and getting things done (pun intended) is to force yourself to just do it.
Semantic Web was supposed to be the Web 3.0. It's so dead now that even its name is stolen by the blockchain. RIP.