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

не те книжки читаете.

был язык CLU - ща его принято относить к ООП - но тогда не было хайпа ООП

хайп ООП был современником массового проникновения GUI в офисы

ваще ООП в компилируемом языке с прикручиванием разделения «живой» сущности ака объект на прототип-шаблон-ака-КЛАСС_с набором методов общих для всех объектов этого класса - где обьект это набор данных отличающих один объект одного класса от другого объекта этого же класса своим адресом либо ещё каким хэндлом в глобальной таблице - это прекрасный пример разных идей скрещенных с нуждой реализации в компилируемость(иначе очень очень медленно)

а что такое компилируемость как не сверхранее разЫменование ибо всё равно одно и тоже

ну и вот....

все кто хотят отказаться от целостного понятия обобщенного типа, заменив его манной кашей, размазанной по всем коду - наркоманы или жулики!

если вы критикуете ооп - значит вы против типов данных, вам хватит и встроенного инта со строкой.

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

самый распространенный вариант - имплементация интерфейса.

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

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

lol пацтол

дык совместимость по интерфейсам ужо в Адке было

ещё до хайпа ООП

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

отличная подмена тезиса

коллега?

если вы критикуете ооп - значит вы против типов данных, вам хватит и встроенного инта со строкой.

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

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

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

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

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

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

эти концепции взаимно протекающие

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

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

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

Один из таких продуктов отрицателей ООП мне давеча пришлось рефакторить. После того, как я увидел в коде на JS огромную хэшмапу на 8 экранных страниц, реализующую форму с контроллами, которая была скопирована в 5 разных мест проекта, и в каждом имела кастомные правки – после этого меня сложно удивить.

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

компитятор это деталь реализации как общность методов у классического(скорее ветви С++) варианта реализации объектов через «хэндл типа» и сразу же прикручивание виртуальных таблиц для перегрузки - всё это обусловлено дорогой(относительно) памятью и требованием быть компилируемым

ООП не обязано быть компилируемым

а вот реализация и рассказывание некритически мыслящими(если такое вообще не оксюморон) ООП в обязательной сцепке с компиляцией и создаёт тот вполне религиозный фанатизм:

кто против ООП не достоин наслаждаться благами декомпозиции сокрытия и прочая прочая

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

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

или экспорт из модуля вы тоже обьявляете нарушением инкапсуляции?

отличное соломенное чучело

чел который неадекват причислят к противникам «единственно верного учения»

тем самым показывать что среди сторонников «единственно верного учения» неадекваты другие

Треугольник не может быть не выпуклым. Но люди так о треугольнике не думают, если они не ушиблены математикой на всю голову. А я говорю о том, как приятнее решать задачи, не перестраивая процесс мышления на машинный. Это ведь то, чем козыряют сторонники динамических сред программирования — что им удобно программировать и пофигу, что типов нет.

я пятиугольник - с пятью.

хорошо, я запомню

да блина сама оппозиция класс vs объект есть мелочь реализации распухшая до ....

сори за кривую цитату:

Мир(да и многие его части в отдельности) как правило не описываються односортными алгебрами

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

а потом читать лекции о вреде треугольников.

Так разговор не о треугольниках, что ж ты не поймешь-то никак, мне капслоком написать, что ли?

у Алана Кея эталонное объяснение ООП через клетки - он по первости биолух

появление классов в ООП это симулянт Страус

мое хорошее настроение перебивает все ваши капслоки. и не надо мне его портить

Он не симулянт. Он воришка интеллектуальной собственности. Украл термин, а потом извратил, чтобы обратно не отняли, ибо кому нужно такое чудовище.

хз

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

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

как в том анеке

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

преамбула: https://habr.com/ru/companies/vk/articles/411307/

кода : https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/

правильные питонисты в курсах какие части следуют погрузить в си/rust|mojo

java это кровавый Ынтерпрайс с public void class main etc

А ты попробуй описать

ты сначала попробуй описать нахрена оно тебе надо )

а то понапривыкали программировать своих коней сферических в рассуждательном вакууме

Это и есть длина получателя не меньше длины отправителя.

https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/

2005-й. Ох как неинклюзивненько.

Попробовал бы он опубликовать такое в 2023-м, сожрали бы на месте.

А Питон - это «новая Java». Разница только в том, что Java действительно простая как кирпич. А «простой» Питон швыряет этот кирпич вам в лицо.

