Как стать автором
Обновить
16
0
Евгений Ромашкан @EvgeniiR

Software Engineer

Отправить сообщение
И я ещё раз напоминаю о существовании бирюзовых организаций, почитайте. Например, кейс Valve — там бирюзовый принцип работает для всех, а не только для программистов, и они как-то справляются с ответами на ваши вопросы. Почитайте про внутреннее устройство таких компаний.
Особенно примечательный пример, в контексте возможных разногласий о которых пишет 0xd34df00d, учитывая что в итоге в «бирюзовой» valve внутри появились неявные иерархии, команды старичков, и проблемы с той самой оценкой сотрудников другими сотрудниками, а рейтинг компании от сотрудников на glassdoor упал уже до 3.3, с тезисами «Feels like a disorganized trap» и «Highly toxic work environment», «Advertising flat structure when there actually isn't».
У этого языка еще не накопилось достаточно опыта использования имеющегося синтаксиса ООП, чтобы принимать решения ломать стандарты, десятилетиями устоявшиеся в Java, C#.
Java стандарты — последняя вещь, на которую стоит ориентироваться, когда речь идёт о выразительности языка или грамотных подходах к проектированию.
Асинхронность хотя бы как в JavaScript
yield есть, а экосистема — ну что поделать, не нужна среднестатистическому пхп разработчику асинхронность, вот и не популярно.

Дженерики a.k.a. шаблоны
Есть в psalm — psalm.dev/docs/annotating_code/templated_annotations

Больше возможностей для типизации, например, возможность указать, что аргумент является массивам с элементами такого-то типа
Также есть в psalm — psalm.dev/docs/annotating_code/type_syntax/array_types
От тайпхинтов самих по себе без каких-либо статических гарантий пользы нет +- никакой
Вы путаете деление юнит-тесты/интеграционные тесты (что на самом деле вопрос про размер сайд-эффектов) и вопрос «код вперёд или тесты вперёд».

«Тесты вперёд»(test first) и TDD это разные вещи, и TDD про написание конкретно юнит-тестов.
По-моему, обобщением занимается именно автор — экстраполирует свой однобокий опыт с JS-разработкой и противопоставляет ей TS в качестве панацеи,
Автор таки, насколько известно из его статей, не js- и не ts- разработчик, хотя наверняка имеет опыт написания кода на них.

И статья эта вовсе не про js/ts, а как раз про два разных подхода в целом. JS тут скорее в роли наиболее близкого большей доле читателей антагониста.
За это спасибо и ограничениям самого ТС, и качеству типов сторонних библиотек.

То есть вы пишете об ограничениях одного конкретного используемого вами языка и его экосистеме, но тем не менее обощаете свои выводы на всех.
Если вы требуете тайпхинтинг во всей кодовой базе и всех библиотеках, то вы внезапно получаете статически типизированный язык.
Разве для этого не нужны какие-то гарантии от компилятора, что тайп хинты корректные?
Тайп хинтинг в том же php это просто добавление проверок в рантайме во все места, где указан тайпхинт, их корректность до выполнения никак не гарантируется, программа по прежнему падает только в рантайме, плюс всякие неразрешимые с т.з. системы типов преобразования/операции допускаются.
Так описывать типы — это же очень круто и стильно, тут весь пост про это.
Видимо мы о разных постах, особенно учитывая что автор предпочитает таки f# а не джаву.

Впрочем, если игнорировать суть, цепляться за слова, личности, аппелировать к другим языкам, решениям, не разбираясь как и для чего они были приняты, и увиливать от ответов это вся ваша аргументация, диалог смысла не имеет.
Программы на современных хипстерских статических языках (Go, Swift, Rust, в какой-то мере C#) куда больше напоминают Питон, чем С++.
Все языки что вы перечислили имеют статическую типизацию. Автовывод типов не делает язык динамическим, а плюсы образцом надежной/выразительной системы типов вовсе не являются.

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

И о том, что происходит конвергенция динамических и статических языков — в новые динамические, например
Не ясно как вы пришли к таким выводам, учитывая что все приведенные вами новые языки статически типизированные.
Оставьте деда в покое, у него TDD головного мозга.
И дед прав!

Не считаю так.

Там в самом конце статьи написано: «So says this old C++ programmer», в этом вся суть.
То что он пишет про качественный код это выводы сделанные им ещё лет 30 назад(хорошие выводы, ничего против), и их совершенствование да преобразования, в том числе чтобы их продавать побольше.
В текущем топике я на него полагаться бы не стал.

Утверждать что 100% покрытие тестами гарантирует что-либо как это может делать типизация — глупо.
Как пример хотя бы sqlite покрытый тестами 5 раз по 100%.
Еще раз: в скриптовых языках дистрибуция происходит на более раннем этапе чем обработка в среде исполнения.

Это никак не оправдывает неудобство от динамики и не делает её удобнее.

И я до сих пор их не вижу. «будет костылём», «рядом не стоят» — это все ваши эмоции.

Тогда попробуйте наконец прочитать мой предыдущий комментарий полностью.

А то что вы ставите статическую типизацию в один ряд с необязательными линтерами для js'а говорит лишь о том что вы не понимаете о чём пишете.

Поэтому проверка типов и должна производится отдельно, ДО компиляции. Если говорить о веб-платформе — то там еще и большая сегментация самих сред, что добавляет

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

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

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

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

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

Нет, это вздор хотя бы потому что мы говорим о разработчиках которые уже выбрали динамические языки. Линтеры и подсказки IDE это не подобные инструменты.

Ваши личные эмоции тут не аргумент.

Аргументы вы почему то решили «не заметить».
Ну вот как-то в PHP нормально относятся к phpdoc аннотациям типа.
phpdoc-аннотации типов в типичном пхп проекте это аннотацими сгенерированные phpstorm'ом которые в лучшем случае не забывают иногда поправлять.

Используют хотя бы статический анализ на уровне psalm/phpstan еденицы.
И язык тут — дело второстепенное, с тем-же JS можно прекрасно юзать статический анализ и тайп-линтинг с аннотациями в JSDoc. Типы — это вопрос архитектурный и пылать праведным хейтом стоит, разве что, в адрес плохой архитектуры но никак не стека и самой возможности использовать динамическую типизацию.

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

Я не думаю, что оно настанет в обозримом будущем.

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

К слову, нужен ли какой-то бэкграунд в математике/теории типов чтобы более-менее продуктивно писать на каком-нибудь Идрисе, или можно всё покрыть документацией(или книжкой по языку)?
Вы путаете строгую/слабую типизацию со статической/динамической.

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

Я ни один скрипт не стану писать без типов, если его будет кто-то читать(а его будет, кроме единственного случая, когда я хочу что-то сделать и удалить на локальной машине). В случае PHP хотя бы psalm(костыль, конечно, но что есть).

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

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

Spoiler header
Ну и вообще, есть языки со статической типизацией, с весьма хорошим автовыводом типов, таким что большую часть их объявлений можно стереть. Спойлер — так никто не делает, ибо незачем.
Интересно, сможем ли мы зайти ещё дальше, и повсеместно взяться за формальную верификацию программного обеспечения?

Сможем, когда придёт время:
«Formal methods will never have a significant impact until they can be used by people that don’t understand them» (с) Types And Programming Languages
Композиция? А в шарпе для неё есть такой же сахар, как в го, когда компилятор сам ищет, к какому классу относится метод?

Лучше. В C# есть делегаты и явные интерфейсы.

Да и вообще голанг весьма бедный язык на «сахар».
Что еще нужно сделать мелкософту чтобы C# не считали завязанным на платформу… эхх

Если вот это: github.com/dotnet/wpf/issues/48 сделают — сразу начну считать его лучшим кроссплатформенным языком для десктоп-приложений :)
Судя по всему в следующем раунде мы так же увидим swoft (фреймворк на основе swoole). Его код уже присутствует в бенчмарке. Будем ждать пересчёта. Будет на кого ориентироваться.

Стоит упомянуть, что Swoft/Swoole асинхронные, в отличие от, так что в реальных приложениях при должном использовании они всегда будут быстрее.

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность