They're not claiming bun is faster to start, only that for use cases where you might otherwise need to shell out hundreds of times bun only needs to start once.
Most of the words I "know" from the female list are ones I've encountered in articles or novels that I didn't need to look up to get the gist of what I was reading. Same for a few on the male list, I've never needed to do anything with a thermistor or servo so I can only assume I recognise those words from SF.
Slippery slope arguments aren't inherently fallacious. If you can justify one more climb on the grounds that probability of injury or death is very low then you will be able to justify every subsequent climb on the same basis.
Slippery slope arguments are inherently fallacies. They don't prove that something will happen.
Just because you can justify the next climb on the same basis, that doesn't mean you will. You could decide that you've already tested the odds one too many times.
Don't get on that greased sliding board that ends at the top of a cliff. Once you start sliding, it will be hard to stop because of the grease, and then once you slide off then end you will fall and die.
Do you really think this slippery slope argument is a fallacy? FWIW, wikipedia acknowledges slippery slope can be a legit argument when the slope, and it's chain of consequences, are actually real. https://en.m.wikipedia.org/wiki/Slippery_slope . Indeed, this is the very basis of mathematical induction.
> The fallacious sense of "slippery slope" is often used synonymously with continuum fallacy, in that it ignores the possibility of middle ground and assumes a discrete transition from category A to category B. In this sense, it constitutes an informal fallacy.
"If you take N steps, you will take N+1 steps" is a fallacy whenever it's possible that you won't take N+1 steps.
"You could decide that you've already tested the odds one too many times" was the original point. Someone responded that the N previous times don't matter and N + 1 has barely any risk. Another poster countered that that argument as stated applies not just for N + 1 but for (N + 1) + 1 etc and therefore the slippery slope principle applies.
Of course if you add in "you could decide that you've already tested the odds one too many times" then it's a fallacy to invoke slippery slope because an off-ramp is explicitly specified. In this case slippery slope was mentioned only because N was dismissed as irrelevant.
There are currently two ways to sign up for the New York times online, one is via the website and the other is via a subscription from the various app stores(an in-app-purchase).
To unsubscribe from the website-based subscription requires a call to NYT’s customer service based in New York which have limited operating hours- here they’ll try their best to convince you not to unsubscribe after waiting in a phone queue.
However if you chose to subscribe through an IAP then you simply browse to your active subscriptions and press a button - far simpler and on par with how easy it was to sign up.
Making subscriptions difficult to cancel is not new in any industry, NYT’s behaviour here isn’t unique, or even the worst example. I use it as a demonstration that even reputable companies use these tactics.
This is one of the reasons why certain businesses loathe IAPs, (regardless of the cost). When providing your details to a business there is a lot of added potential for lock in, follow-on marketing, increasing the cost at irregular intervals and selling your information to 3rd parties.
I say "regardless of the cost" because many types of digital goods have minimal costs to provide them. For example a 15% or 30% cut of such purchases is negligible when selling an in-game currency because there is no genuine cost for providing that currency. Even if the app store charged 0% instead of the 15% or 30%, the business would still be missing out on using your personal details for all of the other valuable ways they can extract money from you/your data.
To use Amazon as an example - I receive extreme levels of spam for the custom email address that I use with Amazon, many vendors I have purchased from have immediately on sold my contact information.
Thanks, it hadn't occurred to me that the app stores would enforce easy cancellation. I'll remember to prefer in-app sign up over website for any new subscriptions in future.
It’s best to check both options before proceeding, as some businesses do offer a cheaper subscription service when working directly - however as mentioned that may come with strings attached.
I feel the success of small developers relies on IAP, it means I can purchase from them without needing to trust them - the app stores do a good job of reviewing the app for malware and if the app doesn’t live up to expectations it is trivial to get a refund from the various app stores.
I got this error the first time but worked fine on subsequent refreshes:
An AudioContext in a cross origin iframe must be created or resumed from a user gesture to enable audio output.
G.snd.init @ (index):98
init @ (index):464
I've used some very basic TXR for refactorings that were a bit beyond my IDE's capabilities, which gave me a taste of how powerful it could be. One thing that's slowed me down in experimenting with it is having to save the script, rerun TXR and refresh the output file each time I make a change. Do you have any tips for quickly and interactively building complex scripts?
Not in the TXR pattern language, I'm afraid! TXR Lisp has those interactive properties of just re-loading a module on-the-fly to redefine some functions without redefining the entire program, but the pattern language isn't interactive in that way.
This is from the ground up, pretty much, emanating from the way it is parsed in its entirety before being executed.
You can develop the logic in small pieces and test them in isolation on some sub-segment of the data, then integrate the pieces into a larger script with @(load ...).
Speaking of code refactorings, I also use it for that myself. When using it to interactively rewrite code, I invoke it in a pipeline out of vim. E.g. select some range of code visually with V, then "!txr script.txr -[Enter]" to filter it through. Vim deletes the original text and replaces it with the output. If the output is wrong, I hit u for undo to restore the original text. Then of course I have to fix script.txr and save it, and recall and repeat that filtering step just with ":[up arrow][Enter]".
To avoid refreshing the output file during development, don't have one; let it dump to standard output.
Something useful is that we can also monitor the first N lines of an output file that fit into the screen using the watch utility that is found in many GNU/Linux distros. Watch repeatedly executes some command that is given (once every 2.0 seconds by default) and splashes its output on a clear screen. If we "watch cat file", we can monitor the changing contents of file.
I didn't think of calling TXR from within vim, thanks I'll try that.
Watch could get me closer to the workflow I'm used to from web development where the browser auto-reloads whenever a change is made. Your mentioning vim (of which I'm not exactly a power user) actually prompted me to check if it had the ability to run a command on writing a buffer or to automatically reload a file when it changes. Turns out it does indeed have ways to do both these things, so that might be another way to achieve what I'm after.
An example of a more complex script is Tamarind: a CGI application in TXR which lets users log in with their IMAP/SASL credentials and edit their personal list of randomly generated throwaway e-mail aliases.
This is a CGI script that runs under Apache. It doesn't use any web framework; everything is there in the code: parsing URL parameters and form data, handling sessions and authentication, etc.
In early versions, I scanned the /etc/passwd file and authenticated users by doing raw crypt calls on the passwords. Then I upgraded to SASL authentication: sending tokens to "saslauthd" over Unix sockets. This is in
Then I added IMAP. That was an example of incremental development. I tested the IMAP code in isolation and then just planted it into auth.txr.
I was surprised because I was sure that would be done in Lisp; but the pattern language easily implements the IMAP conversation needed to authenticate.
I expected most of Tamarind to be Lisp; I'm surprised how much of it in general ended up TXR via a path of least resistance.
I actually tried running TXR from a Python web service so that I could work with it via a web interface, but running it with subprocess felt all wrong. It didn't occur to me to do it as CGI as it would have seemed far too ambitious for a beginner, but that looks surprisingly straightforward.
If appearing obviously fearful is enough to significantly increase the chances of people hassling you it's a pretty good indicator that you're in a bad part of town.
