Здравствуйте, mrozov, Вы писали:

M>Павел, тут такая штука. Ты хочешь понять, но внутренне протестуешь. Ты ищешь поводы не принять эту идею, а причина — в черезмерном увлечении производительностью скорости. Ты на этом немного зациклился.

Может, ты и прав

M>Может, тебе такой ответ понравится/будет близок. .Net — это, как и Java, вещь безусловно не эфимерная. Они останутся.

+1

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

+-


M>Если ты так уж увлечен низкоуровневым программированием — просто ищи для себя соответствующие задачи и все. Их немного, но людей, способных их эффективно решать — еще меньше. И тогда — какое тебе вообще дело до .net? Равно как и до js, например. Ну какое тебе дело до его скорости и особенностей функционирования, если ты не пишешь клиентский код для браузеров?

M>А если ты по каким-либо причинам вынужден иметь дело с прикладным программированием (читай — ширпотребом), тогда твои дела плохи в любом случае. Даже есои ты на .net не перейдешь, то за любовь к оптимизации тебе в этом деле никто спасибо не скажет. Тут действительно нужно менять мировоззрение, но .net тут собственно непричем.

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

А что касается лично меня — если уж так потребуется, плюну 3 раза и напишу неэффективно. Черт с ним

M>И вообще — если вопрос практический, если он касается выбора специализации на ближайшее время... Ну подумай сам, остановки роста производительности пока нет, остановки роста объема памяти — вообще пока не предвидится, многопроцессорные машины снимут остроту проблемы одновременного запуска тяжелых приложений... Никаких выдающихся тормозов управляемый код не привносит — ну несерьезны эти 10-15 процентов на реальных приложениях. MS свое любимое детище, опять же, будет поддерживать всей своей немеренной массой.

Вот последнее меня больше всего и смущает. Если бы не этот фактор — я вообще бы махнул рукой на все эти нововведения. Кто умеет писать эффективно — неэффективно написать всегда сможет

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

Начни новый топик

PD>Ява появилась — я не стал их смещать и был прав.

Не думаю. Я бы даже сказал — очень жаль. Я думаю, ты недооценивашь место Java в мире. Другое дело, что с маркетинговыми заявлениями того времени оно очень мало общего имеет.

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

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

Здравствуйте, mrozov, Вы писали:

PD>>Ява появилась — я не стал их смещать и был прав.

M>Не думаю. Я бы даже сказал — очень жаль. Я думаю, ты недооценивашь место Java в мире. Другое дело, что с маркетинговыми заявлениями того времени оно очень мало общего имеет.

Ты не совсем меня понял. Я не могу всеми на свете языками и системами заниматься. Вопрос стоял так — стоит ли переводить обучение на Яву в свете того, что это генеральное неправление ? И на него я ответил отрицательно. А спецкурс по Яве — бога ради, но я его не веду.

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

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

А тебе не кажется, что слова мировоззрение и (тест-кейсы, соблюдение сроков) — слишком уж из разных миров ? ИМХО соблюдение сроков не есть элемент мировоззрения все же. И оформление кода к мировоззрению так же мало имеет отношения...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А тебе не кажется, что слова мировоззрение и (тест-кейсы, соблюдение сроков) — слишком уж из разных миров ? ИМХО соблюдение сроков не есть элемент мировоззрения все же. И оформление кода к мировоззрению так же мало имеет отношения...

Нет, не кажется. Или скажу иначе — имеет ровно такое же отношение. как и оптимизация.

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

Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, Pavel Dvorkin, Вы писали:

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

Увы, согласиться не могу. Аргументировать не буду — не хватает еще флейм на тему тесткейсов начать, но не согласен. Если человек умеет грамотно писать, но не делает отступы — это лечится намного легче, чем неумение писать.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Увы, согласиться не могу. Аргументировать не буду — не хватает еще флейм на тему тесткейсов начать, но не согласен. Если человек умеет грамотно писать, но не делает отступы — это лечится намного легче, чем неумение писать.

Не видел никого, ктобы писал грамотно без отступов. А вот обратное видел.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Увы, согласиться не могу. Аргументировать не буду — не хватает еще флейм на тему тесткейсов начать, но не согласен. Если человек умеет грамотно писать, но не делает отступы — это лечится намного легче, чем неумение писать.

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

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

Pavel Dvorkin,

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

> А тебе не кажется, что слова мировоззрение и (тест-кейсы, соблюдение сроков) — слишком уж из разных миров ?

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

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет, вопрос иначе стоит. Я преподаватель. И я хочу понять — действительно ли надо смещать акценты в своем преподавании или же все это только мода.
Павел, преподавание — вообще очень скользкая тема. Как неоднократно говорилось, в том числе и в этом форуме, все очень сильно зависит от того, кого ты хочешь получить на выходе.
Есть инженерный подход — он требует обучать людей основам промышленного производства софта. А это означает, что надо следить за тем, что сейчас важно в промышленности, а все остальное — в объеме "можно прочитать в гугле по таким-то ключевым словам".
Есть подход научный — в нем наоборот, главное — не заслонить общую картину мелкими деталями.

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

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

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

Потому, наверное, надо какие-то бесспорные истины преподавать. Не знаю вот только, какие именно
Но хочу предостеречь — в любом случае не стоит вбивать стремление к микроэффективности. Уж очень у нее поле применения теперь узкое. Да, само понятие эффективности быть должно. Чтобы с первого взгляда отличали O(N) от O(logN). Но очень важно умение работать в команде. А оно требует в первую очередь писать понятный код. Время гениев-одиночек прошло безвозвратно. Даже research сейчас ведется командами.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

S>Есть инженерный подход — он требует обучать людей основам промышленного производства софта. А это означает, что надо следить за тем, что сейчас важно в промышленности, а все остальное — в объеме "можно прочитать в гугле по таким-то ключевым словам".
S>Есть подход научный — в нем наоборот, главное — не заслонить общую картину мелкими деталями.

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

S>Я лично считаю, что идеальный IT-специалист должен, с одной стороны, быть всегда готов решить задачу, которую никто раньше не решал (а не как наши друзья из индии, которые встают в тупик сразу по окончанию набора готовых сэмплов из MSDN), а с другой стороны — писать код, который не стыдно в коммерческую систему вставить.

+1

S>Но я себе слабо представляю, какой системой преподавания можно этого добиться. И даже то, каким мировоззрением это должно обеспечиваться.



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

+3.

>У нас вообще большая часть преподавателей ФИТ физфак заканчивала, с минимальной IT-подготовкой.

Угу. А я химфак


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

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

S>Но хочу предостеречь — в любом случае не стоит вбивать стремление к микроэффективности. Уж очень у нее поле применения теперь узкое.

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


>Но очень важно умение работать в команде.

+1. Увы, это в вузе очень серьезная проблема. Но это отдельная тема.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ни то, ни другое.
PD>Первое просто не годится — я вовсе не хочу учить их тому, "что сейчас важно в промышленности". Сейчас одно, через пять лет другое, а у нас все же университет...
PD>Второе — пресловутый академизм. Оторванность от реальности.
Именно. +2.

PD>Я сию минуту не готов излагать свое видение обучения информатики. Может, как-нибудь открою топик (и не здесь, конечно, а в "Образовании")
Дык, все ж к тому ведет. Понимаешь, все вопросы-то вроде бы такие конкретные и четко очерченные. А с другой стороны, ответ-то зависит от того, с какой целью спрашивается. Вот ты, оказывается, дотнет пытаешь не просто из научного любопытства, а для того, чтоб свое преподавание как-то скорректировать. Что само по себе очень хорошо.
[оффтоп]
Как-то был у нас практикум по АСУ. Одна из первых задачек: написать программу управления термостатом. Вводим типа значение температуры, а программа должна его поддерживать. При этом есть датчик (точность — 0.1 градуса), и два ТЭНа, которые можно включать и выключать. Инерционность — дикая. Если писать программу в стиле "если холоднее X — включаем, теплее X — выключаем", то будут колебания в районе 10 градусов. Для сдачи надо в пределах [-1..1].
Я подсмотрел у одного из наших идею решения: применяем модуляцию скважностью. В теории я ничего не парил, потому сделал банальный цикл, который после каждой итерации корректировал скважность в зависимости от температуры и ее производной. Программа держала температуру в пределах погрешности датчика, т.е. сказали 58.4 — держит 58.4 (после пары минут прогрева). Сам я ей страшно гордился. При сдаче мне ее еле зачли. Почему? Потому что релюшкой она щелкала постоянно. Типа, износ аппаратуры будет от такой программы великий. Когда я рассказал об этом папе, он странно на меня посмотрел, и сказал, что я изобрел как раз давно известный классический способ точного управления мощностью шибко инерционных девайсов, и что механические реле в таких конструкциях уже очень давно не применяются.
Мораль: преподаватель жил реалиями многолетней давности. Можно, конечно, все это по-разному интерпретировать, но для преподавателя очень важно быть в курсе текущих достижений. Иначе авторитета никакого не будет. Ляпнешь что-нибудь типа "а что, С++ от С чем-то отличается?" и все, упес пипиндур.
[/оффтоп]

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

PD>Вот это маловероятно. В самом деле, какой такой ерундой можно забить ? Например ? Только ради бога, не надо про микрооптимизацию
Не, ну мало ли. Я сам не так уж много лично с заблуждениями сталкивался. Повезло работать с вменяемыми людьми. Самые две большие проблемы, которая встречались:
1. Непонимание технологии вообще. Человек пишет так, потом эдак, потом еще как-то. Пока оно случайно не заработает. Попытки спросить "почему ты выбрал этот способ" обречены — да нипочему. Просто предыдущие ндцать попыток вообще не заработали, а эта хоть как-то поднялась. Ужос, господа, это ужос. Программирование в стиле квест — когда от отчаяния начинают применять палку к коврику, а чайник к двери.
2. Непонимание, как бы это сказать, сути вещей. Ну вот пример: коллега из США (к слову, родом с индостана) пишет код, который вычисляет интервал между двух моментов времени. Время вводится в четырех инпутах — для часов и минут отдельно.
Раньше минуты всегда были 00, поэтому интервал вычислялся как (endHour-startHour). Я ему объясняю, что надо всего лишь прибавить к часам минуты и поделить: (endHour*60+endMinutes — startHour*60-startMinutes)/60.
Все. Тупик. Два часа общения по аське. Он не смог. Увы, у меня сейчас нет доступа к исходникам того проекта, чтобы посмотреть, через какое ухо он это все-таки реализовал. Я бился головой о клавиатуру и рыдал.

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

PD>Вот никак я одно понять не могу. Почему нужно упорно доказывать то, с чем я вовсе не спорю. Я ведь совсем не о микрооптимизации писал, а о культуре написания кода. О грамотном написании. Нет — сели на конька "ах, он про оптимизацию" — и слезть не могут. Зачем ?
Ок, давайте уже слезем с этой микрооптимизации. Давайте про что-то другое говорить.
Ты же сам ставишь вопрос именно об эффективности (а вовсе не культуре написания кода).
>>Но очень важно умение работать в команде.
PD>+1. Увы, это в вузе очень серьезная проблема. Но это отдельная тема.
Как же отдельная? Это как раз и есть вопрос культуры. Более того, эта эффективность как раз и есть камень нашего преткновения.

