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

вас не смущает в данной цитате, что речь в нехороших тонах идет о си, а не с++? а я говорю о с++.

А тебя не смущает, что С++ является почти полным надмножеством С (с некоторыми оговорками) и все недостатки С в полной мере относятся и к С++? Расскажи, как ты пишешь на С++ без сишной слабой типизации, без сишных char, int и т.д., без сишных неявных преобразований типов и т.д. Очень интересно послушать.

Очень помогает от тупых распространены ошибок типа

А это следствие убогости подобных язычков, где мысль давно остановилась на функции/методе с передачей аргумента + оопэ тупичок и дальше пойти не в состоянии. Какие-то более сложные абстракции - это вообще забей. Банальный dependency injection - это уже большой шаг в сторону от этого всего и там тебя под капотом ждёт всё то, что делают динамические язычки - доступ по названию поля/метода/класса, проверка его наличия, падения в рантайме и никакое иде тебе никогда не объяснит, где ты поставил аннотацию не там. И, к сожалению, это всё, что в принципе жабакококомунити может из себя выдавать. Спринг - это жирная коричневая точка на таких вот ст недоязычках и живой монумент тупиковости их идей.

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

обычный код на джанге и тп

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

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

это в питоновском проекте такие страсти? И как отсутствие типизации помогает тебе это разгребать?

рассказывал уже. смотрите выше.

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

Python не приходилось использовать в разработке (PHP, Perl, JavaScript).
Интересно конечно узнать о том, насколько статическая типизация эффективней динамической в Python.

отсутствие типизации

Кек, ну ты и адепт. Всё, что не ст - отсутствие типизации.

как

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

В питоне строгая динамическая.

Ява то тут причем? Ничего не писал про яву

Тогда о чём тред?

на каком этапе?

Внезапно, временем доступа. Можно вполне опозориться с хешманой слив жс'у.

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

ну ты щас repl описал, а не динамическую типизацию.

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

Ну, сделай репл со статической.

На каком этапе что?

СТ vs ДТ срач.

СТ vs ДТ срач.

Ждем к новому году тему «интерпретируемые vs компилируемые языки, что лучше?».

Дерефаем b как A, а у A уже функция есть, всё логично же.

Писать на дт языках намного сложнее, чем на ст.

Писать на дт языках качественный код намного сложнее, чем на ст.

Ровно по тем же причинам, почему качественно писать на ассемблере сложнее, чем на ЯВУ. Нет машинного контроля за корректностью программы.

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

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

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

Так в любом ЯП система типов что-то неспособна выразить.

Если брать Haskell, там практически невозможно реализовать что-то вроде

(-> a b ... b c) (Listof a) (Listof b) ... b (Listof c)
#<procedure:map>

То есть функция, которая принимает функцию от N аргументов и N списков и возвращает список результатов применения этой функции к элементам списков. В Haskell придётся писать отдельно map, ,ap2, map3, … (которые называбтся zipWith2, zipWith3, …).

Если брать даже Typed Racket, на котором этот самый обобщённый map типизируется, то даже в нём проблематично типизировать, например, продолжения.

ты там фетчишь что-то (жсон, как понимаю) из сети и гуляешь в репле по полям в начале разработки, или когда все полетело к чертям и надо разбираться «чево каво»?

Да поэтому самый популярный сайт для погромистов stackoverflow называется, а не traceback most recent call last

Здесь нет имплицитного вызова. Здесь

fun(&b) = fun(b.deref()) 

Выше указано, что deref всегда возвращает &A. fun хочет именно &A. Всё сходится.

Как я писал выше, глядя на

fn fun(a: &A) -> () { ... }
...
fun(&b)

достоверно можно утверждать, что &b имеет тип &A. Для C++ это не так. Тип может быть любым, для которого компилятор найдёт преобразование.

Ну, сделай репл со статической.

Есть GHCi. И у Typed Racket тоже REPL есть.

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

fun(&b) = fun(b.deref())

И чем это отличается от

fun(b) = fun(b.operator_A())

И у Typed Racket тоже REPL есть.

Так это тот же лисп. Он же динамический.

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

Она ничем не лучше и не хуже Ады, например.

Так даже в жабке он есть. Толку только там от него.

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

fun(b) = fun(b.operator_A())

Тем, что b не может быть b.operator_A(). Более того, в C++ может быть

f(b); // здесь он b.operator_A()
g(b); // здесь он b.operator_С()

Это и есть нестрогая типизация. Такая же в 1С, например. СокрЛП(А) работает для любого А, который можно привести к строковому типу.

Это деталь реализации.

На всех этапах.

И какая разница тогда? В ст я не могу делать key[value] для объекта, а в дт могу в любом случае. В ст мне надо думать, когда там юзать мапу, а когда нет, а в дт - не надо, когда придут данные говна, тогда и заюзается. Прошу заметить, что срач уже перетёк в разряд управление кучей руками vs аллокатор.

Ты вроде уже сам с собой разговариваешь.

Ага, по классике перевести игру на свое поле и задавить на нем соперника. За сим откланиваюсь

Бессмысленнее ts'а вообще ничего не видел. Такое говно надо постараться еще сделать.

Ок, ты говоришь, «не всем надо обходить поля объекта»?

Вот. Типичное решение для ст'ников - пили обёртку. А потом выходит так, что код на жс ест меньше по памяти и работает быстрее, кек.

Я не вывезу больше трех страниц.

Лисп. Но статический. С нормальными полиморфными типами.

Так было же. Очень быстро перешло в срач, что считать компилируемым.

Немного не по теме треда.

Число и дата дробилки неплохо помогают понять «вес» использования каждого оператора и управляющих операторов.

Пост о том, что бывают «big алгоритмы» и «ширпортреб».
И они весьма разнятся.

Python - для «ширпортреба».

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

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

P. S. Никто не мешает в ст добавить тип ИзменяемыйОбъект с методами «добавить поле» и «удалить поле». В 1С есть тип «Структура» именно с такой семантикой. И тип «ТаблицаЗначений», у которой поля строки определяются списком колонок этой таблицы.