Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет chistyakov ([info]chistyakov)
@ 2005-06-10 18:14:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Показалось важным про программирование. Выношу из комментов
Из переписки с dottedmag об объектном и прочем неестественном программировании в дискуссии "Компрачикосы от программирования".

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

Уверяю Вас, что никакие из экзотических видов программирования, перечисленных Вами, не требуются, более того вредны, при решении моих проблем. Ибо все они зиждутся на создании некоторых виртуальных слоёв архитектуры на реальном "железе" ЭВМ. Каждый такой слой, особенно когда его делали чужие люди, особенно иностранцы, является источником ненадёжности, причём принципиально непознаваемой ненадёжности.

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

Господ "программистов" просят не беспокоиться.

{+}


(Читать комментарии) - (Добавить комментарий)


[info]_lis_@lj
2005-06-11 16:20 (ссылка)
Каждый такой слой, особенно когда его делали чужие люди, особенно иностранцы, является источником ненадёжности, причём принципиально непознаваемой ненадёжности.
Да. Хоть и немного о другом, т.к. речь в моих случаях не идет о разнице "слой-железо", скорее о разнице слоев.

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

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

(Ответить) (Ветвь дискуссии)


[info]edtech@lj
2005-06-11 16:29 (ссылка)
Кстати говоря, Ansys и Matlab — качественные продукты, которые сделаны профессионалами, и в безупречности реализации простых схем и алгоритов можно не сомневаться.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]_lis_@lj
2005-06-12 06:00 (ссылка)
Ansys и Matlab — качественные продукты, которые сделаны профессионалами, и в безупречности реализации простых схем и алгоритов можно не сомневаться. - ДА.

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

(Ответить) (Уровень выше)


[info]_lis_@lj
2005-06-12 08:48 (ссылка)
Может там и работают профи, но непосредственным программированием заняты почти студенты, которые в программировании толку особо не знают. - ахуеть! Дайте две!

(Ответить) (Уровень выше)


[info]leonid_@lj
2005-06-14 11:08 (ссылка)
>но непосредственным программированием заняты почти студенты, которые в программировании толку особо не знают.

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

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]edtech@lj
2005-06-14 14:42 (ссылка)
а что вы хотели поподробнее узнать? Нет, я не представляю какую бы то ни было компанию, но, яаляясь, разработчиком, хорошо разбираюсь в том, каким технологиям и программистам можно доверять, а каким — нет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ex_chistyak@lj
2005-06-14 15:19 (ссылка)
Программистам вообще доверять нельзя. Никогда.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]edtech@lj
2005-06-15 12:26 (ссылка)
Товарищам из канадской QSSL — разработчикам QNX я доверяю

подробно о том, чего они добились можете посмотреть тут http://www.swd.ru/qnx/products/software/qnx6.html

Более дилетантскими, но всё же заслуживающими доверия я бы назвал разработки GNU (в том числе и компилятор Паскаля GNU Pascal).

И этим список не ограничивается.

(Ответить) (Уровень выше)


[info]leonid_@lj
2005-06-15 06:41 (ссылка)
я, работая в борланде, имею представление о том, что у нас делают студенты, и могу сказать что вы заблуждаетесь.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]edtech@lj
2005-06-15 12:14 (ссылка)
а вы спросите у товарища Чистякова почему он никогда не будет использовать трансляторы Борланда для своих целей.

Может быть, Borland хорош в области Java, ORB, баз данных, но вот для разработчика (я имею ввиду BCBuilder и Delphi) компания представляет очень ненадёжные и неудобные продукты (даже Visual studio от MS смотрится куда добротнее). Хотя всё это вполне сойдёт для промышленного программирования, но для серьёзных вещей я лучше буду использовать разработки GNU.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]leonid_@lj
2005-06-16 04:26 (ссылка)
борланд - давно уже не только и не столько трансляторы. основное направление работы сейчас - application lifecycle management, или поддержка жизненного цикла программы. то есть комплекс из моделирощика, профайлера, системы версионного хранения, системы отслеживания ошибок, системы контроля сроков разработки. компилятор и среда разработки - малая часть всего этого.

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

(Ответить) (Уровень выше)


[info]ex_chistyak@lj
2005-06-11 16:45 (ссылка)
Очень близко! Мне даже синусы самому приходилось программировать, а то пакетные врали безбожно. Я "пакетами" уже 20 лет не пользуюсь. Если хочешь хорошо, делай сам. Такой вот лозунг. Зато пакеты рисуют красиво:)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]_lis_@lj
2005-06-12 08:42 (ссылка)
Ну да. В Вашу деятельность я лезть не пытаюсь, но судя по всему, у Вас, как и у других (в т.ч. американских, израильских) инженеров, занимающихся ДПЛА, просто нет другого выбора.
Для расчетчика все-таки какой-никакой выбор имеется. Все зависит от задач - если нужно создать именно программный продукт, ориентированный на расчет и оптимальное проектирование чего-либо (те же арбалетные луки или зубные брекеты), то нужно делать самому. Ну а для проведения, скажем, единичного расчета вполне сгодятся ANSYS или MatLab. В конце концов, именно с помощью MatLab я проверял решения системы, всевозможные другие элементарные действия - обращение матриц, решение СЛАУ (решает моя программа, получаю "ответ", далее с теми же условиями решает пакет) - опять же, другого выхода у меня не было.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ex_chistyak@lj
2005-06-12 09:06 (ссылка)
Наверное, Вы поступаете разумно. Я бы так же, скорее всего, делал. То есть, программы бы писал свои, а проверку делал бы на стандартных пакетах. В Вашем случае своя программа хороша тем, что Вы точно знаете, что она делает, а что не делает. У "профессионалов" же ничего до конца не узнаешь. Плюс низкое быстродействие, как я понял из Ваших постов.

{+}

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]_lis_@lj
2005-06-12 09:13 (ссылка)
Низкое быстродействие - из-за больших нагромождений, которые я вынужден делать для решения "многослойных" задач. А как-то их оптимизировать я не волен. Но все равно пакет, особенно хорошо написанный, - это хорошо. Без них потому что плохо :)

(Ответить) (Уровень выше)


[info]rocket_surgeon@lj
2005-06-11 23:58 (ссылка)
Помню эксперимент в невесомости с балкой из конечных элементов то ли на Салюте, то ли на Мире. Что-то хотели посчитать, но оказалось дешевле запустить на орбиту физическую модель чем морочиться с расчетом.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ex_chistyak@lj
2005-06-12 03:02 (ссылка)
>...дешевле запустить на орбиту физическую модель чем морочиться с расчетом

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

(Ответить) (Уровень выше)


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

(Ответить) (Уровень выше)


(Читать комментарии) -