с каждым релизом пытаются сделать все более универсальные механизмы, а в итоге:
1. Трудно читаемый(распознаваемый) код
2. Зачастую, замедление проведения

теперь, чтобы изменить немного проведение документа(например ОПЗС) необходимо:
1. потратить время, чтобы найти где это сделали(через многоуровневые переходы по общим модулям)(тем более часть движений делают через Движения самого документа, часть пишут напрямую в регистр)
2.а потом еще коверкать эти так называемые "универсальные" процедуры

Меня другое бесит - когда не соблюдают свои-же правила оформления кода. Один из примеров:

>>>>Если
>>>>>>
>>>>КонецЕсли;

После обновления превращается в:


..>>Если
......
>>>>КонецЕсли;

, где .. - два пробела, а >> - символ табуляции.

(0) Ну дык.. Эволюция... Или мутация.. Смотря с какой стороны смотреть.

напиши свое

УПП слишком проста...
там многое упростили из за того, что 1Сики понять не могли

Все очень просто. Это из-за универсальности. Узкие, специализированные системы, как правило, значительно проще.

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

так что: 1, 2, 4, 5 + сменить руководство 1С на корню.

Ничего 1С не усложняет.
Это у них само собой получается.

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

А синтаксические ошибки в названиях переменных, функций, свойств - живут почти вечно.

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

упс...

УПП - это просто пример предела подхода в платформе

1. Отсутствие ООП
Теоретически все можно писать и на plain C. Но появился ООП и С++ и прочие джавы.
У платформы нет средств упорядочивания, структуризации кода кроме предлагаемого самой платформой. Что порождает дублирование, избыток копи-пастного кода.
А ведь УПП по количеству строк кода уже почти как программа схожего функционала на "джаве", но без возможности четкого абстрагирования подсистем, упрятывания в виде матрешки функционала в либы, фреймворки и т.д.

2. Динамическая типизация.
Инет полон холиваров dynamic vs static. Но факты в использовании языков программирования таковы:
Чем меньше проект - тем предпочтительней использование динамически типизированного языка. Чем больше, тем статически. Вот эта байда - Если ТипДокумента = Тип говорит о том что преимущества встроенного языка сходят на нет - типизировать все равно приходится.
Конечно есть подход для увеличения масштаба применимости динамического ЯП - метапрограммирование. Но в 1С его нет.

3. Визуальное программирование
Из преимущества оно все больше становится недостатком. Посмотрите "Расчетные листки" в УПП и повторите этот код по памяти. Или объясните новичку как оно работает.
Дело в том что в отличие от генераторов кода (скажем GUI для Java, или редакторов форм в Visual Studio), программист НЕ видит в коде что и как настроено в конфигураторе. И возникает сугубо когнитивная проблема - во-первых алгоритмы и данные находятся в двух несвязанных местах - коде и "настройках", во-вторых - что не написано - тяжело запоминается и передается в виде знания другому. Например по 1С уже в форуме просто текстом вопрос не задашь, нужно прилагать снимок экрана.

4. SQL
Как ни крут SQL как язык, прикладные программисты стараются избегать работы с ним напрямую. ORMы для джавы, Hibernate и проч, LINQ для C# - и т.д. Причина - разрыв представления задачи в виде взаимодействующих объектов и таблиц с реляционными отношениями. Для простых проектов и в целях оптимизации - приходится да и нужно знать как работает SQL на самом то деле. Но 1С предлагает - генератор кода "SQL"кода, а если тебе нужно его сложить из частей, то все, читай "портянки". Мало того, программисту предлагается не так много "конфигуриемых таблиц" для разработки, а дальше - их прходится наворачивать и опять же - не видно в коде что там в ней настроено. То есть в коде имеем вынуждено грязнейший стиль, где намешан SQLкод и работа с объектами.

Конечно, толковый программист в состоянии справляться с этими недостатками. Но проблема в том что стоимость такого программиста приближается к стоимости джависта-дотнетчика, как и скорость доработки. При сохранении все тех же недостатков платформы во время работы программы - медленная и прожорливая.

Но 1С, и УПП в частности, будет жить еще долго, потому что для СНГ есть множество преимуществ, перекрывающих эти недостатки :)

Все прочитала, во понаписали.)) Об платформе, её особенностях и недостатках, могли бы отдельный топик завести ;)

(12) "мое мнение, что 100% можно было написать проще, и работало бы быстрее" - откуда такая убежденность? Ты уже пробовал сам проектировать сложную систему? Да так чтобы другим разработчикам был код понятен и вносить изменения было нетрудно?

(38) "я добавляю одно измерение в регистр ТоварыВРезерве, в итоге приходится все равно для каждого объекта в отдельности переделывать движения..  и нет никакого "одного" места, где было бы все собрано.." - с одной стороны, вроде разумная претензия, а с другой - перед тем как писать движения все равно расчет шел бы разный для разных случаев, чем тебе это было бы легче?

или (65) - не поняла - что тут не так, в обходе результатов запроса по группировкам?

Я для клиентов общепита свое производство писал на семерке

ТС сам дурак