Вот есть функция f(a:A):B

Ну так как она хз когда вернет что-то, то давайте сделаем из нее cps, как в джаваскрипте шоб. f(a:A, accept: B => Unit): Unit.

Ну а что там много параметров, давайте-ка ее каррируем: f(a:A)(accept:B => Unit): Unit - так же можно ее вызвать наполовину, и получить что-то, что берет акцептора ("обработчика"), и применяет его к результату:

f(a:A): (B => Unit) => Unit

Ну так можно же дать название тому, что мы тут делаем, типу результата f:

f(a:A): Future[B]

Вот вам и фьючерсы.

Just found in my code:

    OKif (!badStuff.find()) orCommentTheError "Bad code"

"There is nothing that can possibly be done in this case. The laws of parametricity say that the signature:

def foo[T]: T

can never be satisfied for all T unless you do something dodgy like throw an exception, or not return at all – ie. something that actually is of type Nothing."

http://steve-yegge.blogspot.com/2007/02/next-big-language.html

I guess Scala won. Or something.

scala> def f[T](x:T,y:T=>String) = y(x)
f: [T](x: T, y: T => String)String

scala> f("text", s=>s+s)
:9: error: missing parameter type
              f("гав", s=>s+s)
                        ^

scala> def f[T](x:T)(y:T=>String) = y(x)
f: [T](x: T)(y: T => String)String

scala> f("гав")(s=>s+s)
res1: String = гавгав

src: http://www.slideshare.net/AlexanderPodkhalyuzin/under-the-hood-of-scala-implicits-scala-exchange-2014?utm_source=slideshow&utm_medium=ssemail&utm_campaign=upload_digest

Короче, для менеджмента:
если у функции только один параметр, то скала бодро определит ее тип, а если больше, то бывают проблемы ("у нас тут не хиндли и не милнер).

Для CEO: все должны срочно всê каррировать, это теперь паттерн такой.

I had a function that was returning a Set[User]; and it was bad, since on error it was returning an empty set, swallowing the error. Bad. So I changed it into something returning Result[Set[User]], which can even show you the stacktrace if needed.

Now the usecase was like this:

  for {
    something <- ...
    somethingElse <- ...
    users = giveMeUsers(something)
    ...
  } yield results

To refactor, I just had to replace '=' with '<-'.

  for {
    something <- ...
    somethingElse <- ...
    users <- giveMeUsers(something)
    ...
  } yield results

1. Scala is a mixed object-oriented and functional language. You are free to mix these two features as long as you can explain how it works.
2. Ideally, your code should take care of all possible outcomes. Imagine, it throws an IndexOutOfBounds exception, and somewhere up the food chain some kind of client has to figure out who was it that went outside the range of its data, and why, and what can be done about it, except writing something to the log, so that admins send an email to a manager, and the managers bugs the developer, a day or two later. And you will be scratching your head: who was that bad guy that gave you an empty array when you so desperately needed the array's first element. Since you already know this can happen, you can add the code that takes care of this.
3. Do not:
- use nulls (ask me if you don't know how);
- use vars (ask me if you don't know how);
- introduce setters and getters;
- use mutables (ask me if you don't know how);
- throw exceptions (ask me if you don't know how);
- write methods more than 50 lines long (ideally, more than 14 lines long);
- think this is java;
- hesitate to use more space characters than compiler wants you to;
- except in rare occasions, use indexes of lists, even writing list(0) is bad;
- except for very technical reasons, use length

4. The following are pairs of distinct entities:
- sets and lists;
- order and sequence;
- maps and lists of pairs
5. The code you write will be read by compiler and by your colleague.
5.1. To make compiler's life easy, you can specify the types of your values and functions; it's a known fact that scalac runs faster when types are specified.
5.2. The same applies to your colleagues: if the type of a value is explicitly written (and not obvious otherwise), they'll feel more comfortable;
5.3. Introduce intermediate variables with good names: your compiler may need them, your colleague too.
5.4. Make methods do just one thing.
5.5. There are two kinds of zero-parameter methods: those that just return something with no side effect, and those that mostly just have a side effect, e.g. myInvestment.currentValue vs myInvestment.rebalance().
6. A function that returns a function is okay, it's called currying, and it may also save your cycles (as if anybody cares these days).
7. Your code is a piece of graphic art, although it's just an ASCII art; the more space characters, the more readable it is.
8. The line length... it's up to you, but remember, others are trying to read your masterpiece.
9. Nobody reads documentation or comments these days. So a self-explanatory code makes a lot of sense.
10. Within a project, it may make sense to use the established naming conveniences, coding style and libraries... on the other hand, if we did that, we would be still coding in machine codes and sitting around fire in the caves.
11. Learn local libraries.
12. If you don't know how to write unittests in Scala, drop everything and learn it first. Hardly any of your code makes any sense (even if you believe it does) if there are no tests that prove it (to others; we know you trust yourself). Test frameworks used may vary from project to project; it's a stupid idea to have two frameworks in one project.
13. DRY. Abstraction is your friend.
14. The only true law is that which leads to freedom.


=============
Suggestions?