Комментарии 44
Бывает так, что читать неудобно (на беговой дорожке/влажная уборка и проч). В таких случаях, надо полагать.
Однако, не все же трудозатраты направлены на мгновенную прибыль (open-source тому подтверждение). Часто тот или иной маркетинговый ход, который не генерирует прибыль, в купе с прочими инструментами приносит определённые дивиденды.
Возможно, аудио/видео-формат направлен на
Мне не понятно зачем это надо авторам.
Потому что есть отдельные «потребители контента», которые читать не хотят, а хотят видео или хотя бы аудио. Следовательно либо авторы делают подкаст/видео, либо теряют часть аудитории.
Есть ещё такой нюанс, что текст теряет кучу информации по сравнению с записью голоса — интонации, паузы, ударения, вот это всё. В видео добавляется ещё и мимика с жестами.
конечно, на быстрых танках это не так удобно, но вот на маусе, е100 — мммм, выехал, встал под углом и расслабился, спокойно слушаешь подкаст, пока пушка не перезарядится
Или найдет на GitHub суперинтерпретатор-компилятор JavaScript, который работает с очень усечённым подмножеством JS на три с половиной синтаксические конструкции, но зато выдаёт сверхбыстрый нативный код.
- При условии что такой интерпретатор существует
- Если интерпретатор поддерживает JS не полностью, не надо называть его интерпретатором JS.
Вы ещё можете попытаться возразить что если его не существует, то его можно написать. Но тогда вам придётся доказать что написание такого интерпретатора вообще говоря возможно.
Язык – это математическая абстракция. Это набор правил, согласно которому составляется программа. У него нет производительности, у него нет перфоманса, это нечто, что существует в твоей голове и находит воплощение в текстовом редакторе.
Перфоманс есть у конкретных рантаймов, окружений, у конкретных программ, у конкретных апишек.
Да, но. Особенности языка накладывают ограничения на то каким может быть его рантайм.
Для TS, как и для JS возможен компилятор просто исходя из тьюринг полноты доказывать тут ничего не нужно.
В вызов компилятора с генерацией кода и его выполнение, с кэшированием результатов по исходнику.
придётся таки тащить с собой интерпретатор…
на той же iOs нельзя генерировать код «на лету» и его выполнять…
Почему нельзя? Ставим виртуальную машину Java и что-то вроде этого. Но проще делать приложение с бекэндом и отправлять запрос на бек, где все можно сгенерировать и возвращать ответ.
«Чистый» компилятор невозможен, вернее возможен не на всех платформах, так как есть функция eval(), которая, по сути, является механизмом макроподстановок.
Раскрываем eval на этапе препроцессинга. Макросы ведь не один день в компилируемых языках присутствуют.
Если код чаще всего одинаковый и отличается лишь аргументами с производительностью тоже скорее все будет нормально в обоих случаях, если кешировать результаты.
Такое существовало еще лет 15 назад и писалось элеметарно используя SpiderMonkey/V8. Вызывался нативный код, синтаксис ограничивался довольно сильно, все дела.
Если накостылять компилятор С++ без поддержки, например, шаблонов, это будет всё ещё С++, хоть и с ограничениями.
Если следовать вашей логике, то «компилятор», который всегда даёт на выходе программу, печатающую «Hello world», является «компилятором C++, хоть и с ограничениями».
Я не согласен. В статье слишком идеализированное представление. Языки компилируются реальными компиляторами под реальное железо, возможности и ограничения языка просто обязаны влиять на перформанс.
Например, C++ позволяет управлять размещением объектов в памяти, а языки со сборкой мусора — нет, и вдобавок в них объекты перемещают. Это значит, что в целом классе задач, завясящих от локальности расположения объектов памяти, языки со сборкой мусора будут принципиально медленнее.
Или, например, языки со статической типизацией при прочих равных не будут медленнее языков с динамической — в статическом языке вся информация о типах уже есть, в динамическом её ещё предстоит выяснить во время исполнения.
Или, например, GIL в Python — снижает производительность до уровня однопоточной. Сам дизайн языка плохо совместим с многопоточностью и скорее всего проще придумать новый язык, чем писать многопоточный интерпретатор для старого.
Ещё пример — constexpr в плюсах позволяет быть уверенным, что вычисления будут на этапе компиляции.
В каком-то другом языке можно только надеяться, что неидеальный программист напишет код, который реально можно вычислить во время компиляции, и что неидеальный компилятор догадается это сделать.
Конечно, если сравнивать скажем скорость вызова метода в сишечке и в питоне, то первая выиграет по скорости. Тем не менее быстродействие прграмм зависит от очень многих факторов, а языки отличаются не только по скороти выполнения программ, но и по скорости их написания.
Тем не менее заголовок не врет: "Если ты видишь статью, что язык Х быстрее, чем язык Y – можешь закрывать статью", так как ее автор скорее всего специалист в области перфоманса, нежели программист.
Парадигма «сделай красиво, а оптимальность это на сладкое» зародилась во времена когда делать производительный код было дороже чем подождать годик и гении из Интел подгонят новое железо на котором код будет работать в 2 раза быстрее.
Эти времена прошли. Может еще вернутся, но пока мы живем в реальности другой.
Целые новые поколения инженеров-программистов оперируют парадигмой которая была создана в ныне не существующей реальности. Похмелье после этого праздника будет горьким.
Я согласен с автором в утверждении, что не нужно ставить производительность во главу угла, но оперировать красотой как чем то универсальным — это путь тупиковый.
Мы должны думать о производительности, это наша работа, чтоб помимо того чтоб у пользователя работал наш софт, он должен работать так чтоб пользователь не чувствовал «у меня украли время, почему он работает так медленно?!»
А с современным валом статей и размышлений «лишь бы красиво» мы уже находимся в ситуации когда банальный софт сжирает память и процессор без сожалений, просто потому что текущие инструменты и языки кажутся инженерам удобными и они приносят в жертву интересы пользователей.
Последний раз, когда я сравнивал производительность bwbasic и Rust, я обнаружил, что Rust примерно в 7e8 раз быстрее. Я не уверен, свойства это языка, или нет.
Если же серьёзно — от языка может зависеть использование heap'а (например, java без heap'а существовать не может) и доступные конструкции (например, если язык не допускает использование int'ов, а даёт только float'ы, то производительность с целочисленными операциями у него будет соответствующая).
я сравнивал производительность bwbasic и Rust
Вы сравнивали производительность не языков а результата работы компилятора (у Rust) и интерпретатора (bwbasic — или он в нативный код компилируется?), поскольку сами по себе языки (как форма записи инструкций для компьютеров) это сферические кони в вакууме и их "производительность" можно мерять разве что по количеству человеко-часов необходимых для реализации того или иного проекта на конкретном языке.
Если другим людям нужно, они могут пофиксить сами и прислать пулреквест — сделаю ревью, когда у меня будет время и настроение.
Вся суть опенсурса от васяна. Шлите пул-рекесты в опенскурс корпораций, там для этого есть человек на зарплате.
Если ты видишь статью, что язык Х быстрее, чем язык Y – можешь закрывать статью