Размышления о программировании

    От Аристотеля к Витгенштейну


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

    Предисловие

    Развитие информатики как науки представляется рекой, которая рождается в далеком прошлом (Евклид, III век до н.э.; Вавилон, XIX век до н.э.; а возможно и раньше) из едва заметных ручейков первых алгоритмических вычислений. Неспешно двигаясь по истории, ручейки объединяются в реку, которая, неся свои воды через века, вбирает в себя притоки из смежных дисциплин, накапливает величественность и мощь и, наконец, срывается ниагарским водопадом из второго в третье тысячелетие, превращаясь в стремительный бурлящий поток, который захватывает и несет с собой из прошлого в будущее миллионы людей.



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

    Введение

    «Если ученый не умеет популярно объяснить восьмилетнему ребенку, чем он занимается, значит, он шарлатан»
    Курт Воннегут, «Колыбель для кошки», 1963

    А. «Серебряной пули нет», сказал Ф.Брукс еще в прошлом веке и надолго остудил пыл благородных рыцарей от программирования в борьбе с «Драконом сложности». С тех пор «его Величество Дракон» служит оправданием тому, что пользователям вместо одних плохо работающих программ, навязываются все новые и новые, которые не намного лучше, но пожирают все больше ресурсов процессоров и памяти компьютеров («А что? Пипл хавает!» (с) Б.Титамир). В угоду Дракону выращена целая армия программистов типа «code & fix» («делай и переделывай»): «Не умением, а числом!», «Рефакторинг – наше все!», «Программировать могут даже члены республиканской партии!», написано на их знаменах. Чтобы прокормить Дракона, каждый день они создают гигабайты исходного кода, значительная часть которого никогда не будет востребована пользователями. За прошедшие годы этот отвратительный Дракон разросся и стал «Идеей. Исторической необходимостью. Нашим государственным интересом. Могущественным фактором, оправданием наших объединенных усилий».

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



    В. Мало кто из программистов верит в драконов, зато многие верят в то, что сложность – это понятие субъективное. Одно из определений слова «сложный» — трудный, запутанный. Например, сложная задача, сложная (а может быть точнее — запутанная?) программа. То, что для одного человека является трудным и запутанным, для другого может быть легким и ясным. Движение планет в геоцентрической модели Птолемея по циклам и эпициклам с поправками к ним выглядит сложным. Движение в гелиоцентрической модели по эллипсам Кеплера – простым. Если редактировать изображения в битовом формате, получится сложно, а если в графическом редакторе, то просто. Изображение множества Мандельброта может загипнотизировать своей сложностью непосвященного наблюдателя, но на адекватном языке множество Мандельброта описывается крайне просто: «множество точек с на комплексной плоскости, для которых итеративная последовательность z0=0, zn=zn-12+c (n=1, 2, 3, …) не уходит в бесконечность».

    Г. В природе нет ничего трудного и запутанного. Нечто может только казаться трудным и запутанным человеку, который это нечто пытается понять. Может быть, программные системы, которые мы разрабатываем, мы сами делаем сложными и запутанными? Почему в ERP системе SAP/R3 более 50 тысяч таблиц, а в самом большом словаре русского языка всего примерно 54 тысячи существительных? Я, порой, с сожалением чувствую себя шарлатаном, пытаясь объяснить заказчику, почему так сложно добавить к программе простую функциональность, о которой он просит.

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

    Тезисы


    «Всякая задача становится тривиальной, если ее сформулировать в адекватном языке» И.М.Гельфанд

    О программах

    Программа = задача + модель + алгоритм + структура данных

    Программа создается для того, чтобы решить определенную задачу: обеспечить управление КА при перелете к Фобосу, распознать преступника по фотографии в потоке людей, принять SMS- сообщение с одного мобильного телефона и передать его на другой.

    Модель описывает то, что должна сделать программа для решения поставленной задачи, но не как она это должна сделать. Созданные в мышление человека (ментальные) модели предметной области могут относиться как к явлениям реального мира, например, движение космического объекта в гравитационном поле и атмосфере Земли, так и к идеальным понятиям, таким как интернет-магазин. Модель – это ментальный образ будущего инструмента, который позволит нам решить поставленную задачу.

    Ключевым понятием в определении программы является задача. Как неразумно обсуждать техническую систему в отрыве от задачи, которую она решает, так бессмысленно рассматривать программу вне целей, для которых она создается. Для решения разных задач даже в одной предметной области будут созданы разные модели и разработаны разные программы. Для расчета траекторий межпланетных перелетов достаточно моделировать гравитационное поле как суперпозицию точечных масс Солнца и планет. Для практически приемлемой точности прогнозирования движения спутников на околоземных орбитах в модели гравитации необходимо учитывать неоднородность поля Земли в виде разложения по гармоническим функциям или специально подобранной системе точечных масс. А решение отдельных задач глобальной спутниковой навигационной системы (ГЛОНАСС/GPS) невозможно без привлечения моделей времени и пространства из Общей теории относительности.

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



    Об объектно-ориентированном подходе

    Сегодня для записи программ создано около 2500 языков программирования. История их развития в чем-то схожа с историей развития человеческой речи. Существует мнение, что содержание первых высказываний человека состояло исключительно из требований помощи, которую бы мог оказать ему другой индивид. «Если бы первые высказывания становящегося человека выразить с помощью нашего, развитого языка, они обязательно содержали бы глаголы в повелительном наклонении: “дай!”, “неси!”, “ломай!”, “режь!”, “бей!”, “поднимай!”, “тяни!” и т. п.». Причем эти команды сопровождались жестами, которые точно указывали, к чему конкретно это действие должно быть применено. Ну, очень похоже на команды императивных языков программирования! Например, команды ассемблеров с точным указанием адресов памяти или регистров.

    Человек вначале учится отличать одну практическую ситуацию, взятую в целом, от другой ситуации. Выделение отдельных элементов этих ситуаций (предметов, над которыми совершаются действия, действий, которые совершаются над предметами) осуществляется позже – по мере того как в практической деятельности человек все больше знакомился с окружающими его вещами, познавал их свойства и их отношения друг к другу и к самому человеку. Постепенно человек начинает выделять из конкретной ситуации объект действия (в программировании – данные) и само действие (в программировании — функции). Овладение способностью выделять объекты действия было настоящей революцией в умственном развитии первобытного человека. А это уже очень похоже на объектно-ориентированный подход (ООП), применяемый в программировании. По крайней мере, в его современной реализации в языках: C++, Java, C#.

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

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

    Да, теперь мы уже научились говорить не просто «неси», а «неси дрова» или «неси камень». В своем развитии языки программирования остановились на том, что научились различать объекты (дрова и камень), но не научились выделять действия над ними. И с точки зрения языка программирования men.carry (firewood) и men.carry (stone) будут разными языковыми единицами, если только объекты firewood и stone не имеют общего предка! Просто реализация этими объектами интерфейса «то, что может носить человек» нас не выручит, поскольку это будет две реализации, а, следовательно, и единиц исходного кода тоже будет две.



    Здесь скрыто одно из основных ограничений ООП, которое делает наши программы сложнее, чем они могли бы быть, заставляет нас использовать костыли в виде паттернов проектирования, чтобы компенсировать врожденную хромоту ООП. Когда мы пытаемся определить, подходит ли нам конкретный дизайн программной системы или нет, мы не можем рассматривать данное решение изолированно. Мы должны рассматривать его с точки зрения разумных предположений о том, как будет использоваться данный дизайн в последствие. Если перевести этот тезис на язык «дров» и «камней», то это будет звучать, примерно, так. Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.

    О наследовании

    Другое ограничение ООП заключается в том, что каждый объект принадлежит одной и только одной иерархии ("is а") классов, пусть даже с возможностью множественного наследования и имеет раз и навсегда заданный набор свойств. Например, красная роза — это цветок, а цветок — это растение. Это противоречит реальности, в которой объекты могут эволюционировать, приобретать новые свойства, и утрачивать ранее существовавшие. Например, роза может стать товаром, а потом подарком. Наследником какого класса должна быть роза-подарок? Роза-товар или роза-цветок? Другой пример. Человек рождается с очень ограниченным набором свойств: иметь возраст, вес, рост, пищать, питаться и портить подгузник. Время идет, и он приобретает новые наборы свойств: ученик школы, покупатель, пассажир, солдат, студент, наемный работник, предприниматель, супруг, родитель и т.д. А возможно и не приобретает. Например, не каждый человек служит в армии, учится в вузе, женится и становится отцом или предпринимателем. Или утрачивает. Например, закончил учиться, отслужил в армии или развелся. Следовательно, один и тот же объект должен иметь возможность принадлежать разным классам и этот набор классов должен быть динамическим, т.е. изменяться в ходе эволюции объекта и самой программной системы. На набор классов, к которым относится объект, как правило, накладываются ограничения. Например. Чтобы стать солдатом, человек должен достичь 18 лет. А если человек студент то для того, чтобы стать мужем, необходимо сдать сопромат.



    О сообщениях

    Еще одна странность ООП: «Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений». Но, постойте, если я моделирую столкновение двух автомобилей то, кто из них и какие получает и передает сообщения?



    О свойствах

    «Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств». Но принадлежит ли свойство объекта самому объекту? Буду утверждать, что нет. Например, мы говорим данное яблоко – зеленое. Но что это означает не самом деле? Это значит, что если мы направим источник света, близкого по спектру к солнечному свету, то данное яблоко поглотит все длины волн, кроме тех, которые соответствуют диапазону зеленого цвета, и наблюдатель, который способен воспринимать весь спектр солнечного света увидит только отраженный зеленый свет. Если источник или наблюдатель имеют другой диапазон, например, инфракрасный, то цвет яблока будет черным. Таким образом, свойство не есть неотъемлемая характеристика объекта, а является возможным проявлением объекта при его взаимодействии с другими объектами. Например, свойство предмета «плавать по поверхности» может проявляться во взаимодействии с водой и не проявляться во взаимодействии со спиртом.



    Об агрегации

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



    Об ассоциации

    Если мы говорим, что объект (a) является мужем объекта (b), то мы декларируем что объекты (a и b) связаны ассоциацией. Как же может проявляться эта связь? Во-первых, сама эта связь есть результат взаимодействия трех объектов (a), (b) и объекта (с) (ЗАГС, некий регистратор, где эта связь рождается, и там же она, кстати, может и исчезнуть). Во-вторых, она может проявляться во взаимодействий объектов, например, (a и b): совместное расходование семейного бюджета или рождение и воспитание общего ребенка. Нет смысла спрашивать a.isMarried (b), он может и соврать. Но вполне осмысленна функция isMarried (a, b, c). Следовательно, связи, как и свойства, есть возможные взаимодействия между объектами.



    Об идентичности

    «Идентичность — это такое свойство объекта, которое отличает его от всех других объектов». Что должно соответствовать в действительности этому утверждению? Допустим, я перекрасил свой автомобиль. Для меня он, безусловно, остался тем же самым. Но для ГИБДД это будет совсем другой объект, который получит новый номер государственной регистрации. Другой пример. С автомобиля сняли колеса. Автомобиль остался тем же самым? А если еще и двигатель? А когда автомобиль перестанет быть тем же самым? Идентичность возникает лишь при связывании конкретных объектов. Каждая швабра будет состоять из вполне конкретной щетки и палки. У каждого мужа будет вполне конкретная жена, а у каждого клиента – свой экземпляр счета в банке.



    Итак, в нашем ментальном мире нет объектов и их свойств. А есть структуры и их взаимодействия. Если мы моделируем дорожное движение, то автомобили следует рассматривать как элементарные узлы структуры, которые вступая во взаимодействие (обгоняя, подрезая, тормозя), консистентно изменяют свои координаты в фазовом пространстве (скорость, положение). С другой стороны, автомобили перестают быть элементарными узлам структуры, как только мы начинаем рассматривать их взаимодействие при столкновении. Мы должны перейти на более низкий структурный уровень. На этом уровне элементарными узлами должны быть: бампер, кузов, рама, двигатель и проч. составные части, а также способы их соединения (болты, сварка и т.д.). Сам факт выделения узла структуры есть акт познавательной деятельности (гештальттеория), который зависит от решаемой задачи.

    Об онтологии Людвига Витгенштейна


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

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



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

    О предметно-ориентированном языке (Domain Specific Language, DSL)


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

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

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

    DSL подобно ДНК должен описывать:

    1. сценарии сборки модели из готовых компонентов;
    2. инициализацию начального состояния;
    3. законы эволюции модели во времени.




    Главным строительным блоком языка должно стать взаимодействие, в котором проявляются свойства объектов, изменяются их состояния и рождаются новые экземпляры. Каждый объект в ходе эволюции может быть дополнен новым набором потенциальных взаимодействий и это дополнение не должно затрагивать ранее созданный код. Появление «человека» в мире «камней» и «дров» при таком подходе приведет к созданию нового взаимодействия carry (carrier, thing, space, gravitation);. Элемент carrier должен реализовывать взаимодействия: take (carrier, thing) и move (carrier, thing, space). А элемент thing должен реализовывать взаимодействие: weight (thing, gravitation) и shape (thing, space). В этом случае наша модель действия нести получится достаточно универсальной. Метод не будет меняться от того, что человек реализует взаимодействие take руками, животное — зубами, а подъемный кран — специальным захватом. Поэтому мы сможем легко пополнять нашу программную систему любыми элементами, которые реализуют необходимые взаимодействия для carrier, thing и нам не понадобится менять нашу универсальную функцию. На что это может быть похоже? Возможно, будущий DSL будет похож на Mixin-технологию или Anemic Domain Model (кстати, эту модель Мартин Фаулер назвал антипаттерном), или на «словесное программирование» Д. Кнута, где повествовательное описание взаимодействий будут интерпретироваться в виде алгоритмов и структур данных.



    Выводы

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

    Программирование – это гуманитарная дисциплина и серьезных продвижений в ее теоретическом основании можно добиться лишь, используя достижения гуманитарных наук: философии, психологии, лингвистики, семиотики и др. Но почему-то большинство программистов считают себя именно инженерами, а не лингвистами. Возможно, после прочтения данной публикации, кто-то начнет рассуждать об альтернативном мышлении.
    R-Style 39,40
    Компания
    Поделиться публикацией
    Комментарии 82
    • +6
      Программирование — это инженерная область.
      В разработке ПО еще не открыты свои законы Ньютона, нет уравнений Лагранжа или хотя бы сопромата, которые помогли бы спроектировать и доказать правильность архитектуры новой нетривиальной программной системы.

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

      Помимо ООП есть еще пара подходов, которые вполне решают описанные Вами проблемы: прототипное программирование, например.
      • 0
        Ну, имхо, «прототипное программирование» это одна из реализаций ООП, которая имеет все те же недостатки, о которых я пишу.
        Очень заинтересовало ваше утверждение: «есть огромный слой теории». Можно поподробнее, что именно вы имели в виду?
        • +1
          Про прототипы — Вы можете их расширять в real-time, что решает многие проблемы, описанные в статье. То есть во время выполнения программы, у эмбриона вдруг появился пол и связанные, именно с его полом, характеристики, потом в период созревания он определился с ориентацией, потом нашел партнера и все это сохраняется в его состоянии.

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

          Где-то в ЖЖ проскакивала статья, что должен знать средний программист, список литературы там не помещался на двух экранах. Сейчас попробую найти.
          • 0
            Возможно, вы имели ввиду «теоретический минимум»: sharpc.livejournal.com/67583.html
            Но он не является списком литературы, хотя и содержит некоторые ссылки.
            • 0
              Спасибо, очень похоже.
        • +2
          и мы получаем на выходе поток сознания программиста по структуре напоминающий произведения Тарантино
          Чем вам Тарантино не угодил? По-моему, его «Криминальное Чтиво» — эталон того, как надо делать асинхронные фильмы. Бывает и похуже — бывает код, напоминающий Зеленого Слоника.
          • +1
            Ну когда в одном методе у Вас 4 сюжета, а именно работа с БД, бизнес-логика, формирование ответа клиенту и логирование для статистики + все это перемешано в лучших Тарантиновских традициях, так что рефакторить страшно — да, невольно, проскальзывает ассоциация с Зеленым Слоником.
            • 0
              Не! Тарантиновский код — это когда МНОГО МНОГО МНОГО агрессивных событий, но дух захватывает. И еще комментарии должны быть на чисто матерном языке.
              • 0
                Мда надо написать статью соответствие режиссеров и стилей программирования.
                Боюсь представить, что соответствует функциональному стилю.
                • 0
                  ;) Лет десять назад я уже сравнивал (здесь) режиссеров и руководителей проектов разработки ПО.
        • 0
          Мегабайтная первая картинка в PNG — зачёт! Это какой-то троллинг тех, кто со смартфонов читает?
          • +8
            Предварительный отсев
            • –3
              А что, разве смартфоны не умеют PNG?
              • +6
                В метро они плохо умеют 2MB
                • –1
                  А. А я уже перепугался.
                  • +1
                    И хватит меня минусовать, у меня в жизни не было смартфона, откуда я знаю, как у вас там всё устроено?
            • +3
              Угу, программирование высоконагруженых систем, где оценка математической сложности алгоритмов выполняется чуть ли не постоянно — это чисто гуманитарное занятие.
              • +3
                Но ведь, насколько я понимаю, в этом случае технической является сама проблема, а не язык, с помощью которого она описывается. Например, учебник по физике (справочники, статьи на Вики и так далее) написан на русском языке и именно русский язык используется для описания решения тех или иных задач, но ведь от этого сам русский язык не становится технической дисциплиной.
                • 0
                  Учебник по физике написан на языке формул, которые просто сопровождаются пояснениями на русском языке. Как комментарии к коду.
                  И именно формулами выражается решение тех или иных задач.
                  • +1
                    Привычная нам математическая нотация выработалась только в последние 300 лет, что, несомненно, значительно ускорило развитие математики и сопутствующих технических наук, однако как-то ведь до этого учённые писали своим естественно-математические трактаты без формул? Не было формул — были формулировки, строгие и однозначные, однако со временем становившиеся чрезмерно громоздкими. Например «Квадрат первого, сложенный с квадратом второго и с удвоенным произведением первого на второе, есть квадрат первого, сложенного со вторым». Оперировать с такими формулировками стало неудобно и была изобретена простая и ёмкая символьная нотация, в которой предыдущее утверждение формулировалось как x^2 + 2xy + y^2 = (x + y)^2. Однако это просто сокращённая запись, которая несёт ровно тот же смысл, что и соответствующее утверждение, записанное на русском языке. Формулы — это всего лишь макросы, как в языке C. А учебники и вообще вся литература пишется в первую очередь на языке понятий и образов. И это уже не техническая стезя, а скорей логика и психология.
                    • +2
                      Формулы — это всего лишь макросы, как в языке C

                      Я, если честно, даже не знаю, что вы не понимаете больше: формулы или макросы в С.

                      Вы путаете суть и представление.
                      Если символ «x» в формуле заменить на «икс», а запись "^2" заменить на «в квадрате» — от этого формула формулой быть не перестанет.
                      Однако, говорить, что «Квадрат первого, сложенный с квадратом второго и с удвоенным произведением первого на второе, есть квадрат первого, сложенного со вторым» — это выражение на русском языке, все равно, что утверждать, что программы на Pascal'е написаны на английском.

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

                      Формулы — это не замена «словесного естественного описания».
                      Все совершенно наоборот: до того, как люди сделали язык формул им приходилось описывать естественным языком образы, которые крутились у них в голове.
                      • 0
                        именно формулами выражается решение тех или иных задач

                        Если вы под формулами подразумевали строго сформулированные утверждения, выраженные в словесной либо символьной форме, то я с вами не спорю. Если же вы подразумевали именно символьные выражения, типа F = ma, то мой предыдущий пост вам в ответ.

                        Однако, говорить, что «Квадрат первого, сложенный с квадратом второго и с удвоенным произведением первого на второе, есть квадрат первого, сложенного со вторым» — это выражение на русском языке, все равно, что утверждать, что программы на Pascal'е написаны на английском.

                        Это не совсем точная аналогия. Практически никакая программа на языке Паскаль — да даже на Питоне — не является корректным предложением английской речи. Эти языки просто заимствуют некоторые ключевые слова, наделяя их слегка иной семантикой и сопрягая их по совсем иным синтаксическим правилам. А любая символьная формула, выраженная в словесной форме, является корректным, пусть и специфичным предложением человеческой речи. Я не имею в виду случаи транскрибирования «x = 2y» как «икс равно два игрек», вместо корректного выражения «первое является удвоением второго». Математический язык лишь подмножество языка естественного. И следовательно, естественный язык гораздо богаче математического в плане выразительных средств. Поэтому может быть совсем не лишним обращаться к философии, лингвистике и психологии, если математический язык оказывается неудобен для решения некоторых задач.

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

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

                          На простом примере.
                          Математическая формула: (a+b)*(c-d) = e
                          На русском: Произведение суммы a и b и разности c и d равно e.

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

                          А вот транскрибирование, как раз, к текстовой подстановке, в общем-то, и сводится.
                          Математический язык лишь подмножество языка естественного. И следовательно, естественный язык гораздо богаче математического в плане выразительных средств.

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

                          Математическая аналогия:
                          если у нас есть группа A над одноименным множеством A и A — это подмножество поля B, то это не значит, что в группе A применимы операции поля B.
                          (Расшифровка: у нас есть множество целых чисел, которое является подмножеством вещественных, но это не значит, что вещественное деление можно применять на множестве целых чисел)

                          Прошу прощения за свой mathematish.
                          • 0
                            Спасибо за развёрнутый ответ, здесь я с вами полностью согласен.

                            Однако исходя из чего вы считаете (мне, по крайней мере, так показалось), что задачи программирования сводятся только к математическим задачам, исходя из чего логично следует, что не-математические методологии к ним не применимы?
                            • 0
                              Однако исходя из чего вы считаете (мне, по крайней мере, так показалось), что задачи программирования сводятся только к математическим задачам, исходя из чего логично следует, что не-математические методологии к ним не применимы?

                              Не совсем так. Как я говорил в одном из своих комментариев, программирование — лишь способ решения задач.

                              В зависимости от контекста задачи требуется подключать различные методологии.
                              Где-то явно требуется математика, логика, алгоритмика, физика (написание компиляторов, CAD-систем, 3D-движков).

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

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

                              Комикс в тему.
                              • 0
                                В дополнение к своему комментарию, чтобы был прямой ответ на ваш вопрос: математика (технические познания в целом) нужна далеко не во всех направлениях программирования (для написания сайта, например, не нужна), но требуется умение выражать решение задачи на строгом формальном языке, что является процессом близким к техническим наукам. И, что можно уверенно сказать, программирование нельзя просто взять и отнести к гуманитарному направлению.
                  • +3
                    Центр тяжести технологий программирования уже давно смещается с построения эффективных алгоритмов в сторону построения эффективных моделей предметных областей. ИМХО, сложными математическими алгоритмами (которых нет у Кнута) занимается лишь небольшая когорта избранных (завидую белой завистью!). Но подавляющая часть программистов занимается более прозаическими вещами. И любое новшество с точки зрения более лаконичного отражения логики предметных областей сможет дать ощутимый выигрыш в эффективности нашей индустрии.
                    • +2
                      А вот тут полностью согласен. Проблема в том, чтобы заставить людей думать прежде, чем писать слой модели, но это проблема не языков и фреймворков.
                      • +1
                        Я бы сказал, что программисты смещаются в сторону удобных, а не эффективных методов программирования — ведь действительно зачем писать высоко оптимизированный код, если в каждом телефоне по 2-4 ядра??
                        • +2
                          Концепция «пиши код, который будут читать люди, а не машины» оказалась более выигрышной — вот и все) отсюда и по 2-4 ядра)
                    • +1
                      Рекомендую книгу Криса Партриджа “Business Objects: Re-Engineering for Re-Use”. Она пересекается с затрагиваемыми в статье вопросами. В частности, там содержится критика онтологий по Витгенштейну и автор предлагает собственное решение проблем идентичности и классов.
                      • 0
                        Спасибо за наводку. Про Витгенштейна и программирование, безусловно интересно. Поищу! Странно, что книга не попалась раньше.
                      • –1
                        Нет, ну ладно вам нравиться проводить филологические аналогии, от этого еще вреда не слишком много, но называть программирование гуманитарной дисциплиной это, простите, через чур. Посмотрите определение: «дисциплины, изучающие человека в сфере его духовной, умственной, нравственной, ...» ваш тонкий духовный мир и понятия о нравственности меняются через день, с этим связаны главные особенности гуманитарных дисциплин. Программа завтра не станет иначе работать из-за того, что вы изменили свое мнение о том, как она должна работать, законы там вполне себе естественные и фантазии гуманитариев ничего не способны привнести в эту инженерную дисциплину, не обманывайте себя.
                        • +2
                          Ну, для меня промышленное программирование больше похоже на написание за три месяца романа «Евгений Онегин» командой из двадцати вчерашних студентов под руководством системного архитектора А. Пушкина. Программирование гораздо меньше напоминает создание домов, мостов и космических аппаратов.
                          • 0
                            Мрак и ужас — согласен)
                            Но проблема выше — в тим-лидах, архитекторах, менеджерах, писать на современных языках можно научить даже макаку, а вот следить, чтобы она ничего не ломала… это сложней)
                            • 0
                              А еще в том, что приходится нанимать даже макак на работу ибо нормальных програмистов меньше чем нужно рынку.
                              • 0
                                Это как раз хорошо, значит без работы не останемся.
                                Ситуация, что в ИТ у нас рынок работников, а не работодателей меня полностью устраивает.
                            • 0
                              Найдете серебряную пулю — поделитесь)
                              • 0
                                Как только — так сразу. Обязательно поделюсь.
                              • 0
                                Программирование гораздо меньше напоминает создание домов, мостов и космических аппаратов.

                                Вы участвовали в чем-нибудь таком? Этап проектирования в любых нетиповых вещах не менее косячный и авральный в случае «быстро и дешево».
                                • 0
                                  Ну, 20 лет проработал в ЦУПе. Имел честь участвовать в проектировании того, что летает до сих пор. Так вот, там мы проектировали на основе законов баллистики, аэродинамики, того же сопромата и много еще чего. В программировании похожих законов пока (?) нет. И мы продвигаемся к решению методом проб и ошибок. Поэтому и считаю некорректно сравнивать проектирование ПО и космических аппаратов.
                                  • 0
                                    То, что вы назвали законами — это «правила работы» мира в котором мы работаем.
                                    И они либо есть, либо их нет вообще.
                                    Все остальное — просто выводы из этих «правил».
                                    Причем, даже эти «законы» выводятся из других природных законов. Весь вопрос лишь в том, насколько мы абстрагируемся от устройства этого мира.

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

                                    И проектирование — это не тупое обуздание каких-то законов природы, а комплексное формирование решения для некоторой задачи с учетом нужных ограничений.
                                    Так что проектирование ПО отличается от проектирования космических аппаратов и домов, также как и проектирование космических аппаратов и домов отличается от проектирования автомобилей и мостов.
                                    • 0
                                      По ООП — есть базис по проектированию в виде SOLID, так и математика в виде теории систем, теории множеств и так далее.
                                      По императивщине — есть уже достаточно крепкая база теории, как математики, так и всяких методов по оценке и верификации.
                                      Другие модели программирования изначально строились на базе мат. теорий.

                                      Смутно понимаю какая именно теория вам нужна в дисциплине, которая напрямую родилась из математики.
                                      • 0
                                        Поэтому и считаю некорректно сравнивать проектирование ПО и космических аппаратов.

                                        Я считаю корректным. Я проектировал алгоритм работы космического прибора с учетом оптики, статистики и пары других наук. Окей, напроектировал. Ошибки — все равно переполнение буфера, непроверка инвариантов и несоответствие некоторых характеристик чертежам. Аналогично проектируешь себе КА, сопроматом все насчитал с запасом, а потом отказ из-за косяка при сборке.
                                        Никакой разницы тут нет: в любой созидательной деятельности есть человеческий фактор. Т.е. вы заявляете, что программирование гуманитарно по сути. На самом деле: менеджмент программистов гуманитарен. Так же, как и менеджмент там, где ни строчки кода нет. Если задача стоит «быстро и дешево», от человеческого фактора будет очень много зависеть, но это характеристика любой деятельности, не только программирования.
                                        Отличия программирования только в том, что тут всегда требуется «быстро и дешево». Потому что цена ошибки низкая. Программисты чувствуют себя более расслабленно. Даже Вояджеры умеют перепрошиваться.

                                        Если говорить о научном подспорье, то типизация и есть вещь типа сопромата для программирования. Например, вещи типа boost::units избавляют от большинства ошибок в прикладных расчетах, транзакционная память — от проблем с многопоточностью, и так далее.
                                • +14
                                  Осторожно, эмоции!
                                  Что за херню я только что прочитал?!

                                  Если честно, такое ощущение, что этот текст писался под настроем, вроде «Я не хочу программировать! Я хочу сидеть на подоконнике с чашкой кофе и думать о высоком!»

                                  Вы размышляете о программировании в отрыве от самого программирования. Программирования именно в реальном, а не идеализированном смысле.

                                  Начнем с самого главного. Программирование — это не, !@#$%, язык программирования.
                                  Вы же пишите о программировании в контексте именно языков программирования, потом вообще сводите все к ООП-языкам, которые начинаете связывать с реальной жизнью и, внезапно, выясняется, что модели ООП-языков не совсем соответствуют реальности.
                                  Предикатное, функциональное, процедурное, аспектно и прочее программирование за бортом. Не говоря уже о различных комбинациях.

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

                                  Кроме того, когда вы говорите «программирование», что вы имеет в виду?
                                  Написание сайтов?
                                  Написание web-сервисов?
                                  Написание компиляторов?
                                  Написание драйверов?
                                  Написание операционных систем?
                                  Написание скриптов?
                                  Написание систем для исследования ДНК?
                                  Написание систем, работающих с 3D?

                                  Я могу привести десятки направлений в программировании, которые кардинально отличаются друг от друга.
                                  Некоторые из направлений не получили бы своего развития без огромного математического аппарата за их спиной (компиляторы, 3D-технологии).
                                  Некоторые требуют огромной алгоритмической базы.

                                  Еще эмоции. Простите
                                  Господи, господи! Зачем я это прочитал?! Как вообще можно было такое придумать?!!!


                                  Если же имеется в виду написание алгоритмов, то, простите, я тут тоже не вижу оснований считать программирование гуманитарным направлением.

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

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

                                  В общем, как человек, который последние годы работает в атмосфере наукоемкого программирования, я называю вас Петриком от программирования.
                                  • 0
                                    Есть такой поведенческий паттерн: «Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.» От ответа воздержусь. Но вопрос задать очень хочется. Что такое «атмосфера наукоемкого программирования»? Просветите?
                                    • +2
                                      Написание оптимизирующего компилятора. Или сборщика мусора. Как самые яркие примеры.
                                      И кроме этого много низкоуровневого программирования, работы с ОС, мелких точеченых оптимизаций на ассемблере, где чистой научной ценности не так много.

                                      И где в этом программировании гуманитарная составляющая?
                                      • –1
                                        Заметь, ты приводишь в основном примеры системного программирования = программирования для программистов, если хочешь. Мне кажется, что программист-космонавт Чарльз Симони был совершенно прав, когда говорил: «programmers become unwitting cryptographers». Системное программирование не создает пользовательской ценности, а лишь облегчает (всегда ли?) ее создание для прикладных программистов.
                                        • +8
                                          Я привел эти примеры, потому что раскрывал ту самую «атмосферу наукоемкого программирования», в которой я обитаю.

                                          Если они не устраивают, то могу привести в пример знакомых, работающих по соседству, занимающихся CAD-системами. Где у них гуманитарная составляющая?

                                          У создателей Photoshop'а, наверное, тоже никакой математики не было.
                                          Аудио-видео кодеки?
                                          Создатели игровых 3d-движков?

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

                                          Эта цитата хорошо характеризует ваши представления о системном программировании в целом.
                                          Наверное, фотошопы и CAD'ы тоже не несут пользовательской ценности — они облегчают ее создание для фотографов и архитекторов.
                                          3Ds Max и Maya ьлже не несут пользовательской ценности… Sony Vegas Studio… Word и Excel'и… ваши примеры?
                                          • 0
                                            3Ds Max и Maya ьлже не несут пользовательской ценности… Sony Vegas Studio… Word и Excel'и


                                            Это, как раз, и есть прикладное программирование, о котором я писал в своем посте. Более того я утверждал, что за системами, подобными CAD, — будущее.
                                            • 0
                                              И мой тезис заключается именно в том, что нельзя откидывать пользовательскую ценность системного программирования, только потому, что в данном случае пользователями являются другие программисты.
                                      • +2
                                        Чтобы мои претензии были яснее, предоставлю такой тезис:
                                        Программирование — это не наука и не дисциплина.
                                        Программирование — это способ решения задач с помощью создания программ в широком смысле (скриптов, сайтов, сервисов, приложений).

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

                                        Тем не менее, даже разработкой языков программирования занимаются не гуманитарии, а ученые, математики, т.к. создание формального языка является, по сути, математической задачей, т.к. его будет компилировать программа, работающая на компьютере, который работает по строгой модели, основанной на, опять же, математической модели.
                                      • +5
                                        К сожалению, не хватает кармы для использования тэгов в комментариях, поэтому:
                                        Цитата:
                                        Если честно, такое ощущение, что этот текст писался под настроем, вроде: Я не хочу программировать! Я хочу сидеть на подоконнике с чашкой кофе и думать о высоком!

                                        Конец цитаты.

                                        Вы забыли о пледике и дожде, нельзя сидеть на подоконнике думать о чем-то, если не идет дождь и ты не укутан в пледик :) *сарказм*
                                        • +2
                                          Да, где-то и у меня такие эмоции.
                                          Языки программирования — это всего-лишь языки и никому ничего не должны. Для каких-то задач отлично подходит запись системы уравнений, для других дифуры, для третьих С#. Язык еще один придумать не проблема. Проблема на нем писать. ООП простое, поэтому сравнительно легко писать. Какой-то динамический язык с динамическим наследованием и перенаследованием — только звучит необычно, а писать на нем будет жесть наверное.

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

                                          Видимо, идеальный язык — это идеальный ИИ, который умеет и на естественном поговорить, и понять языки формул и вообще, давать наводящие вопросы, уточняя задание. Т.е. не язык, а интеллект, близкий к человеческому (хотя бы на уровне интерфейса с человеком), который может понять максимально близко, что человек хочет. Правда, когда такой ИИ будет, непонятно, зачем нужен человек. Оно и само будет не хуже принимать решения. И вероятность ошибки при передаче информации «человек-машина» всегда есть. А без человека не будет.

                                          Так что радуемся, что есть пока у нас работа )
                                        • +3
                                          > Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по
                                          > совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится
                                          > созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет
                                          > перетаскивать.

                                          Это не так. См. принцип инверсии зависимостей.

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

                                          Ну так и смотрите на любой динамический язык и с исходным пониманием ООП (Smalltalk, Ruby и даже в какой-то степени JavaScript). Там все так как вам и нужно.

                                          > Еще одна странность ООП: «Поведение — это то, как объект действует и реагирует; поведение выражается в > терминах состояния объекта и передачи сообщений». Но, постойте, если я моделирую столкновение двух
                                          > автомобилей то, кто из них и какие получает и передает сообщения?

                                          Никаких странностей, см. классическое определение информации по Шеннону.

                                          > «Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и
                                          > текущими (обычно динамическими) значениями каждого из этих свойств». Но принадлежит ли свойство
                                          > объекта самому объекту? Буду утверждать, что нет. Например, мы говорим данное яблоко – зеленое. Но что
                                          > это означает не самом деле?

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

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

                                          > Итак, в нашем ментальном мире нет объектов и их свойств. А есть структуры и их взаимодействия. Если мы
                                          > моделируем дорожное движение, то автомобили следует рассматривать как элементарные узлы структуры,
                                          > которые вступая во взаимодействие (обгоняя, подрезая, тормозя), консистентно изменяют свои координаты
                                          > в фазовом пространстве (скорость, положение).

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

                                          > Попытки создания универсального синтаксиса DSL предпринимались не раз.

                                          DSL по определению не может быть универсальным. Что вытекает из расшифровки самой аббревиатуры. Весь раздел, соответственно, не про DSL, а про язык описания семантики (каковых было много, и самый известный — ПРОЛОГ, который внезапно очень похож на ваши примеры на картинках).

                                          > Возможно, будущий DSL будет похож на Mixin-технологию или Anemic Domain Model

                                          Что общего между вороной и письменным столом?

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

                                          Да ради бога! Гугл «формальная верификация».

                                          UPD Простите, но ужасно похоже на творчество «научных фриков». Надерганные термины, без понимания смысла и полноценного анализа, зато с кучей выводов.
                                          • –2
                                            Сожалею, но многого не понял. Готовы пояснить хотя бы вот это:

                                            > Еще одна странность ООП: «Поведение — это то, как объект действует и реагирует; поведение выражается в > терминах состояния объекта и передачи сообщений». Но, постойте, если я моделирую столкновение двух
                                            > автомобилей то, кто из них и какие получает и передает сообщения?

                                            Никаких странностей, см. классическое определение информации по Шеннону.


                                            Какая связь краш-теста и определения информации по Шеннону? И почему определение, например, не по Винеру?
                                            • +2
                                              Шеннон связал количество информации и информационную энтропию с термодинамической, показав, что любое взаимодействие объектов приводит к изменению состояния объектов и передаче соответствующей информации от одного объекта к другому.
                                              Таким образом, в теории информации взаимодействие объектов рассматривается, как изменение состояния объектов в результате передачи некоторой информации от одного объекта к другому.

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

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

                                              UPD Отсюда — ООПшные сообщения и инкапсуляция, как запрет изменения свойств объекта любыми способами кроме посылки ему сообщения.
                                              Потом «посылка сообщения» превратилась в «вызов метода» не поменяв сути.
                                              • 0
                                                Упс, круто завернул!

                                                «Бросая в воду камешки, смотри на круги, ими образуемые...» ( (с) Козьма Прутков) — это тоже про обмен информацией?

                                                А, ничего что, Шеннон писал применительно к техническим системам, лишь о сигналах и связи, да еще при этом сам указывал, что информация, которая передается этими сигналами, его не интересует. А ты говоришь, что он ее определял.
                                                • +2
                                                  Да, конечно. И под «определением информации по Шеннону», я конечно же имею ввиду определение «количества информации» и Шенноновскую математику вокруг этого определения.

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

                                                  • 0
                                                    Количество информации по Шеннону это мера пропускной способности канала связи. К самой информации формула Шеннона отношения не имеет. Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
                                                    Еще раз, космический аппарат, двигаясь в гравитационном поле, никому никаких сообщений не посылает и не принимает. И его имитационные модели, кстати, тоже.
                                                    • +2
                                                      > Количество информации по Шеннону это мера пропускной способности канала связи.
                                                      > К самой информации формула Шеннона отношения не имеет.

                                                      А термин информация по Шеннону (и Винеру, кстати) бессмысленен без возможности ее передачи.
                                                      Тем более, что это не сильно важно, так как я в первую очередь пытаюсь объяснить откуда в ООП взялась абстракция «сообщение», а не правильно определить термин «информация» (это хоть у кого-нибудь получилось? ИМХО, та же фигня, что с термином «время»).

                                                      > Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
                                                      Ни в каком. Потому что и то и другое, представляет собой то что в философии науки называют «знание» и измеримыми сущностями они не являются (опять же по Шеннону), хотя включает в себя некий набор информации.
                                                      А вот если мы говорим о законах, как о неких мат. моделях, которые можно закодировать на некотором формальном языке и куда-то передать — то вот тут уже можно что-то измерить.

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

                                                      Ключевое словосочетание — «гравитационное поле».

                                                      > И его имитационные модели, кстати, тоже.

                                                      А смотря что за имитационная модель. Если аналитическая — то да, никаких сообщений там нет.
                                                      А если событийное — то вам никто не мешает завести объект КА, объект «гравитационное поле» и моделировать взаимодействие через обмен сообщениями.
                                                      • 0
                                                        > Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
                                                        Ни в каком. Потому что и то и другое, представляет собой то что в философии науки называют «знание» и измеримыми сущностями они не являются (опять же по Шеннону), хотя включает в себя некий набор информации.
                                                        А вот если мы говорим о законах, как о неких мат. моделях, которые можно закодировать на некотором формальном языке и куда-то передать — то вот тут уже можно что-то измерить.


                                                        Информация, знания, данные… Это очень интересная тема. Думаю заслуживает отдельного поста. Как нибудь соберусь с силами и напишу. Там и продолжим обсуждение.
                                                        • 0
                                                          Да, было бы интересно :)
                                          • +2
                                            Молоток. Молоток весьма ограниченный инструмент. Им можно только забивать гвозди и ничего более. Если, скажем, мы возьмем задачу нанесения антибликовой поверхности на экран LCD дисплея, то молоток не справится с этой задачей. Также использование молотка весьма неочевидно, так как новички при первом использовании чаще всего пытаются взяться ближе к ударной части, хотя на самом деле это неправильно. Стоит ли говорить, что молоток это древнейший инструмент и в наш развитой век он морально устарел.
                                            • 0
                                              Открываем новую неделю «ООП — зло» на хабре?
                                              • +3
                                                Автор, вы исходите из (неуказанной) посылки, что программирование в том или ином виде стремится отобразить ментальную модель реальности человека?

                                                И сетуете на недостаток «выразительных средств», упирая на ограниченность ООП-языков (если правильно понимаю вашу статью)?

                                                Немного непонятна ваша печаль, если честно.

                                                Таких целей ведь никто и не ставит. Компьютер не должен стать человеком, это инструмент.

                                                Многие из трудностей, которые вы упоминаете, вроде как проработаны уже.

                                                Взять тот же JavaScript. Любой объект можно наделить любым набором свойств и поведений. И даже без наследования.

                                                • 0
                                                  Интересный взгляд на языки программирования.
                                                  Чем-то перекликается с моим Развитие пользовательских типов данных в программировании

                                                  Однако, выводы разнятся.
                                                  Я бы не сказал, что развитие DSL языков будет решением проблем. Имхо, это перекладывание проблем с одних плеч(базового языка программирования) на другие (DSL-языки). А их тоже надо как-то развивать. Сейчас ведь тоже многие DSL-языки находятся на уровне ассемблера — можно только пользоваться встроенными командами.
                                                  • 0
                                                    Ну DSL — это всего лишь способ не думать о мелочах. Оперировать понятиями более высокого уровня, созданными уже программистом.
                                                    Можно, конечно, возразить что и на базовом языке все то же самое можно сделать. Но в базовом нельзя или очень сложно удалить из языка все не нужные для данной задачи конструкции.
                                                    • +1
                                                      Безусловно, DSL — всего лишь способ не думать о мелочах.
                                                      Эллочке-людоедке хватило 30 слов, что бы общаться. Это и есть DSL
                                                      Но для того, что бы общаться нормально, всё равно придётся выучить язык поболе.
                                                      • 0
                                                        Чтобы общаться — да.
                                                        Но чтобы дело делать — это лишнее. Только путаница для всех участвующих.
                                                        Когда надо быстро и точно то хватает пару десятков слов-приказов. Причем в каждой области — своих.
                                                  • 0
                                                    Каждый объект в ходе эволюции может быть дополнен новым набором потенциальных взаимодействий

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

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

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

                                                    Склеить(объект1, объект2, объект3), а не объект1.Склеить(объект2)
                                                    • 0
                                                      Если сравнивать с обычным миром, то лучше присмотреться к реализации взаимодействия в играх. Столкновения, взрывы, падения и т.п


                                                      Да, именно в играх активно развивается Anemic Domain Model, о которой я упоминал
                                                    • 0
                                                      Так ведь программы это и есть те самые DS-языки, которые предоставляют пользователям удобные для их сферы абстракции. Только не всегда DSL должны быть представлены в виде текста, но ведь в некоторых областях эффективны другие способы «программировать»: для дизайнера удобнее крутить ручки в Photoshop, для инженера удобнее строить 3D-модель с помощью мыши и т.д.
                                                      А «настоящие» программисты как раз и создают эти DSL с помощью языков общего назначения, облегчая решение задач для «ненастоящих» программистов, однако и те, и другие занимаются программированием (т.е. алгоритмизацией).
                                                      • 0
                                                        Если ты просто делашь удобный API, то есть конечный набор вызвов и схем, это понятно как настоящему программисту, так и ненастоящему. Конкретные вызовы API как раз таки можно выводить на ручки, контролы и прочий мышиный ввод. А синтаксис самого языка можно почерпнуть из справочника, 5-минутного курса и т.п.

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

                                                        Тем более зачем продвинутому пользователю какой-то изощренный синтаксис, скаляры, списочные структуры, ветвления по условию, переборы и внешние вызовы. Зачем к этому всему что-то еще?
                                                        • 0
                                                          Я не говорил, что пользователь CAD системы что-то должен писать на DSL. ИМХО, у пользователя должен быть графический редактор с набором готовых компонентов, из которых он конструирует решение своей задачи. А вот из того, что он сконструирует, должен генерироваться код на DSL. Где-то так…
                                                          • +1
                                                            Вообще-то, то, что вы описываете, называется графический DSL. И, как показала практика, работает плохо.
                                                      • 0
                                                        Читал с интересом и все ждал, когда на сцену выйдут системы фактов, EAV и т.п. и они, к большому удивлению, таки вышли.

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

                                                        Вместо этого выполз DSL и на этом этапе автор сам запутался

                                                        >законы эволюции модели во времени.
                                                        У него же там вроде модели через отношения определяются. Значит не может быть эволюции модели как таковой, может быть эволюция отношений.
                                                        • 0
                                                          Парадокс — в школе и в универе хорошо шли точные науки, а из рук плохо — гуманитарные, но стал программистом (по отзывам коллег и начальства — неплохим) и судя по Вашей статье — я все же гуманитарий… это как же так получается :) гуманитарием никогда не был — не давалось оно мне, а оказывается я уже много лет Гуманитарий со стажем :-)
                                                          Вот Вы явно не в своей тарелке — по образу мыслей философ, а в профиле:
                                                          О себе: Эксперт. Проектирование и разработка программного обеспечения
                                                          Может не тем занимаетесь? :-)
                                                          • 0
                                                            Вот Вы явно не в своей тарелке — по образу мыслей философ, а в профиле:
                                                            О себе: Эксперт. Проектирование и разработка программного обеспечения
                                                            Может не тем занимаетесь? :-)


                                                            Просто всему — свое время. «Время разбрасывать камни, и время собирать».

                                                            Если бы нас в свое время учили философии (не только марксистко-ленинской), психологии, лингвистике, семиотике, мне кажется, мы могли бы более эффективно проектировать и разрабатывать ПО. Но нас учили, ТФКП, функциональному анализу, квантовой механике и много-много чему еще. Все это было очень интересно, но, к сожалению, в моей программистской карьере не пригодилось :(
                                                          • 0
                                                            > Развитие информатики как науки представляется рекой, которая рождается в далеком прошлом (Евклид, III век до н.э.
                                                            А я уж было подумал, что это цитата!
                                                            • 0
                                                              Уже давно существует и используется компонентно-ориентированное программирование.
                                                              Прочитайте доходчивую и красочную презентацию с канадской конференции разработчиков игр 2009 года, описывающую эту технологию.
                                                              Объект в компонентно-ориентированном подходе представляет из себя мешок из атрибутов и поведений (Behaviours). Поведение как раз и реализует возможность взаимодействия одного объекта с другими и влияет на его атрибуты.
                                                              Мало того, существует рабочая среда наполовину визуальной разработки игр Unity. Например, вы можете создать объкт, добавить в него физическую модель — сферу, привязать камеру и добавить поведение «управление с клавиатуры» — всё, главный герой готов.
                                                              Так что в данном случае именно разработка игр стимулировала развитие архитектуры ПО, потому что сложилось так, что именно в виртуальных игровых мирах возникали самые сложные и неклассифицируемые в диаграмму классов «с наследованием» виды объектов.
                                                              • 0
                                                                Спасибо за информацию! Просмотрел презентацию — очень похоже на то, о чем я написал в посте. Буду изучать внимательнее. Разработкой игр не занимался, но десять лет разрабатывал имитационные модели сложных систем — тысячи объектов с десятками компонентов в каждом. Мои идеи зародились именно при разработке этих моделей.

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

                                                              Самое читаемое