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

G_K>А средний C#-ник сможет, ежели что, пересесть на C++ ?

А там что, ногами теперь нужно по кнопкам жать?
Да и С++ .. Сами пакеты (для С++) от Борланд и MS отличаются гораздо сильнее, чем языки.

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

C>>>Странная и некорректная аналогия.
ГВ>>Напротив. Аналогия как раз вполне корректна. Если говорить о булевых функциях, то есть система символов и способов их комбинирования ("булева функция" и табличный метод её задания), и тривиальные обозначения её некоторых конфигураций (Стрелка Пирса, Штрих Шеффера, ...) С паттернами, фактически, всё то же самое: есть исходная система (ОО-декомпозиция, данные, действия, требования, ...) и тривиальные обозначения некоторых конфигураций (Bridge, Facade, State, ...).
C>Аналогия некорректная. Патерн это не "обозначение конфигураций", а некоторый обобщенный прием, не привязанный к конкретном языку, чтоб не изобретать в который раз колесо, и чтоб программисты в команде могли общаться на одном языке, понимая друг друга, без необходимости вдаваться в детали реализации (что особенно важно на этапе проектирования).

Возможно, мы говорим о разных паттернах. Назови, пожалуйста, парочку таких обобщённых приёмов.

ГВ>>При чём тут твои критерии найма? Я говорю о той системе, которая, теоретически, должна быть преподана.
C>И я с ней не согласен. Что Вам не понятно?

Мне кажется, или ты в самом деле решил, что я противопоставляю ОО-декомпозицию булевым функциям?

ГВ>>Тогда вопроса о паттернах в виде того фетиша, как он блуждает сейчас, вообще не возникнет.
C>Ну это как обычно Ваши фантазии, не имеющие ничего общего с реальностью.

Может быть. И мне бы очень хотелось, чтобы так и было.

C>Транспортную задачу, к примеру, Вы тоже назовете фетишем?

Неужели это паттерн?

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


C>>>>Странная и некорректная аналогия.
ГВ>>>Напротив. Аналогия как раз вполне корректна. Если говорить о булевых функциях, то есть система символов и способов их комбинирования ("булева функция" и табличный метод её задания), и тривиальные обозначения её некоторых конфигураций (Стрелка Пирса, Штрих Шеффера, ...) С паттернами, фактически, всё то же самое: есть исходная система (ОО-декомпозиция, данные, действия, требования, ...) и тривиальные обозначения некоторых конфигураций (Bridge, Facade, State, ...).
C>>Аналогия некорректная. Патерн это не "обозначение конфигураций", а некоторый обобщенный прием, не привязанный к конкретном языку, чтоб не изобретать в который раз колесо, и чтоб программисты в команде могли общаться на одном языке, понимая друг друга, без необходимости вдаваться в детали реализации (что особенно важно на этапе проектирования).

ГВ>Возможно, мы говорим о разных паттернах. Назови, пожалуйста, парочку таких обобщённых приёмов.

Патерны это и есть обобщенные приемы решения стандартных задач в ОО-проектировании. Что Вам перечислить? Названия патернов?
Command, Bridge, Abstract Factory, Decorator, Facade, State, Template method, Singleton, Iterator, и т.д.

ГВ>>>При чём тут твои критерии найма? Я говорю о той системе, которая, теоретически, должна быть преподана.
C>>И я с ней не согласен. Что Вам не понятно?

ГВ>Мне кажется, или ты в самом деле решил, что я противопоставляю ОО-декомпозицию булевым функциям?

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

C>>Транспортную задачу, к примеру, Вы тоже назовете фетишем?

ГВ>Неужели это паттерн?

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

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

ГВ>>>>Напротив. Аналогия как раз вполне корректна. Если говорить о булевых функциях, то есть система символов и способов их комбинирования ("булева функция" и табличный метод её задания), и тривиальные обозначения её некоторых конфигураций (Стрелка Пирса, Штрих Шеффера, ...) С паттернами, фактически, всё то же самое: есть исходная система (ОО-декомпозиция, данные, действия, требования, ...) и тривиальные обозначения некоторых конфигураций (Bridge, Facade, State, ...).
C>>>Аналогия некорректная. Патерн это не "обозначение конфигураций", а некоторый обобщенный прием, не привязанный к конкретном языку, чтоб не изобретать в который раз колесо, и чтоб программисты в команде могли общаться на одном языке, понимая друг друга, без необходимости вдаваться в детали реализации (что особенно важно на этапе проектирования).
ГВ>>Возможно, мы говорим о разных паттернах. Назови, пожалуйста, парочку таких обобщённых приёмов.
C>Патерны это и есть обобщенные приемы решения стандартных задач в ОО-проектировании. Что Вам перечислить? Названия патернов?
C>Command, Bridge, Abstract Factory, Decorator, Facade, State, Template method, Singleton, Iterator, и т.д.

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

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

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

