Прощай, X++

[belugin]

Цитата:

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

ВЗамена наглядного "программирования мышкой" на нечитаемых кадавров автогенерированного кода из VS это откровенная деградация продукта.

Это ты про что? Почему нельзя выкинуть X++ и оставить на месте MorphX?

[belugin]

Вот, кстати, пример

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

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

[macklakov]

Цитата:

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

Почему нельзя выкинуть X++ и оставить на месте MorphX?

Вот именно. Но в 2012 как-то так получилось что перенося свистелки и перделки сомнительной ценности из .Net, MorphX малость погнули, где-то даже поломали. Отсюда и проистекает немного нервная реакция на нововведения.

Цитата:

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

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

95% времени у них все хорошо и ради 5% проблемных случаев большинство не видит смысла в изучении сути, скрытой разработчиками компилятора.

Я сам такой же

[belugin]

Цитата:

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

MorphX малость погнули, где-то даже поломали.

А где поломали-то?
Я вот навскидку кроме пенеоса рилейшенов из EDT на таблицы не могу вспомнить чего-то старого поломанного (не путать с новым). Может просто привык уже.

[AndyD]

За не всегда работающие диналинки - руки бы поотрывал

[Logger]

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

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

[perestoronin]

Цитата:

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

И этими наглядными короткими математическими формулами вы будете рисовать и работать с GUI? Или 20 минут на прекрасное наряду с парой дней на копание с
JavaFX или Swing GUI библиотеками? Там уже не до красивостей будет.

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

Все что нужно бойцу на реальном фронте бизнес-приложений это GUI ориентированные инструменты и удобство работы с базой данной.

И боевой программист, тот который в окопе на линии огня, при всей своей любви к прекрасному С++ будет рад тому же Visual Studio и даже Visual Basic именно из-за GUI и удобства работы с данными. Потому как в окопе прекрасное только сниться.

Тому же MorthX и X++ цены нет если смотреть на разработку не как на кодинг а как на продукт вашего труда у которого основной фокус на потребителе, а не на невидимом совершенстве которого никто не оценит.

Ценность кода (как результата труда программиста) - как легко Вы его сами сможете прочитать как автор и сколько времени потребуется на его восприятие Вам же скажем через год, или сколько времени нужно, чтобы Ваш код понял другой разработчик, или сколько времени нужно чтобы Вы поняли код другого разработчика.

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

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

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

X++ увы, как и модный C#, не являются таковыми, хотя широко другие языки и не используются пока ещё.

На счет GUI и в частности веб-интерфейса для приложений:
http://habrahabr.ru/post/152067/

Цитата:

Когда вы пишете на Lift вы пишите раза в 2-3 меньше кода, чем если бы писали на java-фреймворке (например один прогер переписал свой проект с Play на Lift, на Play у него реализация заняла 24k строк, а на Lift 6k). А если сравнивать с фреймворками типа Spring MVC / Struts то разница будет еще больше.

[ax_mct]

Цитата:

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

Ценность кода (как результата труда программиста) - как легко Вы его сами сможете прочитать как автор и сколько времени потребуется на его восприятие Вам же скажем через год, или сколько времени нужно, чтобы Ваш код понял другой разработчик, или сколько времени нужно чтобы Вы поняли код другого разработчика.

Код это результат работы кодера.

Редкий код нельзя прочитать и понять. Всегда понятно что код делает (в машинном смысле) даже если он не оптимизирован или грязно написан.

Но практически всегда возникают вопросы "зачем" с точки зрения решаемой задачи.
И тут все равно в разы там меньше или больше кода в отдельно взятом методе/функции.

Что действительно имеет значение так это программный дизайн решения, распределение кода по методам и объектам, соответственное их наименование. Только это и может помочь понять что как работает решение (наряду с комментариями в коде).

А проблема чтения строчек кода в отдельно взятом методе - это не существующая трудность.

Цитата:

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

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

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

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

Цитата:

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

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

X++ увы, как и модный C#, не являются таковыми, хотя широко другие языки и не используются пока ещё.

Сюр какой-то. Как то не культурно переходить на личный опыт и на личность, но такое впечатление что сын использует папин логин.
То есть вы не обижайтесь, но программист с коммерческим опытом (то есть не зеленый студент прочитавший взахлеб все три тома Дональда Кнута) такое не напишет (на мой взгляд). Но я вам очень благодарен за поддержание дискуссии, в обмене мнений учатся все и я не исключение. Просто мы какие то очень разные и я пытаюсь понять в чем дело.

Цитата:

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

На счет GUI и в частности веб-интерфейса для приложений:
http://habrahabr.ru/post/152067/

"Когда вы пишете на Lift вы пишите раза в 2-3 меньше кода".

Опять про компактность кода.
То что в методе вместо 30 строк будет 10 строк - это на что влияет? Скорость чтения кода повышается в три раза?

Не влияет "мощность" языка (то есть его более лаконичные или даже более "математические" конструкции) на скорость программирования и стоимость разработки.
Если и влияет то в отрицательную сторону.

Так же как и разгон супермощного автомобиля в два раза быстрее (4 сек вместо 8 сек) и на 100 км/ч большая максимальная скорость (250 км/ч вместо 150 км/ч ) ни на что не влияют в реальных городских условиях. Приятно конечно за рулем посидеть но собственно и все.
Так и собственно в реальном мире программирования происходит - оптимальный маршрут и грамотное вождение. А Форд это или Феррари - нерелевантно.

[belugin]

Цитата:

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

По-моему табличные мапы неплохо справлялись со своими обязанностями.

Возьмем, например, \Data Dictionary\Maps\CustVendTable\Methods\balanceMST
Первым вызовом там идет:

 CustVendTrans   custVendTrans = this.transBuffer();

Давайте посмотрим на его реализцию - переводим курсор, нажимаем F12 и ничего не происходит.

Почему? Потому, что такого метода нет. Вернее он есть только в подмапленных таблицах. Но это никак не контролируется. В результате:

• У нас нет перекрестных ссылок на этот метод
• Мы никак не узнаем если случайно напишем transBufer
• Если кто-то захочет поменять сигнатуру transBuffer ему придется пользоваться поиском

Про большинство ошибок такого типа мы узнаем только в рантайме и только когда выполнение туда дойдет.

Также никак не контролируется подмапливание всех полей (например прям сейчас PatyType не подмаплен). Название поля часто дублируется:
(для добавления поля X всюду нужно добавить в мап, добавить в n таблиц и n меппингов рискуя ошибиться на каждом этапе)

Цитата:

Выигрыш от наследования - неочевиден. Глюков в коде точно прибавилось.

Это вопрос качества реализации. В-общем, ваша претензия это не "Испортили что-то существующее в MorphX", а "сделала что-то новое недостаточно на ваш взгляд качественное и испортили приложение использованием этого"

[perestoronin]

Цитата:

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

Редкий код нельзя прочитать и понять. Всегда понятно что код делает (в машинном смысле) даже если он не оптимизирован или грязно написан.

Прочитать то можно, но пока дойдешь по второй "страницы" можно уже забудешь что было написано на первой странице. Современные системы не должны быть "разовым чтивом". Код должен быть коротким и математически чистым и полностью ясным без заметных затрат на его "исследование" - это безапелляционно
Scala и Lift поспособствуют облегчению труда программиста и повышению читаемости кода и его надежности, и некоторые другие современные тренды тоже могут пригодиться для этого, в том числе C#v6.0. Мне кажется еще не безнадежно устарел X++, да и правок в нем много не потребуется, другое дело, что если сама реализация X++ в ядре системы написана в стиле "разового чтива", то не удивительно что к развитию X++ у компании-разработчика большого рвения не наблюдается, т.к. любая даже незначительная правка языка X++ будет даваться только ценой героических затрат.

[ax_mct]

Пример
Есть метод SettleNow() в классе CustVendSettle - сопоставление транзакций.
Возможно самый большой метод в AX по количеству строк кода.

Вопрос
Если бы программисты при создании этого метода использовали вместо X++ более "мощные" Scala или C#v6.0 (или даже C#v10.0) стал бы этот метод "коротким и математически чистым и полностью ясным без заметных затрат на его "исследование""?

Возможны мы разное вкладываем в понятие "код". Для меня это состав материала кирпичей, когда после обжига не так и важно какие там примеси. Постройка здания - важнее.

То есть c X++ так же можно применять нужную архитектуру решения, проектирования объектов как и с Scala или C#. И программисты без понимания ООП (или в жестких временных рамках) точно так же и на C# v10.0 будут создавать нечто трудное для восприятия.

И кстати скорее всего еще и менее понятное - в случае более лаконичного кода. Сам по себе язык программирования тут ни причем - это как русский противопоставлять английскому по поводу создания нетленных произведений.

[perestoronin]

Цитата:

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

Пример
Есть метод SettleNow() в классе CustVendSettle - сопоставление транзакций.
Возможно самый большой метод в AX по количеству строк кода.

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

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

[belugin]

Цитата:

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

Если бы программисты при создании этого метода использовали вместо X++ более "мощные" Scala или C#v6.0 (или даже C#v10.0) стал бы этот метод "коротким и математически чистым и полностью ясным без заметных затрат на его "исследование""?

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

Цитата:

Возможны мы разное вкладываем в понятие "код". Для меня это состав материала кирпичей, когда после обжига не так и важно какие там примеси. Постройка здания - важнее.

В случае x++ кирпичи появляются кривее, чем могли бы.

Цитата:

То есть c X++ так же можно применять нужную архитектуру решения, проектирования объектов как и с Scala или C#.

В x++ правильное ооп имеет запретительного сложность.

Цитата:

И программисты без понимания ООП (или в жестких временных рамках) точно так же и на C# v10.0 будут создавать нечто трудное для восприятия.

И кстати скорее всего еще и менее понятное - в случае более лаконичного кода. Сам по себе язык программирования тут ни причем - это как русский противопоставлять английскому по поводу создания нетленных произведений.

австралиец не поймёт, если его попросят посчитать, сколько он видит деревьев, животных и птиц, он конкретно назовёт вид животного или породу дерева. Скажем, если австралиец увидит пять какаду и три страуса он не скажет «восемь птиц», для австралийских аборигенов это слишком абстрактное понятие.

[ax_mct]

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

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

[LeonDerCom]

[offtop]Ура, холивар. :-D[/offtop]
По поводу русских и других языков - забавное сравнение. Но напомню, что кисть в руках гения сможет написать великое произведение на любом языке и любом алфавите, а позже его интерпритации в переводе будут перечитывать и знатоки любых других языков. И если человек - деревянный, то вы ему хоть большими буквами напишите - он и на своем языке не поймет. Ну вы поняли к чему я.
Кирпичи - технология производства и отношение строителей с архитекторами и т.д. зависит от их мотивации. Иначе они либо заявят о бракованном кирпиче и заменят его, либо будут из полученного стороить "на совесть". А Джамшут и из качественного сырья слепит к...шку.
По поводу доводов о величине кода - такое впечатление борьба тех, у кого хреново с краткосрочной памятью и хорошо с долгосрочной со своими антиподами, либо эстетов с практиками...
Разговор в стиле - чем отличается инженер от математика и кто из них круче решит задачу на определение сопротивления боевой части баллистической ракеты определенной формы? По секрету, целесообразность решения зависит от ограничений и оптимума. ;-)

[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 а автомобиль это программист