ок) вы ведь уже объяснили зачем это было нужно «картам», и почему появился YM. вы классные (мм, история enb vs bem make вообще эпична). ни кто не сомневается, что ради правильной цели, у вашей команды вместе с Яндексом, хватит ресурсов и на то, чтобы переписать пол гитхаба как вам захочется, если вдруг. я серьезно.
тут уже несколько раз объясняли, что нарушение абстракции это таскать лоадер в зависимостях модуля, т.к. система загрузки модулей должна абстрагировать код от этого. нарушение абстракции это смешивание логики загрузки кода, конструирования и разруливания порядка инстанцирования объектов в одну кучу. но, как оказывается, в некоторых случаях из подобных фокусов можно извлечь определенную практическую пользу. за что еще раз вам респект.
а 'promise!anyName', это не два отдельных слова, а «такое-вот-имя-модуля-целиком» — синтаксический компромисс в именовании, благодаря которому модули могут резовлить реализацию разными способами. «tpl!name», «ym!name» и т.п. главное, что результат для клиента не отличим. так что тут как раз все правильно.
вообще. на мой взгляд, основная ценность систем подобного уровня не в наличии какой-либо «клиллер-фичи», а в возможности интеграции как можно большего количества различных решений между собой наименьшей кровью. поэтому, в целом, соглашения рулят.
вы несомненно молодцы, что сумели стандартизировать этот момент внутри Яндекса. CommonJS/AMD решают схожую задачу, но не в масштабах отдельной компании, а для всего мира. это на порядок сложнее, отсюда больше компромиссов. зря вы ставите в один ранг с CommonJS и AMD, противопоставляя YM — это лишь сбивает с толку и провоцирует бесполезный флейм.
вероятность встретить за пределами яндексных инкубаторов, на открытом воздухе, код, завернутый в YM, такая же как увидеть в лесу динозавра. и год тому назад, когда он заопенсорсился, и сейчас. как только я перестал заниматься околояндексной разработкой, в коде не осталось практически ни чего из этого великолепия. потому, что во всем остальном мире — другие соглашения. за пределами Яндекса YM — лишь элегантное решение частной задачи, коих тысячи. как видите есть альтернативы.
CommonJS и AMD это общепринятые вещи — в смысле использования в проектах, рецептов и инструментов для комбинирования с другими технологиями, поддержки, документации. YM как еще один стандарт — не нужен (имхо). в этом смысле, было бы гораздо полезнее, если бы вы делились с сообществом своими революционными идеями, не в виде альтернатив (это лишь все усложняет), а коммитами в общепринятые технологии.
аналогично, MessagingService и NotificationsSerivce (в примере из статьи), можно тестировать отдельно, а для метода SendMessage зафигачить интеграционный тест. однако лирический герой ратует за то, чтобы непременно тестить освещение не зависимо от реализации конкретных компонентов, для чего наваял DI с конструктором и пачкой новых интерфейсов "… не обусловленных ни какой семантикой".
это так же гибко и правильно, как если в квартире каждый светильник включать через вилку-розетку. и теперь весь сыр-бор вокруг подключения потолочной люстры — когда тестировщикам ужас как хочется заместо неё втыкать свои имитаторы, а хозяевам нафиг не нужно что-то вместо неё подключать и вообще портит интерьер. :)
VIM c ctags (пусть wrangler если это erlang) решают задачу в 95% случаев. остальные 95% кода все равно лапками проверять. не понимаю с чем вы не согласны.
я хотел сказать, что в реальных проектах, возможности языка используются на полную катушку — со всяким мета-программированием, и прочей ерундой, которая делает язык именно таким, за что мы его и выбираем, а статический анализ — лишь приятной примочкой (типа на PEP8 чекать). автоматический рефакторинг в каких-то частных случаях тоже возможен, но поменять мегабайт индуистического кода неглядя, как для Java — это фантастика (или безумие).
угу. только при чем тут Java, если статья конкретно про Erlang?
в этом цирке «Станый Метод» может быть запросто результатом чего-то в роде string:concat(X, Y), или того хуже. это совсем другой мир, где от AST толку чуть. распоследние тулзы пытаются даже код выполнять, но у и этого подхода есть принципиальные ограничения.
по-моему зря этот Джо сюда Java прилепил, она совсем из другой оперы, и отсюда холивар весь.
кто-то может привести пример инструментария для языков с _динамической_ типизацией где всякие go to definition и find all references, дают сколь-нибудь существенное отличие в надежности результата, по сравнению с «тупым грепом»?
мне вот не попадались еще. поэтому да, на первый план, так или иначе, выходит удобство редактирования и «vim» — наше всё. остальные трюки приходится делать лапками и внимательно проверять глазками.
Спасибо за интересную драму про менеджера Егора. Я искренне ему сопереживал на протяжении всей статьи, в надежде, что все закончится хорошо. Единственная досада, что почти детективная интрига с отчетами, обозначенная в завязке, осталась так и не раскрытой, а заявленный алгоритм описывается на примере каких-то совершенно иных, не связанных между собой ситуаций.
Поэтому сюжет, в целом, показался каким-то не логичным, и быть может надуманным, даже. С первого взгляда, такая непоследовательность выглядит либо как недоработка сценария (если это литература), либо как притягивание фактов за уши к теории (если речь про науку). Если только оставлять сюжетную интригу не раскрытой это какая-то специальная особенность маркетинговой публицистики. В общем, не понятно, стоит-ли того же ожидать на ваших курсах, или в отличие от статьи, там все четко разложено по полочкам?
нестандартная реализация создает лишние сложности и сильно ограничивает кейсы их применимости (https://github.com/domenic/chai-as-promised/issues/1, например). поэтому — да, кривой. программисты с исторического факультета могут искать применение, но с практической точки зрения, чем раньше отправят в кунсткамеру это недоразумение, тем лучше — на сегодняшний день стандарт это реальность.
по примерам не понятно, как считать площадь фигур, в итоге, и каким образом преобразованный код иллюстрирует LSP, если ни наследования, ни полиморфизма в нем не осталось?
может вы смотрели, какие именно операции приводят к увеличению потребления памяти (выбор файлов в диалоговом окне, чтение в FileObject через readAsDataURI(), добавление картинки в DOM и т.п.)?
хочу понять, имеет-ли все это смысл, если оригиналы терять нельзя — например для последующей отправки их на сервер — и какую стратегию лучше выбрать.
едва успели выпилить из браузера одно чудо-юдо, как другим уже не терпится запилить туда css с variables и calc.
кажется. что в купе с правилами применения каскадов, наследования (в понимании css), анимаций и традиционными вендор-специфичными глюками это должно стать умопомрачительным в отладке механизмом — или они таким способом хотят готовить персонал для программирования квантовых компьютеров?)
тут уже несколько раз объясняли, что нарушение абстракции это таскать лоадер в зависимостях модуля, т.к. система загрузки модулей должна абстрагировать код от этого. нарушение абстракции это смешивание логики загрузки кода, конструирования и разруливания порядка инстанцирования объектов в одну кучу. но, как оказывается, в некоторых случаях из подобных фокусов можно извлечь определенную практическую пользу. за что еще раз вам респект.
а 'promise!anyName', это не два отдельных слова, а «такое-вот-имя-модуля-целиком» — синтаксический компромисс в именовании, благодаря которому модули могут резовлить реализацию разными способами. «tpl!name», «ym!name» и т.п. главное, что результат для клиента не отличим. так что тут как раз все правильно.
вообще. на мой взгляд, основная ценность систем подобного уровня не в наличии какой-либо «клиллер-фичи», а в возможности интеграции как можно большего количества различных решений между собой наименьшей кровью. поэтому, в целом, соглашения рулят.
вы несомненно молодцы, что сумели стандартизировать этот момент внутри Яндекса. CommonJS/AMD решают схожую задачу, но не в масштабах отдельной компании, а для всего мира. это на порядок сложнее, отсюда больше компромиссов. зря вы ставите в один ранг с CommonJS и AMD, противопоставляя YM — это лишь сбивает с толку и провоцирует бесполезный флейм.
вероятность встретить за пределами яндексных инкубаторов, на открытом воздухе, код, завернутый в YM, такая же как увидеть в лесу динозавра. и год тому назад, когда он заопенсорсился, и сейчас. как только я перестал заниматься околояндексной разработкой, в коде не осталось практически ни чего из этого великолепия. потому, что во всем остальном мире — другие соглашения. за пределами Яндекса YM — лишь элегантное решение частной задачи, коих тысячи. как видите есть альтернативы.
CommonJS и AMD это общепринятые вещи — в смысле использования в проектах, рецептов и инструментов для комбинирования с другими технологиями, поддержки, документации. YM как еще один стандарт — не нужен (имхо). в этом смысле, было бы гораздо полезнее, если бы вы делились с сообществом своими революционными идеями, не в виде альтернатив (это лишь все усложняет), а коммитами в общепринятые технологии.
в этом цирке «Станый Метод» может быть запросто результатом чего-то в роде string:concat(X, Y), или того хуже. это совсем другой мир, где от AST толку чуть. распоследние тулзы пытаются даже код выполнять, но у и этого подхода есть принципиальные ограничения.
кто-то может привести пример инструментария для языков с _динамической_ типизацией где всякие go to definition и find all references, дают сколь-нибудь существенное отличие в надежности результата, по сравнению с «тупым грепом»?
мне вот не попадались еще. поэтому да, на первый план, так или иначе, выходит удобство редактирования и «vim» — наше всё. остальные трюки приходится делать лапками и внимательно проверять глазками.
Поэтому сюжет, в целом, показался каким-то не логичным, и быть может надуманным, даже. С первого взгляда, такая непоследовательность выглядит либо как недоработка сценария (если это литература), либо как притягивание фактов за уши к теории (если речь про науку). Если только оставлять сюжетную интригу не раскрытой это какая-то специальная особенность маркетинговой публицистики. В общем, не понятно, стоит-ли того же ожидать на ваших курсах, или в отличие от статьи, там все четко разложено по полочкам?
хочу понять, имеет-ли все это смысл, если оригиналы терять нельзя — например для последующей отправки их на сервер — и какую стратегию лучше выбрать.
кажется. что в купе с правилами применения каскадов, наследования (в понимании css), анимаций и традиционными вендор-специфичными глюками это должно стать умопомрачительным в отладке механизмом — или они таким способом хотят готовить персонал для программирования квантовых компьютеров?)