.Net

не дочитал еще, но уже начали глодать смутные сомнения:

1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?

2. Везде в тексте указания, что нужно активно плыть в сторону оптимизации, сам компилятор мышей не ловит. Вплоть до того, что рекомендуется строить леса перегруженных методов.

В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?

Вопрос не в плане аксапты, а в плане чистого .Net.

Хотя и в плане аксапты можно прокомментить.

[_scorp_]

Цитата:

Сообщение от otkudao

1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?

Если Вы будете вести расчет какого-нибудь атомного реактора, и найдется "managed" язык более выразительный или удобный для ведения таких расчетов, чем C#, то почему бы этим языком не пользоваться. Тогда как GUI писать на C#.

Цитата:

Сообщение от otkudao

2. Везде в тексте указания, что нужно активно плыть в сторону оптимизации, сам компилятор мышей не ловит. Вплоть до того, что рекомендуется строить леса перегруженных методов.

В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?

Про тормознутость разработки не понял, что имеется ввиду. А про исполнение...Что-то Вы не то читаете, начните с Рихтера которого Вам тут уже неоднократно советовали. Вот что он пишет про "тормознутость" :

Цитата:

Разработчики с опытом программирования на неуправляемых C/C++ наверняка
заинтересуются, как это сказывается на производительности. В конце концов,
неуправляемый код компилируется для конкретного процессора и при вызове
просто исполняется. В управляемой же среде компиляция производится в два этапа.
Сначала компилятор проходит исходный код и переводит его в IL. Но для испол
нения сам ILкод нужно перевести в машинные команды в период выполнения,
что требует дополнительной памяти и процессорного времени.
Поверьте: я сам из тех, кто программирует на C/C++, и, переходя на CLR, я до
статочно скептически рассматривал все эти дополнительные издержки. Вторая
стадия компиляции, имеющая место в период выполнения, снижает скорость и
требует дополнительной динамической памяти — с этим не поспоришь. Однако
Microsoft проделала большую работу, чтобы свести эти издержки к минимуму
Трудно поверить, но многие (включая меня) считают, что управляемые при
ложения могут работать производительнее неуправляемых, и тому есть масса
причин. Взять хотя бы тот факт, что превращая ILкод в команды процессора в
период выполнения, JITкомпилятор располагает более полными сведениями о
среде выполнения, чем компилятор неуправляемого кода. Вот особенности, ко
торые позволяют управляемому коду «опередить» неуправляемый.
 JITкомпилятор может обнаружить факт выполнения приложения на Pentium 4
и сгенерировать машинный код, полностью использующий все преимущества
особых команд этого процессора. Неуправляемые приложения обычно ком
пилируют в расчете на среднестатистический процессор, избегая специ
фических команд, которые заметно повышают производительность приложе
ния на новейших процессорах.
 JITкомпилятор может обнаружить, что определенное выражение на конкрет
ной машине всегда равно false. Например, посмотрим на метод с таким кодом:
if (numberOfCPUs > 1) {
...
}
Здесь numberOfCPUs — число процессоров. Код указывает JITкомпилято
ру, что для машины с одним процессором не нужно генерировать никаких
машинных команд. В этом случае машинный код оптимизирован для конкрет
ной машины: он короче и выполняется быстрее.
 CLR может проанализировать выполнение кода и перекомпилировать ILкод в
команды процессора во время выполнения приложения. Перекомпилирован
ный код может реорганизовываться с учетом обнаруженных некорректных
прогнозов ветвления.
Это лишь малая часть аргументов в пользу того, что управляемый код будуще
го будет исполняться лучше сегодняшнего неуправляемого. Как я сказал, произ
водительность и сейчас очень неплохая для большинства приложений, а со вре
менем ситуация только улучшится.
Если ваши эксперименты покажут, что JITкомпилятор CLR не обеспечивает
нужную производительность, рекомендую воспользоваться утилитой NGen.exe,
поставляемой с .NET Framework SDK. NGen.exe компилирует весь ILкод выбран
ной сборки в машинный и сохраняет его в дисковом файле. При загрузке сборки
в период выполнения среда CLR автоматически проверяет наличие предварительно
скомпилированной версии сборки и, если она есть, загружает скомпилированный
код, так что компиляция в период выполнения не производится. Заметьте, что
NGen.exe не ориентируется на конкретную среду выполнения и генерирует код
для среднестатистической машины; по этой причине созданный утилитой код не
столь оптимизирован, как произведенный JITкомпилятором.

[belugin]

Цитата:

Сообщение от otkudao

1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?

Я встречал жизнеспособные варианты:

1.С++/Cli - есть специальный диалект С++, который является одновременно Managed языком - можно использовать наработанные библиотеки X++, а в результате получаются .NET классы. Я когда-то писал плагин для фара по такой схеме (сейчас другие люди рзрабатывают).

2. PowerShell - на шелле удобно работать с файлами, блгодаря шелльному синтаксису. При этом можно использовать весь .NET фреймворк.Иногда даже в шелльные скрипты вставляют кусочки на C# при помощи Add-Type

3. Вообще когда удобно работать на другом языке билиотеки в-основном есть на C#. Многие предпочитают VB.NET из-за опыта в бейские, есть F#, который содержит паттерн матчинг и контроль едини измерения

Цитата:

2. Везде в тексте указания, что нужно активно плыть в сторону оптимизации, сам компилятор мышей не ловит. Вплоть до того, что рекомендуется строить леса перегруженных методов.

В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?

Вопрос не в плане аксапты, а в плане чистого .Net.

Смотря для чего.

Цитата:

Хотя и в плане аксапты можно прокомментить.

.NET с нормальным GC и JIT гораздо быстрее чем X++. Еще есть богатый фреймфорк, который удобно использовать, если надо чего-то особенного.

[Diman]

Цитата:

Сообщение от otkudao

не дочитал еще, но уже начали глодать смутные сомнения:

1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?

Совместное использование разных ЯП, которые могут генерить один IL как раз и позиционируется как одно из основных преимуществ .Net
Если проект большой, то за разные компоненты отвечают разные команды, или даже компании, соответственно и языки могут быть разными.

Цитата:

Сообщение от otkudao

2. Везде в тексте указания, что нужно активно плыть в сторону оптимизации, сам компилятор мышей не ловит. Вплоть до того, что рекомендуется строить леса перегруженных методов

В сторону оптимизации нужно плыть всегда, компилятор только сможет скомпилировать IL под конкретный процессор, собственно и вся оптимизация, здеcь компиляторы, которые генерят native код в общем случае проигрывают JIT компиляции.
Про леса методов наверно лучше почитать книжку "банды четырех".

Цитата:

Сообщение от otkudao

В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?

Вопрос не в плане аксапты, а в плане чистого .Net.

Хотя и в плане аксапты можно прокомментить.

В аксапте нет оптимизации P-кода как в .Net, здесь IL выигрывает всегда. По поводу скорости разработки - представьте, что вам необходимо сделать приложение, под несколько платформ. Пришлось бы под каждую платформу писать спицифические для нее куски кода. Приходилось иметь дело с кодом на С++, где надо было писать ассемблерные вставки под конкретные процессоры и OS. Соответственно весь этот зоопарк придется поддерживать. А генерация промежуточного IL в общем случае избавляет от этих забот.
Выше упоминался GC, так вот в неправильно спроектированной софтине эта самая недетерминированность как раз и становится узким местом. Когда надо пройтись по графу ссылок и освободить память из поколения 2 например, а объект в это время лежит в файле на диске. Поэтому даже при наличии GC следить за памятью и ее очисткой все-таки придется. Да и еще, при освобождении памяти GC производит дефрагментацию памяти. В большинстве случаев это также ускоряет выделение памяти под новые объекты. Еще есть плюс в том, что алгоритм GC умеет определяеть размер памяти выделяемый под поколения в момент исполнения, что тоже увеличивает производительность.

ИМХО начинать изучать .Net с Рихтера тяжеловато.