OSDev

Перечитал сегодня, что про Кантор на другом форуме написали.

Анекдот в том, что в рамках разработки альфы я хотел написать в блог про "Hello, world!", но пока не нашел нужного слога. Уж слишком заморочисто у меня получается, хоть в книгу рекордов Гиннесса подавай. Так что доля правды в критике есть.

Если описать "Hello, world!" всё же удастся, это снимет хотя бы часть вопросов, почему Кантор разрабатывается не так быстро, как хотелось бы. Из-за высокой связности большинство абстракций приходится прорабатывать сразу, иначе разработка теряет смысл. Уже не раз говорил. Остается надеяться, что результат выйдет достойным.

_________________
Путь успеха Циолковского — правильно умереть

Я свою ОС тоже накатами пишу. С паузой по полгода. В этом году я наверно добрался до 1/3 ядра. Как говорят самое сложное и всё самое интересное только впереди. Зато это тот этап когда не просто пишешь но уже и видишь результат своего труда!


Да вы пишете сложно. В принципе как писать просто есть советы. Есть серия книг - "для чайников ...". Надо писать в таком стиле. Собственно где-то слышал что есть советы от издательств по стилю. Основной совет представить, что ваш читатель ничего не знает вот и пишите таким стилям что-бы он вас понял. Не использовать непонятных и новых слов. Каждое новое слово снижает число читателей в 2 раза. Ещё хорошо освоить технику использования аналогии. Только учесть что есть хорошая аналогия и плохая.

Можно конечно разъяснять для чего и зачем как в книге четырёх про ООП. Или просто показать как это сделал Вирт в своей книге алгоритмы+структуры=программы. Именно такой наглядный подход с рисунками и образами запомнился многим. И те просто начали копировать решения. Человек мыслит образами или как говорят в яндаксе словами и фразами.

От кстати следует надобность в погружении читателя в область. А вот это в вашем стиле как раз и не хватает. Вы когда проблематику описываете вы используете сложные и новые слова.

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

_________________
Путь успеха Циолковского — правильно умереть

В альфе Кантора программа "Hello, world!" должна выглядеть так:

Оператор return -- обычный оператор возврата значения функции, а программа является анонимной функцией, возвращающей строку. Это отличает Кантор от других языков и упомянуто в конце списка "Чего нет в языке Кантор":

     Понятия файла и консоли, а также встроенных в язык операторов или функций ввода-вывода.

Тем самым уже в простейшей программе обработка и отображение данных архитектурно разделены. В альфе Кантора, понятное дело, отображение будет делаться встроенным кодом среды, а потом, когда появится обертывание системных функций, консоль будет написана на Канторе, и выбор конкретной реализации станет параметром сборки. Совсем в будущем будет доступна не только консоль, но также GUI и ZUI.

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

Получается, что на "Hello, world!" я отрабатываю функциональное программирование. Программы-процедуры появятся чуть позже, для них нужно больше работы.

Это не все задачи, связанные с "Hello, world!", пока описал лишь часть из них. За скобками осталась инфраструктура и ООП -- они связаны.

_________________
Путь успеха Циолковского — правильно умереть

Basic завоевал свою популярность потому что у него был встроен ввод и вывод в отличие от фортрана. Потом уже в фортран ввели встроенный ввод вывод. Собственно по этой причине считают что Паскаль создавался для обучения.

Интересно как на канторе вывести более сложную вещь такую как таблица? К примеру как тут
http://forum.sources.ru/index.php?showt ... &p=3593074

И как вы планируете сделать быстрый вывод десятичных чисел?

Бейсик и Паскаль, в отличие от Фортрана, создавались для обучения, причем Бейсик -- вообще для непрофессионалов. Уж кто-то, а вы должны знать, что эти самые процедуры ввода-вывода в Паскале, не имеющие штатного объявления в самом языке, так и остались родимым пятном, а код, их реализующий, лишь неоправданно утяжеляет RTL Delphi или FPC, а реально используется только в обучении.

В языке, ориентированном на системное программирование, ввод-вывод обязательно должен идти в библиотеке и быть заменяемым, раз уж есть ООП. А Кантор вообще создается как язык для всего, поэтому ввод-вывод может быть генерацией веб-страницы, например. Предлагаемая мной концепция в нее укладывается, а прибитый гвоздями ввод-вывод -- нет, будет еще один Delphi.


Не понял вопроса. Если таблицу нужно вывести как текст, она генерируется любым способом, а потом возвращается как текст (или как HTML-таблица, если вдруг). А если подразумевается что-то посложнее и поинтерактивнее, уже нужна абстракция программы-процедуры, которая пока не готова. Могу сказать лишь, что программа-процедура должна абстрагировать точку входа программы, и весь ввод-вывод будет написан уже на Канторе, -- или в самой программе, или взят из библиотек.

Собственно, первая задача после выпуска альфы с "Hello, world!" -- прикручивание импорта системных функций и перенос всей магии среды в код на Канторе. Я всё же компилятор пишу, а работающий интерпретатор -- часть процесса самораскрутки. В конце концов Кантор будет написан на Канторе.

Быстрый вывод десятичных чисел прост, поскольку в Канторе всё есть объект:

_________________
Путь успеха Циолковского — правильно умереть

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


Наличие объектов не делает код быстрым. Ровно как и медленным. Но любая абстракция как правило снижает скорость работы. Но этот вопрос касался не ООП. А то что как я понимаю кантор носит функциональный характер. А значит вывод числа будет медленным, так как без разворота число не сформировать.

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


Объектный код будет представлять собой набор объектов, образующих объектную модель (OM), которая должна уметь сохраняться в файлы и подниматься из них. В памяти она будет представлять собой мини-ООСУБД и мини-ОООС одновременно, для чего соответствующие концепции должны быть проработаны до пригодного для реализации состояния.

Я бы, конечно, мог реализовать альфу при помощи указателей, записей и перечислимого типа, как описывают AST в учебниках, но зачем? И так дофига кода выкинул. Нужно заложить основу для всех этих ОООС, ООСУБД и суперкомпиляторов в коде, для чего и поднял теории.


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

_________________
Путь успеха Циолковского — правильно умереть

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

     Объектно-ориентированная ОС абстрагирует двоичные интерфейсы и контейнеры так же, как концепция UNIX абстрагирует текстовый ввод-вывод и консоль.

Соответственно, если абстракция двоичных интерфейсов является первичной, всё остальное должно выражаться через нее, в том числе и консоль -- для обратной совместимости.

Про ООП и класс как единицу трансляции напишу отдельно.

_________________
Путь успеха Циолковского — правильно умереть

Как-то всё сумбурно.


Консоль, это скорее концепция машины разумной с которой можно говорить. Задавать вопросы и она будет отвечать.

Языки программирования они строились на разных концепциях. Ориентированный на ввод/вывод это скорее PhP и JavaScript. А взять MySQL где концепция описания результата без описания метода реализация и ввод/вывод не предусмотрен. Ассемблер был упрощением набора программ и дальнейших потребностей обычного работника. Фортран транслятор формул и вообще ввод и вывод не подразумевал и в первых версиях отсутствовал как класс.


Unix не абстрагирует ввод-вывод и консоль. У UINIX один интерфейс для ввода/вывода и один для консоли! Возможно вы имели в виду сокрытие?


Совместимость с чем? И почему обратная?

Причем тут двоичные интерфейсы? Почему не просто интерфейсы? ООП - подразумевает использования: абстрагирования, делегирования, сокрытия, капсулирования.

Больно крупная единица. Ведь класс состоит из данных и методов. А методы это наборы комманд. Которые связаны между собой. Допустим последовательно; или линейно с ветвлениями.