1) Я прагматик. Я не вижу смысла делить язык и технологию. Язык сам по себе ничто и представляет исключительно академический интерес.
2) Я не предлагаю писать БД на ассемблере. Жаль, что мне так и не удалось сказать то, что хотелось. Возможно когда ни будь я попробую это сделать другим постом.
VTune вспомните, Intel C++… Трудно отладить параллельное приложение, построенное даже на старых технологиях. И Parallel Studio собирает инструменты, которые давно учатся решать подобные задачи. Брать что-то вообще новое для реализации параллельности — это отважно. :)
Много было сказано о сборщике мусора, и что его не «умеют готовить». Так ведь дело не в умении, не умении. Дело в том, что сложность большого проекта, не зависит от языка. Именно про это была мысль. Какая разница, писать на Си++ контролируя явно указатели, или настраивать GC, делать клиент-сервер и так далее. Сложности всего этого не отличается на порядок. Основная сложность (и время) в проектировании, алгоритмах, поддержке и далее, далее.
К сожалению, видимо никто так и не понял, что я хотел сказать:
а) Язык не может заменяет работу мозга по решению задачи. И не стоит бездумно вестись на новые новшества. И C# был в качестве примера. Я ведь не критикую C#. Я говорю, что нельзя просто взять и положиться на «авось должно теперь все само».
б) Лучше работать с тем, что давно есть и что активно развивается (привел в качестве примера параллельные технологи, развиваемые Intel). А не брать очередное супер новое, что обещает обеспечить, скажем ту же параллельность. Не верю.
Вы думаете, что писать параллельную программу будет проще с использованием .net 4, чем с использованием скажем TBB, OpenMP и так далее? Будет одинаково! И здесь важнее набор различного инструментария. И как я понимаю, Parallel Studio станет лидером в этом.
Высказал исключительно свое мнение. И совершенно четно, ибо в Intel не работаю. Чем обсуждать всякое новомодное, гораздо разумнее сейчас смотреть на то, что делает и предлагает разработчикам Intel. Просто мало еще кто понимает, что параллельность в программах намного важней, чем например красота языка и прочее.
Нужен и удобен одной группе людей, не означает, что не имеет узкие места для других. Если сравниваться язык с лекарством, то информация на упаковке неверна. Там есть то, что он лечит, но не написаны противопоказания. :) Вот кстати, как сейчас наконец в C# можно стало нормально работать с массивами, состоящими из более чем 2 Gb элементов, или все еще нет? :) blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx
Да, уж. Со слишком большим запасом по времени мы предложили разработчикам Viva64. :) Раз только такие распространенные массовые программы подтягиваются, то специализированные тяжелые системы, на которые мы ориентируемся, даже еще и не в планах. Все кто из подобных покупает — в основном в запас. Ох, дожить бы до светлого будущего… (Не удержался от этого комментария. Хочу 64-битность!).
Вы неправы. Они пошли на это! И создали Itanium с архитектурой IA-64. Выбросили все устаревшее и вообще сделали хорошо. И именно этой архитектуре пророчили будущее и именно по этому не хотели затем признавать x86-64 за полноценного приемника x86.
Вот жаль только что не получилось. Совместимость для разработчиков и пользователей стала уже гораздо дороже всего остального.
2) Я не предлагаю писать БД на ассемблере. Жаль, что мне так и не удалось сказать то, что хотелось. Возможно когда ни будь я попробую это сделать другим постом.
а) Язык не может заменяет работу мозга по решению задачи. И не стоит бездумно вестись на новые новшества. И C# был в качестве примера. Я ведь не критикую C#. Я говорю, что нельзя просто взять и положиться на «авось должно теперь все само».
б) Лучше работать с тем, что давно есть и что активно развивается (привел в качестве примера параллельные технологи, развиваемые Intel). А не брать очередное супер новое, что обещает обеспечить, скажем ту же параллельность. Не верю.
blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx
Вот есть:
void Foo1(int a, int b, int c); void Foo2(int a, int b, int c) { Foo1(a, b, c); // a, b, c - больше не используем . . . }В данном случае в стек переменные не сохраняем, но место резервируем. Зачем? Что это дает?
Вот жаль только что не получилось. Совместимость для разработчиков и пользователей стала уже гораздо дороже всего остального.