On Tuesday, 10 August 2021 at 06:23:39 UTC, Paulo Pinto 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 think in both cases a better comparison is Scala, since it's so close to Java. Martin Odersky cleaned up the OOP and made it multiparadigm (with functional programming) and a lot of people liked it. Since it's a programming language, people do complain about Scala, but they complain about other things. The features that stand out about Java are the boilerplate and the lack of expressiveness, and in my opinion, those criticisms are correct. In one sense, the Java language designers agree, since they've copied so much from languages like Scala.

On Tue, Aug 10, 2021 at 06:23:39AM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Monday, 9 August 2021 at 23:09:30 UTC, H. S. Teoh wrote:
> > ...
> > No offense taken.  I just find the OO extremism of Java to be
> > laughable, that's all.  Why not just admit that OO isn't the be-all
> > and end-all of programming, and call free global functions what they
> > are.
> > 
> > This is why D's multi-paradigm approach makes so much more sense: sometimes one paradigm doesn't fit the problem, why not acknowledge it and allow a different paradigm to step in.  Not every problem is a nail to which the OO hammer must be brought to bear.
[...]
> 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.

Whoa, slow down right there.  My rant was against shoehorning every programming problem into a single paradigm, not against OOP itself.  OOP certainly has its uses -- that's why D has it too!  The problem comes when OOP zealots try to shove it down everyone's throats even when the problem at hand clearly does not fit the glove.

I picked Java because that's the language I am most familiar with that exhibits this syndrome.  I don't know enough (well, any) Smalltalk or Eiffel to be able to criticize them coherently, and I have not written a single line of C#, so I don't have much to go on there.  Python I have written in very small scales, and it does have some nice things about it.  But I've not written enough non-trivial Python code to be able to criticize it effectively.

But the point is that single-paradigm languages ultimately suffer from the shoehorn program: trying to shoehorn every programming problem into a single mold, even when it doesn't really fit.  Certain algorithms are simply better expressed as an imperative loop that mutate variables; it's a royal pain in the neck to try to write the equivalent of such code in Lisp, for example.  It's certainly *possible*, thanks to Turing completeness, but exhibits all the symptoms of dressing up a duck as an aquatic chicken with webbed feet: it's awkward, requires excessive paraphrases, and more complex than it really needs to be.  The same can be said about writing range-based code in a language like C: you can do it, but it's awkward, error-prone, and just plain ugly.

In a multi-paradigm language, you can choose the best paradigm to express the algorithm at hand, in the most convenient, clear way, without having to resort to the shoe-horn. It's faster to write, easier to read, and more maintainable in the long run. You can treat a duck as a duck instead of an aquatic chicken with webbed feet. It's so refreshing not to have to paraphrase yourself all the time.


> How has D's multiparadigm helped to have a better marketshare than some of those extremist OOP languages?

I don't understand where marketshare enters the equation. We're talking about how well a language fits a problem domain, not about the fashion contest that is today's programming language "market".

(And incidentally, which language is most popular has very little to do with its technical merit, it is primarily determined by how much marketing capital it has and how well the marketing department sells it. With a large-enough marketing budget and a spark of marketing genius, you can sell *anything* to anyone.  I have no interest in what's popular and what's not; what I look for is technical excellence, which is the true value.)


T

-- 
Дерево держится корнями, а человек - друзьями.

On 8/9/2021 8:15 AM, bachmeier wrote:
> I did not study unsigned math in college.

There are no classes in unsigned math.

> I took one programming class and I've done a lot of independent study. Maybe I could figure out how to work with unsigned math, but why would I want to? I have better things to do with my time.

It's worth spending 5 minutes to learn what 2's complement arithmetic is.

https://en.wikipedia.org/wiki/Two%27s_complement#:~:text=Two's%20complement%20is%20a%20mathematical,two's%20complement%20is%202N.

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

On 8/9/2021 12:01 PM, bachmeier wrote:
> There's an important difference though. Signed/unsigned mistakes are a choice the programming language designer makes - Walter made his choice and Gosling made a different choice. You're more or less stuck with the limitations of floating point.

The thing about two's complement arithmetic, and IEEE floating point, is their faults are very well known. You can move your understanding of them from one language to the next.

It's worthwhile to invest a few minutes learning about them if you're going to spend your career programming.

Just like it's worthwhile learning about how tire adhesion works when looking forward to a decades of driving. (It can save your life.)

On 8/9/2021 12:23 PM, H. S. Teoh wrote:
> As Knuth once said:
> 
> 	People who are more than casually interested in computers should
> 	have at least some idea of what the underlying hardware is like.
> 	Otherwise the programs they write will be pretty weird.
> 	-- D. Knuth
> 
> That includes knowing the ugly realities of 2's complement arithmetic.

A friend mine (a very smart one) back in college one day decided to learn programming. He got the Fortran specification(!), read it, and wrote a program.

The program ran correctly, but incredibly slowly. Baffled, he took it to his programmer friend for help. The friend laughed, and said here's the problem: you're writing to a file in a loop:

    loop
        open the file
        append a character
        close the file

instead of:

   open the file
   loop
      append character
   close the file

My friend said he followed the spec, which said nothing at all about how file I/O actually worked.

On Tuesday, 10 August 2021 at 17:47:48 UTC, H. S. Teoh wrote:
> 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.

Of course, the obvious counterargument is that this approach is exactly how you end up with a language like C++: powerful in the hands of experts, with a large and successful ecosystem, but packed to the gills with pitfalls and footguns for beginners to hurt themselves with.

Ultimately, that's the question D's leadership has to answer. What's more important to D's future: existing users of D, or potential future users of D?

C++ has a lot of inertia, and doesn't necessarily need to attract new users to continue being a successful language. But I'm not sure the same is true for D. If C++ holds onto legacy features that cause pain for beginners, people will grumble and put up with it, because C++ is so entrenched that they have no better option. If D does the same thing, people are more likely to just leave for Rust, or Go, or C#.