GitHub опубликовал отчёт с анализом статистики за 2020 год. Основные тенденции:...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54186
как там со статистикой выпила неугодных реп?
> Аудитория GitHub возросла на 15 млн пользователей
> как там со статистикой выпила неугодных реп?Никому не интересна.
>> Аудитория GitHub возросла на 15 млн пользователей
>> как там со статистикой выпила неугодных реп?
> Никому не интересна.Ну мы то знаем, как сделать, чтобы какая-то информация была никому не интересна. Всегда было интересно, как Анонимы, путающие причину и следствие и транслирующие бред, смогли закончить школу?.. А точно, они её ещё не закончили
> Ну мы то знаем, как сделать, чтобы какая-то информация была никому не интересна.Да. Считать интересным что-то неинтересное.
Эта тема тактично опущена.
https://github.com/github/dmca
Посоветуйте годной литературы по плюсам, чтобы не вызывала отвращения. Современной. Желательно, с картинками и best practices and gotchas, можно с интересным историческим экскурсом но желательно поближе к реальности. Немного устал от программерской литературы сорокалетней давности и касательно плюсов такая ничему хорошему не научит сегодня (т.е. Саттер конечно норм, но старьё).
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
В принципе норм, пару поинтов к сведению принял. А что-нибудь практического и увлекательного? Желательно, с оптимизациями, писать неоптимальный код и я умею.
Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится, сколько к математике.
> Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится,
> сколько к математике.У Саттера читал что-то такое по-моему, там было про решение плюсоспецифичных проблем. Да и сам язык довольно специфический, очень много возможностей случайно отстрелить голову.
>> Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится, сколько к математике.
> У Саттера читал что-то такое по-моему, там было про решение плюсоспецифичных проблем.
> Да и сам язык довольно специфический, очень много возможностей случайно отстрелить
> голову.Аа, ну это не про оптимизацию, а про говнокодинг?
Ну это чтобы было понимание как делать не нужно и к чему это приведёт и как всё таки можно если очень надо. Наверное всё же больше про оптимизацию, только чтобы компилятор с ума от UB не сходил.
> Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится, сколько к математике.Не совсем. Алгоритмы алгоритмами, но программирование -- это не только умение выбрать/составить алгоритм, это ещё и умение этот алгоритм изложить так, чтобы с минимумом абстракций, максимально понятно для читателя, чтобы было возможно вносить изменения, чтобы эти изменения в виде патчей не меняли бы больше строк, чем нужно, чтобы документируемо, чтобы тестами можно было покрыть, чтобы баги можно было искать, причём желательно чтобы большинство багов было бы сделано невозможным, потому что структура кода и/или используемые типы не позволяют...
И когда мы берём всё это вместе и объединяем с языком типа C++, то это всё -- отдельное умение, на самом деле это и есть уровень квалификации в языке программировании. О таких вещах неплохо было бы и в отношении куда более простого C рассказывать -- типа как можно креативно использовать макросы, чтобы делать вещи, в которых без макросов утонешь в boilerplate, и поэтому если без макросов, то лучше везде вместо типизированных указателей использовать void* и хрен с ним с типизацией. В смысле ошибок будет меньше, несмотря на нетипизированные указатели, просто потому что меньше кода руками набирать придётся, и меньше тупых ошибок будет совершено. Или может стоит в каких-то случаях объявить функцию как static inline, передавать туда и возвращать оттуда килобайтовую структуру по значению? Или не стоит так делать, потому что тупой препод в ВУЗе за такое на пересдачу отправлял?
В языках типа C и C++ довольно много таких нюансов, которые хрен где прочитаешь. Только через опыт изучения чужого кода и разглядывание дизассемблерных дампов можно въехать. И в C++ такого больше, потому что там больше возможностей. Я лет двадцать назад, когда выкинул венду и влез в linux, быренько добрался до сорцов ядра, и шаблоны у меня тогда трещали по всем швам. Хрен с ним с goto, который considered harmful -- я привык к jmp в асме, и на goto смотрел без испуга. Но, как щаз помню, list.h мне просто вынес мозг. Я целый день разглядывал его, примеры его использования, разбираясь в том, как это работает. Хотя, казалось бы, чего там: циклический список с принудительной связью и заголовком. Но как завёрнуто -- я не думал, что на C можно писать так.
Вот и вы путаете такие абстракции, как оптимизация (логика приложения) и говнокод (синтаксис и тп).
Первое от языка не зависит, а второе у каждого языка своё.
Добавлю ещё.
Первое делит программистов на архитекторов и тыжпрограммистов.
Второе на джуниоров/миддлов/сеньёров.
> Добавлю ещё.
> Первое делит программистов на архитекторов и тыжпрограммистов.
> Второе на джуниоров/миддлов/сеньёров.Я б порекомендовал тебе _сначала_ стать сеньёром-архитектором, и только _потом_ придумывать классификации программистов.
>> Добавлю ещё.
>> Первое делит программистов на архитекторов и тыжпрограммистов.
>> Второе на джуниоров/миддлов/сеньёров.
> Я б порекомендовал тебе _сначала_ стать сеньёром-архитектором, и только _потом_ придумывать
> классификации программистов.Очевидно, что для успешной карьеры полезно прокачивать оба направления одновременно.
> Очевидно, что для успешной карьеры полезно прокачивать оба направления одновременно.Нет. Дети в возрасте около года-двух становятся озабоченными созданием категорий и раскладыванием всех явлений объектов по категориям. С одной стороны это делает мышление более заострённым, но с другой стороны мешает и путается под ногами. Поэтому когда ты выходишь из того возраста активной категоризации мира, лучше притормозить и не категоризировать почём зря. Пока тебе какой-то набор категорий не нужен для профессиональной деятельности, лучше этих категорий не иметь, потому что если ты категории введёшь криво, то это изменит твоё восприятие и ты этого даже не заметишь.
Я могу привести пример. Сразу после рождения в течение ~полугода ребёнок в состоянии различать звуки речи любого языка. Но через год, когда ребёнок создал категоризацию звуков своего родного языка, он теряет способность различать некоторые звуки, потому что они в его категоризации попадают в одну категорию.
Кто-то из психологов описывал забавный случай. Для демонстрации существования категоризации есть эксперимент, в котором компьютер воспроизводит слова rite, rite, rite, ... lite, lite, lite. Причём звук r от слова к слову звучит всё ближе к l, потом он звучит ближе к l, чем к r, потом он вообще не как r звучит, а как l. То есть это такой плавный процесс изменения rite в lite. Англоязычные слушатели не слышат плавности изменения, они слышат много rite, после которых внезапно начинается много lite. Так вот, и эта психологиня поехала в Японию, выступала перед японцами и в частности продемонстрировала эту технику. И вот она слушает, слышит: rite, rite, rite ..., rite, lite..., естественно она чувствует себя успешной женщиной, демонстрация эффекта удалась, смотрит в зал, а там напряжённые лица слушающих японцев, которые всё ждут того эффекта, который она описывает. Японцы (все говорящие на английском в достаточной мере, чтобы слушать американку с её докладом) так и не дождались, для них _все_ эти слова звучали одинаково, потому что для них r и l попадает в одну какую-то их японскую категорию звуков.
Так вот, представь себе младенца, который поспешил с категориями, не стал дожидатся когда он освоит родной язык в должной мере, и ввёл себе категории в первый месяц жизни, и по случайности это оказались японские категории. Представляешь себе, как много проблем у него будет с дальнейшим изучением языка? Готовый клиент логопеда. Возможно, это будут пожизненные проблемы различения r и l.
Поэтому не надо спешить со введением категорий. И уж тем более не нужно эти категории высасывать из пальца. С категориями мышления чуть проще -- их проще сломать, чем категории звуков речи, но с ними есть проблема: ты можешь не заметить необходимости ломать категории, потому что ты будешь видеть мир через призму этих категорий. Эти категории носят свойство "прозрачности": ты видишь мир через них, но ты не видишь их, ты не понимаешь как они влияют на ту картинку мира, которую ты видишь. Ты воспринимаешь эту картинку как точное отражение мира, даже если оно неточное. Чтобы заметить неточность, нужно а) целенаправленно искать; б) уметь искать такого рода неточности. Лучше не создавать себе этих проблем исходно.
> Я б порекомендовал тебе _сначала_ стать сеньёром-архитекторомА это куда ? Сорян что влезаю в ваши интимные разговоры.
> Вот и вы путаете такие абстракции, как оптимизация (логика приложения) и говнокод
> (синтаксис и тп).Ну, во-первых, ты путаешь оптимизацию и логику приложения. Логика логикой, оптимизации оптимизациями. Работы по кодированию логики и оптимизации проводятся на разных этапах разработки программы, хотя бы это должно намекать.
> Первое от языка не зависит, а второе у каждого языка своё.
Во-вторых, я ничего не путаю. Это ты слишком ригидно пытаешься делить мир на чёрное и белое. Оптимизации очень зависят от языка. И я даже могу объяснить. Такие характеристики кода как "говнокодность" и "оптимизированность" находятся в отношениях обратной корреляции. Чем более оптимизирован код, тем больший он говнокод: в нём сложнее разобраться, его сложнее менять, аудит провести невозможно, тестами его не покрыть, патчик слегка меняющий поведение в каком-нибудь corner-case, может будет патчиком, который поменяет 50% строк файла. В качестве простейшего примера: если ты развернул цикл, продублировав тело цикла 8 раз, то изменение цикла внесёт восемь одинаковых изменений, по одному в каждую копию тела.
Но разные вещи могут очень по-разному выглядеть в разных языках. То что совершенно нечитаемо в C, может быть, возможно оформить вменяемо на C++. Скажем, в Common Lisp'е можно запилить в код статическую типизацию и выделение памяти на стеке. Но в Common Lisp'е это приводит к распуханию кода, в этом коде всё меньше логики выполнения программы, и всё больше мелких технических деталей. В C же ты выделяешь память на стеке и даже не замечаешь этого. В C сложнее из кучи выделить, чем со стека. А уж статическая типизация в C просто обязательна.
Поэтому ты совершенно зря отделяешь оптимизацию от говнокода. Их нельзя рассматривать по-отдельности. Точнее можно, но лишь когда ты говоришь об асимптотической сложности алгоритмов, да и то с некоторыми оговорками.
И снова читаю не про оптимизацию кода, а про выбор оптимального языка под задачу.
> И снова читаю не про оптимизацию кода, а про выбор оптимального языка
> под задачу.Тут я уже ничем не могу помочь. Займись C++, стань специалистом, займись им профессионально, лет через пять поймёшь, о чём я.
> Займись C++, стань специалистом, займись им профессионально, лет через пять поймёшь, о чём я.Сколько раз мне нужно это сделать?
>> Займись C++, стань специалистом, займись им профессионально, лет через пять поймёшь, о чём я.
> Сколько раз мне нужно это сделать?42 раза. До просветления.
>Это ты слишком ригидно пытаешься делить мир на чёрное и белое. Оптимизации очень зависят от языка.Дайте сначала строгое определение понятию "оптимального", чтобы потом утверждать о зависимости от языка.
>>Это ты слишком ригидно пытаешься делить мир на чёрное и белое. Оптимизации очень зависят от языка.
> Дайте сначала строгое определение понятию "оптимального", чтобы потом утверждать о зависимости
> от языка.https://ru.wikipedia.org/wiki/%D0%9E%D0%...)
Помогло?
Но ты наверное имел в виду не "определение понятию оптимального", ты хотел чтобы я дал постановку оптимизационной задачи, так? Но постановка оптимизационной задачи -- это, по-хорошму, часть ТЗ на разработку конкретной программы. И даже если ТЗ пытается это сделать, и даже если вводятся формальные критерии для оценки оптимизационных параметров -- это всё равно очень проектноспецифичная вещь.
> Помогло?Ну и где там зависимость от ЯП?
Там ведь по ссылке написано какие требования ставятся, чтобы было "оптимально", то есть удовлетворяющий следующим требованиям:
1. Допустимое множество
2. Целевую функцию
3. Критерий поискаНо как мы видим эти три требования не определены строго их тоже еще необходимо определять.
> Но ты наверное имел в виду не "определение понятию оптимального", ты хотел
> чтобы я дал постановку оптимизационной задачи, так?"Оптимально" - это уже результат процесса оптимизации.
> Но постановка оптимизационной задачи
> -- это, по-хорошму, часть ТЗ на разработку конкретной программы. И даже
> если ТЗ пытается это сделать, и даже если вводятся формальные критерии
> для оценки оптимизационных параметров -- это всё равно очень проектноспецифичная вещь."проектноспецифичная вещь" - согласен, ну и где тут "Оптимизации очень зависят от языка."? поэтому и задал вам вопрос, чтобы вы дали определение понятию "оптимально" перед тем как утверждать об "очень зависит". Согласны?
пс: добавлю ссылочек и цитат, по теме
https://ru.wikipedia.org/wiki/%D0%9C%D0%...
"Отсюда, «оптимизировать» означает найти такое решение, при котором значение целевых функций были бы приемлемыми для постановщика задачи." - тут тоже не строгое определение процесса.
https://ru.wikipedia.org/wiki/%D0%9E%D0%...
"Оптимальное (от лат. optimus — наилучшее) решение — решение, которое по тем или иным признакам предпочтительнее других." - Такое вот общее не строгое понятие.
> "проектноспецифичная вещь" - согласен, ну и где тут "Оптимизации очень зависят от
> языка."? поэтому и задал вам вопрос, чтобы вы дали определение понятию
> "оптимально" перед тем как утверждать об "очень зависит". Согласны?
> пс: добавлю ссылочек и цитат, по темеНа фоне вышесказанного тобой, эти цитаты нерелеванты -- они не могут объяснить зависимость от языка, потому как они на том же уровне абстракции, где и моя ссылка выше.
Тебе одного примера с common-lisp'ом мало? Выше там был такой пример, ты видел его?
Хочешь я сравню printf из C и println! из rust'а? В rust'е println! разбирает форматную строку на этапе компиляции, чтобы потом в динамике при каждом вызове этого println! не парсить её заново. В C этого не происходит, как ты думаешь, почему?
Моя теория, что это из-за того, что в C нет ни макроязыка, ни константных функций, которые можно выполнять на этапе компиляции. Поэтому в C, чтобы получить разбор форматной строки на этапе компиляции, придётся писать специально заточенный препроцессор. Всем на это плевать, и поэтому если в C реально нужна скорость вывода, ты будешь в процессе оптимизации заменять printf'ы на вручную записанную последовательность вызовов типа:
print_string("Size is ");
print_int(x);
print_string("Mb\n");
...Это вряд ли понадобится, потому как printf это как правило к выводу, а ввод-вывод тормозит больше парсинга. Но всё же.
Или возьми async/await, и прикинь каково выбрать архитектуру программы с async вызовами лямбд, если твой язык -- это C. Для пользователя языка, в котором есть async/await использовать их -- это вполне себе опция доступная на этапе принятия решений об оптимальной архитектуре программы. Для пользователя C это конечно опция, но она будет сопряжена с таким количеством проблем, что лучше её опустить для ясности. Есть другие способы асинхронно выполнять код, плюс можно немного пожертвовать latency, и если быть осторожным и внимательным, то не получить залипаний программы на несколько секунд.
Тебе нужны ещё примеры, или трёх хватит?
А, давай приведу. Возьмём C и C++. В них значения можно передавать либо по указателю/ссылке, либо по значению. С точки зрения производительности, const ссылка -- самая удачная вещь: компилятор, оптимизируя, может полагаться на то, что значение по ссылке не менялось в вызываемой функции, и оптимизировать согласно этому. Но когда мы начинаем говорить о возвращении значений из функции, то тут встаёт вопрос: если я в функции создал объект, то как его вернуть? Есть два варианта -- выделить объект на куче, или вернуть по значению. Какой из них и когда лучше? Этот вопрос существует не в любом языке, во многих он нерелевантен вообще, потому что там, например, всё передаётся по ссылке, и поэтому там даже специального синтаксиса для ссылок нет, потому что когда всё -- ссылка, это не нужно.
> На фоне вышесказанного тобой, эти цитаты нерелеванты -- они не могут объяснить
> зависимость от языка, потому как они на том же уровне абстракции,
> где и моя ссылка выше.Зачем мне С или С++ если "оптимальности" ради я должен втыкать в асм (как вы советуете в комментах выше)?
На веру разве не принимаем, что компилятор сгенерит "оптимальный" код? Нету "сильной зависимости от языка", ибо требования "оптимальности" необходимо строго определить. Выбор ЯП тут относится больше к первому пункту, а может и вовсе не относиться.> Хочешь я сравню printf из C и println! из rust'а? В rust'е
> println! разбирает форматную строку на этапе компиляции, чтобы потом в динамике
> при каждом вызове этого println! не парсить её заново. В C
> этого не происходит, как ты думаешь, почему?И хочется спросить, что в роли "оптимального" критерия в этом случае используется? Опять бежим смотреть какой из компиляторов сгенерил оптимальный код для одного и того же алгоритма? Отсюда значить делаем вывод, что С "оптимальней" Раста, или на оборот? Если да, то тогда зачем нужны эти С и Расты, если можно по дефолту писать "оптимально" на асм?
> Моя теория, что это из-за того, что в C нет ни макроязыка,
> ни константных функций, которые можно выполнять на этапе компиляции. Поэтому в
> C, чтобы получить разбор форматной строки на этапе компиляции, придётся писать
> специально заточенный препроцессор. Всем на это плевать, и поэтому если в
> C реально нужна скорость вывода, ты будешь в процессе оптимизации заменять
> printf'ы на вручную записанную последовательность вызовов типа:
> print_string("Size is ");
> print_int(x);
> print_string("Mb\n");
> ...еще и буфферизацию вывода учтите )
> Это вряд ли понадобится, потому как printf это как правило к выводу,
> а ввод-вывод тормозит больше парсинга. Но всё же.
> Или возьми async/await, и прикинь каково выбрать архитектуру программы с async вызовами
> лямбд, если твой язык -- это C. Для пользователя языка, в
> котором есть async/await использовать их -- это вполне себе опция доступная
> на этапе принятия решений об оптимальной архитектуре программы.А не на С тот же async/await написан?
> Для пользователя C
> это конечно опция, но она будет сопряжена с таким количеством проблем,
> что лучше её опустить для ясности.Именно пользователя, если нет готового решения - нах не нужен.
> Есть другие способы асинхронно выполнять
> код, плюс можно немного пожертвовать latency, и если быть осторожным и
> внимательным, то не получить залипаний программы на несколько секунд.Асинхронность и залипания - мысль не ясна, уточните.
> Тебе нужны ещё примеры, или трёх хватит?
Желательно на асм, я не хочу "сильно зависеть" от ЯП уровнем выше.
> Какой из них и когда лучше?
Вот когда будут строгие критерии "оптимальности", тогда и получите ответ. При одних критериях будет один лучше, при других другой. Вы приводите примеры, но я не вижу критериев.
Я чёт не понимаю, чего ты хочешь добиться? Указать на то, что когда я говорю об "оптимизации программы" я неявно в это закладываю такие критерии как скорость работы, latency, может требования к памяти, но игнорирую такие критерии как читаемость и maintainability кода? Но это не я придумал, это кусочек коллективного сознательного такой, как он сформировался. Почему-то люди говоря об оптимизации имеют в виду именно рантайм характеристики программы, а не состояние сорцов.Или ты чего-то другого пытаешься достичь? Дело в том, что всё, написанное тобой, выглядит для меня как низкопошибная демагогия, причём, на мой взгляд, _слишком_ низкопошибная: ты можешь лучше. Это наводит на мысль, что я не понимаю того, что ты хочешь до меня донести. Может ты попробуешь ещё раз?
> Я чёт не понимаю, чего ты хочешь добиться?Опять нет строгости, добиться от кого, чего, в чем, с помощью чего и т.д. Неопределенность какая-то.
> Указать на то, что когда я говорю об "оптимизации программы" я неявно в это закладываю
> такие критерии как скорость работы, latency, может требования к памяти, но
> игнорирую такие критерии как читаемость и maintainability кода?Неявно? Где строгость? Что ждать от неявности - неопределенность?
> Но это не я придумал, это кусочек коллективного сознательного такой, как он сформировался.
Коллективная логика?
> Почему-то люди говоря об оптимизации имеют в виду именно рантайм характеристики программы, а не состояние сорцов.
А что есть рантайм, как не количество исполненных инструкций и занимаемый объем памяти. Разве не сводится ваша "оптимальность" к понятию сложности алгоритмов?
> Или ты чего-то другого пытаешься достичь? Дело в том, что всё, написанное
> тобой, выглядит для меня как низкопошибная демагогия, причём, на мой взгляд,
> _слишком_ низкопошибная: ты можешь лучше.Фильтруйте и проходите мимо.
> Это наводит на мысль, что я не понимаю того, что ты хочешь до меня донести.
Противоречите самому себе, предложением выше для вас все мной сказанное это "низкопошибная демагогия", а щас - "я не понимаю того, что ты хочешь до меня донести". Так вы понимаете, что это "низкопошибная демагогия", или нет?
> Может ты попробуешь ещё раз?
Как-нибудь в другой раз увы.
Ок. Тебе удалось убедить меня в том, что это низкопошибная демагогия, низкопошибность которой ты даже не в состоянии оценить.
Вы заблуждаетесь.Я видел крестовый код жутко не оптимальный, вся неоптимальность там была из за крестовых абстракций, которые скрыли от недальновидного автора тяжёлые блоки кода.
Как итог он ничего не подозревая в цыкле дёргал безобидную с виду функцию, которая внутри делала много всего, вместо того чтобы вынести её из цикла.Я бы сказал что это крестово специпично, потому что кресты любят за сахаром прятать тяжёлые вещи, и нужно с огромным недоверием относится к крестам и всё проверять чтобы не наступать на такие грабли хотя бы периодически.
Это специфично для любого ООП-кода, независимо от языка.
Только Data-Oriented Design, только Data Locality, только хардкор!
Согласен, принцип ООП - "не обращай внимания как оно там устроено, используй". И отсюда вытекают всякие статью про то, как стандартная библиотека гамно, а собственные аллокаторы тех же строк "оптимизировали" работу программы.
Математика нужна на уровне 7 класса. Нужно изучать Алгоримы и структуры данных.
Советую тебе выпить смузи, современный ты наш Анон.
Так современной или чтобы не вызывала отвращения?
Символьный С++: Введение в компьютерную алгебру с использованием ООП. Киат Ши Тан, Вилли-Ханс Стиб, Йорик Харди.
Надеюсь тебя стошнит.
Можно с C++20? Это единственное что меня интересует, образца плюсы 98 года не очень интересуют (03 уже пользовался).
Ютуб канал "cppProsto". Там по оптимизациям есть неплохие примеры.
Отвратительный совет. Автор пишет на древнем С++98 с редкими вкраплениями С++11, и не может даже скрипт для своих речей заранее заготовить.
для начала (это вообще как маст-хэв) там бОльшая часть про modern C++
Bjarne Stroustrup
A Tour of C++ (C++ In-Depth Series) 2nd Edition
https://www.amazon.com/Tour-2nd-Depth-Bjarne-Stroustrup/dp/0...
> Символьный С++: Введение в компьютерную алгебру с использованием ООП. Киат Ши Тан,
> Вилли-Ханс Стиб, Йорик Харди.
> Надеюсь тебя стошнит.2010 года книжка. Старовата. :(
>> Символьный С++: Введение в компьютерную алгебру с использованием ООП. Киат Ши Тан,
>> Вилли-Ханс Стиб, Йорик Харди.
>> Надеюсь тебя стошнит.
> 2010 года книжка. Старовата. :(2001 )))
>>> Символьный С++: Введение в компьютерную алгебру с использованием ООП. Киат Ши Тан,
>>> Вилли-Ханс Стиб, Йорик Харди.
>>> Надеюсь тебя стошнит.
>> 2010 года книжка. Старовата. :(
> 2001 )))На офсайте последняя версия кода 2010. Вообще чуваки прикольные, интересно, спасибо
Советую Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...
Хоть и не С++11/14, но книга актуальна.
Опечатался, имел ввиду "Хоть и не С++17/20, ..."
https://doc.rust-lang.org/book/
как выучить с++ за 21 день
http://teremock.com/tcpp21.png
(сорри за баян)
> использующие NPM - в среднем подобные проекты связываются с 683 зависимостямиВсё что нужно знать о JopaScript.
Т.е. вот это:> Самым популярным языком на GitHub остаётся JavaScript.
Надо бало писать вот так:
Самым идиотским языком остаётся JavaScript
Не удивительно когда эти руко.опые приходят в линукс то у них проблемы с зависимостями и ничего кроме флатошлаков они осилить не могут.
Думаю вряд ли это именно объявленные зависимости в package.json - тут бы даже я офигел. А вот если считали по содержимому node_modules - вполне верю. Можно поставить один пакет, который притянет только объявленных 50 зависимостей с собой. А каждая зависимость ещё по десятку своих может иметь.
Лишь благодаря яваскрипту нужны огромные мониторы или hidpi или мотор на колёсико мышки и мощные процессоры чтобы отрендерить три строчки. Как известно, только яваскрипт программист не понимает, что написано, если на экран влазит больше 3 строк.
> > использующие NPM - в среднем подобные проекты связываются с 683 зависимостями
> Всё что нужно знать о JopaScript.Это называется "реюзабельность кода": компетентный разработчик перед решением задачи смотрит, не решалась ли она раньше, и если да -- просто подключает готовое решение. Впрочем, откуда тебе это знать, ведь я говорю о компетентных разработчиках.
npm install is-even
Даже не посмотрев в это решение. вроде работает и пофиг, да :-(
Вот именно подключает и даже не удосуживается посмотреть, что там происходит. Отсюда и имеем is-even, is-odd и прочий шлак.
> 683 зависимостями683!!! Это уже не реюзабильность кода, это идитотизм. Но откуда тебе это знать, ведь слово продуманная архитектура тебе не знакома.
Это называется unix-way, каждая мелкая зависимость решает свою задачу.
Только фанаты оффтопика все запихивают в одно место.
Хорошо переиначил на свой лад
Никакого отношения к Unix-way это не имеет. Ты хоть одну книжку про Unix почитал?
Чтобы понять (хоть что-то в этой жизни)) насчет рейтинга Javascript, гляньте какие были примерные рейтинги до появления NodeJS:2008 2007 Lang Rat2008 Delta2007
1 1 Java 20.30% -0.24%
2 2 C 15.28% +1.31%
3 4 C++ 10.36% +1.61%
4 3 Basic 9.270% -0.96%
5 5 PHP 8.940% +0.25%
6 7 Python 5.140% +0.91%
7 8 C# 4.026% +0.11%
8 11 Delphi 4.006% +1.55%
9 6 Perl 3.876% -0.86%
10 10 JavaScript 2.925% 0.00%
11 9 Ruby 2.870% -0.21%
12 12 D 1.442% -0.26%
13 13 PL/SQL 0.939% -0.24%
14 14 SAS 0.729% -0.40%
15 18 ABAP 0.570% -0.08%
16 19 Pascal 0.511% -0.13%
17 17 COBOL 0.510% -0.20%
18 25 ActionScript 0.506% +0.04%
19 23 Logo 0.489% -0.04%
20 16 Lua 0.473% -0.27%
В 2008-м году довольно много вещей писали в native. Включая Qt, Java Swing. Да и php по инерции использовались для генерации веб-интерфейсов. Сейчас же концепции изменились. Настольные приложения почти никто не пишет. На любой чих - веб-приложение. И концепция фронтенда радикально изменилась. Теперь почти нет шаблонизаторов HTML, а есть фреймворки типа React, Angular, Vue.js и пр. То есть основная масса коммерческих заказов сконцентрировалась в технологиях, обслуживаемых JS и TS. Кроме того, JS 8-го года - это не JS6 и более поздние, которые стали похожи на приличный ЯП.
NodeJS здесь весьма опосредованная штука.
Без NodeJS (V8 которого исполняет "нативный" код системы)) не чихалось бы "веб-приложениями" типа современных Skype, WhatsApp, Code, Twish, Atom, Slack, Discord. Фреймворков "хороших и разных" и раньше было не мало - NodeJS опосредовал всех их, повлиял на создание экосистемы (npm) и бурное развитие JS как языка.
Там кучу зависимостей всякие сборщики, транспайлеры и прочий инструментарий тянут. Т.е. то, что у пользователя по факту не исполняется.
По факту слабая Runtime библиотека, а библиотеки все эти созданы для эффекта популярности. Миллионы мух и библиотек. По факту когда доделают все это в Runtime весь этот мусор из npm можно будет вычистить, но правда возникнет еще один сорт мусора промежуточные адаптеры одного дерьма в другое.
По факту - да, слабая. Нода для другого задумывалась, наверное мало кто ожидал, что на ней кучу инструментария построят, чтобы фронтэнд собирать. Остается только надеяться на унификацию и возникновение стандартов.
> По факту слабая Runtime библиотекаТак и про плюсы можно сказать, которые без буста никуда.
А так то вообще, статистику собрали, проанализировать не смогли. Анализ на уровне отписки студента 3-го курса. На троечку, абы сдать.
че за язык такой Shell ?
> че за язык такой Shell ?Баш наверно, я тут упоролся всё делать на баше. Наибольшее ограничение из встреченных, это то, что в строках нельзя хранить нулевой байт. Несколько ограничивает применимость, постоянно приходится питон брать только из-за этого. И как разделитель для строк его нельзя использовать, но тут хотя бы гнутые утилиты спасают хоть как-то.
Сегодня листал один из древних своих баш скриптов. Интересное ощущение. Некоторые конструкции довольно странные, некоторые мусорные, форматирование отсутствует. Смесь пробелов и табов, упс. Удивительно, что оно работает, местами даже продуманнее, чем я бы сделал сейчас. Только стиль отвратительный. Я тогда ещё сомневался, пихать ли мне башизм на башизме, или же думать о калеках.
Нахрена тебе "нулевой байт" в башскрипте? Ты точно выбрал правильный инструмент для своей задачи?
> Нахрена тебе "нулевой байт" в башскрипте? Ты точно выбрал правильный инструмент для
> своей задачи?Ну вот тебе надо прочитать 2 значения из файла, байт 10 там. И ладно бы если данные были записаны как 02 00, но нет же, они будут записаны как 00 02 (это то бишь тебе надо прочитать и поменять их местами). Чё-то уже ой, баш сам такого сделать не может никак, тебе придётся преобразовать байты в цифры и работать уже с ними, конвертируя их туда-сюда. В питоне ты просто берёшь и пишешь i = int.from_bytes(version,'big') и всё.
Разумеется не может, баш не для работы с бинарными данными, сколько бы байт они ни занимали. На баше решаются более высокоуровневые задачи.
Это очень высокоуровневая и абсолютно примитивная задача. Значит, цитирую (сократил немножко):f=open(file_name, "rb")
f.seek(6)
hash_length = int.from_bytes(f.read(4),'big')
f.seek(10)
info_hash = f.read(hash_length).hex().upper()И вот ради этого мне брать питон?
Разбор бинарного файла не звучит как высокоуровневая задача. Обычно это задача, находящаяся в самом нижнем уровне. Скажем, если в башскрипте понадобится выдернуть версию пакета из __текстового__ RPM-spec-файла, все равно предпочтительнее пользоваться уже готовыми решениями (rpmspec), чем городить самостоятельный (и обязательно ошибочный) разбор. Для твоего формата таких же инструментов не нашлось? Чтоб в баше ты высокоуровнево написал только это:INFO_HASH="$(инструмент --дай-мне-то-то ./вот-тебе-файл)"
Ну теперь я из баша дёргаю питон чтобы получить хеш чтобы потом скормить его сишной программе (которая сама не может догадаться извлечь этот хэш из своего же файла, угу). Питон в этой цепочке совершенно лишний.
file_name="./test";
hash_length=$((16#`dd if="$file_name" bs=1 skip=6 count=4 | xxd -ps -c 1000`));
hash_info=`dd if="$file_name" bs=1 skip=10 count=$hash_length | xxd -ps -c 1000`;echo $hash_length ${hash_info^^}
А если немного ПОДУМАТЬ, то можно обойтись то и без питона )) Это первая мысль которая мне пришла на ум.
Какая вторая? Я не помню, почему этот вариант не подошёл, что-то очень похожее у меня и было. Только потом возникли какие-то проблемы. Зачем нужен c и почему такой большой? Это ничего, что у меня в файле big endian, но моя архитектура при этом little endian?
>>Какая вторая?Вторая мысль: когда человек умеет программировать он сможет написать на любом яп что угодно..
>>Я не помню, почему этот вариант не подошёл, что-то очень похожее у меня и было. Только потом возникли какие-то проблемы.Вы писали что не смогли обойтись без питона, в ответ пример и написал выше, как это можно сделать без питона )) Вообще реализации одного и того же действия уйма )).
>>Зачем нужен c и почему такой большой?
по поводу -c, можно было почитать документацию, в том же --help написано что это размер колонок после чего будет разбито новой строкой =)
>>Это ничего, что у меня в файле big endian, но моя архитектура при этом little endian?
А как это с файлом то связано ? как захотите его форматировать так и форматируйте...
Я думал, будет вариант получше. Там просто написано, что захардкоженный максимум это 256, а не 1000+, да и дефолта в 32 вполне достаточно на самом деле. Можно и без питона, и я даже где-то использовал dd conv=swab,ucase под это дело, но это такая-то грязь. А, кроме того, swab ведь инвертирует только пары байтов, если мне надо инвертировать больше чем пары он этого уже не может. Кроме того, на нечётном числе будет баг. Вроде с этим я и столкнулся. Нет, всё-таки, для чтения файлов баш очень не подходит, максимум на что он способен это служить клеем и всё остальное изврат. Т.е. мне надо написать однострочник на си, который это сделает и вызывать уже его. Да даже если так, половина конструкций обломается из-за IFS и другая половина уже из-за IFS=. Я только недавно узнал (заново открыл?) о конструкции вида for file do и раньше с именами файлов мне было работать сложнее.>что угодно
Далеко не что угодно и совсем не как угодно. Проблема ещё и в том, что когда внешних вызовов много, эффективность скрипта снижается весьма значительно и ничего с этим не сделать. В итоге питон оказывается быстрее и эффективнее, поскольку он не спамит процессами. Ещё, например, у меня была задача исправить поломанную кодировку в именах файлов. Обычно, конечно, iconv, но не в с случае с cp932 и cp1252, когда юникод ломается. У питона, кстати, тоже были проблемы, но питон может и работать с любыми байтами без декодирования в локаль и я просто "исправил" их. Я думал свихнуть от жонглирования локалями и кодировками, и всё же нужно передавать так, чтобы баш его не трогал сам. Это было ужасно, питон намного приятней оказался. А ведь задача тоже совершенно элементарная -- поменять кодировку строки из поломанного юникода в корректный юникод. Я выяснил в процессе, что utf8 очень легко сломать и cp1252 вообще похоже не декодируется в utf8 (даже корректный) и только в utf16/utf32, а это дополнительные проблемы.
Особенно забавно писать на баше когда ты не знаешь решения задачи. Тебе сначала надо придумать как же это элементарное действие выполнить на баше, потом проанализировать результаты, потом переделать, и так по кругу. Всё это конечно с тысячами и тысячами бойлерплейта, каждый из которых будет содержать ошибку и если ты её нашёл ты уже занимаешься её отладкой. Нет, всё-таки баш это изврат, если бы данные могли быть любыми (в том числе содержащими 0) это избавило бы от многих проблем. Но, совместимость с доисторическими системами, ничего не поделать, и быстро это не изменить (вся надежда на gnu и благоразумие современных программистов).
Согласен, всё зависит от того что пишешь, многие вещи писать на питоне быстрее и удобнее чем на баше и на оборот, у каждого языка своя ниша.
Костыль на костыле. Вот он шел во всей красе.
Костыль на костыле - любой язык во всей красе ))
А кроме вашего распаренного бала Шклов не бывает?
Кроме распиареного баша других шеллов не бывает?
Существует ещё зш, он лучше конечно, но его придётся ставить отдельно и он не целиком совместим с башем, а это проблема. Хотя зшизмы конечно упрощают жизнь тоже.
И если его обвешать плагинами, он тормозит больше баша, и это ещё одна проблема.
И тсшелл и кшелл и сшелл. И просто Шелл.
Мало кто ими пользуется. Ну может, mksh ещё, на ведре. Но и то это очень нишево.А всякие eshell, rc, tcl маргинальны.
а джаву с джаваскриптом тоже путаешь?
А что не так с Ruby?
Он всё, как я понимаю он обрёл популярно в период, когда у питона были проблемы с юникодом. В основном из-за рельс, да? Лично у меня сотни рубей на диске только из-за раке, который нужен ровно одной программе. Ещё перл бы выкинул, зачем-то иксы на тысячи пакетов перла завязали несколько месяцев назад. Какие-то странные любители перловки проникли в редхат.
Ruby, как язык, конечно, комфортнее для разработки, чем питон. Но проблема в том, что у Ruby подход функциональный. Тупой императивный питон оказывается понятнее большинству начинающих "программистов". И даже не в том дело, что на Ruby нельзя физически так написать, а в том, что для того, чтобы получить максимум от языка, то есть его выразительность и лаконичность, писать надо именно в функциональном стиле.То есть, человек, который на Ruby может написать a = 1; b = a + 5, в питон-мире уже называется программистом. А в Ruby-мире, для "звания прогарммиста" надо хотя бы понимать, что значит фраза типа (1..10).reduce(1) { |acc, i| acc * i }.
чем комфортнее? Руби єто чисто маководовская тема, которая иногда прорастает метастазами в мир л.инупсов или винды.
Хорошая читаемость кода. Код, обычно, короче, чем у питона и не содержит всякий непонятный синтаксический мусор. Сложнее сделать ошибки, поскольку много статических валидаторов.В маках - это просто основной язык для пакетных менеджеров, включая brew и cocoa. Но, собственно, линуксы тоже не далеко ушли. SUSE/OpenSUSE без Ruby использовать не получится. У них всё администрирование на Ruby.
Ну и касаемо области применения Ruby, на маках - это какие-то единицы процентов от того, где он используется. Помним, что основная тема Ruby - это DSL для тестирования и администрирования. Явно не маков.
> (1..10).reduce(1) { |acc, i| acc * i }
> Хорошая читаемость кода
> не содержит всякий непонятный синтаксический мусорага
Аналог в питоновском исполнении будет нечитаем. Но большинство питонистов, вообще, не в состоянии функциональный стиль освоить.
Все адекватные люди эту микропогоньскую помойку давно покинули!
Это хорошо. Не выношу адекватных.
Куда?
На гитлаб, вестимо
> На гитлаб, вестимоGitee
Свой сервер + gitea.
> Куда?Gitee
Ну "Microsoft же опубликовал статистику за 2020 год"))
А статистика сколько аккаунтов слили спецслужбам написали?
А смысл сливать с гитхаба что-то спецслужбам, если и так всё видно?.... Кстати, в отличии от таковых из РФ, спецслужбы США совершенно не стесняются вешать объявления о найме по контекстой рекламе на основании поиска программистов. Там только одно требование - программист должен иметь гражданство США.
Та я вас умоляю, павликов морозовых даже не нанимают - выдаивают все что нужно еще до интервью, а если хочется повертеть - пусть идет в местный алькатрас за вызай, там уже все проще, бутылку кстати можно прихватить свою (это из плюсов).
> На 18% сократилось время рассмотрения запроса перед слиянием кода.Плохая тенденция однако... Разрабов меньше интересует что добавят в их проект? :(
Некогда думать, трясти надо !
Это из-за повсеместной замены master на slave.
Скорее наоборот. Вместо того, чтобы игнорить месяцами, начинают интересоваться входящими PR-ами.
Выводы:
- мы живём в кактусно-мышиное время
- нам нужно больше выходных дней
- в Африке 2%, а в России 0,2%
- TypeScript?
> Самым популярным языком на GitHub остаётся JavaScriptвсе понятно с целевой аудиторией
Да, эта аудитория решает реальные задачи и приносит пользу обществу.
Да, эта аудитория решает реальные задачи и приносит пользу обществу.
Кажется, опеннетовцы не в силах сделать защиту от даблклика
Интересно, а почему Shell есть а Golang нету. Неужели на нем больше проектов?
>Интересно, а почему Shell есть а Golang нету. Неужели на нем больше проектов.Интересно а почему ты веришь в статистику, которая даёт Майкрософт. Это статистика не ГитХаба а Майкрософта.
Там проблема с подсчетом скорее всего. В каждом проекте есть немного Shell файлов вроде automake.sh я думаю, что скорее всего считали суммарно все, а не по максимальному количеству кода. Потом тут сложно так как иногда в одной репе несколько проектов (монорепы) и там тоже есть Shell в корне выходит, что статистика врет.
Github - овно. Хотя бы из-за того, как там сделан поиск. Им видите ли сложно сделать точное совпадение.
Я правильно понимаю, что тебя это на столько задевает, что обязательно надо об этом написать? Мимо пройти никак?)) Ведь и тема статьи как раз сравнение статистики гитхаба и... ?
Любопытно. Топ больше напоминает список языков, от которых хотелось бы держаться подальше.
Вообще от программирования надо подальше держаться дерьмовое это дело ...
А других-то и нет.
что и требовалось доказать - ни gопошников ни растаманов в списке нет
Т.е. +20% лаб школьников и студентов, типа "завести аккаунт на гитхабе" -- это что-то доказывает?))Когда ты соберёшь статистику среди учёных, банков или производства -- картина будет сильно другой. Можешь погуглить)) Например: АЭС, самолётостроение -- внезапно Ада))
Второй момент: если в проекте требуется фронт, то нормальные люди делают вендоринг стороннего проекта на всякий случай (заметка про талантливого психа тут висит рядом). И эти файлы плюсуются ещё раз. Вот и получается, что какие-то языки явно не по заслугам вылазят на первые позиции.
Нужно быть мазохистом чтобы добровольно писать на Джабе
> Нужно быть мазохистом чтобы добровольно писать на ДжабеНу так предпосылка верная. Смелее заканчивайте свою мысль, уважаемый товарищ аноним.
Скоро весь мир будет состоять из программистов. И все будут на гитхабе. Даёшь семь миллиардов пользователей!)))
А он, уже что, закончился этот год? Я ещё свои наработки не закомитил.