Yes, most people who have an incentive in pushing AI say that hallucinations aren't a problem, since humans aren't correct all the time.
But in reality hallucinations either make people using AI lose a lot of their time trying to stuck the LLMs from dead ends or render those tools unusable.
Just wanted to share that I've found part-time roles hard to get by. It seems companies mostly look for full-time employees.
This is unfortunate because it makes harder to keep working on personal projects on the side, because you either have to make them lucrative to let you work on them full-time, or you have to squeeze them during night-time, when you are tired from daily work.
You could support mobile platforms as well. IIRC, even if Android allows creating only one window per activity, this behavior can be easily mapped on the abstraction that you provide.
They solve the use-after-free issue by keeping pointed objects alive, not by helping you think better about object lifetimes in your code. That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references. Added to that, they also introduce random, unpredictable slowdowns in your application to run their algorithms.
I'm not yet sold on Rust, but exploring alternatives for achieving memory safety without needing to put on a GC is commendable.
I'm excited by these explorations of dynamic components in rich text. Notion has popularized the idea of documents with rich blocks, where the blocks can provide dynamic behavior to traditional documents. And now we're seeing types of inline elements that also provide more structure to rich text. Those location routes seem something that I'd use myself.
There's already been some talk of using consumer cloud providers. One shortcoming however is that to work well you have to duplicate the users' data for each client app, so you'll consume x times more storage space of the user. This is fine for apps with little data, but is impractical for other apps.
It seems that Notion is a kind of product that tries to solve issues from many areas, so it has everything that almost solves a meaningful problem for the user, but not quite. So the burden is on the user to go that extra mile, who will have to search for templates, memorize how non-standard tech works just to setup and maintain a system that only the maintainer knows how it works.
Some people use Notion for research and academic writing, which is the same use case for my software (https://getcahier.com). By specializing on this specific use case, I've been able to: offer a standard data model that's widely used in the field (bibtex), innovate in the PDF reader in the direction that my users need (by adding scrollbar markers for the relative position of highlights), and provide clear instructions to users on how to use the software. In principle, learning to use the software is learning how to perform an activity better - in this case, formal or informal research. When working with a software that's too general the user will always have to ask himself an additional question: "now, how do I make it do what I need?".
As the mathematician Hardy used to say, a beautiful theorem is one that is not too specific but also that is not too general - it has to strike a balance between the two.
I've heard about SwiftUI just some months ago, and was initially excited about the demonstration in WWDC, so I started to pay more attention to it. Now I've been reading comments on how it doesn't handle well more complex UIs, but haven't really read anything in depth. Can you recommend any resources on that?
Nice work! It wouldn't be much work to support Android with this library and keep the single source file, since the addition of native_app_glue. It'd require just an AndroidManifest.xml, and the API communication can be done by calling the functions provided by the NDK or in the worst case by calling JNI.
That's actually a great idea for a second follow up article. I've worked a lot with rich text and custom text objects, but would also like to explore itemization and the lower level layers.
I saw them, they are a very small step in what I believe is the right direction, since you can use a custom textDocument. Anyway what I think would be useful is to jailbreak the QML API. Make the QML C++ API publicly available. Let us derive from the controls, manipulate and customize them with C++, as the Qt team devs themselves do.
> I've had more problems with Widgets, especially when doing a lot of animations (even just scrolling big text views) on a 4K display on MacOS, but maybe I'm thinking graphics and not input lag.
There's two things to consider when comparing rendering performance: throughput and latency. Throughput, or how much FPS the engine can sustain, is much better in QML since it's leveraging the GPU, but latency it's very platform-dependent. Mac is actually the one where QML does best in terms of latency (and by that I believe it approaches the latency of Qt Widgets), since it's synchronizing with the VBlank signal provided by CVDisplayLink. On Windows and Android the situation is worse.
Well, I don't want to bash on QML, since I really appreciate the efforts that the team puts in it. But I do think its current state is not the best when compared to Qt Widgets, and lament that there's a split between the two toolkits inside the framework. The problems I had with QML are:
1) The controls that Qt Quick 2 provides are oriented toward touch interfaces, and some are not even feature-complete. For example, QML's Flickable on desktop can be scrolled by clicking and moving the mouse, a behavior that is clearly an artifact from the touch implementation. QML's TextEdit doesn't support much that QTextEdit does, which was particularly important for implementing an app that offers advanced text editing. Ironically, even though Qt Quick is touch-centric, Qt has lots of bugs on mobile platforms, and has a history of presenting regressions on those platforms.
2) Communication between QML and C++ is finicky. You have to use macros and Qt-specific constructs (Q_PROPERTY, signals, slots) to bridge both worlds. Qt Widgets doesn't need bridging in the first place, since it's C++ all the way down.
3) Control customization is a pain. In Qt Widgets, we can create a class that inherits from a standard widget, and then we can customize it however we want while inhering the behavior from the base control. In QML, you have to resort to javascript for that, which has different tooling and ecosystem than C++. Besides, C++ programmers find javascript dynamic typing more error-prone than static typing.
4) The latency of interfaces built with QML is higher than the ones built with Widgets. QML's rendering engine is lagging behind in the input latency mitigation front when compared to browsers, although they've been making efforts in this area.
I don't think those problems are unsolvable, and historically Qt has evolved a lot, so I hope they eventually tackle these issues seriously.
I've been researching CRDTs for a reference manager that I'm building (https://getcahier.com), and thought that some hybrid of automatic and user-operated conflict resolution would be ideal, as you described. But current efforts are mostly directed to automatic resolution.
Do you use last-write-wins using the received order of operations on the server or using a logical clock?
I believe that for Notion the collaboration use case is more important than async editing, so a CRDT makes more sense, but for text editing apps that favor asynchronous collaboration maybe explicit conflict resolution is more reasonable.
CRDTs are powerful, but it's unfortunate that they leave behind a trail of historical operations (or elements), both in their ops- or state-based variants. Even with compression, it's still a downside that makes me concerned about adopting them.
Even so, the discussion surrounding them made me excited by the possibility of implementing conflict-free (or fine-grained conflict resolution) algorithms over file-based storage providers (Dropbox, Syncthing, etc.).
Nice job! I've been wanting to write a PDF parser for learning purposes, but have been put off by the quantity of files that open source PDF parsers have on their repos and the different tech that they need (image formats, compression formats, etc.). I'll probably settle for a reasonable ratio between PDFs supported/learning extracted from the project, so it's useful knowing that PDFs with JS are not very widely used.
Also, I'm the developer of a reference management software, and have naturally been thinking about what it'd take to save in the PDF file metadata fields that are generally useful for advanced readers and academics: original publication dates, ISBNs, DOIs, edition, publisher, etc., instead of just author and title.