C++ не менее многословный. А то и более. Ничего, пишут в блокнотах как-то.

Не стоит думать, что защищаю кресты, они далеко не безупречны. Но минус на минус не даёт плюс в данной ситуации и от оверхедов в крестах жава лаконичнее не становится.

В удобстве разработки, качестве конечного результата.

Качество зависит от человеков. Впрочем, в джаве я качества не вижу. Типичный пример - почему джава для джавы, то есть все эти IDE, на которых она пишется - почему решительно все они (популярные) безбожно тормозят? Ни idea, ни eclipse, ни netbeans быстрыми назвать ни в коем случае нельзя.

Если взять жаву для мобильных устройств, то её использование оправдано далеко не качеством работы, а лишь одним свойством - кросплатформенностью софта. Уж за что я недолюбливаю Apple, но уж точно не за софт - по отношению с андроидами их софт на objC весьма адекватен.

Удобство разработки? Ну, может для кого-то это и так. Но если Пете удобнее пользоваться языком А, а Серёже - языком Б, то это ещё не говорит о каком-то явном и бесспорном превосходстве одного над другим в этой области. Субьективщина, чего уж.

Время набора текста это дай бог 10% от общего времени разработки. А то и 1-2%. Если время набора текста увеличится в 2 раза (пессимистичный сценарий), то время разработки увеличится на 10%.

Тут всё зависит от подхода. Не скажу за других, но лично я сначала продумываю алгоритмы и структуру, а потом уже сажусь писать. И тогда написание кода занимает четверть, треть, а то и половину времени.

Сложно жить в твоём мире.

массивы и вложенность легко реализуются в INI:

[enumA]
a
b с
d e f


[nesting]
enumA
enumB

и да - можно использовать ФС:

например, сделать так, чтобы разбор a.b.c.ini означал предварительную подгрузку родительских ini, тем самым что-то можно еще и переопределить:

c.ini
b.c.ini
a.b.c.ini

надо было ещё добавить -XX:+TieredCompilation, чтоб быстрей грелся

Сложно жить в твоём мире.

Нет, достаточно избегать приложений на яве и не слушать бред от ява-фанатов.

Не стоит думать, что защищаю кресты, они далеко не безупречны. Но минус на минус не даёт плюс в данной ситуации и от оверхедов в крестах жава лаконичнее не становится.

Тем не менее это не мешает людям писать на обоих этих языках огромные кодовые базы.

Качество зависит от человеков.

Согласен. От людей в первую очередь. Но хорошие инструменты тоже не просто так делают. Как IDE, так и другие.

Впрочем, в джаве я качества не вижу. Типичный пример - почему джава для джавы, то есть все эти IDE, на которых она пишется - почему решительно все они (популярные) безбожно тормозят? Ни idea, ни eclipse, ни netbeans быстрыми назвать ни в коем случае нельзя.

У меня Idea не тормозит. Как и большинство других Java-приложений, которыми я пользовался.

Если взять жаву для мобильных устройств, то её использование оправдано далеко не качеством работы, а лишь одним свойством - кросплатформенностью софта. Уж за что я недолюбливаю Apple, но уж точно не за софт - по отношению с андроидами их софт на objC весьма адекватен.

Какого рода кроссплатформенность имеется в виду? Андроид это вообще другой мир, там своя виртуальная машина, свои библиотеки, свои приложения. Пересечение есть, но только в области библиотек и то ограниченное. Взяли Java скорее всего потому, что её все знают, её везде учат и поэтому легко перейти на новую платформу. Примерно по тем же причинам, по которым в Java использовали C++-подобный синтаксис.

Удобство разработки? Ну, может для кого-то это и так. Но если Пете удобнее пользоваться языком А, а Серёже - языком Б, то это ещё не говорит о каком-то явном и бесспорном превосходстве одного над другим в этой области. Субьективщина, чего уж.

Ну можно статистику собрать. Она говорит, что индустрия перепрыгнула с C++ на Java, практически в первые же годы её появления.

Тут всё зависит от подхода. Не скажу за других, но лично я сначала продумываю алгоритмы и структуру, а потом уже сажусь писать. И тогда написание кода занимает четверть, треть, а то и половину времени.

Может ты уникум, но по индустрии средняя производительность программиста — 2-5 строк кода в день. Если пишешь новый софт — ну может 50-100 строк.

