Add docs page on scala programming advice #233
Conversation
ailrst
force-pushed
the
docs-scala-advice
branch
from
bad4c28 to
ebcdf2e
Compare
ailrst
force-pushed
the
docs-scala-advice
branch
from
ebcdf2e to
7a0a282
Compare
| - Scala contains syntax to encourage procedural programming; if/else statements, for, while statements; | ||
| the fact this is implemented through complex syntax sugar on top of functional constructs makes them surprising to both procedural and functional programmers, | ||
| and best avoided. |
There was a problem hiding this comment.
I am a bit confused by this - is this suggesting that if/else statements and for and while loops should all be avoided? I don't think that would be useful advice at all.
There was a problem hiding this comment.
The point generally is that using procedural constructs gets you the X/Y problem that makes one reach for nonsense like breakable, which isn't required if you're writing functional style code.
I don't think there's ever any reason to write a while loop in Scala they always become convoluted procedural fragments of code. Pattern matching is usually better than if/else but it does have its place. And generally I think map should be used instead of for, except for purely side-effecting operations which should be rare if you have immutable data, but they obviously mean the same thing in scala. Except that for is overloaded for do notation.
There was a problem hiding this comment.
The only thing that actually causes problems is breakable, which indeed should be avoided. That part was fine, which is why I didn't highlight it.
For loops being syntactic sugar for map doesn't actually cause problems and using for can sometimes be more readable than using map. There are plenty of cases where if statements are appropriate and pattern matching is not, so more useful advice may be 'pattern matching is recommended where possible' or something along those lines? There are of course plenty of places where we have mutable data as well - for better or worse the project is not written in anything remotely close to a purely functional style and moving away from that would be far more trouble than it's worth. While loops generally only make sense when involving mutable collections but we have those.
I'm mostly concerned that advising people who work on this project (who generally have little-to-no background in functional programming) to avoid these standard procedural programming constructs that they are familiar with will just cause them to write worse, more confused code that avoids them unnecessarily.
| enum Error(r: String): | ||
| case Permission extends Error("permission") | ||
| case NotExists extends Error("not existing") | ||
| export Error._ // adds Permission and Exists to the enclosing scope |
There was a problem hiding this comment.
this is Scala 2 syntax, Scala 3 is export Error.*
| - `case class`es are accessible like tuples, the below is valid code (never write this) | ||
| ```scala | ||
| case class X(a: Int, b: Int) | ||
| val x = X(1,2) | ||
| x._1 == x.a | ||
| ``` |
There was a problem hiding this comment.
I think this should have more emphasis as something NOT to do
No description provided.