Google-oriented programming



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

    Гуглить не зазорно


    Chris пишет в статье «How Much Does an Experienced Programmer Use Google»:

    Я часто слышу, как начинающие программисты, нервно озираясь по сторонам, спрашивают: «Это нормально, если я часто пользуюсь Google?».

    Ответ на этот вопрос — решительное да.

    Google — неотъемлемая часть работы каждого разработчика. Люди, работа которых состоит из умственных усилий, называются работниками умственного труда, и установлено, что они тратят 40% их времени на поиск информации. Иными словами, почти половина вашей работы в качестве разработчика — умение пользоваться Google
    .


    IDC в своем исследовании «The High Cost of Not Finding Information» (PDF) придерживается похожей оценки:

    Мы используем общую оценку: типичный работник умственного труда тратит около 2,5 часов в день или примерно 30% от рабочего дня на поиск информации.


    Кто владеет информацией, владеет миром. В случае с разработчиками — владеет решением.

    Из статьи «Do Experienced Programmers Use Google Frequently?» Umer Mansoor:

    «Часто ли опытные программисты пользуются Google?»

    Громкий ответ — ДА, опытные и хорошие программисты используют Google… часто. На самом деле даже чаще начинающих.
    Большая причина использовать Google в том, что сложно запомнить все мелкие детали и нюансы, особенно если вы программируете на нескольких языках и используете кучу фреймворков
    .


    Синдром самозванца


    Люди, подверженные синдрому самозванца, уверены в том, что они обманщики и не заслуживают успеха, которого достигли. Синдром самозванца ортогонален эффекту Даннинга — Крюгера: квалифицированные специалисты склонны занижать свои способности, в то время как низкоквалифицированные имеют завышенные представления.


    Иллюстрация из статьи «The Imposter Syndrome in Software Development»

    Для программистов это часто выражается в рефлексии: «программист ли я, или просто хорошо гуглю?».

    Scott Hanselman в статье «Am I really a developer or just a good googler?» пишет об этом:

    Недавно я получил очень серьезное и хорошо сформулированное письмо от молодого человека за рубежом. Вот что он пишет:
    «Иногда в моей голове звучит вопрос — действительно ли я разработчик или просто хорошо гуглю. Я не знаю правильного ответа — я гуглер или разработчик. Скотт, пожалуйста, помоги мне выяснить».


    В другой статье «I'm a phony. Are you?» он пишет, что большинство программистов подвержено синдрому самозванца — в том числе и он сам. И вот что он считает по этому поводу:

    Но вот в чем дело. Мы все иногда чувствуем себя обманщиками. Мы все обманщики. Это часть роста. Мы попадаем в ситуации, которые немного сложнее того, с чем мы можем справиться. Но мы справляемся с ними, мы не обманщики, и мы двигаемся к следующему испытанию.


    Разница между начинающим и опытным


    Мы выяснили: гуглят все. Разница в том, как.

    «How Much Does an Experienced Programmer Use Google»:

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


    Призываем уважаемых комментаторов: как Google помогает вам в работе? Считаете ли, что гуглить зазорно, и лучше пойти прочесть пару книг? Рассказывайте.
    Метки:
    GeekBrains 38,71
    Образовательная площадка для программистов
    Поделиться публикацией
    Похожие публикации
    Комментарии 150
    • +29
      Считаете ли, что гуглить зазорно, и лучше пойти прочесть пару книг?
      Это взаимодополняющие процессы. Я стараюсь много читать, причём книги из самых разных областей программирования. У меня нет цели запомнить всё или начать использовать эти знания на следующий день. Моя цель — расширять кругозор, чтобы когда появится необходимость, я знал в какую сторону копать. А сам этот процесс всегда начинается с поисковика.
      • +11
        Тут вопрос даже не в какую сторону копать, а скорее в какую сторону НЕ копать. Как известно для любой волнующей человека проблемы всегда легко найти решение — простое, достижимое и ошибочное (there is always a well-known solution to every human problem — neat, plausible, and wrong).

        Главное для чего нужно читать книжки — это не чтобы найти правильное решение (его вам выдаст Google), а для того, чтобы отсеять кучу неправильных (их тоже будет в выдаче поисковика в достатке).
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            В моём случае, скорее нет. Я просто не в состоянии запомнить все нюансы, связанные с выбором конкретного инструмента (он, выбор, ведь должен быть аргументированным). Важнее знать, что такой инструмент есть и как раз уметь найти его сильные и слабые стороны уже непосредственно в нужный момент. Lazy loading, проще говоря. Например, книга "7 languages in 7 weeks" ничего мне не расскажет о недостатках этих языков, не убережёт от стандартных для них граблей, но когда придёт время я хотя бы буду знать, что такие языки есть и в каких областях используются.
        • +9
          Применительно к статье, интернет можно считать (с определёнными оговорками) аналогом библиотеки. И, слава Гуглу и иже с ним, что поиск информации занимает минуты и часы, а не дни и недели.

          С другой стороны, использование готовых решений из интернета не отменяет чтение книг. Чтение книг создаёт базу, а «готовые решения» — это для конкретной проблемы. Причём часто без базы невозможно подобрать или адаптировать «готовое решение» под конкретную проблему. И беда многих начинающих программистов, что они этого не понимают.
          • +26
            Я программирую вот уже почти 10 лет, и я признаюсь вам честно — за все это время я не дочитал ни одной книги по программированию. Я просто начинаю засыпать, когда читаю их, и усвоение материала начинает стремиться к нулю. В результате начинаешь просто пролистывать и искать то, что тебе более интересно и понятно. Мне кажется, это личное предпочтение. Лично мне вот не нравится сам формат книги, но я с удовольствем посмотрю видеоуроки и полистаю официальную документацию, что бы «включиться» в новый фреймворк или технологию. Для меня это тоже самое, что и книга, но гораздо быстрее. Ну и да — никакая книга не заменит вам практику, технику «просто возьми и начинай что-то делать (тестовый проект, todo list, итд), решая задачи по мере поступления».
            • +8
              Я тоже жил с таким подходом и добился определенного результата.
              Но книги дают систематические знания. А практика дает знания отрывочные.
              С систематическими знаниями можно решать задачи быстро и эффективно, а с отрывочными — просто решать. А скорость и эффективность — дело случая.
              Можно сколько угодно много рассказывать о простоте и эффективности самообучения, но истина проста: систематическое обучение это другое и никакое самообуение не может его на 100% заменить.
              Я лично перестал себя обманывать и стал больше времени уделять систематическим и структурированным источникам знаний. Чего и вам желаю.
              • +2
                Самообучение не исключает использование структурированных источников.
              • НЛО прилетело и опубликовало эту надпись здесь
            • +15
              Сегодня в любой отрасли разработки умение пользоваться гуглом — это, на мой взгляд, один из ключевых навыков программирования. Конечно, когда я говорю «пользоваться гуглом», это значит не просто уметь слепо копи-пастить код со stackoverflow, а умение находить решения и адекватно применять их в своем проекте.
              Именно поэтому лично я считаю идиотизмом задачи на собеседованиях вроде «а сбалансируйте-ка бинарное дерево». Недавно было такое собеседование, на мой вопрос «разрешается ли пользоваться гуглом», ответили «мы хотим проверить ваши навыки программирования, а не навыки пользоваться гуглом». Так и хотелось спросить, не запрещено ли у них случаем пользоваться гуглом в рабочее время, а то может быть, не стоит тратить время.
              Как по мне, так гораздо более адекватно сегодня давать задачи более сложные (те, на которые невозможно найти ответ в гугле за 30 секунд поиска), но с возможностью пользоваться любыми источниками — такие задачи гораздо ближе к реальности, чем эфемерные «изобретите алгоритм, который точно кто-то уже изобрел до вас».
              • +8
                Зачастую Гугл — лучший способ найти нужное место в документации.
                • +1
                  Дерево то сбалансировали?
                  Это на какую должность такое спрашивают? Что за язык? А то у меня синдром самозванца начинает развиваться…
                  • +1
                    Дерево не сбалансировал. Вакансия была — веб-разработчик на Python.
                    Сейчас работаю в компании, в которой на собеседовании не задали ни одного технического вопроса, зато предложили обсудить мои предыдущие проекты, самые трудные задачи, с которыми я сталкивался, как я их решил тогда и что бы я изменил в их решении сегодня.
                    Таких собеседований, к счастью, тоже было достаточно.

                    Собсеседования с вопросами из серии «вспомни первый курс по алгоритмам», были, но бинарные деревья были один раз. В основном задавали вопросы про всякие linked-list'ы, там все гораздо проще, если помнишь хоть что-нибудь.
                    • 0
                      В основном задавали вопросы про всякие linked-list'ы, там все гораздо проще, если помнишь хоть что-нибудь.
                      И тем не менее простейший вопрос типа «посчитайте количество элементов в бесконечном односвязном списке» ставит огромный процент претендентов в тупик.
                      • 0
                        посчитайте количество элементов в бесконечном односвязном списке

                        Нормальный претендент в ответ на такой вопрос напишет единственную строчку: return(INFINITY).


                        Потому что человек с программистким мышлением требует точной постановки задачи. В условии сказано: бесконечный — значит, размер равен бесконечности. Если Вы имели в виду "стопицот" — то это не "бесконечный", а "не помещающийся в памяти", и так и надо писать при постановке задачи; программист не играет в угадайку "а что постановщик вообще этим сказать хотел".

                        • 0
                          Потому что человек с программистким мышлением требует точной постановки задачи.
                          Вы уж извините, но постановка задачи как раз вполне себе чёткая.
                          В условии сказано: бесконечный — значит, размер равен бесконечности.
                          Если сказано бесконечный, то это значит, что это списка без конца (по английски используется слово endless, что несколько упрощает задачу, но идея та же). А дальше — да, небольшой тест на разумность: хороший кандидат поймёт, что имелось в виду сразу или переспросит, а плохой да, напишет return(INFINITY).
                          Если Вы имели в виду «стопицот» — то это не «бесконечный», а «не помещающийся в памяти», и так и надо писать при постановке задачи; программист не играет в угадайку «а что постановщик вообще этим сказать хотел».
                          Мы как бы говорим не об аутсорсе, а о приёме человека в штат. Если человек не готов додумывать, задавать вопросы в случае непонимания условия задачи, и требует, чтобы ему всё разжевали и в рот положили — то он нам, извините, не нужен: с подобными задачами отлично справляются условные «индусы» на аутсорсе, которые стоят гораздо, гораздо, дешевле.

                          P.S. Про «постановку в тупик» — я имел в виду, конечно, неумение написать код. Понятно, что return(INFINITY) — это клиника, но большинство кандидатов, даже поняв — что именно от них хотят неспособны это сделать.
                          • +1
                            Если сказано бесконечный, то это значит, что это списка без конца (по английски используется слово endless, что несколько упрощает задачу, но идея та же)

                            "endless" — это в данном случае не "бесконечный", а "неограниченный". Переводчики такие переводчики.


                            Если человек не готов додумывать

                            Вот в этом-то и проблема: у большинства нанимателей почему-то не возникает даже и намёка на мысль о том, что разные люди могут думать по-разному, и воспринимать Ваше задание по-разному. Попытки "додумать" при этом могут привести к весьма плачевным результатам. Тут в соседнем треде кто-то "додумал", что при нечисловых данных на входе программа должна падать — "а чо, всё равно ничего сделать нельзя" — а если, утрируя, эта программа управляет реактором на АЭС?


                            Например, я в упор не понимаю Вашу задачу. "Посчитать количество слов" в неограниченном списке невозможно: если критерий останова есть, то список не является неограниченным, и наоборот, если критерия останова нет, то return(INFINITY) является правильным ответом. Вы явно имеете в виду что-то другое, но — как собака: "знать-то знаю, но выговорить не могу".

                            • 0
                              Например, я в упор не понимаю Вашу задачу. «Посчитать количество слов» в неограниченном списке невозможно: если критерий останова есть, то список не является неограниченным, и наоборот, если критерия останова нет, то return(INFINITY) является правильным ответом. Вы явно имеете в виду что-то другое, но — как собака: «знать-то знаю, но выговорить не могу».
                              Это у Вас какой-то заскок. Бывает. При очном собеседовании всегда переспросить можно, а на Хабре понять малость сложнее.

                              Отсутствие конца в списке не обозначает, что элементов в нём бесконечное число. Тут вроде про python говорили, так что пусть пример будет на питоне:
                              >>> a = [1, [2, [3, []]]]
                              >>> a[1][1][1] = a[1]
                              
                              Теперь у нас в переменной a список «без конца»:
                              >>> a[0]
                              1
                              >>> a[1][0]
                              2
                              >>> a[1][1][0]
                              3
                              >>> a[1][1][1][0]
                              2
                              >>> a[1][1][1][1][0]
                              3
                              >>> a[1][1][1][1][1][0]
                              2
                              >>> a[1][1][1][1][1][1][0]
                              3
                              >>> a[1][1][1][1][1][1][1][0]
                              2
                              >>> a[1][1][1][1][1][1][1][1][0]
                              3
                              
                              Однако: ходить-то вы по этому списку можете сколько угодно, но элементов-то там больше не стало! Их там по прежлему три!

                              Вот я и хочу, чтобы мне написали функцию, которая выдавала бы это число, оценили бы сложность (как зависит время работы вашей фукнции от размера списка?) и т.п. Элементарная, в общем-то, задача, но народ путается.
                              • +3

                                Дело в том, что для того, чтобы взять поток мысли, выдаваемый клиентом, и перевести его в однозначную формулировку, понятную программисту (software developer), предназначен специальный человек — software consultant. И платят ему, мягко говоря, несколько больше, чем программисту, потому что работа очень нервная — целый день с идиотами общаться.


                                (Иногда software developer и software consultant совмещаются в одном человеке — мне, например, но это далеко не всегда так ;)


                                Ваша задача по-человеческипрограммистски будет звучать так:


                                Дан однонаправленный связный список (a[i].next = a[j]) из конечного числа элементов L, при этом известно, что он зациклен (т.е. a[y].next = a[x] при некоторых неизвестных x и y, таких, что x < y). Определить L.

                                А есть ещё следующая ступень — software archaeologist: это когда есть куча кода без комментариев и документации, и надо понять, что эта куча делает, и почему она написана именно таким, а не иным образом. Это уже ещё более другие деньги.

                                • 0
                                  Дело в том, что для того, чтобы взять поток мысли, выдаваемый клиентом, и перевести его в однозначную формулировку, понятную программисту (software developer), предназначен специальный человек — software consultant. И платят ему, мягко говоря, несколько больше, чем программисту, потому что работа очень нервная — целый день с идиотами общаться.
                                  Опять оказывается, что мы говорим «мимо» друг друга. «Клиенты» и «потоки мысли» существуют только в одном из миров (Консультационное ПО), во всех остальных програмист ну никак не может получить готовую формулировку, потому что важная часть его работы — это разработка требований и сочетание «хотелок» и «возможностей».

                                  А ваша «человеческая» формулировка — невероятно узка. Можно же ведь переформулировать и так: «найти количество разных чисел, которые выдаст функция erand48 при заданном «зерне»» — ведь это та же самая задача, не так ли?

                                  Но породить формулировку — это, как я уже заметил, полдела: да, совсем плохие кандидаты и на это не способны, но это позволяет отсеять только лишь небольшой процент. В любом случае: придумав точную формулировку нужно ведь потом эту задачу ещё и решить — и вот тут-то оказывается как-то, что мастера «Google-oriented programming»а на это зачастую неспособны.
                                  • +1
                                    вот тут-то оказывается как-то, что мастера «Google-oriented programming»а на это зачастую неспособны.

                                    Моё гугл-фу сильнее твоего ;)


                                    «найти количество разных чисел, которые выдаст функция erand48 при заданном «зерне»»

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

                                    • 0
                                      Моё гугл-фу сильнее твоего ;)
                                      Ну да — это половина решения. Но это всё-таки классическая задача, на практике всё-таки приходится придумывать «алгоритм похожий вон на то», а не просто copy-paste делать.

                                      Это другая задача (Мне почему-то кажется, что это количество одинаково вне зависимости от зерна и ограничено разрядностью используемых чисел, но я могу ошибаться).
                                      Вы имеете в виду, что генератор всегда обходит все 248 чисел? Это, конечно, хорошее замечание, но это ведь не мешает вам написать функцию и проверить — действительно ли это так? Это ведь верно только для линейно-конгруэнтного метода (и то не всегда). А для других PRNG количество чисел вполне может зависеть от зерна.
                                      • +1

                                        Видите ли, мало поставить задачу, нужны ещё и граничные условия. Например — где у нас ограничение: по памяти или по процессору? В случае с массивом в памяти решение одно, а в Вашем втором примере (про res = erand48(res)), возможно, имеет смысл кешировать возвращаемые подопытной функцией результаты, чтобы два раза не вставать вызывать erand48(x) (один раз — для "быстрого" указателя, второй — для "медленного"). Предлагаемые решения могут сиииильно отличаться в зависимости от.

                                        • 0
                                          В случае с массивом в памяти решение одно
                                          Это кто ж вам сказал, что «в случае с массивом решение одно»? Во-первых не с массивом, а со списком, а во-вторых обращение в память — это тоже, в общем-то, недёшево. И вполне может оказаться, что кеширование окажется небесполезно.

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

                                          Предлагаемые решения могут сиииильно отличаться в зависимости от.
                                          Ну дык. Собственно в этом и заключается специфика работы не в области Консультационное ПО: когда у тебя нет чётких, заранее обговоренных криетериев «приёмки», то очень часто постановка задачи меняется в зависимости от того, что показывают эксперименты с той или иной реализацией. Так что выявлять «граничные условия» приходится, собственно, тому, кто решает задачу.

                                          И да, все эти вещи обсудить с хорошим кандидатом тоже не грех… после того, как он напишет хоть какую-нибудь реализацию, конечно.
                                          • 0
                                            Во-первых не с массивом, а со списком,

                                            Под "массивом" я подразумеваю структуру данных, имеющую интерфейсный метод [], то есть допускающую доступ по индексу — а Ваш список это допускает: даже если для этого требуется вернуться к корню и добежать при помощи .next до нужного элемента — всё равно это возможно, а детали реализации нас в данный момент не интересуют. (И не надо мне тыкать на википедийное "набор компонентов, расположенных в памяти непосредственно друг за другом", а то я Вам припомню про отображение виртуальных страниц на физическое ОЗУ и файл подкачки ;)


                                            А мой "бесконечный список" из /dev/rand такого интерфейса не имеет иметь не может ;)

                                            • 0
                                              А мой «бесконечный список» из /dev/rand такого интерфейса не имеет иметь не может ;)
                                              То есть списком и не является.

                                              А вот списк erand48 таки списком является и «интерфейсный метод []» он, разумеется, поддерживает.

                                              (И не надо мне тыкать на википедийное «набор компонентов, расположенных в памяти непосредственно друг за другом», а то я Вам припомню про отображение виртуальных страниц на физическое ОЗУ и файл подкачки ;)
                                              Припомните, почему нет. А заодно объясните — как именно всё это делает среднее время доступа по индексу зависящим от индекса для массива или не зависящим — для списка (это ведь практически самое важное различие между ними).
                                              • +1

                                                Мы с Вами просто опять говорим на разных языках. Я же сказал:


                                                Под "массивом" я подразумеваю структуру данных, имеющую интерфейсный метод []

                                                Всё. Про время доступа я ничего не говорил. Ваше определение "массива" отличается от него, всего-то делов. Бывает.

                                                • 0
                                                  Ваше определение «массива» отличается от него
                                                  Это не «моё определение». Это как раз то самое «википедийное» определение. На русской википедии:
                                                  одинаковое время доступа ко всем элементам
                                                  На английской:
                                                  Both store and select take (deterministic worst case) constant time
                                                  .
                                                  всего-то делов.
                                                  И действительно: когда задача на собеседовании определяется в неформальных терминах, то это ужас, это качмар, это небо падает на землю, когда одно из фундаментальных понятий Computer Scrience придаётся извращённый смысл — то это «всего-то делов».

                                                  Хороший подход. Объективный такой. Мне нравится.
                                                  • 0

                                                    Стоит заметить, что в русской вики определение получается некорректное в отличии от английской, где рассматривается determenistic worst case time.


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

                                                    • +1
                                                      одинаковое время доступа ко всем элементам

                                                      "Одинаковое время доступа" — это "достоинство" (Вы заголовки секций, на которые ссылаетесь, хоть читаете?), а не часть определения; а про то, что "одинаковое" оно преимущественно в теории — можно долго спорить (с учётом того, что искомая область памяти может оказаться высвопленной в файл подкачки).


                                                      одно из фундаментальных понятий Computer Scrience придаётся извращённый смысл

                                                      Извращённый смысл ему придан десятилетиями виртуализации. В наше время массив — это "структура данных, предоставляющая доступ к своим элементам по целочисленному индексу". Всё. Как оно хранится, как оно работает — это всё детали реализации. Это может быть обычный сишный массив — *(base + sizeof(element) * index), это может быть memory mapped file, это может быть sparse array, это может быть всё, что угодно; если возможен доступ arr[i] для любого i — то для целей дискуссии за пивом, каковую мы с Вами тут имеем, это "массив". Dixi.

                                                  • 0
                                                    А вот списк erand48 таки списком является и «интерфейсный метод []» он, разумеется, поддерживает.

                                                    А кто мешает добавить такой метод в список as by Wesha?
                                                    • 0
                                                      Тот факт, что в «списке» на основе
                                                      /dev/rand
                                                      каждый элемент может быть прочитан лишь один раз.
                                  • 0
                                    У меня какой-то хаскель от вашего питона.

                                    Сколько элементов в списке
                                    Prelude> :t repeat
                                    repeat :: a -> [a]
                                    Prelude> take 10 $ repeat 1
                                    [1,1,1,1,1,1,1,1,1,1]
                                    

                                    ?

                                    Сколько элементов в списке
                                    Prelude> let meh = 1 : meh
                                    Prelude> take 10 meh
                                    [1,1,1,1,1,1,1,1,1,1]
                                    

                                    ?

                                    А сколько элементов в
                                    Prelude> let fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
                                    Prelude> take 10 fibs
                                    [0,1,1,2,3,5,8,13,21,34]
                                    

                                    ?
                                  • 0
                                    «endless» — это в данном случае не «бесконечный», а «неограниченный». Переводчики такие переводчики.

                                    Я бы неограниченные вещи называл Unbounded. Endless в этом контексте ни разу не приходилось слышать.

                                    Но такая задача меня тоже ставит в тупик.
                                    • 0
                                      В данном случае речь идёт не об «unbounded», а именно об «endless», но «bounded».

                                      Ту же самую задачу можно хоть на Бейсике переписать и решить — суть-то не в синтаксисе.

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

                                      P.S. Можно, конечно, нарваться на условного «Нильса Бора», который всё знает и понимает, но не хочет отвечать потому, что его это всё достало и отсеять его — но так ли это страшно? Это ведь всего лишь обозначает, что этот самый условный «Бор» не очень-то и хочет работать конкретно у вас и вместо того, чтобы просто забрать CV вот так вот выкаблучивается — ну дык стоит ли тогда пытаться его силой затаскивать, если его душа реально чего-то другого хочет?
                                      • +3
                                        Ту же самую задачу можно хоть на Бейсике переписать и решить — суть-то не в синтаксисе.

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

                                        А скорее всего получится, что классический вопрос о нахождении петли в цикле был бы корректнее.

                                        Умение красиво рассказывать про ленивые вычисления в Хаскеле (где действительно бывают структуры, о размере которых нельзя говорить)

                                        А чем ваш зацикленный список отличается от моего примера с let ones = 1 : ones? Рантайм точно так же будет вычислять thunk, который ссылается на себя же, который ссылается на себя же, который… А элемент один.

                                        Или бесконечность.

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

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

                                        Это ведь всего лишь обозначает, что этот самый условный «Бор» не очень-то и хочет работать конкретно у вас

                                        Я вообще плохо представляю, кем надо быть, чтобы люди хотели не задачки интересные решать, не делать продукты в окрестности специализации вашей фирмы, не деньги зарабатывать, в конце концов, а именно работать у вас.
                                        • 0
                                          А пример ваш питоньий можете на C++ переписать?
                                          На C++ будет чуть длиннее, но, в общем, всё то же самое:
                                          struct Node {
                                            int value;
                                            Node* next;
                                          };
                                          
                                          int main() {
                                            Node *head = new Node{1, new Node{2, new Node{3, nullptr}}};
                                            head->next->next->next = head->next;
                                            std::cout << find_len(head) << std::endl;
                                          }
                                          
                                          Мне просто очень интересно, что из этого получится, можно ли это будет называть списком, и так далее.
                                          А почему нет? SICP, упражнение 3.18, к примеру — как раз от таких говорит.

                                          И если бы мы с вами сошлись на том, что это таки список, то, вполне вероятно, на построенной в ходе дискуссии аксиоматике удалось бы доказать, что и в списке с числами Фибоначчи всего один элемент.
                                          Это — вряд ли. Там всё таки все элементы разные :-) Ну, почти.

                                          Я вообще плохо представляю, кем надо быть, чтобы люди хотели не задачки интересные решать, не делать продукты в окрестности специализации вашей фирмы, не деньги зарабатывать, в конце концов, а именно работать у вас.
                                          Работодателем. Собственно любой работодатель смотрит, в том числе, и на то, насколько кандидат заинтересован в том, чтобы устроиться к нему на работу.
                                          • +1
                                            Собственно любой работодатель смотрит, в том числе, и на то, насколько кандидат заинтересован в том, чтобы устроиться к нему на работу.

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

                                            • 0
                                              Последние лет так десять в нашей отрасли кандидаты смотрят на то, насколько работодатель заинтересован, в том, чтобы кандидат работал именно на него.
                                              Ну дык. Финальная стадия пузыря, чего вы хотите.

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

                                              Одни рассказ про то, что ошибки, которые стоят, в буквальном смысле слова, сотни миллиардов долларов (Space Shuttle, ТУ-144) это ерунда по сравнению с тем, какой ужас способны устроить программисты — уже смешон. А уж выводы.

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

                                              Но к рядовым разработчикам это ни в одной области не относится — и IT исключением не является.
                                              • 0
                                                А правда заключается в том, что в любой отрасли есть люди, которые очень дорого стоят и за «головы» которых идёт настоящая охота.


                                                ;)

                                            • +4
                                              На C++ будет чуть длиннее, но, в общем, всё то же самое:

                                              Не то же, принципиально не то. Не менее принципиальный вопрос вам на засыпку: какой тип элемента списка в вашем плюсовом коде?
                                              Какой тип элемента списка в вашем питоньем коде?
                                              Какой тип элемента в моём хаскель-коде?

                                              Это — вряд ли. Там всё таки все элементы разные :-) Ну, почти.

                                              Не более разные, чем в первых двух вариантах, где одни единички получаются, разве нет?

                                              Собственно любой работодатель смотрит, в том числе, и на то, насколько кандидат заинтересован в том, чтобы устроиться к нему на работу.

                                              Это какой-то оборзевший работодатель, наверное, ещё тимбилдинги с планкингом каждое утро устраивает.

                                              Любому™ адекватному™ работодателю понятно, что мне, в общем-то, куда интереснее решать интересные задачи, желательно за интересные деньги, нежели чем испытывать благоговение от самого факта работы на Гундекс/Майкругл/етц.

                                              Если работодателю это непонятно (равно как и мне непонятно, что самое важное для работодателя в тырпрайз-разработке — добавленная мной стоимость, а не то, насколько я хорошо понимаю монадки и способен ли рассуждать об аспектно-ориентированном проектировании в терминах кодекартовых квадратов в какой-то там категории), то нам с ним, вероятно, не по пути, и лучше, чтобы это выяснилось пораньше.
                                              • 0
                                                Не менее принципиальный вопрос вам на засыпку: какой тип элемента списка в вашем плюсовом коде?
                                                Причём тут «тип элемента»? От этого у вас алгоритм изменится?

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

                                                В случае с Haskel-струкртурами ни того, ни другого делать нельзя.

                                                Любому™ адекватному™ работодателю понятно, что мне, в общем-то, куда интереснее решать интересные задачи, желательно за интересные деньги, нежели чем испытывать благоговение от самого факта работы на Гундекс/Майкругл/етц.
                                                Ну если вы так считаете — то значит вы к нам и не придёте, проблем-то.

                                                Никто ведь не гонит вас под дулами автоматов именно в Гундекс/Майкругл/етц.
                                                • 0
                                                  Причём тут «тип элемента»? От этого у вас алгоритм изменится?

                                                  Алгоритм нахождения петли у меня не изменится, даже если там будет void*.

                                                  Однако, судя по русской википедии, вариант на питоне уже списком не будет:
                                                  Тип элементов — тот самый тип A, над которым строится список; все элементы в списке должны быть этого типа.


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

                                                  Я запутался, как вы определяете число элементов?
                                        • +2

                                          "Бесконечный" в математическом смысле — это infinite ("бесконечное множество" — infinite set). "Зацикленный" — looped.


                                          Дело в том, что бесконечный незацикленный односвязный список вполне возможен — например, while(1) { fread(fopen('/dev/rand', 'rb'), 1); }. То, про что пишет автор — это конечный зацикленный односвязный список.

                                          • 0
                                            Я у вас тут в упор не вижу списка, извините.

                                            Либо, если немножко послабить требования и назвать это списком, то список вполне себе зацикленный там, где указано, как перейти к следующему элементу. Да и вообще, вот же цикл while!
                                            • 0

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

                                              • +2
                                                На собеседовании к этому времени я бы уже напрочь запутался в терминологии и полюбопытствовал бы, часто ли в фирме возникают задачи, требующие умения различать бесконечные незацикленные списки от конечных зацикленных.
                                                • 0
                                                  А вы что — собираетесь в будущем решать только задачи, которые встречаются часто? А кто будет решать задачи, которые встречаются редко?

                                                  А что касается зацикленных списков — не знаю что такое «бесконечный зацикленный список», но структуру сводяющуюся примерно к описанным «спискам с циклами» я разбирал примерно месяц назад. Там, правда, списков могло быть много, цикл мог быть не один и они ещё и переплетены могли быть… но это — уже детали же, согласитесь?
                                                  • +2
                                                    Я собираюсь решать неэзотерические задачи. Эзотерические задачи я собираюсь решать за обедом с коллегами в качестве полезной разминки для мозгов, но я ведь нанимаюсь не команду в обед развлекать, поэтому логичнее спрашивать меня что-то более релевантное, не правда ли?

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

                                                      Вы проведите пару сотен интервью для начала, а потом начинайте рассуждать о том, что может случиться и когда. «Чего-нибудь на Хаскеле» выдаёт, дай бог, один кандидат из сотни (после чего его на работу, как мы знаем не берут — что и правильно, так как подобные ответы обозначают, что работа его интересует меньше, чем желание выпендрится), а написать хоть что-то вообще может, дай бог, один кандидат из трёх (если не один кандидат из десяти).

                                                      И это, наверное, даже хорошо, потому что такой человек таки с большей вероятностью осилит пустить два итератора по списку, или чего там в питоне с этим делать.
                                                      Ну вот если он это на интервью сделает — молодец, получит ещё пару вопросов, а затем и предложение о работе. Если нет… ну это его выбор, в конце-то концов.
                                                      • +1
                                                        У меня таки какой-то опыт есть. Видимо, мне везло с кандидатами :(
                                                      • 0
                                                        Эзотерические задачи я собираюсь решать за обедом с коллегами в качестве полезной разминки для мозгов, но я ведь нанимаюсь не команду в обед развлекать, поэтому логичнее спрашивать меня что-то более релевантное, не правда ли?
                                                        Да, в общем, почти всё равно что спрашивать — важно увидеть как кандидат год писать будет.

                                                        Почему вдруг типичная задача из типичного курса по структурам данным вдруг стала «эзотерической» — мне, в общем, неведомо, но если кандидат код не напишет, то резулюция «No Hire» следует, в общем, независимо от того не умеет кандидат это делать или не хочет: вы ведь нанимаетесь чтобы «решать задачи», как вы сами написали, а не «объяснять почему конкретно вы конкретную задачу решать не будете».

                                                        Специалистов по последнему, как показывает практика, гораздо больше — но они мало кому нужны.
                                                        • 0
                                                          Ну не типичная же она!

                                                          Это скорее какая-то игра в угадайку, что именно имел в виду интервьювер.
                                                          • 0
                                                            Вы имеете в виду использование нестандартных терминов и прочее? Вот как ни странно это проблемой редко когда является.

                                                            Несколько дополнительных вопросов, пара картинок — и, если кандидат хоть какой-то опыт имеет, формулировка в стиле Wesha — готова.

                                                            А вот написание кода для большинства кандидатов — проблема. Ещё какая. Примерно как в широко известно опусе.

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

                                                    Поэтому edrand48 — это вполне себе односвязный список, а вот drand48 — уже нет (можно долго и упорно спорить является ли пара drand48/seed48 списком, впрочем...).
                                                    • +1
                                                      В односвязном списке должна быть возможность во-первых как-то запомнить элемент, во-вторых их как-то сравнить

                                                      И тут я снова врываюсь со своим хаскелем…

                                                      Одного взгляда на сигнатуру repeat
                                                      Prelude> :t repeat
                                                      repeat :: a -> [a]
                                                      

                                                      достаточно, чтобы понять, что эта штука возвращает либо пустой список, либо бесконечное повторение переданного элемента, потому что больше никакой информации о типе нет вообще. Даже не факт, что элементы в получаемом списке сравнивать можно. «Запоминать» в контексте хаскеля ещё меньше смысла имеет (если вы имеете ввиду ссылку/указатель).

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

                                                      Либо я вас не так понял.

                                                      К слову, вот если бы у вас было больше информации о типах, например,
                                                      Prelude> :t enumFrom
                                                      enumFrom :: Enum a => a -> [a]
                                                      

                                                      то уже всё куда интереснее:
                                                      Prelude> take 10 $ enumFrom 0
                                                      [0,1,2,3,4,5,6,7,8,9]
                                                      Prelude> take 10 $ enumFrom 'a'
                                                      "abcdefghij"
                                                      
                                                      • 0
                                                        «Запоминать» в контексте хаскеля ещё меньше смысла имеет (если вы имеете ввиду ссылку/указатель).
                                                        «Запоминать» в конексте Хаскеля можно, конечно. Позицию в erand48 запомнить можно, а в «списке» /dev/rand (который, напоминаю, получает энтропию от аппаратных источников) — нельзя. И это фундаментальная разница с которой никакой, самый модный, язык ничего поделать не сможет.

                                                        Одного взгляда на сигнатуру repeat
                                                        Не очень понятно как программа может бросить этот «один взгляд» получив объект. Хотя, может, через интроспекцию в каких-то реализациях?

                                                        В любом случае: либо вы можете предложить как это программно понять и тогда у списка естественным образом появится длина, либо не сможете — и тогда это не список.
                                      • +3

                                        @khim, Wesha, 0xd34df00d


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


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


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


                                        В функциональном программировании, списком называется вполне конкретная структура данных, основанная на идее разбиения последовательности на голову и хвост. Эта структура данных чем-то напоминает обычный односвязный список — но все же отличается. К примеру, обычное и деструктивное получение первого элемента в односвязном списке — это две совершенно разные операции, но для списка в ФП это одно и то же.


                                        Вот эти списки и правда бывают бесконечными — но и длина бесконечного списка также бесконечна. Точнее, она не определена — поскольку невозможно алгоритмически определить, является ли указанный список бесконечным (проблема останова).


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


                                        Ну и в таких языках программирования как C# и Java, списком (List) называется упорядоченная коллекция, допускающая доступ по целочисленному индексу, причем в Java список — это только интерфейс, а в C# список — это и интерфейс, и его же реализация над массивом (IList<>/List<>).




                                        Массив же — всегда был набором элементов одного типа, последовательно расположенных в адресном пространстве. Разумеется, в тех языках, в которых нет понятия адреса, требование непрерывного расположения элементов становится неактуальным, что приближает массив к списку.


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




                                        Файл /dev/random, конечно же, не является ни массивом ни списком. Оба этих понятия подразумевают как минимум воспроизводимость результатов.


                                        Наверное, про /dev/random можно сказать "последовательность" — но это понятие также зависит от контекста.


                                        К примеру, многие алгоритмы нахождения наибольшей возрастающей подпоследовательности не смогут работать с /dev/random напрямую.

                                        • 0
                                          Вы сейчас спорите об определениях, причем выдумывая их на ходу.
                                          Вы действительно считаете, что спорящие тут этого не понимают? Да, разумеется, это спор об определениях. Для того он, в частности, и задаётся в такой формулировке — чтобы понять как кандидат будет на это реагировать.

                                          Есть несколько вариантов:
                                          • Кандидат офигивает от формулировки, но, подумав несколько минут, говорит: «вы имеете в виду циклический список и хотите, чтобы я две бегунка пустил?» — и пишет программу.
                                            Вывод: хороший кандидат, скорее всего берём, но, конечно, это зависит от того, как он отвечает на другие вопросы тоже.
                                          • Кандидат долго пытается понять, чего от него хотят, через час, с горем пополам, пишет нечто слегка похожее на программу, которая, впрочем, не работает (самый популярный результат).
                                            Вывод: отвратительный кандидат, не берём, говорить не о чем.
                                          • Кандидат уходит в спор об определениях, объясняет, что формулировка некорректа и вообще всячески показывает свою эрудированность. Кода в результате нет.
                                            Вывод. Отличный кандат… для наших конкрентов. Не брать.

                                          Всё просто: как я уже сказал: недоговорки и неточные определения — часть производственного процесса. Если кандидат «знает как с этим жить» и может, несмотря ни на что, выдать результат — то это «наш кандидат», с ним будет приятно работать и команда в 1000 человек не будет ждать его из-за того, что поля на техзадании оказались не по ГОСТу. Если кандидат либо не может, либо не хочет в таких условиях работать — нам он не подходит, будь он хоть трижды гений.

                                          Вот и всё.

                                          Это — разумеется, требования которые я применяю к кандидату. Вполне могу предствить себе компанию, где всё по другому и где люди, требующие чётких формурировок, но при этом не отличающие списка от массива будут востребованы. Но это — не у нас.

                                          Если кто-нибудь знает языки программирования где массивом считается что-то иное, пожалуйста расскажите о них.
                                          PHP. Как уже было написано: Этот тип данных ведёт себя как список, упорядоченный хэш, упорядоченный набор, разреженный список и время от времени как их странные комбинации. Какая его эффективность? Каков будет расход памяти?(пер. анализ расхода памяти для массивов) Кто знает? У меня всё равно нет других вариантов.

                                          Ну уже даже JavaScript имеет отдельно массивы и объекты — и массивы ведут себя как массивы, а объекты — как объекты (хотя и используют при это одинаковый синтаксис). Одна есть огромное количество разработчиков, которые понятия не имеют в чём отличие этих структур данных и когда использовать одно, а когда другое. Их вопросы сложности и расхода памяти не заботят вовсе — и, опять-таки: возможно, что существуют компании, которым такие люди подходят.
                                          • +2
                                            Вы действительно считаете, что спорящие тут этого не понимают? Да, разумеется, это спор об определениях. Для того он, в частности, и задаётся в такой формулировке — чтобы понять как кандидат будет на это реагировать.

                                            Но в таком случае зачем вы тут спорите об определениях? Это ж не собеседование :)


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


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


                                            Я ожидаю слишком многого?

                                            • 0
                                              Я ожидаю слишком многого?
                                              Ну как вам сказать, чтобы не обидеть…

                                              Senior Software Engineer; Software Archaeologist:
                                              В наше время массив — это «структура данных, предоставляющая доступ к своим элементам по целочисленному индексу». Всё. Как оно хранится, как оно работает — это всё детали реализации. Это может быть обычный сишный массив — *(base + sizeof(element) * index), это может быть memory mapped file, это может быть sparse array, это может быть всё, что угодно; если возможен доступ arr[i] для любого i — то для целей дискуссии за пивом, каковую мы с Вами тут имеем, это «массив».
                                              Такие дела.

                                              А вы говорите «корректное использование профессиональных терминов»…
                                              • 0

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

                                                • 0

                                                  Я начинал ещё с (прости господи!) фортрана, потом был C, а последние 10 лет работаю на Ruby — который со всякими PHP и питонами начисто заабстрагировал железо чёрт-те куда. (Особенно с учётом того, что даже "железо", на котором мы работаем, на самом деле облачно-виртуальное.)

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

                                                Вот и я тредстартеру пытаюсь объяснить это уже пятый раз: задача software developer — взять условие задачи и реализовать код, её рещающий. Причём если в условии полная хня — то и код будет такой же, либо не будет вообще: garbage in — garbage out. А "понять, что же там заказчик мямлит и корректно поставить задачу девелоперу" — это работа software consultant совсем за другие деньги.


                                                "Поэтому я вам советую подождать специалиста, договориться с нянечкой и заплатить. Но можно этого и не делать. Если вас не интересует результат." ©


                                                А тредстартер хочёт "два в одном флаконе" за ту же цену.

                                              • 0
                                                Всё просто: как я уже сказал: недоговорки и неточные определения — часть производственного процесса.

                                                Всё с Вами понятно: хочется иметь software consultant, а платить ему как software engineer. Плавали, знаем.

                                              • 0

                                                "Пятница. Пришёл лесник и выгнал из лесу всех — и нас, и белых." ©


                                                Массив же — всегда был набором элементов одного типа, последовательно расположенных в адресном пространстве. Разумеется, в тех языках, в которых нет понятия адреса, требование непрерывного расположения элементов становится неактуальным

                                                Вот и я про то же: в наше время массив — набор однотипных элементов, доступных по индексу (требование доступности по физическому адресу из-за отсутствия таковой размывания понятия всякими виртуализациями заменяется требованием доступности по индексу — "виртуальному адресу")

                                                • 0

                                                  Не совсем так. Если язык умеет работать с указателями и допускает арифметические операции над ними — то такие операции имеют смысл только в пределах некоторых непрерывных (в адресном пространстве процесса) блоков памяти. Такие блоки в этих языках и называют массивами.


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

                                                  • 0
                                                    непрерывных (в адресном пространстве процесса)

                                                    Ключевая фраза! В реальной физической памяти оно может располагаться как угодно, хоть на винчестере.


                                                    Как я уже написал выше, я последние 10 лет работаю на Ruby, в котором, в самом деле, "понятие массива "свободно" и может использоваться для любой структуры с индексатором." (Arrays are ordered, integer-indexed collections of any object. ) Поэтому я и произнёс по привычке фразу, с которой и проистёк весь этот спор.

                                      • +14

                                        С позиции опытного разработчика:
                                        Гуглить что?
                                        Чаще всего я гуглю тексты ошибок и куски стектрейсов
                                        Затем — тёмные или подзабытые места фреймворков типа "hibernate declare composite key". Если мне нужно начать использовать новый фреймворк, я предпочту потратить день и прочитать официальную документацию.
                                        И никогда — чужой код. Чужой код при решении проблем нужен только для того, чтобы изучить те API, которыми он пользуется для решения проблемы.
                                        Исключение — это реализация достаточно сложных алгоритмов типа BCrypt, но и там не стоит брать первый попавшийся кусок.


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

                                        • +2
                                          А по документации вы как ищите?
                                          К примеру, я сейчас по работе часто обращаюсь к документации по Unreal Engine. В 99% случаев это вбитый в гугле запрос, который ведет на страницу документации. Оставшийся процент — перекрестные ссылки.
                                          • 0

                                            Наверное, речь идет о С++ и документации к API? Я пишу на Java и там нет такой проблемы — документация к методу находится в исходниках непосредственно над методом и практически ко всем библиотекам есть исходники, которые автоматически подцепляются к проекту. Если же речь идет о крупном закрытом API — то я предпочитаю документацию, оформленную одним документом в html или pdf и ищу по ctrl+f. Если такой возможности нет — то да, только гугль. Почти всегда он ищет лучше, чем специализированные "поиски по онлайн документации".

                                            • 0
                                              Я пишу на Java и там нет такой проблемы — документация к методу находится в исходниках непосредственно над методом
                                              Так и в C++ бывает, но непонятно как это поможет писать код. Читать — да, но писать…

                                              Как вы без поиска понимаете как должен называться метод, который «делает X»? Одно и то же действие можно называть сотней разных способой (если это не какая-нибудь базовая бибоитека, оперирующая уже давным-давно устоявшейся терминологией).
                                        • +5
                                          Раньше читали тот же MSDN, теперь гуглят, потому что к формальному описанию добавляется практический опыт.
                                          Лучше прочитать про чужие грабли, чем наступить на свои.

                                          Так что не вижу ничего плохого (тем более, что решение проблемы, по которой не удалось нагуглить решение, поднимает ЧСВ ещё примерно на over 9000)
                                          • +1
                                            Я уже забыл, когда последний раз читал книгу по программированию. Гугль все заменяет. Правда последние несколько лет он слишком умничает, и основываясь на своих каких-то своих предположениях корректирует выдачу к моим запросам. Например выдает, ссылки, где нет требуемого мне ключевого слова. Поэтому если появится поисковик, который будет работать как гугль 10 лет назад, я сразу на него переключусь.
                                            • +6
                                              • 0
                                                Возможно когда-нибудь дорастет. Пока их индекс во много раз меньше гугловского, и обновляется не так быстро.
                                                • +3
                                                  Возможно уже дорос? Я щупал ddg года 2 назад, тогда были проблемы с поиском на русском языке, да и на английском поисковая выдача была не очень. Однако с тех пор многое изменилось. Уже полгода как перешел на ddg, все устраивает.

                                                  обновляется не так быстро

                                                  Рандомный вопрос со stackoverflow, опубликованный час назад, уже проиндексировался.
                                                  тыц тыц.
                                                  • +1
                                                    Ок, проверяю статью с хабра Strelki.js — еще одна библиотека для работы с массивами, опубликованную сегодня:
                                                    Ищу по названию StrelkiJS — ничего (хотя слово в статье есть)
                                                    Ищу по названию Strelki.js — показывает кучу ссылок
                                                    Видимо кое-что уже занеслось в индекс, но не все. Ну а Гугль, как обычно, сразу все загрузил.
                                                    • 0
                                                      Хм, у меня все находит. https://duckduckgo.com/?q=Strelki.js&ia=web

                                                      Скриншот


                                                      UPD. Завтыкал, по StrelkiJS действительно ничего не находит.
                                                      • +1
                                                        И почему-то первая ссылка на украинском… Странно, ведь оригинал на русском…
                                                    • 0
                                                      На русском они сейчас, ЕМНИП, просто редиректят запрос Яндексу, так что качество выдачи по соответствующим запросам должно быть более-менее достойным.

                                                      Кого не устраивает выдача DDG, может использовать startpage.com — этакий прокси-поисковик, анонимно передающий запросы в Google. Поисковой линзы нет, много раз проверял, Столлман одобряет (https://stallman.org/stallman-computing.html, ищем «ixquick», это то же самое).
                                                      • 0
                                                        Поддержу, сам использовал startpage до того, как перешел на ddg.
                                                • +2
                                                  • +1
                                                    Да, я этими возможностями постоянно пользуюсь. Но гугль все равно корректирует.
                                                    • +4

                                                      К сожалению, они выкинули оператор "+" — обязательное включение в запрос, в любой форме, не синоним. Какое-то время эту задачу кое-как выполняли кавычки (без стемминга, очевидно), но сейчас даже слова в кавычках игнорирует, правда пока хотя бы указывает, что выкинул. Скоро и это уберут наверняка.

                                                      • +2
                                                        Угу, и вообще временами он и сейчас выкидывает почти всё, что без кавычек, а про кавычки говорит «не нашёл, вот тебе про другое». Так скоро вообще можно будет поле ввода убирать из гугла, оставить только кнопку «найти». =)
                                                        • +8
                                                          А еще выкинули оператор "-". Кстати, плюс не выкинули — он ищет страницы в Google+. За это кстати отдельно следовало бы кое-кому вломить.
                                                          • 0

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

                                                            • +1
                                                              "-" прекрасно работает убирает лишние слова из выдачи так, как всегда делал
                                                              • +2
                                                                Я тоже так делал. Но по субъективным впечатлениям стало искать хуже. Намного хуже.
                                                              • 0
                                                                Давно «минус» выкинули?
                                                                • 0
                                                                  Оператор дефис не выкинули. support.google.com/websearch/answer/2466433?hl=ru
                                                                  • 0

                                                                    Он просто не работает в некоторых случаях (может просто является недостаточной пессимизацией).

                                                          • +2
                                                            Гугл для мелких или сугубо прикладных задач.
                                                            Книга для research'а. Ну или научная статья. Которую нагуглил.
                                                            • +3
                                                              Читать книги/статьи хорошо, когда нужно научиться чему-то большому, а именно: изучить новую технологию/методологию/язык.

                                                              Для решения насущных проблем книга не подходит. Невозможно держать в голове все, что ты когда либо прочитал. Да что там прочитал — собственноручно написанный код начисто забывается через год. Я несколько раз слышал о случаях, когда человек гуглил свою проблему и находил свой же ответ на каком-то сайте, оставленный несколько лет назад.
                                                              • 0
                                                                Иронично, что при работе в Google обычно гуглить особо смысла нет. Ну и в целом, если бОльшая часть работы не связана с какими-то стандартными фрэймворками, то объем релевантной информации в интернете весьма ограничен.
                                                                • +2

                                                                  Работа почти любого программиста связана с какой-то стандартной платформой. Уж точно 99% программистов в том же гугле. Если вы не используете фреймворк — вы все равно используете язык программирования и стандартную библиотеку, x86/arm, сетевые протоколы, и т. д.

                                                                  • 0
                                                                    К счастью, базовых знаний языка и стандартной библиотеки достаточно в 99 процентах случаев, ну а всякие низкоуровневые штуки мало кому нужны. Обычно проблемы возникают именно в специфичных местах, которых в интернете нет и быть не может.
                                                                    • +3

                                                                      Ну я по 100 раз на дню гуглю вещи которые 100 раз уже видел, например, методы классов String и Map (для Java — базовее не придумаешь). Всякие сниппеты, например, как сконвертировать строку из одной кодировки в другую, как прочитать содержимое из архива, и т. д. Если нет интернета (например в самолете) — конечно могу написать такие вещи сам, основываясь на API стандартной библиотеки, которое доступно в оффлайне (и по которому есть навигация в IDE). Но если есть гугл — никогда так не делаю, потому что 1) нагуглить быстрее 2) меньше вероятность что упустишь какой-то момент и сделаешь ошибку в мини-велосипеде. Сниппеты со StackOverflow обычно отполированы опытом.

                                                                      • 0

                                                                        100 раз это не преувеличение — вообще в определенные периоды я в среднем делал по 100-150 поисков в день, хотя не использовал никакие фреймворки. Сейчас в среднем 30-50 поисков в день.

                                                                  • +2
                                                                    Кстати DDG ищет техническую информацию гораздо лучше чем гугл. Плюс офромление поисковый выдачи, это нечто — иногда даже по ссылкам ходить не нужно!
                                                                    • +4
                                                                      В отсутствии системных знаний, никакой Google не поможет качественно решить задачу. Равно как и наоборот обладая системными знаниями, можно не решить задачу не расширив кругозор возможными вариантами решения. Как-то так. Но без системных знаний все же никуда. А без гугла еще в теории можно…
                                                                      • +1

                                                                        Без системных знаний на одном гугле — запросто.


                                                                        https://gkoberger.github.io/stacksort/

                                                                        • 0
                                                                          Что бы что-то искать надо знать что искать, а что бы знать что искать нужно обладать системными знаниями.
                                                                      • +5
                                                                        Пользование поиском программиста — это то же самое, что умение пользоваться справочником у любого инженера. Опытный программист часто знает что он ищет, поэтому способен отсеивать лишнее. Начинающий программист ищет хотя бы какое-то решение, поэтому часто берет первое попавшееся.
                                                                        • +4
                                                                          Гуглить стыдно, а ходить в в библиотеку за консультациями в профессиональной литературе и периодике — почётно и является признаком профессионала высокого уровня.

                                                                          Так?
                                                                          • +15
                                                                            Старый анекдот:

                                                                            Физику, математику и инженеру дали задание найти объём красного мячика.
                                                                            Физик погрузил мяч в стакан с водой и измерилл объём вытесненной жидкости.
                                                                            Математик измерил диаметр мяча и рассчитал тройной интеграл.
                                                                            Инженер достал из стола свою «Таблицу объёмов красных резиновых мячиков» и нашёл нужное значение.

                                                                            Вот так и у программистов. Хороший программист всегда сначала попытается нагуглить объём красного резинового мячика, вместо долгого и тернистого пути по поиску объёма самостоятельно. Зачастую нет смысла рыться в документации если тебе нужен чёткий ответ всего на один вопрос — проще нагуглить этот ответ, и работать дальше.
                                                                            • +6

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

                                                                              • +1
                                                                                Напомнило:
                                                                                Идеальный мужчина не пьёт, не курит, не играет на скачках, никогда не спорит и не существует.
                                                                              • +1
                                                                                Вопрос без сарказма: как математик измерил диаметр?
                                                                                Для металлического мячика — зафиксировал параллельно 2 плоскости, загнал между ними мячик, сближаешь поверхности пока мячик позволяет.
                                                                                Но резиновый мячик будет сплющиваться во что-то эллипсоидное.
                                                                                Подвесить мяч на резинке к потолку, под него источник света, и замерять освещенную площадь? Так проще в стакан с водой кинуть…
                                                                                • +1
                                                                                  Математик просто тыкнул в формулу и сказал «решение существует, что вы ко мне со всякими глупостями пристаете».
                                                                                  • +2
                                                                                    1. если на мяче есть центральный шов или нарисовано кольцо — погрузить мяч в сыпучее вещество (песок, мука, крупа) до середины, затем посчитать диаметр отверстия
                                                                                    2. померить диаметр тени от солнца или другого источника прямых лучей, если тень эллиптическая — в самой узкой части тени
                                                                                    3. посыпать мячик сверху псевдослучайным потоком мелких дробинок, потом посчитать сколько из них не отскочили, а упали на поверхность (например, плотный клей), посчитать площадь методом Монте-Карло, вычислить диаметр
                                                                                  • 0
                                                                                    Позаимствовал штангенциркуль у инженера.
                                                                                  • 0
                                                                                    Почему интеграл — тройной?
                                                                                    • +1

                                                                                      Интегрирование по dx dy dz или, например, dr dtheta dphi даст тройной. Если же по dV то одинарный, хоть и по объёму.

                                                                                  • +6
                                                                                    CPP = Copy Paste Programming :-)
                                                                                    • +5

                                                                                      Тогда Go и вовсе Google-oriented

                                                                                      • 0

                                                                                        TDD == toster driven development

                                                                                        • +1

                                                                                          Full-StackOverflow developer

                                                                                          • +1

                                                                                            Вдруг кто еще не видел


                                                                                            картинка

                                                                                            image

                                                                                    • –1
                                                                                      Опытный программист — это программист с приличным опытом гугления.
                                                                                      • +1
                                                                                        Программисту нормально гуглить, а вот какому-нибудь выездному инженеру не стоит рассчитывать, что на объекте будет интернет и можно будет скачать софт, доки, прошивки…
                                                                                        • 0
                                                                                          Тут надо делать скидку на то, что у них примерно известна область случая.
                                                                                          Если я иду по поводу рассыпавшегося рейда, то мне вряд ли придётся гуглить информацию о том, как разные его варианты устроены. Иначе я бы не шёл.
                                                                                          Так и с инженером. Может — решает. Не может — по таким кейсам, думаю, процедура у них описана.
                                                                                        • +2
                                                                                          Некоторая подмена понятий в комментариях.

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

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

                                                                                          Нужно и читать и гуглить, смотреть и слушать, все способы хороши, в любом случае вы получаете одно и тоже — информацию.
                                                                                          • 0
                                                                                            Джинса для Гугл =)
                                                                                            • +1
                                                                                              GDP == «Google Driven Programming».
                                                                                              • +2
                                                                                                Напомнило:

                                                                                                Решили провести тест на интеллектуальное развитие студентов, подошли поочередно к студентам 1-го, 2-го, 3-го, 4-го и 5-го курсов и спросили: «Сколько будет дважды два?»

                                                                                                1-й курс (быстро): «4!»

                                                                                                2-й курс (быстро посмотрев в шпору): «4!»

                                                                                                3-й курс (достав калькулятор, быстро): «4!»

                                                                                                4-й курс (торопясь, полистав справочник): «4!»

                                                                                                5-й курс (с возмущением!): «Что я, все константы должен помнить?»
                                                                                                • +2
                                                                                                  Ну что вы. дважды два — это точно не «4!». Это «4».
                                                                                                  • 0
                                                                                                    1. Мотороллер не мой, шутка с копи… жжена просторов интернета.
                                                                                                    2. В данном случае "!" — не знак факториала, а индикатор эмоциональности ответа, из досмайликовой эры. ;)
                                                                                                  • 0
                                                                                                    Но 2х2 != 24 :)
                                                                                                    • 0

                                                                                                      Простите, у Вас туннельное зрение? Я уже осветил этот вопрос.

                                                                                                      • +1
                                                                                                        Вежливый вы человек, сразу видно :) Поскольку я неполноценный участник, мои комментарии проходят премодерацию автором статьи. В этот раз он был, вероятно, занят и утвердил написанное мною только через пять дней. За этот срок, другой комментатор успел пошутить схожим образом, а вы осветить.
                                                                                                        • 0

                                                                                                          Да, я этого момента не учёл. Прошу прощения!

                                                                                                  • 0
                                                                                                    Мы выяснили: гуглят все. Разница в том, как.

                                                                                                    Касается, в общем-то, не только программистов.
                                                                                                    Здравствуйте, я админ. И я гуглю.
                                                                                                    Вот только гуглить как я в моём окружении может 2 или 3 человека. Остальные десятки будут искать то же самое решение долго и мучительно.
                                                                                                    Это хороший универсальный навык. Потому что занимаясь своим хобби (а это уже как раз программирование) я ищу на примерно том же уровне, что и в области моей профессиональной деятельности.
                                                                                                    Моё личное мнение — если ты не гуглишь, то, скорее всего, ты останавливаешься в развитии. Или уступаешь другим, если не умеешь искать.
                                                                                                    • 0
                                                                                                      Я никогда не задавался таким вопросом, корректно ли гуглить. Я сейчас держу в уме контуры: что где использовать, какие функции, а подробности уже гуглю, например параметры функций, я не буду это всё учить наизусть. Ну и авто-дополнение тоже помогает. И как уже писали выше — ошибки, трейсы и тд — гугль знает все ответы.

                                                                                                      Единственное, о чем я беспокоюсь — рано или позддно гугль возьмёт нас в «оборот» и заставит заплатить за все прошлые и будущие ответы.
                                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                        • 0
                                                                                                          Я обычно пользуюсь поиском яндекса, но вопросы по программированию задаю сразу в гугле, долгое время сравнивал, у кого лучше (тупо задавая вопрос в яндексе и нажимая найти это же в гугле — внизу есть такая сслыка «поискать в других поисковых системах»). Бывало, что оба поисковика понимали, что нужно мой вопрос немного перефразировать — и почему-то на мой взгляд гугл с этим лучше справляется.
                                                                                                          Не могу судить, дело в объёме проиндексированной сети, в том, что для гугл нативный язык — английский или у меня самого корявость английского лучше подходит под гугл, чем под яндекс.
                                                                                                        • +1
                                                                                                          Раньше гугл не был так хорош, да и в интернете не было SO и подобных сайтов. Поиск решения приводил к длинным мануалам, сложным книжкам. Их чтение помимо решения проблемы приносило множество дополнительных знаний. В последние годы возникла проблема: вбил в гугл, получил решение, реализовал, двинулся дальше. В голове в лучшем случае конкретно решение этой проблемы останется, а порой даже и это забывается, через год опять то же самое гуглишь. Для себя считаю это проблемой, поэтому стал пользоваться гуглом, как самым последним средством. Сначала пересматриваю книги, руководства, изучаю исходный код, пытаюсь экспериментируя сам найти решение, даже если этот путь отнимает время. И только в самом крайнем случае иду на SO и если там ничего не нашлось — в гугл. Кстати помимо прочего зависимость от гугла мне тоже не нравится и хотя он вряд ли куда-нибудь исчезнет, всё равно стараюсь сначала использовать другие варианты вроде поиска по SO, DDG и тд.
                                                                                                          • 0
                                                                                                            Решая задачу, лезу сразу в гугл (как правило попадая на stackoverflow) в случаях:
                                                                                                            1) я уже знаю ответ на вопрос, просто не помню точной формулировки (например, название параметра/класса/метода)
                                                                                                            2) я вообще не знаю, в какую сторону искать, но есть за что зацепиться (например, сообщение об ошибке в слабо знакомой технологии)
                                                                                                            3) необходимая срочность решения
                                                                                                            В остальных случаях хотя бы полчаса-час решаю задачу самостоятельно (анализ сорцов либы, эксперименты, спеки). Даже получив ответ, иногда все же захожу в гугл — посмотреть чужой опыт и найти нехватающие нюансы. Полученный таким способом ответ намного лучше оседает в памяти, да и ачивка за решение — всегда приятно.
                                                                                                            • +1
                                                                                                              Если человек не гуглит, а использует только старый опыт, как он может давать современные актуальные решения?
                                                                                                              • +1
                                                                                                                Главное отличие профессионала от халтурщика — понимает ли человек то решение, которое берет, пропустил ли его через свой мезушный узел.

                                                                                                                Если программист копипастит код без понимания как он работает — это халтурщик и гнать его в шею.

                                                                                                                Это в принципе любых профессий касается.
                                                                                                                • 0
                                                                                                                  Важная проблема GOP в том, что оно не совместимо с радикальным методом борьбы с прокрастинацией — уходом в оффлайн. Конечно, во многих сферах программные решения уже и без того завязаны на постоянном интернет-подключении, да и в оффлайне можно прокрастинировать ещё как…
                                                                                                                  • 0
                                                                                                                    Мы ещё используем Stackoverflow Design Pattern
                                                                                                                    • 0
                                                                                                                      По тому какие человек делает запросы и сколько запросов ему понадобится для ответа, видно, насколько он владеет предметной областью.
                                                                                                                      Владение профессиональными терминами и правильное их употребление в контексте, с моей т.з. достаточный тест на профпригодность. Человек не знакомый с типографией будет говорить «расстояние между строк» а знакомый — «интерлиньяж», и найдет более качественную информацию. Кроме того сразу видно как человек владеет языком. Сравните: «как сделать интервал между строк другим» и «как изменить межстрочный пробел».
                                                                                                                      Гуглить почему-то считается моветоном, хотя он экономит время а значит и деньги. Думаю Гуглу надо просто открыть новый сервис: Google Pro — все то же самое, но с обязательной регистрацией, за деньги, и без рекламы. (Для тех кому для имиджа нужно пользоваться только самыми профессиональными инструментами :)
                                                                                                                      • 0
                                                                                                                        Не виду ничего плохого в использовании поисковика для решения задачи.
                                                                                                                        Одна конечная цель и не столь важно каким способом ее достигать, а если я могу тратить меньше времени на поиск решения, а выполнять больший объем работы, то нет смысла противиться прогрессу.
                                                                                                                        Еще один немаловажный факт заключается в самооценке, многие себя переоценивают или напротив, недооценивают, но даже отличный программист может оказаться профаном в чуждой ему области или плохой программист может дать отличные советы по частному вопросу.
                                                                                                                        В самом начале своего пути приходилось изобретать сортировки, какие то списки, а сейчас нет нужды тратить часы жизни на придумывание давно созданного и отлаженного.
                                                                                                                        • 0