Конечно, кто-то определил String и Html. И пользовательские типы под бизнес задачи нет проблем определить. Но излишне их потом указывать при каждом объявлении переменной этого типа. Компилятор по правой части равенства выведет тип переменной(ых) автоматически.
Конкретно, эти типы определены в стандартной библиотеке.
А здесь 20 строке пример объявления пользовательского типа Msg. И компилятор по телу функции выведет её тип view: Int -> Html Msg, где встречается пользовательский тип.
Нет. Вы определение науки видели? Если что-то "сочетает в себе элементы [...] науки", оно наукой еще не становится.
Эх! Согласен с вами и моё намерение процент содержания этой науки увеличить.
игнорируя семантику, вы не можете обсуждать сопровождаемость продукта людьми.
Я игнорирую семантику ООП в этом посте. В основном, потому что её как таковой нет в достаточно строгом смысле (сложно дать определение, например, класса, чтобы нельзя было привести контрпример). Не игнорирую её в продакшене. Я всецело за семантику, только ООП мне не хватает, чтобы переложить побольше сопровождаемости с людей на компьютер.
Вы не сводите к простому определению, вы ищете замену в рамках понятной вам элементной базы.
Вы сами говорили, что вот в этом ООП языке так, а в этом сяк. Времени не напасёшься изучать их комбинации идей! То ли дело стандартный научный базис: все термины однозначны. Вот вы поспорьте над термином "кортеж" столько, сколько мы спорим на "классом". Определение — и есть разложение в элементную базу.
это приводит к потере оригинальной семантики
В этом и проблема — нет никакой универсальной оригинальной семантики.
Эта ловушка была расставлена сознательно, я стараюсь коварно заманить в сети Теории категорий и прочей науки Информатики, чтобы было достаточно разработчиков и не нужно было обосновывать эти риски менеджерам.
Кортеж + функции, принимающие этот кортеж. Пруф хотя бы одного примера из общего случая.
Нет же. Можно иметь класс без данных (или без публичных данных).
Публичных / не публичных, к этому вопросу не относится, это вопрос к модульной системе.
У класса без данных (без состояния) все функции можно сделать статическими, и, вообще, расформировать класс, оставив только эти функции. Это проблема языка, что он обязывает оборачивать такие функции внутрь класса.
(а если продолжать эту цепочку дальше, то кортеж можно заменить просто набором переменных)
Да. Компилятор идёт ещё дальше и заменяет на просто ссылки в памяти.
Это уже отдельный вопрос, и он не имеет отношения к тому, что такое класс.
Как будет угодно, мне не важно, что такое класс, а важно, что им можно сделать. И equals(Object) — это косяк ООП, когда нужен equals(Self).
Нет, потому что реализации в разных языках отличаются.
ООП вообще бывает без классов. А еще можно сделать классы без ООП.
Конечно, потому что "ООП — популярный бренд, исторически сложившийся, но не уникальный набор идей без единого центрального стержня." И жестоко просить дать другое общее определение ООП.
В том, что система — это не вид.
Чего нельзя сделать в "Классе, как одном из видов типов", что можно в "Классе, как одной из систем типов" или наоборот?
Любой курс по технологиям разработки ПО, первый попавшийся в гугл.
Вы — возможно. А менеджмент, которому важно время выхода на рынок?
Я рассматриваю именно экономию итогового проекта времени, коэффициенты берите свои:
Кодирование 0.2 времени
Посткодирование 0.8 времени
Итого 0.2*2 + 0.8/2 = 0.8 время сэкономлено
Но доказать экономию времени для менеджента не такая проблема, как обосновать риски при поиске разработчиков, что упомянуто в начале поста. Тут порочный круг: нет внедрений — нет доказательства, нет доказательства — не будет внедрений. Но это вопрос времени, внедрения появляются и лет через 20 всё будет ок.
Я еще раз спрашиваю, что такое "сильная" и "слабая" системы типов?
Автоматический вывод типов позволяет их не писать.
Типы есть всегда, даже когда их не пишут в коде. Тогда, например, пишут в документации. Или есть один бесполезный для рассуждений тип-сумма всех остальных типов:
Наследование в ООП смешивает как минимум 4 идеи
Ну вы бы хоть сказали, какое из определений наследования вы используете (и зачем вы это делаете).
Никакое определение конкретно и все определения в сумме, т.к. "ООП — набор идей без единого центрального стержня". Мне не интересны определения сами по себе, мне интересно, для чего они используются и альтернатива.
Аналоги: запись, кортеж, тип-произведение.
Нет. Если мы говорим о более-менее устоявшихся определениях, то запись, кортеж и типы-произведения — это не классы, и фундаментальное отличие состоит в том, что обычно класс предполагает поведение, а кортеж — нет.
Я не говорю об определениях, а об аналоге, чем класс можно заменить. Наименьший общий знаменатель в классах — это данные, например, в Data классе нет поведения. Поведение можно упаковать отдельно в функцию и первый аргумент назвать this. Данные и функции можно упаковать в модуль. Разбиение класса на более мелкие сущности (данные и функции) имеет преимущества. Например, когда в функции (типа Java equals) нужен "второй this" приходится вводить интерфейс Comparable, когда это просто функция a->a->Bool. Или меньшая связность кода: функции над одними данными можно поместить в разные модули, а не в классы, связанные наследованием. Или не нужно думать, как раскладывать функции по классам, когда есть несколько подходящих.
Класс — это не система типов. Класс — это (в некоторых ОО-языках) один из видов типов (простите); иными словами (в некоторых ОО-языках) всякий класс — это тип, но не всякий тип — это класс.
Вы сами используете обтекаемые формулировки "в некоторых ОО-языках" потому, что "ООП — набор идей без единого центрального стержня" и сложно сформулировать утверждение для всех ООП языков. Сравните ваше определение "Класс — один из видов типов" и моё "Класс — одна из систем типов". В чём разница? Они изоморфны. Я согласен с вами, что в ООП есть другие подсистемы типов, например элементарные типы и они не классы.
Здесь забыт важный пункт: сильные системы типов могут требовать от вас больше работы, чем слабые. Кстати, эй, а что же такое "сильная" и "слабая" система типов?
В сколько-нибудь реальных проектах, написание кода составляет мизерную долю от общего времени разработки и ошибки на этом этапе имеют стоимость нескольких ударов по клавиатуре. Дебаг, тестирование и сопровождение — вот где работа зарыта. И я с удовольствием поменяю сокращение их вдвое на вдвое более сложное кодирование. Сравните на "силу" и "слабость" системы типов Elm и JavaScript.
Это утверждение, скажем так, бессмысленно. Операции, которые компьютер проводит над типами, ничем не отличаются по "автоматизму" от операций, которые компьютер производит над другими данными.
Если типы слабые, то нужно писать больше юнит тестов, и это будет делать не компьютер автоматически, а вручную программист.
В том числе [наука](https://ru.wikibooks.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5), но не только.
По моим оценкам, сопровождение продукта, когда компилятор 100% верифицировал отсутствие класса ошибок, например NullPointerException, будет дешевле, чем когда программист частично покрыл его тестами. Но тут каждый выбирает сам и получает финансовую обратную связь.
> Вот это «в обмен» и демонстрирует, что они не одинаковы. Значит, вы не нашли общую суть, а заменили одну другой.
Формальное определение одинаковости, операторы неформальны:
У чистого интерпретируемого языка нет compile time.
Не бывает чистого интерпретируемого языка: сегодня нет компилятора, завтра напишут.
Да, это вопрос терминологии.
Отлично, что мы поняли друг друга! Не устаю повторять, меня интересуют идеи, а не алиасы на идеи (терминология). Есть тучи и тьма конфликтующей терминологии, а ясных идей довольно ограниченное количество и они настолько просты, что их сложно выразить.
Формально, интересующее вас отличие называется — насколько я помню — именно что статическим анализом, и к компиляции отношения не имеет.
Всё, что делает компилятор — это статически анализирует код, сначала лексически, потом синтаксически и семантически, потом изоморфно преобразует семантику в оптимизациях. Но статически анализировать код может, например, форматтер.
Статически vs динамически = рано vs поздно = compile vs run = у разработчика vs на продакшене = в моей ветке vs в мастере. Идея есть, а слова, которое выражает все разом нет.
P.S. Ещё раз спасибо, что указываете места, где я криво и непонятно выражаюсь.
… добиться… результата разными средствами,… значит… приводят к одному… результату.
Извините, что сильно порезал вашу цитату, чтобы показать, что это тавтология.
Результат — есть суть того, к чему я стремлюсь по определению "программирование — инженерная наука о композиция кода". Ключевое слово инженерная, то есть нужен практический результат. Если результата можно достичь несколькими способами, то я выберу самый дешёвый и прагматичный.
Так семантика — это то, чем в программировании жертвовать нельзя.
Я пожертвовал семантикой ООП потому, что, во-первых, в ней нет "единого центрального стержня"; во-вторых, пожертвовал в обмен на семантику ФП; в-третьих, прагматика выше мастью, чем семантика по определению программирования.
Для этого подойдет любой "тип" из любого языка программирования? Или эти типы должны соответствовать определенным критериям?
Любой тип. Разница в том, что вы можете из него вывести. Например, тип, который определяет, что в нём может лежать всё, что угодно, даёт вам ноль статической информации в compile time и можно назвать его динамическим.
Совершенно не обязательно же. Можно иметь полностью интерпретируемый язык со статической типизацией.
Можно не пользоваться статической информацией пораньше в compile time и оставить ошибки до run time. Интерпретируемый или нет — не важно. Можно воспользоваться статическим анализатором кода, который обработает типы в compile time, но сгенерирует не код, а отчёт об ошибках или документацию.
Общая суть — это и есть "одно через другое" и наоборот, см. изоморфизм. Меня интересует именно интент, даже прагматика. Ну а семантика, да, пришлось пожертвовать во имя краткости на 3 порядка, о чем написал в предупреждении "не претендующий на точность".
Конечно, кто-то определил String и Html. И пользовательские типы под бизнес задачи нет проблем определить. Но излишне их потом указывать при каждом объявлении переменной этого типа. Компилятор по правой части равенства выведет тип переменной(ых) автоматически.
Конкретно, эти типы определены в стандартной библиотеке.
А здесь 20 строке пример объявления пользовательского типа Msg. И компилятор по телу функции выведет её тип view: Int -> Html Msg, где встречается пользовательский тип.
Эх! Согласен с вами и моё намерение процент содержания этой науки увеличить.
Я игнорирую семантику ООП в этом посте. В основном, потому что её как таковой нет в достаточно строгом смысле (сложно дать определение, например, класса, чтобы нельзя было привести контрпример). Не игнорирую её в продакшене. Я всецело за семантику, только ООП мне не хватает, чтобы переложить побольше сопровождаемости с людей на компьютер.
Например, равенство множеств
Вы сами говорили, что вот в этом ООП языке так, а в этом сяк. Времени не напасёшься изучать их комбинации идей! То ли дело стандартный научный базис: все термины однозначны. Вот вы поспорьте над термином "кортеж" столько, сколько мы спорим на "классом". Определение — и есть разложение в элементную базу.
В этом и проблема — нет никакой универсальной оригинальной семантики.
Эта ловушка была расставлена сознательно, я стараюсь коварно заманить в сети Теории категорий и прочей науки Информатики, чтобы было достаточно разработчиков и не нужно было обосновывать эти риски менеджерам.
Озвучте верное.
Кортеж + функции, принимающие этот кортеж. Пруф хотя бы одного примера из общего случая.
Публичных / не публичных, к этому вопросу не относится, это вопрос к модульной системе.
У класса без данных (без состояния) все функции можно сделать статическими, и, вообще, расформировать класс, оставив только эти функции. Это проблема языка, что он обязывает оборачивать такие функции внутрь класса.
Да. Компилятор идёт ещё дальше и заменяет на просто ссылки в памяти.
Как будет угодно, мне не важно, что такое класс, а важно, что им можно сделать. И equals(Object) — это косяк ООП, когда нужен equals(Self).
Конечно, потому что "ООП — популярный бренд, исторически сложившийся, но не уникальный набор идей без единого центрального стержня." И жестоко просить дать другое общее определение ООП.
Чего нельзя сделать в "Классе, как одном из видов типов", что можно в "Классе, как одной из систем типов" или наоборот?
Тип определяется самим упоминанием литерала "Hello, World!": String, и дальше эта информация выводится вверх по синтаксическому дереву.
text здесь — это функция, превращающая строку в HTML
Поиграться можно тут.
Любой курс по технологиям разработки ПО, первый попавшийся в гугл.
Я рассматриваю именно экономию итогового проекта времени, коэффициенты берите свои:
Кодирование 0.2 времени
Посткодирование 0.8 времени
Итого 0.2*2 + 0.8/2 = 0.8 время сэкономлено
Но доказать экономию времени для менеджента не такая проблема, как обосновать риски при поиске разработчиков, что упомянуто в начале поста. Тут порочный круг: нет внедрений — нет доказательства, нет доказательства — не будет внедрений. Но это вопрос времени, внедрения появляются и лет через 20 всё будет ок.
тут
Автоматический вывод типов позволяет их не писать.
Object = Int + String + Num + ...
Никакое определение конкретно и все определения в сумме, т.к. "ООП — набор идей без единого центрального стержня". Мне не интересны определения сами по себе, мне интересно, для чего они используются и альтернатива.
Я не говорю об определениях, а об аналоге, чем класс можно заменить. Наименьший общий знаменатель в классах — это данные, например, в Data классе нет поведения. Поведение можно упаковать отдельно в функцию и первый аргумент назвать this. Данные и функции можно упаковать в модуль. Разбиение класса на более мелкие сущности (данные и функции) имеет преимущества. Например, когда в функции (типа Java equals) нужен "второй this" приходится вводить интерфейс Comparable, когда это просто функция a->a->Bool. Или меньшая связность кода: функции над одними данными можно поместить в разные модули, а не в классы, связанные наследованием. Или не нужно думать, как раскладывать функции по классам, когда есть несколько подходящих.
Вы сами используете обтекаемые формулировки "в некоторых ОО-языках" потому, что "ООП — набор идей без единого центрального стержня" и сложно сформулировать утверждение для всех ООП языков. Сравните ваше определение "Класс — один из видов типов" и моё "Класс — одна из систем типов". В чём разница? Они изоморфны. Я согласен с вами, что в ООП есть другие подсистемы типов, например элементарные типы и они не классы.
В сколько-нибудь реальных проектах, написание кода составляет мизерную долю от общего времени разработки и ошибки на этом этапе имеют стоимость нескольких ударов по клавиатуре. Дебаг, тестирование и сопровождение — вот где работа зарыта. И я с удовольствием поменяю сокращение их вдвое на вдвое более сложное кодирование. Сравните на "силу" и "слабость" системы типов Elm и JavaScript.
Если типы слабые, то нужно писать больше юнит тестов, и это будет делать не компьютер автоматически, а вручную программист.
В том числе [наука](https://ru.wikibooks.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5), но не только.
По моим оценкам, сопровождение продукта, когда компилятор 100% верифицировал отсутствие класса ошибок, например NullPointerException, будет дешевле, чем когда программист частично покрыл его тестами. Но тут каждый выбирает сам и получает финансовую обратную связь.
> Вот это «в обмен» и демонстрирует, что они не одинаковы. Значит, вы не нашли общую суть, а заменили одну другой.
Формальное определение одинаковости, операторы неформальны:
(a = b) ~ (a <= b) & (b <= a)
Не бывает чистого интерпретируемого языка: сегодня нет компилятора, завтра напишут.
Отлично, что мы поняли друг друга! Не устаю повторять, меня интересуют идеи, а не алиасы на идеи (терминология). Есть тучи и тьма конфликтующей терминологии, а ясных идей довольно ограниченное количество и они настолько просты, что их сложно выразить.
Всё, что делает компилятор — это статически анализирует код, сначала лексически, потом синтаксически и семантически, потом изоморфно преобразует семантику в оптимизациях. Но статически анализировать код может, например, форматтер.
Статически vs динамически = рано vs поздно = compile vs run = у разработчика vs на продакшене = в моей ветке vs в мастере. Идея есть, а слова, которое выражает все разом нет.
P.S. Ещё раз спасибо, что указываете места, где я криво и непонятно выражаюсь.
Извините, что сильно порезал вашу цитату, чтобы показать, что это тавтология.
Результат — есть суть того, к чему я стремлюсь по определению "программирование — инженерная наука о композиция кода". Ключевое слово инженерная, то есть нужен практический результат. Если результата можно достичь несколькими способами, то я выберу самый дешёвый и прагматичный.
Я пожертвовал семантикой ООП потому, что, во-первых, в ней нет "единого центрального стержня"; во-вторых, пожертвовал в обмен на семантику ФП; в-третьих, прагматика выше мастью, чем семантика по определению программирования.
Любой тип. Разница в том, что вы можете из него вывести. Например, тип, который определяет, что в нём может лежать всё, что угодно, даёт вам ноль статической информации в compile time и можно назвать его динамическим.
Можно не пользоваться статической информацией пораньше в compile time и оставить ошибки до run time. Интерпретируемый или нет — не важно. Можно воспользоваться статическим анализатором кода, который обработает типы в compile time, но сгенерирует не код, а отчёт об ошибках или документацию.
Общая суть — это и есть "одно через другое" и наоборот, см. изоморфизм. Меня интересует именно интент, даже прагматика. Ну а семантика, да, пришлось пожертвовать во имя краткости на 3 порядка, о чем написал в предупреждении "не претендующий на точность".