Только надо добавить, что на месте этого "языка высокого уровня" на самом деле выступало не какое-то поделие C++-ненавистников, а самый что ни на есть Lisp. А разброс между возможностями Lisp и языками вроде Java, C++, C# гораздо больше, чем разброс внутри этой троицы. Так что, с технической точки зрения результат был бы одним и тем же, перепиши Яха свой магазин на C++ или на Java (C#, AFAIK, тогда ещё не было, но это ничего не меняет).
VD>Трансляции в С++ тут вообще не причем. Это не более чем способ оптимизировать производительность разных интерпретируемых сред. Для дотнета и явы он имеет мало смысла. К тому же при этом глупо генерировать С++-код. Куда разумнее генерировать С-шный код. Переносимость выше и практически нет неявного оверхэда. А все возможности С++ для генерированного кода на фиг не упали.
Оверхэд C++ по сравнению с C — это миф, тут, скорее, всё обстоит ровно наоборот: например, декларации inline в C нет, сгенерировать шаблонный код для C тоже нельзя. Так что, выбор выглядит не таким уж неразумным. Впрочем, деталей я не знаю, могу только догадываться.
VD>Так что не обольщайся. С++ популярнее не станет. Он живет по инерции.
Популярность C++ меня, прямо скажем, не волнует. А что до инерции — так это очень большой плюс языка, если он обладает такой инерцией: это означает, что программы, разработанные на нём, удовлетворяют многим требованиям на протяжении долгого времени, а новые языки не дают настолько значимых преимуществ, чтобы кинулись всё на них переписывать. Отличный знак, надо сказать!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>"MS считает, что сейчас цикл разработки программы — 2 месяца" (последняя цифра мне особенно в память врезалась).
для ПО, которое поддерживается напрямую разработчиками, я наблюдаю — что цикл 1-2 месяца — это нормально.
и это позволяет такому ПО быстро взлетать и занимать свою нишу.
сейчас только у коробок большой цикл — год-два, но там это больше связано с особенностями психологии покупателей.
ГВ>Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе. Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.
Смещать лучше туда, где риски меньше (добиваться в первую очередь необходимо оптимальности по тому параметру, за который больше карают при отличии от идеала).
От того что, например, программа в среднем на 5-10% тормознее и пусть даже в отдельные моменты тормозит в 10 раз больше — это для использования некритично.
но если программа в среднем имеет на 5-10% больше ошибок и в отдельные моменты в 10 раз больше — это уже пользователю критично.
соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
Здравствуйте, DarkGray, Вы писали:
ГВ>>Я понимаю, что ты хочешь сказать: что не смотря на то, что по моим словам, такие ошибки найти нетрудно — они, тем не менее, есть. Только у нас получится непримиримое противоречие. Ты будешь агитировать за полный переход на managed, читай, увеличивать ресурсы, необходимые конечной программе. Я — за более тщательное тестирование (или compile-time — верификацию) и, соответственно, за сокращение ресурсов, потребляемых конечной программой в эксплуатации. Ошибки могут быть и там, и там. Главная (в контексте топика) разница только в том, куда смещаются энергетические затраты: на разработку или на эксплуатацию. ИМХО, лучше сместить их на разработку.
DG>Смещать лучше туда, где риски меньше (добиваться в первую очередь необходимо оптимальности по тому параметру, за который больше карают при отличии от идеала).
Батарейка. Perf/Watt.
DG>От того что, например, программа в среднем на 5-10% тормознее и пусть даже в отдельные моменты тормозит в 10 раз больше — это для использования некритично.
В контексте топика именно это и критично. Твои минус 5-10% скорости, это плюс 5-10% батарейки, вытряхнутые на те же задачи.
DG>но если программа в среднем имеет на 5-10% больше ошибок и в отдельные моменты в 10 раз больше — это уже пользователю критично.
А вот это в данном случае менее важно. Надёжность можно обеспечить и для managed, и для unmanaged. Вполне допускаю, что для unmanaged затраты на этапе разработки будут несколько больше (хотя это далеко не факт), но потом программа будет работать так же надёжно, как и managed, но уже с меньшими затратами ресурсов. Именно на этот момент сейчас и обратили внимание: потребление ресурсов в процессе эксплуатации, а не разработки.
DG>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
Что и требовалось доказать. Фактически, ты сейчас согласился с тезисами выступления Саттера, которые я вынес в топикстарт.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DG>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
Откуда берется заблуждение, что в дотнетных программах меньше ошибок? Сколько их видел — вылетают ошибки как здасьте. Управляемая среда исключает только ошибки прохода по памяти (вернее, все, связанные с неверной реинтепретацией памяти). Но спроси у любого плюсовика, когда он последний раз вживую видел в С++ коде проход по памяти. Многие и не видели никогда, в плюсовом-то. А остальных ошибок хватает, понятно. Точно таких же, как во всех программах на любых языках.
Здравствуйте, kaa.python, Вы писали:
KP>А как кто-то приводит конкретный пример, дотнетовцы сразу говорят что вот уж в данном случае разговор отдельный. Тут должно тормозить, а вот в целом все очень быстро. Очень знакомо
Тебе повоевать захотелось?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>Легко! Наведенная ошибка — это практически любая неправильно обработанная ошибка или пропущенная где-то ранее ошибка. Самый очевидный пример — когда-то ранее null сохранили без проверки, а в момент использования получи ошибку. Вот тебе классическая наведенная ошибка, найти которую не поможет никакой стек-трейс, т.к. в момент возникновения ошибки ее предыстория неизвестна. Она встречается на несколько порядков чаще в дотнете, да и в нейтиве тоже, чем проходы по памяти. По-сути ты называешь главной причиной наведенных ошибок ту, которая составляет доли одного процента от всех причин для наведенных ошибок. Сие нелепо.
Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.
V>Ну так напомню, что ты и тебе подобные постоянно игнорируют тот факт, что всякие переполнения буфера происходят в основном в legacy-коде, который был писан черти когда на голом С или на самых первых версиях C++, на котором все-равно писали как на С. Уже более 10-15 лет никто не создает в С++ массивы памяти вручную. Стал бы ты, даже имея такую возможность в дотнете (а она есть, через класс Marshal) выделять и вручную следить за блоками памяти? Это же жутко неудобно! Аналогично и в С++ — использование безопасных библиотек удобнее гораздо, банально меньше кода, и голова не болит следить за байтами.
Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
V>Откуда же такое внимание к ошибкам именно в нейтиве?
Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого
2) Наличие коллстеков у всех исключений.
3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы.
T>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме. В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
Еще две очень распространенные в С++ причины стрельбы по памяти — это использование ссылки\указателя на удаленный объект и неинициализированные данные.
Здравствуйте, mrTwister, Вы писали:
T>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
От найтив не найтив это мало зависит, например вполне аналог C++ — D от didgitalmars практически свободен от подобных ошибок.
Ну или другой пример OCaml или Хаскель тоже вполне найтивны, однако по ошибкоустойчивости дадут фору и шарпу и яве.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, mrTwister, Вы писали:
T>>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин:
FR>От найтив не найтив это мало зависит, например вполне аналог C++ — D от didgitalmars практически свободен от подобных ошибок. FR>Ну или другой пример OCaml или Хаскель тоже вполне найтивны, однако по ошибкоустойчивости дадут фору и шарпу и яве.
Неверно Ocaml и Хаскел являются управляемыми языками. В сгенерированном код есть метаданные, которые позволяют использовать безопасные конструкции.
Естественно обращение к метаданным небесплатно. В этом и суть управляемых языков и их отличия от неуправляемых.
При этом для неуправляемых языков гораздо проще писать программу, которая дает предсказуемый нативный код, поэтому и называют языки native.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Есть подозрение что многие разработчики страдают заболеванием типа "хронического оптимизаторства" и пытаются писать априори быстрый код уже на уровне спинного мозга. Используя ссылки чтобы не вызывать копирования, пулы и преаллокацию чтобы не дергать кучу, массивы на стеке с шаблонными функциями вместо векторов.
V>Угу, вот так взять свалить в одну кучу приемы, которые ничего не стоят, и которые просто правила хорошего тона и способы улучшения типобезопасности времени компиляции, с теми, которые требуют анализа, заметных трудозатрат и даже отладки. Круто.
Я же говорю что вживую наблюдал такое, причем не единожды.
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, AndrewVK, Вы писали:
AVK>>Потому что они не работают быстрее. Сравнивать абстрактное приложение на плюсах с абстрактным на .NET глупо, а такого чтобы одно и то же приложение было написано идентичными по квалификации командами с нуля и на С++ и под .NET, мне такое не встречалось.
DR>Был Evernote 3.5 написанный на WPF и заметно более тормозной чем нативные 3.1 и 4.0.
Evernote был написан толпой C++ программистов. Думаю одна из причин низкой производительности была именно в этом.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, DarkGray, Вы писали:
DG>>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
V>Откуда берется заблуждение, что в дотнетных программах меньше ошибок? Сколько их видел — вылетают ошибки как здасьте.
Если взять программистов той же квалификации и они напишут на C++ такую же программу, то в 99% случаев она будет падать сразу при старте, а в оставшихся 1% иметь учетки памяти и необяснимые ошибки.
V>Управляемая среда исключает только ошибки прохода по памяти (вернее, все, связанные с неверной реинтепретацией памяти).
А также утечки памяти. В managed можно вернуть из метода объект и не париться по поводу его времени жизни, в C++ для такого поведения нужны различные умные указатели, аллокаторы и другие далеко нетривиальные конструкции, подсильные только гуру, чтобы все работало с такой же надежностью и эффективностью.
V>Но спроси у любого плюсовика, когда он последний раз вживую видел в С++ коде проход по памяти.
Спросил, мне ответили что около пары недель назад.
Проблема почти классическая. Указатель на освобожденный объект, память оказалась затерта другим значением, в цикле это использовалось в качестве границы. Причем сам код цикла не менялся, просто во внешнем коде переставил вызовы функций. Но там древний проект, большая часть код которого была написана практически на С.
Здравствуйте, gandjustas, Вы писали:
G>Неверно Ocaml и Хаскел являются управляемыми языками. В сгенерированном код есть метаданные, которые позволяют использовать безопасные конструкции. G>Естественно обращение к метаданным небесплатно. В этом и суть управляемых языков и их отличия от неуправляемых.
G>При этом для неуправляемых языков гораздо проще писать программу, которая дает предсказуемый нативный код, поэтому и называют языки native.
Ну а как на счёт D? ) Кстати, с ocaml всё не совсем так. На счёт хаскеля не знаю — не имел с ним дел. )
Здравствуйте, gandjustas, Вы писали:
G>Если взять программистов той же квалификации и они напишут на C++ такую же программу, то в 99% случаев она будет падать сразу при старте, а в оставшихся 1% иметь учетки памяти и необяснимые ошибки.
А вот здесь вы абсолютно правы. И это и есть основное преимущество явы и C# — возможность достаточно эффективно использовать труд малоквалифицированных программистов и легко заменять их в случае надобности. Это особенно актуально в корпоративном "не компьютерном" секторе. А вот для компаний специализирующихся на разработке софта картина немного другая... Тут уже бывает полезнее держать только высококлассных спецов и благодаря этому делать высококонкурентные продукты. Оба подхода востребованы на рынке — каждому своё...
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Неверно Ocaml и Хаскел являются управляемыми языками. В сгенерированном код есть метаданные, которые позволяют использовать безопасные конструкции. G>>Естественно обращение к метаданным небесплатно. В этом и суть управляемых языков и их отличия от неуправляемых.
G>>При этом для неуправляемых языков гораздо проще писать программу, которая дает предсказуемый нативный код, поэтому и называют языки native.
_>Ну а как на счёт D? )
Надо учитывать что native-managed не строгая дихотомия, не который континуум. Есть тн typesafe языки, в которых в принципе нет возможности получить ссылку другого типа на тот же блок памяти, занятый другим объектом, это одна сторона континуума, другая сторона — ассемблер, где управлешь памятью как хочешь. Между ними находится много разных вариантов, причем варианты могут сочетаться даже в одном языке. Вот D один из таких языков, как и C++, только в последнем возможностей меньше.
Но тут есть особенность: для typesafe языков часть проверок можно провести статически, а в рантайме их выкинуть. Для языков где возможны разные варианты safety такой возможности нет надо постоянно выполнять проверки или просто получать проблемы.
_>Кстати, с ocaml всё не совсем так.
Что ты имеешь ввиду? Что он не использует данные о типах? Тогда как он мусор собирает?
Здравствуйте, vdimas, Вы писали:
DG>>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки V>Откуда берется заблуждение, что в дотнетных программах меньше ошибок? Сколько их видел — вылетают ошибки как здасьте. Управляемая среда исключает только ошибки прохода по памяти (вернее, все, связанные с неверной реинтепретацией памяти). Но спроси у любого плюсовика, когда он последний раз вживую видел в С++ коде проход по памяти. Многие и не видели никогда, в плюсовом-то. А остальных ошибок хватает, понятно. Точно таких же, как во всех программах на любых языках.
Я знаю, что сейчас скажут про то, что "многие и не видели никогда": что вот потому и не видели, что эти ошибки невидимы!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mazay, Вы писали:
U>>>По поводу Саттера: он тонко троллит. Никакого ренессанса C++ нет и не предвидится. Точнее, ничего не изменилось. Ни для С++, ни для managed языков. И те и другие развиваются. С++ даже медленнее, чем другие языки. Нет никакого внезапного перехода на С++ в индустрии. C>>С++ развивается комитетом, но развивается. С++11 — несомненный шаг вперёд. M>Который надо было сделать 7 лет назад.
А C# давно уже надо было сделать телепатически понимающим мысли заказчика.
U>>>В MS есть. В MS написали WinRT на С++, ну и что? Мы все знаем какой в MS C++. Корявый С с классами, COM интерфейсами, unsafe буферами и голыми указателями, основательно сдобренные вергерской нотацией. C>>И пофиг, зато быстро работает. M>Про переполнение буфера забыли?
А что это?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Аналогично и в С++ — использование безопасных библиотек удобнее гораздо, банально меньше кода, и голова не болит следить за байтами.
