Re[9]: Многие думают, что математика и теория вообще не нужн - Компьютерные священные войны

Здравствуйте, mymuss, Вы писали:

M>Млин, как же меня достали программисты, не понимающие почему перебирать n^2 элементов массива хуже чем n. И я не могу этого обяснить, не доходит. Правда, влияние административными методами в последнее время дало положительные результаты. Но тоска зеленая не проходит...

свой человек! Я считаю, что есть два типа людей, которые в состоянии осознать необходимую связь между двоичной системой счисления (под этим подразумеваю любые "отдалённые" фундаменатльные знания) и адекватным восприятием ИТ-мира, и которые не в состоянии этого осознать, но у которых дошли руки до клавы

Я придерживаюсь идеологии старой школы: математика, алгоритмы, ассемблер — вот что должен знать каждый (хотя бы самые основы). Я начинал с программирования на ассемблере на Zilog Z80 и хорошо бы было, если бы КАЖДОГО современного тинейджера-программера на пару месяцев пересадить на Z80 и ему подобные процессоры с 48K ОЗУ.

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

Как меня достали горе писатели на перловке или пыхе, они пишут, а мне приходится отрубать весь сайт, который (порой один скриптик может отправить в коматозное состояние весь сервер) положил весь сервер с 500 сайтами. А когда горе хозяин быдло сайтика жалуется на меня со словами, мол мой программист говорит, что у него всё ОК в коде, мне приходится тратить часы, чтобы потом найти какой нибудь горе модуль или класс, который написан через анальное отверстие

Здравствуйте, MescalitoPeyot, Вы писали:

MP>Раз уж мы в КСВ, то без всяких имхо:
MP>Любому нормальному разработчику упомянутые выше Кнут, Хопкрофт и сотоварищи в полном объеме не нужны. Если нужны — значит это специфика достаточно узкой предметной области — геймдева с его аналиткой/линейкой, компиляторостроения с его алгебрами, языками, грамматиками и т. д. Конечно, "вообще не знаком с математикой" — это передергивание: что такое O(..) и конечный автомат знать лучше бы всем, но двадцать алгоритмов сортировки и отличие LL и LR не нужны практически никому. Что касается упорядочивания мозга, то SICP и тот же Haskell лично на меня оказали на порядок большее влияние чем алгоритмы, грамматики и прочие Кнуты с которыми все так почему-то носятся.

Об этом я и говорю, глупо пытаться охватить всё, надо просто быть фундаменталистом-практиком, который способен открыть книжку Кнута и найти нужный алгоритм, но не просто срисовать его как чурбан

, а ещё понять комбинаторные выкладки описывающие его суть, и понять почему он O(n*log_n), а не O(n). И всё это желательно понимать без тормозов, то есть быть подготовленным к восприятию такого материала прямо на рабочем месте.

MP>P.S.: Эх, если бы студентам вместо Кнута какой-нибудь Совершенный код (или иную болтологию сходной тематики) подсовывали, насколько бы мир стал прекраснее...

"Совершенный код" Макконнелла очень хорошая книжка и её стоит читать ДО Кнута. Совместно и в правильном порядке с определённой глубиной восприятия (не супер досконально, но и не супер поверхностно) эти книги очень хорошо способствуют выпрямлению рук

Здравствуйте, hal9000, Вы писали:

L>>Из перечисленного хардкорная математика нужна разве что в написании компиляторов, а вот по поводу остальных пунктов у меня есть сомнения по применимости математики.

H>Из этого утверждения следует, что следующие труды (несмотря на то, что это бестселлеры и написаны ИТ-гуру) абсолютно бесполезны для программистов и утверждения авторов этих трудов о том, что данные знания нужны для всех кто серьёзно изучает информатику, неправильны:

H>Серия книг Д.Э. Кнута "Исскуство программирования" и отдельный труд посвящённый математическому введению "Конкретная математика;
H>Алгоритмы: построение и анализ. Томас Х. Кормен, Чарльз И. Лейзерсон, Рональд Л. Ривест, Клиффорд Штайн;
H>Введение в теорию автоматов, языков и вычислений. Джон Хопкрофт, Раджив Мотвани, Джеффри Ульман;

H>и тому подобные книги.

H>

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

Здравствуйте, mymuss, Вы писали:

M>Я вот пишу говнонетленку из серии криворукого биллинга и веп-два-точка-ноль. Короче, однозначно в эти 95%.
M>Млин, как же меня достали программисты, не понимающие почему перебирать n^2 элементов массива хуже чем n. И я не могу этого обяснить, не доходит. Правда, влияние административными методами в последнее время дало положительные результаты. Но тоска зеленая не проходит...

Знание основ алгоритмов должно входить в компетенцию среднестатистического программиста.
Углубление в дискретку, теорию автоматов и т.д. с большой долей вероятности будет невостребованно впоследствии.

Здравствуйте, Lloyd, Вы писали:

L>Из перечисленного хардкорная математика нужна разве что в написании компиляторов, а вот по поводу остальных пунктов у меня есть сомнения по применимости математики.

Хардкорная, это какая?

Здравствуйте, hal9000, Вы писали:

H>Я придерживаюсь идеологии старой школы: математика, алгоритмы, ассемблер — вот что должен знать каждый (хотя бы самые основы). Я начинал с программирования на ассемблере на Zilog Z80 и хорошо бы было, если бы КАЖДОГО современного тинейджера-программера на пару месяцев пересадить на Z80 и ему подобные процессоры с 48K ОЗУ.
Всех будущих пилотов F1 обязавтельно на пару месяцев пересадить за руль запорожца

Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.
Мне как-то раз мое знание ассемблера стало боком. Я пытался на ассемблере писать для DSP процессора. Даже близкого к оптимальному коду там не получилось. И только через несколько месяцев писания на C и ковыряния получившегося ассемблерного кода я смог обогнать код, который генерит компилятор.
А попробуйте свои знания ассемблера применить для программирования вычислений на шейдерах.
К чему это все... К тому что лучше вместо знания конкретных ассемблеров понимать общие принципы работы процессоров (разных процессоров с разной архитектурой).

H>Сейчас пишут все кому не лень, современные высокоуровневые языки со всякими рюшечками готовыми классами позволяют программировать чуть ли не обезьянам

И это замечательно.

H>Как меня достали горе писатели на перловке или пыхе, они пишут, а мне приходится отрубать весь сайт, который (порой один скриптик может отправить в коматозное состояние весь сервер) положил весь сервер с 500 сайтами. А когда горе хозяин быдло сайтика жалуется на меня со словами, мол мой программист говорит, что у него всё ОК в коде, мне приходится тратить часы, чтобы потом найти какой нибудь горе модуль или класс, который написан через анальное отверстие

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

Здравствуйте, Sni4ok, Вы писали:
S>для них действительно не нужна- им поэтому и светит всю жизнь работать на дядечку и делать однотипные задачи.
Ага. А после смерти они попадут в ад.
Не объяснишь, как знание математики кореллирует с ведением собственного бизнеса (ака "не работать на дядечку")?

Здравствуйте, hal9000, Вы писали:
H>Сейчас пишут все кому не лень, современные высокоуровневые языки со всякими рюшечками готовыми классами позволяют программировать чуть ли не обезьянам

И снова ты говоришь так, будто бы высокоуровневые языки — это что-то плохоею

Здравствуйте, Mr.Cat, Вы писали:

S>>для них действительно не нужна- им поэтому и светит всю жизнь работать на дядечку и делать однотипные задачи.
MC>Ага. А после смерти они попадут в ад.
MC>Не объяснишь, как знание математики кореллирует с ведением собственного бизнеса (ака "не работать на дядечку")?

Ждите рассказов про то, как дискретка нехило прокачивает мозг, а это для ведения бузинесса ой как необходимо

Здравствуйте, gandjustas, Вы писали:

G>Всех будущих пилотов F1 обязавтельно на пару месяцев пересадить за руль запорожца

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

G>Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.

Знание ассемблера дает возможность понять как на самом деле работает процессор тот же.

G>Мне как-то раз мое знание ассемблера стало боком. Я пытался на ассемблере писать для DSP процессора. Даже близкого к оптимальному коду там не получилось. И только через несколько месяцев писания на C и ковыряния получившегося ассемблерного кода я смог обогнать код, который генерит компилятор.

У тебя был плохой преподаватель

G>К чему это все... К тому что лучше вместо знания конкретных ассемблеров понимать общие принципы работы процессоров (разных процессоров с разной архитектурой).

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

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

В индустрии ПО дело вобщем то не в низком уровне программистов, а том, что подготовка руководителей отсутствует как направление.

Здравствуйте, Lloyd, Вы писали:

L>Знание основ алгоритмов должно входить в компетенцию среднестатистического программиста.
L>Углубление в дискретку, теорию автоматов и т.д. с большой долей вероятности будет невостребованно впоследствии.

Это и есть основы алгоритмов.

Здравствуйте, hal9000, Вы писали:

H>Нужно ли понимание общих теоретических концепций для тру программирования?

Видишь ли какое дело. Математика, она разная бывает. То, что называют дискретной, прикладной математикой, computer science — оно, безусловно, очень нужно, если не индусякод плодить.
Но, справедливости ради, математика эта весьма специфична и довольно далеко отстоит от математики классической.

Здравствуйте, MescalitoPeyot, Вы писали:

MP>P.S.: Эх, если бы студентам вместо Кнута какой-нибудь Совершенный код (или иную болтологию сходной тематики) подсовывали, насколько бы мир стал прекраснее...

Не поможет. Чтобы понять "совершенный код" или, скажем, мейерса, нужно на собственной зопе прочувствовать проблемы промышленного программирования в полном масштабе, причем в проектах, где люди думают немножко дальше нескольких методов. Загляни в design — вполне вроде как состоявшиеся программисты упорно оспаривают даже базовые понятия дизайна. А стьюдент просто не поймет, зачем вообще такие сложности.

Здравствуйте, Геннадий Васильев, Вы писали:

L>>Из перечисленного хардкорная математика нужна разве что в написании компиляторов, а вот по поводу остальных пунктов у меня есть сомнения по применимости математики.

ГВ>Хардкорная, это какая?

Наверное, теория формальных грамматик

Здравствуйте, hal9000, Вы писали:

M>>Млин, как же меня достали программисты, не понимающие почему перебирать n^2 элементов массива хуже чем n. И я не могу этого обяснить, не доходит. Правда, влияние административными методами в последнее время дало положительные результаты. Но тоска зеленая не проходит...

Ага, десятилетиями готовили мега-гитлер-супер-пупер-спецалистов и как правило толку всегда мало. Нужны качественные руководящие кадры в индустрии ПО, тогда отвественность программисто вырастет и они таки будут знать что и как перебирать.

H>Сейчас пишут все кому не лень, современные высокоуровневые языки со всякими рюшечками готовыми классами позволяют программировать чуть ли не обезьянам

Это и есть прогресс — высокие технологии позволяют вовлечь в разработку слабообученые массы.

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

Но это при правильном. Что обычно редкость.

H>Как меня достали горе писатели на перловке или пыхе, они пишут, а мне приходится отрубать весь сайт, который (порой один скриптик может отправить в коматозное состояние весь сервер) положил весь сервер с 500 сайтами. А когда горе хозяин быдло сайтика жалуется на меня со словами, мол мой программист говорит, что у него всё ОК в коде, мне приходится тратить часы, чтобы потом найти какой нибудь горе модуль или класс, который написан через анальное отверстие

Не было бы пыха не было бы у тебя этого заработка. Тебе бы незачем было хостить сайты.

Здравствуйте, MescalitoPeyot, Вы писали:

MP>Любому нормальному разработчику упомянутые выше Кнут, Хопкрофт и сотоварищи в полном объеме не нужны. Если нужны — значит это специфика достаточно узкой предметной области — геймдева с его аналиткой/линейкой, компиляторостроения с его алгебрами, языками, грамматиками и т. д. Конечно, "вообще не знаком с математикой" — это передергивание: что такое O(..) и конечный автомат знать лучше бы всем, но двадцать алгоритмов сортировки и отличие LL и LR не нужны практически никому. Что касается упорядочивания мозга, то SICP и тот же Haskell лично на меня оказали на порядок большее влияние чем алгоритмы, грамматики и прочие Кнуты с которыми все так почему-то носятся.
MP>P.S.: Эх, если бы студентам вместо Кнута какой-нибудь Совершенный код (или иную болтологию сходной тематики) подсовывали, насколько бы мир стал прекраснее...

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

Это книга как раз такая, что новичкам еще без толку, а профессионалам уже без толку.

Здравствуйте, hal9000, Вы писали:

H>Как меня достали горе писатели на перловке или пыхе, они пишут, а мне приходится отрубать весь сайт, который (порой один скриптик может отправить в коматозное состояние весь сервер) положил весь сервер с 500 сайтами. А когда горе хозяин быдло сайтика жалуется на меня со словами, мол мой программист говорит, что у него всё ОК в коде, мне приходится тратить часы, чтобы потом найти какой нибудь горе модуль или класс, который написан через анальное отверстие

Неправильно сконфигурирован сервер ?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Ikemefula, Вы писали:

I>Это книга как раз такая, что новичкам еще без толку, а профессионалам уже без толку.

Не согласен , и новичкам Мега пгипер полезна и опытным лишней не будет

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, minorlogic, Вы писали:

I>>Это книга как раз такая, что новичкам еще без толку, а профессионалам уже без толку.

M>Не согласен , и новичкам Мега пгипер полезна и опытным лишней не будет

Что же там гипер-полезного, покажешь на примере ?

Здравствуйте, hal9000, Вы писали:

h> Как меня достали горе писатели на перловке или пыхе, они пишут, а мне приходится отрубать весь сайт, который (порой один скриптик может отправить в коматозное состояние весь сервер) положил весь сервер с 500 сайтами.

Так ты сервер настрой с нормальными ограничениями и ничего ложиться не будет

h> А когда горе хозяин быдло сайтика жалуется на меня со словами, мол мой программист говорит, что у него всё ОК в коде, мне приходится тратить часы, чтобы потом найти какой нибудь горе модуль или класс, который написан через анальное отверстие

Тебе за это платят или ты по собственной инициативе это делаешь?

avalon 1.0rc1 rev 247, zlib 1.2.3

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, minorlogic, Вы писали:

I>>>Это книга как раз такая, что новичкам еще без толку, а профессионалам уже без толку.

M>>Не согласен , и новичкам Мега пгипер полезна и опытным лишней не будет

I>Что же там гипер-полезного, покажешь на примере ?

Например формализованные схемы анализа функции. 25 вопросов на которые надо ответить для ответа на вопрос что дизайн класса не плохой (заметь не хороший а просто не плохой)

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Sni4ok, Вы писали:

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

На дядечку? Я предпочитаю работать на тетечку, такую симпатичную и милую.

Смею тебя заверить, Билл Гейтс не был этаким гением программирования.

RO>И в формочках можно ухитриться применить алгоритм Шлемиэля. Например, при реализации какого-нибудь перетаскивания элементов.

Только поддерживать и модифировать этот код потом нормальным людям как?

Здравствуйте, minorlogic, Вы писали:

M>>>Не согласен , и новичкам Мега пгипер полезна и опытным лишней не будет

I>>Что же там гипер-полезного, покажешь на примере ?

M>Например формализованные схемы анализа функции. 25 вопросов на которые надо ответить для ответа на вопрос что дизайн класса не плохой (заметь не хороший а просто не плохой)

Ага, так вот всё просто, ответил на 25 вопросов и получил мега-ответ

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

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

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

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

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

Здравствуйте, hal9000, Вы писали:

H>ИМХО: если человек знаком с основами дискретной математики (на самом деле любой математики), то его программы будут качественней, чем у человека который вообще не знаком с математикой.

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

Здравствуйте, gandjustas, Вы писали:

G>А попробуйте свои знания ассемблера применить для программирования вычислений на шейдерах.

Я применял, в чем проблемы

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>Всех будущих пилотов F1 обязавтельно на пару месяцев пересадить за руль запорожца

I>Ассемблер тебе все равно придется выучить. Правда уровень ассемблера тоже растет со временем, как и уровень промышленных языков.

Что значит выучить ассемблер? Запомнить все команды cpu\fpu\mmx\sse? А может еще запомнить характеристики количества микроопераций для них всех?
Гораздо лучше знать про архитектуру процессора, кеши, понимать что такое SIMD и зачем оно нужно, понимать что такое арифхетика с переполнением и с насыщением, знать как осуществляется работа с переферией.
А плотно изучать ассемблерные команды нужно только когда задача касается программирования на асме.

G>>Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.
I>Знание ассемблера дает возможность понять как на самом деле работает процессор тот же.
С чего бы? Изучив справочник команд придет понимание? Вряд-ли.

G>>Мне как-то раз мое знание ассемблера стало боком. Я пытался на ассемблере писать для DSP процессора. Даже близкого к оптимальному коду там не получилось. И только через несколько месяцев писания на C и ковыряния получившегося ассемблерного кода я смог обогнать код, который генерит компилятор.
I>У тебя был плохой преподаватель

У меня его вообще не было.

G>>К чему это все... К тому что лучше вместо знания конкретных ассемблеров понимать общие принципы работы процессоров (разных процессоров с разной архитектурой).
I>Для этого и нужен ассемблер, только незачем учить все ассемблеры существующие в природе.
Не нужен, см выше.
Еще раз: знание ассемблера под x86 мне не разу не помогло эффективно использовать ассемблер для другого процессора.

Здравствуйте, Ikemefula, Вы писали:

M>>Например формализованные схемы анализа функции. 25 вопросов на которые надо ответить для ответа на вопрос что дизайн класса не плохой (заметь не хороший а просто не плохой)

I>Ага, так вот всё просто, ответил на 25 вопросов и получил мега-ответ

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Lloyd, Вы писали:

L>Нет, из этого не следует тот вывод, который вы сделали.

Почему не следует?

Здравствуйте, Ikemefula, Вы писали:

I>Это книга как раз такая, что новичкам еще без толку, а профессионалам уже без толку.

Не согласен, так как будучи новичком прочитав _отдельные_ главы этой книги стал намного лучше писать. Там вводятся такие понятия как:

1) правильно оформлять код, чтобы был читабельным
2) делать рефакторинг сложных циклов, чтобы они легко читались тебе и были легко прочитаны другими
3) делать рефакторинг сложных if конструкций, чтобы они легко читались тебе и были легко прочитаны другими
4) делать читабельные имена переменных и функций
5) правильно группировать части кода, например, временную переменную вводить рядом с циклом, где она используется
6) писать самодостаточный интерфейс классов

В книге "Совершенный код" всё это излагается на пальцах для новичков!!!

Но главы посвящённые тонкостям промышленного программирования я не стал читать, так как будучи новичком не воспринимал эту информацию.

Здравствуйте, ylem, Вы писали:

RO>>И в формочках можно ухитриться применить алгоритм Шлемиэля. Например, при реализации какого-нибудь перетаскивания элементов.

Y>Только поддерживать и модифировать этот код потом нормальным людям как?

http://www.joelonsoftware.com/articles/fog0000000319.html

Ты меня не совсем верно понял. Всех будущих пилотов F1 обязательно на пару месяцев заставить ездить БЕЗ автоматической системы корректировки на F1 (у лучшие гонщики любяит управлять машиной своими руками, хотя когда надо включают автоматическое управление F1).

G>Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.
G>Мне как-то раз мое знание ассемблера стало боком. Я пытался на ассемблере писать для DSP процессора. Даже близкого к оптимальному коду там не получилось. И только через несколько месяцев писания на C и ковыряния получившегося ассемблерного кода я смог обогнать код, который генерит компилятор.
G>А попробуйте свои знания ассемблера применить для программирования вычислений на шейдерах.
G>К чему это все... К тому что лучше вместо знания конкретных ассемблеров понимать общие принципы работы процессоров (разных процессоров с разной архитектурой).

Знание ассемблера, точнее даже не знание ассемблера, а его понимание, понимание принципов и основ ОЧЕНЬ помогает. Более того иногда очень полезно (особенно на стадии изучения C) понимать и видеть как компилятор языка C генерирует некоторые конструкции на ассемблере. Например, в некоторых особенно сложных задачках из http://www.gowrikumar.com/c/ просмотр сгенерированного компилятором С ассемблерного кода открывает в тебе более глубокое понимание языка.

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

G>>Всех будущих пилотов F1 обязавтельно на пару месяцев пересадить за руль запорожца

H>Ты меня не совсем верно понял. Всех будущих пилотов F1 обязательно на пару месяцев заставить ездить БЕЗ автоматической системы корректировки на F1 (у лучшие гонщики любяит управлять машиной своими руками, хотя когда надо включают автоматическое управление F1).

Какое еще автоматическое управление на F1

Здравствуйте, Mr.Cat, Вы писали:

MC>Не объяснишь, как знание математики кореллирует с ведением собственного бизнеса (ака "не работать на дядечку")?

Когда чел не креативен и у него нет фундаментальных знаний ИТ (и в их числе математика), то он может лепить только формочки, а это значит, что он будет всю жизнь работать делая рутину в самой низкой иерархии программистов. А возможно даже откроет, когда нибудь собственную быдло конторку по лепки формочек, если его интересуют ТОЛЬКО деньги, а программирование для него ТОЛЬКО способ их срубить с других (с заказчиков), то всё хорошо. Но это уже не тру программист.

Когда чел креативен и у него есть фундаметальные знания и практический опыт, то он сможет продвинутся по иерархии ИТ в качестве специалиста и будет очень ценен. В будущем сможет возглавить действительно КАЧЕСТВЕННЫЙ И ИНТЕРЕСНЫЙ проект.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Видишь ли какое дело. Математика, она разная бывает. То, что называют дискретной, прикладной математикой, computer science — оно, безусловно, очень нужно, если не индусякод плодить.
НС>Но, справедливости ради, математика эта весьма специфична и довольно далеко отстоит от математики классической.

+1 Да, я и не говорю быть супер продвинутым математиком, но чтение Кнута и аналогичных ему трудов даёт очень хорошие прикладные (_именно в ИТ_) математические знания.

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

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

Тут кто-то в этой ветке не понял, почему хуже n^2 переборов, чем n. Ёлки палки, когда буду руководителем

на собеседовании этот вопрос первым буду задавать. Если чел не может параболу от прямой отличить, то это АХТУНГ!!!

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, alpha21264, Вы писали:

A>>Для тех, кто формочки клепает — не нужна.

RO>И в формочках можно ухитриться применить алгоритм Шлемиэля. Например, при реализации какого-нибудь перетаскивания элементов.

Ну вот — стало быть и им нужна

Здравствуйте, _d_m_, Вы писали:

___>Какое еще автоматическое управление на F1

http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D0%BF%D1%80%D0%BE%D0%B1%D1%83%D0%BA%D1%81%D0%BE%D0%B2%D0%BE%D1%87%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0

На счёт формулы 1 ошибся, так как "Позднее стала широко применяться в обычных серийных машинах, а в 2008 году была запрещена в Формуле-1.", но суть не меняется. Например, в одном из многочисленных выпусков Top Gear ведущий сначала обсирал машину, как он обычно любит это делать, а потом отключил подобную систему (я не специалист, но насколько знаю, там несколько видов автоматического управления) и показал настоящие возможности машины. Вообщем поищи Top Gear в youtube.

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, Lloyd, Вы писали:

L>>Из перечисленного хардкорная математика нужна разве что в написании компиляторов, а вот по поводу остальных пунктов у меня есть сомнения по применимости математики.

H>Из этого утверждения следует, что следующие труды (несмотря на то, что это бестселлеры и написаны ИТ-гуру) абсолютно бесполезны для программистов и утверждения авторов этих трудов о том, что данные знания нужны для всех кто серьёзно изучает информатику, неправильны:

H>Серия книг Д.Э. Кнута "Исскуство программирования" и отдельный труд посвящённый математическому введению "Конкретная математика;
H>Алгоритмы: построение и анализ. Томас Х. Кормен, Чарльз И. Лейзерсон, Рональд Л. Ривест, Клиффорд Штайн;
H>Введение в теорию автоматов, языков и вычислений. Джон Хопкрофт, Раджив Мотвани, Джеффри Ульман;

H>и тому подобные книги.
вот уж 9-ый год программлю. За это время первые три года использовал какие-то математические выкладки вроде временной сложности алгоритма поиска или сортировки. Реально нужно было. А вот последние годы просто не сталкиваюсь с подобными задачами. Бывает такое: есть некая процедура (не в смысле процедуры языка, а последовательность определенных действий и реакций). Хочется ее оптимизировать. А потом смотришь — эта процедура будет работать может раз за сутки, или реже. И зачем тратить время на оптимизацию тогда? Уж лучше сделать проще и понятнее для того, кто будет продолжать работу.

Сам любитель оптимизаций, но вот...

Здравствуйте, mymuss, Вы писали:

M>Здравствуйте, Mr.Cat, Вы писали:

M>>>Млин, как же меня достали программисты, не понимающие почему перебирать n^2 элементов массива хуже чем n.
MC>>Действительно, а почему?

M>Тормозит сильно.

1) именно в этом месте тормозит?
2) сколько процентов времени проводит программа в этом месте?
... ну и прочее.

Здравствуйте, hal9000, Вы писали:

H>Тут кто-то в этой ветке не понял, почему хуже n^2 переборов, чем n.

Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

Здравствуйте, hal9000, Вы писали:

I>>Это книга как раз такая, что новичкам еще без толку, а профессионалам уже без толку.

H>Не согласен, так как будучи новичком прочитав _отдельные_ главы этой книги стал намного лучше писать. Там вводятся такие понятия как:

H>1) правильно оформлять код, чтобы был читабельным
H>2) делать рефакторинг сложных циклов, чтобы они легко читались тебе и были легко прочитаны другими
H>3) делать рефакторинг сложных if конструкций, чтобы они легко читались тебе и были легко прочитаны другими
H>4) делать читабельные имена переменных и функций
H>5) правильно группировать части кода, например, временную переменную вводить рядом с циклом, где она используется
H>6) писать самодостаточный интерфейс классов

для этих пунктов не надо читать Совершенный код.

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

п. 1. Я не единожды объяснял и показывал, но читабельность он понимает не так как я.
Ему хорошо читать — он считает это хорошей читабельностью.
Что бы научить этой читабельности, нужно заставить человека читать этот самый код. И одного-двух прмеров или объяснений тут недостаточно.
Мне повезло, что его метод был слишком большой. Через неделю он забыл что и как там происходит и сразу вылезла путаница.

Но повторюсь — читабельность может обеспечить только тот, кто читает вагоны чужого кода, а не тот кро прочитал какую то книжку.

п. 2 Рефакторинг сложных циклов. Что значт сложный цикл ? Для кого сложный ?
Студент пишет сложную логику там где она совершенно не нужна. Обычно это значит, что он пишет так — придумал кусочек, написал. попробовал, не работает, придумал, еще написал.
Сразу продумать целиком весь вариант он еще не умеет, это даётся годами тренировок — написание, отладка, переделка своего и чужого кода.
Книжкой это заменить нельзя. Мозг устроен вобщем то прмерно как и мышцы(аналогия конечно) — тренировки помноженные на время дают эффект (более подробно про это в теори ВПФ). Время можно уменьшить за счет увеличения интесивности тренировок, правильной нагрузки и правильного отдыха.
И обязательно нужен разбор полетов. Точно так же и с мышцами — что бы выполнить сед, нужно хорошо прокачать тягу, иначе во время седа спина будет проседать. Для мозгов нужно найти якорь который мешает понять или продвинуться дальше. Это только у ИТ и ВладД2 все просто

другим надо работать что бы подняться на следущий уровень Простоты.

п.3 здесь тоже самое что и с п.2. все ветвления и циклы студент понимает как кусочки if else и тд.( Hence the expression — императивный программист.) Опытный девлопер цикл со всеми потрохами видит одной сущностью/явлением.
И книжкой это опять же не исправить, масштаб мышления это результат усилий помноженных на время помноженных на понижающий коэффициэнт якоря(ей).

п.4. Похоже на п.1, но немного другое. Вот на примере — что такое rdel и ldel ? Сначала это были узлы — rdel значит узел для удаления, который был справа у узла предка, а ldel — слева. Потом в ходе написания кода rdel и ldel стали указывать на поддеревья а не узлы для удаления. Вроде бы тоже самое но чел привык к названиям и они стали для него нормой.
И книгами здесь не лечится — спустя неделю я просто попросил объяснть программу (разбор полётв) и как раз выяснилось, что чел ничего в ней не понимает и путается в rdel и ldel. Переименовали все что могли и сразу половина текста в 200 строк стала понятной даже мне

п.6 — про классы еще ничего нет, зато есть набор методов, у которых в параметрах может быть черт знает что.
Уже на этом уровне случается хаос, который не передать словами — нужно учить как правильно объявлять методы.
А это значт, сначала нужно научить как правильно выполнить композицию/декомпозицию — и опять это практика/практика/практика + разборы полётов.
в коде например может быть трижды встречаться мега-цикл и новичек не догадается выбросить его за пределы метода или в коде ему окажется очень удобно выводить строчки на экран прямо в методе для удаления.

Мега-авторы мега книг пишут так — вот в в методе есть сущность_а и сущность_б — раз эни разные, то логично и разделить на части.
Опаньки — сразу скормил новичку готовое решение, "сэкономив" время обучения.
+на возможные возражения пишется такое "допустим надо сделать а, б, в и г, что дальше ?" Опаньки — и тут скармиливается готовое решения — автор указывает, что метод с двумя сущностями создаст проблемы.

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

Студента нужно этому учить — увидел, что в коде мешанина, нужно предложить доработать программу для случаев а,б, в и г. Пусть работает а за копипейст поставить двойку.

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

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

Но вообще программа работает на уровне "показать преподавателю". На потоке только пару человек осилили эту лабу(деревья).


...
g_pRoot = DeleteInfo(find_tree,input);
...


MyTree* DeleteInfo(MyData Info,int i_info)
{
 MyTree* del;
 MyTree* ancestor_del=NULL;
 MyTree* rdel;
 MyTree* ldel;
 MyTree* place;
 bool yes_to_go = true;
 bool yes;

 del =g_pRoot;
 ancestor_del = NULL;

 //поиск удаляемого элемента
 while (del != NULL && del -> Info.key != i_info)
 {
  ancestor_del = del;

  if (del->Info.key > i_info)
  {
   del = del->left;
  }

  else
  {
   del = del->right;
  }
 }

 if (del == NULL)
  {
   ShowMessage ( "Element does not exist!");
   return g_pRoot;
  }

 rdel = del->right;
 ldel = del->left;

//ниодного листа

 if((ldel == NULL) && (rdel == NULL))
 {
     //если захотели удалить вершину
     if(del == g_pRoot)
     {
      ShowMessage("MyTree root is deleted!");
      Form1->Memo1->Clear();
      delete g_pRoot;
      return NULL;
     }

     if((ancestor_del->right) == (del))
     {
      ancestor_del->right = NULL;
     }

     else
     {
       ancestor_del->left = NULL;
     }
    yes_to_go = false;
 }

 //только правый или левый
 else
 {

 //левый
   if(rdel == NULL)
   {   //если захотели удалить вершину
       if(del->Info.key == g_pRoot->Info.key)
       {
        ShowMessage("MyTree old root is deleted!\n Here is a new one!");
        g_pRoot = ldel;
        Form1->Memo1->Clear();
        ReviewMyTree(g_pRoot,0);
        Form1->Memo1->Lines->Add("-=Новая вершина=-!");
        return g_pRoot;
       }

       if(rdel == NULL && (ancestor_del->Info.key > del->Info.key))
       {
        ancestor_del->left = ldel;
       }

       else
       {
        ancestor_del->right = ldel;
       }

    yes_to_go = false;
   }

 //правый
   if(ldel == NULL)
   {   //если захлтели удалить вершину
       if(del->Info.key == g_pRoot->Info.key)
       {
        ShowMessage("MyTree old root is deleted!\n Here is a new one!");
        g_pRoot = rdel;
        Form1->Memo1->Clear();
        ReviewMyTree(g_pRoot,0);
        Form1->Memo1->Lines->Add("-=Новая вершина=-!");
        return g_pRoot;
       }

       if(ldel == NULL && (ancestor_del->Info.key > del->Info.key))
       {
        ancestor_del->left = rdel;
       }

       else
       {
        ancestor_del->right = rdel;
       }
      yes_to_go = false;
   }

 }

 //левый и правый
 if(yes_to_go)
 {
   //если зазхотели удалить вершину
   if(del->Info.key == g_pRoot->Info.key)
   {
    ShowMessage("MyTree old root is deleted!\n Here is a new one!");
    g_pRoot = rdel;

    if(rdel->left == NULL)
    {
     rdel->left = ldel;
    }

    else
    {
     place = rdel->left;
     while(place->left != NULL)
     {
      place = place->left;
     }
     place->left = ldel;
    }

    Form1->Memo1->Clear();
    ReviewMyTree(g_pRoot,0);
    Form1->Memo1->Lines->Add("-=Новая вершина=-!");
    return g_pRoot;
   }

  if(ancestor_del->Info.key > del->Info.key)
  {
   ancestor_del->left = rdel;
   place = rdel;

   //ищем самый левый в правом поддереве удаляемого элемента
   if(place->left == NULL)
   {
    rdel->left = ldel;
   }

   else
   {
    place = rdel->left;
    while(place->left != NULL)
    {
     place = place->left;
    }
    place->left = ldel;
   }

  }
  //если предок меньше,чем удаляемый
  else
  {
   ancestor_del->right = rdel;
   place = rdel;

   //ищем самый левый в правом поддереве удаляемого элемента
   if(place->left == NULL)
   {
    rdel->left = ldel;
   }
   else
   {
    place = rdel->left;
    while(place->left != NULL)
    {
     place = place->left;
    }
    place->left = ldel;
   }

  }

 }
  delete del;
  return g_pRoot;
}

Здравствуйте, minorlogic, Вы писали:

M>>>Например формализованные схемы анализа функции. 25 вопросов на которые надо ответить для ответа на вопрос что дизайн класса не плохой (заметь не хороший а просто не плохой)

I>>Ага, так вот всё просто, ответил на 25 вопросов и получил мега-ответ

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

Время на эти 25 вопросв понадобится примерно на порядок больше, чем профессионалу а ответы у новичка скорее всего будут еще и неправильные.

Здравствуйте, gandjustas, Вы писали:

G>Что значит выучить ассемблер? Запомнить все команды cpu\fpu\mmx\sse? А может еще запомнить характеристики количества микроопераций для них всех?
G>Гораздо лучше знать про архитектуру процессора, кеши, понимать что такое SIMD и зачем оно нужно, понимать что такое арифхетика с переполнением и с насыщением, знать как осуществляется работа с переферией.

Ассемблер это язык такой. Атомарными операциями делаются всякие чудеса.

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

До периферии просто не доберёшься, потому что здесь как правило надо многие вещи уметь на раз, иначе из ошибки в пол-бита периферия откажется с тобой контактировать.

G>>>Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.
I>>Знание ассемблера дает возможность понять как на самом деле работает процессор тот же.
G>С чего бы? Изучив справочник команд придет понимание? Вряд-ли.

Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.

I>>У тебя был плохой преподаватель

G>У меня его вообще не было.

Ну да, самообучение оно как и самолечение, пробуют все, выживают единицы.

I>>Для этого и нужен ассемблер, только незачем учить все ассемблеры существующие в природе.
G>Не нужен, см выше.
G>Еще раз: знание ассемблера под x86 мне не разу не помогло эффективно использовать ассемблер для другого процессора.

Тебя испугал сигнальный микропросцессор что ли ?

Но сильно думаю, это потому что ассеблера ты и не знал вобщем то.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>Что значит выучить ассемблер? Запомнить все команды cpu\fpu\mmx\sse? А может еще запомнить характеристики количества микроопераций для них всех?
G>>Гораздо лучше знать про архитектуру процессора, кеши, понимать что такое SIMD и зачем оно нужно, понимать что такое арифхетика с переполнением и с насыщением, знать как осуществляется работа с переферией.

I>Ассемблер это язык такой. Атомарными операциями делаются всякие чудеса.
Глубокая мысль прямол скажем.

I>Без знания ассемблера ты просто не сможешь пощупать кеш, вряд ли поймешь что такое SIMD, а про арифметику с переполнением можешь просто забыть.
С чего бы? я многократно рассказывал людям про архитектуру процессоров без упоминания ассемблерных команд.

G>>>>Ты за "знанием ассемблера" на самом деле прячишь знание того как работает компьютер с определенной архитектурой.
I>>>Знание ассемблера дает возможность понять как на самом деле работает процессор тот же.
G>>С чего бы? Изучив справочник команд придет понимание? Вряд-ли.

I>Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.
Ты выше написал что ассемблер — это язык. Язык определяется синтаксисом и семантикой. И то и другое можжно в справочнике команд найти.

I>>>Для этого и нужен ассемблер, только незачем учить все ассемблеры существующие в природе.
G>>Не нужен, см выше.
G>>Еще раз: знание ассемблера под x86 мне не разу не помогло эффективно использовать ассемблер для другого процессора.

I>Тебя испугал сигнальный микропросцессор что ли ?

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

I>Но сильно думаю, это потому что ассеблера ты и не знал вобщем то.
Да придумывать недостатки оппоненту — это круто.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

"Не всегда хуже" это неинтересно. А "лучше" бывает?

Здравствуйте, mymuss, Вы писали:

НС>>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

M>"Не всегда хуже" это неинтересно. А "лучше" бывает?

Бывает. Все зависит от абсолютной величины константы и величины n.

Здравствуйте, gandjustas, Вы писали:

I>>Без знания ассемблера ты просто не сможешь пощупать кеш, вряд ли поймешь что такое SIMD, а про арифметику с переполнением можешь просто забыть.
G>С чего бы? я многократно рассказывал людям про архитектуру процессоров без упоминания ассемблерных команд.

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

Это по твоему то же самое что и пощупать ?

I>>Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.
G>Ты выше написал что ассемблер — это язык. Язык определяется синтаксисом и семантикой. И то и другое можжно в справочнике команд найти.

Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.

;/*
ideal
p286n
model small,C
dataseg
extrn VideoSeg:word
extrn ScrWidth:byte
extrn ScrDoubleWidth:word
extrn CurVidPage:word
codeseg

extrn vidoffset:near

public wintobuffer
proc wintobuffer

ARG @@sx:byte,@@sy:byte,\
@@ex:byte,@@ey:byte,\
@@buf:dataptr

USES si,di,ds

mov dh,[@@sy]
mov dl,[@@sx]
call vidoffset
mov bx,di
mov si,di
xor cx,cx
mov cl,[@@ey]
sub cl,dh
inc cx
mov dh,cl
mov cl,[@@ex]
sub cl,dl
inc cx
mov dl,cl
mov di,[@@buf]
mov [di],dx
inc di
inc di
mov ax,ds
mov es,ax
mov ds,[VideoSeg]
cld

@@nx:
rep movsw
add bx,[es:ScrDoubleWidth]
mov si,bx
mov cl,dl
dec dh
jnz @@nx

ret
endp wintobuffer

end
;*/

Из примера выш функцию можно вызвать вот так

call wintobuffer sx,sy,ex,ey,buf

вот чудеса, комманда call умеет ажно аргументы всякие ! Вот так процессор

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

I>>Тебя испугал сигнальный микропросцессор что ли ?

G>Ничем не испугал. Просто мои знания ассеблера x86 как языка (со всеми сопуствующими паттернами, архиетктурой) оказались бесполезными.

архитектура будет бесполезна, это так. Разумеется, все наработки придётся оставить, особенно библиотечки всякие.
Прикинь, при переходе с java на C# или наоборот все точно так же !
Зато опыт, разумеется, никуда девать не надо. Время на адаптацию и вперёд.

I>>Но сильно думаю, это потому что ассеблера ты и не знал вобщем то.
G>Да придумывать недостатки оппоненту — это круто.

Я не придумал, ты свел ассемблер к системе комманд процессора. О чем говорить ?

Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, Mr.Cat, Вы писали:

MC>>Не объяснишь, как знание математики кореллирует с ведением собственного бизнеса (ака "не работать на дядечку")?

H>Когда чел не креативен и у него нет фундаментальных знаний ИТ (и в их числе математика), то он может лепить только формочки, а это значит, что он будет всю жизнь работать делая рутину в самой низкой иерархии программистов. А возможно даже откроет, когда нибудь собственную быдло конторку по лепки формочек, если его интересуют ТОЛЬКО деньги, а программирование для него ТОЛЬКО способ их срубить с других (с заказчиков), то всё хорошо. Но это уже не тру программист.

H>Когда чел креативен и у него есть фундаметальные знания и практический опыт, то он сможет продвинутся по иерархии ИТ в качестве специалиста и будет очень ценен. В будущем сможет возглавить действительно КАЧЕСТВЕННЫЙ И ИНТЕРЕСНЫЙ проект.

так вот вы куда клоните ... вас интересуют не ТОЛЬКО деньги , а еще и продвижение по службе

Здравствуйте, Ikemefula, Вы писали:

I>для этих пунктов не надо читать Совершенный код.

I>Я недавно с одним новичков имел как раз такую беседу, он написал метод удаления из дерева длинной ажно в 200 строк два часа долбили её, что бы упростить и уменьшить.

I>п. 1. Я не единожды объяснял и показывал, но читабельность он понимает не так как я.
I>Ему хорошо читать — он считает это хорошей читабельностью.
I>Что бы научить этой читабельности, нужно заставить человека читать этот самый код. И одного-двух прмеров или объяснений тут недостаточно.
I>Мне повезло, что его метод был слишком большой. Через неделю он забыл что и как там происходит и сразу вылезла путаница.

I>Но повторюсь — читабельность может обеспечить только тот, кто читает вагоны чужого кода, а не тот кро прочитал какую то книжку.

I>п. 2 Рефакторинг сложных циклов. Что значт сложный цикл ? Для кого сложный ?
I>Студент пишет сложную логику там где она совершенно не нужна. Обычно это значит, что он пишет так — придумал кусочек, написал. попробовал, не работает, придумал, еще написал.
I>Сразу продумать целиком весь вариант он еще не умеет, это даётся годами тренировок — написание, отладка, переделка своего и чужого кода.
I>Книжкой это заменить нельзя. Мозг устроен вобщем то прмерно как и мышцы(аналогия конечно) — тренировки помноженные на время дают эффект (более подробно про это в теори ВПФ). Время можно уменьшить за счет увеличения интесивности тренировок, правильной нагрузки и правильного отдыха.
I>И обязательно нужен разбор полетов. Точно так же и с мышцами — что бы выполнить сед, нужно хорошо прокачать тягу, иначе во время седа спина будет проседать. Для мозгов нужно найти якорь который мешает понять или продвинуться дальше. Это только у ИТ и ВладД2 все просто

другим надо работать что бы подняться на следущий уровень Простоты.

I>п.3 здесь тоже самое что и с п.2. все ветвления и циклы студент понимает как кусочки if else и тд.( Hence the expression — императивный программист.) Опытный девлопер цикл со всеми потрохами видит одной сущностью/явлением.
I>И книжкой это опять же не исправить, масштаб мышления это результат усилий помноженных на время помноженных на понижающий коэффициэнт якоря(ей).

I>п.4. Похоже на п.1, но немного другое. Вот на примере — что такое rdel и ldel ? Сначала это были узлы — rdel значит узел для удаления, который был справа у узла предка, а ldel — слева. Потом в ходе написания кода rdel и ldel стали указывать на поддеревья а не узлы для удаления. Вроде бы тоже самое но чел привык к названиям и они стали для него нормой.
I>И книгами здесь не лечится — спустя неделю я просто попросил объяснть программу (разбор полётв) и как раз выяснилось, что чел ничего в ней не понимает и путается в rdel и ldel. Переименовали все что могли и сразу половина текста в 200 строк стала понятной даже мне

I>п.6 — про классы еще ничего нет, зато есть набор методов, у которых в параметрах может быть черт знает что.
I>Уже на этом уровне случается хаос, который не передать словами — нужно учить как правильно объявлять методы.
I>А это значт, сначала нужно научить как правильно выполнить композицию/декомпозицию — и опять это практика/практика/практика + разборы полётов.
I>в коде например может быть трижды встречаться мега-цикл и новичек не догадается выбросить его за пределы метода или в коде ему окажется очень удобно выводить строчки на экран прямо в методе для удаления.

I>Мега-авторы мега книг пишут так — вот в в методе есть сущность_а и сущность_б — раз эни разные, то логично и разделить на части.
I>Опаньки — сразу скормил новичку готовое решение, "сэкономив" время обучения.
I>+на возможные возражения пишется такое "допустим надо сделать а, б, в и г, что дальше ?" Опаньки — и тут скармиливается готовое решения — автор указывает, что метод с двумя сущностями создаст проблемы.

I>"допустим надо сделать а, б, в и г" — это условие только кажется простым. Рально от человека требуется смоделировать в уме целую систему, поместить в нее метод, который он написать и применить его к ситуациям а, б,в и г. Это как раз то мышление,что в школе практически не прокачивается.

I>Студента нужно этому учить — увидел, что в коде мешанина, нужно предложить доработать программу для случаев а,б, в и г. Пусть работает а за копипейст поставить двойку.

I>Вот студенческий код (1 курс второй семестр последняя лабораторная) — код этот взялся не потому, что студент книгку не может осилить, а потому что еще навыки не прокачаны.

I>Вот например про g_pRoot интересный момент — чел сунул нос в венгерскую нотацию, но до конца не понял что такое глобальные переменные.
I>Или про параметны — сразу видно, книжкой это не лечится, чел в упор не видел что первый параметр не используется и из за этого чуть не поругались.

I>Но вообще программа работает на уровне "показать преподавателю". На потоке только пару человек осилили эту лабу(деревья).

Вообщем нужно И читать И практиковать. Но всё же перед тем как усиленно практиковать (то есть будучи имея небольшую практику) я думаю, что нужно всё таки внимать в то, что пишут.

Здравствуйте, March_rabbit, Вы писали:

M_>вот уж 9-ый год программлю. За это время первые три года использовал какие-то математические выкладки вроде временной сложности алгоритма поиска или сортировки. Реально нужно было. А вот последние годы просто не сталкиваюсь с подобными задачами. Бывает такое: есть некая процедура (не в смысле процедуры языка, а последовательность определенных действий и реакций). Хочется ее оптимизировать. А потом смотришь — эта процедура будет работать может раз за сутки, или реже. И зачем тратить время на оптимизацию тогда? Уж лучше сделать проще и понятнее для того, кто будет продолжать работу.

M_>Сам любитель оптимизаций, но вот...

Ну так после 9 лет программирования вполне правомерно, чем то пренебрегать, а чем то нет. Но нам новичкам и Вам когда-то всё же ОЧЕНЬ полезно вникать в теорию. Кстати это такой парадокс, человек который когда-то этому учился, потом может сказать что это ему не пригодилось и что практика всё заменила, но спроси его раньше на пару лет, он скажет, что без теории никуда. Без теории он был не стал таким каким есть сейчас.

Здравствуйте, hal9000, Вы писали:

I>>Но вообще программа работает на уровне "показать преподавателю". На потоке только пару человек осилили эту лабу(деревья).

H>Вообщем нужно И читать И практиковать. Но всё же перед тем как усиленно практиковать (то есть будучи имея небольшую практику) я думаю, что нужно всё таки внимать в то, что пишут.

Совершенный код нужно освоить преподавателю. Вот это я считаю обязательно

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте.

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

H>Для меня это звучит дико, поскольку считаю, что без глубокого понимания теории невозможно писать качественное ПО, с поддержкой масштабирования, с адекватной производительностью и т.д., если только не идёт речь пожизненном написании быдло-сайтиков или криворукого билинга для какой нибудь шаражки.

H>Нужно ли понимание общих теоретических концепций для тру программирования?

Для умения отличать n^2 от яичницы и базовых алгоритмов вполне достаточно какой-нибудь тонюсенькой книжки типа "Алгоритмы и структуры данных" Вирта. Никому никуда не упало уметь отличать о-большое от омега-малое и нафиг не сдалось знание о недетерминированной машине Тюринга.
Знание же прочего нужно скорее на уровне "оглавления", есло вообще нужно — дескать ну да, бывают графы, бывают грамматики. А необходимость знания каких-либо конкретных алгоритмов на графах, к примеру, встречается, наверное, не чаще чем необходимость знания численного метода Левенберга-Марквардта. Однако его же вы с программистов не требуете?

Вот внезапно понадобится написать парсер, скажете вы, что тогда делать? Да банально писать в гугле "how to write a parser" и уже оттуда выходить на всю теорию. Естественно, есть области где надо знать все гораздо глубже, но в этом случае это просто отдельная узкая специализация типа криптографии или оптимизации запросов на конкретной СУБД — нет никакой необходимости знать это каждому.

Есть, наверное, какой-то перечень фундаментальных знаний, которыми желательно владеть каждому программисту, но туда точно не входят конечные автоматы и умение писать компиляторы)

Здравствуйте, March_rabbit, Вы писали:

M_>1) именно в этом месте тормозит?
M_>2) сколько процентов времени проводит программа в этом месте?
M_>... ну и прочее.

Θ(n^2) убъёт машину по сравнению с Θ(n), при больших n. Мощности машины можно наращивать, но парабола рано или поздно сведёт на нет вычислительную мощь.

Это в общем случае.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, mymuss, Вы писали:

НС>>>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

M>>"Не всегда хуже" это неинтересно. А "лучше" бывает?

НС>Бывает. Все зависит от абсолютной величины константы и величины n.

Вы уверены, что понимаете, что такое О-большое? При переходе к асимптотике константы теряются. Говорить об O(...) и приплетать сюда константу бессмысленно.

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

Здравствуйте, carpenter, Вы писали:

C>так вот вы куда клоните ... вас интересуют не ТОЛЬКО деньги , а еще и продвижение по службе

Надо стремится заниматься интересными вещами, но при этом ещё и получать деньги

Здравствуйте, March_rabbit, Вы писали:

M>>Тормозит сильно.
M_>)
M_>1) именно в этом месте тормозит?
M_>2) сколько процентов времени проводит программа в этом месте?
M_>... ну и прочее.

1) Вся программа один большой цикл, в котором перебирается много-много записей. (Ну не считая в самом конце крохотной ф-ции, которая генерирует XML/HTML с отчетом)
Нах, спрашивается, вкладывать в него еще один цикл, который в худшем случае будет перебирать то же самое кол-во элементов? Я не уверен, что мне удалось аффтару проги объяснить разницу, точнее я почти уверен, что он продолжает думать что там как было 2*n, так и осталось.

2) Не знаю, 99.999% наверное.

На 200 млн записей разница очень заметна.

Здравствуйте, mymuss, Вы писали:

M>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>Здравствуйте, mymuss, Вы писали:

НС>>>>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

M>>>"Не всегда хуже" это неинтересно. А "лучше" бывает?

НС>>Бывает. Все зависит от абсолютной величины константы и величины n.

M>Вы уверены, что понимаете, что такое О-большое? При переходе к асимптотике константы теряются. Говорить об O(...) и приплетать сюда константу бессмысленно.

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

Вы всегда с бесконечными n работаете?
Открываем, к примеру, сорцы явы (метод Arrays.sort):

    if (len < 7) {
    //Ба! Так это же сортировка вставкой, энквадрат в чистом виде! Ай-яй-яй!
        for (int i=off; i<len+off; i++)
        for (int j=i; j>off && x[j-1]>x[j]; j--)
            swap(x, j, j-1);
        return;
    }

    // Пошел quicksort
    // Choose a partition element, v
        ...

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Следующая стадия — понимание того, что не всегда O(n^2) хуже O(n).

На самом деле O(x) это всего лишь верхняя оценка, поэтому она мало о чём может говорить (ранее использовал обозначение O, так как в лом было искать символ теты). Лучше использовать тету — Θ(x). Это уже не просто потолок, а коридор порядка роста ограниченный двумя константами.

Здравствуйте, mymuss, Вы писали:

НС>>Бывает. Все зависит от абсолютной величины константы и величины n.

M>Вы уверены, что понимаете, что такое О-большое?

Уверен.

M> При переходе к асимптотике

Ну значит стадию перехода от асимптотики к реальному коду ты еще не прошел. Если что, на личности перешел ты первый.

M> константы теряются. Говорить об O(...) и приплетать сюда константу бессмысленно.

Конечно. Но это если говорить об O(...). А если говорить о реальной производительности и масштабируемости, и потом приплетать O(...), то все уже не так вакуумносферично.

M>Можно говорить о том, что квадратичная ф-ция f(n) лучше чем линейная g(n)

Нельзя, пока не определен критерий лучшести.

Здравствуйте, komaz, Вы писали:

K>Для умения отличать n^2 от яичницы и базовых алгоритмов вполне достаточно какой-нибудь тонюсенькой книжки типа "Алгоритмы и структуры данных" Вирта. Никому никуда не упало уметь отличать о-большое от омега-малое и нафиг не сдалось знание о недетерминированной машине Тюринга.
K>Знание же прочего нужно скорее на уровне "оглавления", есло вообще нужно — дескать ну да, бывают графы, бывают грамматики. А необходимость знания каких-либо конкретных алгоритмов на графах, к примеру, встречается, наверное, не чаще чем необходимость знания численного метода Левенберга-Марквардта. Однако его же вы с программистов не требуете?

То, что тебе лично это не понадобилось, мало что означает. Если конечно ты себя не считаешь эталоном хорошего программиста.

Здравствуйте, komaz, Вы писали:

k> Вы всегда с бесконечными n работаете?
k> Открываем, к примеру, сорцы явы (метод Arrays.sort):

Напомнило байку про кошку и привязанную к ее хвосту консервную банку

avalon 1.0rc1 rev 251, zlib 1.2.3

Здравствуйте, komaz, Вы писали:

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

K>Вы всегда с бесконечными n работаете?
K>Открываем, к примеру, сорцы явы (метод Arrays.sort):

Вы мое сообщение прочитали перед тем как ответ постить? Наверное нет, попробую еще раз себя процитировать:

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

В Вашем примере О-большое непричем, нет там О-большого.
Человек же выше ляпнул глупость, написав, что именно асимптотический вариант, т.е. с О-большим, иногда лучше. Именно в такой формулировке фраза не имеет смысла.

K>Вот внезапно понадобится написать парсер, скажете вы, что тогда делать? Да банально писать в гугле "how to write a parser" и уже оттуда выходить на всю теорию. Естественно, есть области где надо знать все гораздо глубже, но в этом случае это просто отдельная узкая специализация типа криптографии или оптимизации запросов на конкретной СУБД — нет никакой необходимости знать это каждому.

K>Есть, наверное, какой-то перечень фундаментальных знаний, которыми желательно владеть каждому программисту, но туда точно не входят конечные автоматы и умение писать компиляторы)

Всё зависит от того, что и на каком уровне писать. Я уже это обсуждал выше.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ну значит стадию перехода от асимптотики к реальному коду ты еще не прошел. Если что, на личности перешел ты первый.

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

PS: На брудершафт с Вами не пили, так что, попрошу не тыкать. Спасибо.

Здравствуйте, mymuss, Вы писали:

M>Ок, лично с Вами у меня продолжать дискуссию желания нет.

Слив засчитан.

M> Я на личности не переходил и был предельно вежлив.

Конечно. И сентенция про мое непонимание мне померещилась, конечно же.

M>PS: На брудершафт с Вами не пили, так что, попрошу не тыкать. Спасибо.

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

Здравствуйте, hal9000, Вы писали:

H>Заметил, что большинство ИТ-специалистов и программистов с которыми я общался считают, что математика ..., теория алгоритмов ... вообще не нужны современному программисту.

Нужно ли плотнику знать сопромат? Нужно ли гончару знать химию? Нужно ли музыканту знать сольфеджио?
В принципе, можно успешно заниматься своим делом, полагаясь лишь на приходящее с опытом чутьё и большой объём "конкретных" знаний. Но сможет ли такой специалист вырваться из круга привычных представлений и предрассудков чтобы создать что-то действительно новое или решить свою задачу нестандартным способом?
Формальные науки (математика и логика) отличаются от всех прочих наук тем, что их законы обязательны для исполнения для всех. И для плотника, и для музыканта, и для программиста, и для Бога. Как ни выдрючивайся, как ни маши волшебной палочкой, квадрат гипотенузы равен сумме квадратов катетов, и баста.

Человек, изучающий математику правильным образом, получает следующие полезные вещи:
1. Очень небесполезный набор абстрактных понятий, в свойствах, взаимосвязях и поведении которых можно быть абсолютно уверенным. Если это ещё подкрепляется курсами естественных и прикладных наук, эти чистые абстракции начинают как-то соотноситься с реальным миром.
2. Математика, изучаемая правильным образом, приучает человека очень чётко отличать доказанные утверждения от гипотез, необходимые условия от достаточных и т.п. Привычка строить свои рассуждения на прочном фундаменте очень полезна в нашем постмодернистском мире, в котором каждый жулик норовит втюхать свою хрень про то, что пиво дарит подарки друзьям, сковородки думают о нас, а шампунь от перхоти делает нас на 52 процента счастливее.

H>Для меня это звучит дико, поскольку считаю, что без глубокого понимания теории невозможно писать качественное ПО, с поддержкой масштабирования, с адекватной производительностью и т.д., если только не идёт речь пожизненном написании быдло-сайтиков или криворукого билинга для какой нибудь шаражки.

Согласен. Без глубокого понимания основ можно быть классным подмастерьей, но мастером без этого не стать.

H>Нужно ли понимание общих теоретических концепций для тру программирования?

Не нужно, но очень полезно

V>Не нужно, но очень полезно

Да, полезно, но только как тренировка ума в целом. С таким же успехом можно рекомендовать изучение теории твердого тела (попутно и математику изучить придется)

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, komaz, Вы писали:

K>>Для умения отличать n^2 от яичницы и базовых алгоритмов вполне достаточно какой-нибудь тонюсенькой книжки типа "Алгоритмы и структуры данных" Вирта. Никому никуда не упало уметь отличать о-большое от омега-малое и нафиг не сдалось знание о недетерминированной машине Тюринга.
K>>Знание же прочего нужно скорее на уровне "оглавления", есло вообще нужно — дескать ну да, бывают графы, бывают грамматики. А необходимость знания каких-либо конкретных алгоритмов на графах, к примеру, встречается, наверное, не чаще чем необходимость знания численного метода Левенберга-Марквардта. Однако его же вы с программистов не требуете?

НС>То, что тебе лично это не понадобилось, мало что означает. Если конечно ты себя не считаешь эталоном хорошего программиста.

Я не считаю себя эталоном, я просто считаю себя хорошим программистом. Весьма странно ставить какие-либо знания в список обязательных из соображения что они кому-то когда-то понадобились. Уверен, большинству людей на этом форуме пришлось обзавестись массой знаний в процессе работы, но вряд ли кто-то будет утверждать что все их стоит заносить в must have.

Здравствуйте, Voblin, Вы писали:

V>Нужно ли плотнику знать сопромат? Нужно ли гончару знать химию? Нужно ли музыканту знать сольфеджио?
V>В принципе, можно успешно заниматься своим делом, полагаясь лишь на приходящее с опытом чутьё и большой объём "конкретных" знаний. Но сможет ли такой специалист вырваться из круга привычных представлений и предрассудков чтобы создать что-то действительно новое или решить свою задачу нестандартным способом?
V>Формальные науки (математика и логика) отличаются от всех прочих наук тем, что их законы обязательны для исполнения для всех. И для плотника, и для музыканта, и для программиста, и для Бога. Как ни выдрючивайся, как ни маши волшебной палочкой, квадрат гипотенузы равен сумме квадратов катетов, и баста.

V>Человек, изучающий математику правильным образом, получает следующие полезные вещи:
V>1. Очень небесполезный набор абстрактных понятий, в свойствах, взаимосвязях и поведении которых можно быть абсолютно уверенным. Если это ещё подкрепляется курсами естественных и прикладных наук, эти чистые абстракции начинают как-то соотноситься с реальным миром.
V>2. Математика, изучаемая правильным образом, приучает человека очень чётко отличать доказанные утверждения от гипотез, необходимые условия от достаточных и т.п. Привычка строить свои рассуждения на прочном фундаменте очень полезна в нашем постмодернистском мире, в котором каждый жулик норовит втюхать свою хрень про то, что пиво дарит подарки друзьям, сковородки думают о нас, а шампунь от перхоти делает нас на 52 процента счастливее.

Вы один из немногих кто это понимает

Можно и теорию суперструн изучать, кому что по вкусу. Уверен, что человек осиливший теорию суперструн со всеми выкладками, может стать очень продвинутым программером

Здравствуйте, komaz, Вы писали:

K>Да, полезно, но только как тренировка ума в целом. С таким же успехом можно рекомендовать изучение теории твердого тела (попутно и математику изучить придется)

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

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, komaz, Вы писали:

K>>Да, полезно, но только как тренировка ума в целом. С таким же успехом можно рекомендовать изучение теории твердого тела (попутно и математику изучить придется)

H>А почему бы и нет!

Отлично, а сможет ли осиливший теорию суперструн стать хорошим программистом не прочитав dragon book?

Здравствуйте, komaz, Вы писали:

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

Ох, если бы все было так просто. Вот, понимаешь, пока я не знал, что такое электролобзик или шуруповерт в подробностях, оно мне нафик не нужно было. А сейчас это основной инструмент. С программированием то же самое — к примеру, если ты не умеешь быстро и качественно писать парсеры, ты их будешь старательно избегать. Как результат — появляются всякие удивительные решения навроде языков программирования на баз XML, хранения исходников в виде бинарно сериализованного AST, запись условий и выражений мышкой при помощи рукопашного построения ast этого выражения и т.п. Еще пример — регулярно вижу в форумах попытку распарсить регексами то, что ими не парсится принципиально. Это — следствие отсутствия понимания того, что такое регулярная грамматика. И, что характерна, если их спросить, то они продолжают утверждать, что такой ужасный головоломный раздел математики, как теория формальных грамматик им нафиг не нужна, и, если что, оне в гуголе все найдут.

K> Уверен, большинству людей на этом форуме пришлось обзавестись массой знаний в процессе работы, но вряд ли кто-то будет утверждать что все их стоит заносить в must have.

Знания знаниям рознь.

Здравствуйте, hal9000, Вы писали:

H>Вы один из немногих кто это понимает

Спасибо!

Здравствуйте, komaz, Вы писали:

K>Отлично, а сможет ли осиливший теорию суперструн стать хорошим программистом не прочитав dragon book?

Я думаю, после M-теории ему не привыкать читать такие книжки

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ох, если бы все было так просто. Вот, понимаешь, пока я не знал, что такое электролобзик или шуруповерт в подробностях, оно мне нафик не нужно было. А сейчас это основной инструмент. С программированием то же самое — к примеру, если ты не умеешь быстро и качественно писать парсеры, ты их будешь старательно избегать. Как результат — появляются всякие удивительные решения навроде языков программирования на баз XML, хранения исходников в виде бинарно сериализованного AST, запись условий и выражений мышкой при помощи рукопашного построения ast этого выражения и т.п. Еще пример — регулярно вижу в форумах попытку распарсить регексами то, что ими не парсится принципиально. Это — следствие отсутствия понимания того, что такое регулярная грамматика. И, что характерна, если их спросить, то они продолжают утверждать, что такой ужасный головоломный раздел математики, как теория формальных грамматик им нафиг не нужна, и, если что, оне в гуголе все найдут.

Аналогично:
1. Не зная про базы данных кто-то может клепать какой-нибудь xml-based persistence storage
2. Не зная о существовании всяких SOAP, WCF, RMI, etc кто-то может клепать какой-нибудь свой xml-based rpc на сокетах
3. Не зная ничего про RSA, SHA, MD5, DES, etc кто-то может изобретать свой rot13
и т.п.

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

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, komaz, Вы писали:

K>>Отлично, а сможет ли осиливший теорию суперструн стать хорошим программистом не прочитав dragon book?

H>Я думаю, после M-теории ему не привыкать читать такие книжки

Именно! На мой взгляд вполне достаточно просто "прокачать" способность к восприятию больших объемов незнакомой и сложной для понимания информации. И вовсе необязательно (хотя, разумеется, явно не повредит) прорешивать все задачи из дистинуальной, тьфу, то есть конкретной математики прежде чем начать работать программистом

Здравствуйте, komaz, Вы писали:

H>>А почему бы и нет!

K>Отлично, а сможет ли осиливший теорию суперструн стать хорошим программистом не прочитав dragon book?

Ну, я, например, не читал dragon book

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

Здравствуйте, komaz, Вы писали:

K>Именно! На мой взгляд вполне достаточно просто "прокачать" способность к восприятию больших объемов незнакомой и сложной для понимания информации. И вовсе необязательно (хотя, разумеется, явно не повредит) прорешивать все задачи из дистинуальной, тьфу, то есть конкретной математики прежде чем начать работать программистом

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

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, March_rabbit, Вы писали:

M_>>вот уж 9-ый год программлю. За это время первые три года использовал какие-то математические выкладки вроде временной сложности алгоритма поиска или сортировки. Реально нужно было. А вот последние годы просто не сталкиваюсь с подобными задачами. Бывает такое: есть некая процедура (не в смысле процедуры языка, а последовательность определенных действий и реакций). Хочется ее оптимизировать. А потом смотришь — эта процедура будет работать может раз за сутки, или реже. И зачем тратить время на оптимизацию тогда? Уж лучше сделать проще и понятнее для того, кто будет продолжать работу.

M_>>Сам любитель оптимизаций, но вот...

H>Ну так после 9 лет программирования вполне правомерно, чем то пренебрегать, а чем то нет. Но нам новичкам и Вам когда-то всё же ОЧЕНЬ полезно вникать в теорию. Кстати это такой парадокс, человек который когда-то этому учился, потом может сказать что это ему не пригодилось и что практика всё заменила, но спроси его раньше на пару лет, он скажет, что без теории никуда. Без теории он был не стал таким каким есть сейчас.
с тем, что знать ЭТО полезно, соглашусь.
Но совсем не обязательно это применять постоянно.

Любая оптимизация — корень всех зол.

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, komaz, Вы писали:

H>>>А почему бы и нет!

K>>Отлично, а сможет ли осиливший теорию суперструн стать хорошим программистом не прочитав dragon book?

V>Ну, я, например, не читал dragon book

Более того, я знаю отличных программистов, которые понятия не имеют о том, как вообще делаются компиляторы.
V>Но вот хороших программистов, не наделённых культурой мышления, я не встречал. Метод тыка и программирование на в расчёте на стечение обстоятельств — вот их жалкий удел.
Да я тоже не читал, более того — в обозримом будущем и не планирую, и по мне полезность этой книги примерно такая же, как у частично упорядоченных множеств, теории графов и конечных автоматов. Все же склад мышления первичен, а знания — дело наживное, есть, конечно, какой-то минимум (вполне холиварный вопрос, что подтверждает и этот топик), но в остальном лучше стараться применять lazy initialization по отношению к новым знаниям

Здравствуйте, komaz, Вы писали:

K>Аналогично:
K>1. Не зная про базы данных кто-то может клепать какой-нибудь xml-based persistence storage
K>2. Не зная о существовании всяких SOAP, WCF, RMI, etc кто-то может клепать какой-нибудь свой xml-based rpc на сокетах
K>3. Не зная ничего про RSA, SHA, MD5, DES, etc кто-то может изобретать свой rot13
K>и т.п.

Ты действительно не понимаешь разницы между математическими теориями и конкретными технологиями?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, komaz, Вы писали:

K>>Аналогично:
K>>1. Не зная про базы данных кто-то может клепать какой-нибудь xml-based persistence storage
K>>2. Не зная о существовании всяких SOAP, WCF, RMI, etc кто-то может клепать какой-нибудь свой xml-based rpc на сокетах
K>>3. Не зная ничего про RSA, SHA, MD5, DES, etc кто-то может изобретать свой rot13
K>>и т.п.

НС>Ты действительно не понимаешь разницы между математическими теориями и конкретными технологиями?
Ну ты первый начал про электролобзики и шуруповерты вместо уравнений Максвелла

А по теме — так уж ли нужны фундаментальные знания для того, чтобы пользоваться antlr и т.п.? Нельзя ли получить необходимый объем знаний в процессе решения конкретной задачи?

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, March_rabbit, Вы писали:

M_>>1) именно в этом месте тормозит?
M_>>2) сколько процентов времени проводит программа в этом месте?
M_>>... ну и прочее.

H>Θ(n^2) убъёт машину по сравнению с Θ(n), при больших n. Мощности машины можно наращивать, но парабола рано или поздно сведёт на нет вычислительную мощь.

H>Это в общем случае.
ты не ответил на два приведенных вопроса. Прикинь, надо тебе отсортировать 32-х битные числа. Число n — реально большое. Ок.
1) Хватит ли памяти для сортировки Θ(n^2)? А для сортировки Θ(n)? (ограничение по памяти)
2) Откуда возьмутся эти данные и куда их надо деть? (ограничение по скорости ввода-вывода)
Эти два вопроса могут серьезно повлиять на выбор метода сортировки. Каждый по своему.

И главный вопрос:
3) Сколько элементов данных нужно в отсортированном массиве?
Вопрос несколько странный, но... Если стоит задача вида "получить M наибольших чисел", лучшая оптимизация — не сортировать весь массив.

Ну а первый (и главный) вопрос: "насколько часто нужна эта сортировка?". Если она нужна настолько редко, что это не повлияет на работу пользователя — то не стоит и тратить на ее оптимизацию время. Например, какая-нибудь хитрая сортировка записей в почтовой папке, с огромным числом писем может вообще быть применена пользователем 1 раз в месяц. И далеко не у всех при этом может набраться сколько-нибудь большое количество писем в сортируемой папке. Такое, чтобы разница по времени была бы ощутимой.

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте, komaz, Вы писали:

K>>Именно! На мой взгляд вполне достаточно просто "прокачать" способность к восприятию больших объемов незнакомой и сложной для понимания информации. И вовсе необязательно (хотя, разумеется, явно не повредит) прорешивать все задачи из дистинуальной, тьфу, то есть конкретной математики прежде чем начать работать программистом

H>При более глубоком изучении ключевых концепций математики (т.е. когда изучаешь по настоящему для души, а не для препода в вузе), начинаешь осознавать, что математика это не наука вычисления чего либо, а нечто большее, это можно сказать формальный язык для операций с информационными объектами любого типа. Математика очень развита и в ней много разных моделей и операций с объектами, поэтому как нельзя лучше подходит для развития правильного мышления и умения работать со сложной информацией любой природы.

С этим не поспоришь, но чем в этом плане дискретка лучше функционального анализа или ТФКП?

Здравствуйте, mymuss, Вы писали:

M>Здравствуйте, March_rabbit, Вы писали:

M>>>Тормозит сильно.
M_>>)
M_>>1) именно в этом месте тормозит?
M_>>2) сколько процентов времени проводит программа в этом месте?
M_>>... ну и прочее.

M>1) Вся программа один большой цикл, в котором перебирается много-много записей. (Ну не считая в самом конце крохотной ф-ции, которая генерирует XML/HTML с отчетом)
M>Нах, спрашивается, вкладывать в него еще один цикл, который в худшем случае будет перебирать то же самое кол-во элементов? Я не уверен, что мне удалось аффтару проги объяснить разницу, точнее я почти уверен, что он продолжает думать что там как было 2*n, так и осталось.

M>2) Не знаю, 99.999% наверное.

M>На 200 млн записей разница очень заметна.
в данном примере есть ровно один вопрос: насколько часто должна применяться эта программа? Если раз в неделю — тогда ИМХО время ей выполнения не важно (если оно меньше недели

Здравствуйте, Anton Batenev, Вы писали:

AB>Напомнило байку про кошку и привязанную к ее хвосту консервную банку

Вопрос о том с какой скоростью она должна бежать чтобы не слышать грохот? или что-то другое?

Здравствуйте, Ikemefula, Вы писали:

I>Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.
ну а теперь по пунктам: что твой листинг говорит о кеше? Об архитектуре процессора? Можно ли в ней увидеть принцип работы стека?

I>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
ну, вообще-то нормальные люди воспринимают ассемблер именно как систему команд + архитектуру процессора, а не набор макросов компилятора.

Здравствуйте, March_rabbit, Вы писали:

M_>ты не ответил на два приведенных вопроса. Прикинь, надо тебе отсортировать 32-х битные числа. Число n — реально большое. Ок.
M_>1) Хватит ли памяти для сортировки Θ(n^2)? А для сортировки Θ(n)? (ограничение по памяти)

Стратегия выбора алгоритма зависит от ресурсов машины и от частоты выполнения этого участка кода. Чаще всего имеют ввиду время работы алгоритма.

M_>2) Откуда возьмутся эти данные и куда их надо деть? (ограничение по скорости ввода-вывода)
M_>3) Сколько элементов данных нужно в отсортированном массиве?

Дополнительный анализ зависит от особенностей конкретной реализации.

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

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

Здравствуйте, komaz, Вы писали:

K>С этим не поспоришь, но чем в этом плане дискретка лучше функционального анализа или ТФКП?

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

Здравствуйте, komaz, Вы писали:

K>Да я тоже не читал, более того — в обозримом будущем и не планирую, и по мне полезность этой книги примерно такая же, как у частично упорядоченных множеств, теории графов и конечных автоматов. Все же склад мышления первичен, а знания — дело наживное, есть, конечно, какой-то минимум (вполне холиварный вопрос, что подтверждает и этот топик), но в остальном лучше стараться применять lazy initialization по отношению к новым знаниям

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

Здравствуйте, hal9000, Вы писали:

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1230>>

Здравствуйте, March_rabbit, Вы писали:

I>>Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.
M_>ну а теперь по пунктам: что твой листинг говорит о кеше? Об архитектуре процессора? Можно ли в ней увидеть принцип работы стека?

По пунктам — листинг был приведен для того, что бы показать что ассемблер не сводится к коммандам процессора. Так понятно ?

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

I>>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
M_>ну, вообще-то нормальные люди воспринимают ассемблер именно как систему команд + архитектуру процессора, а не набор макросов компилятора.

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

Здравствуйте, komaz, Вы писали:

k> AB>Напомнило байку про кошку и привязанную к ее хвосту консервную банку

k> Вопрос о том с какой скоростью она должна бежать чтобы не слышать грохот? или что-то другое?

Ага, оно самое.

avalon 1.0rc1 rev 251, zlib 1.2.3

Здравствуйте, March_rabbit, Вы писали:

M_>в данном примере есть ровно один вопрос: насколько часто должна применяться эта программа? Если раз в неделю — тогда ИМХО время ей выполнения не важно (если оно меньше недели

).

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

Ок, я готов тут признать (надеюсь, мой босс еще не выучил русский и этого не читает). Человек, написавший эту прогу, живет в Индии и получает денег мин раз в 10 меньше, чем я. Если бы он мог писать качественный софт, с которым не возникает подобных проблем, то не знаю, сколько бы я продержался на этой работе. ))) Вот такая диалектика. Но это все бизнес. Большие боссы так решили, им виднее.

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

Здравствуйте, komaz, Вы писали:

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

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

Здравствуйте, hal9000, Вы писали:

H>Нужно ли понимание общих теоретических концепций для тру программирования?

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Без знания ассемблера ты просто не сможешь пощупать кеш, вряд ли поймешь что такое SIMD, а про арифметику с переполнением можешь просто забыть.
G>>С чего бы? я многократно рассказывал людям про архитектуру процессоров без упоминания ассемблерных команд.

I>Я выделил глаголы. Предположим, люди тебя слушали раз ты им рассказывал.
И они поняли, а как вообще пощупать кеш — вопрос интересный. Увидепть его влияние можно только профайлером или снимать показания счетчиков.

I>>>Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.
G>>Ты выше написал что ассемблер — это язык. Язык определяется синтаксисом и семантикой. И то и другое можжно в справочнике команд найти.

I>Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.

К самому языку это отношения не имеет. Даже к ассемблеру как таковому мало относится.
вся это туча кода выполняет копирование части буфера в видеопамять. Даже можно рассказать о тонкостях адресации видеопамяти в текством и графическом режимах, не упоминая при этом ассемблер.
Еще раз: ассемблер как язык — не более чем набор мнемонических обозначений команд процессора. Сам по себе ассемблер ни чем не поможет без знания архитектуры системы.

I>Из примера выш функцию можно вызвать вот так
I>call wintobuffer sx,sy,ex,ey,buf
I>вот чудеса, комманда call умеет ажно аргументы всякие ! Вот так процессор

Не подскажешь, что за код комманды ткой умной, в справочнике комманд это должно быть.
Вау, круто, макросы.
Какое отношение они имеют к ассемблеру?

I>>>Тебя испугал сигнальный микропросцессор что ли ?

G>>Ничем не испугал. Просто мои знания ассеблера x86 как языка (со всеми сопуствующими паттернами, архиетктурой) оказались бесполезными.
I>архитектура будет бесполезна, это так. Разумеется, все наработки придётся оставить, особенно библиотечки всякие.
I>Прикинь, при переходе с java на C# или наоборот все точно так же !
I>Зато опыт, разумеется, никуда девать не надо. Время на адаптацию и вперёд.
И имиенно поэтому знать принципы полезнее, чем знать отдельные языки.
Даже если это ассемблер.

I>>>Но сильно думаю, это потому что ассеблера ты и не знал вобщем то.
G>>Да придумывать недостатки оппоненту — это круто.

I>Я не придумал, ты свел ассемблер к системе комманд процессора. О чем говорить ?
О том чир то правда. Твой пример выше это подтвеждает.

I>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
Ассемблер и есть команды процессора.

Здравствуйте, hal9000, Вы писали:

L>>Нет, из этого не следует тот вывод, который вы сделали.

H>Почему не следует?

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

Здравствуйте, gandjustas, Вы писали:

G>>>С чего бы? я многократно рассказывал людям про архитектуру процессоров без упоминания ассемблерных команд.

I>>Я выделил глаголы. Предположим, люди тебя слушали раз ты им рассказывал.
G>И они поняли, а как вообще пощупать кеш — вопрос интересный. Увидепть его влияние можно только профайлером или снимать показания счетчиков.

Для чего профайлер и счетчики

? Секундомера хватит. Берешь и вычисляешь функцию сто тысяч миллионов раз, а потом её же исправляешь и снова выполняешь столько же раз.
Сравниваешь время/кол.во выполнений и узнаешь результат.

I>>Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.

G>К самому языку это отношения не имеет. Даже к ассемблеру как таковому мало относится.

Ну ка, объясни, а код на си будет ли относиться к сишному коду ?

G>вся это туча кода выполняет копирование части буфера в видеопамять. Даже можно рассказать о тонкостях адресации видеопамяти в текством и графическом режимах, не упоминая при этом ассемблер.

Можно. Только что бы пощупать видеобуфер всерьез надо опять же знать ассемблер.

G>Еще раз: ассемблер как язык — не более чем набор мнемонических обозначений команд процессора. Сам по себе ассемблер ни чем не поможет без знания архитектуры системы.

Я уже понял — код на языке программирования не является кодом на этом языке программирования. Ага.

I>>Из примера выш функцию можно вызвать вот так
I>>call wintobuffer sx,sy,ex,ey,buf
I>>вот чудеса, комманда call умеет ажно аргументы всякие ! Вот так процессор

Не подскажешь, что за код комманды ткой умной, в справочнике комманд это должно быть.
G>Вау, круто, макросы.
G>Какое отношение они имеют к ассемблеру?

Это и есть ассемблер. Язык ассемблера не сводится к коммандам.

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

Конечно. Мне например давали эти общие принцыпы, а ты долбил конкретный язык и архитектуру.

I>>Я не придумал, ты свел ассемблер к системе комманд процессора. О чем говорить ?
G>О том чир то правда. Твой пример выше это подтвеждает.

Ну да. Как там было, код на языке программирования не является кодом на этом языке программирования

I>>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
G>Ассемблер и есть команды процессора.

Ассемблер, кстати говоря, может быть ассемблером и при этом в нем не будет ни единой комманды процессора. Загадка для тебя.

Здравствуйте, hal9000, Вы писали:

H>Когда чел креативен и у него есть фундаметальные знания и практический опыт, то он сможет продвинутся по иерархии ИТ в качестве специалиста и будет очень ценен.

Тот, кто может делать — делает. Тот, кто не может делать — учит. Тот, кто не может учить — руководит.
(c) Народная мудрость.

Т.о. знания и опыт могут только помешать в продвижении по иерархии.

Здравствуйте, hal9000, Вы писали:

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

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

H>Нужно ли понимание общих теоретических концепций для тру программирования?

Естесственно, я бы еще добавил, что не только понимание, но и умение применять это на практике.

Здравствуйте, Sharowarsheg, Вы писали:

S>Для Тру Программирования нужно сначала понимание предметной области. А потом уже можно думать, нужен ли в этой области асимптотический анализ, и если да, то в каком объеме.

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

Здравствуйте, hal9000, Вы писали:

H>На счёт формулы 1 ошибся, так как "Позднее стала широко применяться в обычных серийных машинах, а в 2008 году была запрещена в Формуле-1.", но суть не меняется. Например, в одном из многочисленных выпусков Top Gear ведущий сначала обсирал машину, как он обычно любит это делать, а потом отключил подобную систему (я не специалист, но насколько знаю, там несколько видов автоматического управления) и показал настоящие возможности машины. Вообщем поищи Top Gear в youtube.

Поэтому и аналогия получилась некудышной.

Здравствуйте, hal9000, Вы писали:

H>А почему бы и нет!

Самый корявый говнокод который я видел написан кандидатом физико-математических наук, умнейшим и толковым специалистом в своей области.

Еще раз повторяю способности к математике и программированию совершенно разные способности.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, hal9000, Вы писали:

H>>А почему бы и нет!

FR>Самый корявый говнокод который я видел написан кандидатом физико-математических наук, умнейшим и толковым специалистом в своей области.

FR>Еще раз повторяю способности к математике и программированию совершенно разные способности.

Есть разные области математики. Одна область — непрерывная метаематика очень далека от компьютеров и специалист в этой области вряд ли сможет написать хорошую программу.
Другая область — дискретная математика, теория вычислимости, формальные грамматики, теория категорий. Знания этих областей очень пригодились бы любому программисту.

Здравствуйте, yumi, Вы писали:

S>>Для Тру Программирования нужно сначала понимание предметной области. А потом уже можно думать, нужен ли в этой области асимптотический анализ, и если да, то в каком объеме.

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

Это всё хорошо, если предметная область требует хоть сколько-то дискретки.

Здравствуйте, gandjustas, Вы писали:

G>Есть разные области математики. Одна область — непрерывная метаематика очень далека от компьютеров и специалист в этой области вряд ли сможет написать хорошую программу.
G>Другая область — дискретная математика, теория вычислимости, формальные грамматики, теория категорий. Знания этих областей очень пригодились бы любому программисту.

Конечно они полезны, но не необходимы, и точно не сильно помогут в том о чем писал автор темы:

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

Да чтобы не было не поняток я сам на старости лет ковыряю как раз то что ты выше описал.

Здравствуйте, _d_m_, Вы писали:

___>Смею тебя заверить, Билл Гейтс не был этаким гением программирования.

Те, кто с ним работал, были другого мнения.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, _d_m_, Вы писали:

___>>Смею тебя заверить, Билл Гейтс не был этаким гением программирования.

L>Те, кто с ним работал, были другого мнения.

Он скорее стратег — как Маршал Жуков, но смог бы Жуков взять живым диверсанта ака волкодав Таманцев? Разницу чуствуешь?

Здравствуйте, Ikemefula, Вы писали:

I>Вот студенческий код (1 курс второй семестр последняя лабораторная) — код этот взялся не потому, что студент книгку не может осилить, а потому что еще навыки не прокачаны.
А вот лично мне кажется, что такой код — суть неизбежное следствие дурацкого подхода к преподаванию программирования. Когда сначала студенту дают Управляющие Конструкции, потом Готовые Структуры, потом Забудьте Всё Это Потому Что Теперь Объекты.
SICP как раз даёт понимание в структурной форме, чтобы человек видел устройство программы, а не отдельные операторы.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, komaz, Вы писали:

K>Есть, наверное, какой-то перечень фундаментальных знаний, которыми желательно владеть каждому программисту, но туда точно не входят конечные автоматы и умение писать компиляторы)

Это очень глубокий и фундаментальный вопрос, который, на мой взгляд, совершенно внезапно получил актуальность в последние годы. Грубо говоря, надо ли учить даты правления всех этих французских Луёв, если любой идиот со смартфоном ответит на такой вопрос за 30 секунд? Зачем учить где Кордильеры а где Анды, если есть гуглмапс, который еще и встроен в яблофон по дефолту? Получается, все находятся в одинаковых условиях — и заучки, и разгильдяи.

С другой стороны, знания зачастую оказываются несводимыми к словарю "название -> описание".
Во-первых, для того, чтобы хоть что-то прочитать, нужно уметь читать. Скажем, лично нас в университете два первых года собсно и учили читать — потому, что стандартный десятиклассник, к примеру, хоть и знает ограниченно греческий алфавит, но прочесть с листа формулы с участием спиноров просто не сможет.
Во-вторых, даже умея читать (то есть понимая отдельные лексемы), нужно еще и разбираться в применяемых идентификаторах. Ок, все непонятные слова можно рекурсивно смотреть в интернете — но скорость чтения будет весьма низкой.

В-третьих, всё-таки знания — это не плоский текст или картинка, это, прежде всего, некая модель в голове. Ну вот написал я вам уравнение Шредингера. Ну, прочитали вы его. Что, внезапно у вас появилось в голове понимание квантовой механики? Построить корректную модель — вот это и есть получение знаний.
Хрен с ними с квантами, давайте вот о программированиии. Я, допустим, упоминаю в разговоре: "здесь может пригодиться R-дерево". Ок, любой невежда может быстренько сгуглить на тему R-деревьев. Но поможет ли ему это понять, действительно ли оно здесь пригодится, т.е. ответить на вопрос, на который нет готового ответа в сети. Для того, чтобы ответить на этот вопрос, нужно реально понять, как устроено R-дерево, как оно натягивается на существующую проблематику, и т.п.
В итоге, новичка этот вопрос запросто отвлечёт на пару месяцев усиленного изучения. Программеру, который имеет опыт применения R-деревьев, для ответа потребуется секунда. Между этими полюсами лежат разные уровни подготовки профессионала — наличие либо отсутствие в голове готовых "строительных блоков", из которых будет строиться модель.

Ок, теперь вернёмся к компиляторам. Вопрос, в итоге, сводится вот к чему: не окажется ли случайно курс разработки компиляторов полезным для формирования "сторонних умений", которые могут быть применимы к широкому классу задач, не связанных напрямую с компиляцией?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, hal9000, Вы писали:

H>Здравствуйте.

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

H>Для меня это звучит дико, поскольку считаю, что без глубокого понимания теории невозможно писать качественное ПО, с поддержкой масштабирования, с адекватной производительностью и т.д., если только не идёт речь пожизненном написании быдло-сайтиков или криворукого билинга для какой нибудь шаражки.

H>Нужно ли понимание общих теоретических концепций для тру программирования?

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Вот студенческий код (1 курс второй семестр последняя лабораторная) — код этот взялся не потому, что студент книгку не может осилить, а потому что еще навыки не прокачаны.
S>А вот лично мне кажется, что такой код — суть неизбежное следствие дурацкого подхода к преподаванию программирования. Когда сначала студенту дают Управляющие Конструкции, потом Готовые Структуры, потом Забудьте Всё Это Потому Что Теперь Объекты.

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

У чела проблема не с управляющими конструкциями, а с мышлением. С конструкциями проблем нет абсолютно никаких.

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

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

S>SICP как раз даёт понимание в структурной форме, чтобы человек видел устройство программы, а не отдельные операторы.

Т.е. сразу вбить студенту в голову мышление определенного уровня ? Эдак можно и в школе сразу давать математику без арифметики.

Понимание невозможно вложить в голову, это можно сформировать задачами и только задачами. Ничем больше оно не формируется.

Не бывает проблем с конструкциями, бывают преблемы с логическим мышлением.

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

Проходит все потому, что контингент в МИТ это уровня олимпиадников, у которых мышление прокачано очень сильно, а вузах попроще нужно чем то компенсировать.

Здравствуйте, Sharowarsheg, Вы писали:

S>Для Тру Программирования нужно сначала понимание предметной области.
А еще сначалее нужно умение быстро понимать предметную область. Потому что то понимание, которое нужно, это совсем-совсем особое понимание. Сколько ни говорил с глубоким специалистом в предметной области (не-программистом, ессно) — столько раз убеждался: головой пользоваться не умеет почти никто. Ну не заморачиваются люди выстраиванием у себя в мозгу сколь-нибудь стройной модели. Две штуки, которые отличаются малозначительным атрибутом, для них "ты чо, это же совсем разные вещи, их никак путать нельзя".
Зато две другие штуки, которые связаны отношением "частное-общее" у них сливаются в одну, которая по-разному себя ведёт в зависимости от контекста.

Такому специалисту никакое понимание предметной области не поможет стать программистом. Так и будет в коде всё, как и в голове:

if (a == 0 and b != 0)
{
  x = b;
    if (a != 0) 
      x = x + a;
} 
else if (a != 0)
{
  x = a;
    if (b != 0)
      x = a + b;
}
else
{
  x = a;
    if (a == 0)
      x = b;
    else 
      x = b + a;
}

Подставьте на место a и b "идентификаторы из предметной области" вроде kolvoDneiOtpuska или urovenVodyVBake и получите реальную программу, написанную таким понимальщиком.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Lloyd, Вы писали:

L>

L>Тот, кто может делать — делает. Тот, кто не может делать — учит. Тот, кто не может учить — руководит.
L>(c) Народная мудрость.

L>Т.о. знания и опыт могут только помешать в продвижении по иерархии.

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

Здравствуйте, Ikemefula, Вы писали:
I>Я вобще то сказал уже давно, что преподают программуху на данной специальности _очень_ плохо, потому что все основные моменты я лично объяснял повторно.
Правильно.
I>У чела проблема не с управляющими конструкциями, а с мышлением. С конструкциями проблем нет абсолютно никаких.
У чела проблема с тем, что ему не прочитали SICP.
I>Если ты в целях обучения сообщаешь правильный алгоритм удаления из дерева, то это тоже самое что в школе давать готовые ответы вместо самостоятельных и контрольных работ.
SICP — не про ответы. SICP — про вопросы.
I>Т.е. сразу вбить студенту в голову мышление определенного уровня ? Эдак можно и в школе сразу давать математику без арифметики.
I>Понимание невозможно вложить в голову, это можно сформировать задачами и только задачами. Ничем больше оно не формируется.
I>Не бывает проблем с конструкциями, бывают преблемы с логическим мышлением.
I>Сикп это примерно так "бывают R-деревья, делается вот так, вот так и вот так". Нужно вложить в голову более простые вещи, тогда кучка студентов при решении какой то задачи уже сами родят нечто похожее.
Какие конкретно "более простые вещи" ты хочешь рассказать перед SICP?

I>Проходит все потому, что контингент в МИТ это уровня олимпиадников, у которых мышление прокачано очень сильно, а вузах попроще нужно чем то компенсировать.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Это очень глубокий и фундаментальный вопрос, который, на мой взгляд, совершенно внезапно получил актуальность в последние годы. Грубо говоря, надо ли учить даты правления всех этих французских Луёв, если любой идиот со смартфоном ответит на такой вопрос за 30 секунд? Зачем учить где Кордильеры а где Анды, если есть гуглмапс, который еще и встроен в яблофон по дефолту? Получается, все находятся в одинаковых условиях — и заучки, и разгильдяи.

S>С другой стороны, знания зачастую оказываются несводимыми к словарю "название -> описание".
S>Во-первых, для того, чтобы хоть что-то прочитать, нужно уметь читать. Скажем, лично нас в университете два первых года собсно и учили читать — потому, что стандартный десятиклассник, к примеру, хоть и знает ограниченно греческий алфавит, но прочесть с листа формулы с участием спиноров просто не сможет.
S>Во-вторых, даже умея читать (то есть понимая отдельные лексемы), нужно еще и разбираться в применяемых идентификаторах. Ок, все непонятные слова можно рекурсивно смотреть в интернете — но скорость чтения будет весьма низкой.

S>В-третьих, всё-таки знания — это не плоский текст или картинка, это, прежде всего, некая модель в голове. Ну вот написал я вам уравнение Шредингера. Ну, прочитали вы его. Что, внезапно у вас появилось в голове понимание квантовой механики? Построить корректную модель — вот это и есть получение знаний.
S>Хрен с ними с квантами, давайте вот о программированиии. Я, допустим, упоминаю в разговоре: "здесь может пригодиться R-дерево". Ок, любой невежда может быстренько сгуглить на тему R-деревьев. Но поможет ли ему это понять, действительно ли оно здесь пригодится, т.е. ответить на вопрос, на который нет готового ответа в сети. Для того, чтобы ответить на этот вопрос, нужно реально понять, как устроено R-дерево, как оно натягивается на существующую проблематику, и т.п.
S>В итоге, новичка этот вопрос запросто отвлечёт на пару месяцев усиленного изучения. Программеру, который имеет опыт применения R-деревьев, для ответа потребуется секунда. Между этими полюсами лежат разные уровни подготовки профессионала — наличие либо отсутствие в голове готовых "строительных блоков", из которых будет строиться модель.

+1 С одной стороны жаль, что мало кто это понимает (например, твой будущий руководитель), с другой стороны хорошо, что это мало кто понимает (например, твои будущие конкуренты).

S>Ок, теперь вернёмся к компиляторам. Вопрос, в итоге, сводится вот к чему: не окажется ли случайно курс разработки компиляторов полезным для формирования "сторонних умений", которые могут быть применимы к широкому классу задач, не связанных напрямую с компиляцией?

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

Здравствуйте, Sinclair, Вы писали:

S>Какие конкретно "более простые вещи" ты хочешь рассказать перед SICP?

Спасибо за эту ветку в треде, теперь буду читать и SICP

P.S. Мне нравится твой ник

Здравствуйте, Sinclair, Вы писали:

I>>У чела проблема не с управляющими конструкциями, а с мышлением. С конструкциями проблем нет абсолютно никаких.
S>У чела проблема с тем, что ему не прочитали SICP.

Т.е. если дать ему SICP то резко вырастет уровень логического мышления ?

I>>Понимание невозможно вложить в голову, это можно сформировать задачами и только задачами. Ничем больше оно не формируется.
I>>Не бывает проблем с конструкциями, бывают преблемы с логическим мышлением.
I>>Сикп это примерно так "бывают R-деревья, делается вот так, вот так и вот так". Нужно вложить в голову более простые вещи, тогда кучка студентов при решении какой то задачи уже сами родят нечто похожее.
S>Какие конкретно "более простые вещи" ты хочешь рассказать перед SICP?

Все предметы обычно изучаются так — сначала даётся нечто конкретное, вроде y=kx+b для прямой а потом дается общее, вроде параметрического уравнения для прямой.

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

Вот после такой подготовки можно давать общую теорию, которая и есть в SICP.

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

Здравствуйте, FR, Вы писали:

FR>Конечно они полезны, но не необходимы, и точно не сильно помогут в том о чем писал автор темы:

FR>

FR>Для меня это звучит дико, поскольку считаю, что без глубокого понимания теории невозможно писать качественное ПО, с поддержкой масштабирования, с адекватной производительностью и т.д.
FR>

FR>Да чтобы не было не поняток я сам на старости лет ковыряю как раз то что ты выше описал.

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

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

Здравствуйте, yumi, Вы писали:

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

+1

Здравствуйте, _d_m_, Вы писали:

___>Поэтому и аналогия получилась некудышной.

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

Здравствуйте, Ikemefula, Вы писали:
I>Т.е. если дать ему SICP то резко вырастет уровень логического мышления ?
Естественно.

I>Вот после такой подготовки можно давать общую теорию, которая и есть в SICP.
Сколько такой подготовки нужно? Рекомендую ознакомится с содержанием программы по предмету "информатика" за 10-11 классы. Тратить ценное время первых семестров на то, чтобы дотянуть тех, кто не учился в средней школе, до уровня тех, кто учился, я считаю бессмысленным. Тем более, что в SICP входит практика — те, кто не видел компьютера, тут же сядут за схему (ок, за питон) и начнут колбасить те самые задачи, которые ты и хотел им дать.

I>Т.е. сначала человек разбирается с конкретными случаями, которые по ряду причин проще, сли указателями не перегружены, а потом уже может браться за общие, тут можно хоть сикп, хоть не сикп, главное чтото общее.
К моменту, когда человек разобрался с "конкретными случаями", давать SICP может быть уже поздно. Получится что-то типа Павла Дворкина, который назубок разобрался с одним конкретным видом программирования, и даже его преподаёт, но такая простая штука как immutability просто не может попасть к нему в мозг. Не проходит сквозь намертво приваренную дифракционную решетку.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, komaz, Вы писали:

K>>Есть, наверное, какой-то перечень фундаментальных знаний, которыми желательно владеть каждому программисту, но туда точно не входят конечные автоматы и умение писать компиляторы)

S>Это очень глубокий и фундаментальный вопрос, который, на мой взгляд, совершенно внезапно получил актуальность в последние годы. Грубо говоря, надо ли учить даты правления всех этих французских Луёв, если любой идиот со смартфоном ответит на такой вопрос за 30 секунд? Зачем учить где Кордильеры а где Анды, если есть гуглмапс, который еще и встроен в яблофон по дефолту? Получается, все находятся в одинаковых условиях — и заучки, и разгильдяи.

S>С другой стороны, знания зачастую оказываются несводимыми к словарю "название -> описание".
S>Во-первых, для того, чтобы хоть что-то прочитать, нужно уметь читать. Скажем, лично нас в университете два первых года собсно и учили читать — потому, что стандартный десятиклассник, к примеру, хоть и знает ограниченно греческий алфавит, но прочесть с листа формулы с участием спиноров просто не сможет.
S>Во-вторых, даже умея читать (то есть понимая отдельные лексемы), нужно еще и разбираться в применяемых идентификаторах. Ок, все непонятные слова можно рекурсивно смотреть в интернете — но скорость чтения будет весьма низкой.

S>В-третьих, всё-таки знания — это не плоский текст или картинка, это, прежде всего, некая модель в голове. Ну вот написал я вам уравнение Шредингера. Ну, прочитали вы его. Что, внезапно у вас появилось в голове понимание квантовой механики? Построить корректную модель — вот это и есть получение знаний.
S>Хрен с ними с квантами, давайте вот о программированиии. Я, допустим, упоминаю в разговоре: "здесь может пригодиться R-дерево". Ок, любой невежда может быстренько сгуглить на тему R-деревьев. Но поможет ли ему это понять, действительно ли оно здесь пригодится, т.е. ответить на вопрос, на который нет готового ответа в сети. Для того, чтобы ответить на этот вопрос, нужно реально понять, как устроено R-дерево, как оно натягивается на существующую проблематику, и т.п.
S>В итоге, новичка этот вопрос запросто отвлечёт на пару месяцев усиленного изучения. Программеру, который имеет опыт применения R-деревьев, для ответа потребуется секунда. Между этими полюсами лежат разные уровни подготовки профессионала — наличие либо отсутствие в голове готовых "строительных блоков", из которых будет строиться модель.
Очевидно что скорость чтения будет экспоненциально зависеть от того, насколько придется углубляться, студенты-второкурсники, зная такие страшные слова как лапласиан, гамильтониан и потенциальная энергия не тратят много времени для понимания уравнения Шрёдингера. Программист, знакомый с B-деревьями, быстро поймет что такое R-дерево, хотя, конечно, далеко не за секунду. В результате вместо простой ситуации наличие-отсутствие знаний/секунда-месяц на осмысление, получается довольно размытая картина.

S>Ок, теперь вернёмся к компиляторам. Вопрос, в итоге, сводится вот к чему: не окажется ли случайно курс разработки компиляторов полезным для формирования "сторонних умений", которые могут быть применимы к широкому классу задач, не связанных напрямую с компиляцией?
Безусловно окажется, и даже не случайно) но нужно все-таки помнить о чем мы говорим — о _необходимости_ этих знаний для написания качественного ПО, как заявляет топикстартер, или об общей полезности для развития ума и сравнительно редкого мгновенного практического выхлопа. Если речь о втором — то тут и спорить нечего, а если о первом — то ну никак не соглашусь, что человек, не знающий отличия LL от LR не может создавать качественные продукты и решать сложные задачи. Безусловно, чем больше строительных блоков в голове, тем лучше, но нет никакой необходимости знать в полном объеме весь computer science

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:
I>>Т.е. если дать ему SICP то резко вырастет уровень логического мышления ?
S>Естественно.

Это как, задним числом будет преодолен входной барьер ?

I>>Вот после такой подготовки можно давать общую теорию, которая и есть в SICP.
S>Сколько такой подготовки нужно? Рекомендую ознакомится с содержанием программы по предмету "информатика" за 10-11 классы.

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

11 класс. Вот такие детки учатся в мит.

S>К моменту, когда человек разобрался с "конкретными случаями", давать SICP может быть уже поздно. Получится что-то типа Павла Дворкина, который назубок разобрался с одним конкретным видом программирования, и даже его преподаёт, но такая простая штука как immutability просто не может попасть к нему в мозг. Не проходит сквозь намертво приваренную дифракционную решетку.

Это называется разделение труда.

Можно реальный пример? В стиле "я не писал компилятор, парсер и т. п., а писал совсем другую вещь — ... — и вот тут-то мне очень пригодился курс компиляторостроения"
З.Ы.: курс компиляторостроения без конечных автоматов, они понятное дело встречаются часто.

... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Sharowarsheg, Вы писали:

S>>Для Тру Программирования нужно сначала понимание предметной области.
S>А еще сначалее нужно умение быстро понимать предметную область. Потому что то понимание, которое нужно, это совсем-совсем особое понимание.

Приличная предметная область требует на понимание пару лет минимум.

S> Сколько ни говорил с глубоким специалистом в предметной области (не-программистом, ессно) — столько раз убеждался: головой пользоваться не умеет почти никто.

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

Здравствуйте, Sharowarsheg, Вы писали:

S>>>Для Тру Программирования нужно сначала понимание предметной области.
S>>А еще сначалее нужно умение быстро понимать предметную область. Потому что то понимание, которое нужно, это совсем-совсем особое понимание.

S>Приличная предметная область требует на понимание пару лет минимум.
Что за предметные области такие, что просто для понимания требуется "пару лет минимум"? Обычно же достаточно несколько недель + постоянные консультации / контроль со стороны специалиста предметной области. Иными словами, чтоб написать ПО для управления АЭС вовсе не нужно быть доктором физических наук и досконально понимать все физические/химические и т.д. процессы внутри реактора...

S>> Сколько ни говорил с глубоким специалистом в предметной области (не-программистом, ессно) — столько раз убеждался: головой пользоваться не умеет почти никто.

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

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

Здравствуйте, MescalitoPeyot, Вы писали:

MP>Можно реальный пример? В стиле "я не писал компилятор, парсер и т. п., а писал совсем другую вещь — ... — и вот тут-то мне очень пригодился курс компиляторостроения"
MP>З.Ы.: курс компиляторостроения без конечных автоматов, они понятное дело встречаются часто.

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

Здравствуйте, Sharowarsheg, Вы писали:

S>Приличная предметная область требует на понимание пару лет минимум.

Пример?
Какой уровень понмания требуется?

Здравствуйте, Voblin, Вы писали:

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

Всегда ли?

Здравствуйте, hal9000, Вы писали:

H>Уверен, что человек осиливший теорию суперструн со всеми выкладками, может стать очень продвинутым программером

Уверен, что человек осиливший теорию суперструн со всеми выкладками, мог бы стать очень продвинутым программером, если бы потратил это время на изучение computer science

Здравствуйте, gandjustas, Вы писали:

S>>Приличная предметная область требует на понимание пару лет минимум.

G>Пример?
G>Какой уровень понмания требуется?

Требуется уровень для полноценной замены спецалиста который проработал n-лет и уволился/умер/заболел/ушел в армию/ушел отпуск по уходу за ребенком/ушел на повышение/ушел на понижение.

Здравствуйте, criosray, Вы писали:

S>>Приличная предметная область требует на понимание пару лет минимум.
C>Что за предметные области такие, что просто для понимания требуется "пару лет минимум"? Обычно же достаточно несколько недель + постоянные консультации / контроль со стороны специалиста предметной области. Иными словами, чтоб написать ПО для управления АЭС вовсе не нужно быть доктором физических наук и досконально понимать все физические/химические и т.д. процессы внутри реактора...

Несколько недель это смешная цифра. Вот прикинь, работал девелопер в проекте по управлению АЭС 10 лет и спалился по разным причинам. Сколько тебе надо будет времени, что бы спокойно потянуть все задачи которые он мог потянуть ?

Здравствуйте, Ikemefula, Вы писали:

S>>>Приличная предметная область требует на понимание пару лет минимум.
C>>Что за предметные области такие, что просто для понимания требуется "пару лет минимум"? Обычно же достаточно несколько недель + постоянные консультации / контроль со стороны специалиста предметной области. Иными словами, чтоб написать ПО для управления АЭС вовсе не нужно быть доктором физических наук и досконально понимать все физические/химические и т.д. процессы внутри реактора...

I>Несколько недель это смешная цифра. Вот прикинь, работал девелопер в проекте по управлению АЭС 10 лет и спалился по разным причинам. Сколько тебе надо будет времени, что бы спокойно потянуть все задачи которые он мог потянуть ?

Как это коррелируется с минимально необходимым временем для "понимания предметной области"?

Здравствуйте, MescalitoPeyot, Вы писали:

MP>Можно реальный пример? В стиле "я не писал компилятор, парсер и т. п., а писал совсем другую вещь — ... — и вот тут-то мне очень пригодился курс компиляторостроения"
MP>З.Ы.: курс компиляторостроения без конечных автоматов, они понятное дело встречаются часто.

Как бы тебе сказать. А что если банан это не банан ?

Здравствуйте, mymuss, Вы писали:

НС>>Ну значит стадию перехода от асимптотики к реальному коду ты еще не прошел. Если что, на личности перешел ты первый.

