Тем кто хоть одну серьезную программу написал посвящается

Если ты в своей жизни хоть раз писали что-то большее «Hallo world», то вероятно уже знаешь, что не всегда просто предусмотреть все.

Например:

Код языка совпадает с кодом страны.
Не всегда. Код страны в Японии — jp. Код языка — ja.

или вот:

У каждого места есть только один официальный адрес.
Однако, в Женеве есть дамба, одна ее часть находится во Франции, другая — в Швейцарии. И у неё два адреса.

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

На гитхабе появился постоянно обновляемый список подобных «мелочей».

Ниже перевод с сайта tproger.ru

Мифы о географии

  1. У одного места может быть только одно официальное название.
    На самом деле, не всегда. «Женева» на разных языках внутри страны пишется так: Genève, Genf, Ginevra.
  2. Топонимы (названия топографических объектов) подчиняются правилам языка.
    И это не так: согласно правилам немецкого языка последовательность «ue»  равна «ü». Это правило существует, потому что «üe» больше не используется в языке. Однако холм за Цюрихом называется «Üetliberg».
  3. У каждого места есть только один официальный адрес.
    Однако, в Женеве есть дамба, одна ее часть находится во Франции, другая — в Швейцарии. И у неё два адреса.
  4. Вы заблуждаетесь, если думаете, что у каждой страны есть столица.
    Например, Швейцария явно решила выделиться — у неё нет столицы. Правительство находится в Берне, но как таковой столицы у них нет.
  5. Здания не двигаются.
    Однако это не так! Ведь в Цюрихе здание весом в 6200 тонн было сдвинуто на 60 метров.
  6. Код языка совпадает с кодом страны.
    Не всегда. Код страны в Японии — jp. Код языка — ja.
  7. Если вы думали, что нумерация зданий не может начинаться с нуля, то вы ошибались.
    Пример: 0 Egmont Road, Middlesbrough, TS4 2HT

Узнать ещё о нескольких мифах можно здесь и здесь.

Мифы об именах

  1. Имена людей записаны в ASCII.
  2. Имя человека не может быть изменено ни при каких обстоятельствах.
  3. Если вы думали, что имена не могут состоять из цифр, то вы, к сожалению, ошибались. Ведь в Москве 14 лет назад родился мальчик, которого назвали БОЧ рВФ 260602.
  4. Приставки и суффиксы в именах можно спокойно игнорировать.
  5. Имена даются людям при рождении.
  6. Люди не могут иметь двойные имена.

Еще несколько мифов можно посмотреть здесь. Читать

Путешествия во времени и программирование

Сейчас о путешествиях во времени пишут не только фантасты. После размышлений античных философов, формул общей теории относительности, моделей червоточин продолжают появляться новые теории, и даже проекты. Многие из них, правда, требуют для своей работы черные дыры, бесконечно длинные цилиндры, материю с отрицательной массой и прочие артефакты. Приближает ли все это нас к созданию машины времени? Об этом трудно говорить предметно, не понимая сути вопроса – что такое время. За несколько веков это понимание увеличилось, на самом деле, незначительно. Быть может с приходом программирования ситуация изменится? Ведь именно там нас ожидают многие ответы.

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

Чему я научился за 30 лет программирования

Оригинальная статья Джона Грэхем-Камминга.
Переведено и опубликовано с разрешения автора.

Я занимаюсь программированием уже более 30 лет, начиная с машин, уже устаревших (на процессорах Z80 и 6502) до современных, используя языки BASIC, ассемблера, C, C++, Tcl, Perl, Lisp, ML, occam, arc, Ruby, Go и многие другие.

Далее следует список того, чему я научился.

0. Програмиирование — это ремесло, а не наука или инженерия

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

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

Принимая во внимание, что это ремесло, нетрудно заметить, что важны опыт, инструменты и интуиция.

Читать

Unix как IDE: Введение

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

Подобные средства есть для всех распространенных настольных ОС, включая Linux и BSD, при этом многие из них совершенно бесплатны, засим вряд ли имеет смысл кодить в Блокноте Windows, в nano, или при помощи cat.

Однако, в среде поклонников Unix гуляет в разнообразных вариациях мем о том, что «Unix — это IDE», в том смысле, что средства, которыми разработчики располагают в терминале, легко реализуют основные возможности современных IDE. Вы можете соглашаться или отказываться назвать Unix «IDE» в том самом смысле, что и Eclipse или Microsoft Visual Studio. Так или иначе, вас скорее всего удивит, насколько законченную среду разработки может являть собой скромный Bash.

Читать

Интервью с Чарльзом Уэзереллом

Сегодня у меня в гостях Чарльз Уэзерелл, автор книги «Этюды для программистов», изданной в 1978 году. До сих пор эта книга остается отличным источником интересных реальных задач из разных областей информатики для студентов, изучающих программирование. Сейчас Чарльз работает в компании Оракл, и любезно согласился рассказать немного о себе и о книге.

Предупреждение: Данная статья является переводом с английского. Я не профессиональный переводчик, поэтому в тексте могут встречаться мелкие неточности. Желающие всегда могут прочитать оригинал на английском.


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


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

С 1974 по 1979 я преподавал в университете UC Davis. Там была новая группа выпускников по специальности «Информатика», призванных составить учебную программу по этому предмету, но в реальности это была просто группа людей из разных факультетов. Департамент прикладных наук нанял меня как первого профессора по этой специальности для создания учебной программы. Вместе с небольшой группой других профессоров и преподавателей мы создали новый учебный план с учетом требований по специальности и начали преподавать новые и переработанные курсы.

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

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

Духи-покровители программиста

За душу программиста сражаются три могущественных духа-покровителя: Художник, Трудяга и Прагматик.

Если вы слышите внутри себя голос: «Ты не можешь рисовать», рисуйте во что бы то ни стало, пока голос не стихнет.

— Винсент ван Гог

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

Читать

Эти бесчисленные парадигмы, концепции, инструменты и фреймворки

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

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

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

Читать

Риальная прога риальных пацанов

	какая_то писька стала посередине; // Целая часть
шняга кагбэ Ленин да стал писька; // Замена минимума
шняга кагбэ ЕБАНУТОСТЬ да стала писька; // Замена максимума

Подкатом полный текст программы 😉
источник

Читать