The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"GitHub опубликовал статистику за 2020 год"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"GitHub опубликовал статистику за 2020 год"  +/
Сообщение от opennews (??), 02-Дек-20, 23:58 
GitHub  опубликовал отчёт с анализом статистики за 2020 год. Основные тенденции:...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=54186

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "GitHub опубликовал статистику за 2020 год"  +11 +/
Сообщение от Аноним (1), 02-Дек-20, 23:58 
как там со статистикой выпила неугодных реп?
Ответить | Правка | Наверх | Cообщить модератору

3. "GitHub опубликовал статистику за 2020 год"  +3 +/
Сообщение от Аноним (3), 03-Дек-20, 00:16 
> Аудитория GitHub возросла на 15 млн пользователей
> как там со статистикой выпила неугодных реп?

Никому не интересна.

Ответить | Правка | Наверх | Cообщить модератору

13. "GitHub опубликовал статистику за 2020 год"  +4 +/
Сообщение от _hide_ (ok), 03-Дек-20, 01:55 
>> Аудитория GitHub возросла на 15 млн пользователей
>> как там со статистикой выпила неугодных реп?
> Никому не интересна.

Ну мы то знаем, как сделать, чтобы какая-то информация была никому не интересна. Всегда было интересно, как Анонимы, путающие причину и следствие и транслирующие бред, смогли закончить школу?.. А точно, они её ещё не закончили

Ответить | Правка | Наверх | Cообщить модератору

25. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от б.б. (?), 03-Дек-20, 03:35 
> Ну мы то знаем, как сделать, чтобы какая-то информация была никому не интересна.

Да. Считать интересным что-то неинтересное.

Ответить | Правка | Наверх | Cообщить модератору

29. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от leibniz (ok), 03-Дек-20, 04:07 
Эта тема тактично опущена.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

83. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от dmca (?), 03-Дек-20, 12:50 
https://github.com/github/dmca
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (2), 03-Дек-20, 00:14 
Посоветуйте годной литературы по плюсам, чтобы не вызывала отвращения. Современной. Желательно, с картинками и best practices and gotchas, можно с интересным историческим экскурсом но желательно поближе к реальности. Немного устал от программерской литературы сорокалетней давности и касательно плюсов такая ничему хорошему не научит сегодня (т.е. Саттер конечно норм, но старьё).
Ответить | Правка | Наверх | Cообщить модератору

8. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от Аноним (8), 03-Дек-20, 00:56 
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
Ответить | Правка | Наверх | Cообщить модератору

10. "GitHub опубликовал статистику за 2020 год"  –3 +/
Сообщение от Аноним (2), 03-Дек-20, 01:15 
В принципе норм, пару поинтов к сведению принял. А что-нибудь практического и увлекательного? Желательно, с оптимизациями, писать неоптимальный код и я умею.
Ответить | Правка | Наверх | Cообщить модератору

17. "GitHub опубликовал статистику за 2020 год"  +6 +/
Сообщение от DeerFriend (?), 03-Дек-20, 02:52 
Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится, сколько к математике.
Ответить | Правка | Наверх | Cообщить модератору

18. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (2), 03-Дек-20, 03:01 
> Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится,
> сколько к математике.

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

Ответить | Правка | Наверх | Cообщить модератору

22. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от DeerFriend (?), 03-Дек-20, 03:14 
>> Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится, сколько к математике.
> У Саттера читал что-то такое по-моему, там было про решение плюсоспецифичных проблем.
> Да и сам язык довольно специфический, очень много возможностей случайно отстрелить
> голову.

Аа, ну это не про оптимизацию, а про говнокодинг?

Ответить | Правка | Наверх | Cообщить модератору

23. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (2), 03-Дек-20, 03:18 
Ну это чтобы было понимание как делать не нужно и к чему это приведёт и как всё таки можно если очень надо. Наверное всё же больше про оптимизацию, только чтобы компилятор с ума от UB не сходил.
Ответить | Правка | Наверх | Cообщить модератору

33. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от Ordu (ok), 03-Дек-20, 05:26 
> Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится, сколько к математике.

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

И когда мы берём всё это вместе и объединяем с языком типа C++, то это всё -- отдельное умение, на самом деле это и есть уровень квалификации в языке программировании. О таких вещах неплохо было бы и в отношении куда более простого C рассказывать -- типа как можно креативно использовать макросы, чтобы делать вещи, в которых без макросов утонешь в boilerplate, и поэтому если без макросов, то лучше везде вместо типизированных указателей использовать void* и хрен с ним с типизацией. В смысле ошибок будет меньше, несмотря на нетипизированные указатели, просто потому что меньше кода руками набирать придётся, и меньше тупых ошибок будет совершено. Или может стоит в каких-то случаях объявить функцию как static inline, передавать туда и возвращать оттуда килобайтовую структуру по значению? Или не стоит так делать, потому что тупой препод в ВУЗе за такое на пересдачу отправлял?

В языках типа C и C++ довольно много таких нюансов, которые хрен где прочитаешь. Только через опыт изучения чужого кода и разглядывание дизассемблерных дампов можно въехать. И в C++ такого больше, потому что там больше возможностей. Я лет двадцать назад, когда выкинул венду и влез в linux, быренько добрался до сорцов ядра, и шаблоны у меня тогда трещали по всем швам. Хрен с ним с goto, который considered harmful -- я привык к jmp в асме, и на goto смотрел без испуга. Но, как щаз помню, list.h мне просто вынес мозг. Я целый день разглядывал его, примеры его использования, разбираясь в том, как это работает. Хотя, казалось бы, чего там: циклический список с принудительной связью и заголовком. Но как завёрнуто -- я не думал, что на C можно писать так.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

42. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от DeerFriend (?), 03-Дек-20, 07:49 
Вот и вы путаете такие абстракции, как оптимизация (логика приложения) и говнокод (синтаксис и тп).
Первое от языка не зависит, а второе у каждого языка своё.
Ответить | Правка | Наверх | Cообщить модератору

43. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от DeerFriend (?), 03-Дек-20, 07:52 
Добавлю ещё.
Первое делит программистов на архитекторов и тыжпрограммистов.
Второе на джуниоров/миддлов/сеньёров.
Ответить | Правка | Наверх | Cообщить модератору

51. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Ordu (ok), 03-Дек-20, 08:59 
> Добавлю ещё.
> Первое делит программистов на архитекторов и тыжпрограммистов.
> Второе на джуниоров/миддлов/сеньёров.

Я б порекомендовал тебе _сначала_ стать сеньёром-архитектором, и только _потом_ придумывать классификации программистов.

Ответить | Правка | Наверх | Cообщить модератору

73. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от DeerFriend (?), 03-Дек-20, 11:08 
>> Добавлю ещё.
>> Первое делит программистов на архитекторов и тыжпрограммистов.
>> Второе на джуниоров/миддлов/сеньёров.
> Я б порекомендовал тебе _сначала_ стать сеньёром-архитектором, и только _потом_ придумывать
> классификации программистов.

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

Ответить | Правка | Наверх | Cообщить модератору

109. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 03-Дек-20, 20:44 
> Очевидно, что для успешной карьеры полезно прокачивать оба направления одновременно.

Нет. Дети в возрасте около года-двух становятся озабоченными созданием категорий и раскладыванием всех явлений объектов по категориям. С одной стороны это делает мышление более заострённым, но с другой стороны мешает и путается под ногами. Поэтому когда ты выходишь из того возраста активной категоризации мира, лучше притормозить и не категоризировать почём зря. Пока тебе какой-то набор категорий не нужен для профессиональной деятельности, лучше этих категорий не иметь, потому что если ты категории введёшь криво, то это изменит твоё восприятие и ты этого даже не заметишь.

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

Кто-то из психологов описывал забавный случай. Для демонстрации существования категоризации есть эксперимент, в котором компьютер воспроизводит слова 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.

Поэтому не надо спешить со введением категорий. И уж тем более не нужно эти категории высасывать из пальца. С категориями мышления чуть проще -- их проще сломать, чем категории звуков речи, но с ними есть проблема: ты можешь не заметить необходимости ломать категории, потому что ты будешь видеть мир через призму этих категорий. Эти категории носят свойство "прозрачности": ты видишь мир через них, но ты не видишь их, ты не понимаешь как они влияют на ту картинку мира, которую ты видишь. Ты воспринимаешь эту картинку как точное отражение мира, даже если оно неточное. Чтобы заметить неточность, нужно а) целенаправленно искать; б) уметь искать такого рода неточности. Лучше не создавать себе этих проблем исходно.

Ответить | Правка | Наверх | Cообщить модератору

88. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (-), 03-Дек-20, 13:20 
> Я б порекомендовал тебе _сначала_ стать сеньёром-архитектором

А это куда ? Сорян что влезаю в ваши интимные разговоры.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

50. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 03-Дек-20, 08:58 
> Вот и вы путаете такие абстракции, как оптимизация (логика приложения) и говнокод
> (синтаксис и тп).

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

> Первое от языка не зависит, а второе у каждого языка своё.

Во-вторых, я ничего не путаю. Это ты слишком ригидно пытаешься делить мир на чёрное и белое. Оптимизации очень зависят от языка. И я даже могу объяснить. Такие характеристики кода как "говнокодность" и "оптимизированность" находятся в отношениях обратной корреляции. Чем более оптимизирован код, тем больший он говнокод: в нём сложнее разобраться, его сложнее менять, аудит провести невозможно, тестами его не покрыть, патчик слегка меняющий поведение в каком-нибудь corner-case, может будет патчиком, который поменяет 50% строк файла. В качестве простейшего примера: если ты развернул цикл, продублировав тело цикла 8 раз, то изменение цикла внесёт восемь одинаковых изменений, по одному в каждую копию тела.

Но разные вещи могут очень по-разному выглядеть в разных языках. То что совершенно нечитаемо в C, может быть, возможно оформить вменяемо на C++. Скажем, в Common Lisp'е можно запилить в код статическую типизацию и выделение памяти на стеке. Но в Common Lisp'е это приводит к распуханию кода, в этом коде всё меньше логики выполнения программы, и всё больше мелких технических деталей. В C же ты выделяешь память на стеке и даже не замечаешь этого. В C сложнее из кучи выделить, чем со стека. А уж статическая типизация в C просто обязательна.

Поэтому ты совершенно зря отделяешь оптимизацию от говнокода. Их нельзя рассматривать по-отдельности. Точнее можно, но лишь когда ты говоришь об асимптотической сложности алгоритмов, да и то с некоторыми оговорками.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

74. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от DeerFriend (?), 03-Дек-20, 11:09 
И снова читаю не про оптимизацию кода, а про выбор оптимального языка под задачу.
Ответить | Правка | Наверх | Cообщить модератору

106. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 03-Дек-20, 20:20 
> И снова читаю не про оптимизацию кода, а про выбор оптимального языка
> под задачу.

Тут я уже ничем не могу помочь. Займись C++, стань специалистом, займись им профессионально, лет через пять поймёшь, о чём я.

Ответить | Правка | Наверх | Cообщить модератору

132. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от DeerFriend (?), 05-Дек-20, 15:56 
> Займись C++, стань специалистом, займись им профессионально, лет через пять поймёшь, о чём я.

Сколько раз мне нужно это сделать?

Ответить | Правка | Наверх | Cообщить модератору

133. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 05-Дек-20, 21:39 
>> Займись C++, стань специалистом, займись им профессионально, лет через пять поймёшь, о чём я.
> Сколько раз мне нужно это сделать?

42 раза. До просветления.

Ответить | Правка | Наверх | Cообщить модератору

99. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Sw00p aka Jerom (?), 03-Дек-20, 16:33 
>Это ты слишком ригидно пытаешься делить мир на чёрное и белое. Оптимизации очень зависят от языка.

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

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

105. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 03-Дек-20, 20:18 
>>Это ты слишком ригидно пытаешься делить мир на чёрное и белое. Оптимизации очень зависят от языка.
> Дайте сначала строгое определение понятию "оптимального", чтобы потом утверждать о зависимости
> от языка.

https://ru.wikipedia.org/wiki/%D0%9E%D0%...

Помогло?

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

Ответить | Правка | Наверх | Cообщить модератору

107. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Sw00p aka Jerom (?), 03-Дек-20, 20:40 
> Помогло?

Ну и где там зависимость от ЯП?

Там ведь по ссылке написано какие требования ставятся, чтобы было "оптимально", то есть удовлетворяющий следующим требованиям:

1. Допустимое множество
2. Целевую функцию
3. Критерий поиска

Но как мы видим эти три требования не определены строго их тоже еще необходимо определять.

> Но ты наверное имел в виду не "определение понятию оптимального", ты хотел
> чтобы я дал постановку оптимизационной задачи, так?

"Оптимально" - это уже результат процесса оптимизации.

> Но постановка оптимизационной задачи
> -- это, по-хорошму, часть ТЗ на разработку конкретной программы. И даже
> если ТЗ пытается это сделать, и даже если вводятся формальные критерии
> для оценки оптимизационных параметров -- это всё равно очень проектноспецифичная вещь.

"проектноспецифичная вещь" - согласен, ну и где тут "Оптимизации очень зависят от языка."? поэтому и задал вам вопрос, чтобы вы дали определение понятию "оптимально" перед тем как утверждать об "очень зависит". Согласны?

пс: добавлю ссылочек и цитат, по теме

https://ru.wikipedia.org/wiki/%D0%9C%D0%...

"Отсюда, «оптимизировать» означает найти такое решение, при котором значение целевых функций были бы приемлемыми для постановщика задачи." - тут тоже не строгое определение процесса.

https://ru.wikipedia.org/wiki/%D0%9E%D0%...

"Оптимальное (от лат. optimus — наилучшее) решение — решение, которое по тем или иным признакам предпочтительнее других." - Такое вот общее не строгое понятие.

Ответить | Правка | Наверх | Cообщить модератору

110. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 03-Дек-20, 21:04 
> "проектноспецифичная вещь" - согласен, ну и где тут "Оптимизации очень зависят от
> языка."? поэтому и задал вам вопрос, чтобы вы дали определение понятию
> "оптимально" перед тем как утверждать об "очень зависит". Согласны?
> пс: добавлю ссылочек и цитат, по теме

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

Тебе одного примера с 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 ссылка -- самая удачная вещь: компилятор, оптимизируя, может полагаться на то, что значение по ссылке не менялось в вызываемой функции, и оптимизировать согласно этому. Но когда мы начинаем говорить о возвращении значений из функции, то тут встаёт вопрос: если я в функции создал объект, то как его вернуть? Есть два варианта -- выделить объект на куче, или вернуть по значению. Какой из них и когда лучше? Этот вопрос существует не в любом языке, во многих он нерелевантен вообще, потому что там, например, всё передаётся по ссылке, и поэтому там даже специального синтаксиса для ссылок нет, потому что когда всё -- ссылка, это не нужно.

Ответить | Правка | Наверх | Cообщить модератору

114. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Sw00p aka Jerom (?), 04-Дек-20, 01:01 
> На фоне вышесказанного тобой, эти цитаты нерелеванты -- они не могут объяснить
> зависимость от языка, потому как они на том же уровне абстракции,
> где и моя ссылка выше.

Зачем мне С или С++ если "оптимальности" ради я должен втыкать в асм (как вы советуете в комментах выше)?
На веру разве не принимаем, что компилятор сгенерит "оптимальный" код? Нету "сильной зависимости от языка", ибо требования "оптимальности" необходимо строго определить. Выбор ЯП тут относится больше к первому пункту, а может и вовсе не относиться.

> Хочешь я сравню 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, и если быть осторожным и
> внимательным, то не получить залипаний программы на несколько секунд.

Асинхронность и залипания - мысль не ясна, уточните.

> Тебе нужны ещё примеры, или трёх хватит?

Желательно на асм, я не хочу "сильно зависеть" от ЯП уровнем выше.

> Какой из них и когда лучше?

Вот когда будут строгие критерии "оптимальности", тогда и получите ответ. При одних критериях будет один лучше, при других другой. Вы приводите примеры, но я не вижу критериев.

Ответить | Правка | Наверх | Cообщить модератору

115. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 04-Дек-20, 01:23 
Я чёт не понимаю, чего ты хочешь добиться? Указать на то, что когда я говорю об "оптимизации программы" я неявно в это закладываю такие критерии как скорость работы, latency, может требования к памяти, но игнорирую такие критерии как читаемость и maintainability кода? Но это не я придумал, это кусочек коллективного сознательного такой, как он сформировался. Почему-то люди говоря об оптимизации имеют в виду именно рантайм характеристики программы, а не состояние сорцов.

Или ты чего-то другого пытаешься достичь? Дело в том, что всё, написанное тобой, выглядит для меня как низкопошибная демагогия, причём, на мой взгляд, _слишком_ низкопошибная: ты можешь лучше. Это наводит на мысль, что я не понимаю того, что ты хочешь до меня донести. Может ты попробуешь ещё раз?

Ответить | Правка | Наверх | Cообщить модератору

116. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Sw00p aka Jerom (?), 04-Дек-20, 02:36 
> Я чёт не понимаю, чего ты хочешь добиться?

Опять нет строгости, добиться от кого, чего, в чем, с помощью чего и т.д. Неопределенность какая-то.

> Указать на то, что когда я говорю об "оптимизации программы" я неявно в это закладываю
> такие критерии как скорость работы, latency, может требования к памяти, но
> игнорирую такие критерии как читаемость и maintainability кода?

Неявно? Где строгость? Что ждать от неявности - неопределенность?

> Но это не я придумал, это кусочек коллективного сознательного такой, как он сформировался.

Коллективная логика?

> Почему-то люди говоря об оптимизации имеют в виду именно рантайм характеристики программы, а не состояние сорцов.

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

> Или ты чего-то другого пытаешься достичь? Дело в том, что всё, написанное
> тобой, выглядит для меня как низкопошибная демагогия, причём, на мой взгляд,
> _слишком_ низкопошибная: ты можешь лучше.

Фильтруйте и проходите мимо.

> Это наводит на мысль, что я не понимаю того, что ты хочешь до меня донести.

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

