| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны |  Справка по форуму | Файлообменник |

Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Какой язык перспективен для инженера-конструктора с условием

Какой язык перспективен для инженера-конструктора с условием

Результаты опроса: Какой язык перспективен для инженера-конструктора?
С/С++ 57 14.69%
Delphi 17 4.38%
Пайтон 39 10.05%
Фортран 1 0.26%
Basic/VB/VBA/VB.NET 93 23.97%
джава 7 1.80%
другой, какой - см. по тексту 29 7.47%
матерный 145 37.37%
Голосовавшие: 388. Вы ещё не голосовали в этом опросе

Ответ
Поиск в этой теме
Непрочитано 23.03.2007, 21:50
Какой язык перспективен для инженера-конструктора с условием
The_Mercy_Seat
 
Сообщений: n/a

Предполагается что инженер-строитель использует как AutoCAD (или его клоны) так и расчетные программы узкостроительного направления, времени на изучение минимум. Требуется получить наибольший практический эффект от владения данным языком.
Просмотров: 261011
 
Непрочитано 17.03.2017, 14:15
1 | 1 #621
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,000


Неправильно понимаете работу динблоков:
Обычный блок: Определение -> Вставка
Дин.блок: Определение -> Определение анонимного обычного блока с заданными дин.параметрами -> вставка анонимного блока.

Не надо думать, что использование динамических блоков позволяет что-то экономить: это лишь удобство для пользователя, а акад все равно преобразует в обычный блок перед вставкой - только делает его анонимным (со звездочкой), чтобы пользователь не видел в диалоге - сколько "мусора" в чертеже при использовании дин.блоков.
Сергей812 вне форума  
 
Непрочитано 18.03.2017, 00:16
#622
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,840


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

з.ы. Тут пару страниц назад (давно не заглядывал, заработался) был вопрос\обсуждение по поводу императивности-функиональности и ООП - могу со всей ответственность сказать ООП - может быть и таким и таким, с разными подходами и пр. Если упрощенно, то в функциональных объектах нет методов меняющих свойства - есть только порождение новых объектов на основе вызываемых с измененным свойством. За счет функциональной структуры, компилятору "видно" надо-ли порождать действительно новый объект, или можно изменить старый выдав за новый - если исходный объект больше не будет использоваться - не путать со сборкой мусора - сборка мусора это оптимизация во время выполнения, а то во время компиляции. Оптимизация эта легко проверяется при помощи отложенных вычислений и в ряде случаев дает существенный выигрыш по производительности - вычисляемые свойства для всех используемых "копий" объектов (как уже созданных, так и впоследствии), которые не зависят от внесенных изменений вычисляются один раз для всех.
__________________
Когда в руках молоток все вокруг кажется гвоздями.

Последний раз редактировалось Дима_, 18.03.2017 в 00:35.
Дима_ вне форума  
 
Непрочитано 18.03.2017, 04:20
1 | 1 #623
skkkk


 
Регистрация: 20.03.2008
Сообщений: 2,653


