Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Как ни крути, когда в языках с GC-by-default требуется performance — от этого GC в той или иной мере пытаются избавиться.
Это неполное видение: как ни крути, в любых языках когда требуется performance — пытаются избавиться от лишних аллокаций. Но в целом согласен. Например, в С++ пытаются избавиться от shared указателей.
DM>>А если в целом, то согласно Страуструпу современный С++ — язык со сборкой мусора (причем плохой: на подсчете ссылок, т.е. медленной, ненадежной и небезопасной). EP>1. Есть интерфейс для консервативного GC.
Это тоже медленно и ненадежно.
EP>2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен.
Это уже детали и спекуляции.
DM>>(причем плохой: на подсчете ссылок, т.е. медленной,
EP>Почему медленной?
Потому что система типов слишком легко позволяет поиметь указатель на мертвый объект, например. Или перепутать виды указателей, использовать shared там где нужен weak или наоборот. Нет никаких гарантий, все управление памятью на честном слове держится.
Здравствуйте, AndrewVK, Вы писали:
DM>>И? Как именно это мешает хаскелю быть быстрым? AVK>Потерял нить разговора?
Себя спрашиваешь?
Смотри:
В C# есть GC, но в критичных местах можно писать код без его участия, тем не менее язык все равно в секторе "медленных". Почему? Например, потому что кодогенератор у него так себе.
В Хаскеле есть GC, но в критичных местах можно писать код без аллокаций, при этом кодогенератор у него другой, поэтому записывать его в сектор "медленных" пока нет причин.
Здравствуйте, D. Mon, Вы писали:
EP>>Как ни крути, когда в языках с GC-by-default требуется performance — от этого GC в той или иной мере пытаются избавиться. DM>Это неполное видение: как ни крути, в любых языках когда требуется performance — пытаются избавиться от лишних аллокаций.
Согласен, но в C++ это достигается легко, без потери абстракций. А в языках с GC переходят на уровень даже ниже чем C — играют массивами байт.
EP>>2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен. DM>Это уже детали и спекуляции.
We have implemented both types of collector: a multiprocessor concurrent reference counting collector with cycle collection
В обоих случаях говорится про ref-counted GC со сборкой циклов. Это принципиально отличается от того что даёт std::shared_ptr — никакого cycle collection там нет
DM>>>и небезопасной). EP>>Почему небезопасной? DM>Потому что система типов слишком легко позволяет поиметь указатель на мертвый объект, например. Или перепутать виды указателей, использовать shared там где нужен weak или наоборот. Нет никаких гарантий, все управление памятью на честном слове держится.
При раскладывании объектов по массивам байт в управляемых языках возникают те же проблемы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В обоих случаях говорится про ref-counted GC со сборкой циклов. Это принципиально отличается от того что даёт std::shared_ptr — никакого cycle collection там нет
Это к вопросу о ненадежности. Но даже без cycle collection временные характеристики не менее печальные. Даже такая важная оптимизация как deferred reference counting, как я подозреваю, на С++ не делается.
EP>>>Почему небезопасной? DM>>Потому что система типов слишком легко позволяет поиметь указатель на мертвый объект, например. Или перепутать виды указателей, использовать shared там где нужен weak или наоборот. Нет никаких гарантий, все управление памятью на честном слове держится.
EP>При раскладывании объектов по массивам байт в управляемых языках возникают те же проблемы.
Здравствуйте, D. Mon, Вы писали:
EP>>В обоих случаях говорится про ref-counted GC со сборкой циклов. Это принципиально отличается от того что даёт std::shared_ptr — никакого cycle collection там нет DM>Это к вопросу о ненадежности.
К вопросу о надёжности — кроме памяти есть и другие ресурсы, причём для которых необходимо детерминированное время жизни. В управляемых языках только половинчатые решения: using/try-with-resources/with.
DM>Но даже без cycle collection временные характеристики не менее печальные.
Почему?
DM>Даже такая важная оптимизация как deferred reference counting, как я подозреваю, на С++ не делается.
Чем же она так важна, особенно в контексте C++?
EP>>При раскладывании объектов по массивам байт в управляемых языках возникают те же проблемы. DM>Поэтому не надо раскладывать.
Когда нужна производительность, например на Java — вынужденны раскладывать и отказываться от GC
Здравствуйте, D. Mon, Вы писали:
EP>>При раскладывании объектов по массивам байт в управляемых языках возникают те же проблемы.
надо расклад DM>Поэтому неывать.
Здравствуйте, Artem Korneev, Вы писали:
AK>Но сколько я с ним ни сталкивался — боль и ужас. По параметрам "Safety & Productivity" я бы убрал его в левый нижний угол.
Боль и ужас это DOM и css. Хочешь смотреть серьезные вещи — смотри node.js , внятный АПИ большей частью и довольно предсказуемое поведение.
AK>Вообще я грешил на своё плохое знание JavaScript и по возможности стараюсь это исправить — вот буквально два дня назад на распродаже
купил десяток книг, из них две — по jQuery. По работе частенько приходится сталкиваться с JS, допиливая какие-нибудь веб-интерфейсы.
Не надо путать джаваскрипт с DOM, Css и поделками навроде jQuery.
AK>Но что-то наблюдая за другими разработчиками в своих командах, я бы не сказал что большинство из них пишет JS-части кода сильно быстрее и лучше, чем я.
AK>Куда бы вы поместили JavaScript на этой диаграмме?
Примерно там, где он сейчас стоит, может быть даже чуток правее Скажем, отрисовка в канвас будет не хуже, чем мега сервелат на С#
И не совсем понятно, почему по перформансу джава правее C#, низкоуровневый перформанс в C# намного лучше, там честные оптимизации на дженериках и прочих вещах, навроде строк и типов-значений. Серверный перформанс выше в джаве и исключительно благодаря библиотекам, которым уже 20 скоро будет.
Здравствуйте, Аноним, Вы писали:
А>Да это вообще странная идея о том, что-де на джаваскрипт проще программировать, чем на Java или C#.
А что странного, я вот пишу и отдыхаю после C# Вот первых, отладка намного мощнее, многие вещи можно попробовать прямо в отладочной консоли, в джаве и дотнете это недостижимый предел.
А>Подсказчика нет нормального, постоянно приходится печатать наугад. При этом нет компиляции с проверкой типов, и ошибку ты не поймаешь, пока не запустишь и не дойдешь до этого места. Рефакторинга тоже нет.
Все так, правда это особенности динамических языков, а не джаваскрипта. Обычно частично решается тулами, частично — внятным подходом к дизайну.
Если заводить на каждый чих сущности и методы, то это будет ад.
А>Набирать код в Javascript нужно внимательно и напряженно, чтобы не дай бог не опечататься и ничего не перепутать, и набирать вручную приходится гораздо больше, чем в C# и подобных, из-за отсутствия подсказок, компиляции,
Наоборот — набирать нужно намного _меньше_. А вот если на джаваскрипте писать "как на C#" то гораздо больше.
>рефакторинга и статической типизации. Ну и в Javascript есть набор совершенно диких нелогичностей в преобразованиях типов и синтаксисе, которых в C# нет, при этом в джаваскрипт ты ошибку не найдешь, пока выполнение не дойдет до этого места с нужными предварительными шагами (для получения тех данных, при которых проявляется ошибка). Ну или нужно строго 100% покрытие тестами.
Есть много нелогичностей, но в целом кривая вхождения довольно пологая.
А>Еще можно добавить отсутствие нормальной модульности и отсутствие развитой стандартной библиотеки, заменяемое зоопарком вычурных нестандартных.
джаваскрипт работает везде и совершенно не ясно, в каком виде ты хочешь страндартную библиотеку видеть.
Взять браузер — там одни ограничения. Серверные приложения — другие. Десктоп — третьи. Мобайл — четвертые. На кой ляд там одна библиотека, если скажем работа с файлами принципиально отличается во всех четырех случаях ?
Вместо этого можно подобрать библиотеку под конкретный случай.
А>Если говорить о якобы медленной компиляции, то, во-первых, никакая она не медленная, она делается обычно автоматически при сохранении файла и вообще незаметна, а, во-вторых, необходимость запускать программу каждый раз просто для проверки синтаксиса или корректности выражений, ускорением никак не назовешь.
1. в языках навроде C# слабоватый вывод типов и через это возможности ООП и ФП довольно хилые.
2. юниттесты нужны и в C#, при чем ровно там же, где и в джаваскрипте
3. запуск программы на JS большей частью ничего не стоит и да и запускать можно не программу, а один файл
А>Я не так много программировал на Javascript, так что, уверен, список недостатков можно пополнить. Хотя на Javascript можно делать веселые штуки благодаря динамике, и в отдельно взятых конкретных случаях они могут здорово сократить решение, да. Но не думаю, что таких случаев достаточно, чтобы это было существенно.
Динамика дает возможности, которых в C# нет и никогда не будет
А>Если все это суммировать, утверждения о более высокой производительности разработки на Javascript по сравнению, например, с C# — смехотворный бред, вызванный чьим-то больным воображением, либо какой-то миф, оставшийся от устаревших представлений. Непонятно, почему этот дурацкий миф так широко распространен и всеми так легко принимается на веру.
Хочешь, простой тест сделаем — регэкспы. Сильно удивишься. Или рисование в канвас.
Ну или совсем чит — правильный пайпинг на сервере, т.е. читаешь поток , обрабатываешь и одновременно отдаёшь. Выпилить такое на WCF мало кто сможет, стандартная либа первым делом пытается закачать весь стрим а уже потом разрешить процессить.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код. Но safety — это крайне спорный момент (опять таки — что конкретно подразумевается).
джаваскрипт исполняется в песочнице, что дает сафети.
Здравствуйте, AndrewVK, Вы писали:
EP>>1. Почему Java правее C#? В Java даже структур нету. Или это обусловлено только текущим качеством оптимизаторов?
AVK>Я так понимаю мало кто удосужился прочесть многабукав статьи. А в ней есть ответ: AVK>
AVK>Java is closer than C# thanks to the excellent work in HotSpot-like VMs which employ code pitching and stack allocation.
А что это значит ? Что это за VM такие и что такое питчинг и тд ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Хаскель уже без ГЦ обходится?
Жабаскрип без ЖЦ обходится. Но это ему не шибко помогает.
Что до Хаскеля, то не сказал бы, что писать на нем так уж продуктивно. Так что даже если он не будет отличатья от Си по скорости, один фиг его вряд ли ждет повсеместное применение. Это язык не для всех.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вот это форменный набор приседаний. Вообще, паттерны — это список недоработок в языке. Чем меньше нужно знать паттернов при программировании на языке, тем лучше этот язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код. Но safety — это крайне спорный момент (опять таки — что конкретно подразумевается).
Лично для меня и скорость кодирования на скриптах очень спорный вопрос. Но тут на любителя. Есть люди которым динамика надет преимущество, а есть те для кого это недостаток. Я предпочитают статические проверки типов и качественный интеллисес.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен.
Это ты расскажи тем кто Хорм в Гуле пилит. Они в итоге замаялись с тормозным и глючным посчетом ссылок и запилили ЖЦ для плюсов. Убогий конечно, но для их задач все равно лучше чем то что можно сделать в плюсах без него.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я так понимаю мало кто удосужился прочесть многабукав статьи. А в ней есть ответ: AVK>
AVK>Java is closer than C# thanks to the excellent work in HotSpot-like VMs which employ code pitching and stack allocation.
Что на практике скорее желаемое, нежели действительное. В то же Скале это ни хрена не помогает сделать for таким же быстрым как в Яве, так как он реализован как функция высшего порядка. Казалось бы мощные оптимизации явовского рантайма должны были бы нивелировать разницу, но на практике они только лишь сокращают отставание. Но оно все равно огромно.
В дотнете же оптимизации можно делать за счет использования вэйлью-типов. Так что на практике, в лучшем случае Ява стоит на одном месте по производительности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Ну или совсем чит — правильный пайпинг на сервере, т.е. читаешь поток , обрабатываешь и одновременно отдаёшь. Выпилить такое на WCF мало кто сможет, стандартная либа первым делом пытается закачать весь стрим а уже потом разрешить процессить.
Здравствуйте, Ikemefula, Вы писали:
I>джаваскрипт работает везде и совершенно не ясно, в каком виде ты хочешь страндартную библиотеку видеть.
I>Взять браузер — там одни ограничения. Серверные приложения — другие. Десктоп — третьи. Мобайл — четвертые. На кой ляд там одна библиотека, если скажем работа с файлами принципиально отличается во всех четырех случаях ?
А работа с потоками обычно везде одинаковая — практически везде есть базовый IStream (никогда не видел, чтобы с этим были проблемы).
Или, возьмем для примера, хотя бы коллекции и нотификации о изменениях. В том же .net все используют одни и те же IEnumerable, IList, INotifyPropertyChanged и т.д.
А на jscript каждый придумывает свою базовую библиотеку ни с чем не совместимую. В результате нельзя например написать логическую часть независимо, а потом выбрать GUI библиотеку для отображения — в каждой гуи библиотеке свой не визуальный фреймворк, со своими требованиями ко всем базовым объектам и все завязано на узел по самое ни хочу. И так во всем.
I>Вместо этого можно подобрать библиотеку под конкретный случай.
Вот только если нужно 2 библиотеки, то придется слой взаимодействия между ними писать самому, так как никаких стандартов ни на что нет.
И как вы там выкручиваетесь без элементарных типов, вроде decimal?
I>Динамика дает возможности, которых в C# нет и никогда не будет
Здравствуйте, VladD2, Вы писали:
VD> В то же Скале это ни хрена не помогает сделать for таким же быстрым как в Яве, так как он реализован как функция высшего порядка.
Давно проверял?
Эта проблема была очень давно, и мне казалось, ее уже давно исправили.
Скажем, отрисовка в канвас будет не хуже, чем мега сервелат на С#
