According to Wikipedia, Biblical scholars essentially agree with you, to the point
Bible scholars even maintain that the Bible does not claim that masturbation would be sinful.
which is pretty cool especially given my prior belief that most people agreed it was about lust. Wikipedia does also say that some Christian denominations have interpreted the sin to be as lust, though.
And Catholicism, at least, still doesn't like the ejaculation without procreation:
Since, therefore, the conjugal act is destined primarily by nature for the begetting of children, those who in exercising it deliberately frustrate its natural power and purpose sin against nature and commit a deed which is shameful and intrinsically vicious.
Small wonder, therefore, if Holy Writ bears witness that the Divine Majesty regards with greatest detestation this horrible crime and at times has punished it with death. As St. Augustine notes, "Intercourse even with one's legitimate wife is unlawful and wicked where the conception of the offspring is prevented. Onan, the son of Juda, did this and the Lord killed him for it."
(number 54 and 55 in a Pope Pius XI encyclical)
(I never thought I'd be discussing religion on programming.dev lol)
I get your point, but considering that we got the word "Onanism" from the Bible I was thinking about some Christian denominations' views of why God wasn't happy with Onan in the Bible: because he ejaculated without trying to procreate. That is why I thought it was relevant to tie those two things together like that.
I figured it would look more professional, and it would also let me separate the contributions I made with my more anonymous GitHub out—not too sure how closely they investigate your previous contributions and how good your code was.
I am guessing this was not a good choice, and I should have just continued using my more anonymous GitHub, or made the account as JSmith instead of JaneSmith.
I figure it is called that because both the pull-out method and masturbation for penis-havers involves spilling your seed somewhere outside of a woman's womb.
oh god I always read JSON like "J" + "son", "son" being like a Spanish word for "to be". Or "J" + "sewn". I can't believe I've never read it like the human name "Jason".
you’re they type to micro commit
Thanks for a much shorter and better way to explain this tendency of mine and why I rebase a lot, yoinking this phrase.
I literally just posted this in !software_gore@programming.dev because they had the same energy so I found it on the original Reddit post remembered this one too. Great minds think alike?
"Dear Mr. Architect!" is such a charming start to the letter, sort of getting "kid's letter to Santa" vibes if the kid dreamed of being an architect.
Too bad the rest of the letter isn't quite as charming :P
Shamelessly stolen from a Reddit post that made me laugh when I randomly remembered it today. Figured it was worth reposting to Lemmy if I laughed upon remembering it and not just upon first sight.
Shamelessly stolen from a Reddit post that made me laugh when I randomly remembered it today. Figured it was worth reposting to Lemmy if I laughed upon remembering it and not just upon first sight.
- I can easily bend in half and reach past my toes, but this is another ask entirely.
- Even if I could do this, I don't have eyes in my back or a computer screen in my knees.
Thread can be read on this article.
YouTube page load is 5x slower in Firefox and Edge than in Chrome because YouTube's Polymer redesign relies on the deprecated Shadow DOM v0 API only implemented in Chrome. You can restore YouTube's faster pre-Polymer design with this Firefox extension: https://t.co/F5uEn3iMLR
— Chris Peterson (@cpeterso) July 24, 2018
According to that article,
Google Chrome ads started appearing next to Firefox search terms. Gmail & [Google] Docs started to experience selective performance issues and bugs on Firefox. Demo sites would falsely block Firefox as 'incompatible'
while Firefox was still a Google search partner.
EDIT: Did not realize how long ago this post was made, whoops.
Your comment made me curious, so I looked around the website and found this.
Our dataset documents Texas death row inmates executed from 1976, when the Supreme Court reinstated the death penalty, to the present.
On one level, the data is simply a part of a mundane programming book. On another, each row represents immense suffering, lives lost, and in some cases amazing redemption and acceptance. In preparing for this dataset, I was deeply moved by a number of the statements and found myself re-evaluting my position on capital punishment. I hope that as we examine the data, you too will contemplate the deeper issues at play.
Just a warning for folks who might not be in a good mental spot for seeing this in their SQL tutorial right now, or even just if it wouldn't be to your personal tastes. It's not your average school exercise but with morbid flavoring, the site really integrates its data. It provides a lot more information about capital punishment than you strictly need to solve the database problems. That works nicely with their intention of "Exercises should be realistic and substantial".
Likewise, the exercises here have been designed to introduce increasingly sophisticated SQL techniques while exploring the dataset in ways that people would actually be interested in.
The survey creator will not see your suggestion, because they are over on Reddit. OP just reposted this survey for the benefit of Fediverse users.
I'd understanding actively pressuring someone to share their salary being a faux-pas. Admittedly, just sharing your own may make some people feel pressured to share theirs out of reciprocity, but just sharing your own salary generates nowhere near the same amount of pressure as outright telling someone "share your salary or you're a bad person on the side of The Man!"
I hope the amount of people sharing their salary increases and talking about it becomes normalized.
Article text:
Taking baby steps helps us go faster.
Much has been written about this topic, but it comes up so often in pairing that I feel it’s worth repeating.
I’ll illustrate why with an example from a different domain: recording music. As an amateur guitar player, I attempt to make recorded music. Typically, what I do is throw together a skeleton for a song — the basic structure, the chord progressions, melody, and so on — using a single sequenced instrument, like a nice synth patch. That might take me an afternoon for a 5-minute piece of music.
Then I start working out guitar parts — if it’s going to be that style of arrangement — and begin recording them (musos usually call this “tracking”.)
Take a fiddly guitar solo, for example; a 16-bar solo might last 30 seconds at ~120 beats per minute. Easy, you might think to record it in one take. Well, not so much. I’m trying to get the best take possible because it’s metal and standards are high.
I might record the whole solo as one take, but it will take me several takes to get one I’m happy with. And even then, I might really like the performance on take #3 in the first 4 bars, and really like the last 4 bars of take #6, and be happy with the middle 8 from take #1. I can edit them together, it’s a doddle these days, to make one “super take” that’s a keeper.
Every take costs time: at least 30 seconds if I let my audio workstation software loop over those 16 bars writing a new take each time.
To get the takes I’m happy with, it cost me 6 x 30 seconds (3 minutes).
Now, imagine I recorded those takes in 4-bar sections. Each take would last 7.5 seconds. To get the first 4 bars so I’m happy with them, I would need 3 x 7.5 seconds (22.5 seconds). To get the last 4 bars, 6 x 7.5 seconds (45 seconds), and to get the middle 8, just 15 seconds.
So, recording it in 4 bar sections would cost me 1m 22.5 seconds.
Of course, there would be a bit of an overhead to doing smaller takes, but what I tend to find is that — overall — I get the performances I want sooner if I bite off smaller chunks.
A performance purist, of course, would insist that I record the whole thing in one take for every guitar part. And that’s essentially what playing live is. But playing live comes with its own overhead: rehearsal time. When I’m recording takes of guitar parts, I’m essentially also rehearsing them.
The line between rehearsal and performance has been blurred by modern digital recording technology. Having a multitrack studio in my home that I can spend as much time recording in as I want means that I don’t need to be rehearsed to within an inch of my life like we had to be back in the old days when studio time cost real money.
Indeed, the lines between composing, rehearsing, performing, and recording have been completely blurred. And this is much the same as in programming today.
Remember when compilers took ages? Some of us will even remember when compilers ran on big central computers, and you might have to wait 15–30 minutes to find out if your code was syntactically correct (let alone if it worked.)
Those bad old days go some way to explaining the need for much up-front effort in “getting it right”, and fuelled the artificial divide between “designing” and “coding” and “testing” that sadly persists in dev culture today.
The reality now is that I don’t have to go to some computer lab somewhere to book time on a central mainframe, any more than I have to go to a recording studio to book time with their sound engineer. I have unfettered access to the tools, and it costs me very little. So I can experiment. And that’s what programming (and recording music) essentially is, when all’s said and done: an experiment.
Everything we do is an experiment. And experiments can go wrong, so we may have to run them again. And again. And again. Until we get a result we’re happy with.
So biting off small chunks is vital if we’re to make an experimental approach — an iterative approach — work. Because bigger chunks mean longer cycles and longer cycles mean we either have to settle for less — okay, the first four bars aren’t that great, but it’s the least bad take of the 6 we had time for — or we have to spend more time to get enough iterations (movie directors call it “coverage”) to better ensure that we end up with enough of the good stuff.
This is why live performances generally don’t sound as polished as studio performances, and why software built in big chunks tends to take longer and/or not be as good.
In guitar, the more complex and challenging the music, the smaller the steps we should take. I could probably record a blues-rock number in much bigger takes because there’s less to get wrong. Likewise in software, the more there is that can go wrong, the better it is to take baby steps.
It’s a basic probability, really. Guessing a 4-digit number is an order of magnitude easier if we guess one digit at a time.
Source article for the curious, and an unpaywalled copy on archive.is
As much as I’d like to say this was done by a bot I made that pulls the article text, I (human) just manually copy/pasted it here.