Good presentation, with one comment: When constructing an ADT that extends Exception, be sure to also tag it with NoStacktrace. Otherwise you get a stack trace that lies, since it's from instantiation code, which will be arbitrary and probably confusing/misleading.
Nice talk. It is nice to have these lists of best practices. I wasn't convinced by the description of the Exceptions based problem. Despite the claim by slide 42/79, I don't think the issue is that "Exceptions are like GOTO, and GOTO is bad". On the contrary, GOTO is good, just not in hand written code. Computer languages are also good for code generation, especially in the presence of meta programming, and GOTO is useful in meta programming such as compilers; can you imagine a compiler for example which didn't implement if/then/else as GOTO? The problem with Exceptions is that Scala implements Exceptions by just using the Java Exception implementation (for better or worse) and Java Exceptions unwind the stack. If they didn't, that problem would partially go away. If Exceptions didn't unwind the stack, but rather handling an Exception could optionally unwind the stack, wouldn't most of the problem go away? Another problem with Exceptions is that try/catch works on the dynamic extent, not lexical extend. This means that if a thow is sitting inside a lambda which is inside a try, then the lambda can escape from the try, and be called at a later time, not inside the try. Thus the catch may not catch the exception in lazy code.
Just to add, for implicit resolution discussed at 38:30, the situation has improved in Scala3 since you need to separately import givens(same as "implicit val") from packages. The chance for a name clash for the implicit reduces since you now know which implicits you are importing.
Exactly. Also the zoom-level should be increased considerably. Now majority of the slides is empty but the code snippets are unreadable mess in one corner.
The code presented is difficult to read, the author may have thought that because for him, the code was clear to read, the same will happen with the rest of the audience, unfortunatelly is quite different for the one that see a video of a talk.
Scala Practises I've learned: Scala allows you to write so concise code that you can use a readable zoom level in your presentations.
Good presentation, with one comment:
When constructing an ADT that extends Exception, be sure to also tag it with NoStacktrace. Otherwise you get a stack trace that lies, since it's from instantiation code, which will be arbitrary and probably confusing/misleading.
Qualifier: when using `object`, of course.
@akashic seer that's not really specific to Scala though.
14:40 "Yeah scala is a bit magic, let me get back to javascript" 😂😂
Nice talk. It is nice to have these lists of best practices. I wasn't convinced by the description of the Exceptions based problem. Despite the claim by slide 42/79, I don't think the issue is that "Exceptions are like GOTO, and GOTO is bad". On the contrary, GOTO is good, just not in hand written code. Computer languages are also good for code generation, especially in the presence of meta programming, and GOTO is useful in meta programming such as compilers; can you imagine a compiler for example which didn't implement if/then/else as GOTO? The problem with Exceptions is that Scala implements Exceptions by just using the Java Exception implementation (for better or worse) and Java Exceptions unwind the stack. If they didn't, that problem would partially go away. If Exceptions didn't unwind the stack, but rather handling an Exception could optionally unwind the stack, wouldn't most of the problem go away?
Another problem with Exceptions is that try/catch works on the dynamic extent, not lexical extend. This means that if a thow is sitting inside a lambda which is inside a try, then the lambda can escape from the try, and be called at a later time, not inside the try. Thus the catch may not catch the exception in lazy code.
Just to add, for implicit resolution discussed at 38:30, the situation has improved in Scala3 since you need to separately import givens(same as "implicit val") from packages. The chance for a name clash for the implicit reduces since you now know which implicits you are importing.
the idea of final case classes ar good, fnx
Why can't case classes be extended by other case classes with giving rhe same syntactic sugar? That would save a lot of time
Scala shall put a @deprecated("use java instead") on the scala.enumeration.
dark theme is fine, but not in presentation. readability near zero :(
Exactly. Also the zoom-level should be increased considerably. Now majority of the slides is empty but the code snippets are unreadable mess in one corner.
The code presented is difficult to read, the author may have thought that because for him, the code was clear to read, the same will happen with the rest of the audience, unfortunatelly is quite different for the one that see a video of a talk.
the best scala practise is to stop using it 😅