Re[6]: Ой, чо с D деется-то!?
От: Андрей Хропов Россия  
Дата: 17.11.06 18:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

АХ>>Ну хорошо, выражусь по-другому: в системном языке должна быть возможность спуститься на низкий уровень и контролировать каждый бит. Все время это делать не надо, но, скажем, критические части ядра ОС по-другому не напишешь.

WH>Ну загрузчик по любому нужно писать на асме. Тут даже С не подходит.
C + inline asm

WH>А вот то что пишут на С уже можно писать на чемто болие высокоуровневом.

Можно, но возможность спуститься на низкий уровень должна быть.

WH>>>Все что нужно это value-типы, поддержка двоичных данных на уровне виртуальной машины и оптимизатор который умеет делать region-inference. Еще нужно иметь несколько различных алгоритмов сборщика мусора в том числе подсчет ссылок и вобще отсутствие сборщика мусора (работает только region-inference).

АХ>>Не согласен.
АХ>>Помимо этого должна быть возможность вообще не пользоваться сборщиком мусора,
WH>Перечитай еще раз что я сказал.
region inference говоришь. И где-нибудь он реализован? Как это на практике работает?
Он все равно кажется не слишком предсказуемым. Это вроде статического GC как мне кажется или то что иногда называют memory pools.

АХ>>должен быть встроенный ассемблер (желательно с легко настраиваемым под конкретную архитектуру набором инструкций)

WH>Только для загрузчика. А для этого проще внешний язычек прикрутить.
А мне больше нравится встроенный асм, хотя бы потому что можно имена переменных те же использовать.

АХ>>Также должны быть средства жесткого задания бинарного представления в структурах (в D есть шаги в этом направлении).

WH>Я про это и говорил когда говорил про работу с битами на уровне ВМ.
понял

АХ>>Ядро в Singularity написано на assembler + C++ + С# (safe и unsafe).

АХ>>Хотя неверифицируемая часть состоит всего из 5% кода.
WH>5% это много. Должно быть много меньше.
Откуда такие выводы?

АХ>>Как в текущей реализации D.

АХ>>Да, вот и надо приделать к D точный копирующий GC.
WH>hint: union
Да выкинуть их давно надо. Я ими никогда не пользовался.
Хороший оптимизатор все равно в случае чего (если это безопасно) может соптимизировать распределение памяти.

АХ>>Почему? Надо только разобраться с вопросом можно ли (и как) работать с указателями на GC объекты.

WH>С указателями на ГЦ объект работать нельзя никак.
WH>Иначе ни какого точного ГЦ не будет ни когда.
Можно, только осторожно (например, специально помечая). Проще конечно запретить.

АХ>>Дизайн D вообще говоря меняется.

WH>Дык. Надо же с самого начала все продумывать, собирать информацию о других языках... проанализировать к чему приведет то или иное решение.
WH>А автор D этого не сделал... вот теперь и мучается...
WH>С языками программирования как и интерфейсами объектов. Есть толстые и есть тонкие.
WH>Толстые с виду проще но если нужно сделать что-то чего не предусмотрено то все... тушите свет...
WH>Вот D это толстый язык, а немерле тонкий.
WH>Вот попробуй к D прикрутить late.
WH>Что не можешь? Нужно уговаривать автора?
WH>А к немерле его прикрутил человек не имеющий к самому компилятору никакого отношения.
WH>Таким образом ребята сейчас фиксят баги в ядре, а фенечки наворачивают совершенно посторонние люди.
WH>Причем если к D прикрутить что-то типа late то он появится у всех. Даже у тех кому он не нужен. В случае с немерле все это прекрасно рулится при помощи подключения библиотек с расширениями и using.

Согласен. Вальтер на мой взгляд не слишком хороший разработчик языков. Хотя хороший разработчик быстрых компиляторов.

Если бы я сам выбирал на чем разрабатывать, я бы выбрал Nemerle основным языком и С++ или D для критических по скорости и затратам памяти частей.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.