Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов.
Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей.
Что следует понимать под техникой программирования и как ее надо "ставить"?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
Полностью с Вами согласен. Самого посещали неоднократно такие мысли. Как мне кажется, существует техника, например, параллельного программирования, техника написания программ в функциональном стиле (функциональное программирование) и т.д. ...
LVV>... и как ее надо "ставить"?
Как в том же спорте или музыке — тренировки, тренировки и еще раз тренировки. Правда у программистов это принимает несколько иной вид — чтение соответствующей литературы и практика, потом опять чтение и т.д., пока, так сказать, не натренируешься.
Здравствуйте, LaptevVV, Вы писали:
LVV>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей.
Цель какая? Увеличение производительности приложения, скорости набора, скорости разработки, скорости отладки, простоты поддержки ? Или просто разительно отличиться от других? Более того, для каждого языка техника, которая решает одну или несколько из вышеизложенных задач будет разной.
Здравствуйте, Sharov, Вы писали:
LVV>>Что следует понимать под техникой программирования и как ее надо "ставить"? S>Полностью с Вами согласен. Самого посещали неоднократно такие мысли. Как мне кажется, существует техника, например, параллельного программирования, техника написания программ в функциональном стиле (функциональное программирование) и т.д. ...
Давайте пока разговароивать о начальном обучении императивному программированию. LVV>>... и как ее надо "ставить"? S>Как в том же спорте или музыке — тренировки, тренировки и еще раз тренировки. Правда у программистов это принимает несколько иной вид — чтение соответствующей литературы и практика, потом опять чтение и т.д., пока, так сказать, не натренируешься.
Не, тут как раз совсем неясно.
Вот, например, в боксе. Там четко определены технические элементы-удары: прямой, боковой, снизу. И для каждого вида известно, в каком порядке нужно двигаться, чтобы сделать именно этот удар.
ИМХО в обучении программированию пока такого не наработано.
Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев):
а) полный перебор;
б) поиск по заданному условию;
Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так!
А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск.
Например, поиск максимума в массиве — это полный перебор.
Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while.
Остальные операторы цикла — дополнительные удобства.
И про остальные типовые задачи тоже так нужно сделать. Только я чего-то не видал подхода именно от такой печки. В учебниках изучают язык, а не технику программирования. Такого слова даже не встречается.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, denisko, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали:
LVV>>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей. D>Цель какая? Увеличение производительности приложения, скорости набора, скорости разработки, скорости отладки, простоты поддержки ? Или просто разительно отличиться от других? Более того, для каждого языка техника, которая решает одну или несколько из вышеизложенных задач будет разной.
Цель — учить так, чтобы получался профи, а не любитель. Который по производительности и по качеству производимого программного продукта на порядок лучше любителя.
Не... Не для языка, а для парадигмы, скорее всего. Функциональное программирование сильно отличается от императивного. А все языки императивного программирования — очень похожи.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>ИМХО в обучении программированию пока такого не наработано. LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>а) полный перебор; LVV>б) поиск по заданному условию; LVV>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так! LVV>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск. LVV>Например, поиск максимума в массиве — это полный перебор. LVV>Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while. LVV>Остальные операторы цикла — дополнительные удобства.
А можно узнать, задача вычисления факториала — это задача на перебор или на поиск?
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали:
LVV>>ИМХО в обучении программированию пока такого не наработано. LVV>>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>>а) полный перебор; LVV>>б) поиск по заданному условию; LVV>>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так! LVV>>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск. LVV>>Например, поиск максимума в массиве — это полный перебор. LVV>>Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while. LVV>>Остальные операторы цикла — дополнительные удобства.
D>А можно узнать, задача вычисления факториала — это задача на перебор или на поиск?
На перебор.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Не... Не для языка, а для парадигмы, скорее всего. Функциональное программирование сильно отличается от императивного. А все языки императивного программирования — очень похожи.
Похожесть не отменяет необходимости учиться грамотно использовать на конкретный язык. Очень хорошо об этом пишет J. Bloch в предисловии к Effective Java.
Хотя оно конечно, вычисление факториала выглядит примерно одинаково на всех императивных языках. Но Вы же пишете о технике. В моем понимании этого слова техника программирования на, скажем, Java и С++, все-таки несколько отличается.
Здравствуйте, 31415926, Вы писали:
3>Здравствуйте, LaptevVV, Вы писали:
LVV>>Не... Не для языка, а для парадигмы, скорее всего. Функциональное программирование сильно отличается от императивного. А все языки императивного программирования — очень похожи.
3>Похожесть не отменяет необходимости учиться грамотно использовать на конкретный язык. Очень хорошо об этом пишет J. Bloch в предисловии к Effective Java. 3>Хотя оно конечно, вычисление факториала выглядит примерно одинаково на всех императивных языках. Но Вы же пишете о технике. В моем понимании этого слова техника программирования на, скажем, Java и С++, все-таки несколько отличается.
Ну, это как две разные школы дзюдо... Мастера вам скажут, что техники разных школ сильно отличаются. Но!...
Дзюдо все равно дзюдо. Мастер, освоивший одну из школ, прекрасно освоит и другую.
Я не об этом. Я о постановки БАЗОВОЙ техники программирования.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, 31415926, Вы писали:
3>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>Не... Не для языка, а для парадигмы, скорее всего. Функциональное программирование сильно отличается от императивного. А все языки императивного программирования — очень похожи.
3>>Похожесть не отменяет необходимости учиться грамотно использовать на конкретный язык. Очень хорошо об этом пишет J. Bloch в предисловии к Effective Java. 3>>Хотя оно конечно, вычисление факториала выглядит примерно одинаково на всех императивных языках. Но Вы же пишете о технике. В моем понимании этого слова техника программирования на, скажем, Java и С++, все-таки несколько отличается. LVV>Ну, это как две разные школы дзюдо... Мастера вам скажут, что техники разных школ сильно отличаются. Но!... LVV>Дзюдо все равно дзюдо. Мастер, освоивший одну из школ, прекрасно освоит и другую. LVV>Я не об этом. Я о постановки БАЗОВОЙ техники программирования.
Не очень понимаю, что Вы имеете в виду. Однако, следуя Вашей аналогии — мастерами дзюдо становятся, нсколько я понимаю, в рамках изучения какой-то конкретной школы. Так и с программированием — я плохо себе представляю, как можно приобрести хоть какую-нибудь технику без серьезной практики в каком-то конкретном языке. По-моему, с этого и надо начинать. Другое дело, что знания одного языка явно недостаточно для того чтобы считаться профессиональным программистом.
Здравствуйте, 31415926, Вы писали:
LVV>>Я не об этом. Я о постановки БАЗОВОЙ техники программирования.
3>Не очень понимаю, что Вы имеете в виду. Однако, следуя Вашей аналогии — мастерами дзюдо становятся, нсколько я понимаю, в рамках изучения какой-то конкретной школы. Так и с программированием — я плохо себе представляю, как можно приобрести хоть какую-нибудь технику без серьезной практики в каком-то конкретном языке. По-моему, с этого и надо начинать. Другое дело, что знания одного языка явно недостаточно для того чтобы считаться профессиональным программистом.
Тогда здесь возникает очень хороший вопрос. Базовая техника — самое важное, что должно быть "поставлено" у будущего программера. Тогда язык для постановки базовой техники должен быть максимально "очищен" от всякого рода "фенечек", свойственных именно ЭТОМУ языку, и не имеющих отношения к базовой технике... То есть мы приходим к тому, что язык для постановки базовой техники должен быть минимизирован.
И тогда вопрос: а какой тогда должен быть язык для постановки базовой техники...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Цель — учить так, чтобы получался профи, а не любитель. Который по производительности и по качеству производимого программного продукта на порядок лучше любителя.
Их надо ...бать(с). Если у тебя есть в запасе 7 лет, из которых 4 ты будешь ставить исключительно базовую технику, причем в бешенном ритме, получишь человека, который пишет на порядок лучше любителя, только кроме писать он ничего больше не сможет.
LVV>Не... Не для языка, а для парадигмы, скорее всего. Функциональное программирование сильно отличается от императивного. А все языки императивного программирования — очень похожи.
Есть различный сахар, котороый сильно влияет на стиль.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, 31415926, Вы писали:
LVV>>>Я не об этом. Я о постановки БАЗОВОЙ техники программирования.
3>>Не очень понимаю, что Вы имеете в виду. Однако, следуя Вашей аналогии — мастерами дзюдо становятся, нсколько я понимаю, в рамках изучения какой-то конкретной школы. Так и с программированием — я плохо себе представляю, как можно приобрести хоть какую-нибудь технику без серьезной практики в каком-то конкретном языке. По-моему, с этого и надо начинать. Другое дело, что знания одного языка явно недостаточно для того чтобы считаться профессиональным программистом. LVV>Тогда здесь возникает очень хороший вопрос. Базовая техника — самое важное, что должно быть "поставлено" у будущего программера. Тогда язык для постановки базовой техники должен быть максимально "очищен" от всякого рода "фенечек", свойственных именно ЭТОМУ языку, и не имеющих отношения к базовой технике... То есть мы приходим к тому, что язык для постановки базовой техники должен быть минимизирован. LVV>И тогда вопрос: а какой тогда должен быть язык для постановки базовой техники...
Мне это проблема представляется надуманной. Согласитесь, что как-то странно сначала учить технике на примере какого-то специального языка. Собственно зачем? Чтобы потом человек хорошо программировал в реальной жизни уже на реальном языке? Так не проще ли (и практичней) оттачивать технику на "боевом" языке. Да, у этого языка будут недостатки, зато это реальный язык, которым (с переменным успехом) пользуются миллионы программистов. Уверен, что при изучении последующих языков упомянутые "фенечки" серьезной проблемы не составят. Наоборот, могут, при вдумчивом подходе, помочь понять, какие есть особенности у нового языка. А если техника отрабатывалась на искусственно стерилизованном примере, то проблемы реального мира будут неким "культурным шоком".
Другое дело, что, по возможности стоит объяснять человеку, что какие-то конкретные вещи — результат ошибок дизайна. Ну и язык стоит выбирать не ударясь в экзотику. Как мне кажется, востребованность языка — вполне разумный критерий.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Sharov, Вы писали:
LVV>>>Что следует понимать под техникой программирования и как ее надо "ставить"? S>>Полностью с Вами согласен. Самого посещали неоднократно такие мысли. Как мне кажется, существует техника, например, параллельного программирования, техника написания программ в функциональном стиле (функциональное программирование) и т.д. ... LVV>Давайте пока разговароивать о начальном обучении императивному программированию. LVV>>>... и как ее надо "ставить"? S>>Как в том же спорте или музыке — тренировки, тренировки и еще раз тренировки. Правда у программистов это принимает несколько иной вид — чтение соответствующей литературы и практика, потом опять чтение и т.д., пока, так сказать, не натренируешься. LVV>Не, тут как раз совсем неясно. LVV>Вот, например, в боксе. Там четко определены технические элементы-удары: прямой, боковой, снизу. И для каждого вида известно, в каком порядке нужно двигаться, чтобы сделать именно этот удар. LVV>ИМХО в обучении программированию пока такого не наработано. LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>а) полный перебор; LVV>б) поиск по заданному условию;
Вариантов использоания циклов гораздо больше.
LVV>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так!
Невозможно написать один шаблон. Даже вариантов использования цикла для итерирования масса.
LVV>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск.
Я бы сказал, что это профанация.
LVV>Например, поиск максимума в массиве — это полный перебор.
Хороший пример.
Вот цикл, инкрементирующий элементы массива.
for(int i=0; i<len ;i++) array[i]++;
А вот для поиска максимума.
int ret=array[0];
for(int i=1; i<len ;i++) Replace_max(ret,array[i]);
Чуть-чуть но по другому получается.
LVV>Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while. LVV>Остальные операторы цикла — дополнительные удобства.
LVV>И про остальные типовые задачи тоже так нужно сделать. Только я чего-то не видал подхода именно от такой печки. В учебниках изучают язык, а не технику программирования. Такого слова даже не встречается.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, deniok, Вы писали:
D>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>ИМХО в обучении программированию пока такого не наработано. LVV>>>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>>>а) полный перебор; LVV>>>б) поиск по заданному условию; LVV>>>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так! LVV>>>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск. LVV>>>Например, поиск максимума в массиве — это полный перебор. LVV>>>Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while. LVV>>>Остальные операторы цикла — дополнительные удобства.
D>>А можно узнать, задача вычисления факториала — это задача на перебор или на поиск? LVV>На перебор.
Здравствуйте, Шахтер, Вы писали:
LVV>>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>>а) полный перебор; LVV>>б) поиск по заданному условию; Ш>Вариантов использоания циклов гораздо больше.
Покажите тогда. LVV>>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так! Ш>Невозможно написать один шаблон. Даже вариантов использования цикла для итерирования масса. LVV>>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск. Ш>Я бы сказал, что это профанация. LVV>>Например, поиск максимума в массиве — это полный перебор. Ш>Хороший пример. Ш>Вот цикл, инкрементирующий элементы массива. Ш>
Ш>for(int i=0; i<len ;i++) array[i]++;
Ш>
Это полный перебор. Ш>А вот для поиска максимума. Ш>
И это тоже полный перебор. Ш>Чуть-чуть но по другому получается.
Не... Принцип-то — один. Полный перебор всех элементов. В данном случае — массива.
При вычислении факториала — элементы генерируются. Но их тоже — полный перебор до заданного значения n.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Шахтер, Вы писали:
D>>>А можно узнать, задача вычисления факториала — это задача на перебор или на поиск? LVV>>На перебор. Ш>А числа Фибоначчи посчитать?
то же самое.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LLVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>а) полный перебор; LVV>б) поиск по заданному условию;
ИМХО — пустое словоблудие. А уж рассуждение про for и while — просто смехотвортно, извините за резкость. Я конечно понимаю, что хочется придать наукообразие, но не нужно превращать все в фарс. Насколько я понял, В.Ф. Ткачев — физик, и программирование для него — это программирование вычислений, что является весьма специфической деятельностью (хотя, бесспорно, весьма полезной). Не думаю, что идеи автора пассажа
Уникальное сочетание свойств делает языки семейства Oberon идеальной платформой для разработки алгоритмов для научно-технических расчетов, а также для систематического обучения программированию.
следует как-то учитывать при решении вопроса о том, как учить профессии программиста.
Здравствуйте, 31415926, Вы писали:
3>Здравствуйте, LaptevVV, Вы писали:
LLVV>>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>>а) полный перебор; LVV>>б) поиск по заданному условию;
3>ИМХО — пустое словоблудие. А уж рассуждение про for и while — просто смехотвортно, извините за резкость. Я конечно понимаю, что хочется придать наукообразие, но не нужно превращать все в фарс. Насколько я понял, В.Ф. Ткачев — физик, и программирование для него — это программирование вычислений, что является весьма специфической деятельностью (хотя, бесспорно, весьма полезной).
Ну, Ткачев не только физик, но и препод. И обучает и школьников, и студентов. В МГУ.
Его попытка вычленить самое существенное в циклах совсем не кажется мне фарсом, а напротив, весьма полезной абстракцией.
Во всяком случае, наши первачки как-то хорошо такую постановку вопроса воспринимают.
Кроме того, Илья Ермаков пришел к тем же идеям. Он не только студентов обучает, но и сотрудников для своей конторы готовит, то есть производственник. И отнюдь не физик. 3>Не думаю, что идеи автора пассажа 3>
3>Уникальное сочетание свойств делает языки семейства Oberon идеальной платформой для разработки алгоритмов для научно-технических расчетов, а также для систематического обучения программированию.
3>следует как-то учитывать при решении вопроса о том, как учить профессии программиста.
Дело не в обероне. Дело в минимизации конструкций в языке обучения.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, Ткачев не только физик, но и препод. И обучает и школьников, и студентов. В МГУ. LVV>Его попытка вычленить самое существенное в циклах совсем не кажется мне фарсом, а напротив, весьма полезной абстракцией. LVV>Во всяком случае, наши первачки как-то хорошо такую постановку вопроса воспринимают. LVV>Кроме того, Илья Ермаков пришел к тем же идеям. Он не только студентов обучает, но и сотрудников для своей конторы готовит, то есть производственник. И отнюдь не физик.
Ну — если сам Илья Ермаков.... Кстати — он кто такой? Губернатор острова Борнео? А по поводу Ваших первокурсников — легкость восприятия идеи/понятия, как известно, не является доказательством справедливости и/или полезности оных.
Здравствуйте, LaptevVV,
LVV>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей. LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
--
Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные".
На всех этапах обучения (лекции, практика, курсовые работы) показывал образцы применения правил программирования и оформления программ (например, громадное множество таких микро-примеров можно найти в известной книге Code Complete).
Всячески приветствовал обмен индивудуальным опытом самих студентов. В частности, очень эффективным средством достижения этого было мое отсутствие на практических занятиях, когда простешйие проблемы решались самим студентами, и только тогда, когда никто не мог с проблемой справится, ко мне приходила делегация, и я пытался им помочь.
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>Здравствуйте, LaptevVV,
LVV>>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей. LVV>>Что следует понимать под техникой программирования и как ее надо "ставить"? ГМ>-- ГМ>Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные".
Это непонятно. Как это — непрерывно меняющийся? Техника, она на то и техника, что она на уровне подсознания работает. То есть постоянна.
Кроме того, например, корпоративный стандарт кодирования сразу пресекает всякое "свободное изложение". ГМ>На всех этапах обучения (лекции, практика, курсовые работы) показывал образцы применения правил программирования и оформления программ (например, громадное множество таких микро-примеров можно найти в известной книге Code Complete).
Ой, осторожно нужно к этой книжке относится... Некоторые примеры (однократный цикл, в частности) — это бред сивой кобылы. ГМ>Всячески приветствовал обмен индивудуальным опытом самих студентов. В частности, очень эффективным средством достижения этого было мое отсутствие на практических занятиях, когда простешйие проблемы решались самим студентами, и только тогда, когда никто не мог с проблемой справится, ко мне приходила делегация, и я пытался им помочь.
Ну, это само собой.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, 31415926, Вы писали:
3>Здравствуйте, LaptevVV, Вы писали:
LVV>>Ну, Ткачев не только физик, но и препод. И обучает и школьников, и студентов. В МГУ. LVV>>Его попытка вычленить самое существенное в циклах совсем не кажется мне фарсом, а напротив, весьма полезной абстракцией. LVV>>Во всяком случае, наши первачки как-то хорошо такую постановку вопроса воспринимают. LVV>>Кроме того, Илья Ермаков пришел к тем же идеям. Он не только студентов обучает, но и сотрудников для своей конторы готовит, то есть производственник. И отнюдь не физик.
3>Ну — если сам Илья Ермаков.... Кстати — он кто такой? Губернатор острова Борнео? А по поводу Ваших первокурсников — легкость восприятия идеи/понятия, как известно, не является доказательством справедливости и/или полезности оных.
Не... Принцип KISS — это практически один из главных принципов в реальном программировании. Поэтому если одна и та же конструкция сначала воспринималась трудно, а при повороте мысли стала восприниматься значительно легче — это ХОРОШИЙ поворот мысли. Не следует искать сложность там, где без нее можно обойтись. Сложность — она нас и так достанет...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, 31415926, Вы писали:
3>>Ну — если сам Илья Ермаков.... Кстати — он кто такой? Губернатор острова Борнео? А по поводу Ваших первокурсников — легкость восприятия идеи/понятия, как известно, не является доказательством справедливости и/или полезности оных. LVV>Не... Принцип KISS — это практически один из главных принципов в реальном программировании. Поэтому если одна и та же конструкция сначала воспринималась трудно, а при повороте мысли стала восприниматься значительно легче — это ХОРОШИЙ поворот мысли. Не следует искать сложность там, где без нее можно обойтись. Сложность — она нас и так достанет...
Ладно, продолжайте в том же духе.... Так все-таки — кто такой Илья Ермаков? Я нашел упоминание человеке с таким именем только в связи с бульварным изданием для "чайников". Это он для Вас авторитет?
Здравствуйте, 31415926, Вы писали:
3>Ладно, продолжайте в том же духе.... Так все-таки — кто такой Илья Ермаков? Я нашел упоминание человеке с таким именем только в связи с бульварным изданием для "чайников". Это он для Вас авторитет?
Не... Это директор ООО Метасистемы. И по совместительству — препод. В Орле работают...
Дело не в авторитете, а в рассмотрении разного опыта. Пржде, чем объявлять что-то бредом, полезно хотя бы познакомиться немного... А потом уж решать, бред это или нет...ИМХО так как-то...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, 31415926, Вы писали:
3>>Ну — если сам Илья Ермаков.... Кстати — он кто такой? Губернатор острова Борнео? А по поводу Ваших первокурсников — легкость восприятия идеи/понятия, как известно, не является доказательством справедливости и/или полезности оных. LVV>Не... Принцип KISS — это практически один из главных принципов в реальном программировании. Поэтому если одна и та же конструкция сначала воспринималась трудно, а при повороте мысли стала восприниматься значительно легче — это ХОРОШИЙ поворот мысли. Не следует искать сложность там, где без нее можно обойтись. Сложность — она нас и так достанет...
очень непонятно к какому месту ввёрнут KISS про губернатора острова Борнео
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, LaptevVV, Вы писали:
LVV>>Здравствуйте, 31415926, Вы писали:
3>>>Ну — если сам Илья Ермаков.... Кстати — он кто такой? Губернатор острова Борнео? А по поводу Ваших первокурсников — легкость восприятия идеи/понятия, как известно, не является доказательством справедливости и/или полезности оных. LVV>>Не... Принцип KISS — это практически один из главных принципов в реальном программировании. Поэтому если одна и та же конструкция сначала воспринималась трудно, а при повороте мысли стала восприниматься значительно легче — это ХОРОШИЙ поворот мысли. Не следует искать сложность там, где без нее можно обойтись. Сложность — она нас и так достанет...
К>очень непонятно к какому месту ввёрнут KISS про губернатора острова Борнео
Это не о Борнео. А о легкости восприятия...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV,
LVV>>>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>>>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей. LVV>>>Что следует понимать под техникой программирования и как ее надо "ставить"? ГМ>>-- ГМ>>Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные". LVV>Это непонятно. Как это — непрерывно меняющийся? Техника, она на то и техника, что она на уровне подсознания работает. То есть постоянна.
--
Well, предлагаю посмотреть на себя Разве Вы не видите изменения своей техники программирования с течением времени? Вы же сами пишете — "ставится", а это подразумевает процесс, действие.
Я действительно считаю, что у активно работающего программиста техника программирования меняется, он таки да продолжает обучаться. Может быть, кривая обучения становится только более пологой.
LVV>Кроме того, например, корпоративный стандарт кодирования сразу пресекает всякое "свободное изложение". ГМ>>На всех этапах обучения (лекции, практика, курсовые работы) показывал образцы применения правил программирования и оформления программ (например, громадное множество таких микро-примеров можно найти в известной книге Code Complete). LVV>Ой, осторожно нужно к этой книжке относится... Некоторые примеры (однократный цикл, в частности) — это бред сивой кобылы.
--
Вот и отлично! Попросите студентов найти и объяснить этот бред и обязательно поощряйте их за каждую найденную ошибку. Так, например, сделали мои аспиранты с моим опусом, когда я закончил активную преподавательскую работу и, по их словам, эффект был поразительным.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, 31415926, Вы писали:
3>>Ладно, продолжайте в том же духе.... Так все-таки — кто такой Илья Ермаков? Я нашел упоминание человеке с таким именем только в связи с бульварным изданием для "чайников". Это он для Вас авторитет? LVV>Не... Это директор ООО Метасистемы. И по совместительству — препод. В Орле работают... LVV>Дело не в авторитете, а в рассмотрении разного опыта. Пржде, чем объявлять что-то бредом, полезно хотя бы познакомиться немного... А потом уж решать, бред это или нет...ИМХО так как-то...
Да я знакомлюсь, знакомлюсь — с разным опытом. Вот только программирование для меня — это профессия и тратить время на ознакомление с идеями/опытом маргиналов от ИТ нет возможности, причем не скажу, что к сожалению. Творческих Вам успехов!
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>>>Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные". LVV>>Это непонятно. Как это — непрерывно меняющийся? Техника, она на то и техника, что она на уровне подсознания работает. То есть постоянна. ГМ>-- ГМ>Well, предлагаю посмотреть на себя Разве Вы не видите изменения своей техники программирования с течением времени? Вы же сами пишете — "ставится", а это подразумевает процесс, действие. ГМ>Я действительно считаю, что у активно работающего программиста техника программирования меняется, он таки да продолжает обучаться. Может быть, кривая обучения становится только более пологой.
Ага, понятно. Просто я под техникой имел ввиду базовую технику написания языковых конструкций, а вы смотрели ширше...
Например, ИМХО, техника написания цикла для поиска не должна меняться со временем. Раз и навсегда усвоенный шаблон сильно облегчает жизнь программиста. 1. усвоение шаблона освобождает мозги для мышления о более существенных моментах задачи-программы...
2. Шаблон заведомо правильный — ошибок не может быть... LVV>>Ой, осторожно нужно к этой книжке относится... Некоторые примеры (однократный цикл, в частности) — это бред сивой кобылы. ГМ>Вот и отлично! Попросите студентов найти и объяснить этот бред и обязательно поощряйте их за каждую найденную ошибку. Так, например, сделали мои аспиранты с моим опусом, когда я закончил активную преподавательскую работу и, по их словам, эффект был поразительным.
Хорошая мысль!
Но это — для старших. Первачки наши пока до таких книжек не доросли...
Им бы конструкции понять и усвоить...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, 31415926, Вы писали:
3>Да я знакомлюсь, знакомлюсь — с разным опытом. Вот только программирование для меня — это профессия и тратить время на ознакомление с идеями/опытом маргиналов от ИТ нет возможности, причем не скажу, что к сожалению. Творческих Вам успехов!
Ну почему ж сразу маргиналов-то. Народ давно и довольно успешно работает. И в процессе работы мигрировали с С++ в БлэкБокс... Интересно, почему у них так получилось...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, 31415926, Вы писали:
3>>Да я знакомлюсь, знакомлюсь — с разным опытом. Вот только программирование для меня — это профессия и тратить время на ознакомление с идеями/опытом маргиналов от ИТ нет возможности, причем не скажу, что к сожалению. Творческих Вам успехов! LVV>Ну почему ж сразу маргиналов-то. Народ давно и довольно успешно работает. И в процессе работы мигрировали с С++ в БлэкБокс... Интересно, почему у них так получилось...
Вы, как я понимаю, очень далеки от промышленного программирования, так что объяснять Вам, почему я считаю ребят, лабающих в Орле что-то на Обероне маргиналами — бесполезно. Кстати — а цикл event dispatcher'а (например, в X-Windows или AWT/SWT) — это перебор или поиск? Ну ладно — этот цикл бесконечный. А вот цикл, возникающий при StAX XML parsing — это что? Или (совсем простой случай) — цикл, возникающий при чтении из сокета тела HTTP-запроса/ответа?
Вообще-то, я полагаю, что при обучении прграммированию нужно как можно больше разбирать примеров, а не разводить теоретизирование вокруг вещей, и так интуитивно ясных (убежден, что если человек не понимает, что такое цикл, ему лучше поискать себя в другой профессии).
Здравствуйте, LaptevVV,
ГМ>>>>Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные". LVV>Ага, понятно. Просто я под техникой имел ввиду базовую технику написания языковых конструкций, а вы смотрели ширше... LVV>Например, ИМХО, техника написания цикла для поиска не должна меняться со временем. Раз и навсегда усвоенный шаблон сильно облегчает жизнь программиста. 1. усвоение шаблона освобождает мозги для мышления о более существенных моментах задачи-программы... LVV>2. Шаблон заведомо правильный — ошибок не может быть...
--
Попробую привести опровергающий пример, показывающий изменение техники написания кода для того же цикла перебора элемента
Вот так может выглядеть код для начинающих
#define A_SIZE (10)
int A[ A_SIZE ];
for ( size_t i = 0 ; i < A_SIZE ; i++ ) {
...
}
А вот то же самое для STL::vector для продвинутых пользователей
std::vector< int > B;
for ( size_t i = 0 , Len = B.size() ; i < Len ; i++ ) {
...
}
А для std::list цикл будет другим, а потом мы еще расскажем о std::for_each и т.д.
LVV>>>Ой, осторожно нужно к этой книжке относится... Некоторые примеры (однократный цикл, в частности) — это бред сивой кобылы. ГМ>>Вот и отлично! Попросите студентов найти и объяснить этот бред и обязательно поощряйте их за каждую найденную ошибку. Так, например, сделали мои аспиранты с моим опусом, когда я закончил активную преподавательскую работу и, по их словам, эффект был поразительным. LVV>Но это — для старших. Первачки наши пока до таких книжек не доросли...
--
Ну, можно им и подыграть, явно сделав какую-то ошибку на занятии... Заодно определите лидеров в потоке.
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>Попробую привести опровергающий пример, показывающий изменение техники написания кода для того же цикла перебора элемента ГМ>Вот так может выглядеть код для начинающих ГМ>
ГМ>А вот то же самое для STL::vector для продвинутых пользователей ГМ>
ГМ>std::vector< int > B;
ГМ>for ( size_t i = 0 , Len = B.size() ; i < Len ; i++ ) {
ГМ>...
ГМ>}
ГМ>
ГМ>А для std::list цикл будет другим, а потом мы еще расскажем о std::for_each и т.д.
Ага, понятно, что вы имеете ввиду под техникой. Выходит, сначала надо определиться с самим понятием техники...
Паттерн-то все равно для всех примеров один — полный перебор элементов последовательности...
А конкретное исполнение — возникают технические детали...
LVV>>Но это — для старших. Первачки наши пока до таких книжек не доросли... ГМ>Ну, можно им и подыграть, явно сделав какую-то ошибку на занятии... Заодно определите лидеров в потоке.
Ну, эт мы применяем время от времени...
Спасибо. Полезно для меня...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
Техника, это набор базовых приемов, которые специалист использует в своей деятельности.
Их обычно не много, но они видоизменяются и комбинируются в зависимости от поставленной задачи.
Посмотрите на мастеров боевых искусств и все вопросы о том, что такое техника отпадут. А потом посмотрите как тренируют новичков. Раз за разом повторение одних и тех же движений за учителем, до тех пор, пока не придёт понимание.
Примерно то же самое и в программировании.
В качестве способов обучения: наблюдение за работой мастера и попытки самостоятельно повторить. В программировании, это анализ архитектуры и программного кода, написанного профессионалами, плюс попытки сделать нечто подобное самостоятельно.
И самое главное: больше ошибок хороших и разных. За ошибки не наказывать а поощрять. Инженеры это не павловские собаки. У хорошего специалиста должен быть пытливый ум. Он не должен бояться экспериментов.
Здравствуйте, 31415926, Вы писали:
3>Вы, как я понимаю, очень далеки от промышленного программирования, так что объяснять Вам, почему я считаю ребят, лабающих в Орле что-то на Обероне маргиналами — бесполезно. Кстати — а цикл event dispatcher'а (например, в X-Windows или AWT/SWT) — это перебор или поиск? Ну ладно — этот цикл бесконечный. А вот цикл, возникающий при StAX XML parsing — это что? Или (совсем простой случай) — цикл, возникающий при чтении из сокета тела HTTP-запроса/ответа?
Цикл event dispatcher — это совсем другой уровень программистских знаний. Асинхронные события — это надо думать отдельно...
Цикл, возникающий при StAX XML parsing — зависит от целей цикла. Либо перебираете все вершины дерева, либо ищете определенную.
Wикл, возникающий при чтении из сокета тела HTTP-запроса/ответа?
while(contentLength > 0)
{
if(writer == null)
{
// Read strings
String bodyLine = in.readLine();
contentLength -= bodyLine.length() + 2;
// Find name of file
if(bodyLine.length() > 0)
{
Matcher m = fileNamePattern.matcher(bodyLine);
if(m.find())
{
fileName = m.group(1);
}
}
else if(fileName != null)
{
OutputStream stream = new FileOutputStream(fileName);
if(digestMD5 != null)
stream = new DigestOutputStream(stream, digestMD5);
writer = new OutputStreamWriter(stream, streamCharset);
}
else
throw new RuntimeException("Name of uploaded file not found");
}
Очевидно, перебор. 3>Вообще-то, я полагаю, что при обучении прграммированию нужно как можно больше разбирать примеров, а не разводить теоретизирование вокруг вещей, и так интуитивно ясных (убежден, что если человек не понимает, что такое цикл, ему лучше поискать себя в другой профессии).
Для разбора примеров нужны критерии хорошести и плохости...
Которых в настоящее время столько — сколько программистов вокруг...А должны быть
Это для вас интуитивно ясно. После стольких лет в программировании...
А пацан эту штуку первый раз видит...
Спасибо, полезное для меня.
Вот вам ссылочка:
viewtopic.php?p=46165
Может быть, обнаружите для себя что-то полезное...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Курилка, Вы писали:
LVV>>Может быть, обнаружите для себя что-то полезное... К>Это из серии "хлопок одной рукой"?
Тогда посмотрите вот сюда:
Да, вот внезапно чётко понял, с примером, что меня раздражает в досрочном выходе. Концептуально.
Вот есть процедуры:
PROCEDURE P1 (...);
BEGIN
BlockA
END P1;
PROCEDURE P2 (...);
BEGIN
BlockB
END P2;
...
Я хочу выполнить вполне безобидное преобразование — добавить в P1 и P2 в конец по операции. (Например, логирование. Да что угодно. Какое-то освобождение. Не суть.)
Скажите мне, я имею право это сделать? Если BlockA и BlockB — это нормальные блоки, то я имею право применить последовательную композицию и получить таким преобразованием новые процедуры, какие мне надо (с семантикой "сначала происходит BlockA, потом NewBlock")? Имею право? Да. Это право мне гарантировано свойствами структурных конструкций. Любой блок программы должен допускать последовательную композицию с другими блоками. И не только последовательную, но и вкладывание в объемлющие конструкции. И я не обязан изучать внутреннее устройство этого блока, если нет связей по потокам данных.
Т.е. блоки, в которых использована инструкция выхода из процедуры, являются дефектными, неполноценными, потому что не поддерживают вполне законную композицию в объемлющем блоке.
Если говорить юридически, то оказывается, что требование не использовать досрочные выходы — это не "глупая буква закона", а как раз вполне в терминах "гражданских прав", так сказать. Свобода программиста ставить EXIT-ы ограничивается в силу того, что эта свобода ограничила бы свободу других (осуществлять ЗАКОННУЮ композицию этого блока).
Технически же говоря (ну да, придираясь, но тем не менее...), это ухудшает свойства объемлющей системы в плане возможностей развития.
Мелочь? Само по себе (в отличие от циклов) — может быть, и да. Но если мы вообще принимаем инженерную культуру, как внимание к свойствам своих систем, то непонятно, почему в данном случае нам тоже ей не следовать. Внимание к мелочам — одно из качеств профессионала. Следующее из опыта, что мелочей в серьёзном деле нет...
Если вы не согласны, то, может быть, прочитаете книгу "Чистый код" Роберта Мартина?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Dufrenite, Вы писали:
LVV>>Что следует понимать под техникой программирования и как ее надо "ставить"?
D>Техника, это набор базовых приемов, которые специалист использует в своей деятельности. D>Их обычно не много, но они видоизменяются и комбинируются в зависимости от поставленной задачи. D>Посмотрите на мастеров боевых искусств и все вопросы о том, что такое техника отпадут. А потом посмотрите как тренируют новичков. Раз за разом повторение одних и тех же движений за учителем, до тех пор, пока не придёт понимание. D>Примерно то же самое и в программировании.
Не... В программировании как раз не то же самое. Хотя бы потому, что в боевых искусствах один и тот же прием — он хоть в Африке, хоть в России. А в программировании еще не выработались критерии общепризнанных приемов.
Вот например, в шахматах есть такое правило для новичков: конь на краю доски — плохо. Но гроссы его запросто нарушают. А для новичков — ПЛОХО!
Вот например, написал чел цикл:
while (true)
{ // ...if(некое условие) break;
// ...
}
Это "хороший" цикл? Или такой цикл для новичков лучше запретить? А профи могут им пользоваться, ибо понимают, что и зачем... D>В качестве способов обучения: наблюдение за работой мастера и попытки самостоятельно повторить. В программировании, это анализ архитектуры и программного кода, написанного профессионалами, плюс попытки сделать нечто подобное самостоятельно.
Да это все понятно. Только как отличить мастера от немастера... Тот же Макконелл иногда такие советы дает — хоть к стенке его ставь заа развращение малолетних!
А все потому, что критериев нет. D>И самое главное: больше ошибок хороших и разных. За ошибки не наказывать а поощрять. Инженеры это не павловские собаки. У хорошего специалиста должен быть пытливый ум. Он не должен бояться экспериментов.
А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев):
LVV>а) полный перебор;
LVV>б) поиск по заданному условию;
LVV>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так!
Для снижения градуса возбуждения, добавлю, что такое утверждение — только две схемы цикла — как раз для новичков, для постановки БАЗОВОЙ техники...
Это же два квантора: для любого и существует.
Сначала новичков следует научить этим самым общим схемам, а потом, естественно, можно углубляться...
По мере увеличения уровня обученности, чел научится и "конь на краю доски" применять грамотно и безболезненно...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей. LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
У музыкантов и спортсменов под техникой понимается некоторая физическая составляющая деятельности, коей является доведенная до автоматизма последовательность сокращения мышц. У программиста такой составляющей является разве что стучание по клавишам. В таком случае для "постановки" такой "техники" надо освоить слепой метод печати на клавиатуре, только и всего. Ну может быть еще использование хоткеев и сниппетов в различных IDE (если проводить аналогию "IDE ~ музыкальный инструмент") для продвинутых "технарей".
Если же копнуть дальше, то окажется, что помимо физической составляющей присутствует и базовая теоретическая, которая уже не называется "техникой". Например, у музыкантов это нотная грамота, сольфеджио и т.д. Для программиста же аналогичной составляющей будет изучение основ программирования: Дональд Кнут, SICP и подобные курсы, в целом отвязанные от конкретного языка программирования, изучающие базовые семантические элементы программ (циклы, функции, рекурсию и т.д.).
А если ковырять еще дальше, то уже появится такое понятие как "стиль" (можно обозвать и по-другому, не важно). Как существуют музыканты, играющие в разных жанрах, или спортсмены, исповедующие разные спортивные стили, так и программисты, программирующие в разных стилях: сюда можно отнести личные предпочтения языка, библиотек, парадигм, правил оформления кода и т.д.
Ну а еще выше можно рассматривать коллективное взаимодействие людей на уровне оркестров, спортивных команд, IT-отделов. Тут тоже можно проводить параллели, только на более высоком абстрактном уровне, и к теме это уже не относится.
Очевидно, что программиста-"профи" от кодера-"любителя" помимо всего прочего отличает владение как раз "нотной грамотой". Ответ на изначальный вопрос напрашивается сам собой.
Здравствуйте, Аноним, Вы писали:
LVV>>Что следует понимать под техникой программирования и как ее надо "ставить"?
А>У музыкантов и спортсменов под техникой понимается некоторая физическая составляющая деятельности, коей является доведенная до автоматизма последовательность сокращения мышц. У программиста такой составляющей является разве что стучание по клавишам.
У программистов аналогом является:
— четкая организация проекта
— форматирование кода
— документирование (включая именование функций)
— обязательное тестирование
— использование полноценных средств отладки, логи ошибок
— контроль версий, контроль собственных изменений по diff-ам, бэкапы (если надо)
— использование актуальных тулсов, а не борланд C++ (особенно актуально для некоторых ВУЗов)
Если все это соблюдается, то можно говорить, то «техника» поставлена хорошо.
Индус, но с хорошей техникой все равно произведет проект, с которым можно хоть как-то работать: допиливать, фиксить, дописывать и т.п. А результаты работы способного студента, пишущего в стиле aaa=*b2[0]+pribavit(), скорее всего придется выкинуть и переделать, какими бы блестящими не были. Это и есть аналог колоссальной разницы, какая бывает у музыкантов и художников.
Всякие парадигмы, паттерны, алгоритмы, это уже содержательная, а не техническая составляющая. Что конкретно напишут два человека с одинаковой техникой, это другой вопрос.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Курилка, Вы писали:
LVV>>>Может быть, обнаружите для себя что-то полезное... К>>Это из серии "хлопок одной рукой"? LVV>Тогда посмотрите вот сюда:
[покоцано]
А теперь (внимание!) вопрос: как я должен открывать ссылку "viewtopic.php?p=46165" ?
P.S. Иногда полезно прочесть, на что именно отвечает собеседник
Здравствуйте, LaptevVV, Вы писали:
LVV>Не... В программировании как раз не то же самое. Хотя бы потому, что в боевых искусствах один и тот же прием — он хоть в Африке, хоть в России. А в программировании еще не выработались критерии общепризнанных приемов.
ЭЭ нет батенька. Тут вы не правы. Сравните, например, китайские и японские школы. Или разные стили и направления, например айкидо и карате. Нет там общепризнанных приёмов. У каждой школы, даже у каждого мастера свои, удобные лично ему.
LVV>Вот например, в шахматах есть такое правило для новичков: конь на краю доски — плохо. Но гроссы его запросто нарушают. А для новичков — ПЛОХО! LVV>Вот например, написал чел цикл: LVV>
LVV>Это "хороший" цикл? Или такой цикл для новичков лучше запретить? А профи могут им пользоваться, ибо понимают, что и зачем...
Это хороший цикл. Только его использование должно быть строго обосновано.
LVV>Да это все понятно. Только как отличить мастера от немастера... Тот же Макконелл иногда такие советы дает — хоть к стенке его ставь заа развращение малолетних! LVV>А все потому, что критериев нет.
У Макконела своя школа, у тебя своя. Не согласен — объясни людям почему и предложи более правильный, на твой взгляд, вариант.
LVV>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!
Согласен. Это уже больше к стратегии и тактике. Не даром армии всего мира тратят колоссальные средства на проведение учений. Можно вызубрить все приемы и сдать их на отлично, но пока собственных шишек не набьёшь ты не специалист.
LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
"Техника" программиста — это то, что называется "базой" в образовании.
Умение анализировать, системно мыслить, грамотно ставить вопросы, быстро и точно находить ответы.
Ставится в процессе обучения в типовом техническом вузе.
Здравствуйте, LaptevVV, Вы писали: LVV>Я хочу выполнить вполне безобидное преобразование — добавить в P1 и P2 в конец по операции. (Например, логирование. Да что угодно. Какое-то освобождение. Не суть.)
Мне кажется, цитата на сегодняшний день неактуальна.
Во-первых, нынче в моде использовать исключения, что сводит на нет аргументы автора. Например, освобождение ресурса (и любую другую операцию с семантикой "при выходе из блока") следует делать в finally.
Во вторых, ожидаемым автором свойством обладают функции, так что оборачиваем все, что надо в функцию — и вперед. Автор же хочет механического преобразования кода (без учета семантики).
В третьих, цитата иллюстрирует то, как отважно императивные программисты борются с проблемами, которые сами же себе создают. Если бы в языке не было уродского деления на выражения и стейтменты (а все было бы выражениями — как в ФЯ) — обозначенной проблемы не стояло бы.
Здравствуйте, Dufrenite, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали:
LVV>>Не... В программировании как раз не то же самое. Хотя бы потому, что в боевых искусствах один и тот же прием — он хоть в Африке, хоть в России. А в программировании еще не выработались критерии общепризнанных приемов. D>ЭЭ нет батенька. Тут вы не правы. Сравните, например, китайские и японские школы. Или разные стили и направления, например айкидо и карате. Нет там общепризнанных приёмов. У каждой школы, даже у каждого мастера свои, удобные лично ему.
Айкидо и карате — это разные языки программирования
Но, например, прием "вертушка" он хоть в классике, хоть в вольной борьбе — пратически один и тот же... Схема его выполнения — одна. LVV>>Вот например, в шахматах есть такое правило для новичков: конь на краю доски — плохо. Но гроссы его запросто нарушают. А для новичков — ПЛОХО! LVV>>Вот например, написал чел цикл: LVV>>
LVV>>Это "хороший" цикл? Или такой цикл для новичков лучше запретить? А профи могут им пользоваться, ибо понимают, что и зачем... D>Это хороший цикл. Только его использование должно быть строго обосновано.
Как это сделать? Обоснованию же тоже надо учить. И обоснование должно быть по возможности строгим, а не на уровне словесных пассажей, что это хорошо, потому как на практике применяется. Должно быть сначала обоснование, а уж потом разрешение использовать. Обоснования нет — использовать нельзя, хоть и разрешается языком... LVV>>А все потому, что критериев нет. D>У Макконела своя школа, у тебя своя. Не согласен — объясни людям почему и предложи более правильный, на твой взгляд, вариант. LVV>>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!
И будет опять спор двух авторитетов. А так быть не должно. Всех летчиков сначала на кукурузнике учат, а потом они садятся на машины разного уровня и назначения. Вот такого "кукурузника" я пока в программировании не вижу. D>Согласен. Это уже больше к стратегии и тактике. Не даром армии всего мира тратят колоссальные средства на проведение учений. Можно вызубрить все приемы и сдать их на отлично, но пока собственных шишек не набьёшь ты не специалист.
Это следующий уровень техники — соединение БАЗОВЫХ компонент в СИСТЕМУ. Тоже надо учить, но после постановки базовой техники.
Я б сказал даже "базовой технике мышления".
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Курилка, Вы писали:
К>[покоцано] К>А теперь (внимание!) вопрос: как я должен открывать ссылку "viewtopic.php?p=46165" ?
Пардон, забыл полный адрес дать — на автомате дал локальную ссылку...
Вот: http://forum.oberoncore.ru/viewtopic.php?p=46165 К>P.S. Иногда полезно прочесть, на что именно отвечает собеседник
Именно этим я и занимаюсь. Сбором разных взглядов на процесс программирования и обучение программированию
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Код совершенно чудовищный и, к тому же, абсолютно бессмысленный, но дело не в этом. Если вы пытались изобразить перебор, то, согласно Вашим догмам цикл должен быть "for". Вы уж определитесь, а то студенты вконец запутаются....
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, LaptevVV, Вы писали: LVV>>Я хочу выполнить вполне безобидное преобразование — добавить в P1 и P2 в конец по операции. (Например, логирование. Да что угодно. Какое-то освобождение. Не суть.) MC>Мне кажется, цитата на сегодняшний день неактуальна. MC>Во-первых, нынче в моде использовать исключения, что сводит на нет аргументы автора. Например, освобождение ресурса (и любую другую операцию с семантикой "при выходе из блока") следует делать в finally.
ВО! Очень показательно! Нынче " в моде...". А правильно ли это? Обработка исключений — это, между прочим, нелокальный переход... Который нарушает один из принципов, указанных Робертом Мартином в книге "Чистый код": программа должна читаться сверху вних без прыжков в разные места. На это же намекал и Кнут в Literate Programming. MC>Во вторых, ожидаемым автором свойством обладают функции, так что оборачиваем все, что надо в функцию — и вперед. Автор же хочет механического преобразования кода (без учета семантики). Нет... Автор в этом примере как раз считает, что структурная конструкция на любом уровне должна удовлетворять краеугольному камню: один вход сверху, один выход — снизу. И это нормальное требование. MC>В третьих, цитата иллюстрирует то, как отважно императивные программисты борются с проблемами, которые сами же себе создают. Если бы в языке не было уродского деления на выражения и стейтменты (а все было бы выражениями — как в ФЯ) — обозначенной проблемы не стояло бы.
Каждому свое. В разные времена борются с разным и по-разному.
Различие заложено в конструкции машины: выполнение команд управления принципиально отличается от выполнения других команд.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Курилка, Вы писали:
К>>P.S. Иногда полезно прочесть, на что именно отвечает собеседник LVV>Именно этим я и занимаюсь. Сбором разных взглядов на процесс программирования и обучение программированию
Позанудствую, но предыдущий ответ говорит об обратном: что ты не видел, на что я отвечал.
Надеюсь, что со студентами такого у тебя не наблюдается.
Здравствуйте, 31415926, Вы писали:
LVV>>Wикл, возникающий при чтении из сокета тела HTTP-запроса/ответа? LVV>>
LVV>>while(contentLength > 0)
LVV>>{
LVV>>}
LVV>>
LVV>>Очевидно, перебор. 3>Код совершенно чудовищный и, к тому же, абсолютно бессмысленный, но дело не в этом. Если вы пытались изобразить перебор, то, согласно Вашим догмам цикл должен быть "for". Вы уж определитесь, а то студенты вконец запутаются....
Это не я писал...
Взял готовый из инета... Но поскольку я не занимался никогда написанием такого рода программ, — править не стал.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, 31415926, Вы писали:
LVV>>>Wикл, возникающий при чтении из сокета тела HTTP-запроса/ответа? LVV>>>
LVV>>>Очевидно, перебор. 3>>Код совершенно чудовищный и, к тому же, абсолютно бессмысленный, но дело не в этом. Если вы пытались изобразить перебор, то, согласно Вашим догмам цикл должен быть "for". Вы уж определитесь, а то студенты вконец запутаются.... LVV>Это не я писал... LVV>Взял готовый из инета... Но поскольку я не занимался никогда написанием такого рода программ, — править не стал.
Это ладно — никто не ожидает от преподавателя умения писать код. Но Вы привели это в качестве примера "перебора". Как же так?
Здравствуйте, 31415926, Вы писали:
LVV>>Это не я писал... LVV>>Взял готовый из инета... Но поскольку я не занимался никогда написанием такого рода программ, — править не стал. 3>Это ладно — никто не ожидает от преподавателя умения писать код. Но Вы привели это в качестве примера "перебора". Как же так?
1. Ну, преподы тоже пишут код. Только, как правило, они сроками не связаны. А какой код — зависит от дисциплины, которую преподаешь.
2. Я думаю, что нужно прочитать все байты, которые пришли. Аварийные ветки — это отдельная пестня. Но если аварий нет, то мы принимаем все — вроде так.
Об аварийных ситуациях сейчас давайте не будем рассуждать, ибо стратегию обработки ошибок нужно продумывать на уровне проектирования, а тактику — на уровне реализации каждой как минимум функции. Тогда код, несомненно, будет почище...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
3>>Это ладно — никто не ожидает от преподавателя умения писать код. Но Вы привели это в качестве примера "перебора". Как же так?
LVV>1. Ну, преподы тоже пишут код. Только, как правило, они сроками не связаны. А какой код — зависит от дисциплины, которую преподаешь.
Не обижайтесь, но если бы преподы умели писать код, то с какой стати они сидели бы на своей нищенской зарплате? По крайней мере, большинство из них. Именно поэтому я ничего не жду от наших вузов в плане подготовки программистов. Ну совсем ничего.
LVV>2. Я думаю, что нужно прочитать все байты, которые пришли. Аварийные ветки — это отдельная пестня. Но если аварий нет, то мы принимаем все — вроде так. LVV>Об аварийных ситуациях сейчас давайте не будем рассуждать, ибо стратегию обработки ошибок нужно продумывать на уровне проектирования, а тактику — на уровне реализации каждой как минимум функции. Тогда код, несомненно, будет почище...
Вы не ответили на мой вопрос, хотя мысль, что "нужно прочитать все байты, которые пришли", несомненно глубокая. Да и про аварии/стратегию/тактику мощно задвинуто.
Меня только вот что смущает. Смею предположить, что изрядный процент Ваших студентов посещает Ваши лекции/семинары в рассуждении приобрести знания, которые помогут им в будущем зарабатывать деньги. Вы не чувствуете перед ними ответственности, когда пудрите им мозги умозрительными концепциями, рожденными в Орловских трущобах, и Обероном?
Re[3]: Как обучать технике программирования?
От:
Аноним
Дата:
20.04.10 09:27
Оценка:
Здравствуйте, Кодёнок, Вы писали:
Кё>У программистов аналогом является: Кё>- четкая организация проекта Кё>- форматирование кода Кё>- документирование (включая именование функций) Кё>- обязательное тестирование Кё>- использование полноценных средств отладки, логи ошибок Кё>- контроль версий, контроль собственных изменений по diff-ам, бэкапы (если надо) Кё>- использование актуальных тулсов, а не борланд C++ (особенно актуально для некоторых ВУЗов)
Чушь, это не является аналогом музыкальной техники. Я уже написал: аналогом музыкальной и спортивной техники является стучание по клавишам слепым методом и использование хоткеев и сниппетов. А то, что вы тут понаписали — это лишь составляющая стиля, которая может отсутствовать или быть недоступна. Это даже не "нотная грамота" программиста.
Кё>Если все это соблюдается, то можно говорить, то «техника» поставлена хорошо.
Если всё это соблюдается, то можно говорить, что программист старается следовать хорошему стилю. Ни техника, ни основы программирования тут ни при чем. Никакого толка в этом хорошем стиле нету, если программист не освоил "нотную грамоту".
Кё>Индус, но с хорошей техникой все равно произведет проект, с которым можно хоть как-то работать: допиливать, фиксить, дописывать и т.п.
Ага, и получать такой же индусский проект. И одна неверно выбранная структура данных или алгоритм их обработки может загубить весь ваш проект, каким бы он не был задокументированным и форматированным. И простым рефакторингом вы тут не отделаетесь. И никакие полноценные средства отладки и контроль версий вам не помогут выявить ошибку в многопоточном приложении, которая появляется случайным образом с вероятностью 1e-10 при максимальной загрузке канала связи, например.
Даже если художник умеет технично орудовать кисточкой, он не будет писать хорошие картины до тех пор, пока не освоит базовые теоретические знания про пропорции, цвета, композицию и т.д. Однако движения кисточкой — это лишь сокращения мышц. У программиста эта составляющая практически отсутствует.
Кё>А результаты работы способного студента, пишущего в стиле aaa=*b2[0]+pribavit(), скорее всего придется выкинуть и переделать, какими бы блестящими не были.
А вот результаты работы способного студента, которые добыты со знанием дела (т.е. используя правильные алгоритмы, структуры данных и т.д.) можно быстро привести в нормальный вид, используя простейшие средства рефакторинга и минимальным допиливанием напильником.
Кё>Всякие парадигмы, паттерны, алгоритмы, это уже содержательная, а не техническая составляющая.
Она же и является основной. Но вы явно не поняли моего посыла о том, что у программиста как таковой технической составляющей почти нет, а содержательная делится на несколько частей, одну из которых (не самую главную) вы зачем-то называете техникой.
Здравствуйте, 31415926, Вы писали:
3>Здравствуйте, LaptevVV, Вы писали:
3>>>Это ладно — никто не ожидает от преподавателя умения писать код. Но Вы привели это в качестве примера "перебора". Как же так?
LVV>>1. Ну, преподы тоже пишут код. Только, как правило, они сроками не связаны. А какой код — зависит от дисциплины, которую преподаешь. 3>Не обижайтесь, но если бы преподы умели писать код, то с какой стати они сидели бы на своей нищенской зарплате? По крайней мере, большинство из них. Именно поэтому я ничего не жду от наших вузов в плане подготовки программистов. Ну совсем ничего.
Не в целях саморекламы, но в качестве демонстрации проблем с вузами — только что написанное.
Здравствуйте, 31415926, Вы писали:
3>Здравствуйте, LaptevVV, Вы писали:
3>>>Это ладно — никто не ожидает от преподавателя умения писать код. Но Вы привели это в качестве примера "перебора". Как же так?
LVV>>1. Ну, преподы тоже пишут код. Только, как правило, они сроками не связаны. А какой код — зависит от дисциплины, которую преподаешь. 3>Не обижайтесь, но если бы преподы умели писать код, то с какой стати они сидели бы на своей нищенской зарплате? По крайней мере, большинство из них. Именно поэтому я ничего не жду от наших вузов в плане подготовки программистов. Ну совсем ничего.
Эт ты зря. Во-первых, лично меня просто по возрасту не возьмут в 99 % контор. А преподаю я только с 93 года, когда уехал из Узбекистана в Россию. Я порядка 20 лет отпахал программистом. Писал все и на всем. Вплоть до операционной системы в восьмеричных кодах. И зарплате отдал, естественно, дань...
И даже на персоналках...
А за последний год я написал для дисциплины "Системное ПО" пару интерпретаторов для виртуальных машин, штуки 3-4 варианта ассемблеров, загрузчики, отладчик... Вот до профайлера и линкера все никак не доберусь...
Во-вторых, у нас преподают наши же выпускники. Например, один из них был в течение 5 лет начальником отдела программирования в нашем вузе. Много задач подняли под его руководством. Он четырежды сертифицированный специалист Микрософт. Преподает, потому как ему просто интересно со студентами возиться...
Для своей дисциплины он написал клиент-серверную приблуду для проверки студенческих лабораторных. По паттерну Template Method. Теперь он для rf;lкаждой й темы в лабах дописывает пару-тройку методов, и сидит на кафедре, куда студиозы из класса посылают проги.
Другой — действующий программист в Связьинформ. Третий — ведущий спец в астраханской фирме Агент Плюс. Борис Нуралиев на последней конференции по 1С хорошо отозвался о программных продуктах Агент Плюс, которые фирма 1С продает. Писаны продукты — на С++.
Пацану — тоже интересно со школьниками возиться — он олимпиадный кружок ведет.
Можно найти в сети примеры преподов, которые работают и преподают. Поляков, например, родной школе помогает, преподает там программирование. Хотя сам волне себе работающий ученый... И очень нехило зарабатывает в международных проектах. Вот его сайт — почитайте: http://kpolyakov.narod.ru/index.htm LVV>>2. Я думаю, что нужно прочитать все байты, которые пришли. Аварийные ветки — это отдельная пестня. Но если аварий нет, то мы принимаем все — вроде так. LVV>>Об аварийных ситуациях сейчас давайте не будем рассуждать, ибо стратегию обработки ошибок нужно продумывать на уровне проектирования, а тактику — на уровне реализации каждой как минимум функции. Тогда код, несомненно, будет почище... 3>Вы не ответили на мой вопрос, хотя мысль, что "нужно прочитать все байты, которые пришли", несомненно глубокая. Да и про аварии/стратегию/тактику мощно задвинуто.
Я ж вам сказал, что в этой области — не спец. Хотя если потребуется, разберусь и смогу написать, что нужно. 3>Меня только вот что смущает. Смею предположить, что изрядный процент Ваших студентов посещает Ваши лекции/семинары в рассуждении приобрести знания, которые помогут им в будущем зарабатывать деньги. Вы не чувствуете перед ними ответственности, когда пудрите им мозги умозрительными концепциями, рожденными в Орловских трущобах, и Обероном?
Прежде, чем читать мне мораль, что и как я должен преподавать, потрудились бы хотя бы прочитать.
А то критикуете по принципу: Не читал, но осуждаю.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
3>>Не обижайтесь, но если бы преподы умели писать код, то с какой стати они сидели бы на своей нищенской зарплате? По крайней мере, большинство из них. Именно поэтому я ничего не жду от наших вузов в плане подготовки программистов. Ну совсем ничего. LVV>Эт ты зря. Во-первых, лично меня просто по возрасту не возьмут в 99 % контор. А преподаю я только с 93 года, когда уехал из Узбекистана в Россию. Я порядка 20 лет отпахал программистом. Писал все и на всем. Вплоть до операционной системы в восьмеричных кодах. И зарплате отдал, естественно, дань...
Во-первых, 99% контор просто не стоят, чтобы в них работать. Кроме того, я не утверждал, что преподаватели никогда не умели программировать. Хотя, "операционная система в восьмеричных кодах" — звучит диковато, если Вам конечно не крепко за 60.
LVV>Я ж вам сказал, что в этой области — не спец. Хотя если потребуется, разберусь и смогу написать, что нужно.
А это ничего, что преподаватель ИТ в 21 веке "не спец" в основах Интернет-программирования? Какой процент Ваших выпускников будет реализовывать ассемблер? Сильно подозреваю, что нулевой (разве что пойдут по Вашим стопам). А вот с HTTP все они сталкиваюся каждый день, и очень прискорбно ИМХО, что даже их преподаватель пока что не считает нужным разобраться с тем, как это работает.
LVV>Прежде, чем читать мне мораль, что и как я должен преподавать, потрудились бы хотя бы прочитать. LVV>А то критикуете по принципу: Не читал, но осуждаю.
Я и не думал читать Вам мораль. Просто хотел напомнить об ответственности перед Вашими выпускниками — судя по всему то, чему Вы их учите, современному промышленному программисту не очень-то и нужно. И "клиент-серверная приблуда для проверки студенческих лабораторных по паттерну Template Method" у любого профессионала ничего, кроме усмешки вызвать не может.
А насчет "прочитать" — я уже ранее говорил, что у меня нет времени на ознакомление с маргинальными течениями.
Здравствуйте, LaptevVV, Вы писали:
LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
То же, что и везде: умение читабельно/оптимально реализовать четко поставленную зачаду, в которой отсутствуют неясности. Ну а ставить технику помогает решение упражнений. Как и с интегралами/производными Опять же, технике присущи черты индивидуальности.
LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>а) полный перебор; LVV>б) поиск по заданному условию; LVV>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так! LVV>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск. LVV>Например, поиск максимума в массиве — это полный перебор. LVV>Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while. LVV>Остальные операторы цикла — дополнительные удобства.
LVV>И про остальные типовые задачи тоже так нужно сделать. Только я чего-то не видал подхода именно от такой печки. В учебниках изучают язык, а не технику программирования. Такого слова даже не встречается.
Попытки строго формализовать процесс программирования, да и любую другую инженерную деятельность, то есть фактически исключить из этой деятельности непосредственно инженера, предпринимались неоднократно и пока ни к чему хорошему не привели.
Собственно задача этого самого инженера и заключается в том, чтобы из множества вариантов, каждый из которых имеет свои достоинства и недостатки, в условиях неоднозначно определенных критериев качества получившегося результата, сделать-таки свою работу хорошо.
Здравствуйте, LaptevVV, Вы писали:
LVV>Вот например, в шахматах есть такое правило для новичков: конь на краю доски — плохо. Но гроссы его запросто нарушают. А для новичков — ПЛОХО!
Техника это не методология и свод правил В шахматах под техникой обычно понимают способ реализации перевеса. При этом у каждого шахматиста (да и у музыканта, каратиста) техника своя. В программировании тоже
LVV>Вот например, написал чел цикл: LVV>
Здравствуйте, Аноним, Вы писали:
А>У музыкантов и спортсменов под техникой понимается некоторая физическая составляющая деятельности, коей является доведенная до автоматизма последовательность сокращения мышц.
Не совсем так. Техника есть у шахматистов, у математиков и т. п. Так что сокращение мыщц можно заменить на последовательность действий (необязательно физических).
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные".
Свод правил это все-таки методология. "Непрерывно меняющиеся" звучит достаточно расплывчато. Все в нашем мире меняется, что медленнее, что быстрее. "Индивидуальные" это особенность. Но главное, такое определение не позволяет сказать: техника программирования этого студента хромает. Не включено сюда сравнение
Здравствуйте, LaptevVV, Вы писали:
LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>а) полный перебор; LVV>б) поиск по заданному условию;
Ну... есть еще организация метки:
repeat
if Something then Break;
if SomethingElse then Break;
until True;
LVV>Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while.
А вообще такой подход лично мне не нравится. Для меня цикл это повторяющиеся вычисления. Есть только один цикл: for(;), а все остальное синтаксический сахар вокруг него. Собственно говоря, такой подход реализован в Ada: так есть один основной цикл:
loop
-- инструкции тела цикла
-- Внутри можно юзать exit (выход из цикла) и
-- exit when (выход из цикла, если выполняется определенное условие)
end loop;
А все остальное просто синтаксический сахар вокруг:
while логическое_выражение loop
-- инструкции тела цикла
end loop;
for счетчик in диапазон_значений_счетчика loop
-- инструкции тела цикла
end loop;
Здравствуйте, 31415926, Вы писали:
3>Во-первых, 99% контор просто не стоят, чтобы в них работать. Кроме того, я не утверждал, что преподаватели никогда не умели программировать. Хотя, "операционная система в восьмеричных кодах" — звучит диковато, если Вам конечно не крепко за 60.
Это было в 80-е. Писали на ассемблере, естественно, а отлаживались на встроенном восьмеричном отладчике. Тогда только появился тетрис... LVV>>Я ж вам сказал, что в этой области — не спец. Хотя если потребуется, разберусь и смогу написать, что нужно. 3>А это ничего, что преподаватель ИТ в 21 веке "не спец" в основах Интернет-программирования? Какой процент Ваших выпускников будет реализовывать ассемблер? Сильно подозреваю, что нулевой (разве что пойдут по Вашим стопам). А вот с HTTP все они сталкиваюся каждый день, и очень прискорбно ИМХО, что даже их преподаватель пока что не считает нужным разобраться с тем, как это работает.
Очевидно, вы ОЧЕНЬ ДАЛЕКИ от преподавания... Интернет-технологии у нас тоже преподают... Только это отдельный годовой курс. Преподает наш же выпускник 2004 года, бывший дипломантом 1 степени конкурса "Цифровой ветер". Вполне квалифицированный товарисчь... LVV>>А то критикуете по принципу: Не читал, но осуждаю. 3>Я и не думал читать Вам мораль. Просто хотел напомнить об ответственности перед Вашими выпускниками — судя по всему то, чему Вы их учите, современному промышленному программисту не очень-то и нужно. И "клиент-серверная приблуда для проверки студенческих лабораторных по паттерну Template Method" у любого профессионала ничего, кроме усмешки вызвать не может. 3>А насчет "прочитать" — я уже ранее говорил, что у меня нет времени на ознакомление с маргинальными течениями.
Пока все это похоже на гнутие пальцев...
Я пытаюсь выяснить мнение профи о постановке техники программирования, а вы пальцы гнете... Что ж гните их и дальше...
А "мы пойдем другим путем"...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Sergey Chadov, Вы писали:
LVV>>И про остальные типовые задачи тоже так нужно сделать. Только я чего-то не видал подхода именно от такой печки. В учебниках изучают язык, а не технику программирования. Такого слова даже не встречается.
SC>Попытки строго формализовать процесс программирования, да и любую другую инженерную деятельность, то есть фактически исключить из этой деятельности непосредственно инженера, предпринимались неоднократно и пока ни к чему хорошему не привели. SC>Собственно задача этого самого инженера и заключается в том, чтобы из множества вариантов, каждый из которых имеет свои достоинства и недостатки, в условиях неоднозначно определенных критериев качества получившегося результата, сделать-таки свою работу хорошо.
Речь не о формализации деятельности инженера. А о формировании определенных типовых шаблонов мышления — техники программирования — некоторого определенного уровня. Чтобы на рутинном уровне не мыслить, а делать. А размышлять на более высоком уровне — на архитектурном, например. А циклы пусть пишутся правильно на автомате.
Тенниссист же не задумывается о каждом ударе в партии — он делает это на автомате. А думает он о комбинациях, которые будет проводить... Такой же автоматизм ИМХО нужен и при написании отдельных конструкций...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
SC>>Попытки строго формализовать процесс программирования, да и любую другую инженерную деятельность, то есть фактически исключить из этой деятельности непосредственно инженера, предпринимались неоднократно и пока ни к чему хорошему не привели. SC>>Собственно задача этого самого инженера и заключается в том, чтобы из множества вариантов, каждый из которых имеет свои достоинства и недостатки, в условиях неоднозначно определенных критериев качества получившегося результата, сделать-таки свою работу хорошо. LVV>Речь не о формализации деятельности инженера. А о формировании определенных типовых шаблонов мышления — техники программирования — некоторого определенного уровня. Чтобы на рутинном уровне не мыслить, а делать.
Не мыслить, а делать — это само получится, не надо этому учить
LVV> А размышлять на более высоком уровне — на архитектурном, например. А циклы пусть пишутся правильно на автомате.
На автомате пишется то, что часто используется. Все. Никакими другими средствами автоматизм не достигается.
К тому же, что-то мне не кажется, что особенности написания простейших циклов — то, чему стоит уделять много внимания. Лучше сконцентрироваться на том, чтобы объяснять студенту, почему он неправ в каждом конкретном куске кода, какие могут быть с ним проблемы.
Здравствуйте, LaptevVV, Вы писали:
LVV>Пока все это похоже на гнутие пальцев... LVV>Я пытаюсь выяснить мнение профи о постановке техники программирования, а вы пальцы гнете... Что ж гните их и дальше... LVV>А "мы пойдем другим путем"...
Так я Вам и пытаюсь сказать — нужно разбирать как можно больше конкретных примеров из реальной программистской практики с использованием современных рабочих (т.е. широко используемых) языков программирования.
Это и студентам интереснее будет, как мне кажется. Вот например, упонянутый ранее GUI event dispatcher. По Вашему это — rocket science. Я же считаю, что будущий программист должен как можно раньше познакомиться с этим. По крайней мере, будут отдавать себе отчет, что происходит, когда GUI приложение "виснет". А то попросишь на собеседовании J2EE team lead`а расписать, что происходит в сети от момента ввода URL до показа страницы — а он глазами хлопает и мычит что-то невнятное. Это чудо, если человек, 5+ лет разрабатывающий Интернет приложения способен объяснить разницу между TCP и UDP. Да собственно и для Вас, судя по Вашей реакции, то обстоятельство, что имеется отдельный от Вашего курс, который читает "квалифицированный товарисчь" является оправданием Вашего собственного дремучего невежества в простейших вопросах связанных с самым широко используемой на сегодня технологией. Хочется надеяться, что этот "квалифицированный товарисчь" способен самостоятельно написать цикл, а не ссылается в таких случаях на Вас.
А Вас все в теорию тянет, да в какие-то ветхозаветные материи вроде ассемблера. Или же наоборот — в какую-то экзотику, которой увлечен некий гражданин из Тьмутараканьского НИИЧАВО или дипломанты каких-то загадочных премий. И какие-то странные туманные мечтания о стерильных языках для обучения. Впрочем, похоже, что все это говорить бесполезно. Так и будете преподавать — программирование как набор абстрактных принципов отдельно, Интернет — отдельно, БД — отдельно. А то что люди, получившие подобное "образование" (и, возможно, за него заплатившие) будут потом вынуждены начинать практически с нуля — неважно. Все равно от людей с Астраханским дипломом никто особых чудес не ожидает. Зато преподаватели — все сплошь ученые, которых аж сам Нуралиев по лысине погладил... Ладно хватит воздух сотрясать. Еще раз творческих успехов!
Здравствуйте, Sergey Chadov, Вы писали:
SC>Здравствуйте, LaptevVV, Вы писали:
SC>>>Попытки строго формализовать процесс программирования, да и любую другую инженерную деятельность, то есть фактически исключить из этой деятельности непосредственно инженера, предпринимались неоднократно и пока ни к чему хорошему не привели. SC>>>Собственно задача этого самого инженера и заключается в том, чтобы из множества вариантов, каждый из которых имеет свои достоинства и недостатки, в условиях неоднозначно определенных критериев качества получившегося результата, сделать-таки свою работу хорошо. LVV>>Речь не о формализации деятельности инженера. А о формировании определенных типовых шаблонов мышления — техники программирования — некоторого определенного уровня. Чтобы на рутинном уровне не мыслить, а делать.
SC>Не мыслить, а делать — это само получится, не надо этому учить
В том-то и дело, что "само" — не получается... Учить приходится... LVV>> А размышлять на более высоком уровне — на архитектурном, например. А циклы пусть пишутся правильно на автомате. SC>На автомате пишется то, что часто используется. Все. Никакими другими средствами автоматизм не достигается. SC>К тому же, что-то мне не кажется, что особенности написания простейших циклов — то, чему стоит уделять много внимания. Лучше сконцентрироваться на том, чтобы объяснять студенту, почему он неправ в каждом конкретном куске кода, какие могут быть с ним проблемы.
Вот вы не поверите, приходится останавливаться. Циклы и функции — два краеугольных камня попервоначалу. Потом — указатели...
То, о чем вы говорите — это уже студенты постарше. А начинающих — именно циклам и функциям учить приходится...
Поэтому и собираю опыт, кто как учит или учил...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
SC>>Не мыслить, а делать — это само получится, не надо этому учить LVV>В том-то и дело, что "само" — не получается... Учить приходится...
Получится. побольше практики и разбор кода творят чудеса.
LVV>>> А размышлять на более высоком уровне — на архитектурном, например. А циклы пусть пишутся правильно на автомате. SC>>На автомате пишется то, что часто используется. Все. Никакими другими средствами автоматизм не достигается. SC>>К тому же, что-то мне не кажется, что особенности написания простейших циклов — то, чему стоит уделять много внимания. Лучше сконцентрироваться на том, чтобы объяснять студенту, почему он неправ в каждом конкретном куске кода, какие могут быть с ним проблемы. LVV>Вот вы не поверите, приходится останавливаться. Циклы и функции — два краеугольных камня попервоначалу. Потом — указатели...
Я преподавал программирование у студенток-первокурсниц специальности "документоведение", не надо мне рассказывать
LVV>То, о чем вы говорите — это уже студенты постарше. А начинающих — именно циклам и функциям учить приходится...
Пусть сразу привыкают к принятию инженерных решений, а не к решению "задач на цикл"
Re[3]: Как обучать технике программирования?
От:
Аноним
Дата:
20.04.10 17:06
Оценка:
Здравствуйте, Mystic, Вы писали:
M>Техника есть у шахматистов, у математиков и т. п. Так что сокращение мыщц можно заменить на последовательность действий (необязательно физических).
У меня вот тут под рукой книжка по шахматам. Первый раздел называется "шахматная азбука", второй — "элементы шахматной партии", третий — "основы шахматной тактики". И это всё основы, и это не есть "техника" в том понимании, которое существует у спортсменов, музыкантов и художников. Не подменяйте понятия.
Здравствуйте, Mystic,
ГМ>>Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные".
M>Свод правил это все-таки методология. "Непрерывно меняющиеся" звучит достаточно расплывчато. Все в нашем мире меняется, что медленнее, что быстрее. "Индивидуальные" это особенность. Но главное, такое определение не позволяет сказать: техника программирования этого студента хромает. Не включено сюда сравнение
--
IMHO, вполне можно сравнивать изменение техники программирования одного и того же студента с течением времени, наблюдая (или не наблюдая) изменение "хромоты" его кода, нет?
Здравствуйте, 31415926, Вы писали:
3>А то попросишь на собеседовании J2EE team lead`а расписать, что происходит в сети от момента ввода URL до показа страницы — а он глазами хлопает и мычит что-то невнятное. Это чудо, если человек, 5+ лет разрабатывающий Интернет приложения способен объяснить разницу между TCP и UDP.
А вот это как раз и результат чистого "практического" подхода. Когда человек прогуливает лекции и вместо них кодит на похапе ("современном рабочем", по вашей классификации, языке программирования) дорвеи-магазины-порталы (на этом же можно заработать "много бабла", и время — деньги, некогда менять его на малозначимую ерунду, да?), изобретая на ходу велосипеды или решая попутно "неразрешимые" для него задачи, открывая каждый раз америку. Это тот результат, когда человек научился пользоваться поиском готового кода в гугле и готовыми классами HttpRequest и подобными.
Да-да, именно такие "практики" считают, что отличие протоколов только в параметрах инициализации сокета. А уж если надо, чтобы человек различал по-нормальному, извольте прочитать ему курс сетевых протоколов, в котором отражаются базовые принципы, стоящие за тем и за другим, извольте рассказать про модель OSI, про её уровни, рассказать, что TCP работает на совершенно другом уровне, нежели тот же HTTP и т.д. Вот только к программированию всё это относится чуть более, чем никак (открытие, да?) И, кстати, о чудо — взору откроется так же и то, что подобные принципы работают даже там, где и не пахнет никакими протоколами. А без этого наш глупыш-практик, нахватавшийся знаний по верхам, никогда не заметит настоящих решений, ведь он будет считать это излишней тупой ботвой.
Ведь вы же не такой "практик"? Зачем тогда писать глупости?
Здравствуйте, LaptevVV, Вы писали: LVV>ВО! Очень показательно! Нынче " в моде...". А правильно ли это? Обработка исключений — это, между прочим, нелокальный переход... Который нарушает один из принципов, указанных Робертом Мартином в книге "Чистый код":
Значит, этот принцип применим только в частных случаях. Исключения — это все-таки распространенная "хорошая практика" (в отсутствии противопоказаний), и писать код без них не всем нравится. Это еще не идет речь о более мощной нелокальности, навроде call/cc.
LVV>программа должна читаться сверху вних без прыжков в разные места.
Ну это разве что очень маленькая программа. Автору этого высказывания предлагаю почитать, например, исходники линукса. Ага, сверху вниз.
LVV>Различие заложено в конструкции машины: выполнение команд управления принципиально отличается от выполнения других команд.
Не возьмусь спорить о различных архитектурах и системах команд, но у того же x86 в системе команд нет разделения на "стейтмент" и "экспрешн" в том понимании, в котором оно имеется в императивных языках. Я бы даже сказал, что все суть стейтмент. Так что никакой вины системы команд в разделении нет.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, 31415926, Вы писали:
3>>А то попросишь на собеседовании J2EE team lead`а расписать, что происходит в сети от момента ввода URL до показа страницы — а он глазами хлопает и мычит что-то невнятное. Это чудо, если человек, 5+ лет разрабатывающий Интернет приложения способен объяснить разницу между TCP и UDP.
А>А вот это как раз и результат чистого "практического" подхода. Когда человек прогуливает лекции и вместо них кодит на похапе ("современном рабочем", по вашей классификации, языке программирования) дорвеи-магазины-порталы (на этом же можно заработать "много бабла", и время — деньги, некогда менять его на малозначимую ерунду, да?), изобретая на ходу велосипеды или решая попутно "неразрешимые" для него задачи, открывая каждый раз америку. Это тот результат, когда человек научился пользоваться поиском готового кода в гугле и готовыми классами HttpRequest и подобными.
А>Да-да, именно такие "практики" считают, что отличие протоколов только в параметрах инициализации сокета. А уж если надо, чтобы человек различал по-нормальному, извольте прочитать ему курс сетевых протоколов, в котором отражаются базовые принципы, стоящие за тем и за другим, извольте рассказать про модель OSI, про её уровни, рассказать, что TCP работает на совершенно другом уровне, нежели тот же HTTP и т.д. Вот только к программированию всё это относится чуть более, чем никак (открытие, да?) И, кстати, о чудо — взору откроется так же и то, что подобные принципы работают даже там, где и не пахнет никакими протоколами. А без этого наш глупыш-практик, нахватавшийся знаний по верхам, никогда не заметит настоящих решений, ведь он будет считать это излишней тупой ботвой.
А>Ведь вы же не такой "практик"? Зачем тогда писать глупости?
Надеюсь, что не такой. Вот только как нарисованная Вами картина соотносится с моими высказываниями — убейте, не пойму. Я где-нибудь призывал к отказу от изучения основ или агитировал заменить систематическое образование халтурой? По-моему, я возражал против беспредметного теоретизирования (типа классификации циклов) при обучении и призывал обучать программированию на практических примерах. Зачем приписывать мне противоположную крайность? Я не знаю PHP, но подозреваю, что и на его основе можно дать человеку неплохую основу. Хотя, как мне кажется, языки со строгой типизацией для начального образования все-таки предпочтительней.
Здравствуйте, LaptevVV, Вы писали:
LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
Сегодня спросили А. Степанова, что он думает по этому поводу. Вкратце (надеюсь он не обидится за моё вольное переложение) так: при обучении очень важна традиционность. В частности был камень в огород американских ВУЗов, где сменилось 4 или 5 базовых языка. В этом отношении в России, по его мнению, очень правильная программа: сначала Паскаль с алгоритмами (Вирт + Кнут), потом ассемблер, а затем С (+ классы). Дальше, чем больше используется стандартных компонент — тем лучше.
А ещё он говорил такое (мы как-то не очень согласились, и это, кажется, его расстроило) — важна принадлежность к сообществу, т.е. принятие (в том числе и на веру — вот тут мы спорили) прошлых достижений — разумеется, без фанатизма, так чтоб это не мешало развитию. (Например, он очень сожалел, что из-за стремления к поддержанию всех имеющихся фич в STL, я так понял, речь в основном шла о неявных кастах, не успели проработать концепты, и их не включат в новый стандарт)
А ещё, по его мнению, важно постоянно помнить о производительности кода — что не надо приносить эффективность в жертву обощению. И если есть эффективные частные реализации, не надо от них отказываться в пользу красивых обобщений. (Тут бы некоторый камень в огород функционального программирования)
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
LVV>>Что следует понимать под техникой программирования и как ее надо "ставить"?
F>Сегодня спросили А. Степанова, что он думает по этому поводу. Вкратце (надеюсь он не обидится за моё вольное переложение) так: при обучении очень важна традиционность. В частности был камень в огород американских ВУЗов, где сменилось 4 или 5 базовых языка. В этом отношении в России, по его мнению, очень правильная программа: сначала Паскаль с алгоритмами (Вирт + Кнут), потом ассемблер, а затем С (+ классы). Дальше, чем больше используется стандартных компонент — тем лучше.
Прекрасно! Взгляд со стороны — свежим ветерком повеяло. F>А ещё он говорил такое (мы как-то не очень согласились, и это, кажется, его расстроило) — важна принадлежность к сообществу, т.е. принятие (в том числе и на веру - вот тут мы спорили) прошлых достижений — разумеется, без фанатизма, так чтоб это не мешало развитию. (Например, он очень сожалел, что из-за стремления к поддержанию всех имеющихся фич в STL, я так понял, речь в основном шла о неявных кастах, не успели проработать концепты, и их не включат в новый стандарт)
О! Тут я с ним полностью согласен! Иначе получается по принципу революции: старый мир разрушим до основания, новый — наш — построим. F>А ещё, по его мнению, важно постоянно помнить о производительности кода — что не надо приносить эффективность в жертву обощению. И если есть эффективные частные реализации, не надо от них отказываться в пользу красивых обобщений. (Тут бы некоторый камень в огород функционального программирования)
Во! С этим тоже спорить не приходится. Каждая конкретная программа должна проходить две стадии: работает без ошибок, эффектив6нно работает без ошибок...
Большое спасибо!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[24]: Как обучать технике программирования?
От:
Аноним
Дата:
21.04.10 05:13
Оценка:
Здравствуйте, 31415926, Вы писали:
3>Надеюсь, что не такой. Вот только как нарисованная Вами картина соотносится с моими высказываниями — убейте, не пойму. Я где-нибудь призывал к отказу от изучения основ или агитировал заменить систематическое образование халтурой? По-моему, я возражал против беспредметного теоретизирования (типа классификации циклов) при обучении и призывал обучать программированию на практических примерах. Зачем приписывать мне противоположную крайность? Я не знаю PHP, но подозреваю, что и на его основе можно дать человеку неплохую основу. Хотя, как мне кажется, языки со строгой типизацией для начального образования все-таки предпочтительней.
Изначально мне бросилось в глаза ваше недовольство образовательным подходом, выраженное в ряде фраз и в частности в данной фразе: 3>Так и будете преподавать — программирование как набор абстрактных принципов отдельно, Интернет — отдельно, БД — отдельно.
С этим я позволил себе не согласиться, а потом уж я случайно понаписал лишнего, не имея целью приписать вам некие крайности. Извините. Тем более, что по остальным пунктам с вами нельзя не согласиться.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Mystic, Вы писали:
M>>Техника есть у шахматистов, у математиков и т. п. Так что сокращение мыщц можно заменить на последовательность действий (необязательно физических).
А>У меня вот тут под рукой книжка по шахматам. Первый раздел называется "шахматная азбука", второй — "элементы шахматной партии", третий — "основы шахматной тактики". И это всё основы, и это не есть "техника" в том понимании, которое существует у спортсменов, музыкантов и художников. Не подменяйте понятия.
Ну так надо взять книги для более продвинутого уровня. Я не подменяю понятия, я просто говорю, что слово "техника" применяется к шахматам. Например, Карлсен и Крамник шахматисты с высокой техникой. А у такого-то шахматиста техника хромает. Например:
Филигранная техника седьмого чемпиона мира (Смыслова) до сих пор является эталонной. Внимательное изучение его партий – лучший способ научиться играть окончания. Контуры эндшпиля Смыслов видел задолго, еще с дебюта. При этом он вовсе не сушил игру, не стремился любой ценой к разменам.
или
Главная особенность стиля Таля-комментатора заключается в самоиронии. Вместо серьезного, вдумчивого вещателя истин мы в его примечаниях видим невероятно живого, остроумного человека, который очень доброжелательно относится к шахматистам и постоянно подшучивает над самим собой. Всем известна его фраза к неудачно проведенным окончаниям своих партий: «А далее в бой вступила моя прославленная техника!»
или
Благодаря сотням партий, сыгранным в матчах между двумя «К», был совершен прорыв во многих дебютных вариантах, созданы десятки превосходных партий с образцовой игрой во всех стадиях. Подобно Алехину, который перед матчем в Буэнос-Айресе поставил перед собой и успешно решил задачу догнать Капабланку в позиционной игре, Гарри сумел прямо по ходу первого матча – титанического безлимитного марафона – усилить свою игру. Молодой и горячий южный парень научился хорошо играть скучные технические позиции, терпеливо обороняться, лавировать и быстро перестраиваться по ходу партии. Играя в стиле Карпова, он сумел устоять на поле соперника! А в своей стихии – дебютной подготовке и комбинационной игре – Гарри оказался сильнее, что и позволило ему, в конечном счете, стать новым чемпионом мира. А затем отстоять титул в новых матчах.
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>IMHO, вполне можно сравнивать изменение техники программирования одного и того же студента с течением времени, наблюдая (или не наблюдая) изменение "хромоты" его кода, нет?
Над техникой можно работать, но техника бывает и врожденной Некое чувство гармонии. Бывают еще колебания в зависимости от эмоционального состояния, настроения и т. п.
ГМ>C уважением, ГМ>Геннадий Майко.
Здравствуйте, LaptevVV, Вы писали:
LVV>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей. LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
Финальный бой не забуду никогда. Тогда мне, еще мальчишке, объяснили, в чем разница между спортсменом и человеком, который прошел через настоящие боевые действия. Соперником был офицер, командир разведывательной роты из Рязани. Он нанес столь стремительный и сильный удар, что проломил защитную маску, закрывавшую мое лицо. Естественно, он и победил.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, LaptevVV, Вы писали:
LVV>Это непонятно. Как это — непрерывно меняющийся? Техника, она на то и техника, что она на уровне подсознания работает. То есть постоянна.
А если техника базируется на предположении, что всё в мире меняется?
LVV>Кроме того, например, корпоративный стандарт кодирования сразу пресекает всякое "свободное изложение".
Правильный стандарт рекомендует, а не пресекает. А правильные корпорации понимают, что такие вещи как стандарт кодирования — это набор предпочтений, которые со временем могут меняться.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaptevVV, Вы писали:
LVV>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!
Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
LVV>>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно! IT>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
Не... В любой борьбе приемов — десятки.
И с другой стороны, может быть просто в программировании не выделены БАЗОВЫЕ приемы? А просто мешают в кучу приемы разного уровня?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>И с другой стороны, может быть просто в программировании не выделены БАЗОВЫЕ приемы? А просто мешают в кучу приемы разного уровня?
Если их не выделили за 50 лет, то может нечего выделать?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
LVV>>И с другой стороны, может быть просто в программировании не выделены БАЗОВЫЕ приемы? А просто мешают в кучу приемы разного уровня?
IT>Если их не выделили за 50 лет, то может нечего выделать?
А как же приемы стиля "китайского программирования" или "я вам, суки, помодифицирую" ?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaptevVV, Вы писали:
LVV>>И с другой стороны, может быть просто в программировании не выделены БАЗОВЫЕ приемы? А просто мешают в кучу приемы разного уровня?
IT>Если их не выделили за 50 лет, то может нечего выделать?
Я думаю, они существуют, просто имеют исключительно учебное значение. Это как в начальной школе, когда учили детей писать буквы, использовали в прописях элементы этих букв — для постановки руки.
Здравствуйте, deniok, Вы писали:
IT>>Если их не выделили за 50 лет, то может нечего выделать?
D>Я думаю, они существуют, просто имеют исключительно учебное значение. Это как в начальной школе, когда учили детей писать буквы, использовали в прописях элементы этих букв — для постановки руки.
Думаю, не существуют. В правописании и боевых искусствах понятна конечная цель упраждений. В боевых искусствах ученики повторяют за мастером чтобы поставить удар и научиться его применять. Палочки нужны, чтобы научиться из них составлять буквы и в конечном счёте писать.
Зачем учиться писать циклы — не понятно Какая цель? Циклы ради циклов?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaptevVV, Вы писали:
LVV>>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!
IT>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
Кха... Цикл, условие и подпрограмма.
Этого хватит на любую (кроме совсем уж экзотики) программу.
Здравствуйте, IT, Вы писали:
D>>Я думаю, они существуют, просто имеют исключительно учебное значение. Это как в начальной школе, когда учили детей писать буквы, использовали в прописях элементы этих букв — для постановки руки.
Я тоже так думаю. Только об уровне чуть повыше. То есть не отдельные элементы буквы, а буква. Цикл — это буква в программировании. И надо научиться правильно писать эту букву. IT>Думаю, не существуют. В правописании и боевых искусствах понятна конечная цель упраждений. В боевых искусствах ученики повторяют за мастером чтобы поставить удар и научиться его применять. Палочки нужны, чтобы научиться из них составлять буквы и в конечном счёте писать. IT>Зачем учиться писать циклы — не понятно Какая цель? Циклы ради циклов?
Затем же, зачем учатся наносить удар — чтобы применять.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, alpha21264, Вы писали:
IT>>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками. A>Кха... Цикл, условие и подпрограмма. A>Этого хватит на любую (кроме совсем уж экзотики) программу.
Это правильно. Но речь о дальнейшем разделении.
Я тут уже упоминал, что основных видов цикла — два: полный перебор и поиск по заданному условию. И техника написания этих циклов несколько различается. Например, я категорически не приемлю использование для поиска цикла for. Этот оператор как раз ПРЕДНАЗНАЧЕН для полного перебора.
Или вот для процедур могут быть такие правила:
Например:
— запрет иметь больше одного цикла в процедуре — речь о независимых циклах; вложенные... часто тоже надо в процедуру, а при обучении — всегда; но в ряде случаев, конечно, они необходимы по эффективности;
— запрет организовывать циклы на уровне вложенности глубже, чем 1 (т.е. IF WHILE ... END ELSE .. END — можно, а вот в более глубокие IF-ы фигачить уже нельзя; разрешение на 1-м уровне — из опыта, опять же, что часто какая-то охрана перед циклом бывает нужна; а вот если глубже — то уже явно надо делить логику);
Мне кажется — это очень хорошие правила при постановке техники программирования.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Я тут уже упоминал, что основных видов цикла — два: полный перебор и поиск по заданному условию. И техника написания этих циклов несколько различается. Например, я категорически не приемлю использование для поиска цикла for. Этот оператор как раз ПРЕДНАЗНАЧЕН для полного перебора.
Чушь! for не предназначен для полного перебора. Для полного перебора больше предназначен оператор foreach (кстати, как насчет операторов map, dolist, loop, foldr, foldl и т.д. или list comprehensions?). А for, раз уж на то пошло, изначально предназначен для того, чтобы производить некоторое действие заданное число раз. И то, что в низкоуровневых языках (типа С/С++) отсутствует оператор foreach, и его приходится эмулировать for'ом, не меняет предназначение for'а.
И это не говоря уже о том, что выделение только двух видов циклов и притягивание за уши всего остального к этим двум видам — несусветная глупость. С такой логикой и эти два вида можно свести к одному: "выполнение тела, пока условие не сработает".
LVV>Или вот для процедур могут быть такие правила: LVV>
LVV>Например:
LVV>- запрет иметь больше одного цикла в процедуре — речь о независимых циклах; вложенные... часто тоже надо в процедуру, а при обучении — всегда; но в ряде случаев, конечно, они необходимы по эффективности;
LVV>- запрет организовывать циклы на уровне вложенности глубже, чем 1 (т.е. IF WHILE ... END ELSE .. END — можно, а вот в более глубокие IF-ы фигачить уже нельзя; разрешение на 1-м уровне — из опыта, опять же, что часто какая-то охрана перед циклом бывает нужна; а вот если глубже — то уже явно надо делить логику);
LVV>Мне кажется — это очень хорошие правила при постановке техники программирования.
А мне кажется, что вы слишком узко мыслите (в рамках примитивного императивного низкоуровневого подхода), и придумываете себе (а что самое отвратительное, и студентов заставляете делать то же самое) какие-то жесткие вымышленные ограничения, не имеющие ничего общего с умением программировать. В результате безвозвратно ломаете людям мозги. Подумайте над этим.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, LaptevVV, Вы писали:
LVV>>Я тут уже упоминал, что основных видов цикла — два: полный перебор и поиск по заданному условию. И техника написания этих циклов несколько различается. Например, я категорически не приемлю использование для поиска цикла for. Этот оператор как раз ПРЕДНАЗНАЧЕН для полного перебора. А>Чушь! for не предназначен для полного перебора. Для полного перебора больше предназначен оператор foreach (кстати, как насчет операторов map, dolist, loop, foldr, foldl и т.д. или list comprehensions?). А for, раз уж на то пошло, изначально предназначен для того, чтобы производить некоторое действие заданное число раз. И то, что в низкоуровневых языках (типа С/С++) отсутствует оператор foreach, и его приходится эмулировать for'ом, не меняет предназначение for'а.
Те же яйца, тока вид сбоку. Под полным перебором понимается не только физические существующие элементы контейнеров, но и выполнение действий заданное число раз. Главное, что это — не поиск. А>И это не говоря уже о том, что выделение только двух видов циклов и притягивание за уши всего остального к этим двум видам — несусветная глупость. С такой логикой и эти два вида можно свести к одному: "выполнение тела, пока условие не сработает".
Не... У нас же два основных квантора: для любого (перебор) и существует (поиск).
Если нужно истчо, то ничто не мешает нам добавить в нашей отдельной специфической задаче все, что считаем нужным. Но изначально-то учат только два: для любого и существует. LVV>>Или вот для процедур могут быть такие правила: LVV>>
LVV>>Например:
LVV>>- запрет иметь больше одного цикла в процедуре — речь о независимых циклах; вложенные... часто тоже надо в процедуру, а при обучении — всегда; но в ряде случаев, конечно, они необходимы по эффективности;
LVV>>- запрет организовывать циклы на уровне вложенности глубже, чем 1 (т.е. IF WHILE ... END ELSE .. END — можно, а вот в более глубокие IF-ы фигачить уже нельзя; разрешение на 1-м уровне — из опыта, опять же, что часто какая-то охрана перед циклом бывает нужна; а вот если глубже — то уже явно надо делить логику);
LVV>>Мне кажется — это очень хорошие правила при постановке техники программирования. А>А мне кажется, что вы слишком узко мыслите (в рамках примитивного императивного низкоуровневого подхода), и придумываете себе (а что самое отвратительное, и студентов заставляете делать то же самое) какие-то жесткие вымышленные ограничения, не имеющие ничего общего с умением программировать. В результате безвозвратно ломаете людям мозги. Подумайте над этим.
Ко мне приходят уже с "поломанными" мозгами. А эти правила не выдуманные, а реальный многолетний опыт реального программиста. Который просто их так сформулировал.
И напомню вам принцип KISS — эти правила как раз отвечают этому принципу в полной мере.
И лучше СРАЗУ приучать чела следовать этому принципу, чем он на работе (как я в свое время) потом и кровью самостоятельно придет к тому же.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, LaptevVV, Вы писали: LVV>>Мне кажется — это очень хорошие правила при постановке техники программирования. MC>А чем эти правила обоснованы?
1. Принцип KISS — вы согласны?
2. Это реальный многолетний опыт реального программиста.
3. Посмотрите на Рефакторинг. Там неоднократно призывается уменьшать размеры методов, оставляя за методом ЕДИНСТВЕННУЮ задачу.
4. Это не абсолютный запрет. Если очень хочется — то можно. Но не нужно...
Если у вас много вложенных циклов в процедуре, то как раз есть смысл пересмотреть ее структуру с точки зрения рефакторинга...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали: MC>>Здравствуйте, LaptevVV, Вы писали: LVV>>>Мне кажется — это очень хорошие правила при постановке техники программирования. MC>>А чем эти правила обоснованы? LVV>1. Принцип KISS — вы согласны?
Нет. То, что ты предлагаешь — это требования к структуре программы, не учитывающие ее семантику. Эти требования всегда будут усложнять программу за счет появления в ней лишних сущностей, которые вводятся ради удовлетворения ограничений.
LVV>2. Это реальный многолетний опыт реального программиста.
Кого именно? Тут ведь rsdn — куда ни плюнь — в программиста попадешь.
LVV>3. Посмотрите на Рефакторинг. Там неоднократно призывается уменьшать размеры методов, оставляя за методом ЕДИНСТВЕННУЮ задачу.
Тут речь о задачах — т.е. семантике. Ты же накладываешь ограничения на структуру.
LVV>4. Это не абсолютный запрет. Если очень хочется — то можно. Но не нужно...
В чем тогда смысл правила? "Если очень хочется, то можно" — это, на мой взгляд, неудачная позиция. Правильнее определить допустимые и недопустимые варианты использования.
LVV>Если у вас много вложенных циклов в процедуре, то как раз есть смысл пересмотреть ее структуру с точки зрения рефакторинга...
Ты изначально говорил и про независимые тоже.
Re[8]: Как обучать технике программирования?
От:
Аноним
Дата:
27.04.10 07:57
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Не... У нас же два основных квантора: для любого (перебор) и существует (поиск).
И какое отношение эти кванторы имеют к циклам, а? Тем более, что математические высказывания зачастую содержат оба этих квантора: "для любого Х существует Y, такой что Z". Следуя вашей логике, это должно вылиться в цикл, который одновременно будет и перебором и поиском?
LVV>Ко мне приходят уже с "поломанными" мозгами.
Ну так надо их выправлять, а не ломать до конца.
LVV>А эти правила не выдуманные, а реальный многолетний опыт реального программиста. Который просто их так сформулировал. LVV>И напомню вам принцип KISS — эти правила как раз отвечают этому принципу в полной мере.
Не всегда и не везде. И кстати, принцип KISS куда как более полезно рассказать, чем городить огород из правил, которые из него вытекают.
LVV>И лучше СРАЗУ приучать чела следовать этому принципу, чем он на работе (как я в свое время) потом и кровью самостоятельно придет к тому же.
Ну так и надо приучать. Вот только при чём тут правила написания циклов и прочее, я вот не пойму, хоть убейте. Это настолько низкоуровневая и узкая веточка дерева программирования, что тратить время на ковыряние в её малозначимых деталях я считаю слишком расточительным.
Здравствуйте, LaptevVV, Вы писали:
LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев): LVV>а) полный перебор; LVV>б) поиск по заданному условию; LVV>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так! LVV>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск.
Да, именно так. Нужно много задач, что бы чел распознавал эти циклы. После этого ему будет очень просто перейти на более высокий уровень. Например фильтр, преобразование, последовательсть и тд.
Обычно в ВУЗе циклы даются мимоходом — вот синтаксис, вот задача, вот экзамен.
LVV>И про остальные типовые задачи тоже так нужно сделать. Только я чего-то не видал подхода именно от такой печки. В учебниках изучают язык, а не технику программирования. Такого слова даже не встречается.
Дык в том и то и проблема. Когда у человека нет техники, то про ООП и функциональщину можно забыть.
Здравствуйте, 31415926, Вы писали:
3>Мне это проблема представляется надуманной. Согласитесь, что как-то странно сначала учить технике на примере какого-то специального языка. Собственно зачем? Чтобы потом человек хорошо программировал в реальной жизни уже на реальном языке? Так не проще ли (и практичней) оттачивать технику на "боевом" языке.
Проще, да, преподавателю не надо учить чтото еще. А вот учащемуся придется преодолевать совершенно другую нагрузку.
Здравствуйте, Mr.Cat, Вы писали:
MC>В третьих, цитата иллюстрирует то, как отважно императивные программисты борются с проблемами, которые сами же себе создают. Если бы в языке не было уродского деления на выражения и стейтменты (а все было бы выражениями — как в ФЯ) — обозначенной проблемы не стояло бы.
А если бы люди рождались сразу математиками, то программировали бы на языке покруче хаскеля на три порядка.
Пример Лиспа и прочих функциональных показал, что люди делают выбор не в пользу ФП. Отсюда и деление навыражений и стейтменты, и никак не наоборот
Здравствуйте, IT, Вы писали:
LVV>>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!
IT>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
Зато и осваиваются много быстрее. Простые приемы в БИ осваиваются годами.
Здравствуйте, IT, Вы писали:
IT>Думаю, не существуют. В правописании и боевых искусствах понятна конечная цель упраждений. В боевых искусствах ученики повторяют за мастером чтобы поставить удар и научиться его применять. Палочки нужны, чтобы научиться из них составлять буквы и в конечном счёте писать.
IT>Зачем учиться писать циклы — не понятно Какая цель? Циклы ради циклов?
Писать не циклы, а решать задчи которые закрепляют понимание того, что такое итерация.
После этого можно переходить к более высоким материям, как например последовательности, фильтры, преобразования.
Здравствуйте, Mr.Cat, Вы писали:
LVV>>1. Принцип KISS — вы согласны? MC>Нет. То, что ты предлагаешь — это требования к структуре программы, не учитывающие ее семантику. Эти требования всегда будут усложнять программу за счет появления в ней лишних сущностей, которые вводятся ради удовлетворения ограничений.
Ни в коем случае. Арифметика, да и вообще вся математика, как она дается в школе суть избытточность и лишние сущности с тз проф. математика.
Зато в обучении без этого никак.
LVV>>3. Посмотрите на Рефакторинг. Там неоднократно призывается уменьшать размеры методов, оставляя за методом ЕДИНСТВЕННУЮ задачу. MC>Тут речь о задачах — т.е. семантике. Ты же накладываешь ограничения на структуру.
И правильно. Для обучения нужно наложить ограничения на структуру. Это везде и всюду используется.
Нужно что бы человек научился распознавать паттерны. Оные паттерны ему сначала подсовывают в рафинированом, чистом виде, что бы распознать было легко и так же легко запомнить.
Уже после этого можно усложнять. Но начинать с самых ограниченых, т.е. настолько чистых, что в природе оные не существуют.
В постановке техники ничего необычного нет — вначале ситуации вырожденные, т.е. дети складывают 2+2, боксеры бьют по воздуху стоя на месте а штангисты приседают с пустым грифом.
Все освается понемногу и по отдельности, а со временем сложность наращивается.
Цель такого дела — довести технику до автоматизма, что бы даже в стрессовой ситуации не было сбоя.
Здравствуйте, Ikemefula, Вы писали:
I>Пример Лиспа и прочих функциональных показал, что люди делают выбор не в пользу ФП.
Это потому что после обсуждаемого обучения циклам и всяким низкоуровневым сущностям на языке C/С++ человек уже не может думать в другой парадигме. Он начинает думать в терминах циклов и у него возникают сложности уже с пониманием простой рекурсии, не говоря уже о других "сложных" материях, которые он пытается внутри своей головы выразить в "циклическом" базисе. А если подобное обучение венчается еще С++'ным ООП, то можно считать, что мозги сломаны навсегда.
Здравствуйте, Ikemefula, Вы писали:
I>И правильно. Для обучения нужно наложить ограничения на структуру. Это везде и всюду используется.
До сих пор помню, как преподша по матанализу на семинарах заставляла явно расписывать, какую делаешь замену переменной при взятии интеграла, и не засчитывала ответ. При том, что ответ можно было вообще в уме получить. Убивать надо таких преподов с такими ограничениями на структуру и такими воззрениями на обучение, которые заставляют зубрить синтаксис, уделяя мало времени сути.
I>Нужно что бы человек научился распознавать паттерны. Оные паттерны ему сначала подсовывают в рафинированом, чистом виде, что бы распознать было легко и так же легко запомнить. I>Уже после этого можно усложнять. Но начинать с самых ограниченых, т.е. настолько чистых, что в природе оные не существуют.
Только не ограничивать паттерны циклами, ага? А то человек после такого обучения кроме циклов ничего воспринимать не сможет.
I>В постановке техники ничего необычного нет — вначале ситуации вырожденные, т.е. дети складывают 2+2, боксеры бьют по воздуху стоя на месте а штангисты приседают с пустым грифом. I>Все освается понемногу и по отдельности, а со временем сложность наращивается.
Если брать пример с детьми и "2+2" и продолжать дальше, то получится так:
человек приходит в ВУЗ и ему там говорят: "забудьте то, что учили в школе", и дальше начинают не наращивать, а ПЕРЕУЧИВАТЬ. Вот те люди, в которых жестко сидит школьная парадигма, не смогут воспринимать (и не воспринимают) новый материал. Они никогда не поймут матанализ, высшую алгебру, тфкп и прочие умные вещи в терминах счётных палочек и складывания 2+2.
А теперь вернёмся к программированию. То, что вы тут предлагаете — это и есть вдалбливание этой "школьной" парадигмы, после которой перестроиться на более общий и широкий уровень уже просто так не получится. А так как подобное явление распространено повсеместно, то и получаем ситуации, когда "люди делают выбор не в пользу ФП", когда простые вещи делаются сложно не в подходящем базисе технологий, просто потому что люди думают в ограниченных рамках.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Ikemefula, Вы писали:
I>>И правильно. Для обучения нужно наложить ограничения на структуру. Это везде и всюду используется.
А>До сих пор помню, как преподша по матанализу на семинарах заставляла явно расписывать, какую делаешь замену переменной при взятии интеграла, и не засчитывала ответ. При том, что ответ можно было вообще в уме получить. Убивать надо таких преподов с такими ограничениями на структуру и такими воззрениями на обучение, которые заставляют зубрить синтаксис, уделяя мало времени сути.
Мало решить задачу, нужно решить её методически правильно. В противном случае будет делать огрехи.
Суть как раз простая — овладеть методикой решения задач. Только в этом случае ты можешь перейти на следующий уровень мышления. В противном случаей абстракциям будут мешать огрехи.
I>>Уже после этого можно усложнять. Но начинать с самых ограниченых, т.е. настолько чистых, что в природе оные не существуют.
А>Только не ограничивать паттерны циклами, ага? А то человек после такого обучения кроме циклов ничего воспринимать не сможет.
А ктото здесь сказал что надо циклами ограничить ? Вроде было ясно обозначено, что циклы лишь пример, а не догма.
А>Если брать пример с детьми и "2+2" и продолжать дальше, то получится так: А>человек приходит в ВУЗ и ему там говорят: "забудьте то, что учили в школе", и дальше начинают не наращивать, а ПЕРЕУЧИВАТЬ. Вот те люди, в которых жестко сидит школьная парадигма, не смогут воспринимать (и не воспринимают) новый материал. Они никогда не поймут матанализ, высшую алгебру, тфкп и прочие умные вещи в терминах счётных палочек и складывания 2+2.
Поймут и понимают. Нет никакого противеречия между школьным подходм и вуовским.
Вся разница — в школе сильный упор на воспитание, а в вуз люди счтаются уже воспитанными, потому контроля меньше.
Все что касаеться обучения никакого противоречия нет.
Как правило, сильный выпускник школы имеет неплохой задел на первый курс а то и два.
А>А теперь вернёмся к программированию. То, что вы тут предлагаете — это и есть вдалбливание этой "школьной" парадигмы, после которой перестроиться на более общий и широкий уровень уже просто так не получится.
Нет никакой школьной парадигмы в том понимании как ты описал.
>А так как подобное явление распространено повсеместно, то и получаем ситуации, когда "люди делают выбор не в пользу ФП",
ФП никогда не будет доминирующей парадигмой. 50 лет эволюции программрования во всех транах это хорошо показали.
>когда простые вещи делаются сложно не в подходящем базисе технологий, просто потому что люди думают в ограниченных рамках.
В том то и дело. И так во всех странах на всех континентах. Состояние педагогических наук не оставляет желать другого.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Ikemefula, Вы писали:
I>>Пример Лиспа и прочих функциональных показал, что люди делают выбор не в пользу ФП.
А>Это потому что после обсуждаемого обучения циклам и всяким низкоуровневым сущностям на языке C/С++ человек уже не может думать в другой парадигме.
Это сильное заблуждение. ФП нельзя освоить без императивного.
Здравствуйте, Ikemefula, Вы писали:
А>>До сих пор помню, как преподша по матанализу на семинарах заставляла явно расписывать, какую делаешь замену переменной при взятии интеграла, и не засчитывала ответ. При том, что ответ можно было вообще в уме получить. Убивать надо таких преподов с такими ограничениями на структуру и такими воззрениями на обучение, которые заставляют зубрить синтаксис, уделяя мало времени сути.
I>Мало решить задачу, нужно решить её методически правильно. В противном случае будет делать огрехи. I>Суть как раз простая — овладеть методикой решения задач. Только в этом случае ты можешь перейти на следующий уровень мышления. В противном случаей абстракциям будут мешать огрехи.
Речь о том, что при обучении слишком много времени уделяется "методической правильности" в ущерб уровню абстракций. Даже чересчур много.
А>>Если брать пример с детьми и "2+2" и продолжать дальше, то получится так: А>>человек приходит в ВУЗ и ему там говорят: "забудьте то, что учили в школе", и дальше начинают не наращивать, а ПЕРЕУЧИВАТЬ. Вот те люди, в которых жестко сидит школьная парадигма, не смогут воспринимать (и не воспринимают) новый материал. Они никогда не поймут матанализ, высшую алгебру, тфкп и прочие умные вещи в терминах счётных палочек и складывания 2+2.
I>Поймут и понимают. Нет никакого противеречия между школьным подходм и вуовским. I>Вся разница — в школе сильный упор на воспитание, а в вуз люди счтаются уже воспитанными, потому контроля меньше. I>Все что касаеться обучения никакого противоречия нет. I>Как правило, сильный выпускник школы имеет неплохой задел на первый курс а то и два.
Да вот не понимают. Большинство не может воспринимать многомерные пространства, интегралы-градиенты и прочие математические вещи, пытаясь представить их в рамках привычных им сущностей и понятий. Всё, что получается понять — это геометрический/физический смысл производной, площадь под кривой и т.д. А реальное понимание обычно приходит только потом, если вообще приходит.
А>>А теперь вернёмся к программированию. То, что вы тут предлагаете — это и есть вдалбливание этой "школьной" парадигмы, после которой перестроиться на более общий и широкий уровень уже просто так не получится.
I>Нет никакой школьной парадигмы в том понимании как ты описал.
Я взял слово "школьный" в кавычки. В данном случае "школьная парадигма" означает уровень знаний, потребный для простейшего бытового применения и которому учат на начальном этапе обучения. И который не годится в качестве платформы для дальнейшего обучения. Механика Ньютона, пригодная для бытовых нужд — лишь частный случай эйнштейновской теории, однако чтобы перейти на этот качественно новый уровень, придется поменять в своей голове основы. Другое дело, что старый опыт может помочь сделать это быстрее, а может и наоборот, стать непреодолимой преградой. Вот в программировании как правило так и бывает.
>>А так как подобное явление распространено повсеместно, то и получаем ситуации, когда "люди делают выбор не в пользу ФП", I>ФП никогда не будет доминирующей парадигмой. 50 лет эволюции программрования во всех транах это хорошо показали.
А кто говорит о доминировании? Речь о том, что люди выбирают неправильные инструменты. В том числе и потому что не могут мыслить вне тех рамок, которые им вдолбили на начальном этапе обучения. Более того, они и внутри этих рамок мыслят лишь на уровне "методической правильности". И это печально.
Re[19]: Как обучать технике программирования?
От:
Аноним
Дата:
28.04.10 09:42
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Это сильное заблуждение. ФП нельзя освоить без императивного.
Вот это как раз и есть заблуждение. ФП можно прекрасно освоить без императивщины. Она может потребоваться только для понимания того, во что выливаются функциональные конструкции на низком уровне. Для оптимизации по скорости, памяти и т.д. А чтобы мыслить в этой парадигме, их знание изначально не требуется. Например, для освоения SQL (хоть это и не ФП как таковое), никакой императивщины не нужно, она только отвлекает от сути.
Кроме того, никто не предлагает переходить на ФП. Я лишь говорил о том, что при однобоком подходе (каковым является зубрёжка только лишь императивных сущностей и конструкций) у человека костенеют мозги, и он потом с трудом воспринимает (если вообще воспринимает) другие парадигмы.
Здравствуйте, Аноним, Вы писали:
I>>Мало решить задачу, нужно решить её методически правильно. В противном случае будет делать огрехи. I>>Суть как раз простая — овладеть методикой решения задач. Только в этом случае ты можешь перейти на следующий уровень мышления. В противном случаей абстракциям будут мешать огрехи.
А>Речь о том, что при обучении слишком много времени уделяется "методической правильности" в ущерб уровню абстракций. Даже чересчур много.
Методическая правильность решения задач должна проверяться во всех задачах.
Ошибки в технике проявляются тотально и исправить их крайне тяжело.
В университете ставитяс именно техника, потому что те знания, которые там дают, вообще говоря мизер по сравнению с тем, что выпускник получит в течении уже первого года работы.
I>>Все что касаеться обучения никакого противоречия нет. I>>Как правило, сильный выпускник школы имеет неплохой задел на первый курс а то и два.
А>Да вот не понимают. Большинство не может воспринимать многомерные пространства, интегралы-градиенты и прочие математические вещи, пытаясь представить их в рамках привычных им сущностей и понятий.
А это проблема людей вообще. Абстрактное мышление нельзя привить просто так. Его нужно прокачивать.
И при этом огрехи в технике и становятся препятствием.
>Всё, что получается понять — это геометрический/физический смысл производной, площадь под кривой и т.д. А реальное понимание обычно приходит только потом, если вообще приходит.
Разумеетяс. Понимание это реальный опыт + время. нельзя скормить n-задач, лишь бы как решить и получить понимание.
Есть одно эмпирическое правило — профессионалами становятся минимум за 10 лет.
Образование сроится так, что бы время в ВУЗе вошло в эти 10 лет.
I>>Нет никакой школьной парадигмы в том понимании как ты описал.
А>Я взял слово "школьный" в кавычки. В данном случае "школьная парадигма" означает уровень знаний, потребный для простейшего бытового применения и которому учат на начальном этапе обучения. И который не годится в качестве платформы для дальнейшего обучения. Механика Ньютона, пригодная для бытовых нужд — лишь частный случай эйнштейновской теории, однако чтобы перейти на этот качественно новый уровень, придется поменять в своей голове основы.
Не надо ничего менять в голове. Сложность наращиваетя постепенно, точно так же как и блины на штанге.
И всегда обучение идет от частного к общему.
>Другое дело, что старый опыт может помочь сделать это быстрее, а может и наоборот, стать непреодолимой преградой. Вот в программировании как правило так и бывает.
В программировании хорошо если 10% спецов имеют хорошую подготовку. Остальные либо самоучки со слабой подготовкой и без профильного образованя, либо лица приравненые к оным.
А>А кто говорит о доминировании? Речь о том, что люди выбирают неправильные инструменты.
Люди выбирают инструмены соответсвующие своему уровню мышления.
>В том числе и потому что не могут мыслить вне тех рамок, которые им вдолбили на начальном этапе обучения. Более того, они и внутри этих рамок мыслят лишь на уровне "методической правильности". И это печально.
Даже идеальное образование не сделает человека умнее. Абстрактное мышление нельзя привить сверху, его можно только прокачать с самых нулей. бОльшинство не заинтересовано в этом в принципе.
Большинсво программистов не занимается самообразованием, да и в универе учились для галочки или не по профилю.
Нет никаких чудес, 90% людей не заинтересовано в развитии, по этой причине императивное программирование бует рулить и через 100 лет.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Ikemefula, Вы писали:
I>>Это сильное заблуждение. ФП нельзя освоить без императивного.
А>Вот это как раз и есть заблуждение. ФП можно прекрасно освоить без императивщины. А>Она может потребоваться только для понимания того, во что выливаются функциональные конструкции на низком уровне.
Интересно, как ты поймешь во что выливается, если ты это не освоил ?
>Для оптимизации по скорости, памяти и т.д.
т.е. буквально везде, где есть хоть какие то ограничения связаные с ресурсами.
>А чтобы мыслить в этой парадигме, их знание изначально не требуется.
Что бы мыслить в этой парадигме нужно иметь хорошо прокачаное абстрактое мышление. По другому никак.
>Например, для освоения SQL (хоть это и не ФП как таковое), никакой императивщины не нужно, она только отвлекает от сути.
Я около года назад хорошо посмотрел, как ипользуют SQL люди без императивщины.
Их ничего не отвлекало, только с парой запросов пришлось разбираться более месяца.
А>Кроме того, никто не предлагает переходить на ФП. Я лишь говорил о том, что при однобоком подходе (каковым является зубрёжка только лишь императивных сущностей и конструкций) у человека костенеют мозги, и он потом с трудом воспринимает (если вообще воспринимает) другие парадигмы.
Проблема в отсутствии развития у большинства программистов. Просто в силу отсутствия желания. Потому они и застревают на императивном уровне.
Re[14]: Как обучать технике программирования?
От:
Аноним
Дата:
28.04.10 10:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>В программировании хорошо если 10% спецов имеют хорошую подготовку. Остальные либо самоучки со слабой подготовкой и без профильного образованя, либо лица приравненые к оным.
I>Даже идеальное образование не сделает человека умнее. Абстрактное мышление нельзя привить сверху, его можно только прокачать с самых нулей. бОльшинство не заинтересовано в этом в принципе.
I>Большинсво программистов не занимается самообразованием, да и в универе учились для галочки или не по профилю.
I>Нет никаких чудес, 90% людей не заинтересовано в развитии, по этой причине императивное программирование бует рулить и через 100 лет.
Мы же не говорим про 90%. Вопрос стоит в том, как обучать людей. А обучать их надо так, чтобы задействовать возможности оставшихся 10% по максимуму. Ибо если ориентироваться на 90% (то есть в том случае, когда синтаксис ставится важнее семантики, когда отчёт о решении важнее самого решения и т.д.), то толку не будет ни от тех, ни от других.
Re[21]: Как обучать технике программирования?
От:
Аноним
Дата:
28.04.10 10:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:
А>>Вот это как раз и есть заблуждение. ФП можно прекрасно освоить без императивщины. А>>Она может потребоваться только для понимания того, во что выливаются функциональные конструкции на низком уровне.
I>Интересно, как ты поймешь во что выливается, если ты это не освоил ?
Мы же говорим про возможность овладевания ФП без императивщины. И овладеть можно. Остальное — да, уже другой вопрос.
>>Для оптимизации по скорости, памяти и т.д.
I>т.е. буквально везде, где есть хоть какие то ограничения связаные с ресурсами.
Этот момент вторичен в контексте поставленного вопроса.
>>А чтобы мыслить в этой парадигме, их знание изначально не требуется.
I>Что бы мыслить в этой парадигме нужно иметь хорошо прокачаное абстрактое мышление. По другому никак.
А прокачивается оно математикой, а не императивным программированием.
>>Например, для освоения SQL (хоть это и не ФП как таковое), никакой императивщины не нужно, она только отвлекает от сути.
I>Я около года назад хорошо посмотрел, как ипользуют SQL люди без императивщины. I>Их ничего не отвлекало, только с парой запросов пришлось разбираться более месяца.
Стоит ли говорить, что чистые императивщики мудрят с запросами не хуже
Здравствуйте, Аноним, Вы писали:
А>Мы же говорим про возможность овладевания ФП без императивщины. И овладеть можно. Остальное — да, уже другой вопрос.
Это остальное и есть главная причина.
Просто попрограммировать речи не идет, речь идет об индустрии.
I>>т.е. буквально везде, где есть хоть какие то ограничения связаные с ресурсами.
А>Этот момент вторичен в контексте поставленного вопроса.
Программирование вне индустрии вобщем то не существует. А то бы я с тобой согласился.
I>>Что бы мыслить в этой парадигме нужно иметь хорошо прокачаное абстрактое мышление. По другому никак.
А>А прокачивается оно математикой, а не императивным программированием.
И математикой, и программированием.
I>>Я около года назад хорошо посмотрел, как ипользуют SQL люди без императивщины. I>>Их ничего не отвлекало, только с парой запросов пришлось разбираться более месяца.
А>Стоит ли говорить, что чистые императивщики мудрят с запросами не хуже
Здравствуйте, Аноним, Вы писали:
I>>Нет никаких чудес, 90% людей не заинтересовано в развитии, по этой причине императивное программирование бует рулить и через 100 лет.
А>Мы же не говорим про 90%. Вопрос стоит в том, как обучать людей.
Как обучать людей посмотри на МИТ и Стенфорд. Они отказались от функциональщины для обучения. Одни перешли на Питон, другие — на Си.
>А обучать их надо так, чтобы задействовать возможности оставшихся 10% по максимуму. Ибо если ориентироваться на 90% (то есть в том случае, когда синтаксис ставится важнее семантики, когда отчёт о решении важнее самого решения и т.д.), то толку не будет ни от тех, ни от других.
Обучать нужно столько, что бы удовлетворить потребности индустрии. А сейчас удовлетворяется спрос, вместо потребностей.
Re[23]: Как обучать технике программирования?
От:
Аноним
Дата:
28.04.10 12:58
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>>>т.е. буквально везде, где есть хоть какие то ограничения связаные с ресурсами. А>>Этот момент вторичен в контексте поставленного вопроса. I>Программирование вне индустрии вобщем то не существует. А то бы я с тобой согласился.
Хе-хе. Значит в контексте поставленного вопроса возражений нет?
А по поводу индустрии скажу так: я нигде не утверждал, что следует применять только ФП. Я ЗА использование разных подходов для увеличения эффективности. Только ты зачем-то прицепился отдельно к ФП и затеял холивар на пустом месте.
I>>>Что бы мыслить в этой парадигме нужно иметь хорошо прокачаное абстрактое мышление. По другому никак. А>>А прокачивается оно математикой, а не императивным программированием. I>И математикой, и программированием.
И что же такого серьезного в программировании есть, от чего можно сильно прокачать абстрактное мышление?
Re[16]: Как обучать технике программирования?
От:
Аноним
Дата:
28.04.10 13:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Как обучать людей посмотри на МИТ и Стенфорд. Они отказались от функциональщины для обучения. Одни перешли на Питон, другие — на Си.
Насчёт Си не скажу, а вот питон, как высокоуровневый язык, как раз-таки позволяет рассмотреть разные подходы и парадигмы. Так что говорить "отказались от ФП" неправильно.
Здравствуйте, Undying, Вы писали:
U>С каких это пор while стал удобным способом поиска?
Со времен Кнута и Вирта. Читайте классиков. U>Всю жизнь поиск производил так:
Нет. U>
U>string[] items;
U>foreach (string item in items)
U>{ if (item == condition)
U> return item;
U>}
U>
U>Если foreach в языке нет, тогда через for, что похуже, конечно, но понятно как делать: U>
U>for (int i = 0; i < items.Length; ++i)
U>{ if (items[i] == condition)
U> return items[i];
U>}
U>
Это не структурные конструкции — выход из середины цикла... U>А while для поиска как можно использовать?
Еще раз: классику почитайте. U>ps U>Я согласен с тем, что технику программирования нужно ставить, но использование while для поиска это антитехника.
Это утверждение слишком категорично...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
I>>>>т.е. буквально везде, где есть хоть какие то ограничения связаные с ресурсами. А>>>Этот момент вторичен в контексте поставленного вопроса. I>>Программирование вне индустрии вобщем то не существует. А то бы я с тобой согласился.
А>Хе-хе. Значит в контексте поставленного вопроса возражений нет?
Если взять и выбросить 90% индустрии, то да, ты прав.
А>А по поводу индустрии скажу так: я нигде не утверждал, что следует применять только ФП. Я ЗА использование разных подходов для увеличения эффективности. Только ты зачем-то прицепился отдельно к ФП и затеял холивар на пустом месте.
Я не цеплялся к ФП. Я говорю, что парадигму и языке неверно рассматривать в отрыве от индустрии.
А>>>А прокачивается оно математикой, а не императивным программированием. I>>И математикой, и программированием.
А>И что же такого серьезного в программировании есть, от чего можно сильно прокачать абстрактное мышление?
Давай на примере — я покажу тебе два кусочка кода, а ты мне скажешь, у кого из авторов более сильный матбекграунд ? Идёт ?
Здравствуйте, Аноним, Вы писали:
I>>Как обучать людей посмотри на МИТ и Стенфорд. Они отказались от функциональщины для обучения. Одни перешли на Питон, другие — на Си.
А>Насчёт Си не скажу, а вот питон, как высокоуровневый язык, как раз-таки позволяет рассмотреть разные подходы и парадигмы. Так что говорить "отказались от ФП" неправильно.
Отказались от обучения на основе ФП. Само ФП в программе есть, только его изучают чуть позже.
Re[25]: Как обучать технике программирования?
От:
Аноним
Дата:
28.04.10 15:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:
А>>А по поводу индустрии скажу так: я нигде не утверждал, что следует применять только ФП. Я ЗА использование разных подходов для увеличения эффективности. Только ты зачем-то прицепился отдельно к ФП и затеял холивар на пустом месте. I>Я не цеплялся к ФП. Я говорю, что парадигму и языке неверно рассматривать в отрыве от индустрии.
А я где-то утверждал обратное?
А>>И что же такого серьезного в программировании есть, от чего можно сильно прокачать абстрактное мышление? I>Давай на примере — я покажу тебе два кусочка кода, а ты мне скажешь, у кого из авторов более сильный матбекграунд ? Идёт ?
Нет, ты лучше покажи примеры абстракций в программировании, которые не поймёт средний математик. А то ты в сторону уходишь куда-то.
Здравствуйте, Аноним, Вы писали:
А>>>А по поводу индустрии скажу так: я нигде не утверждал, что следует применять только ФП. Я ЗА использование разных подходов для увеличения эффективности. Только ты зачем-то прицепился отдельно к ФП и затеял холивар на пустом месте. I>>Я не цеплялся к ФП. Я говорю, что парадигму и языке неверно рассматривать в отрыве от индустрии.
А>А я где-то утверждал обратное?
Может не ты а другой аноним
А>>>И что же такого серьезного в программировании есть, от чего можно сильно прокачать абстрактное мышление? I>>Давай на примере — я покажу тебе два кусочка кода, а ты мне скажешь, у кого из авторов более сильный матбекграунд ? Идёт ?
А>Нет, ты лучше покажи примеры абстракций в программировании, которые не поймёт средний математик. А то ты в сторону уходишь куда-то.
Ты сам куда то уходишь.
Код многих математиков настолько императивный, что хочется буквально смеяться.
Могу показать на отличном примере и объяснить на нём же
Re[27]: Как обучать технике программирования?
От:
Аноним
Дата:
28.04.10 15:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I> Может не ты а другой аноним
Надо будет как-нибудь зарегаться что ли
А>>Нет, ты лучше покажи примеры абстракций в программировании, которые не поймёт средний математик. А то ты в сторону уходишь куда-то. I>Ты сам куда то уходишь. I>Код многих математиков настолько императивный, что хочется буквально смеяться. I>Могу показать на отличном примере и объяснить на нём же
Ну покажи-расскажи
Только речь про код изначально не идёт ведь. Умение красиво кодировать можно относительно быстро натренировать при наличии соответствующего матбэкграунда. Проверено.
Здравствуйте, Аноним, Вы писали:
А>Мы же не говорим про 90%. Вопрос стоит в том, как обучать людей. А обучать их надо так, чтобы задействовать возможности оставшихся 10% по максимуму. Ибо если ориентироваться на 90% (то есть в том случае, когда синтаксис ставится важнее семантики, когда отчёт о решении важнее самого решения и т.д.), то толку не будет ни от тех, ни от других.
Вы, наверное, не обратили внимание, что речь как раз идет о семантике. Цикл для перебора — это одна семантика, цикли для поиска — совсем другая семантика. При чем здесь синтаксис?
Это очень хорошо, что семантика задачи (поиск или перебор) явным образом отражается в синтаксисе. Проще запомнить паттерн.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Undying, Вы писали:
U>>>С каких это пор while стал удобным способом поиска? LVV>>Со времен Кнута и Вирта. Читайте классиков. U>Ссылки на авторитетов, без приведения аргументов не стоят ничего. U>>>
U>>>string[] items;
U>>>foreach (string item in items)
U>>>{ if (item == condition)
U>>> return item;
U>>>}
U>>>
LVV>>Это не структурные конструкции — выход из середины цикла... U>Вы альтернативный код с while приведите. Чтобы было что сравнивать как по понятности, так и по лаконичности.
Блин!
Пересказывать классиков — неблагодарная задача — лучше, чем у них, у меня вряд ли получится...
Откройте Кнута — том 3 или Вирта "Алгоритмы и структуры данных",
и посмотрите линейный поиск с барьером.
Если вы до сих пор этого еще не сделали, то сделайте это сейчас.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
U>>Ссылки на авторитетов, без приведения аргументов не стоят ничего. U>>>>
U>>>>string[] items;
U>>>>foreach (string item in items)
U>>>>{ if (item == condition)
U>>>> return item;
U>>>>}
U>>>>
LVV>>>Это не структурные конструкции — выход из середины цикла... U>>Вы альтернативный код с while приведите. Чтобы было что сравнивать как по понятности, так и по лаконичности.
LVV>Откройте Кнута — том 3 или Вирта "Алгоритмы и структуры данных", LVV>и посмотрите линейный поиск с барьером. LVV>Если вы до сих пор этого еще не сделали, то сделайте это сейчас.
Т.е. поиск с помощью while настолько сложен, что Вы его даже написать в посте не в состоянии? На написание поиска с помощью foreach у меня ушло секунд 15.
LVV>Пересказывать классиков — неблагодарная задача — лучше, чем у них, у меня вряд ли получится...
Я от Вас и не требую лучше, чем у них, мне интересно Ваше объяснение, чем код с while (который Вы до сих пор не привели) для поиска, лучше кода с foreach.
ps
Вы, кстати, с учеников что требуете, цитирования Кнута или собственного понимания?
Здравствуйте, LaptevVV, Вы писали:
LVV>Это не структурные конструкции — выход из середины цикла...
Кстати, понятно, откуда брались такие ограничения у классиков. При обилии в тогдашних языках ресурсов требующих явного освобождения и отсутствии finally действительно требовалось чтобы точка выхода у блока кода была всего одна. Однако в современных языках (том же шарпе) ресурсов требующих явного освобождения очень немного, а для случаев когда явное освобождение все же требуется есть using/finally. Соответственно появилась возможность прерывать алгоритм именно в том месте, где это требуется по условию задачи, что резко увеличило читабельность кода. Очень плохо, что Вы этого не понимаете и до сих пор догматически учите студентов подходам, которые были меньшим злом раньше, но устарели для современных языков.
Здравствуйте, LaptevVV, Вы писали:
LVV>Пересказывать классиков — неблагодарная задача — лучше, чем у них, у меня вряд ли получится...
Кстати, когда к Вам студент подходит и просит объяснить то, что ему непонятно, Вы его также почитать Кнута отправляете?
Re[16]: Как обучать технике программирования?
От:
Аноним
Дата:
29.04.10 05:41
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Аноним, Вы писали:
А>>Мы же не говорим про 90%. Вопрос стоит в том, как обучать людей. А обучать их надо так, чтобы задействовать возможности оставшихся 10% по максимуму. Ибо если ориентироваться на 90% (то есть в том случае, когда синтаксис ставится важнее семантики, когда отчёт о решении важнее самого решения и т.д.), то толку не будет ни от тех, ни от других. LVV>Вы, наверное, не обратили внимание, что речь как раз идет о семантике.
Не только. Выше ведь были какие-то примеры с запретом на большую вложенность циклов и т.д. К семантике подобные запреты не имеют отношения.
LVV>Цикл для перебора — это одна семантика, цикли для поиска — совсем другая семантика.
Это правильно. Вот только от вас так и не последовало внятного объяснения, почему видов циклов у вас два.
LVV>Это очень хорошо, что семантика задачи (поиск или перебор) явным образом отражается в синтаксисе.
Да как же она отражается, когда не отражается? Маловато ваших двух операторов для передачи семантического смысла задачи.
PS. Кстати, что там с кванторами-то? Во что выльется высказывание "для любого Х существует Y, такой, что выполняется Z"?
А если я захочу над кванторами проделать операцию отрицания? В математической записи мне достаточно будет поставить знак отрицания над выражением. А как это будет отражено в вонючих тупых циклах for и while? И сейчас будете утверждать, что эти циклы связаны с кванторами и отражают семантически перебор и поиск?
Здравствуйте, alpha21264, Вы писали:
IT>>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
A>Кха... Цикл, условие и подпрограмма. A>Этого хватит на любую (кроме совсем уж экзотики) программу.
Ага. В одном только switch/case можно десяток приёмов насчитать. А по поводу выхода из двух циклов сразу у нас тут помнится на пол года баталия была.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaptevVV, Вы писали:
IT>>Зачем учиться писать циклы — не понятно Какая цель? Циклы ради циклов? LVV>Затем же, зачем учатся наносить удар — чтобы применять.
Цикл без остальной части программы не имеет самостоятельного смысла, в отличии от удара. Поэтому я и спрашиваю, какой ответ будет давать преподаватель на вопрос студентов "зачем это надо?".
Если нам не помогут, то мы тоже никого не пощадим.
LVV>Например:
LVV>- запрет иметь больше одного цикла в процедуре — речь о независимых циклах; вложенные... часто тоже надо в процедуру, а при обучении — всегда; но в ряде случаев, конечно, они необходимы по эффективности;
LVV>- запрет организовывать циклы на уровне вложенности глубже, чем 1 (т.е. IF WHILE ... END ELSE .. END — можно, а вот в более глубокие IF-ы фигачить уже нельзя; разрешение на 1-м уровне — из опыта, опять же, что часто какая-то охрана перед циклом бывает нужна; а вот если глубже — то уже явно надо делить логику);
LVV>Мне кажется — это очень хорошие правила при постановке техники программирования.
Это абсолютно бессмысленные правила. Вот попробуй обосновать почему нельзя иметь более одного цикла в процедуре? Только используя логику, а не предпочтения типа общих фраз на подобии "это плохая практика" или "мне так кажется".
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, LaptevVV, Вы писали:
LVV>>Пересказывать классиков — неблагодарная задача — лучше, чем у них, у меня вряд ли получится...
U>Кстати, когда к Вам студент подходит и просит объяснить то, что ему непонятно, Вы его также почитать Кнута отправляете?
1. Вы — не студент, а позиционируете себя профи.
2. Смотря какой студент и какой вопрос. Если я восемь раз рассказывал и 10 раз показывал, все уже все поняли, и я сам уже все понял И вдруг вылезает чудо, которое на лекции не ходило, лабы не делало, и заявляет, что ничего не понимает — таких однозначно посылаю. Если чел хоть чуть чуть приложился к теме, то и вопросы у него конкретные и точные — таким и нужно объяснять...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
LVV>>Вы, наверное, не обратили внимание, что речь как раз идет о семантике. А>Не только. Выше ведь были какие-то примеры с запретом на большую вложенность циклов и т.д. К семантике подобные запреты не имеют отношения.
Имеют. Если в проце много вложенных циклов и проца — сложная, значит надо подумать, порефакторить и упростит. "Выделение метода" у Мартина Фаулера называется. Практически первый прием рефакторинга. LVV>>Цикл для перебора — это одна семантика, цикли для поиска — совсем другая семантика. А>Это правильно. Вот только от вас так и не последовало внятного объяснения, почему видов циклов у вас два.
Предложите больше. Если найдете... LVV>>Это очень хорошо, что семантика задачи (поиск или перебор) явным образом отражается в синтаксисе. А>Да как же она отражается, когда не отражается? Маловато ваших двух операторов для передачи семантического смысла задачи.
Две задачи — два цикла
1. Задача перебора — цикл for$
2. Задача поиска — цикл while
А>PS. Кстати, что там с кванторами-то? Во что выльется высказывание "для любого Х существует Y, такой, что выполняется Z"?
Для любого — это перебор... :
Псевдокод:
for x in set do
if predicate(y)=true do somthing(z);
Перебираем ВСЕ элементы х. В цикле выполняем действия только для тех х, для которых существует y (то есть предикат принимает значение истина) выполняем действие Z.
Что неясно? А>А если я захочу над кванторами проделать операцию отрицания? В математической записи мне достаточно будет поставить знак отрицания над выражением. А как это будет отражено в вонючих тупых циклах for и while? И сейчас будете утверждать, что эти циклы связаны с кванторами и отражают семантически перебор и поиск?
Посмотрите выше и увидите...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaptevVV, Вы писали:
IT>>>Зачем учиться писать циклы — не понятно Какая цель? Циклы ради циклов? LVV>>Затем же, зачем учатся наносить удар — чтобы применять.
IT>Цикл без остальной части программы не имеет самостоятельного смысла, в отличии от удара.
Прежде, чем весь удар тренировать. Боксер, например, разучивает элементы стойки, положение ног, положение тела.
И тренер его поправляет, если положение ног или тела при ударе не соответствует. Я знаю, я в бокс некоторое время ходил.
Так и цикл — это часть большой задачи, но без "разучивания" цикла весь "удар"-программа получатся хуже, чем при "разучивании".
Поэтому я и спрашиваю, какой ответ будет давать преподаватель на вопрос студентов "зачем это надо?".
Вот затем и надо. Технику написания цикла поставить...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>2. Смотря какой студент и какой вопрос. Если я восемь раз рассказывал и 10 раз показывал, все уже все поняли, и я сам уже все понял
Я настолько не понятно сформулировал вопрос, что Вы до сих пор не способны написать пример использования while для поиска?
Re[18]: Как обучать технике программирования?
От:
Аноним
Дата:
29.04.10 11:10
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Вы, наверное, не обратили внимание, что речь как раз идет о семантике. А>>Не только. Выше ведь были какие-то примеры с запретом на большую вложенность циклов и т.д. К семантике подобные запреты не имеют отношения. LVV>Имеют. Если в проце много вложенных циклов и проца — сложная,
Скажите, а студентам вы так же материал рассказываете и на вопросы отвечаете?
LVV> Имеют. Если в проце много вложенных циклов и проца — сложная, значит надо подумать, порефакторить и упростит. "Выделение метода" у Мартина Фаулера называется. Практически первый прием рефакторинга.
Только изначальная конструкция будет иметь такой же смысл, какой и был. Таким образом, денотационная семантика тут не затрагивается. Меняется лишь операционная, да и то не сильно.
LVV>>>Цикл для перебора — это одна семантика, цикли для поиска — совсем другая семантика. А>>Это правильно. Вот только от вас так и не последовало внятного объяснения, почему видов циклов у вас два. LVV>Предложите больше. Если найдете...
Значит внятного объяснения так и не будет?
LVV>>>Это очень хорошо, что семантика задачи (поиск или перебор) явным образом отражается в синтаксисе. А>>Да как же она отражается, когда не отражается? Маловато ваших двух операторов для передачи семантического смысла задачи. LVV>Две задачи — два цикла LVV>1. Задача перебора — цикл for$ LVV>2. Задача поиска — цикл while
А>>PS. Кстати, что там с кванторами-то? Во что выльется высказывание "для любого Х существует Y, такой, что выполняется Z"? LVV>Для любого — это перебор... : LVV>Псевдокод: LVV>
LVV>for x in set do
LVV> if predicate(y)=true do somthing(z);
LVV>
LVV>Перебираем ВСЕ элементы х. В цикле выполняем действия только для тех х, для которых существует y (то есть предикат принимает значение истина) выполняем действие Z. LVV>Что неясно?
1) вы неверно трактовали математическое высказывание. Z — не действие, Z — это условие. Например: "для любого эпсилон > 0, существует такая дельта > 0, при которой |F(x)-F(x+дельта)| < эпсилон". В общем, в этом духе.
2) по вашей логике, квантор существования должен вылиться в цикл while, его у вас нет.
3) Неясно, как применить операцию отрицания кванторов. В математике достаточно поставить нужный значок. Что нужно добавить в вашем псевдокоде для аналогичного действия?
А>>А если я захочу над кванторами проделать операцию отрицания? В математической записи мне достаточно будет поставить знак отрицания над выражением. А как это будет отражено в вонючих тупых циклах for и while? И сейчас будете утверждать, что эти циклы связаны с кванторами и отражают семантически перебор и поиск? LVV>Посмотрите выше и увидите...
Там ничего нет, что можно было бы принять за ответ на мои вопросы.
Здравствуйте, LaptevVV, Вы писали: LVV>только две схемы цикла LVV>Это же два квантора: для любого и существует.
Вообще, программы (и циклы как их составляющие) принято ассоциировать с доказательствами утверждений, но не самими утверждениями (и кванторами как их составляющими). Т.е. при определении фундаментальных конструкций языка надо отталкиваться не от утверждений, а от фундаментальных приемов их доказательств (от противного, индукция и т.п.).
On 29/04/2010 07:11, LaptevVV wrote:
> Откройте Кнута — том 3 или Вирта "Алгоритмы и структуры данных", > и посмотрите линейный поиск с барьером. > Если вы до сих пор этого еще не сделали, то сделайте это сейчас.
Ужоснах. Если имеется в виду вот это, то в век обобщённого программирования, популяризации функциональнщины и иммутабельных структур данных за такие алгоритмы нужно принудительно мумифицировать, в лучшем случае разрешать писать игрушки для сотовых телефонов.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alpha21264, Вы писали:
IT>>>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
A>>Кха... Цикл, условие и подпрограмма. A>>Этого хватит на любую (кроме совсем уж экзотики) программу.
IT>Ага. В одном только switch/case можно десяток приёмов насчитать. А по поводу выхода из двух циклов сразу у нас тут помнится на пол года баталия была.
Ну я же смайлик поставил!
Эээ... А о чем спорили? Надо ли выходить из двух циклов?
Программирование — искусство многоуровневое.
Есть приемы и выше и ниже того уровня, что я сказал.
Например то, как переменные именовать и как выбрать синтаксис языка плагинов.
Да, а еще отладка есть, регрессии там всякие...
Здравствуйте, ., Вы писали:
.>On 29/04/2010 07:11, LaptevVV wrote:
>> Откройте Кнута — том 3 или Вирта "Алгоритмы и структуры данных", >> и посмотрите линейный поиск с барьером. >> Если вы до сих пор этого еще не сделали, то сделайте это сейчас. .>Ужоснах. Если имеется в виду вот это, то в век обобщённого программирования, популяризации функциональнщины и иммутабельных структур данных за такие алгоритмы нужно принудительно мумифицировать, в лучшем случае разрешать писать игрушки для сотовых телефонов.
Так и скажите, что классиков — не читали... И читать не собираетесь...
Таким образом, техникой программирования элементарных составляющих программы просто не владеете...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, LaptevVV, Вы писали: LVV>>только две схемы цикла LVV>>Это же два квантора: для любого и существует. MC>Вообще, программы (и циклы как их составляющие) принято ассоциировать с доказательствами утверждений, но не самими утверждениями (и кванторами как их составляющими). Т.е. при определении фундаментальных конструкций языка надо отталкиваться не от утверждений, а от фундаментальных приемов их доказательств (от противного, индукция и т.п.).
Уточню. Я просто провел простейшую аналогию между двумя кванторами и двумя циклами.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, LaptevVV, Вы писали:
LVV>>2. Смотря какой студент и какой вопрос. Если я восемь раз рассказывал и 10 раз показывал, все уже все поняли, и я сам уже все понял
U>Я настолько не понятно сформулировал вопрос, что Вы до сих пор не способны написать пример использования while для поиска?
А вы не способны посмотреть Вирта или Кнута? Вот если непонятно будет — я объясню...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
LVV>> Имеют. Если в проце много вложенных циклов и проца — сложная, значит надо подумать, порефакторить и упростит. "Выделение метода" у Мартина Фаулера называется. Практически первый прием рефакторинга. А>Только изначальная конструкция будет иметь такой же смысл, какой и был. Таким образом, денотационная семантика тут не затрагивается. Меняется лишь операционная, да и то не сильно.
Ну дык! Я ничего против этого и не имею... LVV>>>>Цикл для перебора — это одна семантика, цикли для поиска — совсем другая семантика. А>>>Это правильно. Вот только от вас так и не последовало внятного объяснения, почему видов циклов у вас два. LVV>>Предложите больше. Если найдете... А>Значит внятного объяснения так и не будет?
Дык я ж и говорю: если сможете найти еще, я с удовольствием добавлю ваш вариант в качестве третьего. Я пока не вижу... А>>>PS. Кстати, что там с кванторами-то? Во что выльется высказывание "для любого Х существует Y, такой, что выполняется Z"? LVV>>Для любого — это перебор... : LVV>>Псевдокод: LVV>>
LVV>>for x in set do
LVV>> if predicate(y)=true do somthing(z);
LVV>>
LVV>>Перебираем ВСЕ элементы х. В цикле выполняем действия только для тех х, для которых существует y (то есть предикат принимает значение истина) выполняем действие Z. LVV>>Что неясно? А>1) вы неверно трактовали математическое высказывание. Z — не действие, Z — это условие. Например: "для любого эпсилон > 0, существует такая дельта > 0, при которой |F(x)-F(x+дельта)| < эпсилон". В общем, в этом духе. А>2) по вашей логике, квантор существования должен вылиться в цикл while, его у вас нет.
Так бы и говорили сразу...
У нас в курсе матанализа формулировали это так:
Для любого наперед заданного сколь угодно малого эпсилон > 0 существует ... Далее по тексту.
В такой формулировке — это поиск дельты, удовлетворяющего условию. Епсилон — наперед задано. А>3) Неясно, как применить операцию отрицания кванторов. В математике достаточно поставить нужный значок. Что нужно добавить в вашем псевдокоде для аналогичного действия?
Отрицание квантора "для любого" — это квантор "существует". И наоборот. Не существует — это для любого.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
On 29/04/2010 18:35, LaptevVV wrote:
> Так и скажите, что классиков — не читали... И читать не собираетесь... > Таким образом, техникой программирования элементарных составляющих
Покажите эту технику, не я один любопытствую!
> программы просто не владеете...
А оно точно надо? Игра в бисер?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Аноним, Вы писали:
А>>Значит внятного объяснения так и не будет? LVV>Дык я ж и говорю: если сможете найти еще, я с удовольствием добавлю ваш вариант в качестве третьего. Я пока не вижу...
Значит, как не было, так и нет
LVV>Так бы и говорили сразу...
Я считаю, что там это и так очевидно было любому, кто учил матанализ.
А>>3) Неясно, как применить операцию отрицания кванторов. В математике достаточно поставить нужный значок. Что нужно добавить в вашем псевдокоде для аналогичного действия? LVV>Отрицание квантора "для любого" — это квантор "существует". И наоборот. Не существует — это для любого.
Блин, я же вопрос конкретный задал. И опять на вопрос ответа нет.
Черт побери, от вас, преподавателя, невозможно получить ответы на конкретные вопросы? Из вас их невозможно вытянуть так же, как из студента-двоечника, когда вытягиваешь его хотя бы на тройку. Не стыдно, а? А ведь потенциальные покупатели ваших книжек, да и ваши студенты тоже могут читать этот форум. Перед ними-то хоть позориться перестаньте.
Здравствуйте, LaptevVV, Вы писали: LVV>Уточню. Я просто провел простейшую аналогию между двумя кванторами и двумя циклами.
Ну вот тут уже с тобой человек спорит насчет необоснованности такой аналогии. Я просто привожу довод в пользу его точки зрения.
Здравствуйте, LaptevVV, Вы писали:
U>>Я настолько не понятно сформулировал вопрос, что Вы до сих пор не способны написать пример использования while для поиска? LVV>А вы не способны посмотреть Вирта или Кнута? Вот если непонятно будет — я объясню...
Мда, не хотел бы я у Вас учиться. Тот же Павел Дворкин даже если говорит спорные вещи, как правило достаточно внятно их аргументирует, соответственно умению думать он учить студентов способен. А если Вы и студентов учите воспринимать мнение авторитетов как истину в последней инстанции, то в результате получаете начетчиков вместо инженеров.
>> Так и скажите, что классиков — не читали... И читать не собираетесь... >> Таким образом, техникой программирования элементарных составляющих .>Покажите эту технику, не я один любопытствую!
Вот жеж блин! Я для чего это затеял?! Чтоб народ кончструктивно высказывался, а тут как обычно, даже само слово "техника" стали обс...рать! >> программы просто не владеете... .>А оно точно надо? Игра в бисер?
Ну, играйте... А я думаю, как учить...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
А>>>Значит внятного объяснения так и не будет? LVV>>Дык я ж и говорю: если сможете найти еще, я с удовольствием добавлю ваш вариант в качестве третьего. Я пока не вижу... А>Значит, как не было, так и нет
Ну так вы можете предложить третий квантор? Если можете — давайте, пообсуждаем. Я — не могу. LVV>>Так бы и говорили сразу... А>Я считаю, что там это и так очевидно было любому, кто учил матанализ.
Ага. А>>>3) Неясно, как применить операцию отрицания кванторов. В математике достаточно поставить нужный значок. Что нужно добавить в вашем псевдокоде для аналогичного действия? LVV>>Отрицание квантора "для любого" — это квантор "существует". И наоборот. Не существует — это для любого. А>Блин, я же вопрос конкретный задал. И опять на вопрос ответа нет.
А я конкретно отвечаю. Это очевидно для всех, кто учил матлогику. А>Черт побери, от вас, преподавателя, невозможно получить ответы на конкретные вопросы? Из вас их невозможно вытянуть так же, как из студента-двоечника, когда вытягиваешь его хотя бы на тройку. Не стыдно, а? А ведь потенциальные покупатели ваших книжек, да и ваши студенты тоже могут читать этот форум. Перед ними-то хоть позориться перестаньте.
Дык вы хотя бы представьтесь сначала. Чтоб я знал, кто тут такой умный...
Буду обращаться за советами.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, LaptevVV, Вы писали: LVV>>Уточню. Я просто провел простейшую аналогию между двумя кванторами и двумя циклами. MC>Ну вот тут уже с тобой человек спорит насчет необоснованности такой аналогии. Я просто привожу довод в пользу его точки зрения.
Тут человек требует, чтобы я написал отрицание квантора. Я — написал. Он не понял.
Я тоже не понимаю, почему я не могу провести такую аналогию.
Когда она лично мне прекрасно объясняет наличие двух ОСНОВНЫХ форм цикла.
Если кто подскажет еще — я только порадуюсь и возьму на вообужение.
А то пока только одни вопли, что этого не может быть.
Давайте перейдем от критиканство к конструктивности.
Предложите третью семантику применения цикла.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, LaptevVV, Вы писали:
U>>>Я настолько не понятно сформулировал вопрос, что Вы до сих пор не способны написать пример использования while для поиска? LVV>>А вы не способны посмотреть Вирта или Кнута? Вот если непонятно будет — я объясню...
U>Мда, не хотел бы я у Вас учиться. Тот же Павел Дворкин даже если говорит спорные вещи, как правило достаточно внятно их аргументирует, соответственно умению думать он учить студентов способен. А если Вы и студентов учите воспринимать мнение авторитетов как истину в последней инстанции, то в результате получаете начетчиков вместо инженеров.
Да и ладно.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
А>>>>3) Неясно, как применить операцию отрицания кванторов. В математике достаточно поставить нужный значок. Что нужно добавить в вашем псевдокоде для аналогичного действия? LVV>>>Отрицание квантора "для любого" — это квантор "существует". И наоборот. Не существует — это для любого. А>>Блин, я же вопрос конкретный задал. И опять на вопрос ответа нет. LVV>А я конкретно отвечаю. Это очевидно для всех, кто учил матлогику.
Для всех, кто учил матлогику (и для тех, кто просто владеет логикой), очевидно, что на мой вопрос вы не ответили. Может быть надо пояснить, что вопросительным является предложение, в конце которого стоит знак '?'. Я думал, что вы это знаете, извините.
Re[8]: Как обучать технике программирования?
От:
Аноним
Дата:
30.04.10 05:16
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Я тоже не понимаю, почему я не могу провести такую аналогию. LVV>Когда она лично мне прекрасно объясняет наличие двух ОСНОВНЫХ форм цикла.
Ну и о чем дальше говорить?
LVV>Предложите третью семантику применения цикла.
Вам предлагали, вы упорно не хотите замечать, безосновательно утверждая, что всё сводится к перебору и поиску, ссылаясь на свою кривую аналогию.
Здравствуйте, Аноним, Вы писали:
LVV>>Предложите третью семантику применения цикла. А>Вам предлагали, вы упорно не хотите замечать, безосновательно утверждая, что всё сводится к перебору и поиску, ссылаясь на свою кривую аналогию.
Ткните еще раз носом. А то постов много стало.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[22]: Как обучать технике программирования?
От:
Аноним
Дата:
30.04.10 05:22
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Дык вы хотя бы представьтесь сначала. Чтоб я знал, кто тут такой умный...
Как-то так
Здравствуйте, LaptevVV, Вы писали:
LVV>Вот жеж блин! Я для чего это затеял?! Чтоб народ кончструктивно высказывался, а тут как обычно, даже само слово "техника" стали обс...рать! >>> программы просто не владеете...
И что в моих высказываниях не конструктивного? С тем, что техника нужна я согласен, но сразу же возникает вопрос, что на сегодняшний день является правильной техникой? Если человеку поставить неправильную технику, то вреда от этого будет больше чем польза. Вы же почему-то вопрос что есть правильная техника просто отказываетесь рассматривать. И откуда тогда у Вас берется уверенность, что Вы будете учить студентов правильной технике, а не неправильной, которую на реальной работе придется переучивать?
On 30/04/2010 07:56, LaptevVV wrote:
>> > Так и скажите, что классиков — не читали... И читать не собираетесь... >> > Таким образом, техникой программирования элементарных составляющих > .>Покажите эту технику, не я один любопытствую! > Вот жеж блин! Я для чего это затеял?! Чтоб народ кончструктивно > высказывался, а тут как обычно, даже само слово "техника" стали обс...рать!
Не ко мне претензия. Вам показали код, вы его поспешили "обс...рать", мол, вы все необразованные, кнутов не читали. А вот ничего конструктивного с Вашей стороны я так и не наблюдаю.
>> > программы просто не владеете... > .>А оно точно надо? Игра в бисер? > Ну, играйте... А я думаю, как учить...
Так просветите! Уменьшите количество невежества в мире! В конце концов, вы обязаны просвещать, профессия такая.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
On 30/04/2010 08:00, LaptevVV wrote: > Ну так вы можете предложить третий квантор? Если можете — давайте, > пообсуждаем. Я — не могу.
Часто используется "∃!". Вообще говоря, кванторов может быть много, просто полезных не так много, да и их можно свести к этим двум.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Mr.Cat, Вы писали:
MC>>Здравствуйте, LaptevVV, Вы писали: LVV>>>Уточню. Я просто провел простейшую аналогию между двумя кванторами и двумя циклами. MC>>Ну вот тут уже с тобой человек спорит насчет необоснованности такой аналогии. Я просто привожу довод в пользу его точки зрения. LVV>Тут человек требует, чтобы я написал отрицание квантора. Я — написал. Он не понял. LVV>Я тоже не понимаю, почему я не могу провести такую аналогию. LVV>Когда она лично мне прекрасно объясняет наличие двух ОСНОВНЫХ форм цикла. LVV>Если кто подскажет еще — я только порадуюсь и возьму на вообужение. LVV>А то пока только одни вопли, что этого не может быть. LVV>Давайте перейдем от критиканство к конструктивности. LVV>Предложите третью семантику применения цикла.
"Существует, но не единственный" в рамках сомнительной аналогии с логикой. В виде задачи: найти первые два (три,...) элемента для которых выполнен предикат. Это не поиск (в смысле, что одиночный while pred do ... не пройдёт), но и не полный перебор, поскольку может закончится много раньше.
Здравствуйте, ., Вы писали:
.>On 30/04/2010 08:00, LaptevVV wrote: >> Ну так вы можете предложить третий квантор? Если можете — давайте, >> пообсуждаем. Я — не могу. .>Часто используется "∃!". Вообще говоря, кванторов может быть много, просто полезных не так много, да и их можно свести к этим двум.
Ну так я о чем и говорю. Основных паттернов цикла — два. Аналогия с кванторами напрашивается.
А дополнительные — это синтаксический сахар...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, deniok, Вы писали:
LVV>>>>Уточню. Я просто провел простейшую аналогию между двумя кванторами и двумя циклами. MC>>>Ну вот тут уже с тобой человек спорит насчет необоснованности такой аналогии. Я просто привожу довод в пользу его точки зрения. LVV>>Тут человек требует, чтобы я написал отрицание квантора. Я — написал. Он не понял. LVV>>Я тоже не понимаю, почему я не могу провести такую аналогию. LVV>>Когда она лично мне прекрасно объясняет наличие двух ОСНОВНЫХ форм цикла. LVV>>Если кто подскажет еще — я только порадуюсь и возьму на вообужение. LVV>>А то пока только одни вопли, что этого не может быть. LVV>>Давайте перейдем от критиканство к конструктивности. LVV>>Предложите третью семантику применения цикла.
D>"Существует, но не единственный" в рамках сомнительной аналогии с логикой. В виде задачи: найти первые два (три,...) элемента для которых выполнен предикат. Это не поиск (в смысле, что одиночный while pred do ... не пройдёт), но и не полный перебор, поскольку может закончится много раньше.
1. Почему — не поиск. В условии цикла-то мы ж логическое выражение любой сложности писать можем. Вот и напишем:
while pred1() and pred2() do ... end
2. В последней книге Вирта "Алгоритмы и структуры данных" проведена, на мой взгляд, здравая аналогия двоичного поиска с линейным
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Спасибо всем.
Все же конструктивных мыслей было мало.
Да практически и не было.
Вброс двух видов циклов вызвал шквал критических замечаний, о том, что видов циклов гораздо больше.
Особенно когда я провел аналогию с кванторами. Но никто хотя бы еще одну семантику так и не привел.
Которая принципиально отличается от поиска и перебора.
Вброс разумных ограничений на размер процедуры — аналогично.
И в конце, как обычно, все свелось к тому, что автор темы — неграмотный программист,
неграмотный математик, и его нельзя подпускать к студентам...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Спасибо всем. LVV>Все же конструктивных мыслей было мало. LVV>Да практически и не было. LVV>Вброс двух видов циклов вызвал шквал критических замечаний, о том, что видов циклов гораздо больше. LVV>Особенно когда я провел аналогию с кванторами. Но никто хотя бы еще одну семантику так и не привел. LVV>Которая принципиально отличается от поиска и перебора. LVV>Вброс разумных ограничений на размер процедуры — аналогично.
Самое печальное, что автор темы так ничего и не понял из того, что ему говорили.
LVV>И в конце, как обычно, все свелось к тому, что автор темы — неграмотный программист, LVV>неграмотный математик, и его нельзя подпускать к студентам...
Дык если не в первый раз и "как обычно", задумайтесь.
Здравствуйте, Аноним, Вы писали:
А>Самое печальное, что автор темы так ничего и не понял из того, что ему говорили.
Не делайте поспешных выводов... LVV>>И в конце, как обычно, все свелось к тому, что автор темы — неграмотный программист, LVV>>неграмотный математик, и его нельзя подпускать к студентам... А>Дык если не в первый раз и "как обычно", задумайтесь.
Как обычно — это не только обо мне...
Со мной-то — первый раз...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Спасибо всем. Пора заканчивать
От:
Аноним
Дата:
30.04.10 09:30
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Как обычно — это не только обо мне... LVV>Со мной-то — первый раз...
Здравствуйте, Аноним, Вы писали:
А>Ну покажи-расскажи А>Только речь про код изначально не идёт ведь. Умение красиво кодировать можно относительно быстро натренировать при наличии соответствующего матбэкграунда. Проверено.
Умение кодить даже у выпускников мат.специальностей вырабатывается годами.
Дело ведь не в форматировании текста, а в правильной декомпозиции. При этом качественный код, это всегда есть применение нескольких принципов декомпозиции. В большинсве случаев это будет то, что называют функциональным подходом (в отличие от функционального стиля, когда императивная программа использует феньки функционального языка).
Т.е. красивое кодирование есть техника, а не эстетический подход.
А вот пример. Расскажи, кто какой код писал
Q1: if (N<=M) goto Q9; S=0; l=1; r=N;
Q2: i=l; j=r+1; K=R[l]->K;
Q3: i+=1; if (R[i]->K<K) goto Q3;
Q4: j-=1; if (K<R[j]->K) goto Q4;
Q5: if (j<=i) { swap(R[l],R[j],Rt); goto Q7; }
Q6: swap(R[i],R[j],Rt); goto Q3;
Q7: if (r-j>=j-l>M) { push(j+1,r); S+=1; r=j-1; goto Q2; }
if (j-l>r-j>M) { push(l,j-1); S+=1; l=j+1; goto Q2; }
if (r-j>M>=j-l) { l=j+1; goto Q2; }
if (j-l>M>=r-j) { r=j-1; goto Q2; }
Q8: if (S) { pop(l,r); S-=1; goto Q2; }
Q9: for (j=2; j<=N; j+=1) {
if (R[j-1]->K > R[j]->K) {
K=R[j]->K; Rt=R[j]; i=j-1; R[i+1]=R[i];
while (R[i]->K>K && i>=1) i-=1;
R[i+1]=Rt; } }
и вот
template <class T>
void QuickSort(T & item, int left, int right)
{
int i = left;
int j = right;
typename T::value_type center = item[(left + right) / 2];
while(i <= j)
{
while (less(item[i], center))
i++;
while (less(center, item[j]))
j--;
if (i <= j)
Swap(item[i++], item[j--]);
}
if(left < j)
QuickSort(item, left, j);
if(right > i)
QuickSort(item, i, right);
}
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, LaptevVV, Вы писали:
LVV>>Как обычно — это не только обо мне... LVV>>Со мной-то — первый раз...
А>Тем более задумайтесь
Хорошо. На другом форуме побеседуем...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[29]: Как обучать технике программирования?
От:
Аноним
Дата:
30.04.10 09:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Умение кодить даже у выпускников мат.специальностей вырабатывается годами.
Значит, они не математики ни фига.
I>А вот пример. Расскажи, кто какой код писал
И тот, и другой код ублюдский, и писан не математиками.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, deniok, Вы писали:
D>>"Существует, но не единственный" в рамках сомнительной аналогии с логикой. В виде задачи: найти первые два (три,...) элемента для которых выполнен предикат. Это не поиск (в смысле, что одиночный while pred do ... не пройдёт), но и не полный перебор, поскольку может закончится много раньше. LVV>1. Почему — не поиск. В условии цикла-то мы ж логическое выражение любой сложности писать можем. Вот и напишем: LVV>
LVV>while pred1() and pred2() do ... end
LVV>
я так понимаю, что единственное удобство использования while для поиска в том и состоит, что мы используем отрицание того предиката, по которому идёт поиск
while not pred do next_elem
А если приходится конструировать сложное условие из нескольких 'технических' предикатов, то преимущество такого подхода перед break (или return) внутри for --- чистая вкусовщина и спор тупоконечников с остроконечниками. Профессионал должен легко читать и такой и сякой код. А писать: fold, map, scan, find, ну или foreach на худой конец
Здравствуйте, deniok, Вы писали:
D>А если приходится конструировать сложное условие из нескольких 'технических' предикатов, то преимущество такого подхода перед break (или return) внутри for --- чистая вкусовщина и спор тупоконечников с остроконечниками. Профессионал должен легко читать и такой и сякой код. А писать: fold, map, scan, find, ну или foreach на худой конец
С этим я почти согласен. Профессионал должен все это уметь читать. И проводить рефакторинг, если что
Должен ли джентельмен, если он — профессионал...
Но речь идет о БАЗОВОЙ технике.
Ведь приходит новичок, а мы ему: можно так, можно эдак, можно вот так, а еще и вот так. У него глаза разбегаются — и он ничего не усваивает.
А если мы ему говорим: смотри, есть два ОСНОВНЫХ способа использовать цикл. Когда перебираешь все, и когда что-то ищешь.
И приводим схемы.
Паттерны откладываются в голове.
И только по мере обучения он познает (и понимает), что можно еще и так, и эдак, и вот так.
Еще аналогия. Когда Альтшулер свой ТРИЗ выдумал — было много воплей о том, что это — фигня! Творчество формализовать невозможно. И тому подобное.
Оказалось — возможно. Более того, формальные приемы изобретательства позволяют смотреть "ширше, дальше и глубже".
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
On 30/04/2010 11:21, LaptevVV wrote:
> .>Часто используется "∃!". Вообще говоря, кванторов может быть много, > просто полезных не так много, да и их можно свести к этим двум. > Ну так я о чем и говорю. Основных паттернов цикла — два. Аналогия с > кванторами напрашивается. > А дополнительные — это синтаксический сахар...
А можно свести и к одному. ∀x ≡ ¬∃¬x. Хотя иногда с этим возникают проблемы...
Просто эти самые удобные в математической практике оказались. Причём тут циклы — хз.
Квантор в общем смысле это такой оператор, вводящий переменную в своё подвыражение, т.е. например Σ или ∫.
Для суровочелябинского можно вообще без кванторов обойтись.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>On 30/04/2010 11:21, LaptevVV wrote:
>> .>Часто используется "∃!". Вообще говоря, кванторов может быть много, >> просто полезных не так много, да и их можно свести к этим двум. >> Ну так я о чем и говорю. Основных паттернов цикла — два. Аналогия с >> кванторами напрашивается. >> А дополнительные — это синтаксический сахар... .>А можно свести и к одному. ∀x ≡ ¬∃¬x. Хотя иногда с этим возникают проблемы... .>Просто эти самые удобные в математической практике оказались. Причём тут циклы — хз. .>Квантор в общем смысле это такой оператор, вводящий переменную в своё подвыражение, т.е. например Σ или ∫. .>Для суровочелябинского можно вообще без кванторов обойтись.
Вы безусловно правы с точки зрения науки.
Но при практическом объяснении какому-нибудь отстающему — приходится и такие аналогии проводить.
И, знаете, до некоторых доходит... Все же — разные.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
On 30/04/2010 13:38, LaptevVV wrote: > Вы безусловно правы с точки зрения науки. > Но при практическом объяснении какому-нибудь отстающему — приходится и > такие аналогии проводить. > И, знаете, до некоторых доходит... Все же — разные.
Вообще говоря, цикл for(;) в точности соответствует любому квантору в общем виде: — ограниченный квантор по неск переменным, P — ограничивающий предикат. , где "??" — порядок обхода множества, без которого в нашем подлунном мире не обойтись.
Одно плохо, что во многих языках переменные в for могут быть только одного типа. Поубивав бы.
А вот как присобачить цикл while — мне не очень понятно, может поэтому вероятно и существуют некоторые, до которых и не доходит.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
>> И, знаете, до некоторых доходит... Все же — разные. .>Вообще говоря, цикл for(;) в точности соответствует любому квантору в общем виде:
[]
, где "??" — порядок обхода множества, без которого в нашем подлунном мире не обойтись. .>Одно плохо, что во многих языках переменные в for могут быть только одного типа. Поубивав бы.
В смысле — только целые .>А вот как присобачить цикл while — мне не очень понятно, может поэтому вероятно и существуют некоторые, до которых и не доходит.
Лично мне представляется, что как раз цикл while — более фундаметален, чем цикл for. Если только вы не имеете ввиду на месте for(;) цикл без всяких условий вроде конструкции loop — в Компонентном паскале...
А вообще у Дейкстры в дисциплине программирования более фундаментальный цикл прописал — с охраняемыми командами.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
On 30/04/2010 14:19, LaptevVV wrote:
> .>А вот как присобачить цикл while — мне не очень понятно, может поэтому > вероятно и существуют некоторые, до которых и не доходит. > Лично мне представляется, что как раз цикл while — более фундаметален,
while(X) == for(; X, т.е. while просто частный случай for.
> чем цикл for. Если только вы не имеете ввиду на месте for( цикл без > всяких условий вроде конструкции loop — в Компонентном паскале...
Ой, я имел в виду for(;)
> А вообще у Дейкстры в дисциплине программирования более фундаментальный > цикл прописал — с охраняемыми командами.
Синтаксически оно плохо выглядит... компоненты цикла размазаны по коду.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Аноним, Вы писали:
А>Значит, они не математики ни фига.
I>>А вот пример. Расскажи, кто какой код писал
А>И тот, и другой код ублюдский, и писан не математиками.
Один из них, с метками, писался никем иным, как Дональном Кнутом
Второй, с шаблонами — местный дедушка программирования — VladD2.
Re[31]: Как обучать технике программирования?
От:
Аноним
Дата:
30.04.10 12:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Один из них, с метками, писался никем иным, как Дональном Кнутом
Ничего подобного! Кнут этого кода не писал. Это лишь чья-то сишная реимплементация кнутовского кода на вымышленном MIX. А Кнут свой код писал не ради реализации сортировки, а для того, чтобы читатель врубился в алгоритм (то есть код специально написан так, чтобы понять досконально, пока разберёшь код).
Так что пример не катит (вот что бывает, когда принимаешь на веру чужие аргументы), а других, судя по всему, у тебя под рукой нет
Здравствуйте, ., Вы писали:
.>On 30/04/2010 14:19, LaptevVV wrote:
>> .>А вот как присобачить цикл while — мне не очень понятно, может поэтому >> вероятно и существуют некоторые, до которых и не доходит. >> Лично мне представляется, что как раз цикл while — более фундаметален, .>while(X) == for(; X, т.е. while просто частный случай for.
Интересно, что в учебниках цикл со счетчиком обычно описывают в терминах цикла while, а не наоборот... >> А вообще у Дейкстры в дисциплине программирования более фундаментальный >> цикл прописал — с охраняемыми командами. .>Синтаксически оно плохо выглядит... компоненты цикла размазаны по коду.
Не... Синтаксис — обсуждаем. Например, в одном обсуждении была предложена просто великолепная форма в паскалевском синтаксисе:
while
|expr1 do ...
|expr2 do ...
...
|exprk do ...
end
Вертикальная черта — это операция or. Первую or можно опускать — она просто для единообразия поставлена.
В простейшем случае он просто является обычным while
while
expr1 do ...
end
Операцию or опустили за ненадобностью.
И возвращаясь к технике.
Не наработано множество элементарных паттернов. Вернее, общепризнанных паттернов. У каждого препода в заначке, конечно, кое-что есть. Но!
Никто пока не проводил сравнение, какие приемы лучше, какие хуже. И тем более никто не думал над критериями: что значит в контексте обучения "лучше-хуже". Вернее, измеряемых критериев, которые признали бы большинство профи, пока нет.
Мой вброс про два типа циклов и аналогия с кванторами ясно показали, что народ об этом даже не задумывается. Вернее, почти никто.
Точно также — об ограничении размера процедуры простыми эмпирическими правилами.
Мне кажется, пора просто собирать подобные эмпирические правила — для дальнейшего использования при обучении программистов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[30]: Как обучать технике программирования?
От:
Аноним
Дата:
30.04.10 15:15
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Не... Синтаксис — обсуждаем. Например, в одном обсуждении была предложена просто великолепная форма в паскалевском синтаксисе: LVV>
LVV>while
LVV>|expr1 do ...
LVV>|expr2 do ...
LVV>...
LVV>|exprk do ...
LVV>end
LVV>
Еще для полной картины ваших кванторов тут не хватает.
LVV>Не наработано множество элементарных паттернов.
Почти всё уже давно придумано и наработано.
LVV>Вернее, общепризнанных паттернов.
И это есть.
LVV>У каждого препода в заначке, конечно, кое-что есть. Но!
Хе-хе. У преподов в заначке, блин
LVV>Никто пока не проводил сравнение, какие приемы лучше, какие хуже. И тем более никто не думал над критериями: что значит в контексте обучения "лучше-хуже". Вернее, измеряемых критериев, которые признали бы большинство профи, пока нет.
Во-первых, потому что в каждой области, технологии или направлении свои паттерны, которые не пересекаются.
Во-вторых, потому что "большинство профи", которых вы упоминаете, и не профи вовсе, а ребята вроде вас, и каждый со своими "кванторами".
LVV>Мой вброс про два типа циклов и аналогия с кванторами ясно показали, что народ об этом даже не задумывается.
Потому что до такой клоунады ни один нормальный человек не будет опускаться...
LVV>Вернее, почти никто.
...кроме вас.
LVV>Мне кажется, пора просто собирать подобные эмпирические правила — для дальнейшего использования при обучении программистов.
Здравствуйте, Аноним, Вы писали:
А>Ничего подобного! Кнут этого кода не писал. Это лишь чья-то сишная реимплементация кнутовского кода на вымышленном MIX.
Ню-ню.
А>А Кнут свой код писал не ради реализации сортировки, а для того, чтобы читатель врубился в алгоритм (то есть код специально написан так, чтобы понять досконально, пока разберёшь код).
Правильно написаный алгоритм гораздо легче понять.
А>Так что пример не катит (вот что бывает, когда принимаешь на веру чужие аргументы), а других, судя по всему, у тебя под рукой нет
On 30/04/2010 17:05, LaptevVV wrote:
> Интересно, что в учебниках цикл со счетчиком обычно описывают в терминах > цикла while, а не наоборот...
Всякие учебники бывают. Я вот особо поразился одному из них, где реализация односвязного списка описывалась через массив, т.к. последний типа как более простая структура данных.
Да и вообще — for — это не цикл со счётчиком.
for(var parent = elem; parent != null; parent = parent->getParent())
где тут счётчик?
>> > А вообще у Дейкстры в дисциплине программирования более фундаментальный >> > цикл прописал — с охраняемыми командами. > .>Синтаксически оно плохо выглядит... компоненты цикла размазаны по коду. > Не... Синтаксис — обсуждаем. Например, в одном обсуждении была > предложена просто великолепная форма в паскалевском синтаксисе:
О чём я и говорю, условия размазаны по коду. В случае for — главные компонеты — предусловие, инвариант и постусловие описаны в одном месте, потом идёт потенциально большое тело.
> И возвращаясь к технике. > Не наработано множество элементарных паттернов. Вернее, общепризнанных > паттернов. У каждого препода в заначке, конечно, кое-что есть. Но!
Не знаю. Может это важно в процессе обучения, но в Real Life оно, по-моему, не нужно.
> Никто пока не проводил сравнение, какие приемы лучше, какие хуже. И тем > более никто не думал над критериями: что значит в контексте обучения > "лучше-хуже". Вернее, измеряемых критериев, которые признали бы > большинство профи, пока нет.
no silver bullet, однако.
> Мой вброс про два типа циклов и аналогия с кванторами ясно показали, что > народ об этом даже не задумывается. Вернее, почти никто.
Было дело, задумывались, курсе на первом, а то и в школе, изобретая очередную теорию всего.
> Точно также — об ограничении размера процедуры простыми эмпирическими > правилами. > Мне кажется, пора просто собирать подобные эмпирические правила — для > дальнейшего использования при обучении программистов.
Да вроде это тривиальные вещи... хотя может это мне просто так кажется из-за моего опыта.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[33]: Как обучать технике программирования?
От:
Аноним
Дата:
30.04.10 16:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Аноним, Вы писали:
А>>Ничего подобного! Кнут этого кода не писал. Это лишь чья-то сишная реимплементация кнутовского кода на вымышленном MIX. I>Ню-ню.
Вот тут, есичо, это черным по-белому написано.
А>>А Кнут свой код писал не ради реализации сортировки, а для того, чтобы читатель врубился в алгоритм (то есть код специально написан так, чтобы понять досконально, пока разберёшь код). I>Правильно написаный алгоритм гораздо легче понять.
И, как правило, гораздо легче через 10 мин забыть. А такие алгоритмы, которые у Кнута рассматриваются, желательно до мелочей расковырять, чему и способствует его подход.
Здравствуйте, Аноним, Вы писали:
А>>>Ничего подобного! Кнут этого кода не писал. Это лишь чья-то сишная реимплементация кнутовского кода на вымышленном MIX. I>>Ню-ню.
А>Вот тут, есичо, это черным по-белому написано.
Ну, допустим
А>>>А Кнут свой код писал не ради реализации сортировки, а для того, чтобы читатель врубился в алгоритм (то есть код специально написан так, чтобы понять досконально, пока разберёшь код). I>>Правильно написаный алгоритм гораздо легче понять.
А>И, как правило, гораздо легче через 10 мин забыть. А такие алгоритмы, которые у Кнута рассматриваются, желательно до мелочей расковырять, чему и способствует его подход.
Т.е. говнокод позволят улучшить понимание алгоритма ?
Re[35]: Как обучать технике программирования?
От:
Аноним
Дата:
30.04.10 17:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:
А>>И, как правило, гораздо легче через 10 мин забыть. А такие алгоритмы, которые у Кнута рассматриваются, желательно до мелочей расковырять, чему и способствует его подход.
I>Т.е. говнокод позволят улучшить понимание алгоритма ?
Да не говнокод там. Просто низкоуровневый код. Для таких важных для программиста алгоритмов, как у Кнута, подход может где-то спорный, но небезосновательный. Разве не так?
Здравствуйте, LaptevVV, Вы писали:
LVV>Особенно когда я провел аналогию с кванторами. Но никто хотя бы еще одну семантику так и не привел. LVV>Которая принципиально отличается от поиска и перебора.
Не верно выбран термин. Некоторые виды поиска требуют итерации по всей коллекции. Например, поиск максимального элемента в неупорядоченном массиве целых чисел.
LVV>И в конце, как обычно, все свелось к тому, что автор темы — неграмотный программист, LVV>неграмотный математик, и его нельзя подпускать к студентам...
Не стоит дескутировать с анонимами. Особенно с теми, кто читает лукоморье.
Здравствуйте, Dufrenite, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали:
LVV>>Особенно когда я провел аналогию с кванторами. Но никто хотя бы еще одну семантику так и не привел. LVV>>Которая принципиально отличается от поиска и перебора.
D>Не верно выбран термин. Некоторые виды поиска требуют итерации по всей коллекции. Например, поиск максимального элемента в неупорядоченном массиве целых чисел.
Я бы так сказал: для поиска минимального элемента требуется перебрать весь массив. LVV>>И в конце, как обычно, все свелось к тому, что автор темы — неграмотный программист, LVV>>неграмотный математик, и его нельзя подпускать к студентам... D>Не стоит дескутировать с анонимами. Особенно с теми, кто читает лукоморье.
Учту...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Dufrenite, Вы писали:
D>Не стоит дескутировать с анонимами. Особенно с теми, кто читает лукоморье.
Вот она — стандартная отмазка тех людей, которым важнее личность оппонента, нежели его мнение. В некоторых случаях это диагноз, увы.
PS. Кстати, вы сами-то от анонима немногим отличатесь. Профиль у вас пустой, никаких данных нет, кроме негуглимого ника. Хе-хе.
Здравствуйте, Аноним, Вы писали:
А>Вот она — стандартная отмазка тех людей, которым важнее личность оппонента, нежели его мнение. В некоторых случаях это диагноз, увы.
У анонима есть личность? А я думал что это такая программа специальная.
А>PS. Кстати, вы сами-то от анонима немногим отличатесь. Профиль у вас пустой, никаких данных нет, кроме негуглимого ника. Хе-хе.
Моя фамилия Баффет. Только никому не говорите.
Re[5]: Спасибо всем. Пора заканчивать
От:
Аноним
Дата:
01.05.10 14:47
Оценка:
Здравствуйте, Dufrenite, Вы писали:
D>У анонима есть личность? А я думал что это такая программа специальная. D>Моя фамилия Баффет. Только никому не говорите.
Здравствуйте, LaptevVV, Вы писали:
LVV>Все же конструктивных мыслей было мало. LVV>Да практически и не было.
Какой вопрос, такие и ответы.
LVV>И в конце, как обычно, все свелось к тому, что автор темы — неграмотный программист, LVV>неграмотный математик, и его нельзя подпускать к студентам...
Тебя чем-то классические курсы алгоритмов и структур данных не устраивают? Их до жопы. И почти все хороши — начиная с Хоара, продолжая Виртом "как бы про Паскаль", и заканчивая современным МИТ-овским учебником. Ты их сам — читал? Задачи оттуда — решал?
Они чем-то плохи? Тебе что-то в них не нравится? Так ты не стесняйся, скажи — что. Людям, я думаю, это интересно. А то, пнимаешь — второе десятилетие 21-го века на дворе, а ты "с ленинским прищуром" задаешь вопросы из 50-х, как будто Хоар еще не выпустил свою книгу по алгоритмам и структурам данных с примерами на Алголе.
Или ты под техникой подразумеваешь умение печатать ключевые слова вроде for? Так это тебе надо для своих студентов спецкурс "слепой печати для программистов" вводить.
Здравствуйте, Аноним, Вы писали:
А>Вот она — стандартная отмазка тех людей, которым важнее личность оппонента, нежели его мнение. В некоторых случаях это диагноз, увы. А>PS. Кстати, вы сами-то от анонима немногим отличатесь. Профиль у вас пустой, никаких данных нет, кроме негуглимого ника. Хе-хе.
Надо бы новые антианонимные правила предложить. Либо ник должен быть гуглим, либо, если ник негуглимый, то надо предоставлять гуглимое ФИО, а если и этого нет, то ваще хоть что-нибудь гуглимое. В противном случае человек признается принципиально негуглимым, а следовательно — анонимным, и реально не существующим.
Здравствуйте, Ikemefula, Вы писали:
IT>>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
I>Зато и осваиваются много быстрее. Простые приемы в БИ осваиваются годами.
Потому что они осваиваются другой частью мозга и впечатываются в него на уровне рефлексов. Зачем знать цикл на уровне рефлексов?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
IT>>Зачем учиться писать циклы — не понятно Какая цель? Циклы ради циклов?
I>Писать не циклы, а решать задчи которые закрепляют понимание того, что такое итерация.
Нам здесь предлагают писать циклы. О понимании пока речи не было.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaptevVV, Вы писали:
IT>>Цикл без остальной части программы не имеет самостоятельного смысла, в отличии от удара. LVV>Прежде, чем весь удар тренировать. Боксер, например, разучивает элементы стойки, положение ног, положение тела. LVV>И тренер его поправляет, если положение ног или тела при ударе не соответствует. Я знаю, я в бокс некоторое время ходил.
Я некоторое время ходил на дзюдо. И каждый элемент нам объяснялся в подробностях не только как его выполнять, но и главное для чего он нужен.
LVV>Так и цикл — это часть большой задачи, но без "разучивания" цикла весь "удар"-программа получатся хуже, чем при "разучивании".
Я ещё раз повторю свою мысль. "Разучивание" цикла само по себе не имеет абсолютно никакого смысла. А без понимания смысла того, что делает программист можно обучать только мартышек.
IT>Поэтому я и спрашиваю, какой ответ будет давать преподаватель на вопрос студентов "зачем это надо?". LVV>Вот затем и надо. Технику написания цикла поставить...
Ставить надо не технику написания цикла, а технику мышления.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaptevVV, Вы писали: LVV>Тут человек требует, чтобы я написал отрицание квантора. Я — написал. Он не понял. LVV>Я тоже не понимаю, почему я не могу провести такую аналогию. LVV>Когда она лично мне прекрасно объясняет наличие двух ОСНОВНЫХ форм цикла.
Мне непонятны две вещи.
1. По какому принципу проводится аналогия между кванторами в высказываниях им циклами (изоморфизм Ткачева-Лаптева?). Какие примитивы структурного программирования ставятся в соответствие жругим элементам высказываний, например, коньюнкциям, дизъюнкциям?
2. Как от перебора и поиска ты переходишь к for и while?
Здравствуйте, Курилка, Вы писали:
IT>>Ставить надо не технику написания цикла, а технику мышления.
К>А вот есть по-твоему стоящие книжки, которые могут помочь в данном направлении?
Не знаю. Вот так книжку, в которой был бы ответ где найти философский, т.е. программистский камень, я пока не встречал. Зато встречал книжки не про программирование, в которых содержались вполне применимые для нашей профессии умные мысли Да и всё это очень индивидуально. Один думает, что он нашёл камень, другой будет смотреть на этот камень и видеть либо ничего вообще, либо ничего особенного.
К>Ясное дело, что в первую очередь нужна практика.
Практика, причём желательно производственная.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Курилка, Вы писали:
IT>>>Ставить надо не технику написания цикла, а технику мышления.
К>>А вот есть по-твоему стоящие книжки, которые могут помочь в данном направлении?
IT>Не знаю. Вот так книжку, в которой был бы ответ где найти философский, т.е. программистский камень, я пока не встречал. Зато встречал книжки не про программирование, в которых содержались вполне применимые для нашей профессии умные мысли Да и всё это очень индивидуально. Один думает, что он нашёл камень, другой будет смотреть на этот камень и видеть либо ничего вообще, либо ничего особенного.
Ну интересна даже очень субъективная точка зрения.
Но я не настаиваю, конечно.
Здравствуйте, IT, Вы писали:
LVV>>Вот затем и надо. Технику написания цикла поставить... IT>Ставить надо не технику написания цикла, а технику мышления.
Абсолютно согласен! И паттерны в этом только помогают. Вспоминаем Альтшулера "Творчество как точная наука".
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, IT, Вы писали:
I>>Писать не циклы, а решать задчи которые закрепляют понимание того, что такое итерация. IT>Нам здесь предлагают писать циклы. О понимании пока речи не было.
Не писать циклы, а запомнить паттерны циклов: поиск и перебор.
Для новичка, которые вообще первый раз увидел цикл это важно.
Профи-то так давно от этого ушли уже, что и не понимают, каково это — не понимать, как работает цикл...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Mr.Cat, Вы писали:
MC>Мне непонятны две вещи. MC>1. По какому принципу проводится аналогия между кванторами в высказываниях им циклами (изоморфизм Ткачева-Лаптева?). Какие примитивы структурного программирования ставятся в соответствие другим элементам высказываний, например, коньюнкциям, дизъюнкциям?
О БОЖЕ ж мой!!!!!
Простую аналогию уже возвели в ранг изоморфизма...
Воистину, в одном и том же слове КАЖДЫЙ видит СВОЕ... MC>2. Как от перебора и поиска ты переходишь к for и while?
Молча...
Перебор элементов реализуется циклом for, а поиск — циклом while.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
IT>>Нам здесь предлагают писать циклы. О понимании пока речи не было. LVV>Не писать циклы, а запомнить паттерны циклов: поиск и перебор.
Это другое дело, только тогда какое отношение к этому всему имеет противопоставление for и while? У них, кстати, есть одна общая особенность — когда в языке появляется foreach, то они оба становятся экзотикой. Ну может ещё for применяется, если одновременно нужен доступ по индексу к двум последовательностям одновременно. А в функциональных языках и без foreach можно прекрасно обойтись и вообще без операторов цикла. А ты предлагаешь в неокрепшем мозгу студента прибить гвоздями for к перебору, а while к поиску. Или наоборот, не помню уже что тебе с чем больше нравится.
LVV>Для новичка, которые вообще первый раз увидел цикл это важно.
Важно понять что такое цикл, а каким способом он реализуется дело десятое.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Курилка, Вы писали:
IT>>Не знаю. Вот так книжку, в которой был бы ответ где найти философский, т.е. программистский камень, я пока не встречал. Зато встречал книжки не про программирование, в которых содержались вполне применимые для нашей профессии умные мысли Да и всё это очень индивидуально. Один думает, что он нашёл камень, другой будет смотреть на этот камень и видеть либо ничего вообще, либо ничего особенного.
К>Ну интересна даже очень субъективная точка зрения.
Моя даже очень субъективная точка зрения заключается в том, что выбор того или иного решения или инструмента должен прежде всего иметь чёткий ответ на вопрос 'почему именно это решение/инструмент выбрано'. Нет такого ответа, нет чёткого понимания — нет возможности правильно принимать и оценивать применяемые решения — прямой путь либо к безграмотным и неэффективным решениям, либо к переусложнению кода на ровном месте.
Если взять в качестве примера приводимые в этом топике поиск vs. перебор и while vs. for, то для первой пары ответ на вопрос почему вполне очевиден, т.к. вытекает из постановки задачи. Вторая пара без конкретного кода — это абстрактный сфероконик. Я вот даже уже не припомню что для чего предлагается использовать. Вот ты сам к какому хирургу предпочёл бы пойти, тот который выбирает скальпель исходя из состояния пациента, конкретной ситуации и наличия инструментов или к тому, который раз режем аппендицит, то берём скальпель тот, который слева, потому что так учили в институте?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaptevVV, Вы писали:
LVV>Абсолютно согласен! И паттерны в этом только помогают. Вспоминаем Альтшулера "Творчество как точная наука".
При всем уважении к Альтшулеру и ТРИЗ именно эту задачу он не смог разрешить. Все что он может посоветовать для
решения задач четвертого и пятого уровня — развивать воображение.
Здравствуйте, IT, Вы писали:
LVV>>Не писать циклы, а запомнить паттерны циклов: поиск и перебор. IT>Это другое дело, только тогда какое отношение к этому всему имеет противопоставление for и while? У них, кстати, есть одна общая особенность — когда в языке появляется foreach, то они оба становятся экзотикой. Ну может ещё for применяется, если одновременно нужен доступ по индексу к двум последовательностям одновременно. А в функциональных языках и без foreach можно прекрасно обойтись и вообще без операторов цикла. А ты предлагаешь в неокрепшем мозгу студента прибить гвоздями for к перебору, а while к поиску. Или наоборот, не помню уже что тебе с чем больше нравится. LVV>>Для новичка, которые вообще первый раз увидел цикл это важно. IT>Важно понять что такое цикл, а каким способом он реализуется дело десятое.
Я эту тему начал от безисходности. У нас сейчас 2 курс почти полностью деревянный. Мы его уже почистили, осталось всего 17 человек.
И вчера обсуждали, что с ними делать. Например, проводили контрольную по алгоритмам сортировки — они пытались их выучить НАИЗУСТЬ.
Кода я им в начале семестра показал шаблоны и паттерны — это был шок.
Заканчивается уже третий семестр их знакомства с С++, но народ чего-то еще в школе живет.
Не учатся, а получают "оценки" — зачеты и экзамены.
Одна из популярнейших отмазок: "работает же"...
На третьем таких примерно 3 из 15, а на втором — примерно 12 из 17. В общем — мрак. И что делать — ума не приложу. Причем, не я один — 4 препода одновременно, которые у них программистские специальности ведут.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[13]: Как обучать технике программирования?
От:
Аноним
Дата:
04.05.10 05:45
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Я эту тему начал от безисходности. У нас сейчас 2 курс почти полностью деревянный. Мы его уже почистили, осталось всего 17 человек. LVV>И вчера обсуждали, что с ними делать. Например, проводили контрольную по алгоритмам сортировки — они пытались их выучить НАИЗУСТЬ. LVV>Кода я им в начале семестра показал шаблоны и паттерны — это был шок. LVV>Заканчивается уже третий семестр их знакомства с С++, но народ чего-то еще в школе живет.
А не надо обучать программированию, используя С++. Перед нами еще одно лишнее этому доказательство. Почитайте хотя бы вот это, если не читали еще.
Кстати, алгоритмы сортировки им что, только недавно давали? Примерно в одно время с шаблонами и паттернами?
LVV>На третьем таких примерно 3 из 15, а на втором — примерно 12 из 17. В общем — мрак. И что делать — ума не приложу. LVV>Причем, не я один — 4 препода одновременно, которые у них программистские специальности ведут.
Пересмотреть подход к обучению. Я не поверю, что студенты сплошь настолько деревянные, что их невозможно чему-либо обучить. В противном случае, выгонять безжалостно.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, LaptevVV, Вы писали:
LVV>>Я эту тему начал от безисходности. У нас сейчас 2 курс почти полностью деревянный. Мы его уже почистили, осталось всего 17 человек. LVV>>И вчера обсуждали, что с ними делать. Например, проводили контрольную по алгоритмам сортировки — они пытались их выучить НАИЗУСТЬ. LVV>>Кода я им в начале семестра показал шаблоны и паттерны — это был шок. LVV>>Заканчивается уже третий семестр их знакомства с С++, но народ чего-то еще в школе живет. А>А не надо обучать программированию, используя С++. Перед нами еще одно лишнее этому доказательство. Почитайте хотя бы вот это, если не читали еще.
Да читал я это. Толку-то...
Дело — не в С/С++ как таковом. Предыдущие выпуски проблем таких не испытывали. и 3-й, ни 4-й курсы тоже проблем не испытывали. А>Кстати, алгоритмы сортировки им что, только недавно давали? Примерно в одно время с шаблонами и паттернами?
У них Струтуры данных и алгоритмы в этом семестре. А ООП — остаточки, основное было в первом семестре. LVV>>На третьем таких примерно 3 из 15, а на втором — примерно 12 из 17. В общем — мрак. И что делать — ума не приложу. LVV>>Причем, не я один — 4 препода одновременно, которые у них программистские специальности ведут. А>Пересмотреть подход к обучению. Я не поверю, что студенты сплошь настолько деревянные, что их невозможно чему-либо обучить.
В противном случае, выгонять безжалостно.
У на впервые за 15 лет такой курс подобрался.
Общее впечатление — они не решают задачи, которые требуется решить на лабах, а тупо кодят код, чтобы заработало и сдать.
На совещании было высказано наблюдение, что именно этот курс пытается чисто механически воспроизводить то, что узнали от лектора.
Замечено, что книжек по программированию читают мало.
А всех, кто еще хуже — мы уже вычистили...
Вчера я всерьез предлагал некоторых обучать на черепашке. Было высказано опасение, что именно данный курс может навсегда в ней и остаться... , так как при переходе в профессиональную среду они точно те же проблемы будут испытывать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
А>Пересмотреть подход к обучению. Я не поверю, что студенты сплошь настолько деревянные, что их невозможно чему-либо обучить.
В противном случае, выгонять безжалостно.
Добавлю.
Поскольку практически никто из нас со школой не связан, для нас оказалось неожиданностью — столь низкий уровень подготовки абитуры.
Кстати, сейчас проводим занятия со школьниками (на паскале) — изучаем часть C ЕГЭ по информатике. Нормальные пацаны.
Недавно проводили открытую олимпиаду, допустили всех. Школьники побили всех наших второкурсников.
Кое-кого из студентов это задело.
Кстати, после долгих лет я впервые увидел, что школьник считает в уме и очень быстро.
Нынешний второй курс предпочитает использовать калькуляторы....
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[15]: Как обучать технике программирования?
От:
Аноним
Дата:
04.05.10 07:17
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Дело — не в С/С++ как таковом. Предыдущие выпуски проблем таких не испытывали. и 3-й, ни 4-й курсы тоже проблем не испытывали.
Повезло, значит.
Хотя у меня перед глазами есть примеры людей, которые тоже как бы "не испытывали проблем", однако, на 5 (!) курсе не знали, как написать простую функцию. Причин тут несколько, но то, что С++ при обучении тут приложил свои мохнатые лапы — очевидно.
А>>Кстати, алгоритмы сортировки им что, только недавно давали? Примерно в одно время с шаблонами и паттернами? LVV>У них Струтуры данных и алгоритмы в этом семестре. А ООП — остаточки, основное было в первом семестре.
А наоборот — не пробовали?
LVV>Общее впечатление — они не решают задачи, которые требуется решить на лабах, а тупо кодят код, чтобы заработало и сдать. LVV>На совещании было высказано наблюдение, что именно этот курс пытается чисто механически воспроизводить то, что узнали от лектора. LVV>Замечено, что книжек по программированию читают мало.
Под ваше описание попадает большинство студентов что сейчас, что, скажем, 10 лет назад
Вот только у меня еще один вопрос.
Зачем тема называется "техника программирования" (с описанием спорных подходов с последовавшим горячим обсуждением), если изначально вопрос лежит в другой плоскости?
Здравствуйте, IT, Вы писали:
I>>Зато и осваиваются много быстрее. Простые приемы в БИ осваиваются годами.
IT>Потому что они осваиваются другой частью мозга и впечатываются в него на уровне рефлексов. Зачем знать цикл на уровне рефлексов?
Для того, что перейти на следующий уровень мышления.
Здравствуйте, Аноним, Вы писали:
LVV>>Дело — не в С/С++ как таковом. Предыдущие выпуски проблем таких не испытывали. и 3-й, ни 4-й курсы тоже проблем не испытывали. А>Повезло, значит. А>Хотя у меня перед глазами есть примеры людей, которые тоже как бы "не испытывали проблем", однако, на 5 (!) курсе не знали, как написать простую функцию. Причин тут несколько, но то, что С++ при обучении тут приложил свои мохнатые лапы — очевидно.
Не, у нас такого не было никогда. Если чел не испытывал проблем на первых курсах, то он не испытывал НИКАКИХ проблем и с написанием диплома. Причем инструмент выбирается самостоятельно. А>>>Кстати, алгоритмы сортировки им что, только недавно давали? Примерно в одно время с шаблонами и паттернами? LVV>>У них Струтуры данных и алгоритмы в этом семестре. А ООП — остаточки, основное было в первом семестре. А> А>А наоборот — не пробовали?
1. Учебный план — штука инертная, блин!
2. У нас такой план:
1 семестр — информатика, введение в специальность
2-3 семестры — Программирование, 3 семестр — курсовая.
3-4 семестр — ООП, 4 семестр — курсовая.
3 семестр — структуры данных и алгоритмы
4 семестр — организация ЭВМ
5 семестр — ОС, БД, Системное ПО
6 семестр — технология программирования, программирование графики, SQL-сервер.
Элементарные сортировки они еще во 2 — семестре писали по программированию. Некоторые писали курсовую по сортировкам. LVV>>Общее впечатление — они не решают задачи, которые требуется решить на лабах, а тупо кодят код, чтобы заработало и сдать. LVV>>На совещании было высказано наблюдение, что именно этот курс пытается чисто механически воспроизводить то, что узнали от лектора. LVV>>Замечено, что книжек по программированию читают мало. А>Под ваше описание попадает большинство студентов что сейчас, что, скажем, 10 лет назад
Нет. 10 лет назад мы горя не знали. Еще 5 лет назад — не было проблем. Даже на 3-м курсе народ читает. Не все, конечно, но большинство. из 15 10-12 точно читают. А>Вот только у меня еще один вопрос. А>Зачем тема называется "техника программирования" (с описанием спорных подходов с последовавшим горячим обсуждением), если изначально вопрос лежит в другой плоскости?
Потому как эта плоскость обрисовалась явственно только недавно. После интенсивного обсуждения с коллегами.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали: MC>>1. По какому принципу проводится аналогия между кванторами в высказываниях им циклами (изоморфизм Ткачева-Лаптева?). Какие примитивы структурного программирования ставятся в соответствие другим элементам высказываний, например, коньюнкциям, дизъюнкциям? LVV>О БОЖЕ ж мой!!!!! LVV>Простую аналогию уже возвели в ранг изоморфизма... LVV>Воистину, в одном и том же слове КАЖДЫЙ видит СВОЕ...
Кроме шуток. По какому принципу в соответствие кванторам ставятся циклы? Я правда не понимаю.
MC>>2. Как от перебора и поиска ты переходишь к for и while? LVV>Перебор элементов реализуется циклом for, а поиск — циклом while.
А почему не предлагаются более очевидно следующие из предыдущей аналогии формы фундаментальных циклов: foreach и find? Например, совершенно непонятно, как for может быть универсальным циклом перебора множества, если он работает только для чисел, и то хреновенько.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, LaptevVV, Вы писали: MC>>>1. По какому принципу проводится аналогия между кванторами в высказываниях им циклами (изоморфизм Ткачева-Лаптева?). Какие примитивы структурного программирования ставятся в соответствие другим элементам высказываний, например, коньюнкциям, дизъюнкциям? LVV>>О БОЖЕ ж мой!!!!! LVV>>Простую аналогию уже возвели в ранг изоморфизма... LVV>>Воистину, в одном и том же слове КАЖДЫЙ видит СВОЕ... MC>Кроме шуток. По какому принципу в соответствие кванторам ставятся циклы? Я правда не понимаю.
Ну, "для любого" — это все нужно посмотреть... А "существует" — это один хотя бы найти надо.
MC>>>2. Как от перебора и поиска ты переходишь к for и while? LVV>>Перебор элементов реализуется циклом for, а поиск — циклом while. MC>А почему не предлагаются более очевидно следующие из предыдущей аналогии формы фундаментальных циклов: foreach и find? Например, совершенно непонятно, как for может быть универсальным циклом перебора множества, если он работает только для чисел, и то хреновенько.
Ну, в С++ и foreach и find — реализуются как раз с помощью циклов. Это абстракции более высокого полета, чем циклы...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[12]: Как обучать технике программирования?
От:
Аноним
Дата:
05.05.10 09:46
Оценка:
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, в С++ и foreach и find — реализуются как раз с помощью циклов. Это абстракции более высокого полета, чем циклы...
Ну а циклы реализуются с помощью машинных команд сравнения и условного перехода. Это же не повод утверждать, что команды сравнения и условного перехода несут семантику циклов? Ибо циклы — абстракция более высокого полёта, чем машинные команды.
Здравствуйте, Аноним, Вы писали:
А>Ну а циклы реализуются с помощью машинных команд сравнения и условного перехода. Это же не повод утверждать, что команды сравнения и условного перехода несут семантику циклов? Ибо циклы — абстракция более высокого полёта, чем машинные команды.
Да, именно так. Это абстракции. И осваивать новые асбтракции можно только полностью освоив базовые.
Re[14]: Как обучать технике программирования?
От:
Аноним
Дата:
05.05.10 12:34
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Да, именно так. Это абстракции. И осваивать новые асбтракции можно только полностью освоив базовые.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Ikemefula, Вы писали:
I>>Да, именно так. Это абстракции. И осваивать новые асбтракции можно только полностью освоив базовые.
А>С чего прикажете начать? С машинных команд?
А как же токи, напряжения в схемах и электроны в конце концов?
Здравствуйте, Аноним, Вы писали:
I>>Да, именно так. Это абстракции. И осваивать новые асбтракции можно только полностью освоив базовые.
А>С чего прикажете начать? С машинных команд?
Начинать со школьной математики. Постепенно нужно давать понятие процесса вычислений.
Здравствуйте, Курилка, Вы писали:
I>>>Да, именно так. Это абстракции. И осваивать новые асбтракции можно только полностью освоив базовые.
А>>С чего прикажете начать? С машинных команд?
К>А как же токи, напряжения в схемах и электроны в конце концов?
И это тоже надо. Но конкретно для обучения программированию — не обязательно.
Re[16]: Как обучать технике программирования?
От:
Аноним
Дата:
05.05.10 18:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Аноним, Вы писали:
I>>>Да, именно так. Это абстракции. И осваивать новые асбтракции можно только полностью освоив базовые. А>>С чего прикажете начать? С машинных команд? I>Начинать со школьной математики. Постепенно нужно давать понятие процесса вычислений.
При чем тут школьная математика? Мы ж про программирование говорим. В начале обучения программированию подразумевается, что школьная математика уже изучена. И, обычно, в процессе изучения находится высшая.
И на этом этапе наиболее целесообразным и безболезненным переходом является переход от математики к программированию примерно на тот же уровень абстракций. Такой, который предлагают языки высокого уровня, которые должны изучаться в курсе "программирование на ЯВУ" (не С++, конечно же). Студент до определенного момента не должен заботиться о том, что такое освобождение памяти, зачем в языке несколько разных типов, обозначающих целое число, как реализована строка и т.д. А потом уже можно двигаться параллельно в обе стороны: как в сторону абстракций более высокого уровня (архитектура ПО и т.д.), так и в сторону более низкого (ассемблер, системные вещи). Но ни в коем случае не начинать с ассемблера, С и им подобных вещей.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
А>>>С чего прикажете начать? С машинных команд?
К>>А как же токи, напряжения в схемах и электроны в конце концов?
FR>Это не программирование, самый нижний уровень именно программирования это базовые логические элементы И, НЕ, ИЛИ.
Ммм, у мсье есть определение абсолютного базиса программирования?
Ссылку в студию
I/O осуществляется через какой из элементов?
FR>>Это не программирование, самый нижний уровень именно программирования это базовые логические элементы И, НЕ, ИЛИ.
К>Ммм, у мсье есть определение абсолютного базиса программирования? К>Ссылку в студию
Тема скользкая, но электроны и напряжения точно никакого отношения к предмету не имеют. Компьютер без проблем можно
построить хоть на пневматических элементах хоть на шестеренках. Но если этот компьютер будет основан на двоичной логике
то на чем бы он не был сделан самый нижний слой и будет состоять из базовых логических элементов.
К>I/O осуществляется через какой из элементов?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
FR>>>Это не программирование, самый нижний уровень именно программирования это базовые логические элементы И, НЕ, ИЛИ.
К>>Ммм, у мсье есть определение абсолютного базиса программирования? К>>Ссылку в студию
FR>Тема скользкая, но электроны и напряжения точно никакого отношения к предмету не имеют. Компьютер без проблем можно FR>построить хоть на пневматических элементах хоть на шестеренках. Но если этот компьютер будет основан на двоичной логике FR>то на чем бы он не был сделан самый нижний слой и будет состоять из базовых логических элементов.
Продолжая скользкость темы можно вспомнить троичную логику Сетуни и квантовые компьютеры
Здравствуйте, Курилка, Вы писали:
К>Продолжая скользкость темы можно вспомнить троичную логику Сетуни и квантовые компьютеры
С троичной и n-значной логикой проблем никаких, там есть свои базовые логические элементы.
В квантовых компьютерах тоже есть минимальные логические элементы — кубиты.
Тут надо копать или в сторону аналоговых машин, или биологических нейронных сетей в которых тоже
тяжело разделить хард и софт.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Ikemefula, Вы писали:
I>>Да, именно так. Это абстракции. И осваивать новые асбтракции можно только полностью освоив базовые.
А>С чего прикажете начать? С машинных команд?
Или с команд исполнителя-черепашки...
Хотя я начинал как раз с машинных команд — весьма полезно оказалось. Во всяком случае, проблем с написанием последовательности действий не возникало НИКОГДА. В отличие от нынешних абитуров...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
А>И на этом этапе наиболее целесообразным и безболезненным переходом является переход от математики к программированию примерно на тот же уровень абстракций.
С чего ты взял что это безболезненно и целесообразно ?
Вводить в программирование нужно гдето с 10 класса, начинать с указания того, что такое вычисления, чем они отличаются от записей на бумажке — точность, время, ресурсы, ручной труд.
Любая деятельность, в т.ч. и программирование, начинается всегда с сенсорно-моторной стадии и до абстрактного мышления в этой деятельности надо пройти еще несколько стадий. Т.е. мышление нужно развивать каждый раз когда осваиваетя новая деятельность.
А ты же решил сразу дать абстракции
Абстрации нисколько не универсальная сущность. Пойми одну вещь — даже математики занимаются исключительно конкретной областью, и уже в смежной области их достижения сходят на нет.
>Такой, который предлагают языки высокого уровня, которые должны изучаться в курсе "программирование на ЯВУ" (не С++, конечно же). Студент до определенного момента не должен заботиться о том, что такое освобождение памяти, зачем в языке несколько разных типов, обозначающих целое число, как реализована строка и т.д.
Это устарело. В Мит и стенфорде от этого отказались. В стенфорде так вообще за С взялись.
Re[18]: Как обучать технике программирования?
От:
Аноним
Дата:
06.05.10 13:49
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>С чего ты взял что это безболезненно и целесообразно ?
С того, что математика — это язык описания сущностей реального мира и никакого другого языка для этого не существует. И именно на этом языке учат формализовывать предметные области любого нормального инженера. А программирование — это лишь инструмент для перевода математических абстракций в форму, понятную компьютеру. И чем меньше написанная программа будет отличаться от математической записи, тем лучше на начальном этапе. И именно с этого уровня и надо начинать. И только потом изучать аспекты и тонкости. Ибо premature optimization is the root of all evil.
I>Вводить в программирование нужно гдето с 10 класса, начинать с указания того, что такое вычисления, чем они отличаются от записей на бумажке — точность, время, ресурсы, ручной труд.
И нафига оно всё надо школьнику? Всё, что он должен знать про компьютер — это то, что компьютер создан для автоматизации рутинной работы. Для школьника достаточно и черепашки с кукарачей.
I>Любая деятельность, в т.ч. и программирование, начинается всегда с сенсорно-моторной стадии и до абстрактного мышления в этой деятельности надо пройти еще несколько стадий. Т.е. мышление нужно развивать каждый раз когда осваиваетя новая деятельность.
С этим сложно поспорить. Однако в том же программировании ничего не мешает на начальном этапе изучать абстракции высокого уровня, не зная того, как они реализуются на низком. И это потому, что эта деятельность ни черта не новая, а идёт параллельно с математикой. По крайней мере у нормальных людей, а не у кодеров-птушников. Сенсорно-моторная стадия тут конечно же имеется, но не на уровне изучения низкоуровневых сущностей и прочей параши.
Конечно же, хороший программист должен знать архитектуру и устройство компьютера, нюансы и ограничения, которые вытекают из этого и т.д., и всё это должно ложиться в стройную систему в голове. Вот только начинать с самого низа не обязательно. А то есть все шансы, что система в голове не выстроится, и так и будет: программирование отдельно, математика отдельно, одно с другим не состыковывается и рождает на выходе эталонное дерьмо.
Или мы с тобой по разному понимаем, кто такой программист.
I>А ты же решил сразу дать абстракции
Математические абстракции и так уже даны или даются к тому моменту. Я решил показать, как ими можно оперировать, используя компьютер. То есть показать, как перевести математические абстракции на язык компьютера, чтобы он занимался вычислениями вместо человека, в понятных человеку терминах.
А ты предлагаешь вернуться в первый класс и учиться складывать 2+2, чтобы "набить руку", или сначала пописать до посинения if с goto, перед тем как перейти к более высокой абстракции цикла. Не смеши её, она и так смешная.
>>Такой, который предлагают языки высокого уровня, которые должны изучаться в курсе "программирование на ЯВУ" (не С++, конечно же). Студент до определенного момента не должен заботиться о том, что такое освобождение памяти, зачем в языке несколько разных типов, обозначающих целое число, как реализована строка и т.д. I>Это устарело. В Мит и стенфорде от этого отказались. В стенфорде так вообще за С взялись.
Здравствуйте, Аноним, Вы писали:
I>>С чего ты взял что это безболезненно и целесообразно ?
А>С того, что математика — это язык описания сущностей реального мира и никакого другого языка для этого не существует. И именно на этом языке учат формализовывать предметные области любого нормального инженера. А программирование — это лишь инструмент для перевода математических абстракций в форму, понятную компьютеру. И чем меньше написанная программа будет отличаться от математической записи, тем лучше на начальном этапе. И именно с этого уровня и надо начинать.
В Мит и стенфорде от этого отказались, ибо людям крайне сложно воспринимать виртуальную машину.
Невозможно начать осваивать виртуальную машину с интегралов, производных и тд., потому что существенные различия происходят на уровене f(x) = x+1. И именно отсюда надо начинать освоение.
I>>Вводить в программирование нужно гдето с 10 класса, начинать с указания того, что такое вычисления, чем они отличаются от записей на бумажке — точность, время, ресурсы, ручной труд.
А>И нафига оно всё надо школьнику? Всё, что он должен знать про компьютер — это то, что компьютер создан для автоматизации рутинной работы. Для школьника достаточно и черепашки с кукарачей.
Однако важнейший вывод, обосновывающий место информатики в общеобразовательной школе, был сделан несколько позднее, когда было показано, что на знания, умения и навыки “программистского стиля мышления” непосредственно опираются существенно более общие, общекультурные умения и навыки: планирование, поиск, моделирование, общение, инструментирование своей деятельности. Для совокупности этих умений и навыков А.П. Ершов предложил термин “операционный стиль мышления”: он не только знал, понимал и высоко ценил идеи Жана Пиаже, но и видел их место в формировании молодого человека информационного общества. А.П. Ершов определил основной целью школьного курса информатики ответ школы на социальный заказ общества — формирование операционного стиля мышления у молодого поколения, начинающего активную жизнь в эпоху информационного общества. Такой вывод был обоснован: среди множества научных дисциплин, отраженных в школьных предметах, была лишь одна дисциплина, располагавшая полным концептуальным запасом понятий, механизмов и идей, необходимых для формирования операционного стиля мышления, — информатика. Богатый фундаментальный понятийный потенциал информатики делает ее стержнем, вокруг которого группируется, организуется система школьных дисциплин.
I>>Любая деятельность, в т.ч. и программирование, начинается всегда с сенсорно-моторной стадии и до абстрактного мышления в этой деятельности надо пройти еще несколько стадий. Т.е. мышление нужно развивать каждый раз когда осваиваетя новая деятельность.
А>С этим сложно поспорить. Однако в том же программировании ничего не мешает на начальном этапе изучать абстракции высокого уровня, не зная того, как они реализуются на низком.
Мешает, ибо люди не имеют представления о виртуальной машине и это проявляется в первом же применение программирования.
>И это потому, что эта деятельность ни черта не новая, а идёт параллельно с математикой. По крайней мере у нормальных людей, а не у кодеров-птушников. Сенсорно-моторная стадия тут конечно же имеется, но не на уровне изучения низкоуровневых сущностей и прочей параши.
Наоборот, это новая деятельность — организация вычислений, а не сами вычисления.
I>>А ты же решил сразу дать абстракции
А>Математические абстракции и так уже даны или даются к тому моменту. Я решил показать, как ими можно оперировать, используя компьютер. То есть показать, как перевести математические абстракции на язык компьютера, чтобы он занимался вычислениями вместо человека, в понятных человеку терминах.
По любому надо учить с нуля. Сначала научить, как перевести f(x) = x+1.
А>А ты предлагаешь вернуться в первый класс и учиться складывать 2+2, чтобы "набить руку", или сначала пописать до посинения if с goto, перед тем как перейти к более высокой абстракции цикла. Не смеши её, она и так смешная.
Учиться складывать 2+2 не надо. Надо научить перекладывать такое на компьютер.
Будешь смеяться,на первой лекции по 6.01 в Мит так и делают.
I>>Это устарело. В Мит и стенфорде от этого отказались. В стенфорде так вообще за С взялись.
А>Линки есть? Или опять Рабинович напел?
Здравствуйте, Ikemefula, Вы писали:
I>Невозможно начать осваивать виртуальную машину с интегралов, производных и тд., потому что существенные различия происходят на уровене f(x) = x+1.
Какие конкретно различия?
I>
I>Однако важнейший вывод, ... [skip] ... Богатый фундаментальный понятийный потенциал информатики делает ее стержнем, вокруг которого группируется, организуется система школьных дисциплин.
Это слишком утопический текст. Более того, не совсем понятно, за каким хреном тут информатика поставлена как стержень школьного образования. Ну да оставим это на совести автора.
I>Мешает, ибо люди не имеют представления о виртуальной машине и это проявляется в первом же применение программирования.
Как проявляется? Приведи конкретный пример.
I>По любому надо учить с нуля. Сначала научить, как перевести f(x) = x+1.
Чего там учить? Это идёт сразу же после Hello, World. В repl.
А>>А ты предлагаешь вернуться в первый класс и учиться складывать 2+2, чтобы "набить руку", или сначала пописать до посинения if с goto, перед тем как перейти к более высокой абстракции цикла. Не смеши её, она и так смешная.
I>Учиться складывать 2+2 не надо. Надо научить перекладывать такое на компьютер. I>Будешь смеяться,на первой лекции по 6.01 в Мит так и делают.
Ну да. Только там руку никто не набивает на этом. Это и так идёт на интуитивном уровне, ага?
Здравствуйте, Аноним, Вы писали:
I>>Невозможно начать осваивать виртуальную машину с интегралов, производных и тд., потому что существенные различия происходят на уровене f(x) = x+1.
А>Какие конкретно различия?
время, порядок вычислений, требования к памяти, типы данных, точность, разрядность и тд и тд.
Кроме того, появляется такая проблема, как ввод вывод. Ну и наконец синтаксис — язык по любому другой.
А>Это слишком утопический текст. Более того, не совсем понятно, за каким хреном тут информатика поставлена как стержень школьного
образования. Ну да оставим это на совести автора.
Это никакой не утопический текст.
I>>Мешает, ибо люди не имеют представления о виртуальной машине и это проявляется в первом же применение программирования.
А>Как проявляется? Приведи конкретный пример.
например человеку придется заниматься вводом выводом. стало быть придется углубляться в императивщину и тонкости ввода вывода или же изучать дополнительные абстракции, как например монады в хаскеле и много чего еще.
т.е. прежде чем человек сможет хоть чтото напрограммировать, ему придется изучить вагон всякой всячины.
А чуть дальше возникают вопросы разрядности, типов данных и производительности и расхода памяти.
А чуть далее выясняется, что надо заниматься архитектурой, дизайном, бороться с зависимостями, дубликамами и тд и тд и тд
В итоге для серьезной работы придется заниматься ликбезом с самых азов.
I>>По любому надо учить с нуля. Сначала научить, как перевести f(x) = x+1.
А>Чего там учить? Это идёт сразу же после Hello, World. В repl.
Учить — значит осваивать. Например в командной строке питона вводить значения, формулы и смотреть, что из этого получается.
I>>Учиться складывать 2+2 не надо. Надо научить перекладывать такое на компьютер. I>>Будешь смеяться,на первой лекции по 6.01 в Мит так и делают.
А>Ну да. Только там руку никто не набивает на этом. Это и так идёт на интуитивном уровне, ага?
На каком интуитивном ? При чем здесь интуитивный уровень ?
Разумеется, до уровня рефлексов 2+2 никто не забивает. Но все это проходится с самого нуля, с самых простых функций.
Хотя выпускники школ могут даже интегралы, производные и многое другое считать, все равно начинают программирование с азов. Буквально — с вопросов проде 2+2.
Крметого, в МИТ даже курс есть про введение в вычисления. 6.000 называется. Так шта лучше бы тебе перестать сочинять всякое
Re[22]: Как обучать технике программирования?
От:
Аноним
Дата:
07.05.10 08:28
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>>>Невозможно начать осваивать виртуальную машину с интегралов, производных и тд., потому что существенные различия происходят на уровене f(x) = x+1. А>>Какие конкретно различия? I>время, порядок вычислений, требования к памяти, типы данных, точность, разрядность и тд и тд.
И где среди этих слов и словосочетаний то, которое является существенным отличием, без которого нельзя начать обучение программированию, или с которыми студент не знаком?
I>Кроме того, появляется такая проблема, как ввод вывод. Ну и наконец синтаксис — язык по любому другой.
И то и другое — это не такие уж проблемы.
I>Это никакой не утопический текст.
Как еще назвать эту фантастическую писанину?
I>>>Мешает, ибо люди не имеют представления о виртуальной машине и это проявляется в первом же применение программирования. А>>Как проявляется? Приведи конкретный пример. I>например человеку придется заниматься вводом выводом. стало быть придется углубляться в императивщину и тонкости ввода вывода или же изучать дополнительные абстракции, как например монады в хаскеле и много чего еще.
Ты, блин, как Лаптев. Тебе вопрос, а ты в ответ какое-то невнятное мычание. Приведи пример типичной задачи для начального обучения программированию, где человеку изначально надо углубляться в тонкости ввода-вывода.
I>т.е. прежде чем человек сможет хоть чтото напрограммировать, ему придется изучить вагон всякой всячины.
Не придётся. Разве что если он учится программировать на ассемблере. Но мы же говорим о нормальном обучении, не так ли?
I>А чуть дальше возникают вопросы разрядности, типов данных и производительности и расхода памяти.
Это дальше, но не сразу.
I>А чуть далее выясняется, что надо заниматься архитектурой, дизайном, бороться с зависимостями, дубликамами и тд и тд и тд
А ничего, что архитектура — это всегда математика? И она не произрастает из тех "азов", что ты тут наперечислял.
I>В итоге для серьезной работы придется заниматься ликбезом с самых азов.
Для серьезной работы придётся. Только не путай азы с тонкостями и другими аспектами. У нормального инженера азы — они в математике и сопутствующих науках, а в программировании — тонкости, обусловленные несовершенством вычислительных средств. И эти тонкости инженер конечно же обязан знать, вот только с них не начинают, их либо потом, либо параллельно дают так, чтобы в голове автоматически выстроилась стройная картина. Ибо ничего сложного там нет и "руку набивать" незачем просто. А иначе с дуру можно и х.., то есть мозги, сломать.
I>Так шта лучше бы тебе перестать сочинять всякое
Ты бы лучше сам не сочинял. А то сдаётся мне, что ты не знаешь, кто такой программист. Всё больше кодерские замашки проскакивают.
Здравствуйте, Аноним, Вы писали:
I>>>>Невозможно начать осваивать виртуальную машину с интегралов, производных и тд., потому что существенные различия происходят на уровене f(x) = x+1. А>>>Какие конкретно различия? I>>время, порядок вычислений, требования к памяти, типы данных, точность, разрядность и тд и тд.
А>И где среди этих слов и словосочетаний то, которое является существенным отличием, без которого нельзя начать обучение программированию, или с которыми студент не знаком?
обучение начинать можно, если с 2+2. а сущсетвенные отличия — все перечисленные.
I>>Кроме того, появляется такая проблема, как ввод вывод. Ну и наконец синтаксис — язык по любому другой.
А>И то и другое — это не такие уж проблемы.
I>>Это никакой не утопический текст.
А>Как еще назвать эту фантастическую писанину?
Это не фантастическая писанина. Это небольшой очерк о состоянии дел в педагогических науках.
I>>например человеку придется заниматься вводом выводом. стало быть придется углубляться в императивщину и тонкости ввода вывода или же изучать дополнительные абстракции, как например монады в хаскеле и много чего еще.
А>Ты, блин, как Лаптев. Тебе вопрос, а ты в ответ какое-то невнятное мычание.
Вроде все внятно.
А>Приведи пример типичной задачи для начального обучения программированию, где человеку изначально надо углубляться в тонкости ввода-вывода.
например рисовалка графиков или решение любой физико-математической задачи.
I>>т.е. прежде чем человек сможет хоть чтото напрограммировать, ему придется изучить вагон всякой всячины.
А>Не придётся. Разве что если он учится программировать на ассемблере. Но мы же говорим о нормальном обучении, не так ли?
Ассемблер ни при чем. Нужно освоить все особенности виртуальной машины. В противном случае программированием это будет крайне сложно назвать.
I>>А чуть дальше возникают вопросы разрядности, типов данных и производительности и расхода памяти. А>Это дальше, но не сразу.
Сразу.
I>>А чуть далее выясняется, что надо заниматься архитектурой, дизайном, бороться с зависимостями, дубликамами и тд и тд и тд А>А ничего, что архитектура — это всегда математика? И она не произрастает из тех "азов", что ты тут наперечислял.
Произрастает именно оттуда. Математика она разнае. Не бывает людей которые хорошо знают всю математику. Только какую то часть, как правило.
I>>В итоге для серьезной работы придется заниматься ликбезом с самых азов.
А>Для серьезной работы придётся.
Потому неясно, чего ты выступаешь
>У нормального инженера азы — они в математике и сопутствующих науках, а в программировании — тонкости, обусловленные несовершенством вычислительных средств.
Азы программирования разумеется не то же самое что и азы математики.
Азы программирования — базовые операции, алгоритмы, структуры данных и тд и тд.
>И эти тонкости инженер конечно же обязан знать, вот только с них не начинают,
Начинают именно с них. Разумеется паралельно с освоением других спецпредметов.
>их либо потом, либо параллельно дают так, чтобы в голове автоматически выстроилась стройная картина. Ибо ничего сложного там нет и "руку набивать" незачем просто.
Сложнго ничего нет только для тех, кто все освоил.
А>Ты бы лучше сам не сочинял. А то сдаётся мне, что ты не знаешь, кто такой программист. Всё больше кодерские замашки проскакивают.
У тебя кроме художественно-маргинальных загибов ничего не было. Так что гуляй.
Здравствуйте, FR, Вы писали:
А>>>С чего прикажете начать? С машинных команд?
К>>А как же токи, напряжения в схемах и электроны в конце концов?
FR>Это не программирование, самый нижний уровень именно программирования это базовые логические элементы И, НЕ, ИЛИ.
Только этого маловато. Здесь время не учитывается например. Т.е. на базис не годится.
Re[24]: Как обучать технике программирования?
От:
Аноним
Дата:
07.05.10 16:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>обучение начинать можно, если с 2+2. а сущсетвенные отличия — все перечисленные.
То есть нормального ответа так и не будет?
А>>Как еще назвать эту фантастическую писанину? I>Это не фантастическая писанина. Это небольшой очерк о состоянии дел в педагогических науках.
Это, если уж на то пошло, псевдопедагогическая фантастическая утопическая бредятина, а никакой не очерк.
А>>Ты, блин, как Лаптев. Тебе вопрос, а ты в ответ какое-то невнятное мычание. I>Вроде все внятно.
Для нормальных людей — ничего не внятно.
А>>Приведи пример типичной задачи для начального обучения программированию, где человеку изначально надо углубляться в тонкости ввода-вывода. I>например рисовалка графиков или решение любой физико-математической задачи.
И где тут тонкости, а?
А>>Не придётся. Разве что если он учится программировать на ассемблере. Но мы же говорим о нормальном обучении, не так ли? I>Ассемблер ни при чем. Нужно освоить все особенности виртуальной машины. В противном случае программированием это будет крайне сложно назвать.
А что тогда, по-твоему, программирование?
>>У нормального инженера азы — они в математике и сопутствующих науках, а в программировании — тонкости, обусловленные несовершенством вычислительных средств. I>Азы программирования разумеется не то же самое что и азы математики. I>Азы программирования — базовые операции, алгоритмы, структуры данных и тд и тд.
А это не математика, да? Обычная такая программистская математика.
I>Сложнго ничего нет только для тех, кто все освоил.
Нет, сложного нет для тех, у кого в голове мозги, а не известная субстанция.
I>У тебя кроме художественно-маргинальных загибов ничего не было. Так что гуляй.
Слушай, либо ты даёшь определение того, кто такой программист, либо сам гуляешь.
Здравствуйте, Аноним, Вы писали:
I>>обучение начинать можно, если с 2+2. а сущсетвенные отличия — все перечисленные.
А>То есть нормального ответа так и не будет?
Не нравится — не надо.
А>Это, если уж на то пошло, псевдопедагогическая фантастическая утопическая бредятина, а никакой не очерк.
Преподаватель культурологии точно так же отзывалась о программировании
I>>например рисовалка графиков или решение любой физико-математической задачи.
А>И где тут тонкости, а?
Известно где — там где есть ввод вывод, использование памяти, разрядность и тд и тд.
Т.е. вагоны ограничений + автоматизация труда. Это и есть тонкости.
I>>Ассемблер ни при чем. Нужно освоить все особенности виртуальной машины. В противном случае программированием это будет крайне сложно назвать.
А>А что тогда, по-твоему, программирование?
Я употребляю в данном топике программирование как разработка программного обеспечения.
I>>Азы программирования разумеется не то же самое что и азы математики. I>>Азы программирования — базовые операции, алгоритмы, структуры данных и тд и тд.
А>А это не математика, да? Обычная такая программистская математика.
Это описывается математикой,да. При этом разработка не станет от этого математикой.
I>>У тебя кроме художественно-маргинальных загибов ничего не было. Так что гуляй.
А>Слушай, либо ты даёшь определение того, кто такой программист, либо сам гуляешь.
Программист как правило инженер который занимается разработкой программного обеспечения.
Как ты понимаешь, разработка программного обеспечения математикой не является и являться не может.
Здравствуйте, LaptevVV, Вы писали:
LVV>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей. LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?
По-моему следует различать две совершенно разных техники: ту которая "поставлена" у профи и ту которую надо правильно ставить новичку. Первая — всегда личная, уникальная техника конкретного профи, выработаная им самим за долгие годы изучания профессии, проб и ошибок. Это набор приемов которыми он пользуется для решения взникающих перед ним задач. И если профи столкнется с новой для него задачей, он найдет технический прием для ее решения, и этот прием присоединится к его технике. Главный вывод, который из этого следует: сначала зачада — потом прием для ее решения. Получаем паттерны программирования, так что-ли...
Ну тогда учебник по технике программирования для начинающих должен содержать набор задач с примерами их рещения, написанный профи исходя из личного опыта. Как-то так.
Здравствуйте, ZevS, Вы писали:
ZS>По-моему следует различать две совершенно разных техники: ту которая "поставлена" у профи и ту которую надо правильно ставить новичку.
Это одно и то же. Просто новичку надо скармливать оную технику по частям.
>Это набор приемов которыми он пользуется для решения взникающих перед ним задач. И если профи столкнется с новой для него задачей, он найдет технический прием для ее решения, и этот прием присоединится к его технике. Главный вывод, который из этого следует: сначала зачада — потом прием для ее решения. Получаем паттерны программирования, так что-ли...
Паттерны проектирования интересны не боле чем словарь, при определенном опыте нужные абстракции возникают сами собой.
ZS>Ну тогда учебник по технике программирования для начинающих должен содержать набор задач с примерами их рещения, написанный профи исходя из личного опыта. Как-то так.
Рефакторнг Фаулера и Рефакторнг Джошуа Кериевски например
Здравствуйте, ZevS, Вы писали:
LVV>>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов. LVV>>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей. LVV>>Что следует понимать под техникой программирования и как ее надо "ставить"?
ZS>По-моему следует различать две совершенно разных техники: ту которая "поставлена" у профи и ту которую надо правильно ставить новичку. Первая — всегда личная, уникальная техника конкретного профи, выработаная им самим за долгие годы изучания профессии, проб и ошибок. Это набор приемов которыми он пользуется для решения взникающих перед ним задач. И если профи столкнется с новой для него задачей, он найдет технический прием для ее решения, и этот прием присоединится к его технике. Главный вывод, который из этого следует: сначала зачада — потом прием для ее решения. Получаем паттерны программирования, так что-ли... ZS>Ну тогда учебник по технике программирования для начинающих должен содержать набор задач с примерами их рещения, написанный профи исходя из личного опыта. Как-то так.
Правильное наблюдение. Это как начинающий слесарь и профи высокого класса, у которого уже и чемоданчик с инструментами — свой собственный, а не стандартный.
Речь идет здесь именно о новичках.
Но тут вот еще что возникает. Вот пацан дома на компьютере — увлечен. Идет — в программеры. Типа — игрушки буду писать. Интересно, как это все работает.
А когда выясняется, что надо "играть гаммы", интерес угасает — у многих. Это же трудно — делать какие-то непонятные задачи! Когда вон на бейсике — за неделю можно игрушку слепить...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Речь идет здесь именно о новичках. LVV>Но тут вот еще что возникает. Вот пацан дома на компьютере — увлечен. Идет — в программеры. Типа — игрушки буду писать. Интересно, как это все работает. LVV>А когда выясняется, что надо "играть гаммы", интерес угасает — у многих. Это же трудно — делать какие-то непонятные задачи! Когда вон на бейсике — за неделю можно игрушку слепить...
Из личного опыта освоения не только программирования: в каждом деле есть несложные приемы, позволяющие добиваться интересных результатов. В частности, рекурсию мне было интересно изучать на примере рекурсивных графических алгоритмов. Но все это уже совсем не про "технику программирования" и сугубо индивидуально для каждого изучающего.
Однако, в основе любой техники всегда лежит база, некие "аксиомы" мастерства. И если научить "будущего светоча" видеть, как из этих "аксиом" рождаются приемы — это будет намного полезнее освоения какой-то техники. Проблема в том как это сделать, ну и аксиомы эти, в добавок, постояно меняются...
Здравствуйте, Ikemefula, Вы писали:
I>Это одно и то же. Просто новичку надо скармливать оную технику по частям.
Проблема в том что этой технике невозможно обучить. Это как если бы Малевич научил кого-то рисовать черный квадрат. Шутка.
I>Паттерны проектирования интересны не боле чем словарь, при определенном опыте нужные абстракции возникают сами собой.
Цикл — тоже паттерн, не использовать goto — тоже паттерн, в своем роде. )
ZS>>Ну тогда учебник по технике программирования для начинающих должен содержать набор задач с примерами их рещения, написанный профи исходя из личного опыта. Как-то так. I>Рефакторнг Фаулера и Рефакторнг Джошуа Кериевски например
На каком-то этапе — да.
Здравствуйте, ZevS, Вы писали:
I>>Это одно и то же. Просто новичку надо скармливать оную технику по частям. ZS>Проблема в том что этой технике невозможно обучить. Это как если бы Малевич научил кого-то рисовать черный квадрат. Шутка.
Почему же нельзя ? Профы ведь как то осваивают её Разумеется, все сразу не получится.
I>>Паттерны проектирования интересны не боле чем словарь, при определенном опыте нужные абстракции возникают сами собой. ZS>Цикл — тоже паттерн, не использовать goto — тоже паттерн, в своем роде. )
Это базовая техника кодирования.
I>>Рефакторнг Фаулера и Рефакторнг Джошуа Кериевски например ZS>На каком-то этапе — да.
Здравствуйте, LaptevVV, Вы писали:
LVV>Но тут вот еще что возникает. Вот пацан дома на компьютере — увлечен. Идет — в программеры. Типа — игрушки буду писать. Интересно, как это все работает. LVV>А когда выясняется, что надо "играть гаммы", интерес угасает — у многих. Это же трудно — делать какие-то непонятные задачи! Когда вон на бейсике — за неделю можно игрушку слепить...
Игра, это идеальный способ обучения. На задачах по разработке игр можно научить практически всем приёмам программирования. Может пусть начинают как раз с игр?
Здравствуйте, ZevS, Вы писали: ZS>В частности, рекурсию мне было интересно изучать на примере рекурсивных графических алгоритмов.
Мне кажется, на графике можно повредить себе мозг. Вот балуются сперва люди http://www.contextfreeart.org/, а потом рождаются чудовища, типа tikz/pgf или metapost.
Здравствуйте, Ikemefula, Вы писали:
ZS>>Цикл — тоже паттерн, не использовать goto — тоже паттерн, в своем роде. ) I>Это базовая техника кодирования.
Неужели. Лично я, как SQL-программист, ничего о такой технике не знаю...
Здравствуйте, ZevS, Вы писали:
ZS>>>Цикл — тоже паттерн, не использовать goto — тоже паттерн, в своем роде. ) I>>Это базовая техника кодирования. ZS>Неужели. Лично я, как SQL-программист, ничего о такой технике не знаю...
Здравствуйте, ZevS, Вы писали:
ZS>Из личного опыта освоения не только программирования: в каждом деле есть несложные приемы, позволяющие добиваться интересных результатов. В частности, рекурсию мне было интересно изучать на примере рекурсивных графических алгоритмов. Но все это уже совсем не про "технику программирования" и сугубо индивидуально для каждого изучающего.
Ну, вы прям смотрите в корень! С черепашки надо начинать! ZS>Однако, в основе любой техники всегда лежит база, некие "аксиомы" мастерства. И если научить "будущего светоча" видеть, как из этих "аксиом" рождаются приемы — это будет намного полезнее освоения какой-то техники. Проблема в том как это сделать, ну и аксиомы эти, в добавок, постояно меняются...
Мне кажется — это именно техника. Только это техника программистского мышления, а не конкретного написания программных текстов. Как я понимаю теперь — именно этому и надо обучать...
Но обучать-то придется с помощью конкретного писания конкретного кода. Вот такая диалектика — единство и борьба противоположностей...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, ZevS, Вы писали: ZS>>В частности, рекурсию мне было интересно изучать на примере рекурсивных графических алгоритмов. MC>Мне кажется, на графике можно повредить себе мозг. Вот балуются сперва люди http://www.contextfreeart.org/, а потом рождаются чудовища, типа tikz/pgf или metapost.
А обучающая среда должна ограничивать полет фантазии... И объем используемых средств. Только по мере набора опыта "тиски разжимаются"...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Dufrenite, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали:
LVV>>Но тут вот еще что возникает. Вот пацан дома на компьютере — увлечен. Идет — в программеры. Типа — игрушки буду писать. Интересно, как это все работает. LVV>>А когда выясняется, что надо "играть гаммы", интерес угасает — у многих. Это же трудно — делать какие-то непонятные задачи! Когда вон на бейсике — за неделю можно игрушку слепить...
D>Игра, это идеальный способ обучения. На задачах по разработке игр можно научить практически всем приёмам программирования. Может пусть начинают как раз с игр?
Сравни: игра, в которую они играют, и игра, которую они пишут, как новички. Боюсь — слишком большой разрыв...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
D>>Игра, это идеальный способ обучения. На задачах по разработке игр можно научить практически всем приёмам программирования. Может пусть начинают как раз с игр? LVV>Сравни: игра, в которую они играют, и игра, которую они пишут, как новички. Боюсь — слишком большой разрыв...
Здравствуйте, LaptevVV, Вы писали:
ZS>>Однако, в основе любой техники всегда лежит база, некие "аксиомы" мастерства. И если научить "будущего светоча" видеть, как из этих "аксиом" рождаются приемы — это будет намного полезнее освоения какой-то техники. Проблема в том как это сделать, ну и аксиомы эти, в добавок, постояно меняются... LVV>Мне кажется — это именно техника. Только это техника программистского мышления, а не конкретного написания программных текстов. Как я понимаю теперь — именно этому и надо обучать...
Большенство людей думает на родном языке. Так что техника программистского мышления и техника написания программных текстов тесно связаны, как мне кажется. Разные языки — разные подходы. Техника императивного мыщления не очень поможет с SQL или Lisp. Под аксиомами я понимаю некие надязыковые ценности : KISS, high cohesion, low coupling, testability, maintainability, modularity... Приемчики для решения задач в каждом языке свои.
LVV>Но обучать-то придется с помощью конкретного писания конкретного кода. Вот такая диалектика — единство и борьба противоположностей...
Pascal -> C# -> SQL -> Lisp -> Prolog ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, ZevS, Вы писали:
ZS>>>>Цикл — тоже паттерн, не использовать goto — тоже паттерн, в своем роде. ) I>>>Это базовая техника кодирования. ZS>>Неужели. Лично я, как SQL-программист, ничего о такой технике не знаю... I>И ?
Выходит не базовая, а если и базовая то далеко не для всех языков. А вот паттерн будет — "многократное исполнение одного кода над различными (меняющимися) данными". И цикл — одна из его реализаций. Хотя согласен, это не мешет ему быть одновременно и базовой техникой кодирования. ))
Здравствуйте, ZevS, Вы писали:
ZS>Здравствуйте, LaptevVV, Вы писали:
ZS>>>Однако, в основе любой техники всегда лежит база, некие "аксиомы" мастерства. И если научить "будущего светоча" видеть, как из этих "аксиом" рождаются приемы — это будет намного полезнее освоения какой-то техники. Проблема в том как это сделать, ну и аксиомы эти, в добавок, постояно меняются... LVV>>Мне кажется — это именно техника. Только это техника программистского мышления, а не конкретного написания программных текстов. Как я понимаю теперь — именно этому и надо обучать... ZS>Большенство людей думает на родном языке. Так что техника программистского мышления и техника написания программных текстов тесно связаны, как мне кажется. Разные языки — разные подходы. Техника императивного мыщления не очень поможет с SQL или Lisp. Под аксиомами я понимаю некие надязыковые ценности : KISS, high cohesion, low coupling, testability, maintainability, modularity... Приемчики для решения задач в каждом языке свои.
Наверное да.
LVV>>Но обучать-то придется с помощью конкретного писания конкретного кода. Вот такая диалектика — единство и борьба противоположностей... ZS>Pascal -> C# -> SQL -> Lisp -> Prolog ?
Интересная последовательность...
Component Pascal -> C# (Java) -> F# (Lisp-Scala-Schema-Haskell) -> SQL -> Prolog ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Component Pascal -> C# (Java) -> F# (Lisp-Scala-Schema-Haskell) -> SQL -> Prolog ?
Ну или так. ))
А еще, наверно, можно начать с довольно сложной общей теории, а уже из нее выводить ее частные приложения. Это может дать системное понимание конкретных приемов: зачем, когда, как... Например, в цифровой фотографии понимание того что такое цвет, цветовые пространства, контраст и так далее позволяет подойти к применению конкретных инструментов того же фотошопа гораздо осознанней. При этом, теория цвета — далеко не простая вещь. Не уверен правда, что тут можно провести прямую аналогию с программированием.
Здравствуйте, ZevS, Вы писали:
ZS>Здравствуйте, LaptevVV, Вы писали:
LVV>>Component Pascal -> C# (Java) -> F# (Lisp-Scala-Schema-Haskell) -> SQL -> Prolog ? ZS>Ну или так. )) ZS>А еще, наверно, можно начать с довольно сложной общей теории, а уже из нее выводить ее частные приложения. Это может дать системное понимание конкретных приемов: зачем, когда, как... Например, в цифровой фотографии понимание того что такое цвет, цветовые пространства, контраст и так далее позволяет подойти к применению конкретных инструментов того же фотошопа гораздо осознанней. При этом, теория цвета — далеко не простая вещь. Не уверен правда, что тут можно провести прямую аналогию с программированием.
Вот этот подход для начинающих точно не проходит — пробовали. На третьем, при обучении уже специальным дисциплинам — проходит. А новички — не получается так.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Вот этот подход для начинающих точно не проходит — пробовали. На третьем, при обучении уже специальным дисциплинам — проходит. А новички — не получается так.
Вопрос лишь в том когда человек перестает быть новичком...
Разве Вы не видите изменения своей техники программирования с течением времени? Вы же сами пишете — "ставится", а это подразумевает процесс, действие.
Учить приходится...
Если нам не помогут, то мы тоже никого не пощадим.
Какая цель? Циклы ради циклов?
— ограниченный квантор по неск переменным, P — ограничивающий предикат.
, где "??" — порядок обхода множества, без которого в нашем подлунном мире не обойтись.
