Что такое интеграл и для чего он нужен? Интеграл нужен для того, чтобы зная, как изменяется какой-то процесс, быстро понять, как именно он в итоге изменится. Например, зная скорость (изменяющуюся!) автомобиля, понять, как далеко он уедет за любое время. Или зная скорость (изменяющуюся!) вытекания воды из бочки, понять, как быстро она опустеет вся. А если скорость вытекания воды ещё и всегда зависит от того, сколько там сейчас воды, то именно для этого нужны дифференциальные уравнения. Это важно, потому что мы часто можем записать формулы/закон только для мгновенной скорости изменения чего-нибудь, а хотим по этому "мгновенному снимку" распознать весь процесс. По капле воды сделать вывод о существовании океана - это как раз про интегрирование.
Что такое производная и для чего она нужна? Производная нужна для того, чтобы имея всю историю изменения какого-то процесса узнать, как быстро он менялся в каждый момент времени. Например, зная объём (изменяющийся!) воды в баке в каждый момент времени, можем посчитать, с какой скоростью из него вытекала вода. Производные тоже важны (хоть и меньше, чем интегралы) потому, что с ними мы можем исследовать поведение какого-то процесса во времени и узнать самые важные "критичные" (экстремальные) точки. Например, имея запись координат автомобиля в каждый момент времени мы можем узнать, в какой момент он превысил скорость.
А при таком росте доли renewables, при котором ископаемых топлив тоже будет сжигаться больше и больше, их влияние на климат будет возрастать или убывать?
В смысле геометрии может быть и не имеют реальные сетки такого характера. Но если на сетку накладывается фильтр (типовая операция) отображения ячеек типа PORO > MEDIAN(PORO), то легко получится как раз 50% случайно заполненная сетка. Поэтому думаю, что такой критерий для тестирования оправдан!
Я не склонен преувеличивать свой ущерб вклад в их профессиональный путь. Думаю, они бы и без меня нормально работали по всяким яндексам, гуглам и фейсбукам, кто достоин. Да, вы всё правильно говорите, но в рамках бакалавриата у них просто нет времени на этот полноценный эволюционный путь. Приходится вот так, «на стероидах», отправлять в полёт с помощью катапульты. Предложите другой вариант? Что мне делать? У меня 14 лекций и 8 лабораторных работ, а дальше — открытый космос самообразования.
Я видимо не смог правильно свою мысль донести в предыдущем комментарии. Это не со мной нужно обсуждать, магичны ли смартпойнтеры :). Это надо придумать, что и как рассказывать конкретным студентам конкретного потока, которые в подавляющем большинстве еще не успели понять, почему функция вида void inc(int x) {x = x+1;} работает совсем не так, как функция void inc(int &x) {x = x+1;}. С этим бессмысленно спорить, это реальность, данная мне в ощущениях. Я вижу сплошь и рядом такую проблему при изучении программирования, что студенты пишут код как магические заклинания. То есть они понимают, что фраза «вингааардиум левиооооса» заставляет предмет взлететь, но почему так происходит — не понимают. И именно это меня не устраивает, я до этого докапываюсь и перевожу магию в инженерию. Но вынужден делать выбор, что я успею объяснить, а что нет. Поэтому стараюсь использовать только то, что для них (не всех вообще — а только моих студентов) будет здесь и сейчас инженерией, а не магией.
В этих предложениях, безусловно, всё правда, но тогда, возможно, легче просто использовать C# или java, тем более, что они его большей частью и используют там, где можно не использовать С++. Меня беспокоит, что умные указатели для студентов второго курса будут однозначно магией, а я этого категорически не хочу.
Я ж говорю, я в плюсах не умею, я в матлабе, питоне, в sql, в haskell и ещё в одном, что называть нельзя, чтобы не заминусовали :). Не стреляйте в пианиста, играет как умеет :). Мне бы уместить у людей в головах понимание абстракций уровня «указатель на указатель», и я уже сочту свою миссию исполненной :)
Знаете, я на лекциях (напомню, это второй курс, они только-только на первом курсе самим плюсам чуть-чуть типа научились) рассказываю многие вещи именно затем, чтобы они не стали ни жупелом, ни молитвой, а стали именно тем, чем являются — обычными техническими приёмами, которые постоянно будешь использовать, если работаешь с объектами. Чтобы человек на собеседовании не падал в обморок при словах «Template Method», а уверенно кривил губы: «Вы точно хотите этот примитивный приём обсуждать с такой помпой?». Так что цель в этом. Если надо тренироваться работе с объектами, то лучше это делать на не совсем тривиальных приёмах, а заодно и сразу прививку от хайпа на этой теме сделать. Если не впитал это с детства с молоком преподавателя матери, есть риск потом сделаться евангелистом :)
Да. Как известно, новичка оценивают по количеству строк, которые он добавляет для того, чтобы появилась новая функциональность. Профессионала оценивают по количеству строк, которые он удаляет для того, чтобы появилась новая функциональность :).
Несколько мыслей на тему сложности, на оригинальность и тем более истину не претендую:
1) Сложность кода растёт вместе со сложностью задачи, но неграмотный разработчик добавляет больше сложности в код, чем прибавилось сложности в задачу.
2) Не зря великие говорили, что если отладка сложнее написания кода, то не получится отлаживать код, который написал на пределе доступной тебе сложности. Но я бы сказал ещё, что грамотный разработчик не создаёт решения сложнее, чем на 90% от своей способности со сложностью справляться.
3) Нельзя сложные программные системы переписывать с нуля потому, что они тебе не нравятся своей сложностью. Если кто-то приходит к тебе и говорит «да тут у вас слишком сложно, мы напишем с нуля» — нельзя его к написанию подпускать, надо чтобы сначала он продемонстрировал, что старую систему срефакторить сможет. Если ты не можешь справиться с той сложностью, которая уже есть, методом постепенного рефакторинга, то когда начнешь писать сам — наворотишь сложность еще хуже и в итоге задачу не решишь. А всё почему? Потому что нельзя понять, что именно ты не понимаешь и недооценивашь, по определению.
4) Главное для опытного программиста — умение управлять сложностью. Обычно мы сложность только добавляем (нельзя же заниматься только рефакторингом), но горе тому, кто так до рефакторинга (по сути, упрощения!) и не доходит. Тогда вместо того, чтобы наводить порядок и упрощать, такой разработчик накручивает костыли на костыли и остановиться не может, потому что костыли писать проще. Со временем костыли писать становится всё сложнее и сложнее, но фишка в том, что в каждый момент времени написать очередной костыль хоть и всё сложнее и сложнее, но всё равно всегда проще, чем расчистить конюшни и навести порядок. И всегда есть эта иллюзия (?), что по причине дедлайнов оптимальное решение — писать костыли. Увы, это оптимальное решение в моменте, но очень неоптимальное в долгосрочной перспективе.
Не могу согласиться. Это не входит в рамки статьи, но если описать информационные сущности, их ключи и связи, структуру бд можно строить автоматически, потому что вариативности не остаётся. Разработать инфомодель, то есть описать предметную область — вот это ближе к искусству. Но к бд это отношения не имеет.
Спасибо, я подумаю об этом. Я в первую очередь думал о тех, кто только начинает потому что те, кто уже изучил нормальные формы испорчены безвозвратно, а их отсылка к страшным терминам будет только пугать (ну и отвлекать, если они пойдут читать их в википедию). В любом случае, у меня же нормальный курс, там есть дальше и определения, и нормальные формы. Я ещё не настолько радикализовался, чтобы нормальные формы совсем выбрасывать :)
Вы же сами понимаете, что тут «ну, не совсем» можно приписать практически к каждому абзацу :). Если раскрывать, что именно «не совсем», туториала не получится. Small moves, Ellie, small moves.
У меня тоже были такие случаи, и это в любом случае mission impossible. Поэтому да, тут проще описать то, что упомянуто, чем то, что не упомянуто. Ну так и я — только начал учебник писать :).
Лично я хочу, чтобы мои студенты не видели принципиальной разницы между x.foo() и foo(x), а использовали то, что удобнее здесь и сейчас.
Что такое интеграл и для чего он нужен? Интеграл нужен для того, чтобы зная, как изменяется какой-то процесс, быстро понять, как именно он в итоге изменится. Например, зная скорость (изменяющуюся!) автомобиля, понять, как далеко он уедет за любое время. Или зная скорость (изменяющуюся!) вытекания воды из бочки, понять, как быстро она опустеет вся. А если скорость вытекания воды ещё и всегда зависит от того, сколько там сейчас воды, то именно для этого нужны дифференциальные уравнения. Это важно, потому что мы часто можем записать формулы/закон только для мгновенной скорости изменения чего-нибудь, а хотим по этому "мгновенному снимку" распознать весь процесс. По капле воды сделать вывод о существовании океана - это как раз про интегрирование.
Что такое производная и для чего она нужна? Производная нужна для того, чтобы имея всю историю изменения какого-то процесса узнать, как быстро он менялся в каждый момент времени. Например, зная объём (изменяющийся!) воды в баке в каждый момент времени, можем посчитать, с какой скоростью из него вытекала вода. Производные тоже важны (хоть и меньше, чем интегралы) потому, что с ними мы можем исследовать поведение какого-то процесса во времени и узнать самые важные "критичные" (экстремальные) точки. Например, имея запись координат автомобиля в каждый момент времени мы можем узнать, в какой момент он превысил скорость.
А при таком росте доли renewables, при котором ископаемых топлив тоже будет сжигаться больше и больше, их влияние на климат будет возрастать или убывать?
Найдите здесь снижение потребления угля, газа и нефти, и тогда вся статья не будет казаться транспарантом на демонстрации.
ущербвклад в их профессиональный путь. Думаю, они бы и без меня нормально работали по всяким яндексам, гуглам и фейсбукам, кто достоин. Да, вы всё правильно говорите, но в рамках бакалавриата у них просто нет времени на этот полноценный эволюционный путь. Приходится вот так, «на стероидах», отправлять в полёт с помощью катапульты. Предложите другой вариант? Что мне делать? У меня 14 лекций и 8 лабораторных работ, а дальше — открытый космос самообразования.преподавателяматери, есть риск потом сделаться евангелистом :)1) Сложность кода растёт вместе со сложностью задачи, но неграмотный разработчик добавляет больше сложности в код, чем прибавилось сложности в задачу.
2) Не зря великие говорили, что если отладка сложнее написания кода, то не получится отлаживать код, который написал на пределе доступной тебе сложности. Но я бы сказал ещё, что грамотный разработчик не создаёт решения сложнее, чем на 90% от своей способности со сложностью справляться.
3) Нельзя сложные программные системы переписывать с нуля потому, что они тебе не нравятся своей сложностью. Если кто-то приходит к тебе и говорит «да тут у вас слишком сложно, мы напишем с нуля» — нельзя его к написанию подпускать, надо чтобы сначала он продемонстрировал, что старую систему срефакторить сможет. Если ты не можешь справиться с той сложностью, которая уже есть, методом постепенного рефакторинга, то когда начнешь писать сам — наворотишь сложность еще хуже и в итоге задачу не решишь. А всё почему? Потому что нельзя понять, что именно ты не понимаешь и недооценивашь, по определению.
4) Главное для опытного программиста — умение управлять сложностью. Обычно мы сложность только добавляем (нельзя же заниматься только рефакторингом), но горе тому, кто так до рефакторинга (по сути, упрощения!) и не доходит. Тогда вместо того, чтобы наводить порядок и упрощать, такой разработчик накручивает костыли на костыли и остановиться не может, потому что костыли писать проще. Со временем костыли писать становится всё сложнее и сложнее, но фишка в том, что в каждый момент времени написать очередной костыль хоть и всё сложнее и сложнее, но всё равно всегда проще, чем расчистить конюшни и навести порядок. И всегда есть эта иллюзия (?), что по причине дедлайнов оптимальное решение — писать костыли. Увы, это оптимальное решение в моменте, но очень неоптимальное в долгосрочной перспективе.
Я не смогу. Я могу объяснять только то, что сам понимаю и что в голове в систему уложено.
Не могу согласиться. Это не входит в рамки статьи, но если описать информационные сущности, их ключи и связи, структуру бд можно строить автоматически, потому что вариативности не остаётся. Разработать инфомодель, то есть описать предметную область — вот это ближе к искусству. Но к бд это отношения не имеет.
потому что те, кто уже изучил нормальные формы испорчены безвозвратно, а их отсылка к страшным терминам будет только пугать (ну и отвлекать, если они пойдут читать их в википедию). В любом случае, у меня же нормальный курс, там есть дальше и определения, и нормальные формы. Я ещё не настолько радикализовался, чтобы нормальные формы совсем выбрасывать :)