Пользователь
0,0
рейтинг
13 декабря 2013 в 17:45

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

Компания Embarcadero всегда с радостью упоминает продукт Altium Designer, когда речь заходит об успешных коммерческих приложениях, созданных в Delphi. Не может не поражать масштаб проекта – он насчитывает около 15 000 000 (пятнадцати миллионов) строк исходного кода. Altium Designer представляет собой CAD-систему для проектирования печатных плат электронных систем, включая 3D моделирование. Сегодня мы поговорим о технической составляющей системы именно с позиции инженерии ПО.



Целью данной статьи ни в кой мере не является продвижение или рекламирование Altium Designer, который и так хорошо известен среди профессионалов данной области. Мы проведем своего рода экскурсию вглубь проекта и познакомимся с особенностями его реализации в контексте сложности задачи и масштаба реализации. Это будет особенно полезно для начинающих разработчиков, а также специалистов, интересующихся большими во всех смыслах системами (а не только большими данными).

Давайте сразу оценим масштаб системы в контексте её функционала. Опишите, пожалуйста, основные функциональные модули или подсистемы. Это очень важно, т.к. термин CAD (computer aided design) имеет достаточно широкое значение – так можно назвать и простое приложение-«рисовалку», и интеллектуальную САПР. Что умеет делать Altium Designer
?

Инженер получает или же формулирует спецификацию устройства, начиная от условий, в которых оно должно работать, заканчивая элементной базой, которую планируется использовать. Сейчас очень часто разработка ведется от микропроцессора — выбирается чип, решающий необходимую задачу, и под него проектируется обвязка. После этого создается библиотека используемых компонентов, набрасывается логическая/принципиальная схема в редакторе схем. Здесь же задаются уточнения и ограничения, которые могу влиять на то, как плата будет «разводиться» физически. Могут выполняться различные виды анализа — целостности сигнала, моделирования схемы. После этого начинает создаваться печатная плата, т.е. задается кол-во используемых слоев согласно спецификации, размещаются компоненты, определяются дорожки, которые передают сигнал, подводят питание и т.п. Т.е. формируется уже физическое представление платы. После чего генерируется документация, формируются файлы, отправляемые на производство/печать плат, строится список используемых компонентов для сборочных конвейеров.

Одно из преимуществ АД то, что все вышеперечисленные операции выполняются в одном продукте в очень тесной интеграции друг с другом.
Основные функциональные блоки системы:
  • платформа;
  • редактор схем;
  • управление библиотеками компонент;
  • редактор печатных плат;
  • ядро 3D режима;
  • анализ целостности сигнала;
  • модуль генерации выходных файлов;
  • модули импорта/экспорта — начиная от 3D моделей, заканчивая данными для симуляции во внешних системах

Можно ли сказать, что каждая из функциональных подсистем представляет собой достаточно изолированные модули. Так ли это? Если так, то как реализованы модули? Это dll-плагины к некому ядру? Это равнозначные приложения? Какой механизм обмена данными между ними?

Как и большинство крупных систем, Altium использует модульную архитектуру. Есть платформа, обеспечивающая базовую инфраструктуру (документы, настройки, подсистема сообщений и т.п.) и модули, реализующие функционал. В последних версиях каждый модуль — изолированная dll, предоставляющая набор интерфейсов. Интерфейсы не COM-совместимы, но интероперабельны. На этой платформе построено несколько продуктов, но самый крупный — AltiumDesigner.

Чуть подробнее о том, как сочетаются модули. Есть какое-то внутреннее API? Весьма вероятно, что в Altium каждая подсистема разрабатывается отдельной командой. Есть у вас обобщенное представление? Или некие протоколы обмена между модулями? Есть ли сетевое взаимодействие?

Да, конечно есть API используемое внутри. Основа — интерфейсы с некоторыми ограничениями по используемым типам. Довольно широко используется система команд/сообщений.

Учитывая то, что помимо Altium Designer (AD) в стеке решений компании есть достаточно широкий набор вспомогательных продуктов, начиная от сервера лицензий и заканчивая инфраструктурой обеспечивающей экосистему Altium.Live, сетевого взаимодействия много. Активно используются веб-сервисы. Для внутренних продуктов – это чаще всего SOAP протокол, с внешними сервисами? в последнее время — REST.

Как организовано хранение проектов?

Здесь все достаточно просто, есть несколько SVN-репозиториев, разделенных по прикладным областям: платформа, ядро продукта, расширения, веб-проекты. Управление задачами в Assembla, активно используем Google docs.

