Означает ли чрезмерная зависимость от инструментов, что вы ленивы? [закрыто]

29

Я начал программировать на C ++ в универе и мне это нравилось. В следующем семестре мы перешли на VB6, и я его ненавидел.

Я не мог сказать, что происходит, вы перетаскиваете кнопку в форму, и ide пишет код для вас.

Хотя я ненавидел функционирование VB, я не могу утверждать, что это было быстрее и проще, чем делать то же самое в C ++, поэтому я понимаю, почему это популярный язык.

Теперь я не призываю разработчиков VB просто сказать, что это проще, чем C ++, и я заметил, что многие новые языки следуют этой тенденции, такой как C #.

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

Это просто недооцененное мнение младшего программиста или программисты становятся более ленивыми и менее компетентными в целом?

РЕДАКТИРОВАТЬ: Многие ответы говорят, зачем изобретать колесо, и я согласен с этим, но когда колеса доступны, люди не удосуживаются узнать, как сделать колесо. Я могу гуглить, как делать практически все на любом языке, и половина языков делает так много для вас, когда дело доходит до отладки, они понятия не имеют, что делает код о том, как исправить ошибку.

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

скейт
источник
7
«Это просто недооцененное мнение младшего программиста или программисты становятся ленивее и менее компетентны в целом?» - это ни то, ни другое, но оба они верны (только не по тем причинам, которые вы говорите).
Джон Хопкинс
15
Как кто-нибудь может ответить на это, не опровергнув название?
Комментаторы: комментарии предназначены для уточнения, а не для расширенного обсуждения. Если у вас есть решение, оставьте ответ. Если ваше решение уже опубликовано, пожалуйста, подпишите его. Если вы хотите обсудить этот вопрос с другими, используйте чат . Смотрите FAQ для получения дополнительной информации.
8
Почему это не было закрыто , как «субъективное и аргументированный» ...?
BlueRaja - Дэнни Пфлюгофт

Ответы:

103

Нет, разработчики не стали более ленивыми или менее компетентными. Да, потребность в реальном развитии постоянно снижается в том смысле, что вы это знаете. И да, это очень потому, что предприятия хотят быстрых результатов, а почему бы и нет?

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

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

Аналогичным образом слой данных, который обычно представляет собой не что иное, как «Вставить это», «Удалить это», «Заменить это» и большое количество разных представлений одних и тех же данных. Зачем продолжать писать это снова и снова? Давайте изобретать ОРМ.

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

Но эта уникальность всегда будет - там, где ее нет, есть деловые возможности - и людям всегда будет нужно писать код.

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

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

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

прецизионный самописец
источник
3
Существует разница между разработчиком и программистом.
Райнос
9
+1. В точку. Вы платите за работающее программное обеспечение. Код - это средство для создания программного обеспечения, артефакт. Чистое «программирование» - это простая и забавная часть создания программного обеспечения.
Joonas Pulakka
+1 за все. Я не уверен, что «единственное, что вы должны разрабатывать, - это код, который уникален для бизнеса, для которого вы разрабатываете». Но я признаю, что это верная бизнес-стратегия.
SoylentGray
@Chad - Возьми свою точку зрения. Я иногда говорю в гиперболе. Здравый смысл всегда превалирует над философией, когда дело доходит до кризиса, но я думаю, что это хорошая позиция, которую следует обсуждать от случая к случаю, вместо того, чтобы занимать позицию по умолчанию «да, давайте напишем это сами». :)
фунтовые
Для бизнеса самый большой вопрос: какова отдача от инвестиций, затраченных на разработку решения? Моего босса не волнует, на каком языке я развиваюсь, пока я могу помочь компании заработать больше денег, чем они мне платят. Что-нибудь еще, и они теряют деньги на меня.
Дэн Уильямс
38

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

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

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

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

