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

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

Первым программируемым устройством принято считать жаккардовый ткацкий станок, построенный в 1804 году Жозефом Мари Жаккаром, который произвёл революцию в ткацкой промышленности, предоставив возможность программировать узоры на тканях при помощи перфокарт.

Первое программируемое вычислительное устройство, Аналитическую машину, разработал Чарльз Бэббидж (но не смог её построить). 19 июля 1843 года графиня Ада Августа Лавлейс, дочка великого английского поэта Джорджа Байрона, как принято считать, написала первую в истории человечества программу для Аналитической машины. Эта программа решала уравнение Бернулли, выражающее закон сохранения энергии движущейся жидкости.

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

Однако ни одна из программ, написанных Адой Лавлейс, никогда так и не была запущена.

Аду Августу, графиню Лавлейс, принято считать почётным первым программистом (хотя, конечно, написание одной программы по современным меркам не может считаться родом занятий или профессиональной деятельностью). История сохранила её имя в названии универсального языка программирования «Ада».

Первый работающий программируемый компьютер (1941 год), первые программы для него, а также (с определёнными оговорками) первый язык программирования высокого уровня Планкалкюль создал немецкий инженер Конрад Цузе.

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

Программи́рование — процесс создания компьютерных программ.

По известному выражению Никлауса Вирта «Программы = алгоритмы + структуры данных»[1] [2]; иными словами, ключевыми непосредственными задачами программирования являются создание и использование алгоритмов и структур данных.

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

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

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

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

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

Представьте, что у вас на вашем любимом автомобиле что-то сломалось или отвалилось. Точнее, то, что именно сломалось или отвалилось вы не знаете, просто автомобиль перестал выполнять свою основную функцию – возить вас из пункта “А” в пункт” Б”. Вы приезжаете в сервис-центр (на эвакуаторе), с озабоченным лицом оглашаете “сервисмену” симптомы, отдаете своего "коня" и отправляетесь ждать. Через какое-то “понятное” время (требующееся на диагностику проблемы) вам оглашают диагноз и “радуют” прогнозом на то “когда ждать выписки больного” и “сколько вам придется заплатить ветеринару”. Почему диагностика не отнимает много времени, а прогноз возможен? Да потому что во-первых: все автомобили имеют сходную конструкцию, каждая деталь которой выполняет отдельную, понятную функцию (я не про распознавание дорожных знаков и автоматическую парковку); во-вторых: то, что случилось с вашим автомобилем в 95% случаев уже случалось с другими аналогичными авто — вряд ли у нашего брата может быть какой-то эксклюзив. Коллективное творчество

К чему это я…

Если вы посетите тематические форумы по разработке программного обеспечения, то станете свидетелем невероятного многообразия возникающих у разработчиков частных проблем. Естественно, что на каждую такую проблему всегда находится решение, а зачастую и не одно…и ни один десяток, а автор вопроса, в свою очередь, выбирает то решение, которое ему ближе (читай — понятнее), но дело даже и не в этом. Проблема всегда формулируется локально – т.е. автор не уточняет в рамках решения какой подзадачи у него возникла проблема, и какую в целом задачу должен решать его гениальный код. Не уточняет, потому что не считает нужным: it is not your f…cking business, как говорится. Вы мне помогите решить “вот это”, а остальное я сам как-нибудь... В результате, человек учится тому, как средствами “голого” API по любимому всеми http протоколу хитроумно передавать описание вызова (сигнатуру) функции с параметрами на сервер и получать обратно результат ее работы. Часто в таких случаях не заботятся о безопасности, не говоря уже об отказоустойчивости и адекватной идентификации причин ошибок. Если бы проблема была описана полностью, то вопрошающему, скорее всего, посоветовали бы воспользоваться библиотеками известных производителей (например, известных всем своим стремлением сделать сложности программирования “маленькими” и “мягкими”, за что им огромный респект), потому как не стоит забывать, что если тебе в голову пришло что-то гениальное, то, с большой вероятностью, это "что-то" уже посещало голову кого-то другого до тебя…и он “этим” уже как-то распорядился. Windows Communication Foundation (WCF) — технологии Microsoft для создания распределенных информационных систем

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

