Прощай, X++

[ax_mct]

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

То есть к ООП я бы еще добавил методологию управления проектом как фактор действительно влияющий на качество работы программиста.

Но то что более "мощный" язык вас спасет или поможет? Опасная иллюзия, примерная такая же как убежденность клиентов что при появлении проблем надо добавить еще программистов.

Вместо ООП что? Функциональное программирование для бизнес-приложений? Это как?
Вместо X++ что? C#? И как именно смена языка вам поможет как программисту AX? Будете быстрее кодить? Да кому нужна эта скорость?
Может быть бдте бстрее пнмать кд?

[belugin]

Цитата:

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

Вместо X++ что? C#? И как именно смена языка вам поможет как программисту AX?

Перечитайте мои сообщения

Цитата:

Может быть бдте бстрее пнмать кд?

Конечно да. И быстрее находить ошибки.

[ax_mct]

Цитата:

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

Перечитайте мои сообщения

Конечно да. И быстрее находить ошибки.

В моем сообщении было не про просто программиста а про программиста АХ.
И подразумевались типичные условия программирования на АХ.

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

Возможно где-то и есть условия когда деятельность программиста АХ приближена по условиям к деятельности "обычного" программиста .NET или Java или С++ когда результатом работы служат строчки кода в соответствии с требованиями технической спецификации.

Но это тогда какой то заповедник с "кодерами обыкновенными" где обязательно наличие "консов большеголовых" которые как я знаю водятся только в России. За пределами РФ такого редкого вида консультантов которые могут создать тепличные условия для кодеров AX - нет или практически нет.

Кодер АХ - это не обидное, нет. Это зависть тех разработчиков АХ которые работают совсем в других условиях. При этом те же программисты .Net и Java часто работают в тех же условиях "один человек-оркестр" для бизнес приложений. "Консультант-программист" - это почти норма для многих бизнес приложений и скорее наличие роли "кодеров" вызывает удивление на этом поле.

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

Не консерваторская у меня позиция. Мне нравится С# и я с 2003 года ношусь с ним как с родным. Среда разработки тоже не важна, это как профессиональному водителю машину сменить. Единственное что я доказываю это приоритеты и что действительно важно а что нет.

От смены языка программисту АХ легче не станет. Если вы конечно не в заповеднике который вам обеспечивают другие люди и роли.

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

[belugin]

Цитата:

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

В моем сообщении было не про просто программиста а про программиста АХ.
И подразумевались типичные условия программирования на АХ.

Программист X++ есть разновидность программиста.

Просто мы привыкли к нашему блабу. Причем те же самые вещи, которые в блабе есть в одном месте не работают в другом и мы не видим тут никакого противоречия.

[ax_mct]

Цитата:

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

Программист X++ есть разновидность программиста.

Просто мы привыкли к нашему блабу. Причем те же самые вещи, которые в блабе есть в одном месте не работают в другом и мы не видим тут никакого противоречия.

https://ru.wikipedia.org/wiki/Грэм,_Пол

Цитата:

В очерке «Побеждая посредственность» Грэм, в частности, описывает изобретённый им «Парадокс Блаба» («Blub paradox»), объясняющий, почему программисты не желают изучать более эффективные инструменты программирования, чем те, которыми они уже владеют (в частности, объясняющий непопулярность Лиспа). «Парадокс Блаба» состоит в том, что программист, знающий некоторый язык (для него Грэм и вводит условное наименование «Блаб»), как правило, хорошо понимает, чем Блаб лучше, чем любой менее мощный язык, поскольку в состоянии назвать механизмы, имеющиеся в Блабе и отсутствующие в менее мощных языках и понимает, как именно эти механизмы облегчают программирование. В то же время он не в состоянии заметить разницу между Блабом и более мощными языками, поскольку «думает на Блабе» — решение любой задачи автоматически представляет на Блабе, естественно, ограничиваясь теми средствами, которые в Блабе есть. Имеющиеся в более мощном языке дополнительные средства в его глазах ничего не стоят, так как он не умеет их применять и, естественно, не понимает, что они облегчат ему жизнь. И лишь когда программист по каким-то причинам изучит более мощный язык, он получит возможность смотреть на Блаб «сверху вниз» и видеть его ограниченность.

AX это не среда разработки.
Программист AX это не программист X++.

