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

>...Вы предпологаете что сделанные Вами ДПЛА будут развиваться тольво Вами или по крайней мере людьми, знакомыми с техналогиями, по которым они создавались

Отнюдь не так. Более того, я большую часть своего времени посвящаю тому, как сделать так, чтобы дальнейшее развитие ДПЛА вообще не зависело от меня. В частности "матрично-мультиплексная инкапсуляция функций", если видели мой сегодняшний пост, нацелена именно на это. Пока не описал ещё, но в течение месяца сделаю. Там от языков и ЭВМ вообще ничего не будет зависеть. И от меня тоже:). И это хорошо.
Кстати, ДПЛА -- это только один из представителей широкого класса искусственных объектов с программируемым интеллектом. А вовсе не узкая область. Правда?

А она исполняет программу, команда за командой.

Утверждение попросту неверно.

ЭВМ решает сложные логические задачи, многие (очень важные) из которых вообще недетерминированы и непоследовательны во времени.

Таки неправда Ваша. Способность исполнять заложенную в памяти программу именно команда за командой -- это, по сути, ответ на вопрос "что такое ЭВМ?". А это вот устройство такое, которое способно исполнять заложенную в памяти программу команда за командой. Только некоторые команды являются командами перехода, причём условного перехода. А некоторые последовательности команд начинают выполняться по внешним событиям, прервав ранее выполнявшуюся последовательность.

ВСЁ! БОЛЬШЕ В ЭВМ НИЧЕГО СУЩЕСТВЕННОГО НЕТ!

А сложные логические задачи вовсе не ЭВМ решает. И даже не программа. А человек, написавший программу и предопределивший нечувственное решение этих задач, программой, исполняемой на ЭВМ.

Ясность -- прежде всего!

{+}

{+}

То, что вы описали неверно для случая параллельного вычислителя.

А в промышленности и бизнесе сейчас вообще все системы параллельны по своей сути.

Через несколько лет и домашние десктопы тоже станут параллельными.

ЭВМ -- машина, умеющая вычислять логические выражения. Машина же Тьюринга является упрощенным и далеко не универсальным частным случаем ЭВМ.

Машина Тьюринга это всего лишь модель ЭВМ. На смаом деле ЭВМ -- это устройство... см. выше.

Машина Тьюринга как модель схватывает главную сущность ЭВМ. Это последовательное выполнение программы и условные нарушения последовательности по программе.

Не виляйте:). Параллельная ЭВМ -- это несколько непараллельных.

А самолет -- это всего лишь несколько винтиков и болтиков.

Нет уж, есть принципиальные различия, когда мы переходим к параллелизму.

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

рада,что вы уже выздоровели!

не болейте, берегите здоровье!!

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

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

но бензопила - быстрее.

так что любой технологии - свое место.

бортовой вычислитель Ваших систем, насколько я понимаю, управляет достаточно несложными формализованными операциями в условиях ограниченных ресурсов. вот эта вот штука - http://www.borland.com/resources/en/pdf/products/together/together_datasheet_tvs2005.pdf делает совершенно другое и в других условиях. сделать некоторые вещи, реализуемые с ее помощью, методами процедурного программирования невозможно - окончательно доказано было еще в середине 80-х, в том числе и на примере американской системы СОИ. могу поискать библиографию, причем даже тех же лет.

собственно, вещь как раз и предназначена для сохранения ясности в голове. точнее - в головах.

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

Как Вы думаете, мебедь красного дерево всегда делают бензопилой? Наверное. Это же быстрее.

Сложные комплексы, о которых идёт речь, создаются годами и десятилетиями. Здесь неуместна гонка наподобие выпусков очередных бессмысленных версий коммерческих программ. И если надо сделать комплекс ДПЛА быстро, то надо просто взять уже готовую разработку. Если у Вас она есть, конечно. А сделать быстро, особенно благодаря применению каких-то скоростных технологий программирования, невозможно. Когда делают летающие предметы, то стараются сделать не быстро, а хорошо. Иначе будет бесконечно долго.

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

