You can spend a lot of time perfecting the test suite to meet your specific requirements and needs, but I think that would take quite a while, and at that point, why not just write the code yourself? I think the most viable approach of today's AI is still to let it code and steer it when it makes a decision you don't like, as it goes along.
As much as many are against it, couldn't this be yet another argument for social network wide digital identity verification? I think that this is an argument that holds: to avoid AI slop / bots → require government ID
Personally, I don’t see this move as a negative. It implies that a company believes in its product and potentially wants to improve it. Usually, you can tell when a product is not used by its creator(s), and it’s not a good experience.
I would argue there is a glaring problem with the memo: it is basically written from the perspective of someone who writes memos. Computers were fantastic replacements for many uses of typewriters back then, allowing people to do much more with greater ease. Yet they were not universal replacements for typewriters.
The article pointed out one glaring problem, one that was present with the Apple II (along with other microcomputers of the era): it could only display uppercase text. It got around that by displaying capital letters in inverse. A related problem was the limited display width. While a typed page is roughly 80 characters wide, the Apple II could only display 40 characters per line. Thankfully the Apple II was expandable. 80 column cards and cards that displayed lowercase text were created, but Apple didn't introduce such capabilities themselves until the Apple IIe. Even then you needed to buy their 80 column card (but at least that standardized things).
Another hitch was actually typing lowercase letters. You needed to do a shift-key modification for applications to register the shift-key being pressed when a letter was typed. Again, Apple didn't standardize this until the Apple IIe.
Of course, those weren't the only issues. Computerization may have been taking over the world, but so were reams of paper. While most of those additional reams of paper were being generated by computers, much of that paperwork existed before. Forms, in particular, almost necessitated the use of a typewriter. While I would hate to line up forms in a typewriter, such feats were nearly impossible with printers.
So I guess you're right in some circumstances: computers were not a good experience. That doesn't negate the times when they offered a far better experience. Whether you're writing memos or novels, the ability to go back and edit text outweighs the drawbacks (never mind all of the advancements that were just around the corner). But a blanket ban on typewriters was myopic.
The uppercase/lowercase limitations and 80/40 characters don't necessarily prevent replacing typewriters. They weren’t typing text in BASIC, they were using Apple Writer [0], which did support uppercase letters. This wasn't a WYSIWYG editor, so the text on screen does not have to exactly match the printed output.
While it's true that none of that prevents computers from replacing typewriters, it becomes more difficult to convince people that computers are better than typewriters.
Put another way, I grew up with those 8-bit machines. I preferred using those 8-bit machines for writing since it was easier to edit documents, which was important because I was young and learning to type (along with learning spelling, grammar, etc.). Using a typewriter wouldn't so much be an exercise in frustration as it would be one of mental anguish. On top of that, I wouldn't have the expectation of screen text mapping reasonably well to the printed page.
On the other hand, people who had experience with typewriters (or even 80-column terminals) would have that expectation. And they would be bumping into that mismatch whenever they were dealing with indenting or centering or lists or any number of other layout options. They would also be more accustomed to the writing/editing process with a typewriter, so they would be less inclined to view it as problematic. The flip side is that they would be unaccustomed to the writing/editing process on a computer, so they would be more inclined to view those quirks as problematic. On top of that, the process of using a word processor would be completely different from using a typewriter. Think of over-typing: (fake) bold, underlining, and so on. It is less labor intensive to do on a computer, but the average secretary would have trouble seeing that when they have to navigate the then cryptic user interfaces of software.
Proving that something is possible probably wasn't the issue here. Proving that something is better, which isn't hard to do even considering the primitive word processing software for the Apple II of that era, isn't the issue here. Dealing with the expectations of people is.
Strange, this is the first time hearing Treesitter is slow. From experience, Treesitter has been incredibly fast for me (when running its core functions). I’m not discrediting your observation, but it might be something else in the pipeline.
TS can be slow in some situations.
https://github.com/tree-sitter/tree-sitter-julia/raw/refs/he...
open this file with and without treesitter . And neovim will slow to a crawl with TS on. But the traditional regex highlighter can handle it fine. (a file such as the link posted above typically is never meant ot be opened since its machine generated , this is just to show you TS can be slow on large files)
TS is faster in other situations.
for example with TS highlighting enabled entering "(" in the buffer is definitly faster in a julia file. (you can test this by holding down "(" in a .jl file and see the difference between TS enabled and only regex highlighting).
That is true, however, one thing to keep in mind, is that these tools like Via / Vial, will always be limited compared to a fully fledged programming language like C with and its QMK framework.
Something that I only realized after the fact.
reply