Multimodal LLMs already learn to generalize over text inside images. In my experience most multimodal LLMs are significantly better than traditional OCR, especially if there's any unusual formatting going on.
This thread is considering image input as an alternative to text input for text, not as an alternative to other types of OCR, so the accuracy bar is 100%.
I've had mixed results with LLMs for OCR.. sometimes excellent (zero errors on a photo of my credit card bill), but poor if the source wasn't a printed page - sometimes "reusing" the same image section for multiple extracted words!
FWIW, I highly doubt that LLMs have just learnt to scan pages from (page image, page text) training pairs - more likely text-heavy image input is triggering special OCR handling.
As usual with Alzheimer's studies, this is another "breakthrough" in mice. Unfortunately, every other Alzheimer's breakthrough in mice has failed to replicate in humans, because... Mice don't get Alzheimer's. We can create mice with dementia patterns that are surface-level similar to Alzheimer's (beta amyloid plaques!), and clear the plaques and even often reverse the dementia. Unfortunately this doesn't help much of anything, since those diseases we create in mice are not Alzheimer's and appear not to actually be similar causally to Alzheimer's. All of them have failed to replicate and we have many of them.
I generally wouldn't trust any Alzheimer's "breakthroughs" in mice models. The models are not accurate and have thus far had zero predictive power for actual Alzheimer's in humans.
The same is true for life extension in mice. We can massively extend the mouse life span but it doesn’t replicate in humans.
The reason there is pretty easy to grasp. Mice are a short lived more R-selected (lots of offspring, lower parental investment) species. They haven’t been heavily selected for longevity, which means there’s more low hanging fruit, more opportunities to tweak something and make a mouse live longer.
Humans meanwhile are among the longest lived large mammals and are extremely K-selected (few offspring, high parental investment). That means evolution has probably already tweaked all the easy life extension related knobs in humans. Going further will require going beyond the capacities of existing mammalian physiology, which is a lot harder. Probably possible, but requires a lot deeper of an understanding of what’s happening and more radical interventions.
It's not a silver bullet, but there are many studies (including the ones referenced in the article) that show that introducing peanuts in a consistent early childhood window reduces the likelihood of later developing a peanut allergy. I don't think this is "pure fantasy."
I've tried variations on low-color syntax highlighting (I've even tried no syntax highlighting!). While I agree most color schemes are too colorful, to the point where it's largely noise, I think trying to go super low on colors ends up hurting readability.
For example: keywords, specifically, are actually very useful to highlight. This post complains that misspelling "return" didn't make easily-scannable color changes (it changed the color from purple to red, which still looks like a special color)... But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually! In both cases with the proposed color scheme, "return" and "retunr" would have identical coloring: white.
Generally speaking I think a lot of the visual noise of syntax highlighting comes from having too many colors. For example, you don't need the "class" keyword to have a different color than the "const" keyword — and many syntax highlighting themes are guilty of doing exactly that. But it's useful to be able to immediately, visually see if you made a typo: if you expected to write a keyword, and it's colored like normal text, you know you messed up. Similarly, it's useful when reviewing code to quickly be able to tell whether there's a typo somewhere.
I have a pretty custom syntax highlighting theme for Neovim. I have a few categories that are highlighted differently:
- Keywords
- Function calls and method calls (highlighted identically)
- Property accesses (to highlight mistakes when you're simply accessing a property
instead of calling it — it's a different color than a method call)
- Non-string built-in primitive types like numbers, booleans, etc
- Strings
- Comments
- Types
Ultimately I think syntax highlighting is a tool to let you see mistakes. If you go too wild with the colors, it's true that since everything is a unique color, it's hard to tell when something is the wrong unique color. But you can use a relatively restrained palette and get a lot of value, and I think this post goes a bit too far in terms of reducing color usage.
I learned to code back when there was no syntax highlighting. You had one face, one font, one color on your 80x25 terminal. It might have been green, or amber, or white(ish) but that was it.
I'd prefer minimal-to-no syntax highlighting except for things that should NOT be there. Nonexisting keywords should be highlighted. Unclosed strings. Unbalanced parens or brackets.
I like making comments their own color so you can easily separate them from actual code but I'm otherwise in the minimal camp.
Your thoughts seem similar to mine. Going overboard with the colors just turns it all into visual noise. But cutting down as far as they have removes useful colors.
I've always thought the default Visual Studio color scheme was a nice balance. And I especially like the green comment color in that theme. It doesn't scream for your attention but also doesn't fade into the background (which, annoyingly, many themes do quite literally).
Of course if the author prefers their extra minimal colors I'm not going to tell them they're wrong. Though framing it as objectively better I do disagree with.
> But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually!
Yeah I generally want the opposite. I want keywords to be the thing being highlighted.
I also really dislike overly colorful themes, and I prefer light mode (dark mode is far too hard on my eyes, oddly enough I have to strain to focus or it's fuzzy).
But the author's alabaster theme still highlights the wrong things and is inconsistent.
public async Task<byte[]> SomeMethodName(Type param, Type param) results in Task, SomeMethodName, and BOTh the data type and parameter name being highlighted.
If highlighting isn't for keywords, why is Task and the data types highlighted?
likewise var result = await SomeMethodName(param, param); has result and SomeMethodName highlighted and I generally want the opposite, I want the PL's keywords highlighted and nothing else.
I prefer dark mode (precisely for the garish colors, sorry), but been using light mode... because it's hard to make everything use dark mode!
When my terminal was dark, the eg some docs in the browser were light, switching back and forth was quite painful. Yes, it's super simple for websites to detect the preferred color scheme with @media (prefers-color-scheme: dark) {}, yet most (such as this one) don't. I could use some hacks, but then I'm in for a world of pain. So I just use light theme everywhere and it's ok(ish).
> When my terminal was dark, the eg some docs in the browser were light, switching back and forth was quite painful.
I do this all the time (even at night without lights) with no problem at all. The key is to have properly set brightness/contrast on your monitor and gamma correction.
It can achieved by setting the brightness to a minimum (and use the contrast setting to go even lower, or even combine it with GPU settings in addition to monitor settings). It is also important to set a proper gamma correction so that darker/lighter levels don't have too big contrast.
The gamma correction needed can be measured by comparing the apparent thickness of antialiased text in black-on-white vs white-on-black color combinations that you toggle between. Once it is the same you get the right value. For example it's 1.3 on my LCD.
I was like this for a long time, but Dark Reader for Firefox and the default OS dark modes are good enough now I'd rather once in a blue moon fiddle with Dark Reader to correct a bad auto-color-assignment than put up with light mode in my browser and terminal overall. Just a thought. Until the last ~2 years, with win11, latest Linux desktops, and recent macOS all facilitating the change (if i couldn't do it everywhere i might still not do it, y'know? But they all actually work pretty reliably now)
I got started with Notepad on Windows, did that for almost a decade before switching to Linux and learning how to use vim. Definitely prefer the rainbow highlighting to going back to anything close to that.
Not sure I follow the first part of what you're saying.
For the part where you're describing what's possible or not in TypeScript/JS, though, you're incorrect:
You can't do something like title("hi") vs title({attr:123}, "hi")
Yes, you can. In JS it's trivial; in TypeScript, you can even do it while preserving type safety. Here's the function in TypeScript:
// First define which signatures are allowed
function title(content: string): string;
function title(attrs: Record<string, any>, content: string): string;
// Then, implement the function, handling the two possible cases:
function(contentOrAttrs: string | Record<string, any>, maybeContent?: string) {
const content = typeof contentOrAttrs === "string" ? contentOrAttrs : maybeContent!;
const attrs = typeof contentOrAttrs === "string" ? {} : contentOrAttrs;
// now use content and attrs as you please
}
This will be typechecked by the compiler so that if you call title("hi"), it'll know there are no more arguments, and if you call title({ attr: 123 }, "hi"), it'll validate that the first argument is a Record<string, any> and the second argument is a string.
that part was clarified later, "so you need to have fixed function signatures unless you want to have a lot of bother in implementing things"
I should not have used "can't" at that point, correct
To be more clear, you "can't" have a difference between an arbitrary object and a record, unless you know the type of the object and a way to disambiguate that from a record.
Of course, you "can" have a difference, a record "is" `typeof record === 'object' && Object.getPrototypeOf(record) === Object.getPrototypeOf({})` (At least as long as no one uses plain objects as non-recordy things), but, this isn't something I've ever had to care about in any other language. In some you have multiple dispatch built into the language, in some you can just pass named arguments arbitrarily. Javascript and Typescript are very inflexible in this aspect.
Americans are always looking for someone else to blame for their choices.
A bit of an ironic statement, given that this post is you blaming everyone except yourself for the role you played in deepening the opioid crisis to increase profits.
1. The Army gave a reasonable analysis of the security issues with the prototype.
2. This is normal.
3. But most people don't have experience in this field.
4. A reporter got access to the report, and published the most salacious-sounding parts — and if you don't know that this is normal, it sounds really bad.
5. Oh no, the sky is falling. Click here to watch our ads, oops I mean, to read all about it.
Generally my read on tech-adjacent reporters is they have very little understanding of what they're reporting on, and mostly try to manufacture outrage to get clicks.
The impulse may be stronger in some and weaker in others, and the incentive structure at their outlet may be stronger or weaker, but all of them know, even subconsciously, what type of stories are likelier to capture attention, make $ for the outlet and hopefully return a portion of that to them. Outrage is high the list of qualities that guarantee attention.
Since learning about social media algorithms, I've come to think of all news media, even old timey newspapers, in the same light. IMO The only difference between TikTok's For You page and newspaper headlines from 200 years ago was the precision of the engagement feedback and the latency.
It's true for everyone. Over the years, I've been on the business end of several "tech outrage" stories that made the headlines on HN, and over time, became a sort of IT canon: "company X did something really bad".
And they all had the same origin: a party with an ax to grind latched onto a fairly boring story, distorted the facts to tell a narrative, and that narrative "clicked" with everyone else because it confirmed their preexisting biases.
It doesn't mean that there are no companies that are truly evil or incompetent, but I'd wager is <50% of the ones that get raked over the coals here and elsewhere.
Yep — sadly the most effective cure is being on the receiving end of one of the stories, and realizing how bad faith they are.
I think the U.S. slander laws are probably too light. I'm generally supportive of the idea that "democracy dies in darkness," but I think we've gone further than that in allowing people to lie in public for money. I don't think that helps democracy, and in fact probably hurts it. I think anyone, anywhere on the political spectrum, can point to damning examples of the other side lying for their cause, and I think we'd all be better off if that stopped.
Journos wouldn’t have to get clicks, if you people (yes, you people) would pay for journalism but no lets continue to post archive links on HN.
I’m throughly disappointed by the pampered, know-it-all tech class who continually complain about the world but refuses to make investments or engage in collective bargaining to force the tech billionaire class.
Apparently all it takes to sell one’s soul is the feeling of superiority, $150k+ wages and stock options.
I doubt they'd cheat that obviously... But "SVG of X" has become common enough that I suspect most frontier labs train on it, especially since the models are multimodal now anyway.
Not that I mind; I want models to be good at generating SVG! Makes icons much simpler.
reply