1. Alex G.K., 25.09.2008 14:51

Vlad7 Никто из консультантов проекта не несет ответственности за конкретные формулировки настоящего доклада Формулировка шикарная! Ежели перевести - "весь бред принадлежит лично членкору, а на нас не пеняйте"

2. mike_teplitsky, 25.09.2008 17:56

Vlad7 Обучение программированию с помощью Си эквивалентно развращению малолетних»? во первых, это не автор, а некто А.А.Берс на круглом столе в пылу дискуссии. во вторых, согласен что автор слишком уж эмоционален, но ведь проблема-то есть.

3. Lamn, 25.09.2008 18:18

цитата: Обучение программированию с помощью Си эквивалентно развращению малолетних Предлагаю использовать этого имбецила на урановых рудниках.

4. mike_teplitsky, 25.09.2008 19:40

Lamn Предлагаю использовать этого имбецила на урановых рудниках по сути это верно. C имеет опасную иллюзию простоты. учиться программировать все же лучше на других языках. C++ действительно слишком сложен. иногда неоправданно.

5. Murr, 25.09.2008 19:50

mike_teplitsky по сути это верно. C имеет опасную иллюзию простоты. учиться программировать все же лучше на других языках. Зависит от стадии обучения. С не только имеет иллюзию простоты, но и является достаточно простым для изучения, при наличии определенных знаний и навыков.

6. Yossarian, 25.09.2008 20:53

Гм. Господин Вирт продвигает свою теорию "С суть зло". Собственно, к этому сводится весь смысл доклада. Интересны тут два момента. Во-первых, Вирт, при всем моем к нему уважении, не видит реальных недостатков языка С, яростно сражаясь с вымышленными. Второй момент более важен. С, Паскаль, Модула2, Оберон - прекрасные для своего времени языки. Я помню, как изучал Паскаль после нескольких лет программирования на FORTRAN-66. Это казалось чудом, что вот так запросто можно работать с указателями, выделять память, итп. Но это все сейчас полностью и навсегда устарело. Навыки программирования на С, Паскале и ЛЮБОМ ДРУГОМ чисто процедурном языке являются вредными в современном мире. Такова жизнь. Я бы сказал так: обучение программированию на С или Паскале намного хуже развращения несовершеннолетних. От второго не все несовершеннолетние могут пострадать.

7. Vlad7, 25.09.2008 21:34

mike_teplitsky во первых, это не автор, а некто А.А.Берс на круглом столе в пылу дискуссии. http://www.inr.ac.ru/~info21/texts/2006-09-SFO/v2public.pdf Грамотным специалистам очевидно, что с точки зрения обучения программированию Си еще опаснее, чем Бейсик: «Обучение программированию с помощью Си эквивалентно развращению малолетних» - А.А Берс, ведущий научный сотрудник Института систем информатики им. Ершова СО РАН (высказывание сделано – и не встретило возражений - на круглом столе ведущих преподавателей информатики новосибирских университетов и школ во время визита Н.Вирта в ИСИ СО РАН 3 октября 2005г. ) «В пылу дискуссии» – зачем повторять это в своем докладе? Ведь четко и ясно сказано в начале доклада «В публичном варианте текста сделаны некоторые купюры. (Что же тогда было в том, что вырезали, если оставили столь резкие заявления?) Наверное, автору очень понравилось, Кстати, автор доклада сам тоже как будто не возражал. Похоже на собрание какой-то секты, где внушают присутствующим мысль, что «Обучение программированию с помощью Си эквивалентно» уголовному преступлению.

8. mike_teplitsky, 25.09.2008 21:57

Yossarian Навыки программирования на С, Паскале и ЛЮБОМ ДРУГОМ чисто процедурном языке являются вредными в современном мире. Такова жизнь не совсем так. в отличие от классического паскаля С позволяет в известной степени писать в объектно-ориентированном стиле. но для этого нужен опыт, понимание ООП и самодисциплина. Ничего этого у начинающих нет. так что на С луше всего приходить уже зная несколько парадигм программирования. но не начинать с него.

9. vsMsf, 25.09.2008 22:53

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

10. mike_teplitsky, 26.09.2008 00:35

vsMsf будущий профессиональный программер должен сам всему научиться есть еще не-проессиональне програмеры. типа сисадминов (ообенно на юниксе), инженеры-расчетчики, математики. во многих специальностях умение программировать "помаленьку" бывает полезно. ибо до некоторых рутинных задач у профи может и руки не дойдут. если рассматривать программирование с данной позиции, то однозначно сделать выбор в пользу одного языка будет сложно. для бухгалтера это будет VB+Exel, для инженера моет и древний турбо-паскаль сгодится.

11. Murr, 26.09.2008 01:30

Yossarian Но это все сейчас полностью и навсегда устарело. Навыки программирования на С, Паскале и ЛЮБОМ ДРУГОМ чисто процедурном языке являются вредными в современном мире. Такова жизнь. Таковы ваши представления о жизни - скорее так.

12. Yossarian, 26.09.2008 09:00

mike_teplitsky не совсем так. в отличие от классического паскаля С позволяет в известной степени писать в объектно-ориентированном стиле. Это как раз и называется "извращение". Кстати, а почему на Паскале так нельзя ? Странно. так что на С луше всего приходить уже зная несколько парадигм программирования. но не начинать с него. И это тоже. Если вообще есть какие-то причины его использовать.

13. fdn, 26.09.2008 12:35

Не, всётаки новичков надо учить на языке С. Язык С не прощает ошибок связанных с незнанием архитектуры ЭВМ. А без этого им очень трудно осваивать новые языки. Вобщем в итоге учить надо в комплексе ЯП + архитектура, и С для этого подходит намного лучше чем явно устаревший Паскаль, Модула или интерпретаторы типа Перл/Питон/Байэсик и т.п.

14. Murr, 26.09.2008 16:50

fdn Вобщем в итоге учить надо в комплексе ЯП + архитектура, и С для этого подходит намного лучше чем явно устаревший Паскаль, Модула или интерпретаторы типа Перл/Питон/Байэсик и т.п. Еще желательно на аппаратной платформе, где проявляются особенности, которые упускаются из вида на ia32. Например, запрет невыровненного доступа к памяти.

15. mike_teplitsky, 26.09.2008 18:07

fdn и С для этого подходит намного лучше чем но намного хуже чем ассемблер. не-профессионалам/школьникам детальное знание архитектуры уж точно никчему. драйвера для железа любители не пишут. Yossarian Это как раз и называется "извращение" почему. вполне нормально. просто сам язык тебе ничем не помогает. но и не мешает. делай что хочешь, хоть виртуальные функции. а вот в классическом паскале нет ни модульности, ни работы с указателями. все расширения Turbo Pascal они как раз из С

16. Murr, 26.09.2008 19:09

mike_teplitsky а вот в классическом паскале нет ни модульности, ни работы с указателями. все расширения Указатели есть.

17. mike_teplitsky, 26.09.2008 19:13

Murr Указатели есть работы с ними нет.

18. Murr, 26.09.2008 19:15

mike_teplitsky работы с ними нет. Поясните. Вы имеете в виду операции над указателями помимо разыменования?

19. iNdy, 26.09.2008 19:28

Murr В паскале (насколько я помню) указатель на int это совсем другой тип, чем указатель на char. Без извратов одно в другое не преобразовать (через пойнтер AFAIK). В С все проще и естественнее.

20. Murr, 26.09.2008 19:37

iNdy В паскале (насколько я помню) указатель на int это совсем другой тип, чем указатель на char. И в С другой. В С все проще и естественнее. Указатель на char нельзя приводить к указателю на int.

21. Dilmah, 26.09.2008 19:54

Murr > И в С другой. В С есть гарантии того что можно "экспандить структуру". цитата: A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning. Это значит что если есть struct A { ... }; и struct B { struct A a; ... }; то указатель на B можно кастать к указателю на A и увидим там валидный A. То есть это одинарное наследование и полиморфизм в чистом виде и в рамках стандарта.

22. mike_teplitsky, 26.09.2008 20:03

Murr Указатель на char нельзя приводить к указателю на int. void можно приводить. а в C++ - классы связанные наследованием. и что-то я не помню в паскале ни указателей на функции, ни арифметики с указателями. массивы в паскале не эквивалентны ссылке на выделенную область памяти.

23. Murr, 26.09.2008 20:07

Dilmah В С есть гарантии того что можно "экспандить структуру". Я писал несколько о другом. mike_teplitsky void можно приводить. Гарантированно только тот, который получен приведением этого же типа к указателю на void. Добавление от 26.09.2008 20:09: и что-то я не помню в паскале Это не значит, что там нет "работы с ними". Или реализация, скажем, операций над списком - это отдых с указателями? Добавление от 26.09.2008 20:11: В классическом Pascal много чего нет. Например, там case должен предусматривать все возможные варианты. Иначе поведение не определено.

24. mike_teplitsky, 26.09.2008 20:14

Murr скажем, операций над списком ну так это практически все что есть. Гарантированно только тот, который получен приведением этого же типа к указателю на void на практике - любой. в C++ еще круче

25. Yossarian, 26.09.2008 20:21

mike_teplitsky почему. вполне нормально. просто сам язык тебе ничем не помогает. но и не мешает. делай что хочешь, хоть виртуальные функции. а вот в классическом паскале нет ни модульности, ни работы с указателями. все расширения Turbo Pascal они как раз из С Если под "работой с указателями" понимать арифметику указателей, то это вот и есть то место в С, где аппаратная платформа совершенно не учитывается. Вернее, предполагается, что кроме DEC PDP-11 ничего в природе и не существует. Паскаль в этом смысле гибче. Кстати, интересно, почему при сравнении С с Паскалем все поголовно сравнивают современный С с Паскалем 197какого-то года ? Давайте уж сравнивать K&R C и Виртовский Паскаль, ANSI C и ISO Pascal. А то ерунда получается. В исошном паскале есть дженерики ("схемы"), которых нет в С, строки, которых нет в С итп. что-то я не помню в паскале ни указателей на функции Здрасьте... type f = function(i:integer):integer; массивы в паскале не эквивалентны ссылке на выделенную область памяти. Формально говоря, в С они тоже не эквивалентны. В стандарте это особо подчеркивается. Но в общем и целом это все равно все прошлый век. Вроде Фортрана-99. Даже холивар скучно устраивать.

26. Murr, 26.09.2008 20:29

Yossarian Но в общем и целом это все равно все прошлый век "Не гламур" - это, безусловно, самый сильный аргумент фанатиков каких-нибудь чистА кАнкретных кАнцепций и парадигмЪ.

28. Yossarian, 26.09.2008 20:58

Murr "Не гламур" - это, безусловно, самый сильный аргумент фанатиков каких-нибудь чистА кАнкретных кАнцепций и парадигмЪ. Вам не кажется, что Вы разговариваете сами с собой ?

29. Murr, 26.09.2008 20:59

Yossarian Вам не кажется, что Вы разговариваете сами с собой ? Нет, не кажется. А вот вы определенно увлеклись мантрами. Впрочем, существующий миропорядок ваши мантры изменить не смогут. Включая существующее использование языка С, даже если вы вдруг не в курсе, есть ли "какие-токакие-нибудь причины его использовать."

30. Yossarian, 26.09.2008 22:12

Murr Чем трепать клавиатуру попусту, не могли бы Вы сообщить народу, где именно, кроме микроконтроллеров, используется в настоящее время язык С. С, а не С++. (Программирование встроенных систем вряд ли надо изучать в школе, я думаю, мы тут согласимся)

31. Murr, 27.09.2008 00:50

Yossarian Чем трепать клавиатуру попусту, не могли бы Вы сообщить народу, где именно, кроме микроконтроллеров, используется в настоящее время язык С. То, что сходу пришло в голову: Windows NT kernel, Linux kernel, системные библиотеки (куча dll для winnt ;glibc), драйверы устройств, файловых систем, GNU compiler collection (aka gcc), PostgreSQL (СУБД), Qemu (виртуальная машина), Apache HTTP Server (один из наиболее распространенных веб-серверов), Samba Server (распространенный файл-сервер) Вообще, на С написано, развивается и вполне активно используется такое кол-во ПО, что достаточно бессмысленно пытаться его перечислить. Добавление от 27.09.2008 01:07: Наше ПО использовалось для создания (расчета персонажей) фильмов Batman: The Dark Knight, The Chronicles of Narnia: Prince Caspian, Tales of Despereaux. Есть и куда более серьезные приложения.

32. Yossarian, 27.09.2008 11:15

Murr драйверы устройств Устаревшие сведения. Есть некое мнение, что их надо писать на чистом С, но см. The NT Insider, Vol 14, Issue 2, March - April 2007 статья про использование С++ в kernel mode. Там и Boost, и smart pointers... ...an ever increasing number of programmers are willing to try C++ in kernel mode... C++ is really about clarity and concision. It's not just C with a tumor waiting for a merciful doctor to end its suffering. Реальной необходимости в этом нет (и никогда не было). Это просто мифология.

33. Murr, 27.09.2008 19:11

Yossarian Устаревшие сведения. Да неужели? ...an ever increasing number of programmers are willing to try C++ in kernel mode... статья про использование С++ Эти статьи и в 2001 году были (тогда же прочитал несколько), и раньше. Реальной необходимости в этом нет Правда? Если драйвер ФС начинает использовать всякий шлак для простейших вещей, то 10% нагрузка на cpu от 1000 нитей легко превращается в 100%. Плюс в том же Linux у нитей в ядре стек - невыгружаемый и всего 1-2 страницы, приходится быть аккуратным даже с введением дополнительных локальных переменных (в NT, насколько я могу судить по тексту о переполнении стека, найденному в OSR ntfsd, 3 страницы на нить). Любому системщику (в отличие от апологетов каких-либо яп) известен один простой тезис: код в ядре должен быть минимальным (а код hardirq - "абсолютно минимимальным"), основная обработка данных должна производиться в userspace (хоть на С++, хоть на Prolog, если есть желание). Хотя я не буду уподобляться вам и кричать, что С++ (судя по количеству упоминаний, апологетом которого вы являетесь) и ООП - прошлый век (к слову, разработка Smalltalk началась в 1969 году). Даже если и есть вообще альтернатива С в названной области, то называть использование С "устаревшими сведениями", мягко говоря, преждевременно.

34. Yossarian, 27.09.2008 20:33

Murr Я понимаю, что Вы довольно плохо разбираетесь во внутренней организации среды исполнения разных компиляторов (и языков). Программисты вообще редко задумываются над тем, как работают их инструменты. Поэтому вполне естественно употребление Вами бестолковых наименований вроде "шлак". Это оттого, что связно объяснить, что именно Вы имеете в виду, Вы по неграмотности не в состоянии. Отсюда же и необоснованное приписывание собеседнику мнений, которых он никогда не высказывал ("апологет С++"). Короче говоря, аргументы у Вас закончились и началось наклеивание ярлыков. Немного о коде ядра. Что такое "минимальный код" Вы, естественно, определить не соизволили. Современные процессоры работают на частотах 2-3 гигагерц. Время реакции системы (ни Линукс ни Винда не относятся к ОС реального времени) измеряется долями секунды. Объем резидентного модуля - десятки мегабайт. И при этом находятся люди, утверждающие, что нужно экономить на одном-двух (!) обращениях к памяти на вызов подпрограммы (именно такова разница между С и С++). Теряя при этом на общем качестве программы и увеличивая вероятность программистской ошибки. Разумеется, это смешно. И вот такие смешные люди пишут нам драйвера. Не случайно на проблемы с драйверами приходится большая часть всех неприятностей с ОС вообще. Также любопытно, что Вы указали _конкретные_ программы, написанные на С. именно _программы_, а не области деятельности или какие-то категории. Нет ничего удивительного, что какую-то прогу когда-то начали писать на С да так и продолжают. Но разумных причин начинать сегодня разработку чего-то на С нет. Нет и причин изучать С в школе. Сегодняшние школьники начнут работать через 10 лет. За это время доля С (и С++) в разработке еще уменьшится. С++ кстати тоже изучать в школах не нужно. В основном из-за его большой сложности и искусственности многих решений. Идеально было бы угадать тенденцию. Или сформировать ее. Когда-то Вирту, Дейкстре и прочим академикам удалось сделать концепцию структурного программирования общепринятой практикой. Чуть позже Страуструп, Буч и другие сделали то же самое с ООП. Может ли кто-то сегодня сказать, что будет востребовано завтра ?

35. Velund, 27.09.2008 21:31

Yossarian Навыки программирования на С, Паскале и ЛЮБОМ ДРУГОМ чисто процедурном языке являются вредными в современном мире. Такова жизнь. Расскажите это программистам, занимающимся встроенными системами....

36. Murr, 27.09.2008 22:50

Yossarian Я понимаю, что Вы довольно плохо разбираетесь во внутренней организации среды исполнения разных компиляторов (и языков). Программисты вообще редко задумываются над тем, как работают их инструменты. Поэтому вполне естественно употребление Вами бестолковых наименований вроде "шлак". Это оттого, что связно объяснить, что именно Вы имеете в виду, Вы по неграмотности не в состоянии. Отсюда же и необоснованное приписывание собеседнику мнений, которых он никогда не высказывал ("апологет С++"). Короче говоря, аргументы у Вас закончились и началось наклеивание ярлыков. Слишком много фантазий и эмоций, уважаемый. Немного о коде ядра. Что такое "минимальный код" Вы, естественно, определить не соизволили. А какой смысл вам что-либо объяснять, если вы ни ухом, ни рылом в вопросе? Даже про использование С++ умудрились сослаться на статью 2007 года. Что для вас, видимо, явилось откровением. Современные процессоры работают на частотах 2-3 гигагерц. Время реакции системы (ни Линукс ни Винда не относятся к ОС реального времени) измеряется долями секунды. Объем резидентного модуля - десятки мегабайт. Небо синее, море зеленое. И при этом находятся люди, утверждающие, что нужно экономить на одном-двух (!) обращениях к памяти на вызов подпрограммы (именно такова разница между С и С++). Я не знаю, кто эти люди, которые вам поведали про "одно-два обращения". Мое (и не только) мнение - код должен быть минималистичным. То, что используется С, само по себе еще не делает код хорошим. Но в любом случае С достаточно для создания минималистичного кода для этой конкретной области, в т.ч. при использовании полиморфизма. Теряя при этом на общем качестве программы и увеличивая вероятность программистской ошибки. Разумеется, это смешно. И вот такие смешные люди пишут нам драйвера. Не случайно на проблемы с драйверами приходится большая часть всех неприятностей с ОС вообще. Я лично не испытываю особых проблем с драйверами, хотя допускаю, что в винде ситуация иная. Причины вы, несмотря на подробное объяснение выше, указали неверно. Причины - как раз то, что в ядро временами лезут люди, которые абсолютно не представляют принципов и разумных подходов в нем. Их представления могут находиться на вашем, пещерном уровне - про гигагерцы, "времена реакции", современные подходы и "правильные языки программирования" - эти глубокие соображения являются для них руководством по универсальному программированию. Не удивительно, если модули в "десятки мегабайт" чисто статистически могут выдавать синие экраны. Добавление от 27.09.2008 22:56: Также любопытно, что Вы указали _конкретные_ программы, написанные на С. именно _программы_, а не области деятельности или какие-то категории. Наверное, если бы я сформулировал в более общем виде, то у вас бы возник дискомфорт от растекания мыслью по древу - поэтому я привел конкретные примеры. Попытайтесь немного обобщить написанное и у вас все получится. Возьмите первую строку и обнаружьте, что С использовался/используется при создании многих ОС (ядер и системных библиотек). Из того, над чем я работал в свое время,- Lynx (есть такая коммерческая RTOS). Oops, I did it again. Это опять был частный пример. Пусть будет "создание ОС общего и специального назначения". Добавление от 27.09.2008 23:00: Но разумных причин начинать сегодня разработку чего-то на С нет. Нет и причин изучать С в школе. Но разумных причин начинать сегодня разработку "чего-то" на С++/Delphi/C#/Java/Lisp/etc нет. Нет и причин изучать С++/Delphi/C#/Java/Lisp/etc в школе. Это все мантры. Добавление от 27.09.2008 23:12: Сегодняшние школьники начнут работать через 10 лет. За это время доля С (и С++) в разработке еще уменьшится. С++ кстати тоже изучать в школах не нужно. В основном из-за его большой сложности и искусственности многих решений. Вообще ничего изучать не нужно. Завтра же все может измениться... Идеально было бы угадать тенденцию. Или сформировать ее. Да-да. Стать отцом... А если отвлечься от рассуждений на тему эстетики и посмотреть на вопрос чисто практически, то я вам скажу так. С конца 90-х я успел подзабыть языки программирования, отличные от С, по причине полной невостребованности по жизни. В интересующих меня областях вполне достаточно знать С, и высокооплачиваемых вакансий со временем меньше не становится. Мантры о смерти С я слышал еще с 90-х... от программистов-эстетов, занимающихся программированием окошек, "бизнес-логики" или еще какой полной муры. Наше ПО, собранное неидеологичным gcc, работающее поверх неидеологичного Linux и неидеологичной glibc, работает на десятках машин из top100, не считая более мелких машин. Местами - в правительственных организациях США, где даже тематика вычислений является секретной. Вот это то, где сейчас используется С. Чем можете похвастать вы, Yossarian? Где используется созданное вами (при вашем участии) и идеологически правильно написанное ПО?

37. docfell, 28.09.2008 08:37

Паскаль, Си... Главное - 1С!!! Программеров, которые в нем худо-бедно могут кривой отчетик сваять - с руками отрывают.

38. Yossarian, 28.09.2008 10:01

Murr А если отвлечься от рассуждений на тему эстетики и посмотреть на вопрос чисто практически, то я вам скажу так. С конца 90-х я успел подзабыть языки программирования, отличные от С, по причине полной невостребованности по жизни. Мы тут обсуждаем (напомню) какой язык программирования нужно изучать в школах. Перенесем ситуацию на 30 лет назад. Вы тогда стали бы утверждать, что соль земли и единственный язык, какой Вы знаете - Фортран (С еще не было). И именно Фортран следует изучать. Я понимаю, что Ваше кредо - самоизолироваться и не видеть перемен в мире. Но учить детей исходя из этого явно не стоит. Чем можете похвастать вы, Yossarian? А у меня нет комплекса неполноценности, и, соответственно, желания хвастаться.

39. lks, 28.09.2008 16:29

Yossarian И именно Фортран следует изучать. Меня учили фортрану в свое время. Потом я освоил Си. Лет 15 пишу прикладные программы для железа. Язык Си - тяжелый для понимания и поверхностного изучения. Мое мнение - программированию не нужно учить всех подряд. Также не нужно всех учить рисовать кртины маслом, играть на скрипке, летать на вертолета и одномоторном самолете. Кому надо сами научатся... Я бы порекомендовал для изучения язык пакета МАТЛАБ. Очень простой, математически ориентированный и самое главное очень увлекательный процесс освоения самого этого пакета. По жизни легко потом перейти на другие языки. А если потребуется оптимизировать задачку в прикладном плане - дык, эти знания очень пригодятся. Там такие примерчики простые есть - например, моделирование работы сливного бачка унитаза - уже в 5 классе школы детям понятно будет. Там есть возможность работы на очень простом и примитивном уровне - а у кого есть талант может сразу перейти на более сложные вещи. А как там все, на уровне железа, происходит - 95% от общего числа программистов - всеравно не понимают. МАТЛАБ такой же как Фортран, но только с картинками.

40. Murr, 28.09.2008 17:13

lks Там такие примерчики простые есть - например, моделирование работы сливного бачка унитаза - уже в 5 классе школы детям понятно будет. А чем плохи "кенгуренок" и "пылесосик"?

41. lks, 28.09.2008 17:17

Murr А чем плохи "кенгуренок" и "пылесосик"? Может и они тоже не плохи. На меня произвела впечатления модель работы сливного бачка, в свете применения алгоритмов нечеткой логики. На самом деле все это очень просто! (Это я о нечеткой логике...)

