Hacker Newsnew | past | comments | ask | show | jobs | submit | barishnamazov's commentslogin

The production quality of this video is almost too good to be true! Kudos to Yukidama!

Also want to share B- tree implementation from the Algorithmica HPC book: https://en.algorithmica.org/hpc/data-structures/b-tree/

> You often need a real environment to iterate, even for the agent: debug, inspect logs, run the dev server, and use the frontend to actually verify behavior. Without that shared runtime, the agent’s feedback loop isn't tight enough, and you can't verify changes as well.

Cloud environments can do that (e.g., Github Copilot). They can even spin up playwright and take screenshots of an app and do frontend tests.


Agreed, but they don't allow you to intervene if needed, like you would in your local browser (inspect element etc), its usually a closed box.

Would be nice to have publicly accessible URL for each environment for eg.


arXiv creator[0] is one of the co-authors, which gives me better assurance on data collection aspect of the paper.

[0] https://en.wikipedia.org/wiki/Paul_Ginsparg


The key finding here is the reversal of the relationship between writing complexity and paper quality.

Traditionally, sophisticated writing correlated with higher-quality research (or at least higher status/effort). This paper argues that post-LLM, we are seeing a flood of manuscripts that use complex, polished language but contain substantively weaker scientific contribution.

They claim LLM adoption increases output by up to 89%, which is a massive productivity shock. If the cost of generating looks-like-science prose drops to near zero, the signal-to-noise ratio in peer review is going to crash. We are entering the era of the polished turd, and likely worse case of publish and perish [0].

[0] https://en.wikipedia.org/wiki/Publish_or_perish


I don’t like how we speak of science and knowledge in terms of production. This is not a factory. We are not in the business of churning out units.

But what I might expect is not a worse case of publish or perish, but the collapse of this pathology. If churning out crap is cheap, it will render publishing worthless. What I might expect is greater decentralization. Researchers might share reports and articles with colleagues directly. Networks of trust vs. broadcasting.


I don't like how we talk about humans as factories either. That we re all here to be a "productive" as possible. That are life is measured in how much crap we produced.

I would love for this same ethos to spread to other domains. Why DO we hoard things so much? Why don't we just share more? Is it fear? Is it game -theory?

How many households have thousands of dollars worth of equipment to maintain that very household that each is used maybe ~30 minutes a week.

Why do we keep churning out more plastic crap that just sits in our spaces. Unused


Some parts of science can be automated and scaled immensely. Like, look at the science that went into building modern large language models. Massive numbers of theory driven empirical experiments. Ironically, not many papers being written about much of it.

In many domains, human ego is the bottleneck— or maybe organizational incentives. Most scientists work largely alone—a lot more could be done with the right leadership.


we wish it wasn't, but it totally is — in microbiology at least if you don't find anything meaningful to publish even students/post docs in the best unis like Stanford will still put out tons of review papers and microbial resource announcements

The discipline of writing for sharing knowledge is immense - not only for the sharing part, but to look at yourself (or your research) in the mirror with a critical eye and revise it multiple times. If you don't have that discipline, sharing knowledge even with colleagues / networks becomes harder. It's not only LLM churning out slop, but it's also without that discipline, the researcher putting out half finished work.

Think of the use of ML towards formal verification, a putative ML generated proof can be easily checked with a classical verification algorithm.

