Давно мы не заводили веток, что бы мы хотели от 1С
А про то, что хотели бы от 1С в EDT, вообще не помню таких
Итак, что бы вы хотели от 1С в https://edt.1c.ru?

(3) >> ЕДТ никогда не будет эквивалентен конфигуратору.

Уточнение.
EDT не может быть эквивалентен конфигуратору.
Это как сравнивать самосвал и легковушку. Доехать из точки А в точку Б можно на любом из них. Но на этом их сходства заканчиваются. Дальше одни только различия - тип и расход топлива, грузоподъёмность, скорость, управляемость, габариты, вес и т.д.
В 99% случаев самосвал не нужен. Но если вам надо перевезти 10 тонн кирпичей, то делать это на легковушке будет затруднительно.

Так что EDT никогда не заменит конфигуратор. Конфигуратор никогда не уберут из платформы. Во всяком случае на сегодня таких задач и планов не ставится.

(0) А ты с какой целью интересуешься?
Ну, допустим, хочу чтобы оно было хотя бы как IDEA.

(11) То есть ещё сильнее тормозить? Не.. Нафиг...

(10) т.е. остальные языки на самосвалах ездят?

по мне так конфигуратор это каменный век, а не легковушка или самосвал
https://flin.my1.ru/_ph/2/2/643284224.jpg

Поддержку обычных форм

(9) ни разу не то. Кода там совсем нет, только заголовки процедур. Банальный перенос комментариев из кода

нет чтоб просто апи для конфигуратора добавить

(14) EDT ни разу не альтернатива конфигуратору, на настоящий момент.

(10) не уберут, но и развиваться конфигуратор не будет. Т.е. и в 2025-м будет тот же конфигуратор, и в 2040-м...

основной минус едт - это компиляция файлов в цф.
Одно это тормозит разработку существенно

Карту маршрута бизнес-процесса чтобы нарисовать можно было без конфигуратора.

(18) почему? EDT может 96% (пока что, разрыв постоянно сокращается) из того , что может конфигуратор. Ради тех 4% можно и перелить иногда конфигурацию в .cf. При этом EDT уже обладает массой плюшек, которых нет в конфигураторе, и уже не появится

А как сейчас обстоит дело с работой EDT с механизмами поставки и поддержки конфигурации, и с хранилищем конфигурации 1С (не git)?
Удалось наконец реализовать или приходится типовые обновления и захват/помещение объектов в хранилище делать всё равно в конфигураторе?
В первую очередь хотел бы чтобы EDT полностью на все 100% покрыл функциональность конфигуратора 1С.

(22) Потому, что (8).

(22) -> (20)

(24)(25) это всё временные трудности, которые решаются наращиванием мощей компа и небольшим изменением подхода к разработке

(18) Это почему? Очень удобная штука, где то за последние полгода уже не открывал конфигуратор, в EDT определенно удобнее.

(13) >> остальные языки на самосвалах ездят?

Во-первых, при чем тут остальные языки? Мы вроде как говорим о EDT для 1С, а не о EDT вообще для всех и любых языков.
Во-вторых, пример про самосвал условный. Аллегория. Не стоит воспринимать настолько буквально. ;) Не нравится самосвал - сравни седан и минивэн. Прояви чуть больше фантазии.

Прежде всего, хотелось бы бы он помогал РАБОТАТЬ, а не мешал.
Очень очень очень очень много всяких косяков. Мелких и не очень.

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

1С идет по пути "куяк куяк и в продакшен". Это касается платформы, решений на платформе и EDT.
От инструментов ждешь безупречной работы.

ИМХО стоит взять пазу и сосредоточиться не на новом функционале, а на стабилизации того, что уже есть.

Хочу методологов/архитекторов нормальных в 1С.
Тогда будет без разницы, в чем пофигурить после них.

(29) Так если он не будет поддерживать последние версии платформы - то и тем более он нафик не нужен.

На текущий момент не вижу актуальности в EDT.

(31) В том то и дело. Платформа и EDT развиваются отдельно. Конфигуратор с платформой вместе.

+32 Не тот пункт выбрал. Хотел 5й.

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

непонятно также почему поддержку каждой новой платформы 1с добавляют руками.
разве нельзя написать 1 раз апи и ему следовать?

(28) "Во-первых, при чем тут остальные языки? Мы вроде как говорим о EDT для 1С, а не о EDT вообще для всех и любых языков."
Мы говорим об инструменте разработки, а ты тянешь назад, приводя некорректные сравнения.
Вопрос у ТС "Что бы вы хотели от ЕДТ" - мы хотели бы смотреть вперед и его видеть таким чтобы на нем можно было работать, а не говорить как ты, что конфигуратор для большинства задач.

"Во-вторых, пример про самосвал условный. Аллегория"
Ну да, а я не понял этого

(29) >> стоит взять пазу и сосредоточиться не на новом функционале, а на стабилизации того, что уже есть.

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

(10) "EDT не может быть эквивалентен конфигуратору."
Прогресс точно не такие как ты)

Прогресс двигают

(37) >> мы хотели бы смотреть вперед и его видеть таким чтобы на нем можно было работать, а не говорить как ты, что конфигуратор для большинства задач.

Я говорю как есть.
Конфигуратор есть и останется для большинства задач на 99% установок 1С.
Никто не будет ставить у клиента EDT ради доработки пары отчётов или печатных форм. А именно для такой работы в 99% случаев открывается сегодня конфигуратор. Плюс ради чисто административных задач (выгрузка/загрузка/установка обновлений).

Оставшиеся 1% - это большая и серьезная разработка, проектное внедрение, командная разработка, поддержка интенсивно меняющихся конфигураций. Там как раз EDT может и должен быть востребован со всеми его плюшками.

Конфигуратор и EDT это два разных инструмента. И никогда они не заменят друг друга. И не должны. Это просто не нужно.

(39) (40) Да при чем тут прогресс?
Просто пойми простую мысль, что EDT и Конфигуратор - это две разные вещи. Они никак между собой не конкурируют и никак друг другу не мешают развиваться. Тем более, что дальнейшее значительное развитие конфигуратора не предполагается (только поддержка каких-то новых возможностей платформы по мере её развития).

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

(42) очень даже конкурируют. Задача то одна - доработка конфигурации

(42) с чего вдруг разные вещи? это ты простую мысль пойми. И советы какие то, то фантазиюв включить ты мысль понять) Начни с себя)

Я хочу что бы в офф телеграмм канале не было столько багов.
Половина тупые, вторая - критичные.
Я ХЗ как там в мамке ведут разработку, ибо когда сел работать Tormozit он просто аннигилировал тот канал потоком ошибок.

На сколько помню вопрос о внедрении наработок снеговика в v8 был проигнорирован.
1С идет своим путем. И мало обращает внимание на нужды обслуживающего персонала.

(46) И только Александр Капралов рассказывает про свои башни из костылей и говорит, что он себя прекрасно чувствует.
Остальные популяризаторы ЕДТ - давно уже слились и тоже ругаются.

(48) есть такие люди, что поддерживают линию партии не смотря ни на что

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

И бензин не надо и компуктер бортовой не глючит ибо его в лошади нет и т.д.

Штобы была легче и запускалась быстрее
Штобы не глючил кэш конфигурации
Штобы при мерже веток не терялись объекты
Штобы была нормальная темная тема как в VSCODE
Штобы не подлагивал интерфейс
Штобы...

Вангую: EDT в ближайшие 5 лет практически не будет развиваться.
Развиваться будет то, на чем можно заработать "здесь и сейчас": платформа, БП и ЗУП.

По EDT довольно специфичный рынок.  Возможно как-нибудь потом...

(52) >  в ближайшие 5 лет практически не будет развиваться.
Готово! =)

10 апреля 2015 года. https://1c.ru/news/info.jsp?id=19821
    Фирма "1С" объявляет о выпуске 10.04.2015 ознакомительной версии программного
    продукта "1C:Enterprise Development Tools", версия 1.0.

(52) так EDT и не для заработка выпускался. В анонсах ранних версий фирма 1с писала, что одна из главных целей EDT это дать разработчикам, пришедшим из других ЯП, похожую на привычную многим IDE

(44) >> конкурируют. Задача то одна - доработка конфигурации.

Нигде они не конкурируют. Откуда вообще эта парадигма взялась о конкуренции?
Они так же конкурируют как Бухгалтерия с ERP.

