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

Этим вопросом в одной из своих статей задается один из основателей MIT Media Lab Марвин Минский. Он пытается развеять миф о том, что программа – лишь набор строгих правил и инструкций. Минский пишет: «Это ложное убеждение возникает из-за того, что люди путают форму с содержанием […] Разработчик должен четко следовать синтаксису выбранного языка, но содержание, которое он хочет через него выразить, ничем не ограничивается».

Программа STUDENT, разработанная сотрудником исследовательского центра Пало-Альто Дэниелем Боброу (Daniel Bobrow) еще в 1964 году, решала школьные задачки по алгебре в таком виде:

Маша была в два раза старше Ани, когда Маше было столько лет, сколько сейчас Ане. Если Маше сейчас 24, то сколько лет Ане?

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

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

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

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

Уместно вспомнить теорию Сепира-Уорфа, согласно которой язык, которым мы пользуемся, определяет наше мышление. Эта теория применима и к языкам программирования. Любой язык программирования – это инструмент, и для разных задач мы используем разные инструменты.

Трактор, велосипед и автомобиль Tesla – транспортные средства, но их используют для разных целей. То же и с языками. Ruby и JavaScript идеально подходят для создания сайтов, Java и C++ часто используют для создания торговых алгоритмов, Python и R отлично справляются со статистическими задачами и обработкой информации.

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

Таким образом, особенности языка и в самом деле ограничивают наше мышление. Однако мы сами можем преодолеть эти ограничения. Например, такие выражения в Lisp как «cons», «sexp», «car», «cdr» могут не иметь аналогов в ряде других языков. И все же Lisp дает нам свободу выражения своих идей в рамках этого языка.

В книге Design Patterns хорошо показано, как нужно выражать мысли в C++. Больше половины паттернов из книги отсутствует в Lisp, так как их можно выразить в нем, не меняя структуры языка. Выходит, что языки программирования формируют ход наших мыслей, причем каждый по-своему.

Чтобы в этом убедиться, достаточно написать одну и ту же программу на разных языках и посмотреть, какие они выдадут результаты. Затем перевести программу с одного языка на другой. При том, что выбирать следует значительно отличающиеся друг от друга языки, например, те же Lisp и C++. В итоге вы поймете, что язык выражает не все ваши мысли, но самое главное – это то, что он позволяет оценить, что реализовать легко, а что – сложно.

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

Продолжая тему Python, можно вспомнить написанный на нем открытый проект Django. В 2003 году новостное агентство World Online решило заняться разработкой веб-фреймворка, который бы экономил время работы разработчиков. Два года спустя проект стал открытым. Python хорош тем, что он несложный, а главное – он позволяет разработчику быстро создать рабочий прототип.

Поэтому им часто пользуются в стартапах, а его популярность за последние несколько лет выросла до небес. Среди других продуктов на Python выделяются BitTorrent, MyPait, MoinMoin и другие. Этот язык можно дополнить Javascript, который помогает презентовать свои идеи. В итоге связка Python + Javascript идеально подойдет для реализации и представления любых бизнес-идей, а также их масштабирования.



Бывший сотрудник Microsoft Майк Болодзин в интервью Business Insider рассказывает о важности умения выражать свои мысли. Программисты должны уметь грамотно выражать даже самые обыкновенные идеи в письменной форме (помимо программирования).

Это поможет не только эффективнее общаться с руководством, но и предъявлять права на результаты своей работы. Болодзин вспоминает, как однажды не признали его вклад в работу: «Я спорил, что это моя идея, и знал, что этого не могли не заметить». Более ясная презентация своих идей позволит вам избежать подобных ситуаций.

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

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

В качестве дополнительного чтения по теме – пара наших публикаций на Хабре:

Комментарии (20)


  1. lol_wat
    31.01.2016 15:34
    +14

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


    1. leremin
      31.01.2016 17:18
      +4

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


    1. occam
      31.01.2016 21:04
      +1

      Мне Ваша интерпретация понравилась. Единственное возражение, что «программирование» — itsn the only way. Не слабее по эффективности, помогает по выстраиванию порядка в мыслях также:
      — погружение в системный анализ;
      — вербальное общение с ключевыми людьми отрасли;
      — любые виды общения с людьми, научившимися ранее логично выражать свои мысли ))


  1. pfemidi
    31.01.2016 17:39
    +2

    Чего-то я туплю, никак не могу посчитать сколько же лет Ане :)


    1. pfemidi
      31.01.2016 17:56
      +1

      Нет, или я совсем тупой, или данная задача решений не имеет. Если я совсем тупой, то съем свою шляпу (т.к. шляпы нет, то сначала куплю, а после съем).


    1. Mrrl
      31.01.2016 17:57
      +2

      16 лет. 2*(x-(24-x))=x.


      1. pfemidi
        31.01.2016 18:05
        +8

        Пошёл покупать шляпу…


      1. pfemidi
        31.01.2016 18:44

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


    1. dcc0
      31.01.2016 22:22
      +2

      Кстати, можно в цикле посчитать:
      M=24
      А=x
      Щаг 1
      M-1=23
      A=x-1
      Так как второй аргумент в А не половинка от М то увеличим шаг, ( пропустим шаги цикла )
      M-5=18
      A=x-6
      Опять не половинка :(
      M-2=16
      A=x-8
      16/8=2
      Соответственно ответ: 16


  1. lair
    31.01.2016 19:49
    +2

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

    Серьезно?


  1. TimsTims
    31.01.2016 22:19
    +1

    -Маша была в два раза старше Ани, когда Маше было столько лет, сколько сейчас Ане. Если Маше сейчас 24, то сколько лет Ане?

    Вот только в английском языке слово «Маша» «Маши» «Машу» будет в одном слове «Masha». И «Аня» «Аню» «Ане» — тоже. Поэтому построить такой алгоритм для английского языка было бы заметно проще)) уверен, наши учителя по информатике обязательно придрались бы к таким моментам и заставили делать проги, которые воспринимают все варианты имён, аля «Мария» «Машуня» «Машуля» итд)))


  1. gandjustas
    31.01.2016 22:29
    +7

    Статья называется «Как программирование позволяет логично выражать мысли». Я прочитал. Два раза. Ответа не нашел.

    В конце статьи чувак рассказывает как важно программисту уметь письменно выражать мысли. Дай бог устно бы научиться это делать. И это не сложнее чем писать блог. Вот только блоги пишет 1 из 50 наверное. Которые интересно читать — 1 из 500.

    Бред про языки даже комментировать не хочу.


    1. Blumfontein
      01.02.2016 07:34
      +1

      >> Вот только блоги пишет 1 из 50 наверное. Которые интересно читать — 1 из 500.

      Очень оптимистичные оценки. Еще на 2 порядка ниже.


  1. Wesha
    31.01.2016 22:32
    +2

    • Программирование учит точности формулировок. Компьютеру (в отличие от мужа) нельзя сказать «пойди в этот, ну как его, и принеси ту, которой я вчера это, ну, длинную».
    • Программирование учит предусмотрительности. Компьютеру нельзя сказать «Сходи в магазин и купи хлеба и молока, а если не будет — то сам что-нибудь сообразишь.» Нужно на каждой возможной ветке алгоритма нужно чётко прописать случай «а если не будет». (Программистов, не понимающих этого момента, сразу видно по падающим с Access Violation программам.)
    • Программирование учит решать проблемы, раз и навсегда. Подходы вида «у меня не загружается библиотека… нет, мне не надо, чтобы она загружалась, мне надо просто поговорить об этом» в программировании немыслимы.


    1. gandjustas
      31.01.2016 22:54
      +5

      Вот об этом заблуждении я и хотел написать. Точность формулировок != понятность.
      Попробуйте почитать доказательство теоремы Ферма. Там все формулировки точные. Как что-нибудь поймете — расскажите нам.

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

      Программистская формулировка была бы такая:
      Купи в магазине магнит французский батон, не короче 50 сантиметров
      Во первых не очень понятно зачем. Во вторых что делать если магазин закрыт или если нет именно такого батона.

      И тут возникает вторая проблема:
      Нужно на каждой возможной ветке алгоритма нужно чётко прописать случай «а если не будет».
      Это означает что формулировка становится длинной. А чем длиннее мысль, тем меньше людей её поймут.

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

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


      1. Wesha
        31.01.2016 23:12
        -1

        Точность формулировок != понятность.
        Попробуйте почитать доказательство теоремы Ферма. Там все формулировки точные. Как что-нибудь поймете — расскажите нам.
        Не следует смешивать «понятность вообще» с «понятностью тому, кому надо». Вы же не заставляете первоклассника понимать простейший (для нас с Вами) алгоритм решения квадратного уравнения; зачем Вы заставляете меня понимать формулировку теоремы Ферма?
        пойди в этот, ну как его, и принеси ту, которой я вчера это, ну, длинную
        Это понятно мужу. То есть сообщение идеально сформулировано для целевой аудитории.
        … Вообще-то, когда я придумывал, какое задание для мужа написать, я изобразил в мыслях ситуацию «сходи в санузел и принеси мои щипцы для завивки волос»… Поздравляю, Вы сами же подтвердили мою мысль.
        Это означает что формулировка становится длинной. А чем длиннее мысль, тем меньше людей её поймут.
        Десять коротких мыслей не означают одну длинную. Они означают дерево решений.
        В текстовом виде такое никто читать не будет. А если рассказывать устно, то будет неинтересно.
        Вот поэтому программисты с людьми и предпочитают по мере возможности не общаться:
        vsb: Я программирую, потому что мне нравится программировать, а не потому, что есть возможность меньше контактировать с людьми. Это всего лишь приятный бонус :)


        1. lair
          31.01.2016 23:31
          +4

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

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

          (отдельно, конечно, в вашем высказывании прекрасно деление на «программистов» и «людей»)


    1. lair
      31.01.2016 23:29
      +1

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

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

      (я преувеличиваю, конечно)

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


  1. gandjustas
    31.01.2016 23:41

    Не следует смешивать «понятность вообще» с «понятностью тому, кому надо».

    Точность формулировок понятности не добавляет.

    Вообще-то, когда я придумывал, какое задание для мужа написать, я изобразил в мыслях ситуацию «сходи в санузел и принеси мои щипцы для завивки волос»… Поздравляю, Вы сами же подтвердили мою мысль.
    Какую мысль?
    Что не целевая аудитория не поймет? Это очевидно.
    Как точность формулировок помогает донести мысль до ЦА — неясно.


  1. dcc0
    02.02.2016 09:24
    +1

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

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

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

    P.S.
    Вообще очень просится для Хабра серия статей об истории логики и её связи с алгебрами высказываний и программированием. Можно бы даже с самой древности. Хотелось бы, чтобы не были забыты и отечественные учёные — такие как Н.А. Васильев, Челпанов, Асмус.