Конечно. Главная проблема именно в формализации. Тогда и будет "достаточно несложно". Увы, скоростные технологии тут бессильны. Ум нужен. Кто будет "подвешивать колокольчик", в смысле формализовывать?
Кадры решают всё"(с)товарищ Сталин. Люди решают, а не примочки от Борланда.

>...сделать некоторые вещи, реализуемые с ее помощью, методами процедурного программирования невозможно

Охуеть! Дайте две!

{+}

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

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

То, что сложные, например, авиационные комплексы делаются годами и десятилетиями вовсе не означает, что они делаются по методике группы "Б". Они наоборот, делаются по методике группы "А", методом проб и ошибок, в том числе.

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

Сумбурно несколько, но Вы поймёте, я думаю.

{+}

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

>Как Вы думаете, мебедь красного дерево всегда делают бензопилой? Наверное. >Это же быстрее.

прекрасно. мне нужно напилить 5 кубометров дров (машина, на зиму надо 3 машины). Если я буду пилить ножовкой - до ноября не успею.

>Сложные комплексы, о которых идёт речь, создаются годами и десятилетиями. >Здесь неуместна гонка наподобие выпусков очередных бессмысленных версий >коммерческих программ. И если надо сделать комплекс ДПЛА быстро, то надо >просто взять уже готовую разработку. Если у Вас она есть, конечно. А >сделать быстро, особенно благодаря применению каких-то скоростных >технологий программирования, невозможно. Когда делают летающие предметы, то >стараются сделать не быстро, а хорошо. Иначе будет бесконечно долго.

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

>Конечно. Главная проблема именно в формализации. Тогда и будет "достаточно >несложно". Увы, скоростные технологии тут бессильны. Ум нужен. Кто будет >"подвешивать колокольчик", в смысле формализовывать?
>Кадры решают всё"(с)товарищ Сталин. Люди решают, а не примочки от Борланда.

Сталин вообще во многом был прав, чем больше живешь - тем больше это понимаешь. Технологии сами по себе ничего не могут решить. Однако, людям для работы нужен инструмент.

Можно пилить дрова столярной ножовкой. Но у нас есть граничное условие - дрова должны быть готовы к зиме. Если дров к зиме нет - мероприятие теряет смысл. В случае мебели граничное условие - функциональное и красивое изделие.

Разные задачи - разные инструменты.

"Примочки", кстати, как Вы это назвали, делают всего в двух местах в мире. Одно из них - С-Петербург, Финляндский 4А, где и делают описанное.

>>...сделать некоторые вещи, реализуемые с ее помощью, методами процедурного >>программирования невозможно

>Охуеть! Дайте две!

приглашаю Вас к себе на станцию Токсово. 5 кубометров леса и столярную ножовку обеспечу.

Ум нужен везде - даже при распиловке дров. Но вариант пилки и колки дров силой одного лишь чистого разума я отвергаю. Потому что видел только в кино.

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

это верно. если подойти к мебели с бензопилой - получатся дрова, причем плохие.

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

В каком смысле невозможно - теоретически или же по причине больших затрат времени?

>...В каком смысле невозможно

Я думаю, что в смысле "быстрее конкурентов":). Все "программисты" чокнулись на скорости разработки. Есть вещи поважнее чем скорость, да. Капитализм - говно.

при причине затрат времени, превышающих срок жизни человека, а также по причине выхода сложности системы за рамки понимаемого человеком.

>...причине выхода сложности системы за рамки понимаемого человеком.

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

:)

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

программирование в последнее время все больше и больше превращается в классический индустриальный труд, а программист - в рабочего. у форда рабочий крутил гайку ключом на 3/8 дюйма вручную ключом, а программист крутит "вртуальную гайку" мозгом.

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

Чистяков, я целиком поддерживаю ваше определение ЭВМ. Ну что вы бодаетесь с этими "программистами".
Ясность нужна во всем, остальное словоблудие

