Counterpoint: a major use case for this technology would be to experiment on human brain structures to research and hopefully cure neurological diseases like Alzheimer's. If you want to cure Alzheimer's in humans, you might as well use human brain cells from the start.
But yes, I agree that they're likely using human brain cells mainly because it's attention-getting.
Is there a reason they're using human brain cells specifically? This seems like it would also work with neurons from other creatures.
I was under the impression that the relative intelligence of humans versus other animals was largely a function of brain cell quantity, not quality. Can 200k human brain cells really learn faster than 200k mouse brain cells?
A more cynical take is that they're just using human brain cells for shock value. They chose DOOM because of the "can it run DOOM" meme, so they clearly value publicity a lot.
> You do realize there is both lossy and lossless compression, right?
This is simply wrong. There is no lossy compression for ZIP.
DEFLATE, by far the most common ZIP compression method, uses LZ77 and Huffman Coding, both of which are lossless. There are other methods compatible with ZIP containers as specified by PKWARE (e.g. BZIP2, LZMA, Zstandard, PPMd, etc), but all of them are lossless. According to both the official ZIP specification and every ZIP implementation on Earth, you cannot have a lossy ZIP unless it is corrupted.
There do exist lossy data formats (e.g. JPEG), but if you put those in a ZIP file it'll still encode and decode it losslessly.
> Did you hyperfixate on the colloquial usage of zip?
No? I am not hyperfixating on the colloquial usage of ZIP. The colloquial usage of "zip" would be "any compression container", which is not what I'm talking about. I'm talking about the technical definition of ZIP: the lossless container format specified by PKWARE. I thought that would be obvious by my reference to the PKWARE specification.
@godelski clearly indicated 8 days ago they were not referring to to formal ZIP files.
Your misunderstanding might be due to not being exposed to long standing casual usage of "zipping" something up to include many archiving formats, a number of which do include lossy compression methods.
Congrats on being a 15 year old developer, though .. some of the folk kicking about on HN wrote the books(?) you may have read.
Putting aside both my age and the latency of my initial response, all that I was trying to do was correct godelski's erroneous attempted correction of sweetjuly's lighthearted joke. The "colloquial usage of zip" that godelski was chiding sweetjuly for "hyperfixating" on is exactly the usage that godelski was using in their original reply. I did not misunderstand godelski's intended use: they were using "zip" to refer to "any compression format whatsoever, be it lossy or lossless". This is a technically incorrect usage, which would be fine if not for the snarky chiding. I think that misusing a term and then accusing people of "hyperfixating" when they lightheartedly correct you isn't a particularly nice thing to do.
\1 godelski colloquially used the term zip (Not referring to formal ZIP files)
\2 sweetjuly made reference to ZIP files not having lossy methods
\3 godelski indicated they had use zip colloquially, not with the intention of referencing the precise ZIP specification.
\4 ethmarks stepped in and doubled down on the precise ZIP specification, despite that not being what godelski initially referred to.
Here's the thing, people make casual remarks, they use imprecise non technical colloquillisms.
How would you describe the actions in \4 ? Do you believe it served a useful purpose to double down and restate something that was very likely well known to both parties over a week ago?
> Here's the thing, people make casual remarks, they use imprecise non technical colloquillisms.
I think that you're completely misunderstanding my objection here. I'm not in the least bit upset by people using "zip" casually to mean something other than formal ZIP files. I personally use "zip" as a verb to describe compressing to a tarball, for example. This is a technically incorrect usage, but it's okay for things not to be absolutely technically correct.
My objection is to \3, both to your summary of it and to the actual message content. godelski did not "indicate that they had used zip colloquially"; they accused sweetjuly (who fully understood that godelski was using the term colloquially and was simply making a humorous, playful, and lighthearted correction that didn't warrant further reply) of hyperfixating on the colloquial usage of zip. This is not only technically wrong (sweetjuly was "hyperfixated" on the technical definition, not the colloquial usage), but it's also accusatory and mean-spirited.
> Do you believe it served a useful purpose to double down and restate something that was very likely well known to both parties over a week ago?
Not in a strictly pragmatic sense, no. I intended to set the record straight by clarifying the factually accurate statement that ZIP is not a lossy format, which seemed to be contested. I didn't expect anybody to read my comment to an 8-day-old threat, nor did I expect anyone to reply to it barely 3 minutes later, nor did I expect to be drawn into a 7-reply-long debate about this.
Isn't it delightful how well we've proved godelski's original point about how fraught natural language is?
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Strong wording there, from you .. do you suppose that was a vicuous stabbing accusation, or a playful rejoiner questioning the zip V ZIP ambiguity? People do get a bit playful.
> nor did I expect anyone to reply to it barely 3 minutes later,
Apparently the site itself is written in Loon. The HTML is just a static shell that loads a `boot.js` script[1] that runs some WASM that compiles and evals the Loon source files. I found the source code here[2].
Definitely cool in concept, but very performance-intensive and slow.
Because we don't know if this would scale well to high-quality frontier models. If you need to manufacture dedicated hardware for each new model, that adds a lot of expense and causes a lot of e-waste once the next model releases. In contrast, even this current iteration seems like it would be fantastic for low-grade LLM work.
For example, searching a database of tens of millions of text files. Very little "intelligence" is required, but cost and speed are very important. If you want to know something specific on Wikipedia but don't want to figure out which article to search for, you can just have an LLM read the entire English Wikipedia (7,140,211 articles) and compile a report. Doing that would be prohibitively expensive and glacially slow with standard LLM providers, but Taalas could probably do it in a few minutes or even seconds, and it would probably be pretty cheap.
I can't speak for Tesla's FSD specifically, but Waymo did a study on the collision rate of their autonomous cars compared to human drivers: https://waymo.com/safety/impact/. They found that Waymos get into about 81% fewer crashes per mile. Compared to a statistical human driver, Waymo prevented around 411 collisions that would have resulted in any injury, and 27 collisions that would have resulted in serious injury or death. It seems like for Waymo specifically, self-driving cars are demonstrably safer than human drivers. Not sure if that generalizes to Tesla FSD, though.
> I can't speak for Tesla's FSD specifically, but Waymo did a study on the collision rate of their autonomous cars compared to human drivers: https://waymo.com/safety/impact/. They found that Waymos get into about 81% fewer crashes per mile.
I think that's true. Though I recall that Waymo limits their cars to safer and more easily handled conditions, which is totally the right thing to do, but it probably means that statistic needs an asterisk.
> Not sure if that generalizes to Tesla FSD, though.
I don't think it does. They're two totally different systems.
I guess it depends on whether you're only executing the code or if you're submitting it for humans to review. If your use case is so low-stakes that a review isn't required, then vibe coding is much more defensible. But if code quality matters even slightly, such that you need to review the code, then you run into the same problems that you do with AI-generated prose: nobody wants to read what you couldn't be bothered to write.
There’s lots of times where I just don’t care how it’s implemented.
I got Claude to make a test suite the other day for a couple RFCs so I could check for spec compliance. It made a test runner and about 300 tests. And an html frontend to view the test results in a big table. Claude and I wrote 8500 lines of code in a day.
I don’t care how the test runner works, so long as it works. I really just care about the test results. Is it finding real bugs? Well, we went though the 60 or so failing tests. We changed 3 tests, because Claude had misunderstood the rfc. The rest were real bugs.
I’m sure the test runner would be more beautiful if I wrote it by hand. But I don’t care. I’ve written test runners before. They’re not interesting. I’m all for beautiful, artisanal code. I love programming. But sometimes I just want to get a job done. Sometimes the code isn’t for reading. It’s for running.
What is it about the tests that make you not care about how it’s implemented versus other code? Just the fact that it isn’t interesting to you? I happen to like spec-testing code and find it an interesting design space. It is vital to review it thoroughly for correctness. But I also think that whether I find something interesting or not doesn’t have much bearing on whether code quality is important. Code quality can even be more important for uninteresting code, because due to the lack of interest I’ll have a lower attention span when reviewing it.
> What is it about the tests that make you not care about how it’s implemented versus other code?
Huh this is a thought provoking question.
I think there's a few reasons. In a test suite:
- I don't care about performance.
- I don't care (as much) about reliability. My users aren't affected by crashes and other failures in my tests.
- I don't care (as much) about correctness. Erroneously failing tests will get human attention. Tests that erroneously pass are a bigger problem, but my test suite is not the last line of defence against bugs reaching users.
- If I had infinite time, I'd love every line of code to be a mathematically beautiful work of art. But I don't. Writing this test suite by hand would have taken me about 3 weeks. Instead, I did it in 1 day with claude. This let me spend 14 productive days working on other things. I would rather have a good-enough test suite and 14 days of productive work than an excellent test suite and nothing else. I could spend those 14 days fixing all the bugs it found. Or writing more tests. Or getting claude to write more tests. Or going outside with my friends. These are all better uses of my time.
If I was writing the core of a new game engine, the scheduler of an operating system or the data storage engine for a new database, then I would think hard about every line of code. But not all code is like that. We must adapt ourselves to the project at hand. Some lines of code matter a lot more than others. Our workflow should take that into account.
What makes Astro fast isn't just that it's static, it's that it automatically pre-renders and it doesn't ship a runtime. React can render to static as well, it just also ships the React runtime.
I read the original version a few years ago and read the new version when it came out, and I thought that the name changes were pretty amusing. qntm kept the story as close to the original as possible while still making it a legally distinct work for copyright purposes. It's like those off-brand Froot Loops called "Fruit Spins" that are juuust different enough to not get into trademark issues. Except in Antimemetics' case, the "knockoff" version was made by the creator of the original, which I think is pretty funny.
But yes, I agree that they're likely using human brain cells mainly because it's attention-getting.