Я вообще начинаю подозревать, что перспективы развития систем лежат вовсе не в масштабе отдельных задач — ну там типа "теперь мы можем решать дифуры порядка 2000, а раньше — только 899." А в сложности комплексов. Для написания которых просто не хватает ресурсов. Ну вот предположим, что для написания искуственного интеллекта (или хотя бы программы тотального управления финансами для целого государства при детализации до каждого гражданина) нужно сделать миллиард строк осмысленного кода. Да уже даже 1 миллион строк один программист никогда не напишет. Нужно что? а) средства, позволяющие написать это за миллион строк вместо миллиарда и б) средства, позволяющие поделить задачу разработки между, скажем, 1 миллионом девелоперов.
Тогда подобные проекты попадут в "сферу достижимости".
Тридцать лет назад программирование работало в приближении "очень ограниченные вычислительные ресурсы, бесконечные ресурсы разработчиков". Сейчас наблюдается несколько обратная тенденция — трактовать все в приближении "очень ограниченные ресурсы разработчиков, бесконечные аппаратные ресурсы". Что это означает?
Что нужна "единая теория поля", которая свяжет и те и другие ресурсы в одно уравнение, как квантовая электродинамика связывает скорость света и квантовую постоянную. Вот эта-то теория и расскажет нам, как правильно решать задачи. И какие задачи вообще можно ставить.

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

Вроде бы, ничего особенного. Мы вообще привыкли к таким вещам — к тому, что сотовый телефон успевает компрессировать звук в реальном времени, что уже есть видеокамеры, способные писать поток сразу в MPEG-4, и вмещать по шесть часов на фиговинку размером с марку. На десктопе это как-то не очень заметно — вон винда 2003 с первого взгляда от 95 не очень и отличается. Ну иконки в правом углу стали полупрозрачными, ну градиент добавился в заголовках. Юзабилити у эксплорера улучшили — сейчас он мне группирует фотографии по размеру и модели камеры безо всяких специальных софтов, и показывает их thumbnail вместо иконки 16*16.
А вот умная электроника все больше в нас проникает. Все помнят говорящую куртку и самозавязывающиеся кросоовки из Назад в Будущее — 2? Хм, осталось еще 10 лет, ребята. Я что-то уже начинаю сомневаться, что это фантастика.

Здравствуйте, Sinclair, Вы писали:

PD>>Я сию минуту не готов излагать свое видение обучения информатики. Может, как-нибудь открою топик (и не здесь, конечно, а в "Образовании")
S>Дык, все ж к тому ведет. Понимаешь, все вопросы-то вроде бы такие конкретные и четко очерченные. А с другой стороны, ответ-то зависит от того, с какой целью спрашивается. Вот ты, оказывается, дотнет пытаешь не просто из научного любопытства, а для того, чтоб свое преподавание как-то скорректировать. Что само по себе очень хорошо.



S>[оффтоп]

<skipped>

S>Мораль: преподаватель жил реалиями многолетней давности. Можно, конечно, все это по-разному интерпретировать, но для преподавателя очень важно быть в курсе текущих достижений. Иначе авторитета никакого не будет. Ляпнешь что-нибудь типа "а что, С++ от С чем-то отличается?" и все, упес пипиндур.

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


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

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

+1.

S>2. Непонимание, как бы это сказать, сути вещей.

<skipped>

Это не лечится. Или человек возьмется за ум сам, или ничего не будет. Ему можно подсказать, но если он не хочет слушать, то бесполезно.


S>Внимание, вопросы:
S>- какое преподавание могло привести к таким проблемам?

А оно тут скорее всего ни при чем. У человека просто такой "квест" стиль мышления. Проще говоря, неумение алгоритмизировать свою собственную деятельность. Я как преподаватель мало что в таком случае могу изменить.
А с другой стороны, если человек просто не есть грамотный специалист (пример с твоим индусом), то что тут поделать ? "Даром преподаватели время со мною тратили" и т.д, помнишь эту песню ?

S>- можно ли решить такие проблемы на уровне преподавания?

Трудно сказать. Культутуру написания кода, надо, конечно, прививать. Но хаос в голове преподаванием не лечится ИМХО. Заставлять же кого-то делать не так, как ему хочется — я вообще-то против. Потому что вообще против попыток заставить — не верю я в успех таких начинаний. Так что одно из трех — либо он сам поймет (а я могу его подтолкнуть), либо не найдет себе места в ИТ, либо все же найдет такое место, где это не столь важно (согласись, и такие места есть



S>- нужно ли вообще решать эти проблемы на уровне преподавания, или достаточно разработать эффективные методики тестирования кандидатов, и просто отсеивать их при приеме на работу?

П.3 не к преподавателям, а к работодателям, обсуждать не буду.

PD>>Вот никак я одно понять не могу. Почему нужно упорно доказывать то, с чем я вовсе не спорю. Я ведь совсем не о микрооптимизации

S>Ты же сам ставишь вопрос именно об эффективности (а вовсе не культуре написания кода).

Для меня это если не синонимы, то почти. Я имею в виду именно культуру, не допускающую делать "неэффективно".

S>Я вообще начинаю подозревать, что перспективы развития систем лежат вовсе не в масштабе отдельных задач — ну там типа "теперь мы можем решать дифуры порядка 2000, а раньше — только 899." А в сложности комплексов. Для написания которых просто не хватает ресурсов. Ну вот предположим, что для написания искуственного интеллекта (или хотя бы программы тотального управления финансами для целого государства при детализации до каждого гражданина) нужно сделать миллиард строк осмысленного кода. Да уже даже 1 миллион строк один программист никогда не напишет. Нужно что? а) средства, позволяющие написать это за миллион строк вместо миллиарда и б) средства, позволяющие поделить задачу разработки между, скажем, 1 миллионом девелоперов.
S>Тогда подобные проекты попадут в "сферу достижимости".

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

А вообще не готов я это сейчас обсуждать. Через час лекция



S>Тридцать лет назад программирование работало в приближении "очень ограниченные вычислительные ресурсы, бесконечные ресурсы разработчиков". Сейчас наблюдается несколько обратная тенденция — трактовать все в приближении "очень ограниченные ресурсы разработчиков, бесконечные аппаратные ресурсы". Что это означает?
S>Что нужна "единая теория поля", которая свяжет и те и другие ресурсы в одно уравнение, как квантовая электродинамика связывает скорость света и квантовую постоянную. Вот эта-то теория и расскажет нам, как правильно решать задачи. И какие задачи вообще можно ставить.

+1


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

Я с этм давно знаком . Но, должен тебе сказать. что до цифрового аппарата у меня была мыльница за $20, которая умела многое (хоть и не все) из этого списка. Наводка на резкость (т.е выбор значимого объекта), диафрагма, выдержка...

S>А вот умная электроника все больше в нас проникает. Все помнят говорящую куртку и самозавязывающиеся кросоовки из Назад в Будущее — 2? Хм, осталось еще 10 лет, ребята. Я что-то уже начинаю сомневаться, что это фантастика.

И даже порой весьма своеобразным способом

http://www.rsdn.ru/Forum/Message.aspx?mid=1494713&amp;only=1

Автор: Pavel Dvorkin
Дата: 18.11.05

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

Здравствуйте, mrozov, Вы писали:

M>Не думаю. Я бы даже сказал — очень жаль. Я думаю, ты недооценивашь место Java в мире. Другое дело, что с маркетинговыми заявлениями того времени оно очень мало общего имеет.

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

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

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

Касательно же общей темы, помимо "технических" навыков, будущих инженеров надо учить принимать адекватные решения. Т.е. учить взвешивать затраты/выхлопы и уметь расставлять приоритеты. И тут никакого противоречия и даже (!!!) пересечения во времени. Кодированию учат на первых 2-х курсах (та самая область обучения "эффективному" программированию, мы же его мусолим здесь?). Проектированию — начиная с 3-го и до конца. Я лично не вижу причин смещать акценты в первых 2-х годах обучения. Ибо, это можно сделать только одним способом — недоучить.

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

