>Хватит уже оправдываться так вызывающе.

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

> Вообще этот вопрос про программистов и математиков считаю надуманным. Ни в одном нормальном проекте ни в одной нормальной конторе у программиста просто не будет времени на проведение всяких там наунчных математических выкладок. Для этого наймут отдельного человека - математика.

Примерно год назад надо было починить одну глючащую программку. Программка проверяла корректность проводников на печатной плате. Направления проводников кратны 45 градусам. Программист (не знающий математики) породил 8*8=64 ветки алгоритма для проверки пересечений отрезков. Разумеется в двух ветках из этих 64 были ошибки.

Ну и чего вы взбудоражились-то?? Человек тот может быть в школе еще учиться, в 4-ом классе. :-) А вы тут уже развели флейм на 2 страницы.

учится

Ты посмотри - по ссылке ч-к не может даже применить показанные ему формулы, а не то что не помнит.

>и в данный момент не помню, как берутся производные, - я безнадёжен? :)

Да.

Программисты гумманитарии.

>Вообще-то прогрммисту нужно уметь думать, рассуждать, понимать логику, находить ошибки. Можно ли этому научиться без математики?

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

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

>Читал недавно книжку про оптимизацию SQL запросов в Оракле. Там тот же матан, теория массового обслуживания, статистика. Методом тыка покопаться до причины плохой производительности СУБД почти невозможно.

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

Хотел бы я узнать как может матанализ ускорить выборку по не индексированному полю?

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

Голуб дядка конечно хороший, но... я не соглашусь.

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

в данном случае программа - это условность. это может быть связка из DC каждый по сотне серверов и десяткам тысяч различных 'программ' в обычном понимании. а может быть и 'hello world!'. не важно.

программисты служат не абстрактным сущностям. программисты служат людям. а пути людей мягко говоря неисповедимы :)

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

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

// wbr

>>Читал недавно книжку про оптимизацию SQL запросов в Оракле. Там тот же матан, теория массового обслуживания, статистика. Методом тыка покопаться до причины плохой производительности СУБД почти невозможно.

>А там и копаться нечего, если изначально база спроектирована правильно, то и поведение её предсказуемо.

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

>Хотел бы я узнать как может матанализ ускорить выборку по не индексированному полю?

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

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

"если такой умный.." (с)
шо ж ты тут делаешь то, родной? :)

// wbr

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

ОЛОЛО!!!

>ну да, а кто не служил в армии и не чистил сортиры зубной щеткой тот типа и не мужик вообще

матан ужасен. но он развивает мышление и учит проходить через жизненные трудности.

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

>"если такой умный.." (с) шо ж ты тут делаешь то, родной? :)

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

Еще он воспитывает силу воли, честность и учит кодексу Бусидо.

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

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

>http://www.sql.ru/forum/actualthread.aspx?bid=24&tid=654843

"Пишу я на дельфи."

Ещё вопросы?

>"Пишу я на дельфи."

Этничо, что в "Справочнике..." Р. Джордейна примеры на бэйсике? Или Вас это беспокоит?

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

>>А там и копаться нечего, если изначально база спроектирована правильно, то и поведение её предсказуемо.

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

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

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

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

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

>Тебе надо сказать, что и все реальные структуры данных спроектированы через жопу или сам догадаешься? :)

Нууу! Кагба помягше выразиться? Жили-были Буца и Баца, Буца хотел Баца, а Баца не Буца. Вроде к теме это никакого отношения не имеет, но зачем баца с "реальные структуры данных спроектированы через жопу" если можно сразу всё делать правильно или хотя-бы взять готовое решение как шаблон, если своих мозгов не хватает? Или любители ООП не в курсе, что их любимое ООП - это в первую очередь данные, а уж потом код и если неудачно выбрать модель данных, то проще зарезать проект, чем его переделывать?

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

> Или любители ООП не в курсе, что их любимое ООП - это в первую очередь данные, а уж потом код и если неудачно выбрать модель данных, то проще зарезать проект, чем его переделывать?

Ну это ты у них спрашивай, я-то тут причём?

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

Блажен кто верует.

>Блажен кто верует.

Amen!

Сюрпризы для бухгалтеров.

>Т.е., бухгалтеры, сюрприз, творческие люди.
>Или сантехники..

А при чём здесь бухгалтеры и сантехники?