|
27.07.2019, 10:25 | #1 |
Участник
|
Цитата:
Цитата:
в котором взвешенно оценивались последствия и необходимые усилия перевода аксапты на c#. Документ был написан в духе "не нарушить совместимость". прежде всего по разному обрабатываются строки с ограниченной длиной. в C# все строки бесконечной длины, а в X++ сроки с edt всегда тримятся и обрезаются. в результате констркуции типа AccountNum+AccountName могут дать разный результат в C# и в X++ также очень много говорилось о клиент-серверном взаимодействии в Аксапте. А также о сборщике мусора, времени жизни объектов. Ну и пресловутые ключевые слова select, update_recordset и т.п. По ним в документы были очень любопытные предложения. В общем, очень взвешенный и очень качественный документ. Насколько я понимаю, руководство тогда побоялось резких изменений и побоялось объема работ по несовместимости. А потом... херакс! и ax7. полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось. А все почему? А руководство поменялось. Цитата:
Вопрос подразумевает, что в ИТ мейнстрим. Нет, мейнстрим - это как раз ЕРП, легаси и корпоративный софт. А всякие реакты, докеры и прочие кубернетики - это очень дальний фронтир, на котором все может поменяться в несколько ближайших лет. другое дело, что например в X++ вполне можно было бы задействовать и перегрузку методов и генерики. Но пока команда занимается другими вещами - делает из открытой системы закрытую с плагинами и точками расширения (кстати, тоже холивар давно минувших дней) и переводит исходный код из хранилища aod/utilElements в файлы (тоже очень древняя тема). =========== Во-вторых - а почему так происходит? Не почему позади фронтира (это то как раз понятно), а почему так лоскутно и усложненно? ("все усложнилось на «бэкенде»") помимо компиляции в CIL можно вспомнить: * роле ориентированный интерфейс * ListPage * корпоративный портал (привнес web объекты в AOT, выкинут) * корпоративный портал на SharePoint (привнес DataSet объекты, выкинут) * OLAP (те же Data sets, выкинуто) * Partitions (выкинуты) * виртуальные компании выпилили поскольку не разобрались как с ними работать во внешних системах * наследование таблиц (введено и выпилено в следующем сервис-паке) * Permissions в коде на сервере, будь они не ладны * отчеты на Reporting Service и соглашение о dataContracts * новая и улучшенная схема размещения контролов в ax2012 * SysOperationProgress и пресловутый фрейворк, который все не может заменить * подзадачи в пакетном сервере * "суперэффективное" хранение кода в SQL базе было выпилено и заменено на "традиционное" хранение кода в файлах (но при этом почему-то как xml, му-ха-ха) * полностью прибили клиентский код в ax7 (может и вернут: людям надо работать с оформлением формы, людям надо создавать свои контролы на форме, людям надо работать с оборудованием клиентского компьютера, см Retail) * закрыли код и ввели расширения. Но при этом не хватило умений добавить точки расширения в длиннющие методы на несколько сотен строк (а такая технология есть конечно. например, весь движок этого форума построен на плагинах) * перевели в ажур, но для этого отобрали админский доступ к СВОЕЙ базе данных и возможность отладки в Проде и так далее. поэтому нельзя сказать, что совсем ничего не делается. делается. активность зашкаливает. но эта активность носит какой-то фрагментарный и только усложняющий жизнь потребителя характер. причина по моему - система работы руководителей в крупных корпорациях. руководитель назначается на некоторый период. как правило на 1 (один) финансовый год. причем в современных реалиях этот период заведомо меньше, чем время, необходимое для реально полезного изменения системы. так, ax7 была явно переходной системой. да и ax8 концептуально готовой не назовешь. понятно, что перевод с X++ на C# - это огромный проект, который за один финансовый год точно не выполнить. также можно вспомнить проект Electronic Reporting (ER), который длится уже несколько финансовых лет. И опять же нельзя сказать, что он готов к конкуренции с уже существующими на рынке решениями. Что делать руководителю, у которого мандат на 1 год и задачи длительностью в 3-5 его мандатов? А выбирать "киллер-фичи", которые хотя бы предположительно можно сделать за 1 год. См. список выше. Сделал? ну хоть KPI какие-нибудь выполнил? молодец! А что дальше? Дальше он пойдет по карьерной лестнице на другую должность. Ась? Что-что? Пользователи? вот же, они получили такую замечательную киллер-фичу. Радуйтесь. Причем, что я вынес для себя лично во время работы в МС. в МС дураков нет. Все всё понимают. И рядовые сотрудники, и руководители. Но сделать ничего не могут. Причем когда я там был, то уже рядовые сотрудники уже и не пытались что-то с этим сделать. ============= В вопросе звучал 1С. В 1С на самом деле то же самое. Там конечно Нуралиев Б. и Нуралиев С. гораздо ближе к земле, поэтому не настолько запущено. Но и там есть руководители. Да их сроки не настолько жесткие как в МС. Но в принципе то же самое. Про САП. Там, насколько я понимаю, все сильно жестче со сроками и KPI, чем в Майкрософт. Наружу проявляется в том, что директора российского подразделения меняются в последнее время чаще чем раз в год что с этим делать - хз. |
|
|
За это сообщение автора поблагодарили: EVGL (3), trud (5), Lemming (5), twilight (1), apanko (4). |
28.07.2019, 20:41 | #2 |
Участник
|
А еще есть гигантский модуль под названием "ApplicationSuite" который при генерации IL приходится разбивать на netmodule и для конвертации в C# пришлось бы рейфакторить на подмодули, разруливать перекрестные ссылки и так далее.
А еще есть всякие extensibility фичи типа подписки на начало и завершения любого метода. В-общем, попробуйте взять любой свой модуль, написанный на X++ и декомпилировать в C# - посмотрите на что был бы похож эквивалентный код. Цитата:
А потом... херакс! и ax7. полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось.
Во-вторых, сейчас я вижу документацию по апгрейду. В-третьих, обратная совместимость нужна для своего собственного application suite (соответственно трата сил и порождение большего количества глюков) Цитата:
А все почему? А руководство поменялось.
Цитата:
* "суперэффективное" хранение кода в SQL базе было выпилено и заменено на "традиционное" хранение кода в файлах (но при этом почему-то как xml, му-ха-ха)
Цитата:
* полностью прибили клиентский код в ax7 (может и вернут: людям надо работать с оформлением формы, людям надо создавать свои контролы на форме, людям надо работать с оборудованием клиентского компьютера, см Retail)
Цитата:
понятно, что перевод с X++ на C# - это огромный проект, который за один финансовый год точно не выполнить.
Последний раз редактировалось belugin; 28.07.2019 в 20:52. |
|
29.07.2019, 07:46 | #3 |
Участник
|
макс, ты очень интересно формулируешь ответ
"есть" - это разработчики в майкрософт сделали. а попробовать ты предлагаешь нам в качестве доказательства что что-то невозможно сделать. если невозможно, то нахрена майкрософт перевел в режим "есть"? Цитата:
блин. Цитата:
И что это доказывает? Цитата:
Сообщение от belugin
Во-вторых, сейчас я вижу документацию по апгрейду.
Цитата:
по данному вопросу - это какому? что руководство поменялось? а какая разница то ради чего? я говорил о том, что решения вводятся в код и сразу же отменяются. именно ввод-отмена и делает "все усложнилось на «бэкенде»" каждая введенная и отмененная фича в моем списке вводилась ради чего-то. и для отмены также находились очень важные причины. вопрос не в причинах. вопрос - почему приоритеты причин меняются. Цитата:
Сообщение от belugin
Свои контролы делать можно см. "extensible controls" => клиентский код есть, только он не на X++ а на JavaScript
ты сейчас чего доказать то хочешь? что выпиливание клиентского x++ - это было суперправильное решение, которое не отменят? что x++ на клиенте не нужен, а нужен javaScript? тогда зачем вообще нужен X++ - оставили бы сразу javaScript ну и так далее. Макс, давай от охранительства вернемся к теме, пожалуйста. тема: "Как вы думаете почему прогресс средств разработки в ERP отличается от общего прогресса по отрасли (ИТ) в целом?" с тем же выпиливанием клиентского x++... Как ты думаешь, "только серверный код" - это в русле общего прогресса по отрасли? если отличается, то почему и какой смысл в отличии? если отличается, то можно ли ожидать возврата к общему состоянию отрасли ИТ? Цитата:
сразу вопросы: если равноправных больше одного, то почему только два? может и SQL сделать полноправным? и javaScript для клиентского кода? где граница? причем не граница возможностей производителя, а логически обоснованная граница? что ты подразумеваешь под равноправностью языков? (у меня есть свои соображения, то я бы хотел твои рассуждения послушать) мы видели много анонсов инноваций, которые умирали не появившись или сразу после ввода. можешь дать какую-то надежду, что будет несколько равноправных языков? причем разработка в условиях нескольких равноправных языков будет экономически целесообразна как для вендора, так и для потребителя. |
|
|
За это сообщение автора поблагодарили: Lemming (5). |
29.07.2019, 09:45 | #4 |
Участник
|
Цитата:
Цитата:
а попробовать ты предлагаешь нам в качестве доказательства что что-то невозможно сделать.
Цитата:
если невозможно, то нахрена майкрософт перевел в режим "есть"?
Цитата:
где я такое говорил? приведи цитату и логический переход от цитаты к твоему утверждению.
блин. Я так понял, что первое приложение раскрывается вторым, нет? Цитата:
А может не заработает.
И что это доказывает? Цитата:
а тогда - не было
конечно гипотеза. Цитата:
а какая разница то ради чего?
Цитата:
становится как-то смешно.
ты сейчас чего доказать то хочешь? что выпиливание клиентского x++ - это было суперправильное решение, которое не отменят? что x++ на клиенте не нужен, а нужен javaScript? Цитата:
тогда зачем вообще нужен X++ - оставили бы сразу javaScript
Цитата:
ну и так далее.
Макс, давай от охранительства вернемся к теме, пожалуйста. Цитата:
с тем же выпиливанием клиентского x++... Как ты думаешь, "только серверный код" - это в русле общего прогресса по отрасли? если отличается, то почему и какой смысл в отличии? если отличается, то можно ли ожидать возврата к общему состоянию отрасли ИТ?
Сейчас интересны попытки использховать WebAssembly (например blazor) но это не лишено недостатков. Например blazor призодится загружать сборки mono и это ощутимый penalty на старте. Там даже сделали режим когда все рендерится на сервере и посылается в таком виде клиенту. Цитата:
Можно и так:
сразу вопросы: если равноправных больше одного, то почему только два? может и SQL сделать полноправным? и javaScript для клиентского кода? где граница? причем не граница возможностей производителя, а логически обоснованная граница? Цитата:
что ты подразумеваешь под равноправностью языков? (у меня есть свои соображения, то я бы хотел твои рассуждения послушать)
Цитата:
мы видели много анонсов инноваций, которые умирали не появившись или сразу после ввода. можешь дать какую-то надежду, что будет несколько равноправных языков?
|
|
29.07.2019, 10:44 | #5 |
Участник
|
а также дамгаард же добавил модели... и не довел разделение по моделям до конца, бросив большинство функционала в одном Suite он! дамгаард. точно. возможно? ?! Цитата:
Цитата:
без комментариев. я думаю, что каждый читатель сможет сделать выводы сам. Цитата:
|
|
29.07.2019, 12:49 | #6 |
Участник
|
Цитата:
Цитата:
?!
2. Я: Ну отсутствие процедуры апгрейда не означает что она полностью несовместима, например, можно перенести код через буфер обмена и он с очень большой вероятностью заработает. 3. Маззи: где я такое говорил? приведи цитату и логический переход от цитаты к твоему утверждению. блин. 4. Я: {привожу цитату}. Объясняю откуда сделал такой вывод. ( "полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось" - я решил что второе предложение раскрывает значение первого "полностью не совместимая" потому что "предыдущих версий не предусматривалось") Цитата:
ты предлагаешь поговорить о степенях свежести осетрины?
Цитата:
А можешь высказать свое мнение на исходный вопрос?
Т.е. инерция, груз обратной совместимости (хотя бы даже для внутреннего использования). 2. Возможно, языки общего назначения сложнее и проще выстрелить себе в ногу. 3. Иновации действительно есть но в других областях, дополнительная поддержка вебинтерфейса есть у систем про которые я знаю в той или иной форме, например. |
|
29.07.2019, 13:35 | #7 |
Участник
|
Цитата:
ход мысли понятен. каждый может сделать вывод сам. Цитата:
Сообщение от belugin
1. Маззи: потом... херакс! и ax7. полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось.
2. Я: Ну отсутствие процедуры апгрейда не означает что она полностью несовместима, например, можно перенести код через буфер обмена и он с очень большой вероятностью заработает. 3. Маззи: где я такое говорил? приведи цитату и логический переход от цитаты к твоему утверждению. блин. 4. Я: {привожу цитату}. Объясняю откуда сделал такой вывод. ( "полностью не совместимая. в которой продцедур апгрейда с предыдущих версий не предусматривалось" - я решил что второе предложение раскрывает значение первого "полностью не совместимая" потому что "предыдущих версий не предусматривалось") опять же - не вижу смысла переубеждать, если ты настаиваешь на таком в публичном выступлении, то каждый может сделать вывод сам. Цитата:
твое высказывание понятно. не вижу смысла препираться дальше. Цитата:
Сообщение от belugin
1. Чтобы сделать жирную ERP надо много времени, чтобы накопить функционал => большинство из них начали делать давно. Тогда не было языков общего назначения, которые были бы непроприетарны и поддерживали втроенный SQL (SQL/J кажется был проприетарный) => пришлось создавать свой язык, после чего накопилась большая кодовая база/обучающие материалы и прочее, которое надо переводить на новый язык. Кодовая база не расчитана на ограничения современных языков общего назначения (см модули).
Т.е. инерция, груз обратной совместимости (хотя бы даже для внутреннего использования). 2. Возможно, языки общего назначения сложнее и проще выстрелить себе в ногу. 3. Иновации действительно есть но в других областях, дополнительная поддержка вебинтерфейса есть у систем про которые я знаю в той или иной форме, например. например, в java платформу ввели таки и перегрузку, и генерики, и лямбды с замыканиями. И многопоточность и потокобезопасное программирование. И стримы вот сейчас моднючие. И библиотеки под это переписали. а в Аксапте все еще java первого поколения. Неужели для Аксапты груз тяжелее, чем для Джавы, на которой Аксапта основана? Как думаешь? Последний раз редактировалось mazzy; 29.07.2019 в 14:08. |
|
29.07.2019, 14:09 | #8 |
Moderator
|
А может один большой модуль с циклическими ссылками внутри есть отражение реальности предприятия, где все процессы зависят друг от друга и не могут быть разделены?
|
|
|
За это сообщение автора поблагодарили: apanko (4). |
Теги |
1c, abap, axapta, sap, xpp |
|
|