Здравствуйте, mrozov, Вы писали:

PD>>А тебе не кажется, что слова мировоззрение и (тест-кейсы, соблюдение сроков) — слишком уж из разных миров ? ИМХО соблюдение сроков не есть элемент мировоззрения все же. И оформление кода к мировоззрению так же мало имеет отношения...

M>Нет, не кажется. Или скажу иначе — имеет ровно такое же отношение. как и оптимизация.

M>Т.е. если преподаватель откажется принимать лабу, если код оформлен неряшливо или к нему отсутствует набор тест-кейсов, да еще со словами "мне наплевать, как быстро это работает, оно непригодно к промышленному использованию", то это будет самое, что ни на есть прививание мировоззрения.

Немного надуманная ситуация. Неряшливость в коде наблюдается именно у слабых программистов. Ибо она — от неряшливости в голове.

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

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

M>Равно как таковым будет наплевательское отношение к комментарием и похвала "молодец, ассемблерная вставка тут очень к месту".

А если лабы на ассемблере? (у нас таких была просто тонна на разные архитектуры)

Здравствуйте, Sinclair, Вы писали:
S>[оффтоп]
S>Как-то был у нас практикум по АСУ. Одна из первых задачек: написать программу управления термостатом. Вводим типа значение температуры, а программа должна его поддерживать. При этом есть датчик (точность — 0.1 градуса), и два ТЭНа, которые можно включать и выключать. Инерционность — дикая. Если писать программу в стиле "если холоднее X — включаем, теплее X — выключаем", то будут колебания в районе 10 градусов. Для сдачи надо в пределах [-1..1].
S>Я подсмотрел у одного из наших идею решения: применяем модуляцию скважностью. В теории я ничего не парил, потому сделал банальный цикл, который после каждой итерации корректировал скважность в зависимости от температуры и ее производной. Программа держала температуру в пределах погрешности датчика, т.е. сказали 58.4 — держит 58.4 (после пары минут прогрева). Сам я ей страшно гордился. При сдаче мне ее еле зачли. Почему? Потому что релюшкой она щелкала постоянно. Типа, износ аппаратуры будет от такой программы великий. Когда я рассказал об этом папе, он странно на меня посмотрел, и сказал, что я изобрел как раз давно известный классический способ точного управления мощностью шибко инерционных девайсов, и что механические реле в таких конструкциях уже очень давно не применяются.
S>Мораль: преподаватель жил реалиями многолетней давности. Можно, конечно, все это по-разному интерпретировать, но для преподавателя очень важно быть в курсе текущих достижений. Иначе авторитета никакого не будет. Ляпнешь что-нибудь типа "а что, С++ от С чем-то отличается?" и все, упес пипиндур.
S>[/оффтоп]

Оффтоп на оффтоп. Сорри — не удержался.
Задача известная и она именно из области АСУ — автоматических систем управления. И твоя программа и наличие реле — вовсе не при чем, это просто абстракция конкретной задачи. А задача именно такова — инерционность обратной связи, + инерционность воздействия. Решается пропорционально-интегрально-дифференциальным управлением (ПИД). Конкретные параметры ты должен был подсчитать из условий своей задачи.

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

Да, и конкретно по твоей задаче. Представь, что нагреватель у тебя находится в одном месте (проточный нагреватель), а термодатчик — на выходе длинной трубы (надуманно, но тем не менее). Т.е, добавляем очень сильное запаздывание. В этом случае даже ШИМ не работает, опять возвращаемся в классику АСУ.

--------
В общем, обвинять препода не стоит, суть лаб была не в том, чтобы искать конкретное инженерное решение в виде ШИМ, а овладеть принципами теории АСУ на примере конкретных абстракций.

Здравствуйте, vdimas, Вы писали:

V>Оффтоп на оффтоп. Сорри — не удержался.
V>Задача известная и она именно из области АСУ — автоматических систем управления. И твоя программа и наличие реле — вовсе не при чем, это просто абстракция конкретной задачи. А задача именно такова — инерционность обратной связи, + инерционность воздействия. Решается пропорционально-интегрально-дифференциальным управлением (ПИД). Конкретные параметры ты должен был подсчитать из условий своей задачи.
О, классно. А как можно рассчитать конкретные параметры в этом случае? И при помощи чего

V>Да, и конкретно по твоей задаче. Представь, что нагреватель у тебя находится в одном месте (проточный нагреватель), а термодатчик — на выходе длинной трубы (надуманно, но тем не менее). Т.е, добавляем очень сильное запаздывание. В этом случае даже ШИМ не работает, опять возвращаемся в классику АСУ.
И что применяется вместо ШИМ в этом случае?

Здравствуйте, vdimas, Вы писали:

V>Прежде, чем давать Павлу советы, как именно преподавать, неплохо узнать что именно он преподает и кому.
V>(Не обязательно уточнять, это не вопрос, просто замечание оппонентам)

Хоть это и не вопрос , но отвечу.

Преподаю Win32 + MFC студентам 3 курса математического ф-та. На первых двух курсах их действительно учат в основном кодированию и структурам данных.

Что касается эффективности, то вообще-то не так много в этом курсе мест, где она может быть. Но насколько могу и насколько это задачам соответствует, борюсь за эту самую эффективность

Здравствуйте, Sinclair, Вы писали:

S>[оффтоп]
S>Как-то был у нас практикум по АСУ. Одна из первых задачек: написать программу управления термостатом. Вводим типа значение температуры, а программа должна его поддерживать. При этом есть датчик (точность — 0.1 градуса), и два ТЭНа, которые можно включать и выключать. Инерционность — дикая. Если писать программу в стиле "если холоднее X — включаем, теплее X — выключаем", то будут колебания в районе 10 градусов. Для сдачи надо в пределах [-1..1].
S>Я подсмотрел у одного из наших идею решения: применяем модуляцию скважностью.

так же оффтоп.

А зачем было изобретать велосипед? САР Ресвика (в теории, т.к. на практике в цифровых системах шумит сильно), или САР Смита модифицированная — задержка управления не более 2 тау при настроенных коэффициентах.

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

И, вероятно, изобрел ПД-регулятор? Я бы на месте преподавателя скорректировал бы задачу, увеличив продолжительность кванта времени, через которые ты можешь получить показания температуры — тогда бы Д звено начало достаточно сильно шуметь, что могло бы выводить систему в неустойчивое состояние...

Ладно, замолкаю — все мы были студентами Но все равно я против незнания теории и, при этом, изобретательства велосипедов.

Здравствуйте, Sinclair, Вы писали:

V>>Оффтоп на оффтоп. Сорри — не удержался.
V>>Задача известная и она именно из области АСУ — автоматических систем управления. И твоя программа и наличие реле — вовсе не при чем, это просто абстракция конкретной задачи. А задача именно такова — инерционность обратной связи, + инерционность воздействия. Решается пропорционально-интегрально-дифференциальным управлением (ПИД). Конкретные параметры ты должен был подсчитать из условий своей задачи.
S>О, классно. А как можно рассчитать конкретные параметры в этом случае? И при помощи чего
Есть инженерные методики расчета.

V>>Да, и конкретно по твоей задаче. Представь, что нагреватель у тебя находится в одном месте (проточный нагреватель), а термодатчик — на выходе длинной трубы (надуманно, но тем не менее). Т.е, добавляем очень сильное запаздывание. В этом случае даже ШИМ не работает, опять возвращаемся в классику АСУ.
S>И что применяется вместо ШИМ в этом случае?
ШИМ применяется, только по-другому. Выходной сигнал регулятора (положение регулирующего органа) модулируется для получения управляющих импульсов электродвигателю постоянной скорости.

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