Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников? Сегодня, когда индустрия ПО ещё молода и её технологии весьма примитивны, когда всё только начинается, очень сложно угадать что будет завтра, но я попробую! В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC> Из-за чего им сложно представить объект как собственно "объект" а не как нечто конкретное.
:super: Мне понравилось, сам вдруг задумался, а что значит объект для меня лично? Фиг его знает :???:
AC> Во вторых необходимо разработать программный инструмент, который бы облегчил программисту перенос создаваемой им программы из голов в компьютер, и наоборот.
Да пора, давно пора развернуться и обратить внимание — что же там творится в голове у этих программистов!!!
:beer:
Революция в програмировании придет совсем с другой стороны. Со стороны "не ждали".
То что сейчас обсуждается как языковые фичи , обсуждалось и 30 лет назад. Никаких революций с тех пор не случилось.
А вот технологии автоматической оптимизации начинают интенсивно эволюционировать , и на них есть колосальный рыночный спрос. Так вот оптимизирующие компиляторы нового поколения изменят индустрию до неузнаваемости.
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, minorlogic, Вы писали: M>Революция в програмировании придет совсем с другой стороны. Со стороны "не ждали".
Я, за эволюцию M>А вот технологии автоматической оптимизации начинают интенсивно эволюционировать , и на них есть колосальный рыночный спрос. Так вот оптимизирующие компиляторы нового поколения изменят индустрию до неузнаваемости.
Оптимизация штука хорошая, но чтоб существенно изменить индустрию ПО... думаю это врядли.
Почему вы так считаете?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Оптимизация штука хорошая, но чтоб существенно изменить индустрию ПО... думаю это врядли. AC>Почему вы так считаете?
А вы представте себе программу написанную в декларативном стиле которая компилируется и выполняется без существенных накладных расходов. Или новые версии Java JIT которые используют все преимущества рантайм анализа? Среднестатистическое програмирование может радикально измениться.
Здравствуйте, AlexCab, Вы писали:
AC>Каким будет программирование в будущем? Останется ли оно уделом избранных или будет доступным каждому, а может его вовсе не будет, и машины будут обучаться, а не программироваться? Останутся ли языки программирования текстовыми или станут графическими, или, может быть, люди научатся превращать мысли в программы без посредников?
Все будет хорошо. Надеюсь, что никаких революций не будет. Наилучшим путем развития будет взаимопроникновение парадигм, оттачивание и совершенствование языков программирования, вплоть до мелочей. Нередко именно из-за мелочей, на первый взгляд незначительных упущений в дизайне языков исходные коды программ теряют элегантность и становятся толстыми и неповоротливыми. Также нужно совершенствование сред разработки, библиотек, фреймворков и технологий. Языки, надеюсь, останутся текстовыми, но при проектировании новых языков люди будут сначала думать "а удобен ли этот язык для какого-либо визуального представления средствами IDE?".
AC>В этой заметке я расскажу, каким мне представляется программирование в недалёком будущем.
Ни одна проблема не решена, включая глобальные переменные, внутреннее состояние (в данном случае — в компонентах), возможности пройти по несуществующей ссылке (в данном случае это "хендл" компонента) и т.д. и т.п.
Запрет на создание циклических ссылок? А слабо сделать так, чтобы не было вообще ссылок?
Здравствуйте, AlexCab, Вы писали:
AC>Мнения, особенно замечания и конструктивная критика, приветствуются!
очень не сбалансировано между "разработка логики компонента" и "игра в цветные кубики".. получается, что человек для "игры в кубики" просто не нужен..
плюс компонентов будет много.. очень много, больше, чем кажется..
фактически при таком подходе каждый кодер будет делать свою пачку компонентов, потому всю логику реализовать в компонентах времени не хватит.. следующая парадигма вытеснит
про игровой пример могу сказать, что там реюз возможен разве что для ввода-вывода.. т.е. даже минимального реюза логики просто не будет..
следовательно КОП не нужно
...coding for chaos...
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, os24ever, Вы писали: O>Ни одна проблема не решена, включая глобальные переменные,
Отсутствуют. O>внутреннее состояние (в данном случае — в компонентах),
Разве это проблема? Внутреннее состояние это естественное/привычное свойство объектов реальности, зачем от него отказываться в программировании? К тому можно создавать компоненты без внутреннего состояния, но тогда это будут просто библиотеки функций. O>возможности пройти по несуществующей ссылке (в данном случае это "хендл" компонента)
Эту да, пока не удалось решить, но так как хендлы буду (предположительно) использоваться гораздо-гораздо реже, вероятность возникновения таких ошибок значительно меньше. O>и т.д. и т.п.
А по подробней?
O>Запрет на создание циклических ссылок?
Нет, можно сколько угодно создавать циклических хендлов и подключений, кроме подключений root'овских интерфейсов, они да, не могут быть циклическими(но тут очень простое правило: root'овский интерфейс подключается первым, отключается последним и остаётся подключённым всё время "жизни" компонента, т.е. сделать такое подключение циклическим в принципе не получится). O>А слабо сделать так, чтобы не было вообще ссылок?
Во первых, ссылки(хендлы), в общем-то нужны только для того, чтобы рантайм "дать знать" одному компоненту о другом, например, в случае когда необходим учёт компонентов(к примеру в оконном приложении с вкладками, компоенет управляющий вкладками должен "знать" о всех компонентах-вкладках, для чего имеет список их хендлов). Если в приложении такой возможности не требуется(например это простое приложение без динамических компонентов), то хендлы можно(и нужно) не использовать.
Во вторых, ссылки делают КОПрограммирование похожим на ООП, т.е. при переходе с ООП вам не придётся долго и нудно вникать в теорию, вы можете поначалу просто писать код, почти "как раньше".
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, neFormal, Вы писали: F>очень не сбалансировано между "разработка логики компонента" и "игра в цветные кубики"..
В общем-то так и было задумано, большая часть работы выполняется на этапе разработки(включающей так-же анализ и построение модели предметной области) библиотеки компонентов(фреймворка). Пользователям фреймворка(ов) остаётся только собрать решение их конкретной проблемы. Такой подход, например, используется в ПО 1С:Предприятие. F>получается, что человек для "игры в кубики" просто не нужен..
Это уж как разроб сочтёт нужным. Я думаю, такое будет редкостью, т.к. разработка полностью автоматической системы сложна, дорога (а потому не рентабельна), и часто вовсе не возможна. F>плюс компонентов будет много.. очень много, больше, чем кажется.. F>фактически при таком подходе каждый кодер будет делать свою пачку компонентов,
Это не страшно и, от этого никуда не деться, людям интересней сделать что-то своё, чем использовать готовое но чужое. F>потому всю логику реализовать в компонентах времени не хватит.. следующая парадигма вытеснит
Всю не надо, предполагается тесная интеграция с другими ЯП на JVM, так что можно будет например, написать часть приложения в КОП стиле, часть в ФП, часть в ООП и, разумеется использовать готовое. F>про игровой пример могу сказать, что там реюз возможен разве что для ввода-вывода.. т.е. даже минимального реюза логики просто не будет..
Как и в других парадигмах, реюз компонентов очень сложен, если они для этого специально не разрабатывались. Во втором и третьем примерах, реюз выполняется при помощи наследования.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
F>>очень не сбалансировано между "разработка логики компонента" и "игра в цветные кубики".. AC>В общем-то так и было задумано, большая часть работы выполняется на этапе разработки(включающей так-же анализ и построение модели предметной области) библиотеки компонентов(фреймворка). Пользователям фреймворка(ов) остаётся только собрать решение их конкретной проблемы. Такой подход, например, используется в ПО 1С:Предприятие.
Так его постоянно допиливают на местах. Там не только же сборка из кубиков.
F>>получается, что человек для "игры в кубики" просто не нужен.. AC>Это уж как разроб сочтёт нужным. Я думаю, такое будет редкостью, т.к. разработка полностью автоматической системы сложна, дорога (а потому не рентабельна), и часто вовсе не возможна.
Я к тому, что человек, создающий кубики, за 5 минут их сможет составлять в любые конструкции.
Т.е. работодатель не будет брать сборщика.
F>>про игровой пример могу сказать, что там реюз возможен разве что для ввода-вывода.. т.е. даже минимального реюза логики просто не будет.. AC>Как и в других парадигмах, реюз компонентов очень сложен, если они для этого специально не разрабатывались.
Тогда надо решать проблему реюза, иначе смысла от КОП не будет, т.к. сейчас при здравом подходе задачи делятся по сложности между разными людьми. Только реюз позволит
Даже если и возникнет необходимость в разработке новых компонентов, то во первых, их количество будет небольшим(по сравнению готовыми компонентами, использованными в приложении), во вторых, у вас(как разработчика компонента) уже будет "окружение" из готовых компонентов, т.е. вам будет на что опереться/отчего оттолкнуться(иначе говоря будет достаточно просто создать компонент связывающий в одно приложение уже готовые части).
Вот здесь^ заблуждение, что компонентов будет требоваться мало(почему?), и что "достаточно просто создать ..."
Работа сведётся к созданию компонентов при мало-мальски сложных задачах. Более того, оверхед от новых компонентов, вероятно, будет зашкаливать.
Ещё интересно, как будет работать система с данными, которые надо по-разному обрабатывать?
Есть, например, платежи. В первый раз система была реализована для проведения платежей, а во второй потребовалось, чтобы к платежу добавлялся рандомный бонус. В интерфейсе для указания бонуса нужно добавить галочку и счётчик процентов бонуса.
Что надо сделать средствами КОП?
AC>Во втором и третьем примерах, реюз выполняется при помощи наследования.
Тогда что не решается наследованием, что может решиться через КОП?
Здравствуйте, AlexCab, Вы писали:
AC>Мнения, особенно замечания и конструктивная критика, приветствуются!
Картинки отличные!
Текст неплохо бы через спеллчекер и/или ворд хотя бы прогнать, русская языка для автора очно сложная однако.
Содержание: поздравляю, вы заново переизобрели COM. Заметных отличий не видно.
Re[4]: Заметка: Компонентная философия и реализация
AC>>В общем-то так и было задумано, большая часть работы выполняется на этапе разработки(включающей так-же анализ и построение модели предметной области) библиотеки компонентов(фреймворка). Пользователям фреймворка(ов) остаётся только собрать решение их конкретной проблемы. Такой подход, например, используется в ПО 1С:Предприятие. F>Так его постоянно допиливают на местах. Там не только же сборка из кубиков.
Не встречал такого где работал, видел только что "конфигурируют", но там есть COM так что может быть. F>Я к тому, что человек, создающий кубики, за 5 минут их сможет составлять в любые конструкции.
Держать такого, там, где достаточно навыка сборки из кубиков, не выгодно. F>Т.е. работодатель не будет брать сборщика.
Ему(работодателю) и не нужно брать сборщика, если "собирание из кубиков" станет достаточно простым, с ним справится и не программист(но специалист в какой-то другой области). F>Тогда надо решать проблему реюза, иначе смысла от КОП не будет, т.к. сейчас при здравом подходе задачи делятся по сложности между разными людьми.
Эта проблема решится сама, если/когда писать переиспользуемый кода станет выгодней, чему, я надеюсь, КОП сильно поспособствует. F>
F>Даже если и возникнет необходимость в разработке новых компонентов, то во первых, их количество будет небольшим(по сравнению готовыми компонентами, использованными в приложении), во вторых, у вас(как разработчика компонента) уже будет "окружение" из готовых компонентов, т.е. вам будет на что опереться/отчего оттолкнуться(иначе говоря будет достаточно просто создать компонент связывающий в одно приложение уже готовые части).
F>Вот здесь^ заблуждение, что компонентов будет требоваться мало(почему?), и что "достаточно просто создать ..."
Потому же, почему большая часть кода, многих приложений, в библиотеках и, достаточно просто написать "склеивающий" код. В КОП это будет ещё проще, так как часть приложения(возможно даже очень значительную) получится создать методом "сборки из кубиков". F>Работа сведётся к созданию компонентов при мало-мальски сложных задачах.
В сложных нет, но в уникальных, пожалуй да. F>Более того, оверхед от новых компонентов, вероятно, будет зашкаливать.
Т.е.? F>Ещё интересно, как будет работать система с данными, которые надо по-разному обрабатывать? F>Есть, например, платежи. В первый раз система была реализована для проведения платежей, а во второй потребовалось, чтобы к платежу добавлялся рандомный бонус. В интерфейсе для указания бонуса нужно добавить галочку и счётчик процентов бонуса. F>Что надо сделать средствами КОП? Плохой способ:
В бухгалтерском фреймворке просто должно быть два компонента, обычный платёж и платёж с бонусом соответственно. Счётчик размещается БД, в записи плательщика. Хороший способ:
В фрейворке должен быть набор компонентов:
форма — на которой другие компоненты размещают свои пользовательские интерфейсы(поля, кнопки etc.),
стандартный платёж — включающий всегда востребованный минимум возможностей,
бонус — компонент вычисляющий бонус, он создаётся(и добавляет элементы своего UI на форму) если у плательщика собственно есть бонус,
штраф — аналогично предыдущему,
и т.п.
Когда оператор нажимает кнопку "платёж", компонент(обрабатывающий эту кнопку) выполняет скрипт(написанный прикладным программистом), и создаёт к-форму и к-стандартный платёж. Далее когда оператор вводит данные плательщика, к-стандартный платёж обращается к к-БД, за подтверждением и доп. информацией плательщика. Если у плательщика есть бонус, к-стандартный платёж создаёт к-бонус, который добавляет элементы своего UI на форму. Когда оператор нажимает кнопку "проплатить", к-стандартный платёж передаёт данные платежа(перед отправкой в БД) к-бонусу, который вносит в них требуемые изменения. Если вы пишите что то своё, не используя фреймворк или если нет подходящего компонента:
Тут да, приёдётся писать "обычным"(как в ООП) способом самим или заказывать компонент у стороннего производителя. AC>>Во втором и третьем примерах, реюз выполняется при помощи наследования. F>Тогда что не решается наследованием, что может решиться через КОП?
Всё, для чего есть уже реализованный набор компонентов. А наследование используется для реюза при разработке самих компонентов.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[2]: Заметка: Компонентная философия и реализация
Здравствуйте, D. Mon, Вы писали: DM>Содержание: поздравляю, вы заново переизобрели COM. Заметных отличий не видно.
Да, это похоже на COM. Пожалуй, самое главное отличие в том что COM это надстройка над ООП. Здесь же компоненты как-бы на одном уровне с объектами("Компоненты, это объекты с упорядоченными связями!"). Ну и ещё много разных мелких плюшек.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[3]: Заметка: Компонентная философия и реализация
O>>Ни одна проблема не решена, включая глобальные переменные, AC>Отсутствуют. O>>внутреннее состояние (в данном случае — в компонентах), AC>Разве это проблема? Внутреннее состояние это естественное/привычное свойство объектов реальности, зачем от него отказываться в программировании?
Так это и есть глобальные переменные
AC>К тому можно создавать компоненты без внутреннего состояния, но тогда это будут просто библиотеки функций.
Вот их и надо создавать.
Re[3]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Да, это похоже на COM. Пожалуй, самое главное отличие в том что COM это надстройка над ООП. Здесь же компоненты как-бы на одном уровне с объектами("Компоненты, это объекты с упорядоченными связями!"). Ну и ещё много разных мелких плюшек.
Да, плюшки приятные имеются. Но в целом складывается впечатление, что разработка в такой манере только усложнится. Потому что на каждый чих нужен новый компонент, надежда иметь исчерпывающую их библиотеку не оправдается (пример с бонусами выше это показывает). А реализация компонентов требует довольно много усилий по соблюдению их правильного поведения — все эти реверансы с подключениями, рестартами, версионностью. Если это все честно реализовывать для всех компонентов, это вероятно может повысить качество кода, но ценой бОльших усилий по его написанию. А вот тут нас и ждет провал, большинство программистов выберут более простой путь, где основную логику можно описать прямо и не задумываясь о компонентных протоколах.
Когда COM появился, на него же очень похожие надежды возлагали. Но оказалось, что очень уж муторно так писать. Как его эволюция позже возник .net, например.
Здравствуйте, minorlogic, Вы писали:
M>А вы представте себе программу написанную в декларативном стиле которая компилируется и выполняется без существенных накладных расходов. Или новые версии Java JIT которые используют все преимущества рантайм анализа? Среднестатистическое програмирование может радикально измениться.
Пока что все с точностью до наоборот. Ява/дотнет на телефонах статически прекомпилируется, что дает значительный выигрышь в производительности.
С ДСЛ-ями согласен, но универсальные оптимизаторы тут совсем не причем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Заметка: Компонентная философия и реализация
O>>>внутреннее состояние (в данном случае — в компонентах), AC>>Разве это проблема? Внутреннее состояние это естественное/привычное свойство объектов реальности, зачем от него отказываться в программировании? O>Так это и есть глобальные переменные
Какие ж они глобальные? Это конечно не чистое ФП, когда "состояние программы это состояние всех функций", но чтобы один компонент смог изменить другой он должен: 1) иметь соответствующий интерфейс; 2) в принципе "знать"(знать имя или как-то получить хендл) о другом. К тому же другой компонент может и не разрешить себя изменять.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Re[5]: Заметка: Компонентная философия и реализация
Здравствуйте, AlexCab, Вы писали:
AC>Ему(работодателю) и не нужно брать сборщика, если "собирание из кубиков" станет достаточно простым, с ним справится и не программист(но специалист в какой-то другой области).
Я вижу, что КОП нацелен на упрощение сборки при постоянной необходимости создания компонентов. Т.е. всегда нужен программист и никогда сборщик.
Разве не так?
AC>Эта проблема решится сама, если/когда писать переиспользуемый кода станет выгодней, чему, я надеюсь, КОП сильно поспособствует.
Вот примеров хотелось бы.
Желательно в коде
F>>Вот здесь^ заблуждение, что компонентов будет требоваться мало(почему?), и что "достаточно просто создать ..." AC>Потому же, почему большая часть кода, многих приложений, в библиотеках и, достаточно просто написать "склеивающий" код. В КОП это будет ещё проще, так как часть приложения(возможно даже очень значительную) получится создать методом "сборки из кубиков".
Видится мне, что в этом случае компоненты будут очень маленькими. Тогда оверхед будет на их связи друг с другом.
F>>Более того, оверхед от новых компонентов, вероятно, будет зашкаливать. AC>Т.е.?
Чтобы переделать на свой лад, надо будет сделать либо с нуля, либо отнаследоваться. В первом случае оверхед по объёму, во втором оверхед либо по зависимостям(если код не будет дублироваться в компоненте), либо по размеру компонента(если код будет копироваться в компонент).
AC>Хороший способ:
