Спустя восемь лет

← →
oxffff © (2010-09-07 08:36) [80]

Все вкусности С# вытекают из GC(решение проблемы потерянных ссылок(хотя в Delphi есть reference count), а главное циклических ссылок).

Allen Bauer - в комманде с самого рождения Delphi.

Привожу комментарий [27] из http://blogs.embarcadero.com/abauer/2010/02/16/38916

Allen Bauer
Says от February 19th, 2010 at 1:08 pm
@Warren,

Uh.. everything could reference counted… but the cycles would kill you

I think having a GC would enable whole new programming idioms that would make things more usable. It could also *increase* performance in some scenarios. If we are to attract "new blood", having a GC may help attract some of those fresh-from-college CS guys that learned on managed or dynamic languages more comfortable.

It would also make FreeAndNil moot ;-).

← →
Alkid © (2010-09-07 10:01) [81]

> Дмитрий Белькевич (07.09.10 01:48) [77]
> Я утрировал, конечно :) Но не думаю, что объёмы обработки
> - гигабайты за десяток миллисекунд.

Нет, конечно :) Высоконагруженные системы на .net писать я бы не стал. Но "просто нагруженные" получаются и работают.

> Нет, я не принципиально против C# и .net. Я против такого
> C# и .net, какой получился у MS. Как в том анекдоте про
> милиционера в бане - ты или кобуру сними или трусы одень.
>
> Сделала бы MS нативный C#, или, еще лучше, действительно
> кросс-платформенный дотнет - честь и хвала. А так - творческий
> онанизм и массовая генерация энтропии.

Вот не согласен. Как я понимаю, главная претензия к наличию управляемого кода (MSIL) и виртуальной машины, которая этот код как бы исполняет (на самом деле JIT-компилирует). Вот только сути этой претензии уловить не могу. Управляемый код - это не только средство обеспечения кросс-платформенности но и "2-3 килограмма диетического высокоусвояемого мяса". В смысле, что от него есть много других полезных бенефитов. В итогде .NET в том виде, в котором он есть - это очень хороший инструмент для решения очень широкого класса задач в экосисеме Windows.

← →
Alkid © (2010-09-07 10:06) [82]

> oxffff © (07.09.10 08:36) [80]
> Все вкусности С# вытекают из GC(решение проблемы потерянных
> ссылок(хотя в Delphi есть reference count), а главное циклических
> ссылок).

Не все, хотя большиство :)

← →
brother © (2010-09-07 10:07) [83]

> Управляемый код - это не только средство обеспечения кросс-
> платформенности

> это очень хороший инструмент для решения очень широкого
> класса задач в экосисеме Windows

Это как расценивать?

← →
Alkid © (2010-09-07 10:16) [84]

> brother © (07.09.10 10:07) [83]
> Это как расценивать?

Очень просто - насколько я понял аргумент Дмитрия, он спрашивает: "зачем в .net ввели промежуточный код и ВМ, если реально кроссплатформенности из этого не вышло".

Я отвечаю: промежуточный код и ВМ нужны не только для кроссплатформенности.

← →
Alex Konshin © (2010-09-07 10:22) [85]

Хм, посмотрел Axum. Это похоже будет первый реальный широко используемый язык который основам на принципе DataFlow ( http://en.wikipedia.org/wiki/Dataflow_architecture ).
То есть, такие системы были и есть, но они мало используются. А MS уж точно может пробить его. Причём такой язык давно ожидается потому, что ядер в обычных PC становится всё больше и больше, а писать многопоточные приложения непросто и всё равно никогда не будешь 100% уверен, что нигде нет потенциальных мест для deadlock. Это откроет дорогу для действительно многопроцессорных настольных систем с десятками ядер, и заодно даст ещё один повод для более тесной интеграции с GPU, а в дальнейшем и сращивании его с CPU.

← →
Anatoly Podgoretsky © (2010-09-07 10:22) [86]

> brother (07.09.2010 10:07:23) [83]

Расценивай как И

← →
Styx (2010-09-07 10:26) [87]

Alkid © (07.09.10 10:01) [81]
> В смысле, что от него есть много других полезных бенефитов.

А каих, если не секрет?

← →
Alkid © (2010-09-07 10:40) [88]

> Styx (07.09.10 10:26) [87]
> А каих, если не секрет?

1. Language interoperability,
2. Reflection,
3. Динамическая кодогенерация
4. Верификация кода.
5. Возможность оптимизирующей компиляции в машинный код с использованием особенностей контекста (собранная статистика по путям исполнения, использование особенностей аппаратуры и т.п.)

Это то, что навсидку вспомнил.

← →
oxffff © (2010-09-07 10:59) [89]

> Alkid © (07.09.10 10:40) [88]
>
> > Styx (07.09.10 10:26) [87]
> > А каих, если не секрет?
>
> 1. Language interoperability,
> 2. Reflection,
> 3. Динамическая кодогенерация
> 4. Верификация кода.
> 5. Возможность оптимизирующей компиляции в машинный код
> с использованием особенностей контекста (собранная статистика
> по путям исполнения, использование особенностей аппаратуры
> и т.п.)
>
> Это то, что навсидку вспомнил.

1. Сомнительно. Поскольку все языки становятся очень похожими друг на друга во всяком случае с течением времени. Поскольку на самом деле язык один MSIL. Это больше марпетинг.
2. В Delphi тоже есть RTTI
3. Непонятно как это связано с промежуточным представлением. Никто не мешает даже сейчас генерировать код на Delphi и отдавать его компилятору командой строки. Смысл тот же.
4 Непонятно как это связано с промежуточным представлением. Никто не мешает даже сейчас делать верификация кода на Delphi и отдавать его компилятору командой строки. Смысл тот же.

5. Вот это действительно +.

← →
oxffff © (2010-09-07 11:07) [90]

> 5. Вот это действительно +.

Однако и сейчас никто не мешает делать тоже самое на delphi. Это конечно не JIT, однако аналог ngen.

← →
jack128_ (2010-09-07 11:12) [91]

> поэтому не паримся с рефлекшеном

У используется RTTI для маппинга данных из базы на объекты. Ты просто не в курсе :-)

← →
jack128_ (2010-09-07 11:21) [92]

я се слабо представляю как можно сделать верификацию кода если у тя есть указатели, доступ к нативным либам и тд. Если же дельфи всего этого лишить - то мы получим туже самую песочницу, что .NET.

Да и чисто технически - верификацию нативного кода гораздо тяжелее реализовать, хотя наверно и возможно.

← →
oxffff © (2010-09-07 11:25) [93]

> jack128_ (07.09.10 11:21) [92]
> я се слабо представляю как можно сделать верификацию кода
> если у тя есть указатели, доступ к нативным либам и тд.
> Если же дельфи всего этого лишить - то мы получим туже самую
> песочницу, что .NET.
>
> Да и чисто технически - верификацию нативного кода гораздо
> тяжелее реализовать, хотя наверно и возможно.

Почему есть всякие уровни доверия к коду в .NET.

1.8 Verifiability and correctness
Memory safety is a property that ensures programs running in the same address space are correctly isolated from one another (see Partition I). Thus, it is desirable to test whether programs are memory safe prior to running them. Unfortunately, it is provably impossible to do this with 100% accuracy. Instead, the CLI can test a stronger restriction, called verifiability. Every program that is verified is memory safe, but some programs that are not verifiable are still memory safe.
Correct CIL is CIL that executes on all conforming implementations of the CLI, with well-defined behavior as specified in this standard. However, correct CIL need not result in identical behavior across conforming implementations; that is, the behavior might be implementation-specific.
It is perfectly acceptable to generate correct CIL code that is not verifiable, but which is known to be memory safe by the compiler writer. Thus, correct CIL might not be verifiable, even though the producing compiler might know that it is memory safe. Several important uses of CIL instructions are not verifiable, such as the pointer arithmetic versions of add that are required for the faithful and efficient compilation of C programs. For non-verifiable code, memory safety is the responsibility of the application programmer.
Correct CIL contains a verifiable subset. The Verifiability description gives details of the conditions under which a use of an instruction falls within the verifiable subset of CIL. Verification tracks the types of values in much finer detail than is required for the basic functioning of the CLI, because it is checking that a CIL code sequence respects not only the basic rules of the CLI with respect to the safety of garbage collection, but also the typing rules of the CTS. This helps to guarantee the sound operation of the entire CLI.
The verifiability section of each operation description specifies requirements both for correct CIL generation and for verification. Correct CIL generation always requires guaranteeing that the top items on the stack correspond to the types shown in the stack transition diagram. The verifiability section specifies only requirements for correct CIL generation that are not captured in that diagram. Verification tests both the requirements for correct CIL generation and the specific verification conditions that are described with the instruction. The operation of CIL sequences that do not meet the CIL correctness requirements is unspecified. The operation of CIL sequences that meet the correctness requirements, but which are not verifiable, might violate type safety and hence might violate security or memory access constraints.

← →
Alkid © (2010-09-07 12:28) [94]

