Рыночек порешал что быстро пулять МВП выгоднее, чем следить за качеством.
А Пайтону можно обучить кого угодно и платить мало.
Программеры часто лишь притворяются умными, а на деле просто повторяют то, что сказали. Сказали софт скиллс - значит софт скиллс, сказали калчерал фит - значит фит, сказали "петон круто" - значит Питон круто.
Неужели бизнесу не нужен стабильный и хорошо работающий продукт? Возможно ли вообще найти такую компанию, в которой качество на первом месте?
Не всё делают на Питоне, внезапно.
Да и сам Питон неплох как инструмент для скриптинга и прототипирования.
Но не для разработки больших проектов.
Ну если кода не очень много и между модулями мало зависимостей, то поебать, и так сойдет.
А так согласен, я решил что больше никогда не буду писать на языке с динамической типизацией
Удваиваю.
>Что нам предлагает язык со статической типизацией? Он предлагает проверить валидность кода до запуска, чтобы когда мы задеплоим код в продакшен он гарантированно работал.
>Что предлагают нам языки с динамической типизацией?
Так запусти код до деплоя. Ты совсем глупенький?
Что значит запусти? Как минимум, проведи полное регрессионное тестирование всего функционала приложения.
>
>1) Весь код с вероятностью 90% будет переписан.
неправильно.
код УСПЕШНОГО предприятия о котором ты прочитаешь в книжке, с 90% вероятностью КОГДА-НИБУДЬ был переписан.
Про остальной код ничего не известно.
Скорее всего 90% кода просто умрет.
>2) Люди делают ошибки
Ну тут ты прав. Но тк 90% код умрет, это не важно.
>Что нам предлагает язык со статической типизацией? Он предлагает проверить валидность кода до запуска
Динамические языки создавали из соображений, что программисты будут понимать, что они делают. Но потребности рынка другие, хочется заставить кодить макак, которые не понимают что делают и суют один тип в другой. А так хоть какая-то защита.
Так даже в питоне пришли к тайп хинтам, писать без указаний типов на нем сейчас моветон.
Они созданы из соображений, что на них будут писать мелкие говноскрипты, а крупные проекты - никогда. А теперь на них пишут всё, где не жалко, если что-то наёбнется, лишь бы пользователи видели красивый UI.
Пришли к тайпхинтам, но из коробки не завезли даже варнинги.
Стаж?
Какой там стаж у него, первый-второй курс максимум.
Ну а зачем тогда?..
Тайпхинт это не статическая типизация, а декларация. Это контракт. А статическая типизация это техническое ограничение компилируемых языков. Тайпхинты позволяют большую гибкость, не только тип Any, то и тип вроде условного Union[str, int]. Причём инструменты для контроля проверят, что ты корректно обрабатываешь все возможные типы.
С помощью тайпинга в питоне ты можешь описать типы намного более гибко, чем при статической типизации.
А как же Crystal? Там умудрились скрестить подобие дактайпинга (вывод типов в зависимости от того, какие методы вызываешь) с полностью статической типизацией в компайл-тайме.
Истина!
Тупень, ты неправ. На динамикопараше любая программа больше мелкого скрипта превращается в неработающие помои, и главное сам программист этого не заметит, хоть трижды грамотный и знающий что делает.
Я лично видел как дообоебы делали свой собственный язык и писали на нем, а потом переделывали этот язык на строгую типизацию, что вскрыло целые блоки неработающего кода повсюду, не говоря уже о банальных сотнях багов.
В статически типизированных языках тебе очень часто нужны ещё всякие темплейты и дженерики с обмазкой кучей всяких ограничений. Либо же постоянный копипаст одного и того же кода для разных типов. Вот банальную хешмапу без дженериков и без динамической типизации как сделать нормально?
Дженерики и обобщенное программирование - это сложно, и для дизайна языка, и для компилятора, и для производительности, и для программиста, и для того, кто читает и поддерживает, и кто тестирует.
Копипаст кода - совсем очевидное зло.
А при динамической типизации вообще не заморачиваешься над такой проблемой, её просто нет.
Потому что динамическая тиизация экономит пространство кода. Ты меньше бойлерплейта пишешь.
Я питонист, и почти всегда код пишу на виме. И типа никогда не понимал зачем нужны ебаные идешки, это же глючная блоатвара. Но блин попробовал пописать на Джаве и понял что без ИДЕ просто больно. ОЧЕНЬ МНОГО КОДА.
А насчет ошибок в рантайме - вот тебе картинка кода на сишечке. Вот твой рантайм.
Ошибки вызываются не ДИНАМИЧЕСКОЙ типизацией, а СЛАБОЙ. В питоне сильная типизация, а значит хорошая.
Дополню:
Посмотри на свой оппик с языками. У тебя же прям видно как dynamic/strong это стабильные и выразительные языки, static и strong не такое говно как weak но страдающее от бойлерплейт кода, а внизу живет параша
>Неужели бизнесу не нужен стабильный и хорошо работающий продукт?
Есть приоритеты в диаграме цена-качество-скорость и у каждого они свои, делать инвойсы в банках на питухоне никто не будет, писать интернет магазин в котором каждый день что-то меняется, скидки, акции, промо и постоянно нужно что-то дорабатывать и переделывать будут как раз на руби-питухонах потому что быстро и дешево
>как раз на руби-питухонах
Почему ты боишься сказать PHP? Ты ведь знаешь правду?
Да, ну и пыха сюда со своими вордпресами и битриксами, которые полное говно
>хешмапу без дженериков и без динамической типизации
С помощью макроса "typeid()" получаешь внутренний номер типа (длинное целое число) и таскаешь его за собой, везде и всюду.
И тем не менее в петухоне ты не сможешь узнать что тв написал что-то неправильно, пока не запустишь/задеплоишь приложение. Это усложняет рефакторинг и добавление нового функционала, как и написано в ОП-посте.
А пример с сишкой хуёвый, это устаревшее говно мамонта со слабой (хоть и статической) типизацией.
> пока не запустишь
А не например когда? На этапе компиляции? Ну эт надо за компилируемые языки тогда допить, но у них свои сложности есть, не такой удобный воркфлоу
> А Пайтону можно обучить кого угодно и платить мало.
В Питоне уже лет 10 как появилась типизация. Доброе утро
А использовать широко когда начали?
>Что предлагают нам языки с динамической типизацией?
>Ничего
Неверный ответ. Дают скорость разработки
>Весь код с вероятностью 90% будет переписан
Или выброшен за ненадобностью. Такого кода на практике реально дохуя, например прототипы всякой херни или скрипты на пару-другую запусков. Ебаться с типизацией такого кода только тратить время почем зря
Вот только врать не надо, что она появилась. Или текст в комментарии "функция принимает int и возвращает int" - это тоже типизация?
Динамическая типизация это в первую очередь гибкость, и нужно это на сложных типах данных. Сравните работу с json/xml на динамических языках и на статических-компилируемых. Статическая типизация приводит к адовой иерахиии наследования в классах, горе интерфейсов, которые реально нафиг не нужны.
Гибкость это во вторую очередь, первая все-таки скорость разработки, для которой уже требуется гибкость. Но когда проект всерьёз и надолго, то скорость уже не настолько важна как качество, хуяк-хуяк и в продакшен уже не катит, надо действительно задуматься о типизации.
В чём проявляется слабая типизация в С++? Можно на примере каком-то, что там происходит и что должно произойти?
Типа можно определить функцию, которая принимает тип А, и потом передать в неё тип Б, и оно посыпется в рантайме?
Си, а не C++
Для си нормально вот такое, компилятор проглатывает и не выдаёт никаких предупреждений даже. Аналогично конверсия в чары, знаки-беззнаки и т.п. И конверсии указателей.
В плюсах сильнее. Этот пример g++ тоже без ворнингов компилирует, но указатели по-моему жёстче просят приведения. Хотя давно не писал на сях и плюсах, не помню уже.
>без ворнингов компилирует
Выдаст варнинг про имплисит преобразование дабла в инт.
> валидность кода до запуска, чтобы когда мы задеплоим код в продакшен он гарантированно работал.
это ты про агду братан. джябба/крестопараша никаких гарантий не дают either
> Если какая-то процедура вызывается очень редко, то мы не можем узнать что она написана неверно до того как она будет вызвана в рантайме. Зачем? Почему?
про юнит тесты ещё не проходили?
> Зачем в 2022 году лишать себя удобства?
kek
Они дают больше гарантий чем питон. Какие-то гарантии - лучше чем отсутствие гарантий.
Юзаешь в пистоне типизацию с mypy и получаешь такие же гарантии.
> Языки со статической типизацией дают больше гарантий работоспособности кода, чем языки с динамической типизацией
> РРРРЯЯЯ ТВОИ С++ И ЖАБА НИКАКИХ ГАРАНТИЙ НИДАЮТ
> Дают больше, чем питон
> А ТЫ ДОБАВЬ ПИТОНУ СТАТИЧЕСКУЮ ТИПИЗАЦИЮ
Шиз?
В интернете с тобой могут общаться разные люди
Каким образом это отменяет то, что шиз
Статическая типизация и аннотация типов это разные вещи для разных задач. А топят за статическую типизацию в ключе "это спасает от ошиобок" шизы.
> это спасает от ошиобок
Так и есть. Сейчас идёт слив динамикодрисни для любого проекта сложнее интернет-мазазина, даже в вебе все переходят на тайпскрипт.
Если у тебя ошибки вида в виде, что ты вместо целого числа суёшь указатель на строки, то у тебя какой-то мрак на проекте. Это ошибки уровня Smoke test.
Реальная ошибка типа может так выглядеть
void setDickSize(double dickLength, double dickWidth)
ты подставляешь туда сантиметры, а на самом деле надо в дюймах. Система бесится и работает некорректно. Но для компилятора и то, и другое это просто double.
Аналогично если ты местами параметны перепутаешь, компилятор не спасёт. А ведь это всё реальные ошибки.
Динамическая типизация не помогает начинающим программистам писать программы:
Many teachers of CS 1 (introductory programming) have switched to Python rather than C, C++, or Java. One reason is the belief that Python's interpreted nature plus simpler syntax and semantics ease a student's learning, but data supporting that belief is scarce. This paper addresses the question: Do Python learners struggle less than C++ learners? We analyzed student submissions on small coding exercises in CS 1 courses at 20 different universities, 10 courses using Python, and 11 using C++. Each course used either the Python or C++ version of an online textbook from one publisher, each book having 100+ small coding exercises, expected to take 2-5 minutes each. We considered 11 exercises whose Python and C++ versions were nearly identical and that appeared in various chapters. We defined struggle rate for exercises, where struggle means a student spent excessive time or attempts on an exercise. Based on that rate, we found the learning for Python was not eased; in fact, Python students had significantly higher struggle rates than C++ students (26% vs. 13%). Higher rates were seen even when considering only classes with no prerequisites, classes for majors only, or classes for non-majors only. We encourage the community to do further analyses, to help guide teachers when choosing a CS 1 language.
https://dl.acm.org/doi/10.1145/3159450.3160586
отсюда https://drmarkclewis.medium.com/the-struggle-of-dynamically-typed-languages-ef91a87164a1
Похоже начинающий динамико-программист обязан одновременно уметь писать тесты к своим хеллоу-ворлдам.
Many teachers of CS 1 (introductory programming) have switched to Python rather than C, C++, or Java. One reason is the belief that Python's interpreted nature plus simpler syntax and semantics ease a student's learning, but data supporting that belief is scarce. This paper addresses the question: Do Python learners struggle less than C++ learners? We analyzed student submissions on small coding exercises in CS 1 courses at 20 different universities, 10 courses using Python, and 11 using C++. Each course used either the Python or C++ version of an online textbook from one publisher, each book having 100+ small coding exercises, expected to take 2-5 minutes each. We considered 11 exercises whose Python and C++ versions were nearly identical and that appeared in various chapters. We defined struggle rate for exercises, where struggle means a student spent excessive time or attempts on an exercise. Based on that rate, we found the learning for Python was not eased; in fact, Python students had significantly higher struggle rates than C++ students (26% vs. 13%). Higher rates were seen even when considering only classes with no prerequisites, classes for majors only, or classes for non-majors only. We encourage the community to do further analyses, to help guide teachers when choosing a CS 1 language.
https://dl.acm.org/doi/10.1145/3159450.3160586
отсюда https://drmarkclewis.medium.com/the-struggle-of-dynamically-typed-languages-ef91a87164a1
Похоже начинающий динамико-программист обязан одновременно уметь писать тесты к своим хеллоу-ворлдам.
Некорректный тест:
>We considered 11 exercises whose Python and C++ versions were nearly identical and that appeared in various chapters.
Они сделали выборку на примерах, где год питона близок к коду на си. Но это значит, что они нашли примеры, для которых питон не предназначен и писать их на питоне не легче, а скорее тяжелее.
Пример, перемножение матриц. Если не использовать специальные библиотеки, которые осваивать ещё надо, то страглить на этой задаче ты на питоне будешь намного сильнее, чем на си. Потому что это low-level задача.
В то время как есть масса случаев, когда на питоне код будет на порядок проще и понятнее. Но эти примеры исключены из исследования.
> получаешь внутренний номер типа (длинное целое число)
То есть количество типов в программе ограничено разрядностью длинного целого?
длинное целое число это 64 бита, столько памяти в мире не существует
Тебе не хватит 18446744073709551616 типов?
Обратите внимание на то,как целых два человека не смогли ответить на простейший вопрос.
Все так, динамика практически всегда усложняет жизнь.
В этой цитате не сказано что они выбирали близкий код. Сказано что упражнения выбирались одинаковые из тех же глав по смыслу. Как ты вообще к такому странному выводу пришел?
Но если тебе интересно, я нагуглил какие конкретно задачи они выбрали (как в цитате - выбирали идентичные по смыслу). Пикрел отсюда http://www.cs.ucr.edu/~aedgcomb/presentations/SIGCSE18_PythonCpp_Vahid.pptx
Ты передергиваешь. Это не потому что они не смогли, или не хотели. Но потому что ответ уже известен всем читающим.
>Но если тебе интересно, я нагуглил какие конкретно задачи они выбрали (как в цитате - выбирали идентичные по смыслу)
Спасибо, посмотрел. Там действительно идентичные примеры по получаемому коду. Поэтому никакого преимущества питона нет.
Но что будет, когда начнётся работа с массивами? Что будет, когда начнётся работа со строками, скажем сложение строк? Форматирование строк? Разбиение строк на части, проверка вхождения и словари?
Код на C/C++ будет мягко говоря очень недружественным, тогда как на питоне он будет очевидным.
В исследовании же не про то чья стандартная библиотека удобней в использовании. Ну возьмет крестовик boost, будет так же как в питоне выглядеть снаружи.
По какой-то причине тут есть мнение по какой https://drmarkclewis.medium.com/the-struggle-of-dynamically-typed-languages-ef91a87164a1 разница по ошибкам в 2 раза.
Самый на мой взгляд интересный пример оттуда:
The worst student experience I’ve seen with this wasn’t in Python, it was in JavaScript. That student wrote context.fillstyle = 'red' in their code. They then spent hours trying to understand why nothing was being drawn. Print statements and the debugger indicated that everything was working properly. Eventually, they came to me to ask for help and I noticed that line. The student didn’t capitalize the “s”. It should be context.fillStyle. This student wasn’t a novice. He was a Junior who had gone through many previous programming classes. It was frustrating for him. How much more frustrating would it be for a true beginner.
Эти все статьи пропаганда какая-то. В си есть огромная масса моментов, на которых все постоянно спотыкаются. Классический пример:
double x = 1.0;
x += 1/2;
printf("%f", x);
Но реально жёстко начинается, когда надо работать со строками, с выделением-освобождением памяти, буферами и т.п. Насколько удобно в питоне работать со словарями, со списками и многим другим, и насколько это тяжеловесно в C++, а в си вообще невозможно.
Эти boost не помогут.
Реальные проблемы начинаются, когда надо работать с классами. Я хочу сделать обработчик каких-то разнообразных объектов, но надо, чтобы они наследовались от общего интерфейса. А они не отнаследованы. Хотя все методы нужные есть. И что? Возникает проблема на пустом месте.
>The student didn’t capitalize the “s”. It should be context.fillStyle.
Бывают тупые ошибки. На всех платформах. Которые можно часами-днями ловить, особенно если опыта нет.
Вот здесь, можно было бы сделать распечатку всего DOM элемента в консоль. И сразу же увидеть, что там теперь fill\Style и fillstyle. И сразу понятно, в чём ошибка.
Здесь, кстати, слабое место питона, там такое тоже часто бывает, но выглядит иначе. Можно легко опечататься и сделать присвоение не в локальную переменную fill_style, а в fil_style, например. И не заменить. Особенно легко при рефакторинге. Но это проблема не динамической типизации, а отсутствия декларации переменных. Это явный минус питона, вот тут бывали проблемы и бывают. В JS такого нет, там надо декларировать переменные.
Мы переписываем проект с флоу на ТС: т.е. изначальна у нас была какая-то типизация, но она по определенным причинам не подошла и теперь у нас другая типизация, более инновационная!
Прекол в том, что у флоу хуёво с тулзами, да и находится он в полузаброшенном состоянии. А ТС даёт нам замечательную интеграцию с идешками + это не только типизация, это ещё и возможности невиданные раннее фронтенд-розроботчиками.
Прекол в том, что у флоу хуёво с тулзами, да и находится он в полузаброшенном состоянии. А ТС даёт нам замечательную интеграцию с идешками + это не только типизация, это ещё и возможности невиданные раннее фронтенд-розроботчиками.
>В JS такого нет, там надо декларировать переменные.
Нет такого правила
Только в старых стандартах, в новых с "use strict" это ошибка, код не запустится.
Вот держи еще пропаганды от ученых. То же самое пишут. https://arxiv.org/pdf/1901.10220.pdf#subsection.2.1
Но комменты к статье совсем выводы не поддерживают.
>На динамикопараше любая программа больше мелкого скрипта превращается в неработающие помои, и главное сам программист этого не заметит, хоть трижды грамотный и знающий что делает.
И почему это так?
Чем больше гибкости, чем больше альтереатив тем лучше. Поэтому лучшими языками можно считать Typescript и С++, они позволяют максимально гибко описать тип, при этом в ТС это делается в одну строку и вся типизация это зиро кост абстракшн, потому что никак не влияет на рантайм в отличии от того же шарпа в котором каждый генерик или просто интерфейс бьет по перформансу.
Если ударяться в строгость и типизацию, то вместо написания кода ты начинаешь ублажать компилятор, что замедляет разработку и может привнести грязь в код.
>проведи полное регрессионное тестирование всего функционала приложения
А статически типизированный код ты типа тестировать не будешь.
Типа не придётся тестировать то, что может протестировать компилятор.
Ты будешь тестировать ошибки в логике, а не то что ты строку в метод передаёшь, хотя должен объект.
Вот типичный учебный код на си, из ньюфаг-треда. Судя по коду, задача упаковки по методу RLE, когда из исходой строки получается строка вида "символ" и "количество этих символов подряд".
Вопросы вам:
1) насколько в данном коде нужна статическая типизация, какие ошибки она предотвратит?
2) насколько проще понятнее будет тот же самый алгоритм на питоне, даже без использования каких-то специальных возможностей библиотек?
3) если девочку-студентку попросить не только ошибку с буфером исправить, но и адаптировать под под русские строки в кодировке utf-8, убедит ли её это, что ей надо заниматься проституцией?
Спасибо, отключаюсь, завтра прочитаю ваши ответы.
Мой первый язык был C, а так же параллельно мы проходили архитектуру ПУКА и у нас был asm но на эмуляторе процессора. И я за это рил благодарен шараге.
Дает тебе понимание что импорт это не магия, что память есть такая штука, что можно что-то по указателью передать и тд.
Тесты все равно писать, а с ними уже плевать какая типизация. Лучше уж динамика чтобы не пердолиться с интерфейсами и прочим синтаксическим мусором.
Со статикой на тесты уходит 5-10% времени, а с динамикой не меньше 98%.
Да ты заебал, мы сравниваем современные средства разработки, а не кал мамонта из 90х, на котором только прошивки микроконтроллеров пишут. Приведи такой же код на нормальном языке с сильной статической типизацией, тогда поговорим.
Обоснуй.
Никто, кроме разработчиков, не будет ставить гигабайты зависимостей для твоей пердобиблиотеки.
Это в которой нужно писать функцию как класс с call сигнатурой, чтобы в ней можно было дженерики использовать? Про декораторы вообще можно молчать.
Ты о чём? Для серверов пользователи ничего не знают о гигабайтах зависимостей, а для десктопа в дистрбутив всегда включают интерпретатор говна, все зависимости и запускатор, например, блендер тащит с собой петухон, пользователям не надо его устанавливать отдельно.
О том, что человек запустит пакетный менеджер, посмотрит на ебовую кучу зависимостей и откажется от установки. Только ты говномакака будешь ставить стряпая это говно, никому больше не нужное. Тебе легче писать код обмазываясь гигабайтами говна, а мне легче это говно просто не ставить и проходить мимо.
То, что нрaвится тебе в других, понрaвится и другим в тебе.
Не посмотрит. С зависимостями ебутся только разрабы, это их проблемы, у всех остальных всё уже установлено в дистрибутиве приложения, и устанавливать надо ровно одну зависимость - само приложение. Как на нормальных языках никто из пользователей не качает каждую DLL отдельно, точно так же в петухонах и жопаскриптпх никто из них не ставит интерпретатор и зависимости.
>Что нам предлагает язык со статической типизацией? Он предлагает проверить валидность кода до запуска, чтобы когда мы задеплоим код в продакшен он гарантированно работал.
>
перепутал с сильной типизацией
>Зачем существуют языки с динамической типизацией?
Затем что они дают преимущества в ряде случаев где описанные тобой требования не критичны, например на небольших скриптах, либо имеют исключительные особенности рантайма (BEAM)
Это всегда вопросы компромисса
По моему опыту на динамике забивают тесты чаще, чем на статике. У меня например есть знакомый фронт, который до года работы вообще не писал тестов. И пхпшник с примерно таким опытом.
В динамике обычно проекты такие, что можно забить хуй на надёжность. Тем более фронт, где нет бизнес-логики и постоянного хранилища данных, впрочем, даже там сейчас можно юзать TypeScript.
Я бы порекомендовал начинать не с Си, а вот с разбора "до костей" чего-то типа этого эмулятора. https://schweigi.github.io/assembler-simulator/
В плоть до написания студентами своих программ на такой штуке. Там есть все что есть в Си, кроме типов. И только потом уже к типам переходить. Начать с абстрактного описания что тип, это соглашение между программистом и компилятором о том как данные располагаются в памяти -- Тут нам и пригодился опыт эмулятора. Что тип так же может сказать о разрешенных способах оперирования над этими данными.
Чем мне не нравятся аргумент динамиков - они говорят что покроем дополнительными тестами, а потом говорят что статически типизированные языки слишком вербозные. Как первое слагается со вторым?
Вот хорошо придумали, язык в котором пошли еще дальше -- там можно указать не только точный тип, но еще и время жизни объекта, что позволяет понять отношения аргументов функции к возврату. В результате редко возникнет необходимость вообще заглядывать в тело. И не надо все это описывать словами в комментарии к функции. Тем более что каждый может написать коммент по-своему. Тут же задан конкретный строгий формат описания.
fn foo<'a, 'b>(a: &'a Person, b: &'b Person) -> &'b Data { // Видно что возвращается ссылка на данные из `b`
...
}
О, я тебя помню, ты ещё в си треде срал что выскооуровневое программирование для новичков от лукавого
хотя с твоими поинтами в данном посте солидарен
>перепутал с сильной типизацией
Иронично, что перепутал как раз ты
Возьмём в пример яркого представителя сильной типизации (питон) и такого же яркого представителя слабой типизации (C++)
Пик 1 будет запускаться всегда, до тех пор, пока ты не вызовешь функцию fn, а вот код на пик 2 выдаст ошибку времени компиляции.
И то, что C++ слабо типизированный, никак не мешает ему проверить валидность кода до выполнения.
На второй пикче рабочий код, сложение указателя и числа.
А ты деплоишь код не запуская его перед этим? Тогда ты е Лан и динамическая типизация тебе не поможет.
> Тогда ты еблан и статическая типизация тебе не поможет.
Слоуфикс.
>Для серверов пользователи ничего не знают о гигабайтах зависимостей
Как ты собрался клиентскую логику на сервере реализовывать?
Чтобы оттестировать фронт нужно как минимум писать интеграционные тесты, которые заёбисто писать и поддерживать. Юнит-тестами геттеров/сеттеров тут не отделаешься.
При чём тут клиент? Ты сколько зависимостей устанавливал, чтобы сидеть в интернете, кроме браузера? Ничего не работает без установки ноды, да? Пользователь не может просто зайти на сайт через браузер, он должен ещё и npm install сначала выполнить?
Cтатическая типизация никак не решает задачу переписывания кода. На любом яп с динамикой тебе придётся написать меньше кода, чем на статически типизированном яп. А значит, если мы часто его переписываем, то выйграш от меньшего числа строчек будет ещё более заметен. При этом статически типизированные яп слабо решают задачу валидности. Как правило, для этого используется тестирование, код ревью и т.д.
> На любом яп с динамикой тебе придётся написать меньше кода,
Вроде в треде уже отвечали, что рано или поздно ты начнешь делать то, что должен делать компилятор - проверять валидность приходящих параметров.
Считается, что у С++ более строгая типизация чем у питона.
На пиках ты показал отличие статической типизации (типизация времени компиляции) от динамической (типизации времени исполнения).
>Считается, что у С++ более строгая типизация чем у питона.
Кем считается?
>На пиках ты показал отличие статической типизации (типизация времени компиляции) от динамической (типизации времени исполнения).
Отлично, а теперь прочитай
С чего? Приведи пример.
https://github.com/django/django/blob/main/django/utils/text.py#L15
>Кем считается?
Создателем языка. https://www.youtube.com/watch?v=69edOm889V4&t=689s
И вообще, программистами.
>https://github.com/django/django/blob/main/django/utils/text.py#L15
Это не проверка на валидность, это попытка сделать универсальную функцию, чтобы макаки не заморачивались проверками сами. Это скорее исключение, чем правило.
>это попытка сделать универсальную функцию
Это тупое говно. Там разные типы и разный код, это должны быть разные функции. Нет никакого смысла делать одну функцию, но внутри разделенную проверками типа аргумента на разные, и выглядит как говнокод и работает медленно.
Это у статикопетушков это разные функции ибо компилятор неразрешил, а у нас нет. Мы еще и метапрограммировать можем правда редко когда нужно.
>не опроверг указанные недостатки
>ЗАТО МОЖЫМ ГАВНАКОДИТЬ)))
Что и требовалось доказать.
Опровергать нечего. Недостатки выдуманные, динамика сама по себе медленнее, но это не значит что она не нужна. Это всего лишь инструмент для определенных задач.
>Дженерики и обобщенное программирование - это сложно,
> и для дизайна языка, и для компилятора,
Чем сложно? Подставил тип и получил функцию/тип.
> и для производительности,
В крестах всё это на этапе компиляции просчитывается, так что никакой потери пирфоманса.
> и для программиста,
На самом деле шаблоны просты, это как в формулу число подставить.
> и для того, кто читает и поддерживает, и кто тестирует.
Это - тоже программисты.
А я ОПа поддвачну, многие твои ошибки статическая типизация отлавливает еще на стадии компиляции, а динамическая пропускает.
>динамика сама по себе медленнее
>поэтому я еще насру говнокодом напихав ненужных условий чтобы еще медленнее
Синдром разбитых окон в действии. Если твой язык параша, то и желания писать качественный код нет, хочется только гадить говнокодом на похуях. Вот и получается снежный ком, каловая масса нарастает экспотенциально.
> дженереки просто
> в плюсах
> просто подставить
Какой же ты клоун, прости Господи
мимо пишу инструментарий для плюсов
А boost::any эт не дженерик?
Я если шо не крестовый могу тупить
Это тип variant, хранит в себе все возможные значения разных типов (читай размер наибольшего типа + метаданные)
Хуйня иногда полезная, но имеет оверхед и нужно постоянно кастить
Скриптосвинья, вообще отличаешь язык от написанного на языке?
По видимому, концепция компьютера слишком сложна для быдла, что в 2022 выглядит как дурная шутка. Было огромной ошибкой допускать сброд до компьютеров.
>код УСПЕШНОГО предприятия о котором ты прочитаешь в книжке, с 90% вероятностью КОГДА-НИБУДЬ был переписан.
будет переписан и это убьет фирму
вот так то
>Вот банальную хешмапу без дженериков и без динамической типизации как сделать нормально?
в си обобщенные структуры данных делаются или через указатель на void или макросами
кстати, как всегда в подобных тредах, некоторые обсуждающие даже не понимают разницу между динамической типизацией и вывод типов
ну и прочие банальности
ну и прочие банальности
>Считается, что у С++ более строгая типизация чем у питона.
это не так хотя бы по той причине что с++ имеет полную обратную совместимость с си, а си язык со слабой типизацией
объем кода сокращает наличие вывода типа, если он реализуется в яп, а не то какая модель типизации языка - статическая или динамическая
Зачем срать бессмысленными сообщениями? Можешь ещё сгенерировать 100 рандомных символов и запостить.
Ок. И как hash code посчитать, зная, что у тебя тут ✱void?
Тащить ещё указать на функцию, которая получает ✱void и возвращает int?
Да, писать свою функцию для вычисления хешей и передавать указатель на неё.
Сап двач. Прошу вас Аноны помочь и поддержать на еду и продукты питания, прошу у тех, кто может помочь. Прошу на самом деле у всех. Мне это просто необходимо и нужно. В моей ситуации отчаяния я уже не могу стыдиться. Я уже пристыдён.
Прошу вас помочь кто способен снизойти до моей просьбы.
Карта: 2203 4101 8631 2924
Телеграмм: @Cry2222ch
Буду вам крайне обязан и признателен.
Че, пацаны, окамл?
это проблема воспринимающей стороны;
для собаки разговор двух людей будет тоже бессмысленным набором звуков
Смотря каких людей. Большинство людей дегенераты, для которых разговор это общение, а общение это обмен эмоциями которые собака прекрасно понимает.
Вот только собака именно ты.
Воистину мелкобуква - признак долбоёба.
1) Весь код с вероятностью 90% будет переписан.
2) Люди делают ошибки
Код всегда рефакторят, улучшают, добавляют новый функционал. Очень редко бывает так, что код написали, и забыли про него. Таким образом, одна из главных задач code envrionment - облегчить переписывание, добавление, рефакторинг.
И языки с динамической типизацией усложняют эту задачу.
Представьте, мы добавляем новый функционал в какое-нибудь приложение на питоне, эликсире, лиспе, похуй. Мы переписываем код, добавляем новые фичи, и конечно же делаем ошибки. Что нам предлагает язык со статической типизацией? Он предлагает проверить валидность кода до запуска, чтобы когда мы задеплоим код в продакшен он гарантированно работал.
Что предлагают нам языки с динамической типизацией? Ничего. Если какая-то процедура вызывается очень редко, то мы не можем узнать что она написана неверно до того как она будет вызвана в рантайме. Зачем? Почему?
Поясните, я реально не понимаю. Зачем в 2022 году лишать себя удобства? Неужели вы не хотите писать код, который будет валидирован ещё до стадии деплоя?