What will happen is that we just translate more and more physics and engineering into a rigorous formal system, and then those deductions become verifiable. Actual measurements are another matter, and its not unimaginable petty humans will HAVE TO organize measurement tools (DMM, oscilloscope, ...) to cryptographically sign measurements, and to also sign schematic connectivity (yeah, so the oscilloscope or DMM probe terminals and the terminals of say an amplifier etc would be "smart" and sign the fact they are connected during the experimental setup. All to prevent people from faking measurements.

BUT if this is done we can transport physics and engineering into the decentralized formally verifiable domain.

After that biology for example could work, but formalizing ethics or (direct) democratically established rules and medicine at the same time will result in collective realization of certain inconsistencies (not unlike intervention vs non-intervention when watching lions hunt zebra's).


I never cease to be utterly unsurprised how people conflate emotional controversy with disagreement.

shoot the messenger and all that


Right. In my previous work, I wrote a custom XML formatter for making it look table-like which was our use case. Of course, an ideal solution would have been to move away from XML, but can't run away from legacy.

I appreciate the polish for non-technical folks, but "clipboard formatter" feels like a feature, not a product. All of this can be done with AutoHotKey script for Windows and similar open-source tools for the other OS. And given how sensitive is clipboard data (passwords, keys, etc.) using a third-party app feels a bit uncomfortable.

You're absolutely right that you can script this if you have the know-how. I used AHK for years before building this.

But the main goal here is to offer that power to people who don't have the time or desire to learn scripting syntax, set up environments or debug code. They just want a tool that works out of the box. And even for technical folks, maintaining a script that parses complex HTML/RTF without breaking on nested tags (which often happens with Regex) is a headache I wanted to solve permanently.

Regarding privacy, that was actually my top priority when designing the architecture. I'm fully aware of how sensitive clipboard data is, which is why I built it to run 100% locally. You can literally block the app in your firewall or physically disconnect your internet and it works perfectly, I even built an offline license activation method specifically for high-security environments.


As a point of validation, I would use this even though I have know about AHK for years. I don’t have any interest in developing an AHK hobby and I value the specific single feature “strip non-bold/italic/underline/hyperlink formatting”. Thanks for making it :)

Thanks!

That exact feature, keeping the structure (bold/italic...) but stripping the junk was actually the hardest part to build. It requires parsing the full object tree recursively to make it compatible with any app, instead of just doing simple text replacements.

I saw so many people looking for that "middle ground" that I basically built the whole app around it. Glad it resonates!


You'll do better showing this to the people who would be your users. Looks like a solid idea to make some money on the side solving a problem you actually have.

A lot of people on HN wouldn't be your users. That's fine. Find them and post this there.


This is pretty cool, but I hope it isn't used for human-readable config files. TOML/YAML are better options for that. Git diff also can be tricky with realignment, etc.

I can see potential usefulness of this is in debug mode APIs, where somehow comments are sent as well and are rendered nicely. Especially useful in game dev jsons.


Yaml is the worst. Humans and LLMs alike get it wrong. I used to laugh at XML but Yaml made me look at XML wistfully.

Yaml - just say Norway


The Norway issue is a bit blown out of proportion seeing as the country should really be a string `"no"` rather than the `no` value

YAML strings should really require delimiters rather than being context-dependent.

Yeah, but it's a fun slogan. My real peeve is constantly getting the spaces wrong and no tooling to compensete for its warts. If there were linters and test frameworks and unit tests etc for yaml, I'd just sigh and move on. But current situation is, for instance in ADO Yaml: "So it's time to cut a release and time is short - we have a surprise for you! This will make some condition go true which triggers something not tested up till now, you will now randomly commit shit on the release branch until it builds again."

Stuff that would have been structurally impossible in XML will happen in yaml. And I don't even like XML.



Just say Norway to YAML.

This is a reference to YAML parsing the two letter ISO country code for Norway:

    country: no
As equivalent to a boolean falsy value:

    country: false
It is a relatively common source of problems. One solution is to escape the value:

    country: “no”
More context: https://www.bram.us/2022/01/11/yaml-the-norway-problem/

I think it would be better to require quotation marks around all string values, in order to avoid this kind of problems. (It is not the only problem with YAML, but it is my opinion of how any format with multiple types should require explicitly mentioning if it is a string type, but YAML (and some other formats) doesn't.) (If keys are required to strings, then it can be reasonable to allow keys to be unquoted if the set of characters that unquoted keys can contain is restricted (and disallowing unquoted empty strings as keys).)

We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?

Current PyYAML:

  >>> import yaml
  >>> yaml.safe_load("country: NO")
  {'country': False}
Other people did not stop having this problem.

It might be that there’s some setting that fixes this or some better library that everyone should be switching to, but YAML has nothing that I want and has been a repeated source of footguns, so I haven’t found it worth looking into. (I am vaguely aware that different tools do configure YAML parsing with different defaults, which is actually worse. It’s another layer of complexity on an already unnecessarily complex base language.)


The ancient rule of ”use software that is updated with bugfixes” certainly applies here.

A new spec version doesn’t mean we stop having the problem.

E.g. kubernetes wrote about solving this only five months ago[1] and by moving from yaml to kyaml, a yaml subset.

[1]: https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak...


The 1.1 spec was released about _twenty_ years ago, I explicitly used the word _implemented_ for a reason. As in: Our Yaml lib vendor had begun officially supporting that version more than ten years ago.

Note that you reference 1.1, I think that version still had the norway behavior.

1.1 partially fixed it, so that strings (quoted ”no”) did not become Boolean false. 1.2 strengthened it to remove unquoted no from list of tokens which could be interpreted as Boolean false.

> 1.1 partially fixed it, so that strings (quoted ”no”) did not become Boolean false.

Do you have a source? Afaik v1.1 didn’t introduce such a change, v1.0 specified the same behavior for quoted strings, i.e. in v1.0 a quoted “no” would remain a string “no” as well.


Because there's a metric ton of software out there that was built once upon a time and then that bit was never updated. I've seen this issue out in the wild across more industries than I can count.

I’m not here clanking down on Java for lacking Lambda features, the problem is that I did not update my Java environment past the 2014 version, not a problem with Java.

I think this mixes up two separate things. If you're working with Java, it's conceivable that you could probably update with some effort. If you're an aerospace engineer using software that was certified decades ago for an exorbitant amount of money, it's never going to happen. Swap for nearly any industry of your liking, since most of the world runs on legacy software by definition. A very large number of people running into issues like these are not in a position where they could solve the problem even if they wanted to.

That’s about 99% of the argument I am making. The problem is legacy software and bad certification workflows, not the software being used.

If I’m working with Java it’s indeed conceivable that I could update with some effort.

If I’m working with Node it’s conceivable that I could update with some effort.

If I working with YAML is it not conceivable that I could update with some effort?

PHP is stupid because version 3 did not support object oriented programming.

CSS is bad because version 2 did not support grid layouts or flexbox.

Why should I critique on these based on something that they have fixed a long time ago instead of working on updating to the version which contain the fix I am complaining about?

There is a gradient limit where the onus shifts squarely to one side once the spec has changed and a number of libraries have begun supporting the new spec.


Because once a technology develops a reputation for having a problem it's practically impossible to rehabilitate it.

Now add brackets and end-tags, I'll reconsider. ;)

Brackets works fine:

    Roles: [editor, product_manager]
End tags, that I’m not sure what that is. But three dashes is part of the spec to delineate sections:

    something:
        setting: true
    ---
    another:
        thing: false

Yaml works really well with LLMs (not to generate but to consume). So yes, we use it all the time in our service.

Extremely sad that this happened, especially on a holiday night. My condolences and may the injured recover soon.

Why is Bun marked as no on node_modules (I assume it means NodeJS compatibility)? I have large applications and never had NodeJS compatibility issues (it has worked even when Bun wasn't officially supported).

For benchmarks, I'd try to compare Bun's speed using its own Bun.serve instead of Express or Fastify.


no node_modules means that both bun and we don't have the dreaded node_modules folder.

thanks for the benchmark suggestion, we used express and fastify because thats also what's bun is benchmarking and comparing to node and deno


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: