Выбор архитектуры решения для маркетплейса услуг грузоперевозок

Хотелось бы подробнее узнать про данный проект, статья будто на полслове обрывается.

Поддержка аппаратно-специфичных инструкций в .NET Core (теперь не только SIMD)

Спасибо.
Интересная, полезная статья и, несмотря на замечания выше, приятный для чтения перевод.

Не морочьте мне голову со своим функциональным программированием

>Где там сказано что хаскелл компилятор генерит медленный код?
>что почему бы не написать хороший компилятор на Haskel, раз нынешний слабоват
ок, слабоват.
Но в статье к которой вы комментите

— Ужас, сколько тут циклов, сколько промежуточных структур данных… Это вообще не программирование! Вон из профессии!

Просто потому, что компилятор слабоват.

контекст в голове не удержали, бывает

теперь и разговора не получится

Не морочьте мне голову со своим функциональным программированием

Где там сказано что хаскелл компилятор генерит медленный код?
В контексте этого параграфа, там сначала претензия, «мы уже посчитали — а вы скомпилировать не можете» это не про скорость бинаря скомпилированного хаскеллем, это про скорость разработки. А дальше говорится про идеальный мир в котором компилятор должен строить хороший код независимо от того что написал программист. Тут указывается на проблему копилятора хаскеля что ему требуется хороший код, чтоб быть скомпилированным. В противовес тому, что хотелось бы чтоб любой говнокод(«мы уже написали, а вы еще пишете») компилировался в хорший код.
Чтоб читать Брагилевского нужно знать Брагилевского. Море двусмысленности и троллинга. Да, тонко что рвется, просто потому что вы не в контексте и это нормально, что вы не в контексте. ТК этот товарищ хоть и забавный и титульный, но все же немного маргинальный.
И я не защищаю хачкель, просто перевожу с брагилевского на русский.

Не морочьте мне голову со своим функциональным программированием

вв статье не сказано, что это компилятор хаскеля слабый, там указано иное:

Любой программист мейнстрим языка сразу начнет кричать:

— Ужас, сколько тут циклов, сколько промежуточных структур данных… Это вообще не программирование! Вон из профессии!

Просто потому, что компилятор слабоват.

Про хаскель здесь не сказано ничего, но указан некий «программист мейстримового языка» который из своего опыта с мейнстримовым языком, произносит фразу про кучу циклов. Далее следует заключение, что говорит он это потому что компилятор слабоват.

Даю справку: имеется ввиду, что у этого самого мейнстримового языка компилятор слабоват.

Твиттер Брагилевского(автор текста) — хороший инструмент для понимания того когда произошел троллинг.

Функциональное программирование: дурацкая игрушка, которая убивает производительность труда. Часть 1

в Ocaml HKT нет, но если кто скажет что это не фп язык, то даже не знаю какой он.

Система управления проектами по модели Open Core в госсекторе

И вам спасибо за полезное дополнение

Система управления проектами по модели Open Core в госсекторе

Спасибо за подробнейший ответ

Система управления проектами по модели Open Core в госсекторе

Спасибо за статью

Рынок программного обеспечения насыщен большим количеством готовых современных решений. Как говорится велосипед уже изобретен.

А какие еще решения на рынке, по вашему, достойны упоминания?
В идеале можно их как-то сравнить с вашим решением относительно pros cons?

Десять лет программирования на Erlang

Очень интересный пост и приятный перевод, спасибо большое.

Пример Model-View-Update архитектуры на F#

Спасибо за статью.
Очень интересно, что для ознакомления с оригинальным elmish для веба/xamarin/etc. Вы сделали elmish для консоли. Показывает насколько эта концепция гибка.
Так же интересующимся очень советую посмотреть на safe stack
https://safe-stack.github.io/docs/intro/

GitLab: с выходом версии 12.1 мы прекращаем поддержку MySQL

Он хотя бы есть

Fighting complexity in software development

This article is very incredible!
Thank you!
Can you specify some literature for the Interpreter pattern?

Боремся со слишком большими Msg в Elm приложениях

 Откопал статью с по Fable.Elmish многие вещи оттуда применимы и для Elm'a

Кто добавил Python в последнее обновление Windows?

Да-да, я видел это: дотнет, который в винде не собирается, а в Убунте с первого раза.

Ачивка. Буду внукам рассказывать.

Кто добавил Python в последнее обновление Windows?

Извините за ояепятки. С телефона плохо вижу.

Кто добавил Python в последнее обновление Windows?

Потом поставил mingw64 и сделал всё, что надо было, без разбирательств.

Тогда зачем это всем полтзователям по дефолту это ставить, если есть такой леший путь с mingw64?
Надо? Ставьте. В "общий" дистрибутив это пихать не нужно.

Боремся со слишком большими Msg в Elm приложениях

Есть подозрение, что не уловил правильно суть статьи, но обычно (в Fable-Elmish по крайней мере) происходит построение дерева компонентов.  

module NestedComponentOne =
  module Types = 
   type Model = { Counter : int }
   type Msg = | Increment | Decremenet 
  module State = 
    let init () = { Counter = 0 }, Cmd.empty
    let update mode = function  //same as let update model msg = match msg with 
    | Icrement -> { model with Counter = model.Counter + 1 }
    | Decrement -> { model with Counter = model.Counter - 1 }
  module View =
   let view model dispatch = 
    div [ ] [
      h1 [] [ str "Counter" ]
      str <| sprintf "Counter value is %s" model.Counter
      button [ OnCick = fun _ -> despatch Increment ] [ str "Increment" ]
      button [ OnCick = fun _ -> despatch Decrement ] [ str "Decrement" ]
    ]
module NestedComponentTwo =
  ... Same
module RootComponent = 
  module Types =
    type Model = { SomeFields : SomeTypes, NestedComponentOneState: NestedComponentOne.Types.Model, NestedComponentTwoState : NestedComponentOne.Types.Model }
    type Msg = 
     | SomeMsgs of SomeTypes
     | NestedComponentOneMsg of NestedComponentOne.Types.Msg
     | NestedComponentTwoMsg of NestedComponentTwo.Types.Msg
  module State = 
     let init() = 
        {SomeFields = someFieldsInit() 
          NestedComponentOneState = NestedComponentOne.State.init()
          NestedComponentTwoState = NestedComponentTwo.State.init() }
    let update model = function //same as let update model msg = match msg with 
    | SomeMsg someMsg -> ...
    | NestedComponentOneMsg msg -> NestedComponentOneMsg.State.update model.NestedComponentOneState msg
    | NestedComponentTwoMsg msg -> NestedComponentTwoMsg.State.update model.NestedComponentTwoState msg
  module View =
    let root model dispatch =
      div [] [
         div [] [ str "ComponentOne"; NestedComponentOne.View.view model.NestedComponentOneState (NestedComponentOneMsg >> dispatch) ]
         div [] [ str "ComponentTwo"; NestedComponentTwo.View.view model.NestedComponentTwoState (NestedComponentTwoMsg >> dispatch) ]
      ]

как-то ну в разных файлах. в разных изолированных модулях. Это основная мысль

Взгляд на Go глазами .NET-разработчика. Неделя #1

Чёт вы не дотнетчик а сишарпер.
В других дотнетнэйтив языках есть это и многое другое.

Боремся со слишком большими Msg в Elm приложениях

Почему это вообще должно быть в рамках одного компонента?
Почему это не один рутовый компонент который отображает два дочерних?