[прикрываясь ветошью и отползая в ближайшую канаву]

о боже... о нет... сейчас тут ТАКОЕ НАЧНЕТСЯ....
А доклад любопытный, и даже очень.
Особенно мне понравилось про то, что надо еще и предметную область знать.

>...надо еще и предметную область знать

:)! Видимо, это основное отличие программистов от "программистов".

Не смотря на предупреждение, побеспокою.
Языки Вирта мало отличаются от современных монстров, типа C++. Чуть более рафинированные и чуть качественнее спроектированы. Но принцип тот же.
И этот принцип безнадежно старел.
Более того, навязывая этот принцип при обучении, отбивают у студентов способность воспринимать более перспективные идеи.

На мой взгляд, наиболее перспективны так называемые DSL (Domain Specifiec Language). (Кстати, давным давно, некто Михаил Каменщиков продвизал идеи DSL в Oberon - поищите "умные макросы". Но когда я последний раз сним пытался списаться, он уже ушел с головой в какую-то религию.)
В C++ кое-какие методы в стиле DSL применимы, но требуют очень высокой квалификации. В языках Вирта для них требуется разработка дополнительных инструментов, которым рафинированность будет только мешать.

А зря.

Учить надо логике, а не языкам программирования.

Термин "логика" перегружен в в русском языке, хотя и подходит. Конечно, без логики не то, что программировать, жить -то нельзя. Наверное, надо учить правильным приёмам алгоритмирования. Язык же для обучения необходим. Без прогонов программ на реальных машинах толку-то не будет. Но язык должен быть минимальным и содержать только те средства, которые соответствуют "правильным приёмам алгоритмирования". Как-то так, что ли?

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

Какие при этом используются закорючки -- не суть важно.

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

Приёмы программирования -- это как приёмы конструирования. Вал садят в отверстие так-то. В таких-то местах применяют болт, а в таких-то -- заклёпку. Понимаете? Чтобы человек не парил мыслями в эмпиреях "логики", а знал конкретно, как однотипно решать однотипные небольшие задачки, из которых и состоят большие программы. Плюс навыки управления сложностью! Это структурирование самой программы, данных и алгоритма. Программы неимоверно сложны, потому что на их создание не требуется тратить металл:)

Программирование к "конструированию" никакого отношения не имеет. "Конструировать" программы -- все равно, что "конструировать" художественный роман.

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

Вы меня поражаете! Осознание единства программирования и всей иной инженерной деятельности было существеннейшим прорывом 70х годов в понимании обсуждаемой проблемы! Структурированнное программирование и проектирование программ помните?
А штампы нужны. Даже необходимы. В любой области деятельности. Надо только подходить ко всему диалектически. Без абсолютизации и фанатизма:)

Нет никаких "приёмов обращения с лопатой", из принципа, поскольку копание есть просто перемещение земли из одного места в другое.

Аналогия понятна?

всё программирование можно свести к перемещению байтов из одной ячейки памяти в другую?

Нет, естественно. В программировании нас интересуют не процессы, происходящие в компьютере, а мыслительные процессы человека. Поэтому я и хотел сказать, что "приёмы программирования" существуют и должны существовать, поскольку мы здесь имеем дело не с голой логикой, а с человеческой психикой.

А с человеческой психикой мы иметь дело вынуждены, поскольку пока что кроме человека писать программы некому.

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

Пользуйтесь логикой и не балуйтесь аналогиями, короче.

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

Аналогия понятна. Называется Ваша мысль так: "Смелость неведенья".

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

Чтение Ваших новых постов делает неуместным моё саркастическое хмыканье. Я с Вами согласен полностью. ПО психике и по приёмам программирования.

Хотя по вашим другим ответам вижу, что наши мнения здесь совпадают.

>...наши мнения здесь совпадают

Да, абсолютно. Я уже где-то тут высказался по этому поводу. Что совпадают, в смысле:)

Это не ошибка. Программа -- это единство структуры собственно программы (отношения подчинённости частей программы), данных, и алгоритма(ов). То, что обычно называю словом "логика" -- это алгоритм. Только. Остальное -- инженерная конструкция. Типа того.

Язык и мысль, им выражаемая, находятся в диалектической взаимосвязи. Каков язык, таково и качество выражения мысли. При низком качестве языка, его необоснованной перегруженности необязательными "возможностями", самая хорошая мысль может исказиться или просто стать неясной. Не надо противопоставлять алгоритмирование и язык. Без языка нельзя.

И "программа", и "данные" в ровной степени точно такая же чистая логика, как и "алгоритм". (Разница между тремя минимальна -- в том, как именно определяется понятие "времени". При высоком уровне абстракции все три сливаются в одно и то же.)

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

Всё правильно Вы говорите. Я с Вами согласен. Кроме одного -- языка. Язык влияет на выражаемую мысль. На "логику" по Вашему. Язык должен быть минимальным, как набор аксиом и постулатов Эвклида. Иначе напашут. И уже напахали. И ещё пашут. Скоро все будут заниматься латанием ранее написанных некультурных программ.

А в "напаханом" вноваты не языки, а отсутствие аксиом и возможности их применить в головах программистов. Именно поэтому "приемы программирования" сугубо вредны для общества.

У меня сейчас, кажется, истерика начнется.

Сложность программирования НЕ в логике. НЕ в том, чтобы придумать и правильно записать алгоритм. Это - как раз занятие простое и интеллектуально приятное, многие готовы этим заниматься бесплатно и еще приплачивать.

Сложность - во взаимодействии с множеством подсистем, которые писали не боги, а обычные люди. "Обучение программированию", которое не учит взаимодействию с чужими глупостями и ошибками, ПРАКТИЧЕСКИ БЕСПОЛЕЗНО.

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

чтд, в общем.

Хм.

У моего комментария по крайней мере была цель. Донести некую мысль. А у вас?

Займитесь прокачкой скилла чтения на русском и не морочте людям голову, ок?

"Вдобавок" пишется слитно, а "морочьте" - с мягким знаком. Кстати, у вас есть парень? По журналу неясно - там только одна запись, и в ней ничего не написано.

Придумать алгоритм - простое занятие?
Ну-ну...

Не в пример приятнее и проще, чем искать ошибку в чужой плохо написанной программе из ста тысяч строк.

Придумайте алгоритмик, сравнимый хоть с одним из этой книжки (http://www.ozon.ru/context/detail/id/83808/).
Это ни чуть не проще, чем поиск ошибки в ядре FreeBSD. Правда FreeBSD - хорошо написана. С плохо написанными я сталкивался несколько меньшего объема...

Одна из моих любимых книг, кстати =)

Давайте проведу аналогию, чтобы было понятнее.

- сидеть дома за пианино и писать песни легко и приятно, гораздо легче и приятнее, чем разгребать дерьмо лопатой

- а вы напишите-ка мне "Очи черные" или что-нибудь сравнимое, тогда и посмотрим

Ядро FreeBSD - не вполне удачный пример =)

Вообразите себе какую-нибудь "бизнес-систему" - база данных из сотен таблиц без особой нормализации, SQL-запросы размером по несколько килобайт, масса Java-кода на сервере для генерации HTML-формочек. Такая штука легко растет до ста тысяч строк и больше, особенно если над ней работает десяток не самых компетентных программистов в условиях жестких сроков.

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

Правы и те и другие - вот в чём главная печаль :(
Нужно искать золотую середину, а этого никто делать не хочет ... точнее - не может.
А ещё точнее, "как правильно учить программированию" - тоже задачка для Программиста с большой буквы.
"Очи чёрные" в своём роде.

Амбивалентоность проявляете. И нашим, и Вашим... Есть-таки абсолютные истины. Надо их не стесняться.

Я имею ввиду компромисс.
"Абсолютная истина" в данном вопросе состоит в том, что нужно совмещать теорию и практику, но теория стремится быть академической, а практика - тупо прагматической. Отсюда и проблема.

remark: Всё в мире относительно (если не принимать в расчёт Бога в разных проявлениях).

>...но теория стремится быть академической, а практика - тупо прагматической. Отсюда и проблема

Согласен. Причём "тупо" -- очень важное слово:)

Синтез нужен.

Подтверждаю разумность сказанного в докладе и вслед за xlein прячусь в ближайшее бомбоубежище.

> Грубо говоря, сегодняшнее состояние в ИТ области может быть выражено так: "тусовка ИТ-индустрии
> [американской] с прикормленной ИТ-профессурой и компрадорским бизнесом [России]"

Так и есть.

а можно научить человека думать?

>...а можно научить человека думать?

Можно. Этим и занимается образование.

К сожалению, не в его современном виде.

И я о том же:(

Так о том уже не раз. Альтернативы имеют место?

Читайте, например, доклад. И всюду надо так. Фурсенок выгнать надо. Много чего надо... Бороться надо.

Я прочитала. Интересно, но не решает проблемы. Хотя для переходного этапа подойдет. Спасибо. Я вообще думаю сейчас, а вот с Фурсенко - даже спорить не стану:-)

Мне кажется, всякие "компрачикосы" и "компрадоры" затеняют суть.

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

Интересно, там есть драйвер для моего ADSL-модема? Можно ли посмотреть фильм с DVD? Напечатать PDF-документ на принтере? Провести синхронизацию с моим Palm? Закачать файл в телефон по Bluetooth?

Эх, товарищи, все бы вам стратегические отрасли развивать.

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

Так перенесите, раз без проблем. Или Вы это мне предлагаете сделать?

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

У меня они не возникли пока =)

Мне предлагают бесплатный софт, который делает 3 полезные вещи, а 100 других полезных вещей не делает. "Ну и что, зато Бесплатно и Красиво! И вообще, разбирайтесь с проблемами по мере возникновения."

Да кому они нужны, эти ваши проблемы, если в других средах (написанных на C и C++, кстати) они давно и успешно решены!

У инженеров есть такое понятие "наращиваемость системы". Это решение. Зачем "софт", который делает 100 вещей, о существовании которых я даже не подозреваю. Пусть делает три вещи, которые мне действительно нужны. Или четыре. Или столько, сколько я захочу подклюлючить. Как в 80х. :)

Не дадут. Надо выжать из пользователя максимум денег. Поэтому будут впаривать софт, делающий 100 вещей.
А насчет интересно, там есть драйвер для моего ADSL-модема? Можно ли посмотреть фильм с DVD? Напечатать PDF-документ на принтере? Провести синхронизацию с моим Palm? Закачать файл в телефон по Bluetooth? - а можно управлять с линукса или винды атомным реактором или самолетом - хрен там.
Почему нужен драйвер для ADSL-модема? А потому что благодаря "конкуренции" модем работает только с программой заточенной под него. И вместо одного драйвера получаем по драйверу на каждый вариант модема.

а 100 других полезных вещей не делает

Не делает какая-то одна программа? По вашему программа просмотра дирректорий должна и DVD проигрывать, и за пивом бегать?

Если "бесплатный софт" вообще, то что это за "100 полезных вещей", которые не делает свободный софт и делает проприетарный?

Основные изначальные посылки статьи, конечно же, правильные. Кто ж спорит. Однако касательно содержимого университетских курсов - мелкое плаванье; по-хорошему, в МГУшные курсы надо серьезно добавлять и расширять логику, дискретную математику, computational complexity, алгоритмы и т.д. А собственно язык программирования - дело, в принципе, довольно десятое. Хотя Паскаль и производные для обучения хорош, да.

Правильно. Учиться делу надо, а не сложностям языков. А для обучения иметь простой понятный язык. Типа Паскаля. Без излишеств, но с неограниченными возможностями.

Так возьмите Schema - куда уж проще.

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

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

'Структуры данных и алгоритмы', и, уж тем более, Паскаль и Оберон, означает, что мы остаемся в рамках структурного (в лучшем случае - модульного) программирования. Такие вещи, как аспектное, объектно-ориентированное, обобщенное, функциональное программирования, программирование, основанное на языках, специфичных для предметной области, программирование, основанное на правилах, программирование, основанное на ограничениях, логическое программирование остаются 'за кадром', в то время, как многопарадигменные языки, такие как семейство Lisp, позволяют легко показать все вышеперечисленные подходы (навскидку: CommonLisp; Schema; Logo, eLisp, как важные примеры языков предметных областей).

Структуры данных и алгоритмы важны, как хороший пример, на котором можно изучать стиль, эффективность, самодокументирование, совместимость и другие важные аспекты программистского образования, но явно недостаточны для современного программиста. Человек, ознакомившийся со всем Кнутом и с Корменом, будет способен решать задачи ICPC-олимпиад, но уже перед ICFP он будет пасовать.

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

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

{+}

Самый минимальный язык (о которых я знаю) - Smalltalk. Самый удобный язык (с которым знаком) - все тот же Smalltalk. После него очень не хочется использовать C++, C# или, уф, какая неприятность, Pascal.

То, что непрофессиональных программистов больше чем профи, - это известный факт. Но зачем обучать программированию в школе? Ведь из 1000 выпускников школы профессиональными разработчиками станут несколько (1-2 максимум), непрофессиональными - около 20-30 (с большим запасом).

Но, если так подоходить, то для начального обучения Smalltalk выглядит гораздо лучше - потому что в нем можно посмотреть всю систему - до самого "дна". Или ограничиться самым верхом и никуда не спускаться.

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


****
P.S. А кто такие "компрачикосы"?


P.P.S. Лучше обучать "структурному мышлению" - когда человек может разделить сложную задачу на несколько маленьких. Или для сложной задачи взять самые важные детали и начать плясать от них. А то разные программисты либо неверно делят (а потом - дикие сложности), либо начинают углубляться в ненужные детали (где потом теряются все, кто угодно).


P.P.P.S. О докладе (так, просто "цепляние")

Страница 2/10

* "2) Все чаще возникают ситуации, .... Проблема взаимопонимания существенно упростится, если ..."

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

* "4) ...в результате специалисты все чаще предпочитают брать ... профессиональные системы.."

Очень слабо в это верится. Покупать Visual Studio за $1,000.00 или что-нибудь подобное - слишком дорого. Да и освоение профессиональных систем далеко не самое простое занятие.

Страница 3/10

* ".. на самом деле основы программирования - это дисциплина, сравнимая по общему значению с математикой и близкая ей по духу..."

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

...самый минимальный язык -- это лямбда-исчисления. Ну или алгорифмы Маркова.

А что сказать вы хотели, я так и не понял.

Я хотел сказать, что считаю доклад надуманным и вредным.

На мой взгляд, он (доклад) хорошо описывает состояние нашего образования в области обучения разработке ПО (не программированию, но именно разработке) - таковое образование отсутствует.

Умные люди пишут достаточно странный документ, ничем не обоснованный, но с претензией на "давайте сделаем прекрасную штуку". Поэтому доклад надуманный.

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

Ставить профессиональное образование разработчиков надо. Но делать это подобным образом (как предлагается в докладе) - очень нехорошая мысль.

Это такие гады, которые уродуют маленьких детей, чтобы они потом служили клоунами на потеху за деньги. См. Виктор Гюго.

>...Не совсем соглашусь - слишком по-разному идет работа в математике (сугубо работа мозга и выводы в теоремах) и в программировании (переделать 1 Мб кода непросто, а понять или спроектировать работу распределенной системы еще сложнее и нет теорем).

Если глубже продумывать, то не потребуется писать мегабайты кода одним куском. То есть, общий объём кода будет, конечно, большим, но ни одна проблема не будет таиться во всём этом объёме, а только на участке текста программы не более сотни строк.
Вы же сами рассказали, как это надо делать:).
А формально и аккуратно думать учат как раз в математике.

http://www.dialog-21.ru/full_digest.asp?digest_id=42315

Да, тоскливая жизнь у тех, кто этим самым аутсорсингом занимается. Нетворческая. Прям рабство у капитала какое-то!

Все эти споры какой из "структурных" дообъектных языков лучше закончились в средние века с наступлением климакса поколения Дийкстра, Вирта и других великих. Древнегреческие мифы какие-то. Сечас даже ембедщики все объектные. Разговаривал как-то с одним эмбедщиком, спрашиваю зачем тебе сипласплас, у вас же у эмбедщиков ресурсы жесткие. Тот говорит, дескать ничего, нормально. Heap, stack, threads, мини/микро ядра - все как в больших ОС. Идеология на западе очень отличается от российской. При создании продукта задача ставится очень рационально - использовать как можно больше готовых компонент, библиотек, готовых API. А соотечественники чаще встречаются с менталитетом - все свое накропаю, даже соседское бесплатное не возьму. Корни растут видимо в тяжелом историческом наследии - избытке оплаченного рабочего времени времен совка.

>...- все свое накропаю, даже соседское бесплатное не возьму.

Угу. Солидарен. Это правильно.

>...Корни растут видимо в тяжелом историческом наследии - избытке оплаченного рабочего времени времен совка.

Не-а. Корни гораздо глубже. Крестьянский труд на огромной холодной земле. Представьте себя с семьёй в глубокой осенью где-нибудь в маленькой деревеньке в костромских лесах...
Скоро выпадет снег, тогда доедем до села, поменяем лыко на хлеб... Эх, что же я делянку ржи весной-то не засеял, лодырь непутевый! Всё Макар с толку сбил, не возись, говорит, надерёшь лыка, я его всегда на муку сменяю. Вот и грызём локоть теперь. Ещё и лошадь сожрать придётся, чтоб ему!

Экономика называется.

{+}

А совок не трожьте. Люблю я его:).

{+}

overpromise и underdelivery. Похожий паттерн в маркетинге технологий называется Osborne Effect. Одна успешная фирма как то пообещала, что дескать через год всех завалим новой моделью продукта. Спрос на старую модель моментально прекратился. Фирма обанкротилась не успев донести до рынка обещаный новый продукт. С тех пор (с 80-х) принято объявлять о больших изменениях в продукте как можно ближе к дате действительной доставки. С другой стороны если призадуматься то возможен такой же эффект с обратным знаком. Например предыдущий продукт настолько успешен, что спрос на новую модель не формируется.

начинается всё с заоблачных высей, дескать как всё сложно (да, сложно) в таких областях как космонавтика, ядрена физика, ...

потом идёт плач про отсутствие культуры доказательного проектирования (да, отсутсвует) у подавляющего числа программистов...

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

Доказательность рассуждений налицо.

А вы не пробовали интересоваться, на каких языках и кем разрабатывалось ПО для почти-космического проекта выигравшего x-prize? А не интересно ли вам, в какие языки вкладывается тот самый CERN чтобы построить унифицированную среду вычислений для нужд физики высоких энергий?

А причем тут Паскаль?

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

Тьфу на вас, никакой пользы от этого тезиса (в такой форме) ни для науки ни для практики не вижу.

Маркер в руки и чиркать да переписывать.

Вот берите маркер и пишите свой доклад.

вам будет нечего сказать.

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

>...поглядите хоть немного на чужой

Рад бы, но увы. Не вижу образцов для подражания.