Почему в ВУЗах не преподают о разработке собственных приложений под КОМПАС???

[Ведун]

но не программировать сапр

Понятно, что САПР один инженер не напишет, но вот практически  любую библиотеку, думаю, сможет!

[bergovin]

Библиотеки надо не писа`ть или пи`сать, а разрабатывать. Разрабатывать должен инженер с опытом как инженер из своей области что он разрабатывает
(с программистом "на борту").

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

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

Вот именно, только ОСНОВЫ программирования, достойных проектов он (инженер) всёравно не осилит, способ мыслить катигориями программиста годами вырабатывается!!!

А если вы хотите что то РАЗРАБОТАТЬ то не надо пытаться писать библиотеки - разрабатывайте параметрические модели, пишите математические зависимости - КОМПАС многое позволяет и через этот инстркмент; а если Вы уже  и это перерастёте, пользуйтесь менеджером библиотек, а уж только затем замахивайтесь на программирование!!!

[bergovin]

Кно нибуть смотрел как реализована библиотека СТАНДАРТНЫЕ ИЗДЕЛИЯ - отвечаю: там всё раелизовано через параметрические модели (это должен делать инженер). А вот интерфейс ввода данных, и т.д - это уже задача программиста, (и программисту даже и вникать не надо в задачи инженера).

Кстати очень порадовало, что там встречается реализация через VBScript - мой любимый VB и здесь (на зависть любителям Delphi)

[Vitek]

На борту должен быть инжененр, а не как ни наоборот (программист)
Главное лицо -программист, а в виде консультанта - инженер.
Программисту легче вникнуть в вопросы инженера (в машиностроение, архитектуру...), чем инженеру в вопросы программиста.

Есть такое понятие как ТЗ - техническое задание.
Главное лицо то что пишет ТЗ, не думаю что программист сможет написать ТЗ.

[bergovin]

Есть такое понятие как ТЗ - техническое задание.
Главное лицо то что пишет ТЗ, не думаю что программист сможет написать ТЗ.

И кто вам сказал что тот кто пишет ТЗ - это главное лицо, это всего лишь заказчик    (разсмешили). И не надо переносить свои стереотипы на всё (если у вас это так, это не значит что так должно быть).  Инженер может конечно чемуто научится и что то навоять, но там будет куча глюков, библиотека будет вылетать при не правельно введённом значении ... (я уже писал, что чтоб писать программы- нужно мыслить по-особенному!)
Или по вашему 1С, там главный человек - бухгалтер, в AutoCad - инженер, PhotoShop - дизайнер...
А программист, это так бегает только тупо какие то там краказяблы на не понятном языке пишет ???
С вашей логикой, чтоб сделать какой то прибамбас в 1С - это надо бухгалтера программированию учить, ато ж это он ТЗ должен писать, он же главный !!! 

[PVS]

Хочу добавить свои пять копеек в спор.
Тема, на мой взгляд, вечная. Уже несколько лет руковожу подразделением разработки, где работают и программисты, и аналитики, и др. специалисты, необходимые для выпуска качественного продукта.
Так вот в работе нельзя сказать, кто важнее. На работу я предпочитаю брать просто СПЕЦИАЛИСТОВ В СВОЕЙ ОБЛАСТИ. Ты просто озвучиваешь задачу, а каждый из специалистов вносит свой вклад в общее дело.

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

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

Последние два абзаца я могу спокойно поменять местами - кто здесь важнее невозможно сказать! Эти специалисты должны просто уметь общаться между собой. А вот это как раз непросто

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

[Ведун]

to PVS: +5 !!! 

    Знаете, все о чем здесь пишут последние сообщения  , это действительно не мало важно, но кажется в этих спорах мы отклонились от главной темы: Почему в ВУЗах не преподают о разработке собственных приложений под КОМПАС???

    Не то важно, кто главнее или кто должен разрабатывать (или писать) библиотеки! А то где найти человека, который сможет этому научить и вообще нужно ли этому учить? Или пусть этим занимаются те кто может...

[v_over]

*Почему в ВУЗах не преподают о разработке собственных приложений под КОМПАС???*
1. Для студентов инженеров намного важнее сопромат выучить с другими не менее важными предметами.
2. Для студентов программистов не составит труда разобраться в SDK компаса.

Как мне кажется всё зависит от сложности и задачи конечного продукта - если конечный продукт сама библиотека, то безусловно нужен программист, который профессионально разработает и будет поддерживать её. А если это промежуточное звено, которое призвано укорить или облегчить работу человеку или коллективу, то можно и на коленке своять. Благо есть много языков с низким порогом входа.

[Ведун]

*Почему в ВУЗах не преподают о разработке собственных приложений под КОМПАС???*
1. Для студентов инженеров намного важнее сопромат выучить с другими не менее важными предметами.

От части я согласен, но вот скажите: может есть смысл переходить к инженеру "нового вида", вооруженному не только инженерными знаниями?

2. Для студентов программистов не составит труда разобраться в SDK компаса.

В SDK - да, а в технологии производства тех или иных "деталей"?

[v_over]

От части я согласен, но вот скажите: может есть смысл переходить к инженеру "нового вида", вооруженному не только инженерными знаниями?

Дай бог, чтобы инженер был вооружен инженерными знаниями  А если он ещё и программировать будет уметь, то его с руками оторвут, и будут платить на 2350руб больше 