> oxffff © (07.09.10 10:59) [89]
> 1. Сомнительно. Поскольку все языки становятся очень похожими
> друг на друга во всяком случае с течением времени. Поскольку
> на самом деле язык один MSIL. Это больше марпетинг.

"Похожие друг на друга" там C# и VB.
F# и C# уже очень не похожи друг на друга.
А есть еще ряд маргинальных языков, например имплементация моего любимого пролога.
Он похож на C#? :)

> 2. В Delphi тоже есть RTTI

RTTI имеющийся в Delphi 7 (самая новая версия с которой я знаком) серьезно проигрывает по возможностям.
К сожалению, я не в курсе дальнейших продвижений в этой области у Delphi.
Наверное ты прав в том смысле, что Refelction и промежуточный язык ортогональные фитчи, а убогость его реализации в unmanaged языках (оговорюсь - известных мне) - это всего лишь совпадение.

> 3. Непонятно как это связано с промежуточным представлением.
> Никто не мешает даже сейчас генерировать код на Delphi
> и отдавать его компилятору командой строки. Смысл тот же.

Смысл тот же, но имплементация на совершенно разном уровне.
Какие есть типовые решения (фреймворки) для дельфи, реализующие DI и аспекты без необходимости писать руками обертки? Я не знаю пока таких, хотя теоретически их можно сделать. Компилятор командной строки есть же :)

> 4 Непонятно как это связано с промежуточным представлением.
> Никто не мешает даже сейчас делать верификация кода на
> Delphi и отдавать его компилятору командой строки. Смысл
> тот же.

Чем более высокоуровневый код, тем его проще верифицировать. MSIL проще верифицировать, чем машинные коды.
Анализ исходных текстов тут не в тему, ибо речь о run-time.

← →
oxffff © (2010-09-07 12:39) [95]

> Alkid © (07.09.10 12:28) [94]
>
> > oxffff © (07.09.10 10:59) [89]
> > 1. Сомнительно. Поскольку все языки становятся очень похожими
>
> > друг на друга во всяком случае с течением времени. Поскольку
>
> > на самом деле язык один MSIL. Это больше марпетинг.
>
> "Похожие друг на друга" там C# и VB.
> F# и C# уже очень не похожи друг на друга.
> А есть еще ряд маргинальных языков, например имплементация
> моего любимого пролога.
> Он похож на C#? :)

Еще не вечер. Одиночное наследование, замыкания, bounded полиморфизм, рефлексия - это все ноги и ограничения MSIL.
Тем не менее функциональные языки реализуются на ООП ВМ со сборкой мусора. Мать то одна.

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

> > 2. В Delphi тоже есть RTTI
>
> RTTI имеющийся в Delphi 7 (самая новая версия с которой
> я знаком) серьезно проигрывает по возможностям.
> К сожалению, я не в курсе дальнейших продвижений в этой
> области у Delphi.
> Наверное ты прав в том смысле, что Refelction и промежуточный
> язык ортогональные фитчи, а убогость его реализации в unmanaged
> языках (оговорюсь - известных мне) - это всего лишь совпадение.
>

Следуют посмотреть для развития кругозора.

> Чем более высокоуровневый код, тем его проще верифицировать.
> MSIL проще верифицировать, чем машинные коды.
> Анализ исходных текстов тут не в тему, ибо речь о run-time.
>

Верифицировать будешь исходный код на delphi в run time, а не машинные коды.

← →
Игорь Шевченко © (2010-09-07 13:10) [96]

за одно то, что не надо делать .Free уже надо памятник ставить. А местные пикейные жилеты все про Бриана

← →
Alkid © (2010-09-07 13:36) [97]

> oxffff © (07.09.10 12:39) [95]
> Еще не вечер. Одиночное наследование, замыкания, bounded
> полиморфизм, рефлексия - это все ноги и ограничения MSIL.

Хм. А вот есть язык Eiifel, который имеет реализацию под .net.
И ничего, реализуют множественное наследование.
Может эти "ограничения MSIL" не такие уж и ограничения?

> Тем не менее функциональные языки реализуются на ООП ВМ
> со сборкой мусора. Мать то одна.
>
> А почему ты не упомянул именно о способе их взаимодействия?
>
> Ведь во всех них есть некие аналоги сборки, класса, метода,
> свойства. Они по другому не смогут взаимодействовать. Так
> что все приведется к общему знаменателю - MSIL.

Это заблуждение.
Говорить, что все .net языки должны быть похожи друг на друга, потому что "приводятся к единому знаменателю MSIL", это все равно, что утверждать, что все нативные языки должны быть похожи, ибо приводятся к "единому знаменателю машинных кодов". Во всех ведь есть бинарные модули, сегменты, указатели, подпрограмы...

> Верифицировать будешь исходный код на delphi в run time,
> а не машинные коды.

Это уже изменение условия задачи :) Если ты собираешься тащить в run-time исходники, то стоит задуматься над тем, надо ли тебе вообще иметь дело с такими языками, как Delphi, C#, C++. Логичнее будет выглядеть какой-нибудь питон или лисп.

← →
Anatoly Podgoretsky © (2010-09-07 13:44) [98]

> Alkid (07.09.2010 13:36:37) [97]

> все нативные языки должны быть похожи, ибо приводятся к "единому
> знаменателю машинных кодов".

Приводятся к Английскому с американским акцентом.

← →
Anatoly Podgoretsky © (2010-09-07 13:46) [99]

> Alkid (07.09.2010 13:36:37) [97]

Чем тебе не нравится C# в ASP.NET это один из основных языков, работает на
основе исходников, прозначно и незаметно. Очень удобно.

← →
oxffff © (2010-09-07 14:31) [100]

> Alkid © (07.09.10 13:36) [97]
>
> > oxffff © (07.09.10 12:39) [95]
> > Еще не вечер. Одиночное наследование, замыкания, bounded
>
> > полиморфизм, рефлексия - это все ноги и ограничения MSIL.
>
>
> Хм. А вот есть язык Eiifel, который имеет реализацию под
> .net.
> И ничего, реализуют множественное наследование.
> Может эти "ограничения MSIL" не такие уж и ограничения?

Может все же прочитать как это сделано? И что это ненастоящее множественное наследование, а просто делегация.

Multiple Inheritance
Multiple inheritance was, as noted, recognized from the start as a key implementation issue. The reader may indeed wonder how we can provide multiple inheritance on a platform that doesn"t support it, especially with the requirement stated above that other languages should see the Eiffel multiple inheritance structure.

The solution used relies on the ability of a .NET Framework class to inherit multiply from interfaces—completely abstract classes without any implementation at all. In the generated code, the compiler shadows every class with interface.

http://msdn.microsoft.com/en-us/library/ms973898.aspx

> > Тем не менее функциональные языки реализуются на ООП ВМ
>
> > со сборкой мусора. Мать то одна.
> >
> > А почему ты не упомянул именно о способе их взаимодействия?
>
> >
> > Ведь во всех них есть некие аналоги сборки, класса, метода,
>
> > свойства. Они по другому не смогут взаимодействовать.
> Так
> > что все приведется к общему знаменателю - MSIL.
>
> Это заблуждение.
> Говорить, что все .net языки должны быть похожи друг на
> друга, потому что "приводятся к единому знаменателю MSIL",
> это все равно, что утверждать, что все нативные языки должны
> быть похожи, ибо приводятся к "единому знаменателю машинных
> кодов". Во всех ведь есть бинарные модули, сегменты, указатели,
> подпрограмы...

Вот только не стоит подменять понятия. В таком случае можно абсолютно про все языки существуеющие сказать что они Language interoperability.
Под Language interoperability как и подразумевается их взаимодействие через единый понятный .NET языкам механизм (сборки->классы->методы).

> > Верифицировать будешь исходный код на delphi в run time,
>
> > а не машинные коды.
>
> Это уже изменение условия задачи :) Если ты собираешься
> тащить в run-time исходники, то стоит задуматься над тем,
> надо ли тебе вообще иметь дело с такими языками, как Delphi,
> C#, C++. Логичнее будет выглядеть какой-нибудь питон или
> лисп.

Отчего же?
.NET языки же тащат промежуточное представление в виде байкода и таблиц метаданных в exe. То есть тащат исходники.
Почему же нельзя тащить Delphi код?

← →
Alkid © (2010-09-07 14:47) [101]

> oxffff © (07.09.10 14:31) [100]
> Может все же прочитать как это сделано? И что это ненастоящее
> множественное наследование, а просто делегация.

В нативных языках в конечном итоге все тоже выливается совсем не в ООП с наследованием :)

> Вот только не стоит подменять понятия. В таком случае можно
> абсолютно про все языки существуеющие сказать что они Language
> interoperability.
> Под Language interoperability как и подразумевается их взаимодействие
> через единый понятный .NET языкам механизм (сборки->классы-
> >методы).

Да кто же их подменяет? :)
Да, в нативном мире тоже есть свой Language Interoperability: ABI, COM.
Просто там это дается с бОльшим геморроем.
Примерно так же, как и с кодогенерацией - в нативном мире тебе тоже никто не запрещает ни кодогенерироваться, ни интероперироваться. Просто уровень реализации разный

> Отчего же?
> .NET языки же тащат промежуточное представление в виде байкода
> и таблиц метаданных в exe. То есть тащат исходники.

Вот это и есть самая натуральная подмена понятий :)
MSIL не есть исходники.
Или даже так, если MSIL считать исходниками, то машинный код тоже получается исходники.
Тогда смысл разделения понятий "исходный код" и "скомпилированный код" совсем теряется :)

← →
oxffff © (2010-09-07 15:45) [102]

> Alkid © (07.09.10 14:47) [101]
>
> > oxffff © (07.09.10 14:31) [100]
> > Может все же прочитать как это сделано? И что это ненастоящее
>
> > множественное наследование, а просто делегация.
>
> В нативных языках в конечном итоге все тоже выливается совсем
> не в ООП с наследованием :)

Видимо есть некоторые особенности раз такого не сделали для managed С++.

> Да кто же их подменяет? :)
> Да, в нативном мире тоже есть свой Language Interoperability:
> ABI, COM.
> Просто там это дается с бОльшим геморроем.
> Примерно так же, как и с кодогенерацией - в нативном мире
> тебе тоже никто не запрещает ни кодогенерироваться, ни интероперироваться.
> Просто уровень реализации разный

Я просто сколько читал описание .NET различных языков везде в том или ином виде присутствуют ссылки на сборки и классы в качестве Language Interoperability.

> Вот это и есть самая натуральная подмена понятий :)
> MSIL не есть исходники.
> Или даже так, если MSIL считать исходниками, то машинный
> код тоже получается исходники.
> Тогда смысл разделения понятий "исходный код" и "скомпилированный
> код" совсем теряется :)

Машинный код не является исходниками. Поскольку например из него нельзя получить информацию о типах данных. Байт код является аналогом семантического дерева из которого можно получить например информацию о типах данных.
Если представить шаги, то все очень просто

C#->MSIL+Metadata->x86
Delphi->Delphi.dcu->x86

← →
oxffff © (2010-09-07 15:56) [103]

> C#->MSIL+Metadata->x86
> Delphi->Delphi.dcu->x86

Однако Delphi->Delphi.dcu не является аналогом C#->MSIL+Metadata, а является аналогом C#->MSIL+Metadata->x86.
Поэтому в некотором смысле шага C#->MSIL+Metadata нет, то есть это просто другая запись того же самого.

← →
Игорь Шевченко © (2010-09-07 16:16) [104]

> Машинный код не является исходниками. Поскольку например
> из него нельзя получить информацию о типах данных

Странные у тебя критерии исходников

← →
oxffff © (2010-09-07 16:24) [105]

> Игорь Шевченко © (07.09.10 16:16) [104]
>
> > Машинный код не является исходниками. Поскольку например
>
> > из него нельзя получить информацию о типах данных
>
>
> Странные у тебя критерии исходников

Почему очень даже не странные.

Вот аналоги на разных языках

Delphi
var a,b:integer;
begin
a:=b;

C#
Int32 a,b;
a=b;

MSIL
.locals init(int32 a,int32 b)
ldloc b
stloc a

Однако mov eax,ebx не является их аналогом. Здесь речь идет об исходниках которые необходимо type check и verify.

← →
Alkid © (2010-09-07 16:30) [106]

> oxffff © (07.09.10 15:45) [102]
> Видимо есть некоторые особенности раз такого не сделали
> для managed С++.

Я полагаю, что особенность простая - нижележащая система не имеет понятия о множественном наследовании. Следовательно, отображения "один к одному" на её понятия не получится. Следовательно, надо думать и исследовать, как множественное наследование реализовывать в экосистеме CLR.
В нативном коде все то же самое - никакой ООП и, тем более, множественное наследование не отображаются прямо на понятия машинного кода.

> Я просто сколько читал описание .NET различных языков везде
> в том или ином виде присутствуют ссылки на сборки и классы
> в качестве Language Interoperability.

Ну и что? А вот под Windows, например, все языки каким-то удивительным образом производят восновном либо exe, либо dll модули. И для интеропа стабильно используют два механизма - либо ABI, либо COM.
Но это ничего не говорит о похожести самих языков. Среди них есть и логические, и процедурные, и ООП и функциональные и так далее.

> Машинный код не является исходниками. Поскольку например
> из него нельзя получить информацию о типах данных. Байт
> код является аналогом семантического дерева из которого
> можно получить например информацию о типах данных.
> Если представить шаги, то все очень просто
>
> C#->MSIL+Metadata->x86
> Delphi->Delphi.dcu->x86

Хм. Всегда думал, что исходники - это по определению то, из чего исходят. То есть то, что пишет программист.
Дай свое определение исходников.

← →
Игорь Шевченко © (2010-09-07 17:30) [107]

> Однако mov eax,ebx не является их аналогом

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

← →
Дмитрий Белькевич (2010-09-07 19:43) [108]

> за одно то, что не надо делать .Free уже надо памятник ставить.
> А местные пикейные жилеты все про Бриана

Интересно, кстати, менеджер памяти с GC на Делфи принципиально невозможен?

> Дмитрий Белькевич (07.09.10 19:43) [108]
>
> Интересно, кстати, менеджер памяти с GC на Делфи принципиально
> невозможен?

http://codecentral.embarcadero.com/Item/21646

Правда, использовать не пробовал.

> Дмитрий Белькевич (07.09.10 19:43) [108]
> Интересно, кстати, менеджер памяти с GC на Делфи принципиально
> невозможен?

Принципиально возможен, но сборщик мусора в любом языке, в котором есть прямой доступ к памяти и арифметика указателей реализовать проблематично (хотя и возможно) и он будет обладать определенными ограничениями. В прошлой моей конторе пытались реализовать и внедрить свой GC, работающей на дикой смеси подсчета ссылок и mark"n"sweep. Идея с треском рухнула, вобрав в себя кучу человеко-лет и нервов программистов.

Забыл добавить - там писали на С++.

> Alkid © (07.09.10 16:30) [106]
>
> > oxffff © (07.09.10 15:45) [102]
> > Видимо есть некоторые особенности раз такого не сделали
>
> > для managed С++.
>
> Я полагаю, что особенность простая - нижележащая система
> не имеет понятия о множественном наследовании. Следовательно,
> отображения "один к одному" на её понятия не получится.
> Следовательно, надо думать и исследовать, как множественное
> наследование реализовывать в экосистеме CLR.
> В нативном коде все то же самое - никакой ООП и, тем более,
> множественное наследование не отображаются прямо на понятия
> машинного кода.

То есть таким образом ты признаешь, что все .NET языки в каком то смысле подобны, то есть есть костяк за рамки которого они не могут выйти?
И вопрос только во времени, когда все они станут идентичны по механизмам, но различны по синтаксису.

> > Я просто сколько читал описание .NET различных языков
> везде
> > в том или ином виде присутствуют ссылки на сборки и классы
>
> > в качестве Language Interoperability.
>
> Ну и что? А вот под Windows, например, все языки каким-то
> удивительным образом производят восновном либо exe, либо
> dll модули. И для интеропа стабильно используют два механизма
> - либо ABI, либо COM.
> Но это ничего не говорит о похожести самих языков. Среди
> них есть и логические, и процедурные, и ООП и функциональные
> и так далее.

Хорошо сейчас я дома. И могу наконец могу достать из шкафа ... молоток. :)
Рихтера.
Дословно Language Interoperability

.NET обеспечивает интеграцию разных языков, то есть один язык может использовать типы, созданные на других языках. Например, CLR позволяет создать на С++ класс, производный от класса, реализованного на VB. В CLR это возможно из-за наличия общей системы типов (CLS), которую должны использовать все языки, ориентированные на CLR. А поскольку опять же сборки, классы, методы являются основой CLR, то все языки должны в том или ином виде реализовывать такие понятия(примитивы).

>
> Хм. Всегда думал, что исходники - это по определению то,
> из чего исходят. То есть то, что пишет программист.
> Дай свое определение исходников.

Исходники тут не причем. Разговор изначально зашел о том, для верификации в run time нужен промежуточный язык. А я стараюсь тебе показать, что это совсем необязательно.

> Игорь Шевченко © (07.09.10 17:30) [107]
>
> > Однако mov eax,ebx не является их аналогом
>
>
> однако будучи записано строкой является исходником.
> Давай ты если вводишь какие-то свои, отличные от общеупотребительных,
> понятия, ты их заранее будешь декларировать

И?

> oxffff © (07.09.10 21:16) [112]
> То есть таким образом ты признаешь, что все .NET языки в
> каком то смысле подобны, то есть есть костяк за рамки которого
> они не могут выйти?
> И вопрос только во времени, когда все они станут идентичны
> по механизмам, но различны по синтаксису.

Опять 25.
Ну почему они должны стать идентичными по механизмам?
Нативные языки должны в перспективе обрести такую же идентичность?
Если нет, то объясни мне качественную разницу между нативными платформами и .net.
Причем такую, которая объясняла бы, почему на нативе может быть дивергенция, а в .net мы должны конвергировать к какому-то семантически единому языку.
И приведи мне примеры этой конвергенции.
Пока я вижу только параллельную эволюцию C# и VB, которая осуществляется как сознательная политика MS.
Хейлсберг об этом явно заявил.
Так же я вижу дивергенцию - .net имеет ООП природу, но на нем уже реализованы языки всех основных парадигм (процедурной, ООП, функциональной, логической), причем в разных "вкусах" (разные системы типизации, разный уровень динамичности и т.п.). Причем разнообразие реализованных языков лишь растет со временем.

> Хорошо сейчас я дома. И могу наконец могу достать из шкафа
> ... молоток. :)
> Рихтера.
> Дословно Language Interoperability
>
> .NET обеспечивает интеграцию разных языков, то есть один
> язык может использовать типы, созданные на других языках.
> Например, CLR позволяет создать на С++ класс, производный
> от класса, реализованного на VB. В CLR это возможно из-за
> наличия общей системы типов (CLS), которую должны использовать
> все языки, ориентированные на CLR. А поскольку опять же
> сборки, классы, методы являются основой CLR, то все языки
> должны в том или ином виде реализовывать такие понятия(примитивы).

Они должны их реализовывать, но:
1. Эти концепции могут быть лишь деталью реализации яызка на .NET и не проявляться в самом языке.
2. Эти концепции не ограничивают концептуальное богатство языка.

Все нативные программы, работающие на платформе Wintel так же должны в себе как-то реализовывать такие концепции, как модули (PE-модули), должны "знать" о регистрах, об LPC и т.п.

Вот примитивная программа на С:
int main() { return 0; }
Где все, что я перечислил?

А вот код на F#
// подключаем лайт-синтаксис #light // C# : using System; open System // скажем миру привет printfn "Hello, World! What is your name, user?" // а как нас зовут? C# : var name = Console.ReadLine(); let name = Console.ReadLine() // определим функцию, которая будет говорить "привет" аргументу who. // приблизительный аналог на C#: // public delegate void SaySomethingDelegate(string toWho); // SaySomethingDelegate sayHello = who => Console.WriteLine("Hello, {0}!", who); let sayHello who = printfn "Hello, %s!" who // привет, Хабрахабр! sayHello name // а в функциях можно использовать и стандартные методы .Net Framework: let sayHelloDotNet who = Console.WriteLine("Hello from F# via .Net, " + name + "!") // и опять привет! sayHelloDotNet name // в качестве бонуса посчитаем числа Фибоначчи :) let rec fib i = // рекурсивная функция от одного аргумента match i with // которая смотрит на что похож этот аргумент | 1 | 2 -> 1 // если он 1 или 2, то возвращаем 1 | i -> fib(i-1) + fib(i-2) // если он похож только на себя - то рекурсивно вызываем эту же функцию // смотрим, что у нас получилось printfn "%i" (fib 20)
Сколько классов мы тут объявили?

> Исходники тут не причем. Разговор изначально зашел о том,
> для верификации в run time нужен промежуточный язык. А
> я стараюсь тебе показать, что это совсем необязательно.

Это не обязательно.
Промежуточный код это лишь одна из возможных стратегий.

> Alkid (07.09.2010 21:36:54) [114]

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

> Anatoly Podgoretsky © (07.09.10 21:47) [115]
> Промежуточный язык, в не код, был разработан не для верификации,
> а для
> кроссплатформенности. Промежуточный язык он общий для всех
> платформ, затем
> он компилируется в нативный код для платформы и независим
> от процессора и
> его разрядности,

Это не единственная польза и мотивация от введения IL.

> Alkid (07.09.2010 22:00:56) [116]

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

Ну MS на кроссплатформенность плевать. Им это не нужно по большому счету.

Промежуточный код нужен для взаимодействия между сборками написанными на различных NET совместимых языках.

> Alkid © (07.09.10 21:36) [114]
>
> > oxffff © (07.09.10 21:16) [112]
> > То есть таким образом ты признаешь, что все .NET языки
> в
> > каком то смысле подобны, то есть есть костяк за рамки
> которого
> > они не могут выйти?
> > И вопрос только во времени, когда все они станут идентичны
>
> > по механизмам, но различны по синтаксису.
>
> Опять 25.
> Ну почему они должны стать идентичными по механизмам?
> Нативные языки должны в перспективе обрести такую же идентичность?
>
> Если нет, то объясни мне качественную разницу между нативными
> платформами и .net.
> Причем такую, которая объясняла бы, почему на нативе может
> быть дивергенция, а в .net мы должны конвергировать к какому-
> то семантически единому языку.
> И приведи мне примеры этой конвергенции.
> Пока я вижу только параллельную эволюцию C# и VB, которая
> осуществляется как сознательная политика MS.
> Хейлсберг об этом явно заявил.
> Так же я вижу дивергенцию - .net имеет ООП природу, но на
> нем уже реализованы языки всех основных парадигм (процедурной,
> ООП, функциональной, логической), причем в разных "вкусах"
> (разные системы типизации, разный уровень динамичности и
> т.п.). Причем разнообразие реализованных языков лишь растет
> со временем.

По мне так растет лишь разнообразие синтаксиса, а механизмы становятся идентичными.

Фундамент CLR
статическая типизация, ООП, делагаты, F-bounded полиморфизм, сборка мусора.

C#, Oxygene, VB#, Pascal.ABC, F#, Nemerle, Eiifel ...
Напоминает лозунг: А у вас уже есть LINQ? Лямбды? Замыкания? Функции высших порядков? ...
плюшки одних языков пошли в другие.

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

> > Хорошо сейчас я дома. И могу наконец могу достать из шкафа
>
> > ... молоток. :)
> > Рихтера.
> > Дословно Language Interoperability
> >
> > .NET обеспечивает интеграцию разных языков, то есть один
>
> > язык может использовать типы, созданные на других языках.
>
> > Например, CLR позволяет создать на С++ класс, производный
>
> > от класса, реализованного на VB. В CLR это возможно из-
> за
> > наличия общей системы типов (CLS), которую должны использовать
>
> > все языки, ориентированные на CLR. А поскольку опять же
>
> > сборки, классы, методы являются основой CLR, то все языки
>
> > должны в том или ином виде реализовывать такие понятия(примитивы).
>
>
> Они должны их реализовывать, но:
> 1. Эти концепции могут быть лишь деталью реализации яызка
> на .NET и не проявляться в самом языке.
> 2. Эти концепции не ограничивают концептуальное богатство
> языка.
>
> Все нативные программы, работающие на платформе Wintel так
> же должны в себе как-то реализовывать такие концепции, как
> модули (PE-модули), должны "знать" о регистрах, об LPC и
> т.п.
>
> Вот примитивная программа на С:
>
> int main()
> {
> return 0;
> }
>
> Где все, что я перечислил?

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

> А вот код на F#
>
> // подключаем лайт-синтаксис
> #light
> // C# : using System;
> open System
> // скажем миру привет
> printfn "Hello, World! What is your name, user?"
> // а как нас зовут? C# : var name = Console.ReadLine();
> let name = Console.ReadLine()
> // определим функцию, которая будет говорить "привет" аргументу
> who.
> // приблизительный аналог на C#:
> // public delegate void SaySomethingDelegate(string toWho);
>
> // SaySomethingDelegate sayHello = who => Console.WriteLine("Hello,
> {0}!", who);
> let sayHello who = printfn "Hello, %s!" who
> // привет, Хабрахабр!
> sayHello name
> // а в функциях можно использовать и стандартные методы
> .Net Framework:
> let sayHelloDotNet who = Console.WriteLine("Hello from F#
> via .Net, " + name + "!")
> // и опять привет!
> sayHelloDotNet name
> // в качестве бонуса посчитаем числа Фибоначчи :)
> let rec fib i = // рекурсивная функция от одного
> аргумента
> match i with // которая смотрит на что похож этот
> аргумент
> | 1 | 2 -> 1 // если он 1 или 2, то возвращаем 1
> | i -> fib(i-1) + fib(i-2) // если он похож только на себя
> - то рекурсивно вызываем эту же функцию
>
> // смотрим, что у нас получилось
> printfn "%i" (fib 20)
>
> Сколько классов мы тут объявили?

В твоем коде

> .Net Framework:
> let sayHelloDotNet who = Console.WriteLine("Hello from F#
> via .Net, " + name + "!")

Это что? Матчинг? Сим-салябин редукция?

> > Исходники тут не причем. Разговор изначально зашел о том,
>
> > для верификации в run time нужен промежуточный язык.
> А
> > я стараюсь тебе показать, что это совсем необязательно.
>
>
> Это не обязательно.
> Промежуточный код это лишь одна из возможных стратегий.

Напоминаю.В [88] ты утверждаешь, что именно наличие виртуальной машины и байткода позволяет достичь run-time верификации. Я тебе привел пример, что использование кода на delphi или например использование некоторого промежуточного представления в dcu(как это например делается для generics) и отдача этого в run-time компилятору командной строки позволит достичь той же цели.

> DVM (07.09.2010 22:24:58) [118]

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

Спустя восемь лет Найти похожие ветки