Комментарии 44
НЛО прилетело и опубликовало эту надпись здесь

Бывает так, что читать неудобно (на беговой дорожке/влажная уборка и проч). В таких случаях, надо полагать.

НЛО прилетело и опубликовало эту надпись здесь
Есть доля истины в ваших словах.
Однако, не все же трудозатраты направлены на мгновенную прибыль (open-source тому подтверждение). Часто тот или иной маркетинговый ход, который не генерирует прибыль, в купе с прочими инструментами приносит определённые дивиденды.

Возможно, аудио/видео-формат направлен на торговлю хлебалом создание узнаваемого медийного образа.
НЛО прилетело и опубликовало эту надпись здесь
Мне не понятно зачем это надо авторам.

Потому что есть отдельные «потребители контента», которые читать не хотят, а хотят видео или хотя бы аудио. Следовательно либо авторы делают подкаст/видео, либо теряют часть аудитории.
НЛО прилетело и опубликовало эту надпись здесь
Ну так тут ещё проще. У таких авторов основная аудитория сидит на ютюбе и они для них в первую очередь и работают. Или например денег они на ютюбе больше получают. Или ещё какой-то профит там у них выше.

А тексты писать для таких авторов это дополнительная работа и они этим заниматься не хотят.

Есть ещё такой нюанс, что текст теряет кучу информации по сравнению с записью голоса — интонации, паузы, ударения, вот это всё. В видео добавляется ещё и мимика с жестами.

можно играть в танки и слушать подкаст
конечно, на быстрых танках это не так удобно, но вот на маусе, е100 — мммм, выехал, встал под углом и расслабился, спокойно слушаешь подкаст, пока пушка не перезарядится
Лучшая игра для прослушивания подкастов — симулятор дальнобойщика, EuroTrack Simulator, например. Думать в игре вообще не надо, а так можешь и время с пользой проводить.
Перформанс — это из мира моды чото про выход моделек? Трейдоф — это про торговлю?
специалист в области перфоманса

Это артисты, устраивают перфомансы, представления. Цирковые бродяги, например. Вообще с этим словом статья играет новыми, неожиданными красками!


Ну не писать же "производительность" или, не дай бог, "скорость".

Или найдет на GitHub суперинтерпретатор-компилятор JavaScript, который работает с очень усечённым подмножеством JS на три с половиной синтаксические конструкции, но зато выдаёт сверхбыстрый нативный код.

  1. При условии что такой интерпретатор существует
  2. Если интерпретатор поддерживает JS не полностью, не надо называть его интерпретатором JS.

Вы ещё можете попытаться возразить что если его не существует, то его можно написать. Но тогда вам придётся доказать что написание такого интерпретатора вообще говоря возможно.


Язык – это математическая абстракция. Это набор правил, согласно которому составляется программа. У него нет производительности, у него нет перфоманса, это нечто, что существует в твоей голове и находит воплощение в текстовом редакторе.

Перфоманс есть у конкретных рантаймов, окружений, у конкретных программ, у конкретных апишек.

Да, но. Особенности языка накладывают ограничения на то каким может быть его рантайм.

Для TS, как и для JS возможен компилятор просто исходя из тьюринг полноты доказывать тут ничего не нужно.

В вызов компилятора с генерацией кода и его выполнение, с кэшированием результатов по исходнику.

на той же iOs нельзя генерировать код «на лету» и его выполнять…
придётся таки тащить с собой интерпретатор…
на той же iOs нельзя генерировать код «на лету» и его выполнять…

Почему нельзя? Ставим виртуальную машину Java и что-то вроде этого. Но проще делать приложение с бекэндом и отправлять запрос на бек, где все можно сгенерировать и возвращать ответ.

«Чистый» компилятор невозможен, вернее возможен не на всех платформах, так как есть функция eval(), которая, по сути, является механизмом макроподстановок.

Раскрываем eval на этапе препроцессинга. Макросы ведь не один день в компилируемых языках присутствуют.

И как вы будете раскрывать строку на этапе препроцессинга, если эту строку программа читает из файла/сети/из пользовательского ввода в процессе выполнения?
Ну, например, в JVM (и Java тоже) есть множество способов сгененерить классы из текста во время выполнения. Компилируемый язык может компилировать код прямо во время работы приложения. Будет ли это быстрее работы интерпретатора — будет зависит от оптимизаций компилятора/интерпретатора.

Если код чаще всего одинаковый и отличается лишь аргументами с производительностью тоже скорее все будет нормально в обоих случаях, если кешировать результаты.
а если в eval передаётся, например, код, который пришёл из БД (из REST API) или введён пользователем?

Такое существовало еще лет 15 назад и писалось элеметарно используя SpiderMonkey/V8. Вызывался нативный код, синтаксис ограничивался довольно сильно, все дела.

Если накостылять компилятор С++ без поддержки, например, шаблонов, это будет всё ещё С++, хоть и с ограничениями.

Я с вами категорически несогласен. Есть стандарт, описывающий что такое C++. Или в ваш компилятор можно засунуть всё многообразие программ, соответствующих стандарту, и тогда он является компилятором C++ или нельзя и тогда он не является компилятором C++. Он является компилятором чего-то другого.

Если следовать вашей логике, то «компилятор», который всегда даёт на выходе программу, печатающую «Hello world», является «компилятором C++, хоть и с ограничениями».

Т.е. Вы утверждаете, что при выпуске новой версии стандарта с++ в мире пропадают все компиляторы с++? Ведь существующие компиляторы еще не поддерживают новую версию стандарта с++.

Ну давайте рассуждать в терминах «компилятор C++14», «компилятор C++20», тогда проблемы с пропаданием не возникает.
НЛО прилетело и опубликовало эту надпись здесь

Я не согласен. В статье слишком идеализированное представление. Языки компилируются реальными компиляторами под реальное железо, возможности и ограничения языка просто обязаны влиять на перформанс.
Например, C++ позволяет управлять размещением объектов в памяти, а языки со сборкой мусора — нет, и вдобавок в них объекты перемещают. Это значит, что в целом классе задач, завясящих от локальности расположения объектов памяти, языки со сборкой мусора будут принципиально медленнее.
Или, например, языки со статической типизацией при прочих равных не будут медленнее языков с динамической — в статическом языке вся информация о типах уже есть, в динамическом её ещё предстоит выяснить во время исполнения.
Или, например, GIL в Python — снижает производительность до уровня однопоточной. Сам дизайн языка плохо совместим с многопоточностью и скорее всего проще придумать новый язык, чем писать многопоточный интерпретатор для старого.
Ещё пример — constexpr в плюсах позволяет быть уверенным, что вычисления будут на этапе компиляции.
В каком-то другом языке можно только надеяться, что неидеальный программист напишет код, который реально можно вычислить во время компиляции, и что неидеальный компилятор догадается это сделать.

Конечно, если сравнивать скажем скорость вызова метода в сишечке и в питоне, то первая выиграет по скорости. Тем не менее быстродействие прграмм зависит от очень многих факторов, а языки отличаются не только по скороти выполнения программ, но и по скорости их написания.
Тем не менее заголовок не врет: "Если ты видишь статью, что язык Х быстрее, чем язык Y – можешь закрывать статью", так как ее автор скорее всего специалист в области перфоманса, нежели программист.

Ну constexpr не совсем позволяет быть уверенным, что вычисления будут на этапе компиляции. Он говорит что хорошо бы чтобы они были на этапе компиляции(и скорее всего они будут), но это не всегда так

Это неверно. Это constexpr функция не обязана вычисляться в compile time.А constexpr переменная обязана иметь compile-time значение и их можно использовать в качестве аргументов шаблонов

Меня все больше смущает куда двигается индустрия создания софта и как это повлияет на наше будущее.
Парадигма «сделай красиво, а оптимальность это на сладкое» зародилась во времена когда делать производительный код было дороже чем подождать годик и гении из Интел подгонят новое железо на котором код будет работать в 2 раза быстрее.
Эти времена прошли. Может еще вернутся, но пока мы живем в реальности другой.
Целые новые поколения инженеров-программистов оперируют парадигмой которая была создана в ныне не существующей реальности. Похмелье после этого праздника будет горьким.
Я согласен с автором в утверждении, что не нужно ставить производительность во главу угла, но оперировать красотой как чем то универсальным — это путь тупиковый.
Мы должны думать о производительности, это наша работа, чтоб помимо того чтоб у пользователя работал наш софт, он должен работать так чтоб пользователь не чувствовал «у меня украли время, почему он работает так медленно?!»
А с современным валом статей и размышлений «лишь бы красиво» мы уже находимся в ситуации когда банальный софт сжирает память и процессор без сожалений, просто потому что текущие инструменты и языки кажутся инженерам удобными и они приносят в жертву интересы пользователей.

Последний раз, когда я сравнивал производительность bwbasic и Rust, я обнаружил, что Rust примерно в 7e8 раз быстрее. Я не уверен, свойства это языка, или нет.


Если же серьёзно — от языка может зависеть использование heap'а (например, java без heap'а существовать не может) и доступные конструкции (например, если язык не допускает использование int'ов, а даёт только float'ы, то производительность с целочисленными операциями у него будет соответствующая).

я сравнивал производительность bwbasic и Rust

Вы сравнивали производительность не языков а результата работы компилятора (у Rust) и интерпретатора (bwbasic — или он в нативный код компилируется?), поскольку сами по себе языки (как форма записи инструкций для компьютеров) это сферические кони в вакууме и их "производительность" можно мерять разве что по количеству человеко-часов необходимых для реализации того или иного проекта на конкретном языке.

«то производительность с целочисленными операциями у него будет соответствующая» — это бабушка еще на двое сказала, есть IR, если орпеделенный статический анализ показывает, что float тут не требуется и достаточно использовать int, то производительность может быть равноценной с языком в котором есть int. Компилятор может произвести так же различные преобразования когда уверен, что точность вычислений будут сохранена относительно исходного кода, тоесть в конечном итоге зная примерно как работает компилятор или интерпритатор или байткод машина вообшем случае возможно написать достаточно производительный код или эквивалетный код, была целая статья на эту тему «кротовые норы в Js». Касательно Java и heap, честно стандарт не читал, но почти уверен, что определение heap в нем не дается, если я правильно понимаю это абстракция исполнительной среды, не вполне уверен но думаю вполне можно придумать среду в которой не будет heap в привычном нам понимании
Если другим людям нужно, они могут пофиксить сами и прислать пулреквест — сделаю ревью, когда у меня будет время и настроение.

Вся суть опенсурса от васяна. Шлите пул-рекесты в опенскурс корпораций, там для этого есть человек на зарплате.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.