LINUX.ORG.RU

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

 ,


1

4

В теме "Питонячьи радости " на последних страницах между мной и @rtxtxtrx внезапно разгорелся спор, из которого я понял, что есть еще люди, которые не считают динамическую типизацию (в том виде, в котором она представлена в Питоне, а именно строгая динамическая типизация) серьезным недостатком при работе с большим объемом кода, особенно при рефакторинге. Вообще изначально разговор завязался вокруг назначения type hints введенных в Питон 3: я утверждал, что они нужны для создания семантических связей в коде, которые будут препятствовать внесению деструктивных изменений в код в результате опечатки или иной ошибки кодера (изменил код, в результате которого какое-либо выражение получило некорректное значение, которое тем не менее обладает схожим с корректным значением типовым контрактом, поэтому при запуске код не «упадет» сразу, указав на проблему); оппонент заявил, что они нужны для (само)документации и не более того.
Но потом выяснилось, что и царь-то ненастоящий (читай, статическая типизация). Не нужна она, просто именуй сущности понятно и уповай на строгую типизацию. А если типизация не строгая, то сами виноваты, у нас в Питоне всё ОК.
Поскольку тема большая и вкусная, я предлагаю всем обсудить этот очень важный вопрос в меру скромных сил и познаний каждого желающего. Обсуждение вторичных вопросов, как-то «статическая типизация нужна для генерации эффективного кода», «при динамической типизации тип только один, object» etc. не предусмотрено — спорим только о том, дает ли статическая типизация выигрыш, если надо перекраивать несметные тыщи kloc. Если есть вообще о чем спорить 😅.

★★★★★

Ответ на: комментарий от ugoday

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

wandrien ★★
()
Ответ на: комментарий от wandrien

какие проблемы вы видите в вашем примере, которые якобы есть в ст. ЯП и якобы отсутствуют в дин. ЯП.

В случае динамики люди изначально не будут так упарываться по построению башни из классов. Другой мир — другие правила.

Иерархия абстракций создаётся под решаемую задачу и зависит от самой задачи. Универсальной иерархии не существует

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

ugoday ★★★★★
()
Ответ на: комментарий от alex1101

Толпы людей в костюмах с галстуками ходили проповедовали новую ООП религию. Сейчас уже смешно, а в девяностых-нулевых многие верили.

ugoday ★★★★★
()
Ответ на: комментарий от wandrien

Библиотеки предоставляют документацию, поэтому ООП работает. Ясно-понятно, не знаю что с вами, но надеюсь это не заразно.

ugoday ★★★★★
()
Ответ на: комментарий от alex1101

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

В случае динамики люди изначально не будут так упарываться по построению башни из классов. Другой мир — другие правила.

Опять лишенная содержания гуманитарщина пошла.

Как именно «упарываться»?

А точно ли не будут?

Почему «башня из классов» - это плохо?

И в чем более лучшая альтернатива для башни из классов?

Столько вопросов без ответов.

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

Ну как-то так.

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

Так одно другому не противоречит. Переиспользование кода невозможно «в вакууме», оно работает в рамках поставленной задачи.

Открой вон документацию на Cairo и с удивлением обнаружишь там… классы и методы. Как же так.

wandrien ★★
()
Ответ на: комментарий от wandrien

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

Практические задачи, однако.

Точнее, легко можно верифицировать простую систему типов как в Си. И даже в ней уже результат malloc приходится вручную приводить к нужному типу.

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

monk ★★★★★
()
Ответ на: комментарий от alex1101

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

Так закладывается первый кирпич на кривой дороге, что с «ООП что-то не так».

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

Просто у этих данных товарищей он оказался именно вот здесь.

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

В данном случае мы и видим - отсылки на «лучший мир». «А вот в ГО нет вашего ООП. А вот в JS нет вашей статики.» А чего именно нет? Почему именно так? Как меняются свойства инструмента в связи с этим? Тёмный лес.

wandrien ★★
()
Ответ на: комментарий от ugoday

В случае динамики люди изначально не будут так упарываться по построению башни из классов. Другой мир — другие правила.

В динамическом питоне сплошные башни из классов. В статическом хаскеле их полное отсутствие.

monk ★★★★★
()
Ответ на: комментарий от wandrien

Ведь всё же очевидно должно быть в этом проекте, я могу этот же код в разы проще организовать, без башни классов!

Причём на лиспе (который у угодая в тегах), после чего вместо башни классов строит башни скобочек.

alex1101
()
Ответ на: комментарий от monk

Вот про malloc хороший образец.

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

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

Объект производного класса передаётся как аргумент коду, который работает с объектом базового класса и затем возвращает данный объект в колл-бэке.

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

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

wandrien ★★
()
Ответ на: комментарий от wandrien

Опять лишенная содержания гуманитарщина пошла.

К слову неприятие гуманитарного знания выдаёт людей наивных и недалёких. Собственно, изначальное противопоставление технарей и гуманитариев было гуманитарной технологией по контролю над образованными людьми. Но про divide et impera советским инженерам не рассказывали.

Столько вопросов без ответов.

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

Без единой отсылки к чему-либо.

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

Переиспользование кода невозможно «в вакууме», оно работает в рамках поставленной задачи.

Диалектика!

и с удивлением обнаружишь там… классы и методы. Как же так.

Initial release: Before 2003; 20 years ago

