Обновить
-1
1.6

Специалист по теории типов USB-кабелей

Отправить сообщение

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

размер кодовой базы от такого действия удвоится (а то и утроится) - что никому не нужно.

А чё не удесятерится? Откуда здесь хотя бы даже удвоение?

тестировать "грязные" всё равно придётся

Зачем?

Пат

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

Ответ на мой вопрос о том, как блок кода может запросить упомянутую вами информацию, будет, или тезис о бектрейсах в исключениях снимаем?

то есть то, что в НЕКОТОРЫХ случаях работающий инструмент был не (совсем) применим

В каких «НЕКОТОРЫХ»? Это стандартный случай для работающего в проде (сиречь собранного с оптимизациями, и так далее) кода на C++.

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

В какую клетку, зачем загонять? Что это за фантазии проступают через текст?

просто сама пардигма с async/await ущербна, что поделать. есть лучшие парадигмы - stackful.

ИМХО количество мест, где stackless полезнее, особенно для уже имеющихся языков с имеющимися кодовыми базами, куда выше, чем где stackful полезнее.

в том и дело, что мне НЕ нужно собирать трейсы всегда и везде.

Ну так тем более, собирайте только там, где нужно. В чём вопрос-то?

Если откуда-то трейс не нужен — просто не записывайте его, точно так же, как вы сейчас его не записываете, если он вам не нужен.

интеграционный тест фиксирует внешнее поведение

  1. В одном конкретном случае из миллионов.

  2. На это надо потратить время, и ради чего?

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

прокликали - это и есть тесты. просто выполняете их вручную.

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

тесты решают реальные проблемы

Так какие проблемы они решают, кроме повышения зарплаты в потогонках через демонстрацию написанных строк кода, и прикрытия ЧСВ тимлидов, мастурбирующих на совершенно бессмсыленные метрики вроде code coverage?

Доказательством тому - статистика мест, где пользователи чаще делают ошибки.

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

В нормальном языке для начала было бы

add : (a b : Int) → {auto nonZero : b ≠ 0} → Int

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

Потом вы бы попытались доказать какие-нибудь свойства этой функции, вроде add a (add b c) = add (add a b) c, и у вас бы это не получилось, и вы бы подумали, что add делает какую-то ерунду (и правда, делает ерунду). Опа, и у вас нет вранья в именах.

А в тестах без типов бы вы написали add (-4) 2 = -2 и пошли бы дальше писать микросервисы для кэширования, не заметив, что делаете ерунду.

А что с ним нетипизируемого? Даже хаскель может.

так вот, нормальные интеграционные тесты помогают в обоих случаях

Бездоказательное утверждение.

смоделировали действия пользователя в тесте - поправили. тест сохранился на будущее.

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

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

как-то так это и работает

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

Тесты не-ну-жны и вредны.

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

затем, что это естественно для человека НЕ оперировать типами

1

И ему пофиг что считать. Типы становятся не важны.

2 [альтернатива: человек генерализирует до общего типа «считабельные объекты», а неспособные в генерализацию люди не осиливают счёт за пределами палочек]

аннотации нужны только компилятору

3

просишь ИИ переписать код без аннотаций в код с аннотациями и ИИ отлично с этим справляется

4

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

5

и рано или поздно так и будет

6

У Хаскеля проблема в том, что он уже 30 лет research language. С соответствующим культурным кодом. Хотя, как говорится, "вы 50 лет занимаетесь полупроводниками, пора бы уже к полным проводникам перейти!".

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

Некоторая ОС с девизом stable API is nonsense вполне успешно живёт что на мобильниках, что на серверах, так что не думаю, что проблема именно в этом.

оно текст пока оно нужно как текст.

Оно нужно как текст только при записи в логи. Делать текст до этого не нужно совершенно.

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

И рантайм раскрутит обратно все заинлайненные функции, и соотнесёт точку создания экзепшона в асинхронщине со всеми точками запуска всех асинхронных вещей?

Магия! Очень здорово! Можете меня научить делать эту магию на C++? Вот я пишу где-то

try
{
  doStuff();
}
catch (const std::exception& e)
{
  // *
}

Что мне надо написать вместо звёздочки, чтобы получить вот это вот всё? doStuff не знает, что и где будет вызвано, и вообще это может быть в глубине корутин.

Я, кстати, как раз на днях дебажил крэш из-за того, что некоторый awaitable в await_suspend подписывается на событие (возобновляющее соответствующую корутину) и ожидает, что await_resume будет вызвано только тогда, когда это событие произойдёт (и корутина будет возобновлена «симметрично» этому await_suspend), а это не так. Получить адекватный стектрейс там невозможно даже в отладочной сборке из-под gdb, потому что всё падает, будучи вызванным сильно из другого места.

Как в этом случае поможет ваша магия? Куда нажать?

заглянул я в Rust в ошибки - не увидел объектов, которые позволят мне собрать стектрейс. Вот, скажем в yaml парсере их нет.

Он возвращает характерную для парсера ошибку. Нужен стектрейс — вызовите backtrace() (или как его там в расте) при обработке (которая может свестись к одному вызову higher-order function, типа withBacktrace(parse(...))). Собирать стектрейсы всегда и везде — смерть для производительности.

Впрочем Вы постоянно этим грешите, что поделать.

Очередное бездоказательное утверждение на эмоциях с вашей стороны :]

При этом типы существуют и полностью выводятся автоматически.

Это потому что у вас rank-n-полиморфизма, GADT и прочего нет, а оно бывает полезно, мягко скажем.

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

При этом в ML не нужно никаких IO монадов.

Как будто монады — это что-то плохое.

Хочешь писать императивно с изменяемыми переменными и циклами?

Теряешь возможность локально рассуждать о коде.

Я занимался аудитом кода на окамле, это ад. Код на хаскеле по сравнению с ним — это небо и земля.

При этом чем это принципиально лучше

count n = do
  i ← newIORef 0
  whileM_ ((< n) <$> readIORef i) $ do
    print =<< readIORef i
    modifyIORef' i (+ 1)

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

count n = mapM_ print [0 .. n - 1]

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

Тогда как вы пишете эту функцию?

Вы в прошлый раз так и не ответили — зачем тестами код обкладывать? Тесты ограничивают свободу реализации, тесты придуманы менеджерами для контроля программистов, обложенный тестами код тяжелее менять (приходится обновлять тесты), тесты не ловят ошибки, кроме узких случаев, когда они попадают в ошибочное условие, и тесты занимают кучу времени. Пока вы пишете тесты, я уже вывел продукт в прод и он работает. А если не работает — как вы сами писали, напомните? А, во: ну ничего страшного, поправим и задеплоим снова, невелика беда.

теоретически

Почему?

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

Если честно, я довольно регулярно говорю, что для подавляющего большинства задач (и вакансий) в айти высшее образование и знание математики не нужны. Ну, потому что они правда не нужны, и можно пользоваться системой типов хаскеля без знания теории типов, и можно пользоваться этим вашим Array.reduce в жс без знания того, чем катаморфизмы отличаются от анаморфизмов, и почему reduce через map или filter выразить проблематично, а map или filter через reduce — без вопросов.

Но при этом каждый раз, когда я вижу такие заявления, как ваши, особенно в контексте воинственных постов «типы не нужны! ограничения и проверки для лохов! Настоящий Мужик программирует без защиты!», у меня возникают сомнения в собственной правоте. Может, математика на уровне хотя бы первого курса факультета прикладной математики (или хотя бы пара семестров матлога) правда нужна, чтобы мозги поставить и сформировать, даже если потом ты ей никогда не будешь [осознанно] пользоваться? Может, айтишечка с математическим цензом была бы более лучшим и приятным местом? Может, я просто не ценю то, что у меня есть?

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

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

Не понял. Из коммутативности плюса следует, что оба операнда абсолютно равноправны с точки зрения определения типов. Если вы запретили использовать первый, то и второй нелзья (потому что a + b = b + a, и, следовательно, ∀P. P(a + b) ⇒ P(b + a)).

Допустим в baz ошибка, которую мы поймали и обработали в foo.

А проблема в том, что источником ошибки может быть неверный код в функции bar. А когда пользователь смотрит на текст ошибки выброшенный функцией foo, он bar и baz не видит.

Не понял, мы ж ошибку поймали и обработали, что там ещё foo выбрасывает, что связано с bar и baz?

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

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

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

Так чё там как, в эрланге мутабельность-то есть? А то вы ключевой вопрос пропустили, а он ключевой потому, что:

  • вы говорите, что википедия — топ авторитет, и вся ваша дискуссия опирается на этот тезис

  • википедия говорит, что эрланг — это ФП

  • википедия говорит, что ФП — это чистота

  • известно, что в эрланге есть мутабельность (ETS и erlang:put/2 вместе с erlang:get/1)

Найти противоречие в этой системе утверждений (при некоторых дополнительных естественных вводных) смогёте?

Или можно взять ML (или ocaml) — википедия говорит, что он functional programming language, хотя там мутабельность огого (и, из моего опыта, разбираться в коде на окамле сильно неприятнее, чем на хаскеле).

"очевидный" - является аргументом

Нет, это констатация факта.

Исходный оратор сказал про лёгкость рефакторинга в ФП, я (практикующий ФП) понял, о чём он и какое определение ФП он имеет в виду, и девять из десяти (или 99 из 100) других практикующих ФП, поймут и/или уже поняли, о чём он (потому что те практикующие, что есть на хабре, уже правильно понимали аналогичные высказывания в других тредах, или сами их высказывали).

Эта ситуация подходит под семантику фразы «практикующим очевидно, что…».

Вы понимаете о чём говорите (но, увы, доказывать не собираетесь)

Эмпирический пример с type-driven-рефакторингом выше, где мне вообще не пришлось включать мозги, чтобы поправить код под изменившиеся семантические требования.

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

Да вот беда: от перекладывания JSON'ов есть реальная польза

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

а от Ваших типов её нет.

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

Видите ли, когда вы вот тут текст публикуете, то он тоже где-то в виде JSON'ов перекладывается туда-сюда.

Какая польза от опубликованного здесь мной (или вами) текста?

"подкатить к тёлочке" и коррекция сознания с заигрываниями/флиртом - это тоже часть этого. вы явно недооцениваете насколько широко гормоны и "прошивка это ф-ции" влияют на сознание..

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

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

Я говорю о том, что не всё ограничивается тем, что там якобы что-то мешает.

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

а у вас какая проблема? у вас узкий кругозор? физиологические проблемы? или "я обычный парень, не могу выделится из толпы"?

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

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

Если вам мешают моральные установки - рассмотрите их переоценку например...

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

но вот НЕТ

Ура, вы начинаете что-то понимать!

а вот то что мы обсуждаем, наш организм ВСЕГДА и у ВСЕХ имеет генетическую предрасположенность на эти действия и ограничиваеть его могут только мозги, которые с точки зрения физиологие думают чтото лишнее

А, не, ложная тревога.

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

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

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

а мои оппоненты постоянно пытаются что-нибудь мне да запретить: то ООП (который, кстати, инкарнация ваших замечательных типов)

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

то обобщённые алгоритмы (динамическую типизацию)

Что? Как связаны обобщённые алгоритмы и динамическая типизация?

Информация

В рейтинге
1 600-й
Зарегистрирован
Активность