Comments 152
Плюс, с падением курса рубля, программистам на этих языках стало сильно выгоднее работать за границей (или удаленно), что тоже сказывается на рынке разработки. А вот PHP чаще использовался для своих разработок, чем для зарубежных, поэтому он и растет в РФ.
(правда Java ещё и язык смартфонов)
А на C# мобильную разработку вывезли что ли?
Windows Phone (или Windows Mobile, вроде опять переименовали) и Xamarin даже в сумме не дают сколь бы то ни было большого процента присутствия C# на рынке мобильной разработки.
Эх… и в карму кто-то минус зарядил…
Так-то мобильная разработка много на чем есть (Python, JS, C++, даже с Ruby что-то было, не считая Kotlin и прочих JVM-языков, на которых пишут под Android в той или иной степени). И вообще в этом мире бывают аномалии — от сайтов на C++ до десктопных приложений на PHP. Но в расчет их никто не берет.
Карму подровнял, но лучше о ней все же не вспоминать в комментариях :)
Хотя разброс в ценах большой.
У нас люди от 150 работают.
Компания за счет кризиса поднимается, т.к. многие участники международного booking-broker рынка отвалились и на их место частично свободно.
Из-за кризиса освобождает много места, где раньше были конкуренты.
Простите, а что, CSS – уже язык программирования?
«язык описания» != «язык программирования»
XML, JSON или HTML
Вряд ли есть вакансии чисто по «языку» XML или JSON. Они упоминаются только как доп.навыки. А вот CSS/HTML или SQL вполне могут быть единственным «языком» в вакансии (верстальщик, админ баз данных и т.п.)
И SQL это язык запросов, а не программирования, уж если на то пошло.
Это вопрос терминологии. SQL — тьюринг полный, а значит он не менее ЯП, чем, скажем, Brainfuck. В вики SQL указывается как функциональный узкоспецилизированный ЯП, в принципе языки запросов и языки программирование это не исключающие друг друга множества. А всякие расширения, типа PL-SQL или Transact-SQL тем более могут считаться ЯП.
Возможно, стоит чуть шире глянуть своей статистики по вакансиям, не ограничиваясь топ-15 по гитхабу?
Это язык запросов к БД. Тоже не язык программирования. И Oracle там… Это ж фирма. В общем, как-то нет доверия к этому списку языков...
Вы слишком педантичны.
Для любого неспециалиста "язык программирования = формальный язык". Uml, rapide, vrml и verilog" вполне идут в ту же категорию.
https://en.wikipedia.org/wiki/Style_sheet_language — «A style sheet language, or style language, is a computer language that expresses the presentation of structured documents. ».
И ещё статистику отдельный язык/технология/стэк
А где же 1С, спросите вы?
Нет, не спросим...
Мой преподаватель в вузе вообще говорил что PHP язык для собак!) Но я разработчик именно на PHP (ну не только) и сейчас работаю у него в компании на должности PHP разработчика)
Точно так же как если бы взять разработчика на "современном PHP" и попытаться рассказать что такое "современная серверная разработка на javascript". Когда говоришь что там уже есть async/await обычно кислая мина сменяется заинтересованностью.
Можете пояснить зачем разработчику на современном PHP конструкции типа async/await? PHP сам по себе работает основываясь на совершенно другой парадигме.
Как сказал предыдущий комментатор, действительно очень много людей понятия не имеют не то что про современный PHP, но и про предметную область PHP в целом.
Чтобы было понятно, PHP — это DSL, который идеально подходит для своей ниши, но возможностей при этом дает даже больше чем нужно (расскажите, есть ли в "современном JavaScript", например, ORM уровня Doctrine2?)
Можете пояснить зачем разработчику на современном PHP конструкции типа async/await?
Что бы не городить ворох колбэков и промисов. Да, есть корутины, можно строить на них (пример — amphp) но это все же не так вкусно. В php internals дискуссия о том что надо вводить async/await не так давно была и к версии 8 надеюсь реализуют.
Если вы говорите что "ниша php только в сайтиках" то я с вами не соглашусь. А если "ниша php только в web" то сегодня есть огромный пласт задач, для которых старая модель выполнения по принципу "повар приготовил повар умер" крайне не эффективна.
Да, есть проекты вроде FastCGIDaemon или php-pm которые частично решают проблему бутстраппинга приложений (когда можно время респонса symfony + doctrine уменьшить с 20ms до 10ms). Но когда речь идет об асинхронной работе (очереди, pub/sub, много работы с I/O) то тут уже совсем грустно порой становится. У меня к примеру есть один компонент в системе который вынужден на каждый запрос стучаться по сети в отдельную хрень. И пока он стучится сервер ждет а не пробует обработать другой запрос.
В целом же если брать конкретно саму конструкцию, async/await резко понижает порог вхождения в разработку систем использующих event loop. То есть по сути средний php разработчик сможет писать все те же макароны в том же стиле но выполняться это все будет куда эффективнее.
Чтобы было понятно, PHP — это DSL, который идеально подходит для своей ниши
Чтобы было понятно, это не DSL ни разу. Это General-Purpose Language. GPL с ограниченной областью применения не делает этот GPL DSL-ем.
но возможностей при этом дает даже больше чем нужно
а что нужно? для сайтиков нода неплохо справляется. Да и сегодня намного проще бывает заставить на сервере рендрить какой-нибудь react app вместо того чтобы городить php+twig. Это банально эффективнее с экономической точки зрения (вопросы менеджмента и распараллеливания). Если же сфера php low-end сегмент рынка web разработки (вордпресс если проще) — то может быть. И то неизвестно сколько еще это продлится.
ORM уровня Doctrine2?)
TypeORM для TypeScript (мы же хотим быть type safe на бэкэнде, чего php нам к слову не дает). Оно конечно еще сырое и к продакшену не годится, но это весьма активно развивающийся проект. Зато в JS есть WeakMap который намного удобнее для построения того же identity map. Да, weak map есть и для php но доктрина его не умеет по понятным причинам.
Да и опять же, не ORM свет един:
- хотите table gateway/dao — все есть (мне лично нравится knex но есть и другие варианты)
- хотите active record — все есть
- хотите оперировать агрегатами сущностей как в доктрине но не хотите реляционных ограничений — mongodb
- написать гидраторы для сущностей, identity map и unit of work (не универсальный под все а специализированный) — не сильно сложная задача. Заворачиваем все это в репозиторий и готова наша личная ORM без магии. Хотим магии — заворачиваем все в Proxy. Но лучше дождаться TypeORM.
Смею утверждать как разработчик, имеющий 90% времени дело с Symfony + Doctrine2 что для проектов где этот стэк хорошо подходит, жать начинает уже PHP. Если в PHP добавят generics то может быть я стану меньше ныть.
Что бы не городить ворох колбэков и промисов. Да, есть корутины, можно строить на них (пример — amphp) но это все же не так вкусно. В php internals дискуссия о том что надо вводить async/await не так давно была и к версии 8 надеюсь реализуют.
Вы неправильно поняли. Вопрос мой был в том, зачем в PHP вообще использовать асинхронную модель, когда сам PHP по своей сути реализует другую парадигму?
Я-то прекрасно понимаю зачем это нужно, и более того могу напомнить что к примеру во фреймворке Twisted (Python), паттерн reactor (наряду с Deferred) был реализован еще тогда, когда того же jQuery даже в проекте не было, уж не говоря о NodeJS (14 лет назад).
И все кому надо было этим пользовались (синтаксиса async/await еще тогда не было, но была возможность использовать синтаксис генераторов — yield).
Чтобы было понятно, это не DSL ни разу. Это General-Purpose Language. GPL с ограниченной областью применения не делает этот GPL DSL-ем.
Именно понимание и осознание того факта что PHP исторически начинался как DSL, или того проще — как набор CGI скриптов, снимает весь баттхерт у людей, которые считают PHP полноценным языком программирования а потом негодуют когда пытаются на нем писать демонов, или многопоточные приложения.
Конечно формально это язык общего назначения, но по факту это самый настоящий DSL.
И он идеально подходит для своего набора задач, в которые как раз-таки асинхронность/многопоточность и прочее не входят.
Тот факт, что язык развивается под давлением сообщества и в него добавляются эти фичи, говорит лишь о том, что люди ленивы — они не хотят учить новые языки, а также не хотят использовать зоопарк технологий (что в принципе не лишено здравого смысла).
Но здесь нужно понимать, что задачи все-таки бывают разными, и молотком бревна не распилишь: осознание этого факта почему-то не ввергает плотников в ужас =)
а что нужно? для сайтиков нода неплохо справляется. Да и сегодня намного проще бывает заставить на сервере рендрить какой-нибудь react app вместо того чтобы городить php+twig. Это банально эффективнее с экономической точки зрения
Однако PHP судя по графику все еще не только не умер, но и живее всех живых
TypeORM для TypeScript (мы же хотим быть type safe на бэкэнде, чего php нам к слову не дает).
Когда будет production-ready и будет поддерживать, к примеру, Table Inheritance, тогда можно будет о чем-то разговаривать (напомню что сегодня почти 2017 год на дворе).
К тому-же это не JavaScript, а TypeScript.
Но большинство проектов писать надо уже сейчас, а не тогда когда настанет светлое будущее.
Я рассматривал типичные запросы на чтение, вроде "получить список категорий" или "список продуктов в каталоге". Тут самое "жрущее" это инициализация контейнера и гидрация данных (из 20ms ~8 будет занимать та самая гидрация). Причем в зависимости от сложности время на гидрацию будет меняться. Иногда даже проще сделать 2 sql запроса без джойна что бы уменьшить время гидрации.
Причем немало времени уходит на добавление сущностей в UoW… чего можно избежать. Или еще круче — можно заюзать ArrayHydrator и получить оверхэд всего в пару милисекунд.
У меня есть один кусочек проекта где мне нужно было разогнать все по максимуму и там получение списочков занимает в среднем 12ms.
Конечно же это с скомпилированным контейнером, настроенным opcache (не дефолтные настройки), кэшированием метаданных доктрины в apcu и т.д. Пару процентов подарило недавнее обновление composer.
Какое-нибудь добавление того же продукта будет занимать времени уже побольше (тут ресурсы начинает жрать UoW). Хотя это всеравно не так страшно, если вы страшного ничего не делаете.
Симфони в продакшен окружении весьма шустрая штука, да, некоторые вещи там откровенно медленны. И да, есть вещи которые, если о них не знать, резко сказываются на производительности. Но ничего сверхъестественного в этом нет с учетом что приложение на nodejs будет отдавать примерно те же json-ки за пару милисекунд.
А какой уровень этой ORM? С Hibernate сравнится? А по каким параметрам сравнивать?..
Вот интересный вы человек… как оценивать-то?
PS пренебрежительное отношение к PHP и девелоперам на нём связано с несколькими факторами:
- очень низкий порог входа… порождает дичайшее количество говнокодеров и велосипедистов
- исторически сложившееся отношение на пике популярности языка (я с ним не работал уже больше 5 лет, на тот момент он имел отвратительную архитектуру и страшное количество грабель, на которые легко наступить)
- сессионность (я не знаю, как можно работать с языком, который не имеет состояния… нет на уровне простеньких скриптов — всё понятно… но загружаться сложный движок?!..)
- по вкусу — каждый знает лично ему неприятные элементы языка
А какой уровень этой ORM? С Hibernate сравнится? А по каким параметрам сравнивать?..
Вот интересный вы человек… как оценивать-то?
Вообще-то Doctrine во многом вдохновлялась именно Hibernate. Вы не знали этого?
А по каким параметрам сравнивать?
По реализованным паттернам и поддерживаемым фичам. Непонятно даже откуда такой вопрос взялся.
PS пренебрежительное отношение к PHP и девелоперам на нём связано с несколькими факторами
Пренебрежительное отношение к PHP в большинстве случаев возникает именно из-за вопиющего непонимания области его применения, а также из-за комплекса превосходства некоторых разработчиков из других областей.
И да, на PHP не пишут серьезный банковский софт, т.к. PHP для этого не создавался и в этой нише есть свои лидирующие технологии.
Вообще-то Doctrine во многом вдохновлялась именно Hibernate. Вы не знали этого?
По реализованным паттернам и поддерживаемым фичам. Непонятно даже откуда такой вопрос взялся.
Вопрос взялся от того, что вы, приводя пример, заявились как разбирающийся в библиотеке человек. Мне для того же — потребуется существенное время (вернуться в php, разобраться с Doctrine и т.д.). Ну и основываясь на ваших ответах, которые предполагают, что вы разбираетесь в технологии — можете сравнить Hibernate и Doctrine?
Пренебрежительное отношение к PHP в большинстве случаев возникает именно из-за вопиющего непонимания области его применения, а также из-за комплекса превосходства некоторых разработчиков из других областей.
Мой опыт общения с кодом на php и взаимодействия с проектом, реализуемым сторонней командой на php говорит иначе. Низкая квалификация и массовый говнокод даёт много-много радости при попытке заинтегрироваться (и ещё больше при переносе части функционала из php в java)...
PS это не означает, что я не видел лапшу или говнокод на java… Но сама java мешает говнокодить так же сильно, как это возможно на php.
можете сравнить Hibernate и Doctrine?
Doctrine недотягивает до Hibernate по ряду фич, но впереди релиз 3-ей версии и они там пошли чуть по другому пути. Хотя для моделирования предметной области все что надо с большего есть. В частности года 2 назад появились Embeddable объекты для VO и т.д. Работать с коллекциями довольно удобно...
То есть я бы сказал что с этим в PHP комьюнити неплохо и можно строить реально сложные приложения. НО… пользоваться доктриной умеет… не такое большое количество людей. Подавляющее большинство PHP разработчиков в принципе используют процедурное программирование с классами, ActiveRecord/Row Gateway/Table Gateway и живут не тужат. Даже те кто юзают доктрину используют ее в лучшем случае как Row Data Gateway а не как полноценную ORM. Многие даже не пытались разбираться с концепциями вроде unit of work и продолжают персистить сущности при обновлении не понимая что делают.
Лично мне Java не нравится, просто субъективное чувство. Вот Kotlin — он прекрасен.
Низкая квалификация и массовый говнокод даёт много-много радости при попытке заинтегрироваться (и ещё больше при переносе части функционала из php в java)...
Есть такая проблема. Во многом она вызвана тем, что получить какой-то результат в PHP намного проще и быстрее чем в Java.
Получаем результат -> радуемся -> эффект Даннинга Крюгера -> работаем дальше и вырабатываем привычку работать как получается -> напарываемся на проблему которую "как обычно" решить не удается и нужно развиваться и понимаем что напоролись на непреодолимую стену. А работать надо. А времени учиться нет. В итоге многие просто остаются на том уровне. Часть медленно ползет по стеночке.
НО если разработчику в начале пути повезет с командой можно расчитывать что он не будет ждать а будет развиваться более планомерно. Другое дело что в PHP комьюнити это скорее редкость.
Это мои личные наблюдения которые я вывел из общения с большим количеством PHP разработчиков.
Еще есть очень интересная штука… Из-за вот этого разделения на "php-ники и все остальные" отрыв между комьюнити становится больше, идеи и практики из других комьюнити сложнее проникают в php (банально психология людей). Как часто можно услышать при обсуждении очередной RFC по дженерикам "не делайте java из PHP". Люди не понимают профит от этих изменений и не хотят понимать, потому что у них уже негативное восприятие связанное с тем что джависты их гнобят.
Есть такая проблема. Во многом она вызвана тем, что получить какой-то результат в PHP намного проще и быстрее чем в Java.
Получаем результат -> радуемся -> эффект Даннинга Крюгера -> работаем дальше и вырабатываем привычку работать как получается -> напарываемся на проблему которую "как обычно" решить не удается и нужно развиваться и понимаем что напоролись на непреодолимую стену. А работать надо. А времени учиться нет. В итоге многие просто остаются на том уровне. Часть медленно ползет по стеночке.
Ну вот это вот и приводит к
Из-за вот этого разделения на "php-ники и все остальные"
Ну а дальше — по накатанной.
Т.е. проблема изначально в более низком базовом уровне, который заставляет резко расти разрыв уровней между разработчиками в разных языках. Аналогичной проблемы нет между языками java, c#, c++ и прочими (впрочем там есть другие проблемы… но они всё же не настолько остры). Что интересно, разрыв js <-> прочие аналогичен разрыву php <-> прочие, но js имеет свою уникальную экосистему, в которой может работать только он (прочие языки вынуждены транспилироваться/компилироваться в js), а php такой сферы не имеет. За счёт этого в js-мир нередко уходят люди с практиками из других языков. Отсюда страшный кавардак в FE, но при этом там происходит существенное развитие и об этом знают "в остальном мире". Про изменения в мире php в курсе в основном программисты php. И если сам язык и инструменты начинают подтягиваться к остальным по возможностям, то вот комьюнити на текущий момент (имхо) отстаёт.
Почему PHP в табличке, а 1С под табличкой, а не наоборот?
Хотя вы правы — ему нет место в одной таблице с CSS :)
https://www.google.com/trends/explore?date=all&q=%2Fm%2F060kv,%2Fm%2F07sbkfb,%2Fm%2F02p97
Может гугл изменил алгоритмы?
У вас есть данные в абсолютных цифрах?
тренды штука такая… Чем больше домохозяек в интернете, тем ниже популярность специфических ай-ти технологий.
Вы это все учли, когда "предлагали"?
А с Питона, похоже мигрировали в ПХП.
Странно, что ни в каком виде нет Паскаля. Я думал, ещё не все дельфисты пропали. CodeGear-то жив, вроде.
Delphi:
2015 — 709 вакансий
2016 — 923 вакансии
Разве это не топ-20 самых востребованных языков программирования за 2016 год?
Судя по описанию это достаточно фиксированный список, который зависит только от количества вакансий. И он не должен зависеть от какой-либо вольности в трактовках.
Да, можно поспорить насчёт SQL.
Да, Вы не включили в список 1С, но хотя бы сразу написали об этом.
Но похоже, что есть ещё языки, которые также оказались в немилости и были пропущены. Если это так, то ИМХО список как-то теряет весь вложенный смысл.
Статистика бесполезна, если она неверна.
Польза, на мой взгляд, не в конкретном месте языка, это же не «писькомерка», не соревнование, а в количестве вакансий за 15 и 16 год, чтобы оценить реальный спрос рынка на таких специалистов. Ну и в динамике первой пятерки за 5 лет, чтобы попробовать понять, как разные события влияют на спрос — это интереснее, чем место само по себе.
Неужели непонятно, что своим названием Вы утверждаете, что это языки находятся на первых N-позициях?
А в реальности может окажется, что это языки с 5 до 25 место, потому что первые 5 языков Вам не понравились.
Зато в этой статистике есть Delphi https://habrahabr.ru/company/kingservers/blog/307012/
Но да, делфистов еще много живых ))
Какая-то бесполезная, по-моему, статистика. Где данные по средней предлагаемой зарплате по этим востребованным языкам? Предположу, что массово требуются программисты PHP на низкую зарплату. 1C, Obj-С, Java изначально требуют более высокого уровня, поэтому вакансий меньше и они, скорее всего, дороже.
Какое это имеет отношение к блогам^Wхабам "программирование" и "C++" (а заодно "JavaScript" и "PHP") и потоку "Разработка"? Топайте в свой "Маркетинг" или куда-нибудь ещё.
Очень хочется иметь возможность заблеклистить определенные компании, которые со своими говностатьями замусоривают ленту. Уже даже потоки ввели, чтобы этот crap был отдельно, но они всё лезут..
Не могли бы вы посчитать не рост вакансий вообще, а либо рост/падение доли вакансий каждого языка в общей массе (например, php = было 5404/sum(2015), стало 9707/sum(2016), прирост = …), либо прирост каждго языка относительно прироста рынка в целом (например, php +79%, но все языки вместе взятые +50%, а, значит, php лишь +29%)?
Каждый кулик…
язык прост как пареная репа, кросс-платформа и куча готовых библиотек
И кстати, под это определение прекрасно подходит java, почему не на нее?
А в моём личном опыте все вокруг на расте пишут, и что? Его даже в топе пока нет
Как эта статистика собирается?
Я пытался подобную статистику из поиска извлечь, но возникало много вопросов. Например для C# вакансии иногда не содержат C#, а содержат .NET. Часто в вакансиях более одного языка, особенно заметно на результатах поиска C++.
JavaScript вообще в каждой второй присутствует.
У вас есть способ получения "основного языка программирования" из вакансий или вы также на результаты поиска смотрите?
Интересно, кому нужен SAS, на котором я пишу… Уверен, что числа будут небольшие.
Люблю в конце года смотреть на рейтинги ЯП. Особенно радует то, что популярность Си не падает и более того возрастает.
А если еще и напомнить, кто царь горы по скорости
По скорости работы… ассемблер. По определению быстрее него и прямых рук ничего быть не может.
По скорости разработки… точно не Си.
P.S. Си имеет свои область там где ассемблер слишком долго, а более высокоуровневый язык (даже С++) слишком медленно, но не стоит делать из него серебряную пулю или золотой молоток. Тем более что всякие Rust'ы, D, Go и т.п. переодически пытаются откусить от пирога C/C++.
По определению быстрее него и прямых рук ничего быть не может.
тут есть нюанс такой, что помимо прямых рук нужно досканально знать нюансы платформы, на которой будет выполняться код и т.д. И ребята которые пилят GCC могут похвастаться подобными знаниями и ровностью рук. То есть GCC будет генерить вам более эффективный код нежели вы напишите руками.
Вывод, если мы возьмем подавляющее большинство разработчиков то вариант на Си будет быстрее. Остальные могут просто быть такими же быстрыми (например rust на части задач по производительности будет таким же как Си).
По скорости разработки… точно не Си.
Смотря что писать. Некоторые вещи на Си пишутся так же быстро как и много чего еще. Другой нюанс что есть куча возможностей для выстрела в ногу, которые языки вроде rust разруливают на этапе компиляции и ограничивают разработчика от подобного.
В целом же это все крайности. Идеально было бы определить языки, которые находятся в балансе между скоростью разработки, безопасности, и скоростью выполнения. Так же имеет смысл смотреть на то, как все это ложится на конкретные задачи. Если рассматривать только одну сторону медали то это чуть более чем бесполезное сравнение.
И ребята которые пилят GCC могут похвастаться подобными знаниями и ровностью рук. То есть GCC будет генерить вам более эффективный код нежели вы напишите руками. Вывод, если мы возьмем подавляющее большинство разработчиков то вариант на Си будет быстрее.
Но это может быть справедливо и дальше: те кто пилит С++/Rust/Java/C# могут похвастаться подобными знаниями и ровностью рук, а значит их компиляторы могут генерить вам более эффективный код нежели вы напишите руками сами на С (а ведь на С очень многое делается руками).
Проблема в том что на кривые руки на любом более низкоуровневом языке могут сделать код хуже чем сделает компилятор на более высокоуровневом и С тут не исключение. Как только все уходит в высокие материи вроде многопоточного программирования, работы с веб протоколами надо иметь очень прямые руки чтобы написать руками тоже что уже есть из коробки в других языках.
Поэтому вывод неверен: без прямых рук и ассемблер и С могут быть медленнее прочих языков.
Go, Rust и даже скорее D(поскольку шаблоны) могут быть равными по скорости С++, но .NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что
.NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что
У С# и Java есть возможность компиляции в машинный код напрямую, учитывая оптимизации компиляторов и итераторов тут все неоднозначно. Может быть ситуация автоматически оптимизированный код будет более оптимальным.
Можем протестировать примеры, если покажете. Лично я заинтересован в C#, а в Яве из-за широкого использования рефлексии считаю подобную перспективу нереальной.
а в Яве из-за широкого использования рефлексии считаю подобную перспективу нереальной
А при чем тут рефлексия и машинный код? Рефлексия это возможность управлять полями классов напрямую, другими словами запрос дай значения поля X, это не требует байт кода, только сохранения метаданных и возможность прямой ссылки на поле или метод.
Вы может быть спутали рефлексию и кодогенерацию в рантайме (динамические загрузчики классов и т.п.), но это широко используется редко и в принципе компилятор в машинный код может и динамически классы грузить. Нет тут проблем.
Можем протестировать примеры, если покажете
Да на здоровье:
1. Native Compilation Tools
2. Excelsior JET
3. JWrapper
Это «бумажная» возможность, пока не применимая на практике.
В Java это вполне коммерческие продукты за которые платят хорошие деньги.
Эксельсиор — жутко дорогой, забыл по него
Jwrapper — это вообще не компилятор, а упаковщик исполнимого байткода вместе с JRE,
читаю про JServer Accelerator — так там вообще мрак и Оракл 8й версии
Про NET нет вариантов (точнее еще NET Native не готов)
Вы это пробовали лично?
Да нет, не спутал
Рефлексия в Java не меняет байт код, она меняет объекты классов. Объекты классов лежат в памяти и представляют обычные структуры данных. В терминах Си она сохраняет указатели на поля и методы объектов классов и позволяет обратиться в полю или методу по указателю. Ничего такого что нельзя было сделать на чистом С++.
По вашей ссылки на вики видно что рефлексия прекрасно существует и в компилированных языках.
Вы это пробовали лично?
Был опыт использования Эксельсиор'а
Тот же сайт Эксельсиора честно пишет — что с класслоадером используется обычная JIT-технология.
Примерно то же пишет и Микрософт с ограничениями Net Native
Тот же сайт Эксельсиора честно пишет — что с класслоадером используется обычная JIT-технология.
Ещё раз какое отношение ClassLoader имеет к Reflection API? Это никак не связанные в Java вещи. ClassLoader служит для загрузки новых классов, Reflection для изменения объектов существующих классов. Они вообще не связаны. Кастомные ClassLoader в Java используются редко, так это крайне небезопасно и вообще сильный хак.
Rust в целом не особо уступает C. Там конечно есть свои особенности и тикеты в трекере с пометкой slow, но они постепенно закрываются.
но .NET и Java — только на бумаге и в простых тестах (или когда библиотечный код превалирует). Пока что
Опять же смотря что брать и как мерять. JIT оптимизирует только горячий код, и делает это в случае с JVM весьма эффективно. Да, есть нюансы, но JVM в последних версиях вроде как умеет и циклы разворачивать сама и векторизацию вычислений. Так что… Все относительно и зависит от задачи. Ну и опять же, мы можем реализовать на Си те 1% кода которые являются батлнеком на худой конец.
По определению быстрее него и прямых рук ничего быть не может.
тут есть нюанс такой, что помимо прямых рук нужно досканально знать нюансы платформы, на которой будет выполняться код и т.д. И ребята которые пилят GCC могут похвастаться подобными знаниями и ровностью рук. То есть GCC будет генерить вам более эффективный код нежели вы напишите руками.
Поддержу, прямые руки — условие обязательное, но не достаточное. Вот не так давно натолкнулся на код «крутого ассемблерщика»:
void MemZero(void* ptr_, int size_)
{
__asm
{
cld
mov edi,ptr_
xor eax,eax
mov ecx,size_
rep stosb
}
}
Надо ли говорить, что после замены этого велосипеда на обыйный memset(ptr_, 0, size_); производительность функции сильно возросла (в случае SSE аж по 128 бит за раз обнуляется). И таких примеров было не мало.
Где-то также на побайтовый самопальный memCpy натыкался, реализованный другим умельцем на ассемблере (так же быстрее!). Когда ему открыли глаза, что современные реализации memcpy (даже не надо ipp'шные функции использовать, всё уже доступно из коробке в майкрософтсом CRT) могут копировать из памяти в память даже не помещая это в регистры, человек отмазался «ну не буду же я делать разные реализации одной функции».
Третий ассемблерный умелец, нагородил свой велосипед для синхронизации (что-то типа бесконечного спин лока на InterlockCmpExch), за 15 минут так и не разобрался как там работает, пришлось на CCriticalSection менять (не пинайте, VS2005 не поддерживала std::mutex).
В общем если бы не четвёртый сишник с прямыми руками, который хорошо на ассемблере писал, то моя вера в ассемблерщиков была бы полностью подорвана.
Ещё, кстати, хороший пример ручной оптимизации на ассемблере — это библиотеки типа ffmpeg. Если компилировать с ассемблерными вставками, то сразу + 30% к производительности, по сравнению с сишной версией скомпиленной интеловским же компилятором.
В общем моё мнение, что что-то на ассемблере можно сделать быстрее чем, на C, но в реальности на ассемблере часто делают медленнее, чем даже на C можно сделать. Например, то же копирование на C запросто можно не побайтого, а по 8 байт сделать за раз. Но в критическом коде без ассемблера тоже не всегда обойтись. Например, была у нас 2005ая студия, и её реализация CRT memcpy ничего не знала о movntdq, и копирование тормозило. Тут надо было решаться, или переходить на новую студию, либо писать свой самопальный memcpy с movntdq с fallback'ом на movdqa.
А сравниваются две ассемблерные реализации — поскольку все Сишные (да и не только Сишные) интринсики (intrinsics) написаны на ассемблере.
Просто не надо велосипедить, надо брать вылизанные библиотеки.
1) [очевидная истина, можно ассемблершик и сишник заменить почти любыми другими] если у ассемблерщика кривые руки, то он в большей части случае напишет хуже, чем сишник с прямыми руками.
2) [поддерживал предыдущего комментатора, про необходимость досконально знать нюансов платформы, под которую надо писать код ] даже если у ассемблерщика руки вроде как прямые, но он застрял в 90-х (с таблицами сколько тактов выполняются mmx инструкции на pentium 2), то такой тоже ничего хорошего не напишет в современных реалиях. Кстати ещё один случай вспомнился, как мне ассемблерщик доказывал что никак его код не мог замедлить программу. Так ему не понравился сгенеренный компилятор код и он решил написать свою реализацию на ассемблере. Ему тогда не понравился div, и он цитировал что-то вроде «Так, для 386-процессоров выполнение деления на двойное слово требует 38 тактов процессора, на слово — 22 такта, на байт — 14 тактов.». Пришлось ему найти спеку на современные интеловские процы, в которых div занимает 1 такт. Да и вообще, сейчас с конвейерами в процессорах уже никогда нельзя быть точно уверенным сколько тактов займёт та или иная ассемблерная команда, только прицениться на лучший и худший случаи. Поэтому у меня и вызывают уважение парни из ffmpeg'а или наши интеловцы из Нижнего, которые ipp пишут.
Самые востребованные языки программирования 2016