Использование С/С++ тоже не всегда способствует экономии ресурсов.
Нпр., недаром появление общедоступных многоядерных CPU вызвало появление TBB, которое не очень экономично по скорости.
С большим интересом прочел статью и все комметы (на данный момент). ИМХО сделано много верных замечаний про зоопарки (платформ, систем, компиляторов), сказано много правильных слов про необходимость знать стандарты языка, особенности железа и компилятора, на котором работаешь. Но как быть с переносом кода? Где-то, когда-то, кто-то на антикварных сейчас железе, системе, компиляторе (ЖСК) написал нужный мне код, но я могу не знать то ЖСК, тогда вероятно, что используя тот код отгребу кучу багов, которые мне трудно будет фиксить. Чем дальше в лес — тем больше дров: зоопарк ЖСК растет. Для долговременной преемственности кода нужен достаточно строгий язык типа стандартного Паскаля. Пусть ОО Паскаля. Конечно, за все приходится платить. Си гораздо более гибкий чем Паскаль, и даже турбо, и даже Дельфи. Многие трюки будут невозможны. Но м.б. стоит заплатить отказом от трюков? А когда они очень нужны, то тогда и только тогда использовать Си и/или ассемблер?
И отлично! Если они не будут пытаться делать и таких плохих вещей, как на хост пересесть (а это возможно?), то и пусть себе на ВМ (т.е. в гостевой ОС) ничего плохого не делают. А после перезагрузки эту ВМ с вирусами сотру и новую запущу: скопировать ВМ — мгновенное дело, каждый запуск можно свежую копию ставить.
Ваш симулятор только он-лайн можно использовать? А скачать его можно? Исходный код не открываете? Не хотите сделать фильтр для Фотошопа, чтобы такие поля на картинки накладывать?
А если какие тривиальные вирусы даже и ловятся сигнатурами, то всегда защита будет отставать: сначала появляется новый вирус, а уже потом обновление защиты с сигнатурой этого вируса. Между этими событиями проходит время, которое может быть достаточным для злоумышленника. Конечно, для атаки на несколько месяцев такой вирус не подходит.
Существует мнение, что использование виртуальной машины может спасти от многих новых неизвестных антивирусам вирусов. А в статье (если правильно понял) противоположное решение. Почему? В Microsoft считают, что ВМ не спасает?
Да! Ведь могут быть не только баги алгоритма, но и баги реализатора, если он не автор. Ведь практически каждый нетривиальный мат.текст содержит множество смысловых сокращений, иначе бы объем такого текста был бы огромным. Т.о. у реализатора, как правило, есть много возможностей не правильно понять автора и внести баги реализации. Понятно, что реализатору отлавливать такие баги часто бывает сложнее, чем баги алгоритма (свои ошибки увидеть труднее, чем чужие). Хорошо бы издания по CS, публикующие новые алгоритмы, внесли в правила для авторов требование: обязательно вместе с рукописью статьи предоставлять работающий код. Пока такое правило не стало повсеместным, авторам алгоритмов нужно самим понять, что, сделав работающий код, они сделают свой алгоритм гораздо привлекательнее. Ведь каждый автор хочет, чтобы его алгоритм использовали как можно чаще. (Надеюсь, что эта простая мысль будет полезной и для авторов Хабра :) )
Главное что бы все стороны могли разговаривать на понятном друг другу языке :)
Верно. Владение MatLab и подобным — это не всегда бывает, но если хотя бы на уровне Виртовского Паскаля математик может, что-то простое ученическое вроде Ханойских башен написать, то и с ним разговаривать гораздо легче. Хочется верить, что в недалеком будущем все математики будут знать программирование хотя бы на уровне Ханойских башен :)
PS Как и многим, мне часто приходится искать алгоритмы в литературе/в сетке для реализации в программе. При прочих равных выбираю алгоритм, который был реализован, пусть даже на Алголе-60. Перевести на современный язык и приспособить под свою задачу — это обычно не сложно, главное — гарантия, что автор настолько хорошо продумал алгоритм и предусмотрел возможные сложности, что смог его реализовать в виде хоть как-то работающей программы. К сожалению, вредная традиция публиковать новый алгоритм без программной реализации очень живуча. Надеюсь, что в недалеком будущем ее изживут — это будут большой прогресс для IT.
А как Вы описывали эти алгоритмы? Традиционным мат.языком, т.е. слова естественного языка+ мат.формулы? — Да, и так можно. Нпр., Евклид и Эратосфен свои знаменитые алгоритмы без помощи псевдокода описали, но, нпр., уже школьная задачка преобразования арифметических выражений в польскую нотацию с применением сложной рекурсии без псевдокода выглядит громоздко и ненаглядно даже не для школьника. А ведь чтобы правильно закодировать, нужно точно понять, что хотел сказать автор алгоритма.
Верно. Мне много приходится работать с математиками, есть которые пишут хороший код, а есть, которые и псевдокод записать не могут, хотя работают над алгоритмами и очень успешно. В общем, у математика и у «кодера» разное мировосприятие. Им не просто найти общий язык.
Применительно к обсуждаемой теме знания и навыки математики я бы разделил на два типа: «практическая» и «теоретическая» математика (по аналогии с «пркладная» и «чистая»). В практической не нужно доказывать теоремы. Т.е. если можно ограничиться готовыми алгоритмами, плюс к этому алгоритмами, не требующими сложных доказательств корректности и теоретических оценок трудоемкости, плюс к этому эвристическим алгоритмами — нужна практическая математика. В ней я бы выделил следующие особо важные для каждого программиста разделы.
Азы теории вычислительной сложности: на проблему тысячелетия P =? NP с такими знаниями замахиваться не стоит, но понимать, чем принципиально экспоненциальный по времени выполнения в наихудшем случае алгоритм отличается от полиномиального нужно каждому. Основы теории графов алгоритмический подход — списки (стеки, очереди) и деревья — это графы. Комбинаторика. Линейная алгебра, особо матричная алгебра. Нужно знать еще и отличия целого, действительного и рационального числа и т.д. Теорему Пифагора нужно знать, а вот ее доказательство, даже на школьном уровне, подавляющему большинству программистов знать не требуется.
Можно еще добавить разделы, но уже на приведенном примере виден принцип — широкие, но «поверхностные» с точки зрения чистого математика знания. — Они ведь считают, что если не можешь доказать теорему, то не знаешь ее. А тут и многих теорем знать не нужно — только некоторые практически значимые. В той же теории графов, нпр., столько замысловатых теорем: чтобы во всех разобраться надо потратить очень много сил и времени. Так вот очень многим программистам это не надо — вместо этого те же силы и время лучше употребить на практическое поверхностное изучение другой полезной мат. области. Но и при таком подходе математика столь огромна, что всю охватить жизни не хватит.
Специально употребляю термин «практическая математика» вместо более привычного «прикладная», т.к. многие исследования по прикладной математике требуют доказательств очень непростых теорем. Такие исследования не для обычных программистов. Это ИМХО нормальное разделение труда, и пусть каждый занимается своим делом.
Понятие угол, прямой угол существуют только у геометров. в другой области деятельности нет углов
Вот это новость! Даже ребенок-дошкольник понимает, если ему сказать: «встань в угол».
Я бы сказал, что математика дает нам инструмент для моделирования.
Есть четкое понятие мат.модель, а бывают другие модели, нпр., модель самолета из дерева для испытаний в аэродинамической трубе.
ООП предназначено для моделирования кода
Т.е. код — прототип? Но нетривиальная модель не тождественна прототипу. Получается противоречие: программа не тождественна коду, на котором написана, т.е. не тождественна самой себе!
Потому что наследование в обычном мире и наследование в мире ООП отличаются.
Чем? В обычном мире наследуются свойства и методы, и в ООП наследуются свойства и методы. Ребенок подражает родителям и наследует их методы поведения (как хорошие, так и плохие), а от рождения он может унаследовать родительские свойства, нпр., рыжие волосы.
Понятие класса в мире и понятие класса в ООП — тоже отличаются
Чем? Нпр., в мире наблюдается класс любителей риторики. Экземпляры этого класса используют одинаковые риторические методы, чтобы «наводить тень на плетень» :)
Насчет затянутых книг и фильмов — это только ваше мнение
Довольно часто такое мнение высказывают не только многие зрители и читатели, но и проф. критики и рецензенты.
Насчет игр со множеством концовок, я не вижу противоречий
Я не говорил про противоречия.
вовлечь можно во все
Интересно, что термин «вовлечь» встречается в статьях про игры, но не встречается (или почти не встречается) в статьях про худ. литературу, которая упоминается в обсуждаемой статье. Почему бы это?
Появляется непреодолимый страх, когда ты видишь, что сейчас будет последняя серия, чувствуешь конец фильма, видишь, что это последняя глава или физически ощущаешь, что приближаешься к последним страницам книги.
А здесь разрешите не согласиться. Бывают затянутые книги и фильмы, где с нетерпением начинаешь ждать «когда же наконец это кончится?»
С выводами согласен. Однако ИМХО стоит добавить, что иногда в играх бывает несколько вариантов концовок. А если цель игры — набрать больше очков, то, пройдя игру первый раз, игрок может попробовать переиграть часть игры для улучшения результата.
ИМХО бывает, когда нужен творческий подход к задаче, а бывают рутинные задачи. От типа задачи может сильно зависеть оптимальный распорядок дня, недели, месяца и т.д. Если творческая задача сложная и интересная, человек осознанно и бессознательно думает о ней постоянно. Нпр., описано много случаев когда ученые делали открытия во сне. Хорошо думается по дороге на работу и с работы, если не надо торопиться. Поэтому стоит выходить/выезжать вовремя :) А вот про рутинные рабочие дела вне работы ИМХО думать вредно и надо взять за правило выйдя из конторы, редакции, лаборатории и т.д. тут же забывать про эти дела до следующего рабочего дня. Но в творческих работах часто бывает не все гладко. Важно вовремя увидеть, что буксуешь. И тут надо суметь переключится на другую работу или просто отключиться от проблемы. Хорошо если поможет прогулка, пробежка, тренировка, а если все равно продолжаешь думать о работе, т.е. буксовать? Тогда нужны занятия, переключающие мысли — это может быть интересная книга, фильм, компьютерная игра. Иногда стоит сократить рабочее время, чтобы качественно переключиться и отдохнуть. — Часто после этого проблема неожиданно очень быстро решается. Но в общем стоит отметить, что творческая работа — вредная, т.к. часто заставляет менять режим.
Здравствуйте!
Пользуясь случаем, во-первых хочу поблагодарить за удобную программу (FineReader), а во-вторых подкинуть идею вашим разработчикам. Для математических текстов (в том числе и текстов по CS, нпр., с описанием алгоритмов) очень часто используют TeX/LaTeX. Но иногда текст доступен только в pdf. Вот бы сделали возможность распознавать с мат. формулами в TeX/LaTeX, а то, нпр., часто бывает необходимость цитировать мат.тексты.
Комический эффект, основанный на хаосе, – это всегда ставка на непредсказуемость.
Тут ИМХО стоит добавить, что «рандом» часто добавляется для «усиления» AI игры. Важно не переборщить, чтобы прохождение не превратилось в сплошной save/load.
Нпр., недаром появление общедоступных многоядерных CPU вызвало появление TBB, которое не очень экономично по скорости.
Применительно к обсуждаемой теме знания и навыки математики я бы разделил на два типа: «практическая» и «теоретическая» математика (по аналогии с «пркладная» и «чистая»). В практической не нужно доказывать теоремы. Т.е. если можно ограничиться готовыми алгоритмами, плюс к этому алгоритмами, не требующими сложных доказательств корректности и теоретических оценок трудоемкости, плюс к этому эвристическим алгоритмами — нужна практическая математика. В ней я бы выделил следующие особо важные для каждого программиста разделы.
Азы теории вычислительной сложности: на проблему тысячелетия P =? NP с такими знаниями замахиваться не стоит, но понимать, чем принципиально экспоненциальный по времени выполнения в наихудшем случае алгоритм отличается от полиномиального нужно каждому. Основы теории графов алгоритмический подход — списки (стеки, очереди) и деревья — это графы. Комбинаторика. Линейная алгебра, особо матричная алгебра. Нужно знать еще и отличия целого, действительного и рационального числа и т.д. Теорему Пифагора нужно знать, а вот ее доказательство, даже на школьном уровне, подавляющему большинству программистов знать не требуется.
Можно еще добавить разделы, но уже на приведенном примере виден принцип — широкие, но «поверхностные» с точки зрения чистого математика знания. — Они ведь считают, что если не можешь доказать теорему, то не знаешь ее. А тут и многих теорем знать не нужно — только некоторые практически значимые. В той же теории графов, нпр., столько замысловатых теорем: чтобы во всех разобраться надо потратить очень много сил и времени. Так вот очень многим программистам это не надо — вместо этого те же силы и время лучше употребить на практическое поверхностное изучение другой полезной мат. области. Но и при таком подходе математика столь огромна, что всю охватить жизни не хватит.
Специально употребляю термин «практическая математика» вместо более привычного «прикладная», т.к. многие исследования по прикладной математике требуют доказательств очень непростых теорем. Такие исследования не для обычных программистов. Это ИМХО нормальное разделение труда, и пусть каждый занимается своим делом.
Т.е. код — прототип? Но нетривиальная модель не тождественна прототипу. Получается противоречие: программа не тождественна коду, на котором написана, т.е. не тождественна самой себе!
Чем? В обычном мире наследуются свойства и методы, и в ООП наследуются свойства и методы. Ребенок подражает родителям и наследует их методы поведения (как хорошие, так и плохие), а от рождения он может унаследовать родительские свойства, нпр., рыжие волосы.
Чем? Нпр., в мире наблюдается класс любителей риторики. Экземпляры этого класса используют одинаковые риторические методы, чтобы «наводить тень на плетень» :)
Я не говорил про противоречия.
Интересно, что термин «вовлечь» встречается в статьях про игры, но не встречается (или почти не встречается) в статьях про худ. литературу, которая упоминается в обсуждаемой статье. Почему бы это?
А здесь разрешите не согласиться. Бывают затянутые книги и фильмы, где с нетерпением начинаешь ждать «когда же наконец это кончится?»
С выводами согласен. Однако ИМХО стоит добавить, что иногда в играх бывает несколько вариантов концовок. А если цель игры — набрать больше очков, то, пройдя игру первый раз, игрок может попробовать переиграть часть игры для улучшения результата.
Пользуясь случаем, во-первых хочу поблагодарить за удобную программу (FineReader), а во-вторых подкинуть идею вашим разработчикам. Для математических текстов (в том числе и текстов по CS, нпр., с описанием алгоритмов) очень часто используют TeX/LaTeX. Но иногда текст доступен только в pdf. Вот бы сделали возможность распознавать с мат. формулами в TeX/LaTeX, а то, нпр., часто бывает необходимость цитировать мат.тексты.