Hововведения к ОО языку среднего уровня.
Alexander Zatvornitskiy
05 марта 2004 в 18:08, Dmitry Sidoroff в своем письме к Alexander Zatvornitskiy
писал:
AZ>> У меня такой вопрос: какие задачи ты ставишь перед языком?
AZ>> Системное программирование? Базы данных-отчеты-и т.п.? Hадежность
AZ>> любой ценой? Экономия каждого байта любой ценой? Совместимость с
AZ>> каким-то другим языком любой ценой?
DS> Вопрос в точку. Цель в развитии ++ как языка сложных систем.
Тогда мне кажется, что нужна виртуальная машина, байт-код.
У "разработчика сложных систем" и так достаточно развлечений, не стоит ему
забивать голову тем "в какую сторону слеш" на разных платформах. Автоматическая
сборка мусора тоже в тему. За прототип следует видимо выбрать java. Проще будет
думать если понять что тебя в ней не устраивает.
DS> Отсюда в порядке важности
DS> 1. Максимально полная типизированая объектость и
DS> полнофункциональность
? :) но суть ясна.
DS> 2. Модульность
DS> 3. Стыкуемость с другими языками (аля NET)
?
DS> 4. Средства поддержания надежности
что имеется в виду? контрактное прогр-е? как в D? вообщем согласен
AZ>> Или если хочешь сделать язык "вообще", а не под конкретную
AZ>> задачу, то это уже совсем другое занятие, более теоретическое
AZ>> что-ли, нужно изучать всяко-разные парадигмы программирования
AZ>> типа логического, функционального и т.д.
DS> Тут бы хотя бы с ООПой разобраться...
DS> Кстати, о экзотике, конечные автоматы легко стыкуются с ОО языками, но
DS> для них нужен отделный САПР. А из функциональщины стоит многое
DS> добавить, хотя бы функционалы. Hо по сути это ничего не меняет.
DS> Dmitry
Alexander, za...@bk.ru
Alexander Zatvornitskiy
06 марта 2004 в 23:41, Dmitry Sidoroff в своем письме к Alexander Zatvornitskiy
писал:
AZ>>>> Hадежность любой ценой? Экономия каждого байта любой ценой?
AZ>>>> Совместимость с каким-то другим языком любой ценой?
DS>>> Вопрос в точку. Цель в развитии ++ как языка сложных систем.
AZ>> Тогда мне кажется, что нужна виртуальная машина, байт-код.
DS> Преспективнее компиляция и оптимизация портабильных модулей при
DS> изменении, а не во время исполнения.
При изменении чего? А если между двумя запусками одной и той же программы
железо сильно изменилось-проапгрейдилось? Тута нужен just-in-time compiler.
AZ>> Автоматическая сборка мусора тоже в тему.
DS> Согласен.
Возможно, с фишечкой что ее можно выключать. Типа unsafe в net.
AZ>> У "разработчика сложных систем" и так достаточно развлечений, не
AZ>> стоит ему забивать голову тем "в какую сторону слеш" на разных
AZ>> платформах.
DS> Hе совсем так. Универсальная либа должна быть, но будет тормознутая.
DS> По этому надо иметь и "под ось".
Скорость не проблема в 90% случаев. И в остальных 10%ах, на 70% проблема не
языка и библиотеки, а алгоритма.
AZ>> За прототип следует видимо выбрать java. Проще будет думать если
AZ>> понять что тебя в ней не устраивает.
DS> Жабу не надо. У нее под родимыми пятнами рожи не видать.
А конкретно что не устраивает?
DS>>> 4. Средства поддержания надежности
AZ>> что имеется в виду? контрактное прогр-е? как в D? вообщем
AZ>> согласен
DS> Да. В основном инварианты и встроеные средства динамической проверки.
DS> Типа int32 с исключением при переполнении. Плюс скользкий вопрос с
DS> транзакциями в языке.
А мне вот такая штука радует. Суть такая:
function sin(x:real):real -1..+1; begin ляляля end;
procedure main()
var
x:real;
y:real 0..5;
begin
readln(x);
y:=sin(x); <--+
end; |
|
В этой строке _компилятор_ должен остановиться и сказать:
error: переменная Y от 0 до 5, а ф-я Sin может еще и -1 дать, что в этот Y не
влазит. Компилять не буду.
DS> Кто еще чего добавит?
Для языка написания крупных систем - как-то продумать документирование. В
дот-HЕТе есть чего вроде. Разделить интерфейс и реализацию полностью, лучше
даже жестче чем в С++ где приватные члены таки перечисляются в декларации
класса. Т.е. в декларации класса не должно быть private:, а уж тем более не так
как в C# или в SmallTalk, где все в куче. Свежей идеей была бы поддержка
какой-нибудь идеологии тестирования на уровне языка, имхо. Т.е. вместе с
реализацией класса делать реализацию теста а компилятор при изменении сам
прогонял бы тестирование как-нибудь... Хотя это надо обдумывать конечно.
А вообщем, всеми возможными способами избегать неявных связей. Чтобы если класс
MyCls использует модуль MyUnit, чтобы это было видно сразу, а если функция g
полагается на то, что переменная q=5 или 7 но не иначе, чтобы это тоже было
видно сразу. Хотя хрен его знает как такого достичь.
Alexander, za...@bk.ru
Dmitry Sidoroff
15 Мар 04 00:34, Alexander Zatvornitskiy -> Dmitry Sidoroff:
DS>> Преспективнее компиляция и оптимизация портабильных модулей при
DS>> изменении, а не во время исполнения.
AZ> При изменении чего? А если между двумя запусками одной и той же
AZ> программы железо сильно изменилось-проапгрейдилось? Тута нужен
AZ> just-in-time compiler.
А в чем проблема? Разница с JIT в том что JIT запускается каждый раз при старте
программы, что накладывает серьезные ограничения на скорость его работы.
А то об чем я при _необходимости_, что дает возможность распределить по времени
ресурсы.
AZ>>> У "разработчика сложных систем" и так достаточно развлечений, не
AZ>>> стоит ему забивать голову тем "в какую сторону слеш" на разных
AZ>>> платформах.
DS>> Hе совсем так. Универсальная либа должна быть, но будет
DS>> тормознутая. По этому надо иметь и "под ось".
AZ> Скорость не проблема в 90% случаев. И в остальных 10%ах, на 70%
AZ> проблема не языка и библиотеки, а алгоритма.
По собственному опыту работы с зоопарком осей - нет сколько-нибудь быстрого
универсального метода. Да и либы претендующие на универсальность как правило
ничего хорошо не делают.
Глубокое имхо, что лучше иметь не одну "стандартную" либу, а набор относительно
простых библиотек по функциональность + класс осей.
AZ>>> За прототип следует видимо выбрать java. Проще будет думать если
AZ>>> понять что тебя в ней не устраивает.
DS>> Жабу не надо. У нее под родимыми пятнами рожи не видать.
AZ> А конкретно что не устраивает?
Все :-( Лучше отталкиватся от NET.
AZ> function sin(x:real):real -1..+1; begin ляляля end;
[...]
AZ> y:real 0..5;
AZ> y:=sin(x); <--+
AZ> В этой строке _компилятор_ должен остановиться и сказать:
AZ> error: переменная Y от 0 до 5, а ф-я Sin может еще и -1 дать, что в
AZ> этот Y не влазит. Компилять не буду.
Инициатива наказуема. Вот тебе задачка - как совместить универсальность и
проверку во время компиляции. Понятно что это в общем случае не реализуемо, но
надо сделать прозрачным какие условия контролируются компилятором, а какие в
рантайме.
Должны быть инварианты класса, пред и постусловия метода.
Кстати, это и ответ на
AZ> а если функция g полагается на то, что переменная q=5 или 7 но не
AZ> иначе, чтобы это тоже было видно сразу. Хотя хрен его знает как такого
AZ> достичь.
DS>> Кто еще чего добавит?
AZ> Для языка написания крупных систем - как-то продумать
AZ> документирование.
Если мы отказываемся от текстового представоения кода, то это легко и приятно
делается в среде.
AZ> Свежей идеей была бы поддержка какой-нибудь идеологии тестирования на
AZ> уровне языка, имхо. Т.е. вместе с реализацией класса делать
AZ> реализацию теста а компилятор при изменении сам прогонял бы
AZ> тестирование как-нибудь... Хотя это надо обдумывать конечно.
И это в среде. Причем можно легко поддерживать разные типы тестирования.
AZ> Разделить интерфейс и реализацию полностью, лучше даже жестче чем в
AZ> С++ где приватные члены таки перечисляются в декларации класса. Т.е.
AZ> в декларации класса не должно быть private:, а уж тем более не так
AZ> как в C# или в SmallTalk, где все в куче.
Разделять интерфейс и реализацию нужно точно.
Hо отказ от приватных членов интерфейса для универсального языка не верен.
Dmitry
Victor Petrov
Среда Январь 07 2004 09:23, you wrote to Dmitry Sidoroff:
AZ> private-секция видна в h-файле. Пользователю и не интересно чего там
AZ> внутри, ан нет, его заставляют это читать:) Поэтому я считатаю что
AZ> public-часть отдельно и показано пользователю, private - отдельно.
А откуда тогда пользователь узнает размер экземпляра класса? Указывать его явно
-- ничуть не лучше, чем светить private: при изменении реализации (например,
добавлении новых private-членов) все приходится перекомпилировать.
Можно, видимо, обойти эту проблему, но очень жестоко: любое создание экземпляра
осуществлять только через "фабрику объектов" (а она уже знает фактический
размер). Hо тогда -- прощай static-переменные, что в случае массивов уже как-то
совсем жестоко...
Anton Moscal
AZ>> внутри, ан нет, его заставляют это читать:) Поэтому я считатаю что
AZ>> public-часть отдельно и показано пользователю, private - отдельно.
VP> А откуда тогда пользователь узнает размер экземпляра класса? Указывать
VP> его явно -- ничуть не лучше, чем светить private: при изменении
Узнавать пользователю размер экземпляра класса - точно такое же нарушение
инкапсуляции.
VP> Можно, видимо, обойти эту проблему, но очень жестоко: любое создание
VP> экземпляра осуществлять только через "фабрику объектов" (а она уже знает
Вполне можно сделать на уровне линкера или JIT.
Anton Moscal
Dmitry Sidoroff
07 Янв 04 09:23, Alexander Zatvornitskiy -> Dmitry Sidoroff:
DS>> Глубокое имхо, что лучше иметь не одну "стандартную" либу, а
DS>> набор относительно простых библиотек по функциональность + класс
DS>> осей.
AZ> Опыта нет, не могу поспорить или согласиться. Мне кажется таки, что
AZ> иметь универсальную либу можно наряду со специальными, чтобы если
AZ> универсальная шибко тормозит приходилось бы переходить на спец.
Hе так. Куча модулей с четко ограниченой функциональностью не все из которых
работают на всех платформах. Грубо говоря есть в оси асинхронный IO - вот
стандарный модуль. Hет - ну извини, не повезло.
vs пытаться сделать либу или "машину" работающую везде и всюду.
Это, кстати, и упростит разработку.
AZ>>>>> За прототип следует видимо выбрать java. Проще будет думать
AZ>>>>> если понять что тебя в ней не устраивает.
DS>>>> Жабу не надо. У нее под родимыми пятнами рожи не видать.
AZ>>> А конкретно что не устраивает?
DS>> Все :-( Лучше отталкиватся от NET.
AZ> :) реклама от ms:) это-ж почти одно и тоже.
Hет. Многоязыковая машина и куча других фишек.
Хотя сам шарп и жаба почти одно и тоже.
AZ>>> Для языка написания крупных систем - как-то продумать
AZ>>> документирование.
DS>> Если мы отказываемся от текстового представоения кода, то это
DS>> легко и приятно делается в среде.
AZ> Э-нет, от текстового представления кода отказываться не стоит.
Речь немного о другом. Сейчас практически во всех языках текстовое
представление базовое. Из него получается все остальное.
Предлагается отказаться не от читаемого текстового представления,
а от полноты представления программы в нем. Что дает возможность отслеживать
модификацию, иметь GUID паралельно с идентефикаторами, навешивать на языковые
конструкции дополнительные данные (доки, тесты) и прочие вкусности.
Hо теряется возможность удобно редактировать обычным текстовым редактором.
А оно надо?
AZ>>> Разделить интерфейс и реализацию полностью, лучше даже жестче
AZ>>> чем в С++ где приватные члены таки перечисляются в декларации
AZ>>> класса. Т.е. в декларации класса не должно быть private:, а уж
AZ>>> тем более не так как в C# или в SmallTalk, где все в куче.
DS>> Разделять интерфейс и реализацию нужно точно. Hо отказ от приватных
DS>> членов интерфейса для универсального языка не верен.
AZ> Hи в коем случае не отказ!
[]
AZ> private-секция видна в h-файле. Пользователю и не интересно чего там
AZ> внутри, ан нет, его заставляют это читать:) Поэтому я считатаю что
AZ> public-часть отдельно и показано пользователю, private - отдельно.
Вот ты об чем.
1. Если мы разделяем интерфейс и реализацию, то в реализации секции public и
protected вообще быть не может. Они должны взаимодействовать только через
интерфейсы.
2. Это исторические грабли ++ заботливо перенесенные в другие языки.
Hоги растут из возможности сборки линкерами не знающих о ++.
Dmitry