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

ХД>>Я не вижу здесь снижения квалификации
A>Ну может не особо и не всегда проявляется, но есть... Человек, знакомый с архитектурой проца знает, что имеенно из этих двух например работает быстрее (точнее, раньшне работало быстрее, но не в этом суть):

Эти вещи уже давно обрабатываются оптимизаторами компиляторов, которые были созданы именно для того, чтобы специалист по конструированию прогрограммной системы не парился по поводу того, как там работает его процессор и как записать цикл — спереди назад или задом наперёд, а занимался своим делом! Такова же роль и дотнета — дать возможность заниматься своим делом.

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

ХД>>На работе проект на C++ (Builder), дома, в аспирантуре, проект на C# (VS 2003).
MS>Только не говори мне, что ты это интегрируешь

Нет, не интегрирую. Думаю, что то, что я сейчас пишу на С++ потом будут переписывать на С#

ХД>>Фреймворк помогает хотя бы в плане управления памятью. Помогает большой хорошо документированной библиотекой.
MS>Да, управление памятью — это большой плюс. Только вряд ли это уж очень повышает уровень абстракции, не так ли Насчет документации тоже согласен. Microsoft поставило на .NET, поэтому старая документация не обновлялась. Но опять же, чем это повышает уровень абстракции?

Про уровни абстракции я не говорил. Я говорил о том, что теперь я решаю задачи по-другому, не задумывась о вопросах, которые раньше доставляли (и доставляют мне лично сейчас в С++) головную боль. И в библиотеке меня привлекает не сама по себе документация, а обширность, логичная (с моей точки зрения) структурированность и уже потом документированность.

ХД>>Коллекции не пишу, не вспоминаю второй курс института, а выбираю из тех что уже есть. Пока что выбор больше моих требований
MS>Вот я тебя и поймал. В С++ есть коллекции, примем такие, что в .NET 2.0 они появились, реализованные ориентированное на STL. Мне вот лично хватает таких коллекций: ArrayList (C++ — vector, .NET 2.0 — List<>), Hashtable — (С++ — map, .NET 2.0 — Dictionary<,>).

Я за тебя рад

ХД>>Надеюсь со вторым фреймворком получить прирост производительности и читабельности благодаря дженерикам.
MS>Шаблоны (и generics) на самом деле только затрудняют чтение. Сравни (код поскипан)

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

MS>Но я не об этом. Дык, а чем же тебе шаблоны не нравятся в C++? Только честно ответь — используешь их?

Да, использую. И я не говорил, что они мне не нравятся

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Имелось в виду, что для того, чтобы решить одну и ту же задачу, C#-нику понадобится меньший общий объем знаний, чем C++-нику; во-первых, потому что GC и другие плюшки, во-вторых (и, имхо, это главное) — потому что большинство необходимых стандартных вещей есть в библиотеках .Net, а С++-нику часто приходится искать новые библиотеки, осваивать, адаптировать к сущ. коду и т.п.

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

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

ЗХ>>Имелось в виду, что для того, чтобы решить одну и ту же задачу, C#-нику понадобится меньший общий объем знаний, чем C++-нику; во-первых, потому что GC и другие плюшки, во-вторых (и, имхо, это главное) — потому что большинство необходимых стандартных вещей есть в библиотеках .Net, а С++-нику часто приходится искать новые библиотеки, осваивать, адаптировать к сущ. коду и т.п.

ХД>Скажем так, С++ программисту дополнительно требуется умение не погрязнуть в таких мелочах как поиск новых библиотек, адаптация, управление памятью. В этом ты прав. Но, согласись, хорошо об этом не думать, когда пишешь, ну например, классы бизнес-логики?

Ну дык! Я же и не пытался сказать, что это преимущество плюсов!
Просто некоторым нравится

Автор: Зверёк Харьковский
Дата: 11.06.04

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

ХД>Нет, не интегрирую. Думаю, что то, что я сейчас пишу на С++ потом будут переписывать на С#

