Конечно, некропост, но я думаю, вы не очень торопитесь, так что вставлю то, что собирался написать в прошлый раз (а потом пост ушёл в черновики).
— Вообще здорово, конечно, что что-то происходит, но мне кажется, акценты немного не так расставлены. Если мы как-то движемся к магистратуре в западном понимании, то основная задача состоит в подготовке студента к научной или нетривиально-инженерной карьере. Мой опыт общения с коллегами показывает, что ситуация в самых разных точках мира примерно одинаковая: после бакалавриата студенты массово уходят искать работу.
В магистратуру идут либо те, кто всерьёз нацелился на научную (либо некую «нестандартную» инженерную) карьеру, либо те, кто ничего пока лучше для себя не придумал, и хочет получить ещё два года на размышления о том, что же ему делать со своей жизнью. Даже если студент сам не рассматривает ситуацию в таком ракурсе, по факту так оно и есть. Собственно, поэтому в мире не так мало стипендиальных программ для магистрантов (кстати, а какова ваша стипендия примерно? выжить на эти деньги реально?) — дальновидные государства привлекают перспективных людей для своей науки и промышленности.
Таким образом, я думаю, что лекции — это в общем-то второстепенная задача, даже если приглашаются специалисты мирового класса. Конечно, очень здорово послушать сильных лекторов (и в этом смысле важнее, наверно, даже не послужной список, а преподавательская харизма… есть где-нибудь рейтинги харизмы?) Однако, в конце концов, книжки можно и самому почитать.
Магистратура не должна быть «более крутым бакалавриатом». Здесь уже пора делать упор не на знания предметов, а на другие навыки. Например:
Активный технический английский (умение не только читать, но и хорошо писать на научно-технические темы). Навыки композиции научного текста (это не только про язык, но и про законы жанра, про структуру; даже если человек не будет учёным, составлять грамотные технические тексты надо уметь). Презентационные навыки. Обязательно научная работа в лаборатории профессора — с тем, чтобы к концу магистратуры хотя бы одна-две научные публикации на английском языке вышли.
Ну вот например, из ваших курсов я довольно поверхностное представление имею о криптографии или о системе Unix. Но я уверен, что при необходимости пару книжек осилю. Но какая книжка научит грамотной технической презентации? Или разделению труда в команде? Или сочинению достойного технического текста? Это можно освоить лишь в соответствующей среде, и магистратура как раз для этого и нужна.
Эта идея совершенно понятна и звучит разумно, но слабо верится, что язык, слепленный по такому принципу, может получить широкое распространение. Как тот же Страуструп писал, все языки делятся на два вида: те, которые все ругают и те, на которых никто не пишет.
В процессе развития языка всегда возникает дилемма: порвать с прошлым и переписать заново, либо сохранять всё в языке. Конечно, в первом случае мы получаем красоту, но никто с таким языком не захочет иметь дела. Даже весьма скромные обновления Python в третьей версии вызвали раскол, до сих пор не преодолённый.
А С++ да, сохраняет все те окаменелости, которые давно пора бы выбросить, но нельзя. Я вот не знаю, если бы на месте Страуструпа решил, что перегрузка операторов нужна, чтобы я делал? Наверно, тоже ввёл бы ссылки. Макроподстановки взяты ещё из C, стало быть, в С++ надо было не делать const вообще или переписать механизм макросов.
Да уж. По поводу шаблонов — не зря Страуструп сокрушался, что в стандарт так и не вошли концепты. Если дождёмся, полегчает. Хотя язык станет ещё монстроуознее.
А «написанный с нуля С++» уже есть — язык D. Вон какой популярный, все на нём только и пишут :)
Да, в этом смысле проблема C++ показательна, потому что Страуструп в «Дизайн и эволюция С++» пишет, что ссылки были введены ради перегрузки операторов. Тут было два пути — либо отказаться перегружать операции, либо отказаться от ссылок. Проблема в том, что «по Вирту» надо было вообще отказаться от нужной фичи из-за того, что она частично пересекается с существующей. Ну или переписать весь язык с нуля, да. В этом смысле С++ похож на человеческие языки: в нём сосуществуют самые разные «пласты» лексики. Некоторые явно архаичны, но с этим ничего не сделаешь.
По поводу молотка — я вот думаю, что дело обстоит как раз наоборот, обобщённое программирование и итерация по коллекции значительно снижают вероятность ошибок. Потому что без обобщённого программирования я должен заново реализовывать библиотечные алгоритмы, а без итерации по коллекции могу перепутать индексы.
А по поводу «набора фич» — в общем-то С++ тоже консервативен. Апдейт стандарта раз 13 лет — разве это часто? А на выходе такая разница с Обероном. А вот С#, конечно, бешеная собака. Я не успеваю версии отслеживать.
Да, конечно, тут можно многое обсудить. Для меня «язык общего назначения» — это, скажем так, второй язык программирования. Если в качестве первого языка я бы предложил изучить что-то простое и полуигрушечное (вроде SmallBasic), то в качестве второго языка это был бы тот самый наш «общеназначенец». И это был бы явно и не SQL, и не MATLAB, и не PHP.
Ну давайте согласимся, что играть в слова незачем: любой полный по Тьюрингу язык годится для чего угодно. Так что и C может «широко применяться», естественно.
А значит, разница состоит исключительно в «удобстве» (в любом понимании этого термина) для программиста. Соответственно, вам кажется, что инструменты, разработанные за последние 40 лет, не особенно ценны. Ну что я могу на это сказать?.. Видимо, в вашей сфере деятельности действительно это не нужно.
Я исхожу из того, что любой инструмент, придуманный за последние 40 лет, призван решать какую-то задачу. А чем больше задач может решать язык, тем шире он применим в реальной жизни, вот и всё.
Оставим пока наследование, потому что второе — это проблема.
Как алгоритмический модуль может импортировать ADT-модуль, если ADT-модуля ещё нет? То есть я вот хочу написать библиотеку алгоритмов, которой могут воспользоваться неизвестные мне люди. Классическое разделение труда.
Да чего уж там, давайте сразу назовём ассемблер.
Понятно, что любой язык программирования полон по Тьюрингу, но наши представления о прекрасном всё-таки прошли некоторую эволюцию с 1973 года.
Вот если бы я увидел код, вопросы бы отпали сами собой.
В частности (опять же, мы теряем время, потому что я вынужден формулировать все вопросы, которые и так бы прояснились при виде кода):
1) Можно ли получить тип на основе нескольких базовых? Это необходимо в моей задаче.
2) Как имея только базовый тип, написать код присваивания объектов производных типов?
3) Как конкретно можно разрешить автору производного типа передать алгоритму сортировки (который ничего не знает о производном типе) функцию сравнения?..
Да, пишут. Но разве я сильно ошибусь, если предположу, что ниша C постепено отходит к задачам, где основная работа как раз и производится с такими массивами?.. Рискну сделать и более сильное утверждение: в 2014 году язык С уже не может считаться языком общего назначения.
Вот в этом и проблема, потому что сначала нам рассказывают про инструменты, «простые как скальпель», которые благодаря своей простоте «предохраняют от ошибок», но потом на практике оказывается, что всё это на самом деле болтовня. Потому что да, чем меньше инструментов, тем меньше способов ошибиться. Но чем проще инструмент, тем хуже он подходит для решения любой отдельно взятой задачи, и в итоге провоцирует совершать идиотские ошибки, просто по невнимательности, да и плодит сущности там, где это не надо. Например, в Паскале если мне надо просто выполнить действие для каждого элемента коллекции, у меня возникает абсолютно избыточная сущность «индексатор i», хотя в моей задаче его нигде не было.
Ну то есть по сути предлагается альтернатива: либо вафельница + тостер, либо сковородка. Да, в первом случае сущности две, но неправильно их применить трудно. А во втором случае сущность одна, но ошибиться можно миллионом способов.
Вот смотрите, я просил десять строк кода, а в результате снова получаю несколько абзацев текста. Давайте код. Я не собираюсь свои критерии трактовать с религиозным рвением. Под сжатостью я понимаю, например, то, что сортировка пузырьком не будет занимать 200 строк. А 10 строк или 20 — не так принципиально. Но если 200 — увольте, у меня нет времени столько печатать сортировку.
Разделение работы меня интересует в контексте «одни пишут алгоритмы, а другие структуры». Вот как это реализуется (поэтому и просил обобщённую сортировку)? Применение в новых проектах — это идеально формализуемый критерий, которому удовлетворяет любая библиотека, такая как стандартные классы .NET или библиотека C++ STL.
Книга Вирта меня в данном случае не устраивает (я её читал), потому что там рассматриваются алгоритмы на примерах базовых типов данных. Например, если вы пойдёте в главу 2.2, то увидите, что сортировка описывается на примере сортировки целых чисел.
Как раз пример книги AD — это, в общем-то фейл уважаемого мэтра доказать свою теорию. Потому что со времён первого издания (1985) в ней по факту очень мало изменились листинги. Как-то вот на месте топчемся. Те же примеры практически в тех же декорациях.
— Вообще здорово, конечно, что что-то происходит, но мне кажется, акценты немного не так расставлены. Если мы как-то движемся к магистратуре в западном понимании, то основная задача состоит в подготовке студента к научной или нетривиально-инженерной карьере. Мой опыт общения с коллегами показывает, что ситуация в самых разных точках мира примерно одинаковая: после бакалавриата студенты массово уходят искать работу.
В магистратуру идут либо те, кто всерьёз нацелился на научную (либо некую «нестандартную» инженерную) карьеру, либо те, кто ничего пока лучше для себя не придумал, и хочет получить ещё два года на размышления о том, что же ему делать со своей жизнью. Даже если студент сам не рассматривает ситуацию в таком ракурсе, по факту так оно и есть. Собственно, поэтому в мире не так мало стипендиальных программ для магистрантов (кстати, а какова ваша стипендия примерно? выжить на эти деньги реально?) — дальновидные государства привлекают перспективных людей для своей науки и промышленности.
Таким образом, я думаю, что лекции — это в общем-то второстепенная задача, даже если приглашаются специалисты мирового класса. Конечно, очень здорово послушать сильных лекторов (и в этом смысле важнее, наверно, даже не послужной список, а преподавательская харизма… есть где-нибудь рейтинги харизмы?) Однако, в конце концов, книжки можно и самому почитать.
Магистратура не должна быть «более крутым бакалавриатом». Здесь уже пора делать упор не на знания предметов, а на другие навыки. Например:
Активный технический английский (умение не только читать, но и хорошо писать на научно-технические темы). Навыки композиции научного текста (это не только про язык, но и про законы жанра, про структуру; даже если человек не будет учёным, составлять грамотные технические тексты надо уметь). Презентационные навыки. Обязательно научная работа в лаборатории профессора — с тем, чтобы к концу магистратуры хотя бы одна-две научные публикации на английском языке вышли.
Ну вот например, из ваших курсов я довольно поверхностное представление имею о криптографии или о системе Unix. Но я уверен, что при необходимости пару книжек осилю. Но какая книжка научит грамотной технической презентации? Или разделению труда в команде? Или сочинению достойного технического текста? Это можно освоить лишь в соответствующей среде, и магистратура как раз для этого и нужна.
Честнее будет сказать, что процесс не идёт, если мы не можем подтвердить обратное.
А разработчикам таких библиотек неплохо бы поразмыслить об этом.
В процессе развития языка всегда возникает дилемма: порвать с прошлым и переписать заново, либо сохранять всё в языке. Конечно, в первом случае мы получаем красоту, но никто с таким языком не захочет иметь дела. Даже весьма скромные обновления Python в третьей версии вызвали раскол, до сих пор не преодолённый.
А С++ да, сохраняет все те окаменелости, которые давно пора бы выбросить, но нельзя. Я вот не знаю, если бы на месте Страуструпа решил, что перегрузка операторов нужна, чтобы я делал? Наверно, тоже ввёл бы ссылки. Макроподстановки взяты ещё из C, стало быть, в С++ надо было не делать const вообще или переписать механизм макросов.
В общем, всё плохо :)
А «написанный с нуля С++» уже есть — язык D. Вон какой популярный, все на нём только и пишут :)
По поводу молотка — я вот думаю, что дело обстоит как раз наоборот, обобщённое программирование и итерация по коллекции значительно снижают вероятность ошибок. Потому что без обобщённого программирования я должен заново реализовывать библиотечные алгоритмы, а без итерации по коллекции могу перепутать индексы.
А по поводу «набора фич» — в общем-то С++ тоже консервативен. Апдейт стандарта раз 13 лет — разве это часто? А на выходе такая разница с Обероном. А вот С#, конечно, бешеная собака. Я не успеваю версии отслеживать.
А значит, разница состоит исключительно в «удобстве» (в любом понимании этого термина) для программиста. Соответственно, вам кажется, что инструменты, разработанные за последние 40 лет, не особенно ценны. Ну что я могу на это сказать?.. Видимо, в вашей сфере деятельности действительно это не нужно.
Я исхожу из того, что любой инструмент, придуманный за последние 40 лет, призван решать какую-то задачу. А чем больше задач может решать язык, тем шире он применим в реальной жизни, вот и всё.
Как алгоритмический модуль может импортировать ADT-модуль, если ADT-модуля ещё нет? То есть я вот хочу написать библиотеку алгоритмов, которой могут воспользоваться неизвестные мне люди. Классическое разделение труда.
Понятно, что любой язык программирования полон по Тьюрингу, но наши представления о прекрасном всё-таки прошли некоторую эволюцию с 1973 года.
В частности (опять же, мы теряем время, потому что я вынужден формулировать все вопросы, которые и так бы прояснились при виде кода):
1) Можно ли получить тип на основе нескольких базовых? Это необходимо в моей задаче.
2) Как имея только базовый тип, написать код присваивания объектов производных типов?
3) Как конкретно можно разрешить автору производного типа передать алгоритму сортировки (который ничего не знает о производном типе) функцию сравнения?..
Ну то есть по сути предлагается альтернатива: либо вафельница + тостер, либо сковородка. Да, в первом случае сущности две, но неправильно их применить трудно. А во втором случае сущность одна, но ошибиться можно миллионом способов.
И да, в Бейсике есть абстрактные типы данных. И из книги Вирта AD я не увидел особой разницы. Многие листинги оттуда прекрасно переносятся на Бейсик.
Разделение работы меня интересует в контексте «одни пишут алгоритмы, а другие структуры». Вот как это реализуется (поэтому и просил обобщённую сортировку)? Применение в новых проектах — это идеально формализуемый критерий, которому удовлетворяет любая библиотека, такая как стандартные классы .NET или библиотека C++ STL.
Книга Вирта меня в данном случае не устраивает (я её читал), потому что там рассматриваются алгоритмы на примерах базовых типов данных. Например, если вы пойдёте в главу 2.2, то увидите, что сортировка описывается на примере сортировки целых чисел.
Как раз пример книги AD — это, в общем-то фейл уважаемого мэтра доказать свою теорию. Потому что со времён первого издания (1985) в ней по факту очень мало изменились листинги. Как-то вот на месте топчемся. Те же примеры практически в тех же декорациях.