Сразу оговорюсь, что готовил ответ задолго (по крайней мере, за несколько часов) до ответа _Димы, но дописать и опубликовать не успел (спасибо Admin'у и функции черновиков).

Цитата:
Сообщение от ShaggyDoc Посмотреть сообщение
А мне вот не приходилось и нет необходимости, хотя написал несколько тысяч функций, в том числе "блоковых". Программист все свойства может установить и нет никакой необходимости, чтобы блок обладал какой-то динамичностью.
Цитата:
Сообщение от Владимир_М Посмотреть сообщение
А если вы уже освоили программирование, то дин. блоки уже становятся для Вас просто ненужными.
Для идеального случая, возможно, это так. Но в реальности... Программная вставка и программное же назначение параметров дин. блокам бывает очень кстати. Во-первых, это удобно и для программиста, учитывая возможности (в моем контексте - лиспа) по программному изменению параметров дин.блоков, удобно вставить и сразу же назначить, например, нужную видимость дин.блоку. Во-вторых, (видимо только на этапе, когда программная система для отдельно взятого случая еще не доработана, и может лишь создавать чертежи, но не может качественно и легко вносить в них изменения) это удобно для пользователя, который не вносит теперь весьма муторно изменения "ручками", а дергая лишь одну-две ручки грамотно созданных дин.блоков, вносит изменения "на раз" (тут бывает очень полезно использование полей). В частности, соглашусь с Сергеем812 по поводу удобства программного изменения дин.блока рамки (в частности - ее формата или варианта формы штампа). Также соглашусь и с Linkor'ом в том, что параметры дин.блоков могут быть функцией других параметров (читай "переменных") программы. Ну и, конечно, согласен с Димой_ в его мысли о том, что дин.блоки нужны программисту как средство для назначения их параметров юзером, обработку которых заранее предусмотрел программист, договорившись с юзером об "оговоренных стандартах". Единственное, с чем я не согласен, так это с тем, чтобы создавать дин.блоки программно. Вот тут уж, даже если и есть такая возможность (на мой субъективный взгляд, совершенно ненужная программисту), она только усложнит ему работу. Ведь такие блоки создаются один раз вручную (и то - с многочисленными тестированиями и глюками), а после используются многократно, хоть и программно - весьма полезны при любом подходе.

Но возвращаясь к теме главного вопроса, надо бы сказать, что выбор языка должен бы базироваться на том, чтобы он умел в том числе программно изменять параметры дин.блоков. Ну и быть "изнутри" Автокада.
Стало быть, это может быть один из списка:
  • VBA (учитывая его "ущербность" и мнения о том, что он "калечит" мозги программистам)
  • LISP (учитывая ограниченность его возможностей и возможное сходство в каком-то плане с VBA)
  • C++ (с его легендарной трудностью постижения и почти неограниченными возможностями и универсальностью в среде WINDOWS)
  • C# (... с его идеальностью во всех упомянутых недостатках... сугубо имхостных))
Возможно, я не вполне понимаю и знаю, что еще можно добавить в этот список.
skkkk вне форума  
 
Непрочитано 18.03.2017, 11:07
#624
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,000


Имхо, достаточная частая ошибка начинающих программистов-самоучек, занимающихся процессами автоматизации основной деятельности - вследствие возникшей эйфории от открывающихся "перспектив" начинать дублировать своим кодом уже существующий функционал программ. Вместо изучения этого функционала с последующим дополнением своим кодом для получения законченного решения нужной задачи.
Сергей812 вне форума  
 
Непрочитано 18.03.2017, 11:56
#625
Boxa

КЖ; C#
 
Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 2,588


Сергей812, я даже знаю про кого это написано.
Boxa вне форума  
 
Непрочитано 18.03.2017, 12:18
#626
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,000


Цитата:
Сообщение от Boxa Посмотреть сообщение
я даже знаю про кого это написано.
никого конкретно не имел в виду, большинство в той или иной мере проходило этот этап по мере накопления опыта) И даже опытные люди не застрахованы от подобных казусов на 100%.
Сергей812 вне форума  
 
Непрочитано 18.03.2017, 13:49
#627
bigden


 
Регистрация: 05.08.2008
Сообщений: 821


бывает проще написать новый велосипед, чем убивать время на изучение безграничных библиотек
bigden вне форума  
 
Непрочитано 18.03.2017, 14:34
#628
Boxa

КЖ; C#
 
Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 2,588


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
Имхо, достаточная частая ошибка начинающих программистов-самоучек, занимающихся процессами автоматизации основной деятельности - вследствие возникшей эйфории от открывающихся "перспектив" начинать дублировать своим кодом уже существующий функционал программ. Вместо изучения этого функционала с последующим дополнением своим кодом для получения законченного решения нужной задачи.
Цитата:
Сообщение от bigden Посмотреть сообщение
бывает проще написать новый велосипед, чем убивать время на изучение безграничных библиотек
Конструктивная беседа...
Boxa вне форума  
 
Непрочитано 18.03.2017, 17:08
#629
Владимир_М


 
Регистрация: 05.11.2015
Сообщений: 585


Offtop:
Цитата:
Сообщение от Boxa Посмотреть сообщение
Сергей812, я даже знаю про кого это написано.
Цитата:
Сообщение от Boxa Посмотреть сообщение
Конструктивная беседа...
Две полных цитаты подряд от одного автора. Сколько же в них-то добавлено конструктива!
Хотя бы в offtop закрывали.


----- добавлено через ~1 ч. -----
Цитата:
Сообщение от Дима_ Посмотреть сообщение
Не соглашусь, что дин. блоки не нужны программисту - это прекрасное средство для ввода графических параметров юзером, причем при соблюдении "оговоренных стандартов" юзер вполне может и сам создавать эти блоки, которые потом будут обрабатываться программно по нужному сценарию (у меня из таких блоков полный производственный цикл "вытягивается", от планирования поставок материалов, до отгрузки готовой продукции, включая ее автоматизированное производство).
А можно как-то на пальцах об этой чудесной технологии. Пока из этих общих слов у меня складывается такая картина: запускается программа, выполняется какая-то в том числе графическая работа, в том числе энное количество дин. блоков. После этого юзер, путем ввода графических параметров в этих болках, и даже создавая сам такие же болки (при соблюдении "оговоренных стандартов"), в любой момент времени и в любом месте уже выполненной программой работы ранее, изменяет "полный производственный цикл" от планирования поставок материалов, до отгрузки готовой продукции, включая ее автоматизированное производство.
Или же речь идет просто о том, что динблок используется как первичный носитель каких-то данных, которые считываются программой по ходу ее выполнения. Но тогда при чем тут динамичность этих блоков, в контексте обсуждения взаимосвязи именно динамических блоков и программирования (особенно в плане создания динблоков программно). Носителем той же самой информации может быть и обычный блок (текст, таблица, да и вообще любой примитив).

Последний раз редактировалось Владимир_М, 18.03.2017 в 19:21.
Владимир_М вне форума  
 
Непрочитано 18.03.2017, 19:39
1 | #630
Дима_

Продуман
 
Регистрация: 22.02.2007
Питер
Сообщений: 2,840


На сервере, в БД, лежат дин. блоки изделий с описанием и формулами преобразования параметров дин. блоков в спецификацию исходных материалов и заданий на ЧПУ для производства деталей из последних. Через GUI'шки данные блоки изделий выбираются из базы и расставляются на чертеже с заданием параметров в соответствии с ТЗ. Далее есть набор команд для планирования производства (разбивки на смены), составления графика подвоза продукции в соответствии с ним, документов выдачи со склада, генерации производственных (монтажных) чертежей (на основе тех-же дин. блоков, специальным образом связанных с исходными блоками), спецификации на каждое производимое изделие, получения управляющих программ для обработки на ЧПУ, печати этикеток на "промежуточную" продукцию и остатков материалов, оптимизации раскроя материала, учета полезных остатков с предыдущих смен и пр. бумаг и "выгрузок" в БД для бухгалтерии. Блоки может создавать и описывать "продвинутый" пользователь, так-же через свой набор GUI'шек. В сложных случаях (когда визуализацию изделия сложно или невозможно описать дин. блоком, добавляются "overrule" модули меняющие отображение отдельных блоков - это к сожалению только программно - была мысль сделать DSL и на этот случай - но он получается сложный для "продвинутого пользователя").
__________________
Когда в руках молоток все вокруг кажется гвоздями.
Дима_ вне форума  
 
Непрочитано 18.03.2017, 20:43
1 | #631
Владимир_М


 
Регистрация: 05.11.2015
Сообщений: 585


Дима_, спасибо и большой респект! Вот это достойная задача - автоматизировать такой производственный цикл!
По сути последнего разговора хотел было продолжить возражать, что типа использование именно динамических блоков не принципиально, т. е. так оно и остается на мой взгляд блоки - блоками, программирование - программированием.
Но... сам вдруг вспомнил свой недавний опыт. И как-то уже посмотрел на тот же вопрос с другой стороны.
Дело, правда, касалось не Акада, а Ревита. В чем суть той "технологии"? Модель сооружения создается программно из заготовленных ранее семейств. А что такое семейства в Ревит? это практически то же самое, что и динамические блоки в Акаде. (Правда, есть большое преимущество в семействах по сравнению с динблоками, что они уже понимают "IF").
Остается в силе, что и там и там также можно было бы обойтись и без динблоков и без семейств, а изображать все от и до чисто из программного кода. Но это было бы очень и очень долго и нудно. Т. е. именно программист должен через код описать все необходимые детали конструкций, например, из типовых проектов. Но для того и придуманы семейства (читай дин. блоки) что их может создавать и описывать "продвинутый" пользователь , не владеющий ЯП.
Так вот - да. Если объем задачи глобальный, и можно подключить к ее решению других пользователей, уменьшив работу по написанию кода, то идея правильная.
Ну в принципе примерно об этом уже и говорилось. Использование уже существующих наработок (блоков, семейств).
Но все-таки не сочтите за занудство. Так и не могу себе представить, чтобы я те же семейства создавал программно, если всю их геометрию можно создавать в параметрическом редакторе семейств наглядно, графически.
Владимир_М вне форума  
 
