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 день. Это больше предыдущего рекорда почти на две недели.» «Больше» здесь неправильно, правильно «Это лучше предыдущего рекорда почти на две недели» (или «короче» — поскольку длительность обслуживания сократилась на две недели, не увеличилась).
К примеру, как раз взгляд на математику как на дисциплину, оперирующую логическими построениями, сформировался в относительно недавнее историческое время (меньше двух веков) в результате… «смены научных парадигм»? Вы можете спорить, что это не было «сменой научных парадигм», предлагать другой термин — тем не менее, процессы, похожие на смены научных парадигм (лучше всего иллюстрируемые примерами из других наук) происходили и происходят и в математике тоже. Приведу небольшой частный пример несостоявшейся смены научных парадигм в математическом анализе (ну или по крайней мере в преподавании математического анализа) — так называемый «нестандартный анализ». Он предлагает использование расширенной числовой прямой, в которой бесконечно малые величины — реальны (а не являются языковой конструкцией, скрывающей довольно громоздкий дельта / эпсилон аппарат «стандартного» анализа). Набор доказываемых фактов такая смена аксиоматики не меняет, но доказательства и преобразования становятся значительно легче и понятнее. Не прижился (критики внедрения этого подхода в преподавании взяли верх, насколько я понял), но влияние оказал (в частности, прояснил вопрос, как математикам прошлых веков — до появления строгого логического базиса стандартного анализа — могли добиваться верных результатов, оперируя мутными понятиями вроде «бесконечно малые величины», и не надоказывать ложных теорем).
Извините, решил написать реплику, поскольку ваш оппонент не ответил. В студенческие годы я интересовался темой альтернативных аксиоматик, например, есть разделы математики, изучающие последствия удаления или замены некоторых «стандартных» аксиом, например, аксиомы выбора в аксиоматике теории множеств, или логического закона исключения третьего. Так вот, в моём понимании собственно изобретение неевклидовых геометрий в XIX веке было существенным, но только фрагментом «смены парадигм» в математике, растянувшейся на многие десятилетия; о «революции» можно наверно говорить только в применении к конкретному разделу математики, геометрии. Лобачевский и другие авторы неевклидовых геометрий дали неожиданные ответ на трудный вопрос в геометрии: действительно ли постулат о единственности линии, параллельной данной и проходящей через данную точку, является аксиомой? Геометры прошлого строили доказательство этого постулата (пятого постулата «Начал» Евклида), базирующееся на остальных аксиомах геометрии (таким образом низводя его статус от аксиомы к теореме), но позднее в этих доказательствах обнаруживали ошибки. Работы Лобачевского (и других авторов) продемонстрировали независимость пятого постулата от других аксиом — посредством построения моделей альтернативных аксиоматик, в которых пятый постулат заменен одним или другим противоречащим ему утверждением (или «несколько», как написано у вас — гиперболические геометрии — или «ни одной» — эллиптические геометрии).
Эта частная геометрическая история (заметьте, ваша фраза «в принципе таких параллельных прямых можно провести несколько» относится не к евклидовой геометрии, её никто не опровергал — она относится к альтернативным аксиоматикам, описывающим не евклидову плоскость / пространство, а другой математический объект, в котором определённое подмножество фактов евклидовой геометрии сохранено, но другое — заменено или удалено) подтолкнула интерес к построению и изучению формальных аксиоматических систем в других областях математики.
Вы правы насчёт 4-х: в этой схеме испытаний частота события и среднее время ожидания события — величины взаимно обратные (1/4 и 4). Как это проверить? Можно повозиться с простой алгеброй (считать суммы арифметических прогрессий), но можно поступить проще. Давайте назовём искомую величину — среднее количество проверок, включая последнюю, успешную проверку — X. При первой проверке с вероятностью 1/4 мы имеем количество проверок 1 (удача при первой попытке!) и с оставшейся вероятностью 3/4 мы имеем количество проверок 1 (неудача при первой попытке) плюс X (ситуация после первой попытки ровно такая же!):
Спасибо, было интересно почитать. Вам интересно было бы немного поитерировать над получившимся кодом? В первую очередь я бы предложил избавиться от C-style вызовов new и delete, используя, скажем, std::vector вместо C массивов и std::owning_ptr вместо C указателей на Node. Объём вашего кода сократится: например, вам не нужно будет кодировать HashTable::~HashTable, компилятор прекрасно справится сам с этой задачей (HashTable::HashTable тоже сократится благодаря дефолтовому конструктору std::owning_ptr, вызовы которого сгенерирует компилятор). Аналогично, сократятся Resize и Rehash, каждый на несколько строк в конце (автоматический вызов деструктора локального std::vector-а, свопнутого с основным, позаботится об освобождении памяти). Код будет не только короче, но и дешевле в долговременной поддержке. Производительность не должна измениться.
Говоря о производиетльности — имеет смысл поднять служебные поля на уровень основного массива, чтобы для обращения за ними не надо было бы разыменовывать указатель. Правда, при этом увеличится расход памяти. Мне было бы любопытно рассмотреть последствия в конкретных числах, а вам?
Скажите, почему вы объявляете Decorator как struct, в то время как фактически это namespace? Мне такие struct-ы попадаются в старом коде, вероятно, написанном до появления namespace (сейчас попробовал найти, когда это произошло, и не нашёл — как будто фича namespace в C++ была всегда). Или вы планируете добавить не-static содержимое, или защищаете Decorator от сторонних добавлений?
Не уверен, каким образом поправкой перевода спровоцировал ваши претензии к автору оригинала именно в этой ветке обсуждения перевода. По сути — она не ставила целью написать внятную статью об авиастроительном бизнесе на почтенный сайт habr.com; напишите в The New Republic или Maureen Tkacik напрямую.
Кстати руководству пункты а) и б) могут быть вполне понятны, они головную боль перетерпят.
Поверхностно ответ на «Структурное программирование? Функциональное?» — скорее ближе к структурному.
Мозгу проще и приятнее заниматься этим (а не реальной работой, требующей более сильного напряжения творческих сил), это вроде бы установленный медицинский факт.
Фантастическая (но реализуемая, и не слишком сложно) идея — иметь локальную конфигурацию «идеального» форматирования и схемы наименования кода, плюс наиболее популярные вариативные проекции в repo для поиска на любой вкус.
Пример реализации: автор(ы) языка Nim забил(и) (в основном) на различия CamelCase snake_case nocase bAdCaSe в наименованиях. Хороший пример послать паразитную проблему подальше, не идеальный (в идеале в проекте есть спеллчекер в идентификаторах и правильная конверсия в CamelCase, snake_case, nocase по настройкам индивидуального разработчика — плюс строгое выпалывание bAdCaSe, конечно).
Слабое место — поиск, но это технически решаемая проблема. Интересный комментарий выше — про полезность минимального Hungarian вроде "_" или «m_» префиксов, теперь уже из-за удобств IDE. С чего я начну новую строку моего идеального кода? Первый элемент намеренья обозначен довольно рудиментарным префиксом, а там уже — любимая мозгом рутинка, как в компьютерную игрушку играешь. Все довольны (главное, мозг :) ).
Эта частная геометрическая история (заметьте, ваша фраза «в принципе таких параллельных прямых можно провести несколько» относится не к евклидовой геометрии, её никто не опровергал — она относится к альтернативным аксиоматикам, описывающим не евклидову плоскость / пространство, а другой математический объект, в котором определённое подмножество фактов евклидовой геометрии сохранено, но другое — заменено или удалено) подтолкнула интерес к построению и изучению формальных аксиоматических систем в других областях математики.
Кстати, вспомнил переводную книгу, изданную в СССР где-то в середине 80-х, «Математика: утрата определённости» Мориса Клайна, сейчас поищу — о, про неё даже заметка в Википедии: ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0._%D0%A3%D1%82%D1%80%D0%B0%D1%82%D0%B0_%D0%BE%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8 (интересная книга, насколько я помню).
X = 1/4 * 1 + 3/4 * (1 + X)
1/4 * X = 1
X = 4
Говоря о производиетльности — имеет смысл поднять служебные поля на уровень основного массива, чтобы для обращения за ними не надо было бы разыменовывать указатель. Правда, при этом увеличится расход памяти. Мне было бы любопытно рассмотреть последствия в конкретных числах, а вам?
«Если обнаружите в публикации трудности перевода или оформления, дайте знать.»
Вот здесь ошибка в переводе: "… в результате которого погибли его жена, сын, четырехлетняя дочь, девятимесячная дочь и свекровь" — тёща, не свекровь.