Как вы думаете почему прогресс средств разработки в ERP отличается от общего прогресса по отрасли (ИТ) в целом?

[fed]

Я чуть-чуть дополню и немного не соглашусь с mazzy,
Во первых в DAX2012 радикально изменились главная книга, конфигуратор продукции и ресурсное планирование. Добавился новый модуль упраления складом. Все остальное что изменилось и добавилось - это маркетинговые фичи очень ограниченного применения. При этом - только новая ГК принципиально не совместима с аксаптой по идеологии (и вообще кривой кусок дерьма). Все остальное - совместимо на уровне идеологии как раз. Так что я бы сказал что в DAX2012 - 85% кода совместима с аксаптой по идеологии, и процентов 70 - просто совместимо.
Во вторых - на уровне топ-менеджмента в MS, нормальный срок сидения на должности - это лет 5. Да - есть годовые результаты и метрики, но по моему впечатлению, чтобы тебя слили, надо зафакапить два годовых плана подряд. На уровне среднего менеджмента - горизонт планирования - года два -три. Там подход - запилить killing featue->промаркетить себя хорошенько->Уйти в другое подразделение с повышением - работает в полный рост. Именно этому подходу обязаны своим существованием наследование таблиц, SysOperation, новая ГК и распределения, методология SureStep.
В третьих - а ты вообще уверен что прогресс в средствах разработки - он реальный а не маркетинговый ? То есть - с точки зрения enterprise, последняя технология, которая реально окупала свое внедрение была трехзвенка, внедренная аж 20 лет назад. Все что было после - это были попытки (пусть и успешные) выдать все новые и новые поколения весьма нишевых технологий за очередную технологическую панацею. Со средствами разработки, картина примерно аналогичная. Да - наверное с generics, замыканиями и итераторами на уровне языка можно было бы писать код местами покрасивее и побыстрее, но особого прорыва это бы не произвело.

[mazzy]

Цитата:

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

Я чуть-чуть дополню и немного не соглашусь с mazzy,

ура!

Цитата:

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

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

согласен про функционал.
не согласен про платформу.

убрали старые отчеты и добавили Reporting Service именно в 2012

добавили в платформу пре- пост- EventHandler'ы и делегаты именно в 2012, а уже потом в акс7 эти инструменты стали использоваться в полный рост в экстеншенах. и уже сильно потом случился code seal и перевод всех модификаций в... пре- и пост- обработчики. понятно, что потом техника и реализация этих инструментов изменилась. но появились то они в 2012. это значит, решение по ним было принято еще раньше.

Опять же компиляция в CIL появилась именно в 2012. пусть и в режиме опции.

Цитата:

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

Так что я бы сказал что в DAX2012 - 85% кода совместима с аксаптой по идеологии, и процентов 70 - просто совместимо.

согласен.

Цитата:

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

Во вторых - на уровне топ-менеджмента в MS, нормальный срок сидения на должности - это лет 5. Да - есть годовые результаты и метрики, но по моему впечатлению, чтобы тебя слили, надо зафакапить два годовых плана подряд. На уровне среднего менеджмента - горизонт планирования - года два -три. Там подход запилить killing featue->промаркетить себя хорошенько->Уйти в другое подразделение с повышением работает в полный рост. Именно этому подходу обязаны своим существованием наследование таблиц, SysOperation, новая ГК и распределения, методология SureStep.

угу. возможно ты прав насчет сроков. но мне кажется, что процессы сильно ускорились с того времени, как ты там был. мне кажется, что глобальная причина - уход стабильного Билла Гейтса и Балмера и период безвластия пока идет возня на самом верху.

но тут могу сильно ошибаться.

мне кажется, что можно отделить период Кирилла Татаринова и период Сатьи Наделы. Где-то между произошли очень сильные изменения.

Цитата:

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

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

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

Цитата:

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

