Простите, а вы сколько программ на этих фреймворках написали, чтобы это говорить? )
«Эти фреймворки», как вы выразились, работают в 2-3 раза быстрее STL даже на базовых операциях типа работы с динамическими массивами или строками.
Компиляция SQL идёт на стадии компиляции программы. То есть, с точки зрения динамических языков, во время выполнения происходят мгновенно.
Что значит костыли? Кусок, отодранный из Cω, и добавленный спустя пять лет после разработки основного языка, это не костыли?
Мы ведь говорим об эффективности, о памяти, об удобстве. Тот пример запроса, что вы привели выше, давно уже компилируется и в С++, я вам привёл пруфлинк. Всё работает стабильно, быстро. И пользоваться удобно.
Что касается SQL-функций, то имеется в виду PL/pgSQL и что-то подобное? Если да, то это довольно большая специфическая тема, далёкая от обсуждаемого «большинства прикладных задач».
1. Защита памяти.
И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++? А плохо написанные приложения на Яве — не падают?
Я пробовал разные приложения что на чистой Яве, что на Андроиде — и знаете что — они падают. И падают довольно часто. Может, конечно, у меня с Явой что-то не то, не знаю.
2. По поводу плюсов и минусов Явы перед С++, в той самой Википедии, на которую вы ссылаетесь, написано следующее.
а) Независимость байт-кода от операционки (мы все знаем, что на деле распространяется несколько бинарников для нескольких процессоров, что покрывает 99% пользователей).
б) Система безопасности. О ней я писал выше — там всё очень и очень спорно, как минимум.
И что же мы получаем за эти неочевидные преимущества:
— замедление работы кода в несколько раз
— потребление памяти в 10-30 раз больше
Заметьте, это не я придумал, это написано в Википедии, на которую вы сами же и ссылаетесь.
Как я говорил выше, подобный уровень удобства давно уже дают фреймворки в С++. И давно уже есть компиляция (compile-time!) на необходимый диалект SQL. Например, вот так.
Очень интересно будет посмотреть на производительность этой системы. )
А особенно интересно будет, если, как вы предлагаете, всё делать в одной задаче: если вдруг что с виртуальной машиной, то падает вообще весь user space. Напоминает старые времена DOS.
Этакий anti-unix way.
Если сравнивать Яву с С++ и фремворками образца начала 2000-х, то скорость разработки безусловно выше. С тех пор многое поменялось. Вот не самый свежий пример: www.ultimatepp.org/www$uppweb$vsswing$en-us.html
Отлично! Забыли про динамическую память, теперь говорим про ФП.
Скажите пожалуйста, чем отсутствие ФП в С++ мешает, как вы там выразились, для большинства прикладных задач?
Понимаете, всё это не объясняет, почему вместо хорошего фреймворка С++, потребовалось городить отдельный язык с фреймворком.
Маркетинговые заголовки типа «решает проблемы с динамической памятью» — потускнели и покрылись трещинами. Из самописных андроидовских программ на яве, дай бог если половина не падает.
В С++ при правильном подходе у разработчика также будет изъята возможность устраивать проблемы с памятью (я писал об этом статью в своё время).
Я также утверждаю, что эти проблемы решить куда проще, чем проблемы многопоточности, проблемы неверной логики работы алгоритмов, проблемы покрытия различных ситуаций (включая нештатные). Ява здесь не решает вообще ничего по сравнению с С++.
Профайлер вам не покажет, что вообще ВСЁ в Яве делается медленнее, чем в С++. Начиная от обращения к переменной, и заканчивая работой с динамической памятью. Вы лишь увидите наиболее относительно медленные участки. Вот только относительно чего? Вы же не уберёте мусоросборщик, не поменяете внутреннюю логику работы с переменными (там где С++ работает со стеком процессора, меняя всего один его регистр).
И здесь я даже не говорю про память. А на этом стоило бы остановиться подробнее.
Но — зачем? Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++. Нужно ли мне тратить время на разубеждение? Не вижу смысла.
Всё равно производительность будет другой.
Во-первых, на лету скомпилировать также качественно не удастся. Оптимизирующий компилятор того же С++ (в режиме полной оптимизации) требует совсем других времён и совсем другой памяти — ничего этого в маленьком устройстве может не быть, не говоря уже о том, что это сотни мегабайт данных, которые динамически генерятся и «перевариваются» процессором.
Всё, на что можно рассчитывать в JIT — это баланс между скоростью и памятью при компиляции против её качества. Как правило, не в пользу качества.
Но это ещё не всё! Как ты ни компилируй, у тебя останутся свистелки вроде фонового мусоросборщика, дополнительных накладных расходов памяти при аллокации, и самое главное — проблемы скорости динамических переменных. Работа с переменной в С++ не сравнится с той же задачей в Яваскрипт. Там, где С++ обходится простым вызовом процессорной инструкции, Яваскрипт осуществит массу проверок, выполнит массу кода, прежде чем перейдёт к непосредственной работе. И эта проблема ПРИНЦИПИАЛЬНО не решается оптимизирующей компиляцией, это логика работы динамических языков.
Якобы, это спасает от проблем времени выполнения. На практике, даже этот довод оказывается очень спорным: от действительно серьёзных проблем в логике программы, динамическое программирование всё равно не спасает — программа, даже если не упадёт, то окажется неработоспособной. По сути, на практике выясняется, что нужна та же самая работа по отладке, что и в неконтролируемой среде.
Да, динамическое программирование позволяет делать некоторые «финты», которые в ряде случаев уменьшают затраты на разработку. Но извините, пользователю пофигу на это всё: ему важно, чтобы программа на его не самом мощном устройстве хорошо и быстро работала. А по этой характеристике, динамические языки позади статических. Особенно, на слабых процессорах с минимумом оперативной памяти.
Всё зависит от задачи.
Пользователю (а автолюбитель — это максимум уровень продвинутого пользователя) действительно не так важно знать, как оно работает. Уметь хотя бы минимально настраивать — уже хорошо (ну там фильтр воздушный зима-лето, жидкостей подливать когда надо, проверять стёртость колодок и т.п.).
Программисту (то есть автоконструктору) знать эти вещи обязательно. И, уверяю вас, он их знает без всяких Википедий.
Это правда. Но я могу хотя бы примерно примерно оценить сверху скорость выполнения отдельных участков кода БЕЗ профайлера, потому что примерно знаю какой код С++ как реализован. Я точно знаю где происходит аллокация и деаллокация. Я точно знаю это и могу рассматривать детерминированные сценарии использования памяти. Я не боюсь, что в какой-то момент запустится мусоросборщик и всё зависнет.
Наконец, все вот эти вот фразы, что «у нас всё работает не медленнее чем на С или С++» — это как правило значит, что люди серьёзные приложения не сравнивали. Ну быстрее работает неинтерпретированный код. Быстрее. И не только потому, что оптимизирующий С++ компилятор имеет больше времени на оптимизации, чем JIT. Сама структура языка предполагает более детерминистский подход к программированию. Это сложнее, да. Но если этим правильно пользоваться, то будет реально быстрее.
Мне ОЧЕНЬ не хватает нормальной поддержки С++ на Андроиде. Мне будет точно также не хватать её в этой ОС. Я ещё понимаю, если бы скорость девайсов была такая, что интерпретированность не чувствовалась. Так ведь нет же: берут слабую железку, заставляют писать на высокоуровневых и менее эффективных (с точки зрения исполнения) языках. При этом ещё обрубают высокоэффективные средства разработки на С++.
Ну и наконец, вся эта хвалёная стабильность систем на Яве. Всё это на практике виснет, глючит и падает ничуть не меньше, чем нативный код. Программы с утилитами точно также глючат, при этом ещё съедают гораздо больше памяти.
Тогда спрашивается — НАФИГА было затеваться с Явой?
Ну сделайте вы систему открытой. Допилите под неё gcc и прочее. Остальные постепенно подтянутся.
Пусть кто на чём может, тот на том и будет писать. Кто не может или не хочет С++, пусть пишет на Яве, Яваскрипте, да хоть брэйнфаке.
Что это за дурацкие проприетарные ограничения, которые выдаются гигантами за охрененно продвинутый современный подход, которые к тому же плохо себя показывают на практике?
Просто для разработки утилиты использован «бульдозер» с реактивными двигателями, ракетницами и защитными полями.
На С++ вполне можно сделать бинарник размером порядка 1 МиБ при полном отсутствии несистемных зависимостей. А если вообще не пользовать фреймворки, то это будет вообще что-то около 200 КиБ, не больше.
Да не, зря критикуют. Идея хорошая. Давно нужно было сделать что-то подобное поверх ВК.
Я не уверен что это переформатирует весь рынок, но имеет право на жизнь — совершенно точно.
«Эти фреймворки», как вы выразились, работают в 2-3 раза быстрее STL даже на базовых операциях типа работы с динамическими массивами или строками.
Компиляция SQL идёт на стадии компиляции программы. То есть, с точки зрения динамических языков, во время выполнения происходят мгновенно.
Мы ведь говорим об эффективности, о памяти, об удобстве. Тот пример запроса, что вы привели выше, давно уже компилируется и в С++, я вам привёл пруфлинк. Всё работает стабильно, быстро. И пользоваться удобно.
Что касается SQL-функций, то имеется в виду PL/pgSQL и что-то подобное? Если да, то это довольно большая специфическая тема, далёкая от обсуждаемого «большинства прикладных задач».
И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++? А плохо написанные приложения на Яве — не падают?
Я пробовал разные приложения что на чистой Яве, что на Андроиде — и знаете что — они падают. И падают довольно часто. Может, конечно, у меня с Явой что-то не то, не знаю.
2. По поводу плюсов и минусов Явы перед С++, в той самой Википедии, на которую вы ссылаетесь, написано следующее.
а) Независимость байт-кода от операционки (мы все знаем, что на деле распространяется несколько бинарников для нескольких процессоров, что покрывает 99% пользователей).
б) Система безопасности. О ней я писал выше — там всё очень и очень спорно, как минимум.
И что же мы получаем за эти неочевидные преимущества:
— замедление работы кода в несколько раз
— потребление памяти в 10-30 раз больше
Заметьте, это не я придумал, это написано в Википедии, на которую вы сами же и ссылаетесь.
А особенно интересно будет, если, как вы предлагаете, всё делать в одной задаче: если вдруг что с виртуальной машиной, то падает вообще весь user space. Напоминает старые времена DOS.
Этакий anti-unix way.
www.ultimatepp.org/www$uppweb$vsswing$en-us.html
Скажите пожалуйста, чем отсутствие ФП в С++ мешает, как вы там выразились, для большинства прикладных задач?
Маркетинговые заголовки типа «решает проблемы с динамической памятью» — потускнели и покрылись трещинами. Из самописных андроидовских программ на яве, дай бог если половина не падает.
Я также утверждаю, что эти проблемы решить куда проще, чем проблемы многопоточности, проблемы неверной логики работы алгоритмов, проблемы покрытия различных ситуаций (включая нештатные). Ява здесь не решает вообще ничего по сравнению с С++.
И здесь я даже не говорю про память. А на этом стоило бы остановиться подробнее.
Но — зачем? Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++. Нужно ли мне тратить время на разубеждение? Не вижу смысла.
В данном случае, возможно, скорее зеалот.
Во-первых, на лету скомпилировать также качественно не удастся. Оптимизирующий компилятор того же С++ (в режиме полной оптимизации) требует совсем других времён и совсем другой памяти — ничего этого в маленьком устройстве может не быть, не говоря уже о том, что это сотни мегабайт данных, которые динамически генерятся и «перевариваются» процессором.
Всё, на что можно рассчитывать в JIT — это баланс между скоростью и памятью при компиляции против её качества. Как правило, не в пользу качества.
Но это ещё не всё! Как ты ни компилируй, у тебя останутся свистелки вроде фонового мусоросборщика, дополнительных накладных расходов памяти при аллокации, и самое главное — проблемы скорости динамических переменных. Работа с переменной в С++ не сравнится с той же задачей в Яваскрипт. Там, где С++ обходится простым вызовом процессорной инструкции, Яваскрипт осуществит массу проверок, выполнит массу кода, прежде чем перейдёт к непосредственной работе. И эта проблема ПРИНЦИПИАЛЬНО не решается оптимизирующей компиляцией, это логика работы динамических языков.
Якобы, это спасает от проблем времени выполнения. На практике, даже этот довод оказывается очень спорным: от действительно серьёзных проблем в логике программы, динамическое программирование всё равно не спасает — программа, даже если не упадёт, то окажется неработоспособной. По сути, на практике выясняется, что нужна та же самая работа по отладке, что и в неконтролируемой среде.
Да, динамическое программирование позволяет делать некоторые «финты», которые в ряде случаев уменьшают затраты на разработку. Но извините, пользователю пофигу на это всё: ему важно, чтобы программа на его не самом мощном устройстве хорошо и быстро работала. А по этой характеристике, динамические языки позади статических. Особенно, на слабых процессорах с минимумом оперативной памяти.
Пользователю (а автолюбитель — это максимум уровень продвинутого пользователя) действительно не так важно знать, как оно работает. Уметь хотя бы минимально настраивать — уже хорошо (ну там фильтр воздушный зима-лето, жидкостей подливать когда надо, проверять стёртость колодок и т.п.).
Программисту (то есть автоконструктору) знать эти вещи обязательно. И, уверяю вас, он их знает без всяких Википедий.
Наконец, все вот эти вот фразы, что «у нас всё работает не медленнее чем на С или С++» — это как правило значит, что люди серьёзные приложения не сравнивали. Ну быстрее работает неинтерпретированный код. Быстрее. И не только потому, что оптимизирующий С++ компилятор имеет больше времени на оптимизации, чем JIT. Сама структура языка предполагает более детерминистский подход к программированию. Это сложнее, да. Но если этим правильно пользоваться, то будет реально быстрее.
Мне ОЧЕНЬ не хватает нормальной поддержки С++ на Андроиде. Мне будет точно также не хватать её в этой ОС. Я ещё понимаю, если бы скорость девайсов была такая, что интерпретированность не чувствовалась. Так ведь нет же: берут слабую железку, заставляют писать на высокоуровневых и менее эффективных (с точки зрения исполнения) языках. При этом ещё обрубают высокоэффективные средства разработки на С++.
Ну и наконец, вся эта хвалёная стабильность систем на Яве. Всё это на практике виснет, глючит и падает ничуть не меньше, чем нативный код. Программы с утилитами точно также глючат, при этом ещё съедают гораздо больше памяти.
Тогда спрашивается — НАФИГА было затеваться с Явой?
Ну сделайте вы систему открытой. Допилите под неё gcc и прочее. Остальные постепенно подтянутся.
Пусть кто на чём может, тот на том и будет писать. Кто не может или не хочет С++, пусть пишет на Яве, Яваскрипте, да хоть брэйнфаке.
Что это за дурацкие проприетарные ограничения, которые выдаются гигантами за охрененно продвинутый современный подход, которые к тому же плохо себя показывают на практике?
На С++ вполне можно сделать бинарник размером порядка 1 МиБ при полном отсутствии несистемных зависимостей. А если вообще не пользовать фреймворки, то это будет вообще что-то около 200 КиБ, не больше.
Я не уверен что это переформатирует весь рынок, но имеет право на жизнь — совершенно точно.