Копаю дальше. Версия jre на windows нужна именно 32-разрядная. "Нужна" она только потому что об этом сообщает модальное окно.
После некоторого гугления обнаружил, что в этом офисе просто нет редактирования скриптов питона из коробки. Поэтому надо эти самые скрипты либо класть в директорию пользователя, либо распаковывать .odt как архив, вставлять туда файл, оформлять конфиг и запаковывать все это обратно.
Для запуска скрипта на питоне JRE на самом деле оказалась не нужна.
Все эти пляски с бубном для подключения это явный минус. Если складывать скрипты в общую папку на общественном компьютере, то будет немножко больше бардака. Но вот редактировать эти скрипты надо чем-то другим, т.е. нормальной IDE и храниться они будут как текст, т.е. в git. Так что это плюс.
Скачал, поставил. У свежей установки есть выбор между OOB, BeanShell, js, Python. Для последних трех нужна установленная JRE(!).
Для новичков надо чтобы "просто работало". Поэтому остается только Open Office Basic.
Вот если бы в Excel было что-нибудь помимо VBA, с его отвратительным отладчиком, то программирование в школе можно было бы давать на нем.
Этот офисный пакет действительно востребован практически везде совсем как js.
Согласен. Возвращение кодов возврата в простых задачах неуместно. Оно полезно при работе с DirectX, SDL, WinAPI на С++, где иного выхода нет, либо вместе с HTTP клиентом, либо когда в программе много различных ошибочных исходов. Поэтому тривиальную задачу на такую тему придумать трудно.
Нужно ли вообще об этом подходе рассказывать в учебном заведении? Или отдать на самостоятельное освоение?
Я не предлагал все обработки исключений заменять на коды ошибок. Просто не нужно упускать их из поля зрения.
Непонятно еще, полезно ли вообще рассказывать о кодах возврата. Точно знаю, что если и рассказывать, то не с начала, а возле тех же исключений.
Не знаю насчет школьников, но начинающим взрослым на уровне задачек про квадратный корень нагляднее делать либо так:
int x = double.Parse(Console.ReadLine());
if (x<0){
Console.WriteLine("Подкоренное выражение должно быть неотрицательно");
return;
}
double result = Math.Sqrt(x);
Console.WriteLine(result);
либо так
int x = double.Parse(Console.ReadLine());
if (x<0){
Console.WriteLine("Подкоренное выражение должно быть неотрицательно");
} else {
double result = Math.Sqrt(x);
Console.WriteLine(result);
}
Никаких исключений и кодов ошибок тут не надо. Лишние они, когда вся программа на одном экране помещается.
Ну да, представьте такой вариант:
int a = readInt(f);
А если файл кончился, то просто выбрасывается исключение.
Исключение при чтении файла, который закончился, нагляднее предупреждать if(!reader.EndOfStream){/*read*/}, чем ловить. Думаю, что это верно для всех языков.
К тому же буквально вчера наткнулся на то, что StreamReader в C# исключение не бросает, а вычитывает null в случае с существующим, но пустым файлом.
StreamReader sr = new StreamReader("TextFile1.txt");
String val = sr.ReadLine();
val = sr.ReadLine();
Так что поведение при чтении пустого файла очень зависит от реализации этого чтения в конкретном инструменте.
Обработка исключений — не самая простая для школьника тема.
Обоснуйте, сошлитесь на опыт.
Если через весь курс вести идею о том, что нужно выдавать адекватные сообщения об ошибке даже при неадекватных данных, то исключения хорошо заходят сразу после того, как объясняешь методы. Просто еще один способ обрабатывать ошибки. Поскольку до наследования и ООП еще не дошли, но иерархия классов исключений объясняется в терминах "общее", "частное". На этот эмпирический опыт потом накладывается объяснение наследования.
throw в Main никакой пользы не несет, поэтому и объяснение исключений откладываю до момента объяснения функций-методов. Кстати исключения — не единственный способ реакции на ошибки. Не забывайте еще статус-коды (WinAPI, HTTP) и Either в ФП.
Интуитивно понятно, что пузырьковая сортировка вполне школьный алгоритм, а вот поиск прямых и овалов преобразованием Хафа в OpenCV для школы не обязателен, и параллельные алгоритмы в школе тоже не обязательны.
Думаю стоит уточнить, чтобы не было разночтений.
Возьмем как пример ту же пузырьковую сортировку. В рамках учебы реализовать ее полезно. Один раз в жизни. Это достаточно сложная задача, требующая понимания массивов, при этом у нее простая постановка и идея. Но вот в промышленном программировании реализовывать ее руками вредно, т.к. есть стандартные библиотеки, которыми нужно уметь пользоваться.
А если вдруг стандартная сортировка не подходит? Допустим для сортировки по дате 20Гб записей о транзакциях на компьютере с 4Гб оперативной памяти. Тут на первый план выходят навыки анализа задачи и поиска оптимального решения.
При реализации этой самой пузырьковой сортировки эти навыки даже тренируются. Но алгоритм в этом случае не цель, а средство.
Поэтому считаю тезис "цель обучения в школе — добиться точного знания множества конкретных алгоритмов и умения их реализовать без справочника" ошибочным. Пусть даже алгоритмы и простые.
Аналогично, театральные пьесы начинаются списком действующих лиц, а кулинарные рецепты — списком необходимых продуктов.
При таком подходе появляется проблема в случае, когда нужны промежуточные переменные. Но в процессе обучения, проблема "где лучше объявлять переменные" несущественна. Программки там маленькие и даже однобуквенные переменные a,b,c,d не вносят ощутимого бардака в решение. Можно сколько угодно требовать нормальное оформление кода и рассказывать про Mars Climate Orbiter, но пока это не приведет к шишкам от граблей, никто не поймет зачем надо его оформлять.
Популяризацией программирования сейчас не занимается только ленивый. И зарплаты тебе, и гамак, и два монитора.
Раз уж речь зашла про честность, то тогда уж точно не алгоритмы показывать надо, а более приземленное "подключись к базе данных, обработай результат запроса, нарисуй на формочке".
Недавних студентов-программистов к алгоритмам и не пустят. Тех же студентов-геологов привлекали ведь не для анализа грунта, а для копания земли, приготовления пищи и других хозяйственных активностей.
А для чего вам доказывать? У вас есть уютная экосистема технологий в которой вы профессионал. Может быть даже незаменимый. Доказательства вам "не убедительны" только потому что не интересно. Изучение какой-либо технологии это как восхождение на гору. Пока не заберешься, не увидишь открывающихся перспектив. Объективно, github и python — очень полезные технологии. Они помогают решать производственные и образовательные задачи. Если вам эти технологии не интересны — не пользуйтесь. Зачем демагогию устраивать?
По линейке СЛАУ и задачи по системному анализу отлично решаются в Excel. Это считается информатикой?
Вот только прикладное применение такой математики заключается в решении каких-то задач бизнеса. Найти оптимальный путь, распределить нагрузку и т.п.
Если проводить аналогию с "передать привязку булевой алгебры на информатику", то получается что надо "передать привязку линейной алгебры к решению бизнес-задач на работодателя"?
В нынешней ситуации если какой-то предмет вызывает вопрос "а зачем он?" и объяснение предполагается в рамках другого предмета, то у студентов получается закономерная реакция "сдать и забыть". А если это не желательный исход, было бы логично объяснять в рамках самого предмета.
Выгнать студента тоже не легко. Уже писали об этом.
Ужасно. Гнать такого студента! Он и таблицу умножения до шестью семь — сорок три наверное не знает. Пусть на его место придет более сообразительный.
Не будьте так категоричны. Такой вопрос я задаю только сильным студентам. Со сворачиванием и разворачиванием условных выражений, а также с другими задачами по программированию эти же студенты отлично справляются. Слабым сразу идет разбор решения задачи.
Дело в мотивации. Для сухой математики она звучит как "сдал и забыл" как раз потому что нет привязки к реальным задачам.
Привязку даст информатика, пятиклассник, знающий отличие И от ИЛИ, поймет.
Зачем в таком случае нужно булеву алгебру как отдельную тему подавать? Тут уже приводили пример про Мольера и разговоры прозой.
Вот только подавать ее отдельно неполезно. Не всякий студент, который недавно сдал "дискретную математику", может сформулировать отличие "И" от "ИЛИ".
При этом в булевой алгебре нет никакой привязки к конструкциям ветвления.
Навык преобразования таких выражений во что-нибудь вроде
if cond1 and cond2 then
call1
else
call2;
не требует привлечения сложного математического аппарата. Люди сами начинают так писать, если им вообще рассказать про логические операторы. Если очень хочется обратить внимание, то можно специальный набор заданий сделать.
Как контролируют выполнение домашних заданий в школе. Устные и письменные опросы, контрольные работы и т.д.
По той же математике задача вполне понятная: реши уравнение и напиши ход решения на бумаге; или упрости выражение и получи эквивалентное.
Не понятно как будет выглядеть письменный или устный опрос по переписанному алгоритму. Можно поставить задачу на вычисление сложности, но это уже не школьная задача.
Главный вопрос при этом: зачем алгоритм нужно переписывать с бумаги? Если нужен именно процесс переписывания, то можно оформить PDF без возможности выделения.
При сортировке деревом, нпр., решение очевидно:
Оно очевидно вам, потому что вы в контексте и держали эту задачу у себя в голове. А человеку без контекста решение будет совсем не очевидно.
Школьник найдет на Хабре решение для чисел Фибоначчи в одну строчку и перепишет. Учитель будет трудно отклонить такое решение — «мы lambda не используем» прозвучит неубедительно.
"Молодец, что нашел такой способ решения. В реальной разработке полезно пользоваться готовыми решениями. Но мы сейчас учимся, поэтому тебе будет полезно решить эту задачу самостоятельно. Сохрани оба варианта решения."
По моему мнению, польза тренажера не просто в том, чтобы перехватить нажатия клавиш и проверить корректность. Тут тоже важен порядок и постепенное повышение сложности. Сначала разминаем указательные, потом средние, потом мучаемся с безымянными и в конце страдаем с мизинцами.
Я до колледжа печатал двумя пальцами. А потом как то решился и сел за тренажер Шахиджаняна. Осилил только 50 заданий из 100, но сейчас оцениваю это как очень ценное вложение времени.
А как же развитие навыков оценки ситуации, анализа, планирования?
Сомневаюсь, что их тренируют каким либо другим школьным предметом. До массового распространения планшетов и мобильников в такие игры играли ради развлечения. А сейчас есть большой выбор кликеров и "три-в-ряд", которые не очень способствуют планированию и сложному анализу.
Как объяснить нужность предмета ребенку? Это точно не стоит делать с точки зрения "нужно ходить, иначе ...". Просто игра, в которую иногда и по вечерам интересно поиграть.
А далее появляется сомнение, что и все предметы могут быть ненужными.
Поддерживаю идею о том, что для каждой задачи нужен свой инструмент (язык) и что нужно попробовать хотя бы 2 разных.
На скорость написания кода, помимо самого языка и навыка быстрой печати, еще влияет IDE. Если освоить автодополнение, то скорость написания кода заметно возрастет. Почти для всех IDE есть вариант распространения Community.
Аналогия про перевозчика нелегалов просто супер. Многие люди были бы рады устроиться хотя бы ремесленником. А высокие материи придут с опытом и последующим образованием.
Обучаемый должен посмотреть под отладчиком по шагам как работает данный алгоритм, чтобы понять принцип.
А как убедиться, что такое задание выполнено?
Нпр., разные порядки обхода бинарного дерева. В учебнике в дерево записываются целые числа, а обучаемый должен модифицировать на строки. Сделать чтобы в дереве не содержались дубликаты данных.
Модификация на строки не выглядит полезным заданием. Если взять тот же питон, то там просто при вводе не парсить данные и все. В строготипизированных языках — просто типы поменять.
А вот исключение дубликатов тянет на полноценный, но другой алгоритм. Зачем для этого переписывать исходный?
Другие возможности в других языках не столь особые, и их используют часто.
Ну например есть чтение из консоли в Java.
До версии 8 нужно было вызвать дьявола для считывания целого числа из консоли.
Вот так:
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
try {
int a = Integer.parseInt(br.readLine());
} catch (IOException e) {
e.printStackTrace();
}
А в версии 8 для тех же целей ввели удобный класс. И тот же самый код оформляется вот так:
Scanner scanner = new Scanner(System.in);
int n = scanner.nextInt();
Студенту конечно же нужно знать про обработку исключений, потоки ввода-вывода в операционной системе, иметь представление о буферизированном вводе и его пользе при чтении данных. Но не на первом занятии же объяснять все это. Там нужно элементарно считать данные и вывести результат. Ну, может быть еще выполнить какие-нибудь арифметические операции.
Лет 7 назад там были весьма назойливые модальные окна и очень невыразительные сообщения об ошибках.
Если учесть, что в ходу может быть даже офис 2003 года, то новые версии офиса не сильно уменьшают дискомфорт.
Копаю дальше. Версия jre на windows нужна именно 32-разрядная. "Нужна" она только потому что об этом сообщает модальное окно.
После некоторого гугления обнаружил, что в этом офисе просто нет редактирования скриптов питона из коробки. Поэтому надо эти самые скрипты либо класть в директорию пользователя, либо распаковывать .odt как архив, вставлять туда файл, оформлять конфиг и запаковывать все это обратно.
Для запуска скрипта на питоне JRE на самом деле оказалась не нужна.
Все эти пляски с бубном для подключения это явный минус. Если складывать скрипты в общую папку на общественном компьютере, то будет немножко больше бардака. Но вот редактировать эти скрипты надо чем-то другим, т.е. нормальной IDE и храниться они будут как текст, т.е. в git. Так что это плюс.
Скачал, поставил. У свежей установки есть выбор между OOB, BeanShell, js, Python. Для последних трех нужна установленная JRE(!).
Для новичков надо чтобы "просто работало". Поэтому остается только Open Office Basic.
Судя по https://wiki.openoffice.org/wiki/Documentation/DevGuide/Scripting/Writing_Macros
там есть OpenOffice Basic, BeanShell, js, java, python.
При этом встроенный отладчик и редактор есть только для Basic и js.
Вот если бы в Excel было что-нибудь помимо VBA, с его отвратительным отладчиком, то программирование в школе можно было бы давать на нем.
Этот офисный пакет действительно востребован практически везде
совсем как js.Согласен. Возвращение кодов возврата в простых задачах неуместно. Оно полезно при работе с DirectX, SDL, WinAPI на С++, где иного выхода нет, либо вместе с HTTP клиентом, либо когда в программе много различных ошибочных исходов. Поэтому тривиальную задачу на такую тему придумать трудно.
Нужно ли вообще об этом подходе рассказывать в учебном заведении? Или отдать на самостоятельное освоение?
Я не предлагал все обработки исключений заменять на коды ошибок. Просто не нужно упускать их из поля зрения.
Непонятно еще, полезно ли вообще рассказывать о кодах возврата. Точно знаю, что если и рассказывать, то не с начала, а возле тех же исключений.
Не знаю насчет школьников, но начинающим взрослым на уровне задачек про квадратный корень нагляднее делать либо так:
либо так
Никаких исключений и кодов ошибок тут не надо. Лишние они, когда вся программа на одном экране помещается.
Исключение при чтении файла, который закончился, нагляднее предупреждать
if(!reader.EndOfStream){/*read*/}, чем ловить. Думаю, что это верно для всех языков.К тому же буквально вчера наткнулся на то, что StreamReader в C# исключение не бросает, а вычитывает null в случае с существующим, но пустым файлом.
Так что поведение при чтении пустого файла очень зависит от реализации этого чтения в конкретном инструменте.
Если через весь курс вести идею о том, что нужно выдавать адекватные сообщения об ошибке даже при неадекватных данных, то исключения хорошо заходят сразу после того, как объясняешь методы. Просто еще один способ обрабатывать ошибки. Поскольку до наследования и ООП еще не дошли, но иерархия классов исключений объясняется в терминах "общее", "частное". На этот эмпирический опыт потом накладывается объяснение наследования.
throw в Main никакой пользы не несет, поэтому и объяснение исключений откладываю до момента объяснения функций-методов. Кстати исключения — не единственный способ реакции на ошибки. Не забывайте еще статус-коды (WinAPI, HTTP) и Either в ФП.
Думаю стоит уточнить, чтобы не было разночтений.
Возьмем как пример ту же пузырьковую сортировку. В рамках учебы реализовать ее полезно. Один раз в жизни. Это достаточно сложная задача, требующая понимания массивов, при этом у нее простая постановка и идея. Но вот в промышленном программировании реализовывать ее руками вредно, т.к. есть стандартные библиотеки, которыми нужно уметь пользоваться.
А если вдруг стандартная сортировка не подходит? Допустим для сортировки по дате 20Гб записей о транзакциях на компьютере с 4Гб оперативной памяти. Тут на первый план выходят навыки анализа задачи и поиска оптимального решения.
При реализации этой самой пузырьковой сортировки эти навыки даже тренируются. Но алгоритм в этом случае не цель, а средство.
Поэтому считаю тезис "цель обучения в школе — добиться точного знания множества конкретных алгоритмов и умения их реализовать без справочника" ошибочным. Пусть даже алгоритмы и простые.
При таком подходе появляется проблема в случае, когда нужны промежуточные переменные. Но в процессе обучения, проблема "где лучше объявлять переменные" несущественна. Программки там маленькие и даже однобуквенные переменные a,b,c,d не вносят ощутимого бардака в решение. Можно сколько угодно требовать нормальное оформление кода и рассказывать про Mars Climate Orbiter, но пока это не приведет к шишкам от граблей, никто не поймет зачем надо его оформлять.
Популяризацией программирования сейчас не занимается только ленивый. И зарплаты тебе, и гамак, и два монитора.
Раз уж речь зашла про честность, то тогда уж точно не алгоритмы показывать надо, а более приземленное "подключись к базе данных, обработай результат запроса, нарисуй на формочке".
Недавних студентов-программистов к алгоритмам и не пустят. Тех же студентов-геологов привлекали ведь не для анализа грунта, а для копания земли, приготовления пищи и других хозяйственных активностей.
А для чего вам доказывать? У вас есть уютная экосистема технологий в которой вы профессионал. Может быть даже незаменимый. Доказательства вам "не убедительны" только потому что не интересно. Изучение какой-либо технологии это как восхождение на гору. Пока не заберешься, не увидишь открывающихся перспектив. Объективно, github и python — очень полезные технологии. Они помогают решать производственные и образовательные задачи. Если вам эти технологии не интересны — не пользуйтесь. Зачем демагогию устраивать?
По линейке СЛАУ и задачи по системному анализу отлично решаются в Excel. Это считается информатикой?
Вот только прикладное применение такой математики заключается в решении каких-то задач бизнеса. Найти оптимальный путь, распределить нагрузку и т.п.
Если проводить аналогию с "передать привязку булевой алгебры на информатику", то получается что надо "передать привязку линейной алгебры к решению бизнес-задач на работодателя"?
В нынешней ситуации если какой-то предмет вызывает вопрос "а зачем он?" и объяснение предполагается в рамках другого предмета, то у студентов получается закономерная реакция "сдать и забыть". А если это не желательный исход, было бы логично объяснять в рамках самого предмета.
Выгнать студента тоже не легко. Уже писали об этом.
Не будьте так категоричны. Такой вопрос я задаю только сильным студентам. Со сворачиванием и разворачиванием условных выражений, а также с другими задачами по программированию эти же студенты отлично справляются. Слабым сразу идет разбор решения задачи.
Дело в мотивации. Для сухой математики она звучит как "сдал и забыл" как раз потому что нет привязки к реальным задачам.
Зачем в таком случае нужно булеву алгебру как отдельную тему подавать? Тут уже приводили пример про Мольера и разговоры прозой.
Вот только подавать ее отдельно неполезно. Не всякий студент, который недавно сдал "дискретную математику", может сформулировать отличие "И" от "ИЛИ".
При этом в булевой алгебре нет никакой привязки к конструкциям ветвления.
Навык преобразования таких выражений во что-нибудь вроде
не требует привлечения сложного математического аппарата. Люди сами начинают так писать, если им вообще рассказать про логические операторы. Если очень хочется обратить внимание, то можно специальный набор заданий сделать.
По той же математике задача вполне понятная: реши уравнение и напиши ход решения на бумаге; или упрости выражение и получи эквивалентное.
Не понятно как будет выглядеть письменный или устный опрос по переписанному алгоритму. Можно поставить задачу на вычисление сложности, но это уже не школьная задача.
Главный вопрос при этом: зачем алгоритм нужно переписывать с бумаги? Если нужен именно процесс переписывания, то можно оформить PDF без возможности выделения.
Оно очевидно вам, потому что вы в контексте и держали эту задачу у себя в голове. А человеку без контекста решение будет совсем не очевидно.
"Молодец, что нашел такой способ решения. В реальной разработке полезно пользоваться готовыми решениями. Но мы сейчас учимся, поэтому тебе будет полезно решить эту задачу самостоятельно. Сохрани оба варианта решения."
По моему мнению, польза тренажера не просто в том, чтобы перехватить нажатия клавиш и проверить корректность. Тут тоже важен порядок и постепенное повышение сложности. Сначала разминаем указательные, потом средние, потом мучаемся с безымянными и в конце страдаем с мизинцами.
Я до колледжа печатал двумя пальцами. А потом как то решился и сел за тренажер Шахиджаняна. Осилил только 50 заданий из 100, но сейчас оцениваю это как очень ценное вложение времени.
А как же развитие навыков оценки ситуации, анализа, планирования?
Сомневаюсь, что их тренируют каким либо другим школьным предметом. До массового распространения планшетов и мобильников в такие игры играли ради развлечения. А сейчас есть большой выбор кликеров и "три-в-ряд", которые не очень способствуют планированию и сложному анализу.
Как объяснить нужность предмета ребенку? Это точно не стоит делать с точки зрения "нужно ходить, иначе ...". Просто игра, в которую иногда и по вечерам интересно поиграть.
По этому поводу есть замечательная карикатура.
Поддерживаю идею о том, что для каждой задачи нужен свой инструмент (язык) и что нужно попробовать хотя бы 2 разных.
На скорость написания кода, помимо самого языка и навыка быстрой печати, еще влияет IDE. Если освоить автодополнение, то скорость написания кода заметно возрастет. Почти для всех IDE есть вариант распространения Community.
Аналогия про перевозчика нелегалов просто супер. Многие люди были бы рады устроиться хотя бы ремесленником. А высокие материи придут с опытом и последующим образованием.
А как убедиться, что такое задание выполнено?
Модификация на строки не выглядит полезным заданием. Если взять тот же питон, то там просто при вводе не парсить данные и все. В строготипизированных языках — просто типы поменять.
А вот исключение дубликатов тянет на полноценный, но другой алгоритм. Зачем для этого переписывать исходный?
Ну например есть чтение из консоли в Java.
До версии 8 нужно было вызвать дьявола для считывания целого числа из консоли.
Вот так:
А в версии 8 для тех же целей ввели удобный класс. И тот же самый код оформляется вот так:
Студенту конечно же нужно знать про обработку исключений, потоки ввода-вывода в операционной системе, иметь представление о буферизированном вводе и его пользе при чтении данных. Но не на первом занятии же объяснять все это. Там нужно элементарно считать данные и вывести результат. Ну, может быть еще выполнить какие-нибудь арифметические операции.