Как написали первую программу без программы для написания программ?
Если коротко, то новые языки программирования и другие инструменты создаются на основе уже существующих. Полная аналогия с другими областями техники, где новые станки и материалы позволяют создавать всё более совершенные станки и материалы. Как все станки начались с палки-копалки и кремниевого рубила, так и языки программирования начались с перфокарт и нечитаемого двоичного кода.
Центральный процессор вашего компьютера понимает только программы, написанные на языке ноликов и единичек. Например, команда «прибавить константу 5 к числу, записанному в регистре AL» записывается так:
0000 0100 0000 0101
Здесь 0000 0100 — код операции «прибавить число к регистру AL», а 0000 0101 — двоичное представление числа 5.
На заре индустрии для ввода программы в компьютер нужно было либо перещёлкнуть сотни тумблеров на специальной панели (тумблер ВЫКЛ — нолик, тумблер ВКЛ — единичка), либо пробить дырочки в специальной перфокарте. Ошиблись в одной ячейке из тысячи — программа будет работать неправильно, будьте добры сами найти ошибку методом пристального взгляда.
Ясно, что такой способ программирования жутко неудобен и подвержен ошибкам. Чтобы не тратить время на это занудство, ленивые программисты начали думать, как переложить неблагодарную работу на машину.
Можно один раз хорошенько помучиться и написать на языке ноликов и единичек вспомогательную программу, которая называется ассемблер («сборщик»). Этот волшебный ассемблер принимает на вход человеко-читаемый текст и преобразует его в нолики и единички. Например, та же самая команда «прибавить константу 5 к числу, записанному в регистре AL» записывается на языке ассемблера x86 так:
Думаю, вы согласитесь, что это всё-таки более читаемо, чем 0000 0100 0000 0101. Здесь хотя бы понятно, что речь идёт о сложении (ADD) и числе 5. Теперь уже дело ассемблера преобразовать эту строчку в 0000 0100 0000 0101. На языке ассемблера сложно писать большие программы, процессоры разных производителей могут требовать разных ассемблеров, но всё равно это был большой шаг вперёд.
Дальше инженерную мысль было не остановить. Нужно один раз помучиться, чтобы написать на ассемблере компилятор языка программирования, например Фортрана. Потом ещё немного помучиться, чтобы написать на Фортране компилятор Алгола. Затем передохнуть, помучиться и написать на Алголе компилятор языка CPL. Ещё немного мучений, и можно на основе CPL написать компилятор языка C. Дальше можно уже не мучиться и в свое удовольствие писать на C компиляторы C++, Java, C# и других современных языков. Впрочем, никто не запретит использовать Java чтобы написать ассемблер x86 и замкнуть рекурсию.
Как создали программы для программирования без программ для программирования?
Если коротко, то новые языки программирования и другие инструменты создаются на основе уже существующих. Полная аналогия с другими областями техники, где новые станки и материалы позволяют создавать всё более совершенные станки и материалы. Как все станки начались с палки-копалки и кремниевого рубила, так и языки программирования начались с перфокарт и нечитаемого двоичного кода.
Центральный процессор вашего компьютера понимает только программы, написанные на языке ноликов и единичек. Например, команда «прибавить константу 5 к числу, записанному в регистре AL» записывается так:
0000 0100 0000 0101
Здесь 0000 0100 — код операции «прибавить число к регистру AL», а 0000 0101 — двоичное представление числа 5.
На заре индустрии для ввода программы в компьютер нужно было либо перещёлкнуть сотни тумблеров на специальной панели (тумблер ВЫКЛ — нолик, тумблер ВКЛ — единичка), либо пробить дырочки в специальной перфокарте. Ошиблись в одной ячейке из тысячи — программа будет работать неправильно, будьте добры сами найти ошибку методом пристального взгляда.
Ясно, что такой способ программирования жутко неудобен и подвержен ошибкам. Чтобы не тратить время на это занудство, ленивые программисты начали думать, как переложить неблагодарную работу на машину.
Можно один раз хорошенько помучиться и написать на языке ноликов и единичек вспомогательную программу, которая называется ассемблер («сборщик»). Этот волшебный ассемблер принимает на вход человеко-читаемый текст и преобразует его в нолики и единички. Например, та же самая команда «прибавить константу 5 к числу, записанному в регистре AL» записывается на языке ассемблера x86 так:
Думаю, вы согласитесь, что это всё-таки более читаемо, чем 0000 0100 0000 0101. Здесь хотя бы понятно, что речь идёт о сложении (ADD) и числе 5. Теперь уже дело ассемблера преобразовать эту строчку в 0000 0100 0000 0101. На языке ассемблера сложно писать большие программы, процессоры разных производителей могут требовать разных ассемблеров, но всё равно это был большой шаг вперёд.
Дальше инженерную мысль было не остановить. Нужно один раз помучиться, чтобы написать на ассемблере компилятор языка программирования, например Фортрана. Потом ещё немного помучиться, чтобы написать на Фортране компилятор Алгола. Затем передохнуть, помучиться и написать на Алголе компилятор языка CPL. Ещё немного мучений, и можно на основе CPL написать компилятор языка C. Дальше можно уже не мучиться и в свое удовольствие писать на C компиляторы C++, Java, C# и других современных языков. Впрочем, никто не запретит использовать Java чтобы написать ассемблер x86 и замкнуть рекурсию.
Как начать программировать?
Для кого эта статья?
В первую очередь для тех, кто интересуется программированием, но не знает как к нему подступиться.Ведь это неизвестность, которая всегда пугает.
Ко мне периодически обращаются юноши, которые горят желанием программировать, но теряются. Действительно, есть много такого, что хочется создать своими руками. Много разного. Чаще всего молодёжь хочет написать крутейшую игру, которая будет работать на слаааабенькой видеокарте 🙂 Мне приходится их разочаровывать. Дело в том, оптимизация программы не менее сложная работа, чем её написание. целые команды профессионалов работают над этим. И наивно полагать,сто один разработчик,который только начал изучать азы программирования окажется более эффективным в этой задаче. Задача «крутая игра на слабом железе» возникает от невозможности позволить себе дорогую видеокарту. Обычно такую задачу ставят себе старшеклассники, либо студенты начальных курсов институтов.
Один из моих студентов со временем понял, что заниматься WEB программированием (не путать с вёрсткой) намного интереснее. А крутую видеокарту можно купить на нормальную зарплату программиста, без особого ущемления других своих потребностей.
Платформы
Итак, первым шагом определяем, что именно хочется программировать. В какое именно устройство вложить свой мозг и для чего это нужно именно Вам (может, просто для высокой зарплаты).
Основных направлений не так уж много:
Мобильные приложения (Android, iOS)
Виртуальная и дополненная реальность AR/VR
Мультимедиа (Фото, видео и звук)
Встроенные системы и IoT(типа, Arduino, STM32, AVR, ESP и т.п.)
Наверняка есть ещё направления. Более экзотические. Или комбинации из перечисленных. Например, дополненная реальность в мобильных приложениях.
Выбирайте, с какими устройствами Вы хотите работать и переходим к следующему шагу.
Инструменты и технологии
Лёгкий старт
Для того, чтобы новичку придать начальное ускорение в каждом развитом технологическом решении (платформа + инструмент) есть примеры готовых приложений, которые можно просто собрать и запустить на выполнение. Посмотреть как оно работает. Поизучать какие изменение в тексте программы как влияет на исполнение приложения. Есть так же образцы кода, которые можно скопировать в своё приложение. На жаргоне программистов это называется «скопипастить» от слов Copy + Paste Правда, они могут не всегда работать 🙂
Живое сотрудничество
Тайные смыслы
Почему так сложно? Потому, что современное программирование давно и далеко ушло от своих истоков. Наработано огромное количество технологий, библиотек, компонетов и прочего кода, который хочется использовать повторно. На жаргоне это называется Reuse (реюз) Встают практические задачи совместно использовать один компонент с другим, одновременно использовать разные компоненты, в одном приложении или системе использовать различные технологии одновременно. Такая задача называется интеграцией. Сборкой чего-то целого из частей. И программисты часто сталкиваются с проблемой совместимости этих самых частей. возникают ошибки, конфликты сборки и исполнения, различия систем понятий. Чтобы разрешить проблемы нужно глубоко вникать в детали и подробности. Глубже и глубже. Делать предположения, проверять их. Затем тестировать. В общем, это целый мир. «Зазеркалье»
Хотите туда? Интересно? Тогда дерзайте.
Эта статья не претендует на введение в специальность.
Она была написана постольку, поскольку вопросы задаются и я на них отвечаю.
Программирование для начинающих: как стартовать и куда двигаться?
Бывает, что человек, совсем не связанный с IT, проникается интригующей красотой этой сферы и ставит себе задачу постепенно освоить программирование с нуля. И тут он зачастую просто теряется, не понимая, с чего начать, и нуждаясь в хорошем фундаменте и системном подходе.
Я, будучи недавно в такой же ситуации, гуглила, искала мануалов на Хабре (кое-что нашла: Десять советов начинающим программистам, Начинающему программисту про стартапы и не только…), но в итоге всё же была вынуждена обратиться за советом к одному хорошему человеку, который составил для меня вот такой план. С разрешения этого человека размещаю данный план на Хабре – вдруг он пригодится и кому-то ещё. (Тем более, что перечисленные книги относятся к «золотому фонду» литературы в данной сфере и проверены временем.)
UPD: Новичкам советую обратить внимание на комментарии — там активно и аргументированно корректируется этот план.
Нортон «Программно-аппаратная организация IBM PC»
Эта книга, несмотря на свою давность, относятся к тем, что пока отнюдь не устарели. Как новичок подтверждаю – повествование вполне понятно и для почти полного чайника в IT.
Гук «Аппаратные средства IBM PC»
А эту книгу стоит прочитать «поверх» – она расскажет о том, как дела в данной сфере обстоят сейчас.
Морс, Алберт «Архитектура микропроцессора 80286»
Почему тут берётся за основу именно микропроцессор 80286 – станет понятно по изучении трудов первого этапа.
Гук «Аппаратные интерфейсы ПК»
Гук «Интерфейсы устройств хранения»
Этап III. Операционные системы
Таненбаум «Архитектура компьютера»
Колисниченко, Аллен «Linux: полное руководство»
От общей теории переходим к изучению конкретной операционной системы – на примере Linux.
Немет, Снайдер, Хейн «Руководство администратора Linux»
Этап IV. Собственно программирование
Керниган, Ричи «Язык программирования С»
Почему первым для освоения выбран именно язык Си? Как мне рассказали знающие товарищи, он поможет достичь правильного «программистского мышления», чего было бы сложно достичь, начиная изучение, скажем, с Паскаля. Кроме того, язык Си по-прежнему используется в наши дни и подходит как для прикладного, так и для системного программирования.
Кнут «Искусство программирования»:
Том 1. Основные алгоритмы
Том 2. Получисленные алгоритмы
Том 3. Сортировка и поиск
Бентли «Жемчужины программирования»
Зачем осваивать эти труды? Как уже отмечали на Хабре – «наверное, нигде больше, чем в айти, не изобретается такое огромное количество велосипедов». Данные книги помогут этого избежать – и попутно будут прививать умение писать не просто код, а хороший код.
Ну а для затравки можно прочесть небольшой цикл лекций «Культура программирования» (автор – А. Бабий). Он помогает начинающим программистам понять, что их деятельность не будет проходить в вакууме, а неизбежно включит взаимодействие с другими программистами, с заказчиками и пользователями (а также включит необходимость копаться потом в своих собственных или в чужих программах).
Закономерный вопрос новичка: сколько времени займёт изучение всего этого? По прогнозам моего советчика, у человека, который может тратить на изучение программирования только вечера и выходные, на прочтение и осмысление литературы первых трёх этапов уйдёт полгода-год. На четвёртый этап тоже даётся год – чтение должно сопровождаться практикой по самостоятельному составлению программ. Как получится на самом деле – время покажет.
Буду крайне благодарна за ваши советы и уточнения.
Не путайте разработку ПО и программирование
Каждый разработчик ПО умеет программировать, но не каждый программист может разрабатывать ПО
Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!
Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.
Чтобы стать разработчиком, уметь программировать недостаточно.
Научить программировать можно любого — это легко. Писать простые программы, которые работают у конкретных людей на конкретных машинах, может почти кто угодно, но никто не гарантирует, что те же программы будут работать в других условиях.
Мне нравится такая аналогия: каждый может ради собственного развлечения петь в ду́ше, но вы же не ставите треки с записями этого пения на вечеринке — вы обращаетесь к произведениям профессиональных музыкантов.
Хотите еще аналогий? Пожалуйста:
Программирование в простейшем представлении — это передача компьютеру указаний на совершение некоторых действия с некоторыми входными данными для получения некоторого вывода.
Разработка же программного обеспечения — это проектирование, написание, тестирование и поддержка компьютерных программ с целью решения задач для множества пользователей; это создание надежных защищенных решений, которые выдержат испытание временем и справятся с некоторыми не известными заранее задачами, лежащими в области, близкой к очевидным исходным задачам.
Разработчики ПО досконально изучают решаемые задачи, полностью понимают, как работают предложенные ими решения, как эти решения ограничены и как они характеризуются с точки зрения конфиденциальности работы с данными и безопасности.
А если кто-то не понимает задачу, ему нельзя давать разрабатывать для нее решение.
Ориентированный на решения подход
«Умные решают проблемы — гении же их предотвращают».
— Альберт Эйнштейн
Для сложных задач приходится писать несколько программ. В некоторых случаях нужны программы, работающие параллельно, в других — запускающиеся последовательно. Иногда для решения задачи достаточно обучить пользователей.
Прежде чем писать код, разработчик задастся следующими вопросами:
Качество кода
В качественных программах код понятен и читается легко, их можно без труда расширять, они отлично взаимодействуют с другим ПО, а их поддержка не превращается в кошмар. Качество кода не должно становиться жертвой компромиссов; использование быстрых, но неаккуратных решений из-за поджимающего срока, излишнего волнения, взбудораженности, раздраженности и т. д. — неприемлемо.
Один из важнейших аспектов разработки ПО — это проектирование с нуля продукта, готового к расширению. Модификация приложений после их выпуска — факт, с которым нужно смириться. Пользователям будет нужно всё больше функционала, они захотят, чтобы пользоваться приложением было еще проще.
Компонент приложения обычно не очень полезен сам по себе. Пользу ПО начинает приносить, когда несколько компонентов взаимодействуют друг с другом, обмениваются данными и совместно работают на задачей представления данных и интерфейсов пользователям.
И с учетом этого нужно разрабатывать программы. Какие сообщения принимает ПО? Какие события отслеживает? Какие сообщения выдает? Как проходит проверка подлинности и авторизация при передаче данных?
Другой важный аспект написания хороших программ — это понятный код, а совсем не количество тестов или число в отчете о покрытии кода. Здесь всё просто. Подумайте: смогут ли другие прочитать код? Или — что еще лучше — сможете ли вы сами, написав код сегодня, понять его спустя несколько недель?
«В компьютерных технологиях есть только две сложные задачи: недействительность кэша и придумывание названий».
— Фил Карлтон
«У меня не было времени написать письмо короче».
— Блез Паскаль
С любой программой в какой-то момент что-то обязательно пойдет не так. Главный признак хорошего ПО — возможность легко исправить уже выпущенную в работу программу. Если программа во время работы выдает ошибку, об этом должно быть понятное сообщение, которое будет где-то централизованно записано — чтобы ошибки можно было отслеживать. При сообщении о новой ошибке у ответственного за ее исправление должна быть возможность провести отладку, в любой момент времени подключиться к системе и получить сведения о контексте выполнения, а также проверить ожидаемое поведение какого-либо компонента системы.
Рабочее окружение и тестирование
Когда разработчик пишет программу, он проверяет, чтобы она работала во множестве различных окружений, на машинах с разными ресурсами и в разных часовых поясах. ПО должно работать на экранах различных размеров и ориентации, в условиях ограниченной памяти и малой вычислительной мощности.
Например, если ПО пишется для веб-браузера, оно должно работать на всех основных браузерах. При создании классического ПО оно в большинстве случаев должно работать на платформах Mac и Windows. Если создаваемое приложение зависит от получения данных, оно должно продолжать работать и в том случае, если подключение к данным медленное или даже некоторое время полностью отсутствует.
Чтобы написать компонент ПО, разработчики пытаются продумать все возможные сценарии, которые только можно себе представить, и планируют их проверку. Начинают с того, что называется сценарием по умолчанию (или «счастливой дорогой» — от англ. «happy path»), в котором не происходит ничего неожиданного, а все возможные на этом пути проблемы — что важно — документируются и для каждой планируется тест. Некоторые разработчики начинают с написания «тестовых случаев», которые имитируют такие сценарии. Затем они пишут функциональный код, который проходит эти тестовые случаи.
Разработчики должны понимать предъявляемые к ПО требования, а ведь те часто бывают неоднозначными и неполными. Мастерство разработчика проявляется не в том, как он напишет решение, а скорее в том, какое решение он посчитает необходимым.
Стоимость и эффективность
В большинстве случаев разработчик может решить задачу быстро. Если вам кажется, что нанимать на работу опытных программистов — затратно, задумайтесь: чем больше у программиста опыта, тем быстрее он создаст функциональное, точное, надежное решение, которое несложно будет поддерживать. А это — меньшие затраты в долгосрочной перспективе.
Кроме того, учитывать следует и «стоимость работы» программы: всякое ПО потребляет ресурсы компьютера, а они не бесплатные. Разработчик напишет эффективную программу, которая не будет использовать ресурсы ПК без необходимости. Для этого он может применить, к примеру, кэширование часто используемых данных, — и это всего лишь один из, наверное, тысяч инструментов и способов, которые помогают повысить эффективность и скорость работы программы.
Возможно, программист-новичок и даст дешевое решение, но работа с этим решением может стоить вам и вашим клиентам намного больше, чем если бы вы сразу наняли опытного разработчика, который в первую очередь стремится найти эффективное решение.
Удобство использования
Хорошее ПО разрабатывается с учетом взаимодействия компьютера с пользователем (UX), и это довольно обширная тема, по которой проведено множество исследований и получено немало результатов. Чем больше выводов из этих исследований учтено, тем лучше будет ПО в использовании.
Позвольте я приведу пару примеров, чтобы вы могли прочувствовать, почему это важно:
Надежность, безопасность и защищенность
Пожалуй, самый важный аспект, который отличает разработчиков-профессионалов от программистов-любителей, заключается в том, что профессионалы знают, что они несут ответственность за создание безопасных защищенных решений.
Компонент ПО должен быть устойчив к «плохим» данным, неправильным состояниям и неверному взаимодействию. Добиться такой устойчивости ОЧЕНЬ сложно — именно поэтому мы постоянно читаем о том, как кто-то умер из-за ошибки ПО.
Пользователи будут вводить в ПО «плохие» и неправильные данные. Кто-то будет делать это намеренно — с целью взломать ПО и добраться до ресурсов, которые представляет данное ПО. Сотрудника, якобы ответственного за брешь в безопасности американского бюро кредитных историй Equifax, которой воспользовались злоумышленники, обвинили в том, что он не выполнил свою работу: он должен был обеспечить устойчивость к «плохим» и вредоносным данным во всём ПО, открыто публикуемом от имени компании.
Задача обеспечения безопасности связана не только с «плохими» и вредоносными данными, но и с обычными. Например, если пользователь забыл пароль, сколько раз он может попробовать его ввести? Блокировать ли его после исчерпания попыток ввода? Что, если кто-то умышленно пытается заблокировать пользователя? Давать ли пользователям возможность отправлять пароль по незашифрованному соединению? Что делать, если кто-то пытается войти в учетную запись из необычного места? Что предпринять, если возникает подозрение, что вход в систему осуществляется автоматически?
Как защитить своих пользователей от межсайтовых сценариев и подделки межсайтовых запросов, атак «злоумышленник посередине» и простого социального фишинга? Как разработать стратегию резервного функционирования в случае DDoS-атаки на сервера? Перечисленные вопросы — лишь малая толика из множества вопросов, которые нужно учитывать при проектировании.
Защищенные программы хранят конфиденциальные сведения не в виде обычного текста, а как односторонне зашифрованные данные со сложно взламываемыми алгоритмами. Это — резервная защита на случай взлома ПО и несанкционированного доступа к данным: хакерам достанутся зашифрованные данные, которые в большинстве случаев будут бесполезны.
Приложение может перейти в состояние ошибки, и его нужно будет исправить: даже в самых лучших программах возникают неожиданные проблемы. Если вы не учитываете это при планировании, вы — не профессиональный разработчик, а просто кодер с небезопасными программами.
Программные дефекты выявить сложно. Наш ум ограничен в своей способности прогнозировать и предотвращать известные дефекты. Поэтому разработчики ПО ценят хорошие инструменты, которые помогают писать правильный код и создавать безопасное ПО.
Используемые инструменты
Очевидно, что нам нужно больше инструментов и нужны инструменты лучше. В разработке ПО инструменты имеют большое значение, но их часто недооценивают.
Представьте на минутку, что для развертывания нам по-прежнему нужно было бы использовать FTP! Представьте отладку сети и выявление проблем производительности без браузерных инструментов разработчика! Представьте себе, как упадет эффективность написания JavaScript-кода, если не использовать ESLint и Prettier!
Если в JavaScript-разработке вы почему-то вынуждены оставить только один плагин для редактора кода, выбирайте ESLint.
Отличным дополнением будет всякий инструмент, который сокращает цикл обратной связи при написании кода. Мысль Брета Виктора об изобретении мгновенных визуальных представлений того, что мы создаем, открыла мне глаза. Использование и совершенствование инструментов — один из способов приблизиться к этому светлому будущему. Если вы еще не видели выступление Брета — обязательно посмотрите его.
Когда я нахожу отличный инструмент, я сожалею лишь о том, что не пользовался им раньше. Чем лучше инструмент, тем лучше с его помощью пишутся программы. Ищите, используйте и цените их, а если можете — и совершенствуйте.
Выбор языка — важен. Безопасность типа — важна. Лучшее, что произошло с языком JavaScript, — это TypeScript (и Flow). Статический анализ кода важнее, чем вам кажется. Если вы его не используете, вы, в сущности, становитесь уязвимы для возможных неизвестных проблем в будущем. Не пишите код без системы статического контроля типов. Если в выбранном языке нет статического контроля типов, нужно либо сменить язык, либо найти для него транскомпилятор: сегодня они уже достаточно умны, чтобы работать по комментариям в коде, и мне кажется, что для языков, не поддерживающих статический контроль типов, транскомпиляторы вскоре станут стандартным инструментом.
Становление разработчика ПО
Невозможно научиться разрабатывать ПО за пару месяцев, полгода и даже за год. На курсах программирования из вас не сделают разработчика. Я начал учиться 20 лет назад — и продолжаю учиться сегодня. С достаточной уверенностью я смог назвать себя опытным программистом только после десяти лет обучения, в течение которых мне пришлось спроектировать, создать и обеспечить поддержку приложений, используемых тысячами пользователей.
Разработка программного обеспечения — занятие не для всех, но каждый должен научиться решать собственные задачи с помощью компьютеров. Если вы можете научиться писать простые программы — сделайте это. Если можете научиться использовать несложные программные сервисы — сделайте это. Если можете научиться использовать ПО с открытым исходным кодом, в ваших руках окажутся мощные инструменты.
Задачи с течением времени меняются, поэтому меняется и разработка ПО. Задача этой профессии в будущем — дать возможность обычным людям использовать компьютеры, не тратя при этом на обучение полдюжины лет. Нужно дать пользователям простые и понятные инструменты, с помощью которых они будут самостоятельно решать простые задачи. А затем разработчики перейдут к созданию лучших инструментов, решению более масштабных известных задач и сделают все возможное, чтобы предотвратить появление неизвестных проблем.
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.