Кстати вопрос, как стоит обучать программированию людей школьного возраста и должно ли их обучение строится по какому-то особому плану, стоит рассмотреть отдельно. Это очень сложный вопрос. На мой взгляд (я это уже отметил в предыдущем своём комментарии) детей изучающих программирование не надо рассматривать как детей (вообще учеников не надо рассматривать как детей, как бы это пародоксально не звучало). Не надо с ними «сюсюкать». Конечно, пальцевые примеры нужны. Но в этих пальцевых примерах должна прослеживаться абстрактность, чтобы помочь обучающемуся собственно в процессе обобщения.
На мой взгляд объяснение полиморфизма следует начинать как раз с функций ведущих себя одинаково на значениях разного типа (операции со списками, например).
Великолепная статья! Гениальная! Стиль Бурбаки — именно тот стиль, после которого на вопрос «сколько будет два плюс три» ребёнок даёт ответ «два плюс три будет столько же, сколько три плюс два, потому что сложение коммутативно»…
Я не призываю вас учить по ней детей. Даже и не надо пытаться рассматривать людей изучающих программирования подобным образом, сколько бы им лет не было…
Если вы думаете, что ребёнок поймёт что такое полиморфизм после того, как прочитает взрывающую мозг фразу
Этот принцип просто-напросто гласит что резюме работника не совпадает с самим работником.
то вы сильно заблуждаетесь. Эта фраза построенна весьма характерным образом и выдаёт наличие у вас научно-технической подготовки, но для обучения она неподходит.
для программирования на пальцах это объяснение может и пойдёт, но большинство людей программирует всё же на компьютерах.
не смотря на ваш призыв абстрагироваться от языков, вы тем не менее взялись объяснять довольно частный случай полиморфизма, а не его общую концепцию.
наконец, Luca Cardelli написал прекрасную статью On Understanding Types, Data Abstraction, and Polymorphism. Рекомендую прочитать и осознать её, прежде чем учить кого-либо тому, что такое полиморфизм.
Про дифуры. Сами по себе дифуры, может, и не нужны и бесполезны. Как бесполезна сама по себе таблица умножения.
Нет, я этого не говорил. Они нужны, но нужны совершенно конкретным людям, а не как часть общего курса для подготовки программистов.
вообще генерации звука, например, в музыкальных инструментах, звучания пианино в тех же синтезаторах, или ударных в электрических ударных установках (не сэмпловых, разумеется) — это случайно не оно
У нас в МСС были конечно законы газовой динамики, но там вообще одномерный случай рассматривался… вообщем не про то. Больше похоже на урматы, там уравнения аккустики рассматривались, правда достаточно бегло и исключительно с точки зрения их математических свойств, без приложения к реальности. Так что я вам ничем не помогу, к сожалению. Я думаю лучше физика спросить, а я всё таки математик по диплому =)
Ну, если сможете так давайте. Я пока не увидел ни слова про МСС.
Концепт матрицы как таковой — тривиален. В рамках курса алгебры изучить его, плюс различные классы линейных операторов — полсеместра. Однако на этом ведь не останавливаются. Изучается всякая тяжелая артиллерия типа теоремы Жордана и т.д. Я вам скажу, мне на работе матрицы пока не приходилось использовать. И я не знаю никого из программистов (исключая тех кто занимается разного рода математическими расчетами), кто бы их использовал.
Алгебра вещь полезная и красивая. Я её очень люблю. Теория Галуа вообще песня! Но к моей работе программистом она не имеет никакого отношения.
Теперь о дифурах. Изучить ОДУ и общие методы их решения полсеместра достаточно. Но опять же подтягивается тяжелая артиллерия: много частых видов, со специфическими трюками для решения, устойчивость к малым возмущениям, а потом курс уравнений в частных производных (часто известный как урматы — уравнения математической физики) — это самая настоящая труба! А вычметоды, все эти разностные схемы, равномерные и неравномерные сетки, методы Галеркина?
Еще раз повторю — большинству программистов достаточно математики в объеме 2 семестров.
посмотрите на последний ICFPC :)
смотрел я на него. скучноват, хотя безусловно имеет связь с реальностью.
Можете доходчиво объяснить зачем программисту скажем вычислительные методы или механика сплошных сред (жидкость, газ, твердое тело, сумарно 4 семестра)? зачем дифуры?
Вам приходилось на работе когда-нибудь изучать систему дифуравнений на устойчивость по Ляпунову? Исследовать, когда сдавленая с двух сторон железная балка преодолеет предел текучести по Треска или Мизесу? Изобретать разностную схему с третьим порядком аппроксимации? Расчитывать движение r-волны разряжения в трубе?
Даже если и взять боллее близкие курсы типа матлогики, я всё равно не могу понять как, например, применить теорему Лося-Вота (Łoś-Vaught) в повседневном программировании…
Иначе Кнута Вы потом как откроете, так и закроете…
ну вы просто поджигаете... во-первых, я не совсем понимаю почему вы всё время называете сборщик --- аллокатором, безусловно стратегии аллокации и сборки связанны, но это совсем не одно и тоже. особенно меня поражает "generational аллокатор", это что еще за зверь такой? Сборщики бывают поколенными, это да... Но поколенный аллокатор я слабо себе представляю. Конечно, можно сделать некоторые эвристические предположения или анализ (ключевые слова: prolific types, CBGC) и иногда при выделении памяти сразу выделять память и старого поколения (JVM так поступает для очень больших объектов).
во-вторых, приведенная вами стратегия это уже древний гудрон, старье. в современных высокопроизводительных VM применяются гораздо более сложные алгоритмы, позволяющие на большинстве приложений значительно сократить время GC-пауз.
Вообщем и целом у меня создаётся впечатление, что вы пытаетесь рассуждать о вещах, о которых имеете лишь поверхностное представление.
читал я сию статью, безусловно познавательно, как и большинство статей бородатого дяди Хертца. Но вообще не показатель --- там же с оракулярным управлением сравнивается, а оракул он всегда знает лучшую точку, в которой можно удалить объект... Но что самое забавное в заключении там сказано: Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory.
чего-то я не понял, причем тут переключение контекстов. не поясните ли?
и я вам говорю, можно убрать барьеры на запись в некоторых случаях. Почитайте например статьи дяди Detlefs'а (например, Compile-time concurrent marking write barrier removal).
На мой взгляд объяснение полиморфизма следует начинать как раз с функций ведущих себя одинаково на значениях разного типа (операции со списками, например).
Я не призываю вас учить по ней детей. Даже и не надо пытаться рассматривать людей изучающих программирования подобным образом, сколько бы им лет не было…
Если вы думаете, что ребёнок поймёт что такое полиморфизм после того, как прочитает взрывающую мозг фразу
то вы сильно заблуждаетесь. Эта фраза построенна весьма характерным образом и выдаёт наличие у вас научно-технической подготовки, но для обучения она неподходит.
не смотря на ваш призыв абстрагироваться от языков, вы тем не менее взялись объяснять довольно частный случай полиморфизма, а не его общую концепцию.
наконец, Luca Cardelli написал прекрасную статью On Understanding Types, Data Abstraction, and Polymorphism. Рекомендую прочитать и осознать её, прежде чем учить кого-либо тому, что такое полиморфизм.
Нет, я этого не говорил. Они нужны, но нужны совершенно конкретным людям, а не как часть общего курса для подготовки программистов.
У нас в МСС были конечно законы газовой динамики, но там вообще одномерный случай рассматривался… вообщем не про то. Больше похоже на урматы, там уравнения аккустики рассматривались, правда достаточно бегло и исключительно с точки зрения их математических свойств, без приложения к реальности. Так что я вам ничем не помогу, к сожалению. Я думаю лучше физика спросить, а я всё таки математик по диплому =)
Ну, если сможете так давайте. Я пока не увидел ни слова про МСС.
Концепт матрицы как таковой — тривиален. В рамках курса алгебры изучить его, плюс различные классы линейных операторов — полсеместра. Однако на этом ведь не останавливаются. Изучается всякая тяжелая артиллерия типа теоремы Жордана и т.д. Я вам скажу, мне на работе матрицы пока не приходилось использовать. И я не знаю никого из программистов (исключая тех кто занимается разного рода математическими расчетами), кто бы их использовал.
Алгебра вещь полезная и красивая. Я её очень люблю. Теория Галуа вообще песня! Но к моей работе программистом она не имеет никакого отношения.
Теперь о дифурах. Изучить ОДУ и общие методы их решения полсеместра достаточно. Но опять же подтягивается тяжелая артиллерия: много частых видов, со специфическими трюками для решения, устойчивость к малым возмущениям, а потом курс уравнений в частных производных (часто известный как урматы — уравнения математической физики) — это самая настоящая труба! А вычметоды, все эти разностные схемы, равномерные и неравномерные сетки, методы Галеркина?
Еще раз повторю — большинству программистов достаточно математики в объеме 2 семестров.
смотрел я на него. скучноват, хотя безусловно имеет связь с реальностью.
слишком много ненужной математики, слишком много подробностей, вот что такое Кнут. программисту он не нужен.
Вам приходилось на работе когда-нибудь изучать систему дифуравнений на устойчивость по Ляпунову? Исследовать, когда сдавленая с двух сторон железная балка преодолеет предел текучести по Треска или Мизесу? Изобретать разностную схему с третьим порядком аппроксимации? Расчитывать движение r-волны разряжения в трубе?
Даже если и взять боллее близкие курсы типа матлогики, я всё равно не могу понять как, например, применить теорему Лося-Вота (Łoś-Vaught) в повседневном программировании…
а стоит ли его вообще открывать?
манга - это исключительно печатная продукция
манга - это комиксы
во-вторых, приведенная вами стратегия это уже древний гудрон, старье. в современных высокопроизводительных VM применяются гораздо более сложные алгоритмы, позволяющие на большинстве приложений значительно сократить время GC-пауз.
Вообщем и целом у меня создаётся впечатление, что вы пытаетесь рассуждать о вещах, о которых имеете лишь поверхностное представление.
и я вам говорю, можно убрать барьеры на запись в некоторых случаях. Почитайте например статьи дяди Detlefs'а (например, Compile-time concurrent marking write barrier removal).