Far be it from me to get in the way of someone protesting megabank centralization, but...
I have to imagine that this bank relationship will be different from those previous acquisitions? I never interacted with Goldman Sachs for the duration I've had my Apple Card—the relationship is entirely with Apple and their iOS app. I don't imagine that to be much different when Chase is the issuer.
I have a couple store brand cards backed by Chase (like the Amazon one) and they are basically exactly like any other first party Chase card. They show up on the Chase dashboard. You call Chase customer service for issues. Payments happen through Chase. The card benefits are all provided by Chase. The only difference is that there's Amazon printed in front and the points the card earns aren't regular Chase points. Of course their relationship with Apple could be different, but I doubt it'll be anything like the Goldman one. Remember that Goldman didn't have a consumer business at all before they got into the partnership.
"Of course their relationship with Apple could be different, but I doubt it'll be anything like the Goldman one" I can nearly guarantee this is completely wrong. It will be just like Goldman. That's literally the point of getting the card, is do everything through Apple and Goldman is just the backbone and support (through Apple's UI). Apple's contract with Goldman was until 2030, they wouldn't let Goldman out of it unless they were able to find a new partner with same or better experience and terms. They could have choose Synchrony, etc if Chase didn't agree. And clearly Chase was willing to concede to Apple since they don't even offer high yield savings, but agreed to for Apple since thats part of their existing offerings. Right now Apple decides the Promos for Apple Card, and at most maybe Chase will have a little more involvement in those but probably not. So in realty the only real world change is probably better customer support than Sachs, and Chase may not offer higher risks customers credit or as much like Goldman did and finally they may not offer the very low APR's that Apple card is known for, for it's best customers.
AFAIK in the current setup, only the UI is Apple's; any time you message customer service or open a dispute, that is handled directly by
Goldman employees, and decisions to raise/lower your credit limit are also made by Goldman. All of those parts will be handled by Chase now.
Have to disagree there. While the iOS wallet apple is all apple and thats what you will use for checking your statements and making payments which is great. But anytime I have to actually interact with for support that is 100% with Goldman. When you do you support through the iMessage chat feature it's all Goldman on the other end, not Apple at all. And I've had to deal with them far too many times, and each time was absolutely terrible. Because of Goldman but also because of the platform Apple gives them for support, since you send a message have to wait for a text response. So feels like a chat but unlike a chat responses can take a while more like email, but then if they respond and you dont respond very fast then it closes it out and your response triggers a how can we help and you start all over, which is unlike email. So it's the worst of Chat and the worst of Email. Hopefully that is revamped with the new relationship. And if you have to call you get Sachs not Apple. Chase isn't great but expect much better than Sachs.
My problem with Chase and PNC is that their "fraud detection" seems to be random die rolls or monkeys throwing darts at my picture on a wall. I love the 5 minutes of anxiety after each and every purchase where I wonder if it will just randomly fail.
Does that mean that this new partnership will be better because Chase is better at consumer banking than Goldman Sachs, or Chase negotiated a deal that will not cause them to lose a lot of money?
If it's the latter, does that mean that the card rewards for Apple Card will get worse?
> If it's the latter, does that mean that the card rewards for Apple Card will get worse?
Can it really get worse? All they do is a 2% cash back if you use Apple Pay, and 1% if you use the physical card. Ok if you buy directly from Apple it’s 3% back but that’s hardly “good” - you get a couple of bucks for buying an AirPod.
> Does that mean that this new partnership will be better because Chase is better at consumer banking than Goldman Sachs, or Chase negotiated a deal that will not cause them to lose a lot of money?
The partnership between Apple and Chase is not new, even though this particular credit card product offering is. There is another quite popular form of payment Apple has supported for years which necessitated this partnership to be established.
> does that mean that the card rewards for Apple Card will get worse?
the card rewards for AC were pretty awful in the first place. It's only useful as a store card that offers 0% financing.
the deal is probably more in favor of chase when it comes to the fee schedule and various issuing bank and interchange fees (ie, the ~2-3% that card networks charge to merchants)
I have a single line in my config[1] which binds s to back-scroll, so that d and s are right next to each other and I can quickly page up/down with one hand.
If you’re on macOS, you may not be able to use this unless you install less from Homebrew, or otherwise replace the default less.[2]
What’s the approach to embedding fonts in standard ebooks’ epubs? Curious whether there’s a set of fonts that producers are allowed to embed in finished books, or whether there’s project consciously avoids embedding fonts, and if so why.
I tried to find a policy page on this via a standardebooks.org site search but nothing looked relevant.
I’m asking after realizing that some of my favorite books were books where the ebook had intentional font choices, for example different fonts for chapter titles vs body text, fonts that matched the vibe of the book (historical, more modern, etc.) It would be nice if more ebook readers made it easy to import more than the ~8 fonts they include by default but the next best thing is when the book itself includes a great font.
The ebooks we produce are entirely in the US public domain, including metadata and any other files. Unfortunately there are basically no good fonts released under the CC0 license. (Most open fonts are released under the OFL license, which is not the same.) Therefore we don't embed any font files, except for Standard Blackletter[1] when necessary, which is a font we developed especially for our use based on public domain specimens, and released via the CC0 license.
For another perspective on "lying to the compiler," I enjoyed the section on Loopholes in Niklaus Wirth's "Good Ideas, Through the Looking Glass"[1]. An excerpt:
Experience showed that normal users will not shy away from using the loophole, but rather enthusiastically grab on to it as a wonderful feature that they use wherever possible. This is particularly so if manuals caution against its use.
[...]
The presence of a loophole facility usually points to a deficiency in the language proper, revealing that certain things could not be expressed.
Wirth's use of loophole most closely aligns with the unchecked casts that the article uses. I don't think exceptions amount to lying to the compiler. They amount more to assuming for sake of contradiction, which is not quite lying (e.g., AFSOC is a valid proof technique, but proofs can be wrong). Null as a form of lying is not the fault of the programmer, that's more the fault of the language, so again doesn't feel like lying.
I have maintained a pandoc filter in Haskell for a while. Pandoc is written in Haskell, and so takes a similar approach: JSON API for arbitrary languages, but with a library for trivially parsing that JSON back into the same Haskell datatype that Pandoc uses under the hood.
When you sit down to write the filter for the first time, it’s amazing. You’re using a typed IR that’s well documented, a language that catches you when you’re making mistakes, etc. You have to do very little boring grunt work and focus only on what the filter needs to do.
Over time, the filter became feature complete, so I didn’t want to have to touch it anymore, but the library for parsing JSON releases a new version for every new feature in the AST, and the parsing function checks that the version your filter was compiled with is at least as new as the pandoc that produced the JSON. It has to, because if the pandoc is newer, your older filter won’t know how to parse some of the nodes.
My filter is feature complete, and shouldn’t need to look at those nodes or their new fields: needing to upgrade is just toil. But over time, pandoc releases new versions, and I’d need to recompile the filter to build the new version. At those points, I also found myself having to deal with library, build tool, OS, or compiler upgrades, all to recompile a filter that should need to be.
Eventually I switched to Pandoc lua filters, which eliminated the toil while also being platform agnostic (and not requiring any sort of notarization or executable quarantine on enterprise systems) at the expense of having to tolerate Lua the language. Now, new versions of Pandoc don’t require me to boop a version number in my filter. If that wasn’t an option, for any future filters I write, I’d write my own JSON parser that only parses as much of the JSON as I needed, leaving the rest untouched—that way it wouldn’t matter if new changes came along. I could even tolerate backwards incompatible changes as long as they didn’t alter the contract of the narrow focus of that one filter!
There are of course other ways to deal with problems like these (protocol buffers, JSON parsing with an option to throw away unrecognized JSON, etc. etc.)
I have not looked at how mdBook plugins handle this. But if I were writing such a plugin, it’s the first thing I’d look at, and be sure to program around.
Mdbook passes a version and the renderer/preprocessor can/should do a version check. Since it uses semantic versioning I would expect it to abide by those rules.
It's an interesting approach. From my skim, the way it works:
1. Parse the files with a Ruby parser, collect all method definition nodes
2. Using location information in the parsed AST, and the source text of the that was parsed, splice the parameters into two lambda expressions, like this[1]:
"-> (#{method_node.parameters.slice}) {}"
3. Evaluate the first lambda. This lets you reflect on `lambda.parameters`, which will tell you the parameter names and whether they're required at runtime, not just statically
4. In the body of the second lambda, use the `lambda.parameters` of the first lambda in combination with `binding.get_local_variable(param_name)`. This allows you to get the runtime value of the statically-parsed default parameters.
This is an interesting and ambitious architecture.
I had though in the past about how you might be able to get such a syntax to work in pure Ruby, but gave up because there is no built-in reflection API to get the parameter default values—the `Method#parameters` and `UnboundMethod#parameters` methods only give you the names of the parameters and whether they are optional or required, not their default values if they are optional.
This approach, being powered by `binding` and string splicing, suffers from problems where a name like `String` might mean `::String` in one context, or `OuterClass::String` in another context. For example:
class MyClass
include LowType
class String; end
def say_hello(greeting: String); end
end
MyClass.new.say_hello(greeting: "hello")
This program does not raise an exception when run, despite not passing a `MyClass::String` instance to `say_hello`. The current implementation evaluates the spliced method parameters in the context of a `binding` inside its internal plumbing, not a binding tied to the definition of the `say_hello` method.
An author could correct this by fully-qualifying the constant:
class MyClass
include LowType
class String; end
def say_hello(greeting: MyClass::String); end
end
MyClass.new.say_hello(greeting: "hello") # => ArgumentTypeError
and you could imagine a Rubocop linter rule saying "you must use absolutely qualified constant references like `::MyClass::String` in all type annotations" to prevent a problem like this from happening if there does not end up being a way to solve it in the implementation.
Anyways, overall:
- I'm very impressed by the ingenuity of the approach
- I'm glad to see more interest in types in Ruby, both for runtime type checking and syntax explorations for type annotations
> how you might be able to get such a syntax to work in pure Ruby, but gave up because there is no built-in reflection API to get the parameter default values
> as opposed to whether the construct is allowed/part of the language
Arguably this is also semantics. Type checking and reporting type errors decides whether a construct is allowed or not, yet belongs squarely in the semantic analysis phase of a language (as opposed to the syntactic analysis phase).
> how it differs from syntax
Consider a language like C, which allows code like this:
if (condition) {
doWhenTrue();
}
And consider a language like Python, which allows code like this:
if condition:
doWhenTrue()
The syntax and the semantics are both different here.
The syntax is different: C requires parens around the condition, allows curly braces around the body, and requires `;` at the end of statements. Python allows but does not require parens around the condition, requires a `:`, requires indenting the body, and does not allow a `;` at the end of statements.
Also, the semantics are different: in C, `doWhenTrue()` only executes if `condition` either is a non-zero integer, or can be implicitly coerced to a non-zero integer.
In Python, `doWhenTrue` executes if `condition` is "truthy," which is defined as whether calling `condition.__bool__()` returns `True`. Values like `True`, non-zero numbers, non-empty containers, etc. are all truthy, which is far more values than in C.
But you could imagine a dialect of Python that used the exact same syntax from C, but the semantics from Python. e.g., a language where
if (condition) {
doWhenTrue();
}
has the exact same meaning as the Python snippet above: that `doWhenTrue()` executes when `condition` is truthy, according to some internal `__bool__()` method.
reply