Comments 130
> Ммм… Супер язык… Дайте мне кривой велосипед, состоящий чуть более чем полностью из других кривых велосипедов, пожалуйста!
fixed.
fixed.
"… Сейчас занимаются тем, что делят проект на две взаимодействующие части: интерфейсную и обрабатывающую от нее запросы. Идея в том, что легкий интерфейс остается всегда живой..." — так вообще нужно делать всегда и везде, независимо от языка и платформы.
А на счет подвисаний в пару секунд во время очистки мусора — так в последнем .NET этот процесс вроде бы фоновый и основное приложение не блокирует.
А на счет подвисаний в пару секунд во время очистки мусора — так в последнем .NET этот процесс вроде бы фоновый и основное приложение не блокирует.
А на счет подвисаний в пару секунд во время очистки мусора — так в последнем .NET этот процесс вроде бы фоновый и основное приложение не блокирует.
Т.е. GC работает в отдельном потоке?
У него и раньше была возможность работать в отдельном потоке:
А четвертом .Net ввели фоновую сборку мусора:
Отсюда
При сборке мусора рабочей станции можно включить параллельную сборку мусора, что позволит потокам работать параллельно с выделенным потоком, выполняющим сборку мусора, в течение большей части длительности сборки мусора.Этот вариант влияет только на сборки мусора для поколения 2, сборки для поколений 0 и 1 всегда выполняется непараллельно, так как они заканчиваются очень быстро.
Параллельная сборка мусора выполняется в выделенном потоке.По умолчанию среда CLR выполняет сборку мусора рабочей станции с выключенной параллельной сборкой мусора.Это справедливо для однопроцессорных и многопроцессорных компьютеров.
А четвертом .Net ввели фоновую сборку мусора:
Начиная с .NET Framework 4, параллельная сборка мусора заменяется фоновой сборкой мусора.
Отсюда
У GC вообще такая специфика. Ему необходимо зафризить исполнение основной программы на то время пока он с мусором разбирается. Такая проблема есть что у Явовского что у .net овского. И если к моменту когда GC проснулся мусора оказалось оч много, то он будет его долго убирать.
Посему если не хотите фризов, то прибивайте не нужные объекты по старинке ручками. :)
Посему если не хотите фризов, то прибивайте не нужные объекты по старинке ручками. :)
В чем тогда смысл GC, если ручками? :)
А вообще smart pointers очень достойная замена этим всем GC, я на С++ о памяти просто не задумываюсь, достаточно в нужных местах расставить умные указатели… к тому же умные указатели работают предсказуемо и всегда одинаково…
А вообще smart pointers очень достойная замена этим всем GC, я на С++ о памяти просто не задумываюсь, достаточно в нужных местах расставить умные указатели… к тому же умные указатели работают предсказуемо и всегда одинаково…
А что это такое? Если вкратце?
Если вкратце, проблема освобождения памяти в C++ в современном мире не особенно актуальна. Вместо
Obj *p = new Obj;
любой нормальный программист сейчас пишет что-то вроде
shared_ptr<Obj> p = new Obj;
При этом shared_ptr — это объект, который уничтожит Obj самостоятельно при выходе за границы области видимости.
Obj *p = new Obj;
любой нормальный программист сейчас пишет что-то вроде
shared_ptr<Obj> p = new Obj;
При этом shared_ptr — это объект, который уничтожит Obj самостоятельно при выходе за границы области видимости.
Ага… про циклические ссылки не забываем только. Ну и по мне так лучше выстраивать иерархии объектов, чтобы родители при удалении заботились об удалении всех потомков.
ИМХО, если у вас появились циклические ссылки, то что-то в архитектуре ооочень не так :).
В подавляющем числе случаев указателем владеет только один объект одновременно, при этом выигрыш по сравнению с auto_ptr заключается в том, что в некоторых местах можно использовать временные локальные копии указателя.
Если же указателем владеет много объектов, то такой объект обычно просто предоставляет некоторый функционал своим владельцам, при этом сам он своими владельцами пользоваться даже косвенно не должен…
Если все же очень хочется, для разрыва цикла надо использовать weak_ptr…
p.s. способов прострелить себе ногу всегда было много :)
В подавляющем числе случаев указателем владеет только один объект одновременно, при этом выигрыш по сравнению с auto_ptr заключается в том, что в некоторых местах можно использовать временные локальные копии указателя.
Если же указателем владеет много объектов, то такой объект обычно просто предоставляет некоторый функционал своим владельцам, при этом сам он своими владельцами пользоваться даже косвенно не должен…
Если все же очень хочется, для разрыва цикла надо использовать weak_ptr…
p.s. способов прострелить себе ногу всегда было много :)
Двусвязаный список. Вроде типичная структура.
Если Вы имеете в виду
То за такое надо отрывать руки, потому что во-первых есть STL, где все это уже реализовано, а во вторых такая структура нелогична.
Поясню нелогичность:
В примере получается что prev владеет next, а next владеет prev (отсюда и баг).
Однако, если вы проведете анализ отношений владения, у Вас получится следующее:
Всеми элементами владеет список как объект. Список как объект это корневой элемент плюс дополнительная информация (например, размер списка), следовательно 1й (корневой) элемент должен владеть всеми последующими элементами. Т.к. структура всех элементов должна быть одинакова, то получается, что если строить список на shared_ptr, то должно быть так:
struct foo
{
shared_ptr<foo> prev;
shared_ptr<foo> next;
int very_usefull_value;
};
То за такое надо отрывать руки, потому что во-первых есть STL, где все это уже реализовано, а во вторых такая структура нелогична.
Поясню нелогичность:
В примере получается что prev владеет next, а next владеет prev (отсюда и баг).
Однако, если вы проведете анализ отношений владения, у Вас получится следующее:
Всеми элементами владеет список как объект. Список как объект это корневой элемент плюс дополнительная информация (например, размер списка), следовательно 1й (корневой) элемент должен владеть всеми последующими элементами. Т.к. структура всех элементов должна быть одинакова, то получается, что если строить список на shared_ptr, то должно быть так:
struct foo
{
weak_ptr<foo> prev;
shared_ptr<foo> next;
int very_usefull_value;
};
> То за такое надо отрывать руки, потому что во-первых есть STL.
С этим нельзя не согласиться.
Вполне себе логичным для двусвязанного списка хранить как указатель на голову, так и на хвост…
А в целом, посмотрите какие вы логические рассуждения сделали для выбора типа указателей. И это с учётом того, что задача простая. Разве оно того стоит?
Да и к томуже, GC временами позволяет повысить производительность за счёт того, что освобождение может происходить в другом процессе и системные вызовы дёргаются более кучно.
С этим нельзя не согласиться.
Вполне себе логичным для двусвязанного списка хранить как указатель на голову, так и на хвост…
А в целом, посмотрите какие вы логические рассуждения сделали для выбора типа указателей. И это с учётом того, что задача простая. Разве оно того стоит?
Да и к томуже, GC временами позволяет повысить производительность за счёт того, что освобождение может происходить в другом процессе и системные вызовы дёргаются более кучно.
> Вполне себе логичным для двусвязанного списка хранить как указатель на голову, так и на хвост…
Согласен, но это не должны быть умные указатели с подсчетом ссылок… Если бы я писал двусвязный список next был бы auto_ptr, а prev — самый обыкновенный.
Насчет рассуждения… Там больше текста, чем мыслей :) Я когда вижу next и prev, объявленные как shared_ptr, у меня сразу красная лампочка в голове загорается, еще до того, как я подумаю о чем-то :) Еще раз повторюсь, в правильно разработанной системе вопрос «кому отдать указатель во владение?» тривиальна.
> Да и к томуже, GC временами позволяет повысить производительность за счёт того, что освобождение
> может происходить в другом процессе и системные вызовы дёргаются более кучно.
Не согласен :)
1. Сама процедура сборки мусора задача трудоемкая, т.к. сборщику мусора надо проанализировать граф зависимостей на предмет «недостижимых областей», да еще и в условиях когда этот граф постоянно меняется…
2. Для того, чтобы дергать системные вызовы более кучно в С++ используется Loki::SmallObjAllocator (системные вызовы будут происходить для сравнительно больших блоков по 4Кб). Такая оптимизация имеет смысл, когда программа работает с множеством маленьких объектов и дает выигрыш до 20 раз по сравнению с new. В качестве дополнительного бонуса Loki::SmallObjAllocator позволяет уменьшить количество кэш-промахов.
Согласен, но это не должны быть умные указатели с подсчетом ссылок… Если бы я писал двусвязный список next был бы auto_ptr, а prev — самый обыкновенный.
Насчет рассуждения… Там больше текста, чем мыслей :) Я когда вижу next и prev, объявленные как shared_ptr, у меня сразу красная лампочка в голове загорается, еще до того, как я подумаю о чем-то :) Еще раз повторюсь, в правильно разработанной системе вопрос «кому отдать указатель во владение?» тривиальна.
> Да и к томуже, GC временами позволяет повысить производительность за счёт того, что освобождение
> может происходить в другом процессе и системные вызовы дёргаются более кучно.
Не согласен :)
1. Сама процедура сборки мусора задача трудоемкая, т.к. сборщику мусора надо проанализировать граф зависимостей на предмет «недостижимых областей», да еще и в условиях когда этот граф постоянно меняется…
2. Для того, чтобы дергать системные вызовы более кучно в С++ используется Loki::SmallObjAllocator (системные вызовы будут происходить для сравнительно больших блоков по 4Кб). Такая оптимизация имеет смысл, когда программа работает с множеством маленьких объектов и дает выигрыш до 20 раз по сравнению с new. В качестве дополнительного бонуса Loki::SmallObjAllocator позволяет уменьшить количество кэш-промахов.
habrahabr.ru/blogs/htranslations/95063/
Вот тут, пункт 7. Меньше сущностей — меньше мест напортачить. А если есть возможность напортачить — напортачишь. Хотя, это в основном вопрос умения и предрасположенностей разработчика.
> Не согласен :)
Там не просто так было написано «временами», говорят раз в год и палка стреляет. Вообще, прирост может быть в случае если очень активно создаются и разрушаются мелкие объекты (современные сборщики с поколениями работают очень неплохо). И в случае если сборщик мусора будет бежать на отдельном ядре процессора.
Вот тут, пункт 7. Меньше сущностей — меньше мест напортачить. А если есть возможность напортачить — напортачишь. Хотя, это в основном вопрос умения и предрасположенностей разработчика.
> Не согласен :)
Там не просто так было написано «временами», говорят раз в год и палка стреляет. Вообще, прирост может быть в случае если очень активно создаются и разрушаются мелкие объекты (современные сборщики с поколениями работают очень неплохо). И в случае если сборщик мусора будет бежать на отдельном ядре процессора.
Помойму, у вас сильно устарели данные… Java, по крайней мере, уже давно так умеет…
Уж слишком откровенная реклама :-(
Где? :)
Блог компании Интел -> Статья «Скачивайте Parallel Studio, смотрите»
Каждый язык имеет свои плюсы и минусы.
А в статье кроме минусов C# и ссылки на Parallel Studio ничего больше нет.
Каждый язык имеет свои плюсы и минусы.
А в статье кроме минусов C# и ссылки на Parallel Studio ничего больше нет.
Высказал исключительно свое мнение. И совершенно четно, ибо в Intel не работаю. Чем обсуждать всякое новомодное, гораздо разумнее сейчас смотреть на то, что делает и предлагает разработчикам Intel. Просто мало еще кто понимает, что параллельность в программах намного важней, чем например красота языка и прочее.
Тогда пожалуйста, в следующий раз приведите плюсы/минусы обоих сред.
Чтобы было честное и объективное сравнение.
В дополнение, думаю, что новая версия компилятора C# будет поддерживать параллельную обработку (если уже не поддерживает).
Чтобы было честное и объективное сравнение.
В дополнение, думаю, что новая версия компилятора C# будет поддерживать параллельную обработку (если уже не поддерживает).
«Просто мало еще кто понимает, что параллельность в программах намного важней, чем например красота языка и прочее. „
Вы, наверное, не в курсе, что в “новомодном» .net 4 есть отдельное пространство имен для упрощения работы с параллельными вычислениями?
Вы, наверное, не в курсе, что в “новомодном» .net 4 есть отдельное пространство имен для упрощения работы с параллельными вычислениями?
Вы думаете, что писать параллельную программу будет проще с использованием .net 4, чем с использованием скажем TBB, OpenMP и так далее? Будет одинаково! И здесь важнее набор различного инструментария. И как я понимаю, Parallel Studio станет лидером в этом.
«Будет одинаково» — значит, выбор будет по прочим возможностям инструмента, языка и платформы.
В .net есть свои достоинства, оправдывающие его выбор при сравнении с другими языками. Соответственно, Parallel возвращает нам паритет средств разработки, давая нам возможности (легко) работать с параллельными вычислениями там, где они уже работают по каким-то другим причинам.
Так что не надо раз за разом переводить стрелки на Intel. На Parallel Studio свет клином не сошелся.
В .net есть свои достоинства, оправдывающие его выбор при сравнении с другими языками. Соответственно, Parallel возвращает нам паритет средств разработки, давая нам возможности (легко) работать с параллельными вычислениями там, где они уже работают по каким-то другим причинам.
Так что не надо раз за разом переводить стрелки на Intel. На Parallel Studio свет клином не сошелся.
.net и c# уже больше 8-ми лет, а для многих это всё ещё «новые модные языки».
так-то все правда. Но вы забыли еще один момент, не относящийся непосредственно к процессу разработки. Это стоимость разработчиков. На данный момент у нас с заказчиком идет активное обсуждение инструмента разработки. Я считаю, что надо взять Qt/C++, а другие советчики говорят про Java. Нечего возразить… явисты дешевле.
Что интересно, вновь получается что язык второстепенен. :)
о том и речь
Первостепенным скорее является платформа. Qt вот или .Net или еще что. То есть уже не просто ЯП, а ЯП плюс библиотеки и средства разработки. Большие проекты на Qt обычно состоят из ядра на С++ и некоторого количества кода на Javascript'е и доля этого кода будет неизбежно увеличиваться в будущем. В будущем же мелкие прожки народ и вовсе будет полностью на js делать.
Что-то мне говорит, что у большинства крупных .net проектов ядро тоже на вполне обычном, не managed C++ написано.
Что-то мне говорит, что у большинства крупных .net проектов ядро тоже на вполне обычном, не managed C++ написано.
А в разных тредах интерфейс и обработчик сделать не пробовали? Всё-таки мне кажется это кривизна рук программистов, а не языка. На плюсах тоже можно написать так, что всё будет глючить и тормозить.
Даже не имеет смысла обсуждать их достоинства и недостатки. Стоит познакомиться с новыми возможностями и не более.
Действительно. Давайте стоять на месте. Любую технологию и язык можно использовать неправильно и тем самым подпортить себе жизнь. А при правильном подходе можно сэкономить в затраченных ресурсах грандиозно.
Имел дело с серверными частями real-time MMORPG в одном случае на C++, в другом на Python: небо и земля. Думаю не стоит пояснять в каком случае мы получили буст.
Расскажите, пожалуйста. Тут мы обсуждаем политические и организационные моменты выбора инструмента. Я так подозреваю, с набором спецов питонистов у вас не было никаких проблем. Какие преимущества вы получили от С++?
Хорошего питонера найти сложнее чем хорошего C++ спеца. Я бы сказал сильно сложнее. Но это с лихвой покрывается скоростью разработки на Python’e. В течение года работы 3,5 питонера (в среднем) проделали работу, которую 5 C++ человек делало почти два года. Это, понятно, грубое сравнение, основанное на сравнении возможностей сервера в разных играх, но о чём-то это надеюсь говорит.
А потом настанет день когда питоний сервак начнет умирать под нагрузкой, а денег на новое железо не предусмотрели… Вот и придется с профилировщиком лазить и переписывать узкие места на си или плюсах
Во-первых, узкое место — это не весь проект, это ограниченное количество мест. Их не грех и на C/C++ переписать в случае реальной необходимости.
Во-вторых, stress-тестирование проводится заранее и умирать внезапно никто не собирается.
В-третьих, как уже 1000 раз показывала практика, ботлнеки зачастую оказываются там, где язык не важен: например, доступ до внешнего хранилища или брут-форс алгоритм, там где не мешало бы использовать что-то более умное.
Во-вторых, stress-тестирование проводится заранее и умирать внезапно никто не собирается.
В-третьих, как уже 1000 раз показывала практика, ботлнеки зачастую оказываются там, где язык не важен: например, доступ до внешнего хранилища или брут-форс алгоритм, там где не мешало бы использовать что-то более умное.
Сейчас вроде «Hardware is Cheap, Programmers are Expensive» т.е., купить новую железку значительно дешевле и быстрее, чем оплачивать 1-2 мясаца работы разработчика.
Возможно, для приложений которые нельзя масштабировать это не так, но они в любом случае обречены, потому что рано или поздно достигнут предела будь они хоть на ассемблере написаны.
Возможно, для приложений которые нельзя масштабировать это не так, но они в любом случае обречены, потому что рано или поздно достигнут предела будь они хоть на ассемблере написаны.
Поэтому раньше на Луну летали с примитивными «калькуляторами», а сейчас не могут.
Это уже из области философии и прочего, я говорю о том как есть в реальном мире.
Мне, как заказчику проекта, главное что бы я
а. Получил качественный продукт, причем большинство заказчиков вообще никак не волнует «как оно там все внутри устроено». И как бы нам программистам не было обидно, показав им строчки, которыми можно гордиться на наших форумах и блогах, мы не получим возгласов радости «ой смотрите он 10 строк кода на C# в 1 строку на С++ засунул, вот молодчина!!»
б. Потратил только то количество финансов, которым я обладаю(ну нету больше), и желательно сэкономил. Так что если дешевле купить компы и написать на языке более высокого уровня, то наверное это мой вариант.
в. И последнее, но не менее важное, получить поддержку потом всего этого добра и масштабируемость. Иначе, не дай бог, с первоначальным исполнителем что-то случится и придется переписывать. Ну а с масштабируемостью думаю все и так ясно, какой бы супер быстрый код не был у него всегда есть планка в N запросов в секунду(если говорить, допустим, о веб приложении).
Мне, как заказчику проекта, главное что бы я
а. Получил качественный продукт, причем большинство заказчиков вообще никак не волнует «как оно там все внутри устроено». И как бы нам программистам не было обидно, показав им строчки, которыми можно гордиться на наших форумах и блогах, мы не получим возгласов радости «ой смотрите он 10 строк кода на C# в 1 строку на С++ засунул, вот молодчина!!»
б. Потратил только то количество финансов, которым я обладаю(ну нету больше), и желательно сэкономил. Так что если дешевле купить компы и написать на языке более высокого уровня, то наверное это мой вариант.
в. И последнее, но не менее важное, получить поддержку потом всего этого добра и масштабируемость. Иначе, не дай бог, с первоначальным исполнителем что-то случится и придется переписывать. Ну а с масштабируемостью думаю все и так ясно, какой бы супер быстрый код не был у него всегда есть планка в N запросов в секунду(если говорить, допустим, о веб приложении).
Это всё понятно, я о другом. Компьютерные мощности не заменяют мозги. Как переход на цифровую фотографию не увеличивает число шедевров.
А лунную программу действительно закрыли, под силу.
А лунную программу действительно закрыли, под силу.
К сожалению (или к счастью, тут каждый сам решает), заменяют.
Не знаю о каком реальном мире вы говорите, но я наблюдаю тысячи студентов, которые закладывают вычислительные задачи в FDTD или FEM методы, получают неизвестно что и выкатывают это как супер-пупер результаты пользуясь головой только для поедания пончиков во время ожидания результатов с кластеров.
Студенты != профессиональные программисты. Я когда студентом был, много чего делал, о чем сейчас без смеха/слез не вспомнишь. И вычислительные задачи не лучший пример, там, может быть, и имеет смысл оптимизировать все до самого немогу, иначе считать будет вечность.
Но в статье вроде шел разговор о простых приложениях, у которых есть заказчик, бюджет и прочие требования.
Но в статье вроде шел разговор о простых приложениях, у которых есть заказчик, бюджет и прочие требования.
Три сферических коня в вакууме обогнали двух других таких же коней :) Это не ответ, почему один ЯП лучше другого. Несколько лет назад я решил попробовать применять питон в своей работе. Ради интереса я написал одну и туже программу (решение задачи разложения по плоским волнам) на C++ и на питоне (до этого использовал матлаб). Так вот на плюсах получилось и быстрее по разработке и быстрее по выполнению. Профита питона не обнаружил.
Так что всё относительно :)
Так что всё относительно :)
Не спорю, оперирую конями: не приходит в голову объективная метрика.
Однако в вашем случае эксперимент был, насколько я понимаю, сильно короче и нишевее. Поэтому мне кажется однозначный вывод из него сделать ещё сложнее.
Однако в вашем случае эксперимент был, насколько я понимаю, сильно короче и нишевее. Поэтому мне кажется однозначный вывод из него сделать ещё сложнее.
Не спорю, оперирую конями: не приходит в голову объективная метрика.
Потому что её нет. Конечно есть некие экстремальные ситуации, что вычматы не надо писать на javascript, а интерфейс на ассемблере. Всё от человека зависит. Заятлого питониста сточка
for (std::list<acoustic::IElasticMedium*>::iterator _=media_list.begin();
_!=media_list.end(); ++_)
delete *_;
убьёт наповал, а по мне просто и понятно :)
Я заятлый питонер и мне ваш снипет кажется простым и понятным. Непонятно только почему переменная-итератор названа _, а оператор сравнения != не отделён пробелами вокруг. Попутать хотели? :)
Пугать не хотел, просто копирнул первую попавшуюся строчку с соседнего экрана :) А переменные цикла у меня частенько _ или __, если их две. Так как она действует всего несколько строк вниз, то зачем расходовать время на придумывание обозначения. Стандартная i у меня мнимая единица.
О_о надеюсь, мне не придётся работать с таким кодом.
Кстати, меня пример не «убивает наповал», а просто вызывает отвращение :) Весь этот бардак чтобы просто сказать «for p in list»…
Кстати, меня пример не «убивает наповал», а просто вызывает отвращение :) Весь этот бардак чтобы просто сказать «for p in list»…
Я ж говорю дело вкуса. Мне как раз приятно, что я вижу все внутренности контейнера. А вот передавать каждый раз self, писать __init__, наци-форматинг и отсутствие приватных функций у меня вызывает отвращение :P
Вкус вкусом, но с подчерками имхо перебор :) __=++_++-__;
Мне тоже не всё нравится в питоне, но это не сравнить с ужасами C++ (и тем более STL). У меня отвращение вызывает не стиль (мне без разницы, как называть конструктор или сколько ставить пробелов), а сложность восприятия и написания, отладки, и т.п.
Мне тоже не всё нравится в питоне, но это не сравнить с ужасами C++ (и тем более STL). У меня отвращение вызывает не стиль (мне без разницы, как называть конструктор или сколько ставить пробелов), а сложность восприятия и написания, отладки, и т.п.
Со следующего года в С++ будет свой foreach :)
За итератор с названием _ убил бы! Называйте уж понятно it или elastic_iterator;
Он же действует всего одну строчку delete *_;
Тем более внутренние переменные принято начинать с _.
Тем более внутренние переменные принято начинать с _.
Не такая уж она и внутренняя обычно, заботится о читаемости всё равно стоит. А все эти итераторы с названием _, всякие ужасы типа _,__,___ очень уж в тоску вгоняют.
Хуже только венгерская нотация, от вида которой выть хочется.
Хуже только венгерская нотация, от вида которой выть хочется.
Венгерская нотация изначально была вполне себе удобна и полезна, просто её извратили.
Проблема с подвисанием программы звучит либо как проявления фундаментального недостатка Си-шарп, в существование которого как-то не верится, либо как ошибка в проектировании и/или реализации конкретной программы.
Кому был бы нужен Си-шарп если бы он действительно не мог адекватно работать с кодом объемом больше некоторой величины?
Кому был бы нужен Си-шарп если бы он действительно не мог адекватно работать с кодом объемом больше некоторой величины?
Нужен и удобен одной группе людей, не означает, что не имеет узкие места для других. Если сравниваться язык с лекарством, то информация на упаковке неверна. Там есть то, что он лечит, но не написаны противопоказания. :) Вот кстати, как сейчас наконец в C# можно стало нормально работать с массивами, состоящими из более чем 2 Gb элементов, или все еще нет? :)
blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx
blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx
+1
Сколько на .net (кстати, шарп тут не при чем, сбор мусора — прикол CLR) не писал, никогда такого не видел — чтобы из-за GC тормозил интерфейс. Понятно, что телепатически проблему не диагностируешь, но скорее всего — ошибка архитектуры.
В частности, тот факт, что память управляется сборщиком, еще не означает, что не надо делать Dispose там, где он есть.
Сколько на .net (кстати, шарп тут не при чем, сбор мусора — прикол CLR) не писал, никогда такого не видел — чтобы из-за GC тормозил интерфейс. Понятно, что телепатически проблему не диагностируешь, но скорее всего — ошибка архитектуры.
В частности, тот факт, что память управляется сборщиком, еще не означает, что не надо делать Dispose там, где он есть.
«Поскольку процесс высвобождения памяти неконтролируем, то временами в работе приложения стали возникать паузы в 1-2 секунды, в течении которых система разбирается с памятью, что освободить, что нет.» — меня охватывает странное чувство, что разработчикам нужно было лучше почитать про GC, кучи и тд. дотНета, и разобраться как это все работает работает, а не оставлять всё на откуп системе и не говорить «процесс высвобождения памяти неконтролируем», тогда бы и проблем было меньше.
Я прикинусь на секунду глупеньким. А как же реклама, где обещали, что все будет само!!?? :)
«все будет само» — для среднестатистического проекта, где нет особой нагрузки (хотя прогать тоже надо правильно), вот там все будет «само» и вы не увидите проблем. А вот в высоконагруженных системах или в мобильных устройствах(щас ими занимаюсь), если выбран C#.NET, то тут надо просто создать правильную архитектуру и прогать думая о ресурсах.
Позвольте поинтересоваться: какой именно достигнут придел в том проекте?
Функциональный, нагрузочный, объем кода, объем данных…
Почему спрашиваю — мы с партнерами разрабатываем проект на с#, исходники проекта более 20тыщ строк * 100+ пользователей * БД 10-400к записей в таблицах (база 9гб). Проект на сервере иногда ест до 3гб памяти. Проект клиент-серверный (я так понял у вас вин-формы).
Ничего подобного (зависания) не встречали.
Функциональный, нагрузочный, объем кода, объем данных…
Почему спрашиваю — мы с партнерами разрабатываем проект на с#, исходники проекта более 20тыщ строк * 100+ пользователей * БД 10-400к записей в таблицах (база 9гб). Проект на сервере иногда ест до 3гб памяти. Проект клиент-серверный (я так понял у вас вин-формы).
Ничего подобного (зависания) не встречали.
Если у вас основная часть обработки данных идет на сервере, а на клиенте только окошки рисуются, то вы и не увидите фризов никогда.
«Фризы» были бы при ответах сервера, причем для практически всех клиентов.
Приложение очень активно использует AJAX > .NET. Таких задержек в принципе не наблюдаем уже за более 1.5 года.
Приложение очень активно использует AJAX > .NET. Таких задержек в принципе не наблюдаем уже за более 1.5 года.
В таких местах как MIT писали на высокоуровневых языках уже в начале 60-х, но многие компании продолжали писать на машинных кодах вплоть до 80-х. Бьюсь об заклад, что многие продолжали писать на машинных кодах до тех пор, пока процессор, словно бармен, собирающийся закрыть бар и пойти домой, не выдворил их прочь, переключившись на набор команд RISC.
Lisp: побеждая посредственность
Было сломано много копий. Вроде и не разработчики виноваты, а делать что-то надо. Сейчас занимаются тем, что делят проект на две взаимодействующие части: интерфейсную и обрабатывающую от нее запросы.
Уфф… «Совершенный код» Макконнелла был написан в 93-м году, «Искусство программирования» Кнута — так вообще в 68-м.
Мне одному кажется, что в проблеме, иллюстрирующей второй момент, виноваты ССЗБ, а не выбранный язык программирования?
PS Я не пытаюсь оспорить второй момент.
Насчёт C# и подвисаний — классическая ситуация.
Вот только причина не в «страшном тормозном GC», а (пардон) в уровне разработчиков.
Автоматическое управление памятью не значит, что об управлении последней можно вообще забыть.
Тем более это важно для проекта сложности выше среднего.
Ну, а если вдруг появились мысли в стиле «фу, какой гадкий этот C#», уточню — всё это актуально и для Java и практически для любой системы с управлением памятью.
Вот только причина не в «страшном тормозном GC», а (пардон) в уровне разработчиков.
Автоматическое управление памятью не значит, что об управлении последней можно вообще забыть.
Тем более это важно для проекта сложности выше среднего.
Ну, а если вдруг появились мысли в стиле «фу, какой гадкий этот C#», уточню — всё это актуально и для Java и практически для любой системы с управлением памятью.
Согласен, GC работают хорошо для подавляющего большинства систем, если начинаются проблемы — вместо заявлений «gc сакс, какие плохие java/.net» стоит просто настроить GC. Не знаю, как в .net, в java «крутилок» для GC хватает.
Ну и помнить про GC надо при проектировании архитектуры — а то народ создает JVM с хипом в 10Гб для кэша, а потом удивляются — «а что это у нас периодически кэш медленно отвечает», в то время как GC методично проходится по всем 10 гигам объектов.
Ну и помнить про GC надо при проектировании архитектуры — а то народ создает JVM с хипом в 10Гб для кэша, а потом удивляются — «а что это у нас периодически кэш медленно отвечает», в то время как GC методично проходится по всем 10 гигам объектов.
Лично я предпочитаю избегать подобных проблем на этапе проектирования/написания кода.
Привязываться к конкретной настройке GC как-то… не нравится в общем.
И не сказал бы что я «не умею их готовить». Не нравится и всё тут.
Ну а проектирование вообще отдельная тема.
В большинстве (чужих) проектов, что довелось видеть, проектированием занимались люди практически не знакомые с платформой.
В результате, делалось всё это лишь для того, чтобы потом с гордостью сказать «над проектированием системы 3 месяца работали наши лучшие непонятно-кто».
… а потом ещё 3 месяца программисты придумывали сами-знаете-какие названия этим непонятно-кому.
В конце-концов плюнули и втихую за месяц «перепроектировали» всё сами, но дабы соотвествовало «изначальному проекту».
Лично мне так и не довелось поработать в _настоящей_ связке менеджер-архитектор-разработчик.
Вот так. «Грустнично-реалистично»…
Привязываться к конкретной настройке GC как-то… не нравится в общем.
И не сказал бы что я «не умею их готовить». Не нравится и всё тут.
Ну а проектирование вообще отдельная тема.
В большинстве (чужих) проектов, что довелось видеть, проектированием занимались люди практически не знакомые с платформой.
В результате, делалось всё это лишь для того, чтобы потом с гордостью сказать «над проектированием системы 3 месяца работали наши лучшие непонятно-кто».
… а потом ещё 3 месяца программисты придумывали сами-знаете-какие названия этим непонятно-кому.
В конце-концов плюнули и втихую за месяц «перепроектировали» всё сами, но дабы соотвествовало «изначальному проекту».
Лично мне так и не довелось поработать в _настоящей_ связке менеджер-архитектор-разработчик.
Вот так. «Грустнично-реалистично»…
Хочу дополнить Ваш вывод. Не только «Относиться к новым модным языкам следует спокойно», но и «не пытайтесь оценивать новый язык предварительно не выкинув начисто знания о вашем любимом языке программирования из головы».
Что бы интерфейс не подвисал надо выполнять тяжеловесные процессы в отдельном потоке а не в основном — как в C# так и в C++
Только одному мне показалось, что по сути в статье была описана проблема со сборщиком мусора, одна единственная неудачная попытка ее решения в лоб и сделанный из этого вывод, что C# непригоден для написания больших проектов?
К сожалению, видимо никто так и не понял, что я хотел сказать:
а) Язык не может заменяет работу мозга по решению задачи. И не стоит бездумно вестись на новые новшества. И C# был в качестве примера. Я ведь не критикую C#. Я говорю, что нельзя просто взять и положиться на «авось должно теперь все само».
б) Лучше работать с тем, что давно есть и что активно развивается (привел в качестве примера параллельные технологи, развиваемые Intel). А не брать очередное супер новое, что обещает обеспечить, скажем ту же параллельность. Не верю.
а) Язык не может заменяет работу мозга по решению задачи. И не стоит бездумно вестись на новые новшества. И C# был в качестве примера. Я ведь не критикую C#. Я говорю, что нельзя просто взять и положиться на «авось должно теперь все само».
б) Лучше работать с тем, что давно есть и что активно развивается (привел в качестве примера параллельные технологи, развиваемые Intel). А не брать очередное супер новое, что обещает обеспечить, скажем ту же параллельность. Не верю.
Так я не понял, а сколько лет Intel Parallel Studio, что она «давно есть и активно развивается»?
… а, да. «Intel announced Parallel Studio during their Intel Developer Forum in August 2008». Очень давно, конечно.
VTune вспомните, Intel C++… Трудно отладить параллельное приложение, построенное даже на старых технологиях. И Parallel Studio собирает инструменты, которые давно учатся решать подобные задачи. Брать что-то вообще новое для реализации параллельности — это отважно. :)
UFO just landed and posted this here
Мне кажется, вы неправильно построили статью и теперь должны всем объяснять, что вы на самом деле имели ввиду. Для меня все прозвучало именно так, как я сказал. Язык действительно на заменяет работу мозга. Но как это относится к тому, что туча программистов не смогли справится с таким поведением сборщика мусора и к тому, что из вашего вывода следует, что C# — новый, модный непроверенный язык, которым пока лучше не пользоваться, а наблюдать, что будет?
Много было сказано о сборщике мусора, и что его не «умеют готовить». Так ведь дело не в умении, не умении. Дело в том, что сложность большого проекта, не зависит от языка. Именно про это была мысль. Какая разница, писать на Си++ контролируя явно указатели, или настраивать GC, делать клиент-сервер и так далее. Сложности всего этого не отличается на порядок. Основная сложность (и время) в проектировании, алгоритмах, поддержке и далее, далее.
Во-первых, вы продолжаете путать язык и технологию.
А во-вторых, сложность реализации проекта зависит от используемых технологий. Скажем, разница в «написать клиент-серверный транспорт самим» и «взять готовую реализацию» — человекомесяцы (если не годы). Вся ценность любой платформы разработки в том, что она позволяет разработчику думать о конкретных проблемах бизнес-приложения, а не о решении типовых задач класса «как мне написать кэш».
А во-вторых, сложность реализации проекта зависит от используемых технологий. Скажем, разница в «написать клиент-серверный транспорт самим» и «взять готовую реализацию» — человекомесяцы (если не годы). Вся ценность любой платформы разработки в том, что она позволяет разработчику думать о конкретных проблемах бизнес-приложения, а не о решении типовых задач класса «как мне написать кэш».
1) Я прагматик. Я не вижу смысла делить язык и технологию. Язык сам по себе ничто и представляет исключительно академический интерес.
2) Я не предлагаю писать БД на ассемблере. Жаль, что мне так и не удалось сказать то, что хотелось. Возможно когда ни будь я попробую это сделать другим постом.
2) Я не предлагаю писать БД на ассемблере. Жаль, что мне так и не удалось сказать то, что хотелось. Возможно когда ни будь я попробую это сделать другим постом.
1) А вот зря. Иначе бы вы понимали, что c# — это одна вещь, а GC — другая. И если c# означает GC, обратное — неверно. И, как следствие, не приводили бы примеров, вызывающих столько дискуссий.
А отсюда и вывод: вот изучать параллельные вычисления — хорошо. Это полезно, это сейчас актуально и так далее. А вот изучать конкретный язык и средство, которые реализуют параллельность — например, Intel Parallel Studio — это, по большому счету, прямо обратно смыслу вашей статьи.
2) А что вы предлагаете?
А отсюда и вывод: вот изучать параллельные вычисления — хорошо. Это полезно, это сейчас актуально и так далее. А вот изучать конкретный язык и средство, которые реализуют параллельность — например, Intel Parallel Studio — это, по большому счету, прямо обратно смыслу вашей статьи.
2) А что вы предлагаете?
Какая разница, писать на Си++ контролируя явно указатели, или настраивать GC, делать клиент-сервер и так далее. Сложности всего этого не отличается на порядок.
Разница не только в сложностях. Хотя они и отличается, пусть и не «на порядок».
Для большинства приложений сегодня безопасность не менее значительна чем производительность.
Ошибка при работе с указателями с C++ одна из наиболее распространённых «ошибко-дыр».
При работе в управляемой среде, незнание GC выльется в потерю производительности.
Но это я не к тому «что лучше, а что хуже». Просто у всего есть и плюсы и минусы.
И, таки да, всё надо «уметь готовить». Иначе даже самая трижды-рас-серебрянная пуля не поможет.
Основная сложность (и время) в проектировании, алгоритмах, поддержке и далее, далее.
Может я и ошибаюсь, но похоже весь спор просто из-за разницы в точках зрения.
Судя по Вашей фразе, Вы ближе к точке зрения менеджера-архитектора.
А большинство оппонентов (я в их числе, каюсь) смотрят на это с точки хрения программиста.
… я вот, например, именно архитектор.
Одна из вещей, которой учит Казман в курсе оценки архитектуры — собственно, важнейшая вещь — это понимание того, что любое решение есть компромис. Выбор платформы — это тоже компромис, плюсы и минусы которого надо осознавать.
И да.
Архитектурные решения принимаются на каждом уровне — включая микроуровень.
Одна из вещей, которой учит Казман в курсе оценки архитектуры — собственно, важнейшая вещь — это понимание того, что любое решение есть компромис. Выбор платформы — это тоже компромис, плюсы и минусы которого надо осознавать.
И да.
Архитектурные решения принимаются на каждом уровне — включая микроуровень.
Не понимаю.
На дворе 2010-ый год, а в спорах об удобстве языков обсуждают автоматическое управление памятью. Не возможности расширения языка и написания на нём DSL; не использование декларативного подхода вместо императивного; не богатство семантики и удобство высокоуровневых абстракций; а автоматическое управление памятью. Как будто сейчас до сих пор 1995-ый год, Microsoft только что выпустил Chicago, а Sun открывает кофейную тему в программировании. Не понимаю.
Реализация фактически любого современного языка программирования начинается с того, что у него обеспечиваются возможности взаимодействия с библиотеками на C/C++, вызова native code, лёгкого создания биндингов к доступным библиотекам. После этого, по мере возможностей, комьюнити делает эти биндинги более прозрачными с точки зрения языка, а то и переписывает функционал на самом языке, зачастую обеспечивая более надёжную реализацию. Часть языков явно позиционируются на использование в комплексе с другими языками, embedding. Когда в одном проекте используются сразу несколько языков, можно каждому из них выделить ту нишу, в которой он более эффективен. Тем не менее, кто-то ещё выбирает язык по библиотекам для него, как когда-то Delphi (потому что для неё есть готовый компонент для рисования графиков!), и всерьёз надеется, что одним языком можно и дрова из леса возить, и на светофоре стритрейсеров обгонять. Не понимаю.
Lisp вышел в 1958-ом году как алгоритмический язык высокого уровня, не привязанный к конкретной системной архитектуре. С появился в 1972-ом году как нишевый системный язык, ориентированный на особенности конкретных системных архитектур того времени; он настолько низкоуровнев, что даже не позволяет задействовать возможности архитектуры Фон Неймана. Дальнейшее развитие С и С++ быстро упёрлось в то, что архитектура стала меняться слишком существенно, стали выползать проблемы, связанные с невозможностью языка быстро отразить эти изменения архитектур — нестрогостью типизации, неуместной оптимизацией с помощью арифметики указателей, строгой линейностью и однопоточностью программ. Но вместо того, чтобы оставить этот язык в своей нише, а взамен использовать более соответствующие архитектуре языки, его стали притягивать за уши и навешивать на него костыли в виде отдельных программ, определений, библиотек. Вместо того чтобы отказаться от в принципе не нужных указателей, завели всякие Valgrind-ы и BoundChecker-ы; вместо того, чтобы пользоваться языками со встроенными в язык примитивами для упрощения программирования многопоточных приложений, изобрели всякие MPI и пишут во всяких Intel Parallel Studio; вместо того чтобы выбрать язык, изначально поддерживающий векторные вычисления, его пытаются эмулировать, громоздко и многословно, с помощью всевозможных OpenMP и CUDA. В своё время я писал на языке, появившемся лет через десять после C. В нём, на уровне языка, были возможности указания подсказок для branch predictor-а, так что наиболее часто используемые ветки кода/условных ветвлений/значения переменных/функции выполнялись быстрее, чем менее вероятные; простейшая оптимизационная возможность, полезная для любого низкоуровневого языка и появившаяся в этом языке (и невозможная в С/С++) просто потому, что он появился позднее, чем С, для более актуальных на тот момент архитектур. Что уж говорить о современных гетерогенных компьютерах, где в одном компьютере может быть несколько вычислительных ядер в процессоре и несколько вычислительных ядер в видеокарте. Ан за С/С++ до сих пор цепляются. Не понимаю.
Фактически вся история развития C — это попытки перетащить в него и прикрутить костылями концепции, уже давно бывшие в Lisp-е. Фактически вся дальнейшая история развития языков программирования — это попытки найти удобный и эффективный (на данный момент времени) баланс между низкоуровневостью и компьютероориентированностью Fortran-а и высокоуровневостью и человекоориентированностью Lisp-а. Тем не менее, С и отошедшие от него клоны, типа С++/Java/C#, считаются «старым добрым языком» (впрочем, кем-то даже C#/Java не считаются), а Lisp и отошедшие от него высокоуровневые языки типа тех же Haskell-а или F# — мифическими суперязыками. При этом каждый год в С-клоны подтягивают всё больше и больше возможностей из «мифических суперязыков», полностью оправдывая десятое правило Гринспена — но программисты так и предпочитают слушать Рабиновича, а не первоисточник. Не понимаю.
На дворе 2010-ый год, а в спорах об удобстве языков обсуждают автоматическое управление памятью. Не возможности расширения языка и написания на нём DSL; не использование декларативного подхода вместо императивного; не богатство семантики и удобство высокоуровневых абстракций; а автоматическое управление памятью. Как будто сейчас до сих пор 1995-ый год, Microsoft только что выпустил Chicago, а Sun открывает кофейную тему в программировании. Не понимаю.
Реализация фактически любого современного языка программирования начинается с того, что у него обеспечиваются возможности взаимодействия с библиотеками на C/C++, вызова native code, лёгкого создания биндингов к доступным библиотекам. После этого, по мере возможностей, комьюнити делает эти биндинги более прозрачными с точки зрения языка, а то и переписывает функционал на самом языке, зачастую обеспечивая более надёжную реализацию. Часть языков явно позиционируются на использование в комплексе с другими языками, embedding. Когда в одном проекте используются сразу несколько языков, можно каждому из них выделить ту нишу, в которой он более эффективен. Тем не менее, кто-то ещё выбирает язык по библиотекам для него, как когда-то Delphi (потому что для неё есть готовый компонент для рисования графиков!), и всерьёз надеется, что одним языком можно и дрова из леса возить, и на светофоре стритрейсеров обгонять. Не понимаю.
Lisp вышел в 1958-ом году как алгоритмический язык высокого уровня, не привязанный к конкретной системной архитектуре. С появился в 1972-ом году как нишевый системный язык, ориентированный на особенности конкретных системных архитектур того времени; он настолько низкоуровнев, что даже не позволяет задействовать возможности архитектуры Фон Неймана. Дальнейшее развитие С и С++ быстро упёрлось в то, что архитектура стала меняться слишком существенно, стали выползать проблемы, связанные с невозможностью языка быстро отразить эти изменения архитектур — нестрогостью типизации, неуместной оптимизацией с помощью арифметики указателей, строгой линейностью и однопоточностью программ. Но вместо того, чтобы оставить этот язык в своей нише, а взамен использовать более соответствующие архитектуре языки, его стали притягивать за уши и навешивать на него костыли в виде отдельных программ, определений, библиотек. Вместо того чтобы отказаться от в принципе не нужных указателей, завели всякие Valgrind-ы и BoundChecker-ы; вместо того, чтобы пользоваться языками со встроенными в язык примитивами для упрощения программирования многопоточных приложений, изобрели всякие MPI и пишут во всяких Intel Parallel Studio; вместо того чтобы выбрать язык, изначально поддерживающий векторные вычисления, его пытаются эмулировать, громоздко и многословно, с помощью всевозможных OpenMP и CUDA. В своё время я писал на языке, появившемся лет через десять после C. В нём, на уровне языка, были возможности указания подсказок для branch predictor-а, так что наиболее часто используемые ветки кода/условных ветвлений/значения переменных/функции выполнялись быстрее, чем менее вероятные; простейшая оптимизационная возможность, полезная для любого низкоуровневого языка и появившаяся в этом языке (и невозможная в С/С++) просто потому, что он появился позднее, чем С, для более актуальных на тот момент архитектур. Что уж говорить о современных гетерогенных компьютерах, где в одном компьютере может быть несколько вычислительных ядер в процессоре и несколько вычислительных ядер в видеокарте. Ан за С/С++ до сих пор цепляются. Не понимаю.
Фактически вся история развития C — это попытки перетащить в него и прикрутить костылями концепции, уже давно бывшие в Lisp-е. Фактически вся дальнейшая история развития языков программирования — это попытки найти удобный и эффективный (на данный момент времени) баланс между низкоуровневостью и компьютероориентированностью Fortran-а и высокоуровневостью и человекоориентированностью Lisp-а. Тем не менее, С и отошедшие от него клоны, типа С++/Java/C#, считаются «старым добрым языком» (впрочем, кем-то даже C#/Java не считаются), а Lisp и отошедшие от него высокоуровневые языки типа тех же Haskell-а или F# — мифическими суперязыками. При этом каждый год в С-клоны подтягивают всё больше и больше возможностей из «мифических суперязыков», полностью оправдывая десятое правило Гринспена — но программисты так и предпочитают слушать Рабиновича, а не первоисточник. Не понимаю.
Причина одна: библиотеки и старые наработки. И все. И никак. И ничего не изменится. :)
Третий абзац.
Непонятно, что в этом непонятного. :))
Да, язык выбирают по тому, с какими библиотеками (в том числе — написанными не на этом языке) он может использовать. Для того, чтобы упростить code reuse и сэкономить на разработке.
Чего вы в этом не понимаете?
Чего вы в этом не понимаете?
Непонятно, как можно оценивать язык по наличию библиотек, как только у языка появляется средство изготовления биндингов к С/C++-ным библиотекам. После чего в языке становится возможно использовать как свои библиотеки, так и фактически весь набор C/C++-ных (причём обратное зачастую неверно).
Это теоретически. На практике в случае большого объема плотно используемых библиотек, проще взять тот же язык.
Очень легко можно оценивать — вот представьте себе, что у компании есть крупная бизнес-библиотека, написанная на язык XYZ. Язык XYZ не является с/с++ и не вызывается из с/с++.
Логично же, что выбирая платформу для новых разработок, которая должна реализовывать ту же бизнес-функциональность, компания будет выбирать такой язык, который позволит reuse XYZ-библиотеки?
Просто библиотеками c/c++ жизнь не ограничивается.
Логично же, что выбирая платформу для новых разработок, которая должна реализовывать ту же бизнес-функциональность, компания будет выбирать такой язык, который позволит reuse XYZ-библиотеки?
Просто библиотеками c/c++ жизнь не ограничивается.
Мне совершенно не интересно реализовать алгоритм SVD разложения или поиска корней методом Ньютона. Я лучше возьму cvm или gsl. Если у супер пупер языка нет биндига к таким библиотекам то он бесполезен.
Уж что-то, но биндинг к GSL, по-моему, есть даже в S-Lang. Не говоря уже про мейнстрим типа OCaml или Common Lisp. А в случае народно любимого Haskell-а, вызовы GSL даже в туториалах по Foreign Function Interface описываются.
UFO just landed and posted this here
О а вот и Лисперы подтянулись. :) let the C++ срач begin… Си еще всех вас переживет.
UFO just landed and posted this here
Когда-то давно писали в машинных кодах, даже я баловался этим пару раз. Потом догадались оформить мнемониками в ассемблер, потом сделать макросы, что вылилось в следующий уровень. Который тоже развивался. И продолжает развиваться. И переходить на следующий уровень абстракции.
Каждый раз есть ретрограды, которые обьективно правы в обосновании вредности очередного повышения уровня. Но прогресс идет вперед и выгоды перевешивают недостатки.
Если вы уверены что плюсы, шарп или ява будут вовек, можете сразу занимать очередь за фортрановцами и коболовчанами. Да, и если последним на их век хватило, то ускорение развития выкинет текущие стандарты де факто быстрее.
Каждый раз есть ретрограды, которые обьективно правы в обосновании вредности очередного повышения уровня. Но прогресс идет вперед и выгоды перевешивают недостатки.
Если вы уверены что плюсы, шарп или ява будут вовек, можете сразу занимать очередь за фортрановцами и коболовчанами. Да, и если последним на их век хватило, то ускорение развития выкинет текущие стандарты де факто быстрее.
Ну вот сколько не пророчили смерть Си, я даже видел статью, составленную неким Хабровчанином на тему того, что Сишный программист это умирающая профессия… Как бы не так! Она еще многие годы будет востребована, все высокоуровневые языки они представляют полную абстракцию от оборудования, кобол и фортран кстати тоже старались по этому пути идти. Си же это кроссплатформенный ассемблер. Поэтому пока не будет изобретена какая-нибудь ну совершенно новая архитектура компьютеров, где Си окажется не удел, он будет жить.
Хочу еще сказать, что для разработки многопоточных приложений придумали erlang вообще-то.
JFYI:
haskell-cnc — Intel Concurrent Collections for Haskell.
© 2009–2010 Intel Corporation
И нет, это не обёртка к плюсовому коду, это чистый Haskell.
haskell-cnc — Intel Concurrent Collections for Haskell.
© 2009–2010 Intel Corporation
И нет, это не обёртка к плюсовому коду, это чистый Haskell.
Sign up to leave a comment.
Ммм… Супер язык… Дайте мне Си++ пожалуйста!