Comments 82
Программирование — это инженерная область.
Это спорное утверждение — есть огромный слой теории + вытекающие из них паттерны, применяя которые Вы получите грамотный, хорошо читаемый и поддерживаемый код. Тот факт, что хороший код приносят в жертву бизнес целям (часто сомнительным) и мы получаем на выходе поток сознания программиста по структуре напоминающий произведения Тарантино не превращает ее в гуманитарную науку, из контрольных школьников тоже можно сделать вывод, что математика и физика чисто гуманитарные дисциплины.
Помимо ООП есть еще пара подходов, которые вполне решают описанные Вами проблемы: прототипное программирование, например.
В разработке ПО еще не открыты свои законы Ньютона, нет уравнений Лагранжа или хотя бы сопромата, которые помогли бы спроектировать и доказать правильность архитектуры новой нетривиальной программной системы.
Это спорное утверждение — есть огромный слой теории + вытекающие из них паттерны, применяя которые Вы получите грамотный, хорошо читаемый и поддерживаемый код. Тот факт, что хороший код приносят в жертву бизнес целям (часто сомнительным) и мы получаем на выходе поток сознания программиста по структуре напоминающий произведения Тарантино не превращает ее в гуманитарную науку, из контрольных школьников тоже можно сделать вывод, что математика и физика чисто гуманитарные дисциплины.
Помимо ООП есть еще пара подходов, которые вполне решают описанные Вами проблемы: прототипное программирование, например.
Ну, имхо, «прототипное программирование» это одна из реализаций ООП, которая имеет все те же недостатки, о которых я пишу.
Очень заинтересовало ваше утверждение: «есть огромный слой теории». Можно поподробнее, что именно вы имели в виду?
Очень заинтересовало ваше утверждение: «есть огромный слой теории». Можно поподробнее, что именно вы имели в виду?
Про прототипы — Вы можете их расширять в real-time, что решает многие проблемы, описанные в статье. То есть во время выполнения программы, у эмбриона вдруг появился пол и связанные, именно с его полом, характеристики, потом в период созревания он определился с ориентацией, потом нашел партнера и все это сохраняется в его состоянии.
Про теорию, я не буду касаться алгоритмов, но для решения определенного класса задач есть общепризнанные паттерны, например мы понимаем, что у нас будет трехзвенка и из этого тут же следует, что на сервере будет слой DAO объектов, а из SOLID вытекает, что мы предоставляем к нему доступ через интерфейсы, реализация же методов может плыть и зависит от квалификации программистов, но структура уже более-менее вырисовывается. Аналогично и на клиенте.
По большей части это справедливо для 99% задач, с которым мы сталкиваемся и гуманитарная отмазка — «я так вижу» — тут не прокатит, всегда после нее хочется услышать, я отступил от общих принципов для того, чтобы… и тут уже можно спорить не в субъективных терминах, а объективных — подобный подход быстрей реализуется, быстрей работает итд, далее необходимо отталкиваться от сформулированных требований.
Где-то в ЖЖ проскакивала статья, что должен знать средний программист, список литературы там не помещался на двух экранах. Сейчас попробую найти.
Про теорию, я не буду касаться алгоритмов, но для решения определенного класса задач есть общепризнанные паттерны, например мы понимаем, что у нас будет трехзвенка и из этого тут же следует, что на сервере будет слой DAO объектов, а из SOLID вытекает, что мы предоставляем к нему доступ через интерфейсы, реализация же методов может плыть и зависит от квалификации программистов, но структура уже более-менее вырисовывается. Аналогично и на клиенте.
По большей части это справедливо для 99% задач, с которым мы сталкиваемся и гуманитарная отмазка — «я так вижу» — тут не прокатит, всегда после нее хочется услышать, я отступил от общих принципов для того, чтобы… и тут уже можно спорить не в субъективных терминах, а объективных — подобный подход быстрей реализуется, быстрей работает итд, далее необходимо отталкиваться от сформулированных требований.
Где-то в ЖЖ проскакивала статья, что должен знать средний программист, список литературы там не помещался на двух экранах. Сейчас попробую найти.
Возможно, вы имели ввиду «теоретический минимум»: sharpc.livejournal.com/67583.html
Но он не является списком литературы, хотя и содержит некоторые ссылки.
Но он не является списком литературы, хотя и содержит некоторые ссылки.
UFO just landed and posted this here
Ну когда в одном методе у Вас 4 сюжета, а именно работа с БД, бизнес-логика, формирование ответа клиенту и логирование для статистики + все это перемешано в лучших Тарантиновских традициях, так что рефакторить страшно — да, невольно, проскальзывает ассоциация с Зеленым Слоником.
UFO just landed and posted this here
Мда надо написать статью соответствие режиссеров и стилей программирования.
Боюсь представить, что соответствует функциональному стилю.
Боюсь представить, что соответствует функциональному стилю.
;) Лет десять назад я уже сравнивал (здесь) режиссеров и руководителей проектов разработки ПО.
Мегабайтная первая картинка в PNG — зачёт! Это какой-то троллинг тех, кто со смартфонов читает?
Угу, программирование высоконагруженых систем, где оценка математической сложности алгоритмов выполняется чуть ли не постоянно — это чисто гуманитарное занятие.
UFO just landed and posted this here
Учебник по физике написан на языке формул, которые просто сопровождаются пояснениями на русском языке. Как комментарии к коду.
И именно формулами выражается решение тех или иных задач.
И именно формулами выражается решение тех или иных задач.
Привычная нам математическая нотация выработалась только в последние 300 лет, что, несомненно, значительно ускорило развитие математики и сопутствующих технических наук, однако как-то ведь до этого учённые писали своим естественно-математические трактаты без формул? Не было формул — были формулировки, строгие и однозначные, однако со временем становившиеся чрезмерно громоздкими. Например «Квадрат первого, сложенный с квадратом второго и с удвоенным произведением первого на второе, есть квадрат первого, сложенного со вторым». Оперировать с такими формулировками стало неудобно и была изобретена простая и ёмкая символьная нотация, в которой предыдущее утверждение формулировалось как x^2 + 2xy + y^2 = (x + y)^2. Однако это просто сокращённая запись, которая несёт ровно тот же смысл, что и соответствующее утверждение, записанное на русском языке. Формулы — это всего лишь макросы, как в языке C. А учебники и вообще вся литература пишется в первую очередь на языке понятий и образов. И это уже не техническая стезя, а скорей логика и психология.
Формулы — это всего лишь макросы, как в языке C
Я, если честно, даже не знаю, что вы не понимаете больше: формулы или макросы в С.
Вы путаете суть и представление.
Если символ «x» в формуле заменить на «икс», а запись "^2" заменить на «в квадрате» — от этого формула формулой быть не перестанет.
Однако, говорить, что «Квадрат первого, сложенный с квадратом второго и с удвоенным произведением первого на второе, есть квадрат первого, сложенного со вторым» — это выражение на русском языке, все равно, что утверждать, что программы на Pascal'е написаны на английском.
Формулы пишутся на определенном формальном языке. Именно языке, т.к. он обладает синтаксисом, семантикой и пр. Эти формулы, конечно, можно выражать, используя слова из естественного языка, но для формализации все равно потребовалось бы использовать подмножество языка с наложенными дополнительными правилами.
Формулы — это не замена «словесного естественного описания».
Все совершенно наоборот: до того, как люди сделали язык формул им приходилось описывать естественным языком образы, которые крутились у них в голове.
именно формулами выражается решение тех или иных задач
Если вы под формулами подразумевали строго сформулированные утверждения, выраженные в словесной либо символьной форме, то я с вами не спорю. Если же вы подразумевали именно символьные выражения, типа F = ma, то мой предыдущий пост вам в ответ.
Однако, говорить, что «Квадрат первого, сложенный с квадратом второго и с удвоенным произведением первого на второе, есть квадрат первого, сложенного со вторым» — это выражение на русском языке, все равно, что утверждать, что программы на Pascal'е написаны на английском.
Это не совсем точная аналогия. Практически никакая программа на языке Паскаль — да даже на Питоне — не является корректным предложением английской речи. Эти языки просто заимствуют некоторые ключевые слова, наделяя их слегка иной семантикой и сопрягая их по совсем иным синтаксическим правилам. А любая символьная формула, выраженная в словесной форме, является корректным, пусть и специфичным предложением человеческой речи. Я не имею в виду случаи транскрибирования «x = 2y» как «икс равно два игрек», вместо корректного выражения «первое является удвоением второго». Математический язык лишь подмножество языка естественного. И следовательно, естественный язык гораздо богаче математического в плане выразительных средств. Поэтому может быть совсем не лишним обращаться к философии, лингвистике и психологии, если математический язык оказывается неудобен для решения некоторых задач.
Мне, кстати, было бы любопытно прочесть вашу иллюстрацию того, в чём заключается принципиальное отличие разворачивания в сознании символьных формул в понятийные, скажем так, формулы от макроподстановки в языке Си.
Мне, кстати, было бы любопытно прочесть вашу иллюстрацию того, в чём заключается принципиальное отличие разворачивания в сознании символьных формул в понятийные, скажем так, формулы от макроподстановки в языке Си.
Именно тем, что макросы в С — это именно примитивная текстовая подстановка.
В то время как разворачивание формул (например, математических) в предложения на естесственном языке — это процесс трансляции, который требует, как минимум, структурного разбора формулы, создания внутреннего представления (которое, по сути, является абстрактным представлением формулы в голове) и дальнейшего преобразования внутреннего представления в предложение на естественном языке.
В другую сторону аналогично.
На простом примере.
Математическая формула: (a+b)*(c-d) = e
На русском: Произведение суммы a и b и разности c и d равно e.
Как можно заметить, часть предложения слева от слова «равно» напоминает польскую нотацию.
Банальной текстовой подстановкой, на уровне Сишных макросов, вы подобных преобразований (польская нотация <-> инфиксная) не добьетесь.
А вот транскрибирование, как раз, к текстовой подстановке, в общем-то, и сводится.
Математический язык лишь подмножество языка естественного. И следовательно, естественный язык гораздо богаче математического в плане выразительных средств.
Простите, но естественный язык на то и естественный язык — он по умолчанию предназначен для того, чтобы описывать вообще все, что только возможно.
В то время, как математический язык был предназначен для описания математической модели.
И, собственно, математические задачи можно решать только математическим языком.
То, что есть отображение из этого языка в естественный вовсе не означает, что методологии наук, работающих с естественным языком, можно применять на математическом.
Математическая аналогия:
если у нас есть группа A над одноименным множеством A и A — это подмножество поля B, то это не значит, что в группе A применимы операции поля B.
(Расшифровка: у нас есть множество целых чисел, которое является подмножеством вещественных, но это не значит, что вещественное деление можно применять на множестве целых чисел)
Прошу прощения за свой mathematish.
Спасибо за развёрнутый ответ, здесь я с вами полностью согласен.
Однако исходя из чего вы считаете (мне, по крайней мере, так показалось), что задачи программирования сводятся только к математическим задачам, исходя из чего логично следует, что не-математические методологии к ним не применимы?
Однако исходя из чего вы считаете (мне, по крайней мере, так показалось), что задачи программирования сводятся только к математическим задачам, исходя из чего логично следует, что не-математические методологии к ним не применимы?
Однако исходя из чего вы считаете (мне, по крайней мере, так показалось), что задачи программирования сводятся только к математическим задачам, исходя из чего логично следует, что не-математические методологии к ним не применимы?
Не совсем так. Как я говорил в одном из своих комментариев, программирование — лишь способ решения задач.
В зависимости от контекста задачи требуется подключать различные методологии.
Где-то явно требуется математика, логика, алгоритмика, физика (написание компиляторов, CAD-систем, 3D-движков).
А где-то, например при создании автоматического переводчика, требуются какие-то гуманитарные методологии. Но это лишь на самом верхнем уровне абстракции, т.к. в итоге все будет сведено к написанию программы на формальном языке программирования, работающем на детерминированной системе.
И мы лишь можем выбирать между прямым решением (собственно, строгие алгоритмы) или косвенным (генетические алгоритмы, нейронные сети), которое тоже сводится, в некотором смысле, к математике.
Комикс в тему.
В дополнение к своему комментарию, чтобы был прямой ответ на ваш вопрос: математика (технические познания в целом) нужна далеко не во всех направлениях программирования (для написания сайта, например, не нужна), но требуется умение выражать решение задачи на строгом формальном языке, что является процессом близким к техническим наукам. И, что можно уверенно сказать, программирование нельзя просто взять и отнести к гуманитарному направлению.
Центр тяжести технологий программирования уже давно смещается с построения эффективных алгоритмов в сторону построения эффективных моделей предметных областей. ИМХО, сложными математическими алгоритмами (которых нет у Кнута) занимается лишь небольшая когорта избранных (завидую белой завистью!). Но подавляющая часть программистов занимается более прозаическими вещами. И любое новшество с точки зрения более лаконичного отражения логики предметных областей сможет дать ощутимый выигрыш в эффективности нашей индустрии.
А вот тут полностью согласен. Проблема в том, чтобы заставить людей думать прежде, чем писать слой модели, но это проблема не языков и фреймворков.
Я бы сказал, что программисты смещаются в сторону удобных, а не эффективных методов программирования — ведь действительно зачем писать высоко оптимизированный код, если в каждом телефоне по 2-4 ядра??
Рекомендую книгу Криса Партриджа “Business Objects: Re-Engineering for Re-Use”. Она пересекается с затрагиваемыми в статье вопросами. В частности, там содержится критика онтологий по Витгенштейну и автор предлагает собственное решение проблем идентичности и классов.
Нет, ну ладно вам нравиться проводить филологические аналогии, от этого еще вреда не слишком много, но называть программирование гуманитарной дисциплиной это, простите, через чур. Посмотрите определение: «дисциплины, изучающие человека в сфере его духовной, умственной, нравственной, ...» ваш тонкий духовный мир и понятия о нравственности меняются через день, с этим связаны главные особенности гуманитарных дисциплин. Программа завтра не станет иначе работать из-за того, что вы изменили свое мнение о том, как она должна работать, законы там вполне себе естественные и фантазии гуманитариев ничего не способны привнести в эту инженерную дисциплину, не обманывайте себя.
Ну, для меня промышленное программирование больше похоже на написание за три месяца романа «Евгений Онегин» командой из двадцати вчерашних студентов под руководством системного архитектора А. Пушкина. Программирование гораздо меньше напоминает создание домов, мостов и космических аппаратов.
Мрак и ужас — согласен)
Но проблема выше — в тим-лидах, архитекторах, менеджерах, писать на современных языках можно научить даже макаку, а вот следить, чтобы она ничего не ломала… это сложней)
Но проблема выше — в тим-лидах, архитекторах, менеджерах, писать на современных языках можно научить даже макаку, а вот следить, чтобы она ничего не ломала… это сложней)
Найдете серебряную пулю — поделитесь)
Программирование гораздо меньше напоминает создание домов, мостов и космических аппаратов.
Вы участвовали в чем-нибудь таком? Этап проектирования в любых нетиповых вещах не менее косячный и авральный в случае «быстро и дешево».
Ну, 20 лет проработал в ЦУПе. Имел честь участвовать в проектировании того, что летает до сих пор. Так вот, там мы проектировали на основе законов баллистики, аэродинамики, того же сопромата и много еще чего. В программировании похожих законов пока (?) нет. И мы продвигаемся к решению методом проб и ошибок. Поэтому и считаю некорректно сравнивать проектирование ПО и космических аппаратов.
То, что вы назвали законами — это «правила работы» мира в котором мы работаем.
И они либо есть, либо их нет вообще.
Все остальное — просто выводы из этих «правил».
Причем, даже эти «законы» выводятся из других природных законов. Весь вопрос лишь в том, насколько мы абстрагируемся от устройства этого мира.
И в программировании есть свои законы.
Эти законы определяются компьютерной архитектурой. Сверху накладываются абстракции ОС. Еще выше абстракции языка. И так далее, и тому подобное. И все это лежит на законах физики.
И проектирование — это не тупое обуздание каких-то законов природы, а комплексное формирование решения для некоторой задачи с учетом нужных ограничений.
Так что проектирование ПО отличается от проектирования космических аппаратов и домов, также как и проектирование космических аппаратов и домов отличается от проектирования автомобилей и мостов.
И они либо есть, либо их нет вообще.
Все остальное — просто выводы из этих «правил».
Причем, даже эти «законы» выводятся из других природных законов. Весь вопрос лишь в том, насколько мы абстрагируемся от устройства этого мира.
И в программировании есть свои законы.
Эти законы определяются компьютерной архитектурой. Сверху накладываются абстракции ОС. Еще выше абстракции языка. И так далее, и тому подобное. И все это лежит на законах физики.
И проектирование — это не тупое обуздание каких-то законов природы, а комплексное формирование решения для некоторой задачи с учетом нужных ограничений.
Так что проектирование ПО отличается от проектирования космических аппаратов и домов, также как и проектирование космических аппаратов и домов отличается от проектирования автомобилей и мостов.
По ООП — есть базис по проектированию в виде SOLID, так и математика в виде теории систем, теории множеств и так далее.
По императивщине — есть уже достаточно крепкая база теории, как математики, так и всяких методов по оценке и верификации.
Другие модели программирования изначально строились на базе мат. теорий.
Смутно понимаю какая именно теория вам нужна в дисциплине, которая напрямую родилась из математики.
По императивщине — есть уже достаточно крепкая база теории, как математики, так и всяких методов по оценке и верификации.
Другие модели программирования изначально строились на базе мат. теорий.
Смутно понимаю какая именно теория вам нужна в дисциплине, которая напрямую родилась из математики.
Поэтому и считаю некорректно сравнивать проектирование ПО и космических аппаратов.
Я считаю корректным. Я проектировал алгоритм работы космического прибора с учетом оптики, статистики и пары других наук. Окей, напроектировал. Ошибки — все равно переполнение буфера, непроверка инвариантов и несоответствие некоторых характеристик чертежам. Аналогично проектируешь себе КА, сопроматом все насчитал с запасом, а потом отказ из-за косяка при сборке.
Никакой разницы тут нет: в любой созидательной деятельности есть человеческий фактор. Т.е. вы заявляете, что программирование гуманитарно по сути. На самом деле: менеджмент программистов гуманитарен. Так же, как и менеджмент там, где ни строчки кода нет. Если задача стоит «быстро и дешево», от человеческого фактора будет очень много зависеть, но это характеристика любой деятельности, не только программирования.
Отличия программирования только в том, что тут всегда требуется «быстро и дешево». Потому что цена ошибки низкая. Программисты чувствуют себя более расслабленно. Даже Вояджеры умеют перепрошиваться.
Если говорить о научном подспорье, то типизация и есть вещь типа сопромата для программирования. Например, вещи типа boost::units избавляют от большинства ошибок в прикладных расчетах, транзакционная память — от проблем с многопоточностью, и так далее.
Осторожно, эмоции!
Что за херню я только что прочитал?!
Если честно, такое ощущение, что этот текст писался под настроем, вроде «Я не хочу программировать! Я хочу сидеть на подоконнике с чашкой кофе и думать о высоком!»
Вы размышляете о программировании в отрыве от самого программирования. Программирования именно в реальном, а не идеализированном смысле.
Начнем с самого главного. Программирование — это не,
Вы же пишите о программировании в контексте именно языков программирования, потом вообще сводите все к ООП-языкам, которые начинаете связывать с реальной жизнью и, внезапно, выясняется, что модели ООП-языков не совсем соответствуют реальности.
Предикатное, функциональное, процедурное, аспектно и прочее программирование за бортом. Не говоря уже о различных комбинациях.
Язык — это инструмент. Инструмент может быть несовершенен и неуниверсален. Но если к совершенству можно стремиться, то универсальность языка — это будет его же бич.
И инструмент никому ничего не должен, кроме возможности с его помощью решать поставленные задачи.
И программист — это человек, который умеет решать поставленные задачи с помощью имеющихся инструментов, и чьим результатом работы является программа в том или ином виде.
Кроме того, когда вы говорите «программирование», что вы имеет в виду?
Написание сайтов?
Написание web-сервисов?
Написание компиляторов?
Написание драйверов?
Написание операционных систем?
Написание скриптов?
Написание систем для исследования ДНК?
Написание систем, работающих с 3D?
Я могу привести десятки направлений в программировании, которые кардинально отличаются друг от друга.
Некоторые из направлений не получили бы своего развития без огромного математического аппарата за их спиной (компиляторы, 3D-технологии).
Некоторые требуют огромной алгоритмической базы.
Еще эмоции. Простите
Господи, господи! Зачем я это прочитал?! Как вообще можно было такое придумать?!!!
Если же имеется в виду написание алгоритмов, то, простите, я тут тоже не вижу оснований считать программирование гуманитарным направлением.
Вообще, весь пост напоминает различные анти-, полу-начные статьи, в стиле «мне нечего сказать по делу, поэтому растекусь мыслью по древу, а потом сделаю крутой и шокирующий вывод, который ниоткуда не следует и ничего за собой не несет».
Конечно, можно создать огромную филосовскую базу и на основании лежащего на лужайке камня.
Но давайте не будем забывать, что придуманная философия — это то, чему вы учитесь у камня, а не то, чем является камень на самом деле.
В общем, как человек, который последние годы работает в атмосфере наукоемкого программирования, я называю вас Петриком от программирования.
Есть такой поведенческий паттерн: «Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.» От ответа воздержусь. Но вопрос задать очень хочется. Что такое «атмосфера наукоемкого программирования»? Просветите?
Написание оптимизирующего компилятора. Или сборщика мусора. Как самые яркие примеры.
И кроме этого много низкоуровневого программирования, работы с ОС, мелких точеченых оптимизаций на ассемблере, где чистой научной ценности не так много.
И где в этом программировании гуманитарная составляющая?
И кроме этого много низкоуровневого программирования, работы с ОС, мелких точеченых оптимизаций на ассемблере, где чистой научной ценности не так много.
И где в этом программировании гуманитарная составляющая?
Заметь, ты приводишь в основном примеры системного программирования = программирования для программистов, если хочешь. Мне кажется, что программист-космонавт Чарльз Симони был совершенно прав, когда говорил: «programmers become unwitting cryptographers». Системное программирование не создает пользовательской ценности, а лишь облегчает (всегда ли?) ее создание для прикладных программистов.
Я привел эти примеры, потому что раскрывал ту самую «атмосферу наукоемкого программирования», в которой я обитаю.
Если они не устраивают, то могу привести в пример знакомых, работающих по соседству, занимающихся CAD-системами. Где у них гуманитарная составляющая?
У создателей Photoshop'а, наверное, тоже никакой математики не было.
Аудио-видео кодеки?
Создатели игровых 3d-движков?
Эта цитата хорошо характеризует ваши представления о системном программировании в целом.
Наверное, фотошопы и CAD'ы тоже не несут пользовательской ценности — они облегчают ее создание для фотографов и архитекторов.
3Ds Max и Maya ьлже не несут пользовательской ценности… Sony Vegas Studio… Word и Excel'и… ваши примеры?
Если они не устраивают, то могу привести в пример знакомых, работающих по соседству, занимающихся CAD-системами. Где у них гуманитарная составляющая?
У создателей Photoshop'а, наверное, тоже никакой математики не было.
Аудио-видео кодеки?
Создатели игровых 3d-движков?
Системное программирование не создает пользовательской ценности, а лишь облегчает (всегда ли?) ее создание для прикладных программистов.
Эта цитата хорошо характеризует ваши представления о системном программировании в целом.
Наверное, фотошопы и CAD'ы тоже не несут пользовательской ценности — они облегчают ее создание для фотографов и архитекторов.
3Ds Max и Maya ьлже не несут пользовательской ценности… Sony Vegas Studio… Word и Excel'и… ваши примеры?
Чтобы мои претензии были яснее, предоставлю такой тезис:
Программирование — это не наука и не дисциплина.
Программирование — это способ решения задач с помощью создания программ в широком смысле (скриптов, сайтов, сервисов, приложений).
Да, программист — это не всегда инженер. Но из этого не следует, что он гуманитарий. Из этого вообще ничего не следует.
Просто это очень популярный и эффективный способ решения широкого круга задач, поэтому для этого способа есть множество различных инструментов, самыми удобными из которых являются языки программирования.
Тем не менее, даже разработкой языков программирования занимаются не гуманитарии, а ученые, математики, т.к. создание формального языка является, по сути, математической задачей, т.к. его будет компилировать программа, работающая на компьютере, который работает по строгой модели, основанной на, опять же, математической модели.
Программирование — это не наука и не дисциплина.
Программирование — это способ решения задач с помощью создания программ в широком смысле (скриптов, сайтов, сервисов, приложений).
Да, программист — это не всегда инженер. Но из этого не следует, что он гуманитарий. Из этого вообще ничего не следует.
Просто это очень популярный и эффективный способ решения широкого круга задач, поэтому для этого способа есть множество различных инструментов, самыми удобными из которых являются языки программирования.
Тем не менее, даже разработкой языков программирования занимаются не гуманитарии, а ученые, математики, т.к. создание формального языка является, по сути, математической задачей, т.к. его будет компилировать программа, работающая на компьютере, который работает по строгой модели, основанной на, опять же, математической модели.
К сожалению, не хватает кармы для использования тэгов в комментариях, поэтому:
Цитата:
Если честно, такое ощущение, что этот текст писался под настроем, вроде: Я не хочу программировать! Я хочу сидеть на подоконнике с чашкой кофе и думать о высоком!
Конец цитаты.
Вы забыли о пледике и дожде, нельзя сидеть на подоконнике думать о чем-то, если не идет дождь и ты не укутан в пледик :) *сарказм*
Цитата:
Если честно, такое ощущение, что этот текст писался под настроем, вроде: Я не хочу программировать! Я хочу сидеть на подоконнике с чашкой кофе и думать о высоком!
Конец цитаты.
Вы забыли о пледике и дожде, нельзя сидеть на подоконнике думать о чем-то, если не идет дождь и ты не укутан в пледик :) *сарказм*
Да, где-то и у меня такие эмоции.
Языки программирования — это всего-лишь языки и никому ничего не должны. Для каких-то задач отлично подходит запись системы уравнений, для других дифуры, для третьих С#. Язык еще один придумать не проблема. Проблема на нем писать. ООП простое, поэтому сравнительно легко писать. Какой-то динамический язык с динамическим наследованием и перенаследованием — только звучит необычно, а писать на нем будет жесть наверное.
В общем, дело не в языках, а в человеческом мышлении. Человек думает кучей разных моделей, каким-то непонятным образом. При передаче информации пользуется тоже многими вещами, начиная от рисунков, формул, заканчивая «клеем» — естественным языком. Который очень нечеткий. Программирование — это такой перевод его представления в языки программирования. Т.к. естественные языки и другие языки представления отличаются от языков программирования — будут ошибки.
Видимо, идеальный язык — это идеальный ИИ, который умеет и на естественном поговорить, и понять языки формул и вообще, давать наводящие вопросы, уточняя задание. Т.е. не язык, а интеллект, близкий к человеческому (хотя бы на уровне интерфейса с человеком), который может понять максимально близко, что человек хочет. Правда, когда такой ИИ будет, непонятно, зачем нужен человек. Оно и само будет не хуже принимать решения. И вероятность ошибки при передаче информации «человек-машина» всегда есть. А без человека не будет.
Так что радуемся, что есть пока у нас работа )
Языки программирования — это всего-лишь языки и никому ничего не должны. Для каких-то задач отлично подходит запись системы уравнений, для других дифуры, для третьих С#. Язык еще один придумать не проблема. Проблема на нем писать. ООП простое, поэтому сравнительно легко писать. Какой-то динамический язык с динамическим наследованием и перенаследованием — только звучит необычно, а писать на нем будет жесть наверное.
В общем, дело не в языках, а в человеческом мышлении. Человек думает кучей разных моделей, каким-то непонятным образом. При передаче информации пользуется тоже многими вещами, начиная от рисунков, формул, заканчивая «клеем» — естественным языком. Который очень нечеткий. Программирование — это такой перевод его представления в языки программирования. Т.к. естественные языки и другие языки представления отличаются от языков программирования — будут ошибки.
Видимо, идеальный язык — это идеальный ИИ, который умеет и на естественном поговорить, и понять языки формул и вообще, давать наводящие вопросы, уточняя задание. Т.е. не язык, а интеллект, близкий к человеческому (хотя бы на уровне интерфейса с человеком), который может понять максимально близко, что человек хочет. Правда, когда такой ИИ будет, непонятно, зачем нужен человек. Оно и само будет не хуже принимать решения. И вероятность ошибки при передаче информации «человек-машина» всегда есть. А без человека не будет.
Так что радуемся, что есть пока у нас работа )
> Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по
> совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится
> созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет
> перетаскивать.
Это не так. См. принцип инверсии зависимостей.
> Следовательно, один и тот же объект должен иметь возможность принадлежать разным классам и этот набор > классов должен быть динамическим, т.е. изменяться в ходе эволюции объекта и самой программной системы.
Ну так и смотрите на любой динамический язык и с исходным пониманием ООП (Smalltalk, Ruby и даже в какой-то степени JavaScript). Там все так как вам и нужно.
> Еще одна странность ООП: «Поведение — это то, как объект действует и реагирует; поведение выражается в > терминах состояния объекта и передачи сообщений». Но, постойте, если я моделирую столкновение двух
> автомобилей то, кто из них и какие получает и передает сообщения?
Никаких странностей, см. классическое определение информации по Шеннону.
> «Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и
> текущими (обычно динамическими) значениями каждого из этих свойств». Но принадлежит ли свойство
> объекта самому объекту? Буду утверждать, что нет. Например, мы говорим данное яблоко – зеленое. Но что
> это означает не самом деле?
Все зависит от степени абстракции. Можно смоделировать «зеленое яблоко», а можно смоделировать «яблоко», «луч света» и процесс «освещения яблока лучом света», которые даст на выходе результат «зеленый».
И, собственно, что?
Дальше еще много воды, на которую ответ такой же — все зависит от модели предметной области и ее трактовки.
> Итак, в нашем ментальном мире нет объектов и их свойств. А есть структуры и их взаимодействия. Если мы
> моделируем дорожное движение, то автомобили следует рассматривать как элементарные узлы структуры,
> которые вступая во взаимодействие (обгоняя, подрезая, тормозя), консистентно изменяют свои координаты
> в фазовом пространстве (скорость, положение).
Вау, в первом предложении у вас не свойств, а в третьем внезапно появляются координаты. Координаты — это что?
> Попытки создания универсального синтаксиса DSL предпринимались не раз.
DSL по определению не может быть универсальным. Что вытекает из расшифровки самой аббревиатуры. Весь раздел, соответственно, не про DSL, а про язык описания семантики (каковых было много, и самый известный — ПРОЛОГ, который внезапно очень похож на ваши примеры на картинках).
> Возможно, будущий DSL будет похож на Mixin-технологию или Anemic Domain Model
Что общего между вороной и письменным столом?
> В разработке ПО еще не открыты свои законы Ньютона, нет уравнений Лагранжа или хотя бы сопромата,
> которые помогли бы спроектировать и доказать правильность архитектуры новой нетривиальной программной
> системы.
Да ради бога! Гугл «формальная верификация».
UPD Простите, но ужасно похоже на творчество «научных фриков». Надерганные термины, без понимания смысла и полноценного анализа, зато с кучей выводов.
> совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится
> созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет
> перетаскивать.
Это не так. См. принцип инверсии зависимостей.
> Следовательно, один и тот же объект должен иметь возможность принадлежать разным классам и этот набор > классов должен быть динамическим, т.е. изменяться в ходе эволюции объекта и самой программной системы.
Ну так и смотрите на любой динамический язык и с исходным пониманием ООП (Smalltalk, Ruby и даже в какой-то степени JavaScript). Там все так как вам и нужно.
> Еще одна странность ООП: «Поведение — это то, как объект действует и реагирует; поведение выражается в > терминах состояния объекта и передачи сообщений». Но, постойте, если я моделирую столкновение двух
> автомобилей то, кто из них и какие получает и передает сообщения?
Никаких странностей, см. классическое определение информации по Шеннону.
> «Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и
> текущими (обычно динамическими) значениями каждого из этих свойств». Но принадлежит ли свойство
> объекта самому объекту? Буду утверждать, что нет. Например, мы говорим данное яблоко – зеленое. Но что
> это означает не самом деле?
Все зависит от степени абстракции. Можно смоделировать «зеленое яблоко», а можно смоделировать «яблоко», «луч света» и процесс «освещения яблока лучом света», которые даст на выходе результат «зеленый».
И, собственно, что?
Дальше еще много воды, на которую ответ такой же — все зависит от модели предметной области и ее трактовки.
> Итак, в нашем ментальном мире нет объектов и их свойств. А есть структуры и их взаимодействия. Если мы
> моделируем дорожное движение, то автомобили следует рассматривать как элементарные узлы структуры,
> которые вступая во взаимодействие (обгоняя, подрезая, тормозя), консистентно изменяют свои координаты
> в фазовом пространстве (скорость, положение).
Вау, в первом предложении у вас не свойств, а в третьем внезапно появляются координаты. Координаты — это что?
> Попытки создания универсального синтаксиса DSL предпринимались не раз.
DSL по определению не может быть универсальным. Что вытекает из расшифровки самой аббревиатуры. Весь раздел, соответственно, не про DSL, а про язык описания семантики (каковых было много, и самый известный — ПРОЛОГ, который внезапно очень похож на ваши примеры на картинках).
> Возможно, будущий DSL будет похож на Mixin-технологию или Anemic Domain Model
Что общего между вороной и письменным столом?
> В разработке ПО еще не открыты свои законы Ньютона, нет уравнений Лагранжа или хотя бы сопромата,
> которые помогли бы спроектировать и доказать правильность архитектуры новой нетривиальной программной
> системы.
Да ради бога! Гугл «формальная верификация».
UPD Простите, но ужасно похоже на творчество «научных фриков». Надерганные термины, без понимания смысла и полноценного анализа, зато с кучей выводов.
Сожалею, но многого не понял. Готовы пояснить хотя бы вот это:
Какая связь краш-теста и определения информации по Шеннону? И почему определение, например, не по Винеру?
> Еще одна странность ООП: «Поведение — это то, как объект действует и реагирует; поведение выражается в > терминах состояния объекта и передачи сообщений». Но, постойте, если я моделирую столкновение двух
> автомобилей то, кто из них и какие получает и передает сообщения?
Никаких странностей, см. классическое определение информации по Шеннону.
Какая связь краш-теста и определения информации по Шеннону? И почему определение, например, не по Винеру?
Шеннон связал количество информации и информационную энтропию с термодинамической, показав, что любое взаимодействие объектов приводит к изменению состояния объектов и передаче соответствующей информации от одного объекта к другому.
Таким образом, в теории информации взаимодействие объектов рассматривается, как изменение состояния объектов в результате передачи некоторой информации от одного объекта к другому.
Таким образом, в вашем примере — в момент столкновения автомобилей каждый из них получает информацию о состоянии другого автомобиля (скорость, направление итд). И получив сообщение с этой информацией реагирует изменением своего состояния («изменяя форму», например).
Выкладки Шеннона более подробные и основаны, внезапно, на определениях Винера, и сам Винер с Шенноном позже согласился.
UPD Отсюда — ООПшные сообщения и инкапсуляция, как запрет изменения свойств объекта любыми способами кроме посылки ему сообщения.
Потом «посылка сообщения» превратилась в «вызов метода» не поменяв сути.
Таким образом, в теории информации взаимодействие объектов рассматривается, как изменение состояния объектов в результате передачи некоторой информации от одного объекта к другому.
Таким образом, в вашем примере — в момент столкновения автомобилей каждый из них получает информацию о состоянии другого автомобиля (скорость, направление итд). И получив сообщение с этой информацией реагирует изменением своего состояния («изменяя форму», например).
Выкладки Шеннона более подробные и основаны, внезапно, на определениях Винера, и сам Винер с Шенноном позже согласился.
UPD Отсюда — ООПшные сообщения и инкапсуляция, как запрет изменения свойств объекта любыми способами кроме посылки ему сообщения.
Потом «посылка сообщения» превратилась в «вызов метода» не поменяв сути.
Упс, круто завернул!
«Бросая в воду камешки, смотри на круги, ими образуемые...» ( (с) Козьма Прутков) — это тоже про обмен информацией?
А, ничего что, Шеннон писал применительно к техническим системам, лишь о сигналах и связи, да еще при этом сам указывал, что информация, которая передается этими сигналами, его не интересует. А ты говоришь, что он ее определял.
«Бросая в воду камешки, смотри на круги, ими образуемые...» ( (с) Козьма Прутков) — это тоже про обмен информацией?
А, ничего что, Шеннон писал применительно к техническим системам, лишь о сигналах и связи, да еще при этом сам указывал, что информация, которая передается этими сигналами, его не интересует. А ты говоришь, что он ее определял.
Да, конечно. И под «определением информации по Шеннону», я конечно же имею ввиду определение «количества информации» и Шенноновскую математику вокруг этого определения.
Только вот потом был Эшби, который выводы Шеннона, в свою очередь, расширил на вообще сложные системы, по пути родив понятие «разнообразие», как меру информационного различия между двумя системами.
И откуда-то оттуда подход к имитациооному моделированию сложных систем, как совокупностей объектов, обменивающихся сообщениями, из которого и выросло в итоге то самое ООП.
Только вот потом был Эшби, который выводы Шеннона, в свою очередь, расширил на вообще сложные системы, по пути родив понятие «разнообразие», как меру информационного различия между двумя системами.
И откуда-то оттуда подход к имитациооному моделированию сложных систем, как совокупностей объектов, обменивающихся сообщениями, из которого и выросло в итоге то самое ООП.
Количество информации по Шеннону это мера пропускной способности канала связи. К самой информации формула Шеннона отношения не имеет. Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
Еще раз, космический аппарат, двигаясь в гравитационном поле, никому никаких сообщений не посылает и не принимает. И его имитационные модели, кстати, тоже.
Еще раз, космический аппарат, двигаясь в гравитационном поле, никому никаких сообщений не посылает и не принимает. И его имитационные модели, кстати, тоже.
> Количество информации по Шеннону это мера пропускной способности канала связи.
> К самой информации формула Шеннона отношения не имеет.
А термин информация по Шеннону (и Винеру, кстати) бессмысленен без возможности ее передачи.
Тем более, что это не сильно важно, так как я в первую очередь пытаюсь объяснить откуда в ООП взялась абстракция «сообщение», а не правильно определить термин «информация» (это хоть у кого-нибудь получилось? ИМХО, та же фигня, что с термином «время»).
> Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
Ни в каком. Потому что и то и другое, представляет собой то что в философии науки называют «знание» и измеримыми сущностями они не являются (опять же по Шеннону), хотя включает в себя некий набор информации.
А вот если мы говорим о законах, как о неких мат. моделях, которые можно закодировать на некотором формальном языке и куда-то передать — то вот тут уже можно что-то измерить.
> Еще раз, космический аппарат, двигаясь в гравитационном поле, никому никаких сообщений не посылает и не принимает.
Ключевое словосочетание — «гравитационное поле».
> И его имитационные модели, кстати, тоже.
А смотря что за имитационная модель. Если аналитическая — то да, никаких сообщений там нет.
А если событийное — то вам никто не мешает завести объект КА, объект «гравитационное поле» и моделировать взаимодействие через обмен сообщениями.
> К самой информации формула Шеннона отношения не имеет.
А термин информация по Шеннону (и Винеру, кстати) бессмысленен без возможности ее передачи.
Тем более, что это не сильно важно, так как я в первую очередь пытаюсь объяснить откуда в ООП взялась абстракция «сообщение», а не правильно определить термин «информация» (это хоть у кого-нибудь получилось? ИМХО, та же фигня, что с термином «время»).
> Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
Ни в каком. Потому что и то и другое, представляет собой то что в философии науки называют «знание» и измеримыми сущностями они не являются (опять же по Шеннону), хотя включает в себя некий набор информации.
А вот если мы говорим о законах, как о неких мат. моделях, которые можно закодировать на некотором формальном языке и куда-то передать — то вот тут уже можно что-то измерить.
> Еще раз, космический аппарат, двигаясь в гравитационном поле, никому никаких сообщений не посылает и не принимает.
Ключевое словосочетание — «гравитационное поле».
> И его имитационные модели, кстати, тоже.
А смотря что за имитационная модель. Если аналитическая — то да, никаких сообщений там нет.
А если событийное — то вам никто не мешает завести объект КА, объект «гравитационное поле» и моделировать взаимодействие через обмен сообщениями.
> Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
Ни в каком. Потому что и то и другое, представляет собой то что в философии науки называют «знание» и измеримыми сущностями они не являются (опять же по Шеннону), хотя включает в себя некий набор информации.
А вот если мы говорим о законах, как о неких мат. моделях, которые можно закодировать на некотором формальном языке и куда-то передать — то вот тут уже можно что-то измерить.
Информация, знания, данные… Это очень интересная тема. Думаю заслуживает отдельного поста. Как нибудь соберусь с силами и напишу. Там и продолжим обсуждение.
Молоток. Молоток весьма ограниченный инструмент. Им можно только забивать гвозди и ничего более. Если, скажем, мы возьмем задачу нанесения антибликовой поверхности на экран LCD дисплея, то молоток не справится с этой задачей. Также использование молотка весьма неочевидно, так как новички при первом использовании чаще всего пытаются взяться ближе к ударной части, хотя на самом деле это неправильно. Стоит ли говорить, что молоток это древнейший инструмент и в наш развитой век он морально устарел.
Открываем новую неделю «ООП — зло» на хабре?
Автор, вы исходите из (неуказанной) посылки, что программирование в том или ином виде стремится отобразить ментальную модель реальности человека?
И сетуете на недостаток «выразительных средств», упирая на ограниченность ООП-языков (если правильно понимаю вашу статью)?
Немного непонятна ваша печаль, если честно.
Таких целей ведь никто и не ставит. Компьютер не должен стать человеком, это инструмент.
Многие из трудностей, которые вы упоминаете, вроде как проработаны уже.
Взять тот же JavaScript. Любой объект можно наделить любым набором свойств и поведений. И даже без наследования.
И сетуете на недостаток «выразительных средств», упирая на ограниченность ООП-языков (если правильно понимаю вашу статью)?
Немного непонятна ваша печаль, если честно.
Таких целей ведь никто и не ставит. Компьютер не должен стать человеком, это инструмент.
Многие из трудностей, которые вы упоминаете, вроде как проработаны уже.
Взять тот же JavaScript. Любой объект можно наделить любым набором свойств и поведений. И даже без наследования.
Интересный взгляд на языки программирования.
Чем-то перекликается с моим Развитие пользовательских типов данных в программировании
Однако, выводы разнятся.
Я бы не сказал, что развитие DSL языков будет решением проблем. Имхо, это перекладывание проблем с одних плеч(базового языка программирования) на другие (DSL-языки). А их тоже надо как-то развивать. Сейчас ведь тоже многие DSL-языки находятся на уровне ассемблера — можно только пользоваться встроенными командами.
Чем-то перекликается с моим Развитие пользовательских типов данных в программировании
Однако, выводы разнятся.
Я бы не сказал, что развитие DSL языков будет решением проблем. Имхо, это перекладывание проблем с одних плеч(базового языка программирования) на другие (DSL-языки). А их тоже надо как-то развивать. Сейчас ведь тоже многие DSL-языки находятся на уровне ассемблера — можно только пользоваться встроенными командами.
Ну DSL — это всего лишь способ не думать о мелочах. Оперировать понятиями более высокого уровня, созданными уже программистом.
Можно, конечно, возразить что и на базовом языке все то же самое можно сделать. Но в базовом нельзя или очень сложно удалить из языка все не нужные для данной задачи конструкции.
Можно, конечно, возразить что и на базовом языке все то же самое можно сделать. Но в базовом нельзя или очень сложно удалить из языка все не нужные для данной задачи конструкции.
Каждый объект в ходе эволюции может быть дополнен новым набором потенциальных взаимодействий
А не кажется ли (хоть это и крамольно в свете принципов ООП ;) что как раз наоборот к взаимодействию можно добавить новый набор объектов, которые могут так взаимодействовать между собой. И не один объект, а несколько сразу.
Если молоток забивает гвоздь, то не так и важно молоток ведущий или гвоздь. Важнее какое между ними взаимодействие. А вот объекты можно переставлять или добавлять сколько угодно.
А в программировании такое объединение понятно — оно исторически сложилось.
Если сравнивать с обычным миром, то лучше присмотреться к реализации взаимодействия в играх. Столкновения, взрывы, падения и т.п
Склеить(объект1, объект2, объект3), а не объект1.Склеить(объект2)
Так ведь программы это и есть те самые DS-языки, которые предоставляют пользователям удобные для их сферы абстракции. Только не всегда DSL должны быть представлены в виде текста, но ведь в некоторых областях эффективны другие способы «программировать»: для дизайнера удобнее крутить ручки в Photoshop, для инженера удобнее строить 3D-модель с помощью мыши и т.д.
А «настоящие» программисты как раз и создают эти DSL с помощью языков общего назначения, облегчая решение задач для «ненастоящих» программистов, однако и те, и другие занимаются программированием (т.е. алгоритмизацией).
А «настоящие» программисты как раз и создают эти DSL с помощью языков общего назначения, облегчая решение задач для «ненастоящих» программистов, однако и те, и другие занимаются программированием (т.е. алгоритмизацией).
Если ты просто делашь удобный API, то есть конечный набор вызвов и схем, это понятно как настоящему программисту, так и ненастоящему. Конкретные вызовы API как раз таки можно выводить на ручки, контролы и прочий мышиный ввод. А синтаксис самого языка можно почерпнуть из справочника, 5-минутного курса и т.п.
DSL же подразумевают свой синтаксис. При этом они сложны в разработке, так как докидывают пару-тройку слоев абстракции. И даже примитивные сложны в изучении, так как их не окружает достаточно знаний о проблемах и паттернах использования.
Тем более зачем продвинутому пользователю какой-то изощренный синтаксис, скаляры, списочные структуры, ветвления по условию, переборы и внешние вызовы. Зачем к этому всему что-то еще?
DSL же подразумевают свой синтаксис. При этом они сложны в разработке, так как докидывают пару-тройку слоев абстракции. И даже примитивные сложны в изучении, так как их не окружает достаточно знаний о проблемах и паттернах использования.
Тем более зачем продвинутому пользователю какой-то изощренный синтаксис, скаляры, списочные структуры, ветвления по условию, переборы и внешние вызовы. Зачем к этому всему что-то еще?
Читал с интересом и все ждал, когда на сцену выйдут системы фактов, EAV и т.п. и они, к большому удивлению, таки вышли.
А то уже стал опасаться какого ни будь анонса очередного полуэзотерического ЯП, где все замечательно в теории, не считая такой мелочи, что не удалось решить проблему с вводом и хранением текстовой строки, не говоря уж о выводе.
Вместо этого выполз DSL и на этом этапе автор сам запутался
>законы эволюции модели во времени.
У него же там вроде модели через отношения определяются. Значит не может быть эволюции модели как таковой, может быть эволюция отношений.
А то уже стал опасаться какого ни будь анонса очередного полуэзотерического ЯП, где все замечательно в теории, не считая такой мелочи, что не удалось решить проблему с вводом и хранением текстовой строки, не говоря уж о выводе.
Вместо этого выполз DSL и на этом этапе автор сам запутался
>законы эволюции модели во времени.
У него же там вроде модели через отношения определяются. Значит не может быть эволюции модели как таковой, может быть эволюция отношений.
Парадокс — в школе и в универе хорошо шли точные науки, а из рук плохо — гуманитарные, но стал программистом (по отзывам коллег и начальства — неплохим) и судя по Вашей статье — я все же гуманитарий… это как же так получается :) гуманитарием никогда не был — не давалось оно мне, а оказывается я уже много лет Гуманитарий со стажем :-)
Вот Вы явно не в своей тарелке — по образу мыслей философ, а в профиле:
О себе: Эксперт. Проектирование и разработка программного обеспечения
Может не тем занимаетесь? :-)
Вот Вы явно не в своей тарелке — по образу мыслей философ, а в профиле:
О себе: Эксперт. Проектирование и разработка программного обеспечения
Может не тем занимаетесь? :-)
Вот Вы явно не в своей тарелке — по образу мыслей философ, а в профиле:
О себе: Эксперт. Проектирование и разработка программного обеспечения
Может не тем занимаетесь? :-)
Просто всему — свое время. «Время разбрасывать камни, и время собирать».
Если бы нас в свое время учили философии (не только марксистко-ленинской), психологии, лингвистике, семиотике, мне кажется, мы могли бы более эффективно проектировать и разрабатывать ПО. Но нас учили, ТФКП, функциональному анализу, квантовой механике и много-много чему еще. Все это было очень интересно, но, к сожалению, в моей программистской карьере не пригодилось :(
> Развитие информатики как науки представляется рекой, которая рождается в далеком прошлом (Евклид, III век до н.э.
А я уж было подумал, что это цитата!
А я уж было подумал, что это цитата!
Уже давно существует и используется компонентно-ориентированное программирование.
Прочитайте доходчивую и красочную презентацию с канадской конференции разработчиков игр 2009 года, описывающую эту технологию.
Объект в компонентно-ориентированном подходе представляет из себя мешок из атрибутов и поведений (Behaviours). Поведение как раз и реализует возможность взаимодействия одного объекта с другими и влияет на его атрибуты.
Мало того, существует рабочая среда наполовину визуальной разработки игр Unity. Например, вы можете создать объкт, добавить в него физическую модель — сферу, привязать камеру и добавить поведение «управление с клавиатуры» — всё, главный герой готов.
Так что в данном случае именно разработка игр стимулировала развитие архитектуры ПО, потому что сложилось так, что именно в виртуальных игровых мирах возникали самые сложные и неклассифицируемые в диаграмму классов «с наследованием» виды объектов.
Прочитайте доходчивую и красочную презентацию с канадской конференции разработчиков игр 2009 года, описывающую эту технологию.
Объект в компонентно-ориентированном подходе представляет из себя мешок из атрибутов и поведений (Behaviours). Поведение как раз и реализует возможность взаимодействия одного объекта с другими и влияет на его атрибуты.
Мало того, существует рабочая среда наполовину визуальной разработки игр Unity. Например, вы можете создать объкт, добавить в него физическую модель — сферу, привязать камеру и добавить поведение «управление с клавиатуры» — всё, главный герой готов.
Так что в данном случае именно разработка игр стимулировала развитие архитектуры ПО, потому что сложилось так, что именно в виртуальных игровых мирах возникали самые сложные и неклассифицируемые в диаграмму классов «с наследованием» виды объектов.
Спасибо за информацию! Просмотрел презентацию — очень похоже на то, о чем я написал в посте. Буду изучать внимательнее. Разработкой игр не занимался, но десять лет разрабатывал имитационные модели сложных систем — тысячи объектов с десятками компонентов в каждом. Мои идеи зародились именно при разработке этих моделей.
Sign up to leave a comment.
Размышления о программировании