Прости за резкость, но это глупо. Лучше уж сразу на C#.

ХД>>>Фреймворк помогает хотя бы в плане управления памятью. Помогает большой хорошо документированной библиотекой.
MS>>Да, управление памятью — это большой плюс. Только вряд ли это уж очень повышает уровень абстракции, не так ли Насчет документации тоже согласен. Microsoft поставило на .NET, поэтому старая документация не обновлялась. Но опять же, чем это повышает уровень абстракции?

ХД>Про уровни абстракции я не говорил.

Возвращаясь к контексту, я бы отметил, что .Net Framework помогает не рассматривать проблемы низкого уровня, а сконцентрироваться на решении задачи, решать проблемы более высокого порядка.

Выделенное не что иное, как уровни абстракции

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

Полностью согласен. Это преимущества .NET. Но вопрос был ведь не в этом

ХД>Я за тебя рад

Спасибо.

ХД>>>Надеюсь со вторым фреймворком получить прирост производительности и читабельности благодаря дженерикам.
MS>>Шаблоны (и generics) на самом деле только затрудняют чтение. Сравни (код поскипан)

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

Именно. А в С++ они чуть ли не с рождения. Тогда чем же в данном контексте помогает .NET, которые пока еще не выпустил данную функциональность?

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

C>Возможность запуска .NET-приложения на "большом железе". Я просто не
C>знаю сколько там у них тесты работают, поэтому и не могу цифры привести.

Дык времена то уже не те. Сановское "большое железо" на сегодня уже барахло. Ничего нового они уже и не пытаются делать. У них теперь Оптероны — это большое железо. А на них и виндвс с Линуксом идут неплохо. Учитывая потери неизбежные при таких крутых портированиях скорость решения на "большом железе" может оказаться не стоящей тех затрат которые требуются на этот перход.

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

VladD2 пишет:

> C>Возможность запуска .NET-приложения на "большом железе". Я просто не
> C>знаю сколько там у них тесты работают, поэтому и не могу цифры привести.
> Дык времена то уже не те. Сановское "большое железо" на сегодня уже
> барахло. Ничего нового они уже и не пытаются делать.

Оно не барахло на действительно _больших_ масштабах (типа 32
процессоров, в нашем случае их было 24), x86 просто до такого не
масштабируется. Кроме того, Сановское железо отличается хорошей
стабильностью.

> У них теперь Оптероны — это большое железо. А на них и виндвс с
> Линуксом идут неплохо. Учитывая потери неизбежные при таких крутых
> портированиях скорость решения на "большом железе" может оказаться не
> стоящей тех затрат которые требуются на этот перход.

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

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

Он не был "суперкомпьютерным", просто достаточно тяжелым.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

MS>

MS>Возвращаясь к контексту, я бы отметил, что .Net Framework помогает не рассматривать проблемы низкого уровня, а сконцентрироваться на решении задачи, решать проблемы более высокого порядка.

MS>Выделенное не что иное, как уровни абстракции

Да, действительно, прочитал wikipedia Ну что ж, тогда да, примененяя библиотеки уровня .Net Framework я начинаю работать на более высоком уровне абстракции.
Упреждая вопрос, а что же даёт именно фреймворк? Стандартность в какой-то мере. Я могу вспомнить только штук 5 классов строк, используемых при программировании на С++. И также вспоминаю геморрой, с которым я скрещиваю эти самые разные типы строк.

MS>>>Шаблоны (и generics) на самом деле только затрудняют чтение. Сравни (код поскипан)
ХД>>Но эти затруднения, я надеюсь, будут несравнимы с преимуществами типизированных коллекций, которые будут включены в релиз второго фреймворка.
MS>Именно. А в С++ они чуть ли не с рождения. Тогда чем же в данном контексте помогает .NET, которые пока еще не выпустил данную функциональность?

Я уже написал же выше — он позволяет мне не задумываться до поры до времени о выборе библиотеки, об управлении памятью etc. Я уже получил добротно сделанный инструмент, который меня на сегодня удовлетворяет. А если он станет ещё лучше, я воспользуюсь и новыми фичами

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

ХД>Ну что ж, тогда да, примененяя библиотеки уровня .Net Framework я начинаю работать на более высоком уровне абстракции.

Вернулись к началу нашего разговора. А чем же обусловленно данное повышение абстракции? Вот ты говоришь, что теперь только и делаешь, что реализовываешь бизнес-логику, и не о чем не заботишься. Этому есть два разумных объяснения (не связанное с .NET):

a) Ты стал главным архитектором и в твои задачи входит создание макетов на UML.
б) Ты еще не подошел к основной задачи.

Создание бизнес-сущностей — день делов. Детализация + реализация — полгода. Понимаешь к чему я клоню? Создание xml файлов, работа с БД, сохранение настроек и т.п. — это низкоуровневые вещи, помогающие решать задачи. Именно ими ты и будешь заниматься оставшиеся полгода без одного дня. Это будет происходить как на С++, так и на С#. Никакой разницы.

ХД>Упреждая вопрос, а что же даёт именно фреймворк? Стандартность в какой-то мере. Я могу вспомнить только штук 5 классов строк, используемых при программировании на С++. И также вспоминаю геморрой, с которым я скрещиваю эти самые разные типы строк.

Да, стандартность — это очень сильная вещь. Здесь я согласен. Класс String мощный механизм по сравнению с его С++ — аналогами.

MS>>>>Шаблоны (и generics) на самом деле только затрудняют чтение. Сравни (код поскипан)
ХД>>>Но эти затруднения, я надеюсь, будут несравнимы с преимуществами типизированных коллекций, которые будут включены в релиз второго фреймворка.
MS>>Именно. А в С++ они чуть ли не с рождения. Тогда чем же в данном контексте помогает .NET, которые пока еще не выпустил данную функциональность?

ХД>Я уже написал же выше — он позволяет мне не задумываться до поры до времени о выборе библиотеки, об управлении памятью etc.

А каким образом это относиться к generics и шаблонам?

ХД>Я уже получил добротно сделанный инструмент, который меня на сегодня удовлетворяет. А если он станет ещё лучше, я воспользуюсь и новыми фичами

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

Но!

За .NET будующее. Его поддерживают все больше и больше. За ним стоит Microsoft. Именно эти три слона и склоняют чашу в сторону .NET. Именно поэтому и я его выбрал

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

MS>Создание бизнес-сущностей — день делов. Детализация + реализация — полгода. Понимаешь к чему я клоню? Создание xml файлов, работа с БД, сохранение настроек и т.п. — это низкоуровневые вещи, помогающие решать задачи. Именно ими ты и будешь заниматься оставшиеся полгода без одного дня. Это будет происходить как на С++, так и на С#. Никакой разницы.

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

ХД>>Я уже написал же выше — он позволяет мне не задумываться до поры до времени о выборе библиотеки, об управлении памятью etc.
MS>А каким образом это относиться к generics и шаблонам?

Да никаким, на шаблонах свет клином не сошёлся Ты неправильно цитату разбил, потерял следующее:

Я уже получил добротно сделанный инструмент, который меня на сегодня удовлетворяет. А если он станет ещё лучше, я воспользуюсь и новыми фичами

Так что шаблоны я рассматриваю как очень вкусное дополнение.


MS>Вот, именно это и есть ключевые слова. .NET не повышает уровень абстракции, он не облегчает (по крайней мере настолько, чтобы трубить об этом на каждом повороте) контроль памятью, он не повышает скорость разработки. Все это миф.

Может, у тебя не тот дотнет?

MS>Но!
MS>За .NET будующее. Его поддерживают все больше и больше. За ним стоит Microsoft. Именно эти три слона и склоняют чашу в сторону .NET. Именно поэтому и я его выбрал

У...

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

C>Оно не барахло на действительно _больших_ масштабах (типа 32
C>процессоров, в нашем случае их было 24), x86 просто до такого не
C>масштабируется. Кроме того, Сановское железо отличается хорошей
C>стабильностью.

Оба предположения не верны. Тот же сан делает многопроцессорные серверы на Оптеронах. Да и есть куча другого крутого железа не от Сана. Серверы от HP или каой-нить Unisys.

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

Ну, ему вденее... хотя по мне так изврат форменный.

VladD2 пишет:

> C>Оно не барахло на действительно _больших_ масштабах (типа 32
> C>процессоров, в нашем случае их было 24), x86 просто до такого не
> C>масштабируется. Кроме того, Сановское железо отличается хорошей
> C>стабильностью.
> Оба предположения не верны. Тот же сан делает многопроцессорные
> серверы на Оптеронах. Да и есть куча другого крутого железа не от
> Сана. Серверы от HP или каой-нить Unisys
> <http://redmondmag.com/news/article.asp?EditorialsID=1983&gt;.

На больших параллельных системах сказывается влияние сильной модели
памяти в x86 — очень много времени уходит на синхронизацию кэшей
процессоров. Sparc'и в этом отношении намного лучше — они
проектировались изначально под многопроцессорность.

> C>Мы смотрели возможность сделать и кластерный вариант, но оказалось, что
> C>придется переделывать всю систему, так что купить железо посильнее для
> C>заказчика было дешевле.
> Ну, ему вденее... хотя по мне так изврат форменный.

Угу, мне тоже так кажется. Но ведь работает, что самое удивительное!

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

ХД>>>Я не вижу здесь снижения квалификации
A>>Ну может не особо и не всегда проявляется, но есть... Человек, знакомый с архитектурой проца знает, что имеенно из этих двух например работает быстрее (точнее, раньшне работало быстрее, но не в этом суть):

ХД>Эти вещи уже давно обрабатываются оптимизаторами компиляторов, которые были созданы именно для того, чтобы специалист по конструированию прогрограммной системы не парился по поводу того, как там работает его процессор и как записать цикл — спереди назад или задом наперёд, а занимался своим делом! Такова же роль и дотнета — дать возможность заниматься своим делом.

Да в общем не все они оптимизируются. Это пример, допустим, скомпилировался на VC++ .NET вот так:

; 10   :     for (int i=0; i<1000; i++)

    xor    eax, eax
    npad    8
$L9624:

; 11   :         c[i] = i;

    mov    DWORD PTR _c$[esp+eax*4+4000], eax
    inc    eax
    cmp    eax, 1000                ; 000003e8H
    jl    SHORT $L9624

; 12   : 
; 13   :     for (int i=999; i>=0; i--)

    mov    eax, 999                ; 000003e7H
$L9628:

; 14   :         c[i] = i;

    mov    DWORD PTR _c$[esp+eax*4+4000], eax
    dec    eax
    jns    SHORT $L9628

Короче, на одну инструкцию меньше. Другое дело, что для нынешний Пентиум это и не заметит — у него есть проблемы и посерьезней.

А вот, например, перемножение матриц размером 1000x1000: человек, имеющий представление о кэше будет знать, что быстрее будет вторую матрицу транспонировать, параллельно вычисляя первую строку результирующей матрицы. Ну а при вычислении последней строки, транспонировать ее обратно. И насколько я помню, будет лучше, если выделить память 1000x1024.
Но это такой, специализированный пример. Реальных тоже хватает. Вот не так давно одна дама пыталась передать в другой процесс с помощью WM_COPYDATA одну структурку членом которой являлся String. И она удивлялась, почему же у нее там в другом процессе вместо этой строки абра-кадабра. На что ей посоветовали сменить кодировку... Был бы опыт программирования с указателями, она бы уже задалась вопросом, а копируется ли текст вообще, или передается только адрес?
Может оно и не так часто встречается, но есть... В общем, понимание того, что там за кулисами творится, будет несомненным плюсом.

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

IT>У них вообще нет такого понятия. Черырёхлетнее образование в колледже даёт бакалавра и далеко не все российские институты эвалюируются буржуями в MS, очень часто в того же бакалавра. Я бы сказал, что колледж находится где-то между нашими иститутом и техникумом. Будржуйские университеты так же выпускают бакалавров. Если хочешь получить мастера, то это ещё 2 года обучения и вот оно возможно только в универе.
Спасибо за инфу

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

A>>Докажи!
Д>тебе нужно доказывать, что изучение паскаля, C и C# займет больше времени, чем одного C#?
Д>тяжелый случай, однако
Д>объем знаний будет один и тот же, просто экономится время за счет выброшенного мусора синтаксических отличий

Итак цитирую:
Д>глупости. Если вводить его первым, то как раз наборот — на императивные языки уйдет меньше времени. А освободившееся время можно будет использовать для чего-нибудь более интересного

Докажи, что последовательность Pascal -> C++ -> Java -> .NET будет длиннее, чем .NET -> Java -> C++ -> Pascal.

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

ХД>>>Я уже написал же выше — он позволяет мне не задумываться до поры до времени о выборе библиотеки, об управлении памятью etc.
MS>>А каким образом это относиться к generics и шаблонам?

ХД>Да никаким, на шаблонах свет клином не сошёлся Ты неправильно цитату разбил, потерял следующее:

Еще раз приведу твою цитату:

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

Так вот. В С++ это было изначально (типизированный коллекции). Так что в данном случае .NET ему только уступает.

ХД>Может, у тебя не тот дотнет?

Со временем начинаешь смотреть на вещи трезво, отметая всякую целофановую шелуху ввиде мифических зверей наподобие "dll hella" и "memory leak". Ни первое, ни второе .NET не решает. Если хорошая поддержка инструментария, но чтобы так, досконально решить проблему раз и навсегда — такого в .NET просто не существует.

Ты и сам это увидишь, когда за .NET появится еще одна технология. Вот тогда все и начнут говорить, мол в .NET GC неправильный, и языки слабоваты, да и утечки памяти плодятся. А что делать, программисты тоже есть хотят

Да можно даже готовый пример взять. Есть такая чудо технология Remoting. Была прекрасно-распрекраной. Думали — вот она, панацея для всего RPC-мира. Но стоило появиться Indigo, как тут же начали выплывать наружу довольно неприятные стороны Remoting (заслуженно и незаслуженно).

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

MS>Ты и сам это увидишь, когда за .NET появится еще одна технология. Вот тогда все и начнут говорить, мол в .NET GC неправильный, и языки слабоваты, да и утечки памяти плодятся. А что делать, программисты тоже есть хотят
Вот и я про то же... Перебесятся немного и "на своей шкуре прочувствуют необходимость перехода", а потом появится тема "Почему C# major надо вводить первым языком для обучения".

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

A>У нас до 3го курса в класс с win-машинами не пускают. Зато пускают в класс с FreeBSD-машинами и быстрым халявным интернетом. В результате многие к концу 2го курса очень неплохо управляются с никсами

И каков смысл этого действа?

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

A>4) Понимание того, что операционные системы бывают разные, и что о переносимости следует задумываться заранее

Странный какой-то способ объяснять что ОС бывают разные не пуская к алтернативе.

A>5) Понимание того, что не MS единым жив IT (ой, запинают...)

Сдается мне, что таким бразом скорее можно привить ненависть. Или к тем самым никсам, или к тем самым ОС от МС.

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

A>Собственно, аргументы в основном те же, что на тему .NET, просто фанатиков Delphi уровня Влада нонче не видно...

Милый, я на Дельфи (2-3) два года отбарабанил. И еще минимум 7 на С++. Сейчас 4-ый год получаю большое удовольствие от дотнета. Выйдет еще что-то более достойное получу удовольствие и от него. А фанатики — это те кто уперся во что-то одно и не хочет понять, что мир развивается. Пусть по спирали, но все же развивается.