this post was submitted on 18 Mar 2025
4 points (75.0% liked)
Programming Languages
1280 readers
1 users here now
Hello!
This is the current Lemmy equivalent of https://www.reddit.com/r/ProgrammingLanguages/.
The content and rules are the same here as they are over there. Taken directly from the /r/ProgrammingLanguages overview:
This community is dedicated to the theory, design and implementation of programming languages.
Be nice to each other. Flame wars and rants are not welcomed. Please also put some effort into your post.
This isn't the right place to ask questions such as "What language should I use for X", "what language should I learn", and "what's your favorite language". Such questions should be posted in /c/learn_programming or /c/programming.
This is the right place for posts like the following:
- "Check out this new language I've been working on!"
- "Here's a blog post on how I implemented static type checking into this compiler"
- "I want to write a compiler, where do I start?"
- "How does the Java compiler work? How does it handle forward declarations/imports/targeting multiple platforms/?"
- "How should I test my compiler? How are other compilers and interpreters like gcc, Java, and python tested?"
- "What are the pros/cons of ?"
- "Compare and contrast vs. "
- "Confused about the semantics of this language"
- "Proceedings from PLDI / OOPSLA / ICFP / "
See /r/ProgrammingLanguages for specific examples
Related online communities
- ProgLangDesign.net
- /r/ProgrammingLanguages Discord
- Lamdda the Ultimate
- Language Design Stack Exchange
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think that they don't talk to enough language designers. Errors-as-values is the correct model because it eventually leads to the understanding that errors are our opinions about the state of the machine rather than an actual failure of the machine's invariants, and the permanent divide between recoverable-yet-undesirable "error" states and genuine faults in the hardware. All other error models persist due to inertia and machismo.
This doesn't mean that exceptions have to be removed from languages, but rather that we should think of them as continuation-passing or stack-controlling operations which perform non-local jumps; they're part of the structured-control-flow toolbox along with break/return/continue jumps. Going in the other direction, a language designer need not add exceptions if they intend to add call/cc instead.
Yeah, but Sturgeon's Law never stops; most new programming languages are fundamentally not interesting because they are either garbage-collected Algol-descended languages or memory-unsafe. Meanwhile, sum types can always be added to simply-typed lambda calculi without invalidating any safety properties. If you argue in favor of mediocrity, you're gonna get Golang instead of something good.