ГВ>>>>При чём тут твои критерии найма? Я говорю о той системе, которая, теоретически, должна быть преподана.
C>>>И я с ней не согласен. Что Вам не понятно?
ГВ>>Мне кажется, или ты в самом деле решил, что я противопоставляю ОО-декомпозицию булевым функциям?
C>Нет, я говорю о том, что я считаю, что патерны обязательно должны, просто обязаны, преподаваться в профильных ВУЗах либо в пределах курса ООП, либо (что лучше) отдельным курсом, называемым "Приемы ОО проектирования" или просто "Патерны ООП".

Это ты сказал в самом начале, не закручивай сериал про белого бычка. Я тебя прекрасно понял, потому и возражаю. ИМХО, паттерны не могут быть отдельным курсом, если это не КВН.

C>>>Транспортную задачу, к примеру, Вы тоже назовете фетишем?
ГВ>>Неужели это паттерн?
C>Нет, это другая типичная задача с осмысленным именем, которая, кстати, широко преподается на IT факультетах.

Отличный пример, кстати. Вспомни, в каком курсе и почему она преподаётся.

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

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

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

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

ГВ>>Я вполне допускаю, что помимо всего прочего, в основе паттернов лежат ещё и какие-то особенности человеческого мышления, но тогда в курс проектирования ПО должна обязательно вводиться ещё и психология. Не знаю уж, какая именно, не специалист.
FR>Вполне серъезно, не помешало бы, но из нужных разделов только психология групп достаточно зрелая, а все что связанно с мышлением, способностями и работоспособностью еще толком не устаканилось.

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

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

C>Нет, я говорю о том, что я считаю, что патерны обязательно должны, просто обязаны, преподаваться в профильных ВУЗах либо в пределах курса ООП, либо (что лучше) отдельным курсом, называемым "Приемы ОО проектирования" или просто "Патерны ООП".

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

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

C>>Нет, я говорю о том, что я считаю, что патерны обязательно должны, просто обязаны, преподаваться в профильных ВУЗах либо в пределах курса ООП, либо (что лучше) отдельным курсом, называемым "Приемы ОО проектирования" или просто "Патерны ООП".

LMA>Почему лучше, если отдельным курсом? Мне кажется, что самое место для паттернов — это примеры для общего курса по программированию, не более того — просто как хорошие примеры дизайна.

Это не примеры и это никак не относится к "общему курсу по программированию" (что это за предмет-то такой?)

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

Я не в курсе как оно сейчас, но в мои годы именно проектированию уделялось очень мало внимания и мне фактически все пришлось постичь самому по книгам, блогам, скринкастам, статьям и т.д. Хотя вполне мог бы узнать это еще в ВУЗе. Точно было бы полезнее какой-нибудь сортировки пузырьком, которую нам читали в курсе лекций про алгоритмы сортировки.

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

LMA>>Почему лучше, если отдельным курсом? Мне кажется, что самое место для паттернов — это примеры для общего курса по программированию, не более того — просто как хорошие примеры дизайна.
C>Это не примеры и это никак не относится к "общему курсу по программированию" (что это за предмет-то такой?)

Это именно что примеры удачных решений.

C>Еще раз. Паттерны — это классифицированные техники ОО проектирования.

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

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

LMA>>Почему лучше, если отдельным курсом? Мне кажется, что самое место для паттернов — это примеры для общего курса по программированию, не более того — просто как хорошие примеры дизайна.

C>Это не примеры
Почему это?

C>и это никак не относится к "общему курсу по программированию"
Относится. Просто потому, что проектирование является частью программирования.

C>(что это за предмет-то такой?)
Предметы в школах, а в ВУЗах — курсы.

C>Еще раз. Паттерны — это классифицированные техники ОО проектирования.
Паттерны проектирования — это просто поименованные примеры решений часто возникающих проблем дизайна.

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

