AbstractionХорошо бы ссылку на конкретное мнение, ...
К тому же, Вы учите не языку, а ООП, иллюстрируя свои построения некоторым конкретным языком; большая часть сведений остаётся применима и при переходе от одного языка к другому, ....

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


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

Проблема в том, что 90% любой группы - это те, кто хочет особо ничего не делая получить оценку. Им вроде бы хочется стать программистами, но нет огня, они не сидят допоздна за кодом, стремясь сделать свой проект, не просят советов и т.п. Делают лабы с буквальной точностью, и если в методичке у меня опечатка, и любому ясно, что вот тут вот так делать - бред, нет же, они так сделают, "ибо написано".
Вопрос: стоит мне тратить силы и разжевывать материал так, чтобы у них что-то осталось в голове? Они все равно не станут программистами. При этом 10% более шарящих чуваков будут скучать. Не лучше ли подумать о тех, кому знания и опыт действительно нужны?


asws
Для начала независимо от языка растолкуйте/повторите студентам основные практические вещи, необходимые для небыдла:
- практически любая ООП - программа является приложением ОС;
- обработка сообщений ОС;
- понятие оконной функции;
и т.д.

Странный подход) Зачем при погружении в ООП знать про оконные функции? Это же GUI-специфика, первые лабы вообще под консоль. ООП - это парадигма, глобальный подход, а оконные функции - частная техническая деталь. Это в итоге нужно знать, но стоит ли с этого прям начинать? Тогда нужно будет рассказать про IDE, процесс компиляции, виды языков, стек и кучу,...


an-24-111
что за странный выбор. А вот java не подходит под Ваши критерии что-ли? Нет привязки к MS. Современный. Работы завались.

Тут все банально: я не знаю Java. Преподаю то, с чем работал не один год (C++\C#). С другой стороны, лучший способ что-то выучить - начать это рассказывать другим. Но качество, наверное, будет слишком низким.


Проясним ситуац
Ты застрял в 90-х годах. Сейчас декстоп приложения нафиг никому не впились, кроме коробочных многотиражек - все пишут или
мобильные, или веб, или гамнокодят на Java/C#/1C. Под декстоп - разве на VB и Delphi, и то, это совсем запущенные случаи.

У меня нет статистики, каких проектов сколько сейчас ведется, только личный опыт - есть, и еще долго будут проекты под десктоп. Да, лет через 10 и фотошоп будет web-приложением, но пока есть очень много legacy-кода.
Не вижу ничего плохого в разработке под десктоп на том же C# - очень много корпоративного софта, всяких утилит и т.п.

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

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


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

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

рубистТолько не нужно давать студентам MFC или QT или еще что-то такое. Об этом можно раскозать обзорно, просто что это есть.
Давать нужно классический C++ и STL ... можно и boost если успеете.

Без GUI тут никак. Им диплом нужно писать - не под консоль же. В 95% вакансий им придется иметь дело с GUI-приложениями.

Проясним ситуац
Говоря проще - если ты предпочитаешь C++ (а не C), то ты 99.9% но - говнокодер.

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

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

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

k0rvinА почему нет? Server-side какой-нибудь, тот же веб. Или библиотека обработки чего-нибудь (изображений, звука и т.п.), где важен алгоритм, а ГУЙ так, можно на коленке за пол дня на каком-нибудь tcl/tk написать или вообще не нужен.

Плюсовик, не знакомый с MFC или Qt, равно как .net-чик, не имеющий опыта работы с WinForms\WPF - это как-то странно) Т.е. хотя бы ознакомиться не помешает.