Прощай, X++

[ax_mct]

Цитата:

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

Я не писал аддонов, но по опыту работы со скриптами не заметил никкакой обратной несовместимости - что там требуется кроме перебития номера версии в референсах? Тут говорял что аддины обратно совместимы.

Это как "повезет" или как о совместимости "позаботятся".
Пойнт в том что использовать вызовы "системного" кода такого как WinAPI или популярные стандартные библиотеки - это одно (основываться на текущем фундаменте или на старом фундамента который оставили для совместимости),
а ссылаться на прикладной слой (который меняется) это как на живом существе мансарду строить.
Вы можете сделать в AX свой независимый модуль который будет использовать только свои собственные обьекты AOT (классы, таблицы и прочее) и все может быть хорошо.
Но как только вы используете или ссылаетесь на "не свое" - оно может и более того должно меняться со временем. Это нормально.
Так как чаще всего то что мы имеем в AOT это не "интерфейс", это внутренности сложного существа где все слишком переплетено. Начнем отделять один орган - порвем другие.
Для работы со сторонними системами совместимость интерфейсов (данных, программного) необходима, но для внутренней работы AX это делать нельзя - живой и сложный организм помрет от такой целесообразности.

Цитата:

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

Почему интерфейс обязан меняться при этих изменениях?

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

Цитата:

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

Меньше строчек надо поддерживать. Меньше возможности внести ошибку.

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

Цитата:

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

Еще забыли SSRS.
Интеграцией с VS, моделями, компиляцией (в IL?) можно не пользоваться. Функционал не является средством разработки.
Как по вашему, что из перечисленного внесло наибольший вклад в усложнение разработки?

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

Думаю что все понемногу внесло в усложнение разработки. Так как не одна составляющая усложнилась а почти все. И в каждом конкретном случае это по разному.

[belugin]

Цитата:

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

Это как "повезет" или как о совместимости "позаботятся".
Пойнт в том что использовать вызовы "системного" кода такого как WinAPI или популярные стандартные библиотеки - это одно (основываться на текущем фундаменте или на старом фундамента который оставили для совместимости),
а ссылаться на прикладной слой (который меняется) это как на живом существе мансарду строить.

Вы не поверите, но у WinApi за фасадом тоже кое-что меняется. Разумеется, для более мелкого рынка в backwards compatibility вкладывают меньше (у джоэла была история о том, что для поддержки Sim City эмулировали баг)

Цитата:

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

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

Цитата:

Меняется функциональность - меняется все. Это оправданно.

Знаком ли вам open closed principle проектирования?

Цитата:

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

То есть вы считаете что то, что вы называете "красотой кода" никак не связано с количеством ошибок и временем разработки?

Цитата:

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

Вот вам пример про хорошо спроектированную программу. Редактор кода внутри AX2012 - это компонент Visual Studio. Разработчики VS не знали, что редактор планируют вставить куда-то еще и никак не дорабатывали его для Ax2012. Но кусок одной программы оказалось можно вставить в другую программу, при помощи расширений обучить возможностям другого языка и теперь, если вам нужно подсветку парных скобочек или свертывание и развертывание тела if - вы можете просто взять готовое расширение (по ссылке фактически скомпилированные стандартные примеры для VS SDK).

- эти расширения практически не надо тестировать для работы в AX
- разработчики VS знают, что они могут менять без нарушения работы расширений
- вам не надо изучать реализацию редактора VS, а только его интерфейс чтобы его расширить

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

[RVS]

Цитата:

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

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

Можно, ессно.. а оно НАДО?

Больно смотреть на то, как из нормального продукта (Аксы) делают.. полуфабрикат под свой вкус.

ЗЫ : на вкус и на цвет все фломастеры - разные )

[belugin]

Цитата:

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

Можно, ессно.. а оно НАДО?

Что именно оно? Отделять интерфейс от реализации?

Цитата:

