BatmanAoD

joined 2 years ago
[โ€“] BatmanAoD@programming.dev 2 points 1 day ago (1 children)

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.

[โ€“] BatmanAoD@programming.dev 2 points 1 week ago (3 children)

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.)

[โ€“] BatmanAoD@programming.dev 17 points 1 week ago (7 children)

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.

[โ€“] BatmanAoD@programming.dev 11 points 4 weeks ago

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.

[โ€“] BatmanAoD@programming.dev 13 points 1 month ago (4 children)

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.

30
submitted 2 years ago* (last edited 2 years ago) by BatmanAoD@programming.dev to c/rust@programming.dev
 

Almost five years ago, Saoirse "boats" wrote "Notes on a smaller Rust", and a year after that, revisited the idea.

The basic idea is a language that is highly inspired by Rust but doesn't have the strict constraint of being a "systems" language in the vein of C and C++; in particular, it can have a nontrivial (or "thick") runtime and doesn't need to limit itself to "zero-cost" abstractions.

What languages are being designed that fit this description? I've seen a few scripting languages written in Rust on GitHub, but none of them have been very active. I also recently learned about Hylo, which does have some ideas that I think are promising, but it seems too syntactically alien to really be a "smaller Rust."

Edit to add: I think Graydon Hoare's post about language design choices he would have preferred for Rust also sheds some light on the kind of things a hypothetical "Rust-like but not Rust" language could do differently: https://graydon2.dreamwidth.org/307291.html

view more: next โ€บ