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

GitHub опубликовал статистику за 2020 год, opennews (??), 02-Дек-20, (0) [смотреть все] как там со статистикой выпила неугодных реп , Аноним (1), 23:58 , 02-Дек-20, (1) +11 // Никому не интересна , Аноним (3), 00:16 , 03-Дек-20, (3) +3 // Ну мы то знаем, как сделать, чтобы какая-то информация была никому не интересна , _hide_ (ok), 01:55 , 03-Дек-20, (13) +4 // Да Считать интересным что-то неинтересное , б.б. (?), 03:35 , 03-Дек-20, (25) Эта тема тактично опущена , leibniz (ok), 04:07 , 03-Дек-20, (29) +2 https github com github dmca, dmca (?), 12:50 , 03-Дек-20, (83) Посоветуйте годной литературы по плюсам, чтобы не вызывала отвращения Современн, Аноним (2), 00:14 , 03-Дек-20, (2)   // https isocpp github io CppCoreGuidelines CppCoreGuidelines, Аноним (8), 00:56 , 03-Дек-20, (8) +2   // В принципе норм, пару поинтов к сведению принял А что-нибудь практического и ув, Аноним (2), 01:15 , 03-Дек-20, (10) –3   // Для оптимизации нужно изучать алгоритмы, а это не столько к плюсам относится, ск, DeerFriend (?), 02:52 , 03-Дек-20, (17) +6   У Саттера читал что-то такое по-моему, там было про решение плюсоспецифичных про, Аноним (2), 03:01 , 03-Дек-20, (18) +1   Аа, ну это не про оптимизацию, а про говнокодинг , DeerFriend (?), 03:14 , 03-Дек-20, (22) +2   Ну это чтобы было понимание как делать не нужно и к чему это приведёт и как всё , Аноним (2), 03:18 , 03-Дек-20, (23) –1   Не совсем Алгоритмы алгоритмами, но программирование -- это не только умение вы, Ordu (ok), 05:26 , 03-Дек-20, (33) +2   Вот и вы путаете такие абстракции, как оптимизация логика приложения и говноко, DeerFriend (?), 07:49 , 03-Дек-20, (42)   Добавлю ещё Первое делит программистов на архитекторов и тыжпрограммистов Второе, DeerFriend (?), 07:52 , 03-Дек-20, (43)   Я б порекомендовал тебе _сначала_ стать сеньёром-архитектором, и только _потом_ , Ordu (ok), 08:59 , 03-Дек-20, (51) –1   Очевидно, что для успешной карьеры полезно прокачивать оба направления одновреме, DeerFriend (?), 11:08 , 03-Дек-20, (73)   Нет Дети в возрасте около года-двух становятся озабоченными созданием категорий, Ordu (ok), 20:44 , 03-Дек-20, (109)   А это куда Сорян что влезаю в ваши интимные разговоры , Аноним (-), 13:20 , 03-Дек-20, (88)   Ну, во-первых, ты путаешь оптимизацию и логику приложения Логика логикой, оптим, Ordu (ok), 08:58 , 03-Дек-20, (50)   И снова читаю не про оптимизацию кода, а про выбор оптимального языка под задачу, DeerFriend (?), 11:09 , 03-Дек-20, (74)   Тут я уже ничем не могу помочь Займись C , стань специалистом, займись им проф, Ordu (ok), 20:20 , 03-Дек-20, (106)   Сколько раз мне нужно это сделать , DeerFriend (?), 15:56 , 05-Дек-20, (132)   42 раза До просветления , Ordu (ok), 21:39 , 05-Дек-20, (133)   Дайте сначала строгое определение понятию оптимального , чтобы потом утверждать, Sw00p aka Jerom (?), 16:33 , 03-Дек-20, (99) +1   https ru wikipedia org wiki D0 9E D0 BF D1 82 D0 B8 D0 BC D0 B8 D0 B7 D0 B0 D, Ordu (ok), 20:18 , 03-Дек-20, (105)   Ну и где там зависимость от ЯП Там ведь по ссылке написано какие требования став, Sw00p aka Jerom (?), 20:40 , 03-Дек-20, (107)   На фоне вышесказанного тобой, эти цитаты нерелеванты -- они не могут объяснить з, Ordu (ok), 21:04 , 03-Дек-20, (110)   Зачем мне С или С если оптимальности ради я должен втыкать в асм как вы сов, Sw00p aka Jerom (?), 01:01 , 04-Дек-20, (114)   Я чёт не понимаю, чего ты хочешь добиться Указать на то, что когда я говорю об , Ordu (ok), 01:23 , 04-Дек-20, (115)   Опять нет строгости, добиться от кого, чего, в чем, с помощью чего и т д Неопре, Sw00p aka Jerom (?), 02:36 , 04-Дек-20, (116)   Ок Тебе удалось убедить меня в том, что это низкопошибная демагогия, низкопошиб, Ordu (ok), 02:38 , 04-Дек-20, (117)   Вы заблуждаетесь Я видел крестовый код жутко не оптимальный, вся неоптимальность, Ivan_83 (ok), 11:51 , 03-Дек-20, (76)   Это специфично для любого ООП-кода, независимо от языка Только Data-Oriented Des, Аноним (87), 13:14 , 03-Дек-20, (87) +1   Согласен, принцип ООП - не обращай внимания как оно там устроено, используй И, Sw00p aka Jerom (?), 16:37 , 03-Дек-20, (100)   Математика нужна на уровне 7 класса Нужно изучать Алгоримы и структуры данных , Аноним (93), 15:50 , 03-Дек-20, (93)   Советую тебе выпить смузи, современный ты наш Анон , MasterSlave (?), 06:23 , 03-Дек-20, (34) –3   Так современной или чтобы не вызывала отвращения , Аноним (39), 06:55 , 03-Дек-20, (39) +4   Символьный С Введение в компьютерную алгебру с использованием ООП Киат Ши Та, Дегенератор (ok), 07:23 , 03-Дек-20, (40)   // Можно с C 20 Это единственное что меня интересует, образца плюсы 98 года не оч, Аноним (2), 08:17 , 03-Дек-20, (46) –2   // Ютуб канал cppProsto Там по оптимизациям есть неплохие примеры , Дегенератор (ok), 08:39 , 03-Дек-20, (49) –1   Отвратительный совет Автор пишет на древнем С 98 с редкими вкраплениями С 11,, Siborgium (ok), 16:05 , 03-Дек-20, (95)   для начала это вообще как маст-хэв там бОльшая часть про modern C Bjarne Stro, заминированный тапок (ok), 13:06 , 03-Дек-20, (86) –1   2010 года книжка Старовата , lockywolf (ok), 08:47 , 04-Дек-20, (118)   // 2001 , Дегенератор (ok), 08:50 , 04-Дек-20, (119)   На офсайте последняя версия кода 2010 Вообще чуваки прикольные, интересно, спас, lockywolf (ok), 09:42 , 04-Дек-20, (120)   Советую Effective Modern C 42 Specific Ways to Improve Your Use of C 11 and , Аноним (58), 09:27 , 03-Дек-20, (58) –1   // Опечатался, имел ввиду Хоть и не С 17 20, , Аноним (58), 09:29 , 03-Дек-20, (59) –1   https doc rust-lang org book , Няшная Сишечка (?), 19:46 , 03-Дек-20, (103) –1   как выучить с за 21 деньhttp teremock com tcpp21 png сорри за баян , teremock (?), 13:10 , 07-Дек-20, (137)   Всё что нужно знать о JopaScript Т е вот это Надо бало писать вот так Самым иди, Аноним (4), 00:21 , 03-Дек-20, (4) –1 // Не удивительно когда эти руко опые приходят в линукс то у них проблемы с зависим, Аноним (4), 00:24 , 03-Дек-20, (5) Думаю вряд ли это именно объявленные зависимости в package json - тут бы даже я , НяшМяш (ok), 00:33 , 03-Дек-20, (6) +2 Лишь благодаря яваскрипту нужны огромные мониторы или hidpi или мотор на колёсик, Аноним (-), 00:49 , 03-Дек-20, (7) –4 Это называется реюзабельность кода компетентный разработчик перед решением за, Аноним (24), 03:21 , 03-Дек-20, (24) +4 // npm install is-even, LordTermor (ok), 04:55 , 03-Дек-20, (32) +1 Даже не посмотрев в это решение вроде работает и пофиг, да - , псевдонимус (?), 06:42 , 03-Дек-20, (36) +2 Вот именно подключает и даже не удосуживается посмотреть, что там происходит От, Дерьмократ (?), 12:46 , 03-Дек-20, (81) 683 Это уже не реюзабильность кода, это идитотизм Но откуда тебе это знать, , Аноним (128), 19:32 , 04-Дек-20, (128) +1 Это называется unix-way, каждая мелкая зависимость решает свою задачу Только фа, Аноним (65), 10:07 , 03-Дек-20, (65) –2 // Хорошо переиначил на свой лад, Дерьмократ (?), 12:47 , 03-Дек-20, (82) Никакого отношения к Unix-way это не имеет Ты хоть одну книжку про Unix почитал, Аноним (128), 19:33 , 04-Дек-20, (129) Чтобы понять хоть что-то в этой жизни насчет рейтинга Javascript, гляньте как, Чолхан (ok), 11:14 , 03-Дек-20, (75) // В 2008-м году довольно много вещей писали в native Включая Qt, Java Swing Да и, Аноним (-), 13:01 , 03-Дек-20, (85) // Без NodeJS V8 которого исполняет нативный код системы не чихалось бы веб-п, Чолхан (ok), 14:55 , 03-Дек-20, (91) Там кучу зависимостей всякие сборщики, транспайлеры и прочий инструментарий тяну, лолшто (?), 11:58 , 03-Дек-20, (77) +1 // По факту слабая Runtime библиотека, а библиотеки все эти созданы для эффекта поп, Аноним (96), 16:07 , 03-Дек-20, (96) –1 // По факту - да, слабая Нода для другого задумывалась, наверное мало кто ожидал, , лолшто (?), 17:02 , 03-Дек-20, (101) Так и про плюсы можно сказать, которые без буста никуда , Аноним (65), 18:54 , 03-Дек-20, (102) А так то вообще, статистику собрали, проанализировать не смогли Анализ на уровн, Аноним (4), 01:13 , 03-Дек-20, (9) +3 че за язык такой Shell , Аноним (11), 01:23 , 03-Дек-20, (11) –5 // Баш наверно, я тут упоролся всё делать на баше Наибольшее ограничение из встреч, Аноним (2), 02:04 , 03-Дек-20, (14) –1 // Нахрена тебе нулевой байт в башскрипте Ты точно выбрал правильный инструмент , Аноним (24), 03:05 , 03-Дек-20, (20) +4 // Ну вот тебе надо прочитать 2 значения из файла, байт 10 там И ладно бы если дан, Аноним (2), 03:13 , 03-Дек-20, (21) –1 Разумеется не может, баш не для работы с бинарными данными, сколько бы байт они , Аноним (24), 03:43 , 03-Дек-20, (26) +1 Это очень высокоуровневая и абсолютно примитивная задача Значит, цитирую сокра, Аноним (2), 03:54 , 03-Дек-20, (28) Разбор бинарного файла не звучит как высокоуровневая задача Обычно это задача, , Аноним (24), 04:12 , 03-Дек-20, (30) +5 Ну теперь я из баша дёргаю питон чтобы получить хеш чтобы потом скормить его сиш, Аноним (2), 04:34 , 03-Дек-20, (31) file_name test hash_length 16 dd if file_name bs 1 skip 6 count 4 , svsd_val (ok), 06:41 , 03-Дек-20, (35) Какая вторая Я не помню, почему этот вариант не подошёл, что-то очень похожее у, Аноним (2), 08:12 , 03-Дек-20, (45) –1 Вторая мысль когда человек умеет программировать он сможет написать на любом яп, svsd_val (ok), 10:38 , 03-Дек-20, (68) +1 Я думал, будет вариант получше Там просто написано, что захардкоженный максимум, Аноним (2), 22:49 , 03-Дек-20, (112) Особенно забавно писать на баше когда ты не знаешь решения задачи Тебе сначала , Аноним (2), 22:58 , 03-Дек-20, (113) Согласен, всё зависит от того что пишешь, многие вещи писать на питоне быстрее и, svsd_val (ok), 11:39 , 04-Дек-20, (122) +1 Костыль на костыле Вот он шел во всей красе , Аноним (62), 09:59 , 03-Дек-20, (62) Костыль на костыле - любой язык во всей красе , svsd_val (ok), 10:40 , 03-Дек-20, (69) А кроме вашего распаренного бала Шклов не бывает , псевдонимус (?), 06:48 , 03-Дек-20, (37) –2 Кроме распиареного баша других шеллов не бывает , псевдонимус (?), 06:50 , 03-Дек-20, (38) –2 // Существует ещё зш, он лучше конечно, но его придётся ставить отдельно и он не це, Аноним (2), 08:20 , 03-Дек-20, (47) И если его обвешать плагинами, он тормозит больше баша, и это ещё одна проблема , Аноним (2), 08:21 , 03-Дек-20, (48) И тсшелл и кшелл и сшелл И просто Шелл , псевдонимус (?), 09:48 , 03-Дек-20, (61) +1 Мало кто ими пользуется Ну может, mksh ещё, на ведре Но и то это очень нишево , lockywolf (ok), 09:17 , 03-Дек-20, (54) а джаву с джаваскриптом тоже путаешь , Аноним (71), 10:52 , 03-Дек-20, (71) +1 А что не так с Ruby , Аноним (12), 01:25 , 03-Дек-20, (12) // Он всё, как я понимаю он обрёл популярно в период, когда у питона были проблемы , Аноним (2), 02:24 , 03-Дек-20, (15) +2 // Ruby, как язык, конечно, комфортнее для разработки, чем питон Но проблема в том, Аноним (63), 10:00 , 03-Дек-20, (63) –1 // чем комфортнее Руби 1108 то чисто маководовская тема, которая иногда прораста, Аноним (67), 10:35 , 03-Дек-20, (67) –3 Хорошая читаемость кода Код, обычно, короче, чем у питона и не содержит всякий , Аноним (-), 12:56 , 03-Дек-20, (84) –1 ага, Аноним (123), 14:24 , 04-Дек-20, (123) +1 Аналог в питоновском исполнении будет нечитаем Но большинство питонистов, вообщ, Аноним (131), 11:40 , 05-Дек-20, (131) –1 Все адекватные люди эту микропогоньскую помойку давно покинули , Гога (?), 02:27 , 03-Дек-20, (16) +2 // Это хорошо Не выношу адекватных , Ordu (ok), 03:03 , 03-Дек-20, (19) Куда , Аноним (41), 07:46 , 03-Дек-20, (41) +1 // На гитлаб, вестимо, банан (?), 07:59 , 03-Дек-20, (44) // Gitee, lockywolf (ok), 09:19 , 03-Дек-20, (55) Свой сервер gitea , Аноним (52), 09:01 , 03-Дек-20, (52) Gitee, lockywolf (ok), 09:20 , 03-Дек-20, (56) Ну Microsoft же опубликовал статистику за 2020 год , user90 (?), 03:51 , 03-Дек-20, (27) +2 А статистика сколько аккаунтов слили спецслужбам написали , Аноним (53), 09:10 , 03-Дек-20, (53) // А смысл сливать с гитхаба что-то спецслужбам, если и так всё видно Кстати, , Аноним (63), 10:04 , 03-Дек-20, (64) +3 // Та я вас умоляю, павликов морозовых даже не нанимают - выдаивают все что нужно е, Аноним (89), 13:33 , 03-Дек-20, (89) Плохая тенденция однако Разрабов меньше интересует что добавят в их проект , Аноним (57), 09:20 , 03-Дек-20, (57) // Некогда думать, трясти надо , Аноним (60), 09:45 , 03-Дек-20, (60) +4 Это из-за повсеместной замены master на slave , n00by (ok), 10:56 , 03-Дек-20, (72) +1 Скорее наоборот Вместо того, чтобы игнорить месяцами, начинают интересоваться в, anonymous (??), 11:00 , 04-Дек-20, (121) Выводы - мы живём в кактусно-мышиное время- нам нужно больше выходных дней- в Аф, Аноним (66), 10:27 , 03-Дек-20, (66) –1 все понятно с целевой аудиторией, nomad__ (ok), 12:02 , 03-Дек-20, (78) // Да, эта аудитория решает реальные задачи и приносит пользу обществу , Отражение луны (ok), 18:33 , 04-Дек-20, (125) Да, эта аудитория решает реальные задачи и приносит пользу обществу , Отражение луны (ok), 18:33 , 04-Дек-20, (126) // Кажется, опеннетовцы не в силах сделать защиту от даблклика, Отражение луны (ok), 18:34 , 04-Дек-20, (127) +1 Интересно, а почему Shell есть а Golang нету Неужели на нем больше проектов , COBA (?), 12:13 , 03-Дек-20, (79) +3 // Интересно а почему ты веришь в статистику, которая даёт Майкрософт Это статисти, Аноним (-), 15:55 , 03-Дек-20, (94) +1 Там проблема с подсчетом скорее всего В каждом проекте есть немного Shell файло, Аноним (96), 16:14 , 03-Дек-20, (97) +1 Github - овно Хотя бы из-за того, как там сделан поиск Им видите ли сложно сде, Неа (?), 14:04 , 03-Дек-20, (90) –1 // Я правильно понимаю, что тебя это на столько задевает, что обязательно надо об э, Брат Анон (ok), 10:23 , 07-Дек-20, (134) Любопытно Топ больше напоминает список языков, от которых хотелось бы держаться, Аноним (92), 15:16 , 03-Дек-20, (92) // Вообще от программирования надо подальше держаться дерьмовое это дело , Аноним (96), 16:14 , 03-Дек-20, (98) +3 А других-то и нет , Аноним (123), 14:27 , 04-Дек-20, (124) что и требовалось доказать - ни gопошников ни растаманов в списке нет, Аноним (104), 20:16 , 03-Дек-20, (104) –1 // Т е 20 лаб школьников и студентов, типа завести аккаунт на гитхабе -- это ч, Брат Анон (ok), 10:26 , 07-Дек-20, (135) Нужно быть мазохистом чтобы добровольно писать на Джабе, Аноним (108), 20:41 , 03-Дек-20, (108) +1 // Ну так предпосылка верная Смелее заканчивайте свою мысль, уважаемый товарищ ано, Брат Анон (ok), 10:29 , 07-Дек-20, (136) Скоро весь мир будет состоять из программистов И все будут на гитхабе Даёшь се, Аноним (111), 21:54 , 03-Дек-20, (111) А он, уже что, закончился этот год Я ещё свои наработки не закомитил , Аноним (130), 23:33 , 04-Дек-20, (130) 1,2,4,9,11,12,16,27,53,57,66,78,79,90,92,104,108,111,130

Сообщения

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

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ообщить модератору

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

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