We really don’t know that, they had terrible data reporting on drug use before the policy was implemented so we can’t even make a before/after comparison. We also can’t parse out the extent to which changes in drug use stats reflect changes in autopsies or in cultural attitudes and candor about drug use affecting self reports.
Code is more flexible than text for drafting the idea. Later on it will expand into a fully working solution. Defining non functional interface definitions and data objects for "scribbling" the use case works best for me.
> just to save a few characters and make everything more magic than it is
No, this is not the true motivation. Human attention spans on symbols, the more succinct the code is, the more meaning it can encompass in the same number of characters. Writing abstracted enough code often requires inventing new languages to hide the complexity behind abstractions.
Software development in Haskell is particularly focused on DSLs, lens language being one of them.
^.. is a relatively simple operator though, it just abstracts away traversals.
> Writing abstracted enough code often requires inventing new languages to hide the complexity behind abstractions.
Human attention may pick out symbols more easily, but human comprehension benefits from things that actually have meaning. Otherwise you end up with a soup of ASCII symbols that very few can parse since every library in Haskell seems hellbent on inventing new and useless ascii combinations for function names and operators.
Even the article goes (emphasis mine):
--- start quote ---
The basic operators here are ^., .~, and %~. If you’re not a fan of funny-looking operators, Control.Lens provides more helpfully-named functions called view, set, and over (a.k.a. mapping)
--- end quote ---
And then proceeds to use the ASCII soup instead of the more helpful function names.
It doesn't help in the least that there are multiple get operations ^. ^? ^.. Or this idiocy: "Here, a single < before the operator signifies that it returns the updated value, while a double << signifies that it returns the old value. This gets a little weird with the monoidal operator; <<>~ returns the updated value, not the old one". Bonus points. What does this do: <<<>~
Because "why have useful names when you can pretend your fake intellectual superiority by using confusing ascii symbol combinations"
> Software development in Haskell is particularly focused on DSLs, lens language being one of them.
The domain specific language for lenses is view, set, traverse, update etc. Not whatever this is.
> The domain specific language for lenses is view, set, traverse, update etc. Not whatever this is.
The word you are looking for is "script"; though that is rather ambiguous in the context of programming. I suppose "writing system" is good enough.
And now we have entirely expressed the problem: someone tried to make their code more readable by adding a donation-specific writing system! Just break out your handy Rosetta stone, and you'll be fine, right?
Yes and you tend to use ^. in Haskell where you'd use . in python, say. And . is also an operator. Similarly, you'd likely be using = in python where you'd use .~ in python. As for ^.., I'm not sure there's an idiomatic python equivalent - certainly nothing as simple as adding an extra . to the operator.
I don't understand why Perl is consistently dismissed as "line noise" and "write-only" but that characterization's rarely leveled against Haskell. It's much worse about it, IMO. At least the "line noise" variety of Perl doesn't usually dominate basic tutorials and introductions to the language.
[EDIT] Nor do Perl libraries tend to contribute to or encourage line-noise style.
I agree that FP languages sometimes exaggerate with the opeators (I think introducing new operators has its uses but the learning curve has to be traded off against the supposed benefits), but...
Perl is IMHO worse because it relies much more on global mutable context. For example, the diamond operator <> behaves differently depending on whether the magic global variable @ARGV is set.
By contrast, Haskell is typed and purely expression based, so that at least in principle you can pull apart expressions, examine them (and test them!) individually and then understand how they combine.
I kind of see idioms like lenses as part of the language.
But the language allows defining your own (infix) operators, so the core language designers weren't entirely innocent either. The abundance of custom operators in Haskell kind of made me appreciate Lisp and Forth a little more!
There are of course many good things about having your language designed by mathematicians, too.
I can confirm that: cloud helps to evade the incompetent sales and infrastructure teams in many companies. Saving money never works once your product scales out.
reply