On Tuesday, 10 August 2021 at 06:23:39 UTC, Paulo Pinto wrote:
> On Monday, 9 August 2021 at 23:09:30 UTC, H. S. Teoh wrote:
...
I love how people love to hate Java, yet have no words of hate against OOP in Smalltalk, SELF, Eiffel, Sather, C#, VB, Python (check methods from typeof(func)), Dart.
How has D's multiparadigm helped to have a better marketshare than some of those extremist OOP languages?
I may have started some of the jump on Java trend with the bumper car comment.
This may get long, as there are historical evolutions to cover, an old guy in the mood to ramble, and maybe pass on some learnin's, save a few younglings from some choice of programming tool angst.
I'm not going to speak for others, Paulo, but I find Java to be fun, not hated, more smirky amusing.
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.
Be sure to check out sc, the spreadsheet calculator, a TUI interface console spreadsheet with vi like key bindings. Something James also wrote, way back when as public domain code.
And some personal reasons behind the smirking at Java.
When Java was first being hyped (and it was hyped, something like $500 million was allocated to advertising by Sun), I was programming in Forth on a Vax for a phone company. PCs were toys and core business adjacent, not core business tools, in my mind at the time.
The web was a distraction, for science and amusement, viewed as business adjacent, not core. At the time. Could see the potential of Mosaic and the WWW, but would not have recommended it to a manager as a smart move for critical work. It was for the marketing department, not a competitor to telephony. The web did not seem like bigboy pants internet technology at the time, not like the more serious uses like Gopher, Telnet and FTP. :-)
Attitude on the web changed fairly quickly, but Java still seemed like a toy. 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.
Our Forth system was set to be superseded by an amalgam overlord system in C++, consolidating some 20 or 30 other large systems. Watched in predicted horror as three years of 300 people's time was wasted on project management and Grady Booch cloud diagram planning. 300 people. 3 years. The writing was on the wall when zero user level demo screens were available years after starting. C++ isn't going to work, this needs to be in Java, was the next recommendation.
I think the Forth project we worked on (for many more years after the story from above) was finally retired a few years ago after being outsourced to a Vaxen emulator in Bangalore a decade ago. The amalgam is still in a continuing cycle of development startup followed by cancel and fail, last I heard. 25ish years later. Yet, unless given the runway we initially enjoyed with the Forth system, I would not recommend Forth for large scale systems. You need time to build an application vocabulary when using Forth in the large, and there is little chance for cost recovery during that phase. Given lead time, absolutely, but that'd be a rare management decision in the 3rd millennium.
C++ rose to fame, in part, due to human pride. A sense of "I figured it out, ar'mant I smart". That's a powerful draw. For many, C++ is very smart. Smarter than some of us prideful programmers though.
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.
That's all ok, but I was young when it was just starting, and it smelled like a toy then. It still kinda smells like a toy, because of that initial bias.
Useful for business adjacent pretty reporting and such. Haven't been paid to work in Java since 1998-ish, but have followed it along the way, 1.2 was just coming out, with the whole J2EE thing (or J2SE, or JDK, can't quite remember the marketing speak without looking it up). I'm not sure, but I'd wager some of that Java 1.2 is still in the marketing application we wrote, if the company still exists.
Still enjoy exploring OpenJDK 11 now, and have an intrinsic FUNCTION JVM built into a version of GnuCOBOL, which should eventually be solid enough for us to advertise GnuCOBOL as ready to run any enterprise Java classes in an engine embedded in COBOL via JNI. At its core, JDK Java is written in C and GnuCOBOL compiles via C.
I'm still that kind of biased internally, COBOL for core business, Java for some fluffy bits and pretty pictures. Also realize that the amount of .class code in the world is immense. Why not leverage it to help an enterprise pursue its goals, while counting all the beans in COBOL, integrated tightly?
My bias to OOP is similar. Watched too many large scale failures come and go with C++ and Java rip and replace projects. 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.
Except for the life expectancy of source code thing, I'd happily hype D to any management at any large company. But at 6ish years of life expectancy before being forced to manually update a codebase, it'd be a hard sell for large systems. Will recommend D for business adjacent short span productivity applications from now on though.
How many sites still run Python 2 because the code borks in Python 3? How many sites will be on Java 8 until 2038 or beyond? The borks might be extremely trivial to a programmer, parens around arguments to print
for instance, but when a non-tech boss sees the first
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(name)?
they may just stick with Python 2 and get on with running their business. They paid for that code already. 10 years is nothing in that kind of time frame. They will wait until the pain of stagnation (or being mocked as archaic legacy) exceeds a threshold. Then they will pour money at the tech team, often times just to save face, and in a sour mood. There will always be another consultant ready to hype a tech, and promise a short cut to the promised land.
Slow, long tail growth is the best kind of growth, in my old guy opinion.
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.
To keep a little bit more in thread, some of the decisions may be guard rail protect the programmer from the programmer decisions. Those aren't all bad.
COBOL isn't active at 60 because it's great tech in the internet era, it's still active, with a huge market share, because it grew that big with a never shrinking codebase, that still compiles. Pennies are still pennies, core banking is still the same banking. If I'm not mistaken, the oldest still running codebase is a contract management system, MOCAS, for the U.S. department of defense. 60+ years old, mostly COBOL. There are billions on the line for the first team that can answer a still open call to convince DoD that a replacement won't drop any features or muck up any contracts in play at time of transition. Some have tried, all failed to convince the brass, so far. More famous, but still old is the SABRE airline reservation system, in COBOL/CICS. There are programs running in the IRS supporting the Individual Master File and Master Banking File projects still using (probably, these are not overly public source codes) COBOL sources written in 1962, recompiled for each new mainframe iteration.
Java 8 is set to enjoy suffer a similar fate. As is Python 2, Perl 5, ... (whether the Python/Perl/... core contributors like it or not). Ruby, maybe not, but maybe. If you can convince a company to pay for some code, they are not going to want to pay for the same code again, even decades later.
Ranting almost over. D design decisions seem like very sane long view decisions. But source codes need a longer life expectancy, or D may end up relegated to short and mid range development planning, ad infinitum. That's ok, if that is the end goal or an acceptable fate.
D does not feel like a design effort with stupid in mind. The guard rails and preferred paths in D seem well planned and well placed. Still new to D, could be completely wrong in the depths. Protecting from tricks some people may feel comfortable with but keeping simple mistakes from being catastrophic, painful to find and fix or costly to maintain, is not limiting, in my opinion, at least not in a bad way. That goes for D or any other programming language tool chain.
Have good, make well, excuse the long read and slow drift.