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

там ассемблерное колдунство по поводу «откуда printf берет значения своих аргументов», int и float пишутся в разные регистры.

Все равно Python лучше Assembler’а, потому что на Ass’e нельзя YouTube написать

На питоне тем более нельзя. Посмотрю как ты кодек для пережимания видео на питоне напишешь.

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

О технологиях разработки.

Наскальные же ведь.
Вот в чём беда!

А у таковых и ЯП такие же.
Разработка схожа с хождением по краю оврага.

это иначе:

из

https://www.tuhs.org/cgi-bin/utree.pl?file=V2/lib/printf.c

printn(n,b) {
	extern putchar;
	auto a;

	if(a=n/b) /* assignment, not test for equality */
		printn(a, b); /* recursive */
	putchar(n%b + '0');
}

printf(fmt,x1,x2,x3,x4,x5,x6,x7,x8,x9)
	char fmt[];
	{
	extern printn, putchar;
	char s[];
	auto adx[], x, c;

	adx = &x1; /* argument pointer */
loop:
	while((c = *fmt++) != '%') {
		if(c == '\0')
			return;
		putchar(c);
	}
	x = *adx++;
	switch (c = *fmt++) {

	case 'd': /* decimal */
	case 'o': /* octal */
		if(x < 0) {
			x = -x;
			if(x<0) {  	/* is - infinity */
				if(c=='o')
					printf("100000");
				else
					printf("-32768");
				goto loop;
			}
			putchar('-');
		}
		printn(x, c=='o'?8:10);
		goto loop;

	case 'c': /* char */
		putchar(x);
		goto loop;

	case 's': /* string */
		s = x;
		while(c = *s++)
			putchar(c);
		goto loop;
	}
	putchar('%');
	fmt--;
	adx--;
	goto loop;
}

стек растёт навстречу индексации

это потом навертели комитетом всякий шлак varargов переусложняющий путём мнимой универсализации которая по факту течёт

Соглашения ABI в разных платформах по передаче аргументов - тот еще адок.

Для функций с переменным числом аргументов и/или аргументов произвольного типа хорошо бы отдельное соглашение о вызове, в которое компилятор автоматом вставляет RTTI. Но хрен там плавал, Сишечка - по своей природе это недоассемблер.

Сишечка - по своей природе это недоассемблер

Почему недо-, а не пере-?

Хороший вопрос…. Наверное потому, что «ни вашим, ни нашим», ни рыба, ни мясо.

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

А если же взять макроязык - посмотри на fasm, там на макросах можно такие чудеса делать, что сишечке и не снились.

фактически в яву добавили ещё один язык, в результате можно в одном файле на двух языках писать (как html+php в древнем вебе)

Там этот язык кастрированный, а вот шаблоны C++ это мощь! Львиная доля сложности именно в шаблонах. И это цена строгой статической типизации.

Шутка

Гм., Лисп в этом плане лучше.
С++ нервно грызёт ногти глядя на Лисп.

Между ними экзистенциальное различие. Лисповые макросы существуют для удобства программиста, а плюсовые шаблоны для удобства компилятора. Выбирая C++ ты становишься на путь раба машины. И все прочие жаборасты продолжают генеральную линию.

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

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

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

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

всё это факторы влияющие, но не определяющие.

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

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

тчк.

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

ну они как раз выходит заглянуть и не могут, раз стадию приятия не проходят: то что отсутствие статической типизации не мешает, да и на том же питоне все сервисы яндекса, а крупнейшие магазины типа pleer.ru полностью на php

вапще не вопрос, но на что-то большее замахиваться не советую

пейсбук и одноклассники с вкудахте самовыпилились. про вкудахте там интересно, когда он был уже мега-популярным его перевели на kphp в котором мало того что тупизации даже с боку нет, там еще и классы выкинули… и он все равно получился мертворожденным с приростом в скорости где-то в три раза, такой же профит будет и от замены питонов на статические тупизмы типа java/golang, а все почему? - да потому что мы большую часть времени тупо ожидаем сокет.

и тут еще указали мол на питоне нельзя напейсать драйвера и прочие конвертеры - можно, но не нужно… точно так же как на go, java или лишпе… и на дай бози на 1Ц

отсутствие статической типизации не мешает

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

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

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

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

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

а с какой они там типизацией - дело совершенно десятое.

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

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

не может. «а + б» - это про чо вапще?

если это вся программа, то опачки.

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

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

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

но как это отменяет тот факт, что мегажирные проекты написаны на языках которые якобы не подходят?

а с другой стороны на ней написано практически все. кроме того, что написано на ЯП, которые написаны на сишечке

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

компелятор [интерпретатора] питона уточню и тогда получится, что питон написан на питоне, как тот змей пожирающий сам себя, олицетворящий вечность

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

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

как это отменяет тот факт, что мегажирные проекты написаны на языках которые якобы не подходят?

