rot13 hint, pretty involved hint that doesn't literally say the answer but is one step away
lbh ner ba gur evtug genpx gung vg vaibyirf fraqvat na rznvy, Cv (fcrpvsvpnyyl gur cerpvfvba bs Cv cebivqrq), naq urknqrpvzny ahzoref. lbh ner hasbeghangryl qbvat gur rapbqvat vapbeerpgyl, V jbhyq gel qbvat vg gur jnl n crefba jub qbrfa'g xabj nalguvat nobhg ahzoref, onfrf, sybngvat cbvag, rgp jbhyq qb vg. vg'f abg n "pyrire" fbyhgvba.
Thanks so much for this. I was also beating my head against the wall over-nerding the correct idea. This gave me what I needed and didn't really add any spoilers beyond the ones contained in the post above.
10 was difficult in a different way than the prior puzzles, and honestly was a little chilling once I figured it out. Good luck, I'm sure you can get it!
vg'f abg pyrne jung gur nqqerff vf, be jung gb fraq... (V'z thrffvat whfg "uv" sebz gur HEY...? Be gb qb jvgu gur urk pbybef bs gur qrfnghengrq vzntr..?)
Edit: oh, hah. Got it. I somehow missed trying the right thing. I had gotten very close before, I just needed to add in the other hint.
I love the 38” 1600p format so much, it’s both wide and tall while still feeling like it’s a single monitor. I’ve heard though from friends in the industry that it’s not long for this world :(
I recently spent a few days working in front of two 27" QHD monitors. It made me realise how often I have three windows side by side (working doc in the middle, reference materials to the side).
In the US anyway, they're legally required to give you your prescription (SPH, CYL, prism, etc). However, PD and other ocular measurements aren't classified as part of a prescription.
I don't have a ton of Xcode experience, but from what I've touched, while it does feel good to use in terms of a "native" experience, as an IDE it feels lacking. Even basic things like the text editing experience feels limited compared to other IDEs (e.g. why is there still no auto-formatting built in? why can't I duplicate a line without having to use pseudo-Emacs movements?)
You only see the colors on messages you send. OP is implying that you wouldn’t know what “color” the conversation is unless you’re actively replying to the spammer.
You can still tell whether it is an iMessage or text message without replying and observing the color. Long-press on the incoming message. If the menu shows: Reply, Copy, Translate, More… then it is an iMessage. If the menu shows: Copy, Translate, More… then it is a text.
That's cool, didn't know that Apple didn't try to somehow shoehorn threads into SMS (like they currently do extremely poorly with tapbacks and stickers)
I want to note that Vue provides official instructions on how to use it without build tools [1], and lots of folks who have written posts on how to use React without tooling as well [2]. I agree that they're ultimately designed to be used with tooling, but it's not a blanket requirement.
What about Rust? Rust doesn’t go as in-depth as Haskell when it comes to modeling effects in the type system, but it still has a relatively complex type system on top of dealing with the borrow checker (which is almost as joked about as Monads at this point). Even with that difficulty, Rust seems to be a lot more successful than Haskell, and has existed for far less time.
If it’s because Rust is still mostly imperative, then you could look to Clojure or even Scala—less complicated when it comes to types, but also (usually) much less imperative. Both I feel are more popular than Haskell.
I was thinking about Rust a lot when I wrote this comment, actually.
IMO, imperative vs. functional aside, Rust does suffer from a lot of the same learning curve issues people commonly pin on Haskell. Rust has plenty of libraries with weird, excessively "clever" APIs, weird experimental language features, a complicated metaprogramming facility, and so on. Personally, I have found lifetimes in Rust more annoying to deal with in semi-nontrivial situations than anything I ever encountered in Haskell, and it doesn't help that things that seem like they should work often don't.
(I always figure that's the language telling me that I should use a different memory management strategy, and I generally follow its advice, but I digress.)
This is very much my opinion, but I'd attribute Rust's success over Haskell to three main points:
* Functional vs. imperative, skill curves. Rust is still vastly more familiar to most programmers at a first impression, and IMO it also has a lower skill floor.
* Rust's tooling feels a lot more modern and streamlined. `cargo` is a joy to use. Maybe Haskell's ecosystem has improved, but back when I was actively using it, it was clearly inferior to Rust's. For me, this manifested mainly in significantly greater difficulties managing dependencies and reproducing builds. This stuff is a first-class priority for the Rust team, and it shows.
* Somewhat related to the last point, Rust is "cool". It isn't burdened by decades of academic cruft; it just feels approachable, modern, and relevant in a way Haskell doesn't.
The last two points aren't really Haskell's fault. I think the Rust team has done an absolutely top-tier job of making the language approachable and usable, obviously building on lessons of the past (including Haskell, Stack, cabal, haddock, etc.) and I'd almost say it's succeeded despite the essential nature of the Rust language itself.
The difference is actually much more simple. Rust fills a gap, Haskell does not.
Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means. Lazy evaluation is actually a double edged sword so it's not a clear win either.
Rust on the other hand is adding safety and correctness assurance specifically without or with very little runtime overhead while providing very predictable performance (both in runtime and space).
You can sub Haskell out for Clojure/Scala/OCaml and arguably mixed paradigm languages like Kotlin/Rust/Swift and be fairly happy.
However if the constraints of your problem call for Rust then your only other real options are to sacrifice correctness/data safety and use C/C++ instead.
FWIW I think Haskell is awesome, this is just why I think we don't see it in "the real world' much.
For me the real selling point of Haskell is that it's vastly more powerful and ergonomic for solving certain kinds of problems, in ways other functional languages don't necessarily share. First-class currying, typeclasses, HKTs, do-notation and other features in that vein give Haskell code a level of effortless composability whose equal I haven't seen anywhere else, and the way pattern matching is built into every part of the language makes other languages' versions of it feel clumsy and primitive.
Back when I was fluent in it, I wouldn't reach for Haskell for functional purity or lazy evaluation---I'd reach for it because I wanted the richness and flexibility of its type system and pattern matching for building and manipulating a tricky data model, or because I was doing something involving tree-like linked structures and/or that lent itself well to recursion. Parsers are the obvious example, but they are a very narrow view of what Haskell excels at.
(In short, I'd reach for it for reasons that are basically impossible to explain to somebody who doesn't already know what I'm talking about.)
I can't be so effusive about Rust. It's a really great language with a thoughtful and restrained design, powerful and practical and flexible, but I would actually say the opposite re: filling gaps: Rust feels like more of an iterative improvement in the space occupied by C/C++/Go/etc., while Haskell is transcendently good for those classes of problem where it excels.
---
Today I'm more or less fluent in Rust after a few hours' warm-up, but it would take me days or weeks to warm up my Haskell. Why? Mostly because I've largely stopped programming for fun, and I use nothing like Haskell at work. Throw in the quality of Rust's tooling and the largely effortless reproducibility of its builds (great for warming up a 6+ month old project), and it's just a far more practical choice for the little hobby programming I do. Hence my earlier comment. But I still contend that Haskell has vast untapped potential, locked away behind an intractable adoption barrier. It's less that it has nothing new or useful to offer us, and more that we are unwilling to pay the price of admission.
> Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means.
Is the end result reached by other means the same? Can you give an example of a competing approach in a non-pure language that gives one Haskell's advantages?
I don't think the result is the same but it is comparable. I would say using any language with a reasonable type system, say Kotlin w/property based testing gets you a result that while not as good as Haskell w/quickcheck is "good enough" for practical use in production software.
There is maybe some niches where that wouldn't be the case like very high assurance software where instead of Haskell you might choose say ADA instead but I'm not really familiar with those domains.
Rust is doing well because it fills a usecase that has been crying out for a new solution for decades. Low level systems programming - kernels, microcontrollers, high performance applications - have basically had to be written in C or C++. Sure, under some circumstances people can get away with writing performance critical apps in other things, but you can't really write a real world OS kernel in anything else.
Rust brings a new set of tools and tricks and safety to an important use case that has had no movement for such a long time. The only real advancement has been smart pointers and "modern" C++, but while they are an improvement they also contribute to C++ being a bag of all the features.
I was keen to do a small project in Haskell. However I quickly found that the compiler gives cryptic errors. I am very capable of managing that (I have many years experience using a variety of old school compilers in the past), but I have no desire to repeat yet another compiler hell experience and waste my time fighting my tools, trying to diagnose where I have misunderstandings.
I haven’t yet tried programming rust, but I have read that error management and suggestions for correction in rust are superb. That makes a world of difference for a neophyte in a programming language.
lbh ner ba gur evtug genpx gung vg vaibyirf fraqvat na rznvy, Cv (fcrpvsvpnyyl gur cerpvfvba bs Cv cebivqrq), naq urknqrpvzny ahzoref. lbh ner hasbeghangryl qbvat gur rapbqvat vapbeerpgyl, V jbhyq gel qbvat vg gur jnl n crefba jub qbrfa'g xabj nalguvat nobhg ahzoref, onfrf, sybngvat cbvag, rgp jbhyq qb vg. vg'f abg n "pyrire" fbyhgvba.