Форум: "Прочее";
Текущий архив: 2008.05.25;
Скачать: [xml.tar.bz2];
ВнизПарадокс Блаба и обучению программированию Найти похожие ветки
← →
Alkid © (2008-04-09 11:55) [0]Есть такой чувак - Пол Грэхам, пророк и мессия LISPа в нашем грешном мире. Он в своё время сформулировал интересную вещь - парадокс Блаба.
(он есть тут, где-то посередине текста:
http://www.paulgraham.com/avg.html ищите по слову "Blub").
ИМХО, рациональное зерно в этом есть.
Так вот, собственно, вопрос - не стоит ли начинать преподавание в профильных ВУЗах с более мощных и высокоуровневых языков, пусть даже и не мэйнстримовых? Того же Лиспа, например (или Схемы), что бы "размять мозги" студенту и не дать ему закоснеть в рамках более ограниченного мэнстрима. А потом уже переходить к распространённым промышленным языкам (C/C++/Java/.NET/Deplhi), что бы подготовить его к реальным задачам. Ваши мнения, коллеги?
← →
Kolan © (2008-04-09 12:01) [1]> Блаба
Только с 20 раза прочитал не «бабла».
> Ваши мнения, коллеги?
Мое имхо — надо учить думать, проектировать, а языки — это инстументы…
← →
Alkid © (2008-04-09 12:11) [2]
> Только с 20 раза прочитал не «бабла».
Кому что :)
> Мое имхо — надо учить думать, проектировать, а языки — это
> инстументы…
Хм, не совсем. Язык, как естественный, так и программирования, навязывает нам абстракции, которыми мы мыслим, т.е. серьёзным образом определяет наш способ думать. И думать в контексте программирования людей учат именно при помощи языков программирования.
← →
clickmaker © (2008-04-09 12:23) [3]
> стоит ли начинать преподавание в профильных ВУЗах с более
> мощных и высокоуровневых языков
у нас в ВУЗе давали и лисп и плюсы и трубопаскакаль... только вот программистами, да хоть и просто инженерами, стали по 2-3 человека из группы.
Остальные - кто куда. Кто продает, кто покупает, кто руководит...
Я к чему. Половина идет в ВУЗ просто за дипломом "щоб було". Их "разминать" бесполезно. Другая половина делится на тех, кого удалось "размять", т.е. они сами заинтересовались и тех, кто в конце концов присоединяется к первой половине.
Отсюда вывод: если нет реальных/практических/интересных (нужное подчеркнуть) задач, то размять мозги не сможет даже самый мускулистый массажист. А реальные/практические/интересные задачи - это тот самый мэинстрим
← →
Simpson (2008-04-09 12:29) [4]Alkid © (09.04.08 11:55)
Есть мнение что профессор Вирт писал Паскаль как раз под эти цели, помимо того есть еще и Оберон, и Модула того же автора. Дубовый кофе(Java) много чего утянул у Вирта, так что и простота, и строгость, и логика.
Специально для учебных заведений болтается в сети BlackBox(Windows+IDE+ Pascal), только учат все равно Си
← →
Mystic © (2008-04-09 12:39) [5]> Так вот, собственно, вопрос - не стоит ли начинать преподавание
> в профильных ВУЗах с более мощных и высокоуровневых языков,
> пусть даже и не мэйнстримовых? Того же Лиспа, например
> (или Схемы), что бы "размять мозги" студенту и не дать ему
> закоснеть в рамках более ограниченного мэнстрима. А потом
> уже переходить к распространённым промышленным языкам (C/C++/Java/.
> NET/Deplhi), что бы подготовить его к реальным задачам.
> Ваши мнения, коллеги?
Я бы не сказал про ВУЗы, меня просто интересует методика преподавания программирования.
Итак, вопрос: ты пробовал писать на функциональных языках программирования? На самом деле переходить на них и привыкать к ним очень даже непросто: другой стиль мышления. Нет локальных переменных. Функция зачастую передается в качестве аргумента другой функции. По сути это реализация некоторой математической абстракции.
С другой стороны при таком подходе возможен обратный эффект, о котором упоминал Джоэл Спольский: после этого становится трудно постигнуть указатели, императивный стиль. Да и те, кто программировал на ФЯ, зачастую после этого стремятся перенести функциональные черты в C#/C++/Delphi/Java. Хорошо это или плохо я не знаю, но языки под это мало пригодны (lambda есть только в C#)
Лично мой путь в программировании такой: МК-52, BASIC по книге, C, Pascal а уже потом ради интереса всякие другие языки программирования. Я знаю, что это рабочая схема.
← →
clickmaker © (2008-04-09 12:40) [6]
> мой путь в программировании такой: МК-52
а счеты? ))
← →
Kolan © (2008-04-09 12:46) [7]> счеты
Между прочим у нас в России я частенько вижу как на них считают в маленьких магазинах…
Привычка с 4 века до нашей эры видимо осталась…
← →
DiamondShark © (2008-04-09 12:47) [8]
> а счеты? ))
А у них не фоннеймановская архитектура.
← →
Alkid © (2008-04-09 12:51) [9]
> у нас в ВУЗе давали и лисп и плюсы и трубопаскакаль... только
> вот программистами, да хоть и просто инженерами, стали по
> 2-3 человека из группы.
> Остальные - кто куда. Кто продает, кто покупает, кто руководит.
> ..
Я не спорю, с ЭТИМ (т.е. с мотивацией) ситуация реально плачевная, но это тема для отдельной дискуссии. Я сейчас о другом - о том, как правильно научить тех, у кого с мотивацией в порядке и кто готот реально вложиться в обучение. Как правильно "потратить" этот ресурс, выжать из него максимум пользы - вот вопрос.
← →
DiamondShark © (2008-04-09 13:04) [10]
> Я не спорю, с ЭТИМ (т.е. с мотивацией) ситуация реально
> плачевная, но это тема для отдельной дискуссии. Я сейчас
> о другом - о том, как правильно научить тех, у кого с мотивацией
> в порядке и кто готот реально вложиться в обучение. Как
> правильно "потратить" этот ресурс, выжать из него максимум
> пользы - вот вопрос.
А тогда надо посмотреть на мотивацию ВУЗов.
Кодить на жабе, паскале и плюсах можно и обезьяну обучить. А у учебных заведений, даже типа некоммерческих, баблос за поголовье капает, а не за качество, всё равно рынок эту стаю обезьян слопает и не подавится. А то что продукт -- говно, так это фигня, для этого на соседнем факультете маркетоиды учатся.
← →
Alkid © (2008-04-09 13:06) [11]
> Итак, вопрос: ты пробовал писать на функциональных языках
> программирования? На самом деле переходить на них и привыкать
> к ним очень даже непросто: другой стиль мышления. Нет локальных
> переменных. Функция зачастую передается в качестве аргумента
> другой функции. По сути это реализация некоторой математической
> абстракции.
Немного пробовал. Мой путь тоже "традиционен" и "рабоч" - Turbo Pascal, Turbo Basic, калькулятор Б3-34, потом C, C++, C#.
Засада тут вот в чём - долгое время я учился (восновном сам) программировать н этих языках и они сформировали моё понимание программирования. Я не знал, что это лишь частный случай и есть альтернативные подходы.
Первая ломка сознания у меня случилась лет в 17, когда я начал изучать ООП. К тому времения я уже лет 7 самопалом прогарммировал в процедурном стиле и по-началу не мог вообще понять, что это за ООП, нафига оно надо, когда у меня и так всё замечательно. А там каких-то сложностей понавыдумывали.
Но потом я всё же изучил ООП и с тех пор (мне щас 26) "прокачивал" именно эту парадигму.
К сожалению, наш ВУЗ давал весьма хреновый уровень знаний по программированию и ни о каких альтернативах нам даже не рассказывали.
Из-за этого про альтернативы я узнал поздно, уже достаточно приросши мозгом к ООП. С другой стороны, хотелось развиватьс и я самостоятельно начал изучать ФП и ЛП, что привело к второй ломке сознания, когда уже сложившееся представление о том, как надо программировать, было отброшено и я начал снова его выстраивать. И пусть я даже не программирую на работе на Лиспе и Прологе (у нас С++), но те идеи, которые я почерпнул из них помогают мне.
Например, сейчас я пишу весьма хитрый кусок программы, где мне крайне пригодились некоторые новые для меня концепции. Я сначала написал "по-старинке", а потом увидел новые возможности и переписал - получилось короче, проще, элегантнее и, что немаловажно, оптимальнее по памяти и скорости работы.
Так вот, можно ли как-нибудь изначально дать студентам больше кругозора, что бы они не замыкались в одной парадигме? Имхо это было бы полезно, лучше чем если бы все как я доходили до этого личным опытом.
← →
Alkid © (2008-04-09 13:09) [12]
> А тогда надо посмотреть на мотивацию ВУЗов.
> Кодить на жабе, паскале и плюсах можно и обезьяну обучить.
> А у учебных заведений, даже типа некоммерческих, баблос
> за поголовье капает, а не за качество, всё равно рынок эту
> стаю обезьян слопает и не подавится. А то что продукт --
> говно, так это фигня, для этого на соседнем факультете
> маркетоиды учатся.
Увы, есть такое дело. Как пример - ВУЗ, в котором я учился. К счастью я самопалом учил всё сам и сильно за пределами программы. Уровень преподавания у нас был УЖАСЕН, при том, что победных фанфар на тему "какие мы крутые" было много :(
← →
Mystic © (2008-04-09 13:21) [13]> И пусть я даже не программирую на работе на Лиспе и Прологе
> (у нас С++)
Программирование на шаблонах и есть функциональный стиль :)
template <int n>
struct Factorial<0>
{
const value = 1;
};
template <int n>
struct Factorial
{
const value = n * Factorial<n-1>::value;
};
int array[Factorial<5>::value];
> Так вот, можно ли как-нибудь изначально дать студентам больше
> кругозора, что бы они не замыкались в одной парадигме?
Это безусловно полезно, вопрос с чего начинать?С фон Неймановской архитектуры, а потом писать на ней интерпретатор LISP или с LISP-а, а потом писать на нем интерпретатор фон Неймановской машины?
← →
Alkid © (2008-04-09 15:47) [14]
> Программирование на шаблонах и есть функциональный стиль
> :)
Это compile-time прибамбасы :) Кстати, шаблоны в Ц++ это тоже пример. Я сначала изучил С++ без шаблонов и, даже прочитав про них, не стал их использовать - мне и так было хорошо, я знал, как всё и без них сделать. Потом, когда уже научился ими пользоваться и "распробовав" их я начал извлекать из реальную выгоду.
> Это безусловно полезно, вопрос с чего начинать?С фон Неймановской
> архитектуры, а потом писать на ней интерпретатор LISP или
> с LISP-а, а потом писать на нем интерпретатор фон Неймановской
> машины?
С чего начинать - не знаю. Наверное РЕШАЮЩЕЙ роли это не играет. Тут дело в другом - надо достаточно быстро дать разные альтернативы, что бы человек не коснел в рамках одной парадигмы, а знал, что есть разные подходы.
← →
TRSteep © (2008-04-09 16:11) [15]LISP по крайней мере в нашем университете проходили
Думать как работает язык после паскаля получаеться очень даже не сразу...
← →
neanderthal (2008-04-09 18:45) [16]>
> Есть мнение что профессор Вирт писал Паскаль как раз под
> эти цели
"размять мозги"? паскалем-то?! LOL
← →
Alkid © (2008-04-09 19:10) [17]
> "размять мозги"? паскалем-то?! LOL
Паскалем - нет, не удастся.
Только если наряду с паскалем дать ещё какой-нибудь незамутнённый функциональный язык + Пролог.
← →
Mystic © (2008-04-09 20:37) [18]> "размять мозги"? паскалем-то?! LOL
Если программировать только на ФЯ, то любой императивный язык, в том числе и паскаль, будет разминать мозги: столько всего нового :)
← →
jack128_ (2008-04-10 00:07) [19]
> Тут дело в другом - надо достаточно быстро дать разные альтернативы,
> что бы человек не коснел в рамках одной парадигмы, а знал,
> что есть разные подходы.
один подход станет родным, а остальные он будет знать. Сколь угодно хорошо, но просто знать. И дай бог, что б родным стал подход, используемый мейнстримом..
← →
Игорь Шевченко © (2008-04-10 00:16) [20]А меня на фортране учили. Ничего страшного.
> не стоит ли начинать преподавание в профильных ВУЗах с более
> мощных и высокоуровневых языков, пусть даже и не мэйнстримовых?
> Того же Лиспа, например (или Схемы), что бы "размять мозги"
> студенту
Матаном надо мозги разминать. Или сопроматом.
← →
neanderthal (2008-04-10 01:31) [21]
> Mystic © (09.04.08 20:37) [18]
> > "размять мозги"? паскалем-то?! LOL
> Если программировать только на ФЯ, то любой императивный
> язык, в том числе и паскаль, будет разминать мозги: столько
> всего нового :)
Автор процитированого мною поста [4] явно не ФЯ имел ввиду. Просто у многих при виде слов "обучение программированию" в голове загорается лампочка "пиарим Оберон" и взводится флажок "Си - бууууу!!!". Что мне и бросилось в глаза в свете темы ветки.
← →
Германн © (2008-04-10 01:32) [22]
> Игорь Шевченко © (10.04.08 00:16) [20]
Матаном - да. Но не сопроматом.
Эвтаназия не должна быть мучительной! :)
← →
clickmaker © (2008-04-10 09:47) [23]
> Матаном надо мозги разминать. Или сопроматом
или "проектированием механизмов и приборов". Отличная разминка. Ползаешь по листу ватмана, рисуешь вектора моментов и смотришь, чтоб все сошлось. Почти как дебет с крЕдитом
← →
oldman © (2008-04-10 10:14) [24]
> Alkid © (09.04.08 12:11) [2]
> Язык, как естественный, так и программирования,
> навязывает нам абстракции, которыми мы мыслим, т.е. серьёзным
> образом определяет наш способ думать.
Имхо, язык - способ выражения мыслей, а не их навязывания...
Можно думать и на русском и на нерусском (при хорошей тренировке, разумеется).
Мысли при этом одинаковые.
← →
Alkid © (2008-04-10 10:45) [25]
> один подход станет родным, а остальные он будет знать. Сколь
> угодно хорошо, но просто знать. И дай бог, что б родным
> стал подход, используемый мейнстримом..
Согласен. Но знать про остальыне полезно. Как я уже на своём опыте убедился - успешно применять эти знания можно и программируя на мэнстриме.
> Матаном надо мозги разминать. Или сопроматом.
Не согласен. Да как прокачка именно абстрактной думалки это сгодится, но это слишком далеко от программирования, что бы дать непосредственный эффект.
> Имхо, язык - способ выражения мыслей, а не их навязывания.
> ..
> Можно думать и на русском и на нерусском (при хорошей тренировке,
> разумеется).
> Мысли при этом одинаковые.
Язык не навязывает мысли, он навязывает способ мышления. Применительно к программированию - любой тьюринг-полный язык может быть успешно применён для решения любой алгоритмической задачи, но разные задачи решаются на разных языка с разной степенью элегантности, причём именно за счёт разных абстракций, поддерживаемых языком.
Например, возвращаясь к моей работе: сейчас я пишу оптимизатор команд. Достаточно интересная и нетривиальная программа. Первый прототип я набросал в традиционном стиле, ООП, STL, контейнеры. В принципе получилось неплохо (по меркам ООП).
В последнее время я активно изучал новые для меня языки Lisp, Scheme, Prolog и их варианты. После анализа получившегося прототипа я увидел, что некоторые абстракции, которые я почерпнул из них могут очень пригодиться. В Частности продолжения (Scheme) и бэктрэкинг (Prolog). Плюс к этому я реорганизовал код, выразив его в виде набора чистых функций, оперирующих неизменяемыми структурами данных (т.е. порождающих их).
Вуаля! Код сократился в полтора раза, количество классов сократилось в два раза. И это при том, что продолжения и бэктрэкинг мне пришлось моделировать самому, в некотором специальном виде.
Так вот к чему я - если бы я не изучал эти "ненужные" немэйнстримовые языки, я был бы ограничен способах выражения своих мыслей.
← →
Игорь Шевченко © (2008-04-10 10:58) [26]Alkid © (10.04.08 10:45) [25]
> Не согласен. Да как прокачка именно абстрактной думалки
> это сгодится, но это слишком далеко от программирования,
> что бы дать непосредственный эффект.
Видишь ли, прокачка именно абстрактной думалки и дает способность к поиску изящных решений, вне зависимости от используемого языка программирования. Если нужно воспитать китайца, работающего методом copy|paste (а использование этого метода широко варьируется), тогда ему и думалка ни к чему - заставил вызубрить грамматику языка и вперед.
← →
jack128_ (2008-04-10 11:06) [27]
> Имхо, язык - способ выражения мыслей, а не их навязывания.
> ..
Новояз и ему подобные - не просто так придумываются ;-)
> В Частности продолжения (Scheme) и бэктрэкинг (Prolog).
хе, а мона чуть подробнее?? что то судя по описанию - в ОО языках это реализуется добовлением в класс методов SaveToSream/LoadFromStream -)
← →
DiamondShark © (2008-04-10 11:24) [28]
> > В Частности продолжения (Scheme) и бэктрэкинг (Prolog).
>
>
> хе, а мона чуть подробнее?? что то судя по описанию - в
> ОО языках это реализуется добовлением в класс методов SaveToSream/LoadFromStream
> -)
~~
о-0
\_/
День удался ;)
← →
jack128_ (2008-04-10 11:59) [29]
> День удался ;)
Я что то не то сморозил???
Ну вот цитата:
есть так называемый откат ("бэктрэкинг"). Откат, это когда программа возвращается к пройденному ранее состоянию, если доказательство очередной подцели закончилось неудачей. Во время отката программы отменяются все присваивания переменным, сделанные в ходе её исполнения, и переменные становятся снова неопределёнными. Обычно программа откатывается до первой пройденной развилки в алгоритме, чтобы попытаться пройти по другому пути. (с) http://www.cplire.ru/Lab144/start/r_intro.html
И ?? в delphi я бы так это сделал:
begin
SaveToStream(TmpStream);
if not TryProve then
LoadFromStream(TmpStream);
...
end;
PS - что такое логические языки предстовляю смутно :-)
← →
Alkid © (2008-04-10 12:09) [30]
> Видишь ли, прокачка именно абстрактной думалки и дает способность
> к поиску изящных решений, вне зависимости от используемого
> языка программирования. Если нужно воспитать китайца, работающего
> методом copy|paste (а использование этого метода широко
> варьируется), тогда ему и думалка ни к чему - заставил вызубрить
> грамматику языка и вперед.
Да, даёт. Но это слишком оторвано от нашей специфики. Да, математику изучать надо. Сопромат - не уверен. Но это ни в коем случае не заменит изучения нашей специфики, может только помочь - вот что я хочел сказать.
> хе, а мона чуть подробнее?? что то судя по описанию - в
> ОО языках это реализуется добовлением в класс методов SaveToSream/LoadFromStream
> -)
Эхм...
Нет, абсолютно неверно.
Вот первое что нашёл - английская википедия.
Продолжения:
http://en.wikipedia.org/wiki/Continuation
Бэктрэкинг:
http://en.wikipedia.org/wiki/Backtracking
← →
Alkid © (2008-04-10 12:14) [31]
> PS - что такое логические языки предстовляю смутно :-)
Советую этот пробел ликвидировать :)
Как реализовать НОРМАЛЬНЫЙ бэктрэкинг на Delphi/C++ в нормальном виде я не знаю. Даже если можно, это, наверное, будет непросто и неизящно. Я реализовывал его для ОЧЕНЬ СПЕЦИАЛЬНОГО случая, применяя продолжения (тоже сработанные на коленке), рекурсивные функции и immutable data structures (IDS).
В *принципе* вместо IDS можно использовать сериализацию/восстановление, но это, ИМХО, некрасиво и неоптимально.
← →
Игорь Шевченко © (2008-04-10 13:30) [32]Alkid © (10.04.08 12:09) [30]
> Да, даёт. Но это слишком оторвано от нашей специфики. Да,
> математику изучать надо. Сопромат - не уверен. Но это ни
> в коем случае не заменит изучения нашей специфики, может
> только помочь - вот что я хочел сказать.
Ты себе можешь представить, что существует масса неплохих программистов, которых либо вовсе не обучали программированию, либо обучали "не тому" программированию - другие языки, другие парадигмы и т.д.
?
Вот откуда они взялись, с прокачанными мозгами ?
Программирование - оно по-любому набор технических приемов, их можно тупо вдолбить, без всякого прокачивания мозгов, и получится программист, вполне, кстати, пользуясь вдолбленными приемами, будет писать среднего или ниже качества код.
Архангельского начитается и вперед :)
← →
Alkid © (2008-04-10 14:10) [33]
> Ты себе можешь представить, что существует масса неплохих
> программистов, которых либо вовсе не обучали программированию,
> либо обучали "не тому" программированию - другие языки,
> другие парадигмы и т.д.?
Самообразование ещё никто не отменял. Хотя, если честно, среди программистов с непрофильным образованием я видел больше плохих программистов, чем хороших.
> Программирование - оно по-любому набор технических приемов,
> их можно тупо вдолбить, без всякого прокачивания мозгов,
> и получится программист, вполне, кстати, пользуясь вдолбленными
> приемами, будет писать среднего или ниже качества код.
Это смотря ещё что считать программированием, а что - нет. Например, есть задача - написать оптимизатор очереди команд. К этому оптимизатору может быть несколько подходов: шаблонный оптимизатор, оптимизатор генерирующий минимальную достаточную последовательность команд, оптимизатор на базе генетических алгоритмов и т.п. Выбрать подход, конкретизировать его в рамках задачи, оценить побочные свойства подхода (его расширяемость, аддитивность, протухаемость, и т.п.), расписать модель классов (процедур/функций/модулей/предикатов и т.п.) их свойства, взаимодейтствия и потом всё это закодировать. Где здесь граница между приминением "набора технических приёмов", котрые можно "тупо вдолбить" и реальной работой инженера? Для меня всё это - программирование, начиная от формализации задачи, кончая заливкой файлов в систему контроля версий.
P.S.
Кстати, замечу между делом, что я в корне не согласен с позицией, что программирование - это нечто такое несерьёзное, чему легко научиться побочно основной (другой) специальности, и вообще сводится к "набору технических приёмов". Как правило так считают взрослые программисты, получившие техническое образование раньше и перепрофилировавшиеся потом в программистов, но по-прежнему считающие свою первую специальность чем-то, несоизмеримо более высоким и важным. Другой стороной этой медали являются стада молодёжи, считающие, что после прочтения книги "С++ для чайников" они уже круты и должны получать не меньше пары тысяч зелени.
Я повидал уже немало таких "программистов" и достаточно поковырялся в их коде, что бы сделать такие выводы. Программирование - это самостоятельная дисциплина, которую надо упорно изучать, что бы добиться в ней успехов. Это упорное изучение не может быть заменено в полной мере упорным изучением других дисциплин, или общим уровнем наглости (это про молодёжь). Я не говорю "математику на свалку", нет. Математика, как и многие другие дисциплины (в т.ч. и гуманитарные) программисту изучать ПОЛЕЗНО, они будут способствовать его развитию. Но они никак не могут заменить изучение своей специальности.
P.P.S. Хорошая статься, немного не по этой теме, но релевантная :)
http://www.williamspublishing.com/21-days.html
← →
Игорь Шевченко © (2008-04-10 14:26) [34]Alkid © (10.04.08 14:10) [33]
> Хотя, если честно, среди программистов с непрофильным образованием
> я видел больше плохих программистов, чем хороших.
А эта...тут такой момент - программированию раньше не обучали. А программисты потом получались. Заметь, получались и хорошие. Значит, не в профиле образования дело. Или под профильным образованием понимаем разное ?
> Кстати, замечу между делом, что я в корне не согласен с
> позицией, что программирование - это нечто такое несерьёзное,
> чему легко научиться побочно основной (другой) специальности,
> и вообще сводится к "набору технических приёмов".
Ты можешь быть не согласен, но от этого мало что изменится :) Ты полагаешь, надо в течение нескольких лет изучать циклы, ветвления и организацию подпрограмм, чтобы обучение было серьезным ? :)
> P.P.S. Хорошая статься, немного не по этой теме, но релевантная
> :)
> http://www.williamspublishing.com/21-days.html
Хорошая статья.
← →
oldman © (2008-04-10 14:58) [35]
> Игорь Шевченко ©
Но некоторые задачи более успешно решаются "в лоб" школьниками с задатками алгоритмизирования на QBasic for DOS, чем заумными дядьками с дипломами по SQL... И код у школьников более читабелен...
Особливо те задачи, где эффектность не влияет на эффективность.
Вы согласны?
← →
DiamondShark © (2008-04-10 15:00) [36]
> Но некоторые задачи более успешно решаются "в лоб" школьниками
> с задатками алгоритмизирования на QBasic for DOS, чем заумными
> дядьками с дипломами по SQL... И код у школьников более
> читабелен...
Можно пример такой задачи увидеть?
← →
oldman © (2008-04-10 15:04) [37]
> DiamondShark © (10.04.08 15:00) [36]
> Можно пример такой задачи увидеть?
Нет.
← →
Alkid © (2008-04-10 15:28) [38]
> А эта...тут такой момент - программированию раньше не обучали.
> А программисты потом получались. Заметь, получались и хорошие.
> Значит, не в профиле образования дело. Или под профильным
> образованием понимаем разное ?
Программированию обучали, пусть и не так, как сейчас. Мой отец, по образованию инженер, учился программировать в институте и потом применял свои знания на практике, но по образованию он - конструктор газодинамических систем, занимался в своё время проектированием систем охлаждения для лазеров.
Кроме того, понятие "хорошего программиста" со временем меняется. Как я могу судить, сейчас "хороших программистов" нигде не готовят. У нас не готовят. Я, интереса ради, изучал курс SICP из Массачусетского Технологического Института - это уже гораздо больше похоже на то, что надо.
Замечу, кстати, что я не отрицаю саму возможность для человека стать хорошим программистом без профильного образования. Безусловно, такие примеры есть. Но, лучше готовить людей по профильным программам обучения, а не готовить, скажем, людей по программе "нефтяные трубопроводы", в надежде, что из них получатся хорошие сантехники или проектировщики систем циркуляции летательных аппаратов.
> Ты можешь быть не согласен, но от этого мало что изменится
> :) Ты полагаешь, надо в течение нескольких лет изучать циклы,
> ветвления и организацию подпрограмм, чтобы обучение было
> серьезным ? :)
Циклы, ветвления и организация подпрограмм - это ДАЛЕКО не всё, что надо знать программисту. :) Но и это ещё не всё. Легко выучить синтаксис языка и понять основы, но научиться хорошо программировать - сложно. Приведу аналогию - правила шахмат обычный человек может усвоить за 10 минут, но это не значит, что он научился ИГРАТЬ в шахматы (т.е. эффективно применять разрешённые ходы фигур). Играть он может учиться потом всю жизнь, открывая для себя что-то новое.
← →
Alkid © (2008-04-10 15:29) [39]
> Но некоторые задачи более успешно решаются "в лоб" школьниками
> с задатками алгоритмизирования на QBasic for DOS, чем заумными
> дядьками с дипломами по SQL... И код у школьников более
> читабелен...
>
> Особливо те задачи, где эффектность не влияет на эффективность.
>
> Вы согласны?
"Навёрнутость" программы не равна её оптимальности.
← →
DiamondShark © (2008-04-10 15:33) [40]
> oldman © (10.04.08 15:04) [37]
>
> > DiamondShark © (10.04.08 15:00) [36]
> > Можно пример такой задачи увидеть?
>
> Нет.
Тогда цак надень и в пепелаце сиди.
← →
Alkid © (2008-04-10 16:01) [41]
> Тогда цак надень и в пепелаце сиди.
Господа, пожалуйста, не ругайтесь
:)
← →
Игорь Шевченко © (2008-04-10 16:42) [42]Alkid © (10.04.08 15:28) [38]
> Программированию обучали, пусть и не так, как сейчас. Мой
> отец, по образованию инженер, учился программировать в институте
> и потом применял свои знания на практике, но по образованию
> он - конструктор газодинамических систем
Ну да, я примерно о том же. Меня тоже учили в институте. На Фортране и недолго. Я не знаю сколько лет твоему отцу, но есть у меня мнение, что в определенный период программированию иначе просто не учили.
> Циклы, ветвления и организация подпрограмм - это ДАЛЕКО
> не всё, что надо знать программисту. :)
Да ну ? А что еще надо знать ? Просто интересно (с)
> Как я могу судить, сейчас "хороших программистов" нигде
> не готовят. У нас не готовят. Я, интереса ради, изучал
> курс SICP из Массачусетского Технологического Института
> - это уже гораздо больше похоже на то, что надо.
MIT тоже не всегда готовил "хроших программистов" - они сами собой зарождались. Тут такое дело, программирование - это очень молодая отрасль по сравнению с фундаментальными, скажем, науками, поэтому и накатанных шаблонов обучения не очень много. Я так думаю (с)
← →
Ega23 © (2008-04-10 16:49) [43]<OFFTOP>
Лёха, а поехали завтра в Дубну?
</OFFTOP>
← →
Alkid © (2008-04-10 18:21) [44]
> Лёха, а поехали завтра в Дубну?
Сорри, не могу :( С ремонтом куча проблем...
> Ну да, я примерно о том же. Меня тоже учили в институте.
> На Фортране и недолго. Я не знаю сколько лет твоему отцу,
> но есть у меня мнение, что в определенный период программированию
> иначе просто не учили.
Отцу моему 60 стукнуло во вторник :) Он ещё на БЭСМах и ЕСах работал. Потом уже на IBMистых машинах на Турбо Паскале рассчётыне программки писал. Подробностей особо не знаю.
> Да ну ? А что еще надо знать ? Просто интересно (с)
ИМХО:
1. Основные парадигмы программирования (императивное-структурное/ООП, функциональное, логическое). Уметь формализовать предметную область и задачу в рамках этих парадигм.
2. Принципы организации и ведения проектов. Понятие процесса разработки (касадного, итеративного). Понятие корпоративного стиля программирования, оформления исходного кода. Знать, что есть и зачем есть системы контроля версий, баг- и реквест-трэкинга, тестирования (автоматизированное тестировние, unit testing), билдовые системы. Знать, что есть Use Case, Test Case и т.п. Зачем делается Code Review. Какие виды документации бывают, когда они нужны (а когда мешают) и в каком объеме.
3. Графические нотации. (ERD, UML, IDEF0, DFD...).
4. Иметь хорошие познания в дискретке (тут пробел у многих, в т.ч. и у меня, активно устраняю), классических алгоритмах и структурах данных. Представлять себе трудности, опасности и выгоды параллельных программ, и как с ними бороться.
5. Иметь представление о том, как работает железо и операционные системы (причём, желательно, разные), сети. Иметь представление о том, как устроены те инструменты (языки) которыми он пользуется, КАК ИМЕННО реализуется то, что он там напрограммирует.
Сразу оговорюсь - это требования к к хорошему (точно не Junior :) ) программисту, который разрабатывает/принимает участие в разработке достаточно крупных продуктов с работой в команде. Если программист работает самопалом (фрилансер), то к этому ему ещё надо разбираться в юзабилити, общении с заказчиком, предметном анализе, и многом другом.
Наверное сюда можно ещё много чего добавить - писал навскидку те вещи, которыми пользуюсь либо ежедневно, либо часто. Порядок написания не связан с важностью.
← →
Alkid © (2008-04-10 18:23) [45]P.S. Забыл ещё указать, что надо не просто, а ХОРОШО знать ту парадигму, которая используется разработке. Т.е. если ООП (а этом щас мэйнстрим), то это паттерны, разные примочки и уловки и т.п.
← →
Игорь Шевченко © (2008-04-10 18:44) [46]Alkid © (10.04.08 18:21) [44]
> 1. Основные парадигмы программирования (императивное-структурное/ООП,
> функциональное, логическое). Уметь формализовать предметную
> область и задачу в рамках этих парадигм.
> 2. Принципы организации и ведения проектов. Понятие процесса
> разработки (касадного, итеративного). Понятие корпоративного
> стиля программирования, оформления исходного кода. Знать,
> что есть и зачем есть системы контроля версий, баг- и реквест-
> трэкинга, тестирования (автоматизированное тестировние,
> unit testing), билдовые системы. Знать, что есть Use Case,
> Test Case и т.п. Зачем делается Code Review. Какие виды
> документации бывают, когда они нужны (а когда мешают) и
> в каком объеме.
> 3. Графические нотации. (ERD, UML, IDEF0, DFD...).
> 4. Иметь хорошие познания в дискретке (тут пробел у многих,
> в т.ч. и у меня, активно устраняю), классических алгоритмах
> и структурах данных. Представлять себе трудности, опасности
> и выгоды параллельных программ, и как с ними бороться.
> 5. Иметь представление о том, как работает железо и операционные
> системы (причём, желательно, разные), сети. Иметь представление
> о том, как устроены те инструменты (языки) которыми он пользуется,
> КАК ИМЕННО реализуется то, что он там напрограммирует.
>
> Сразу оговорюсь - это требования к к хорошему (точно не
> Junior :) ) программисту, который разрабатывает/принимает
> участие в разработке достаточно крупных продуктов с работой
> в команде. Если программист работает самопалом (фрилансер),
> то к этому ему ещё надо разбираться в юзабилити, общении
> с заказчиком, предметном анализе, и многом другом.
> Наверное сюда можно ещё много чего добавить - писал навскидку
> те вещи, которыми пользуюсь либо ежедневно, либо часто.
> Порядок написания не связан с важностью.
А собственно, зачем это все программисту ? Сдается мне, что ты пытаешься сделать из программитста некоего универсала, который и жнец и швец и на дуде игрец. И более того, сдается мне, что совместить хорошее владение всем перечисленным в одном лице несколько сложновато.
На мой взгляд, достаточно умения алгоритмизировать. Ну и эти...циклы с ветвлениями. :)
А ООП, UML и прочие там ERD с IDEF0-ами...программировать и без них можно, и очень даже, поверь, неплохо.
Вон целый Unix а за ним и линукс напрограммировали без кучи этих страшных терминов. И ничего, вполне себе немаленькие и успешные проекты.
← →
Alkid © (2008-04-10 19:12) [47]
> А собственно, зачем это все программисту ? Сдается мне,
> что ты пытаешься сделать из программитста некоего универсала,
> который и жнец и швец и на дуде игрец. И более того, сдается
> мне, что совместить хорошее владение всем перечисленным
> в одном лице несколько сложновато.
Нет, не сложновато. Не сказать, что я этим всем владею, есть и пробелы, но я их достаточно методично закрыва и в весьма обозримом будущем закрою. Да, я тут описал программиста с достаточно развитыми способностями, задача которого - решать проблемы, которые решаются путём написания программ. Собственно говоря, мне этим и приходится заниматься.
Не знаю, может быть где-то и есть чудесные фирмы, где на программиста скидывают детализированные, полные и непротиворечивые и неизменяемые ТЗ, которые можно "просто алгоритмизировать с циклами и ветвлениями". Где программы пишутся сразу в конечном (и, заметьте, оптимальном!) варианте, никогда не модифицируются, не читаются другими людьми и сразу пишутся без ошибок. Где заказчики сразу, внятно и полно описывают что им надо.
Я таких фирм не видел :) А ведь большинство из того, что я перечислил - это технологии борьбы с подобными рисками проекта, а не программирование в чистом виде.
> На мой взгляд, достаточно умения алгоритмизировать. Ну и
> эти...циклы с ветвлениями. :)
Личная практика показывает, что недостаточно, иначе бы я сидел тихо-тихо и не размышлял бы об этом :) Может у Вас иная личная практика? :)
> А ООП, UML и прочие там ERD с IDEF0-ами...программировать
> и без них можно, и очень даже, поверь, неплохо.
>
> Вон целый Unix а за ним и линукс напрограммировали без кучи
> этих страшных терминов. И ничего, вполне себе немаленькие
> и успешные проекты.
Конечно можно, кто же спорит! :) Да и вообще можно в машкодах писать. Писали же! И хорошие вещи писали, получше, чем большинство из того, что щас написано :) С другой стороны, все эти ООП - это вещь ПОЛЕЗНАЯ. Позволяющая сэкономить силы, побороть сложность программы. А если относиться к ООП без фанатизма и сдобрить его хорошей порцией идей из других парадигм, то она может стать ещё полезнее.
Собственно я к тому, что из утверждения "можно обойтись без Х" не следует "Х - ненужная фигня". С этим Вы согласитесь? :)
Кроме того, я могу внятно объяснить, зачем нужно всё из того, что я перечислил, что будет, если от этого отказаться и как без этого жить. :) Я же тоже не родился с тем пониманием ситуации, которое щас излагаю. Например, я работал долго в конторе, где не слышали про систему контроля версий. И ведь жили же! Но хреноооовооо... Там же не слышали про нормальное тестирование и request tracking. В итоге всё было весьма бажным, фитчи и баги забыливали фиксить/делать. Там не слышали про корпоративный стиль к Code Review, в итоге развели дикую помойку в исходниках. Ну и так далее.
Багтрэкинг и контроль версий (как и другие технологии поддержки процесса) нужен и с ассемблером и с паскалем. Кстати, в Линуксе этих технологий весма есть.
← →
Simpson (2008-04-10 19:31) [48]DiamondShark © (10.04.08 15:00) [36]
10 print "hello world"
← →
Simpson (2008-04-10 19:38) [49]#ifdef ЮМОР
Alkid © (10.04.08 18:21) [44]
а как же знание SQL, DirectX, OpenGL, Геодезических расчетов, SSL, Html и других страшных слов?
#endif
← →
Simpson (2008-04-10 19:42) [50]Alkid © (10.04.08 19:12) [47]
Я вот например думал, что программист пишет программы, не программист не пишет программы, а страшные слова и абревиатуры их все больше, смысла в них все меньше.
← →
Игорь Шевченко © (2008-04-10 19:44) [51]Alkid © (10.04.08 19:12) [47]
> А ведь большинство из того, что я перечислил - это технологии
> борьбы с подобными рисками проекта, а не программирование
> в чистом виде.
Так это не программирование - это менеджмент. А для менеджера и так понятно, что лучше быть здоровым и богатым, чем бедным и больным.
> Не знаю, может быть где-то и есть чудесные фирмы, где на
> программиста скидывают детализированные, полные и непротиворечивые
> и неизменяемые ТЗ, которые можно "просто алгоритмизировать
> с циклами и ветвлениями".
> Я таких фирм не видел :)
Microsoft :)
> Личная практика показывает, что недостаточно, иначе бы я
> сидел тихо-тихо и не размышлял бы об этом :) Может у Вас
> иная личная практика? :)
Наверное иная - как-то было достаточно.
ООП и прочие страшные слова, это не серебряная пуля, а всего лишь инструменты, как и конкретный язык и конкретная среда разработки.
> Собственно я к тому, что из утверждения "можно обойтись
> без Х" не следует "Х - ненужная фигня". С этим Вы согласитесь?
> :)
Безусловно, я не призываю ничего отбрасывать. Я просто предлагаю несколько сузить перечень того, что перечислено, как необходимый багаж знаний именно программиста.
← →
Псалтырь (2008-04-11 00:51) [52]
> Матаном надо мозги разминать. Или сопроматом.
+100 :-*
← →
Псалтырь (2008-04-11 01:01) [53]Парадигмы... слова всякие... я видел людей, которык в легкую на олимпиадах писали парсеры (ибо по сути это банальная задача), но не могли мозг включить на кпрозенной задаче "4 красок", которую любой, прочитавший Гарднера, знал
← →
Marser © (2008-04-11 01:25) [54]
> DiamondShark © (09.04.08 12:47) [8]
>
>
> > а счеты? ))
>
> А у них не фоннеймановская архитектура.
Гарвардская? :-))
← →
Simpson © (2008-04-11 08:48) [55]Псалтырь (11.04.08 01:01) [53]
Ну тогда шейкерная сортировка вообще само то, про нее вообще мало кто слышал, в основном те кто Вирта читал, спрашиваеш как работает шейкерная сортировка и все не знают что сказать ))
← →
clickmaker © (2008-04-11 10:34) [56]
> как работает шейкерная сортировка и все не знают что сказать
> ))
встряхиваешь посильнее, как ляжет - так и ляжет )
← →
Alkid © (2008-04-11 10:44) [57]
> а как же знание SQL, DirectX, OpenGL, Геодезических расчетов,
> SSL, Html и других страшных слов?
:) Заметь,я не упоминал, что человек должен знать С++ или дельфи или, например, какую-то конкретную систему контроля версий. :)
> Я вот например думал, что программист пишет программы, не
> программист не пишет программы, а страшные слова и абревиатуры
> их все больше, смысла в них все меньше.
Писать программы можно по-разному :) Их можно писать хорошо или плохо. Делать это через попу (в организационном смысле) или не через попу. :)
> Так это не программирование - это менеджмент. А для менеджера
> и так понятно, что лучше быть здоровым и богатым, чем бедным
> и больным.
Нет, ЭТО - не менеджмент. Или по-вашему получается, например, что программист пишет код, отдаёт его менеджеру, а тот его сам должен загружать в систему контроля версий, ибо "не программистское это дело"? Или менеджер должен брать код прораммиста и писать для его юнит-тесты? Или менеджер должен брать код программиста и форматировать его согласно корпоративным правилам? :)
> Microsoft :)
Личный опыт? :)
> Наверное иная - как-то было достаточно.
> ООП и прочие страшные слова, это не серебряная пуля, а всего
> лишь инструменты, как и конкретный язык и конкретная среда
> разработки.
Заметье, я не писал, что программист обязан программировать, применяя ООП (или ФП, или ЛП). Я не писал, например, что он обязан знать именно ООП, именно С++, именно MSVS.NET 8.0, именно CVS, именно bugzilla, именно Windows, именно x86-архитектуру процессора. Я описывал общие категории, в которых он должен разбираться, и приводил примеры. Не конкретно CVS, а система контроля версий. Не ООП, а основные парадигмы программирования. Более того, чем больше он знает, тем лучше - его кругозор шире, мышление незашореннее, выбор инструмента под задачу богаче. Собственно, мою позицию тут можно свести к простой фразе "хороший программист должен очень знать много разных вещей, причём много разновидностей каждой вещи".
И спор-то у нас начался с того, что более полезно знать - сопромат или парадигмы программирования :)
← →
Игорь Шевченко © (2008-04-11 10:57) [58]Alkid © (11.04.08 10:44) [57]
> Нет, ЭТО - не менеджмент. Или по-вашему получается, например,
> что программист пишет код, отдаёт его менеджеру, а тот
> его сам должен загружать в систему контроля версий, ибо
> "не программистское это дело"? Или менеджер должен брать
> код прораммиста и писать для его юнит-тесты? Или менеджер
> должен брать код программиста и форматировать его согласно
> корпоративным правилам? :)
Обычно такие вещи делаются автоматически или прямым приказом по организации, что опять же менеджмент.
> Личный опыт? :)
Во-первых, Спольски популярно объясняет, даже с картинками, во-вторых, знакомые были - рассказывали.
> И спор-то у нас начался с того, что более полезно знать
> - сопромат или парадигмы программирования :)
Нет, спор начался с того, чем мозги тренировать. А не "более полезно знать".
← →
Simpson © (2008-04-11 11:08) [59]Alkid © (11.04.08 10:44) [57]
А как же Lisp и UML?
UML чем отличается от блок схем?
А блок схемами можно описать класический пример "человек снимает деньги с карточки в банкомате"?
Оказыватся инструментов море, но как их испльзует человек две большие разници,
для примеров далеко ходить не надо почитай форум "Начинающие" и "Игры".
Все таки не убедил для меня программист человек который пишет программы, а не человек который знает контроль версий, UML, сопромат, танцы с бубном вокруг сервера.
← →
clickmaker © (2008-04-11 11:14) [60]
> [44] Alkid © (10.04.08 18:21)
>
> 1. Основные парадигмы программирования (императивное
Если бы при приеме на работу к водителям относились так же, как к
программистам:
--
Вакансия: водитель.
Требования: профессиональные навыки управлении легковыми и грузовыми
автомобилями, троллейбусами, трамваями, поездами метрополитена и
фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном
ходу, боевыми машинами пехоты и современными легкими/средними танками,
находящимися на вооружении стран СHГ и HАТО. Hавыки раллийского и
экстремального вождения - обязательны, опыт управления болидами F1 -
приветствуется. Знания и опыт ремонта поршневых и роторных двигателей,
автоматических и ручных трансмиссий, систем зажигания, бортовых
компьютеров, антиблокировочных систем, навигационных систем (GPS) и
автомобильных аудиосистем ведущих производителей - обязательны. Опыт
проведения кузовных и окрасочных работ приветствуется. Претенденты
должны иметь сертификаты Mercedes, BMW, General Motors, а также справки
об участии в крупных международных ралли не более чем двухлетней
давности. Зарплата 15000-25000 руб., определяется по результатам
собеседования.
(c)
← →
Simpson © (2008-04-11 11:24) [61]Alkid © (11.04.08 10:44) [57]
Кстате в 1980-82 в свет вышел Unix IV прорадитель всех Unix систем, а вот они не знали не ООП не UML, может в этом причина поражения Unix?
Хотелось бы уточнить ты сейчас говориш про то что должен знать мега-Гуру или что должен згать программист вообще?
Если мега-Гуру то я не спорю он должен знать даже больше, а простому программисту достаточно писать программы.
Опять же в программировании уже было несколько революций когда опыт программирования на чем то оказывался бесполезен, что ты сам скажеш про свой список через 10 лет?
← →
Alkid © (2008-04-11 11:27) [62]
> Обычно такие вещи делаются автоматически или прямым приказом
> по организации, что опять же менеджмент.
В смысле "автоматически"? :) Программисты в этом участие должны принимать, а, значит, должны уметь.
> Во-первых, Спольски популярно объясняет, даже с картинками,
> во-вторых, знакомые были - рассказывали.
Читал я Спольски, пишет красиво. Однако есть инсайдерская информация, в которой есть и менее радужные описание того, что там происходит. :)
> Нет, спор начался с того, чем мозги тренировать. А не "более
> полезно знать".
Хе-хе :)
Так значит мы с Вами спорили о разных вещах! Я говорил не про общее развитие мозгов, а конкретно про кругозор в плане парадигм программирования. :)
Фразу "Размять мозг" я применил в следующем смысле: изначально расширить себе кругозор, что бы знать, что мэнстрим - это лишь частный случай, а не "истина в последней инстанции". *Только* в этом смысле. По-этому меня и удивили Ваши слова о сопромате. Это направление спора можно закрывать :)
> А как же Lisp и UML?
А что с ними не так? Первый - один из функциональных языков. Второе - одна из графических нотаций. В принципе, хорошие представители своих классов. Я думаю знать и то и другое полезно.
> А блок схемами можно описать класический пример "человек
> снимает деньги с карточки в банкомате"?
Можно.
> Оказыватся инструментов море, но как их испльзует человек
> две большие разници,
> для примеров далеко ходить не надо почитай форум "Начинающие"
> и "Игры".
Абсолютно согласен. См. аналогию с шахматами.
> Все таки не убедил для меня программист человек который
> пишет программы, а не человек который знает контроль версий,
> UML, сопромат, танцы с бубном вокруг сервера.
Про прыжки вокруг сервера - это лишь боковое ответвление тематики спора. Изначально речь шла о парадигмах программирования. Естественно я не считаю, что знающий CVS с багзиллой уже программист. Это, скорее, одмин.
Программист должен уметь писать программы. В этой боковой ветке я пытался показать, что программисту не хватает для работы знать "циклы с ветвлениями", что даже просто уметь составлять грамотные программы ему не достаточно - нужне сопутствующие навыки.
А по поводу сопромата - это са-а-авсем не я предложил ;)
← →
Alkid © (2008-04-11 11:30) [63]
> Кстате в 1980-82 в свет вышел Unix IV прорадитель всех Unix
> систем, а вот они не знали не ООП не UML, может в этом причина
> поражения Unix?
Поражение Unix? Какое-такое поражение? Пожалуйста, прочитай ВНИМАТЕЛЬНО, что я тут писал. Я не пропагандировал ООП и UML, как must-have. Я приводил их в качестве примеров.
> Хотелось бы уточнить ты сейчас говориш про то что должен
> знать мега-Гуру или что должен згать программист вообще?
Уровень Developer, переходящий в Senior Developer.
> Опять же в программировании уже было несколько революций
> когда опыт программирования на чем то оказывался бесполезен,
> что ты сам скажеш про свой список через 10 лет?
Хм. Изменения будут такие: Сам набор категорий изменится, но не сильно. Набор конкретных аббревиатур среди примеров поменяется сильно.
← →
Simpson © (2008-04-11 11:37) [64]Alkid © (11.04.08 11:30) [63]
>>Поражение Unix?
Да Досу и Виндусу, так уж получилось, что пользователи в этом вопросе правят балом.
Так бы и писал главный специалист, ведущий специалист, архитектор системы должен знать <твой текст>, а то программист, программист.
← →
Alkid © (2008-04-11 11:38) [65]
> Да Досу и Виндусу, так уж получилось, что пользователи в
> этом вопросе правят балом.
Ну, десктопы - это ещё не весь мир :)
> Так бы и писал главный специалист, ведущий специалист, архитектор
> системы должен знать <твой текст>, а то программист, программист.
Я писал "хороший программист".
← →
ekto (2008-04-11 11:50) [66]офтоп
а в 30 лет можно научиться программировать с 0?
← →
Alkid © (2008-04-11 11:53) [67]
> офтоп
> а в 30 лет можно научиться программировать с 0?
Можно. Только, ИМХО, как и с любым изучением чего угодно в 30 лет это сложнее начинать, чем лет в 20.
← →
Игорь Шевченко © (2008-04-11 11:59) [68]Alkid © (11.04.08 11:27) [62]
> В смысле "автоматически"? :) Программисты в этом участие
> должны принимать, а, значит, должны уметь.
Автоматически в смысле говорится, что есть некий набор действий, его можно выучить, можно записать в прошнурованную амбарную книгу, но выполнять обязательно. Например, хранить исходные тексты в системе контроля версий, описав действия, которые необходимо для этого хранения выполнить. Или форматировать текст так-то и так-то, а кто не форматирует, тех лишать премии.
А толку с таких знаний у программиста при смене корпоративного стандарта или системы контроля версий - ноль.
> Я говорил не про общее развитие мозгов, а конкретно про
> кругозор в плане парадигм программирования. :)
Я говорил про общее развитие мозгов, потому что чем они более развиты, тем с большей вероятностью из экземпляра выйдет хороший программист.
Я еще раз могу сказать, что программирование - дисциплина молодая, и мэйнстрим меняется несколько раз на протяжении трудовой деятельности отдельного экземпляра. А уж сколько раз меняется не-мэйнстрим - и говорить-то страшно.
← →
Alkid © (2008-04-11 12:10) [69]
> Автоматически в смысле говорится, что есть некий набор действий,
> его можно выучить, можно записать в прошнурованную амбарную
> книгу, но выполнять обязательно. Например, хранить исходные
> тексты в системе контроля версий, описав действия, которые
> необходимо для этого хранения выполнить. Или форматировать
> текст так-то и так-то, а кто не форматирует, тех лишать
> премии.
> А толку с таких знаний у программиста при смене корпоративного
> стандарта или системы контроля версий - ноль.
Я имел в виду несколько более высокий уровень проблемы. Про то, что программист должен понимать, что такое этот стиль, зачем он нужен и чего бывает, если его не придерживаться. А сколько пробелов где ставить и какие буквы каким регистром писать - это уже конкретика. То же и про остальные аспекты. Простое выучивание набора действий без понимания, зачем это надо, какие мотивы есть для произведения этих действий, часто приводит к плачевному результату.
> Я говорил про общее развитие мозгов, потому что чем они
> более развиты, тем с большей вероятностью из экземпляра
> выйдет хороший программист.
C этим согласен.
> Я еще раз могу сказать, что программирование - дисциплина
> молодая, и мэйнстрим меняется несколько раз на протяжении
> трудовой деятельности отдельного экземпляра. А уж сколько
> раз меняется не-мэйнстрим - и говорить-то страшно.
Ну... как Вам сказать... основные парадигмы и теоретическая база программирования была придумала уже давно и с тех пор не особо не менялась и не развивалась, а просто по разному комбинировалась в разных продуктах. Часто под влиянием моды и маркетинга. Я призываю изучать именно эту теоретическую базу, которая весьма стабильна. Алгоритм quicksort был придуман в 1960-ом году и до сих пор остаётся самым быстрым. Это изучение, естественно, надо комбинировать с изучением практических средств, ибо "даже маленькая практика стоит большой теории" :)
А разные модные джавы, плюсы, шарпы и дельфи - это действительно вещи приходящие и уходящие, с этим не спорю.
← →
Simpson © (2008-04-11 12:47) [70]Alkid © (11.04.08 12:10) [69]
>>Алгоритм quicksort был придуман в 1960-ом году и до сих пор остаётся самым быстрым.
Алгоритмы то развиваются, уже и на quicksort вплотную наступают.
Единственно что ооочень давно не меняется само определение алгоритма
← →
Alkid © (2008-04-11 12:50) [71]
> Алгоритмы то развиваются, уже и на quicksort вплотную наступают.
> Единственно что ооочень давно не меняется само определение
> алгоритма
Да не, понятно что они развиваются. Просто это развитие сродни развитию математики и имеет мало общего с метаниями мэнстрима.
← →
Simpson © (2008-04-11 12:54) [72]Alkid © (11.04.08 12:50) [71]
Data mining тоже недавно был исключительно научным эффектов, распознание образов тоже самое. Мейнстрим это просто мода.
← →
Alkid © (2008-04-11 13:27) [73]
> Data mining тоже недавно был исключительно научным эффектов,
> распознание образов тоже самое. Мейнстрим это просто мода.
Да кто же спорит? :)
← →
clickmaker © (2008-04-11 13:33) [74]
> Мейнстрим это просто мода.
мэинстрим - это попытка получать максимум бабла при минимуме затрат
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2008.05.25;
Скачать: [xml.tar.bz2];
Память: 0.77 MB
Время: 0.009 c