Что мешает писать программы автоматически?
Мне кажется, что формализация задачи выльется в конечном итоге в программу того или иного языка программирования. 
почему эта формализация не появляется автоматически? ведь этих форумов уже есть тысячи готовых, а значит есть тысячи готовых формализаций
Не помню, кажется, я уже постил это, но повторюсь...
Framework и генерация кода под задачу - это диаметрально противоположные вещи.
Не хватает фреймворка с функцией DWIM
Во-первых, форум - это уже не модно. Во-вторых, если тебе нужен форум - зачем его писать? Берёшь готовый (один из тысячи настраиваешь, допиливаешь, доделываешь чего не хватает, делаешь новый модуль к нему. Вообще, по-моему нужны очень веские основания для того, чтобы программить с нуля то, что в принципе и так уже есть.
почему эта формализация не появляется автоматически?А это уже ИИ.
ведь этих форумов уже есть тысячи готовых, а значит есть тысячи готовых формализацийЗадача "хочу, чтобы было как там" решается в простейшем случае полным копированием.
Иначе уже возникают куча нюансы. Что такое ошибки (которые не надо воспроизводить что-то нравится, что-то не нравится. Мне кажется если углубляться, то тут до полноценного ИИ придётся дойти.из твоего описания даже юзкейс непонятен - весьма неоднозначно можно додумать - какие данные такая система должна получать на вход
тем более не получится придумать что-то конструктивное на тему - "почему такое не сделали"
а если совсем абстрактно, то совершенно не ясно, почему общение с системой, умеющей "автоматически писать программы" будет проще, чем непосредственное написание программ
ну и вообще - ты пишешь на С++, а система (компилятор) автоматически пишет программу на машинном коде. чем такая связка концептуально отличается от того, что ты имеешь ввиду?
тем более не получится придумать что-то конструктивное на тему - "почему такое не сделали"
а если совсем абстрактно, то совершенно не ясно, почему общение с системой, умеющей "автоматически писать программы" будет проще, чем непосредственное написание программ
ну и вообще - ты пишешь на С++, а система (компилятор) автоматически пишет программу на машинном коде. чем такая связка концептуально отличается от того, что ты имеешь ввиду?
почему общение с системой, умеющей "автоматически писать программы" будет проще, чем непосредственное написание программнапример, если дать задачу приблизить некую функцию по табличным данным (а в реальности это будет f(x)=x^2)
то чувак без ограничений на методы посмотрит на график и выдаст ответ за 1 минуту,
чувак, которому скажут решать задачу численными методами, построит аппроксимационный алгоритм, потратив, допустим день
а чувак, которому скажут использовать машинное обучение, может потратить неделю, чтобы разбираться с алгоритмами, с тем который лучше использовать и как его настроить, чтобы получать приемлемый ответ
Это заговор просто, чтобы программисты работы не лишились.
В 1974 году Эдвард Коллинз из Техаса решил эту задачу, построив универсальный генератор программ. Его убили, конечно.
В 1974 году Эдвард Коллинз из Техаса решил эту задачу, построив универсальный генератор программ. Его убили, конечно.
то совершенно не ясно, почему общение с системой, умеющей "автоматически писать программы" будет проще, чем непосредственное написание программНу вот я как раз это и имел в виду, что "формализация приведёт к программе". Хотя тут ещё вопрос что могли бы существовать всякие декларативные языки, которые уже переводятся в программы. Но видимо алгоритмические языки людям оказалось проще использовать, чем декларативные или декларативные общего назначения не очень получается сделать.
Кстати, что уж говорить, если даже везде пишут, что клиенты не могут с программистами договориться о том, что за программу они хотят получить. А уж чтобы компьютер понял — это уже не просто искусственный интеллект нужен, а искусственный сверхинтеллект.
Решаемая задача - та же самая. Упростить или исключить написание кода.
Вплоть до того, что вполне есть себе фреймворки с тулзами генерящими код. А-ля всякие визивиг редакторы формочек итп.
Вплоть до того, что вполне есть себе фреймворки с тулзами генерящими код. А-ля всякие визивиг редакторы формочек итп.
А генератор программ был продан в рабство в индию
Мне не нравится, что с кодом сейчас дело обстоит следующим образом: чем больше кода, тем сложнее его применить к новой задаче (этим же грешать framework-и: чем больше framework, тем сложнее его применить к чему-то новому). И этот эффект является полной противоположностью эффекта знаний: чем больше знаний, тем проще их применить к новой задаче.
Такое сильное несоответствие намекает на то, что сейчас код строится совсем не на тех принципах, что стоило бы.
Такое сильное несоответствие намекает на то, что сейчас код строится совсем не на тех принципах, что стоило бы.
имхо это не совсем правда
если взять тот же форум:
20 лет назад его надо было писать на плюсах (см физтеховский форумный движок)
10 лет назад можно было взять готовый на перле или vbulletin какой
сейчас на каком-н RoR можно свой с блэкджеком сваять за недельку
мне кажется, что технологии развиваются, просто они развиваются не одномоментно: когда появились первый версии jboss люди ими сразу пользовались, и эти версии были говно. Но прошло 10 лет и оно устаканилось, стало более mature и им уже действительно можно пользоваться. И так со всем: начиная от биоса и заканчивая оболочками домашних роутеров.
У меня складывается ощущение, что любой новой идее нужно лет 5 на то, чтобы дойти до ума.
если взять тот же форум:
20 лет назад его надо было писать на плюсах (см физтеховский форумный движок)
10 лет назад можно было взять готовый на перле или vbulletin какой
сейчас на каком-н RoR можно свой с блэкджеком сваять за недельку
мне кажется, что технологии развиваются, просто они развиваются не одномоментно: когда появились первый версии jboss люди ими сразу пользовались, и эти версии были говно. Но прошло 10 лет и оно устаканилось, стало более mature и им уже действительно можно пользоваться. И так со всем: начиная от биоса и заканчивая оболочками домашних роутеров.
У меня складывается ощущение, что любой новой идее нужно лет 5 на то, чтобы дойти до ума.
20 лет назад его надо было писать на плюсах (см физтеховский форумный движок)Ключевое в этом то, что ранее написанный код никак не помогает при написании новой итерации на обновленных технологиях. Что опять же является полной противоположностью применению знаний: тот же опыт, наоборот, помогает - и это намекает, что в коде пишется совсем не то, что следовало бы записывать.
10 лет назад можно было взять готовый на перле или vbulletin какой
сейчас на каком-н RoR можно свой с блэкджеком сваять за недельку
Если знаний много, то чтобы их эффективно применять надо долго учиться.
Так же с фреймворками имхо. Чем больше фреймворк - тем дольше надо учиться в нем ориентироваться...
Так же с фреймворками имхо. Чем больше фреймворк - тем дольше надо учиться в нем ориентироваться...
Ключевое в этом то, что ранее написанный код никак не помогает при написании новой итерации на обновленных технологиях. Что опять же является полной противоположностью применению знаний: тот же опыт, наоборот, помогает - и это намекает, что в коде пишется совсем не то, что следовало бы записывать.Тебе никогда не доводилось слышать фразу "А теперь забудьте всё, чему вас учили в 8 классе/школе/на первом курсе/в универе/..."? =) Иногда одна концепция сменяется другой так, что связи между ними настолько неочевидны, что проще старую концепцию просто забыть
Что же не хватает для перевода желания "Хочу еще один форум" в автоматическую генерацию кода под это?"Хочу еще один форум" это ТЗ такое?
ИМХО ответ на твой вопрос: Мешает "согласование требований". Тут пока без человека никак не обойтись.
Мне не нравится, что с кодом сейчас дело обстоит следующим образом: чем больше кода, тем сложнее его применить к новой задаче (этим же грешать framework-и: чем больше framework, тем сложнее его применить к чему-то новому). И этот эффект является полной противоположностью эффекта знаний: чем больше знаний, тем проще их применить к новой задаче.Ну вообще код со знаниями сравнивать не очень корректно, мне кажется. Конечно, у них есть общие черты. И то и другое является информацией. Но тут код можно было бы сравнить с домами. Тогда выражения вроде "существующий код нельзя применить к новой задаче" будут выглядеть вполне гармонично в таком контексте.
Ну то есть почему ты считаешь, что код и знания — это одно и то же и сравниваешь их?
Ну то есть почему ты считаешь, что код и знания — это одно и то же и сравниваешь их?Ключевой переуточненный вопрос звучит так:
как надо записать знания о программе (и программировании) так, чтобы на основе этого можно было автоматически получить код под конкретную задачу?
какие фундаментальные причины мешают сделать такую запись?
как надо записать знания о программе (и программировании) так, чтобы на основе этого можно было автоматически получить код под конкретную задачу?ты так и не написал - что для тебя значит "автоматически" на практике
какие фундаментальные причины мешают сделать такую запись?
есть, например, такая штука как BDD - behavior driven developement. Когда вводится DSLка такая, что на ней более менее комфортно говорить и CEO и бизнес-аналитикам и программистам - этакий новояз - урезанная копия языка с четкой и жесткой семантикой. На нем пишется, как должна себя вести программа в тех или иных условиях - иными словами - набор тестов.
И он занимает сотни страниц для сколько-нибудь серьезной задачи. А это ведь по факту и есть - подробное описание того, что должна делать программа.
Из такой, при должном старании, можно сваять и автоматическую кодогенерацию - но это все равно просто еще один язык программирования с большим большим объемом "кода".
А задача из абзаца текста получить готовую программу называется кнопочкой "сделать охуенно" и в реальном мире не встречается.
И он занимает сотни страниц для сколько-нибудь серьезной задачи. А это ведь по факту и есть - подробное описание того, что должна делать программа.
Из такой, при должном старании, можно сваять и автоматическую кодогенерацию - но это все равно просто еще один язык программирования с большим большим объемом "кода".
А задача из абзаца текста получить готовую программу называется кнопочкой "сделать охуенно" и в реальном мире не встречается.
Хотя если честно, не выглядит теоретически невозможным что-то, потипу того, что если на входе подаешь
"хочу телевизор, который умеет делать омлет" - из базы схем возьмутся схемы телевизора и мультиварка, смержатся и по какому-то принципу соптимизируются и получится на выходе если не готовый продукт, то хотя бы функциональный прототип, который нужно будет допиливать.
Но масштаб решаемых при этом задач даже мысленно представить сложно)
"хочу телевизор, который умеет делать омлет" - из базы схем возьмутся схемы телевизора и мультиварка, смержатся и по какому-то принципу соптимизируются и получится на выходе если не готовый продукт, то хотя бы функциональный прототип, который нужно будет допиливать.
Но масштаб решаемых при этом задач даже мысленно представить сложно)
Есть такая штука как компилируемые требования или спецификации. Почти человеческий язык. Но на нём можно задавать тесты (и то не полностью а не реализацию.
Почти человеческий язык.человеческий язык херня http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...
ты так и не написал - что для тебя значит "автоматически" на практикезадание программы через хочу (формулирования требований к результату) с автоматическим на основе best practices заполнением логических пропусков и разрешением конфликтов.
И он занимает сотни страниц для сколько-нибудь серьезной задачи.вот это, кстати, не понятно... Зачем нужны сотни страниц спецификаций для постановки задачи? Ведь большая часть такой спецификации напрямую вытекает из требования "Сделать заебись!", а оставшая часть есть следствие текущих ограничений окружающего мира.
Это потому что ты пример выбрал неправильный. Тебе нужно сделать форум. Чтоб "всё было заебись". В то время как форум уже давно сделан и не один раз, а главное - давно понятно, что должно быть в форуме, и что там за best practices. Ну, то есть не надо писать в ТЗ, что там должны быть аватарки, приватные сообщения, система рейтингов/званий, роли, банхаммер. И главное, когда я пишу "банхаммер" - в целом понятно, что я имею в виду. А теперь представь себе, что мы делаем принципиально новую систему (чем в идеале и должны заниматься программисты, а не передирать уже готовое у конкурентов либо это новое для нас - интернет-форум. Т.е. форумов ещё нет, а есть идея - надо сделать такую штуку, чтобы люди могли коллективно (сотни, тысячи человек) обсуждать разные вопросы. И чтоб всё было офигенно. И вот чтобы это развернуть - нужны очень подробные, очень формализованные описания. Вплоть до того, как работает банхаммер, как редактируются посты, как регулируются права юзеров и т.д.
А теперь представь себе, что мы делаем принципиально новую системуи там будет 99% всё того же:
документы, юзеры, обмен сообщениями, администрирование - если это что-то для людей,
или ресурсы, цели, сбор данных, балансировка и оптимизация - если это что-то автоматическое.
(формулирования требований к результату)А на каком языке ты будешь формулировать требования?
Классически - это ведь составлять т.з.
Написать исчерпывающее тз (а именно такое понадобится для машины например, к форуму в 99% случаев будет точно сложнее чем взять готовый форум и подкрутить его руками.
Написать исчерпывающее тз (а именно такое понадобится для машины например, к форуму в 99% случаев будет точно сложнееимхо, такое исчерпывающее описание необходимо только на одном первом проекте. На всех остальных проектах будет тоже самое. Человечество за тысячелетия так ничего нового и не придумало, кроме всё тех же банальных требований: цена, качество, сроки.
Написать исчерпывающее тз (а именно такое понадобится для машины например, к форуму в 99% случаев будет точно сложнее чем взять готовый форум и подкрутить его руками.Готовые, готовые ... можно подумать всё так хорошо. А как начнешь пробовать что-то готовое, так окажется, что говнецо. Начнешь дописывать... Но, как известно, из говна конфетку не сделаешь. Вот разработчик ушел из stackoverflow и основал компанию, которая как раз занимается разработкой форумов. Оказалось, что там же работает один из разработчиков Ember.js. Те, кто умеет прогать, делают сами. А брать готовое это удел школоты.
Те, кто умеет прогать, делают сами. А брать готовое это удел школоты.Чёрт, всегда думал, что наоборот =) Это школота свой собственный CString делает. Ну, либо динозавры индустрии, у которых код идёт ещё с тех пор, когда std::string не было в стандарте
И как-то не хватало времени на рефакторинг.Ну то есть почему ты считаешь, что код и знания — это одно и то же и сравниваешь их?если код - это не знания, то тогда основной вопрос: какая фундаментальная причина мешает записывать знания о коде, вместо самого кода, а потом из этих знаний автоматически получать код?
В 1974 году Эдвард Коллинз из Техаса решил эту задачу, построив универсальный генератор программ. Его убили, конечно.А сам генератор спрятали и с тех пор втайне пользуются им, чтобы он писал за них программы, пока они смотрят котиков.
А задача из абзаца текста получить готовую программу называется кнопочкой "сделать охуенно" и в реальном мире не встречается.Открой для себя технологии Apple!
если код - это не знания, то тогда основной вопрос: какая фундаментальная причина мешает записывать знания о коде, вместо самого кода, а потом из этих знаний автоматически получать код?Что ты привязался к причинам. Если ты не последователь пенроуза, то можно предположить, что таковых причин нет. Т.е. можно создать искусственный интеллект эквивалентный человеческому. Вот он и будет делать твои хотелки. Можешь заняться его созданием.
автоматически получитьКто что имеет в виду под этим?
Что ты привязался к причинам.потому что решение сложной задачи всегда начинается с выяснения базового противоречия.
как надо записать знания о программе (и программировании) так, чтобы на основе этого можно было автоматически получить код под конкретную задачу?фундаментальная причина - неединственность оптимального решения.
какие фундаментальные причины мешают сделать такую запись?
на примере форумов, необходим критерий выбора оптимальной реализации форума для ограничений введенных постановкой задачи, либо стандарт, который однозначно формулирует что является форумом. вот тогда можно генерировать форумы автоматически.
код не тянет на аналог знаний
это больше аналог научных статей, которых как известно очень много и 99% из них мусор.базовое противоречие - уровень формализации, не? типа чем меньше формализации и четкости в постановке задачи, тем больше нужно человеческого труда, чтобы максимально формализовать задачу(по сути закодировать дабы ее выполнил компьютер.
Что нужно? Нужен искуственный интеллект, который не выполняет алгоритм, а сводит неформальное описание к максимально формальному.
Что нужно? Нужен искуственный интеллект, который не выполняет алгоритм, а сводит неформальное описание к максимально формальному.
фундаментальная причина - неединственность оптимального решения.следует ли из этого, что можно сгенерить субоптимальное или неоптимальное решение?
следует ли из этого, что можно сгенерить субоптимальное или неоптимальное решение?если задача решена, то да.
форумы же существуют, значит неоптимальные решения есть - выбирай случайное и всё.
это уже выбор из существующих вариантов, а не генерация кода.
полностью задача выглядит следующим образом:
есть постановка:
Хочу форум с определенными ограничениями (например, чтобы форум был на языке D с базой MySql со структурой форум->тред->сообщение с анонимными сообщениями (сообщения не привязаны к конкретному пользователю)
Комп сгенерируй, пожалуйста, автоматически код под такую постановку.
и твой тезис:
задача не может быть решена, потому что оптимальное решение не единственное.
И соответственно мой вопрос:
неоптимальное решение сгенерировать можно?
если ответ "тоже нельзя", то тогда возвращаемся к вопросу:
какая фундаментальная причина мешает получить неоптимально сгенерированный код под заданную постановку?
полностью задача выглядит следующим образом:
есть постановка:
Хочу форум с определенными ограничениями (например, чтобы форум был на языке D с базой MySql со структурой форум->тред->сообщение с анонимными сообщениями (сообщения не привязаны к конкретному пользователю)
Комп сгенерируй, пожалуйста, автоматически код под такую постановку.
и твой тезис:
задача не может быть решена, потому что оптимальное решение не единственное.
И соответственно мой вопрос:
неоптимальное решение сгенерировать можно?
если ответ "тоже нельзя", то тогда возвращаемся к вопросу:
какая фундаментальная причина мешает получить неоптимально сгенерированный код под заданную постановку?
пожалуйстаC этого и надо было начинать.
потому что решение сложной задачи всегда начинается с выяснения базового противоречия.Так противоречие очень простое. Компы на данный момент могут программироваться только очень жесткими формальными языками, а ты хочешь, чтобы они понимали человеческий язык, в котором используется контекст и отражены законы реального мира.
Сразу же ответ на следующий вопрос - можно ли сделать что-то промежуточное. Ответ, нет нельзя, потому что проблема понимания естественного языка и общения на нем настолько сложна, что невозможно на текущем этапе даже понять, что нужно делать.
что невозможно на текущем этапе даже понять, что нужно делать.понятно, что задача не имеет решения, но
Вот это ты не признаешь за причину?
фундаментальная проблема в том, что неформальное описание даже разные люди поймут по-разному. А ты хочешь, чтобы это понял выполняющий жестко-формальные интсрукции компьютер.
Компы на данный момент могут программироваться только очень жесткими формальными языками
фундаментальная проблема в том, что неформальное описание даже разные люди поймут по-разному. А ты хочешь, чтобы это понял выполняющий жестко-формальные интсрукции компьютер.
Мне более менее понятно почему тяжело создать формальное описание неформального естественного языка. Основная причина слишком много понятий, которые находятся за пределами компьютера (другими словами, компьютеру их тяжело "потрогать" самостоятельно).
Но непонятно, что мешает заформализовать понятия, которые используются при написании программ. В целом, их не так много: числа, множества, последовательности, память/состояние, поток управления, пространства, ресурсы и т.д.
Но непонятно, что мешает заформализовать понятия, которые используются при написании программ. В целом, их не так много: числа, множества, последовательности, память/состояние, поток управления, пространства, ресурсы и т.д.
Но непонятно, что мешает заформализовать понятия, которые используются при написании программ. В целом, их не так много: числа, множества, последовательности, память/состояние, поток управления, пространства, ресурсы и т.д.так они заформализованы более-менее. Только их совсем не хватает, чтобы неформально описать задачу "сгенерируй мне форум с блекджеком и поэтэссами".
Можно ими описать формально такой форум. Получим очередную реализацию форума в коде, т.е. формальных понятиях.
так они заформализованы более-менее.пример такой формализации?
ps
для формализованных принятий решений (что и представляет из себя генерация кода) - необходима формализация причино-следственных связей. А этого как раз и нет
т.е. типы данных - это не формализованные числа, множества и т.д.?
Поясни, как должны быть формализованны причинно-следственные связи? не получится ли так, что на этом этапе у нас уже возникнет неоднозначность, а значит проблема с формализацией.
Поясни, как должны быть формализованны причинно-следственные связи? не получится ли так, что на этом этапе у нас уже возникнет неоднозначность, а значит проблема с формализацией.
т.е. типы данных - это не формализованные числа, множества и т.д.?нет, конечно.
до этого несколько раз заходила речь о знании. Одно из основных свойств знания, что оно умеет отвечать на вопросы: в чем схожесть, и в чем отличие между X и Z?
Текущие типы такого ответа совсем не дают. С помощью них нельзя получить ответ на вопрос: в чем отличие между int и byte? в чем отличие между char* и string? между Queue и ReadOnlyCollection? между int и DateTime?
а без такой информации невозможно принять решения.
давай тогда начнем с формализации понятия "отличие". ЧТо это такое, как выражается, сколько вообще отличий должно быть?
есть постановка:Вот смотри, я написал функцию, которая считает n-e число Фибоначчи
Хочу форум с определенными ограничениями (например, чтобы форум был на языке D с базой MySql со структурой форум->тред->сообщение с анонимными сообщениями (сообщения не привязаны к конкретному пользователю)
Комп сгенерируй, пожалуйста, автоматически код под такую постановку.
private static int Fib(int n)
{
if (n == 0)
{
return 0;
}
var p0 = 0;
var p1 = 1;
while (n > 1)
{
var p = p0 + p1;
p0 = p1;
p1 = p;
n--;
}
return p1;
}
Теперь я хочу, чтобы было то же самое, но первые два члена последовательности не 0 и 1, а 5 и -6, и чтобы int не переполнялся.
Формализуй мое хотение так, чтобы программа-программист мне написала эту функцию.
есть постановка:переведи свои требования на язык D и автоматически получишь решение
Хочу форум с определенными ограничениями (например, чтобы форум был на языке D с базой MySql со структурой форум->тред->сообщение с анонимными сообщениями (сообщения не привязаны к конкретному пользователю)
Комп сгенерируй, пожалуйста, автоматически код под такую постановку.
если в языке D есть такие понятия, как "форум", "тред", "сообщение", "пользователь", и наконец "хочу", то перевод будет простой, если нет, то придётся напрячься, вариантов перевода в понятия языка D будет много. И это ещё без учёта правил грамматики
в русско-английском словаре несколько сотен тысяч слов, но всё равно перевод не всегда однозначный, тем более автоматический.
научи компьютер большему числу слов и всего делов.
И соответственно мой вопрос:можно. напиши компьютеру в редакторе "хочу форум и т.д.", скомпилируй, он выдаст решение.
неоптимальное решение сгенерировать можно?
Дальше пообщайся с ним по-человечески, разъясни всё что имеешь ввиду и придешь к оптимальному для тебя решению.
напиши компьютеру в редакторе "хочу форум и т.д.", скомпилируй, он выдаст решение.
Дальше пообщайся с ним по-человечески, разъясни всё что имеешь ввиду и придешь к оптимальному для тебя решению.
Такая фича была в суперкомпьютере Cray. Он был таким большим, что внутри помещались два человека, которые и занимались формализацией команд. К сожалению, портировать это решение на десктопные компьютеры не удалось.
Такая фича была в суперкомпьютере Cray. Он был таким большим, что внутри помещались два человека, которые и занимались формализацией команд. К сожалению, портировать это решение на десктопные компьютеры не удалось.Надо вспомнить, что еще в XVIII веке по такому принципу строились автоматы, умеющие играть в шахматы. Мы опять утеряли знание древних!
давай тогда начнем с формализации понятия "отличие". ЧТо это такое, как выражается, сколько вообще отличий должно быть?Разница (она же отличие, дельта и т.д.) - это аксиоматическое неопределяемое понятие. Можно лишь дать его описание.
Разница - это операция подобная операции "вычитание". Разница между 1 и 3 есть 2. Разница между множествами (a, c) и (a, d) есть (c, -d)
Операция "разница" имеет спецификацию (T, T) -> dT, и имеет комплементарную операцию "Дополнение" со спецификацией (T,dT) -> T. Есть свойство, что дополнение(A, разница(A,B = B. Есть понятие нулевого элемента и т.д.
Формализуй мое хотение так, чтобы программа-программист мне написала эту функцию.для начала вместо кода для вычисления n-го элемента, стоило зафиксировать, что:
фибоначи - есть генерируемая последовательность с кадром в три элемента и сдвигом кадра на 1 элемент, где последний элемент в кадре зависит определенным образом от двух предыдущих (x3 = x1 + x2)
соответственно, из такого определения становится понятным, как выполнить задачу: продолжить фибоначи последовательность, начиная с элементов 5, -6
чтобы int не переполнялсяформально это звучит следующим образом, для вычисления последовательности взять целочисленный числовой тип с областью определения (-inf, +inf). Под это подходит тип BigInteger
переведи свои требования на язык D и автоматически получишь решениеЗачем такое надо делать? Требования-то к форуму от языка не зависят.
Вообще, разница между языками очень незначительная. Есть только разница в синтаксисе и в поддерживаемом базовом наборе операций/понятий.
Зачем такое надо делать? Требования-то к форуму от языка не зависят.в твоей постановке указан конкретный язык, иначе бери любой форум и решение готово.
Вообще, разница между языками очень незначительная. Есть только разница в синтаксисе и в поддерживаемом базовом наборе операций/понятий.если всё просто, то нужен переводчик между языками и переводи уже реализованный форум на требуемый язык.
если всё просто, то нужен переводчик между языками и переводи уже реализованный форум на требуемый язык.межязыковый транслятор - это не то, что хочется. При этом происходит потеря информации, как при испорченном телефоне.
Зачем такое надо делать? Требования-то к форуму от языка не зависят.вообще, не видно логической связи между тем, что в постановке указан конкретный язык, и тезисом, что требования надо переводить на язык D.
в твоей постановке указан конкретный язык, иначе бери любой форум и решение готово.
ps
например, если есть постановка задачи:
хочу копию диплома на языке суахили.
То саму постановку задачи на язык суахили, конечно, же переводить не надо.
ну вот твоё описание задачи уже длиннее, чем код, в этом и проблема собственно
ну вот твоё описание задачи уже длиннее, чем код, в этом и проблема собственноСобственно, это я и хотел показать. В процессе написания кода ты не закладываешь в программу семантического смысла ее конструкций (генерируемая последовательность, кадр в три элемента). Соответственно, прежде чем автоматически модифицировать программу, ты вынужден обо всех этих деталях сообщать автомату.
Кстати, в моем примере у тебя был доступ к тексту функции. А как делать, если доступа нет, и ты даже не знаешь, рекурсивная она или итеративная, или вообще считает через золотое сечение?
до этого несколько раз заходила речь о знании. Одно из основных свойств знания, что оно умеет отвечать на вопросы: в чем схожесть, и в чем отличие между X и Z?Тебе может быть интересна вот эта работа:
http://cseweb.ucsd.edu/~lerner/papers/popl10.pdf
Generating Compiler Optimizations from Proofs
We present an automated technique for generating compiler optimizations from examples of concrete programs before and after improvements have been made to them. The key technical insight of our technique is that a proof of equivalence between the original and transformed concrete programs informs us which aspects of the programs are important and which can be discarded. Our technique therefore uses these proofs, which can be produced by translation validation or a proof-carrying compiler, as a guide to generalize the original and transformed programs into broadly applicable optimization rules.
We present a category-theoretic formalization of our proof generalization technique. This abstraction makes our technique applicable to logics besides our own. In particular, we demonstrate how our technique can also be used to learn query optimizations for relational databases or to aid programmers in debugging type errors.
Finally, we show experimentally that our technique enables programmers to train a compiler with application-specific optimizations by providing concrete examples of original programs and the desired transformed programs. We also show how it enables a compiler to learn efficient-to-run optimizations from expensive-to-run super-optimizers.
Но непонятно, что мешает заформализовать понятия, которые используются при написании программ. В целом, их не так много: числа, множества, последовательности, память/состояние, поток управления, пространства, ресурсы и т.д.Академики этим занимаются с тех пор, когда компьютеров-то еще не было, но пока выходило, что
1) некоторые очевидные для нас вещи оказываются крайне сложными для математики, например, равенство функций f(x) = 2 * x и g(x) = x * 2, да и вообще сама тема равенства и эквивалентности.
2) формальные описания и доказательства довольно простых казалось бы понятий оказываются очень громоздкими и сложными.
Ключевые слова: calculus of constructions, intensional type theory, function extensionality, homotopy type theory.
По-русски и на пальцах:
http://thedeemon.livejournal.com/65083.html
http://akuklev.livejournal.com/1143519.html
http://sassa-nf.livejournal.com/19023.html
Ведь большая часть такой спецификации напрямую вытекает из требования "Сделать заебись!", а оставшая часть есть следствие текущих ограничений окружающего мира.тк потом еще надо будет людям объяснять, что именно такой вариант является "заебись" при заданных ограничениях.
1) некоторые очевидные для нас вещи оказываются крайне сложными для математики, например, равенство функций f(x) = 2 * x и g(x) = x * 2, да и вообще сама тема равенства и эквивалентности.Почему первая фраза мне понятна, а последняя какой-то птичий язык? Может в первой и в последней речь о разном?
2) формальные описания и доказательства довольно простых казалось бы понятий оказываются очень громоздкими и сложными.
Ключевые слова: calculus of constructions, intensional type theory, function extensionality, homotopy type theory.
Последняя - это какая? Список незнакомых терминов?
ну вот твоё описание задачи уже длиннее, чем код, в этом и проблема собственнода, наверное. Но приведенное мной описание можно достаточно широко повторно использовать, в отличии, от кода.
2) формальные описания и доказательства довольно простых казалось бы понятий оказываются очень громоздкими и сложными.на практике при решении задач мы же этим всё равно не занимаемся сложными доказательствами. А используем простые быстрые подходы (например, ту же нормализацию).
равенство функций f(x) = 2 * x и g(x) = x * 2через использовании нормализации равенство легко проверяется.
О какой именно нормализации идет речь?
Видимо, x÷>x₁, 2←, x₁→.
Тогда f÷> x₁ -> 2 * x₁, g÷> x₁ -> 2 * x₁, и мы видим, что эти строки равны при посимвольном сравнении.
Остается придумать алгоритм нормализации, чтобы был готов ко всему, знал все правила сокращения и эквивалентности.
Хотя если только композицию полиномов и тригонометрических полиномов, тоже неплохо.
Тогда f÷> x₁ -> 2 * x₁, g÷> x₁ -> 2 * x₁, и мы видим, что эти строки равны при посимвольном сравнении.
Остается придумать алгоритм нормализации, чтобы был готов ко всему, знал все правила сокращения и эквивалентности.
Хотя если только композицию полиномов и тригонометрических полиномов, тоже неплохо.
- уже ответил.
Распишу только общую идею.
Если некий "узел" допускает несколько вариантов записи, то из них выбирается одна каноническая, к которой всё и сводится.
Например, свободная переменная может быть любой, но в канонической записи выбирается x1..xn
Умножение и сложение может записываться разными способами, но в канонической записи левое подвыражение должно быть "меньше", чем правое. И соответственно, вводятся тем или иным способом сравнение подвыражений (например, константа меньше, чем переменная; переменная меньше с меньшим номерм; переменная меньше, чем функция и т.д.)
Константа может записываться как функция от констант, в канонической записи - константы вычисляется.
и т.д.
ps
в целом, если вспомнить среднюю школу, то там как раз все эти правила в том или ином виде и давались. И многочисленные упражнения на упрощения выражений - и были подвидом нормализации.
Распишу только общую идею.
Если некий "узел" допускает несколько вариантов записи, то из них выбирается одна каноническая, к которой всё и сводится.
Например, свободная переменная может быть любой, но в канонической записи выбирается x1..xn
Умножение и сложение может записываться разными способами, но в канонической записи левое подвыражение должно быть "меньше", чем правое. И соответственно, вводятся тем или иным способом сравнение подвыражений (например, константа меньше, чем переменная; переменная меньше с меньшим номерм; переменная меньше, чем функция и т.д.)
Константа может записываться как функция от констант, в канонической записи - константы вычисляется.
и т.д.
ps
в целом, если вспомнить среднюю школу, то там как раз все эти правила в том или ином виде и давались. И многочисленные упражнения на упрощения выражений - и были подвидом нормализации.
Но приведенное мной описание можно достаточно широко повторно использовать, в отличии, от кода.каким образом? для другой задачи и описание понадобится другое (как и код)
каким образом? для другой задачи и описание понадобится другое (как и код)новых знаний о последовательности фибоначчи за последние 700 лет появилось ничтожно мало
Такая нормализация с захардкоженными правилами для арифметики поможет решить простые случаи (я такую применял в своем компиляторе для реализации common subexpression elimination но программирование не сводится к одной лишь арифметике, и в общем случае она бесполезна. Какая нормализация поможет доказать эквивалентность quicksort'a и mergesort'a? Или вот хотя бы две простых функции типа [a] -> [a] :
f xs = xs
g = reverse . reverse
f и g равны или нет? Если да, то как компьютер должен это понять?
f xs = xs
g = reverse . reverse
f и g равны или нет? Если да, то как компьютер должен это понять?
Умножение и сложение может записываться разными способами, но в канонической записи левое подвыражение должно быть "меньше", чем правое. И соответственно, вводятся тем или иным способом сравнение подвыражений (например, константа меньше, чем переменная; переменная меньше с меньшим номерм; переменная меньше, чем функция и т.д.)Опять ты зачем-то вытаскиваешь формальные языки, хотя проблемы хочешь формулировать на естественном. Не получится у тебя ничего с формальными языками, если бы получалось японцы бы еще в 80-х все научились бы делать.
Какая нормализация поможет доказать эквивалентность quicksort'a и mergesort'a? Или вот хотя бы две простых функции типа [a] -> [a] :Как это понимает программист средней руки? И какой программист, вообще, доказывает что две сортировки делают одно и тоже?
f xs = xs
g = reverse . reverse
Всё это делается только через советы старших товарищей, зубрежку и нормализацию.
я к тому, что то о чем ты говоришь - имеет очень далекое отношение к реальному написанию программ.
Максимум это имеет отношение к тотальной оптимизации, что в прикладных программах встречается не часто.
ps
нормализация операций над коллекциями тоже есть.
например, reverse.where(x => x != null).reverse нормализуется как where(x => x != null).reverse.reverse и соответственно, просто where(x => x != null)
в общем случае, отдельно рассматриваются операции неменяющие порядка, меняющие порядок и работающие с иерархической структурой
Опять ты зачем-то вытаскиваешь формальные языки, хотя проблемы хочешь формулировать на естественном. Не получится у тебя ничего с формальными языками, если бы получалось японцы бы еще в 80-х все научились бы делать.имхо, будущее за смесью неформальных языков с формальными. На неформальном языке делается постановка и выписываются общие закономерности, а на формальном делаются окончательные выводы.
По крайней мере, именно так устроено мышление человека.
ps
Естественный язык совсем не хочу, потому что в нем много терминов привязанных к особенностям человека или окружающего мира, которые очень далеки от восприятия компьютером.
если бы получалось японцы бы еще в 80-х все научились бы делать.японцы едва ли что-то могут придумать в этом направлении. У них нет, и не было - сильных школ по софтостроению и экспертным системам. Они хороши в электронике.
Какая нормализация поможет доказать эквивалентность quicksort'a и mergesort'a?У любой функции есть цель: набор добавочных ограничений, которых не было у входа.
У элементарных функций спецификация цели совпадает с телом: sin(x) => sin(x a + b => a + b, но вот для сложных функций (например, сортировки): спецификация цели становится проще самого тела.
У любого sort-а одна и та же спецификация результата: bla-bla-sort(x-s) => x-s, where xi <= xj, для i < j. И обоснование эквивалентности двух sort-ов делается, исходя из того, что их спецификации результата совпадает.
Sort-ы же друг от друга отличаются оценкой сложности, ограничениями на вход и т.д.
Средние программисты не занимаются созданием спецификацией результата сложных функций. Они не высчитывают сложность таких функций, не анализируют ограничения на ввод. Они верят на слово Кнуту и берут эти данные из справочника. Либо, вообще, используют мантру - используй sort из стандартной либы, и сильно не ошибешься.
Что приводит к вопросу - если этим не занимаются программисты, но при этом пишут продаваемые программы, то зачем этим заниматься при автоматической генерации программ?
пишут продаваемые программыа что форумы хорошо продаются?
новых знаний о последовательности фибоначчи за последние 700 лет появилось ничтожно малодля той же задачи подойдёт тот же код, для новой задачи нужно новое описание и новый код
вообще примерно то, что ты просишь, давно есть: называется библиотеки компонентов и RAD - с ними проблема в том, что этих компонентов не хватает для практически важных задач, нужно дополнительно что-то программировать; недостаточно просто перевести слова естественного языка на машинный язык, так как возможных компонентов гораздо больше, чем слов
в обычной инженерии так же: например, если для сборки трактора нужна гайка, то нельзя её просто взять из детского конструктора, потому что там пластиковая, нужно где-то взять стальную гайку; стальные гайки делают на другом заводе и по совсем другому техпроцессу
а потом переходим к более сложному компоненту - например колесy, и выясняется, что колесо от легкового автомобиля тоже не подходит, для трактора нужно тракторное колесо
и вот мы спрашиваем: почему нельзя взять бригаду рабочих и сказать им "сделайте трактор", а нужны специальные люди, которые умеют конструировать именно трактора?
У любого sort-а одна и та же спецификация результата: bla-bla-sort(x-s) => x-s, where xi <= xj, для i < j. И обоснование эквивалентности двух sort-ов делается, исходя из того, что их спецификации результата совпадает.Ты предлагаешь:
а) пользоваться только библиотечными сортами;
б) каждой функции обязательно контракт, где обязательно стандартизованно записано, что после этого результат упорядочен относительно второго аргумента;
в) беспорядочно сваливать записи "glibc.std::sort <=> SunCC.libc.std::sort" в одну бочку с победным кличем "BIG DA-ATA-A-A!";
г) все вышеперечисленное;
д) другое (впишите).
?
вообще примерно то, что ты просишь, давно есть: называется библиотеки компонентов и RAD - с ними проблема в том, что этих компонентов не хватает для практически важных задач, нужно дополнительно что-то программировать; недостаточно просто перевести слова естественного языка на машинный язык, так как возможных компонентов гораздо больше, чем словэто лобовой перенос идеи строительства на программирование. но так как программирование на строительство похоже очень отдаленно (как минимум из-за того, что программирование имеет намного больше степеней свободы то всё это заканчивается пшиком.
Программирование больше похоже на работу со знанием, чем на строительство. Соответственно, и использовать необходимо тот же подход, что и используется при работе со знанием.
Соответственно, и использовать необходимо тот же подход, что и используется при работе со знанием.И какой же это подход?
то всё это заканчивается пшиком.совсем нет
на самом деле, твоя первая задача "сделать форум" решается непрофессионалом без использования программирования: надо поставить готовую сборку форума - это чисто готовый код из репозитория
И какой же это подход?во-первых, аспектная декомпозиция, а не структурная.
во-вторых, формализованное выполнение операций композиции и декомпозиции (и в строительстве, и в коде сейчас - поддерживается только формализованная композиция)
в-третьих, формализованное фиксирование - идентичности, эквивалентности, стоимости, обратимости, сохранимости свойств при изменениях
есть еще и в-четвертых, в-десятых, но для начала хотя бы это.
это ты уже придираешься к формулировкам.
Программирование больше похоже на работу со знанием, чем на строительствону хз как ты измерял
инженеры-конструкторы тоже работают со знанием
если ты скажешь бригаде таджиков-разнорабочих "постройте мне трактор", то их остановит именно нехватка знаний: они не будут даже знать, с чего начать, а будут ждать, пока ты каждому не дашь конкретное задание, которое он сможет понять: стоять тут, копать туда, отрезать вот здесь
После прочтения этого твоего текста любому человеку понятно, что ответ на изначальный вопрос в том, что люди даже друг друга не всегда могут понять. Что уж говорить от том, чтобы объяснить хоть что-то машине.
Ты предлагаешь:я предлагаю совсем другое.
Есть сильная постановка задачи: "уметь писать автоматически какие угодно программы". И есть обоснованные контр-доводы, что сильную постановку задачи решить невозможно (или очень и очень сложно).
Каждый из приведенный контр-доводов можно нивелировать, если ослабить постановку задачи (пусть получившаяся программа будет не самая оптимальная; пусть программа не занимается доказательством сложных выводов, а пользуется справочником; и т.д.).
И каждое ослабление раз за разом возвращает к исходным вопросам:
- не получился ли после ослабления пустой класс задач?
- какая основная причина мешает решить этот класс задач?
инженеры-конструкторы тоже работают со знаниемда, и их подход достаточно сильно отличается от того, как ты это описал на примере строительства.
Программа - это объект, поведение которого должно быть предсказуемо. Подчиняться определенным правилам. Если это форум - он должен принять у меня сообщение и дать другим на него посмотреть. И еще кучу всяких вещей.
Чтобы объект вёл себя как положено, мы должны дать ему знание - а как положено. Сложное поведение - сложный набор правил.
Если взять не тупые компьютеры, а умных людей - у них по сути то же самое. Для того, чтоб военные вели себя предсказуемо (то бишь одинаково у них есть толстые книжки уставов.
В программе на языке высокого уровня уже можно практически сказать: пришел человек - требуй пароль. Да, пусть человек/пароль - это объекты какой-нить библиотеки, но на уровне повыше мы уже разговариваем с компом почти по-человечески. Проблема в том, что мы хотим большой предсказуемости, поэтому приходится задавать много правил.
Это уже потом можем сказать "объект с таким-то поведением - это форум". Коротко и ясно - когда набор правил уже задан и обозван.
Чтобы объект вёл себя как положено, мы должны дать ему знание - а как положено. Сложное поведение - сложный набор правил.
Если взять не тупые компьютеры, а умных людей - у них по сути то же самое. Для того, чтоб военные вели себя предсказуемо (то бишь одинаково у них есть толстые книжки уставов.
В программе на языке высокого уровня уже можно практически сказать: пришел человек - требуй пароль. Да, пусть человек/пароль - это объекты какой-нить библиотеки, но на уровне повыше мы уже разговариваем с компом почти по-человечески. Проблема в том, что мы хотим большой предсказуемости, поэтому приходится задавать много правил.
Это уже потом можем сказать "объект с таким-то поведением - это форум". Коротко и ясно - когда набор правил уже задан и обозван.
Мужик долгое время страстно молился:
- Господи! Ну выполни только одно желание! Ну пожалуйста!
Через несколько лет Господь наконец не выдержал и явился ему.
- Ну ладно, какое у тебя желание, только коротко - я очень занят!
- Хочу стать КЕЛАВРИКОМ!
- Это кто такой?!
(мужик достает огромный томище)
- Вот, Господи, я здесь все написал!
Полностью согласен, есть только один нюанс.
Правила можно описывать, в первую очередь, через "как" (это то, что сейчас пишется в любом коде) или через "зачем".
Хочется второе, оно, конечно, требует более интеллектуального исполнителя, но зато лучше адаптируется к изменяющимся условиям.
ps
и одно "зачем", конечно, не будет. Будет смесь "зачем" и "как", но проблема в том, что уровень "зачем" сейчас, вообще, никак не специфицируется
Правила можно описывать, в первую очередь, через "как" (это то, что сейчас пишется в любом коде) или через "зачем".
Хочется второе, оно, конечно, требует более интеллектуального исполнителя, но зато лучше адаптируется к изменяющимся условиям.
ps
и одно "зачем", конечно, не будет. Будет смесь "зачем" и "как", но проблема в том, что уровень "зачем" сейчас, вообще, никак не специфицируется
проблема в том, что уровень "зачем" сейчас, вообще, никак не специфицируетсяПравда? И в декларативных языках?
Правда? И в декларативных языках?например? есть только пролог (но он чисто логический но программ на нем ничтожно мало.
ps
sql декларативным называют, но это сильно с натяжкой.
А что хаскель не декларативный? Особенно если убрать всякие монады для массивов.
например? есть только пролог (но он чисто логический но программ на нем ничтожно мало.ну вот и ответь на свой вопрос: почему ты, как программист, практически не используешь декларативные языки?
А что хаскель не декларативный? Особенно если убрать всякие монады для массивов.он скорее функционален, чем декларативен (если делать такое разделение)
ну вот и ответь на свой вопрос: почему ты, как программист, практически не используешь декларативные языки?потому что отсутствуют современные декларативные языки
потому что отсутствуют современные декларативные языкину написал бы свой
всего-то нужно: по спецификации результата построить алгоритм его достижения
ну написал бы свойчто-то такое я и делаю
когда-нибудь наверное гугл сможет сам добавлять в себя фичи на основании запросов, которые делают пользователи - и они уволят всех программистов
что-то такое я и делаю
Рассказывай скорее!
когда-нибудь наверное гугл сможет сам добавлять в себя фичи на основании запросов, которые делают пользователи - и они уволят всех программистовпо моему гугл делает то, что пользователи не придумают
нечего пока рассказывать.
только есть
кусочные декларации,
реализации алгоритмов по достижению цели,
какие-то наметки по автоматической генерации знании
только есть
кусочные декларации,
реализации алгоритмов по достижению цели,
какие-то наметки по автоматической генерации знании
он скорее функционален, чем декларативен (если делать такое разделение)Ничего, что это ортогональные категории? Для тебя, надеюсь, Haskell и Scheme do not alias?
по моему гугл делает то, что пользователи не придумаютну бывшие программисты тоже станут пользователями, так что по-любому придумает не хуже
Ничего, что это ортогональные категории? Для тебя, надеюсь, Haskell и Scheme do not alias?Для меня - они ортогональные. И декларативность является нечетко измеряемой категорией (её может быть больше, или меньше а не бинарной вида "да, декларативный; нет, не декларативный".
ps
И есть закономерность, что функциональность значительно улучшает декларативность.
ну бывшие программисты тоже станут пользователями, так что по-любому придумает не хужетк надо развивать аппарат, который помогает в процессе придумывания. Пока кроме кода ничего для этого нет. Об этом прям в начале базового курса MIT по информатике рассказывается. Т.е. программистов по-любому надо оставлять, сменятся разве что их аппарат и инструментарий.
Об этом прям в начале базового курса MIT по информатике рассказывается.а ответ на первый вопрос треда есть в этом курсе?
Ведь большая часть такой спецификации напрямую вытекает из требования "Сделать заебись!", а оставшая часть есть следствие текущих ограничений окружающего мира.А как будет заебись сделать поведение на форме для обязательного поля?
Вот в известном плагине JQuery (и при регистрации на сайте Outlook.com) поведение такое. Сначала все поля пустые. Встаем курсором на первое поле, потом на второе. Сообщение об ошибке не возникает. Теперь пишем в поле слово "заебись", потом подумали и стерли всё. Перешли на второе поле. Сообщение по прежнему не появляется. Теперь ввели слово в первое поле и перешли на второе, потом перешли на первое, стерли там всё и перешли на второе. Опа, сообщение появилось. По мне так это нихрена не заебись, когда появление сообщения зависит от истории перемещений курсора по полям. А в доках к плагину это подается как фича. Кстати, при регистрации на GMail не такое поведение.
И таких историй куча.
P.S. Некоторые сайты настолько вымораживают своей навязчивой валидацией, что стараешься всё делать сразу правильно, чтобы машину не обидеть.
Кстати, а вот о фрайворках. Берем наиболее сейчас раскрученный AngularJS, смотрим на первой странице проекта раздел JavaScript Projects, наживаем кнопку New http://angularjs.org/new Поля красные. Как это понимать? Типа это демонстрация, не всё доделали?... А какого хуя не доделали?... И это фрайворк, который пиарят на каждом углу.
Для mbber.js сходу не нагуглил демо пример.
Для mbber.js сходу не нагуглил демо пример.
форум это слишком абстрактно..
Возьмем маленькую задачу:
1. В каком виде должна быть спецификация задачи, чтобы ее можно было автоматически решить?
2. Какими моделями должен оперировать решатель, чтобы понять спецификацию и смочь предложить решение?
3. Что мешает сделать первое и второе?
Возьмем маленькую задачу:
Пятиклассник Вася, выполняя домашнее задание по природоведению, в течение N дней каждое утро записывал показания уличного термометра в рабочую тетрадь. В учебнике Вася прочитал, что Уральские горы преграждают путь массам воздуха, поступающим с запада, зато холодный арктический воздух и теплые воздушные массы Прикаспия и южных пустынь сюда могут беспрепятственно проникать. Поэтому для Урала характерны резкие колебания температур: зимой — от суровых морозов до оттепелей и дождей, летом — от жары выше +35 °C до заморозков. Вася захотел найти среди своих записей наблюдений температуры такие резкие изменения.Вопросы те же самые:
Напишите программу, которая определит день наблюдений, в который произошло максимальное изменение температуры по сравнению с предыдущим днем.
В первой строке содержатся одно целое число N (2 ≤ N ≤ 100) – количество наблюдений
температуры. Во второй строке содержатся N целых чисел в диапазоне от -40 до 40 — показания термометра.
Вывести одно целое число — номер дня наблюдений, в который произошло максимальное изменение температуры по сравнению с предыдущим днем. Если есть несколько дней с максимальным изменением, то вывести номер первого из них.
1. В каком виде должна быть спецификация задачи, чтобы ее можно было автоматически решить?
2. Какими моделями должен оперировать решатель, чтобы понять спецификацию и смочь предложить решение?
3. Что мешает сделать первое и второе?
Вопросы те же самые:раз уж ответ был на мой комментарий, то отвечу
1. В каком виде должна быть спецификация задачи, чтобы ее можно было автоматически решить?
2. Какими моделями должен оперировать решатель, чтобы понять спецификацию и смочь предложить решение?
3. Что мешает сделать первое и второе?
Не понятно, почему ты сосредоточился именно на "автоматически написать программу". Итог работы любой программы - некоторый результат. То есть в реальности ты хочешь, чтобы написав какой-то текст компьютер мог преобразовать его в машинный код и исполнять этот код. Формально начальный текст от которого будет отталкиваться компьютер - и есть программа.
То есть ответы на твои вопросы:
1) Спецификация задачи должна быть написана в виде программы на любом компилируемом языке программирования.
2) Решатель должен оперировать моделями заданными в стандарте языка программирования.
3) Ничего не мешает - это уже сделано.
Теперь вернемся с сути твоего вопроса - суть вопроса в том "почему языки программирования не очень удобны для решения твоих задач - всё время приходится кодить очень много". На этот вопрос не получится ответить, поскольку обычно всё не так. Под какую-то задачу пишут библиотеку, фреймворк и прочее, что сильно облегчает работу в будущем и сильно снижает необходимость писать один и тот же код. Но ты это всё и так прекрасно знаешь и используешь в своей работе.
Имхо про форумы такого фреймворка не сделали просто потому, что никому этого не надо - иметь конструктор в котором наиболее приближенно к человеческому языку можно было бы описать результат и получить его.
Не понятно, почему ты сосредоточился именно на "автоматически написать программу".потому что мне, в первую очередь, нужна именно программа, а не результат ее работы.
Это связано по двум причинам:
1. я разработчик, а не пользователь, и результатом моей работы являются программы.
2. сценарий использования "решатель по спецификации выдает программу" более гибкий, чем сценарий "спецификация+решатель вызывается каждый раз, когда нужно получить результат". В частности, первый вариант требует меньше ресурсов (по памяти и процессору) при каждом получении результата, и, соответственно, он более подходит для применения в микроконтроллерах, в браузере или мобильных устройствах.
2) Решатель должен оперировать моделями заданными в стандарте языка программирования.Ни один из более-менее используемых языков программирования не описывает модели. Они описывают что-то другое: классы, методы, функции, процедуры, но не модели.
ps
модели умеют предсказывать, код это делать не умеет.
Ни один из более-менее используемых языков программирования не описывает модели. Они описывают что-то другое: классы, методы, функции, процедуры, но не модели.просто такие штуки не называют языками программирования, поскольку разработка модели не считается программированием
просто такие штуки не называют языками программирования, поскольку разработка модели не считается программированиемкаким словом называется "разработка модели"?
ну например, моделирование
ну например, моделированиеи какие есть формальные языки для моделирования?
и какие есть формальные языки для моделирования?UML
например есть математические пакеты, которым можно задать математическую модель, и они что-то смогут рассчитать про неё - символьно или же приближённо
или есть пакеты, которым можно задать трёхмерную модель детали, а они рассчитают что-то про её поведение
или есть пакеты, которым можно задать трёхмерную модель детали, а они рассчитают что-то про её поведение
Под какую-то задачу пишут библиотеку, фреймворк и прочее, что сильно облегчает работу в будущем и сильно снижает необходимость писать один и тот же код.это только в теории. на практике сейчас получается обратное.
например, большие проекты в своей работе используют: сервера, десктопы, телефоны и микроконтроллеры. И значительное подмножество кода должно уметь одновременно крутится в sql server-е, на сервере приложений, на веб-сервере, в браузере, в rich-клиенте, в телефонном приложении и в микроконтроллере.
Что требует один и тот же код, в идеале, уметь записывать на sql-е, c#/java-е, javascript-е, C, Objective-C и т.д.
И тенденция идет к тому, что растет кол-во вариантов готовых вычислителей (которые удобнее или необходимее использовать и растет кол-во способов задания кода для этих вычислителей.
UMLон для визуализации моделей, а не для описания смысла моделей.
в обоих случаях, получается зафиксировано "поле" моделей - в одном случае, это математическое, в другом - пространственное трехмерное.
какие есть языки, которые позволяют описать произвольную модель? или хотя бы описать модель в "понятийном" поле?
какие есть языки, которые позволяют описать произвольную модель? или хотя бы описать модель в "понятийном" поле?
какие есть языки, которые позволяют описать произвольную модель?IDEF0 пойдет?
какие есть языки, которые позволяют описать произвольную модель? или хотя бы описать модель в "понятийном" поле?Русский, например.
Что требует один и тот же код, в идеале, уметь записывать на sql-е, c#/java-е, javascript-е, C, Objective-C и т.д.трансляция между разными языками - это вроде не то, что ты изначально спрашивал
и она вполне может работать
И тенденция идет к тому, что растет кол-во вариантов готовых вычислителейда вроде нет
раньше было больше распространённых процессорных архитектур, сейчас кроме x86 и arm никого особо
компании стараются унифицировать десктопные, серверные и мобильные платформы: общий набор библиотек, одна ОС
встраиваемые системы со всяких недопроцессоров переходят на обычные платформы с обычной ОС (чаще линукс)
ну и всё такое
в обоих случаях, получается зафиксировано "поле" моделей - в одном случае, это математическое, в другом - пространственное трехмерное.ты хочешь ИИ, превышающий по возможностям человеческий
какие есть языки, которые позволяют описать произвольную модель? или хотя бы описать модель в "понятийном" поле?
> раньше было больше распространённых процессорных архитектур,
> сейчас кроме x86 и arm никого особо
Кроме MIPS есть ещё и появляющиеся "GPU".
---
...Я работаю антинаучным аферистом...
> сейчас кроме x86 и arm никого особо
Кроме MIPS есть ещё и появляющиеся "GPU".
---
...Я работаю антинаучным аферистом...
MIPS отмирает насколько я знаю, а GPU да, появляются, но их, опять же насколько я знаю, всего два вида общих для мобильных и для стационарных устройств - причём вопрос не ставится так, что один и тот же код должен исполняться на CPU и на GPU, а скорее библиотека может уметь ускорять выполнение расчётов, используя GPU, если он доступен
в той постановке задачи, о которой говорит DG, можно игнорировать GPU
в той постановке задачи, о которой говорит DG, можно игнорировать GPU
> MIPS отмирает насколько я знаю,
У меня другие данные, но я всё ещё хочу увидеть, что из этого выйдет.
Вот насчёт SPARC у меня ощущение, что он заглох.
---
"Пускай критики решают, что мы хотели сказать.
Им за это деньги платят."
У меня другие данные, но я всё ещё хочу увидеть, что из этого выйдет.
Вот насчёт SPARC у меня ощущение, что он заглох.
---
"Пускай критики решают, что мы хотели сказать.
Им за это деньги платят."
ты хочешь ИИ, превышающий по возможностям человеческийесть доводы, которые это утверждение обосновывают?
раньше было больше распространённых процессорных архитектур, сейчас кроме x86 и arm никого особоя о появлении прослойки программных вычислителей со своими наборами команд и библиотек: sql server, browser, java, .net, flash, облако, android, iphone и т.д.
и о том, что во многих задачах эффективнее и дешевле использовать (или вообще единственная возможность) такие программные вычислители, чем пытаться получить прямой доступ к процессору и на нем что-то вычислять, пытаясь повторить работу готового обкатанного сервиса.
ps
и, соответственно, существующая тенденция ведет к увеличению таких программных вычислителей: как, минимум, из-за того, что опасно давать прямой доступ к процессору, а единый стандарт по "безопасному" набору команд так и не появился, и пока не видно предпосылок, что появится в ближайщее время.
IDEF0 пойдет?опять же эта штука умеет описывать взаимодействие частей, но не умеет описывать сами понятия (сходства, различия, композиция, декомпозиция и т.д.)
есть доводы, которые это утверждение обосновывают?люди тоже за исключением редких инсайтов не используют одновременно модели из разных предметных областей, а каждой области надо учиться
например, чтоб решать дифуры, надо пройти
1) базовый курс алгебры
2) базовый курс анализа
3) курс дифуров
4) курс численных методов (если нужны численные решения тоже)
и 5) несколько лет опыта, иначе хоть постановку задачи и поймёшь, но не решишь
компьютеру надо для этого поставить математический пакет
но этот курс не даст тебе возможность рассчитывать турбины, пока ты не выучишься на проектировщика турбин - а ты хочешь от компьютера именно этого
в данном случае, ты говоришь не о том, что ИИ должен быть круче человека, а о том, что человек за свою жизнь до становления в специалиста успевает усвоить значительное кол-во моделей (условно, 200 учебников - 15 лет по 6 предметов, каждые полгода).
ps
и второй вопрос: сколько надо человеко-лет, чтобы перевести один учебник в формализованное описание моделей, годных под автоматическое использование?
люди тоже за исключением редких инсайтов не используют одновременно модели из разных предметных областей, а каждой области надо учитьсяэто подводит к более интересному и конкретному вопросу: какое кол-во моделей необходимо знать и уметь ими оперировать, чтобы смочь написать простую программу (например, последнюю задачку про Петю)?
ps
и второй вопрос: сколько надо человеко-лет, чтобы перевести один учебник в формализованное описание моделей, годных под автоматическое использование?
это подводит к более интересному и конкретному вопросу: какое кол-во моделей необходимо знать и уметь ими оперировать, чтобы смочь написать простую программу (например, последнюю задачку про Петю)?нужно знать один тип моделей, но надо заранее озаботиться и изучить его
и второй вопрос: сколько надо человеко-лет, чтобы перевести один учебник в формализованное описание моделей, годных под автоматическое использование?ну тебе уже давали ссылки на автоматическое доказательство теорем, там люди этим и занимаются
в данном случае, ты говоришь не о том, что ИИ должен быть круче человекаоб этом
у человека инсайты бывают редко и нерегулярно
а ты хочешь запрограммировать это и поставить на поток - то есть сделать круче чем умеют люди
так вот, препятствие тут в том, что мы недостаточно знаем о том, как это работает, и не можем запрограммировать
ну тебе уже давали ссылки на автоматическое доказательство теорем, там люди этим и занимаютсяне-е.
доказательство теорем - это не построение моделей. Доказательство теорем - штука много сильнее.
Человек, когда строит модели, редко заморачивается их формальным доказательством. В лучшем случае проверяет их через какой-то аналог Монте-Карло (мысленно или опытным путем).
Сейчас же мы говорим не о построении моделей, а об их использовании - что требует еще меньшие интеллектуальные способности.
доказательство теорем - это не построение моделей. Доказательство теорем - штука много сильнее.есть ещё проверка готового доказательства - несложное дело, после того как доказательство записано формально
>> доказательство теорем - это не построение моделей.
>> Доказательство теорем - штука много сильнее.
> есть ещё проверка готового доказательства - несложное дело,
> после того как доказательство записано формально
Если немного вспомнить математику, доказательство теорем, вообще-то,
изоморфно выполнению программ, то есть значительно проще, чем написание программ.
---
"Математика --- это язык."
>> Доказательство теорем - штука много сильнее.
> есть ещё проверка готового доказательства - несложное дело,
> после того как доказательство записано формально
Если немного вспомнить математику, доказательство теорем, вообще-то,
изоморфно выполнению программ, то есть значительно проще, чем написание программ.
---
"Математика --- это язык."
почему ты не решил все "проблемы тысячелетия", если это просто?
> Если немного вспомнить математику, доказательство теорем, вообще-то,
изоморфно выполнению программ, то есть значительно проще, чем написание программ.
Карри-Ховард это вроде не оно, потому что к выполнению не имеет ни малейшего отношения.
Можно поподробнее, что это за изоморфизм такой?
изоморфно выполнению программ, то есть значительно проще, чем написание программ.
Карри-Ховард это вроде не оно, потому что к выполнению не имеет ни малейшего отношения.
Можно поподробнее, что это за изоморфизм такой?
есть ещё проверка готового доказательства - несложное дело, после того как доказательство записано формальнопри записи доказательства есть два очень сложных момента:
обоснование правомерности каждого вывода,
обоснование полноты (что все варианты рассмотрены).
Тот же мгу-шный форум показывает, что люди в своей деятельности (и обосновании своих выводов) ни первым, ни вторым особо не заморачиваются.
доказательство теорем, вообще-то, изоморфно выполнению программ,при выполнении программ не происходит проверка правомерности каждого действии, а при проверки доказательства проверяется правомерность каждого действия, что и составляет основную сложность.
при выполнении программ не происходит проверка правомерности каждого действии, а при проверки доказательства проверяется правомерность каждого действия, что и составляет основную сложность.Лучше так. Доказательство теорем изоморфно компиляции строго типизированных программ.
При этом утверждения в доказательстве - есть строго типизированные функции (без читов типа "функция не определена на таком входе") компилируемой программы.
Пример:
Пусть нам надо доказать что из A следует C. При этом уже есть доказанные утверждения что из A следует B и из B следует С. Применяем два раза modus ponens и получаем доказательство исходного утверждения.
Теперь то же самое в терминах типов. Надо написать функцию из A в C. У нас есть функции из A в B и из B в C. Берём их композицию - задача решена.
Довольно сумбурно получилось, но это всё что я запомнил из двухнедельного упарывания Coq два года назад.
Тот же мгу-шный форум показывает, что люди в своей деятельности (и обосновании своих выводов) ни первым, ни вторым особо не заморачиваются.к чему ты написал эту фразу? типа тебе достаточно не совсем корректной программы? ну тогда лови
{ return 42; }даёт ответ на любую задачу, но не всегда правильно
к чему ты написал эту фразу? типа тебе достаточно не совсем корректной программы?да, мне достаточно не совсем корректной программы. если она проходит проверку через Монте-Карло (в ряде случаев, даже достаточно 51% правильности) - в большинстве случаев ее уже можно использовать.
даёт ответ на любую задачу, но не всегда правильносовсем не проходит проверку монте-карлой
совсем не проходит проверку монте-карлойэто зависит от распределения ГСЧ
т.е. ты оспариваешь тезис, что люди сплошь и рядом пользуются некорректными программами?
да у тебя в каждом посте тезис свой
да, мне достаточно не совсем корректной программы. если она проходит проверку через Монте-Карло (в ряде случаев, даже достаточно 51% правильности) - в большинстве случаев ее уже можно использовать.Все тебе не так. И корректность у тебя определятся убого. В итоге ты скажешь, что тебе нужно не монте карло, а чтобы все было правильно в каких-то только тебе нужных случаях. И мы возвращаемся назад, когда я тебе писал, что твои хотелки может удовлетворить только искусственный интеллект схожий с человеческим (на самом деле он будет превосходить человеческий на порядки). Вот и займись его созданием, чем нам тут мозги компостировать. Простых решений нет.
В итоге ты скажешь, что тебе нужно не монте карло, а чтобы все было правильно в каких-то только тебе нужных случаях.после того, как у меня заработает вариант с Монте-Карло, конечно, же захочется больше, но пока достаточно хотя бы его.
Оставить комментарий
Dasar
Что мешает(не хватает для того, чтобы) писать программы автоматически?Например, возьмем нашу "любимую" задачу - написать форум. Их написано уже тысячи, у них банальная структура..
Что не хватает, чтобы написать еще один автоматически?
Интересует конкретика: фундаментальная причина. Например, для строительства тысяче-этажного дома не хватает прочности материалов. Что же не хватает для перевода желания "Хочу еще один форум" в автоматическую генерацию кода под это?
ps
форум взят чисто для примера, потому что эта тема много раз уже обсуждалась. и для него легко перейти на конкретику при необходимости.
pps
свои мысли напишу, "когда приду домой"