> man operating_systems
Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21
 
<< Предыдущая тема | Следующая тема >>
Заглядывая в туманное будущее - обсуждение
Переход на страницу  1 2 [3] 4 ... 13 14 15
Модераторы: Roman I Khimov, Wanderer, Dron
Автор Добавил
batu
Среда 27.07.2005 00:07
ID пользователя #5
Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22
Не получается пока у нас диалога. Начнем с простого. Попробуй придумать как после трансляции будет выглядеть на ассемблере вот такая процедура
Sub NN (OD As Object)
OD+=1
End Sub
Размышления тебя натолкнут на некоторые проблемы.
Наверх
Сайт
captain cobalt
Среда 27.07.2005 04:30

ID пользователя #12
Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144
batu написал(а) ...
Не получается пока у нас диалога.
Я, кажется, выдвигаю вполне конструктивные предложения о технической реализации конкретных механизмов на конкретной (делаю это "по мотивам" архитектуры Bluebottle). В ответ - никаких опровержений, пока только лишь "всё настолько элементарно, что нечего обсуждать", "идите читайте Бабаяна", теперь вот ещё "отгадайте загадку".
batu написал(а) ...
Начнем с простого. Попробуй придумать как после трансляции будет выглядеть на ассемблере вот такая процедура
Sub NN (OD As Object)
OD+=1
End Sub
Разумеется, ответ зависит от предположений насчёт языка программирования. Возможны следующие предположения:

1. Язык программирования поддерживает перегрузку операторов - синтаксический сахар над вызовами методов, в данном случае оператор инкрементного сложения.

1.1. Язык программирования требует, что тип Object, являющийся подразумеваемым базовым суперклассом всех других классов, должен реализовывать этот оператор (а также, возможно, все другие арифметические операторы). Это не особо удивительная ситуация, другие объектные языки, имеющие такой универсальный суперкласс, тоже требуют от него некоторой функциональности - одни языки персистентность, другие хэшируемость и т. п. В данной ситуации такой оператор - это вызов оператора сложения этого базового класса (возможно, перекрытого в производном). Очень просто.

1.2. Язык использует динамическую типизацию. Реализация оператора необязательна в классе, но может применяться только к объектам классов, в которых реализована. Для этого действительно может потребоваться скрытая динамическая проверка типа во время исполнения. Динамическая типизация - это не очень хорошо. Частично от того, что привносит накладные расходы эти скрытые проверки, частично от того, что непонятно, что делать при неудачной проверке. В абсолютном большинстве случаев программист может грамотно построить иерархию своих типов, и привносить динамическую типизацию (именно со скрытыми проверками типов) в язык программирования - это дополнительная сложность и возможное снижение устойчивости.

1.3. Язык использует статическую типизацию. Тогда вообще говоря, такая подпрограмма уже некорректна. Однако, можно потребовать, чтобы эта процедура могла применяться только к типам, о которых на этапе компиляции известно что они реализуют оператор, а для других типов выдавать ошибку компиляции. Кроме того, можно научить динамический компоновщик выполнять такие проверки когда эта процедура объявлена в одном модуле, а используется в другом. Это всё довольно сложно и также представляется неоправдвнным.

2. Язык не поддерживает перегрузку операторов. Языки семейства Oberon не поддерживают перегрузку операторов. Перегрузка операторов - это усложнение языка. Перегрузка операторов - это дырявая абстракция. Перегрузка операторов может маскировать сложность, вызывающую проблемы с производительностью. Перегрузка операторов провоцирует людей загадывать вот такие "загадки".
batu написал(а) ...
Размышления тебя натолкнут на некоторые проблемы.
Здесь опять применим "аргумент доктора" - "а вы так не делайте".
Сначала разрабатывается некая архитектура, а потом "неожиданно" возникают трудности с реализацией. Проблема - в архитектуре. Проектировать следует учитывая возможности дальнейшей реализации. Это удивительным образом приводит к гораздо более гибким и качественным архитектурам. Все инженерные дисциплины - это всегда решение проблем в условиях ограниченных возможностей реализации.

Можно привести такой пример. Пузырьковая сортировка исполняется медленно на "обычных" машинах.
Есть два решения:
1. Разработать специальный процессор, который может быстро исполнять именно пузырьковую сортировку.
2. Поискать более эффективный алгоритм для обычных машин.

При отсутствии непреодолимых причин, следует использовать второй путь. Фактически, это вся инженерия программного обеспечения.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.
Наверх
Сайт
batu
Среда 27.07.2005 15:32
ID пользователя #5
Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22
Captain cobalt, я не собирался ввязываться в полемику по архитектуре Bluebottle. Есть некие объективные вещи которые я предложил. И на этом все. Мне кажется определенных успехов я достиг. Из обсуждения примера вы поняли что без проверки типов (а ткаже формирования адресной части команд) во время выполнения не обойтись. Машина это будет делать или программа вопрос второй. Но если вы представили объем генерируемого кода и накладные расходы в программном решении, то... сделайте сами ыводы.И ведь мы говорим о будущем!
Наверх
Сайт
Rygoravich
Среда 27.07.2005 17:02

ID пользователя #10
Зарегистрирован: Воскресенье 04.07.2004 16:29
Местонахождение: Navapolatsk, Belarus
Сообщений: 30
Wanderer написал(а) ...

Вот только не надо путать теплое с мягким. Заметь, что я говорил об общении с машиной, а не с человеком. Твои же примеры почему-то скатываются к тому абсолютно понятному факту, что языки программирования - не самое лучшее средство для программирования людей.

Т.е. ты говоришь об интеграции человека в машинный мир. А я - об интеграции машин в мир людей.
Wanderer написал(а) ...

Я напомню, что я по-прежнему говорю о компьютерах, а не о роботах, наделенных искусственным интеллектом.

Имхо, эволюция компьютерной техники в туманном будущем и должна привести к вырождению компьютера в робота. Хотя это, конечно, дело не десяти лет.
Wanderer написал(а) ...

Rygoravich написал(а) ...

Что и требовалось доказать... "Раньше я думал, что техника нужна, чтобы служить мне. Теперь, когда я познакомился с ней поближе - я готов ей служить".

Еще одно подтверждение мои словам.

Лично я не вижу резона в изготовлении объектов поклонения... Идолы и иконы изжили себя и не стоит, имхо, создавать некую киберрелигию.
Wanderer написал(а) ...

Rygoravich написал(а) ...

Согласен со всеми аргументами, однако делаю из них диаметрально противоположные выводы .

Что и требовалось доказать.

Что люди могут не соглашаться друг с другом .
[ Редактирование среда 27.07.2005 17:05 ]
Наверх
Rygoravich
Четверг 28.07.2005 17:16

ID пользователя #10
Зарегистрирован: Воскресенье 04.07.2004 16:29
Местонахождение: Navapolatsk, Belarus
Сообщений: 30
Dron написал(а) ...
Погоди... давай не будем отождествлять программирования и общение с компьютером...

Ага, вот тут мы подошли к той черте, когда спор становится бессмысленным, если только не определиться с терминами... Программирование - это написание программ. Программа - последовательность действий, которые должен выполнить компьютер. Откуда (я не настаиваю на правильности своих определений, можно обсуждать) - дать несколько заданий виндозному планировщику или написать двустрочный скрипт - значит программировать. А это желательно бы уметь любому пользователю...

Итак: в чем существенные отличия программирования от пользования?
Dron написал(а) ...

но вернемся к первой категории... кто сказал что они не смогут на своем родном языке давать компьютеру задания??? "отправь почту, закажи пицу и напомни чтобы я почистил зубы после того"...

Но это ведь не имеет никакого отношения к программированию. системы распознавания речи будут совершенствоваться.

Согласно вышеприведенной концепции это тоже программа .
Dron написал(а) ...

Писать на естественном языке указания компу - это тоже изврат, и это неизбежно повлечет за собой упрощение командного языка. как там в чатах то общаются?

В чем проблема, почему упрощение языка - плохо?
Dron написал(а) ...

короче клавке не место на компах пользователей... все будет осуществляться через голос... мощности компов будут неизбежно расти и качество распознавания не заставит себя ждать.

То же самое с текстами - их проще надиктовывать нежели набивать.

А теперь - ситуация. В одном помещении сидят 10 человек и каждый надиктовывает текст своему компу... Представляешь ?
Dron написал(а) ...

А программирование... если уж фантазировать, то мне кажется что там вообще языку не место особо... объекты... сущности.. да как хотите называйте... и сидишь перед 3D монитором... организуешь взаимодействие сущностей...

Ну, тут, возможно, ты и прав... Только пока что я себе этот процесс плохо представляю...
Dron написал(а) ...

ЗЫ: добавлю немного... вообще программирование это нелинейный процесс... см выше... это не стих, который прочитал и успокоился... это стих, который придется перечитывать сто раз до тех пор, пока ты не научишься читать его правильно... или постоянно прыгать с места на место... это слово не так... здесь вообще хотел не то сказать... какой смысл в естественном языке? я против!

Общение - тоже процесс нелинейный... И вообще - посмотри какое-нить кино, как делают кино - читают по сотне раз, пока не научатся читать правильно. Откуда вывод - программы должны писать актеры .

З.Ы. Кажется в конце меня уже куда-то не туда занесло .
Наверх
Dron
Четверг 28.07.2005 17:24


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
Вообще давно известно что программирование процесс творческий, и гораздо лучше с ним справляются лингвисты а не математики...

А насчет программирования/непрограммирования...
Всетаки программирование - это не отдача компьютеру распоряжений. Мы же не считаем программированием кликание по иконкам в меню, хотя тем самым тоже побуждаем компьютер к совершению некоторых действий...

Rygoravich: Ты ведь не хочешь чтобы общение пользователей с компьютером напоминало съемку кино
Кадр первый дубль первый
- Хочу фильму...
- Не понял что вы хотите...
- Кино давай...
- Что давать?
Дубль тридцать первый...
- Выключайся.
- Нет такой команды...
- Шутдаун, Ресет, офф???
- Добро пожаловать в нашу супер дружественную систему!
[ Редактирование четверг 28.07.2005 17:31 ]

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев
Наверх
Сайт
Chizh
Вторник 02.08.2005 17:31
ID пользователя #90
Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170
>Операционная система будет мала, быстра и незаметна. Единственная ее цель - служить прослойкой между оборудованием и человеком. Поэтому ОС будущего будет скрывать железо насколько это только возможно.

Хотел бы я посмотреть как ОС скроет монитор, клаву, мышь, принтер, DVD диск и флэшку. Всё бы вам чего-нибудь скрывать Пользователь тебя ### если окажется что записанная информация попала не на нужный _девайс_.
В программировании сейчас уже так называемое "декларативное" программирование рулит. Как в SQL - ты указываешь что ты хочешь получить, но не заботишься как ты это получишь. В примере с чуваком - не "подними (_|_) и сходи за пивом в магазин", а "просьба принести пива". Как и откуда - не суть вопроса.

<span class='smallblacktext'>[ Редактирование вторник 02.08.2005 17:38 ]</span>
Наверх
Сайт
captain cobalt
Среда 03.08.2005 12:27

ID пользователя #12
Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144
Alexander написал(а) ...
Всё бы вам чего-нибудь скрывать
...
Как и откуда - не суть вопроса.
Противоречие?
batu написал(а) ...
Из обсуждения примера вы поняли что без проверки типов ... во время выполнения не обойтись.
Я протестую лишь против приведённых примеров, которые являются примером неправильного проектирования (например прибавление единицы к произвольному объекту).
При таком подходе из-за ошибок программирования может возникать "неожиданный полиморфизм" (бич некоторых языков программирования) - ситуация, когда корректная операция применяется к корректному объекту и вызывает некорректный (возможно, разрушительный) результат.

Например, известная история, когда Торвальдс "позвонил на винчестер" - это пример "неожиданного полиморфизма". Операция "позвонить" - корректна для некоторых устройств. Винчестер - тоже корректное устройство. А вот "позвонить на винчестер" - увы.

Разумеется, проверка типов иногда необходима. Однако, лучше, если она написана явно.
Сильная типизация - один из краеугольных камней Bluebottle. И динамическая проверка типов там есть. Кроме того, там есть активизация процесса по выполнению условия, причём синхронно с разблокировкой объекта. За счёт синхронности компилятор может оптимизировать сохранение контекста (в отличие от прерываний в произвольный момент времени) и это гораздо лучше вписывается в конвеер (опять в отличие от прерываний в произвольный момент времени). Если в Bluebottle есть все эти мечты, "why not Bluebottle?".
batu написал(а) ...
(а ткаже формирования адресной части команд) во время выполнения не обойтись
Про "формирование адресной части команд" до сих пор ничего не понятно.
Например?
batu написал(а) ...
Машина это будет делать или программа вопрос второй. Но если вы представили объем генерируемого кода и накладные расходы в программном решении, то... сделайте сами ыводы.И ведь мы говорим о будущем!
Одна проверка типа == одно сравнение - весьма немного. Кроме того, проектировать надо правильно.

Разумеется, это должна делать программа. Тогда процессор может быть проще, и, следовательно, может быть сделан быстрее, что приведёт к общему повышению производительности.

Возьмём, например, E2K.
Разработчики утверждают, что EPIC/VLIW должен вытеснить суперскаляры.
Суперскаляры - это машины которые динамически аппаратно во время выполнения выполняют instruction scheduling - выбирают подходящий порядок исполнения инструкций, меняют их местами и т. п. Это требует вычислительных ресурсов и серьёзно препятствует повышению параллелизма.
В EPIC/VLIW машинах instruction scheduling, в том числе распараллеливание, выполняет компилятор (естественно программно).

Вот оно будущее - очень быстрая и очень "тупая" машина с массовым параллелизмом и "умный" компилятор.
Осталось только взять с собой "умный" язык программирования.
И Bluebottle.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.
Наверх
Сайт
Chizh
Среда 03.08.2005 14:35
ID пользователя #90
Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170
captain cobalt написал(а) ...
Alexander написал(а) ...
Всё бы вам чего-нибудь скрывать
...
Как и откуда - не суть вопроса.
Противоречие?

Честно говоря те два абзаца не разные темы, просто я поленился писать два отдельных письма. Первый об архитектуре ОС, второй - о программировании. Наверно про программирование пример не очень правильный. Сопоставляя с SQL выражением "SELECT [x] FROM [y]" правилнее будет "ПРИТАЩИ [топлива] ИЗ [магаза за углом]"
Наверх
Сайт
Rygoravich
Вторник 16.08.2005 17:40

ID пользователя #10
Зарегистрирован: Воскресенье 04.07.2004 16:29
Местонахождение: Navapolatsk, Belarus
Сообщений: 30
Dron написал(а) ...

А насчет программирования/непрограммирования...
Всетаки программирование - это не отдача компьютеру распоряжений. Мы же не считаем программированием кликание по иконкам в меню, хотя тем самым тоже побуждаем компьютер к совершению некоторых действий...

Ну так о том я и говорю - пока не определимся с терминами - спорить бессмысленно...
Dron написал(а) ...

Rygoravich: Ты ведь не хочешь чтобы общение пользователей с компьютером напоминало съемку кино
Кадр первый дубль первый
- Хочу фильму...
- Не понял что вы хотите...
- Кино давай...
- Что давать?
Дубль тридцать первый...
- Выключайся.
- Нет такой команды...
- Шутдаун, Ресет, офф???
- Добро пожаловать в нашу супер дружественную систему!
[ Редактирование четверг 28.07.2005 17:31 ]

А теперь перечитай еще раз внимательнее - ведь в приведенном тобой примере проблемы возникают ТОЛЬКО потому, что компьютер недостаточно хорошо понимает человека... Ну нет на сегодняшний день таких технологий. А завтра они могут появиться. И тогда:
- Хочу фильму...
- Пожалуйста!
Просмотр фильма...
- Выключайся.
- Спокойной ночи. Включайте еще нашу супер дружественную систему!
Наверх
Переход на страницу  1 2 [3] 4 ... 13 14 15  

Перейти:     Наверх

Транслировать сообщения этой темы: rss 0.92 Транслировать сообщения этой темы: rss 2.0 Транслировать сообщения этой темы: RDF
Powered by e107 Forum System

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.