В SDK - да, а в технологии производства тех или иных "деталей"?

Попыхтят немного над предметной областью. Могут воспользоваться услугами специалиста. Я думаю разберутся.

[Ведун]

1. Вряд ли имеет смысл "как бы пытаться, что-нибудь программить". Это то же самое, что "я как бы пытаюсь работать".

Согласен, напишу так: я программирую под компас. 

Кроме того, что вам мешает постичь знания, которыми обладает инженер?

Ничего, поэтому учусь именно на инженера! А не на программиста.

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

Согласен!

Способностью разработки собственных приложений под КОМПАС?!

Думаю, да хотябы простейшие, для собственного использования! Не бегать же за каждым к программистам?! 

[Ведун]

Опять же, далеко не факт, что и в самом Компасе этот момент не изменится кардинально.

Действительно.

По-моему, софт совершенствуется куда быстрее, нежели подготавливается специалист.

Да, потом специалисту придется "совершенствоваться" под софт))): научили в одном, а работать нужно в другом 

[Senior lecturer]

научили в одном, а работать нужно в другом 

И ничего в этом страшного нет - неделя делов на изучение расположения кнопок и специфики и всё. Ну а если уж совсем другой софт - ещё день полистать руководство пользователя.
Ведь если человек научился ездить на ВАЗ-2101, то для того, чтобы ехать на Мерседесе времени вообще не нужно, ну а чтобы знать остальные функции - руководство пользователя.

[Ведун]

А я и не говорил, что это проблема. для меня 

Скорее это (!) уже проблема, снова-таки, преподавания в ВУЗе.

[pavel]

2. Для студентов программистов не составит труда разобраться в SDK компаса.

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

[bergovin]

Ничего, поэтому учусь именно на инженера! А не на программиста.

Думаю, да хотябы простейшие, для собственного использования! Не бегать же за каждым к программистам?! 

Если для вас программирование как хобби, то я только рад за вас.
А если вы видите смысл с 0 учить студента-конструктора программированию, то я в корне с вами не согласен! Для того чтобы как вы говорите сделать что то простейшее - достаточно освоить параметрическое моделирование (при этом нужна только математика при описании зависимостей) и менеджер шаблонов, повторю для тех кто не внимателен МЕНЕДЖЕР ШАБЛОНОВ - всё !!! При помощи менеджера шаблонов, безовсякого программирования можно сделать 99% простейших вещей, для собственного использования!
Или если вам нужно что то сложное (1%) - вы как инженер сделайте модель, объявите там требуемые внешние переменные, проанализируйте как инженер  весь тех. процесс и отдайте это творение программисту сказав ему что там нужно доработать (ну скажем сделать красивый интерфейс ввода данных, или повесить на это базу данных которую вы ему подготовите, или прорезать на вашей модели канавку с невообразимой траекторией...)
И не нужно тратить драгоценное ВУЗовское время на то что всё равно понадобится 1 из 100000, да и то половину программы он не поймёт, и все будут плеваться, используя программы, написанные данным творцом

[PVS]

Соглашусь с предыдущим высказыванием.

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

Немного уметь программировать для себя - это как любить поковыряться в свое удовольствие с машиной или приготовить из еды. Как хобби - это чудно, но и изучить такой уровень можно по книжке. Все равно всю жизнь чему-то учиться. А вот заниматься конструктору программированием под CAD-системы на серьезном уровне - это уже не конструкторская работа. Ведь вспомните, сами CAD-системы в вузах изучаются как ИНСТРУМЕНТЫ для работы конструктора. А мы уже требуем, чтобы нас учили и эти инструменты делать. А сами предметы конструирования кто будет изучать?

[PVS]

Почему везде у работников отдела ИТ (или другой подобной структуры, в зависимости от предприятия) при слове CAD глаза лезут из орбит и начинается тремор. Для них конструктора - кость в горле. Если из конструкторов кто-то может что-то написать, то это великое счастье! Спасение утопающих - дело рук самих утопающих.

Попробую высказать свое мнение. Дело в том, что в сферу деятельности IT-служб большинства производственных предприятий входит ответственность за работу сети на предприятии, серверов, за работу всех установленных на компьютерном парке приложений. Одной из основных задач, обычно, является поддержание работы какой-нибудь 1С (или другой системы, обслуживающей бухгалтерию и управление предприятием), правка конфигурации программистами и т.д. в том же духе. В лучшем случае, они готовы создавать конфигурации рабочих мест для различных подразделений (конструкторов, технологов и т.д.) А писать библиотеки под имеющиеся CAD-ы - это вряд ли входит в их служебные обязанности. Да и нужно сказать честно - мало людей среди конструкторов, кто способен эти задачи корректно ставить. (Конструктору зачастую кажется, что у программиста блю-тус в голове! Сам должен догадаться! )

[pavel]

А писать библиотеки под имеющиеся CAD-ы - это вряд ли входит в их служебные обязанности. Да и нужно сказать честно - мало людей среди конструкторов, кто способен эти задачи корректно ставить. (Конструктору зачастую кажется, что у программиста блю-тус в голове! Сам должен догадаться! )

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

[PVS]

И такие люди на рынке труда очень ценятся. Такова наша жизнь.

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