Версии

Я также предполагаю сохранение версий каждого объекта при его изменении. Так что, вместо реального изменения объекта будет производиться его клонирование и дальнейшее изменение клона. Таким образом, если вы сделали ошибку и вам необходимо откатить изменения, или если вы хотите увидеть, какие произошли изменения, вы можете увидеть различия. То есть у вас будет встроенный CVS.

Продолжая эту тему, должен быть механизм очистки системы от старых объектов, которые более не нужны. Например, если вы работали над каким-либо исходным кодом и версия 7 у вас работала, а потом вы сделали изменения в версиях 8, 9, 10, 11 и 12. А в версиях 9, 10 и 11 содержались ошибки, которые вы не хотите сохранять. Когда вы завершите, у вас должна быть возможность удалить эти ненужные версии.

Сегодня дисковое пространство чрезвычайно дешево. Я только что проверил, вполне можно купить жесткий диск на 200 гигабайт за чуть более $100. А диски Blu-ray от Sony будут способны хранить 23 гигабайта данных в одном слое. Имея такие объемы устройств хранения, я думаю, что сохранение нескольких копий вашей работы имеет смысл.

Безопасность

Безопасность - один из аспектов, который я еще не окончательно продумал. Но вот то, над чем я размышлял:

<ul><li>Различные части объекта могут иметь различные уровни безопасности. Например, если у вас есть объект Person, некоторая его информация может быть публична, например, имя человека и адрес его электронной почты. Но другие части могут быть доступны только меньшей группе, такой как ваши коллеги по работе, например, номер вашего сотового телефона. А какая-то информация будет доступна только избранным, такая как номер вашего социального страхования.</li>
<li>Все непубличные данные, когда они не находятся в оперативной памяти, будут шифроваться. Когда эти данные хранятся на любом носителе или передаются по сети, они будут зашифрованы.</li>
<li>Должен быть какой-то механизм создания групп, который позволит сгруппировать людей, схоже с механизмом групп в Unix/Linux.</li>
<li>Также должны существовать различные уровни безопасности. Например, когда вы авторизованы как вы сами, у вас будет доступ к некоторым данным просто исходя из вашей аутентификации по логину. Затем уровень безопасности выше, когда даже при том, что вы авторизованы своим логином, вам необходимо ввести еще один пароль для доступа к специфичным данным. Возможен еще один уровень безопасности, еще выше, когда вам придется ввести еще один пароль или использовать какую-либо смарт-карту, ключ, или что-то подобное. В Mac OS X используется схожий механизм, разделяющий обычный доступ и "администраторск", который используется для установки ПО или внесения серьезных изменений в конфигурацию. Я бы хотел иметь эти несколько уровней из одного аккаунта пользователя. Например, вы можете иметь нормальный уровень безопасности, когда вы пишите отчет о глобальном потеплении. Но вам, наверное, захочется иметь повышенный уровень безопасности для объекта, который хранит номер вашего социального страхования. Я хочу также интегрировать что-то вроде SE Linux, который устанавливает "" того кто что может делать. Например, не должно быть одного могущественногопользователя, который может читать любой объект системы, даже тот, который содержит ваш номер социального страхования.</li></ul>

Кэширование в ОЗУ

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

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

Больше последовательноти

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

Мне кажется, что вместо запуска из ничего каждый раз и затем завершения приложений так, как их никогда и не было, было бы лучше если (хотя бы некоторые) приложения сохраняли свое состояние нетронутым. Это будет более похоже на их включение и выключение.

Например, я не понимаю, почему офисный текстовый редактор не может быть более похож на печатную машинку? Положим, у вас есть листок бумаги в печатной машинке и вы находитесь в процессе напечатывания чего-нибудь. Вам звонят, отрывают от дела, вам надо лететь в Стамбул, вы выключаете ее (полагаем, что это электронная печатная машинка) и оставляете. Через шесть месяцев вы возвращаетесь, включаете ее, и она в том же состоянии, как она была когда вы ее оставили.

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

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

Спускаемся ниже

Большая часть из того, что я обсуждал до этого - это высокий уровень, в реальности лишь верхушка операционной системы. На самом же деле мой первоначальный план по доказательству концепции - построить упомянутое выше объектное хранилище поверх Linux и/или одной из BSD.

Но затем мне захотелось расширить объектную парадигму дальше. Я хочу, чтобы все в операционной системе было объектно-ориентированно, кроме самого ядра. Я полагаю, что в ядре получится что-то вроде виртуальной машины Java. Когда компьютер включается, он загружает виртуальную машину, скорее всего с чем-нибудь вроде Just In Time компилятора для ускорения. После этого все объектно-ориентированно.

Что в языке

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

Хорошо, сейчас я нарушу один из своих принципов и немного пройдусь по C++. Я знаю, что можно писать хороший код на C++. Можно писать хороший код на языке ассемблера. Вся штука в количестве вовлеченных сложностей. Я работал во многих проектах на C++, но я не работал ни над одним, где я бы чувствовал его продуктивность. Даже те проекты, что я делал полностью сам на C++, были ужасом. Я обнаружил, что обычно это приводит к одной из двух вещей: разработчики приклеиваются к небольшому подклассу языка, так что это на самом деле просто C с несколькими объектами, вброшенными тут и там; или он становится настолько сложен, что у большинства людей появляются трудности с его пониманием, а добавление или поддержка функций становится кошмаром. Я помню как в одном проекте разработчик жаловался, что для добавления одной простой возможности ему пришлось изменять 42 различных файла. Когда код становится настолько сложен, это плохо. В своей книге "Thinking in C++" (в русском переводе - "Философия С++" - примечание переводчика) Брюс Эккель говорит о том, что C++ даже запутаннее, чем Ada. В Интернете можнество сайтов о проблемах с C++, например: Why C and C++ Are Bad. По моему мнению, язык должен делать написание хорошо спроектированноо и легкого в поддержке кода настолько простым, насколько это возможно. И мне кажется, что C++ в области здорово проигрывает.

Я знаю, что сейчас 99% программистов всего мира просто прекратят чтение. Но мой опыт показывает, что Eiffel и Design by Contract (контрактное проектирование) - абсолютное благо для программировани.

Давайте я приведу пример где, как я думаю, контрактное проектирование может быть серьезным улучшением. Одной из самых серьезных причин дыр в безопасности ПО является переполнение буфера. И я думаю, что эта ошибка лежит в языке C, он просто ничего не проверяет. А программисты не идеальны, они делают ошибки и C позволяет им делать ошибки. Я уверен, что если бы использовался язык вроде Eiffel, который проверяет состояния ошибок, ПО было бы более безопасно. (Единственная оговорка здесь в том, что вы не можете отключить эти проверки, они всегда должны быть на месте. Я бы с удовольствием пожертвовал немного производительноти ради безопасности.)

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

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

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

Исходя из хранения кода как объектов, вместо текста, мне пришла в голову еще одна мысль - вы сможете смотреть/редактировать код в вашем любимом формате. Если вам нравится картина фигурных скобок, которую можно видеть в языках семейства C, вы можете просматривать программу вот так:

if (a == b) { c++; }

Можно будет даже убрать все эти аргументы выше фигурных скобок:

if (a == b) { c++; }

А если вы предпочитаете более легкий для чтения синтаксис:

if a = b then c := c + 1; end

индекс статьи
страница 1 : страница без заголовка
страница 2 - текущая : страница без заголовка
страница 3 : страница без заголовка
страница 4 : страница без заголовка