Hacker News new | past | comments | ask | show | jobs | submit | lgessler's comments login

> Fermentation is completely stopped in a regular fridge, you need higher temperature for fermentation.

My understanding as a hobbyist brewer and fermenter is that this is not true. Fermentation is greatly slowed at lower temperatures, but you should have things happening above freezing. Lager beers, for example, go from pure sugar to beer at 35F. And kimchi matures at fridge temperatures in ways that I'm pretty sure are caused by fermentation.


I think this is both a harmful and irrational attitude. Why focus on some trivial mechanical errors and disparage the authors for it instead of the thing that is much more important, i.e., the substance of the work? And in dismissing work for such trivial reasons, you risk ignoring things you might have otherwise found interesting.

In an ideal world would second-language speakers of English proofread assiduously? Of course, yes. But time is finite, and in cases like this, so long as a threshold of comprehensibility is cleared, I always give the benefit of the doubt to the authors and surmise that they spent their limited resources focusing on what's more important. (I'd have a much different opinion if this were marketing copy instead of a research paper, of course.)


>in dismissing work for such trivial reasons, you risk ignoring things you might have otherwise found interesting

Not dismissing work for trivially avoidable mistakes risks wasting your precious, limited lifespan investing effort into nonsense. These signals are useful and important. If they couldn't be bothered to proofread, what else couldn't they be bothered to do?

>spent their limited resources focusing on what's more important

Showing that you give a crap is important, and it takes seconds to run through a spell checker.


Well, it not exactly a research paper, more an overview of the problem and suggested techniques, but it'd still be interesting to hear some criticism based on the content rather than the (admittedly odd) omission to run it through a spell checker. I do wonder why it was written in English, apparently targeting a western audience.

Two of the authors are from "Shanghai AI Labs" rather than students, so one might hope it had at least been proofread and passed some sort of muster.


With all respect and love to the OP, I must admit that I laughed out loud when I saw the AWS architectural diagram and wondered whether this might be a joke. Personally, I'd have implemented this as a few dozen lines of Python living as a cron job (or even as a long-lived process with a schedule), but I'm no pedigreed engineer.


Fair enough! As mentioned earlier, one reason I used AWS/Terraform is for personal learning. It may not be the most efficient approach, but I built it this way because it was the most enjoyable for me. :)


I do the same on my personal projects. Big over engineering projects for learning purposes :-)


If you're using Terraform on AWS as a learning experience I hope you're using a pre-paid card.


> With all respect and love to the OP, I must admit that I laughed out loud when I saw the AWS architectural diagram

OP actually did it more efficiently than most! You should see the AWS suggested architecture. It uses something like 10 different AWS services.

My company actually set out to solve this very problem. We have a cloud cron hosting that's more reliable than the AWS architecture but just requires a few lines of code. Literally this is all you have to do:

    @DBOS.scheduled('* * * * *')
    
    @DBOS.workflow()
    def example_scheduled_workflow(scheduled_time: datetime, actual_time: datetime):
      DBOS.logger.info("I am a workflow scheduled to run once a minute.")
https://github.com/dbos-inc/dbos-demo-apps/blob/main/python/...


I think this is where Cloudflare shines. They just focussed on the essentials with Workers (“serverless”) at the core of everything instead of VPS at the core of everything.


Yes, DBOS has a similar philosophy. Strip away all the hard and annoying parts, let you just code. Our other philosophy is "just do it in Postgres". :)

FWIW you can't really do the same thing on Cloudflare workers -- their crons are "best effort", and you'd still need to get storage somewhere else. With DBOS the storage is built right in.


Cloudflare Durable Objects have alarms you can use to imitate cron, and have storage built-in (there's even support for SQLite databases attached to DOs in beta)


You’re not kidding about AWS’s own architecture diagrams.


Although if you drew that out you'd have about the same.

Cron trigger.

Process.

Gpt API.

Database for persistence.

Email sender.

Which part of that wouldn't you have?


This is a great fit for Google AppScript.


Who likes to learn a niche scripting language that only works on one platform?


It's ordinary javascript. It interacts with many google services including gmail without having to actually maintain servers or setup authentication. It's perfect for small little glue tasks like sending yourself emails or anything that interacts with Sheets. You wouldn't use it if you weren't trying to use a Google service.


I think GP is saying that just lines on the same plot would have been less deceptive, whereas the plot that is actually there has fake data points. Readers are used to the former being purely imaginative, whereas the latter almost always means there's real measurement involved.


Extended (or rather, distended) Markdown flavors always make me queasy, and I don't love the snippet from Code Hike. In my mind, Markdown is fundamentally intended to be lightweight--something for a Reddit post or a blog comment. Heavily extending its syntax instead of choosing a saner syntactic basis strikes me as ill-advised. But one can't deny the advantages for adoption to be had from using Markdown as a starting point, and the project appears to be very popular, so perhaps worse is better.


This has led to work showing that models can do better sometimes if you decompose these into their constituent characters, e.g.: https://aclanthology.org/2022.emnlp-main.472.pdf


A paper on Korean where the main acronym is BTS has got to be intentional, right?


> We hope that our BTS will light the way up like dynamite[9] for future research on Korean NLP.


I'll add mine to the pile: I needed a visualization of the classic Towers of Hanoi puzzle for a course I'm teaching and Claude banged it out (in pure JavaScript, no less) in like 3 minutes of me typing: https://lgessler.com/files/towers.html

The first stab was basically correct, but then I needed to prompt him several times to correct an issue where the disk that's currently picked up was being rendered as a vertical strip instead of as a disk, and then I just told him to convert the React into pure JS and IIRC it worked first try.


This is interesting, I also tried this with my daughter after we had been talking about Towers of Hanoi, and like you it worked really well. Then we tried to get it to implement a little version of the game where you have a farmer, some corn, a chicken and a wolf and you have to get them across the river in only one boat (actually Wiki says goat and cabbage, but whatever https://en.wikipedia.org/wiki/Wolf,_goat_and_cabbage_problem). I wasn't trying to get it to solve the puzzle, just give us a UI to play the game. We gave up after an hour or more of going in circles. I wonder if there's a lot of Towers of Hanoi implementations out there it can use as references.


I'm afraid I feel that this piece confuses more than it clarifies.

First, saying a model "scours through its vast training data" is misleading at best: at inference time, LLMs no longer have direct access to their training data; they only have access to it insofar as it's been encoded in its parameters.

Second, saying "Every instance of an answer in the training data is like a vote" doesn't give the full picture. First of all, there are embedded contexts where "votes" can be negated: consider saying "the Earth is flat." vs. "We know it's false that the Earth is flat." or "Only a fool thinks the Earth is flat." All three contain the substring "the Earth is flat.", but both humans and LLMs are able to use context to understand that the latter two sentences are doing the opposite of endorsing the proposition that the Earth is flat. You could even imagine an extended satirical bit with "the Earth is flat" embedded within it where it is clear to a reader that all its content is intended to be taken as farcical, and I'd wager that an LLM would in many cases recognize this. So the voting metaphor breaks down here--it makes you think that the LLM is just keeping a tally of propositions, but really, it is doing something a bit more sophisticated.

I don't disagree with the premise, of course. LLM overhype is real. But we should be skeptical for the right reasons. Anna Rogers and Sasha Luccioni have a paper I really like: https://openreview.net/pdf?id=M2cwkGleRL


IMHO reviews are almost indistinguishable from noise at the AI conferences I'm familiar with these days anyway, so I don't see much of a value add.


Sad state of affairs, people are incentivized to get more papers and citations at all costs, and quality be damned.

An AI Winter is not a great an idea, but an AI Autumn may be beneficial.

Just have no major AI conferences for ‘25, perhaps only accept really high tier literature reviews.


GP wrote "simple to use API". You can attribute many qualities to TensorFlow, but this is not one of them.


Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: