Здравствуйте, Undying, Вы писали:
НС>>Нет, ничего подобного я не утверждал даже близко. U>Т.е. технологи при написании кода все-таки нужны?
Я где то утверждал обратное?
НС>>Нет, я просто знаю что доказательства по аналогии логически некорректны. U>Так как тогда учиться на чужих ошибках?
Не вижу связи между высказываниями.
НС>>О том что ты вывернул мои слова на прямо противоположные. U>То чего ты занудный.
Ага, на демагогию не поддаюсь.
U> Я не выворачивал твои слова наизнанку
Именно это ты и сделал.
U>>>Ты меня вообще читаешь? Я уж давно признал, что если использовать на собеседовании задачи как первичный фильтр, то задача переворота списка может быть неплохим, хоть и дорогим вариантом. НС>>Ты несколько другое писал. U>
U>Признаю твою правоту. Я думал вы так специалистов-кодеров отбираете, а учитывая, что они вам не нужны, то это хорошая задача для первичного отбора.
Здравствуйте, Tanker, Вы писали:
T>Кажись тебе хочется выдать за доказательство суждение по методу аналогии.
Нет, не хочется. Поскольку тут спор и обоснование изложенной теории, а не мозговой штурм и попытка теорию придумать, то индукция сразу отпадает. Остается единственное корректное применение аналогии — в качестве иллюстрации. Но при этом обязательно рядом должны быть доказательства утверждения, чего мы не наблюдаем. Так что имеет место быть классический случай доказательства по аналогии.
T>То есть, не надо бояться аналогий.
Это не значит что аналогии можно применять для доказательства.
Здравствуйте, Ночной Смотрящий, Вы писали:
T>>Кажись тебе хочется выдать за доказательство суждение по методу аналогии.
НС>Нет, не хочется. Поскольку тут спор и обоснование изложенной теории, а не мозговой штурм и попытка теорию придумать, то индукция сразу отпадает. Остается единственное корректное применение аналогии — в качестве иллюстрации. Но при этом обязательно рядом должны быть доказательства утверждения, чего мы не наблюдаем. Так что имеет место быть классический случай доказательства по аналогии.
Для иллюстрации достаточно пояснений и они приведены. Как только появятся доказательства, то аналогия в тот же момент станет вполне рабочей теорией.
Здравствуйте, Tanker, Вы писали:
T>Для иллюстрации достаточно пояснений и они приведены. Как только появятся доказательства, то аналогия в тот же момент станет вполне рабочей теорией.
Вот только это все уже заявлено как рабочая теория, а не как попытка индукции.
Здравствуйте, Undying, Вы писали:
U>Давно опробована. Вон у нас Панкратов в секции был, ныне гросс который, так он в 8 лет играл в силу кандидата в мастера. А подавляющее большинство остальных занимающихся и в 16 лет играли намного хуже.
8 лет вполне нормально для КМС, здесь нет ничего необычного. Вот если бы он до уровня гроссов дошел в этом возрасте — вот что странно. Собтсвенно уровень гроссов менее чем за 10 лет достигают уникумы.
I>>А я где то говорил что надо всё знать ? Вот скажем если ты понимаешь, что такое производная,то не надо запоминать все производные всех функций, можно взять и вывести все что тебе надо.
U>И какую часть нужного на практике составляют производные? Большинство инженеров за свою жизнь ни разу не сталкивается с применением производных на практике.
Я объясняю простую вещь — понимая основы нет необходимости запоминать.
U>Это я ни к тому, что математику в школе изучать не надо, т.к. для становления мышления она полезна. Но надо понимать, что математика и инженерная деятельность это совершенно разные вещи, хоть изредка и пересекающиеся.
Тем не менее в инженерном деле есть такая же база, как и в математике, то есть, не надо зазубривать.
U>Чтобы задетектить достаточно очень общих знаний, вроде того, что нормальное время сортировки это n*log(n), поиска по ключу — О, поиска в сортированном списке log(n). И чтобы подобные общие знания передать требуется немного времени при наличии о обучаемого способностей.
U>По такой логике написание программных продуктов вообще невозможно. Т.к. на любом реальном проекте регулярно встречаются принципиально новые задачи. И если на каждую такую задачу искать спеца, который имеет знания и опыт решения таких задач, то проект никогда не будет закончен.
Ты похоже не слышишь, что я говорю. Нет необходимости в таких спецах, если у тебя есть некотрая база. Если хорошо понимаешь, что такое "разделяй и властвуй", то легкой поймешь любой алгоритм и сможешь проанализировать его. Еще раз — любой.
U>Если вам постоянно нужна математика на проекте, то, значит, да, желательно иметь адекватного выпускника прикладной математики, который и будет консультировать остальных по сложным вопросам и наиболее математически сложные места сам кодить. Всем-то программистам зачем мегаматематиками быть?
Так и есть. Математики решают довольно сложные задачи, из за мелких проблем, типа лаги и креши, незачем отвлекать их от своей работы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Его не надо совать в топливо, это теория. На основании этого преобразования считается матрица ВЧ фильтра или любой другой потребной функции, которую нужно наложить на сигнал.
В чем смысл частотного фильтра? В том, что он позволяет подавить в сигнале одни частоты, сохранив другие. Соответственно когда носителем информации в сигнале является частота, частотный фильтр является полезным и вероятно незаменимым методом первичной фильтрации. В рассматриваемой задаче носителем информации является уровень сигнала, частота никакой информации не несет. Так зачем здесь частотный фильтр? Какие частоты ты собрался в сигнале сохранять?
НС>Неа, в мою специальность в вузе вообще DSP не входила. "Зазубрить" меня заставила работа, плотно связанная с DSP, причем от паяльника до алгоритмов, близких к ИИ. Не все задачки можно решить колхозными методами, увы.
Заучить методы ты сумел, а вот понять их смысл и границы применимости так и не смог.
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Я, например, прекрасно понимаю структуры данных. При этом если бы на форуме не тусовался об односвязном списке не знал бы ничего. НС>Ух жесть то какая.
А чего, тут вон был какой-то дядька, всё рассказывал про "монитор" в многопоточности. Пришлось в википедию смотреть, хотя я вроде многопоточно пишу уже лет десять. Не был бы на форуме, не знал бы, что такое монитор.
Здравствуйте, Sharowarsheg, Вы писали:
S>А чего, тут вон был какой-то дядька, всё рассказывал про "монитор" в многопоточности. Пришлось в википедию смотреть, хотя я вроде многопоточно пишу уже лет десять. Не был бы на форуме, не знал бы, что такое монитор.
Односвязный список все таки общепринятый термин. Или ты тоже не знаешь что это такое?
Здравствуйте, Undying, Вы писали:
U>В чем смысл частотного фильтра?
Где я говорил, что нужен обязательно и исключительно частотный фильтр?
U>Заучить методы ты сумел
А еще я их сумел использовать в реальных устройствах посложнее датчика уровня топлива в баке.
U>, а вот понять их смысл и границы применимости так и не смог.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А чего, тут вон был какой-то дядька, всё рассказывал про "монитор" в многопоточности. Пришлось в википедию смотреть, хотя я вроде многопоточно пишу уже лет десять. Не был бы на форуме, не знал бы, что такое монитор.
НС>Односвязный список все таки общепринятый термин. Или ты тоже не знаешь что это такое?
Я-то знаю, но вот в общепринятость чего угодно не верю уже давно. Кстати, дядька тот (Морозов, чтоли?) тоже настаивал на общепринятости слова "монитор".
НС>>Односвязный список все таки общепринятый термин. Или ты тоже не знаешь что это такое?
S>Я-то знаю, но вот в общепринятость чего угодно не верю уже давно. Кстати, дядька тот (Морозов, чтоли?) тоже настаивал на общепринятости слова "монитор".
односвязный список -- это крайне неудачный термин (в русском языке). Потому что квалификатор "односвязный" уже давно прочно занят под совершенно другое понятие "simply connected".
А тут это слово используется в совершенно другом смысле "singly linked".
D>односвязный список -- это крайне неудачный термин (в русском языке). Потому что квалификатор "односвязный" уже давно прочно занят под совершенно другое понятие "simply connected". D>А тут это слово используется в совершенно другом смысле "singly linked".
Там где (и тогда, когда) я учился, это называлось "однонаправленный" или, короче, "прямой" список. И, соответственно был "двунаправленный" или "двойной" список. Но это было давно и русской терминологии особо не было ещё.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>И часто очень важно обосновать правильный выбор. Есть случаи, когда можно и нужно использовать быструю сортировку, а есть случаи, когда ни в коем случае этого нельзя делать.
Зависит от области применения. Скажем, там где я сижу,
"часто" нужно написать List.Sort() и всё
"очень редко" правильный выбор обосновывает профайлер
и ни разу я не обосновывал ничего до замера.
Здравствуйте, Ночной Смотрящий, Вы писали:
T>>Для иллюстрации достаточно пояснений и они приведены. Как только появятся доказательства, то аналогия в тот же момент станет вполне рабочей теорией. НС>Вот только это все уже заявлено как рабочая теория, а не как попытка индукции.
В данной ветке проблема не в аналогиях, а в том что Undying выдумывает терминологию для уже имеющихся вещей.
Здравствуйте, Tanker, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
I>>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>>Чувак, 90% компаний этим не занимается.
T>Чтото в этом есть. Современный веб это все меньше и меньше программирования, а в кое где это уже сегодня на 100% конфигурирование. В такие компании программисты не нужны.
Между конфигурированием и программированием тонкая грань. Написание кода для 1С это программирование или конфигурирование?
С одной стороны конфигурирование, так как сама платформа не меняется. С другой стороны — программирование, ибо язык полн по тьюрингу и написать можно что угодно.
Но программирование это связано не связано с созданием приложения с нуля, разбиением на слои и реализацией алгоритмов. Оно связано с максимально эффективным использованием существующих возможностей платформы и расширением там где необходимо. Скорее похоже на создание плагинов, чем на разработку приложений с нуля.
Причем большая часть enterprise разработки именно такая.
T>Поэтому навыки программировани уже неактуальны, необходимо и достаточно выяснить знание основного набора инструментов — копипаст, справочник, гугл и умение разобраться в том, что нужно сделать и в том что уже сделано.
Это смотря что считать "навыкам программирования". Программирование уже давно не реализация с нуля приложений, это именно комбинирование существующих функций для достижения результата.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Очень мнгого программистов видел, которые генерируют тонны кода. НС>И что?
G>> Обрабатывают сотни кейсов, которые никогда не встретятся из-за особенностей api, закладывают гибкость, там где она не нужна итп. почти весь код бесполезен. НС>И что? Это называется умение писать код?
G>>Писать код они точно умеют. НС>Ну так и читать, видимо, тоже не умеют. Ты к чему все это написал?
К тому что писать они умеют. Код, который они нагенерировали, прошел бы любой review и соотвествует всем практикам. Но бесполезен, ибо сами релизовали то, что уже есть в платформе, а их код как раз с платформой интегрируется плохо.
G>> Как бы ты не пытался доказать обратное. НС>Обратное? Да я давно уже понял, что в твоих задачах вообще программисты особо не нужны. И я, в отличие от тебя, не пытаюсь доказать, что это не так.
Ты о чем? Думашь без программирования много сделаешь на sharepoint? Увы это не так.
Вот только программирование крайне далеко от разворотов списка. Это факт.
А что ты пытаешься доказать? Что человек, умеющий разворачивать списки фиганет любое решение на sharepoint\crm\1c?
Не сможет. Тоже факт.
G>> У тебя нет ни фактов, ни адекватных доводов. Везде только твое неподкрепленное ничем мнение. НС>Надо понимать, у тебя есть факты и адекватные доводы?
Я же говорю — практика и статистика.
Ты, видимо, работаешь в области, где разворачивать списки нужно и тебе кажется, что это важное умение.
Я поработал в разных областях и вижу, что оно далеко не везде нужно.
НС>>>Чем он лучший? Тем что кода в два раза больше надо писать? G>>Тем что не надо ничего держать в голове. НС>Почему это? Надо, причем больше — сущностей то в коде больше.
Не вижу связи. То что сущностей в коде больше не означает, что надо больше держать в голове.
В этом и суть разработки — декомпозируем задачу, чтобы минимизировать количество информации, которые надо держать в голове при написании и чтении. Потом собираем из маленьких кусочков большое решение.
G>> Нету циклов со сложными инвариантами НС>Ты вообще о каком коде говоришь? Тот что я привел — там цикл есть.
О том, который я привел. Там нет циклов.
G>>, и с точки зрения платформы это оптимальный способ. НС>Нет, не оптимальный, ни по памяти, ни по процессору. Можешь взять и померять, если не веришь.
static void Main(string[] args)
{
var count = 100000;
var s = "abracedabra";
Reverse1(s);
Reverse2(s);
var sw1 = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
Reverse1(s);
}
sw1.Stop();
Console.WriteLine(sw1.ElapsedMilliseconds); //34мсvar sw2 = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
Reverse2(s);
}
sw2.Stop();
Console.WriteLine(sw2.ElapsedMilliseconds); //11мс
}
static string Reverse1(string s)
{
var result = new StringBuilder(s.Length);
for(int i = s.Length-1; i>=0; i--)
{
result.Append(s[i]);
}
return result.ToString();
}
static string Reverse2(string s)
{
var chars = s.ToCharArray();
Array.Reverse(chars);
return new string(chars);
}
Можешь у себя запустить.
НС>>>Это я уже понял. Кто то под шерпоинт пишет, а кто то и сам шерпоинт. G>>Сам шарепонт написан индусами. Под капотом такой страшный код, что иногда удивительно как он работает. НС>Ну так нафига его тогда использовать?
Он много чего умеет. Столько, что неэффективно подобную систему с нуля разрабатывать.
Глючит иногда, но если знать как делать, то глючить не будет.
G>> Статический анализ на сборках sp выдает миллионы замечаний. НС>FXCop тоже написан индусами
Дык то не fxcop.
G>>И это не только sp такой. каждая корпоративная платформа такая. Где-то чуть лучше, где-то хуже. Это не потому что разработчики плохие. Это экономика разработки enterprise софта такая. НС>Ага, тут главное — верить, что не только ты говнокод пишешь — все такие.
Да ты можешь верить, а вот заказчик не поверит.
Важно не то, какой ты код пишешь, а важно как он решает проблемы.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Наоборот, именно там и важно понимать все эти ссылки и многое другое. G>>Нет, ссылки не нужны. Более того, часто бывает что G>>Object.ReferenceEquals(x.A,x.A) == false
I>Это как раз и требует понимания, что такое ссылки. Скажем ссылка требует уверенного понимания идентити и хотя бы представляения о том, что есть референс тайпы и валюе тайпы.
Ну ок. Человек понимает что такое value и ref типы. ИМХО без этого нельзя писать на .NET.
Что ему ее нужно? Разворачивать список на месте на бумажке? Я так и не понял зачем это умение.
Понимание identity? Что это вообще такое? Как выражается?
G>>В такой ситуации жонглирование ссылками — рассадник багов. I>После "каждый десятый пишет" твои аргументы даже слушать смешно.
Ну посмейся и приходи, серьезно продолжим разговаривать.
Ты ведь так и не сказал зачем нужен разворот списка. Вроде свелось к пониманию value и ref, но это не головоломка (см определение выше).
I>>>Судя по тому, как ты не задав ни одного вопроса предложил наихудшее решение да еще начал доказывать, что оно будет работать на раз, сильно сомневаюсь, что у тебя адекватная практика. G>>Обоснуй что худшее. Начни с твоих "особенностей". I>Хороший инженер обязан узнавать особенности до того, как начнет решения выдвигать. В противном случае это не инженер а изобретатель велосипедов.
Пффф... Ты откуда такую глупость придумал?
Есть исследование, которое показывает что инженеры обычно генерируют кучи решений и отсекают неподходящие. Причем критерий "подходящести" обычно меняется при рассмотрении новых вариантов.
Увы ссылку не найду быстро, можешь погуглить если интересно.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Если у вас такое пишет каждый десятый, то вполне понятны твои вопли про реверс списка I>>>У нас такое пишет каждый первый G>>На собеседовании? Я тебе просто не верю.
I>Разумеется. Но мы же здесь не твою веру обсждаем, правильно ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>>Не понял, зачем? I>Затем, что такой код и дает больше всего ошибок.
Я же тебе писал что ты неправ. В среднем плотность ошибок одинаковая. Типовой код пишется чще, следовательно ошибок в нем больше.
Кроме того нетиповой код скорее всего пройдет формальное review и ошибки будут устранены. А весь типовой код не проходит.
I>>>Наверное это особенности Шарепоинта или тех людей которых ты нанял, раз в типовом коде плотность ошибок такая же как и в остальном коде G>>Нет, эта статистика постоянная и устойчивая во времени, практически не зависит от языка и среды. Скорее всего предел человеческой внимательности.
I>Дай уже эту статистику. I>Как то очень странно — качество решения задачи вдруг перестаёт зависеть от того, берется ли готовое решение или его надо еще родить I>Парадокс какой то.
Ты не подменяй понятия "готовое" и "типовое". Если ты 100500 раз писал обходы графов, то любой обход для тебя будет типовой. Даже если ты его с нуля пишешь.
Так вот ты пишешь таким образом 80% типового кода. Пишешь его быстро и обычно у тебя 20-50 ошибок на 1000 строк. Просто из-за невнимательности.
20% кода не типовые, ты тратишь на них большую часть времени, проверяешь несколько раз, и получаешь те же 20-50 ошибок на 1000 строк.
Вот только ты написал типового кода 200 строк, а не типового — 40. И где суммарно будет больше ошибок?
I>Но в принципе есть объяснение — твои разрабы, если ты не путаешь, не могут ни строчки написать без ошибок.
Я вот консалтингом подрабатываю, в том числе занимаюсь внедрением процессов контроля качества кода. Так вот почти у всех в только что написаном коде примерно один дефект на 6-10 строк.
Это я наблюдал в дсятке мест.
I>>>Конечно по другому — давали типовые задачи для асп-нета. G>>Нет, как раз давали головоломки. I>Кто ж вам доктор теперь ?
Ну вот перестали давать, как-то лучше стало.
I>>>Если задача сводится к типовой, это просто типовая задача. G>>Нет. Иногда можно условия поменять. I>Покажи такое изменение условия.
Как показать? Это варианты архитектуры, оценка value, переговоры с заказчиком.
I>>>Это чушь. Типовые пишутся даже пьяным без ошибок. G>>Статистика говорит обратное. I>Покажи уже эту статистику.
МакКонелла читай.
Увы ссылку на оригинальное исследование не могу найти.
I>>>Разлагается на другие и типовая задача это две большие разницы. G>>Почему же? На каком-то уровне декомпозиции будут кусочки, которые ты уже писал. Поэтому задача резко становится типовой. I>Ну, поздравляю, ты доказал что вообще все задачи в программировании типовые.
Нет, не все.
G>>Иногда бывает что не все кусочки ты уже писал, и если по внешней похожести твой мозг определил задачу как типовую, то ты даже не поймешь что не так сделал. I>Ты уже сам себе начал противоречить. Выше ты доказал что все задачи типовые.
Я говорю что два случая бывает. Но мозг тебя часто обманывает, выдавая второй за первый.
I>Но вообще ты прав — всегда есть вещи, которые ты пишешь крайне редко, но так получается, что все редкие случаи вместе взятые составляют значительный процент и создают наибольшее количество проблем.
Это только кажется. Потому что твой мозг напрягается при решении гораздо больше. А за время проведения codereview я разницы не заметил, да и наш TFS говорит о том, что разницы в принципе нет.
G>>тобы рефлексы работали правильно — их надо тренировать. Можно натренировать человека решать нестандартные задачи. Но для него тогда большая часть задач будет нестандартными и получится велосипедостроитель. Причем у стремление
I>Велосипедостроитель получается не из умения решать нестандартные задачи, а из нежелания учиться или хотя бы смотреть изредка по сторонам или хотя бы задавать вопросы.
Еще раз. Это все неосознано. От квалификации программистов не зависит.
I>Плюс ко всему между людьми есть разница примерно такая — одни лучше решают типовые задачи(быстрее и эффективнее), другие лучше решают уникальные(быстрее и эффективнее).
Не может один и тот же программист все время решать уникальные задачи. Они просто кончатся. Поэтому достоверную статистику собрать непонятно как.
Обычно распределение решаемых задач — 80\20. Как только программист натренируется решать определенные задачи — они становятся типовым для него, он их решет быстрее и у него появляется время решать другие задачи, которые для него нетиповые.
I>Велосипедостроителей примерно одинаково и там и там, причины я описал.
Я так и не понял как ты их поделил.
G>>>>Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника. I>>>Ты прав с точностью до наоборот. G>>Почему? У тебя данные из ничего появляются в памяти?
I>Данные всегда в памяти.
Откуда они берутся? Они зашиты в исполняемый модуль?
I>>>Есть мир вне Шарепоинта. G>>А причем тут SharePoint? Ты считаешь что сбалансированное дерево только в SharePoint можно посторить? I>Вещи про которые я говорил, встречаются много чаще чем тебе кажется.
У тебя? Не сомневаюсь.