> Может ты попробуешь ещё раз?

Как-нибудь в другой раз увы.

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

117. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 04-Дек-20, 02:38 
Ок. Тебе удалось убедить меня в том, что это низкопошибная демагогия, низкопошибность которой ты даже не в состоянии оценить.
Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

76. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ivan_83 (ok), 03-Дек-20, 11:51 
Вы заблуждаетесь.

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

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

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

87. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (87), 03-Дек-20, 13:14 
Это специфично для любого ООП-кода, независимо от языка.
Только Data-Oriented Design, только Data Locality, только хардкор!
Ответить | Правка | Наверх | Cообщить модератору

100. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Sw00p aka Jerom (?), 03-Дек-20, 16:37 
Согласен, принцип ООП - "не обращай внимания как оно там устроено, используй". И отсюда вытекают всякие статью про то, как стандартная библиотека гамно, а собственные аллокаторы тех же строк "оптимизировали" работу программы.
Ответить | Правка | Наверх | Cообщить модератору

93. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (93), 03-Дек-20, 15:50 
Математика нужна на уровне 7 класса. Нужно изучать Алгоримы и структуры данных.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

34. "GitHub опубликовал статистику за 2020 год"  –3 +/
Сообщение от MasterSlave (?), 03-Дек-20, 06:23 
Советую тебе выпить смузи, современный ты наш Анон.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

39. "GitHub опубликовал статистику за 2020 год"  +4 +/
Сообщение от Аноним (39), 03-Дек-20, 06:55 
Так современной или чтобы не вызывала отвращения?
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

40. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Дегенератор (ok), 03-Дек-20, 07:23 
Символьный С++: Введение в компьютерную алгебру с использованием ООП. Киат Ши Тан, Вилли-Ханс Стиб, Йорик Харди.
Надеюсь тебя стошнит.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

46. "GitHub опубликовал статистику за 2020 год"  –2 +/
Сообщение от Аноним (2), 03-Дек-20, 08:17 
Можно с C++20? Это единственное что меня интересует, образца плюсы 98 года не очень интересуют (03 уже пользовался).
Ответить | Правка | Наверх | Cообщить модератору

49. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Дегенератор (ok), 03-Дек-20, 08:39 
Ютуб канал "cppProsto". Там по оптимизациям есть неплохие примеры.
Ответить | Правка | Наверх | Cообщить модератору

95. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Siborgium (ok), 03-Дек-20, 16:05 
Отвратительный совет. Автор пишет на древнем С++98 с редкими вкраплениями С++11, и не может даже скрипт для своих речей заранее заготовить.
Ответить | Правка | Наверх | Cообщить модератору

86. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от заминированный тапок (ok), 03-Дек-20, 13:06 
для начала (это вообще как маст-хэв) там бОльшая часть про 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...
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

118. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от lockywolf (ok), 04-Дек-20, 08:47 
> Символьный С++: Введение в компьютерную алгебру с использованием ООП. Киат Ши Тан,
> Вилли-Ханс Стиб, Йорик Харди.
> Надеюсь тебя стошнит.

2010 года книжка. Старовата. :(

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

119. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Дегенератор (ok), 04-Дек-20, 08:50 
>> Символьный С++: Введение в компьютерную алгебру с использованием ООП. Киат Ши Тан,
>> Вилли-Ханс Стиб, Йорик Харди.
>> Надеюсь тебя стошнит.
> 2010 года книжка. Старовата. :(

2001 )))

Ответить | Правка | Наверх | Cообщить модератору

120. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от lockywolf (ok), 04-Дек-20, 09:42 
>>> Символьный С++: Введение в компьютерную алгебру с использованием ООП. Киат Ши Тан,
>>> Вилли-Ханс Стиб, Йорик Харди.
>>> Надеюсь тебя стошнит.
>> 2010 года книжка. Старовата. :(
> 2001 )))

На офсайте последняя версия кода 2010. Вообще чуваки прикольные, интересно, спасибо

Ответить | Правка | Наверх | Cообщить модератору

58. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (58), 03-Дек-20, 09:27 
Советую Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14

https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...

Хоть и не С++11/14, но книга актуальна.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

59. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (58), 03-Дек-20, 09:29 
Опечатался, имел ввиду "Хоть и не С++17/20, ..."
Ответить | Правка | Наверх | Cообщить модератору

103. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Няшная Сишечка (?), 03-Дек-20, 19:46 
https://doc.rust-lang.org/book/
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

137. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от teremock (?), 07-Дек-20, 13:10 
как выучить с++ за 21 день
http://teremock.com/tcpp21.png
(сорри за баян)
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

4. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (4), 03-Дек-20, 00:21 
> использующие NPM - в среднем подобные проекты связываются с 683 зависимостями

Всё что нужно знать о JopaScript.
Т.е. вот это:

> Самым популярным языком на GitHub остаётся JavaScript.

Надо бало писать вот так:

Самым идиотским языком остаётся JavaScript

Ответить | Правка | Наверх | Cообщить модератору

5. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (4), 03-Дек-20, 00:24 
Не удивительно когда эти руко.опые приходят в линукс то у них проблемы с зависимостями и ничего кроме флатошлаков они осилить не могут.
Ответить | Правка | Наверх | Cообщить модератору

6. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от НяшМяш (ok), 03-Дек-20, 00:33 
Думаю вряд ли это именно объявленные зависимости в package.json - тут бы даже я офигел. А вот если считали по содержимому node_modules - вполне верю. Можно поставить один пакет, который притянет только объявленных 50 зависимостей с собой. А каждая зависимость ещё по десятку своих может иметь.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

7. "GitHub опубликовал статистику за 2020 год"  –4 +/
Сообщение от Аноним (-), 03-Дек-20, 00:49 
Лишь благодаря яваскрипту нужны огромные мониторы или hidpi или мотор на колёсико мышки и мощные процессоры чтобы отрендерить три строчки. Как известно, только яваскрипт программист не понимает, что написано, если на экран влазит больше 3 строк.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

24. "GitHub опубликовал статистику за 2020 год"  +4 +/
Сообщение от Аноним (24), 03-Дек-20, 03:21 
> > использующие NPM - в среднем подобные проекты связываются с 683 зависимостями
> Всё что нужно знать о JopaScript.

Это называется "реюзабельность кода": компетентный разработчик перед решением задачи смотрит, не решалась ли она раньше, и если да -- просто подключает готовое решение. Впрочем, откуда тебе это знать, ведь я говорю о компетентных разработчиках.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

32. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от LordTermor (ok), 03-Дек-20, 04:55 
npm install is-even
Ответить | Правка | Наверх | Cообщить модератору

36. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от псевдонимус (?), 03-Дек-20, 06:42 
Даже не посмотрев в это решение. вроде работает и пофиг, да :-(
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

81. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Дерьмократ (?), 03-Дек-20, 12:46 
Вот именно подключает и даже не удосуживается посмотреть, что там происходит. Отсюда и имеем is-even, is-odd и прочий шлак.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

128. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (128), 04-Дек-20, 19:32 
> 683 зависимостями

683!!! Это уже не реюзабильность кода, это идитотизм. Но откуда тебе это знать, ведь слово продуманная архитектура тебе не знакома.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

65. "GitHub опубликовал статистику за 2020 год"  –2 +/
Сообщение от Аноним (65), 03-Дек-20, 10:07 
Это называется unix-way, каждая мелкая зависимость решает свою задачу.
Только фанаты оффтопика все запихивают в одно место.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

82. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Дерьмократ (?), 03-Дек-20, 12:47 
Хорошо переиначил на свой лад
Ответить | Правка | Наверх | Cообщить модератору

129. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (128), 04-Дек-20, 19:33 
Никакого отношения к Unix-way это не имеет. Ты хоть одну книжку про Unix почитал?
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

75. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Чолхан (ok), 03-Дек-20, 11:14 
Чтобы понять (хоть что-то в этой жизни)) насчет рейтинга 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%

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

85. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (-), 03-Дек-20, 13:01 
В 2008-м году довольно много вещей писали в native. Включая Qt, Java Swing. Да и php по инерции использовались для генерации веб-интерфейсов. Сейчас же концепции изменились. Настольные приложения почти никто не пишет. На любой чих - веб-приложение. И концепция фронтенда радикально изменилась. Теперь почти нет шаблонизаторов HTML, а есть фреймворки типа React, Angular, Vue.js и пр. То есть основная масса коммерческих заказов сконцентрировалась в технологиях, обслуживаемых JS и TS. Кроме того, JS 8-го года - это не JS6 и более поздние, которые стали похожи на приличный ЯП.
NodeJS здесь весьма опосредованная штука.
Ответить | Правка | Наверх | Cообщить модератору

91. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Чолхан (ok), 03-Дек-20, 14:55 
Без NodeJS (V8 которого исполняет "нативный" код системы)) не чихалось бы "веб-приложениями" типа современных Skype, WhatsApp, Code, Twish, Atom, Slack, Discord. Фреймворков "хороших и разных" и раньше было не мало - NodeJS опосредовал всех их, повлиял на создание экосистемы (npm) и бурное развитие JS как языка.
Ответить | Правка | Наверх | Cообщить модератору

77. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от лолшто (?), 03-Дек-20, 11:58 
Там кучу зависимостей всякие сборщики, транспайлеры и прочий инструментарий тянут. Т.е. то, что у пользователя по факту не исполняется.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

96. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (96), 03-Дек-20, 16:07 
По факту слабая Runtime библиотека, а библиотеки все эти созданы для эффекта популярности. Миллионы мух и библиотек. По факту когда доделают все это в Runtime весь этот мусор из npm можно будет вычистить, но правда возникнет еще один сорт мусора промежуточные адаптеры одного дерьма в другое.
Ответить | Правка | Наверх | Cообщить модератору

101. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от лолшто (?), 03-Дек-20, 17:02 
По факту - да, слабая. Нода для другого задумывалась, наверное мало кто ожидал, что на ней кучу инструментария построят, чтобы фронтэнд собирать. Остается только надеяться на унификацию и возникновение стандартов.
Ответить | Правка | Наверх | Cообщить модератору

102. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (65), 03-Дек-20, 18:54 
> По факту слабая Runtime библиотека

Так и про плюсы можно сказать, которые без буста никуда.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

9. "GitHub опубликовал статистику за 2020 год"  +3 +/
Сообщение от Аноним (4), 03-Дек-20, 01:13 
А так то вообще, статистику собрали, проанализировать не смогли. Анализ на уровне отписки студента 3-го курса. На троечку, абы сдать.
Ответить | Правка | Наверх | Cообщить модератору

11. "GitHub опубликовал статистику за 2020 год"  –5 +/
Сообщение от Аноним (11), 03-Дек-20, 01:23 
че за язык такой Shell ?
Ответить | Правка | Наверх | Cообщить модератору

14. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (2), 03-Дек-20, 02:04 
> че за язык такой Shell ?

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

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

Ответить | Правка | Наверх | Cообщить модератору

20. "GitHub опубликовал статистику за 2020 год"  +4 +/
Сообщение от Аноним (24), 03-Дек-20, 03:05 
Нахрена тебе "нулевой байт" в башскрипте? Ты точно выбрал правильный инструмент для своей задачи?
Ответить | Правка | Наверх | Cообщить модератору

21. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (2), 03-Дек-20, 03:13 
> Нахрена тебе "нулевой байт" в башскрипте? Ты точно выбрал правильный инструмент для
> своей задачи?

Ну вот тебе надо прочитать 2 значения из файла, байт 10 там. И ладно бы если данные были записаны как 02 00, но нет же, они будут записаны как 00 02 (это то бишь тебе надо прочитать и поменять их местами). Чё-то уже ой, баш сам такого сделать не может никак, тебе придётся преобразовать байты в цифры и работать уже с ними, конвертируя их туда-сюда. В питоне ты просто берёшь и пишешь i = int.from_bytes(version,'big') и всё.

Ответить | Правка | Наверх | Cообщить модератору

26. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (24), 03-Дек-20, 03:43 
Разумеется не может, баш не для работы с бинарными данными, сколько бы байт они ни занимали. На баше решаются более высокоуровневые задачи.
Ответить | Правка | Наверх | Cообщить модератору

28. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (2), 03-Дек-20, 03:54 
Это очень высокоуровневая и абсолютно примитивная задача. Значит, цитирую (сократил немножко):

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()

И вот ради этого мне брать питон?

Ответить | Правка | Наверх | Cообщить модератору

30. "GitHub опубликовал статистику за 2020 год"  +5 +/
Сообщение от Аноним (24), 03-Дек-20, 04:12 
Разбор бинарного файла не звучит как высокоуровневая задача. Обычно это задача, находящаяся в самом нижнем уровне. Скажем, если в башскрипте понадобится выдернуть версию пакета из __текстового__ RPM-spec-файла, все равно предпочтительнее пользоваться уже готовыми решениями (rpmspec), чем городить самостоятельный (и обязательно ошибочный) разбор. Для твоего формата таких же инструментов не нашлось? Чтоб в баше ты высокоуровнево написал только это:

INFO_HASH="$(инструмент  --дай-мне-то-то  ./вот-тебе-файл)"

Ответить | Правка | Наверх | Cообщить модератору

31. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (2), 03-Дек-20, 04:34 
Ну теперь я из баша дёргаю питон чтобы получить хеш чтобы потом скормить его сишной программе (которая сама не может догадаться извлечь этот хэш из своего же файла, угу). Питон в этой цепочке совершенно лишний.
Ответить | Правка | Наверх | Cообщить модератору

35. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от svsd_val (ok), 03-Дек-20, 06:41 
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ообщить модератору

45. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (2), 03-Дек-20, 08:12 
Какая вторая? Я не помню, почему этот вариант не подошёл, что-то очень похожее у меня и было. Только потом возникли какие-то проблемы. Зачем нужен c и почему такой большой? Это ничего, что у меня в файле big endian, но моя архитектура при этом little endian?
Ответить | Правка | Наверх | Cообщить модератору

68. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от svsd_val (ok), 03-Дек-20, 10:38 
>>Какая вторая?

Вторая мысль: когда человек умеет программировать он сможет написать на любом яп что угодно..
>>Я не помню, почему этот вариант не подошёл, что-то очень похожее у меня и было. Только потом возникли какие-то проблемы.

Вы писали что не смогли обойтись без питона, в ответ пример и написал выше, как это можно сделать без питона )) Вообще реализации одного и того же действия уйма )).

>>Зачем нужен c и почему такой большой?

по поводу -c, можно было почитать документацию, в том же --help написано что это размер колонок после чего будет разбито новой строкой =)

>>Это ничего, что у меня в файле big endian, но моя архитектура при этом little endian?

А как это с файлом то связано ? как захотите его форматировать так и форматируйте...

Ответить | Правка | Наверх | Cообщить модератору

112. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (2), 03-Дек-20, 22:49 
Я думал, будет вариант получше. Там просто написано, что захардкоженный максимум это 256, а не 1000+, да и дефолта в 32 вполне достаточно на самом деле. Можно и без питона, и я даже где-то использовал dd conv=swab,ucase под это дело, но это такая-то грязь. А, кроме того, swab ведь инвертирует только пары байтов, если мне надо инвертировать больше чем пары он этого уже не может. Кроме того, на нечётном числе будет баг. Вроде с этим я и столкнулся. Нет, всё-таки, для чтения файлов баш очень не подходит, максимум на что он способен это служить клеем и всё остальное изврат. Т.е. мне надо написать однострочник на си, который это сделает и вызывать уже его. Да даже если так, половина конструкций обломается из-за IFS и другая половина уже из-за IFS=. Я только недавно узнал (заново открыл?) о конструкции вида for file do и раньше с именами файлов мне было работать сложнее.

>что угодно

Далеко не что угодно и совсем не как угодно. Проблема ещё и в том, что когда внешних вызовов много, эффективность скрипта снижается весьма значительно и ничего с этим не сделать. В итоге питон оказывается быстрее и эффективнее, поскольку он не спамит процессами. Ещё, например, у меня была задача исправить поломанную кодировку в именах файлов. Обычно, конечно, iconv, но не в с случае с cp932 и cp1252, когда юникод ломается. У питона, кстати, тоже были проблемы, но питон может и работать с любыми байтами без декодирования в локаль и я просто "исправил" их. Я думал свихнуть от жонглирования локалями и кодировками, и всё же нужно передавать так, чтобы баш его не трогал сам. Это было ужасно, питон намного приятней оказался. А ведь задача тоже совершенно элементарная -- поменять кодировку строки из поломанного юникода в корректный юникод. Я выяснил в процессе, что utf8 очень легко сломать и cp1252 вообще похоже не декодируется в utf8 (даже корректный) и только в utf16/utf32, а это дополнительные проблемы.

Ответить | Правка | Наверх | Cообщить модератору

113. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (2), 03-Дек-20, 22:58 
Особенно забавно писать на баше когда ты не знаешь решения задачи. Тебе сначала надо придумать как же это элементарное действие выполнить на баше, потом проанализировать результаты, потом переделать, и так по кругу. Всё это конечно с тысячами и тысячами бойлерплейта, каждый из которых будет содержать ошибку и если ты её нашёл ты уже занимаешься её отладкой. Нет, всё-таки баш это изврат, если бы данные могли быть любыми (в том числе содержащими 0) это избавило бы от многих проблем. Но, совместимость с доисторическими системами, ничего не поделать, и быстро это не изменить (вся надежда на gnu и благоразумие современных программистов).
Ответить | Правка | Наверх | Cообщить модератору

122. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от svsd_val (ok), 04-Дек-20, 11:39 
Согласен, всё зависит от того что пишешь, многие вещи писать на питоне быстрее и удобнее чем на баше и на оборот, у каждого языка своя ниша.
Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

62. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (62), 03-Дек-20, 09:59 
Костыль на костыле. Вот он шел во всей красе.
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

69. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от svsd_val (ok), 03-Дек-20, 10:40 
Костыль на костыле - любой язык во всей красе ))
Ответить | Правка | Наверх | Cообщить модератору

37. "GitHub опубликовал статистику за 2020 год"  –2 +/
Сообщение от псевдонимус (?), 03-Дек-20, 06:48 
А кроме вашего распаренного бала Шклов не бывает?
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

38. "GitHub опубликовал статистику за 2020 год"  –2 +/
Сообщение от псевдонимус (?), 03-Дек-20, 06:50 
Кроме распиареного баша других шеллов не бывает?
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

47. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (2), 03-Дек-20, 08:20 
Существует ещё зш, он лучше конечно, но его придётся ставить отдельно и он не целиком совместим с башем, а это проблема. Хотя зшизмы конечно упрощают жизнь тоже.
Ответить | Правка | Наверх | Cообщить модератору

48. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (2), 03-Дек-20, 08:21 
И если его обвешать плагинами, он тормозит больше баша, и это ещё одна проблема.
Ответить | Правка | Наверх | Cообщить модератору

61. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от псевдонимус (?), 03-Дек-20, 09:48 
И тсшелл и кшелл и сшелл. И просто Шелл.
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

54. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от lockywolf (ok), 03-Дек-20, 09:17 
Мало кто ими пользуется. Ну может, mksh ещё, на ведре. Но и то это очень нишево.

А всякие eshell, rc, tcl маргинальны.

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

71. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (71), 03-Дек-20, 10:52 
а джаву с джаваскриптом тоже путаешь?
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

12. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (12), 03-Дек-20, 01:25 
А что не так с Ruby?
Ответить | Правка | Наверх | Cообщить модератору

15. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от Аноним (2), 03-Дек-20, 02:24 
Он всё, как я понимаю он обрёл популярно в период, когда у питона были проблемы с юникодом. В основном из-за рельс, да? Лично у меня сотни рубей на диске только из-за раке, который нужен ровно одной программе. Ещё перл бы выкинул, зачем-то иксы на тысячи пакетов перла завязали несколько месяцев назад. Какие-то странные любители перловки проникли в редхат.
Ответить | Правка | Наверх | Cообщить модератору

63. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (63), 03-Дек-20, 10:00 
Ruby, как язык, конечно, комфортнее для разработки, чем питон. Но проблема в том, что у Ruby подход функциональный. Тупой императивный питон оказывается понятнее большинству начинающих "программистов". И даже не в том дело, что на Ruby нельзя физически так написать, а в том, что для того, чтобы получить максимум от языка, то есть его выразительность и лаконичность, писать надо именно в функциональном стиле.

То есть, человек, который на Ruby может написать a = 1; b = a + 5, в питон-мире уже называется программистом. А в Ruby-мире, для "звания прогарммиста" надо хотя бы понимать, что значит фраза типа (1..10).reduce(1) { |acc, i| acc * i }.

Ответить | Правка | Наверх | Cообщить модератору

67. "GitHub опубликовал статистику за 2020 год"  –3 +/
Сообщение от Аноним (67), 03-Дек-20, 10:35 
чем комфортнее? Руби єто чисто маководовская тема, которая иногда прорастает метастазами в мир л.инупсов или винды.
Ответить | Правка | Наверх | Cообщить модератору

84. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (-), 03-Дек-20, 12:56 
Хорошая читаемость кода. Код, обычно, короче, чем у питона и не содержит всякий непонятный синтаксический мусор. Сложнее сделать ошибки, поскольку много статических валидаторов.

В маках - это просто основной язык для пакетных менеджеров, включая brew и cocoa. Но, собственно, линуксы тоже не далеко ушли. SUSE/OpenSUSE без Ruby использовать не получится. У них всё администрирование на Ruby.

Ну и касаемо области применения Ruby, на маках - это какие-то единицы процентов от того, где он используется. Помним, что основная тема Ruby - это DSL для тестирования и администрирования. Явно не маков.

Ответить | Правка | Наверх | Cообщить модератору

123. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (123), 04-Дек-20, 14:24 
> (1..10).reduce(1) { |acc, i| acc * i }
> Хорошая читаемость кода
> не содержит всякий непонятный синтаксический мусор

ага

Ответить | Правка | Наверх | Cообщить модератору

131. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (131), 05-Дек-20, 11:40 
Аналог в питоновском исполнении будет нечитаем. Но большинство питонистов, вообще, не в состоянии функциональный стиль освоить.
Ответить | Правка | Наверх | Cообщить модератору

16. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от Гога (?), 03-Дек-20, 02:27 
Все адекватные люди эту микропогоньскую помойку давно покинули!
Ответить | Правка | Наверх | Cообщить модератору

19. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Ordu (ok), 03-Дек-20, 03:03 
Это хорошо. Не выношу адекватных.
Ответить | Правка | Наверх | Cообщить модератору

41. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (41), 03-Дек-20, 07:46 
Куда?
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

44. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от банан (?), 03-Дек-20, 07:59 
На гитлаб, вестимо
Ответить | Правка | Наверх | Cообщить модератору

55. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от lockywolf (ok), 03-Дек-20, 09:19 
> На гитлаб, вестимо

Gitee

Ответить | Правка | Наверх | Cообщить модератору

52. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (52), 03-Дек-20, 09:01 
Свой сервер + gitea.
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

56. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от lockywolf (ok), 03-Дек-20, 09:20 
> Куда?

Gitee

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

27. "GitHub опубликовал статистику за 2020 год"  +2 +/
Сообщение от user90 (?), 03-Дек-20, 03:51 
Ну "Microsoft же опубликовал статистику за 2020 год"))
Ответить | Правка | Наверх | Cообщить модератору

53. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (53), 03-Дек-20, 09:10 
А статистика сколько аккаунтов слили спецслужбам написали?
Ответить | Правка | Наверх | Cообщить модератору

64. "GitHub опубликовал статистику за 2020 год"  +3 +/
Сообщение от Аноним (63), 03-Дек-20, 10:04 
А смысл сливать с гитхаба что-то спецслужбам, если и так всё видно?.... Кстати, в отличии от таковых из РФ, спецслужбы США совершенно не стесняются вешать объявления о найме по контекстой рекламе на основании поиска программистов. Там только одно требование - программист должен иметь гражданство США.
Ответить | Правка | Наверх | Cообщить модератору

89. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (89), 03-Дек-20, 13:33 
Та я вас умоляю, павликов морозовых даже не нанимают - выдаивают все что нужно еще до интервью, а если хочется повертеть - пусть идет в местный алькатрас за вызай, там уже все проще, бутылку кстати можно прихватить свою (это из плюсов).
Ответить | Правка | Наверх | Cообщить модератору

57. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (57), 03-Дек-20, 09:20 
> На 18% сократилось время рассмотрения запроса перед слиянием кода.

Плохая тенденция однако... Разрабов меньше интересует что добавят в их проект? :(

Ответить | Правка | Наверх | Cообщить модератору

60. "GitHub опубликовал статистику за 2020 год"  +4 +/
Сообщение от Аноним (60), 03-Дек-20, 09:45 
Некогда думать, трясти надо !
Ответить | Правка | Наверх | Cообщить модератору

72. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от n00by (ok), 03-Дек-20, 10:56 
Это из-за повсеместной замены master на slave.
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

121. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от anonymous (??), 04-Дек-20, 11:00 
Скорее наоборот. Вместо того, чтобы игнорить месяцами, начинают интересоваться входящими PR-ами.
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

66. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (66), 03-Дек-20, 10:27 
Выводы:
- мы живём в кактусно-мышиное время
- нам нужно больше выходных дней
- в Африке 2%, а в России 0,2%
- TypeScript?
Ответить | Правка | Наверх | Cообщить модератору

78. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от nomad__email (ok), 03-Дек-20, 12:02 
> Самым популярным языком на GitHub остаётся JavaScript

все понятно с целевой аудиторией

Ответить | Правка | Наверх | Cообщить модератору

125. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Отражение луны (ok), 04-Дек-20, 18:33 
Да, эта аудитория решает реальные задачи и приносит пользу обществу.
Ответить | Правка | Наверх | Cообщить модератору

126. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Отражение луны (ok), 04-Дек-20, 18:33 
Да, эта аудитория решает реальные задачи и приносит пользу обществу.
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

127. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Отражение луны (ok), 04-Дек-20, 18:34 
Кажется, опеннетовцы не в силах сделать защиту от даблклика
Ответить | Правка | Наверх | Cообщить модератору

79. "GitHub опубликовал статистику за 2020 год"  +3 +/
Сообщение от COBA (?), 03-Дек-20, 12:13 
Интересно, а почему Shell есть а Golang нету. Неужели на нем больше проектов?
Ответить | Правка | Наверх | Cообщить модератору

94. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (-), 03-Дек-20, 15:55 
>Интересно, а почему Shell есть а Golang нету. Неужели на нем больше проектов.

Интересно а почему ты веришь в статистику, которая даёт Майкрософт. Это статистика не ГитХаба а Майкрософта.

Ответить | Правка | Наверх | Cообщить модератору

97. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (96), 03-Дек-20, 16:14 
Там проблема с подсчетом скорее всего. В каждом проекте есть немного Shell файлов вроде automake.sh я думаю, что скорее всего считали суммарно все, а не по максимальному количеству кода. Потом тут сложно так как иногда в одной репе несколько проектов (монорепы) и там тоже есть Shell в корне выходит, что статистика врет.
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

90. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Неа (?), 03-Дек-20, 14:04 
Github - овно. Хотя бы из-за того, как там сделан поиск. Им видите ли сложно сделать точное совпадение.
Ответить | Правка | Наверх | Cообщить модератору

134. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Брат Анон (ok), 07-Дек-20, 10:23 
Я правильно понимаю, что тебя это на столько задевает, что обязательно надо об этом написать? Мимо пройти никак?)) Ведь и тема статьи как раз сравнение статистики гитхаба и... ?
Ответить | Правка | Наверх | Cообщить модератору

92. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (92), 03-Дек-20, 15:16 
Любопытно. Топ больше напоминает список языков, от которых хотелось бы держаться подальше.
Ответить | Правка | Наверх | Cообщить модератору

98. "GitHub опубликовал статистику за 2020 год"  +3 +/
Сообщение от Аноним (96), 03-Дек-20, 16:14 
Вообще от программирования надо подальше держаться дерьмовое это дело ...
Ответить | Правка | Наверх | Cообщить модератору

124. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (123), 04-Дек-20, 14:27 
А других-то и нет.
Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

104. "GitHub опубликовал статистику за 2020 год"  –1 +/
Сообщение от Аноним (104), 03-Дек-20, 20:16 
что и требовалось доказать - ни gопошников ни растаманов в списке нет
Ответить | Правка | Наверх | Cообщить модератору

135. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Брат Анон (ok), 07-Дек-20, 10:26 
Т.е. +20% лаб школьников и студентов, типа "завести аккаунт на гитхабе" -- это что-то доказывает?))

Когда ты соберёшь статистику среди учёных, банков или производства -- картина будет сильно другой. Можешь погуглить)) Например: АЭС, самолётостроение -- внезапно Ада))

Второй момент: если в проекте требуется фронт, то нормальные люди делают вендоринг стороннего проекта на всякий случай (заметка про талантливого психа тут висит рядом). И эти файлы плюсуются ещё раз. Вот и получается, что какие-то языки явно не по заслугам вылазят на первые позиции.

Ответить | Правка | Наверх | Cообщить модератору

108. "GitHub опубликовал статистику за 2020 год"  +1 +/
Сообщение от Аноним (108), 03-Дек-20, 20:41 
Нужно быть мазохистом чтобы добровольно писать на Джабе
Ответить | Правка | Наверх | Cообщить модератору

136. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Брат Анон (ok), 07-Дек-20, 10:29 
> Нужно быть мазохистом чтобы добровольно писать на Джабе

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

Ответить | Правка | Наверх | Cообщить модератору

111. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (111), 03-Дек-20, 21:54 
Скоро весь мир будет состоять из программистов. И все будут на гитхабе. Даёшь семь миллиардов пользователей!)))
Ответить | Правка | Наверх | Cообщить модератору

130. "GitHub опубликовал статистику за 2020 год"  +/
Сообщение от Аноним (130), 04-Дек-20, 23:33 
А он, уже что, закончился этот год? Я ещё свои наработки не закомитил.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру