Если уж мысль развивать, то тут интереснее что-то вроде GitHub Gist + Mermaid Live Editor, то есть возможность делиться форматированными кусочками кода. Тогда имеет смысл кодировать в Base64. В любом другом случае проще закодировать в командной строке.
скругление углов картинки (для форматов с прозрачностью)
размеры отступов от кода до края картинки
выделение блока текста линейным выделением
прозрачность картинки
трапецоид, 3Д трансформации, градиенты, фильтры мне не нужны, но я понимаю, где они могут использоваться, поэтому тоже неплохо, чтобы были и они тоже должны настраиваться из командной строки (профиля)
настраиваемый водный знак
Требования к такому проекту можно разделить на две группы:
работа с кодом
работа с дизайном
Мне гораздо важнее работа с кодом. Работу с дизайном тоже нужна, и если делать, то делать единообразно (через скрипты, в т.ч.)
Подготовка таких картинок очень нужна, когда делаешь презентации с большим количеством кода.
Я пользовался сервисом https://carbon.now.sh/, но у него мало языков и мало настроек. Кроме того, у такого сервиса есть один существенный недостаток - это веб-приложение, очень трудоемко выходит: настрой, загрузи код, задай название картинки, скачай.
Такая метрика, как количество вакансий на язык, сама по себе мало информативна.
В других областях промышленности есть примеры, когда на всю страну есть несколько штучных специалистов и вакансий открытых нет вообще. И ничего, как-то живут люди. По мере необходимости готовят специалистов, доучивают.
Если инструмент решает специфичные задачи, то ему просто нет необходимости быть массовым.
До Steam была новосибирская компания Alawar, которая примерно в 2000 году начала экспериментировать с разными способами оплаты за игры. Кроме того, примерно в это же время игры стали выпускаться на slim box (могу ошибиться с названием), такие очень тонкие упаковки для CD-дисков, которые стоили заметно дешевле других вариантов изданий. Может, конечно, и другие факторы повлияли, но я тогда стал подмечать, что люди реально покупают игры.
Спасибо большое! Ваш рассказ очень резонирует и... мотивирует, что-ли.
Простите, но зачем такой разработке бенчи? Автор развлекается, о чём честно пишет.
Ну так про эффективность вообще речи не идет в статье.
Большая ошибка измерять эффективность языка эффективностью сгенерированного кода.
Посмотрите ещё раз на цели в начале статьи. На мой взгляд, цели достигнуты, автор молодец.
Если уж мысль развивать, то тут интереснее что-то вроде GitHub Gist + Mermaid Live Editor, то есть возможность делиться форматированными кусочками кода. Тогда имеет смысл кодировать в Base64. В любом другом случае проще закодировать в командной строке.
Сайт не всегда доступен.
Нередко презентация дорабатывается в самолете или поезде, где может не быть связи, поэтому офлайн режим крайне важен.
Дополню пожелания (подсмотрел в проекте):
скругление углов картинки (для форматов с прозрачностью)
размеры отступов от кода до края картинки
выделение блока текста линейным выделением
прозрачность картинки
трапецоид, 3Д трансформации, градиенты, фильтры мне не нужны, но я понимаю, где они могут использоваться, поэтому тоже неплохо, чтобы были и они тоже должны настраиваться из командной строки (профиля)
настраиваемый водный знак
Требования к такому проекту можно разделить на две группы:
работа с кодом
работа с дизайном
Мне гораздо важнее работа с кодом. Работу с дизайном тоже нужна, и если делать, то делать единообразно (через скрипты, в т.ч.)
Подготовка таких картинок очень нужна, когда делаешь презентации с большим количеством кода.
Я пользовался сервисом https://carbon.now.sh/, но у него мало языков и мало настроек. Кроме того, у такого сервиса есть один существенный недостаток - это веб-приложение, очень трудоемко выходит: настрой, загрузи код, задай название картинки, скачай.
В итоге пришел к использованию https://pygments.org/docs/cmdline/
Но у pygmentize тоже есть недостатки.
Итого, для подготовки картинок кода у меня такие пожелания:
работа из командной строки
большоей количество подсветок синтаксиса (и несложное добавление новых)
возможность добавления нумерации строк (с настройками внешнего вида)
задание начала нумерации
задание нумерации диапазонами, т.е. что-то вроде
(- - - 1 2 3 . . . 50 51 52), где "-" - пропуск/пробел, а "." - точка, показывающая пропуск кода)
поддержка разной стилистики для разных диапазонов
выделение строк (с настройками внешнего вида)
указание ширины (в символах) кода (важно для единообразия в рамках презентации)
поддержка разных выходных форматов (png обычно хватает, но иногда надо и другие форматы)
Настраиваемый перенос кода длинного кода (иногда по логике презентации можно многоточие поставить вместо свертки)
возможность задания "окна" редактора (в том числе и убрать совсем)
работа с профилями настроек (разная стилистика для разных презентаций)
Поэтому работу автора очень приветствую, буду наблюдать за вашим проектом.
Сделал такой же тест с помощью Фикуса (репозиторий).
На моем ноутбуке этот тест работает за 40мс примерно.
Если убрать директивы @parallel с 8 и 13 строк, тогда тест работает 195мс.
Тест на Питоне 12.28 сек.
Еще чего доброго и на себя интересные "запросы" зарегистрируют.
Ничего не мешает, но это ваша статья, без ссылок и примеров она не информативна, к сожалению.
Doom на CSS:
https://dev.to/grahamthedev/doomrendered-using-a-single-div-and-css-1fal
Калькулятор на CSS:
https://codepen.io/vrugtehagel/pen/eYJjYNm
CSS 3D cube:
https://codepen.io/Seasle/pen/yxpQYr
А по сути статьи -- нетривиальная такая технология развилась, да.
Far прекрасен, на *nix сейчас тоже замечательно работает. Пользуюсь каждый день.
Спасибо, интересно
Такая метрика, как количество вакансий на язык, сама по себе мало информативна.
В других областях промышленности есть примеры, когда на всю страну есть несколько штучных специалистов и вакансий открытых нет вообще. И ничего, как-то живут люди. По мере необходимости готовят специалистов, доучивают.
Если инструмент решает специфичные задачи, то ему просто нет необходимости быть массовым.
Программисты часто склонных хоронить языки, кроме тех, на которых пишут сами, увы.
Слухи о моей смерти сильно преувеличены! (с) Марк Твен.
Несколько дней назад автор одной из реализаций Common Lisp получил грант на доработки. Так что работы ведутся, разработка идет.
Может быть есть более подробная информация? С удовольствием ознакомился бы с материалами.
Так уж и ни одной?
del
(промахнулся веткой)
Ну не знаю. Мне сразу помогли и объяснили, что надо сделать. Я действительно зашел в следующий автобус и приложил карту.
Это не совсем корректно. Точнее, совсем некорректно.
Навскидку и по памяти:
PascalABC.NET
Klaus
Тривиль/Арвиль
Производных от Оберона целая пачка
Ficus
kPHP
1C, разумеется
Parser
Есть и другие разработки, большой список ведется на сайте https://compiler.su/
До Steam была новосибирская компания Alawar, которая примерно в 2000 году начала экспериментировать с разными способами оплаты за игры. Кроме того, примерно в это же время игры стали выпускаться на slim box (могу ошибиться с названием), такие очень тонкие упаковки для CD-дисков, которые стоили заметно дешевле других вариантов изданий. Может, конечно, и другие факторы повлияли, но я тогда стал подмечать, что люди реально покупают игры.