Доработка доработке рознь.
Если заказчику нужен один дополнительный отчет или небольшая доработка типового объект (справочника или документа), то делать это при помощи EDT просто бессмысленно. Потратишь больше времени на загрузки-выгрузки конфигурации. Зачем? Только ради утилизации процессорного времени и докупленной под EDT оперативной памяти?

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

(55) конечно конкурируют, особенно с учетом того что конфигуратор не развивается

(55) "Если заказчику нужен один дополнительный отчет.. делать это при помощи EDT просто бессмысленно. "
по твом меркам отчет это что то мелкое, не требующее ветвлений в гит итд

Да, с EDT метод разработки ХХП даётся чуть труднее
https://cs8.pikabu.ru/images/big_size_comm/2016-03_5/1458912097163946994.jpg

(57) >> отчет это что то мелкое, не требующее ветвлений в гит итд.

Опять таки возникает вопрос - что за отчет и в рамках чего делается.
В рамках большой мегаразработки, которая ведётся в EDT - конечно нужно делать отчет в EDT. Даже если сам по себе он простой.
Но в рамках разовой доработки какой-нибудь типовой конфигурации - EDT бессмысленнен. Если только это не какой-то суперсложный отчет, требующий параллельной доработки других объектов, подсистем и модулей.
Использование git или типового хранилища конфигурации 1С - тоже вопрос не всегда однозначный. Целесообразность разворачивания EDT и подключение к git какой-нибудь типовой бухгалтерии, где делается по одной мелкой доработке в год, а 99.9% изменений - это обновление типовой, выглядит весьма сомнительной. Усложнение процесса ради процесса.

У EDT есть огромное количество своих преимуществ и плюшек в сравнении с конфигуратором. Хотя бы та же возможность использования git вместо хранилища. Только это не означает, что воробьёв нужно теперь расстреливать непременно исключительно из пушки.

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

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

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

(58) >> с EDT метод разработки ХХП даётся чуть труднее.

По-моему, не особо. Во всяком случае г*внокодить в EDT ни чуть не труднее.
Разве что порог входа чуть-чуть повышается для программистов за счет более сложной среды. Хотя сложность тут скорее связана больше с непривычностью для тек, кто очень давно или никогда не работал с другими IDE или языками, кроме 1С.

Дима Трефиленков сказал хорошую весчь.
ЕДД разрабатывается для выпуска коробочных продуктов в распределенной команде.
И заточен сейчас именно на это.
Все удобства конкретного пахаря, сценарий доработки на местах, где то в конце беклога. Главное что бы коробочки было удобно выпускать вендору, всё.
И да они могут себе позволить подождать.

(63) А есть ли видимый результат от разработки ERP в EDT?

(58) Думаете, в самой 1с не пользуются EDT для разработки типовых?

(65) А ты знаешь, как их там бьют? (с)

(64) Счастье разрабов от сахара и девопсеров от конвеера

Я понял, что я хочу от него )))
ЧТобы он внятно ставился. А не молча закрывал окно. Которое даже не гуёвое, а cmd...

(68) java у тебя не той системы

(69) Пусть тогда скажет об этом, а не молчит из угла в угол, как рыба об лёд.

это голос в пустоту, но...
хотелось бы поддержку древних версий платформы. чтобы можно было взять и загрузить в edt какой-нибудь супер-легаси "продукт", и начать его ставить на рельсы 21 века.

(68) Внятно оно ставится, если мануалку почитать :)
В требованиях там явно написана какая-то ява с javafx на борту для гуевого установщика.
У меня работает на openjdk-15, так как в ней нет этого самого fx ставлю с командной строки, хотя и OpenJFX прикрутить не проблема при желании.

(72) Манулы на сетап читать? У меня виндовз или линукз???
Поставил через cli. Даже JavaFX скачал.
А всё равно не запускается.
В общем - натуральный вторпродукт.

(73) надо оракловую жаву удалить

(73) Надо ставить жаву из фулл сборки. Если ты качал без слова "фулл" значит ты не ту поставил :)

(74) У меня её нет )))
У меня OpenJDK