да никак, а должно?

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

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

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

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

только это может быть ошибка

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

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

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

А это ещё лучше. В том же Хаскеле, если тип получился не тот, которого ожидаешь, значит надо искать в тексте ошибку. А если получился t -> a, значит в функции вечный цикл.

Математики еще как правило ужасные какие-то программисты.

Мой научник писал код сразу в обфусцированном виде и без отступов, но писал без ошибок. Поэтому это с какой стороны посмотреть. Если с точки зрения красоты кода то да.

Кода без ошибок не бывает.

У математиков бывает. Они так мыслят.

Мой научник писал код сразу в обфусцированном виде и без отступов

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

Потому что математики и железячники пишут программы не для людей, а для компьютера. Железячники иногда ещё и для конкретного компьютера.

В академической сфере иные подходы. Если вы опубликовали статью, то у вас получился артефакт, который: а) доделывать-переделывать не нужно; б) доделать-переделать невозможно, в крайнем случае можно опубликовать другую статью. К коду у них получается такое же отношение.

Так про вообще любой проект говна можно сказать.

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

Типом не укажешь, что функция принимает стороны треугольника

Стороны одного и того же треугольника? Почему нельзя передать сам треугольник?

Статическая типизация призвана решить несколько проблем
Уменьшить количество логических ошибок

Она её не то, чтобы как-то решит или уменьшит радикально.

Улучшить читаемость кода

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

Предоставить информацию о типах в рантайме для дальнейшего использования

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

Правда эти твои «большие проекты» уже лет 15 подпираются костылями из динамики с рефлексией. Ой, как так не ловко вышло. Тьфу на вас, лицемеры.

что из кода(без документации) вообще неочевидно какими могут и должны быть те или иные значения в аргументах методов

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

Помимо вышеперечисленного ты используешь

Сначала сам перестань заниматься демагогией а потом можешь выпендриваться на кого-то.

строго статически типизированная вообще падать не будет.

Толку от того, что она падать не будет. Ушло 10 миллионов не на тот счёт, ну зато не упала, молодец, решил вообще все проблемы сразу.

Статическая типизация не обязывает ловить все исключения.

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

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

Зато потом, когда скажут, что надо вот тут что-то поменять, закатываем глазки и начинаем выть про то, что это сложна, это не нужна, что добавить что-то в готовый проект, чего не было в тз - это 100х работы и что вообще иерархия на самом деле говно, делал её вася, которого давно уволили, что она не подходит под требования и всё надо переписать заново. Жалкое зрелище.

Разные подходы и системы типов - это попытки придумать всё более мощный язык описания этой неправильности. Начиная от простейшей типизации в Си и заканчивая всякими системами зависимых типов.

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

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

Не критичная ошибка, но неприятная.

Это вообще чудесно, требовать от языка, который не делает проверку на типы, чтобы он её делал. Один только вопрос, почему вы не переписывали его с 2.7 на жабку?

Ага! А какими, простите, тестами?

Ты должен быть железобетонно уверен, что при вызове у тебя вот эта функция create_key получила tuple. То есть проверка должна быть в функции или должна быть обёртка (возможно отключаемая) которая это делает. Если ты этого не проверяешь, то ты очень самоуверенный человек. В дт нет контрактов, нет типов, первое что ты должен сделать - контракты и типы. А там накодили как на ст язычке надеясь что всё будет ок. А с хера ли оно так должно быть? А потом ой, проблемы, дт не правильное, я член дверью прищемил. Видимо, потому что дебил, поэтому и прищемил.

Ну тут еще даунская философия пистона, что мол это всё проблемы вызывающего, ибо нешмогли, неосилили.

Та то не типы. У typescript'а два недостатка. Он не type и он не script/

Аннотации - годная штука.

У которых под капотом рефлексия и динамика. Которые не проверяются компилятором на этапе сборки и падают в рантайме с встратыми стектрейсами. Плохой ты адепт ст, негодный, позорный.

Ты чо-то попутал. Ноешь тут ты, тебе проверки типов компилятором мешают говно месить

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

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

Это для ст язычка нормально, ты припёрся писать код на другом языке, а пишешь всё как на диды фортране, лул.

когнитивных способностях

То у тебя проблемы, что раз в руках молоток, то всё кажется гвоздями.

У которых под капотом рефлексия и динамика.

давно жабскому компилятору нужна рефлексия?

Которые не проверяются компилятором на этапе сборки

аннотации целиком и полностью формируются при компиляции.

и падают в рантайме с встратыми стектрейсами.

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

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

Аннотации не делают, спринг делает. А сами по себе они нахер не нужны, если с ними ничего не делать.

Типом не укажешь, что функция принимает стороны треугольника

Стороны одного и того же треугольника? Почему нельзя передать сам треугольник?

А как проще выразить треугольник? Даже площадь посчитать можно, по формуле Герона.