Есть несколько внутренних вспомогательных сервисов — сбор «креш-репортов», «билд-система», система запуска тестов на «тест-фарме».

Когда мы говорим о полномасштабной среде, возникают простые, но интересные вопросы. Сколько пунктов меню в главном окне системы? Сколько окон в приложении? Понятно дело, никто специально не считает, но просто интересно. Это как «на постройку телебашни пошло столько-то миллионов заклёпок или болтов». Как у вас с такими формальными параметрами?

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

Поиск dfm-файлов по двум основным репозиториям дает числа ~500 для платформы и ~1800 для основного продукта. Кол-во пунктов меню как-то уж совсем сложно вычислить, тем более оно динамическое, и зависит от открытого документа, режима работы и т.п. Но их действительно много :)
В базовой конфигурации порядка 150-200 dll-модулей, в базовых репозиториях около 500 dpr-проектов, полный «билд» продукта занимает 40 минут (правда это действительно полный, результат такого «билда» становится доступен пользователям в системе обновлений).

Можно представить какой-нибдуь скрин-шот окна системы с загруженной схемой. Это – типовое окно объектной САПР? Главное рабочее графическое поле, панель инструментов, редактор свойств объектов? Или есть некие особенности?

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

image

На втором скриншоте (ниже) — 3D представление гибко-жесткой платы. Сам дизайн обычно ведется в 2D режиме.

image

Использовали ли вы стандартные компоненты Delphi или для повышения уровня эргономики интерфейса использовали дополнительные библиотеки?

Из визуальных – довольно широко используются компоненты DevExpress и DreamControls, есть достаточно много самописных элементов управления.
модель рисования – использовали «канву» или какую-нибудь GPU-based библиотеку (OpenGL, DirectX)?
Сейчас для схем — GDI/GDI+, для PCB — DirectX.

Насколько открыта система? Можно ли создавать свои пользовательские плагины?

Она была достаточно открыта ранее, сейчас существует достаточно много расширений, чаще всего интеграционного характера. А в последних версиях на это сделан акцент — у нас появилось SDK для Delphi, C++ и С#. В ближайшие дни выходит версия DeveloperEdition, которая сделает разработку расширений еще проще.

Есть ли механизм пользовательской автоматизации? Какие-нибудь скрипты, макросы, внутренний язык программирования?

Да, есть, достаточно популярный у пользователей, Delphi/Basic/Java-script. Используется как для написания расширений, так и для повседневной работы, в частности для задания сложных фильтров по объектам.

image

Поговорим об истории развития. С чего начинался проект?

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

С какой версии Delphi и по какую ведется разработка Altium Designere-а? Понятно, что такой масштабный проект сложно мигрировать, но были ли успешные попытки?

Если я не ошибаюсь, первые версии продукта были созданы на TurboPascal, далее череда версий Delphi начиная с 3-ей. На текущий момент это Delphi 2010. Миграции обычно происходили тогда, когда это было оправдано с прагматичной точки зрения — появлялись необходимые технологии, исправлялись критические ошибки. Любое, даже незначительная модификация системообразующих классов заставляет сильно призадуматься и очень взвешенно подойти к решению, вплоть до весьма точно расчёт трудозатрат. Примем во внимание, что есть ещё и сторонние библиотеки. Пока мы не спешим с переходом на последнюю версию.

Но помимо Delphi использует довольно много языков и сред, к примеру часть модулей реализованы на C++ и С#, для части веб-сервисов и приложений используется Morfik.

Как организована архитектура основных модулей? Это классические варианты типа «форма-элемент управления-действие-процедура отклика» или есть более изощренные техники типа разделение модели и интерфейса?

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

Интерфейс среды в основном статический или есть динамический механизм генерации интерфейса пользователя в зависимости от внешней конфигурации?

Часть интерфейса зависит от того какой документ открыт (к примеру для PCB и BOM набор команд и меню отличает кардинально), от того какой функционал доступен с активной лицензией. Т.е. какой-то базовый каркас, обеспечиваемый платформой, неизменен, остальное определяется режимом и логикой работы модуля.

Какие сложные, научные с элементами искусственного интеллекта или просто интересные алгоритмы применяются в системе?
Не совсем уверен в применении AI, но есть несколько областей в которых алгоритмическая база довольно сложная, особенно в области PCB и симуляции. К примеру авторазводка плат — область очень емкая с точки зрения алгоритмики. При ее реализации приходится решать не только задачу размещения дорожек в пространстве (сейчас большинство плат многослойные, и трек может менять слои), но и учитывать громадное кол-во ограничений, задаваемых пользователем — минимальное расстояние между дорожками, импеданс дорожки, “шумность” получаемой топологии на высоких частотах и т.п… Полноценно эта область у нас еще не решена.

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

