У меня есть математическое образование — просмотр статей в Википедии расставил вещи более по местам в моей голове (после состояния лёгкого сумбура, вызванного чтением заметки). Вроде бы вектроное произведение векторов входит в школьный курс геометрии (да, оно ведь и в школьном курсе физики должно использоваться), я бы на месте автора подключил соответствующие ассоциативные связи ранее при изложении.
Спасибо за информацию! Стало любопытно, приладил ли кто-либо к Taskflow couroutine синтакс. Готового не нашёл, но должно быть не сложно (по стопам std::future), если буду экспериментировать с Taslflow, попробую.
А не попадалась ли вам вот эта книга: www.state-machine.com/psicc («Practical Statecharts in C/C++») — старая, но довольно любопытная. Автор разработал свою библиотеку для реализации иерархических FSM (предыдущее издание называлось «Hierarchical State Machines in C/C++»), программируя для embedded-устройств (GPS, как мне помнится).
Спасибо и вам! При случае (если вам захочется) можно обсудить, так ли уж магичны смартпойнтеры (после того, как вызовы delete в деструкторах / завершениях функции начнут казаться студентам чем-то, заслуживающим обобщения как переиспользуемый, один раз реализованный «паттерн автоматического управления памятью в C++») и как объявлять функцию так, чтобы её взаимоотношения на счёт владения объектами с вызывающим кодом были ясны уже из объявления, без необходимости заглядывания в реализацию — но это уже C++-специфично, к вашему курсе, вероятно, плохо подойдёт.
Вы правы, в курсе по ООП лучше использовать Java, C#. Однако, если вы выбрали C++, пожалуйста, не демонстрируйте студентам код от преподавателя с ошибками в управлении памятью. В вашем первом примере (с беззаботной по части управления памяти передачей ответственности в DivisionChecker)
queue = new DivisionChecker(i, queue);
классическая, учебниковая утечка памяти (вызывающий код, вероятно, предполагает передачу владения старого queue в новый экземпляр DivisionChecker, который к этой неожиданной для него дополнительной задаче относится несколько беззаботно). Можно использовать как простую задачу на зачете или разогревный вопрос на интервью.
Здравствуйте, я хотел бы добавить свой комментарий в этом обсуждении исключительно потому, что вы показываете этот код студентам (ну и здесь вы пометили материал как Tutorial). Пожалуйста, потратьте какое-то количество времени на прочистку — на благо вашим студентам и человечества в целом. Используйте std::unique_ptr вместо T* там, где структура данных владеет объектом T (и, в целом, постарайтесь избегать * по возможности, используйте &). Используйте nullptr вместо NULL (в объявлении чистых виртуальных методов пишите "= 0", не "= NULL"). Определитесь, как вы обозначаете перекрытие вирутального метода в наследующем классе (я бы однозначно рекомендовал override — у вас в коде это ключевое слово отсутсвует, а virtual то есть, то нет). Используйте !X вместо X == false.
Про «абстракцию указатель на указатель» — может оказаться опасной педагогическая затеей, на мой взгляд, при отсутствии базовых понятий об управлении памятью. Работая с аллоцируемой в куче памятью на C++, прежде всего, учите пользоваться std::unique_ptr (плюс std::make_unique — чтобы в коде решения задачи не светились не только явные delete, но и явные new) и & ссылками с первого дня. Окупится сторицей. Если нужен дополнительный материал для пытливых студентов, дайте им std::shared_ptr (c std::make_shared) и настоятельно отговаривайте от использования «голых» C указателей, new, delete.
Отдельно номинативная и отдельно структурная типизация есть из коробки также в Nim — это более молодой (в сравнении с OCalm) язык, компилируемый в C, С++, JavaScript. Структурные типы (tuple) и номинативные типы (object) в Nim довольно унифицированы в плане синтаксиса. Структурные типы предоставляют больше удобств, изящно сочетающихся с структурной типзацией.
Про ваш случай с бойлерплейт-кодом на C# — возможно, продуманное применение Source Generators могло бы ситуацию улучшить (я редко прогаммирую на C#, но при случае попробую новую фичу, плюс record types).
Да, и поскольку F# — своебразный порт OCalm на .NET, скорее всего, вы увидите там типизацию в стиле OCalm (на вскидку не могу уверенно сказать, помню только, что record типы в F# есть давным-давно, тут C# догоняет F#).
KD637 в ваш перевод просочилась довольно забавная ошибка. В оригинале указано BB(2) = 6 и BB(3) = 21 (а не 107, как в вашем переводе) — и не указано BB(4), за этим знанием надо обратиться к статье 1983го года… Чтобы узнать, что BB(4) = 107! Так вот откуда взялось неверное значение BB(3)! :)
Я так понял, внутриполитическая логика была такая: партия / движ переписать приложения с нуля заполучило мощного союзника — отдел iOS — но при условии того, что переписывание для iOS будет на Swift. Сюжетная линия, что Android-приложение тоже переписывалось с нуля, провисла, поскольку автор не в отделе Android работал. Далее, предполагаемая логика отдела iOS: а) рано или позно переходить на Swift надо, почему не воспользоваться моментом; б) Swift — современный модный хайповый язык, приобретаемые навыки перспективны, возможности привлечения молодых программистов лучше.
Кстати руководству пункты а) и б) могут быть вполне понятны, они головную боль перетерпят.
Загляните по ссылке в заголовке поста. Блог автора (4 записи) плюс краткая информация о нём (включая фотографию) рисуют мне следующий образ. Молодой человек работает в геймдеве над игровым движком, его интересы сосредоточены вокруг перформанса. В примерах кода он использует стиль чистого C. Аргументирует в эту сторону (например, цикл по C-массиву, представленному указателем, ему милей, чем использование стандартной библиотеки C++), вплоть до отказа использования не только стандартной библиотеки, но и общепринятых C++ парадигм, например RAII. Ссылается на видео с CppCon 2014, посвящённого Data Oriented Design и чужие блоги (я планирую посмотреть и то и другое). Возможно, он предполагает, что его читатели, также как он, работают над приложениями, в которых перформанс — критичен, а безопасность получающегося кода и скорость разработки — нет. Мне его рассуждения не показались убедительными. Если кому-любо интересно, я бы продолжил после ознакомления с материалами по ссылкам из записей этого блога.
Поверхностно ответ на «Структурное программирование? Функциональное?» — скорее ближе к структурному.
Я регулярно думаю о частной проблеме — человеческий, но формализованный язык для общения с самим собой (ладно с ним, с остальным человечеством). Переносимость идей, алгоритмов через моды / синтакс разных ЯП / изменения в синтаксе даже одного ЯП (мой ЯП — C++, он стал динамичнее меняться в последние лет 15). Идеи AOP, DSL мне лично нравятся и для меня лично они адекватны проблеме. Далее, я — довольно типичный «опытный программист со стажем», адекватность для меня что-то значит и для остального человечества. Это я просто в антитезу вашему (понятному мне) скепсису.
Подумайте над идеями, как это исправить «правильными» системами поиска по исходному коду. Которые завоюют мир, а вы, их автор, будете сами себе платить зарплату. Шутка. Я вижу (поверхностно, конечно) ваш психологический профиль, это не ваш метод. Ваш метод — сбросить пар на хабре, продолжить комфортно получать зарплату, где получаете. Я то же так делаю, но не сбрасываю пар на хабре.
Гипотеза: дело в том, что первые пользователи C++ были C программисты, экономили байты исходного кода (кроме того, замечательная более поздняя идея делать this. (this-> на C++, мне лично сама -> противна из-за nullptr dereferencing) была придумана более поздно, в языке Java. Так сложилось, короче. C++ более старый, логичнее задуматься о том, почему и чем идея с this. (Java, C#), увеличивающая многословность, количество ударов пальцами по клавиатуре, правильная и полезная. Я не подвергаю эту идею сомнению, хорошая идея, но не универсальная. Есть другие идеи, точки зрения, инструменты проверки соответствия кода оным.
Удивительно, как много созидательной энергии, увы, тратится на форматирование, соглашения о наименованиях, такие мелкие штуки, которые Компьютер должен делать (и делает) проще для мыслителей-программистов. Однако, у мыслителей-программистов есть некоторая проблема с приоретизацией, реальная проблема — человеческий мозг хватается за мелкие штуки первым делом, ему проще выполнить рутинную работу по переформатированию, переименованию, расставлению скобочек и запятых красивенько так — и это на подсознательном уровне. При том, что Компьютер сделает всё это ОК за миллисекунды.
Мозгу проще и приятнее заниматься этим (а не реальной работой, требующей более сильного напряжения творческих сил), это вроде бы установленный медицинский факт.
Фантастическая (но реализуемая, и не слишком сложно) идея — иметь локальную конфигурацию «идеального» форматирования и схемы наименования кода, плюс наиболее популярные вариативные проекции в repo для поиска на любой вкус.
Пример реализации: автор(ы) языка Nim забил(и) (в основном) на различия CamelCase snake_case nocase bAdCaSe в наименованиях. Хороший пример послать паразитную проблему подальше, не идеальный (в идеале в проекте есть спеллчекер в идентификаторах и правильная конверсия в CamelCase, snake_case, nocase по настройкам индивидуального разработчика — плюс строгое выпалывание bAdCaSe, конечно).
Слабое место — поиск, но это технически решаемая проблема. Интересный комментарий выше — про полезность минимального Hungarian вроде "_" или «m_» префиксов, теперь уже из-за удобств IDE. С чего я начну новую строку моего идеального кода? Первый элемент намеренья обозначен довольно рудиментарным префиксом, а там уже — любимая мозгом рутинка, как в компьютерную игрушку играешь. Все довольны (главное, мозг :) ).
«Пока я не знаю, что с этим делать» — по-моему, описанные вами инструменты могут быть полезными для создания учебных материалов. Вспомнился сайт explorabl.es («Explorable Explanations») — я довольно бегло его просматривал, но, как мне помнится, некоторые представленные там инструменты для создания интерактивных обучающих материалов используют модель блокнота. У меня с работой пересечений мало (я программист), не освоил, но любопытно из-за связи с любительской педагогикой (математические и программистские кружки для школьников). Спасибо за статью!
Не смотрели ли вы на то, насколько сложно дополнить парсер (в выбранном вами стеке) реализацией базового IDE-плагина (опять же, соответствующего вашему стеку)? Например, если вы используете IDE, поддерживающую Language Server Protocol (LSP), реализация LSP в каком-то объёме может улучшить usability вашего DSL.
Предложение по стилистической коррекции фрагмента «Обслуживание многоразовой ступени заняло всего 51 день. Это больше предыдущего рекорда почти на две недели.» «Больше» здесь неправильно, правильно «Это лучше предыдущего рекорда почти на две недели» (или «короче» — поскольку длительность обслуживания сократилась на две недели, не увеличилась).
К примеру, как раз взгляд на математику как на дисциплину, оперирующую логическими построениями, сформировался в относительно недавнее историческое время (меньше двух веков) в результате… «смены научных парадигм»? Вы можете спорить, что это не было «сменой научных парадигм», предлагать другой термин — тем не менее, процессы, похожие на смены научных парадигм (лучше всего иллюстрируемые примерами из других наук) происходили и происходят и в математике тоже. Приведу небольшой частный пример несостоявшейся смены научных парадигм в математическом анализе (ну или по крайней мере в преподавании математического анализа) — так называемый «нестандартный анализ». Он предлагает использование расширенной числовой прямой, в которой бесконечно малые величины — реальны (а не являются языковой конструкцией, скрывающей довольно громоздкий дельта / эпсилон аппарат «стандартного» анализа). Набор доказываемых фактов такая смена аксиоматики не меняет, но доказательства и преобразования становятся значительно легче и понятнее. Не прижился (критики внедрения этого подхода в преподавании взяли верх, насколько я понял), но влияние оказал (в частности, прояснил вопрос, как математикам прошлых веков — до появления строгого логического базиса стандартного анализа — могли добиваться верных результатов, оперируя мутными понятиями вроде «бесконечно малые величины», и не надоказывать ложных теорем).
ru.wikipedia.org/wiki/%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F_%D0%B0%D0%BB%D0%B3%D0%B5%D0%B1%D1%80%D0%B0
en.wikipedia.org/wiki/Exterior_algebra
Английская статья — значительно более обстоятельная.
У меня есть математическое образование — просмотр статей в Википедии расставил вещи более по местам в моей голове (после состояния лёгкого сумбура, вызванного чтением заметки). Вроде бы вектроное произведение векторов входит в школьный курс геометрии (да, оно ведь и в школьном курсе физики должно использоваться), я бы на месте автора подключил соответствующие ассоциативные связи ранее при изложении.
queue = new DivisionChecker(i, queue);
классическая, учебниковая утечка памяти (вызывающий код, вероятно, предполагает передачу владения старого queue в новый экземпляр DivisionChecker, который к этой неожиданной для него дополнительной задаче относится несколько беззаботно). Можно использовать как простую задачу на зачете или разогревный вопрос на интервью.
Дайте знать в случае, если вам нужны пояснения к этим рекомендациям: я попробую их предоставить (ссылаясь, например, на C++ Core Guidelines: isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html).
Про «абстракцию указатель на указатель» — может оказаться опасной педагогическая затеей, на мой взгляд, при отсутствии базовых понятий об управлении памятью. Работая с аллоцируемой в куче памятью на C++, прежде всего, учите пользоваться std::unique_ptr (плюс std::make_unique — чтобы в коде решения задачи не светились не только явные delete, но и явные new) и & ссылками с первого дня. Окупится сторицей. Если нужен дополнительный материал для пытливых студентов, дайте им std::shared_ptr (c std::make_shared) и настоятельно отговаривайте от использования «голых» C указателей, new, delete.
nim-lang.org/docs/tut1.html#advanced-types-objects
Про ваш случай с бойлерплейт-кодом на C# — возможно, продуманное применение Source Generators могло бы ситуацию улучшить (я редко прогаммирую на C#, но при случае попробую новую фичу, плюс record types).
Да, и поскольку F# — своебразный порт OCalm на .NET, скорее всего, вы увидите там типизацию в стиле OCalm (на вскидку не могу уверенно сказать, помню только, что record типы в F# есть давным-давно, тут C# догоняет F#).
Кстати руководству пункты а) и б) могут быть вполне понятны, они головную боль перетерпят.
Поверхностно ответ на «Структурное программирование? Функциональное?» — скорее ближе к структурному.
Мозгу проще и приятнее заниматься этим (а не реальной работой, требующей более сильного напряжения творческих сил), это вроде бы установленный медицинский факт.
Фантастическая (но реализуемая, и не слишком сложно) идея — иметь локальную конфигурацию «идеального» форматирования и схемы наименования кода, плюс наиболее популярные вариативные проекции в repo для поиска на любой вкус.
Пример реализации: автор(ы) языка Nim забил(и) (в основном) на различия CamelCase snake_case nocase bAdCaSe в наименованиях. Хороший пример послать паразитную проблему подальше, не идеальный (в идеале в проекте есть спеллчекер в идентификаторах и правильная конверсия в CamelCase, snake_case, nocase по настройкам индивидуального разработчика — плюс строгое выпалывание bAdCaSe, конечно).
Слабое место — поиск, но это технически решаемая проблема. Интересный комментарий выше — про полезность минимального Hungarian вроде "_" или «m_» префиксов, теперь уже из-за удобств IDE. С чего я начну новую строку моего идеального кода? Первый элемент намеренья обозначен довольно рудиментарным префиксом, а там уже — любимая мозгом рутинка, как в компьютерную игрушку играешь. Все довольны (главное, мозг :) ).