На чем пишется софт для КА?

[jettero]

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

[LRV_75]

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

так на прерываних от таймеров там все и построено. Плюс ПДП на котором вся регистрация

[sychbird]

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

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

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

[jettero]

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

так на прерываних от таймеров там все и построено. Плюс ПДП на котором вся регистрация

О том и речь, видел я компы для танков – тупо через ПДП все делается, вся работа программера в том, чтобы закодить и отладить готовый алгоритм по баллистике. Для ЗРК правда, когда я работал, начинали делать поумнее систему - на основе американской RTOS RTEMS. Но и работа с RTOS относительно проста и прозрачна, по сравнению с клубком API в современных оконных OS для ПК. А уж если лезть дальше в дебри энтерпрайзного софта для датамайнинга или для ERP систем... вот где реально сложная работа для программера. Чем больше составных частей, и различных уровней в системе, чем больше распределенность системы, тем сложнее ее проектировать и кодить. На встраиваемых системах такой уровень сложности архитектуры практически не встречается, разве что на самолетах (западных, увы), где реализуется приборная панель-стеклянный кокпит, навигация, доки по оборудованию итп, все в одном флаконе.

[zyxman]

В действительности речь должна идти о "слабых мозгах в квадрате" Не только о низкой квалификации программеров, но и в первую очередь о возможности использовать "манагеров низкой квалификации"

Да, само собой. Сейчас кстати большой дефицит хоть сколько-нибудь приличных менеджеров, и он будет несомненно сохраняться, пока не сделают ИИ способный заменить хотя-бы низкоквалифицированных менеджеров.

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

Во первых, "пипл хавает", и "сто миллионов леммингов не могут ошибаться" вы же это понимаете под демократией[/size]

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

Ах да, чуть не забыл - есть еще пожалуй в нулевых - главная сейчас задача минимизировать время выхода на рынок (потому что рынок плохо прогнозируем, особенно плохо прогнозируемы конкуренты), а время выхода на рынок очевидно тем меньше чем меньше сложность разработки :wink:

[sychbird]

пока не сделают ИИ способный заменить хотя-бы низкоквалифицированных менеджеров.

Об этой возможности так и хочется сказать ННШ Менеджмент - это прежде всего человеческие связи и взаимоотношения. :wink:

[Not]

пока не сделают ИИ способный заменить хотя-бы низкоквалифицированных менеджеров.

Мне вообще видится, что ИИ в государственном управлении  - единственный выход для Украины  :lol:

[Not]

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

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

[zyxman]

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

А можно без Майкрософт? :lol:

Я же тут уже кажется упоминал, что в истории уже были крайне неудобные в программировании, но очень быстрые ВМ, которые программировали два уровня программистов:
были системщики экстра-класса, которые писали все библиотеки нижнего/среднего уровня и инструменты,
и были все остальные, кто делал чисто специфические прикладные вещи используя уже готовые библиотеки.
То есть другими словами: самая сложная часть была выделена в отдельный слой и унифицирована и затем широко тиражировалась, а простым разработчикам оставили только то что может использовать тупой.
И сейчас я тоже вижу аналогичную картину - основные деньги зарабатываются на кастомизации, а ядра пишут энтузиасты, которые зарабатывают немного в сравнении с кастомизаторами, если не меньше.
И получается картина похожая на космическую отрасль, где операторы пусковых услуг и производители носителей зарабатывают меньше чем владельцы запускаемого в космос оборудования, и нет смысла развивать носители нормальным рыночным путем (а только в виде доения госструктур).
Кстати Майкрософт вполне вписывается в эту схему, тк существенных изменений их коммерческих ОС не было почти с времен NT, то есть они тот древний код тиражируют до сих пор.

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

[zyxman]

Менеджмент - это прежде всего человеческие связи и взаимоотношения. :wink:

Да это так, но не обязательно это отношения между начальником и подчиненным :wink:
Ну и кроме того человек склонен очеловечивать железяки, как например американские солдаты в Ираке привязываются к боевым роботам :lol:

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

[LRV_75]

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

извиняюсь, влез) бурно развивается рынок платежные системы, программистов там берегут

[sychbird]

извиняюсь, влез) бурно развивается рынок платежные системы, программистов там берегут

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

[PyKaB]

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

Я уже приводил примеры и подобных очень много. Я бы сказал так, что хорошо написанная программа на Си всегда будет несколько быстрее программы на Ява, но в случаях не идеальных предложений Ява вообще может вырваться вперед. 10 кратный разрыв будет наверно только в случае PHP(кто-то вспоминал вэб сервер на КА? :-D )

