Парадокс Блаба и обучению программированию

← →
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?
Да Досу и Виндусу, так уж получилось, что пользователи в этом вопросе правят балом.

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

> Да Досу и Виндусу, так уж получилось, что пользователи в
> этом вопросе правят балом.

Ну, десктопы - это ещё не весь мир :)

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

Я писал "хороший программист".

← →
ekto (2008-04-11 11:50) [66]

офтоп
а в 30 лет можно научиться программировать с 0?

> офтоп
> а в 30 лет можно научиться программировать с 0?

Можно. Только, ИМХО, как и с любым изучением чего угодно в 30 лет это сложнее начинать, чем лет в 20.

Alkid © (11.04.08 11:27) [62]

> В смысле "автоматически"? :) Программисты в этом участие
> должны принимать, а, значит, должны уметь.

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

> Я говорил не про общее развитие мозгов, а конкретно про
> кругозор в плане парадигм программирования. :)

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

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

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

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

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

C этим согласен.

> Я еще раз могу сказать, что программирование - дисциплина
> молодая, и мэйнстрим меняется несколько раз на протяжении
> трудовой деятельности отдельного экземпляра. А уж сколько
> раз меняется не-мэйнстрим - и говорить-то страшно.

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

А разные модные джавы, плюсы, шарпы и дельфи - это действительно вещи приходящие и уходящие, с этим не спорю.

Alkid © (11.04.08 12:10) [69]

>>Алгоритм quicksort был придуман в 1960-ом году и до сих пор остаётся самым быстрым.

Алгоритмы то развиваются, уже и на quicksort вплотную наступают.

Единственно что ооочень давно не меняется само определение алгоритма

> Алгоритмы то развиваются, уже и на quicksort вплотную наступают.
> Единственно что ооочень давно не меняется само определение
> алгоритма

Да не, понятно что они развиваются. Просто это развитие сродни развитию математики и имеет мало общего с метаниями мэнстрима.

Alkid © (11.04.08 12:50) [71]
Data mining тоже недавно был исключительно научным эффектов, распознание образов тоже самое. Мейнстрим это просто мода.

> Data mining тоже недавно был исключительно научным эффектов,
> распознание образов тоже самое. Мейнстрим это просто мода.

Да кто же спорит? :)

> Мейнстрим это просто мода.

мэинстрим - это попытка получать максимум бабла при минимуме затрат

Парадокс Блаба и обучению программированию Найти похожие ветки