Cудьба Mono

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

что в этом плохого?

Ну я конечно понимаю что легче заниматься решением уже решенных проблем чем нерешенных.

дело не в этом. Знаешь, почему до сих пор не сделали автомобиль для всех? Просто потому, что потребности у всех разные. Кому-то нужен порше, кому-то москвич, а кому-то камаз. И именно по этому до сих пор не придумали идеальную стратегию распределения памяти - она в 95% случаев будет НЕ идеальной, и в 50% случаев - унылым говном.

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

Вот возьми тот же алгоритм Бейкера, который здесь обсуждался. Он отлично работает (хотя и отъедает вдвое больше памяти чем нужно) пока памяти достаточно. Но как только программа подходит к пределу, этот ваш stop'n'copy вешает вашу программу намертво. Не, я согласен, это тоже решение. Но согласись, не всегда оно допустимо.

В итоге, я не смогу написать даже программу управления сливным бачком в унитазе(на сишарпе) - надо СРОЧНО клапан открывать, а оно мне тут мусор собирает. Я понимаю, такое будет происходить не часто, но тем не менее это будет не слишком-то и приятно. Такие дела.

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

что в этом плохого?

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

Знаешь, почему до сих пор не сделали автомобиль для всех? Просто потому, что потребности у всех разные. Кому-то нужен порше, кому-то москвич, а кому-то камаз. И именно по этому до сих пор не придумали идеальную стратегию распределения памяти - она в 95% случаев будет НЕ идеальной, и в 50% случаев - унылым говном.

Отговорка программистов-прокрастинаторов которые изучают Computer Science за деньги фирмы вместо того чтобы решать проблемы фирмы. И при этом не обращают внимания на возможности библиотек, за которые уже фирмой уплачены деньги. То-то Том Кайт когда его нанимают спасать очередной фейловый проект первым делом вычищает унылые костыли заменяющие функциональность которая в сервере уже есть, спроектирована и написана экспертами и хорошо отлажена.

 0 LOAD_FAST                1 (b)
 3 LOAD_FAST                0 (a)
 6 ROT_TWO             
 7 STORE_FAST               0 (a)
10 STORE_FAST               1 (b)

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

Ну то есть ты в универсальной стратегии управления ходом выполнения не видишь ничего плохого, а в универсальной стратегии управления памятью - видишь.

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

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

я знаю. Именно в таких случаях и есть смысл применять сборку мусора. Однако, накой эта сборка например для выделения памяти под строчку, которую никто, кроме этого кода всё равно не будет использовать, да и не сможет, даже если захочет? А таких строчек 99% ваще-то.

Отговорка программистов-прокрастинаторов которые изучают Computer Science за деньги фирмы вместо того чтобы решать проблемы фирмы. И при этом не обращают внимания на возможности библиотек, за которые уже фирмой уплачены деньги. То-то Том Кайт когда его нанимают спасать очередной фейловый проект первым делом вычищает унылые костыли заменяющие функциональность которая в сервере уже есть, спроектирована и написана экспертами и хорошо отлажена.

Ой, да ладно!

И где я к этому призывал? Лично я не вижу ничего плохого например в STL, и прочих библиотеках (в т.ч. и коммерческих), вот только я также не вижу никакой необходимости прибивать гвоздями этот функционал к самому языку. К примеру мне и в голову не придёт писать собственный std::string - именно по озвученной тобой причине. Кроме того, если я уж сподобился юзать например Qt, то я буду юзать также и QString, а не что-либо другое. Но на кой хрен мне сдался String в самом ЯП?? Ну а свой класс(шаблон) my_string я если и буду писать, то только в том случае, если:

1. у меня какие-то особые строки, СОВСЕМ не такие, на которые заточен std::string

2. и кроме того, работа с этими строками занимает ЗНАЧИТЕЛЬНУЮ часть ресурсов.

Если хоть один из этих пунктов не выполнен, я даже думать не стану о своём велосипеде.

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

