Комментарии 40
А если программистов всего 3, и один хорошо знает бизнес-процессы (и сам их создаёт), постоянно помогает пользователям решать их задачи (кастомные запросы и выгрузки, полезные кнопочки), то пусть развлекается. Здесь и без лямбд низкий бас-фактор, а такая свобода будет хорошим стимулом оставаться в организации. Нематериальная мотивация.
А если программистов всего 3,
Даже если он всего один. Нафиг. Люди имеют свойство болеть, уходить в отпуск, менять работу и еще 100500 различных вариантов.
За написание кода, который приводит к появлению в вакансиях требования «умение читать чужой код» — надо выгонять.
И не только в 1С. Смотри какой я крутой и в одну строчку запихал 100500 функций, процедур, циклов, условий и еще черт знает чего — нафиг оно надо?! Это не дизайн, это украшательство. Кроме понтов, это ничего не дает. Читаемость, по факту, не улучшается, причем даже тот, кто писал, сам, через год не может вспомнить, что он нам намудрил. Сокращение объема кода весьма сомнительно.
Я бы на месте руководителя вас бы уволил, за такие вредительские для предприятия решения.
Обычно бюджет уже попилен и поделен.Т.е. Вы за все плохое?
Да ещё и денег попросит в 1.5 раза больше, потому что для него работа — это не развлечение, он сюда пришёл зарабатывать, а не лямбды писать.Так да, и пользы приносит бизнесу в 3 раза больше, и проблем не создает — чего бы ему не платить в 1,5 раза больше?
работает от звонка до звонка, никакой самодеятельности, но и никакой инициативы.Вообще не понятно, почему если лямбды не пишет то никакой самостоятельности?
А если лямбды пишет, но работает от звонка до звонка, самостоятельности ни какой, инициативы ни какой — держать его за лямбды?
Помню давно, когда писал на Visual Foxpro, там тоже были такие понятия как макроподстановка (когда можно было выполнить конкретную строку кода, которая хранилась в переменной), а также потом появилась функция EXECSCRIPT, куда можно было передать любую программу, она компилировалась на лету и выполнялась.
Так вот макроподстановка была в 8 раз медленнее, чем обычная строка кода, а EXECSCRIPT — в 25 раз.
Так вроде автор об этом написал и у него цифры похожие:
"Разница между вызовом классического кода и такого же, но командой Выполнить, минимум в 10 раз! На моих тестах замедление доходило почти до 25 раз. "
Забавно, что иногда подход с компиляцией кода мог быть даже быстрее, чем классический. Например, мы делали такие оптимизации, что когда много ветвлений и условий в программе (в зависимости от каких-то внешних параметров/настроек), то выгоднее было сначала сгенерировать код с учетом всех этих настроек, а затем его выполнить. Это было в некоторых случаях значительно быстрее, чем когда внутри FOR/SCAN на каждой записи проверялись бы эти условия.
Такой код - первый вариант. Но не вижу проблем с оформленным комментариями кодом на сотню строк, если сравнивать его с сотнями тысяч строк "поддерживаемого" типового кода с запросами на 10 страниц прокрутки. Читать же можно, там по-русски почти все! Я - программист, делаю нужные инструменты. А менять работу из-за того, что чего-то в языке не достаёт, так где же работать тогда?! Но, повторюсь, конкретно этот код - эксперимент. И даже устарел за время модерации.
Уволить программиста за проектирование инструментов? Интересно тут.
Я вовсе не "продаю" это и не навязываю. Делюсь с коллегами идеей на тематическом сайте. Мне дальше интересно её развить. А кому нет - продолжат жить без неё, делая дело, как удобно им. Я просто хотел уточнить, что в конечном счёте планируются вызовы типа Filter в одну-строчки. Если это не читаем, то уж не знаю, что читаем.
Два примера! Уже привёл. Если вы имеете в виду, рассказать, как на этом заработать, то пока не придумал)
Я как раз и хотел узнать конкретику Кошмара) думал, хоть здесь объяснят
Приведите пример использования
Я бы этот кошмар в продакшен тащить не стал.
Перспектива такой код поддерживать мне видится крайне сомнительной затеей.
Заметно облегчая написание и чтение кода, данные анонимные функции, конечно, замедляют работу программы.
Где же здесь облегчение написания и чтения кода?
И так клянут разработчиков типового функционала, типа БСП, за излишнюю усложненность кода в угоду универсальности. А если кто-то ещё и такие навороты начнёт делать...
Что тут скажешь? Используйте то, что понятно, а что не понятно не используйте.
Я исхожу из того, что написание и чтение Filter вполне прозрачны. На другом ресурсе коллега доказывал, что выгоднее писать цикл в лоб, как обычно. Но он в собственном примере из 20ти строк так и не смог найти ошибки. Меньше буков, меньше ошибок!
Не понял, какие проблемы у вас с фиксированным количеством параметров, ибо передавать как структуру, можно конструируя их прямо на месте в нужном количестве.
Ну и собственно, пара моментов: goto вам уже намекнуло на антипаттерн, а передача подпрограмм в виде текста, это полный бред, ибо полностью выключает IDE для этих кусков, не говоря уже про экранирование и верификацию. Для запросов (аналогичный текстовый джихад), есть хотя бы конструктор и разумные люди давно прокляли адептов ЗУПа, которые даже такие вещи превратили в лютую хрень из условных конкатенаций клочков и инжекций каких-то символов и замен на лету, отполированных менеджерами временных таблиц. Тоже весьма «гибкая система» (гори она в Аду), не уподобляйтесь им, а включите мозг.
P. S. Жду вторую статью, поскольку испытываю двойственные чувства к функциональщине и частенько посматриваю в материалы не нагруженные функциональной терминологией.
P. S. Я вам описал конкретный кейс редактирования языка запросов, представленных как строка, и это очень хреновая практика, аналогичная у вас, эсли вы не способны понять такую простую аналогию, то нам не о чем разговаривать.
Как по мне, вместо ФП(каррирования, денотации) получился какой-то Франкенштейн, который с лямбдами использует псевдо ООП.
… покатайтесь на велосипеде за городом, придумайте хокку, съешьте круассан в Париже
Вот честно не понимаю, почему люди мучаются? У меня получается игнорировать неинтересные лично мне темы.
З.Ы. Уже писал на ИС, но для истории и тут оставлю.
У решения две проблемы:
1) Производительность, ибо выполняется интерпретация при каждом выполнении, в отличии от обычного кода который компилируется после первого прохода.
2) Безопасность, ибо при невнимательном обращении позволяет инъекции произвольного кода на сервер.
Я надеюсь, мы не будем сюда переносить всю историю с других ресурсов. В 1С нет функции Split в нормальном понимании (что строку обратно можно собрать командой Join). Но при необходимости все пишут функцию с нужным пониманием разделителя, а не уходят в среду, где все уже есть. Написать анонимные функции оказалось не прямо уж так сложно, когда мне понадобилось.
К тому же я в свободное время развиваю идею. Скорость работы теперь отличается в 3-6 раз, а не в 10-25. На счёт безопасности - вопрос архитектуры. Разработчику нужно как-то объяснить, что ждать на сервере с клиента код для выполнения - опасно. Предполагается, что лямбда-код выполнится в той среде, откуда вызван (клиент-клиент или сервер-сервер). Параметры используются, как есть. То есть, строки с инструкциями, переданные с клиента как параметры, останутся строками, а не инструкциями.
Я стараюсь трезво смотреть на эту идею. Она явно не привычна одинэсникам, и в то же время не считается интересной для адептов тех языков, где функции первого класса уже есть. Меня никто не понимает :(. Но это не означает, что я не могу опубликовать статьи. Кто-то расценит это как курьез из г и п, кто-то - как занятный прикол, кто-то может найти практическое применение. Но в любом случае вопрос будет рассмотрен,а это уже хорошо для сообщества.
Потому и советую перейти на что то получше, в 1с вы не дождетесь качественных улучшений в адекватные сроки. Скорее всего лямбды/замыкания/какое то подобие ооп в 1с появится, но лет через 15-20, если платформа еще жива будет.
В случае с замыканиями там еще и техническая проблема есть потому как сборщик мусора в 1с на подсчете ссылок, а не трассирующий. И потому с замыканиями будет сложно следить за памятью прикладным разработчикам. Кстати непонятно почему разработчики платформы трассирующий сборщик мусора не добавят, ведь подсчет ссылок с их проблемой зацикливания в платформе подразумевающей что разработчикам не нужно задумываться о низких уровнях — это странно и явно проблем добавляет.
Параметры используются, как есть. То есть, строки с инструкциями, переданные с клиента как параметры, останутся строками, а не инструкциями.Вероятно, речь о возможных инъекциях типа
НовыйМассив = Filter(Массив, "Возврат _1 = " + ПараметрОтЮзера + ";");Вероятно. Но, кажется, я ответил. Если этот параметр ожидается именно, как параметр, то код будет: filter(массив, "_1 = _2", ПараметрОтЮзера). Это означает, что сравнение будет производиться со строкой, и инструкции инъекции не будут выполнены. А если программа спроектирована таким образом, что вставляет код, полученный из вне, то, извините, это не проблема технологии анонимных функций.
Похоже на какое-то извращение, если честно. Но очень напоминает программное написание текстов запросов, которых раньше было очень много в типовых конфигурациях 1с.
Лямбда-функции на встроенном языке 1С