От темы и правда ушли, тут GC, ниже GUI, но вы попали в больное место, не могу молчать.
Rust, Машина Тьюринга и Brainfuck — те вещи, знакомство с которыми я считаю необходимыми для современного образованного программиста. Rust, чтобы увидеть, как бывает всё не так и это здорово. Машина Тьюринга вместе с задачей останова просто для понимания пределов программирования. Меня поражает как мало людей не понимают, что нельзя в общем случае написать программу, которая идеально проинспектирует другую программу. А Brainfuck для демонстрации абсолютно чистого программирования, кода самого в себе. Его простота и полнота завораживает и заставляет относиться к компьютеру по-другому.
И всё это не важно в каком порядке и когда. Rust разве что только после становления хотя бы как начинающего программиста. Чтобы видеть контраст, нужно видеть фон.
Вы мне предлагаете поспорить о вкусах. Я знаком с проблемами и сложностями проектирования GUI, не интересно. Не знаю будет ли это хорошим примером, но интересна ли вам проблема числа 10958? Или доказательства/опровержения существования и единственности решения системы уравнений Навье-Стокса? И в то, и в другое я закапывался и мне это нравится, но я не ожидаю, что понравится всем, даже если потратят столько же времени. Фломастеры разные, пусть все занимаются своим делом. У меня интерфейсы вызывают непреодолимую тоску и вовсе не из-за простоты или рутины.
Про C++ не спорю, это мой основной рабочий инструмент для прода в нише совершенно противоположенной вашей — разработка серверных библиотек. По совершенно объективным причинам я не лезу туда с D. А вот инструментарий для себя и других я пишу на D, и все это устраивает, потому что быстро пишется и быстро работает.
Острой необходимости в замене C++ нет, иначе бы она уже была, но это не значит, что нужно останавливаться на нём.
все эффективные оптимизации аллокации уже реализованы в malloc.
Все эффективные оптимизации на общий случай реализованы в malloc. Всегда есть частный случай, который может быть быстрее. Тот же malloc не располагает кучей данных, которые есть у GC — априорное знание о размерах объектов, например.
ну вы будете его использовать только там, где без него совсем никак — в случаях раздельного владения объектом между потоками
И RC нужен не только для многопоточности. Растовский rc::Rc наоборот не атомарен и должен использоваться только в одном потоке. Общее владение ресурсом так или иначе приводит к счётчику ссылок, сборке мусора или ошибкам и утечкам. Выбирайте. Здорово, когда можно не выбирать и использовать только одиночное эксклюзивное владение, но это же не всегда возможно даже в Rust.
Вы считаете, что C++ лучше в качестве первого языка? Или я не правильно понял про места, где учат C++? Я считаю что D гораздо лучше в качестве первого, возможно даже лучший из мне известных.
Это на ваш взгляд, а для меня нет хуже задачи, чем GUI. Занимался им на Qt и на Flash. Я верю, что вам и многим другим нравится, но на нём свет клином не сошёлся.
Про опенсорс согласен, хотелось бы больше. Не хватает какой-то библиотеки, которая подняла бы D своей популярностью. Я надеялся, что vibe.d станет ею, но разочаровался — удобно, но не быстро, не хватает какой-то изюминки.
Ручное управление памятью в D есть, и это отвечает на оба ваших вопроса. Ничего не мешает вообще использовать только C подмножество, будет всё то же самое, но удобнее за счёт фич этапа компиляции.
А к докладу Антона Полухина, который вы скинули, я бы хотел добавить, что любое управление памятью имеет накладные расходы. malloc требует дополнительного места под размер, имеет избыточное потребление для маленьких объектах на многих реализациях, и вообще не быстр, иначе не появились бы альтернативы и ручные аллокаторы. Любое выделение памяти не бесплатно, любой контроль за используемой памятью, GC, счётчик ссылок или дерево владения из Qt, вносит накладные расходы. Тот же Rust при всеобъемлющем контроле за временем жизни всё равно предлагает счётчик ссылок для динамики. А есть ситуации, когда RC медленнее, чем GC.
Поэтому важны настоящие zero cost абстракции, которые позволят вообще не выделять память, коих в D хватает. Например ленивые диапазоны (моя статья на хабре). После выхода C++20 выглядит банально, вот только как Ranges туда попали? Eric Niebler напрямую ссылался на D в объяснениях. И я считаю такие вещи важнее, чем встроенный в язык GC.
Существенная доля ответов есть в статье, но постараюсь ответить подробнее.
Лично мне D просто нравится. Я продуктивнее пишу на D, чем на C++, Perl или JS, и похоже это не только субъективное восприятие, а свойство языка. Почему именно на этой кафедре решили преподавать именно этот язык, история сложная и для меня до сих пор целиком не известная.
Я понимаю, что GC делает язык похожим на другие языки со сборщиком мусора, но это иллюзия. В D гораздо больше из мира C++ и Rust, чем из C# или Java. Банально сравните производительность, граммотный D на голову обходит любые VM языки или тот же Go. В задачах, когда из процессора действительно нужно выжать всё, D не уступает и часто лидирует в сравнении с C и Rust. И это очень важно понять, что удобство не всегда достаётся ценой производительности.
В вузе надо учиться программировать и изучать концепции, а не практиковаться в чём-то одном. Вуз не должен выпускать программистов на Go, он должен выпускать образованных людей. После D вы сможете относительно просто перейти и на C++, и на C# и на Go, а вот обратное не верно. Этот язык богат на подходы, при этом прост в изучении основ. Кроме того кругозор позволяет видеть абстракции, а не конкретные синтаксические конструкции. На примере D хорошо объяснять программирование контрактное, функциональное, многопоточное, метапрограммирование. Как вы сможете донести саму идею zero cost (бесплатных) абстракций на примере Java, где их фактически не существует? А ведь это важная идея, которую продвигает тот же Rust.
И да, если бы я оценивал свой уровень владения Rust достаточным, то я бы предложил преподавать его. Имхо, в нём одна интересная мысль, но она действительно стоит того. Вот только я знаю D, а не Rust. Ну и кстати, в D тоже появляется анализ времени жизни и зарождается borrow checker. И если они доведут его до кондиции, решив все проблемы удобства и совместимости, то лет через 6 мы увидим его в C++, поверьте.
Спасибо за отзыв, приятно слышать.
Чат в дискорде был, в нём же собирались на «лекции». В нём можно удобно писать и личные вопросы и общие в групповой. Так себе работало, как всегда только для самых активных.
Прямо как на хабре)
Ручки и мёрч от компании это интересно. Видимо ваш работодатель возлагает какие-то надежды на выпускников? К себе работать зовёте?
Я планировал и всё ещё хочу так делать, но пока не получается. В этом году знакомство с группой началось с вопроса от них, можно ли на стажировку, так что может быть удача наконец-то улыбнётся.
Нет. После экзамена с ними не общался. Очной связи с ними нет, других предметов я не веду, но есть групповая почта. Они сейчас должны были закончить бакалавратуру, то есть фактически выпустились, но попробую. Ну и ближе к концу года можно подобное закинуть группе прошлого года. Действительно было бы интересно узнать результаты и отношение спустя два года.
Я на рабочую программу и не жаловался, документ понятный, нужный, пусть и объёмный. Это как раз очень порадовало, что программа — фактически единственная "бумажка".
Про посещаемость да, но всё же оставлять всё на самодисциплину неправильно. Не всем хватает мотивации, и если правильно "помочь" организоваться, то результаты будут лучше. Не поделитесь опытом, за что поднимаете и понижаете карму? Работает как элемент геймификации или наоборот школьного журнала?
Ну а истории про то, как просят кому-то что-то поставить и у меня появились. Я боялся, что их будет даже больше, но пока всё в рамках разумного. Родители к счастью ещё ни разу не звонили.
Вас, возможно, интересует, почему ваша статья заминусована? Я кнопки голосования не трогал, но позволю себе высказать гипотезу.
Формулировка задачи выглядит очень странно. Что такого особенного в передаче файлов по сети? Почему без сторонних библиотек? Зачем шифровать? Почему не взять более традиционные алгоритмы?
Ну и технический уровень реализации тоже не высок. Простите за сравнение, но у меня студенты третьего курса не самого профильного факультета на сокетах посложнее вещи делают. Не говоря уже про то, что они делают с библиотеками.
Это вовсе не означает, что вы не можете написать о своём опыте на хабр, но нужно трезвее оценивать уровень и соответственно менять фокус с того, что вы сделали на то, почему. Может быть, вы учитесь программировать и хотите поделиться своей историей? Или делаете сложную техническую систему, где программирование лишь неважная деталь? При нужном ракурсе вы сможете получить тут поддержку и советы, а не минусы.
Да, но 0..100 читается лучше. iota хороша для функциональных цепочек с map, filter, chunk и тд, и ещё для шага отличного от 1, он там третьим аргументом передаётся.
Имхо, это недоработка в языке, что 0..100 это только для foreach. Было бы лучше, если можно было бы в любом месте использовать для обозначения диапазонов. Вместо этого… переиспользовали для срезов и значение там совсем другое.
Выше уже упоминали D, а если вспомнить, что все эти ranges в C++ попали оттуда (именно в виде шаблонных конструкций этапа компиляции), то и for надо смотреть там же.
foreach (i; 0..100) {}
В C++ это переносится примерно так же, как у вас в статье
for (auto i : iota(100)) {}
Я считаю, что синтаксический сахар в виде range-based for вместе с хорошей библиотекой ranges (ranges-v3, которая фактически в стандарте C++20), и есть идеальный for.
Ну и стоит упомянуть, что функциональщина в виде map, filter или cartesianProduct часто лучше читается. Можете посмотреть на ndslice и увидеть, как хорошо решается задача многомерного прохода на тех же абстракциях.
Это гораздо лучше чем перевод очередной графомании зарубежного автора, новости про телеграмм, потому что это АйТи и многого другого на хабра.
Космос не зауряден, тем более, что сейчас кое-что меняется и движется в этой сфере. Такие новости про запуски создают хороший и правдоподобный фон происходящего.
Вот это выкидывание на рынок мне, да и не только мне, тоже не нравится. А точнее разработка под такой рынок. Но боюсь, это примерно того же порядка, что и «мне не нравится вода, потому что она сырая». Это же не заговор злых менеджеров по продажам, это объективные рыночные условия, так что приходится расслабляться и получать удовольствие.
А вот должен ли разработчик сам следить за памятью — это уже интересный технический вопрос. Тот же rust отлично показывает, что даже под жёстким контролем и гарантиями языка, человек не может точно управлять временем жизни объектов. Иначе там бы не появился счётчик ссылок. То есть есть ситуации, когда время жизни не очевидно и зависит от разных условий. И тогда это становится выбором между счётчиком и сборщиком. И оба не идеальны. Так что я бы не называл это ошибкой, скорее рекомендацией обойтись без автоматического управления, когда хватает ручного. В терминах C++ это использование uniq_ptr вместо shared_ptr, в D — @nogc, в C# struct, где это возможно.
Особенно ярко проблема заметна не на памяти, а файловых дескрипторах и прочих ресурсах, которые сборщик не трогает. Они должны управляться предельно просто и детерменировано. Но там и циклических ссылок нет.
Спору нет, hard realtime это точно не про GC. Но согласитесь, это очень маленькая ниша и там себя неплохо чувствует C. Там есть средства и время на разработку.
А вот с тем, что GC из D может приводить к требованию 256 ядер процессора для простой игры, я не соглашусь. Люди пишут говнокод независимо от языка и фреймвёрка. Если бы не было js или C# с Unity, в такой же среде даже на чистом C написали бы то же самое, такое же медленное, но дороже. Более того, я уверен, что при равных трудозатратах код на C будет медленнее кода на D и, возможно, C#. C быстр тогда, когда на него тратят силы, а когда тяп-ляп и в прод, будет ад.
И нет, это не разработчики обленились и не хотят «включать мозг». Это запрос рынка на тяп-ляп, js, electron… ой, у нас анимация мигания курсора проц съела. Если качество кода не ценится, то язык не поможет. Административные проблемы техническими средствами не решаются.
Я писал на D физический симулятор реального времени для применения в играх. В нём не понадобилось отключать или как-либо особо задумываться над GC, всё просто работало. Предыдущая версия на C++ содержала свои коллекции и аллокаторы, была заметно сложнее в этом аспекте, но работала медленнее. Удобство написания кода позволяет больше времени уделять алгоритмам.
Это я к тому, что GC удобен, а ситуаций, где с ним надо что-то делать не так много. Обычный программист на C++ не пишет свои аллокаторы (разве что использует готовые простые решения), так же и обычно на D не надо вспоминать про особенности сборки мусора.
Весь цикл статей как раз про то, что не надо бояться GC, потому что вам его хватит, а если нет, то даже за его пределами есть жизнь.
Я рассматривал все сочетания лесенок высотой 3 и 4, их не много, можно разбить на классы и все рассмотреть на бумаге. Сейчас точно не воспроизведу, доказательство не сохранял, уже уверен, что в нём есть дыры, раз уж никто до сих пор полноценно задачу не решил.
Rust, Машина Тьюринга и Brainfuck — те вещи, знакомство с которыми я считаю необходимыми для современного образованного программиста. Rust, чтобы увидеть, как бывает всё не так и это здорово. Машина Тьюринга вместе с задачей останова просто для понимания пределов программирования. Меня поражает как мало людей не понимают, что нельзя в общем случае написать программу, которая идеально проинспектирует другую программу. А Brainfuck для демонстрации абсолютно чистого программирования, кода самого в себе. Его простота и полнота завораживает и заставляет относиться к компьютеру по-другому.
И всё это не важно в каком порядке и когда. Rust разве что только после становления хотя бы как начинающего программиста. Чтобы видеть контраст, нужно видеть фон.
Про C++ не спорю, это мой основной рабочий инструмент для прода в нише совершенно противоположенной вашей — разработка серверных библиотек. По совершенно объективным причинам я не лезу туда с D. А вот инструментарий для себя и других я пишу на D, и все это устраивает, потому что быстро пишется и быстро работает.
Острой необходимости в замене C++ нет, иначе бы она уже была, но это не значит, что нужно останавливаться на нём.
И RC нужен не только для многопоточности. Растовский rc::Rc наоборот не атомарен и должен использоваться только в одном потоке. Общее владение ресурсом так или иначе приводит к счётчику ссылок, сборке мусора или ошибкам и утечкам. Выбирайте. Здорово, когда можно не выбирать и использовать только одиночное эксклюзивное владение, но это же не всегда возможно даже в Rust.
Про опенсорс согласен, хотелось бы больше. Не хватает какой-то библиотеки, которая подняла бы D своей популярностью. Я надеялся, что vibe.d станет ею, но разочаровался — удобно, но не быстро, не хватает какой-то изюминки.
А к докладу Антона Полухина, который вы скинули, я бы хотел добавить, что любое управление памятью имеет накладные расходы. malloc требует дополнительного места под размер, имеет избыточное потребление для маленьких объектах на многих реализациях, и вообще не быстр, иначе не появились бы альтернативы и ручные аллокаторы. Любое выделение памяти не бесплатно, любой контроль за используемой памятью, GC, счётчик ссылок или дерево владения из Qt, вносит накладные расходы. Тот же Rust при всеобъемлющем контроле за временем жизни всё равно предлагает счётчик ссылок для динамики. А есть ситуации, когда RC медленнее, чем GC.
Поэтому важны настоящие zero cost абстракции, которые позволят вообще не выделять память, коих в D хватает. Например ленивые диапазоны (моя статья на хабре). После выхода C++20 выглядит банально, вот только как Ranges туда попали? Eric Niebler напрямую ссылался на D в объяснениях. И я считаю такие вещи важнее, чем встроенный в язык GC.
Лично мне D просто нравится. Я продуктивнее пишу на D, чем на C++, Perl или JS, и похоже это не только субъективное восприятие, а свойство языка. Почему именно на этой кафедре решили преподавать именно этот язык, история сложная и для меня до сих пор целиком не известная.
Я понимаю, что GC делает язык похожим на другие языки со сборщиком мусора, но это иллюзия. В D гораздо больше из мира C++ и Rust, чем из C# или Java. Банально сравните производительность, граммотный D на голову обходит любые VM языки или тот же Go. В задачах, когда из процессора действительно нужно выжать всё, D не уступает и часто лидирует в сравнении с C и Rust. И это очень важно понять, что удобство не всегда достаётся ценой производительности.
В вузе надо учиться программировать и изучать концепции, а не практиковаться в чём-то одном. Вуз не должен выпускать программистов на Go, он должен выпускать образованных людей. После D вы сможете относительно просто перейти и на C++, и на C# и на Go, а вот обратное не верно. Этот язык богат на подходы, при этом прост в изучении основ. Кроме того кругозор позволяет видеть абстракции, а не конкретные синтаксические конструкции. На примере D хорошо объяснять программирование контрактное, функциональное, многопоточное, метапрограммирование. Как вы сможете донести саму идею zero cost (бесплатных) абстракций на примере Java, где их фактически не существует? А ведь это важная идея, которую продвигает тот же Rust.
И да, если бы я оценивал свой уровень владения Rust достаточным, то я бы предложил преподавать его. Имхо, в нём одна интересная мысль, но она действительно стоит того. Вот только я знаю D, а не Rust. Ну и кстати, в D тоже появляется анализ времени жизни и зарождается borrow checker. И если они доведут его до кондиции, решив все проблемы удобства и совместимости, то лет через 6 мы увидим его в C++, поверьте.
Чат в дискорде был, в нём же собирались на «лекции». В нём можно удобно писать и личные вопросы и общие в групповой. Так себе работало, как всегда только для самых активных.
Ручки и мёрч от компании это интересно. Видимо ваш работодатель возлагает какие-то надежды на выпускников? К себе работать зовёте?
Я планировал и всё ещё хочу так делать, но пока не получается. В этом году знакомство с группой началось с вопроса от них, можно ли на стажировку, так что может быть удача наконец-то улыбнётся.
Нет. После экзамена с ними не общался. Очной связи с ними нет, других предметов я не веду, но есть групповая почта. Они сейчас должны были закончить бакалавратуру, то есть фактически выпустились, но попробую. Ну и ближе к концу года можно подобное закинуть группе прошлого года. Действительно было бы интересно узнать результаты и отношение спустя два года.
Я на рабочую программу и не жаловался, документ понятный, нужный, пусть и объёмный. Это как раз очень порадовало, что программа — фактически единственная "бумажка".
Про посещаемость да, но всё же оставлять всё на самодисциплину неправильно. Не всем хватает мотивации, и если правильно "помочь" организоваться, то результаты будут лучше. Не поделитесь опытом, за что поднимаете и понижаете карму? Работает как элемент геймификации или наоборот школьного журнала?
Ну а истории про то, как просят кому-то что-то поставить и у меня появились. Я боялся, что их будет даже больше, но пока всё в рамках разумного. Родители к счастью ещё ни разу не звонили.
Вас, возможно, интересует, почему ваша статья заминусована? Я кнопки голосования не трогал, но позволю себе высказать гипотезу.
Формулировка задачи выглядит очень странно. Что такого особенного в передаче файлов по сети? Почему без сторонних библиотек? Зачем шифровать? Почему не взять более традиционные алгоритмы?
Ну и технический уровень реализации тоже не высок. Простите за сравнение, но у меня студенты третьего курса не самого профильного факультета на сокетах посложнее вещи делают. Не говоря уже про то, что они делают с библиотеками.
Это вовсе не означает, что вы не можете написать о своём опыте на хабр, но нужно трезвее оценивать уровень и соответственно менять фокус с того, что вы сделали на то, почему. Может быть, вы учитесь программировать и хотите поделиться своей историей? Или делаете сложную техническую систему, где программирование лишь неважная деталь? При нужном ракурсе вы сможете получить тут поддержку и советы, а не минусы.
Да, но 0..100 читается лучше. iota хороша для функциональных цепочек с map, filter, chunk и тд, и ещё для шага отличного от 1, он там третьим аргументом передаётся.
Имхо, это недоработка в языке, что 0..100 это только для foreach. Было бы лучше, если можно было бы в любом месте использовать для обозначения диапазонов. Вместо этого… переиспользовали для срезов и значение там совсем другое.
Выше уже упоминали D, а если вспомнить, что все эти ranges в C++ попали оттуда (именно в виде шаблонных конструкций этапа компиляции), то и for надо смотреть там же.
В C++ это переносится примерно так же, как у вас в статье
Я считаю, что синтаксический сахар в виде range-based for вместе с хорошей библиотекой ranges (ranges-v3, которая фактически в стандарте C++20), и есть идеальный for.
Ну и стоит упомянуть, что функциональщина в виде map, filter или cartesianProduct часто лучше читается. Можете посмотреть на ndslice и увидеть, как хорошо решается задача многомерного прохода на тех же абстракциях.
В данном случае дело не только в jpeg, но суть вы поняли
Космос не зауряден, тем более, что сейчас кое-что меняется и движется в этой сфере. Такие новости про запуски создают хороший и правдоподобный фон происходящего.
А вот должен ли разработчик сам следить за памятью — это уже интересный технический вопрос. Тот же rust отлично показывает, что даже под жёстким контролем и гарантиями языка, человек не может точно управлять временем жизни объектов. Иначе там бы не появился счётчик ссылок. То есть есть ситуации, когда время жизни не очевидно и зависит от разных условий. И тогда это становится выбором между счётчиком и сборщиком. И оба не идеальны. Так что я бы не называл это ошибкой, скорее рекомендацией обойтись без автоматического управления, когда хватает ручного. В терминах C++ это использование uniq_ptr вместо shared_ptr, в D — @nogc, в C# struct, где это возможно.
Особенно ярко проблема заметна не на памяти, а файловых дескрипторах и прочих ресурсах, которые сборщик не трогает. Они должны управляться предельно просто и детерменировано. Но там и циклических ссылок нет.
А вот с тем, что GC из D может приводить к требованию 256 ядер процессора для простой игры, я не соглашусь. Люди пишут говнокод независимо от языка и фреймвёрка. Если бы не было js или C# с Unity, в такой же среде даже на чистом C написали бы то же самое, такое же медленное, но дороже. Более того, я уверен, что при равных трудозатратах код на C будет медленнее кода на D и, возможно, C#. C быстр тогда, когда на него тратят силы, а когда тяп-ляп и в прод, будет ад.
И нет, это не разработчики обленились и не хотят «включать мозг». Это запрос рынка на тяп-ляп, js, electron… ой, у нас анимация мигания курсора проц съела. Если качество кода не ценится, то язык не поможет. Административные проблемы техническими средствами не решаются.
Это я к тому, что GC удобен, а ситуаций, где с ним надо что-то делать не так много. Обычный программист на C++ не пишет свои аллокаторы (разве что использует готовые простые решения), так же и обычно на D не надо вспоминать про особенности сборки мусора.
Весь цикл статей как раз про то, что не надо бояться GC, потому что вам его хватит, а если нет, то даже за его пределами есть жизнь.