mfp: X++ the most extensible language on the planet!

[ax_mct]

Цитата:

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

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

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

Те же Netsuite, SalesForce предоставляют API к транформаторной будке и это намного честнее. В чем крутизна хитро-изогнутых инструментов X++ если нельзя ими лазить - непонятно.

Поэтому лучше бы MFP посыпал голову пеплом. Мальчишки-живодеры.

Я кстати написал там у него вежливый но саркастичный комментарий два дня назад, но полагаю что его не пропустят. Например я задал вопрос как много сейчас программистов X++ v.7-8 во всем мире вне стен Microsoft. И пожалел что пока еще нет лямбд и шаблонов на уровне языка.

[belugin]

Цитата:

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

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

Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.

Цитата:

Те же Netsuite, SalesForce предоставляют API к транформаторной будке и это намного честнее.

Это что значит?

Цитата:

В чем крутизна хитро-изогнутых инструментов X++ если нельзя ими лазить - непонятно.

Как это нельзя? Можно но не всюду. Невозможно сделать обратно совместимое API, где можно вообще все.

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

[ax_mct]

Цитата:

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

Зависит от того, что значит "изменять функциональность". В разрешенных местах можно вроде. Драйвера поддерживаются в рамках одного поколения API.
..
Это что значит?
..
Как это нельзя? Можно но не всюду. Невозможно сделать обратно совместимое API, где можно вообще все.

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

API означает более или менее неизменный интерфейс и определяет границы дозволенного.

Самый расширяемый язык X++ (читай D365FO) не имеет таких интерфейсов, а предлагает сверлить и подвешиваться где только сможешь.
При этом нигде не говорится о концепции и границах дозволенного. Все рассматривается только со стороны технических возможности.

Опытные программисты AX по инерции используют те же границы дозволенного к которым они привыкли. Клиенты по инерции рассматривают как ту же платформу разработки которая переехала в web. И данная инерция движения и мысли провоцируется и поощряется вот такими вот статьями.

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

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

Цитата:

менять процессы порождающие проводки можно

Уверены? По идее все от зависит от нюансов. Что-то можно, а что-то нельзя, но кто это будет оценивать и на какой стадии?

[belugin]

Цитата:

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

API означает более или менее неизменный интерфейс и определяет границы дозволенного.

Самый расширяемый язык X++ (читай D365FO) не имеет таких интерфейсов, а предлагает сверлить и подвешиваться где только сможешь.
При этом нигде не говорится о концепции и границах дозволенного. Все рассматривается только со стороны технических возможности.

Я думаю на эту тему в терминах design-by-contract, ковариантности, контравариантности и обратной совместимости.

Цитата:

Уверены? По идее все от зависит от нюансов. Что-то можно, а что-то нельзя, но кто это будет оценивать и на какой стадии?

Я имею ввиду гипотетичекскую альтернативную реальность в которой разделяем приложение разделено на две части - в одном модули которые можно легко обновить на новую версию с продуманным интерфейсом расширения, а в другой - "скрипты", которые можно править, но при этом новая версия не является обратно совместимой. То есть возможен ли некий компромисс. Условно говоря, как в линуксе - можно написать приложение, используя API, а можно поменять исходный код ОС. Или как в игровых движках (тут я не специалист но вроде там так) ядро .из основных понятий и скрипты (насколько я знаю, там даже другие языки для них используют чем для ядра - типа lua).

[ax_mct]

Цитата:

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

Я думаю на эту тему в терминах design-by-contract, ковариантности, контравариантности и обратной совместимости.
...
Я имею ввиду гипотетичекскую альтернативную реальность в которой разделяем приложение разделено на две части - в одном модули которые можно легко обновить на новую версию с продуманным интерфейсом расширения, а в другой - "скрипты", которые можно править, но при этом новая версия не является обратно совместимой. То есть возможен ли некий компромисс. Условно говоря, как в линуксе - можно написать приложение, используя API, а можно поменять исходный код ОС. Или как в игровых движках (тут я не специалист но вроде там так) ядро .из основных понятий и скрипты (насколько я знаю, там даже другие языки для них используют чем для ядра - типа lua).

А я в терминах бизнеса. Самое важное в этом бизнесе правильно оценить возможность и трудоемкость задачи. Вовремя при этом сделать. Какое-то расхождение до 20% считается приемлимым. С новыми лабиринтами браться за программисткие задачи - это неприемлимый риск уже на стадии оценки.

Все уже придумано. Легион продуктов и фрэймоворков. Наиболее популярный подход с использованием предопределенной файловой структруры. Когда мы просто создаем директории и файлы которые подхватываются системой. При этом базовый код не редактируется. Это уже даже некий стандарт.

В облачных ERP типа SalesForce и NetSuite это API. Так как падение wordpress, Yii и прочих web сайтов это не то же самое как падение ERP. (Хотя для онлайн-магазин это тоже больно, но грабли уже всем известные и потому комфортные).

Цитата:

Пишите код на языке программирования Apex для добавления бизнес-логики или на языке разметки Visualforce (для
создания пользовательского интерфейса). Интегрируйте свое приложение с помощью API-интерфейсов и проводите
проверку подлинности своих внешних приложений.

https://resources.docs.salesforce.co...xtend_code.pdf

Теорeтечески ISV решения для D365FO имеют потенциал. Но они опять таки разумны если делать боковой или паралельный фунционал, не меняя сами существующие процессы. Но с таким сбоку не важно чем, слоями, расширениями или API, снижение рисков за счет функциональной отвязанности.

У меня есть несколько своих вертикальных решений которые я бы в других условиях сделал бы для AppStore D365FO. Но я даже не в состоянии оценить ровно ничего. А на оценке строится бизнес.

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