C>Я не в курсе как оно сейчас, но в мои годы именно проектированию уделялось очень мало внимания и мне фактически все пришлось постичь самому по книгам, блогам, скринкастам, статьям и т.д. Хотя вполне мог бы узнать это еще в ВУЗе. Точно было бы полезнее какой-нибудь сортировки пузырьком, которую нам читали в курсе лекций про алгоритмы сортировки.
Мне кажется, Вы свои проблемы экстраполируете на других. Тут скорее проблема конкретного ВУЗа, если не конкретного преподавателя. Приведу пример: когда я бал первокурсником, то при изучении языка Си, когда рассматривали такую тему как параметры функций, мы изучали не только стеки и рекурсию — куда больше времени ушло на изучение stateless programming и его применении к распараллеливанию. И хотя профессор, который нам это читал, потом в "лихие девяностые" ушел из ВУЗа работать в банк, а его приемники уже не так читали этот курс, насколько мне известно, ну так и поступить в наш ВУЗ на эту специальность стало значительно проще — просто понизился уровень многих отечественных ВУЗов в тот период, значит, есть повод поступать в другие ВУЗы, только и всего.
А по поводу сортировки пузырьком — так это знать надо, ибо эта простая идея много непростых идей в различных областях породила. Но это уже на темы "Читайте Кнута всю жизнь" и "чем отличается программист от кодера"

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

LMA>>>Почему лучше, если отдельным курсом? Мне кажется, что самое место для паттернов — это примеры для общего курса по программированию, не более того — просто как хорошие примеры дизайна.

C>>Это не примеры
LMA>Почему это?
Объяснил уже.

C>>и это никак не относится к "общему курсу по программированию"
LMA>Относится. Просто потому, что проектирование является частью программирования.
Демагогия.

C>>(что это за предмет-то такой?)
LMA>Предметы в школах, а в ВУЗах — курсы.
Во-первых, не цепляйтесь к словам. Во-вторых, Вы не ответили на вопрос. Что это за курс такой?

C>>Еще раз. Паттерны — это классифицированные техники ОО проектирования.
LMA>Паттерны проектирования — это просто поименованные примеры решений часто возникающих проблем дизайна.
Примеры решения привязаны к языку, платформе, окружению. Паттерны — нет.
Паттерны — это решения типичных задач ОО проектирования, да. Паттерны — это классифицированные техники ОО проектирования, да.

C>>Вообще этот термин "паттерны проектирования" был введен не программистом, а архитектором, а в программировании его просто позаимствовали, как наиболее точно отражающий суть явления.
LMA>А это тут при чем?
При том, что Вы не понимаете о чем речь?

C>>Я не в курсе как оно сейчас, но в мои годы именно проектированию уделялось очень мало внимания и мне фактически все пришлось постичь самому по книгам, блогам, скринкастам, статьям и т.д. Хотя вполне мог бы узнать это еще в ВУЗе. Точно было бы полезнее какой-нибудь сортировки пузырьком, которую нам читали в курсе лекций про алгоритмы сортировки.
LMA>Мне кажется, Вы свои проблемы экстраполируете на других. Тут скорее проблема конкретного ВУЗа, если не конкретного преподавателя.
Да нет, это проблема всех ВУЗов, коль курс по паттернам проектирования отсутствует как класс.

LMA>Приведу пример: когда я бал первокурсником, то при изучении языка Си, когда рассматривали такую тему как параметры функций, мы изучали не только стеки и рекурсию — куда больше времени ушло на изучение stateless programming и его применении к распараллеливанию.
Пока это строится на доброй воли преподавателя, а не на стандартизированной и утвержденной программе, толку от этого не будет в общеобразовательном смысле.

LMA>А по поводу сортировки пузырьком — так это знать надо, ибо эта простая идея много непростых идей в различных областях породила. Но это уже на темы "Читайте Кнута всю жизнь" и "чем отличается программист от кодера"
Ох, ну это опять демагогия. Давайте конкретно: какие именно "непростые идеи" в Вашей голове породило знание конкретно сортировки пузырьком? Внимательно Вас слушаю.

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


LMA>>>Почему лучше, если отдельным курсом? Мне кажется, что самое место для паттернов — это примеры для общего курса по программированию, не более того — просто как хорошие примеры дизайна.
C>>Это не примеры и это никак не относится к "общему курсу по программированию" (что это за предмет-то такой?)

ГВ>Это именно что примеры удачных решений.

C>>Еще раз. Паттерны — это классифицированные техники ОО проектирования.

ГВ>В тридесятый раз один и тот же совет: наведи порядок в своей голове. Если ты говоришь о паттернах, как о техниках (способах действий человека), то это паттерны процесса, такие тоже есть, но это не "паттерны проектирования" (имея в виду традиционное понимание этого термина). То есть, скажем, Bridge — это некоторая структура классов, модулей, но никак не техника проектирования.

Читайте книгу GOF — возможно и поймете.

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

I>>>>Сейчас точно не нужно много технических специалистов с мат. бекграундом.
I>>>>Почему люфт пошел в эту стороно, догадаться не трудно, в сфере высоких технологий происходит разделение труда и это только начало.
ГВ>>>Как мне жаль твоих студентов...
I>>Я не преподаватель, но со студентами местами имею дело.
I>>Ктото пойдет в ОС, ктото займётся БД, ктото вычислениями, а ктото геймдевом. Это реальность и всем нужна совершенно различная подготовка.

ГВ>Как это связано с тем, что "не нужно много технических специалистов с мат. бекграундом"?

В моём понимании мат-бекграунд это определенные специальности. Повтас напрмер в их число не входит.

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

I>>Держишься за свои фантазии ?

S>Моей фантазии не хватает предположить, где вы кандидатов на собеседование отлавливаете, что 80% не знают про виртуальные методы.

В том числе и на RSDN. Зайти в форум где собеседования обсуждаются — больше всего крику вызывают аккурат задачи уровня сложности к в sicp.

Какой ты ВУЗ закончил ? Скорее всего один из тех, что пяток другой на всю Россию, а кроме них десятки "сельских" которые и готовят основную массу программистов.

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

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

I>>>Держишься за свои фантазии ?

S>>Моей фантазии не хватает предположить, где вы кандидатов на собеседование отлавливаете, что 80% не знают про виртуальные методы.

I>В том числе и на RSDN. Зайти в форум где собеседования обсуждаются — больше всего крику вызывают аккурат задачи уровня сложности к в sicp.

Тут какая-то подмена понятий. Не поверю, что 80% посетителей RSDN не знают про виртуальные методы. Скорее те, кто знает что такое виртуальные методы, не идут к вам на собеседования.

Задачи уровня сложности SICP — это очень расплывчатое понятие. Там от "определите процедуру, которая возвращает сумму квадратов аргументов" до "Разработайте рудиментарную реализацию Scheme на C".

I>Какой ты ВУЗ закончил ? Скорее всего один из тех, что пяток другой на всю Россию, а кроме них десятки "сельских" которые и готовят основную массу программистов.
УрГУ. Быть может он из пятого или даже десятого пятка, т.е. по твоим понятиям как-раз "сельский". Учился на троечки.

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

C>>>Это не примеры
LMA>>Почему это?
C>Объяснил уже.
Нет, не объяснили. Пока с Вашей стороны в этом плане наблюдаются только попытки представить паттерны как нечто значительное, достойное отдельного рассмотрения. И это без какого-либо обоснования.

C>>>и это никак не относится к "общему курсу по программированию"
LMA>>Относится. Просто потому, что проектирование является частью программирования.
C>Демагогия.
Это Вы о свой фразе или о моей?

C>>>(что это за предмет-то такой?)
LMA>>Предметы в школах, а в ВУЗах — курсы.
C>Во-первых, не цепляйтесь к словам. Во-вторых, Вы не ответили на вопрос. Что это за курс такой?
Какой конкетно курс — зависит от специальности и много другого. Обычно это что-то типа "Алгритмические языки и программирование"

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

C>Паттерны — нет.
Утверждая это, Вы готовы избразить реализацию singleton на прологе?

C>>>Вообще этот термин "паттерны проектирования" был введен не программистом, а архитектором, а в программировании его просто позаимствовали, как наиболее точно отражающий суть явления.
LMA>>А это тут при чем?
C>При том, что Вы не понимаете о чем речь?
Еще раз: к чему Вы приплели Кристофера Александра? По моему, Вы просто не понимаете, что разработка архитектуры ПО — часть программирования, поэтому пытаетесь их противопоставить.

LMA>>Мне кажется, Вы свои проблемы экстраполируете на других. Тут скорее проблема конкретного ВУЗа, если не конкретного преподавателя.
C>Да нет, это проблема всех ВУЗов, коль курс по паттернам проектирования отсутствует как класс.
Такой курс отсутствует как класс, потому что паттерны никто в здравом уме не будет ставить в один ряд с дискетной математикой или теорий баз данных. Аналогично, то, что почти нигде нет курсов, в названиях которых присутствуют С++, Pascal, Java или Python, не означает, что их не преподают в ВУЗах.

LMA>>Приведу пример: когда я бал первокурсником, то при изучении языка Си, когда рассматривали такую тему как параметры функций, мы изучали не только стеки и рекурсию — куда больше времени ушло на изучение stateless programming и его применении к распараллеливанию.
C>Пока это строится на доброй воли преподавателя, а не на стандартизированной и утвержденной программе, толку от этого не будет в общеобразовательном смысле.
Вы, видимо, не представляете как формируются утвержденные программы: к каждому курсу из министерства приходит список рекомендуемых тем, на основании которых конкретный преподаватель формирует и утверждает у ректора программу курса. Так что в любом случае речь идет о воле преподавателя, ибо преподаватель лучше, чем любой чиновник министерства знает чему учить по его предмету. Право студента — выбирать кто его будет учить реализуется посредсвом выбора ВУЗа при поступлении (или можно перевестись). Так что если Вас учили далеко не Вирт, Кнут или Мейер, так это Вы для себя такое выбрали.

LMA>>А по поводу сортировки пузырьком — так это знать надо, ибо эта простая идея много непростых идей в различных областях породила. Но это уже на темы "Читайте Кнута всю жизнь" и "чем отличается программист от кодера"
C>Ох, ну это опять демагогия. Давайте конкретно: какие именно "непростые идеи" в Вашей голове породило знание конкретно сортировки пузырьком? Внимательно Вас слушаю.
А никто не говорит, что каждая тема, которую изучают в ВУЗе, должна пригодиться каждому. Если Вам лично не пригодилась ни одна из тех фундаментальных тем, которые Вы изучали, то это повод задуматься — а не было ли Вам бы проще, если бы Вы пошли учиться не в ВУЗ, а в ПТУ.

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

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

M_>>>>на пятом. Писали что-то простенькое для паскалеподобного языка с выходом в COM-файл. Лабораторная работа.

I>>>Именно на схемах ? Дай посмотреть эту лабу.
M_>>не, на паскале накидали (см выделенное), насколько помню. Мы тогда плюсов не знали

I>На паскале я тебе сам могу дать. И на с, и на ассемблере.
мне? зачем?
ЗЫ: а на бейсике слабо?

M_>>четвертый курс: фуфло на тему "использование ММХ-инструкций при вычислениях", больше не помню. Ничего интересного вроде не было, только лабы

I>Нахрена это надо ?
а ХЕЗ, чтобы автоматом 4 получить по предмету, на котором всякие БПФы изучали в полный рост

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

ГВ>>Как это связано с тем, что "не нужно много технических специалистов с мат. бекграундом"?

I>В моём понимании мат-бекграунд это определенные специальности. Повтас напрмер в их число не входит.

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

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

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

ГВ>>>Как это связано с тем, что "не нужно много технических специалистов с мат. бекграундом"?

I>>В моём понимании мат-бекграунд это определенные специальности. Повтас напрмер в их число не входит.

ГВ>А... В моём понимании математическая подготовка — это ВМ в объёме не-математической специальности технического вуза. Ну, чтобы улышав, например, слово "матрица" инженер не хлопал глазами.

А такие встречаются?

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

_>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>А... В моём понимании математическая подготовка — это ВМ в объёме не-математической специальности технического вуза. Ну, чтобы улышав, например, слово "матрица" инженер не хлопал глазами.

_>А такие встречаются?

Еще как!
Работал я в институте одном... Так начальник отдела, где я работал (кандидатом физ-мат наук недавно стал), не знал как считать расстояние в 3D пространстве. Не то чтобы придуривался, правда не знал. Бегал спрашивал. И синус у него ступор вызывал. Как щас — не знаю...
Никому не в обиду, но он программирует на C++. Не знал, что такое указатель. Вызывает как-то спросить, почему не компилится у него, объяснить ему ничего не получается, пальцем ткнешь, типа "вот тут звездочку поставь" и зашибись.

Наука!