Действительно заменили. Это дико спортное решение, которое у многих вызвало кучу вопросов. К версии DUB 0.7.25 _зачем-то_ внедрили формат Simple Descriptive Language. Основная мотивация - в json нельзя писать на «нулевом» уровне вложенности и нет комментариев.

Крайне неудачный выбор. Мало того, что форматом пользуются 3.5 real life софтины, так еще и неудачное название (SDL - это известная штука, и она не про конфиг-файлы). Плюс, сайт формата... тупо лежит лежит уже пару месяцев (http://sdl.ikayzo.org/).

JSON все еще поддерживается, но как бы deprecated и новый проекты по умолчанию делаются в sdlang.

Утешимся тем, что это всего лишь формат конфигов, он очень прост и разобраться в нем можно за 10 секунд строгого взгляда в конфиг. Little pains, little gains.

Взяли Java скорее всего потому, что её все знают, её везде учат и поэтому легко перейти на новую платформу.

А еще потому, что нельзя спрогнозировать, на каком железе софтина будет запускаться.

А фибоначчи, фибоначчи как?

У меня Idea не тормозит.

У подавляющего большинства тормозит, они не могут собирать hi-end конфигурации для одного лишь кодинга.

Какого рода кроссплатформенность имеется в виду? Андроид это вообще другой мир, там своя виртуальная машина, свои библиотеки, свои приложения. Пересечение есть, но только в области библиотек и то ограниченное.

Андроид это как пример не очень удачно, однако и чистую джаву не используют в мобильных устройствах, а при удобном случае апологеты всё равно говорят: «жава есть хоть под тостер, у всех всё зашибись».

Ну можно статистику собрать. Она говорит, что индустрия перепрыгнула с C++ на Java, практически в первые же годы её появления.

Ну-ну, не надо сгущать краски. «Активно пользоваться» и «полностью сменить» это не одно и то же. Плюсы до сих пор очень популярны.

Может ты уникум, но по индустрии средняя производительность программиста — 2-5 строк кода в день. Если пишешь новый софт — ну может 50-100 строк.

Не спорю, поддержка существующего и написание нового кода это разные вещи. Но да, меня так со школьной скамьи научили, и взаправду - системный подход к разработке даже одним человеком на чём-то чуть круче helloworld'а уже оправдан.

Реализовал тест на либе которая используется у меня на работе. код теста : http://pastebin.com/zPZekvjT

Результаты:

Javascript Node
0.49962461411279646
0.5000679585097806
0.5003248037503812
2.36s, 903.1Mb
Ruby
0.49962461411279646
0.5000679585097806
0.5003248037503812
8.14s, 2103.1Mb
D
0.49962461
0.50006796
0.50032480
8.81s, 1416.4Mb
Python
0.499624614113
0.50006795851
0.50032480375
8.13s, 1410.1Mb
C++ Boost
0.49962461
0.50006796
0.50032480
11.23s, 2863.1Mb
c++ json2 - мой тест
0.499625
0.500068
0.500325
2.84s, 24.7Mb

На мой взгляд производительности nodejs более чем достаточно.

Для python ujson раз в 10 быстрее стандартного. Другой разговор, что парсер json в python ещё и удобная чтука с кучей плюшек. :)

Я вот тут писал: http://habrahabr.ru/post/228707/

Хорош, Чорный Властелин, мы поняли тебя.

Да там много чего можно было для оптимизации сделать. Например еще и с опциями gc поиграться. И, кстати, попробовать другие парсеры, jackson вроде не самый быстрый.

Нет, достаточно избегать приложений на яве и не слушать бред от ява-фанатов.

Ты надеюсь понимаешь, что твоё сообщение было обработано приложением на Java? :) Как-то плохо у тебя получается их избегать. Я думаю, в твоей жизни участвует куда больше приложений на Java, чем ты думаешь.

Если ты про само предложение, где идет сравнение с питоном, то это вброса ради же

quote: В любом случае троллинг уныл

Но да, эффект достигнут :)

Ждём D на GPGPU!

Удваиваю вопрос.

Да как обычно все. Оптимизированная и, возможно, урезанная реализация vs тяп-ляп реализация.

Взяли Java скорее всего потому, что её все знают, её везде учат и поэтому легко перейти на новую платформу.

А еще потому, что нельзя спрогнозировать, на каком железе софтина будет запускаться.

Ещё раз. На андроиде от Java только язык. VM у них своя. Они могли хоть хаскель взять в качестве исходного языка. Языков с виртуальной машиной в мире очень много и любой из них можно запускать на более-менее любой платформе. Я больше скажу — даже C можно запускать на любом железе, если использовать специальные инструменты для этого.

Андроид это как пример не очень удачно, однако и чистую джаву не используют в мобильных устройствах, а при удобном случае апологеты всё равно говорят: «жава есть хоть под тостер, у всех всё зашибись».

Жава есть под все серверные платформы (Windows + *nix). Этого ей хватает. На десктопе по ряду причин она не взлетела, на мобилках я тоже не агитирую её использовать.

Ну-ну, не надо сгущать краски. «Активно пользоваться» и «полностью сменить» это не одно и то же. Плюсы до сих пор очень популярны.

В сфере корпоративного софта (подавляющее большинство программ) нет. Только если очень специфичные требования к производительности.

Ух ты, педон не только самый тормозной, но и память, сцук, жрет. Вот это новость!

а генты весь портаж на это гуано написан. вот нахуа спрашивается если есть перл и из генты его тоже не выкинуть?

а какую реализацию D использовали? GDC, DMD или LDC? в обсуждаемом тесте, например, именно GDC

Ты надеюсь понимаешь, что твоё сообщение было обработано приложением на Java? :)

Понимаю, но что это дает? У меня есть возможность переключить ЛОР?

Как-то плохо у тебя получается их избегать.

Такова уж реальность.

Я думаю, в твоей жизни участвует куда больше приложений на Java, чем ты думаешь.

Откуда вы знаете, что я думаю?

Сишные парсеры? Они представлены в списке, вот например: https://github.com/lloyd/yajl/tree/master/src

Это аналогично самому быстрому парсеру на Python, который тупо вызывает С код.

Нет.

Ну я как бы и не спорю - почему-то жава прижилась в кровавом энтерпрайзе. Но нельзя говорить, что она тут одна, ни в коем случае. Многое зависит от задач.

На десктопах джава предоставлена только майнкрафтом и в целом не нужна. На контроллерах и всяком embedded она не нужна ещё больше, но находятся безголовые фанатики, которые пытаются впихуть невпихуемое.

Есть история про человечка, который собрал робота размером с торс человека, а софт его был джавой. Робот умел только несколько минут калиброваться и ломать себя, хотя у человечка-сборщика было N лет опыта работы исключительно на джаве в интерпрайзе, а на робота было вбухано много времени, денег и сил.

        asm //pure @nogc nothrow
        {
            naked;
            movdqu XMM1, [RDI];
            mov R10, constant;
            movq XMM2, R10;
            mov RAX, charsLength;
            mov RDX, 16;
            pcmpestri XMM2, XMM1, flags;
            mov RAX, RCX;
            ret;
        }

Wow! So D! Much portability!

На DMD, не нашел как на женте установить GDC :( зато собрал c++ rapid : 0.65s, 752.2Mb

все это не нужно ведь есть перл.

А jansson кто-нибудь тестировал? Я ее везьде юзаю.

simd в D часть языка, если что

https://doc.rust-lang.org/std/simd/
http://huonw.github.io/blog/2015/08/simd-in-rust/

DMD медленный и использовать его для бенчмарков не имеет смысла.

А что из этого будет работать на ARM и MIPS?

И что? Вы агитируете юзать медленно работающий, но зато универсальный код? Я вообще-то к тому, что нетривиальные оптимизации там все же есть, хоть и для определенной платформы. Т.е. в принципе, результат этого «бенча» все же может быть не просто результатом «неправильного замера».

не поддерживает бинарные строки. Приходится рекурсивно кодировать в base64

base64 — не самая элегантная кодировка, бро. Попробуй что-нибудь в духе https://en.wikipedia.org/wiki/Percent-encoding (для невалидных с точки зрения utf8 байтов)

Лучше бы для rust написали хороший html парсер

Можешь не сомневаться, Mozilla обязательно напишет хороший парсер html и на этом языке тоже :D

сравнение самой быстрой реализации на скриптовом языке по сравнению с реализацией на компилируемом языке

Вот знаешь, с появлением jit для утино-типизированного js, всё это кудахтанье про «скриптовый язык» вызывает только жалость

Зачем нужен JSON, когда есть INI?

У них разные ниши абсолютно. INI - для удобства людишек, а JSON - для удобства робатов и для структур с большой степенью вложенности.

И что? Вы агитируете юзать медленно работающий, но зато универсальный код?

Да, именно так. Кроссплатформенный код приносит больше пользы обществу в перспективе чем быстрый но залоченый на конкретного вендора.

В реальных проектах нужны и масивы и вложенность на пару-тройку уровней.

Массивы в ini делаются спокойно, как и пара уровней вложенности. https://github.com/toml-lang/toml/blob/master/examples/example-v0.4.0.toml

А больше двух уровней вложенности — не дружественно к людям. Аффтарам системы нужно напрячь остатки мозга и пересмотреть структуру конфигурационного файла

Уже написали: https://github.com/servo/html5ever

JSON-парсер не должен приностиь пользу обществу. Он должен, как ни странно, парсить JSON.

JSON - это, в первую очередь, веб. Много веб-серверов на ARM и MIPS?

Изволь померить для serde (https://github.com/serde-rs/serde).

Я так понял, они для serde и меряют. https://github.com/kostya/benchmarks/tree/master/json/json.rs

Понятнее YAML ничего нет

Как по мне понятнее yaml ничего нет.

Подписываюсь под каждым словом.

Открываю некоторую статью на Швабре, а там такое:

{«AcpiRootBridgePxm»:«Enabled»,«AcpiRtcSupport»:«Disabled»,«AcpiSlit»:«Enabled»,«AdjSecPrefetch»:«Enabled»,«AdminEmail»:"",«AdminName»:"",«AdminOtherInfo»:"",«AdminPassword»:"",«AdminPhone»:"",«AdvancedMemProtection»:«AdvancedEcc»,«AsrStatus»:«Enabled»,«AsrTimeoutMinutes»:«10»,«AssetTagProtection»:«Unlocked»,«AttributeRegistry»:«HpBiosAttributeRegistryP86.1.1.0»,«AutoPowerOn»:«RestoreLastState»,«BootMode»:«LegacyBios»,«BootOrderPolicy»:«RetryIndefinitely»,«ChannelInterleaving»:«Enabled»,«CollabPowerControl»:«Enabled»,«ConsistentDevNaming»:«LomsOnly»,«CustomPostMessage»:"",«DcuIpPrefetcher»:«Enabled»,«DcuStreamPrefetcher»:«Enabled»,«Description»:«This is the Platform/BIOS Configuration (RBSU) Current Settings»,«Dhcpv4»:«Enabled»,«DynamicPowerCapping»:«Auto»,«DynamicPowerResponse»:«Fast»,«EmbNicEnable»:«Enabled»,«EmbSata1Enable»:«Enabled»,«EmbSata2Enable»:«Enabled»,«EmbVideoConnection»:«Auto»,«EmbeddedDiagnostics»:«Enabled»,«EmbeddedDiagsMode»:«Auto»,«EmbeddedSata»:«Raid»,«EmbeddedUefiShell»:«Enabled»,«EmsConsole»:«Disabled»,«EnergyPerfBias»:«BalancedPerf»,«EraseUserDefaults»:«No»,«ExtendedAmbientTemp»:«Disabled»,«ExtendedMemTest»:«Disabled»,«F11BootMenu»:«Enabled»,«FanFailPolicy»:«Shutdown»,«FanInstallReq»:«EnableMessaging»,«HwPrefetcher»:«Enabled»,«IntelDmiLinkFreq»:«Auto»,«IntelPerfMonitoring»:«Disabled»,«IntelProcVtd»:«Enabled»,«IntelQpiFreq»:«Auto»,«IntelQpiPowerManagement»:«Enabled»,«IntelTxt»:«Disabled»,«IntelligentProvisioning»:«Enabled»,«Ipv4Address»:«0.0.0.0»,«Ipv4Gateway»:«0.0.0.0»,«Ipv4PrimaryDNS»:«0.0.0.0»,«Ipv4SecondaryDNS»:«0.0.0.0»,«Ipv4SubnetMask»:«0.0.0.0»,«MaxMemBusFreqMHz»:«Auto»,«MaxPcieSpeed»:«MaxSupported»,«MemFastTraining»:«Enabled»,«MinProcIdlePkgState»:«C6Retention»,«MinProcIdlePower»:«C6»,«MixedPowerSupplyReportngi»:«Enabled»,«Modified»:«2015-02-12T20:16:59+00:00»,«Name»:«BIOS Current Settings»,«NetworkBootRetry»:«Enabled»,«NicBoot1»:«NetworkBoot»,«NicBoot2»:«Disabled»,«NmiDebugButton»:«Enabled»,«NodeInterleaving»:«Disabled»,«OldAdminPassword»:"",«OldPowerOnPassword»:"",«PciBusPadding»:«Enabled»,«PostF1Prompt»:«Delayed20Sec»,«PowerButton»:«Enabled»,«PowerOnDelay»:«None»,«PowerOnLogo»:«Enabled»,«PowerOnPassword»:"",«PowerProfile»:«BalancedPowerPerf»,«PowerRegulator»:«DynamicPowerSavings»,«PreBootNetwork»:«EmbNic»,«ProcCoreDisable»:0,«ProcHyperthreading»:«Enabled»,«ProcNoExecute»:«Enabled»,«ProcTurbo»:«Enabled»,«ProcVirtualization»:«Disabled»,«ProcX2Apic»:«Enabled»,«ProductId»:«777424-AA1»,«QpiBandwidthOpt»:«Balanced»,«QpiSnoopConfig»:«Standard»,«RedundantPowerSupply»:«BalancedMode»,«RemovableFlashBootSeq»:«ExternalKeysFirst»,«RestoreDefaults»:«No»,«RestoreManufacturingDefaults»:«No»,«RomSelection»:«CurrentRom»,«SataSecureErase»:«Disabled»,«SaveUserDefaults»:«No»,«SecureBoot»:«Disabled»,«SerialConsoleBaudRate»:«115200»,«SerialConsoleEmulation»:«Vt100Plus»,«SerialConsolePort»:«Auto»,«SerialNumber»:«8CW4340081»,«ServerAssetTag»:"",«ServerName»:"",«ServerOtherInfo»:"",«ServerPrimaryOs»:"",«ServiceEmail»:"",«ServiceName»:"",«ServiceOtherInfo»:"",«ServicePhone»:"",«SettingsResult»:{«ETag»:"",«Messages»:[{«MessageArgs»:[],«MessageID»:«Base.1.0:Success»}],«Time»:«»},«Sriov»:«Enabled»,«ThermalConfig»:«OptimalCooling»,«ThermalShutdown»:«Enabled»,«TimeZone»:«Utc0»,«TpmBinding»:«Disabled»,«TpmOperation»:«Disable»,«TpmState»:«NotPresent»,«TpmType»:«NoTpm»,«TpmVisibility»:«Visible»,«Type»:«HpBios.1.0.0»,«UefiOptimizedBoot»:«Enabled»,«UefiPxeBoot»:«Auto»,«UefiShellBootOrder»:«Disabled»,«UefiShellStartup»:«Disabled»,«UefiShellStartupLocation»:«AttachedMedia»,«UefiShellStartupUri»:"",«UrlBootFile»:"",«Usb3Mode»:«Auto»,«UsbBoot»:«Enabled»,«UsbControl»:«UsbEnabled»,«UtilityLang»:«English»,«VideoOptions»:«BothVideoEnabled»,«VirtualInstallDisk»:«Disabled»,«VirtualSerialPort»:«Com2Irq3»,«WakeOnLan»:«Enabled»,«links»:{«BaseConfigs»:{«href»:«/rest/v1/systems/1/bios/BaseConfigs»},«Boot»:{«href»:«/rest/v1/systems/1/bios/Boot»},«Mappings»:{«href»:«/rest/v1/systems/1/bios/Mappings»},«Settings»:{«href»:«/rest/v1/systems/1/bios/Settings»}}}

Нужны ли ещё доказательства, что JSON не приспособлен для людей.

YAML

INI - для удобства людишек, а JSON - для удобства робатов и для структур с большой степенью вложенности.

YAML для удобства людишек не в ущерб удобства робатам.

YAML - overrated кусок говна. Вот эта портянка — Парсер JSON, написанный на D, стал самым быстрым парсером JSON в мире (комментарий) — полностью корректный YAML.

Го вообще никогда и не заявлялся как системный/низкоуровневый язык.

By its design, Go proposes an approach for the construction of system software on multicore machines.

Осталось только парсер на фокале написать для полного счастья

Факап не нужен. Равно как и половина упомянутых в новости языков.

JSON is YAML

YAML - overrated кусок говна. Вот эта портянка — Парсер JSON, написанный на D, стал самым быстрым парсером JSON в мире (комментарий) — полностью корректный YAML.

Вы заставляете меня соглашаться с вами и плакать. Зачем только JSON сделали валидным подвидом YAML.