42. DEADoomik, 28.09.2008 17:53

lks Язык Си - тяжелый для понимания и поверхностного изучения. Скажите, а что конкретно, по Вашему мнению, может вызвать затруднение при изучении языка Си?

43. Yossarian, 28.09.2008 21:16

lks Меня учили фортрану в свое время. Потом я освоил Си. Аналогично. Мое мнение - программированию не нужно учить всех подряд. Также не нужно всех учить рисовать кртины маслом, играть на скрипке, летать на вертолета и одномоторном самолете. Кому надо сами научатся... Да, конечно. Но это не значит, что тех, кто хочет летать на вертолете, учить не надо - сами научатся. Это явно неправильный подход. С программированием то же самое. И хотя программистов-самоучек намного больше, чем пилотов-самоучек, учить все равно надо. Я бы порекомендовал для изучения язык пакета МАТЛАБ. Интересная идея. DEADoomik Скажите, а что конкретно, по Вашему мнению, может вызвать затруднение при изучении языка Си? Можно, я отвечу. Главная проблема - ориентированность С на конкретную архитектуру процессора и среды исполнения. Для того, чтобы понимать С, нужно понимать, как работает процессор, что такое адрес памяти, что такое стек итп. Вопрос - какой процессор ? Проблема в том, что среды с параметрами, предполагавшимися при разработке С уже нигде не существует. Обратиться по произвольному адресу памяти не даст система защиты. Ввод-вывод на терминал не особо популярен. Сигналы не везде есть. То есть мы должны долго объяснять ученику, как работает НЕ ТОТ процессор, плюс ещё объяснять сам язык. Первое знание является вспомогательным, но бесполезным. ( В принципе в преподавании часто так делают - дают неверную модель. Но это обычно упрощенная модель, например, что Земля имеет форму шара. А здесь модель не упрощенная, а скорее устаревшая. Это примерно как некоторые пособия по фотографии начинают с устройства фотоаппарата такого типа, который можно найти только в музее. )

44. Murr, 28.09.2008 22:53

Yossarian Главная проблема - ориентированность С на конкретную архитектуру процессора и среды исполнения. На чисто конкретную? На легендарную и очень сильно устаревшую машину фон Неймана? Но вот беда. Упомянутый (хоть и с оговоркой о сложности для изучения школьниками) пару раз С++, практически полностью поддерживая синтаксис-семантику С, получается, обладает тем же набором заболеваний. Обратиться по произвольному адресу памяти не даст система защиты. Даже если определенная платформа дает/давала возможность обращаться по произвольному адресу, то какова может/могла быть семантика (с точки зрения языка) обращения к адресам, которые не заняты тем, что современные стандарты С называют object? То есть мы должны долго объяснять ученику, как работает НЕ ТОТ процессор, плюс ещё объяснять сам язык. Если ученик будет следовать существующему стандарту С, то с описанной особенностью работы vm он не столкнется. А "терминальный" ввод-вывод, кстати, как раз отлично подходит для изучения программирования (будучи предельно простым, хотя форматный вывод в C и несколько сложнее ввода-вывода в Pascal, он позволяет не отвлекаться на второстепенные вещи). Добавление от 28.09.2008 22:58: Проблема - в том, что вы рассматриваете С исключительно как инструмент (это ваше слово) для решения определенных прикладных задач (чем он, безусловно, является) и не рассматриваете его как язык программирования общего назначения (без ms, gnu и еще каких-либо расширений). Не загружая школьнику голову инкапсуляцией-полиморфизмом-наследованием и прочей мутью, на С можно и довольно просто "пощупать" на практике основы алгоритмов и структур данных (не буду, впрочем, спорить, что на Pascal/Modula-2 это можно сделать с тем же успехом).

45. Yossarian, 29.09.2008 09:30

Murr Ага. Вот мы (к счастью) отвлеклись от мерянья Top100 и перешли к конструктиву. Упомянутый (хоть и с оговоркой о сложности для изучения школьниками) пару раз С++, практически полностью поддерживая синтаксис-семантику С, получается, обладает тем же набором заболеваний. Совершенно справедливо замечено. какова может/могла быть семантика (с точки зрения языка) обращения к адресам, которые не заняты Для программистов PDP-11 этот вопрос не возникал. Ввод-вывод, конечно. Поинтересуйтесь на досуге особенностями работы шины этого замечательного устройства, и Вам сразу станет ясно, почему в С действительно необходимо было сделать обращение по произвольному адресу памяти. А "терминальный" ввод-вывод, кстати, как раз отлично подходит для изучения программирования Увы. Ученик, освоившийся с терминальным вв=выв, пробует написать что-то под Win32 или X и тут же понимает, что его учили чему-то не тому. Далее они делятся на две группы. Первые забывают то, чему их учили и переучиваются заново. Вторые полагают, что окошки и сообщения это, как Вы выразились, "муть", и оставшуюся жизнь проводят в рамках той модели, которой их научили. И то и другое вряд ли стоит считать достигнутой целью обучения. Не загружая школьнику голову инкапсуляцией-полиморфизмом-наследованием и прочей мутью Гм. Может быть, Вы просто недостаточно хорошо во всем этом разбираетесь ? ООП это не больно и не страшно, зато от него много пользы. "пощупать" на практике основы алгоритмов и структур данных Вот это еще одна важная вещь. Я когда-то старательно изучал Кнута, Вирта и другие книги по алгоритмам. Я знаю, чем отличается heapsort от quicksort, что такое алгоритм Боуера-Мура и алгоритм Кули-Тьюки. И мне ни разу в жизни это не пригодилось. Ни разу. Если в С вызывая функцию qsort я еще как-то могу сказать, что именно она делает, то в Perl я пишу sort, полагаясь на совесть разработчиков. Которые, кстати, тоже сортировку не сами писали. В SQL, добавляя ORDER BY, я уже точно знаю, что там не heapsort, не quicksort, а что-то еще. А из школьного курса как бы следует, что поиск и сортировка это прямо-таки краеугольные камни программирования. Отсюда вопрос : а надо ли этому учить ?

46. lks, 29.09.2008 10:22

DEADoomik Скажите, а что конкретно, по Вашему мнению, может вызвать затруднение при изучении языка Си? Для нормальной работы на Си - вначале нужно бы изучить ассемблер - без этого сложновато будет. Т.е. Си - это для тех кто лехко пищет на ассемблере, но им уже "влом" много писать букв - вот тут Си незаменим... Вообще Си это аппаратно ориентированный язык - это основная проблема. Вы когда в последний раз видели учителку по информатике? Вы думаете, она сама в состоянии будет освоить Си? Школьники имеют подготовку математическую неплохую, логично бы им предлагать математически ориентированны языки. Фортран неплох для этих целей - но он уже устарел и для него нет качественных графических оболочек, нет литературы современной и т.д. МАТЛАБ - это модно, современно и имеет (в перспективе) прикладное значение. Хотя конечно алгоритмы (простейшие) везде одинаковы. Можно смело тащить все базовые алгоритмы из фортрана - в Матлаб, и "не париться"... ИМХО нужно учить не языкам программирования - а принципам построения алгоритмов. А на каком языке - это уже дело вкуса.

47. Murr, 29.09.2008 17:22

Yossarian: Для программистов PDP-11 этот вопрос не возникал. Ввод-вывод, конечно. Поинтересуйтесь на досуге особенностями работы шины этого замечательного устройства, и Вам сразу станет ясно, почему в С действительно необходимо было сделать обращение по произвольному адресу памяти. Вы старательно мешаете теплое и мягкое, хотя нет никакого резона это делать. Давайте все же разделять системное программирование и программирование на языке С. Ваш ответ лежит в области системного программирования, а не языка С. С точки зрения языка С, как сегодня, так и задолго до этой великой даты, обращение по произвольному адресу не несло большого смысла. printf/scanf, буде они упомянуты, появились далеко не вчера для "терминального ввода-вывода". Что же касается ввода-вывода в общем случае, то он лежит сугубо в области системного программирования. Вы поставили в минус С то, что он дескать имеет привязку к аппаратной платформе. И, допустим, описанная проблема с PDP-11 действительно имела место, но не из K&R C, не из стандарта C99 нельзя получить никакого представления о проблемах PDP-11 и особенностях ввода-вывода на этой платформе, чтобы потом пришлось переучиваться. Так какая все же взаимосвязь между особенностями организации PDP-11 и языка С? Добавление от 29.09.2008 17:32: Yossarian: Увы. Ученик, освоившийся с терминальным вв=выв, пробует написать что-то под Win32 или X и тут же понимает, что его учили чему-то не тому. Далее они делятся на две группы. Первые забывают то, чему их учили и переучиваются заново. Главный фетиш терминального ввода-вывода - в том, что его не нужно учить. Если человек испытывает сложности с тем, чтобы с первого раза запомнить базовый синтаксис-семантику printf/scanf или read/write/readln/writeln, то ему лучше на этом закончить свое ознакомление с миром программирования. С не предоставляет средства для рисования окошек, проигрывания музыки и прочего. Но вспоминается тот факт, что когда я начинал изучать Java, то в ней использовался пакет awt, а уже через пару лет стандартом стал swing. Все со временем меняется, увы. Вторые полагают, что окошки и сообщения это, как Вы выразились, "муть", и оставшуюся жизнь проводят в рамках той модели, которой их научили. И то и другое вряд ли стоит считать достигнутой целью обучения. Изучение окошек может быть полезным, но в отличие от базовых навыков программирования оно понадобится далеко не всем. Даже в окошечных приложениях, если в них есть что-либо помимо окошек, есть целый пласт, где окошки не фигурируют. Добавление от 29.09.2008 17:51: Yossarian: Гм. Может быть, Вы просто недостаточно хорошо во всем этом разбираетесь ? ООП это не больно и не страшно, зато от него много пользы. От знаний всегда есть польза, но невозможно знать всё. Надо расставлять приоритеты, отделить плоды от шелухи, тыкскать. Ни в одном вменяемом вузе в основах программирования не рассказывают про ООП. Есть множество парадигм, ООП - лишь одна из многих. [i]Вот это еще одна важная вещь. Я когда-то старательно изучал Кнута, Вирта и другие книги по алгоритмам. Я знаю, чем отличается heapsort от quicksort, что такое алгоритм Боуера-Мура и алгоритм Кули-Тьюки. И мне ни разу в жизни это не пригодилось. Ни разу. Если в С вызывая функцию qsort я еще как-то могу сказать, что именно она делает, то в Perl я пишу sort, полагаясь на совесть разработчиков. Которые, кстати, тоже сортировку не сами писали. В SQL, добавляя ORDER BY, я уже точно знаю, что там не heapsort, не quicksort, а что-то еще. А из школьного курса как бы следует, что поиск и сортировка это прямо-таки краеугольные камни программирования. Отсюда вопрос : а надо ли этому учить ?[/q] Сортировка - не краеугольный вопрос алгоритмов. Но вот что на практике мне лично встречается часто - это выбор эффективного представления данных в памяти, структурирования на диске, оптимизирование сетевых протоколов. Можно, конечно, сказать, что сейчас 21 век, для хранения всех данных использовать СУБД общего назначения, для сетевого взаимодействия без оглядки на нагрузку использовать RPC... но как это будет работать? Сейчас множество крупных контор заинтересовано в том, чтобы это все не просто работало, а работало быстро, и при этом они за это готовы платить большие деньги. Потом, все равно кто-нибудь должен создавать те же СУБД, генераторы оберток для rpc. Это все не очень сложно, при этом интересно, ну а что не везде востребовано - ну так нет ничего такого, что было бы везде востребовано.

48. Nosorog, 29.09.2008 19:21

Господа, поясните. Так что, существует готовая среда для разработки приложений на "правильном" языке, которую можно скачать и попробовать? Я вот хочу написать программу, которая должна обладать следующими свойствами: 1. Взаимодействовать с внешним прибором через СОМ-порт (ввод и вывод); 2. Рисовать графики, вид которых будет управляться пользователем с помощью кнопок, скроллбаров и т.д.; 3. Работать под Win2000, WinXP и последующими версиями Win, причем разной локализации. Интерфейс будет английским; 4. Иметь привычный установщик, который создаст папку в Program Files и в меню "Старт"; 5. Быть компактной, то есть не тащить с собой десятки мегабайт рантаймов. Получу ли я все это, если использую софт с сайта проекта, обсуждаетого в статье? Заодно бы поучился правильно программировать, а то ведь самоучка на бейсике/фортране/VBA Не получится ли так, что это все красивая абстракция, имеющая слабое отношение к практике?

49. Yossarian, 29.09.2008 21:59

Murr Давайте все же разделять системное программирование и программирование на языке С. Увы, это не удастся сделать. Язык С разрабатывался как язык системного программирования, и ничего с этим поделать нельзя. Это первый "серьезный" язык, в котором есть возможность без существенных извращений обратиться по любому адресу памяти в строго определенной архитектуре. В x86 или IBM370 этот номер не пройдет - есть защита. В AVR адресных пространств 5 штук разных. В Паскале проблем не возникает ни с тем, ни с этим - проверка типов не даст произвольно смешивать разные адреса. Кстати, всякие += -= *= появились тоже в С. И по точно такой же причине - в PDP-11 есть забавная фича read-after-write. Другое дело, что эти операции прижились, оказались удобными. Но вводили их по вполне конкретной причине. Дело не в том, можно ли аппаратную платформу "реконструировать" по языку - отчасти можно. Проблема в том, что без знания этой платформы часть возможностей языка выглядит как чистое шаманство. Язык позволяет, а делать это нельзя. Почему нельзя ? А вот.... далее следует лекция об особенностях архитектуры x86 и используемой ОС. Ни в одном вменяемом вузе в основах программирования не рассказывают про ООП. ВМК - невменяемый вуз ? Любопытно. Я скажу ребятам, они, похоже, не в курсе. Про ООП надо рассказывать обязательно. ООП это основа основ современного проектирования. И тоже уже устаревает. Ничего не поделаешь, все развивается довольно быстро. Гибкие диски и модемы уходят в прошлое. Кстати, перечислите альтернативные ООП парадигмы программирования, хоть немного приближающиеся к ООП по масштабам использования. но как это будет работать? Сейчас множество крупных контор заинтересовано в том, чтобы это все не просто работало, а работало быстро, и при этом они за это готовы платить большие деньги. Я еще раз напомню, мы говорим об обучении школьников. До больших денег там еще далеко. Их надо научить чему-то, причем так, чтобы они а) не зациклились на изученном и б) не бросили это дело из-за излишней сложности или излишней простоты. Но вспоминается тот факт, что когда я начинал изучать Java, то в ней использовался пакет awt, а уже через пару лет стандартом стал swing. Я думаю, Вы в курсе, почему так. С не предоставляет средства для рисования окошек, проигрывания музыки и прочего. Вот и плохо. Когда сходу можно получить интересный результат вроде проигрывания музыки или еще какого эффекта, ученикам становится интересно. А когда для воспроизведения звукового файла нужно написать полстраницы заклинаний - это скучно.

50. Vlad Tepes, 29.09.2008 22:39

Yossarian Увы. Ученик, освоившийся с терминальным вв=выв, пробует написать что-то под Win32 или X и тут же понимает, что его учили чему-то не тому. Далее они делятся на две группы. Первые забывают то, чему их учили и переучиваются заново. Вторые полагают, что окошки и сообщения это, как Вы выразились, "муть", и оставшуюся жизнь проводят в рамках той модели, которой их научили. А вариант параллельного обучения этим вещам вы не рассматриваете? На одном занятии студент занимается изучением алгоритмических аспектов программирования, а на другом - современных прикладных технологий программирования. Вот это еще одна важная вещь. Я когда-то старательно изучал Кнута, Вирта и другие книги по алгоритмам. Я знаю, чем отличается heapsort от quicksort, что такое алгоритм Боуера-Мура и алгоритм Кули-Тьюки. И мне ни разу в жизни это не пригодилось. Ни разу. Я согласен, что большая часть, например, Кнута представляет чисто академический интерес, но с другой стороны, представления о фундаментальных концепциях у студента должны сформироваться. И понятия деревьев, стеков и очередей пригодиться все-таки могут... Так же как и представление о нормальных формах для пользователей SQL. Как мне кажется, более или менее достаточный для студентов объем знаний по алгоритмам приведен в книге Кормена, Лейзерсона, Ривеста "Алгоритмы, построение и анализ". ООП это не больно и не страшно, зато от него много пользы. Полностью согласен. Вот только ответьте на один вопрос - нужно ли сначала ознакомить студента с парадигмой структурного программирования, или же сразу начинать с объектно-ориентированной? Я еще раз напомню, мы говорим об обучении школьников. До больших денег там еще далеко. Их надо научить чему-то, причем так, чтобы они а) не зациклились на изученном и б) не бросили это дело из-за излишней сложности или излишней простоты. Обучение школьников - это особая, еще более сложная проблема... с одной стороны из-за недостаточной для серьезного изучения фундаментальных алгоритмов математической подготовки, с другой из-за особенностей детской психологии, таких, как "Когда сходу можно получить интересный результат вроде проигрывания музыки или еще какого эффекта, ученикам становится интересно. А когда для воспроизведения звукового файла нужно написать полстраницы заклинаний - это скучно." Проблема в том, что для получения такого "результата" не требуется вникать в фундаментальные принципы (ну не будете же вы школьникам объяснять в требуемом объеме принципы оцифровки звуковых сигналов), т.е. эффект от такого обучения в итоге будет почти нулевым. Кроме того все-таки желательно в процессе обучения, особенно на начальном этапе, максимально абстрагироваться от конкретных решений привязанных к платформе отдельно взятого производителя. А вот интересно, как бы Вы предложили построить учебный курс по программированию для школьников (имеется в виду перечень и очередность изложения нужных на Ваш взгляд тем).

51. Yossarian, 30.09.2008 09:18

Vlad Tepes А вариант параллельного обучения этим вещам вы не рассматриваете? На одном занятии студент занимается изучением алгоритмических аспектов программирования, а на другом - современных прикладных технологий программирования. Я не считаю событийно-управляемое программирование чем-то новым и современным. Оно появилось примерно одновременно с терминальным вводом-выводом. Проблема в том, что как правильно выразился Murr, главный фетиш терминального ввода-вывода - в том, что его не нужно учить. Ученик мгновенно с ним осваивается и далее считает, что все ясно. А это всего лишь частный случай. но с другой стороны, представления о фундаментальных концепциях у студента должны сформироваться. И понятия деревьев, стеков и очередей пригодиться все-таки могут... Да, конечно. Но найти нужную пропорцию - непростая задача. нужно ли сначала ознакомить студента с парадигмой структурного программирования, или же сразу начинать с объектно-ориентированной? Интересный вопрос. Я бы начал с ООП. Исходя из неких общих принципов усваивания материала. Хотя есть вариант вообще начинать с логического или функционального программирования. ну не будете же вы школьникам объяснять в требуемом объеме принципы оцифровки звуковых сигналов А почему бы и нет ? Теорема отсчетов интуитивно понятна. Нарисовать картинку, показывающую как происходит оцифровка и восстановление сигнала несложно. Да и не надо ничего рисовать, открыть звуковой редактор и показать. Кроме того все-таки желательно в процессе обучения, особенно на начальном этапе, максимально абстрагироваться от конкретных решений привязанных к платформе отдельно взятого производителя. Это верно. И это еще один сильный аргумент в пользу функциональных, марковских и скриптовых языков. А вот интересно, как бы Вы предложили построить учебный курс по программированию для школьников (имеется в виду перечень и очередность изложения нужных на Ваш взгляд тем). Я боюсь, что мой опыт преподавания недостаточен для того, чтобы вот так сразу написать темы целого курса. Но по темам примерно так: Теория множеств, дискретная алгебра. Тут же где-то двоичная система и коды. Функции, вычисления. Вычисления на калькуляторе. Формулировка задачи, логическое программирование. Функциональное программирование. Алгоритмы. Объекты и свойства. Структуры данных. Параллельные вычисления. Синхронизация. Сетевые взаимодействия. Распределенные вычисления. Основные операторы (if, while, =). Методы объектов. Базы данных, SQL, реляционная алгебра. Объектное проектирование. Насчет последовательности я не уверен. Из языков я бы взял что-то вроде Ruby (PHP,Python,lua) и что-то вроде Erlang (Refal, Clean, Caml). Но где-то в этой системе надо постоянно давать возможность что-то создавать самим. Может быть, какая-то игрушка со встроенным скриптовым языком. Или рисовать фракталы на функциональном языке. Кстати о звуках: звуковой редактор Audacity имеет встроенный функциональный язык.

52. lks, 30.09.2008 09:24

Nosorog Я вот хочу написать программу, которая должна обладать следующими свойствами: 1. Взаимодействовать с внешним прибором через СОМ-порт (ввод и вывод); 2. Рисовать графики, вид которых будет управляться пользователем с помощью кнопок, скроллбаров и т.д.; 3. Работать под Win2000, WinXP и последующими версиями Win, причем разной локализации. Интерфейс будет английским; 4. Иметь привычный установщик, который создаст папку в Program Files и в меню "Старт"; 5. Быть компактной, то есть не тащить с собой десятки мегабайт рантаймов. МАТЛАБ в принципе должен удовлетворять. Хотя я сам не пользовался СОМ портом - но интерфейсы там различные присутствуют - есть даже возможность подключать специальные платы АЦП, ЦАП и прочее. Различные лабораторные макеты тоже должны быть в природе.

53. Murr, 30.09.2008 13:25

Yossarian ВМК - невменяемый вуз ? Любопытно. Я скажу ребятам, они, похоже, не в курсе. Про ООП надо рассказывать обязательно. ООП это основа основ современного проектирования. И тоже уже устаревает. Ничего не поделаешь, все развивается довольно быстро. Гибкие диски и модемы уходят в прошлое. Я не знаю вуза под названием ВМК. Если вы имеете в виду факультет ВМК, то их в этой стране как минимум несколько. Но если еще раз сузить круг до МГУ, то там ООП не изучается в основах программирования, насколько мне известно (разве что меня обуял страшный склероз всего за 10 лет). На 1м курсе проходятся две базовых "программистских" дисциплины - это "алгоритмы" (на базе Pascal) и "ассемблер" (8086 + какие-то экзотические придуманные машины). На 2м курсе изучались системное программное обеспечение (на базе С), прикладное программное обеспечение и машинная графика. Я слышал, что несколько лет назад С заменили на С++, но даже если оставить этот мудрый ход конем без комментариев, то в основы это все равно никак не попадает. Добавление от 30.09.2008 13:34: Yossarian Увы, это не удастся сделать. Язык С разрабатывался как язык системного программирования, и ничего с этим поделать нельзя. Почему же нельзя. Можно забыть о том, с какой целью он разрабатывался. Это первый "серьезный" язык, в котором есть возможность без существенных извращений обратиться по любому адресу памяти в строго определенной архитектуре. В x86 или IBM370 этот номер не пройдет - есть защита. Вы говорите, что есть возможность, а потом сразу же говорите, что нет. K&R не говорит о такой возможности, C99 тоже. Кому верить? Если мы говорим, не о первом компиляторе С, а о чем-нибудь мал-мальски стандартизированном, то описанная вами возможность ограничена. С точки зрения языка обращение к памяти, не занятой объектом, не имеет смысла. Допустим, стандарт не запрещает такую операцию, а всего лишь указывает на неопределенность результата. Если следовать этой идее, не углубляясь в детали, то вопрос об особенностях PDP-11 при изучения программирования можно закрыть. Позже, в рамках изучения системного программирования при желании каждый имеет возможность узнать, что же для его компилятора и платформы будет обозначать "неопределенная" операция *((int *)0x12345678). В AVR адресных пространств 5 штук разных. Их и на x86 можно сделать несколько использованием сегментации (например, так много где работает адресация TLS - хотя в данном случае а.п. TLS отличается от адресного пр-ва процесса только смещением). В Linux на IA-32 ядро и процессы могут жить в отдельных 4-гб адресных пространствах. Но при этом этот вопрос волнует очень узкий слой системных разработчиков (я уже не говорю про изучающих программирование), поскольку в рамках используемой ими модели процесс не может напрямую адресовать ядро и наборот. В Паскале проблем не возникает ни с тем, ни с этим - проверка типов не даст произвольно смешивать разные адреса. То, что компилятор/среда_исполнения бьет программиста по рукам - это может и хорошо в каком-то смысле. Но до изобретения искусственного интеллекта программист всегда при желании на любом языке сможет написать неработающий код. Добавление от 30.09.2008 13:56: Yossarian Вот и плохо. Когда сходу можно получить интересный результат вроде проигрывания музыки или еще какого эффекта, ученикам становится интересно. А когда для воспроизведения звукового файла нужно написать полстраницы заклинаний - это скучно. Насколько я помню, в нашем курсе "информатики" были и текстовый редактор и графический редактор и чего только не было "красявого" и увлекательного. Основы программирования - и то были на "кенгуренке" и "пылесосике". Но в какой-то момент надо посерьезнее.

54. Yossarian, 30.09.2008 18:07

Murr Вы говорите, что есть возможность, а потом сразу же говорите, что нет. А, ну так не путайте теплое с мягким, и все будет хорошо. Язык дает такую возможность, а железка не дает. И это плохо. Потому что при изучении программирования должна быть какая-то помощь со стороны инструмента. Не сразу пускать на пилораму, а потренироваться на более безопасных вещах. Их и на x86 можно сделать несколько использованием сегментации Нее.. В AVR они не просто разные, они физически разные. И обращение к ним идет разными командами процессора. А кстати, вспомните, как выглядели в x86 real mode все эти модели памяти. Large, Huge, Small. Прошу заметить, что в турбопаскале этой проблемы не было. То, что компилятор/среда_исполнения бьет программиста по рукам - это может и хорошо в каком-то смысле. Но до изобретения искусственного интеллекта программист всегда при желании на любом языке сможет написать неработающий код. После - тоже. Основы программирования - и то были на "кенгуренке" и "пылесосике". Да. У нас почему-то часто путают занимательность и сюсюканье. Но это не программерская проблема.

55. Murr, 01.10.2008 02:45

Yossarian Язык дает такую возможность, а железка не дает. цитата: 752 An integer may be converted to any pointer type. 753 Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation. Добавление от 01.10.2008 02:53: Нее.. В AVR они не просто разные, они физически разные. И обращение к ним идет разными командами процессора. Ну на IA32 использование дополнительных сегментных регистров тоже добавляет префикс к машинной инструкции. Так что в каком-то смысле оно тоже почти разное. А кстати, вспомните, как выглядели в x86 real mode все эти модели памяти. Large, Huge, Small. Прошу заметить, что в турбопаскале этой проблемы не было. Если мне не изменяет память, то небольшие программы, использующие небольшие объемы данных, можно было создавать при любой модели памяти. У каждой реализации (компилятора под определенную платформу) есть свои ограничения, это понятно. Столкновение с таким несправедливым мироустройством - еще не повод бросаться в панику. В конце-концов и для 64 кб можно было много интересного написать. Добавление от 01.10.2008 02:55: После - тоже. После в каком-то смысле потребность в программистах отпадет. Во всяком случае формулировать задачу можно будет на очень высоком уровне. Добавление от 01.10.2008 03:16: Использование произвольной адресации - далеко не всегда хорошая идея. Когда-то давно у нас код тестировался на AXP 21264, Redhat 9. И там была одна замечательная особенность, о которой я прочитал в мануале - то, что AXP не терпит невыровненного доступа к памяти. Поскольку это никак не соответствовало моему опыту работы на этой машине (ну и вообще идее, что там работает более-менее любое криво написанное ПО), то пришлось поставить опыт, в результате которого выяснилось, что ядерный код Linux для AXP при возникновении исключения невыровненного доступа пытается разобрать текущую команду и изобразить ее эквивалент несколькими операциями выровненного доступа. Замеры производительности показали, что код, использующий невыровненный доступ, в сотни (или даже тысячи) раз медленнее нормального. Собственно к чему этот пример... К тому, что даже если и можно разыменовать определенный указатель, то могут быть значительные платформозависимые тонкости. Но, опять же, их не обязательно знать человеку, который изучает С. Вот в курсе системного программирования (если он выберет изучение программирования) он уже узнает про виртуальную память и соответствующие механизмы и про mmap/munmap/mprotect (или их не-POSIX аналоги) в частности.

56. Yossarian, 01.10.2008 08:57

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

57. Vlad Tepes, 01.10.2008 21:44

Yossarian Я не считаю событийно-управляемое программирование чем-то новым и современным. Оно появилось примерно одновременно с терминальным вводом-выводом. Проблема в том, что как правильно выразился Murr, главный фетиш терминального ввода-вывода - в том, что его не нужно учить. Ученик мгновенно с ним осваивается и далее считает, что все ясно. А это всего лишь частный случай. Да в общем то любой ввод/вывод моно отнести к "частным случаям". Проблема в том, что изучение реализации ввода/вывода в различных GUI во-первых связано с особенностями конкретной платформы (API), а во-вторых требует несколько больших затрат времени, и в рамках учебного процесса это не всегда может быть оправдано. Хотя есть вариант вообще начинать с логического или функционального программирования. Мне кажется что начинать с этого и потом переходить к структурному программированию и ООП - это экстрим Тем более при обучении школьников. А вот интересно, как бы Вы предложили построить учебный курс по программированию для школьников (имеется в виду перечень и очередность изложения нужных на Ваш взгляд тем). Я боюсь, что мой опыт преподавания недостаточен для того, чтобы вот так сразу написать темы целого курса. Но по темам примерно так: Теория множеств, дискретная алгебра. Тут же где-то двоичная система и коды. Функции, вычисления. Вычисления на калькуляторе. Формулировка задачи, логическое программирование. Функциональное программирование. Алгоритмы. Объекты и свойства. Структуры данных. Параллельные вычисления. Синхронизация. Сетевые взаимодействия. Распределенные вычисления. Основные операторы (if, while, =). Методы объектов. Базы данных, SQL, реляционная алгебра. Объектное проектирование. Вы уверенны, что параллельные вычисления и синхронизация это те темы, которые следует рассматривать в школьном возрасте? Думаю этим вещам нужно учить исключительно тех, кто избрал программирование своей будущей профессией, и несколько позднее Murr Столкновение с таким несправедливым мироустройством - еще не повод бросаться в панику. В конце-концов и для 64 кб можно было много интересного написать. А еще, в качестве примера способов борьбы с "несправедливым мироустройством" можно озадачить учеников такой темой, как работа с разреженными матрицами Yossarian На самом деле мы с Вами говорим в точности об одном и том же. О платформозависимых тонкостях. Только я считаю, что наличие таких тонкостей мешает преподаванию языка в качестве первого, а Вы считаете, что не мешает. Вот и вся разница. По моему в контексте темы правильнее было бы говорить не о наличии тонкостей у конкретной платформы, а о возможности использования этих тонкостей в конкретном языке (или даже в конкретной реализации языка) программирования . И я не уверен, что, например, возможность использовать в C адресную арифметику, делает этот язык категорически не пригодным для учебного процесса. Сам по себе этот язык вполне удобен, и, что очень важно - достаточно широко распространен. На мой взгляд, не может быть ничего хуже, чем фраза в процессе обучения "а вот это тебе пока что знать не надо". Складывается впечатление, что для того чтобы избежать необходимости произносить эту фразу, Вы хотите поставить учеников в условия, при которых они даже не будут догадываться о существовании "этого".

58. Yossarian, 02.10.2008 10:02

Vlad Tepes Проблема в том, что изучение реализации ввода/вывода в различных GUI во-первых связано с особенностями конкретной платформы (API), а во-вторых требует несколько больших затрат времени, и в рамках учебного процесса это не всегда может быть оправдано. Если не использовать универсальные "обертки" типа Delphi или wxWindows или Qt - то да. Но кто мешает их использовать ? Мне кажется что начинать с этого и потом переходить к структурному программированию и ООП - это экстрим. Тем более при обучении школьников. Экстрим это только в одном смысле. Преподаватели не знают ни ООП ни функционального программирования. А для школьников разницы нет. Вы уверенны, что параллельные вычисления и синхронизация это те темы, которые следует рассматривать в школьном возрасте? Да, конечно. Интернет в каждом доме, многоядерные процессоры - это реалии сегодняшнего дня. Складывается впечатление, что для того чтобы избежать необходимости произносить эту фразу, Вы хотите поставить учеников в условия, при которых они даже не будут догадываться о существовании "этого". Не совсем точная формулировка. Я хочу организовать обучение так, чтобы "этих" вопросов в рамках курса не возникало. А за рамками - сколько угодно.

59. doomer#gp, 02.10.2008 10:57

Больше всего я не понимаю нафига нужно повальное изучение этого программирования. Зачем толпы кодирующих мартышек ? Почему повально не учат торговле на бирже, бурению скважин, банковскому делу, хирургии итд. и тп. Программист - это серьезная узкоспециализированная профессия (в зависимости от области), требующая нормального поставленного обучения. Если раньше программист ассоциировался с серьезным бородатым дядей лет 30-40, то теперь под этим человеком чаще всего понимается како-то больной мальчик, котрому в жизни ничего кроме компа не надо. Но ведь эти больные мальчики не создают новых эффективных продуктов - так, поковырять лишь-бы что-то, заплатки да поделки. Есть более важные и нужные области чем это повальное программирование. Разве не заметно как идет потеря времни на постаянную погоню за чужими краткосрочными технологиями (которые объективно абсолютно не являются прогрессом), вместо развития в фундаментальных предметных областях. DOS Win95,WinXP, WinVista - разработчики теряют время на осовения работы гигабайтов индусского кода вместо развития в прикладной области, прогресс в которой и дает возможность создания принципиально новых продуктов на рынок. Помню как-то проводили какой-то конкурс по программированию среди разработчиков. Были разные задания на алгоритмы, работу с памятью и т.д. Больше всего запомнился тот факт что задачу о распознавании изображения практически нико из участников и не решил, что явно свидетельствует о крайне слабом развитии в пердметной области. Добавление от 02.10.2008 11:04: Да, в развитии кибирнетики за последние пол века скачек значительный. Но в тоже время. Сколько прошло времени как выполняются регулярные, скажем, авиа преревозки. Скорость, в 10 мах на данных аппаратах не достигнута. Вот, если можно было доставить скажем 100 т. груза из Москвы в Нью-Йорк за 5 мин., в промышленном масштабе - то это уже принципиально меняет положение дел.

60. ash of mind, 02.10.2008 11:07

Yossarian Да, конечно. Интернет в каждом доме, многоядерные процессоры - это реалии сегодняшнего дня. 1. "По результатам интернет-опроса, 100% пользователей пользуются интернетом" (с) 2. Вы-таки уверены, что под всё это софт пишется собственноручно? Остальное за меня сказал doomer#gp.

61. Пьеро, 02.10.2008 11:14

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

62. Yossarian, 02.10.2008 11:57

Пьеро Поэтому полагаю, что в школе должна проводиться работа в рамках "компьютерной грамотности" и не более того. А вот в ВУЗах сразу необходимо учиться по "углубленной" программе. Это распространенное мнение. Дескать, давайте в школах до 11 класса играть в куклы и читать Муму, а в институте давайте сразу всему научим. Первое более или менее удается, а вот с переходом ко второму возникает масса сложностей. Я думаю, что во-первых, в школах тоже нужна некоторая специализация, а во-вторых, надо стараться учить каким-то более-менее передовым вещам. Когда школьники начнут работать, эти вещи вполне успеют устареть.

63. Пьеро, 02.10.2008 12:07

Yossarian Подавляющее большинство людей не будут программистами и "учить каким-то более-менее передовым вещам" не нужно принципиально. Необходимо научить пользоваться компьютером, не более того. Специализация может быть и в рамках школы - матклассы могут включать в себя нечто большее "компьютерной грамотности". Никого ведь не смущает, что в школе в рамках уроков физики на примере "кукол и Муму" объясняют про прочность материалов и закон Ома. А в институте потом "сразу всему учат" на существенно другом уровне: сопромат, электротехника и т.д. Почему программирование ставят в привилегированное положение? Этот раздел человеческих знаний ничем не лучше/хуже других и отношение к нему должно быть соответствующее. Добавление от 02.10.2008 12:32: Yossarian Подавляющее большинство людей не будут программистами и "учить каким-то более-менее передовым вещам" не нужно принципиально. Необходимо научить пользоваться компьютером, не более того. Специализация может быть и в рамках школы - матклассы могут включать в себя нечто большее "компьютерной грамотности". Никого ведь не смущает, что в школе в рамках уроков физики на примере "кукол и Муму" объясняют про прочность материалов и закон Ома. А в институте потом "сразу всему учат" на существенно другом уровне: сопромат, электротехника и т.д. Почему программирование ставят в привилегированное положение? Этот раздел человеческих знаний ничем не лучше/хуже других и отношение к нему должно быть соответствующее.

64. Yossarian, 02.10.2008 13:18

Пьеро Почему программирование ставят в привилегированное положение? Этот раздел человеческих знаний ничем не лучше/хуже других и отношение к нему должно быть соответствующее. Да, конечно. Все именно так. На уроках биологии рассказывают про фотосинтез, на уроках физики про закон Джоуля-Ленца. Хотя большинство школьников никогда этими знаниями не воспользуется. ООП ничуть не сложнее, и на самом деле сейчас в школах обратная ситуация. По программированию рассказывают какие-то безнадежно устаревшие вещи. Я же не предлагаю изучать RUP, системное программирование или генетические алгоритмы. Я предлагаю примерно подтянуть эту дисциплину (надеюсь, в ее необходимости сомнений нет ?) к остальным. Ну что поделаешь, эта отрасль действительно очень быстро развивается.

65. mike_teplitsky, 28.10.2008 16:38

где именно, кроме микроконтроллеров, используется в настоящее время язык С ну я вот например в банке на C ядро системы отчетов пишу. интерейсы на Perl и Web services

66. Yossarian, 28.10.2008 17:07

mike_teplitsky ну я вот например в банке на C ядро системы отчетов пишу А почему именно на С ?

67. mike_teplitsky, 28.10.2008 17:09

Yossarian А почему именно на С тяжелое наследие прошлого

68. Yossarian, 28.10.2008 18:22

mike_teplitsky тяжелое наследие прошлого Ну вот об этом и речь.

70. Yossarian, 19.11.2008 09:50

Ди С++ и Pascal в настоящий момент не тяжёлое наследие прошлого? Увы, да. К тому моменту, когда современные школьники дорастут до институтов и техникумов, С++ может стать на место современного С, а С - соответственно - на место COBOL или светлой памяти Algol 60.

72. Yossarian, 19.11.2008 21:36

Ди Сложный вопрос. Вряд ли академики смогут его решить. Если взять несколько развивающихся языков (например, PHP, Javascript, Nemerle, Python, lua...) и смотреть, в какую сторону идет развитие, то можно приблизительно выделить некоторые черты, чаще других добавляемые к языкам. Это : Создание объектов на основе прототипов, возможность смешивать функциональный и процедурный стиль программирования, стирание разницы между объектами и массивами, разделение пространств имен (namespaces), reflection. В опреденной степени эти же особенности появляются и в "традиционных" C++, Object Pascal, Java но там их внедрение ограничено уже сложившимися способами реализации. Разумеется, должны быть обработка исключительных ситуаций (try - catch), ООП, возможность НЕ использовать ООП.

74. Yossarian, 20.11.2008 08:28

Ди Ну и что из выше перечисленного нет в С++\Delphi language\Java\C# ? Например, прототипов. В Дельфи нет безымянных функций/лямбд. В Java нет возможности не использовать ООП. что тут нового? А Вы думали, что я предложу malbolge ? В нем тоже ничего нового. Преподавать Haskell или Prolog большинство преподавателей не смогут. Если Вы уверены что компьютер есть в каждом доме В большинстве школ есть.