Непрочитано 18.03.2017, 20:47
#632
100k

Жалкий инженеришка-проектаст
 
Регистрация: 31.01.2010
Сообщений: 1,986


Цитата:
Сообщение от Владимир_М Посмотреть сообщение
Так и не могу себе представить, чтобы я те же семейства создавал программно, если всю их геометрию можно создавать в параметрическом редакторе семейств наглядно, графически.
А грасхопер может создавать такие семейства програмно. Работает отлично.
100k вне форума  
 
Непрочитано 18.03.2017, 21:09
#633
Владимир_М


 
Регистрация: 05.11.2015
Сообщений: 585


Цитата:
Сообщение от 100k Посмотреть сообщение
А грасхопер может создавать такие семейства програмно. Работает отлично.
Что значит программно? Т. е. я примерно в курсе что такое грасхопер, Динамо. И примерно понимаю, что там можно сделать. Там, конечно же, все очень красиво смотрится, когда гоняешь разные ползунки и вся геометрия в динамике меняется любым замысловатым образом.
Но в чем преимущества путаницы всех этих шлангов, по сравнению с обычным создание параметрического семейства, если эти мультики для моей задачи вообще никак не употребить?
Владимир_М вне форума  
 
Непрочитано 20.03.2017, 09:45
#634
Boxa

КЖ; C#
 
Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 2,588


Цитата:
Сообщение от Сергей812 Посмотреть сообщение
никого конкретно не имел в виду
Я вот про эту тему вспомнил http://forum.dwg.ru/showthread.php?t=104517 =о) и то, что рано или поздно этот этап проходят все, совершенно согласен, впрочем указанная тема это отлично иллюстрирует и как видно от выбранного ЯП это не очень то зависит. =)
Boxa вне форума  
 
Непрочитано 20.03.2017, 10:33
#635
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,000


Цитата:
Сообщение от Boxa Посмотреть сообщение
вот про эту тему вспомнил http://forum.dwg.ru/showthread.php?t=104517 =о)
что тратят время на изобретения новых способов автоматизированной печати из модели вместо листов и наборов параметров листов?
Сергей812 вне форума  
 
Непрочитано 20.03.2017, 10:54
#636
Boxa

КЖ; C#
 
Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 2,588


Да, вместо использования блоков с полями, подшивок, создания листов по шаблонам, автоматических ведомостей листов, пакетной публикации и прочего функционала уже реализованного в автокаде, пишутся велосипеды с печатью из модели.
Могу продолжить этапы роста: ИМХО, после написания своих костылей, приходит пора изучения того, что уже написано другими и покупка/использование уже существующих программ.
Boxa вне форума  
 
Непрочитано 20.03.2017, 11:19
#637
Сергей812


 
Регистрация: 10.08.2013
Сообщений: 11,000


Этапы перехода на листы и подшивки: создать шаблоны на все форматы по ГОСТ 2.301-68 (чтобы потом не оказалось, что надо срочно печатать - а настроенного листа нет), настроить параметры листов под конкретные печатающие устройства + сопутствующие файлы, создать шаблон подшивки, инструкцию в картинках на 2-3 страницах (не любят у нас в стране инструкции читать обычно). Желательно устроить пробную распечатку. И выложить на сервер в защищенную от изменений папку (всегда найдутся шаловливые ручки). И это только полпути - потом еще заставить людей переходить на работу в листах на фоне криков, что это все сложно, им некогда и т.д. Т.е. это работа не на час, и не на два. А если в фирме есть "мамонты", до сих пор чертящие палочками - там саботирование перехода на листы с подшивками может принять и резко выраженную форму.

