Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Старый алгоритм так и работал, т.е. первоначально накладывал фильтр на сигнал. В результате терялась(загрублялась) информация о точности данных НС>Значит фильтр неправильный. Простейший ВЧ фильтр — не единственный вариант.
В очередной раз убеждаюсь, что больше умных слов употребляет в речи человек, тем меньше он способен думать. Я привел конкретные проблемы применения фильтров. В ответ ты ничего по существу сказать не смог. Т.к. зазубрить умные методы тебя в вузе заставили, а вот их пониманию, в частности пониманию когда их применение правильно и оптимально, а когда нет, не научили.
Здравствуйте, Undying, Вы писали:
U>В очередной раз убеждаюсь, что больше умных слов употребляет в речи человек, тем меньше он способен думать. Я привел конкретные проблемы применения фильтров. В ответ ты ничего по существу сказать не смог. Т.к. зазубрить умные методы тебя в вузе заставили, а вот их пониманию, в частности пониманию когда их применение правильно и оптимально, а когда нет, не научили.
Ты ничего конкретного не привел, кроме того, что кто-то что-то прилепил и оно не работало.
Здравствуйте, Ikemefula, Вы писали:
I>Все правильно, только время надо как то учитывать. Если ты хочешь решать сложные задачи скажем в области цифровой обработки сигналов так же быстро и качественно, как и человек, который там варится 10 лет, то теб надо будет потратить сравнимое время.
Если будет не у кого учиться, то возможно, да. А если на проекте уже будут специалисты в этой области, то учиться человек со способностями будет быстро, а пользу начнет приносить практически сразу.
I>Способности большей частью трансформируются в прочные знания. По другому не бывает. Умение решать задачи показывает именно способности.
Невозможно знать всего — областей деятельности очень много и никакой жизни не хватит для того, чтобы охватить их все. Человек знает только то, с чем реально сталкивался на практике. Из того с чем не сталкивался любой человек знает ничтожнейшую часть.
Возможности программиста определяются способностями, общим пониманием, конкретными знаниями. При этом развить способности очень сложно, общему пониманию при наличии способностей научить можно, но обычно требуется довольно много времени, конкретным знаниям человек учится очень быстро. При этом почему-то на собеседовании, как правило, спрашивают конкретные знания, т.е. то чему можно обучить очень быстро, а способности и общее понимание, т.е. то что неисправимо, даже не пытаются выяснить.
I>А я где то сказал, что любые задачи решаются за секунды ? Если тебе на каждый чих гуглить надо, то я боюсь сложные задачи потребуют годы на решение.
Зачем на каждый чих гуглить? Гуглить надо либо для общего знакомства с ранее незнакомой темой, либо для получения шаманских знаний, т.е. того что невозможно понять и надо просто запомнить. С незнакомыми темами сталкиваешься далеко не каждый день, использование методов требующих шаманских знаний желательно сводить к минимуму. Соответственно на практике я гуглю очень редко.
Здравствуйте, Vzhyk, Вы писали:
U>>В очередной раз убеждаюсь, что больше умных слов употребляет в речи человек, тем меньше он способен думать. Я привел конкретные проблемы применения фильтров. В ответ ты ничего по существу сказать не смог. Т.к. зазубрить умные методы тебя в вузе заставили, а вот их пониманию, в частности пониманию когда их применение правильно и оптимально, а когда нет, не научили. V>Ты ничего конкретного не привел, кроме того, что кто-то что-то прилепил и оно не работало.
Тебя сказанное тоже касается. Но на всякий случай повторю:
Старый алгоритм так и работал, т.е. первоначально накладывал фильтр на сигнал. В результате терялась(загрублялась) информация о точности данных — уровень топлива фильтр возвращает, а дисперсию уже нет, о времени начала/конца события — реальная точка начала заправки/слива замусорена последующим поднятием/снижением уровня топлива, о уровне топлива на начало/конец события — по той же причине.
Так какой фильтр нужно наложить на сигнал, чтобы вся эта информация сохранялась?
Здравствуйте, Undying, Вы писали:
I>>Все правильно, только время надо как то учитывать. Если ты хочешь решать сложные задачи скажем в области цифровой обработки сигналов так же быстро и качественно, как и человек, который там варится 10 лет, то теб надо будет потратить сравнимое время.
U>Если будет не у кого учиться, то возможно, да. А если на проекте уже будут специалисты в этой области, то учиться человек со способностями будет быстро, а пользу начнет приносить практически сразу.
Хорошая теория, попробуй её на шахматах.
U>Невозможно знать всего — областей деятельности очень много и никакой жизни не хватит для того, чтобы охватить их все. Человек знает только то, с чем реально сталкивался на практике. Из того с чем не сталкивался любой человек знает ничтожнейшую часть.
А я где то говорил что надо всё знать ? Вот скажем если ты понимаешь, что такое производная,то не надо запоминать все производные всех функций, можно взять и вывести все что тебе надо.
U>Возможности программиста определяются способностями, общим пониманием, конкретными знаниями. При этом развить способности очень сложно, общему пониманию при наличии способностей научить можно, но обычно требуется довольно много времени, конкретным знаниям человек учится очень быстро. При этом почему-то на собеседовании, как правило, спрашивают конкретные знания, т.е. то чему можно обучить очень быстро, а способности и общее понимание, т.е. то что неисправимо, даже не пытаются выяснить.
Ты это ганджустасу скажи, это он про знания спрашивать любит.
U>Зачем на каждый чих гуглить? Гуглить надо либо для общего знакомства с ранее незнакомой темой, либо для получения шаманских знаний, т.е. того что невозможно понять и надо просто запомнить. С незнакомыми темами сталкиваешься далеко не каждый день, использование методов требующих шаманских знаний желательно сводить к минимуму. Соответственно на практике я гуглю очень редко.
Общее знакомство тебе мало что даст. Если скажем ты пришел к выводу что имеющаяся структура данных не годится, то хотя бы задетектить эту проблему, а потом выбрать подъходящую, надо уметь анализировать структуры данных вообще, а не просто знать свойства одно двух вариантов деревьев.
В этом случае такая задача решается за минуты в уме. А если ты будешь гуглить, то есть шанс что используешь чейто велосипед который непригоден абсолютно.
Скажем, у меня не получается хорошо анализировать структуры данных и алгоритмы, тут надо свободно математикой владеть, а её, этой математики, уменя совсем мало. Более-менее простые случае получаются, а что посложнее, то студенты факультета прикладной математики заруливают в минуса.
Соответсвено я нигде не позиционирую себя как специалиста по алгоритмам и структурм данных. Но это, вобщем, не значит, что с алгоритмами у меня все плохо
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Как минимум рабочие в программировании не нужны, потому что в материальном производстве рабочии занимаются созданием копий изделий, а в программировании копирование бесплатно.
Токарь в опытном цехе может каждый день точить разные детали, от этого он не перестает быть рабочим.
Отличие конструктора и технолога от рабочего в том, что рабочий выпускает конечный продукт (т.е. изделие в металле или коде). Т.е. рабочие производят трактор, конструктора — чертежи трактора, технологи — описание техпроцессов по изготовлению деталей трактора.
Простенький пример работы технолога в программировании. Ты приводил задачу с переворотом списка. Допустим на проекте эта задача встречается регулярно. Конечно, можно каждый раз решать ее заново. Но в решении имеется довольно сложное состояние, при работе с которым можно ошибиться из-за описки, невнимательности или усталости. Работа технолога состоит в том, чтобы упростить решение этой задачи для других программистов. Например, это можно сделать вынеся код переворота в такую функцию:
static T Reverse(T first, Getter<T, T> nextGetter, Executter<T, T> nextSetter);
Использование этой функции намного проще, чем сам код переворота списка, соответственно программисты теперь на переворот списка будут тратить меньше времени и допускать меньше ошибок. Т.е. программист-технолог облегчил их работу.
Другой пример работы технолога в программировании. Это знаток некоего фрамеворка, который может разъяснить другим программистам, решающим прикладные задачи с использованием этого фрамеворка, тонкости, подводные камни и сложные места использования этого фрамеворка.
U>>Гордыня на мозг не жмет? НС>Нет. А тебе? А то от тебя столько пафоса льется, что деревьев не видно.
Своих коллег по профессии я обезъянками не считаю. Так что до эталонов гордыни мне еще очень далеко.
Здравствуйте, Ikemefula, Вы писали:
U>>Если будет не у кого учиться, то возможно, да. А если на проекте уже будут специалисты в этой области, то учиться человек со способностями будет быстро, а пользу начнет приносить практически сразу. I>Хорошая теория, попробуй её на шахматах.
Давно опробована. Вон у нас Панкратов в секции был, ныне гросс который, так он в 8 лет играл в силу кандидата в мастера. А подавляющее большинство остальных занимающихся и в 16 лет играли намного хуже.
U>>Невозможно знать всего — областей деятельности очень много и никакой жизни не хватит для того, чтобы охватить их все. Человек знает только то, с чем реально сталкивался на практике. Из того с чем не сталкивался любой человек знает ничтожнейшую часть.
I>А я где то говорил что надо всё знать ? Вот скажем если ты понимаешь, что такое производная,то не надо запоминать все производные всех функций, можно взять и вывести все что тебе надо.
И какую часть нужного на практике составляют производные? Большинство инженеров за свою жизнь ни разу не сталкивается с применением производных на практике.
Это я ни к тому, что математику в школе изучать не надо, т.к. для становления мышления она полезна. Но надо понимать, что математика и инженерная деятельность это совершенно разные вещи, хоть изредка и пересекающиеся.
I>Ты это ганджустасу скажи, это он про знания спрашивать любит.
У него может специфика такая. Возможно Sharepoint действительно сплошное шаманство, которое нельзя понять, а можно только запомнить. Тогда там реально специфические люди нужны, обычные — сбегут.
I>Общее знакомство тебе мало что даст. Если скажем ты пришел к выводу что имеющаяся структура данных не годится, то хотя бы задетектить эту проблему, а потом выбрать подъходящую, надо уметь анализировать структуры данных вообще, а не просто знать свойства одно двух вариантов деревьев.
Чтобы задетектить достаточно очень общих знаний, вроде того, что нормальное время сортировки это n*log(n), поиска по ключу — О, поиска в сортированном списке log(n). И чтобы подобные общие знания передать требуется немного времени при наличии о обучаемого способностей.
I>В этом случае такая задача решается за минуты в уме. А если ты будешь гуглить, то есть шанс что используешь чейто велосипед который непригоден абсолютно.
По такой логике написание программных продуктов вообще невозможно. Т.к. на любом реальном проекте регулярно встречаются принципиально новые задачи. И если на каждую такую задачу искать спеца, который имеет знания и опыт решения таких задач, то проект никогда не будет закончен.
I>Скажем, у меня не получается хорошо анализировать структуры данных и алгоритмы, тут надо свободно математикой владеть, а её, этой математики, уменя совсем мало. Более-менее простые случае получаются, а что посложнее, то студенты факультета прикладной математики заруливают в минуса.
Если вам постоянно нужна математика на проекте, то, значит, да, желательно иметь адекватного выпускника прикладной математики, который и будет консультировать остальных по сложным вопросам и наиболее математически сложные места сам кодить. Всем-то программистам зачем мегаматематиками быть?
Здравствуйте, gandjustas, Вы писали:
I>>>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>>>Не понял, зачем? НС>>В рамочку и на стенку. G>То есть доводов у тебя нет?
Да какие уж тут еще нужны доводы? Ты просто шедевры изрекаешь, мне просто поддерживать разговор надо.
НС>>Надо говорить "мне приходится редко" G>Тебе надо? Ну говори.
Мне то зачем? Это ты вселенской общности утверждения делаешь.
G>Тебя просят дать оценку.
Кто и какую оценку просит меня дать?
G> Ты называешь цифру или диапазон, на основании чего? Обычно мозг пытается сопоставить задачу с теми, которые ты уже решал. Когда ты пишешь код, мозг работает также. Ты неосознано генерируешь код, который ты уже писал. А иногда очень осознанно делаешь копипасту.
Я что то не припомню, что ты за моим плечом когда либо стоял.
НС>>Мы уже поняли, что тебе программисты не нужны. О чем тогда ты споришь? G>Это ты споришь о сущности умения разворачивать списки, пытаясь доказать что это практически Умение писать код.
Ничего подобного я доказать не пытаюсь. Я говорю лишь о том, что способность решить эту задачу — необходимое условие. Но отнюдь не достаточное.
G> Но у тебя нет ни доводов, ни фактов, ничего...
Здравствуйте, Undying, Вы писали:
U>В очередной раз убеждаюсь, что больше умных слов употребляет в речи человек, тем меньше он способен думать.
В очередной раз убеждаюсь, что чем меньше фактов у человека, тем больше он хамит. Пока что тут ты демонстрируешь просто фантастическую безграмостность как в основах программирования, так и в основах DSP.
U> Я привел конкретные проблемы применения фильтров.
Ничего ты по сути не привел. Все что можно из предоставленного тобой понять, это то что кто то там неверно подобрал функцию обработки, а ты, видимо из-за нулевого математического бекграунда, изобрел странный велосипед. В принципе, я тоже так делал, когда в университете учился, из-за недостатка опыта. И оно даже работало. Вот только мне потом повезло с существенно более сложными задачами, так что я быстро осознал наличие пробелов.
U>Т.к. зазубрить умные методы тебя в вузе заставили
Неа, в мою специальность в вузе вообще DSP не входила. "Зазубрить" меня заставила работа, плотно связанная с DSP, причем от паяльника до алгоритмов, близких к ИИ. Не все задачки можно решить колхозными методами, увы.
Здравствуйте, Undying, Вы писали:
U>Так какой фильтр нужно наложить на сигнал, чтобы вся эта информация сохранялась?
Если у тебя проблема с латентностью, то, обычно, в параллель ставят диффильтр, потом какой нибудь фильтр, удаляющий мусор, потом фильтр распознавания (их там несколько классов есть, подбирается в зависимости от потребностей) — на выходе у тебя будут нужные тебе сигналы с задержкой от 1-2 до десятка отсчетов, в зависимости от длины и сложности фиксируемого паттерна. Но это так, из пальца. Конкретные направления можно будет понять только после ознакомления с полной задачей и реальными семплами.
Здравствуйте, gandjustas, Вы писали:
НС>>Это связанные умения. G>Практика показывает что не связанные.
Твоя. А моя — что связанные.
G>Очень мнгого программистов видел, которые генерируют тонны кода.
И что?
G> Обрабатывают сотни кейсов, которые никогда не встретятся из-за особенностей api, закладывают гибкость, там где она не нужна итп. почти весь код бесполезен.
И что? Это называется умение писать код?
G>Писать код они точно умеют.
Ну так и читать, видимо, тоже не умеют. Ты к чему все это написал?
НС>>Это не объясняет, почему у разных программистов с одинаковым опытом производительность может отличаться на порядок. G>Именно объясняет.
Нет, не объясняет.
G>Моя практика показывает
Наконец то ты использовал правильное местоимение.
НС>>Нет, смешно это когда человек, претендующий на работу программиста, не в состоянии справится с примитивной ссылочной конструкцией. И энтерпрайз, он очень разный, не обобщай шерпоинт на все остальное. G>Да не нужно это умение.
Опять местоимение забыл.
G> Как бы ты не пытался доказать обратное.
Обратное? Да я давно уже понял, что в твоих задачах вообще программисты особо не нужны. И я, в отличие от тебя, не пытаюсь доказать, что это не так.
G> У тебя нет ни фактов, ни адекватных доводов. Везде только твое неподкрепленное ничем мнение.
Надо понимать, у тебя есть факты и адекватные доводы?
G>О да, каждый день программисты пишут dsl_и ??
Не каждый, но у нас такие задачки не редкость. Не нравятся DSL — задачки реализации транзакционного ресурса, к примеру, в плане косвенности не сильно проще, там такие хитрые ситуации вылазят, что мама не горюй.
НС>>Чем он лучший? Тем что кода в два раза больше надо писать? G>Тем что не надо ничего держать в голове.
Почему это? Надо, причем больше — сущностей то в коде больше.
G> Нету циклов со сложными инвариантами
Ты вообще о каком коде говоришь? Тот что я привел — там цикл есть.
G>, и с точки зрения платформы это оптимальный способ.
Нет, не оптимальный, ни по памяти, ни по процессору. Можешь взять и померять, если не веришь.
НС>>Это я уже понял. Кто то под шерпоинт пишет, а кто то и сам шерпоинт. G>Сам шарепонт написан индусами. Под капотом такой страшный код, что иногда удивительно как он работает.
Ну так нафига его тогда использовать?
G> Статический анализ на сборках sp выдает миллионы замечаний.
FXCop тоже написан индусами
G>И это не только sp такой. каждая корпоративная платформа такая. Где-то чуть лучше, где-то хуже. Это не потому что разработчики плохие. Это экономика разработки enterprise софта такая.
Ага, тут главное — верить, что не только ты говнокод пишешь — все такие.
G>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
G>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков. G>Кстати в конце статьи описан новый подход гугла к найму, который так не нравится многим программистам, верящим в свою уникальность.
Для меня — точно бесполезны. Мозг у всех людей работает по-разному. Например, я тормоз в ментальном смысле, но это не значит, что я болван. Помню, было интервью в Микрософте и там задали вопрос про перфокарты, как за один проход определить, что все они уникальные в колоде. Не смог ответить. Потом придумал способ, но было уже поздняк метаться.
Но главное — все эти головоломки не имеют никакого отношения к реальной работе.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Undying, Вы писали:
U>Токарь в опытном цехе может каждый день точить разные детали, от этого он не перестает быть рабочим.
Ну то есть ты решил перейти на доказательства по аналогии. Зря, на меня этот прием демагогии не действует.
U>Простенький пример работы технолога в программировании.
Настала пора обратится к энциклопедии, чтобы ты понял смысл термина:
Инженер-технолог — инженер, занимающийся разработкой, организацией того или иного производственного процесса.
U> Ты приводил задачу с переворотом списка. Допустим на проекте эта задача встречается регулярно.
Нет, эта задача в реальном проекте не встречается, я уже 10 раз это здесь писал. Ты толи не читаешь мои сообщения полностью, толи полностью игнорируешь все, что противоречит теории в твоей голове.
А про упрощение да, все правильно. И именно поэтому "программисты", умеющие писать только шаблонный код, не нужны.
НС>>Нет. А тебе? А то от тебя столько пафоса льется, что деревьев не видно. U>Своих коллег по профессии я обезъянками не считаю.
Я тоже не считаю. Я прямо писал, опять же неоднократно — программист из человека, который не в состоянии развернуть односвязный список, как из говна пуля. И это не потому что у меня какая то гордыня, это абсолютно практический опыт. Ты когда/если повоюешь за качество кода (ага, это уже работа инженера-технолога) подольше, в итоге к тому же и придешь. Разводить сопли с людьми, у которых моск не приспособлен для программирования — бесполезная трата времени и денег, а так же гавно в проекте, которое потом еще и вычищать придется.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Настала пора обратится к энциклопедии, чтобы ты понял смысл термина: НС>
НС>Инженер-технолог — инженер, занимающийся разработкой, организацией того или иного производственного процесса.
Т.е. по-твоему программирование это не производственный процесс и организовывать там нечего?
Собственно в непрограммировании несколько веков было тоже самое, тогда в производственных процессах не было ни конструкторов, ни технологов, ни рабочих, были только ремесленники. Сейчас в программировании все тоже самое. Т.к. на чужом опыте программисты учиться не желают, и будут учиться только на своих ошибках.
U>> Простенький пример работы технолога в программировании. Ты приводил задачу с переворотом списка. Допустим на проекте эта задача встречается регулярно. НС>Нет, эта задача в реальном проекте не встречается, я уже 10 раз это здесь писал. Ты толи не читаешь мои сообщения полностью, толи полностью игнорируешь все, что противоречит теории в твоей голове.
Ты что такое пример и допущение понимаешь?
НС>Я тоже не считаю. Я прямо писал, опять же неоднократно — программист из человека, который не в состоянии развернуть односвязный список,
Ты за рамки собственного примера выйти можешь? Речь уже давно не о том нужно ли спрашивать разворот списка на собеседовании, а о куда более общих вещах.
Здравствуйте, Undying, Вы писали:
U>Т.е. по-твоему программирование это не производственный процесс и организовывать там нечего?
Ты опять полностью игнорируешь мною написанное. Я прямо написал, что инженеры-технологи в процессе разработки ПО нужны. Только это совсем другие навыки.
U>Собственно в непрограммировании несколько веков было тоже самое
Ясно, опять пошли доказательства по аналогии.
U>Сейчас в программировании все тоже самое.
Нет.
НС>>Нет, эта задача в реальном проекте не встречается, я уже 10 раз это здесь писал. Ты толи не читаешь мои сообщения полностью, толи полностью игнорируешь все, что противоречит теории в твоей голове. U>Ты что такое пример и допущение понимаешь?
Делать допущения, которые прямо противоречат словам человека, и на основании этого доказывать что он не прав, с которым ты споришь — это, мягко говоря, не совсем корректный прием спора.
НС>>Я тоже не считаю. Я прямо писал, опять же неоднократно — программист из человека, который не в состоянии развернуть односвязный список, U>Ты за рамки собственного примера выйти можешь?
Могу. А зачем? Обсуждать другие отрасли я не собираюсь по очевидным причинам.
U> Речь уже давно не о том нужно ли спрашивать разворот списка на собеседовании, а о куда более общих вещах.
Ну то есть со списком ты ничего доказать не смог и решил сменить тему? Создай отдельный топик, изложи свои тезисы, обсудим.
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Т.е. по-твоему программирование это не производственный процесс и организовывать там нечего? НС>Ты опять полностью игнорируешь мною написанное. Я прямо написал, что инженеры-технологи в процессе разработки ПО нужны. Только это совсем другие навыки.
Это ты игнорируешь. Я написал "программирование", т.е. написание кода, а не "разработка ПО", которая может в себя включать тестирование, настройку стендов и т.п.
Я правильно понял, что ты утверждаешь, что написание кода это не производственный процесс, поэтому организовывать там нечего и технологи там не нужны?
U>>Собственно в непрограммировании несколько веков было тоже самое НС>Ясно, опять пошли доказательства по аналогии.
Т.е. ты умеешь учиться только на своих ошибках. Чужой опыт это почти всегда аналогия, полное совпадение бывает крайне редко.
НС>Делать допущения, которые прямо противоречат словам человека, и на основании этого доказывать что он не прав, с которым ты споришь — это, мягко говоря, не совсем корректный прием спора.
Ты о чем вообще? Где я в посте с примером говорил о том, что задача переворота списка плохо?
НС>Ну то есть со списком ты ничего доказать не смог и решил сменить тему?
Ты меня вообще читаешь? Я уж давно признал, что если использовать на собеседовании задачи как первичный фильтр, то задача переворота списка может быть неплохим, хоть и дорогим вариантом. Дорогим потому, что отсеет многих середняков, которые могли бы хорошо работать при должной организации процесса программирования.
НС>Создай отдельный топик, изложи свои тезисы, обсудим.
Здравствуйте, Undying, Вы писали:
U>Это ты игнорируешь. Я написал "программирование", т.е. написание кода, а не "разработка ПО", которая может в себя включать тестирование, настройку стендов и т.п.
Ну, если в команде нет выделенного специалиста — могут. Только эти навыки к программированию все равно отношения не имеют.
U>Я правильно понял, что ты утверждаешь, что написание кода это не производственный процесс, поэтому организовывать там нечего и технологи там не нужны?
Нет, ничего подобного я не утверждал даже близко.
U>>>Собственно в непрограммировании несколько веков было тоже самое НС>>Ясно, опять пошли доказательства по аналогии. U>Т.е. ты умеешь учиться только на своих ошибках
Нет, я просто знаю что доказательства по аналогии логически некорректны.
НС>>Делать допущения, которые прямо противоречат словам человека, и на основании этого доказывать что он не прав, с которым ты споришь — это, мягко говоря, не совсем корректный прием спора. U>Ты о чем вообще?
О том что ты вывернул мои слова на прямо противоположные.
U> Где я в посте с примером говорил о том, что задача переворота списка плохо?
Тогда с чем ты споришь?
НС>>Ну то есть со списком ты ничего доказать не смог и решил сменить тему? U>Ты меня вообще читаешь? Я уж давно признал, что если использовать на собеседовании задачи как первичный фильтр, то задача переворота списка может быть неплохим, хоть и дорогим вариантом.
Ты несколько другое писал.
U> Дорогим потому, что отсеет многих середняков, которые могли бы хорошо работать при должной организации процесса программирования.
Я не верю в то, что человек, не способный справится с такой простенькой задачей это середняк. По факту это даже не начинающий, а, либо, полный ноль, либо человек с неподходящим для программирования складом ума.
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Я правильно понял, что ты утверждаешь, что написание кода это не производственный процесс, поэтому организовывать там нечего и технологи там не нужны? НС>Нет, ничего подобного я не утверждал даже близко.
Т.е. технологи при написании кода все-таки нужны?
НС>Нет, я просто знаю что доказательства по аналогии логически некорректны.
Так как тогда учиться на чужих ошибках?
НС>О том что ты вывернул мои слова на прямо противоположные.
То чего ты занудный. Я не выворачивал твои слова наизнанку, т.к. никогда не утверждал, что на твоей работе переворот списков это обычное дело.
НС>Тогда с чем ты споришь?
Последние посты о полезности разделения труда в программировании.
U>>Ты меня вообще читаешь? Я уж давно признал, что если использовать на собеседовании задачи как первичный фильтр, то задача переворота списка может быть неплохим, хоть и дорогим вариантом.
НС>Ты несколько другое писал.
Признаю твою правоту. Я думал вы так специалистов-кодеров отбираете, а учитывая, что они вам не нужны, то это хорошая задача для первичного отбора.
U>>Т.е. ты умеешь учиться только на своих ошибках
НС>Нет, я просто знаю что доказательства по аналогии логически некорректны.
Кажись тебе хочется выдать за доказательство суждение по методу аналогии.
Пару цитат известных математиков:
«Математик — это тот, кто умеет находить аналогии между утверждениями, лучший математик — тот, кто устанавливает аналогии доказательств, более сильный математик — тот, кто замечает аналогии теорий; но можно представить себе и такого, кто между аналогиями видит аналогии». Стефан Банах.
«Возможно не существует открытий ни в элементарной, ни в высшей математике, ни даже, пожалуй, в любой другой области, которые могли бы быть сделаны без аналогии». Дьёрдь Пойа.
То есть, не надо бояться аналогий.
Здравствуйте, gandjustas, Вы писали:
I>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>Чувак, 90% компаний этим не занимается.
Чтото в этом есть. Современный веб это все меньше и меньше программирования, а в кое где это уже сегодня на 100% конфигурирование. В такие компании программисты не нужны. И Шейрпоинт твой где то в этой окрестности. Поэтому навыки программировани уже неактуальны, необходимо и достаточно выяснить знание основного набора инструментов — копипаст, справочник, гугл и умение разобраться в том, что нужно сделать и в том что уже сделано.