M>Ок, лично с Вами у меня продолжать дискуссию желания нет. Я на личности не переходил и был предельно вежлив.

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

M>PS: На брудершафт с Вами не пили, так что, попрошу не тыкать. Спасибо.

Ути-пути, бедненький

Здравствуйте, komaz, Вы писали:

K>Ну ты первый начал про электролобзики и шуруповерты вместо уравнений Максвелла

Это была иллюстрация. А ты пытаешься аналогиями аргументировать.

K>А по теме — так уж ли нужны фундаментальные знания для того, чтобы пользоваться antlr и т.п.?

Фнндаментальные знания нужны, чтобы пользоваться antlr грамотно и там где нужно. Antlr не серебряная пуля, самую сложную часть работы тебе придется сделать самому. Посему, одно дело взять готовую грамматику и с нее отплодить парсер, и совсем другое спроектировать и отладить грамматику собственную.

K> Нельзя ли получить необходимый объем знаний в процессе решения конкретной задачи?

Вот конкретно в случае парсеров, как показывает моя практика, нельзя. Где то в design как то был топик, когда человек убил чуть ли не полгода на собственный парсер, и только тогда у него зачесалось, что что то идет не так.

Здравствуйте, MescalitoPeyot, Вы писали:

MP>Можно реальный пример? В стиле "я не писал компилятор, парсер и т. п., а писал совсем другую вещь — ... — и вот тут-то мне очень пригодился курс компиляторостроения"

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

Здравствуйте, criosray, Вы писали:

I>>Несколько недель это смешная цифра. Вот прикинь, работал девелопер в проекте по управлению АЭС 10 лет и спалился по разным причинам. Сколько тебе надо будет времени, что бы спокойно потянуть все задачи которые он мог потянуть ?

C>Как это коррелируется с минимально необходимым временем для "понимания предметной области"?

Понимание предметной области это не хухры мухры, набор теорем и тд и тд. Это умение определенные задачи решать за определенное время.

Здравствуйте, komaz, Вы писали:
K>Очевидно что скорость чтения будет экспоненциально зависеть от того, насколько придется углубляться, студенты-второкурсники, зная такие страшные слова как лапласиан, гамильтониан и потенциальная энергия не тратят много времени для понимания уравнения Шрёдингера. Программист, знакомый с B-деревьями, быстро поймет что такое R-дерево, хотя, конечно, далеко не за секунду. В результате вместо простой ситуации наличие-отсутствие знаний/секунда-месяц на осмысление, получается довольно размытая картина.
Да, именно это я и написал в абзаце, на который вы ответили.

K>Безусловно окажется, и даже не случайно) но нужно все-таки помнить о чем мы говорим — о _необходимости_ этих знаний для написания качественного ПО, как заявляет топикстартер, или об общей полезности для развития ума и сравнительно редкого мгновенного практического выхлопа. Если речь о втором — то тут и спорить нечего, а если о первом — то ну никак не соглашусь, что человек, не знающий отличия LL от LR не может создавать качественные продукты и решать сложные задачи. Безусловно, чем больше строительных блоков в голове, тем лучше, но нет никакой необходимости знать в полном объеме весь computer science

Вопрос интересный. Если трактовать в таком разрезе, то окажется, что вообще никакие знания не являются необходимыми для написания качественного ПО. Типа, всегда можно компенсировать отсутствие опыта с GLR наличием опыта с реляционной алгеброй. Но в контексте подготовки специалистов интересует детерминированный способ натренировать людей с широким разбросом исходных знаний до более-менее приемлемого уровня.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Ikemefula, Вы писали:
I>Требуется уровень для полноценной замены спецалиста который проработал n-лет и уволился/умер/заболел/ушел в армию/ушел отпуск по уходу за ребенком/ушел на повышение/ушел на понижение.
Ну вот я сталкивался, скажем, с отчётами в БЭСТ, которые писаны "который проработал n-лет и уволился/умер/заболел/ушел в армию/ушел отпуск по уходу за ребенком/ушел на повышение/ушел на понижение". Ну да, потребовалось примерно часа четыре на то, чтобы найти и исправить 90% косяков в его мегакоде. Если бы у меня под рукой был сам специалист, то удалось бы исправить и остальные 10% — там просто есть зоопарк интринсик функций, которые делают магические вещи. По названию понять их невозможно, а документации нет.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, criosray, Вы писали:

S>>>>Для Тру Программирования нужно сначала понимание предметной области.
S>>>А еще сначалее нужно умение быстро понимать предметную область. Потому что то понимание, которое нужно, это совсем-совсем особое понимание.

S>>Приличная предметная область требует на понимание пару лет минимум.
C>Что за предметные области такие, что просто для понимания требуется "пару лет минимум"?

Ну, какая-нибудь аэродинамика, или спектроскопия. Возможно, кстати, что и бухгалтерия тоже — не уверен, никогда не пробовал ничего похожего.

S> Обычно же достаточно несколько недель + постоянные консультации / контроль со стороны специалиста предметной области.
S> Иными словами, чтоб написать ПО для управления АЭС вовсе не нужно быть доктором физических наук и досконально понимать все физические/химические и т.д. процессы внутри реактора...

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

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Sharowarsheg, Вы писали:

S>>Приличная предметная область требует на понимание пару лет минимум.

G>Пример?
G>Какой уровень понмания требуется?

Ну возьми самый добрый пример — программирование.
Требуется, по минимуму
1. обычно (в большинстве случаев) понимать слова, которые используются в разговоре
2. не ставить программистам задач, которые непрактично решать.

Здравствуйте, Sharowarsheg, Вы писали:

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

S>Это всё хорошо, если предметная область требует хоть сколько-то дискретки.

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

Здравствуйте, Sharowarsheg, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Sharowarsheg, Вы писали:

S>>>Приличная предметная область требует на понимание пару лет минимум.

G>>Пример?
G>>Какой уровень понмания требуется?

S>Ну возьми самый добрый пример — программирование.
S>Требуется, по минимуму
S>1. обычно (в большинстве случаев) понимать слова, которые используются в разговоре
S>2. не ставить программистам задач, которые непрактично решать.

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

Здравствуйте, Sharowarsheg, Вы писали:

S>Приличная предметная область требует на понимание пару лет минимум.

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

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

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

Здравствуйте, Sinclair, Вы писали:

S>Ну вот я сталкивался, скажем, с отчётами в БЭСТ, которые писаны "который проработал n-лет и уволился/умер/заболел/ушел в армию/ушел отпуск по уходу за ребенком/ушел на повышение/ушел на понижение". Ну да, потребовалось примерно часа четыре на то, чтобы найти и исправить 90% косяков в его мегакоде. Если бы у меня под рукой был сам специалист, то удалось бы исправить и остальные 10% — там просто есть зоопарк интринсик функций, которые делают магические вещи. По названию понять их невозможно, а документации нет.

S>Впрочем, даже полрабочего дня хватило на то, чтобы полноценно заменить этого специалиста — ведь он писал отчет две недели, и сделал в нём чудовищное количество ошибок.
S>Зато он мегаглубоко вник в "предметную область" — расчёт длительности отпусков в соответствии с законодательством.

Ты привел вырожденый пример.

Здравствуйте, Ikemefula, Вы писали:

I>>>Несколько недель это смешная цифра. Вот прикинь, работал девелопер в проекте по управлению АЭС 10 лет и спалился по разным причинам. Сколько тебе надо будет времени, что бы спокойно потянуть все задачи которые он мог потянуть ?

C>>Как это коррелируется с минимально необходимым временем для "понимания предметной области"?

I>Понимание предметной области это не хухры мухры, набор теорем и тд и тд. Это умение определенные задачи решать за определенное время.

Да кто же Вам такую глупость сказал?

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

Здравствуйте, yumi, Вы писали:

S>>Это всё хорошо, если предметная область требует хоть сколько-то дискретки.

Y>Это говорит о том, что Вы дискретку не знаете или знаете, но думаете, что Вы его не знаете. Почти любая предметная область требует дискретку, хотя нет, не почти любая, а абсолютно все предметные области.

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

Здравствуйте, gandjustas, Вы писали:

S>>Ну возьми самый добрый пример — программирование.
S>>Требуется, по минимуму
S>>1. обычно (в большинстве случаев) понимать слова, которые используются в разговоре
S>>2. не ставить программистам задач, которые непрактично решать.

G>Я так понимаю, что рассматриваем предментные области за пределами программирования.

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

Здравствуйте, yumi, Вы писали:

S>>Приличная предметная область требует на понимание пару лет минимум.

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

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

Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, Lloyd, Вы писали:

L>>Здравствуйте, _d_m_, Вы писали:

___>>>Смею тебя заверить, Билл Гейтс не был этаким гением программирования.

L>>Те, кто с ним работал, были другого мнения.

___>Он скорее стратег — как Маршал Жуков, но смог бы Жуков взять живым диверсанта ака волкодав Таманцев? Разницу чуствуешь?

Жуков мог бы. Может быть не так ловко как Таманцев. Начал он свой путь от сержанта-драгуна.

Билли Гейц может быть и не гений программирования. Но он действительно программист и знает эту кухню на своей шкуре.

Здравствуйте, Lloyd, Вы писали:

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

L>Всегда ли?

Пока пространство евклидово (считаем верными геометрические аксиомы), то да. Если же выходим за рамки этих аксиом (например, рисуем треугольник на сфере), то не всегда.
Это, кстати, демонстрирует тот факт, что в математике важно не только выучить набор определений/правил/формул, но и понимать, что из чего и каким образом выведено. И, следовательно, какие границы применимости имеет.

Здравствуйте, Sharowarsheg, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>>>Ну возьми самый добрый пример — программирование.
S>>>Требуется, по минимуму
S>>>1. обычно (в большинстве случаев) понимать слова, которые используются в разговоре
S>>>2. не ставить программистам задач, которые непрактично решать.

G>>Я так понимаю, что рассматриваем предментные области за пределами программирования.

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

А зачем? Мы же не говорим что программисты круче всех.
Мы тут обсуждаем какой уровень знаний предметной области вне программирования необходим для решения задач.
Меня всегда удивляло что некоторые думают что знание предметной области важнее знания программирования.

Здравствуйте, Ночной Смотрящий, Вы писали:

K>> Нельзя ли получить необходимый объем знаний в процессе решения конкретной задачи?

НС>Вот конкретно в случае парсеров, как показывает моя практика, нельзя. Где то в design как то был топик, когда человек убил чуть ли не полгода на собственный парсер, и только тогда у него зачесалось, что что то идет не так.

Но ведь программист работает не в вакууме! Всегда есть коллеги/друзья/форумы, неужели за полгода человек не интересовался все ли правильно он делает и срок в полгода его не насторожил?

Здравствуйте, alpha21264, Вы писали:

___>>Он скорее стратег — как Маршал Жуков, но смог бы Жуков взять живым диверсанта ака волкодав Таманцев? Разницу чуствуешь?

A>Жуков мог бы. Может быть не так ловко как Таманцев. Начал он свой путь от сержанта-драгуна.

Да Жуков ваще Супермэн и Человек-Паук.

Здравствуйте, Ikemefula, Вы писали:

>Ты привел вырожденый пример.
А большинство примеров — именно такие.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

>>Ты привел вырожденый пример.
S>А большинство примеров — именно такие.

Ну допустим. ТОгда такой вопрос — прдеставь себе другого Синклера, которого создали в тот момент, когда ты начал програмировать по взрослому. При чем создали со всеми потрохами, воспоминаниями, способностями, опытом и тд и тд.

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

Допустим, ты завтра(на крайняк на следущей неделе) околеешь и ему надо будет заменить тебя глобально, а не на уровне багфикса. Сколько ему понадобится времен, что бы заменить тебя ?

Здравствуйте, criosray, Вы писали:

I>>Понимание предметной области это не хухры мухры, набор теорем и тд и тд. Это умение определенные задачи решать за определенное время.

C>Да кто же Вам такую глупость сказал?

А какуб предметную область ты имел ввиду ? Рассчет отпусков, бухгалтерия ? Это мягко говоря не предметная область.

>Умение решать "определенные задачи за определенное время" никак не связано с "пониманием предметной области" и уж точно не требуется "минимум двух лет", чтоб эффективно программировать софт. Как уже было сказано, достаточно потрать несколько недель, чтоб "войти в курс", а дальше сотрудничать со специалистом(-ами) данной предметной области.

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

Вот чудеса ! Вероятно ты супермен. Или ты под предметной областью имел ввиду её отсутствие ?

S>Например, в потоке воды нет дискретности.

алгебраическая топология только этим и занимается -- извлекает и изучает дискретные структуры из непрерывных объектов.

Здравствуйте, yumi, Вы писали:

Y>Это говорит о том, что Вы дискретку не знаете или знаете, но думаете, что Вы его не знаете. Почти любая предметная область требует дискретку, хотя нет, не почти любая, а абсолютно все предметные области.

Где используется дискретка например в бухгалтерии?

Здравствуйте, Lloyd, Вы писали:

Y>>Это говорит о том, что Вы дискретку не знаете или знаете, но думаете, что Вы его не знаете. Почти любая предметная область требует дискретку, хотя нет, не почти любая, а абсолютно все предметные области.

L>Где используется дискретка например в бухгалтерии?

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

Здравствуйте, Ikemefula, Вы писали:
I>А какуб предметную область ты имел ввиду ? Рассчет отпусков, бухгалтерия ? Это мягко говоря не предметная область.
А что это по-твоему?

I>Я правильно понимаю, тебе надо несколько недель что бы войти в курс и начать программить например NP-полные задачи на графах приближенными вычислениями или какие нибудь генетическими алгоритмами ?
С каких это пор "генетические алгоритмы" стали предметной областью?
Предметная область — это те задачи, которые предполагается решать генетическими алгоритмами.
I>Вот чудеса ! Вероятно ты супермен. Или ты под предметной областью имел ввиду её отсутствие ?
Общепринятое определение предметной области — это "часть реального мира, которую нужно отразить в модели".

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

I>>А какуб предметную область ты имел ввиду ? Рассчет отпусков, бухгалтерия ? Это мягко говоря не предметная область.
S>А что это по-твоему?

Фигня какая то.

I>>Я правильно понимаю, тебе надо несколько недель что бы войти в курс и начать программить например NP-полные задачи на графах приближенными вычислениями или какие нибудь генетическими алгоритмами ?
S>С каких это пор "генетические алгоритмы" стали предметной областью?
S>Предметная область — это те задачи, которые предполагается решать генетическими алгоритмами.

Разумеется. Я про то, что предметная оласть требует свободного владения определенным инструментарием и в две недели, даже в два месяца тут не уложиться.

Здравствуйте, Ikemefula, Вы писали:
I>Фигня какая то.

I>Разумеется. Я про то, что предметная оласть требует свободного владения определенным инструментарием и в две недели, даже в два месяца тут не уложиться.
Да ладно! Ты серьезно полагаешь, что программист, знакомый с генетическими алгоритмами, не сможет за две недели начать их применять к новой предметной области?
Никакого "владения инструментарием" предметная область не требует. Инструментарий вообще ортогонален предметной области, кроме редких вырожденных случаев.

Страшные рассказы про "программирование АЭС" сильно преувеличены — если у программиста есть хоть малейший опыт работы с АСУ ТП, то никаких сложностей он не испытает. Да, если программист не знаком с АСУ ТП, то он огребёт и в более простых случаях — но АСУ ТП это и есть инструментарий. Его можно и нужно изучать в отрыве от конкретной предметной области. А саму предметную область изучить в объеме, достаточном для автоматизации — раз плюнуть.
Вот ты считаешь бухгалтерию фигнёй — поговори об этом со своим главбухом. Там начнётся ооо! ууу! и прочее про то, как это всё немерено сложно. "Я сама тридцать лет в бухгалтерии работаю, из них двенадцать главбухом, и то всего не знаю". И часть из этого даже правда — ежеквартально выходящие поправки к законодательству доконают любого. Но с точки зрения программирования, эта предметная область устроена не сложнее лопаты — потому что программисту не нужно знать всё содержимое консультант+.

Точно так же с АЭС — программисту совершенно неважно, идет там ядерный синтез или ядерный распад.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, hal9000, Вы писали:

H>Для меня это звучит дико, поскольку считаю, что без глубокого понимания теории невозможно писать качественное ПО, с поддержкой масштабирования, с адекватной производительностью и т.д., если только не идёт речь пожизненном написании быдло-сайтиков или криворукого билинга для какой нибудь шаражки.

Сами себе и ответили , может они не хотят писать качественное по? А для очень широкого ряда задач, можно знать очень небольшой набо приемов. Радуйтесь, меньше конкурентов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Ikemefula, Вы писали:

I>>>Понимание предметной области это не хухры мухры, набор теорем и тд и тд. Это умение определенные задачи решать за определенное время.

C>>Да кто же Вам такую глупость сказал?

I>А какуб предметную область ты имел ввиду ? Рассчет отпусков, бухгалтерия ? Это мягко говоря не предметная область.

Что же это? По-моему Вы путаетесь в терминологии.

>>Умение решать "определенные задачи за определенное время" никак не связано с "пониманием предметной области" и уж точно не требуется "минимум двух лет", чтоб эффективно программировать софт. Как уже было сказано, достаточно потрать несколько недель, чтоб "войти в курс", а дальше сотрудничать со специалистом(-ами) данной предметной области.

I>Я правильно понимаю, тебе надо несколько недель что бы войти в курс и начать программить например NP-полные задачи на графах приближенными вычислениями или какие нибудь генетическими алгоритмами ?
Точно путаетесь. NP-полные задачи на графах и генетические алгоритмы никак не связаны с какой-то конкретной предметной областью.

Здравствуйте, dilmah, Вы писали:

D>алгебраическая топология только этим и занимается -- извлекает и изучает дискретные структуры из непрерывных объектов.

Так же рекомендую почитать "Конкретная математика" Д.Э. Кнута. С конца второй главы там очень тесно переплетаются дискретная математика и непрерывная.

Здравствуйте, criosray, Вы писали:

I>>А какуб предметную область ты имел ввиду ? Рассчет отпусков, бухгалтерия ? Это мягко говоря не предметная область.

C>Что же это? По-моему Вы путаетесь в терминологии.

Это фигня. Таким бредом все полки в магазинах завалены, потому и возникает иллюзия, что сменить предметную область это неделя-другая.

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

Здравствуйте, Sinclair, Вы писали:

I>>Разумеется. Я про то, что предметная оласть требует свободного владения определенным инструментарием и в две недели, даже в два месяца тут не уложиться.
S>Да ладно! Ты серьезно полагаешь, что программист, знакомый с генетическими алгоритмами, не сможет за две недели начать их применять к новой предметной области?

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

S>Никакого "владения инструментарием" предметная область не требует. Инструментарий вообще ортогонален предметной области, кроме редких вырожденных случаев.

ну да. Вероятно все программисты без искючения имеют опыт решения np-полных задач и умеют генетические алгоритмы лабать.

Вот где собака то зарыта !

S>Вот ты считаешь бухгалтерию фигнёй — поговори об этом со своим главбухом. Там начнётся ооо! ууу! и прочее про то, как это всё немерено сложно.

S>Но с точки зрения программирования, эта предметная область устроена не сложнее лопаты — потому что программисту не нужно знать всё содержимое консультант+.

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

Здравствуйте, Mr.Cat, Вы писали:

MC>Не объяснишь, как знание математики кореллирует с ведением собственного бизнеса (ака "не работать на дядечку")?

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sinclair, Вы писали:

I>>>Разумеется. Я про то, что предметная оласть требует свободного владения определенным инструментарием и в две недели, даже в два месяца тут не уложиться.
S>>Да ладно! Ты серьезно полагаешь, что программист, знакомый с генетическими алгоритмами, не сможет за две недели начать их применять к новой предметной области?

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

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

S>>Вот ты считаешь бухгалтерию фигнёй — поговори об этом со своим главбухом. Там начнётся ооо! ууу! и прочее про то, как это всё немерено сложно.
S>>Но с точки зрения программирования, эта предметная область устроена не сложнее лопаты — потому что программисту не нужно знать всё содержимое консультант+.
I>Я и говорю — потому это не предметная область вовсе, ты с ней не работаешь.
Ну давай свое определение предметной области?
Только учти что набор алгоритмов не является предметной областью.

Здравствуйте, Ikemefula, Вы писали:

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

I>ну да. Вероятно все программисты без искючения имеют опыт решения np-полных задач и умеют генетические алгоритмы лабать.
Бред какой-то! Ты вообще читаешь, что тебе пишут?

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Я серьезно думаю, что человек, который занимался бухгалтерией вынужден будет потратить вагон времен на генетические алгоритмы.
S>Ещё раз, медленно: генетические алгоритмы — это не предметная область.

I>>ну да. Вероятно все программисты без искючения имеют опыт решения np-полных задач и умеют генетические алгоритмы лабать.
S>Бред какой-то! Ты вообще читаешь, что тебе пишут?

Мне тут подумалось, что тому, кто применит генетические алгоритмы при написании программ для бухучета(например, чтобы программы сами учились отчетность подчищать), должны дать Нобелевскую премию

Здравствуйте, mymuss, Вы писали:

M>Здравствуйте, March_rabbit, Вы писали:

M_>>в данном примере есть ровно один вопрос: насколько часто должна применяться эта программа? Если раз в неделю — тогда ИМХО время ей выполнения не важно (если оно меньше недели

).

M>Согласен. Она запускается раз в сутки и рекорд был около 8 часов (я не помню, сколько тогда было записей в базе). После чего ее оптимизировали.
ну да, 8 часов работы каждые 24 — это жестко. Правда, если это ночью, и если рост времени меньше линейного при росте количества записей....

M>Ок, я готов тут признать (надеюсь, мой босс еще не выучил русский и этого не читает). Человек, написавший эту прогу, живет в Индии и получает денег мин раз в 10 меньше, чем я. Если бы он мог писать качественный софт, с которым не возникает подобных проблем, то не знаю, сколько бы я продержался на этой работе. ))) Вот такая диалектика. Но это все бизнес. Большие боссы так решили, им виднее.

M>В контексте же топика, как я и говорил, считаю, что понимание фундаментальных концепций необходимо для "тру программирования" (с). Для "фаст-фуд программирования" оно не обязательно.

Здравствуйте, hal9000, Вы писали:

H>Любая нормальная книга по ассемблеру содержит вводный курс по архитектуре процессора.
пример, пожалуйста. С описанием принципов работы кэша и конкретной реализации в паре моделей?

Здравствуйте, Ikemefula, Вы писали:

M_>>ну а теперь по пунктам: что твой листинг говорит о кеше? Об архитектуре процессора? Можно ли в ней увидеть принцип работы стека?
I>По пунктам — листинг был приведен для того, что бы показать что ассемблер не сводится к коммандам процессора. Так понятно ?

Мне как-то раз мое знание ассемблера стало боком. Я пытался на ассемблере писать для DSP процессора. Даже близкого к оптимальному коду там не получилось. И только через несколько месяцев писания на C и ковыряния получившегося ассемблерного кода я смог обогнать код, который генерит компилятор.
А попробуйте свои знания ассемблера применить для программирования вычислений на шейдерах.
К чему это все... К тому что лучше вместо знания конкретных ассемблеров понимать общие принципы работы процессоров (разных процессоров с разной архитектурой).

вот и скажи, какое отношение твой листинг имеет к цитате?

I>Для того, что бы понять как работает кеш нужно уметь писать на ассемблере на отлично. И тоже самое с архитектурой и стеком.
Ха, понять как работает кэш можно и без ассемблера. На пальцах. Ибо кэш к ассемблерам отношения не имеет — он для загрузки данных. А что есть эти данные — кешу по барабану.

То же самое и с конвейером.
В универе мы это все безотносительно ассемблера изучали, чисто теоретически.

I>>>Ну, хорошо, ты знал его на уровне комманд процессора. Сам виноват. Так устраивает ?
M_>>ну, вообще-то нормальные люди воспринимают ассемблер именно как систему команд + архитектуру процессора, а не набор макросов компилятора.

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

Здравствуйте, Ikemefula, Вы писали:

I>>>Я выделил глаголы. Предположим, люди тебя слушали раз ты им рассказывал.
G>>И они поняли, а как вообще пощупать кеш — вопрос интересный. Увидепть его влияние можно только профайлером или снимать показания счетчиков.

I>Для чего профайлер и счетчики

? Секундомера хватит. Берешь и вычисляешь функцию сто тысяч миллионов раз, а потом её же исправляешь и снова выполняешь столько же раз.
I>Сравниваешь время/кол.во выполнений и узнаешь результат.

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

Здравствуйте, Sinclair, Вы писали:

I>>Я серьезно думаю, что человек, который занимался бухгалтерией вынужден будет потратить вагон времен на генетические алгоритмы.
S>Ещё раз, медленно: генетические алгоритмы — это не предметная область.

Еще раз, медленно — я знаю это. Это инструмент. Так понятно ?

I>>ну да. Вероятно все программисты без искючения имеют опыт решения np-полных задач и умеют генетические алгоритмы лабать.
S>Бред какой-то! Ты вообще читаешь, что тебе пишут?

Разумеется. Каждое сообщение обычно по два-три раза. Серьезно.

Здравствуйте, gandjustas, Вы писали:

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

G>С чего бы это? Я занимался бухгалтерией и даже не знал о генетических алгоритмах.
G>Модель бухгалтерии вообще очень простая.

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

I>>Я и говорю — потому это не предметная область вовсе, ты с ней не работаешь.
G>Ну давай свое определение предметной области?

Определение выдумывать лень. Предметная область — телекоммуникации, телевидение, астрономия

G>Только учти что набор алгоритмов не является предметной областью.

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

Здравствуйте, March_rabbit, Вы писали:

I>>Для чего профайлер и счетчики

? Секундомера хватит. Берешь и вычисляешь функцию сто тысяч миллионов раз, а потом её же исправляешь и снова выполняешь столько же раз.
I>>Сравниваешь время/кол.во выполнений и узнаешь результат.
M_>

M_>забыл упомянуть, что функция написана на асме и загружена с дискеты

А дискета тебе зачем ? с начала 80х компы умеют работать с HDD.

Разумеется на асме. Да хоть на чем угодно, не надо никаких особых счетчиков смотреть, чт бы замерить эффект от кеша.

Специалист по ассемблеру этого не знал, наверное у нго эффект от кеша действитльно заметен только по счетчикам.

Наверное мега-алгоритмы сводят на нет труды кеширования.

Здравствуйте, March_rabbit, Вы писали:

M_>А попробуйте свои знания ассемблера применить для программирования вычислений на шейдерах.
M_>К чему это все... К тому что лучше вместо знания конкретных ассемблеров понимать общие принципы работы процессоров (разных процессоров с разной архитектурой).
M_>[/q]
M_>вот и скажи, какое отношение твой листинг имеет к цитате?

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

I>>Справочник комманд это не ассемблер. И ассеблер это не справочник комманд.
G>Ты выше написал что ассемблер — это язык. Язык определяется синтаксисом и семантикой. И то и другое можжно в справочнике команд найти.

Чушь. Смотри внимательно, одна из первых моих фунцый. Половина того, что в этом коде, нет ни в каком справочнике комманд, зато есть во многих книгах по ассемблеру.

+листинг скипнул

Если тебе до сих пор не понятно, то я могу пояснить, что возникло разногласние на предмет того, кто что вкладывает в понятие ассемблер и листингом я объяснил свою позицию.

Когда человек называет систему комманд ассемблером, неудивительно, что эффект от кеша он заметит по счетчикам.

I>>Для того, что бы понять как работает кеш нужно уметь писать на ассемблере на отлично. И тоже самое с архитектурой и стеком.
M_>Ха, понять как работает кэш можно и без ассемблера. На пальцах. Ибо кэш к ассемблерам отношения не имеет — он для загрузки данных. А что есть эти данные — кешу по барабану.

Разумеется, кеш про ассемблер ничего не знает. Ты думал мне это не известно ?

M_>То же самое и с конвейером.

M_>В универе мы это все безотносительно ассемблера изучали, чисто теоретически.

Разумеется, чисто теоретически можно вообще нигде ничего не программировать.

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

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

I>>Вообще то для одного процессора много ассемблеров и даже одни и те же комманды там могут писаться по разному.
M_>Дык, еще более непонятно, зачем ты увел разговор с архитектуры в область языка?

По архитектуре достигли полного согласия — помнится я скаал "архитектура будет бесполезна, это так. Разумеется, все наработки придётся оставить, особенно библиотечки всякие."

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

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

G>>С чего бы это? Я занимался бухгалтерией и даже не знал о генетических алгоритмах.
G>>Модель бухгалтерии вообще очень простая.
I>Я и говорю, это значт что предметной области там нет — на пальцах все можно растолковать и особых тренировок для инструментария не требуется.

I>>>Я и говорю — потому это не предметная область вовсе, ты с ней не работаешь.
G>>Ну давай свое определение предметной области?
I>Определение выдумывать лень. Предметная область — телекоммуникации, телевидение, астрономия

Ты хоть как-нибудь опиши. А то твое представление о предметных областях сильно расходится с общепринятым.

G>>Только учти что набор алгоритмов не является предметной областью.
I>Конечно не являются, зато предметная область определяет, какие алгоритмы нужны а какие нет.
Ничего она не определяет. Предметная область != набор конкретных задач.

Здравствуйте, gandjustas, Вы писали:

G>>>Только учти что набор алгоритмов не является предметной областью.
I>>Конечно не являются, зато предметная область определяет, какие алгоритмы нужны а какие нет.
G>Ничего она не определяет. Предметная область != набор конкретных задач.

Тебе из бухгалтерии виднее.

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, gandjustas, Вы писали:

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

F>т.е. знатоки непрерывной математики должны будут рулить в функциональном программировании?. ~_^

Как это связано с моим утверждением?

Здравствуйте, Sinclair, Вы писали:

S>Это очень глубокий и фундаментальный вопрос, который, на мой взгляд, совершенно внезапно получил актуальность в последние годы. Грубо говоря, надо ли учить даты правления всех этих французских Луёв, если любой идиот со смартфоном ответит на такой вопрос за 30 секунд?

В книжке "Об интеллекте" господина Джефа Хокинза есть одна интересная мысль, которую можно сформулировать примерно так: при решении задач кора головного мозга ничего не вычисляет, а лишь вспоминает. Этим, кстати, объясняется, почему сверхсложная в вычислительном плане задача ловли летящего мячика в прыжке выполняется запросто за долю секунды, а вычислительная элементарщина типа перемножения трёхзначных чисел требует мучительного вычисления в столбик на бумажке.

Чтобы нам, посетителям этого форума, успешно заниматься своим основным видом деятельности и иметь с этого много вкусного хлебушка с маслицем, нам нужно, чтобы наш основной рабочий инструмент (кора больших полушарий) как можно лучше решал задачки. А так как, согласно вышесказанному, вычислять ответ он не умеет, а умеет только "вспоминать" решение, то в наших интересах сделать так, чтобы ему было из чего вспоминать. Если мы кормим свой мозг мутными фэнтезями, домами два, блокбастерами про супергероев и игрой в дурака, то и "вспоминать" придётся из них. Мы состоим из того, что мы съели.

Что толку с того, что смартфон может за несколько секунд выдать информацию о всех возможных французских Луях, а заодно и об R-деревьях? Для того, чтобы "одной левой", на уровне интуиции находить решения сложных и запутанных проблем (и, как следствие, намазывать маслице слоем потолще), нужно, чтобы тонны подобной фигни были уже загружены в неокортекс.

Поэтому мне смешно слушать стоны типа "Ну зачем мы учим эти тычинки-пестики, эти кислоты-щёлочи? Всё равно это всё сразу забудется и в жизни точно не пригодится." Сама эта информация (конкретика) действительно забудется сразу и потом никак не пригодится. Но качественно и разнообразно тренированные нервные клеточки останутся, и верой-правдой нам послужат.

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

2. Родной язык. На поверхности — умение писать и говорить без ошибок, что само по себе уже ценно. Кроме того, даёт навык сознательной работы с совершенно сумасшедшей штукой — знакомым с детства естественным языком.
3. История. Кроме безусловно полезной передачи "памяти поколений", не хило развивает память на сложные сюжеты. А сюжеты там такие, что всякие фентези и детективы нервно курят в сторонке.
4. Литература. Отчаянная попытка подготовить подрастающее поколение к тем "сюрпризам", которые ожидают его во взрослой жизни. Кроме того, заучивание стихотворений наизусть шикарно тренирует речевую память. Кроме того, написание многочисленных сочинений шикарно тренирует способность выдавать осмысленный текст.
5. Биология. Опыт изучения объектов совершенно запредельной сложности.
6. Физика и химия. Кроме набора безусловно полезных в жизни сведений, даёт целостную картину мира и учит применять математику не только к подсчёту сдачи в магазине.
7. Иностранный язык. Многие думают, что он нужен для того, чтобы общаться с иностранцами и/или читать MSDN в подлиннике. Но он нужен не только и не столько для этого. Загрузка "альтернативной прошивки" в речевые зоны неокортекса — это упражнение, значение которого переоценить просто невозможно.

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

Здравствуйте, gandjustas, Вы писали:

G>>>Есть разные области математики. Одна область — непрерывная метаематика очень далека от компьютеров и специалист в этой области вряд ли сможет написать хорошую программу.
F>>т.е. знатоки непрерывной математики должны будут рулить в функциональном программировании?. ~_^
G>Как это связано с моим утверждением?

ФП ближе к математикам.. дискретка там может и не использоваться..

Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Lloyd, Вы писали:

Y>>>Это говорит о том, что Вы дискретку не знаете или знаете, но думаете, что Вы его не знаете. Почти любая предметная область требует дискретку, хотя нет, не почти любая, а абсолютно все предметные области.

L>>Где используется дискретка например в бухгалтерии?

C>Дискретка в программировании повсеместно встречается в виде, например, логических исчислений (конъюнкция, дизъюнкци, импликация...),

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

Здравствуйте, neFormal, Вы писали:

F>Здравствуйте, gandjustas, Вы писали:

G>>>>Есть разные области математики. Одна область — непрерывная метаематика очень далека от компьютеров и специалист в этой области вряд ли сможет написать хорошую программу.
F>>>т.е. знатоки непрерывной математики должны будут рулить в функциональном программировании?. ~_^
G>>Как это связано с моим утверждением?

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

Здравствуйте, gandjustas, Вы писали:

G>теория вычислимости

это правда кто то использует в работе?.

Здравствуйте, criosray, Вы писали:

L>>Где используется дискретка например в бухгалтерии?

C>Дискретка в программировании повсеместно встречается в виде, например, логических исчислений (конъюнкция, дизъюнкци, импликация...), в виде связных графов (частные случаи: списки, деревья). Даже кодирование информации имеет непосредственное отношение к дискретной математике: сжатие, шифрование, представление разных типов данных однообразно в виде бинарного кода и т.д.

Если так глубоко копать, то можно договориться до того, что программисту 1C никак не обойтись без детального знания устройства ОС, архитектуры компьютера и глубокого познаний в физике, в частности в квантовой.

Здравствуйте, komaz, Вы писали:

K>Но ведь программист работает не в вакууме! Всегда есть коллеги/друзья/форумы, неужели за полгода человек не интересовался все ли правильно он делает и срок в полгода его не насторожил?

Насторожил. Потому он в форум и написал. Но массу времени и сил таки уже было убито.
Но это полбеды. Есть еще один неприятный момент — очень многие считают, что парсер это очень сложно, и подсознательно избегают любых решений, связанных с разбором текста, который нельзя сделать легко регексами.
Я вот видел во вполне промышленном продукте — там нужно было задавать логические условия. И условия эти задавались при помощи рукопашного построения мышкой AST логического выражения с сохранением результата в XML. Кода на поддержку этого чуда тоже было соответственно. Как думаешь, у того, кто это придумал, было профильное образование?

Здравствуйте, Codechanger, Вы писали:

C>Мне тут подумалось, что тому, кто применит генетические алгоритмы при написании программ для бухучета(например, чтобы программы сами учились отчетность подчищать

Узко мыслишь. Вот тебе типовая задачка, где генетические алгоритмы могут пригодиться — образование родительного или дательного падежа от ФИО для формирования дефолтных значений в справочнике физлиц.

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:

S>>Это очень глубокий и фундаментальный вопрос, который, на мой взгляд, совершенно внезапно получил актуальность в последние годы. Грубо говоря, надо ли учить даты правления всех этих французских Луёв, если любой идиот со смартфоном ответит на такой вопрос за 30 секунд?

V>В книжке "Об интеллекте" господина Джефа Хокинза есть одна интересная мысль, которую можно сформулировать примерно так: при решении задач кора головного мозга ничего не вычисляет, а лишь вспоминает. Этим, кстати, объясняется, почему сверхсложная в вычислительном плане задача ловли летящего мячика в прыжке выполняется запросто за долю секунды, а вычислительная элементарщина типа перемножения трёхзначных чисел требует мучительного вычисления в столбик на бумажке.

Ошибаешься. Забываешь, что у человека не один мозг и не два.
Ловлей летящего мячика в прыжке управляет другой мозг — мозжечок. Базовые навыки движений закладываюся основным мозгом — обучение мозжечка. После того как мозжечок обучен — сформировался двигательный стереотип, главный мозг лишь вызывает необходимую подпрограмму с параметрами в мозжечке. Не забывай про еще коррекцию движений в процессе в связи с информацией от датчиков: глаз, вестибулярного аппарата, датчиков усилий в мышцах и прочее.

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

Здравствуйте, Ikemefula, Вы писали:
I>Еще раз, медленно — я знаю это. Это инструмент. Так понятно ?
Непонятно, почему ты сложность изучения генетических алгоритмов (сильно, кстати, преувеличенную) относишь к каким-то предметным областям.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, _d_m_, Вы писали:

___>Ошибаешься. Забываешь, что у человека не один мозг и не два.
___>Ловлей летящего мячика в прыжке управляет другой мозг — мозжечок.

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

Разделение всё равно весьма условное.

Здравствуйте, Ночной Смотрящий, Вы писали:

L>>Где используется дискретка например в бухгалтерии?

НС>Реляционная алгебра подойдет? Или там вокруг OLAP кубов есть много интересной математики.

Да ладно дискретка, без глубоких познаний химии тоже не обойтись. Приходишь например ты на работу, хочешь включить комп, а кнопка включения-то из пластмассы сделана! Как же с ней можно работать, не прослушав курс по химии полимеров?!
Эх, тяжело нам, программерам.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, March_rabbit, Вы писали:

I>>>Для чего профайлер и счетчики

? Секундомера хватит. Берешь и вычисляешь функцию сто тысяч миллионов раз, а потом её же исправляешь и снова выполняешь столько же раз.
I>>>Сравниваешь время/кол.во выполнений и узнаешь результат.
M_>>

M_>>забыл упомянуть, что функция написана на асме и загружена с дискеты

I>А дискета тебе зачем ? с начала 80х компы умеют работать с HDD.

I>Разумеется на асме. Да хоть на чем угодно, не надо никаких особых счетчиков смотреть, чт бы замерить эффект от кеша.
а это ничего, что кэш используется не только для твоей программы?

Кстати, ну и насколько в цифрах кэш ускорил работу программы?

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

I>Наверное мега-алгоритмы сводят на нет труды кеширования.

Здравствуйте, _d_m_, Вы писали:

___>Кстати, есть люди которые мгновенно перемножают огромные числа и запоминают горы любой информации. Дело в том, перемножение трех чисел это исскуственное нагромаждение для естественного мыслительного процесса мозга. Люди которые быстро перемножают просто придумали другой способ наиболее близкий к естественному мышллению.

Ага.

___>Например для запоминания используются ассоциации: охотник убил добычу, женщина взяла банан — что-то типа этого.

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

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

Здравствуйте, Sinclair, Вы писали:

I>>Еще раз, медленно — я знаю это. Это инструмент. Так понятно ?
S>Непонятно, почему ты сложность изучения генетических алгоритмов (сильно, кстати, преувеличенную) относишь к каким-то предметным областям.

А куда её относить, если предметная область ставит задачи, которые такими алгоритмами и решаются ?

Здравствуйте, Ikemefula, Вы писали:

I>>>Еще раз, медленно — я знаю это. Это инструмент. Так понятно ?
S>>Непонятно, почему ты сложность изучения генетических алгоритмов (сильно, кстати, преувеличенную) относишь к каким-то предметным областям.

I>А куда её относить, если предметная область ставит задачи, которые такими алгоритмами и решаются ?

И че, генетические алгоритмы применяются в какой-то одной конкретной предметной области? Ух ты, расскажи нам сирым в какой именно...

Здравствуйте, March_rabbit, Вы писали:

I>>Разумеется на асме. Да хоть на чем угодно, не надо никаких особых счетчиков смотреть, чт бы замерить эффект от кеша.
M_>а это ничего, что кэш используется не только для твоей программы?

Вижу, ты специлист. Кто его в ДОС в защищенном режиме может пользовать кроме меня, если прерывания, в т.ч. немаскИруемые запрещены ?

M_>Кстати, ну и насколько в цифрах кэш ускорил работу программы?

Не помню. В разы — минимум.

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

Я и говорю про это. Некоторых нельзя пускать к ассемблеру.

Здравствуйте, kuj, Вы писали:

I>>А куда её относить, если предметная область ставит задачи, которые такими алгоритмами и решаются ?

kuj>И че, генетические алгоритмы применяются в какой-то одной конкретной предметной области? Ух ты, расскажи нам сирым в какой именно...

Нет, разумеется

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

Здравствуйте, Voblin, Вы писали:

V>В книжке "Об интеллекте" господина Джефа Хокинза есть одна интересная мысль, которую можно сформулировать примерно так: при решении задач кора головного мозга ничего не вычисляет, а лишь вспоминает. Этим, кстати, объясняется, почему сверхсложная в вычислительном плане задача ловли летящего мячика в прыжке выполняется запросто за долю секунды, а вычислительная элементарщина типа перемножения трёхзначных чисел требует мучительного вычисления в столбик на бумажке.

V>Чтобы нам, посетителям этого форума, успешно заниматься своим основным видом деятельности и иметь с этого много вкусного хлебушка с маслицем, нам нужно, чтобы наш основной рабочий инструмент (кора больших полушарий) как можно лучше решал задачки. А так как, согласно вышесказанному, вычислять ответ он не умеет, а умеет только "вспоминать" решение, то в наших интересах сделать так, чтобы ему было из чего вспоминать. Если мы кормим свой мозг мутными фэнтезями, домами два, блокбастерами про супергероев и игрой в дурака, то и "вспоминать" придётся из них. Мы состоим из того, что мы съели.

V>Что толку с того, что смартфон может за несколько секунд выдать информацию о всех возможных французских Луях, а заодно и об R-деревьях? Для того, чтобы "одной левой", на уровне интуиции находить решения сложных и запутанных проблем (и, как следствие, намазывать маслице слоем потолще), нужно, чтобы тонны подобной фигни были уже загружены в неокортекс.

V>Поэтому мне смешно слушать стоны типа "Ну зачем мы учим эти тычинки-пестики, эти кислоты-щёлочи? Всё равно это всё сразу забудется и в жизни точно не пригодится." Сама эта информация (конкретика) действительно забудется сразу и потом никак не пригодится. Но качественно и разнообразно тренированные нервные клеточки останутся, и верой-правдой нам послужат.

V>Давайте посмотрим, как мутные и бесполезные школьные предметы помогают нам жить:
V>1. Математика. Кроме того, что помогает определить, не наё... ли нас со сдачей в магазине, даёт навык работы с чрезвычайно чёткими и жёсткими абстракциями. Полезный навык. Особенно при отладке неизвестно почему не работающих программ, которые до этого неизвестно почему работали

V>2. Родной язык. На поверхности — умение писать и говорить без ошибок, что само по себе уже ценно. Кроме того, даёт навык сознательной работы с совершенно сумасшедшей штукой — знакомым с детства естественным языком.
V>3. История. Кроме безусловно полезной передачи "памяти поколений", не хило развивает память на сложные сюжеты. А сюжеты там такие, что всякие фентези и детективы нервно курят в сторонке.
V>4. Литература. Отчаянная попытка подготовить подрастающее поколение к тем "сюрпризам", которые ожидают его во взрослой жизни. Кроме того, заучивание стихотворений наизусть шикарно тренирует речевую память. Кроме того, написание многочисленных сочинений шикарно тренирует способность выдавать осмысленный текст.
V>5. Биология. Опыт изучения объектов совершенно запредельной сложности.
V>6. Физика и химия. Кроме набора безусловно полезных в жизни сведений, даёт целостную картину мира и учит применять математику не только к подсчёту сдачи в магазине.
V>7. Иностранный язык. Многие думают, что он нужен для того, чтобы общаться с иностранцами и/или читать MSDN в подлиннике. Но он нужен не только и не столько для этого. Загрузка "альтернативной прошивки" в речевые зоны неокортекса — это упражнение, значение которого переоценить просто невозможно.

V>Самое смешное, что я не могу в этом же духе спеть осанну информатике. Я думаю, не меня одного колбасит от того, что у этого школьного предмета сейчас нет никакого "двойного дна".

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

Здравствуйте, Ikemefula, Вы писали:

I>>>А куда её относить, если предметная область ставит задачи, которые такими алгоритмами и решаются ?

kuj>>И че, генетические алгоритмы применяются в какой-то одной конкретной предметной области? Ух ты, расскажи нам сирым в какой именно...

I>Нет, разумеется

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

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

Здравствуйте, kuj, Вы писали:

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

Да, ты привел хороший пример отсутствия предметной области. Не надо знать УК что бы написать программу для милиции.

Здравствуйте, March_rabbit, Вы писали:

M_>пример, пожалуйста. С описанием принципов работы кэша и конкретной реализации в паре моделей?

Вообщем на счёт кеша, возможно The Software Optimization Cookbook (Intel press), вот ещё статейка:

http://software.intel.com/en-us/articles/recognizing-efficient-use-of-caches-in-code-for-the-itaniumr-processor-family/

Относительно неё можно дальше поискать.

Но точно я точно знаю, так это то, что программирование на ассемблере может дать хорошее представление о моделях памяти процессора.

Здравствуйте, Ikemefula, Вы писали:

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

I>Да, ты привел хороший пример отсутствия предметной области. Не надо знать УК что бы написать программу для милиции.

Отсутствие предметной области? Какую траву ты куришь?

Здравствуйте, gandjustas, Вы писали:

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

У Фейнмана, кажется, есть замечательная история про людей, которые делали механический вычислитель для зенитной стрельбы.
Ну, туда-сюда, сделали его, работает.
Приходит кто-то из военных и говорит
-- а куда тут вводить расстояние до наводчика?
-- что?
-- ну, наводчик может сидеть не в том месте, где пушка стоит, вы что, не знали?
-- 8-O
а все вычисления уже сделаны — в полярных координатах. В декартовых — не было бы проблемы, а вот в полярных (с нулем в пушке) легко не поправишь уже.

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

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

Здравствуйте, Sharowarsheg, Вы писали:

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

S>У Фейнмана, кажется, есть замечательная история про людей, которые делали механический вычислитель для зенитной стрельбы.
S>Ну, туда-сюда, сделали его, работает.
S>Приходит кто-то из военных и говорит
S>-- а куда тут вводить расстояние до наводчика?
S>-- что?
S>-- ну, наводчик может сидеть не в том месте, где пушка стоит, вы что, не знали?
S>-- 8-O
S>а все вычисления уже сделаны — в полярных координатах. В декартовых — не было бы проблемы, а вот в полярных (с нулем в пушке) легко не поправишь уже.

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

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

И какие выводы мы должны сделать из этой стены текста? Что программист должен знать предметную область лучше специалиста этой области? Было бы конечно круто. А еще было бы круто выиграть миллион баксов в лотерею.

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

Здравствуйте, kuj, Вы писали:

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

kuj>И какие выводы мы должны сделать из этой стены текста? Что программист должен знать предметную область лучше специалиста этой области?

Не лучше, но достаточно, чтобы уметь правильно понимать специалиста — желательно, с одного раза.

kuj>Пора спуститься с небес на землю, друг мой.

Мне-то зачем?

Здравствуйте, Sharowarsheg, Вы писали:

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

kuj>>И какие выводы мы должны сделать из этой стены текста? Что программист должен знать предметную область лучше специалиста этой области?

S>Не лучше, но достаточно, чтобы уметь правильно понимать специалиста — желательно, с одного раза.

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

Здравствуйте, kuj, Вы писали:

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

kuj>>>И какие выводы мы должны сделать из этой стены текста? Что программист должен знать предметную область лучше специалиста этой области?

S>>Не лучше, но достаточно, чтобы уметь правильно понимать специалиста — желательно, с одного раза.

kuj>Специалист сам себя не всегда правильно понимает, а ты хочешь, чтоб программер всегда понимал спеца с полуслова, а может еще и мысли читал? Говорю же — спускайся с небес на землю.

Не только хочу, но и добиваюсь. Предпочитаю учиться, но не спускаться.

Здравствуйте, Sharowarsheg, Вы писали:

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

kuj>>>>И какие выводы мы должны сделать из этой стены текста? Что программист должен знать предметную область лучше специалиста этой области?

S>>>Не лучше, но достаточно, чтобы уметь правильно понимать специалиста — желательно, с одного раза.

kuj>>Специалист сам себя не всегда правильно понимает, а ты хочешь, чтоб программер всегда понимал спеца с полуслова, а может еще и мысли читал? Говорю же — спускайся с небес на землю.

S>Не только хочу, но и добиваюсь. Предпочитаю учиться, но не спускаться.

Расскажи где учат на телепатов — запишусь!

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, _d_m_, Вы писали:

___>>Ошибаешься. Забываешь, что у человека не один мозг и не два.
___>>Ловлей летящего мячика в прыжке управляет другой мозг — мозжечок.

V>Ну, во-первых, не два, а больше.

Ты читать сначала научись, прежде чем тыкать пальцами в клавиатуру.

V>Во-вторых, всем работы хватает (зрительная, двигательная и многие другие области тоже задействуются, и даже речевой центр выдаёт "ё моё!"). В-третьих, какая разница, что принимает основную нагрузку — процессор или точно такой же по конструкции сопроцессор?

Разделение всё равно весьма условное.

Разница такая, что данное утверждение уже не верно:

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

Здравствуйте, Voblin, Вы писали:

___>>Например для запоминания используются ассоциации: охотник убил добычу, женщина взяла банан — что-то типа этого.

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

Не корой единой...
Кора — это все что сейчас просто худо-бедно изученно — на нее электроды легко крепить. Значительно больший объем составляет все то, что под корой

V>Чем-то это похоже на GPGPU — выполнение вычислений общего назначения на графической карте. Потом всё доводится до автоматизма, и человек начинает думать во вполне естественных для арифметики терминах, но думать "гениально".

Ну в любом случае требуется обучение. Нейроны должны создать между собой связи.
Кстати, очень интересная тема — нейропроцессоры. Процессоры созданые по модели сети нейронов.

http://www.module.ru/articles/www.osp.ru/os/1999/07/computerworld0799.htm

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, minorlogic, Вы писали:

S>>>Приличная предметная область требует на понимание пару лет минимум.
C>>Что за предметные области такие, что просто для понимания требуется "пару лет минимум"? Обычно же достаточно несколько недель + постоянные консультации / контроль со стороны специалиста предметной области.

M>Сжатие мквия данных, обработка изображений, высоконагруженные сервера, моделирование физ/хим процессов, геймдев, продолжать ?

Ржу. Сжатие данных и обработка изображений это предметные области?

Высоконагруженные сервера это предметная область?

ппц... еще один гений логики и сообразительности. ;]

Здравствуйте, _d_m_, Вы писали:

___>Ты читать сначала научись, прежде чем тыкать пальцами в клавиатуру.

Ой блин, как же мы страшны в праведном гневе!

Здравствуйте, _d_m_, Вы писали:

___>Кстати, очень интересная тема — нейропроцессоры. Процессоры созданые по модели сети нейронов.
___>http://www.module.ru/articles/www.osp.ru/os/1999/07/computerworld0799.htm

Уже больше десяти лет периодически мониторю нейрокомпьютерную тематику. Пока мнение такое: весь нейрокомпьютинг со всеми своими потрохами — унылое говно. Примитив. Не интересно.

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, _d_m_, Вы писали:

___>>Ты читать сначала научись, прежде чем тыкать пальцами в клавиатуру.

V>Ой блин, как же мы страшны в праведном гневе!

Не надо окрашивать мои посты эмоциями, которых там нет.

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, _d_m_, Вы писали:

___>>Кстати, очень интересная тема — нейропроцессоры. Процессоры созданые по модели сети нейронов.
___>>http://www.module.ru/articles/www.osp.ru/os/1999/07/computerworld0799.htm

V>Уже больше десяти лет периодически мониторю нейрокомпьютерную тематику. Пока мнение такое: весь нейрокомпьютинг со всеми своими потрохами — унылое говно. Примитив. Не интересно.

Как знать, как знать...
А распознавание лиц в реальном времени с видеокамеры? А распознавание голосов в реальном времени среди множества других?

Боюсь что с твоим стилем общения, найдется не много желающих, продолжать таковое. Удачного бана.

Здравствуйте, _d_m_, Вы писали:

___>>>Кстати, очень интересная тема — нейропроцессоры. Процессоры созданые по модели сети нейронов.
___>>>http://www.module.ru/articles/www.osp.ru/os/1999/07/computerworld0799.htm

V>>Уже больше десяти лет периодически мониторю нейрокомпьютерную тематику. Пока мнение такое: весь нейрокомпьютинг со всеми своими потрохами — унылое говно. Примитив. Не интересно.

___>Как знать, как знать...
___>А распознавание лиц в реальном времени с видеокамеры? А распознавание голосов в реальном времени среди множества других?

Нейросхема — один из многих способов решения задачи фильтрации. Один из методов аппроксимации функции многих переменных. Среди полезных свойств — малая чувствительность к количеству входных параметров. Среди неприятных свойств — длительное время обучения, непредсказуемость результатов, отсутствие строгого математического обоснования.

Распознавание лиц в реальном времени? Распознавание голосов? Я, например, распознаю лицо и голос единожды увидев и услышав человека. А нейросхема? После десятытысекратного предъявления образца? Ну-ну...

Кроме того, от распознавалки до чего-то действительно интересного — ну примерно как от элемента И-НЕ до гугл мэпса.

Здравствуйте, Ikemefula, Вы писали:
I>А куда её относить, если предметная область ставит задачи, которые такими алгоритмами и решаются ?
К инструментам, естественно. Ты что думаешь, что если некая предметная область поставит задачи, которые решаются исключительно рекурсивными алгоритмами, то эти алгоритмы автоматически станут частью этой предметной области? Проблемы с логикой налицо.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

I>>А куда её относить, если предметная область ставит задачи, которые такими алгоритмами и решаются ?
S>К инструментам, естественно. Ты что думаешь, что если некая предметная область поставит задачи, которые решаются исключительно рекурсивными алгоритмами, то эти алгоритмы автоматически станут частью этой предметной области? Проблемы с логикой налицо.

Для великих логиков я напомню с чего началось

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

Т.е. сложность, а не алгоритмы. Это к вопросу о логике. Ты часто подменяешь понятия, не знаю, специально или нет. Здесь — подменил. (И похожий случай был когда обсуждали кнутовский ассемблер

, нехорошо, становится тенденцией

)

Теперь

S>Ещё раз, медленно: генетические алгоритмы — это не предметная область.

Еще раз, медленно — я знаю это. Это инструмент. Так понятно ?

Судя по всему ты этого так и не понял. Повторяю — я знаю, что алгоритмы это не предметная область. Можешь вернуться в начало и перечитать, будет полезно.

G>Только учти что набор алгоритмов не является предметной областью.

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

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

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

Здравствуйте, Ikemefula, Вы писали:

I>И снова "сложность изучения генетических алгоритмов" — вот эта самая сложность поднимает планку для работы в конкретной предметной области. Потому что нельзя отделить предметную область от задач в ней и алгоритмов для решения задач. На бумаге можно, но денег за это почему то не платят.
Ну конечно же можно отделить предметную область от алгоритмов для решения задач.
Почему? Да потому, что в обратном случае нам бы пришлось записать в "сложность предметной области" вообще все сложности, которые были у человека в жизни перед тем, как он начал заниматься "предметной областью". Начиная с умения пользоваться горшком, продолжая умением читать и писать, и заканчивая, соответственно, генетическими алгоритмами.
Ведь любая предметная область требует умения читать и писать документы, а в промежутках между этим выполнять правила личной гигиены.

I>Посему сложность я отношу именно к предметной области. алгоритмы можешь относить куда хочешь.
Ну и неправильно относишь ты эту сложность. Мне вообще непонятно — ты какими предметными областями занимался? Просто примеры, которые ты приводишь, выглядят крайне подозрительно.

Вообще, кстати о птичках, в природе всё же бывают такие особенные предметные области, на фоне которых знание инструментария второстепенно.
Но их не так уж, чтобы и много — и в этой ветке их практически не упоминают. К примеру, помянутая тобой предметная область "управление АЭС" — полная фигня по сравнению с той же бухгалтерией, по уровню сложности.

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

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

Можно отделить, не спорю.

S>Почему? Да потому, что в обратном случае нам бы пришлось записать в "сложность предметной области" вообще все сложности, которые были у человека в жизни перед тем, как он начал заниматься "предметной областью". Начиная с умения пользоваться горшком, продолжая умением читать и писать, и заканчивая, соответственно, генетическими алгоритмами.

Сложность это понятие относительное. Потму твой вопрос не ясен.

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

Разумеется, если ты читать не умеешь или писать, то работать тебе нельзя. Омерики ты не открыл.

I>>Посему сложность я отношу именно к предметной области. алгоритмы можешь относить куда хочешь.
S>Ну и неправильно относишь ты эту сложность. Мне вообще непонятно — ты какими предметными областями занимался? Просто примеры, которые ты приводишь, выглядят крайне подозрительно.

Телекоммуникации, в основном оптические. Хватит этого ?

S>Но их не так уж, чтобы и много — и в этой ветке их практически не упоминают. К примеру, помянутая тобой предметная область "управление АЭС" — полная фигня по сравнению с той же бухгалтерией, по уровню сложности.

Ну пусть так и что ?

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

Не только задачи численного моделирования. Обычно есть хорошие специалисты которые могут хорошо поставить задачу хорошим математкам которые решат её и хорошо смогут поставить задачу программистам результаты которых проверят хорошие специалисты и так по кругу

S>Хотя и это не факт — тому же программисту, обученному вычметодам, достаточно дать уравнения, которые придумал или нашел специалист предметной области. Программисту нет нужды погружаться в детали построения сверхкороткоимпульсных лазерных установок или нелинейной спектроскопии. Для него играет роль только уравнения.

Тем не менее приходится довольно много вкуривать всякой всячины по предметной области.

Здравствуйте, Ikemefula, Вы писали:

I>Телекоммуникации, в основном оптические. Хватит этого ?
Не знаю, смотря кому. А менять предметную область тебе приходилось часто?
Просто лично я проработал пяток лет в области заказной разработки — там новая предметная область приходит в среднем раз в месяц.

I>Не только задачи численного моделирования. Обычно есть хорошие специалисты которые могут хорошо поставить задачу хорошим математкам которые решат её и хорошо смогут поставить задачу программистам результаты которых проверят хорошие специалисты и так по кругу

Хорошее у тебя "обычно". У нас вот "обычно"
1. Хорошие специалисты ставят задачу с большим трудом — у них ограниченное мышление и нулевые навыки объяснения интуитивно понятных вещей незнакомым с областью людям.
2. Хороших математиков в уравнении тупо нет — потому, что "хороший математик" в одиночку не водится, он потащит за собой всю лабу, а та — целый институт. Заказчик не готов оплачивать целый Институт Математики для того, что ему кажется плёвым делом.
3. Программисты — люди вообще простые. А вот разрабочики программного обеспечения — и есть те люди, которые должны из бэканья и мэканья "хорошего специалиста" понять существенные для задачи вещи, придумать решение, проверить его на пользователях (которые обычно так же далеки от "хороших специалистов", как и программеры), и собсно сдать.

I>Тем не менее приходится довольно много вкуривать всякой всячины по предметной области.
Ну, это не воспрещается. Ты бы поразился, сколько всего в голове хорошего одинэсника есть про бухгалтерию. Значительно больше, чем в голове среднего главбуха. Несмотря на то, что у главбуха — профильное образование + 20 лет работы по специальности. А у одинэсника — образование типа "незаконченное высшее", курсы 1с, и пять лет опыта "внедрения конфигураций".

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Sinclair, Вы писали:

I>>Телекоммуникации, в основном оптические. Хватит этого ?
S>Не знаю, смотря кому. А менять предметную область тебе приходилось часто?

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

S>Просто лично я проработал пяток лет в области заказной разработки — там новая предметная область приходит в среднем раз в месяц.

А я поработал с проектами с которыми до этого поработали программисты из области заказной разработки. Руки сами тянутся к молотку

Не потому, что плохие программисты разумеется.

S>Хорошее у тебя "обычно". У нас вот "обычно"
S>1. Хорошие специалисты ставят задачу с большим трудом — у них ограниченное мышление и нулевые навыки объяснения интуитивно понятных вещей незнакомым с областью людям.

Мышление у всех ограниченое. Разумеется задачи ставят инженеры с хорошей мат.базой.

S>2. Хороших математиков в уравнении тупо нет — потому, что "хороший математик" в одиночку не водится, он потащит за собой всю лабу, а та — целый институт. Заказчик не готов оплачивать целый Институт Математики для того, что ему кажется плёвым делом.

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

S>3. Программисты — люди вообще простые. А вот разрабочики программного обеспечения — и есть те люди, которые должны из бэканья и мэканья "хорошего специалиста" понять существенные для задачи вещи, придумать решение, проверить его на пользователях (которые обычно так же далеки от "хороших специалистов", как и программеры), и собсно сдать.

В заказной разработке так и происходит, от разработчиков уходит процентов 90% информации они это пытаются компенсировать разными методами.

I>>Тем не менее приходится довольно много вкуривать всякой всячины по предметной области.
S>Ну, это не воспрещается. Ты бы поразился, сколько всего в голове хорошего одинэсника есть про бухгалтерию. Значительно больше, чем в голове среднего главбуха. Несмотря на то, что у главбуха — профильное образование + 20 лет работы по специальности. А у одинэсника — образование типа "незаконченное высшее", курсы 1с, и пять лет опыта "внедрения конфигураций".

Бывает и так. Но "бухгалтерия" это хорошо проработая и формализованая область с известными решениями. Соответственно многим там тупо скучно и они забивают на работу.

	От:	hal9000
	Дата:	28.06.09 11:37
	Оценка:

	От:	Lloyd
	Дата:	28.06.09 12:03
	Оценка:	1 (1) +6

	От:	Mr.Cat
	Дата:	28.06.09 12:52
	Оценка:

	От:	hal9000
	Дата:	28.06.09 12:57
	Оценка:

	От:	Lloyd
	Дата:	28.06.09 13:31
	Оценка:	3 (1) +1 -1

	От:	MescalitoPeyot
	Дата:	28.06.09 17:41
	Оценка:	4 (3) +1

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	28.06.09 18:41
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	28.06.09 20:02
Оценка:	+3

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	28.06.09 22:17
Оценка:

	От:	Ночной Смотрящий
	Дата:	28.06.09 22:22
	Оценка:

От:	Anton Batenev	https://github.com/abbat
Дата:	28.06.09 22:55
Оценка:

	От:	March_rabbit
	Дата:	29.06.09 10:53
	Оценка:	1 (1)

От:	Voblin	http://maslyaew.narod.ru/
Дата:	29.06.09 14:39
Оценка:	2 (1) +2

От:	Sinclair	https://github.com/evilguest/
Дата:	30.06.09 09:17
Оценка:	+1