Им бы на Go писать, там это норма.

Вон из профессии тогда.

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

вообще-то инструмент должен помогать, а не служить дополнительным препятствием.

Именно. Статически типизированный язык помогает рефакторить код и вносить изменения в архитектуру. Вот прямо как в данном примере про селёдку.

Чем мне поможет питон? Стек-трейсами?

А ты попробуй описать

ты сначала попробуй описать нахрена оно тебе надо )

а то понапривыкали программировать своих коней сферических в рассуждательном вакууме

Подожду более благодарного собеседника, если Вы не против 😊, которому объяснять не придется.

Питон тем и хорош

что на н>м можно отличить

в отличии от Жабы изначальной которая не могла (ща может) быть использована для классификации пациентов

На питоне ща массово пишут еще более хелло-ворлдный мрак без архитектуры, чем на Жаве. Благодаря «хэшмап-ориентированному программированию», которое на Жаве было затруднёно из-за статической природы языка.

А вот при попытке писать на Питоне качественный и надежный код, ты получаешь в лицо кирпич.

Так что отличить благодаря Питону программистов действительно можно:

Грамотный программист никогда при прочих равных не возьмёт для реализации крупного проекта Питон.

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

Всё же приведенный Вами пример скорее не о типах данных, а о семантике полей.

Если так людьми разбрасываться, то некому работать будет.

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

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

и где в описанном случае ошибка или препятствие?

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

Простые контракты можно заменить типом. Чуть посложнее «sort возвращает упорядоченный массив из тех же элементов, что пришли на вход», уже нужны зависимые типы и что-то вроде Agda или Liquid Haskell. Ещё чуть сложнее «f : функция от вещественного числа x, которая возвращает функцию от вещественного числа, возвращающую числа не меньше x». Такое вроде как типами уже никак не выразить.

Накладных расходов при копировании не будет? Временные переменные и т.д.?

Если и будут, то на стеке. А он уже есть.

вы не знаете?

И опять вместо того, чтобы просто спросить, вы предпочли сделать неявное предположение, что собеседник — необразованный идиот (и потому с вами не согласен). Стереотип, что программисты — социально неадаптированные аутисты, появился не на пустом месте.

Упреждая ваши следующие вопросы отвечу:

1. Выделяйте в системах независимые части и позволяйте им обмениваться через интерфейсы.

2. У ООП, естественно, нет монополии на этот подход, а уж статическая типизация тут и вовсе не при делах.

И всё. Вся ваша иерархия наследования отправляется к козе в трещину. Переделывайте.

ооп это не идея, это концепция.

Глубокая мысль.

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

Ты не веришь в нашу Тумбу-Юмбу!

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

лысенковщиной. Хотя на самом деле с ООП никто не борется. Просто мода прошла и сейчас применяют другие подходы. Вы немножко отстали от жизни, но это ничего. Некоторые вообще до сих пор на Коболе пишут с Фортраном и отлично себя чувствуют.

ладно, вторая попытка )

Как это отобразить в системе типов?

нет никаких «типов», есть «контракты».

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

центральный момент - контракт, а не «ООП», «процедурное, структурное, функциональное, какое-еще-там программирование».

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

Контрактно Ориентированное Программирование - вот к чему все пришло, просто это (пока еще) громко и отчетливо не произнесено вслух.

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

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

У вас что-то где-то болит - это не мои проблемы.

Упреждая ваши следующие вопросы отвечу:

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

ООП это практическая реализация такой методологии.

Говорить «мы за всё хорошее против всего плохого» - это НЕ методология.

Ты не веришь в нашу Тумбу-Юмбу!

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

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

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

А я вообще чувак не модный. На скутере не езжу, смузи не заказываю. Хмуро жарю простую картошечку на сковороде, а потом иду читать непонятные для вас книжки. Мне почти 40 лет, и я могу себе позволить не заниматься борьбой с ветряными мельницами.

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

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

Именно. Статически типизированный язык помогает рефакторить код и вносить изменения в архитектуру. Вот прямо как в данном примере про селёдку.

- Ты, я слышал, машину купил? Ну, как?
- Отлично. Сегодня с утра съездил за запчастями, потом заправился, потом - в гараж договориться о покраске, потом в ГАИ... Представляешь, как бы я все это успел без машины?

«sort возвращает упорядоченный массив из тех же элементов, что пришли на вход»

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

Такое вроде как типами уже никак не выразить.

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

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