Только посмотрел так сказать для общего развития. С самим этим языком я раньше дел не имел, так что ни запускать, ни проверять уровень кода особой возможности не имею.
Кстати, как раз благодаря просмотру кода на разных языках неожиданно (изначально я этого не заметил) оказалось, что автор статьи ещё и смухлевал немного — код разный (принципиально, а не из-за особенности языка) на разных языках. Детали опишу в другом комментарии (ниже).
Во-первых, JVM бывают разные, есть очень маленькие.
Меньше получаемого в Rust/D/Nim исполняемого файла под той же платформой? )
В-третьих, JVM портирован почти везде, так что можно считать его частью системы.
Похоже кто-то тут путает кроссплатформенность (имеется не только у JVM, а много где, включая и Rust/D/Nim) и предустановленный в данной ОС рантайм. Я что-то не слышал про предустановленный рантайм Java на Windows или OSX или Linux…
Раз уж это моя статья позвольте мне и решать кого записывать в перспективные. Напишите свою — с удовольствием почитаю.
Выбирать критерии отбора языков — это безусловно авторское дело. Однако, даже если использовать для этого такой странный по нынешним временам (если конечно речь не про МК) параметр, как размер получаемого дистрибутива, то всё равно это надо делать честно (учитывая весь рантайм). Именно это один из главных недостатков статьи, просто бросающийся в глаза своей некорректностью.
На мой взгляд, красота и удобство Qt API в сравнении с убогой std в разы перевешивают возможные потери производительности.
Ха, совсем неудивительна симпатия Java-программиста к Qt. Только вот надо понимать, что это совсем не путь развития современного C++. Qt родилась в 90-ые (как раз одновременно с Java) и вся её архитектура из тех времён. Сейчас мир C++ уже далеко ушёл от этого в совсем другую сторону и данный Java-стиль является откровенным legacy. Конечно авторы Qt понемногу пытаются исправить эту ситуацию, но пока выходит очень слабо.
Да нет там никакого «Java стиля» обычный Qt-шный код.
)))
Код в студию, пожалуйста, только не в С-style.
Накидал сейчас для развлечения на нормальном C++ (с Boost'ом вместо Qt) программку с полностью аналогичной функциональностью. Значит получился один файл исходников из 70 строк/2,4 КБ, причём 1/3 файла занимают подключения заголовочных файлов и пространств имён. Исполняемый файл при полной (включая стандартную библиотеку языка, т.е. такой exe можно спокойно распространять везде в одиночку) статической линковке на 64-ёх битной Windows занимает 1 МБ. Время работы в 1,5 раза меньше, чем у приведённого в статье Java кода, что в общем то и ожидалось изначально.
Мда… Мне ещё не приходилось писать столько отрицательных комментариев, к статье с вроде как правильной изначальной идеей — такого уникально низкого уровня реализации я давно не видел.
Для начала сразу же повеселила фраза «Т.е. маленькая програмулька, которая печатает в консоль тупую строчку и должна занимать от силы 3-4Кб весит мегабайты!» Ну так оно и весит мегабайты на практически всех языках, кроме разве что чистого C++. В той же Java это будет более 100 мегабайт (мы же будем по честному считать, включая рантайм, не так ли?). Причём эта фраза была в статье не просто так, а на её основание из тестирование убрали как раз самые интересные и перспективные языки.
На фоне предыдущего пункта меня сильно поразило наличие в тестирование C++/Qt, т.к. как раз Qt и является примером очень жирной библиотеки — тут было явно что-то не то. Но когда я увидел размер программы на Qt в 37 КБ, то всё стало на свои слова — автор похоже ещё и не особо разбирается в разнице между статической и динамической линковкой…
Так же слегка шокировали слова «обычные язык, без откровений» по отношению к Scala. И это про язык, который принёс полноценное функциональное программирование и метапрограммирование в мир JVM.
После всего этого на результаты тестов уже можно было и не смотреть особо… Гораздо интереснее было взглянуть на исходники. И в первую очередь на вариант с C++. Собственно как и ожидалось, там был классический «java стиль», тот самый, который не позволяет писать быстродействующее ПО на C++. Если же решить эту простейшую задачку на нормальном современном C++ (и для начала это будет Boost, а не Qt), то она будет и в разы быстрее и в разы меньше кода.
В итоге статье крайне не понравилась огромным числом ляпов, не говоря уже о смешных итоговых результатах.
Прочитал ниже — да, я согласен с подобным описанием разных техник высасывания денег из игроков. Нюанс только в том, что подобным же «баблонасосом» является в нашем мире буквально всё вокруг. Например современная мода (скажем на одежду) — это те же деньги в обмен на понты. И что? Почему никто не призывает с этим бороться? )))
В нормальных играх система доната нисколько не раздражает, а рейтинги весьма слабо от него зависят (иначе это было бы просто соревнованием кошельков, которое мало кому интересно). Так что просто не стоит играть во всякий третьесортный мусор (даже если он при этом выпущен топовым издателем) — сейчас полно нормальных игр.
Что касается детей (назовём так тех, кто пока что не зарабатывает сам на свою жизнь), то у них безусловно не должно быть возможности свободно тратить родительские деньги. Причём это должно касаться не только игр, но и вообще всего. Правда в статье товарищ вроде как сам зарабатывал, так что там не всё понятно…
Ага, ага. ) Значит девочки, покупающие за не малые реальные деньги кастомизированный вид (какой-нибудь там розовый бронелифчик) брони в игре (естественно без изменения её параметров), или же мужики, покупающие опять же за реальные деньги надпись «За Сталина!» (опять же никак не влияющую на результат боя) на свой виртуальный танчик, просто испытывают при этом патологическое желание выигрыша? )))
Ну у психиатров среди любителей компьютерных игр тоже есть большое поле деятельности: например живущие (а иногда даже умирающие там от переутомления) в компьютерных клубах китайские и корейские игроки и т.п. случаи чрезмерного увлечения. Однако фокус в том, что именно такие проблемы очень редко сочетаются с обсуждаемой в статье проблемой траты денег на игры («задроты» и «донаты» — это обычно люди с совсем разным отношением к игре).
1. Указанная болезнь «Патологическое влечение к азартным играм» — это вообще о другом. Это о таких вещах как казино и игровые автоматы, в которых люди тратят деньги в ложной надежде (ну для регулярных игроков, а случайным как раз может и повезти) заработать ещё большие деньги. Это абсолютно противоположная большинству компьютерных игр психология, т.к. в них деньги практически всегда тратятся на увеличение комфорта игры, а не для попытки заработка.
2. А что такого странного в трате денег на своё хобби? Почему-то любителя рыбалки никто не будет осуждать за покупку новейших удочек… ))) Тем более, если речь о таких смешных цифрах (13 килобаксов за 6 лет) — даже если у человека нет никаких хобби, то он на банальных прогулках по барам/ночным клубам потратит в 10 раз больше за тоже время (причём это скорее всего будет менее полезно для здоровья).
Интересно, чем Zeplin, Balsamiq, Moqups и т.п. помогут руководителю команды, разрабатывающей скажем компилятор? Или СУБД? Или прошивку для МК? Или ещё 99,9% видов «digital продуктов», к которым данная статья даже близко не применима? Вы взяли крайне узкую область цифрового мира и распространили её специфику на весь этот огромный мир (если судить по заголовку). И кстати, даже в этой узкой специфики результаты несколько сомнительные, т.к. только один человек упомянул о системе контроля задач (Jira) и вроде никто не упоминал ни одного профессионального (с диаграммами Гантта, расчётом стоимости и т.п.) инструмента для планирования проектов. Ну да ладно, это уже мелочи по сравнению с фундаментальным несоответствием содержимого вашей статьи и заявленного в заголовке и введение.
Если бы статья называлась как-то вроде «20 полезных инструментов для команды фронтенд разработчиков», то это был бы уже вменяемый (хотя и довольно приевшийся) материал. А так…
Было бы действительно интересно почитать статью на тему паттернов проектирование в мире функционального программирования. Но к сожалению в данной статье ничего подобного не видно. Здесь имеется только обзор всем известных основ ФП и всё. Вот например какие паттерны мне надо применить при проектирование GUI библиотеки? Человек из ООП мира ответит сразу (ну или может пойдёт в начале полистает всем известную книжку и ответит потом). А что скажет сторонник ФП? «Использовать монады и функции»? Ну так это аналогично ответу «использовать классы» и ничего не говорит об архитектуре. В отличие от таких понятий как например «паттерн Посетитель» и т.п.
В общем я сильно порадовался названию статьи и полностью разочарован её содержимым. Буду ждать следующую попытку от адептов ФП…
Ну просто по факту это менее точный способ, т.к. чаще всего люди просто умножают ёмкость на номинальное напряжение (которое по факту держится на аккумуляторе только один краткий момент времени внутри одного цикла). Для получения реального значения надо посчитать интеграл этого произведения (в нормальной документации к аккумуляторам указываются графики напряжения), но естественно при подобных случаях (DIY и т.п.) никто этим не страдает, так что озвученное значение имеет скорее странный смысл «ёмкость умноженная на номинальное напряжение», а не реальную запасённую энергию.
Хм, ёмкость аккумуляторов традиционно измеряется в А*ч. Если почему-то очень лень указывать вместе с ёмкостью ещё и рабочее напряжение (хотя именно это и есть нормальный подход), то можно указать запасаемую в аккумуляторе энергию, которая измеряется в единицах Вт*ч. А вот про величину измеряемую в Вт/ч я что-то никогда не слышал.
Поэтому RTOS-ы на С++ еще долго будут не востребованы.
Глупости какие. Не стоит путать языка на котором написана ОС и то какие она предоставляет API. Внутри очень многие ОС написаны на C++ и это вполне оправдано, т.к. этот язык абсолютно во всём превосходит C. А вот API чаще его выставляется в процедурном стиле, т.к. он давно стандартен и его использование возможно из любых языков/компиляторов.
P.S. Если что, мы сами с большим удовольствием использую возможности C++17 в программирование под МК. Правда без всяких ОС. )))
Я к тому, что в других «взрослых» ОС процедурное API является следствием вполне фундаментальных причин, а не чем-то вроде отсталости и т.п. И вы с этими проблемами тоже столкнулись бы, если бы не ограничились упрощённой задачкой с исключительно монолитными прошивками.
Да, и кстати многие из этих взрослых ОС написаны внутри себя с помощью полноценного ООП ещё несколько десятков лет назад, только вот выставить наружу эти интерфейсы в API не получается.
Процедурный подход в современных ОС применяется в основном потому, что для него есть стандартизированный ABI, понимаемый всеми языками. Ничего аналогичного для ООП мира нет. Более того, если мы возьмём главный системный язык (C++), то его ООП ABI не совместим даже внутри разных компиляторов (и даже разных версий!) этого языка. Что уж тут говоришь о совместимости с другими языками. Другое дело, если у вас всё ПО будет компилироваться исключительно в одну бинарную прошивку вместе с ОС — тогда конечно же нет никаких проблем. Но если ваша ОС подразумевает возможность запуска чужого ПО в виде готовых бинарных сборок, то вряд ли у вас есть какой-то ещё выбор помимо процедурного API. Ну разве что ограничить разработку под вашу ОС одним языком и компилятором. )))
Кстати, как раз благодаря просмотру кода на разных языках неожиданно (изначально я этого не заметил) оказалось, что автор статьи ещё и смухлевал немного — код разный (принципиально, а не из-за особенности языка) на разных языках. Детали опишу в другом комментарии (ниже).
Меньше получаемого в Rust/D/Nim исполняемого файла под той же платформой? )
Похоже кто-то тут путает кроссплатформенность (имеется не только у JVM, а много где, включая и Rust/D/Nim) и предустановленный в данной ОС рантайм. Я что-то не слышал про предустановленный рантайм Java на Windows или OSX или Linux…
Выбирать критерии отбора языков — это безусловно авторское дело. Однако, даже если использовать для этого такой странный по нынешним временам (если конечно речь не про МК) параметр, как размер получаемого дистрибутива, то всё равно это надо делать честно (учитывая весь рантайм). Именно это один из главных недостатков статьи, просто бросающийся в глаза своей некорректностью.
Ха, совсем неудивительна симпатия Java-программиста к Qt. Только вот надо понимать, что это совсем не путь развития современного C++. Qt родилась в 90-ые (как раз одновременно с Java) и вся её архитектура из тех времён. Сейчас мир C++ уже далеко ушёл от этого в совсем другую сторону и данный Java-стиль является откровенным legacy. Конечно авторы Qt понемногу пытаются исправить эту ситуацию, но пока выходит очень слабо.
)))
Накидал сейчас для развлечения на нормальном C++ (с Boost'ом вместо Qt) программку с полностью аналогичной функциональностью. Значит получился один файл исходников из 70 строк/2,4 КБ, причём 1/3 файла занимают подключения заголовочных файлов и пространств имён. Исполняемый файл при полной (включая стандартную библиотеку языка, т.е. такой exe можно спокойно распространять везде в одиночку) статической линковке на 64-ёх битной Windows занимает 1 МБ. Время работы в 1,5 раза меньше, чем у приведённого в статье Java кода, что в общем то и ожидалось изначально.
Для начала сразу же повеселила фраза «Т.е. маленькая програмулька, которая печатает в консоль тупую строчку и должна занимать от силы 3-4Кб весит мегабайты!» Ну так оно и весит мегабайты на практически всех языках, кроме разве что чистого C++. В той же Java это будет более 100 мегабайт (мы же будем по честному считать, включая рантайм, не так ли?). Причём эта фраза была в статье не просто так, а на её основание из тестирование убрали как раз самые интересные и перспективные языки.
На фоне предыдущего пункта меня сильно поразило наличие в тестирование C++/Qt, т.к. как раз Qt и является примером очень жирной библиотеки — тут было явно что-то не то. Но когда я увидел размер программы на Qt в 37 КБ, то всё стало на свои слова — автор похоже ещё и не особо разбирается в разнице между статической и динамической линковкой…
Так же слегка шокировали слова «обычные язык, без откровений» по отношению к Scala. И это про язык, который принёс полноценное функциональное программирование и метапрограммирование в мир JVM.
После всего этого на результаты тестов уже можно было и не смотреть особо… Гораздо интереснее было взглянуть на исходники. И в первую очередь на вариант с C++. Собственно как и ожидалось, там был классический «java стиль», тот самый, который не позволяет писать быстродействующее ПО на C++. Если же решить эту простейшую задачку на нормальном современном C++ (и для начала это будет Boost, а не Qt), то она будет и в разы быстрее и в разы меньше кода.
В итоге статье крайне не понравилась огромным числом ляпов, не говоря уже о смешных итоговых результатах.
Что касается детей (назовём так тех, кто пока что не зарабатывает сам на свою жизнь), то у них безусловно не должно быть возможности свободно тратить родительские деньги. Причём это должно касаться не только игр, но и вообще всего. Правда в статье товарищ вроде как сам зарабатывал, так что там не всё понятно…
1. Указанная болезнь «Патологическое влечение к азартным играм» — это вообще о другом. Это о таких вещах как казино и игровые автоматы, в которых люди тратят деньги в ложной надежде (ну для регулярных игроков, а случайным как раз может и повезти) заработать ещё большие деньги. Это абсолютно противоположная большинству компьютерных игр психология, т.к. в них деньги практически всегда тратятся на увеличение комфорта игры, а не для попытки заработка.
2. А что такого странного в трате денег на своё хобби? Почему-то любителя рыбалки никто не будет осуждать за покупку новейших удочек… ))) Тем более, если речь о таких смешных цифрах (13 килобаксов за 6 лет) — даже если у человека нет никаких хобби, то он на банальных прогулках по барам/ночным клубам потратит в 10 раз больше за тоже время (причём это скорее всего будет менее полезно для здоровья).
Если бы статья называлась как-то вроде «20 полезных инструментов для команды фронтенд разработчиков», то это был бы уже вменяемый (хотя и довольно приевшийся) материал. А так…
В общем я сильно порадовался названию статьи и полностью разочарован её содержимым. Буду ждать следующую попытку от адептов ФП…
Глупости какие. Не стоит путать языка на котором написана ОС и то какие она предоставляет API. Внутри очень многие ОС написаны на C++ и это вполне оправдано, т.к. этот язык абсолютно во всём превосходит C. А вот API чаще его выставляется в процедурном стиле, т.к. он давно стандартен и его использование возможно из любых языков/компиляторов.
P.S. Если что, мы сами с большим удовольствием использую возможности C++17 в программирование под МК. Правда без всяких ОС. )))
Да, и кстати многие из этих взрослых ОС написаны внутри себя с помощью полноценного ООП ещё несколько десятков лет назад, только вот выставить наружу эти интерфейсы в API не получается.