bitcrafter

I would argue that everything is being named for what it is, it's just that the mathematical definitions underlying the types are sufficiently subtle that it is not easy to look at them and immediately make the connection between what you are seeing and why it works. (I personally had to study them for a while before really understanding what was going on.) Additionally, the lens package is arguably not the best entry point because it makes you learn both the basic concepts and a full batteries-included library for working with them in every conceivably way at the same time, which can be so overwhelming that it becomes impossible to learn either of these things.

The good news, though, is that the advantage of this style of lenses is that the types are inherently structural rather than nominal, which means that you can, for example, use the far simpler microlens package instead and still interoperate with code that uses the lens package.

I find it interesting that you are so passionate about elm. The impression that I got when I last played with it a few years ago is that it is a good introduction to functional program because it shows just how nice things can get when everything is pure, but that eventually one outgrows it and its simplicity feels far more constraining than useful. So the good news is that you never have to learn about things like lenses, but the bad news is that if you run into a problem that would be solved really well by them, then too bad. How much one cares about this kind of thing is a genuine matter of personal preference, though.

The reason why there are so many operators is because there is a scheme with three parts:

1. << to return the old value, < to return the new value, neither to not return any intermediate value
2. The operator to apply, e.g. +.
3. = to "mutate" inside a MonadState, ~ to do a pure computation

This is how you end up with so many operators. I get that this is not necessarily explained that well, though.

Also, as elegant as this style of lenses is, I agree that the types are a bit weird, which makes then a bit tricky to lean and also can result in unhelpful error messages, so your point is well taken there.

Sure, but the comment to which I replied made the specific claim that, if Rust had used Python-style layout, then there would have been no serious adoption, and that is what I was responding to.

It is a joke. Nobody serious actually expects you to know what this term means.

Lenses, by contrast, solve a practical problem that comes up in languages where everything is immutable when you really want to change something deeply nested in your data structure, so they are not nearly as obscure.

The context is that this entire post is essentially making fun of another post; follow the link to the original post on lemmy.world to see what I mean.

That's a fair point. I have learned so many programming languages and continue to enjoy learning about weird ones that these relatively minor syntax design decisions do not seem like they should be dealbreakers to me, but that likewise means that I am also not the one that they have to worry about appeasing when designing the syntax to attempt to maximize adoption.

Hi everyone, I really am glad to see that we have decided to create a whole thread to pick on that self-admitted Lemmy noob for asking a question--what a loser!!!

1. Fear of unfamiliar syntax. This is utterly bogus, but I can bet you that if rust used python style layout and haskell style type signatures, it would still be incredibly niche. Something can wipe the floor with the competition, be rock solid, stable and blazingly fast, but if it’s unfamiliar it will be niche. See elm for front end, for example.

But the weird thing to me is that Rust's syntax is also pretty ~~familiar~~ unfamiliar since it is (just to start) heavily inspired by ML. Does it really just come down to the fact that it has mandatory curly braces and semicolons? It just seems weird to me that this should be the sticking point for people.

Edit: Oops, wrote "familiar" when I meant "unfamiliar".

A lot of these operators are things like += and -=, though, which should not be too hard to remember if you are familiar with C-flavored languages.

Yeah, I had been willing to give the author the benefit of the doubt that this was all part of a big joke, until I saw that the rest of their blog postings are also just like this one.

What happens if you use an out of range array subscript a[n]? Does that always return an option type?

I think that you would be surprised by the amount you would learn if you spent five minutes actually trying to answer your own questions, instead of treating them as proof that you just made a relevant point merely by asking them.

My humanity.