Пора уже переходить к "программированию наоборот".
Компьютер формирует всегда абсолютно правильную программу сам, а программист подсказывает что изменить.
Не формирует программу по частичкам (как сейчас), не говорит компу сделай все сам (как видится в фантастических рассказах), а направляет комп по чуть-чуть в нужную сторону.
— Программист: Рисуй фигуру. Компьютер: Рисует круг
— П: с углами. К: рисует треугольник
— П: углов четыре. К: рисует квадрат
— П: белого цвета. К: закрашивает квадрат
Итого, образовалась программа рисования квадрат белого цвета. Безошибочная.
Задача может быть и сложнее:
— П: Делаем новый API. К: Ок
— П: На java. К: Ок
— П: RPC-JSON, а не REST. К: Ок
и т.п.
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, Буравчик, Вы писали: Б>>Когда уже такое будет?
Р>Да уже есть — функциональное программирование называется. Осталось только голосовые команды прикрутить.
В контексте топика функциональная парадигма не слишком отличается от императивной.
К подвидам декларативного программирования также зачастую относят функциональное и логическое программирование — несмотря на то, что программы на таких языках нередко содержат алгоритмические составляющие
Лично я склоняюсь к мысли, что функциональная парадигама программирования не выполняет заявленные идеи декларативного и смотреть нужно в сторону логического. Один из языков логического программирования — Prolog.
Б>Когда уже такое будет?
Если это не какой-нибудь генератор кода, то вряд ли скоро. В связи с этим хотелось бы ещё отметить парадигму метапрограммирования. Теоретически на нём можно сделать обвязку для всех языков и библиотек, но практически это очень ресурсоёмкая задача.
Никогда.
Потому что получим ситуацию из анекдота про магазин с уточняющими вопросами, когда мужик и унитаз притащил, и жопу показывал, а ему туалетную бумагу так и не продали.
Недавняя ситуация: Делал трекинг выделяемой и освобождаемой памяти в ядре. Чтобы знать, кто и когда блок трогал, и подробности операций иметь, раскрутив стек. Трекаю область размером 4гб. Сделал трехуровневую sparsed струтуру а-ля page tables у процессоров. Чтобы и данные плотно упаковались, и индексация за константное время несколькими битовыми операциями.
Как ты это объяснять будешь и сколько это времени займёт ?
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Буравчик,
Б>>Когда уже такое будет?
IID>Никогда. IID>Потому что получим ситуацию из анекдота про магазин с уточняющими вопросами, когда мужик и унитаз притащил, и ........ показывал, а ему туалетную бумагу так и не продали.
IID>Недавняя ситуация: Делал трекинг выделяемой и освобождаемой памяти в ядре. Чтобы знать, кто и когда блок трогал, и подробности операций иметь, раскрутив стек. Трекаю область размером 4гб. Сделал трехуровневую sparsed струтуру а-ля page tables у процессоров. Чтобы и данные плотно упаковались, и индексация за константное время несколькими битовыми операциями. IID>Как ты это объяснять будешь и сколько это времени займёт ?
Когда ТС погрузится в такие же дебри разработки софта, о которых ты пишешь, а не будет сидеть где-то наверху, лабая простейшие свистелки на куче API, тогда у него подобных мыслей просто не возникнет, а если возникнет, то он только посмеётся над ними.
Б>Итого, образовалась программа рисования квадрат белого цвета. Безошибочная.
... и никому ненужная
Б>Задача может быть и сложнее: Б>- П: Делаем новый API. К: Ок Б>- П: На java. К: Ок Б>- П: RPC-JSON, а не REST. К: Ок Б>и т.п.
а дальше?
Б>Когда уже такое будет?
уже есть :
Здравствуйте, Буравчик, Вы писали:
Б>Пора уже переходить к "программированию наоборот".
Б>Компьютер формирует всегда абсолютно правильную программу сам, а программист подсказывает что изменить. Б>Не формирует программу по частичкам (как сейчас), не говорит компу сделай все сам (как видится в фантастических рассказах), а направляет комп по чуть-чуть в нужную сторону.
Б>- Программист: Рисуй фигуру. Компьютер: Рисует круг Б>- П: с углами. К: рисует треугольник Б>- П: углов четыре. К: рисует квадрат Б>- П: белого цвета. К: закрашивает квадрат
Б>Итого, образовалась программа рисования квадрат белого цвета. Безошибочная.
Б>Задача может быть и сложнее: Б>- П: Делаем новый API. К: Ок Б>- П: На java. К: Ок Б>- П: RPC-JSON, а не REST. К: Ок Б>и т.п.
Б>Когда уже такое будет?
Это не "наоборот", а обычное программирование. Нужно нарисовать фигуру — берёшь библиотеку рисования фигур и она "безошибочно" это делает. Сложность указывания, что именно программа должна делать и возможность ошибок в инструкция от добавления распознавания речи никуда не денутся.
Здравствуйте, Буравчик, Вы писали:
Б>Когда уже такое будет?
Давайте сразу предположим, что такое есть.
Все программы "вырастают" из простейшей int main() {return 0;} путём последовательности трансформаций.
В чём будет подвох?
Принципиальный — в том, что каждый шаг трансформации обязан сохранять валидность программы. Сразу видим, что подобным способом можно породить только те программы, которые входят в "область связности" исходной программы.
Совершенно неочевидно, что эта область связности покрывает абсолютно все нужные нам программы.
Простейший аналог: если задать начальное слово, и разрешить менять по 1й букве на каждом шаге, требуя, чтобы результат оставался в пределах словаря, то из МОРЕ сделать ГОРА получится, а вот ПИВО — уже нет.
Напомню, что в обычном программировании объём правок между последовательными сборками может быть любым; мы не обязаны соблюдать никакую непрерывность.
Менее принципиальный, но ещё более действенный подвох — неудобство.
Сейчас программист думает в терминах структуры программы — что ему нужно написать, чтобы программа сделала то, что нужно.
В вашем подходе программист будет вынужден думать не только об этом, но и о том, в каком порядке вносить изменения.
Как ему сделать из программы, которая рисует круг, робота для торговли на бирже.
Опять же, на пальцах: понять, где должна стоять каждая фитюлинка в кубике Рубика, можно без подготовки. А вот придумать последовательность шагов, которые собирают кубик — это уже challenge.
Вы предлагаете заменить упраждение по наклеиванию квадратиков на стороны упражнением по сборке кубика.
Отличный способ просадить продуктивность на порядки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Буравчик, Вы писали:
Б>Пора уже переходить к "программированию наоборот".
Б>Компьютер формирует всегда абсолютно правильную программу сам, а программист подсказывает что изменить.
Б>Когда уже такое будет?
Программист тут не будет нужен, подсказывать сможет любой эндюзер.
Наконец то сбудется то что предсказывали с 80-x.
Это конец профессии.
НУ и осталось всего лишь сделать программу которая будет подстказывать той что ихменить.
Никогда. Потому что даже твоя «абсолютно правильная» простейшая программа вызывает множество неразрешимых вопросов. Собственно:
Б>Компьютер формирует всегда абсолютно правильную программу сам, а программист подсказывает что изменить.
Что такое «абсолютно правильная программа»? Этот термин идентичен сферовакуумному коню. Итак:
Б>- Программист: Рисуй фигуру. Компьютер: Рисует круг
Почему круг? Почему не овал? Не Шар? Не Додекаэдр? Не линию? Ну и т.п.
Б>- П: с углами. К: рисует треугольник
Почему треугольник? Почему не четырех-, пяти-, 128-, n-угольник? Почему не додекаэдр?
Хорошо, треугольник. Прямой? Равносторонний? Равнобедренный? С одним тупым углом?
Б>- П: углов четыре. К: рисует квадрат
Почему квадрат? Почему не трапецию? Ромб? Прямоугольник? Почему обязательно прямые линии?
Б>- П: белого цвета. К: закрашивает квадрат
Закрашивает, включая грани, или исключая?
Б>Итого, образовалась программа рисования квадрат белого цвета. Безошибочная.
Образовалась программа рисования неизвестно чего. С указанными инструкциями вот это тоже безошибочный результат:
Здравствуйте, MamutArGud, Вы писали:
MAG>Почему круг? Почему не овал? Не Шар? Не Додекаэдр? Не линию? Ну и т.п. MAG>Почему треугольник? Почему не четырех-, пяти-, 128-, n-угольник? Почему не додекаэдр? MAG>Хорошо, треугольник. Прямой? Равносторонний? Равнобедренный? С одним тупым углом? MAG>Почему квадрат? Почему не трапецию? Ромб? Прямоугольник? Почему обязательно прямые линии?
Потому что человек обычно хочет именно это.
В этом и есть сложность такой системы — угадывать (предсказывать) хотелки из существующих условий.
И да, может система даже должна подстраиваться под человека.
Для одного нарисовать круг, а для другого — овал.
MAG>>Почему круг? Почему не овал? Не Шар? Не Додекаэдр? Не линию? Ну и т.п. MAG>>Почему треугольник? Почему не четырех-, пяти-, 128-, n-угольник? Почему не додекаэдр? MAG>>Хорошо, треугольник. Прямой? Равносторонний? Равнобедренный? С одним тупым углом? MAG>>Почему квадрат? Почему не трапецию? Ромб? Прямоугольник? Почему обязательно прямые линии?
Б>Потому что человек обычно хочет именно это.
Не будем говорить за всех людей. Мне, например, очень редко нужно именно это, и именно в таком порядке.
Б>В этом и есть сложность такой системы — угадывать (предсказывать) хотелки из существующих условий. Б>И да, может система даже должна подстраиваться под человека. Б>Для одного нарисовать круг, а для другого — овал.
Ну то есть нет никакой "абсолютно правильной программы", а внезапно она становится «относительно правильной программой» потому что одинаковые инструкции двух разных людей приведут к созданию двух разных программ. Потому что для одного программа угадала, что надо начинать с круга, а для другого — с теста Роршаха.
Здравствуйте, MamutArGud, Вы писали:
MAG>Не будем говорить за всех людей. Мне, например, очень редко нужно именно это, и именно в таком порядке.
Мне тоже очень-очень редко приходилось рисовать круги.
Смотри на проблему шире.
MAG>Ну то есть нет никакой "абсолютно правильной программы", а внезапно она становится «относительно правильной программой» потому что одинаковые инструкции двух разных людей приведут к созданию двух разных программ. Потому что для одного программа угадала, что надо начинать с круга, а для другого — с теста Роршаха.
Правильная программа — это та, в которой нет ошибок (ну ок, ок, минимум ошибок).
Т.е. если круг нарисован, то он идеально ровный. И в квадрате все стороны равны и параллельны осям.
Потому что математика.
Если слон — то с хоботом, с четырьмя ногами и розовый (потому что программист на кывт зарегистрирован)
MAG>>Не будем говорить за всех людей. Мне, например, очень редко нужно именно это, и именно в таком порядке.
Б>Мне тоже очень-очень редко приходилось рисовать круги. Б>Смотри на проблему шире.
Я на нее и посмотрел. Задал вопросы. Внезапно (при том, что даже тебе редко приходилось рисовать круги) твоя абсолютно правильная программа рисует круги потому что «человек обычно хочет именно это.»
MAG>>Ну то есть нет никакой "абсолютно правильной программы", а внезапно она становится «относительно правильной программой» потому что одинаковые инструкции двух разных людей приведут к созданию двух разных программ. Потому что для одного программа угадала, что надо начинать с круга, а для другого — с теста Роршаха.
Б>Правильная программа — это та, в которой нет ошибок (ну ок, ок, минимум ошибок).
Правильная программа — эта та, что без ошибок выполняет поставленную задачу.
Б>Т.е. если круг нарисован, то он идеально ровный. И в квадрате все стороны равны и параллельны осям. Б>Потому что математика.
Да, только при этом эта программа будет на 100% ошибочной, потому что мне не нужен круг. И остается самый первый вопрос: почему на запрос «нарисуй фигуру» программа должна рисавать идеальный круг? Или квадрат? В математике есть множество фигур. Steinmetz 2-solid или там Archimedean solids — это тоже математика. Не говоря уже о Бэтмане.
Б>Если слон — то с хоботом, с четырьмя ногами и розовый (потому что программист на кывт зарегистрирован)
Какой слон? Африканский или индийский? Какой оттенок розового (у Pantone их 30 штук)? Возраст слона? Пол слона?
Здравствуйте, Буравчик, Вы писали:
Б>Пора уже переходить к "программированию наоборот".
Б>Компьютер формирует всегда абсолютно правильную программу сам, а программист подсказывает что изменить. Б>Не формирует программу по частичкам (как сейчас), не говорит компу сделай все сам (как видится в фантастических рассказах), а направляет комп по чуть-чуть в нужную сторону.
Б>- Программист: Рисуй фигуру. Компьютер: Рисует круг Б>- П: с углами. К: рисует треугольник Б>- П: углов четыре. К: рисует квадрат Б>- П: белого цвета. К: закрашивает квадрат
Б>Итого, образовалась программа рисования квадрат белого цвета. Безошибочная.
Б>Задача может быть и сложнее: Б>- П: Делаем новый API. К: Ок Б>- П: На java. К: Ок Б>- П: RPC-JSON, а не REST. К: Ок Б>и т.п.
Б>Когда уже такое будет?
Здравствуйте, Sinclair, Вы писали:
S>Принципиальный — в том, что каждый шаг трансформации обязан сохранять валидность программы. Сразу видим, что подобным способом можно породить только те программы, которые входят в "область связности" исходной программы. S>Совершенно неочевидно, что эта область связности покрывает абсолютно все нужные нам программы.
Очевидно, что исходную пустую программу можно доразвить до машину Тьюринга, а дальше выразимы все алгоритмы.
Так что в "область связности" входит всё вычислимое...
S>Отличный способ просадить продуктивность на порядки.
+100500
Но это зависит от того, кто программирует. Некоторым людям такой подход будет органичен, а обычный вообще недоступен. И таких людей больше, чем таких, кому нынешнее программирование хорошо даётся
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Программирование наоборот -- это реверсинженеринг, а тебе надо обучение...
Здравствуйте, Буравчик, Вы писали:
Б>Когда уже такое будет?
Такое уже давно есть. Только это не применяют для задач, вроде "разработать рисовалку зелёных квадратов", а применяют для задач вроде "разработать автопилот для автомобиля" или "разработать детектор раковых заболеваний по рентгеновским снимкам".
ML называется
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском