Когда я говорил про "не сыграет", то, разумеется, имел в виду "не сыграет на концерте". В остальном согласен. Собственно, я же скорее на стороне "алгоритмистов" в текущей дискуссии :)
Хорошо, пианист разминается гаммами, но не играет их на концертах. Чем разминается программист (или музыкант) — его личное дело. Можно разминаться как раз реализацией алгоритмов. Мы же сейчас говорим о том, что люди делают не ради разминки, а конкретно на работе. Про химиков рассуждать не берусь, но подозреваю, что те, кто занимается разработкой новых техпроцессов — это аналог тех программистов, которые на работе разрабатывают алгоритмы :) То есть явно не средне-стандартный уровень.
Мне кажется, что подойти можно с другой стороны. Нужно ли программисту знать, как решается квадратное уравнение? Может, и не нужно, но как же вы можете этого не знать, если тему проходят в средней школе?
Курс алгоритмов — неизбежный этап в обучении программированию от Австралии до Норвегии. Предположим, я только начинаю учиться программировать. ОК, написали сначала "Hello, world", потом "Hello, %username%", а дальше-то что? Что можно делать с этими буковками? Выучили понятие массива — отлично, а давайте мы теперь найдём в нём требующееся значение. Нашли? А давайте теперь отсортируем по возрастанию, чтобы данные были как в телефонном справочнике. Замечательно. А давайте теперь поищем значение в отсортированном массиве. Ага! Совсем иначе всё выглядит, да?..
Выше вон писали: зачем программировать, если любую программу можно скачать в интернете? Штука в том, что начинающий программист за первый год (если не больше) обучения в принципе не напишет ничего такого, чего нельзя скачать в интернете. Но учиться же на чём-то надо. Аналогично: студент-химик переливает реактивы в пробирках, хотя на производстве никто ничего переливать не будет; студент-токарь вытачивает детали на станке, которые никогда в жизни больше вытачивать не будет; пианист играет гаммы и этюды, которые никогда больше не сыграет, и так везде.
Если человек ухитрился пройти мимо вот этого этапа обучения, я бы в принципе поостерёгся иметь с ним дело. Пёс его знает, что у него в голове. Это по моим понятиям что-то вроде чатбота: да, наверно, он может умело отвечать на разные вопросы в течение десяти минут, но рано или поздно где-то обнаружится фантастическая дыра, которая сделает дальнейшую работу решительно невозможной.
Другой вопрос состоит в том, насколько важно иметь библиотеку алогоритмов в голове. Ведь ясно, что в университете даже за годовалый курс можно едва-едва освоить книгу Кормена (и то, вероятно, не целиком), а уж всякие специализированные вещи явно остаются за бортом. Не знаю. Наверно, не очень важно. Для меня скорее важно на книге Кормена и аналогичных вырастить в голове некую "чуйку", которая поможет найти в литературе готовый алгоритм по описанию задачи.
Ну то есть возникает на практике какая-то задача, и надо сразу понять: это что-то совсем узкое, и надо думать самому, или достаточно широкое, чтобы готовый алгоритм можно было найти? Если можно найти, то как переформулировать задачу, чтобы найти? А как и где искать?.. Ну и так далее.
А какие-то совсем базовые вещи вроде списков, деревьев, хэш-таблиц, алгоритмов сортировки и поиска, обхода графов и т.п., конечно, надо знать. Но это довольно скромный объём знаний, и опять-таки, пройти мимо них в реальной жизни довольно трудно.
Не согласен.
Проблема в том, что пользователь действительно должен, но не может описать свою проблему с достаточным количеством деталей для её решения.
Вы по сути повторяете вот эту старую мысль: проблема именно в сложности языков вроде Java или Pascal или C, а вот если бы пользователю дали писать на условном русском языке или рисовать диаграммы, то сразу бы рожь заколосилась и наступило бы всеобщее счастье.
В реальности (по крайней мере, так я понимаю из литературы и личного опыта) язык — это уже самый распоследний бастион. Человек неподготовленный в принципе мыслит неформально. Он может сказать, например, что ему нужно определить существование заданной карточки вида «Имя Фамилия» в базе данных. А когда даёшь ему то, что требовалось, оказывается, что «Нефёдов» и «Нефедов» нужно рассматривать как одно и то же, или что одинаковы строки «Иван Иванов» и «Иван <четыре пробела> Иванов», или «Иван» и «иван» — короче говоря, масса тонкостей, о которых люди не думают.
И не стоит ожидать, что люди будут аккуратны и строги в постановке задач. Человек, по складу ума склонный а такого рода рассуждениям, без проблем освоит на базовом уровне любой существующий несложный язык программирования.
Даже если я не соглашусь, мне интересно, как вы выводите эту тенденцию. Скажем, в C++ списки существуют со стандарта 1998 года официально, в Java примерно с того же времени. Специализированные инструменты тоже выбрасывались столько, сколько себя помню (ещё в вузе делали курсовики с помощью Silverrun — это CASE средство для разработки баз данных, тогда была особенно модная тема).
Мне кажется, вы неявно предполагаете, что основная проблема пользователя — это выучить SQL-подобный (или любой другой) язык программировния, чтобы генерировать отчёты и тому подобное. Это ведь тоже довольно старая мысль: давайте вместо Pascal/Java/etc. дадим пользователю нечто вроде русского языка или вообще графические блоки, он будет соединять их стрелочками, и наступит всеобщее счастье.
Да вот практика показывает, что основная проблема не в языке, а в программистском способе мышления, которым необходимо овладеть, чтобы рисовать правильные стрелочки, так что всё равно определённый тренинг здесь необходим.
Я уж не говорю о том, что пользователь сам может убраться в офисе и приготовить обед, но смысла в этом мало: у пользователя своя работа, у повара своя, а у программиста своя, и лучше каждому делать то, в чём он лучше всего разбирается, и сотрудничать на всеобщее благо. В конце концов, за фразой «требуется консультация с программистом» не скрывается никакой особенной трагедии: открыл скайп и проконсультировался, всего-то дел.
Нет, я всё-таки о другом. Мне абсолютно всё равно, какое оборудование выполняет мою программу, речь именно о том, что мне как программисту приходится об этом думать.
Если же вы хотите сказать, что декларативное программирование доступно на декларативной машине, императивное — на императивной, а макаронное — на макаронной, что ж, трудно не согласиться, но это же пустой разговор. Других машин в обозримом будущем не предвидится.
По правде говоря, я не вижу тенденции. Как некий способ программирования — конечно, да, а откуда тенденция?
Также я не вижу связи между списками и декларативным подходом. Список — это просто структура данных, такая же как массив или стек. Что в ней декларативного?
Я немного о другом. Декларативность — это когда (как нам пытаются объяснить книжки по декларативному программированию) мы описываем какие-то соотношения между элементами предметной области, а компьютер «сам» выводит ответы на интересующие нас запросы.
В действительности же чистой декларативности нет нигде, потому что две одинаковые (декларативно) программы могут в реальности вести себя совершенно по-разному. Это, собственно, во всех нормальных учебниках сообщается открытым текстом.
Вопрос в том, насколько такая декларативность лучше императивности. Для этого инструмента в принципе не существует «своей» среды, потому что если я просто буду представлять в голове соотношения между символами и записывать их в виде логических формул, ничего хорошего не выйдет: я именно что обязан думать о том, как все эти соотношения будет императивно обрабатывать компьютер. То есть я бы и рад не использовать инструмент в чужой среде, но меня заставляют.
Как-то вы себе противоречите. В комментах к первой части это же ваша реплика: «Пора уже понять, что процедурный подход в программировании — временное явление. Все модные языки — это сдача позиций перед неизбежностью декларативности символьных структур.»
И я как раз соглашусь с новым комментарием — в том и беда, что декларативность в Прологе только декларируется (каламбур-с), а на самом деле приходится всё равно размышлять над тем, как машинка под капотом все эти факты и правила будет обрабатывать. То есть скрытая императивность.
По мне так явное лучше скрытого. Явная императивность лучше скрытой императивности. Явную декларативность будем обсуждать тогда, когда она появится.
А я разве её не люблю? Говорю же, «списки и рекурсия есть везде, хоть в Питоне».
Проблема в том, что в Прологе (и нигде вообще) никакой декларативности нет. Декларативность — это фикция, потому что в действительности на Прологе (и на других якобы декларативных языках) приходится всё равно писать императивные программы, замаскированные под декларации.
Из двух декларативно эквивалентных программ одна может работать моментально, а другая навсегда зацикливаться. Есть пример попроще: регулярные выражения, там ровно та же история происходит.
То есть если бы вся эта механика реально работала, конечно, мы бы жили совсем в другом мире. К сожалению, на практике мы просто имеем некий инструмент неявного императивного программирования, причём достаточно простой внутри. И говорить, что пользование этим инструментом перевернёт наше представление о разработке ПО достаточно опрометчиво.
Да если бы… Чтобы написать ту же злосчастную сортировку списка, надо прыгнуть через обруч задом наперёд, пытаясь вникнуть в логику этого языка (по сути борясь с декларативностью и обеспечивая неявную императивность).
Конечно, есть странные задачи вроде поиска троюродных дядюшек в списке пар детей и братьев — здесь да, получится быстро. Видимо, авторы Пролога считали, что именно такие задачи предстоит решать на практике в основном.
А списки и рекурсия есть везде, хоть в том же упомянутом Питоне. Равно как и отсутствие проблем с динамической памятью.
Очень не хочется вступать в перепалки и обсуждать уже многократно обсуждавшиеся вещи, но…
Любому программисту хорошо бы изучить и Пролог, и Лисп, и Хаскел, и Форт, и много чего ещё нестандартного, хотя бы для того, чтобы потом лучше программировать на «родном» языке.
Однако довольно странно в очередной раз рассказывать о том, какой замечательный язык X, когда про этот язык уже всё давно известно, и все копья давно сломаны. Жизнь богаче и мудрее любых отдельных армий на этом фронте. Если господствуют Java, C++ и C#, значит, в этом имеется какой-то объективный смысл. У Пролога есть свой круг любителей и круг задач, с которым он справляется. Ну и прекрасно, чего же более? Если не хочется совсем погружаться с головой в чужой мир, есть, например, pyDatalog — с его помощью любой может поупражняться в логическом программировании, не вылезая из Питона.
Какие-то вещи в логической парадигме делаются просто и удобно, какие-то с трудом. Ну объясните мне, чем first order logic хорошее средство для описания процессов, идущих во времени: сначала происходит то-то, потом то-то, а потом то-то. Мне кажется, что язык задумывался как реализация разных фантастических планов шестидесятых, но в итоге всё оказалось куда сложнее.
Например, если почитать старые книги по Прологу, там объясняют, что вот ты тут декларируешь условия, цели и допустимые операции, а компьютер потом «думает сам», но потом оказывается, что реальность скромнее. Нельзя сказать, что сортированный список удовлетворяет таким-то критериям, а потом получить на выходе quicksort. Придётся программировать сортировку почти что явно, почти что как на любом императивном языке.
Или вот, у Братко был пример, где обезьяна должна сначала придвинуть ящик к банану, а потом залезть на него и достать банан. И там же объяснялось, что сначала надо пробовать достать банан, а потом уже двигать, иначе система будет бесконечно двигать ящик (я могу ошибаться в деталях, но суть примерно такова). И дальше он как бы оправдывается: мол, да, декларативное программирование и всё такое, но о процедурном смысле думать всё равно надо, но не стоит сокрушаться, потому что уж лучше какой-то декларативный смысл, чем никакого.
То есть мы имеем по сути дырявую абстракцию: где-то работает, где-то нет. Неудивительно, что после таких исходных посылов многие быстро остывают и разочаровываются. А кто готов мириться, спокойно пользуются; за них рад. И не надо говорить сначала о том, какой язык «простой» и «удобный», а потом «элитарный». Тут уж одно из двух: простой и удобный — это Бейсик, а «элитарный» — это нечто из другой оперы.
Я уже написал в другом месте, но мысль важная, поэтому повторю.
За любым языком стоит некая «новая философия», в противном случае непонятно, ради чего данный язык создавался. Неужели тысяч уже существующих языков мало?
Соответственно, профессиональное владение — это, разумеется, владение именно философией и идиоматикой данного языка. Причём именно на уровне письма. Если ей не владеть, то нет никакого смысла заморачиваться с его изучением. Для меня эти вещи самоочевидны, поэтому я их просто пропускал в диалоге.
Допустим, некто с опытом C «знает» также C++, но никогда не использует ключевое слово private, хотя и знает, что оно означает. По моему определению («пользоваться без словаря»), он, конечно, «владеет», но профессиональным владением назвать это никак нельзя.
Человек должен без запинки выдавать код, соответствующий идеологии используемого языка, иначе это просто профанация какая-то.
Спасибо и вам :)
Ну с одной стороны да, тысяча причин, с другой стороны как объективно оценить, стоит оно того или нет? Я ведь по сути поднимаю эту дискуссию, но стопроцентно обоснованных ответов у меня нет.
Если бы были готовые ответы — занимает столько-то времени, сэкономит столько-то. А так одно гадание получается.
По правде говоря, я вот сейчас наступлю на горло собственной песне, но вот эти цифры «800 часов» мне самому кажутся слишком оптимистичными. Посмотрите, сколько лет мы учим родной язык в школе, и всё равно когда дело доходит до сочинения даже простеньких текстов, у людей уже возникают проблемы.
Сам я имел опыт изучения финского языка на групповых курсах в похожем интенсивном режиме: 4 часа в день плюс домашние задания пять дней в неделю. Это было очень утомительно, и по факту (это уже не личный опыт, а более-менее объективная статистика) считалось хорошим результатом за три семестра человека натаскать на средний уровень государственного экзамена (а это вовсе не уровень C2, а гораздо слабее).
Впрочем, мы и в представлении о компьютерных языках расходимся: «Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию» — ну и какой смысл тогда в изучении нового языка? Это же получается по старому выражению о том, что программу в стиле Фортрана можно написать на любом языке. Ясное дело, если вы учите старый язык в новой обложке, и трёх месяцев хватит. Суть же в том, чтобы на спинномозговом уровне освоить новый принцип написания программ, а пока он не освоен, то смысла в этом образовании мало — работайте тогда со старым языком, всё равно удобнее.
Я думал, мне не придётся пояснять, что программист — это не тот, кто без проблем читает код, но и тот, кто пишет. Обычному носителю языка редко приходится сочинять даже на родном языке более-менее внятные тексты. А программисту приходится, что подразумевает активное владение, а не пассивное, что требует совсем иных усилий.
Если требуется только читать и комментировать код — да какие проблемы, я так с десяток языков знаю весьма неплохо. Но на профессиональном активном уровне всё куда скромнее.
К сожалению, ваши выкладки относительно естественного языка уже неверны: помимо активного запаса вам абсолютно необходим пассивный запас, который, по крайней мере, на порядок выше. Вряд ли вы активно используете слова вроде гнедая или форзац, однако представляете себе значения этих слов. Кроме того, помимо слов важны сочетания: важно понимать, что «морская свинка» и «свинка» — это совершенно разные вещи, никак не связанные между собой, а количество сочетаний уж совсем несравнимо с количеством слов. Таким же образом абсолютно неверно сводить изучение языка к изучению словаря.
Кстати, для естественных языков подобные выкладки имеются. Например, чтобы изучить английский на уровне C2 (а это по сути и есть профессиональное использование), потребуется 700-800 часов обучения с учителем, можете попробовать прикинуть, сколько лет жизни это в реалистичных условиях (ну и понятно, что 16 часов в день учиться бессмысленно, организм столько не вынесет).
Так что если бы я и в самом деле взялся за выкладки, то подошёл бы с другого конца: берём приличный учебник по языку (из списка рекомендованных в каком-нибудь достойном вузе), заставляем человека выполнить хотя бы 3/4 домашних заданий, затем написать хотя бы один полноценный проект (не слишком большой, но полноценный). Вот это мне кажется больше похоже на правду.
Мне кажется, что подойти можно с другой стороны. Нужно ли программисту знать, как решается квадратное уравнение? Может, и не нужно, но как же вы можете этого не знать, если тему проходят в средней школе?
Курс алгоритмов — неизбежный этап в обучении программированию от Австралии до Норвегии. Предположим, я только начинаю учиться программировать. ОК, написали сначала "Hello, world", потом "Hello, %username%", а дальше-то что? Что можно делать с этими буковками? Выучили понятие массива — отлично, а давайте мы теперь найдём в нём требующееся значение. Нашли? А давайте теперь отсортируем по возрастанию, чтобы данные были как в телефонном справочнике. Замечательно. А давайте теперь поищем значение в отсортированном массиве. Ага! Совсем иначе всё выглядит, да?..
Выше вон писали: зачем программировать, если любую программу можно скачать в интернете? Штука в том, что начинающий программист за первый год (если не больше) обучения в принципе не напишет ничего такого, чего нельзя скачать в интернете. Но учиться же на чём-то надо. Аналогично: студент-химик переливает реактивы в пробирках, хотя на производстве никто ничего переливать не будет; студент-токарь вытачивает детали на станке, которые никогда в жизни больше вытачивать не будет; пианист играет гаммы и этюды, которые никогда больше не сыграет, и так везде.
Если человек ухитрился пройти мимо вот этого этапа обучения, я бы в принципе поостерёгся иметь с ним дело. Пёс его знает, что у него в голове. Это по моим понятиям что-то вроде чатбота: да, наверно, он может умело отвечать на разные вопросы в течение десяти минут, но рано или поздно где-то обнаружится фантастическая дыра, которая сделает дальнейшую работу решительно невозможной.
Другой вопрос состоит в том, насколько важно иметь библиотеку алогоритмов в голове. Ведь ясно, что в университете даже за годовалый курс можно едва-едва освоить книгу Кормена (и то, вероятно, не целиком), а уж всякие специализированные вещи явно остаются за бортом. Не знаю. Наверно, не очень важно. Для меня скорее важно на книге Кормена и аналогичных вырастить в голове некую "чуйку", которая поможет найти в литературе готовый алгоритм по описанию задачи.
Ну то есть возникает на практике какая-то задача, и надо сразу понять: это что-то совсем узкое, и надо думать самому, или достаточно широкое, чтобы готовый алгоритм можно было найти? Если можно найти, то как переформулировать задачу, чтобы найти? А как и где искать?.. Ну и так далее.
А какие-то совсем базовые вещи вроде списков, деревьев, хэш-таблиц, алгоритмов сортировки и поиска, обхода графов и т.п., конечно, надо знать. Но это довольно скромный объём знаний, и опять-таки, пройти мимо них в реальной жизни довольно трудно.
Проблема в том, что пользователь действительно должен, но не может описать свою проблему с достаточным количеством деталей для её решения.
Вы по сути повторяете вот эту старую мысль: проблема именно в сложности языков вроде Java или Pascal или C, а вот если бы пользователю дали писать на условном русском языке или рисовать диаграммы, то сразу бы рожь заколосилась и наступило бы всеобщее счастье.
В реальности (по крайней мере, так я понимаю из литературы и личного опыта) язык — это уже самый распоследний бастион. Человек неподготовленный в принципе мыслит неформально. Он может сказать, например, что ему нужно определить существование заданной карточки вида «Имя Фамилия» в базе данных. А когда даёшь ему то, что требовалось, оказывается, что «Нефёдов» и «Нефедов» нужно рассматривать как одно и то же, или что одинаковы строки «Иван Иванов» и «Иван <четыре пробела> Иванов», или «Иван» и «иван» — короче говоря, масса тонкостей, о которых люди не думают.
И не стоит ожидать, что люди будут аккуратны и строги в постановке задач. Человек, по складу ума склонный а такого рода рассуждениям, без проблем освоит на базовом уровне любой существующий несложный язык программирования.
Да вот практика показывает, что основная проблема не в языке, а в программистском способе мышления, которым необходимо овладеть, чтобы рисовать правильные стрелочки, так что всё равно определённый тренинг здесь необходим.
Я уж не говорю о том, что пользователь сам может убраться в офисе и приготовить обед, но смысла в этом мало: у пользователя своя работа, у повара своя, а у программиста своя, и лучше каждому делать то, в чём он лучше всего разбирается, и сотрудничать на всеобщее благо. В конце концов, за фразой «требуется консультация с программистом» не скрывается никакой особенной трагедии: открыл скайп и проконсультировался, всего-то дел.
Если же вы хотите сказать, что декларативное программирование доступно на декларативной машине, императивное — на императивной, а макаронное — на макаронной, что ж, трудно не согласиться, но это же пустой разговор. Других машин в обозримом будущем не предвидится.
Также я не вижу связи между списками и декларативным подходом. Список — это просто структура данных, такая же как массив или стек. Что в ней декларативного?
В действительности же чистой декларативности нет нигде, потому что две одинаковые (декларативно) программы могут в реальности вести себя совершенно по-разному. Это, собственно, во всех нормальных учебниках сообщается открытым текстом.
Вопрос в том, насколько такая декларативность лучше императивности. Для этого инструмента в принципе не существует «своей» среды, потому что если я просто буду представлять в голове соотношения между символами и записывать их в виде логических формул, ничего хорошего не выйдет: я именно что обязан думать о том, как все эти соотношения будет императивно обрабатывать компьютер. То есть я бы и рад не использовать инструмент в чужой среде, но меня заставляют.
И я как раз соглашусь с новым комментарием — в том и беда, что декларативность в Прологе только декларируется (каламбур-с), а на самом деле приходится всё равно размышлять над тем, как машинка под капотом все эти факты и правила будет обрабатывать. То есть скрытая императивность.
По мне так явное лучше скрытого. Явная императивность лучше скрытой императивности. Явную декларативность будем обсуждать тогда, когда она появится.
Проблема в том, что в Прологе (и нигде вообще) никакой декларативности нет. Декларативность — это фикция, потому что в действительности на Прологе (и на других якобы декларативных языках) приходится всё равно писать императивные программы, замаскированные под декларации.
Из двух декларативно эквивалентных программ одна может работать моментально, а другая навсегда зацикливаться. Есть пример попроще: регулярные выражения, там ровно та же история происходит.
То есть если бы вся эта механика реально работала, конечно, мы бы жили совсем в другом мире. К сожалению, на практике мы просто имеем некий инструмент неявного императивного программирования, причём достаточно простой внутри. И говорить, что пользование этим инструментом перевернёт наше представление о разработке ПО достаточно опрометчиво.
Конечно, есть странные задачи вроде поиска троюродных дядюшек в списке пар детей и братьев — здесь да, получится быстро. Видимо, авторы Пролога считали, что именно такие задачи предстоит решать на практике в основном.
А списки и рекурсия есть везде, хоть в том же упомянутом Питоне. Равно как и отсутствие проблем с динамической памятью.
Любому программисту хорошо бы изучить и Пролог, и Лисп, и Хаскел, и Форт, и много чего ещё нестандартного, хотя бы для того, чтобы потом лучше программировать на «родном» языке.
Однако довольно странно в очередной раз рассказывать о том, какой замечательный язык X, когда про этот язык уже всё давно известно, и все копья давно сломаны. Жизнь богаче и мудрее любых отдельных армий на этом фронте. Если господствуют Java, C++ и C#, значит, в этом имеется какой-то объективный смысл. У Пролога есть свой круг любителей и круг задач, с которым он справляется. Ну и прекрасно, чего же более? Если не хочется совсем погружаться с головой в чужой мир, есть, например, pyDatalog — с его помощью любой может поупражняться в логическом программировании, не вылезая из Питона.
Какие-то вещи в логической парадигме делаются просто и удобно, какие-то с трудом. Ну объясните мне, чем first order logic хорошее средство для описания процессов, идущих во времени: сначала происходит то-то, потом то-то, а потом то-то. Мне кажется, что язык задумывался как реализация разных фантастических планов шестидесятых, но в итоге всё оказалось куда сложнее.
Например, если почитать старые книги по Прологу, там объясняют, что вот ты тут декларируешь условия, цели и допустимые операции, а компьютер потом «думает сам», но потом оказывается, что реальность скромнее. Нельзя сказать, что сортированный список удовлетворяет таким-то критериям, а потом получить на выходе quicksort. Придётся программировать сортировку почти что явно, почти что как на любом императивном языке.
Или вот, у Братко был пример, где обезьяна должна сначала придвинуть ящик к банану, а потом залезть на него и достать банан. И там же объяснялось, что сначала надо пробовать достать банан, а потом уже двигать, иначе система будет бесконечно двигать ящик (я могу ошибаться в деталях, но суть примерно такова). И дальше он как бы оправдывается: мол, да, декларативное программирование и всё такое, но о процедурном смысле думать всё равно надо, но не стоит сокрушаться, потому что уж лучше какой-то декларативный смысл, чем никакого.
То есть мы имеем по сути дырявую абстракцию: где-то работает, где-то нет. Неудивительно, что после таких исходных посылов многие быстро остывают и разочаровываются. А кто готов мириться, спокойно пользуются; за них рад. И не надо говорить сначала о том, какой язык «простой» и «удобный», а потом «элитарный». Тут уж одно из двух: простой и удобный — это Бейсик, а «элитарный» — это нечто из другой оперы.
Я уже написал в другом месте, но мысль важная, поэтому повторю.
За любым языком стоит некая «новая философия», в противном случае непонятно, ради чего данный язык создавался. Неужели тысяч уже существующих языков мало?
Соответственно, профессиональное владение — это, разумеется, владение именно философией и идиоматикой данного языка. Причём именно на уровне письма. Если ей не владеть, то нет никакого смысла заморачиваться с его изучением. Для меня эти вещи самоочевидны, поэтому я их просто пропускал в диалоге.
Допустим, некто с опытом C «знает» также C++, но никогда не использует ключевое слово private, хотя и знает, что оно означает. По моему определению («пользоваться без словаря»), он, конечно, «владеет», но профессиональным владением назвать это никак нельзя.
Человек должен без запинки выдавать код, соответствующий идеологии используемого языка, иначе это просто профанация какая-то.
Ну с одной стороны да, тысяча причин, с другой стороны как объективно оценить, стоит оно того или нет? Я ведь по сути поднимаю эту дискуссию, но стопроцентно обоснованных ответов у меня нет.
Если бы были готовые ответы — занимает столько-то времени, сэкономит столько-то. А так одно гадание получается.
Сам я имел опыт изучения финского языка на групповых курсах в похожем интенсивном режиме: 4 часа в день плюс домашние задания пять дней в неделю. Это было очень утомительно, и по факту (это уже не личный опыт, а более-менее объективная статистика) считалось хорошим результатом за три семестра человека натаскать на средний уровень государственного экзамена (а это вовсе не уровень C2, а гораздо слабее).
Впрочем, мы и в представлении о компьютерных языках расходимся: «Ему просто нужно новый синтаксис выучить и набор слов, чтобы не лазать в документацию» — ну и какой смысл тогда в изучении нового языка? Это же получается по старому выражению о том, что программу в стиле Фортрана можно написать на любом языке. Ясное дело, если вы учите старый язык в новой обложке, и трёх месяцев хватит. Суть же в том, чтобы на спинномозговом уровне освоить новый принцип написания программ, а пока он не освоен, то смысла в этом образовании мало — работайте тогда со старым языком, всё равно удобнее.
Если требуется только читать и комментировать код — да какие проблемы, я так с десяток языков знаю весьма неплохо. Но на профессиональном активном уровне всё куда скромнее.
Кстати, для естественных языков подобные выкладки имеются. Например, чтобы изучить английский на уровне C2 (а это по сути и есть профессиональное использование), потребуется 700-800 часов обучения с учителем, можете попробовать прикинуть, сколько лет жизни это в реалистичных условиях (ну и понятно, что 16 часов в день учиться бессмысленно, организм столько не вынесет).
Так что если бы я и в самом деле взялся за выкладки, то подошёл бы с другого конца: берём приличный учебник по языку (из списка рекомендованных в каком-нибудь достойном вузе), заставляем человека выполнить хотя бы 3/4 домашних заданий, затем написать хотя бы один полноценный проект (не слишком большой, но полноценный). Вот это мне кажется больше похоже на правду.