- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
Top 5 most loved languages:
Rust: 86.1%
TypeScript: 67.1%
Python: 66.7%
Kotlin: 62.9%
Go: 62.3%
Top 5 most dreaded languages:
VBA: 80.4%
Objective-C: 76.6%
Perl: 71.4%
Assembly: 70.6%
C: 66.9%
Top 5 most wanted languages:
Python: 30.0%
JavaScript: 18.5%
Go: 17.9%
TypeScript: 17.0%
Rust: 14.6%
А в антирейтинге нормальные пацанские языки: VB, Пёрл, Асм, Сишка.
Зачем? Зачем?
VBA же, а не VB.
А на VBA только троянов внутри документов опердень внутри экселек.
Или там как питон и питон в lldb или гимпе или куда его там заембедили
Кстати, видел полезное использование макроса в ворде в одной газете в прошлом веке.
Там текст форматировался в размер гранки, которую потом отдавали в типографию вроде
Только apiшки разные. Так это один язык.
Vb очень сильно отличается от VB.net, VBScript или QBasic. Там действительно пропасть.
Но ведь реакт и *уй — говнище.
АнгулярЖс самый лучший клиентский фрейворк. На нём даже нгк написан.
Зачем уважающему себя программисту активно сидеть на сайте с вопросами, ответами и _рейтингом_? Лично я там зарегался только когда не мог что-то нагуглить, поэтому хотел задать новый вопрос. Но удобный поиск по уже заданным вопросам избавил меня от этой необходимости, с тех самых пор в свой аккаунт я уже не заходил )))
В итоге, что нам показывает эта статистика? Не мнение, может быть, 2% нормальных программистов, не знающих про говнокод, а потому срущих на стаке, а мнение 98% ламерков, прошедших курсы HTML/PHP/JS и не осиливших что-либо сложнее скриптушни или языка "который как сишка тока безопасный даже думоть не надо!"
Доброе утро, oaoaoammm.
Поэтому, если беглый гуглинг вопроса не дал результатов, то на «SO», скорее всего, на него тем более никто ответить не сможет.
у меня не очень много вопросов на so, но почти на все из них есть ответы и ответы вполне себе адекватные.
если на so нет твоего вопроса, то как на нём появится ответ на твой вопрос? :-)
то ли дело qaru.site
вы вам перезвоним
SO лишь срез всего айти. Думаю дело в общем обанскиливании профессии.
В которую народ активно ломится, не потому что любит программировать. А просто за баблом.
Я сделал забавное наблюдение, зарплаты в «most dreaded» сильно ниже средних цифр, а «most loved» сильно выше.
https://insights.stackoverflow.com/survey/2020#work-salary-and-experience-by-language
Может дело и вовсе не в языках, а народ просто жаждет денег?
Люди любят деньги и комфорт работы
Ещё вчера люди учились на экономистов, юристов или барменов и смотрели на кодеров как на задротов и недолюдей.
А сегодня только услышав, сколько вечнозелёных получает «Колька, Иркин брат», бегут в погромисты.
На волне «войти в айти», они дружно рассказывают о своих мечтах быть «айтишником», как они любят кодинг.
И как им мама в детстве на ночь читала Кнута. И какая заебатая штука ТайпСкрипт, а Rust вообще чудо.
Надо было чего попроще. Типа html.
PHP: 62.7%
Но я был искренне удивлён, когда увидел, что народ больше страшится Ассемблера и Сишки, чем «PHP».
«За баранкой был под мухой...»
ты просто сказку не знгаешь
https://www.joelonsoftware.com/2001/12/11/back-to-basics/
не vb, но vbs
VBScript is the dinkiest language on earth and ASP programming consists of learning about 5 classes, only two of which you use very often. And only now do I finally feel like I know the best way to architect an ASP/VBScript applicatio
https://englishplusplus.jcj.uj.edu.pl/texts/lord-palmerston-programming/fulltext/index.html
риальне питух
Я немного пробовал это учить. Просто отвратительная, ублюдочная копия Ecma (ещё того, куцего, времён IE4-5).
Спольски понять можно. VBA в Экселе получился лютой годнотой. На тот момент технология просто революционная.
Но VBA для браузера, тут уж извините.
Это выкидывая за скобки немаловажный момент, что его поддерживал только IE, во времена своей славы.
Бейсик изначально ведь и позиционировался как простая скриптуха для быстрого прототипирования.
С этой точки зрения JS и Питон — эволюционировавший на следующую ступень Бейсик.
А разработчики «TypeScript» этого так и не поняли, сотворив мерзкую, осклизлую, болотную недожабу для браузеров.
- а как надо было?
Изначальный ЖС был гораздо ближе к идеалу. Туда бы хороший type inference прикрутить и тупизацию.
Я уже много раз про это писал.
Идеальный язык где ты пишешь.
a=1
А все ненужная питушня доопределяется сама
const a:int=1;
Изначальный ЖС был функционален.
А прототипуха, это мелочь, без неё можно было и обойтись.
Кстати, для "JS"-дебилов: имейте в виду, что для превращения числа-строки в целое число необязательно использовать "parseInt" - можно просто умножить строку с числом на 1.
И тогда заставлять явно писать мудификатор.
Ситуация довольно редкая, потому от этого только польза.
> выдавать ошибку при shadow.
ну, такое
А тогда классическое:
var a=1
Смысл в том чтоб const был по умолчанию.
Это не то. Хуйня.
Неявный const очень сильно всё упрощает, и избавляет от целых КЛАССОВ ошибок.
Типа переопределения ниже по функции и захватов в лямбдах.
А классическое == убивается на корню:
Компилятор это отловит, т.к. это переприсваивание константы.
if (x=2){ //тут ошибка, хотели x==2
Компилятор это отловит, т.к. это переприсваивание константы."
Если компилятор и так "понимает", что имелось в виду, почему бы ему сразу на лету не переделать некорректный код и не выполнить то, что подразумевал пользователь?
Везет же некоторым...
> ну, такое
https://govnokod.ru/28254
если потеребонькать ширину таблички по нажатию на кнопаньку, то да
если SPA во все поля с файербейзами и рагулярами, то жс вообще ни о чём
Минимум всякого синтаксичесого хлама private, public, protected. Без наследования.
Вся приватность как в сишке (кишки не видны через h-файлы интерфейс модуля) или как в жс, локальные переменные прячутся в замыкании.
Именно.
это такое буэ, что страшно сказать
> или как в жс
this is undefined
В "Word"-е.
З.Ы. Это было бы смешно, если бы авторы некоторых либ реально так не делали.
сгенерь документацию из исходников
а вообще отойдите от меня, мужчина, от Вас сильно пахнет нафталином
- откуда я знаю, как это делается в языке, на котором ты пишешь? погугли
В моём языке я просто посылаю нахуй ООП с его классами и интерфейсами, пишу нормальный процедурный код и теку.
у тебя документация делается путём создания интерфейсов?
начешуя мне копаться в твоих сырцах, чтобы про апи почитать
Можно назвать эти классы случайными наборами букв и цифр. Если, конечно, без классов вообще никак - ну любишь ты БДСМ.
- не понял, в твоём языке модификаторы public и private означают что-то более другое?
и ты его ещё форсишь после этого?)
>это такое буэ, что страшно сказать
Возможно открою тайну.
Но интерфейсы есть в КАЖДОМ современном промышленном языке: C++, C#, Java, TypeScript, Python, Go, Rust (trait) итд.
не считая крестов
я беру питон
пишу одно файло
импорчу его и теку
сишка не осилила многопроходный компилятор, теперь до сих пор жрёт говно. это подаётся как невиданное достижение. ну обалдеть)
пишу одно файло
импорчу его и теку
Та же хуйня с "PHP".
Я беру сишку. Пишу int main() и теку.
Я написал реализацию, тыркнул кнопкой, и попросил вынести ее декларацию в .h файл
это ещё более-менее
а в жабе это зачем руками делать?
а если в IDE, то оно сгенерит его.
В общем смысл в том, что
ничем не хуже
но первое все ругают, а второе нет
почаму?
В public interface Petushok {
Буковок больше.
Им за буковки платят.
Интерфейсы есть не только в ЙАЖЕ, а вообще везде.
и в го не надо
и в питоне не надо
и даже в великом и ужасном лишпе - нет, не надо
у вас молоко убежало
Форварды к объективному си поди?
Чтобы можно было его юзать из объективной сишки?
А потом вылазят .h-файлы, llvm, биндинги сишные, вотэтовотвсё.
Сидят на полностью ворованной инфраструктуре да и покрякивают.
- я не рефлексирую по этому поводу)
просто разделение на .h и .с это, на мой взгляд, рудимент, а вы ещё это в 2020-ом году предлагаете в качестве "инновации" добавить в js
Может показаться что это «троллинг». Однако здесь абсолютно серьёзно.
Есть модуль isTen.
Внутри него объявлены всякие foo, bar.
Мы хотим чтобы они не торчали наружу, засирая глобальную видимость.
Наружу торчит только функция isTen.
Добиться этого можно разными способами. private/public один из вариантов. Как я уже отметил далеко не наилучший.
nodejs module.exports по духу как тот же extern, позволяет «увидеть» функцию или константу из других модулей. Да, там ещё есть поправки на линковку, но в целом.
> nodejs module.exports
- это ж оно и есть?
Поздравляю! Мы изобрели h-файл!
Чем не явный список экспорта?
Businesses and organizations
TSD Desalination, an Israeli start-up
Texas School for the Deaf, U.S.
Transylvanian Society of Dracula
Turin School of Development, Italy
University of Wales Trinity Saint David, a university in the U.K.
TSD - Tunisian Software Development, Tunis , a Waste management IT consulting company
Government
Technical Services Division, another term for the U.S. CIA's Office of Technical Service
Treatment, Storage, and Disposal Facility; see HAZWOPER
Treasury Solicitor's Department, U.K.
Trilateral Security Dialogue, part of the Quadrilateral Security Dialogue
Science and medicine
Target-to-skin distance, a measurement in external beam radiotherapy
Tay–Sachs disease, a genetic disorder, fatal in its most common variant
Temperature-dependent sex determination
Thermionic specific detector, another term for nitrogen–phosphorus detector
Total sleep deprivation, a parameter in sleep and memory studies
если у тебя есть ещё обжсишные или сишные инклуды, которые ты хочешь сделать публичными, ты их в этот хедер добавляешь
я не знаю, даёт ли он что-то для чистого свифта, по крайней мере, нигде не встречал упоминаний. думаю, это ради консистентности
хедеры
на случай, если кто-то приебётся, что там импорты, а не инклуды
я чот думал, что их надо в обязательном порядке помечать как @objc, но это только для рантайма
ну и свифтовые типы должны быть представимы в objc
в свифте как минимум есть llvm'ный modulemap
только руками его никто не трогает почти никогда за исключением редких случаев
Про modulemap для затравки
https://stackoverflow.com/questions/47036023/what-is-export-in-module-modulemap-file-inside-each-framework
https://clang.llvm.org/docs/Modules.html#export-declaration
а как он выглядет?
а, ок
А это как раз modulemap
Это разные вещи
modulemap генерируется автоматом при сборке. Но можно и руками, емнип
В тонкой настройке экспорта я честно не силён, надо вникать в доку по llvm.
Но там много можно разного делать, например, создавать модули из голых сишных исходников
И клиент потом компилируется против этого .h файла.
Кстати, что за браузер?
Звучит очень смешно, т.к. в го приципиально отказались от ооп, однако зачем-то завезли:
Видимо, потому что «не надо».
Разделение реализации и API достаточно очевидная концепция.
Особенно в контексте обсуждения модификаторов public/private.
МАКАКА даже пример дал:
https://govnokod.ru/26961#comment576261
я ж никогда не поверю, что ты не знаешь разницы между interface в %LANGNAME% и хедерами в сишке.
ты троллируешь
но я не ведусь(
Речь не о разнице. А о схожести.
h-файлы немного по-уебански сделаны, через из-за чего пришлось выдумывать precompiled headers и прочую питушню.
Но их суть отделить API от его реализации.
>ты троллируешь
Даже gcc пишут что это интерфейсы.
https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html
только ж они всё-таки про разное
наличие interface в Go не заставляет язык иметь ещё и интерфейсные файлы отдельно
Так в Сишке тоже можно объявлять в одном файле сигнатуры функций и чуть ниже писать их реализацию.
А в явах/шарпах тоже принято писать интерфейсы в отдельных файлах.
На самом деле это логично.
И на практике во всех RPC типа WSDL, SOAP принято поставлять стабы в отдельных файлах.
Которые по сути те же интерфейсы.
в Си тебе нужно иметь хедер для своей библиотеки. и при этом писать его руками.
в других языках* эти хедеры даже если и есть, то пишутся машиной и людьми обычно не редактируются
вон Макака говорит, что какая-то сишная ИДЕ тоже умеет сигнатуры в хедер копировать. это прогресс.
а то, что таким образом в сишке достигается инкапсуляция, так это чудесно и я про это знаю. только других способов-то там по идее и нет :-)
* не считая ожидаемо C++ и совершенно внезапно Лажи, ну и обжси до кучи
А в WSDL для библиотеки нужны стабы. В чём отличие-то?
>и при этом писать его руками
Не обязательно.
Вообще не вижу корреляции между функцией IDE сгенерить h-файл и возможностями языка.
а так отличие в том, что ты свои дефиниции мейнтейнишь в одном файле, а не в двух
А разве в свифте когда объявили protocol, его не нужно мейтенить в двух местах (объявлении и реализации)?
если ты говоришь про имплементацию протокола, так это уже совсем другая сущность. её может и не быть в данном конкретном модуле.
Поменяли протокол — нужно поменять реализацию, верно?
вот тебе пример на C++, как я его понимаю (если в чём проебу, старшие товарищи поправят)
у тебя есть абстрактный класс
он описан в .h файле
.cpp файла у него ведь нету, верно? (ну даже если есть, то только лучше для моего примера)
есть наследник абстрактного класса.
у него есть и .h, и .cpp
то есть это три файла
в Свифте протокол в одном файле и реализация в другом файле
это два файла
выигрыш в полтора раза
масштабируй даже на небольшой проект на ~1000 файлов, нифига себе экономия энтропии
а кто там что потом меняет и рефакторит, это вообще к теме разговора не относится
https://php.ru/
когда ставишь компилять, сражаешься на мечах на стульях в коридоре
всё равно всё в шаблонах через шаблоны
/green
то тогда конечно меняем в браузерах js на C++
если захочется конструктор там позвать
Когда в хедере у тебя ХуёМоё с единственным полем - указателем на ХуёМоёИмпл. А ХуёМоёИмпл лежит в цппшнике вместе с реализацией методов ХуёМоё.
Ну и твой вариант с тремя файлами тоже часто встречается.
В крестах дохуя вариантов отстрелить себе ногу так то.
Стабильное ABI. Методы не виртуальные, на их порядок и количество насрать. А все кишки спрятаны в реализации и их можно менять как хочешь без переконпеляции клиента.
Qt это юзает, к примеру.
нет ничего идеального
ты свой ХуёМоё экспортировал в длл
в приложении клиента импортируешь ХуёМоёЛиб.длл, но компилятор клиента также должен знать как минимум о размере объекта ХуёМоё, чтобы выделить ему, например, 56 байт на стеке (для этого вместе с длл ты поставляешь и хедер), скомпилил, собрал, молодец
теперь ты решил, что в ХуёМоё надо хранить на одно приватное поле больше - int dick_length_;
пересобрал ХуёМоё.длл - всё, клиент пошёл по пизде, его теперь тоже надо пересобирать
ABI
> укококозатель
https://en.cppreference.com/w/cpp/language/pimpl
господи, даже на дцпреференс статью сделали для тебя, что за анскильность задавать такие вопросы в интернете
2) Там указатель, в этом и минус подхода. Но в случае с интерфейсом и фабрикой он тоже будет.
Если ты хочешь максимум пирфоманса, ты вынужден светить кишками наружу.
Либо просто привык после какого-нибудь Qt.
> теперь ты решил, что в ХуёМоё надо хранить на одно приватное поле больше - int dick_length_;
Какая кресто-инкапсуляция )))
Абасракция потекла по штанине.
Удобство в том, что у этой хренотени крайне стабильное ABI. Ты в любой момент можешь выпустить новую версию либы с новыми фишками или полностью перехуячить реализацию. И старые клиенты будут совместимы с этой дллкой.
Кстати, в ХуёМоёИмпл методы совсем не обязательны. Можешь юзать его в методах ХуёМоё просто как структуру.
Pimpl не настолько гибкий в плане поштучной подмены компонентов. Да и "импл" часто просто структура без методов.
>Добавленрие поля хз, но вроде тоже
Там в каком-то смысле ещё хуже.
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/Serializable.html
The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named serialVersionUID that must be static, final, and of type long.
However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class serialVersionUID fields are not useful as inherited members.
В плане ABI проблем конечно меньше. Но при использовании RPC-технологий (а это в ынтырпрайзе частый гость) они как бы возвращаются вместе с сериализацией.
В Йажа всё-таки есть более-менее рабочая инкапсуляция. И сериализационных и ABI-проблем меньше.
То есть безболезненно добавить приватное поле пожалуй можно, только осторожно и c transient.
Но «перегенерить стабы и скелетоны» когда-то давно было довольно частой ситуацией во времена корбы и рми. Даже при неизменном классе, а например при обновлении версии jvm с 4ой на 5ю.
Это же кресты ебаные. В них нет никакой логики.
СиПлюсТруп вдобавок к имеющемуся в сишке механизму инкапсуляции (headers) сделал ещё один (классы с приватными полями).
Где можно «прятать» поля.
Механизм ожидаемо оказался полным говном, т.к. приватные поля хоть и не видны, но влияют на размер структуры.
И к тому же в их содержимое всегда можно посмотреть скастив структуру в массив.
То есть поставленные цели не достигнуты: ни сокрытия, ни абстрагирования достигнуть не удалось.
Либо у тебя структура в паблике и часть ABI, либо ты её прячешь но начинаешь дрочить кучу.
Либо ты делаешь ёбаный хак с резервированием места - для клиента поля не видны, только char buf[N].
Если ты все методы сделаешь виртуальными, а поля клиенту не покажешь - всё будет как в жабе.
Если ты поля клиенту покажешь, даже приватные - они станут частью ABI, клиентов придётся пересобирать, зато работать будет быстрее и аллокатор можно не дрочить.
Просто жаба тебе выбора не даёт, вот там это и выглядит "естественно".
>Интерфейс класса не изменится.
Ахаха. Наивный. Почитай про java serialVersionUID.
>Но в ООП совершенно естественно добавить приватное поле.
Именно поэтому я против «ООП».
Они не сделали инкапсуляцию данных или абстракцию, скрывающую детали реализации от пользователя API.
Они просто сделали говно на котором писать нельзя.
И в этом и заключается фокус.
Но далее говноооп нам экспортирует публичные методы интерфейса на которых мы уже и пытаемся что-то сваять.
Очевидно, что сваять ничего нельзя - поэтому отовсюду торчат фасады, обёрточки, pimpl-указатели.
Это вообще стандартная практика.
Ещё один паттерн, сделать енум с ид параметров и хуйнуть flexible array member.
Если ты анскильный птушный лох, то безусловно.
Потому я уже устал вам объяснять, что массив — единственная нужная структура данных.
И чем вы быстрее это поймёте, тем будет лучше.
В Сишке пацаны используют flexible array member. Пока ооптухи делают поля приватными и рвут стек.
То есть С+Труп сделал свою реализацию сишных хедеров через public/private.
И свою реализацию линковки, через виртуальные функции.
Но этот подход соснул хуйца и мы возвращаемся к .h и extern "C".
Ахахаха.
но можно фабрику абстрактных синглтонов написать, конечно)
(но это и будет та самая единица компиляции, которой надо форвард-декларацию на конкретный ХуёМоё иметь)
можно сделать IoC, чтобы ХуёМоё сам себя зарегистрировал в каком-то реестре, как плагины делают, а потом абстрактная фабрика хуяк хуяк - нашла во мху енота и отдала
на что только люди не пойдут, лишь бы не использовать шаблоны через шаблоны!
This.
Но можно и просто фабричную функцию рядом с интерфейсом оставить, если это что-то внутреннее. Кишки с полями в хедер не торчат - и ладно.
что за предрассудки
кресты не сишка, лучше иметь инлайн, где он нужен, чем течь от джампов
Можно юзать несколько прекомпайлед хедеров, по одному на подсистему например. Тогда не всё, а только десяток-другой файлов.
Потом, конечно, ты будешь ждать пока соберутся остальные. Но они не всегда нужны.
Поэтому что-то у тебя будет на инлайнах и инклудах, чтобы работало побыстрее. Что-то будет на интерфейсах или пимпл чтобы изоляция получше и конпеляция побыстрее.
https://govnokod.ru/26961#comment576217
с этим говном мамонта сталкиваюсь по большим праздникам (хотя тут уместнее антоним)
думаю, что это технически должно быть возможно, ведь в общем приватные методы класса в обжективе так и пишут: делают экстеншн в .m файле и текут
пиздец конечно там атмосфера
>а вы ещё это в 2020-ом году предлагаете в качестве "инновации"
Да, в Сишке есть киллер-фича: линкер. А ЖСах и Йажах его нет.
Спольски писал про это.
https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-have-a-linker/
Вместо линкера в мире лалок принято ебошить: http://c.d.n/pitux.latest.js. А потом эпично ломаться, когда latest меняет api.
Те что похитрее используют уёб-пак. Но до уровня Сишка-с-линкером по-прежнему не дотягивают, отдавая мегабайты ненужной хуйни. Это я не упоминаю -flto
Вот эту стадию скриптухи почему-то так и не освоили.
>Then, it removes any library functions that your program does not use.
Именно поэтому я за импорт Сишных концептов и технологий будущего во все новомодные языки.
Но меня и правда бесит отсуствие линкера. И как результат многие мегабайты жс-кода, кучи фрейморков ради одной кнопочки или автокомплита.
Я знаю:
>>Те что похитрее используют уёб-пак.
Только он не умеет того, что умеет сишный линкер.
А именно выбрасывать из фреймворков неиспользуемые функции.
это был вынужденный костыль, чтобы не инклюдить тела функций в каждую единицу компиляции, чтобы потом линекер охуел и сказал "я два раза два раза не повторяю", но и хоть как-то компилятору намекнуть, что это имя функции всем известно, и принимает она вот такие аргументы (первый компиляторам было даже похуй че она там принимает, известна, и на том спасибо, а если неизвестна - то ворнинг, пусть линекер разбирается)
среди практически современников ранней сишки уже были виртовские языки (мудула?), которые как раз и должны были уже отделить мух от котлет, но VHS победил Betamax, а питушки продолжают кипятить и в 2020 году
Я было повёлся на это, а в итоге это оказалось той же хуетой.
Вообще кошернее наоборот. Ты пишешь интерфейс, а IDE генерит заглушки для реализации.
но обычно же не так
обычно ты пишешь реализацю, и в процессе рождается понимание, как из нее абстракцию сделать
или нет?
ты ты сначала пишешь интерфейс и тест, а потом код?
* делает хоть как-то
* делаем на это тест
* переписываем по уму
У меня та же хуйня со всеми остальными языками.
В сишке тоже структы по умолчанию закрытые, а методы финальные )))
- очередная хипстерская мода. "мы настолько анскильные, что боимся отсабкласситься, кабы чего не вышло"
А потому что только Программист знает, что валидно, а что нет.
Он царь и бог, а не житель анально огороженной крепости с надсмотрщиком как в джава
даже в шарпе есть интернал
не говоря уже про более новые языки
Наследование создаёт больше проблем, чем решает.
а про то, что макака в двух разных местах проповедует абсолютно противоположные вещи)
я за явное лучше неявного
лучше написать final, когда ты понимаешь, что он тебе реально нужен, чем сидеть тупить помнить, а какой же мудификатор здесь по умолчанию
но авторам котлина виднее, конечно
я ж не написал, что final нужен всем в 99% случаев
он может быть нужен
и потом разработка это не только либы
я пишу конечное приложение и буду постоянно биться лбом о мудрость авторов котлина?
если я пишу приложуху, то какая хер разница, опен у меня там или жопен
> потому что наследование в 99% случаев не нужно
- попробуй пописать на UIKit совсем без наследования
если выбирать между JS и TS то выбор вроде бы очевиден:) Так что они всё таки сделали лучше.
Другой вопрос, что всю скриптопарашу надо обоссать и сжечь нахуй уже давно, и заменить ее нормальными современными языками с нормальной стат типизацией, с выводом типов, кококок-вариантностью нормальной (а не анальной, как жобе) с сахаром итд
Нахуй нужно всё это говно?
Эти языки сейчас в тренде, потому и вот
В хроме флаги есть, проверь
На графике видно конкретно, что video decode работает.
Видимо просто отношение busy/total по времени. А то, что видюха на расслабоне крутится на низкой частоте не учли.
В прыщах в настройках нвидии те же 30% и 500-600МГц.
Кстати спасибо за идею. Надо во что-нибудь поиграть перед сном, а то отопление ещё не дали.
Я просто в 3дмарке стресс-тест гонял когда охлаждение системника проверял. 200+ ватт он с неё вполне выжимает.
На самом деле, интересно было бы нейросетки на ней погонять. Тензорфлоу вроде умеет юзать тензорные ядра.
Приведи реальный пример.
На 5ГГц получилось только 6 гипертредов из 12 запустить без троттлинга.
Резать жалко, вот соберусь новый покупать - тогда можно попробовать по приколу.
На последних поколениях вроде опять металл начали заливать.
Ну и вдруг у тебя не на декодирование, а тупо на обслуживание приемки мпег чанков с сервера.
Ещё надо разобраться какой кодек пришел (профиль и тд)
А вот всякие косинусные преобразования и все что дальше скорее всего уже видюха.
Навскидку, в своей памяти ему удобнее будет декодить. А потом скопировать. Она всё-таки поближе, чем память видюхи.
А так то и проц видюхе и видюха процу могут в память срать.
intel_gpu_top
Так что если играть в распоследние игры или считать что-то на видюхе не собираешься - впизду её.
DXVA2
Оно оптимизируется, конечно, если матан вспомнить. Но все равно вычислений дохуя.
Кобенирование кусков картинок и мыльный фильтр полегче будут.
играй в VA VA (до)
Вот если загрузка CPU не упадёт, то уже нужно пердолиться.
d++ дело говорит. Зависит от формата же. Ютуб совсем недавно AV1 выкатил в прод.
И с сервера уже может AV1 приходить, без спроса. И ни одна видяха его пока не умеет декодить.
И VP9 кстати тоже, если комп старше 5 лет.
надо прогу которая из коментов в говнокоде делает посты
Кстати в ФФ наконец-то завели libva для X11. Вот только недавно. 2k20.
Там есть такой замечательный примитив как загрузка прямоугольника из буфера.
Через текстуру в OpenGL можно ещё выводить.
Х.з., может ещё какой-то способ есть, о котором я не знаю.
З.Ы. Но эти преобразования очень криво работают. По сути только RGB, BGR, RGBA и ABGR. Остальное у меня не получалось запустить, цветовые маски игнорятся.
VA-API video decode/encode interface is platform and window system independent but is primarily targeted at Direct Rendering Infrastructure (DRI) in X Window System on Unix-like operating systems
The main motivation for VA-API is to enable hardware-accelerated video decode at various entry-points (VLD, IDCT, motion compensation, deblocking) for the prevailing coding standards today (MPEG-2, MPEG-4 ASP/H.263, MPEG-4 AVC/H.264, H.265/HEVC, and VC-1/WMV3).