Это очень похоже на программирование. C ++ - хороший язык и имеет свое назначение (в основном производительность). Что мне нравится в таких языках, как C #, так это то, что я могу сосредоточиться на проблеме, думать об алгоритме безо всякого шума, который делает C ++, например, неоднозначные предупреждения компилятора, неопределенное поведение и так далее. Разработка становится все более и более сложной, чем в старые времена мэйнфреймов и первых компьютеров, но человеческий мозг остается тем же самым - в значительной степени тупым. Одно приложение может работать в облаке, на мобильном устройстве, на настольном компьютере, есть много зависимостей, проблем безопасности и других проблем. Я хочу иметь лучший инструмент, чтобы сосредоточиться на более сложных проблемах и решать их.

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

лукас
источник
1
Я не думаю, что аналогия работает, потому что и Брэд, и Пит по-прежнему будут знать, как снять шину, и все, что с этим связано (гаечные ключи, ключи и пиво).
Кристофер Хох
3
+1 Отличный ответ. Я бы добавил, что независимо от того, какой инструмент вы используете, если вы понимаете, что он делает, вы будете делать свою работу правильно. С другой стороны, если вы этого не сделаете, неважно, сколько работы выполняет инструмент, в какой-то момент вы собираетесь что-то испортить.
Яцек Прусия
1
@Kristofer: Может быть, было бы лучше, если бы Пит знал немного электроники. В то время как Брэд знает, как использовать диагностический компьютер и считывать, что датчик O2 вышел из строя, Пит видит, что провод датчика немного перегорел, достает счетчик для его измерения и понимает, что регулятор напряжения вышел из строя и выгорание датчиков О2.
Zan Lynx
@ Зан, это не одно и то же. @Kristofer только потому, что я использую конструктор для быстрого перетаскивания элементов управления на элемент формы и создания стандартного кода, не означает, что я не знаю, как затем изменить этот код, чтобы потом делать то, что я хочу.
Jcolebrand
Прекрасный способ выразить это.
riwalk
37

Итак, что мы называем программированием сейчас

Ты говоришь:

Будущие программисты скажут компьютеру, чего они хотят, и компилятор напишет программу для них, как в Star Trek.

просто проведите эксперимент: наблюдайте за «Звездным путем» и попытайтесь интерпретировать то, что компьютер приказал сделать «немного бесподобным».

  • Чай, Эрл Грей, горячий -> много пара.
  • Чай, Эрл Грей, 60 градусов по Цельсию -> лужа и облако пара
  • Эрл Грей, 60 градусов по Цельсию -> лужа
  • Эрл Грей, 60 градусов по Цельсию, в чашке -> чашка с каплей в ней
  • Эрл Грей, 60 градусов по Цельсию, 0,2 литра, в чашке. -> наконец (хорошо, вы можете придираться больше)

Когда вы вызываете Программирование: «Знание об использовании памяти, указателях и т. Д.», Да, я думаю, это станет менее важным (поскольку «Знание о http, openid, unicode» станет более важным).

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

оборота кеппла
источник
2
@Raynos: тааак правда. Особенно удручает, когда эти люди являются лидерами команд и делают руководящие указания, например, «когда отправляемые данные меньше X байтов, используйте GET, когда больше, используйте POST»
keppla
8
@keppla - Ваша проблема не в том, что руководитель вашей команды не понимает HTTP, а в том, что он не хотел менять свое мнение в свете свидетельств того, что он ошибался (если вы пытались что-то ему объяснить). Вы не можете знать больше, чем все, кто работает на вас, обо всем - настоящее преступление не в том, что кто-то другой знает о чем-то большем, чем вы.
Джон Хопкинс
3
«Чай, Эрл Грей, Хот» - это декларативное программирование. Работа компьютера состоит в том, чтобы найти контекстуально релевантный результат, основанный на разумных ожиданиях. Производство пара из «горячего чая» на языке такого типа было бы ошибкой для части команды разработчиков компьютера, а не для программиста. Следует использовать контекстуально релевантный случай, если не введен конкретный запрос.
Диадема
1
@Diadem: даже когда это декларативно, вам нужно знать, что объявлять, и как программист, imho, вы не ожидаете, что компьютер по прошлому будет угадывать, что вы будете делать дальше, потому что вы будете делать что-то новое. Интерфейс, который интерпретирует ваши пожелания, предназначен для конечных пользователей.
Кепла
2
@Zan Lynx: Может быть, лучший пример: заставить компьютер предупреждать вас каждый раз, когда кого-то похищают (кажется, что компьютер не заботится об этом в TNG). «Компьютер: сообщите мне, когда кого-то похитили». «Определите похищенного». «Когда его берут против его воли». «Определите волю» и т. Д. Придумайте решение, например «Сообщите ответственному сотруднику при изменении местоположения кого-либо». от неизвестного к неизвестному, и нет никаких данных о том, что транспортный офицер отправил его в сторону или он вошел в челнок, и судно не в доке ». тебе еще нужен программист Mindset.
Кепла
23

Программисты не становятся ленивее. Программисты всегда были ленивы. Быть ленивым является частью фундаментального характера работы. Проблема в том, что люди считают ленивость негативной. Быть «ленивым» программистом - добродетель.

Помните старую поговорку: «Работай умнее, а не усерднее». Это основной драйв программистов.

Парни, которые строили и программировали первые компьютеры, не делали этого, потому что им нравилось делать тяжелую работу, они делали это, чтобы ИЗБЕГАТЬ еще более тяжелой работы. (делать страницы расчетов вручную)

Быть ленивым - одна из фундаментальных причин, почему программисты программируют. Именно поэтому мы пишем новые и все более высокоуровневые языки, лучшие и лучшие отладчики и IDE, сценарии оболочки и сборки и т. Д.

Программист смотрит на проблему, все, что он или она делает и думает;

"Я могу автоматизировать это?" , "сколько времени это займет?" , «Сколько времени , что , кроме меня?»

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

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

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

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

Джастин ом
источник
19

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

Что касается компетенции, программирование является гораздо более популярной и равноправной работой, чем раньше. Так что да, есть много новичков, которым не хватает знаний. Я, однако, не имею в виду, что вдруг появляются менее компетентные программисты. На самом деле их больше. Вы просто смотрите на неправильную сторону кривой звонка.

Vartec
источник
11
Люди, которые водят автомобили, ленивы, в этом нет ничего смешного. Руководство с пяткой на носок дает намного больший контроль и производительность автомобиля, но требует большого умения и дополнительной работы.
Кодер
11
@Coder: «требует дополнительной работы» - на шоссе это не так, в пробках это делает, но в любом случае это не дает вам никаких преимуществ.
vartec
2
Механические коробки передач также обеспечивают лучшую экономию топлива на шоссе, хотя это не так с блокировочными гидротрансформаторами.
Дэйв Маркл,
4
@ Дэйв, на самом деле, современная электроника в среднем сделала автоматику более эффективной. Мой Ford Fusion с такими же опциями был оценен почти на целую милю за галлон меньше. Я уверен, что бывают моменты, когда руководство по микросхемам все же лучше, но по всем автоматическим технологиям лидирует.
SoylentGray
3
@ Кодер - Если вы думаете, что вождение в ручном режиме требует «большого навыка», вам нужно осмотреть тысячи некомпетентных водителей на дороге с механическими коробками передач. ;)
techie007
15

Я испытываю желание сказать: «Да, неосведомленные младшие программисты стали ленивыми и менее компетентными», но давайте попробуем серьезный ответ:

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

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

В целом, разработчик программного обеспечения сегодня должен знать больше языков, чем разработчик программного обеспечения 20 лет назад. Тогда что-то вроде C и SQL было достаточно. Сегодня я использую JavaScript, HTML, Groovy, Java, SQL в одном проекте.

оборота user281377
источник
+1 да, неосведомленные юные программисты стали ленивыми и менее компетентными
SoylentGray
12

Программисты становятся менее компетентными и ленивыми в некоторых отношениях, но более компетентными в других, хотя разделение C ++ / VB не является причиной или симптомом в моем сознании.

Использование GUI Builder не лениво, оно просто другое, оно связано с инструментами для работы. Если бы программист на ассемблере назвал программиста на C ++ ленивым, вы бы назвали это ерундой (правильно), и то же самое относится и к C ++ и VB. VB позволяет вам делать некоторые вещи быстро за счет некоторого контроля. Барьеры для начала кодирования в нем, безусловно, ниже, но это совсем не то, что лень - вы просто изучаете разные вещи и применяете их по-разному. Программисты на VB не более ленивы, чем программисты на C ++, они непродуктивны, они просто работают и производят по-разному.

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

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

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

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

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

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

Джон Хопкинс
источник
поэтому, когда никто не знает, что такое алгоритм или как реализовать структуру данных, потому что все они «программируют» в интегрированной среде разработки, они просто используют подходящий инструмент для работы?
Скит
@Skeith - Зависит от того, какая работа, но если она производит программное обеспечение, которое решает проблему, тогда да.
Джон Хопкинс
1
@ Джон-Хопкинс, я бы сказал, что огромный всплеск зависимого от Google программирования связан с огромным количеством API, которые нам нужны в настоящее время. Слишком сложно следить за всем этим. (Но, по сути, вы правы)
Джаррод Неттлс
1
@Skeith - Создание пользовательского интерфейса занимает около 5% от среднего времени разработчиков приложений. Как вы думаете, что они делают остальные 95%? Дизайнер не очень помогает с бэкэнд-кодом. Вы явно нападаете на соломенного человека. Большинство людей знают инструменты, необходимые для их работы, иначе они не были бы наняты.
Морган Херлокер
@ Скейт: Должен ли пользователь базы данных заботиться о том, как реализовать базу данных? Конечно нет; пользователь базы данных использует его. Им, возможно, потребуется знать некоторые детали, чтобы они могли оптимизировать свои базы данных, но они не должны быть в состоянии реализовать это, чтобы быть достойными его использования. Кроме того, программист может не знать, что означает слово «алгоритм», но это не значит, что они его не пишут . Я разрабатывал и реализовывал алгоритмы задолго до того, как услышал этот термин.
Никол Болас
11

Я отмечаю из вашего профиля, что вам 23 года. Позвольте мне засунуть зубы и дать вам некоторое представление о человеке, который примерно в два раза старше вас, который делал это очень давно:

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

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

... никому нет дела до того, как все работает, пока оно не работает.

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

Теперь я не призываю разработчиков VB просто сказать, что это проще, чем C ++, и я заметил, что многие новые языки следуют этой тенденции, такой как C #.

Это все вопрос перспективы. Я был рядом, чтобы увидеть, как появился С ++, и он также следует этой тенденции. C ++ делает вещи намного проще, чем C, C делает вещи намного проще, чем сборка, а сборка делает вещи намного проще, чем написание кодов операций вручную. Как человек, который написал много сборок и собрал несколько вещей вручную с нуля, вы, как программист на C ++, сделаете три шага по пути «проще».

оборота Blrfl
источник
1
+1 указывает на то, что это вопрос перспективы. Я был рядом, когда UNIX впервые появился в Bell Labs, и было немало «тск тск», потому что языки высокого уровня, такие как «С», заглушали древнее и эзотерическое искусство написания операционных систем, и это, несомненно, привело к не хорошо. По мере того, как наши инструменты совершенствуются и занимаются для нас более бессмысленной бухгалтерией, мы можем использовать сэкономленное время для более сложных и более тонких задач.
Чарльз Грант
6

То, что я поддерживал в течение долгого времени, это:

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

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

Когда я преподавал программирование в первом упражнении, первый день занятий был о том, как создать приложение в NOTEPAD и скомпилировать его с помощью VCC или VBC. Да, это то, что мы (как программисты) не делаем ежедневно, но должны понимать, что происходит, когда мы нажимаем «F6».

Программисты (как правило) не становятся «ленивее» настолько, насколько мы ожидаем получить больше от наших инструментов. Мне не нужно набирать «get / set» 10 000 раз в день, мне нравится, что Visual Studio и другие инструменты, такие как Code Smith и Resharper, работают для меня, чтобы сделать то, что я уже знаю, как это сделать, чтобы я мог приложить свои усилия к вычислению как делать "новые" вещи. Это не делает меня ленивым, это делает меня «инновационным».

Как профессиональный разработчик, мы не должны «тратить время» на новое изобретение колеса, но мы должны четко понимать, что входит в создание колеса, которое мы собираемся использовать. Это то, чему мы «должны» учиться как разработчики (но, к сожалению, часто нет). Если разработчик не понимает какую-то технологию «черного ящика», это действительно делает их менее «компетентными». Большинство разработчиков «в основном понимают», как работает драйвер ODBC, они просто понимают, «что» он делает. Должен ли я знать, как работает трансмиссия, чтобы быть компетентным водителем? Я бы сказал нет. Это делает меня более компетентным владельцем автомобиля, чтобы знать это, да.

Cos Callis
источник
4

Необходимость быстрой разработки приложений (обязательная ссылка на вики: http://en.wikipedia.org/wiki/Rapid_application_development ) означает, что разработчики пишут меньше кода, а новые разработчики понимают меньше, потому что им не нужно понимать, как реализовать связанный список, так как у них есть что-то более высокого уровня, чтобы сосредоточиться на.

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

StuperUser
источник
4

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

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

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

back2dos
источник
4

Ты просто стареешь.

Не шутите, то, что вы испытываете, является своего рода правом прохода для разработчиков. С тех пор, как первые языки более высокого уровня вытеснили сборку. Тогда вы слышали, как все программисты ASM жалуются на одно и то же. Через 5 лет все разработчики Ruby on Rails будут жаловаться на то, как ленивый еще один урожай новых инструментов делает людей.

Этот рефрен будет повторяться до тех пор, пока машины не уничтожат нас всех: «Кажется ли, что технология X делает разработчиков ленивее и хуже, чем технология Z, которую я всегда использовал?»

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

DougW
источник
+1: «Эти ленивые дети сегодня с колесницами, луками и стрелами. Когда я был мальчиком, мы сражались с короткими мечами в битвах и шли на поле битвы и обратно. И это было в обоих направлениях». - Ксеркс I, Император Персии, 473 г. до н.э.
Боб Мерфи,
3

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

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

Для конкретного примера: я - разработчик .NET по профессии. Я ожидаю, что компетентный разработчик .NET будет знать о таких вещах, как LINQ, Entity Framework, WPF, MVC и т. П .; им не нужно было использовать это или толкать это на рабочем месте, но, по крайней мере, мимолетное понимание «Это существует» лучше, чем абсолютное невежество, которое я вижу слишком часто.

Уэйн М
источник
2

Я работаю только около 4 лет, и это почти полностью на C #. Я изучал C ++, когда учился в колледже и университете, но сейчас я не смог бы с этим многое сделать.

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

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

Kioshiki
источник
2

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

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

Джох
источник
1
под компетенцией я имел в виду программирование, все остальные навыки не имеют значения, кроме математики.
Скит
3
@Skeith - «под компетенцией я имел в виду программирование, все остальные навыки не имеют значения, кроме математики» - это так неправильно. Одно из самых больших улучшений в отрасли за последние 30 лет заключается в том, что навыки общения теперь считаются абсолютно ключевыми. Дайте мне по-настоящему компетентного программиста с отличными математическими навыками или одного с отличными коммуникативными навыками, и это парень с навыками общения каждый раз.
Джон Хопкинс
+1 @Jon - Полностью согласен. Программисты, которые не говорят с покупателями ни в чем, кроме лямбда-исчисления и супа алафавита, бесполезны на большинстве проектов.
Морган Херлокер
1
@Skeith: То есть вам нужно только знать программирование и математику, чтобы быть хорошим программистом? В каком ты мире? Вам нужно знать, как пользоваться компьютером, как общаться с клиентами и другими программистами, как писать документы и т. Д. Вам не нужно знать математику. Конечно, есть некоторые совпадения между математикой и программированием, но достаточно знать только часть программирования.
Мартин Вилканс
Когда я учился в колледже, я посещал занятия по бизнес-исчислению. В финале я финишировал первым и получил 100 (учитель оценил меня прямо там - он был впечатлен, что я так быстро закончил). Тем не менее, как разработчик программного обеспечения, я использую ноль математики. Я использую логику, чтобы понять сферу бизнеса, и я использую харизму, чтобы взаимодействовать с людьми. Языки программирования развились настолько, что, если вы умеете хорошо писать по-английски, вы можете хорошо писать код. Предостережение: хорошо писать по-английски сложнее, чем программировать, потому что вы программируете программное обеспечение на основе ДНК ..
Кристофер Махан
2

Есть разница между «программистом» и «настоящим программистом». Пожалуйста, не называйте HTML языком программирования, но есть много «программистов HTML». Каждый из вас (программисты / разработчики) может пообщаться с коллегами - просто «выключите Интернет (фактически не позволяйте им использовать поисковые системы)», и вы увидите, что огромное количество «программистов» будет сидеть без работы. Что они могут сделать, они просто знают, что если им нужно, например, поиск по тексту, они должны «искать» поиск текста в% language_name% '"? Они не могут ответить на это - каковы различия в алгоритмах Бойера-Мура и Кнута-Морриса-Пратта.

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

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

Я ошибся?

UPD: Главное и главное - это знание основ, таких как алгоритмы, структуры данных и т. Д. Кто из вас может реализовать библиотеки / стандартные функции / и т.д. в случае, если сегодняшнее будет случайно удалено? ИМО, программист должен использовать разработанный / хорошо отлаженный «чужой» код (библиотеки / фреймворки / и т. Д.), Но должен иметь возможность изобретать колесо всегда!

дегуманизатор
источник
6
Моя единственная проблема с этим заключается в том, что я работал программистом (настоящий программист, а не web / HTML / скрипт) в течение 20 лет и понятия не имею об алгоритмах Кнута-Морриса-Пратта. Для большинства программистов такого рода теория не влияет на их повседневную жизнь, так как все это в библиотеках.
Джон Хопкинс
2
Стандартные библиотеки, с которыми я работаю, имеют тысячи классов и сотни тысяч строк кода. Вы говорите, что я смогу переопределить все это без документации? Если нет, вам нужно уточнить, насколько большим может быть что-то, прежде чем оно перестает быть колесом.
Питер Тейлор
6
Люди не имеют срока службы, необходимого для того, чтобы научиться изобретать все изобретенные колеса и научиться изобретать изобретаемые сейчас .
Мак
3
@Dehumanizer: надеюсь, я буду обучен и у меня в руках будет больше, чем C-компилятор, чтобы спасти мир, иначе я все равно облажусь. (Кстати, почему даже компилятор C? Почему бы не просто USB-флешка, осциллограф и батарея на 9 В? Серьезно ....)
Macke
1
Просто выключите их компиляторы, и вы увидите, что большинство людей просто сидят без дела, пока РЕАЛЬНЫЕ программисты набирают машинный код прямо в файл!
Филипп
1

Что касается простоты использования VB и ленивых программистов, выбирающих VB из-за этого:

Я думаю, что VB окружен одним большим мифом о простоте использования. Этот миф изначально был несколько правдив: в те дни, когда в 1991-1994 годах динозавры ходили по земле, вокруг было всего два реальных инструмента RAD, VB и Delphi. Они были очень похожи, но ОТМЕТЬТЕ: Delphi и VB одинаково просты в использовании! Единственное заметное различие между ними заключалось в том, что VB имел совершенно нелогичный синтаксис и создавал невероятно вялые программы.

Графические интерфейсы C / C ++ были написаны либо в MFC, либо в сыром Win API. Так что VB, конечно, было проще в использовании, чем альтернатива Microsoft. Тогда мельница слухов пошла так:

  • VB проще в использовании, чем Microsoft C / C ++ / Win API. ->
  • VB проще в использовании. ->
  • VB прост в использовании. ->
  • VB самый простой.

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

Затем в конце 90-х Borland выпустил C ++, эквивалентный Delphi: C ++ Builder. Теперь было 3 одинаково простых инструмента. Примерно в это же время умерло несколько оставшихся рациональных аргументов в пользу использования VB. И все же миф жил до сих пор. «VB самый простой».

Затем появилась Java, и для нее также было несколько инструментов RAD (и для ее фиаско-версии Microsoft под названием J ++). И все же миф о ВБ жил.

Затем Microsoft также сделала поддержку RAD для C ++, а также создала C #, превратив все это в одну большую систему под названием .NET. Так как миф о VB все еще жил, они смогли обмануть старых разработчиков VB, используя VB.NET вместо C ++ или C #. Хотя VB.NET был совершенно несовместим с более ранними версиями VB.

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

user29079
источник
спасибо, теперь я могу звучать более оправданно в своей ненависти к VB, добавив причину
Skeith
1

Существует огромное разнообразие видов деятельности, которые объединены под лозунгом «программирования», и все большее число работников задействовано на «техническом» уровне шкалы. Вам не нужно уметь писать компиляторы или даже выбирать из набора алгоритмов, чтобы решить конкретную проблему, чтобы собрать сайт на PHP. Промышленность / общество нуждается в большом количестве людей, производящих упомянутые веб-сайты (очевидно), а также в определенном количестве программистов, работающих над более сложными проблемами. Эта вторая группа не ленива или некомпетентна, в целом, иначе наши самолеты загорятся, банкоматы доставляют случайные суммы наличных денег, рентгеновские аппараты доставляют смертельные дозы радиации, финансовые рынки просыпаются и т. Д. Держись, забудь о том, что последний :-)

