Я думаю, Тьюринг хотел сказать нам, что отличить реальный интеллект от умелой имитации в принципе невозможно.
Но, с другой стороны, умелая имитация может оказаться ничуть не хуже реального интеллекта — тогда в чём разница?
Разница в том, что реальный интеллект способен совершать интеллектуальную (или не очень) работу на основании общения, то есть как раз описываемое автором смысловое ядро преобразовывать в другое представление. О чём тест Тьюринга, проверяющий исключительно коммуникативную функцию, ничего не говорит.
Когда мы говорим компьютеру: “Сири, какая сейчас погода?” и он сообщает нам погоду, то это реальный искусственный интеллект, хотя, возможно, очень слабый. А когда, в ответ на вопрос, компьютер посылает нас в известном направлении, потому что у него депрессия, то это хороший результат по Тьюрингу, но совершенно не требующий анализа смысла речи и вообще интеллектуальных действий в традиционном понимании.
Сёрл говорит о том, что, если разум алгоритмичен, то можно вести разумный диалог, не имея субъектности. Это само по себе никак не относится к предмету настоящего обсуждения, и, на мой взгляд, и так самоочевидно.
Парадокс китайской комнаты несколько глубже, он больше относится к проблеме философского зомби, чем к тесту Тьюринга. Я же здесь говорю только о том, что, рассматривая человека, как преобразователь входной цепочки символов в выходную, можно реализовать такое преобразование самыми разными путями, необязательно через анализ их смысла. Поэтому успешное прохождение теста Тьюринга само по себе никак не может убедить современного программиста в наличии разума с той стороны.
Собственно, и средний человек больше имитирует обработку смысла, чем в действительности производит её. В предельном случае, Вы мне говорите: “Добрый вечер!”, я Вам отвечаю: “Добрый вечер!”. Смысла ноль, чистое подражание обучающим примерам диалогов (на чём, кстати, построено преподавание иностранного языка в ряде методик).
Утверждение же о комбинаторном взрыве – это вообще не аргумент в принципиальном вопросе. На практике, разумеется, нет необходимости учитывать все комбинации бессмысленных символов, и можно сильно соптимизировать словарь, чем, собственно, и занимаются современные боты.
Тьюринг, при всём к нему уважении, всё-таки не мог предусмотреть развития науки и практики программирования и философии сознания за последующие 60 лет. Поэтому для своего времени его тест был выдающимся результатом, но на сегодня он, скорее, уводит в сторону.
Это всё разумно, только тест Тьюринга на самом деле не имеет отношения к мышлению, и лучшие программы на сегодня его проходят. Тест Тьюринга показывает только возможность имитировать человеческую письменную речь.
Формально, тест Тьюринга опровергается мысленным экспериментом по построению таблицы человеческих ответов на все возможные комбинации входных символов в пределах заданной максимальной длины диалога. Программа, находящая входной текст в левом столбике и печатающая в ответ на него текст из правого столбика, пройдёт ТТ.
Причём тут вообще собственник? Юрлицо неспособно к хозяйственной деятельности; это вполне достаточно знать о клиенте.
Что дальше сделает собственник? Скорее всего, ликвидирует бизнес сам или сбросит его на распродажу остатков. В любом случае, хостер своих денег вряд ли когда-нибудь дождётся, и речь идёт о том, чтобы возможно раньше отсечь убытки.
Отдельно замечу, что клиент, генерирующий 100К платежей в месяц (из которых хорошо если 20% являются прибылью) никак не может являться ключевым для дата-центра.
Это всего лишь, по сути, предоставление клиенту скидки, равной стоимости кредита на задержанную сумму оплаты, и в правильных договорах прописывается право эти проценты истребовать. Целесообразна такая скидка или нет, и нужно ли пользоваться таким правом – вопрос маркетинга.
По справедливости, надо было бы поставить автоматический выключатель, блокирующий трафик при появлении отрицательной суммы на счёте. Но провайдер в интересах ведения своего бизнеса вправе выполнять кредитование клиента услугами на тех или иных условиях. Никаких юридических или нравственных обязательств, кроме прописанных в договоре, он при этом не несёт, и я вообще удивлён, что тут можно обсуждать.
Программа на PL/I выдаёт очень поверхностное знание этого языка.
1. В конструкции DATA могут содержаться только имена переменных, поэтому такая программа вызовет ошибку при компиляции. Должно быть PUT SKIP LIST ('HELLO WORLD!');
2. Переменная FLAG, будучи описанной по умолчанию и обладая именем, начинающимся с буквы F, имеет вещественный тип, поэтому не очень осмысленно, хотя и возможно, сравнивать её с целым нулём и использовать в качестве флажка. Также не очень понятен бесконечный цикл, организованный таким образом.
3. Инструкции должны записываться не менее чем со второй позиции, коль скоро речь про IBM.
На бумажке – условные переходы без меток, адреса переменных в числовой форме, и ниже – список адресов команд, составленный вручную. То есть автор сначала писал машинные команды в символической записи, а потом переводил их в машинный код вручную. Короче, представлен исходный материал для ручного ассемблирования.
В случае использования ассемблера там стояли бы символические адреса.
Ответственные приложения надёжно работают вовсе не потому, что в них нет ошибок, и тем более не потому, что мифический язык программирования не допускает совершения ошибок.
Падать — значительно лучше, чем работать некорректно.
Зависит от назначения программы. Если у вас прошивка маршрутизатора будет падать от некорректного, по её мнению, символа в контактном e-mail администратора в настройках, я думаю, вам вряд ли это понравится.
Я всё пытаюсь понять вашу точку зрения по поводу применимости статической типизации — конкретно что не так с типом EmailAddress.
Конкретно с типом EmailAddress не так то, что это по своему содержимому и есть String. И ничего более ограниченного, чем String, в нём нет.
А когда какая-нибудь программа начинает выдавать ошибку, потому что не находит в адресе собаки или точки, то это индусское программирование в чистом виде.
Опишите этот «типичный случай» для начала. Пока вы просто сделали односложное малопонятное утверждение, которое я читаю как «понятие URL само по себе не нужно, нужно понятие Фигня-Которую-Юзер-Написал-В-Адресной-Строке».
Понятие URL нужно. Не нужны (в большинстве случаев) переменные типа URL. Так как нет ни одного внешнего источника данных, за который мы могли бы поручиться, что оттуда всегда поступают именно URL.
Если Вы мне пытаетесь объяснить, что вообще типизация имеет применение в программировании, то я, вроде, с этим и не спорил. Я писал только о том, что переменные ограниченных и перечислимых типов (не сами эти типы, а имеющие их переменные!) находят гораздо меньше применений на практике, чем этого хотелось бы на первый взгляд.
Вы путаете URL и адресную строку броузера.
Я ничего не путаю, я пишу о типичном случае применения.
Заблуждение здесь состоит в том, что компилятор может отличить корректное прикладное значение от некорректного. В частности, ничто в самой строке «привет» не говорит о том, что её нельзя использовать в качестве e-mail. По формальным признакам, это имя пользователя в почтовом домене по умолчанию.
Единственный корректный способ отличить правильный e-mail от неправильного — это соединиться со своим smtp сервером и предложить ему соответствующее RCPT TO. Понятно, что это возможно только динамически. А все статические проверки e-mail адреса — это зло. Большинство авторов почтовых программ, к счастью, это хорошо понимают.
По поводу url — слово «привет», разумеется, не является url-ем, но, тем не менее, может иногда использоваться в качестве такового, в чём легко убедиться, набрав его в браузере.
Специально для Вас, набрал в почтовом клиенте Apple Mail сообщение на адрес vadim@mail, успешно отправил его при помощи Postfix и успешно получил при помощи Dovecot. mail – это имя моего почтового сервера в локальной сети, домен подразумевается по умолчанию.
Затем сделал то же с адресом просто vadim (имя сервера по умолчанию).
Date: Sun, 4 Sep 2016 14:41:56 +0300
To: vadim
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Не мешает, но в статье-то Вы агитируете за поддиапазоны в стиле Ada/Delphi.
На самом деле, даже цикл for… to MAXINT в большинстве реализаций никогда не завершится, даже без всяких поддиапазонов (в Си это тривиально следует из записи условия цикла, а во многих других языках является неприятным открытием для многих программистов). Это просто иллюстрирует фундаментальное противоречие, заключающееся в том, что алгоритмически целесообразный диапазон значений переменной может отличаться от домена прикладных значений, для обработки которых предназначена эта переменная.
Разница в том, что реальный интеллект способен совершать интеллектуальную (или не очень) работу на основании общения, то есть как раз описываемое автором смысловое ядро преобразовывать в другое представление. О чём тест Тьюринга, проверяющий исключительно коммуникативную функцию, ничего не говорит.
Когда мы говорим компьютеру: “Сири, какая сейчас погода?” и он сообщает нам погоду, то это реальный искусственный интеллект, хотя, возможно, очень слабый. А когда, в ответ на вопрос, компьютер посылает нас в известном направлении, потому что у него депрессия, то это хороший результат по Тьюрингу, но совершенно не требующий анализа смысла речи и вообще интеллектуальных действий в традиционном понимании.
Собственно, и средний человек больше имитирует обработку смысла, чем в действительности производит её. В предельном случае, Вы мне говорите: “Добрый вечер!”, я Вам отвечаю: “Добрый вечер!”. Смысла ноль, чистое подражание обучающим примерам диалогов (на чём, кстати, построено преподавание иностранного языка в ряде методик).
Утверждение же о комбинаторном взрыве – это вообще не аргумент в принципиальном вопросе. На практике, разумеется, нет необходимости учитывать все комбинации бессмысленных символов, и можно сильно соптимизировать словарь, чем, собственно, и занимаются современные боты.
Тьюринг, при всём к нему уважении, всё-таки не мог предусмотреть развития науки и практики программирования и философии сознания за последующие 60 лет. Поэтому для своего времени его тест был выдающимся результатом, но на сегодня он, скорее, уводит в сторону.
Насколько мне известно, программа Веселова и Демченко официально прошла тест Тьюринга.
Формально, тест Тьюринга опровергается мысленным экспериментом по построению таблицы человеческих ответов на все возможные комбинации входных символов в пределах заданной максимальной длины диалога. Программа, находящая входной текст в левом столбике и печатающая в ответ на него текст из правого столбика, пройдёт ТТ.
Что дальше сделает собственник? Скорее всего, ликвидирует бизнес сам или сбросит его на распродажу остатков. В любом случае, хостер своих денег вряд ли когда-нибудь дождётся, и речь идёт о том, чтобы возможно раньше отсечь убытки.
Отдельно замечу, что клиент, генерирующий 100К платежей в месяц (из которых хорошо если 20% являются прибылью) никак не может являться ключевым для дата-центра.
1. В конструкции DATA могут содержаться только имена переменных, поэтому такая программа вызовет ошибку при компиляции. Должно быть PUT SKIP LIST ('HELLO WORLD!');
2. Переменная FLAG, будучи описанной по умолчанию и обладая именем, начинающимся с буквы F, имеет вещественный тип, поэтому не очень осмысленно, хотя и возможно, сравнивать её с целым нулём и использовать в качестве флажка. Также не очень понятен бесконечный цикл, организованный таким образом.
3. Инструкции должны записываться не менее чем со второй позиции, коль скоро речь про IBM.
;)
В случае использования ассемблера там стояли бы символические адреса.
1. Некоторые неисправности связаны со старением железа, а не с выработкой его ресурса, поэтому ЗИП может точно так же выйти из строя.
2. Специфика бюджетирования проекта может позволить заказать железо или поддержку на начальном этапе, но не позволить докупать в последующие годы.
В этом плане иногда выгоднее переплатить на начальном этапе, но снять с себя некоторые будущие риски.
Зависит от назначения программы. Если у вас прошивка маршрутизатора будет падать от некорректного, по её мнению, символа в контактном e-mail администратора в настройках, я думаю, вам вряд ли это понравится.
Конкретно с типом EmailAddress не так то, что это по своему содержимому и есть String. И ничего более ограниченного, чем String, в нём нет.
А когда какая-нибудь программа начинает выдавать ошибку, потому что не находит в адресе собаки или точки, то это индусское программирование в чистом виде.
Понятие URL нужно. Не нужны (в большинстве случаев) переменные типа URL. Так как нет ни одного внешнего источника данных, за который мы могли бы поручиться, что оттуда всегда поступают именно URL.
Я ничего не путаю, я пишу о типичном случае применения.
Единственный корректный способ отличить правильный e-mail от неправильного — это соединиться со своим smtp сервером и предложить ему соответствующее RCPT TO. Понятно, что это возможно только динамически. А все статические проверки e-mail адреса — это зло. Большинство авторов почтовых программ, к счастью, это хорошо понимают.
По поводу url — слово «привет», разумеется, не является url-ем, но, тем не менее, может иногда использоваться в качестве такового, в чём легко убедиться, набрав его в браузере.
Затем сделал то же с адресом просто vadim (имя сервера по умолчанию).
Date: Sun, 4 Sep 2016 14:41:56 +0300
To: vadim
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
На самом деле, даже цикл for… to MAXINT в большинстве реализаций никогда не завершится, даже без всяких поддиапазонов (в Си это тривиально следует из записи условия цикла, а во многих других языках является неприятным открытием для многих программистов). Это просто иллюстрирует фундаментальное противоречие, заключающееся в том, что алгоритмически целесообразный диапазон значений переменной может отличаться от домена прикладных значений, для обработки которых предназначена эта переменная.