LINUX.ORG.RU

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

 ,


1

4

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

★★★★★

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

ритуал public static void - это желание обойтись без вложений в реальное образование что кодеров, что мэнэджерья

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

дифузировать раннее «взаимно независимые» детали реализации для выгребания последних процентов(а по факту порядков) производительности

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

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

ну скажем взлёт(местами) «rpa» ровно потому и происходит, что пользовательские интерфейсы настолько закаменели, что РОБОТники настолько по одним и тем же траекториям ходют что исходные интерфейсы излишне универсальны -

в том и прикол что при спаивании современных по всем правилам декомпозированных ограждённых инкапсулированных и прочая прочая систем которые всё равно оказываются от разных изготовителей(даже если брэнд один) обнаруживается два порядка резерва - ибо Сэр Синклер а уж Сэры что arm

qulinxao3
()
Ответ на: комментарий от Nervous

а это риальне - вопрос на каком моменте происходит этап «компиляции» проекта

если компоненты реально не чёрные ящики - а сами есть реальне типовые узлы

то при «правильной компиляции» из проекта получается монолит -пример идеи golang в части всё нужное бинарится всё не нужное ненужно

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

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