Зачем нужна статическая типизация?, или Вы всё врете!

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

Хорошо, пусть будут не стороны треугольника, а процедура копирования элементов массива (а-ля strcpy). С контрактом, что длина массива-приёмника не меньше, чем длина массива источника.

Для двух массивов тоже будешь создавать объект с типом НастройкиКопирования?

А в языках с динамической типизацией нет иерархии типов?

Там не надо проектированием заниматься?

Твой вой просто жалко выглядит, он демонстрирует лишь твои проекции.

В хаскеле (и любом другом ЯП) есть конкретные правила вывода типов.

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

Такое предположение разбивается о факт, что вывод произвольной системы типов из произвольного кода будет эквивалентен вопросу о вычислимости данного кода за конечное число шагов. А он в общем виде неразрешим.

Красота-то какая.

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

Давай я тебе перечислю кратко основные принципы проектирования, которые работают независимо от выбранного ЯП:

• Использование согласованных абстракций.
• Инкапсуляция деталей реализации.
• Скрытие секретов.
• Локализация областей вероятных изменений.
• Слабое сопряжение.
• Сведение сложных взаимодействий к стандартным шаблонам проектирования.

Говорит о чем-нибудь этот список? Судя по твоим комментам - ни о чем не говорит.

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

В динамических ЯП приходится заниматься тем же самым, но без какой-либо поддержки со стороны языка. Единственным инструментом, который он предоставляет, является «Господу нашему помолимся».

А особенно нелепо в этой теме выглядят наскоки питонистов на… Жаву. В то время как в Жаве классы - это классы, и они обеспечивают инкапсуляцию, в питоне классы - это проходной двор. Любая элементарная правка публичного интерфейса типа в статически типизированном языке делается легко и просто, в то время как на питоне она превращается в квест с грепами, гаданием на картах и увлекательными стек-трейсами.

А учитывая, что в питоне де-факто все кишки являются публичными… Аминь.

выведет типы сам. Без правил.

Что значит «без правил»?

Правила ведь общие для всех ЯП. Если есть f(x) и для f указано, что она принимает значения типа int значит x типа int. Если есть a + b и указано, что + принимает значения одинаковых типов, значит типы a и b одинаковы. Вывести вполне можно.

Единственная проблема в том, что в Хаскеле каждое значение принадлежит только одному типу, а в Питоне может быть в любом типе объединении. Поэтому автоматический вывод может ограничивать типы только при использовании в операциях.

x = 1 # x : Any
x = x + 1 # x : U Number Object
y = 1 / x # x : Number

И вторая проблема питона, что если в нём включить вывод типов, то всё равно часть программ станет некорректными. Потому что в примере выше никто не мешает четвёртой строкой написать x = "ok".

Можно попытаться считать каждое присваивание созданием нового типа, но тогда возникает проблема такого вида:

y = 1 / x # x : Number
if f(z):
  x = "ok" # x : String
if g(z):
  a = len(x) # здесь надо ругаться на несоответствие типа?

В питоне есть такая «замечательная» вещь как манки-патчинг, и в особенности специальный сахар для неё под названием декораторы.

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

А типы данных типа Справочника, Документа и тп не говорят об этом?

Расскажу Вам о агрегатных объектах Справочник и Документ.

Начнём с Справочника.

Обычно в базах СУБД имеются таблицы, содержащие нормативно-справочную информацию («Города», «Страны», ...) и таблицы с данными.

Так вот объект Справочник это ни какой-то специфичный лишь для 1С объект.
Справочники содержат обычно нормативно-справочные данные.

Немного об объекте Документ.

Это отнюдь не специфичный лишь для 1С объект.

Например можно создать объект типа Документ «Форумчане», в табличной части которого будут находиться учётные данные форумчан.

Объекты «Справочник» и «Документ» могут иметь несколько табличных частей.

В 1С имеется много методов для непосредственной работы с объектами, но обычно 1С-ники используют объект «Запрос» для выбора данных из объектов.

Пост был о том, что многие ассоциируют 1С лишь как «бухгалтерскую» программу.
Это вовсе не так.

В 1С всё так спокойненько,
Ни статической, ни динамической типизации не видать,
Всё культурненько, всё пристойненько,
Исключительная благодать.

Не, но я думаю, что нужно включить в контракт гарантии, что на копирование хватит памяти.

Можно двумя углами и стороной например.

Это уже 2 типа: Угол и Сторона. А так только Сторона в 3 экземплярах. Хотя всё зависит от конкретной задачи, для чего этот сферический треугольник вообще нужен. На координатной плоскости скорее всего намного полезнее будут координаты вершин.

Шутка

Чёт вектора вспомнились ...

здесь надо ругаться на несоответствие типа?

Очевидно, надо. Иначе будет TypeError в рантайме, если значение f(z) ложное, а g(z) наоборот. Но сама по себе смена типа переменной не страшна, она равнозначна выводу старой переменной из области видимости и созданию новой.

Говорит о чем-нибудь этот список? Судя по твоим комментам - ни о чем не говорит.

Вы систематически делаете вместо собеседника чучело, которое потом героически побеждаете. Вы, конечно, герой и молодец и чучело своё победили, переспорили и унизили, но в целом это делает вас малоинтересным собеседником. Такие дела.

В то время как в Жаве классы - это

… причина раздутого кода, сорванных сроков и в целом тупиковое направление развития ЯП. Все языки последнего времени от явавского ООП уходят, если и вводят в язык такую возможность, то очень-очень острожно, краешком, развешивая предупреждающие таблички.

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

потому, что заново переизобретать яву скучно и в принципе не имеет смысла, она уже есть.

Вы систематически делаете вместо собеседника чучело, которое потом героически побеждаете. Вы, конечно, герой и молодец и чучело своё победили, переспорили и унизили, но в целом это делает вас малоинтересным собеседником. Такие дела.

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

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

Про вашу личность я ничего не знаю. Обсуждается только манера диалога.

А какие идеи оказались состоятельными?

«Забить на сложность систем»?

Ути. Манера диалога crutch_master и rtxtxtrx, которые разговаривают хуже, чем пьяные бомжи, вас не смущает. А когда я посоветовал одному из них заняться самообразованием, вас это так задело.

Понимаю, про макак в исполнении rtxtxtrx всяко интереснее. Но я в цирке не работаю.

А какие идеи оказались состоятельными?

Структурное программирование, уже упоминавшееся здесь, пример состоятельного подхода — как до него тыщу лет назад додумались, так с тех пор и применяем. А вот иерархия классов … Ну, посмотрите, что в Go и Rust от неё оставили.

А когда я посоветовал одному из них заняться самообразованием, вас это так задело.

Вы начали с неявного предположения «собеседник не согласен со мной, потому что он необразованный идиот» и порекомендовали ему заняться самообразованием. Ну, что я могу сказать, вы молодец, всё делаете правильно, удачи вам по жизни.

Ну, посмотрите, что в Go и Rust от неё оставили.

Это что, аргумент такой?

Структурное программирование - это парадигма, весь смысл которой в том, что «программа может быть написана без goto», что было актуальным вопросом в 70-е, в эпоху ассемблер-оринтированного программирования в виде лапши из переходов по меткам.

Структурное программирование никак не противоречит ОО парадигме, поскольку применимо на уровне кода процедур (функций, методов…), но ничего не говорит о более высокоуровневой структуре проекта.

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

И при этом - питон является объектно-ориентированным языком. Плохим объектно-ориентированным языком - но всё же объектно-ориентированным.

Просто идея иерархии классов, как метода управления сложностью систем оказалась несостоятельной.

иерархия классов не то чтобы какая-то определяющая фича явы, композицию - которая широко используется в идиоматичном явовском коде, а не просто «ну вот есть такая фича» - никто там не отменял.

Я указал конкретные факты и аргументы в своём сообщении. Вам есть что возразить?

Говорит о чем-нибудь этот список? Судя по твоим комментам - ни о чем не говорит.

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

Понятно, режим забалтывания.

Структурное программирование - это парадигма, весь смысл которой в том, что «программа может быть написана без goto», что было актуальным вопросом в 70-е,

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

И при этом - питон является объектно-ориентированным языком.

Всё правильно. Старому языку — старые идеи.

ООП тоже закрыло тему, введя в массовое сознание разработчиков понятия полиморфизма, наследования и инкапсуляции, что превратило ADT из мутной математической концепции в рабочий способ структурирования кода. И только отдельные дон-Кихоты продолжают сражаться за право ходить в лаптях и сидеть по вечерам при лучине.

Для этого лучше контракты, а не статические типы. Контракты гибче. Типом не укажешь, что функция принимает стороны треугольника, а контрактом легко.

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

иерархия классов не то чтобы какая-то определяющая фича явы

Да как не посмотришь на явистов, вечно у них одно и то же:

1. Селёдка наследуется от рыбы.
2. Голубь наследуется от птицы.
3. Рыбы и птицы тоже наследуется,через многоклеточных от животных.
4. Все танцуют и поют, получилось красиво и удобно всё описать.
5. Приходит заказчик и говорит, что они изобрели мутации и нужно картошке добавить гены клубники и каракатицы.

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

И при этом - питон является объектно-ориентированным языком. Плохим объектно-ориентированным языком - но всё же объектно-ориентированным.

Можно заметить, что сочетание «плохой объектно-ориентированный язык» непременное условие успеха для ЯП. Так чем же плох Rust?? Условие выполнено…

Это уже 2 типа

Как будто что-то плохое.

Хотя всё зависит от конкретной задачи

Именно, нет смысла завозить в доменную модель всю геометрию.

ООП тоже закрыло тему,

Поэтому от него отказываются. Ага-ага.

введя в массовое сознание разработчиков понятия полиморфизма

Так это не заслуга ООП. Это заслуга книжек про ООП, которые рассказали тёмным императивным массам то, что лисперы знали ещё 60-х годах прошлого века.

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

А вам не приходило в голову, что дон Кихот — это вы?

Вы не поняли. Я сказал, что «ООП — неудачная идея» и в качестве примера привёл удачную.

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

и горе-разработчик голубей и селедок не смог за 15 минут выделить общие гены в интерфейс? Вон из профессии тогда.

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

нужно картошке добавить гены клубники и каракатицы.

И? Что сказать-то хотел?

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

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

А вам не приходило в голову, что дон Кихот — это вы?

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

Борьба с ООП сильно напоминает борьбу с теорией относительности.

Борьба с ООП сильно напоминает борьбу с теорией относительности.

насколько я помню, один их идеологов критики ооп, не менее буйно критиковал и теорию относительности. поскольку мол она ничего не дает. :)))

Типы описывают сущности, а контракты отношения между сущностями?

тип это разновидность контракта

например,

class MyIntType{
    int min = 1000;
    int max = 2000;
    boolean even = true;

    private value;

    public MyIntType(int value){
        this.value = value;
        if(!valid()) throw new MyCustomException();
    }

    private boolean valid{
        return value >= min && value <= max && isEven();
    }
}

использование этого типа вместо простого int гарантирует тебе не просто что «число целое», а что оно больше 1000, меньше 2000 и четное. эта незамысловатая гарантия сама по себе дает некоторое количество удобств. если число вот такого типа, то можно уже не проверять, что число не нулл, не отрицательное, не простое, что оно не выходит за границы заданного диапазона.

How can one man be so based?!

А вот так?

class MyIntType{
    int min = 1000;
    int max = 2000;
    boolean even = true;

    private value;

    public MyIntType(int value){

     if( ! ( value >= min && value <= max && isEven() ) )
      throw new MyCustomException();

     this.value = value;

    }
}

single responsibility principle

нет нужды размазывать проверки на то и се по всему коду. если ты точно знаешь, что вот в этой переменной хранится тип «IP address» (может быть даже из конкретного диапазона, или из возможного списка адресов) - создай соответствующий тип, выполни все необходимые проверки внутри него и дальше пользуйся экземпляром этого типа со спокойной душой, везде и всюду.

ООП это «котёнок с дверцей»

единственное что отличает тот винегрет идей который маркирует ООП от идей которые имели(и имеют) самостоятельную ценность и до и после

маркетинга начатого в журнале байт с шаром Смолтока и достигшее одного из пиков выкатыванием понятной и домохозяйке Wын95 как полностью ООП прогремме и последовавшей полностью ООП жаба 1.0

так это наследование (как повторное использование но с возможностью лазит и необходимость различать private vs protected vs friendly vs «same_file» vs «same_namespace» и прочае шарлатанство)

которое(наследование) возникла у А.КЕЯ как отличная идея и вариант реализация делегирования от листа к корню - т.е если у листа нет реализации то лезем к предкам

а когда идеи динамического резолва Smalltalk(self и т.д.) так и не прикрутили к статическим компилируемым так что бы это было не только на картинках но и было просто замещено практикой как критерием истины

НО

тут карта и пошла

GUI как причина успеха ООП

:)

кстати о типах и ооп.

класс - это просто обобщенный тип. а не способ конструирования программы.

класс это совокупность {S,O,I,T, С/D} где S - внутреннее состояние, 0 - операции, I - инварианты, T-трансформации в другие типы, С/D - конструкторы/деструкторы значения типа.

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

ооп это религия попавшая в образовательную машину

и так пусть будет )

если этот маленький кусочек кода приводить в порядок, придется еще всякое писать, а во-первых лень, а во-вторых так и основная мысль потеряться может )