X++ является только частью инструментария для программиста AX.
X++ не является независимым языком как тот же C++ ( http://lurkmore.to/C%2B%2B ).

Поэтому если говорить о Блабе то это не X++ а сама система в целом.
Не как X++ vs С# а как Axapta 3.0 vs AX 2009 vs AX 2012 vs AX 2015.

Надежность "движка", среды выполнения, обработки ошибок ядром намного важнее чем мощь инструкций и удобство программиста.

Для программиста AX знания архитектуры системы и фунционала намного важнее чем расширенное владение языком программирования. Мне до сих пор не по себе от проекта в котором из-за написанной на X++ мнопоточности AOS ложился каждые 2 дня. Та же задача решалась на раз-два стандартными средствами. Но были продвинутые программисты пришедшие с C++.

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

В условиях постоянных новых вводных для того чтобы код был "чистым" его часто надо переписывать с нуля. А это уже нереально или просто опасно. "Грязные" но безопасные заплатки лучше в большинстве случаев.

С точки зрения поддержки кода и его расширения намного важнее применение ООП (в соответствии с Best Practices) чем чистый математический код в отдельных методах.

Комментарии в коде и осмысленные наименования намного эффективнее чем иной синтаксис или математическая чистота кода.

Математическая чистота кода для меня как эйфория художественно продвинутых от квадрата Малевича. Намалевано так же, но квадрат!

P.S. К чему это я => язык это только малая часть средств разработки, а его синтаксис это вообще дело вкуса но не более того.
Что вы хотите получить от С#? Асинхронность, поточность и так далее? А может лучше не надо?

Правостороннее движение - автомобиль и лошадь. Безопасность превыше правил. Причем животное это AX а автомобиль это программист

[belugin]

Цитата:

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

X++ является только частью инструментария для программиста AX.
X++ не является независимым языком как тот же C++

Инструменты меняют, причем иногда части инструментов на более новые.

Цитата:

Поэтому если говорить о Блабе то это не X++ а сама система в целом.
Не как X++ vs С# а как Axapta 3.0 vs AX 2009 vs AX 2012 vs AX 2015.

Вам знакомо слово "декомпозиция"?

Цитата:

Надежность "движка", среды выполнения, обработки ошибок ядром намного важнее чем мощь инструкций и удобство программиста.

см. ниже ("статическая типизация")

Цитата:

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

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

Цитата:

В условиях постоянных новых вводных для того чтобы код был "чистым" его часто надо переписывать с нуля.

Вы все пропустили - рефакторинг известен с 1991 года, если верить википедии. Сейчас уже давно есть автоматизированные средства для многих распространненных языков.

Цитата:

А это уже нереально или просто опасно. "Грязные" но безопасные заплатки лучше в большинстве случаев.

Если они грязные, то как правило, небезопасные.

Цитата:

Комментарии в коде и осмысленные наименования намного эффективнее чем иной синтаксис или математическая чистота кода.

Как жаль что для X++ нет средств для безопасного переименования.
Как жаль, что в X++ нет пространст имен и подсистеме даже нельзя дать имя.

Цитата:

P.S. К чему это я => язык это только малая часть средств разработки, а его синтаксис это вообще дело вкуса но не более того.

Существует объективная семантическая разница между языками и вкус тут не причем. Просто блаб программистам не видно то, что выше привычного уровня абстракции.

Цитата:

Что вы хотите получить от С#? Безопасность превыше правил. Причем животное это AX а автомобиль это программист

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

Давайте про безопасность:

1. Безопасность - это статическая типизация
   в X++ нету дженериков, поэтому List, Map, Array, Set, container используются без уточнения типа, в результате соответствие типов не проверяется.
   Нельзя объявить Query<InventTrans> поэтому в самых важных для разработки ERP частях код не проверяется компилятором. select имеет совершенно нелогичную семантику и тоже не проверяется статически (присоединением exists join можно сломать запрос и компилятор ничего не скажет, можно не выбрать поле и его использовать и т.д.)
2. Безопасность это проверки - для X++ нет ничего похожего на CodeContracts
3. Безопасность - это легкость понимания - нельзя выделять куски select в отдельные функции - в результате копипаст и ошибки при модификации.
   
   Нет продвинутых средств поиска участков кода
   
   
   
   
4. Безопасность, это единый стиль - в X++ нет достаточно удобных средств для рефакторинга, проверки стиля кода.