Здравствуйте, Denys V., Вы писали:
A>>В конечном итоге, каждый человек сам выбирает для себя то, что он считает нужным или лучшим. DV>В статьи!!! DV>В "Философия программирования" однозначно!
Будем честными. Сразу уж в КСВ.
, 2003 г.
A>Правда состоит в том, что лучшей альтернативы С++ в ближайшее время не предвидится. C++ будет жить ещё очень долго. C++ будет жить до тех пор, пока на платформах будут поддерживаться компиляторы этого языка. А Microsoft далеко не единственный производитель компиляторов. Например, Intel традиционно выпускает два компилятора — C++ и Фортран.
Налачие кучи компиляторов фортрана в его время не спасло от устаревания, также история с коболом, несмотря на то что на коболе и по сей день написано больше всего строк кода. C++ тоже устарел. Процесс его вытеснения идет.
A>С++ это СВОБОДА. Программиста С++ не сажают в "тюрьму" какого-то одного фрэймворка или одной операционной системы. С++ программисту невозможно что-то навязать снаружи, потому что это универсальный язык, который позволяет полностью абстрагироваться от конкретной реализации. Более того, невероятная гибкость позволяет повторно использовать один и тот же код в разных независимых проектах на разных операционных системах (а некоторое время спустя написанные раньше библиотеки могут снова пригодиться — ведь ничего не пропадает, всё сохраняется!), и это позволяет существенно экономить время. По простоте изучения C++ почти такой же как Java или С#.
Невернятная гибкость C# позволяет запускать один и тотже код (в бинарном виде) на Windows, Linux, MacOS (iPhone в том числе), WindowsMobile. Иходники также могут быть скомилированы для запуска в браузере (Silverlight), также по C# можно создать JS код (Script#) или SQL запрос (Linq2SQL, EF).
Так что речь о "тюрьмах" и повторном использовании — мимо кассы.
По простоте изучения C++ гораздо сложнее Java и C#. А обилие способов "выстрелить себе в ногу" на C++ требует большой строгости при разработке (почитайте coding styles гугла).
A>Кроме этого, С++ применим для любой ниши.
Ага, особенно для веб-разработки. Да и в enterprise он не сильно прижился.
A>C++ это кость в горле Microsoft.
Счего бы?
A>Программист, который пишет на C++ полностью неуправляем с точки зрения монополии. Такой программист может делать всё что захочет. У него есть все степени свободы. Он вещь сама в себе. Он может спокойно перейти на Линукс, на Макинтош, на FreeBSD/Unix/Solaris или ... на любую новую операционную систему, к примеру от Google. Да... Язык С++ это тот самый кошмарный сон Майкрософта, от которого монополия уже который год пытается незаметно избавиться с помощью агрессивной рекламы .NET технологий и последующей "привязкой" разработчиков к C#.
C C# тоже самое. С помощью Mono можно разрабатывать на любой ОС.
A>С коммерческой точки зрения язык С++ — это реальная угроза для монополии. Особенно в условиях чрезвычайно острой конкуренции со свободными юниксами, и тем более сейчас, с выходом бесплатного Qt.
Прямо вендекапец какой-то.
A>Задача монополиста — жестко посадить девелопера "на иглу". Поэтому политика свелась даже к тому, чтобы в бесплатную версию VS.NET Express не включать традиционные средства разработки приложений на C++ для Windows — MFC.
Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего. Будь MS действительно такой плохой компанией вообще бы отказались от поддержки C++ библиотек года 3 назад.
A>Зато маркетинговый пиар С# и VB.NET продолжается полным ходом. Здесь всё понятно. В Microsoft выбрали традиционный подход для оболванивания разработчиков, и пока он работает. Но только есть одна проблема — кризис доверия. Люди не могут простить то, что произошло с VB Classic, Win32 API, COM+.
И что с ними произошло? Правильный ответ — ничего. Просто эти технологии достигли предела развития. А MS чтобы держаться на плаву надо придумывать что-то новое.
A>Я когда-то тоже писал на VB6, внимательно изучал COM технологии. Но потом случилось то, что всех лояльных программистов неожиданно "кинули" — сказали что языку VB6 пришёл конец. Писали даже петицию, с просьбой включить VB Classic в состав новой студии — не помогло. Многие расценили этот шаг от Microsoft как издевательство. Программисты с девяностых годов учили Visual Basic около 15 лет, потратили кучу времени на изучение особенностей, а потом их просто ставят перед фактом — что весь ваш труд можете выбросить, или попробовать всё переписать. Почему? Потому что кому-то в Microsoft так захотелось.
И большенство из тех, кто писал на VB пересели на VB.NET. Недовольных я что-то не видел.
Вообще любые перемены вызывают такие кризисы, но если предлагается достойная замена, то кризис быстро проходит.
.NET более чем достойная замена.
A>Так вот, вместо выбора очередного маразма под называнием VB.NET, я полностью перешёл на надёжный C++.
А что же сразу не стали на C++ кодить? Ждали пока MS вас кинет? VB и был-то не самым лучшим языком, больше для скриптинга подходил.
A>Кстати, знаю и про то, что новоиспечённые сторонники C# часто тоже переходят на C++ и говорят об удобстве проектирования ПО с помощью кроссплатформенных обёрток и библиотек таких как Qt, о долговечности, проверенной надежности языка C++. В конечном итоге они приходят к выводу, что важнее больше думать, вместо того чтобы громко кричать.
"Часто" — это очень громко сказано. Из порядка сотни программистов на .NET я знаю только одного, который на C++ перешел. В основном наоборот.
A>Хотя вас никто не заставляет использовать С++ и быть свободными. Пожалуйста, пользуйтесь очередными "технологиями" от Microsoft. А я, например, очень уважаю свой труд, и поэтому не могу позволить чтобы работоспособность моего кода зависела от очередного выпендрёжа или замены очередного фреймворка Microsoft на что-нибудь ещё, более "модное". Я просто хочу чтобы мои наработки можно было использовать и через 5 лет, и через 10 лет. А гадать в какой следующий дурдом побежит команда Билли мне не интересно.
Никто вам не мешает знать несколько языков и технологий. Новые технологии не появляются неожижанно, у вас всегда будет время изучить новое, прежде чем оно пойдет в массы.
A>В конечном итоге, каждый человек сам выбирает для себя то, что он считает нужным или лучшим.
Аминь
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, gandjustas, Вы писали:
G>>И что, не развернулась?
Кё>Да как бы, почему-то, я не знаю почему, нет. Я сам с 2001-го года, как только увидел спецификацию C#, питаю большие надежды на .Net. Но Microsoft пока лишь доказывает, что она Microsoft.
Кё>С одной стороны, забавно наблюдать, как восемь лет назад C++серы усмехались, мол «вот майкрософт сделала неудачную попытку клонировать яву, через полгода умрет». Да впрочем, и до сих пор такие одаренные попадаются
В 2001 я тоже так усмехался.
Кё>С другой стороны, .Net даже близко не подошел к тому, чтобы стать платформой нового времени. Что я пока вижу, это как M$ включает в самый первый же гайд по WPF раздел "Optimizing WPF Application Performance", в котором говорится, что делать, если ваше приложение работает медленно или жрет слишком много. Интересно, не так ли?
А что такого удивительного. Напишите графический движок, которым будут тысячи людей пользоваться и заставьте его всегда работать быстро и экономично.
Кё>Максимум, что сумел .Net — занял ниши, в которых C++ был плох. Рано еще говорить «будем писать на C#/WPF вместо C++/Qt, ибо разницы нет». Ибо разница есть. И я не предвижу ничего со стороны MS, чтобы эту разницу устранить.
И в чем разница?
Почему-то на этот вопрос ответ находится только "кроссплатформенность", но а)кроссплатформенность гуя не означает кроссплатформенность всего приложения, б)при 90% виндовсов на персональных компьютерах эта кросплатформенность не сильно нужна, в)с появлением Mono 2.0 на .NET также можно писать кроссплатформенный код.
Здравствуйте, gandjustas, Вы писали:
S>>Множественного наследования реализации. G>А вы его используете? Тогда вам в форум по философии, там быстро все объяснят.
Разумеется, используем — невиртуальное. Что на эту тему думают философы, меня абсолютно не волнует.
S>>Так и нам хватает, для текущих задач, но не сказать чтобы с избытком. Юзеры по крайней мере хотели бы обрабатывать в сто раз большие данные — и желательно в сто раз быстрее G>Пусть платят в 100*100, те в 10000 раз больше и все им будет
Они не хотят платить больше, смысл в использовании софта пропадет. Но их деньги нам все равно нужны.
G>А чем вы таким занимаетесь? G>При ОЧЕНЬ больших объемах уже проблемы не перформанса на одной машине возникают.
Data Mining/Text Mining. Не на одной машине — это кстати гораздо сложнее, чем на одной на плюсах. И куда дороже.
>>>>> динамически генерировать код и тому подобное. S>>>>И часто вам приходится динамически генерировать код? G>>>Сам кодогенерацию пишу примерно раз в месяц, а использую кадлый день.
S>>В смысле, Emit раз в месяц? Жостко G>Да ниче страшного нет. В основном простые функции эмитятся, чтобы рефлекшеном не пользоваться.
Это видимо из-за отсутствия более правильных средств
S>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? G>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов.
Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение.
S>>Кодогенерация на лету у нас в программе когда-то была, на ассемблере G>.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится.
Да в общем то и не надо
S>>Не, чего бы мне из шарпа реально пригодилось — это разве что LINQ и лямбды, остальное нафиг. Метапрограммирование в компайлтайме должно быть и совсем не такое. G>Метапрограммирование должно быть везде.
В рантайме — разве что скрипты компилять. Так они и без него неплохо работают.
>>>>> S>Наоборот, если быстродействие важно — с ним убъешся просто, с дотнетом этим. Так что утверждение "Месяц это минимум" неплохо бы сначала обосновать. >>>>> А вы поищите сравнения производительности на форуме. Нету супер-тормозов, кроме того программы на .NET параллелятся в разы проще.
S>>>>Я не говорю про супер-тормоза, оно просто все равномерно работает раза в два медленнее. G>>>как раз равномерно все работает быстрее, из-за быстрого выделения памяти, а тех местах где надо много считать получается чуть медленее (даже не в 2 раза).
S>>У наших конкурентов есть очень похожий на наш (вернее, мы на них) продукт, написан на джаве. Работает раза в три медленнее и жрет в два раза больше памяти. S>>Так что не надо мне рассказывать сказки. G>Это ж джава. Она и скоростью никогда не отличалась.
На дотнете такое писать пока желающих не нашлось. Напишут — сравним.
G>да еще и непонятно какой уровень разработчиков.
Типа лидер рынка.
S>>>>И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо. G>>>Это вы сами придумали? G>>>Производительность можно посадить при неправильной стратегии выделения памяти в программе и использования неподходящих классов. G>>>Но можно этих ошибок и не совершать.
S>>Да да да. Но на управляемых языках совершать эти ошибки проще. G>Ошибки совершаются одинаково независимо от языка. Только в управляемых потенциальных ошибок меньше.
Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. А ошибки в логике что там что сям действительно одинаково легко навесить. В голом С кстати ошибки с производительность еще труднее делать, но там и код писать сильно труднее
G>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код.
Хочешь еще про необходимость профотбора пофлеймить что ли?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Множественного наследования реализации. G>>А вы его используете? Тогда вам в форум по философии, там быстро все объяснят. S>Разумеется, используем — невиртуальное. Что на эту тему думают философы, меня абсолютно не волнует.
>>>>>> динамически генерировать код и тому подобное. S>>>>>И часто вам приходится динамически генерировать код? G>>>>Сам кодогенерацию пишу примерно раз в месяц, а использую кадлый день. S>>>В смысле, Emit раз в месяц? Жостко G>>Да ниче страшного нет. В основном простые функции эмитятся, чтобы рефлекшеном не пользоваться. S>Это видимо из-за отсутствия более правильных средств
Ну да. Отсутствие "compiler as service" иногда напрягает. Но вроде как с DLR в .NET 4 станет чуть легче жить.
S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение.
Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму.
S>>>Кодогенерация на лету у нас в программе когда-то была, на ассемблере G>>.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится. S>Да в общем то и не надо
Вам может и не надо, а возможность очень хорошая.
S>>>Не, чего бы мне из шарпа реально пригодилось — это разве что LINQ и лямбды, остальное нафиг. Метапрограммирование в компайлтайме должно быть и совсем не такое. G>>Метапрограммирование должно быть везде. S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают.
Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции.
G>>да еще и непонятно какой уровень разработчиков. S>Типа лидер рынка.
Ну это ни о чем не говорит. Я работал к компании — лидере своего рынка, но код там воистину ужасен.
S>>>>>И иногда — большие провалы из-за каких-то специфических особенностей контейнеров. Не, может их и можно забороть, но на это время надо. G>>>>Это вы сами придумали? G>>>>Производительность можно посадить при неправильной стратегии выделения памяти в программе и использования неподходящих классов. G>>>>Но можно этих ошибок и не совершать.
S>>>Да да да. Но на управляемых языках совершать эти ошибки проще. G>>Ошибки совершаются одинаково независимо от языка. Только в управляемых потенциальных ошибок меньше.
S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее.
И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна.
G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. S>Хочешь еще про необходимость профотбора пофлеймить что ли?
Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3251166@news.rsdn.ru...
> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? > G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. > S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. > Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму.
Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую
> S>>>Кодогенерация на лету у нас в программе когда-то была, на ассемблере > G>>.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится. > S>Да в общем то и не надо > Вам может и не надо, а возможность очень хорошая.
Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off.
> S>>>Не, чего бы мне из шарпа реально пригодилось — это разве что LINQ и лямбды, остальное нафиг. Метапрограммирование в компайлтайме должно быть и совсем не такое. > G>>Метапрограммирование должно быть везде. > S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. > Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции.
Ну я только рад за разработчиков FPGA, только мне-то что с того?
> G>>да еще и непонятно какой уровень разработчиков. > S>Типа лидер рынка. > Ну это ни о чем не говорит. Я работал к компании — лидере своего рынка, но код там воистину ужасен.
У меня нет оснований полагать, что мы напишем лучше. А на плюсах — написали.
> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. > И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна.
Сложнее — потому что слой "шоколада" толще.
> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. > S>Хочешь еще про необходимость профотбора пофлеймить что ли? > Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании.
Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании Совсем уж бред то не пиши, ладно?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
>> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. >> S>Хочешь еще про необходимость профотбора пофлеймить что ли? >> Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании.
S>Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании Совсем уж бред то не пиши, ладно?
Ну разве не видно, что у человека C# повинен во всех радостях жизни. Завтра окажется, что мы тоже должны читать мантры, и какого мы неблагодарные этого не понимаем то? Счастье то вот оно.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, gandjustas, Вы писали:
С>>Ну, она, наверное, развернулась, так ведь до сих пор говорят — "через пару лет будет ого-го". G>Ну так технология развивается. "через пару лет будет ого-го" каждый раз говорят о разных вещах.
Каждый раз говорят о том, что C/C++ вот-вот станет никому не нужен, и C# будет годен для всего.
G>Этот индекс ужасен. Вы зайдите и посмотрите его определение. G>Лучше смотрите в объявлениях о работе чем компании щанимаются.[...]
А по-моему — прекрасный индекс.
Не нравится этот — найдите другой индекс, посмотрим и на него. Я ещё один нашёл.
По поводу, чем компании занимаются — вот с job.ru, Москва, первая страница выдачи. Мной убраны вакансии администраторов и всяких "менеджеров по ведению бизнеса".
Программист 1С: УПП 8.0
Программист 1С
Консультант по программе Парус
Консультант SAP
Программист Visual C++
Ведущий программист С++
Разработчик С++
Программист С++
Aрхитектор С++
Старший разработчик Java
Java программист
Старший разработчик С++/3D
Разработчик драйверов
Консультант SAP HR
Программист С#
Разработчик C#
Разработчик J 2EE
Разработчик .NET
Разработчик SAP Netweaver
Программист С++
С>>Эти три примера, в принципе, моё высказывание подтверждают, а что эти ораторы учли, а что нет — не важно. G>Вы считаете что любую бредятину, которую пишут на форуме пожно приводить в подтверждение своих слов?
Мои слова подтверждает не смысл этого сообщения (который, совершенно согласен, по сути бредовое), а наличие такого сообщения.
A>Первый раз — когда финн Линус Торвальдс осмелился написать бесплатную и открытую операционную систему, выйти против монстроидально устрашающего конкурента...
Дабы подлить огня в затухающее пламя .
Было бы неплохо обсудить преимущество языков с точки зренея наступающего(или наступившего у кого как) кризиса.
Из моего опыта с Джавистами и Дотнетчиками компании прощаються охотней (почемуто особенно аутсорсеры).
Здравствуйте, gandjustas, Вы писали:
G>Налачие кучи компиляторов фортрана в его время не спасло от устаревания.
Фортран занимает лидирующее положение среди языков программирования, ориентированных на решение научно-технических задач, требующих большого объема вычислений. Особенно актуальным является применение Фортрана при решении крупномасштабных вычислительных задач с использованием современных параллельных вычислительных систем. Решение таких задач требуется в различных сферах фундаментальных научных исследований. Одно из преимуществ современного Фортрана — большое количество написанных на нём программ и библиотек подпрограмм. Среди учёных, например, ходит такая присказка, что любая математическая задача уже имеет решение на Фортране, и, действительно, можно найти среди тысяч фортрановских пакетов и пакет для перемножения матриц, и пакет для решения сложных интегральных уравнений и многие, многие другие. Ряд таких пакетов создавались на протяжении десятилетий и популярны в научной среде по сей день. Большинство таких библиотек является фактически достоянием человечества: они доступны в исходных кодах, хорошо документированы, отлажены и весьма эффективны. Поэтому изменять, а тем более переписывать их на других языках программирования накладно, несмотря на то, что регулярно производятся попытки автоматического конвертирования FORTRAN-кода на языки C/C++. Самый новый стандарт этого языка — Fortran 2008.
G>C++ тоже устарел. Процесс его вытеснения идет.
Чем? Шарпом и джавой? Так ведь это тюремные языки привязанные к своим фреймворкам и капризам корпораций.
G>С помощью Mono можно разрабатывать на любой ОС.
Mono — это провокация, очередная попытка освобождения программистов от тюрьмы майкрософта (Mono is a free implementation of Microsoft's language C#. Microsoft has declared itself our enemy and we know that Microsoft is getting patents on some features of C#.) Патенты на C#/CLI принадлежат Microsoft, и до сих пор ведутся споры насчёт допустимости риска ради использования Mono. Но так или иначе, Mono закономерно приспосабливается под требования очередных реализаций дот-нет-фреймворков. И здесь очевидная цель — не создание альтернативной платформы для разработчиков C#, а простое освобождение людей от Windows-зависимости, путём копирования под юниксы. Но от самой политики Microsoft это не спасёт. А какая политика у этой компании уже все знают — непредсказуемость и "кидалово". И даже вы это здесь подтверждаете:
G>А MS чтобы держаться на плаву надо придумывать что-то новое.
Тратить драгоценное время на изучение очередных одноразовых "технологий" Microsoft, только чтобы удержать эту корпорацию на плаву — не интересно.
A>>Кроме этого, С++ применим для любой ниши. G>Ага, особенно для веб-разработки.
Не спорю, маркетинг-пиаром для веб-разработки на С++ — просто не кому было заниматься. В результате, многие упустили очень важную деталь — С++ позволяет экономить сотни тысяч (а в последствии миллионы) долларов на вычисительных мощностях серверов. И задачи, функциональность ультрабыстрых веб сервисов можно постоянно усложнять без значительного наращивания ресурсов. Это позволяет делать FastCGI в связке с C++.
Есть даже такой веб сервер — лайти (lighttpd с нативной поддержкой FastCGI), который кстати довольно успешно используется на Youtube именно для этих целей.
G>Да и в enterprise он не сильно прижился.
Enterprise очень сильно зависит от психологического воздействия пиара, маркетинга, давления корпораций. Там сложная политика больших денег, а не технологий.
G>Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего.
Политика майкрософт — это вообще клиника. Там ещё старый зоопарк толком не закончился, а уже начался новый — с совместимостью разных версий .NET фрэймворков.
G>Будь MS действительно такой плохой компанией вообще бы отказались от поддержки C++ библиотек года 3 назад.
Они прекрасно понимают что явным образом такой шаг будет сделать очень сложно. И пока даже сами пишут Windows на C/C++.
G>А что же сразу не стали на C++ кодить? Ждали пока MS вас кинет? VB и был-то не самым лучшим языком, больше для скриптинга подходил.
Я могу вам сейчас задать точно такой же вопрос: А чего вы на C# кодите? Ждёте пока MS вас кинет?
С# по скорости выполнения, пока тоже больше для скриптинга подходит.
G>Никто вам не мешает знать несколько языков и технологий. Новые технологии не появляются неожижанно, у вас всегда будет время изучить новое, прежде чем оно пойдет в массы.
Ещё раз повторю. Терять время на изучение новых одноразовых "технологий", только чтобы удержать Microsoft на плаву — не интересно.
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3251166@news.rsdn.ru...
>> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? >> G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. >> S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. >> Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму.
S>Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую
всегда — это во всем приложении. Все связи между слоями приложения управляются через IoC.
>> S>>>Кодогенерация на лету у нас в программе когда-то была, на ассемблере >> G>>.NETовский JIT умеет инлайнить код сгенерированной сборки в вызывающий код Вручную такое делать не получится. >> S>Да в общем то и не надо >> Вам может и не надо, а возможность очень хорошая.
S>Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off.
Нету затрат по производительнотси никаких, во многих сценариях .NET работает быстрее C++ за счет более быстрого выделения памяти.
>> G>>Метапрограммирование должно быть везде. >> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. S>Ну я только рад за разработчиков FPGA, только мне-то что с того?
С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
>> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. >> И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна. S>Сложнее — потому что слой "шоколада" толще.
Ну CLR не дураки пишут, само по себе тормозить оно не умеет. Тормоза чаще всего вызываны неправильным исопользованием. Вот как раз сценариев неправльного использования не так много.
>> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. >> S>Хочешь еще про необходимость профотбора пофлеймить что ли? >> Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании. S>Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании Особенно шаблоны и кастомные алокаторы
S>Совсем уж бред то не пиши, ладно?
Правда жизни. Вся комнда пришла после меня, никто ни разу не написал супер-тормозной код.
Действительно тормозящий код на .NET видел один раз, как раз из-за использовани Reflection. от после этого и начал заниматься кодогенерацией.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, gandjustas, Вы писали:
С>>>Ну, она, наверное, развернулась, так ведь до сих пор говорят — "через пару лет будет ого-го". G>>Ну так технология развивается. "через пару лет будет ого-го" каждый раз говорят о разных вещах.
С>Каждый раз говорят о том, что C/C++ вот-вот станет никому не нужен, и C# будет годен для всего.
Дык .NET с каждым мажорным апдейтом начинает покрывать все большие области. C\C++ никогда не станет совсем не нужным, но его доля на рынке постоянно уменьшается.
Или вы думаете что в один приекрасный день все бросят писат на C++ и разом перейдут на шарп?
G>>Этот индекс ужасен. Вы зайдите и посмотрите его определение. G>>Лучше смотрите в объявлениях о работе чем компании щанимаются.[...]
С>А по-моему — прекрасный индекс. С>Не нравится этот — найдите другой индекс, посмотрим и на него. Я ещё один нашёл.
Мда..
С>По поводу, чем компании занимаются — вот с job.ru, Москва, первая страница выдачи. Мной убраны вакансии администраторов и всяких "менеджеров по ведению бизнеса".
не сами вакансии интересуют, а количество различных конмпаний, работающих на C#. Косвенно этот праметр оценть можно по вакансиям.
С>>>Эти три примера, в принципе, моё высказывание подтверждают, а что эти ораторы учли, а что нет — не важно. G>>Вы считаете что любую бредятину, которую пишут на форуме пожно приводить в подтверждение своих слов?
С>Мои слова подтверждает не смысл этого сообщения (который, совершенно согласен, по сути бредовое), а наличие такого сообщения.
Ну на просторах интернета можно много чего найти. На этом форуме можно найти сотни цитат про то что .NET загнется.
Здравствуйте, Germes, Вы писали:
G>Дабы подлить огня в затухающее пламя . G>Было бы неплохо обсудить преимущество языков с точки зренея наступающего(или наступившего у кого как) кризиса. G>Из моего опыта с Джавистами и Дотнетчиками компании прощаються охотней (почемуто особенно аутсорсеры).
наверное потому что в аутсорсе намного больше Java и .NET чем C++
Аутсорс первым пострадал от кризиса.
Здравствуйте, Anonim12, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>C++ тоже устарел. Процесс его вытеснения идет. A>Чем? Шарпом и джавой? Так ведь это тюремные языки привязанные к своим фреймворкам и капризам корпораций.
А вы на ГОЛОМ С++ пишете?
G>>С помощью Mono можно разрабатывать на любой ОС.
A>Mono — это провокация, очередная попытка освобождения программистов от тюрьмы майкрософта (Mono is a free implementation of Microsoft's language C#. Microsoft has declared itself our enemy and we know that Microsoft is getting patents on some features of C#.)
Источник откровения?
Наверное они такие заклятые враги, что даже пригласили выедущего разработчика Mono на PDC в качестве докладчика.
A>Патенты на C#/CLI принадлежат Microsoft, и до сих пор ведутся споры насчёт допустимости риска ради использования Mono.
С# стандартизован ECMA и никому не пренадлежит. Также ECMA стандартизировала спецификацию CLR.
Так что ваши слова — откровенный бред.
A>Но так или иначе, Mono закономерно приспосабливается под требования очередных реализаций дот-нет-фреймворков.
Mono во второй версии имеет некоторые фичи, которые даже в .NET 4 недоступны будут.
A>И здесь очевидная цель — не создание альтернативной платформы для разработчиков C#, а простое освобождение людей от Windows-зависимости, путём копирования под юниксы. Вы бы вопрос изучили перед тем как такое писать.
A>Но от самой политики Microsoft это не спасёт. А какая политика у этой компании уже все знают — непредсказуемость и "кидалово". И даже вы это здесь подтверждаете: G>>А MS чтобы держаться на плаву надо придумывать что-то новое.
Выход любого нового продукта анонсируют за год-два. Причем вместе с тупой рекламой предоставляют возможности будущим пиользователям бесплатно пользоваться продуктом во время тестирования?
Так где непредсказуемость и кидалово?
A>Тратить драгоценное время на изучение очередных одноразовых "технологий" Microsoft, только чтобы удержать эту корпорацию на плаву — не интересно.
Ну .NET не одноразовая технология. Скоро 10 лет ей стукнет и пока никто не собирается её выбрасывать.
Те кто с свое время перешаело на VB.NET не прогадали.
A>>>Кроме этого, С++ применим для любой ниши. G>>Ага, особенно для веб-разработки.
A>Не спорю, маркетинг-пиаром для веб-разработки на С++ — просто не кому было заниматься. В результате, многие упустили очень важную деталь — С++ позволяет экономить сотни тысяч (а в последствии миллионы) долларов на вычисительных мощностях серверов.
И потратить миллиарды на стоимости разработки
A>И задачи, функциональность ультрабыстрых веб сервисов можно постоянно усложнять без значительного наращивания ресурсов. Это позволяет делать FastCGI в связке с C++.
Это в теории, а примеры "ультрабыстрых веб сервисов" есть?
A>Есть даже такой веб сервер — лайти (lighttpd с нативной поддержкой FastCGI), который кстати довольно успешно используется на Youtube именно для этих целей. Только Youtube на питоне написан.
А lighttpd нужен для максимально быстрой отдачи контента.
G>>Да и в enterprise он не сильно прижился. A>Enterprise очень сильно зависит от психологического воздействия пиара, маркетинга, давления корпораций. Там сложная политика больших денег, а не технологий.
Ага, все гондоны, один я в белом халате.
G>>Конечно, MS гораздо выгоднее поддерживать один .NET чем зоопарк из MFC, ATL, WTL и прочего. A>Политика майкрософт — это вообще клиника. Там ещё старый зоопарк толком не закончился, а уже начался новый — с совместимостью разных версий .NET фрэймворков. Нету зоопарка. Разные версии FW не зависят друг от друга и могут спокойно сосуществовать на одной машине.
G>>А что же сразу не стали на C++ кодить? Ждали пока MS вас кинет? VB и был-то не самым лучшим языком, больше для скриптинга подходил. A>Я могу вам сейчас задать точно такой же вопрос: А чего вы на C# кодите? Ждёте пока MS вас кинет?
Ну я много на чем писал, на C# проще всего.
A>С# по скорости выполнения, пока тоже больше для скриптинга подходит.
Повторяйте это чаще — сами поверите. А пока из того что я видел на .NET работает быстрее C++. особенно это касается серверных приложений.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3251920@news.rsdn.ru...
>>> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? >>> G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. >>> S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. >>> Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму. > > S>Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую > всегда — это во всем приложении. Все связи между слоями приложения управляются через IoC.
Сколько тех слоев-то?
> S>Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off. > Нету затрат по производительнотси никаких, во многих сценариях .NET работает быстрее C++ за счет более быстрого выделения памяти.
Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения.
>>> G>>Метапрограммирование должно быть везде. >>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. > S>Ну я только рад за разработчиков FPGA, только мне-то что с того? > С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
CUDA SDK никак не устроит? Или ты утверждаешь, что F# сам сумеет криво написанный (т.е., без учета особенностей вычисления на видеокарте) алгоритм переделать?
>>> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. >>> И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна. > S>Сложнее — потому что слой "шоколада" толще. > Ну CLR не дураки пишут, само по себе тормозить оно не умеет. Тормоза чаще всего вызываны неправильным исопользованием. Вот как раз сценариев неправльного использования не так много.
Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят.
>>> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. >>> S>Хочешь еще про необходимость профотбора пофлеймить что ли? >>> Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании. > S>Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании > Особенно шаблоны и кастомные алокаторы
А что сложного в шаблонах и аллокаторах?
> S>Совсем уж бред то не пиши, ладно? > Правда жизни. Вся комнда пришла после меня, никто ни разу не написал супер-тормозной код. > Действительно тормозящий код на .NET видел один раз, как раз из-за использовани Reflection. от после этого и начал заниматься кодогенерацией.
Действительно тормозящий — это в сто раз что ли ?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
S>"gandjustas" <67312@users.rsdn.ru> wrote in message news:3251920@news.rsdn.ru...
>>>> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? >>>> G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. >>>> S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. >>>> Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму. >> >> S>Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую >> всегда — это во всем приложении. Все связи между слоями приложения управляются через IoC. S>Сколько тех слоев-то?
Ну как обычно. 3-4 слоя + cross-cutting.
>> S>Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off. >> Нету затрат по производительнотси никаких, во многих сценариях .NET работает быстрее C++ за счет более быстрого выделения памяти.
S>Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения.
Ну так приведите бенчмарки здесь.
>>>> G>>Метапрограммирование должно быть везде. >>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. >> S>Ну я только рад за разработчиков FPGA, только мне-то что с того? >> С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни.
S>CUDA SDK никак не устроит? Или ты утверждаешь, что F# сам сумеет криво написанный (т.е., без учета особенностей вычисления на видеокарте) алгоритм переделать?
Ну не любой код на фшарпе, а какое-то его подмножество. Но тем не менее это будет статически типизированынй код.
>>>> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. >>>> И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна. >> S>Сложнее — потому что слой "шоколада" толще. >> Ну CLR не дураки пишут, само по себе тормозить оно не умеет. Тормоза чаще всего вызываны неправильным исопользованием. Вот как раз сценариев неправльного использования не так много.
S>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят.
CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
>>>> G>>На собеседованиях я всегда задаю вопросы про потенциальные проблемы .NET. Их не так уж много, ответив или неответив на определенные вопросы кандидат сразу показывает насколько он может написать кривой код. >>>> S>Хочешь еще про необходимость профотбора пофлеймить что ли? >>>> Это я к тому что не очень много способов посадить производительность на ровном месте и почти все можно объяснить еще на собеседовании. >> S>Да-да-да, в плюсах тоже почти все можно объяснить еще на собеседовании >> Особенно шаблоны и кастомные алокаторы S>А что сложного в шаблонах и аллокаторах?
Действительно, совсем ничего
>> S>Совсем уж бред то не пиши, ладно? >> Правда жизни. Вся комнда пришла после меня, никто ни разу не написал супер-тормозной код. >> Действительно тормозящий код на .NET видел один раз, как раз из-за использовани Reflection. от после этого и начал заниматься кодогенерацией.
S>Действительно тормозящий — это в сто раз что ли ?
Действительно тормозящий — это быстродействия которого было недостаточно для выполнения задачи.
"gandjustas" <67312@users.rsdn.ru> wrote in message news:3252058@news.rsdn.ru...
>>>>> S>>>Это вот такая хрень http://search.cpan.org/~stevan/IOC/ оказывается теперь недоступна неуправляемым языкам? >>>>> G>>Доступна, но .NET IoC применять легко и непринужденно. Без внешних XML конфигов. >>>>> S>Ioc не настолько часто нужен, чтобы это имело хоть какое-то значение. >>>>> Ну это вы так думаете. Я считаю что IoC и сборка приложения из частей нужны всегда. останавливает только сложность таких решений. Но и она стремиться минимуму. >>> >>> S>Всегда — это сколько раз на приложение? Два, пять, пятьсот? Для пяти раз лично мне XML-конфиг написать не западло, ну а в пятистах случаев я просто обычные коллбэки использую >>> всегда — это во всем приложении. Все связи между слоями приложения управляются через IoC. > S>Сколько тех слоев-то? > Ну как обычно. 3-4 слоя + cross-cutting.
Т.е., 1 раз для приложения написать конфиг xml-ный — это ужас-ужас, сильно утомляющий программиста?
>>> S>Да хорошая, кто спорит. Только тех затрат по памяти и производительности, которые тащат за собой управляемые среды, для нас эта возможность не стоит — вот и весть trade-off. >>> Нету затрат по производительнотси никаких, во многих сценариях .NET работает быстрее C++ за счет более быстрого выделения памяти. > > S>Большинство когда либо найденных мной бенчмарков говорит об обратном. Равно как и личный опыт применения. > Ну так приведите бенчмарки здесь.
Ну те естественно уже не найду, канули так сказать в лету. Вот первое что попалось: http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html http://www.osnews.com/story/5602 http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/
>>>>> G>>Метапрограммирование должно быть везде. >>>>> S>В рантайме — разве что скрипты компилять. Так они и без него неплохо работают. >>>>> Узко мыслите. На F# например можно код на FPGA выполнить. При этом все будет статически типизировано и проверяться при компиляции. >>> S>Ну я только рад за разработчиков FPGA, только мне-то что с того? >>> С того что в программе можно computation-intensive задачу положить на видеокарту и радоваться жизни. > > S>CUDA SDK никак не устроит? Или ты утверждаешь, что F# сам сумеет криво написанный (т.е., без учета особенностей вычисления на видеокарте) алгоритм переделать? > Ну не любой код на фшарпе, а какое-то его подмножество.
Дело даже не в подмножестве, не заточенный под карту код либо вообще не пойдет, либо будет работать медленне чем на CPU.
> Но тем не менее это будет статически типизированынй код.
А с CUDA это по твоему какой код будет?
>>>>> S>Я говорю про ошибки связанные с быстродействием. В управляемых такие ошибки совершать легче, исправлять сложнее. >>>>> И почему их исправлять сложнее? Как раз чаще всего ошибка, которая бъет по перформансу, сразу видна. >>> S>Сложнее — потому что слой "шоколада" толще. >>> Ну CLR не дураки пишут, само по себе тормозить оно не умеет. Тормоза чаще всего вызываны неправильным исопользованием. Вот как раз сценариев неправльного использования не так много. > > S>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят. > CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
И че, Paint.NET умеет делать хотя бы 10% от того, что умеет фотошоп? И в котором месте тормозит фотошоп?
>>> S>Совсем уж бред то не пиши, ладно? >>> Правда жизни. Вся комнда пришла после меня, никто ни разу не написал супер-тормозной код. >>> Действительно тормозящий код на .NET видел один раз, как раз из-за использовани Reflection. от после этого и начал заниматься кодогенерацией. > > S>Действительно тормозящий — это в сто раз что ли ? > Действительно тормозящий — это быстродействия которого было недостаточно для выполнения задачи.
Ну это значит задачи такие, что им быстродействие не нужно.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, gandjustas, Вы писали:
S>>Угу, и JVM само по себе тормозить не умеет. Однако конечные продукты вполне тормозят. G>CLR — не JVM. Также как и программы на C++ тормозят. Смотри пример Photoshop vs Paint.NET.
Давайте больше ну будем приводить этот пример. Ибо Paint.Net и Photoshop это моська и Слон.
Даже сложность интерфейса несравнима, не говоря уже об функционале.
так... маленькая ремарка, открыл одну и ту же картинку в обеих... сделал пару мазков брашем и там и там...
Paint.Net занял в памяти 60 Мб
Photoshop 120 Мб
Но ведь даже интерфейса открытого и сложности в нем меньше в намного больше раз чем в 2 раза.
Так что не нужно сравнивать несравнимое. Ненужно. Я с радостью посмотрю на примеры — но этот — несостоятелен!!!
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
особенно аутсорсеры).
