В принципе, непрерывность передачи импульсов это неплохая зацепка. Спасибо, про нее я раньше не задумывался.
Хотя и не кажется основополагающим фактором. Чуть исхитрившись можно добавить дублирование сигналов куда-то некоторое время (такие себе RAID 1 нейроны).
А потом взять и разделить физически. Тут так сразу и не сказать, где "оригинал" то будет.
Отличная архитектура, между прочим. Вы же не думаете "адреналином". Думаете вы отдельным специализированным устройством. А адреналин, упрощенно — это реакция на внешний раздражитель, благодаря которой вы отбиваетесь, а не смотрите как вам тигр руку отгрызает с покерфейсом.
Конечно. Только думается мне, что "процесс не останавливается" — это больше интуитивное понимание "себя". Раз я всегда был собой, то любые физические изменения не влияют на "суть" и "я" всегда остаюсь "собой". Но ведь это только потому, что мы ассоциируем себя с физической оболочкой. С другой стороны протез руки совсем не удивляет, пересадка готовы уже посложнее, протез/пересадка мозга — уже интуитивно непонятно.
Для сознания "смотря изнутри" ничего не поменялось же, а для внешних наблюдателей уже, пожалуй, — копия.
Решение тут, видимо, в очень серьезном уточнение терминологии, т.к. пока эти рассуждения больше интуитивные, а интуиция то тут как раз не работает
Вот про телепорт интересно, спасибо. Хотя интереснее, конечно, понаблюдать, как человечество будет решать моральные вопросы, которые при этом обязательно возникнут.
Так не имеет же значения так выглядит или не так. Сами строили или не сами. Клетки и так постоянно меняются, ну вот меняйте постепенно на искусственные. Штука то в том, что нет такого момента, в который сознание "вдруг пропадет". Почему вас больше интересует физический носитель и его похожесть на что-то, а не информация на нем записанная?
Не думаю, что материаловедение хоть как-то помогает сознанию "чувствовать свою сознательность". Сознанию не нужно думать про носитель чтоб осознавать себя. Это со стороны, конечно, интересно посмотреть, как устроено и на чем записано.
"Станет ли компьютер личностью". Там все-таки в обратном порядке эксперимент проходит. Изначально ведь мы берем человека. Подумайте какой процент мозга надо заменить на искусственный, чтоб перестать считать себя сознательным и начать считать моделью и копией? И наступит ли этот момент? Попробуйте провести его медленнее (буквально по одному нейрону) и над собой.
Есть один интересный мысленный эксперимент.
Можно менять по одному нейрону мозга на искусственный аналог. Постепенно меняя нейрон за нейроном можно заменить весь мозг на искусственный, полностью сохранив сознание.
Или в какой-то момент человек станет компьютером и моделью бывшей личности?
Затем, что последовательное поведения важнее обратной совместимости. А на двух стульях одновременно усидеть все равно не получится. Возьмите тот же повсеместный переход на итераторы. Вы считаете, что лучше было бы оставить как в 2.х xrange и range, iteritems и items и т.д.?
Но тогда язык обрастет кучей мусора либо просто устареет.
Один из важнейших плюсов питона это то, что он пытается использовать новые идеи в максимально лаконичной форме, вместо добавления в каждой версии миллиона ключевых слов. Это сохранение чистоты языка.
«Изменения в юникоде» значительно более фудаментальные, чем кажется на первый взгляд. Это как минимум логическое отделений байтовых типов от строчных, что с идейной стороны корректно, а с практической затрагивает очень много существующего кода.
А заставлять авторов приходится вследствии важности этих изменений для языка и для того чтоб хорошие библиотеки стати еще лучше с новыми возможностями.
А десятки скритов с большой вероятностью неплохо сконвертируются с помощью 2to3 либо будут продолжат работать на 2й версии, использование которой никто не отменял. Больше всего проблем у авторов библиотек, которые хотят чтоб один код работал и во второй и в третьей версии. Но это ж не самая распространенная потребность для прикладного программирования.
Как заявляют разработчки, ember стремится уменьшить кол-во «шаблонного кода», т.е. в нем сразу выбраны решения для типичных задач.
Основное преимущество и видимо одновременно и недостаток — это байндинги данных к Handlebars шаблонам. Что позволяет очень удобно автоматически обновлять страницу при изменениях. А с другой стороны это же накладывает некоторые ограничения на генерируемый по умолчанию html и он немного «замусоревается» служебными тегами, которые нужны ember для поддержки этой автоматики.
Ну и есть вопрос насколько гибко и быстро это будет работать в случае большого и/или сложного приложения. Хотя разработчики, вроде бы, обещают, что с этим все хорошо.
Также хорошо выглядит возможнось создавать вложенные view (пример из документации):
Это позволяет управлять довольно маленькими блоками страницы и повторно их использовать в других view.
Не могу сказать, что у меня сильно большой опыт работы с backbone и ember, но поигравшись с ними в небольших проектах, мне ember кажется удобнее и производит хорошее впечатление.
Nexus S, ICS 4.0.3. Начал заметно быстрее разряжаться. Раза в 2 минимум.
Иногда при входящем звонке не реагирует на прикосновения. Приходится блокировать и разблокировать, чтоб ответить на звонок.
«порождаемые программой аудиовизуальные отображения» считаются ее частью, т.е. входят в состав РИД автора компьютерной программы
Т.е. получается, что все фотографы, например, использующие цифровые фотоаппараты не имею прав на свои фотографии, а правами владеют производители фотоаппаратов, а может даже и производители станков с ЧПУ на которых эти фотоаппараты производились?
Я не имел ввиду решение уравнения голосованием (и даже не написал так).
Это был пример «пользы» равенства голосов. Да, слишком утрированный и не очень удачный.
Но есть же масса других вопросов, которые все равно требуют специальных знаний.
Учат же чему-то экономистов в университете много лет, в конце концов.
Да любое министерство возьмите и попробуйте переложить его ф-ции на людей.
Хотя и не кажется основополагающим фактором. Чуть исхитрившись можно добавить дублирование сигналов куда-то некоторое время (такие себе RAID 1 нейроны).
А потом взять и разделить физически. Тут так сразу и не сказать, где "оригинал" то будет.
Для сознания "смотря изнутри" ничего не поменялось же, а для внешних наблюдателей уже, пожалуй, — копия.
Решение тут, видимо, в очень серьезном уточнение терминологии, т.к. пока эти рассуждения больше интуитивные, а интуиция то тут как раз не работает
Можно менять по одному нейрону мозга на искусственный аналог. Постепенно меняя нейрон за нейроном можно заменить весь мозг на искусственный, полностью сохранив сознание.
Или в какой-то момент человек станет компьютером и моделью бывшей личности?
Затем, что последовательное поведения важнее обратной совместимости. А на двух стульях одновременно усидеть все равно не получится. Возьмите тот же повсеместный переход на итераторы. Вы считаете, что лучше было бы оставить как в 2.х xrange и range, iteritems и items и т.д.?
Но тогда язык обрастет кучей мусора либо просто устареет.
Один из важнейших плюсов питона это то, что он пытается использовать новые идеи в максимально лаконичной форме, вместо добавления в каждой версии миллиона ключевых слов. Это сохранение чистоты языка.
«Изменения в юникоде» значительно более фудаментальные, чем кажется на первый взгляд. Это как минимум логическое отделений байтовых типов от строчных, что с идейной стороны корректно, а с практической затрагивает очень много существующего кода.
А заставлять авторов приходится вследствии важности этих изменений для языка и для того чтоб хорошие библиотеки стати еще лучше с новыми возможностями.
А десятки скритов с большой вероятностью неплохо сконвертируются с помощью 2to3 либо будут продолжат работать на 2й версии, использование которой никто не отменял. Больше всего проблем у авторов библиотек, которые хотят чтоб один код работал и во второй и в третьей версии. Но это ж не самая распространенная потребность для прикладного программирования.
Основное преимущество и видимо одновременно и недостаток — это байндинги данных к Handlebars шаблонам. Что позволяет очень удобно автоматически обновлять страницу при изменениях. А с другой стороны это же накладывает некоторые ограничения на генерируемый по умолчанию html и он немного «замусоревается» служебными тегами, которые нужны ember для поддержки этой автоматики.
Ну и есть вопрос насколько гибко и быстро это будет работать в случае большого и/или сложного приложения. Хотя разработчики, вроде бы, обещают, что с этим все хорошо.
Также хорошо выглядит возможнось создавать вложенные view (пример из документации):
Это позволяет управлять довольно маленькими блоками страницы и повторно их использовать в других view.
Не могу сказать, что у меня сильно большой опыт работы с backbone и ember, но поигравшись с ними в небольших проектах, мне ember кажется удобнее и производит хорошее впечатление.
по-моему звучит намного лучше «крайних» и нет проблемы «последних»
Телепорту? Или прийдется ждать пока Вы начнете поддерживать интерфейс телепортации.
Иногда при входящем звонке не реагирует на прикосновения. Приходится блокировать и разблокировать, чтоб ответить на звонок.
Т.е. получается, что все фотографы, например, использующие цифровые фотоаппараты не имею прав на свои фотографии, а правами владеют производители фотоаппаратов, а может даже и производители станков с ЧПУ на которых эти фотоаппараты производились?
Это был пример «пользы» равенства голосов. Да, слишком утрированный и не очень удачный.
Но есть же масса других вопросов, которые все равно требуют специальных знаний.
Учат же чему-то экономистов в университете много лет, в конце концов.
Да любое министерство возьмите и попробуйте переложить его ф-ции на людей.