Хочу поюзать, что пишет ЮЗ 2

← →
VMcL © (2005-05-26 19:08) [160]

>>Игорь Шевченко © (26.05.05 19:06) [159]

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

← →
Игорь Шевченко © (2005-05-26 19:12) [161]

VMcL © (26.05.05 19:08) [160]

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

← →
Суслик © (2005-05-26 19:18) [162]

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

Всяко бывает.

← →
DiamondShark © (2005-05-26 19:18) [163]

> Игорь Шевченко © (26.05.05 19:05) [158]

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

← →
DiamondShark © (2005-05-26 19:21) [164]

> Игорь Шевченко © (26.05.05 19:12) [161]

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

А экспертов по согласованию действий экспертов, кажется, нет ;)

← →
Игорь Шевченко © (2005-05-26 19:23) [165]

Суслик © (26.05.05 19:18) [162]

Я вроде на ММП говорил тебе про дела с точки зрения прибыли ?

DiamondShark © (26.05.05 19:18) [163]

> Попробуйте определить, что такое, к примеру, "эксперт в
> области СУБД", или, скажем, "эксперт в области системного
> программирования".

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

← →
Игорь Шевченко © (2005-05-26 19:24) [166]

DiamondShark © (26.05.05 19:21) [164]

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

Это безусловно. Еще Козьма Прутков отметил :)

← →
Суслик © (2005-05-26 19:27) [167]

> [165] Игорь Шевченко © (26.05.05 19:23)

Резинотехнические изделия?
Не согласен.

> безотносительно системы конкретного производителя.

А толку то? Вернее, теорию, кончено, нужно знать. Но нужно знать и конкретный сервер. Если хочешь писать хорошие запросы должен знать как работает оптимизатор. А это исключительно опыт. ИМХО.

← →
Игорь Шевченко © (2005-05-26 19:32) [168]

Суслик © (26.05.05 19:27) [167]

> Не согласен.

С точки зрения прибыли ? А зря не согласен.

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

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

← →
VMcL © (2005-05-26 20:53) [169]

>>Игорь Шевченко © (26.05.05 19:12) [161]

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

← →
Сергей Суровцев © (2005-05-26 23:21) [170]

Юрий, Вы бы лучше тактико-технические даные своего интерпретатора обнародовали, конечно без выдачи гос.тайны. :)

Это, правда, куда интереснее, чем читать рассуждения о том, чего должны-не должны делать программисты-непрограммисты и программисты ли они после этого? :)

Тема, смею надеяться, заинтерисует многих.

← →
Piter © (2005-05-26 23:44) [171]

Игорь Шевченко © (26.05.05 17:34) [140]
Я повторю вопрос - откуда у тебя такие оценки численности, как в посте [134] ?

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

False_Delirium © (26.05.05 17:58) [141]

еще раз повторяю:

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

ЭТО ЗАДАЧИ ПРОГРАММИСТА? РАСЧЕТ ТРАЕКТОРИИ ПОЛЕТА ЭТО ТОЖЕ ЗАДАЧА ПРОГРАММИСТА?

Сложно представить, кто нужен ещё для написания компилятора, кроме программистов

Ну хорошо, я переформулирую. Из 200 человек 170 будут программисты.

VMcL © (26.05.05 18:05) [144]
Программист <> кодер. ИМХО.

вот тут да, это очень сложно. Программирование - прикладное искусство...

← →
Игорь Шевченко © (2005-05-26 23:51) [172]

Piter © (26.05.05 23:44) [171]

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

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

> Программирование - прикладное искусство...

Декоративно-прикладное. Сродни макраме.

← →
Сергей Суровцев © (2005-05-27 00:27) [173]

>Игорь Шевченко © (26.05.05 23:51) [172]
>Декоративно-прикладное. Сродни макраме.

Тогда уж народный промысел.

← →
Marser © (2005-05-27 00:29) [174]

> VMcL © (26.05.05 19:08) [160] [Новое
>сообщение][Ответить]
>>>Игорь Шевченко © (26.05.05 19:06) [159]
>
> Лучше быть экспертом в одной или нескольких областях и
> при этом неплохо разбираться во многих других. IMHO.

Настоящий специалист должен знать немного обо всём и всё о немногом.
(С)

← →
Игорь Шевченко © (2005-05-27 00:35) [175]

Marser © (27.05.05 00:29) [174]

Именно!

← →
Юрий Зотов © (2005-05-27 05:47) [176]

> Piter © (26.05.05 17:30) [138]

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

????????????

Прокол №3. Сорри, но факт. Выхожу из дискуссии. Поскольку мы говорим на разных языках.

← →
Суслик © (2005-05-27 11:35) [177]

> [168] Игорь Шевченко © (26.05.05 19:32)

По поводу серверов.

Если бы ты, Игорь, был прав в своем примере с пультами от телевизора, то не было бы понятия сертифицированного специалиста в ms sql server (скажем), который знает физическую организацию именно этого сервера, правила страничной подкачки, правила кластеризации и исходя из этого может выбрать конкретную архитектуру конкретной задачи, которая приводила бы к тому, что запросы будут выполняться наибыстрейшим образом.

Несколько не вижу смысла в дискуссии, т.к. я могу таким же образом сказать, что знаю большинство языков (современных!): ++, #, java, delphi (есно) + php, perl и пр. На каждом из них я смогу что-то написать, что-то без справки, что-то со справкой. Плюс к этому могу построить (но скорее с книжкой) грамматику современного языка. Но я же не специалист в языках от этого! Хотя согласно твоему определению специалиста в области СУБД (напомню: эксперт в области СУБД обладает знаниями о теории работы СУБД... <skipped т.к. здесь не важно>), я являюсь специалистом в языках.

Конкретика и резинотехнические изделия - вот залог успеха (финансового). ИМХО.

Замечу, что я не отношу себя к последнему высказыванию: я еще не дорос до этого уровня, я только к этому стремлюсь :)

← →
Игорь Шевченко © (2005-05-27 12:17) [178]

Суслик © (27.05.05 11:35) [177]

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

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

> Конкретика - вот залог успеха
> (финансового).

An expert is one who knows more and more about less and less until he knows absolutely everything about nothing. (с)

← →
Суслик © (2005-05-27 12:24) [179]

> [178] Игорь Шевченко © (27.05.05 12:17)

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

Не согласен, т.к. это идеализм.

← →
Игорь Шевченко © (2005-05-27 12:30) [180]

Суслик © (27.05.05 12:24) [179]

В том, что одну и ту же нетривиальную задачу в большинстве случаев можно решить разными способами, у тебя сомнения есть ?
(Достаточно походить по тематическим форумам)

Тогда почему ты считаешь, что мой пример - это идеализм ?

← →
DiamondShark © (2005-05-27 12:31) [181]

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

← →
Суслик © (2005-05-27 12:46) [182]

> [180] Игорь Шевченко © (27.05.05 12:30)

Вспомни, когда я вступил в дискуссию: я возразил на твое высказвание о том, что спец по СУБД должен разбираться в теории без привязки к конкретному серверу.

Я выделил спец по СУБД потому, что спец во СУБД ИМХО должен именно разбираться именно в серверах СУБД, а не просто знать теорию, которую знает любой профильный студент. Спец должен обладать огромным опытом работы с конкретным сервером(и), т.к. именно этот опыт может повлиясть на решение задачи.

Я хоршо пишу запросы sql для нашей базы. Что значит хорошо? Это значит, что я их пишу а) правильно (т.е. они работают) б) от оптимального запроса по времени выполнения они отличиются максимум в 2 раза. И именно это двухкратное ускорения дает именно специалист в ms sql, а не вообще в теории СУБД. При этом, часто суть запроса не меняется. Меняются хинты, явные преобразования типов, явное указание индексов и пр. Возможность такой оптимизации очевидное следствие знания конкретного сервера, а не просто теории (похоже я повторяюсь :))))

← →
Суслик © (2005-05-27 12:49) [183]

2Шевченко.

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

В смысле того, что решений конкретной задачи может быть много ты абсолютно прав. Но ИМХО выбор макроахитектуры системы не входит в компетенцию спеца по СУБД.

← →
Игорь Шевченко © (2005-05-27 12:53) [184]

DiamondShark © (27.05.05 12:31) [181]

> неких общих принципов построения движков вообще.

Я именно это имею в виду.

Суслик © (27.05.05 12:49) [183]

> Зачастую сейчас системы строятся не только на классических
> СУБД аля клиент-сервер. Часто используются сервера приложений
> и многое доругое.

Ну там свои эксперты, не так ли ?

← →
Суслик © (2005-05-27 13:02) [185]

> Я именно это имею в виду.

а мне кажется вы о разных вещах с Акуличевым говорите :)

← →
Piter © (2005-05-27 16:56) [186]

Игорь Шевченко © (26.05.05 23:51) [172]
Смею заметить, что любая серьезная военная система гораздо сложнее компилятора

Да ну вас... вы хоть читали, что я пишу?

Юрий Зотов © (27.05.05 5:47) [176]
Прокол №3

а-а-а, так вы свели все к подсчету проколов :)
Да пожалуйста, я не против :)

Выхожу из дискуссии

как угодно

спорщик-террорист, Адназначна )

> Piter © (27.05.05 16:56) [186]

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

Известно, что один раз - случайность, два раза - совпадение, три раза - система. Вот и весь "подсчет".

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

Юр, раскрой серкрет, ты грамматику Pascal сам писал или где-то взял?

Юрий Зотов © (27.05.05 17:09) [188]
А раз система - значит, продолжать нет смысла.

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

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

Гы-гы :)
Дима, ты очень высокого мнения о профильных студентах?
Я ещё таких не встречал :)
Может познакомишь? ;)

2 Piter ©
Странное у тебя представление о программистах :)
ИМХО то, что ты называешь "кодер" - это демо-версия программиста, с урезанной функциональностью.
Такие могут быть разве что в Очень большой конторе с большой иерархией, с присутствием Главного архитектора, помошников архитектора по различным направлениям, у которых по несколько отделов, в каждом из которых есть свой руководитель, и только в самом низу - "кодер", который зажат в жесткие рамки конкретного ТЗ и правил кодирования.

Cobalt © (28.05.05 16:34) [193]

Cогласен, что это сложный вопрос. Программирование - прикладное искусство (если не считать задачек, типа вывести программе свой исходный код). Поэтому программист еще должен быть кем-то. Но вот насколько?

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

А в реальности еще все сложнее...

В общем, флейм :)

http://www.google.ru/search?hl=ru&lr=&oi=defmore&q=define:CODER

Эх, загубили ветку, а так все хорошо начиналось.

2 Piter © (29.05.05 04:20) [194]
> То есть, программист должен знать математику, но вот насколько глубоко?

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

Программист - это умение строить алгоритмы + знание некого языка и понимание прикладной области.

Хочу поюзать, что пишет ЮЗ 2 Найти похожие ветки