Старому коду старые подходы. Ничего удивительного.

ugoday ★★★★★
()
Ответ на: комментарий от monk

Ну, нет. Гораздо меньше, как на яве на питоне и близко не пишут. Бывают случаи «программист на фортране способен написать программу на фортране на любом языке», но это исключения. Хаскелл — функциональщина. Другой мир, другие правила, как и было сказано. Но мы тут в одномерном случае путаемся, а если ещё ось координат «функциональщина—императивщина» добавим, то точно зашьёмся.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

И повальная мода на микросервисы, и ограничение на ООП в новых ЯП вас не убеждает.

Конечно не убеждает, потому что это не аргумент, а херня.

В твиторе и тиктоке, которые обосраться какие модные, есть ограничения на длину контента, отсюда делаем вывод, что лонгриды, книги и фильмы - ошибка природы, мусор и фу? Ну, видимо как-то так и работает мышление у людей, которые ёрничают насчёт чтения каких-то там книжек.

alex1101
()
Ответ на: комментарий от wandrien

Я же сказал уже. Выделяйте модули и стройте интерфейсы. Сейчас это модно делать, через микросервисы, но можно и без них.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

переписывают на Go и Js.

хоронили тещу - порвали два баяна.

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

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

olelookoe ★★★
()
Ответ на: комментарий от ugoday

Сейчас это модно делать

Сейчас ещё модно себе член отрезать и находить в себе прочие психические расстройства…

alex1101
()
Ответ на: комментарий от olelookoe

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

Ну, да. Там Агда, Идрис и формальное доказательство кода во все поля. Жаль, ни разу такого не видел, но приятно сознавать, что где-то есть такие профессионалы. Я-то всё больше по интерпрайзу, тут немножко уныленько, зато деньги есть.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Мля, чел… Может мне начать подсказывать тебе, как убедительнее нести эту чушь?

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

Оно так хоть поубедительнее будет выглядеть.

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

wandrien ★★
()
Ответ на: комментарий от ugoday

К слову неприятие гуманитарного знания выдаёт людей наивных и недалёких. Собственно, изначальное противопоставление технарей и гуманитариев было гуманитарной технологией по контролю над образованными людьми. Но про divide et impera советским инженерам не рассказывали.

Ну так ты ж начал сказочку про белую козу… про аутистов, то есть. Не нраицца что ли? А я вот только во вкус вошел. Опустился, так сказать, до уровня собеседника и проникся.

wandrien ★★
()
Ответ на: комментарий от wandrien

Нахер мне не нужны эти ваши контракты и проверка типов компилятором.

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

похож с этой «модой».

Обидно? А нечего быть такими зашоренными.

ugoday ★★★★★
()
Ответ на: комментарий от wandrien

Вам ещё многое предстоит узнать. Например, что гуманитарное знание — это высшее знание. Гуманитарии правят миром, а технари — обслуга. Вроде римского сенатора и раба-горшечника. Так что можете продолжать обзывать меня гуманитарием. Можете ещё и плейбоем-миллиардером. Это неправда, но всё равно приятно.

ugoday ★★★★★
()
Ответ на: комментарий от wandrien

Привычка носить с собой член

Боюсь, не смогу поддержать с вами беседу об этой волнующей теме.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

А особенно мне от этого диалога забавно от того, как ты в начале с краплёных козырей зашел. Типа вот ты, wandrien, говоришь как-то не так, хороший тон дискуссии не соблюдаешь. Не по правилам, не по феншую. И вся вот эта ботва.

Сразу расклад ясен, что гнилой базар. Ну оно и вылезло всё сразу.

wandrien ★★
()
Ответ на: комментарий от ugoday

Зацепило, зацепило) Хорошо получилось. Я доволен результатом.

wandrien ★★
()
Ответ на: комментарий от wandrien

Ну, вы и правда постоянно создаёте соломенных чучел. Я что ли вас научил этому? Сами, всё сами.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Кстати, интересное наблюдение.

Пока в python и php тащат типы, в C++ от них фактически отказываются.

Вот такое компилируется:

auto compose(auto f, auto g) { return [=](auto x) { return f(g(x)); }; }

Попробуйте написать тип compose.

monk ★★★★★
()
Ответ на: комментарий от ugoday

Объект живой природы, который надо как-то описать в рамках данной архитектуры.

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

  • в яве это сделать невозможно
  • в яве это сделать сложно
  • в яве это сделать долго и муторно
  • в яве так делать не принято
  • в целом в ООП так делать не принято
  • свой вариант

который из пунктов?

arkhnchul ★★★
()
Ответ на: комментарий от ya-betmen

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

Это ведь не та ситуация, когда ты осознал, что сморозил глупость и теперь отвечаешь невпопад чтобы поскорее съехать с темы?

ya-betmen ★★★★★
()
Ответ на: комментарий от arkhnchul

в яве это сделать невозможно

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

в яве это сделать долго и муторно

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

ugoday ★★★★★
()
Ответ на: комментарий от monk

Разумный подход. Человек должен думать, машина — работать и если часть работы можно переложить на компилятор, то её следует переложить на компилятор.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

А без классов можно сразу правильно всё спроектировать? И рефакторить не надо, красота. Но почему-то никакого софта на голанге нет, а только микросервисы. А на расте написали парсер CSS, с полноценным движком уже обломались. Странно это всё.

bread
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)