this post was submitted on 21 Aug 2025
47 points (91.2% liked)

Technology

74646 readers
2602 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] FishFace@lemmy.world 13 points 1 week ago (13 children)

I'm always suspicious of people who say that a language is suboptimal and use as evidence some filthy one-liner. Maybe if you bothered to write some whitespace and didn't write the language ignorant of its features (like generator expressions) you would end up with better code?

sum(
    all(
        abs(x) >= 1 and abs(x) <= 3 for x in line
    ) and (
        all(x > 0 for x in line) or
        all(x < 0 for x in line)
    )
    for line in diffs
)

You no longer have to "jump back and forth" except one single time - you have to look to the end to see where line is coming from and then you can read the body of the main expression from start to finish.

People don't, in fact, read code from top to bottom, left to right; they read it by first looking at its "skeleton" - functions, control flow, etc - until finding the bit they think is most important to read in detail. That implies that "jumping back and forth" is a natural and necessary part of reading (and hence writing) code, and so is nothing to fear.

There is still a slight advantage to not having to jump around, but consider the costs: in Javascript, map and filter are methods on Array and some other types. So how are you going to implement them for your custom iterable type? Do you have to do it yourself, or write lots of boilerplate? It's easy in Python. It's not bad in Rust either because of traits, but what this all means is that to get this, you need other, heavy, language features.

In practice, you often know what a comprehension is iterating over due to context. In those situations, having what the comprehension produces be the most prominent is actually a boon. In these scenarios in Rust/JS you are left skipping over the unimportant stuff to get to what you actually want to read.

[–] patatahooligan@lemmy.world 6 points 1 week ago (2 children)

I agree with you that the one liner isn't a good example, but I do prefer the "left to right" syntax shown in the article. My brain just really likes getting the information in this order: "Iterate over Collection, and for each object do Operation(object)".

The cost of writing member functions for each class is a valid concern. I'm really interested in the concept of uniform function call syntax for this reason, though I haven't played around with a language that has it to get a feeling of what its downsides might be.

[–] speq@lemmy.dbzer0.com 1 points 1 week ago

I think Nim is the frontrunner here. Close to Python to write because it is so expressive, close to C speed because it is compiled properly.

load more comments (1 replies)
load more comments (11 replies)