откуда ему это знать? Каким образом сборщик мусора узнаёт, что данные в переменной можно безболезненно удалять? Если мы используем подсчёт ссылок, то ответ очевиден - тогда, и только тогда, когда счётчик ссылок будет равен 0. С другой стороны, кто этот счётчик увеличивает? Ответ также очевиден - операция «равно» и увеличивает. Вот только ты этого не видишь. И не только не видишь, но и не можешь никак контролировать.

синхронную модель мне никто не навязывает, он только «поощряется», и это хорошо, ибо синхронная модель тупо проще, а стало быть асинхронную следует применять лишь тогда, когда нужно

Вот написание гуя это прямо такая вот редкая задача которая редко нужна, например. И поручают ее обычно только выпускникам Berkley и MIT.

А вот управление памятью в сишарпе такое, какое есть. И ничего я с ним поделать не могу.

Выдели себе для своих CERN-овских рассчетов огромный массив и размести его в статическом scope. GC его трогать не будет.

1) у меня какие-то особые строки, СОВСЕМ не такие, на которые заточен std::string. 2) и кроме того, работа с этими строками занимает ЗНАЧИТЕЛЬНУЮ часть ресурсов.

Ты конечно же можешь привести примеры таких задач? Или это абстрактные построения?

Вот написание гуя это прямо такая вот редкая задача которая редко нужна, например. И поручают ее обычно только выпускникам Berkley и MIT.

а если мне нужен гуй, я его не стану писать. Зачем? Мало что-ли тулкитов на любой вкус? А уж прицепить свою функцию к чекбоксу я как-нибудь осилю.

Выдели себе для своих CERN-овских рассчетов огромный массив и размести его в статическом scope. GC его трогать не будет.

открой наконец Кнута, и узнай о разряжённых матрицах. Причём без всяких GC.Искусство программирования, том 1, 2.2.6

Ну и освежи для себя 2.3.5 оттуда-же, что-бы не говорить ерунды (кстати, Кнут на ассемблере захерачил GC, и ничего - работает даже. Так то)

Ты конечно же можешь привести примеры таких задач? Или это абстрактные построения?

да что-то в голову не приходит ничего интересного. Я же говорю, IRL достаточно STL или средств тулкита. Когда-то давно пришлось делать...

Про сборщик мусора я уже говорил - мне как-то понадобился вырожденный сборщик, который ничего не собирает. Но удаление там тоже таки было (просто память не освобождалась, типа как в tar --delete или CD-R).

На C# может даже попроще было бы кое-где.

Особенно с портами работать. Или с libusb. Или CUDA, ага.

Особенно с портами работать. Или с libusb. Или CUDA, ага.

Ко всему этому есть биндинги даже для Питона. И к CUDA, да.

можно пример бизнес-задач? очередной онлайн магазин? так мне просто интересно, что вы там такое на сишарпе пишете?

Отвечаю с большим лагом, ибо в отпуске был.

Примеров на самом деле много — конкретно сейчас я уже ничего вообще c C# общего не имею, но на предыдущем месте работы, это была довольно крупная аутсорсинг контора (50+ девелоперов, 60+ QA, не считая менеджеров и прочих), было довольно много больших проектов, писавшихся с нуля изначально на C# — кастомизированные системы под конкретных клиентов, для той или иной автоматизации производства / управления, конкретнее сказать не могу, ибо NDA.

Сам при этом я в C# разработке не участвовал, просто общаясь с коллегами из Win отдела, знал чем они живут. «онлайн магазинов» imho у нас там не было ни одного проекта.

Примеров на самом деле много — конкретно сейчас я уже ничего вообще c C# общего не имею, но на предыдущем месте работы, это была довольно крупная аутсорсинг контора (50+ девелоперов, 60+ QA, не считая менеджеров и прочих), было довольно много больших проектов, писавшихся с нуля изначально на C# — кастомизированные системы под конкретных клиентов, для той или иной автоматизации производства / управления, конкретнее сказать не могу, ибо NDA.

много букв. достаточно «писались программы. Детальнее не могу, ибо не в курсе». Не вы конечно в курсе, но в том-то и дело, что вы в курсе того, что «под NDA», а вот про интересующие нас детали (в контексте нашего спора) вас в известность не поставили. А вот они как раз и не под NDA.

Сам при этом я в C# разработке не участвовал, просто общаясь с коллегами из Win отдела, знал чем они живут. «онлайн магазинов» imho у нас там не было ни одного проекта.

онлайн-магазин ИМХО это ооочееень широкий термин, под который наверняка подходит и ваши «кастомизированные проекты». Видел я ваши СУПры, что поделки из 90х на дельфях, что их замену из нашего времени на C#. Просто последние стОят на порядок больше, в них занято на порядок больше быдлокодеров, которых ещё надо синхронизировать/обстирывать Over9000 начальников/уборщиц.

ЗЫЖ можете мне сколько угодно рассказывать, типа «ты не понимаешь!». Не трудитесь. То, чего я не понимаю, никак не относится к исключительности C# для ваших задач, и к NDA НЕ относится. Или относится? В том смысле, что ВЫ подписываете договор с вашими быдлокодерами, о неразглашении того факта, что все ваши проекты можно писать и на PHP, только вдвое быстрее по скорости написания, или на C++/Java с той же скоростью написания, но они будут жрать вдвое меньше ресурсов? Просто быдлокодера владеющего C# найти проще, и стОит он ЧСХ дешевле? По сравнению с C++ или Java? Да и с пхп тоже, если речь идёт об опытном быдлокодере, за плечами которого не только домашняя страничка?

Имхо ставить в один ряд C++ и Java сравнивая их с С# - не совсем конкретно, Java вполне тоже неплохо используется для схожих задач. А вот использовать С++ в проекте, где нет экстримально критичной необходимости экономить каждый байт и каждый такт -решится только менеджер - самоубийца. Затраты на отладку С++ кода при сравнимых уровнях разработчиков - существенно больше.

Да, один конкретный проект я наверное смогу упомянуть, т.к. это не коммерческий проект, и оплачивался из бюджета - это система внутреннего документооборота между медицинскими учреждениями США, - поскольку часто общался в курилке с теми людьми, кто ее разрабатывал, имел некоторое представление о том, какое технологии они используют, итп, какие баги ловят, - о многих проблемах, которые встречаются у С++ разработчиков они просто не вспоминали, хотя те баги что были у них вполне могут быть и в С++, т.е. С# убирает часть головной боли разработчика. Они больше бились уже с «логическими» багами, а не непонятными крешами, вызванными порушенной кучей или доступом к уже не валидному указателю. Я понимаю, для вас это опять всего лишь слова, но факт остается фактом - новые проекты редко используют С++

Имхо ставить в один ряд C++ и Java сравнивая их с С# - не совсем конкретно, Java вполне тоже неплохо используется для схожих задач. А вот использовать С++ в проекте, где нет экстримально критичной необходимости экономить каждый байт и каждый такт -решится только менеджер - самоубийца. Затраты на отладку С++ кода при сравнимых уровнях разработчиков - существенно больше.

разве кто-то запрещает использовать смешанную архитектуру? Почему не написать критичные куски кода на C++ (или даже C), а остальное на ЯП более высокого уровня? Ну например как написан mercurial, который работает ничуть не медленнее git'а, который запилен в основном на C? Несмотря на вердикт анонимуса, что питон - тормозное УГ.

о многих проблемах, которые встречаются у С++ разработчиков они просто не вспоминали, хотя те баги что были у них вполне могут быть и в С++, т.е. С# убирает часть головной боли разработчика. Они больше бились уже с «логическими» багами, а не непонятными крешами, вызванными порушенной кучей или доступом к уже не валидному указателю

порушенная куча или невалидные указатели - совсем НЕ типичная проблема C++. В C++ ты можешь реализовать любую стратегию работы с памятью, и если ты выбрал самую примитивную, что идёт по дефолту, и которая ещё и самая быстрая - ССЗБ. У любой стратегии есть свои минусы, минус самой примитивной очевидно в том, что ВСЕМ кодерам придётся следить за целостностью кучи, и валидностью указателей. В т.ч. и тем, которые должны заниматься совершенно другими проблемами. Очевидно, в таком случае будет оптимальна стратегия сборки мусора, а возможно даже какая-то своя стратегия.

Я понимаю, для вас это опять всего лишь слова, но факт остается фактом - новые проекты редко используют С++

проблема в том, что большинство разработчиков попросту не знает C++. Ещё недавно авторитетные аналитеги с ЛОРа доказывали мне, что в C++ даже невозможна примитивная сборка мусора. Но это таки проблема аналитегов, а совсем не C++.

Порушенная куча и не валидные указатели - это так, для примера просто.

Впрочем вы своими словами только подтверждаете мои мысли, - разработка на шарпе требует меньше затрат, т.к. знать С++ досконально - не так просто, но необходимо для написания нормально когда. С С#-ом нет такой тучи подводных камней про которые надо быть всегда в курсе. А уж сообщения плюсовых компиляторов на пару экранов при ошибках - повергнут в ужас любого человека не пишущего на С++ (хотя может в новых компиляторах дела и лучше обстоят, по работе вынужден использовать VS 2008, а свободного времени «кодить для себя» - давно нет, хватает только на неспешное почитывание книг. Сейчас вот как раз в отпуске почитал немного Троелсена, и надо сказать применял мнение о С# - не такой плохой язык, имеет много вкусностей, которые в полюсах или появились только в C++11 или вообще скорее всего никогда не появятся (LINQ например или конструкции вида yield return). При наличии мозга у разработчика, неплохой язык .

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

Для написания хорошего кода требуется хорошее знание ЯП. Всегда ваш К.О. С другой стороны, подводных камней в C++ не так уж и настолько много, и они (в отличие от C#) досконально изучены, и подробно расписаны. Любой быдлокодер знает про синдром type-void*-type, и про то, что деструкторы надо делать витртуальными (быдлокодер правда об этом «забывает», за что и наказан постоянной отладкой своего быдлокода, и разнообразными крешами).

А уж сообщения плюсовых компиляторов на пару экранов при ошибках - повергнут в ужас любого человека не пишущего на С++

C++ очень гибкий ЯП, и по незнанию можно там накрутить такую бредятину, для объяснения бредовости которой можно написать целую книгу. Не думаю, что это минус. Просто не используй ту идиому, которую ты ниосилил понять на все 100%.

Сейчас вот как раз в отпуске почитал немного Троелсена, и надо сказать применял мнение о С# - не такой плохой язык, имеет много вкусностей, которые в полюсах или появились только в C++11 или вообще скорее всего никогда не появятся (LINQ например или конструкции вида yield return). При наличии мозга у разработчика, неплохой язык .

ИМХО какие-то очередные маздайные расширения, которые попросту не нужно вводить в ЯП. Если они тебе нужны - реализуй их сам. Это как с распределителем памяти - мне не нужен «самый лучший», мне нужен самый простой, и возможность заменить на свой, с картами и девками.

То же распределение памяти должно быть закопано где-то внутри самых базовых классов, и большинство кодеров НЕ должны о нём задумываться. Это же касается работы с итераторами и работы с СУБД - кодер(ы) не должны об этом думать, разве что при реализации этих итераторов.

type-void-type и виртуальные деструкторы - это имхо мелочи, бывают вещи и повеселее. Особенно когда оказывается что каждый компилятор по своему понимает некоторые аспекты языка. Сколько невров я убил, прокручивая boost::gil к нашему проекту (взамен менее эффективному коду, что был ранее), добрая часть примеров из мануала просто не компилируется в 2008 студии, показывая ошибки экранов на 10 :) (в буквальном смысле). Хотя это проблема не сколько языка, сколько компилятора, но все же.

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