По поводу "для первого запуска" - не совсем понял, но в любом случае правдой на 100% быть не может. Интерпретатор все равно требует ресурсов, так или иначе.

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

Вы неправы. Хотите поспорить - приведите пример "удаленной модернизации скриптового ПО" на КА.

Я не могу с Вами поспорить ибо мало чего знаю про КА вообще и их софт в частности, тем более "скрипты" на КА пока еще не летают вроде.
НО процесс обновления, например, программы может быть достаточно простым, не требующем передачи больших объемов информации и процессорного времени.
Например, для программы на Python состоят из исходников и байт-кода лежащих рядом(runme.py, runme.pyc) и для обновления достаточно применить текстовый патч к исходнику и в простейшем случае сразу перекомпилируется байт-код.

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

[LRV_75]

извиняюсь, влез) бурно развивается рынок платежные системы, программистов там берегут

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

так я не понял, Вам внесенную сумму за оплату кредита перевели на сотовый? :shock: как такое возможно? Платежная система как называется? :? А понимаю, они скорее всего работают не по онлайн режиму, но Такое слышу впервые) и кривой интервейс тут врядли виноват, просто сам шлюз сделан криво! Ну пипес и скорее всего просто ваш банк системой не поддерживается, но платеж они приняли. Был такой вид мошениества, но видим это было давно  :shock:

[Not]

Я бы сказал так, что хорошо написанная программа на Си всегда будет несколько быстрее программы на Ява, но в случаях не идеальных предложений Ява вообще может вырваться вперед. 10 кратный разрыв будет наверно только в случае PHP(кто-то вспоминал вэб сервер на КА? :-D )

Ваш тезис может быть справедлив только в случае процедурной программы на Ява и объектной на С++. Процедурные же алгоритмы написанные на С всегда значительно быстрее аналогичных программ на Яве. Именно вследствие интерпретируемости последних. И оптимизатор (JIT, Hotspot и т.д.)вам не поможет. Хорошая оптимизированная С - программа мало чем отличается от вручную написанного ассемблерного кода - мало что приходится выбрасывать.

[Not]

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

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

[jettero]

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

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

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

[PyKaB]

Миллион строк для web проекта это только фреймворк  
Хороший WEB проект сложнее софта для КА по любому, за одним лишь исключением - web очень динамично развивающаяся среда из-за нелюбви изобретать велосипеды каждый раз и есть уже очень много готового кода.

[PyKaB]

Я бы сказал так, что хорошо написанная программа на Си всегда будет несколько быстрее программы на Ява, но в случаях не идеальных предложений Ява вообще может вырваться вперед. 10 кратный разрыв будет наверно только в случае PHP(кто-то вспоминал вэб сервер на КА? :-D )

Ваш тезис может быть справедлив только в случае процедурной программы на Ява и объектной на С++. Процедурные же алгоритмы написанные на С всегда значительно быстрее аналогичных программ на Яве. Именно вследствие интерпретируемости последних. И оптимизатор (JIT, Hotspot и т.д.)вам не поможет. Хорошая оптимизированная С - программа мало чем отличается от вручную написанного ассемблерного кода - мало что приходится выбрасывать.

Конечно, давайте писать только процедурные программы и почаще использовать ассемблер... Это конечно придаст удобство, скорость и надежность "нескольким миллионам строк кода"
Так что на порядок различий не будет, тем более что использования того же Python, Java, да хоть и PHP не убирает возможности написать критичные вещи на С, что всегда и делается

[Not]

Я бы сказал так, что хорошо написанная программа на Си всегда будет несколько быстрее программы на Ява, но в случаях не идеальных предложений Ява вообще может вырваться вперед. 10 кратный разрыв будет наверно только в случае PHP(кто-то вспоминал вэб сервер на КА? :-D )

Ваш тезис может быть справедлив только в случае процедурной программы на Ява и объектной на С++. Процедурные же алгоритмы написанные на С всегда значительно быстрее аналогичных программ на Яве. Именно вследствие интерпретируемости последних. И оптимизатор (JIT, Hotspot и т.д.)вам не поможет. Хорошая оптимизированная С - программа мало чем отличается от вручную написанного ассемблерного кода - мало что приходится выбрасывать.

Конечно, давайте писать только процедурные программы и почаще использовать ассемблер... Это конечно придаст удобство, скорость и надежность "нескольким миллионам строк кода"
Так что на порядок различий не будет, тем более что использования того же Python, Java, да хоть и PHP не убирает возможности написать критичные вещи на С, что всегда и делается

Но ведь речь о бортовых системах, не так ли? Или вы тоже предлагает веб-сервер на борт КА запихнуть?