Мне представляется маловероятной, но к подобному подходу ("забудьте про файлы", "не надо загружаться") почему-то слишком многие стремятся, начиная с той же MS, дальше любимый Раскиным CanonCat, и так далее...
"A: Вполне реально. Прирост производительности разработчиков от простого перехода в разработке ПО с языка программирования C++ на языки Java и C# оценивается экспертами в 500 % — чем, собственно, и объясняется вытеснение первого языка двумя последними в течение достаточно короткого срока."
N>http://dz.ru/solutions/phantom/ N>кто что думает о подобной инициативе? N>Мне представляется маловероятной, но к подобному подходу ("забудьте про файлы", "не надо загружаться") почему-то слишком многие стремятся, начиная с той же MS, дальше любимый Раскиным CanonCat, и так далее...
Фантому лет 8 не меньше. Это он сейчас проснулся, а родился он давно.
Там плохой основной язык программирования.
При создании Фантома товарищи вдохновлялись идеями EROS. Но, поскольку вдохновение было давно, авторы Фантома ничего недавнего про EROS и его потомков не читали.
А авторы EROS перешли к написанию другой ОС — Coyotos, — и в процессе поняли, что их текущий ЯП C++ маловыразителен и стали собирать свой собственный язык — BitC.
О чем авторы Фантома и не подозревали.
В Фантоме нет разграничения на ядро и пользовательские процессы. Это подаётся авторами, как основное отличие от EROS. Но для такой организации всё равно необходим контроль за ресурсами, но уже на уровне типов. А их в языке толком и нет.
В общем, вот.
По-моему, будет "хотели как лучше, получилось, как всегда".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, netch80, Вы писали:
N>Мне представляется маловероятной, но к подобному подходу ("забудьте про файлы", "не надо загружаться") почему-то слишком многие стремятся, начиная с той же MS, дальше любимый Раскиным CanonCat, и так далее...
Давно пора. Я всегда говорил, что кнопка Save — это зло. Только у них не хватает возможности вернуть состояние любой программы на любой момент в прошлом (в том числе, и до прошлого выключения компьютера), и еще делать бранчи. Боюсь только представить, сколько ресурсов будет жрать такая система и как она будет тормозить.
Здравствуйте, nikov, Вы писали:
N>Давно пора. Я всегда говорил, что кнопка Save — это зло. Только у них не хватает возможности вернуть состояние любой программы на любой момент в прошлом (в том числе, и до прошлого выключения компьютера), и еще делать бранчи. Боюсь только представить, сколько ресурсов будет жрать такая система и как она будет тормозить.
Какие проблемы-то? Версирующие файловые системы давно уже существуют. В частности, то что ты описал УЖЕ делается с помощью ZFS — даже графический интерфейс в GNOME добавили: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs
Осталось только делать autosave после существенных модификаций.
Здравствуйте, thesz, Вы писали: T>А авторы EROS перешли к написанию другой ОС — Coyotos, — и в процессе поняли, что их текущий ЯП C++ маловыразителен и стали собирать свой собственный язык — BitC.
Кстати, а почему надо обязательно изобретать новый язык? Разве нельзя использовать существующий? Например OCaml (или Nemerle)?
Здравствуйте, Mr.Cat, Вы писали:
MC>Кстати, а почему надо обязательно изобретать новый язык? Разве нельзя использовать существующий? Например OCaml (или Nemerle)?
Потому что ни немерли ни окамл ни подходят на роль низкоуровнегого языка.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, nikov, Вы писали:
N>>Давно пора. Я всегда говорил, что кнопка Save — это зло. Только у них не хватает возможности вернуть состояние любой программы на любой момент в прошлом (в том числе, и до прошлого выключения компьютера), и еще делать бранчи. Боюсь только представить, сколько ресурсов будет жрать такая система и как она будет тормозить. C>Какие проблемы-то? Версирующие файловые системы давно уже существуют.
Ну одной из первых была VMS (считаем, середина 80-х). Тонкости подхода не помню — кажется, новая версия открывалась только при открытии, говоря сишным языком, fopen(,"w") — но сохранялось энное количество старых версий.
Но это при чётком оформлении понятия "а вот тут сохранить состояние". А без такого чёткого оформления я что-то плохо себе представляю этот подход...
Здравствуйте, netch80, Вы писали:
C>>Какие проблемы-то? Версирующие файловые системы давно уже существуют. N>Ну одной из первых была VMS (считаем, середина 80-х). Тонкости подхода не помню — кажется, новая версия открывалась только при открытии, говоря сишным языком, fopen(,"w") — но сохранялось энное количество старых версий.
Угу, регулируемое число версий, до 32768.
N>Но это при чётком оформлении понятия "а вот тут сохранить состояние". А без такого чёткого оформления я что-то плохо себе представляю этот подход...
Это просто нужно ещё добавить транзакционные файловые операции — как в NTFS. Т.е. делаешь "ioctl(fl, IOCTL_ADD_TO_TRANSACTION, trans)", делаешь изменения, а потом делаешь что-то типа "commit_trans(trans);".
Здравствуйте, Mr.Cat, Вы писали:
T>>А авторы EROS перешли к написанию другой ОС — Coyotos, — и в процессе поняли, что их текущий ЯП C++ маловыразителен и стали собирать свой собственный язык — BitC. MC>Кстати, а почему надо обязательно изобретать новый язык? Разве нельзя использовать существующий? Например OCaml (или Nemerle)?
У них цель — сделать полностью доказанное микроядро. Т.е. оно будет даже теоретически работать всегда корректно в отсутствие аппаратных сбоев.
T>>Фантому лет 8 не меньше. Это он сейчас проснулся, а родился он давно. A>Так они ее уже 8 лет разрабатывают? И она до сих пор у них еще в таком "загадочном" состоянии. Ладно, разбудите меня еще через 8 лет.
Они недавно проснулись и стали снова активно ей заниматься.
Поэтому не всё так плохо, но всё равно плохо.
PS
Со сроком я мог и напутать, но не сильно. Ну, шесть лет, вместо 8. По-моему, всё же, в районе 8.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>А авторы EROS перешли к написанию другой ОС — Coyotos, — и в процессе поняли, что их текущий ЯП C++ маловыразителен и стали собирать свой собственный язык — BitC. MC>Кстати, а почему надо обязательно изобретать новый язык? Разве нельзя использовать существующий? Например OCaml (или Nemerle)?
Из-за мощности доказательств.
В BitC ты можешь в типе данных или функции написать все необходимые инварианты (и они постоянно работают над расширением — то есть, проверяется, пока не всё, или не так удобно, как хотелось бы). В типе OCaml или Nemerle это, мягко говоря, трудно. Я думаю, сравнимо по сложности с созданием BitC.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Название хорошее — "Система призрак". Мне почему-то напомнило "Неуловимый Джо"
А если серьзено, то идея отказаться от сохранения мне нравится.
Но я не понял аргументацию в области:
1. Полного отказа от файлов. Хорошо когда файлы только для одного приложения, но как же разрулить ситуацию, когда один файл может использовать несколько программ? Кстати, нечто подобное было в palmOS — но там это решалось "базами" в памяти, которые могли разделяться между приложениями, ровно как файлы. И, соответственно, сохранять состояние разработчику надо было самому. Но пользователю было удобно. И для слабеньких первых пальмов это было очень эффективным решением.
2. Как согласуется то, что ОС сама всегда сохраняет состояние программы и возможность "перезапустить" программу для лишения проблемы утечки памяти? Если утечка "функциональная" — т.е. система просто не подчищает какие-то испольуемые списки, формально это не мусор, но по факту это неисползуемые программой данные, объем которых будет расти и расти. И будет честно сохраняться операционкой. А при перезапуске программы — честно зачитываться обратно...
3. Что будет с состоянием памяти и сохраненных пользовательских "документов" при обновлении версии программы? Не получится ли что усилия программиста по обеспечению обратной совместимости перебьют плюсы от ликвидации работы с файлами?
Правильно:
— Ребята написали прототип (Singularity), ЗАТЕМ начали строчить статьи "как у нас будет круто", "смотрите какие у нас результаты тестов" и т.п.
— В Ericsson создали erlang, но никому не сказали, опробовали, ЗАТЕМ написали кучу статей, защитили диссертации, где рассказали, как у них все круто и надежно и параллельно.
Неправильно:
— ОС будет крутая! Будет быстро! Вот какая идея! [БОЛЬШАЯ СТАТЬЯ 1 БОЛЬШАЯ СТАТЬЯ 2 БОЛЬШАЯ СТАТЬЯ 3]. А где результаты тестов? Есть downloads? Эээ, да мы еще толком и не начали, вот, эмулятор версия 0.0.0.1 вчера заработал...
— SymADE это революция! Все будет по уму! А почему из файлов только документы? Где в твоих статьях скриншоты? де результаты тестов? Эээээээээ, [1000000 слов], вы не понимаете, [1000 слов], дело в том, что [10000000 слов]. Вот.
Проекты это здорово, дай бог чтобы получилось. Но: есть заметная корреляция между тем, с чего все началось — с дел или со слов, и вышел ли из проекта толк. Почему бы не вложить время, потраченное на распихивание статей по инету, в написание еще хотя бы пары десятков строчек, которых проекту так сильно не хватает.
