• Total Haskell code base: >2M lines, >150 contributors (~20 core), >110k commits.
• Haskell code everywhere: real time pricing, risk management, data analysis, regulatory systems, desktop and web GUIs, web services, algo pricing, end-user scripting, and as plugins to C++, Java, C#, Excel.
• Windows, Linux, clusters and grids. On servers and desktops in >30 countries.

GUIs: Generate native Windows WPF GUI or JavaScript app from single Haskell impl.
Bindings: Tons of bindings to external services. Haskell as API glue.

In-house Haskell compiler: `Mu’. One of Lennart’s many Haskell compilers.
• Whole world optimizing compiler.
• Compiles to portable bytecode – same blob runs on Linux or Windows.
• Values, closures, functions can be serialized.

And, even if the language has the tools, developers need taste and guidance to use them

Often working from verbal, ad hoc evolving spec. And at best from informal functional specs.
 Spec often refined/derived based on the Haskell implementation.
o “No plan survives contact with implementation”

Writing lots of apps; services; libraries in Haskell.

Heavy use of process isolation. Baby Erlang in Haskell.

Old code doesn’t fall apart – large, (very) strongly typed code bases don’t rot.

Use the machine to... Document the design for later developers

Often working from verbal, ad hoc evolving spec. Spec often refined/derived based on the Haskell implementation.

Make wrong code impossible to write

Strong, expressive types give us machine-checkable, modular software
• APIs become self-describing

Any dev can build systems without worrying about implementation internals.
 Just fit types together

You can write Java in any language

M>Ну, то есть если нет насаждающих это диктаторов, все будет очень, очень плохо (ну, как в Кларне ).

M>>А потом дебажить типы, когда логика закодирована неправильно

Order flow:

1. Создали заказ

2. Опционально обновили заказ (добавили или убрали item'ы)

3. Если заказ expired, можно продлить expiry date

4. Пометили заказ, как отправленный [или]
   пометили лишь некоторые из item'ов в заказе, как отправленные

Как сейчас:

1. Если оплата карточкой, мы сразу делаем authorize and capture (резервация денег и снятие со счета)

Как будет:

1. В зависимости от конфигурации магазина мы делаем или authorize and capture или только authorize
2. Если сделан только authorize, мы позволяем повышать сумму заказа даже для товаров, оплаченныз карточкой (зависит от конфигурации магазина)
3. Если заказ expired, мы должны отменить authorization в банке. Если продливается expiry date, мы должны заново сделать auth в банке
4. Если заказ помечен, как отправелнный, и в заказе сделан только auth, то мы должны в этот момент сделать capture

Как именно мне тут помогут типы, если я забуду сделать четвертый пункт?

if is_activated(Order) and is_auth_only(Order):
  do_capture(Order)

def flush(moment: Long) = ???
def analyze(moment: Long) = ???

sealed trait Day
sealed trait Epoch
type EpochTime = Long @@ Epoch
type DayTime   = Long @@ Day

def flush(moment: EpochTime) = ???
def analyze(moment: DayTime) = ???

// наш пользовательский классик, который мы хотим билдить
case class Foo(x: Int, y: String, z: Char)

// HasBuilder[_] из библиотеки shapeless-builder
object Foo extends HasBuilder[Foo] {
  // вспомогательные штука из библиотеки shapeless
  val isoContainer = createIsoContainer(apply _, unapply _)
  val fieldsContainer = createFieldsContainer(X :: Y :: Z :: HNil)

  // параметр x обязательный
  object X extends Param[Int]

  // параметр Y опциональный с дефолтом "5"
  object Y extends OptParam[String]("5")

  // параметр Z опциональный с дефолтом '!'
  object Z extends OptParam[Char]('!')
}

import Foo._
val test = Foo.builder.set(X, 42).set(Z, '+').build()
// здесь test == Foo(42,"5",'+')
// если не сделаем set(X, ...) получим ошибку компиляции

case class CommentRow(id: Option[CommentId], // Option в Slick показывает, что он автоинкрементный
                      text: String,
                      authorId: UserId,
                      date: DateTime)

case class UserRow(id: Option[UserId],
                   email: String,
                   firstName: String,
                   lastName: String)
// И потом в Дао очевидно будет ошибка компиляции, если это будет не UserId
usersDao.findById(userId)

Often working from verbal, ad hoc evolving spec. And at best from informal functional specs.

- Есть заказ.
- Пока заказ не помечен, как отправленный, можно уменьшать и увеличивать сумму заказа
- Величина, на которую можно увеличить сумму заказа, зависит от:
  - Страны, в которой сделан заказ по конфигурируемому умолчанию
    - для Германии:
      - уменьшить можно на max(10% от оригинальной суммы заказа, 10 евро)
      - увеличить можно на max(10% от оригинальной суммы заказа, 10 евро)
  - Магазина, в котором сделан заказ
    - если конфигурации для магазина нет, берутся умолчания для страны магазина
  - если заказ помечен, как pre-paid, увеличивать сумму нельзя, уменьшать можно
    - уже есть тикет, который позволяет увеличивать сумму заказа для pre-paid
      заказов в зависимости от конфигурации магазина

- Есть заказ.
- Пока заказ не помечен, как отправленный, можно уменьшать и увеличивать сумму заказа
- Величина, на которую можно увеличить сумму заказа, зависит от:
  - Страны, в которой сделан заказ по конфигурируемому умолчанию
    - для Германии:
      - уменьшить можно на max(10% от оригинальной суммы заказа, 10 евро)
      - увеличить можно на max(10% от оригинальной суммы заказа, 10 евро)
  - Магазина, в котором сделан заказ
    - если конфигурации для магазина нет, берутся умолчания для страны магазина
  - если заказ помечен, как pre-paid, увеличивать сумму нельзя, уменьшать можно
    - уже есть тикет, который позволяет увеличивать сумму заказа для pre-paid заказов в зависимости от конфигурации магазина
M>

  type Order is
    ID: Integer;
    Sum: Money;
    Sent: Boolean;
  end;

  type SentOrder is Order where Sent = true;
  type UnsentOrder is Order where Sent = false;

  function SendOrder(order: UnsentOrder): SentOrder is
    ...
  end;

  function ChangeOrderSum(order: UnsentOrder, newSum: Money): UnsentOrder is    // эту функцию нельзя вызвать для заказа, у которого Sent равно true!
    ...
  end;

  function PrintOrderDetails(order: SentOrder) is
    ...
  end;

  var order := CreateOrder(1, 12000.00);
  order := ChangeOrderSum(order, 2800.23);
  order := SendOrder(order);
//  order := ChangeOrderSum(order, 5555.00);    // error
  PrintOrderDetails(order);    // OK

update_order(Order, Amount) ->
  Estore         = order_api:get_estore(Order),
  Country        = estore_api:get_country(Estore),
  OriginalAmount = order_api:get_original_amount(Order),
  AmountDiff     = OriginalAmount - Amount,

  case AmountDiff > 0 andalso order_api:is_prepaid(Order) of
    true -> {error, amount};
    false -> 
        %% config сам определяет, что брать — конфиг магазина или страны,
        %% если 
        MaxIncreasePct = config:get_max_config_increase_pct(Estore),
        MaxIncrease    = config:get_max_config_increase(Estore),
        MaxDecreasePct = config:get_max_config_decrease_pct(Estore),
        MaxDecrease    = config:get_max_config_decrease(Estore),

        case (AmountDiff < 0 andalso abs(AmountDiff) > max(....)).... of
           true -> {error, amount};
           false -> 
             UpdatedOrder = order_api:set_amount(Order, Amount),
             order_ops:write(UpdatedOrder)
        end
  end.

ARK>  type SentOrder is Order where Sent = true;
ARK>  type UnsentOrder is Order where Sent = false;

ARK>  function ChangeOrderSum(order: UnsentOrder, newSum: Money): UnsentOrder is    // эту функцию нельзя вызвать для заказа, у которого Sent равно true!
ARK>    ...
ARK>  end;

ARK>  var order := CreateOrder(1, 12000.00);
ARK>  order := ChangeOrderSum(order, 2800.23);
ARK>  order := SendOrder(order);
ARK>//  order := ChangeOrderSum(order, 5555.00);    // error
ARK>  PrintOrderDetails(order);    // OK

ARK>

Order = read_order_from_db(OrderId),
change_order_amount(Order, Amount).

M>>>Order = read_order_from_db(OrderId),
M>>>checnge_order_amount(Order, Amount).
M>>>

ARK>>Внезапно в этом месте будет ошибка компиляции — ибо checnge_order_amount хочет не тот тип, который выдает read_order_from_db. Какая печаль.

  Order = read_order_from_db(OrderId);
  if (Order.Sent = true)
    change_order_amount(Order, Amount);

M>Ерунду написал

M>>>Я об этом (среди прочего) и говорю уже пятнадцать сообщения подряд Нет, «магический тайпчекер все проверит»

M>>>Order = read_order_from_db(OrderId),
M>>>checnge_order_amount(Order, Amount).
M>>>

Order[New] order = read_order_from_db(OrderId)
Order[Processed] processedOrder= order.processSomehow()

при этом имея метод: 
void checnge_order_amount(Order[Processed] order, Amount amount) 

ну и: 
checnge_order_amount(order, Amount) << ошибка
checnge_order_amount(processedOrder, Amount) << ок

M>>13 января заказ уже имеет статус «обработан и отослан». Нет никакого read -> process -> change_amount. Есть read -> change_amount.

G>Я тебе идею иллюстрирую, а ты к конкретной строчке докопался .

Order = read_order_from_db(OrderId),
update_order_amount(Order, Amount)

M>Я понимаю, что идея. Только уже сколько раз эти идеи мало соотносятся с реальностью И твой пример, и первый пример AlexRK строго зависит от того, чтобы все изменения шли друг за другом, чтобы компилятор видел, что происходит в каждой точке с этим объектом

M>Order = read_order_from_db(OrderId),
M>update_order_amount(Order, Amount)
M>

public Order[*] read_order_from_db(OrderId id); // читаем уже правильный ордер, либо Order[New] либо Order[Processed]

G>public Order[*] read_order_from_db(OrderId id); // читаем уже правильный ордер, либо Order[New] либо Order[Processed]
G>

public Order[*] read_order_from_db(OrderId id);

// каким образом тут компилятор проверит, что за Order сюда идет?
// заказ же из базы читается
change_order_amount(Order, Amount)

M>- Есть заказ.
M>- Пока заказ не помечен, как отправленный, можно уменьшать и увеличивать сумму заказа
  ...
M>  - если заказ помечен, как pre-paid, увеличивать сумму нельзя, уменьшать можно
M>

data NewOrder -- основные качественные состояния заказа
data PrepaidOrder 
data SentOrder

type Money = Int -- для простоты тут такие заглушки, реально Money описывает неотрицательные суммы в нужной валюте
type OrderInfo = [String] 

data Order state = Ordr Money OrderInfo -- тип заказа параметризован состоянием

class CanChangeAmount a  -- в каких состояниях можно менять сумму
instance CanChangeAmount NewOrder
instance CanChangeAmount PrepaidOrder

--уменьшить сумму. работает лишь для нужных состояний, сохраняет состояние
decreaseAmount :: (CanChangeAmount state) => Order state -> Money -> Order state
decreaseAmount (Ordr amt info) delta = Ordr (amt - delta) info

--увеличить сумму. работает лишь для того состояния, где это разрешено
increaseAmount :: Order NewOrder -> Money -> Order NewOrder
increaseAmount (Ordr amt info) delta = Ordr (amt + delta) info

M>По ссылке не вижу ничего подобного. Более того, я вижу там банальное if typeof(Object) == что-то там Только присыпанное синтаксическим сахаром

void printIfPrintable(Object obj) {
    if (is Printable obj) {
        obj.printObject();
    }
}

void Func1(MyObj obj)
{
  if (obj.Prop == 3 && ....  // тут много проверок
    Use(obj);
}

void Func2(MyObj obj)
{
  if (obj.Prop == 3 && obj.Prop2 == 4 && ....  // тут те же проверки, и еще пара других
    Use(obj);
}

MyObj obj = GetMyObj();
Func1(obj);
Func2(obj);


// предлагаемый вариант (псевдокод)

type MyCoolObj = MyObj where obj.Prop == 3 && ...   // тут все проверки

void Func1(MyCoolObj obj)
{
  Use(obj);  // проверок нет
}

void Func2(MyCoolObj obj)
{
  if (obj.Prop2 == 4 && ....  // тут только пара "лишних" проверок
    Use(obj);
}

MyObj obj = GetMyObj();
if (obj is MyCoolObj)    // все проверки в типе, тут ничего нет
{
  Func1(obj);
  Func2(obj);
}

В этих обстоятельствах одна и та же ошибка может быть проверена и с помощью утверждения, и обработчиком ошибок. Так, в исходном коде Microsoft Word условия, которые должны быть истинными, сперва помещаются в утверждения, а затем и в коде обработки ошибок рассматривается ситуация, когда утверждение ложно. В столь сложных и долгоживущих приложениях, как Word, утверждения служат для выявления как можно большего числа ошибок периода разработки. Но поскольку приложение очень сложное (миллионы строк кода) и прошло через столько изменений, неразумно ожидать обнаружения и исправления всех мыслимых ошибок до начала поставки приложения пользователям. Поэтому ошибки должны обрабатываться и в промышленной версии системы.

M>Которая на практике выстреливает раз в год Не говоря уже о том, что всю эту логику, навороченную в типе еще тоже надо проверить каким-то образом.

M>Тогда нафига козе баян? Ну и как это? Меня тут активно пытались убедить, что все прекрасно, и чуть ли ен все можно в типы запихнуть