Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 130
отличный материал. Если Вы все же сможете перевести весь материал, буду безмерно благодарен!
> С удовольствием приму замечания и пожелания по поводу того, что ещё можно включить из оригинального доклада. Перевести целиком было бы замечательно, но более 70 тыс. знаков — для меня лично это работа на неделю минимум. <
Надо запрячь какого-нибудь аспиранта. У них сейчас как раз экзамены начнуться. Ау, аспиранты, отзовитесь :)
Надо запрячь какого-нибудь аспиранта. У них сейчас как раз экзамены начнуться. Ау, аспиранты, отзовитесь :)
Javascript sucks & must die - страшный язык, не содержит оригинальных концепций, все реализации глючные до жути, изначально возник как "примочка" для browser-а. Наверное автор доклада прав вообще на счет динамических языков, но будущее, в котором софт пишут на JavaScript - это кошмар ночной какой-то.
Что, неужели там теперь переменные block scoped? :)
Интенсивное использование глобальных переменных и отсутствия block scope - первая (наипростейшая) из причин утечки памяти. А так же и то, и другое потворствует многим ошибкам и проблемам кода. В любом языке, где есть такая практика.
Вы сами-то ее почитайте:
------------
Standard ECMA-262
------------
If the variable statement occurs inside a FunctionDeclaration, the variables are defined with function-local scope in that function, as described in s10.1.3. Otherwise, they are defined with global scope (that is, they are created as members of the global object, as described in 10.1.3) using property attributes {DontDelete}. Variables are created when the execution scope is entered. A Block does not define a new execution scope. Only Program and FunctionDeclaration produce a new scope.
------------
В "C" тоже есть глобальные переменные, проблема не в их наличии. Проблема в практике использования. Я не пишу на JavaScript подо все, что движется. Но когда я смотрю код HTML страниц с JavaScript и библиотек, которые используются при разработке сайтов - там переменная на переменной... Неудивительно, что память течет даже в Firefox при заходе на большие сайты.
------------
Standard ECMA-262
------------
If the variable statement occurs inside a FunctionDeclaration, the variables are defined with function-local scope in that function, as described in s10.1.3. Otherwise, they are defined with global scope (that is, they are created as members of the global object, as described in 10.1.3) using property attributes {DontDelete}. Variables are created when the execution scope is entered. A Block does not define a new execution scope. Only Program and FunctionDeclaration produce a new scope.
------------
В "C" тоже есть глобальные переменные, проблема не в их наличии. Проблема в практике использования. Я не пишу на JavaScript подо все, что движется. Но когда я смотрю код HTML страниц с JavaScript и библиотек, которые используются при разработке сайтов - там переменная на переменной... Неудивительно, что память течет даже в Firefox при заходе на большие сайты.
я бы не стал кричать "sucks & must die" на язык за то, что в подавляющем большинстве случаев он используется для выпадающих меню. веб-приложение на одних глобальных переменных не протянешь, а в применении глобальных переменных для простейшей, обособленной и часто единственной задачи ничего страшного нету.
Согласен - я излишне экспрессивен, но ничего с собой не могу поделать. :) Вообще язык был специально сделан для создания динамических сайтов, но любая современная практическая потребность (формы с автоподкидкой и всякими комбо-боксами, гибкое форматирование) - и имеем трах, разное поведение кода в разных браузерах, отсутствие стандартных функций для получения нужной информации, проблемы с таймерами и асинхронной работой... Наблюдал это со стороны и сочувствовал нашим программистам. Куча усилий квалифицированного персонала тратится непонятно на что или нужно подключать огромные frameworks, которые медленно грузятся, которые ГЛЮЧАТ сами по себе и код их приходится хачить под свои потребности тем же программистам. И в них течет память.
грёбанный браузер решил не постить коммент… ррр… или грёбанный сервер…
да я думаю, что будут теже api, а софт под них будут писать теже самые разработчики, так что снова будут (в лучшем случае) чуть-чуть разные интерпретации, за счет "сглаживания разногласий" появятся теже фреймворки, ну и так далее… квалифицированный персонал в догонку к текущей ситуации будет вынужден изучать что-то революционно новое, но с тем же толком.
а глобальные исследования должны начинаться на голом энтузиазме, чтобы ни один маркетолог на них не позарился. иначе получается то, что сейчас есть :)
да я думаю, что будут теже api, а софт под них будут писать теже самые разработчики, так что снова будут (в лучшем случае) чуть-чуть разные интерпретации, за счет "сглаживания разногласий" появятся теже фреймворки, ну и так далее… квалифицированный персонал в догонку к текущей ситуации будет вынужден изучать что-то революционно новое, но с тем же толком.
а глобальные исследования должны начинаться на голом энтузиазме, чтобы ни один маркетолог на них не позарился. иначе получается то, что сейчас есть :)
Может быть стоит вообще убрать из browser-а всю логику и превратить его в формальную систему отображения?
Чтобы не было проблемы разной видимости одного и того же сайта под разными браузерами на разных платформах и при разных юзерских настройках... И чтобы нельзя было в принципе ничего хакнуть из-за недосмотра на страницах, так как страница - это снова "как в старые добрые" статическая вещь.
Сейчас каналы достаточно быстрые, передача PNG + JPEG + векторной графики может занять МЕНЬШЕ времени, чем перекачка на машину клиента javascipt-ов фреймворков всяких по 400K каждый.
И AJAX не нужен или в каком-то смысле - доведен до предела в такой модели. :)
Чтобы не было проблемы разной видимости одного и того же сайта под разными браузерами на разных платформах и при разных юзерских настройках... И чтобы нельзя было в принципе ничего хакнуть из-за недосмотра на страницах, так как страница - это снова "как в старые добрые" статическая вещь.
Сейчас каналы достаточно быстрые, передача PNG + JPEG + векторной графики может занять МЕНЬШЕ времени, чем перекачка на машину клиента javascipt-ов фреймворков всяких по 400K каждый.
И AJAX не нужен или в каком-то смысле - доведен до предела в такой модели. :)
этакие pdf'ки, вариант интересный. насколько я понимаю, "убрать из browser-а всю логику и превратить его в формальную систему отображения" было бы здорово, если бы ответ от сервера (или сигнал из сети, если от http абстрагироваться) читало нечто :) да таже операционка. операционка, правда, тоже не одна-единственная, но уже много стабильнее.
только встает вопрос интерактивности :)
js-фреймворки люди юзают, судя по моей практике (я, собсно, верстальщик), исключительно по не умению: не умению отправить post-запрос, не умению работы с DOM'ом, не умению отсортировать таблицу по столбцу. но в любом из-за интреактивности, а значит, оно потребно. если бы перекинуть и её (интерактивность) в нечто единое и стабильное, было бы очень и очень круто. а вот как этому "нечту" избежать долгий и мучительный процесс становления?
только встает вопрос интерактивности :)
js-фреймворки люди юзают, судя по моей практике (я, собсно, верстальщик), исключительно по не умению: не умению отправить post-запрос, не умению работы с DOM'ом, не умению отсортировать таблицу по столбцу. но в любом из-за интреактивности, а значит, оно потребно. если бы перекинуть и её (интерактивность) в нечто единое и стабильное, было бы очень и очень круто. а вот как этому "нечту" избежать долгий и мучительный процесс становления?
кнеш, оффтоп… а утечки памяти в браузере это так жутко? дофига программ страдают тормозами при длительной работе, закрыл, открыл и снова все нормуль. Да, не рулит, но, похоже, это исключительно недостаток квалификации.
Ну зачем же сразу 'сакс, мастдай'... Ведь, по-моему, речь идёт об оптимизации, т.е. устранении недостатков. Почему все реализации глючные? Если Вы не встречали нормальных веб-приложений - мне Вас искренне жаль. Примочка для браузера, говорите? А мне кажется, что всё идёт к тому, что скоро браузер станет примочкой для джаваскрипта, который, кстати, вовсе не застыл в своём развитии.
Я действительно не встречал ни одного нормального веб-приложения, где бы активно использовался JavaScript. Они все тяжеловесные и в них течет память, или они "виснут" непонятно почему время от времени, особенно при длительном использовании. Включая gmail. Если даже чудом там не течет память - то это исключение, которое подтверждает правило. Значит, что разработчики сайта и frameworks вложили человеко-годы в тяжелый трах с миллионами глюков реализаций JavaScript в разных браузерах и ужасными хаками пофиксили проблему. Причем хаки эти нигде не описаны и эзотерическое знание о них которых передается от учителя к ученику, как в секте, или же добывается reverse engineering-ом чужих сайтов. А на любом ресурсе, где есть программисты на JavaScript (включая Хабрахабр), найдется с десяток статей с частицами таких сведений - что говорит об актуальности проблемы.
По-моему кто-то путает язык с проблемами кроссбраузерности. Это разные вещи, джаваскрипт - один из лучших языков, на которых я писал.
Лучших ДЛЯ ЧЕГО, в отрыве от browser-ов, где он используется? И что Вы на нем писали?
Во-первых, я использую его через scripting API в джаве. До шестой джавы я подключал его к своим приложениям используя библиотеку для мозилловского Rhino. В отрыве от браузеров это очень хороший язык. А в купе с DOM-моделью - так вообще прелесть.
Во-вторых, в том, что браузеры по-разному реализуют DOM и стандартные объекты, виноваты они сами, и джаваскрипт тут какбе вообще нипричем.
Во-вторых, в том, что браузеры по-разному реализуют DOM и стандартные объекты, виноваты они сами, и джаваскрипт тут какбе вообще нипричем.
Почему 99.99% для пользователей не нужно делать настройки на конкретный компилятор в C? Почему там всегда так было с 80-х годов, когда язык был еще молод даже. Если не извращаться по-черному, то программа собиралась одинаково всеми компиляторами и работала одинаково, в рамках модели заданной языком, его стандарта.
Но в JavaScript мои коллеги на одной бывшей работе вынуждены были тратить изрядную часть рабочего времени на поиск, исследование и обход проблем интероперабельности в разных broweser-ах. Не так сложно им было писать сам код, как добиваться стабильной, одинаковой работы этого кода даже под основными ветвями browsers. Причем с той самой DOM у них было много траха.
Я думаю, что с самим языком есть какие-то проблемы, если каждая его реализация настолько уникальна в своих глюках и отступлениях от стандарта, что значительное время и огромное количество нервов программисты тратят на interoperability. Просто по факту.
Но возможно я не прав, "идея была хорошей", только ее плохо реализовали.
Чем же хорош сам JavaScript как язык программирования? Чем он выделяется на фоне других языков так, что Вы его прямо хвалите? Дайте конструктов, пожалуйста развернутый, а не одной короткой фразой.
Но в JavaScript мои коллеги на одной бывшей работе вынуждены были тратить изрядную часть рабочего времени на поиск, исследование и обход проблем интероперабельности в разных broweser-ах. Не так сложно им было писать сам код, как добиваться стабильной, одинаковой работы этого кода даже под основными ветвями browsers. Причем с той самой DOM у них было много траха.
Я думаю, что с самим языком есть какие-то проблемы, если каждая его реализация настолько уникальна в своих глюках и отступлениях от стандарта, что значительное время и огромное количество нервов программисты тратят на interoperability. Просто по факту.
Но возможно я не прав, "идея была хорошей", только ее плохо реализовали.
Чем же хорош сам JavaScript как язык программирования? Чем он выделяется на фоне других языков так, что Вы его прямо хвалите? Дайте конструктов, пожалуйста развернутый, а не одной короткой фразой.
Насчет Си - когда-то на втором курсе мы делали лабы на С, одна и та же программа (скомпилированный экзешник) запускался дома и не запускался в универе. Либо в универе запускался через раз. Больше к С я не притрагивался.
Это я к тому, что С тоже не сахар.
Проблемы с самим джаваскриптом нет. Проблема в разной реализации DOM и стандартных объектов Javascript.
Чем хорош джаваскрипт? Да он мне просто нравится=)
Это я к тому, что С тоже не сахар.
Проблемы с самим джаваскриптом нет. Проблема в разной реализации DOM и стандартных объектов Javascript.
Чем хорош джаваскрипт? Да он мне просто нравится=)
Почему 99.99% для пользователей не нужно делать настройки на конкретный компилятор в C? Почему там всегда так было с 80-х годов, когда язык был еще молод даже. Если не извращаться по-черному, то программа собиралась одинаково всеми компиляторами и работала одинаково, в рамках модели заданной языком, его стандарта.
Но в JavaScript мои коллеги на одной бывшей работе вынуждены были тратить изрядную часть рабочего времени на поиск, исследование и обход проблем интероперабельности в разных broweser-ах. Не так сложно им было писать сам код, как добиваться стабильной, одинаковой работы этого кода даже под основными ветвями browsers. Причем с той самой DOM у них было много траха.
Я думаю, что с самим языком есть какие-то проблемы, если каждая его реализация настолько уникальна в своих глюках и отступлениях от стандарта, что значительное время и огромное количество нервов программисты тратят на interoperability. Просто по факту.
Но возможно я не прав, "идея была хорошей", только ее плохо реализовали.
Чем же хорош сам JavaScript как язык программирования? Чем он выделяется на фоне других языков так, что Вы его прямо хвалите? Дайте пожалуйста конструктов, развернутый, а не одной короткой фразой.
Но в JavaScript мои коллеги на одной бывшей работе вынуждены были тратить изрядную часть рабочего времени на поиск, исследование и обход проблем интероперабельности в разных broweser-ах. Не так сложно им было писать сам код, как добиваться стабильной, одинаковой работы этого кода даже под основными ветвями browsers. Причем с той самой DOM у них было много траха.
Я думаю, что с самим языком есть какие-то проблемы, если каждая его реализация настолько уникальна в своих глюках и отступлениях от стандарта, что значительное время и огромное количество нервов программисты тратят на interoperability. Просто по факту.
Но возможно я не прав, "идея была хорошей", только ее плохо реализовали.
Чем же хорош сам JavaScript как язык программирования? Чем он выделяется на фоне других языков так, что Вы его прямо хвалите? Дайте пожалуйста конструктов, развернутый, а не одной короткой фразой.
Хех. Давайте я вам отвечу прямо цитатой:
ИТ-индустрия никогда не была похожа на сладкий сон :-)
Lemme tell ya how it was supposed to be. JavaScript was going away. It doesn't matter whether you were Sun or Microsoft or anybody, right? JavaScript was going away, and it was gonna get replaced with… heh. Whatever your favorite language was.
I mean, it wasn't actually the same for everybody. It might have been C#, it might have been Java, it might have been some new language, but it was going to be a modern language. A fast language. It was gonna be a scalable language, in the sense of large-scale engineering. Building desktop apps. That's the way it was gonna be.
The way it's really gonna be, is JavaScript is gonna become one of the smokin'-est fast languages out there. And I mean smokin' fast.
ИТ-индустрия никогда не была похожа на сладкий сон :-)
были бы руки...
Возьмем ПРОСТЕЙШИЙ пример - массово используемую вставку XMLHttpRequest.js. 362 строки кода и десятки грязных хаков, чтобы добиться безглючной работы одного-единственного метода средней тривиальности под разными браузерами, включая Opera, Mozilla и IE - ни один из них не делает все как надо. Это п-ц. И так там практически все, может быть просто в чем-то другом несколько меньше глюков и больше стандартизации, но проверки типа браузера и хаки для обхода утечек памяти - в любом framework, в любой большой библиотеке...
не хочу разводить тут холивор, тем более, я был такого же мнения о js примерно год назад.
но как-то так случилось, что я "проникся" идеей динамических языков. может, Вы тоже скоро это поймете.
а по поводу вашего примера... js как-бы не предназначен для работы с xml, он работает с json нативно. попробуйте поискать библиотеку работы с json, например, для java - там тоже не все просто.
но как-то так случилось, что я "проникся" идеей динамических языков. может, Вы тоже скоро это поймете.
а по поводу вашего примера... js как-бы не предназначен для работы с xml, он работает с json нативно. попробуйте поискать библиотеку работы с json, например, для java - там тоже не все просто.
Я использую, например, rexx (в текстовом редакторе), с какого-то мохнатого года, это тоже динамический язык. Для работы с HTML (в принципе) он бы тоже подошел. :) Но писать на таких языках что-то серьезное? Это IMHO извращение. Вынужденное, в некоторых случаях.
Неужели Вы не видите, что ВСЯ технологическая цепочка, начиная от HTTP-сервера (типа Apache) и заканчивая JavaScript и HTML - это безнадежное, прогнившее до основания нагромождение "культурных слоев" давно минувших эпох и цивилизаций? Просто нам дано это все в ощущениях, эти технологии уже "раскручены", в них вложены миллиарды баксов и миллионы человеко-лет и поэтому мы не можем от них отказаться. Хотя де-факто это просто хаотическое нагромождение исторического наследия и хаков.
Но гораздо конструктивнее потратить следующие человеко-годы на разработку принципиально новой, современной среды, вообще не использующей никаких элементов этой безнадежно устаревшей цепочки, а не на ускорение JavaScript и добавление еще каких-то 101-х по счету технологий-затычек к существующему маразматическому наслоению.
Неужели Вы не видите, что ВСЯ технологическая цепочка, начиная от HTTP-сервера (типа Apache) и заканчивая JavaScript и HTML - это безнадежное, прогнившее до основания нагромождение "культурных слоев" давно минувших эпох и цивилизаций? Просто нам дано это все в ощущениях, эти технологии уже "раскручены", в них вложены миллиарды баксов и миллионы человеко-лет и поэтому мы не можем от них отказаться. Хотя де-факто это просто хаотическое нагромождение исторического наследия и хаков.
Но гораздо конструктивнее потратить следующие человеко-годы на разработку принципиально новой, современной среды, вообще не использующей никаких элементов этой безнадежно устаревшей цепочки, а не на ускорение JavaScript и добавление еще каких-то 101-х по счету технологий-затычек к существующему маразматическому наслоению.
Оставим в покое JS и HTML. HTTP чем не угодил?
К формату пакетов претензий не имею, хотя и сложно понять, зачем он human-readable, если его люди не читают (ну разве что для отладки глюков в настройках перегруженных историческим наследием серверов). А вот в совокупности вся технология HTTP-доступа имеет столько недостатков, что по ним можно писать книги. :) Основное, на вскидку:
- Отсутствует нормальная поддержка сессий,
- Отсутствует поддержка для загрузки структурированных объектов,
- Кэширование требует танцев с бубном, особенно в сочетании с AJAX,
- Используется протокол TCP, что ведет к неизводимым замираниям и задержкам при загрузке страниц - если пропал один-единственный пакетик от сервера,
- Серверы типа Apache во всей своей архитектуре ориентированы на концепцию файловой системы, хотя все современные сайты - это динамический сгенерированный контент.
- Отсутствует нормальная поддержка сессий,
- Отсутствует поддержка для загрузки структурированных объектов,
- Кэширование требует танцев с бубном, особенно в сочетании с AJAX,
- Используется протокол TCP, что ведет к неизводимым замираниям и задержкам при загрузке страниц - если пропал один-единственный пакетик от сервера,
- Серверы типа Apache во всей своей архитектуре ориентированы на концепцию файловой системы, хотя все современные сайты - это динамический сгенерированный контент.
Они - не human readable, а human writeable. И это важно, чтобы программы для генерации динамических страничек писать. Конечно, можно было бы во что-нибудь компилировать. Но текст - это хорошо. Потому что универсально
И каждый раз расходы времени серверов на генерацию human readable headers, а так же на парсинг запросов от клиента, особенно в AJAX. И баги в этом парсинге, в том числе дырки в security. :) А на proxy или в кэше - необходимость полного парсинга и rewrite headers. Но это как раз наименьшее из зол, а основное я перечислил ниже.
HTTP. HyperText Transfer Protocol. Гипертекст трансферит? Трансферит. Что ещё нужно?
То, что кого-то не устраивают какие-то конкретные реализации, уже отдельная от HTTP проблема.
Это Вы не о недостатках HTTP пишете, а о чём-то своём абстрактно-наболевшем. Не нужно все проблемы мира на беднягу скидывать. =)
То, что кого-то не устраивают какие-то конкретные реализации, уже отдельная от HTTP проблема.
Это Вы не о недостатках HTTP пишете, а о чём-то своём абстрактно-наболевшем. Не нужно все проблемы мира на беднягу скидывать. =)
Да отличный протокол, кто бы спорил - для своего времени вообще замечательный!
Только мир ушел далеко вперед с тех времен, когда нужно было просто потоком передать статическую страницу гипертекста с сервера на клиент. Теперь эта страница даже в стандартной модели представляет собой целую иерархию объектов, которые не нужно грузить все сразу. Каналы стали такими быстрыми, а страницы такими большими, что TCP уже неадекватен для "реактивных" on-line приложений, как несущий протокол (хотя формально HTTP как формат заголовков к нему отношения не имеет, но все же в стандарте явно указывается, что HTTP использует TCP и такова практика). Прокси и кэши для обеспечения работы миллионов клиентов должны быть как можно более быстрыми, в идеале даже аппаратными - а HTTP подразумевает парсинг [и переписывание] текстовых заголовков на промежуточных узлах. Концепция Web 2.0 предполагает, что пользователь интерактивно работает с сайтом - а в HTTP нет четкого понятия сессии и обратной связи с пользователем.
Только мир ушел далеко вперед с тех времен, когда нужно было просто потоком передать статическую страницу гипертекста с сервера на клиент. Теперь эта страница даже в стандартной модели представляет собой целую иерархию объектов, которые не нужно грузить все сразу. Каналы стали такими быстрыми, а страницы такими большими, что TCP уже неадекватен для "реактивных" on-line приложений, как несущий протокол (хотя формально HTTP как формат заголовков к нему отношения не имеет, но все же в стандарте явно указывается, что HTTP использует TCP и такова практика). Прокси и кэши для обеспечения работы миллионов клиентов должны быть как можно более быстрыми, в идеале даже аппаратными - а HTTP подразумевает парсинг [и переписывание] текстовых заголовков на промежуточных узлах. Концепция Web 2.0 предполагает, что пользователь интерактивно работает с сайтом - а в HTTP нет четкого понятия сессии и обратной связи с пользователем.
Да отличный протокол, кто бы спорил - для своего времени вообще замечательный!
Только мир ушел далеко вперед с тех времен, когда нужно было просто потоком передать статическую страницу гипертекста с сервера на клиент. Теперь эта страница даже в стандартной модели представляет собой целую иерархию объектов, которые нужно грузить управляемо. Каналы стали такими быстрыми, а страницы такими большими, что TCP уже неадекватен для "реактивных" on-line приложений, как несущий протокол - один пакет где-то застревает и мы имеем задержку в секунды или дясятки секунд на всю страницу. Формально HTTP (как формат заголовков) к TCP отношения не имеет, но все же в стандарте явно указывается, что HTTP использует TCP и такова практика. Прокси и кэши для обеспечения работы миллионов клиентов должны быть как можно более быстрыми, в идеале даже аппаратными - а HTTP подразумевает полноценный парсинг [и переписывание] текстовых заголовков на промежуточных узлах. Концепция Web 2.0 предполагает, что пользователь интерактивно работает с сайтом - а в HTTP нет четкого понятия сессии и обратной связи с пользователем. Например, попробуйте написать на HTTP будильник или уведомить человека о приходе ему почты без поллинга, который создает траффик и жрет ресурсы Вашего сервера.
Только мир ушел далеко вперед с тех времен, когда нужно было просто потоком передать статическую страницу гипертекста с сервера на клиент. Теперь эта страница даже в стандартной модели представляет собой целую иерархию объектов, которые нужно грузить управляемо. Каналы стали такими быстрыми, а страницы такими большими, что TCP уже неадекватен для "реактивных" on-line приложений, как несущий протокол - один пакет где-то застревает и мы имеем задержку в секунды или дясятки секунд на всю страницу. Формально HTTP (как формат заголовков) к TCP отношения не имеет, но все же в стандарте явно указывается, что HTTP использует TCP и такова практика. Прокси и кэши для обеспечения работы миллионов клиентов должны быть как можно более быстрыми, в идеале даже аппаратными - а HTTP подразумевает полноценный парсинг [и переписывание] текстовых заголовков на промежуточных узлах. Концепция Web 2.0 предполагает, что пользователь интерактивно работает с сайтом - а в HTTP нет четкого понятия сессии и обратной связи с пользователем. Например, попробуйте написать на HTTP будильник или уведомить человека о приходе ему почты без поллинга, который создает траффик и жрет ресурсы Вашего сервера.
Вот Вам пример - отсутствие поддержки сессий и транзакций в HTTP приводит к тому, что подвисший при загрузке на сервер мой комментарий опубликовался вместе с его новой редакцией, которую я послал позже увидев, что первое окно браузера висит и убив его.
отсутствие поддержки сессий разве не изза использования TCP происходит?
да, ужасно. всем нам нужен добрый дядя который подарит всем сказку.
при любых недостатках у "хаотического нагромождения исторического наследия и хаков" есть одно преимущество: оно работает. это совсем не мало.
при любых недостатках у "хаотического нагромождения исторического наследия и хаков" есть одно преимущество: оно работает. это совсем не мало.
И пусть работает, я разве призываю всех выйти из browser-а?
Но если уж делать что-то новое, research какой-то в области языков, то зачем дальше городить новые наслоения? Предлагаю эту энергию пустить на разработку действительно свежих концепций. Например, функциональных языков. Или таких языков, которые позволят писать приложения автоматически разделяя работу между клиентом и сервером. Или на универсальные системы управления динамическим контентом без программирования. Сколько можно тянуть и нагромождать слой за слоем на старое, погрязая все глубже в дырах и концептуальных проколах прошлого.
Но если уж делать что-то новое, research какой-то в области языков, то зачем дальше городить новые наслоения? Предлагаю эту энергию пустить на разработку действительно свежих концепций. Например, функциональных языков. Или таких языков, которые позволят писать приложения автоматически разделяя работу между клиентом и сервером. Или на универсальные системы управления динамическим контентом без программирования. Сколько можно тянуть и нагромождать слой за слоем на старое, погрязая все глубже в дырах и концептуальных проколах прошлого.
этакие pdf'ки, вариант интересный. насколько я понимаю, "убрать из browser-а всю логику и превратить его в формальную систему отображения" было бы здорово, если бы ответ от сервера (или сигнал из сети, если от http абстрагироваться) читало нечто :) да таже операционка. операционка, правда, тоже не одна-единственная, но уже много стабильнее.
только встает вопрос интерактивности :)
js-фреймворки люди юзают, судя по моей практике (я, собсно, верстальщик), исключительно по не умению: не умению отправить post-запрос, не умению работы с DOM'ом, не умению отсортировать таблицу по столбцу. но в любом из-за интреактивности, а значит, оно потребно. если бы перекинуть и её (интерактивность) в нечто единое и стабильное, было бы очень и очень круто. а вот как этому нечту избежать долгий и мучительный процесс становления?
только встает вопрос интерактивности :)
js-фреймворки люди юзают, судя по моей практике (я, собсно, верстальщик), исключительно по не умению: не умению отправить post-запрос, не умению работы с DOM'ом, не умению отсортировать таблицу по столбцу. но в любом из-за интреактивности, а значит, оно потребно. если бы перекинуть и её (интерактивность) в нечто единое и стабильное, было бы очень и очень круто. а вот как этому нечту избежать долгий и мучительный процесс становления?
блин, не туда отписал :(
... а закончили заупокой :)
я с Вами согласен. по крайней мере, в том смысле, что текущее состояние распространенных (!) клиент-серверных реализация (html+js+css+ajax+flash+cookies+uri) - это каша из нагромождений наследуемых стандартов и маркетинга. но будьте реалистом. революцию сделать не получится.
мы хотим читать новости и тут же ставить свою оценку статье. при этом мы не хотим каждый раз устанавливать новое ПО на свои машины. придумайте что-то такое, чтобы пользователь прямо _сейчас_ мог это осуществить, сделайте так, чтобы программистам было гораздо проще писать серверную часть и тогда вы заработаете кучу денег на патенте :)
но статья-то не про то :) статья про новое веяние в ЯЗЫКАХ, а не в web. JS - это ЯЗЫК программирования. просто он используется в броузерах.
я с Вами согласен. по крайней мере, в том смысле, что текущее состояние распространенных (!) клиент-серверных реализация (html+js+css+ajax+flash+cookies+uri) - это каша из нагромождений наследуемых стандартов и маркетинга. но будьте реалистом. революцию сделать не получится.
мы хотим читать новости и тут же ставить свою оценку статье. при этом мы не хотим каждый раз устанавливать новое ПО на свои машины. придумайте что-то такое, чтобы пользователь прямо _сейчас_ мог это осуществить, сделайте так, чтобы программистам было гораздо проще писать серверную часть и тогда вы заработаете кучу денег на патенте :)
но статья-то не про то :) статья про новое веяние в ЯЗЫКАХ, а не в web. JS - это ЯЗЫК программирования. просто он используется в броузерах.
Да, но чем JS примечателен по сравнению с другими языками? Как компилируемый язык он никакой даже в принципе, а как интерпретируемый (динамический)... Зачем мы используем такие языки? Чтобы быстро разработать приложение. Я смотрю, как программисты отлаживают и доводят AJAX-сайты на JavaScript и я четко понимаю и даже вижу примеры из жизни, что сделать намного более стабильное десктопное приложение с той же функциональностью даже проще, а в работе оно получится rock-solid. Даже если его дополнить back-end-ом в виде удаленного сервера, то работа по крайней мере сопоставима по объемам. Просто это не вписывается в современную маркетинговую модель.
То есть, JavaScript плохо справляется со своей основной задачей. Написать на нем user-ский front-end не намного проще, чем на каком-нибудь C++ + QT. Даже если и проще - то не принципиально. Если учитывать время отладки и доводки, а не только время на набрасывание на коленке прототипной демо-версии. И качество приложения получается ниже. И в чем же тогда прикол?
То есть, JavaScript плохо справляется со своей основной задачей. Написать на нем user-ский front-end не намного проще, чем на каком-нибудь C++ + QT. Даже если и проще - то не принципиально. Если учитывать время отладки и доводки, а не только время на набрасывание на коленке прототипной демо-версии. И качество приложения получается ниже. И в чем же тогда прикол?
1) статья про динамические языки, а не про применение их в web
2) прикол в маркетинге и том, что js поддерживается большинством броузеров, вот и все :)
2) прикол в маркетинге и том, что js поддерживается большинством броузеров, вот и все :)
Я написал программу на Си для windows и она не работает в линуксе, даже с хаками =((((
PS> http://developer.mozilla.org/presentatio… (js2.0)
PS> http://developer.mozilla.org/presentatio… (js2.0)
А я написал, и она работает без хаков :) SDL и GTK рулят :)
Я где-то противопоставляю "C" и JavaScript?
Речь вообще о другом - ЗАЧЕМ тратить деньги и время лучших программистов на ускорение исполнения JavaScript (как предположил автор доклада), то есть на вылизывание изживших себя, полностью превратившихся в нагромождение хаков старых технологий современного Web, если можно потратить эту энергию на разработку НОВЫХ ИДЕЙ!
Пусть будут новые языки - подходящие для параллельного программирования, и/или существенно упрощающие создание интерактивных распределенных приложений, в которых данные хранятся не на стороне клиента и весь контент динамический. Но ЗАЧЕМ тратить силы на доведение до блеска run-time сред от полностью погрязших в маразме и наслоениях старых систем?
Речь вообще о другом - ЗАЧЕМ тратить деньги и время лучших программистов на ускорение исполнения JavaScript (как предположил автор доклада), то есть на вылизывание изживших себя, полностью превратившихся в нагромождение хаков старых технологий современного Web, если можно потратить эту энергию на разработку НОВЫХ ИДЕЙ!
Пусть будут новые языки - подходящие для параллельного программирования, и/или существенно упрощающие создание интерактивных распределенных приложений, в которых данные хранятся не на стороне клиента и весь контент динамический. Но ЗАЧЕМ тратить силы на доведение до блеска run-time сред от полностью погрязших в маразме и наслоениях старых систем?
Вы путаете выртуальную машину ECMAScript и следование браузеров стандартам
http://en.wikipedia.org/wiki/Tamarin_(JIT)
флеш плох?
http://en.wikipedia.org/wiki/Tamarin_(JIT)
флеш плох?
хабр съел ссылку, но думаю понятно куда сходить почитать :)
Уже вложены миллиарды долларов в разработку байт-кода, JIT и всей технологии, связанной с Java. Зачем еще раз повторять вообще тоже самое, но с другим front-end языком? Не лучше ли вложить миллиарды долларов в что-то продвигающее технологии действительно вперед. Например, в те же функциональные языки, по типу Erlang и Haskell. Они теоретически могут вывести на новый уровень параллелизм программ. Или потратить усилия и деньги пусть не на новые технологии, но на что-то базисное, фундаментальное для написания остального софта. Например, создать новый язык системного программирования, который подходил бы для современных мульти-процессоров и заменил бы собой "C". Или вообще пойти в другую сторону, и поработать над технологиями, которые позволят создавать КАЧЕСТВЕННЫЕ и полностью динамические сайты без привлечения настоящих программистов. А зачем делать очередной JIT по типу предыдущего для языка, который ничего принципиально нового нам не даст?
Нет оригинальных концепций? Ну сейчас это самый популярный прототипный (а не ООП) язык программирования.
На счет этого всего можно вот что сказать:
Сейчас всё стремится к простоте. К простоте разработки программного обеспечения. Важно понимать как все происходит в этой отрасли. Тут основная проблема не в кишках уже :-) Не в том, на каком языке программирования все это делается. Многим скоро на это на все будет просто наплевать. Тут проблема в другом. Проблема – в развитии людей/программистов. В понимании философии программной индустрии.
Люди/программеры все больше ведутся на эффект. Что такое эффект?
Под эффектом я и подразумеваю "простоту".
Что проще ребёнку понять?
1. Код / философию программирования
2. Графическую информацию в виде образов (схем, диаграмм и прочего).
Ответ – 2.
IDE как раз нам и даёт эту простоту вместе с графикой ;)
Так что вывод мой вот в чем (имхо):
Динамические языки не в большей степени уже не будут развиваться. Все приоритеты направлены уже не на это. А на визуализацию. На мощные IDE и не менее главную вещь – на технологии разработки ПО.
Сейчас всё стремится к простоте. К простоте разработки программного обеспечения. Важно понимать как все происходит в этой отрасли. Тут основная проблема не в кишках уже :-) Не в том, на каком языке программирования все это делается. Многим скоро на это на все будет просто наплевать. Тут проблема в другом. Проблема – в развитии людей/программистов. В понимании философии программной индустрии.
Люди/программеры все больше ведутся на эффект. Что такое эффект?
Под эффектом я и подразумеваю "простоту".
Что проще ребёнку понять?
1. Код / философию программирования
2. Графическую информацию в виде образов (схем, диаграмм и прочего).
Ответ – 2.
IDE как раз нам и даёт эту простоту вместе с графикой ;)
Так что вывод мой вот в чем (имхо):
Динамические языки не в большей степени уже не будут развиваться. Все приоритеты направлены уже не на это. А на визуализацию. На мощные IDE и не менее главную вещь – на технологии разработки ПО.
Ну :) Тогда нам - unix'оидам - светит хорошее будущее. Потому что, реально, то, что в IDE делается за 10 минут кликания мышкой по всяким потаёным местам в shell пишется за 30 секунд в одну строчку. Это реальный опыт с программистских соревнований.
Ноя я думаю, что вы не правы в этом вопросе, и таки жить будет сложно всём. На самом деле, основная мощ в IDE идёт не от графики, а от возможности проводить глобальные преобразования кода. Но на самом деле, по сравнению с суперкомпиляцией (вспоминаем великий и ужасный Refal) нынешние IDE весьма примитивны.
Ноя я думаю, что вы не правы в этом вопросе, и таки жить будет сложно всём. На самом деле, основная мощ в IDE идёт не от графики, а от возможности проводить глобальные преобразования кода. Но на самом деле, по сравнению с суперкомпиляцией (вспоминаем великий и ужасный Refal) нынешние IDE весьма примитивны.
>>> Никто не знает, насколько быстрыми могут быть динамические языки, если ими всерьёз заняться.
Я считаю, что графическое представление удобно только для разработки интерфейсов (и интерфейсной логики). Успех GUI никак нельзя автоматически интерполировать на все отрасли IT. Программа, алгоритм, сама является не графической сущность. Программировать рисую — это, если можно сравнить, всё равно что писать стихи картинками. Можно, но бессмысленно :). Думаю не надо приводить огромное количестве провалов очередныз графических языков программирования.
Но согласен, что языки становятся более понятны. Например, Ruby многим нравиться, потому что он очень близко идёт к английским предложениям (потому что текст и программа близкие сущности). Например, реализация assertEquals(x, y) в RSpec:
x.should == y
Но согласен, что языки становятся более понятны. Например, Ruby многим нравиться, потому что он очень близко идёт к английским предложениям (потому что текст и программа близкие сущности). Например, реализация assertEquals(x, y) в RSpec:
x.should == y
И снова я не согласен.
А Ruby, да тот же Python?
Хорошему языку всегда есть место и не мы, так наши дети освоят их и будут утирать нам нос. Я по доброму завидую тем, кто начал с Ruby, они одной строчной могут писать то, что мы писали в десятки на ASM.
Уверен появятся и гибкие, элегантные низкоуровневые языки программирования, которые будут сродни Ruby но альтернативой ASM.
Языки отнюдь не упрощаются, мы просто переосмысливаем философию программирования.
А Ruby, да тот же Python?
Хорошему языку всегда есть место и не мы, так наши дети освоят их и будут утирать нам нос. Я по доброму завидую тем, кто начал с Ruby, они одной строчной могут писать то, что мы писали в десятки на ASM.
Уверен появятся и гибкие, элегантные низкоуровневые языки программирования, которые будут сродни Ruby но альтернативой ASM.
Языки отнюдь не упрощаются, мы просто переосмысливаем философию программирования.
Вы оспариваете возможность появление новых языков? Ну Ruby появился ещё в 1995, а становиться популярными только сейчас.
Верно, ну а 2000 появился какой нибудь LifeAMS или RubiBU, который внедряется и используется в какой нибудь закрытой лаборатории и в 2010 станет популярным. Тем более что вы не учитываете фактор появление новых технологи, которые в свою очередь повлекут развитие новых языков программирования.
P.S. По теме "Золотая лихорадка вокруг компиляторов нового поколения"
P.S. По теме "Золотая лихорадка вокруг компиляторов нового поколения"
Мне кажется, что сейчас мы наблюдаем начало всплеска в развитии динамических языков. Началось всё с java script, потом начали развиваться веб-приложения и развиваются по сей день, и тот же AIR... По идее, это всё - логическое продолжение развития языков программирования, начиная от ассемблера - с повышением уровня, и при этом всё больше возлагается на компилятор/интерпретатор, тем самым упрощается собственно разработка.
А вообще от статьи у меня странное впечатление. Типа: а давайте сначала усложним себе производительную жизнь медленными динамическими языками, а потом начнём преодолевать эти сложности. Героизм, конечно... Но если мне нужна будет производительность, мне не нужны будут jit-компиляторы. Я буду выжимать её даже из FPGA, если придётся. В runtime должна остаться только моя программа и никаких других сложных (действительно сложных) штук, вроде jit.
А если я хочу получить хорошую систему за счёт оптимизации высокоуровневой архитектуры, так а почему бы её не оптимизировать и для языков с компиляторами? Можно же думать и в этом направлении. Например, все языкознатели почему-то упорно закрывают глаза на 'C, например. Между тем - реактивная штука с безумной производительностью, благодаря runtime спецификации кода. И контроля над исполнением больше, и гибкости тоже, и вообще это на модульных маршрутизаторах используется на полную катушку.
Непонятно, почему бы не двигаться в этом направлении? Зачем скрывать детали runtime-специализации от программиста? Попытаться придумать хорошие абстракции для этого, и всё. А так всё получается слишком языко-(jvm-, .net-, нечто-)зависимым.
Хотя, конечно, эту фишку с деревьями трасс без jit не сделаешь. Но... Странная она какая-то. А что, если встречается объект, который под трассу не подходит? Всё-равно же if'ы везде нужно будет тыкать.
А если я хочу получить хорошую систему за счёт оптимизации высокоуровневой архитектуры, так а почему бы её не оптимизировать и для языков с компиляторами? Можно же думать и в этом направлении. Например, все языкознатели почему-то упорно закрывают глаза на 'C, например. Между тем - реактивная штука с безумной производительностью, благодаря runtime спецификации кода. И контроля над исполнением больше, и гибкости тоже, и вообще это на модульных маршрутизаторах используется на полную катушку.
Непонятно, почему бы не двигаться в этом направлении? Зачем скрывать детали runtime-специализации от программиста? Попытаться придумать хорошие абстракции для этого, и всё. А так всё получается слишком языко-(jvm-, .net-, нечто-)зависимым.
Хотя, конечно, эту фишку с деревьями трасс без jit не сделаешь. Но... Странная она какая-то. А что, если встречается объект, который под трассу не подходит? Всё-равно же if'ы везде нужно будет тыкать.
Например, все языкознатели почему-то упорно закрывают глаза на 'C, например. Между тем - реактивная штука с безумной производительностью, благодаря runtime спецификации кода.
А можно подробнее про эту штуку? Нагуглить что-то по такому названию проблематично.
А... Да. Оно ещё называется tick C http://pdos.csail.mit.edu/tickc/ . Смысл такой: берём обычный Си и расширяем его оператором compile, который может компилировать код функции, в которую могут быть подставленны значения некоторых переменных, вычисляемых в runtime. Плюс ещё некоторые механизмы подстановки, включая явную развёртку циклов и прочие довольно простые средства.
В итоге можно явно алгоритмически специализировать функции под обрабатываемые данные в runtime.
И вот. Несмотря на то, что compile работает с исходным текстом программы (а не с байткодом каким-нибудь), несмотря на то, что используется компилятор lcc, как ядро (не самый эффективный и быстрый компилятор), программы написанные в этой парадигме просто на куски рвут программы, откомпилированные Intel C/C++ с максимальной оптимизацией.
В итоге можно явно алгоритмически специализировать функции под обрабатываемые данные в runtime.
И вот. Несмотря на то, что compile работает с исходным текстом программы (а не с байткодом каким-нибудь), несмотря на то, что используется компилятор lcc, как ядро (не самый эффективный и быстрый компилятор), программы написанные в этой парадигме просто на куски рвут программы, откомпилированные Intel C/C++ с максимальной оптимизацией.
ведется разговор не про оптимизацию по времени исполнения, а оптимизация по времени разработки и сложности поддержки. я сейчас говорю про тенденцию в эволюции программирования.
зачем нам сборщики мусора? ответ: для того, чтобы проще было писать программы. пусть это влияет на время выполнения, но стоимость разработки будет в несколько раз меньше.
это же относится и к динамическим языкам. возможно, в будущем, будут разработанны методологии, которые позволят разрабатывать приложения гораздо дешевле с использованием именно динамических языков. сейчас таких методологий нет. но вдруг появятся?
зачем нам сборщики мусора? ответ: для того, чтобы проще было писать программы. пусть это влияет на время выполнения, но стоимость разработки будет в несколько раз меньше.
это же относится и к динамическим языкам. возможно, в будущем, будут разработанны методологии, которые позволят разрабатывать приложения гораздо дешевле с использованием именно динамических языков. сейчас таких методологий нет. но вдруг появятся?
Хм :) Вы просто не видели тех людей, которые месяцами утечки памяти в java-программах. Да, налабать код быстрее получается. Да, с иллюзией того, что всё работае и что среда обо всём позаботилась. А потом начинаются забытые ссылки в различных структурах данных. Как следствие, оставленные открытыми файль, сериализации по сети гигабайтных объёмов, улетающая в трубу память. И обнаруживается это уже после внедрения в производство. Хых. Это на самом деле очень печальные истории. Я лично знаком со случаем, когда из-за такого вот бага человек налетел на огромные деньги и не по своей вине. Хорошо хоть, что без жертв обошлось.
А в Си эти ситуации вылавливаются довольно просто на этапе отладки. Через segmentation fault'ы.
Вот. И, imho, дело всё же не в динамизме, а в уровне абстракций тех примитивов, которыми позволяет оперировать язык.
А в Си эти ситуации вылавливаются довольно просто на этапе отладки. Через segmentation fault'ы.
Вот. И, imho, дело всё же не в динамизме, а в уровне абстракций тех примитивов, которыми позволяет оперировать язык.
я бы не был столь категоричен. все-таки дело больше в программистах, а не в языке (за редким исключением).
можно писать с утечками памяти и на c/c++ и на java. я уважаю c и c++. с c++ я начал думать "в классах". более того, я считаю, что учиться ООП следует именно на c++, а не на java.
но ей богу, писать спец. приложения проще на j2ee/.net, в управляемой среде, чем на чистом c/c++, какое бы кол-во библиотек не было испоьлзовано.
это мое личное мнение. Вы вполне можете его не разделять.
можно писать с утечками памяти и на c/c++ и на java. я уважаю c и c++. с c++ я начал думать "в классах". более того, я считаю, что учиться ООП следует именно на c++, а не на java.
но ей богу, писать спец. приложения проще на j2ee/.net, в управляемой среде, чем на чистом c/c++, какое бы кол-во библиотек не было испоьлзовано.
это мое личное мнение. Вы вполне можете его не разделять.
Учится ООП, imho, нужно на ассемблере. Чтобы понимать, что там к чему и как происходит.
Вот. А насчёт приложений. Их нужно писать на нескольких языках. И использовать unix'овскую парадигму процессов, для управления ресурсами. Очень эффективно работает. И очень гибко - можно варьировать всё между быстро написать/выполнить.
Не, я, конечно, понимаю, что настоящий русский мужик может дом одним топором построить. Но зачем пренебрегать удобными инструментами? Зачем привязываться к только одному языку? У всего есть слабые места.
Вот. А насчёт приложений. Их нужно писать на нескольких языках. И использовать unix'овскую парадигму процессов, для управления ресурсами. Очень эффективно работает. И очень гибко - можно варьировать всё между быстро написать/выполнить.
Не, я, конечно, понимаю, что настоящий русский мужик может дом одним топором построить. Но зачем пренебрегать удобными инструментами? Зачем привязываться к только одному языку? У всего есть слабые места.
извините, но с Вами не согласен.
Учится ООП, imho, нужно на ассемблере. Чтобы понимать, что там к чему и как происходит.
Это какие же есть фундаментальные характеристики ООП, которые можно разглядеть на уровне ассемблера? Общие для C++, Java, Smalltalk, CLOS, you name it? Проблема деревьев и леса, как мне кажется. Толковый специалист разберётся в механике происходящего и после понимания высокоуровневых концепций.
Не, я, конечно, понимаю, что настоящий русский мужик может дом одним топором построить. Но зачем пренебрегать удобными инструментами? Зачем привязываться к только одному языку?
Настоящий мужик как раз соорудит вязанку из трёх любимых языков. Только мало вокруг таких настоящих, которые потом это поддерживать будут :-)
Language interoperability — тоже своего рода Holy Grail.
Это какие же есть фундаментальные характеристики ООП, которые можно разглядеть на уровне ассемблера? Общие для C++, Java, Smalltalk, CLOS, you name it? Проблема деревьев и леса, как мне кажется. Толковый специалист разберётся в механике происходящего и после понимания высокоуровневых концепций.
Никаких нет :) Именно поэтому и надо учить на ассемблере, чтобы понять, что there is no spoon :) то есть ооп. Что всё ООП про интерфейсы и про позднее связывание, коего может быть в различных вариантах привеликое множество: от виртуальных функций в Си++ до прототипов в Smalltalk. А ещё можно ещё чего-нибудь интересное написать и самому.
Никаких нет :) Именно поэтому и надо учить на ассемблере, чтобы понять, что there is no spoon :) то есть ооп. Что всё ООП про интерфейсы и про позднее связывание, коего может быть в различных вариантах привеликое множество: от виртуальных функций в Си++ до прототипов в Smalltalk. А ещё можно ещё чего-нибудь интересное написать и самому.
Учится ООП, imho, нужно на ассемблере. Чтобы понимать, что там к чему и как происходит.
И каким образом ассемблер приближает к пониманию ООП?
Работать с внешними библиотеками (сложными) в C++ действительно очень сложно - согласен с Вами! Даже в чистом C сложновато, а в C++ зачастую попросту невозможно нормально совместить два разных больших пакета (со своей идеологией).
а ежели у вас segfault случается раз в двести лет, когда звезды в ряд становится и древнее зло просыпается?
вот возьмёт и у вас во время тестирования не вылезет, а к клиенту отправите --- порвёт все на кусочки...
вот возьмёт и у вас во время тестирования не вылезет, а к клиенту отправите --- порвёт все на кусочки...
Не спится... Ну, да ладно, за опечатки прошу прощения.
Так это и есть процесс отладки. Клиент сказал - вот у меня тут глюки. И я их исправлю. С GC же проблема в том, что этот глюк может быть выявлен очень-очень-очень поздно. И его выловить будет просто теоретически невозможно. Забытая ссылка - никак на целостность системы не влияет и вполне себе корректна с точки зрения runtime.
В Си (условно) я могу воспользоваться кучей инструментов для отлова таких ситуаций. Начиная с CINT, и заканчивая electric fence. И эти инструменты эффективно работают. Даже теория некая есть для расчёта вероятности отлова ошибки, и вероятность очень высока.
В языках же с GC это сделать просто невозможно. Логика у них работы такая. Поэтому приходится всегда за собой чистить (= null писать на каждый чих). Но тут легко ошибиться так, что это не будет ошибкой в runtime.
Так это и есть процесс отладки. Клиент сказал - вот у меня тут глюки. И я их исправлю. С GC же проблема в том, что этот глюк может быть выявлен очень-очень-очень поздно. И его выловить будет просто теоретически невозможно. Забытая ссылка - никак на целостность системы не влияет и вполне себе корректна с точки зрения runtime.
В Си (условно) я могу воспользоваться кучей инструментов для отлова таких ситуаций. Начиная с CINT, и заканчивая electric fence. И эти инструменты эффективно работают. Даже теория некая есть для расчёта вероятности отлова ошибки, и вероятность очень высока.
В языках же с GC это сделать просто невозможно. Логика у них работы такая. Поэтому приходится всегда за собой чистить (= null писать на каждый чих). Но тут легко ошибиться так, что это не будет ошибкой в runtime.
В языках с GC вы можете попросить runtime дать вам дамп кучи. А потом методом внимательного взгляда понять что к чему.
Скажем так, те ошибки, на которые вы указываете для языков с автоматическим управлением памятью, точно также свойственны и языкам с явным управлением: потеряли вы в C указатель и привет семье (причем заметим, что к segfault это не приведёт, просто ресурсы "утекать" начнут, так что не обязательно во время тестирования выявится), нужно расчехлять valgrind или efence, причем может так оказаться, что развертывать это отладочное окружение нужно будет на стороне клиента. А в некоторых управляемых средах вам и развертывать ничего не надо: цепляетесь к запущенному под VM приложению по официальному отладочному интерфейсу и начинаете шукать по сусекам, где чего лишнего осталось.
С другой стороны нельзя не признать, что например C++ благодаря автоматическому вызову деструкторов для стековых объектов делает возможным написание очень красивого кода для управления ресурсами (RAII --- Resource Acquisition Is Initialization), в той же Java приходится во все дырки finally затыкать.
Скажем так, те ошибки, на которые вы указываете для языков с автоматическим управлением памятью, точно также свойственны и языкам с явным управлением: потеряли вы в C указатель и привет семье (причем заметим, что к segfault это не приведёт, просто ресурсы "утекать" начнут, так что не обязательно во время тестирования выявится), нужно расчехлять valgrind или efence, причем может так оказаться, что развертывать это отладочное окружение нужно будет на стороне клиента. А в некоторых управляемых средах вам и развертывать ничего не надо: цепляетесь к запущенному под VM приложению по официальному отладочному интерфейсу и начинаете шукать по сусекам, где чего лишнего осталось.
С другой стороны нельзя не признать, что например C++ благодаря автоматическому вызову деструкторов для стековых объектов делает возможным написание очень красивого кода для управления ресурсами (RAII --- Resource Acquisition Is Initialization), в той же Java приходится во все дырки finally затыкать.
ВСё то же самое можно сделать и для языков без GC. Я же не зря про CINT говорил. И забытые в памяти объекты он вам найдёт. Я же немного про другое говорю.
Я говорю про неуничтоженные объекты, которые больше не используются с точки зрения логики программы, но не с точки зрения runtime (забыли ссылку в дереве, списке, массиве, etc) Если у нас есть явное free, которое вызывается где-то в программе, то такая забытая ссылка уже является ошибкой runtime и отлавливается инструментами автоматически.
Да дампы памяти помогают, теоретически. Но а если у вас 16GiB относительно небольших объектов? Придётся ещё писать анализатор дампа на Python'е :). И люди это реально делали, чтобы вправить мозги одной системе.
Я говорю про неуничтоженные объекты, которые больше не используются с точки зрения логики программы, но не с точки зрения runtime (забыли ссылку в дереве, списке, массиве, etc) Если у нас есть явное free, которое вызывается где-то в программе, то такая забытая ссылка уже является ошибкой runtime и отлавливается инструментами автоматически.
Да дампы памяти помогают, теоретически. Но а если у вас 16GiB относительно небольших объектов? Придётся ещё писать анализатор дампа на Python'е :). И люди это реально делали, чтобы вправить мозги одной системе.
Точно также вы можете забыть ссылку и в программе на С, а можете даже не просто забыть, а потерять. И придётся изучать те же самые дампы.
Но вероятность забыть и ссылку и забыть сделать free меньше, чем вероятность просто забыть ссылку.
кхе-кхе, вам нужно помнить (или проверять автоматическими тулами), что перед каждым изменением поля указателя возможно необходимо вставить free, т.е. вы хотите сказать, что необходимость делать больше работы улучшает память программиста?
Хм... Таких сценариев, обычно не бывает. Нужно помнить о том, где ресурс выделяется, и где он освобождается. И всё. Места эти, обычно, хорошо локализованы. Да и подход стимулирует их не разбрасывать по всей программе, что упрощает систему и улучшает качество кода.
Я как-то проводил тупой анализ кода... Кажется, на исходниках какой-то нетривиальной игрушки. Так вот, там было только 4 new/delete на 1000 строк кода. Так ли уж страшна проблема, как её малюют коммерческие языкоделатели?
Я как-то проводил тупой анализ кода... Кажется, на исходниках какой-то нетривиальной игрушки. Так вот, там было только 4 new/delete на 1000 строк кода. Так ли уж страшна проблема, как её малюют коммерческие языкоделатели?
Со стороны клиента автоматическая сборка мусора не вызывает никаких нареканий. Но на сервере из-за нее происходит трешинг кэшей процессора и задержки в обработке запросов (во время обхода кучи сборщиком мусора). Особенно непонятно, как совместить ее с мультитредностью нормально. Поэтому для быстродействующих приложений языки со сборкой мусора плохо подходят - ну разве что если запускать каждый их скрипт со своей кучей и уничтожать ее побыстрее, вместе со всеми данными. :)
Но на сервере из-за нее происходит трешинг кэшей процессора и задержки в обработке запросов (во время обхода кучи сборщиком мусора).
Во-первых, кеши все больше и больше. Во-вторых, седовласые старцы тоже не зря свои бутерброды кушают и изобретают различные подходы к GC позволяющие кэшем меньше шебуршать, да и вообще всякие real-time GC. Ну и наконец, есть всякие железные ухищрения, см. например Azul Systems.
Во-первых, кеши все больше и больше. Во-вторых, седовласые старцы тоже не зря свои бутерброды кушают и изобретают различные подходы к GC позволяющие кэшем меньше шебуршать, да и вообще всякие real-time GC. Ну и наконец, есть всякие железные ухищрения, см. например Azul Systems.
Язык без указателей и при этом не тормозящий в мутьтитредной среде - это как философский камень. Кто из системных программистов не пытался найти решение проблемы такого аллокатора памяти? Но особых сдвигов нет за десятилетия - точнее решения не оправдывают себя, слишком много вносят накладных расходов. Есть только полу-меры, типа разных куч для объектов разных поколений или заказанных на разных процессорах и т.п. А покупать особое железо для своих серверов - это вообще путь в никуда. Во сколько Вам это обойдется, если понадобятся тысячи машин? Можете ли Вы рисковать своим бизнесом, завязываясь на одного поставщика уникального, ни с чем не совместимого железа? Это еще хуже, чем купить майнфрейм. :)
Язык без указателей и при этом не тормозящий в мутьтитредной среде - это как философский камень.
Кхе-кхе, чего-то я не особо секу как наличие указателей ускоряет собственно аллокацию. Не поясните ли? (если же поговорить о распараллеливание, так как раз из-за указателей и проблемы вылезут. зависимость по данным отследить --- это надо пуд соли съесть.)
Если говорить об ускорении аллокации, то Thread Local Heap'ы пока никто не отменял.
Кхе-кхе, чего-то я не особо секу как наличие указателей ускоряет собственно аллокацию. Не поясните ли? (если же поговорить о распараллеливание, так как раз из-за указателей и проблемы вылезут. зависимость по данным отследить --- это надо пуд соли съесть.)
Если говорить об ускорении аллокации, то Thread Local Heap'ы пока никто не отменял.
Наличие явных указателей, как в C[++] предполагает как бы, что программист сам явно и отменяет память (не считая автоматической деаллокации объектов, созданных на стеке). Если же указателей нет, то это не обязательно в теории, но на практике всегда ведет к сборке мусора - нет явной деаллокации. Где сборка мусора - там проблемы с параллельностью. Программа в другом треде из машинного кода лезет в неизвестно какой блок памяти и мы не имеем над этим контроля. Или имеем контроль - но тогда мы уже отказываемся от прямой генерации нормального машинного кода и работаем с памятью через промежуточный слой и добавляем на каждое обращение еще несколько машинных команд. В результате - замедление вычислительно-емких или интенсивно обрабатывающих структуры данных программ в РАЗЫ. Решения проблемы требуют или использования особого железа, или же интеллектуального переключателя задач, специального компилятора и разметки машинного кода. Чего на практике мы не имеем.
Ась? Вы так и не ответили на мой вопрос... Почему аллокация-то разгонятся... Нету в вашем комментарии слов "аллокация"/"выделение", а есть куча общих слов о том, что GC --- это бяка. Насколько я понял, вы про read/write барьеры говорите. Так ведь некоторое их количество и поудалять можно на основе статического анализа.
На практике мы всё имеем: и специальные компиляторы и особое железо (Azul Systems).
На практике мы всё имеем: и специальные компиляторы и особое железо (Azul Systems).
Потому что указатели просто напросто намного проще. Чтобы выделить память, вам нужно войти в критическую секцию, найти свободный блок в виртуальной памяти (и скорее всего, для этого вы просто вытащите первый попавшийся кусок из пула), и вернуть ссылку. Всё. Для освобождения, вам нужно будет войти в секцию и вернуть объект в очередь.
С толстыми ссылками (со счётчиками и косвенной адрессацией) вам нужно выделять память и под ссылку ещё. Время пребывания в критической секции увеличивается. Удаление тоже будет усложнено.
С указателями и (это как по русски-то?) сборщиками с поколениями, вы используете тот же самый пул для выделения, но освобождение памяти - это поиск областей связности в графе, который меняется несколькими нитями. А вот это настоящий гипермегагеморрой. Попробуйте реализовать такой алгоритм сами. Может, у вас выйдет, конечно :) Тогда вы станете гуру одномоментно.
Похоже, фундаментальная проблема здесь в том, что в GC вам нужно учитывать маловероятные сценарии поведения приложения, чтобы система не разрушилась, и для учёта этих сценариев надо наворачивать дополнительный код.
А если у вас ручное управление памятью, то да, вы можете развалить систему этим кривым маловероятным поведением, но зато хорошее и не кривое решение будет более производительным.
С толстыми ссылками (со счётчиками и косвенной адрессацией) вам нужно выделять память и под ссылку ещё. Время пребывания в критической секции увеличивается. Удаление тоже будет усложнено.
С указателями и (это как по русски-то?) сборщиками с поколениями, вы используете тот же самый пул для выделения, но освобождение памяти - это поиск областей связности в графе, который меняется несколькими нитями. А вот это настоящий гипермегагеморрой. Попробуйте реализовать такой алгоритм сами. Может, у вас выйдет, конечно :) Тогда вы станете гуру одномоментно.
Похоже, фундаментальная проблема здесь в том, что в GC вам нужно учитывать маловероятные сценарии поведения приложения, чтобы система не разрушилась, и для учёта этих сценариев надо наворачивать дополнительный код.
А если у вас ручное управление памятью, то да, вы можете развалить систему этим кривым маловероятным поведением, но зато хорошее и не кривое решение будет более производительным.
Полностью поддерживаю
жжоте, неудачный у вас примерчик... уже то, что вам надо входить в критическую секцию аукнется на любой более менее активно аллоцирующей в нескольких потоках программе. ну это ладно.
вы можете мне объяснить что мешает скажем Java программе делать почти тоже самое --- найти блок подходящего размера и отдать его программе?
Оставим в стороне счетчик ссылок, но даже glibc дополнительно к запрошенному куску памяти выделаяет еще место под заголовок. Так что оверхеда никакого особого нет. Вообщем никаких доказательств того, что аллокаторы в неуправляемых средах будут работать быстрее я пока так и не увидел.
Теперь что касается удаления. Да, даже при применении различных ухищрений (различные виды incremental/concurrent collection) эта операция дольше чем просто вызов delete/free/VirtualFreeEx. Однако это замедление в общем случае не настолько значительное, чтобы городить велосипед ручного управления памятью. Написать нормальный ручной аллокатор/деаллокатор фактически означает переписать некоторую часть среды управления памятью из какой-нибудь VM. Ну и нафиг это нужно среднестатистическому программисту?
вы можете мне объяснить что мешает скажем Java программе делать почти тоже самое --- найти блок подходящего размера и отдать его программе?
Оставим в стороне счетчик ссылок, но даже glibc дополнительно к запрошенному куску памяти выделаяет еще место под заголовок. Так что оверхеда никакого особого нет. Вообщем никаких доказательств того, что аллокаторы в неуправляемых средах будут работать быстрее я пока так и не увидел.
Теперь что касается удаления. Да, даже при применении различных ухищрений (различные виды incremental/concurrent collection) эта операция дольше чем просто вызов delete/free/VirtualFreeEx. Однако это замедление в общем случае не настолько значительное, чтобы городить велосипед ручного управления памятью. Написать нормальный ручной аллокатор/деаллокатор фактически означает переписать некоторую часть среды управления памятью из какой-нибудь VM. Ну и нафиг это нужно среднестатистическому программисту?
Я разве примеры приводил? :) Я описал общую схему, вроде как.
Вот. Но вот какая ошибка очевидная есть в ваших рассуждениях: процедуры освобождения ресурсов работают с точно теми же структурами данных, с которыми работают процедуры выделения ресурсов. Для сборки мусора ВАМ ПРИДЁТСЯ пройтись по графу ссылок, который потенциально (и ОЧЕНЬ ДАЖЕ ВЕРОЯТНО) изменяется во время работы нескольких нитей, и это очень сильно усложняет алгоритм прохода. И этот проход будет влиять и на выделение памяти, и на общую производительность, из-за необходимости синхронизовывать кучу доступов к информации о ресурсах. И это замедление довольно ощутимо / доберусь домой - найду ссылку с результатами тестирования.
Можно, конечно, говорить о чём-то более похожем на процессы, когда у нитей есть своя память и явно объявляемая общая, чтобы хотя бы рост стеков не мешал работе разных нитей. Но это лишь частичное решение проблемы. Если общее состояние приложения сложное, то в общей памяти будут затыки. Если же его можно организовать без ссылок, то зачем нити вообще? Можно использовать процессы, общую память (или какие-нибудь централизованные хранилища) и управление ресурсами прямо на уровне процессов: запустили процесс, он замусорил себе виртуальную память, завершился - за ним всё будет почищено системой.
Лично я бы был готов пойти на жертвы в скорости работы программы, если бы мне давали ощутимо большую мощь в описании алгоритмов и их компановке. Похоже, сборка мусора не является тем средством, которое как-то с этим связано. Посмотрите на shootout.alioth.debian.org - программы на Си в объёме не превосходят программы на Java.
Пока действительно гораздо более мощным, чем Си, средством для меня является bash или rc с набором утилит соответствующих. Но там, вроде как и нет совсем никакой сборки мусора, зато, есть отличные возможности по запуску всего параллельно и сшиванию кучи (под)программ в единое целое.
Вот. Но вот какая ошибка очевидная есть в ваших рассуждениях: процедуры освобождения ресурсов работают с точно теми же структурами данных, с которыми работают процедуры выделения ресурсов. Для сборки мусора ВАМ ПРИДЁТСЯ пройтись по графу ссылок, который потенциально (и ОЧЕНЬ ДАЖЕ ВЕРОЯТНО) изменяется во время работы нескольких нитей, и это очень сильно усложняет алгоритм прохода. И этот проход будет влиять и на выделение памяти, и на общую производительность, из-за необходимости синхронизовывать кучу доступов к информации о ресурсах. И это замедление довольно ощутимо / доберусь домой - найду ссылку с результатами тестирования.
Можно, конечно, говорить о чём-то более похожем на процессы, когда у нитей есть своя память и явно объявляемая общая, чтобы хотя бы рост стеков не мешал работе разных нитей. Но это лишь частичное решение проблемы. Если общее состояние приложения сложное, то в общей памяти будут затыки. Если же его можно организовать без ссылок, то зачем нити вообще? Можно использовать процессы, общую память (или какие-нибудь централизованные хранилища) и управление ресурсами прямо на уровне процессов: запустили процесс, он замусорил себе виртуальную память, завершился - за ним всё будет почищено системой.
Лично я бы был готов пойти на жертвы в скорости работы программы, если бы мне давали ощутимо большую мощь в описании алгоритмов и их компановке. Похоже, сборка мусора не является тем средством, которое как-то с этим связано. Посмотрите на shootout.alioth.debian.org - программы на Си в объёме не превосходят программы на Java.
Пока действительно гораздо более мощным, чем Си, средством для меня является bash или rc с набором утилит соответствующих. Но там, вроде как и нет совсем никакой сборки мусора, зато, есть отличные возможности по запуску всего параллельно и сшиванию кучи (под)программ в единое целое.
Обещанная статья: http://www-cs.canisius.edu/~hertzm/gcmal…
читал я сию статью, безусловно познавательно, как и большинство статей бородатого дяди Хертца. Но вообще не показатель --- там же с оракулярным управлением сравнивается, а оракул он всегда знает лучшую точку, в которой можно удалить объект... Но что самое забавное в заключении там сказано: Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory.
Упс. Это статья об однопоточных сборщиках. Чего-то я не то запостил... А с многонитевыми найти не получается. Там цифры гораздо печальнее были.
Но даже тут. Это же оракул хитрый. Его ещё использовали для того, чтобы чистить память перед malloc'ами. Но обычно, так никто не делает. И даже с этим оверхэдом сборщики в среднем не обгоняют ручное управление памятью.
Но даже тут. Это же оракул хитрый. Его ещё использовали для того, чтобы чистить память перед malloc'ами. Но обычно, так никто не делает. И даже с этим оверхэдом сборщики в среднем не обгоняют ручное управление памятью.
Вообще-то есть ОДНА техника для языков со сборкой мусора, которая не вносит больших накладных расходов. Она известна давно и используется во многих динамических средах. Могу рассказать более и менее подробно, так как сам написал такой аллокатор для одного из бывших проектов.
Делается это так - когда кончается вся память в куче, аллокатор останавливает все треды программы средствами ОС (suspend thread). При этом ОС сохраняет контексты всех тредов (дампы регистров) в памяти. Так как типовая ОС (ни одна известная мне) не имеет вызова для массовой остановки тредов по списку, то останавливаем мы их в цикле. Вызов приостановки треда блокирующий и ждущий, так как иначе мы не были бы уверены, что thread остановлен и его регистры сохранены. В результате по мере остановки других тредов мы сами успеваем (как правило) потерять пару раз управление из-за переключения контекстов. Генерируется куча IPI на мультипроцессорной машине...
Наконец, все треды остановлены. Наш аллокатор запрашивает у ОС контексты всех тредов - так как ему нужно просканировать ВСЕ значения во ВСЕХ регистрах прикладной программы. Мы ищем в каждом из регистров значение, внешне ПОХОЖЕЕ на указатель на блок памяти, находящийся под контролем нашего аллокатора.
Когда находим такой "указатель" - маркируем соответствующий блок как зафиксированный, как и ВСЕ блоки, на которые он ссылается (для этого мы должны получить от компилятора или еще откуда-то описание всех структур данных в программе и рекурсивно обойти все блоки по ссылкам из данного блока).
Далее лезем во все стековые фреймы всех замороженных тредов, находим там все указатели на память и маркируем все блоки, на которые они ссылаются, как живые. И блоки на которые ссылаются эти блоки и т.д., рекурсивно. То есть, применяем классический mark-and-sweep алгоритм для разметки живых блоков и дальнейшего уничтожения мусора.
Блоки, которые маркированы как живые, но не помечены как зафиксированные - можно переместить, если мы в состоянии откорректировать ссылки на них. Это нужно если мы используем generational аллокатор. Без такого аллокатора вообще вся память при mark-and-sweep стратегии сборки мусора будет изведена в момент.
Перемещение блоков - отдельная песня, так как мы должны иметь возможность откорректировать все ссылки на перемещаемые блоки – значит нам нужно уметь трассировать их в обратную сторону.
Вот так это работает.
Требуется поддержка на уровне компилятора - но это не страшно, если у нас свой язык, а не C[++]. Очень большие накладные расходы и торможение в момент приостановки тредов - параллельность вся идет нафик. НО! Так как при использовании ХОРОШЕГО generational аллокатора сборка мусора происходит ОТНОСИТЕЛЬНО РЕДКО, то с этим можно мириться. Накладные расходы на поддержание структур тоже в целом приемлемы, на фоне выгод для программиста от языка без указателей.
Однако есть ВАЖНОЕ ограничение. Этот прием нормально работает (оправдывает себя) только с mark-and-sweep стратегией выявления мусора и подразумевает stopping the world - остановку всех тредов на время сборки.
Из-за этого данная стратегия, наиболее эффективная для исполнения кода на предельной скорости, не подходит для real-time приложений и для серверов, где нужно быстрое время отклика.
Так как в НЕПРЕДСКАЗУЕМЫЕ ЗАРАНЕЕ моменты система "зависает" на неопределенное по большому счету время и начинает собирать мусор. При этом НИ ОДНИН СОДЕРЖАТЕЛЬНЫЙ тред программы не может работать - все стоит раком. Сервер не отвечает на запросы, пока это не кончится, растут очереди. Далее все оживает и начинает снова работать быстро - до следующей сборки мусора...
Кэши все равно трешатся намного сильнее, чем в программах на C[++].
Но, тем не менее, несмотря на все эти минусы, ПРАКТИЧЕСКИ это лучший IMHO алгоритм. Несмотря на его идейную кривизну - например, на то, что иногда он случайное число в регистре какого-то треда ложно трактует как указатель на блок памяти. Все-таки это всего-лишь неэффективность, но не bug.
Делается это так - когда кончается вся память в куче, аллокатор останавливает все треды программы средствами ОС (suspend thread). При этом ОС сохраняет контексты всех тредов (дампы регистров) в памяти. Так как типовая ОС (ни одна известная мне) не имеет вызова для массовой остановки тредов по списку, то останавливаем мы их в цикле. Вызов приостановки треда блокирующий и ждущий, так как иначе мы не были бы уверены, что thread остановлен и его регистры сохранены. В результате по мере остановки других тредов мы сами успеваем (как правило) потерять пару раз управление из-за переключения контекстов. Генерируется куча IPI на мультипроцессорной машине...
Наконец, все треды остановлены. Наш аллокатор запрашивает у ОС контексты всех тредов - так как ему нужно просканировать ВСЕ значения во ВСЕХ регистрах прикладной программы. Мы ищем в каждом из регистров значение, внешне ПОХОЖЕЕ на указатель на блок памяти, находящийся под контролем нашего аллокатора.
Когда находим такой "указатель" - маркируем соответствующий блок как зафиксированный, как и ВСЕ блоки, на которые он ссылается (для этого мы должны получить от компилятора или еще откуда-то описание всех структур данных в программе и рекурсивно обойти все блоки по ссылкам из данного блока).
Далее лезем во все стековые фреймы всех замороженных тредов, находим там все указатели на память и маркируем все блоки, на которые они ссылаются, как живые. И блоки на которые ссылаются эти блоки и т.д., рекурсивно. То есть, применяем классический mark-and-sweep алгоритм для разметки живых блоков и дальнейшего уничтожения мусора.
Блоки, которые маркированы как живые, но не помечены как зафиксированные - можно переместить, если мы в состоянии откорректировать ссылки на них. Это нужно если мы используем generational аллокатор. Без такого аллокатора вообще вся память при mark-and-sweep стратегии сборки мусора будет изведена в момент.
Перемещение блоков - отдельная песня, так как мы должны иметь возможность откорректировать все ссылки на перемещаемые блоки – значит нам нужно уметь трассировать их в обратную сторону.
Вот так это работает.
Требуется поддержка на уровне компилятора - но это не страшно, если у нас свой язык, а не C[++]. Очень большие накладные расходы и торможение в момент приостановки тредов - параллельность вся идет нафик. НО! Так как при использовании ХОРОШЕГО generational аллокатора сборка мусора происходит ОТНОСИТЕЛЬНО РЕДКО, то с этим можно мириться. Накладные расходы на поддержание структур тоже в целом приемлемы, на фоне выгод для программиста от языка без указателей.
Однако есть ВАЖНОЕ ограничение. Этот прием нормально работает (оправдывает себя) только с mark-and-sweep стратегией выявления мусора и подразумевает stopping the world - остановку всех тредов на время сборки.
Из-за этого данная стратегия, наиболее эффективная для исполнения кода на предельной скорости, не подходит для real-time приложений и для серверов, где нужно быстрое время отклика.
Так как в НЕПРЕДСКАЗУЕМЫЕ ЗАРАНЕЕ моменты система "зависает" на неопределенное по большому счету время и начинает собирать мусор. При этом НИ ОДНИН СОДЕРЖАТЕЛЬНЫЙ тред программы не может работать - все стоит раком. Сервер не отвечает на запросы, пока это не кончится, растут очереди. Далее все оживает и начинает снова работать быстро - до следующей сборки мусора...
Кэши все равно трешатся намного сильнее, чем в программах на C[++].
Но, тем не менее, несмотря на все эти минусы, ПРАКТИЧЕСКИ это лучший IMHO алгоритм. Несмотря на его идейную кривизну - например, на то, что иногда он случайное число в регистре какого-то треда ложно трактует как указатель на блок памяти. Все-таки это всего-лишь неэффективность, но не bug.
ну вы просто поджигаете... во-первых, я не совсем понимаю почему вы всё время называете сборщик --- аллокатором, безусловно стратегии аллокации и сборки связанны, но это совсем не одно и тоже. особенно меня поражает "generational аллокатор", это что еще за зверь такой? Сборщики бывают поколенными, это да... Но поколенный аллокатор я слабо себе представляю. Конечно, можно сделать некоторые эвристические предположения или анализ (ключевые слова: prolific types, CBGC) и иногда при выделении памяти сразу выделять память и старого поколения (JVM так поступает для очень больших объектов).
во-вторых, приведенная вами стратегия это уже древний гудрон, старье. в современных высокопроизводительных VM применяются гораздо более сложные алгоритмы, позволяющие на большинстве приложений значительно сократить время GC-пауз.
Вообщем и целом у меня создаётся впечатление, что вы пытаетесь рассуждать о вещах, о которых имеете лишь поверхностное представление.
во-вторых, приведенная вами стратегия это уже древний гудрон, старье. в современных высокопроизводительных VM применяются гораздо более сложные алгоритмы, позволяющие на большинстве приложений значительно сократить время GC-пауз.
Вообщем и целом у меня создаётся впечатление, что вы пытаетесь рассуждать о вещах, о которых имеете лишь поверхностное представление.
Ох, почему на любом русскоязычном форуме чуть ли не любая дискуссия в итоге переходит в терминологические споры и пальцы веером? Какая содержательная разница сказать аллокатор с поколениями или сборщик мусора с поколениями? Будто Вам непонятно, о чем идет речь.
Если нужно предельное быстродействие - то нет отдельно аллокатора и отдельно стратегии сборки мусора. Это только в теории можно отделить их безболезненно. Для выделения памяти в классическом аллокаторе нам нужна структура, которая:
- Быстро находит свободное место нужного размера,
- Не ведет к сильной фрагментации памяти,
- По возможности избегает раздачи блоков из одной линии кэша разным тредам,
- Если это возможно, то не содержит одного глобального mutex-а на всю кучу.
Но стратегия сборки мусора принципиальным образом влияет на выбор алгоритма, например:
- Арена нулевого поколения может быть вообще стеком, если затем блоки будут перенесены в другую память,
- Если сборщик мусора перемещающий, то можно ослабить требование низкой фрагментации и применить более эффективные, но фрагментирующиеся структуры для разметки блоков и для поиска подходящего блока,
- Управление параллельностью при сборке мусора, при аллокации [и возможно при доступе] связаны друг с другом, что приведет или к использованию общей методики защиты от порчи структур из разных тредов, или наоборот – снимет требование не иметь одного глобального mutex-а, что существенно упростит аллокатор.
Вообще при написании аллокатора для мультитредной системы основная головная боль - как избавится от одного глобального лока. На втором месте неразрешимая в классической парадигме проблема разделения строк кэша.
Поэтому, во всяком случае в моей изращенной голове все эти задачи неразделимы.
15 лет назад я был сторонником языков с неявным управлением памятью, динамических этих и тащился от них. Потом стал работать на телефонистов, у которых мульти-канальные системы, реальное время и борьба за быстродействие. Пришел к выводу, что все со сборкой мусора - отстой, лучше уж трахаться явной отменой памяти, чем смотреть, как мигает лампока HDD при работе очередного Java-приложения, которому не хватает памяти, чтобы нарисовать два окна на экране.
Теперь занимаюсь параллельной обработкой данных и придерживаюсь третей парадигмы - с моей точки зрения вообще все классические (основанные на одной куче или на кучах привязанных к тредам) подходы к управлению памяти отстойные, потому, что единственное правильное решение - не иметь никакой общей памяти и иметь много отдельных, не защищенных mutex-ами структур для аллокации, созданных содержательно, а не формально по принципу одна куча на тред и т.п. Sharing nothing лучше всего ляжет на архитектуры будущего, я думаю.
Если нужно предельное быстродействие - то нет отдельно аллокатора и отдельно стратегии сборки мусора. Это только в теории можно отделить их безболезненно. Для выделения памяти в классическом аллокаторе нам нужна структура, которая:
- Быстро находит свободное место нужного размера,
- Не ведет к сильной фрагментации памяти,
- По возможности избегает раздачи блоков из одной линии кэша разным тредам,
- Если это возможно, то не содержит одного глобального mutex-а на всю кучу.
Но стратегия сборки мусора принципиальным образом влияет на выбор алгоритма, например:
- Арена нулевого поколения может быть вообще стеком, если затем блоки будут перенесены в другую память,
- Если сборщик мусора перемещающий, то можно ослабить требование низкой фрагментации и применить более эффективные, но фрагментирующиеся структуры для разметки блоков и для поиска подходящего блока,
- Управление параллельностью при сборке мусора, при аллокации [и возможно при доступе] связаны друг с другом, что приведет или к использованию общей методики защиты от порчи структур из разных тредов, или наоборот – снимет требование не иметь одного глобального mutex-а, что существенно упростит аллокатор.
Вообще при написании аллокатора для мультитредной системы основная головная боль - как избавится от одного глобального лока. На втором месте неразрешимая в классической парадигме проблема разделения строк кэша.
Поэтому, во всяком случае в моей изращенной голове все эти задачи неразделимы.
15 лет назад я был сторонником языков с неявным управлением памятью, динамических этих и тащился от них. Потом стал работать на телефонистов, у которых мульти-канальные системы, реальное время и борьба за быстродействие. Пришел к выводу, что все со сборкой мусора - отстой, лучше уж трахаться явной отменой памяти, чем смотреть, как мигает лампока HDD при работе очередного Java-приложения, которому не хватает памяти, чтобы нарисовать два окна на экране.
Теперь занимаюсь параллельной обработкой данных и придерживаюсь третей парадигмы - с моей точки зрения вообще все классические (основанные на одной куче или на кучах привязанных к тредам) подходы к управлению памяти отстойные, потому, что единственное правильное решение - не иметь никакой общей памяти и иметь много отдельных, не защищенных mutex-ами структур для аллокации, созданных содержательно, а не формально по принципу одна куча на тред и т.п. Sharing nothing лучше всего ляжет на архитектуры будущего, я думаю.
В обычной системе (в Linux, Windows) мы не имеем контроля над моментом переключения контекстов. Происходит прерывание от таймера - и они переключают контекст, не интересуясь тем, что в этот момент делает машинный код юзерской программы. Поэтому если напрямую работать с памятью по указателю или убрать всякие флаги/барьеры, запись в которые ест время (и создает трафик на межпроцессорной/между-ядерной шине), то все вообще накроется медным тазом после переключения контекстов. Можно статическим анализом убрать сами аллокации/деаллокации, часть из них переведя в заказы на стеке - согласен. Но предположим, что у нас настоящая программа, работающая со структурами данных, а не просто вычислительные циклы вложенные. И динамический заказ памяти в ней делается содержательно и на стек его не перевести никак. В результате имеем кучу проблем - начиная от поглощения всей памяти за короткое время (с чем борются generational аллокаторами) и заканчивая самым сложным - вообще плохой увязкой таких языков с многопроцессорностью/многоядерностью. А железо покупать особенное - это для тех, кто уже имел неосторожность завязаться, скажем, на Java - и теперь не знает, как решить проблему масштабируемости. Но лучше сразу не привязываться к таким технологиям, проблемы которых можно снять только специальным железом.
Да, налабать код быстрее получается. Да, с иллюзией того, что всё работае и что среда обо всём позаботилась. А потом начинаются забытые ссылки в различных структурах данных. Как следствие, оставленные открытыми файль, сериализации по сети гигабайтных объёмов, улетающая в трубу память
ну так, а вы что думали, раз язык со сборкой мусора значит теперь не надо за памятью совсем следить? Если у программиста руки из одного места растут, то никакой GC не поможет
Динамический язык и сборки мусора не дают право кому попало писать программы, код должен писать профессианал, такие среды как java или .NET лишь автоматизирут процесс. Что касается производительности - недавно тестил портированный на .NET код Quake 3. Несмотря на использование байт кода FPS упала всего на 3% зато по отзывам команды было найдено и исправлено огромное кол-во ошибок, которые тяжело было бы отыскать в C++ версии (они так и остались в релизе), а скорость разработки в .NET кода идентичного качества примерно на 30-40% быстрее чем кода на классическом C++ при решении той же задачи. Я имею опыт длительной коммерческой работы с различными языками и компиляторами: C и C++, PASCAL, OBJECT PASCAL (DELPHI), Java, .NET (C Sharp)
Пришел к выводу что для большинства существующих задач в которых используется ПК экономически выгоднее использовать именно языки как Java или C Sharp, по поводу производительности - один из моих проектов - это специализированная поисковая система, полность написанная на платформе .NET. Первая реализация была на C++ - делалась пол года и утонула в поддержке, в результате было принято решение переписать. Сделали за 2 месяца рабочую версию. Еще за месяц написали свой удаленный отладчик который собирал все что было нужно для мониторинга системы (это было просто сделать т.к. в .NET очень удобно работать с метаданными). Сейчас архитектура позволяет без проблем расширять себя, подключая новые дедики-краулеры для повышения производительности. На C++, С и тем более асме нам банально не хватил бы денег запуститься, т.к. потребовалась бы команда минимум в 2-3 раза больше. И в результате мы бы в лучшем случае получили бы систему с работающую на 10% быстрее.
Пришел к выводу что для большинства существующих задач в которых используется ПК экономически выгоднее использовать именно языки как Java или C Sharp, по поводу производительности - один из моих проектов - это специализированная поисковая система, полность написанная на платформе .NET. Первая реализация была на C++ - делалась пол года и утонула в поддержке, в результате было принято решение переписать. Сделали за 2 месяца рабочую версию. Еще за месяц написали свой удаленный отладчик который собирал все что было нужно для мониторинга системы (это было просто сделать т.к. в .NET очень удобно работать с метаданными). Сейчас архитектура позволяет без проблем расширять себя, подключая новые дедики-краулеры для повышения производительности. На C++, С и тем более асме нам банально не хватил бы денег запуститься, т.к. потребовалась бы команда минимум в 2-3 раза больше. И в результате мы бы в лучшем случае получили бы систему с работающую на 10% быстрее.
1. :thinking: Так, вроде, порт Q3 для .net сделан на не managed C++ (конечно, если верить исходникам :), а MSIL - это просто промежуточное представление программы, которое в момент исполнения вполне себе компилируется в машинный код, если нужно. Для C/C++ это делается по умолчанию.
2. А вы уверены, что у вас всё просто получалось по той именно причине, что в C# используется сборщик мусора? :) А не по той причине, что в .net есть дофигища библиотек, которые упрощают разработку web-приложений?
Вам бы действительно не хватило бы времени написать это всё на Си или Си++, потому что вам многое пришлось бы писать самим. Но это не заслуга C#, как языка. Это заслуга MS, которая наклепала такие удобные для вас библиотеки.
Кроме того. Всё же на Си++ надо уметь программировать. Это ОЧЕНЬ сложный язык. Да и на Си тоже надо уметь программировать, потому что он предназначен для писания программ в unix-, а не в windows- стиле.
А С# с framework'ом на 200 мегабайт придуман, чтобы писать под Windows специально. Так чего же удивляться, что у вас с ним получилось проще? :)
Это не показатель качества самого языка.
2. А вы уверены, что у вас всё просто получалось по той именно причине, что в C# используется сборщик мусора? :) А не по той причине, что в .net есть дофигища библиотек, которые упрощают разработку web-приложений?
Вам бы действительно не хватило бы времени написать это всё на Си или Си++, потому что вам многое пришлось бы писать самим. Но это не заслуга C#, как языка. Это заслуга MS, которая наклепала такие удобные для вас библиотеки.
Кроме того. Всё же на Си++ надо уметь программировать. Это ОЧЕНЬ сложный язык. Да и на Си тоже надо уметь программировать, потому что он предназначен для писания программ в unix-, а не в windows- стиле.
А С# с framework'ом на 200 мегабайт придуман, чтобы писать под Windows специально. Так чего же удивляться, что у вас с ним получилось проще? :)
Это не показатель качества самого языка.
http://habrahabr.ru/blog/programming/419…
1. Компилятор как Managed C++ так и C Sharp как раз и генерирует этот MSIL. А при запуске приложения среда выполнения докомпилирует
его в асемблерный код команд процессора. Кстати последняя версия среды Java от SUN работает так же.
2. Уверен, т.к. синтаксис управляемых языков более краток и прост как в написании так и понимании.
Пример 1. Если нам нужно инкапсулировать сложную инициализацию в объект на C++ то кроме конструктора мы должны реализовать метод Create или Initialize потому что если в инициализации произошла ошибка - то делать throw в конструкторе в C++ недопустимо, как результат появляются статусы (Initialized, NotInitialized) которые нужно прописывать и при каждом использовании проверять.
Пример 2. Для сбора дампов за 1 день была написана утилита, которая используя метаданные складывает в xml объект со всеми полями и связанными объектами (сериализация всего дома объектов от рута).
Пример 3. В среде .NET как особенность архитектуры присутсвует такая вешь как Proxy (RealProxy, TransparentProxy) которая позволяет перехватывать любой вызываемы виртуальный метод без непосредственного вмешательства в класс. На основе этой идеологии написаны библиотеки Remoting, WFC и Web-службы. Т.к. нас они не устраивали - мы написали свой вариант высокоуровневого протокола общения серверов расширив функционал Remotin-а тем что нам было нужно. В результате для реализации серверного компонента требуется лишь унаследовать класс и интерфейс объявляющий интерфейс взаимодействия. До этого мы использовали DCOM, мало того что Microsoft навставлял в компилятор C++ кучу расширений чтобы это вообще работало.
Пример 4. Делегаты - как то нашел в инете (помоему через RSDN) реализацию идеологии делегатов (указатели на функции-члены классов)
она была сделана на таких хакак, что в коммерческом проекте я бы это использовать не стал.
Пример 5. Управление памятью значительно ускоряет процесс разработки, т.к. я не забочусь об указателях, мне не надо думать о том где создавать объект в стеке или в куче. Мне не надо думать о том где и как освобождать эту память и не требуется использовать различные Smart-указатели. Для написания кода я использую 2 главных правила:
для ресурсоемких объектов или исп. ресурсы Windows необходимо всегда реализовывать/использовать финализатор (Dispose());
не сохранять большие объемы данных в статические переменные.
Пример 6. Глубокое копирование объекта сводится к Serialize, Deserialize
Пример 7. Если я хочу гарантированно финализировать объект после использования - я использую такую конструкцию как
using(MyItem item = new MyItem())
{
...
}
вместо
MyItem item = new MyItem()
try
{
...
}
finally
{
if(item != null)
item.Dispose();
}
Кроме того 2-ой Framework весит всего 23,5 МБ - это никак не 200
Да и изначально как Java так и .NET были ориентированы на написание серверных приложений и распределенных систем. А не драйверов или прикладных программ что и объясняет объем пакета. Т.к. в инсталлятор сразу вшиты расширения для ASP.NET и пр.
Самы выжным для меня - работающего на платформе Windows является возможность изучения исходного кода платформы .NET при помощи инструмента Reflector. Т.к. мы прекрасно знаем что Microsoft и OpenSource несовместимые компоненты.
1. Компилятор как Managed C++ так и C Sharp как раз и генерирует этот MSIL. А при запуске приложения среда выполнения докомпилирует
его в асемблерный код команд процессора. Кстати последняя версия среды Java от SUN работает так же.
2. Уверен, т.к. синтаксис управляемых языков более краток и прост как в написании так и понимании.
Пример 1. Если нам нужно инкапсулировать сложную инициализацию в объект на C++ то кроме конструктора мы должны реализовать метод Create или Initialize потому что если в инициализации произошла ошибка - то делать throw в конструкторе в C++ недопустимо, как результат появляются статусы (Initialized, NotInitialized) которые нужно прописывать и при каждом использовании проверять.
Пример 2. Для сбора дампов за 1 день была написана утилита, которая используя метаданные складывает в xml объект со всеми полями и связанными объектами (сериализация всего дома объектов от рута).
Пример 3. В среде .NET как особенность архитектуры присутсвует такая вешь как Proxy (RealProxy, TransparentProxy) которая позволяет перехватывать любой вызываемы виртуальный метод без непосредственного вмешательства в класс. На основе этой идеологии написаны библиотеки Remoting, WFC и Web-службы. Т.к. нас они не устраивали - мы написали свой вариант высокоуровневого протокола общения серверов расширив функционал Remotin-а тем что нам было нужно. В результате для реализации серверного компонента требуется лишь унаследовать класс и интерфейс объявляющий интерфейс взаимодействия. До этого мы использовали DCOM, мало того что Microsoft навставлял в компилятор C++ кучу расширений чтобы это вообще работало.
Пример 4. Делегаты - как то нашел в инете (помоему через RSDN) реализацию идеологии делегатов (указатели на функции-члены классов)
она была сделана на таких хакак, что в коммерческом проекте я бы это использовать не стал.
Пример 5. Управление памятью значительно ускоряет процесс разработки, т.к. я не забочусь об указателях, мне не надо думать о том где создавать объект в стеке или в куче. Мне не надо думать о том где и как освобождать эту память и не требуется использовать различные Smart-указатели. Для написания кода я использую 2 главных правила:
для ресурсоемких объектов или исп. ресурсы Windows необходимо всегда реализовывать/использовать финализатор (Dispose());
не сохранять большие объемы данных в статические переменные.
Пример 6. Глубокое копирование объекта сводится к Serialize, Deserialize
Пример 7. Если я хочу гарантированно финализировать объект после использования - я использую такую конструкцию как
using(MyItem item = new MyItem())
{
...
}
вместо
MyItem item = new MyItem()
try
{
...
}
finally
{
if(item != null)
item.Dispose();
}
Кроме того 2-ой Framework весит всего 23,5 МБ - это никак не 200
Да и изначально как Java так и .NET были ориентированы на написание серверных приложений и распределенных систем. А не драйверов или прикладных программ что и объясняет объем пакета. Т.к. в инсталлятор сразу вшиты расширения для ASP.NET и пр.
Самы выжным для меня - работающего на платформе Windows является возможность изучения исходного кода платформы .NET при помощи инструмента Reflector. Т.к. мы прекрасно знаем что Microsoft и OpenSource несовместимые компоненты.
1. А я разве сказал нечто иное? :) Только про Java, насколько я знаю, это не совсем так. SUN всё пытается проводить runtime спецификацию кода и их jit-компилятор, это всё-таки jit-компилятор.
2.0. Скорее вы говорите об идомах, а не о синтаксисе. А то большинство функциональных языков синтаксис имеют на порядки более простой, чем современные императивные язык. А насчёт идиом - вот чёрт его знает. Да, вы можете писать такие конструкции наподобии:
И да, это всё идёт из динамических языков. Но, вот, например, в том языке, который мы разрабатываем у себя в институте, такое тоже можно писать. Но этот язык заточен под высокопроизводительные вычисления, и никаких сборщиков мусора ему для обработки подобоной вот констркции не понадобится. Более того, этот язык даже не объектно ориентированный в том смысле, в котором это понимается в Java, С# или C++ (вообще говоря, в этом языке getlines и sort будут без скобок - они не методы, а определяемые пользователем операторы). Всё дело лишь в аккуратной модели вычисления выражений, представлении значений и абстракциях для операторов. Вот.
2.1. ВоооОт. Со сложной инициализацией как раз нужен полный и тотальный контроль над откатом в случае ошибки. А сборщик мусора собирает объекты так, как его алгоритму угодно. Поэтому, у вас ко всему прочему возможны в программе неконтроллируемые deadlock'и (когда программа многопоточная), или ещё какая зараза похлеще. Что же касается исключений, да - не лучший метод обрабатывать ошибки. Но вполне приемлемый. Главное - правильно написать цепочку сложной инициализации, и в случае ошибки откатить её обратно. Это достигается классической 'if (ok) {ok = ...} if (ok) {...}' цепочкой. И проблем с этим никогда не было. И непонятно, как в условиях необходимости контроллировать последовательность инициализации и корректно её откатывать помогает автоматическая сборка мусора.
2.2. Ну и что? Я вот в субботу за полдня написал решение очередной олимпиадной задачки :) И что с того? У нас с вами просто есть уже накопленный инструментарий и подходы к решению различных задачек. Вы в теме, вот и решили быстро. Плюс удобные библиотеки для работы с XML. Так что это не показатель.
2.3. А вот это уже весомые штуки... Тут вряд ли можно возразить что-то кроме: всё-равно можно такие обёртки вручную клепать. Но вот если их можно в runtime генерировать автоматом, тогда да - это плюс системе программирования.
2.4. Там не хаки, а вполне себе шаблоны. А как часто вам приходится использовать делегатов в вашей повседневной жизни? Проще уж функциями обычными обходится, imho.
2.5. Так мне при программировании на том же Си тоже не надо об этом думать. Это же всё естественно: чего на стеке делать - то, что не уйдёт выше этой функции. В куче - то, что должно быть доступно на глобальном уровне, ну или динамический объект, который по своей сути такой. Правило очень простое. Тут, конечно, может быть некоторая издержка в связи с тем, что объекты не могут закончить свою жизнь в глубине дерева вызовов, если были созданы в стеке на его вершине. Ну, да, издержка. Зато, надёжно и гарантирует последовательность, а доверевшись сборщику мусора вам придётся использовать 'грязные' хаки, которые вы описываете в 2.7.
2.6. Но это просто интерфейсы для объектов. Опять же, в том языке, который я упомянул в 2.0. есть автоматические генераторы сериализаторов для объектов любой сложности. Сборка мусора тут ни при чём.
2.7. Чем это не хак?
Вот. Насчёт размеров... Может я чего-то путаю, но у меня вот некий файлик лежит dotnetfx35.exe размером в 206 мегабайтов. Вроде как это framework для .net 3.5. Про 2.0 не знаю. Не лежит :).
2.0. Скорее вы говорите об идомах, а не о синтаксисе. А то большинство функциональных языков синтаксис имеют на порядки более простой, чем современные императивные язык. А насчёт идиом - вот чёрт его знает. Да, вы можете писать такие конструкции наподобии:
file("some.txt").getlines().sort().map(function ('string a) {print(a.split(':')[1])}) И да, это всё идёт из динамических языков. Но, вот, например, в том языке, который мы разрабатываем у себя в институте, такое тоже можно писать. Но этот язык заточен под высокопроизводительные вычисления, и никаких сборщиков мусора ему для обработки подобоной вот констркции не понадобится. Более того, этот язык даже не объектно ориентированный в том смысле, в котором это понимается в Java, С# или C++ (вообще говоря, в этом языке getlines и sort будут без скобок - они не методы, а определяемые пользователем операторы). Всё дело лишь в аккуратной модели вычисления выражений, представлении значений и абстракциях для операторов. Вот.
2.1. ВоооОт. Со сложной инициализацией как раз нужен полный и тотальный контроль над откатом в случае ошибки. А сборщик мусора собирает объекты так, как его алгоритму угодно. Поэтому, у вас ко всему прочему возможны в программе неконтроллируемые deadlock'и (когда программа многопоточная), или ещё какая зараза похлеще. Что же касается исключений, да - не лучший метод обрабатывать ошибки. Но вполне приемлемый. Главное - правильно написать цепочку сложной инициализации, и в случае ошибки откатить её обратно. Это достигается классической 'if (ok) {ok = ...} if (ok) {...}' цепочкой. И проблем с этим никогда не было. И непонятно, как в условиях необходимости контроллировать последовательность инициализации и корректно её откатывать помогает автоматическая сборка мусора.
2.2. Ну и что? Я вот в субботу за полдня написал решение очередной олимпиадной задачки :) И что с того? У нас с вами просто есть уже накопленный инструментарий и подходы к решению различных задачек. Вы в теме, вот и решили быстро. Плюс удобные библиотеки для работы с XML. Так что это не показатель.
2.3. А вот это уже весомые штуки... Тут вряд ли можно возразить что-то кроме: всё-равно можно такие обёртки вручную клепать. Но вот если их можно в runtime генерировать автоматом, тогда да - это плюс системе программирования.
2.4. Там не хаки, а вполне себе шаблоны. А как часто вам приходится использовать делегатов в вашей повседневной жизни? Проще уж функциями обычными обходится, imho.
2.5. Так мне при программировании на том же Си тоже не надо об этом думать. Это же всё естественно: чего на стеке делать - то, что не уйдёт выше этой функции. В куче - то, что должно быть доступно на глобальном уровне, ну или динамический объект, который по своей сути такой. Правило очень простое. Тут, конечно, может быть некоторая издержка в связи с тем, что объекты не могут закончить свою жизнь в глубине дерева вызовов, если были созданы в стеке на его вершине. Ну, да, издержка. Зато, надёжно и гарантирует последовательность, а доверевшись сборщику мусора вам придётся использовать 'грязные' хаки, которые вы описываете в 2.7.
2.6. Но это просто интерфейсы для объектов. Опять же, в том языке, который я упомянул в 2.0. есть автоматические генераторы сериализаторов для объектов любой сложности. Сборка мусора тут ни при чём.
2.7. Чем это не хак?
Вот. Насчёт размеров... Может я чего-то путаю, но у меня вот некий файлик лежит dotnetfx35.exe размером в 206 мегабайтов. Вроде как это framework для .net 3.5. Про 2.0 не знаю. Не лежит :).
Тьфу блин. Сколько очепяток. Всё, пора спать. Всем приятных снов :)
мое мнение о js менялось много раз. И очень сильно на него повлияли Douglas Crockford и фрэймворки (prototype, ext-js,jquery,dojo).
Хочу поделиться ссылкой на презентацию Douglas Crockford, где он делает введение в javaScript - если ваша работа связана с этим языком - не поленитесь - послушайте
http://video.yahoo.com/watch/111593
Хочу поделиться ссылкой на презентацию Douglas Crockford, где он делает введение в javaScript - если ваша работа связана с этим языком - не поленитесь - послушайте
http://video.yahoo.com/watch/111593
JavaScript совершенно потрясная вещь.На примере ExtJS это видно особенно хорошо. Очень хочу быстрый JS :)
>>Программисты любят заниматься микро-оптимизациями, потому что это требует меньше умственных усилий, чем проработка архитектуры.
всегда ненавидел непродуманную архитектуру и "оптимизацию" на ней
всегда ненавидел непродуманную архитектуру и "оптимизацию" на ней
на Erlang работает все оборудование Ericsson
А на Си написано много чего ещё, и что? ;)
это я наверное к этому >>> Инерция слишком велика: в маркетинг вложены большие средства. Никакой энтузиаст не сможет протолкнуть использование LISP или Haskell, или Erlang в корпорации. Миллионы программистов по всему миру не намерены изучать второй язык. Как следствие, в обозримом будущем нам остаётся довольствоваться тем, что есть. Это очень печально, но с этим придётся смириться.
Очень удобны для прототипирования и вообще для задач, где можно пожертвовать скоростью.
Если смотреть на The Next Big Language трезво, то он должен удволетворять следующим требованиям(на примере Scala):
1) Скорость на уровне большой тройки(Java/.NET/C++):
Scala соизмерима по скорости с Java. Это такой же статически типизированный язык, для которых и были сделаны JVM & CLR.
2) Совместимость с другими технологиями, библиотеками:
Scala создавалась тем же человеком, что писал javac, поэтому совместимость с Java на высшем уровне. Работает со всеми Java-библиотеками. Есть так же версия языка и для .NET.
3) Компактность:
Scala не такой verbose язык как Java, код на ней зачастую в 2 раза короче за счёт синтаксиса. К примеру клон твиттера писали на ней в 500 строк. Есть фреймворк liftweb, взявший много из rails, django, wicket...
4) Масштабируемость:
Erlang-style. Scala - ещё и функциональный язык с поддержкой actors model.
5) DSL:
Любители Ruby & RSpec могут оценить http://code.google.com/p/specs/wiki/QuickStart BDD фреймворк.
6) Признание:
Scala не стеснялись называть "The next Java" на прошедшем JavaOne, в том числе и сам Джеймс Гослинг(создатель Java). Нил Гафтер, Java-евангелист в Google писал в своём блоге, что они(если что) могут перейти на Scala. В объявлениях на работу в Yandex тоже встречается Scala, где её использование согласованно с руководством.
Интересно было бы видеть для других языков ответы этим требованиям. Ну или какие-то ещё требования для TNBL.
1) Скорость на уровне большой тройки(Java/.NET/C++):
Scala соизмерима по скорости с Java. Это такой же статически типизированный язык, для которых и были сделаны JVM & CLR.
2) Совместимость с другими технологиями, библиотеками:
Scala создавалась тем же человеком, что писал javac, поэтому совместимость с Java на высшем уровне. Работает со всеми Java-библиотеками. Есть так же версия языка и для .NET.
3) Компактность:
Scala не такой verbose язык как Java, код на ней зачастую в 2 раза короче за счёт синтаксиса. К примеру клон твиттера писали на ней в 500 строк. Есть фреймворк liftweb, взявший много из rails, django, wicket...
4) Масштабируемость:
Erlang-style. Scala - ещё и функциональный язык с поддержкой actors model.
5) DSL:
Любители Ruby & RSpec могут оценить http://code.google.com/p/specs/wiki/QuickStart BDD фреймворк.
6) Признание:
Scala не стеснялись называть "The next Java" на прошедшем JavaOne, в том числе и сам Джеймс Гослинг(создатель Java). Нил Гафтер, Java-евангелист в Google писал в своём блоге, что они(если что) могут перейти на Scala. В объявлениях на работу в Yandex тоже встречается Scala, где её использование согласованно с руководством.
Интересно было бы видеть для других языков ответы этим требованиям. Ну или какие-то ещё требования для TNBL.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стив Егге: динамические языки возвращаются