Jaybee
источник
1

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

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

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

Высокий уровень Цель на высоких уровнях - автоматизировать базовую функциональность и упростить программирование. Это снижает планку ввода для новых программистов, ускоряет работу и стандартизирует способ представления и обработки данных, часто с накладными расходами. Рассмотрим строку. В первые дни кто-то, вероятно, использовал 1-26 для аз, и использовал только 5 битов, и ему просто нужно было знать, какого размера были его слова. Затем был разработан стандарт ascii, и у нас были C-строки с символом-терминатором. Теперь у нас есть объекты, которые обрабатывают вещи, чтобы избежать переполнения буфера, и специальные подтипы, которые запрещают экранирующие символы. Или петля. Цикл «for» немного выше уровня цикла «while». А цикл while - это просто представление структурированного вызова GOTO.

Также,

Будущие программисты скажут компьютеру, чего они хотят, и компилятор напишет программу для них, как в Star Trek.

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

Филипп
источник
1

Я думаю, что где-то по пути вы потеряли из виду, за что платят программисты.

Наш результат не Код, это работающее программное обеспечение.

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

Нам платят за решение бизнес-задач на компьютерах). Если вы можете доставить один и тот же продукт за меньшее время за меньшие деньги, то я думаю, что мы ОБЯЗАНЫ отбросить предлог, что программы на C ++ превосходят просто потому, что их сложнее создавать.