Да - наверное с generics, замыканиями и итераторами на уровне языка можно было бы писать код местами покрасивее и побыстрее, но особого прорыва это бы не произвело.

дело не в красоте и быстроте.
дело в стоимости разработки и поддержки.

покопавшись в Котлине, я точно уверен, что генерики уменьшают стоимость разработки библиотеки и стоимость изучения библиотек.

я точно уверен, что перегрузка методов уменьшает стоимость программирования.
просто ломает возвращаться в джаву первого поколения (X++), попрограммировав в других языках. в той же java 8

абсолютно точно уверен насчет итераторов. уменьшают стоимость разработки. даже в X++
https://github.com/mazzy-ax/SysEnumerators

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

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

в общем, на мой взгляд, стоимость разработки снизилась бы существенно, если бы просто начали использовать C# или довели X++ до текущего развития C#.
Совместимость они жеж все равно потеряли в ax7

[belugin]

Цитата:

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

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

Продвинутые типы данных и средства автоматического рефакторинга это еще и уменьшение количества ошибок (как за счет контроля так и за счет большей понятности для читателя).

Хотя у меня есть некоторое ощущение регресса в с точки зрения простоты работы для прикладных программистов. Например простую форму для работы с базой данных сделать проще было на Delphi чем на C#, ориентация на сервисы заставляет думать в терминах сетевого взаимодействия а не предметной области и так далее.

[Lemming]

Цитата:

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

Хотя у меня есть некоторое ощущение регресса в с точки зрения простоты работы для прикладных программистов. Например простую форму для работы с базой данных сделать проще было на Delphi чем на C#

В 3-й (а так же 4-й и 2009-й) аксапте простую форму тоже легко было сделать и те кто пришел из Delphi штамповали их "как горячие пирожки". Я насмотрелся форм, в которых вывод в Excel был прописан прям в методе clicked (или как там его, уже не помню) кнопки "Печать". Или когда люди упаковывали в статический метод всю бизнес-логику какого-нибудь процесса, а что бы навести в этих километрах кода хотя бы какую-то инкапсуляцию использовали локальные функции. Это реально бравые дельфи программисты. Вся суть этой простоты в аксапте ранних версий сыграла не последнюю роль в том, что ходили шуточки про 90% провальных внедрений. Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!

[axm2017]

Цитата:

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

... Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!

Цель подозреваю была не в новых программистах а в простоте, быстроте и легкости модификации системы под нужды предприятия.

[fed]

Цитата:

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

В 3-й (а так же 4-й и 2009-й) аксапте простую форму тоже легко было сделать и те кто пришел из Delphi штамповали их "как горячие пирожки". Я насмотрелся форм, в которых вывод в Excel был прописан прям в методе clicked (или как там его, уже не помню) кнопки "Печать". Или когда люди упаковывали в статический метод всю бизнес-логику какого-нибудь процесса, а что бы навести в этих километрах кода хотя бы какую-то инкапсуляцию использовали локальные функции. Это реально бравые дельфи программисты. Вся суть этой простоты в аксапте ранних версий сыграла не последнюю роль в том, что ходили шуточки про 90% провальных внедрений. Но цель привлечь много программистов в новую на рынке систему за счет простоты - была достигнута!

Во первых - привлечение программистов в новую на рынке систему вызывается не простотой системой, а экономическими причинами. (То есть - соотношением между зарплатой, спросом, возможностью работать в качестве фрилансера и тп).
Во вторых - по моим собственным наблюдениям, эдак в 85% случаев кривое программирование было вызвано не тем, что программист плохой, а тем что "надо сделать к завтрашнему утру", "бюджета уже почти не осталось", "вот тут клиент посмотрел и попросил слегка изменить - это же 15 минут работы" и тп.
В третьих - по моим наблюдениям, реально плохие программисты, вооруженные голым фортраном, они не так опасны, как реально плохие программисты, вооруженные перегрузкой операций, итераторами, замыканиями и тд и тп.