4 ms·

> My understanding is that Java added a lot of functional programming This is true, but needs more context. Java 8 added Stream API, which (at this time) was a

> My understanding is that Java added a lot of functional programming This is true, but needs more context. Java 8 added Stream API, which (at this time) was a fantastic breath of fresh air. However, the whole thing felt overengineered at many points, aka - it made complex things possible (collector chaining is admittedly cool, parallel streams are useful for quick-and-dirty data processing), but simple everyday things cumbersome. I cannot emphasize how tiring it was to have to write this useless bolierplate customers.stream().map(c -> c.getName()).collect(Collectors.joining(", ")) for 1000th time, knowing that customers.map(c -> c.getName()).join(", ") is what users need 99.99999% of the time.

bvrmn 11mo ago
It bothers me that majority of languages ignores a nice python approach. `', '.join(any_str_iterable)`. Instead of supporting join for myriads of containers there is a single str method.
- still_grokking 11mo ago
  Python's approach is one of the most confusing ways to possibly do it. Not having proper, discoverable methods is super annoying, and I need to look it up every time anew I use Python because it's so unintuitive. Of course you can write a generic version of `mkString` (as this method is called in Scala), so it's also just one method no matter the container count. The Python weirdness is actually a direct result from the language lacking generics…
  - bvrmn 11mo ago
    From typing perspective there is no sense to have Container[T].join() -> str for any T.
    - mystifyingpoi 11mo ago
      I agree, but from convenience perspective there is a lot of sense. Java Streams is actually a good example of a "correct" design, but not very convenient.
      - bvrmn 11mo ago
        That's my point. Python has convenient and good type design with str.join ignored by other languages. For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.
        still_grokking 11mo ago
        > Python has convenient and good type design with str.join ignored by other languages. Of course such non-discoverable and unintuitive design gets ignored everywhere! We just established that even in Python the correct way to do it would be Iterable[str].join(str) -> str but for that Python would need generic iterators on the language level… > For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container. So you're saying you've been able to implement custom Scala collection types, which is regarded some of the more difficult stuff one could possibly do, but you don't know how to implement an Iterator for your custom collection—as this is all needed for mkString to work? BTW, how did you implement the collection type at all without implementing Iterator for it? Your collection is not Iterable? TBH, this does not sound very realistic. This sounds more like typical HN Scala FUD. People throwing around some vague, most of the time outright made up issues they've heard about somewhere about 10 - 15 years ago.
    - still_grokking 11mo ago
      That's obviously the wrong signature. The semantically correct one is "Container[T : Printable].join(): String"; T must implement the Printable concept, but Python lacks concepts (or type-classes as these are alternatively called). But this all is irrelevant as this is anyway not the signature of `str.join()` in Python. It's `str.join(Iterable[str]) -> str` there. With sane design and syntax it would just become `Iterable[str].join(str)`.
still_grokking 11mo ago
It's such a blessing to be able to write in Scala customers.map(_.name).mkString(", ") instead of the Java bloat customers.stream().map(c -> c.getName()).collect(Collectors.joining(", "))

bvrmn 11mo ago

It bothers me that majority of languages ignores a nice python approach. `', '.join(any_str_iterable)`. Instead of supporting join for myriads of containers there is a single str method.

still_grokking 11mo ago
Python's approach is one of the most confusing ways to possibly do it. Not having proper, discoverable methods is super annoying, and I need to look it up every time anew I use Python because it's so unintuitive. Of course you can write a generic version of `mkString` (as this method is called in Scala), so it's also just one method no matter the container count. The Python weirdness is actually a direct result from the language lacking generics…
- bvrmn 11mo ago
  From typing perspective there is no sense to have Container[T].join() -> str for any T.
  - mystifyingpoi 11mo ago
    I agree, but from convenience perspective there is a lot of sense. Java Streams is actually a good example of a "correct" design, but not very convenient.
    - bvrmn 11mo ago
      That's my point. Python has convenient and good type design with str.join ignored by other languages. For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.
      - still_grokking 11mo ago
        > Python has convenient and good type design with str.join ignored by other languages. Of course such non-discoverable and unintuitive design gets ignored everywhere! We just established that even in Python the correct way to do it would be Iterable[str].join(str) -> str but for that Python would need generic iterators on the language level… > For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container. So you're saying you've been able to implement custom Scala collection types, which is regarded some of the more difficult stuff one could possibly do, but you don't know how to implement an Iterator for your custom collection—as this is all needed for mkString to work? BTW, how did you implement the collection type at all without implementing Iterator for it? Your collection is not Iterable? TBH, this does not sound very realistic. This sounds more like typical HN Scala FUD. People throwing around some vague, most of the time outright made up issues they've heard about somewhere about 10 - 15 years ago.
  - still_grokking 11mo ago
    That's obviously the wrong signature. The semantically correct one is "Container[T : Printable].join(): String"; T must implement the Printable concept, but Python lacks concepts (or type-classes as these are alternatively called). But this all is irrelevant as this is anyway not the signature of `str.join()` in Python. It's `str.join(Iterable[str]) -> str` there. With sane design and syntax it would just become `Iterable[str].join(str)`.

still_grokking 11mo ago

It's such a blessing to be able to write in Scala customers.map(_.name).mkString(", ") instead of the Java bloat customers.stream().map(c -> c.getName()).collect(Collectors.joining(", "))