(65) Пользуются.
Но вроде как не все команды.
И да сами иронично к этому подождать в любой ситуации от 5 минут относятся.
С другой стороны, если бы их самих это есть не заставляли - продукт был бы обречен.
Так через внутреннюю боль он худо бедно, но идет вперед

(73) (74) (75) Именно поэтому у меня этой херни не будет. Я про едт.
Я ее даже не ставил, но зная пиздопляски от javasdk, разные версии javaw, прописанные в path, я уверен, что едт будет этим страдать.
Такой едт на и накой не нужон.

Этой же херней страдает и android studio, и delphi, когда собирает что то под android. Короче, везде, где торчит еплет javaw.

(67) А для пользователей ERP?

Чтобы отошла и не мешала. Или передайте уже разработку нормальным людям например в JetBrains.

солидарен

(80) Думаю, на качество кода разработка через ЕДТ положительно влияет

(83) А что мешало писать качественный код в конфигураторе?

EDT — это GIT
Если убрать из EDT GIT, то, собственно, станет непонятно, нахрена вообще EDT нужен
Все остальные отличия — это несерьезно
А вот GIT сразу меняет все
Прикрутить разработчикам конфигуратора GIT к конфигуратору можно только как седло к корове, то есть можно, но выглядеть это будет всегда нелепо, неуместно и все будет говорить о том, что GIT здесь не планировался от слова совсем
Начиная от возможности работы с несколькими ветками и заканчивая работой с большим количеством файлом, а не монолитным cf

(85) "заканчивая работой с большим количеством файлом, а не монолитным cf"
Файлы в контексте прикладной разработки 1с - лишняя внешняя сущность, как и cf. Есть метаданные, вот с ними и работаем. А в файлы только выгружаем для переноса.

(83) А может, положительно влияет автоматическое тестирование и качественная проработка архитектуры?

(85) ГИТ нужен немногим. Качественные инструменты разработки - всем.

(88) гит нужен немногим потому что в 1с по большей части нет культуры разработки
из этой позиции да, он немногим нужен

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

(86) возможно твое мнение было бы верным лет так 10 назад, но сейчас с ростом сложности разработки, 1с переживает кризис
отсюда движение сторону файлов а не монолита, едт, итд

(89) И, чтобы повысить культуру разработки, 1С выкатило нам глючный громоздкий неудобный EDT? Спасибо, чо.

(91) все верно... Конфы по несколько тыщ объектов, а несколько программистов ковыряют один ЦэЭф, "захватывая объекты". Это мрак какой-то...

(92) ну культура сверху приходит, 1с в своем духе

(87) если говорить про автотестирование, то гит очень способствует этому

и плюшки есть типа бисекции

(91) "но сейчас с ростом сложности разработки, 1с переживает кризис
отсюда движение сторону файлов а не монолита, едт, итд" - против спагетти-кода ООП было бы гораздо эффективнее.

(97) Сейчас набежит Волшебник и напишет, что в 1С ООП есть.

(97) Макараны можно писать на любом языке.
(98) ОП, но не ООП

(97) "против спагетти-кода ООП было бы гораздо эффективнее"

это всё в теории

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

(88) Сказал деревенский паренек, не зная, что бывают ситуации, когда над продуктом работает целая команда

(92) Напиши свой, чо

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

(97) Ну да ну да, из последнего помню Фузину с ООП, где объект "Товары" наследовался от объекта "Организации"
Охрененная эффективность, эффективнее некуда

(103) Хочешь ООП, пиши на другом, нахрена тебе тогда 1С со своими готовыми жестко заданными и ограниченными вариантами объектов?

(101) Неистово одобряю сей комментарий.

(101) Рома, опять ты не понял, а отвечаешь, прям фирменный знак какой-то.

(103) А сейчас разработка крупных проектов простая и дешёвая?

(84) Я, увы, не знаю, кто являлся в 1С драйвером создания и продвижения идеи ЕДТ и каковы были его мотивы. Но то что гит - это де-факто уже неотъемлемый атрибут инструментов контроля качества кода, это кажется очевидным. Можно и через АПК проверять, но наверное развитие и доработка там не так удобна, как с использованием более современных средств.
Так и с ЕДТ, наверное, посчитали - не будем допиливать пофигуратор, воспользуемся более распространенным в миру еклипсом.