Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>Не правильно, разворот списка не имеет отношения к реальной программе. I>>>Объясняю еще раз — кроме ссыдлк-указателей и тд, в каждой программе всегда и везде будет уникальный код, который пишется практически каждый день. G>>И что?
I>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам.
Не понял, зачем?
I>Умение писать такой код это умение обучаться, умение решать проблемы.
Нет, умение обучаться не связано с умением писать код.
I>>>Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче. G>>Нужны способности писать этот уникальный код, а не пытаться всё свести к развороту списка. I>И ты проверяешь способности писать уникальный код с помощью типовой задачи. Я правильно тебя понял ?
Нет, я же говорю, что писать уникальный код приходится редко. Незачем проверять это умение на собеседовании.
G>>>>Или по итеративному вычислению квадратного корня? I>>>Фильтруют, не переживай. G>>Не видел. I>Мало видел.
Много видел.
I>>>Оставшиеся 20% задач как раз и создают бОльшую часть проблем. Если кандидат начнет сводить их к типовым, получится хаос. G>>Нет. Как раз проблемы возникают в совершенно типовом коде. То есть плотность ошибок примерно одинаковая, но типового кода тупо больше. I>Наверное это особенности Шарепоинта или тех людей которых ты нанял, раз в типовом коде плотность ошибок такая же как и в остальном коде
Нет, эта статистика постоянная и устойчивая во времени, практически не зависит от языка и среды. Скорее всего предел человеческой внимательности.
I>>>Естественно, ты же и асп-нетчиков брал точно так же — по типовым задачам. А если человек умеет решать нестандартные задачи, то как правило ему разбираться будет легко. G>>Нет, как раз их брали по-другому. I>Конечно по другому — давали типовые задачи для асп-нета.
Нет, как раз давали головоломки.
I>>>Ты похоже начал сам с собой спорить: "человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ" G>>Да. Просто человек заранее не понял что задача нетиповая. Если бы заранее понял, то её проще к типовой свести, чем решать как есть. I>Если задача сводится к типовой, это просто типовая задача.
Нет. Иногда можно условия поменять.
I>>>Смысл в том, что типовые задачи создают меньше всего проблем в силу того, что они отработаны чуть не до автоматизма. А остальные задачи создают бОльшую часть проблем. G>>Нет, типовые задачи создают столько же проблем. Плотность ошибок одинаковая. Так как типовых задач больше, то и ошибок в них больше. I>Это чушь. Типовые пишутся даже пьяным без ошибок.
Статистика говорит обратное.
G>>С чего ты взял? Как раз большая часть любых задач решается именно комбинированием существующих кусочков. G>>Реализация алгоритма, который не разлагается на другие, требуется крайне редко. I>Разлагается на другие и типовая задача это две большие разницы.
Почему же? На каком-то уровне декомпозиции будут кусочки, которые ты уже писал. Поэтому задача резко становится типовой.
Иногда бывает что не все кусочки ты уже писал, и если по внешней похожести твой мозг определил задачу как типовую, то ты даже не поймешь что не так сделал.
Мозг тебя очень часто обманывает. Большую часть решений человек принимает неосознано, грубо говоря на уровне рефлексов.
тобы рефлексы работали правильно — их надо тренировать. Можно натренировать человека решать нестандартные задачи. Но для него тогда большая часть задач будет нестандартными и получится велосипедостроитель. Причем у стремление решать нестандартные задачи будет так велико (неосознано конечно), что даже в уже решенной задаче он будет видеть нестандартную.
Увы для работы такие люди очень вредны, зато они успешно разворачивают списки и спасают гномиков, а некоторые даже гору фудзи передвигать умеют.
I>>> Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n) G>>Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника. I>Ты прав с точностью до наоборот.
Почему? У тебя данные из ничего появляются в памяти?
G>>Например при загрузке программы построить дерево. При небольших изменениях в него даже вставлять можно за log(n). I>Есть мир вне Шарепоинта.
А причем тут SharePoint? Ты считаешь что сбалансированное дерево только в SharePoint можно посторить?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Задача не алгоритмическая.
НС>А задача разворота списка что, алгоритмическая? Т.е. переворот списка по принципу ханойской башни это алгоритм, который надо придумать? Жесть.
Да, потому что есть ровно один алгоритм разворота списка на месте. И если ты его заранее не знаешь, то надо придумать.
I>>>Правильно,и с реверсом тоже самое — нет решения, не подходит. G>>Не правильно, разворот списка не имеет отношения к реальной программе.
НС>А строку ты часто в реальных программах разворачиваешь?
Нет, но задача не на знание алгоритма, а на знание платформы.
Некоторые пытаются разворачивать строку на месте, не зная что строки immutable
Некоторые клеят строи в цикле, не зная про string builder.
Некоторые не могут цикл нормально написать
А идеальный вариант:
var a = str.ToCharArray();
Array.Reverse(a);
return new string(a);
Но такой пишет каждый десятый.
Операций со строками в реальных программах много происходит.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
НС>>>В данном случае — понимание что такое ссылка и умение удерживать несложные ссылочные конструкции в голове. G>>Зачем? НС>Затем что это напрямую влияет на качество и эффективность программиста.
На качество и эффективность самое большое влияние оказывают умение читать код, а не писать.
На втором месте — знание среды, в которой работает. Тройку замыкает усидчивость и внимательность.
Умение жонглировать ссылками оказывает настолько маленькое влияние в enterprise разработке, что даже упоминать смешно.
G>>Пуст лучше компьютер удерживает, у него памяти много и она не дырявая, как в програиистов. НС>Компьютер еще дизайн софта самостоятельно делать не научился. Так что пока только головой.
Но можно писать так, чтобы минимум удерживать в голове.
Поэтому самый лучший разворот списка:
list.Reverse()
Если программист такое не может сделать, то он бесполезен для реальной работы.
НС>>>В месте программирования. Не все ж какой нибудь 1С подпиливают, некторые и посложнее задачки решают. G>>Ну вот, ты уже сам пришел к выводу, что это не всем надо.
НС>Конечно не всем. Это надо программистам. Ну так мы и собеседуем не вообще, а для конкретных вакансий.
Угу, и немалая часть конкретных вакансий это enterprise разработка, где жонглирование ссылками бесполезно.
НС>>>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен. G>>Практика показывает обратное. НС>Практика именно это и показывает.
У нс разная практика.
Здравствуйте, gandjustas, Вы писали:
I>>Ты хочешь что бы я выложил 10мб спецификаций ? G>Нет, ты просто по русски напиши.
Ты лучше научись вопросы задавать, а делать вид что один ты здесь умный.
I>>>>Предложи решение которое даст O(n) без дополнительной памяти. G>>>Зачем? I>>Для того, что бы сошлись концы с концами. G>А почему так не сходятся? Память нинче дешевая. 4гб стоят дешевле моего дня работы. Причем сильно дешевле.
Память и адресное пространство нужно другим задачам.
I>>Представляю — рендеринг картинки вместо пол-секунды займет пол-часа. Похоже это про тебя: "у нас всё в базу упирается" G>Ты её можешь заранее отрендерить, а потом показывать? Может не всю, а по слоям. Сама идея слоев пришла из ГИСов, где рендерить все на лету нереально. Поэтому картинка режется на слои и рендеринг каздого оптимизируется с целью делать как можно меньше работы. Заметь — не делать как можно быстрее, а делать как можно меньше.
Ну ты же сказал, что алгоритм не надо оптимизировать если менее нескольких часов работает. Зачем тогда слои и тд ?
I>>>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>>>Чувак, 90% компаний этим не занимается. I>>Ага, вне шарепоинта жизни нет. G>Есть, и вообще SharePoint — малнькая среда. На всю Россию сотня крупных проектов. Во всем мире порядка на два больше. G>Но даже это больше, чем САПРов.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Ты хочешь что бы я выложил 10мб спецификаций ? G>>Нет, ты просто по русски напиши. I>Ты лучше научись вопросы задавать, а делать вид что один ты здесь умный.
А я тут причем? Это ты прячешься за 10мб спецификаций.
I>>>>>Предложи решение которое даст O(n) без дополнительной памяти. G>>>>Зачем? I>>>Для того, что бы сошлись концы с концами. G>>А почему так не сходятся? Память нинче дешевая. 4гб стоят дешевле моего дня работы. Причем сильно дешевле. I>Память и адресное пространство нужно другим задачам.
Каким? Памяти мало?
I>>>Представляю — рендеринг картинки вместо пол-секунды займет пол-часа. Похоже это про тебя: "у нас всё в базу упирается" G>>Ты её можешь заранее отрендерить, а потом показывать? Может не всю, а по слоям. Сама идея слоев пришла из ГИСов, где рендерить все на лету нереально. Поэтому картинка режется на слои и рендеринг каздого оптимизируется с целью делать как можно меньше работы. Заметь — не делать как можно быстрее, а делать как можно меньше. I>Ну ты же сказал, что алгоритм не надо оптимизировать если менее нескольких часов работает. Зачем тогда слои и тд ?
Тебе же полсекуды надо. А у меня только чтение с диска дольше идет.
Здравствуйте, gandjustas, Вы писали:
I>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>Не понял, зачем?
Затем, что такой код и дает больше всего ошибок.
I>>Умение писать такой код это умение обучаться, умение решать проблемы. G>Нет, умение обучаться не связано с умением писать код.
Ты постоянно передёргиваешь и как то я подустал от этого.
I>>>>Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче. G>>>Нужны способности писать этот уникальный код, а не пытаться всё свести к развороту списка. I>>И ты проверяешь способности писать уникальный код с помощью типовой задачи. Я правильно тебя понял ? G>Нет, я же говорю, что писать уникальный код приходится редко. Незачем проверять это умение на собеседовании.
I>>Мало видел. G>Много видел.
Мне не единожды задавали похожие вопросы
I>>Наверное это особенности Шарепоинта или тех людей которых ты нанял, раз в типовом коде плотность ошибок такая же как и в остальном коде G>Нет, эта статистика постоянная и устойчивая во времени, практически не зависит от языка и среды. Скорее всего предел человеческой внимательности.
Дай уже эту статистику.
Как то очень странно — качество решения задачи вдруг перестаёт зависеть от того, берется ли готовое решение или его надо еще родить
Парадокс какой то.
Но в принципе есть объяснение — твои разрабы, если ты не путаешь, не могут ни строчки написать без ошибок.
I>>Конечно по другому — давали типовые задачи для асп-нета. G>Нет, как раз давали головоломки.
Кто ж вам доктор теперь ?
I>>Если задача сводится к типовой, это просто типовая задача. G>Нет. Иногда можно условия поменять.
Покажи такое изменение условия.
I>>Это чушь. Типовые пишутся даже пьяным без ошибок. G>Статистика говорит обратное.
Покажи уже эту статистику.
I>>Разлагается на другие и типовая задача это две большие разницы. G>Почему же? На каком-то уровне декомпозиции будут кусочки, которые ты уже писал. Поэтому задача резко становится типовой.
Ну, поздравляю, ты доказал что вообще все задачи в программировании типовые.
G>Иногда бывает что не все кусочки ты уже писал, и если по внешней похожести твой мозг определил задачу как типовую, то ты даже не поймешь что не так сделал.
Ты уже сам себе начал противоречить. Выше ты доказал что все задачи типовые.
Но вообще ты прав — всегда есть вещи, которые ты пишешь крайне редко, но так получается, что все редкие случаи вместе взятые составляют значительный процент и создают наибольшее количество проблем.
G>Мозг тебя очень часто обманывает. Большую часть решений человек принимает неосознано, грубо говоря на уровне рефлексов.
Правильно. Вот и надо проверять, как часто обманывает мозг. У всех это по разному.
G>тобы рефлексы работали правильно — их надо тренировать. Можно натренировать человека решать нестандартные задачи. Но для него тогда большая часть задач будет нестандартными и получится велосипедостроитель. Причем у стремление
Велосипедостроитель получается не из умения решать нестандартные задачи, а из нежелания учиться или хотя бы смотреть изредка по сторонам или хотя бы задавать вопросы.
Плюс ко всему между людьми есть разница примерно такая — одни лучше решают типовые задачи(быстрее и эффективнее), другие лучше решают уникальные(быстрее и эффективнее).
Велосипедостроителей примерно одинаково и там и там, причины я описал.
Скажем в задаче с сортировкой, где ты удачно 'блеснул'
первые подойдут примерно так как ты сделал — возьмут дерево и париться не будут. В итого говновелосипед который создает проблемы.
Вторые изобретут новые структуры данных, возможно то же дерево, и снова в итоге говновелосипед который создает проблемы.
Что интересно, если люди умеют учиться, то ни там, ни там проблем не будет.
Первые могут не только решать типовые, но как минимум смогут выяснить, что задача не решается в лоб типовым подходом.
Вторые могут не только хорошо решать уникальные, но не брезгуют стандартными алгоритмами и структурами данных.
G>>>Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника. I>>Ты прав с точностью до наоборот. G>Почему? У тебя данные из ничего появляются в памяти?
Данные всегда в памяти. Пудозреваю, ты думал что данные всегда где то в базе или в сети и хотел свести задачу к типовой ?
Похоже это про тебя :
"Велосипедостроитель получается не из умения решать нестандартные задачи, а из нежелания учиться или хотя бы смотреть изредка по сторонам или хотя бы задавать вопросы. "
I>>Есть мир вне Шарепоинта. G>А причем тут SharePoint? Ты считаешь что сбалансированное дерево только в SharePoint можно посторить?
Вещи про которые я говорил, встречаются много чаще чем тебе кажется.
Просто во многих аутсорсных конторах появилось новое поколение менеджеров из вчерашних джуниоров, которые не зная базы обещают всё подряд, а потом заставляют девелоперов расставлять костыли и писать водопроводный код.
Вот и ходят по собеседованиям эдакие "программисты-сантехники" — специалисты по костылям и водопроводному коду.
Здравствуйте, gandjustas, Вы писали:
I>>Ты лучше научись вопросы задавать, а делать вид что один ты здесь умный. G>А я тут причем? Это ты прячешься за 10мб спецификаций.
По моему это ты предлагаешь решения не интересуясь ни требованиями, ни ограничениями.
G>>>А почему так не сходятся? Память нинче дешевая. 4гб стоят дешевле моего дня работы. Причем сильно дешевле. I>>Память и адресное пространство нужно другим задачам. G>Каким? Памяти мало?
Мало. Другие задачи это частично задачи этого же приложения, всем нужна память, частично — задачи ОС.
I>>Ну ты же сказал, что алгоритм не надо оптимизировать если менее нескольких часов работает. Зачем тогда слои и тд ? G>Тебе же полсекуды надо. А у меня только чтение с диска дольше идет.
То есть, ты предлгагаешь оптимизировать мой случай на основании каких то своих ограничений ?
Похоже ты натягиваешь типовое решение на уникальный случай, рожая велосипед
Здравствуйте, gandjustas, Вы писали:
НС>>А задача разворота списка что, алгоритмическая? Т.е. переворот списка по принципу ханойской башни это алгоритм, который надо придумать? Жесть. G>Да, потому что есть ровно один алгоритм разворота списка на месте. И если ты его заранее не знаешь, то надо придумать.
А алгоритм цикла ты каждый раз не придумываешь?
НС>>А строку ты часто в реальных программах разворачиваешь? G>Нет
Вот видишь.
G>но задача не на знание алгоритма, а на знание платформы.
1) ЭТО НЕ ЗАДАЧА НА ЗНАНИЕ АЛГОРИТМА!!!
2) Какие знания платформы ты проверяешь разворотом строки? Наличие индексера у класса string?
G>Некоторые пытаются разворачивать строку на месте, не зная что строки immutable
А зачем знать что строки immutable, если у string индексер только get акцессор содержит?
G>Некоторые не могут цикл нормально написать
Это знание платформы?
G>Операций со строками в реальных программах много происходит.
Здравствуйте, Undying, Вы писали:
U>Старый алгоритм так и работал, т.е. первоначально накладывал фильтр на сигнал. В результате терялась(загрублялась) информация о точности данных
Значит фильтр неправильный. Простейший ВЧ фильтр — не единственный вариант.
Здравствуйте, gandjustas, Вы писали:
НС>>Затем что это напрямую влияет на качество и эффективность программиста. G>На качество и эффективность самое большое влияние оказывают умение читать код, а не писать. G>На втором месте — знание среды, в которой работает. Тройку замыкает усидчивость и внимательность.
G>Умение жонглировать ссылками оказывает настолько маленькое влияние в enterprise разработке, что даже упоминать смешно.
В энтерпрайзе по моему мнению такой код, что нужно на раз знать все возможные последствия и сайд-эффекты у каждой строчки.
НС>>Конечно не всем. Это надо программистам. Ну так мы и собеседуем не вообще, а для конкретных вакансий. G>Угу, и немалая часть конкретных вакансий это enterprise разработка, где жонглирование ссылками бесполезно.
Наоборот, именно там и важно понимать все эти ссылки и многое другое.
НС>>>>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен. G>>>Практика показывает обратное. НС>>Практика именно это и показывает. G>У нс разная практика.
Судя по тому, как ты не задав ни одного вопроса предложил наихудшее решение да еще начал доказывать, что оно будет работать на раз, сильно сомневаюсь, что у тебя адекватная практика.
Здравствуйте, gandjustas, Вы писали:
G>На качество и эффективность самое большое влияние оказывают умение читать код, а не писать.
Это связанные умения.
G>На втором месте — знание среды, в которой работает. Тройку замыкает усидчивость и внимательность.
Это не объясняет, почему у разных программистов с одинаковым опытом производительность может отличаться на порядок.
G>Умение жонглировать ссылками оказывает настолько маленькое влияние в enterprise разработке, что даже упоминать смешно.
Нет, смешно это когда человек, претендующий на работу программиста, не в состоянии справится с примитивной ссылочной конструкцией. И энтерпрайз, он очень разный, не обобщай шерпоинт на все остальное.
НС>>Компьютер еще дизайн софта самостоятельно делать не научился. Так что пока только головой. G>Но можно писать так, чтобы минимум удерживать в голове.
Иногда нельзя. В DSL, к примеру, без понимания таких конструкций просто делать нечего, там косвенность в 3-4 уровня — норма. И никакие алгоритмы тебя не спасут, только полномасштабные средства, которые сделают за тебя вообще все.
G>Поэтому самый лучший разворот списка:
Чем он лучший? Тем что кода в два раза больше надо писать?
НС>>Практика именно это и показывает. G>У нс разная практика.
Это я уже понял. Кто то под шерпоинт пишет, а кто то и сам шерпоинт.
Здравствуйте, Undying, Вы писали:
U>Программистскую спесь поубавь.
Ты чего то перепутал. Спесь это у тебя, а у меня набитые шишки.
U> В любой производственной деятельности работники делятся на конструкторов (люди, которые видят задачу целиком и умеют разбить ее на более простые части), технологов (люди, которые видят типовые задачи и умеют сделать их решение тривиальным) и рабочих (тех кто собственно воплощает продукт в реальность).
Нет, не в любой, это очевидно.
U>Хотя на самом деле программирование это такая же производственная деятельность
Нет никакой такой производственной деятельности вообще, есть конкретные задачи. И нет, они не абсолютно одинаковы, везде своя специфика.
U> и работа программистов точно также разделяется на конструкторскую, инженерную и рабочую.
Как минимум рабочие в программировании не нужны, потому что в материальном производстве рабочии занимаются созданием копий изделий, а в программировании копирование бесплатно. Ну и конструктор это разновидность инженера, совершенно непонятно почему ты их противопоставляешь. Инженер-конструктор в программировании это как раз программист и есть, а инженер-технолог это тот человек, который занимается обеспечением VCS, CI, релиз-менеджментом и т.п.
U> Разница только в том, что т.к. программисты отказываются это признавать, то в их проектах зачастую процветает кустарщина и бардак.
Батхерт в тебе я чую.
НС>>Мне кажется с самого начала было понятно, что речь не идет об найме обезьянок для шаблонного кода. U>Гордыня на мозг не жмет?
Нет. А тебе? А то от тебя столько пафоса льется, что деревьев не видно.
Здравствуйте, gandjustas, Вы писали:
I>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>Не понял, зачем?
В рамочку и на стенку.
G>Нет, я же говорю, что писать уникальный код приходится редко.
Надо говорить "мне приходится редко"
G> Незачем проверять это умение на собеседовании.
Мы уже поняли, что тебе программисты не нужны. О чем тогда ты споришь?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
I>>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>>Не понял, зачем? НС>В рамочку и на стенку.
То есть доводов у тебя нет?
G>>Нет, я же говорю, что писать уникальный код приходится редко.
НС>Надо говорить "мне приходится редко"
Тебе надо? Ну говори.
А вообще обрати внимание. Тебя просят дать оценку. Ты называешь цифру или диапазон, на основании чего? Обычно мозг пытается сопоставить задачу с теми, которые ты уже решал. Когда ты пишешь код, мозг работает также. Ты неосознано генерируешь код, который ты уже писал. А иногда очень осознанно делаешь копипасту.
G>> Незачем проверять это умение на собеседовании. НС>Мы уже поняли, что тебе программисты не нужны. О чем тогда ты споришь?
Это ты споришь о сущности умения разворачивать списки, пытаясь доказать что это практически Умение писать код. Но у тебя нет ни доводов, ни фактов, ничего...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>На качество и эффективность самое большое влияние оказывают умение читать код, а не писать. НС>Это связанные умения.
Практика показывает что не связанные.
Очень мнгого программистов видел, которые генерируют тонны кода. Обрабатывают сотни кейсов, которые никогда не встретятся из-за особенностей api, закладывают гибкость, там где она не нужна итп. почти весь код бесполезен.
Писать код они точно умеют.
G>>На втором месте — знание среды, в которой работает. Тройку замыкает усидчивость и внимательность. НС>Это не объясняет, почему у разных программистов с одинаковым опытом производительность может отличаться на порядок.
Именно объясняет. Исследования проводились как раз на предмет как пишут. Считали количество программ, багов итд. А вот как раз умения за пределами кодинга и отладки не проверяли. Моя практика показывает, что наиболее эффективные программисты могу за час просмотреть кода на 500+ строк и рассказать потом как он работает, какие проблемы и как улучшить.
G>>Умение жонглировать ссылками оказывает настолько маленькое влияние в enterprise разработке, что даже упоминать смешно.
НС>Нет, смешно это когда человек, претендующий на работу программиста, не в состоянии справится с примитивной ссылочной конструкцией. И энтерпрайз, он очень разный, не обобщай шерпоинт на все остальное.
Да не нужно это умение. Как бы ты не пытался доказать обратное. У тебя нет ни фактов, ни адекватных доводов. Везде только твое неподкрепленное ничем мнение.
НС>>>Компьютер еще дизайн софта самостоятельно делать не научился. Так что пока только головой. G>>Но можно писать так, чтобы минимум удерживать в голове.
НС>Иногда нельзя. В DSL, к примеру, без понимания таких конструкций просто делать нечего, там косвенность в 3-4 уровня — норма. И никакие алгоритмы тебя не спасут, только полномасштабные средства, которые сделают за тебя вообще все.
О да, каждый день программисты пишут dsl_и 😃
G>>Поэтому самый лучший разворот списка:
НС>Чем он лучший? Тем что кода в два раза больше надо писать?
Тем что не надо ничего держать в голове. Нету циклов со сложными инвариантами, и с точки зрения платформы это оптимальный способ.
НС>>>Практика именно это и показывает. G>>У нс разная практика.
НС>Это я уже понял. Кто то под шерпоинт пишет, а кто то и сам шерпоинт.
Сам шарепонт написан индусами. Под капотом такой страшный код, что иногда удивительно как он работает. Статический анализ на сборках sp выдает миллионы замечаний. Тем не менее МС говорит что у sp 120M пользователей по всему миру.
И это не только sp такой. каждая корпоративная платформа такая. Где-то чуть лучше, где-то хуже. Это не потому что разработчики плохие. Это экономика разработки enterprise софта такая.
Здравствуйте, Ikemefula, Вы писали:
I>В энтерпрайзе по моему мнению такой код, что нужно на раз знать все возможные последствия и сайд-эффекты у каждой строчки.
Зависит.
НС>>>Конечно не всем. Это надо программистам. Ну так мы и собеседуем не вообще, а для конкретных вакансий. G>>Угу, и немалая часть конкретных вакансий это enterprise разработка, где жонглирование ссылками бесполезно.
I>Наоборот, именно там и важно понимать все эти ссылки и многое другое.
Нет, ссылки не нужны. Более того, часто бывает что
Object.ReferenceEquals(x.A,x.A) == false
В такой ситуации жонглирование ссылками — рассадник багов.
НС>>>>>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен. G>>>>Практика показывает обратное. НС>>>Практика именно это и показывает. G>>У нс разная практика.
I>Судя по тому, как ты не задав ни одного вопроса предложил наихудшее решение да еще начал доказывать, что оно будет работать на раз, сильно сомневаюсь, что у тебя адекватная практика.
Обоснуй что худшее. Начни с твоих "особенностей".
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>А идеальный вариант: G>>
G>>var a = str.ToCharArray();
G>>Array.Reverse(a);
G>>return new string(a);
G>>
G>>Но такой пишет каждый десятый.
I>Если у вас такое пишет каждый десятый, то вполне понятны твои вопли про реверс списка I>У нас такое пишет каждый первый
На собеседовании? Я тебе просто не верю.
Здравствуйте, gandjustas, Вы писали:
I>>Если у вас такое пишет каждый десятый, то вполне понятны твои вопли про реверс списка I>>У нас такое пишет каждый первый G>На собеседовании? Я тебе просто не верю.
Разумеется. Но мы же здесь не твою веру обсждаем, правильно ?
Здравствуйте, gandjustas, Вы писали:
I>>Наоборот, именно там и важно понимать все эти ссылки и многое другое. G>Нет, ссылки не нужны. Более того, часто бывает что G>Object.ReferenceEquals(x.A,x.A) == false
Это как раз и требует понимания, что такое ссылки. Скажем ссылка требует уверенного понимания идентити и хотя бы представляения о том, что есть референс тайпы и валюе тайпы.
G>В такой ситуации жонглирование ссылками — рассадник багов.
После "каждый десятый пишет" твои аргументы даже слушать смешно.
I>>Судя по тому, как ты не задав ни одного вопроса предложил наихудшее решение да еще начал доказывать, что оно будет работать на раз, сильно сомневаюсь, что у тебя адекватная практика. G>Обоснуй что худшее. Начни с твоих "особенностей".
Хороший инженер обязан узнавать особенности до того, как начнет решения выдвигать. В противном случае это не инженер а изобретатель велосипедов.
Все нужные объяснения уже были дадены — читай внимательно.
Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n) 
