Size: a a a

2020 May 15

AV

Alexander Vershilov in fprog_spb
источник

AV

Alexander Vershilov in fprog_spb
Ну и в твиттер формате гуглится
источник

AV

Alexander Vershilov in fprog_spb
Там кажется повеселее читалось
источник

n

neFormal in fprog_spb
Если допустимо уронить инстанс или кинуть ошибку в корень, то пофиг. Динамика тут только проще интерфейс даёт. В статике посложнее будет
источник

AV

Alexander Vershilov in fprog_spb
Возможно
источник

АГ

Александр Гранин... in fprog_spb
BTW, я не очень понимаю аргумент "но мир же принципиально нетипизирован!" или "но модели данных же гетерогенные", или даже "но что если кто-то изменит модель данных?". Если мир меняется, то и код тоже должен меняться. Разработка - это не "написал и забыл", хотя можно дизайнить системы так, чтобы они были future proof, - не ломались от каких-то непредвиденных колебаний во внешнем мире. Однако невозможно предугадать все риски, и нет смысла делать защитное программирование, когда программа рассчитывает на данные А, Б, а еще на то, что появится Вася и пришлет какую-нибудь ерунду.
источник

AV

Alexander Vershilov in fprog_spb
Я динамический язык воспринимаю как большой фреймворк и как с любым большим фреймворком, если твоя задача на него хорошо ложится, то он работает хорошо. Если не ложится - не очень. Причем тут проблема может быть как в задаче, так и в программисте
источник

n

neFormal in fprog_spb
Александр Гранин
BTW, я не очень понимаю аргумент "но мир же принципиально нетипизирован!" или "но модели данных же гетерогенные", или даже "но что если кто-то изменит модель данных?". Если мир меняется, то и код тоже должен меняться. Разработка - это не "написал и забыл", хотя можно дизайнить системы так, чтобы они были future proof, - не ломались от каких-то непредвиденных колебаний во внешнем мире. Однако невозможно предугадать все риски, и нет смысла делать защитное программирование, когда программа рассчитывает на данные А, Б, а еще на то, что появится Вася и пришлет какую-нибудь ерунду.
Это вопрос исключительно цены в глазах исполнителя.
источник

AV

Alexander Vershilov in fprog_spb
Склеивать сервисы отдела выдачи кредитов и отдела страхования, которые выдали тебе закрытые CDN c кучей легаси, багов, плохой документацией и разными струткрурами данных, наверное на кложе приятнее
источник

PS

Peter Sovietov in fprog_spb
Kakadu
В одном умном видео говорилось, что провоцировать человека на изучение новой технологии нужно в тот момент, когда он наступил на проблемы текущей, провел 2 дня в отладке и очень зол на свою работу. Если же у него и так всё шустро работает, он не допускает ошибок, и т.д., то он нафиг не захочет учить чего-то новое
У меня была очень давняя история — для одного спецпроцессора я написал супероптимизатор и пошел хвастаться коллегам. Все были впечатлены, кроме одного очень опытного ассемблерщика (кстати, надо ли говорить, что языки ассемблера иногда отличаются друг от друга не меньше, чем Haskell от Clojure?). Это был очень хороший низкоуровневый алгоритмист и он искренне не понимал, зачем автоматизировать то, что он и так легко придумывает. Я это к тому, что люди опытные могут в рутине и в необязательном преодолении препятствий находить для себя особое удовольствие. Да ту же историю с фон Нейманом вспомнить, хотя бы!
источник

AS

Alex Shipilov in fprog_spb
Alexander Vershilov
Такие штуки не нужны, только если у функций вообще нет никаких контрактов, я вижу целых 2 кейса для этого:
1. вы передаёте сообщения из пункта А в пункт Б, например перекладываете всё что придёт в базу
2. вы даёте пользователю доступ к анализу документов
У меня задача в основном, дернуть апи, получить json, выбрать оттуда нужные поля, скомпоновать в мапку, положить в базу, по запросу возвращать
источник

AV

Alexander Vershilov in fprog_spb
Тебе (или тому кто попроси) важно, что в мапке или нет?
источник

AV

Alexander Vershilov in fprog_spb
Есть ли у него какие-либо ожидания
источник

K

Kakadu in fprog_spb
Peter Sovietov
У меня была очень давняя история — для одного спецпроцессора я написал супероптимизатор и пошел хвастаться коллегам. Все были впечатлены, кроме одного очень опытного ассемблерщика (кстати, надо ли говорить, что языки ассемблера иногда отличаются друг от друга не меньше, чем Haskell от Clojure?). Это был очень хороший низкоуровневый алгоритмист и он искренне не понимал, зачем автоматизировать то, что он и так легко придумывает. Я это к тому, что люди опытные могут в рутине и в необязательном преодолении препятствий находить для себя особое удовольствие. Да ту же историю с фон Нейманом вспомнить, хотя бы!
А что за история по фон Ноймана?
источник

PS

Peter Sovietov in fprog_spb
Kakadu
А что за история по фон Ноймана?
John von Neumann, when he first heard about FORTRAN in 1954, was unimpressed and asked "why would you want more than machine language?" One of von Neumann's students at Princeton recalled that graduate students were being used to hand assemble programs into binary for their early machine. This student took time out to build an assembler, but when von Neumann found out about it he was very angry, saying that it was a waste of a valuable scientific computing instrument to use it to do clerical work.
источник

АГ

Александр Гранин... in fprog_spb
Типы очень важны и нужны при командной разработке. Это единственный путь договориться с коллегами о контрактах
источник

YS

Yan Shkurinskiy in fprog_spb
Александр Гранин
Типы очень важны и нужны при командной разработке. Это единственный путь договориться с коллегами о контрактах
Ну, будем честны - не единственный
источник

AV

Alexander Vershilov in fprog_spb
Ну не едиственный
источник

YS

Yan Shkurinskiy in fprog_spb
Можно просто пожать руки, предварительно плюнув в ладонь
источник

YS

Yan Shkurinskiy in fprog_spb
Кому-то этого хватает
источник