BatmanAoD

I've never seen that, and I've been using Windows professionally and personally for...ever.

I don't necessarily love Python either, but it sounds like your perspective is a little limited.

Why would anyone change so many standards?

You happen to have almost exclusively used languages that are syntactically descended from a common ancestor, Algol. If you had learned a LISP descendant, or another non-Algol language such as ML, Prolog, APL, or Haskell, you'd probably be less surprised by Python not following the Algol-ish syntax.

Why would you provide a way to type parameters but don't enforce it at runtime?

As another commenter mentioned, this is basically just a result of Python's historical development. Explicit types are fully optional, and originally did not exist: the type annotations idea wasn't even created until 2014, over two decades (!!) after Python's initial release; and that was just the initial theoretical groundwork, not an implementation of anything. To introduce explicit static typing into a language that is dynamically or implicitly typed, without breaking legacy code, requires gradual typing, an idea that is relatively recent in the history of programming languages, and there are different approaches. The TypeScript approach may seem like the obvious "right" way now that TypeScript has become so dominant in the JS ecosystem, but it was in no way obvious that TypeScript would be so successful back when it was introduced, which was right around when Python started developing its gradually-typed system. So Python took a different approach: rather than designing a new language as a superset of the existing language, and writing a compiler to typecheck the new language and strip type annotations, they added a syntax for type annotations into the language, so that the code you write is still the code that actually gets interpreted, but decided that actually enforcing type-checking should be left to separate tools rather than the Python interpreter. Personally, with the benefit of hindsight, and as someone who has not used Python much and prefers Rust-style static typing, I think the TypeScript way is better. But I don't think Python is likely to evolve in that direction.

Giving a specific time range and making this prediction in earnest is well worth receiving some credit if it pans out.

Oof, yeah, those count. The fact that CMake was best-in-class when I wrote C++ professionally was...awful.

I have managed to mostly avoid needing to code in either language, but my strong inclination is to agree that they are indeed hacks.

There's a proliferation of dynamically and/or softly typed languages. There are very few, if any, truly untyped languages. (POSIX shells come close, though internally they have at least two types, strings and string-arrays, even if the array type isn't directly usable without non-POSIX features.)

Yes. Types are good. Numeric operations have specific hardware behavior that depends on whether you're using floating-point or not. Having exclusively floating-point semantics is wildly wrong for a programming language.

I think you're misunderstanding that paragraph. It's specifically explaining how LLMs are not like humans, and one way is that you can't "nurture growth" in them the way you can for a human. That's not analogous to refining your nvim config and habits.

That's just not terribly meaningful, though. Was JavaScript the "best tool" for client-side logic from the death of Flash until the advent of TypeScript? No, it was the only tool.

Even in the original comic, that would have been appropriate, I think.

At one point the user linked to a rust-lang forum thread from 2016-2019 as evidence that Jai has "some of the tools to make the code language agnostic" or something like that. The thread started with a discussion of array-of-struct vs struct-of-array data layouts, which of course has nothing to do with making code "language agnostic." The user also mentioned the coding influencer lunduke multiple times. So I think they are simply misinformed on a lot of points, and I doubt they're in the closed beta for Jai.

(I read some of the comments simply because I had the same question you did. And, as it happens, the last post in the forum thread I mentioned was written by me, which was a funny surprise.)

Exactly: that's tight feedback loops. Agents are also capable of reading docs and source code prior to generating new function calls, so they benefit from both of the solutions that I said people benefit from.

As an even more obvious example: students who put wrong answers on tests are "hallucinating" by the definition we apply to LLMs.

making the same mistakes

This is key, and I feel like a lot of people arguing about "hallucinations" don't recognize it. Human memory is extremely fallible; we "hallucinate" wrong information all the time. If you've ever forgotten the name of a method, or whether that method even exists in the API you're using, and started typing it out to see if your autocompleter recognizes it, you've just "hallucinated" in the same way an LLM would. The solution isn't to require programmers to have perfect memory, but to have easily-searchable reference information (e.g. the ability to actually read or search through a class's method signatures) and tight feedback loops (e.g. the autocompleter and other LSP/IDE features).

This seems like it doesn't really answer OP's question, which is specifically about the practical uses or misuses of LLMs, not about whether the "I" in "AI" is really "intelligent" or not.

One list, two list, red list, blue list

(I genuinely thought that was where you were going with that for a line or two)

Agile Meridian / Post Manager

Thanks for sharing this! I really think that when people see LLM failures and say that such failures demonstrate how fundamentally different LLMs are from human cognition, they tend to overlook how humans actually do exhibit remarkably similar failures modes. Obviously dementia isn't really analogous to generating text while lacking the ability to "see" a rendering based on that text. But it's still pretty interesting that whatever feedback loops did get corrupted in these patients led to such a variety of failure modes.

As an example of what I'm talking about, I appreciated and generally agreed with this recent Octomind post, but I disagree with the list of problems that "wouldn’t trip up a human dev"; these are all things I've seen real humans do, or could imagine a human doing.

Well now you've seen it elsewhere, too.

distributing relay knowledge among chatters (TBD)

This is the core reason that centralization is currently necessary. So admitting that it's an unsolved problem for a federated alternative is basically reinforcing Signal's point.

BatmanAoD

@ BatmanAoD @programming.dev

Posts

2
Comments

242
Joined

2 yr. ago

BatmanAoD

I love it

I'm struggling with Python, as someone who started with C, Java, PHP and JS

🪟 Prediction: Microsoft Is Going To Do The Funniest Thing Imaginable

TIL: Why ARM Has a JavaScript Instruction

TIL: Why ARM Has a JavaScript Instruction

TIL: Why ARM Has a JavaScript Instruction

TIL: Why ARM Has a JavaScript Instruction

LLMS Are Not Fun

You can pry pattern matching from my cold dead hands

Rust bad Jai good

Rust bad Jai good

Permanently Deleted

Permanently Deleted

Permanently Deleted

Permanently Deleted

Linux 6.19 Gets Rid Of The Kernel's "Genocide" Function

Clock but the PM quit and was replaced halfway through the project. Handover instructions: "Make the clock hands show the current time"

Do you like (AI) clocks?

Well, hello waterfox and librewolf

Delta chat criticism against Signal

Small Data (a new KRAZAM video)

Who's working on a "smaller Rust"?