Comments 25
Я тоже интересуюсь прогрессивными парадигмами.
В первой части вы писали:
"Вкратце опишу основную задачу
Она заключается в том, чтобы создать такой язык программирования, который был бы удобен как для описания модели предметной области, так и для работы с ней. Чтобы описание модели было как можно более естественным, понятным для человека и близким к спецификациям программного обеспечения. Но при этом оно должно быть частью кода на полноценном языке программирования. Для этого модель будет иметь форму онтологии и состоять из конкретных фактов, абстрактных понятий и отношений между ними. "
Для того, чтобы приблизить программирование к человеку, надо дать ему возможность неточно программировать. Давайте назовем то, о чем я собираюсь рассказать, парадигмой неточного программирования.
Итак, смотрите, я сейчас объясняю все очень образно, вот так:
- Компилятор работает только с точной информацией.
- Человек (программист) работает с точной информацией + с неточной информацией.
Предлагаемая парадигма должна поднять работу с неточной информацией на более высокий уровень. Компилятор по-прежнему будет работать только с точной информацией (иначе никак), а язык программирования и IDE должны служить новой парадигме.
На самом деле существующие языки и среды разработки частично, но неосознанно (на мой взгляд) поддерживают парадигму неточного программирования.
Для этого используются:
- Комментарии (компилятор игнорирует, программист нет)
- Абстракции, имена (компилятору неважно, как именуются константы, переменные, функции, объекты и др., а программисту — важно)
- Прочие программные конструкции (компилятор может оптимизировать программные решения под быстродействие и память, а программист оптимизирует для упрощения понимания)
Что значит "полноценная поддержка парадигмы неточного программирования"? А вот интересный вопрос! У меня есть несколько наметок, но мне кажется, что я ухватил взглядом лишь верхушку айсберга. Я проанализировал неточную информацию — в основном это информация от аналитиков, архитекторов ПО и собственные наблюдения и представления программиста. Цель — максимально формализовать и сохранить информацию в проекте, удобно изложить/отобразить и использовать для поддержки разработки. Информация зачастую неформализована, неструктурирована, слабо структурирована. Сейчас для подобной информации используются комментарии как возможность языка для организации "свалки", можно туда еще картинки, звукозаписи и видео сваливать. Надо уйти от свалки, можно же вместо закомменчивания строки кода использовать нормальные инструменты языка программирования??? А список to do в комментах? А обозначить паттерн проектирования (паттерны же у нас хорошо формализованы)?
Точная информация (которая предназначена для компилятора) — тут уже все изъезжено и изжевано.
Проблема в том, что языки программирования формальны, они недопускают неоднозначности. Грубо говоря, есть только один жестко заданный путь исполнения программы.
А естественные языки неоднозначны. Ингда одно и то же предложение можно понять разными способами. И опыт и здравый смысл позволяет оценить правильность того или иного варианта.
Было бы интересно найти способ сблизить формальные и неформальные языки. Это открыло бы очень много новых возможностей по автоматизации программирования и тестирования, различным компьютерным помощникам и т.п.
Ну смотрите: неформальная информация имеет частные случаи — полное отсутствие информации, частичная (неполная) информация, вероятностная информация. Дублирование смысла — это синтаксический сахар, наелись уже. :-) А с противоречивой информацией не хотелось бы сталкиваться в программировании.
Ну вот смотрите: предлагаю элементы языка для частичной информации. Допустим мы хотим указать объект или функцию, можем назвать имя и т.п., но не знаем тело объекта или функции.
Мы можем использовать комментарии для того, чтобы в них написать незаконченную функцию или объект. Однако IDE не будет распознавать этот элемент и не может помочь в разработке.
Можно использовать привычные элементы языка для указания незавершенных программных конструкций, но помечать эти конструкции ключевым словом "under_construction". Все просто!
Про вероятностную информацию сложнее, но тоже можно реализовывать: мы можем указывать вероятностные распределения для переменных и выражений. Зачем? Компилятору это не надо, зато программистам важно. Пусть есть выражение в условии if, это выражение может принимать значения false/true. Допустим true вероятность 0.9, false — 0.1. Тогда очень важный момент: становится ясным, что путь выполнения программы then вероятнее (важнее), чем путь else. Это реализация идеи "царская дорога" из отечественной среды разработки ДРАКОН. Среда разработки может вместе с программистом понимать, где более важные элементы кода. Как-то так.
Таким макаром можно наконец-то ввести в языки программирования элементы паттернов проектирования design_pattern, списки todo_list — это элементы, которые говорят, что в коде должно что-то быть, но неконкретизируют.
Хватит закомменчивать строки! Давайте просто ключевое слово использовать типа test_instruction, правда, я думаю, не первый я это придумал, есть же чем-то похожий элемент языка assert() в С++…
Короче, нужно больше идей для метаэлементов языков программирования!
Комментарии, кстати, я предлагаю не просто вставлять посреди кода, а привязывать его к элементам языка, указывать связь. Такое тоже не ново…
Можно в стиле аннотаций это сделать.
Но реализовать это лучше на уровне IDE. Во-первых, не будет привязки к конкретному языку, а во-вторых, все эти дополнительные конструкции потребуют удобных GUI элементов.
Человек же видит то, что отображает IDE, а не текст на некотором языке (хотя многие IDE настолько тупы).
1. Обосновывающая информация (информация о системе заказчика)
1а. Таргет-информация (требования заказчика, обоснование программных решений). Примеры: «Было три варианта, этот лучший, потому что ...», «Наши аналитики провели исследование и выяснили, что оптимальное значение колеблется от 0.1 до 0.3, поэтому я выбрал 0.2».
1б. Факт-информация (фактические процессы у заказчика). Пример: «Кнопку 1 в лифте нажимают чаще других, поэтому обработчик событий ...».
2. Проективная информация. Примеры: «Вот код накидал, но не доделал», «Это я тут закомментил, когда выйдет новая фича, то надо будет раскомментировать».
Этот весь багаж знаний держится в голове у команды разработчиков, вроде больше никакой информации не циркулирует. Хорошо, когда они ее догадываются в комментарии записать.
Отдельно хотелось бы выделить проективное программирование. Это то, что реализуется todo_list, under_construction и т.п.
Поиграем?
under_construction Feature class() {} //объявили пустой класс в разработке
Feature Somefeature1 new Feature(); // ошибка компиляции
under_construction Feature Somefeature1 new Feature(); // а так можно
under_construction Somefeature1.func1(); // а так можно? или нет?Наверное надо кроме ошибок компиляции рассматривать ошибки проектирования (= предупреждение компиляции). То есть для последней строчки ошибки компиляции нет, а ошибка проектирования есть.
Проективная информация имеет довольно короткое время жизни — пока идет работа над задачей. Думаю, что в большинства случаев будет достаточно простых комментариев. Хотя, возможно, какие-то специальные комментарии-пометки IDE могла бы распознавать и обрабатывать.
Их сложно будет убедить продублировать документацию в коде.
Я бы не исключал того, что будущее программирования не просто в переносе инфы из одной системы в другую или в создании линков между системами а-ля гипертекстовых ссылок, а в полной интеграции систем, когда конструкции в одной системе порождают конструкции в другой системе. Это может сокращать срок разработки, принесет профит.
Тот же under_construction может генерироваться из бэклога таск-трекера. В бэклоге создали новую задачу по запиливанию новой фичи поддержки многоязычного интерфейса (выше мой пример с InternationalSupport) — вот тебе пожалуйста, тимлид обозначил участки кода, подлежащие реконструкции.
Довольно смелые предложения?
Проективная информация имеет довольно короткое время жизни — пока идет работа над задачей.
Работа с кодом — дорогостоящий процесс и в то же время доходный, вспомните, кто самый богатый в мире. Так что про короткое время жизни — это может и верно, но не в этом суть.
P.S. Ещё в список видов неточной информации я отнес бы пояснительную информацию. Обосновывающая информация — это информация о внешних системах (системах пользователей, заказчиков), с которыми взаимодействует программа, а пояснительная информация, наоборот, это информация о коде, о внутренней системе. Просто иногда у программиста не хватает «оперативной памяти», чтобы разобраться в коде. Пояснительную информацию стараются минимизировать по правилу «не комментируй работу кода». Однако там, где оперативки много требуется, то можно разместить поясняющую диаграмму или какой-нибудь граф.
under_construction InternationalizationSupport {Feature class() {} }
// некий код
under_construction InternationalizationSupport {Feature Somefeature1 new Feature();}
// некий код
to_exchange InternationalizationSupport {// некий компилируемый код}
by {Somefeature1.func1();}
Как-то так.
При ней
concept unpaidBill is bill where amountToPay > amountPaid;превратился бы в
concept unpaid is not paid;
property paid of bill, agent
Ваш пример похож на OWL, который применяется для создания больших онтологий. В нем есть и свойства, и инверсия свойств, и классы, и пересечения и объединения класов.
Ну а я нацелен на интеграцию данных, работу со слабоструктурированными данными, моделирование в ООП стиле, где будет удобным явное описание структур.
был сделан неутешительный вывод об отсутствии в открытом доступе работоспособной теории, объединяющей все аспекты естественного языка (ЕЯ) в единую систему и позволяющей производить строгие вычисления, необходимые для определения совпадения или различия смысла текста
Строгих вычислений быть не может)
А так да, в аксиоматических системах можно доказывать строго. В естественном языке изначальная аксиома — кто как понял, тот так и крутится. То есть все субъективно. Даже если вы изобретете машину, доказывающую что-то в ЕЯ, вы должны быть готовы, что найдется субъект, который не согласится, только потому что религия не позволяет или звёзды в небе не сошлись, и в его голове это будет правильно. А представьте себе 90% населения будут несогласны? Запросто! Так что требуется не доказательство, а имитация.
Возможно вас заинтересует проект, которым я занимаюсь. Суть его как раз в том, чтобы дать обычному пользователю интерфейс позволяющий управлять его семантической сетью из фреймов. На главной странице можно глянуть видео, как за 15 минут с нуля собрать свой менеджер задач. А тут можно глянуть презумпцию в формате json.tree, по которой строится интерфейс редактирования концептов. Он позволяет описывать свойства более наглядно. В перспективе я думаю добавить вычисляемые свойства, значения которых реактивно зависит от формулы и свойств других фреймов.
Оригинален ещё и подход к наследованию — вместо хардкода свойства "родитель-потомок" используется флаг у связи. Если он взведён, то фрейм будет брать описание свойств из фрейма, на который указывает свойство. Полезно это для кейсов вида: если для товара выбран тип "автомобиль", то у него появляются свойства автомобиля такие как "скорость", "мощность мотора", "тип двигателя". И если выбран электрический тип двигателя, то добавляется свойство "ёмкость батарей" и так далее.
Ещё я пробовал сделать rdf браузер, но всё упирается в то, что далеко не все неймспейсы выдают по своим ссылкам что-то машиночитаемое. Да и CORS многие не поддерживают. В общем, пишите, если что, сколаборируемся.
Проектируем мульти-парадигменный язык программирования. Часть 4 — Основные конструкции языка моделирования