Откровенно каких-то оптимизаций я особо не припоминаю, особенно по размерам. Я бы даже сказал, что размеры часто приходят “снаружи” — в виде спецификации, механической модели уже существующего устройства, размера используемого чипа, интерфейсного разъема и т.п.

Очень часто проект может начинаться с задания множества ограничений, т.н. constraint driven desing. Инженер определяет ограничения, иногда достаточно сложные, а продукт помогает их исполнять или запрещает нарушать. Например, одна из простых проверок — ширина дорожки между определенными компонентами или допустимые углы при разводке ВЧ-трактов.

image

Каковы возможности по подключению внешнего производственного оборудования к системе? Можно ли использовать систему в составе стенда, когда на вход инженер подает формальное описание задачи, а на выходе – уже готовая схема, реализованная «в железе»?

Производственного — скорее нет, чем да. Это все же область хоть и смежная, но далекая от той, на которой фокусируемся мы — дизайн и разработка. Управлять современной сборочной линией, когда автомат на готовые платы наносит припой, размещает компоненты, а затем «запекает» плату согласно техпроцесса достаточно сложно, и совершенно не пересекается с разработкой самой платы. Хотя поддержка стадии изготовления, безусловно, есть, это одна из важнейших частей процесса — экспорт и подготовка данных для изготовления плат, для сборочного производства, для тестовых стендов и т.п.
Из подключаемого оборудования можно упомянуть Nanoboard, устройство используемое для разработки с использованием программируемой логики (FPGA/ПЛИС).

Думали ли вы о реализации некого мобильного front-end-а? Известно, что для многих CAD-систем уже есть мобильные варианты клиентских рабочих мест. Их полезность пока недостаточно очевидна, но, возможно у вас есть своё видение применимости мобильных приложений в рамках больших CAD-систем или даже САПР-ов?

На текущий момент планов таких нет. Как вы сами заметили, не совсем понятна цель и необходимость в них. Для работы их особо использовать не получится, как замена бумажных чертежей в MCAD — тоже…

В компании есть отделы, занимающиеся мобильной разработкой, но это отдельное направление в соседней области, не связанной непосредственно с AD.

Могу предположить, что у вас очень развитая объектная структура. Используете ли вы графические нотации для взаимодействия между разработчиками? Или квалификация программистов такова, что существующее распределение по зонам ответственности и функционалу модулей позволяет использовать исходный код единый источник знаний о системе?

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

Чем сложнее система, тем жестче требования к тестированию, особенно, регрессионному. Как у вас налажен данный процесс? Автоматические тесты, ручные тесты, соотношение между разработчиками и тестировщиками?

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

Какова кадровая политика компании Altium? У вас достаточно закрытая команда? Или вы всегда открыты и готовы принять на работу достойного специалиста?

В этой области компания более, чем открытая. Насколько я знаю, в текущий момент мы активно ищем разработчиков высокой квалификации в киевский и шанхайский офисы. Кстати забавный момент — так вышло, что значительную часть ядра R&D нашей австралийской компании сейчас составляют русскоязычные инженеры.

В первую очередь вы расширяете штат за счет профессионалов или есть вакансии для начинающих, кто только начинает строить свою карьеру в области разработки ПО?

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

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

Да :).

Все же Альтиум — это продуктовая компания, и от того, кто работает над продуктом зависит очень многое. Здесь мы не будем обсуждать формальные стороны вопроса, для этого есть специальные люди в нашей компании (anastasia.demchenko@altium.com), они всегда на связи.

Чтобы работать в Altium на позиции разработчика, что нужно знать помимо Delphi? Нужно быть «электронщиком», родившимся с «паяльником в руках»? Или нужно очень хорошо знать математику и теорию САПР? Или просто нужно быть грамотным программистом с хорошим опытом решения разнообразных задач?

Нет, не обязательно для работы в нашей компании нужно было родиться «с паяльником в руках» :)) Безусловно знание электроники или математики для некоторых направлений это плюс, но не обязательное требование — круг задач с которыми мы сталкиваемся очень широкий.

Какова стратегия развития продуктовой части? Что сейчас является приоритетным направлением? Повышение уровня автоматизации? Расширения функционала? Попытка войти в смежные области, например, проектирование других элементов сложных технических систем?

Есть несколько направлений, в основном они нацелены на расширение занимаемой доли на рынке ECAD систем. Т.е. мы вряд ли будем двигаться в сторону механических CAD, кроме как расширяя интеграцию с существующими продуктами, но наверняка будем улучшать, к примеру, возможности проектирования плат в 3D.

Традиционный вопрос. Что можно посоветовать начинающим программистам, которые хотят дорасти до уровня профессионально разработки, чтобы быть, к примеру, востребованным компанией Altium?

Ответ в общем случае здесь универсален — набираться опыта, учиться решать задачи, иметь хорошую техническую базу. Есть несколько открытых ECAD проектов, участие в них может быть очень полезным.
@FireMonkey
карма
8,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (51)

  • +16
    Когда предыдущий шеф гордо сказал, что в проекте миллионы строк кода, то я мысленно сделал рука-лицо, и, надо сказать, не ошибся в своих предположениях.
    • +4
      Altium действительно очень большой и сложный продукт.
      • –3
        Я один вспомнил не менее сложные продукты, например, от компании Autodesk (всякие там AutoCAD, Inventor, 3DStudioMAX, Maya и пр.), разработанные на альтернативных языках программирования и инфраструктуре?

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

        Я так понимаю, аргументация типа Skype и Total Commander написанный на Delphi уже мало кого вставляет? Автор статьи решил тяжёлую артилерию в бой кинуть?
        • +5
          Язык все дохнет-дохнет, дохнет-дохнет. Да ни как вот не подохнет. Может хватит уже говорить про мертвость языка, на котором пишут промышленные проекты?
          • +3
            Живым он будет по ходу вечно, как и всякие там COBOL'ы, на которых тоже написано полно промышленных проектов, которые с одной стороны просто не трогают, потому что и так работает, а с другой стороны количество новых проектов на нём стремится к нулю. Вы хоть один реально крупный и реально новый проект найдите за последние 5-6 лет, который народ отважился писать на Delphi (ну кроме самого)… Хотя давайте назовите какую-нибудь узкоспециализированную тулу, разработанную на Delphi, потому что главный инженер НИИЧАВО больше ничего не знает, и до этого 20 лет лабал одну систему, вот теперь за новую взялся, а что-то новое выучить уже возраст не позволяет :)

            На том же С и C++, который хоронят не меньше, вот вам пачка довольно свежих и на порядок более сложных по сравненнию с какой-то там CAD-системой проектов, которые на слуху у общественности: Chromium, Chrome OS, Firefox OS, а ещё всякие другие менее известные мобильные операционные системы, всякие Node.js, Nginx и пр. — по сути до его распространённости он впереди планеты всей… Хотелось бы что-то подобное, что у всех на слуху услышать, а то из спора в спор всё одни и те же Skype и Total Commander перетекают, вот ещё какая-то CAD система появилась — теперь её приводить будут :)

            Если зомби всё ещё шевелится, это не значит, что он на самом деле живой.

            P.S. «c какой-то там CAD-системой» — не зря сказано — я в теме и сам работал над промышленной коммерческой CAD системой (первая работа), поэтому понимаю, что практически любая CAD гораздо проще по своей реализации, чем например браузер. В CAD меньше внешних неизвестных или плавающих факторов, хотя математика и физика (например конечно-элементный анализ какой-нибудь) там может быть гораздо сложнее. Но это уже математика и физика, имеющая к языку программирования очень опосредованное отношение.
            • +1
              Каждый пишет на чем считает нужным. Или все должны писать на одном_истино_тру_вечно_живом_языке? IT сильно разнообразием задач и арсеналом для их решения. Если кому-то нравится делфи — прекрасно. Если вам (на сколько я понял из вашего комментария) нравится С/С++ — работайте на нем. Делфи, как наследник паскаля, обладает полнотой по тьюрингу. Следовательно, любую задачу в теории на нем можно сделать. Это всего лишь инструмент, со своими плюсами и минусами. Хорошие и плохие программы на нем делают конкретные люди, а не синтаксис/компилятор/IDE
              • –1
                ну вот… опять то же самое… отвечаем а вопрос, который сами хотим, а не на вопрос, который задавался :( Стыдно что ли, что новых проектов нет (причём как ни хороших, так ни прохих, которые делают люди)? Или всё же есть? Или мы не знаем?

                Сколько бы он не был бы полным по Тьюрингу (как и ассемблер прям :) ), для коммерческой разработки, на которую вы так напирали выше, необходимы и другие преимущества: распространённость и популярность сегодня (чтобы легко можно было найти специалистов), распространённость под различные платформы, наличие широкого комьюнити и широкого набора инструментов. Тот же C# на голову обгоняет Delphi по всем параметрам. Я уже не говорю про всякие С++ и Java.

                Кроме отсутствия необходимости переписать говнокод, наработанный за годы, других преимуществ у Delphi просто нет. В лучшем случае он где-то не хуже. Но это «где-то» исчезающе мало.
                • 0
                  ru.wikipedia.org/wiki/Delphi_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)
                  • 0
                    Извиняюсь, не правильно ссылку вставил. Вот статья вики со списком
            • +12
              То что в треде, в котором упоминается слово делфи — всегда появляется холиварщик, готовый костьми лечь, чтобы доказать что делфи мировое зло — никого не удивишь.
              Но Вас, как одного из представителей я хочу спросить:
              Откуда у вас (холиварщиков) эта психологическая травма? Вам в детстве делфи жизнь сломал? Когда и при каких обстоятельствах Вы почувствовали что делфи это мировое зло? Вы пробовали говорить на эту тему с психологами?
              • –2
                То что в треде, в котором упоминается слово делфи — всегда появляется холиварщик, готовый костьми лечь, чтобы доказать что делфи это наше всё без оперирования фактами и ответами на прямые вопросы — никого не удивишь.

                Вы реально пишете на нём потому что видите какие-то преимущества (блин, ну вот какие?) по сравнению с другими технологиями или у приверженцев Delphi просто мозгов не хватает изучить что-то другое? А может просто нравится?

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

                Для делфистов же просто мнение о смерти как виагра для старпёра: «Нет язык не мёртв — это вы его постоянно закапываете!»
                • +6
                  готовый костьми лечь, чтобы доказать что делфи это наше всё
                  Я ничего никому не доказываю. Я спрашиваю почему вы приходите на хаб Delphi, и всем доказываете. Это вроде не хаб C\C++, и что делфи круче, а остальное мастдай — я не говорил. Так что в данный момент вы готовы лечь костьми, чтобы наставить читателей хаба Delphi на путь истинный.
                  Ну а мне всего лишь интересно, почему вы это делаете с таким упорством, как будто вам на мозоль жизни наступили. Выглядит как психологическая травма с детства, ей богу.
                  • –5
                    а я и не про ваши кости…

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

                    Но может я неправ? И я прихожу в блог Delphi, где надеюсь встретить профессионалов, которые мне объяснят, в чём я неправ. Но всё развивается всегда по одному и тому же сценарию (лучший сценарий): я спрашиваю, мне отвечают, я уточняю, мне отвечают, я уточняю моменты, в которых я вижу проблему в надежде, что я просто что-то не знаю или не понимаю, человек видно не может ничего ответить по существу и максисмум что делает — отвечает пространными фразами (ну типа «это решаемо», «язык обладает полнотой по Тьюрингу» и пр. теоретические выкладки), кидается приколами типа «забанили в Google» и пр. Результат: ответа на вопрос я не получил, меня объявили тролем :)

                    Это что касается общего…

                    В данном случае не так. Статья просто кишит маркетинговым посылом какая Delphi классная и смотрите какой проект на ней можно забабахать. При этом это не преимущества Delphi, это просто ещё один проект, который мог быть сделан на чём угодно. Я просто компенсировал тяжесть маркетингового вброса, приведя примеры других проектов, «случайно» написав, что язык скорее мёртв, чем жив.

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

                    И да, я не могу считать живым язык, на котором пишут скорее по привычке и инерции, на котором не было ни одного нового большого проекта за последние 5-6 лет (при том, что в IT 2 года — считай новая эра) и который подходит разве что для поддержания накопленного говнокода.

                    Готов изменить своё мнение, но пока фактов и аргументов нет, кроме как доставания с антресолей проектов в лучшем случае из первой половины 2000-х с криками: «Мы ещё живы!»
                    • +5
                      О мертвых плохо не говорят.
                      Я с паскаля и дэлфи вообще начинал программировать(как и многие здесь, я думаю).
            • 0
              > Вы хоть один реально крупный и реально новый проект найдите за последние 5-6 лет
              А ещё можно попросить назвать реально крупный и реально новый проект на, не знаю, php. И если не назовут — то говорить, что php умер. А если назовут, то говорить, что он не крупный, или что программист кроме php ничего не знает.
          • +3
            Хоронили Delphi, порвали три Fortran'а
        • +2
          Я только хотел сказать что 4 миллиона строк для Altium — вполне реальность т.к. хорошо представляю его функционал — он огромен.
  • +11
    Как вообще можно судить о продукте/проекте по количеству строк кода? И вообще, чем больше строк кода, тем больше вероятность ошибки — основы теории вероятностей.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        На Википедии хорошая статья об этом.
        • НЛО прилетело и опубликовало эту надпись здесь
  • +5
    Очень интересно.

    Интересно прочесть подобный пост от разработчиков FL Studio.
  • +2
    Целью данной статьи ни в кой мере не является продвижение или рекламирование Altium Designer

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

    По факту получилась стандартная маркетинговая жвачка чуть приправленная вымученными «сколько у вас пунктов меню? а окошек? у вас есть нескучные обои?».
    Где же обещанные «вглубь» и «особенности реализации»?
    • 0
      Поддерживаю. Все вопросы вида «А есть ли у вас такая полезная и уникальная фича, позволяющая пользователям сделать быстро и просто со скидкой 21% ?»
  • +2
    КОМПАС 3D, Лоцман, Вертикаль да и практически все отсальные продукты АСКОНа на Delphi написаны. Только теперь их активно переписывают из за тормознутости, отсутсвия гибкости Delphi кода.
    • 0
      На что переписывают то?
      • 0
        Ну флагмановские продукты на C++ + QT, а новые по-разному, например Лоцман: ПГС на C#
    • 0
      Скорость работы программы в большей мере зависит от программиста, а не от языка программирования. Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.

      И да, тоже интересует какой же язык выбрали в качестве «быстрого».
      • 0
        Скорость работы программы в большей мере зависит от программиста, а не от языка программирования. Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.
        да?? то есть если например написать браузер целиком на плюсах, а потом на руби при одинаковых временных рамках, то его скорость будет одинакова? то есть ты вот так утверждаешь??
        • 0
          Во-первых, я написал «в большей мере от программиста», а не «только от программиста и не от чего либо другого», а во-вторых сравнивать компилируемый язык программирования с интерпретируемым в быстродействии — это как минимум глупо. Вот если бы делфи был интерпретируемым языком программирования и написали, что от него отказываются из-за не большой скорости выполнения, тогда и вопроса не возникло.
          • 0
            а во-вторых сравнивать компилируемый язык программирования с интерпретируемым в быстродействии — это как минимум глупо.

            Согласен. Правда шибко большим умом я не отличаюсь. поэтому взял дельфийский код из эпичного треда forums.embarcadero.com/thread.jspa?threadID=74930 и перевел на java script gist.github.com/jack128/7983236
            в результате на моей машине delphi xe4 (32bit релиз) 1,8sec
            node v0.10.23 — 1,069sec
            • 0
              И много таких эпичных тредов вы знаете?

              Я согласен, в Делфи есть свои узкие места, я их обычно обхожу написанием библиотеки на C/C++ с нужным мне функционалом, но в целом язык не на столько медленный, чтобы вот так взять и переписывать гигантские проекты на другой.

              Я сам бывал в подобной ситуации: есть в программе функционал, смотрю на него и понимаю, что быстрее уже не сделаешь, а тут мне один из пользователей говорит, что у конкурентов такой же функционал работает в 2 раза быстрее (программа на C#). Смотрю — действительно так. Начинаю оптимизировать свой код и знаете что? — всегда мне удавалось оптимизировать его до аналогичной либо большей скорости выполнения. А вот такого, что из-за Делфи все очень медленно работает и ничего с этим не поделать на моей практике еще не было.
              • 0
                походу ты забыл свой же исходный посыл. Напомню:

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

                А теперь почему то начинаешь сравнивать свой код и код каких то программистов на C#.

                Я вообще не знаю, как можно не понимать простой вещи. Если пишут ПО люди равной квалификации, то как раз наоборот, единственное от чего зависит скорость результирующего продукта — это язык/компилятор.
                • 0
                  Если пишут ПО люди равной квалификации, то как раз наоборот, единственное от чего зависит скорость результирующего продукта — это язык/компилятор.


                  Это да, но если код изначально плохо оптимизирован, то смена языка программирования не даст значительного прироста в скорости. Потому я и написал «ожидать значительного ускорения работы программ не стоит». А причина так плохо о программистах думать у меня та, что они решили полностью переписать все программы (если это действительно правда), а не только узкие места. Знаю я таких горе программистов, у них все виноваты: тугие компьютеры, криворукие пользователи, тормозная Делфи, но только не они.
                  • 0
                    Это да, но если код изначально плохо оптимизирован, то смена языка программирования не даст значительного прироста в скорости
                    смена языка программирования при плохом исходном коде даст ровно тоже ускорение, что и имена оного при хорошем коде. Если язык/компилятор дает хреновый маш. код для пузырьковой сортировки, то и для quicksort он выдаст хреновый маш. код.

                    Ну вот например, классический пример в холиварах C vs C++ ideone.com/E5JDWq.
                    ВНЕЗАПНО разница от смены языка программирования в три с гаком раза. Хотя конечно можно сказать, что «три раза» — это не значительная разница. Причем тут компилятор даже один и тот же, прирост обусловлен только языком.
                    • 0
                      Вас не в ту степь несёт. Вы мне пытаетесь доказать, что язык имеет значение в скорости работы программы. Спасибо, я это знаю, я этого не отрицал и говорил совсем о другом. Я говорил о том, что для программиста, который винит медленную скорость работы программы язык программирования, смена этого языка не очень то и поможет, потому что в первую очередь нужно оптимизировать алгоритмы. Плохо оптимизированный алгоритм будет на столько же плохо оптимизирован и на другом языке программирования. И не обязательно переписывать всю программу, можно переписать только узкие места. И ваши единичные примеры это доказывают. Вот сколько вы примеров доминирования в скорости работы одного языка над другим можете привести? Хотя бы десяток осилите?
                      • 0
                        Я говорил о том, что для программиста, который винит медленную скорость работы программы язык программирования, смена этого языка не очень то и поможет, потому что в первую очередь нужно оптимизировать алгоритмы.

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

                        Вроде простая мысль же. Если на выходе компилятора быстрый код, значит вероятность что тебе придется этот код оптимизировать меньше. А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.
                        • 0
                          Вроде простая мысль же. Если на выходе компилятора быстрый код, значит вероятность что тебе придется этот код оптимизировать меньше.


                          Два слова: «единичные случаи». Можете привести больше примеров доминирование одного языка программирования по скорости над другим, хотя бы десяток? А если я приведу диаметрально противоположные примеры для тех же языков, то что это значит?

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

                          Вы думаете, что я не понимаю простых вещей, но это вы не понимаете меня и то, что я пытаюсь вам сказать. Если выкидывать слова из контекста, то конечно же я не прав, но что именно в моём первом сообщении не правда? Вы хотите сказать, что:

                          1. Смена языка однозначно значительно ускорит программу? Вы на 100% уверены?
                          2. Скорость работы программы не зависит от программиста? Да это даже смешно обсуждать.

                          А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.

                          А это уже однозначно зависит от программиста и больше не от чего другого. У одних и с первого раза нормальный код не получается, а другие внеся десятки изменений умудряются получить чистый и читаемый код.
                          • –2
                            Два слова: «единичные случаи». Можете привести больше примеров доминирование одного языка программирования по скорости над другим, хотя бы десяток? А если я приведу диаметрально противоположные примеры для тех же языков, то что это значит?
                            Да любой код на плюсах с шаблонами _всегда_ быстрее по сравнению с кодом на дельфи с виртуальными методами/указателями на функцию. Как частный случай — это лямбды.

                            Смена языка однозначно значительно ускорит программу?
                            смотря как это язык выбирать.

                            Скорость работы программы не зависит от программиста?
                            Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.

                            А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.


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

                            Угу, только проблема в том, что таких идеальных программистов нету в реальной жизни. А если вспомнить, что обычно чем быстрее алгоритм, тем он сложнее…
                            • –1
                              Да любой код на плюсах с шаблонами _всегда_ быстрее по сравнению с кодом на дельфи с виртуальными методами/указателями на функцию. Как частный случай — это лямбды.


                              В Делфи тоже есть подобие шаблонов, называется оно только по другому — дженерики. Провел эксперимент: написал 2 похожие по функционалу операции работы с шаблонными объектами, а именно запись в ассоциативный массив и чтение из ассоциативного массива. Одна программа на Делфи ( pastebin.com/Y9CGvmJ7 ), вторая на С++ ( pastebin.com/AeQmL3ux ). Обе программы скомпилированы со стандартными настройками Release конфигурации проекта. Использовались Delphi 2010 и VS 2012.

                              Запускаем тест.

                              Делфи:
                              Reading file speed: 63 ms.
                              Adding to the dictionary: 156 ms.
                              Dictionary reading: 109 ms.

                              C++:
                              Reading file speed: 516 ms.
                              Adding to the dictionary: 797 ms.
                              Dictionary reading: 500 ms.

                              И _ВНЕЗАПНО_ «всегда быстрее С++» проиграл с умопомрачительным разрывом, что доказывает, что программист в большей мере влияет на скорость работы программы чем компилятор, потому что в данном случая я просто перевел код с одного языка на другой.

                              Я не спорю, что можно оптимизировать С++ код и значительно его ускорить, но я очень сильно сомневаюсь, что вам удастся добиться значительно лучших результатов чем в исходном (под значительно лучшими я имею ввиду прирост в скорости хотя бы на 25%).

                              смотря как это язык выбирать.

                              Так как мы обсуждение ведем в ветке о Делфи, то давайте отталкиваться именно от Делфи. Назовите любой, который побьёт в любых тестах по скорости работы делфи код и при этом будет сопоставим с удобством разработки.

                              Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.

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

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

                              Я никогда не видел больных раком, но это не значит, что их нету.
                              • +1
                                Провел эксперимент: написал 2 похожие по функционалу операции работы с шаблонными объектами, а именно запись в ассоциативный массив и чтение из ассоциативного массива.

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

                                Назовите любой, который побьёт в любых тестах по скорости работы делфи код и при этом будет сопоставим с удобством разработки.
                                Оригинальная постановка. Ты понимаешь, что например скорость считывания с диска гигового файла практически не зависит от ЯП и компилятора?

                                Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.

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


                                Еще раз процитирую
                                Так что если будут переписывать те же люди, что делали изначальный продукт, то ожидать значительного ускорения работы программ не стоит.
                                • –2
                                  Переход на личности? Отличный ход. По существу нечего сказать? Всего хорошего.
                                  • +2
                                    То есть все это:

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

                                    не по существу?? Ну тогда гудбай.
                              • +1
                                И хоть я часто выступаю за Дельфи, но здесь сравнение кода некорректно чуть более, чем полностью! Вы меня конечно извините, но код на плюсах — полное говно %)
                                • –3
                                  А что собственно говоря не корректно? Сравнение чтение и записи ассоциативных массивов на разных языках это чуть более чем полностью не корректно? Вы меня конечно извините, но я же не сравниваю операцию умножения с отрисовкой окна.

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

                                  Ну да ладно, предоставьте решение лучше. Вот человек заявляет, что С++ даёт ощутимые преимущества в скорости выполнения кода абсолютно во всех операциях в которых слабым звеном является сам код, но почему то рабочего примера не предоставил, а занимается только пустозвонством и оскорблениями выставляя это неопровержимыми фактами.
            • 0
              запустил этот скрипт на wscript.exe 5.8 — считал 7мин 22сек /11мин 28сек
              • 0
                нашел node.js — действительно, математика у него немного быстрее чем в XE5
                1.8 против 2.1 сек
    • 0
      а где почитать можно об активном переносе на другие языки?
  • +2
    Altium Designer — отличный пример того, что важен не язык а реализация. Когда пользовался им 4 года назад — дизайнил довольно простую платку. Никаких нареканий по работе программы на очень среднем железе 2004 года не было. Все довольно шустро крутилось, рендерило 3д-модель. Без этого топика никогда и не подумал бы что написан он был на Delphi.

    Кстати на Delphi в свое время многие энтузиасты писали свои проги-полезняшки, не будучи глубоко знакомыми с программированием как таковым. Как пример — всякие мониторы ИБП, мониторы температуры, вентиляторов ПК и прочее. Порог вхождения ниже, и соответственно результат получался быстрее.
  • 0
    А можно вопрос по интеграции Альтиума с другими информационными системами? В описании имеющихся скриптовых языков я не увидел возможности общения с внешним миром, кроме как через текстовые файлы. А есть ли возможность работать с сетью (чтобы можно было дергать web сервисы) или вызова COM объектов? Или для этого надо Developer SDK покупать?
  • 0
    Да я вообще считаю, что писать под «большую ЭВМ» на С/С++ — это изврат! Для микроконтроллеров, начиная от тупеньких «восьмерёночков» до 8-ядерных Ti'евских DSPшников — да. Здесь Си — вне конкуренции, по собственному опыту. По «сухому» железу, или по неразвитой оси типа uCos — тоже да. Но писать под «взрослые» операционки на сях — извините. Потом разбирать огроменный и нечитаемый код на языке, который изначально был предназначен быть как можно ближе к «железу» — увольте! Под «хосты» писал и писать буду на Дельфи!

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