Больно смотреть на то, как из нормального продукта (Аксы) делают.. полуфабрикат под свой вкус.

ЗЫ : на вкус и на цвет все фломастеры - разные )

Тут вопрос не вкуса а вполне конкретных потребительских свойств.

[ax_mct]

Цитата:

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

...
Я не говорю, что для прикладного кода можно достигнуть совершенно такой же легкости и обратной совместимости, но думаю, можно существенно продвинуться относительно текущего состояния.
…
Проблема как раз в том, что Ax не конструктор, а конструкция из пластилина - у конструктора есть четкие интерфейсы деталек
…
Почему нельзя использовать те же принципы (...прекрасные детальки Tables, Forms, Maps…) для прикладного кода?
…
Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор
…
Наличие отделения интерфейса от реализации позволит сделать изменения более быстрыми и дешевыми

С точки зрения клиента это жалобы кочегара на пароходе. Который хочет чтобы лопата была удобнее, топка пониже и уголь лежал так чтобы его было удобнее бросать.

С точки зрения программиста это нереально (или нереально дорого) отделить интерфейс от реализации для прикладной логики в AX. Дорого и неоправданно.

Цитата:

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

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

Это возможно из-за "зафиксированного" расположения внутренних органов вместе с их одинаковыми функциями.
Прикладной же код АХ это метаморф с постоянным изменением места внутренних органов и даже их функций.

Цитата:

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

Знаком ли вам open closed principle проектирования?

Сlasses, modules and functions should be open for extension but closed for modifications.
Невозможно для прикладного кода AX. Это смерть для нее.

Цитата:

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

То есть вы считаете что то, что вы называете "красотой кода" никак не связано с количеством ошибок и временем разработки?

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

AX это вещь для потребителя. Программист AX не является ее потребителем а просто обслуживающий персонал.

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

[belugin]

Цитата:

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

С точки зрения программиста это нереально (или нереально дорого) отделить интерфейс от реализации для прикладной логики в AX. Дорого и неоправданно.

Он уже отделен в какой-то мере (посмотреть слова "интерфейс" и "реализация" в словаре, применить к любому классу прикладной логики AX)

Цитата:

Представьте что вы заказываете себе строительство дома. И вам чихать на стандарты строителей

Мне кажется опять не очень удачная метафора: во-первых, это топик для строителей, во-вторых, мне не чихать, построили дом в соответствии со стандартами или нет; в третьих вам не чихать, так как вы это продолжаете обсуждать

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

[ax_mct]

Цитата:

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

Он уже отделен в какой-то мере (посмотреть слова "интерфейс" и "реализация" в словаре, применить к любому классу прикладной логики AX)

Это да. Но я имел в виду именно то мне показалось что вы имели в виду
Когда "интерфейс" только дополняется и наши кастомизации могут работать безболезненно независимо от изменений в реализации прикладной бизнес-логики.
И я хотел выразить только то что для такой системы как AX это лишено смысла.

Цитата:

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

Мне кажется опять не очень удачная метафора: во-первых, это топик для строителей, во-вторых, мне не чихать, построили дом в соответствии со стандартами или нет; в третьих вам не чихать, так как вы это продолжаете обсуждать

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

Цитата:

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

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

+1024. Набор компромиссов. И облегчить жизнь хочется и даже возможно. Но не счет того чтобы вместо 3 строчек написать одну, а за счет использования OOП и технологичного дизайна классов.

Но тема в части "куда идет программирование в AX" не раскрыта.
Элементарный вопрос - Прощай "старое" программирование и Здравствуй что?
Если сейчас это X++/MorthX и желательно .NET/VS а также SSRS/ Enterprise Portal(ASP.NET) то что нас ждет в следующей версии?

Будет ли генератор кода HTML5 и JavaScripts? А если будет то насколько полноценный?

Что будет основным и рекомендуемым языком для AX2015 - X++ в VS или C#?