JohnFx
источник
* это раздутый софт, (иногда)
кагали-сан
0

Соотношение (число разработчиков основной программы / количество разработчиков) уменьшается, потому что:

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

  • Люди привыкают к ИТ-технологиям, у них больше желания тратить деньги на индивидуальные инструменты

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

  • Больше рабочих мест, фильтр ослаблен

  • На каждом жизненном цикле требуется больше автоматизации, спрос растет, а предложения недостаточно

  • Соотношение застройщиков к населению увеличивается.

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

oguzalb
источник
0

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

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

шанс
источник
0

До 1940-х годов компьютеры были проводными схемами. Затем фон Нейману пришла в голову идея сохранения областей памяти. Я уверен, что эти программисты из Массачусетского технологического института думали, что он собирается перевести свою торговлю в нечто слишком простое. Затем пришла сборка, затем пришел FORTRAN, затем ada, затем C, затем c ++, затем java и так далее. Суть в том, что смысл языка заключается в том, чтобы позволить дальнейшую и дальнейшую абстракцию. Это всегда было целью, и именно поэтому C ++ завоевал популярность, а затем и Java. Моя самая большая проблема в том, что университеты больше не учат студентов о компьютерах. Я не нанимаю программистов на С #, если они не знают С ++, как свою собственную руку. Зачем? Поскольку быть плохим программистом слишком легко, тем более абстрактным становится язык. Они должны понимать указатели, управление памятью, динамическое связывание и т. Д. , внутри и снаружи, прежде чем они смогут понять C # до уровня, которому я доверяю, чтобы они внесли свой вклад в нашу кодовую базу. Я также заставляю их бороться с созданием файлов, прежде чем разрешить им использовать Visual Studio. Тем не менее, я люблю C # и хорошую IDE, но они хороши как инструменты, если их правильно понять. На мой взгляд, абстракция наиболее полезна, когда вы понимаете, что абстрагируются частные сведения - это очень старая идея, см. Томас Аквинский об отношении абстракции к частным.

