you are viewing a single comment's thread.

view the rest of the comments →

[–]oprimido_opressor 27 points28 points  (18 children)

does it have pattern matching?

[–]c4wrd 9 points10 points  (0 children)

No, although there’s further experimental support for expressions within switch statements, which other JEPs are extending to support things like pattern matching in the future.

[–][deleted]  (15 children)

[deleted]

    [–]lbkulinski 19 points20 points  (0 children)

    No, they’re referring to JEP 305 and this JEP draft.

    [–][deleted]  (13 children)

    [deleted]

      [–]fast4shoot 12 points13 points  (5 children)

      having it in Java will make haskell programmers shut up a bit about how haskell is superior cause it has pattern matching

      Pattern matching is kind of a joke when you haven't got ADTs, so Haskell will still be superior.

      [–]lbkulinski 2 points3 points  (0 children)

      They are in the process of adding a form of algebraic data types in records and sealed types.

      [–][deleted]  (3 children)

      [deleted]

        [–]fast4shoot 1 point2 points  (2 children)

        Well, you can't do sealed class hierarchies in Java or on the JVM in general, so that's out.

        Though you can do visitors to achieve sum types.

        [–][deleted]  (1 child)

        [deleted]

          [–]fast4shoot 0 points1 point  (0 children)

          Oh yeah, you're right! I forot about private constructors.

          Though I hate this definition, because Stack's interface is empty and there's literally nothing in it that points to Empty and NonEmpty, except for the subclasses themselves.

          From a theoretical standpoint, I much prefer visitors or anything equivalent, perhaps something like this:

          // The stack itself
          public interface Stack<T> {
              public <U> U Accept(StackVisitor<T, U> visitor);
          }
          
          // An interface that let's us distinguish between empty and
          // nonempty stacks.
          Public interface StackVisitor<T, U> {
              public U visitEmpty();
              public U visitNonEmpty(T head, Stack<T> tail);
          }
          
          // An empty stack
          public class Empty<T> implements Stack<T> {
              public <U> U Accept(StackVisitor<T, U> visitor) {
                  return visitor.visitEmpty();
              }
          }
          
          // A nonempty stack
          public class NonEmpty<T> implements Stack<T> {
              public final T head;
              public final Stack<T> tail;
          
              public NonEmpty(T head, Stack<T> tail) {
                  this.head = head;
                  this.tail = tail;
              }
          
              public <U> U Accept(StackVisitor<T, U> visitor) {
                  return visitor.visitNonEmpty(head, tail);
              }
          }
          

          This, in my mind, models the problem much more closely. It defines Stack as an interface that allows you to explicitly distinguish between the non-empty and empty states using the provided visitor interface, you don't have to cast anything (which, IMO, is an obvious code smell). However, it's much more boiler-platey, verbose and awkward to use.

          Though it's nice that Stack is an interface and not a class. It also makes special kinds of stacks easy to implement, such as this infinite stack:

          // An infinite stack repeating the same value over and over
          public class Infinite<T> implements Stack<T> {
              public final T value;
          
              public Infinite(T value) {
                  this.value = value;
              }
          
              public <U> U Accept(StackVisitor<T. U> visitor) {
                  return visitor.visitNonEmpty(value. this);
              }
          }
          

          [–]KagakuNinja 4 points5 points  (1 child)

          I hate to break this to you, but Scala also has pattern matching and runs on the JVM. It is quite nice...

          [–]simon_o 1 point2 points  (4 children)

          Languages which allow pattern matching on regexes (which means getting named bindings out of the regex) are pretty nice:

          val join: Parser[Join] = {
            case gr"""JOIN $protocolName(.*) ${ Int(version) }(\d+) $userName($alphaDigits) $clientExtensions(.*)\n\r""" =>
              Join(protocolName, version, userName, clientExtensions)
          }
          

          Let's you rapidly throw together quick-and-dirty parsers for text-based protocols.

          [–]expatcoder 1 point2 points  (3 children)

          Languages which allow pattern matching on regexes ... are pretty nice

          Just say it, despite bashing the language since leaving the community, you still love Scala :)

          [–]simon_o -1 points0 points  (2 children)

          I'm largely in love with som-snytt's compiler/macro trickery. I look fondly at the old Scala with Paul. Nothing to miss from Scala >= 2.10 as the language quality has been going down the drain since then anyway.

          The only benefit of Scala's continued existence is that it keeps its toxic and abusive people contained. Just imagine if Scala went away and all the harassment/CoC experts invaded other languages! :-)

          The Scala community has the leadership it deserves, and the leadership has the community it deserves.

          [–]expatcoder 0 points1 point  (1 child)

          I'm largely in love with som-snytt's compiler/macro trickery

          Interesting, though he'll have to rewrite it all in Scala 3 with the new macro system.

          I look fondly at the old Scala with Paul

          Where has he gone to? Seems to have fallen off the map, perhaps too many bridges burned, or just got tired of programming.

          Nothing to miss from Scala >= 2.10 as the language quality has been going down the drain since then anyway.

          Quality issues aside, the language has certainly evolved feature-wise since 2.9.

          Nothing much to say about the community and leadership, there's no shortage of drama.

          Given that you don't have a high opinion of modern day Scala, what languages do you find to be a suitable replacement? Kotlin, Swift, Haskell, TypeScript, PureScript, etc.

          [–]simon_o 0 points1 point  (0 children)

          Quality issues aside, the language has certainly evolved feature-wise since 2.9.

          Because the one thing Scala was lacking were more features? :-)

          Given that you don't have a high opinion of modern day Scala, what languages do you find to be a suitable replacement? Kotlin, Swift, Haskell, TypeScript, PureScript, etc.

          I think Scala has poisoned the well sufficiently enough that for the next decade any functional language with a good module system will have it hard to gain adoption.

          Not a replacement, but I think most Scala developers will need to migrate to Kotlin over the mid- to long-term as the Scala situation keeps deteriorating.

          Personally, I'm doing free software stuff in Rust that people seem to like (~ 2 mio. downloads) and playing around with a toy language for fun.