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

"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__ (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 | Индекс форумов | Темы | Пред. тема | След. тема