Pull to refresh
3
Karma
0
Rating
Андрей Кутейко @andy128k

User

ТВ для «любимой бабули» или куда смотреть, если нужен хороший вариант

Ждать следующий пост про саундбары для бабушек?

«Rust – не Си на стероидах. Чтобы его изучить, нужно избавиться от предрассудков»

Rust накладывает на программиста больше ограничений чем C++. И компилятору вроде как "проще" от этого.

Сишный компилятор тут как эталон. Rust сделан как фронтенд к LLVM. Точно так же сделан и Clang. И значит их можно как-то сравнивать в этом поле. Гипотеза (и вроде есть примеры) в том что Rust может передать тому же LLVM больше информации о коде чем Сlang.

Есть ли жизнь без тестов?

Чаще всего за уверенностью в надёжности кода стоит недоинформированность. Тесты может и не единственный способ и даже может не самый лучший, но единственный измеримый.

Оживляем картинку шейдерами или программирование абстрактного текста

Вот она какая, прикладная каббала! Интересно было бы разобраться в коде.

Styled Components — идеальная стилизация React-приложения

Чтобы CSS был отдельным файлом тот же webpack нужно отдельно настраивать. По-умолчанию стандартная связка style-loader/css-loader помещают стили в JS бандл.

> css in js это просто неоправданно срать в коде

Когда-то так же говорили про JSX, якобы это "html in js"

> срать в бандле итоговом.

Не уверен что это недостаток. С помощью того же url-loader картинки бандлят. Иногда может быть удобно иметь приложение в виде одного файла, например для встраивания.

Не знаю деталей про styled components, но вроде бы есть аналогичные библиотеки которые позволяют извлечь CSS (google подсказывает linaria и astroturf, может есть и другие). Так что я бы не стал обобщать на весь "css in js".

Styled Components — идеальная стилизация React-приложения

Ну а разве styled components делает что-то другое? Вроде как он тоже генерирует CSS и классы для селекторов, и так же генерирует `<style/>` узел в `<head/>`. Ну разве что в случае модулей это будет `<link/>`. Но в обоих случаях браузеру нужно загружать все стили.

Styled Components — идеальная стилизация React-приложения

Разве для тех же CSS-модулей ситуация не такая же?

Непереводимые английские слова, которых нам реально не хватает

В польском языке есть такое же слово -- dziadkowie. От слова dziadek -- дед.

Обзор Onyx Boox Volta 3: электронная книга с сенсорным экраном E-Ink-Carta, Wi-Fi и Bluetooth

Не один. Когда я в очередной раз разломал свой покетбук, то следующий брал намеренно без сенсорного экрана.

Очень сильно раздражало то что случайные касания воспринимались как жесты и, например, менялся размер шрифта.

Уходим с Mercurial на Git

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

Почему вы должны попробовать Rust

Потому что Rust это практичный компромисс между полным отсутствием проверок (С/С++) и слишком сложными и медленными системами доказательств.


И, как показывает опыт, компромисс вполне удачный. Этого самого unsafe кода исчезающе мало по сравнению с остальным кодом.

Почему вы должны попробовать Rust

Ну можно впасть в крайность и разметить весь код как unsafe. И даже в этом случае получится язык более безопасный чем C/C++.


Процитирую мануал. В unsafe коде можно дополнительно делать:


  • разыменовывать указатель
  • вызывать другой unsafe код
  • обращаться к глобальным переменным
  • реализовывать unsafe traits
  • использовать union-ы

Всё! Все остальные инварианты и проверки сохраняются, в том числе и пресловутый borrow checker.

Почему вы должны попробовать Rust

https://www.areweguiyet.com/ — вот тут собирают информацию о состоянии GUI в Rust.


Из личных наблюдений — есть очень приличный gtk-rs (привязка к gtk3), куча обвязок вокруг WebView, и написанные с нуля библиотеки со скупыми наборами виджетов.

Почему вы должны попробовать Rust

Так в том и дело, что весь код проверять и не надо. Только unsafe блоки. В них обычно пишут больше всевозможных проверок и покрывают их тестами.


Я уже года 4 пишу на расте и за всё время мне unsafe понадобился всего пару раз. Это были переписывания с C/C++ на раст и такой код был временным клеем. Как только последняя функция была переписана на расте — он удалялся. И в чистом коде на расте никакого unsafe уже не было.


Ну и важно понимать, что даже unsafe раст намного безопаснее C/C++. У компилятора есть проверки которые он выполняет всегда (safe и unsafe) и проверки которые доступны только в safe. Это всего лишь означает, что компилятор не может сделать это сам и требуется помощь человека (обычно это означает, что нужны тесты для этого куска кода).

Что не так с Лиспом?

Если язык согласован

Вот это точно не про Common Lisp. Язык, который появился в результате слияния разных диалектов от разных вендоров. При этом каждый вендор тащил туда свою специфику.

Что не так с Лиспом?

Перенимать всё же стоит полезные и уместные фичи.


  • REPL Driven Development выбивается из современной практики ведения истории кода в VCS. Дампы состояния интерпретатора (ну или лисп-машины) на роль версий не подходят никак. А уж про коллективную разработку и речи нет.
  • Хотрелоад есть много где. Erlang, JRebel для Java, Spring gem в Ruby on Rails, Webpack dev server для JS-а.
  • Компиляция в бинарник с рантаймом? Это скорее похоже на выдачу единственного что лиспы умеют за преимущество. А вот нормального tree shaking не завезли. Но если уж так хочется всё запаковать, то тот же докер-контейнер с любым интерпретатором вполне на эту роль подойдёт.
  • Про макросы я уже написал выше, там где они нужны, они есть (Rust, Scala), а в динамических языках и без них обходятся. Даже в Clojure макросы хоть и есть, их используют крайне редко.
  • Разные парадигмы в одном языке. Разве этим хоть кого-то можно удивить? Все более-менее популярные языки такие. Если же взять избитый лисперами пример про Prolog внутри лиспа, то вот пожалуйста — http://minikanren.org/ реализации на любой вкус.
  • Про рестарты тоже уже написал выше. Они необычные, но вот полезные ли? То что они делают достигается простой передачей замыкания.

Что не так с Лиспом?

Из перечисленного только макросы интересны и они (или другие инструменты кодогенерации) появились в других языках (макросы в Rust, Sweet.js/Babel в JS, и, простите, Lombok в Java).


Рестарты это сомнительная вещь сама по себе. Она запутывает поток выполнения и не известно как будет работать и будет ли вообще в многопоточных приложениях.


MOP переоценён. В любом динамическом языке (Python, Ruby, JS) это вообще не проблема. А в статических обходятся рефлексией и кодогенерацией, если нужно.


Можно ещё было бы вспомнить экзотику вроде комбинаторов методов. Но не будем :)

Что не так с Лиспом?

С Лиспом всё так. Вот только ему нечего предложить в современном мире по сравнению с другими языками. Он уже давно не "элегантное супероружие джедая". Многие языки впитали из него достаточное количество свойств. А те что остались, либо не сильно нужны, либо и вовсе вредны. А та же гомоиконность оказалась переоценённой.

Что не так с Лиспом?

Статья ссылается на Debian Woody, который вышел в 2002-ом и был актуален до 2006-го.

Размышления о Rust

Пока ! не стабилизирован, но его можно либо определить самостоятельно (как пустой enum) либо воспользоваться крейтом never.

Information

Rating
Does not participate
Location
Донецк, Донецкая обл., Украина
Date of birth
Registered
Activity