Фу! Хоть Вы это знаете. А то просто отчаяние охватывает.
Спасибо.

Нутк
Старая школа! КАИ - пуп земли!
З.Ы: Прошу болезненно не воспринимать. Это просто дань традиции и моей школе :)

Так Вы тоже авиатор! Я многих выпускников КАИ знал. А пуп, так пуп, какая разница. Так и надо жить, в пупе. А то многие всегда считают, что пуп -- это где-то там... В Новом Ёрке, например. В итоге становятся нудными провинциалами. Особенно гуманитарии склонны к этому:).

{+}

Есть у меня один КАИст (вместе в аэроклубе летали), который тоже ДПЛА проектировал, на полигонах пропадал. Зовут Андрей Попов. У него даже вроде страничка в инете была по тематике. Надо бы порыться найти

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

Боюсь, что Вы просто не знаете насколько сложны информационные системы современногоь самолёта. Я уж не говорю о ВВС, например, или ПВО в целом.

Кстати, Вы не ответили. У Вас есть высшее образование?

По меркам программирования все системы там примитивны до зубной боли.

>...По меркам программирования все системы там примитивны до зубной боли.

Такие системы делаются десятилетиями. Думаю, если бы они были примитивными, то новые истребители пекли бы, как новые версии "ВиндовС". Вы чего-то недопонимаете, по-моему.

Просто -- это хорошо. Сложно и дурак сделает. Я таким принципом руководствуюсь.

И, всё-таки, какое у Вас образование?

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

Тем не менее, есть реальная, неотложная потребность в "сложных" ИС. Кто-то должен их проектировать и строить.

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

Двое студентов из группы считали напряжения в радиальной шине с помощью знаменитого конечноэлементного пакета ANSYS. Заметили, что при одной и той же модели, элементной разбивке, нагрузке, закреплении, наборах свойств материалов АНСИС выдавал совершенно разные напряжения. Пошли к руководителю проекта, естественно, подозревая, что это они в чем-то не разобрались, т.е. не ансис виноват. Однако преподаватель сказал, из-за внутренних "косяков" в написании одного или нескольких модулей ансиса, а из-за закрытости его кодов, естественно, нам невозможно ничего определить и исправить. Поэтому ANSYSу "доверили" лишь создание регулярной сетки элементов, а весь расчет вынуждены были программировать "вручную" на 77-м Фортране.

Похожая ситуация была и у меня - занимался расчетом динамических характеристик арбалетного лука. Нужно было создать мат. модель нелинейного деформирования лука как плоского стержня, получить систему ОДУ и создать программу, проводящую расчет на трех этапах - "подвязка тетивы", "натяжение тетивы", "выстрел" и оптимизировать форму стержня лука и его сечение. Стоял выбор - делать все это в MatLab или использовать язык программирования (любой). В общем, я выбрал Delphi ("практически" Паскаль) - не пожалел об этом. Моя программа считает это за 5-15 секунд, МатЛаб бы считал минут 10 и только из-за своих стандартных модулей интегрирования систем ОДУ (Адамса, Рунге-Кутта, которые просто обозначены как numeric - вот и гадай, какую он там схему использует), к которым программа обращается в циклах по нескольку тысяч раз.

Кстати говоря, Ansys и Matlab — качественные продукты, которые сделаны профессионалами, и в безупречности реализации простых схем и алгоритов можно не сомневаться.

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

Ansys и Matlab — качественные продукты, которые сделаны профессионалами, и в безупречности реализации простых схем и алгоритов можно не сомневаться. - ДА.

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

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

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

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

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

Программистам вообще доверять нельзя. Никогда.

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

Очень близко! Мне даже синусы самому приходилось программировать, а то пакетные врали безбожно. Я "пакетами" уже 20 лет не пользуюсь. Если хочешь хорошо, делай сам. Такой вот лозунг. Зато пакеты рисуют красиво:)

Ну да. В Вашу деятельность я лезть не пытаюсь, но судя по всему, у Вас, как и у других (в т.ч. американских, израильских) инженеров, занимающихся ДПЛА, просто нет другого выбора.
Для расчетчика все-таки какой-никакой выбор имеется. Все зависит от задач - если нужно создать именно программный продукт, ориентированный на расчет и оптимальное проектирование чего-либо (те же арбалетные луки или зубные брекеты), то нужно делать самому. Ну а для проведения, скажем, единичного расчета вполне сгодятся ANSYS или MatLab. В конце концов, именно с помощью MatLab я проверял решения системы, всевозможные другие элементарные действия - обращение матриц, решение СЛАУ (решает моя программа, получаю "ответ", далее с теми же условиями решает пакет) - опять же, другого выхода у меня не было.

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

{+}

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

Помню эксперимент в невесомости с балкой из конечных элементов то ли на Салюте, то ли на Мире. Что-то хотели посчитать, но оказалось дешевле запустить на орбиту физическую модель чем морочиться с расчетом.

>...дешевле запустить на орбиту физическую модель чем морочиться с расчетом

У меня тожа так бывало порой. Особенно, когда матчасть есть, то проще провести испытания, чем расчёты. Да и достоверность результата совсем другая, да. Правда, когда делаешь расчёт, то больше думаешь. Это тоже очень важно:)

Может быть. Но это уже как минимум лет 20 назад было (если это Мир), тогда еще МКЭ только набирал обороты, не был так известен и развит. А если Салют, то это уж совсем "глубокая древность" :). Зенкевич же только в 73-м, кажется, написал и опубликовал свой труд "Конечные элементы и аппроксимация". До него, безусловно, метод тоже существовал, но была путаница и в названиях, и в символах, систематизировал все именно он. О каких-либо мощных пакетах речи до конца 80-х вообще не шло. Думаю, сейчас подобное моделируют в том же NASTRANе (реже ANSYS) за несколько часов.

Слушайте, если Вы занимаетесь ДПЛА, какого вы вообще лезете в развитие информационных технологий в нашей стране, и навязываете никому не нужные "паскалеобразные" языки типа Оберона?
Я в курсе того, что именно паскаль используется у военных, например, на нем реализованы системы управления для ПВО, авиационных комплексов и еще куча всего.

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

Да, и позвольте спросить, на каком языке написана операционная система, под которой Вы разрабатываете программы? Случайно ли не на Си?

Извините, но Вы молоды ещё, указания давать чем мне заниматься, а чем не заниматься.
Что Вы так взволновались? Пишите на "Си", на здоровье. Придёте ко мне, будете на Паскале писать. Никаких проблем. А мою деятельность ещё никто ни в чём не ограничивал. Я считаю, что молодёжь портят маловразумительным подходом к программированию. В итоге молодёжь работает хуже, чем могла бы, если бы её правильно научили.

Дорогой мой! Мои программы не работают под управленияем чьих бы то ни было операционных систем. Они работают непосредственно на ЭВМ.

Re: Вы кто?
Я — студент, к которому видимо, применили маловразумительный подход к программированию. Сейчас занимаюсь вовсе другими вещьми, но по долгу специальности иногда приходится программировать.

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

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

По поводу последнего предложения.. уверен, Вы знаете, что ЭВМ исполняет проргамму в машинных кодах. Уверен, также Вам известно, что Паскаль - язык программирования высокого уровня. Так кто делал компилятор, который преобразует программу на паскале машинный код?

>...Вразумительность обучения программированию вовсе не зависит от языка, на котором их учат

Неправда Ваша. Язык всегда диалектически воздействует на представление о предмете. Это не только к программированию относится. Попробуйте рассказать один и тот же короткий сюжет на русском и на английском. Вы заметите, что сам язык уже вносит какую-то окраску. Кнут-то свой язык для изложения алгоритмов в своей книге всё-таки придумал. То есть нельзя без языка-то, да? "Улица корчится, безъязыкая..."(с)В.Маяковский. Чувствует, а сказать не может.

Вы правы в том, что хорошо бы обучать программированию вообще без кодов. Только математика и алгоритмы. Это было бы идеально. Молодёжь бы не засоряла мозги особенностями того или иного языка. Однако, такое обучение неинтересно. Помните восторг, который возникает, когда Ваша программа впервые пошла на ЭВМ? МОлодым это очень нужно.
Поскольку язык всё равно нужен для описания алгоритмов (вспоминаем Кнута, опять же), то неплохо бы чтобы этот язык позволял транслировать и исполнять программы на реальных ЭВМ. В качестве такого языка для первоначального обучения и предлагается Оберон (потомок Паскаля). Он чрезвычайно прост. Он не позволяет создавать "опасные" конструкции. В то же время, Оберон -- полноценный язык. Уж точно не слабее "Си". Важно ведь что ещё, чтобы текст программы "смотрелся". На "Си" тексты не смотрятся. Да и лишнего там больше, чем необходимого. Зачем нам лишнее, да ещё и "опасное" подчас.

В Вас говорят некие религиозные чувства. Я замечал это у многих "сишников". Психику, что ли "Си" травмирует?:)

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

>...Так кто делал компилятор, который преобразует программу на паскале машинный код?

Компилятор написал один немец из Иоганесбурга (ЮАР). Зовут его Райнер. Я его знаю. Писал он транслятор на Дельфи.

И в заключение:

>...Заниматься надо теми вещьми, в которых вы действительно разбираетесь

Было бы любопытно узнать, как Вы определили в чём я разбираюсь, а в чём нет? Это очень полезное искусство. Научите?

С Богом, студент!

{+]

Если Вы утверждаете, что программирование не должно превратиться в изучение конкретного языка, то почему же тогда, одной из ключевых целей проекта Информатика-XXI является.."пропаганда и внедрение в системе образования Компонентного Паскаля/Оберона как практически идеальной единой платформы для систематического преподавания основ программирования в XXI веке."; "значение Оберона для программирования можно сравнивать со значением евклидовых "Начал" для классической математики" ?

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

Так может лучше заняться разработкой стандарта ИТ-образования в школе? Но только с требованиями к знаниям алгоритмов и устройства компьютеров, без привязки к какому-либо языку. А конкретный язык пускай выбирают преподаватели — им наверно виднее, как лучше научить ребенка, ведь чтобы его научить надо быть не только хорошим математиком/программистом, но и хорошим учителем. Опять же в качестве варианта можно предложить наглядный Visual Basic.Net, который, к тому же, допускает не только чистое программирование, но и долю творчества.

Вообще по поводу конкретного языка мне сложно спорить, так как я не видел ни одной программы на Обероне (хотя на Паскале не только видел, но и когда-то сам писал). Но, повторюсь, я абсолютно против навязывания ЯП "сверху". Если Вы приведёте конкретные доводы за такое навязывание, возможно, я с Вами соглашусь.

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

Если уж так хочется низкопоклонничать перед американцами, лучше уж выберите что-нибудь вменяемое: http://mitpress.mit.edu/sicp/full-text/book/book.html

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

А кто и где к тебе применил "маловразумительный подход к программированию"?!
Потому что, учась с тобой в одной группе, я подобного подхода со стороны преподавателей явно не замечал. Может быть, это ты сам? :)

я это не утверждал, а лишь предположил

извиняюсь за оффтоп.. было бы интересно узнать Ваше мнение об этом..
http://www.newsru.com/russia/08jun2005/corbie.html

Кажется, тут уже шла речь о Ямахе, но вот это, по-моему, очень неплохая реализация вертолета-разведчика.

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

Показательно, что пишут бред. Дальность 25 км, а с автопилотом 150, что ли, км. Интересно, как улететь на дальность 25 км без автопилота? Врут-с...

{+}

Насколько мне известно основная часть ядра Windows написана на "плоском" C с вставками ASM. И если драматизировать, то наверное в самом наиответственнейшем месте гордо забили прямой машинный код не доверяя ассемблеру. И посему, наверняка группу ядерных людей в Microsoft держат в специальном ящике с промасленой бумагой, а на ящике прибита алюминиевая талбичка с надписью "хранить вечно, при пожаре выносить в первую очередь". А всяких немытых типа C++ и C# к настоящим близко не подпускают чтобы те не развратили ортодоксов своими пошлыми объектно-ориентированными мыслями.

В общем, наверное, так:)

"Объектно-ориентированность" можно реализовать и на голом С. Кстати, как раз именно так и делается в ядре Виндовс. Вас удивляет то, что С и С++ -- разные языки с разными свойствами и характеистиками?

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

Впрочем, с заявленной задачей ООП справляется плоховато. (Но это отдельная тема и к вашей критике его вообще никак не относится.)

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

Надёжность и функциональность не противоречат друг другу. Это раз.
Два. Отлаживать на пользователе -- неэтично.

И три. А если бы компьютер после каждого сбоя взрывался, тогда как, где бы были Виндовс? А зависание программы для ДПЛА -- однозначная катастрофа. Вопрос цены ошибки, да.

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

Сложность - это всегда безобразие. Не думайте что "программисты" так легко соглашаются на усложнение своих продуктов добавлением новых или сменой привычных слоев новыми. В современном дизайне в любой области от карманных сотовых органайзеров до атомных реакторов всегда есть проблема как определить направление "хорошо"/"плохо". В 100% случаев и без исключения побеждает "дешево". В случае с software "дешево", значит сложно, поскольку есть рынок готовых компонент. Да есть исключения, как например в вашей теме с роботами, где объем кода достаточно обозрим и возникает соблазн вести полностью авторизованый дезайн. Прекрасно если этот случай счастливо избежит 3rd party компоненты или неверифицируемые источники. И этот случай вовсе не показателен для проблемы сложности. Те кто строит свой продукт используя гигабайтные код-базы просто позавидует и не найдет в этом опыте ничего полезного.

>...Те кто строит свой продукт используя гигабайтные код-базы

Пусть строят. Любой объём можно свести к простоте путём структурирования. Спасибо за советы.

А если бы компьютеры взрывались из-за сбоев, то никаких бы Виндовс не было. Никто бы не стал связываться:)

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

Если Вы — обычный пользователь, то Windows для вас может быть надёжна, но спросите у математиков, под какими ОС они работают, сами убедитесь.

Только не говорите про Юникс, это сведет уровень общения с вами до планки цырка с конями.

Если Вы про что-то специальное, малотиражное, в керамических корпусах с золотыми ножками и подписями сборщиц на каждой веревочке, то это менее надежно и обычно менее сложно чем какой-нибудь копеечный калькулятор. Было замечено годах в 90-х например что в Японии новые дизайны чипов идут в массовый тираж для каких-нибудь игрушек и утюгов, а потом в авионику и др. специальные места, а в штатах сначала для военных, а потом в массовый тираж. Преимущество по качеству оказалось у японцев. По этой причине я уверен, что в какой-нибудь QNX для атомных реакторов концентрация багов удельно на инструкцию CPU выше чем в Windows.

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

Если сравнивать Windows и Unix-подобные системы, то последние, опять таки гораздо надёжнее, если правильно скомпилировать ядро. И поверьте мне, как человеку, копавшемуся с ядром Линукса и нашедшим в нём ошибки, ядро Windows не идёт ни в какое сравнение с UNIX.

Мой критерий - цена и распространенность, поэтому продукция Microsoft с инженерной точки зрения в том числе рулит. Вера в QNX без source code - не больше чем вера, подкрепленная замечательным маркетингом компании QNX. У меня такое же было отношение к Novell в свое время, не без участия маркетинговых первопроходцев этой фирмы, пришедших в Россию в числе самых первых. Но приведись мне делать что-то в математике ничего лучше Windows и не надо.

Мои аргументы, естественно, не приведены.

Это же Ваши аргументы:). Приводите, пожалуйста здесь.