I appreciate somebody trying to connect disparate concepts to give both some kind of fresh perspective; perfectly happy to entertain analogies that break down if you look at them too hard... but like somebody else said, this reads like a draft or a foreword. Also, what about any of this is "zen"? This goes nowhere and has no connection with the concepts put forward in the title. Chucking "the zen of" in front of anything for no reason was tired 10 years ago, yet people keep doing it. We get it, you've heard of the book.
The Zen of Parallel Programming
21–30 of 50 posts
Re: The Zen of Parallel Programming
#22I cannot make sense of a single word of this essay. What sort of insight am I missing? There's not a peep here about write barriers, futexes, OS schedulers, critical paths and/or how they relate to Zen or whatever. This article can be easily recycled as the Zen of compiler design or Zen of audio engineering or whatever, without substantially having to chance much of the words, thats how generic it is. I'm genuinely c…
There is no substance. It's navel-gazing dribble.
The "about" section of the website is equally vacuous:
SmolNero is a philosophical startup rooted
in first-principles thinking.
We explore how humans relate to technology—
how we speak to it, depend on it, thank it,
and sometimes forget it’s there at all.
We don’t claim expertise. We see ourselves
as translators—working at the crossroads of
emotion and programming, curiosity and care
Re: The Zen of Parallel Programming
#23[flagged]
Re: The Zen of Parallel Programming
#24[flagged]
Re: The Zen of Parallel Programming
#25I cannot make sense of a single word of this essay. What sort of insight am I missing? There's not a peep here about write barriers, futexes, OS schedulers, critical paths and/or how they relate to Zen or whatever. This article can be easily recycled as the Zen of compiler design or Zen of audio engineering or whatever, without substantially having to chance much of the words, thats how generic it is. I'm genuinely c…
There is no substance. It's navel-gazing dribble. The "about" section of the website is equally vacuous: SmolNero is a philosophical startup rooted in first-principles thinking. We explore how humans relate to technology— how we speak to it, depend on it, thank it, and sometimes forget it’s there at all. We don’t claim expertise. We see ourselves as translators—working at the crossroads of emotion and programming, cu…
There have always been snake oil salesmen, for awhile they had to put the effort into knocking on your door peddling MLMs, now they're making more impressive snake oil, but vacuous, with LLMs.
Re: The Zen of Parallel Programming
#26Aside from the sentence "How many experiences continue to consume us because they were never allowed to finish burning?", I'm not sure what to make of this article. But the book it mentions, "Zen Mind, Beginner's Mind", seems worth taking a look at (an older one, not a promotion).
Re: The Zen of Parallel Programming
#27It’s true that “zen of” is bolted onto many topics… it’s a tired cliche to suggest “simplicity” when things are complex. Does it help or is it faux spirituality?
I’ve enjoyed reading the comments here and I think there’s truth in how the technical problem is divided and teams are arranged. The idea of frequency of features (or builds) being a reflection of our division of the problem, is interesting. It made me think about our teams trying to ship releases and the problems arising, but zen and parallelism don’t give any hints. It’s just about effort to organise better, like it always was
Re: The Zen of Parallel Programming
#28[deleted]
Re: The Zen of Parallel Programming
#29Fred Brooks and the mythical man month observed that communication between people expands faster than linear, and that adding more people to a project makes it later.
[deleted]
Re: The Zen of Parallel Programming
#30Fred Brooks and the mythical man month observed that communication between people expands faster than linear, and that adding more people to a project makes it later.
Amdahl's law says something similar, adding more processors to a problem eventually gives almost no speedup because parts of the problem cannot be parallelized and need to be done sequentially.
To the people wondering the meaning of the article, it's I think this.