Python-сообщество

> Изнутри графическая работа выглядит так….

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

> Профи в алгоритмах не может найти пару недель на то чтобы выучить язык? Может и матанализ надо перестать изучать на первом кусрсе, а то сложно больно?

Если бы всё было так просто, то и программисты были бы не нужны.

Rodegast
но технической трудности в этом нет.

Тут есть идеологическая трудность. Графика несет много трудно формализуемой информации. Собственно в этом ее преимущество. Вот взял кто-то и подвинул элемент (икону или соединитель.) Это новая схема? С точки зрения логики работы нет. А при сливке проектов да. Поскольку все вместе стало “красивее”. diff Вам показывает несколько строк вокруг места изменения. Этого достаточно, поскольку в тексте все более или менее локализовано. Именно так нас и учат программировать. А что показывать при сравнении схем? У нас сейчас показывают схему вцелом, мигающей красной рамкой обводят изменившиеся элементы. Иначе нельзя, поскольку нужно общее впечатление от схемы для адекватного ее восприятия, но это очень неудобно, поскольку надо просматривать все. Потом возникают вопросы как это сливать. Еще одна не очень понятная область - поиск нужных элементов. С текстом понятно, есть регулярки и т. п. А для схем что? Проверять изменение топологии? Изменения раскрашивания? Смещения элементов, масштаба всей схемы?

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

Rodegast
то и программисты были бы не нужны.

А вы посмотрите сколько на этом форуме людей с надписью в дипломе “Программист” Людей которые 5.5 лет учились программированию. Я в своей деятельности таких не встречал. Программирование сейчас это как умение водить велосипед, ну может автомобиль. Человек с высшим или среднетехническим образованием уже умеет программировать. Одного семестра хватает на это с головой. Другое дело что написать хорошую программу все равно что спроектировать хороший двигатель. Но проблема тут не в знании языка программирования, а в профессионализме. Чертить ведь тоже все могут, только конструкторы далеко не все.

> Это новая схема? С точки зрения логики работы нет. А при сливке проектов да… diff Вам показывает несколько строк вокруг места изменения.

Вот по этому я и песал что нужен специализированный diff. ИХМО проверять геометрические изменения не обязательно.

> Еще одна не очень понятная область - поиск нужных элементов. С текстом понятно, есть регулярки и т. п. А для схем что?

Для схем тоже самое. У икон есть текстовое описание по нему и нужно производить поиск.

> Человек с высшим или среднетехническим образованием уже умеет программировать. Одного семестра хватает на это с головой.

Кому-то может и достаточно, но таких мало. Вот что ты писал про автоматчиков:

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

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

Отредактировано Rodegast (Янв. 22, 2016 10:02:37)

Rodegast
Можно посмотреть Вашу программу написанную на визуальном языке программирования?

> Можно посмотреть Вашу программу написанную на визуальном языке программирования?

А разве я где-то говорил что у меня есть какая-то программа? Мы тут обсуждаем визуальные ЯП чисто теоретически.

Аааа. ОК. Вопрос снят…

Rodegast вопрос в том что все говорят что в теории все ОК , но по факту решают вопросы которые прямым программированием решаются НАМНОГО быстрее и лучше и приходит понимание того что сделал. С граффическим программированием 70% остается за кадром. Я наблюдаю как уже почти 2 года люди топчутся на месте, вместо того что бы просто сесть за язык и понять “как все устроенно” они упорно чертят графы (графические связи). При этом ,как тут уже заметили , в случае изменения кода одного из блоков нужно перечерчивать всю схему . Это адовая работа. Но я в топике не зря указал Autodesk. Компания уже давно ничего не делает в плане инженерных решений. И в данной теме граффического програмирования они хотят переложить свои обязанности по исправлению косяков и недочетов в ПО на плечи пользователей. И все ассоциируется под таким сосусом “ если вам что то не хвататет то берете граффическое программирование и допиливаете сами” но круг решаемых задач просто ничтожен и оторван от реальности. Нету примеров решения сложных задач. И сообщество таких инженеров и архитекторов крайне не дружелюбны к критике , по факту уже немного напоминают зомби …….. Если не говорить про будущее что вы можете посоветовать в данный момент в качестве инструмента решения инженерных задач ?

> Если не говорить про будущее что вы можете посоветовать в данный момент в качестве инструмента решения инженерных задач ?

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

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

Отредактировано miko2009 (Янв. 22, 2016 13:47:43)

Rodegast
то вы можете посоветовать в данный момент в качестве инструмента решения инженерных задач ?

Вопрос не ко мне, но попробую чтото сказать.

miko2009
теория упругости и пластичности, сопротивление материалов, метод конечных элементов (можно выделить в отдельное направление)

Конкретно я сталкивался с FEM. Тут есть много красивых решений, но что касается использования питона, то мне показался интересным проект http://fenicsproject.org. Это в большей степени научный инструмент, а не инженерный. Кое что делал во http://www.freecadweb.org/ но этот проект еще сырой, до solid works ему еще далеко. О графическом программировании в этих проектах никто даже близко не заикается. На практике большое число инженерных задачек решается в Wolfram Mathematica, имеет смысл рассмотреть если вы готовы покупать лицензию.

Rodegast
Они боятся программирования, не понимают его и пытаются всячески его избежать

Я лично считаю что они просто ленятся а не боятся. Как это происходит. Ставится задача “разработка системы Х”. Нарисовать ее в самом деле проще. Если у человека опыта мало, ему кажется что и все вцелом быстрее в такой среде сделать. А когда наступает пора решать весь комплекс проблем, они уже боятся выкинуть то что наделали. Потому что окажутся в середине проекта практически ни с чем. В результате они мучаются до конца и сдают недоделанную систему.

Отредактировано doza_and (Янв. 22, 2016 15:50:49)