Microsoft раскрывает .NET

> У вас тут что зеленые звезды это признаки дебилизма.

Вы просто завидуете :-).

> У вас тут что зеленые звезды это признаки дебилизма.

Порекомендую тебе интересный сайт: linuxsuxx.org. Тебе там обязательно понравится. Поспеши, они почти закончили раздавать халявные емайлы в обмен на какашки про линукс! :)

> Сходил по ссылке, как всегда повеселили ремарки:

> If you choose AllDirectories in your search and the directory structure contains a link that creates a loop, the search operation enters an infinite loop.

Интересно, кого в MS нанимают на работу системными программистами, которые не осилили даже распознавание тривиальных циклов при рекурсивном обходе.

В Linux'е, разумеется find не зацикливается.

Чему? Дебилизму?

> В Linux'е, разумеется find не зацикливается.

Более того, он ещё и на глючных ФС(как-то натолкнулся, когда подглючивала cifs) ругается что что-то не так и вылезает из рекурсии.

> Перечислю основные признаки:

Посмеялся, ибо кое-что похожее наблюдаю. Отличия следующие:

> 1. Разумеется, стоимость комплекса не менее 10^6 долларов.

Несколько меньше, всё-таки.

> На основе MsSQL, разумеется.

Самое поразительное, что там есть Oracle и даже под Solaris. Но MSSQL тоже присутствует, разумеется на винде :)

> 5. Ну и как же я мог забыть, оно работает с огромными финансовыми потоками.

С документооборотом только. Финансов напрямую никак не касается.

> Несколько меньше, всё-таки.

Кстати, тут я может быть поторопился. Поскольку вся эта хрень уже не первый год никак "не взлетит", есть шансы, что стоимость таки достигнет 10^6 и даже превысит.

>Чувствовал, что не зря начал читать этот длинный топик. Интуиция меня не подвела, anonymous отжёг про PHP. Откидываюсь на диван в предвкушении знатных предпитничных посиделок

Это был стёб вообще-то.

> Чему? Дебилизму?

Не-а. Звездочкам. С дебилизмом, судя по всему, у Вас все в порядке.

;-)

> хотя C# действительно удобный и простой язык,

C# 3.0 - простой? Да там список ключевых слов на две страницы только ;)

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

Итак, .NET (M$) vs C++. Берем очень простую задачку, и делаем ее на .NET и на С++. Задача: login в систему, запрос информации о клиенте, logoff.

Делаем на .NET, код тривиален. Время выполнения задачи (сервер не самый шустрый): 217ms.

Делаем на C++. Кода довольно много, хотя большая часть - просто поддержка web-services (универсальна и не увеличивается при добавлении новых сервисов). Кода на вызов запроса и получение ответа примерно столько же. Время выполнения: 63ms.

Теперь MSSQL vs PostgreSQL. Делаем 100000 inserts в только что сделанную таблицу customers с двумя десятками полей и primary key.

MSSQL дает ~1400 транзакций в сек. PostgreSQL дает > 3700 транзакций в сек. Это если для доступа использовать ODBC. Теперь пишем C++ wrapper, чтобы делал prepare, binary binding - the whole nine yards. Жмем все до предела. Результат: MSSQL - 2200 op/sec, PG - 7100 op/sec.

Кто-то еще хочет доказывать, что M$-решения полезны для бизнеса? Никакое удобство использования не перевесит замедление системы в 2-3 раза.

>Можно статистику по доходам от Vista на которой вы основываетесь?

>anonymous (*) (04.10.2007 11:07:45)

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

>> Перечислю основные признаки:

> Посмеялся, ибо кое-что похожее наблюдаю. Отличия следующие:

Ну так я вроде как для стёба и писал :) Рад, что при этом попал в точку.

> foreach(FileInfo fi in DirectoryInfo.GetFiles("*.cpp",SearchOptions.AllDirectories)) Console.WriteLine(fi.FullName);

Кстати, этот код _гораздо_ хуже того, который написал комрад shlag. Да, здесь короче записано. Но здесь массив со списком, который теоретически может оказаться огромным, зачем-то сохраняется в памяти перед тем, как быть обработаным. То есть уже на такой быдлозадачке, при самом лёгком её дотнетном решении, мы наблюдаем громадный перерасход памяти.

Эффективность, ау!

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

Эта... А если на F# попробовать?

> Делаем на .NET, код тривиален. Время выполнения задачи (сервер не самый шустрый): 217ms.

Нифига себе, скорость разработки... o_O

> Можно говно и с тремя конструкциями наворотить.

Ну почему, Brainfuck очень себе ничего язычок. Симпатишный :-)

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

> Эта... А если на F# попробовать?

Во-первых, цитата из википедии: "F# — это исследовательский прототип, не являющийся официальным языком от Microsoft. Не планируется делать его коммерческим."

Во-вторых, анонимус утверждал, что всё дотнетное можно сделать и на сишарпе.

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

Утомил уже с этой задачей... Топик читать скучно...

Все зависит от того, что понимается под "эффективностью".

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

Если эффективность - это скорость написания, то баш без сомнения рулит, но надолго ли? Минуты на три, пока другой программист не напишет более быстрый C# -код...

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

> Утомил уже с этой задачей... Топик читать скучно...

Прошу прощения, чересчур детально разобрал. Но я думаю, что разговор того стоит.

> Все зависит от того, что понимается под "эффективностью".

> Если эффективность - это скорость исполнения, то на C# можно написать эффективный код, в том числе для этой задачи.

С точки зрения скорости, лучшей будет программа, написанная на ассемблере конкретного процессора :) А если серьёзно, то использованный find как раз и заточен под _узкую_ задачу вывода списка файлов, потому её он решает с минимальным возможным оверхедом.

> Если эффективность - это скорость написания, то баш без сомнения рулит, но надолго ли? Минуты на три, пока другой программист не напишет более быстрый C# -код...

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

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

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

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

Вы ещё забываете таком момент, как поддержка. Например, ассемблерный код поддерживать - уж извините, лучше смерть :) Да и сишарпный код(для работы в неспецифичной для него области) будет трудно поддерживать.

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

gaa: чем дальше я читаю твои "высказывания", тем больше у меня уверенность, что ты не программист, а быдлобашадмин - бывший Делфи-ниудачник.

С такой уверенностью нести полную ахинею!

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

Бред сивой кобылы. Ты вылези из Доса! А в Баше интересно есть рекурсия? А обьекты?

А сейчас я начну кидаться Windows Monad Shell! Крутая среда разработки!

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

> Бред сивой кобылы. Ты вылези из Доса!

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

> А в Баше интересно есть рекурсия? А обьекты?

Рекурсия есть. А объекты там не нужны. Для чего-то, что решается лучше с помощью ООП, разумно использовать в т.ч. и сишарп. Например, EJB очень хорошо смотрится в объектной форме.

ООП - это всего лишь одна из парадигм программирования, не стоит возводить её в ранг абсолюта. Посмотри на тот же F#, который ни коим разом не объектно-ориентированный, а функциональный.

> А сейчас я начну кидаться какашкой! Крутая среда разработки!

о, вижу на линукссакс ты сходил :)

> С точки зрения скорости, лучшей будет программа, написанная на ассемблере конкретного процессора :) А если серьёзно, то использованный find как раз и заточен под _узкую_ задачу вывода списка файлов, потому её он решает с минимальным возможным оверхедом.

Это не так. В общем случае компилятор может создать и часто создает более эффективный код (критерии тоже бывают разными), чем тот код, который вручную может написать опытный программист на ассемблере. Тема давно изучена - повторяться не будем, надеюсь. Что касается find, то он предполагает множество входных параметров => find заточен под более общую задачу => есть шанс написать более эффективный код для данной задачи.

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

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

В мире NTFS просто не принято использовать рекурсивные ссылки (видимо из-за желания сохранить совместимость с FAT или еще по какой другой причине). Поэтому можно сказать, что проблема тоже решена в стандрартной библиотеке. Просто исходные задачи были разными (вероятно это проблема для Mono, но это не очень-то и нужно для .NET ??).

А сама задача решается просто. Храним граф пройденных каталогов и для новых каталогов/ссылок делаем проверку на повторяемость. Правда уже не три минуты. Где-нибудь минут тридцать - чтобы было время хорошо подумать.

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

Моя позиция остается прежней. Для _программирования_ лучше подумать один раз хорошо, и реализовать метод, который потом будет работать намного быстрее, чем посиксный find. Может быть, добавлю два исключения: (1) если такой вызов используется очень редко; (2) если find - это самая сложная часть программы... :)

> Моя позиция остается прежней. Для _программирования_ лучше подумать один раз хорошо, и реализовать метод, который потом будет работать намного быстрее, чем посиксный find. Может быть, добавлю два исключения: (1) если такой вызов используется очень редко; (2) если find - это самая сложная часть программы... :)

Ну да. Тут я совсем не спорю. Я именно такие случаи и имел в виду.

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

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

> В мире NTFS просто не принято использовать рекурсивные ссылки (видимо из-за желания сохранить совместимость с FAT или еще по какой другой причине). Поэтому можно сказать, что проблема тоже решена в стандрартной библиотеке.

А Вы помните вирус DIR? Он плодил несколько ссылок на один и тот же файл и система продолжала нормально работать, пока кто-нибудь умный не запускал Norton Disk Doctor, который убивал файл с более чем одной ссылкой, тем самым уничтожая данные.

Предлагаю идею вируса DIR-II: насоздавать рекурсивных ссылок на NTFS и ждать, пока Window$ сама себя убъёт :)

О таких вирусах не слышал. Зато читал, что есть такие, которые прячутся в неглавных потоках (streams), а наружу предстают обычными с виду текстовыми файлами.

Как говорится, недостатки - это продолжение наших достоинств.

> О таких вирусах не слышал. Зато читал, что есть такие, которые прячутся в неглавных потоках (streams), а наружу предстают обычными с виду текстовыми файлами.

DIR - он старый как дос, неудивительно, что о нём не помнят. Примерно после того, как его обнаружили, в "лечилках" дисков типа NDD или MS Scandisk появился вопрос о том, что делать с файлами, имеющими общие цепочки кластеров, в котором дефолтным значением было "копировать", а не "удалять", как раньше делалось.

> Для чего-то, что решается лучше с помощью ООП, разумно использовать в т.ч. и сишарп.

В т.ч. Java, Python и Ruby.

> Теперь MSSQL vs PostgreSQL. Делаем 100000 inserts в только что сделанную таблицу customers с двумя десятками полей и primary key.

> MSSQL дает ~1400 транзакций в сек. PostgreSQL дает > 3700 транзакций в сек. Это если для доступа использовать ODBC. Теперь пишем C++ wrapper, чтобы делал prepare, binary binding - the whole nine yards. Жмем все до предела. Результат: MSSQL - 2200 op/sec, PG - 7100 op/sec.

То есть базу тестируем используя только insert'ы? Может стоит програнать тесты отсюда http://tpc.org/

> gaa: чем дальше я читаю твои "высказывания", тем больше у меня уверенность, что ты не программист, а быдлобашадмин - бывший Делфи-ниудачник.

Уважаемый анонимус, разрешите полюбопытствовать. Я учусь разпозновать и отличать стеб от троллинга. Скажите пожалуйста, то, что вы пишете - это стеб или троллинг?

Это скорее всего правда. Я занимаюсь изучением тупости ЛОР-чеггоф. gaa - это уникальны экземпляр.

Видимо у него абсцецц мосга. Вернее, того, что раньше было им...

А вот и не оскорбил :-P

Единственное, в чём ты мог разочароваться, так это в своих способностях пересказывать книгу Рихтера по дотнету(вступление, где сказано "программисты, изучившие C++ считают его верхом совершенства, но дотнет лучше") и в том, что я не реагирую на детсадовские провокации типа обзывалок.

Это можно раасматривать наличие у тебя абсцесса головного мозга

Значит я должен был "вскипеть" и заорать в ответ на твои тяфкалки? Ты себя слишком высоко ценишь, меня и более профессионально пытались оскорбить :)

>Это можно раасматривать наличие у тебя абсцесса головного мозга

если аргументы закончились, не отчаивайтесь - оппонента всегда можно обозвать (с)

Да на такого быдлу оскорбления лень пускать, тем более профессионально. Ведь это ж пустое место.

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

ахахаха стёб засчитан! 5 балов! :DDDDDD

> Можно :) Не факт, что эффективнее, но работает. Ну, подставить вместо эндвиз проверку регулярного выражения можно без проблем

>class MainClass { public static void Main(string[] args) { Console.WriteLine("dotNET MEGAfinder"); find("/home/shlag/",".cpp"); } public static void find(string startFrom, string template) { foreach (string str in Directory.GetFiles(startFrom)) { if (str.EndsWith(template)) Console.WriteLine(startFrom + Path.DirectorySeparatorChar + str); }

>foreach (string str in Directory.GetDirectories(startFrom)) { find(str, template); } } }

фигня-с всё проще:

foreach (FileInfo fi in new DirectoryInfo("h:\\music").GetFiles("*.mp3", SearchOption.AllDirectories))

Console.WriteLine(fi.FullName);

к примеру

> foreach (FileInfo fi in new DirectoryInfo("h:\\music").GetFiles("*.mp3", SearchOption.AllDirectories)) Console.WriteLine(fi.FullName);

Анонимус не читает ремарки в MSDN? Там же чёрным по html-ю написано, что используя AllDirectories(кстати, почему не AllFolders?) можно нарваться на бесконечный цикл.

У 99,9999% пользователей Win такого извращения, как проблемы с рекурсивными ссылками - нет.

А в Юнихах это в каждой системе такое есть! Круто!

> У 99,9999% пользователей Win такого извращения, как проблемы с рекурсивными ссылками - нет.

Почитайте выше по треду про вирус DIR. На самом деле наличие _возможности_ иметь рекурсивные ссылки, но отсутствие механизма обхода зацикливания - это бомба замедленного действия. В *nix эти ссылки давно уже есть и все с ними работать умеют.

>Анонимус не читает ремарки в MSDN? Там же чёрным по html-ю написано, что используя AllDirectories(кстати, почему не AllFolders?) можно нарваться на бесконечный цикл.

там написано почему это может быть а в вин шансов что такое произойдет достаточно мало

>> Анонимус не читает ремарки в MSDN? Там же чёрным по html-ю написано, что используя AllDirectories(кстати, почему не AllFolders?) можно нарваться на бесконечный цикл.

> там написано почему это может быть а в вин шансов что такое произойдет достаточно мало

Достаточно _одной_ рекурсивной ссылки в %MyDocuments% чтобы система начинала виснуть при поиске файлов. Кстати, ещё неизвестно, как винда будет удалять такой рекурсивный каталог. Так что, вероятно придётся переформатировать диск. Хотя это вполне true-windows-way :)

А для того, чтобы этот малый шанс реализовался, достаточно всего одного троянописателя, наткнувшегося на эту запись в MSDN.

> У 99,9999% пользователей Win такого извращения, как проблемы с рекурсивными ссылками - нет.

Так и запишем - штатными возможностями NTFS в винде лучше не пользоваться, а то что-нить упадет.

>> У 99,9999% пользователей Win такого извращения, как проблемы с рекурсивными ссылками - нет.

> Так и запишем - штатными возможностями NTFS в винде лучше не пользоваться, а то что-нить упадет.

Можно обобщить: виндой лучше не пользоваться, а то что-нибудь упадёт :)

Вообще-то штатные ср-ва NTFS - маппинг каталога из совершенно другого места, а не всякие там рекурсии

> Вообще-то штатные ср-ва NTFS - маппинг каталога из совершенно другого места, а не всякие там рекурсии

Но оно позволяет реализовать и рекурсию. Следовательно, рекурсия - вполне штатная ситуация.

anonymous>

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

>(жалобно) может лучше всё-таки булочки?

Ну если отравиться захотелось - велкам :)