Ошибки, баги, вопросы - страница 2637

[Nikolai Semko]

Andrei Trukhanovich:

может по сравнению с функциональным?

Смотрим википедию:

• Функциональное программирование
• Процедурное программирование

И выясняем, что оказывается это не одно и тоже. 

Так что все же процедурное...

[Petros Shatakhtsyan]

Nikolai Semko:

Возможно удивлю Вас, но современные молодые программисты считают ООП более легким программированием по сравнению с процедурным. 

Вы мыслите категориями 25-летней давности. Современная молодежь ООП впитывает уже с молоком матери. Учите ООП, если хотите быть в тренде, а иначе удел один - ворчание.

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

То что ранее проходили в ВУЗ-ах, такие темы как динамическое программирование, теория графов, ООП, классы и т.д.  нынешние школьники 9-10 классов(не все конечно) такие задачи решают за считанные минуты.

И это закономерно. Закон природы :)

[Nikolai Semko]

Roman:

Да я то понимаю ООП, не в том объеме конечно как хотелось бы.
Это не ворчание, а конструктивное предложение.
Чтобы разработчику не писать одну функцию, по выделению двух malloc, заставляют пользователей учить ООП.   
Это конечно ещё тот прогресс, развития и популяризации языка. Оно и видно как тут любят и понимают ООП.
Понимаешь Николай, всё что в обёртке, это лишний код на выполнение, думаю не нужно объяснять.
Про современные оптимизирующие компиляторы, тоже не нужно рассказывать, мы не знаем какие инструкции он применит.
Возможно и я вас удивлю, что даже американские программисты предпочитают писать в процедурном стиле, не потому что ООП плох, а потому что проще и быстрее получается код.
И если в проекте не стоит объектных задач, зачем использовать обёртки, которые нужно ещё как то понять, для молодежи ))
По этому не соглашусь с вами, что молодежь охотно впитывает ООП. 

Я мыслю языком Си, на котором и построена логика языка mql.
Язык Си рождён в 1972 году, так что получается что 48-летней давности ))  
Но как ни крути, Си один из быстрых языков. А знаете почему? Потому что в нём нет обёрток в виде классов.

Ну это вовсе не так. Просто до сих пор много используется языков без ООП. Си например. В Канаде, например, большинство правительственных учереждений сидят на Коболе и никак слезть с него не могут. 

https://www.tiobe.com/tiobe-index/

Роман, я, честно говоря, не понимаю почему Вы подняли волну по поводу изменения размерности матриц - какие могут быть сложности с этим.
Не нужны ни указатели, ни ООП для этого. 
Все равно для компьютера массив любой размерности - это одномерный массив. 
Вот и работайте с одномерным динамическим массивом. А матрицы формируйте виртуально и делайте ресайз как угодно через фукции. 
Например что-то типа:

double GetValFromMx(double &A, int x, int y, int SizeX, int SizeY) {
if (x<SizeX && y<SizeY) return A[y*SizeX+x];
else return EMPTY_VALUE; }

Сам на практике в коде использую только одномерные массивы, хотя и имею дело с многомерными на основе этих одномерных.

[Igor Makanu]

Roman:

По этому есть очевидная хотелочка, сделайте пожалуйста функции на подобие ArrayResize только для матриц ArrayResizeMx(A, n, m)

все сделано, не хотите готовые решения с помощью ООП (от Вас не требуется знание ООП, используйте готовое!)

используйте ALGLIB , там есть метод изменения размера матрицы Resize().... но все равно все выполнено с помощью ООП )))

ЗЫ: поиском по форуму, было много раз на эту тему общение, там и примеры были, можно структуру с полем массив, обернуть в массив таких структур - будет без ООП, но по моему громоздко все это выглядит

Roman:

Я мыслю языком Си, на котором и построена логика языка mql.

Язык Си рождён в 1972 году, так что получается что 48-летней давности ))  
Но как ни крути, Си один из быстрых языков. А знаете почему? Потому что в нём нет обёрток в виде классов.

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

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

[Roman]

Nikolai Semko:

Роман, я, честно говоря, не понимаю почему Вы подняли волну по поводу изменения размерности матриц - какие могут быть сложности с этим.
Не нужны ни указатели, ни ООП для этого.
Все равно для компьютера массив любой размерности - это одномерный массив.
Вот и работайте с одномерным динамическим массивом. А матрицы формируйте виртуально и делайте ресайз как угодно через функции. 

Да это понятно, что для компьютера любая размерность это одномерный массив.
Всё дело в удобстве использования языка, если в коде мы видим размерность [][], то мы визуально понимает что это матрица, а не одномерный массив.
Читаемость кода в разы повышается, чем гадать что же там содержит в себе []
Не думал что на просьбу добавить одну функцию по выделению памяти для матриц, встречу такое не понимание.
Вы же все пользуетесь ArrayResize, удобно ведь, и не паритесь с этим. Какая проблема для разработчика написать функцию выделения памяти для многомерного массива?
Правильно не каких проблем и препятствий нет, а для пользователей это удобство организации кода. Вот решил я портировать огромную хорошую Си библиотеку численных методов на mql,
а нормальных mql инструментов для этого нет. Снова какие то костыли, что пропадает всё желание городить не эффективный код.

[Aleksey Mavrin]

Roman:

Да я то понимаю ООП, не в том объеме конечно как хотелось бы.
Это не ворчание, а конструктивное предложение.
Чтобы разработчику не писать одну функцию, по выделению двух malloc, заставляют пользователей учить ООП.   
Это конечно ещё тот прогресс, развития и популяризации языка. Оно и видно как тут любят и понимают ООП.
Понимаешь Николай, всё что в обёртке, это лишний код на выполнение, думаю не нужно объяснять.
Про современные оптимизирующие компиляторы, тоже не нужно рассказывать, мы не знаем какие инструкции он применит.
Возможно и я вас удивлю, что даже американские программисты предпочитают писать в процедурном стиле, не потому что ООП плох, а потому что проще и быстрее получается код.
И если в проекте не стоит объектных задач, зачем использовать обёртки, которые нужно ещё как то понять, для молодежи ))
По этому не соглашусь с вами, что молодежь охотно впитывает ООП. 

Я мыслю языком Си, на котором и построена логика языка mql.
Язык Си рождён в 1972 году, так что получается что 48-летней давности ))  
Но как ни крути, Си один из быстрых языков. А знаете почему? Потому что в нём нет обёрток в виде классов.

MQL построена на С++.

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

Вы же сами говорили что надо проще чтобы было тем кто непрофессионал.

Это ситуация типа "Я хорошо научился крутить педали на велосипеде, это так просто и понятно. Давайте в БМВ введём педали, будет проще." :)

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

[Roman]

Igor Makanu:

все сделано, не хотите готовые решения с помощью ООП (от Вас не требуется знание ООП, используйте готовое!)

используйте ALGLIB , там есть метод изменения размера матрицы Resize().... но все равно все выполнено с помощью ООП )))

ЗЫ: поиском по форуму, было много раз на эту тему общение, там и примеры были, можно структуру с полем массив, обернуть в массив таких структур - будет без ООП, но по моему громоздко все это выглядит

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

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

Пробовал ALGLIB возникает проблема с печатью из объекта, функция ArrayPrint не выводит на печать объекты.
А из [][] выводит красивенькую матрицу, даже с заголовками, опять же удобство восприятие информации, когда необходимо визуально отслеживать результат расчёта.
Да, темки поглядел на форуме, но не впечатлило. Вот именно что это всё выглядит громоздко и не эффективно. Си очень элегантный язык, а mql его коверкает.
Да, в Си память для динамических матриц через указатели выделяется, но в mql нет указателей на переменную, снова поход в объекты, нафига спрашивается.
Когда всего то пользователям нужна одна функция ArrayResizeMx(A, n, m, k) а она уже будет в нативном исполнении, понимаете разницу.
Да смысла нет продолжать, если услышали и сделают, тогда большое спасибо. Но функция реально полезная и необходима.

[Koldun Zloy]

Roman:

Рассуждения вслух, но скорее это обращение к разработчику.
По этому Zloy не принимайте на свой счёт.

Получается работа с динамическими матрицами возможна только через объекты или структуры. В общем очередной костыль получается.
Указателей на переменную в mql нет, остаётся использовать объектный подход, там указатели есть.
Получается чтобы использовать динамические матрицы, пользователю необходимо знать ООП и работу с указателями, да и ещё в исполнении MQL.
Многие такими знаниями владеют? Сами знаете ответ. Мне то разобраться с объектным подходом не составит труда, но для тех кто не владеет ООП
создаётся искусственный порог использования языка, в частности по работе с динамическим матрицами.
Как мне кажется, разработчик наоборот должен быть заинтересован в упрощении использования языка, а не его усложнение.
То есть разрабатывать такие функции, которые необходимы пользователю для удобной работы с языком.
А тем более с матрицами, чуть ли не основой численных методов.

По этому есть очевидная хотелочка, сделайте пожалуйста функции на подобие ArrayResize только для матриц ArrayResizeMx(A, n, m),
ну и для многомерных возможно. То есть дайте возможность работать с матрицами не как с объектами, а как с привычными массивами в стиле С.
Тем более для визуального отображения матриц, функция ArrayPrint(A, 0) печатает матрицу из массивов, а не из объекта.

Разработчики высказывались об этом вполне конкретно. Здесь

[Roman]

Koldun Zloy:

Разработчики высказывались об этом вполне конкретно. Здесь

Далеко ходить не надо, следующий пост, с конкретными вопросами от Привала,
Знаю его давно примерно с того же времени, грамотный военный разработчик, и что, почему он от сюда ушёл, ответ очевиден.
Прошло десять лет, что то изменилось?
Как была кодобаза заполнена простыми алгоритмами, так на этом уровне и осталась. Где профессиональные решения?
За то к питону интеграцию пилим, чем дать инструменты для написания этих профессиональных решений, и развития своей кодобазы.
Вот где ошибка, нет инструментов, нет соответствующего уровня программистов.
Ладно, пойду посплю, не спал ещё. Удачи всем.

[TheXpert]

Nikolai Semko:

Так что все же процедурное...

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

Думаю вы таки попутали и имелось в виду функциональное. Впрочем, неважно.