Pull to refresh

Comments 27

Конечно, я понимаю, что если бы знала предмет изначально досконально и имела большой опыт программирования на C, то пособие писалось бы раза в два быстрее.


А какой опыт коммерческого (за деньги) программирования на C, если не секрет?
Зашел, чтобы задать тот же вопрос ;)

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

Чтобы практика действительно подняла пособие на новый уровень, ее должно быть много, она должна быть многолетней, в разных командах и для разных целей. Для объективности. Но это требует много времени и зависит от того, как часто человек менял сферу применения языка или чего-то еще. Если он напишет потом книгу, то она будет на вес золота. Таких книг наверное единицы, они всем известны и «живут» достаточно долго.

Остальные описывают либо свой опыт разработки, и тогда книги разных авторов на одну тему сильно могут различаться. Неподготовленный читатель составляет мнение о предмете на основе того, что ему подвернулось.
Второй вариант, как в моем случае, пишут примитив, базу, не зная всех специфических особенностей предмета изложения.
Может быть это плохо, но это реальность, которая приводит к куче литературы.
Прочитал с удовольствием — написано простым и ясным языком, без заумностей, что в книгах бывает редко. Также очень понравилась вёрстка текста.
Пособие ИМХО очень хорошее.

Отдельное спасибо за перевод страниц в трудодни. Я забросил свою писанину именно потому, что признал что я очень медленно пишу. А оказывается вполне нормально. Наверное соберусь с мыслями и сделаю вторую попытку.
Начинание хорошее, но нужно техническое ревью и редактура (в большом количестве). Пролистал несколько первых страниц.

> conio.h

Сейчас 2012 год, а вы рассказываете про conio.h?!

> Объявите в
> программе переменную max типа int и присвойте ей значение на единицу больше
> максимально допустимого.

signed overflow — undefined bahavior в Си. (Если не знаете что это такое — спросите).

> unsigned shot

shot

> Вот по-моему и все.
А как же char? (Да, об этом дальше, но вы же тут приводите список целочисленных типов и заканчиваете фразой «всё» — то есть список претендует быть исчерпывающим) А unsigned int это то же самое что unsigned или нет?

> При выводе длинных чисел
Длинные числа — это длинее двух цифр или как? (Исправьте на long)

> short j = 'b', k = 99;
> int arr[5], nums[N];
Человек впервые в жизни видит Си, а вы ему объявление с множественными деклараторами показываете (которые, кстати, запрещены многими кодстайлами, так что о них можно не рассказывать вообще, разве что в приложении «для тех что хочет знать больше»)

> Вещественные числа
> В языке C существует три типа чисел с плавающей точкой
Что такое точка и почему она плавает? Не хотите раскрывать подробности машинной арифметики — продолжайте называть их вещественными везде.

> Функция sizeof()
функция?! /0 facepalm

> mask = mask | (int)pow(2,N-i-1)
(int) pow(...) конечно, нам повезёт и всё округлится туда, куда нужно, да?

> В языке программирования C существуют так называемые статические переменные.
Вот так вот, одной фразой, смешали три разных понятия языка: object lifetime, object linkage, object scope.

Дальше не читал.
  int min, max;
  
  min = -2147483649; // минимально допустимое -2147483648
  max = 2147483648; // максимально допустимое 2147483647
  
  printf("%d \n", min); // 2147483647
  printf("%d \n", max); //-2147483648


При компиляции gcc выводится всего лишь предупреждение: overflow in implicit constant conversion
Тема «Компьютерная арифметика». Окружность. Доходим до максимально, потом сразу идет минимальное и т.д.

unsigned short и short — различаются. В первом случае, только положительные числа.

""" А unsigned int это то же самое что unsigned или нет?""" Это одно и тоже, но и писать unsigned int тоже можно.
> При компиляции gcc выводится всего лишь предупреждение

Почитайте что такое UB. Я серьёзно. (Компилятор совершенно не обязан о нём предупреждать.) Вы вообще читали стандарт? У вас есть хотя бы копия черновика стандарта?

> Доходим до максимально, потом сразу идет минимальное и т.д.

Эта отличная абстракция громко разбивается о процессры, использующие one's complement (а не two's complement), которые поддерживает стандарт Си, определяя signed overflow как UB.

> Это одно и тоже, но и писать unsigned int тоже можно.

Спасибо, я в курсе. А в тексте книги на это нет и мелейшего намёка.
Я писала учебник, а не справочник или пособие по разработке программ. Это другой «формат». Есть ограничения на объем информации. Во-вторых, есть как бы негласное правило методистов и педагогов, согласно которому излагать и делать акценты надо только на важных понятиях. Все остальное за борт, иначе понимание происходящего у обучаемых снижается.
Когда человек уже будет знать основы, он дочитает остальное из других источников.
Совершенно верно, формат другой, но это не повод делать ошибки или оставлять простанство для неточностей.

Поэтому я и предлагаю убрать объявление с множественными деклараторами, так как это не важно для начинающих, но очень запутывает. А вот говорить что можно переполнять знаковые числа — это, что называется, учить плохому, так как в стандарте явно написано что так делать нельзя (тот факт что у вас на gcc получился «нужный» эффект ничего не доказывает). И знаковые/беззнаковые целочисленные типы тоже стоит вводить параллельно, а не общим списком, так как между знаковыми/беззнаковыми типами существует соответствие. Так, например, unsigned это просто сокращение от unsigned int и поэтому нет смысла показывать эту возможность учащимся: просто ТИП знаковый, unsigned ТИП — беззнаковый.
""«А вот говорить что можно переполнять знаковые числа — это, что называется, учить плохому, так как в стандарте явно написано что так делать нельзя (тот факт что у вас на gcc получился «нужный» эффект ничего не доказывает)»""
Весомый аргумент, учту. В следующей редакции сделаю примечание о том, что в практическом программировании так не делают. При этом надо будет ввести представление о стандартах языков.
Однако вряд ли откажусь от наглядного примера компьютерной арифметики. Одно дело, что когда-то теоретически объясняли ученику, а тут вот оно — существует в реальности.
Я кстати ошибся.

min = -2147483649; // минимально допустимое -2147483648

Здесь литерал -2147483649 имеет тип long, а затем происходит implicit conversion в int.

А если написать так:

min = -2147483648 — 1;

(или, как бы я написал, min = INT_MIN — 1;)

То получим переполнение знаковых чисел, так как оба операнда имеют тип int.

В общем если хотите продемонстрировать особенности дополнительного кода портабельно и не заходя на скользкие участки, предлагаю проще: измен ите в это упражнении тип на short. Тогда оба варианта:
min = -32769;
min = -32768 — 1;
будут работать корректно, так как все литералы тут имеют тип int и переполнения не происходит (неявное преобразование в short происходит после арифметики).
> известное издание K&R, которое часто рекомендуют, не подходит для начинающих
Извините конечно, но если K&R не подходит для начинающих, то им и начинать не следует.
мне стало печальнее от того, что «С не подходит для первого знакомства с программированием», а ведь именно так у меня и было…
А вы не верьте. Знаю точно, что «Как программировать на C» от Дейтел и Дейтел подходит для начинающих, там ещё упражнения хорошие.
Подтверждаю. Для самостоятельно изучения, если есть достаточно свободного времени, лучше я не видела.
Я около пяти лет видела, как подростки осваивают программирование в малых группах. Если первый язык Python или Pascal, то обучение проходит легче.
Почему вы отказываете тем, кто не способен легко понимать программирование, в обучении ему? Разве это не тоже самое, что сказать: «Ты никогда не станешь спортсменом, не занимайся спортом».
Люди разные. Бывает, у человека проблема с логикой, но он вполе думающий и творческий (может придумывать что-то новое и интересное).
А те, у кого нет способностей никогда и не станут спортсменами настоящими… поверьте, я знаю о чем говорю, отец у меня тренер спортсменки, попавшей в этом году на Олимпиаду.

И если у человека проблема с логикой, то программистом ему становиться не стоит. Как хобби пусть себе на ардуинах собирает девайсы да на jass'aх пописывает интересные карты к играм, или greasemonkey-скрипты для любимого сайта. Но профессионалом без логики ему быть совершенно не нужно, я бы даже сказал вредно!
OpenOffice.org
Картинки-схемы были сделаны в Inkscape.

Мы тоже собираемся писать что-то вроде учебного пособия по подготовке к экзамену по информатике (примерно уровня ЕГЭ). И думаем что использовать. Пока что выбор склоняется в сторону TeX.
Я задавал подобный вопрос в комментариях к статье, на которую вы ссылались вначале, но мне никто не ответил.
Скажите, какими пособиями или учебниками сейчас пользуются авторы для формирования понятного стиля изложения? Наверняка, ведь, есть книги, в которых учат, как писать так, чтоб был максимальный процент просветлённых читателей?
Я спрашивал у выпускников педагогических факультетов, но они не могут посоветовать ни одной книги или статьи — наверное, они заняты подготовкой к работе в отрасли общепита.
""«Наверняка, ведь, есть книги, в которых учат, как писать так, чтоб был максимальный процент просветлённых читателей?»""
Сомневаюсь, не попадались. Возможно есть «рекомендации» по поводу длины предложений (они вроде как не должны быть в треть страницы с тремя друг другу подчиненными деепричастными оборотами), абзацев, стиля изложения.
В свое время в пед.вузе была услышана примерно такая аллегория: «Знания, которые вы излагаете, — это верхушка айсберга. То, что под водой, должно быть намного массивней. Тогда любой вопрос или проблема, ударивший по верхушке, не перевернут айсберг.»
Чем человек сам лучше разбирается в проблеме, тем понятней может объяснить другому. Выходов тут, на мой взгляд, два. Либо иметь большой опыт, либо прочитать, проанализировать и сравнить существующие источники.
Также скорее всего опыт написания играет большую роль. Например, у меня по качеству материал трехлетней давности хуже, чем теперь.
Возможно надо прочитать что-то из области психологии восприятия и анализа человеком информации.

Интересно, на какие темы выпускники педагогических ВУЗов защищают свои дипломные и докторские, если ни один из них до сих пор не рассмотрел такую важную тему?
Училась на естественно-географическом факультете пед.вуза. В нашей «биологической» группе был выбор защиты диплома по биологии, химии, педагогике/психологии/методике преподавания.
Часто преподаватели разделов биологии сами предлагали студентам темы дипломных уже на 3-м курсе, т.к. исследования обычно требовали полевых работ. Оставшиеся на педагогику/психологию начинали готовить дипломные на 5 курсе, некоторые за несколько месяцев до защиты. Уже не вспомню, какие у них были темы, но их практическая часть заключалась в хождение в школу и тестирование учеников, анкетирование. Одна девушка защищалась по методике преподавания. Кажется в качестве практической части там фигурировало создание наглядных пособий.

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

Articles