Прощай, X++

[AP-1055D]

К тому же там C#, а речь о X++

[KindDog]

Лучше бы Python вместо шарпа вкорячили.... си плюс плюсов было бы больше

[belugin]

Цитата:

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

Лучше бы Python вместо шарпа вкорячили.... си плюс плюсов было бы больше

Как в Питоне сделать, чтобы

(x for c in employee if employee.salary >= 100)

Приводило к SQL запросу? Я, правда, перестал интересоваться этим лет 8 назад - но тогда хорошего способа не было.

[Logger]

Мне кажется основные проблемы в Аксапте не из-за языка программирования и его недостатков / преимуществ. Все что сейчас надо, можно сделать текущими средствами.

Вопрос в том что именно делать, как делать и как это продавать.

[perestoronin]

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

[pitersky]

Цитата:

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

Конечно можно и старой ржавой лопатой траншеи копать, а можно и современной машиной. Вопрос каким инструментом быстрее и менее затратнее.

"если у вас есть молоток, то вы со всем будете обращаться как с гвоздями"(с)
инструмент всё-таки должен соответствовать задаче
копать современной машиной траншеи, конечно, быстрее, но если она копает 5% времени, а 95% простаивает, то вряд ли это эффективный инструмент

[macklakov]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

Почему?

[macklakov]

Цитата:

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

Почему?

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

[Logger]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

[Diman]

Цитата:

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

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

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

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

[ax_mct]

Цитата:

Вот стандарт наименования для C#

Нет стандартов в C#, есть рекомендации. И если наименование свойств как интерфейса важны то с локальными переменными все работают как бог на душу положит.
Программисты из других систем в X++ пишут не
InventTable inventTable;
а
InventTable tblInvent;
InventTable table;
InventTable _invent;
и так далее. То есть они просто не следуют уставу монастыря в которой пришли.
Или еще того хуже следуют примерам из MSDN
http://msdn.microsoft.com/en-us/library/jj677293.aspx
Loan lTbl;
Person pTbl;

delete_from lTbl;
delete_from pTbl;

У меня лично иногда это вызывает некоторое раздражение при том что с C# у меня уже лет 11 как все хорошо.
А подобный кодинг я вижу все чаще и чаще когда опытные программисты но из других систем начинают работать с AX.
Иногда даже почти родное m_* для членов класса встретишь.

И дело конечно же не в C#, а в самих программистах. Лично я на каждом языке (С, C++, VB, Java, C#, X++) всегда программировал так как принято в данном языке.

Но я вижу что подобных поводов для раздражения относительно кода будет все больше и больше из-за "доступности" AX для большего числа программистов.
Так как для меня определенно что все эти изменения не для удобства специалистов по AX а для маркетинговой привлекательности и декларируемого доступа более "дешевых" программистов с опытом не в MorthX а в Visual Studio.

Как понимаю спрос на "архитекторов" резко возрастет так как все будут думать что в Visual Studio и на C# могут программировать многие деревни в Индии и надо только найти создателя технических спецификаций и будет всем экономия денег (Смайлик я поставил, смайлик!)

[belugin]

Цитата:

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

Нет стандартов в C#, есть рекомендации.

Как, впрочем и в X++.

Цитата:

InventTable tblInvent;

Тяжелое наследие венгерской нотации. Пришло из C

Цитата:

InventTable table;

В коротких методах - более менее, если в нем нет ничего кроме "invent" но лучше inventTable.

Цитата:

InventTable _invent;

На это даже есть автоматическая проверка, насколько я помню.

Цитата:

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

Как вы думаете, почему эти имена прошли code review?
Если бы code review делался автоматически прямо по мере набора кода больше или меньше шансов было получить такие имена?

[ax_mct]

Цитата:

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

...
На это даже есть автоматическая проверка, насколько я помню.
...
Как вы думаете, почему эти имена прошли code review?
Если бы code review делался автоматически прямо по мере набора кода больше или меньше шансов было получить такие имена?

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

Code review эти имена не проходят. Его практически просто нигде нет. Некому и незачем. Лично я устал на каждом новом проекте об этом говорить. Бесполезно.

И да такая автоматическая проверка только и спасет. Но это надо чтобы хоть один такой перфекционист оказался в начале проекта. Дело ведь не только в опытности но и в менталитете.

[belugin]

Цитата:

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

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

Можно анализировать только новые ошибки.

Цитата:

И да такая автоматическая проверка только и спасет. Но это надо чтобы хоть один такой перфекционист оказался в начале проекта.

Если бы у вас был инструмент типа Resharper, могли бы переименовать не нравящиеся вам переменные прям по ходу дела.

[lvan]

подобный потс говорит многое о внедренцах во Владимире =)

[ax_mct]

Прогресс... Совершённый язык...

Я в упор не вижу недостатков X++.
Так же как и не вижу недостатков в Visual Basic, Java, C, C++, C# на которых я работал коммерчески.

Вот Assembler меня доставал, копать землю иголкой мне не понравилось.

Я очень против "прогресса" когда шило меняется на мыло, или на молоток ставят резиновую накладку и говорят о революции. В результате этого бессмысленного прогресса вызванного маркетингом очень мало опытных и нормальных программистов. Нормальные люди устают от этих скачек и уходят наверх или в сторону от программирования в АХ. Как результат остаются или останутся только сумасшедшие или новички.

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

[ax_mct]

C# 6
http://damieng.com/blog/2013/12/09/p...es-illustrated

Чуть короче объявления. То есть например вместо трех строк одна.

Программирование, в том числе и на X++, это не синтаксис языка и лаконичность его конструкций, это прежде всего грамотное использование архитектуры конкретной системы и концепций ООП насколько это уместно для данной системы. То есть я могу понять разговоры про интерфейсы и паттерны, AX Best Practices, но меня просто парализуют разговоры о сокращении строчек кода.

Неужели мы, программисты AX (X++) в настолько разных реальностях?

P.S.

Цитата:

для быстрочитаемого и при этом компактного надежного кода

Сомнительно про надежность и читаемость когда код "компактен" и "красив".
P.P.S
Красивость и надежность кода никак не связана c синтаксисом языка. Как письмо на французском не делает его изысканным по причине использования данного языка.

Вот зачем уходить от X++?

Ладно там надежность/производительность в силу интерпретатора или компилятора, среды выполнения. Но тогда надо говорить не о выражениях языка а о других компонентах. А тут как я понимаю речь о листингах кода и как строчки кода могут выглядеть. Я вас просто не понимаю

[perestoronin]

Цитата:

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

Сомнительно про надежность и читаемость когда хочется компактно и красиво.

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