Справедливо, что сравнение серийного продукта и результата разработки на заказ некорректно, но…

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

P.S. Нужно всегда относиться с уважением к тому, что ты делаешь. Если бы кто-то собрался снимать "приквел" к фильму “матрица”, то, по моему мнению, в конце фильма к месту пришлась бы фраза: “Если вы не будете аккуратно и качественно проектировать программы, то в будущем они будут проектировать вас…”

Timus Online Judge — это крупнейший в России архив задач по программированию с автоматической проверяющей системой. Основной источник задач для архива — соревнования Уральского федерального университета, Чемпионаты Урала, Уральские четвертьфиналы ACM ICPC, Петрозаводские сборы по программированию. Чтобы начать решать задачи прочитайте руководство.

Timus Online Judge позволяет принять участие в онлайн-версиях большинства соревнований, которые регулярно проходят в Уральском федеральном университете. Перед участием в онлайн-соревнованиях ознакомьтесь с правилами их проведения.

Сайт создан и поддерживается студентами и выпускниками Уральского федерального университета.

Если вы хотите разместить свои задачи в архиве или провести онлайн-соревнование, напишите по адресу [email protected].

почему на вашем сайте нет банальной задачи А+В?

прошу добавить на этот сайт эту задачу Бюро путешествий

Далеко не все в Тентуре имеют право носить малиновые штаны, и конечно, не все владеют пепелацем с гравицапой, поэтому для большинства жителей проблема перемещения между планетами была неразрешимой. Но с некоторых пор один предприимчивый чатланин с планеты Плюк вышел на рынок пассажирских перевозок, и за немного чатлов, готов перевозить желающих с планеты на планету. Рейс начинается с планеты Плюк, включает нескольких других планет, и завершается там же, на планете Плюк. Однако при подготовке рейса возникли неожиданные проблемы. Например, если чатланин с планеты Плюк хочет попасть на планету, которая является в рейсе предпоследней – ему невольно придётся посетить все планеты, которые находятся в рейсе между планетой Плюк и его точкой назначения. Очевидно, что часть планет в этом списке могут оказаться пацакскими. Но каждый чатланин обязан носить цак на пацакской планете и, наоборот, каждый пацак должен носить цак на чатланской планете. (Цак — колокольчик для носа, знак отличия для относительно низшей касты на данной планете). А процедура ношения цака унизительна во всех смыслах этого слова…

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

Первая строка входного файла содержит натуральное число N ≤ 22 – количество планет, обслуживаемых данным рейсом (не считая планеты Плюк). N следующих строк содержат информацию о планетах, в следующем виде: тип планеты (латинская заглавная буква С – чатланская, P – пацакская), количество чатлан, следующих до этой планеты с Плюка, количество пацаков, следующих до этой планеты с Плюка, количество чатлан, с данной планеты на Плюк, количество пацаков, с данной планеты на Плюк. Всего пассажиров ≤ 1000. Выходные данные

В выходной файл выводится, сколько раз придётся надевать цак при оптимальном маршруте, затем порядок посещения планет через пробел. Планеты, перечисленные во входном файле, нумеруются начиная с единицы, планета Плюк имеет номер ноль и всегда указывается в последовательности дважды – в начале и в конце последовательности. Если существуют несколько оптимальных маршрутов – то следует выбрать тот, где планета с меньшим номером посещается раньше Примеры № пример 1:2 C 1 4 5 2 P 2 5 1 4 ответ примера:5 0 2 1 0 пример2:4 С 3 0 0 0 С 3 0 0 1 С 3 0 0 1 С 3 0 0 1 ответ примера 2:3 0 1 2 3 4 0