Прощай, X++

[macklakov]

Цитата:

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

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

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

[belugin]

Цитата:

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

но читать и дебажить их почти так же трудно, как регулярные выражения.

Почему?

[macklakov]

Цитата:

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

Почему?

Ну насколько помню, там breakpoint не на что поставить. И рекурсии на каждом шагу. А еще возможность написать всю программу в одну строку. Ну и конечно же ФП чемпион по возможностям мета-программирования.
Лучше такой инструмент в руки прикладных аксапщиков не давать. Я бы и контейнеры с макросами убрал бы от шаловливых ручек подальше.

[Logger]

Цитата:

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

Ну насколько помню, там breakpoint не на что поставить. И рекурсии на каждом шагу. А еще возможность написать всю программу в одну строку. Ну и конечно же ФП чемпион по возможностям мета-программирования.
Лучше такой инструмент в руки прикладных аксапщиков не давать. Я бы и контейнеры с макросами убрал бы от шаловливых ручек подальше.

Вот-вот !
Нужно думать еще о том какого уровня спецы будут потом систему поддерживать.
Спички детям не игрушка.

[ax_mct]

Цитата:

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

Вот-вот !
Нужно думать еще о том какого уровня спецы будут потом систему поддерживать.
Спички детям не игрушка.

Читаю и боюсь программистов для которых "красота" кода или сокращение его строчек важнее всего. Eй богу страшно стало. Я даже не знаю кто хуже - русские "гении" способные сократить код в три раза или индусы не понимающие ООП и дублирующие код где только возможно.

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

И бог с ним с X++, какая разница на чем программировать. Но если вдруг это приведет к тому что в AX будут программировать junior .NET программисты без опыта в AX то мне жалко и клиентов и систему. Не в синтаксисе дело.

[dech]

Цитата:

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

Читаю и боюсь программистов для которых "красота" кода или сокращение его строчек важнее всего. Eй богу страшно стало. Я даже не знаю кто хуже - русские "гении" способные сократить код в три раза или индусы не понимающие ООП и дублирующие код где только возможно.

Простите, но если вы даже на Х++ будете писать "код с душком", коллеги вас когда-нибудь побьют.

[ax_mct]

Цитата:

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

Простите, но если вы даже на Х++ будете писать "код с душком", коллеги вас когда-нибудь побьют.

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

Душок, не душок, но если нет ошибок Best Practices - значит код допустимый.
Я не про свой код, а про свое отношение к нему.

То есть я к тому что я искренне не понимаю когда для программистов красота кода на первом месте. На моей планете этой красоты просто никто не оценит и не увидит. Совсем другие условия работы со взглядом не со стороны программиста а со стороны клиента когда в конце этого туннеля до кода взгляд и не доходит.

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

P.S. Вот что сразу вымораживает так это использование СиШарпного стиля в X++. Прежде всего наименование переменных. Вот это я считаю проблемой и в С# и в X++ когда каждый программист со своим стилем.

[belugin]

Цитата:

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

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

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

Эти вещи характерны тем, что имеют отложенный эффект ( См. понятие "технический долг". )

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

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

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

Например простейшие рефакторинги из Resharper (типа переименование переменной, выделить метод), которые этот инструмент делает быстро и гарантированно безопасно, в X++ часто дороги и рискованны, поэтому от них часто отказываются.

Сам язык X++ не позволяет создавать неймспейсы и иметь внутренние классы и т.д. в результате много модификаций сводится к изменению существущего кода, а не к его расширению к тому же пропадает формальное разделение на модули и интерфейс модулей становится непонятным (нельзя сказать "пользуйтесь вот этими классами, а эти - детали реализации").

и т.д.

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

[ax_mct]

Цитата:

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

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

Такова суть AX - заплатки и обновления. Куча. Смена языка ничего не изменит. И строгие пространства имен и прочее ни на что не повлияют в этом плане. Это всего лишь гаечный ключ к монстру Как я понимаю смена языка и среды разработки только увеличивает время разработки. И все. Зато хорошо звучит то что можно найти больше программистов и слепить еще большего монстра

[belugin]

Цитата:

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

Ну насколько помню, там breakpoint не на что поставить.

В F# можно (есть еще REPL), в C# в лямбдах нельзя.

Цитата:

И рекурсии на каждом шагу.

А это чем мешает?

Цитата:

А еще возможность написать всю программу в одну строку.

Такие программы дебажатся при помощи repl

Цитата:

Ну и конечно же ФП чемпион по возможностям мета-программирования.

ФП и метапрограммирование параллельны. Сравните Lisp nemerle и какой-нибудь F#.

Цитата:

Лучше такой инструмент в руки прикладных аксапщиков не давать. Я бы и контейнеры с макросами убрал бы от шаловливых ручек подальше.

LINQ в C# этот как раз ФП для немытых масс. + больше возможностей реализовать open closed principle (убрать от шалдовливых ручек правку исходников, а всместо этого давать расширять)

[Diman]

Цитата:

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

Ну насколько помню, там breakpoint не на что поставить. И рекурсии на каждом шагу. А еще возможность написать всю программу в одну строку. Ну и конечно же ФП чемпион по возможностям мета-программирования.
Лучше такой инструмент в руки прикладных аксапщиков не давать. Я бы и контейнеры с макросами убрал бы от шаловливых ручек подальше.

Брекпоинты ставить можно во многих ЯФП, правда не везде, но если правильно код написан, то и отладка в тех местах не нужна. В ФП много разных вкусностей, но увы, это не про X++ и даже не про С#.

А вот за контейнеры, согласен, я б их вообще запретил, а еще c anytype что-то надо сделать на этапе компиляции.