Я думаю, что еще одно хорошее упражнение для разработчиков начального уровня - заставить их написать несколько приложений с использованием Windows API. Затем, после того, как они закончат его, пусть они сделают его объектно-ориентированным, где каждая форма наследуется от вашего общего оконного класса. Пусть они инкапсулируют цикл событий и помещают некоторые указатели на функции, возвращающиеся в их класс формы. Тогда скажите "хорошо", Microsoft уже сделала это для вас, она называется System.Windows.Forms. Повеселись.

Если они хотят быть веб-разработчиками, попросите их написать несколько CGI-программ, чтобы они понимали POST, GET и т. Д., А затем написали сценарий на странице. Это делает ASP.NET и PHP более понятными.

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

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

Университеты должны делать это, но это не так, как мы.

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

Джонатан Хенсон
источник
0

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

Я не согласен с этим пунктом.
Не зная, что такое сознание, работа программиста безопасна.

Вот так выглядят «мыслительные машины» на данный момент:

Перестань менять тему!
-Я думал, что наша любовь была особенной.
Перестань менять тему!
-Я не меняю тему.
-Ты! Я пытаюсь говорить о вашей неспособности понять, о чем мы говорим.
Нет, это даже не близко. моя любимая песня битлз по всей вселенной. Что твое?

Я считаю, что только те программисты, которые не понимают этого, обречены.

Например, ответ Dehumanizer :

Они не могут ответить на это - каковы различия в алгоритмах Бойера-Мура и Кнута-Морриса-Пратта.

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

Сами инструменты не решают проблемы, они просто (иногда) делают программистов более эффективными.

Это как с: «оружие не убивает, люди делают».

Арнис Лапса
источник
1
Если я не ошибаюсь, разве Клевербот просто не повторяет то, что люди уже сказали ему?
Эндрю Арнольд
0

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

Авиатор с кофеином
источник
0

Означает ли чрезмерная зависимость от инструментов, что вы ленивы?

Вообще говоря, «нет»; но есть одна большая оговорка.

Я начал программировать на C ++ в универе и мне это нравилось. В следующем семестре мы перешли на VB6, и я его ненавидел.

Я не мог сказать, что происходит, вы перетаскиваете кнопку в форму, и ide пишет код для вас.

Да, в самом деле. Ваш опыт в университете говорит с той оговоркой, которую я упомянул.

Если вы не знаете, какую проблему решает ваш инструмент, или вы неспособны решать проблемы, когда у вашего инструмента есть собственные проблемы, тогда это огромный красный флаг. Это обстоятельство не обязательно подразумевает лень, но, вероятно, подразумевает неопытность.

Джим Г.
источник
-2

Я думаю, что есть 2 варианта программистов. Есть программисты, которые просто программируют, чтобы выполнить свою работу из-за крайнего срока или, возможно, просто чтобы быть более продуктивным. Я бы сказал, что они ленивы. Я просто считаю, что они не заинтересованы в том, «как» компьютер делает то, что он делает, или «как» программа делает то, что делает.

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

Icemanind
источник
Я не согласен. Разные люди интересуются разными вещами. Некоторые люди больше интересуются программированием нижнего уровня и любят знать, что происходит в аппаратном обеспечении. Другие люди более высокого уровня и касаются в первую очередь приложений. Как вы думаете, кто-то, пишущий код, скажем, для Facebook, имеет какие-либо проблемы с тем, что происходит с процессором или как работают драйверы? Сказать, что, по совпадению, люди, которые интересуются теми же частями программирования, что и вы, являются страстными, не имеет логической основы.
шанс
-3

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

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

кодер
источник