Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Religious and spiritual folklore surrounding programming

deusinmachina.net

Post reply on HN
Print view View original

91–100 of 122 posts

Re: Religious and spiritual folklore surrounding programming

#91

Post by posix86 »

dale_glass wrote: post #36
yjftsjthsd-h wrote: post #26

Earlier quoted context omitted.

> Things like GPG I, for one, would very much prefer GPG to be decomposed to follow the unix philosophy - I think I would have a much easier time understanding and composing commands like `gpg-sign --keyfile ~/mykeyfile somefile | gpg-encrypt --to ~/someperson.pub | gpg-asciiarmor > somefile.gpg` than whatever the monolithic incantation is. This would make it much less painful to interact with, especially because GPG…

And that'd be awful for many use cases, because maximizing that would make it incredibly unwieldy and brittle. For instance if you want to deal with keyrings, and be fully philosophy compliant, then that might be a gpg-keyring tool, which means now we have a problem. A signature operates on both a key and a file, and a pipe only works on one stream. Then there's the issue with error handling, since any of those bits…

You're still on the text streams!!

Re: Religious and spiritual folklore surrounding programming

#92

Post by flippinburgers »

raphlinus wrote: post #33

A lot of the cultural phenomena around Rust can best be explained in religious terms. It's no accident that we are sometimes referred to as the "Rust Evangelism Strike Force," and the word "zealot" is frequently used, of course largely by critics. There's a deeper level as well. The concept of "memory safety" which is a core principle of Rust has, I believe, a lot in common with religious concepts of purity and clean…

I'm pretty confident that the desire to be clean is not restricted to religious zealotry.

Re: Religious and spiritual folklore surrounding programming

#93

Post by ajuc »

pjmlp wrote: post #88
ajuc wrote: post #23

Earlier quoted context omitted.

I much prefer Unix philosophy to contenerized microservices for Todo list app philosophy.

Microservices is UNIX philosophy of multiprocessing and IPC taken to the network level. Sun Microsystems business quote on their manuals, "The network is the computer". Then again, besides being a famous book quote, most commercial UNIXes never cared about such philosophy.

Engineering is all about trade-offs, and taking good trade-offs to the next level usually makes them bad. This is a prime example.

Re: Religious and spiritual folklore surrounding programming

#94

Post by JonChesterfield »

slavik81 wrote: post #74

> Not everyone agrees to who belongs in the pantheon, but for them there are fictional hackers, like Mel Mel wasn't fictional. Melvin Kaye was an application programmer at Librascope, and there's a photo of him in the company newsletter. https://www.freecodecamp.org/news/macho-programmers-drum-mem...

There was quite a long period where he was known to be fictional though, probably including when the OP was written. Which if anything makes listing Mel within the pantheon more appropriate.

Re: Religious and spiritual folklore surrounding programming

#95

Post by JonChesterfield »

stared wrote: post #14

It reminds me of "If Programming Languages were Religions" (2008), http://kokizzu.blogspot.com/2015/02/if-programming-languages... I think it deserves and update - 15 years is quite some time.

Referenced under that is the claim:

> most popular modern languages are incomplete subsets of it that obsess over artificial restrictions of their own creation

which honestly hits a bit close to home

Re: Religious and spiritual folklore surrounding programming

#96

Post by JonChesterfield »

praptak wrote: post #83

My closest to religious experience was a C program crashing after removing an unused variable. I repeated this and tested multiple times by adding and removing the variable and running the program. Now I obviously have a believable rational hypothesis for that behaviour but then it was mystical. I left the variable and got a passing grade (it was a student program).

Deleting a dead function won me a segfault in the last year or so. That turned out to be an oddity related to shared libraries.

Re: Religious and spiritual folklore surrounding programming

#97

Post by JonChesterfield »

Quarrelsome wrote: post #56

Somewhat off-topic question: if I wanted to try to re-interpret assembly as a religion (i.e. knowledge left for us by our creator as opposed to a programming language for a technology we understand); which book about assembly would be most appropriate to choose as the core holy text?

That's a tricky one because there is no "assembly language", so much as N different ways of mapping text onto numbers that a processor can interpret.

First the target instruction set changes. You may have a `mov` for copying between registers but you may not. For that matter, you may not have registers. You probably can write raw bytes in the middle of an instruction stream for instructions that the assembler doesn't know about, and if you wrote the entire program like that, you'd (almost) have the binary itself.

Then there are common conventions like `label:` and being able to write basic arithmetic in a place that an instruction expects an immediate operand, but they're at the whim of whoever wrote the assembler. There's probably a macro layer or two.

There is a strong analogy remaining though. Some creator gave us the processor, with documentation of some quality about how to make the piece of sand do anything, and on top of that someone (who may have been the same creator but may not) usually writes mnemonics for the instruction set and from that, an assembler.

The core holy text for a given processor is then something like https://developer.amd.com/wp-content/resources/Vega_Shader_I... - an incomplete description of what the magic sand does, from which one who is sufficiently determined can construct arbitrary computation.

Re: Religious and spiritual folklore surrounding programming

#98

Post by stared »

raphlinus wrote: post #33

A lot of the cultural phenomena around Rust can best be explained in religious terms. It's no accident that we are sometimes referred to as the "Rust Evangelism Strike Force," and the word "zealot" is frequently used, of course largely by critics. There's a deeper level as well. The concept of "memory safety" which is a core principle of Rust has, I believe, a lot in common with religious concepts of purity and clean…

Once I saw the light of Rust, I understood that it is the one true programming language.

There are pieces of wisdom in low-level languages, script languages, and functional languages. But after seeing Rust, one knows that there are only fragments of something greater.

I am a sinner, though. Even after I saw Rust, I still write mostly in Python and TypeScript. Out of convenience, out of habit, by social pressure.

Re: Religious and spiritual folklore surrounding programming

#99

Post by klankbrouwerij »

joeman1000 wrote: post #30

Great post, but I don't think the author really knows what 'flamer' means when he uses it to describe Linus Torvalds

For those who are missing some context, a flamer can also mean a very flamboyant ("flaming"), effeminate gay male [1].

[1] https://en.wiktionary.org/wiki/flamer

Re: Religious and spiritual folklore surrounding programming

#100

Post by mark_undoio »

praptak wrote: post #83

My closest to religious experience was a C program crashing after removing an unused variable. I repeated this and tested multiple times by adding and removing the variable and running the program. Now I obviously have a believable rational hypothesis for that behaviour but then it was mystical. I left the variable and got a passing grade (it was a student program).

Computers are extremely haunted. It's often remarkably they were working at all before you made the change, then you prod and all the goblins come out.

Similar experiences I've had:

* Putting a big array on a stack (early in C programming career) - compiles fine, instant crash at runtime.

* Colleague discovers that a function needs padding with NOPs to achieve precise timing. Number of NOPs needed varies depending on code changes (even NOPs added or removed) in functions higher up the same source file.

* Occasional crashes in low level routines on ARM64 after changing completely unrelated code. The stack appears to contain a struct from elsewhere in memory instead of ... a stack.

(First one was probably just the array was too big for sensible stack management/ growth and a friendlier compiler would have just told me. Second one was to do with the size of memory pages in the flash - there was a delay if you ran over a boundary. Third one was, IIRC, the variable containing the base of a temporary stack occasionally getting splattered to point into other data structures! The actual stack was fine but you couldn't see it anymore)

Post reply on HN