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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты говоришь:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я ошибся?

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

Что касается простоты использования 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. Синтаксис языка совершенно ужасен, настолько плох, что фактически поощряет плохой дизайн программы и плохую практику программирования.

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

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

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

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

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

Также,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До 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 и поэтому не понимают, как они работают. Тем не менее, абстракция весьма полезна при правильном использовании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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