Оver-engineering - "зачем так сложно?"

[belugin]

Цитата:

Сообщение от ax_mct

придет что перенос на .NET и переход на VS - это Оverengineering.

Почему gподдерживать отдельную специальную более медленную виртуальную машину для X++ это не overengineering?

Почему поддерживать отдельную более бедную IDE для X++ это не overengineering?

Вон ABAP вполне себе на Eclipse живет (поправьте, если я что-то не так понимаю)

[ax_mct]

Цитата:

Сообщение от belugin

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

От того что мы расчленим эти 2000 строк (10 экранов?) на классы с использованием мощных паттернов и ненатурального ООП, а затем будем со всем этим искусстно бороться - ни продукту, ни клиенту не жарко и не холодно. Это программирование ради программизма.
Нет большой разницы 2000 это строк или 20 классов с точки зрения разных задач у вендора, партнера и клиента.
Нет такой проблемы как избыточность кода. Есть проблема у программистов которые смотрят на этот код.

Цитата:

Сообщение от belugin

Почему gподдерживать отдельную специальную более медленную виртуальную машину для X++ это не overengineering?

Почему поддерживать отдельную более бедную IDE для X++ это не overengineering?

Усилия и затраты по реализации нежелания поддерживать "отдельную специальную более медленную виртуальную машину для X++" и "отдельную более бедную IDE для X++" - в десятки и десятки раз превышают усилия и затраты по их поддержке.

Медленность нативного X++ это миф, бедность IDE - миф.
Скорость это железо, база данных и кэширование, бедность IDE - это плагины.

[mazzy]

Цитата:

Сообщение от ax_mct

Медленность нативного X++ это миф, бедность IDE - миф.

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

и дело даже не в портировании на .net/vs.
каждый помнит тормоза при первом обращении к AOT, при создании программисткого проекта. для глобальной компиляции аж специальную утилиту сделали.

про бедность - стоит вспомнить, что X++ основан на java-виртуальной машине первого поколения. когда никакого JIT, никаких оптимизаторов, тривиальный сборщик мусора, убогая модель объектов в памяти, чудовищно неэффективные exception и кривая релиазция tread, никаких функций высшего порядка. (тривиальный-убогий-неэффективный конечно по нынешним временам и по современным меркам).

сейчас актуальной является java 8 поколения. ближайшим будущим является java 9.

бедность особенно проявляется в том же инструментарии. хотя тот же jUnit третьего поколения реализовали. актуальным является junit четвертого поколения.

событий в morphX до версии акс7 существенно меньше, чем есть в операционках.
контролов современных не хватает.

не говоря уже про убогий отладчик.

==========================
не, morphX - отличная вещь для своего времени, хорошо продуманная и крепко сделанная.
но рано или поздно все-таки надо двигаться дальше.
и хорошо, что двигаются.

[ax_mct]

Цитата:

Сообщение от mazzy

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

Спасибо за по существу. Но можно слушать пользователей, то есть не страдать аутизмом, но при этом продолжать болеть программизмом и в упор не видеть оverengineering.

Тормозов стало меньше? Что-то стало быстрее? Да на текущем железе оно летало бы.
Программировать стало легче?

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

оverengineering это когда нет чувства достаточности. Тот медленный и бедный нативный X++ был достаточен. Это как лопату усовершенствовать.

[belugin]

Цитата:

Сообщение от ax_mct

Что-то стало быстрее?

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

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

[Logger]

Цитата:

Сообщение от belugin

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора

Да, это так и CIL хорош для этих целей. (Хотя в случае корреспонденции, надо бы все же алгоритм оптимизировать, так как для большого числа строк CIL тоже не поможет. Слишком быстро растет время с ростом числа строчек в документе )
Но к сожалению есть ряд минусов, которые сильно портят впечатление.

1. Вот зачем было принудительно заставлять делать обработки только в CIL для пакетов и вебсервисов ? Есть ли какие-то технические ограничения ? Для пакетов так точно не должно быть.
Почему бы не дать нам выбор ? Зачем гвоздями прибивать?

2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять.

3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему Помогите найти: Сравнение производительности различных операндов при конкатенации строк
операция += в CIL ведет себя по-тормозному по сравнению с p-code. И никуда тут не денешься. только если переписывать код через StringBuilder или TextBuffer что сильно ухудшает читаемость.

пп. 1-2 зануляют все плюсы CIL
Рука тянется за револьвером

[belugin]

Цитата:

Сообщение от Logger

1. Вот зачем было принудительно заставлять делать обработки только в CIL для пакетов и вебсервисов ? Есть ли какие-то технические ограничения ? Для пакетов так точно не должно быть.
Почему бы не дать нам выбор ? Зачем гвоздями прибивать?

Ответ на этот вопрос я не знаю.

Цитата:

2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять.

Как тогда реализовано Edit and Continue ?

Цитата:

3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему

Интересно. Тут вопрос за счет чего это и нельзя ли пофиксить помпилятор чтобы он для конкретного случая генерировал StringBuilder. Спасибо за ссылку

[ax_mct]

Цитата:

Сообщение от belugin

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

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

Моя категоричность она для чистоты лечения

Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое решение.

Но нам же неинтересен плоский T-SQL так как 3D OOП, не так ли? Вот оно и есть - программизм.

[mazzy]

Цитата:

Сообщение от ax_mct

Те же хранимые процедуры это стандартное и приемлимое решение.

Ритейл в акс7 построен на хранимых процедурах.
Не приведи господь.

Цитата:

Сообщение от ax_mct

Моя категоричность она для чистоты лечения

не надо, пожалуйста.
открывайте балаган в курилке в новой ветке.

[belugin]

Цитата:

Сообщение от ax_mct

Моя категоричность она для чистоты лечения

Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.

Цитата:

Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое
решение.

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

Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX.

[belugin]

Цитата:

Сообщение от ax_mct

От того что мы расчленим эти 2000 строк (10 экранов?) на классы с использованием мощных паттернов и ненатурального ООП, а затем будем со всем этим искусстно бороться - ни продукту, ни клиенту не жарко и не холодно. Это программирование ради программизма.

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

Цитата:

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

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

Цитата:

Усилия и затраты по реализации нежелания поддерживать "отдельную специальную более медленную виртуальную машину для X++" и "отдельную более бедную IDE для X++" - в десятки и десятки раз превышают усилия и затраты по их поддержке.

Докажите.

Цитата:

бедность IDE - это плагины.

Вы непонятно выражаетесь. "Граальность" VS в том, что плагинов там большая куча

[Ace of Database]

Цитата:

Сообщение от belugin

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

Похоже, чтобы решить задачку из соседней ветки, придется продублировать целую форму. А в старых Аксаптах все решилось бы маленькой модификацией
добавить readonly датасорс на форму, для фильтрования
Так какой подход плодит больше багов: старый или новый?

[belugin]

Цитата:

Сообщение от Ace of Database

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

Если бы там был метод в 2000 строк - было бы легче?

[Ace of Database]

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

[belugin]

Цитата:

Сообщение от Ace of Database

Но еще хуже, когда для добавления источника данных надо дублировать форму.

Это отдельное обсуждение на тему "Надо ли закрывать возможность overlayering, а если надо, то где и когда"