Re[2]: Несколько предложений - Философия программирования

Здравствуйте, Cyberax, Вы писали:

C>Kluev wrote:
>> Вряд ли, С++ убьет аналогичный низкоуровневый язык в котором будет
>> обеспечена обратная binary compatibility м-ду версиями классов. Тогда
>> будет устранен его единственный недостаток который не позволяет создать
>> стройный framework, т.е. привести зоопарк библиотек к некой общей основе.
C>Ну в D это возможно — они думают над стандартом на ABI. Если хорошо его
C>продумать — то вполне такое возможно.

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

К примеру если в ДЛЛ

struct Foo
{
   int  x;
};

А в том кто ее линкует
void test()
{
   Foo f; // на стеке
}

То добавить переменную в класс Foo без перекомпиляции всего уже не получится

struct Foo
{
   int x;
   int y;
};

Вместо этого прийдется юзать pImpl

struct Foo
{
  struct FooImpl *impl; // impl меняем как хотим.
};

Для переменных pImpl еще спасет хотя это не маленький оверхед: память выделяется динамически по любому, а вот от добавления виртуальной функции уже не спасет. К тому же паттерн pImpl — неудобен.

Единственный выход из это ситуации (если хотим жить без перекомпиляции), создавать VMT и разметку классов динмаически, в процессе загрузки. А если сразу это в язык не заложить то потом уже поезд ушел.

>> Причем добавить это достаточно просто с небольшим оверхедом. Back-end
>> уже есть (за что респект GCC team).
C>Угу.

>> З.Ы. Я периодически начинаю писать и проект у меня лежит (пока только
>> парзер), но мысль об обьеме пугает меня.
>> Может кто возьмется?
C>У меня постоянно такая же мысль. Только вот времени нужно ОЧЕНЬ много.

Сложно сказать.

Здравствуйте, VladD2, Вы писали:

GZ>>Эквивалентность может измеряться по разному. Действительно, если немного подвернуть эти примеры, то можно получить эквивалентные по функциональности подпрограммы. Но можно измерять эквивалентность с помощью генерируемых кодов которые должен выполнять процессор. Числодробилки пока никто не отменял. И тут у меня есть некоторая догадка, что чем больше знает компилятор об обрабатываемых конструктциях, тем больше у него возможностей оптимизации. Ты рассматривал этот вопрос?

VD>Я уверен в справедливосьи теоремы о том, что эквивалентный код может порождать идентичный машинный код. И в том, что качественный оптимизирующий компилятор будет переписывать конструкции наиболее оптимальным образом и в итоге породит идентичный код.
Я тоже уверен в справедливости этой теоремы. Только я также уверен в том, что sql никогда не преобразуется в действительно оптимальный набор команд, поскольку для этого надо решить по крайней мере 2 NP задачи.

GZ>>И еще:
GZ>>

GZ>>Так в чем же удача Nemerle-овцев и ошибка C++-ников?

GZ>>Я не очень то согласен что у C++-ников была какая-то ошибка.

Не очень хорошая фраза. В чем ошибка? В том, что С++ ники пользуются побочными эффектами С++? Запретим им пользоваться, то будет лучше?

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

А во вторых я имел ввиду что это можно назвать ошибкой языка, а не ошибкой C++-ников.

Иначе ты людей обижаешь на ровном месте.

GZ>>ЗЫ. К сожалению, статью полностью прочитать смогу только вечером(сегодня привезут журнальчик). Поэтому это касается только вступления. Слишком уж резануло

VD>Ну, вот когда прочтешь до конца, то с удовольствием послушаю мнение о статье. А то споры явно уходят в сторону от сути статьи.
Прочел. Не понравилось. Влад, какого фига ты сравниваешь метапрограммирование с макросами макроассемблера? Макроассемблер родил С, С родил С++. Фича оставалось неизменной. Но сейчас развитие языка (с помощью библиотек) идет на основании шаблонов.(за некоторыми исключениями). Твое сравнение не есть корректно. После публикации главы "Расширение синтаксиса" будет нехилый флейм.

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Kluev, Вы писали:

K>>З.Ы. Я периодически начинаю писать и проект у меня лежит (пока только парзер), но мысль об обьеме пугает меня.

Д>полноценный совместимый со стандартом парсер?

Со стандартом, только со своим.

Д>Был кстати еще проект по внедрению полноценной кодогенерации в С++ (в Bell Labs), но он кажется уже загнулся. Хотя если бы они это доделали, то С++ мог бы получить второй шанс

В С++ сахара и так достаточно. Никудышная модульность, препроцессор, крайняя сложность разработки всяких IDE под него. Вот что его губит. Более того дополнительный сложный сахар — он скорее ускоряет его конец чем оттягивает его. Т.к. при существующей инфраструктуре сырец->препроцессор->единица_трансляции->компилер->обьектник->линкер все становится крайне сложным. Должно быть так:

сырцы->parser->(ast файлы для всяких рефактори-броузеров)->компилер->модуль с интерфейсом на борту.

Никаких хидеров и препроцессора. Вместо препроцессора празер должен давать ast в стандартизованном формате, чтобы IDE писатели не мучались.

P/S/ А всякие рассужедния о том что в С++ не хватает сахарка А или сахарка Б — это просто от непонимания сути воопроса и проблем программирования вообще. Продвигая сахарок народ с мухами сражается, не замечая чудовищных глобальных проблем готорые достались от С

Здравствуйте, Kluev, Вы писали:

K>Единственный выход из это ситуации (если хотим жить без перекомпиляции), создавать VMT и разметку классов динмаически, в процессе загрузки. А если сразу это в язык не заложить то потом уже поезд ушел.
В конце концов у тебя получится жаба или .НЕТ... Так зачем мучаться?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Kluev, Вы писали:

K>>Единственный выход из это ситуации (если хотим жить без перекомпиляции), создавать VMT и разметку классов динмаически, в процессе загрузки. А если сразу это в язык не заложить то потом уже поезд ушел.
WH>В конце концов у тебя получится жаба или .НЕТ... Так зачем мучаться?

Нет. Ни то и не другое. язык будет такимже низкоуровневым как и С++, просто для классов которые экспортируются из ДЛЛ добавится дополнительный уровень виртуализации.

В С++ чтобы добратся к переменой класс комилер делает:
ptr_to_Field = ptr_to_Object + FieldOffset (где FieldOffset константа)

А нужно сделать чтобы для нектороых классов была возможность FieldOffset сделать переменным (вернее он должен вычислятся в момент инициализации, сразу после загрузки модулей). Тогда изменения в layout-е базовых классов не страшны.

Аналогично для VMT, компилер выбирает функцию из VMT зная ее индекс. Для некоторых классов индекс так же будет динамическим

Здравствуйте, Kluev, Вы писали:

K>Нет. Ни то и не другое. язык будет такимже низкоуровневым как и С++, просто для классов которые экспортируются из ДЛЛ добавится дополнительный уровень виртуализации.
Вот у нас уже появилась метаинформация те один шаг до рефлекшена.
Далие нам понадобится что-то сделать с менеджером памяти... а там глядишь уже и до ГЦ недолеко.
Потом захечется код во время исполнения сгенерить... и вот у нас уже появляется System.Reflection.Emit...
...
Так зачем мучаться?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

WolfHound wrote:
> K>Нет. Ни то и не другое. язык будет такимже низкоуровневым как и С++,
> просто для классов которые экспортируются из ДЛЛ добавится
> дополнительный уровень виртуализации.
> Вот у нас уже появилась метаинформация те один шаг до рефлекшена.
Так как бы с этим никто и не спорит — reflection запросто реализуется и
без VM.

> Далие нам понадобится что-то сделать с менеджером памяти... а там
> глядишь уже и до ГЦ недолеко.
Опциональный GC с тщательной проработкой взаимодействия с другими
менеджерами — тоже нормальная вещь. И делается это намного проще, чем в
C++/CLI если не задумываться о совместимости с .NET.

> Потом захечется код во время исполнения сгенерить... и вот у нас уже
> появляется System.Reflection.Emit...
А вот это уже не нужно. Так же как и JIT-компиляция и байт-код.

> Так зачем мучаться?
В .NET слишком много нужного .НЕТ. И добавить это не ломая самых основ —
не получится.

Posted via RSDN NNTP Server 2.0

FR,

K>>>Единственный выход из это ситуации (если хотим жить без перекомпиляции), создавать VMT и разметку классов динмаически, в процессе загрузки. А если сразу это в язык не заложить то потом уже поезд ушел.
WH>>В конце концов у тебя получится жаба или .НЕТ... Так зачем мучаться?

FR>Необязательно, может получится и что-то совсем другое

+1
У других получился Erlang, и ещё у третьих — Java, а у четвёртых вообще попугай (Parrot)

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Kluev, Вы писали:

K>>Нет. Ни то и не другое. язык будет такимже низкоуровневым как и С++, просто для классов которые экспортируются из ДЛЛ добавится дополнительный уровень виртуализации.
WH>Вот у нас уже появилась метаинформация те один шаг до рефлекшена.
WH>Далие нам понадобится что-то сделать с менеджером памяти... а там глядишь уже и до ГЦ недолеко.
WH>Потом захечется код во время исполнения сгенерить... и вот у нас уже появляется System.Reflection.Emit...

Не, GC и Emit у нас не будет. Зачем?

А вот скриптинг будет. Причем в качестве скриптового будет выступать сам основной язык.
Т.к. хидеров нет и информация о типах лежит в модулях, то нет никаких препятствий. Компилим в байткод и запсукаем. Эдакий unsafe скриптинг с указателями, адрессной арифметикой и без GC.

И не надо морочится c написанием разных переходников и оберток.

Разработка будет происходить так: пишем скелет основной програмы, запускаем, в него подгружается scrip-runtime. Далее фичи дописываем интерактивно в скриптовом режиме. после того как фича написана и отлажена, просто добавляем файл к основному проекту и он уже компилируется в native.

Kluev,

K>А вот скриптинг будет. Причем в качестве скриптового будет выступать сам основной язык.
K>Т.к. хидеров нет и информация о типах лежит в модулях, то нет никаких препятствий. Компилим в байткод и запсукаем. Эдакий unsafe скриптинг с указателями, адрессной арифметикой и без GC.

И не надо морочится c написанием разных переходников и оберток.

K>Разработка будет происходить так: пишем скелет основной програмы, запускаем, в него подгружается scrip-runtime. Далее фичи дописываем интерактивно в скриптовом режиме. после того как фича написана и отлажена, просто добавляем файл к основному проекту и он уже компилируется в native.

REPL захотелось? Всё уже украдено до тебя: LISP, Erlang, Smalltalk.

Теоретически такую инкрементальную разработку можно реализовать на JVM и .NET, только в последних 2х случаях народ пошёл (вернее народ повели) по классическому пути.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Kluev,

K>>А вот скриптинг будет. Причем в качестве скриптового будет выступать сам основной язык.
K>>Т.к. хидеров нет и информация о типах лежит в модулях, то нет никаких препятствий. Компилим в байткод и запсукаем. Эдакий unsafe скриптинг с указателями, адрессной арифметикой и без GC.

И не надо морочится c написанием разных переходников и оберток.

K>>Разработка будет происходить так: пишем скелет основной програмы, запускаем, в него подгружается scrip-runtime. Далее фичи дописываем интерактивно в скриптовом режиме. после того как фича написана и отлажена, просто добавляем файл к основному проекту и он уже компилируется в native.

LCR>REPL захотелось? Всё уже украдено до тебя: LISP, Erlang, Smalltalk.

REPL получается на халяву как довесок. Если основные недостатки С++ устранить.

LCR>Теоретически такую инкрементальную разработку можно реализовать на JVM и .NET, только в последних 2х случаях народ пошёл (вернее народ повели) по классическому пути.

Цель не в этом.

Здравствуйте, GlebZ, Вы писали:

GZ>Я тоже уверен в справедливости этой теоремы. Только я также уверен в том, что sql никогда не преобразуется в действительно оптимальный набор команд, поскольку для этого надо решить по крайней мере 2 NP задачи.

Не понял.

GZ>Ты забыл сказать унаследованные от предыдущих языков.

Какая разница что кто у кго унаследовал? В Немереле тоже есть и for и if. Но это не значит, что они обязаны быть жестко вмонтированы в компилятор. Если основа языка полноценна, а язык расширяем, то все это можно реализовать на нем самом. Собственно это я слышу о С++ постоянно, и сообственно именно этого я не вижу. И именно об этом статья.

GZ> А во вторых я имел ввиду что это можно назвать ошибкой языка, а не ошибкой C++-ников.

Иначе ты людей обижаешь на ровном месте.

Под С++-никами в данном случае пордазумеваются разработчкики языка. Возможно я выразился двусмысленно. К пользователям языка это не относится.

GZ>>>ЗЫ. К сожалению, статью полностью прочитать смогу только вечером(сегодня привезут журнальчик). Поэтому это касается только вступления. Слишком уж резануло

VD>>Ну, вот когда прочтешь до конца, то с удовольствием послушаю мнение о статье. А то споры явно уходят в сторону от сути статьи.
GZ>Прочел. Не понравилось. Влад, какого фига ты сравниваешь метапрограммирование с макросами макроассемблера?

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

GZ> Макроассемблер родил С, С родил \С++. Фича оставалось неизменной.

Акстись. Макроассемблер появился сильно позже чем С и его маросы. И речь о макросах С в общем-то не идет. Они упамянаются один раз когда речь идет о изменении синтаксиса, так как это единственная возможность изменить именно синтаксис, а не семантику:

Разные хитрые извороты позволяют изменить семантику имеющегося синтаксиса в этом языке, но вы не в силах изменить сам синтаксис.
Конечно, можно реализовать цикл как-то так:
#define while(condition, body) ля-ля-ля
Но тогда и использовать его придется довольно странно:
int i = 0;

while (i < 100, 
  ...
  i++;
)
Но и тут возникнут проблемы, так как в «ля-ля-ля» вы будете вынуждены забить некоторые имена, которые могут пересечься с имеющимися в контексте использования оператора.

GZ> Но сейчас развитие языка (с помощью библиотек) идет на основании шаблонов.(за некоторыми исключениями).

Прочти еще раз выделенное жирным выше. Шаблоны не могут изменить синтаксис языка! В принципе не могут! Об этом и шала речь. В прочем и define-ы тоже это не делают.

GZ> Твое сравнение не есть корректно. После публикации главы "Расширение синтаксиса" будет нехилый флейм.

Ну, то что флэйм будет я даже не сомневаюсь. Жаль что я не смог уберечься от двусмысленных конструкций. Это конечно вызовет некоторые пролемы. Но думаю, основаня проблема в том, что эта статься по сути своей говорит нелицеприятную правду. Именно этим она заденет многих фанатов. Они будут понимать, что именно Неперловый путь верный, а С++ не идет дальше деклараций благих намерений, но в силу привязанности к любимому языку будут стараться защищать его любой ценой.

Тут ничего не поделашь. Эта статья и не имела намерения переметнуть закареневших С++ в иную "веру". Ее цель воздействие на людей которым по душе красивые фундаментальные решения. Я бы сказал она рассчитана на рамантиков со вкусом.

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