ООП: худшее, что случалось с программированием

а меня и от кока чё-т тошнит

Почему? Там же теоремки сильно проще чем в агде получаются

ООП: худшее, что случалось с программированием

А приведите там код, как вы в рантайме, в зависимости от пользовательского ввода решаете делать ли просто Encoder или заворавичвать его в DumpingEncoder? Как вы потом его вызываете?

-- Поправил типы, чтобы их можно было сконструировать и выводить на экран
data Bitstream = Bitstream deriving Show
data VideoFrame = VideoFrame Int deriving Show

data Vp9SWEncoder = Vp9SWEncoder deriving Show
data Vp9HWEncoder = Vp9HWEncoder deriving Show

-- Поправил инсансы, чтобы не выбрасывали ошибки
instance Encoder Vp9SWEncoder where
  encode _ = return Nothing

instance Encoder Vp9HWEncoder where
  encode _ = return Nothing

-- Полиморфный код
do_something_with_encoder :: Encoder a => State a ()
do_something_with_encoder = do
  encode $ VideoFrame 0
  encode $ VideoFrame 1
  encode $ VideoFrame 2

  return ()

-- Функция вызывающая полиморфный код
main :: IO ()
main = do
  user_input <- getLine
  if user_input == "wrap" 
    then do
      let encoder = DumpingEncoder Vp9SWEncoder []
      let (DumpingEncoder _ dump) = execState do_something_with_encoder encoder 

      print $ reverse dump 
    else do
      let _ = execState do_something_with_encoder Vp9SWEncoder 
      putStrLn "No dump"

  return ()

Потом, у вас тут не ООП разве? Классы есть, экземпляры какие-то есть, данные, насколько я понимаю, лежат рядом с функциями где-то.

Это классы типов. Из мейнстрима больше всего похожи на trait-ы в rust, но нет, это не ООП.

Где лежит is_fallback, ведь он же меняется?

Строчка

  _is_fallback :: Bool

Внутри SoftwareFallbackEncoder

Функции нифига не чистые, или я что-то напутал?

Или это какой-то стейт неявно передаваемый функции, точно так же как методам класса неявно передается инстанс объекта

Во-первых мутабельность не всегда противоречит чистоте (см. монаду ST). Во-вторых, тут мутабельности действительно нет. State конструирует сложную, но всё же функцию без мутабельности.
Вы, судя по всему, на C++ пишете. Там это аналогично тому, чтобы вместо

  x = 10;
  rest

Писать

  [](int x) { rest } (10)

В чем тогда вообще разница с ООП?

Все эффекты (в данном случае доступ к состоянию) явно выражены в типах

ООП: худшее, что случалось с программированием

Есть куча разных кодеков. Т.е. вам надо в вашей функции в зависимости от кодека вызывать разные функции, которым нужен какой-то совершенно уникальный стейт, т.е. ваш стейт уже дикая структура, в которой описаны ВСЕ возможные состояния для всех кодеков.

Нет, стейт будет обычная структура в которой сохранены другие структуры. Как у вас

  bool is_fallback_ = false;

  Encoder * sw_encoder_;
  Encoder * hw_encoder_;

так и в ФП:

data SoftwareFallbackEncoder sw hw = SoftwareFallbackEncoder {
  _sw_fallback_encoder :: sw,
  _hw_encoder :: hw,
  _is_fallback :: Bool
}

ООП дает очень удобную композицию. Вам иногда нужен энкодер, который записывает на диск битстрим для отладки? Создаете FrameDumpingEncoder, который снаружи все тот же Encoder, но внутри помимо делегации вызовов собственно энкодеру сохраняет результат в файл. Вам нужно подсчитать статистику? Добавляете класс, который считает статистику и по цепочке вызывает остаток. Весь свой стейт он хранит внутри, его не надо как-то туда через аргументы передавать.

Что мешает то же самое сделать в ФП?

data DumpingEncoder e = DumpingEncoder { _inner :: e, _dump :: [VideoFrame] }
makeLenses ''DumpingEncoder

instance Encoder e => Encoder (DumpingEncoder e) where
  encode frame = do
    modifying dump (frame:)
    zoom inner $ encode frame 

Другой пример: алгоритмы бывает очень сложно писать в функциональном стиле эффективно. Ну это не совсем про ООП, а скорее про императивщину.

Это, увы, часто так, но тут на помощь приходит CAF, ST и разные оптимизации внутри GHC

А что вы делаете в ФП? Тоже тогда с кодом, пожалуйста.

{-# LANGUAGE TemplateHaskell #-}
module Main (main) where

import Control.Monad.State
import Control.Lens

data Bitstream
data VideoFrame

class Encoder a where
  encode :: VideoFrame -> State a (Maybe Bitstream)

data Vp9SWEncoder
data Vp9HWEncoder

instance Encoder Vp9SWEncoder where
  encode = undefined

instance Encoder Vp9HWEncoder where
  encode = undefined


data SoftwareFallbackEncoder sw hw = SoftwareFallbackEncoder {
  _sw_fallback_encoder :: sw,
  _hw_encoder :: hw,
  _is_fallback :: Bool
}
makeLenses ''SoftwareFallbackEncoder


instance (Encoder sw, Encoder hw) => Encoder (SoftwareFallbackEncoder sw hw) where
  encode frame = do
    use_fallback <- gets $ view is_fallback

    if use_fallback 
      then do
        maybe_encoded <- zoom hw_encoder $ encode frame
        
        case maybe_encoded of
          Just encoded -> return $ Just encoded 
          Nothing -> do
            is_fallback .= True
            zoom sw_fallback_encoder $ encode frame
          
      else
        zoom sw_fallback_encoder $ encode frame 

Можно было ещё ContT затянуть, чтобы не дублировать zoom sw_fallback_encoder $ encode frame, но показалось, что тут будет больше вреда чем пользы

ООП: худшее, что случалось с программированием

Ваш "потомок" благополучно модифицировал 40 функций. Еще 2 он не обнаружил.

Где в это время был тайпчекер?

Программисту нужна математика?

ещё раз; типы позволяют Вам избегать только ошибок связанных с типами: вместо килограмм пришли метры — ошибка

Попробуйте всё же открывать ссылки прежде чем повторять ложные тезисы. Это из теоремы четырёх красок:

Theorem four_color m : simple_map m -> colorable_with 4 m.

Определяет функцию four_color, которая имеет тип "Для любого m типа map R, из simple_map m следует colorable_with 4 m". Теорема выраженная на типах.

Это из Iris:

  Local Lemma acquire_spec γ lk R :
    {{{ is_lock γ lk R }}} acquire lk {{{ RET #(); locked γ ∗ R }}}.

  Local Lemma release_spec γ lk R :
    {{{ is_lock γ lk R ∗ locked γ ∗ R }}} release lk {{{ RET #(); True }}}.

Теоремы о том, как ведёт себя spin_lock в языке Heaplang. От двоеточия до точки это тип. В типе записана тройка Хоара, которая дальше доказывается.

Программисту нужна математика?

теоремы только про типы
ошибки только про типы

Утверждение, если не ложное, то очень натянутое. Вот теорема четырёх красок в Coq. Вот фреймворк для верификации многопоточки и полторы сотни статей про решение реальных задач впридачу. Вот формально верифицированный компилятор си. Подавляющее большинство свойств программы можно выразить в системе типов и формально доказать

а вот знак больше на больше или равно может по ошибке сменить
и типы или Coq здесь ему никак не помогут

Вы уже приводили этот пример и вам на него уже отвечали. Попробуйте доказать какое-то свойство программы и довольно быстро станет понятно, что в ней что-то не так

Программисту нужна математика?

вот это классическая подмена от людей "читающих книги по Coq".

Тут нет подмены, изоморфизм Карри-Ховарда позволяет логические утверждения перенести на уровень типов. При желании можно и теоремы про свои программы доказывать

Программисту нужна математика?

Из того, что обратный переход невозможен не следует, что происходит мутация. На мир ещё можно смотреть (и теория относительности, насколько я знаю, так и смотрит) как на четырёхмерное пространство, которое просто существует без каких-либо изменений. Энтропия при таком подходе это некоторая функция от времени, причём, тоже иммутабельная

Программисту нужна математика?

а претензия в том, почему вы смотрите только на этот факт, как достаточное основание для внедрения типизации?

Вы приписываете мне взгляды, которых я не придерживаюсь

однако за внедрение типов придётся платить оверхедом аннотаций, отказом от возможности формулировки выражений обобщённо, кучей механизмов преодоления построенной нами же клетки

Вы уже выдвигали эти тезисы, но подтверждения им так и не предоставили. Какой оверхед от аннотаций? Почему вдруг невозможно выразить формулировки выражений обобщённо?

за редко встречающуюся проблему платить много и постоянно

Системы типов разные бывают. Возьмёте сильную -- заплатите много, но она словит почти все ошибки, возьмёте слабую -- ошибок словит меньше, но и заплатите мало.

итого, по-хорошему: типы должны остаться уделом языков низкого уровня, где считают каждый флопс

Типы не столько для скорости нужны, сколько для выразительности и корректности

и, кстати, заметьте, как далёк наш спор от математики: а она здесь ни при чём, мы ведь о программировании говорим

Увы, не могу с вами согласиться. Последние пару месяцев я читаю книгу по математической логике и система типов Coq помогает и в понимании, и в проверке некоторых утверждений

Программисту нужна математика?

второй закон термодинамики утверждает мутабельность мира

Второй закон термодинамики он же про тепловые двигатели, энтропию и т.п.. Как из него следует мутабельность мира?

Программисту нужна математика?

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

Во-первых ошибки не только пользователь совершает, но и программист. Типы исключают целую категорию программистких ошибок. Во-вторых к пользовательскому входу типы тоже применимы. С помощью развитой системы типов можно, например, безопасный аналог printf сделать с форматной строкой пришедшей от пользователя

второй закон термодинамики - базис мутабельности

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

Современные языки программирования: как мода убила гениальность

Это же некорректное обоснование. Контрпример: "без атомов нет воды; уран это атом; значит в воде должен быть уран"

Откуда взялась хвостовая рекурсия и когда ожидается ее реализация в новом стандарте языка Си. Рекурсия VS Iteration

List не подойдёт, очень схемо-специфичный код. Из мира хаскеля ContT r (ST s) ближе всего к написанному

Откуда взялась хвостовая рекурсия и когда ожидается ее реализация в новом стандарте языка Си. Рекурсия VS Iteration

вроде недетерминированного программирования

Не поделитесь ссылкой на сайт/книгу/статью где можно поподробнее почитать про это?

Болезнь «ООП головного мозга»

Эта характеристика настолько общая, что становится бессмысленой. Под её кроме типов и классов ещё, например, тесты и документация подходят

Болезнь «ООП головного мозга»

Возмём определение системы типов (TaPL, B.C.Pierce) :

A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.

Классы не являются частью этого процесса. Классы могут существовать без системы типов (python, ruby, javascript), система типов может существовать без классов (c, haskell, agda, rust). Иногда классы добавляются в систему типов (typescript, c++, java), но в общем случае это абсолютно разные вещи, которые решают разные задачи. И это если забыть, что в прошлом комментарии вы писали про то, что типы это объекты, а в этом сравниваете их с классами.

Болезнь «ООП головного мозга»

прислал сюда ссылку: X действительно не нужно в программировании.

X на типах не нужно в программировании

почему я (опять) оказался прав?

Наверное, потому что подменять тезисы и побеждать ветрянные мельницы гораздо проще чем оспаривать реальные тезисы ваших оппонентов.

А что такое типы? Это тот же самый ООП, только чуть более широкий, ибо простые типы тоже могут рассматриваться как объекты.

Настолько плохо, что местами даже хорошо

кроме того, в спорах выше вы мне типы именно и рекламили.

Не припомню такого. Если только вы не считаете рекламой мои комментарии о том, что ваши представления про системы типов не соответствуют действительности

неа, я сражаюсь с тезисом, что типы жизненно необходимы для программирования. что их непременно надо повсюду запихать, а всех кто сопротивляется - посадить в клетку

Правильно! С такими вредными тезисами нужно бороться. Только вот не могу вспомнить кто же этот тезис высказывал...

Болезнь «ООП головного мозга»

Воинствующая безграмотность это писать, что Х не нужно в программировании не зная и даже не погуглив что такое Х.

а когда фигня действительно оказалась ненужной

Статья, которую вы смотрите называется "Числа Пеано на системе типов Rust". И сражаетесь вы, соответственно, с тезисом "арифметика на типах нужна для программирования", подменяя начальный: "арифметика нужна для программирования"

Болезнь «ООП головного мозга»

это не безграмотность, это офтопик по отношению к обсуждаемой теме

@vkni привёл числа Пеано как пример того, что в математике сложные вещи получаются из простых. Если бы вы открыли хотя бы википедию, вы бы увидели, что числа Пеано в этом контексте это просто натуральные числа. Но этого не сделали, проигнорировали, что пример был про математику, и начали говорить, что числа Пеано в программировании не нужны.

в программировании эта фигня не нужна (равно как и ряд Фибоначчи)

Покажете полезную программу никак не использующую натуральные числа?

А в математике и философии я интересуюсь только тем, что и правда интересно.

Трудно представить область математики, которую можно серьёзно изучать и при этом ни разу не столкнуться с аксиомами Пеано

Болезнь «ООП головного мозга»

погодите. Вы пока не объяснили: зачем вы постоянно программируете ряд Фибоначчи, а уже какие-то новые числа пихаете.

Числа Пеано в программировании не нужны.

Судя по тезисам, погуглить что такое числа Пеано вы не удосужились. Безграмотность настолько воинственная, что уже больше на троллинг похоже чем на реальное обсуждение