А при этом надо еще и основную работу делать. Поэтому начальство, даже если какие то действия по переходу совершались, дает отмашку - делайте как умеете. А перейдете потом - когда будет время. И в результате приходиться приделывать автоматизированные костыли к уже существующему бардаку. Это печальная действительность для многих фирм.
Сергей812 вне форума  
 
Непрочитано 20.03.2017, 11:29
#638
Boxa

КЖ; C#
 
Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 2,588


Offtop:
Цитата:
Сообщение от Сергей812 Посмотреть сообщение
А при этом надо еще и основную работу делать. Поэтому начальство, даже если какие то действия по переходу совершались, дает отмашку - делайте как умеете. А перейдете потом - когда будет время. И в результате приходиться приделывать автоматизированные костыли к уже существующему бардаку. Это печальная действительность для многих фирм.
В этом то и трагизм ситуации =о( Вместо траты время на образование и повышение квалификации сотрудников, начальство поощряет кустарную автоматизацию и трату времени на написание велосипедов.
Это как купить конвеер по производству машин, разобрать его на отдельные станки и все равно выпускать машины, придумав свою технологию производства.
ЗЫ.
Мне повезло, в компании, где тружусь, нашелся энергичный человек, который старательно всех перетаскивает на нормальную работу с подшивками и шаблонами.
Boxa вне форума  
 
Непрочитано 20.03.2017, 13:38
#639
veb86

Проектировщик электрических сетей
 
Регистрация: 17.01.2014
Пенза
Сообщений: 176


Offtop:
Цитата:
Сообщение от Сергей812 Посмотреть сообщение
А если в фирме есть "мамонты", до сих пор чертящие палочками - там саботирование перехода на листы с подшивками может принять и резко выраженную форму.
А если таких большинство!!!Я то не до конца понимаю о чем конкретно вы рассуждаете (листы с подшивками), а про свое большинство вообще молчу. У нас, даже переход в пространство листа не возможно сделать. Приходят молодые привыкают к модели и они, уже сами начинают выступать против видовых окон и т.п. Внешние ссылки отвергаются как ересь. Со слоями получше, но иногда приходится ругаться, ну забыли они что в "0" чертили. Чертежи замусорены хламом, копируются из проекта в проект, из года в год, и потом удивляются чего то он 30мБ весит, а на нем всего лишь 10 тыщ линий.

Цитата:
Сообщение от Boxa Посмотреть сообщение
покупка/использование уже существующих программ.
В стране кризис, а Вы о закупках. Оцениваю исключительно по своему городу.

Цитата:
Сообщение от Boxa Посмотреть сообщение
Мне повезло, в компании, где тружусь, нашелся энергичный человек, который старательно всех перетаскивает на нормальную работу с подшивками и шаблонами.
Согласен Вам повезло


----- добавлено через ~8 мин. -----
Цитата:
Сообщение от Boxa Посмотреть сообщение
Я вот про эту тему вспомнил http://forum.dwg.ru/showthread.php?t=104517 =о) и то, что рано или поздно этот этап проходят все, совершенно согласен, впрочем указанная тема это отлично иллюстрирует и как видно от выбранного ЯП это не очень то зависит. =)
Я тоже тратил время на похожую задачу, но для себя ставил ее по другому, необходимо было просто найти на обычном чертеже рамки листов (форматов не так много ) образованные линиями или поллиниями и разбить их по физическим листам 1.dwg, 2.dwg. сейчас экономлю кучу времени. А если бы у нас в конторе не было бы отдела выпуска проектов (как я думаю у ребят которые пишут такие проги), то скорее всего, печатал свои проекты сам и задача была бы такая же как у них
veb86 вне форума  
 
Непрочитано 23.03.2017, 09:06
2 | #640
Boxa

КЖ; C#
 
Регистрация: 03.11.2005
Санкт-Петербург
Сообщений: 2,588


Выбирающим язык может быть интересна эта заметка от микрософт по поводу перспектив развития языков .NET группы: https://habrahabr.ru/company/microsoft/blog/324548/
Boxa вне форума  
Ответ
Вернуться   Форум DWG.RU > Программное обеспечение > Программирование > Какой язык перспективен для инженера-конструктора с условием

Размещение рекламы
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск