Прощай, X++

[belugin]

Цитата:

Сообщение от Владимир Максимов

Т.е. может ли после указания критериев быть много кода прежде чем будет создан новый список по этим критериям?

Критерий - это параметр метода создания списка

в C# можно сделать как-то.

var isEven = (Int x) => x % 2 == 0;

...   ...

new []{1, 2,3,4,5}.Where(isEven);

То есть в каком-то смысле может (код самого критерия отдельно).

В каком-то смысле не может (этот параметр обязательный и надо что-то туда передать)

Аналогично

bool isEven(int x)
{
     return x % 2 == 0;
}

...   ...

new []{1, 2,3,4,5}.Where(isEven);

[Владимир Максимов]

Цитата:

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

Языки программирование вообще созданы для удобства. Без них вообще можно обойтись. Тут никакого "только так а не иначе". Теоретически можно даже на brainfuck перейти - он тоже Тьюринг-полный.

Языки программирования созданы для удобства. Да. Но следует уточнить: для удобства решения определенных задач.

Так вот, каким образом, описанная типобезопасность позволит упростить (иначе, зачем связываться) решение тех задач, для которых и предназначен язык X++? Собственно, какую вообще задачу решает подобная типобезопасность?

[belugin]

Цитата:

Сообщение от Владимир Максимов

Так вот, каким образом, описанная типобезопасность позволит упростить (иначе, зачем связываться) решение тех задач, для которых и предназначен язык X++? Собственно, какую вообще задачу решает подобная типобезопасность?

Посмотрите по перекрестным ссылкам количество мест испорльзующих Map, List, container и прочих.

Во всех этих местах компилятор не найдет ошибок если вы будете использовать не тот тип.

[perestoronin]

Цитата:

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

х++ не единственный язык без прочей радости и это не повод ему "умирать".

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

[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]

Цитата:

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

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

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

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

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

[dech]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

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

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

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

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

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

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

и т.д.

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

[ax_mct]

Цитата:

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

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

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

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

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

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

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

[ax_mct]

Цитата:

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

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

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