You are a stupid programmer, you can't have that

[H. S. Teoh]

On Tue, Aug 10, 2021 at 10:59:58AM +0000, Brian Tiffin via Digitalmars-d wrote:
[...]
> *Now rambling to the room.* Being a fellow Canuck, I've followed the
> works of James Gosling with some interest, for a lot of years now.
> Back when it was Oak, and the smart agent in Oak was Duke, and Duke is
> still a very cool mascot.

Haha, didn't realize Gosling was Canadian.  Hooray for fellow
Canuckians!  ;-)


[...]
> When Java was first being hyped (and it was hyped, something like $500
> million was allocated to advertising by Sun), [...]
> [...] Real programmers wrote to machine code, not a play area sandbox.
> But, $500 million in advertising budget caught the eye of many a
> leader, and it was fun.

Yep, that's the perception I had from the 90's.  I was young and
idealistic, and immediately smelled the hype behind Java -- and
distrusted it.  Almost 3 decades later, I still distrust it.  But now,
with history in hindsight, it is also abundantly clear that what drives
programming language popularity is marketing budget.  Technical merit
plays at best a secondary role (if even).


[...]
> Java did not rise to fame on merit (it might have, more slowly). It rose to
> fame on aggressive marketing and expensive hype.  Since the lock in had
> started, many companies have poured billions into JVM technology, to ensure
> its success at making reasonably fast bumper cars run in a sandbox.

Yes, and that is why marketing hype is ultimately the decider of
technology adoption, not the technical merit itself.  First, with a
large enough budget, you attract the attention of the VIPs who make the
decisions at the top level. They dictate the use of said tech among the
lower ranks, and then over time the tech becomes entrenched, ensuring
its continued use.  Technical excellence does not play a major role
here.  If it works reasonably well, it will stay. And the longer it
stays, the harder it becomes to displace it. Inertia is a powerful
force.


[...]
> My bias to OOP is similar.  Watched too many large scale failures come
> and go with C++ and Java rip and replace projects.

As Joel Spolsky once said:

	... the single worst strategic mistake that any software company
	can make: They decided to rewrite the code from scratch.

;-)


> But when determined and with deep enough pockets most failures can be
> silently buried, small successes over hyped until it all becomes
> legacy code anyway, ready to be replaced by Go, Ruby, Rust, Zig, or
> whatever is the lang hype du jour at the time.

Haha, this reminds me of one of my favorite Walter quotes:

	I've been around long enough to have seen an endless parade of
	magic new techniques du jour, most of which purport to remove
	the necessity of thought about your programming problem.  In the
	end they wind up contributing one or two pieces to the
	collective wisdom, and fade away in the rearview mirror.
	-- Walter Bright


But yeah, it's the hype that drives adoption.  The technical merit, not
so much. If at all.


[...]
> Slow, long tail growth is the best kind of growth, in my old guy
> opinion.

I agree.

But that's a hard sell in today's age of instant gratification. Nobody
wants to -- nor has the time to -- gradually build up an infrastructure
that will last for the long term.  They want, and need, a solution NOW,
and you better be able to deliver NOW, otherwise they will just move on
to the next salesman who promises the here and now.

And it's hard to fault them when the investors are knocking on their
door asking when the promised results will materialize.


> D is making sound decisions in the now it seems, growing slowly, which
> is sound in the long term.  Now to convince the D dev team that we,
> the stupid programmers, leave behind code that may not age well if
> even a small language detail changes.  Cover that base and businesses
> will follow.
[...]

I think this is what Andrei has been saying every so often: stop
deleting, start adding.  I.e., never remove old features, just add new
ones to be used in favor if necessary.  If needed, deprecate and hide
away old features (hide away the docs so that new people don't
accidentally use it for new code), but never, ever remove it. If a new,
better way to do something is discovered, add it to the language,
highlight it front and center in the docs, but don't ever remove the old
stuff.  If we need to redesign Phobos, for example, do it in a new
namespace, don't remove/replace the old one.  Make it possible for the
two to coexist.  Accretion rather than replacement.

OT1H the idealist in me screams "please break my code, fix the language
to remove all the broken stuff!".  OTOH the long-term code maintainer in
me shakes his fists every time a compiler upgrade breaks one of my old
projects.

The solution to the conundrum is, accretion rather than replacement.
Let the old code compile.  Complain about deprecations if you have to,
but don't ever make it not compile (unless it was an outright bug to
have compiled in the first place).  But new code can use the new stuff
and benefit from it.


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts