<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: lgessler</title><link>https://news.ycombinator.com/user?id=lgessler</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 23 Apr 2026 01:27:41 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=lgessler" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by lgessler in "Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model"]]></title><description><![CDATA[
<p>I'll be really interested to hear qualitative reports of how this model works out in practice. I just can't believe that a model this small is actually as good as Opus, which is rumored to be about two orders of magnitude larger.</p>
]]></description><pubDate>Wed, 22 Apr 2026 19:29:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=47868161</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=47868161</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47868161</guid></item><item><title><![CDATA[New comment by lgessler in "Writing Lisp is AI resistant and I'm sad"]]></title><description><![CDATA[
<p>Is Java or Haskell any closer to human language?</p>
]]></description><pubDate>Sun, 05 Apr 2026 04:24:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=47646092</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=47646092</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47646092</guid></item><item><title><![CDATA[New comment by lgessler in "If you thought the code writing speed was your problem; you have bigger problems"]]></title><description><![CDATA[
<p>Has everyone always nailed their implementation of every program on the first try? Of course not. Probably what happens most times is you first complete something that sorta works and then iterate from there by modifying code, executing, observing, and looping back to the beginning. You can wonder about ultimately how much of your time/energy is consumed by the "typing code" part, and there's surely a wide range of variation there by individual and situation, but it's undeniable that it is a part of the core iteration loop for building software.<p>I don't understand why GP's comment is so controversial. GP is not denying that you should maybe think a little before a key hits the keyboard as many commenters seem to suppose. Both can be true.</p>
]]></description><pubDate>Tue, 17 Mar 2026 19:16:00 +0000</pubDate><link>https://news.ycombinator.com/item?id=47416925</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=47416925</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47416925</guid></item><item><title><![CDATA[New comment by lgessler in "Show HN: Han – A Korean programming language written in Rust"]]></title><description><![CDATA[
<p>I know this is mostly about keyword substitution but it still tickles me that you still write f(x) in this language and not (x)f given that Korean is SOV but I guess that's just how you notate that no matter what cultural context you're in. Hadn't ever considered that the convention of writing a function before its arguments might have been a contingency of this notation being developed by speakers of SVO languages.</p>
]]></description><pubDate>Sun, 15 Mar 2026 00:58:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=47383111</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=47383111</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47383111</guid></item><item><title><![CDATA[New comment by lgessler in "Claude Code is being dumbed down?"]]></title><description><![CDATA[
<p>Let's be real here, regardless of what Boris thinks, this decision is not in his hands.</p>
]]></description><pubDate>Thu, 12 Feb 2026 02:02:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=46984011</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=46984011</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46984011</guid></item><item><title><![CDATA[New comment by lgessler in "Cognitive load is what matters"]]></title><description><![CDATA[
<p>Novels are fictional too. So long as they're not taken too literally, archetypes can be helpful mental prompts.</p>
]]></description><pubDate>Sat, 30 Aug 2025 17:15:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=45076319</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=45076319</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45076319</guid></item><item><title><![CDATA[New comment by lgessler in "Gemma 3 270M re-implemented in pure PyTorch for local tinkering"]]></title><description><![CDATA[
<p>If you're really just doing traditional NER (identifying non-overlapping spans of tokens which refer to named entities) then you're probably better off using encoder-only (e.g. <a href="https://huggingface.co/dslim/bert-large-NER" rel="nofollow">https://huggingface.co/dslim/bert-large-NER</a>) or encoder-decoder (e.g. <a href="https://huggingface.co/dbmdz/t5-base-conll03-english" rel="nofollow">https://huggingface.co/dbmdz/t5-base-conll03-english</a>) models. These models aren't making headlines anymore because they're not decoder-only, but for established NLP tasks like this which don't involve generation, I think there's still a place for them, and I'd assume that at equal parameter counts they quite significantly outperform decoder-only models at NER, depending on the nature of the dataset.</p>
]]></description><pubDate>Wed, 20 Aug 2025 21:11:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=44966516</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=44966516</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44966516</guid></item><item><title><![CDATA[New comment by lgessler in "FFmpeg 8.0 adds Whisper support"]]></title><description><![CDATA[
<p>I recommend having a look at 16.3 onward here if you're curious about this: <a href="https://web.stanford.edu/~jurafsky/slp3/16.pdf" rel="nofollow">https://web.stanford.edu/~jurafsky/slp3/16.pdf</a><p>I'm not familiar with Whisper in particular, but typically what happens in an ASR model is that the decoder, speaking loosely, sees "the future" (i.e. the audio after the chunk it's trying to decode) in a sentence like this, and also has the benefit of a language model guiding its decoding so that grammatical productions like "I like ice cream" are favored over "I like I scream".</p>
]]></description><pubDate>Wed, 13 Aug 2025 11:36:28 +0000</pubDate><link>https://news.ycombinator.com/item?id=44887204</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=44887204</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44887204</guid></item><item><title><![CDATA[New comment by lgessler in "Grok: Searching X for "From:Elonmusk (Israel or Palestine or Hamas or Gaza)""]]></title><description><![CDATA[
<p>In my (poor) understanding, this can depend on hardware details. What are you running your models on? I haven't paid close attention to this with LLMs, but I've tried very hard to get non-deterministic behavior out of my training runs for other kinds of transformer models and was never able to on my 2080, 4090, or an A100. PyTorch docs have a note saying that in general it's impossible: <a href="https://docs.pytorch.org/docs/stable/notes/randomness.html" rel="nofollow">https://docs.pytorch.org/docs/stable/notes/randomness.html</a><p>Inference on a generic LLM may not be subject to these non-determinisms even on a GPU though, idk</p>
]]></description><pubDate>Fri, 11 Jul 2025 01:10:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=44527453</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=44527453</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44527453</guid></item><item><title><![CDATA[New comment by lgessler in "How University Students Use Claude"]]></title><description><![CDATA[
<p>Sure, this is a common sentiment, and one that works for some courses. But for others (introductory programming, say) I have a really hard time imagining an assignment that could not be one-shot by an LLM. What can someone with 2 weeks of Python experience do that an LLM couldn't? The other issue is that LLMs are, for now, periodically increasing in their capabilities, so it's anyone's guess whether this is actually a sustainable attitude on the scale of years.</p>
]]></description><pubDate>Thu, 10 Apr 2025 02:44:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=43640148</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=43640148</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43640148</guid></item><item><title><![CDATA[New comment by lgessler in "How University Students Use Claude"]]></title><description><![CDATA[
<p>I'm a professor at an R1 university teaching mostly graduate-level courses with substantive Python programming components.<p>On the one hand, I've caught some students red handed (ChatGPT generated their exact solution and they were utterly unable to explain the advanced Python that was in their solution) and had to award them 0s for assignments, which was heartbreaking. On the other, I was pleasantly surprised to find that most of my students are not using AI to generate wholesale their submissions for programming assignments--or at least, if they're doing so, they're putting in enough work to make it hard for me to tell, which is still something I'd count as work which gets them to think about code.<p>There is the more difficult matter, however, of using AI to work through small-scale problems, debug, or explain. On the view that it's kind of analogous to using StackOverflow, this semester I tried a generative AI policy where I give a high-level directive: you may use LLMs to debug or critique your code, but not to write new code. My motivation was that students are going to be using this tech anyway, so I might as well ask them to do it in a way that's as constructive for their learning process as possible. (And I explained exactly this motivation when introducing the policy, hoping that they would be invested enough in their own learning process to hear me.) While I still do end up getting code turned in that is "student-grade" enough that I'm fairly sure an LLM couldn't have generated it directly, I do wonder what the reality of how they really use these models is. And even if they followed the policy perfectly, it's unclear to me whether the learning experience was degraded by always having an easy and correct answer to any problem just a browser tab away.<p>Looking to the future, I admit I'm still a bit of an AI doomer when it comes to what it's going to do to the median person's cognitive faculties. The most able LLM users engage with them in a way that enhances rather than diminishes their unaided mind. But from what I've seen, the more average user tends to want to outsource thinking to the LLM in order to expend as little mental energy as possible. Will AI be so good in 10 years that most people won't need to really understand code with their unaided mind anymore? Maybe, I don't know. But in the short term I know it's very important, and I don't see how students can develop that skill if they're using LLMs as a constant crutch. I've often wondered if this is like what happened when writing was introduced, and capacity for memorization diminished as it became no longer necessary to memorize epic poetry and so on.<p>I typically have term projects as the centerpiece of the student's grade in my courses, but next year I think I'm going to start administering in-person midterms, as I fear that students might never internalize fundamentals otherwise.</p>
]]></description><pubDate>Wed, 09 Apr 2025 23:19:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=43639035</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=43639035</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43639035</guid></item><item><title><![CDATA[New comment by lgessler in "Kimchi Refrigerator"]]></title><description><![CDATA[
<p>> Fermentation is completely stopped in a regular fridge, you need higher temperature for fermentation.<p>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.</p>
]]></description><pubDate>Sat, 11 Jan 2025 02:19:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=42662700</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=42662700</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42662700</guid></item><item><title><![CDATA[New comment by lgessler in "A path to O1 open source"]]></title><description><![CDATA[
<p>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.<p>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.)</p>
]]></description><pubDate>Sat, 04 Jan 2025 01:28:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=42591408</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=42591408</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42591408</guid></item><item><title><![CDATA[New comment by lgessler in "Show HN: I send myself automated emails to practice Dutch"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Fri, 27 Dec 2024 17:23:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=42524035</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=42524035</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42524035</guid></item><item><title><![CDATA[New comment by lgessler in "The Curse of Markdown"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Tue, 03 Dec 2024 20:06:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=42310680</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=42310680</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42310680</guid></item><item><title><![CDATA[New comment by lgessler in "The Curse of Markdown"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Tue, 03 Dec 2024 20:05:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=42310662</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=42310662</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42310662</guid></item><item><title><![CDATA[New comment by lgessler in "History of Hangul"]]></title><description><![CDATA[
<p>> We hope that our BTS will light the way up like dynamite[9] for future research on Korean NLP.</p>
]]></description><pubDate>Sun, 24 Nov 2024 23:21:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=42231485</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=42231485</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42231485</guid></item><item><title><![CDATA[New comment by lgessler in "History of Hangul"]]></title><description><![CDATA[
<p>This has led to work showing that models can do better sometimes if you decompose these into their constituent characters, e.g.: <a href="https://aclanthology.org/2022.emnlp-main.472.pdf" rel="nofollow">https://aclanthology.org/2022.emnlp-main.472.pdf</a></p>
]]></description><pubDate>Sun, 24 Nov 2024 18:45:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=42229558</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=42229558</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42229558</guid></item><item><title><![CDATA[New comment by lgessler in "Everything I built with Claude Artifacts this week"]]></title><description><![CDATA[
<p>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: <a href="https://lgessler.com/files/towers.html" rel="nofollow">https://lgessler.com/files/towers.html</a><p>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.</p>
]]></description><pubDate>Thu, 24 Oct 2024 02:40:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=41931399</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=41931399</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41931399</guid></item><item><title><![CDATA[New comment by lgessler in "LLMs Aren't Thinking, They're Just Counting Votes"]]></title><description><![CDATA[
<p>I'm afraid I feel that this piece confuses more than it clarifies.<p>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.<p>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.<p>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: <a href="https://openreview.net/pdf?id=M2cwkGleRL" rel="nofollow">https://openreview.net/pdf?id=M2cwkGleRL</a></p>
]]></description><pubDate>Wed, 23 Oct 2024 15:47:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=41926246</link><dc:creator>lgessler</dc:creator><comments>https://news.ycombinator.com/item?id=41926246</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41926246</guid></item></channel></rss>