Pull to refresh

Comments 164

Почему нет? Тем более плюсов там нет в примере, чистый С. Да если бы был — учат же не языку, а программированию. А это разные вещи.
ИМХО, идеальный вариант, сам начинал на псевдокоде, но по настоящему удовольствие стал получать когда стал в старших классах писать программы на C++. Они короче, быстрее пишутся и проще для понимания.
Но пожалуй сейчас актуальнее брать первым языком JavaScript.
Увы, не подходит в первую очередь из-за отсутствия статической типизации, см. мой ответ ниже.
C JavaScript легко найти подработку после уроков, вакансий полно. А проект на C++ ещё найти надо.
Без статической типизации вполне можно жить, почему она так важна для обучения — неясно.
Вы серьезно? Подработка для школьников? Это же даже не студенты, их знаний и навыков не хватит на серьезный проект, даже в рамках «подработки». В каком джаваскрипт-проекте сейчас обходится без jQuery, node.js или какого-то подобного фреймворка? Предлагаете учить школьников еще и этому?

Статическая типизация важна, поскольку позволяет привить дисциплину, «научить хорошему» сразу и надолго. Компилятор предупреждает об ошибках, заставляет следить за типами данных, а в случае JS — ошибка будет в рантайме, причем далеко не очевидная. Не могу согласиться, что джаваскрипт подходит для обучения — это язык для опытного программиста.

Мы и так в Си наступили на несколько неочевидных ошибок, связанных с преобразованием типов (наподобие применения abs к double), боюсь с JS это было бы намного страшнее.
Фреймворки — это отдельная тема. Аналогично я могу спросить будете ли вы рассказывать про Boost?
Что касается школьников, вы их недооцениваете.
В идеале вылавливанием ошибок должны заниматься тесты, а не компилятор.
Не буду. Но и не буду предлагать участвовать в реальном проекте, поскольку там обязательно найдется STL, Boost, Qt, Gtk или еще какая-нибудь библиотека. После второго года обучения, возможно, дети с этим справятся, после первого — нет.

Насчет тестов — спорно. Если ошибка может быть выявлена компилятором — она должна быть выявлена компилятором, это избавит от написания лишнего теста. Далее — чтобы ошибки вылавливались тестами их нужно сначала написать. А написанию тестов — научить. А чтобы научить написанию тестов — нужно научить программировать. Плюс изучить какой-нибудь тестовый фреймворк.

Но начинать обучение нужно с обучения программированию, основ. И джаваскрипт для этого далеко не самый подходящий язык.
Сам школьник, часто принимаю заказы от студентов сделать курсовые по программированию(в основном программированию графики на OpenGL ). Вполне нормальная подработка, что скажете?
Извините, в каком вы классе и сколько времени уже изучаете программирование?
Перешел в 10. Изучаю именно программирование около 4 -5 лет, около 2ух именно OpenGL. Естественно, пока изучал графику, за одно и познал некоторые элементы линейной алгебры, такие как матрицы, так что математическая база у меня несколько выше, чем та, что дают по школьной программе.
Вот вы и ответили на свой вопрос. А в начале обсуждения речь шла о том, чтобы изучать JS в качестве первого языка, под предлогом того что «C JavaScript легко найти подработку после уроков». Я и ответил что о подработке раньше чем через 2-3 года занятий говорить рано (не считая особо выдающихся учеников). Ваш пример только подтверждает мои слова.
Мм, действительно, извиняюсь. Просто я изначально не понял, что речь идет именно о подработке СРАЗУ после уроков(быть может это потому, что звучит это крайне нелепо).
Ситуация один в один, коллега :-)
А по поводу статьи: все верно, на уроках ИВТ учат не применению полученных знаний на практике, но синтаксису языка, что от реальности очень далеко. При этом учат штампованным алгоритмам, не разрешая отступать от них ни на шаг, даже в именах переменных.
UFO just landed and posted this here
Я за плюсы, но только если дети его действительно осиливают. Все таки это не на Бейсике квадраты с окружностями заливать. Может Си лучше для начала?
Ну по сути первый год обучения там и есть Си. Плюсы если и возникают, то только в виде небольшого синтаксического сахара к сишным конструкциям.
Лично у меня вышло как-то наоборот: в 7-8 классе, когда изучали псевдокод, я ни черта не понимал и все списывал. Как дело дошло до реального языка — я стал, без преувеличения, лучшим в классе и начал самообучение языку.
Да. На самом деле в начале обучения обходимся в основном Си, элементы «плюсов» появляются значительно позже.

А какие на самом деле еще варианты? Обучение начинается с процедурного программирования, поэтому Java, C# и прочие OO-языки, где без объекта простейшей программы не напишешь не подходят. К тому же в них достаточно «магии», наподобие сборщика мусора — это тоже плохо. Значит нужен процедурный язык. Нужна статическая типизация — это полностью укладывается в принцип «учить хорошему». Из чего выбирать? Паскаль и Си — ИМХО больше кандидатов нет.

Паскаль всем хорош, кроме непопулярности. Это язык для обучения, в реальных проектах практически не используется. Что очень критично — для него мало библиотек. Я считаю плохим решением учить на одном языке, а потом говорить «забудь все чему тебя учили, настоящие взрослые программы пишут на другом языке».

Как показывает практика, Си нормально воспринимается детьми, он не настолько сложен. Точнее — из него можно выделить подмножество достаточно простых конструкций и пользоваться ими, оставив «дебри», такие как шаблоны, множественное наследование и т.п. на будущее.
Нас в своё время именно на Паскале обучали. Turbo Pascal, даже не Object. Не скажу, что он мне нравится, но основы алгоритмизации на нём очень хорошо изучать. Если бы начали сразу с Си, то может и был другой эффект, не знаю. По крайней мере, опыт изучения разных языков всегда пригодится.
Ну по крайней мере большинство современных языков Си-подобны. Тот же C#, Java, Javascript — после изучения Си их синтаксис покажется знакомым. А вот синтаксис Паскаля — увы, отдельно от всего остального. В «свое время» он был эффективным средством обучения, сейчас — увы.

А основы алгоритмизации можно и на Си очень хорошо преподать. А кое-какие структуры данных, те же списки — даже проще чем на Паскале (по крайней мере мне указатели в Паскале всегда казались какими-то странными).
«одним из design goals при разработке Паскаля была возможность LL(1)-разбора — т.е. автоматом, который видит только один следующий символ текста. Большинство «живых языков» в LL не укладываются: например, в Си на int может начинаться объявление либо переменной, либо функции, и мы не может отличить одно от другого, пока не дочитаем строку до конца.»
habrahabr.ru/post/99466/

Это к слову о странности.
UFO just landed and posted this here
Если начинать с консоли — да, сложности будут. Но с ними можно справиться, если на первом этапе сказать «сейчас делай так, потом разберем подробнее что это за конструкция». Поэтому мы до консоли добираемся где-то во втором семестре, рассматриваем printf, scanf. А первый семестр построен целиком на рисовании через TXLib, там нет таких сложностей, все достаточно несложно и логично.

GoLang я, к сожалению, не знаю, поэтому не рассматривал. Учить нужно на том языке, который знаешь сам.
Когда приходится начинать с консоли (при переучивании первокурсников с Паскаля на Си), то объясняю так: когда scanf воспримет число с клавиатуры, он должен знать, куда его положить. Передать ему просто «х» — означает передать значение «х», а это ему бесполезно. Надо передать информацию, где находится переменная «х», где она лежит в памяти, какой у нее адрес. Как узнать этот адрес? Для этого есть оператор "&". &x — «адрес того места, где лежит переменная х». Поэтому когда на улице подходит гопник и спрашивает, с какого вы района, то он всего лишь применяет к вам оператор & :) Зная адрес, scanf закинет (запишет) туда значение. Кстати, термин «адрес» понятнее начинающим, чем «указатель», и второй я ввожу как синоним первого.

Вообще-то, конечно, лучше создать ситуацию, в которой очень хочется, чтобы функция меняла значение параметра. Например, напишем простейшее моделирование движения шарика по экрану с отскоком от стенок. Если говорить кратко, то отскок там будет выглядеть как vx = -vx или vy = -vy под условиями. Таких случаев будет 4 (не надо сокращать до двух:) ), и если рефлексы обучаемого правильно развиты, он захочет выделить эту физику в функцию. Реализовав ее, увидим, что шарик стоит на месте. Тут как раз очень удобно объяснить, что при вызове функции значения переменных скопируются и драматически проиграть эту ситуацию с листочками, на которых написаны значения — в конце «исполнения» листочки-копии с обновленными значениями торжественно разрываются и выбрасываются. Чтобы отменить копирование, надо передать не значение-копию, а информацию о месте, где лежит листочек-оригинал, т.е. его адрес. Далее см. объяснение выше. (Плюс есть еще пара аллегорий на тему копирования и указателей, которые придумались за время таких объяснений.)

Главное только рассказать это после возврата значения из функции (return), а то будут писать void-функции со сплошными указателями (то же происходит при использовании ссылок, поэтому о них я тоже не рассказываю довольно долго).

Понятные объяснения, но мне кажется вы недооцениваете сложнось преподавания школьникам. Я использовал эти сравнения, но все равно пришлось про указатели повторять несколько раз разными словами, в том числе рисовать на доске таблицу «адрес — значение».

Отличие между использование return и указателя на самом деле ввести просто: если функция модифицирует свой параметр — передаем указатель, если вычисляет что-то новое — используем return.
Если школьникам, то я ввожу это только вторым (основным) способом. Многое зависит от подробностей «игр» с листочками и используемых метафор, от умения читать декларации (plain-style, Yoda-style). Т.е., практически, это и есть повторение разными словами и даже способами. Это нормально, ведь ученик здесь впервые встречается с понятием явной косвенности в программировании, с которым он в других областях привык работать неявно. Кроме того, он впервые знакомится с базовыми понятиями архитектуры (адрес). Плюс, поняв концепцию, ему далее надо не запутаться в обозначениях. :)

Рисовать таблицу на доске или фрагмент оперативной памяти — очень и очень правильное занятие!

Про возврат значения я имел в виду не объяснение как таковое, а формирующиеся привычки. Если ученик не привык явно возвращать значение функции, он имеет тенденцию не пользоваться return (даже если он знает, что это такое), а передавать переменную по указателю. Часто это сочетается с неразборчивостью форм передачи переменной (проще говоря, он все начинает передавать по указателю, ему так проще, т.к. не надо тщательно продумывать о роли переменных) — далее это ведет к спутанности логики и неудачной архитектуре. Синтаксический сахар в виде ссылок здесь приводит к синтаксическому «диабету» и провоцирует эту спутанность, т.к. не надо думать даже о синтаксисе. Склонность некоторых паскалистов передавать параметры как var (через ссылки) имеет ту же природу.
А на примере какой задачи вы вводите return и как она встраивается в программу? Я не увидел возможности дать возврат значения во время обучения анимации, поэтому в моем курсе они оказались перепутаны — сначала указатели, потом return.
В задаче движения шарика можно ввести препятствия, это превращает (управляемую) анимацию в простую игру. Столкновение с препятствием или другим шариком можно рассчитывать по теореме Пифагора, это достаточно муторная запись, чтобы возникла мотивация сделать функцию с возвращаемым значением (про hypot не рассказываем). Если дети не знают теоремы Пифагора, то можно работать через txGetPixel, но тогда их потребуется несколько, чтобы учесть размеры объектов — это тоже мотивация для рефакторинга с выделением кода в функцию.

При дальнейшем развитии игры возникает желание сделать главное меню программы с пунктами «игра», «выход» и т.д., а это проверки на нажатия мышки в прямоугольник (опять функция с return-ом). Кроме того, функции игры часто полезно возвращать значение {проиграл, выиграл, прервал игру, что-то еще} для какой-либо индикации или действий в главном меню (например, break из цикла или rerurn из main).
У меня так и получилось, когда начали делать игру. Но ведь сначала делается движение (указатели) и только потом проверка на столкновения (return). А в комментарии выше, вы пишете что указатели нужно давать до return.
Имхо совсем необязательно в одном занятии делать прототип движущихся шариков с физикой, прописанной в прямо цикле движения, и рефакторинг кода с выделением функции (и указателями). Можно сначала рассмотреть препятствия и return. Хотя в принципе, если группа сильная и уверенность в ней есть, можно return давать и после указателей. Главное, чтобы произошло не вытеснение одного метода передачи результата другим, а грамотная расстановка акцентов. В слабой группе это не всегда просто дается, и тогда я не рискую и разношу методы по времени. (Возможно, я выше был слишком категоричен в вопросе о последовательности.)
Сложность перехода с паскаля на си, все-таки, преувеличена, немного. Но я считаю, что язык должен выбирать преподаватель, си, значит си, джава-скрипт, значит джаваскрипт, лишь бы он смог этот язык объяснить ученикам.
Сложнее обратный переход :)
Имхо, разумеется, но популярность языка здесь неважна. Паскаль проще с точки зрения понимания и отладки, поэтому при обучении программированию будет проще сконцентрироваться на алгоритме и задаче, а не сайд-эффектах языка и их отладке.
Важна, если воспринимать обучение не как изолированный процесс, а как часть системы. Наша программа обучения ориентирована на практику и использовать язык, который не имеет большого практического применения, я не вижу смысла. Рано или поздно мы упремся в ограничения языка (или экосистемы, например, не сможем найти нужную библиотеку) и что тогда? Говорить детям «мы вас тут учили не совсем правильно, давайте быстренько выучим Си и дальше будем писать на нем»? ИМХО — не вариант.
Что значит «учили неправильно»? Вы же говорили, что учите детей именно программировать.

И да, сразу вспомнилось вот это
Да, программировать. Это значит что в будущем для них перестанет иметь значение язык программирования, они смогут переключаться, осваивать новые для себя языки. Но метаться между языками в процессе обучения я считаю недопустимым.

Ссылку просмотрел, сразу могу сказать что автор настроен к Си предвзято. Он говорит что не может понятно объяснить «Hello, world!». Сравните с моим примером — программа подлиннее чем «Hello, world!» и тем не менее с ней особых проблем не возникает, нужно только подобрать правильные слова, не бросаться в дебри, наподобие «директива макропроцессора», «возвращемый тип данных» и прочие:

#include <stdio.h> //включили (include) в программу модуль ввода-вывода

int main() //начало главного (main) фрагмента программы
{ //начало
  printf("Hello, world!\n"); //напечатать (print) на экран строку
  return 0; //вернуть количество ошибок - ошибок нет, возвращаем 0
} //конец


Так что я с автором не согласен, на Си вполне можно (и даже нужно) учить программированию, наша практика это подтверждает.
Почему нельзя менять язык? Можете посчитать сами сколько раз язык менялся у меня в школе habrahabr.ru/post/136272/#comment_4537012, и ничего, очень даже полезно это оказалось.
Менять язык можно, но я считаю это контрпродуктивным. Время потраченное на смену языка, на изучение новых конструкций — по сути потрачено неэффективно.

Вот простой пример. В Паскале
if a=b then

В Си:
if (a==b) {

Маленькая разница между = и ==, а сколько проблем. Некоторые из моих учеников (10 класс) параллельно учили Паскаль в школе. Путаница между = и == случалась регулярно.
И опять же, динамическая типизация. Хотя язык отличный, ему можно и нужно обучать, но после того, как основы программирования заложены.
Она динамическая, но сильная в отличии от JS или PHP.
Akela_wolf В питоне начиная с 3.5 есть type hints это уже зачатки статической типизации, до этого похожая возможность была в виде отдельной тулзы mypy.
Питон или Руби.
Оба — красивые языки, прививающие любовь к хорошему коду.
Нужна статическая типизация — это полностью укладывается в принцип «учить хорошему».

Чем плоха динамическая типизация?
Тем что при использовании динамической типизации очень легко наделать ошибок, которые проявятся только в рантайме и которые начинающему сложно находить.
Да ладно. Мы сейчас говорим о коде, где ошибка проявляется один раз на тысячу запусков или почти гарантированно на каждом запуске (в учебных проектах почти всегда так)?

Я не вижу большой разницы между ситуациями:
1) Компилятор говорит, что у меня ошибка такая-то в такой-то строке.
2) Я запускаю код, и он вываливается в дебаггер с сообщением об ошибке такой-то в такой-то строке.
Даже в статически-типизированном Си у моих учеников случилась ошибка, проявлявшаяся не на каждом запуске (неинициализированная переменная).
Но пусть она даже появляется каждый раз — проблема не в том, что программа остановится (это хорошо если остановится). Она может работать неправильно, выдавая чудные результаты и искать такую ошибку может быть достаточно сложно (повторюсь, даже ошибка округления в результате преобразования double -> int была достаточно проблемной для поиска). А если остановится — место где она остановится может быть достаточно далеко от места где сделана ошибка (даже в другой функции, даже не по стеку вызовов). Опять же начинающему находить такие проблемы очень непросто.
Ха, ну так видите — дело не в типизации, а в языке. Вот в C# программа с неинициализированной переменной не откомпилируется.

Я думаю, что вы в целом несправедливо проводите разграничение по линии типизации.

Да, C — язык со статической типизацией, но его типизация позволяет выполнять дивнейшие фортели.
В то время как более современные языки с динамической типизацией могут быть гораздо строже к выполняемым конструкциям.
Всё зависит от конкретного языка.
В таком случае, считайте меня сторонником статической типизации (каковым я и являюсь) :) С моей точки зрения у статической типизации больше плюсов, особенно в учебных целях.

В идеале я бы выбрал язык с более строгой типизацией, чем Си, тот же Java, например. Но с ними другие проблемы. Поэтому приходится идти на компромисс.
Проблему Java вы озвучили — объектно-ориентированность, но реальные эксперименты (Кэя или Парнаса, упоминал...) её опровергают.
Не знаком с этими экспериментами. Но из моей практики — объект это далеко не самая простая для понимания вещь, особенно когда доходит до полиморфизма, даже студенты не все это хорошо понимают.

А использовать объекты как контейнеры для статических методов — значит по сути не использовать их вообще.
Ну, просто Java — язык агрессивно объектный, надо взять что-то менее заставляющее принудительно пользоваться объектами.

Я исхожу из того, что недостатки C ещё более существенны и формируют достаточно однобокий взгляд на программирование. Конечно, как преподаватель вы можете его скорректировать, но это приходится делать явным образом.

Например, в C есть массивы, но нет ассоциативных массивов. А ведь с точки зрения логики в чём разница? Там сопоставляют структуру целочисленному индексу, а здесь один объект другому. Словарь, телефонный справочник.

В C его нет лишь потому, что авторы не удосужились его добавить. А у школьника возникает сразу же деление структур данных на «встроенные в C» и «какие-то-другие-из-сложного-учебника», которые надо либо подключать в сторонних библиотеках, либо писать самому.

Если программирование — это структуры данных и алгоритмы, то в C всё очень скверно со структурами данных, и если уж изучать программирование на примере C, то параллельно надо читать отдельную книжку по структурам.
Так в этом его преимущество! Когда будем изучать структуры данных, дети должны будут сами написать тот же ассоциативный массив (map), поймут как он работает, ощутят его особенности «на собственной шкуре», а не просто подключат библиотеку. В обучении должно быть минимум «магии», ученики должны понимать как устроено то что они используют.

Кстати, в Си ассоциативных массивов нет не потому что «авторы не удосужились добавить», а потому что работать с численными индексами — естественно для компьютера (адресная арифметика), а с сопоставлением «объект-объект» — нет. В первом случае алгоритмы тривиальны, во втором — увы, нет.

Обратите внимание, в C++ тоже нет ассоциативных массивов, они в STL, но не в самом языке.
Мы вступаем на очень тонкий лёд. Безусловно, они должны понимать, как работает структура данных, но реализовывать всё самим — а где та грань? Почему бы им самим не реализовать, например, функцию синуса — или вы тоже их это заставляете? Я думаю, что любой человек должен прежде всего знать наперечёт все базовые структуры данных, а их реализация — вопрос уже следующий.

Ученики всё равно не могут всё знать. Вот спросите, как в компьютере вычисляется логарифм или квадратный корень — уверен, далеко не все ответят.

По поводу «удосужились — не удосужились» — вот в Паскале есть встроенные операции со множествами, а в Си нет. Не удосужились :)

В C++ ассоциативные массивы есть. Я не знаю, что такое STL (dumb mode on) — если вы заглянете в Стандарт C++, то увидите там упоминание std::map наряду с std::max(), например, а слова STL вы не увидите нигде. То, что исторически map взят из библиотеки STL, не имеет никакого значения. Я тоже могу сказать, что в C нет поддержки файлов — она есть в stdio.h.
Синус вычислять, конечно, не заставляю. Хотя если кто-то захочет — мешать не буду, это полезный опыт.

Но с моей точки зрения нужно знать структуры данных и принципы их реализации. Иначе вопросы «почему в списке время доступа к произвольному элементу O(n), а в массиве O(1)? А почему в дереве O(log n)?» будут ставить в тупик. А чтобы понять принципы реализации нужно их реализовать на практике.

Это промышленный программист не может позволить себе изобретать велосипед, в целях обучения собственные велосипеды необходимы.
Конечно, поддерживаю. Но в общем-то всё это вопрос нюансов.

Рассмотрим вот такую простую задачу: с клавиатуры вводится массив чисел (число-enter-число-enter...), пока не будет введён нуль. Далее этот массив каким-то образом обрабатывается.

В чистом C эта банальщина реализуется очень трудно (т.к. нет автоматически растущих массивов). Получается, либо надо выделять фиксированный блок на N элементов (чему мы учим детей??? этому чудовищному стилю, где возможен buffer overflow?), либо реализовывать поведение наподобие того, что есть в std::vector.

Получается, что да, технически мы имеем сложную задачу, но логически это минимальный юнит кода, чисто служебный. Аналогично, есть задачи, где ассоциативный массив напрашивается, но писать его самостоятельно (даже в учебных целях) никто не будет, т.к. реализация займёт 50% всего кода. Игра не стоит свеч. Вот и будут делать линейный поиск.

Таким образом, получается, что дети не учатся выбирать наиболее эффективную структуру данных для своей задачи. Если реализация тоже ложится на их плечи, конечно, будет выбрано наиболее простое решение. Да ё-моё, я сам почти всегда пишу std::map, даже если правильнее было бы взять хэш-таблицу, но как стандарт она появилась только в C++11.
Если следовать основной мысли подхода, а именно учить не языку, а решению задач, то я предлагаю Scheme. Сам я начинал с С. Так вот, для того что б начать программировать на С, нужно хоть базово знать архитектуру процессора и основы организации памяти в компьютере.
Lisp-подобный синтаксис начинающим? В качестве первого языка? На второе занятие придет половина группы, на третье — один человек.
Ну это же стереотип. Для мелких заданий очень даже удачный синтаксис.
А для чего-то более-менее крупного? Хотя бы квадратное уравнение решить — в скобках не запутаетесь?
Математические вычисления действительно в лиспе выглядят не очень красиво. Но не одних только вычислениях мир сошёлся. Если брать для примеры программ для вашего ТХ, то лисп тоже будет весьма простым выглядеть.
Ну так это же только примеры. Начинается анимация — начинаются вычисления. Делаем игру — тоже вычисления, логика. Хотя бы даже проверить попадание точки в прямоугольник:
struct Rect {
  int leftPos;
  int topPos;
  int width;
  int height;
}

bool isInside(Rect rect, int x, int y)
{
  bool xInside = (x >= rect.leftPos) && (x <= rect.leftPos + rect.width);
  bool yInside = (y >= rect.topPos) && (y <= rect.topPos + rect.height);
  return xInside && yInside;
}

А как это будет выглядеть на лиспе?
На кложуре это может выглядеть так:
Объявление прямоугольника
(def rect {:leftPos 1
           :topPos  2
           :width   3
           :height  4})

Функция проверки принадлежности
(defn inside? [rect x y]
  (let [{:keys [leftPos topPos width height]} rect
        x-inside? (<= leftPos x (+ leftPos width))
        y-inside? (<= topPos y (+ topPos height))]
    (and x-inside? y-inside?)))

В принципе не особо и страшнее получилось.
На Scheme:

(define (left-pos rect) (car rect))
(define (top-pos rect) (cadr rect))
(define (width rect) (caddr rect))
(define (height rect) (cadddr rect))

(define (in? x low hi)
  (and (>= x low) (<= x hi)))
                         
(define (inside? rect x y) 
  (and
   (in? x (left-pos rect) (+ (left-pos rect) (width rect)))
   (in? y (top-pos rect) (+ (top-pos rect) (height rect)))))

(inside? (list 0 0 30 40) 20 30)
Вот решение квадратного уравнения.

(define (discriminant a b c)
  (- (* b b) (* 4 a c)))

(define (solve a b c)
  (let ((d (discriminant a b c)))
    (cond ((< d 0) (error "уравнение не имеет действительных корней"))
          ((= d 0) (- (/ b (* 2 a))))
          (else (list (/ (+ (- b) (sqrt d)) (* 2 a)) 
                      (/ (- (- b) (sqrt d)) (* 2 a)))))))

(solve 1 8 7)

Разве все так ужасно выглядит?
7 скобок подряд — да, это ужасно.
Если оценивать программу по числу скобок, то да. Но мне кажется это не совсем разумный критерий.
А как вам такой критерий:
На математическую запись этого решения не похоже вообще
Этот критерий мне больше нравится. Нет претензии «много скобочек — некрасиво». Я уже говорил, что на лиспах средние и сложные арифметические операции выглядят не очень красиво. К счастью не так уж часто приходится их использовать.
Си как и Паскаль — морально устаревшие языки, которые тянут за собой огромный багаж не самых красивых архитектурных решений, дырок, да и просто ненужностей (для современного мира). Для нас, состоявшихся программистов, это не проблема — если понимаешь суть, можно писать хоть на Паскале, хоть на Коболе. Работа есть работа.

Использовать же его для обучения детей — это значит объявить последние 35 лет развития IT технологий потерянными. Дескать, ничего за эти годы достойного не появилось. Это крайне печальная и несправедливая позиция. Скажем, со времён Паскаля даже его непосредственный автор сочинил Модулу, Модулу-2, Оберон и Оберон-2 — вероятно, считая их более совершенными языками.

Детям нужно давать язык, на котором писать легко и приятно. Да, рано или поздно нужно изучить C, чтобы понимать внутреннее устройство компьютера и знать, что почём, что сложение целых и сложение строк — далеко не одно и то же. Но если ребёнку надо выполнить десяток базовых операций над строками, и мы для этой цели предлагаем strcpy(), strcat() и иже с ними — это форменное издевательство.

К сожалению, есть объективная проблема: как только кто-то изобретает «простой» язык для обучения, у языка тут же находятся адепты, желающие решать на нём реальные задачи, и язык тут же начинает обрастать разными нетривиальными средствами. Конечно, так происходило всегда, но не с нынешней скоростью.

Я бы сам детей учил либо на C#, либо на Питоне. Из старья — рассмотрел бы даже QuickBasic, всяко проще Паскаля. А MS вообще вон придумала SmallBasic для детей — совсем неплохо. По поводу «объектной ориентированности» — кто-то из патриархов (то ли Кэй, то ли Парнас) писал, что дети прекрасно осваивают объекты, и ничего страшного в них нет.
Учить на «чистом» Си может быть не самое лучше решение. Но Си + учебная библиотека (в роли которой TXLib) превращается в мощный инструмент. Не хотите издеваться над детьми с функциями вида strcpy, strcmp. stricmp и подобными — напишите несложную библиотеку, которая все это скроет от них.

Мы же просто не используем строковых операций до второго года обучения, без них прекрасно можно обходиться.
Можно, но почему?

По-моему, моя первая компьютерная программа была чем-то вроде:

INPUT name$
PRINT «Hello, »; name$; "!"

Получается, какие-то довольно простые и прикольные вещи скрыты лишь потому, что конкретный язык этого не позволяет.

TXLib — хорошо, но в любом упомянутом мной языке тоже есть хорошие библиотеки.
Всему одновременно научить нельзя. Чему учить и в какой последовательности — это определяет программа обучения. Конечно, она подбирается под возможности языка, так что выбери мы другой язык — произошло бы тоже самое «простые и прикольные вещи скрыты лишь потому, что конкретный язык этого не позволяет». Увы, нет языков одинаково хорошо справляющихся с любой задачей.
А как Вы отнесетесь к Scala (Kojo)?
Статически типизирован, поддерживает разные стили, доступны библиотеки Java.
Есть REPL — на мой взгляд важно для обучения.
Я дико жалею, что в школе нас пичкали фигней… интересно как жизнь повернулась бы… т.к. программинг привлек внимание только к 20 годам, хотя до этого я его обходил стороной
Я тоже компьютеры увидел в 23, вместе с программируемыми калькуляторами.
В институте программировали только в тетрадях.
И ничего, программист :-)
Ну «ничего» это… Представьте сколько времени можно было бы сэкономить… я например сначала в ФизТехе учился, щас заканчиваю дизайнерский =)) и главное: хочу связать жизнь с программингом — если бы в школе что-то было иначе возможно не пришлось бы терять столько лет чтобы найти себя)
Познание других областей знаний тоже полезно. Можно говорить со специалистами на их языке.
Может, судьба такая — физику визуализировать :-)
Преподаватель должен обладать опытом практического программирования

Это должно быть первой фразой в любой статье такого рода. Извините, наболело.
UFO just landed and posted this here
email — для старперов, все давно пользуются контактом =)
Из всех моих знакомых ИТшников, только десяток знакомых из киевского Фидо есть в одноклассниках.
Во вконтакте из ИТшников всего пару человек, зато в скайпе и фейсбуке есть и активно общаются почти все.

Так что очень зависит от окружения, имхо
UFO just landed and posted this here
но не учат намного более важному умению — применять их для решения возникающих на практике задач

к сожалению, это не только к программированию относится и не только к школе, но и к ВУЗу
При моих попытках учить людей программированию самым сложным всегда было дать понятие переменной. Отсылка к аналогичному понятию в математике и/или физике скорее мешала, чем помогала. Приходилось опускаться до уровня чуть ли не ассемблера, рассказывать об организации памяти (линейное пространство, прямая и косвенная адресация и т. п.) причем «на пальцах», без примеров кода.

Как у вас вводится? Читал рассказ ожидая этого момента, но очень вскользь затронуто.
С понятием «переменная» каких-то проблем не было. Вводил я его очень просто — вот в программе у нас есть число (литерал). Хорошее такое число, но у него есть недостаток — оно постоянное, а нам нужно его менять. Мы ему можем дать имя (константа), но все равно не сможем менять значение, константа это просто понятное имя для числа. Дальше обсуждение как эту проблему решить. Собственно к этому моменту дети уже понимают разницу между именем и значением, говорят — вот было бы хорошо менять значение константы, а это и есть переменная.

Больше проблем было с указателями. Вот тут пришлось рисовать на доске схему организации памяти, рассказывать адресацию и прочее. В итоге дети почти без подсказок дошли до случая «указатель на указатель» :)
А я объяснял переменные так:
У вас есть коробочка с надписью на ней «Имя(Name)», вторая коробочка с надписью «Количество лет (Age)», и т.д.
А значения — это листочки с текстом, которые мы кладем в коробки.
Присваивание — это ксерокопирование листочка со значением, затем кладем копию в нужную коробку.

А указатели — еще проще:
Вот есть человек — это объект.
А есть его телефонный номер — это его указатель.
С помощью телефонного номера мы можем звонить человеку, отдавть ему команды или что-то у него спрашивать.
Листок с телефонным номером можно отксерокопировать сколько угодно раз и хранить в любом количестве коробок.
Так хорошо объяснять в Java или C#. А у них C, где указатель обычно не адресует объект, а используется для всяких трюков типа передачи массива в функцию, прохода по строке, тут же арифметика указателей приплетается, надо объяснять, в чём разница между указателями на разные типы и т.п.
Адресную арифметику детям не рассказываем. Даже массивы прекрасно даются без адресной арифметики. Указатель адресует что-то (целое число, дробное число, структуру и т.д.)
Я на своих занятиях ввожу на нескольких примерах:
Коробка, куда можно положить что-то. На коробке написано иия. Сразу с указанием того, что в отличие от вещей данные копируются.
Второй пример — флешка. На флешку влезает 1 файл. На флешке написано имя.
Но это почти не требуется, понятие буквенных обозначений знакомо из математики.

Чтобы не было проблем с оператором присваивания, первое время для его обозначение не использую знак равенства.
Сразу объясняю, что это оператор, мы его можем обозначить как хотим. Давайте договоримся использовать для этого стрелку.
Но может быть используем знак равенства, человечка, хоть летающую тарелку.

Типизация:
Напоминаю им про пример с коробкой. Но коробки для велосипеда и мячика разного размера и формы.

Указатели:
Напоминаю им про пример с коробкой-ка переменной. Прошу представить, что все вещи у нас лежат на складе. Склад представляет собой много квадратов, пронумерованных по порядку начиная с 0. Коробка занимает несколько соседних квадратов.
Есть коробка с нарисованной буквой А, внутри нее бумажка с адресом квадрата, на котором мой велосипед.
Выделение памяти, освобождение — запись в амбарной книге у кладовщика. И так далее по всем понятиям, связанных с адресной арифметикой.
Нам в университете в курсе логического программирования рассказывали, что ни в коем случае нельзя проводить аналогию между переменной в математике и переменной в императивных языках. В математике переменная не имеет никакого конкретного значения (даже наоборот), а в том же C++ переменная всегда имеет вполне конкретное значение (если инициализирована, конечно). Математическую переменную можно сравнить с переменной в Прологе, но никак не в императивных языках.
Я до этого дошел опытным путем. Теперь не привожу, просто рассказываю про память и что имя переменной это адрес памяти, в которой храниться какое-то значение (в некотором диапазоне), но одно и только одно.
Очень интересно! Спасибо!
А можете подробнее рассказать о своей программе? На сколько рассчитан курс обучения, какие темы подымаете? В чем проявляется недостатки вузовского образования по программированию?
Про программу нужно рассказывать отдельным постом. Курс планируется на два года, может быть в будущем мы его скорректируем.

Если кратко: первый семестр осваиваемся с рисованием мультика (функции, циклы, структуры, собственная библиотека функций, документирование и прочее). Под конец первого семестра, в начале второго, делаем игру (взаимодействие с клавиатурой, ветвления, указатели, массивы, освоение работы с достаточно большим проектом). Ближе к концу второго семестра меняем тему, начинаем рисовать графики математических функций, здесь знакомимся с указателями на функции.
Второй год начнем с синтаксического разбора арифметического выражения, затем элементы объектного программирования. Попробуем сделать универсальный построитель графиков, способный обработать введенную пользователем комбинацию элементарных функций. Дальше запланирована возня с графическим интерфейсом — окна, виджеты и прочее, углубление знаний и навыков в ООП. Но, как известно, ни один план не выдерживает столкновения с реальностью, посмотрим как будет дальше. На второй год, кстати, планируем знакомство с mercurial и его практическое использование для командной работы.

Недостаток вузовского образования глобально один — нет практического опыта, нет умения применять знания для решения задач, отсюда вытекает все остальное.
Скажите, а почему бы не ввести систему контроля версий гораздо раньше? Не вдаваясь в дебри и подробности просто объяснить, что это такая штука которая поможет «не потерять» исходники при переписывании или случайном удалении. Наверняка подобное хоть раз, но случалось. Достаточно просто результаты каждого урока оформлять в виде коммита, а потом дать детям возможность пробежаться по своей программе и увидеть, как она изменялась.

Опять же, это разовьет навыки своевременного сохранения работы и важность бекапов (в будущем).
Мне кажется, это будет очень хорошим подспорьем в деле правильной организации работы.

И только потом уже имеет смысл рассказывать про бранчи и прочие операции, сложнее чем hg ci / hg up
Чтобы осознать пользу от подобной системы хорошо бы потерять исходники разочек :) Тогда больше не захочется.

Я этот вопрос задавал Илье Рудольфовичу при личной встрече, он ответил что для первого года это слишком сложно. Дети не понимаю зачем это нужно и как этим пользоваться. Первый год у них и так достаточно нового материала, чтобы дополнительно нагружать системами контроля версий.

А на второй год ввести подобное становится достаточно просто — после знакомства с системой контроля версий учитель принимает только тот код, который лежит в репозитории.
Ну так вполне же можно спровоцировать ситуацию, когда исходники «потеряются» :) Лучше обжечься на чем-то простом, чем потом потерять месяц работы из-за ерунды :)

Ведь для начала можно даже не объяснять сути VCS. Например по началу результаты каждого урока складывать в отдельную папочку на дропбоксе, а потом перейти к тому что это неудобно, легко запутаться и т. д. и предложить делать коммит. Но это уже конечно сильно зависит от специфики.
тема интересная

хотелось бы узнать как устроенно рабочее место для школьника: какой софт используется, где хранится код?
Код хранится в dropbox. У каждого школьника свой аккаунт, с которым они могут работать как в классе так и дома.

В качестве IDE используем Geany, но, вероятно, будем что-то менять к новому учебному году — инсталляция на домашний компьютер даже при наличии подробных инструкций превратилась в натуральный квест. Компилятор — gcc.

Документация к библиотеке генерируется с помощью doxygen. Плюс браузер, чтобы залезть в интернет при необходимости.

Собственно пока все, никакого другого софта не использовалось. На второй год будем изучать mercurial и bitbucket или аналогичный сервис.
Тема интересная, я веду факультатив «основы программирования» 1 курс
У студентов кроме меня, есть основной курс программирования

Пришел к тому, что потребовал от студентов разжиться ноутбуками
(Работа каждый раз с новым компьютером в новой аудитории — вводила их в ступор)

Среда программирования: vs2010 express
(12 — не пошла, не смогли поставить)

Свой код я раздавал через github.com/BloodJohn/console_app
(Можно скачать архив через web и распаковать прямо на занятии)

Еще одна проблема, с которой я столкнулся — никто не учит терминологии.
(Очень помогло, когда я расписал в комментариях, что именно происходит в каждой строчке кода)

У студентов был натуральный ужас, когда первый раз рассказывал про параметры/аргументы и объявление/реализацию функций.
С указателями и строчками было чуть проще.
У нас проще — домашние директории пользователей хранятся на сервере, то есть влогинившись с любого компьютера под своей учеткой школьник видит свои файлы и настройки. Плюс дропбокс для синхронизации между домашним компьютером и классом. Так что этой проблемы практически нет.
в школе учат не решению проблем с помощью программирования, не разработке программ, а лишь языку программирования как таковому


Вы знаете, это очень повезет, если хотя бы так.
Знакомая год назад показывала мне свою тетрадку по информатике (училась она в одном из довольно известных лицеев Москвы, 9й класс).
Суть в том, что вела предмет пожилая женщина, точно за 65, и преподавала она так называемое программирование.

Смысл был в следующем — компьютеры при обучении не использовались принципиально.
Все занятия проходили на доске/в тетрадках, обучали их какому-то русскоязычному псевдокоду (то ли такой действительно существует и используется для обучения, то ли это изобретение этой самой учительницы). На доске она писала и пыталась объяснять конструкции вроде:
Если а=б то
а:=c
Конец если


Что-то между русским языком и паскалем. Сейчас могу уже ошибаться, но конструкции там были не хилые.
После чего ученикам в качестве домашнего задания задавали написать рабочую программу на этом псевдо-языке в тетради.
Тетради сдавались ей на проверку. Плюс нужно было еще какой-то устный тест сдать ей. Естественно, никто не мог этого сделать, и все ходили к ней пересдавать до конца года по нескольку раз на тройку.
Я когда эти «лекции» и «домашние задания» (точнее, попытки их решить) увидел, чуть не упал.
Вероятно нечто вроде этого
Проц Старт()
    Вывод 'Здравствуй, мир!'
Кон Проц

Называется Рапира В обиходе «русский паскаль» В конце 80-х- начале 90-х его массово в школах давали, афаик (в нашей давали точно :)
Есть ЛКШ (летняя омпьютерная школа), в которой не плохо учат программмированию. Объем знаний огромный и превышает бинпоиск). Вот ссылка на учебные параллели и их программы.
Не стоит думать что все чему научились дети — это только бинарный поиск. Это был просто пример хорошей самостоятельной работы.
Я так и не думаю. Просто я этим занимался гораздо раньше, чем 9-11 класс. Я рисовал в бейсике классе в 5-том. Поэтому в возрасте 9-11 класс остается больше времени для изучения более продвинутых алгоритмов. Я думаю надо этому класса с 5 — 7 учить.
Мне интересно следующее: а как у обучаемых с английским? Ведь тот же компилятор выводит сообщение об ошибке не на русском языке. Не мешает ли это обучению?
Большинство изучают в школе английский. Конечно, недостаточной уровень знания языка мешает, приходится переводить, объяснять. Но сообщения об ошибках довольно типичны, ученики довольно быстро начинают в них ориентироваться самостоятельно.
Мне кажется, что наибольшего успеха можно достичь, начиная обучать учеников 8-9 класса — в дальнейшем обучаемость снижается.


Я обучаю школьников программированию более 7 лет (в системе доп. образования детей). Контингент был с 4-го по 11 класс. Мои выводы для общей массы детей (не берем случаев одаренности):
1) Учить детей младше 8-го класса чему-то более сложному, чем Logo и HTML не стоит. У них еще нет жизненного опыта, чтобы вполне осозновать, зачем это надо. Кроме того, они в принципе не могут понять сложные логические конструкции. Их мозг еще привян к наглядности и им сложно рассуждать абстрактно.
2) Восьмиклассники справляются с основами программирования. Это возраст, когда надо начинать знакомить с каким-либо языком программирования. Подготовка простых проектов помогает обучению, сложных и объемных — только мешает и путает ученика, способна заварить кашу в голове ученика. Обучение основано на многократном повторении: решаем много аналогичных задач.
3) Учащиеся 10-го класса намного быстрее осваивают программирование по сравнению с 8-м классом, даже если до этого они с ним не были особо знакомы. Это факт. То что с 8-ми классником я прохожу за 3 месяца, с десятиклассником — за 1 месяц. Десятиклассник легко видит аналогию, легко перекладывает опыт решения прошлой задачи на новую, легко обобщает.
Примеры проектов, которые делают подростки: younglinux.info/projects
Большинство из тех, что там перечислены, занимали призовые места на всероссийской конференции «Шаг в будущее».
его ученики уже в 9-11 классе пишут программы, по сложности соответствующие 3-4 курсу технического вуза (!) — компиляторы


Было бы интересно посмотреть на компилятор, написанный 11-тиклассником. На сайте Дединского вижу разбор выражений методом рекурсивного спуска от второкурсника и попытку восьмиклассника сделать трансляцию автоматов на Visio в С.
Что -то мне все-таки кажется, что от правильной расстановки пробелов и игры «Угадай число» до 3D-движков дистанции огромного размера.
Вот, почти сходу на его сайте нашлось: Платформа для машинно-независимого исполнения программного кода с возможностью JIT-компиляции


Это очень круто (остальные проекты тоже, наверняка хороши, просто я в этих опенглях не разбираюсь)).
Ну, соответсвенно возникает вопрос сколько в этом успехе от методики, а сколько от таланта ученика (который очевиден).
Ок, рассказали мы ученикам про пробелы, отступы и пустые строки, напугали страшными последствиями ошибки в модуле, но опыт показывает, что теперь ученики могут самостоятельно писать «Угадай число». Как до JIT-компиляторов-то доскочить, в чем секрет?
Вот как думаете, у ваших учеников результат воспроизведется, будут они динамические анализаторы C++ в старших классах писать?
Что я могу сказать кроме банального «поживем — увидим»? Среди моих учеников тоже есть способные ребята, которые стремятся развиваться дальше. Главное — у них есть интерес, есть стремление, я думаю что секрет в этом. Если есть желание развиваться, если желание учиться программированию встречает содействие со стороны учителя, если учитель направляет развитие так, чтобы оно было максимально продуктивным, то результат не заставит себя долго ждать. Если ученик заинтересуется какой-то проблемой, пусть даже сложной, такой как JIT-компилятор, а учитель поможет ему разобраться в ней, то это уже полдела.

Я делаю акцент в первую очередь на том, чтобы «научить хорошему», не только отступам и пробелам, но и более сложным вещам. Я выделил «отступы и пробелы» как наиболее очевидные вещи, которые, тем не менее, часто упускают. Точно также есть «хорошее» и «плохое» в ООП, например, и я тоже буду стараться учить детей «хорошему», правильной иерархии классов, отделению интерфейса от реализации, принципам SOLID и т.п.

Возможно, что с первой группой сверхвыдающихся результатов не будет (хотя вполне достойные — будут обязательно), но мы же только начинаем наш проект.
В свободное время пытаюсь разрабатывать учебный язык программирования (подход похож на C#)

Прошу оценить понятность примеров исходного кода для детей ( подробнее примеры — pl2-rainbow.livejournal.com/3570.html, подход — habrahabr.ru/qa/39571/ )

В каком возрасте дети «потянут» такие простейшие примеры (наиболее способные и в среднем)?

Пустой файл

code source=pl2 name=example1
    namespace start \ начальное знакомство с языком программирования PL2 \
    {
    }
/code



Вывод Hello, world

code source=pl2 name=example2
    using user.OS.IO; // взаимодействие пользователя с компьютером средствами операционной системы
    using pl2.translator.system; // взаимодействие с транслятором

    namespace start \ начальное знакомство с языком программирования PL2 \
    {
        class Example2 \ класс для проверки работоспособности транслятора \
        {
            static void main \ программа для запуска средствами операционной системы \
               (String arguments \параметры командной строки выполняемого файла\ [])
            {
                String string_for_out \ строка для вывода \
                   := "Здравствуй, мир!";

                Console.write_line(string_for_out);
            }
        }
    }
/code



Hallo, world с наворотами

code source=text name=example_3_text
Пример выводимого текста:
Здравствуй, мир!
/code 
 
code source=pl2 name=example3
    using numbers;
    using user.OS.IO;
    namespace start
    {
        class Example3 \ третий пример начального уровня \
        {
            String example_text = source.example_3_text; // получаем строку исходников в переменную

            static void main \ основная функция исполнения третьего примера начального уровня \
               ( String aruments \ одномерный массив строк после имени исполняемого файла при запуске программы \
                           []
               )
            {
                numbers.Integer counter \ индексатор для перечисления параметров \;
                numbers.Integer parameters_count \ количество переданных параметров при вызове исполняемого файла \;
                parameters_count = arguments.lenght();
                Console.write_line(example_text);
                if (parameters_count > 0)
                    for (counter := 0 ; counter < parameters_count ; ++counter)
                        Console.write_line(arguments[counter]);
            }
        }
    }
/code



Hallo, world с наворотами на русском

код метод=text имя=текст_примера_4
Пример выводимого текста:
Здравствуй, мир!
/код 
 
код метод=pl2 имя=пример4
    использовать числа;
    использовать пользователь.ОС.ВВ;
    пространство начало
    {
        класс Пример4 \ четвертый пример начального уровня \
        {
            Строка текст_примера := исходный.текст_примера_4; // получаем строку исходников в переменную

            статичное пустое главное \ основная функция исполнения четвертого примера начального уровня \
               ( Строка аргументы \ одномерный массив строк после имени исполняемого файла при запуске программы \
                           []
               )
            {
                числа.Целое перечислитель \ индексатор для перечисления параметров \;
                числа.Целое количество_параметров \ количество переданных параметров при вызове исполняемого файла \;
                количество_параметров := аргументы.количество();
                Терминал.вывести_строку(текст_примера);
                если (количество_параметров > 0)
                    для (перечислитель := 0 ; перечислитель < количество_параметров ; ++ перечислитель )
                        Консоль.вывести_строку(аргументы[перечислитель]);
            }
        }
    }
/код


В перспективе предполагается выделение следующих областей видимости (по habrahabr.ru/post/176249/ )

functional — Функциональное — для разделов, использующих функциональное программирование.
aspect — Аспектное — для интерфесов и аспектов. Для методов могут указываться необходимые свойства и дополнения, используемые перед методом (before), после метода (after) и при выполнении каждого оператора (invariant)
predicate — Логическое — соответствует Булевым переменным, доказательству теорем, Аристотелевкой логике, работе с запросами SQL, LINQ или простейшим операциям Prolog.
controller — Управляющее — соответствует контроллеру (Controller) модели MVC
publish — Изменяемое — соответствует представлению (View) для модели MVC
public — Соединяющее — соответствует модели базы данных (Model) модели MVC
protected — Защищенное — внутренние элементы класса
private — Внутреннее — скрытые элементы класса
local — Блоковые — переменные методов и блоков
Так почему не использовать реальный язык? раз уж так все похоже.
Уже не похоже :-) Вчера додумал оператор цикла ( pl2-rainbow.livejournal.com/3833.html?view=14073#t14073 )

loop [explicit] [метка]
{
    for <[тип] переменная [ := инициализатор]>;
    in <контейнер>;
    while <условие, при котором цикл продолжает итерации>; 
    next <оператор итерации>;
    where <условие выполнения тела цикла>

    ...
    continue;
    break [метка блока];
}


Здесь:
loop — оператор начала цикла
explicit — цикл исполняется хотя бы один раз, проверка условия выхода из цикла перед первым проходом не выполняется
for — список переменных цикла и их инициализация
in — контейнер, из которого выбираются элементы при проходе по циклу
while — условие, при котором цикл продолжает итерации
next — команды, выполняемые после итерации
where — условие для выполнения тела цикла
continue — оператор досрочного перехода к следующей итерации
break — оператор досрочного выхода из текущего или указанного цикла
Излишне сложно и многословно. Я бы на таком языке писать не стал, тем более использовать его для обучения.
Попробую показать минимальный вариант

code source=pl2 name=example3
    using user.OS.IO;

    namespace start
    {
        class Example6
        {
            static void main( String aruments[])
            {
                Console.write_line("Hallo, world!");
                loop{
                    for argument;
                    in arguments;

                    Console.write_line(argument);
                }
            }
        }
    }
/code


Для переменной цикла подразумевается автоматическое определение типа. Как со сложностью данного примера?
Очень высокая

1. В чем смысл обрамления code /code? В файле может быть что-то кроме кода? Почему тогда не фигурными скобками, как везде?
code {
}
2. В чем смысл source и name?
3. using — ладно, пусть будет. Хотя иерархия настораживает.
4. namespace — для простых задач совершенно не нужен.
5. class — ага, у нас все классы. То есть чтобы обучать детей нужно сначала объяснить что такое класс?
6. статический метод. Так класс тут, оказывается не нужен — он просто контейнер статического метода. Что мешаешь отказаться от класса в данном случае вообще?
7. В чем смысл слова loop? Почему слова for и прочие считаются подчиненными относительно loop? Почему тело цикла отнесено на один уровень с for… in ...? Почему конструкция for… in… разбита на две строки, разделенные точкой с запятой, как будто это независимые конструкции? Почему после in стоит точка с запятой, как будто это независимая конструкция, относительно тела цикла?

Если профессиональному программисту это объяснить можно (хоть это и нелогично с моей точки зрения), то ученику — точно нет. Объяснения сведутся к «понимаешь, это магия».
1. В чем смысл обрамления code /code?
Предлагаю, что в этом же файле могут храниться другие ресурсы: комментарии, SQL, HTML, BNF для описания компилятора, многострочный текст и т.д. Каждый раздел может проверять отдельный анализатор. Импорт текста в строчную переменную программы продемонстрирован в примерах 3 и 4.
Раздел code не является частью синтаксиса PL2, а для того, чтобы не заморачиваться с тегами XML, HTML выбраны простые текстовые ключевые слова метаанализатора
2. В чем смысл source и name?
source задает режим проверки данного раздела.
name позволяет обратиться к блоку по внутреннему экземпляру файла времени компиляции source. Это напоминает метаслово __FILE__ C.
3. using — ладно, пусть будет. Хотя иерархия настораживает.
Необходимые ссылки можно передавать компилятору через настройки в командной строке.
по иерархии: думаю, что класс Console лучше хранить в пространствах пользователя, в отличии от пространства потоков OS.IO
4. namespace — для простых задач совершенно не нужен.
можно ввести ключевое слово program для простейших программ из одного класса
5. class — ага, у нас все классы. То есть чтобы обучать детей нужно сначала объяснить что такое класс?
Для использования Console.write_line что то объяснять придется
6. статический метод. Так класс тут, оказывается не нужен — он просто контейнер статического метода. Что мешаешь отказаться от класса в данном случае вообще?
да, при использовании program эту часть можно убрать.
7. В чем смысл слова loop?
это единственный оператор цикла
Почему слова for и прочие считаются подчиненными относительно loop?
для указания конкретных параметров цикла. Используются только те параметры, которые необходимы из вышеприведенного описания оператора цикла. Все параметры цикла описываются в его начале.
Почему тело цикла отнесено на один уровень с forin ...?
это не операторы, это объявления для цикла loop
Почему конструкция forin… разбита на две строки, разделенные точкой с запятой, как будто это независимые конструкции?
Они и независимы, за исключением того, что с ключевым словом in не может использоваться ключевое слово next. Конкретные разрешенные сочетания надо будет выделить в отдельные блоки описания языка

Почему после in стоит точка с запятой, как будто это независимая конструкция, относительно тела цикла?
А чего их все в одну строку пихать? А читать, на мой взгляд, будет легче.

Спасибо. Ключевое слово program придется задействовать :-)
:) у вас есть жесткий интерес к разработке языков, но причем тут бедные детишки?
скажу иначе. если ваша цель — сделать из первокласника — второкласника, то это одна задача. если ваша цель сделать из 10тиклассника 11классника — это другое. если из первоклассника за 10 лет 11ка — это тоже совсем другой вариант. ваш язык уже очень похож на то, что вы пытаетесь сделать из технического студента — академика. Т.е. одно дело — решать задачу по обучению ребенка и в рамках этой задачи разработать какой-то наипростейший минимальный подходящий для этого язык, а другое — выдумать sql#
После некоторых раздумий ключевое слово in заменено на ключевое слово from
Слишком многословно все. Если такие дети могут понять что такое static void и namespace то можно сразу и С# показывать.
Я бы наверно начал с питона. Hello world is just print 'Hello, world!'
Компилятор для write(«Hello, world») из одного оператора write с компилятором в .COM я уже писал.
Я считаю, что программа должна быть читаемой с возможностью наращивания сложности и модульным подходом.
А
echo "Hallo, world!"
или
 MsgBox "Hallo, world!"

дети написать и сейчас замечательно могут :-)
На первый взгляд — очень сложные конструкции. С какой целью разрабатывается этот учебный язык? Если не начинать обучение на нем (а в этом мало смысла — конструкции слишком громоздкие и излишне академические), то какой в нем смысл далее? Если дети освоили программирование на Си или Паскале, то смогут дальше перейти на другой язык при необходимости. Какое место должен будет занять ваш язык в системе обучения?

Пока у меня складывается ощущение что вы пытаетесь сделать язык «все в одном»: функциональное программирование, логическое, аспектное и т.д. ИМХО, это плохая идея, учебный язык должен быть простым и сосредоточенным на цели именно обучения, даже в ущерб строгости синтаксиса. Например, в Паскале наиболее часто используемые функции вынесены в модуль System, который неявно подключается к каждой программе. В Си такого нет, любой заголовочный файл нужно подключать явно.
С какой целью разрабатывается этот учебный язык?
Одно из положений — Компилятор языка использует стандартные ключевые слова на английском языке, но включает опцию расширения для каскадированного включения в таблицу лексем синонимов на национальных языках народов России. В результате, дети могут писать программы на своем естественном языке, а переводом занимается компилятор. При этом преподаватель может проверить листинг на любом из промежуточных языков (русский, английский) ( pl2-rainbow.livejournal.com/301.html).
Если не начинать обучение на нем (а в этом мало смысла — конструкции слишком громоздкие и излишне академические), то какой в нем смысл далее?
Попробую еще уменьшить размер примера сверху:

code source=pl2 name=example6
    program( String aruments[] )
    {
        Console.write_line("Hallo, world!");
        loop
        {
            for integer argument_number := 0;
            while argument_number < arguments.length()
            next ++argument_number;                   

            Console.write_line(arguments[argument_number]);
        }
    }
/code


Если дети освоили программирование на Си или Паскале, то смогут дальше перейти на другой язык при необходимости.
Да, императивные языки так изучили миллионы.
Какое место должен будет занять ваш язык в системе обучения?
Ознакомить с основными возможными способами программирования.
Пока у меня складывается ощущение что вы пытаетесь сделать язык «все в одном»: функциональное программирование, логическое, аспектное и т.д.
Да, именно на это я и целюсь (правда, медленно)
ИМХО, это плохая идея, учебный язык должен быть простым и сосредоточенным на цели именно обучения, даже в ущерб строгости синтаксиса.
На мой взгляд, это должен быть больше язык для чтения чужих программ. Но желательно, чтобы он плохо, но решал типичные примеры из каждого вида программирования.
У меня отец, научный сотрудник, большой опыт программирования, когда вышел на пенсию, устроился учителем информатики.

То, какой там поставлен курс, по его мнению, вообще в принципе нельзя научить детей программированию…
Он отошел от учебника и стал рассказывать по своему. Оценок он не ставил, так как пока оценивать было не чего…
К концу четверти дети стали что-то понимать… А вот, в конце года его уволили…
Если его выпуск чему-то научился, то задачу он выполнил на все сто!
не думаю, что на все 100
он просто их не успел ничему научить, но некоторых сумел научить немного думать…
Увы, система образования сопротивляется изменениям и это не здоровый консерватизм. Нам проще, а вот с внедрением подобной методики в школах будет куда больше бюрократии :(
видимо он в какой-то мере подставил школьников, да еще и непедагогично, опустив министерство образования в их глазах, им ведь когда-то экзамены сдавать — это же реальный мир. при таком альтруизме лучше было бы вести кружок или на продленке правильные знания передавать.
думаю, что те кто хоть что-то соображают, то сдадут все экзамены на отлично,
и не только выпускные, но и Вузовские.
а кому учеба не нужно — тот получит своё. Это было везде и всегда.
Я говорил про то, что есть формальная часть и она в реале занимает не поседнюю роль, поэтому нельзя на неё забивать.
Очень полезно посылать студентов учить школьников программированию. Не знаю, научат они их чему-нибудь или нет, но девушку себе найдут запросто ;)
дружище, это уже статья
Ну с 16-то уже можно! А это, как-никак, 10-11 классы!
это взаимовыручка, старшие должны помогать младшим. если распространить этот принцип вообще на всё, а не только на программирование — здесь был бы рай
Как бы парня себе не нашли :)
В одной руке девушка, в другой учебник «С++ для чайников» — ну что еще нужно что бы спокойно войти в зрелую жизнь?:)
Уже второй год занимаюсь обучением школьников программированию, набрался немного опыта. Да 8-9 класс самое оптимальное. Понял что чем проще тем лучше, когда отсекаешь все лишнее, оставшееся воспринимается лучше. Детали потом можно нарастить.
Начинал с html добавляя JS, чтобы не утонуть в сухом изучении конструкций языка, после каждого нового оператора придумывал интересную задачку. Например, изучили массив, работу со строками и генерацию случайного числа, делаем задачку — генератор предложений, а для продвинутых генератор ников, программа минимум, удовольствия максимум. Изучили условия и циклы — уже можно игру, классическую посадку на луну, текстовый вариант готов — воспользуемся средствами html и добавим графику, оживив текстовую посадку корабля движущимися картинками, листинг программы умещается в один экран, с комменатриями. Вся соль в примерах и упражнениях, можно дать все конструкции но что с ними делать дети знать не будут, только на интересных примерах хорошо все запоминается.
Почему html+JS? Не нужно ничего кроме браузера, результатами можно делиться сразу же в соцсетях, даже на телефонах и планшетах программы работают. (один из примерчиков цепная реакция)
Интересный подход, но освоят ли дети после этого классическое програмирование? Все-таки HTML + JS имеет свою специфику.
Основной принцип у меня — не навреди, и — получи результат сразу. В процессе даю все основные принципы классического программирования, последовательность выполнения программы, понятный код, основные конструкции, стараюсь дать понять что язык лишь средство реализации задачи. Забыл упомянуть, как решаю проблему черного ящика (как объяснить что такое & и т.п.) — Параллельно я делаю занятия на устройство компьютера, в качестве визуализации процессов используется майнкрафт, сейчас собрана модель сумматора с десятичным индикатором результатов, в плане — ячейки памяти для наглядной демонстрации процессов в компьютере.
Очень интересно. А можно узнать с чего начинаются ваши занятия, что дети узнают в первую очередь, как расставлены приоритеты?
Абстракциям посвящаю минимум, изучая теги сначала даю отвлеченный пример — описать любой объект с помощью тегов, например <голова><глаз1></глаз1><глаз2></глаз2></голова>… тут уже можно говорить о понятности кода. Иногда у детей получаются забавные существа, например, с глазом в глазе или руками из неожиданных частей тела, рисую, даю понять что они делают, схватывают сразу же. Дальнейший переход к реальным тегам уже прост.
Как только поймут как рисовать страничку и выводить статический текст, показываю как добавить программу, конечно тут своя специфика, но зато сознание пока не обременяется разного рода компиляторами, непонятными ошибками, отладчиками, хотя про консоль и отладку упоминаю. Для программ использую песочницу http://learn.javascript.ru/play. Что то написал — тут же получил результат.
Конечно же рассказываю о типах данных, и то что они учат язык очень лояльный к ошибкам, но программы работают, глазки загораются когда получается.
Еще раз — основной принцип — это простота, стараюсь отсечь все лишнее чтобы получить результат. Задача -> средство -> воплощение.
Интересный подход. Насколько я понимаю, принципы в значительной степени пересекаются с изложенными в статье. Надо будет обдумать ваш подход детальнее, возможно, что-то из него возьму себе.
Мне интересно мнение автора по двум вопросам. Akela_wolf, как вы считаете, полезно ли детям показать как примерно работает компьютер, т.е. потратить один урок и рассказать про двоичный транзистор, регистры, шины, память и т.п.? По опыту, по своему небольшому опыту я заметил, что массовые программисты-внедренцы 1С зашли настолько далеко от программирования, что не владеют понятием таблицы реляционной базы данных, т.е. люди, которые разрабатывают программы, в принципе не понимают как те исполняются — это отрыв программы от реального железа, наподобии шизофрении. По моему мнению такие разрывы в знаниях ведут к полной дезориентации, в головах складывается система знаний, не соответствующая действительности, основанная вполовину на магии, вполовину на импирическом опыте.

>>Школьные уроки сводятся, по сути, к изучению конструкций языка и выполнению каких-либо заданий на эти конструкции, но не учат намного более важному умению — применять их для решения возникающих на практике задач.

Второй вопрос совсем абстрактный. Как вы считаете, целесообразно ли программирование увязывать детям с реальной жизнью? Т.е. математика в школе преподается не столько прикладная, сколько сама математика (задачка: вася ехал на велосипеде 20 км/ч, а потом 40… ляляля… — какова средняя скорость?), а геометрия со всеми ее площадями и тригонометрией кажется абсолютно бесполезной. Тоже самое можно сказать о всех школьных науках, кроме химии->раздел «Порох» — это хоть какое-то развлечение. Возможно стоит сплетать хотябы информатику с практической реальностью?
Спасибо за интересные вопросы.

1. Вопрос сложный. С одной стороны — это подводит базу, с другой — тема очень большая, далеко не уверен что получится уложиться в один урок. Плюс не совсем понятно как это связать с дальнейшим. Вот рассказали вы про регистры, шину данных, память и прочее, переходите к написанию программ. Где оно все? Ну память еще ладно — переменные. А где регистры? Где шина данных? Думаю эти знания слишком абстрактны для школьников, лучше сосредоточиться на конкретных задачах.

2. Не совсем понимаю что значит «сплетать с практической реальностью». Вот мы на уроках делали игру — это сплетено с практической реальностью? Если речь о том, что дети должны видеть результат своих трудов — это само собой. Нужно стремиться выбирать задачи, которые им интересны, которые принесут положительные эмоции в процессе и результате решения.
По первому пункту: (где регистры?) — регистры там, где операции процессора — машинный код. машинный код там, где: while = for = if+goto. Еще регистры там, где у нас побитовые и логические операции. Еще в какой-то день каждый из учеников заметит, что в файле int хранится в обратном порядке и понеслась:), а также рекурсия, сжирающая всю память (поди объясни это явление без понятия стека). Уши 86го процессора торчат из всех мест.

По второму пункту. Можно представить, что химия связана с физикой непосредственно. Что все люди, которые что-то понимали и открывали в этих науках имели целостное понимание этих предметов. Вот я вчера у Краевича (учебник физики в 18хх году) прочитал, что невозможно сделать эталонный термометр, потому что у всех жидкостей коэффициент расширения меняется по-разному в зависимости от температуры. т.е. градуировка термометров для разных жидкостей не соответсвует и нет возможности определить идеальную равномерную жидкость, чтобы сделать из нее термометр, поэтому решили сделать газовый и от него попробывать отталкнуться. И весь учебник пропитан приборами, экспериментами и сплетен с практикой. Вот, например, двигатель внутреннего сгорания — это результат работы физиков или химиков?
И вот тут вы красиво написали:
>>Но программирование ведь нужно не только «избранным». На уроках программирования дети учатся в первую очередь работать с информацией, структурировать её, управлять ею, а эти навыки жизненно необходимы в условиях все нарастающего «информационного вала» современной жизни.
Я вам сейчас открою безценную тайну программистов: все они безупречные управленцы. У них 100% управленческий труд. Они оперируют командами и их мозг мгновенно оптимизирует управляющие процессы — это лучшие управленцы, они выкидывают ВСЁ лишнее и сразу видят идеальное решение. Причинно-следсвенные связи — это их среда обитания. Таким образом, на самом подсознательном уровне программист вылавливает противоречия, которыми кишит реальная жизнь. Ну, как-то так. Но, вообще, я думаю, если вы добавите в учебный практикум хотябы решение на компьютере задач по физике из учебника — это будет прорыв и склеивание во едино того, единого, что есть мир в целом.
С трудом себе представляю как знания устройства транзистора, шины и памяти могут помочь в работе какому-нибудь одинэснику
Чтобы это представить, предлагаю подумать на тему: 1с-ник отвечает на вопрос: «объяните мне, что такое регистр, измерения?» или «что такое план видов характеристик?», «контекст?», учитывая, что слово «таблица» в контексте sql субд он не понимает. У них там какое-то свое понимание этих вопросов, у каждого свое. Нормальную книжку они, если когда-то откроют — не поймут, они даже не узнают, что не понимают какую-то важно вещь. Это как пользователь MSExcel'я не будет знать, что его задачка экселем решается в пару кликов. Я ввязывался в 1с коротко и быстро и выяснил для себя, что во многих вопросах реализация великого замысла — ущербная, хотябы из-за тотальных ограничений регистров, документов и т.п. — то что на sql делается тривиально (соединения, фильтрация по любому полю), 1с-ники делают мегациклами и не знают, что это не дело — такими вещами заниматься.
А вы бы могли представить себе нормального человека, который считает, что пользоваться строками фиксированный длинны и резать пробелы справа в каждой строчке кода — что это так и должно быть в нормальном мире?
Ближе к железу. Мне помнится там есть тест производительности, типа вставляешь в программу метки, а потом можешь посмотреть насколько где программа тупит (сделано — пусть будет), но она же по времени меряет в многозадачной ОС — это же глупо, когда программируешь, наверняка надо понимать такие вещи, а как их поймешь не представляя что такое процессор и как вообще в принципе выполняется программа?

Я не говорю, что 1с-ник никак не справится с задачей из-за того, что не имеет представления об указателях, кэшах процессора и т.п. но зачастую квалификация его такова, что он скажет, что что-то там невозможно, на основании своего собственного представления о магии компьютера, нежели аргументирует (самому себе, хотябы) объективными причинами.

А откуда у них такая редкость в использовании массивов при программировании? или они мне по истечении нескольких лет уже мерещатся, а их в 1с вообще нет?

По существу на ваш коментарий я могу и прямо ответить. Зная устроство компьютера — а это сложная такая умная штука в которой есть чему поучиться — можно писать более разнообразные программы. т.е. знание сложного устройства добавляет в арсенал, как минимум, готовые шаблоны решения разнообразных задач, подобные которым решены в железе (очереди, арбитры, кэш-память — многое из этого приходится программировать попутно основной задаче, хорошо если сам догадаешься что так можно:), а так бы уже заранее знал). По настоящему научаешься программировать, когда уже представляешь как работает операционка и процессор — без этого на высоком уровне можно заниматься только веб-дизайном.

Но главный смысл моих посылов — чем глубже понимание, тем более адекватна работа (поведение, решения). А так, конечно, я принимаю от вас намек на абсолютную тупость 1с-ника-подмастерья/самоучки — ему знание железа не поможет, оно пока что к его голове не применимо. Я бы его в первую очередь отправил бы учить sql, а не архитектуру процессора.
>>Я ввязывался в 1с коротко и быстро и выяснил для себя, что во многих вопросах реализация великого замысла — ущербная, хотябы из-за тотальных ограничений регистров, документов и т.п. — то что на sql делается тривиально (соединения, фильтрация по любому полю), 1с-ники делают мегациклами и не знают, что это не дело — такими вещами заниматься.

Странно как-то вы изучали. В 1С соединение таблиц и фильтрация по любому полю делается также тривиально, как и в SQL + сдобрено плюшками значительно облегчающими работу — наличие виртуальных таблиц, доступ к данным через точку, конструктор запросов

>>Мне помнится там есть тест производительности, типа вставляешь в программу метки, а потом можешь посмотреть насколько где программа тупит (сделано — пусть будет), но она же по времени меряет в многозадачной ОС — это же глупо, когда программируешь, наверняка надо понимать такие вещи, а как их поймешь не представляя что такое процессор и как вообще в принципе выполняется программа?
Цель теста производительности не измерение скорости выполнения программы, а поиск узких мест, для оптимизации. Замер производительности показывает время и процент выполнения каждой операции. Больше в принципе ничего знать и не требуется.

>>Я не говорю, что 1с-ник никак не справится с задачей из-за того, что не имеет представления об указателях, кэшах процессора и т.п. но зачастую квалификация его такова, что он скажет, что что-то там невозможно, на основании своего собственного представления о магии компьютера, нежели аргументирует (самому себе, хотябы) объективными причинами.

Обычно наоборот бывает у неопытных одинэсников. Приходит к клиенту внедрять или дорабатывать программу. Клиент выдает список требований «хочу здесь кнопочку, хочу здесь кнопочку, хочу вот такой отчет, хочу все перекрасить в зеленый и чтобы сзади синий фон был». Специалист со всем соглашается — «и это могу и это могу и это сделаю и вообще могу копать, могу не копать, вы только попросите». Но при этом не совсем понимает специфику, что клиенту на самом деле не кнопочка нужна, клиент хочет решить какую-то проблему. Зачастую эту проблему можно решить штатными средствами, включив в настройках какую-нибудь опцию или с минимумом доработок. Или вообще бывает проблема из пальца высосана и стоит клиенту это объяснить. Вместо этого поверх существующего функционала пишется какой-нибудь четырехглавый неподдерживаемый монстр.

>>А откуда у них такая редкость в использовании массивов при программировании? или они мне по истечении нескольких лет уже мерещатся, а их в 1с вообще нет?
Вообще-то не редкость. Например, слово массив в ЗУП встречается ~12000 раз. И плюс зачастую есть более удобные типы данных. Таблицы значений, структуры, деревья значений, соответствия и т.д.

>>Но главный смысл моих посылов — чем глубже понимание, тем более адекватна работа (поведение, решения).
Не всегда. Человек не может хорошо знать сразу несколько предметных областей. Чем сильнее человек углубляется в знание железа, транзисторов, адресации памяти, ассемблера и др., тем хуже он будет знать предметную область (что при работе с 1С немаловажно) и собственно саму платформу. С тем, что знание SQL необходимо я согласен, без него сложно обходиться, но проблема не в отсутствии знании более низких слоев работы ПК, а в том, что наличие кадрового голода и как следствие относительно высокие зарплаты приводят к появлению в профессии большого количества случайных людей, которым это не интересно и которые далеки и от программирования и от учетных систем
Блин, не могу так четко выразиться, как это получается у великих писателей, надо или нам в приват уходить, или прекращать. Но я говорю не про 1с, я говорю о том, что очень часто конструктивные споры с разными разработчиками заваливаются из-за того, что у сбеседников нет нужных реальных образов и терминов. Это ведет спор в гуманитарное русло, более связанное не с пониманием, а с чувствами, т.е. мечтами, эмоциями и т.д. Представьте, включаете вы вай-фай в ноутбуке, а проводная сеть сразу отваливается — а почему так? А потому что маршрутизация. А попробуй объясни это человеку, который в контру 10 лет проиграл, а route не запускал ни разу. А вы знаете, что в 1с очень распространена проблема с ключами (лпт, юсб алладин), которых не видно? :) Запустил я снифер и посмотрел, выключил одну сетевуху на компе и увидел, что всё заработало — для того, чтобы понять хотябы капельку проблемы достаточно пару команд запустить. А без низко-уровневых знаний можно сколько угодно ходить и верить в глюкавость драйверов, я даже знаю случаи когда пиратские дрова ставят из-за того, что нормальные незаработали сами по себе:). Пример должно быть понятен.

Дальше не про педагогику, а про ее результат. Люди привыкли, к тому, что всё не так и считают это нормальным — побочный результат посещения школы.
То что вы похвалили 1с вначале — это дань восьмерке. В семерке всё было не так, при том что какой-то микрософт аксесс был на планете уже сотни лет. Однако разработчиков это не смущало. А еще вспомните, что внедрение восьмерки до самых последних времен откладывалось из-за того, что все они писали под семерку:) потому что для 8ки не было разнообразия базовых конфигураций. Это какой-то отдельный мир 1с со своим отдельным контингентом. Кстати вы меня засмущали временными таблицами, разве они есть в 1с-sql'е? ну да ладно, если есть — хорошо. А доступ к полям и методам через точечку отжирал у меня много нервов, потому что редактором подсказывалось меньше половины того, что можно было написать. Я великим замыслом назвал непосредственный доступ к данным из алгоритмического языка, но реализация фактически получилась одноногая.

По поводу графического интерфейса — вот уже точно — это такая вещь, понимание которой приходит с опытом работы в качестве пользователя (если педагоги здесь, обратите на это внимание). Стандартные типовые правила, заложенные в интерфейс полезны не всегда, доказать их вредность разговорами практически невозможно. Идеальный шаблон затмевает разум. У нас была задача создавать записи(строки) прямо в таблице с 10ю колонками. Так вместо того, чтобы сделать одно окно с этой таблицей, внедренцы предлагали 100 раз пощелкать в каких-то окошках-списках, потому что так положено. Их метод годен, когда надо создавать одну запись за пол часа, а если объем работы большой, то десятки тысяч раз в день выводить новые окна на экран — никуда не годится.

В основом я хотел намекнуть, что программист, не понимающий процессы, протекающие в компьютере — по сути не понимает, что программирует, т.е. он не понимает, что делает, из чего результат может оказаться всякий, примером тому такое изобилие красивеньких виснущих оболочек драйверов под мышку или звуковуху.
>А вы знаете, что в 1с очень распространена проблема с ключами (лпт, юсб алладин), которых не видно? :)
Ага, помню, лень разбираться было, сисадминам передавал, они проблему быстро решали. Сейчас 1С продает коробки без аппаратных ключей.

>А еще вспомните, что внедрение восьмерки до самых последних времен откладывалось из-за того, что все они писали под семерку:) потому что для 8ки не было разнообразия базовых конфигураций.
Не знаю, я с 1С работаю с 2010 года, к тому времени уже было достаточно различных конфигураций

>Кстати вы меня засмущали временными таблицами, разве они есть в 1с-sql'е?
Да, help1c.com/faq/view/903.html

>А доступ к полям и методам через точечку отжирал у меня много нервов, потому что редактором подсказывалось меньше половины того, что можно было написать.
Мы видимо совсем 1С занимались совсем в разное время и в разных версиях (из 7.7 только данные переносил в 8.1, 8.2). Я подобного не замечал. Если редактор понимает тип данных в переменной, то отображает все доступные поля и методы, как в коде, так и в конструкторе запросов.

>Так вместо того, чтобы сделать одно окно с этой таблицей, внедренцы предлагали 100 раз пощелкать в каких-то окошках-списках, потому что так положено.
Они видимо предлагали вместо текстовых полей использовать справочники и выбирать из них, вместо того, чтобы использовать текстовые типы данных? Тут от задачи зависит — если один раз создать таблицу, распечатать и забыть, то проще воспользоваться excel или ручкой с бумажкой. Если требуется вести учет чего-либо, то их подход имеет место быть, т.к. один человек напишет «Гвозди красные», другой «Красные гвозди» и попробуйте, разберитесь потом сколько гвоздей было продано. А ввод этот можно упростить, используя подбор или ввод по строке. Достаточно ввести «гвоз», 1С выдаст список номенклатуры, начинающейся с «гвоз», в 8.3 поиск осуществляется по всей строке, не только сначала.

>> В основом я хотел намекнуть, что программист, не понимающий процессы, протекающие в компьютере — по сути не понимает, что программирует, т.е. он не понимает, что делает, из чего результат может оказаться всякий, примером тому такое изобилие красивеньких виснущих оболочек драйверов под мышку или звуковуху.
По-моему просто произошло разделение труда, и узкие специалисты оказались востребованы. Вы там выше пример приводили про аппаратные лицензии. Я с этой проблемой сталкивался пару раз на первой работе, звонил сисадминам, потратили на решение проблемы ~час-полтора. Недавно откопали конфигурацию управление автотранспортом, ключи не работали, позвонил в техподдержку, выслали обновленную версию драйверов, установил, заработало. На всё ушло полчаса. Если бы не к кому было обратиться, то при помощи гугла и черной магии также решил бы проблему, пусть и затратив лишних несколько часов. А если бы пошел по пути изучения сетевых технологий и, глубоко закопавшись в работу триггеров транзисторов, то на это ушло бы явно не один день.
>>Они видимо предлагали вместо текстовых полей использовать справочники
Да, но не вместо, а сама реализация:
чтобы создать запись в таблице — окно
выбрать документ(а может и создать новый +окно) — окно
для заполнения первого поля, чтобы открыть первый справочни — окно

10го поля — окно
провести документ — окно

не надо забывать, что любое окно, когда открывается, в нем прокрутка опять в самом начале, т.е. ее крутит — это тоже муторно, попробуйте 10 раз подряд выбрать одну и туже профессию из справочника, когда между этим по 10 окон со справочниками выбираете.
Вбить 10 записей в таблицу — это не сложно, но когда для этого всякие окна выскакивают в общей сложности 100 раз — это интерфейс негодный.

>>закопавшись в работу триггеров
Так в том и смысл, чтобы иметь представление о том как работает компьютер еще со школы, чтобы техподдержка могла сказать «отключите антивирусы, фаерволы и посмотрите на какой сетевой адаптер уходят пакеты». Так вообще разговор на три минуты. Если человек целыми днями сидит за компьютером, то производительность его повысится если он будет знать что такое файл, расширение, процессор и т.п., а если человек программирует целыми днями, то производительность повысится тем, что он напишет алгоритм, в котором объем данных поместится в кэш процессора, привяжет его к конкретному ядру и т.п.
>>попробуйте 10 раз подряд выбрать одну и туже профессию из справочника
ctrl+c, ctrl+v

>>Так в том и смысл, чтобы иметь представление о том как работает компьютер еще со школы, чтобы техподдержка могла сказать «отключите антивирусы, фаерволы и посмотрите на какой сетевой адаптер уходят пакеты».

А многие ли будут работать в техподдержке и помогать пользователям с настройкой роутера? Выше я уже писал свои мысли по-поводу разделения труда и невозможности хорошо знать сразу несколько областей, пару слов еще добавлю.
Как думаете кто будет более востребован как одинэсник — человек, который знает сетевые протоколы, умеет программировать на ассемблере и хорошо разбирается в железе или человек, ничего этого не умеющий, но зато знающий бухгалтерский, налоговый учет, МСФО и другое добро?
Хороший вопрос. Плохо, что в нем нет третьего варианта, потому что третий вариант (обощающий) — самый главный:) Я ведь вообще не хотел сказать, что ассемблером надо владеть как русским. Весь смысл в том, чтобы иметь представление о том как на самом деле работает компьютер — элементарные образы и терминология. Т.к. работа компьютера — это управленческая деятельность, то термины и методы работы пригодятся в любом месте. Всегда и везде есть очереди, всегда есть что-то, что обслуживает — задержки и т.п. жизнь. Непосредственно по вопросу я сейчас думаю, что программист, немного разобравшийся в бухгалтерии будет наголову круче финансиста, слегка разобравшегося в программировании, потому что в этом случае на должность требуется именно программист. И потом это место такое, что программисту предметную область докладывает бухгалтер и просит че-то там сделать. А если бухгалтер будет пытаться что-то запрограммировать и ему будет помагать тоже бухгалтер, то потребуется еще программист все-равно.

Про 10 раз выбрать профессию вы не поняли. Между тем чтобы выбрать профессию и второй раз выбрать профессию, надо пройти 9 окошек — остальные поля для новой записи, где тоже надо выбирать что-то одинаковое на каждом цикле, например, подразделение (из дерева) и т.п. Т.е. в 1с принято каждый раз, чтобы что-то выбрать — открывать окно со справочником — это ужасно. Тогда когда все записи примерно одинаковые, заполнять их каждый раз заново таким образом — необосновано трудоемко.

Я посмотрел на временные таблицы и сразу вспомнил. Там этот бессмысленный менеджер временных таблиц, с которым зачем-то надо возиться. Это было одно из того чему я недоуменно удивлялся, т.к. MSSQL, на котором крутится 1с, имеет временные таблицы без лишних менеджеров, там просто пишешь select * into #ВременныеЗаказы from Заказы и больше ничего не надо — решеточка сама собой означает, что таблица — временная. И разработчики движка 1с несомненно знали, что можно так сделать, но сделали эти свои менеджеры. Меня тогда каждый день что-нибудь в 1с также удивляло и приводило в недоумение:) Самое крутое это было отсутсвие на Земле книги, где бы было нормально по-русски написано что такое Документ или что такое Регистр! (Для версии 8. Для 7 было — был мануал на известном сайте). Можно открыть любую книгу по си и там будет написано «массив — это ...», «указатель — это ....», но для 1с нельзя было открыть никакую такую книгу:)

Про техподдержку не очень понял, либо можно понять вопрос так: куда девать всех этих специалистов из техподдержки, если все сами себе станут роутеры настраивать?, либо: много ли требуется специалистов в нашем мире, чтобы помогать настраивать роутеры?.. Тут вообще момент в любом случае очень важный — сейчас очень скоро настанет время, когда роутер и компьютер будет почти в каждом доме, поэтому люди впринципе должны были бы быть, по-хорошему, подготовлены в достаточной мере, чтобы ими пользоваться, как они пользуются ложкой или вилкой, а они понятия не имеют об айпи-адресе.
>>Непосредственно по вопросу я сейчас думаю, что программист, немного разобравшийся в бухгалтерии будет наголову круче финансиста, слегка разобравшегося в программировании

Собственно для обоих сейчас место найдется. В 1С это не так заметно, т.к. почти любой специалист универсальный, а в SAP есть четкое разделение на консультантов и программистов, причем каждый из них чаще всего знаком только с определенной областью и специалист по зарплате может смутно себе представлять работу CRM. При этом стоимость работы консультантов выше, чем программистов.

>>Между тем чтобы выбрать профессию и второй раз выбрать профессию, надо пройти 9 окошек — остальные поля для новой записи, где тоже надо выбирать что-то одинаковое на каждом цикле, например, подразделение (из дерева) и т.п. Т.е. в 1с принято каждый раз, чтобы что-то выбрать — открывать окно со справочником — это ужасно.

Я что-то не пойму что там эти умельцы смастерили. Как по мне, так должна быть табличная часть в каком-нибудь документе, строки заполняются без открытия новых окошек для каждой строке. Если строки похожие их можно добавлять копированием. Вместо того, чтобы открывать каждый раз новые окошки для выбора из справочника можно использовать ввод по строке — в поле ввода набираем первые несколько букв из названия, программа подскажет возможные варианты выбора. Можно организовать подбор, например для добавления номенклатуры без закрытия окна.

>>Там этот бессмысленный менеджер временных таблиц, с которым зачем-то надо возиться.
Можно обойтись без него, если временные таблицы будут работать только в рамках одного запроса.

>>куда девать всех этих специалистов из техподдержки, если все сами себе станут роутеры настраивать?
Это фантастика. Роутеры сами себе люди будут настраивать только если в них останется только 2 кнопки — включить и выключить
Про консультантов красивый ответ, но он выскочил из контекста, эдак можно 1сником назвать и повара, который для столовой в учебном центре 1с пирожки лепит:) Я как-то все больше разработчиков нахваливал, которые сидят и «настраивают», а про тех, которые ходят и деньги вышибают, как-то не подумалось.

По роутерам, кстати мы уже свидетели этого времени: в Москве Стрим научился adsl-роутеру на кнопку reset вешать прошивку, которая высталяет все нужные настройки (кроме пароля, если я не путаю, что он там нужен), а ключи для wifi на бумажке напечатаны.

По поводу интерфейса я расписал все окна, которые нужно вызывать чтобы создать документ, запись в нем и выбрать окнами справочника каждое поле. Будто это так принято в 1С — справочники окнами открывать и надо так всегда делать. Ну заставить переделать у нас получилось, а доделать — нет — слишком много требовалось написать того, чего изначально не было, а они только переделывали все время по бесконечному циклу. С налета пришли, думали опять возьмут стандартную конфигурацию, что-то поднастроят и прокатит, как раз два три, но надо было сначала посчитать а потом садиться делать. Многие думают, что всегда возможно организовать работу так, чтобы поправить какие-то места, доделать каких-то форм, отчетов и будет достаточно. Почему-то даже никаких схем баз данных не рисуют.
Sign up to leave a comment.

Articles