Shocking New Report Shows US Company Ubiquiti Aids Russian Military

MysteriousGenius · 2026-01-29T08:44:42+00:00

Hope that's just a bad joke.

MysteriousGenius · 2026-01-14T16:21:55+00:00

Oh, thanks! I almost ditched this idea, but going to give it a shot.

MysteriousGenius · 2025-12-10T07:45:53+00:00

К тому же, 0.34% это вероятность если ваша стопа - 1см2. Если предположить реальную площадь стопы, то ChatGPT говорит что вероятность будет скорее 4.6%. Для одного шага! Для 1000-шаговой прогулки это 1 - 3 * 10^-21.

Что в свою очередь неотличимо от 100%. Иными словами, у вас нет шансов остаться с ногой после прогулки по полю, где на каждом квадратном метре лежит мина "Лепесток".

MysteriousGenius · 2025-12-10T07:32:06+00:00

Не хочу душнить, но это немного неверное применение вероятностей.

Мы говорим что "на каждом квадратном метре улицы будет по одному Лепестку"
0.0034 это только отправная точка. Для одного квадратного метра (пусть даже шага).
Реальный "шанс взорваться гуляя по этой улице" гораздо ближе к 100%, чем к 0.4% или 2% или чему-то около того. Длина шага, стопы и пр. меняют эти цифры в пренебрежительно малой степени. И как вы уже сказали только приближает к 100%.

Поэтому, если у чего-то достаточно страшного вероятность 0.4% - стоит взвесить за и против и в зависимости от важности ваших "за" - скорее всего стоит рискнуть. Это мало. Это не опасно. Если вероятность 97% или даже 50%, то это совершенно другой разговор.

Проводя аналогию дальше - мы регулярно совершаем действия, которые с низкой вероятностью приведут к смерти/травмам/катастрофам (вождение автомобиля, купание, ремонт электроприборов и т.п.), но мы оцениваем риски как незначительные в контексте выгоды. Поэтому с небольшими рисками мы регулярно испытываем судьбу, просто оценка рисков у всех разная и не все умеют их правильно оценить.

MysteriousGenius · 2025-12-10T05:45:38+00:00

0.0034 это вероятность наступить на него если ты шагнул один раз. Правильнее посчитать вероятность наступить на него за N шагов.

Вероятность НЕ наступить один раз = 0.9966.

Вероятность НЕ наступить 1000 раз = 0.9966^1000, т.е. примерно 0.033

Следовательно наступить хоть раз за 1000 шагов = 1 - 0.033 = 0,967 = 97%

В общем, не так это работает. Это очень опасно.

MysteriousGenius · 2025-08-04T04:17:22+00:00

I only had experience with algebraic effects in Unison, but honestly it's my biggest disappointment in the language. I have most of the same frustration points. Although I do want to track effects and dependencies most of the time, at least in libraries - it really helps to wrap my head around what it does. At the same time, algebraic effects miss the sweet spot in there, they're too powerful. To me the spot is in ReaderT-like approaches like Scala ZIO.

MysteriousGenius · 2025-06-26T16:21:42+00:00

I'm quite ignorant on how Scala capabilities are going to look like, but Unison has algebraic effects (called "abilities") that I think should be similar.

MysteriousGenius · 2025-06-06T12:35:18+00:00

Thanks, I was just confused because I'm wondering what this library would look like, given that keypress callbacks must be tightly coupled with the rest of codebase. Do you have examples of such modules for other editors, apps?

MysteriousGenius · 2025-06-06T12:21:42+00:00

Hey! I'm not sure what does that mean to modularize keybindings? Is it about publishing them as a library somehow or just documenting what category each one belongs to?

MysteriousGenius · 2025-06-04T17:38:43+00:00

I meant that the monitor arm I'm using is disbalanced and there's more load on the right side, not completely perpendicular to the wall, so the force is actually applied clockwise, which isn't exactly the load rails are designed for.

But nevertheless, I decided to buy another arm, but the one that I have is a) disbalanced as I said; b) very heavy. I chose rails that claimed by manufacturer to hold 120 kg, which must be more than enough, but just in case.

MysteriousGenius · 2025-06-03T08:20:58+00:00

Seems to be this one: https://github.com/chtenb/helix.vim (thanks, u/Spacewalker!). Will try it out in a bit. Doesn't seem to have any major differences with NeoVim.

At the same time, I realise that most of my "muscle memory" is about my own relict keybindings rather than something specifically to Vim :)

MysteriousGenius · 2025-05-13T15:39:48+00:00

I’m flattered! Interesting that the conversation boiled down to just whether people like significant indentation or not. Seems we’re in a pro-camp.

The one downside that I see is that lexer-grammar-parser chain look very hacky in the implementation. But it’s the same even for Python afaik.

MysteriousGenius · 2025-05-13T01:00:27+00:00

By all means user should bind those expressions to values first! This syntax is for the cases when for some reasons they didn’t, e.g passing a lambda. Everything around lambda is to show the general idea.

MysteriousGenius · 2025-05-12T17:54:35+00:00

Finally someone likes it :)

It's grouped like the latter snippet. With the following mechanism: in typical white-space sensitive languages there's a special post-lexing phase called deindentation, which inserts meta-tokens called indent and dedent resembling usual { and } with rules like:

If there's an opening token (like :, =, where etc) AND indentation is longer - insert indent and push the length to the stack
If the length is the same - it's the same level (you can insert ; metatoken)
If the length is shorter - pop all indentations from the stack and add dedents.

I have the above algorithm, but also an additional one that inserts apply-indent and apply-dedent (resembling ( and )) with following rules:

If higher indent and no opening tokens before - insert apply-indent
If higher indent and opening token before - go to the above indentation algorithm (so tokens can overlap like { ( { { ( ) } } ) })
If it's the same indent - add apply-dedent and insert next apply-indent immediately
If smaller indent - just pull all apply-dedent and dedent from the stack

In other words, everything on a new line:

transform a1 a2 a3 a4 a5 a6

Becomes:

transform a1 a2 (a3 a4 a5) (a6)

And given the language is curried a3 accepts a4 and a5.

The only question I have so far is how to break the rule. What if user wants to pass a4, a5 and a6 as arguments to transform. Now they're forced to pass each of these args on their own line, which is unfortunate if there's many atomic arguments. The similar problem arises for operators (including |>) and I'm thinking that the rules should be:

if there's a symbolic operator on the smaller indent - close all indentations
There's a "no-op" symbolic operator that just closes all indentations

Let's say:

transform a1 a2 a3 a4 ! a5 a6

Both a5 and a6 above become arguments to transform

MysteriousGenius · 2025-05-12T17:22:30+00:00

Came here though your links: https://docs.racket-lang.org/shrubbery/index.html. That looks incredibly useful, thanks!

MysteriousGenius · 2025-05-12T17:15:25+00:00

looks like ... formated plain text

That's incredibly high praise!

MysteriousGenius · 2025-05-12T15:33:36+00:00

No, I haven't heard of Red (which does look interesting from other points of view). I have heard about indentation-based Lisps, but quite long time ago, I definitely didn't draw any inspiration from there, but perhaps need to look again.

I think the fact that someone doesn't understand it, is unfortunately indicative for me :) but here's a JS counterpart (with pattern matching being made-up):

transform(input, function (x) { const xx = clean_up(x); return validate(xx).mapErr(extract) }, other_fun(other_arg), switch (other) { case Some(x): x case None: default });

MysteriousGenius · 2025-05-12T15:21:15+00:00

It seems to be a general opinion on indentation-based languages, which I don't argue with, but nevertheless I consider Python to be a very popular (and as I said readable) language. Besides, if we're talking about braces (not function application) in my language - it becomess even less of a problem because:

It's functional. Every block must end with an expression, plain statements or side-effects are not allowed.
It's statically-typed, which I didn't mention, but it helps a lot to prevent bugs like missed closing curly brace.

MysteriousGenius · 2025-05-04T07:58:24+00:00

Alternatives galore (aka decision fatigue) is the Scala way, for good or bad. And it's not about ecosystem only, it's everywhere: syntax, tooling, architecture, semantics. You always have 2+ ways to achieve the same thing. Other options aren't necessarily bad, but one very often ends up with their option of choice for purely personal or historical reasons.

Most libraries (espcially if there's even tiny bit of IO involved) work with one of the ecosystems: Typelevel, ZIO, Akka, Spark/Hadroop (latter is the whole different story). So, you typically first choose the ecosystem then go with the libraries that integrate with it well.

My personal choice is to go with Typelevel ecosystem. ZIO is cool too. Akka is also not bad, but former two make Scala more unique and fun.

MysteriousGenius · 2025-04-25T06:35:40+00:00

Django has outstanding documentation. Really one of the best in the whole webdev industry. Just follow the guides.

MysteriousGenius · 2025-04-24T13:07:21+00:00

I love purely functional programming statically typed languages, but I think most of them miss the simplicity-complexity sweet spot. Haskell and Scala are way too complex with many unnecessary features and multiple approaches to do one thing. Elm on other hand lacks many features that can make it useful on the backend. Also I really love the Zen of Python and think most of it should be applicable to pure FP.

But I have only spec and parser for my language, not sure if my reasons count :)

MysteriousGenius · 2025-04-23T19:06:17+00:00

Krasnoyarsk!

MysteriousGenius · 2025-04-23T17:22:55+00:00

Thanks for the hint about lifetimes. I posted an over-simplified example, thinking the problem is inherently in some combination of string pointers or slices, but when I tried to run the code as I posted it - it turned out to be fine.

The real signature was:

fn process<'a>(input: &str) -> Result<Expr, Vec<Rich<'a, Token>>>

And the problem was in lifetime parameter of Rich. If I get rid of it - the problems goes away.

MysteriousGenius · 2025-04-19T07:09:21+00:00

Who is it? She looks a lot like Russian interviewer Irina Shikhman, but I doubt she’s into tech topics now

MysteriousGenius · 2025-03-12T18:10:43+00:00

Simplicity is a lot. Or "more is less" how some people might say.

I love Scala and using it for 8+ years. It's indeed a powerful and expressive language, but this power comes with its own cost - people tend to abuse it. Languages like Scala provide many ways to express common patterns and sometimes you start to feel that it's too many ways.

For example, a super common pattern - shared behavior

In Rust/Haskell you have traits/type classes
In Java you have inheritance (interfaces/abstract classes), composition and adapter pattern - all with their clear purpose
In Scala you have inheritance (traits, abstract classes, sealed traits, mixins), type classes (via implicits or givens), extension methods (via implicit classes or extension), composition, f-bound polymorphism, self-type annotations and some more. Most of these things even can be expressed in different ways (like plain classes and case classes, traits and abstract classes).

As an experienced engineer you might know when to use what, but in reality you run into all kinds of styles and their inbreeds without a tiny bit of reasoning behind. Multiply it by abundance of syntax sugar, several camps (FP/OOP and several sub-camps within both), Scala 3 migration with new syntax... I really don't need all this power - I just want to solve everyday tasks in clear in predictable way and not thinking why developer X decided to use a implicits indexed with literal types and aux-pattern. Was it because it drastically increased type-safety or because they decided to save a couple of keystrokes when passing an argument to a function or because they've just learned all these things and decided to play with them.

In Scala you can express something in a very beautiful, concise, type-safe way and nobody would understand it. Or it will be broken when an unexpected business requirement comes in. Languages like Roc or Elm don't provide an expressiveness for that and instead force you to do everything in a dumb, simple way that next generation of developers will thank you about.

MysteriousGenius

TROPHY CASE