Как я студентам язык D преподавал

    Два года назад я начал читать курс “Язык программирования Ди” в самом настоящем университете, провёл в общей сложности 40 лекций, примерно столько же практических занятий даже дважды принял экзамен, один раз удалённо. Как так случилось, кому вообще может быть нужен D, и как ученик превосходит учителя, под катом.

    Всё началось чуть два с половиной года назад. Тогда в почтовой рассылке D появился необычный вопрос: А не хочет ли кто-нибудь поучить студентов в Москве? Но прежде, чем можно будет продолжить нужно раскрыть несколько моментов.

    Что такое D?

    Ответ требует лекции на полтора часа. Но если коротко, то это C++ сделанный правильно. Статьи про него есть на хабре, но уходить в подробности не вижу смысла. Он гораздо удобнее и приятнее для программиста, предлагает более высокую продуктивность при той же производительности. Убийца C++, если хотите, только при этом не rust.

    Зачем он студентам?

    Вакансий на D мало. И я говорю на первой лекции, что скорее всего в реальной работе практические навыки не пригодятся. Но это не делает его изучение бесполезным. Во-первых, на нём проще учиться программировать, чем на C или C++. Это важно, потому что даже после курса программирования на C и ООП на C++ многие вообще не умеют программировать. Во-вторых, разнообразие это хорошо, чем шире кругозор, тем лучше код. Ну и самое важное, D - будущее C++ и не только. На нём обкатывались многие новшества C++, почти все возможности C++11/17/20 уже были в  D. И он всё ещё куда прогрессивнее и богаче плюсов. Мне знакомство с D позволило улучшить код на C++, а также значительно ускорило изучение Python, а точнее его итераторов.

    Кто я и зачем он мне?

    Проще всего сказать, что я C++ программист, по крайней мере по основной профессиональной деятельности. Я никогда ничего не преподавал и, честно говоря, даже на основной работе не очень-то участвую в менторстве над джунами.  С момента окончания магистратуры нижегородского ВМК 6 лет назад к академической среде вообще не имею никакого отношения. Первое время в университете меня посещали мысли о том, чтобы учить школьников, но как я сейчас понимаю, это просто было некоторое стремление к ”справедливости”. Ведь в школе всё неправильно, а в универе всё круто и надо применить универские подходы в школе, и тогда всё получится. Наивно, конечно, но весь первый семестр меня не покидала мысль “Если бы мне объяснили это так раньше”. Я ощутил, что за месяц в университете получаю знаний больше, чем в школе за год, и это круто. Желание пойти работать в школу у меня пропало после получения первой зарплаты программиста, но некоторая память о стремлении осталась. 

    Программированием на D я тоже заинтересовался в универе. После C++ он казался просто идеальным. Можно писать такой же быстрый код, но без всех этих атавизмов. В итоге софт для диплома я написал на D и мне понравилось. По скорости выполнения получилось лучше, чем у предыдущей C++ версии, а по простоте и объёму кода вдвое лучше. Скорость удалось выжать благодаря тому, что чуть более сложные и эффективные алгоритмы банально проще реализовывать, а на C++ лениво, да и сроки у студентов всегда горят. 

    Так что с тех пор я интересовался D и старался писать на нём свои домашние поделки. Хотелось как-то помочь сообществу этого языка, но писать нужные библиотеки у меня не получалось, да и как-то в целом на open source не хватает мотивации.

    3 месяца до начала

    Автором исходного предложения был Дмитрий Ольшанский, довольно известный в D’ишном  сообществе человек, автор библиотеки регулярных выражений D и не только. Я написал ему, что мне интересно было бы попробовать, и стал ждать. Самостоятельным преподавателем я себя не видел и рассчитывал, что буду помогать ну или вести практические занятия по готовому плану. И в начале всё так и выглядело: лектором вызвался другой довольно известный в сообществе человек - Rikki Cattermole. Он собирался удалённо читать лекции по скайпу, а от меня требовалось помогать на месте. Примерно в этот же момент выяснилось, что ВУЗ, где всё будет происходить - РГГУ, Российский Государственный Гуманитарный Университет. Да, там есть технические факультеты и да, они действительно программируют. В этом я убедился, просмотрев учебную программу. D добавляли в программу третьего курса, а на первых двух у них был C, C++, Prolog, кажется даже Lisp (многовато, но почему и нет). По математике программа тоже выглядела серьёзно (да, я из тех, кто считает математику важной для программистов). Так что с самого начала я взял за ориентир свои собственные воспоминания об учёбе и уровне навыков на третьем курсе. 

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

    Неспешно мы начали готовить программу, хотя в этом “мы” я почти отсутствовал. А зря. 

    1 месяц до начала

    Выясняется что из-за какого-то, чуть ли не личного, конфликта с Дмитрием Рикки отказывается продолжать и покидает нас. Для меня это было неожиданно, но ещё же вагон времени? Тогда же с радаров начинает пропадать Дмитрий.

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

    Бюрократия

    Тут должны были описываться страшные истории, как бедный программист преодолевал ужасные бюрократические преграды. Сходив первый раз подписать договор, я даже начал всем рассказывать, как же там много бумажек. Когда понадобилось оформить карту МИР для зарплаты, "ржали всем офисом". Но на самом деле, на этом всё. Следующей бюрократической задачей было составление рабочей программы (это такой официальный документ, содержащий учебную программу и материалы). Там действительно куча формальностей, но мне помогли, показав программу очень похожего курса. Ну, а наполнение программы это уже вполне реальная и важная вещь. Так что с точки зрения бумажек и формальностей всё было гораздо лучше, чем я ожидал. Спасибо за это преподавателям и работникам кафедры. Договор был сроком на год, в этом году я смог его перезаключить, появившись один раз, оставив на столе одну бумажку, и намалевав автограф ещё на двух. Первый раз было сложнее, но сейчас всё очень просто и быстро.

    Первое занятие

    Расписание сложилось так, что первым занятием был семинар (он же лаба, она же практика), а не лекция. Это только формально так, потому что на весь поток одна группа, всего 14 человек, и нет фактической разницы, когда что делать. Позже расписание немного поправили и у меня было 2 пары подряд и я сам решал, что есть лекция, а что практика. Сразу сложился график: на первой паре я рассказываю что-то и отвечаю на общие вопросы (лекция), на второй студенты программируют и задают практические вопросы.

    К первой паре я подготовил довольно короткий обзор языка, сконцентрировался на базовом описании “на что это похоже”, показал синтаксис, дал компилятор и несколько очень простых задач. Было решение квадратного уравнение, подсчёт площади треугольника и подобные задачи, которые по простому вводу предлагали простой вывод. Идея была в том, чтобы быстро погрузить студентов в тему и сразу дать что-то сделать. План удался и к концу первого занятия многие совладали с консольным компилятором, написали в блокноте код, решив по несколько задач.

    Консоль и блокнот

    Думаю, найдётся немало людей, которые на предыдущем предложении возмутились по поводу консоли и блокнота. Что, даже IDE нет? Есть, но в первом семестре я оставил это на откуп желающим. Причиной этому был собственный опыт изучения программирования в целом и C++ в частности. Понимание того, как вообще работает компилятор, и как потом из нескольких файлов линковать проект, критически необходимо для понимания языка в целом. Такие понятия как объявление (declaration) и определение (definition) в C  просто не имеют смысла без понимания процесса сборки. Да, в D подобных тонкостей меньше, нет заголовочных файлов, но всё же хотелось учить программированию на D, а не в конкретной IDE. Да и без хедеров раздельная компиляция никуда не делась и с консольным компилятором понять принцип работы import проще, чем через “интуитивно понятный интерфейс”. Плюс, базовый синтаксис запоминается лучше, если автоподстановка не пишет код вместо тебя. 

    Развитие курса

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

    Новая программа

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

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

    Задача

    Возможно, многие видели видео о проблеме числа 10958. Суть в том, что нужно расставить знаки и скобки между цифрами 1 2 3 4 5 6 7 8 9, чтобы полученное выражение было равно 10958. Все остальные числа до 11000 раскладываются, а под это никто ничего не нашёл. Строгого доказательства отсутствия разложения тоже нет, поэтому это называют проблемой. Я предложил студентам написать программу, которая прямым перебором будет искать разложение. То есть переберёт все возможные расстановки знаков и скобок. Вычисления в простых double, без длинной арифметики, поэтому это совсем не доказательство, зато проще. Мне задача казалась хорошей по разным причинам. Во-первых, я написал решение, аналог которого хотел видеть от студентов, примерно за 5 часов или 2 вечера. С поправкой на студенческий уровень объём работ выглядит подходящим для семестрового проекта. Во-вторых, задача не решается совсем в лоб. Прямой перебор требует слишком много времени, значит нужно правильно отсечь одинаковые выражения ещё на этапе построения перебора. То есть нужно сначала подумать, оценить свои действия, и только потом программировать. Ну и в-третьих, мне задача казалась увлекательной и даже захватывающей. И вот в этом я не мог ошибиться сильнее. Большинству подобная математика оказалась не то что неинтересна, они вообще не поняли в чём тут проблема и зачем нужно это 10958. Заинтересовать не получилось.

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

    Второй семестр

    Курс рассчитан на год, поэтому у меня была возможность исправиться. Для второго семестра я старался подобрать максимально интерактивную и практическую задачу. Поэтому предложил студентам написать игру. По плану шли сети и интернет, поэтому игра была нужна многопользовательская. Вспомнилось, как студентами мы играли в “крестики-нолики на всё поле” на скучных лекциях. По умному эта игра называется гомоку.  Два игрока могут играть по сети, а реализация логики самой игры не так сложна. Я надеялся заинтересовать студентов игрой, что они попробуют поиграть друг с другом на бумаге, вовлекаясь в предметную область.

    Не знаю, играли ли они на самом деле, но всё же эта задача пошла гораздо лучше предыдущей. Однако, успехом результат назвать всё равно сложно.

    Я очень хотел показать удобное асинхронное программирование на корутинах (в D они называются Fiber), как всё удобно в фреймвёрке vibe.d, и как легко подключаются сторонние библиотеки через менеджер dub. Ошибка номер один - не надо продавать корутины тем, кто ещё не понял проблемы callback hell. Ошибка номер два - не проверять оборудование и требования фреймвёрков. 

    Сложности откуда не ждали

    Никогда бы до этого не подумал, что однопоточная компиляция может упереться в объём оперативной памяти. А она может, потому что на компьютерах в университете было по 2 гигабайта RAM, а на некоторых нетбуках студентов встречалось и по одному. Простенькие программки собираются превосходно даже на таких слабых машинках, всё же D не C++, он значительно быстрее компилируется. Но вот большой фреймвёрк для своей сборки потребовал много памяти. И вот представьте, я только что рассказал на лекции, как всё легко и просто делается, а у большинства даже hello world с сетью не собирается. В свою защиту скажу, что я заранее проверял, что всё будет работать, установив себе нужную версию windows 7 в виртуалку с 2 гигабайтами памяти. На ней проверил работу дополнительных ключей компиляции для снижения потребления памяти. То есть теоретически я был готов. Но новая библиотека + новая система сборки + флаги компиляции это слишком много для одного раза, мозг игнорирует лишнее. Поэтому даже при том, что я показал, как на слабых компьютерах собирать программу, пришлось индивидуально каждому подходить и объяснять, почему привычный способ компиляции не работает. А тем, у кого всего один гигабайт, я в вообще сразу помочь не смог. 

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

    Итоги года 

    К сожалению я потребовал слишком много для одного семестра, поэтому хоть какой-то ИИ был всего у одной студентки. Зато, по её словам, она очень радовалась, когда он сделал первый осмысленный ход. Ещё одна студентка весь год говорила, что программирование это вообще не её и она не понимает. В конце года она сама написала и клиент и сервер. Значит всё было  не зря.

    Попытка номер два

    Всё написанное выше происходило в учебном году 18/19. Звёзды сложились, и на следующий учебный год я продолжил. Новые студенты, новые возможности, новая программа. На этот раз я был готов гораздо лучше. Уже были материалы для большинства лекций, не пришлось всё перекраивать на ходу, да и за лето была возможность сделать работу над ошибками.

    Я сразу убрал задачу 10958 за скучность. Вместо этого растянул игру гомоку почти на оба семестра. Почти, потому что первый семестр начинался с простой задачи на ООП, где требуется реализовать классы геометрических фигур с кастомизацией их вывода на экран. Это следующий шаг после “hello world”, чтобы все освоились с инструментарием, а я понял уровень студентов. Думаю, что ни для кого не секрет, что уровень очень разный. Кто-то уже работает программистом и ходит на курс только ради интереса, а кто-то испытывает проблемы с переменными и циклами. Ещё в первый год я для себя решил, что я делаю курс не для всех, а для тех, кому интересно и хорошо получается. Но всё же совсем забрасывать остальных тоже неправильно, поэтому нужны задачи подходящего уровня для всех.

    Для упрощения старта работы с сетью я поднял свой сервер с эталонной реализацией, к которому можно было подключиться и играть хоть через telnet. Дополнительное время и объяснения сказались на продуктивности очень позитивно. Многие добрались до сверхзадачи, и в  конце получилось устроить небольшой конкурс между ИИ. Их всё ещё легко обыгрывает человек, но это большой прогресс по сравнению с предыдущим годом.

    Приятная неожиданность

    Интересным прецедентом второго года был другой конкурс. В первом семестре я предлагал сыграть в кодгольф. Простая задача, которую нужно решить минимальной программой. Чтобы добавить мотивации, я сказал, что лучшие результаты в группе освобождаются от написания отчёта по семестровой работе. А если вдруг кто-то побьет моё решение, то зачёт автоматом. Самонадеянно, но я был уверен, что никто не побьет, ведь я это решение очень долго оттачивал. Через неделю слегка ошарашенный, с трудом подбирая слова, потому что меня побили. И нет, я не отказался от своих слов, я поставил этот зачёт, но как только получил ведомость. А всё потому, что я за год отстал от последних изменений в компиляторе, и некоторые запрещённые ранее вещи стали разрешены. Что интересно, я смог улучшить предложенное решение, сократив ещё на 4 символа. Я очень боялся, что автомат почти в середине семестра отобьёт желание ходить на пары, но к счастью оказался не прав. 

    Назад в настоящее

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

    Нужно рушить стену в личном общении. Чем более доверительные отношения, тем лучше идёт процесс. Сложнее всего с теми, кто боится преподавателя даже когда всё получается. Нужно искать контакт и комфортную социальную дистанцию. Ничего конкретного пока не придумал, всё решим в частном порядке.

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

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

    Коронавирус

    Нельзя не упомянуть, как пандемия сказалась на образовании. Весной все занятия были перенесены в онлайн. Читать лекции удалённо очень удобно, я действительно считаю, что это хорошо работает. Можно договориться об удобном времени проведения и не нужно заботиться о поиске свободной аудитории. Особенно хорошо, что вопросы можно задавать голосом - это аналог поднятой руки в оффлайне, а можно написать в чат. Такие вопросы не сбивают, но при этом на них можно своевременно реагировать. А вот практику вести у меня не получилось. Когда студенты сидят в аудитории они хоть что-то делают, ведь проще вообще не приходить, если ничего делать не собираешься. Когда всё удалённо они всегда “не приходят”. То есть не получается это сессии программирования с оперативной помощью от преподавателя. Я пробовал решить это предложением писать вопросы в любое время, а не во время пар, надеясь, что смогу помочь тогда, когда они реально пишут код. Но нет, это сработало только для 2-3 человек. Остальным помочь не смог. 

    Сейчас пока можно учиться очно, пусть и с ограничениями. Пока на обязательную удалёнку отправили только преподавателей из группы риска (65+ и их не мало). Надеюсь, что ситуация останется под контролем и можно будет проводить занятия очно.

    Спасибо, что дочитали!

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 67

      +2

      Это вы еще в шоколаде. Мне пришлось вначале за свои деньги (правда заработанные в универе) покупать платы для лаб, а потом за счет моей конторы в которой я работаю. Зато теперь каждый год — договор о безвозмездной передаче новых плат и там всякой обвески делаем для универа.
      Зато мой курс, самый оборудованный — платы раздал на руки студентам, и поэтому удаленно точно также, как и не удаленно, все транслирую им через университетскую систему (все сделано с умом — удобно), потом каждого прошу показать, что они делают… и каждому поясняю ошибки — 15 человек нормально, 20 уже конечно тяжеловато, но обычно, человек 5 нет всегда. Так что 15 — успеваю каждого проверить.


      Рабочая программа — да, но так нужно, иначе как понять, что вы даете и собираетесь дать и зачем это нужно. Она обычно один раз в год обновляется.


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


      Лабы сдают через гит в *.adoc формате — в универ только на знакомство ездил на первую лекцию.
      Вроде нормально получается, конечно очно все лучше, но и удаленно нормально.

        +2

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

          +1
          Работает как элемент геймификации или наоборот школьного журнала?

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


          Как минимум со значками проще допуститься до зачета и экзамена, но еще я разыгрываю всякие небольшие призы, типа Набор ручек от моей конторы, головоломок, сувениров ну и так далее за наибольшее количество значков.


          Еще каждому на следующую лекцию даю задание по небольшой презентации на какую-нибудь связанную тему, которую прошли только очень вскользь. И каждый из учеников должен за семестр доложиться перед всеми так, чтобы его поняли, 15 минут на каждой лекции этому посвящаем. Например, вскользь сказал им про конвейер, что микроконтроллер выполняет команды используя 4 ступенчатый конвейер, немного сказал что это значит, а на дом дал сделать презентацию и подробно описать принц работы конвейера. Вот один из студентов это и докалывает.


          Не поделитесь опытом, за что поднимаете и понижаете карму?

          Например, Лабораторная не сдана вовремя — карма -1.
          Проверяем задание, нечего показать (ничего не делает) — карма -1.
          Не сделал презентацию, которую должен был сделать — карма -1
          Посещение оно само отмечается при удаленной лекции — 2 раза пропустил, карма -1.
          Ну и так далее, "-10" — карма слита, и можно даже не стараться зачет сдавать.


          Плюсов обычно в карму нет.

            0
            Плюсов обычно в карму нет.
            Прямо как на хабре)
            Ручки и мёрч от компании это интересно. Видимо ваш работодатель возлагает какие-то надежды на выпускников? К себе работать зовёте?
            Я планировал и всё ещё хочу так делать, но пока не получается. В этом году знакомство с группой началось с вопроса от них, можно ли на стажировку, так что может быть удача наконец-то улыбнётся.
              0
              Ручки и мёрч от компании это интересно. Видимо ваш работодатель возлагает какие-то надежды на выпускников? К себе работать зовёте?

              Да так и есть, вначале на стажировку 2 года — пока они в магистратуре учатся. У меня 4 курс бакалавриата, я как раз там выбираю 2-3 на стажировку, а с неё уже как получится.

          0
          Простите, в каком ВУЗе Вы преподаете? Мне чтоб знать куда детей отправлять ))
          +2
          А пробовали спросить студентов прошедших курс два года назад, как у них сложилось с программированием и что они помнят из курса?
            0

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

              +1

              Вопрос не мне, но я могу по своему опыту ответить. Для аттестации кафедры каждые 3 года вроде бы, делается опрос выпускников — определенный процент выпустившихся должен работать по специальности, у них делают официальный опрос: На сколько вам пригодились знания, полученные по специальности, какие конкретно предметы. Даже приезжала из Европы тетенька опрашивала пару моих бывших студентов. Кого опрашивала — у тех порядок с программированием. Но точный процент сказать трудно. Думаю, что как минимум половина выпустившихся дружат с программированием в той или иной степени.


              Другой вопросы, что прошлый выпуск, например, был всего 8 человек. Остальные 12 или даже 14 были отсеяны за 4 года. А в Магистратуру идут уже вообще единицы, по-моему из 8 только 2 пошли.

              +2

              На мой взгляд — вы большой молодец! Всегда приятно видеть преподавателя, который знает, чему учит, и болеет за свое дело!


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

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


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


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


              Я пробовал решить это предложением писать вопросы в любое время, а не во время пар, надеясь, что смогу помочь тогда, когда они реально пишут код. Но нет, это сработало только для 2-3 человек. Остальным помочь не смог.

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

                0
                Спасибо за отзыв, приятно слышать.
                Чат в дискорде был, в нём же собирались на «лекции». В нём можно удобно писать и личные вопросы и общие в групповой. Так себе работало, как всегда только для самых активных.
                +4
                А почему именно D? Ну, допустим с с/с++ всё действительно сложновато, но тогда можно и rust. Чем D, будучи языком с GC, превзошел Java/C#/Go? А если забивать на работу с памятью, то почему не тот же python? Почему в вузах так любят языки, которые никому никогда не пригодятся?
                  +2

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

                    +1
                    Существенная доля ответов есть в статье, но постараюсь ответить подробнее.
                    Лично мне D просто нравится. Я продуктивнее пишу на D, чем на C++, Perl или JS, и похоже это не только субъективное восприятие, а свойство языка. Почему именно на этой кафедре решили преподавать именно этот язык, история сложная и для меня до сих пор целиком не известная.
                    Я понимаю, что GC делает язык похожим на другие языки со сборщиком мусора, но это иллюзия. В D гораздо больше из мира C++ и Rust, чем из C# или Java. Банально сравните производительность, граммотный D на голову обходит любые VM языки или тот же Go. В задачах, когда из процессора действительно нужно выжать всё, D не уступает и часто лидирует в сравнении с C и Rust. И это очень важно понять, что удобство не всегда достаётся ценой производительности.
                    В вузе надо учиться программировать и изучать концепции, а не практиковаться в чём-то одном. Вуз не должен выпускать программистов на Go, он должен выпускать образованных людей. После D вы сможете относительно просто перейти и на C++, и на C# и на Go, а вот обратное не верно. Этот язык богат на подходы, при этом прост в изучении основ. Кроме того кругозор позволяет видеть абстракции, а не конкретные синтаксические конструкции. На примере D хорошо объяснять программирование контрактное, функциональное, многопоточное, метапрограммирование. Как вы сможете донести саму идею zero cost (бесплатных) абстракций на примере Java, где их фактически не существует? А ведь это важная идея, которую продвигает тот же Rust.
                    И да, если бы я оценивал свой уровень владения Rust достаточным, то я бы предложил преподавать его. Имхо, в нём одна интересная мысль, но она действительно стоит того. Вот только я знаю D, а не Rust. Ну и кстати, в D тоже появляется анализ времени жизни и зарождается borrow checker. И если они доведут его до кондиции, решив все проблемы удобства и совместимости, то лет через 6 мы увидим его в C++, поверьте.
                      +2
                      В задачах, когда из процессора действительно нужно выжать всё, D не уступает и часто лидирует в сравнении с C и Rust
                      кажется, это даже чисто теоретически невозможно, а в этом замечательном докладе вы можете ознакомиться с причинами.
                      В вузе надо учиться программировать и изучать концепции, а не практиковаться в чём-то одном
                      Да, вы правы. Однако «изучить концепцию и полезный навык» всегда будет лучше чем просто «изучить концепцию». По той же самой причине я критикую преподавание pascal/basic — они может и подходят для обучения, но почти бесполезны как навыки. А еще, изучение практических навыков в вузе нужно для того, чтобы выпускники не оказывались оторваны от реальности.
                      Как вы сможете донести саму идею zero cost (бесплатных) абстракций на примере Java, где их фактически не существует?
                      А как можно изучать управление памятью на примере языка с GC? Универсальной технологии тут нет и не будет. Студентам чисто IT специальностей имеет смысл дать сразу несколько ЯП (например алгоритмы/структуры данных на си/плюсах, немного асма, архитектуру/паттерны на java, предметное типа обработки изображений/ML — python), а вот для инженеров непрограммерских специальностей наверно стоит советовать что-то более распространенное в индустрии. Скажем, радиотехникам python ну вот совсем не упал, D впрочем тоже.
                        +1
                        кажется, это даже чисто теоретически невозможно

                        Если Вы о сборщике мусора (по ссылке по крайней мере про него), то в D можно его не использовать. Хоть обширная часть стандартной библиотеки и написана с его применением, но все же никто не мешает программировать без этого, и более того, доступен специальный атрибут @nogc, который заставит компилятор ругаться каждый раз когда происходит выделение памяти через GC.


                        То есть формально D в настоящее время — это универсальный инструмент и для низкого уровня, и для абстрактной логики, поэтому неудивительно что автор использует его для обучения концепциям программирования.


                        Так что не вижу ни теоретической, ни практической невозможности, тем более что код генерируется одними и теми же бэкендами (GCC и LLVM)

                          0
                          Ручное управление памятью в D есть, и это отвечает на оба ваших вопроса. Ничего не мешает вообще использовать только C подмножество, будет всё то же самое, но удобнее за счёт фич этапа компиляции.
                          А к докладу Антона Полухина, который вы скинули, я бы хотел добавить, что любое управление памятью имеет накладные расходы. malloc требует дополнительного места под размер, имеет избыточное потребление для маленьких объектах на многих реализациях, и вообще не быстр, иначе не появились бы альтернативы и ручные аллокаторы. Любое выделение памяти не бесплатно, любой контроль за используемой памятью, GC, счётчик ссылок или дерево владения из Qt, вносит накладные расходы. Тот же Rust при всеобъемлющем контроле за временем жизни всё равно предлагает счётчик ссылок для динамики. А есть ситуации, когда RC медленнее, чем GC.
                          Поэтому важны настоящие zero cost абстракции, которые позволят вообще не выделять память, коих в D хватает. Например ленивые диапазоны (моя статья на хабре). После выхода C++20 выглядит банально, вот только как Ranges туда попали? Eric Niebler напрямую ссылался на D в объяснениях. И я считаю такие вещи важнее, чем встроенный в язык GC.
                            0
                            я бы хотел добавить, что любое управление памятью имеет накладные расходы. malloc… и вообще не быстр
                            все эффективные оптимизации аллокации уже реализованы в malloc. Оптимизировать дальше можно лишь за счет существенного увеличения объемов потребляемой памяти.
                            иначе не появились бы альтернативы и ручные аллокаторы
                            альтернативные аллокаторы это не всегда про быстродействие и не всегда про выделение памяти из кучи. Чаще всего — про осознанный размен потребления памяти на проценты быстродействия.
                            Тот же Rust при всеобъемлющем контроле за временем жизни всё равно предлагает счётчик ссылок для динамики
                            ну вы будете его использовать только там, где без него совсем никак — в случаях раздельного владения объектом между потоками. В таких ситуациях и GC без атомиков не справится.
                              +1
                              все эффективные оптимизации аллокации уже реализованы в malloc.
                              Все эффективные оптимизации на общий случай реализованы в malloc. Всегда есть частный случай, который может быть быстрее. Тот же malloc не располагает кучей данных, которые есть у GC — априорное знание о размерах объектов, например.
                              ну вы будете его использовать только там, где без него совсем никак — в случаях раздельного владения объектом между потоками
                              И RC нужен не только для многопоточности. Растовский rc::Rc наоборот не атомарен и должен использоваться только в одном потоке. Общее владение ресурсом так или иначе приводит к счётчику ссылок, сборке мусора или ошибкам и утечкам. Выбирайте. Здорово, когда можно не выбирать и использовать только одиночное эксклюзивное владение, но это же не всегда возможно даже в Rust.
                                +1
                                Все эффективные оптимизации на общий случай реализованы в malloc. Всегда есть частный случай, который может быть быстрее.
                                ну у вас программа же не из единого частного случая состоит, там аллокатор настолько же общего назначения. Знание размера типа может помочь убрать пару из аллокации/деаллокации совсем, но едва ли ускорит саму аллокацию. Вы же не будете инстанцировать аллоцирующий метод для каждого из потенциальных размеров данных?

                                Растовский rc::Rc наоборот не атомарен и должен использоваться только в одном потоке
                                да, перепутал с Arc. Обычный Rc во-первых сравнительно редко используется*, а во-вторых, его накладные расходы минимальны и уж точно не выше таковых у GC.

                                * Лично я за свою карьеру на плюсах использовал неатомарный refcounting единожды. Возможно, в расте его используют почаще — чтобы обойти некоторые ограничение borrow checker'а без unsafe, но думаю всё равно редко
                                  0
                                  Обычный Rc во-первых сравнительно редко используется*, а во-вторых, его накладные расходы минимальны и уж точно не выше таковых у GC.

                                  Ну, не совсем. Счётчики сильных и слабых ссылок — это +2 машинных слова к каждой аллокации в Rc. Кэш из-за них страдает, особенно, если данные маленькие лежат. Уничтожение одной структуры в Rc может привести по цепочке к уничтожению Rc, которые тот объект держал, и глубина вложенности может быть произвольной. Деструктор Rc работает на том же потоке, что и остальная часть программы, так что пока деструктор обходит граф объектов, программа ничего полезного не делает. Клонирование, опять-таки, хоть и дешёвое, но всё же дороже просто копирования указателя.


                                  Это всё проблемы, которых лишён хороший сборщик мусора. Вдобавок он ещё и может нормально циклы владеющих ссылок разрулить, которые при помощи Rc нужно разбивать руками с использованием слабых ссылок.

                                    +1
                                    во-первых, как я уже сказал, Rc почти никогда не нужен, поэтому его влияние на производительность минимально даже если бы оверхед был значительным.
                                    Счётчики сильных и слабых ссылок — это +2 машинных слова к каждой аллокации в Rc. Кэш из-за них страдает, особенно, если данные маленькие лежат.
                                    для функционирования GC нужно в каждой аллокации размещать объект со всеми ссылками. В общем случае это куда больше двух машинных слов.
                                    Уничтожение одной структуры в Rc может привести по цепочке к уничтожению Rc, которые тот объект держал, и глубина вложенности может быть произвольной. Деструктор Rc работает на том же потоке, что и остальная часть программы, так что пока деструктор обходит граф объектов, программа ничего полезного не делает.
                                    значит когда на многоядерной машинке одно ядро чистит свои ресурсы, то это «программа ничего не делает», а во время stop the world вот прямо таки блещет производительностью. Ах, да, бывают же многопоточные GC без stop the world, которые работают… на атомарном рефкаунтинге.
                                    Клонирование, опять-таки, хоть и дешёвое, но всё же дороже просто копирования указателя.
                                    в большинстве случаев это мув.
                                    Это всё проблемы, которых лишён хороший сборщик мусора
                                    это все проблемы, которых сборщик мусора не только не лишен, а которые в нем гиперболизированы
                                      +1
                                      Вы куда то далеко от темы топика уехали.

                                      Раст настолько «не такой как все», что его учить в универе просто вредно.
                                      Разве что в конце обучения на спецкурсе наравне с Лентой Тьюринга и Брейнфаком.
                                        +1
                                        От темы и правда ушли, тут GC, ниже GUI, но вы попали в больное место, не могу молчать.
                                        Rust, Машина Тьюринга и Brainfuck — те вещи, знакомство с которыми я считаю необходимыми для современного образованного программиста. Rust, чтобы увидеть, как бывает всё не так и это здорово. Машина Тьюринга вместе с задачей останова просто для понимания пределов программирования. Меня поражает как мало людей не понимают, что нельзя в общем случае написать программу, которая идеально проинспектирует другую программу. А Brainfuck для демонстрации абсолютно чистого программирования, кода самого в себе. Его простота и полнота завораживает и заставляет относиться к компьютеру по-другому.
                                        И всё это не важно в каком порядке и когда. Rust разве что только после становления хотя бы как начинающего программиста. Чтобы видеть контраст, нужно видеть фон.
                            –1
                            кажется, это даже чисто теоретически невозможно, а в этом замечательном докладе вы можете ознакомиться с причинами.

                            этом замечательном докладе

                            Что-то я не разделяю ваших восторгов.

                              +1
                              я не просто так скинул ссылку именно на ту часть доклада, где обсуждается GC
                        +2
                        Самое интересное в программировании, на мой взгляд, это кодирование пользовательского интерфейса. Для С++ используются такие фреймворки, как Qt, wxWidgets, Win32++, WTL / ATL и т.п.

                        Программированию интерфейсу, как таковому, уделяется слишком мало внимания. Соответственно, как только сталкиваешься с реальной задачей, так сразу возникает куча проблем на ровном месте. Как сделать то, это и другое. Общий подход, что позволяет делать официальный фреймворк, то и делай, все остальное от лукавого. Подход, почти как в «1С» – ешьте, что дают и, смотрите, не обляпайтесь.

                        Но ведь С++ это фундаментальный язык, поэтому с ограничениями фрейморков можно согласиться, только если это высокоуровневые платформы, типа Qt и wxWidgets. Но WTL, скажем, это почти уровень WinAPI, так что его ограничения трудно принять.

                        Возьмем, например, парадигму MDI. Не знаю, с какого бодуна, наверное, еще со времен Windows-3.1, но существует запрет, на уровне системных dll, использования локального меню в дочерних MDI-окнах. Вот народ и изгаляется. Создает контекстное меню, кнопочное меню, командные бары и панели, панельное меню и даже html-окна с меню в виде ссылок. Хорошей иллюстрацией этого служат разные версии продуктов 1С77-1С8х.

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

                        Хорошо, идем дальше. Вот язык D демонстрирует работу в консольных окнах. Замечательно! Но нам надо оконный интерфейс, запускаемый в консоли. При этом происходит мигание консольного окна перед созданием GUI. В С++ проблема решается разными точками входа. Вместо консольного main() используется графическая WinMain() и все хорошо, пока это возможно. Но возьмем, для примера, консольный опенсорный видеоплейер FFPlay.c. Замечательная программа, но использует окна из SDL фреймворка, а те просто не работают, по определению, с WinMain(), только с main(). Соответственно, с графическим окном видеоплейера болтается рядом консольное окно, которое нам, в принципе, не нужно. Да, его можно удалить с помощью вызова FreeConsole(), но мигание останется, что выглядит очень непрофессионально.

                        Те же эксперименты с видеоплейером FFPlay.c, в программе с графическим пользовательским интерфейсом, ненавязчиво подводят нас к GUI-шной мультипоточности. И опять, хороших примеров подобной связки в Интернете нет. А если использовать адаптированный код работы с потоками мастера Multi-SDI из WTL, то упираемся в ограничение данной модели мультипоточности, связанной с невозможностью реструктуризировать Си код в код С++ (проще говоря, переписать FFPlay.c в виде классов).

                        После долгой возни со всеми описанными проблемами их, в конечном счете, можно решить на приемлемом уровне. Но это все как бы достаточно стандартные вещи, а не какие-то там изобретения, но народ почему-то к интерфейсу пользователя относится по остаточному принципу. Есть, хорошо, нет – обойдемся. Но, то что простительно для концепции «1С» не слишком подходит к С++ или там другим новомодным языкам программирования.

                        И последний момент, которой не способствует особому интересу к «D», как к «C++ сделанному правильно». Это опенсорс. Когда будет приемлемый опенсорс на «D», тогда и посмотрим.
                          0
                          У D действительно не так много библиотек как у C/C++. Но любые С либы можно использовать в D т.к. этот язык ABI совместим с С, а чтобы импортировать C функцию достаточно одной строки: extern© int brk(void* address), все теперь вы можете использовать brk в своем D коде. D также имеет хорошую совместимость с С++ (читайте их туториал).

                          Что касается опенсорсных библиотек, веб фреймворк vibe.d и mir-algorithm приходят на ум. У D около 1.8к пользовательских библиотек, не говоря об очень большой стандартной библиотеке. D используют в проде, движок к игре Quantum Break был написан на D, высокопроизводительная файловая система от Weka.io написана на D и много еще чего, что мне просто лень тут перечислять. Зайдите на D сайт и посмотрите. В Мюнхене например он довольно популярен и тут есть 3 большие компании, которые используют его в проде. Тут же и проводятся митапы по D. Несомненно, это не очень популярный язык и найти с ним работу крайне сложно. Но ведь у вас цель не работу искать, а расширять собственный кругозор ;)
                            –2
                            У D действительно не так много библиотек как у C/C++. Но любые С либы можно использовать в D т.к. этот язык ABI совместим с С

                            А зачем? Я не хочу Си, я хочу С++. Для меня это идеальный язык программирования. Зачем мне «умножать сущности без необходимости»?

                            Что касается опенсорсных библиотек, веб фреймворк vibe.d и mir-algorithm приходят на ум. У D около 1.8к пользовательских библиотек, не говоря об очень большой стандартной библиотеке.

                            Вы меня сможете заинтересовать, если покажите пример опесорса, типа «2С» (достаточно одного только интерфейса, без содержательной части), но сделанного красиво и удобно. Главные требования: MDI, закладки (табы) окон, грид (форма списка), поддерживающий группы элементов, как в 1С77 и согласованный с деревом (TreeView), удобные настраиваемые панели инструментов, а также полноценные локальные меню в дочерних окнах, поддержка ГУИ-шной мультипоточности и т.п.
                              +1
                              Вы сами только что ответили «Я не хочу Си, я хочу С++.». Я не смогу вас убедить.

                              Я лишь прокомментирую «Зачем мне «умножать сущности без необходимости»?». Это надо делать, чтобы быть профессионалом. Недостаточно знать один язык, надо знать около 5 языков. И это не мои слова, а слова Страуструпа. У D есть много интересных решений, которые сделают вас лучшим специалистом, особенно, если вы пишете код на С/С++.
                                –1
                                Вы сами только что ответили «Я не хочу Си, я хочу С++.». Все дальнейшие разговоры непродуктивны, как и непродуктивны выши комментарии к данному посту.

                                Претензия ко всем туториалам, для начинающих, это увлечение консольными приложениями в ущерб оконным. Зачем ломиться в открытую дверь? С консольным программированием нет проблем, когда примеров учебного кода порядка 99%. Если бы ваш любимый «D» дал бы примеры нетривиального подхода к программированию пользовательского интерфейса, то это было бы интересно всем, кому уже надоела консоль.

                                Я лишь прокомментирую «Зачем мне «умножать сущности без необходимости»?». Это надо делать, чтобы быть профессионалом. Недостаточно знать один язык, надо знать около 5 языков.

                                А кто вас сказал, что я не знаю «5 языков»? Пожалуйста, Ассемблер (MASM-32) (можете посмотреть мои статьи на erfaren.narod.ru ), Object Professional (Pascal), Adobe Action Script (AS3) ( scholium.webservis.ru ), Visual FoxPro 9 и C++ (с фреймворками), наконец. Кстати, кормит меня 1С и VFP-9.
                                А С++ это язык для удовольствия.

                                У D есть много интересных решений, которые сделают вас лучшим специалистом, особенно, если вы пишете код на С++.

                                Интересного есть много где. Мои задачи мне поможет решить С++ / WTL, а не «D». А курс «Программирование пользовательского интерфейса на С++ / WTL / ATL» в университете, не исключено я буду вести лично, благо образование позволяет.
                                  +1
                                  А курс «Программирование пользовательского интерфейса на С++ / WTL / ATL» в университете, не исключено я буду вести лично
                                  Обязательно напишите про то, что у вас получится, с удовольствием почитаю про ваш опыт. Серьёзно, без подколок и сарказма. Разнообразие это очень хорошо.
                                    0
                                    Если поборю собственную лень :). В случае успеха, опубликую информацию, здесь, на Хабре.
                                      +1
                                      WTL / ATL… преподавать
                                      В Fallout'e 1 или 2 был перк «Гробокопатель». Минутка черного юмора…
                                      +2
                                      А кто вас сказал, что я не знаю «5 языков»? Пожалуйста, Ассемблер (MASM-32) (можете посмотреть мои статьи на erfaren.narod.ru ), Object Professional (Pascal), Adobe Action Script (AS3) ( scholium.webservis.ru ), Visual FoxPro 9 и C++ (с фреймворками), наконец. Кстати, кормит меня 1С и VFP-9.
                                      Могу только пособолезновать такому жизненному пути (
                                      Не зная даже названия ЯП....(Object Professional)
                                        –1
                                        Могу только пособолезновать такому жизненному пути (

                                        Сейчас актуальны искусственный интеллект и 3d-моделирование. Вы занимаетесь этими вещами? Нет? Тогда тоже сочувствую. Какие такие собственные преимущества вы имеете в виду?

                                        Не зная даже названия ЯП....(Object Professional)

                                        О! Это очень прикольная штука на заре заката MS-DOS. DOS уже уходил в небытие и фирмы спешно продавали исходный код своих программ за символические деньги (до этого библиотека распространялась только в бинарниках). Мы купили эти исходники и я даже успел наваять одну серьезную программу. Object Professional поддерживала работу резидентных программ и доступ к расширенной памяти, что во времена MS-DOS было очень актуально. Получалось очень круто по тем временам, но вскоре пришла Windows 95/98 и DOS стал постепенно отмирать.

                                        А так еще приходилось иметь дело с VB.NET, интересная система, но .NET, как и COM не стали слишком уж популярными.
                                          +1
                                          Object Professional это не язык программирования, а библиотека от TurboPower Software
                                          По ссылке можно скачать исходники — поностальгировать, которые они при закрытии выложили в открытый доступ (но не Object Professional).

                                          ЯП же называется Object Pascal от Борланд, есть коллизия с версией от Эппл. Появился в версии Turbo Pascal 5.5
                                            0
                                            Object Professional это не язык программирования, а библиотека от TurboPower Software
                                            По ссылке можно скачать исходники, которые они при закрытии выложили в открытый доступ (но не Object Professional).

                                            Я же в скобках указал Pascal. Понятно, что речь шла о библиотеке, которая до этого распространялась только в бинаринках. Но мы купили именно Object Professional, v. 1.02. Даже книги были.

                                            Кроме этого мы еще купили исходники стандартной библиотеки Си (до 1995 года еще), типа код функций printf и т.п., но меня разочаровало отсутствие там исходного кода для работы с графикой.

                                            ЯП же называется Object Pascal от Борланд, есть коллизия с версией от Эппл.

                                            В литературе, которая шла с исходниками, речь была только о паскале. Может и были какие-то нюансы, но я их не заметил, хотя успел написать серьезную программу, с использованием кода Object Professional, v. 1.02.
                                        +4
                                        erfaren.narod.ru

                                        Автора подобного безобразия надо от преподавания GUI гнать поганой метлой.

                                    +1
                                    движок к игре Quantum Break был написан на D

                                    Не совсем: движок игры написан на C++, а D использовался вместо скриптового языка для быстрого прототипирования: код на D компилировался в DLL, и можно было вносить изменения, даже не перезапуская игру.

                                    0
                                    Это на ваш взгляд, а для меня нет хуже задачи, чем GUI. Занимался им на Qt и на Flash. Я верю, что вам и многим другим нравится, но на нём свет клином не сошёлся.
                                    Про опенсорс согласен, хотелось бы больше. Не хватает какой-то библиотеки, которая подняла бы D своей популярностью. Я надеялся, что vibe.d станет ею, но разочаровался — удобно, но не быстро, не хватает какой-то изюминки.
                                      0
                                      Это на ваш взгляд, а для меня нет хуже задачи, чем GUI. Занимался им на Qt и на Flash. Я верю, что вам и многим другим нравится, но на нём свет клином не сошёлся.

                                      Вполне верю, но у вас просто не было амбициозной задачи, требующей хорошего интерфейса. Вот, я только что написал в соседней реплике: «Для примера, сделайте аналог интерфейса пользователя (но более современно выглядящий) для учетной платформы 1С77. Не надо движков баз данных, макетирования отчетов, запросов и т.п. Сложно это или просто? С учетом любых доступных систем программирования и опенсорса. Можно посмотреть в сторону опенсорса «2С», но там ужасная реализация GUI на MFC. Если сделаете, цены вам не будет. А все остальное мы уже «припердолим» сами :) .»

                                      Про опенсорс согласен, хотелось бы больше. Не хватает какой-то библиотеки, которая подняла бы D своей популярностью. Я надеялся, что vibe.d станет ею, но разочаровался — удобно, но не быстро, не хватает какой-то изюминки.

                                      Как по мне, то С++ с существующими фреймворками вполне хорош! Поэтому лично у меня нет потребности в другом языке программирования. Я много чего перепробовал, но остановился на С++ / WTL ( возможно еще ATL). Все остальное – опенсорс, которого более, чем достаточно, успевай только осваивать. Super!
                                        +2
                                        Вы мне предлагаете поспорить о вкусах. Я знаком с проблемами и сложностями проектирования GUI, не интересно. Не знаю будет ли это хорошим примером, но интересна ли вам проблема числа 10958? Или доказательства/опровержения существования и единственности решения системы уравнений Навье-Стокса? И в то, и в другое я закапывался и мне это нравится, но я не ожидаю, что понравится всем, даже если потратят столько же времени. Фломастеры разные, пусть все занимаются своим делом. У меня интерфейсы вызывают непреодолимую тоску и вовсе не из-за простоты или рутины.
                                        Про C++ не спорю, это мой основной рабочий инструмент для прода в нише совершенно противоположенной вашей — разработка серверных библиотек. По совершенно объективным причинам я не лезу туда с D. А вот инструментарий для себя и других я пишу на D, и все это устраивает, потому что быстро пишется и быстро работает.
                                        Острой необходимости в замене C++ нет, иначе бы она уже была, но это не значит, что нужно останавливаться на нём.
                                          0
                                          Вы мне предлагаете поспорить о вкусах. Я знаком с проблемами и сложностями проектирования GUI, не интересно.

                                          Ну, на нет и суда нет. Верю, что вам не интересно, плохо не это, плохо то, что это никому не интересно. Книги на эту тему всего лишь пережевывание MSDN. Однако мне интересно, поэтому, хотя бы одна книга, написанная на данную тему, увлеченным автором должна быть. Поэтому, как накоплю достаточно практического опыта, так и опубликую свой опус. А потом посмотрим, заинтересуется ею хоть кто-нибудь.

                                          Не знаю будет ли это хорошим примером, но интересна ли вам проблема числа 10958?

                                          Не интересна! Когда я был маленьким, море подобных задач публиковалось в журнале «Наука и Жизнь». Тогда это было хоть немного интересно. А сейчас…

                                          Вот смотрите, я придумал новый алгоритм внешней сортировки «естественным слиянием» ( emery-emerald.narod.ru/Cpp/2E1562.html ), который использует частичный порядок даже в произвольных последовательностях. Самое интересное, что случайная последовательность обладает частичным порядком больше минимального, который теоретически равен 2! А именно, после обсуждения на форуме математиков dxdy.ru, удалось доказать, что средняя длина упорядоченной подпоследовательности L для равномерно распределенной случайной последовательности данных равна: L = 2e – 3 = 2.436563656918.

                                          Поэтому, если хотите решить задачу числа 10958, обратитесь на этот форум, очень вероятно, что вам помогут. Недавно я там обсуждал тему, связанную с распознаванием встроенных субтитров обучающих видео: «Как группировать бинарные матрицы по степени их похожести?» ( dxdy.ru/topic142232.html ). В результате нашел подходящий алгоритм решения, не связанный с OpenCV.

                                          Или доказательства/опровержения существования и единственности решения системы уравнений Навье-Стокса?

                                          Это вы собираетесь доказать экспериментально, с помощью компьютерного моделирования?
                                            0
                                            Почему же экспериментально, вполне теоретически. Сейчас уже нет, но ещё недавно вполне неплохо был погружён в теоретические изыскания. Так как для хобби сложновато, а в работе не пользуюсь, безнадёжно отстал. Никогда не считал, что это задача мне по силам (если она вообще кому-то по силам), но интересно же. Там весёлая история, как и с P=NP, практики исходят из существования единственного решения, как и P!=NP, а теоретики не уверены — одна из задач тысячелетия.
                                              0
                                              Никогда не считал, что это задача мне по силам (если она вообще кому-то по силам), но интересно же.

                                              Ну, если вам нравится теоретическая физика, то давайте обсудим что-нибудь попроще.

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

                                              Общее уравнение Шредингера (УрШ) можно рассматривать как квадратное уравнение относительно постоянной Планка h. Решаем его, получаем формально два корня. Но постоянная Планка то одна, поэтому либо дискриминант квадратного уравнения равен нулю, либо у постоянной Планка есть второе фундаментальное значение. Оба случая интересны. В первом варианте получаем из одного уравнения два, что упрощает решение и анализ УрШа. А, во втором, делаем научное «открытие», постоянная Планка имеет два разных значения. Ура, товарищи! Куда обращаться за Нобелевской Премией? :)
                                                +1
                                                Не понимаю к чему это. В квантовой физике я понимаю примерно ничего, проблема наличия решения уравнений Навье-Стокса лежит исключительно в области математики, никак не касаясь физики. Давайте не уходить в оффтопик. Я изначально писал про уравнения исключительно как специфическую область интересов, которую не все разделяют.
                                                Мы вроде сошлись на том, что мне интересно одно, вам другое и оба не видим в этом факте беды. Вы сокрушаетесь, что ваша любимая тема непопулярна, чтож бывает. Вы хотите создать курс программирования GUI? Ничего не имею против, поспособствовать тоже особо ничем не могу. Мне лично не кажется, что такая узкая тема как «Программирование пользовательского интерфейса на С++ / WTL / ATL» не совсем хороша для базового курса, но в магистратуре профильных заведений может найтись место.
                                                  0
                                                  Не понимаю к чему это. В квантовой физике я понимаю примерно ничего, проблема наличия решения уравнений Навье-Стокса лежит исключительно в области математики, никак не касаясь физики. Давайте не уходить в оффтопик.

                                                  Там квантовая механика, дана, как я написал, «для маскировки». По сути, чтобы напугать, а не в силу особой необходимости. Поэтому проблема чисто математическая, а не физическая. Физики там не больше, чем в уравнении жидкости в трехмерном пространстве, то бишь, Навье-Стокса. Модель имеет физические истоки, но стала чисто математической. Так и в указанной задачке для пятого класса. Для ее решения достаточно школьных знаний, возможно советских времен, а не российских. Странно, немного, что проблему Навье-Стокса вы понимаете лучше, чем эту достаточно простую задачу.
                                                  Однако могу вас утешить, впервые я обратился за разъяснениями к своему физику-семинаристу, в первом ВУЗе, ученику Капицы. Он любил задалбливать нас трехмерными интегралами из гидродинамики, но по этой задачке сказал, что здесь должна быть ошибка, но где, ищи сам. Потом, обратился к одной даме физику, случайно оказавшейся напарницей по автобусу. Она тоже не смогла ответить по существу. И только студент мехмата второго курса, который оказался моим напарником по комнате в общежитии МГУ, ответил четко и правильно, причем быстрее, чем я даже успел сформулировать эту задачу. Даже раздосадовало немного, что все оказалось так просто.
                                                    0
                                                    Понимаете, с точки зрения математики тут парадокса нет. Вы предложили рассматривать как квадратное уравнение, а то есть зафиксировать момент времени t и координаты r. Может быть один корень, может два. Последствия и того, и другого начинаются в физической интерпретации. Как и области определений, из которой очень быстро может следовать бессмысленность второго корня в силу отрицательности или ненулевой мнимой части. Тут же подразумевается вещественное время и координаты, но комплексные функции. Ограничения на h нужно тоже задать и смотреть. А пока мы просто решаем уравнение, проблем нет.
                                                    Раз вы видите парадокс и знаете его решение, значит вы рассматриваете модель подробнее, чем простое квадратное уравнение, а значит нужно разбираться с используемыми функциями, их областями определений, значений и тд.
                                                    Ну а истории про то, как ученик Капицы не смог решить, отсылки про советские и российские времена, и общий тон вопроса придают очень неприятные оттенки задаче и задающему.
                                                    P.S. Квадратные уравнения, это 8 класс российской и 7 класс советской школы, никак не 5. Куда же нас унесло, хорошо же общались про D и GUI.
                                                      0
                                                      Кстати, есть интересное направление — программирование научных вычислений. Вполне себе университетские задачи по линейному программированию итп.

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

                                                        Насчет 5-го или 7-го класса спорить не буду, но ощущения знакомства с квадратными уравнениями у меня очень ранние.

                                                        Насчет, «куда же нас занесло», это нормально. По основной теме как бы уже все сказано, добавить особо нечего, поэтому либо «а поговорить» либо подождать публикации другой, более соответствующей статьи.

                                                        По задачке, «физической интерпретации» особо никакой нет. Речь идет просто об избыточном корне квадратного уравнения. У нас в школе их называли «паразитными». Скажем так, уравнение Шредингера может быть записано без паразитных корней для постоянной Планка, присутствующей в первой степени. Но это будет не одно уравнение, а несколько. Путем математических преобразований из нескольких уравнений получено одно, соответственно добавился лишний корень для h (типа, из х = 1 получаем x^2 = 1 и избыточный корень х = –1). При этом избыточные корни отсекаются за счет краевых условий, поэтому подобная форма УрШ вполне всех устраивает.

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

                                                        Как видите, особого физического смысла здесь нет, уравнение подобного типа в физике может встречаться и в других моделях, анализ, по сути, чисто математический.
                                        +2
                                        А какое отношение этот опус имеет к университетскому программированию?

                                        Впрочем из GUI на D лично я собирал еще в 2014г демки с разными библиотеками — DWT, GtkD, DFL, TkD. Недавно — с DlangUI
                                        Это все опенсорс, включая компилятор и стандартную библиотеку.

                                        P.S.Лично я не считаю D хорошим первым языком для обучения. Слишком сложен, требует бэкграунда. Вторым, — вполне (особенно в тех местах, где «учат» С++).
                                          0
                                          Вы считаете, что C++ лучше в качестве первого языка? Или я не правильно понял про места, где учат C++? Я считаю что D гораздо лучше в качестве первого, возможно даже лучший из мне известных.
                                            +1
                                            1й — бейсик или паскаль или аналоги, где не надо рассказывать для хелловорлда про файлы, модули, импорты, проекты, компилятор/линкер итп

                                            С++ сложнее чем Д, так что еще хуже для 1го.

                                            Главное, не зацикливаться на 1м языке, а после понимания простых основ — подпрограмм, циклов, двигаться вперед. Это уже может быть и Питон и Д и Шарп и Ява и С++(но сначала С)
                                            0
                                            А какое отношение этот опус имеет к университетскому программированию?

                                            А что университетское программирование это типа учебного, т.е., ненастоящего программирования? Чтобы, придя на предприятие, сказали: «Забудьте все то, чему вас учили!»?

                                            А так, мое мнение, программистам надо давать отдельный курс, вроде: «Программирование пользовательского интерфейса на С++ / WTL / ATL», вплоть до программирования собственных контролов, типа форм списков. Вообще, почти все стандартные контролы Windows требует «напильника», чтобы довести их до ума. Те же закладки для MDI-окон, вроде не сложно, но хороших примеров нет, а то, что есть, имеет явно избыточный вес.

                                            Впрочем из GUI на D лично я собирал еще в 2014г демки с разными библиотеками — DWT, GtkD, DFL. Недавно — с DlangUI
                                            Это все опенсорс, включая компилятор и стандартную библиотеку.

                                            Не интересно GUI вообще, интересно иметь легкий рабочий вариант. Для примера, сделайте аналог интерфейса пользователя (но более современно выглядящий) для учетной платформы 1С77. Не надо движков баз данных, макетирования отчетов, запросов и т.п. Сложно это или просто? С учетом любых доступных систем программирования и опенсорса. Можно посмотреть в сторону опенсорса «2С», но там ужасная реализация GUI на MFC. Если сделаете, цены вам не будет. А все остальное мы уже «припердолим» сами :).
                                              +1
                                              А так, мое мнение, программистам надо давать отдельный курс, вроде: «Программирование пользовательского интерфейса на С++ / WTL / ATL»

                                              Мне кажется, что это ещё хуже.


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


                                              Мне кажется, что вы зацикливаетесь на устаревшей технологии с которой любите (или вынуждены) иметь дело и экстраполируете это на всю индустрию. Если уж писать гуй на С++, то лучше Qt взять что ли.

                                                0
                                                Я сам предпочитаю десктопные приложения повсеместному уходу в веб, но надо быть реалистом: на WTL/ATL сейчас очень мало что пишут (а уж начинать проект с прицелом на эти технологии так вообще почти никто не будет). Да и кроссплатформенность сейчас более актуальна.

                                                Я могу себе позволить не обращать внимания на моду. Да и выражение такое есть, если хотите добиться успеха, идите туда, где никого нет. Этот принцип меня вполне устраивает.

                                                Что касается кроссплатформенности, то проще переписать программу с нуля, чем сразу поддерживать «коня и трепетную лань». Тем более что необходимости осваивать другие платформы, пока нет.

                                                Мне кажется, что вы зацикливаетесь на устаревшей технологии с которой любите (или вынуждены) иметь дело и экстраполируете это на всю индустрию. Если уж писать гуй на С++, то лучше Qt взять что ли.

                                                Я работал с Qt, он мне нравится, но он очень большой для моих целей. Потом взял систему попроще, wxWidgets, тоже милая вещь, но тоже великовата для меня. Потом нашел WTL и это оказалось то, что мне нужно. Есть еще легкий опенсорсный Win32++, как заменитель MFC, однако WTL мне импонирует больше.
                                                  0
                                                  Я могу себе позволить не обращать внимания на моду. Да и выражение такое есть, если хотите добиться успеха, идите туда, где никого нет.

                                                  Это замечательно, но мы, вроде как, об обучении говорим? И выше как раз было о том, что университетские знания не должны быть бесполезными для "реального программирования". Так вот WTL подавляющему большинству не пригодится.


                                                  Что касается кроссплатформенности, то проще переписать программу с нуля, чем сразу поддерживать «коня и трепетную лань».

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


                                                  Я работал с Qt, он мне нравится, но он очень большой для моих целей.

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

                                                    0
                                                    Это замечательно, но мы, вроде как, об обучении говорим? И выше как раз было о том, что университетские знания не должны быть бесполезными для «реального программирования». Так вот WTL подавляющему большинству не пригодится.

                                                    Т.е., выходит я занимаюсь «не реальным программированием»? Меня же никто не принуждает, сам пришел к необходимости освоения WTL, значит, потребность была немного более чем абстрактный интерес.

                                                    Кстати, вы же изучение Qt или wxWidgets не отрицаете, видите в этом пользу. А WTL это тоже самое, только легковесное. Разве программист обязан делать только монструозные программы? Тем более что один и тот же результат, что для Qt, что для WTL можно получить сопоставимыми усилиями. Разница только в объеме конечной программы.

                                                    Более того, можно вообще поставить задачу создания интерфейсного контейнера, как я его называю, в виде некоего мастера. Допустим, вам дали задачу перенести данные из одной системы (формата) в другую. Вы быстренько наваяли какой-нибудь sql-скрипт с элементами пред и постобработки, вручную завели исходные параметры, выполнили, получили результат. Завтра другие данные и параметры, вы вручную меняете их и снова получаете результат. И так каждый раз. У меня лично подобных программ по разовой конвертации данных сотни, если не тысячи.

                                                    Вот сидишь и думаешь, нафига козе баян? А так берешь наш мастер по генерации произвольного интерфейсного контейнера, в автоматическом режиме генеришь код, добавляешь туда содержательную часть и у вас получается программа вполне товарного вида, от которой пользователи будут просто пищать. А усилий минимум. Профит? Вполне!

                                                    Или возьмем ту же программу 1С77. Ее все не любят, она давно морально устарела, но часто – густо более предпочтительна, чем 1С82 или 1С83. Она на порядок дешевле, непритязательна к ресурсам, легко поддерживается и программируется, поэтому для учета на средних предприятий, особенно в случае таких непризнанных республик, как ЛНР / ДНР просто идеальное решение.

                                                    Но почему бы не пойти дальше и не сгенерировать интерфейсный контейнер а-ля 1С77, только на более современном уровне, в т.ч., для 64-х битных платформ. В качестве движка базы данных можно взять опенсорсный SQLite, навигацию по данным делать с помощью MMF, а поддержку отчетов использовать на первых порах опенсорсную.

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

                                                    Кстати, бизнес логику удобно вынести на уровень плагинов, так чтобы каждый мог добавлять в программу нужный модуль. Отсюда мы плавно переходим к модульному учету, который вполне востребован на разных уровнях, на всех предприятиях. Речь не идет об альтернативе для корпоративных пользователей, только для малых и средних предприятий, коими 1С просто тупо перестала заниматься.

                                                    И после этого фразы типа: «Так вот WTL подавляющему большинству не пригодится» выглядят несколько наивно :). Хотя, по сути, вы правы, всем не нужно. Народу нужен результат, а результат должны дать программисты, а они вправе желать облегчить себе генерацию шаблонного кода. А спрос для подобных программ я лично у себя в ЛНР (и не только) всегда найду. Вот почему я кровно заинтересован решить проблему пользовательского интерфейса на приемлемом для себя уровне.

                                                    ядро/бэкенд лучше написать один раз — это и поддерживать будет проще

                                                    Пересборкой своих и чужих программ приходится заниматься постоянно. Я бы даже назвал это методом освоения и совершенствования программирования. Поэтому насчет «один раз» весьма спорно, если вы конечно не гений программирования.

                                                    Любопытно было бы услышать подробности. В чём выражается это «очень большой»? В микроконтроллер не влезает? Или просто занимает на пару мегабайт больше, чем хотелось бы?

                                                    Естественно, дело не объеме выходного кода, хотя если размер можно уменьшить на порядок, без потери качества, то почему бы этого не сделать? Скорее речь идет о понимании используемого опенсорса. Qt объемный в смысле освоения, но если следовать в парадигме стиля программирования Qt, то проблем как бы не возникает. Нюансы появляются, когда что-то хочешь сделать по своему, что не является стандартным для Qt. Можно это сделать? Конечно можно! Только надо знать как.

                                                    Поэтому вопрос в данном случае чисто прагматический. Да, Qt очень мощный и там можно делать все. Особенно мне нравится, что он поддерживает SQLite на уровне встроенного драйвера, а также контрол «форма списка» или грид. Это лучший опенсорсный грид, который я видел. Тем не менее, у меня и здесь есть собственные нюансы. Во-первых, SQLite мне нужен только для создания и поддержки индексов, а для юзания базы данных (типа sdf – simple data format) я хочу использовать технологию MMF (отличнейшая вещь, у меня даже статья на codeproject.com есть на эту тему). А по гриду я хочу иметь универсальный контрол, общий и для формы списка и для формы элемента (диалога) и для печатной / табличной форм. А экспериментировать с этим лучше в «чистой» системе, т.е., не такой сложной как Qt, поэтому WTL – идеальное решение.
                                            +4
                                            Самое интересное в программировании, на мой взгляд, это кодирование пользовательского интерфейса.

                                            Да вы, наверное, шутите! Это самое мерзкое и геморное, что есть в программировании!

                                              0
                                              Да вы, наверное, шутите! Это самое мерзкое и геморное, что есть в программировании!

                                              Да нет, не шучу! Но я вполне понимаю вашу неприязнь к GUI, а вы мою любовь к пользовательскому интерфейсу оценить не в состоянии :).
                                                +1

                                                Ну справедливости ради, многим новичкам реализовывать какие-то синтетические штуки в консоли и правда кажется унылым. А с GUI можно даже что-то условно-полезное для себя соорудить: делфи с набрасыванием компонентов на форму не зря большую популярность получил. Хотя сейчас даже в плане пользовательского интерфейса, вероятно, уже другие ориентиры: веб, мобильные приложения и т.д.

                                                  +1
                                                  Вы правы. Я думал, как включить минимальный GUI в курс, чтобы поднять интерес. Не стал, потому что для этого нужно убрать что-нибудь другое. GUI сложнее консоли, у него больше состояний, так или иначе он базируется на событиях и нужна инверсия контроля. В этом году я ещё не делал нового обзора gui библиотек на D, есть небольшой шанс, что я всё же внесу интерфейс в курс.
                                                  Очень хотел бы внести ещё и компиляцию в webassembly с библиотекой для вёрстки прямо из кода, но инструментарий был сыроват и сложноват. Это бы позволило писать под привычное окружение — браузер.
                                                    0
                                                    так или иначе он базируется на событиях и нужна инверсия контроля

                                                    Это само по себе очень важная концепция, которую, как я думаю, надо преподавать. Уж для GUI или ещё для чего — не важно.

                                                      0
                                                      В моём курсе она встроена в работу с сетью и события подключений и новых данных для чтения. Так проще пройти путь от блокирующихся операций на низкоуровневых сокетах, через активное ожидание неблокирующихся, к событийному циклу, инверсии и колбекам. Ну, а дальше только корутины. Пока что эта цепочка мне кажется полезнее интерактивных кнопочек.
                                                    0

                                                    Я, помнится, в детстве игрался с Visual Basic 6.0.
                                                    Можно сделать что-то полезное для себя. Но как сделаешь это полезное, возникает ("Блин! Ещё сковородка!") проблема, как для этого полезного адекватный GUI набросать, и какой он — адекватный GUI.
                                                    И начинаешь пробовать… и так, и этак, вот тут не умещается, а тут — концептуально не то… Обычно это занятие так утомляло, что весь проект забрасывался.


                                                    Позже я стал предпочитать творить простые DSL, но это было позже.


                                                    Вот например, писал я калькулятор для векторов, и гадал как сделать ввод и вывод. Кончилось тем, что нет ни чего лучше, чем xi+yj+zk в строковом поле.

                                                0
                                                Очень интересно! Респект!
                                                «Нужен промежуточный контроль успеваемости».
                                                О, да! По причине наличия этого контроля ИМХО наша школа эффективнее ВУЗов.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое