Вот именно, критичные. А "критичность" ошибок определяет сам разработчик. И очередь исправления ошибок в Алтиуме далеко не нулевая. Использую Алтиум/DXP 12 лет, ситема неплохая. Но баги, в основном тормоза, убивают все поз. эмоции. После каждого обновления с трепетом проверяю исправление известных мне багов - полностью исправлено или нет - и наличие новых "особенностей".

Так и происходит. Заказчики, имеющие по 100 лицензий составляют ТЗ и оно отрабатывается.
В целом такое ТЗ мы принимаем от всех пользователей, но приоритет отдается крупным пользователям. Остальные пожелания также рано или поздно уходят в работу. Мои контакты у вас есть - пишите, это не останется без внимания.


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


Многие из них мы решили еще год назад, но это потребовало больших изменений, и период тестирования может занять еще какого-то времени!


А куда вы сообщаете об известных вам багах? Наверное если бы они были известны еще кому-то кроме вас, их бы уже и не было)))
Давайте обсуждать эти вопросы более предметно.
Вот вы можете например написать 10 изветсных вам багов, которые не были исправлены за последние 2 года?

Мне хватило одного раза объясниться с людьми Альтиума по очень серьезному багу, на мой взгляд, по выбору компонетов для разных вариантов схемы, пока они приняли этот баг к работе. 2 раза мою заявку о баге снимали, пока по телефону не объяснил по шагам. Прошло больше 1,5 лет, они исправили в версии 14.8 (если не ошибаюсь), получилось неплохо. За исключением появившегося нового бага: после выбора компонентов для вариантов схемы и последующем пермещении компонентов (без изменения схемы, только для упрощения и читабельности) я применяю annotation снова для упорядочивания нумерации. При этом исходная информация по разным компонентам в вариантах перемешивается с неизменяемыми компонентами и приходится чистить это вручную. После моего первого "объяснения" с Алтиумом стараюсь избегать заявок об ошибках. Во всяком случае пока.

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

Да?
А как же это?
Altium Designer: самое большое приложение (about 15 000 000 codelines), сделанное в Delphi

И мне кажется что из-за дельфи тормоза и идут. И тоже думаю, что исправить это невозможно.

Это не так, продукт написан на Delphi! На семинаре говорилось про новые разработки!

Уж что что, а на шарпе явно проще и надежнее можно писать приложения благодаря его гибкости, а вот выбранный язык для Альтия - довольно специфичен ибо он уже старичёк, более того создатель делфи - это и создатель шарпа. И сколько не использовал программ - все что на делфи написаны, порядком тяжелее и медлительнее (скайп, винамп и д.р.) по сравнению с аналогами на С++ \ С# (к примеру винамп \ аимп сравнить можно), но стоит признать - редактор ПП в нем сделан довольно удобно и вполне логично + самый приятный рендер плат в 3D - таки притягивают.

Сообщение отредактировал truppik - May 7 2015, 17:04

Полагаю, что дело не Delphi или других каких-то языках. ведь тормозит не на 50% и даже не на100% от желаемого быстродействия, а многократно дольше. Иногда процессы длятся минутами. И это не от выбора языка программирования. Похоже, что, как всегда, программисты и тестироващики проверяют на простых задачах с ограничениями на количество и объемы проектов и просто с этим не сталкиваются.

Это не так. Если говорить о вычислительном аспекте, то решают все алгоритмы и отсутствие криворукости.
А интерфейс никогда не был причиной медлительности.

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

Плюсуюсь.

По моим представлениям, основной язык для реализации функциональности серьёзного САПРа сегодня должен быть С++. С#, насколько мне известно, это интерпретируемый язык, что означает, что он по эффективности (в плане скорости, в частности) может конкурировать с Java и Python, но никак не с нативным кодом, получаемым из компилируемых языков С/С++ (и, кстати, Paskal/Delphi). Если на Шарпе там только GUI сделан, то это нормально, но если внутренние потроха, то перспектив в плане прироста быстродействия рассматривать не приходится.

Также полностью согласен с TSerg в том, что эффективность алгоритмов рулит, и если алгоритмы горбатые, то никакой ЯП уже ничего не исправит.

P.S.: IMHO: выбор C#, а не, скажем, С++ обусловлен тем, что идут по пути наименьшего сопротивления - высококвалифицированных программистов С++ найти гораздо труднее, чем на C#, т.к. и язык сложнее многократно, и порог вхождения выше. Шарп позволяет проще найти разработчиков, но в итоге он вводит определённый "потолок" для САПРа по размеру/сложности разрабатываемых проектов.

P.P.S.: Выбрав C#, Альтиум прибил себя гвоздями к венде. Недальновидное решение и стратегически проигрышное, учитывая, что венда чем дальше, тем тошнотворнее становится.

Не профессиональный программист я, но C# не должен быть интерпретируемым.
Есть у меня проект управления моей аппаратурой, написанный в MFC, и недавно я к нему прислюнил спектроанализатор на C# + WPF. К моему экзешнику добавилась dll-ка, и эта сладкая парочка спокойно запускается на старинном Acer Aspire One с XP на борту. Никаких дополнительных интерпретирующих приблуд не потребовала (NET Framework 3.5 там уже стоял).

Согласен, потребуется среда исполнения - аля .Net
Скорость, да несколько ниже чем на с\с++, Но ИМХО не настолько критичная разница для прог пользовательского уровня. У нас же не система реального времени на микроконтроллере.


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

Сообщение отредактировал truppik - May 12 2015, 13:08

Да, уж лучше бы P-CAD воскресили. Мечта... P-CAD 2015! Хотя бы слегка...