Вопрос к господам СиПиПиШникам и другим программистам под *nix.

нужна дискретка, общее по алгоритмам, C (без плюсов, плюсы с STL превращают человека в кодера, который даже и не знает и не может банальности сделать без STL), читай потом опять же основы по *nix, как что работает и так далее, какие сисвызовы.

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

+1 Всё зависит от того чем больше нравится заниматься. Одно время работал в конторе, там девушка была с дипломом мехмата МГУ, так она не знала, что такое связи и ключи в бд, программировала на php... Но математику знала хорошо:)

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

кодер который баналности делает без STL (или подобного) --- велосипедист, попросту необразован и непрофессионален.

>одер который баналности делает без STL (или подобного) --- велосипедист, попросту необразован и непрофессионален.

я не призываю писать каждый раз банальности, но плюсники тех что я видел - их большинство при вопросе на собеседовании "реализуйте бинарное дерево, splay например или red&black" отвечает что он не знает и зачем ему есть STL - я таких сразу не беру - ибо надо знать такие вещи ОБЯЗАТЕЛЬНО, а есть это в STL или нет - дело десятое.

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

>Но математику знала хорошо:)

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

> при вопросе на собеседовании "реализуйте бинарное дерево, splay например или red&black"

А справочник по алгоритмам выдают, или хороший программист алгоритм реализации splay-дерева постоянно в головеи держит?

>А справочник по алгоритмам выдают, или хороший программист алгоритм реализации splay-дерева постоянно в головеи держит?

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

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

Не понял тебя. Итак, идет собеседование, ты предлагаешь кандидату реализовать splay-дерево. У меня вопрос - ты ему книгу с алгоритмом выдаешь, или он должен раелизовывать так, как помнит (если помнит)? В чем смысл проверки - в том, что он должен помнить алгоритм, или в том, что он должен быть способен его реализовать по описанию?

> велосипеддостроительство получается - ты так думаешь?

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

> не надо передергивать.

И в мыслях не было.

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

// wbr

>Не понял тебя. Итак, идет собеседование, ты предлагаешь кандидату реализовать splay-дерево. У меня вопрос - ты ему книгу с алгоритмом выдаешь, или он должен раелизовывать так, как помнит (если помнит)? В чем смысл проверки - в том, что он должен помнить алгоритм, или в том, что он должен быть способен его реализовать по описанию?

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

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

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

> я прошу реализовать дерево, то которое он помнит.

Интересно, много ли людей помнят такие алгоритмы достаточно детально для реализации. Я - точно не помню. Зачем - для того, чтобы попасть к тебе на работу?

> а если это не кресты ? или на крестах свет клином сошелся

Этот тред - он о Си++ в основном, и OP интересовался именно Си++.

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

Не завязан _сильно_, но всё-таки завязан.

>Интересно, много ли людей помнят такие алгоритмы достаточно детально для реализации. Я - точно не помню. Зачем - для того, чтобы попасть к тебе на работу?

много и представляют как это работает и не "потому что это есть в STL и мне ничего не нужно знать кроме того что это есть в STL"

>Этот тред - он о Си++ в основном, и OP интересовался именно Си++.

ну ладно. хотя кресты та еще гадость.

>Не завязан _сильно_, но всё-таки завязан.

завязан в плане что на языке A он быстрее что то сделает, но и на языке B тоже только медленнее, а если надо то быстро изучит язык C, и это только благодаря тому что у него есть базовые знания, а не потому что он знает что это есть в STL.

>завязан в плане что на языке A он быстрее что то сделает, но и на языке B тоже только медленнее, а если надо то быстро изучит язык C, и это только благодаря тому что у него есть базовые знания, а не потому что он знает что это есть в STL.

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

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

>>Интересно, много ли людей помнят такие алгоритмы достаточно детально для реализации. Я - точно не помню. Зачем - для того, чтобы попасть к тебе на работу?

>много и представляют как это работает

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

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

Фигассе "интересная работа" - реализовывать двоичные деревья :)

Как раз удел кодеров - кодировать описанные в справочниках алгоритмы. А вот программисту достаточно _знать_ оценки сложности алгоритмов, чтобы выбрать более подходящий (или придумать, адаптировать).

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

ЗЫ: Реализация двоичного дерева это тестовое задание, а не работа.

>Интересно, много ли людей помнят такие алгоритмы достаточно детально для реализации. Я - точно не помню.

многие если и не помнят в деталях, то поразмыслив вполне могут восстановить.

>Зачем - для того, чтобы попасть к тебе на работу?

чтобы понимать что именно ты используешь и зачем.

>>Зачем - для того, чтобы попасть к тебе на работу?

>чтобы понимать что именно ты используешь и зачем.

Ну что за максимализм :( Чтобы использовать сверло, нужно точно знать химический состав инструментальной стали?

>Ну что за максимализм :( Чтобы использовать сверло, нужно точно знать химический состав инструментальной стали?

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

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

Или представь себе автомеханика, который нихрена не шарит как работают компоненты автомобиля.

Достаточно аналогий?

>Ну что за максимализм :( Чтобы использовать сверло, нужно точно знать химический состав инструментальной стали?

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

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

> программист - это не пользователь инструмента, по крайней мере в данном случае, а разработчик инструмента

Программист - это _одновременно_ и пользователь, и разработчик инструментов. Он пользуется одними инструментами, чтобы разработать другие. И ему необходимо детально понимать то, что он разрабатывает, но только приблизительно - как работает используемый им инструмент. Насколько глубоко ты знаешь, как работает компилятор? СУБД? Контроллер PCI?

> Достаточно аналогий?

Более чем достаточно для того, чтобы я пожалел о том, что использовал всего одну.

> судя по твоим словам ты обычный кодер.

Эксперты ЛОР уже давно установили, что я - codemonkey :)

Алпекс, научи уже детей ебаться?

Чем отличается кодер от разработчика?

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

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

Но сказано: ...Каждый программер должен:
(1) запрограммировать бинарное дерево
(2) создать и заселить \home
(3) воспитать еще одного программера

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

Вообще-то в оригинале речь шла о splay-дереве, и его я и в самом деле запрограммировать не могу. Двоичное дерево - а какое именно двоичное дерево вам нужно? Сбалансированное? Их много разных. Несбалансированное? Это любой сможет.

> ...Каждый программер должен:

> (1) запрограммировать бинарное дерево

B+ покатит за отмазку? :)

> (2) создать и заселить \home

И \home, и /home - неоднократно :)

> (3) воспитать еще одного программера

Пока получается их только строить :/

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

с этим я и не спорю.

>И ему необходимо детально понимать то, что он разрабатывает, но только приблизительно - как работает используемый им инструмент. Насколько глубоко ты знаешь, как работает компилятор? СУБД? Контроллер PCI?

Все зависит от задачи.

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

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

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

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

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

>Чем отличается кодер от разработчика?

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

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

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

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

Раз ты участвовал в реализации СУБД, это не очень подходящий пример. Но всё же - ты знаешь ее архитектуру РСУБД и то, как она работает "в общем". А, например структуру страниц или WAL System R знаешь? Или особенности реализации SQL в DB2 на OS/390?

> и задачи на которых ее выгоднее использовать чем реляционные СУБД.

Это отчасти университетский курс СУБД, отчасти - понимание практической задачи.

> Насчет PCI - не знаю, мне не к чему.

Как же так - ведь ты _постоянно_ используешь PCI-устройства. Можно сказать, это твой главный инструмент 8)

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

Оп-па... консенсус. Именно это я и пытаюсь сказать. Детали нужны очень редко а когда нужны - их лучше посмотреть в справочнике. А кодера от программиста отличает то, что программист знает, в какие справочники заглядывать :)

Давайте определимся:

(1) Базовые вещи надо знать и уметь программировать.

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

(3) Про остальное надо знать где искать документацию/руководства.

В п.1 попадают распространенные виды деревьев, списки, словари и распространенные алгоритмы работы с ними, всякие шаблоны программирования (напр., фабрика классов), и пр.пр.пр.

Реляционные СУБД, компиляторы, алгоритмы распознавания образов на основе нейронных сетей попадают в п.2.

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

Дьявол в мелочах. Все дело в том, как именно распределить конкретные знания и умения. Альфекс считает, что splay-дерево относится к 1, а я - что к 2 или даже 3. А вот знание шины PCI я бы занес в 2.

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

Ну вот согласия с точностью до епсилон мы достигли. :)

Конкретное наполнение п.2 и п.3 зависит от специализации.

> Ну вот согласия с точностью до епсилон мы достигли. :)

осталось выяснить, входит ли в 1 реализация splay-дерева 8)

> (3) Про остальное надо знать где искать документацию/руководства.

0. нужно быть легко восприимчивым к новой [забытой] информации. любой.
1. нужно уметь на базе имеющегося опыта адаптировать новую информацию к требуемым задачам.
2. нужно знать где и как искать информацию.
3. нужно знать где и как искать информацию.
....
99. нужно знать где и как искать информацию.
100. нужно знать базовые вещи.
....
1000. нужно знать, что такое сплей-дерево.
10^01. -//-//- что такое Linux.

// wbr

>Как же так - ведь ты _постоянно_ используешь PCI-устройства. Можно сказать, это твой главный инструмент 8)

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

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

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

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

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

> Но сказано: ...Каждый программер должен:
> (1) запрограммировать бинарное дерево

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

> (2) создать и заселить \home

?

> (3) воспитать еще одного программера

на это способны редкие единицы. это чрезвычайно жёсткий критерий и в 99% случаев он не проходит.

// wbr

> 0. нужно быть легко восприимчивым к новой [забытой] информации. любой.

да, забыл самое главное: Хороший Программист в первую очередь обладает чрезвычайно развитой интуицией.

// wbr

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

Ты крут! Мне понадобится часа два, не меньше :)

>Хотя мне и смешно отнесение РСУБД и компиляторов в 2

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

>(насчет нейронных сетей не знаю - не компетентен)

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

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

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

>Я бы только добавил, что само умение искать и понимать найденное - это едва ли не самое главное.

полный +1

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

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

> кстати, что ты будешь делать если вдруг придется вести разработку на платформе, где нет stl (ну вот не сложилось), а какой-то функционал из нее тебе нужен? лезть в справочники и перечитывать про работу со структурами данных и алгоритмы?

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

>>Хотя мне и смешно отнесение РСУБД и компиляторов в 2

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

Пункт 2 - это "умение сходу их запрограммировать необязательно (хотя и желательно)". Умение "сходу запрограммировать" РСУБД вызывает у меня улыбку.

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

не суть важно, я ж не зря в кавычках написал ;)

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

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

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

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

>Пункт 2 - это "умение сходу их запрограммировать необязательно (хотя и желательно)". Умение "сходу запрограммировать" РСУБД вызывает у меня улыбку.

да-да, это тоже улыбнуло :) хотя помнится в бытность студентом писали и СУБД и компилятор (простенькие правда, но все же).

вот сижу я допиваю кружку пива и думаю: а что вы там медленно пишете? сами флейм затеяли а на площади ни души. хоть хорони. вот допью я её и спать пойду так как скучно как в морге :-/

// wbr

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

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

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

а сколько ты забудешь лет через 10 :D

> множество должно быть побольше, ибо это твое преимущество перед сотнями тысяч других программеров

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

> сами флейм затеяли

алфекс, затеявший флейм, потерял к нему интерес и ушел, а мы практически достигли консенсуса :)

> алфекс, затеявший флейм, потерял к нему интерес и ушел, а мы практически достигли консенсуса :)

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

и эти вопросы вы желаете задавать, допустим, на собеседовании кандидата на пост Умного Разработчика? на зубрёжку? чтобы слёту выдал на ура? смех да и только... :-/

ps: да, как собеседовавший и не раз. это btw одно из самых трудный пожалуй вещей - провести грамотное и адекватное желаемому собеседование. не много кто на это способен.

// wbr

> да кривой консенсус что говорить.

А по-моему, нормально

> я и слова то такого не знаю - балансировка деревьев

Каку кружку пива допиваешь? ;)

> оптимизировать подумав дважды имея на руках уже проверенный макет.

Мы все всегда так и делаем

> и эти вопросы вы желаете задавать, допустим, на собеседовании кандидата на пост Умного Разработчика? на зубрёжку? чтобы слёту выдал на ура?

Я - точно не желаю

> смех да и только... :-/

Вот и мне тоже грустно

> ps: да, как собеседовавший и не раз. это btw одно из самых трудный пожалуй вещей - провести грамотное и адекватное желаемому собеседование. не много кто на это способен.

Воистину так. У меня не получается :(

это да, но с кем спорить то будем? где Агент Смитт? :)

// wbr

>и эти вопросы вы желаете задавать, допустим, на собеседовании кандидата на пост Умного Разработчика? на зубрёжку? чтобы слёту выдал на ура? смех да и только... :-/ >ps: да, как собеседовавший и не раз. это btw одно из самых трудный пожалуй вещей - провести грамотное и адекватное желаемому собеседование. не много кто на это способен.

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