Many an ISP these days blocks domains that have been registered less than a month ago because most scam campaigns have to cycle through domains way faster than that time.
Check if you have enabled some sort of "malware protection" at your ISP, because that usually is based on DNS filtering.
I _think_ what you’ve said is “go shallow, not deep”. That is, don’t let the walk you make inside the latent space a long one. Twenty-five short and peppered steps, from de novo, is better than one long, protracted stew.
Well, if it works on step one, then why not step two? Where would different folks draw the line? My grandparents might continue on a while, whereas I would not. But if it also “works” on step two for me, should I take a third?
What counts as “works” is the important bit, I think.
I think you and 7e are both right. Being able to iterate some N orders of magnitude quicker is a big deal. This doesn’t eliminate design and UX. Rather, it merges it with high iteration speed to produce a form of “play”.
“Play” is what produced at least two (likely more) generations of attentive (and therefore competent) programmers. The hype around LLMs is painful, yes, but attentive human minds will ultimately bust through it.
That is an absolutely lovely resource. Thanks for sharing! Concise, useful, references like this are great “core drills”[0] into the ever-expanding deluge of human knowledge.
Imagine your database is a sensor network instead of some schema-ful/typed data store. Field operators unbeholden to you keep adding, removing, or updating sensors. Your data format evolves underneath you, and you behave more like a magic carpet pilot than a builder of things unbreakable. You’re attempting to store the flight path as best as you can, update configurable sensors for the most profitable reads, but what you record is a direct reflection of the current sensors and their current settings.
I am wary of hastily agreeing that Dijkstra missed something. He may have been talking about specific, general purpose algorithms, which do not change much once conjured. There is another type of software, though, a software that sits atop the immutable spellcraft, a software that attempts to shake the boughs of profit trees at specific points and places in time and space.
Dijkstra says “Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs "because PASCAL was not maintained".”
The oil company folk are the kind who prefer tree-trembling to the deep and unchanging sea.
I, too, when cold and hugging uncertainty for warmth, prefer to cut down trees for fire than to spelunk for hard diamonds.
“…we aren’t yet good at thinking about the intended lifetime of a software system when we’re designing it.”
And sometimes the life expectancy is so short that any old (or new) design will do.
Some software is made to solve constantly-changing problems and thus constantly evolves too. If the software does not evolve to follow the world, then it does bitrot unlike what Dijkstra asserts.
Anecdotally, I've seen software being developed for the sole purpose of an event that would last a couple hours, software whose client needed it for the evening when calling in the morning, etc. It's a form of bitrot too: the code, event-specific, is as useful to us as the memories of said event a couple years in.
NKosmatos pointed out in another reply that this post was about software rot, and not data rot.
From the Wikipedia article he linked for software rot:
“[software rot] is not a physical phenomenon: the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides.”
The software doesn’t physically rot. Its relationship to something (the world) does.
I attempted to draw a parallel of this to a database because, for many folks, the immediate environment of their app is a database of some kind. The world is kind of like a database, too, because it is read from and written to. But unlike an in-house data store, it changes without regard for dependant applications.
In the second paragraph I attempted to distinguish two kinds of programming endeavours. One is like chopping wood for fire, the other like retrieving and then cutting a hard substance. Whatever the purpose of the latter, it takes planning, experience, and the result is both intended to last a long time, and to be versatile. But the former is cheap and short and for the moment. You’ll have to do it again, many times, and in slightly different ways, depending on where you are, who you’re with, what the weather is like, and so on. Dijkstra’s seeming dismissal of rot may be directed against the latter, but not the former.
I guess my third commentary is that many, many software systems are not designed at the time of their construction, because they are sudden and their manifestation is opportunistic. This lack of design at the point of construction is an implicit assertion against the expected lifetime of any such system. It admits rot as a matter of course.
Offers will vary, but, if impromptu answers carry any weight, then off the top of my Sunday afternoon head, this is the first reference that percolates to the surface.
They do not say why in the returned html.
I do not approve of such blockage.
Nevertheless. Knowledge is knowledge. So I post for everyone’s sake.